BAZE DE DATE

Fundamente ale bazelor de date

Tehnologiile informaţionale influenţează continuu şi produc modificări substanţiale

asupra mijloacelor de lucru din întreaga lume. Informaţii care erau altădată stocate în
depozite pline de dulapuri, pot fi accesate astăzi prin intermediul unei singure apăsări a
butonului mouse-ului. Astfel, pentru stocarea informaţiilor din orice mediu imaginabil în zilele
noastre sunt folosite sistemele de baze de date. De la bazele de date mari, aşa cum sunt
sistemele care permit rezervarea on-line a biletelor pentru companiile aeriene şi până la
fişele dintr-o bibliotecă, sistemele de baze de date sunt folosite pentru memorarea şi
distribuirea datelor de care încep să depindă tot mai mult vieţile noastre.
Până în urmă cu câţiva ani, sistemele mari de baze de date se găseau numai pe
calculatoare de tip mainframe. Însă, aşa cum era şi firesc, proiectarea, achiziţionarea sau
întreţinerea unei astfel de maşini reprezenta o sarcină costisitoare şi dificil de realizat. Odată
cu apariţia calculatoarelor din clasa staţiilor de lucru, pe care le întâlnim la tot pasul (biblioteci,
laboratoare de informatică, departamente de lucru, etc.) şi care sunt puternice şi în acelaşi
timp destul de ieftine, programatorii au posibilitatea de a proiecta rapid şi la costuri reduse
produse informatice care să permită întreţinerea şi distribuirea datelor.
Cercetarea aferentă bazelor de date are aproape 35 de ani de istorie, ani care au
condus în mod inevitabil la cele mai relevante şi importante dezvoltări ale ingineriei software.
În mod natural, tehnologiile specifice bazelor de date, arhitecturile şi cadrele conceptuale au
fost tot mai bine consolidate în ultimile decade. Mai mult, în ultimii ani, managementul
bazelor de date a evoluat astfel încât bazele de date au devenit o componentă cheie a
sistemelor informaţionale moderne. Acest aspect a provocat un impact adânc precum şi
modificări semnificative în modul de lucru al instituţiilor şi organizaţiilor, contribuind într-o
măsură relevantă la adoptarea celor mai adecvate decizii care să le poată garanta succesul
în afaceri şi nu numai. În acest context, este important să menţionăm anumiţi factori care au
contribuit la această explozie: noile tehnici şi instrumente de modelare, cele mai importante,
fiind cele care se bazează pe o gândire orientată obiect, apariţia procesării de tipul client-
server, diminuarea semnificativă a preţurilor aferente atât componentei hardware cât şi a
celei software şi, nu în ultimul rând, necesitatea unei administrări eficiente şi corecte a
cantităţilor tot mai mari de informaţii care caracterizează activităţile fiecărei organizaţii din
zilele noastre.
În prezent, bazele de date fac parte tot mai mult din viaţa noastră de zi cu zi în aşa
măsură, încât uneori nici măcar nu mai conştientizăm că le utilizăm. Atunci când cumpărăm
ceva de la un supermarket, probabil că va fi accesată o bază de date. Casierul va trece un
cititor de coduri de bare peste fiecare dintre articolele pe care le achiziţionăm. Acesta este
conectat la un sistem informatic pentru baze de date, care utilizează codul de bare pentru a
identifica preţul produsului pe care l-am ales, evident dintr-o bază de date care gestionează
produsele. De asemenea, dacă stocul pentru un produs scade sub o anumită limită, este
posibil ca sistemul să emită în mod automat o comandă către un furnizor, pentru a obţine un
stoc suplimentar din acel articol.

Ce este baza de date?

Majoritatea bazelor de date iau naştere începând cu o listă într-un editor de texte sau
într-o foaie de calcul. La momentul respectiv, suntem tentaţi să credem că a fost aleasă cea
mai bună soluţie, atât timp cât necesităţile informaţionale sunt satisfăcute, este adevărat, în
contextul unei cantităţi reduse de informaţii. În timp însă, acest volum creşte (spre exemplu,

3
odată cu creşterea activităţii unei organizaţii, ceea ce face ca soluţiile (privite iniţial ca fiind
cele mai adecvate) să nu mai fie potrivite. Mai mult, pe măsură ce lista devine tot mai mare,
încep să apară redundanţe şi inconsistenţe la nivelul datelor gestionate. Datele devin greu de
înţeles sub forma listei, iar posibilităţile de căutare, regăsire şi extragere a subseturilor de
date pentru revizuire, actualizare sau utilizare devin extrem de limitate. Odată cu apariţia
acestor probleme, o idee bună, chiar o necesitate în anumite situaţii, ar fi aceea al
transferului acestor date într-o bază de date creată cu ajutorul unui sistem de gestiune al
bazelor de date.
În prezent ne este tot mai clar faptul că explozia informaţională este de ani buni
trăsătura definitorie care caracterizează activităţile fiecărei organizaţii sau instituţii, indiferent
de domeniul său de activitate. Volumul tot mai însemnat de informaţii nu mai poate fi utilizat
eficient cu ajutorul mijloacelor tradiţionale. Practic, constatăm că procesul de prelucrare
automată a datelor prin intermediul sistemelor electronice de calcul a devenit o necesitate
pentru majoritatea domeniilor de activitate. În acest context, putem afirma că cea mai
evoluată metodă de organizare a datelor în vederea prelucrării lor automate o întâlnim la
bazele de date.
În literatura de specialitate există numeroase definiţii aferente conceptului de bază de
date. În continuare vom prezenta câteva dintre ele, care, în opinia noastră, acoperă cel mai
bine conceptul de bază de date.
„O bază de date conţine toate informaţiile necesare despre obiectele ce intervin într-o
mulţime de aplicaţii, relaţii logice între aceste informaţii şi tehnicile de prelucrare
corespunzătoare. În bazele de date are loc o integrare a datelor, în sensul că mai multe
fişiere sunt privite în ansamblu, eliminându-se pe cât posibil acele informaţii redundante. De
asemenea, este permis accesul simultan la aceleaşi date, care se regăsesc în acelaşi loc
sau sunt distribuite spaţial, a mai multor persoane de pregătiri diferite, fiecare cu stilul
personal de lucru” [Bâscă, 1997, p.11].
Referitor la definiţia prezentată anterior, putem spune că avem unele reţineri în ceea
ce priveşte utilizarea conceptului de informaţie. Astfel, autorul vede baza de date ca un
ansamblu de informaţii, părere pe care o împărtăşim parţial şi numai în cazul în care se face
referire la baza de date în general, dar nu şi la o bază de date relaţională. Este cert faptul că
atunci când facem referire la baza de date relaţională, nu putem vorbi de informaţii, ci numai
de date.
„Totodată, putem privi baza de date ca ansambluri unitare de date, structurate,
corelate logic între ele şi memorate împreună cu descrierea formală a structurii lor şi a
legăturilor logice dintre ele, a cărui gestionare este realizată de un sistem software unitar şi
specializat, numit sistem de gestiune a bazei de date” [Georgescu, Georgescu, 2005, p.63].
O definiţie completă şi explicativă a noţiunii de bază de date este oferită în [Velicanu et
al., 2003, p.51]. Astfel, aceasta reprezintă un ansamblu de colecţii de date:
• organizat, pe niveluri de organizare a datelor (conceptual, logic, fizic), aşa cum reiese şi
din arhitectura pe niveluri a unui sistem de baze de date;
• coerent, conform restricţiilor de integritate şi a legăturilor dintre date, care rezultă din
modelul logic aferent;
• structurat, conform unui model de date pentru bazele de date;
• cu redundanţă minimă şi controlată, care este asigurată prin modelul de date implementat
şi prin tehnicile de proiectare ale bazei de date;
• accesibil mai multor utilizatori în timp real, adică mai mulţi utilizatori, concomitent, pot
obţine informaţiile dorite atunci când au nevoie de ele.

4
 Profesorul M. Fotache prezintă şi analizează o definiţie academică a bazei de date.
Astfel, în opinia acestuia, baza de date reprezintă un ansamblu structurat de fişiere care
grupează datele prelucrate în aplicaţiile informatice ale unei persoane, grup de persoane,
întreprinderi, instituţii, etc. Din punct de vedere formal, defineşte baza de date ca „o colecţie
de date aflate în interdependenţă, împreună cu descrierea datelor şi relaţiilor dintre ele sau,
similar, o colecţie de date folosită într-o organizaţie, colecţie care este automatizată, partajată,
definită riguros (formalizată) şi controlată la nivel central” [Fotache, 2005, p.14].
Plecând de la definiţiile prezentate anterior, putem afirma că o bază de date
relaţională reprezintă o colecţie partajată de date, între care există diferite legături logice
(împreună cu o descriere a acestora), proiectată pentru a satisface necesităţile
informaţionale ale fiecărei organizaţii. Totodată, putem privi o bază de date ca un instrument
pentru organizarea şi colectarea tuturor informaţiilor, astfel încât să se satisfacă toate
necesităţile informaţionale ale utilizatorilor ei.
Definiţia prezentată anterior trebuie analizată în detaliu pentru a putea fi în măsură să
dobândim o mai bună înţelegere a conceptului de bază de date. Baza de date reprezintă un
depozit de date unic, larg, care este definit o singură dată şi este utilizat simultan de diferite
departamente sau utilizatori. Această soluţie substituie crearea mai multor fişiere separate cu
date de cele mai multe ori considerate a fi redundante şi presupune integrarea tuturor datelor
necesare, dublarea lor fiind în acest caz minimală. De aici decurge un prim avantaj
semnificativ: baza de date nu mai este deţinută de un singur departament, ci constituie acum
o resursă comună, partajată. Pe de altă parte, baza de date conţine nu numai datele
operaţionale ale unei organizaţii sau instituţii, ci şi o descriere a acestora, întâlnite în
literatură sub denumirea de metadate (date despre date).
Atunci când analizăm necesităţile informaţionale ale unei organizaţii, avem în vedere
în principal identificarea entităţilor, atributelor şi relaţiilor. Putem privi o entitate ca un obiect
distinct (o persoană, un departament, un concept sau un eveniment) care aparţine unei
organizaţii şi care trebuie reprezentat în baza de date. Atributul este o proprietate care
descrie un aspect oarecare al obiectului pe care dorim să-l înregistrăm, iar relaţia se referă la
o asociaţie între diferite entităţi. Astfel, putem spune că baza de date conţine entităţile,
atributele, dar şi relaţiile (legăturile) logice dintre ele. În capitolul 4 vom arăta cum se
concretizează din punct de vedere practic legăturile logice dintre relaţii, prin introducerea
conceptului de cheie străină.

Arhitecturi ale sistemelor de baze de date

În literatura de specialitate sunt prezentate mai multe tipuri de arhitecturi ale
sistemelor de baze de date. Nouă ne-au atras atenţia cele prezentate în [Velicanu et al.,
2003, p.13]. Astfel, conform autorilor, rolul unei arhitecturi este de a realiza o reprezentare
grafică a elementelor sistemului, precum şi a legăturilor dintre ele. În funcţie de ceea ce se
evidenţiază grafic, se folosesc două tipuri de arhitecturi:
1. arhitectura pe componente – oferă o imagine asupra elementelor care formează un
sistem de baze de date, dar şi a inter-dependenţelor dintre ele.
Componentele specifice arhitecturii pe componente sunt:
a. datele – sunt organizate într-o bază de date care conţine:
• colecţii de date propriu-zise;
• dicţionarul de date (structura de date, restricţiile de integritate, vederile, etc.);
• fişierele anexe, aşa cum sunt cele de index.

5
 b. software-ul – este aferent realizării şi exploatării bazei de date şi conţine:
• sistemul de gestiune a bazei de date;
• programele de aplicaţie dezvoltate, în cea mai mare parte, într-un sistem de
gestiune a bazelor de date.
c. elementele auxiliare – sunt componentele care contribuie la realizarea şi funcţionarea
întregului sistem de baze de date:
1. un set de proceduri automate (rutine) şi manuale;
2. reglementări legale şi administrative;
3. mijloace hardware utilizate;
4. persoane implicate pe categorii de utilizatori.

2. Arhitectura pe niveluri structurează un sistem de baze de date pe trei niveluri şi oferă o

imagine despre modul de organizare şi funcţionare al acestuia.
Niveluri de
Vederi ale
Manipulare date Descriere date organizare
bazei de date
date

Program Structura externa

Programator aplicatie 1 (logica)
de aplicatie ... ... Logic

SGBD
Administrator Structura
baza de date conceptuala Conceptual
S.O. ...

Inginer
Structura interna
(analist) de B a z ă d e d at e (fizica) Fizic
sistem

Figura 1.2. Arhitectura pe niveluri a unui sistem de baze de date

În arhitectura prezentată în figura 1.2 sunt redate nivelurile de organizare

(reprezentare) a datelor în baza de date şi legăturile dintre ele: nivelul conceptual, nivelul
logic şi nivelul fizic.
a. nivelul conceptual – este dat de viziunea administratorului bazei de date asupra datelor.
Legat de acest nivel, se pot menţiona următoarele aspecte:
• administratorul realizează structura conceptuală a bazei de date, eventual cu ajutorul
instrumentelor oferite de un SGBD;
• structura conceptuală se obţine utilizând un anumit model de date pentru baza de date,
precum şi o tehnică de proiectare cât mai adecvată;
• structura conceptuală este o reprezentare în interiorul sistemului a realităţii pe care
baza de date o transcrie;
• viziunea administratorului asupra bazei de date este independentă de aplicaţiile care
vor fi dezvoltate (independenţa logică);

6
 • rezultatul nivelului conceptual este schema conceptuală;
• realizarea schemei corespunde unei activităţi de modelare pentru că este vorba
despre o transpunere în termeni abstracţi a entităţilor lumii reale;
• odată definită, schema conceptuală trebuie confruntată cu lumea reală pentru
identificarea şi soluţionarea neconcordanţelor sau a omisiunilor; datorită caracterului
său global şi unitar, se recomandă ca schema conceptuală să fie gestionată de o
singură persoană [Georgescu, Georgescu, 2005, p.67].
b. nivelul logic – este dat de viziunea programatorului asupra datelor. Legat de acest nivel
se pot prezenta următoarele aspecte:
• programatorul realizează programele de aplicaţie pentru descrierea şi manipularea
datelor, scrise într-un SGBD;
• programele implementează structura externă (logică) a datelor;
• structura externă este dedusă din structura conceptuală;
• structura externă reprezintă viziunea programatorului asupra bazei de date pentru o
anumită aplicaţie;
• viziunea programatorului este independentă de suportul tehnic de informaţie
(independenţa fizică);
• rezultatul nivelului logic este schema externă, ca parte din schema conceptuală,
implementată cu ajutorul unui SGBD.
c. nivelul fizic – este dat de viziunea analistului (inginerului) de sistem asupra datelor şi are
rolul de a descrie modul în care sunt stocate datele în baza de date. Aferent nivelului fizic
putem menţiona următoarele:
• analistul de sistem este cel căruia îi revine sarcina de a realiza structura internă
(fizică);
• structura internă este dedusă din cea externă conform unor tehnici şi metode de
alocare pe suport fizic;
• structura internă corespunde descrierii datelor pe suportul fizic de informaţie;
• rezultatul la nivelul fizic este schema internă (fizică) care se defineşte în termeni de
fişiere şi înregistrări;
• implementarea schemei interne se face cu ajutorul sistemului de gestiune a fişierelor
(SGF) din cadrul SGBD-ului şi/sau din sistemul de operare, prin gestiunea fizică a
perifericelor.

7
 Proiectarea şi administrarea unei baze de date

În prezent observăm că avalanşa produselor software o depăşeşte net pe cea a

componentelor hardware. Însă, din păcate, dacă privim evoluţia în timp a dezvoltării
sistemelor software constatăm că nu este impresionantă. În ultimile decade am observat o
expansiune a aplicaţiilor software, de la cele mici şi relativ simple şi care presupuneau câteva
linii de cod, până la cele mari, destul de complexe şi care presupuneau scrierea a milioane şi
milioane de linii de cod. Însă, în mod normal, aceste aplicaţii necesitau şi o întreţinere
constantă, care urmărea în primul rând corectarea erorilor detectate, îmbunătăţirea
funcţionalităţii prin implementarea altor cerinţe care veneau din partea utilizatorului. Totodată,
această ameliorare avea în vedere şi adaptarea acestor aplicaţii la platforme multiple, astfel
încât, indiferent de locul în care rula aplicaţia, funcţionalitatea ei să nu fie afectată.
Toate aceste aspecte specifice întreţinerii au condus la un consum tot mai însemnat
de resurse, iar rezultatul nu a întârziat să apară: multe proiecte importante se aflau în
întârziere, bugetul alocat lor devenea constant insuficient, întreţinerea se face tot mai greu,
iar performanţele întârziau să apară (cam 80-90% din sisteme nu-şi atingeau scopul). Practic,
această situaţie a condus la ceea ce se numea la vremea respectivă „criza de software”.
Printre principalele motive care au stat la baza acestei crize putem aminti: lipsa specificaţiilor
complete referitoare la cerinţe, a unei metodologii adecvate de realizare, dar şi proasta
partiţionare a proiectării în componente uşor de manevrat. Astfel, ca o soluţie care să permită
ieşirea din criză şi soluţionarea problemelor menţionate anterior, a fost propusă o nouă
abordare structurată privind dezvoltarea produselor software, numită ciclu de viaţă al
sistemelor informaţionale.

Ciclul de viaţă al sistemelor informaţionale

Putem privi sistemul informaţional ca un ansamblu de fluxuri şi circuite informaţionale,
organizate într-o concepţie unitară şi care asigură legătura dintre sistemul decizional (de
conducere) şi cel operaţional (de execuţie).
Trebuie menţionat faptul că nu trebuie să confundăm sistemul informaţioanal cu cel
informatic (din păcate, am constatat că există studii sau păreri care le privesc pe cele două
ca fiind unul şi acelaşi lucru). Astfel, sistemul informatic reprezintă un ansamblu structurat de
elemente intercorelate funcţional, utilizat pentru culegerea, prelucrarea, transmiterea şi
stocarea datelor cu ajutorul mijloacelor automate de prelucrare a datelor. Scopul acestuia
este de a automatiza procesul informaţional şi de a sta la baza fundamentării deciziilor. În
plus, sistemul informatic este inclus în cel informaţional şi îi oferă acestuia noi valenţe, atât
sub aspect calitativ, cât şi cantitativ. Acest lucru se realizează prin implementarea de către
sistemul informatic a unor modele matematice şi prin utilizarea tehnicii electronice de calcul.
Începând cu anii ’70, treptat, sistemele de baze de date le-au luat locul celor bazate pe
fişiere, ca parte a infrastructurii sistemelor informaţionale din cadrul unei organizaţii. În
acelaşi timp, a avut loc o recunoaştere treptată a faptului că datele constituie o resursă
comună, importantă, vitală în anumite situaţii, care trebuie tratată cu respect, ca toate
celelalte resurse ale organizaţiei. Acest aspect a avut ca rezultat crearea unor departamente
funcţionale denumite administrarea datelor şi administrarea bazelor de date, care erau
responsabile cu administrarea şi controlul datelor.
Astfel, considerăm că baza de date este o componentă de bază a unui sistem
informaţional, iar dezvoltarea şi utilizarea sa trebuie privite şi analizate din perspectiva
8
cerinţelor mai largi ale organizaţiei. În acest context, ciclul de viaţă al sistemului informaţional
dintr-o organizaţie este puternic legat de ciclul de viaţă al sistemului de baze de date care îl
susţine. De obicei, etapele aferente ciclului de viaţă al unui sistem informaţional includ:
planificarea, analiza cerinţelor, proiectarea (inclusiv a bazei de date), prototipizarea,
implementarea şi întreţinerea.

Ciclul de viaţă al unui sistem de baze de date

Etapele specifice ciclului de viaţă al unei aplicaţii de tip bază de date nu sunt strict
secvenţiale, ci pot presupune revenirea la o etapă anterioară şi repetarea lor. Spre exemplu,
dacă apar anumite probleme în timpul proiectării bazei de date, se poate reveni la etapa
anterioară care are drept obiectiv colectarea şi analiza cerinţelor.
Principalele activităţi asociate fiecărei etape din ciclul de viaţă al aplicaţiei de tip bază
de date sunt:
• planificarea bazei de date – presupune planificarea modului în care etapele ciclului de
viaţă pot fi realizate cel mai eficient;
• delimitarea graniţelor sistemului – se referă la specificarea scopului şi limitelor aplicaţiei, a
utilizatorilor săi şi a domeniilor de aplicaţie. Înainte de a începe proiectarea unei aplicaţii
de tip bază de date, este foarte important să definim limitele (graniţele) sistemului avut în
vedere şi modul în care acesta realizează interfaţa cu alte părţi ale sistemului
informaţional al organizaţiei. Practic, includerea şi delimitarea graniţelor unui sistem este
o etapă importantă, nu numai pentru utilizatorii şi aplicaţiile curente, ci şi pentru cele din
viitor;
• colectarea şi analiza cerinţelor – are în vedere analiza cerinţelor colectate de la utilizatori,
dar şi a domeniilor de aplicaţie. Mai precis, această etapă vizează procesul de culegere şi
analiză a informaţiilor aferente organizaţiei pentru care se proiectează baza de date
respectivă, dar şi utilizarea acestora în vederea identificării cerinţelor utilizatorilor privind
noul sistem;
• proiectarea bazei de date – include proiectarea conceptuală, logică şi fizică. În sens larg,
principalele scopuri urmărite atunci când se doreşte proiectarea unei baze de date se
referă la:
ƒ reprezentarea datelor şi a relaţiilor logice dintre acestea, necesare tuturor
domeniilor de aplicaţie şi principalelor grupuri de utilizatori;
ƒ oferirea unui model de date care să permită realizarea tranzacţiilor asupra datelor;
ƒ specificarea unui proiect minimal şi structurat în mod adecvat pentru realizarea
cerinţelor stabilite referitoare la performanţele noului sistem;
ƒ alegerea SGBD-ului – este o etapă opţională şi presupune alegerea unui SGBD
adecvat pentru aplicaţia realizată. Această alegere poate fi făcută în orice moment
anterior proiectării logice, cu condiţia să fie disponibile suficiente informaţii
referitoare la cerinţele sistemului, cum ar fi performanţa sau constrângerile de
securitate şi integritate;
ƒ proiectarea aplicaţiei – are în vedere proiectarea interfeţei cu utilizatorul şi a
programelor care utilizează şi prelucrează baza de date;
ƒ prototipizarea – este tot o etapă opţională şi presupune construirea unui prototip de
sistem care să permită proiectantului, dar şi utilizatorului, să evalueze modul de
funcţionare al noului sistem;
ƒ implementarea – la încheierea etapelor de proiectare, ne aflăm în situaţia de a
implementa baza de date şi programele aplicaţie. Implementarea bazei de date se
9
 realizează prin utilizarea limbajului de definire a datelor (LDD), corespunzător
sistemului de gestiune a bazelor de date ales. Instrucţiunile limbajului LDD sunt
compilate şi utilizate pentru a permite crearea schemei bazei de date. Totodată,
toate vederile specificate de către utilizatori sunt definite în această etapă;
ƒ testarea – este etapa în care se testează aplicaţia şi se identifică eventualele
neconcordanţe dintre cerinţele utilizatorilor şi rezultatul furnizat de aceasta;
ƒ întreţinerea operaţională – presupune o monitorizare continuă a aplicaţiei realizate,
iar dacă este nevoie, vor fi încorporate cerinţe noi, parcurgând etapele precedente
ale ciclului de viaţă.

Proiectarea bazelor de date

Connoly şi colaboratorii săi [Connoly et al., 2002, p.281-282] identifică şi descriu trei
tipuri de proiectări:
• conceptuală, care se referă la dezvoltarea unui model informaţional independent de orice
considerent privitor la aspectul fizic al datelor;
• logică, care vizează construirea unui model informaţional bazat pe unul din modelele
tradiţionale (E-R 1 , relaţional, OO 2 , OR 3 ), dar independent de tipul SGBD-ului ales şi de
alte aspecte fizice ale modelului;
• fizică – urmăreşte implementarea efectivă a bazei de date pe suportul de stocare, inclusiv
acele aspecte care ţin de asigurarea şi garantarea securităţii datelor.
Proiectarea corespunzătoare bazei de date este o etapă foarte importantă, mai ales că
trebuie să fie capabilă să garanteze buna funcţionare a acesteia şi a oricărei aplicaţii care o
utilizează. În lipsa unei proiectări adecvate a bazei de date, aceasta poate prezenta mai
multe deficienţe, cum ar fi:
• compromiterea integrităţii datelor deoarece restricţiile de integritate nu pot fi proiectate
sau implementate corect;
• datele sunt redundante, iar aplicaţiile individuale se „aglomerează” în încercarea de a se
asigura sincronizarea datelor;
• performanţele sunt afectate deoarece este posibil ca pentru finalizarea unei instrucţiuni
(spre exemplu, instrucţiunea Select) să fie necesare interogări suplimentare.

1
E-R – Entitate – Relaţie
2
OO – Orientat Obiect
3
OR – Obiectual – Relaţional
10
 Sisteme de gestiune a bazelor de date

În sens larg putem defini sistemul de gestiune a bazelor de date (SGBD) ca un sistem
de programe care permite utilizatorilor definirea, generarea şi întreţinerea unei baze de date,
precum şi accesul controlat la aceasta. În [Velicanu et al., 2003, p.94] SGBD-ul este definit
ca un ansamblu complex de programe care asigură interfaţa între o bază de date şi utilizatorii
acesteia. Totodată, autorii consideră SGBD-ul o componentă software a unui sistem de baze
de date care este capabil să interacţioneze cu toate celelalte componente ale acestuia,
asigurând legătura şi independenţa între elementele sistemului.
Un SGBD oferă utilizatorului posibilitatea de a accesa datele prin intermediul unui
limbaj de nivel înalt, apropiat de modul obişnuit de exprimare, pentru a obţine informaţii,
utilizatorul făcând abstracţie de mijloacele şi metodele folosite pentru alegerea datelor
implicate şi a modului de memorare a lor. SGBD-ul este practic o interfaţă între utilizatori şi
sistemul de operare.
Termenul de bază de date se va referi la datele de prelucrat, la modul de organizare a
acestora pe suportul fizic de memorare, iar termenul de gestiune va semnifica totalitatea
operaţiilor ce se aplică asupra datelor din baza de date.

Facilităţi oferite de un SGBD

Spre deosebire de un limbaj de programare obişnuit, în care declararea datelor este
realizată în acelaşi loc cu prelucrarea lor, bazele de date dispun de limbaje separate pentru
declarare şi prelucrare. Această separare se justifică prin faptul că într-un program obişnuit
datele există efectiv numai pe parcursul rulării lui, în timp ce într-o bază de date, în general,
ele sunt definite o singură dată şi nu sunt necesare redefiniri ulterioare pentru fiecare
prelucrare realizată.
Practic, un SGBD constă în elemente software care interacţionează cu programele
aplicaţie ale utilizatorului şi cu baza de date. Printre principalele facilităţi care sunt oferite de
un SGBD menţionăm:
1. permite utilizatorului să definească baza de date, de obicei prin intermediul unui limbaj de
definire a datelor (LDD), care permite fiecărui utilizator să specifice tipurile şi structurile de
date, în timp ce constrângerile asupra datelor sunt memorate în baza de date;
2. oferă posibilitatea actualizării datelor în baza de date (adăugare, modificare, ştergere),
dar şi a extragerii lor prin intermediul limbajului de manipulare a datelor (LMD). Faptul că
există un depozit central al tuturor datelor şi descrierilor acestora permite limbajului de
manevrare să ofere o facilitate de interogare generală a acestor date, denumită limbaj de
interogare. Existenţa unui limbaj de interogare elimină dificultăţile sistemelor bazate pe
fişiere, unde utilizatorul este constrâns să lucreze cu un set fix de interogări pentru a evita
proliferarea de programe, care creează probleme majore privind gestionarea acestora.
Există două tipuri de limbaje de manipulare a datelor:
• procedurale
• neprocedurale
care se pot deosebi în funcţie de operaţiile de extragere. Principala diferenţă între ele
constă în faptul că, de obicei, limbajele procedurale tratează bazele de date înregistrare
cu înregistrare, în timp ce limbajele neprocedurale operează asupra unor seturi de
11
 înregistrări. În consecinţă, limbajele procedurale specifică cum se va obţine rezultatul unei
instrucţiuni LMD, iar cele neprocedurale descriu numai ce date vor fi obţinute. Cel mai
obişnuit tip de limbaj neprocedural este limbajul structurat de interogare (SQL - pronunţat
„Es-Q-L” sau, uneori, „Sii-Quel”), care reprezintă acum atât limbajul standard, cât şi cel de
facto pentru sistemele SGBD relaţionale.
3. oferă accesul controlat la baza de date. De exemplu, poate furniza:
• un sistem de securitate, care previne accesarea bazei de date de către
utilizatori neautorizaţi;
• un sistem de integritate, care menţine concordanţa datelor stocate;
• un sistem de control al concurenţei, care permite accesul partajat la baza de
date;
• un sistem de control al refacerii, care restaurează baza de date într-o stare
precedentă concordantă, ca urmare a unei defecţiuni la nivel hardware sau
software;
• un catalog accesibil utilizatorilor, care conţine descrieri ale datelor din baza de
date.
Datorită funcţionalităţilor pe care le oferă, SGBD-urile constituie instrumente extrem de
utile. Totuşi, deoarece pe utilizatori nu-i interesează cât de complexă sau de uşoară este
pentru sistem o anumită sarcină, s-ar putea argumenta că sistemul SGBD a făcut ca
lucrurile să devină mai complexe, deoarece acum se pot vedea mai multe date decât este
cu adevărat necesar sau decât se doreşte. Ca o recunoaştere a acestei probleme,
sistemul SGBD prezintă o altă facilitate, cunoscută sub denumirea de mecanism de
vizualizare, care permite fiecărui utilizator să-şi definească propriul mod de vizualizare a
bazei de date. Limbajul LDD permite definirea de moduri de vizualizare, în care acestea
reprezintă un subset al bazei de date.
4. oferă un anumit nivel de securitate. Modurile de vizualizare pot fi realizate astfel încât să
nu includă datele ce nu trebuie cunoscute de anumiţi utilizatori. De exemplu, s-ar putea
crea un mod de vizualizare care să permită unui administrator de filială şi departamentului
Contabilitate să afişeze toate datele referitoare la personalul unei instituţii, inclusiv
detaliile despre salariu. Pe lângă acesta, s-ar putea crea un al doilea mod de vizualizare,
care să excludă detaliile despre salariu, ce va fi utilizat de către ceilalţi angajaţi;
5. pot prezenta o imagine coerentă, neschimbată a structurii bazei de date, chiar dacă
aceasta este modificată (de exemplu, s-ar putea adăuga sau elimina câmpuri, s-ar putea
modifica relaţiile, diviza, restructura sau redenumi anumite fişiere). Dacă sunt adăugate
sau eliminate câmpuri dintr-un fişier, iar acestea nu sunt cerute de către modul de
vizualizare, el nu este afectat de către modificarea realizată. Prin urmare, modul de
vizualizare contribuie la asigurarea independenţei program-date.

Componentele unui SGBD

Principalele componente ale unui SGBD sunt [Georgescu, Georgescu, 2005, p.75-81]:
• motorul SGBD – este componenta care asigură interfaţa dintre subsistemul de proiectare
şi cel de execuţie pe de o parte, şi datele bazei de date pe de altă parte şi are rolul de a
asigura accesul fizic la datele bazei de date. Toate acţiunile motorului SGBD sunt
realizate unitar şi respectă restricţiile impuse de legăturile dintre date, dar şi de regulile de
integritate ale bazei de date definite în dicţionarul de date. Principalele responsabilităţi ale
motorului SGBD sunt:
ƒ realizează gestionarea tranzacţiilor la nivelul unei baze de date;

12
 ƒ permite regăsirea datelor pe baza informaţiilor de adresare din fişierele de index;
ƒ salvarea şi restaurarea datelor;
ƒ blocarea şi deblocarea datelor în cazul operaţiilor fizice la nivelul memoriei externe;
• subsistemul instrumentelor de proiectare – dispune de un set de instrumente software
care permit proiectarea şi generarea bazei de date şi a aplicaţiilor care descriu modul de
utilizare a bazei de date. Această componentă permite definirea:
ƒ structurii tabelelor din baza de date;
ƒ machetelor de interfaţă cu utilizatorul;
ƒ a formatului rapoartelor şi cererilor de interogare a bazei de date.
Subsistemul instrumentelor de proiectare poate include:
ƒ limbaje de descriere a datelor (LDD) 4 ;
ƒ limbaje de manevrare a datelor;
ƒ limbaje de interogare a datelor din baza de date;
ƒ editoare de cod;
ƒ generatoare de cod care să permită definirea interfeţei cu utilizatorul, a rapoartelor,
meniurilor, etc.;
ƒ un sistem de asistenţă on-line pentru autodocumentarea utilizatorului.
• subsistemul de execuţie – permite execuţia aplicaţiilor sau cererilor de consultare a bazei
de date, formulate prin utilizarea instrumentelor subsistemului de proiectare, prin
consultarea dicţionarului de date şi generarea tranzacţiilor. Aceasta este componenta
care garantează autonomia logică a datelor în baza de date şi are rolul de a intermedia
operaţiile cu baza de date prin consultarea descrierii organizării logice a datelor
memorate în structura bazei de date. Practic, fiecare operaţie de actualizare sau
consultare a bazei de date se realizează prin identificarea formatelor de descriere a
datelor din dicţionarul de date şi conectarea acestor descrieri din schema internă a bazei
de date

Funcţiile SGBD-ului
În [Velicanu et al., 2003, p.104-107] se arată că îndeplinirea tuturor obiectivelor unui
SGBD se realizează prin intermediul unor componente care permit efectuarea unor operaţii
specifice. În funcţie de natura lor, dar şi de scopul urmărit, operaţiile pot fi grupate pe
activităţi. Activităţile acceptă şi ele o grupare pe funcţii astfel încât, una sau mai multe
activităţi, relativ omogene, vor realiza o funcţie anume. Ţinând cont de complexitatea unui
SGBD, de facilităţile pe care le pune la dispoziţie, de limbajele utilizate, precum şi de modul
de implementare al modelului de date, gruparea activităţilor pe funcţii are un anumit caracter
relativ.
Plecând de la modelul de date pe care îl implementează, SGBD-urile se
caracterizează printr-un număr de particularităţi identificate prin operaţii şi activităţi specifice.
În pofida acestor particularităţi, există câteva funcţii general valabile pentru toate tipurile de
SGBD; acestea sunt funcţii importante, pe care un sistem software, dacă nu le are în
totalitate, nu poate fi considerat SGBD. Astfel, principalele funcţii pe care le putem atribui
unui SGBD sunt: descrierea datelor, manipularea datelor, utilizarea şi administrarea bazei de
date.
4
Un limbaj de descrierea a datelor permite descrierea componenţei bazei de date, a structurii acesteia , a relaţiilor dintre
componentele ei, precum şi a tuturor drepturilor de acces ale utilizatorilor la baza de date.
13
 Descrierea datelor
Prin intermediul funcţiei de descriere a datelor, fiecare SGBD permite definirea unei
structuri a bazei de date cu ajutorul limbajului de definire a datelor (LDD). Definirea datelor
poate fi realizată la nivel conceptual, logic şi fizic. Se descriu atributele din cadrul structurii
bazei de date, legăturile dintre entităţile acesteia sau dintre atributele aceleiaşi entităţi, se
definesc criteriile de validare a datelor (dacă este cazul), metodele care asigură accesarea
datelor, precum şi aspectele care se referă la asigurarea integrităţii datelor. Concretizarea
acestei funcţii este schema bazei de date, memorată în cod intern. Memorarea se face într-
un fişier, ceea ce permite afişarea şi actualizarea structurii bazei de date, în orice moment de
timp.
Această funcţie a fost mult automatizată în timp, limbajul de descriere a datelor
beneficiind în prezent de puţine comenzi. Acest limbaj este specific fiecărui SGBD, dar el
mereu realizează descrierea lor conform elementelor modelului de date pe care îl
implementează SGBD-ul respectiv. Astfel se realizează definirea şi descrierea entităţilor şi a
caracteristicilor lor, definirea legăturilor dintre obiectele identificate (asocierile) şi a regulilor
de integritate specifice modelului de date.
Manipularea datelor
Funcţia de manipulare a datelor este cea mai complexă şi realizează actualizarea şi
regăsirea datelor din baza de date, cu ajutorul limbajului de manipulare a datelor 5 .
Manipularea datelor este cea mai folosită funcţie în bazele de date, fiind cea mai bine
suportată de sistemul de gestiune a bazelor de date faţă de oricare alt sistem de gestionare a
datelor din memoria externă. Practic, un SGBD manipulează datele într-o manieră eficientă,
folosind în acest scop diferite tehnici şi metode de optimizare a accesului şi a alocării
spaţiului din memoria calculatorului.
Menţionam în paragraful anterior că limbajul de manipulare a datelor este cel care
asigură realizarea acestei funcţii. În ceea ce-l priveşte, acest limbaj trebuie să respecte
restricţiile de integritate a datelor şi să implementeze operatorii din modelul de date pe care
se bazează SGBD-ul căruia îi aparţine.
Această funcţie presupune derularea următoarelor activităţi:
• încărcarea datelor în baza de date - se realizează prin operaţii automatizate sau
programate ce asigură şi criteriile de validare necesare;
• actualizarea bazei de date – se referă la operaţiile de adăugare, modificare şi ştergere de
înregistrări. La operaţiile de adăugare şi de modificare se păstrează aceleaşi criterii de
validare care s-au folosit şi la activitatea de încărcare a datelor. Actualizarea se
realizează numai autorizat, prin asigurarea unei protecţii corespunzătoare a datelor,
pentru a se păstra coerenţa bazei de date.
• prelucrarea datelor – presupune realizarea operaţiilor de selecţie, ordonare, etc. efectuate
asupra entităţilor bazei de date. Acestea sunt, de obicei, operaţii pregătitoare activităţii de
regăsire a datelor. Multe din operaţiile de prelucrare sunt realizate cu ajutorul operatorilor
din modelul de date pe care îl implementează SGBD-ul.
• regăsirea (interogarea) datelor – presupune realizarea operaţiilor de vizualizare (afişare
pe ecran, imprimare pe hârtie), răsfoire, editarea unor documente de ieşire (rapoarte).
Documentele de ieşire pot fi intermediare sau finale şi se pot obţine pe diferiţi suporţi
tehnici de informaţie (ecran, hârtie, mediu magnetic, mediu optic). Ele pot avea cele mai

5
În literatură întâlnim frecvent şi Limbaj de Manevrare a Datelor
14
 diferite forme (punctuale, liste, rapoarte, grafice, imagini, sunet, video, etc) şi se pot
obţine după cele mai diferite criterii de regăsire.
Funcţia de utilizare
Această funcţie are rolul de a asigura interfeţele necesare care să permită
comunicarea utilizatorilor cu baza de date (cu alte cuvinte, să asigure legătura dintre utilizator
şi baza de date). Pentru realizarea acestei funcţii, SGBD-ul trebuie să ofere facilităţi pentru
mai multe categorii de utilizatori ai bazei de date, şi anume: neinformaticieni, specialişti
(informaticieni) şi administratorul.
Utilizatorii neinformaticieni reprezintă principala categorie a beneficiarilor de informaţii
(utilizatori finali şi intensivi) din baza de date. SGBD-ul le oferă acestora limbaje
neprocedurale, dar şi alte facilităţi de interogare (generatoare, utilitare, etc.) a bazei de date
într-o formă simplă şi interactivă. Aceşti utilizatori nu trebuie să cunoască structura bazei de
date şi nu trebuie să ştie să programeze, SGBD-ul sprijinindu-i în manieră interactivă în
utilizarea bazei de date. În acest sens SGBD-ul oferă:
• meniuri cu opţiuni sugestive;
• ferestre de lucru;
• şabloane pentru diferite forme;
• asistenţi tip Wizard;
• autodocumentarea (help-uri, mesaje/ferestre explicative).
Spre deosebire de utilizatorii neinformaticieni, cei specialişti în informatică sunt în
măsură să creeze structura bazei de date şi să realizeze proceduri complexe de exploatare a
acesteia. SGBD-ul oferă acestor utilizatori limbajul de descriere şi limbajul de manipulare a
datelor precum şi interfeţe cu limbaje universale. Acestea sunt de complexitate şi putere
diferită, de la un SGBD la altul, oferind atât elemente neprocedurale cât şi procedurale
specialistului în informatică. Cu aceste elemente el poate să descrie schema bazei de date şi
să asigure manipularea complexă a datelor.
Administrarea bazei de date
Funcţia de administrare este una destul de complexă şi din acest motiv se consideră
că este doar de competenţa administratorului bazei de date.
Administratorul, care are o bogată experienţă de analiză, proiectare şi programare,
organizează şi administrează baza de date în toate etapele de realizare a acesteia. Astfel, el
organizează baza de date conform unei anumite metodologii, realizează schema
conceptuală a acesteia şi coordonează proiectarea ei. Pentru toate aceste aspecte, SGBD-ul
oferă o serie de instrumente CASE, precum şi o serie de utilitare specializate.
În etapa de exploatare a bazei de date, administratorul îndeplineşte mai multe roluri:
• de a autoriza accesul la date (crează conturi de acces, parole, etc.);
• de a reface baza de date în caz de incidente (prin jurnalizare, copii de siguranţă);
• de a utiliza eficient spaţiul de memorie internă şi externă (prin organizare, rutine de
optimizare);
• de a realiza o serie de analize statistice din baza de date (număr şi tip de utilizatori,
număr de accese, număr de actualizări, etc.).
Pentru fiecare din activităţile menţionate mai sus, SGBD-ul oferă instrumente şi tehnici
de lucru.

15
 Abordarea relaţională a bazelor de date
Înainte de a prezenta principalele aspecte care caracterizează modelul relaţional,
considerăm că este oportună definirea conceptului de bază de date relaţională. După o
îndelungă analiză şi sinteză a definiţiilor formulate de cercetătorii consacraţi ai domeniului,
dar şi profesori de seama care au analizat această paradigmă, putem afirma pe scurt că o
bază de date relaţională reprezintă colecţii organizate de date şi corelate din punct de vedere
logic. La o simplă analiză a definiţiei, observăm că ea impune două direcţii de studiu:
1. colecţii organizate de date;
2. colecţii corelate logic.
În acest context, pe parcursul capitolului, plecând de la prezentarea aspectelor fundamentale
care caracterizează modelul relaţional al bazelor de date, vom argumenta definiţia prezentată
anterior şi implicit cele două direcţii de studiu.
Atunci când luăm în discuţie abordarea relaţională a bazelor de date, vom analiza în
principal trei direcţii:
• structura datelor – are în vedere definirea domeniilor şi a relaţiilor corespunzătoare
acestor domenii;
• integritatea datelor – se referă la definirea restricţiilor de integritate care au rolul de a
proteja datele bazei de date; lipsa unor restricţii de integritate ar putea avea ca efect
alterarea conţinutului bazei de date şi obţinerea unor rezultate eronate;
• prelucrarea datelor – se realizează prin intermediul operaţiilor specifice algebrei
relaţionale sau calculului relaţional.
După cum sugerează şi numele, modelul relaţional se bazează pe noţiunea de relaţie
care este definită din punct de vedere matematic ca o submulţime a produsului cartezian a
unei liste (finite) de mulţimi, numite domenii. Fiecare element al unei relaţii poartă numele de
tuplu, iar numărul de domenii se numeşte aritate. Într-o relaţie, fiecare domeniu se identifică
printr-un nume, numit atribut, iar mulţimea numelor atributelor unei relaţii formează schema
acesteia. Fie relaţia din exemplul 4.1:

Exemplul 4.1. Student (cnp, nr_matr, nume, pren, facult, spec)

Astfel, în exemplul anterior am definit relaţia Student care include atributele:
• cnp – definit pe domeniul cod numeric personal;
• nr_matr – definit pe domeniul număr_matricol;
• nume – definit pe domeniul nume;
• pren – definit pe domeniul prenume;
• facult – defint pe domeniul facultate;
• spec – definit pe domeniul specializare;
De asemenea, formulând altfel, putem spune că în exemplul 4.1 am definit relaţia
Student cu schema dată de atributele cnp, nr_matr, nume, pren, facult, spec. În exemplul 4.2
sunt prezentate trei tupluri pentru relaţia Student defintă în exemplul 4.1.

Exemplul 4.2
Student ( cnp nr_matr nume pren facult spec )
16
 1701212120139 1234 Popa Dan FSE IE
2731210176143 1987 Darie Alina FD AP
1801009129145 4432 Mihnea Ion FSE FB

În ceea ce priveşte o relaţie, ordinea de apariţie a atributelor este absolut

nesemnificativă şi acelaşi lucru îl putem spune şi despre tupluri.
Aşa cum se observă, un tuplu se obţine prin atribuirea de valori atributelor relaţiei. În
ceea ce priveşte tuplurile unei relaţii (care se mai numesc şi realizări) trebuie spus că nu pot
exista două sau mai multe tupluri identice. Altfel spus, toate tuplurile unei relaţii trebuie să
difere cel puţin prin valoarea unui atribut: cheia.
Cheia reprezintă un atribut (sau un grup de atribute) care are rolul de a identifica în
mod unic fiecare tuplu al unei relaţii, astfel încât nu pot exista două tupluri diferite care să
aibă valori identice pe domeniul unei chei. În cadrul abordării relaţionale există patru tipuri de
chei care pot fi identificate:
• candidat;
• primară;
• alternantă (în funcţie de sursa citată, întâlnim în litaratură şi termenul de cheie
alternativă);
• străină.
Dintre cele patru tipuri de chei, primele trei se analizează la nivelul unei singure relaţii,
în timp ce cheia străină apare atunci când asociem două sau mai multe relaţii (este cea care
asigură practic legătura logică între diferite relaţii).
Atunci când analizăm o relaţie, primul pas pe care îl facem este acela al identificării
cheilor candidat. Dintre cheile candidat identificate, se alege una ca fiind cheia primară a
relaţiei respective, restul cheilor candidat devenind chei alternante. În general, vom alege ca
şi cheie primară, acea cheie candidat care este formată din numărul minim de atribute. În
cazul în care am identificat mai multe chei candidat şi fiecare dintre ele au acelaşi număr de
atribute, atunci oricare din cheile candidat pot deveni cheie primară, alegerea făcându-se în
funcţie de opţiunea şi dorinţa proiectantului.
Deşi pot exista mai multe chei candidat, este bine să reţinem că fiecare relaţie are o
singură cheie primară, care în anumite situaţii poate fi formată chiar din toate atributele ei.
Pentru a exemplifica tipurile de chei, abordate până acum doar la nivel teoretic, vom
folosi relaţia din exemplul 4.1. Aşa cum aminteam anterior, iniţial trebuie să identificăm cheile
candidat ale relaţiei Student. Cu alte cuvinte, trebuie să identificăm acele atribute sau grupuri
de atribute pentru care nu pot exista valori duplicate, indiferent de numărul de tupluri ale
relaţiei Student (iniţial se analizează atributele în mod individual şi apoi se fac combinaţii între
ele, pentru a identifica în mod clar toate cheile). Vom începe cu atributul nume: în mod cert,
acest atribut nu poate fi considerat cheie deoarece oricând pot exista doi studenţi cu acelaşi
nume. Acelaşi lucru putem afirma şi despre atributul pren.
Totodată, nici atributele facult şi spec nu sunt chei candidat deoarece la o facultate şi
la o specializare sunt înscrişi mai mulţi studenţi. În exemplul 4.3 am redat alte tupluri pentru
relaţia Student şi în care se poate observa că avem valori duplicate pe domeniile analizate.

Exemplul 4.3
Student ( cnp nr_matr nume pren facult spec )

17
 1701212120139 1234 Popa Dan FSE IE
2731210176143 1987 Darie Dan FD AP
1801009129145 4432 Popa Ion FSE IE
În continuare ne vom opri asupra celor două atribute rămase, şi anume cnp şi nr_matr.
Cu siguranţă, că la întrebarea „Sunt atributele cnp şi nr_matr chei candidat?” am primi un
singur răspuns: „DA”. Aşa să fie oare? Nu este aşa. Iar argumentul este dat de exemplul 4.4.

Exemplul 4.4
Student ( cnp nr_matr nume pren facult spec )
1701212120139 1234 Popa Dan FSE IE
2731210176143 1987 Darie Dan FD AP
2731210176143 5634 Darie Dan FSE FB

Aşa cum observăm, pe domeniul aferent atributului cnp, avem două valori identice:
este situaţia în care o persoană este studentă la două facultăţi diferite (şi nu este singura
situaţie posibilă). Deci, nici atributul cnp nu poate fi cheie candidat. De ce am ajuns să facem
o astfel de greşeală şi să considerăm că cnp poate fi cheie? Probabil că ne-am gândit la
faptul că nu pot existat două persoane cu acelaşi CNP. Este adevărat: nu există două
persoane cu acelaşi CNP, însă schema relaţiei Student nu conţine doar atribute despre o
persoană, ceea ce înseamnă că trebuia să ne gândim dacă pentru un anume CNP putem
identifica cel puţin o valoare a unui alt atribut care să se modifice faţă de tuplul de la care am
plecat.
În ceea ce priveşte atributul nr_matr, putem spune că el este cheie candidat. Cum
arătăm asta? Să plecăm de la situaţie din exemplul 4.5.
Exemplul 4.5
Student ( Cnp nr_matr nume pren facult spec )
1701212120139 1234 Popa Dan FSE IE
? 1234 ? ? ? ?
Astfel, considerăm că avem un tuplu care reprezintă un student cu numărul matricol
1234, care este la facultatea FSE, specializarea IE. Dacă vom putea înlocui semnul întrebării
aferent unui atribut cu o valoare diferită de cea aflată pe celălalt tuplu (evident, pentru acelaşi
atribut), atunci cele două tupluri diferă, ceea ce înseamnă că putem avea valori duplicate pe
domeniul respectiv de valori. În mod cert, un student cu o anumită matricolă (în cazul nostru
1234) nu poate avea alt cod numeric personal, alt nume sau alt prenume. De asemenea, un
student nu poate fi la două specializări diferite (în aceeaşi facultate sau în facultăţi diferite)
având aceeaşi matricolă. Asta înseamnă că dacă pe tuplul doi am avea 1234 ca matricolă,
atunci toate celelalte valori ar fi identice cu cele de la primul tuplu, situaţie care ar face ca
cele două tupluri să fie identice şi aşa cum aminteam în prima parte, o astfel de situaţie nu
este permisă (acest aspect este reprezentat în exemplul 4.6). Deci, atributul nr_matr este
cheie candidat a relaţiei Student.
Exemplul 4.6
Student ( cnp nr_matr nume pren facult spec )
1701212120139 1234 Popa Dan FSE IE
1701212120139 1234 Popa Dan FSE IE
Odată identificată o cheie candidat, procesul nu este finalizat. În continuare va trebui
să căutăm şi diferite combinaţii de atribute care ar putea fi cheie. Singurul lucru clar este
18
acela că atributul nr_matr nu poate face parte din nici o cheie compusă (cheia trebuie să fie
formată din numărul minim de atribute care identifică în mod unic tuplurile unei relaţii). Dacă
vom avea în vedere algoritmul descris anterior, vom mai identifica o cheie candidat:
cnp+facult+spec. De ce toate trei? Dacă ne-am gândi la atributele cnp+facult am vedea că un
student într-o facultate, poate fi la mai multe specializări (spre exemplu, la forme diferite de
învăţământ) în timp ce pentru combinaţia de atribute cnp+spec ar putea apare valori
duplicate în cazul în care mai multe facultăţi ar avea o aceeaşi specializare. Însă, în situaţia
în care le analizăm pe toate trei am ajunge la concluzia că o persoană nu poate face aceeaşi
specializare de două ori într-o facultate 6 .
Sintetizând, pentru relaţia Student am identificat două chei candidat:
• nr_matr;
• cnp+facult+spec.
Dintre cele două chei candidat, vom alege cheia primară ca fiind nr_matr deoarece are
mai puţine atribute decât cealaltă cheie, ceea ce înseamnă că, în final vom avea:
• chei candidat: nr_matr, cnp+facult+spec;
• cheie primară: nr_matr;
• cheie alternantă: cnp+facult+spec.
Astfel, în final, relaţia noastră ar arăta astfel:

Exemplul 4.7. Student (cnp, nr_matr, nume, pren, facult, spec)

Aşa cum observăm, atributul/atributele care formează cheia primară a relaţiei vor
apare subliniate.
În mod normal, relaţia de mai sus este una nenormalizată şi este evident că ea
introduce redundanţă. Astfel, ar fi mai simplu dacă datele referitoare la facultăţi, respectiv
specializări, le-am gestiona separat, în relaţii de sine stătătoare. În acest caz, redundanţa ar
fi în mare măsură înlăturată, iar procesul de identificare a cheilor ar fi mult simplificat. Astfel,
în exemplul 4.8 vom descompune relaţia în alte trei relaţii:

Exemplul 4.8
Student (cnp, nr_matr, nume, pren)
Facultate (facult, profil)
Specializare (spec, formă_înv)
În relaţia Facultate, atributul facult este cheie primară deoarece considerăm că nu pot
exista două facultăţi cu acelaşi nume în cadrul unei universităţi. De asemenea, atributele
spec şi formă_înv formează cheia primară în relaţia Specializare numai luate împreună
deoarece o anumită specializare poate apare la diferite forme de învăţământ (spre exemplu,
specializarea Contabilitate şi Informatică de Gestiune are studenţi şi la forma de învăţământ
Zi, şi la Ifr).

6
Mecanismul de identificare corectă şi completă a cheilor unei relaţii se va realiza numai după parcurgerea şi înţelegerea
procesului de normalizare a unei baze de date relaţionale.
19
 Astfel, prin descompunerea relaţiei iniţiale în cele trei relaţii din exemplul 4.8 am
argumentat prima parte a definiţiei bazei de date relaţionale. Aşa cum observăm, în acest
moment structura noastră este formată din trei colecţii organizate în care:
• Student conţine doar date de strudenţi;
• Facultate include ca realizări (tupluri) doar facultăţile gestionate;
• Specializare care se referă la specializările fiecărei facultăţi gestionate.

Legături între relaţii

Dacă analizăm cu atenţie relaţiile din exemplul 4.8 observăm că redundanţa datelor a
fost înlăturată, în sensul că aceleaşi date nu le mai gestionăm de mai multe ori în cadrul unei
relaţii, aşa cum se întâmpla în exemplul 4.7, unde numele unei facultăţi ar fi apărut de fiecare
dată când mai gestionam un student al aceleaşi facultaţi (realizarea FSE, ca valoare a
atributului facult ar fi apărut de fiecare dată când am fi avut un student al acestei facultăţi).
Însă, în acelaşi timp, în exemplul 4.7 erau disponibile informaţii complete despre student
(nume, prenume, facultatea la care studiază, specializarea la care este înmatriculat). Odată
cu descompunerea în mai multe relaţii, observăm că aceste informaţii nu le mai avem: există
trei relaţii în care avem date personale despre studenţi (relaţia Student), date despre facultăţi
(relaţia Facultate), respectiv date despre specializări (relaţia Specializare), fără însă să
putem spune la ce facultate sau specializare este un anume student.
În acest context, pentru a putea oferi aceste informaţii, trebuie să asociem relaţiile
modelului din exemplul 4.8. Astfel, abordarea relaţională propune patru tipuri de legături între
relaţii.

Legătura binară 1-1 (unu la unu)

Definiţie. Atunci când asociem două relaţii fiu, legătura dintre ele se realizează prin
migrarea cheilor primare din fiecare relaţie, sub forma cheii străine în relaţiile
corespunzătoare.
Obs. În cadrul unei asocieri binare, fiecare dintre cele două relaţii poate fi atât relaţie fiu, cât
şi relaţie părinte.
Definiţie. Spunem despre o relaţie că este fiu atunci când unui tuplu din relaţia
respectivă îi corespunde un singur tuplu în relaţia cu care s-a asociat.
Definiţie. O relaţie este considerată părinte atunci când unui tuplu din relaţia respectivă
îi pot corespunde mai multe tupluri în relaţia cu care s-a asociat.
Definiţie. Cheia străină reprezintă un atribut (sau un grup de atribute) care
îndeplineşte rolul de cheie primară în cadrul relaţiei din care a migrat. Practic, cheia străină
este cea care permite crearea legăturilor logice dintre relaţii. Ca valori ale atributelor care
formează cheia străină putem avea fie valori care se regăsesc pe domeniul cheii primare în
relaţia din care provine cheia străină, fie valoarea NULL (în literatura de specialitate, această
constrângere este numită restricţie referenţială).

Exemplul 4.9: Fie următoarele două relaţii:

Client ( cnp nume pren localitate )
1701212120139 Popa Dan Galaţi
2711010120121 Darie Alina Brăila
1721209145123 Preda Marin Galaţi

20
 Legitimaţie ( nr_leg valabilitate )
12121 2
23456 2
187654 3

Prin intermediul relaţiilor Client şi Legitimaţie încercăm să modelăm situaţia accesului

într-un supermarket pe baza unei legitimaţii. Pentru a realiza legătura dintre relaţiile asociate,
va trebui să identificăm mai întâi tipul relaţiilor (fiu sau părinte). Astfel, pe baza definiţiilor
prezentate anterior, observăm că ambele relaţii sunt fiu deoarece fiecare client, la un
moment dat, nu poate avea decât o singură legitimaţie care să-i permită accesul în
supermarket. Cu alte cuvinte, pentru exemplul 4.9, Popa Dan nu poate avea decât o singură
legitimaţie, ceea ce înseamnă că unui tuplu din relaţia Client nu-i poate corespunde decât un
singur tuplu în relaţia Legitimaţie. Analizând în acelaşi mod, este evident că o legitimaţie nu
poate corespunde mai multor clienţi.
Astfel, deoarece ambele relaţii sunt fiu, tipul de legătură dintre cele două este 1-1.
Conform definiţiei enunţate, atributul cnp va migra din relaţia Client (unde este cheie primară)
în relaţia Legitimaţie, unde va îndeplini rolul de cheie străină. În acelaşi mod, atributul nr_leg
va migra din relaţia Legitimaţie în relaţia Client, iar modelul va arăta ca în exemplul 4.10.
Exemplul 4.10:
Client ( cnp nume pren localitate nr_leg )
1701212120139 Popa Dan Galaţi 23456
2711010120121 Darie Alina Brăila 12121
1721209145123 Preda Marin Galaţi 187654

Legitimaţie ( nr_leg valabilitate cnp )

12121 2 2711010120121
23456 2 1701212120139
187654 3 1721209145123

După migrarea cheii primare sub forma cheii străine, putem spune că am realizat
legătura între relaţiile asociate, astfel încât să putem spune despre un client ce număr de
legitimaţie are, sau plecând de la numărul legitimaţiei, să putem identifica fără ambiguitate
care este deţinătorul acesteia.

Legătura binară 1-n (unu la mai mulţi)

Definiţie. Atunci când asociem două relaţii, dintre care una este relaţie fiu, iar cealaltă
este părinte, legătura dintre ele se realizează prin migrarea cheii primare din relaţia părinte,
sub forma cheii străine în relaţiile fiu.
Pentru exemplificare, vom pleca de la relaţiile Student şi Specializare din exemplul 4.8.
Exemplul 4.11:
Student ( nr_matr cnp nume pren )
1111 1701212120139 Popa Dan
2222 2711010120121 Darie Alina
3333 1721209145123 Preda Marin

Specializare ( cod_spec spec formă_înv )

61 CIG ZI
51 FB ZI
52 FB IFR

21
 Pentru a avea o evidenţă clară a apartenenţei unui student la o specializare, va trebui
să realizăm legătura dintre cele două relaţii. Ca şi în cazul primului tip de legătură, şi de
această dată vom pleca de la identificarea tipurilor de relaţii, răspunzând pe rând la
întrebarea: „Unui tuplu din relaţia X câte tupluri în relaţia Y îi pot corespunde”, unde X şi Y
sunt cele două relaţii pe care le asociem.
a. Identificarea tipului pentru relaţia Student: întrebarea la care trebuie să răspundem este:
„Un student la câte specializări poate fi?”. La această întrebare, o parte din cititori ar
putea spune că un student poate fi la una sau mai multe specializări, în timp ce alţii
consideră că un student nu poate fi decât la o singură specializare. Răspunsul corect este
cel de-al doilea deoarece un student, care are asociată o anumită matricolă, nu poate fi la
mai multe specializări. Este clar că o persoană, cu un anume cod numeric personal,
poate fi la mai multe specializări, caz în care numărul matricol este altul. Altfel spus,
studentul Popa Dan cu matricola 1111 nu poate aparţine decât unei singure specializări.
Concluzionând vom afirma despre Student că este relaţie fiu.
b. Identificarea tipului pentru relaţia Specializare – în acest caz, răspunsul la întrebarea: „La
o specializare câţi studenţi pot fi înmatriculaţi?” este „mai mulţi”, ceea ce înseamnă că
unui tuplu din relaţia Specializare îi corespund mai multe tupluri din relaţia Student. În
acest caz, Specializare este relaţie părinte.
Plecând de la analiza făcută anterior, am stabilit că relaţia Student este fiu în timp ce
relaţia Specializare este părinte: legătura dintre cele două se va realiza prin migrarea cheii
primare din relaţia părinte (cod_spec din Specializare) sub formă de cheie străină în relaţia
Student, iar modelul va arăta ca în exemplul 4.12.
Exemplul 4.12:
Student ( nr_matr cnp nume pren cod_spec )
1111 1701212120139 Popa Dan 61
2222 2711010120121 Darie Alina 52
3333 1721209145123 Preda Marin 61

Specializare ( cod_spec spec formă_înv )

61 CIG ZI
51 FB ZI
52 FB IFR

În exemplul 4.12 observăm că, după crearea legăturii, suntem în măsură să

identificăm specializarea la care este înmatriculat fiecare student. Astfel, atunci când vom
dori să aflăm care este specializarea şi forma de învăţământ a studentului Preda Marin, se va
realiza o interogare a datelor din relaţia Specializare şi se va identifica acel tuplu care are ca
valoare a atributului cod_spec, valoarea aferentă cheii străine din relaţia Student, adică 61.
După parcurgerea secvenţială a tuplurilor din Specializare vom vedea că studentul este la
specializarea CIG, forma de învăţământ ZI.

Legătura binară n-n (mai mulţi la mai mulţi)

Definiţie. Atunci când asociem două relaţii părinte, legătura dintre ele se realizează
prin generarea unei noi relaţii care va avea ca şi cheie primară, cheile primare ale relaţiilor
asociate. Această nouă relaţie poate include şi alte atribute (în afara celor care formează
cheia primară) care reies din contextul problemei modelate.
Fie relaţiile Factură şi Produs din exemplul 4.13:

22
Exemplul 4.13:
Factură ( serie_fact nr_fact val_fact data_fact )
DX 1111 100 10.10.2008
VR 2222 200 10.10.2008
DF 3333 300 12.10.2008

Produs ( cod_produs den_prod um stoc )

11 Telefon Nokia Buc 0
22 TV Samsung Buc 2
33 Laptop Asus Buc 2

Considerăm că relaţia Factură permite gestionarea facturilor primite de un comerciant,

în timp ce în relaţia Produs sunt gestionate produsele comercializate. Odată ce am
considerat atributul cod_produs ca fiind cheia primară a relaţiei Produs vom presupune că nu
vor exista două produse care să aibă acelaşi cod, garantându-se astfel (prin semantica
specificată) unicitatea valorilor pe domeniul atributului cod_produs. Totodată, atributul stoc
are rolul de a gestiona cantitatea aferentă unui produs care se găseşte la un moment dat în
stocul comerciantului.
Plecând de la cele două relaţii, dorim să punem în evidenţă care este conţinutul
fiecărei facturi (produsele şi cantităţile conţinute de fiecare factură). Iniţial, vom identifica tipul
relaţiilor pentru a putea realiza legătura dintre ele. Astfel, relaţia Factură este părinte
deoarece considerăm că o factură poate conţine unul sau mai multe produse. Totodată, si
relaţia Produs este tot părinte deoarece un produs poate fi achiziţionat prin intermediul mai
multor facturi. Deci, ambele relaţii sunt de tipul părinte; asta înseamnă că se va crea o nouă
relaţie, care va avea cheia primară formată din cheile primare ale celor două relaţii asociate.
Exemplul 4.14:
Aprovizionare ( serie_fact nr_fact cod_produs cant_aprov )
DX 1111 11 10
DX 1111 33 15
DF 3333 11 5

Aşa cum se observă, legătura de tipul mai mulţi la mai mulţi a fost pusă în evidenţă
prin noua relaţie generată: Aprovizionare. În cadrul acesteia, pe primele două tupluri am pus
în evidenţă faptul că o factură (DX 1111) poate conţine mai multe produse (conţine produsele
cu codul 11 şi 33) în timp ce un produs (cel cu codul 11) poate fi achiziţionat prin intermediul
mai multor facturi (se găseşte atât pe factura DX 1111 cât şi pe DF 3333).
În cadrul relaţiei Aprovizionare observăm un nou atribut, care nu se regăsea la nivelul
relaţiilor pe care le-am asociat. Acest atribut apare în cadrul acestei noi relaţii deoarece o
realizare a acestuia are loc numai atunci când asociem câte un tuplu din fiecare relaţie (nu
putem avea o cantitate aprovizionată dacă există produsul, dar nu există factura şi, în acelaşi
timp, nici dacă există factura şi nu există produsul).

Legătura dintre trei sau mai multe relaţii

Atunci când asociem mai mult de două relaţii, legătura dintre ele se realizează prin
definirea unei noi relaţii, care va avea cheia primară formată din cheile primare ale tuturor
relaţiilor, împreună cu alte atribute care reies din contextul problemei modelate. Practic, este
un caz particular al legăturii binare mai mulţi la mai mulţi, fără însă să mai necesite în
prealabil identificarea tipului fiecărei relaţii.

23
 Revenind la exemplul 4.8, vom asocia cele trei relaţii cu scopul de a putea preciza cu
claritate facultatea şi specializarea la care este înmatriculat fiecare student.
Exemplul 4.15
Student ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Cătălin

Facultate ( facult profil )

Ştiinţe Economice Economic
Drept Administrativ

Specializare ( cod_spec Spec formă_înv

751 FB ZI
752 FB IFR
662 AP IFR

În urma asocierii celor trei relaţii, se va genera o nouă relaţie care se va identifica prin
intermediul atributelor nr_matr, facult şi cod_spec, aşa cum se observă în exemplul 4.16.
Exemplul 4.16
Studiu ( nr_matr facult cod_spec )
111 Ştiinţe Economice 751
222 Drept 662
333 Ştiinţe Economice 751

Cu ajutorul acestei noi relaţii, putem spune despre Preda Marin că este student la
facultatea de Ştiinţe Economice, la specializarea FB, forma de învăţământ IFR.
Abia în acest moment putem spune că am argumentat pe deplin definiţia bazei de
date relaţionale: am creat diferite colecţii de date organizate, după care am stabilit legăturile
logice dintre acestea pentru a avea o viziune completă asupra întregului volum de date care
formează respectiva bază de date. În acest fel, utilizatorul va putea, prin intermediul
comenzilor de interogare specifice SGBD-ului utilizat, să acceseze şi să utilizeze în acelaşi
timp toate datele gestionate în baza de date.

Algebra relaţională – operatorii relaţionali

Algebra relaţională se referă la diferiţi operatori care au ca operanzi relaţiile, fiind
concepută de cercetătorul E.F. Codd. În funcţie de aritatea operatorului, rezultatul aplicării
acestuia la una sau la două relaţii va fi tot o relaţie. În prezentarea operaţiilor, vom pleca de
la presupunerea că fiecare relaţie are un număr finit de tupluri distincte şi sunt descrise prin
intermediul unei mulţimi finite de atribute.
Aceste operaţii specifice algebrei relaţionale sunt folosite pentru formalizarea
limbajului de cereri al sistemului de gestiune al bazelor de date relaţionale. Ele sunt
implementate în funcţiile de manevrare a datelor aferent sistemului de gestiune şi sunt
disponibile utilizatorului cu ajutorul comenzilor limbajului de manevrare a datelor sau a
limbajului de interogare ale sistemului de gestiune [Georgescu, Georgescu, 2005, p.93].
Cererile specifice algebrei relaţionale se pot exprima prin cinci operaţii asupra relaţiilor,
întâlnite în literatură sub numele de operaţii de bază, şi anume: reuniunea, diferenţa,

24
produsul cartezian, proiecţia şi selecţia. Dintre aceste cinci operaţii, primele trei presupun
existenţa a două relaţii în timp ce următoarele se aplică pentru o singură relaţie.
1. Reuniunea. Reuniunea a două relaţii A şi B 7 , notată A ∪ B , este o relaţie care va avea
schema identică cu a relaţiilor reunite şi care va include ca tupluri, toate tuplurile celor două
relaţii, considerate o singură dată.
Exemplul 4.17
Stud1 ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Cătălin

Stud2 ( nr_matr nume pren )

444 Manea Oana
333 Ionescu Cătălin
555 Dragomir Alina

Stud1∪ Stud2 = ( nr_matr Nume pren )

111 Preda Marin
222 Darie Alina
333 Ionescu Cătălin
444 Manea Oana
555 Dragomir Alina

2. Diferenţa. Diferenţa a două relaţii A şi B 8 , notată A \ B , este o relaţie care va avea schema
identică cu a relaţiilor iniţiale şi ca realizări toate tuplurile primei relaţii care nu se regăsesc în
cea de-a doua relaţie.
Astfel, dacă realizăm diferenţa relaţiilor Stud1 şi Stud2 din exemplul 4.17, rezultatul
este următorul:
Stud1\ Stud2 = ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
3. Produsul cartezian. Fie relaţiile A (cu aritatea a) şi B (cu aritatea b) 9 . Produsul cartezian
al celor două relaţii, notat A × B este o relaţie care are aritatea a+b şi care va conţine toate
tuplurile rezultate prin concatenarea unui tuplu din A cu fiecare tuplu din B. Trebuie menţionat
faptul că atunci când schemele celor două relaţii includ şi atribute comune, atunci în schema
produsului cartezian, cele două atribute vor apare de două ori, însă cu nume diferite (o relaţie
nu poate avea două atribute cu acelaşi nume).
Exemplul 4.18
Student ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Cătălin

7
Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii.
8
Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii.
9
Schemele relaţiilor A şi B sunt diferite, dar pot exista atribute comune.
25
 Disciplină ( cod_disc denumire tip_disc )
SE1 Baze de date curs
SE2 Baze de date laborator
SE3 Contabilitate Seminar
Aşa cum se observă, aritatea ambelor relaţii este 3, ceea ce înseamnă că după
realizarea produsului cartezian asupra celor două relaţii, aritatea va fi 6 (relaţia rezultată în
urma operaţiei Student × Disciplină va avea şase atribute), aşa cum se observă mai jos:

Student × Disciplină ( nr_matr nume pren cod_disc denumire tip_disc )

111 Preda Marin SE1 Informatică curs
111 Preda Marin SE2 Informatică laborator
111 Preda Marin SE3 Contabilitate seminar
222 Darie Alina SE1 Informatică curs
222 Darie Alina SE2 Informatică laborator
222 Darie Alina SE3 Contabilitate seminar
333 Ionescu Cătălin SE1 Informatică curs
333 Ionescu Cătălin SE2 Informatică laborator
333 Ionescu Cătălin SE3 Contabilitate seminar

4. Proiecţia. Proiecţia se aplică unei singure relaţii A de aritate a, se notează cu π şi se

realizează după un număr de atribute, a1, a2, …, an, care trebuie să fie incluse în schema
relaţiei A. Noua relaţie va avea schema dată de atributele după care se realizează proiecţia,
Totodată, relaţia obţinută după realizarea proiecţiei va avea acelaşi număr de tupluri ca
relaţia iniţială.
Exemplul 4.19 Fie relaţia Student:
Student ( nr_matr cnp nume pren )
1111 1701212120139 Popa Dan
2222 2711010120121 Darie Alina
3333 1721209145123 Preda Marin
Plecând de la această relaţie, dorim să realizăm proiecţia după atributele nr_matr,
nume şi pren. Astfel, vom obţine următoarea relaţie:

π nr_matr, nume, pren (Student) = ( nr_matr nume pren )

1111 Popa Dan
2222 Darie Alina
3333 Preda Marin

5. Selecţia. Selecţia se defineşte pentru o singură relaţie A de aritate a, se notează cu σ şi

se realizează pe baza unei condiţii logice. Noua relaţie va avea aceeaşi schemă ca relaţia
iniţială şi va conţine doar acele tupluri care respectă condiţia după care se realizează selecţia.
Exemplul 4.20 Fie relaţia Student:
Student ( nr_matr nume pren media )
1111 Popa Dan 7.00
2222 Darie Alina 8.00
3333 Preda Marin 9.00

26
 Plecând de la relaţia de mai sus, dacă dorim să realizăm o selecţie a studenţilor cu
media mai mare sau egală cu opt, vom ajunge la următoare relaţie:

σ media >=8 ( Student ) = ( nr_matr nume pren media )

2222 Darie Alina 8.00
3333 Preda Marin 9.00

Pe lângă operaţiile amintite anterior, se mai pot utiliza şi alte operaţii, numite operaţii
derivate şi care se bazează pe operaţiile de bază. Utilizarea în practică a operaţiilor derivate
oferă o flexibilitate sporită a cererilor de interogare a bazei de date şi facilitează, în cele mai
multe situaţii, obţinerea unor răspunsuri mai rapide. Dintre operaţiile derivate utilizate mai
frecvent amintim:
6. Intersecţia. Intersecţia a două relaţii A şi B 10 , notată A ∩ B , este o relaţie care va avea
schema identică cu a relaţiilor intersectate, iar ca realizări doar tuplurile comune celor două
relaţii.
Exemplul 4.21
Stud1 ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Cătălin

Stud2 ( nr_matr nume pren )

444 Manea Oana
333 Ionescu Cătălin
555 Dragomir Alina

Stud1 ∩Stud2 = ( nr_matr nume pren )

333 Ionescu Cătălin
7. Uniunea. Uniunea se defineşte pentru două relaţii A şi B (de aritate a, respectiv b), o
condiţie logică între două valori ale unor atribute ce aparţin celor două relaţii 11 şi se notează
A | X | B . Rezultatul uniunii va fi o relaţie de aritate a+b, cu schema dată de reuniunea
c
atributelor celor două relaţii şi care va conţine toate tuplurile aferente produsului cartezian
dintre A şi B care respectă condiţia menţionată. Cu alte cuvinte, uniunea a două relaţii se
realizează în doi paşi:
a. realizarea produsului cartezian dintre relaţii;
b. selecţia tuplurilor conform condiţiei logice.
În cazul în care condiţia c este de egalitate, atunci operaţia se numeşte echiuniune. În
plus, dacă vom realiza o proiecţie după atributele primei operaţii, operaţia se numeşte semi-
uniune-stânga, iar dacă se face după atributele relaţiei din dreapta (a doua relaţie) se va
numi semi-uniune-dreapta. În continuare vom exemplifica uniunea şi echiuniunea.

10
Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii.
11
În cazul uniunii, cele două atribute trebuie să fie câte unul din fiecare relaţie.
27
Exemplul 4.22 Fie următoarele relaţii:
Aprov ( s_fact nr_fact cod_prod cant_a )
DX 1122 P1 20
DX 1122 P2 10
JZ 2233 P3 15

Comandă ( cod_cmd cand_c )

C1 20
C2 12
C3 10
În cadrul relaţiei Aprov se presupune că avem situaţia aprovizionărilor, în relaţia
Comandă avem o evidenţă a produselor comandate, iar semantica atributelor este
următoarea:
• s_fact – reprezintă seria unei facturi;
• nr_fact – reprezintă numărul facturii;
• cod_prod – codul produsului achiziţionat prin intermediul unei facturi;
• cant_a – se referă la cantitatea aferentă unui produs care se găseşte pe o factură;
• cod_cmd – codul unei comenzi (se presupune că două comenzi diferite vor avea
coduri diferite);
• cant_c – reprezintă cantitatea comandată prin intermediul unei comenzi.
Pentru a realiza uniunea celor două relaţii, aminteam anterior că primul pas care
trebuie făcut este realizarea produsului cartezian.
Aprov X Comandă= ( s_fact nr_fact cod_prod cant_a cod_cmd cant_c )
DX 1122 P1 20 C1 20
DX 1122 P1 20 C2 12
DX 1122 P1 20 C3 10
DX 1122 P2 10 C1 20
DX 1122 P2 10 C2 12
DX 1122 P2 10 C3 10
JZ 2233 P3 15 C1 20
JZ 2233 P3 15 C2 12
JZ 2233 P3 15 C3 10
După realizarea produsului cartezian, vom face selecţia tuplurilor pe baza condiţiei
cant_a <= cant_c.
Aprov | X | Comandă= ( s_fact nr_fact cod_prod cant_a cod_cmd cant_c )
cant _ a <=
cant _ c

DX 1122 P1 20 C1 20
DX 1122 P2 10 C1 20
DX 1122 P2 10 C2 12
DX 1122 P2 10 C3 10
JZ 2233 P3 15 C1 20
În cazul în care condiţia este cant_a=cant_c, atunci vom avea o echiuniune a celor
două relaţii, aşa cum se observă în exemplul 4.23:

28
Exemplul 4.23: Echiuniunea relaţiilor Aprov şi Comandă.
Aprov | X | Comandă= ( s_fact nr_fact cod_prod cant_a cod_cmd cant_c )
cant _ a =
cant _ c

DX 1122 P1 20 C1 20
DX 1122 P2 10 C3 10

8. Uniunea naturală. Uniunea naturală a relaţiilor A şi B, notată | A X B | se poate realiza

numai în cazul în care cele două relaţii au un set de atribute comune. Astfel, uniunea
naturală se obţine prin selectarea din produsul cartezian al celor două relaţii a tuplurilor ce
conţin valori comune pentru atributele cu acelaşi nume. Schema relaţiei va fi dată de
reuniunea atributelor celor două relaţii (ceea ce înseamnă că atributele comune vor apare o
singură dată).
Exemplul 4.23: Fie următoarele relaţii:
Student ( nr_matr nume pren )
111 Popa Dan
222 Darie Alin
333 Moga Dana

Disc ( den_disc nr_matr notă )

Finanţe 333 9
Birotică 222 10
Birotică 333 8
a. Se realizează produsul cartezian al celor două relaţii:
Student X Disc = ( s.nr_matr nume pren den_disc d.nr_matr notă )
111 Popa Dan Finanţe 333 9
111 Popa Dan Birotică 222 10
111 Popa Dan Birotică 333 8
222 Darie Alin Finanţe 333 9
222 Darie Alin Birotică 222 10
222 Darie Alin Birotică 333 8
333 Moga Dana Finanţe 333 9
333 Moga Dana Birotică 222 10
333 Moga Dana Birotică 333 8
b. La acest pas va trebui să determinăm condiţia după care se va realiza selecţia. Aşa cum
observăm, atributul comun celor două relaţii este nr_matr, ceea ce înseamnă că uniunea
naturală se va face pe baza condiţiei Student.nr_matr = Disc.nr_matr.
c. După identificarea condiţiei, ea se va aplica asupra produsului cartezian realizat la punctul
a:
σ Student .nr _ matr = Disc .nr _ matr ( Student X Disc) =
( s.nr_matr nume pren den_disc d.nr_matr notă )
222 Darie Alin Birotică 222 10
333 Moga Dana Finanţe 333 9
333 Moga Dana Birotică 333 8
d. În final, se realizează o proiecţie asupra relaţiei obţinute la punctul c după mulţimea
atributelor celor două relaţii, considerate o singură dată. După realizarea proiecţiei, vom
obţine:

29
 | Student X Disc |= (nr_matr nume pren den_disc notă )
222 Darie Alin Birotică 10
333 Moga Dana Finanţe 9
333 Moga Dana Birotică 8

9. Uniunea externă. Uniunea externă (outer join) va include toate tuplurile uniunii naturale, la
care se adaugă câte un tuplu pentru acele tupluri dintr-o relaţie care nu au corespondent în
cealaltă relaţie. Tuplurile adăugate au valoarea NULL pentru toate atributele ce nu apar în
relaţia din care provin. Uniunea externă se notează astfel: A | ⊗ | B, unde A şi B sunt cele
două relaţii.
Plecând de la relaţiile Student şi Disc din exemplul 4.23 şi de la uniunea naturală
Student | X | Disc, vom avea următoarea uniune externă:

Exemplul 4.24
Student | ⊗ | Disc = (nr_matr nume pren den_disc notă )
111 Popa Dan NULL NULL
222 Darie Alin Birotică 10
333 Moga Dana Finanţe 9
333 Moga Dana Birotică 8
Aşa cum se observă, în relaţia Student există un singur tuplu care nu are
corespondent în relaţia Disc: în acest caz, tuplul va fi adăugat în relaţia aferentă uniunii
externe, iar valorile aferente atributelor din relaţia Disc pentru care nu există corespondent
vor primi valoarea NULL. În ceea ce priveşte relaţia Disc, nu există nici un tuplu care să nu
aibă corespondent în relaţia Student (altfel spus, valorile 222 şi 333, ca realizări ale
atributului nr_matr în relaţia Disc, se regăsesc în relaţia Student pe domeniul de valori al
atributului nr_matr).
De asemenea, există două operaţii derivate din uniunea externă şi anume uniune
externă stânga (left outer join) şi uniune externă dreapta (right outer join). În ceea ce priveşte
uniunea externă stânga, relaţia va conţine toate tuplurile uniunii naturale la care se vor
adăuga cele ale primei relaţii (considerată relaţia din stânga) care nu au corespondent în
relaţia din dreapta. În dreptul acestor valori se va trece valoarea NULL (exemplul 2.25). În
mod similar se realizează uniunea externă stânga, numai că în acest caz vor fi adăugate
uniunii naturale doar tuplurile relaţiei din dreapta (exemplul 2.26).
Exemplul 4.25
Student | ⊗ Disc = (nr_matr nume pren den_disc notă )
111 Popa Dan NULL NULL
222 Darie Alin Birotică 10
333 Moga Dana Finanţe 9
333 Moga Dana Birotică 8
Exemplul 4.26
Student ⊗ | Disc = (nr_matr nume pren den_disc notă )
222 Darie Alin Birotică 10
333 Moga Dana Finanţe 9
333 Moga Dana Birotică 8

30
 Bibliografie

1. [Bâscă, 1997] Bâscă, O., Baze de date, Editura All, Bucureşti, 1997.
2. [Connoly et al., 2002] Connoly, T., Begg, C., Strachan, A., Database Systems – A
practical Approach to Design, Implementation and Management, Second Edition, Addison
Wesley Limited, 2002.
3. [Date, 1994] Date, J., An introduction to Database Systems, ed. Addison Wesley, 1994.
4. [Date, 2004] Date, J., An introduction to database systems, ediţia a VIII-a, Pearson
Addison Wesley, 2004.
5. [Diaz, 2000] Diaz, O., Advanced database technology and design, ed. Piattini, 2000.
6. [Fotache, 2005] Fotache, M., Proiectarea bazelor de date. Normalizare şi postnormalizare.
Implementări SQL şi Oracle, Editura Polirom, Iaşi, 2005.
7. [Garsia-Molina et al., 2002] Garcia-Molina, H., Ullman, H., Widom, J., Database Systems.
The complete Book, Prentice Hall, Upper Saddle Riner, 2002.
8. [Georgescu, Georgescu, 2005] Georgescu, C., Georgescu, M., Baze de date relaţionale
şi multidimensionale, Editura Didactică şi Pedagogică R.A., Bucureşti, 2005.
9. [Lungu, Bodea, 1995] Lungu, I., Bodea, C., Baze de date – organizare, proiectare şi
implementare, Editura All, Bucureşti, 1995.
10. [Popa et al., 1994] Popa, Ghe., Stanciu, A., Ivancenco, V., Mareş, V., SGBD, Editura All,
Bucureşti, 1994.
11. [Popescu, 2001] Popescu, I., Modelarea bazelor de date, Editura Tehnică, Bucureşti,
2001.
12. [Trandafir et al., 2007] Trandafir, R., Nistorescu, M., Mierluş-Mazilu, I., Baze de date
relaţionale, Bucureşti, 2007.
13. [Velicanu et al., 2000] Velicanu, M., Bodea, C., Lungu, I., Ioniţă, I., Bădescu, G., Sisteme
de gestiune a bazelor de date, Editura Petrion, Bucureşti, 2000.
14. [Velicanu et al., 2003] Velicanu, M., Lungu, I., Muntean, M., Ionescu, S., Sisteme de baze
de date – teorie şi practică, Editura Petrion, Bucureşti, 2003.
15. http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_2.pdf.

31