BAZE DE DATE

Fundamente ale bazelor de date

Tehnologiile informaionale influeneaz continuu i produc modificri substaniale

asupra mijloacelor de lucru din ntreaga lume. Informaii care erau altdat stocate n
depozite pline de dulapuri, pot fi accesate astzi prin intermediul unei singure apsri a
butonului mouse-ului. Astfel, pentru stocarea informaiilor din orice mediu imaginabil n zilele
noastre sunt folosite sistemele de baze de date. De la bazele de date mari, aa cum sunt
sistemele care permit rezervarea on-line a biletelor pentru companiile aeriene i pn la
fiele dintr-o bibliotec, sistemele de baze de date sunt folosite pentru memorarea i
distribuirea datelor de care ncep s depind tot mai mult vieile noastre.
Pn n urm cu civa ani, sistemele mari de baze de date se gseau numai pe
calculatoare de tip mainframe. ns, aa cum era i firesc, proiectarea, achiziionarea sau
ntreinerea unei astfel de maini reprezenta o sarcin costisitoare i dificil de realizat. Odat
cu apariia calculatoarelor din clasa staiilor de lucru, pe care le ntlnim la tot pasul (biblioteci,
laboratoare de informatic, departamente de lucru, etc.) i care sunt puternice i n acelai
timp destul de ieftine, programatorii au posibilitatea de a proiecta rapid i la costuri reduse
produse informatice care s permit ntreinerea 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 dezvoltri 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 nct bazele de date au devenit o component cheie a
sistemelor informaionale moderne. Acest aspect a provocat un impact adnc precum i
modificri semnificative n modul de lucru al instituiilor i organizaiilor, contribuind ntr-o
msur relevant la adoptarea celor mai adecvate decizii care s le poat garanta succesul
n afaceri i nu numai. n acest context, este important s menionm anumii factori care au
contribuit la aceast explozie: noile tehnici i instrumente de modelare, cele mai importante,
fiind cele care se bazeaz pe o gndire orientat obiect, apariia procesrii de tipul client-
server, diminuarea semnificativ a preurilor aferente att componentei hardware ct i a
celei software i, nu n ultimul rnd, necesitatea unei administrri eficiente i corecte a
cantitilor tot mai mari de informaii care caracterizeaz activitile fiecrei organizaii din
zilele noastre.
n prezent, bazele de date fac parte tot mai mult din viaa noastr de zi cu zi n aa
msur, nct uneori nici mcar nu mai contientizm c le utilizm. Atunci cnd cumprm
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 achiziionm. Acesta este
conectat la un sistem informatic pentru baze de date, care utilizeaz codul de bare pentru a
identifica preul 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 ctre un furnizor, pentru a obine un
stoc suplimentar din acel articol.

Ce este baza de date?

Majoritatea bazelor de date iau natere ncepnd cu o list ntr-un editor de texte sau
ntr-o foaie de calcul. La momentul respectiv, suntem tentai s credem c a fost aleas cea
mai bun soluie, att timp ct necesitile informaionale sunt satisfcute, este adevrat, n
contextul unei cantiti reduse de informaii. n timp ns, acest volum crete (spre exemplu,

3
odat cu creterea activitii unei organizaii, ceea ce face ca soluiile (privite iniial ca fiind
cele mai adecvate) s nu mai fie potrivite. Mai mult, pe msur ce lista devine tot mai mare,
ncep s apar redundane i inconsistene la nivelul datelor gestionate. Datele devin greu de
neles sub forma listei, iar posibilitile de cutare, regsire i extragere a subseturilor de
date pentru revizuire, actualizare sau utilizare devin extrem de limitate. Odat cu apariia
acestor probleme, o idee bun, chiar o necesitate n anumite situaii, 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 informaional este de ani buni
trstura definitorie care caracterizeaz activitile fiecrei organizaii sau instituii, indiferent
de domeniul su de activitate. Volumul tot mai nsemnat de informaii nu mai poate fi utilizat
eficient cu ajutorul mijloacelor tradiionale. Practic, constatm 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 prelucrrii lor automate o ntlnim la
bazele de date.
n literatura de specialitate exist numeroase definiii aferente conceptului de baz de
date. n continuare vom prezenta cteva dintre ele, care, n opinia noastr, acoper cel mai
bine conceptul de baz de date.
O baz de date conine toate informaiile necesare despre obiectele ce intervin ntr-o
mulime de aplicaii, relaii logice ntre aceste informaii i tehnicile de prelucrare
corespunztoare. n bazele de date are loc o integrare a datelor, n sensul c mai multe
fiiere sunt privite n ansamblu, eliminndu-se pe ct posibil acele informaii redundante. De
asemenea, este permis accesul simultan la aceleai date, care se regsesc n acelai loc
sau sunt distribuite spaial, a mai multor persoane de pregtiri diferite, fiecare cu stilul
personal de lucru [Bsc, 1997, p.11].
Referitor la definiia prezentat anterior, putem spune c avem unele reineri n ceea
ce privete utilizarea conceptului de informaie. Astfel, autorul vede baza de date ca un
ansamblu de informaii, prere pe care o mprtim parial i numai n cazul n care se face
referire la baza de date n general, dar nu i la o baz de date relaional. Este cert faptul c
atunci cnd facem referire la baza de date relaional, nu putem vorbi de informaii, 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
legturilor logice dintre ele, a crui gestionare este realizat de un sistem software unitar i
specializat, numit sistem de gestiune a bazei de date [Georgescu, Georgescu, 2005, p.63].
O definiie complet i explicativ a noiunii de baz de date este oferit n [Velicanu et
al., 2003, p.51]. Astfel, aceasta reprezint un ansamblu de colecii de date:
organizat, pe niveluri de organizare a datelor (conceptual, logic, fizic), aa cum reiese i
din arhitectura pe niveluri a unui sistem de baze de date;
coerent, conform restriciilor de integritate i a legturilor 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 muli utilizatori, concomitent, pot
obine informaiile dorite atunci cnd au nevoie de ele.

4
 Profesorul M. Fotache prezint i analizeaz o definiie academic a bazei de date.
Astfel, n opinia acestuia, baza de date reprezint un ansamblu structurat de fiiere care
grupeaz datele prelucrate n aplicaiile informatice ale unei persoane, grup de persoane,
ntreprinderi, instituii, etc. Din punct de vedere formal, definete baza de date ca o colecie
de date aflate n interdependen, mpreun cu descrierea datelor i relaiilor dintre ele sau,
similar, o colecie de date folosit ntr-o organizaie, colecie care este automatizat, partajat,
definit riguros (formalizat) i controlat la nivel central [Fotache, 2005, p.14].
Plecnd de la definiiile prezentate anterior, putem afirma c o baz de date
relaional reprezint o colecie partajat de date, ntre care exist diferite legturi logice
(mpreun cu o descriere a acestora), proiectat pentru a satisface necesitile
informaionale ale fiecrei organizaii. Totodat, putem privi o baz de date ca un instrument
pentru organizarea i colectarea tuturor informaiilor, astfel nct s se satisfac toate
necesitile informaionale ale utilizatorilor ei.
Definiia prezentat anterior trebuie analizat n detaliu pentru a putea fi n msur s
dobndim o mai bun nelegere 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 soluie substituie crearea mai multor fiiere 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 deinut de un singur departament, ci constituie acum
o resurs comun, partajat. Pe de alt parte, baza de date conine nu numai datele
operaionale ale unei organizaii sau instituii, ci i o descriere a acestora, ntlnite n
literatur sub denumirea de metadate (date despre date).
Atunci cnd analizm necesitile informaionale ale unei organizaii, avem n vedere
n principal identificarea entitilor, atributelor i relaiilor. Putem privi o entitate ca un obiect
distinct (o persoan, un departament, un concept sau un eveniment) care aparine unei
organizaii i care trebuie reprezentat n baza de date. Atributul este o proprietate care
descrie un aspect oarecare al obiectului pe care dorim s-l nregistrm, iar relaia se refer la
o asociaie ntre diferite entiti. Astfel, putem spune c baza de date conine entitile,
atributele, dar i relaiile (legturile) logice dintre ele. n capitolul 4 vom arta cum se
concretizeaz din punct de vedere practic legturile logice dintre relaii, prin introducerea
conceptului de cheie strin.

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 atenia 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 legturilor dintre ele. n funcie de ceea ce se
evideniaz 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-dependenelor dintre ele.
Componentele specifice arhitecturii pe componente sunt:
a. datele sunt organizate ntr-o baz de date care conine:
colecii de date propriu-zise;
dicionarul de date (structura de date, restriciile de integritate, vederile, etc.);
fiierele anexe, aa cum sunt cele de index.

5
 b. software-ul este aferent realizrii i exploatrii bazei de date i conine:
sistemul de gestiune a bazei de date;
programele de aplicaie 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 funcionarea
ntregului sistem de baze de date:
1. un set de proceduri automate (rutine) i manuale;
2. reglementri 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 funcionare 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 legturile 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 meniona urmtoarele aspecte:
administratorul realizeaz structura conceptual a bazei de date, eventual cu ajutorul
instrumentelor oferite de un SGBD;
structura conceptual se obine utiliznd un anumit model de date pentru baza de date,
precum i o tehnic de proiectare ct mai adecvat;
structura conceptual este o reprezentare n interiorul sistemului a realitii pe care
baza de date o transcrie;
viziunea administratorului asupra bazei de date este independent de aplicaiile care
vor fi dezvoltate (independena logic);

6
 rezultatul nivelului conceptual este schema conceptual;
realizarea schemei corespunde unei activiti de modelare pentru c este vorba
despre o transpunere n termeni abstraci a entitilor lumii reale;
odat definit, schema conceptual trebuie confruntat cu lumea real pentru
identificarea i soluionarea neconcordanelor sau a omisiunilor; datorit caracterului
su 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 urmtoarele aspecte:
programatorul realizeaz programele de aplicaie 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 aplicaie;
viziunea programatorului este independent de suportul tehnic de informaie
(independena 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 meniona urmtoarele:
analistul de sistem este cel cruia 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 informaie;
rezultatul la nivelul fizic este schema intern (fizic) care se definete n termeni de
fiiere i nregistrri;
implementarea schemei interne se face cu ajutorul sistemului de gestiune a fiierelor
(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 observm c avalana produselor software o depete net pe cea a

componentelor hardware. ns, din pcate, dac privim evoluia n timp a dezvoltrii
sistemelor software constatm c nu este impresionant. n ultimile decade am observat o
expansiune a aplicaiilor software, de la cele mici i relativ simple i care presupuneau cteva
linii de cod, pn la cele mari, destul de complexe i care presupuneau scrierea a milioane i
milioane de linii de cod. ns, n mod normal, aceste aplicaii necesitau i o ntreinere
constant, care urmrea n primul rnd corectarea erorilor detectate, mbuntirea
funcionalitii prin implementarea altor cerine care veneau din partea utilizatorului. Totodat,
aceast ameliorare avea n vedere i adaptarea acestor aplicaii la platforme multiple, astfel
nct, indiferent de locul n care rula aplicaia, funcionalitatea ei s nu fie afectat.
Toate aceste aspecte specifice ntreinerii au condus la un consum tot mai nsemnat
de resurse, iar rezultatul nu a ntrziat s apar: multe proiecte importante se aflau n
ntrziere, bugetul alocat lor devenea constant insuficient, ntreinerea se face tot mai greu,
iar performanele ntrziau s apar (cam 80-90% din sisteme nu-i atingeau scopul). Practic,
aceast situaie 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 specificaiilor
complete referitoare la cerine, a unei metodologii adecvate de realizare, dar i proasta
partiionare a proiectrii n componente uor de manevrat. Astfel, ca o soluie care s permit
ieirea din criz i soluionarea problemelor menionate anterior, a fost propus o nou
abordare structurat privind dezvoltarea produselor software, numit ciclu de via al
sistemelor informaionale.

Ciclul de via al sistemelor informaionale

Putem privi sistemul informaional ca un ansamblu de fluxuri i circuite informaionale,
organizate ntr-o concepie unitar i care asigur legtura dintre sistemul decizional (de
conducere) i cel operaional (de execuie).
Trebuie menionat faptul c nu trebuie s confundm sistemul informaioanal cu cel
informatic (din pcate, am constatat c exist studii sau preri care le privesc pe cele dou
ca fiind unul i acelai lucru). Astfel, sistemul informatic reprezint un ansamblu structurat de
elemente intercorelate funcional, utilizat pentru culegerea, prelucrarea, transmiterea i
stocarea datelor cu ajutorul mijloacelor automate de prelucrare a datelor. Scopul acestuia
este de a automatiza procesul informaional i de a sta la baza fundamentrii deciziilor. n
plus, sistemul informatic este inclus n cel informaional i i ofer acestuia noi valene, att
sub aspect calitativ, ct i cantitativ. Acest lucru se realizeaz prin implementarea de ctre
sistemul informatic a unor modele matematice i prin utilizarea tehnicii electronice de calcul.
ncepnd cu anii 70, treptat, sistemele de baze de date le-au luat locul celor bazate pe
fiiere, ca parte a infrastructurii sistemelor informaionale din cadrul unei organizaii. n
acelai timp, a avut loc o recunoatere treptat a faptului c datele constituie o resurs
comun, important, vital n anumite situaii, care trebuie tratat cu respect, ca toate
celelalte resurse ale organizaiei. Acest aspect a avut ca rezultat crearea unor departamente
funcionale denumite administrarea datelor i administrarea bazelor de date, care erau
responsabile cu administrarea i controlul datelor.
Astfel, considerm c baza de date este o component de baz a unui sistem
informaional, iar dezvoltarea i utilizarea sa trebuie privite i analizate din perspectiva
8
cerinelor mai largi ale organizaiei. n acest context, ciclul de via al sistemului informaional
dintr-o organizaie este puternic legat de ciclul de via al sistemului de baze de date care l
susine. De obicei, etapele aferente ciclului de via al unui sistem informaional includ:
planificarea, analiza cerinelor, proiectarea (inclusiv a bazei de date), prototipizarea,
implementarea i ntreinerea.

Ciclul de via al unui sistem de baze de date

Etapele specifice ciclului de via al unei aplicaii de tip baz de date nu sunt strict
secveniale, ci pot presupune revenirea la o etap anterioar i repetarea lor. Spre exemplu,
dac apar anumite probleme n timpul proiectrii bazei de date, se poate reveni la etapa
anterioar care are drept obiectiv colectarea i analiza cerinelor.
Principalele activiti asociate fiecrei etape din ciclul de via al aplicaiei 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 granielor sistemului se refer la specificarea scopului i limitelor aplicaiei, a
utilizatorilor si i a domeniilor de aplicaie. nainte de a ncepe proiectarea unei aplicaii
de tip baz de date, este foarte important s definim limitele (graniele) sistemului avut n
vedere i modul n care acesta realizeaz interfaa cu alte pri ale sistemului
informaional al organizaiei. Practic, includerea i delimitarea granielor unui sistem este
o etap important, nu numai pentru utilizatorii i aplicaiile curente, ci i pentru cele din
viitor;
colectarea i analiza cerinelor are n vedere analiza cerinelor colectate de la utilizatori,
dar i a domeniilor de aplicaie. Mai precis, aceast etap vizeaz procesul de culegere i
analiz a informaiilor aferente organizaiei pentru care se proiecteaz baza de date
respectiv, dar i utilizarea acestora n vederea identificrii cerinelor utilizatorilor privind
noul sistem;
proiectarea bazei de date include proiectarea conceptual, logic i fizic. n sens larg,
principalele scopuri urmrite atunci cnd se dorete proiectarea unei baze de date se
refer la:
reprezentarea datelor i a relaiilor logice dintre acestea, necesare tuturor
domeniilor de aplicaie i principalelor grupuri de utilizatori;
oferirea unui model de date care s permit realizarea tranzaciilor asupra datelor;
specificarea unui proiect minimal i structurat n mod adecvat pentru realizarea
cerinelor stabilite referitoare la performanele noului sistem;
alegerea SGBD-ului este o etap opional i presupune alegerea unui SGBD
adecvat pentru aplicaia realizat. Aceast alegere poate fi fcut n orice moment
anterior proiectrii logice, cu condiia s fie disponibile suficiente informaii
referitoare la cerinele sistemului, cum ar fi performana sau constrngerile de
securitate i integritate;
proiectarea aplicaiei are n vedere proiectarea interfeei cu utilizatorul i a
programelor care utilizeaz i prelucreaz baza de date;
prototipizarea este tot o etap opional i presupune construirea unui prototip de
sistem care s permit proiectantului, dar i utilizatorului, s evalueze modul de
funcionare al noului sistem;
implementarea la ncheierea etapelor de proiectare, ne aflm n situaia de a
implementa baza de date i programele aplicaie. Implementarea bazei de date se
9
 realizeaz prin utilizarea limbajului de definire a datelor (LDD), corespunztor
sistemului de gestiune a bazelor de date ales. Instruciunile limbajului LDD sunt
compilate i utilizate pentru a permite crearea schemei bazei de date. Totodat,
toate vederile specificate de ctre utilizatori sunt definite n aceast etap;
testarea este etapa n care se testeaz aplicaia i se identific eventualele
neconcordane dintre cerinele utilizatorilor i rezultatul furnizat de aceasta;
ntreinerea operaional presupune o monitorizare continu a aplicaiei realizate,
iar dac este nevoie, vor fi ncorporate cerine noi, parcurgnd etapele precedente
ale ciclului de via.

Proiectarea bazelor de date

Connoly i colaboratorii si [Connoly et al., 2002, p.281-282] identific i descriu trei
tipuri de proiectri:
conceptual, care se refer la dezvoltarea unui model informaional independent de orice
considerent privitor la aspectul fizic al datelor;
logic, care vizeaz construirea unui model informaional bazat pe unul din modelele
tradiionale (E-R 1 , relaional, OO 2 , OR 3 ), dar independent de tipul SGBD-ului ales i de
alte aspecte fizice ale modelului;
fizic urmrete implementarea efectiv a bazei de date pe suportul de stocare, inclusiv
acele aspecte care in de asigurarea i garantarea securitii datelor.
Proiectarea corespunztoare bazei de date este o etap foarte important, mai ales c
trebuie s fie capabil s garanteze buna funcionare a acesteia i a oricrei aplicaii care o
utilizeaz. n lipsa unei proiectri adecvate a bazei de date, aceasta poate prezenta mai
multe deficiene, cum ar fi:
compromiterea integritii datelor deoarece restriciile de integritate nu pot fi proiectate
sau implementate corect;
datele sunt redundante, iar aplicaiile individuale se aglomereaz n ncercarea de a se
asigura sincronizarea datelor;
performanele sunt afectate deoarece este posibil ca pentru finalizarea unei instruciuni
(spre exemplu, instruciunea Select) s fie necesare interogri suplimentare.

1
E-R Entitate Relaie
2
OO Orientat Obiect
3
OR Obiectual Relaional
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 ntreinerea 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 interfaa 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 interacioneze cu toate celelalte componente ale acestuia,
asigurnd legtura i independena ntre elementele sistemului.
Un SGBD ofer utilizatorului posibilitatea de a accesa datele prin intermediul unui
limbaj de nivel nalt, apropiat de modul obinuit de exprimare, pentru a obine informaii,
utilizatorul fcnd abstracie 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
operaiilor ce se aplic asupra datelor din baza de date.

Faciliti oferite de un SGBD

Spre deosebire de un limbaj de programare obinuit, n care declararea datelor este
realizat n acelai 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 obinuit
datele exist efectiv numai pe parcursul rulrii 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 interacioneaz cu programele
aplicaie ale utilizatorului i cu baza de date. Printre principalele faciliti care sunt oferite de
un SGBD menionm:
1. permite utilizatorului s defineasc baza de date, de obicei prin intermediul unui limbaj de
definire a datelor (LDD), care permite fiecrui utilizator s specifice tipurile i structurile de
date, n timp ce constrngerile asupra datelor sunt memorate n baza de date;
2. ofer posibilitatea actualizrii datelor n baza de date (adugare, 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. Existena unui limbaj de interogare elimin dificultile sistemelor bazate pe
fiiere, unde utilizatorul este constrns s lucreze cu un set fix de interogri 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 funcie de operaiile 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
 nregistrri. n consecin, limbajele procedurale specific cum se va obine rezultatul unei
instruciuni LMD, iar cele neprocedurale descriu numai ce date vor fi obinute. Cel mai
obinuit tip de limbaj neprocedural este limbajul structurat de interogare (SQL - pronunat
Es-Q-L sau, uneori, Sii-Quel), care reprezint acum att limbajul standard, ct i cel de
facto pentru sistemele SGBD relaionale.
3. ofer accesul controlat la baza de date. De exemplu, poate furniza:
un sistem de securitate, care previne accesarea bazei de date de ctre
utilizatori neautorizai;
un sistem de integritate, care menine concordana datelor stocate;
un sistem de control al concurenei, 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 defeciuni la nivel hardware sau
software;
un catalog accesibil utilizatorilor, care conine descrieri ale datelor din baza de
date.
Datorit funcionalitilor pe care le ofer, SGBD-urile constituie instrumente extrem de
utile. Totui, deoarece pe utilizatori nu-i intereseaz ct de complex sau de uoar este
pentru sistem o anumit sarcin, s-ar putea argumenta c sistemul SGBD a fcut ca
lucrurile s devin mai complexe, deoarece acum se pot vedea mai multe date dect este
cu adevrat necesar sau dect se dorete. Ca o recunoatere a acestei probleme,
sistemul SGBD prezint o alt facilitate, cunoscut sub denumirea de mecanism de
vizualizare, care permite fiecrui 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 nct s
nu includ datele ce nu trebuie cunoscute de anumii utilizatori. De exemplu, s-ar putea
crea un mod de vizualizare care s permit unui administrator de filial i departamentului
Contabilitate s afieze toate datele referitoare la personalul unei instituii, inclusiv
detaliile despre salariu. Pe lng acesta, s-ar putea crea un al doilea mod de vizualizare,
care s exclud detaliile despre salariu, ce va fi utilizat de ctre ceilali angajai;
5. pot prezenta o imagine coerent, neschimbat a structurii bazei de date, chiar dac
aceasta este modificat (de exemplu, s-ar putea aduga sau elimina cmpuri, s-ar putea
modifica relaiile, diviza, restructura sau redenumi anumite fiiere). Dac sunt adugate
sau eliminate cmpuri dintr-un fiier, iar acestea nu sunt cerute de ctre modul de
vizualizare, el nu este afectat de ctre modificarea realizat. Prin urmare, modul de
vizualizare contribuie la asigurarea independenei program-date.

Componentele unui SGBD

Principalele componente ale unui SGBD sunt [Georgescu, Georgescu, 2005, p.75-81]:
motorul SGBD este componenta care asigur interfaa dintre subsistemul de proiectare
i cel de execuie 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 aciunile motorului SGBD sunt
realizate unitar i respect restriciile impuse de legturile dintre date, dar i de regulile de
integritate ale bazei de date definite n dicionarul de date. Principalele responsabiliti ale
motorului SGBD sunt:
realizeaz gestionarea tranzaciilor la nivelul unei baze de date;

12
 permite regsirea datelor pe baza informaiilor de adresare din fiierele de index;
salvarea i restaurarea datelor;
blocarea i deblocarea datelor n cazul operaiilor 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 aplicaiilor 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 interfeei cu utilizatorul, a rapoartelor,
meniurilor, etc.;
un sistem de asisten on-line pentru autodocumentarea utilizatorului.
subsistemul de execuie permite execuia aplicaiilor sau cererilor de consultare a bazei
de date, formulate prin utilizarea instrumentelor subsistemului de proiectare, prin
consultarea dicionarului de date i generarea tranzaciilor. Aceasta este componenta
care garanteaz autonomia logic a datelor n baza de date i are rolul de a intermedia
operaiile cu baza de date prin consultarea descrierii organizrii logice a datelor
memorate n structura bazei de date. Practic, fiecare operaie de actualizare sau
consultare a bazei de date se realizeaz prin identificarea formatelor de descriere a
datelor din dicionarul de date i conectarea acestor descrieri din schema intern a bazei
de date

Funciile 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 operaii
specifice. n funcie de natura lor, dar i de scopul urmrit, operaiile pot fi grupate pe
activiti. Activitile accept i ele o grupare pe funcii astfel nct, una sau mai multe
activiti, relativ omogene, vor realiza o funcie anume. innd cont de complexitatea unui
SGBD, de facilitile pe care le pune la dispoziie, de limbajele utilizate, precum i de modul
de implementare al modelului de date, gruparea activitilor pe funcii are un anumit caracter
relativ.
Plecnd de la modelul de date pe care l implementeaz, SGBD-urile se
caracterizeaz printr-un numr de particulariti identificate prin operaii i activiti specifice.
n pofida acestor particulariti, exist cteva funcii general valabile pentru toate tipurile de
SGBD; acestea sunt funcii importante, pe care un sistem software, dac nu le are n
totalitate, nu poate fi considerat SGBD. Astfel, principalele funcii 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 componenei bazei de date, a structurii acesteia , a relaiilor dintre
componentele ei, precum i a tuturor drepturilor de acces ale utilizatorilor la baza de date.
13
 Descrierea datelor
Prin intermediul funciei 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, legturile dintre entitile acesteia sau dintre atributele aceleiai entiti, se
definesc criteriile de validare a datelor (dac este cazul), metodele care asigur accesarea
datelor, precum i aspectele care se refer la asigurarea integritii datelor. Concretizarea
acestei funcii este schema bazei de date, memorat n cod intern. Memorarea se face ntr-
un fiier, ceea ce permite afiarea i actualizarea structurii bazei de date, n orice moment de
timp.
Aceast funcie a fost mult automatizat n timp, limbajul de descriere a datelor
beneficiind n prezent de puine comenzi. Acest limbaj este specific fiecrui 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 entitilor i a
caracteristicilor lor, definirea legturilor dintre obiectele identificate (asocierile) i a regulilor
de integritate specifice modelului de date.
Manipularea datelor
Funcia de manipulare a datelor este cea mai complex i realizeaz actualizarea i
regsirea datelor din baza de date, cu ajutorul limbajului de manipulare a datelor 5 .
Manipularea datelor este cea mai folosit funcie 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 alocrii
spaiului din memoria calculatorului.
Menionam n paragraful anterior c limbajul de manipulare a datelor este cel care
asigur realizarea acestei funcii. n ceea ce-l privete, acest limbaj trebuie s respecte
restriciile de integritate a datelor i s implementeze operatorii din modelul de date pe care
se bazeaz SGBD-ul cruia i aparine.
Aceast funcie presupune derularea urmtoarelor activiti:
ncrcarea datelor n baza de date - se realizeaz prin operaii automatizate sau
programate ce asigur i criteriile de validare necesare;
actualizarea bazei de date se refer la operaiile de adugare, modificare i tergere de
nregistrri. La operaiile de adugare i de modificare se pstreaz aceleai criterii de
validare care s-au folosit i la activitatea de ncrcare a datelor. Actualizarea se
realizeaz numai autorizat, prin asigurarea unei protecii corespunztoare a datelor,
pentru a se pstra coerena bazei de date.
prelucrarea datelor presupune realizarea operaiilor de selecie, ordonare, etc. efectuate
asupra entitilor bazei de date. Acestea sunt, de obicei, operaii pregtitoare activitii de
regsire a datelor. Multe din operaiile de prelucrare sunt realizate cu ajutorul operatorilor
din modelul de date pe care l implementeaz SGBD-ul.
regsirea (interogarea) datelor presupune realizarea operaiilor de vizualizare (afiare
pe ecran, imprimare pe hrtie), rsfoire, editarea unor documente de ieire (rapoarte).
Documentele de ieire pot fi intermediare sau finale i se pot obine pe diferii supori
tehnici de informaie (ecran, hrtie, mediu magnetic, mediu optic). Ele pot avea cele mai

5
n literatur ntlnim frecvent i Limbaj de Manevrare a Datelor
14
 diferite forme (punctuale, liste, rapoarte, grafice, imagini, sunet, video, etc) i se pot
obine dup cele mai diferite criterii de regsire.
Funcia de utilizare
Aceast funcie are rolul de a asigura interfeele necesare care s permit
comunicarea utilizatorilor cu baza de date (cu alte cuvinte, s asigure legtura dintre utilizator
i baza de date). Pentru realizarea acestei funcii, SGBD-ul trebuie s ofere faciliti pentru
mai multe categorii de utilizatori ai bazei de date, i anume: neinformaticieni, specialiti
(informaticieni) i administratorul.
Utilizatorii neinformaticieni reprezint principala categorie a beneficiarilor de informaii
(utilizatori finali i intensivi) din baza de date. SGBD-ul le ofer acestora limbaje
neprocedurale, dar i alte faciliti de interogare (generatoare, utilitare, etc.) a bazei de date
ntr-o form simpl i interactiv. Aceti 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 opiuni sugestive;
ferestre de lucru;
abloane pentru diferite forme;
asisteni tip Wizard;
autodocumentarea (help-uri, mesaje/ferestre explicative).
Spre deosebire de utilizatorii neinformaticieni, cei specialiti n informatic sunt n
msur 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 interfee cu limbaje universale. Acestea sunt de complexitate i putere
diferit, de la un SGBD la altul, oferind att elemente neprocedurale ct 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
Funcia de administrare este una destul de complex i din acest motiv se consider
c este doar de competena 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 ndeplinete 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 spaiul de memorie intern i extern (prin organizare, rutine de
optimizare);
de a realiza o serie de analize statistice din baza de date (numr i tip de utilizatori,
numr de accese, numr de actualizri, etc.).
Pentru fiecare din activitile menionate mai sus, SGBD-ul ofer instrumente i tehnici
de lucru.

15
 Abordarea relaional a bazelor de date
nainte de a prezenta principalele aspecte care caracterizeaz modelul relaional,
considerm c este oportun definirea conceptului de baz de date relaional. Dup o
ndelung analiz i sintez a definiiilor formulate de cercettorii consacrai ai domeniului,
dar i profesori de seama care au analizat aceast paradigm, putem afirma pe scurt c o
baz de date relaional reprezint colecii organizate de date i corelate din punct de vedere
logic. La o simpl analiz a definiiei, observm c ea impune dou direcii de studiu:
1. colecii organizate de date;
2. colecii corelate logic.
n acest context, pe parcursul capitolului, plecnd de la prezentarea aspectelor fundamentale
care caracterizeaz modelul relaional al bazelor de date, vom argumenta definiia prezentat
anterior i implicit cele dou direcii de studiu.
Atunci cnd lum n discuie abordarea relaional a bazelor de date, vom analiza n
principal trei direcii:
structura datelor are n vedere definirea domeniilor i a relaiilor corespunztoare
acestor domenii;
integritatea datelor se refer la definirea restriciilor de integritate care au rolul de a
proteja datele bazei de date; lipsa unor restricii de integritate ar putea avea ca efect
alterarea coninutului bazei de date i obinerea unor rezultate eronate;
prelucrarea datelor se realizeaz prin intermediul operaiilor specifice algebrei
relaionale sau calculului relaional.
Dup cum sugereaz i numele, modelul relaional se bazeaz pe noiunea de relaie
care este definit din punct de vedere matematic ca o submulime a produsului cartezian a
unei liste (finite) de mulimi, numite domenii. Fiecare element al unei relaii poart numele de
tuplu, iar numrul de domenii se numete aritate. ntr-o relaie, fiecare domeniu se identific
printr-un nume, numit atribut, iar mulimea numelor atributelor unei relaii formeaz schema
acesteia. Fie relaia din exemplul 4.1:

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

Astfel, n exemplul anterior am definit relaia Student care include atributele:
cnp definit pe domeniul cod numeric personal;
nr_matr definit pe domeniul numr_matricol;
nume definit pe domeniul nume;
pren definit pe domeniul prenume;
facult defint pe domeniul facultate;
spec definit pe domeniul specializare;
De asemenea, formulnd altfel, putem spune c n exemplul 4.1 am definit relaia
Student cu schema dat de atributele cnp, nr_matr, nume, pren, facult, spec. n exemplul 4.2
sunt prezentate trei tupluri pentru relaia 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 privete o relaie, ordinea de apariie a atributelor este absolut

nesemnificativ i acelai lucru l putem spune i despre tupluri.
Aa cum se observ, un tuplu se obine prin atribuirea de valori atributelor relaiei. n
ceea ce privete tuplurile unei relaii (care se mai numesc i realizri) trebuie spus c nu pot
exista dou sau mai multe tupluri identice. Altfel spus, toate tuplurile unei relaii trebuie s
difere cel puin 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 relaii, astfel nct nu pot exista dou tupluri diferite care s
aib valori identice pe domeniul unei chei. n cadrul abordrii relaionale exist patru tipuri de
chei care pot fi identificate:
candidat;
primar;
alternant (n funcie de sursa citat, ntlnim n litaratur i termenul de cheie
alternativ);
strin.
Dintre cele patru tipuri de chei, primele trei se analizeaz la nivelul unei singure relaii,
n timp ce cheia strin apare atunci cnd asociem dou sau mai multe relaii (este cea care
asigur practic legtura logic ntre diferite relaii).
Atunci cnd analizm o relaie, primul pas pe care l facem este acela al identificrii
cheilor candidat. Dintre cheile candidat identificate, se alege una ca fiind cheia primar a
relaiei respective, restul cheilor candidat devenind chei alternante. n general, vom alege ca
i cheie primar, acea cheie candidat care este format din numrul minim de atribute. n
cazul n care am identificat mai multe chei candidat i fiecare dintre ele au acelai numr de
atribute, atunci oricare din cheile candidat pot deveni cheie primar, alegerea fcndu-se n
funcie de opiunea i dorina proiectantului.
Dei pot exista mai multe chei candidat, este bine s reinem c fiecare relaie are o
singur cheie primar, care n anumite situaii poate fi format chiar din toate atributele ei.
Pentru a exemplifica tipurile de chei, abordate pn acum doar la nivel teoretic, vom
folosi relaia din exemplul 4.1. Aa cum aminteam anterior, iniial trebuie s identificm cheile
candidat ale relaiei Student. Cu alte cuvinte, trebuie s identificm acele atribute sau grupuri
de atribute pentru care nu pot exista valori duplicate, indiferent de numrul de tupluri ale
relaiei Student (iniial se analizeaz atributele n mod individual i apoi se fac combinaii 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 oricnd pot exista doi studeni cu acelai
nume. Acelai 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 nscrii mai muli studeni. n exemplul 4.3 am redat alte tupluri pentru
relaia 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 rmase, i anume cnp i nr_matr.
Cu siguran, c la ntrebarea Sunt atributele cnp i nr_matr chei candidat? am primi un
singur rspuns: DA. Aa s fie oare? Nu este aa. 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

Aa cum observm, pe domeniul aferent atributului cnp, avem dou valori identice:
este situaia n care o persoan este student la dou faculti diferite (i nu este singura
situaie posibil). Deci, nici atributul cnp nu poate fi cheie candidat. De ce am ajuns s facem
o astfel de greeal i s considerm c cnp poate fi cheie? Probabil c ne-am gndit la
faptul c nu pot existat dou persoane cu acelai CNP. Este adevrat: nu exist dou
persoane cu acelai CNP, ns schema relaiei Student nu conine doar atribute despre o
persoan, ceea ce nseamn c trebuia s ne gndim dac pentru un anume CNP putem
identifica cel puin o valoare a unui alt atribut care s se modifice fa de tuplul de la care am
plecat.
n ceea ce privete atributul nr_matr, putem spune c el este cheie candidat. Cum
artm asta? S plecm de la situaie din exemplul 4.5.
Exemplul 4.5
Student ( Cnp nr_matr nume pren facult spec )
1701212120139 1234 Popa Dan FSE IE
? 1234 ? ? ? ?
Astfel, considerm c avem un tuplu care reprezint un student cu numrul matricol
1234, care este la facultatea FSE, specializarea IE. Dac vom putea nlocui semnul ntrebrii
aferent unui atribut cu o valoare diferit de cea aflat pe cellalt tuplu (evident, pentru acelai
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 specializri diferite (n aceeai facultate sau n faculti diferite)
avnd aceeai 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, situaie care ar face ca
cele dou tupluri s fie identice i aa cum aminteam n prima parte, o astfel de situaie nu
este permis (acest aspect este reprezentat n exemplul 4.6). Deci, atributul nr_matr este
cheie candidat a relaiei 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 cutm i diferite combinaii 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 numrul minim de atribute care identific n mod unic tuplurile unei relaii). Dac
vom avea n vedere algoritmul descris anterior, vom mai identifica o cheie candidat:
cnp+facult+spec. De ce toate trei? Dac ne-am gndi la atributele cnp+facult am vedea c un
student ntr-o facultate, poate fi la mai multe specializri (spre exemplu, la forme diferite de
nvmnt) n timp ce pentru combinaia de atribute cnp+spec ar putea apare valori
duplicate n cazul n care mai multe faculti ar avea o aceeai specializare. ns, n situaia
n care le analizm pe toate trei am ajunge la concluzia c o persoan nu poate face aceeai
specializare de dou ori ntr-o facultate 6 .
Sintetiznd, pentru relaia 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 puine atribute dect 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, relaia noastr ar arta astfel:

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

Aa cum observm, atributul/atributele care formeaz cheia primar a relaiei vor

apare subliniate.
n mod normal, relaia de mai sus este una nenormalizat i este evident c ea
introduce redundan. Astfel, ar fi mai simplu dac datele referitoare la faculti, respectiv
specializri, le-am gestiona separat, n relaii de sine stttoare. n acest caz, redundana ar
fi n mare msur nlturat, iar procesul de identificare a cheilor ar fi mult simplificat. Astfel,
n exemplul 4.8 vom descompune relaia n alte trei relaii:

Exemplul 4.8
Student (cnp, nr_matr, nume, pren)
Facultate (facult, profil)
Specializare (spec, form_nv)
n relaia Facultate, atributul facult este cheie primar deoarece considerm c nu pot
exista dou faculti cu acelai nume n cadrul unei universiti. De asemenea, atributele
spec i form_nv formeaz cheia primar n relaia Specializare numai luate mpreun
deoarece o anumit specializare poate apare la diferite forme de nvmnt (spre exemplu,
specializarea Contabilitate i Informatic de Gestiune are studeni i la forma de nvmnt
Zi, i la Ifr).

6
Mecanismul de identificare corect i complet a cheilor unei relaii se va realiza numai dup parcurgerea i nelegerea
procesului de normalizare a unei baze de date relaionale.
19
 Astfel, prin descompunerea relaiei iniiale n cele trei relaii din exemplul 4.8 am
argumentat prima parte a definiiei bazei de date relaionale. Aa cum observm, n acest
moment structura noastr este format din trei colecii organizate n care:
Student conine doar date de strudeni;
Facultate include ca realizri (tupluri) doar facultile gestionate;
Specializare care se refer la specializrile fiecrei faculti gestionate.

Legturi ntre relaii

Dac analizm cu atenie relaiile din exemplul 4.8 observm c redundana datelor a
fost nlturat, n sensul c aceleai date nu le mai gestionm de mai multe ori n cadrul unei
relaii, aa cum se ntmpla n exemplul 4.7, unde numele unei faculti ar fi aprut de fiecare
dat cnd mai gestionam un student al aceleai facultai (realizarea FSE, ca valoare a
atributului facult ar fi aprut de fiecare dat cnd am fi avut un student al acestei faculti).
ns, n acelai timp, n exemplul 4.7 erau disponibile informaii complete despre student
(nume, prenume, facultatea la care studiaz, specializarea la care este nmatriculat). Odat
cu descompunerea n mai multe relaii, observm c aceste informaii nu le mai avem: exist
trei relaii n care avem date personale despre studeni (relaia Student), date despre faculti
(relaia Facultate), respectiv date despre specializri (relaia Specializare), fr ns s
putem spune la ce facultate sau specializare este un anume student.
n acest context, pentru a putea oferi aceste informaii, trebuie s asociem relaiile
modelului din exemplul 4.8. Astfel, abordarea relaional propune patru tipuri de legturi ntre
relaii.

Legtura binar 1-1 (unu la unu)

Definiie. Atunci cnd asociem dou relaii fiu, legtura dintre ele se realizeaz prin
migrarea cheilor primare din fiecare relaie, sub forma cheii strine n relaiile
corespunztoare.
Obs. n cadrul unei asocieri binare, fiecare dintre cele dou relaii poate fi att relaie fiu, ct
i relaie printe.
Definiie. Spunem despre o relaie c este fiu atunci cnd unui tuplu din relaia
respectiv i corespunde un singur tuplu n relaia cu care s-a asociat.
Definiie. O relaie este considerat printe atunci cnd unui tuplu din relaia respectiv
i pot corespunde mai multe tupluri n relaia cu care s-a asociat.
Definiie. Cheia strin reprezint un atribut (sau un grup de atribute) care
ndeplinete rolul de cheie primar n cadrul relaiei din care a migrat. Practic, cheia strin
este cea care permite crearea legturilor logice dintre relaii. Ca valori ale atributelor care
formeaz cheia strin putem avea fie valori care se regsesc pe domeniul cheii primare n
relaia din care provine cheia strin, fie valoarea NULL (n literatura de specialitate, aceast
constrngere este numit restricie referenial).

Exemplul 4.9: Fie urmtoarele dou relaii:

Client ( cnp nume pren localitate )
1701212120139 Popa Dan Galai
2711010120121 Darie Alina Brila
1721209145123 Preda Marin Galai

20
 Legitimaie ( nr_leg valabilitate )
12121 2
23456 2
187654 3

Prin intermediul relaiilor Client i Legitimaie ncercm s modelm situaia accesului

ntr-un supermarket pe baza unei legitimaii. Pentru a realiza legtura dintre relaiile asociate,
va trebui s identificm mai nti tipul relaiilor (fiu sau printe). Astfel, pe baza definiiilor
prezentate anterior, observm c ambele relaii sunt fiu deoarece fiecare client, la un
moment dat, nu poate avea dect o singur legitimaie care s-i permit accesul n
supermarket. Cu alte cuvinte, pentru exemplul 4.9, Popa Dan nu poate avea dect o singur
legitimaie, ceea ce nseamn c unui tuplu din relaia Client nu-i poate corespunde dect un
singur tuplu n relaia Legitimaie. Analiznd n acelai mod, este evident c o legitimaie nu
poate corespunde mai multor clieni.
Astfel, deoarece ambele relaii sunt fiu, tipul de legtur dintre cele dou este 1-1.
Conform definiiei enunate, atributul cnp va migra din relaia Client (unde este cheie primar)
n relaia Legitimaie, unde va ndeplini rolul de cheie strin. n acelai mod, atributul nr_leg
va migra din relaia Legitimaie n relaia Client, iar modelul va arta ca n exemplul 4.10.
Exemplul 4.10:
Client ( cnp nume pren localitate nr_leg )
1701212120139 Popa Dan Galai 23456
2711010120121 Darie Alina Brila 12121
1721209145123 Preda Marin Galai 187654

Legitimaie ( nr_leg valabilitate cnp )

12121 2 2711010120121
23456 2 1701212120139
187654 3 1721209145123

Dup migrarea cheii primare sub forma cheii strine, putem spune c am realizat
legtura ntre relaiile asociate, astfel nct s putem spune despre un client ce numr de
legitimaie are, sau plecnd de la numrul legitimaiei, s putem identifica fr ambiguitate
care este deintorul acesteia.

Legtura binar 1-n (unu la mai muli)

Definiie. Atunci cnd asociem dou relaii, dintre care una este relaie fiu, iar cealalt
este printe, legtura dintre ele se realizeaz prin migrarea cheii primare din relaia printe,
sub forma cheii strine n relaiile fiu.
Pentru exemplificare, vom pleca de la relaiile 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 apartenenei unui student la o specializare, va trebui
s realizm legtura dintre cele dou relaii. Ca i n cazul primului tip de legtur, i de
aceast dat vom pleca de la identificarea tipurilor de relaii, rspunznd pe rnd la
ntrebarea: Unui tuplu din relaia X cte tupluri n relaia Y i pot corespunde, unde X i Y
sunt cele dou relaii pe care le asociem.
a. Identificarea tipului pentru relaia Student: ntrebarea la care trebuie s rspundem este:
Un student la cte specializri poate fi?. La aceast ntrebare, o parte din cititori ar
putea spune c un student poate fi la una sau mai multe specializri, n timp ce alii
consider c un student nu poate fi dect la o singur specializare. Rspunsul corect este
cel de-al doilea deoarece un student, care are asociat o anumit matricol, nu poate fi la
mai multe specializri. Este clar c o persoan, cu un anume cod numeric personal,
poate fi la mai multe specializri, caz n care numrul matricol este altul. Altfel spus,
studentul Popa Dan cu matricola 1111 nu poate aparine dect unei singure specializri.
Concluzionnd vom afirma despre Student c este relaie fiu.
b. Identificarea tipului pentru relaia Specializare n acest caz, rspunsul la ntrebarea: La
o specializare ci studeni pot fi nmatriculai? este mai muli, ceea ce nseamn c
unui tuplu din relaia Specializare i corespund mai multe tupluri din relaia Student. n
acest caz, Specializare este relaie printe.
Plecnd de la analiza fcut anterior, am stabilit c relaia Student este fiu n timp ce
relaia Specializare este printe: legtura dintre cele dou se va realiza prin migrarea cheii
primare din relaia printe (cod_spec din Specializare) sub form de cheie strin n relaia
Student, iar modelul va arta 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 observm c, dup crearea legturii, suntem n msur s

identificm specializarea la care este nmatriculat fiecare student. Astfel, atunci cnd vom
dori s aflm care este specializarea i forma de nvmnt a studentului Preda Marin, se va
realiza o interogare a datelor din relaia Specializare i se va identifica acel tuplu care are ca
valoare a atributului cod_spec, valoarea aferent cheii strine din relaia Student, adic 61.
Dup parcurgerea secvenial a tuplurilor din Specializare vom vedea c studentul este la
specializarea CIG, forma de nvmnt ZI.

Legtura binar n-n (mai muli la mai muli)

Definiie. Atunci cnd asociem dou relaii printe, legtura dintre ele se realizeaz
prin generarea unei noi relaii care va avea ca i cheie primar, cheile primare ale relaiilor
asociate. Aceast nou relaie poate include i alte atribute (n afara celor care formeaz
cheia primar) care reies din contextul problemei modelate.
Fie relaiile 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

Considerm c relaia Factur permite gestionarea facturilor primite de un comerciant,

n timp ce n relaia Produs sunt gestionate produsele comercializate. Odat ce am
considerat atributul cod_produs ca fiind cheia primar a relaiei Produs vom presupune c nu
vor exista dou produse care s aib acelai cod, garantndu-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 gsete la un moment dat n
stocul comerciantului.
Plecnd de la cele dou relaii, dorim s punem n eviden care este coninutul
fiecrei facturi (produsele i cantitile coninute de fiecare factur). Iniial, vom identifica tipul
relaiilor pentru a putea realiza legtura dintre ele. Astfel, relaia Factur este printe
deoarece considerm c o factur poate conine unul sau mai multe produse. Totodat, si
relaia Produs este tot printe deoarece un produs poate fi achiziionat prin intermediul mai
multor facturi. Deci, ambele relaii sunt de tipul printe; asta nseamn c se va crea o nou
relaie, care va avea cheia primar format din cheile primare ale celor dou relaii 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

Aa cum se observ, legtura de tipul mai muli la mai muli a fost pus n eviden
prin noua relaie generat: Aprovizionare. n cadrul acesteia, pe primele dou tupluri am pus
n eviden faptul c o factur (DX 1111) poate conine mai multe produse (conine produsele
cu codul 11 i 33) n timp ce un produs (cel cu codul 11) poate fi achiziionat prin intermediul
mai multor facturi (se gsete att pe factura DX 1111 ct i pe DF 3333).
n cadrul relaiei Aprovizionare observm un nou atribut, care nu se regsea la nivelul
relaiilor pe care le-am asociat. Acest atribut apare n cadrul acestei noi relaii deoarece o
realizare a acestuia are loc numai atunci cnd asociem cte un tuplu din fiecare relaie (nu
putem avea o cantitate aprovizionat dac exist produsul, dar nu exist factura i, n acelai
timp, nici dac exist factura i nu exist produsul).

Legtura dintre trei sau mai multe relaii

Atunci cnd asociem mai mult de dou relaii, legtura dintre ele se realizeaz prin
definirea unei noi relaii, care va avea cheia primar format din cheile primare ale tuturor
relaiilor, mpreun cu alte atribute care reies din contextul problemei modelate. Practic, este
un caz particular al legturii binare mai muli la mai muli, fr ns s mai necesite n
prealabil identificarea tipului fiecrei relaii.

23
 Revenind la exemplul 4.8, vom asocia cele trei relaii 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 Ctlin

Facultate ( facult profil )

tiine Economice Economic
Drept Administrativ

Specializare ( cod_spec Spec form_nv

751 FB ZI
752 FB IFR
662 AP IFR

n urma asocierii celor trei relaii, se va genera o nou relaie care se va identifica prin
intermediul atributelor nr_matr, facult i cod_spec, aa cum se observ n exemplul 4.16.
Exemplul 4.16
Studiu ( nr_matr facult cod_spec )
111 tiine Economice 751
222 Drept 662
333 tiine Economice 751

Cu ajutorul acestei noi relaii, putem spune despre Preda Marin c este student la
facultatea de tiine Economice, la specializarea FB, forma de nvmnt IFR.
Abia n acest moment putem spune c am argumentat pe deplin definiia bazei de
date relaionale: am creat diferite colecii de date organizate, dup care am stabilit legturile
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 acelai
timp toate datele gestionate n baza de date.

Algebra relaional operatorii relaionali

Algebra relaional se refer la diferii operatori care au ca operanzi relaiile, fiind
conceput de cercettorul E.F. Codd. n funcie de aritatea operatorului, rezultatul aplicrii
acestuia la una sau la dou relaii va fi tot o relaie. n prezentarea operaiilor, vom pleca de
la presupunerea c fiecare relaie are un numr finit de tupluri distincte i sunt descrise prin
intermediul unei mulimi finite de atribute.
Aceste operaii specifice algebrei relaionale sunt folosite pentru formalizarea
limbajului de cereri al sistemului de gestiune al bazelor de date relaionale. Ele sunt
implementate n funciile 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 relaionale se pot exprima prin cinci operaii asupra relaiilor,
ntlnite n literatur sub numele de operaii de baz, i anume: reuniunea, diferena,

24
produsul cartezian, proiecia i selecia. Dintre aceste cinci operaii, primele trei presupun
existena a dou relaii n timp ce urmtoarele se aplic pentru o singur relaie.
1. Reuniunea. Reuniunea a dou relaii A i B 7 , notat A B , este o relaie care va avea
schema identic cu a relaiilor reunite i care va include ca tupluri, toate tuplurile celor dou
relaii, considerate o singur dat.
Exemplul 4.17
Stud1 ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Ctlin

Stud2 ( nr_matr nume pren )

444 Manea Oana
333 Ionescu Ctlin
555 Dragomir Alina

Stud1 Stud2 = ( nr_matr Nume pren )

111 Preda Marin
222 Darie Alina
333 Ionescu Ctlin
444 Manea Oana
555 Dragomir Alina

2. Diferena. Diferena a dou relaii A i B 8 , notat A \ B , este o relaie care va avea schema
identic cu a relaiilor iniiale i ca realizri toate tuplurile primei relaii care nu se regsesc n
cea de-a doua relaie.
Astfel, dac realizm diferena relaiilor Stud1 i Stud2 din exemplul 4.17, rezultatul
este urmtorul:
Stud1\ Stud2 = ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
3. Produsul cartezian. Fie relaiile A (cu aritatea a) i B (cu aritatea b) 9 . Produsul cartezian
al celor dou relaii, notat A B este o relaie care are aritatea a+b i care va conine toate
tuplurile rezultate prin concatenarea unui tuplu din A cu fiecare tuplu din B. Trebuie menionat
faptul c atunci cnd schemele celor dou relaii includ i atribute comune, atunci n schema
produsului cartezian, cele dou atribute vor apare de dou ori, ns cu nume diferite (o relaie
nu poate avea dou atribute cu acelai nume).
Exemplul 4.18
Student ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Ctlin

7
Relaiile A i B trebuie s aib aceeai schem definit pe aceleai domenii.
8
Relaiile A i B trebuie s aib aceeai schem definit pe aceleai domenii.
9
Schemele relaiilor 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
Aa cum se observ, aritatea ambelor relaii este 3, ceea ce nseamn c dup
realizarea produsului cartezian asupra celor dou relaii, aritatea va fi 6 (relaia rezultat n
urma operaiei Student Disciplin va avea ase atribute), aa 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 Ctlin SE1 Informatic curs
333 Ionescu Ctlin SE2 Informatic laborator
333 Ionescu Ctlin SE3 Contabilitate seminar

4. Proiecia. Proiecia se aplic unei singure relaii A de aritate a, se noteaz cu i se

realizeaz dup un numr de atribute, a1, a2, , an, care trebuie s fie incluse n schema
relaiei A. Noua relaie va avea schema dat de atributele dup care se realizeaz proiecia,
Totodat, relaia obinut dup realizarea proieciei va avea acelai numr de tupluri ca
relaia iniial.
Exemplul 4.19 Fie relaia Student:
Student ( nr_matr cnp nume pren )
1111 1701212120139 Popa Dan
2222 2711010120121 Darie Alina
3333 1721209145123 Preda Marin
Plecnd de la aceast relaie, dorim s realizm proiecia dup atributele nr_matr,
nume i pren. Astfel, vom obine urmtoarea relaie:

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

1111 Popa Dan
2222 Darie Alina
3333 Preda Marin

5. Selecia. Selecia se definete pentru o singur relaie A de aritate a, se noteaz cu i

se realizeaz pe baza unei condiii logice. Noua relaie va avea aceeai schem ca relaia
iniial i va conine doar acele tupluri care respect condiia dup care se realizeaz selecia.
Exemplul 4.20 Fie relaia Student:
Student ( nr_matr nume pren media )
1111 Popa Dan 7.00
2222 Darie Alina 8.00
3333 Preda Marin 9.00

26
 Plecnd de la relaia de mai sus, dac dorim s realizm o selecie a studenilor cu
media mai mare sau egal cu opt, vom ajunge la urmtoare relaie:

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

2222 Darie Alina 8.00
3333 Preda Marin 9.00

Pe lng operaiile amintite anterior, se mai pot utiliza i alte operaii, numite operaii
derivate i care se bazeaz pe operaiile de baz. Utilizarea n practic a operaiilor derivate
ofer o flexibilitate sporit a cererilor de interogare a bazei de date i faciliteaz, n cele mai
multe situaii, obinerea unor rspunsuri mai rapide. Dintre operaiile derivate utilizate mai
frecvent amintim:
6. Intersecia. Intersecia a dou relaii A i B 10 , notat A B , este o relaie care va avea
schema identic cu a relaiilor intersectate, iar ca realizri doar tuplurile comune celor dou
relaii.
Exemplul 4.21
Stud1 ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Ctlin

Stud2 ( nr_matr nume pren )

444 Manea Oana
333 Ionescu Ctlin
555 Dragomir Alina

Stud1 Stud2 = ( nr_matr nume pren )

333 Ionescu Ctlin
7. Uniunea. Uniunea se definete pentru dou relaii A i B (de aritate a, respectiv b), o
condiie logic ntre dou valori ale unor atribute ce aparin celor dou relaii 11 i se noteaz
A | X | B . Rezultatul uniunii va fi o relaie de aritate a+b, cu schema dat de reuniunea
c
atributelor celor dou relaii i care va conine toate tuplurile aferente produsului cartezian
dintre A i B care respect condiia menionat. Cu alte cuvinte, uniunea a dou relaii se
realizeaz n doi pai:
a. realizarea produsului cartezian dintre relaii;
b. selecia tuplurilor conform condiiei logice.
n cazul n care condiia c este de egalitate, atunci operaia se numete echiuniune. n
plus, dac vom realiza o proiecie dup atributele primei operaii, operaia se numete semi-
uniune-stnga, iar dac se face dup atributele relaiei din dreapta (a doua relaie) se va
numi semi-uniune-dreapta. n continuare vom exemplifica uniunea i echiuniunea.

10
Relaiile A i B trebuie s aib aceeai schem definit pe aceleai domenii.
11
n cazul uniunii, cele dou atribute trebuie s fie cte unul din fiecare relaie.
27
Exemplul 4.22 Fie urmtoarele relaii:
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 relaiei Aprov se presupune c avem situaia aprovizionrilor, n relaia
Comand avem o eviden a produselor comandate, iar semantica atributelor este
urmtoarea:
s_fact reprezint seria unei facturi;
nr_fact reprezint numrul facturii;
cod_prod codul produsului achiziionat prin intermediul unei facturi;
cant_a se refer la cantitatea aferent unui produs care se gsete 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 relaii, aminteam anterior c primul pas care
trebuie fcut 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 selecia tuplurilor pe baza condiiei
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 condiia este cant_a=cant_c, atunci vom avea o echiuniune a celor
dou relaii, aa cum se observ n exemplul 4.23:

28
Exemplul 4.23: Echiuniunea relaiilor 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 relaiilor A i B, notat | A X B | se poate realiza

numai n cazul n care cele dou relaii au un set de atribute comune. Astfel, uniunea
natural se obine prin selectarea din produsul cartezian al celor dou relaii a tuplurilor ce
conin valori comune pentru atributele cu acelai nume. Schema relaiei va fi dat de
reuniunea atributelor celor dou relaii (ceea ce nseamn c atributele comune vor apare o
singur dat).
Exemplul 4.23: Fie urmtoarele relaii:
Student ( nr_matr nume pren )
111 Popa Dan
222 Darie Alin
333 Moga Dana

Disc ( den_disc nr_matr not )

Finane 333 9
Birotic 222 10
Birotic 333 8
a. Se realizeaz produsul cartezian al celor dou relaii:
Student X Disc = ( s.nr_matr nume pren den_disc d.nr_matr not )
111 Popa Dan Finane 333 9
111 Popa Dan Birotic 222 10
111 Popa Dan Birotic 333 8
222 Darie Alin Finane 333 9
222 Darie Alin Birotic 222 10
222 Darie Alin Birotic 333 8
333 Moga Dana Finane 333 9
333 Moga Dana Birotic 222 10
333 Moga Dana Birotic 333 8
b. La acest pas va trebui s determinm condiia dup care se va realiza selecia. Aa cum
observm, atributul comun celor dou relaii este nr_matr, ceea ce nseamn c uniunea
natural se va face pe baza condiiei Student.nr_matr = Disc.nr_matr.
c. Dup identificarea condiiei, 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 Finane 333 9
333 Moga Dana Birotic 333 8
d. n final, se realizeaz o proiecie asupra relaiei obinute la punctul c dup mulimea
atributelor celor dou relaii, considerate o singur dat. Dup realizarea proieciei, vom
obine:

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

9. Uniunea extern. Uniunea extern (outer join) va include toate tuplurile uniunii naturale, la
care se adaug cte un tuplu pentru acele tupluri dintr-o relaie care nu au corespondent n
cealalt relaie. Tuplurile adugate au valoarea NULL pentru toate atributele ce nu apar n
relaia din care provin. Uniunea extern se noteaz astfel: A | | B, unde A i B sunt cele
dou relaii.
Plecnd de la relaiile Student i Disc din exemplul 4.23 i de la uniunea natural
Student | X | Disc, vom avea urmtoarea 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 Finane 9
333 Moga Dana Birotic 8
Aa cum se observ, n relaia Student exist un singur tuplu care nu are
corespondent n relaia Disc: n acest caz, tuplul va fi adugat n relaia aferent uniunii
externe, iar valorile aferente atributelor din relaia Disc pentru care nu exist corespondent
vor primi valoarea NULL. n ceea ce privete relaia Disc, nu exist nici un tuplu care s nu
aib corespondent n relaia Student (altfel spus, valorile 222 i 333, ca realizri ale
atributului nr_matr n relaia Disc, se regsesc n relaia Student pe domeniul de valori al
atributului nr_matr).
De asemenea, exist dou operaii derivate din uniunea extern i anume uniune
extern stnga (left outer join) i uniune extern dreapta (right outer join). n ceea ce privete
uniunea extern stnga, relaia va conine toate tuplurile uniunii naturale la care se vor
aduga cele ale primei relaii (considerat relaia din stnga) care nu au corespondent n
relaia din dreapta. n dreptul acestor valori se va trece valoarea NULL (exemplul 2.25). n
mod similar se realizeaz uniunea extern stnga, numai c n acest caz vor fi adugate
uniunii naturale doar tuplurile relaiei 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 Finane 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 Finane 9
333 Moga Dana Birotic 8

30
 Bibliografie

1. [Bsc, 1997] Bsc, O., Baze de date, Editura All, Bucureti, 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, ediia 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.
Implementri SQL i Oracle, Editura Polirom, Iai, 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 relaionale
i multidimensionale, Editura Didactic i Pedagogic R.A., Bucureti, 2005.
9. [Lungu, Bodea, 1995] Lungu, I., Bodea, C., Baze de date organizare, proiectare i
implementare, Editura All, Bucureti, 1995.
10. [Popa et al., 1994] Popa, Ghe., Stanciu, A., Ivancenco, V., Mare, V., SGBD, Editura All,
Bucureti, 1994.
11. [Popescu, 2001] Popescu, I., Modelarea bazelor de date, Editura Tehnic, Bucureti,
2001.
12. [Trandafir et al., 2007] Trandafir, R., Nistorescu, M., Mierlu-Mazilu, I., Baze de date
relaionale, Bucureti, 2007.
13. [Velicanu et al., 2000] Velicanu, M., Bodea, C., Lungu, I., Ioni, I., Bdescu, G., Sisteme
de gestiune a bazelor de date, Editura Petrion, Bucureti, 2000.
14. [Velicanu et al., 2003] Velicanu, M., Lungu, I., Muntean, M., Ionescu, S., Sisteme de baze
de date teorie i practic, Editura Petrion, Bucureti, 2003.
15. http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_2.pdf.

31