Materialaditional Cursbd Partea1 [608308]

CURS BD – PARTEA I
I. Baze de date ș i sisteme de gestiune a bazelor de date

I.1. No țiuni introductive

În prezent, bazele de date reprezintă nucleul sistemelor informatice din orice companie sau institu ție, având un
impact major asupra modului de func ționare și organizare al acestora. Totodată oferă o deschidere majoră asupra
pieții pe care o vizează, ofer ind posibilitatea clien ților de a avea acces în mod facil la datele esen țiale de care ace știa
au nevoie. Fiecare ac țiune pe care o persoană o efectuează în prezent în mediul online implică direct sau indirect
interac țiunea cu una sau mai multe baze de date, fie că este vorba de o simplă căutare pe Google, rezervarea unui
bilet de avion pe SkyS canner, accesul la o librărie digitală, achizi ționarea de produse pe Amazon sau verificarea
contului din bancă. Inevitabil, cu to ții interac ționăm cu baze de date, iar prin natura lor de a structura eficient
informa țiile acestea ne pot u șura considerabil activită țile cotidiene.
Trebuie avut în vedere faptul că de multe ori, în viaț a de zi cu zi, prin abuz de limbaj, se folose ște termenul de Bază
de D ate (BD) pentru a desemna de fapt un S istem de G estiune a B azelor de D ate (SGBD) . Ce este deci o bază de
date și care este diferen ța față de un sistem de gestiune a bazelor de date?

Putem defini într-o primă etapă o Bază de D ate (BD) ca fiind un ansamblu de date structurat, stocat în mod
centralizat sau nu , pe servere, accesibil , interogabil și modificabil de un grup de utilizatori care lucrează în paralel,
prin intermediul uneia sau a mai multor aplica ții. Pe de altă parte, un Sistem de Gestiune a Bazelor de Date (SGBD)
poate fi văzut generic ca un sistem care se ocupă de structur area, stocarea, actualizarea ș i mentenan ța datelor,
reprezentând de fapt interfa ța între baza de date ș i utilizator sau aplica țiile acestuia.

Metodele tradi ționale de gestiune și management a datelor se bazau pe sistemele de fi șiere pentru stocarea
perman entă a informaț iilor. Însă, s implele colec ții de fișiere de date care nu permit operații de interogare nu pot fi
considerate baze de date. De exemplu, ansamblul de informa ții stocate în fișiere generate de aplica ții de calcul
tabelar precum Microsoft Excel nu poate fi considerat o bază de date. Organizarea datelor în fi șiere nu poate
răspunde decât unor nevoi precise . Serviciile care folosesc aceste fi șiere, utilizează cel mai adesea informaț ii în mod
separat pentr u diferite tratamente. Din acest motiv, spre exemplu, fiecare departament al unei companii dispune de
propriile fi șiere de date în care nu sunt stocate decât informaț iile care le privesc în mod strict.
Astfel, în contextul metodei convenț ionale de organi zare a datelor în sisteme de fi șiere se poate consta ta apari ția unor
inconveniente majore precum:
– Redundan ța datelor – existen ța unor date identice în fi șiere diferite poate pune probleme serioase atunci când
se dore ște actualizarea acestor informaț ii. Spre exemplu, în cazul unei bănci, dacă coordonatele unui client
sunt stocate atât într -un document ce con ține tranzacț iile efectuate de acesta, cât ș i într -un document ce
stochează informaț ii privind creditele, atunci actualizarea informaț iilor în toate f ișierele în care clientul
figurează va deveni aproape imposibilă. Evident, pot apărea probleme de incoerenț ă în cazul în care
modificarea nu se reflectă în toate documentele în care se regăseș te acea informaț ie.
– Dificultatea de acces la date – accesul la anumite informa ții necesită interven ția unei persoane specializate
care cunoa ște exact structura ș i căile către directoarele și fișierele existente în sistem. Această structură nu
oferă de cele mai multe ori un nivel de abstractizare suficient pentru a putea permite interogări directe și
interactive din partea utilizatorilor neexperimentaț i.
CURS BD

– Probleme privind accesul concurent la date – În cazul în care mai multe aplicaț ii deschid și modifică în mod
simultan un fi șier vor apărea pierderi de date deoarece ultima salvare va produce documentul final care va
rămâne stocat în sistem.
– Probleme legate de i ntegritatea datelor – Când anumite informa ții sunt introduse în sistem, acestea trebuie să
se supună unor constrângeri. De exemplu, dacă soldul unui cont bancar nu are voie să fie mai mic de -10000
RON, atunci această constrângere trebuie implementată în toate aplicaț iile care pot modifica soldul unui cont
bancar. Mai mult, dacă această constrângere se modifică după o perioadă de timp, vor trebui găsite toate
programele care verifică această constrângere, modificate și recompilate. Deci, poate apărea o incoeren ță la
nivel de coordonare între diferitele aplica ții care gestionează în mod direct sisteme de fiș iere.
– Lipsa de securitate a datelor – Anumite informaț ii dintr -un sistem ar trebui să poată fi accesate doar de
anumi ți angaja ți. De exemplu: un angajat al unei companii ar trebui să poată vizualiza doar informa țiile
privind propriul salariu, nu și pe cel al colegilor săi. De asemenea, nu ar trebui să aibă dreptul să îl modifice. Securitatea datelor este deci, de cele mai multe ori imposibil de asigurat, având în vedere că anumite informa ții dintr -un fi șier ar trebui să fie accesibile pentru anumi ți utilizatori și private pentru al ții.
– Imposibilitatea portării datelor și a aplicaț iilor care le gestionează – În cazul în care o companie lucrează în
prezent pe un anumit sistem de operare ș i utilizează anumite aplica ții proprietare pentru manipularea datelor
interne, atunci migrarea către un alt sistem de operare va fi extrem de greoaie. Spre exemplu: toate documentele salvate în aplicaț ii precum Microsoft Office vor trebui convertite în fiș iere OpenOffice,
compatibilitatea între cele două aplicații nefiind asigurată în mod predefinit în orice situaț ie.
– Probleme de mentenan ță – în cazul în care este necesară modificarea structurii datelor manipulate de sistem,
va trebui asigurată trecerea datelor din vechea structură în cea nouă. Acest lucru, de cele mai multe ori, poate
presupune rescrierea completă a aplicaț iilor dezvoltate de și vor realiza aceleaș i opera ții ca și în trecut.

În consecin ță, organizarea datelor în mod tradițional, sub formă de fiș iere și utilizarea acestora în aplica ții, fără a se
face o separare completă între cele două, atrage după sine inconveniente majore. O solu ție la această problemă
presupune regruparea și crearea unui caracter de unicitate al datelor, precum ș i gestionarea acestora într- un mod
centralizat. Administrarea unică și centralizată a datelor la nivel de companie/societate asigură coeren ță accesului la
informa ție și independen ța înt re aplica ții și datele stocate. Toate aceste probleme pot fi rezolvate cu ajutorul
Sistemelor de Gestiune a Bazelor de Date.

Astfel, doar în acest context, ansamblul tuturor datelor dintr -un sistem pot fi regrupate sub denumirea de Baze de
Date. Datele trebuie deci descrise într -un mod independent de aplica țiile și utilizatorii finali care le folosesc. Această
descriere necesită întotdeauna un model , un ansamblu de concepte și reguli, cât mai detaliate din punct de vedere
semantic pentru a putea oferi într -o manieră formală o schemă privind modul de structurare a informa ției. Sistemele
care pun în aplicare aceste scheme (care stochează datele, gestionează accesul la date, gestionează drepturile de utilizatori ș i tratează toate problemele descrise anterior) formează veritabilele Sisteme de Gestiune a Bazelor de Date.

I.2. Modelarea datelor
Un model de date reprezintă un ansamblu de reguli ș i concepte care permit descrierea datelor și a relaț iilor dintre ele
așa cum se regăsesc într-un sistem informatic. Într -un sens mai larg, putem spune că un model de date oferă o
modalitate de abstractizare a lumii reale care permite descrierea și reprezentarea:
– entită ților ș i a datelor care o compun
– legăturilor (asocieri, rela ții, corespondenț e) dintre ele
– constrângerilor pe care trebuie să le respecte informaț iile din baza de date.

CURS BD

Conform standardului ANSI/SPARC [1], descrierea datelor se poate realiza pe trei niveluri de abstractizare ( fizic,
conceptual , extern ) denumite niveluri de descriere sau scheme (Figura I.1). Fiecare nivel corespunde unei categorii
de utilizatori diferiț i, astfel:

– Nivelul fizic are în vedere modul de stocare ( schema fizică ) a bazei de date pe dispozitivele fizice de
memorie (organizarea și parti ționarea informa ției pe hard- disk, sistemul de exploatare, numele fi șierelor,
dimensiunea lor, calea de acces, modul de acces). Bineîn țeles, acest nivel depinde de platforma ș i sistemul de
operare pe care este stocată baza de date. Fiecare SGBD are în general implementat un model propriu de
descriere a bazei de date la nivel fizic, oferind facilităț i de manangement pentru administratorul bazei de
date în vederea modificării acestuia. Un SGBD nu utilizează în general sistemul de fi șiere pus la dispozi ție
de sistemul de operare pentru a salva informaț ia pe disc, ci folose ște propriile tehnici de stocare. Un SGBD
rezervă o anumită parte din memorie ș i hard -disk și utilizează blocuri de memorie pentru a realiza operaț ii de
scriere, citire, alocare sau dealocare de memorie. În aceste blocuri de memorie, informaț ia este văzută ca un
șir de octe ți pentru care sistemul cunoa ște modul de organizare și poate citi în consecin ță informația stocată.
– Nivelul conceptual define ște structura ( schema conceptuală) bazei de date cu tot ansamblul colec țiilor de
date și a legăturilor dintre acestea. La acest nivel se va stabili, spre exemplu, că o anumită colec ție de date
conține lista tuturor angaja ților dintr -o companie și că o anumită persoană are atribuit un nume (care
reprezintă un ș ir de caractere), o dată de na ștere, o adresă, etc. Această descriere trebuie să fie independentă
de modul de im plementare la nivel fizic ș i de modul în care ea va fi accesată de diferitele grupuri de
utilizatorii finali prin intermediul aplica țiilor. Schema conceptuală este definită și administrată de
dezvoltatorii bazei de date, eventual în colaborare cu administr atorul bazei de date și dezvoltatorii de
aplicaț ii.
– Nivelul extern (sau nivelul vedere) permite utilizatorilor/grupurilor de utilizatori/aplica țiilor să dispună doar
de informa țiile din baza de date la care au acces. Se permite astfel, crearea mai multor vederi asupra unei
aceleiași realită ți. Spre exemplu, clientul unei bănci nu poate vizualiza informaț iile din întreaga bază de date
a băncii, ci are acces numai asupra unei vederi cu informa țiile propriului cont. Logica după care sunt create
vederile poartă numele de scheme externe și sunt descrise de obicei cu ajutorul modelului de date folosit
pentru schema conceptuală.

Fig. I.1. Nivelurile de abstractizare ale unei baze de date
Se observă faptul că o bază de date are asociată o singură schemă fizică și o singură schemă conceptuală, dar mai
multe scheme externe.
CURS BD

Sistemele de gestiune a bazelor de date dispun de mecanisme de coresponden ță pentru a putea transforma datele de
pe un anumit nivel în informa ții ce pot fi interpretate în mod corect de nivele le vecine. În acest fel, utilizatorul bazei
de date nu trebuie să deț ină cuno ștințe de programare aprofundată.

Modul de abstractizare pe cele trei niveluri permite ob ținerea unei independen țe atât din punct de vedere fizic cât și
logic. Independenț a din punct de vedere fizic asigură faptul că o modificare a schemei fizice nu va atrage după sine o
modificare a schemei conceptuale sau a modului de acces la date. Acest lucru permite spre exemplu, mutarea bazei de date de pe un server pe altul, fără a fi necesară modificarea structurii bazei sau a aplicaț iilor care o accesează. O
simplă modificare a fiș ierelor de configurare a SGBD -ului care face coresponden ța între nivelul fizic și cel
conceptual va permite fără nici o problemă operaț ii precum: înlocuirea di spozitivelor de stocare, schimbarea numelor
fișierelor în care este stocată baza de date sau modificarea diferi ților parametrii ai SGBD -ului care stabilesc modul în
care datele sunt salvate în sistem.
Din punct de vedere logic, independenț a constă în posibilitatea de modificare a schemei conceptuale fără a atrage
după sine necesitatea modificării vederilor sau a schemei fizice. Eventual, doar anumite vederi care au impus modificarea schemei conceptuale, vor fi modificate la rândul lor.

În proiectarea bazelor de date se folosesc 2 categorii de modele de date pentru definirea schemei conceptuale:
– Modele conceptuale de nivel înalt care descriu in mod succint datele ce modelează o parte din lumea reală,
fără a specifica modul de reprezentare al acestora. Din această categorie fac parte: modelul Entitate -Asociere
și modelul Entitate-Asociere Extins.
– Modele specializate care descriu în detaliu, sub formă de scheme logice, mul țimea obiectelor ce trebuie
modelate din lumea reală precum și rela țiile dintre acestea. Din această categorie fac parte: modelul ierarhic,
modelul re țea, modelul rela țional, modelul obiect- orientat.

I.2.1. Modele conceptuale de nivel înalt
Modelele de date de nivel înalt propun definirea unor concepte apropiate de modul în care cea mai mare parte a
utilizatorilor percep datele. Sunt definite concept precum entităț i, atribute, rela ții. Cel mai întâlnit model de nivel
înalt este modelul Entitate -Asociere (E/A) car e descrie schema conceptuală a bazei de date prin mul țimi de entită ți și
asocieri între acestea. Modelul E/A a fost extins rezultând dezvoltarea unui model similar, cunoscut de numele de
model Entitate -Asociere Extins (E/A -E), care permite în plus faț ă de E/A introducerea de subclase și superclase,
împreună cu concepte precum specializare și generalizare. Proiectarea modelului E/A sau E/A -E reprezintă una din
primele etape în dezvoltarea bazelor de date.

I.2.1.1. Modelul Entitate -Asociere (E/A)
Modelul Entitate -Asociere (Entity -Relationship) este un model foarte des utilizat în dezvoltarea aplicaț iilor de baze
de date datorita simplită ții și expresivită ții sale , fiind un model conceptual de nivel înalt care define ște mul țimea
entită ților ș i a relaț iilor dintre acestea, f ără a impune însă condi ții specifice de gestiune sau structurare a informaț iei.
Modelul E/A este compus din trei elemente definitorii:
– Entit ăți
– Atribute
– Asocieri între entită ți
CURS BD

O entitate modelează un obiect, un concept, un element care există de regulă în lumea reală și care se diferen țiază de
alte elemente (unic). Spre exemplu, contul bancar al unei persoane X este o entitate descrisă de un număr de
identificare, numele ș i prenumele clientului X, soldul con tului, etc. În modul de reprezentare grafică, o entitate este
figurată printr -un dreptunghi cu numele entităț ii în interior conform figurii I.2.

Fig. I.2. Convenț ia de reprezentare a conceptului de entitate în cadrul modelului E/A
Un atribut reprezintă o proprietate care descrie o anumită caracteristică a unei entități. Poartă un nume și are asociat
un domeniu de valori (Ex: medie, [1..10] ). Un atribut poate fi văzut ș i ca o func ție entitate →domeniu . De exemplu:
atributul sold poate reprezenta soldul curent al unui cont client dintr -o bancă. Văzut ca o funcț ie, putem avea
sold(client_X) = 2500 . În cadrul modelului Entitate -Asociere, conven ția de reprezentare a conceptului de atri but este
ilustrată în figura I.3.

Fig. I.3. Convenț ia de reprezentare a conceptului de atribut în cadrul modelului E/A
Atributele pot fi de mai multe tipuri:
– atribute compuse și atribute simple . Atributele compuse sunt acele atribute care pot fi divizate în subpăr ți,
respectiv în atribute elementare care au o anumită semnifica ție de sine stătător. Spre exemplu, atributul
adresă al unui angajat, care are valoarea “ B-dul Iuliu Maniu, Nr. 313, Sector 6, Bucure ști” poate fi divizat în
sub-atribute le: strada , număr , sector și oraș, cu valorile: “ Iuliu Maniu”, “313”, “6”, “ Bucure ști”. Atributele
care nu sunt divizibile se numesc atribute simple sau atomice. Valoarea unui atribut compus se poate ob ține
prin concatenarea valorilor atributelor simple din care este constituit. Atributele compuse permit modelizarea
unei situa ții în care utilizatorul poate să facă referire fie global, la întreaga valoare a atributului compus, fie
la păr țile sale componente. Dacă este nevoie doar de valoarea sa globală atunci nu are sens divizarea sa în
sub-atribute, iar acesta va fi considerat atribut simplu.
– Atribute monovaloare și multivaloare. Marea majoritate a atributelor unei entită ți au o singură valoare (a nu
se înțelege că poate lua o singură valoare dintr -un domeniu de valori posibile). Acest tip de atribut se numesc
atribut monovaloare . De exemplu: vârsta este un atribut monovaloare a unei entităț i persoană. Însă, în
anumite situa ții, atributul unei entită ți poate de ține un ansamblu de valori. De exemplu: putem avea entită ți
mașină care au o singură culoare, deci atributul corespunzător are o valoare unică, dar putem avea și mașini
bicolore și în acest caz atributul culoare va avea două valori. Un astfel de atribut se numeș te atribut
multivaloare .
– Atribute stocate și atribute derivate. În anumite situa ții valorile atributelor unei entită ți pot fi
interdependente. De exemplu: atributele vârstă și dataNaș tere , asociate unei entită ți persoan ă, sunt într -o
legătură directă. Valoarea atributului vârstă poate fi calculată u tilizând data curentă ș i valoarea atributului
dataNaș tere. Spunem că atributul vârstă este un atribut derivat, din atributul stocat dataNaș tere . Anumite
valori pot fi derivate și indirect din alte informa ții stocate în baza de date. De exemplu: numărul de studen ți
dintr- o facultate poate fi ob ținut prin însumarea entităț ilor student care învaț ă în acea facultate.
Există situa ții în care valoarea unui atribut nu poate fi specificată, fie pentru că nu se cunoa ște (de exemplu: o
persoană nu doreș te să î și facă public numărul de telefon), fie pentru că ea nu a fost men ționată în mod voluntar (de
CURS BD

exemplu: atributul numarApartament al unei adrese nu corespunde la nimic în cazul în care persoana locuie ște la
casă.). În acest caz se recurge la utilizarea valor ii NULL pentru atributul respectiv.

Entită ți similare (omogene) care pot fi descrise de aceleaș i atribute (dar care pot avea valori diferite), sunt grupate în
așa numitele mulțimi (clase) de entită ți. O clasă de entită ți este definită de un nume și de atributele sale. Aceasta
reprezintă un tip (o schemă ) pentru entită țile sale. Spre exemplu: clasa Conturi_Clien ți poate grupa toate conturile
clien ților dintr -o bancă. Atunci contul persoanei X putem spune că este de tipul Conturi_Clien ți.

Deși dife rențele între entitate și clasă/mul țimi de entită ți sunt evidente, în cadrul modelului E/A, în reprezentarea
grafică uzuală , cele două concepte sunt reprezentate în mod similar conform figurii I.2.
Un atribut sau ansamblul de mai multe atribute care permit e realizarea distinc ției (identificarea unică) între entită țile
unei clase se numeș te identificator sau cheie . De exemplu: atributul IDcont poate reprezenta un identificator în
cadrul clasei Conturi_Clien ți și va avea o valoare diferită pentru fiecare entitate a clasei. În cazul în care o cheie este
formată dintr -un ansamblu de atribute, atunci acest set trebuie să fie minimal ș i să asigure condi ția de unicitate. Altfel
spus, doar prin combinarea valorilor atr ibutelor din acest set, fiecare entitate poate fi identificată în mod unic. În
cadrul diagramei E/A, numele atributului cheie este subliniat în interiorul o valului conform figurii I.4.

Fig. I.4. Convenț ia de reprezentare a conceptului de identificator în cadrul modelului E/A
Modelul E/A introduce de asemenea conceptul de asociere care permite punerea în relaț ie a mai multor entită ți. De
exemplu: între entităț ile salariat și departament se poate stabili o asociere membru_in care descrie împăr țirea
angajaților unei companii pe departamente. În momentul în care un atribut al unei clase de entităț i face referire la un
alt tip de entitate, spunem că există o asociere între ele. Astfel, de și în exemplul de mai sus departamentul ar putea fi
văzut ca un atribut pentru o entitate salariat, totu și această legătură nu trebuie privită în acest mod, ci ca o relaț ie între
cele două clase. În cadrul diagramelor E/A, asocierile sunt reprezentate prin romburi care conectează prin segmente
de dreaptă două sau mai m ulte entită ți. Numele asocierii este afi șat în interiorul rombului conform figurii I.5 .

Fig. I.5. Convenț ia de reprezentare a conceptului de asociere în cadrul modelului E/A

Ca și în cazul entită ților, asocierile pot avea atribute. De exemplu: pentru a memora data de la care un salariat este
membru_in cadrul unui departament , se poate introduce proprietatea dataIntrare ca atribut al asocierii membru _in.

Grupul de asocieri de acelaș i tip , care au aceleaș i atribute ș i care unesc entităț i de acelaș i tip formează o
clasă/mul țime de asocieri . Fiecare instan ță a unei clase de asocieri poate pune în relaț ie o entitate a unei clase de
entită ți cu o altă entitate a unei alte clase. De exemplu: conside rând clasele de entităț i Salariati și Departamente ,
fiecare instan ță asociere din clasa de asocieri membru_in pune în rela ție o entitate salariat cu o entitate
departament , astfel: Petrescu Ion ↔ Cercetare, Marinescu Dan ↔ IT, Gavrilescu Mircea ↔ Economic, etc.
Figura I.6 prezintă schematic tipul de asociere membru_in între Salariati și Departamente .

CURS BD

Fig. I. 6. Reprezentarea mul țimii de asocieri membru_in între clasele de entităț i Salariati și Departamente

Ca și în cazul entită ților și a claselor de entităț i, deși diferen ța este evidentă, prin abuz de limbaj, se va înț elege prin
termenul de asociere, o mul țime de asocieri, iar reprezentarea grafică în cadrul modelului E/A va fi identică
(Figura I.5).
Pentru o asociere se poate defini termenul de grad ca numărul mulț imilor de entităț i care intervin în acea asociere.
Asocierile pot fi binare (de gradul 2) sau multiple (de grad mai mare decât 2; ex: ternare, quaternare, etc.) . În
Figura I.7 este prezentat exemplul unei asocieri ternare, unde fiecare instan ță a
i
reprezintă o asociere între trei
entită ți: un salariat s, un departament d și un proiect p .

Fig. I.7. Exemplu de asociere ternară

CURS BD

Asocierile cele mai des întâlnite rămân totu și cele binare, deoarece odată cu cre șterea gradului, crește și
complexitatea modelului E/A. În func ție de numărul entităț ilor puse în corespondenț ă în fiecare mul țime de entită ți
(fie acestea E1 și E2) putem distinge patru tipuri de asocieri binare:
– asociere “unu- la-unu” – unei entită ți din mul țimea E1 îi corespunde o singură entitate din E2 și vice -versa.
Pentru acest tip de asociere se folose ște nota ția 1:1. Asocierea conduce , așa cum este prezentată în
Figura I.8.a reprezintă un exemplu bun de relaț ie binară 1:1. În cadrul acestei asocieri, o entitate de tip
Sefi_departamente este pusă în rela ție cu o entitate de tip Departamente , ceea ce poate fi în concordan ță cu
constrângerile impuse în cadrul companiilor ca un angajat să nu poată conduce decât un singur departament,
iar un departament să nu poată fi condus decât de o singură persoană.
– asociere “unu- la-multe ” – unei entită ți din mul țimea E1 îi pot corespunde mai multe entităț i din E2, dar o
entitate din E2 nu poate fi asociată mai multor entită ți din E1 . Pentru acest tip de asociere se folose ște
notația 1:N. Asocierea compus_din , așa cum este prezentată în Figura I.8 .b poate reprezenta un exemplu de
relație binară 1:N. O entitate de tip calculator poate fi compus din mai multe entităț i de tip componente, dar o
aceeași componentă nu se poate regăsi în mai multe calculatoare.
– asociere “multe -la-unu” – mai multe entită ți din mul țimea E1 corespund unei entită ți din E2 , dar o entitate
din E1 nu poate fi asociată mai multor elemente din E2. Pentru acest tip de asociere se foloseș te notaț ia N:1 .
Asocierea membru_ in, așa cum este prezentată în Figura I.8 .c reprezintă un exemplu de relaț ie binară N:1 .
Un salariat poate fi membru doar într -un singur departament, în timp ce un departament este format din mai
mulți salaria ți.
– asociere “multe -la-multe ” – mai multe elemente din mul țimea E1 pot fi asociate cu mai multe elemente din
E2 și vice -versa. Pentru acest tip de asociere se foloseș te nota ția N:M. Asocierea predare_la așa cum este
prezentată în Figura I.8 .d poate reprezenta un exemplu de rela ție binară N:M. Astfel mai mul ți profesori pot
preda la mai multe grupe de studen ți, în timp ce fiecare grupă poate lua lec ții de la mai mul ți profesori la
diferite materii.

Fig. I.8. Tipuri de asocieri binare: a) asociere 1:1; b) asociere 1:N; c) asociere N:1; d) asociere N:M
CURS BD

Număr ul de elemente dintr -o mul țime de entităț i care pot fi asociate unui element dintr -o altă mulț ime de entităț i se
nume ște cardinalitate a asocierii față de acea mul țime. Putem distinge între cardinalitate minimă și maximă . În cazul
cardinalită ții maxime putem avea valori: 1 sau M (/N /P/…). De exemplu: un client poate avea M cont uri într-o bancă,
respectiv un client poate avea maxim 1 credit de tip prima casă. În cazul cardinalită ții minime putem avea valori: 0
sau 1. De exemplu, o persoană poate să nu aibă nici un cont în bancă (minim 0), respectiv un cont în bancă este deținut de cel puțin o persoană (minim 1). Cardinalitatea maximă este cunoscută și sub denumirea de grad de
asociere, iar cardinalitatea minimă reprezintă obligativitatea participării entită ților la o asociere. În cadrul diagramei
E/A, cardinalitatea este înscrisă pe segmentele de dreaptă care unesc clasele de entită ți de mul țimea de asocieri. În
Figura I.9, se poate observa gra ție cardinalită ților marcate pe diagramă că un client poate să nu aibă nici un cont (0)
sau poate să aibă maxim N conturi în bancă, în timp ce un cont trebuie să aibă asociat cel puț in un client, putând avea
până la maximum M titulari.

Fig. I.9. Reprezentarea cardinalităț ii asocierii în cadrul diagramelor E/A
Raportul dintre valorile cardinalită ților maxime ale unei asocieri binare fa ță de cele două clase de entită ți pe care le
pune în relaț ie se numește raport de cardinalitate . Pentru exemplul din Figura I.9, raportul de cardinalitate este N:M.
Figura I.9 poate fi simplificata conform diagramei din Figura I.10.

Fig. I.10. Metoda simplificată de reprezentare a cardinalită ții asocierii în cadrul diagramelor E/A
În cazul asocierilor multiple (de grad mai mare ca doi) se va stabili câte un raport de cardinalitate pentru fiecare pereche de clase de entităț i asociate.

Revenind la tipurile de entităț i, acestea pot fi clasificate în două categorii:
– entită ți puternice
– entită ți slabe
Entită țile puternice sunt acele entită ți care pot fi identificabile doar cu ajutorul propriilor atribute (de țin un atribut
cheie). O entitate care apar ține unui clase de entită ți slabe sunt identificabile doar prin raportare la alte entităț i
puternice (dominante). În consecinț ă, o entitate slabă va avea o cheie formată din unul sa u mai multe atribute proprii
(identificatori par țiali), la care se adaugă identificatorul entităț ii dominante. De exemplu, în cadrul unei companii
care î și desfă șoară activitatea în mai multe corpuri de clădiri, există entită ți slabe – birouri , care au ca entită ți
puternice – clădirile în care acestea se află. Identificatorul par țial va fi numărul biroului, în timp ce cheia va fi
obținută prin concatenarea acestuia cu numele clădirii (care în acest caz este identificatorul entităț ii dominante). În
cadrul di agramelor modelelor E/A, entită țile slabe sunt reprezentate printr -un dreptunghi cu muchie dublă, iar
numele atributului identificator par țial este subliniat cu linie punctată conform exemplului din Figura I.11.

Fig. I.11. Exemplu de reprezentare a unei entităț i slabe în cadrul unei diagrame E/A
CURS BD

Pentru exemplificare și pentru a putea rezuma noțiunile prezentate anterior, se va considera caz ul detaliat al unui
model conceptual de nivel înalt, al unei baze de date , reprezentat sub forma unei diagrame Entitate -Asociere
(Figura I.12). Se urmăreș te punerea în eviden ță a modului de reprezentare a diferitelor tipuri de entități împreună cu
atributele care le definesc, precum și a tipurile de asocieri care se stabilesc între acestea.

Fig. I.12. Exemplu detaliat de model conceptual de nivel înalt reprezentat sub formă de diagrama E/A

În exemplul din Figura I.12, clasa Clien ți este un tip de entitate puternică care de ține patru atribute ( numeClient,
CNP, IDClient, adresă ), dintre care unul este identific atorul clasei (IDClient ) care permite diferen țierea între entităț ile
clasei. Clasa Clien ți grupează mulț imea tuturor entită țile de acest tip, caracterizate de aceleaș i atribute. Putem scrie
toate aceste informaț ii sub formă sintetică, astfel: Clien ți(IDClient , numeClient, CNP, adresă) . Similar, pentru
mulțimea de entităț i Conturi , avem: Conturi( numarCont
, sold) .
Tipul de entitate Tranzac ții depinde în mod direct de contul din care se realizează operaț iunea. Se poate observa că
această clasă n u deține un ident ificator propriu, ci cheia este formată din identificatorul numarCont al clasei Conturi
și identificatorul par țial numarTranzactie . Spunem că tipul Tranzac ții este un tip de entită ți slab. Acesta se poate
scrie sub formă sintetică astfel: Tranzac ții (numarCont
, numarTranzactie , data, suma) .
În cadrul diagramei din Figura I.12 se stabileș te de asemenea o asociere denumită detine , între mul țimile de entită ți
Clien ți și Conturi , care este de tipul “ multe -la-multe ” cu raportul de cardinalitate N:M, ceea ce semnifică faptul că
un client poate de ține maximum M conturi și fiecare cont poate avea maximum N titulari. Asocierea detine are în
plus și un atribut data, care în acest caz poate reprezenta data la care s-a asoc iat contul X, unui client Y.

Asocierea efectuat prezintă un raport de cardinalitate 1:Q faț ă de mul țimile de entită ți Conturi și Tranzac ții, ceea ce
semnifică faptul că dintr -un cont se pot efectua Q tranzac ții, dar o tranzacț ie nu poate fi asociată decât unui singur
cont client.

I.2.1.2. Modelul Entitate -Asociere Extins (E/A -E)

Conceptele abordate în cadrul modelului E/A sunt în general suficiente pentru reprezentarea schemelor bazelor de date simple, tradi ționale. Însă, în ultimii ani, dezvoltatorii de baze de date [2] au încercat să conceapă modele din ce
în ce mai exacte, capabile să reprezinte cât mai precis proprietăț ile datelor ș i asocierile dintre acestea, aș a cum se
regăsesc în lumea reală. Unul dintr e aceste modele este modelul Entitate- Asociere Extins (E/A -E) care cuprinde toate
conceptele modelului clasic E/A explicate în capitolul anterior. Acest nou model introduce conceptele de subclase
(subtipuri ) și superclase ( supertipuri ), precum ș i noțiunile asociate lor de specializare ș i generalizare .

Există cazuri în care mai multe clase de entităț i se aseamănă din punct de vedere semantic și structural (ex: o entitate
Student_la_Licenta și o entitate Student_la_Master ). Pentru a ob ține o schemă conceptuală mai compactă care să
pună în evidenț ă asemănările dintre mulțimile de entită ți, se poate crea un nou tip de entitate (tipul Student pentru
CURS BD

exemplul anterior) care să înglobeze proprietăț ile comune (atribute le) ale claselor considerate. Acest pr oces poartă
numele de generalizare, iar clasa ob ținută este denumită superclasă .

De asemenea, pot fi situa ții în care , pornind de la un tip de entităț i existent, se doreș te definirea unor subtipuri de
entită ți care să se diferen țieze între ele doar prin câteva proprietă ți specifice, în func ție de rolul pe care îl îndeplinesc
în cadrul modelului de date. Acest proces poartă numele de specializare, iar clasele ob ținute sunt denumite subclase .
Practic, specializarea este procesul invers al generalizării.
Subclasele moștenesc în mod predefinit atributele ș i asocierile specifice clasei generale (superclasei). De exemplu,
pentru modelul prezentat în Figura I.12. putem crea din superclasa generală Conturi , care grupează caracteristicile
comune ale tuturor contur ilor ( numarCont , sold ), două submul țimi de entită ți denumite : Cont uriCurent e (cu atributul
specific descoperitAutorizat
1
) și Cont uriDeEconomii (cu atributele dobanda și dataScadenta). Această separare pe
subclase permite apoi definirea de noi tipuri de entită ți asociate, care în caz contrar nu ar fi putut avea sens din punct
de vedere logic. Spre exemplu, unui cont curent îi putem asocia o entitate de tip card, în timp ce acest lucru nu este
posibil pentru un cont de economii.
Figura I.13. prezintă diagrama modelului Entitate/Asociere -Extins pentru exemplul prezentat în Figura I.12 și
dezvoltat conform explica țiilor anterioare. Conceptul de moș tenire dintre o superclasă și toate subclasele sale este
reprezentat în cadrul diagramei E/A -E printr-un segment de dreaptă ș i un semicerc orientat către tipurile de entită ți
derivate.

Fig. I.13. Model conceptual de nivel înalt reprezentat sub formă de diagrama E/A -E

I.2.1.3. Reguli în construirea modelelor conceptuale E/A ș i E/A -E

În func ție de complexitatea datelor care trebuie modelate pentru a satisface cât mai precis condi țiile impuse de
realitate, uneori pot apărea ambiguită ți în clasificarea diverselor informaț ii în concepte precum: entitate, atribut,
cheie sau asociere. Aceste ambiguităț i pot crea probleme în construirea modelulu i E/A pe baza căruia ulterior se va
stabili structura bazei de date. De exemplu: dacă într -o bază de date avem informaț ii despre angajaț ii unei companii
și ne interesează oraș ul în care s- au născut, atunci conceptu l de OrasNastere poate fi modelat ca un atribut al entităț ii
Angajat . Însă dacă dorim să realizăm o bază de date cu toate persoanele din Romania, atunci conceptul de Oraș va fi
văzut ca o entitate distinctă sau ca un atribut al entităț ii Persoană ?

1 Descoperitul autorizat de cont reprezintă o soluție de finanțare prin care un client al unei bănci are acces în orice moment la o rezervă de bani
în cazul în care î și consumă propriile economii din cont . În exemplul curent, atributul descoperitAutorizat va specifica valoarea rezervei.
CURS BD

Pentru a putea elimina aceste ambiguităț i, trebuie ț inut cont de o serie de reguli în construirea modelelor conceptuale,
astfel:

A. Reguli legate de alegerea identificatorului
R1. Se va evita utilizarea identificatorilor compu și deoarece reduc viteza de căutare în baza de date.
R2 Se va evita utilizarea identificatorilor susceptibili la schimbare de -a lungul timpului.
R3. Se vor evita identificatorii de tip șiruri de caractere .

Figura I.14 prezintă o serie de cazuri în care alegerea greș ită a identifica torilor poate pune probleme ulterioare în
momentul utilizării bazei de date :
– În primul caz al tipului de entitate Persoana , alegerea identificatorului compus din cele două atribute nume
și prenume nu reprezintă o alegere corectă, deoarece va fi imposibilă introducerea în baza de date a două
persoane omonime (tizi).
– În cel de -al doilea caz al entităț ii Persoana , alegerea identificatorului CNP poate pune de asemenea probleme
în unele situa ții. Două persoane născute la interval de un secol, pot avea un cod numeric personal identic. De
asemenea, un străin care intră pe teritoriul României nu va avea un CNP, caz în care informaț ia va rămâne
necompletată ( NULL ) în baza de date.
– Pentru tipul de entită ți Mașină, num arInmatriculare nu reprezintă de asemenea un identificator bun,
deoarece în momentul schimbării domicili ului proprietarului în altă localitate este necesară și modificarea
numărului de înmatriculare.
– Pentru entitatea Localitate , atributul codPostal nu este de asemenea un identificator valid, deoarece un cod
poștal poate acoperi uneori mai multe sate sau un oraș poate avea mai multe coduri po ștale.

Fig. I.14. Cazuri de alegere în mod eronat a identificatorului unei mul țimi de entită ți

Pentru a putea rezolva toate probleme le men ționate anterior, care pot pune probleme serioase în procesul de creare a l
unui model de bază de date valid, se poate recurge la o solu ție simplă. În locul variantei de a alege un identificator
din setul de atribute asociate clasei se poate introduce un atribut suplimentar, arbitrar, de tip întreg (integer) care să
reprezinte cheia acelei clase de entităț i. Valoarea cheii va fi incrementată în mod automat în momentul inserării unei
noi instanț e. În felul acesta, se asigură constrângerea ca fiecare entitate din clasă să poată fi identificată în mod unic.

CURS BD

B. Reguli legate de alegerea numelor

R4. Numele entităț ilor, atributelor și asocierilor trebui e să fie unic.
Existen ța unor atribute cu acela și nume chiar dacă apar țin de clase de entităț i diferite poate reprezenta un semn că
modelizarea bazei de date este redundantă sau incompletă. În exemplul din Figura I.15 se poate observa că două
tipuri de entită ți dețin fiecare un atribut adresaDeFacturare , ceea ce indică faptul că în baza de date vor apărea
informa ții duplicate. Aceste situaț ii pot antrena de asemenea probleme de in coeren ță în manipularea datelor ș i prin
urmare trebuie evitate.

Fig. I.15. Cazul utilizării de atribute cu acelaș i nume – semn de redundan ță
De asemenea, este de evitat utilizarea aceluiaș i nume pentru diferite elemente , deoarece poate introduce confuzie în
momentul manipulării datelor din bază. În exe mplul din Figura I.16 atributele adresa și nume asociate celor două
clase de entită ți Client și Furnizor trebuie redenumite deoarece nu vor conț ine acelea și informa ții, iar în momentul
folosirii lor de către un utilizator neexperimentat va putea produce confuzie. Pentru a rezolva această problemă se pot
redenumi atributele astfel încât numele lor să cuprindă și numele entită ții sau asocierii de care depind. Pentru
exemplul din Figura I.16, clasa Client poate fi rescrisă astfel: Client (IDClient, numeClient, prenumeClient,
adresaClient ), iar clasa Furnizo r: Furnizor( IDFurnizor, numeFurnizor, adresaFurnizor) .

Fig. I.16. Necesitatea denumirii atribute lor în func ție de numele clasei

C. Reguli legate de normalizarea atributelor
R5. A tributele multivaloare vor fi înlocuite cu un tip de asociere ș i un tip de entitate suplimentare .

Pentru o bază de date care stochează informa ții despre angajaț ii unei companii, conceptul de nrTelefon poate fi văzut
ca un atribut simplu al clasei Angajat atâta timp cât fiecare persoană deține un singur număr de telefon. Însă, în mod
uzual orice persoană poate deț ine mai multe telefoane fixe ș i mobile. În acest caz atributul nrTelefon devine un
atribut multivaloare. Lucrul direct cu atributele multivaloare în cadrul bazelor de date este foarte dificil, de aceea se
preferă transformarea lor în entită ți care vor fi conectate cu clasa de origine prin asocieri. În Figura I.17 este
prezentată modalitatea de normalizare a atributelor multivaloare prin exemplificare cu atributele nrTelefon și adrese
CURS BD

(o persoană poate avea de asem enea mai multe re ședințe). Prin normalizare, accesul la informaț ii se poate face într –
un mod mult mai ușor și rapid.

Fig. I.17. Normalizarea atributelor multivaloare

R6. Valorile a tributelor trebuie să reprezinte date elementare.

Valorile atributelor nu trebuie să fie derivate din valorile altor atribute sau din alte informa ții care sunt stocate direct
sau indirect în baza de date. De exemplu, pentru schema din Figura I.18, atributul numarSalariati al mul țimii de
entită ți Departamente ar trebui eliminat, deoarece valoarea acestuia se poate ob ține din însumarea entită ților
asociate Angaja ți. În caz contrar, de fiecare dată când o nouă persoană este angajată în cadrul unui departament (sau
pleacă), valoarea atributului numarSalariaț i ar trebui actualizată în mod corespunzător.

Fig. I.18. Exemplu de atribut derivat (numarSalariati ) care ar trebui eliminat din modelul E/A

Un alt exemplu de atribut derivat care nu ar trebui stocat într -o bază de date este vârsta unei persoane, deoarece
valoarea acesteia poate fi calculată în orice moment pe baza datei naș terii și a datei curente.
R7. Un atribut poate fi alipit unei asocieri doar dacă acesta depinde de toate entităț ile conectate la asociere.

De exemplu, pentru schema din Figura I.19, atributul cantitate , al asocierii con ține, depinde atât de identificatorul
IDComanda al clasei Com enzi cât și de atributul IDProdus al mul țimii de entită ți Produse .

CURS BD

Fig. I.19. Alipirea atributelor la asocieri

R8. Un atribut care corespunde unei enumerări poate fi înlocuit cu o mulțime de entităț i
Atunci când un atribut poate lua o valoare dintr -un set bine stabilit de valori, spunem că este de tip enumerare. În
acest caz atributul poate fi înlocuit cu o clasă de entităț i. Pentru exemplu din Figura I.20 atributul tip al clasei de
entită ți Emisiuni poate lua valori dintr -un set precum: ( jurnal, divertisment, talk -show, reportaj, etc.). Înlocuirea
atributului tip cu o clasă de entităț i permite în acest caz și asocierea mai multor tipuri de emi siuni la o aceeaș i entitate
din mul țimea Emisiuni (exemplu: cultura și reportaj ).

Fig. I.20. Separarea atributelor de entită ți

D. Reguli legate de normalizarea tipurilor de entităț i
R9. Acolo unde este posibil, dacă se doreș te, tipurile de entită ți ar trebuie fuzionate
În cazul în care există mai multe mul țimi de entită ți care prezintă aceleaș i tipuri de atribute și au un înț eles semantic
comun, pentru simplificarea schemei conceptuale a bazei de date se poate realiza fuziunea acestora într -o singură
clasă de mul țimi. În cazul exemplului din Figura I.21, mul țimile de entită ți Neurolog , Dentist , Oftalmolog pot fi
fuzionate într -o singură clasă de entităț i, denumită Medic .

Fig. I.21. Fuziunea mul țimilor de entită ți cu introducere de atribute suplimentare ( specializare )

CURS BD

În acest caz, pentru a putea face totu și diferen ța între tipurile de medici, a fost introdus un atribut suplimentar
denumit specializare , însă acest lucru nu este neapărat necesar sau dorit întotdeau na. În exemplul din Figura 1.22,
faptul că nu se introduce un alt atribut suplimentar în urma fuziunii permite reprezentarea unei persoane atât ca
abonat cât ș i ca autor în acela și timp .

Fig. I.22. Fuziunea mul țimilor de entită ți fără introducerea de atribute suplimentare

E. Reguli legate de normalizarea tipurilor de asocieri
R10. Acolo unde este posibil, dacă se doreș te, tipurile de asocieri ar trebuie fuzionate

În cazul în care există mai multe tipuri de asocieri care unesc aceleaș i mul țimi de entită ți și care prezintă un înț eles
semantic comun, pentru simplificarea schemei conceptuale a bazei de date se poate realiza fuziunea acestora într -o
singură clasă de asocieri. Pentru exemplul din Figura I.23, asocierile furnizeazăLegume și furnizeazăFr ucte pot fi
fuzionate într -o singură clasă de asocieri, denumită furnizează.

CURS BD

Fig. I.23. Fuziunea asocierilor

R11. În cazul în care toate cardinalită țile (minime și maxime) unei asocieri sunt 1, atunci asocierea trebuie eliminată
și tipurile de entită ți adiacente, fuzionate. Un astfel de exemplu este prezentat în Figura I.24.

Fig. I.24. Fuziunea unei asocieri de tip unu- la-unu

R12. Se vor elimina asocierile redundante, care pot fi deduse din alte asocieri deja existente.

În cazul exemplului din Figura I.25, asocierea membru_in modelează apartenen ța fiecărui angajat dintr -o companie
într-o anumită echipă. Fiecare echipă este implicată într -un proiect descris de asocierea dezvoltă . Din compunerea
celor două asocieri putem afla în ce proiect este implicat fiecare angajat al companiei. Prin urmare, asocierea lucrează_la (care are exact această semnifica ție) devine redundantă ș i trebuie eliminată.
CURS BD

Fig. I.25. Fuziunea asocierilor redundante

F. Reguli legate de normalizarea ierarhiilor de generalizare/specializare

R13. Î n cazul modelului E/A -E, atributele care sunt comune tuturor subclaselor unei ierarhii de
generalizare/specializare se vor elimina din acestea ș i se vor atribui clasei părinte (exemplu: Figura I.26).

Fig. I.26. Regula de î mpăr țire a atributelor între clasa părinte și subclase
CURS BD