Capitolul 8.

Proiectarea logică

Scopul proiectării logice este de a construi o schemă logică ce reprezintă corect şi eficient
toate informaţiile descrise într-o schemă entitate-relaţie.
Translatarea din schema conceptuală în cea logică nu este un proces simplu deoarece, în
primul rând, nu toate construcţiile modelului E-R pot fi translatate natural într-un model relaţional.
Spre exemplu, dacă o entitate poate fi reprezentată simplu printr-o relaţie, pentru o generalizare
există mai multe variante. În al doilea rând, scopul proiectării conceptuale este de reprezenta datele
la un nivel înalt de abstractizare, fără a ţine cont de detaliile de implementare. Proiectarea logică
trebuie să ia în considerare performanţele impuse produsului final. Din acest motiv, proiectarea
logică presupune parcurgerea următoarelor etape:
• Restructurarea schemei E-R – fază independentă de modelul logic ales şi care se
bazează pe criterii de optimizare a schemei şi de simplificare a următoarei etape;
• Translarea în modelul logic –care ţine cont de un anumit model logic (modelul
relaţional spre exemplu) şi poate include alte optimizări, bazate pe caracteristicile
modelului logic.

La intrarea primei etape există schema conceptuală şi estimarea încărcării bazei de date
(cantitatea de date şi cerinţele operaţionale). Rezultatul acestei etape este schema E-R restructurată,
care nu mai este o schemă E-R propriu-zisă deoarece utilizează aspecte de implementare pentru
reprezentarea datelor.
Această schemă şi modelul logic ales formează intrarea celei de-a doua etape, care va
produce schema logică a bazei de date, împreună cu constrângerile de integritate aferente şi
documentaţia.

Figura 1. Proiectarea logică a unei baze de date

 8.1 Analiza performanţelor schemei E-R

O schemă E-R poate fi modificată astfel încât să se optimizeze unii indicatori de

performanţă:
• costul unei operaţii – evaluat în funcţie de numărul de apariţii ale entităţilor şi relaţiilor
ce sunt parcurse pentru a executa o operaţie asupra unei baze de date;
• cerinţa de stocare – evaluată în funcţie de numărul de octeţi necesari stocării datelor
descrise de schemă.
Pentru a evalua aceşti indicatori avem nevoie de următoarele informaţii:
• volumul de date
– numărul de apariţii ale fiecărei entităţi şi relaţii din schemă;
– dimensiunea fiecărui atribut.
• caracteristicile operaţiilor:
– tipul operaţiei (interactivă sau batch);
– frecvenţa operaţiei (numărul mediu de execuţii într-un anumit interval de timp);
– datele implicate (entităţi şi/sau relaţii).

Să luăm ca exemplu schema din figura următoare:

Figura 2. Exemplu de schemă E-R

Operaţiile tipice pentru această schemă pot fi:

• operaţia 1: atribuie un angajat unui proiect;
• operaţia 2: găseşte datele pentru un angajat, pentru departamentul în care lucrează acesta
şi pentru proiectele în care este implicat;
• operaţia 3: găseşte datele pentru toţi angajaţii unui anumit departament;
• operaţia 4: pentru fiecare filială, găseşte departamentele, cu numele managerilor şi lista
angajaţilor din fiecare departament.
 Volumul datelor şi caracteristicile generale ale operaţiilor pot fi descrise prin utilizarea unor
tabele, ca în figura următoare:

Tabelul volumelor
Concept Tip Volum
Filială E 10 Tabelul operaţiilor
Departament E 80 Operaţie Tip Frecvenţă
Angajat E 2000 Op 1 I 50/zi
Proiect E 500 Op 2 I 100/zi
Compoziţie R 80 Op 3 I 10/zi
Membru R 1900 Op 4 B 2/săptămână
Management R 80
Participare R 6000
Figura 3. Exemplu de tabele ale volumelor şi operaţiilor

În tabelul volumelor se prezintă toate conceptele schemei (entităţi şi relaţii) cu volumul lor
estimat. În tabelul operaţiilor se înscriu, pentru fiecare operaţie, frecvenţa aşteptată şi un simbol
care arată dacă operaţia este interactivă (I) sau batch (B).
În tabelul volumelor, numărul apariţiilor unei relaţii depinde de doi parametri:
• volumul entităţilor implicate în relaţie
• de câte ori o apariţie a acestor entităţi participă, în medie, într-o apariţie a relaţiei; acest
parametru depinde de cardinalităţile relaţiei.
Spre exemplu, numărul de apariţii ale relaţiei COMPOZIŢIE este egal cu numărul
departamentelor, deoarece cardinalitatea relaţiei indică faptul că fiecare departament aparţine doar
unei filiale. Numărul de apariţii ale relaţiei MEMBRU este mai mic decât numărul angajaţilor,
deoarece există angajaţi care nu aparţin nici unui departament. Dacă un angajat este implicat în
medie în trei proiecte avem 6000 de apariţii ale relaţiei PARTICIPARE (şi deci 6000/500=12 angajaţi
în medie pentru fiecare proiect).
Pentru fiecare operaţie se pot descrie datele implicate prin intermediul schemei de navigare
care constă în fragmente ale schemei E-R relevante pentru operaţie. Pe această schemă este utilă
desenarea „căilor logice” care trebuie urmate pentru a accesa informaţiile cerute. Un exemplu de
schemă de navigare este prezentat în figura 4, referitoare la operaţia 2.

Figura 4. Exemplu de schemă de navigare

 Acum se poate estima costul unei operaţii prin numărarea accesărilor apariţiilor entităţilor şi
relaţiilor necesare efectuării unei operaţii.
Ca exemplu ne vom referi tot la operaţia 2. Ţinând cont de schema de navigare trebuie să
accesăm întâi o apariţie a entităţii ANGAJAT pentru a accesa o apariţie a relaţiei MEMBRU şi, prin
intermediul acesteia, a unei apariţii a entităţii DEPARTAMENT. Pentru a obţine datele referitoare la
un proiect la care angajatul lucrează trebuie să accesăm în medie trei apariţii ale relaţiei
PARTICIPARE (deoarece am presupus că un angajat lucrează în medie la trei proiecte). Apoi, prin
această relaţie accesăm în medie trei apariţii ale entităţii PROIECT. Aceste informaţii pot fi sumate în
tabelul accesărilor din figura 5. În ultima coloană a acestui tabel se menţionează tipul accesului (R
pentru citire, W pentru scriere)

Tabelul accesărilor
Concept Tip Accesări Tip
Angajat Entitate 1 R
Membru Relaţie 1 R
Departament Entitate 1 R
Participare Relaţie 3 R
Proiect Entitate 3 R
Figura 5. Tabelul accesărilor pentru operaţia 2

8.2 Restructurarea schemei E-R

Etapele restructurării unei scheme E- R sunt precizate în figura 6.

Figura 6. Etapele restructurării schemei E-R

• analiza redundanţelor - decide ştergerea sau păstrarea unor redundanţe din schema E-R;
• eliminarea generalizărilor - înlocuieşte toate generalizările cu alte construcţii;
 • partiţionarea/combinarea entităţilor şi relaţiilor – decide dacă este convenabilă
partiţionarea unui concept în mai multe sau unirea mai multor concepte separate în unul
singur;
• selecţia identificatorilor primari – alege un identificator pentru acele entităţi care au mai
mult de un identificator.

Analiza redundanţelor

Într-o schemă conceptuală o redundanţă corespunde unei informaţii ce poate fi derivată din
alte date. Cele mai frecvente exemple sunt:
• atribute ale căror valori pot fi derivate, pentru fiecare apariţie a unei entităţi/relaţii, din
valorile altor atribute pentru aceeaşi apariţie. În exemplul de mai jos, fiecare atribut poate
fi dedus din celelalte două prin operaţii aritmetice

• atribute ce pot fi derivate din alte atribute aparţinând altor entităţi/relaţii, de obicei prin
intermediul funcţiilor agregat. În exemplul următor, atributul ValoareTotala a
entităţii ACHIZITIE poate fi calculat din valorile atributului Pret a entităţii PRODUS prin
sumarea preţurilor produselor achiziţionate, după cum se specifică în relaţia
COMPUNERE.

• atribute ce pot fi derivate din operaţii de numărare a apariţiilor. În exemplul de mai jos,
atributul NumarLocuitori poate fi obţinut prin numărarea apariţiilor relaţiei
REZIDENŢĂ în care apare un anumit oraş.

• relaţii ce pot fi derivate din alte relaţii în prezenţa ciclurilor. Relaţia INVATARE dintre
studenţi şi profesori poate fi derivată din relaţiile PREZENŢĂ şi ATRIBUIRE. Prezenţa
ciclurilor nu generează în mod automat redundanţe. Spre exemplu, dacă se înlocuieşte
relaţia INVATARE cu relaţia SUPERVIZARE reprezentând legătura dintre studenţi şi
supervizori, atunci schema nu mai este redundantă.
 Prezenţa informaţiilor derivate într-o bază de date prezintă un avantaj şi totodată
dezavantaje.
Avantajul este reducerea numărului de accesări necesare obţinerii informaţiilor derivate.
Dezavantajele ar fi:
• creşterea cererii de stocare;
• necesitatea efectuării de operaţii suplimentare pentru actualizarea informaţiilor derivate.
Decizia menţinerii sau eliminării unei redundanţe poate fi luată prin compararea costului
operaţiilor ce implică informaţia redundantă şi capacitatea de stocare necesară în cazul prezenţei,
respectiv absenţei redundanţei.

Exemplu

Să considerăm exemplul referitor la persoane şi oraşe

pentru care se definesc următoarele operaţii:

• operaţia 1: adaugă o persoană nouă cu oraşul de rezidenţă al acesteia;
• operaţia 2: afişează toate datele referitoare la oraş (inclusiv numărul de locuitori).
Presupunem de asemenea că încărcarea bazei de date este dată în tabelele de mai jos.
Volumul relaţiei REZIDENŢĂ este egal cu volumul entităţii PERSOANA deoarece cardinalităţile
indică faptul că fiecare persoană are rezidenţa într-un singur oraş.

Tabelul volumelor Tabelul operaţiilor

Concept Tip Volum Operaţie Tip Frecvenţă
Oraş E 200 Op 1 I 500/zi
Persoană E 1000000 Op 2 I 2/zi
Rezidenţă R 1000000

1. Să facem o evaluare a performanţelor în cazul prezenţei redundanţei (atributul

NumarLocuitori).
Presupunem că pentru stocarea numărului de locuitori dintr-un oraş sunt necesari 4 octeţi.
Astfel, datele redundante necesită 4 x 200 = 800 octeţi (nesemnificativ).
Să estimăm acum costul operaţiilor.
Pentru operaţia 1:
• 1 operaţie de scriere în entitatea PERSOANĂ (adăugare persoană);
• 1 operaţie de scriere în relaţia REZIDENŢĂ (adăugare pereche persoană-oraş);
 • 1 operaţie de citire din entitatea ORAŞ (găsire oraş);
• 1 operaţie de scriere în entitatea ORAŞ ( actualizare număr de locuitori).
Tabelul accesărilor (în prezenţa redundanţelor)
Operaţia 1
Concept Tip Accesări Tip
Persoana E 1 W
Rezidenţă R 1 W
Oraş E 1 R
Oraş E 1 W
Operaţia 1 necesită 3 x 500 = 1500 accesări în scriere / zi
1 x 500 = 500 accesări în citire / zi
Pentru operaţia 2:
• 1 operaţie de citire din entitatea ORAŞ
Tabelul accesărilor (în prezenţa redundanţelor)
Operaţia 2
Concept Tip Accesări Tip
Oraş E 1 R
Operaţia 2 necesită 1 x 2 = 2 accesări în scriere / zi (neglijabil)
Presupunând că accesul în scriere costă de două ori mai mult decât accesul în citire, numărul
de accesări / zi în prezenţa redundanţelor este 2 x 1500 + 500 = 3500.

2. Să facem o evaluare a performanţelor în cazul absenţei redundanţei. Vom evalua costul

operaţiilor.
Pentru operaţia 1:
• 1 operaţie de scriere în PERSOANA;
• 1 operaţie de scriere în REZIDENŢĂ.
Tabelul accesărilor (în absenţa redundanţelor)
Operaţia 1
Concept Tip Accesări Tip
Persoana E 1 W
Rezidenţă R 1 W
Operaţia 1 necesită 2 x 500 = 1000 accesări în scriere / zi
Pentru operaţia 2:
• 1 operaţie de citire din ORAŞ (neglijabil)
• în medie 5000 de operaţii de citire din REZIDENŢĂ pentru a determina numărul de
locuitori (5000 = 1000000 persoane / 200 oraşe)
Tabelul accesărilor (în absenţaredundanţelor)
Operaţia 2
Concept Tip Accesări Tip
Oraş E 1 R
Rezidenţă R 5000 R
Operaţia 2 necesită 2 x 5000 = 10000 accesări în citire / zi
Numărul de accesări / zi în absenţa redundanţelor este de 2 x 1000 + 10000 = 12000.
Se observă că în al doilea caz sunt necesare 8500 accesări / zi în plus pentru a „salva” mai
puţin de un kilo-octet. Putem trage concluzia că este mai convenabil să menţinem redundanţa în
cazul acestei probleme.
 Eliminarea generalizărilor

Deoarece modelul relaţional nu permite reprezentarea directă a generalizărilor din modelul

E-R apare necesitatea transformării acestor construcţii în alte construcţii ce pot fi translate cu
uşurinţă.
Există trei posibilităţi de reprezentare a unei generalizări cu ajutorul entităţilor şi relaţiilor.
Pentru înţelegerea acestor moduri de transformare să considerăm schema din figura 7.

Figura 7. Exemplu de schema cu generalizare

1. Înglobarea entităţilor copil în entitatea părinte

Entităţile E1 şi E2 sunt eliminate şi proprietăţile acestora sunt adăugate proprietăţii părinte E0.
Se adaugă entităţii părinte atributul Atype pentru a distinge tipul (E1 sau E2) unei apariţii a lui E0. A11
şi A21 pot avea valoarea NULL pentru unele apariţii ale entităţii E0. Relaţia R2 va avea cardinalitatea
minimă 0 pentru E0 deoarece apariţiile lui E2 formează o submulţime a apariţiilor entităţii E0.

2. Înglobarea entităţii părinte în entităţile copil

 Entitatea părinte E0 este eliminată şi, prin proprietatea de moştenire, atributele sale,
identificatorii şi relaţiile în care era implicată sunt adăugate entităţilor copil E1 şi E2. Relaţiile R11 şi
R12 reprezintă restricţia relaţiei R1 pe apariţiile entităţii E1, respectiv E2.

3. Substituirea unei generalizări cu relaţii

Generalizarea este transformată în două relaţii „una la unu” ce leagă părintele de copiii E1 şi
E2. Nu există transfer de atribute sau relaţii şi entităţile E1 şi E2 sunt identificate extern prin entitatea
E0. În noua schemă apar constrângeri în plus: nici o apariţie a lui E0 nu poate participa în ambele
relaţii RG1 şi RG2.; mai mult, dacă generalizarea este completă, fiecare apariţie a lui E0 trebuie să
participe în exact una din relaţiile RG1 şi RG2.

Pentru a alege una din cele trei variante trebuie avute în vedere următoarele aspecte:

• Prima opţiune este convenabilă atunci când operaţiile implică apariţii şi atribute ale E0,
E1 şi E2 într-un mod asemănător. În acest caz, deşi se stochează valori NULL, alegerea
asigură mai puţine accesări în comparaţie cu celelalte variante în care apariţiile şi
atributele sunt distribuite celorlalte entităţi.
• A doua opţiune este posibilă doar dacă generalizarea este totală, altfel apariţiile lui E0
care nu sunt apariţii nici ale lui E1 nici ale lui E2 nu vor putea fi reprezentate. Această
metodă este utilă când există operaţii care se referă doar la apariţiile lui E1 sau ale lui E2
şi astfel se face distincţia între aceste entităţi. Nu mai există în principiu atribute ce pot
lua valori NULL. Numărul de accesări este mai redus în comparaţie cu a treia metodă,
deoarece nu este necesară accesarea lui E0 pentru a accesa atribute ale E1 şi E2.
• A treia metodă este utilă atunci când generalizarea nu este totală şi operaţiile se referă fie
la apariţiile şi atributele lui E1(E2) fie ale lui E0 şi astfel se face distincţia între entităţile
părinte şi copil. Stocarea este mai mică în raport cu prima metodă datorită absenţei
valorilor NULL dar creşte numărul accesărilor pentru a păstra consistenţa apariţiilor.

Opţiunile prezentate nu sunt singurele posibile. O variantă ar fi cea din figura 8. În acest caz,
pe baza consideraţiilor anterioare, s-a decis înglobarea E0 şi E1 şi lăsarea separată a lui E2. Atributul
Atype este adăugat pentru a distinge apariţiile lui E0 de cele ale E1.
 Figura 8. Restructurare posibilă a schemei din figura 7

Partiţionarea / combinarea entităţilor şi relaţiilor

Creşterea eficienţei accesului la datele dintr-o bază de date se poate realiza conform
următorului principiu: operaţiile de acces sunt reduse prin separarea atributelor aceluiaşi concept
(entitate sau relaţie) ce sunt accesate de operaţii diferite, respectiv prin combinarea atributelor
aparţinând unor concepte diferite ce sunt accesate de aceleaşi operaţii.

Partiţionarea entităţilor

Un exemplu de partiţionare a entităţilor este prezentat în figura 9: entitatea ANGAJAT este

substituită prin două entităţi legate printr-o relaţie 1:1. Una din entităţi descrie informaţii despre
statutul unui angajat, iar cealaltă descrie informaţii personale ale unui angajat. Acest tip de
restructurare este utilă doar dacă operaţiile ce implică frecvent entitatea originală necesită, pentru un
angajat, ori numai informaţii personale, ori numai informaţii legate de angajare.

Figura 9. Exemplu de partiţionare a entităţilor

 Acest exemplu este un exemplu de partiţionare verticală, în sensul că un concept este
divizat ţinând cont de atributele sale. Avantajul partiţionării verticale este generarea unor noi entităţi
cu număr mai mic de atribute decât entitatea originală. Prin urmare, noile entităţi pot fi translate în
structuri fizice din care se poate extrage un volum mare de date printr-un singur acces.
Este posibilă de asemenea şi partiţionarea orizontală, în care divizarea se face în raport cu
apariţiile entităţii. De exemplu, pot exista operaţii asociate analiştilor şi operaţii asociate angajaţilor
din departamentul vânzări. În acest caz se dovedeşte utilă partiţionarea entităţii ANGAJAT în două
entităţi distincte, ANALIST şi VÂNZARE, având aceleaşi atribute ca entitatea originală. Partiţionarea
orizontală are ca efect secundar introducerea de duplicate pentru relaţiile în care participă entitatea
originală. Acest fenomen poate avea un impact negativ asupra performanţelor bazei de date.

Ştergerea atributelor multi-valoare

Acest tip de restructurare este necesar deoarece modelul relaţional nu permite reprezentarea
directă a atributelor multi-valoare. Un exemplu este prezentat în figura 10.

Figura 10. Exemplu de ştergere a atributelor multi-valoare

Entitatea AGENTIE este separată în două entităţi: una având acelaşi nume şi aceleaşi atribute
cu entitatea originală, în afară de atributul multi-valoare (Telefon) şi o entitate TELEFON cu
atributul Numar. Entităţile sunt legate de o relaţie 1:N. Evident, dacă atributul este opţional, atunci
cardinalitatea minimă pentru entitatea TELEFON trebuie să fie 0.

Combinarea entităţilor

Combinarea entităţilor este operaţia inversă partiţionării. Un exemplu de combinare a

entităţilor este ilustrat în figura 11. Entităţile PERSOANA şi APARTAMENT aflate în relaţia
PROPRIETAR sunt combinate într-o singură entitate ce deţine atributele ambelor entităţi. Această
restructurare poate fi sugerată de faptul că majoritatea operaţiilor frecvente asupra entităţii
PERSOANA necesită informaţii în legătură cu apartamentul deţinut de persoana respectivă. Prin
urmare se doreşte evitarea accesărilor necesare extragerii datelor prin intermediul relaţiei
PROPRIETAR.
Dezavantajul acestei restructurări constă în posibilitatea apariţiei valorilor NULL în noua
entitate PERSOANA deoarece cardinalitatea entităţii originale PERSOANA indică faptul că există
persoane ce nu deţin un apartament.
 Figura 11. Exemplu de combinare a entităţilor

Operaţia de combinare se efectuează în general asupra relaţiilor 1:1 şi mai rar asupra
relaţiilor 1:N sau N:N. Motivul constă în apariţia redundanţelor în atributele non-cheie ale entităţii
având cardinalitatea N.

Alte tipuri de partiţionare şi combinare

Operaţiile de partiţionare şi combinare pot fi aplicate şi relaţiilor din următoarele motive:

• pentru a separa apariţiile unei relaţii ce sunt întotdeauna accesate separat;
• pentru a uni două (sau mai multe) relaţii între aceleaşi entităţi într-o singură relaţie,
atunci când apariţiile lor sunt accesate întotdeauna împreună.
Un exemplu de partiţionare a unei relaţii este prezentat în figura 12, în care se face distincţie
între jucătorii prezenţi ai unei echipe de fotbal şi cei din trecut.

Figura 12. Exemplu de partiţionare a unei relaţii

Selecţia identificatorilor primari

În cazul în care există entităţi ce deţin mai mulţi identificatori apare necesitatea stabilirii
acelor atribute ce formează identificatorul primar. Identificatorul primar va avea drept corespondent
în modelul relaţional o cheie primară.
Criteriile de alegere a unui identificator primar sunt:
• Atributele ce pot deţine valori NULL nu pot forma un identificator primar.
• Este indicat ca un identificator primar să conţină un atribut sau cât mai puţine atribute.
Avantajele acestei alegeri ar fi:
- indecşi de dimensiune redusă (un index este o structură auxiliară pentru acces
rapid la date);
- spaţiu redus pentru crearea legăturilor logice între relaţii;
- sunt facilitate operaţiile de joncţiune.
• Un identificator intern este de preferat unuia extern, care poate implica mai multe entităţi
şi aceasta din cauză că identificatorii externi sunt translaţi în chei ce conţin identificatorii
tuturor entităţilor implicate în identificatorul extern.
• Este de preferat un identificator ce este utilizat de majoritatea operaţiilor pentru a accesa
apariţiile entităţii. În acest fel operaţiile vor fi executate eficient, fiind avantajate de
indecşii construiţi automat de sistemul de gestiune a bazei de date.

Dacă în această etapă nu există nici un identificator care să satisfacă criteriile anterioare, se
va introduce un atribut suplimentar în entitate, atribut ce va fi utilizat exclusiv pentru identificarea
apariţiilor entităţii.

8.3 Translarea în modelul relaţional

Translarea în modelul relaţional este a doua etapă a proiectării logice. Plecând de la o

schemă E-R se construieşte schema relaţională echivalentă (echivalentă din punct de vedere al
capacităţii de a reprezenta informaţii echivalente). Ţinând cont de faza de restructurare a schemei E-
R, translarea va pleca de la o schemă E-R simplificată, ce nu conţine generalizări sau atribute multi-
valoare şi are numai identificatori primari.

Entităţi şi relaţii N:N

Se consideră schema din figura 13.

Figura 13. Schemă E-R cu o relaţie N:N

Translarea în modelul relaţional se face urmând paşii:

• Fiecare entitate va fi translată într-o relaţie M-R(a modelului relaţional) cu acelaşi nume
şi având aceleaşi atribute ca şi entitatea; cheia fiecărei relaţii este dată de identificatorul
entităţii corespunzătoare.
 • Fiecare relaţie E-R dintre entităţi va avea drept corespondent o relaţie M-R cu acelaşi
nume şi cu atribute atributele relaţiei E-R şi identificatorii entităţilor implicate; cheia
relaţiei M-R va conţine identificatorii entităţilor.
Dacă entităţile sau relaţiile E-R au atribute opţionale, atributele corespunzătoare din modelul
relaţional pot avea valoarea NULL.
Se obţine referitor la exemplul din figura 13:
ANGAJAT(Numar, Nume, Salariu)
PROIECT( Cod, Nume, Buget)
PARTICIPARE(Numar, Cod, DataStart)
În cazul în care se doreşte mărirea clarităţii schemei obţinute se pot opera redenumiri de
atribute:
PARTICIPARE(Angajat, Proiect, DataStart)
Domeniul atributului Angajat este o mulţime de numere de înregistrare pentru angajaţi, iar
domeniul pentru atributul Proiect este o mulţime de coduri de proiecte. De asemenea trebuie
impuse constrângeri de referinţă între aceste atribute şi relaţiile ANGAJAT, respectiv PROIECT.
Operaţia de redenumire este esenţială în cazul relaţiilor recursive. Să considerăm schema din
figura 14.

Figura 14. Schemă E-R cu relaţie recursivă

Prin translare se obţine:

PRODUS(Cod, Nume, Pret)
COMPUNERE(Componenta, Subcomponenta, Cantitate)
Atributele Componenta şi Subcomponenta au ca domeniu mulţimea de coduri ale produselor.
Trebuie impuse constrângeri de referinţă între Componenta şi PRODUS şi Subcomponentă şi
PRODUS.
Translarea relaţiilor E-R ce implică mai mult de două entităţi este similară cazului relaţiilor
E-R între două entităţi (relaţii binare). Ca exemplu este dată schema din figura 15. Schema este
translată în:
FURNIZOR(IDFurnizor, NumeFurnizor)
PRODUS(Cod, Tip)
DEPARTAMENT(Nume, Telefon)
LIVRARE(Furnizor, Produs, Departament, Cantitate)
 Figura 15. Schemă E-R cu o relaţie ternară

Se impun constrângeri de referinţă între atributele Furnizor, Produs şi Departament

ale relaţiei M-R LIVRARE şi relaţiile M-R FURNIZOR, PRODUS şi DEPARTAMENT.
Pentru acest ultim tip de translare trebuie verificat dacă identificatorii entităţilor, luaţi
împreună, nu formează o cheie, sau mai degrabă o super-cheie redundantă pentru relaţia M-R care
reprezintă relaţia E-R din schemă. Aceasta se poate întâmpla, spre exemplu, dacă există un singur
furnizor care livrează un produs dat unui departament dat. Este de notat faptul că rămâne validă
cardinalitatea deoarece acest furnizor poate livra mai multe produse acestui departament sau altor
departamente. În acest caz, cheia relaţiei M-R LIVRARE trebuie să fie formată doar din atributele
Produs şi Departament, deoarece, fiind dat un produs şi un departament, furnizorul este
determinat în mod unic.

Relaţii 1:N

Se consideră schema din figura 16.

Figura 16. Schemă E-R cu o relaţie 1:N

Utilizând regula de translare a relaţiilor N:N se obţine:

JUCATOR(Nume, DataNastere, Pozitie)
ECHIPA(Nume, Oras, CuloriEchipa)
CONTRACT(NumeJucator, DataNastereJucator, Echipa, Salariu)
Cheia relaţiei CONTRACT este formată numai din identificatorul entităţii JUCATOR
deoarece cardinalităţile indică faptul că fiecare jucător are contract la o singură echipă.
Se observă că relaţiile JUCATOR şi CONTRACT au aceeaşi cheie. Acest lucru indică
posibilitatea combinării celor două relaţii în una singură, fără să existe pericolul introducerii de
redundanţe. Această combinare este posibilă datorită corespondenţei 1:1 între instanţele celor două
relaţii. Astfel, pentru schema din figura 16 se preferă translarea:
JUCATOR(Nume, DataNastere, Pozitie, Echipa, Salariu)
ECHIPA(Nume, Oras, CuloriEchipa)
 Trebuie impusă o constrângere de referinţă între atributul Echipa şi relaţia ECHIPA.
Să considerăm cazul în care entitatea JUCATOR participă opţional la relaţia CONTRACT
(pot exista jucători care nu au contract cu nici o echipă). Ambele translări prezentate anterior sunt
valide. Ce-a de-a doua prezintă dezavantajul că pot exista valori NULL în relaţia JUCATOR pentru
atributele Echipa şi Salariu.
Regulă: entitatea ce participă la o relaţie E-R cu cardinalitatea maximă 1 este translată într-o
relaţie M-R ce include identificatorii celorlalte entităţi implicate în relaţia E-R şi posibilele atribute
ale relaţiei E-R. Astfel nu mai este nevoie de o relaţie M-R separată pentru relaţia din schema E-R.
Ca exemplu, să presupunem că entitatea PRODUS participă în relaţia din figura 15 cu
cardinalităţile minimă şi maximă 1. Aceasta înseamnă că pentru fiecare produs există un singur
furnizor care livrează produsul respectiv şi un singur departament deservit. Schema este translatată
sub forma:
FURNIZOR(IDFurnizor, NumeFurnizor)
DEPARTAMENT(Nume, Telefon)
PRODUS(Cod, Tip, Furnizor, Departament, Cantitate)
Se impun constrângeri de referinţă între atributul Furnizor al relaţie PRODUS şi relaţia
FURNIZOR şi între atributul Departament al relaţiei PRODUS şi relaţia DEPARTAMENT.

Entităţi cu identificatori externi

Să considerăm exemplul din figura 17.

Figura 17. Schemă E-R cu identificator extern

Schema relaţională este:

STUDENT(NrInregistrare, Universitate, Nume, AnInregistrare)
UNIVERSITATE(Nume, Oras, Adresa)
Există o constrângere de referinţă între atributul Universitate şi relaţia
UNIVERSITATE.
Este de notat faptul că, prin reprezentarea identificatorului extern, a fost reprezentată şi
relaţia dintre entităţi.
Acest tip de translare este valid indiferent de cardinalitatea cu care participă celelalte entităţi
la relaţie.

Relaţii 1:1

Pentru relaţiile 1:1 există mai multe posibilităţi de translare. Să considerăm relaţia din figura
18, cu participare obligatorie din partea celor două entităţi implicate.
 Figura 18. Schemă E-R cu o relaţie 1:1

Există două posibilităţi valide de translare:

SEF(Numar, Nume, Salariu, Departament, DataStart)

DEPARTAMENT(Nume, Telefon, Filiala)

cu constrângere de referinţă între atributul Departament al relaţiei SEF şi relaţia

DEPARTAMENT, sau

SEF(Numar, Nume, Salariu)

DEPARTAMENT(Nume, Telefon, Filiala, Sef, DataStart)

cu constrângere de referinţă între atributul Sef al relaţiei DEPARTAMENT şi relaţia SEF.

Pe lângă aceste două soluţii, există posibilitatea obţinerii unei singure relaţii, incluzând toate
atributele din schema E-R. Motivul pentru care această soluţie va fi eliminată este următorul: dacă
după faza de restructurare (care precede faza de translare) schema E-R conţine două entităţi legate
printr-o relaţie 1.1, este de dorit ca în faza de translare cele două concepte să rămână separate.

Să considerăm cazul unei relaţii 1:1 cu participarea opţională a uneia dintre entităţi, ca în
schema din figura 19.

Figura 19. Schema E-R cu o relaţie 1:1 cu participare opţională

Soluţia adoptată este:

ANGAJAT(Numar, Nume, Salariu)

DEPARTAMENT(Nume, Telefon, Filiala, Sef, DataStart)

cu constrângere de referinţă între atributul Sef al relaţiei DEPARTAMENT şi relaţia ANGAJAT.

Această opţiune este preferabilă uneia în care relaţia E-R este reprezentată în relaţia M-R
ANGAJAT prin numele departamentului manageriat, deoarece, pentru acest atribut, ar putea exista
valori NULL.
 Să considerăm cazul în care ambele entităţi au participări opţionale. Să presupunem că în
schema din figura 19 pot exista departamente fără şef (cardinalitatea minimă a entităţii
DEPARTAMENT este 0). În acest caz se obţine prin translare:
ANGAJAT(Numar, Nume, Salariu)
DEPARTAMENT(Nume, Telefon, Filiala)
MANAGEMENT(Sef, Departament, DataStart)

Se observă că se poate lua drept cheie a relaţiei MANAGEMENT atributul Departament. Se

impun constrângeri de referinţă între atributele Sef şi Departament ale relaţiei MANAGEMENT şi
relaţiile ANGAJAT şi DEPARTAMENT.
Această soluţie are avantajul că atributele ce implementează relaţia din schema E-R nu pot
avea valori NULL. Dezavantajul soluţiei constă în relaţia nouă introdusă. Această soluţie este
recomandată în cazul în care numărul de apariţii ale relaţiei este mic în comparaţie cu numărul de
apariţii ale entităţilor implicate în relaţie.

Exemplu de translare a unei scheme complexe cu obţinerea unui număr minim de relaţii

Să considerăm schema E-R din figura 20.

Figura 20. Schemă entitate relaţie

Într-o primă fază se translează fiecare entitate într-o relaţie din modelul relaţional. Translarea
entităţilor cu identificatori interni este imediată:
E3(A31, A32)
E4(A41, A42)
E5(A51, A52)
E6(A61, A62, A63)
 Al doilea pas constă în translarea entităţilor cu identificatori externi. Se obţin următoarele
relaţii M-R:
E1(A11, A51, A12)
E2(A21, A11, A51, A22)
Este de notat modul în care E2 preia atributul A11 din E1 şi tranzitiv, atributul A51 din E5
care, împreună, identifică E1. Trebuie impuse constrângeri de referinţă adecvate (de exemplu între
atributul A51 din E1 şi relaţia E5).
În al treilea pas se translează relaţiile din schema E-R. Relaţiile R1 şi R6 au fost deja
translate datorită identificatorilor externi ai entităţilor E1, respectiv E2. Presupunem că vrem să
obţinem un număr minim de relaţii M-R în schema finală. Astfel:
• Pentru a transla R3, vom introduce, cu redenumiri adecvate, atributele care identifică E6
printre cele ale lui E5, precum şi atributul AR3 al lui R3. Astfel introducem A61R3,
A62R3 şi AR3 în E5.
• Similar, pentru R4, introducem A61R4 şi A62R4 în E5.
• Similar, pentru R5, introducem A61R5, A62R5 şi AR5 în E5.
Se obţine
E5(A51, A52, A61R3, A62R3, AR3, A61R4, A62R4, A61R5, A62R5, AR5)
Cheia relaţiei M-R E5 este formată doar din A51 deoarece entitatea E5 participă cu
cardinalitatea maximă 1 la relaţiile E-R R3, R4 şi R5.
Redenumirea atributelor entităţii E6 este obligatorie pentru a face distincţia între utilizări ale
aceloraşi atribute în reprezentarea unor relaţii diferite (spre exemplu A61R3 care reprezintă R3 şi
A61R4 care reprezintă R4).
În final se translează singura relaţie N:N, şi anume R2:
R2(A21, A11, A51, A31, A41, AR21, AR22)
Schema relaţională care se obţine în final este:

E1(A11, A51, A12)

E2(A21, A11, A51, A22)
E3(A31, A32)
E4(A41, A42)
E5(A51, A52, A61R3, A62R3, AR3, A61R4, A62R4, A61R5, A62R5, AR5)
E6(A61, A62, A63)
R2(A21, A11, A51, A31, A41, AR21, AR22)

Tabel rezumat pentru translarea din modelul entitate-relaţie în modelul relaţional

În figura 21 sunt prezentate, pe scurt, posibilităţi de translare din modelul E-R în modelul
relaţional
Simbolurile X şi Y indică o cardinalitate permisă. Asteriscul indică posibilitatea prezenţei
valorilor NULL iar linia de subliniere întreruptă marchează o cheie alternativă celei marcate prin
linie continuă.
 Tip Schema iniţială Translare posibilă

Relaţie binară
N:N

Relaţie ternară
N:N

Relaţie 1:N cu
participare
obligatorie

Relaţie 1:N cu
participare
opţională
sau

Relaţie cu
identificatori
externi

Relaţie 1:1 cu
participare
obligatorie
pentru ambele sau
entităţi

Relaţie 1:1 cu
participare
opţională pentru
o entitate

Relaţie 1:1 cu
sau
participare
opţională pentru
ambele entităţi

sau
Figura 21. Translări din modelul E-R în modelul relaţional
 Documentarea schemelor logice

Rezultatul proiectării logice nu constă doar în schema bazei de date ci presupune şi o

documentaţie asociată. O parte a documentaţiei obţinute în faza proiectării conceptuale poate fi
„moştenită” de schema logică. În particular, dacă numele conceptelor din schema E-R sunt refolosite
pentru construirea schemei relaţionale, regulile de operare definite anterior pot fi folosite pentru
documentarea acesteia din urmă. Documentaţia schemei relaţionale trebuie completată cu
constrângerile de referinţă.
Pentru aceasta se adoptă o notaţie grafică simplă atât pentru relaţii cât şi pentru
constrângerile dintre acestea. Un exemplu referitor la schema din figura 13 este dat în figura 22.
Cheile relaţiilor se scriu îngroşat, săgeţile descriu constrângerile de referinţă iar asteriscul asociat
indică posibilitatea ca atributul respectiv să aibă valori NULL.

Figura 22. Reprezentarea grafică a translării schemei din figura 13.

În acest mod se pot păstra informaţii despre relaţiile din modelul E-R, permiţându-se
reconstrucţia informaţiilor reprezentate prin relaţia originală. În exemplul din figura 22, proiectele în
care angajaţii sunt implicaţi pot fi regăsite prin intermediul relaţiei PARTICIPARE.
În figura 23 este prezentat un alt exemplu referitor la schema din figura 16.

Figura 23. Reprezentarea grafică a translării schemei din figura 16.

Este de remarcat faptul că această metodă permite de asemenea reprezentarea explicită a

relaţiilor din schema iniţială E-R cărora, în schema relaţională echivalentă, nu le corespunde nici o
relaţie (spre exemplu relaţia CONTRACT din modelul E-R din figura 16).
În figura 24 este reprezentată schema relaţională corespunzătoare exemplului anterior de
translare a unei scheme complexe cu obţinerea unui număr minim de relaţii (figura 20). În acest mod
se pot identifica uşor legăturile logice dintre diferitele relaţii care apar.
 Figura 24. Reprezentarea grafică a schemei relaţionale
corespunzătoare schemei E-R din figura 20

8.4 Exemplu de proiectare logică

Să considerăm exemplul din capitolul anterior (proiectarea conceptuală) referitor la o

companie de instruire. Schema conceptuală este prezentată în figura 25.

Figura 25. Schema E-R pentru o companie de instruire

Operaţiile care au loc asupra datelor descrise prin schema anterioară sunt:
• Operaţia 1: se inserează un nou instruit incluzând datele despre el;
• Operaţia 2: se atribuie un instruit unei ediţii a unui curs;
• Operaţia 3: se inserează un nou instructor, incluzând toate datele şi cursurile pe care
acesta este calificat să le predea;
• Operaţia 4: se atribuie un instructor calificat pentru o ediţie a unui curs;
• Operaţia 5. se afişează toate informaţiile despre o ediţie anterioară a cursului: titlu, orar,
număr de instruiţi;
• Operaţia 6: afişează toate cursurile disponibile, cu informaţii despre instructorii
calificaţi să le ţină;
• Operaţia 7: pentru fiecare instructor, se găsesc instruiţii pentru toate cursurile pe care le
ţine sau le-a ţinut;
• Operaţia 8: se realizează o analiză statistică a tuturor instruiţilor cu toate informaţiile
despre ei, despre ediţiile cursurilor pe care le-au urmat şi notele obţinute.

Faza de restructurare

Încărcarea bazei de date este prezentată în figura 26.

Tabelul volumelor
Concept Tip Volum
Clasă E 8000 Tabelul operaţiilor
EdiţieCurs E 1000 Operaţie Tip Frecvenţă
Curs E 200 Op 1 I 40/zi
Instructor E 300 Op 2 I 50/zi
Temporar E 250 Op 3 I 2/zi
Permanent E 50 Op 4 I 15/zi
Instruit E 5000 Op 5 I 10/zi
Angajat E 4000 Op 6 I 20/zi
LiberProfesionist E 1000 Op 7 I 5/zi
Angajator E 8000 Op 8 B 10/lună
PrezenţăAnterioară R 10000
PrezenţăCurentă R 500
Compoziţie R 8000
Tip R 1000
PredareAnterioară R 900
PredareCurentă R 100
Calificare R 500
AngajareActuală R 4000
AngajareAnterioară R 10000
Figura 26. Tabelele volumelor şi operaţiilor pentru schema din figura 25
 Analiza redundanţelor. În schemă există doar o dată redundantă şi anume atributul
NrParticipanţi în EDIŢIECURS, care poate fi derivat din relaţiile PREZENŢĂCURENTĂ şi
PREZENŢĂANTERIOARĂ. Cererea de stocare este de 4 x 1000 = 4000 octeţi, presupunând că sunt
necesari patru octeţi pentru ca fiecare apariţie a entităţii EDIŢIECURS să stocheze numărul de
participanţi. Operaţiile care implică această informaţie sunt 2, 5 şi 8. Ultima operaţie poate fi lăsată
deoparte deoarece este o operaţie cu o frecvenţă mică, care se execută în modul batch. Vom evalua
costul operaţiilor 2 şi 5 în prezenţa şi în absenţa redundanţei. Se poate deduce din tabelul volumelor
că fiecare ediţie a unui curs are, în medie, 8 clase şi 10 participanţi. Pornind de la aceste date se
poate obţine uşor tabelul accesărilor prezentat în figura 27.

Accesări în prezenţa redundanţei Accesări în absenţa redundanţei

Operaţia 2 Operaţia 2
Concept Tip Accesări Tip Concept Tip Accesări Tip
Instruit E 1 R Instruit E 1 R
PrezenţăCurentă R 1 W PrezenţăCurentă R 1 W
EdiţieCurs E 1 R
EdiţieCurs E 1 W
Operaţia 5
Operaţia 5 Concept Tip Accesări Tip
Concept Tip Accesări Tip EdiţieCurs E 1 R
EdiţieCurs E 1 R Tip R 1 R
Tip R 1 R Curs E 1 R
Curs E 1 R Compoziţie R 8 R
Compoziţie R 8 R Clasă E 8 R
Clasă E 8 R PrezenţăAnterioară R 10 R
Figura 27. Tabelele accesărilor pentru schema din figura 25

Se obţine:
• În prezenţa redundanţei: pentru operaţia 2 avem 2 x 50 = 100 accesări în citire / zi şi tot
atâtea accesări în scriere / zi, în timp ce, pentru operaţia 5, avem 19 x 10 = 190 accesări
în citire / zi dintr-un total de 490 accesări / zi (s-a considerat că accesul în scriere costă
de două ori mai mult decât accesul în citire);
• În absenţa redundanţei: pentru operaţia 2 avem 50 de accesări în citire / zi şi tot atâtea în
scriere, în timp ce pentru operaţia 5 avem 29 x 10 = 290 accesări în citire / zi, dintr-un
total de 440 accesări / zi (s-a considerat că accesul în scriere costă de două ori mai mult
decât accesul în citire).

Se observă că în prezenţa redundanţei, apar dezavantaje atât în ceea ce priveşte cererea de

stocare cât şi timpul de acces. Din acest motiv se va renunţa la atributul NrParticipanţi al
entităţii EDIŢIECURS.

Eliminarea generalizărilor. În schemă există două generalizări: una referitoare la instructori

şi una referitoare la instruiţi.
În ceea ce priveşte instructorii, să remarcăm că operaţiile relevante (3,4,6 şi 7) nu fac
distincţia între instructorii temporari şi cei angajaţi permanent de companie. Mai mult, entităţile
corespunzătoare nu au atribute specifice acestora. Din aceste motive, vom şterge entităţile copil ale
generalizării şi vom adăuga atributul Tip entităţii INSTRUCTOR. Acest atribut are domeniul format
din simbolurile T (pentru temporar) şi P (pentru permanent).
 În ceea ce priveşte instruiţii, să observăm că şi în acest caz, operaţiile relevante (1, 2 şi 8) nu
fac o diferenţa majoră între diversele tipuri de apariţii. Entităţile copil au ambele atribute specifice.
Se pot lăsa entităţile ANGAJAT şi LIBERPROFESIONIST adăugând două relaţii 1:1 între aceste entităţi
şi entitatea INSTRUIT. În acest fel se evită atribute cu posibile valori NULL pentru entitatea părinte
şi se poate reduce dimensiunea relaţiilor.
Rezultatul eliminării generalizărilor se poate vedea în figura 28.

Partiţionarea / combinarea conceptelor. Din analiza datelor şi operaţiilor se pot identifica

mai multe restructurări potenţiale. Prima se referă la entitatea EDIŢIECURS. Operaţia 5 şi relaţiile
PREDAREANTERIOARĂ şi PREZENŢĂANTERIOARĂ se referă doar la ediţiile anterioare ale cursului.
Astfel, pentru a face operaţia anterioară mai eficientă, se poate descompune entitatea orizontal
pentru a distinge între ediţiile curente şi cele anterioare ale cursului. Dezavantajul acestei alegeri
este acela că relaţiile COMPOZIŢIE şi TIP se vor duplica. Pe de altă parte, operaţiile 7 şi 8 nu fac o
distincţie majoră între ediţiile curente şi anterioare ale unui curs şi ar putea fi mai costisitoare dacă
necesită vizitarea a două entităţi distincte. Din aceste motive, nu vom partiţiona entitatea
EDIŢIECURS.
Două restructurări posibile ar putea avea loc prin combinarea relaţiilor
PREDAREANTERIOARĂ ŞI PREDARECURENTĂ şi respectiv a relaţiilor PREZENŢĂANTERIOARĂ ŞI
PREZENŢĂCURENTĂ. În ambele cazuri avem de-a face cu două concepte similare între care câteva
operaţii (7 şi 8) nu fac diferenţa. Combinarea acestor relaţii mai poate duce la un avantaj şi anume
că nu mai este necesar transferul apariţiilor de la o relaţie la alta la sfârşitul unei ediţii a unui curs.
Un dezavantaj ar fi acela că atributul Notă, care nu apare la o ediţie curentă a cursului va avea
valori NULL. Din tabelul de volume se observă că numărul de apariţii ale relaţiei
PREZENŢĂCURENTĂ este de 500. Presupunând că avem nevoie de 4 octeţi pentru a stoca notele,
cererea de stocare va fi de doar aproximativ 2 Kocteţi. Decidem deci să combinăm cele două
perechi de relaţii după cum se poate vedea în figura 28. Trebuie adăugată o constrângere care nu
poate fi reprezentată direct pe schemă şi anume aceea ca un instructor să nu poată preda mai mult de
o ediţie a unui curs în aceeaşi perioadă. Similar, un participant nu poate fi prezent la mai mult de o
ediţie a unui curs la un anumit moment.
În final, este necesară eliminarea atributului multi-valoare Telefon din entitatea
INSTRUCTOR. Pentru aceasta se introduce o nouă entitate TELEFON legată printr-o relaţie 1:N de
entitatea INSTRUCTOR (din care se elimină atributul respectiv).

Selecţia identificatorilor primari. Doar entitatea INSTRUIT are doi identificatori: CNP-ul şi
codul intern. Este preferabil să se aleagă al doilea identificator deoarece CNP-ul poate necesita
câţiva octeţi pentru stocare în timp ce codul, care trebuie să distingă între 5000 de apariţii (vezi
tabelul volumelor) nu necesită mai mult de doi octeţi.
Entitatea EDIŢIECURS este identificată prin atributul DatăStart şi prin entitatea CURS.
Într-o reprezentare relaţională, acest identificator trebuie utilizat pentru a implementa două relaţii
(PREZENŢĂ şi PREDARE). Se poate observa că fiecare curs are un cod şi că numărul mediu de ediţii
pentru un curs este 5. Aceasta înseamnă că este convenabil să adăugăm un atribut Cod cu domeniul
small integer pentru a identifica o ediţie a unui curs, în locul identificatorului extern.

Schema rezultată în urma restructurării poate fi observată în figura 28.

 Figura 28. Schema E-R din figura 25 după faza de restructurare

Translarea în modelul relaţional

Folosind tehnicile de translare prezentate anterior, schema din figura 28 poate fi translată în
următoarea schemă relaţională:

EDIŢIECURS(Cod, DatăStart, DatăSfârşit, Curs, Instructor)

CLASĂ(Timp, Sală, Dată, Ediţie)
INSTRUCTOR(CNP, Nume, Vârstă, OraşDeNaştere, Tip)
TELEFON(Număr, Instructor)
CURS(Cod, Nume)
CALIFICARE(Curs, Instructor)
INSTRUIT(Cod, CNP, Nume, Vârstă, OraşDeNaştere, Sex)
PREZENŢĂ(Instruit, Ediţie, Note*)
ANGAJATOR(Nume, Adresă, Telefon)
ANGAJAREANTERIOARĂ(Instruit, Angajator, DatăStart, DatăSfârşit)
LIBERPROFESIONIST(Instruit, Expertiză, TitluProfesional*)
ANGAJAT(Instruit, Nivel, Poziţie, Angajator, DatăStart)

Schema logică va fi completată cu o documentaţie care va descrie, printre altele, toate

constrângerile de referinţă care există între relaţii. Aceasta se poate face utilizând notaţiile grafice
prezentate anterior.