SUPORT PENTRU ACTIVITATI DE CURS

APLICATIE REZOLVATA

Prof. univ. dr. Alexandru Manole

amanole@artifex.org.ro
Aplicație 1. Reprezentarea datelor
Cerințele prezentate cu caractere bold constituie schema externă –
reprezentarea datelor la nivel extern.
Pentru informatizarea activității Societății Comerciale ABC SRL, se cunosc
următoarele:
 Societatea vinde cherestea. Produsele se caracterizează prin: Cod intern, cod de
bare, lungime, u.m., tip lemn, grosime, calitate, denumire;
 Vânzarea se realizează pe bază de factură, care conține: datele furnizorului,
serie număr factură, data facturii, valuta facturii, data scadentă, produsele
facturate, preț, cantitate, cota TVA, valoarea fără TVA pe linie factură, TVA pe
linie factură, valoare totală fără TVA, TVA total, valoare totală inclusiv TVA,
datele beneficiarului, nr. auto, semnătură primire, date șofer (CNP, nume, data
nasterii, categorie permis, data emiterii);
 Pentru beneficiari se rețin următoarele date: CNP_CUI, Nume_Denumire,
Adresa, Banca, cont (IBAN), email, telefon contact;
 Datele auto: număr auto, marca, tip remorcă, culoare, capacitate transport;
 Plata facturilor se poate realiza printr-o metodă de plată (cash, transfer
bancar), în baza unui document care conține: Nr_document, data document,
beneficiar, suma în valută, suma în lei, banca, factura/facturile decontate, contul,
plătitor, tip document plată. Se admite plata în tranșe a oricărei facturi, iar un
document de plată poate achita sume în contul mai multor facturi.
Aplicație 1. Reprezentarea datelor
Pentru elaborarea modelului conceptual, propunem următorul algoritm:
Etapa I. Reprezentarea entităţilor
Entităţile se utilizează pentru abstractizarea:
- persoanelor fizice/juridice;
- documentelor;
- bunurilor.
Observație 1: nu se va reprezenta o entitate pentru persoana fizică sau juridică
a cărei activitate face obiectul modelului (în cazul nostru SC ABC SRL). Datele
societății sunt mai degrabă constante și nu intră în categoria atribute. De
asemenea, crearea unei atare entități va provoca dificultăți atât în etapa a treia
(asocieri), dar și la construirea modelului logic de date, ceea ce conduce la
denaturarea structurii bazei de date.
Drept urmare, entităţile modelului nostru sunt:
 FACTURI
 SOFERI
 BENEFICIARI
 PRODUSE
 AUTO
 PLATA
Aplicație 1. Reprezentarea datelor
Observaţie 1’: deși putem vorbi de două tipuri de documente de plată, acestea
pot fi agregate într-o singură entitate, PLATĂ, prin unire. Pentru a marca
aplicarea unirii, este obligatoriu cel puțin un atribut care să diferențieze între
realizările de diferite tipuri (cash vs. transfer bancar). Un astfel de atribut se
poate denumi Tip document și asigură identificarea explicită între diferite tipuri
de realizări. Alternativ, se poate stabili că numărul documentului de plată
(atribut care deja există) poate fi utilizat în rolul menționat: numerele de
chitanțe încep cu prefixul CH, numerele ordinelor de plată încep cu OP
(identificare implicită a celor două tipuri de realizări).

Similar, observația se aplică pentru beneficiari. Fie se introduce (identificare

explicită) un atribut tip beneficiar, fie presupunem că diferențierea se face prin
CNP/CUI, având în vedere structura valorilor acestui atribut (CNP are 13
caractere, CUI mai puține, acest număr de caractere poate fi verificat cu o
funcție dedicată - identificarea implicită).
Aplicație 1. Reprezentarea datelor
Etapa II. Reprezentarea atributelor şi identificatorilor
Observaţie 2: nu se reprezintă, într-o entitate, atribute referitoare la altă
entitate din acelaşi model. În schimb, se vor reprezenta asocieri între entităţile
aflate în această situaţie.
Observaţie 2’: nu se vor reprezenta, în model, atribute ale căror valori pot fi
calculate pe baza valorilor altor atribute din același model.
Observaţie 2’’: în entitățile de tip document, se va acorda o atenție deosebită
oportunității de a înscrie alte atribute decât cele referitoare la numărul și data
documentului. Nu se vor defini într-o astfel de entitate atribute referitoare la
persoane implicate în circulația documentului, nici atribute care descriu
bunurile tranzacționate pe baza documentului.

Atributele și identificatorii entităţilor sunt următoarele:

 FACTURI: SerieNrf, Dataf, Valuta, Datasc, Semnpf
 SOFERI: CNPs, Numes, Datans, Categs, Dataem
 BENEFICIARI: CNP_CUI, Nume_denb, Adresab, Banca, IBAN, Emailb, Telb
 PRODUSE: Codintp, Codbarep, Lngp, UM, Tiplemn, Grp, Calp, Denp
 AUTO: Nrauto, Marca, Tipr, Culoare, Captr
 PLATA: Nrdoc, Datadoc, Tipdoc.
Aplicație 1. Reprezentarea datelor
 Conform observației nr. 1, nu se reprezintă entitate/atribute referitoare la societatea
comercială însăși. Descriptorul datele furnizorului nu se regăsește în modelul de
date (furnizorul este societatea comercială ABC SRL).
 Descriptorul produsele facturate nu se regăsește în entitatea PRODUSE –
observația nr. 2 (există entitatea PRODUSE).
 Descriptorul datele beneficiarului nu se regăsește în entitatea FACTURI –
observația nr. 2 (există entitatea BENEFICIARI).
 Atributul nr. auto nu se regăsește în entitatea FACTURI – observația nr. 2 (există
entitatea AUTO).
 Descriptorul date șofer și atributele asociate, din enunț, nu se reprezintă în entitatea
FACTURI – observația nr. 2 (există entitatea ȘOFERI).
 Atributele valoarea fără TVA pe linie factură, TVA pe linie factură, valoare totală
fără TVA, TVA total, valoare totală inclusiv TVA se pot calcula pe baza cantității,
prețului unitar și cotei de TVA.
 Atributele beneficiar, banca, factura/facturile decontate, contul, plătitor nu se
reprezintă în entitatea PLATA (observația nr. 1, respectiv observația nr. 2).
 Atributele cantitate, preț, cota TVA, suma în valută, suma în lei nu sunt
reprezentate în entități, datorită unor considerente care vor fi explicate în continuare.
Aplicație 1. Reprezentarea datelor
Etapa III. Reprezentarea asocierilor
În primul rând se vor trata situaţiile corespunzătoare observaţiei nr. 2.
• FACTURI - BENEFICIARI
• FACTURI - PRODUSE
• FACTURI - PLATA
• FACTURI - AUTO - SOFERI (asociere de grad trei – între trei entități). Acest tip
de asociere se reprezintă atunci când realizarea asocierii implică participarea unor
realizări ale tuturor celor trei entități. Reprezentarea prin asocieri de grad doi
FACTURI – AUTO, FACTURI – SOFERI, AUTO – SOFERI nu descrie complet
acțiunea prin care un anume șofer conduce un anumit auto care transportă produse
vândute în baza unei anumite facturi.
 Observaţie 3: nu se reprezintă asocieri între entităţi ce descriu persoane
implicate în tranzacții cu bunuri și entitățile care se referă la bunurile
respective. Ambele entităţi în schimb vor fi conectate prin asocieri cu
documentul justificativ al operaţiunii economice. Astfel, nu se poate asocia
BENEFICIARI cu PRODUSE, ambele se vor asocia cu FACTURI.
 Observaţie 3’: atributele cu semnificație cantitativ-valorică care se referă la
o tranzacție se înscriu în asocierea care descrie acea tranzacție, stabilită
între documentul justificativ al tranzacției și bunul tranzacționat. Ca
generalizare, întotdeauna atributele a căror realizare coincide cu realizarea
unei asocieri, vor fi înscrise în asocierea respectivă.
Aplicație 1. Reprezentarea datelor
Observaţie 3’’: Atributele ale căror valori pot fi considerate destul de
persistente în timp/spațiu, cum ar fi cele cu semnificație de cotă de
taxare/impozit/termen de plată etc. aplicabile unei tranzacții, se pot procesa, la
nivelul reprezentării datelor, în mai multe variante (trebuie să se țină cont de
faptul că valorile acestor cote pot varia în timp și/sau spațiu - dacă se aplică
valori diferite pentru diverse segmente ale activității pentru care se reprezintă
date, de exemplu cote de TVA diferite în funcție de bunurile comercializate):
1. Dacă avem un singur parametru sau acesta variază numai în timp, atributele
se pot reprezenta direct la nivelul fizic, într-un tabel auxiliar, cu următoarea
structură:
COTA (Data_in, Cota)
Fiind vorba de un singur parametru, nu se justifică reprezentarea unei entități,
iar absența variației în spațiu împiedică asocierea cu entitatea care reprezintă
obiectul impunerii – produsul în cazul aplicației de față.
2. Parametrizarea datelor – dacă sunt mai mulți parametri (nu este o problemă
prezența la un moment dat a unui singur parametru) și aceștia variază în timp
și în spațiu (acest criteriu îl apreciem a fi mai important).
Se definește o entitate auxiliară pentru parametrii care au semnificația descrisă
mai sus, care ar trebui să poarte cel puțin două atribute (un identificator și o
denumire pentru parametru), dar pot fi incluse și alte atribute – descrierea
economică, prezentarea cadrului legal etc.
Aplicație 1. Reprezentarea datelor
Această entitate se conectează printr-o asociere cu entitatea care reprezintă
obiectul impunerii, iar asocierea are două atribute proprii: data de la care intră
în vigoare cota de taxare (Data_inițială) și valoarea cotei de taxare.

Soluția va genera, în modelul logic și în baza de date, un tabel cu următoarea

structură:
TAXARE (Cod_parametru, Cod_produs, Data_inițială, Cota_taxare)
Datele astfel reprezentate se pot prelucra, în orice moment, prin încadrarea
documentului care generează obligația de impunere, prin valoarea atributului
care marchează data sa calendaristică, în intervalul de valabilitate al unei
anumite cote (interval definit de două valori succesive cronologic ale atributului
Data_inițială, a doua valoare marchează încheierea unui interval), precum și
asocierea între produsul comercializat (prin codul său) și cota aplicabilă, în
funcție de cod.
Aplicație 1. Reprezentarea datelor
b. La nivelul programelor-utilizator, se pot defini proceduri
dedicate pentru variația doar în timp:
- Procedura include istoricul cotelor de taxare și intervalele de
referință specifice;
- La fiecare actualizare a cotei de taxare, se „deschide” un nou
interval, care nu are definită limita superioară (este vorba de
cota de taxare în vigoare);
- Se citește data documentului;
- Se încadrează data documentului în intervalul de referință;
- Se preia cota de taxare corespunzătoare.
O astfel de soluție devine mai puțin practică atunci când cota de
taxare variază și în spațiu.

3. Reprezentarea cotei de taxare fără a apela la tabele suplimentare/auxiliare se

poate realiza astfel:
a. Valoarea atributului variază doar în timp - atributul se
înscrie în entitatea corespunzătoare documentului justificativ
aferent tranzacției.
b. Valoarea atributului variază și în spațiu - poziționarea sa va
fi ca atribut propriu al asocierii evidențiate de observația 3’.
Această abordare generează valori repetitive ale cotelor.
Aplicație 1. Reprezentarea datelor
Pentru tratarea acestor atribute, dacă nu se specifică explicit variația în spațiu,
se poate aborda soluția nr. 1: nu se reprezintă direct în model astfel de atribute,
datele lor sunt stocate și prelucrate într-un tabel auxiliar, direct în baza de date
fizică.
Această ultimă soluție – nr. 3 – a fost considerată în cadrul aplicației 1, pentru
exemplificare.
Astfel, în cazul aplicației de față, cantitatea, prețul și cota TVA se înscriu în
asocierea dintre entitățile FACTURI și PRODUSE.
Observaţie 3’’’: reprezentarea operațiunii de plată comportă mai multe
variante, în funcție de regulile comerciale stabilite între parteneri. Distingem
următoarele cazuri:
- se acceptă doar plata integrală, un document de plată se referă la o singură
factură:
* atributul Suma (suma plătită) se înscrie în entitatea PLATA
- se acceptă plata în tranșe, un document de plată se referă la o singură factură:
* atributul Suma se înscrie în entitatea PLATA
- cazul aplicației 1. se acceptă plata în tranșe, iar un document poate deconta
sume în contul mai multor facturi:
* atributul Suma se înscrie în asocierea FACTURI - PLATA.
Dacă nu se precizează nimic în acest sens, recomandăm utilizarea soluției din
această aplicație, respectiv cea mai acoperitoare.
Aplicație 1. Reprezentarea datelor
Înainte de a se trece la etapa IV, se verifică trei „chei de control”:
a) fiecare entitate participă la cel puţin o asociere.
Soluția minimală, în cazul în care pentru o entitate A nu se verifică acest criteriu,
identificarea celei mai relevante entități cu care A să fie conectată printr-o asociere.
b) modelul nu este segmentat în mai multe submodele care să fie ne-conectate;
Un astfel de exemplu (reprezentat simplificat) este redat în figura de mai jos:

A B C

D E

Considerând A, B, C, D și E entități, iar liniile dintre ele asocieri, se observă că, deși
fiecare entitate participă la o asociere (sau două, în cazul entității B), modelul este
segmentat în două submodele: unul include entitățile A, B și C; celălalt entitățile D
și E.
Soluția minimală: reprezentarea unei asocieri între una din entitățile A, B și C și una
din entitățile din submodelul D – E.
c) toate atributele și acţiunile (corelaţiile) din enunţ sunt reflectate în model.
 Aplicație 1. Reprezentarea datelor
Etapa IV. Reprezentarea cardinalităţilor
 Pentru reprezentarea cardinalităţilor, în fiecare asociere se analizează situaţia fiecărei entităţi,
determinând numărul realizărilor celeilalte entităţi şi stabilind cardinalităţile corespunzătoare.
 Asocierea FACTURI – SOFERI – AUTO:
 o FACTURĂ implică participarea a cel minimum un AUTO cu ȘOFER și maximum
mai multor AUTO și ȘOFERI (cardinalitate 1,n).
 un ȘOFER poate conduce mai multe AUTO, executând transporturi în baza mai multor
FACTURI (cardinalitate 1,n).
 un AUTO poate fi angrenat în transportul produselor vândute prin mai multe FACTURI
și, în decursul timpului, poate fi condus de mai mulți ȘOFERI (cardinalitate 1,n).
 Asocierea FACTURI – PRODUSE:
 o FACTURĂ include mai multe PRODUSE (cardinalitate 1,n – obligatoriu 1, nu 0,
deoarece se facturează minim un produs).
 un PRODUS poate apare pe mai multe facturi (cardinalitate 1,n sau 0,n).
 Asocierea FACTURI – PLĂȚI:
 o FACTURĂ poate fi plătită integral sau în tranșe (cardinalitate 1,n).
 un DOCUMENT poate deconta sume în contul mai multor FACTURI (cardinalitate
1,n).
 Asocierea FACTURI – BENEFICIARI:
 o FACTURĂ este emisă către un singur BENEFICIAR (cardinalitate 1,1).
 un BENEFICIAR poate primi mai multe FACTURI (cardinalitate 1,n).
Aplicație 1. Reprezentarea datelor
 Reprezentarea datelor
Pachet pedagogic – tema 3
 Cuvinte - cheie
 Nivel extern.
 Nivel conceptual
 Entitate.
 Atribut.
 Realizare.
 Asociere.
 Cardinalitate.
 Rol.
 Identificator.
 Reprezentarea datelor
 Întrebări

 Care sunt cele trei categorii de cerințe care rezultă în urma colectării
informațiilor la nivelul extern?
 Care sunt cele trei tipuri de obiecte care pot fi reprezentate prin entități?
 Ce rol are identificatorul entității?
 Care este corelația dintre noțiunile entitate și realizare a entității?
 Ce este asocierea reflexivă?
 Cum se reprezintă corect entitățile și asocierile între entitățile descrise
mai jos:
 Un tip de document în baza căruia se realizează tranzacții cu un anumit tip de
bunuri;
 Bunurile tranzacționate cu acest document;
 Partenerii implicați în tranzacție (persoane fizice/juridice).
 TEMA 4.
Nivelul logic
4.1. Definiție. Modelul logic de tip relațional.
4.2. Instrumentele modelului relațional.
4.3. Regulile de trecere la modelul relațional.
4.4. Aplicații.
 Modelul logic al datelor
4.1. Definiție. Modelul logic de tip relațional
 Modelul logic al datelor presupune reprezentarea datelor utilizând
instrumente compatibile cu SGBD în care va fi implementată
baza de date (de la logiciel în limba franceză = program). Pentru
SGBD relaționale, se va utiliza modelul relațional.
4.2. Instrumentele modelului relațional
- Relația: o structură de date bidimensională, similară unui tabel
(tabel este denumirea instrumentului utilizat la nivel fizic pentru
reprezentarea relației în accepțiunea unor SGBD relaționale).
Termenul de relație, în acest context nu trebuie confundat cu cel
de asociere sau corespondență;
- Orice relație poartă un nume (întrucât relația provine dintr-o
entitate sau asociere a modelului conceptual, este de așteptat să
preia numele obiectului sursă);
- Fiecare coloană a relației corespunde unui anumit atribut, care
are propriul nume, care permite diferențierea atributelor între ele
(ca și în cazul relației, numele poate fi păstrat de la MCD).
 Modelul logic al datelor
- Denumirile relațiilor și atributelor trebuie să fie unice, pentru a
nu genera confuzii;
- Fiecărui atribut îi corespunde un domeniu de valori (mulțimea
valorilor acceptate pentru atribut). La trecerea la nivelul fizic,
domeniul atributului se va regăsi în tipul de date și celelalte
restricții definite pentru valorile atributului;
- O relație reprezintă date despre mai multe obiecte, iar pentru
fiecare obiect individual există în cadrul relației un tuplu. Altfel
spus, un tuplu se formează dintr-un grup de valori, cel mult o
valoare pentru fiecare atribut (pot exista valori necompletate,
dacă acestea nu încalcă regulile privind integritatea datelor).
- Inclusiv datele care descriu structura bazei de date (metadatele)
este necesar a fi stocate conform aceluiași principiu.
 Modelul logic al datelor
- Cheia primară: „un atribut sau grup de atribute care
identifică, prin valori distincte sau combinaţii de valori
distincte”, fiecare tuplu dintr-o relație. Pentru cheile
primare nu se acceptă valori nule;
- Cheia externă: un atribut dintr-o relație care este cheie
primară în altă relație. Între cele două atribute se stabilește
restricția de integritate referențială.
 Orice relație are cel puţin o cheie: primară sau externă.
În baza corespondenței din definiția cheii externe, se
definesc, la nivelul fizic, legăturile dintre tabele.
 Conger (2012) are în vedere următoarele avantaje
ale modelului relațional:
- Minimizarea redundanței;
- Corelarea datelor din diferite segmente ale bazei de date.
 Modelul logic al datelor
 Datele despre fiecare persoană sau bun sunt reprezentate o
singură dată, ca tuplu în relația respectivă, iar dacă o persoană,
sau un bun, sunt implicate într-o acțiune descrisă printr-o altă
relație, se preia doar valoarea corespunzătoare persoanei sau
bunului, în înregistrarea referitoare la acțiunea respectivă, ca
valoare a cheii externe care referă persoana sau bunul.
 Simplitatea și aplicabilitatea modelului permit utilizarea
acestuia ca instrument de lucru inclusiv în scop didactic.

Modelul logic poate fi reprezentat prin utilizarea notației:

NUME_TABEL (Cheieprimară, Atribut2, …, Atributn,
Cheieexternă), conform Năstase și colectiv (2000).
Dacă sunt mai multe tabele, acestea pot fi reprezentate unul sub
altul.
 Modelul logic al datelor
4.3. Regulile de trecere la modelul relațional.
 Modelul relaţional se obţine din modelul conceptual, prin
aplicarea regulilor de trecere:
 „R1. Toate entităţile se transformă în tabele. Atributele
entităţilor devin atribute ale tabelelor. Identificatorii entităţilor
devin chei primare ale tabelelor.
 R2. Asocierile în care ambele cardinalităţi maxime sunt n se
transformă în tabele. Atributele asocierii, dacă există, devin
atribute ale tabelelor corespunzătoare. Identificatorii entităţilor
participante la asociere devin chei externe ale noului tabel.
 R3. Asocierile în care una din cardinalităţile maxime este 1 şi
cealaltă n dispar. Tabelul provenit din entitatea cu
cardinalitatea maximă 1 preia identificatorul celeilalte entităţi,
cu rol de cheie externă.
 R4. Asocierile în care ambele cardinalităţi maxime sunt 1
dispar. Una dintre entităţi preia identificatorul celeilalte
entităţi, cu rol de cheie externă”.
 Modelul logic al datelor
 Regula nr. 1 (R1) se aplică prima. Este singura regulă care
se aplică pentru entități.
 După reprezentarea tabelelor, atributelor și cheilor primare
conform cu regula R1, se analizează fiecare asociere,
evaluându-se combinația de cardinalități maxime.
 Dacă ambele cardinalități maxime sunt n se aplică regula
nr. 2 (R2). Se recomandă definirea combinației de chei externe
a tabelelor rezultate prin R2, drept cheie primară compusă.
 Dacă numai una din cardinalitățile maxime este n, se aplică
R3.
 Dacă ambele cardinalități maxime sunt 1, se aplică R4.
Alternativ, atributele celor două entități se pot comasa în
același tabel.
 Modelul logic al datelor
Pachet pedagogic – tema 4
 Cuvinte - cheie
 Nivel logic.
 Model relațional.
 Tabel – relație.
 Atribut.
 Înregistrare - tuplu.
 Cheie primară.
 Cheie externă.
 Trecere de la MCD la MLD.
 Modelul logic al datelor
 Întrebări

 Care este rolul cheilor primare?

 Cum se formează cheile externe?
 Pentru ce obiecte din modelul conceptual de tip EAC se aplică regula de
trecere R1?
 Când se aplică regula de trecere R2?
 Cum se aplică regula de trecere R4?
 Ce convenții se utilizează pentru reprezentarea cheilor primare? Dar a
celor externe?
 Ce instrument permite definirea, la nivel fizic, a legăturilor între tabele?
Aplicație 1. Reprezentarea datelor
Reprezentarea modelului logic al datelor
 Etapa I. Se aplică mai întâi regula R1, se reprezintă tabelele, atributele şi cheile
primare conform structurii entităților.
 Etapa II. Se analizează fiecare asociere, şi se aplică regula R2, R3 sau R4.
 Asocierea FACTURI-PRODUSE (FACTURARE)
 Cardinalităţile maxime sunt n şi n.
 Asocierea se transformă în tabel (tabelul FACTURARE).
 În noul tabel se înscriu cele trei atribute ale asocierii: Cant, Pret, Cota TVA.
 Tabelul preia și identificatorii entităților participante la asociere, respectiv
SerieNrf de la FACTURI și Codintp de la PRODUSE, cu rol de chei externe.
 Asocierea FACTURI-BENEFICIARI (VANZARE)
 Cardinalităţile maxime sunt 1 şi n. Asocierea NU se transformă în tabel.
Tabelul provenit din entitatea FACTURI preia identificatorul de la
BENEFICIARI, CNP_CUI, cu rol de cheie externă.
Aplicație 1. Reprezentarea datelor
 Asocierea FACTURI-PLATA (DECONT)
 Cardinalităţile maxime sunt n şi n. Asocierea se transformă în tabel (tabelul
DECONT).
 În noul tabel se înscriu atributele asocierii: SumaV și SumaL.
 Tabelul preia și identificatorii entităților participante, respectiv SerieNrf de la
FACTURI si Nrdoc de la PLATA, cu rol de chei externe.
 Asocierea terțiară FACTURI-SOFERI-AUTO (EMITE)
 Cardinalităţile maxime sunt n. Asocierea se transformă în tabel, care preia
identificatorii entităților participante, cu rol de chei externe.
Rezultatul aplicării regulilor de trecere este prezentat în continuare (cheile cu
italic corespund regulii nr. 2, cele cu bold regulii nr. 3):
 FACTURI (SerieNrf, Dataf, Valuta, Datasc, Semnpf, CNP_CUI)
 SOFERI (CNPs, Numes, Datans, Categs, Dataem)
 BENEFICIARI (CNP_CUI, Nume_denb, Adresab, Banca, IBAN, Emailb, Telb)
 PRODUSE (Codintp, Codbarep, Lngp, UM, Tiplemn, Grp, Calp, Denp)
 AUTO (Nrauto, Marca, Tipr, Culoare, Captr)
 PLATA (Nrdoc, Datadoc, Tipdoc)
 DECONT (Nrdoc, SerieNrf, SumaV, SumaL)
 TRANSPORT (Nrauto, SerieNrf,CNPs)
 FACTURARE (Codintp, SerieNrf, Cantf, PretF, Cota_TVA)
Aplicație 1. Reprezentarea datelor
Etapa descrisă în continuare nu face parte din cerințele pentru examen.
Etapa III. Se asigură unicitatea realizărilor de asocieri, prin transformarea cheilor
externe multiple (este vorba de tabele configurate prin efectul regulii nr. 2) în chei
primare compuse.
În tabelele FACTURARE și DECONT, nu este nici o problemă din acest punct de
vedere, prin prisma cardinalităților acceptate pentru asocierile din care provin cele
două tabele:
- nu se poate înscrie, pe o singură factură, decât o singură dată, un anume cod
de produs, cu cantitatea și prețul corespunzătoare;
- nu se poate înscrie, pe un document de plată, mai mult de o sumă
corespunzătoare unei anumite facturi achitate.
În tabelul TRANSPORT, o astfel de cheie permite participarea unui anumit șofer,
conducând o anumită mașină, la un singur transport efectuat în contul unei anumite
facturi.
Dacă o asemenea restricție nu se acceptă, o soluție este definirea în modelul fizic a
unui atribut care, fără a fi cheie primară, poate fi configurat să nu admită duplicate.
Pentru înscrierea unor atribute suplimentare – data, ora plecării, ora sosirii etc. o
soluție poate fi introducerea unui document special (fișă transport), care va
beneficia de o entitate proprie, care se asociază cu AUTO, FACTURI și ȘOFERI,
în locul asocierii ternare din acest exemplu.