Sunteți pe pagina 1din 30

BAZE DE DATE

Fundamente ale bazelor de date

Tehnologiile informa ionale influen eaz continuu i produc modificri substan iale
asupra mijloacelor de lucru din ntreaga lume. Informa ii 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 informa iilor 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 vie ile noastre.
Pn n urm cu c iva ani, sistemele mari de baze de date se gseau numai pe
calculatoare de tip mainframe. ns, aa cum era i firesc, proiectarea, achizi ionarea sau
ntre inerea unei astfel de maini reprezenta o sarcin costisitoare i dificil de realizat. Odat
cu apari ia calculatoarelor din clasa sta iilor 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 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 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 informa ionale moderne. Acest aspect a provocat un impact adnc precum i
modificri semnificative n modul de lucru al institu iilor i organiza iilor, 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 men ionm 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 gndire orientat obiect, apari ia procesrii de tipul client-
server, diminuarea semnificativ a pre urilor aferente att componentei hardware ct i a
celei software i, nu n ultimul rnd, necesitatea unei administrri eficiente i corecte a
cantit ilor tot mai mari de informa ii care caracterizeaz activit ile fiecrei organiza ii din
zilele noastre.
n prezent, bazele de date fac parte tot mai mult din via a 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 achizi ionm. 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 ctre un furnizor, pentru a ob ine 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 tenta i s credem c a fost aleas cea
mai bun solu ie, att timp ct necesit ile informa ionale sunt satisfcute, este adevrat, n
contextul unei cantit i reduse de informa ii. n timp ns, acest volum crete (spre exemplu,

3
odat cu creterea 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 msur 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 cutare, regsire 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
trstura definitorie care caracterizeaz activit ile fiecrei organiza ii sau institu ii, indiferent
de domeniul su de activitate. Volumul tot mai nsemnat de informa ii nu mai poate fi utilizat
eficient cu ajutorul mijloacelor tradi ionale. 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 defini ii 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 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
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 informa ii redundante. De
asemenea, este permis accesul simultan la aceleai date, care se regsesc n acelai loc
sau sunt distribuite spa ial, a mai multor persoane de pregtiri diferite, fiecare cu stilul
personal de lucru [Bsc, 1997, p.11].
Referitor la defini ia prezentat anterior, putem spune c avem unele re ineri n ceea
ce privete utilizarea conceptului de informa ie. Astfel, autorul vede baza de date ca un
ansamblu de informa ii, prere pe care o mprtim 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 cnd 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
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 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), aa cum reiese i
din arhitectura pe niveluri a unui sistem de baze de date;
coerent, conform restric iilor 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 mul i utilizatori, concomitent, pot
ob ine informa iile dorite atunci cnd 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 fiiere care
grupeaz datele prelucrate n aplica iile informatice ale unei persoane, grup de persoane,
ntreprinderi, institu ii, etc. Din punct de vedere formal, definete 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].
Plecnd de la defini iile prezentate anterior, putem afirma c o baz de date
rela ional reprezint o colecie partajat de date, ntre care exist diferite legturi logice
(mpreun cu o descriere a acestora), proiectat pentru a satisface necesit ile
informa ionale ale fiecrei organiza ii. Totodat, putem privi o baz de date ca un instrument
pentru organizarea i colectarea tuturor informa iilor, astfel nct s se satisfac toate
necesit ile informa ionale ale utilizatorilor ei.
Defini ia prezentat anterior trebuie analizat n detaliu pentru a putea fi n msur s
dobndim 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 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 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, ntlnite n
literatur sub denumirea de metadate (date despre date).
Atunci cnd analizm 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 nregistrm, iar relaia 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 (legturile) logice dintre ele. n capitolul 4 vom arta cum se
concretizeaz din punct de vedere practic legturile logice dintre rela ii, 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 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 legturilor 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.);
fiierele anexe, aa cum sunt cele de index.

5
b. software-ul este aferent realizrii i exploatrii 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. 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 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 az 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 men iona urmtoarele aspecte:
administratorul realizeaz structura conceptual a bazei de date, eventual cu ajutorul
instrumentelor oferite de un SGBD;
structura conceptual se ob ine 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 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
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 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 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 informa ie;
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 evolu ia n timp a dezvoltrii
sistemelor software constatm 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 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 aplica ii necesitau i o ntre inere
constant, care urmrea n primul rnd corectarea erorilor detectate, mbunt 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
nct, 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 ntrziat s apar: multe proiecte importante se aflau n
ntrziere, bugetul alocat lor devenea constant insuficient, ntre inerea se face tot mai greu,
iar performan ele ntrziau 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 proiectrii n componente uor de manevrat. Astfel, ca o solu ie care s permit
ieirea 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 informaionale.

Ciclul de via al sistemelor informaionale


Putem privi sistemul informaional ca un ansamblu de fluxuri i circuite informa ionale,
organizate ntr-o concep ie unitar i care asigur legtura dintre sistemul decizional (de
conducere) i cel opera ional (de execu ie).
Trebuie men ionat faptul c nu trebuie s confundm sistemul informa ioanal 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 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 fundamentrii deciziilor. n
plus, sistemul informatic este inclus n cel informa ional i i ofer acestuia noi valen e, 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 informa ionale din cadrul unei organiza ii. n
acelai timp, a avut loc o recunoatere 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, considerm 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 proiectrii bazei de date, se poate reveni la etapa
anterioar care are drept obiectiv colectarea i analiza cerin elor.
Principalele activit i asociate fiecrei 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 granielor sistemului se refer la specificarea scopului i limitelor aplica iei, a
utilizatorilor si 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 pr 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 cerinelor 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 identificrii cerin elor 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 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 fcut n orice moment
anterior proiectrii logice, cu condi ia s fie disponibile suficiente informa ii
referitoare la cerin ele sistemului, cum ar fi performan a sau constrngerile 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 aflm 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), corespunztor
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 ctre 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, 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 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 urmrete implementarea efectiv a bazei de date pe suportul de stocare, inclusiv
acele aspecte care in de asigurarea i garantarea securit ii datelor.
Proiectarea corespunztoare bazei de date este o etap foarte important, mai ales c
trebuie s fie capabil s garanteze buna func ionare a acesteia i a oricrei aplica ii care o
utilizeaz. n lipsa unei proiectri 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 interogri 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,
asigurnd legtura 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 obinuit de exprimare, pentru a ob ine informa ii,
utilizatorul fcnd 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.

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 interac ioneaz cu programele
aplica ie ale utilizatorului i cu baza de date. Printre principalele facilit i care sunt oferite de
un SGBD men ionm:
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. Existen a unui limbaj de interogare elimin dificult ile 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 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
nregistrri. 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
obinuit tip de limbaj neprocedural este limbajul structurat de interogare (SQL - pronun at
Es-Q-L sau, uneori, Sii-Quel), care reprezint acum att limbajul standard, ct 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 ctre
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. 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 anumi i 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 institu ii, 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 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 aduga sau elimina cmpuri, s-ar putea
modifica rela iile, 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 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 legturile 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 regsirea datelor pe baza informa iilor de adresare din fiierele 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 execuie 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 organizrii 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

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 opera ii
specifice. n func ie de natura lor, dar i de scopul urmrit, opera iile pot fi grupate pe
activit i. Activit ile accept i ele o grupare pe func ii astfel nct, una sau mai multe
activit i, relativ omogene, vor realiza o func ie anume. innd 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.
Plecnd de la modelul de date pe care l implementeaz, SGBD-urile se
caracterizeaz printr-un numr de particularit i identificate prin opera ii i activit i specifice.
n pofida acestor particularit i, exist cteva 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 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 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, legturile dintre entit ile acesteia sau dintre atributele aceleiai 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 fiier, ceea ce permite afiarea 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 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 entit ilor i a
caracteristicilor lor, definirea legturilor 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
regsirea 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 alocrii
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 privete, 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 cruia i apar ine.
Aceast func ie presupune derularea urmtoarelor activit i:
ncrcarea 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 adugare, modificare i tergere de
nregistrri. La opera iile 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 protec ii corespunztoare a datelor,
pentru a se pstra 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 pregtitoare activit ii de
regsire a datelor. Multe din opera iile de prelucrare sunt realizate cu ajutorul operatorilor
din modelul de date pe care l implementeaz SGBD-ul.
regsirea (interogarea) datelor presupune realizarea opera iilor 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 ob ine pe diferi i supor i
tehnici de informa ie (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
ob ine dup cele mai diferite criterii de regsire.
Funcia 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 legtura 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, specialiti
(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. 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 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 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 interfe e 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
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 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 spa iul 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 activit ile men ionate 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 rela ional,
considerm c este oportun definirea conceptului de baz de date rela ional. Dup o
ndelung analiz i sintez a defini iilor formulate de cercettorii 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 colecii organizate de date i corelate din punct de vedere
logic. La o simpl analiz a defini iei, observm c ea impune dou direc ii 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 rela ional al bazelor de date, vom argumenta defini ia prezentat
anterior i implicit cele dou direc ii de studiu.
Atunci cnd lum 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 corespunztoare
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 numrul de domenii se numete 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 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 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 privete o rela ie, ordinea de apari ie a atributelor este absolut


nesemnificativ i acelai lucru l putem spune i despre tupluri.
Aa cum se observ, un tuplu se ob ine prin atribuirea de valori atributelor rela iei. n
ceea ce privete tuplurile unei rela ii (care se mai numesc i realizri) 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 nct nu pot exista dou tupluri diferite care s
aib valori identice pe domeniul unei chei. n cadrul abordrii rela ionale exist patru tipuri de
chei care pot fi identificate:
candidat;
primar;
alternant (n func ie 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 rela ii,
n timp ce cheia strin apare atunci cnd asociem dou sau mai multe rela ii (este cea care
asigur practic legtura logic ntre diferite rela ii).
Atunci cnd analizm o rela ie, primul pas pe care l facem este acela al identificrii
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 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
func ie de op iunea i dorin a proiectantului.
Dei pot exista mai multe chei candidat, este bine s re inem c fiecare relaie 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 pn acum doar la nivel teoretic, vom
folosi rela ia din exemplul 4.1. Aa cum aminteam anterior, ini ial trebuie s identificm cheile
candidat ale rela iei 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
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 oricnd pot exista doi studen i 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 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 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 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 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 rela iei Student nu con ine doar atribute despre o
persoan, ceea ce nseamn c trebuia s ne gndim 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 privete atributul nr_matr, putem spune c el este cheie candidat. Cum
artm asta? S plecm 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, 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 facult i 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, situa ie care ar face ca
cele dou tupluri s fie identice i aa 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 cutm 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 numrul 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 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
nv mnt) 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 aceeai specializare. ns, n situa ia
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 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 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, rela ia 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 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
specializri, le-am gestiona separat, n rela ii de sine stttoare. n acest caz, redundan a ar
fi n mare msur nlturat, 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 considerm c nu pot
exista dou facult i cu acelai 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 mnt (spre exemplu,
specializarea Contabilitate i Informatic de Gestiune are studen i i la forma de nv mnt
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 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. Aa cum observm, 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 realizri (tupluri) doar facult ile gestionate;
Specializare care se refer la specializrile fiecrei facult i gestionate.

Legturi ntre relaii


Dac analizm cu aten ie rela iile din exemplul 4.8 observm c redundan a datelor a
fost nlturat, n sensul c aceleai date nu le mai gestionm de mai multe ori n cadrul unei
rela ii, aa cum se ntmpla n exemplul 4.7, unde numele unei facult i ar fi aprut de fiecare
dat cnd mai gestionam un student al aceleai faculta i (realizarea FSE, ca valoare a
atributului facult ar fi aprut de fiecare dat cnd am fi avut un student al acestei facult i).
ns, n acelai 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, observm 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 specializri (rela ia Specializare), fr 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 legturi ntre
rela ii.

Legtura binar 1-1 (unu la unu)


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

Exemplul 4.9: Fie urmtoarele dou rela ii:


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

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

Prin intermediul rela iilor Client i Legitimaie ncercm s modelm situa ia accesului
ntr-un supermarket pe baza unei legitima ii. Pentru a realiza legtura dintre rela iile asociate,
va trebui s identificm mai nti tipul rela iilor (fiu sau printe). Astfel, pe baza defini iilor
prezentate anterior, observm c ambele rela ii sunt fiu deoarece fiecare client, la un
moment dat, nu poate avea dect o singur legitima ie care s-i permit accesul n
supermarket. Cu alte cuvinte, pentru exemplul 4.9, Popa Dan nu poate avea dect o singur
legitima ie, ceea ce nseamn c unui tuplu din rela ia Client nu-i poate corespunde dect un
singur tuplu n rela ia Legitimaie. Analiznd n acelai mod, este evident c o legitima ie nu
poate corespunde mai multor clien i.
Astfel, deoarece ambele rela ii sunt fiu, tipul de legtur 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 Legitimaie, unde va ndeplini rolul de cheie strin. n acelai mod, atributul nr_leg
va migra din rela ia Legitimaie n rela ia Client, iar modelul va arta ca n exemplul 4.10.
Exemplul 4.10:
Client ( cnp nume pren localitate nr_leg )
1701212120139 Popa Dan Gala i 23456
2711010120121 Darie Alina Brila 12121
1721209145123 Preda Marin Gala i 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 rela iile asociate, astfel nct s putem spune despre un client ce numr de
legitima ie are, sau plecnd de la numrul legitima iei, s putem identifica fr ambiguitate
care este de intorul acesteia.

Legtura binar 1-n (unu la mai muli)


Defini ie. Atunci cnd asociem dou rela ii, dintre care una este rela ie fiu, iar cealalt
este printe, legtura dintre ele se realizeaz prin migrarea cheii primare din rela ia printe,
sub forma cheii strine 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 realizm legtura dintre cele dou rela ii. Ca i n cazul primului tip de legtur, i de
aceast dat vom pleca de la identificarea tipurilor de rela ii, 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 rela ii pe care le asociem.
a. Identificarea tipului pentru rela ia 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 al ii
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 apar ine dect unei singure specializri.
Concluzionnd vom afirma despre Student c este rela ie fiu.
b. Identificarea tipului pentru rela ia Specializare n acest caz, rspunsul la ntrebarea: La
o specializare ci studeni pot fi nmatriculai? 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 printe.
Plecnd de la analiza fcut anterior, am stabilit c rela ia Student este fiu n timp ce
rela ia Specializare este printe: legtura dintre cele dou se va realiza prin migrarea cheii
primare din rela ia printe (cod_spec din Specializare) sub form de cheie strin n rela ia
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 nv mnt 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 strine 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 mnt ZI.

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


Defini ie. Atunci cnd asociem dou rela ii printe, legtura 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

Considerm 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 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 rela ii, dorim s punem n eviden care este con inutul
fiecrei facturi (produsele i cantit ile con inute de fiecare factur). Ini ial, vom identifica tipul
rela iilor pentru a putea realiza legtura dintre ele. Astfel, rela ia Factur este printe
deoarece considerm c o factur poate con ine unul sau mai multe produse. Totodat, si
rela ia Produs este tot printe deoarece un produs poate fi achizi ionat prin intermediul mai
multor facturi. Deci, ambele rela ii sunt de tipul printe; 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

Aa cum se observ, legtura 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 gsete att pe factura DX 1111 ct i pe DF 3333).
n cadrul rela iei Aprovizionare observm un nou atribut, care nu se regsea 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 cnd asociem cte un tuplu din fiecare rela ie (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 rela ii, legtura 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 legturii binare mai mul i la mai mul i, fr ns s mai necesite n
prealabil identificarea tipului fiecrei 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 Ctlin

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, aa 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 tiine Economice, la specializarea FB, forma de nv mnt 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 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 rela ional se refer la diferi i operatori care au ca operanzi rela iile, fiind
conceput de cercettorul E.F. Codd. n func ie de aritatea operatorului, rezultatul aplicrii
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 numr 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,
ntlnite n literatur sub numele de operaii de baz, i anume: reuniunea, diferena,

24
produsul cartezian, proiecia i selecia. Dintre aceste cinci opera ii, primele trei presupun
existen a a dou rela ii n timp ce urmtoarele 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 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. 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 realizri toate tuplurile primei rela ii care nu se regsesc n
cea de-a doua rela ie.
Astfel, dac realizm diferen a rela iilor 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 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 cnd 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 acelai nume).
Exemplul 4.18
Student ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Ctlin

7
Rela iile A i B trebuie s aib aceeai schem definit pe aceleai domenii.
8
Rela iile A i B trebuie s aib aceeai schem definit pe aceleai 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
Aa 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), 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. Proiec ia se aplic unei singure rela ii 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
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 acelai numr 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
Plecnd de la aceast rela ie, dorim s realizm proiec ia dup atributele nr_matr,
nume i pren. Astfel, vom ob ine urmtoarea rela ie:

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


1111 Popa Dan
2222 Darie Alina
3333 Preda Marin

5. Selecia. Selec ia se definete 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 aceeai 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
Plecnd de la rela ia de mai sus, dac dorim s realizm o selec ie a studen ilor cu
media mai mare sau egal cu opt, vom ajunge la urmtoare rela ie:

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


2222 Darie Alina 8.00
3333 Preda Marin 9.00

Pe lng opera iile amintite anterior, se mai pot utiliza i alte opera ii, numite operaii
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 rspunsuri mai rapide. Dintre opera iile derivate utilizate mai
frecvent amintim:
6. Intersecia. 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 realizri doar tuplurile comune celor dou
rela ii.
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 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 pai:
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 numete echiuniune. n
plus, dac vom realiza o proiec ie dup atributele primei opera ii, opera ia se numete semi-
uniune-stnga, 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 aceeai schem definit pe aceleai domenii.
11
n cazul uniunii, cele dou atribute trebuie s fie cte unul din fiecare rela ie.
27
Exemplul 4.22 Fie urmtoarele 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 aprovizionrilor, n rela ia
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 achizi ionat 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 rela ii, 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 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, aa 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 acelai 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 urmtoarele 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 determinm condi ia dup care se va realiza selec ia. Aa cum
observm, 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 cte un tuplu pentru acele tupluri dintr-o rela ie care nu au corespondent n
cealalt rela ie. Tuplurile adugate 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.
Plecnd de la rela iile 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 Finan e 9
333 Moga Dana Birotic 8
Aa 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 adugat 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 privete rela ia Disc, nu exist nici un tuplu care s nu
aib corespondent n rela ia Student (altfel spus, valorile 222 i 333, ca realizri ale
atributului nr_matr n rela ia Disc, se regsesc 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 stnga (left outer join) i uniune extern dreapta (right outer join). n ceea ce privete
uniunea extern stnga, rela ia va con ine toate tuplurile uniunii naturale la care se vor
aduga cele ale primei rela ii (considerat rela ia din stnga) 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 stnga, numai c n acest caz vor fi adugate
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. [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, 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.
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