Proiectarea logică a bazei de

date
Întrebări:
• Etapele proiectării logice a BD
• Reprezentarea entităților în dreptunghi în diagrame E-R
• Tipuri de relații în diagrame E-R
• Capcane de conectare a entităților în diagrame E-R
• Modelarea datelor istorice
• Modelarea generică
• Transformarea diagramei E-R în model relațional de baza de
date
ETAPELE PROIECTĂRII LOGICE A BD
 Etapele proiectării logice a bazei de date
• Pasul 1. Identificarea tipurilor de entități
• Pasul 2. Identificarea tipurilor de relații
• Pasul 3. Identificarea si atribuirea de atribute la tipurile de
entități si tipurile de relații
• Pasul 4. Determinarea domeniilor de definiție a atributelor
• Pasul 5. Determinarea atributelor care compun cheile
candidate si primare
• Pasul 6. Specializare/generalizare (pas opțional)
• Pasul 7. Desenarea diagramei E-R
• Pasul 8. Verificarea modelului conceptual local cu ajutorul
utilizatorului
REPREZENTAREA ENTITĂȚILOR ÎN
DREPTUNGHI ÎN DIAGRAME E-R
 Reprezentarea în dreptunghi a entităților
Dacă se foloseste un număr mare de atribute, reprezentarea grafică a
diagramelor E-R este greoaie și dificil de urmărit. De a ceea, se preferă
convenția de reprezentare „în dreptunghi” , în care atributele unei entitați sunt
înscrise toate în dreptunghiul asociat acesteia și se au în vedere următoarele
reguli:
• O entitate se reprezinta printr-un dreptunghi (softbox), în care se scrie
numele entitatii. Numele entității este întotdeauna un substantiv la singular
și se scrie în partea de sus a dreptunghiului cu majuscule.
• O entitate este o clasa de obiecte si pentru orice entitate exista mai multe
instanțe ale sale. O instanța a unei entități este un obiect, persoană,
eveniment, particular din clasa de obiecte care formează entitatea.
• Atributele entității se scriu unul sub celalalt în același dreptunghi, sub
numele entității, cu litere mici.
• Cheia primara se scrie prima în lista de atribute și se marchează cu un „
diez” (#).
• Un atribut obligatoriu se marchează cu un „asterisc” ( *).
• Un atribut cu valoare opționala se marchează cu un „ cerculeț” (o).
Reprezentarea în dreptunghi a entităților
 Tipuri si subtipuri de entități
• În lumea reală obiectele sunt deobicei clasificate.
• Un subtip sau o subentitate este o clasificare a unei entitati
care are caracteristici comune cu entitatea generala,
precum atribute și relații. Subtipurile se reprezintă în cadrul
hărții relațiilor ca entități în interiorul altei entități . Atributele
și relațiile comune tuturor subtipurilor se vor reprezenta la
nivelul supertipului, sau superentității. Atributele și
relațiile supertipului vor fi moștenite de către subtipuri.
• Un subtip poate avea la rândul sau alte subtipuri incluse.
Tipuri si subtipuri de entități
 Tipuri si subtipuri de entități

• Subtipurile trebuie sa respecte doua reguli importante:

- trebuie sa acopere toate cazurile posibile de instante ale
supertipului, cu alte cuvinte, orice instanta a supertipului trebuie
să apartină unui subtip. De multe ori ERD-urile includ un subtip
"ALTUL" pentru a acoperi toate situatiile, si pentru a permite
viitoare dezvoltări ale modelului.
- subtipurile trebuie să se excludă reciproc. Aceasta regula se
traduce pe exemplul de mai sus în faptul ca un angajat nu poate
fi, de exemplu, și manager și secretara în același timp.
TIPURI DE RELAȚII ÎN DIAGRAME E-R
 Reprezentarea relațiilor
• Relația dintre doua entități se reprezintă printr-o linie, etichetată cu numele
relației.
• Linia de legatura dintre entitati este continuă dacă participarea entității la
relație este totală sau obligatorie.
• Linia de legatură dintre entități este întreruptă la capatul la care participarea
entității este opțională.
• Relatia se reprezinta cu un capat ramificat, în trei („talpa gâstei”), dacă o
entitate are o participare multiplă la acea relație.
 Reprezentarea relațiilor
• Linia de la JUCATOR la ECHIPA se termină în partea dinspre ECHIPA cu
o linie simplă, deci un jucător joaca la o echipa si numai una.
• Linia de la ECHIPA la JUCATOR se termină cu piciorul de cioara,
înseamnă ca unei instanțe a entității ECHIPA îi corespund mai multe
instanțe ale entității JUCATOR, adică o echipă are unul sau mai mulți
jucători.
 Tipuri de relații
• relații one-to-one – acest tip de relație este destul de rar întâlnit. Uneori
astfel de relații pot fi modelate transformând una dintre entitati în atribut al
celeilalte entități.
 Tipuri de relații
• relații one-to-many – sunt cele mai întâlnite tipuri de relații.
• relatii many-to-many – aceste tipuri de relatii apar în prima faza a
proiectării bazei de date, însa ele trebuie sa fie ulterior eliminate.
 Transferabilitatea relațiilor
• Spunem ca o relatie este nontransferabila daca o asociație între doua
instanțe ale celor doua entității, odată stabilita, nu mai poate fi modificata.
Nontransferabilitatea unei relatii se reduce la faptul ca valorile cheii straine
corespunzătoare relației respective nu pot fi modificate.
• Condiția de nontransferabilitate a unei relații este asigurată prin program.
De aceea trebuie sa documentam aceasta restricție. În ERD o relație
nontransferabilă se notează cu un romb pe linia corespunzatoare relatiei,
înspre entitatea a carei cheie straina nu este permis sa o modificăm (adică
în partea cu many a unei relații one-to-many).

Este normal ca o notă dată unui elev să nu poată fi apoi transferată unui alt elev.
 Relații exclusive
• În unele situații, relațiile se pot exclude reciproc, adică dintr-
un grup de relații, la un moment dat doar una dintre ele poate
avea loc. De exemplu, un cont anume la o bancă este deținut
fie de o persoana fizică, fie de o firmă, dar nu de ambele tipuri
de clienți simultan.
• Un grup de relații exclusive este reprezentat în harta relațiilor
printr-un arc peste relațiile care fac parte din respectivul grup.
Toate relațiile ce fac parte din grupul de relații exclusive
trebuie sa aibă aceeași opționalitate. Un arc apartine unei
singure entitati, adica va include doar relatii care pleaca de la o
aceeasi entitate.
• O entitate poate avea mai multe arce, dar o anumita relație nu
poate face parte decât dintr-un singur arc.
 Relații exclusive

Relații exclusive obligatorii Relații exclusive opționale

 Relații exclusive

• Exista doua tipuri de relații exclusive:

- relații exclusive obligatorii în care toate relațiile ce fac parte
din arcul respectiv sunt obligatorii, ceea ce înseamnă ca de
fiecare data, una dintre relatii are obligatoriu loc.
- relații exclusive opționale caz în care toate relațiile ce fac
parte din arc sunt opționale. În acest caz de fiecare data are loc
cel mult una dintre relații, existând varianta că pentru o instanță a
entității căreia aparține arcul sa nu aibă loc nici una din relațiile
din grupul respectiv.
 Relații ierarhice
• Sa analizam care este structura personalului într-o firmă
oarecare.
 Relații ierarhice
• Implementarea unei structuri ierarhice
 Relații ierarhice
• Un alt bun exemplu, este acela al localizării camerelor din căminele dintr-
un campus studențesc, prin numărul de cămin, prin etaj si numărul
camerei. Aceasta este o ierarhie pe trei nivele
• Se observa ca identificarea unei camere din campus, nu se face doar prin nu
marul camerei, ci prin toate cele trei chei primare: numar_camin,
numar_etaj, numar_camera, ceea ce se reprezinta prin relatii barate între
entitatile din ierarhie.
 Relații recursive
• Problema este ca fiecare tip de angajat din figura anterioara este de
fapt un angajat și probabil există foarte multe atribute comune
tuturor acestor entități ca de exemplu nume, prenume, adresa,
telefon, email, data nașterii etc. Vom putea de aceea modela această
structură cu ajutorul unei singure entitati numită ANGAJAT.
• Însă fiecare angajat poate fi condus de către un alt angajat.
Așadar, vom avea o relație de la entitatea ANGAJAT la ea însasi.
O astfel de relatie se numeste relatie recursiva.
 Relații redundante

• Atunci când o relație poate fi dedusa din alte relații spunem ca

acea relație este redundantă . Se observa că un elev face
parte dintr-o clasă, iar la aceea clasa predau mai multi
profesori. Asadar, relatia Profesor și Elev nu mai est e necesara
deoarece putem deduce profesorii care îi predau unui elev,
aflând profesorii clasei din care face parte elevul.
• Aceasta relatie poate fi eliminată.
 Relații redundante

• În cazul în care analizam relațiile dintre entități, luam în

considerare următoarele reguli:
R1. Nu se admit relatii M:M deoarece crește riscul erorilor de
actualizare a datelor din BD.
R2. Nu se admit relatii 1:M care creeaza capcane „în evantai”.
R3. Se pastreaza cu prioritate, relatiile de tip 1:1.
R4. Se pot păstra unele relații redundante dacă prin aceasta se
elimină riscul apariției unei capcane de întrerupere.
 Rezolvarea relațiilor many-to-many

• Relațiile many-to-many pot apărea într-o prima fază a

proiectarii bazei de date, însă ele nu au voie sa apară în
schema finală.
• Să considerăm relația din dintre entitatile STUDENT si
CURS. Se stie ca orice curs se termină în general cu un
examen. Unde vom memora nota studentului la fiecare
examen?
 Rezolvarea relațiilor many-to-many
• Daca încercam sa introducem atributul NOTA la entitatea
STUDENT, nu vom ști cărei materii corespunde acea nota,
întrucât unei instanțe a entității STUDENT îi corespund mai multe
instanțe ale entității CURS.
• Invers, dacă încercăm să memoram nota în cadrul entității CURS,
nu vom știi cărui student îi aparține acea nota.
• Rezolvarea unei relatii many-to-many consta introducerea unei noi
entitati numita entitate de intersectie, pe care o legam de entitățile
originale prin câte o relație one-to-many.
 Rezolvarea relațiilor many-to-many
• Pașii în rezolvarea unei relații many-to-many sunt următorii:
1) Se găsește entitatea de intersecție, pentru exemplul nostru vom introduce
entitate INSCRIERE.
2) Crearea noilor relații:
- opționalitatea: relațiile care pleacă din entitatea de intersecție sunt
întotdeauna obligatorii în aceasta parte. În partea dinspre entitatile originale,
relatiile vor pastra opționalitatea relatiilor inițiale.
- cardinalitatea: ambele relații sunt de tip one-to-many, iar partea cu many va fi
întotdeauna înspre entitatea de intersecție.
- definirea unor nume noilor relații
 Rezolvarea relațiilor many-to-many

3) Adăugarea de atribute în cadrul entității de intersecție, dacă acestea există.

În exemplul nostru ne poate interesa, de exemplu, data la care s-a înscris un
student la un curs, data la care a finalizat cursul, precum și nota obtinuta la
sfârsitul cursului.
 Rezolvarea relațiilor many-to-many
4) Stabilirea identificatorului unic pentru entitatea de intersecție: daca
entitatea de intersecție nu are un identificator unic propriu, atunci acesta se
poate forma din identificatorii unici ai entitatilor initiale la care putem adauga
atribute ale entității de intersecție.
• În exemplul nostru, identificatorul unic al entității de intersecție este format
din id-ul studentului, id-ul cursului și data înscrierii la curs.
5) Faptul ca identificatorul unic al unei entități preia identificatorul unic din
alta entitate cu care este legata este reprezentat grafic prin bararea relației
respective, înspre entitatea care preia UID-ul celeilalte entități.
CAPCANE DE CONECTARE A
ENTITĂȚILOR ÎN DIAGRAME E-R
 Capcane de conectare
În proiectarea modelului de date conceptual, pot sa apara anumite
ambiguitati de interpretare a relațiilor care sa conduca la imposibilitatea
soluționării unor interogări asupra BD. Aceste probleme ale modelului ER se
numesc capcane de conectare si sunt de doua tipuri:
Capcanele în „evantai” apar atunci când aceeași entitate este
implicata în mai multe relații de tip 1: M si căile dintre entități devin ambigue.
De exemplu, din diagrama ER reprezentata mai jos nu putem deduce exact care
proprietăți sunt administrate de un anumit membru de personal.

Capcană în
evantai
 Capcane de conectare
Prin modificarea ordinii de reprezentare a entităților implicate în aceste
relații se obține o structura de tip „arbore” prin care se elimina ambiguitatea
diagramei

Eliminarea capcanei
în evantai
 Capcane de conectare

Capcanele de întrerupere sunt cauzate de absenta reprezentării unor relații

în modelul ER. În modelul de mai sus lipsește relația directă dintre entitățile
Departament și Proprietati, necesara identificării departamentului care se ocupa
de o anumita proprietate. Introducând-o, se creează o anumită redundantă,
preferabilă în unele situații.

Eliminarea capcanei
de întrerupere
MODELAREA DATELOR ISTORICE
 Modelarea datelor istorice
• Viata înseamna schimbare, orice lucru se schimba de-a lungul
timpului, si nu doar obiectele se modifică în timp, dar chiar si
relațiile dintre aceste obiecte se schimbă. Prețul produselor poate
suferi modificari destul de des. Factorii care duc la aceste
modificari pot fi dintre cei mai diversi, inflația, anotimpul etc.
Așadar, atributul Preț din cadrul entității Produs se modifica
de-a lungul timpului. Daca nu ne interesează decât prețul actual
al fiecărui produs, modelul este foarte simplu, ca cel din figură.

• Daca însă pentru afacerea modelată este important să reținem

un istoric al preturilor pentru fiecare produs, atunci atributul
Preț se va transforma într-o noua entitate. Atributul data_sfarsit
este opțional, deoarece data până la care este valabil prețul
curent al unui produs nu este de obicei cunoscut.
 Modelarea datelor istorice
• Vom considera acum o situatie putin mai dificila. Sa presupunem ca dorim sa
modelam o baza de date pentru o biblioteca. Evident este important de reținut un
istoric al tuturor împrumuturilor, deoarece pe baza acestora, se pot afla domeniile
de interes ale cititorilor, si astfel vom ști ce achiziții de carte să facem în viitor,
vom putea determina uzura cărtilor, astfel încât sa le putem înlocui, etc.
• Într-o prima faza vom obține o relație de many-to-many între entitățile CARTE si
CITITOR. Fiecare carte poate fi împrumutata de mai multi cititori (evident
nu în acelasi timp), si fiecare cititor poate împrumuta mai multe carti.
 Modelarea datelor istorice
• Rezolvam aceasta relatie many-to-many.
• Sa verificăm că acest caz este cel corect. Cheia primara în relația de intersecție
este acum combinația coloanelor cod, data_imprumut, cnp.
• Poate un cititor împrumuta două carti în aceeași data? Adică următoarele
două înregistrări cu tupluri identice pot exista simultan în tabela
ISTORIC_IMPRUMUT? Răspunsul este DA, combinația celor trei coloane,
pentru cele doua înregistrari fiind unică.
 Modelarea datelor istorice
• Bararea automată a celor două relații dinspre entitatea de intersecție nu este
întotdeauna o soluție corecta. Pentru a evita aceste complicații putem recurge la
introducerea unei chei artificiale în entitatea de intersectie.
• În exemplul nostru se poate decide ca pentru fiecare împrumut în parte sa se
completeze câte o fișă separată care are un număr unic. Obținem modelul din
figură , care este, de asemenea, unul corect.
MODELAREA GENERICĂ
 Modelarea generică
• În cazul în care regulile afacerii se schimbă foarte des, este relativ dificil
de anticipat și de modelat entitățile bazei de date. În astfel de situații, cu
evoluții nepredictibile ale afacerii, se poate folosi cu succes un model
generic.
• Modelarea generică a BD este avantajoasă din mai multe motive:
– Este flexibilă, adică permite definirea de noi entități și atribute, pe
măsură ce specificul activității descrise se schimbă.
– Folosește un număr considerabil redus de entități, generice, cu
atribute care pot fi definite pe parcurs.
– Se adaptează usor și rapid unor noi condiții de lucru.

• Modelarea generica defineste o entitate generică, cu atribute generice,

care urmează sa ia valori specifice pe măsură ce activitatea descrisă în
BD se diversifică.
 Modelarea generică
• Ca exemplu, putem considera entitatea generică PRODUS, cu un set
extins de atribute, în care să includem toate atributele posibile de la toate
tipurile de articole de îmbrăcăminte (id, denumire, marime, lungime,
culoare, material, gen, circumferinta_talie, bust, lungime_ mâneca,
dimensiune_gât, stil si altele), bineînțeles, toate cu caracter opțional,
astfel încât, pentru un anumit tip de produs, să completăm doar câmpurile
specifice, iar cele care nu îl caracterizează să admită lipsa valorii
(NULL).
• Se pot defini și subtipuri ale entitatii generice, cu condiția să putem
anticipa care sunt tipurile pe care le vizăm pentru activitatea unui
magazin de haine pe durata de viabilitate a BD.
• Ca neajuns, observam ca acest mod de abordare implică o crestere
nedorită a numărului de atribute și a dimensiunii tabelului asociat
entității (12 coloane).
 Modelarea generică
• Totuși, modelarea generică impune o și mai mare generalizare a
noțiunilor.
• Putem folosi entitatea generică TIP_PRODUS cu șase atribute generice
pe care le notăm atribut_1, atribut_2, atribut_3, atribut_4, atribut_5,
atribut_6.
• În tabelul asociat se trec denumirile atributelor, urmând ca valorile lor sa
fie specificate în alt ta bel, corespunzator unei entitati
VALOARE_ATRIBUT. Acest mod de descriere „reciclează” atributele,
reducând numărul lor si mentinând dimensiuni rezonabile ale tabelelor
din BD. Conform diagramei din figura, un articol va avea minimum patru
atribute specificate si maximum șase, alese dintr-un set extins de atribute.
Tabelul cu tipurile de produse va avea șapte coloane în loc de
douăsprezece. Valorile atributelor pentru diferite tipuri de produse, sunt
specificate în alt tabel, cu denumiri generice ale coloanelor.
Modelarea generică

Modelarea generica a entității

PRODUS

Definirea atributelor
unor tipuri de produse

Valorile atributelor
unor tipuri de produse
 Modelarea generică
• Modelul generic prezentat stocheaza informatiile despre produse într-un
singur tabel, cu foarte multe înregistrări, greu de urmărit, si este necesara
sortarea pe mai multe nivele a datelor pentru separarea informațiilor
despre un anumit tip de produs.
• De aceea, în unele cazuri se recurge la folosirea unor relații recursive care
sa permită stocarea informațiilor despre diferite categorii de obiecte, în
tabele diferite.
• Pentru exemplul anterior, în care se modelează BD a unui magazin, în loc
de doua entități generice (TIP_PRODUS, VALOARE_ATRIBUT), se pot
considera mai multe entitati, cu atribute si valori specifice:
• TIP_PRODUS (# id_tip_produs, * nume)
• PRODUS (# id_produs, * id_tip_produs, * nume)
• ATRIBUT (# id_atribut, # id_tip_produs, * nume)
• VALOARE_ATRIBUT(# id_produs, # id_atribut, #
id_tip_produs, * valoare)
 Modelarea generică

• Acest model generic „generalizat” este deosebit de flexibil, în sensul ca

permite adaptarea numărului de atribute la diferitele tipuri de produse sau
de entități, în general. Spre deosebire de primul model generic care
considera un număr maxim prestabilit de atribute, invariabil de la un tip
la altul, modelul generalizat poate include un numar variabil de atribute
pentru diversele tipuri considerate. Modelul poate fi ușor modificat în
timp, pe măsură ce se extinde activitatea descrisa în BD.
• Numărul de coloane din tabelele asociate este fix, în timp ce numarul de
înregistrari (linii) din tabele va creste.
• Prin realizarea unor modele de date generice, se prelungeste durata de
viata a BD si se simplifica munca administratorilor de date. Totuși,
complexitatea și costurile de implementare a unei BD pe baza unui model
generic sunt considerabil crescute.
TRANSFORMAREA DIAGRAMEI E-R ÎN
MODEL RELAȚIONAL DE BAZA DE DATE
Transformarea diagramei E-R în tabele
 Reguli de transformare a diagramei E-R
în model logic
Transformarea entităților se bazează pe regulile:
• Entitățile independente devin tabele independente. Cheia
primară nu conține chei externe.
Exemplu: entitatea independentă SALARIAT generează un tabel
independent pentru care atributul cod_salariat este cheia primară.
• Entitățile dependente devin tabele dependente. Cheia
primara a entităților dependente conține cheia primară a
entității de care depinde plus unul sau mai multe atribute
adiționale.
Exemplu: cheia primară a entității SARCINA este formată din
#nr._proiect (cheia primara a entității PROIECT) și #nr._sarcina.
• Subentitățile devin subtabele.
 Reguli de transformare a diagramei E-R
în model logic
Transformarea relațiilor folosește regulile:
• Relațiile 1:1 și 1:n devin chei externe. Astfel, relația
„conduce’ devine coloană in tabelul DEPARTAMENTE și
relația ‚lucreaza_in’ este coloană in tabelul SALARIAT.
• Simbolul „X” marchează plasamentul cheii externe.
• Simbolul „X” - cheia externa este conținută de cheia primară.
• Relația m:n devine un tabel special (tabel de intersecție)
care are 2 chei externe pentru cele 2 tabele asociate. Cheia
primară este formata din compunerea celor 2 chei externe
plus coloane adiționale. Se specifica punctat.
 Reguli de transformare a diagramei E-R
în model logic
Transformarea atributelor folosește regulile:
• Un atribut singular devine o coloana.
• Atributele multiple devin tabele dependente ce conțin cheia
primara a entității și atributul multiplu.

Exemplu: un SALARIAT are mai multe numere de telefon →

nr._telefon este atribut multiplu care generează tabelul dependent
TELEFON.
 Reguli de transformare a diagramei E-R
în model logic

Schemele relaționale obținute sunt:

SALARIAT(cod_salariat#, nume, prenume, salariu, lucrează_in)
DEPARTAMENTE(cod_departament#, nume, localitate, conduce)
INSCRIS_LA(cod_salariat#, nr._proiect#, funcție)
PROIECT(nr._proiect#, descriere, buget_alocat)
SARCINA(nr._proiect#, nr._sarcina#, stare)
TELEFON(cod_salariat#, nr._telefon#)