2.

Proiectarea bazelor de date

2.1 PROIECTAREA BD – SCHIMBAREA DE PARADIGMĂ

Structura unei BD (entităţile, atributele, relaţiile) este determinată în timpul proiectării

BD. Abordarea proiectării unei BD este diferită de cea a sistemelor pe bază de fişiere, unde totul
era dictat de nevoile aplicative ale departamentelor individuale. În cazul BD trebuie de
considerat întâi datele apoi aplicaţiile. Această schimbare a modului de tratare se numeşte
schimbare de paradigmă.
Cauza principală a eşecurilor sistemelor informaţionale este lipsa aplicării unei
metodologii de proiectare a BD în mod structurat. Astfel rezultă BD ineficiente pentru cerinţele
aplicaţiilor, documentaţia este limitată, întreţinerea dificilă.

2.1.1 Poziţiile persoanelor din mediul BD

În acest paragraf se examinează a 5-a componentă a mediului SGBD, anume persoanele.

Se pot identifica patru tipuri distincte de persoane implicate în mediul SGBD:
- administratorii de date şi de BD;
- proiectanţii de BD;
- programatorii de aplicaţii;
- utilizatorii finali.

Administratorii de date şi de BD
BD şi SGBD sunt resurse comune care trebuie gestionate ca orice resursă.
Sarcinile administratorului de date (DA = data administrator):
- responsabil cu gestionarea resurselor de date: planificarea, elaborarea şi
întreţinerea strategiilor şi procedurilor bazei de date
- responsabil cu proiectarea conceptuală/logică a BD
- consultarea şi îndrumarea managerilor superiori cu privire la direcţia de
dezvoltare a BD, a.î BD să sprijine obiectivele generale ale organizaţiei.
Administratorul de baze de date (DBA – data base administrator) este responsabil cu
realizarea fizică a BD, având următoarele sarcini:
- proiectarea şi implementarea BD,
- securitatea şi controlul integrităţii BD,
- întreţinerea sistemului operaţional,
- asigurarea de performanţe satisfăcătoare pentru aplicaţii şi utilizatori;
Rolul DBA este mai tehnic şi necesită cunoaşterea în detaliu a SGBD şi a mediului acestuia.

Proiectanţii de BD
Există proiectanţi de BD logice şi proiectanţi de BD fizice.

1
Proiectanţii de BD logice: “ce anume?”
- se ocupă cu identificarea datelor (entităţi şi atribute) şi relaţiilor dintre acestea, şi
de constrângerile asupra celor care vor fi stocate în BD;
- trebuie să cunoască foarte bine datele organizaţiei şi a regulilor de operare ale
organizaţiei;
- trebuie să implice toţi posibilii utilizatori ai BD în modelul creat.

Etape de proiectare a BD logice:

a) proiectarea conceptuală a BD, independent de detaliile de implementare (de ex. SGBD
utilizat, programele de aplicaţie, limbajele de programare etc.)
b) proiectarea logică a BD, care se bazează pe un anumit model, de ex. relaţional, ierarhic,
în reţea, orientat pe obiecte.

Proiectanţii de BD fizice (“Cum anume?”) preia modelul logic şi stabileşte realizarea fizică:
- transpunerea modelului logic de date într-un set de tabele şi constrângeri privind
integritatea;
- selectarea de structuri de stocare şi metode de acces specifice, a.î. să se obţină
performanţe bune ale datelor in activităţile legate de BD;
- măsuri referitoare la securitatea datelor.
Proiectarea fizică a unei BD trebuie să ţină cont de SGBDul avut în vedere; proiectantul trebuie
să cunoască funcţionalitatea acestui SGBD şi avantajele şi dezavantajele fiecărei variante de
implementare a BD. Strategia de stocare aleasă trebuie să ţină cont de modul de utilizare.

Programatorii de aplicaţii
Odată realizată BD trebuie implementate programele de aplicaţie ce conferă
funcţionalitatea cerută de utilizatorii finali. Aceasta este sarcina programatorilor de aplicaţii.
Fiecare program conţine instrucţiuni care îi cere SGBD să efectueze o operaţie oarecare în BD
(extragere, inserare, reactualizare, ştergere de date). Programele pot fi scrise într-un limbaj de
generaţia a treia sau a patra.

Utilizatorii finali
Sunt clienţii pentru care a fost proiectată, implementată şi este întreţinută BD, pentru a le
satisface necesităţile informaţionale.
Utilizatorii simpli nu sunt conştienţi de SGBD. Accesează BD prin programe de aplicaţie
speciale, simplificatoare. Ei folosesc comenzi simple, opţiuni din meniu. Utilizatorul simplu nu
ştie nimic despre BD sau SGBD (de ex. vânzătorul care citeşte codul de bare pentru a afla preţul
unui produs. Există totuşi un program care citeşte codul de bare, caută preţul articolului respectiv
în BD, modifică câmpul cu stocul de articole, afişează preţul la casă).
Utilizatorii sofisticaţi sunt familiarizaţi cu structura BD şi facilităţile SGBD. Pot utiliza un limbaj
de interogare de nivel înalt (SQL). Pot scrie programe de aplicaţie pentru uz personal.

2
2.2. O METODOLOGIE CLASICĂ DE DEZVOLTARE A APLICAŢIILOR

Până acum am punctat importanţa datelor în sistemul informaţional al organizaţiilor,

nivelurile la care se poate aborda structura şi conţinutul unei baze de date, precum şi locul
"stratului" date în aplicaţiile informatice actuale. În acest capitol vom încerca să încadrăm
activitatea (activităţile) de proiectare a bazei de date în demersul mai larg al dezvoltării de
aplicaţii.
De la bun început trebuie precizat că subiectul paragrafului de faţă constituie obiect de
studiu pentru cel puţin două domenii ale informaţiei aplicate în organizaţii, sau, mai bine spus,
ale sistemelor informaţionale în organizaţii. Mai întâi, este vorba de ceea ce în literatura anglo-
saxona se numeşte software engineering, în franceză genie logiciel, iar la noi dezvoltare de
aplicații software. Este un domeniu conturat încă din anii '60 şi aflat de atunci, cel puţin după
spusele marilor specialişti, într-o permanentă criză, ce nu dă semne de epuizare.
Al doilea domeniu este mai larg şi ţinteşte mult mai mult decât realizarea de aplicaţii,
deşi aceasta reprezintă totuşi un obiectiv central. Este vorba de analiza şi proiectarea sistemelor
informaţionale. Analiza şi proiectarea se ocupă, printre altele, şi cu investigarea tuturor
proceselor, operaţiunilor şi tranzacţiilor dintr-o firmă sau instituţie, cerinţelor utilizatorilor şi
perspectivelor organizaţionale, astfel încât toate aceste aspecte să fie luate în calcul în realizarea
unui sistem informaţional coerent, aliniat misiunii, obiectivelor şi politicilor firmei. Cu alte
cuvinte, analiza şi proiectarea pornesc mai din amonte, de la utilizatori, procese, tranzacţii
economice, încercând să formalizeze/modeleze realitatea sub forma unei largi game de diagrame,
scheme, specificaţii pe care le vor înainta realizatorilor modulelor de interfaţă, prelucrări şi date.
Una dintre cele mai cunoscute scheme de realizare (dezvoltare) a aplicaţiilor de lucru cu
baze de date sau, altfel spus, schema de principiu a ciclului de viaţă al aplicaţiilor cu BD este cea
rezentată în figura 2.1.
Amploarea activităţilor din ciclul de viaţă a unei BD depinde de anvergura aplicaţiei.
Când sistemul dezvoltat vizează un numar redus de utilizatori şi se referă la un ansamblu
de funcţii nu din cale-afară de complex, multe etape sunt sărite sau parcurse sumar.

Planificarea bazei de date

Planificarea BD presupune eşalonarea paşi1or ciclului de viată pentru atingerea unui

maximum de eficacitate. Ca şi în cazul planificării software-ului, planificarea BD presupune
identificarea şi evaluarea activităţilor ce trebuie derulate (întreprinse), resurselor necesare
derulării activităţilor, fondului de timp, specialiştilor şi banilor disponibili. Planificarea BD
trebuie integrată în strategia de ansamblu a firmei, unul dintre obiectivele esenţiale fiind
catalizarea activităţilor, politicilor şi strategiei unităţii.

3
 Planificarea BD

Definirea sistemului

Colectarea şi analiza cerinţelor

Proiectarea BD
Proiectarea conceptuală
Selectarea Proiectarea
SGBD aplicaţiei
Proiectarea logică

Proiectarea fizică

Prototipizare Implementare

Încărcarea şi
conversia datelor

Testare

Întreţinere operaţională

Fig. 2.1 Ciclul de viaţă a aplicaţiilor ce utilizează baze de date

Definirea sistemului

Definirea sistemului presupune specificarea domeniului şi graniţelor aplicaţiei ce

lucrează cu baza de date, utilizatorilor, aplicabilităţii sale, precum şi a celorlalte componente ale
sistemului informaţional la care se va conecta noul subsistem.

Colectarea şi analiza cerinţelor

4
 Aceasta etapă implică adunarea şi analiza cerinţelor aplicaţiilor din partea utilizatorilor.
Cerinţa reprezintă o opţiune, un element ce trebuie inclus, tratat în noul sistem. Proiectarea BD
se bazează pe informaţii despre organizaţii, informaţii ce trebuie preluate şi gestionate de bază.
Acestea pot fi culese în diferite moduri :

• intervievarea personalului din întreprindere, cu precădere a celor mai apropiaţi, prin

specificul activităţii lor, de profilul aplicaţiei, avându-se în vedere acordarea unei atenţii
mărite experţilor din compartimentele funcţionale considerate;
• observarea modului de derulare a operaţiilor în cadrul firmei ;
• examinarea documentelor, în principal a celor purtătoare de informaţii (primare,
rapoarte) ;
• folosirea chestionarelor pentru preluarea informaţiilor de la un mare număr de
utilizatori;
• utilizarea experienţei acumulate la proiectarea unor sisteme similare.

Informaţia culeasă trebuie să includă: principalele domenii (zone) şi grupuri de

utilizatori; documentaţia utilizată sau generată de şi despre aceste domenii/grupuri de utilizatori;
detaliile tranzacţiilor reclamate de fiecare domeniu/grup; o listă de cerinţe, pe priorităţi a fiecărui
domeniu/grup.
Rezultatul acestei activităţi îl reprezintă specificaţiile cerinţelor organizaţionale,
prezentate, de obicei, sub forma unui set de documente în care sunt descrise, din diferite
unghiuri, operaţiile întreprinderii. De obicei, cerinţele specificate se prezintă într-o formă puţin
structurată şi necesită transformarea utilizând tehnici consacrate, cum ar fi cele de tip SAD -
Structured Analisys and Design (analiză şi proiectare structurată), DFD - Data Flow Diagrams
(diagrame ale fluxurilor de date), diagrame HIPO - Hierarchical Input Process Output (ierarhice -
intrări-prelucrări-ieşiri) etc.

Proiectarea bazei de date

Aceasta include proiectarea logică şi fizică a BD. În urma acestei etape va fi elaborat
modelul BD care va constitui suportul obiectivelor şi operaţiunilor organizaţiei. Principalele
obiective ale proiectării BD sunt:

• reprezentarea datelor şi a relaţiilor dintre date, formulare pe diferitele zone ale aplicaţiei
şi ale grupurilor de utilizatori ;
• furnizarea unui model al datelor care să permită orice tranzacţie autorizată asupra
acestora ;
• construirea unui proiect care va atinge cerinţele de performanţă ale sistemului, cum ar
fi: securitatea, timpul de răspuns etc.

5
 Deseori însă, realizarea unui obiectiv se face în detrimentul altuia. Spre exemplu, un nivel
ridicat de securitate atrage după sine scăderea vitezei de răspuns.
Există două abordări majore ale proiectării BD. Abordarea bottom-up porneşte de la
nivelul elementar, cel al atributelor, care sunt grupate în clase de entitati şi asociaţii.
Normalizarea este un exemplu tipic de demers bottom-up, care dă rezultate bune atunci când
numărul atributelor nu este prea mare.
Când numărul de atribute este ridicat, mai nimerită este abordarea top-down, care
dezvoltă mai întâi un model sintetic, simplificat al datelor. Cele câteva entităţi sunt descompuse
ulterior în mai multe etape, până la identificarea atributelor şi entităţilor elementare. Modelarea
folosind diagrame E-R are la bază abordarea top-down.
Există şi alte abordări ale proiectării BD; spre exemplu, inside-out (de la interior către
exterior) seamănă cu bottom-up, dar diferă prin faptul că mai întâi se stabileşte un set de
concepte majore şi apoi analiza se lărgeşte prin includerea în model şi a altor concepte care se
afla în relatie cu cele majore. Strategia mixtă utilizează deopotrivă, pentru diferitele părţi ale
modelului, şi bottom-up, şi top-down, combinând rezultatele.
După cea mai mare parte a autorilor, proiectarea bazelor de date este de două tipuri,
logică şi fizică, în timp ce după alţii există trei tipuri: conceptuală, logică, fizică.

Selectarea sistemului de gestiune a bazei de date

Considerată un pas opţional, selectarea SGBD presupune alegerea celui mai adecvat
SGBD pentru realizarea şi exploatarea aplicaţiei. Nu toate SGBD-urile satisfac cerinţele
aplicaţiei, iar, pe de altă parte, cele mai performante sunt şi cele mai scumpe. Cerinţele de
funcţionalitate trebuie coroborate cu resursele disponibile, în vederea identificării celui mai
adecvat SGBD comercial pentru realizarea şi exploatarea aplicaţiei.

Proiectarea aplicaţiei

Proiectarea aplicaţiei se referă la conceperea secvenţelor de cod (instrucţiuni în limbaje

de programare) ce vor lucra cu baza. Din figura 2.1 se observă că proiectarea BD şi proiectarea
aplicaţiei sunt activităţi distincte, paralele ale ciclului de viaţă al aplicaţiilor cu BD. În cea mai
mare parte a cazurilor, proiectarea aplicaţiei nu poate fi finalizată înainte de proiectarea bazei. Pe
de altă parte, informaţiile proiectării vor fi transmise proiectării BD.
În această etapă trebuie verificat dacă toate funcţiile specificate în cerinţele utilizatorului
se regăsesc în proiectul aplicaţiei. Proiectarea aplicaţiei include şi activitatea de proiectare a
tranzacţiilor. De asemenea, tot acum se elaborează şi modelul interfeţei cu utilizatorul a
aplicaţiei.

Prototipizarea

6
 Deşi opţională, prototipizarea se poate dovedi deosebit de utilă prin construirea unui
model de lucru iniţial simplificat, model ce permite dezvoltatorilor şi utilizatorilor să testeze şi să
amelioreze incremental noua aplicaţie. Un mare avantaj al prototipizarii este gradul mult mai
mare de acceptare a noului sistem la final, acesta fiind dezvoltat împreună cu utilizatorii ce pot
să-şi exprime pe parcurs doleanţele. Etapele prototipizarii sunt descrise în figura 2.2.

Dezvoltarea modelului de lucru Repetare de câteAbandonarea

ori este necesar
aplicaţiei

Construirea prototipului Implementarea aplicaţiei

Decizie

Testarea şi utilizarea prototipului Re-dezvoltarea aplicaţiei

Revizuirea prototipului Dezvoltarea unui nou prototip

Fig. 2.2 Schema de principiu a prototipizării

Implementarea

Implementarea presupune crearea definiţiilor BD la nivelurile conceptual, extern, intern,

precum şi punerea în lucru a programelor (aplicaţiei), fiind realizată utilizând limbajul de
definire a datelor (DDL) pus la dispozitie de SGBD-ul selectat. Implementarea aplicaţiei se
realizează într-un mediu de programare utilizand un limbaj de tip 3GL sau 4GL.

Conversia şi încărcarea datelor

Acest pas este necesar atunci când sistemul (aplicaţia) dezvoltat înlocuieşte un altul.
Datele trebuie transferate din vechea aplicaţie în cea nouă, operaţie ce implică de multe ori
schimbarea structurii fişierelor, a formatului, logic şi fizic, al datelor, în concordanţă cu cerinţele
noii aplicaţii, dar şi ale noului SGBD. Uneori sunt necesare (şi posibile) şi conversii ale unor
programe din vechiul în noul sistem. Majoritatea SGBD-urilor actuale au module de import-
export din/în alte SGBD-uri. Conversia aplicaţiilor este, în general, mult mai complexă atunci
când se schimbă limbajul/mediul de programare.

Testarea
7
 Testarea este operaţiunea sistematică de verificare a funcţionalităţii sistemului, a gradului
de adecvare la cerinţele utilizatorilor. Prin testare, aplicaţia este lansată în execuţie, urmărindu-se
depistarea eventualelor erori şi ameliorarea unor parametri precum viteza, securitatea etc.
Urmând o metodologie riguroasă, măsurătorile din cadrul testării dau posibilitatea evaluării
calităţii şi fiabilităţii software-ului.
Este de preferat ca utilizatorii aplicaţiei să fie pe deplin implicaţi în procesul testării, iar
aplicaţia testată să fie instalată pe un alt sistem decât cel pe care a fost concepută; în orice caz,
trebuie avut în vedere şi un mecanism de recuperare a datelor corupte în caz de avarie.
Există mai multe strategii de testare a corectitudinii şi funcţionalităţii unei ap1icaţii de
lucru cu BD ce pot fi aplicate individual sau combinate în cadrul aceluiaşi sistem:

• top-down;
• bottom-up;
• fire de execuţie ;
• test de stres.

Testarea top-down începe de la nivelul superior al funcţiilor majore ale aplicaţiei. Este
utilă în verificarea arhitecturii sistemului, reproiectările majore fiind semnalate din primele
momente ale testării.
Testarea bottom-up începe cu modulele elementare şi continuă pe verticală cu modulele
compozite până la nivelul general al aplicaţiei.
Testarea firelor de execuţie este foarte importantă în sistemele de prelucrare în timp real,
în care sunt rulate simultan o serie de procese ce cooperează. Acest tip de testare este mult mai
complex, fiind legat de detaliile tehnice ale sistemului de operare. Fiecarui proces i se alocă un
fir de execuţie (thread) care este urmărit de la declanşarea sa, acordându-se o mare importanţă
punctelor de întâlnire cu celelalte fire executate pe sistem.
Testul de stres presupune suprasolicitarea bazei şi aplicaţiilor. Astfel, BD se încarcă
automat cu un număr extrem de mare de înregistrări, iar la aplicaţie se conectează cât mai mulţi
utilizatori. Astfel se depistează până la ce limite rezistă aplicaţia.

Întreţinerea operaţională

Această activitate se derulează pe toată durata de utilizare a aplicaţiei. În afară de

monitorizarea BD, a programelor, de "curăţarea" periodica şi repararea eventualelor erori
hard/soft, tot în această activitate sunt încorporate operaţiunile de actualizare a datelor şi
programelor (ca urmare a unor noi oportunităţi tehnologice), modificarea unor parametri
(procente TVA, impozite etc.). Monitorizarea performanţei sistemului se realizează prin
8
raportarea la un nivel prestabilit de acceptare. Dacă este cazul, o situare a performanţei generale
sub acest punct critic poate antrena reorganizarea BD. Altminteri, chiar şi în cazul funcţionării în
parametri normali, BD trebuie optimizată, având în vedere şi facilităţile oferite de SGBD.
Întreţinerea şi actualizarea aplicaţiei sunt necesare în mai mare sau mai mică măsură.
Spre exemplu, într-un mediu economic şi legislativ dinamic, cum este cel din ţara noastră,
deseori este necesară modificarea unor părţi importante ale aplicaţiei. Uneori, modificarea
presupune reluarea unora sau tuturor paşilor din ciclul de viaţă al aplicaţiei de lucru cu BD.

2.2 PRIVIRE DE ANSAMBLU ASUPRA PROIECTĂRII BAZELOR DE DATE

Deși au fost publicate destule cărți dedicate proiectării bazelor de date, subiectul continuă
să fie departe de epuizare. Chiar dacă unii autori s-au străduit să aducă rigurozitate, uneori cu
prețul unei anume rigidități, proiectarea bazelor de date rămâne preponderent o artă și mai puțin
o știință. Problema proiectarii unei baze de date ține de elaborarea unei structuri logice și a alteia
fizice în vederea întâmpinării nevoilor informaționale ale utilizatorilor într-o organizație, pentru
un set definit de aplicaţii.
Există mai multe curente de idei în ceea ce privește proiectarea bazelor de date. Unul
dintre acestea împarte procesul de proiectare în două direcții: modelarea logică a datelor și
proiectarea bazelor de date relaționale, definind modelarea logică a datelor ca procedură pentru
reprezentarea cerințelor informaționale într-un format corect, consistent și stabil, iar proiectarea
BD relaționale drept procedură de transformare a modelului logic al datelor într-o schemă
relațională stabilă. Aici apare o inadvertență, considerându-se că o schemă relațională alcătuită
din tabele și restricțiile la care sunt supuse datele din tabele nu ar corespunde nivelului logic al
bazei de date, ci nivelului fizic. În această abordare, metodologia de modelare logica a datelor
(MLD) se deruleaza în 12 paşi:
1. identificarea entităților majore ;
2. determinarea relațiilor dintre entități;
3. determinarea cheilor primare şi alternative;
4. determinarea cheilor străine;
5. determinarea celor mai importante reguli organizaționale (key business rules) ;
6. adăugarea celorlalte atribute (atributele non-cheie) ;
7. validarea perspectivelor utilizatorului folosind normalizarea ;
8. determinarea domeniilor (restricțiilor asupra valorilor autorizate ale atributelor) ;
9. determinarea operațiunilor declanşatoare (regulile care guvernează efectele
modificărilor asupra atributelor şi entităților) ;
10. combinarea perspectivelor utilizatorului;
11. integrarea cu modelele de date existente ;
12. analiza stabilității şi dezvoltărilor ulterioare.

9
 Este evident că, deşi se separă artificial proiectarea logică a bazei de date de proiectarea
bazei de date relaționale, o parte dintre paşii modelării logice sunt raportați explicit la modelul
relațional. Perspectiva poate fi explicată prin faptul că, la nivelul anilor ‘80, modelul suveran în
materie de gestiune a bazelor de date era cel relațional (suveranitate manifestată din plin şi
astăzi), iar SGBD-urile ce puteau exploata baze de date obiectuale erau ca şi inexistente.
Cea de a doua direcție, proiectare a bazei de date relaționale (PBDR), care continuă
operațiunile derulate în MLD, presupune următorii pași:

1. identificarea tabelelor ;
2. identificarea atributelor;
3. adaptarea structurii datelor la specificul SGBD-ului folosit ;
4. inventarierea regulilor organizaționale privind entitățile;
5. inventarierea regulilor organizaționale privind relațiile (asociațiile) dintre entități ;
6. inventarierea regulilor adiționale despre atribute ;
7. optimizarea structurii în vederea unui mecanism de acces cât mai eficient ;
8. definirea secvenţelor de "înmănunchiere" (clustering);
9. definirea cheilor pentru calcularea adreselor logice ale înregistrărilor în tabele (hash
keys) ;
10. adăugarea indexurilor;
11. adăugarea de date redundante;
12. redefinirea coloanelor;
13. redefinirea tabelelor.

Literatura de specialitate și practica se raportează însă preponderent la doar două

componente majore ale proiectarii bazelor de date: proiectarea logica și proiectarea fizică. Din
acest punct de vedere, cele 12 etape din MLD și primele 6 din așa-numita PBDR ar corespunde,
în linii mari, proiectării logice a bazei, în timp ce etapele următoare (7-13) din PBDR -
proiectării fizice.
O altă abordare, structurează ciclul de viață al bazelor de date pe următoarele etape:

1. analiza cerinţelor;
2. proiectarea logică, ce se materializează în schema globală ce conține datele și relațiile
dintre ele, fiind derulată astfel :
a) modelarea E-R;
b) integrarea perspectivelor utilizator;
c) conversia diagramelor E-R în tabele;
d) normalizarea tabelelor ;
3. proiectarea fizică: selectarea indexurilor, metodelor de acces, cluster-elor de date; tot
aici, se include și denormalizarea;

10
 4. distribuirea datelor, materializată în schema de fragmentare și schema de alocare a
datelor ;
5. implementarea, monitorizarea și modificarea ulterioară a bazei de date. Și aici apar
dubii legate de modul de derulare a normalizării (2.d), o dată ce prin conversia
diagramelor E-R se obțin deja tabelele relaționale (2.c).

Ambele abordări sunt legate îndeosebi de paradigma relațională folosind în primele etape
modelul E-R, mai apropiat de lumea reală.
Mai nou, proiectarea bazelor de date este privită pornind de la cele trei modele în vogă
astăzi: relațional, obiectual şi relațional-obiectual. Din această perspectivă, procesul proiectării
bazelor de date este prin excelență unul iterativ, incremental, într-o măsura cu atât mai mare cu
cât ne apropiem de obiectual. Fiecare iterație se materializează într-o formă a schemei bazei,
pornindu-se de la modelare, apoi trecându-se de la proiectare la construcție (implementare). Cu
toate acestea, activitățile principale ale ciclului de viață al bazei de date nu diferă prea mult, cel
puțin la nivel general:

• analiza cerinţelor informaționale;

• modelarea datelor ;
• proiectarea şi optimizarea bazei de date (proiectare logică și fizică) ;
• testarea și revizuirea bazei ;
• certificarea bazei de date;
• întreținerea şi ameliorarea bazei.

Specifică acestei dezvoltări este activitatea de certificare a bazei care se constituie ca un

fel de atestat de bună funcționare acordat bazei, atestat menit a întări încrederea beneficiarilor
bazei.
În altă idee recentă se definesc trei componente ale proiectării bazelor de date:
proiectarea conceptuală, ce ține de construirea unui model informațional independent de orice
considerent privind aspectul fizic al datelor; proiectarea logică, ce constă în construirea unui
model informațional pe calapodul unui model de date consacrat (E-R, relaţional, OO, OR), dar
independent de tipul SGBD-ului ales şi de celelalte aspecte fizice ale modelului; proiectarea
fizică, ce se materializează în implementarea efectivă a bazei pe suportul de stocare, inclusiv
aspecte ce țin de asigurarea unui acces eficient şi a securității.
În acest curs, alegând varianta mai simplă, cu cele două tipuri de proiectare, logică şi
fizică, vom discuta aproape exclusiv despre proiectarea logică.
2.3 CONSTRUIREA DE DIAGRAME ENTITATE-RELAŢIE

Prima etapă pentru realizarea unei baze de date constă în analiza sistemului. Se cunosc
mai multe tehnici de analiză, dar cea mai des întâlnită este tehnica entitate-relaţie.

11
 Prin tehnica entiate-relaţie (denumită şi entitate-asociere) se construieşte o diagramă
entiate-relaţie (notată E-R) prin parcurgerea următorilor paşi:
a) identificarea entităţilor (componentelor) din sistemul proiectului;
b) identificarea asocierilor (relaţiilor) dintre entităţi şi calificarea lor;
c) identificarea atributelor corespunzătoare entităţilor;
d) stabilirea atributelor de identificare a entităţilor.

a) Identificarea entităţilor

Prin entitate se înţelege un obiect concret sau abstract reprezentat prin proprietăţile sale.
Prin convenţie, entităţile sunt substantive, se scriu cu litere mari şi se reprezintă prin
dreptunghiuri. Într-o diagramă nu pot exista două entităţi cu acelaşi nume, sau o aceeaşi entitate
cu nume diferite.
Pentru o bază de date din domeniul imobiliar, se pot pune în evidenţă următoarele
entităţi:
- DATE_PERSOANĂ – entitate care stochează date personale ale ofertantului
(vânzătorului) sau ale clientului (cumpărătorului);
- CERERI_ OFERTE – conţine ofertele sau cererile imobiliare propuse de vânzători,
respectiv cumpărători;
- DESCRIERE_IMOBIL – stochează informaţiile referitoare la imobile;
- JUDEŢE – entitate ce conţine judeţele în care sunt amplasate imobilele;
- LOCALITĂŢI - entitate ce conţine localităţile în care sunt amplasate imobilele;
- STRĂZI - entitate ce precizează străzile în care sunt amplasate imobilele;
- FACTURI – formularul necesar unei tranzacţii de cumpărare-vânzare.
Figura următoare prezintă o primă formă a diagramei entitate-asociere (E-R).

DATE_ PERSOANA FACTURI

LOCALITATI
CERERI_ OFERTE

JUDETE

DESCRIERE_IMOBIL
STRAZI

Fig. 2.3. Diagrama E-R pentru domeniul imobiliar (prima formă)

b) Identificarea asocierilor dintre entităţi şi calificarea lor

Între majoritatea componentelor (adică a entităţilor) unui sistem economic se stabilesc

legături (asocieri).

12
Exemplu: Există o asociere între entităţile CERERI_OFERTE şi FACTURI deoarece facturile
reprezintă finalizarea unei cereri/oferte. Această asociere se reprezintă ca în figura de mai jos.

(1,1) (0,1)
CERERI_OFERTE sunt finalizate FACTURI
prin

Fig. 2.4. Prezentarea asocierii dintre entităţile CERERI_OFERTE şi FACTURI

Sunt necesare precizarea câtorva notaţii şi noţiuni utilizate în exemplul de mai sus:
- legăturile (asocierile) se reprezintă prin arce neorientate între entităţi;
- fiecărei legături i se acordă un nume plasat la mijlocul arcului şi simbolizat printr-un
romb (semnificaţia legăturii);
- numerele simbolizate deasupra arcelor se numesc cardinalităţi şi reprezintă tipul
legăturii;
- cardinalitatea asocierilor exprimă numărul minim şi maxim de realizări a unei entităţi
cu cealaltă entitate asociată.
Exemplu: Cardinalitatea (1,1) ataşată entităţii CERERI_OFERTA înseamnă că o factură poate fi
rezultatul tranzacţionării a minim unei cereri/oferte şi a unui număr maxim de tot o cerere/ofertă.
Cardinalitatea (0,1) ataşată entităţii FACTURI înseamnă că o cerere se poate finaliza prin maxim
o factură sau prin nici una (0 facturi) . Această cardinalitate reiese din analiză:

CERERI_OFERTE FACTURI
1 F1
2 F2
3

Fig. 2.5. Determinarea cardinalităţii asocierii dintre entităţile CERERI_OFERTE şi

FACTURI

Maximele unei cardinalităţi sunt cunoscute şi sub denumirea de grad de asociere, iar
minimele unei cardinalităţi, obligativitatea participării entităţilor la asociere.

Tipuri de asocieri (legături) între entităţi

Asocierile pot fi de mai multe feluri, iar odată cu asocierea, se impune stabilirea
calificării acesteia. Asocierea dintre entităţi se face în funcţie de
i) cardinalitatea asocierii;
ii) numărul de entităţi distincte care participă la asociere.
i. După cardinalitatea asocierii

13
 În funcţie de maxima cardinalităţii (gradul de asociere), se cunosc trei tipuri de asocieri,
care, la rândul lor, sunt de două tipuri, în funcţie de minima cardinalităţii (gradul de obligativitate
al participării la asociere):
 asocieri de tip „unu la unu”;
o asocieri parţiale de tip „unu la unu”
o asocieri totale de tip „unu la unu”
 asocieri de tip „unu la mai mulţi”
o asocieri parţiale de tip „unu la mulţi”
o asocieri totale de tip „unu la mulţi”
 asocieri de tip „mulţi la mulţi”
o asocieri parţiale de tip „mulţi la mulţi”
o asocieri totale de tip „mulţi la mulţi”.
ii. După numărul de entităţi distincte care participă la asociere:
 asocieri binare (între două entităţi distincte);
 asocieri recursive (asocieri ale entităţilor cu ele însele);
 asocieri complexe (între mai mult de două entităţi distincte).
În continuare se descriu asocierile grupate după cardinalitatea ei.

Asocieri în funcţie de cardinalitatea legăturii

1. Asocieri de tip „unu la unu” sunt asocieri în care maximele cardinalităţii au

valoarea 1.

E1 (...,1) A (...,1) E2

Fig. 2.6. Asociere de tip unu la unu

Exemplu: Asocierea din figura 2.5 este asociere de tip „1 la 1”.

2. Asocieri de tip „unu la mai mulţi” sunt asocieri în care maxima cardinalităţii
unei entităţi este unu, iar a celeilalte entităţi are valoarea „mulţi”.

(...,1) (...,n) (...,n) (...,1)

E1 A E2 E1 A E2

Fig. 2.7. Asociere de tipul unu la mai mulţi

Exemplu:

14
 A B
LOCALITATI CERERI_OFERTE
L1 1
L2 2
L3 3

(1,1) îi corespunde
(0,n)
LOCALITATI CERERI_OFERTE

Fig. 2.8. Asociere de unu la mai mulţi între entităţile LOCALITĂŢI şi CERERI_OFERTE

3. Asocieri de tipul „mulţi la mulţi” sunt asocieri în care maximele cardinalităţii au

valoarea „mulţi”.

E1 (...,n) A (...,n) E2

Fig. 2.9. Asociere de tipul mulţi la mulţi

Exemplu:

DEPOZIT PRODUS
D1 P1
D2 P2
D3 P3

(0,n) (0,n)
DEPOZIT În magazie PRODUS
nează

Fig. 2.10. Asociere de tipul mulţi la mulţi între entităţile DEPOZIT

şi PRODUS

Observaţie: Uneori (în cazul utilizării unor SGBD), asocierea de tip „mulţi la mulţi” se
transformă în două asocieri de tipul „unul la mulţi” fiind, de regulă, mai uşor de implementat şi
de utilizat şi anume:

15
 (...,n) (...,n) (...,1) (...,n) (...,n) (...,1)
Din E1 A E2 în E1 A1 E’ A2 E2

a) b)
Fig. 2.11. Transformarea unei asocieri de tipul mulţi la mulţi (a)
în asocieri de tipul unu la mulţi (b)

Exemplu: În cazul exemplului de mai sus (vezi figura 2.10), transformarea asocierii „mulţi la
mulţi” în asocieri de tipul „unu la mulţi” se poate realiza prin construirea unei noi entităţi
DEPOZIT_PRODUS astfel:

DEPOZIT_
PRODUS PRODUS
D1-P1 P1
DEPOZIT
(0,1) (0,n) D1-P3 (0,n) (0,1) P2
D1 asociază asociază
D2-P1 P3
D2
D3-P4 P4
D3
D4

Fig. 2.12. Transformarea asocierii de tipul mulţi la mulţi în asocieri de tipul unu la mulţi

Asocieri parţiale şi totale

Printr-o asociere parţială se înţelege o asociere în care nu există obligativitatea

participării la această asociere a tuturor entităţilor vizate, ci numai a unora dintre ele sau a nici
uneia. Asocierea parţială se caracterizează prin faptul că minima cardinalităţii ataşată unei
entităţi este zero.
Observaţii (asupra minimei cardinalităţii)
- minima cardinalităţii este zero, are drept rezultat lipsa obligativităţii participării
partenerului la această asociere;
- minima cardinalităţii este mai mare decât zero, are drept rezultat obligativitatea
participării.

(0,…) (…,…) (…,…) (0,…)

E1 A E2 E1 A E2

a) b)
Fig. 2.13 Asocieri parţiale între entităţile E1 şi E2
Exemplu: Asocierea dintre entităţile CERERI_OFERTE şi FACTURI din fig. 2.5 reprezintă o
asociere parţială, deoarece participarea entităţii FACTURI nu este obligatorie, minima
caracteristicii corespunzătoare entităţii CERERI_OFERTE fiind 0.

16
 O asociere este totală dacă toate entităţile au obligativitatea să participe la asociere, adică
minima cardinalităţii este mai mare decât zero.

(1,…) (1,…)
E1 A E2
a)

(1,…) (n,…) (n,…) (1,…)

E1 A E2 E1 A E2
b) c)

(n,…) (n,…)
E1 A E2
d)

Fig. 2.14 Asocieri totale între entităţile E1 şi E2

În continuare se dau câteva exemple de asocieri totale, respectiv parţiale.

Exemplu: Asocieri parţiale de tip unu la unu

CERERI_OFERTE FACTURI
1 F1
2 F2
3

Exemplu: Asocieri totale de tip unu la unu

CERERI_OFERTE DESCRIERE_IMOBIL
1 I1
2 I2
3 I3

Exemplu: Asocieri parţiale de tip unu la mulţi

17
 LOCALITATI CERERI_OFERTE
L1 1
L2 2
L3 3

Exemplu: Asocieri totale de tip unu la mulţi

ELEVI
CLASE
E1
C1
E2
C2
E3
C3
E4

Exemplu: Asocieri parţiale de tip mulţi la mulţi

DEPOZIT PRODUS
D1 P1
D2 P2
D3 P3
D4

Exemplu: Asocieri totale de tip mulţi la mulţi

STUDENTI
CURSURI S1
C1 S2
C2 S3
C3 S4

Fig. 2.13 Asocieri după gradul şi obiectivitatea lor

În exemplul bazei de date AGENTIE_IMOBILIARA, tipurile de asocieri dintre entităţi

stabilite în funcţie de modul în care se desfăşoară activitatea modelată sunt:

18
 - JUDETE-LOCALITATI 1:n – deoarece unui judeţ îi corespund mai multe
localităţi;
- LOCALITATI-STRAZI 1:n - deoarece unei localităţi îi corespund mai multe
străzi;
- STRAZI-CERERI_OFERTE 1:n – deoarece unei străzi îi pot corespunde mai
multe oferte/cereri;
- FACTURI-CERERI_OFERTE 1:1 – deoarece fiecare factură conţine doar câte o
ofertă/cerere;
- CERERI_OFERTE-DECRIERE_IMOBIL 1:1 – fiecărei cereri i se face o singură
descriere de imobil;
- FACTURI- DATE_PERSOANA 1:1 – o factură este încheiată de o singură
persoană;
- DATE_PERSOANA -CERERI 1:n – o persoană poate lansa mai multe cereri sau
oferte de imobil.

c) Identificarea atributelor entităţilor şi a asocierilor dintre entităţi

Atributele unei entităţi reprezintă proprietăţi ale acestora. Atributele sunt substantive, iar
pentru fiecare atribut i se va preciza tipul fizic (integer, float, char, string etc.)
Exemplu: Entitatea LOCALITĂŢI are următoarele atribute: codul localităţii, notat „cod_loc”,
simbolul de identificare al judeţului „simbol_judeţ” şi denumirea localităţii „nume_loc”.

d) Stabilirea atributelor de identificare a entităţilor

Un atribut de identificare (numit cheie primară), reprezintă un atribut care se

caracterizează prin unicitatea valorii sale pentru fiecare instanţă a entităţii.
În cadrul diagramei entitate-asociere, un atribut de identificare se marchează prin
subliniere sau prin marcarea cu simbolul # plasat la sfârşitul numelui acestuia.

a E a# E
(a) (b)

Fig. 2.16. Notaţii uzuale pentru atributele de identificare

Exemplu: Ca atribut de identificare putem considera codul numeric personal „cnp” pentru
entitatea DATE_PERSOANĂ.
Pentru ca un atribut să fie atribut de identificare, acesta trebuie să satisfacă unele cerinţe:
- oferă o identificare unică în cadrul entităţii;
- este uşor de utilizat:
- este scurt (de cele mai multe ori, atributul de identificare apare şi în alte entităţi, drept
cheie externă).

19
 Pentru o entitate pot exista mai multe atribute de identificare, numite atribute (chei)
candidate. Dacă există mai mulţi candidaţi cheie se va selecta unul, preferându-se unul cu valori
mai scurte şi mai puţin volatile.

Exemplu: În urma analizării celor 4 etape necesare construirii diagramei entitate-asociere:

 identificarea entităţilor domeniului sau a sistemului economic;
 identificarea asocierilor dintre entităţi;
 identificarea atributelor aferente entităţilor şi asocierilor dintre acestea;
 stabilirea atributelor de identificare a entităţilor,
se poate prezenta forma completă a diagramei asociate domeniului ales în exemplu.

(0,n) (1,1) (0,n) (1,1)

STRAZI are asociată LOCALITATI are asociată JUDETE

(1,1)

se regăseşte

(1,n)

DATE_PERSOANA
(1,1)
CERERI_ OFERTE (1,n) conţin
(1,1)
incheie
(1,1) (0,1)
(1,1)
finisate (0,1) FACTURI

conţin

(1,1)

DESCRIERE _IMOBIL

Fig. 2.17. Diagrama E-R pentru domeniul imobiliar (a doua formă)

În cazul în care se doreşte o diagramă care să conţină şi atributele fiecărei entităţi însoţite
de precizarea atributelor de identificare (adică a cheilor primare), pentru a nu încărca imaginea,
diagrama proiectului se poate fragmenta pe mici domenii, după cum este cazul entităţii
OFERTE, prezentat în figura 2.18. (S-au considerat un număr relativ mic de atribute).

20
 id_co#

tipul

cnp

data_inreg

cod_loc
CERERI_OFERTE
id_strada

nr_imobil

pret_min

pret_max

tip_solutionare

Fig. 2.18. Reprezentarea atributelor aferente entităţii CERERI_OFERTE (detaliu dintr-o

diagramă E-R)

În reprezentarea atributelor aferente entităţii CERERI_OFERTE semnificaţia atributelor

este următoarea: cheia primară a entităţii „id_co” reprezintă numărul de ordine al cererii sau
ofertei de imobil lansată de o anumită pesoană, atributul „tipul” specifică dacă este vorba de o
cerere sau de o ofertă, prin „cnp” se precizează codul numeric personal al clientului,
„data_inreg” reprezintă data la care s-a înregistrat oferta/cererea, apoi uremază câteva date legate
de imobil: codul străzii „id_strada”, numărul imobilului „nr_imobil”, preţul minim, respectiv
preţul maxim al imobilului „pret_min”, „pret_max”. Ultimul atribut, „tip_solutionare” precizează
dacă cererea/oferta respectivă a fost soluţionată; pentru o cerere/oferta nou introdusă, acest
atribut se va completa cu explicaţia de ”nesoluţionat”.
Astfel, diagrama bazei de date AGENŢIE IMOBILIARĂ conţine 7 entităţi a căror
asociere a fost prezentată în figura 2.19.

21
DATE_PERSOANA STRĂZI LOCALITATI JUDETE
cnp# id_strada# cod_loc# simbol_judet#
numele cod_loc# simbol_judet nume_judet
adresa nume_str nume_loc
nr_telefon _
email
banca_client
nr_cont_client

CERERI-OFERTE DESCRIERE_IMOB IL
id_co # id_co#
tip tip_imobil
cnp etaj
data_inreg nr_camere
tip_solutionare suprafata
FACTURI cod_loc garaj
nr_factura# id_strada centrala_termica
id_oferta nr_imobil termopane
data_factura pret_min
cnp pret_max
pret
TVA
total

Fig. 2.19. Baza de date AGENŢIE IMOBILIARĂ- entităţi şi atribute

2.3.1 Reprezentarea constrângerilor de participare în diagramele E-R

Constrângerile de participare determină dacă existenţa unei entităţi depinde de legătura
sa de altă entitate prin intermediul unei relaţii.

22
 Există două tipuri de constrângeri de participare (a unei entităţi într-o relaţie):
- participare totală sau obligatorie (reprezentată printr-o linie dublă)
- participare parţială sau opţională (reprezentată printr-o linie simplă).

Participarea unei entităţi într-o relaţie este totală, dacă existenţa unei entităţi necesită
(este condiţionată de) existenţa altei entităţi prin intermediul unei anumite relaţii. Altfel
participarea este parţială.
Exemplu. În relaţia binară FILIALA Este Alocat PERSONAL (fig. 2.20) o filială poate
exista, evident, numai dacă are alocat personal. Deci existenţa entităţii FILIALA este
condiţionată de existenţa entităţii PERSONAL. Ca urmare entitatea FILIALA va participa total
(obligatoriu) în relaţia Este Alocat, şi se va reprezenta cu linie dublă.

Conform regulilor de afaceri

Nr. Filiala Nr. Personal ale organizaţiei, pot însă
exista membri de personal
care nu sunt alocaţi unei
anumite filiale. Entitatea
PERSONAL va avea deci
1 M participare parţială
FILIALA Este Alocat PERSONAL (opţională) în relaţia Este
Alocat, şi se va reprezenta cu
linie simplă.
Fig. 2.20. Constrângeri de participare

O reprezentare alternativă a
Nr. Filiala Nr. Personal
constrângerilor de
participare rezultă din fig.
2.21, unde pe liniile de
legătură sunt trecute
valorile minimă şi maximă
(5,N) (0,1) cu care pot participa
FILIALA Este Alocat PERSONAL
entităţile în relaţie.

Fig. 2.21 Constrângeri de participare, notaţie alternativă

În cazul exemplului, o filială poate avea minim 5 şi maxim nedefinit (N) angajaţi. Un
angajat poate să nu fie alocat unei filiale (valoare minimă 0) sau să fie alocat unei filiale, şi
numai uneia (valoare maximă 1).

23
2.3.2 Problemele modelului ER

În proiectarea unui model de date conceptual pot apărea aşa-numite capcane de

conectare, datorită interpretării eronate a sensului unei relaţii.

2.3.2.1 Capcane în evantai

Capcanele în evantai sunt acele capcane de conectare care într-un model ER reprezintă
o relaţie dintre tipuri de entităţi, dar căile dintre anumite apariţii ale entităţilor sunt ambigue.

SECŢIE
1 1 Capcanele în evantai apar când două sau mai multe
relaţii 1:M provin din aceeaşi entitate (fig. 2.22).

Din model nu rezultă la ce filială este alocat un anumit

Este alocat Coordonează membru al personalului dintr-o secţie, ştiind că o
secţie coordonează mai multe filiale.
M M

PERSONAL FILIALA

Fig. 2.22 Capcană în evantai

Examinăm modelul la nivel de apariţii individuale prin intermediul reţelei semantice (fig.
2.23).

Entităţile PERSONAL
Relaţia Este alocat Entităţile SECŢIE Relaţia Coordonează Entităţile FILIALA

r1 r4
SA1 F1
S1

r2 r5 F2
SA2

SA3 r3 S2 r6 F3

Fig. 2.23. Reţeaua semantică a modelului ER din fig. 2.22

Se poate observa capcana în evantai: Angajatul SA1 este alocat secţiei S1, dar secţia S1
coordonând filialele F1 şi F3, nu se ştie la care dintre aceste două filiale este alocat SA1.

24
 FILIALA
Capcana se rezolvă prin restructurarea modelului ER,
M 1
a.î. acesta să reprezinte corect asocierile dintre entităţi
(fig. 2.24).
Coordonează Este alocat Se observă care secţie coordonează care filiale, şi ce
personal este alocat fiecărei filiale.

1 M

SECŢIE PERSONAL

Fig. 2.24. Model ER restructurat

Reţeaua semantică a modelului restructurat (corect) este cea din fig. 2.25.

Entităţile SECŢIE Relaţia Coordonează Entităţile FILIALA Relaţia Este alocat Entităţile PERSONAL

r4 r1
S1 F1 SA1

r5 r2
F2 SA2

S2 r6 r3 SA3
F3

Fig. 2.25. Reţeaua semantică a modelului ER din fig. 2.24.

Angajatul SA1 este alocat filialei F1, coordonată de secţia S1.

2.3.2.2 Capcane de întrerupere

Capcanele de întrerupere sunt acele capcane de conectare în care un model sugerează

existenţa unei relaţii între tipurile de entităţi, dar nu există căi între anumite apariţii ale acestor
entităţi.

25
 Capcanele de întrerupere apar când în calea prin care sunt legate entităţile intervine o
entitate cu participare parţială.

Exemplu. Din modelul din fig. 2.26 se observă următoarele:

Pe ramura din stânga:

- unei singure filiale îi sunt alocaţi mai mulţi angajaţi (relaţie 1:M)
- filiale există numai dacă are personal, fiecare membru al personalului este
obligatoriu alocat unei filiale (participări totale – linii duble de legătură).

Pe ramura din dreapta:

- Un angajat (membru al personalului) poate superviza mai multe proprietăţi, o proprietate

poate fi supravegheată de un membru al personalului (relaţie 1: M)
- Nu fiecare membru al personalului supraveghează obligatoriu proprietăţi şi nu toate
proprietăţile sunt supravegheate obligatoriu de un membru al personalului (participări
parţiale – linii simple de legătură).

PERSONAL
Din M 1 modelul din fig. 2.26 nu se poate deduce ce
proprietăţi sunt disponibile la care filiale.

Este alocat Supervizează

1 M Fig. 2.26 Capcană de

întrerupere
FILIALA Proprietate de închiriat

Modelul ER sugerează existenţa unei relaţii între entităţile FILIALA şi

PROPRIETATE_DE_ÎNCHIRIAT, dar, aşa cum rezultă din reţeaua semantică asociată (fig.
2.27) nu există căi între anumite apariţii ale entităţilor.

Entităţile PROPRIETATE_DE_ÎNCHIRIAT

Entităţile FILIALA Relaţia Este alocat Entităţile PERSONALRelaţia Supervizează

r1 r4
26SA1 P1
F1

F2 r2
SA2 P2
 F3 r3 r5 P3
SA3

Fig. 2.27. Reţeaua semantică a modelului ER din fig. 2.26.

Lipsa căilor între anumite apariţii ale entităţilor FILIALA şi Proprietate_de_Inchiriat se

observă clar din reţeaua semantică din figura 2.27.

Nu se poate deduce la ce filială este disponibilă proprietatea P2.

Participarea parţială a entităţilor PERSONAL şi PROPRIETATE_DE_ÎNCHIRIAT în

relaţia Supravegheaza are ca efect faptul că unele proprietăţi nu pot fi asociate cu o filială prin
intermediul unui membru al personalului.

Pentru rezolvarea acestei capcane de întrerupere trebuie identificată relaţia care lipseşte. Aceasta
PERSONAL este relaţia Are dintre
M 1 entităţile FILIALA şi

Este alocat Supervizează

M
1
PROPRIETATE_DE_ÎNCHIRIAT
FILIALA Are
PROPRIETATE_DE_ÎNCHIRIAT.
Se restructurează modelul ER, introducând relaţia nou identificată Are între entităţile între care
lipseau căile (fig. 2.28).

Fig. 2.28. Model ER restructurat pentru eliminarea capcanei de întrerupere.

Entităţile PROPRIETATE_DE_ÎNCHIRIAT
Entităţile FILIALA Relaţia Este alocat Entităţile PERSONAL Relaţia Supervizează
27

r1 r4
F1 SA1 P1
 F2 SA2 P2

F3 r3 r5 P3
SA3

Relaţia Are

r1

r2

r3

Fig. 2.29. Reţeaua semantică a modelului ER restructurat din fig. 2.28.

Acum la nivelul apariţiilor individuale, adică din reţeaua semantică, se poate stabili că
proprietatea P2 este disponibilă la filiala F2 (fig. 2.29).

28
 3. MODELUL RELAŢIONAL
3.1 Terminologie

3.1.1 Structura relaţională a datelor

Relaţie: o relaţie este un tabel cu coloane şi rânduri.

Atribut: Un atribut este o coloană a unei relaţii, cu o anumită denumire.

Domeniu: Un domeniu este mulţimea de valori permise pentru unul sau mai multe atribute. Pentru fiecare
atribut se defineşte în mod central denumirea domeniului, sensul acestuia şi domeniul de definiţie. Ca urmare
sistemul va evita operaţiile incorecte semantic. (De ex. compararea unui număr de telefon cu nr. de casă, deşi
ambele sunt şiruri de caractere; însă: nr. luni este legal de înmulţit cu salariile, deşi primele sunt caractere text,
iar celelalte sunt valori monetare).

Exemplu:

Atribut Denumirea Sensul Domeniul de definiţie

domeniului
(cap de coloană)

Localitatea Localitatea Mulţimea tuturor denumirilor Caracter: dimensiune 20

de localităţi din România

Nr tel Numere telefon Mulţimea tuturor numerelor de Caracter: dimensiune 14

telefon din România

Tuplu: Un tuplu este un rând dintr-o relaţie.

Intensitatea unei relaţii: structura tabelului, specificarea domeniilor şi a altor restricţii referitoare la valorile
posibile. Intensitatea este de regulă fixă/fixată.

Extensia (starea) unei relaţii: tuplurile, care se modifică în timp.

Grad: Gradul unei relaţii reprezintă numărul de atribute pe care îl conţine. O relaţie cu două atribute, de
exemplu, se numeşte binară.

29
Cardinalitate: cardinalitatea unei relaţii este numărul de tupluri conţinute de aceasta.

Baza de date relaţională: Un set de relaţii normalizate. O BDR constă din relaţii structurate adecvat.

3.1.2 Relaţii matematice

Pentru a înţelege sensul termenului de relaţie revedem unele concepte matematice.

Produsul cartezian:

D1 x D2;

D1 = {2, 4}; D2 = { 1, 3, 5};

D1 x D2 = {(2,1); (2,3); (2,5); (4,1); (4,3); (4,5)}

Orice submulţime a produsului cartezian este o relaţie:

de ex. R = {(2,1); (4,1)}, adică: R = {(x,y)| x  D1, y  D2 şi y = 1}

sau:

S = {(x,y)| x  D1, y  D2 şi x = 2y}, adică S ={(2,1)}

X Di
În general scriem produsul cartezian a n mulţimi ca fiind: i=1

Fiecare element al produsului cartezian va fi un n-tuplu, adică este format din n elemente, câte unul din
fiecare mulţime de la 1 la n. Orice submulţime a acestui produs cartezian, adică orice mulţime de n-tupluri
reprezintă o relaţie a celor n mulţimi (care formează produsul cartezian).

3.1.3 Relaţii în bazele de date

Schema de relaţie: O denumire a relaţiei, urmată de un set (mulţime) de perechi formate din atribute şi
denumiri de domenii.

30
 Fie o relaţie R cu atributele Ai cu domeniile corespunzătoare Di, i=1,n.

Relaţia R va fi definită de schema de relaţie S= {A 1:D1, A2:D2, ..., An:Dn}.

Fiecare înregistrare (tuplu) din acest tabel (relaţie) va fi descrisă prin n coloane (atribute), va fi deci un n-
tuplu, fiecare atribut (Ai , i=1,n) luând o valoare (di , i=1,n) din domeniul corespunzător (D i , i=1,n). Deci di  Di.

Un n-tuplu al relaţiei (o înregistrare din tabel) va avea deci forma: (A 1:d1, A2:d2, …, An:dn).

Fiecare element din acest n-tuplu este format dintr-un atribut şi valoarea lui.

Relaţia va fi deci o mulţime (un set) de astfel de n-tupluri.

Când relaţia R se scrie sub formă de tabel, atributele (A i) vor fi capetele de coloane, iar tuplurile (n-
tuplurile) vor fi rândurile, de forma d1, d2, …, dn.

Astfel, o relaţie din modelul relaţional este o submulţime al produsului cartezian al domeniilor
atributelor. Tabelul este o reprezentare fizică a unei astfel de relaţii.

3.1.4 Proprietăţile relaţiilor

- fiecare relaţie are o denumire, diferită de toate celelalte denumiri de relaţii;

- fiecare celulă a relaţiei conţine exact o valoare atomică (singulară); este ilegală trecerea de mai multe
valori într-o celulă;

- fiecare atribut are o denumire distinctă;

- toate valorile unui atribut aparţin aceluiaşi domeniu;

- ordinea atributelor nu are nici o importanţă;

- fiecare tuplu este distinct; nu există dubluri ale tuplurilor;

- teoretic, ordinea tuplurilor nu are nici o importanţă (în practică poate afecta eficienţa accesării
tuplurilor).

Aceste proprietăţi rezultă din proprietăţile relaţiilor matematice:

- din moment ce relaţia este o mulţime, ordinea elementelor nu are importanţă; deci ordinea tuplurilor
nu are importanţă;

- într-o mulţime nu se repetă nici un element; deci nu există tupluri duble.

31
3.1.5 Chei relaţionale

Trebuie să existe posibilitatea de identificare unică a unui tuplu dintr-o relaţie, prin valorile atributelor
sale.

Supercheia: Este un atribut sau un set de atribute care identifică în mod unic un tuplu din interiorul unei relaţii.

O supercheie poate conţine şi atribute care nu sunt necesare identificării unice a tuplului.

Cheia candidat: este o supercheie minimă, pentru care nici o submulţime nu este supercheie în cadrul relaţiei
respective.

O cheie poate include mai multe atribute, caz în care se numeşte cheie combinată.

O cheie candidat este unică (în fiecare tuplu al relaţiei R, valorile cheii identifică acel tuplu în mod unic) şi
ireductibilă (nici o submulţime a cheii candidat nu este unică).

Cheia primară: este cheia candidat care este selectată [din toate cheile candidat identificate] pentru a identifica
în mod unic tuplurile din cadrul unei relaţii.

Cheile candidat neselectate se numesc chei alternative.

Cheie străină: Un atribut sau o mulţime de atribute din cadrul unei relaţii, care se potrivesc cu o cheie candidate
din altă relaţie.

De exemplu o cheie străină dintr-o relaţie poate (spunem că ţinteşte) coincide cu cheia primară din altă
relaţie. (Spunem că ţinteşte cheia primară din altă relaţie).

Atributele comune joacă un rol important în manipularea datelor.

3.1.6 Reprezentarea schemelor (de relaţii) din BD relaţionale

Schema unei relaţii dintr-o BD are forma:

32
Denumire relaţie [titlu tabel] (Atribute, începând cu cheia primară, subliniată)

Clienţi (Nr. crt., firmă, localitate, adresă facturare, judeţ, cod poştal, nr. telefon, cont trezorerie, dată contact).

Modelul conceptual (schema conceptuală) al unei BD este mulţimea tuturor schemelor de relaţie pentru BD
respectivă.

3.1.7 Integritatea relaţională

Un model de date relaţional cuprinde:

- o parte structurală, discutată în paragraful precedent;

- un set de reguli de integritate care asigură corectitudinea datelor;

- o parte de manipulare, care defineşte tipurile de operaţii permise asupra datelor.

Fiecare atribut are un domeniu, deci asupra valorilor permise pentru fiecare atribut există anumite
constrângeri de domeniu.

Mai există două reguli de integritate importante care sunt constrângeri ce se aplică întregii baze de
date, anume:

- integritatea entităţilor

- integritatea referenţială

3.1.7.1 Null-uri

Null reprezintă valoarea unui atribut care este curent necunoscută sau nu este aplicabilă tuplului respectiv.

Valoare logică “necunoscut”.

33
 Un Null nu este acelaşi lucru cu o valoare numerică = 0 sau cu un şir de text “spaţii” (zero string);
acestea sunt valori, un Null însemnând însă absenţa unei valori.

3.1.7.2 Integritatea entităţilor

Se aplică cheilor primare ale relaţiilor de bază. O relaţie de bază (tabel de bază) corespunde unei
entităţi în schema conceptuală a BD.

Integritatea entităţilor: într-o relaţie de bază nici un atribut al unei chei primare nu poate fi Null.

3.1.7.3 Integritatea referenţială

Se aplică cheilor străine.

Integritatea referenţială: Dacă într-o relaţie există o cheie străină, valoarea acesteia trebuie ori să coincidă cu
valoarea unei chei candidat a unui tuplu în relaţia sa de bază, ori să fie în întregime Null.

3.1.7.4 Constrângerile de întreprindere

Constrângerile de întreprindere: sunt reguli adiţionale, specificate de către utilizatorii sau administratorul bazei
de date (DBA).

3.1.8 Vederi

Vederea externă este structura BD aşa cum apare ea unui anumit utilizator.

În modelul relaţional o vedere este o relaţie virtuală, o relaţie care nu este de fapt de sine stătătoare, ci
este derivată în mod dinamic din una sau mai multe relaţii de bază.

3.1.8.1 Terminologie

34
Relaţie de bază: O relaţie cu o anumită denumire, corespunzătoare unei entităţi din schema conceptuală, ale
cărei tupluri sunt stocate fizic în BD.

Vedere: Rezultatul dinamic al uneia sau mai multor operaţii relaţionale care acţionează asupra relaţiilor de bază,
pentru a obţine o altă relaţie. O vedere este o relaţie virtuală, care în realitate nu există în BD, ci este produsă în
momentul respectiv, la cererea unui utilizator.

Conţinutul unei vederi este definit ca o interogare asupra unei sau mai multor relaţii de bază. Vederile
sunt dinamice, adică modificările în relaţiile de bază sunt reflectate imediat în vederi. Şi invers, modificările
permise operate asupra vederii se transmit relaţiilor de bază.

3.1.8.2 Scopul vederilor

Mecanismul de vedere este util pentru că:

- furnizează un mecanism de securitate puternic;

- permite utilizatorilor accesarea datelor în mod personalizat; aceleaşi date pot fi vizualizate
simultan, în moduri diferite, de către diverşi utilizatori;

- poate simplifica operaţiile complexe asupra relaţiilor de bază.

3.1.8.3. Reactualizarea vederilor

Există restricţii referitor la modificările care pot fi efectuate prin intermediul vederilor.

Condiţiile de care depinde reactualizarea datelor prin intermediul vederilor sunt:

- sunt permise reactualizările prin intermediul unor vederi definite prin utilizarea unei interogări simple
a unei singure relaţii de bază, şi care interogare conţine fie cheia primară, fie cheia candidat a acesteia;

- nu sunt permise reactualizările prin vederi care implică relaţii de bază multiple;

- nu sunt permise reactualizările prin vederi care implică operaţia de acumulare sau de grupare.

3.2 Proiectarea modelului relaţional

35
 Proiectarea corectă a bazelor de date este crucială pentru obţinerea unei aplicaţii de înaltă performanţă.

Modelul relaţional este cel mai utilizat dintre modelele de date existente (modele ierarhice, modele
reţea, modele orientate pe obiect). Faţă de modele ierarhic şi reţea, modelul relaţional prezintă câteva avantaje:

- propune structuri de date uşor de utilizat;

- ameliorează independenţa logică şi fizică;

- pune la dispoziţia utilizatorilor limbaje neprocedurale;

- optimizează accesul la date;

- îmbunătăţeşte confidenţialitatea datelor.

Din punct de vedere istoric, trebuie menţionat că modelul relaţional s-a conturat în două articole
publicate de către F.E. Codd în 1969 şi 1970, matematician la centrul de cercetări (California) I.B.M. Codd a
propus o structură de date tabelară, independentă de tipul de echipamente şi de software-ul de sistem pe care
este implementată. Deşi puternic matematizat, modelul relaţional este relativ uşor de înţeles.

Dacă, teoretic, modelul s-a consacrat în anii 1970, produsele software care să gestioneze baze de date
au devenit populare abia în anii 80. Cele mai utilizate sisteme de gestiune a bazelor de date relaţionale (SGBDR)
dedicate uzului individual sunt: ACCESS, PARADOX, Visual Fox Pro. Pentru aplicaţiile complexe din bănci şi
instituţii de mari dimensiuni se folosesc SGBDR-urile de „categorie grea”, ORACLE, DB2 IBM, Informix IBM,
SyBase (SyBase), SQL Server (MicroSoft). Sunt mult mai robuste, fiabile, dar şi costisitoare. În ultimul timp şi-au
făcut apariţia aşa-zisele SGBD-uri (aproape) gratuite: PostgreSQL, MySQL, mSQL, FireBird etc. (Acestea rulează
de obicei pe sisteme de operare Linux).

Modelul relaţional are la bază teoria matematică a relaţiilor şi poate fi privit ca o mulţime de tabele
obţinute prin metoda normalizării, eliminându-se astfel anomaliile de actualizări.

Conceptele modelului relaţional sunt:

1. structura relaţională a datelor;

2. operatorii modelului relaţional;

3. restricţiile de integritate ale modelului relaţional.

3.2.1 Structura relaţională a datelor

O bază de date relaţională (BDR) reprezintă un ansamblu de relaţii, prin care se reprezintă datele şi
legăturile dintre ele.

36
 În cadrul bazei de date relaţionale, datele sunt organizate sub forma unor tablouri bidimensionale
(tabele) de date, numite relaţii. Asocierile dintre relaţii se reprezintă prin atributele de legătură. În cazul
legăturilor de tip „unu la mulţi”, aceste atribute figurează într-una dintre relaţiile implicate în asociere. În cazul
legăturilor de tip „mulţi la mulţi”, atributele sunt situate într-o relaţie distinctă, construită special pentru
explicarea legăturilor între relaţii.

Prezentarea structurii relaţionale a datelor impune definirea noţiunilor de:

 domeniu;
 relaţie;
 atribut;
 schemă a unei relaţii.
Conceptele utilizate pentru a descrie formal, uzual sau fizic elementele de bază ale organizării datelor
sunt date în următorul tabel:

Formal Uzual Fizic

Relaţie Tablou Fişier

Tuplu Linie Înregistrare

Atribut Coloană Camp

Domeniu Tip de dată Tip de dată

Fig. 3.1. Concepte uzuale folosite în exprimarea formală, uzuală şi fizică

 Domeniul

Domeniul reprezintă o mulţime de valori, notată prin litere mari D 1,D2 etc., caracterizată printr-un nume.

Modalităţile de definire a unui domeniu sunt:

 explicit: prin enumerarea tuturor valorilor aparţinând domeniului;

 implicit: prin precizarea proprietăţilor pe care le au valorile din cadrul domeniului.

Exemplu: D1: {“Da”, “Nu”} reprezintă un domeniu definit explicit. D 2: {x/ x este de dată calendaristică} sau D 3: {s/
s este număr decimal} reprezintă domenii definite implicit, unde prin număr decimal se înţelege un număr
zecimal pentru care se precizează numărul de cifre componente.

37
 Printr-un tuplu se înţelege o succesiune de valori de diferite tipuri. Un tuplu se notează enumerând
valorile sale <V1,V2,V3,...,Vn>, unde V1 este o valoare din domeniul D1, V2∈D2 etc.

Exemplu: Considerăm că tuplul referitor la persoana x din entitatea CERERI_OFERTE conţine trei valori diferite ce
desemnează:

 codul numeric personal (cnp): 1701205230023;

 data înregistrării ofertei (data_înreg): 2006-07-03;
 tipul soluţionării (tip_soluţionare): „Nu”.
Se formează tuplul <1701205230023, ‘2006-07-03’, ”Nu”>.

 Relaţia

Relaţia R este un subansamblu al produsului cartezian dintre mai multe domenii D 1, D2, ..., Dn,
reprezentată sub forma unei tabele de date (tabelul bidimensional) şi deci, o mulţime de tupluri.

Exemplu: Considerăm că:

 D1 cuprinde valori referitoare la tipul soluţionării tranzacţiei: „Da”, dacă

tranzacţia a fost soluţionată, „Nu”, în caz contrar;
 D2 cuprinde valori ale datei calendaristice;
 D3 conţine valori care exprimă cnp-ul persoanei.
De asemenea considerăm că se cunosc datele a doi ofertanţi şi că fiecare pune în vânzare doar câte un
imobil. Atunci definim relaţia R prin tuplurile care descriu aceste informaţii ale ofertelor celor două persoane:

R: {<1701205230023,’2006-07-03’, ”Nu”>, <2661805270023,’2006-05-27’, ”Da”>}.

sau R:

D3 D2 D1

2661805270023 2006-05-27 Da

1701205230023 2006-07-03 Nu

Fig. 3.2. Variante de prezentare a unei relaţii R

38
Observaţia 1. Într-o relaţie, tuplurile trebuie să fie distincte.

Observaţia 2. Cardinalul relaţiei este numărul tuplurilor dintr-o relaţie.

Gradul relaţiei este numărul valorilor dintr-un tuplu.

 Atributul

Atributul reprezintă coloana unei tabele de date, caracterizată printr-un nume.

Exemplu:

R:

cnp: D3 data_înreg:D2 tip_soluţionare:D1

2661805270023 2006-05-27 Da

1701205230023 2006-07-03 Nu

Fig. 3.3. Relaţia R reprezentată cu ajutorul atributelor

Atributele sunt utile atunci când într-o relaţie un domeniu apare de mai multe ori. Prin numele dat
fiecărei coloane (atribut), se diferenţiază coloanele care conţin valori ale aceluiaşi domeniu, eliminând
dependenţa faţă de ordine.

 Schema unei relaţii

Schema unei relaţii este numele relaţiei urmată de lista de atribute, pentru fiecare atribut precizându-se
domeniul asociat.

Astfel, pentru o relaţie R cu atributele A 1, A2, ... , An şi domeniile D1, D2, ... ,Dm,

cu m ≤ n, schema relaţiei R poate fi prezentată astfel:

39
 R(A1: D1, A2:D2, ... , An: Dm)

sau

R:

A1:D1 ... An:Dm

Fig. 3.4. Reprezentarea schemei relaţiei R

Ca o concluzie, dintre caracteristicile modelului relaţional menţionăm:

- nu există tupluri identice;

- ordinea liniilor şi a coloanelor este arbitrară;

- articolele unui domeniu sunt omogene;

- fiecare coloană defineşte un domeniu distinct şi nu se poate repeta în cadrul aceleiaşi relaţii.

3.2.2 Operatorii modelului relaţional

Modelul relaţional oferă două colecţii de operatori pe relaţii:

- algebra relaţională;

- calcul relaţional:

 calcul relaţional orientat pe tuplu;

 calcul relaţional orientat pe domeniu.

În acest curs va fi tratat doar cazul algebrei relaţionale.

Algebra relaţională este o colecţie de operaţii pe relaţii, fiecare operaţie având drept operanzi una sau
mai multe relaţii, rezultatul fiind o altă relaţie.

Există mai multe criterii de grupare a operaţiilor:

- operaţii de bază:

40
  reuniunea;

 diferenţa;

 produsul cartezian etc.

- operaţii derivate:

 intersecţia;

 diviziunea etc.

sau

- operaţii tradiţionale pe mulţimi (reuniune, intersecţie, diviziune, produs cartezian)

- operaţii relaţionale speciale (selecţia, proiecţia, joncţiunea, etc.)

 Reuniunea

Reuniunea reprezintă o operaţie a algebrei relaţională definită pe două relaţii: R 1 şi R2, ambele cu aceeaşi
schemă, în urma căreia se construieşte o nouă relaţie R 3, cu aceeaşi schemă ca şi R 1 şi R2 şi având drept extensie
tuplurile din R1 şi R2, luate împreună o singură dată.

Notaţii:

R1U R2

OR (R1, R2)

APPEND (R1, R2)

UNION (R1, R2)

Reprezentarea grafică

R3

∪ 41

R1 R2
 Fig. 3.5. Reprezentarea grafică a operaţiei de reuniune a două relaţii

Exemplu: Deoarece aplicaţia AGENTIE IMOBILIARA luată ca exemplu nu conţine două relaţii cu aceeaşi structură,
pentru a putea exemplifica operaţia de reuniune se vor construi două relaţii ARHIVA_OFERTE şi ARHIVA_CERERI
populate cu informaţiile aferente ofertelor respectiv cererilor soluţionate (s-au ales doar trei atribute: id-ul
ofertei sau a cererii, cnp-ul clientului, tipul soluţionării). Pentru a afla care sunt toate ofertele şi cererile
soluţionate, se realizează operaţia de reuniune.

REZ:

ARHIVA_OFERTE: ARHIVA_CERERI:

Fig. 3.6. Reuniunea relaţiilor ARHIVA_OFERTE şi ARHIVA_CERERI

42
 Diferenţa

Diferenţa reprezintă o operaţie a algebrei relaţionale definită pe două relaţii R 1 şi R2, ambele cu o aceeaşi
schemă, în urma căreia se construieşte o nouă relaţie R 3, cu schema identică cu R 1 şi R2, având drept extensie
acele tupluri ale relaţiei R1 care nu se regăsesc în relaţia R2.

Notaţii:

R1 – R2

REMOVE (R1, R2)

MINUS (R1, R2)

Reprezentarea grafică:

R3

-
R1 R2

43
 Fig. 3.7. Reprezentarea grafică a operaţiei de diferenţă a două relaţii

Exemplu: Presupunând că există clienţi care au înregistrări în ambele tabele (adică au oferit imobil spre vânzare,
dar şi au achiziţionat un alt imobil în acelaşi timp), pentru a afla care au fost doar ofertanţii de imobile, se aplică
diferenţa dintre relaţiile ARHIVA_OFERTE şi ARHIVA_CERERI.

REZ:

ARHIVA_OFERTE: ARHIVA_CERERI:

Fig. 3.8. Diferenţa relaţiilor ARHIVA_OFERTE şi ARHIVA_CERERI

 Produsul cartezian

Produsul cartezian reprezintă o operaţie a algebrei relaţionale definită pe două relaţii R 1 şi R2, în urma
căreia se construieşte o nouă relaţie R 3, a cărei schemă se obţine prin concatenarea schemelor relaţiilor R 1 şi R2,
având ca extensie toate combinaţiile tuplurilor din R 1 cu cele din R2 (operaţie laborioasă).

Notaţie: R1xR2

PRODUCT (R1, R2)

TIMES (R1, R2)

44
 Reprezentarea grafică:

R3


R1 R2

Fig. 3.9. Reprezentarea grafică a produsului cartezian

Exemplu: Operaţia de produs cartezian va fi exemplificată pe un exemplu independent de aplicaţia AGENŢIA

IMOBILIARĂ considerată. Astfel:

TRANSPORT:

LOCALIT:
 TARIFE:

Fig. 3.10. Produsul cartezian dintre relaţiile LOCALIT şi TARIFE

45
  Proiecţia

Proiecţia reprezintă o operaţie a algebrei relaţionale definită asupra unei relaţii R, în urma căreia se
construieşte o nouă relaţie P, în care se găsesc acele atribute din R specificate explicit în cadrul operaţiei.

Prin operaţie de proiecţie se trece de la o relaţie de grad n (are n coloane) la o relaţie de grad mai mic, p
(p<n).

Π A , A ,... , A ( R)
Notaţie: j j m

R[ A j , A j ,..., A m ]

PROJECT ( R , A j , A j ,... , A m )

Reprezentarea grafică:
P

Aj,Aj,...,Am

Fig. 3.11. Reprezentarea grafică a operaţiei de proiecţie

Exemplu: Pentru a obţine o listă cu numele şi numerele de telefon ale ofertanţilor/cumpărătorilor, se poate
aplica operaţia de proiecţie a relaţiei DATE_PERSOANE asupra atributelor „numele”, „nr_telefon”

46
 REZ:

numele,
nr_telefon

DATE_PERSOANA:

Fig.3.12. Proiecţia relaţiei DATE_PERSOANA pe atributele „numele”, „nr_telefon”

 Selecţia

Selecţia reprezintă o operaţie din algebra relaţională definită asupra unei relaţii R, în urma căreia se
construieşte o nouă relaţie S, cu aceeaşi schema ca R, având extensia construită din acele tupluri din R care
satisfac o condiţie menţionată explicit în cadrul operaţiei (se poate interpreta ca „tăiere orizontală”: nu toate
tuplurile din R satisfac această condiţie).

Condiţia precizată în cadrul operaţiei de selecţie se reprezintă sub forma:

atribut, operator de comparaţie, valoare

unde “operator de comparaţie” poate fi unul din semnele <, <=, >=, > sau ≠.

47
 Notaţie:

σ condiţie (R)

R [condiţie]

RESTRICT (R, condiţie)

Reprezentarea grafică:

condiţie

Fig. 3.13. Reprezentarea grafică a operaţiei de selecţie

Exemplu: În cazul în care se doreşte afişarea ofertelor/cererilor anterioare datei de 2006-07-03, se poate aplica
operaţia de selecţie asupra relaţiei CERERI_OFERTE, după cum se va vedea în figura 3.14.

48
 OFERTE VECHI:

Data_înreg<2006-07-03

OFERTE:

id_ tipul cnp data_ inreg Cod_loc Id_ Nr_ etaj Pret_ Pret_ max Id_confort
co# strada imobil min

12 oferta 2660805270023 2006-05-27 CJ147 120 22 P 45 47 0013

13 oferta 1701205230023 2006-07-03 BV230 120 52 2 30 35 0012

Fig. 3.14. Selecţia efectuată asupra relaţiei CERERI_OFERTE

 Joncţiunea

Joncţiunea (joinul) reprezintă o operaţie a algebrei relaţionale definită pe două relaţii: R 1 şi R2, în urma
căreia se construieşte o altă relaţie R 3, prin concatenarea unor tupluri din R 1 cu tupluri din R2 care îndeplinesc o
anumită condiţie specificată explicit în cadrul operaţiei.

Notaţie:

R1 R2;

JOIN(R1,R2,condiţie)

Reprezentarea grafică:
R3

atribut din R1 atribut din R2

Operator de comparaţie

R1 R2

49
 Fig. 3.15. Reprezentarea grafică a operaţiei de joncţiune

Condiţia de concatenare din cadrul operaţiei de joncţiune este de forma:

atribut din R1 operator de comparaţie atribut din R2

În funcţie de operatorul de comparaţie din condiţia de concatenare, joinul poate fi de mai multe feluri,
însă cel mai important este equijoinul:

atribut din R1 = atribut din R2

Exemplu: Aplicând operaţia de equijoin relaţiilor DATE_PERSOANE şi FACTURI pentru atributul „cnp”, se obţin
informaţii referitoare la clienţii care au încheiat facturi. Pentru a nu încărca figura, pentru cele două relaţii s-au
ales doar câteva atribute.

50
 REZ:

cnp cnp

= FACTURI:
DATE_PERSOANA:

Fig. 3.16. Operaţia de equijoin a relaţiilor DATE_PERSOANA şi FACTURI

Observaţie: Operaţia de joncţiune se poate exprima cu ajutorul operaţiilor de produs cartezian şi

selecţie, rezultatul unui join fiind asemenea cu cel al operaţiei de selecţie asupra unui produs cartezian:

JOIN (R1, R2, condiţie) = RESTRICT (PRODUCT (R 1, R2), condiţie).

Este indicată utilizarea joinului în locul produsului cartezian, de câte ori este posibil.

Tipuri de joncţiuni

În funcţie de

- tipul condiţiilor de conectare

- modul de definire a schemei

- extensia relaţiei rezultate prin joncţiune,

51
vom studia:

- joncţiunea naturală

- joncţiunea externă

- semijoncţiunea.

 Joncţiunea naturală

Joncţiunea naturală este o operaţie definită pe două relaţii R 1 şi R2, în urma căreia se construieşte o nouă
relaţie R3, a cărei schemă este obţinută prin reuniunea atributelor din relaţiile R 1 şi R2 (atributele cu aceleaşi
nume se iau o singură dată) şi a cărei extensie conţine tuplurile obţinute prin concatenarea tuplurilor din R 1 cu
cele din R2 care prezintă aceleaşi valori pentru atributele cu aceleaşi nume.

Joncţiunea naturală elimină inconvenientul ce apare în cazul equijoinului şi anume: schema relaţiei în
cazul equijoinului conţine toate atributele celor două relaţii. Astfel, în relaţia R 3 a joncţiunii naturale, atributele
cu acelaşi nume vor apărea o singură dată.

Reprezentarea grafică:
R3

R1 R2

Fig. 3.17. Reprezentarea grafică a operaţiei de joncţiune naturală

52
Exemplul 1: Reluând exemplul anterior, prin joncţiunea naturală se elimină atributul repetitiv „cnp”.

REZ:

cnp cnp
=

DATE_PERSOANA: FACTURI:

Fig. 3.18. Operaţia de joncţiune naturală a relaţiilor DATE_PERSOANA şi FACTURI

Exemplul 2: Dacă se doreşte aflarea denumirilor localităţilor în care sunt oferte sau cereri, cum în relaţia
CERERI_OFERTE se află doar codul localităţii respective iar în relaţia LOCALITATI este asociat fiecărui cod de
localitate denumirea localităţii, trebuie să se realizeze o joncţiune naturală între aceste două relaţii. Astfel
rezultatul joncţiunii va fi cel prezentat în figura 3.19.

53
 REZ:

cod_loc cod_loc LOCALITATI:

CERERI_OFERTE:

Fig. 3.19. Joncţiunea naturală a relaţiilor CERERI_OFERTE şi LOCALITATI

 Joncţiunea externă

Joncţiunea externă este operaţia definită pe două relaţii: R 1 şi R2, în urma căreia se obţine o nouă relaţie
R3 prin joncţionarea relaţiilor R1 şi R2. În relaţia R3 apar şi tuplurile din R 1 şi R2 care nu au participat la join
(atributul de joncţiune – cel care are acelaşi nume şi în relaţia R 1 şi în relaţia R2 – nu prezintă aceleaşi valori).
Aceste tupluri sunt completate cu valora „NULL”.

Joncţiunea externă elimină inconvenientul cauzat de joncţiunea internă şi anume pierderea de tupluri
(vezi figura 3.19, tuplul <44,”oferta”, 2661111246642, 2006-09-17, MM430, 133, 4, 50, “nu”> nu mai apare în
relaţia REZ deoarece simbolul „MM430” corespunzătoare atributului cod_loc din relaţia CERERI_OFERTA nu
figurează printre valorile atributului cu acelaşi nume din relaţia LOCALITATI.

Reprezentarea grafică:

R3

R1 54 R2
 Fig. 3.20. Reprezentarea grafică a operaţiei de join extern

Exemplu: Joncţiunea externă este o operaţie care din punct de vedere al programării prezintă inconvenientul
manipulării valorilor nule. În relaţia REZ, judeţului Braşov nu i s-a asignat o localitate, deci nici codul localităţii.

REZ:

simbol_judet simbol_judet

LOCALITATI:
JUDETE:

Fig. 3.21. Operaţia de joncţiune externă a relaţiilor LOCALITĂŢI şi JUDEŢE

55
 Semijoncţiunea

Semijoncţiunea este o operaţie definită pe două relaţii R 1 şi R2, în urma căreia se construieşte o nouă
relaţie R3, a cărei extensie conţine tuplurile relaţiei R 1 care participă la joncţiunea celor două relaţii, conservând
atributele relaţiei R1.

Notaţie:

R1 R2;

SEMIJOIN(R1, R2).

Reprezentarea grafică:
R3

R1 R2

Fig. 3.22. Reprezentarea grafică a operaţiei de semijoncţiune

Exemplu: Semijoncţiunea următoare realizează lista localităţilor care au referinţă în relaţia JUDETE.

56
 REZ:

simbol_judet

LOCALITATI:
JUDETE:

Fig. 3.23. Operaţia de semijoncţiune a relaţiilor LOCALITATI şi JUDETE

Observaţia 1. Această operaţie a fost introdusă de P.A. Bernstein, fiind necesară la optimizarea cererilor
de date.

Observaţia 2. Semijoncţiunea produce acelaşi rezultat ca operaţia de proiecţie pe atributele din relaţia
R1 efectuată asupra joncţiunii dintre R 1 şi R2

PROJECT (JOIN (R1, R2, condiţia), A1, A2, A3)=SEMIJOIN (R1, R2).

 Intersecţia

Intersecţia reprezintă o operaţie algebrei relaţionale definită pe două relaţii, R 1 şi R2, ambele cu aceeaşi
schemă, în urma căreia se construieşte o nouă relaţie R 3, cu schema identică cu a operanzilor şi cu schema
formată din tuplurile comune lui R1 şi R2.

Notaţie:

57
 R1∩R2

INTERSECT (R1, R2)

AND (R1, R2)

Reprezentarea grafică:

R3


R1 R2

Fig. 3.24. Reprezentarea grafică a operaţiei de intersecţie

Exemplu:

58
 REZ:


ORASE: MUNICIPII:

Fig. 3.25. Intersecţia relaţiilor ORASE şi MUNICIPII

Observaţie: Intersecţia se poate exprima prin intermediul unor operaţii de bază. De aceea intersecţia este o
operaţie derivată.

R1∩R2=R1-(R1-R2)

R1∩R2=R2-(R2-R1)

 Diviziunea

Diviziunea reprezintă o operaţie a algebrei relaţionale definită asupra unei relaţii R cu schema R(A 1:D1,
… , Ap:Dk, … , Ap+1:Di, … , An:Dm), în urma căreia se construieşte o nouă relaţie Q cu ajutorul unei relaţii r cu
schema r (Ap+1:Dl, … , An:Dm), relaţia Q având schema: Q(A1:D1, …, Ap:Dk).

Tuplurile relaţiei Q concatenate cu tuplurile relaţiei r permit obţinerea tuplurilor relaţiei R.

Notaţie:

R÷r

Division (R, r).

Reprezentarea grafică:
Q
59


 R r

Fig. 3.26. Reprezentarea grafică a operaţiei de diviziune

Observaţie: Operaţia de diviziune este o operaţie derivată deoarece se poate exprima prin intermediul
operaţiilor de bază: a diferenţei, a produsului cartezian şi a proiecţiei:

R÷r=Π A ,. . . , A p (R )−Π A 1 ,. .., A p (( Π A 1 ,.. ., A p ( R)×r)−R)

1 .

 Complementarea

Complementarea reprezintă o operaţie (adiţională) a algebrei relaţionale, definită asupra unei relaţii R,
în urma căreia se construieşte o nouă relaţie C, numită complementarea relaţiei R. Extensia relaţiei C va conţine
ansamblul tuplurilor din produsul cartezian al domeniilor asociate atributelor relaţiei, care nu figurează în
extensia relaţiei considerate.

Notaţii: ┐R

60
 NOT (R)

COMP(R)

Exemplu:

Fie relaţia: R(A1:D1, A2:D2), unde

A1 = culoare;

A2 = număr;

D1 = {“Roşu”, „Galben”, „Albastru”}

D2 = {1, 2, 3}

reprezentată prin tabelul:

R:

A1:D1 A2.D2

Roşu 1

Roşu 2

Galben 3

a) relaţia R

Complementarea relaţiei R va fi relaţia NOT (R) repezintată prin tabelul:

NOT (R):

A1:D1 A2:D2

Roşu 3

Galben 1

Galben 2

Albastru 1

61
 Albastru 2

Albastru 3

b) relaţia not R

Fig. 3.27. Complementarea relaţiei R

Observaţie: Complementaritatea este puţin utilizată, datorită rezultatului foarte mare de tupluri.

 Splitarea

Splitarea (spargerea) reprezintă o operaţie (adiţională) a algebrei relaţionale definită asupra unei relaţii
R, în urma căreia se construiesc două relaţii R 1 şi R2 cu aceeaşi schemă cu R, relaţii obţinute pe baza unei condiţii
definite asupra atributelor din R.

Extensia lui R1 conţine tuplurile din R care verifică condiţia specificată, iar R 2 conţine tuplurile din R care
nu verifică această condiţie.

Exemplu: Considerând relaţia R din figura 3.27 (a) şi condiţia A 2>2, operaţia de splitare a relaţiei R produce
relaţiile R1 şi R2 reprezentate prin tabelele:

R1

A1:D1 A
2:D2

Galben 3

R2

A1:D1 A2:D2

Roşu 1

Roşu 2

62
 Figura 3.28. Rezultatul operaţiei de splitare a relaţiei R din figura 3.27 (a)

pe baza condiţiei A2>2

 Închiderea tranzitivă

Închiderea tranzitivă este o operaţie (adiţională) a algebrei relaţionale, definită asupra unei relaţii R, a
cărei schemă conţine două atribute A 1 şi A2 cu acelaşi domeniu asociat, operaţie care constă în adăugarea la
relaţia R a tuplurilor care se obţin succesiv prin tranzitivitate: dacă în R există tuplurile: <a,b> şi <b,c> se va
adăuga la R tuplul <a,c>.

Notaţie: τ(R)

R+

CLOSE(R)

Exemplu:

R:  (R ) :

a)

b)

Fig. 3.29. Închiderea tranzitivă a relaţiei R

63
3.2.3 Restricţii de integritate ale modelului relaţional

Restricţiile de integritate ale modelului relaţional reprezintă cerinţe pe care trebuie să le îndeplinească
datele din cadrul bazei de date pentru a putea fi considerate corecte şi coerente în raport cu lumea reală pe care
o reflectă. Dacă o bază de date nu respectă aceste cerinţe, ea nu poate fi utilizată cu un maxim de eficienţă.

Restricţiile sunt de două tipuri:

o restricţii de integritate structurale, care se definesc prin egalitatea sau inegalitatea unor
valori din cadrul relaţiilor:
 restricţia de unicitate a cheilor;
 restricţia entităţii;
 dependenţele între ele;
o restricţii de integritate de comportament care ţin cont de semnificaţia valorilor din
cadrul bazei de date.
Utilizarea modelului relaţional nu impune definirea şi verificarea tuturor acestor

tipuri de restricţii de integritate. Din acest punct de vedere există restricţii de integritate minimale. Acestea sunt
obligatoriu de definit şi de respectat când se lucrează cu modelul relaţional. Dintre restricţiile minimale fac
parte:

 restricţia de unicitate a cheii;

 restricţia referenţială;

 restricţia entităţii.

Alte restricţiii de integritate ar fi

 dependenţele;

 restricţii de comportament.

3.2.3.1 Restricţii de integritate minimale

Restricţiile de integritate minimale sunt definite în raport cu noţiunea de cheie a unei relaţii. Cheia
identifică un tuplu în cadrul unei relaţii fără a face apel la toate valorile din tuplu.

64
 Cheia unei relaţii reprezintă ansamblul minimal de atribute prin care se poate identifica în mod unic
orice tuplu al relaţiei.

Oricare relaţie posedă cel puţin o cheie:

o cheie simplă, când cheia este construită dintr-un singur atribut;

o cheie compusă, când cheia este construită din mai multe atribute.
Exemplu:

R2:
R1:

a) cheie simplă

b) cheie compusă

Fig. 3.30. Chei simple şi chei compuse

Determinarea cheii unei relaţii necesită cunoaşterea tuturor extensiilor posibile, nu numai a aceleia din
momentul în care se stabileşte cheia. Astfel, presupunând că R 1 şi R2 sunt versiuni ale aceleiaşi relaţii R la
momente de timp diferite: t1, respectiv t2, alegerea la momentul t1 drept cheie atributul A a relaţiei R se
dovedeşte a fi greşită, întrucât atributul A nu face posibilă identificarea unică a tuplurilor şi la momentul t 2. Cheia
relaţiei R este reprezentată, prin urmare, de perechea de atribute (A,B).

Exemplu:

JUDETE: STRAZI:

Fig. 3.31. Chei simple şi chei compuse în cadrul relaţiilor JUDEŢE, respectiv STRĂZI

65
Observaţie: Cheia relaţiei JUDEŢE este „simbol_judeţ” deoarece fiecare judeţ are o codificare unică a denumirii
sale, deci fiecărui judeţ îi corspunde un singur simbol. Cheia relaţiei STRĂZI este compusă din atributele
„cod_loc” şi „id_strada”. Dacă s-ar alege drept cheie primară doar atributul „id_strada”, acesta nu ar identifica în
mod unic numele unei străzi dintr-o localitate, numele străzii respective putându-se regăsi şi în alte localităţi ale
aceluiaşi judeţ sau a altui judeţ. La fel, dacă s-ar alege drept cheie primară atributul „cod_loc”, acesta nu ar mai
identifica în mod unic un tuplu, deoarece într-o localitate există mai multe străzi.

O relaţie poate avea mai multe combinaţii de atribute, cu proprietatea de identificare unică a tuplurilor.
Se spune în acest caz că relaţia posedă mai mulţi candidaţi cheie (chei candidate).

Definiţia 1. Se numeşte cheie primară, cheia aleasă dintre cheile candidate care să servească în mod
efectiv la identificarea tuplurilor.

Cheia primară nu poate fi reactualizată. Cheia primară a unei relaţii nu este altceva decât atributul de
identificare a unei entităţi, prin urmare se reprezintă fie prin subliniere, fie urmate de semnul #.

Definiţia 2. Se numeşte cheie externă atributul/grupul de atribute dintr-o relaţie R 1 a cărui/căror valori
sunt definite pe acelaşi domeniu/aceleaşi domenii ca şi cheia primară a unei alte relaţii R 2 şi care are rolul de a
modela asocierea între entităţile reprezentate prin relaţiile R 1 şi R2. În acest caz, R1 se numeşte relaţie care
referă, iar R2 se numeşte relaţie referită.

Exemplu:

DATE_PERSOANA: JUDETE:

Fig. 3.32. Reprezentarea legăturii dintre relaţiile DATE_PERSOANA şi JUDETE cu ajutorul cheii
externe „simbol_judet” din cadrul relaţiei DATE_PERSOANA

Observaţia1:

66
 În exemplul de mai sus, relaţia DATE_PERSOANA are drept cheie primară atributul „cnp”, iar ca şi cheie
externă atributul „simbol_judet”, iar relaţia JUDETE are drept cheie primară cheia „simbol_judet”. Relaţia
DATE_PERSOANA este relaţia care referă, iar JUDETE este relaţia referită.

Observaţia2:

Între cele două relaţii (entităţi) avem următoarea asociere:

(0,n) are reşedinţa (1,1)

DATE_PERSOANA JUDETE

Fig. 3.33. Asocierea dintre entităţile DATE_PERSOANA şi JUDETE

Exemplu:

JUDETE: LOCALITATI:

STRĂZI:

Fig. 3.34. Reprezentarea legăturii între relaţiile JUDETE şi LOCALITATI cu ajutorul cheilor externe „simbol_judet”
şi „cod_localitate”

67
 Restricţia de unicitate a cheii

Restricţia de unicitate a cheii impune ca într-o relaţie să nu existe două linii identice (linii care să nu
conţină aceleaşi valori pentru toate atributele). Altfel spus, restricţia de unicitate a cheii impune ca într-o relaţie
să nu existe două tupluri cu o aceeaşi valoare pentru atributul cheie.

Exemplele respectă restricţia de unicitate a cheii.

 Restricţia referenţială

Restricţia referenţială impune ca într-o relaţie R1 care referă o relaţie R2, valorile cheii externe să figureze
printre valorile cheii primare din R 2 sau să fie valori „null” (nedefinite). R 1 şi R2 nu trebuie să fie neapărat
distincte.

Exemplele prezintă un mecanism de legare a relaţiilor şi respectă restricţia referenţială a cheii.

 Restricţia entităţii

Restricţia entităţii impune ca într-o relaţie atributele cheii primare să fie nenule. (Atributele cheie să nu
conţină valori nule). Dacă există valori „null”, cheia îşi poate pierde rolul de identificator de tuplu. Astfel, la
încărcarea unui tuplu, valoarea cheii trebuie să fie cunoscută, pentru a se putea verifica faptul că această valoare
nu există deja încărcată.

Exemplele respectă restricţia entităţii.

Relaţia REZ din figura 3.21 încalcă restricţia entităţii deoarece există chei primare ce conţin valori nule,
după cum este cazul judeţului Braşov.

3.2.3.2 Alte restricţii de integritate

În categoria restricţii de integritate intră următoarele tipuri de restricţii:

a) restricţii referitoare la dependenţa datelor:

68
  dependenţă funcţională;

 dependenţă multivaloare;

 dependenţă joncţiune

b) restricţii de comportament:

 restricţii de domeniu;

 restricţii temporale.

Restricţiile referitoare la dependenţa datelor, reprezintă modul în care datele depind unele de altele.

 Dependenţele funcţionale

Dependenţele funcţionale reprezintă dependenţa între date prin care se poate identifica un atribut/grup
de atribute prin intermediul altui atribut/grup de atribute.

Dacă X şi Y sunt două subansamble de atribute ale atributelor relaţiei R, spunem că între X şi Y există o
dependenţă funcţională, notată X →Y , dacă şi numai dacă:

(i) fiecare valoare a lui X poate fi asociată unei singure valori din Y, şi

(ii) două valori distincte ale lui X nu pot fi asociate decât aceleiaşi valori ale lui Y.

X se numeşte determinantul (sursa) dependenţei, iar Y se numeşte determinatul (destinaţia)

dependenţei.

Exemple: Următoarele atribute se află în dependenţă funcţională:

o cod_poştal→localitate, deoarece unui cod poştal îi corespunde o singură localitate (sensul

dependenţei este foarte important, deoarece, viceversa ar însemna: o localitate are un
singur cod_poştal);
o nr_factură→data_factură, deoarece cunoaşterea numărului facturii determină cu
exactitate data facturii.
Două atribute nu sunt în dependenţă funcţională, notată X Y, atunci când cunoaşterea unei
valori a primului atribut fie nu permite cunoaşterea nici uneia dintre valorile celui de al doilea atribut, fie

69
permite cunoaşterea mai multor valori ale celui de al doilea atribut.

Exemplu:

Următorul atribut nu se află în dependenţă funcţională: cnp nr_factură, deoarece pentru o

persoană se pot întocmi mai multe facturi (aferente fiecărei vânzări).

În cadrul modelului relaţional, o dependenţă funcţională este reprezentată printr-o săgeată ce porneşte
din sursă şi se termină în destinaţie.

FACTURI:

Fig. 3.35. Reprezentarea dependenţei funcţionale între atributele „nr_factura” şi „data_facturii”

 Dependenţele multivaloare

Dependenţele multivaloare reprezintă dependenţa în care un atribut/ grup de atribute poate

reprezenta/ identifica mai multe valori pentru o singură valoare a unui alt atribut/ grup de atribute.

Dacă X,Y şi Z sunt trei subansambluri de atribute ale atributelor relaţiei R, spunem că între X şi Y există o
dependenţă multivaloare, notată X →→Y sau X →→Y |Z , dacă şi numai dacă:

(i) la fiecare valoare a lui X poate fi asociată una sau mai multe valori ale lui Y, şi

(ii) această asociere nu depinde de apariţiile lui Z.

Altfel spus, dacă X →→Y şi (x,y,z), (x’,y’,z’) sunt două tupluri din R, atunci şi (x,y’,z), (x,y,z’) sunt
tupluri din R.

Exemplu:

În relaţia OFERTE (alcătuită din atributele: „id_tip_oferte”, „cnp” şi „simbol_judet”) valorile atributului
„id_tip_oferte” au următoarea semnificaţie: 01 desemnează imobil de tip apartament, iar 02, imobil de tip casă.
Astfel, următoarea relaţie conţine dependenţe multivaloare:

70
 OFERTE:

deoarece

01 1701205230023 MM

01 2581023457723 SM

01 1701205230023 SM
01 2581023457723 MM

Fig. 3.36. Relaţia OFERTE în care există dependenţă multivaloare

 Dependenţele de joncţiune

Dacă X1, X2, ...,Xm sunt m subansambluri de atribute din relaţia R, spunem că există o dependenţă de
joncţiune de ordinul m între X 1, X2, ...,Xm, notată X1/ X2/ .../Xm, dacă şi numai dacă R reprezintă joncţiunea
proiecţiilor sale pe X1, X2, ...,Xm.

Observaţie: Dacă m=2. atunci are loc dependenţa multivaloare.

71
72
3.2.4 Regulile lui Codd

Prin sistem de gestiune a bazelor de date relaţionale (SGBDR) se înţelege un SGBD care utilizează drept
concepţie de organizare a datelor modelul relaţional.

Definirea unui SGBDR impune o detaliere a caracteristicilor pe care trebuie să le prezinte un SGBD
pentru a putea fi considerat relaţional. În acest sens, Codd a formulat (în 1985) 13 reguli, care exprimă cerinţele
pe care trebuie să le satisfacă un SGBD. Aceste reguli sunt deosebit de utile în evaluarea unui SGBDR.

R0: Regula privind gestionarea datelor la nivel de relaţie.

- sistemul trebuie să gestioneze BD numai prin mecanisme relaţionale.

R1: Regula privind reprezentarea logică a datelor.

- într-o bază de date relaţionată, informaţia este reprezentată la nivel logic sub forma unor
tabele (relaţii);

- acest lucru înseamnă că toate datele trebuie să fie memorate şi prelucrate în acelaşi mod.

R2: Regula privind reprezentarea logică a datelor

- orice data din baza de date relaţionată trebuie să poată fi accesată prin specificarea:

 numelui relaţiei;

 valorii cheii primare;

 numele atributului.

R3: Regula privind valorile nule

- sistemul trebuie să permită declararea şi manipularea sistematică a valorilor NULL (semnifică

lipsa unor date);

- valorile NULL diferă de şirurile de caractere „spaţiu”, şirurile vide de caractere.

- valorile NULL sunt deosebit de importante în implementarea restricţiilor de integritate:

 integritatea entităţilor;

 integritatea referenţială.

R4: Regula privind metadatele

- utilizatorii autorizaţi trebuie să poată aplica asupra descrierii bazei de date aceleaşi operaţii ca
şi asupra datelor obişnuite.

R5: Regula privind facilităţile limbajelor de utilizare:

73
 - trebuie să existe cel puţin un limbaj care să exprime oricare din următoarele operaţii:

 definirea relaţiilor;

 sa vizualizeze;

 să regăsească informaţia;

 să poată reactualiza informaţia;

 să verifice şi să corecteze datele de intrare, etc.

- în general, toate implementările SQL respectă această regulă.

R6: Regula privind actualizarea tabelelor virtuale:

- toate tabelele/relaţiile virtuale trebuie să poată fi actualizate.

- nu toate tabelele virtuale sunt teoretic actualizate.

Exemplu: Fie tabela de bază PROD, cu următoarea schemă PROD(Denp:D 1, Cant:D2, Pret:D3), cu
ajutorul tabelei PROD este definită o tabelă virtuală DISP, cu schema: DISP (Denp:D 1, Cant:D2,
Pret:D3, Val:D4). Valorile atributului „Val” se calculează astfel:

Val=Cant*Pret.

Presupunem că se doreşte schimbarea preţului unitar la un anumit produs, această schimbare

trebuie efectuată în tabela de bază PROD, atributul „Pret” din tabela virtuală DISP, fiind
actualizabil, întrucât actualizarea se poate propaga spre tabela de bază.

Presupunem că se doreşte schimbarea valorii „Val” la un anumit produs:

 modificarea de la tabela virtuală spre tabela de bază nu mai este posibilă, atributul „Val” nu este
actualizabil, deoarece schimbarea valorii „Val” se poate datora schimbării cantităţii „Cant” şi/sau
a preţului unitar „Pret”.

 astfel trebuie să existe un mecanism prin care să se poată determina dacă anumite vizualizări
pot fi modificate sau nu.

- majoritatea implementărilor SQL îndeplinesc această cerinţă.

R7: Regula privind inserările, modificările şi ştergerile din baza de date.

- un SGBDR nu trebuie să oblige utilizatorul să caute într-o relaţie, tuplu cu tuplu, pentru a
regăsi informaţia dorită;

- această regulă exprimă cerinţa ca în operaţiile prin care se schimbă conţinutul bazei de date să
se lucreze la un moment dat pe o întreagă relaţie.

74
 R8: Regula privind independenţa fizică a datelor

- o schimbare a structurii fizice a datelor nu trebuie să blocheze funcţionarea programelor de

aplicaţii;

- într-un SGBDR trebuie să se separe aspectul fizic al datelor (stocare sau acces la date) de
aspectul logic al datelor.

R9: Regula privind independenţa logică a datelor.

- o schimbare a relaţiilor bazei de date nu trebuie să afecteze programele de aplicaţie.

R10: Regula privind restricţiile de integritate

- restricţiile de integritate trebuie să fie definite într-un limbaj relaţional, nu în programul de

aplicaţie.

R11: Regula privind distribuirea geografică a datelor

- distribuirea datelor pe mai multe calculatoare dintr-o reţea de comunicaţii de date, nu trebuie
să afecteze programele de aplicaţie.

R12: Regula privind prelucrarea datelor la nivelul de bază

- dacă sistemul posedă un limbaj (de bază orientat pe prelucrarea de tupluri şi nu pe

prelucrarea relaţiilor, acest limbaj nu trebuie să fie utilizată pentru a evita restricţiile de
integritate).

3.2.4.1 Clasificarea regulilor lui Codd

În funcţie de tipul de cerinţe pe care le exprimă, regulile sunt grupate în 5 categorii:

1. Reguli de bază: R0 şi R12;

2. Reguli structurale: R1 şi R6;

3. Reguli privind integritatea datelor: R 3 şi R10;

4. Reguli privind manipularea datelor: R 2, R4, R5, R7;

5. Reguli privind independenţa datelor: R 8, R9, R11.

75
3.2.4.2 Evaluarea/prelucrarea cerinţelor şi optimizarea

În SGBDR interfaţa cu utilizatorul este de tip neprocedural. Utilizatorul defineşte datele pe care doreşte
să le vizualizeze fără a da algoritmi de acces. Sistemul trebuie să convertească cererea utilizatorului într-o cerere
optimală.

Evaluarea unei cereri se efectuează în trei etape:

1. Analiza cererii ce constă în studierea sintactică şi semantică a cererii pentru a verifica

corectitudinea sa şi a simplifica criteriului de căutare.

2. Ordonanţarea presupune:

- descompunerea cererii într-o mulţime de operaţii elementare şi

- determinarea ordinii optimale a acestor aplicaţii.

3. Execuţia în paralel şi/sau secvenţială a operaţiilor elementare pentru a obţine rezultatul

cererii.

Presupunem că utilizatorul transmite sistemului de gestiune o cerere exprimată prin ordine SQL. Pentru
a răspunde cererii, SGBD-ul trebuie să înţeleagă cererea utilizatorului. Cererea trebuie să fie corectă sintactic,
datele trebuie să fie disponibile utilizatorului şi trebuie localizate analizând diferite drumuri de acces la ele.

Ideea generală este concretizată în schema de mai jos:

cerere arbore algebric (nu este unic)  plan de executie  optimizare

adică optimizarea cererilor de date se realizează prin parcurgerea următoarelor etape:

1. exprimarea cererilor sub forma unei expresii algebrice relaţionale;

2. aplicarea unor transformări algebrice asupra expresiilor obţinute în etapa precedentă, în scopul
executării mai eficiente a lor;

3. planul de execuţie;

76
 4. optimizarea.

Un plan de execuţie implică o secvenţă de paşi pentru evaluarea cererii (în mod obişnuit, fiecare pas
din planul de execuţie corespunde unei operaţii relaţionale) precum şi metoda care va fi folosită pentru
evaluarea operaţiei. De obicei, pentru o operaţie relaţională dată, există mai multe metode ce pot fi folosite
pentru evaluarea acesteia.
Două planuri de execuţie diferite care au întotdeauna acelaşi rezultat se numesc echivalente. Planuri
de execuţie echivalente pot avea diferite costuri. Scopul optimizării cererilor este de a găsi, printre diversele
planuri de execuţie echivalente, pe acela de cost minim. Într-un sistem centralizat, costul evaluării unei
cereri este suma a două componente, costul I/O (transferuri de date) şi costul CPU (verificare de condiţii,
operaţii join etc.).
Strategiile de optimizare pot fi de două tipuri:

1. Strategii generale de optimizare (independente de modul de memorare al datelor);

2. Strategii specifice anumitor SGBDR (ţin cont de modul de memorare al datelor).

Implementarea strategiilor generale de optimizare este permisă datorită proprietăţilor operaţiilor din
algebra relaţională.

Aceste proprietăţi sunt:

a) Comutativitatea operaţiilor de join şi produs cartezian

E1⋈E2 ≡ E2⋈E1

E1 ¿ E2 ≡ E2 ¿ E1

b) Asociativitatea operaţiilor de join şi produs cartezian

(E1 ⋈E2) ⋈ E3 ≡ E1 ⋈ (E2 ⋈E3)

(E1 ¿ E2 ) ¿ E3 ≡ E1 ¿ (E2 ¿ E3 )

c) Compunerea proiecţiilor

ΠA1,...,Am (ΠB1,...,Bn (R)) = ΠA1,...,Am (R),

unde A1,...,Am trebuie să aparţină de B1,...,Bn.

d) Compunerea selecţiilor

σ F 1 ( σ F 2 ( R ))≡σ F 1∧F 2 ( R ) .

Deoarece F 1∧F 2=F 2∧F 1 , selecţiile se pot comuta

σ F 1 ( σ F 2 ( R ))≡σ F 2(σ F 1 (R )) .

77
 e) Comutarea selecţiei şi proiecţiei

- Dacă condiţia F implică numai atributele A 1,...,An, atunci

Π A 1 ,..., An (σ F (R ))=σ F ( Π A 1 ,..., An ( R)) .

- Dacă condiţia F implică şi atributele B 1,...,Bm, care nu aparţine de A1,...,An atunci

Π A1 ,..., An (σ F (R ))=Π A1 ,..., An (σ F ( Π A1 ,...,An ,B 1,...,Bm ( R))) .

f) Comutarea selecţiei cu produsul cartezian

- Dacă toate atributele menţionate în F sunt atribute ale lui E 1, atunci

σ F ( E1 ×E2 )≡σ F ( E1 )×E2 .

-Dacă, în plus, F este de forma

F=F1 ∧F 2 şi F implică numai atributele din E , iar F implică numai
1 1 2

atributele din E2, atunci

σ F ( E1 ×E2 )≡σ F ( E1 )×σ F ( E2 )

1 2 .

Daca F1 implică numai atribute din E1, dar F2 implică atribute atât din E1 cât şi din E2, atunci

σ F ( E1 ×E2 )≡σ F ( σ F ( E1 )×E2 )

2 1 .

g) Comutarea selecţiei cu reuniunea

σ F ( E1 ∪E2 )≡σ F ( E1 )∪σ F ( E 2 ) .

h) Comutarea selecţiei cu diferenţa

σ F ( E1 −E2 )≡σ F ( E1 )−σ F ( E 2 ) .

i) Comutarea proiecţiei cu produsul cartezian

Dacă A1,A2,...,An sunt atribute din cadrul a două expresii E 1 şi E2, formate din atributele B 1,...,Bm ale lui E1
şi din atributele C1,...,Ck ale lui E2, atunci

Π A 1 ,..., An (E 1×E 2 )≡Π B 1 ,...,Bm ( E1 )×Π C1 ,...,Ck ( E 2 ) .

j) Comutarea proiecţiei cu reuniunea

Π A 1 ,. .. , An (E 1∪E 2 )≡Π A 1 ,. .. , An (E 1 )∪Π A 1 ,. .., An( E 2 ) .

78
 Aceste proprietăţi permit definirea unor strategii generale de optimizare a cererilor de date şi anume:

Regula de optimizare 1. Selecţiile se execută cât mai devreme posibil. Motivaţia acestei reguli este că
selecţiile reduc substanţial dimensiunea relaţiilor. Regula de transformare 4 poate fi folosită pentru a separa două
sau mai multe selecţii în selecţii individuale care pot fi distribuite joncţiunii (join-ului) sau produsului cartezian
folosind comutarea selecţiei cu joncţiunea (join-ul).

Regula de optimizare 2.   Produsele carteziene se înlocuiesc cu join-uri, ori de câte ori este posibil. Un produs
cartezian între două relaţii este de obicei mult mai scump (ca şi cost) decât un join între cele două relaţii, deoarece
primul generează concatenarea tuplurilor în mod exhaustiv şi poate genera un rezultat foarte mare. Această
transformare se poate realiza folosind legătura dintre produs cartezian, join şi selecţie.

Regula de optimizare 3.   Dacă sunt mai multe join-uri atunci cel care se execută primul este cel mai restrictiv.
Un join este mai restrictiv decât altul dacă produce o relaţie mai mică. Se poate determina care join este mai
restrictiv pe baza factorului de selectivitate sau cu ajutorul informaţiilor statistice. Algebric, acest lucru se poate
realiza folosind regula de transformare 2.

Regula de optimizare 4.   Proiecţiile se execută la început pentru a îndepărta atributele nefolositoare. Dacă un
atribut al unei relaţii nu este folosit în operaţiile ulterioare atunci trebuie îndepărtat. În felul acesta se va folosi o
relaţie mai mică în operaţiile ulterioare. Aceasta se poate realiza folosind comutarea proiecţiei cu join-ul.

79
 4. NORMALIZAREA

4.1. Relaţii/tabele, domenii, atribute, valori nule

La modul simplist, o bază de date relaţională (BDR) poate fi definită ca un ansamblu de relaţii
(tabele); fiecare tabelă (sau tabel), alcătuită din linii (tupluri), are un nume urnc şi este stocată pe suport
extern (de obicei disc). La intersecţia unei linii cu o coloană se gaseşte o valoare atomică. O relaţie
conţine informaţii omogene legate de anumite entităţi, procese, fenomene: CARŢI, ELEVI,
LOCALITĂŢI, PERSONAL, FACTURI etc. Spre exemplu, în figura 4.1 este reprezentată tabela
STUDENŢI ce stochează informaţii privitoare la studenţii înscrişi la cursurile unei facultăţi.
În teoria relaţională se foloseşte termenul relaţie. Practica însă a consacrat termenul tabelă (engl.
table). Un tuplu sau o linie este o succesiune de valori de diferite tipuri. În general, o linie grupează
informaţii referitoare la un obiect, eveniment etc., altfel spus, informaţii referitoare la o entitate: o carte
(un titlu sau un exemplar din depozitul unei biblioteci, depinde de circumstanţe), un/o student(ă), o
localitate (oraş sau comună), un angajat al firmei, o factură emisă etc. În figură este pus în evidenţă al
şaselea tuplu din tabela STUDENŢI, tuplu referitor la studentul Ionescu Y. Vasile. Linia respectiva este
alcătuită din nouă valori ce desemnează: matricolul studentului; numele, iniţiala tatălui şi prenumele;
codul numeric personal (CNP-ul), adresa (stabilă); anul de studiu; modulul (dacă e în anul 1 sau 2) sau
specializarea (dacă e în anii 3, 4 sau 5) la care este înscris studentul; seria de curs; grupa; tipul de bursă
de care beneficiază.
Teoretic, orice tuplu reprezintă o relaţie între clase de valori (în cazul nostru, între nouă clase de
valori); de aici provine sintagma baze de date relaţionale, în sensul matematic al relaţiei, de asociere a
două sau mai multe elemente. Fireşte, toate tuplurile relaţiei au acelaşi format (structură). Ordinea
tuplurilor nu prezintă importanţă din punctul de vedere al conţinutului informaţional al tabelei.

Matricol Nume- CNP Adresa An Modul- Seria Grupa Tip bursa

Prenume studiu Specializare
M1 A R. B 1222…1 Vaslui, … 1 1 A 1 M
M2 W D. E 2222…2 Botoşani, … 1 1 A 2 NULL
M3 O F. D 2222…3 Iaşi, … 1 2 A 2 S1
M4 P H. J 1222…4 NULL 3 C C 3 NULL
M5 R T. U 1222…5 Sibiu, … 4 T G 3 S2
M6 I Y. V 2222…6 Cluj, … 2 2 D 2 S1
M7 J G. F 1222…7 Arad, … 3 D E 1 NULL

Figura 4.1. Relaţia (tabela) STUDENŢI

Fiecare atribut este caracterizat printr-un nume şi un domeniu de valori pe care le poate lua.
Domeniul poate fi definit ca ansamblul valorilor acceptate (autorizate) pentru un element component al
relaţiei :

80
 • într-o tabelă destinată datelor generale ale angajaţilor, pentru atributul Sex, domeniul este
alcătuit din două valori : femeiesc şi bărbătesc ;
• domeniul atributului Judeţ este alcătuit din numele fiecărui judeţ (plus Bucureşti) ;
• domeniul unui atribut precum PreţUnitar, care se referă la preţul la care a fost vândut un
produs/serviciu, este cu mult mai larg, fiind alcătuit din orice valoare cuprinsă între 1 şi 99999999999
lei.
Reţinem corespondenţa noţiunilor relaţie-tabelă, tuplu-linie şi atribut-coloană.
Numărul de tabele pe care le conţine o bază de date, atributele "adunate" în fiecare tabelă,
domeniul fiecăruia dintre atribute prezintă diferenţe majore de la o bază la alta, chiar dacă uneori
reflectă acelaşi tip de procese. Intrăm astfel în sfera proiectării bazelor de date, a dependenţelor şi
normalizării.
În figura 4.1 se observă că atributul Adresa conţine, pe linia (tuplul) 4, o valoare curioasă, notata
NULL. Valoarea NULL este considerată o metavaloare şi indică faptul că, în acel loc, informaţia este
necunoscută sau inaplicabilă. În cazul nostru, studentului P H. J nu i se cunoaşte adresa. Valoarea
NULL este diferită de valorile 0 sau spaţiu.
În încheiere, principalele caracteristici ale unei relaţii sunt sistematizate după cum urmează:
•în cadrul unei baze de date, o relaţie prezintă un nume distinct de al celorlalte relaţii;
• valoarea unui atribut într-un tuplu oarecare conţine a singură valoare (o valoare atomică) ;
• fiecare atribut are un nume distinct;
• orice valoare a unui atribut face parte din domeniul pe care a fost definit acesta ;
• ordinea dispunerii atributelor în relaţie nu prezintă importanţă ;
• fiecare tuplu este distinct, adică nu pot exista două tupluri identice ;
• ordinea tuplurilor nu influenţează conţinutul informaţional al relaţiei.

4.2. Restricţii ale bazei de date

Principalele restricţii definibile în modelul relaţional sunt: de domeniu, de nenulitate, de

atomicitate, de unicitate, referenţiala şi cele definite de utilizator.

Restricţia de domeniu
După cum am văzut în paragraful anterior, un atribut este definit printr-un nume şi un domeniu.
Orice valoare a atributului trebuie să se încadreze în domeniul definit. Există mai multe moduri de
percepţie a acestei restricţii. O parte din informaticieni substituie domeniul tipului atributului: numeric,
şir de caractere, dată calendaristică, logic (boolean) etc., şi, eventual, lungimii (numărul maxim de
poziţii/caractere pe care se poate "întinde" un atribut). După cum se observă, este luat în calcul numai
aspectul sintactic al domeniului. Faptul că anul de studiu al unei clase poate fi una dintre valorile 9, 10,
11, 12 reprezintă o restricţie de comportament sau, mai simplu, o restricţie definită de utilizator.
Cea de-a doua categorie priveşte deopotrivă domeniile sintactic şi semantic. Astfel, domeniul
sintactic al atributului LitClasa (litera) dintr-o relaţie precum ELEVI_LICEU este un caracter,
obligatoriu literă,şi chiar mai restrictiv, litera e obligatoriu majusculă. Din punct de vedere semantic,

81
LitClasa poate lua una dintre valorile: A, B, C, ... , în funcţie de numărul de clase dintr-un an de studiu
(cinci clase de a IX-a, patru de a X-a etc.).
Majoritatea SGBD-urilor permit definirea tuturor elementelor ce caracterizează domeniul
(sintactic şi semantic) atributelor prin declararea tipului şi lungimii atributului şi prin aşa-numitele reguli
de validare la nivel de câmp (field validation rules). Sunt însă şi produse la care domeniul poate fi
definit explicit, sintactic şi semantic, dându-i-se un nume la care vor fi legate atributele în momentul
creării tabelelor.

Nenulitatea
Deşi inventată de însuşi E.P. Codd, valoarea nulă este vehement contestată de cea mai mare parte
a liniei purist-relaţionale (Date, Darwen, Pascal). Nu discutăm aici legitimitatea unei asemenea meta-
valori, ci doar amintim că, într-o bază de date, unora dintre atribute li se poate interzice valoarea NULL.

Atomicitate
Conform teoriei bazelor de date relaţionale, orice atribut al unei tabele oarecare trebuie să fie
atomic, în sensul imposibilităţii descompunerii sale în alte atribute.
În aceste condiţii, se spune că baza de date se află în prima formă normală sau prima formă
normalizată (lNF). în tabela STUDENTI un atribut cu valori neatomice poate fi considerat, pentru
majoritatea situaţiilor, Adresa, întrucat valorile sale îngrămădesc elemente ce pot fi şi individualizate:
stradă, număr, bloc, scară, etaj, apartament, localitate şi judeţ.
Astăzi, atomicitatea valorilor atributelor a devenit o ţintă predilectă a "atacurilor duşmănoase" la
adresa modelului relaţional, datorită imposibilităţii înglobării unor structuri de date mai complexe,
specifice unor domenii ca: proiectare asistată de calculator, baze de date multimedia etc.

Unicitate
Într-o relaţie nu pot exista două linii identice (două linii care prezintă aceleaşi valori pentru toate
atributele). Mai mult, majoritatea relaţiilor prezintă un atribut sau o combinaţie de atribute care
diferenţiază cu siguranţă un tuplu de toate celelalte tupluri ale relaţiei. Cheia primara a unei relaţii
(tabele) este un atribut sau un grup de atribute care identifică fără ambiguitate fiecare tuplu (linie) al
relaţiei (tabelei). Există trei restricţii pe care trebuie sa le verifice cheia primară :
o unicitate: o cheie identifică un singur tuplu (linie) al relaţiei ;
o compoziţie minimală: atunci când cheia primară este compusă, niciun atribut din cheie nu
poate fi eliminat fără distrugerea unicităţii tuplului în cadrul relaţiei; în cazuri limită, o
cheie poate fi alcătuită din toate atributele relaţiei ;
o valori nenule: valorile atributului (sau ale ansamblului de atribute) ce desemnează cheia
primară sunt întotdeauna specificate, deci nenule; mai mult, niciun atribut din compoziţia
eheii primare nu poate avea valori nule. Cea de-a treia condiţie se mai numeşte şi
restricţie a entităţii.
Domeniul unui atribut care este cheie primară într-o relaţie este denumit domeniu primar. Dacă
într-o relaţie există mai multe combinaţii de atribute care conferă unicitate tuplului, acestea sunt
denumite chei candidate. O cheie candidată care nu este identificator primar este referită ca fiind cheie

82
alternativă. În tabela STUDENŢI există două chei candidate, Matricol şi CNP. Pe baza unor criterii
necunoscute (deocamdată), am ales Matricol drept cheie primară, CNP-ul devenind cheie alternativă.
Dacă cheia primară a tabelei STUDENŢI este una simplă, există însă suficiente eazuri în care
cheia primară este compusă din două, trei ş.a.m.d. sau, la extrem, toate atributele relaţiei. Să luăm spre
analiză o relaţie PERSONAL care conţine date generale despre angajaţii firmei. Fiecare tuplu al relaţiei
se referă la un angajat, atributele fiind: Nume, Prenume, DataNaşterii, Vechime, SalariuTarifar.
o Atributul Nume nu poate fi cheie, deoareee chiar şi într-o întreprindere de talie mijlocie
este posibil să existe doi angajati cu acelaşi nume.
o Dacă apariţia a două persoane cu nume identice este posibilă, atunci apariţia a două
persoane cu acelaşi Prenume este probabil.
o Niciunul dintre atributele DataNaşterii, Vechime şi SalariuTarifar nu poate fi "înzestrat"
cu funcţia de identificator.
o În acest caz, se încearcă gruparea a două, trei, patru ş.a.m.d. atribute, până când se obţine
combinaţia care va permite diferenţierea clară a oricărei linii de toate celelalte.
o Combinaţia Nume +Adresa pare, la prima vedere, a îndeplini "cerinţele" de identificator.
Ar fi totuşi o problemă: dacă în aceeaşi firmă (organizaţie) lucrează împreună soţul şi
soţia? Ambii au, de obicei, acelaşi nume de familie şi, tot de obicei, acelaşi domiciliu.
Este adevărat, cazul ales nu este prea fericcit. Dar este suficient pentru compromiterea
combinaţiei.
o Următoarea tentativă este grupul Nume + Prenume + Adresa, combinaţie neoperantă dacă
în organizaţie lucrează tatăl şi un fiu (sau mama şi o fiică), avand aceleaşi nume şi
prenume şi domiciliul comun.
o Ar rămâne de ales una dintre soluţiile (Nume +Prenume +Adresa +Vechime) sau (Nume
+ Prenume +Adresa + DataNaşterii).
Oricare dintre cele două combinaţii prezintă riscul violării restricţiei de entitate, deoarece este
posibil ca, la preluarea unui angajat în bază, să nu i se cunoască adresa sau data naşterii, caz în care
atributul respectiv ar avea valoarea NULL. Dificultăţile de identificare fără ambiguitate a angajaţilor au
determinat firmele ca, la angajare, să aloce fiecărei persoane un număr unic, număr denumit Marca. Prin
adăugarea acestui atribut la cele existente, pentru relaţia PERSONAL, problema cheii primare este
rezolvată mult mai simplu. Actualmente, sarcina este simplificată şi prin utilizarea codului numeric
personal (CNP), combinaţie de 13 cifre care prezintă avantajul că rămâne neschimbată pe tot parcursul
vieţii persoanei.

Restricţia referenţială
O bază de date relaţională este a1cătuită din relaţii (tabele) aflate în legătură. Stabilirea legăturii
se bazează pe mecanismul cheii străine şi, implicit, al restricţiei referenţiale. Figura 4.2 prezintă o relaţie
în care sunt implicate tabelele TIP_BURSE şi STUDENTI. Atributul Tip_Bur sa joacă un rol de "agent
de legătură" între cele două relaţii. Pentru tabela TIP_BURSE, atributul Tip_Bursa este cheie primară, în
timp ce în tabela STUDENTI, Tip_Bursa reprezintă o coloană de referinţă sau cheie străina (externă),
deoarece numai pe baza valorilor sale se poate face legătura cu relaţia-părinte TIP_BURSE. Cheile
străine sau coloanele de referinţă sunt deci atribute sau combinaţii de atribute care pun în legătură linii

83
(tupluri) din relaţii diferite. Tabela în care atributul de legătură este primar se numeşte tabela-părinte (în
cazul nostru, TIP_BURSE), iar cealată, tabelă-copil.
Legat de noţiunea de cheie străina apare conceptul de restricţie referenţială. O restricţie de
integritate referenţială apare atunci când o relaţie face referinţă la o altă relaţie. Când două tabele
(relaţii), T1 şi T2, prezintă atributul sau grupul de atribute notat CH, care pentru Tl este cheie primară,
iar pentru T2 - cheie străină, dacă în T2 se interzice apariţia de valori nenule ale CH care nu există în
niciun tuplu din T1, se spune că între T2 ~i T1 s-a instituit o restricţie referenţială.
Instituirea restricţiei referenţiale între tabelele TIP_BURSE (părinte) şi STUDENŢI (copil)
permite cunoaşterea, pentru fiecare student, a denumirii bursei şi a cuantumului lunar. Dacă în
STUDENŢI ar exista vreo linie în care valoarea atributului Tip_Burse ar fi, spre exemplu S3, este clar
că acea linie ar fi orfană (nu ar avea linie corespondentă în tabela-parinte).

TIP BURSE
Tip bursă Denumire Cuantum
bursă bursă
M Merit 700
NULL
S1 Studiu 1 500

STUDENŢI
Matricol Nume- CNP Adresa An Modul- Seria Grupa Tip bursa
Prenume studiu Specializare
M1 A R. B 1222…1 Vaslui, … 1 1 A 1 M
M2 W D. E 2222…2 Botoşani, … 1 1 A 2 NULL
M3 O F. D 2222…3 Iaşi, … 1 2 A 2 S1

Fig. 4.2. Mecanismul de legare a tabelelor

Observaţii
• Pentru mulţi utilizatori şi profesionişti ai bazelor de date, denumirea de "relaţional" desemnează
faptul că o bază de date este alcătuită din tabele puse în legatură prin intermediul cheilor străine.
Aceasta este, de fapt, a doua accepţiune a termenului de BDR, prima, cea “clasică”, având în
vedere percepţia fiecărei linii dintr-o tabelă ca o relaţie între clase de valori.
• Majoritatea SGBD-urilor prezintă mecanisme de declarare şi gestionare automată a restricţiilor
referenţiale, prin actualizări în cascadă şi interzicerea valorilor care ar indica aceste restricţii.
• Respectarea restricţiilor referenţiale este una dintre cele mai complicate sarcini pentru
dezvoltatorii de aplicaţii ce utilizează baze de date. Din acest punct de vedere, tentaţia este de a
"sparge" baza de date în cât mai puţine tabele cu putinţă, altfel spus, de a avea relaţii cât mai
"corpolente". Gradul de fragmentare a bazei ţine de normalizarea bazei de date, care, ca parte a
procesului de proiectare a BD, se bazează pe dependenţele funcţionale, multivaloare şi de
joncţiune între atribute.

84
Restricţii-utilizator
Restricţiile-utilizator mai sunt denumite şi restricţii de comportament sau restricţii ale
organizaţiei. De obicei, aceste restricţii iau forma unor reguli de validare la nivel de atribut, la nivel de
linie sau de tabelă sau a unor reguli implementate prin declanşatoare (triggers). Spre exemplu, se poate
institui o regulă care interzice emiterea unei noi facturi (o nouă vânzare) dacă datoriile firmei client sunt
mai mari de 2.ooo.ooo.ooo lei, iar directorul acesteia nu este membru în partidul/partidele de
guvernământ.

4.3. Nevoia de normalizare

Unul dintre cele mai bune argumente în favoarea normalizării ţine de punerea în evidenţă a ceea
ce s-ar întâmpla în absenţa sa. Să luăm un prim exemplu, cel din figura 2.3, care este dedicat stocării
datelor privitoare la studenţii unei facultăţi, mai ales în ceea ce priveşte situaţia şcolară a acestora.
Fiecare student are un identificator unic - Matricol -, este înscris la o specializare într-un an de studii şi
susţine examenele la disciplinele din planul de învăţământ. Orice disciplină are alocat un număr de
credite prin planul de învăţământ al specializării. Fiecare student poate susţine un examen de mai multe
ori, până îl promovează (sau este exmatriculat). Astfel, Ionescu I. Ion a picat examenul la Baze de date
în prima sesiune (pe 29 ianuarie 2oo9), dar l-a promovat în restanţe (pe 12 septembrie).

STUDENŢI EXAMENE
Matricol NumePrenume An Specializare CodDisc DenumireDisc NrCredite DataExamen Nota
M1 Ionescu I. Ion 3 Reţele D31 Baze de date 4 29.01.09 4
M2 Popescu P. Petre 3 Reţele D31 Baze de date 4 29.01.09 7
M3 Georgescu G. George 3 Reţele D31 Baze de date 4 29.01.09 6
M4 Florescu F. Florin 3 Reţele D31 Baze de date 4 29.01.09 9
M5 Ionescu I. Ion 3 Reţele D31 Baze de date 4 29.01.09 8
M5 Costescu C. Costin 3 Reţele D31 Baze de date 4 12.09.09 6

Figura 4.3. Relaţie supusă normalizării

Deoarece fiecare linie se referă la un examen susţinut la o anumită dată de un student, cheia
primară a relaţiei este combinaţia (Matricol, CodDisc, DataExamen).

4.3.1. Redundanţe
Este lesne de observat că relaţia de mai sus conţine redundanţe. Astfel, dacă un student susţine,
pe parcursul primelor n semestre de studii, 25 de examene, atunci matricolul, numele, anul şi
specializarea sunt prezente în toate cele 25 de linii. Dacă pentru o disciplină s-au consemnat în baza de
date 15oo de examinări, atunci nu numai codul, ci şi denumirea şi numărul de credite alocat disciplinei
apar de acelaşi număr de ori.

85
 Cu cât baza de date este mai mare, cu atât risipa de spaţiu este mai importantă.Chiar dacă spaţiul
de stocare nu mai este o problemă din punctu1 de vedere al costului, obezitatea unei tabele precum cea
de mai sus poate atrage serioase probleme de viteză în exp1oatare (timpi de aşteptare 1a preluarea noilor
note etc.).

4.3.2. Anomalii la inserare

Să luăm în discuţie studenţii din anul I. După examenul de admitere, ce are loc în lunile iulie şi
septembrie, aceştia sunt înmatriculaţi. Dacă însă baza de date are schema relaţiei de mai sus, preluarea
este imposibilă până în momentul primului examen al studentului respectiv. Aceasta deoarece în cheia
primară sunt incluse şi atributele CodDisc şi DataEx, iar modelul relaţional interzice valori nule pentru
atributele-cheie (restricţia de entitate). Or, la data înmatriculării, studenţii din anul I nu au nici un
examen susţinut, iar prima sesiune e abia în ianuarie, anul urmator, aşa că şi CodDisc şi DataEx sunt în
acel moment NULL.

4.3.3. Anomalii la modificare

Presupunem că într-o şedinţă de catedră se decide ca disciplina Programarea calculatoarelor să
fie redenumită Programare I, titulatură sub care va apărea şi în foile matricole ale studenţilor din actualul
an al III-lea, care vor absolvi specializarea Reţele. În baza de date există câteva sute de înregistrări
referitoare la studenţii examinaţi la această disciplină şi toate trebuie modificate. Dacă, dintr-un motiv
sau altul, modificarea se face numai pe o parte dintre liniile cu pricina, putem afirma că datele îşi pierd
consistenţa. Avem de-a face cu o anomalie de modificare într-o relaţie atunci când modificarea valorii
unui atribut atrage obligativitatea actualizării aceleeaşi valori pe mai multe linii.

4.3.4. Anomalii la ştergere

Anomaliile la ştergere se manifestă atunci când, prin eliminarea unei linii dintr-o tabelă, se pierd
involuntar nu numai informaţiile despre entitatea reflectată de linia respectivă, ci şi alte informaţii.
Astfel, dacă ştergem ultima linie din relaţia de mai sus, cea care conţine nota examenului la Baze de date
susţinut de studentul Georgescu G. George pe 29 ianuarie 2oo9, se pierd nu numai datele despre
examenul respectiv, ci şi toate informaţiile despre studentul Georgescu G. George., deoarece aceasta era
singura linie în care apărea studentul cu pricina.

4.5. Normalizarea
Proiectarea bazelor de date relaţionale (BDR) presupune definirea atributelor, gruparea lor în
tabele, stabilirea legăturilor dintre ele, a mecanismelor de integritate şi securitate, fiind un proces dificil
în care cunoştinţele teoretice, experienţa, inteligenţa, intuiţia şi creativitatea proiectanţilor se îmbină într-
un mod mai mult sau mai puţin armonios.
Structura finală a BD trebuie să asigure un echilibru între, pe de o parte, obţinerea unui volum
maxim de informaţii într-un interval de timp cât mai scurt şi, pe de altă parte, eliminarea anomaliilor de
stocare şi actualizare, toate în condiţiile unui grad apreciabil de securitate şi integritate.
Elaborarea schemei unei BD poate începe (şi) cu gruparea tuturor atributelor bazei de date într-o
singură tabelă (relaţie universală). Dincolo de avantajul compactităţii, lucrul cu o singură relaţie
86
atotcuprinzătoare ridică serioase probleme privind redundanţa datelor şi generează anomalii importante
la adăugarea, modificarea sau ştergerea unor linii (tupluri).
Ca o consecinţă directă, este necesară spargerea bazei în mai multe tabele care să fie legate prin
restricţii de integritate referenţială. Este tocmai obiectivul central a1 normalizării. Spargerea relaţiei nu
trebuie făcută oricum, deoarece apare riscul pierderilor de informaţii. De asemenea, un număr prea mare
de tabele necesită un efort sporit pentru controlul bazei şi respectarea restricţiilor. În plus, trebuie să
ţinem seama de faptul că obţinerea multor informaţii dintr-o bază de date fragmentată este posibilă prin
operaţiunea de joncţiune, mare consumatoare de resurse.
Într-o enumerare, principalele obiective ale normalizării sunt:
o minimizarea spaţiului necesar stocării datelor ;
o minimizarea riscului apariţiei de date inconsistente în cadrul BD ;
o minimizarea anomaliilor ce pot apărea la actualizare (inserarea datelor, dar mai ales
modificări şi ştergeri) ;
o ameliorarea structurii bazei, reprezentarea diverselor conexiuni dintre atributele bazei;
o diminuarea nevoii de reorganizare periodică a modelului.

Obiect al numeroase studii, nu se poate afirma că există o unanimitate de idei şi instrumente

privind normalizarea. Importanţa normalizării nu trebuie absolutizată, deoarece aceasta vine adesea în
contradicţie cu parametri extrem de importanţi ai aplicaţiilor de lucru cu bazele de date: viteza de acces,
securitate mărita, resurse hard/soft disponibile, reducerea traficului pe reţea etc. Se poate spune că o BD
riguros normalizată nu este neapărat una optimă.
Teoria clasică a normalizarii este construită în jurul a două forme care în literatură sunt referite
ca normale sau normalizate. Deşi termenul original este “normal form” (şi nu ”normalized form”), mai
uzuală este sintagma “forma normalizată”. Pentru a fi într-o anumită formă normală/normalizată, o bază
de date trebuie să respecte un anumit set de restricţii.
Codd, părintele modelului relaţional, a definit iniţial trei forme normale, notate prin 1NF, 2NF ţi
3NF. Întrucat, într-o primă formulare, definiţia 3FN ridică ceva probleme, Codd şi Boyce au elaborat o
nouă variantă, cunoscuta sub numele Boyce-Codd Normal Form (BCNF). Deşi este vorba, în principiu,
despre o formulare mai riguroasă a aceleeaşi 3FN, BCNF este prezentată separat în majoritatea
lucrărilor.
Formele 4 şi 5, legate de numele lui Ronald Fagin, sunt tratate mai cu reţinere în literatura
consacrată analizei şi proicetării bazelor de date. Unele lucrări cu tentă mai pragmatica se opresc
declarat la 3FN, pe care o consideră suficientă în elaborarea BDR.

4.5.1. Etapele normalizării

Fundamentul normalizării BDR îl constituie dependenţele dintre atribute. Primele trei forme
normale pot fi determinate pe baza dependenţelor funcţionale elementare (totale) şi tranzitive. Forma a
patra (4FN) se bazează pe dependenţele multivaloare, în timp ce a cincea formă normală (5FN) - pe
dependenţele de joncţiune. Problema este că dependenţele multivaloare şi (mai ales) cele de joncţiune
sunt dificil de identificat şi rar întâlnite în practică.

87
 Normalizarea BDR poate fi imaginată ca un proces prin care, pornindu-se de la relaţia iniţială R
(universală), se realizează descompunerea succesivă a acesteia în subrelaţii, după succesiunea din figura
4.4. Relaţia R poate fi ulterior reconstruită din cele n relaţii obţinute în urma normalizării, prin operaţii
de joncţiune aplicate asupra acestora.

Relaţie universală R

nu Există grupuri repetitive? da

Atomizarea atributelor

nu Releţia R are cheie primară? da

Descompunerea în relaţii ce au cheie primară

1FN

nu Există DF parţiale? da

Atomizarea atributelor

2FN

nu Există DF tranzitive? da

Aducerea relaţiilor în 3FN

88

3FN
 nuToţi determinanţii sunt chei candidate?da

Aducerea relaţiilor în BCFN

BCFN

nu Există DF multivaloare? da

Aducerea relaţiilor în 4FN

4FN

nu Există dependenţe de joncţiune ? da

Aducerea relaţiilor în 5FN

5FN

Fig. 4.4 Etapele clasice ale normalizării bazelor de date relaţionale

Concluzionând, o relaţie este într-o formă normală dacă satisface o mulţime de constrângeri
specificată în figura 4.5. De exemplu, se spune că o relaţie se află în a doua formă normală 2FN dacă şi
numai dacă se află în 1FN.

89
 Relaţia universală
1FN
2FN
3FN
BCFN
4FN
5FN

Fig. 4.5. Formele normale ale relaţiilor dintr-o BDR

Normalizarea bazei de date relaţionale poate fi imaginată ca un proces prin care pornindu-se de la
relaţia iniţială/universală R se realizează descompunerea succesivă a acesteia în subrelaţii, aplicând
operatorul de proiecţie. Relaţia R poate fi ulterior reconstruită din cele n relaţii obţinute în urma
normalizării, prin operaţii de joncţiune.

4.5.2. Prima formă normală (1FN)

1FN este strâns legată de noţiunea de atomicitate a atributelor unei relaţii. Astfel, aducerea unei
relaţii în 1FN presupune introducerea noţiunilor de:

 atribut simplu;
 atribut compus;
 grupuri repetitive de atribute.

 Atributul simplu- Atribut compus

Prin atribut simplu (atribut atomic) se înţelege un atribut care nu mai poate fi descompus în alte
atribute, în caz contrar, atributul este compus (atribut neatomic).

Exemplu: Următoarele exemple de atribute pot fi considerate simple sau compuse în funcţie de
circumstanţe şi de obiectivele bazei de date.

 Data calendaristică – este un atribut în care apar câmpurile: zi, lună, an;
 Adresa – este un atribut în care apar câmpurile: strada, nr, bloc, scara, etaj, apartament, localitate,
judeţ;
 Data operaţiunii bancare – este un atribut în care apar câmpurile data, ora;
 Buletin/carte identitate – este un atribut în care apar câmpurile: seria, nr.
Aceste atribute pot fi atomice sau neatomice. Astfel adresa clienţilor agenţiei imobiliare
interesează la nivel global, pe când pentru adresa ofertei sau a cererii de imobile este vitală prelucrarea
separată a fiecărui câmp considerat.

Analog, atributul „nume” reprezentă un atribut simplu al acestei baze de date, deoarece numele
clientului interesează la nivel global.

90
 Grupuri repetitive de atribute
Un grup repetitiv este un atribut (grup de atribute) dintr-o relaţie care apare cu valori multiple
pentru o singură apariţie a cheii primare a relaţiei nenormalizate.

Exemplu: Fie relaţia nenormalizată (primară) FACTURI. Dorim să stabilim o structură de tabele care să
permită stocarea informaţiilor conţinute în document (factură) şi obţinerea unor situaţii sintetice privind
evidenţa sumelor facturate pe produse, pe clineţi, pe anumite perioade de timp.

FACTURI
nr_factura#
data_factura
nume_client
adresa_client
banca_client
nr_cont_client
delegat
cod_produs
denumire_produs
unitate_de_masura
cantiate
pret_unitar
valoare
valoare_tva
total_valoare_factura
total_valoare_tva

Fig. 4.6. Relaţia FACTURI nenormalizată

În cazul în care o factură conţine mai multe produse, relaţia de mai sus va avea grupurile
repetitive: „cod_produs”, „denumire_produs”, „cantitate”, „pret_unitar”, „valoare”, „valoare_tva”.

Aducerea unei relaţii universale la 1FN

1FN este tratată în general cu superficialitate, deoarece principala cerinţă – atomicitatea valorilor
– este uşor de îndeplinit (cel puţin la prima vedere).
Dintre toate formele normale, doar 1FN are caracter de obligativitate. Se spune că o bază de date
este normalizată daca toate relaţiile se află măcar în 1FN.

91
 O relaţie este în 1FN dacă domeniile pe care sunt definite atributele relaţiei sunt constituite
numai din valori atomice. Un tuplu nu trebuie să conţină atribute sau grupuri de atribute repetitive.
Aducerea relaţiilor în 1FN presupune eliminarea atributelor compuse şi a celor repetitive.
Se cunosc trei soluţii pentru determinarea grupurilor repetitive:
 eliminarea grupurilor repetitive pe orizontală (în relaţia R iniţială, în locul atributelor compuse se
trec componentele acestora, ca atribute simple);
 eliminarea grupurilor repetitive prin adăugarea de tupluri;
 eliminarea grupurilor repetitive prin construirea de noi relaţii
Primele două metode generează relaţii stufoase prin duplicarea forţată a unor atribute, respectiv
tupluri, creându-se astfel redundanţe masive cu multiple anomalii de actualizare.
Metoda a treia presupune eliminarea grupurilor repetitive prin construirea de noi relaţii, ceea ce
generează o structură ce oferă cel mai mic volum de redundanţă.
Etapele de aducere a unei relaţii în 1FN sunt:
1. se construieşte câte o relaţie pentru fiecare grup repetitiv;
2. în schema fiecărei noi relaţii obţinute la pasul 1 se introduce şi cheia primară a relaţiei R
nenormalizate;
3. cheia primară a fiecărei noi relaţii va fi compusă din atributele chei ale relaţiei R, plus
unul sau mai multe atribute proprii.

Exemplu: Deoarece o factură poate avea unul sau mai multe produse înscrise pe aceasta, informaţiile
legate de produse vor fi separate într-o altă tabelă. Aplicând etapele de aducere la 1FN, se obţin două
relaţii:
FACTURI LINII_FACTURI
nr_factura# nr_factura#
data_factura cod_produs#
nume_client denumire_produs
adresa_client unitate_de_masura
banca_client cantiate
nr_cont_client pret_unitar
delegat valoare
total_valoare_factura valoare_tva
total_valoare_tva

Fig. 4.7. Relaţia FACTURI adusă în forma normală 1FN

Observaţia1:
Câmpul „adresa_client” curpinde informaţii despre judeţul, localitatea, strada şi numărul
domicililului clientului. Dacă se consideră că este de interes o evidenţă a sumelor factorizate pe judeţe
sau localităţi, se vor pune în locul câmpului „adresa_client” trei câmpuri distincte: „judet_client”,
„localitate_client”, „adresa_client”, uşurând în acest fel interogările.
Observaţia2:
92
 Între tabela FACTURI şi tabela LINII_FACTURI există o relaţie de „unu la mulţi”, adică unui
număr unic de factură îi pot corespunde unul sau mai multe produse care sunt memorate ca înregistrări
în tabele LINII_FACTURI. Cheia primară în această tabelă este o cheie compusă, formată din două
câmpuri: „nr_factura” şi „cod_produs”.
Eliminarea grupurilor repetitive, adică aducerea unei relaţii la 1FN, nu rezolvă complet problema
normalizării.

4.5.3. A doua formă normală (2FN)

2FN este strâns legată de noţiunea de dependenţă funcţională.

O relaţie se află în a doua formă normală 2FN dacă:
1. se află în forma normală 1FN şi
2. fiecare atribut care nu este cheie este dependent de întreaga cheie primară.
Etapele de aducere a unei relaţii de la 1FN la 2FN sunt:
I. Se identifică posibila cheie primară a relaţiei aflate în 1FN;
II. Se identifică toate dependenţele dintre atributele relaţiei, cu excepţia acelora în care sursa este un
atribut component al cheii primare;
III. Se identifică toate dependenţele care au ca sursă un atribut sau subansamblu de atribute din cheia
primară;
IV. Pentru fiecare atribut (sau subansamblu) al cheii de la pasul III se creează o relaţie care va avea
cheia primară atributul (subansamblul) respectiv, iar celelalte atribute vor fi cele care apar ca
destinaţie în dependenţele de la etapa III.

Exemplu:
Relaţia care conţine date redundante (de exemplu, modificarea denumirii unui produs atrage
după sine modificarea în fiecare tuplu în care apare acest produs) este relaţia LINII_FACTURI. Se
observă ca nu există nici o dependenţă funcţională între atributele necomponente ale cheii. În schimb,
toate atributele care nu intră în alcătuirea cheii compuse sunt dependente de aceasta, iar DF dintre
atributul component al cheii primare sunt: cod_produs --> denumire_produs, cod_produs -->
unitate_de_masura. Ca urmare se formează încă două relaţii.

FACTURI LINII_FACTURI PRODUSE

nr_factura# nr_factura# cod_produs#

data_factura cod_produs# denumire_produs
nume_client cantiate unitate_de_masura
adresa_client pret_unitar
banca_client valoare
nr_cont_client valoare_tva
delegat 93
total_valoare_factura
total_valoare_tva
 Fig. 4.8. Relaţia FACTURI în a doua forma normală 2FN

Chiar dacă au fost eliminate o parte din redundanţe, mai rămân şi alte redundanţe ce se vor
elimina aplicând alte forme normale.

4.5.4. A treia formă normală (3FN)

O relaţie este în forma normală trei 3FN dacă:

1. se găseşte în 2FN şi
2. fiecare atribut care nu este cheie (nu participă la o cheie) depinde direct de cheia primară.
A treia regulă de normalizare cere ca toate câmpurile din tabele să fie independente între ele.
Etapele de aducere a unei relaţii de la 2FN la 3FN sunt:
I. Se identifică toate atributele ce nu fac parte din cheia primara şi sunt surse ale unor dependenţe
funcţionale;
II. Pentru aceste atribute, se construieşte câte o relaţie în care cheia primară va fi atributul respectiv,
iar celelalte atribute, destinaţiile din DF considerate;
III. Din relaţia de la care s-a pornit se elimină atributele destinaţie din DF identificată la pasul I,
păstrându-se atributele surse.

Exemplu:
În relaţia FACTURI se observă că atributul „nume_client” determină în mod unic atributele
„adresa_client”, „banca_client” şi „nr_cont_client”. Deci pentru atributul „nume_client” se construieşte
o relaţie CLIENTI în care cheia primară va fi acest atribut, iar celelalte atribute vor fi „adresa_client”,
„banca_client” şi „nr_cont_client”. Câmpurile „valoare” şi „valoare_tva” depind de câmpurile
„cantitate”, „pret_unitar”, şi de un procent fix de TVA. Fiind câmpuri ce se pot calcula în orice moment
ele vor fi eliminate din tabelă LINII FACTURI deoarece constituie informaţie memorată redundant.

FACTURI LINII_FACTURI PRODUSE CLIENTI

nr_factura# nr_factura# cod_produs# nume_client#

data_factura cod_produs# denumire_produs adresa_client
nume_client cantiate unitate_de_masura banca_client
delegat pret_unitar nr_cont_client
total_valoare_factura
total_valoare_tva
94
 Fig. 4.9. Relaţia FACTURI în a treia forma normală 3FN

Observaţia 1:
Această a treia formă normală mai poate suferi o serie de rafinări pentru a putea obţine o
structură performantă de tabele ale bazei de date. De exemplu se observă că „nume_client” este un câmp
în care este înscris un text destul de lung format dintr-o succesiune de litere, semne speciale (punct,
virgulă, cratimă), spaţii, numere. Ordonarea şi regăsirea informaţiilor după astfel de câmpuri este lentă
şi mai greoaie decât după câmpuri numerice. Din acest motiv se poate introduce un nou atribut
„cod_client” care să fie numeric şi care să fie cheia primară de identificare a pentru fiecare client.
Observaţia 2:
O altă observaţie care poate fi făcută în legătură cu tabelele aflate în cea de a treia formă normală
este aceea că „total_valoare_factura” este un câmp care ar trebui să conţină informaţii sintetice obţinute
prin însumarea valorii tuturor ofertelor aflate pe o factură. Este de preferat ca astfel de câmpuri să fie
calculate în rapoarte sau interogări şi să nu fie memorate în tabelele bazei de date.

FACTURI LINII_FACTURI PRODUSE CLIENTI

nr_factura# nr_factura# cod_produs# cod_client#

data_factura cod_produs# denumire_produs nume_client
delegat cantiate unitate_de_masura adresa_client
pret_unitar banca_client
nr_cont_client

Fig. 4.9. Relaţia FACTURI în a treia forma normală 3FN (modificată)

Verificarea aplicării corecte a procesului de normalizare se realizează astfel încât uniunea

acestora să producă relaţia iniţială, cu alte cuvinte, descompunerea este fără pierderi.
Celelalte forme normale se întâlnesc mai rar în practică. Aceste forme nu sunt respectate, în
general, pentru că beneficiile de eficienţă pe care le aduc nu compensează costul şi munca de care este
nevoie pentru a le respecta.

95
 5. METODOLOGIA DE PROIECTARE CONCEPTUALĂ A
BAZELOR DE DATE

Proiectarea unei baze de date cuprinde următoarele etape:

-proiectarea conceptuală

- proiectarea logică

- proiectarea fizică.

5.1. Proiectarea conceptuală a bazei de date

Proiectarea conceptuală a bazei de date este procesul de construire a unui model al

informaţiilor utilizate în întreprindere, independent de consideraţiile de ordin fizic (SGBDul utilizat).

5.1.1. Construirea modelului de date conceptual local pentru fiecare vedere a

utilizatorilor
De regulă vederea unui utilizator este o zonă funcţională a întreprinderii (de exemplu
producţia, marketingul, vânzările, resursele umane, contabilitatea, aprovizionarea etc.). utilizatorul
este o persoană reală individuală sau un grup de persoane. identificarea vederilor utilizatorilor se
realizează prin examinarea diagramelor de flux şi prin chestionarea utilizatorilor.

Modelul de date conceptual corespunzător vederii unui utilizator se numeşte model de date
conceptual local corespunzător vederii respective. Fiecare model de date conceptual local cuprinde
elementele enumerate în tabelul de mai jos, din care se desprind sarcinile de proiectare
conceptuală.

Elemente ale modelului de Sarcini pentru construirea modelului conceptual local

date conceptual local
(Paşi)

Tipuri de entităţi 1.1. Identificarea tipurilor de entităţi (t.e.)

Tipuri de relaţii 1.2. Identificarea tipurilor de relaţii (t.r.)

Atribute 1.3. identificarea şi asocierea atributelor cu t.e. şi t.r.

Domeniile atributelor 1.4. Determinarea domeniilor atributelor

Cheile candidat 1.5. Determinarea atributelor chei candidat şi chei primare

Cheile primare

96
 1.6. Specializarea/generalizarea t.e. (opţional)

1.7. Desenarea diagramei ER

1.8. Revizuirea modelului conceptual local cu utilizatorii

5.1.2. Identificarea tipurilor de entităţi (t.e.)

Modalităţi de identificare:

- studierea specificaţiei cerinţelor utilizatorului referitor la funcţia utilizatorului în

întreprindere; se caută substantivele în specificaţia cerinţelor utilizatorului (de exemplu
Nr_Personal; NumeP; Nr_Proprietate; AdresaP; Chirie etc.)

- se caută obiectele principale de interes, excluzându-se calităţile; se grupează (de exemplu

Nr_Personal şi NumeP vor aparţine aceluiaşi tip de entitate Personal)

- se identifică obiectele care există pe cont propriu (de exemplu Personal există indiferent de
Nr_Personal, NumeP, etc.)

- discuţii cu utilizatorii (de exemplu pentru eliminarea sinonimelor: Angajat = Personal)

Documentarea t.e.: după identificarea t.e. li se atribuie denumiri evidente, care se trec într-
un dicţionar de date.

5.1.3. Identificarea tipurilor de relaţii (t.r.)

- Identificarea relaţiilor: de regulă relaţiile sunt indicate de expresii verbale în specificaţia

utilizatorului. De exemplu: filiale are personal; personal administrează proprietate; chiriaş
vizitează proprietate etc. Interesează numai relaţiile dintre entităţi cerute. Majoritatea
relaţiilor sunt binare. Este bine de verificat fiecare pereche de tipuri de entităţi, pentru a găsi
o posibilă relaţie între ele.

- Determinarea cardinalităţii (1:1; 1:M; M:N) şi constrângerilor de participare (totală, parţială);

eventual se specifică şi valorile limită ale cardinalităţii.

- Documentarea tipurilor de relaţii. Pe măsură ce sunt identificate, li se atribuie denumiri

evidente; acestea, precum şi constrângerile se trec în dicţionarul de date.

- Vizualizarea pe parcurs a t.e. şi t.r. identificate prin modelarea ER.

5.1.5. Identificarea şi asocierea atributelor cu t.e. sau t.r.

- Identificare: Se caută substantive sau expresii substantivale în specificaţia cerinţelor

utilizatorilor care să caracterizeze t.e. şi t.r. găsite. Atributele sunt proprietăţi, calităţi,

97
 caracteristici identificatoare ale unei entităţi sau relaţii. Se deosebeşte între atribute simple,
compuse, derivate. Atributele derivate trebuie reprezentate în modelul conceptual pentru a
nu pierde informaţii.

- Documentarea atributelor: pe măsură ce sunt identificate li se atribuit denumiri evidente şi

semnificative pentru utilizatori. Pentru fiecare atribut se trec în dicţionarul de date:
denumirea, sinonime sau aliasuri, tipul de date şi lungimea, eventuale valori prestabilite
(default value), dacă se acceptă Null-uri (required), dacă e compus sau derivat, formula de
calcul, dacă are valori multiple.

5.1.6. Determinarea domeniilor atributelor

- Determinarea: Domeniul este un recipient de valori din care unul sau mai multe atribute îşi
iau valorile. De exemplu domeniul numerelor de filială valabile este compus din 3 caractere,
literă-cifră-literă. Domeniul va include şi mulţimea valorilor permise, dimensiunea şi
formatul câmpului.

- Documentarea domeniului atributelor: se înregistrează denumirea şi caracteristicile

domeniilor atributelor în dicţionarul de date.

5.1.7. Determinarea atributelor chei candidat şi chei primare

- identificare: pentru fiecare entitate se identifică toate cheile candidat şi se secţionează

dintre ele cheia primară. O cheie candidat este o submulţime minimă de atribute ale unei
entităţi, care identifică în mod unic fiecare apariţie a acesteia. Cheia primară aleasă va
îndeplini următoarele criterii:

o va cuprinde un set minim de atribute

o va fi cheia candidat cu cea mai mică probabilitate de modificare a valorilor

o va fi cheia candidat cu cea mai mică probabilitate de a-şi pierde caracterul de

unicitate

o va fi cheia candidat cu cele mai puţine caractere

o va fi cheia candidat cel mai uşor de utilizat d.p.d.v. al utilizatorilor

Unei entităţi tari i se poate identifica o cheie primară, nu şi unei entităţi slabe. Unei entităţi slabe
i se poate identifica o cheie primară numai prin plasarea în ea a unei chei străine, în cadrul
relaţiei sale cu entitatea tare.

Cheile candidat care nu sunt selectate cheie primară devin chei alternative.

- Documentarea cheilor primare şi alternative prin înregistrare în dicţionarul de date.

98
5.1.8. Specializarea/generalizarea tipurilor de entităţi (opţional)

Acest pas este dictat de reprezentarea cât mai clară a entităţilor importante şi a relaţiilor
dintre ele. Diagrama ER finală trebuie să fie cât mai lizibilă.

Modelul ER din figura 5.1 a conţine entităţile Proprietate_de_Inchiriat şi Proprietate_de_Vanzare. Se

generalizează prin crearea entităţii Proprietate (fig. 5.1 b.)

Nr.
Nr. Chiriaş Chirie Preţ Cumpărător
Tip Tip

M N Proprietate de M
Proprietate de închiriat vânzare 1
Chiriaş Cumpără Cumpărător
Închiriază
Nr. Proprietate
Nr. Proprietate M M
Deţine
Adresa Adresa
1
Proprietar

Nr.
Proprietar

Nr.
Nr. Chiriaş Chirie Preţ Cumpărător

M N Proprietate de M
Proprietate de închiriat vânzare 1
Chiriaş Cumpără Cumpărător
Închiriază

a)
d
Tipul
M 1
Proprietate Deţine Proprietar

Adresa
Nr.
Proprietate Nr.
Proprietate

99
b)

Fig. 5.1. Exemplu de generalizare a tipului de entitate

Entităţile Proprietate_de_Inchiriat şi Proprietate_de_Vanzare devin subclase ale entităţii Proprietate

în baza atributelor comune (Tipul, Adresa, cheia primară) şi în baza relaţiilor comune asociate
fiecăreia (Proprietar_deţine_Proprietate).

Entităţile subclasă au şi atribute diferite (Chirie respectiv Preţ) şi relaţii diferite (Inchiriaza respectiv
Cumpara).

5.1.9. Desenarea diagramei ER

Diagrama ER care se desenează va fi reprezentarea conceptuală a vederii unui utilizator

asupra întregii întreprinderi. Diagrama ER va reprezenta modelul de date conceptual local bazat pe o
anumită vedere a utilizatorului asupra întreprinderii.

5.1.10. Revizuirea modelului de date conceptual local împreună cu utilizatorii

Acest pas este necesar pentru a garanta că modelul este o reprezentare „adevărată” a
întreprinderii d.p.d.v. al utilizatorului.

100
5.1.11. Rezumat
Proiectarea conceptuală a bazei de date este procesul de construire a unui model al
informaţiilor utilizate în întreprindere, independent de consideraţiile de ordin fizic.

Proiectarea conceptuală începe prin crearea unui model de date conceptual al întreprinderii,
complet independent de detaliile de implementare. Pentru fiecare vedere a utilizatorilor asupra
întreprinderii este creat un model de date conceptual local.

O vedere a utilizatorului constă în datele cerute de către un anumit utilizator pentru a lua o
decizie sau a efectua o anumită sarcină. De regulă vederea unui utilizator este o zonă funcţională a
întreprinderii. Un utilizator poate fi o persoană sau un grup de persoane care utilizează în mod direct
sistemul.

Vederile utilizatorilor se pot identifica utilizând diagrame de flux de date – care definesc
zonele funcţionale şi eventual funcţiile individuale – sau/şi prin chestionarea utilizatorilor,
examinarea procedurilor, rapoartelor şi observarea întreprinderii.

Fiecare model de date conceptual local cuprinde tipurile de entităţi, tipurile de relaţii, atributele,
domeniile atributelor, cheile candidat şi primare.

Fiecare model de date conceptual local este susţinut de către o documentaţie, cum ar fi
dicţionarul de date, care este realizat pe parcursul dezvoltării modelului.

5.2. Proiectarea logică

Proiectarea logică este procesul de construire a unui model al informaţiilor utilizate în

întreprindere pe baza unui anumit model de date, dar independent de SGBD şi de alte consideraţii
de ordin fizic.

5.2.1 Construirea şi validarea modelului de date logic pentru fiecare vedere a

utilizatorilor
Acest pas este bazat pe modelul de date conceptual al vederii utilizatorului asupra
întreprinderii. Se efectuează modificarea structurii modelului conceptual conform cerinţelor
modelului de date relaţional (conform cerinţelor caracteristice unui sistem de gestionare relaţional).

5.2.1.1 Transpunerea modelului de date conceptual local într-un model de date logic local

Se rafinează modelul de date conceptual local prin eliminarea caracteristicilor nedorite.

101
5.2.1.1.1 Eliminarea relaţiilor de tip M:N

O relaţie M:N (de mai mulţi la mai mulţi) se descompune pentru a identifica o relaţie
intermediară. Relaţia M:N se înlocuieşte cu două relaţii 1:M.

Exemplu: Relaţia Ziar Face Reclama Proprietate (fig. 5.2. a) este de cardinalitate M:N, deoarece un
ziar poate face reclamă mai multor proprietăţi, iar unei proprietăţi i se poate face reclamă in mai
multe ziare.

Relaţia se descompune conform figurii 5.2. b, unde Reclama este o entitate slabă a cărei
existenţă depinde de existenţa celorlalte două entităţi tari.

Nr. Proprietate
Nume ziar

M N
Ziar Face reclama Proprietate

Nr. Proprietate
Nume ziar

1 N M 1
Ziar Listeaza Reclama Reclama In Proprietate
a)

b)

102
 Fig. 5.2. Relaţia de cardinalitate M:N se descompune în 2 relaţii de cardinalitate 1:M

Apar două tipuri de relaţii noi: Listeaza şi respectiv ReclamaIn care leagă entitatea slabă de
cele 2 entităţi tari.

5.2.1.1.2 Eliminarea relaţiilor complexe

O relaţie complexă include cel puţin trei tipuri de entităţi. Ea trebuie descompusă pentru a
identifica o relaţie intermediară. Relaţia complexă se înlocuieşte cu un număr corespunzător de
relaţii binare de cardinalitate 1:M.

În exemplul din figura 5.3. relaţia complexă Inchiriaza s-a descompus în trei relaţii 1:M,
anume Organizeaza, AsociatCu şi Ţine; s-a identificat o entitate slabă: Acord_de_Inchiriere care este
legată de entităţile tari (iniţiale) prin cele trei relaţii binare de cardinalitate 1:M identificate. Analizaţi
constrângerile de participare din fig. 5.3. a şi 5.3. b!

Nr. Proprietate
Nr. Personal

M M
Personal Inchiriaza Proprietate

Chirias

Nr. Chirias

Nr. Proprietate
Nr. Personal
103
1 M M 1
Personal Organizeaza Proprietate Asociat cu Proprietate
 M

Ţine

Chirias

Nr. Chirias

a)

b)

Fig. 5.3. Relaţie complexă M:N descompusă în trei relaţii binare 1:M.

104
5.2.1.1.3 Eliminarea relaţiilor recursive

Acesta este un tip particular de relaţie care trebuie descompusă pentru a identifica o relaţie
intermediară. În exemplul din figura 5.4. relaţia recursivă Supravegheaza este eliminată prin
identificarea unei relaţii adiţionale denumită SupravegheatDe şi a unei entităţi slabe:
Personal_Alocat.

Supervizează

1 M

Personal

Nr_Personal

Personal_Alocat
1 M

a)

SupravegheatDe Supervizează

1 1

Personal
105

Nr_Personal
 b)

Fig. 5.4. Eliminarea unei relaţii recursive

5.2.1.1.4 Eliminarea relaţiilor cu atribute

Atunci când o relaţie are asociat un atribut, acest lucru sugerează existenţa unui tip de
entitate neidentificat. Exemplul din figura 5.5 se referă la determinarea numărului de ore lucrate de
angajaţii temporari atribuiţi fiecărei filiale. Relaţia LucreazaLa are atributul Ore-Lucrate şi este de
cardinalitate M:N. Se descompune în două relaţii binare de cardinalitate 1:M. Acum atributul
Ore_Lucrate aparţine noii entităţi slabe identificate: Alocaţie_Filiala. Analizaţi constrângerile de
participare din fig. 5.5 a şi 5.5. b!

106
 Ore_Lucrate Nr. Filială
Nr. Personal

M N
Personal Lucrează La Filiala

Ore_Lucrate Nr. Filială

Nr. Personal
a)

N M N
1
Personal Atribuit La Alocaţie_Filiala Necesită Filiala

b)

Fig. 5.5. Eliminarea unei relaţii cu atribut

5.2.1.1.5 Eliminarea atributelor cu valori multiple

Este vorba de atribute cu mai multe valori pentru o singură entitate. Acest atribut trebuie
descompus pentru a identifica o nouă entitate. Exemplul din figura 5.6. se referă la evidenţa

107
filialelor, unde o filială poate avea mai multe numere de telefon. Se identifică o nouă entitate:
Telefon, legată de entitatea Filiala prin relaţia Are.

Nr. Telefon Nr. Filială

Adresă

Filiala

Nr. Filială
Nr. Telefon

M 1
Telefon Are Adresa
Filiala

Fig. 5.6. Eliminarea atributelor cu valori multiple

5.2.1.5 Reexaminarea relaţiilor 1:1

Asemenea relaţii pot indica existenţa a două relaţii care să reprezinte acelaşi obiect în cadrul
întreprinderii. De exemplu entităţile Filiala şi departament pot fi sinonime. În astfel de situaţii cele

108
două entităţi se îmbină, selectând una din cheile primare, dacă acestea nu coincid. Cealaltă cheie
primară devine alternativă.

5.2.1.1.7 Eliminarea relaţiilor redundante

O relaţie este redundantă atunci când aceeaşi informaţie se poate obţine şi prin alte relaţii.
Trebuie deci de aflat dacă există mai mult decât o singură cale între două entităţi. Dacă se identifică
2 căi, nu înseamnă neapărat că una din relaţii este redundantă. Trebuie de ţinut cont şi de
semnificaţia temporală a relaţiilor.

1 1
Bărbat CăsătoritCu Femeie

1 1

Tatăl lui Mama lui

1
M
M
Copil

Fig. 5.7. Relaţie neredundantă!

În exemplul din figura 5.7. relaţia este neredundantă, deşi există 2 căi intre entitatea Copil şi
Barbat. Tatăl ar putea avea copii dintr-o căsătorie precedentă, sau ar putea să nu fie căsătorit cu
mama copilului, iar în figură se modelează numai căsătoria curentă a tatălui.

5.2.1.2 Extragerea relaţiilor (tipurilor de entităţi) din modelul de date logic local

În urma 5.2.1.1 s-a obţinut modelul de date logic local, ca urmare a rafinării modelului de
date conceptual.

La 5.2.1.2. se extrag relaţiile pentru a reprezenta entităţile care le compun. Componenţa

fiecărei relaţii va fi descrisă utilizând un limbaj de definire a bazelor de date (DBDL). Într-un DBDL
apare denumirea relaţiei, apoi între paranteze atributele simple. Se identifică cheia primară, cheile
alternative şi/sau cheile străine ale relaţiei. Se trece relaţia care conţine cheia străină ca şi cheie
primară.

109
 Relaţia pe care o entitate o are cu altă entitate este exprimată prin mecanismul cheie
primară – cheie străină. Adică cheia primară din entitatea părinte devine cheie străină în entitatea
copil.

În continuare se prezintă cum relaţiile care reprezintă entităţile şi relaţiile acestora sunt
extrase din structurile de date posibile, prezentate în modelul de date logic (fig. 5.8.).

Strada Oraşul
Prenume
Nume

Nume_ Prenume CodPoştal

Adresa

Nr_Filială
Adresa
Funcţie Administrează
1
1
Salariu Personal Filiala
M Nr. Fax
Are 1
Sex 1
Nr_Personal Nr. Tel.

ÎnruditCu

Rudenie M

Rudă Apropiată

NumeR
Nr. Tel.
Adresa

110
 Fig. 5.8. Model de date logic

Din acest model de date logic se extrag:

a. Tipuri de entităţi tari:

Pentru fiecare entitate tare (obişnuită) se creează o relaţie care să cuprindă toate atributele
sale simple.

Exemplu: entitatea tare Personal

Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu)

Cheie primară Nr_Personal

b. Tipuri de entităţi slabe: Ruda_Apropiata.

Pentru fiecare entitate slabă se creează o relaţie care să cuprindă toate atributele sale simple. În plus
se include cheia primară a entităţii părinte (sau proprietar) ca şi cheie străină.

111
Compoziţia acestei relaţii va fi:

Ruda_Apropiata (Nr_Personal, NumeR, Adresa, Nr_Tel, Rudenie)

Cheie primară Nr_Personal împreună cu NumeR

Cheie străină Nr_Personal se referă la Personal (Nr_Personal)

c. Tipuri de relaţii binare unu la unu (1:1)

În relaţia de cardinalitate 1:1 Personal Administreaza Filiala entitatea părinte este Personal,
deoarece are participare parţială. Ca urmare se plasează o copie a cheii primare din Personal în
Filiala, unde devine cheie străină sub denumirea Nr_Personal_Manager.

Compoziţia acestor relaţii va fi:

Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu)

Cheie primară Nr_Personal

Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)

Cheie primară Nr_Filiala

Cheie alternativă Nr_Tel sau Nr_Fax

Cheie străină Nr_Personal_Manager, care se referă la Personal (Nr_Personal)

d. Tipuri de relaţii binare unu-la-mai-mulţi (1:M)

Pentru fiecare relaţie binară 1:M între entităţile E1 şi E2 se plasează o copie a cheii primare
din E1 în E2, unde devine cheie străină. Entitatea aflată în partea notată cu „1” este entitatea
părinte, iar cea din partea cu „M” este entitatea copil. Întotdeauna cheia primară din entitatea
părinte devine cheie străină în entitatea copil.

Exemplu: Filiala Are Personal, unde Filiala este părinte iar personal este copil.

Compoziţia acestor relaţii va fi:

112
Personal (Nr_Personal, Prenume, Nume, Strada, Orasul, CodP, Functia, Sex, Salariu, Nr_Filiala)

Cheie primară Nr_Personal

Cheie străină Nr_Filiala se referă la Filiala (Nr_Filiala)

Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)

Cheie primară Nr_Filiala

Cheie alternativă Nr_Tel sau Nr_Fax

Cheie străină Nr_Personal_Manager, care se referă la Personal (Nr_Personal)

5.2.1.2. se încheie cu documentarea relaţiilor şi atributelor chei străine.

Compoziţia relaţiilor extrase din modelul de date logic se documentează utilizând DBDL. Sintaxa
poate fi extinsă pentru a exprima constrângerile de integritate asupra cheilor străine (vezi 5.2.1.6). Şi
dicţionarul de date trebuie reactualizat cu noile atribute cheie identificate la 5.2.1.2

5.2.1.3 Validarea modelului prin utilizarea normalizării

Normalizarea este o procedură de stabilire a atributelor care aparţin împreună unui tip de
entitate. Prin normalizare datele sunt organizate conform dependenţelor lor funcţionale şi se elimină
riscul anomaliilor de reactualizare. În prima formă normală se elimină grupurile repetitive.

5.2.1.4 Validarea modelului conform tranzacţiilor utilizatorului

Modelul trebuie să accepte tranzacţiile cerute de către vederile utilizatorului. Tranzacţiile se

determină din specificaţiile cerinţelor utilizatorilor. Prin folosirea diagramei ER, a dicţionarului de
date şi a legăturilor cheie primară/cheie străină prezentate în relaţii se încearcă efectuarea manuală
a tranzacţiilor.

5.2.1.5 Desenarea diagramei ER

Se desenează varianta finală a diagramei ER, validată prin normalizare şi conform cu

tranzacţiile pe care trebuie să le accepte.

5.2.1.6 Definirea constrângerilor de integritate

Prin impunerea de constrângeri se protejează baza de date faţă de riscul de incoerenţă.

113
Se consideră 5 tipuri de integritate, anume referitoare la:

a. datele cerute

b. domeniile atributelor

c. integritatea entităţilor

d. integritatea referenţială

e. constrângerile întreprinderii

a. Datele cerute

Unele atribute nu admit Null-uri. În aceste situaţii se selectează proprietatea de câmp

required, care cere date pentru câmpul respectiv. Se verifică dacă aceste constrângeri au fost
identificate şi documentate în dreptul atributelor în dicţionarul de date (vezi 5.1.2)

b. Constrângerile privind domeniile atributelor

Se verifică dacă s-au identificat şi documentat la 5.1.4

c. Integritatea entităţilor

Cheia primară a unei entităţi nu poate conţine Null-uri. Se verifică 5.1.5

d. Integritatea referenţială

Se referă la relaţia entitate părinte – entitate copil. Se ştie că cheia primară din părinte se
copiază în copil unde devine cheie străină.

Integritatea referenţială înseamnă ca o valoare nenulă a cheii străine din entitatea copil trebuie să
se refere la (să coincidă cu) o valoare existentă în entitatea părinte.

Dacă entitatea copil are participare totală în relaţie, nu sunt permise Null-uri în câmpul cheie străină.
Se admit atunci când entitatea copil are participare parţială.

Asigurarea integrităţii referenţiale se realizează prin constrângeri de existenţă. Acestea definesc

condiţiile în care poate fi inserată, reactualizată (modificată) sau ştearsă o cheie candidat sau o cheie
străină.

114
Se ia ca exemplu relaţia Personal Administrează Proprietate, de cardinalitate 1:M.

Entitate părinte (Ep): Personal, cheie primară: Nr_Personal

Entitate copil (Ec): Proprietate, cheie străină: Nr_Personal, copie a cheii primare din Personal.

Cazul 1. Inserarea unei apariţii în relaţia (entitatea) copil

Pentru a asigura integritatea referenţială se verifică dacă atributul Nr_Personal din apariţia nou
inserată în Ec este stabilit ca Null sau are o valoare existentă în Ep.

Cazul 2. Ştergerea unei apariţii din relaţia (entitatea) copil

Se poate efectua fără probleme, nu afectează integritatea referenţială.

Cazul 3. Reactualizarea cheii străine în relaţia (entitatea) copil

Similar cazului 1.

Cazul 4. Inserarea unei apariţii în relaţia (entitatea) părinte

Se poate efectua fără probleme. Ep are participare parţială, deci poate exista un membru al
personalului care nu administrează o proprietate.

Cazul 5. Ştergerea unei apariţii din relaţia (entitatea) părinte.

Dacă apariţie care urmează a fi ştearsă din Ep îi corespunde o apariţie (sau mai multe) din Ec, atunci
integritatea referenţială se pierde prin ştergere.

Posibile strategii de luat în considerare:

NO ACTION Blocarea ştergerii apariţiei din Ep, dacă are corespondent(i) în Ec

CASCADE Dacă o apariţie în Ec se şterge, se şterg automat corespondenţii din Ec.

Dacă Ec acţionează ca Ep în altă relaţie, ştergerea se propagă în cascadă.

115
SET NULL Când se şterge o apariţie din Ep, valorile cheii străine în Ec sunt setate la
Null. Are loc o reactualizare prin setare la Null a valorilor atributelor
selectate din cheia străină a Ec. Această strategie se poate aplica numai
dacă atributele cheie străină acceptă Null-uri.

SET DEFAULT Când se şterge o apariţie din Ep, valorile cheii străine corespunzătoare din
Ec sunt setate la valori prestabilite (default).

Exemplu: se şterge un membru al personalului în Ep (Personal) şi automat

proprietăţile pe care acestea le-a administrat trecute în Ec (Proprietăţi) se
setează la atributul Nr_Pers la valoarea corespunzătoare managerului.

NO CHECK Nu are loc nici o verificare de integritate. Când se şterge o apariţie din Ep
nu este garantată menţinerea integrităţii referenţiale.

Cazul 6. Reactualizarea cheii primare în relaţia (entitatea) părinte

Dacă valorii reactualizate a cheii primare în Ep îi corespundeau una (mai multe) valori ale cheii
străine în Ec, integritatea referenţială este pierdută. Se va aplica una din strategiile de la cazul 5.

e. Constrângerile întreprinderii

Sunt de fapt regulile de afaceri care pot uneori genera reactualizări ele entităţilor. De
exemplu agenţia imobiliară poate stabili ca un membru al personalului să administreze maxim 10
proprietăţi.

5.2.1.6. se încheie cu documentarea tuturor constrângerilor de integritate. Aceasta se face

în dicţionarul de date, pentru a fi luate în considerare la implementarea fizică.

5.2.1.7 Revizuirea modelului de date logic local împreună cu utilizatorii

Se verifică dacă modelul de date logic local este o reprezentare „adevărată” a vederii
utilizatorului. Modelul de date logic local trebuie să fie complet şi in întregime documentat. Modelul
şi documentaţia se revăd împreună cu utilizatorul.

116
5.2.2. Construirea şi validarea modelului de date logic global

În această etapă se construieşte un model de date logic global prin îmbinarea modelelor de date
logice locale individuale, care au fost realizate pentru a reprezenta fiecare vedere a utilizatorilor.

După îmbinare trebuie rezolvate conflictele dintre vederi, ca şi orice suprapuneri existente. Va
rezulta o reprezentare a întregii întreprinderi independentă de orice utilizator sau aplicaţie.

5.2.2.1. Îmbinarea modelelor de date logice locale individuale într-un singur model de date logic
global al întreprinderii

(1) Revizuirea denumirilor entităţilor şi cheilor primare din modelele locale.

Pot exista două sau mai multe entităţi care au aceeaşi denumire dar sunt de fapt diferite,
respective acre au denumiri diferite, dar sunt aceleaşi. Se compară conţinutul de date al
fiecărui tip de entitate. Se utilizează cheile primare pentru a identifica tipurile de entităţi
echivalente, dar cu denumiri diferite.

(2) Revizuirea denumirilor relaţiilor. Se procedează ca la (1).

(3) Îmbinarea entităţilor din vederile locale

Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie primară (fig. 5.9)

Astfel de entităţi reprezintă de regulă acelaşi obiect în lumea reală. La fuziune se includ
atributele entităţilor iniţiale, eliminându-se dublurile.

(Vederea 1)

Personal (Nr_Personal, Nume_Prenume, Funcţie, Sex, Salariu, Nr_Filială)

Cheie primară Nr_Personal

Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

(Vederea 2)

Personal (Nr_Personal, Prenume, Nume, Adresa, Nr_Filială)

Cheie primară Nr_Personal

Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

117
 (Vedere Globală)

Personal (Nr_Personal, Prenume, Nume, Adresa, Funcţie, Sex, Salariu, Nr_Filială)

Cheie primară Nr_Personal

Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

Fig. 5.9. Îmbinarea entităţilor cu aceeaşi denumire şi aceeaşi cheie primară

În versiunea globală obţinută prin îmbinare s-a utilizat versiunea descompusă a atributului
Nume_Prenume (în urma consultării cu utilizatorii).

Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite (fig. 5.10)

Astfel de entităţi nu au aceeaşi cheie primară, dar au chei candidat similare. Rezultă aceeaşi
vedere globală ca în fig. 5.9.

(Vederea 1)

Personal (Nr_Personal, Nume_Prenume, Funcţie, Sex, Salariu, Nr_Filială)

Cheie primară Nume_Prenume

Cheie alternativă Nr_Personal

Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

(Vederea 2)

Personal (Nr_Personal, Prenume, Nume, Adresa, Nr_Filială)

Cheie primară Nr_Personal

118
Cheie alternativă Prenume, Nume

Cheie străină Nr_Filială se referă la Filiala(Nr_Filială)

Fig. 5.10. Îmbinarea entităţilor cu aceeaşi denumire şi chei primare diferite

Îmbinarea entităţilor cu denumiri diferite, cu chei primare similare sau diferite

Astfel de entităţi se pot identifica atunci când: denumirile sunt diferite, dar indică acelaşi
scop, după cheia primară, după participarea în anumite relaţii.

Exemplu: Entităţile Personal şi Angajaţi.

(4) Includerea (fără îmbinare) a entităţilor unice din fiecare vedere locală

Toate entităţile care nu au echivalent se includ nemodificate în modelul global.

(5) Îmbinarea relaţiilor din vederile locale

Se examinează toate relaţiile (denumire, scop, constrângeri structurale) din toate vederile
locale şi se elimină conflictele, prin:

- Îmbinarea relaţiilor cu aceeaşi denumire şi acelaşi scop, apoi

- Îmbinarea relaţiilor cu denumiri diferite dar acelaşi scop

(6) Includerea (fără îmbinare) a relaţiilor unice din fiecare vedere locală

Relaţiile pentru care nu s-au găsit relaţii identice în alte vederi se includ nemodificate în
modelul global.

(7) Căutarea entităţilor şi relaţiilor lipsă

Identificarea entităţilor şi relaţiilor lipsă dintre diversele vederi ale utilizatorilor şi care nu
apar în nici una dintre vederi este o operaţiune dificilă:

Acestea pot rezulta din modelul de date general, dacă există.

119
 Când se consultă utilizatorii asupra unei anumite vederi, ei trebuie rugaţi să examineze şi
entităţile şi relaţiile din alte vederi.

Se examinează atributele fiecărui tip de entitate şi se compară cu atributele entităţilor din

alte vederi. Poate exista un atribut al unei entităţi dintr-o vedere care corespunde unui atribut
cheie primară, cheie alternativă sau unui atribut simplu al unei entităţi din altă vedere. Dintr-o
astfel de corespondenţă rezultă existenţa unei relaţii neidentificate, construibilă prin mecanismul
cheie primară/cheie străină.

(8) Verificarea cheilor străine

Se verifică dacă cheile străine din entităţile copil mai sunt corecte şi se efectuează
modificările necesare.

(9) Verificarea constrângerilor de integritate

Se verifică dacă constrângerile de integritate ale modelului global nu intră în conflict cu

constrângerile de integritate din vederile utilizatorilor. Conflictele se rezolvă prin consultarea cu
utilizatorii.

(10)Desenarea modelului de date logic global

Se desenează diagrama ER a modelului de date logic global, care reprezintă îmbinarea

tuturor modelelor de date logica locale.

(11)Reactualizarea documentaţiei

Documentaţia trebuie reactualizată în urma modificărilor intervenite la realizarea modelului

global. Documentaţia trebuie să reflecte întotdeauna modelul de date curent.

5.2.2.2 Validarea modelului de date logic global

Se realizează prin utilizarea normalizării şi conform tranzacţiilor cerute, dacă este necesar.
Este un pas echivalent cu 5.2.1.3 respectiv 5.2.1.4, anume se fac aceleaşi validări dar acum pentru
modelul de date logic global.

5.2.2.3 Verificarea în vederea dezvoltării locale

Se determină dacă este probabil ca în viitorul previzibil să apară modificări şi se evaluează

capacitatea modelului de date logic global de a cuprinde aceste modificări. Modelul de date logic

120
 global trebuie să poată fi extins cu uşurinţă. Modelul creat trebuie să fie extensibil, să poată
evolua în condiţiile afectării minime a utilizatorului. Se incorporează modificări numai dacă
utilizatorul o cere.

5.2.2.4 Desenarea diagramei ER finale

Diagrama ER finală reprezintă modelul de date logic global al întreprinderii. Se desenează

după ce modelul de date logic global a fost validat. Documentaţia (schema relaţională şi
dicţionarul de date) trebuie reactualizată şi completată.

5.2.2.5 Revizuirea modelului de date logic global împreună cu utilizatorii

Revizuirea va garanta faptul că modelul de date logic global este o reprezentare „adevărată”
a întreprinderii. Modelul împreună cu documentaţia se revizuiesc în colaborare cu utilizatorii,
pentru a confirma că sunt corecte şi complete.

5.2.3. Rezumatul capitolului 5.2.

Proiectarea logică a bazelor de date este procesul de construire a unui model al

informaţiilor utilizate în cadrul unei întreprinderi, bazat pe un anumit model de date, dar
independent de un anumit SGBD şi de alte consideraţii de ordin fizic.

Principalele etape cuprind: construirea şi validarea unui model de date logic local
corespunzător fiecărei vederi a utilizatorilor (5.2.) şi construirea şi validarea unui model de date logic
global (5.2.2).

Rafinarea unui model de date conceptual pentru a obţine un model de date logic include:
eliminarea relaţiilor de tip M:N, a relaţiilor complexe, recursive, cu atribute, a atributelor cu valori
multiple, reexaminarea relaţiilor de tip 1:1 şi eliminarea relaţiilor neredundante.

Modelul de date logic se validează prin normalizare, prin care se garantează că modelul
reprezintă fidel întreprinderea, este coerent, cu redundanţă minimă şi stabilitate maximă.

Constrângerile de integritate se impun pentru a proteja BD faţă de a deveni incoerentă.

Există 5 tipuri de constrângeri de integritate: asupra datelor necesare, ale domeniilor atributelor, de
integritate a entităţilor, de integritate referenţială şi ale întreprinderii.

Integritatea referenţială se asigură prin constrângeri de existenţă, care definesc în ce

condiţii poate fi o cheie candidata sau străină inserată, reactualizată sau ştearsă.

121
Există mai multe strategii care pot fi aplicate atunci când o apariţie a entităţii părinte pe care vrem să
o ştergem are corespondent în entitatea copil: NO ACTION, CASCADE, SET NULL, SET DEFAULT şi NO
CHECK.

Constrângerile întreprinderii se numesc uneori şi reguli de afaceri.

Modelul de date logic este susţinut de către documentaţie, cum ar fi dicţionarul de date sau
schema relaţională, care sunt realizate pe parcursul construirii modelului.

122
1. Introducere în BD. Tratarea datelor. Sisteme de gestionare a bazelor
de date. Sisteme bazate pe fişiere
1.1 Introducere

Sistemele de baze de date sunt o componentă esenţială a vieţii de zi cu zi în societatea modernă. În

cursul unei zile, majoritatea persoanelor desfăşoară activităţi care implică interacţiunea cu o bază de date:
depunerea sau extragerea unor sume de bani din bancă, rezervarea biletelor de tren sau avion, căutarea
unei referinţe într-o bibliotecă computerizată, cumpărarea unor produse etc.

Bazele de date pot avea dimensiuni (număr de înregistrări) extrem de variate, de la câteva zeci de
înregistrări (de exemplu, baza de date pentru o agendă cu numere de telefon) sau pot ajunge la zeci de
milioane de înregistrări (de exemplu, baza de date de plată pentru plata taxelor şi a impozitelor).

Utilizatorii unei baze de date au posibilitatea să efectueze mai multe categorii de operaţii asupra datelor
memorate:

• Introducerea de noi date (insert);

• Ştergerea unora din datele existente (delete);

• Actualizarea datelor memorate (update);

• Interogarea bazei de date (query) pentru a regăsi anumite informaţii, selectate după un criteriu ales.

În sensul cel mai larg, o bază de date (database) este o colecţie de date corelate din punct de vedere
logic, care reflectă un anumit aspect al lumii reale şi este destinată unui anumit grup de utilizatori. În acest
sens, bazele de date pot fi create şi menţinute manual (de exemplu, fişele de evidenţă a cărţilor dintr-o
bibliotecă, aşa cum erau folosite cu ani în urmă) sau computerizat, aşa cum este majoritatea bazelor de date
folosite în momentul de faţă. O definiţie într-un sens mai restrâns a unei baze de date este următoarea:

O bază de date (database) este o colecţie de date creată şi menţinută computerizat, care permite
operaţii de introducere, ştergere, actualizare şi interogare a datelor.

Simple colecţii de fişe (documente pe hârtie) sau fişiere de date, care conţin înregistrări de date, dar nu
permit operaţii de interogare, nu sunt considerate baze de date. De exempu, datele memorate în fişiere pe
disc de un instrument de calcul tabelar (ca Microsoft Excel) sau documentele memorate de un editor de text
(ca Microsoft Word) nu sunt considerate baze de date.

Modelul relaţional de BD

123
 Există trei modele uzuale de implementare de BD: ierarhic, reţea sau relaţional. Fiecare se
bazează pe conceptul de date stocate ca set sau mulţime de înregistrări. Imaginaţi-vă un set de fişe,
de exemplu. Modelele ierarhic şi reţea se bazează pe parcurgerea legăturilor dintre date pentru a
lucra cu baza de date; de regulă sunt utilizate pentru sisteme-cadru generale, vaste şi nu fac obiectul
cursului nostru.
Sistemele de gestionare a bazelor de date relaţionale (SGBDR) au cunoscut o largă
răspândire, datorită modelului simplu, relaţional de date pe care-l utilizează:
 Datele se prezintă sub forma unei colecţii (unui set) de relaţii

 Fiecare relaţie are forma unui tabel (cea mai importantă componentă a unei BD)

 Rândurile (înregistrările) tabelului reprezintă entităţi

 Coloanele (câmpurile) tabelului sunt atribute/proprietăţi ale acestor entităţi

 Fiecare tabel are un set de atribute, care împreună reprezintă o “cheie” care defineşte fiecare
entitate în mod unic.

De exemplu, o societate poate avea în baza sa de date un tabel cu angajaţii săi, cu un

rând/înregistrare pentru fiecare angajat. Ce atribute ar fi de interes? Depinde, desigur, de scopul pentru care
a fost creat tabelul, şi atributele sunt stabilite la momentul configurării bazei de date. Ca exemplu aplicaţia
poate fi un ştat de plată, deci va fi nevoie, în afară de nume, cod angajat şi de informaţii referitoare la adresă
şi salariu.

1.2 Tratarea datelor prin sisteme bazate pe fişiere

Superioritatea administrării datelor dintr-o organizaţie cu ajutorul unui sistem de gestionare de baze
de date (SGBD) rezultă dintr-o scurtă comparaţie între sistemele tradiţionale de date, bazate pe fişiere şi
sistemele de gestionare a bazelor de date (SGBD).

Sistemul bazat pe fişiere este o colecţie de programe de aplicaţie care efectuează servicii
pentru utilizatorii finali, cum ar fi producerea de rapoarte. Fiecare program defineşte şi gestionează
propriile date.

Exemplu: o firmă care furnizează componente pentru diferite proiecte/clienţi.

Compartimentul magazie (al firmei) va ţine fişiere cu:
- componentele în stoc, pe fişa fiecărei componente apărând denumirea, seria, costul, nr. bucăţi
etc.
Compartimentul contabilitate (al firmei) va ţine fişiere cu:
- componentele în stoc, documentele de achiziţie, intrare, denumirea, seria, costul, nr. bucăţi
etc.
- ieşirile de componente, cu caracteristicile şi cantităţile de componente, documentaţie
însoţitoare de ieşire (inclusiv numele proiectelor/clienţilor către care se furnizează)
Compartimentul vânzări (al firmei) va ţine fişiere cu:

124
 - numele proiectelor către care se livrează, inclusiv nume clienţi, număr contract, tipuri de
componente livrate
- cerinţele clienţilor, cu detalierea componentelor necesare, inclusiv descrierea componentelor,
gradul de urgenţă şi prioritate etc.

Rezultă următoarele limitări ale sistemelor bazate pe fişiere:

- Separarea şi izolarea datelor. Atunci când datele sunt izolate în fişiere separate, cele care ar
trebui să fie disponibile sunt mai greu de accesat. De exemplu dacă vrem să aflăm care
componente până la o anumită limită de preţ şi în ce cantitate se află în stoc pentru un anumit
proiect, va trebui sa extragem date din fişierul cu proiecte şi apoi din cel cu stocuri (fişiere
existând la compartimente diferite), va trebui să creăm un fişier temporar care să cuprindă
toate aceste date. Extragerea corectă de date este dificilă, necesitând sincronizarea prelucrării
(în compartimente diferite) a două sau mai multe fişiere.

- Dublarea datelor. Din cauza modului de abordare descentralizat, specific fiecărui

compartiment, tratarea datelor pe bază de fişiere a dus la dublarea necontrolată a datelor.
Observăm în exemplul nostru, că mai multe compartimente au introdus aceleaşi date în
fişierele lor. Dublarea datelor este de nedorit din următoarele cauze:
o Risipă: introducerea datelor de mai multe ori costă timp şi bani, ocupă spaţiu
suplimentar de stocare, deci alte costuri;
o Alterarea integrităţii datelor, prin dublare, deci datele nu mai concordă. De exemplu,
dacă intrarea unor componente cu preţ nou nu este comunicată de către
compartimentul contabilitate celor de la magazie, aceleaşi componente vor apărea în
fişierele diferitelor compartimente cu preţ diferit.

- Dependenţa de date. Dacă este necesară modificarea structurii unui fişier (de ex. mărimea
unui câmp), atunci trebuie identificate toate programele care lucrează cu acest fişier, pentru a
opera modificările respective în fiecare dintre ele. Această caracteristică a sistemelor bazate
pe fişiere se numeşte dependenţă program-date.

- Incompatibilitatea fişierelor. Este posibil ca fiecare compartiment să-şi genereze fişiere în alt
limbaj de programare; structura fişierelor va fi dependentă de limbajul în care este scris
programul. De exemplu, dacă compartimentul vânzări vrea să afle detaliile legate de stocul
existent pentru o anume componentă, va încerca să acceseze fişierul corespunzător al
compartimentului magazie, plecând de la câmpul “denumire componente” existent în fişierele
ambelor compartimente; dacă fişierele sunt generate cu limbaje diferite, va trebui să intervină
un programator care să scrie un program de transformare a fişierelor într-un format comun.

- Interogarea fixă sau proliferarea programelor de aplicaţie. Tratarea datelor prin sisteme de
fişiere a reprezentat un progres semnificativ faţă de sistemele manuale. Au crescut cererile de
interogări noi sau modificate, care necesitau de fiecare dată intervenţia programatorului, care
trebuia să scrie interogările. Astfel au apărut două situaţii. Pentru a limita volumul de lucru al
programatorilor, s-a ajuns la fixarea numărului de interogări disponibile. Pentru a satisface
numărul crescând de cereri de interogări, a proliferat numărul de aplicaţii; au rezultat
programe ineficiente, scrise în grabă, cu documentaţie limitată şi dificil de întreţinut. Accesul
la fişiere este limitat la un singur utilizator o dată, deci nu exista partajarea accesului pentru
mai mulţi utilizatori din acelaşi compartiment.

Limitările tratării datelor bazată pe fişiere au două cauze:

125
 (1) definiţia datelor este încorporată în programele de aplicaţie, în loc de a fi stocată independent;
(2) nu există control asupra accesului şi manipulării datelor dincolo de cel impus de programele
de aplicaţie.

Ca urmare a apărut o nouă tratare a datelor, prin baze de date (BD), gestionate de sisteme de
gestionare a bazelor de date (SGBD).

1.3 Tratarea datelor prin baze de date (BD)

Baza de date este o colecţie partajată de date între care există relaţii logice (şi o descriere a
acestor date), proiectată pentru a satisface necesităţile informaţionale ale unei organizaţii.

Baza de date nu mai este deţinută de un singur compartiment al unei organizaţii, ci este o
resursă comună, partajată. Datele sunt integrate, cu o dublare minimă. BD conţine datele
operaţionale ale organizaţiei şi descrierea acestora.
O bază de date este deci o colecţie autodescrisă de înregistrări integrate. Această
caracteristică BD este cunoscută şi ca independenţa program - date.

O BD relaţională conţine entităţile, atributele şi relaţiile logice dintre acestea, reprezentate

printr-o diagramă entitate – relaţie (ER). Vom reveni în detaliu asupra modelului ER de BD.

1.4 Sistemul de gestionare a bazei de date (SGBD)

SGBD este un sistem de programe care permite utilizatorului definirea, crearea şi întreţinerea
bazei de date şi accesul controlat la aceasta.

SGBD constă în elemente de software care interacţionează cu programele de aplicaţie ale

utilizatorului pe de o parte şi cu baza de date pe cealaltă.

Un SGBD oferă o serie de facilităţi:

- permite definirea BD printr-un limbaj de definire a datelor (DDL)
- permite inserarea, reactualizarea, ştergerea şi extragerea de date printr-un limbaj de
manipulare a datelor (DML). BD fiind un depozit unic şi central de date şi descrieri de date,
DML poate oferi o interogare generală a acestor date, numită limbaj de interogare. Un astfel
de limbaj de interogare este SQL, care elimină utilizarea unui set fix de interogări
disponibile, ca în cazul tratării datelor prin sisteme de fişiere.
- Oferă accesul controlat la BD. Astfel SGBD poate furniza:
o Un sistem de securitate, pentru a împiedica accesul utilizatorilor neautorizaţi
o Un sistem de integritate, care menţine concordanţa datelor stocate;
o Un sistem de control al utilizării simultane, care permite accesul partajat la BD;
o Un sistem de control al refacerii, care restaurează BD într-o stare precedentă
concordantă, ca urmare a unei defecţiuni hard sau soft;
o Un catalog accesibil utilizatorilor, care conţine descrieri ale datelor din BD
- Oferă generarea de vederi/views numite şi moduri de vizualizare a BD prin mecanismul de
vizualizare. Astfel se vor afişa numai acele date din BD care sunt utile utilizatorului,

126
 eliminându-se încărcarea rezultatului unei interogări cu date existente în BD, dar care nu
interesează utilizatorul. Modurile de vizualizare oferă şi alte avantaje:
o Un anumit nivel de securitate; se exclud date care nu trebuie văzute de anumiţi
utilizatori;
o O personalizare a aspectului BD. De exemplu redenumirea câmpurilor după
preferinţele utilizatorului;
o O imagine coerentă, neschimbată a structurii BD, chiar dacă BD însăşi este
modificată; prin modul de vizualizare se va afişa în continuare structura prestabilită a
BD.

1.5 Componentele mediului SGBD

Un sistem de baze de date (Database System) este un sistem computerizat de menţinere a evidenţei
unei anumite activităţi, folosind baze de date. Componentele unui sistem de baze de date sunt: hardware,
software, utilizatori, date persistente.

Hardware. Sistemele de baze de date sunt instalate, de regulă, pe calculatoare de uz general, de la

calculatoare PC standard, până la staţii multiprocesor puternice. Bineînţeles, performanţele generale de
operare ale calculatorului (numărul şi viteza procesoarelor, dimensiunea şi viteza de operare a memoriei
principale etc.) influenţează în mod corespunzător performanţele sistemului de baze de date. Dar, ceea ce
interesează în mod deosebit în utilizarea unui calculator pentru un sistem de baze de date, este volumul
(capacitatea) memoriei secundare, utilizată pentru memorarea colecţiei de date persistente ale bazei de
date.

Dat fiind că într-un sistem de baze de date este necesar accesul rapid la oricare din înregistrările de
date, pentru memorarea acestora se folosesc discurile magnetice (hard-discuri). Benzile magnetice (care
oferă acces secvenţial la înregistrările de date) sunt utilizate numai pentru duplicarea ( back-up) şi
salvarea/restaurarea datelor.

Software. Între baza de date (colecţia de date memorate fizic în fişiere pe hard-discuri) şi utilizatorii
sistemului există un nivel software, numit Sistem de Gestiune a Bazei de Date (SGBD) - ( Database
Management System -DBMS)

Baza de date
Utilizator final Program aplicatie
SGBD Date

Fig. 1.1. Componente ale unui sistem de baze de date.

127
 Sistemul de gestiune a bazei de date - SGBD - (Database Management System - DBMS)
recepţionează cererile utilizatorilor de acces la baza de date (pentru operaţii de introducere, ştergere,
modificare sau interogare), le interpretează, execută operaţiile corespunzătoare şi returnează rezultatul către
utilizatori.

Sistemul SGBD oferă utilizatorilor o viziune (vedere - view) a bazei de date la un nivel înalt
şi îi eliberează de necesitatea de a cunoaşte organizarea particulară a sistemului (driverele de disc,
structura înregistrărilor de date, etc.).

1.6 Arhitectura internă a sistemelor de baza de date

Arhitectura internă a unui sistem de baze de date propusă prin standardul ANSI/X3/SPARC (1975)
conţine trei niveluri funcţionale: nivelul extern, nivelul conceptual şi nivelul intern (fig. 1.2). Nivelul extern
este o colecţie de scheme externe, care sunt vederi ale diferitelor grupuri de utilizatori, existând câte o
vedere individuală a datelor pentru fiecare grup; nivelul conceptual conţine schema conceptuală (logică) a
bazei de date, iar nivelul intern conţine schema internă (fizică) a bazei de date.

O schemă externă (vedere utilizator) (external schema, user’s view) conţine o subschemă
conceptuală a bazei de date, mai precis descrierea datelor care sunt folosite de acel grup de utilizatori.

Schema conceptuală a bazei de date (conceptual schema) corespunde unei reprezentări unice
(pentru toţi utilizatorii) şi abstracte a datelor, descriind ce date sunt stocate în baza de date şi care sunt
asocierile dintre acestea.

Schema internă (fizică) a bazei de date (internal schema) specifică modul de reprezentare a datelor
pe suportul fizic.

Un sistem de baze de date suportă o schemă internă, o schemă conceptuală şi mai multe scheme
externe; toate aceste scheme sunt descrieri diferite ale aceleiaşi colecţii de date, care există doar în nivelul
intern.

128
corespondenţe (mappings): între schemele externe şi schema conceptuală şi între schema conceptuală şi
schema internă.

Unele sisteme SGBD nu separă complet cele trei niveluri funcţionale ale bazelor de date, existând
posibilitatea de a specifica detalii ale schemei interne sau ale schemelor externe în cadrul schemei
conceptuale.

1.7 Avantajele oferite de sistemele de baze de date

Faţă de vechile metode de înregistrare a datelor privind diferite activităţi pe fişe (documente scrise)
sau chiar în fişiere pe disc, sistemele de baze de date oferă avantaje considerabile, ceea ce explică extinsa
utilizare a acestora. Câteva dintre avantajele oferite sunt prezentate în continuare.

• Compactitate ridicată: volumul ocupat de sistemele de baze de date este mult mai redus decât volumul
ocupat de documente scrise sau de fişiere necorelate.

• Viteză mare de regăsire şi actualizare a informaţiilor.

129
• Redundanţă scăzută a datelor memorate, care se obţine prin partajarea datelor între mai mulţi utilizatori
şi aplicaţii. În stocarea pe fişe sau în fişiere a datelor, fiecare aplicaţie conţinea propriile seturi de date. În
sistemele de baze de date, mai multe aplicaţii pot folosi date comune, memorate o singură dată. De
exemplu, o aplicaţie de personal şi o aplicaţie de rezultate la examene dintr-o universitate care exploatează
o singură bază de date, pot folosi aceleaşi informaţii referitoare la structurarea facultăţilor şi a secţiilor.

• Posibilitatea de introducere a standardelor privind modul de stocare a datelor, ceea ce permite

interschimbul informaţiilor între diferite organizaţii.

• Menţinerea integrităţii datelor prin politica de securitate (drepturi de acces diferenţiate în funcţie de rolul
utilizatorilor), prin gestionarea tranzacţiilor şi prin refacerea datelor în caz de funcţionare defectuoasă a
diferitelor componente hardware sau software.

• Independenţa datelor faţă de suportul hardware utilizat. Sistemele de gestiune a bazelor de date oferă o
vedere (view) externă a datelor, care nu se modifică atunci când se schimbă suportul de memorare fizic,
ceea ce asigură imunitatea structurii bazei de date şi a aplicaţiilor la modificări ale sistemului hardware
utilizat.

1.8 Clasificarea sistemelor de baze de date

Se pot lua în consideraţie mai multe criterii de clasificare ale sistemelor de baze de date.

Clasificare după modelul de date. Majoritatea sistemelor de baze de date actuale sunt realizate în
modelul de date relaţional sau în modelul de date obiect. Dezvoltarea continuă a acestor modele a condus
către o nouă categorie de baze de date, numite obiect-relaţionale, care combină caracteristicile modelului
relaţional cu cele ale modelului obiect. De asemenea, mai sunt încă în funcţiune baze de date în modele mai
vechi (modelul ierarhic sau modelul reţea). Modelele de date utilizate de sistemele SGBD vor fi prezentate în
secţiunea următoare.

Clasificare după numărul de utilizatori. Majoritatea sistemelor de baze de date sunt sisteme
multiutilizator, adică permit accesul concurent (în acelaşi timp) a mai multor utilizatori la aceeaşi bază de
date. Un număr redus de sisteme de baze de date sunt de tip monoutilizator, adică suportă accesul doar al
unui singur utilizator (la un moment dat).

Clasificare după numărul de staţii pe care este stocată baza de date. Există două categorii de
sisteme de baze de date: centralizate şi distribuite.

Un sistem de baze de date centralizat (Centralized Database System) este un sistem de baze de date
în care datele şi sistemul de gestiune sunt stocate pe o singură staţie (calculator).

130
 Un sistem centralizat poate suporta unul sau mai mulţi utilizatori, dar, în orice situaţie, datele şi
sistemul de gestiune rezidă în întregime pe o singură staţie.

Un sistem de baze de date distribuit (Distributed Database System) poate avea atât datele, cât şi
sistemul de gestiune, distribuite în mai multe staţii interconectate printr-o reţea de comunicaţie.

Sistemele de baze de date pot fi reprezentate din punct de vedere al funcţionării lor printr-o
arhitectură de tip client-server.

Într-un sistem centralizat (fig. 1.3) există un singur server, care este chiar sistemul SGBD, care
răspunde cererilor unui singur client (în sistemele mono-utilizator, fig. 1.3, a) sau mai multor clienţi (în
sistemele multi-utilizator, fig. 1.3, b), care accesează baza de date respectivă. Clienţii sunt programe de
aplicaţii oferite de furnizorul sistemului de gestiune sau dezvoltate de programatori.

Aplicaţiile client pot fi executate pe staţii diferite, conectate printr-o reţea de comunicaţie cu staţia
pe care rulează serverul. Această arhitectură permite o prelucrare distribuită a datelor şi, mai mult, o
configurare a sistemului adaptată cerinţelor de calcul particulare. Astfel, serverul bazei de date poate fi un
sistem puternic, echipat corespunzător (cu volum mare de memorie secundară), în timp ce fiecare client este
o staţie personală, cu putere de calcul adecvată aplicaţiei executate.

131
 Sistemele de baze de date distribuite pot fi reprezentate într-un mod asemănător din perspectiva
structurării client-server (fig. 1.4).

O bază de date distribuită este o colecţie de date care aparţin din punct de vedere logic aceluiaşi
sistem, dar care pot să fie, din punct de vedere fizic, memorate în mai multe staţii de calcul (locaţii - sites)
conectate printr-o reţea de comunicaţie. Sistemul software care gestionează o astfel de bază de date se
numeşte Sistem de Gestiune a Bazei de Date Distribuite - SGBDD - (Distributed Database Management
System - DDBMS). Aplicaţiile client rulează pe alte staţii din reţea şi solicită servicii de la sistemul de gestiune
distribuit.

132
 Există numeroase avantaje ale sistemelor de baze de date distribuite (creşterea capacităţii de
stocare şi prelucrare a datelor, creşterea disponibilităţii şi a partajării datelor, etc.), dar şi o creştere
considerabilă a complexităţii acestora.

Cea mai importantă cerinţă pe care trebuie să o îndeplinească sistemele de gestiune a bazelor de
date distribuite este de a asigura administrarea transparentă a datelor. Transparenţa se referă la capacitatea
unui sistem distribuit de a ascunde detaliile de implementare, astfel încât utilizatorii să poată accesa datele
pe baza unui model de nivel înalt, fără a fi necesară cunoaşterea exactă a modului de amplasare, replicare
sau comunicare a datelor.

Sistemele de gestiune a bazelor de date distribuite comerciale nu oferă în momentul de faţă un nivel
suficient de transparenţă a localizării datelor, dar dezvoltarea continuă a acestora va putea să asigure în
viitor această cerinţă.

1.9 Modelarea datelor

Un model este o abstractizare a unui sistem, care captează cele mai importante trăsături
caracteristice ale sistemului (concepte), relevante din punct de vedere al scopului pentru care se defineşte
modelul respectiv. Tehnica de identificare a trăsăturilor caracteristice esenţiale ale unui sistem se numeşte
abstractizare.

Un model de date stabileşte regulile de organizare şi interpretare a unei colecţii de date. În

proiectarea bazelor de date se folosesc, de regulă, mai multe modele de date, care se pot clasifica în două
categorii: modele conceptuale de nivel înalt şi modele specializate.

Un model conceptual de nivel înalt al datelor conţine o descriere concisă a colecţiilor de date care
modelează activitatea dorită (numită schemă conceptuală de nivel înalt), fără să detalieze modul de
reprezentare sau de prelucrare a datelor.

Modelele specializate de date (cum sunt: modelul ierarhic, modelul reţea, modelul relaţional, etc.)
impun anumite structuri speciale de reprezentare a mulţimilor de entităţi şi a asocierilor dintre acestea,
structuri pe baza cărora sunt dezvoltate sistemele de gestiune a bazelor de date. Într-un astfel de model de
date, o bază de date este reprezentată printr-o schemă conceptuală (logică) specifică. Trecerea de la
modelul conceptual de nivel înalt la un model de date specific reprezintă etapa de proiectare logică a bazei
de date care asigură corespondenţa dintre schema conceptuală de nivel înalt a bazei de date şi schema
conceptuală specifică modelului de date respectiv.

1.9.1 Modele conceptuale de nivel înalt

133
 Cel mai utilizat model conceptual de nivel înalt este modelul Entitate-Asociere (E-A) care reprezintă
schema conceptuală de nivel înalt a bazei de date prin mulţimi de entităţi şi asocieri dintre acestea.
Dezvoltarea acestui model, astfel încât să permită extinderea tipurilor de entităţi, este cunosută sub numele
de model Entitate-Asociere Extins (E-AE). Proiectarea modelului E-A sau al modelului E-AE este, de regulă,
una din primele etape în proiectarea bazelor de date, etapă numită proiectarea schemei conceptuale.

1.9.1.1 Modelul Entitate-Asociere

Modelul Entitate-Asociere (Entity-Relationship Model), introdus în 1976 de P.S. Chen, este un model
conceptual de nivel înalt al unei baze de date, care defineşte mulţimile de entităţi şi asocierile dintre ele, dar
nu impune nici un mod specific de structurare şi prelucrare (gestiune) a datelor.

Elementele esenţiale ale modelului Entitate-Asociere folosit în proiectarea bazelor de date sunt
entităţile (entities) şi asocierile dintre acestea (relationships).

O entitate (entity) este „orice poate fi identificat în mod distinctiv"; o entitate se referă la un aspect
al realităţii obiective care poate fi deosebit de restul universului şi poate reprezenta un obiect fizic, o
activitate, un concept, etc. Orice entitate este descrisă prin atributele sale.

Un atribut (attribute) este o proprietate care descrie un anumit aspect al unei entităţi.

Atributele prin care este descrisă o entitate se aleg pe baza criteriului relevanţei relativ la domeniul
de interes pentru care se defineşte modelul respectiv, astfel încât să asigure diferenţierea acelei entităţi faţă
de restul universului.

Toate entităţile similare, care pot fi descrise prin aceleaşi atribute, aparţin unui acelaşi tip de entitate
(entity type), iar colecţia tuturor entităţilor de acelaşi tip dintr-o bază de date constituie o mulţime de entităţi
(entities set). În general, în modelul E-A se foloseşte aceeaşi denumire atât pentru un tip de entitate cât şi
pentru mulţimea entităţilor de acel tip.

De exemplu, tipul de entitate „angajat” (al unei instituţii) reprezintă orice persoană angajată a
instituţiei, care are o anumită funcţie şi primeşte un anumit salariu. Acest tip de entitate poate fi descris prin
mai multe atribute, dintre care o parte sunt atribute de identificare a persoanei
(Nume,Prenume,DataNasterii,Adresa), iar altele sunt atribute legate de activitatea acesteia în instituţia
respectivă (Functie,Salariu).

Prin analogie cu modelul obiect, se poate spune că un tip de entitate corespunde unei clase, o
entitate este o instanţă a unui tip de entitate şi corespunde unui obiect, iar mulţimea entităţilor de un tip dat
corespunde mulţimii obiectelor (instanţelor) unei clase.

În proiectarea bazelor de date se consideră două categorii de entităţi: entităţi normale (puternice,
obişnuite - regular entities) şi entităţi slabe (dependente - weak entities).

Entităţile normale au o existenţă proprie în cadrul modelului, în timp ce entităţile slabe nu pot exista
decât dacă există o entitate normală (puternică) cu care sunt asociate. De exemplu, o entitate „dependent”

134
poate să reprezinte o persoană care depinde de un angajat al unei instituţii (adică se află în întreţinerea
acestuia). O entitate „angajat” este o entitate puternică, deoarece ea există în mod normal în modelul
activităţii instituţiei, în timp ce o entitate “dependent” este o entitate slabă: nu se va înregistra o astfel de
persoană decât dacă părintele (susţinătorul) acesteia este angajat în acea instituţie.

În proiectarea bazelor de date se definesc asocieri între mulţimile de entităţi componente, pentru a
reprezenta anumite aspecte ale realităţii pe care baza de date o modelează.

O asociere (relationship) este o corespondenţă între entităţi din două sau mai multe mulţimi de
entităţi.

Gradul unei asocieri este dat de numărul de mulţimi de entităţi asociate. Asocierile pot fi binare (de
gradul 2, între 2 mulţimi de entităţi) sau multiple (între k mulţimi de entităţi, k > 2).

Asocierile binare sunt, la rândul lor, de trei categorii, după numărul elementelor din fiecare dintre
cele două mulţimi puse în corespondenţă de asocierea respectivă (fig. 1.5). Fiind date două mulţimi de
entităţi, E1 şi E2, se definesc următoarele categorii de asocieri binare:

• Asocierea “unul-la-unul” (one-to-one) este asocierea prin care unui element (entitate) din
mulţimea E1 îi corespunde un singur element din mulţimea E2, şi reciproc; se notează cu 1:1.

• Asocierea „unul-la-multe” (one-to-many) este asocierea prin care unui element din
mulţimea E1 îi corespund unul sau mai multe elemente din mulţimea E2, dar unui element din E2 îi
corespunde un singur element în mulţimea E1; se notează cu 1:N.

• Asocierea „multe-la-multe” (many-to-many) este asocierea prin care unui element din
mulţimea E1 îi corespund unul sau mai multe elemente din mulţimea E2 şi reciproc; se notează cu
M:N.

Cardinalitatea (multiplicitatea) unei asocieri faţă de o mulţime de entităţi (cardinality, multiplicity)

este numărul maxim de elemente din acea mulţime care pot fi asociate cu un element din altă mulţime a
asocierii.

135
 Fig. 1.5. Categorii de asocieri între două mulţimi de entităţi: a - asociere 1:1; b - asociere 1:N; c- asociere
M:N.

De exemplu, asocierea 1:N dintre mulţimile E1 şi E2 prezintă multiplicitatea 1 faţă de mulţimea E1 şi

multiplicitatea N (se înţelege o valoare oarecare N > 1) faţă de mulţimea E2. Raportul dintre valorile
cardinalităţilor unei asocieri binare faţă de cele două mulţimi de entităţi se numeşte raport de cardinalitate
(cardinality ratio). Se poate observa că cele trei categorii de asocieri descrise mai sus diferă între ele prin
raportul de cardinalitate.

Asocierile multiple (k-are, k > 2) prezintă câte un raport de cardinalitate pentru fiecare pereche de
mulţimi de entităţi pe care le asociază.

O asociere între două sau mai multe mulţimi de entităţi este, în acelaşi timp, o asociere între tipurile
de entităţi corespunzătoare.

Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezintă modelul Entitate-Asociere prin

mulţimile de entităţi şi asocierile dintre acestea.

Există numeroase variante de notaţii pentru redarea diagramei E-A. Una dintre cele mai folosite
notaţii reprezintă un tip de entitate (precum şi mulţimea de entităţi de acel tip) printr-un dreptunghi, iar
atributele tipului de entitate prin elipse conectate printr-o linie continuă la acesta (fig. 1.6). Pentru entităţile
puternice se utilizează un dreptunghi încadrat cu o linie simplă, iar pentru entităţile slabe se utilizează un
dreptunghi încadrat cu linie dublă.

Fig. 1.6. Notaţiile diagramei Entitate-Asociere (E-A).

O asociere (tip de asociere) dintre două sau mai multe tipuri de entităţi se reprezintă printr-un romb
conectat prin link-uri (linii continue, formate din unul sau mai multe segmente) la tipurile de entităţi

136
asociate. O asociere poate să aibă sau nu un nume; dacă are un nume, acesta poate fi înscris în rombul
respectiv sau în vecinătatea acestuia. Categoria asocierii se notează prin înscrierea multiplicităţii pe fiecare
link care conduce la un tip de entitate. Este posibil ca o asociere să prezinte ea însăşi atribute, şi aceste
atribute se reprezintă prin elipse conectate la asocierea respectivă.

Exemplu. În continuare se exemplifică dezvoltarea modelului conceptual de nivel înalt al unei baze
de date a unei instituţii şi diagrama E-A corespunzatoare, definind câteva tipuri de entităţi şi asocierile între
acestea. Diagrama E-A a acestui mic model de bază de date este prezentată în figura. 1.7.

Fig. 1.7. Exemplu de diagramă E-A.

Tipul de entitate „secţie” reprezintă o unitate de organizare a instituţiei şi este un tip de entitate
puternică (de sine stătătoare). Acest tip se caracterizează prin mai multe atribute, de exemplu, un număr al
secţiei, numele secţiei şi bugetul alocat. Mulţimea de entităţi care grupează toate entităţile de acest tip se
poate denumi SECTIE sau SECTII (oricare variantă poate fi folosită) şi este caracterizată prin aceleaşi atribute
care caracterizează tipul entităţii:

SECTIE(Numar,Nume,Buget)

137
 Tipul de entitate „angajat” reprezintă o persoană angajată în instituţie şi este de asemenea un tip de
entitate puternică. Acest tip de entitate, ca şi mulţimea de entităţi care grupează toate entităţile de acest tip,
se poate defini astfel

ANGAJAT(Nume,Prenume,DataNasterii,Adresa,Functie,Salariu)

Tipul de entitate „proiect” reprezintă o activitate a instituţiei, şi este de asemenea un tip de entitate
puternică, care poate fi caracterizat prin numele proiectului, data începerii, termen de realizare, bugetul
proiectului:

PROIECT(Nume,DataInceperii,Termen,Buget)

Tipul de entitate „dependent” reprezintă o persoană care depinde de un angajat al instituţiei (adică
se află în întreţinerea acestuia). Acest tip de entitate este un tip de entitate slabă: nu se va înregistra o astfel
de persoană decât dacă întreţinătorul acesteia este angajat în acea instituţie. Acest tip se poate defini astfel:

DEPENDENT(Nume,Prenume,DataNasterii,GradRudenie)

Asocierea SECTIE-ANGAJAT este o asociere 1:N, dacă se consideră că o secţie cuprinde mai mulţi
angajaţi, iar un angajat aparţine unei singure secţii.

Asocierea ANGAJAT-PROIECT este o asociere M:N, dacă se consideră că la fiecare proiect lucrează
mai mulţi angajaţi, şi fiecare angajat poate lucra la mai multe proiecte.

Asocierea ANGAJAT-DEPENDENT este o asociere de tipul 1:N, deoarece un angajat poate întreţine
mai multe persoane (fii, părinţi etc.), iar o persoană dependentă este în întreţinerea unui singur susţinător.

Raportul de cardinalitate al unei asocieri este stabilit de proiectant astfel încât să reflecte cât mai
corect modul de organizare a activităţii modelate. De exemplu, asocierea ANGAJATI-PROIECTE are raportul
de cardinalitate M:N dacă în instituţia respectivă se admite ca un angajat să lucreze la mai multe proiecte;
dacă s-ar impune ca un angajat să lucreze la un singur proiect, atunci asocierea respectivă ar avea raportul
de cardinalitate N:1. În ambele situaţii se admite că la un proiect lucrează mai mulţi angajaţi.

Sunt de remarcat câteva caracteristici generale ale modelului E-A:

a) Modul de stabilire a tipurilor de entităţi şi a asocierilor dintre acestea nu este unic, deoarece
graniţa dintre entităţi şi asocieri nu este, în general, una bine precizată. Aceeaşi funcţionalitate se poate
obţine printr-o varietate de diagrame E-A, depinzând de felul în care proiectantul dezvoltă modelul
conceptual. O asociere poate fi considerată şi ca un tip de entitate. De exemplu, pentru baza de date a unei
facultăţi (şcoli) se definesc tipurile (mulţimile) de entităţi:

STUDENTI(Nume,Prenume,Adresa,...)

DISCIPLINE(Denumire,Credite,...)

Între aceste mulţimi de entităţi se poate defini asocierea STUDENTI-DISCIPLINE, cu raportul de

cardinalitate M:N. Această asociere reprezintă (în general) studierea unor discipline de către studenţi, cu
atribute ca: Nota (examenului la disciplina respectivă), DataExamen, etc. Dar, la fel de bine, este posibil să se
definească tipul de entitate NOTE, aflat în asociere N:1 cu fiecare din tipurile de entităţi STUDENTI şi
DISCIPLINE (fig. 1.8).

138
 Fig. 1.8. Diferite moduri de definire a tipurilor de entităţi şi a asocierilor:

a- asociere M:N între mulţimile de entităţi STUDENTI şi DISCIPLINE;

b - mulţimea de entităţi EXAMENE este asociată cu raportul de cardinalitate N:1

cu fiecare din mulţimile de entităţi STUDENTI şi DISCIPLINE.

b) În modelul E-A, tipul de entitate (şi mulţimea de entităţi corespunzătoare) semnifică un

substantiv, în timp ce o asociere semnifică un verb. Bineînţeles, nu este obligatoriu ca numele dat unei
asocieri să fie un verb (şi, de cele mai multe ori, nici nu este), dar o asociere reprezintă o interacţiune între
tipurile de entităţi (şi mulţimile de entităţi corespunzătoare), care poate fi exprimată printr-un verb. De
exemplu, în diagrama E-A din figura 1.7, asocierea SECTIE-ANGAJAT poate fi exprimată prin verbul cuprinde,
asocierea ANGAJATI-DEPENDENTI poate fi exprimată prin verbul întreţine, asocierea ANGAJATI-PROIECTE
poate fi exprimată prin verbul lucrează etc.

c) Modelul E-A nu precizează modul cum sunt realizate asocierile între mulţimile de entităţi. Acest
aspect depinde de modelul de date specializat utilizat pentru definirea bazei de date. De exemplu, în
modelele ierarhic şi reţea, asocierile sunt realizate explicit, prin pointeri de la o entitate la entităţile asociate,
în timp ce în modelul relaţional asocierea se realizează prin egalitatea valorilor unor atribute comune ale
entităţilor (chei).

1.9.1.2 Modelul Entitate-Asociere Extins

Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model) permite definirea de subtipuri

ale unui tip de entităţi, care moştenesc atribute de la tipul de entitate pe care il extind (şi care, în acest
context, se numeşte supertip) şi au în plus atribute specifice semnificaţiei lor. Prin definirea tipurilor şi a
subtipurilor de entităţi se pot crea ierarhii de tipuri de entităţi pe mai multe niveluri.

Modelul E-A prezentat în capitolul precedent este suficient pentru modelarea aplicaţiilor de baze de
date „tradiţionale”, adică bazele de date utilizate pentru activităţi financiare şi industriale, în care se folosesc
tipuri de date simple. Odată cu dezvoltarea sistemelor de baze de date, domeniile în care acestea se folosesc
au devenit tot mai numeroase, ca, de exemplu: telecomunicaţiile, proiectarea tehnologică, sistemele de
informaţii geografice, seviciul Web, etc. Tipurile de entităţi definite în astfel de baze de date sunt mult mai
complexe şi pentru reprezentarea lor cât mai intuitivă şi mai compactă au fost propuse mai multe concepte
noi, care au fost introduse în modelul E-A extins.

139
Modelul E-A extins se reprezintă printr-o diagramă E-A extinsă. Ierarhiile de tipuri se pot crea prin
specializare sau generalizare.

Specializarea (specialization) este un proces de abstractizare a datelor prin care, pornind de la un tip
de entitate dat, se definesc unul sau mai multe subtipuri, diferenţiate între ele în funcţie de rolul specific pe
care îl au în modelul de date.

De exemplu, pornind de la tipul de entitate ANGAJAT se definesc prin specializare subtipurile

SECRETARA, TEHNICIAN, INGINER, pentru a diferenţia funcţiile pe care angajaţii le pot avea în întreprinderea
respectivă (fig. 1.9). Litera “d” din marcajul de specializare a tipurilor indică o constrângere de disjuncţie
impusă specializării, care va fi descrisă mai jos.

Subtipurile de entităţi moştenesc atribute ale tipului iniţial şi fiecare dintre ele are atribute suplimentare,
specifice rolului lor. De exemplu, atributele (Nume, Prenume, DataNasterii, Adresa, Salariu) ale tipului de
entitate ANGAJAT sunt moştenite de fiecare din subtipurile acestuia. Atributul Functie nu este moştenit,
deoarece specializarea subtipurilor s-a efectuat după acest atribut. Ca atribute specifice, subtipul SECRETARA
are atributul VitezaRedactare, care este o măsură a calificării, subtipul TEHNICIAN are atributul Calificare,
care reprezintă gradul de calificare, iar subtipul INGINER are atributul Specialitate, care este o precizare a
domeniului in care lucrează (mecanic, electric, etc.).

Generalizarea (generalization) este procesul de abstractizare invers specializării, prin care se crează
un supertip de entitate pornind de la mai multe tipuri de entităţi.

Pentru definirea unei generalizări, se identifică atributele comune ale mai multor tipuri de entităţi şi
aceste atribute vor caracteriza supertipul de entitate, iar atributele care diferă de acestea rămân specifice
fiecărui tip.

De exemplu, dacă au fost definite tipurile de entităţi: AUTOMOBIL (NrInregistrare, Marca,

VitezaMaxima, Pret, NumarPasageri) şi CAMION(NrInregistrare, Marca, VitezaMaxima, Pret, Tonaj), se poate
defini un supertip al acestor tipuri: VEHICUL (NrInregistrare, Marca, VitezaMaxima, Pret). Acest tip va
cuprinde toate atributele comune, iar tipurile iniţiale, AUTOMOBIL şi CAMION, devin subtipuri ale tipului
VEHICUL, fiecare conţinând atributele specifice (NumarPasageri pentru tipul AUTOMOBIL şi Tonaj pentru
tipul CAMION).

Rezultatul obţinut prin generalizare este, ca şi în cazul specializării, o ierarhie de tipuri de entităţi;
ceea ce diferă este modul în care se definesc nivelurile ierarhiei.

140
 Fig.1.9. Diagrama E-A extinsă cu ierarhie de tipuri de entităţi.

Moştenirea atributelor. Proprietatea principală a ierarhiilor de tipuri de entităţi create prin

specializare sau generalizare este moştenirea atributelor: atributele tipurilor de entităţi de nivel ridicat
(supertipuri) sunt moştenite de tipurile de entităţi de nivel scăzut (subtipuri).

Moştenirea dintre un subtip de entităţi şi supertipul acestuia se reprezintă în diagrama E-A extinsă
printr-o legătură (link) între subtip şi supertipul de entitate corespunzător pe care este plasat un semicerc
orientat către subtip (aşa cum se poate vedea în figura 1.9).

Este evidentă asemănarea dintre ierarhiile de tipuri de entităţi din modelul E-A extins şi ierarhiile de
clase din modelul obiect-orientat, dar modelul E-A extins este un model de date mult mai general (de nivel
inalt), care poate fi transpus în diferite modele de date specializate, inclusiv modelul obiect-orientat. Aceste
transpuneri se fac în funcţie de suportul oferit de modelul specializat respectiv pentru reprezentarea
entităţilor, asocierilor, moştenirilor, etc.

1.9.2 Modele specializate de date

1.9.2.1 Modelul de date ierarhic

În modelul ierarhic (Hierarchical Model) o bază de date se reprezintă printr-o structură ierarhică de
înregistrări de date (records) conectate prin legături (links).

141
 Modelul de date ierarhic a fost primul model folosit pentru dezvoltarea bazelor de date. Cea mai
cunoscută realizare de SGBD ierarhic este sistemul IMS (Information Management System) dezvoltat de
firma IBM în cadrul programului de cercetări Apollo, în perioada anilor 1960.

O înregistrare de date în modelul ierarhic este o instanţă a unui tip de înregistrare (record type) şi
constă dintr-o colecţie de câmpuri (fields), fiecare câmp conţinând valoarea unui atribut. Un tip de
înregistrare corespunde unui tip de entitate, iar o înregistrare corespunde unei entităţi din modelul E-A.

Un tip de legătură în modelul ierarhic este un tip de asociere cu raportul de cardinalitate 1:N (de tip
părinte-fiu) între două tipuri de înregistrări. Tipul de înregistrare din partea cu multiplicitatea 1 a asocierii
este numit tip de înregistrare părinte, iar tipul din partea cu multiplicitatea N a asocierii este numit tip de
înregistrare fiu.

Schema conceptuală a unei baze de date în modelul ierarhic se reprezintă printr-un număr oarecare
de scheme ierarhice (fig. 1.12). O schemă ierarhică este un arbore direcţionat, reprezentat pe mai multe
niveluri, în care nodurile sunt tipurile de înregistrări, iar arcele sunt tipurile de legături. Fiecare nod (cu
excepţia nodului rădăcină) are o singură legătură către un nod de pe un nivel superior (nodul părinte) şi
fiecare nod (cu excepţia nodurilor frunză) are una sau mai multe legături către noduri de pe nivelul imediat
inferior (noduri fii).

Se poate stabili o corespondenţă între o schemă conceptuală ierarhică şi o diagramă E-A: tipurile de
înregistrări corespund tipurilor de entităţi, iar tipurile de legături corespund tipurilor de asocieri. (fig. 1.12, a
şi b).

În modelul ierarhic nu sunt admise decât legături de tipul părinte-fiu, care corespund asocierilor 1:1
şi asocierilor 1:N din modelul E-A. Asocierile M:N din modelul E-A nu se pot reprezenta în mod direct în
modelul ierarhic, ci numai prin multiplicarea înregistrărilor de tip fiu, atunci când sunt referite de mai multe
înregistrări de tip părinte. Acest lucru conduce la o mare redundanţă a datelor.

Corespunzător schemei ierarhice a unei baze de date se pot reprezenta mai mulţi arbori de
instanţiere a datelor, care sunt, de asemenea, arbori direcţionaţi (fig. 1.12, c). Fiecare arbore de instanţiere
contine ierarhii pe mai multe niveluri de înregistrări între care există legături de tipul părinte-fiu.

142
 Fig. 1.12. Bază de date ierarhică: a - diagrama E-A;

b - schema conceptuală a bazei de date ierarhice; c - arbori de instanţiere a datelor.

Corespunzător schemei ierarhice a unei baze de date se pot reprezenta mai mulţi arbori de
instanţiere a datelor, care sunt, de asemenea, arbori direcţionaţi (fig. 1.12, c). Fiecare arbore de instanţiere
contine ierarhii pe mai multe niveluri de înregistrări între care există legături de tipul părinte-fiu.

Avantajele modelul ierarhic sunt simplitatea şi eficienţa de calcul, dar în momentul de faţă, pentru
realizarea bazelor de date sunt preferate modele de date mai puternice (modelul relaţional, modelul obiect-
orientat).

1.9.2.2 Modelul de date reţea

Modelul reţea (Network Model) foloseşte o structură de graf pentru definirea schemei conceptuale a
bazei de date; nodurile grafului sunt tipuri de entităţi (înregistrări - records), iar muchiile grafului reprezintă
în mod explicit asocierile (legăturile-links) dintre tipurile de entităţi.

Apărut după modelul ierarhic, modelul reţea de reprezentare a bazelor de date a fost standardizat în
1971, de o comisie DBTG (Database Task Group). Modelul reţea a avut mai multe implementări ca sisteme
de gestiune comerciale: IDS II (Honeywell), UNISYS (Burroughs), IDMS (Computer Associates).

Deosebirea faţă de modelul ierarhic constă în aceea că în modelul reţea asocierile M:N se reprezintă
fără duplicarea înregistrărilor, fiecare înregistrare putând fi referită de mai multe înregistrări, ceea ce elimină
redundanţa.

La fel ca şi la modelul ierarhic, dezavantajul principal al modelului reţea este acela că fiecare
interogare trebuie să fie prevăzută încă din faza de proiectare, prin memorarea explicită a legăturilor între
tipurile de entităţi. În plus, complexitatea reprezentării datelor în modelul reţea este deosebit de ridicată, iar
programatorii trebuie să o cunoască pentru a putea realiza aplicaţiile necesare.

În momentul de faţă modelul de date reţea este foarte rar utilizat pentru baze de date de uz general
(care implică operaţii de interogare), dar există unele domenii în care structurarea ca graf a datelor permite
o parcurgere eficientă a acestora. De exemplu, majoritatea bazelor de date grafice folosite în modelarea
scenelor tridimensionale din realitatea virtuală sunt baze de date reţea [Ion96a].

1.9.2.3 Modelul de date relaţional

143
 Modelul relaţional (Relational Model) se bazează pe noţiunea de relaţie (relation) din matematică,
care corespunde unei mulţimi de entităţi de acelaşi tip.

Modelul de date relaţional a fost propus de cercetătorul E.F. Codd de la compania IBM, care a
publicat în anul 1970 lucrarea "Un model Relaţional de Date pentru Bănci Mari de Date Partajate" [Codd70].
Alte lucrări ale lui Codd, ca şi ale altor cercetători (C.J. Date, P. Chen, R. Boyce, J.D. Ullman, R. Fagin, W.W.
Armstrong, M. Stonebraker, etc.) au perfecţionat modelul de date relaţional şi au permis dezvoltarea fără
precedent a sistemelor de gestiune a bazelor de date, datorită simplităţii şi a fundamentării matematice a
modelului.

Primul Sistem de Gestiune a Bazelor de Date Relaţionale (SGBDR) a fost prototipul System R,
dezvoltat la compania IBM în anii 1970, după care numeroase companii au realizat sisteme de gestiune
relaţionale (Oracle, Microsoft, Ingres, Sybase, etc.) iar aplicaţiile de baze de date relaţionale au căpătat o
amploare deosebită.

Pe lângă avantajul unui model de date precis şi simplu, sistemele de baze de date relaţionale mai
beneficiază şi de un limbaj de programare unanim recunoscut şi acceptat, limbajul SQL (Structured Query
Language), pentru care au fost emise mai multe standarde de către ISO (International Standardization
Office). Majoritatea SGBD-urilor relaţionale actuale implementează versiunea SQL92 (sau SQL2).

1.9.2.4 Modelul de date obiect-orientat

Modelul obiect (Object Model) este un concept unificator în ştiinţa calculatoarelor, fiind
aplicabil în programare, în proiectarea hardware-ului, a interfeţelor, a bazelor de date, etc.
Sistemele de baze de date obiect- orientate se bazează pe limbaje de programare obiect-orientate cu
capacităţi de persistenţă, în care datele sunt independente de timpul de viaţă al programelor care le
creează, prin memorare pe suport magnetic (disc).
Oricât de folositor este modelul de date relaţional pentru realizarea bazelor de date, există
unele domenii (în special acele domenii în care se manevrează tipuri de date complexe), în care
modelul relaţional s-a dovedit a fi insuficient de expresiv şi cu performanţe de execuţie reduse.
Domenii ca: proiectarea asistată de calculator, sisteme de informaţii geografice, medicină (şi altele)
au impulsionat cercetări pentru găsirea unor modele mai performante, dintre care modelul obiect-
orientat şi modelul obiect-relaţional au cunoscut şi cunosc în continuare o dezvoltare semnificativă.
Caracteristicile importante ale modelului obiect (abstractizarea, moştenirea, încapsularea,
modularitatea) sunt intens dezbătute şi analizate mai ales din perspectiva proiectării şi programării
obiect-orientate.
Din perspectiva realizării bazelor de date, o altă proprietate a modelul obiect, persistenţa, este
aceea care asigură memorarea transparentă pe suport magnetic a obiectelor care alcătuiesc o bază de
date obiect-orientată.
Pentru dezvoltarea unui sistem de gestiune a bazelor de date obiect- orientate (SGBDOO) se
poate aborda una din următoarele strategii:

• Extinderea unui limbaj de programare obiect-orientat cu capacităţi de administrare a

obiectelor persistente. Sistemul GemStone este un astfel de SGBDOO, dezvoltat prin
extinderea limbajelor C++ şi Java.

144
 • Extinderea unui limbaj de programare relaţional cu capacităţi de orientare spre obiecte. Un
astfel de limbaj este limbajul ODL (Object Query Language) (sau Object SQL), specificat
prin standardul propus de consorţiul Object Database Management Group, din care fac
parte principalii producători de sisteme de baze de date obiect-orientate. Există mai multe
astfel de sisteme, cum sunt: Ontos, Versant, O2.

• Dezvoltarea unui limbaj obiect-orientat pentru baze de date complet nou, care să asigure
crearea şi interogarea obiectelor persistente. Există şi astfel de produse, ca de exemplu
sistemul SIM (Semantic Information Manager).

Dintre avantajele cele mai importante ale sistemelor de baze de date dezvoltate în modelul
obiect se evidenţiază capacitatea acestora de a defini şi manevra tipuri de date complexe (clase), care
se pot extinde prin mecanismul de moştenire, ceea ce contribuie la creşterea performanţelor în
aplicaţiile de baze de date avansate.
Există, bineînţeles, şi dezavantaje ale sistemelor de baze de date obiect-orientate, care le fac
să aibă o utilizare limitată, mult mai redusă decât cea a sistemelor de baze de date relaţionale (sub
5% din piaţa sistemelor de baze de date). Principalul dezavantaj îl constitue complexitatea de
dezvoltare a bazei de date şi a aplicaţiilor, datorită faptului că proiectanţii şi programatorii trebuie să
prevadă în structura obiectelor toate asocierile (legăturile) necesare tuturor interogărilor. Cu cât
interogările sunt mai complexe, cu atât sunt necesare mai multe asocieri între obiecte şi deci se
complică structura acestora. La acest dezavantaj se adaugă şi altele, cum ar fi lipsa unui standard de
limbaj de interogare care să fie unanim (sau cât mai larg) acceptat.

1.9.2.5 Modelul de date obiect-relaţional

Modelul obiect-relaţional (Object-Relational Model) reprezintă extinderea modelului

relaţional cu caracteristici ale modelului obiect, extindere necesară pentru realizarea bazelor de
date care definesc şi prelucrează tipuri de date complexe.
În esenţă, modelul obiect-relaţional păstrează structurarea datelor în relaţii (reprezentate ca
tabele), dar adaugă posibilitatea definirii unor noi tipuri de date, pentru domeniile de valori ale
atributelor. Tipurile de date definite de utilizator pot fi extinse prin mecanismul de moştenire şi
pentru fiecare tip sau subtip se pot defini metode pe care le pot executa obiectele de acel tip.
În general, dezvoltarea sistemelor de gestiune a bazelor de date obiect-relaţionale (SGBDOR) se
realizează prin extinderea sistemelor relaţionale, de cele mai multe ori în mod gradat, adăugându-se
de la o versiune la alta cât mai multe caracteristici posibile ale modelului obiect şi păstrând în
continuare toate caracteristicile modelului relaţional.
O astfel de abordare asigură rularea în continuare a aplicaţiilor relaţionale existente în noile
versiuni de sisteme SGBDOR, ceea ce permite producătorilor să-şi păstreze clienţii şi domeniile de
utilizare. Mai mulţi dintre principalii producători de sisteme de gestiune (Oracle, Informix şi IBM)
au extins în acest mod sistemele lor relaţionale pentru a deveni sisteme obiect-relaţionale. Este o
tendinţă firească, dat fiind că prin aceasta se păstrează toată experienţa şi rezultatele obţinute cu
sistemele relaţionale şi se pot dezvolta şi aplicaţii complexe, obiect-relaţionale.
Standardele limbajelor de programare pentru sistemele de gestiune obiect-relaţionale sunt extensii
ale standardului SQL (ca de exemplu, versiunea din anul 1999, denumită SQL3).

1.10 Avantajele şi dezavantajele SGBD

Avantaje

145
- Controlul redundanţei datelor; nu se elimină în întregime redundanţa, ci se controlează volumul
inerent al acesteia în BD.

- Coerenţa datelor; datorită eliminării redundanţei, orice reactualizare a unui articol (stocat o singură
dată) se face o singură dată, eliminându-se incoerenţa. Dacă articolul este stocat de mai multe ori,
SGBD garantează coerenţa tuturor exemplarelor din articolul respectiv.

- Mai multe informaţii obţinute de la aceeaşi cantitate de date; ca urmare a integrării datelor
operaţionale, două sau mai multe fişiere pot fi integrate, extrăgându-se mai multe informaţii.

- Partajarea datelor; fişierele sunt deţinute de compartimentele organizaţiei care le utilizează, dar
fiind parte din BD, ele sunt la dispoziţia tuturor utilizatorilor interesaţi.

- Integritatea crescută a datelor; se referă la validitatea şi coerenţa datelor stocate. Integritatea este
exprimată prin constrângeri, care reprezintă reguli de coerenţă pe care BD nu are voie să le încalce.

- Securitatea crescută; se referă la protecţia BD faţă de utilizatorii neautorizaţi. Fără sisteme de

securitate, integrarea ar face datele foarte vulnerabile. Securitatea se realizează prin nume de
utilizatori plus parole. Se poate limita tipul de operaţie efectuată.

- Aplicarea standardelor; prin integrare se pot aplica standarde organizaţionale, naţionale sau
internaţionale, ca de ex. formatul datelor, convenţii referitoare la denumire, pt. a facilita schimburi
între sisteme.

- Economia de scală; în loc de bugete pentru fiecare compartiment pentru crearea unui sistem propriu
de BD bazat pe fişiere, există un buget unic combinat, care permite alocarea fondurilor economisite
pentru îmbunătăţirea sistemului.

- Echilibrul între cerinţele aflate în conflict; cerinţele posibil în conflict ale diferitelor compartimente
referitoare la utilizarea BD sunt gestionate la nivel de DBA, care va lua deciziile ce se impun şi va
acorda prioritate aplicaţiilor majore.

- Îmbunătăţirea accesibilităţii datelor şi capacităţii de răspuns; limbajele de interogare şi generatoare

de rapoarte asociate SGBD oferă utilizatorilor posibilitatea unor interogări ad-hoc, fără a apela la
programator.

- Productivitatea crescută; SGBD furnizează standardele necesare aplicaţiei, economisind timpul

programatorului.

- Capacitatea de întreţinere îmbunătăţită, prin independenţa de date; într-un SGBD descrierile datelor
sunt separate de aplicaţii, aplicaţiile fiind imune la modificarea descrierii datelor; este caracteristica
de independenţă program-date, care uşurează întreţinerea aplicaţiilor din BD.

- Concurenţa/simultaneitatea îmbunătăţită; se garantează alterarea datelor în situaţia când acelaşi

fişier este utilizat simultan de mai mulţi utilizatori.

- Îmbunătăţirea serviciilor de salvare de siguranţă şi refacere. Se minimizează pierderile apărute ca

urmare a unor defecţiuni. Nu este necesară realizarea zilnică de copii de siguranţă.

146
Dezavantaje

- Complexitatea; pt. ca un SGBD să fie funcţional, acesta va evolua într-un sistem soft extrem de
complex. Funcţionalitatea trebuie cunoscută de către toţi cei implicaţi în BD, de la DA la utilizatorul
final, pentru a o putea exploata. Dacă SGBD este greşit înţeles, BD proiectată poate fi greşită, cu
toate consecinţele acestei situaţii.

- Dimensiunea; Fiind un element soft foarte complicat, SGBD ocupă mult spaţiu pe disc şi necesită
multă memorie pentru a funcţiona eficient.

- Costul SGBD; variază în funcţie de mediu şi funcţionalitate. De la 150 USD pt. un PC cu un utilizator,
la 750.000 USD pt. un sistem mainframe cu sute de utilizatori. Se adaugă cheltuieli periodice anuale
de întreţinere.

- Costurile adiţionale pentru elemente hardware; pentru a sigura performanţele SGBD poate fi nevoie
de achiziţionarea unui calculator mai mare, chiar dedicat rulării SGBD, cu disc şi memorie mai mari.

- Costul conversiei; la implementarea unui nou sistem SGBD şi/sau a unei noi configuraţii hard,
conversia poate costa semnificativ mai mult decât noile elemente hard. Se include costul instruirii
personalului, angajarea de personal specializat. Apare termenul de sistem moştenit, adică un sistem
mai vechi, inferior, de care organizaţia se cramponează din motive de costuri de conversie.

- Performanţa; SGBD (spre deosebire de cel bazat pe fişiere) este general, creat pentru a permite
diverse aplicaţii; astfel unele pot funcţiona mai puţin rapid decât în cazul sistemului bazat pe fişiere,
creat pentru o anume aplicaţie.

- Impactul crescut al unei defecţiuni. Centralizarea (partajarea) resurselor creşte vulnerabilitatea

SGBD. Eşecul oricărei componente poate duce la sistarea tuturor operaţiilor.

1.11 Complexitatea datelor şi a interogărilor

M. Stonebraker a oferit o reprezentare în patru cadrane a universului bazelor de date (fig.

1.13) deosebit de simplă şi de interesantă, bazată numai pe complexitatea datelor şi a interogărilor.
Propusă în anul 1996, această clasificare nu include modelele prerelaţionale (modelul ierarhic şi
modelul reţea), considerate depăşite în această fază de dezvoltare a bazelor de date.
Pe abscisa diagramei este reprezentată capacitatea de definire a tipurilor de date complexe, iar pe
ordonată este reprezentată capacitatea de interogare a bazelor de date.

În cadranul din stânga jos sunt acele aplicaţii care prelucrează tipuri de date simple şi nu necesită
interogarea datelor. Astfel de tipuri de aplicaţii (cum sunt procesoarele de texte – Word, Framemaker)
folosesc direct sistemul de fişiere al sistemului de operare pentru memorarea datelor persistente.

147
 Fig. 1.13. Clasificarea sistemelor de gestiune a bazelor de date.

În cadranul din stânga sus sunt sistemele de gestiune a bazelor de date relaţionale (SGBDR),
care prelucrează tipuri simple de date, dar permit interogări complexe.
În cadranul din dreapta jos sunt sistemele de gestiune a bazelor de date obiect-orientate
(SGBDOO), care prelucrează tipuri de date complexe, dar în care rezolvarea interogărilor este destul
de dificilă, dat fiind că pentru fiecare interogare trebuie să fie prevăzute legăturile necesare în
structura obiectelor.
În cadranul din dreapta sus sunt reprezentate sistemele obiect-relaţionale (SGBDOR), care
permit prelucrarea datelor complexe şi rezolvarea interogărilor complexe. Modelul obiect-relaţional
este, evident, cel mai complet, deoarece admite atât tipuri de date definite de utilizator cât şi
interogări complexe. În aceeaşi lucrare, Stonebraker denumeşte sistemele de gestiune a bazelor de
date obiect-relaţionale ca fiind sisteme de baze de date universale.
În momentul de faţă este evidentă tendinţa producătorilor de sisteme de gestiune a bazelor de
date de a trece la sisteme obiect-relaţionale şi, în general, această trecere se realizează prin adăugarea
treptată a caracteristicilor modelului obiect în sistemele de gestiune relaţionale. Oferta de sisteme de
gestiune a bazelor de date este deosebit de generoasă, pe o scară extinsă de performanţe şi costuri, de
la sisteme care se pot folosi gratuit (fără licenţă sau cu licenţă publică), până la sisteme cu înalte
performanţe, a căror utilizare necesită plata licenţelor respective. Chiar şi pentru astfel de sisteme
există versiuni de test (trial versions) care pot fi obţinute gratuit prin Internet (de la adrese care sunt
indicate în Bibliografie), astfel încât pot fi folosite pentru a înţelege şi a executa exemplele propuse
în această lucrare.
Sistemul Oracle este un sistem de gestiune a bazelor de date multi-utilizator puternic, cu
implementări pe toate platformele (Windows, Unix, Linux), care oferă atât performanţe de execuţie
ridicate, cât şi un grad înalt de protecţie şi securitate a datelor. În toate versiunile, Oracle oferă
implementarea completă a caracteristicilor modelului relaţional (conform standardului SQL2), iar
ultimele versiuni (Oracle8i, Oracle9i şi Oracle 10g) sunt sisteme de gestiune obiect-relaţionale
distribuite, implementând extensiile obiect-orientate prevăzute în standardul SQL3 şi oferind
posibilitatea de dezvoltare a bazelor de date distribuite. Sistemele de gestiune Oracle, ca şi diferite
instrumente de dezvoltare a aplicaţiilor de baze de date (Oracle Application Server, JDeveloper,
Oracle Forms etc.), se pot obţine de la adresa http://www.oracle.com şi termenii licenţei permit
utilizarea acestor sisteme în scopuri necomerciale pe o perioadă nelimitată; pentru utilizarea în
scopuri comerciale trebuie să fie plătite licenţele corespunzătoare
SQL Server este sistemul de gestiune a bazelor de date relaţionale dezvoltat de firma
Microsoft pentru sistemele de operare Windows. Au existat mai multe versiuni, versiunea actuală
(2007) fiind SQL Server 2005. În toate versiunile sistemul SQL Server suportă complet standardul
SQL2, cu implementarea performantă a trăsăturilor avansate de stocare şi prelucrare a datelor
(integritate referenţială, subinterogări, triggere, gestiunea tranzacţiilor, etc). De la adresa

148
http://www.microsoft.com/sql se poate obţine gratuit o versiune de test a sistemului SQL Server sau
se poate cumpăra o versiune completă. În plus, pachetul de dezvoltare .NET SDK (.NET Software
Development Kit), care se poate obţine gratuit de la adresa http://msdn.microsoft.com/downloads
conţine o versiune mai simplă de server de baze de date numit Microsoft SQL Server 2000 Desktop
Engine (MSDE 2000) care poate fi folosită pentru dezvoltarea şi execuţia exemplelor prezentate în
lucrare.
Microsoft Access este unul din cele mai cunoscute sisteme de gestiune a bazelor de date
relaţionale pe platforme de calculatoare personale. MS Access dispune de un sistem de control al
bazei de date (database engine) şi o interfaţă grafică pentru interacţiunea cu utilizatorul. Aplicaţiile
de baze de date în MS Access se pot dezvolta cu multă uşurinţă datorită generatoarelor de aplicaţii
(Wizards) care permit proiectarea vizuală a bazelor de date şi a formularelor (forms) pentru
interfeţele grafice. MS Access este folosit în special pentru aplicaţii personale sau pentru mici afaceri
şi licenţa acestuia se poate cumpăra odată cu licenţa produsului Microsoft Office.
MySQL este un sistem de gestiune a bazelor de date relaţionale cu implementări pentru sistemele de
operare Windows, Linux, Unix. La adresa http://www.mysql.com se găseşte ultima versiune şi documentaţia
sistemului de gestiune a bazelor de date MySQL care se poate utiliza gratuit (este open source). Acest sistem
este compatibil cu standardul SQL2, dar unele prevederi ale standardului sunt implementate parţial.
Versiunea actuală 2007 este versiunea 5.0 care ofera vederi, proceduri stocate, triggere (caracteristici care
lipseau in versiunile precedente).

149