Baze Date Economie Lupasc

Universitatea Dunrea de Jos Galai
Baze de date aplicate n economie

Lect. dr. Lupac Adrian
Departamentul pentru nvmnt la Distan i cu Frecven Redus

Galai - 2008
CUPRINS
Capitolul I Fundamente ale bazelor de date............................................................3
Ce este baza de date? .........................................................................................................4
Arhitecturi ale sistemelor de baze de date .......................................................................6
Capitolul II Proiectarea i administrarea unei baze de date.................................13

Ciclul de via al sistemelor informaionale...................................................................14
Ciclul de via al unui sistem de baze de date................................................................14
Proiectarea bazelor de date .............................................................................................17
Proiectarea conceptual ...............................................................................................................17
Proiectarea logic ........................................................................................................................17
Proiectarea fizic .........................................................................................................................19
Proiectarea tranzaciilor..................................................................................................19
Capitolul III Sisteme de gestiune a bazelor de date ..............................................24

Evoluia sistemelor de gestiune a bazelor de date .........................................................24
Faciliti oferite de un SGBD ..........................................................................................27
Avantajele i dezavantajele SGBD-urilor ......................................................................29
Componentele unui SGBD...............................................................................................35
Funciile SGBD-ului .........................................................................................................36
Capitolul IV Abordarea relaional a bazelor de date ..........................................43

Regulile lui Codd ..............................................................................................................43
Fundamente ale modelului relaional .............................................................................45
Legturi ntre relaii.........................................................................................................50
Legtura binar 1-1 (unu la unu) .................................................................................................51
Legtura binar 1-n (unu la mai muli)........................................................................................52
Legtura binar n-n (mai muli la mai muli) ..............................................................................53
Legtura dintre trei sau mai multe relaii.....................................................................................55
Algebra relaional operatorii relaionali ...................................................................56

Probleme rezolvate ...........................................................................................................63
Bibliografie ................................................................................................................73
Fundamente ale bazelor de date
Capitolul I Fundamente ale bazelor de date
****************************************************************************************
Obiectivele capitolului
Capitolul I Fundamente ale bazelor de date prezint evoluia i
ascensiunea pn n prezent a domeniului bazelor de date i realizeaz o
descriere succint a aspectelor de baz care caracterizeaz domeniul. n
acest context, am ncercat s poziionm teoria bazelor de date n cadrul
tehnologiilor informaionale, am prezentat cteva definiii relevante ale
conceptului de baz de date formulate de cercettori i profesori care s-au
remarcat cu preocupri nsemnate n cadrul domeniului i au fost identificate
i analizate principalele arhitecturi specifice sistemelor de baze de date.
Totodat, principalul scop avut n vedere este de a oferi o viziune clar i o
nelegere general a ceea ce reprezint astzi baza 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 1 . 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.
Mainframe reprezint un tip de calculator de mare putere care este utilizat cel mai adesea
pentru gestiunea bazelor de date de dimensiuni foarte mari, precum i a altor aplicaii
asemntoare, care necesit o capacitate de stocare foarte mare i o interaciune puternic
cu un numr mare de utilizatori, concretizat printr-un volum foarte mare de comunicaii de
date.

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.
Atunci cnd vizitai o bibliotec (!dac se mai ntmpl acest lucru)
constatai c exist o baz de date care conine informaii detaliate despre
crile care formeaz fondul de carte al bibliotecii. Practic, pentru a
prentmpina anumite cerine, aceste sisteme se bazeaz pe un index
computerizat care permite cititorului s identifice o carte dup titlu, autor sau
subiectul acesteia.
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,
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.
4

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, eliminnduse 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.
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.
5

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, aa cum se poate observa n figura 1.1.
Date
Software
Elemente auxiliare
Figura 1.1. Arhitectura pe componente a unui sistem de baze de date
Aa cum se observ, componentele specifice arhitecturii din figura 1.1

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.
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 (figura 1.2).

Vederi ale
bazei de date
Programator
de aplicatie
Administrator
baza de date
Inginer
(analist) de
sistem
Manipulare date
Program
aplicatie 1
...
SGBD
S.O.
Baz de date
Niveluri de
organizare
date
Descriere date
Structura externa
(logica)
Structura
conceptuala
...
...
Structura interna
(fizica)
Logic
Conceptual
Fizic
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 SGBD2;
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);
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].
SGBD Sistem de Gestiune a Bazelor de Date

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.
Perspective asupra unei baze de date
Fiecare baz de date o putem privi din diferite perspective, cum ar fi:
perspectiva utilizatorului, care lucreaz cu diferite pri

componente ale unei baze de date, numite vederi. Vederile sunt
descrise prin intermediul unor subscheme n sublimbaje ale
limbajului de descriere a datelor (LDD). Totodat, utilizatorii pot
primi rspunsuri la cererile pe care le formuleaz prin intermediul
limbajului de prelucrare a datelor;
perspectiva administratorului bazei de date, care integreaz toate

vederile referitoare la baza de date ntr-un singur model numit
schem conceptual. Practic, aceast schem conceptual
constituie nivelul logic al bazei de date;
perspectiva implementatorului bazei de date n foarte multe

situaii, el coincide cu administratorul bazei de date, care privete
baza de date ca pe o colecie de fiiere memorate pe diferite medii
externe. Acesta constituie nivelul fizic al bazei de date i care este
practic singurul nivel care exist efectiv.

ntrebri recapitulative
1. Ce reprezint o baz de date?
2. Menionai factorii care au permis domeniului bazelor de date s devin o
component cheie a sistemelor informaionale moderne.
3. Identificai principalele motive care determin trecerea de la o organizare
a datelor sub forma foilor de calcul Excel la cea sub forma bazei de date.
4. Definii conceptul de entitate.
5. Definii conceptul de atribut.
6. Care sunt componentele specifice arhitecturii pe componente?
7. Prezentai rolul nivelului conceptual aferent arhitecturii pe niveluri.
8. Prezentai rolul nivelului logic aferent arhitecturii pe niveluri.
9. Prezentai rolul nivelului fizic aferent arhitecturii pe niveluri.
10. Cror viziuni corespund cele trei niveluri ale arhitecturii pe niveluri?
Teste gril
1. Printre factorii care au contribuit la adoptarea n mas a sistemelor de
baze de date se numr:
a. necesitatea unei administrri mai eficiente a unei cantiti mai mari
de informaii;
b. creterea semnificativ
hardware i software;
preurilor
aferente
componentelor
c. apariia tehnicilor bazate pe gandirea orientat-obiect;

d. dezvoltarea prelucrrilor bazate pe tehnologia client-server.
2. Referitor la o baz de date relaional, putem afirma c va conine:
a. colecii organizate de date ntre care pot exista diferite legturi;
b. colecii organizate de date ntre care pot exista legturi, iar dac
exist, ele sunt legturi logice;
c. colecii organizate de date fr legturi logice;
d. colecii organizate de date ntre care exist legturi logice.
3. Componenta software specific arhitecturii pe componente a unui sistem
de baze de date poate conine:
a. dicionarul de date;
b. sistemul de gestiune al bazei de date;
c. datele;
d. fiierele anex.
10

4. Elementele auxiliare specifice arhitecturii pe componente se refer la:
a. realizarea i funcionarea ntregului sistem de baze de date;
b. programe de aplicaii dezvoltate ntr-un sistem de gestiune a
bazelor de date;
c. realizarea i exploatarea bazei de date;
d. structura datelor, restriciile de integritate i vederile unei baze de
date.
5. Nivelul conceptual specific arhitecturii pe niveluri se refer la:
a. viziunea administratorului bazei de date asupra datelor;
b. viziunea programatorului asupra datelor;
c. viziunea utilizatorului asupra modului de proiectare a bazei de date;
d. viziunea administratorului, al programatorului i al utilizatorului
asupra modului de proiectare a bazei de date.
6. n cadrul arhitecturii pe niveluri, la nivel logic:
a. programatorul realizeaz programele de aplicaie
descrierea i manipularea datelor, scrise ntr-un SGBD;
pentru
b. viziunea programatorului este independent de suportul tehnic de

informaie;
c. viziunea administratorului asupra bazei de date este independent
de aplicaiile care vor fi dezvoltate;
d. implementarea schemei interne se face cu ajutorul sistemului de
gestiune a fiierelor din cadrul SGBD-ului i/sau din sistemul de
operare, prin gestiunea fizic a perifericelor.
7. Independena logic se refer la faptul c:
a. viziunea programatorului asupra bazei de date este independent
b. viziunea administratorului asupra bazei de date este independent
c. viziunea utilizatorului final asupra bazei de date este independent
d. viziunea programatorului i al administratorului asupra bazei de
date este independent de aplicaiile care vor fi dezvoltate.
8. Independena fizic se refer la faptul c:
a. viziunea administratorului bazei de date este independent de
suportul tehnic de informaie;
b. viziunea programatorului i al administratorului bazei de date este
independent de suportul tehnic de informaie;
c. viziunea programatorului este independent de suportul tehnic de
informaie;
d. independena fizic se realizeaz indiferent de
programatorului, utilizatorului sau a administratorului.
viziunea
11

9. Nivelul fizic aferent arhitecturii pe niveluri se refer la:
a. viziunea analistului de sistem asupra datelor i descrie modul n
care ele sunt stocate n baza de date;
b. viziunea inginerului de sistem asupra datelor, dar nu descrie modul
n care sunt stocate datele n baza de date;
c. viziunea inginerului de sistem asupra datelor i descrie modul n
care sunt stocate datele n baza de date;
d. viziunea administratorului bazei de date asupra datelor.
10. Independena logic este specific:
a. nivelului logic;
b. nivelului conceptual;
c. nivelului fizic;
d. independena logic este specific nivelului conceptual sau
nivelului logic, n funcie de modul de proiectare al bazei de date.
12
Proiectarea i administrarea unei baze de date
Capitolul II Proiectarea i administrarea unei baze de date
****************************************************************************************
Proiectarea i administrarea sistemelor de baze de date reprezint o sarcin
dificil i important n cadrul ciclului de via al unui sistem informatic care
are drept scop gestionarea i utilizarea unui anume volum de date stocate
prin intermediul acestora. n acest context, capitolul II Proiectarea i
administrarea unei baze de date urmrete atingerea urmtoarelor
obiective:
identificarea i definirea principalelor caracteristici ale ciclului de via

al unui sistem de baze de date;
detalierea procesului de proiectare a unei baze de date;
prezentarea tipurilor de proiectare: conceptual, logic i fizic;
definirea i proiectarea tranzaciilor.
****************************************************************************************
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
13

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 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
sunt prezentate n figura 2.1. Trebuie menionat c etapele ciclului de via
ale unei astfel de aplicaii 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.
14
Planificarea
bazei de date
Delimitarea granitelor
sistemului
Colectarea si
analiza cerintelor
Proiectarea
bazei de date
Proiectarea conceptuala
Alegerea SGBD-ului
Proiectarea logica
Proiectarea aplicatiei
Proiectarea fizica
Prototipizarea
Implementarea
Testarea
ntretinere operationala
Figura 2.1. Ciclul de via al unei aplicaii de tip baz de date
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
15

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:
16
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 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-R3, relaional, OO4, OR5), 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 6 ) s fie necesare
interogri suplimentare.
Proiectarea conceptual
Proiectarea conceptual este prima faz din procesul de proiectare a

unei baze de date i presupune crearea unui model de date conceptual
pentru partea care se dorete a fi modelat (parte din activitatea unei
organizaii). Acest model de date va fi construit prin utilizarea informaiilor
aferente specificaiilor cerinelor utilizatorului. Proiectarea conceptual a
bazei de date este complet independent de detaliile de implementare, cum
ar fi elementele de software ale sistemului SGBD avut n vedere, programele
de aplicaie, platforma hardware sau orice alte consideraii fizice. Totodat,
trebuie s menionm c este important ca pe tot parcursul procesului de
realizare a modelului conceptual de date, acesta s fie permanent testat i
validat conform cerinelor utilizatorului. Practic, acest model constituie o
surs important de informaii pentru faza de proiectare logic.
Proiectarea logic
Aceast faz are ca rezultat crearea unui model de date logic aferent
activitilor sau proceselor pe care dorim s le modelm. Modelul de date
3
E-R Entitate Relaie

OO Orientat Obiect
5
OR Obiectual Relaional
6
Select este o instruciune specific limbajului SQL Structured Query Language care
permite extragerea datelor din baza de date.
4
17

conceptual creat n faza precedent este rafinat i transpus ntr-un model de
date logic. Acesta este influenat de ctre modelul de date avut n vedere
pentru baza de date (spre exemplu, modelul de date relaional pe care l vom
detalia n capitolul IV).
Spre deosebire de cellalt model, care este independent de toate
consideraiile fizice, modelul logic este creat plecnd de la modelul de date
principal al sistemului SGBD int. Cu alte cuvinte, tim c SGBD-ul este, de
exemplu, relaional, ierarhic sau orientat spre obiecte. ns, se ignor alte
aspecte ale SGBD-ului ales i, mai ales, fiecare detaliu fizic, aa cum sunt
structurile de stocare.
Pe parcursul realizrii modelului logic de date, se efectuez testarea i
validarea permanent a acestuia n conformitate cu cerinele utilizatorului.
Tehnica de normalizare este utilizat pentru a testa corectitudinea modelului
logic de date. Practic, normalizarea garanteaz c relaiile derivate din
modelul de date nu prezint redundane, care pot cauza anomalii (la
implementare) la actualizarea bazei de date. Altfel spus, normalizarea este
procesul prin care se elimin redundana datelor din baza de date i se
construiete un model de baz de date care susine diverse cerine
funcionale i structuri alternative ale bazei de date.
Normalizarea presupune mprirea unei relaii (care include la
momentul respectiv toate atributele necesare problemei) n mai multe relaii
ntre care se definesc diferite legturi logice. Principalele obiective ale
normalizrii sunt [Fotache, 2005, p.41-42]:
minimizarea spaiului necesar stocrii datelor;
minimizarea riscului apariiei de date inconsistente n cadrul bazei de

date;
minimizarea numrului de anomalii ce pot aprea la actualizare
(inserarea datelor, dar mai ales modificri i tergeri);
ameliorarea structurii bazei de date, reprezentarea diverselor
conexiuni dintre atributele acesteia;
diminuarea nevoii de reorganizare periodic a modelului.
Exist un numr de reguli care se aplic n normalizare. n continuare

vom prezenta doar primele trei reguli care sunt n msur s garanteze
definirea unei structuri logice a bazei de date ntr-o form acceptabil (n
care ns redundana nu este eliminat complet):
1. Toate atributele trebuie specificate o singur dat (forma I normal);
2. Fiecare atribut trebuie s depind n totalitate de cheia primar a relaiei
pe care o descrie (forma II normal). Aceast regul se realizeaz prin
repartizarea atributelor ntr-o relaie, astfel nct fiecare dintre ele va
depinde n totalitate de cheia primar.
3. Pentru a putea fi n forma III normal, fiecare relaie trebuie s aib o
singur cheie primar.
Totodat, modelul logic de date reprezint o surs important de
informaii pentru faza de proiectare fizic, punnd la dispoziia proiectantului
bazei de date logice un mecanism care s-i permit realizarea negocierilor,
care sunt foarte importante pentru a face ca proiectarea bazei de date s fie
eficient. Totodat, acest model are un rol important n etapa de ntreinere
18

operaional din ciclul de via al unei aplicaii cu baze de date. Dac este
ntreinut i mbuntit adecvat, modelul de date permite efectuarea unor
modificri viitoare n programele aplicaie i reprezentarea corect i eficient
a datelor de ctre baza de date.
Proiectarea fizic
Proiectarea fizic a bazelor de date este a treia faz din procesul de
proiectare a unei baze de date, n care proiectantul stabilete cum va fi ea
implementat. Aa cum am vazut deja, faza precedent presupunea
realizarea unei structuri logice, cu alte cuvinte se referea la definirea relaiilor,
atributelor i legturilor dintre ele. Cu toate c aceast structur este
independent de SGBD-ul ales, ea se realizeaz conform unui model de
date, aa cum este cel relaional. n realizarea proiectrii fizice, trebuie iniial
identificat sistemul de baze de date avut n vedere. Prin urmare, proiectarea
fizic este croit dup modelul unui anumit SGBD. ntre proiectarea fizic i
cea logic exist o legtur, deoarece pe parcursul proiectrii fizice sunt
luate decizii referitoare la mbuntirea performanelor, care pot ns afecta
structura modelului logic de date.
n cele mai multe situaii, obiectivul principal al proiectrii fizice este de
a descrie cum se intenioneaz realizarea implementrii fizice a proiectului
logic al unei baze de date. Astfel, n cazul modelului relaional, aceasta
presupune:
extragerea unui set de tabele relaionale (relaii) i de constrngeri asupra

acestora, din informaiile prezentate n modelul logic de date (modelul
global);
identificarea structurilor de stocare specifice i metodelor de acces la date,

astfel nct s se garanteze obinerea unor performane optime cu
sistemul respectiv;
proiectarea mijloacelor care s asigure securitatea sistemului.
Proiectarea tranzaciilor
n sens larg, putem defini o tranzacie ca o aciune sau o serie de
aciuni efectuate de utilizator sau de un program de aplicaie, care acceseaz
sau actualizeaz o baz de date. De asemenea, n [Georgescu, Georgescu,
2005, p.71] tranzacia este definit ca unitatea logic de prelucrare asupra
unei baze de date care include setul complet de operaii elementare ce
trebuie executat n vederea realizrii unei tranziii, pentru asigurarea
consistenei i siguranei bazei de date. Aceeai autori consider c o
tranziie se refer la trecerea de la o realizare la alta a unei baze de date i
poate fi produs de modificarea coninutului unei tabele a bazei de date, de
modificarea structurii acesteia, de adugarea unei noi tabele, etc.
Tranzaciile reprezint evenimente din lumea real, cum ar fi
adugarea unui nou angajat, nregistrarea unui nou client, nregistrarea unei
note obinute de un student la o disciplin, etc. Aceste tranzacii trebuie
aplicate bazei de date, pentru a garanta c datele coninute n aceasta
rmn la curent cu situaia din lumea real, dar i pentru a susine nevoile
informaionale ale utilizatorilor.
19

O tranzacie poate fi format din mai multe operaii, cum ar fi spre
exemplu, transferul banilor dintr-un cont n altul. Totui, din punctul de vedere
al utilizatorului, aceste operaii realizeaz o singur sarcin. Din perspectiva
SGBD-ului, o tranzacie transfer baza de date dintr-o stare n alta. SGBD-ul
asigur coerena bazei de date, chiar n cazul unei defeciuni. Totodat,
SGBD-ul garanteaz i faptul c odat tranzacia finalizat, modificrile
realizate sunt stocate permanent n baza de date i nu pot fi pierdute sau
anulate. Dac dintr-un motiv oarecare, tranzacia nu poate fi terminat,
SGBD-ul este n msur s garanteze c modificrile realizate de acesta
sunt anulate. n exemplul menionat anterior, cel al transferului de bani, dac
banii sunt debitai ntr-un cont i tranzacia eueaz naintea creditrii
celuilalt cont, SGBD-ul va anula i debitarea. n cazul n care am defini cele
dou operaii (debitarea i creditarea) ca tranzacii separate, atunci, odat
debitat primul cont i ncheiat tranzacia, modificarea nu ar mai putea fi
anulat (pentru situaia n care creditarea nu s-ar realiza).
Trebuie s mai menionm i faptul c proiectarea unei tranzacii se
bazeaz pe informaiile din specificaiile cerinelor utilizatorului. Exist
numeroase tehnici de preluare i generare a specificaiilor cerinelor, care
includ i o notaie pentru specificarea tranzaciilor cerute de ctre utilizatori.
Aceste tranzacii pot constitui operaii complexe care, atunci cnd sunt
analizate, se dovedesc a fi compuse, de fapt, din mai multe operaii, fiecare
dintre acestea constituind cte o singur tranzacie.
20

1. Ce reprezint sistemul informaional?
2. Identificai i prezentai pe scurt principalele scopuri ale proiectrii unei
baze de date.
3. Ce reprezint ntreinerea operaional?
4. Care sunt principalele tipuri de proiecri n viziunea cercettorului
Connoly i a colaboratorilor si?
5. Proiectarea conceptual.
6. Proiectarea logic.
7. Proiectarea fizic.
8. Proiectarea tranzaciilor.
9. Ce reprezint tranzacia?
10. Ce reprezint tranziia?
Teste gril
1. Rolul sistemului informaional este de a asigura legtura dintre:
a. sistemul decizional i cel operaional;
b. sistemul operaional i cel informatic;
c. sistemul de conducere i cel de execuie;
d. toate sistemele organizaiei.
2. Etapele ciclului de via al unui sistem de baze de date:
a. nu pot fi mereu secveniale;
b. sunt mereu secveniale;
c. depinde de maniera de proiectare a sistemului informatic: n
funcie de aceasta, etapele ciclului de via se pot derula
secvenial sau nu;
d. se poate reveni la o etap anterioar numai dup parcurgerea
tuturor etapelor.
3. Proiectarea bazei de date se refer i la:
a. alegerea SGBD-ului;
b. prototipizare;
c. testare;
d. ntreinere operaional.
21

4. ntreinerea operaional se refer la:
a. monitorizarea i testarea continu a aplicaiei;
b. monitorizarea continu a aplicaiei i ncorporarea unor noi
cerine, atunci cnd este cazul;
c. monitorizarea continu a aplicaiei i ncorporarea permanent
a unor noi cerine;
d. monitorizarea continu a aplicaiei, fr ns a se mai putea
aduga funcionaliti suplimentare aferente noilor cerine.
5. Prototipizarea este:
a. o etap obligatorie specific proiectrii bazei de date care
permite numai proiectantului s evalueze modul de funcionare
a aplicaiei;
b. o etap opional specific proiectrii bazei de date care
permite numai proiectantului s evalueze modul de funcionare
a aplicaiei;
c. o etap obligatorie specific proiectrii bazei de date care
permite proiectantului i utilizatorului s evalueze modul de
funcionare a aplicaiei;
d. o etap opional specific proiectrii bazei de date care
permite proiectantului i utilizatorului s evalueze modul de
funcionare a aplicaiei.
6. Proiectarea bazei de date se refer i la:
a. oferirea unui model de date care s permit realizarea
tranzaciilor;
b. oferirea unui model de date care s permit realizarea tuturor
tranziiilor necesare;
c. oferirea unui model de date care s permit realizarea
tranzaciilor i a tranziiilor asupra datelor;
d. proiectarea bazei de date nu se refer la oferirea unui model de
date.
7. Proiectarea conceptual se refer la:
a. construirea unui model informaional dependent de fiecare
considerent privitor la aspectul fizic al datelor;
b. construirea unui model informaional independent de fiecare
considerent privitor la aspectul fizic al datelor;
c. construirea unui model informaional independent bazat pe unul
din modelele tradiionale;
d. implementarea efectiv a bazei de date.
22

8. Proiectarea incorect a bazei de date poate conduce la urmtoarele
deficiene:
a. lipsa performanelor dorite;
b. neredundana datelor;
c. afectarea integritii datelor;
d. imposibilitatea proiecrii corecte a restriciilor de integritate
asupra datelor.
9. Realizarea unui model de date logic este specific:
a. proiectrii conceptuale;
b. proiectrii fizice;
c. proiectrii logice;
d. proiectrii tranzaciilor.
10. Tranzacia se refer la:
a. aciuni care numai acceseaz baza de date;
b. aciuni care numai actualizeaz baza de date;
c. aciuni care acceseaz sau actualizeaz baza de date;
d. trecerea de la o realizare la alta a bazei de date.
23
Sisteme de gestiune a bazelor de date
Capitolul III Sisteme de gestiune a bazelor de date
****************************************************************************************
Sistemul de gestiune a bazelor de date constituie n prezent un cadru de
baz al sistemelor informaionale i a modificat fundamental modul de
operare al unei organizaii. Astfel, n cadrul capitolului trei, am definit sistemul
de gestiune a bazelor de date, am descris evoluia n timp a acestora i am
prezentat principalele faciliti pe care le ofer. Totodat, am tratat
componentele unui sistem de gestiune a bazelor de date, funciile lui, precum
i principalele avantaje i dezavantaje pe care le aduc introducerea n
practic a acestora.
****************************************************************************************
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 [Trandafir et al., 2007, p.10].
Evoluia sistemelor de gestiune a bazelor de date

Aa cum se tie, predecesorul SGBD-ului a fost sistemul bazat pe
fiiere. Totui, nu a existat un moment bine definit, n care s nceap
tratarea prin baze de date i s nceteze sistemul bazat pe fiiere. De fapt,
sistemul bazat pe fiiere mai exist nc i astzi n anumite domenii. S-a
sugerat c SGBD-ul i are rdcinile n proiectul de aselenizare Apollo din
24

anul 1960, care a fost iniiat ca rspuns la obiectivul preedintelui J.F.
Kennedy de a trimite un om pe lun pn la sfritul deceniului. n acel
moment, nu exista nici un sistem capabil s trateze i s administreze
cantitile vaste de informaii pe care le necesita proiectul.
Ca rezultat, compania North American Aviation (NAA - acum Rockwell
International), primul contractant al proiectului, a dezvoltat un software
cunoscut sub denumirea de GUAM (Generalized Update Access Methodh
metoda general de acces prin reactualizare). Sistemul GUAM pornea de la
ideea c, toate componentele mai mici constituie pri ale unor componente
mai mari i aa mai departe, pn la asamblarea produsului final. Aceast
structur, care seamn cu un copac cu susul n jos, este cunoscut i sub
denumirea de structur ierarhic. La mijlocul anilor 1960, companiile IBM i
NAA au transformat sistemul GUAM n ceea ce este cunoscut sub denumirea
de IMS7 (sistem de gestionare a informaiilor). Motivul pentru care cei de la
IBM au restrns sistemul IMS la administrarea ierarhiilor nregistrrilor a fost
de a permite utilizarea unor dispozitive de stocare seriale, mai ales benzi
magnetice, ceea ce constituia o cerin de pia n acel moment. Aceast
restricie a fost abandonat ulterior. Cu toate c este unul dintre primele
sisteme SGBD, IMS este nc cel mai important i este utilizat de majoritatea
calculatoarelor de tip mainframe.
La mijlocul anilor 1960, o alt realizare semnificativ a fost apariia
sistemului IDS8 (depozitul de date integrate), realizat de compania General
Electric. Acest proiect a fost condus de ctre unul dintre pionierii sistemelor
de baze de date, Charles Bachrnann. Aceast realizare a dus la apariia unui
nou tip de sistem de baze de date, cunoscut sub denumirea de sistem SGBD
n reea, care a avut un efect profund asupra sistemelor informaionale din
acea generaie. Baza de date n reea a fost realizat, parial, pentru a
rspunde necesitii de reprezentare a unor relaii dintre date mai complexe
dect se puteau modela cu ajutorul structurilor ierarhice i, parial, pentru a
impune un standard pentru bazele de date. Pentru a contribui la stabilirea
unor astfel de standarde, la Conferina despre Limbajele Sistemelor de Date
(CODASYL9) din 1965, la care au participat reprezentani ai guvernului SUA
i ai lumii afacerilor i comerului, s-a format Fora Operativ de Prelucrare a
Listelor, redenumit Grupul Operativ pentru Baze de Date (DBTG10) n 1967.
Termenii de referin ai grupului DBTG constau n definirea de specificaii
standard pentru un mediu care s permit crearea de baze de date i
manipularea datelor. n 1969 a aprut un raport preliminar, iar n 1971
raportul definitiv. Propunerea grupului DBTG a identificat trei componente:
schema de reea - organizarea logic a ntregii baze de date, aa cum

este vzut de ctre administratorii bazei de date i include o definire a
denumirii bazei de date, a tipului fiecrei nregistrri i a componentelor
fiecrui tip de nregistrare;
subschema - partea din baza de date, aa cum este vzut de ctre

utilizator sau de ctre programul aplicaie;
un limbaj de gestionare a datelor, care s defineasc caracteristicile i

structura datelor i care s le manipuleze.
Acronim pentru Information Management System

Acronim pentru Integrated Data Store
9
COnference on DAta SYstems Language
10
Data Base Task Group
8
25

Pentru standardizare, grupul DBTG a specificat trei limbaje distincte:
un limbaj de definire a datelor (LDD) pentru schem, care permite

administratorului bazei de date s defineasc schema;
un limbaj de descriere a datelor pentru subschem, care permite

programelor aplicaie s defineasc componentele bazei de date de care
au nevoie;
un limbaj de manipulare a datelor (LMD), pentru manipularea lor.
Cu toate c, formal, raportul nu a fost adoptat de ctre Institutul

Naional American pentru Standarde (ANSI11), ulterior s-a realizat un numr
de sisteme conform propunerii DBTG. Acestea sunt cunoscute acum sub
denumirea de sisteme CODASYL sau DBTG. Abordrile de tip CODASYL i
ierarhice au reprezentat prima generaie de SGBD-uri. Totui, aceste dou
modele prezint cteva dezavantaje fundamentale, printre care cele mai
importante sunt:
trebuie scrise programe complexe pentru a rspunde chiar i la interogri

simple, bazate pe accesul navigaional orientat spre nregistrri;
exist o independen minim de date;
nu exist nici o baz teoretic larg acceptat.
n 1970, E.F. Codd de la Laboratorul de Cercetare IBM a publicat un

articol de foarte mare influen despre modelul de date relaional. Acest
articol, aprut exact la momentul potrivit, analizeaz dezavantajele
abordrilor prezentate mai sus. De atunci, au fost implementate multe
sisteme SGBD relaionale experimentale, primele produse comerciale
aprnd la sfritul anilor 1970 i nceputul anilor 1980. De remarcat este
proiectul System R, de la Laboratorul de Cercetare IBM din San Jose,
realizat la sfritul anilor 1970 [Astrahan et al., 1976]. Acest proiect a fost
ndeplinit pentru a demonstra caracterul practic al modelului relaional, prin
realizarea unei implementri a structurilor de date i a operaiilor acestuia,
fapt care a avut dou consecine majore:
dezvoltarea unui limbaj de interogare structurat, denumit SQL, care de

atunci a devenit limbajul standard pentru sistemele SGBD relaionale;
producerea de diverse sisteme SGBD relaionale la scar comercial, n

decursul anilor 1980; de exemplu, sistemele DB2 i SQL/DS de la IBM i
Oracle de la compania cu acelai nume .
n prezent, exist cteva sute de sisteme SGBD relaionale, att

pentru medii mainframe, ct i pentru microcalculatoare, cu toate c multe
dintre ele extind definiia modelului relaional. Alte exemple de sisteme SGBD
relaionale multiutilizator sunt: CS-OpenIngres de la compania Computer
Associates i Informix de la Informix Software Inc. Cteva exemple de
sisteme SGBD relaionale pentru microcalculatoare sunt: Access i FoxPro
ale companiei Microsoft, Paradox i Visual dBase ale companiei Borland i
R:Base al companiei Microrim. Sistemele SGBD relaionale sunt denumite
sisteme SGBD din a doua generaie.
Cu toate acestea, modelul relaional a cunoscut i eecuri - n
particular, datorit capacitilor sale de modelare limitate. De-a lungul
11
Acronim pentru American National Standards Institute
26

timpului, s-au efectuat multe cercetri care au ncercat s rezolve aceast
problem. n 1976, Chen a prezentat modelul Entitate-Relaie, care
reprezint acum o tehnic de proiectare a bazelor de date larg acceptat. n
1979, nsui Codd a ncercat s rezolve cteva dintre esecurile din lucrarea
sa initial, printr-o versiune extins a modelului relaional, denumit RM/T
(1979), urmat mai recent de RM/V2 (1990). ncercrile de realizare a unui
model de date care s reprezinte mai ndeaproape lumea real au primit
denumirea nu prea inspirat de modelare semantic a datelor.
Ca rspuns la complexitatea crescnd a aplicaiilor bazelor de date,
au aprut dou noi sisteme: sistemele SGBD orientate spre obiecte
(OODBMS12) i sistemele SGBD de obiecte relaionale (ORDBMS13). Totui,
spre deosebire de modelele anterioare, compoziia acestora nu este clar, iar
aceast evoluie reprezint a treia generaie de sisteme SGBD.
n prezent, datorit facilitilor pe care le ofer, constatm c cea mai
mare partea bazelor de date sunt realizate cu ajutorul unor SGBD-uri
relaionale i tot mai puine se bazeaz pe cele de generaia I. Totodat,
trebuie remarcat i evideniat interesul tot mai mare fa de utilizarea n
practic a SGBD-urilor orientate obiect.
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.
12
13
Acronim pentru Object-Oriented DataBase Management System

Acronim pentru Object-Relational DataBase Management System
27

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 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 si 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
28

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.
Analiza prezentat mai sus este una general. Nivelul real de
funcionalitate a unui SGBD difer de la produs la produs. De exemplu, s-ar
putea ca un SGBD pentru un calculator personal s nu accepte accesul
partajat concurent, ns ar prezenta doar un control limitat al securitii,
integritii i refacerii. Totui, produsele SGBD moderne, multiutilizator,
prezint toate funciile de mai sus i nc multe altele. Sistemele moderne
sunt programe extrem de complexe, formate din milioane de linii de cod, cu
documentaia constnd n multe volume. Acesta este un rezultat al necesitii
de realizare a unor programe care s trateze cerine de o natur mai
general. Mai mult, n zilele noastre, utilizarea unui SGBD necesit sisteme
care s prezinte un grad de fiabilitate i de disponibilitate de aproape 100%,
chiar n cazul unor defeciuni, fie la nivel hardware, fie software. Totodat,
toate SGBD-urile trebuie s evolueze i s se dezvolte permanent, dar
necesit i o perfecionare continu pentru a prentmpina noile cerine ale
utilizatorilor. De exemplu, dac unele aplicaii necesit stocarea de imagini
grafice, video, sunete, etc. pentru satisfacerea acestei piee, SGBD-urile
trebuie s se modifice. Cel mai probabil c o nou funcionalitate va fi mereu
necesar, aa nct aceasta nu va putea deveni niciodat static.
Avantajele i dezavantajele SGBD-urilor

Aa cum vom arta n continuare, utilizarea n practic a sistemelor de
gestiune a bazelor de date beneficiaz de promitoare avantaje poteniale,
ns, din pcate, exist i unele dezavantaje.
Avantajele SGBD-urilor
1.Controlul redundanei datelor
Aa cum am mai menionat, n sistemele tradiionale bazate pe fiiere
se fcea risip de spaiu prin stocarea acelorai informaii n mai multe fiiere.
Prin contrast, n tratarea prin baze de date se ncearc eliminarea
redundanei prin integrarea fiierelor, astfel nct s nu se stocheze mai
multe copii ale acelorai date. Totui, n tratarea prin baze de date nu se
elimin n ntregime redundana, ci se controleaz volumul inerent al acesteia
n baza de date. Uneori, pentru modelarea relaiilor, este necesar dublarea
unor articole de date cheie. Alteori, pentru mbuntirea performanelor, este
de dorit s se dubleze unele articole de date.
2.Coerena datelor
Prin eliminarea sau controlul redundanei se reduce riscul apariiei
incoerenei datelor. Dac un articol de date este stocat o singur dat n
baza de date, orice reactualizare a valorii sale trebuie realizat tot o singur
dat, iar noua valoare este disponibil imediat, pentru toi utilizatorii. Dac un
articol de date este stocat de mai multe ori, iar sistemul este contient de
29

aceasta, el poate garanta c toate copiile articolului respectiv sunt meninute
coerente. Din pcate, multe dintre sistemele SGBD actuale nu garanteaz
automat acest tip de coeren.
3.Mai multe informaii de la aceeai cantitate de date
Odat cu integrarea datelor operaionale, ar putea fi posibil ca
organizaia respectiv s extrag informaii suplimentare din aceleai date.
4.Partajarea datelor
n general, fiierele sunt deinute de ctre persoanele sau
departamentele care le utilizeaz. Pe de alt parte, baza de date aparine
ntregii organizaii sau instituii i poate fi partajat de ctre toi utilizatorii
autorizai. n acest mod, mai muli utilizatori partajeaz o cantitate mai mare
de date. Mai departe, se pot construi noi aplicaii bazate pe datele existente
n baza de date, n timp ce datele adiionale (care nu sunt stocate n mod
curent) se pot aduga fr a fi necesar definirea repetat a tuturor cerinelor
referitoare la acestea. Noile aplicaii se pot baza i pe funciile oferite de
ctre sistemul SGBD (cum ar fi definirea i manipularea datelor i controlul
concurenei i refacerii) n loc de a fi necesar s le furnizeze ele nsele.
5.Integritatea crescut a datelor
Integritatea bazei de date se refer la validitatea i coerena datelor
stocate. De obicei, integritatea este exprimat n termeni de constrngeri,
care reprezint reguli de coeren, pe care baza de date trebuie s le
respecte. Constrngerile se pot aplica articolelor de date dintr-o singur
nregistrare sau relaiilor dintre diferite nregistrri. Spre exemplu, o
constrngere privind integritatea ar putea stabili c salariul unui angajat nu
poate fi mai mare de o mie de euro sau c nota pe care o obine un student
la o disciplin nu poate fi mai mic de patru. Din nou, integrarea permite
administratorului bazei de date s defineasc (iar bazei de date s
ntreasc) constrngerile privind integritatea.
6.Securitate sporit
Securitatea se refer la protecia bazei de date fa de utilizatorii
neautorizai. Fr msuri de securitate clare i adecvate, integrarea face ca
datele s fie mult mai vulnerabile dect n cazul sistemelor bazate pe fiiere.
Totui, integrarea va permite administratorului bazei de date s defineasc
(iar bazei de date s ntreasc) securitatea acesteia. Aceasta se poate
realiza prin atribuirea unor nume de utilizatori i parole, care s permit
identificarea persoanelor autorizate s utilizeze baza de date (fiecare
persoana poate accesa, n funcie de poziia pe care o are n organizaie, un
anumit set de date). Accesul la date permis unui utilizator autorizat poate fi
limitat de tipul operaiei efectuate (extragere, inserare, reactualizare,
tergere). De exemplu, administratorul bazei de date are acces la toate
datele din baza de date, un manager de fIlial ar putea accesa doar datele
legate de filiala respectiv, n timp ce un utilizator de la compartimentul
Vnzri ar putea avea acces numai la datele referitoare la proprieti, dar nu
30

i la datele sensibile, cum ar fi detaliile despre salariile angajailor sau
contractele ncheiate.
7.Aplicarea standardelor
Din nou, integrarea permite administratorului bazei de date s
defineasc i s aplice toate standardele necesare. Acestea ar putea include
standarde departamentale, organizaionale, naionale sau internaionale
(pentru diferite aspecte, cum ar fi formatul datelor) care s faciliteze schimbul
de date ntre sisteme, conveniile privind denumirile, standardele de
documentare, procedurile de reactualizare i regulile de acces.
8.Economia de scal
Combinarea tuturor datelor operaionale ale organizaiei ntr-o singur
baz de date i crearea unui set de aplicaii care s funcioneze pentru
aceast unic surs de date pot avea ca rezultat micorarea costurilor. n
acest caz, s-ar putea combina bugetele care ar fi fost alocate n mod normal
fiecrui departament pentru dezvoltarea i ntreinerea propriului sistem
bazat pe fiiere, ceea ce ar putea duce la un total mai sczut al cheltuielilor,
avnd ca rezultat o economie de scal. Bugetul combinat poate fi utilizat
pentru achiziionarea unei configuraii a sistemului mai adecvate cerinelor i
necesitilor organizaiei respective. Aceasta ar putea consta ntr-un
calculator cu o configuraie mai bun, cu o putere de calcul sporit sau ntr-o
reea de calculatoare mai mici.
9.Echilibrul ntre cerinele aflate n conflict
Fiecare utilizator sau departament are propriile sale cerine, care ar
putea intra n conflict cu ale altora. Din moment ce baza de date se afl sub
controlul administratorului bazei de date, acesta poate lua decizii privind
proiectarea i utilizarea operaional a acesteia, care s duc la folosirea
optim a resurselor pentru organizaia luat n ansamblu. Aceste decizii vor
realiza performane optime ale aplicaiilor majore, posibil n detrimentul celor
mai puin importante.
10.mbuntirea accesibilitii datelor i capacitii de rspuns
Ca rezultat al integrrii, datele care depesc graniele unui
departament sunt direct accesibile utilizatorilor finali. Aceasta creeaz un
sistem cu o mult mai mare funcionalitate potenial dect ar putea fi folosit,
de exemplu, pentru furnizarea unor servicii mai bune utilizatorului final sau
clienilor organizaiei. Multe SGBD-uri ofer limbaje de interogare sau
generatoare de rapoarte, care permit utilizatorilor s formuleze ntrebri adhoc i s obin aproape imediat afiarea informaiilor cerute la terminal, fr
a fi nevoie de un programator care s scrie un program de extragere a
acestora din baza de date. De exemplu, un manager de filial ar putea lista
toate apartamentele cu o chirie lunar de peste 400 euro, prin simpla scriere
a urmtoarei comenzi SQL la un terminal:
31

SELECT*
FROM proprietate_de_inchiriat
WHERE type = 'Apartament' AND chirie> 400;
11.Productivitate crescut
Aa cum am menionat anterior, un SGBD ofer multe dintre funciile
standard, pe care ar trebui s le scrie n mod normal programatorul, n cazul
unei aplicaii bazate pe fiiere. La nivel fundamental, SGBD-ul ofer toate
rutinele de nivel jos pentru manevrarea fiierelor, tipice n programele
aplicaie. Furnizarea acestor funcii permite programatorului s se
concentreze mai mult asupra funcionalitii specifice cerute de ctre
utilizatori, fr ns a se preocupa de detaliile de nivel jos privind
implementarea. Multe sisteme SGBD furnizeaz i un mediu din a patra
generaie, care const n instrumente de simplificare a dezvoltrii de aplicaii
n domeniul bazelor de date. Aceasta are ca rezultat o productivitate crescut
a programatorului i un timp redus de programare (mpreun cu reducerea
corespunztoare a costurilor).
12.ntreinere mbuntit datorit independenei datelor
Descrierile datelor i logicii de accesare a lor n cadrul sistemelor
bazate pe fiiere erau ncorporate n fiecare program aplicaie, ceea ce fcea
ca acestea s depind de date. O modificare n structura datelor (de exemplu,
atribuirea a 50 de caractere n loc de 40 pentru adres sau schimbarea
modului de stocare a datelor pe suport fizic) poate necesita schimbri
importante n programele afectate de modificrile produse. Prin contrast, ntrun SGBD, descrierile datelor sunt separate de aplicaii, ceea ce face ca
acestea s fie imune la modificrile din descrierea datelor. Aceast
caracteristic este cunoscut sub denumirea de independen fa de date
(sau independena datelor). Realizarea independenei datelor simplific
substanial ntreinerea aplicaiilor din baza de date.
13.Concuren mbuntit
Majoritatea sistemelor bazate pe fiiere se confruntau adesea cu o
problem important, cu influene negative asupra ceea ce nseamn
gestionarea eficient a coninutului unui baze de date. Astfel, dac doi sau
mai muli utilizatori aveau permisiunea de a accesa simultan acelai fiier, se
ntmpla ca cele dou accesri s se suprapun, ceea ce avea evident ca
rezultat pierderea informaiilor sau chiar alterarea integritii datelor
respective. n ceea ce privete un SGBD, una dintre sarcinile importante
care-i revin acestuia se refer la administrarea accesului concurent la baza
de date, fapt care are drept consecin garania evitrii apariiei unor astfel
de probleme.
14.mbuntirea serviciilor de salvare de siguran i refacere
Multe sisteme bazate pe fiiere las n sarcina utilizatorului
responsabilitatea de a lua msuri de protecie a datelor, n cazul unor
defeciuni ale sistemului de calculatoare sau ale programului aplicaie.
32

Aceasta ar putea presupune realizarea unei copii de siguran a datelor la
intervale scurte de timp (spre exemplu, n fiecare zi). Apariia unei defeciuni
la un moment dat, va avea drept consecin preluarea ultimei copii de
siguran, precum i reluarea muncii realizate n intervalul de timp scurs de la
ultima salvare realizat. Spre deosebire de acestea, SGBD-urile moderne
ofer faciliti de minimizare a pierderilor (aferente prelucrrilor realizate) ca
urmare a unei defeciuni.
Dezavantaje SGBD-urilor
Pe lng avantajele menionate anterior, fiecare SGBD comport i un
numr de dezavantaje, iar cele mai importante sunt menionate n continuare.
1.Complexitatea
Proiectarea funcionalitii unui SGBD optim face ca acesta s devin
un element software extrem de complex. Proiectanii i dezvoltatorii bazelor
de date, administratorii de date i de baze de date, precum i utilizatorii finali
trebuie s cunoasc (uneori, chiar n detaliu) aceast funcionalitate, pentru a
putea profita de ea la maximum. Eecul n nelegerea sistemului poate
cauza fundamentarea i luarea unor decizii greite aferente etapei de
proiectare, care, n mod cert, pot conduce la consecine negative importante
pentru fiecare organizaie sau instituie specializat care dispune de un astfel
de sistem.
2.Costul
Costul unui SGBD variaz semnificativ, n funcie de mediu i de
funcionalitatea pe care o ofer. De exemplu, un SGBD cu un singur utilizator,
pentru un calculator personal, poate costa numai 100 euro. Cu toate acestea,
un SGBD mainframe, multi-utilizator, care deservete sute de utilizatori,
poate fi extrem de scump. Mai exist i cheltuielile periodice anuale de
ntreinere care reprezint, de regul, un procent din preul acestuia. n acest
caz, este clar c vom alege un SGBD pentru gestionarea unei activiti
numai n concordan cu necesitile curente: nu are sens s achiziionm un
SGBD scump dac nevoia nu o cere, ns nu recomandm nici
achiziionarea unui SGBD ieftin atunci cnd volumul de date, dar i cel al
prelucrrilor de realizat este mare (mai ales n cazul gestionrii datelor la
nivelul bazelor de date distribuite14).
3.Costurile adiionale specifice componentelor hardware
Cerinele de stocare pe suport fizic pentru un SGBD i baza de date ar
putea necesita achiziionarea unui spaiu de stocare suplimentar. Mai mult,
pentru obinerea performanelor dorite, ar putea fi necesar cumprarea unui
calculator mai performant, poate chiar unul destinat rulrii SGBD-ului. Astfel,
14
Baza de date distribuit reprezint un set de baze de date aflate pe mai multe calculatoare
i care este vzut de ctre aplicaie ca fiind o singur baz de date (aflat pe un singur
calculator) adic baza de date vzut de ctre aplicaie este fragmentat i mprit pe
mai multe calculatoare din reea. O baz de date se spune c este distribuit dac diferitele
componente ale acesteia sunt memorate n staiile i/sau serverul reelei.
33

este clar c achiziionarea de componente hardware adiionale conduce la
creterea cheltuielilor.
4.Costul conversiei
n unele cazuri, costul unui SGBD i al componentelor hardware
adiionale poate fi nesemnificativ, comparativ cu costul conversiei aplicaiilor
existente, necesare ca acestea s poat funciona n noul SGBD i n noua
configuraie hardware. Acest cost include i preul instruirii personalului
pentru a putea utiliza noile sisteme i, posibil, angajarea unui personal
specializat, care s ajute la conversia i funcionarea sistemului. Aceste
cheltuieli reprezint unul dintre motivele principale pentru care unele
organizaii se mpiedic de sistemele existente i nu pot trece la tehnologia
modern specific bazelor de date. Termenul de sistem motenit este utilizat
uneori pentru a se face referire la un sistem mai vechi, de obicei inferior din
punct de vedere al funcionalitii.
Totodat, exist i situaii n care anumite organizaii renun la
actualizarea permanent a componentelor hardware, determinate de
conversiile realizate la nivel software n detrimentul achiziionrii unui produs
software nou i care este n concordan cu necesitile cerute. ns, aceast
soluie este una important, cu implicaii directe asupra cheltuielilor realizate,
dar i a modului de lucru specific personalului de care se dispune la un
moment dat.
5.Dimensiunea
Complexitatea i extinderea funcionalitii fac din SGBD-uri elemente
software destul de cuprinztoare, ce ocup mult spaiu pe suportul fizic i
necesit o memorie15 substanial pentru a funciona eficient i corect.
6.Performana
De obicei, un sistem bazat pe fiiere este realizat pentru o anumit
aplicaie, cum ar fi facturarea. Ca rezultat, performanele sunt, de regul,
foarte bune. Totui, SGBD-ul este creat pentru a fi mai general, pentru a oferi
mai multe funcionaliti, nu una singur. Rezultatul este c unele aplicaii ar
putea s nu mai funcioneze tot att de rapid sau la fel de eficient.
7.Impactul crescut al unei defeciuni
Centralizarea resurselor mrete vulnerabilitatea sistemului. Din
moment ce toi utilizatorii i toate aplicaiile se bazeaz pe disponibilitate din
partea SGBD-ului, eecul oricrei componente a acestuia poate duce la
sistarea tuturor operaiilor.
15
Evident, ne referim la memoria RAM (Random Access Memory) a calculatorului pe care

se gsete i ruleaz SGBD-ul respectiv.
34

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;
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)16;
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
utilizatorului.
asisten
on-line
pentru
autodocumentarea
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
16
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.
35

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.
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 datelor17.
17
n literatur ntlnim frecvent i Limbaj de Manevrare a Datelor
36

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 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:
37
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.
Administratorul bazei de date este un utilizator special i are un rol
hotrtor n ceea ce privete funcionarea optim a ntregului sistem. Datorit
importanei acestei categorii de utilizatori, SGBD-ul are o funcie distinct n
acest sens.
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 CASE18, 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.).
18
Instrumentele CASE (Computer Aided Software Engineering) sunt aplicaii informatice, formate din
mai multe componente, care ajut la realizarea unui proiect software, n anumite etape (sau n toate
etapele) din ciclul de via al unei aplicaii. Obiectivul principal al instrumentelor CASE const n
punerea n practic a produselorprogram de proiectare i realizarea softwarelui cu ajutorul
calculatorului. Instrumentele oferite de CASE sunt utilizabile din faza de definire a cerinelor pn la
ntreinerea fizic a produsului informatic [Oprea, 1999, p.123].
38

Pentru fiecare din activitile menionate mai sus, SGBD-ul ofer
instrumente i tehnici de lucru.
n cazul lucrului n reea, cu baze de date distribuite, SGBD-ul are
dezvoltate foarte mult componentele destinate administratorului. Acest lucru
este determinat de faptul c baza de date este, n acest caz, de mare
complexitate, datele sunt distribuite pe calculatoarele reelei, iar utilizatorii
sunt de toate tipurile i n numr mare.
39

1. Ce este SGBD-ul?
2. Care este diferena dintre limbajele procedurle i cele neprocedurale?
3. Ce reprezint coerena datelor?
4. Ce reprezint partajarea datelor?
5. Cum se poate realiza securitatea datelor la nivelul unui SGBD?
6. La ce se refer costul conversiei?
7. Prezentai pe scurt componentele unui SGBD.
8. Ce este motorul SGBD?
9. Prezentai principale caracteristici ale subsistemului instrumentelor de
proiectare.
10. Prezentai principale caracteristici ale subsistemului de execuie.
Teste gril
1. SGBD-ul reprezint o interfa ntre:
a. sistemul de operare i alt SGBD;
b. dou sau mai multe SGBD-uri, dac ele se gsesc pe platforme
diferite;
c. utilizatori i sistemul de operare;
d. dou sisteme de operare care ruleaz pe platforme diferite.
2. SGBD-urile relaionale sunt denumite SGBD-uri din:
a. I-a generaie;
b. a II-a generaie;
c. a III-a generaie;
d. a IV-a generaie.
3. Un SGBD permite:
a. doar actualizarea datelor din baza de date;
b. doar extragerea datelor prin intermediul limbajului de descriere
a datelor;
c. doar extragerea datelor
manipulare a datelor;
prin
intermediul
limbajului
de
d. actualizarea datelor i extragerea lor prin intermediul limbajului

de manipulare a datelor.
40

4. Principala deosebire ntre limbajele procedurale i cele neprocedurale
const n faptul c:
a. limbajele procedurale trateaz datele unei baze de date
nregistrare cu nregistrare, n timp ce cele neprocedurale
lucreaz cu seturi de nregistrri;
b. limbajele neprocedurale trateaz datele unei baze de date
nregistrare cu nregistrare, n timp ce cele procedurale
lucreaz cu seturi de nregistrri;
c. limbajele neprocedurale se bazeaz pe limbajele de descriere a
datelor, n timp ce cele procedurale lucreaz cu limbajele de
d. limbajele procedurale se bazeaz pe limbajele de descriere a
datelor, n timp ce cele neprocedurale lucreaz cu limbajele de
5. Costul conversiei, ca dezavantaj al SGBD-ului, se refer la:
a. conversia unui SGBD ntr-un sistem bazat pe fiiere;
b. conversia componentelor hardware n unele mai performante;
c. conversia aplicaiilor existente la un moment dat ntr-o
organizaie;
d. conversia unei componente hardware n una software.
6. Motorul SGBD este componenta care:
a. permite proiectarea i generarea bazei de date i a aplicaiilor
care descriu modul de utilizare a bazei de date;
b. are rolul de a asigura accesul fizic la datele bazei de date;
c. permite execuia aplicaiilor sau cererilor de consultare a bazei
de date;
d. permite definirea structurii tabelelor din baza de date.
7. Subsistemul instrumentelor de proiectare nu poate include:
a. limbaje de descriere a datelor;
b. limbaje de manevrare a datelor;
c. limbaje de programare;
d. limbaje de interogare a datelor.
8. Subsistemul instrumentelor de proiectare nu permite definirea:
a. structurii tabelelor din baza de date;
b. machetelor de interfa cu utilizatorul;
c. accesului fizic la datele bazei de date;
d. formatului rapoartelor i cererilor de interogare a bazei de date.
41

9. n etapa de exploatare a bazei de date, administratorul:
a. poate autoriza accesul la datele bazei de date;
b. poate permite modificarea structurii logice a bazei de date;
c. poate crea conturi de acces la baza de date;
d. nu poate reface baza de date n cazul unor incidente.
10. Subsistemul de execuie al SGBD-ului este componenta care:
a. permite proiectarea i generarea bazei de date i a aplicaiilor
care descriu modul de utilizare a bazei de date;
b. are rolul de a asigura accesul fizic la datele bazei de date;
c. permite execuia aplicaiilor sau cererilor de consultare a bazei
de date;
d. permite definirea structurii tabelelor din baza de date.
42
Abordarea relaional a bazelor de date
Capitolul IV Abordarea relaional a bazelor de date
****************************************************************************************
Principalul obiectiv al capitolului IV este acela de a oferi o viziune general
asupra relaionrii datelor dintr-o baz de date. Astfel, n acest capitol am
urmrit:
prezentarea regulilor lui Codd pe care se bazeaz ntreaga abordare
relaional;
identificarea
relaional;
prezentarea
fundamentelor
specifice
modelului
definirea tipurilor de chei ntlnite la nivelul unei relaii;
definirea tipurilor de legturi dintre relaii; nelegerea mecanismului

cheii strine;
prezentarea principalilor operatori ai algebrei relaionale.
****************************************************************************************
Aa cum reiese din literaura de specialitate, au existat n timp mai
multe modele de reprezentare a informaiilor la nivel logic i de operare:
reea;
ierarhic;
relaional.
n cadrul acestui capitol vom analiza detaliat cel mai utilizat model de
reprezentare, utilizat n prezent pe scar larg, i anume modelul relaional.
Regulile lui Codd

Pentru a fi considerat relaional, fiecare sistem de gestiune a bazelor
de date trebuie s respecte nite reguli, ntlnite n literatur sub numele de
regulile lui Codd. Modelul de stocare a datelor sub forma unei baze de date
relaionale s-a dezvoltat pornind de la un articol aprut n anul 1970, A
relational Model of Data for Large Shared Data Banks, i care aparine
cercettorului Codd [Codd, 1970, p.377-387]. Astfel, regulile enunate de
cercettor sunt prezentate n continuare:
43

R0 Gestionarea datelor la nivel de relaie.
Toate informaiile din baza de date sunt gestionate numai prin mecanisme
relaionale. Rezult c SGBD-ul trebuie s-i ndeplineac toate funciile
utiliznd ca unitate de informaie mulimea, cu alte cuvinte, s utilizeze
diferite limbaje, aa cum este i SQL, care s opereze la un moment dat pe o
relaie.
R1 Reprezentarea logic a datelor.
Informaiile bazei de date relaionale vor fi reprezentate n mod explicit la
nivel logic ntr-un singur mod i anume ca valori n tabelele de date. Rezult
c toate datele ar trebui s fie memorate i prelucrate n manier identic.
Informaiile referitoare la numele tabelelor, al coloanelor, domeniilor,
definiiilor tabelelor virtuale, al restriciilor de integritate trebuie s fie
memorate tot n tabelele de date.
R2 Garantarea accesului la date
Accesarea tuturor informaiilor bazei de date se va realiza prin specificarea
numelui tabelei respective, a valorii cheii primare, precum i a numelui de
coloan.
R3 Regula aferent valorii NULL
Un SGBD trebuie s permit declararea i utilizarea valorii NULL, cu
semnificaia unor date lips sau care nu pot fi aplicate. Valorile NULL (care
sunt diferite de irurile de caractere spaiu sau de cele vide) sunt importante
pentru implementarea restriciilor de integritate (integritatea entitii i
integritatea referenial) aferente modelului relaional.
R4 Regula specific metadatelor
Informaiile referitoare la descrierea bazei de date metadatele trebuie
specificate la nivel logic n manier identic cu descrierea datelor propriuzise. Practic, utilizatorul va aplica asupra descrierii bazei de date aceleai
operaii ca i la datele obinuite. Sistemul nu trebuie s fac diferene ntre
descrierea datelor i a metadatelor utiliznd o singur structur, i anume
cea relaional.
R5 Faciliti ale limbajelor utilizate
Un sistem relaional trebuie s fac posibil utilizarea mai multor limbaje, n
diferite moduri. Trebuie s existe cel puin un limbaj de nivel nalt ale crui
instruciuni s poat exprima oricare din urmtoarele operaii: definirea
tabelelor, a tabelelor virtuale, manevrarea datelor, definirea tuturor restriciilor
de integritate, garantarea i autorizarea accesului la date, precum i
prezentarea limitelor tranzaciilor.
R6 Actualizarea bazei de date
Fiecare SGBD trebuie s permit manipularea unei tabele (de baz sau
virtual), att n cazul actualizrii datelor n baza de date, ct i pentru
operaii de regsire a acestora. n cazul unei operaii care va modifica
coninutul unei baze de date, trebuie s se lucreze la un moment dat pe o
relaie ntreag.
44

R7 Independena fizic a datelor
Programele de aplicaie nu trebuie s fie afectate de modificrile realizate n
modul de reprezentare a datelor sau n metodele de acces. O schimbare a
structurii fizice a datelor nu trebuie s blocheze funcionarea programelor de
aplicaie.
R8 Independena logic a datelor
Programele de aplicaie nu trebuie s fie afectate de modificrile efectuate
asupra relaiilor care formeaz baza de date.
R9 Regula aferent restriciilor de integritate
Toate restriciile de integritate trebuie s poat fi definite prin intermediul
limbajului folosit de SGBD pentru definirea datelor i s fie memorate.
R10 Distribuirea geografic a datelor
n cazul n care datele sunt distribuite, programele de aplicaie s fie logic
aceleai cu cele utilizate n cazul n care datele sunt fizic centralizate. Practic,
n aceast situaie, utilizatorul ar trebui s perceap aceste date ca fiind
centralizate i nu aparinnd unor staii diferite de lucru, aflate n zone
geografice diferite.
R11 Actualizarea tabelelor virtuale
n cadrul abordrii relaionale, nu toate atributele sunt actualizabile, ceea ce
nseamn c nu toate tabelele virtuale pot fi actualizate.
R12 Prelucrarea datelor la nivel de baz
Dac SGBD-ul posed un limbaj de baz de nivel sczut orientat pe
prelucrarea tuplurilor i nu pe cea a relaiilor, atunci acest limbaj nu trebuie
folosit pentru a se evita restriciile de integritate sau restriciile introduse prin
utilizarea limbajelor relaionale de nivel nalt.
Fundamente ale modelului relaional

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:
45
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 )
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.
46

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
1701212120139
2731210176143
1801009129145
nr_matr
1234
1987
4432
nume
Popa
Darie
Popa
pren
Dan
Dan
Ion
facult
FSE
FD
FSE
spec )
IE
AP
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
47

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
1701212120139
2731210176143
2731210176143
nr_matr
1234
1987
5634
nume
Popa
Darie
Darie
pren
Dan
Dan
Dan
facult
FSE
FD
FSE
spec )
IE
AP
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
1701212120139
?
nr_matr
1234
1234
nume
Popa
?
pren
Dan
?
facult
FSE
?
spec )
IE
?
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
48
cnp
1701212120139
1701212120139
nr_matr
1234
1234
nume
Popa
Popa
pren
Dan
Dan
facult
FSE
FSE
spec )
IE
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 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 facultate19.
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:
19
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 (la pagina 18 au
fost prezentate succint cteva aspecte de baz specifice normalizrii). Pentru cei interesai s tie mai
multe despre procesul de normalizare i postnormalizare, recomandm cartea profesorului M. Fotache:
Proiectarea bazelor de date: Normalizare i postnormalizare. Implementri SQL i Oracle.
49

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).
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.
50

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
Legitimaie
( cnp
nume
pren localitate )
1701212120139
2711010120121
1721209145123
Popa
Darie
Preda
Dan
Alina
Marin
( nr_leg
valabilitate )
12121
23456
187654
2
2
3
Galai
Brila
Galai
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.
51

Exemplul 4.10:
( cnp
nume
pren
1701212120139
2711010120121
1721209145123
Popa
Darie
Preda
Dan
Alina
Marin
( nr_leg
valabilitate
cnp )
12121
23456
187654
2
2
3
2711010120121
1701212120139
1721209145123
Client
Legitimaie
localitate nr_leg )
Galai
Brila
Galai
23456
12121
187654
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
2222
3333
1701212120139
2711010120121
1721209145123
Popa
Darie
Preda
Dan
Alina
Marin
spec
form_nv )
CIG
FB
FB
ZI
ZI
IFR
Specializare ( cod_spec
61
51
52
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
52

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
2222
3333
1701212120139
2711010120121
1721209145123
Popa
Darie
Preda
Dan
Alina
Marin
spec
form_nv )
CIG
FB
FB
ZI
ZI
IFR
61
51
52
61
52
61
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:
53

Exemplul 4.13:
Factur
Produs
val_fact data_fact )
( serie_fact
nr_fact
DX
VR
DF
1111
2222
3333
100
200
300
10.10.2008
10.10.2008
12.10.2008
( cod_produs
den_prod
um
stoc )
11
22
33
Telefon Nokia
TV Samsung
Laptop Asus
Buc
Buc
Buc
0
2
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
DX
DF
1111
1111
3333
11
33
11
10
15
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).
54

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.
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
222
333
Preda
Darie
Ionescu
Marin
Alina
Ctlin
Facultate
Specializare
( facult
profil )
tiine Economice
Drept
Economic
Administrativ
( cod_spec
Spec
form_nv
751
752
662
FB
FB
AP
ZI
IFR
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
111
222
333
facult
cod_spec )
tiine Economice
Drept
tiine Economice
751
662
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
55

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 [Riccardo, 2001, p.54].
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, 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 B20, 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
111
222
333
nume
Preda
Darie
Ionescu
pren )
Marin
Alina
Ctlin
pren )
Stud2 ( nr_matr
nume
444
Manea
Oana
333
Ionescu Ctlin
555
Dragomir Alina
Stud1 Stud2 =
20
pren )
( nr_matr
Nume
111
Preda
Marin
222
Darie
Alina
333
Ionescu Ctlin
444
Manea
Oana
555
Dragomir Alina
Relaiile A i B trebuie s aib aceeai schem definit pe aceleai domenii.
56

2. Diferena. Diferena a dou relaii A i B21, 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)22.

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
111
222
333
pren )
Marin
Alina
Ctlin
nume
Preda
Darie
Ionescu
tip_disc )
Disciplin ( cod_disc
denumire
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
21
22
( nr_matr
nume
pren
cod_disc
denumire
tip_disc )
111
111
111
222
222
222
333
333
333
Preda
Preda
Preda
Darie
Darie
Darie
Ionescu
Ionescu
Ionescu
Marin
Marin
Marin
Alina
Alina
Alina
Ctlin
Ctlin
Ctlin
SE1
SE2
SE3
SE1
SE2
SE3
SE1
SE2
SE3
Informatic
Informatic
Contabilitate
Informatic
Informatic
Contabilitate
Informatic
Informatic
Contabilitate
curs
laborator
seminar
curs
laborator
seminar
curs
laborator
seminar

Schemele relaiilor A i B sunt diferite, dar pot exista atribute comune.
57

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
2222
3333
Popa Dan
Darie Alina
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
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
2222
3333
pren
Darie Alina
Preda Marin
media )
8.00
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
58

unor rspunsuri mai rapide. Dintre operaiile derivate utilizate mai frecvent
amintim:
6. Intersecia. Intersecia a dou relaii A i B23, 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
111
222
333
nume
Preda
Darie
Ionescu
pren )
Marin
Alina
Ctlin
pren )
Stud2 ( nr_matr
nume
444
Manea
Oana
333
Ionescu Ctlin
555
Dragomir Alina
Stud1 Stud2 =
pren )
( nr_matr nume
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 relaii24 i se noteaz A | X | B . Rezultatul uniunii va fi o relaie de
c
aritate a+b, cu schema dat de reuniunea 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-uniunedreapta. n continuare vom exemplifica uniunea i echiuniunea.
23
24

n cazul uniunii, cele dou atribute trebuie s fie cte unul din fiecare relaie.
59

Exemplul 4.22 Fie urmtoarele relaii:
Aprov
( s_fact
DX
DX
JZ
cod_prod cant_a )
P1
20
P2
10
P3
15
nr_fact
1122
1122
2233
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
DX
DX
DX
JZ
60
1122
1122
1122
1122
2233
P1
P2
P2
P2
P3
20
10
10
10
15
C1
C1
C2
C3
C1
20
20
12
10
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:
Exemplul 4.23: Echiuniunea relaiilor Aprov i Comand.
Aprov | X | Comand=
( s_fact
nr_fact
cod_prod
cant_a
cod_cmd
cant_c )
DX
DX
1122
1122
P1
P2
20
10
C1
C3
20
10
cant _ a =
cant _ c
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
Disc
( nr_matr
111
222
333
nume
Popa
Darie
Moga
pren )
Dan
Alin
Dana
( 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
111
111
111
222
222
222
333
333
333
Popa
Popa
Popa
Darie
Darie
Darie
Moga
Moga
Moga
pren den_disc d.nr_matr not )

Dan
Finane
333
9
Dan
Birotic
222
10
Dan
Birotic
333
8
Alin
Finane
333
9
Alin
Birotic
222
10
Alin
Birotic
333
8
Dana Finane
333
9
Dana Birotic
222
10
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:
61
Student .nr _ matr = Disc.nr _ matr ( Student X Disc) =

( s.nr_matr
222
333
333
nume
Darie
Moga
Moga
pren
Alin
Dana
Dana
den_disc
Birotic
Finane
Birotic
d.nr_matr
222
333
333
not )
10
9
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:
| Student X Disc |= (nr_matr nume
222
333
333
Darie
Moga
Moga
pren
Alin
Dana
Dana
den_disc
Birotic
Finane
Birotic
not )
10
9
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
111
222
333
333
nume pren den_disc not )

Popa Dan
NULL
NULL
Darie Alin
Birotic
10
Moga Dana Finane
9
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
62

vor fi adugate uniunii naturale doar tuplurile relaiei din dreapta (exemplul
2.26).
Exemplul 4.25
Student | Disc = (nr_matr
111
222
333
333

Popa Dan
NULL
NULL
Darie Alin
Birotic
10
Moga Dana Finane
9
Moga Dana Birotic
8
Exemplul 4.26
Student | Disc = (nr_matr
222
333
333

Darie Alin
Birotic
10
Moga Dana Finane
9
Moga Dana Birotic
8
n exemplul 4.26, uniunea extern dreapta este identic cu uniunea

natural deoarece nu exist tupluri n relaia din dreapta (relaia Disc n cazul
nostru) care s nu aib corespondent n cealalt relaie.
Probleme rezolvate
1. Mai multe societi comercializeaz pe baz de factur diferite
produse. Folosind abordarea relaionl, s se pun n eviden
emitentul i coninutul fiecrei facturi.
Pentru a soluiona problema propus anterior, va trebui s parcurgem
urmtoarele etape:
a) identificarea atributelor care reies din contextul problemei;
b) definirea relaiilor pe baza atributelor identificate la punctul a);
c) crearea legturilor dintre relaiile identificate la punctul b).
a) Pentru a avea garania unei rezolvri corecte a unei probleme, va
trebui ca nainte de a identifica atributele s rspundem la urmtoarea
ntrebare: Pentru problema dat, avem nevoie de atribute pentru cine, sau
pentru ce? Astfel, pentru problema noastr, dac ncercm s rspundem la
aceast ntrebare, vom constata c va trebui s identificm atribute despre
societi, produse i facturi. Cu alte cuvinte, aceste colecii pe care le-am
identificat acum vor reprezenta relaiile pe care le vom defini la punctul b).
Dup ce am identificat aceste colecii, va trebui s descriem minim
dou atribute care caracterizeaz fiecare din aceste colecii de date. Este
important ca atunci cnd identificm atributele, s avem n vedere c fiecare
relaie are n mod obligatoriu o cheie primar, ceea ce nseamn c va trebui
63

s ne gndim nc de la acest pas care va fi atributul sau atributele care vor
avea rolul de a identifica n mod unic fiecare tuplu al relaiilor de la punctul b).
Astfel, n cazul nostru, putem considera c referitor la o societate ne va
interesa codul unic de identificare al acesteia (care este unic pentru toate
societile descrise) i denumirea ei. n ceea ce privete produsul, dac ne
gndim la un atribut care s identifice unic fiecare produs, atunci acesta
poate fi cod_produs, pentru care introducem o semantic suplimentar i
spunem c nu pot exista dou produse care s aib acelai cod. De
asemenea, tot referitor la un produs considerm c ne mai intereseaz
denumirea acestuia, unitatea de msur i eventual cantitatea care exist n
stoc la un moment dat.
n ceea ce privete factura, tim cu toii c aceasta se identific printro serie i un numr i c fiecare factur are o valoare i o dat a emiterii.
Referitor la seria i numrul facturii, trebuie s precizm faptul c, numai
luate mpreun, cele dou atribute vor putea identifica unic fiecare factur25.
Totodat, dac analizm cu atenie cerina problemei, vom constata
c mai avem nevoie de un atribut, astfel nct s putem evidenia coninutul
fiecrei facturi. Practic, prin coninutul fiecrei facturi nelegem c trebuie s
punem n eviden produsele care se gsesc pe fiecare factur primit de
societile gestionate i cantitile aferente; cu alte cuvinte, atributul de care
vom avea nevoie se va referi la cantitatea aprovizionat dintr-un produs pe o
factur.
Astfel sintetiznd cele menionate anterior, la punctul a) vom avea
urmtoarele atribute (pentru claritate, n dreptul fiecrui atribut vom meniona
i semantica corespunztoare):
cui codul unic de identificare al fiecrei societi;
den_s denumirea societii;
cod_prod codul fiecrui produs; se presupune c nu exist dou

produse gestionate care s aib acelai cod;
den_prod denumirea produsului gestionat;
um unitatea de msur specific fiecrui produs;
cant cantitatea (aferent unui produs) care se gsete n stoc la un

moment dat;
serie seria unei facturi;
nr numrul facturii;
val valoarea unei facturi;
data data emiterii facturii;
cant_aprov cantitatea aferent unui produs aprovizionat prin

intermediul unei facturi. Referitor la acest atribut, menionm faptul c vom
avea o realizare a acestuia numai atunci cnd este emis o factur pe care
se gsete un produs gestionat. Altfel spus, ca s dispunem de o realizare a
acestui atribut va trebui s existe att factura ct i produsul.
25
Aceast regul este ntlnit n literatur sub numele de regula entitii i menioneaz
faptul c toate atributele care formeaz cheia primar trebuie s primeasc valori.
64

b) Dup identificarea atributelor, va trebui s definim relaiile din cadrul
crora ele vor face parte. Astfel, vom avea urmtoarele relaii (pentru fiecare
relaie, vom descrie i trei tupluri care s ne ajute la identificarea corect a
cheilor primare ale relaiilor):
Societate
den_s )
( cui
R111111 Rione SRL
R222222 Selena SRL
R333333 Select SRL
Produs ( cod_prod
um cant )
den_prod
11
Telefon Nokia
B
2
22
Telefon Samsung B
3
33
Laptop Dell
B
0
data )
Factur ( serie
val
nr
DX
1111 2000 10.11.2008
DX
2222 8500 10.11.2008
JW
1111 6500 11.11.2008
c) La acest pas va trebui s soluionm dou cerine. Prima se refer la
punerea n eviden a emitentului fiecrei facturi. Pentru aceasta, vom asocia
relaiile Societate i Factur. Aa cum am menionat n subcapitolul n care
am descris legturile dintre relaii, pentru a identifica tipul legturii va trebui
s vedem rolul fiecrei relaii n cadrul modelului: fiu sau printe. Analiznd
cele dou relaii, observm c Societate este relaie printe deoarece fiecare
societate poate primi una sau mai multe facturi, n timp ce Factur este
relaie fiu deoarece o factur nu poate fi emis dect unei singure societi
(reamintim c o relaie este considerat fiu atunci cnd unui tuplu din acea
relaie i va corespunde un singur tuplu n relaia cu care s-a asociat i este
printe atunci cnd i vor corespunde mai multe tupluri).
Astfel, legtura este de tipul 1-n (unu la mai muli), ceea ce nseamn
c atributele care formeaz cheia primar n relaia printe vor migra sub
forma cheii strine n relaia fiu: atributul cui din relaia Societate va migra
sub forma cheii strine n relaia Factur.
A doua cerin este cea prin care ni se cere s punem n eviden
coninutul fiecrei facturi. n acest caz, vom asocia relaiile Factur i Produs.
Aa cum am procedat anterior, i n acest caz va trebui s identificm iniial
tipul relaiilor pentru a determina tipul legturii. Astfel, legtura este de tipul
n-n (mai muli la mai muli) deoarece ambele relaii sunt printe: fiecare
factur poate conine unul sau mai multe produse, n timp ce un produs
poate fi aprovizionat prin intermediul uneia sau a mai multor facturi. Conform
regulii menionate, legtura se va realiza prin generarea unei noi relaii care
va avea cheia primar format din cheile primare ale celor dou relaii
asociate. De asemenea, aceast nou relaie va include i atributul
cant_aprov care ne va permite s punem n eviden cantitatea aprovizionat
dintr-un produs pe o factur.
65

Dup crearea acestor legturi, modelul relaional va artat astfel:
Societate
den_s )
( cui
R111111 Rione SRL
R222222 Selena SRL
R333333 Select SRL
Produs ( cod_prod
um cant )
den_prod
11
Telefon Nokia
B
2
22
Telefon Samsung B
3
33
Laptop Dell
B
0
Factur ( serie
val
cui )
nr
data
DX
1111 2000 10.11.2008 R222222
DX
2222 8500 10.11.2008 R333333
JW
1111 6500 11.11.2008 R222222
cod_prod cant_aprov )
Coninut_factur ( serie
nr
DX
1111
11
10
DX
1111
33
15
JW
1111
11
20
Astfel, prin intermediul atributului cheie strin cui din relaia Factur
putem s punem n eviden care este emitentul fiecrei facturi (ce societate
a emis o factur). Spre exemplu, dac dorim s aflm cine a emis factura DX
2222, vom identifica n cadrul relaiei Factur care este tuplul care are ca
realizare a atributelor serie i nr valorile DX (pentru serie), respectiv 2222
(pentru nr). Apoi, dup identificarea tuplului, vom prelua valoarea cheii
strine (n cazul nostru, R333333) i vom cuta aceast valoare pe domeniul
de valori aferent atributului care este cheie primar n relaia din care a
migrat. Pentru exemplul nostru, vom merge n relaia Societate i pe
domeniul cheii primare vom cuta acel tuplu pentru care valoarea atributului
cui este R333333. n acest fel vom constata c factura DX 2222 este emis
de Select SRL.
Coninutul fiecrei facturi este evideniat prin intermediul relaiei
Coninut_factur. n acest fel constatm c produsul Telefon Nokia este
achiziionat prin intermediul a dou facturi (DX 1111 i JW 1111), iar
cantitatea aprovizionat este de 10, respectiv 20 uniti. Totodat, prin
intermediul acestei noi relaii am pus n eviden faptul c o factur poate
conine mai multe produse (factura cu seria i numrul DX 1111 conine
produsele cu codurile 11 i 33), dar i faptul c un produs se poate gsi pe
mai multe facturi (produsul cu codul 11 se gsete att pe factura cu seria i
numrul DX 1111 ct i pe JW 1111), ceea ce argumenteaz legtura de
tipul mai muli la mai muli.
De asemenea, n cadrul relaiei Factur se argumenteaz i regula
entitii. Astfel, putem observa c n cazul n care unul din cele dou atribute
care formeaz cheia primar nu are valoare, atunci exist posibilitatea ca pe
66

domeniul de valori respectiv s avem valori duplicate, ceea ce nseamn c
nu mai poate ndeplini rolul de cheie primar a relaiei. Spre exemplu, dac
vom da valori numai atributului serie, atunci vom ajunge n situaia n care
avem dou valori duplicate pe domeniul respectiv de valori, ceea ce nu ar fi
permis. Deci, trebuie s nu omitem s dm valori tuturor atributelor care
formeaz cheia primar a unei relaii.
2. Fie descrierea studenilor unei faculti care studiaz diferite
discipline n funcie de specializarea fiecruia. S se pun n eviden
specializarea de care aparine fiecare student, precum i disciplinele
studiate de acetia.
a) Pentru problema menionat anterior, va trebui s identificm atribute
despre student, specializare i disciplin. Dei poate am fi tentai s credem
c am avea nevoie i de atribute despre facultate, nu este aa, deoarece, n
cazul n care am avea relaia facultate, aceasta ar avea un singur tuplu i nu
se justific generarea unei relaii care s aib o singur realizare. Astfel,
pentru problema dat, am putea identifica urmtoarele atribute:
nr_matr numrul matricol al studentului;
nume numele studentului;
pren prenumele unui student;
cod_spec codul unei specializri care aparine unei faculti; vom

presupune c nu exist dou faculti care s aib acelai cod;
den_spec denumirea specializrii;
cod_disc codul disciplinei; ca i n cazul codului specializrii, i aici

vom presupune c dou discipline diferite au coduri diferite, indiferent de
forma disciplinei (curs, seminar, laborator sau proiect);
den_disc denumirea disciplinei studiate;
tip_disc tipul unei discipline;
semestru semestrul n care este studiat o disciplin; n funcie de

specializare, o disciplin poate fi studiat n semestre diferite de studenii
acesteia.
b) Relaiile pe care le identificm sunt urmtoarele:
Student ( nr_matr nume
pren )
111
Popa
Alin
222
Marin Daniela
333
Mihnea Ioana
den_spec )
76
Contabilitate i Informatic de Gestiune
75
Finane Bnci
70
Informatic Economic
67

tip_disc )
den_disc
D11
Baze de date
Curs
D12
Baze de date
Laborator
D21
Contabilitate financiar Seminar
c) Pentru a evidenia specializarea de care aparine fiecare student,
vom asocia relaiile Student i Specializare. Relaia Student este o relaie fiu
deoarece un student cu o anumit matricol nu poate fi nmatriculat la mai
multe specializri, n timp ce relaia Specializare este una printe ntruct, n
mod evident, fiecare specializare va avea mai muli studeni. Astfel, legtura
dintre cele dou relaii este de tipul unu-la-mai-muli, ceea ce nseamn c
va migra cheia primar din relaia Specializare sub forma cheii strine n
relaia Student. Astfel, prin intermediul atributului cod_spec din relaia
Student putem s aflm la ce specializare este nmatriculat fiecare student.
Dac dorim s determinm disciplinele studiate de fiecare student,
vom asocia relaiile Student i Disciplin. Cele dou relaii sunt printe
deoarece un student studiaz una sau mai multe discipline, iar fiecare
disciplin este studiat de nici un student (pot exista discipline opionale care
nu se aleg din pachetul de opionale) sau de mai muli studeni, ceea ce
nseamn c vom avea o legtur mai-muli-la-mai-muli. Aa cum tim deja,
n aceast situaie se va genera o nou relaie. Astfel, dup crearea
legturilor, modelul relaional este urmtorul:
cheia straina
pren
cod_spec )
Student ( nr_matr nume
111
Popa
Alin
76
222
Marin Daniela
75
333
Mihnea Ioana
76
76
75
70
den_spec )
Contabilitate i Informatic de Gestiune
Finane Bnci
Informatic Economic
tip_disc )
den_disc
D11
Baze de date
Curs
D12
Baze de date
Laborator
D21
Contabilitate financiar Seminar
Studiu ( nr_matr cod_disc semestru )
111
D11
3
111
D12
3
333
D21
2
68

Astfel, relaia Studiu este cea care ne permite s identificm
disciplinele studiate de fiecare student, dar i perioada n care acestea sunt
parcurse, astfel:
prin intermediul atributului nr_matr identificm studentul;
cu ajutorul atributului cod_disc vedem disciplina studiat de un student;
atributul semestru ne arat perioada n care un student studiaz o

anumit disciplin.
69

1. La ce se refer regula reprezentrii logice a datelor?
2. Ce reprezint baza de date relaional?
3. Ce reprezint cheia primar?
4. Ce reprezint cheia strin?
5. Ce este relaia fiu? Dar cea printe?
6. Ce reprezint legtura logic?
7. La ce se refer legtura de tipul unu-la-unu?
8. La ce se refer legtura de tipul unu-la-mai-muli?
9. La ce se refer legtura de tipul mai-muli-la-mai-muli?
10. Cum se realizeaz legtura dintre trei sau mai multe relaii?
Teste gril
1. Cte chei poate avea o relaie?
a. una primar, una strin si una alternant;
b. mai multe candidat, una primar i cel puin una strin;
c. una sau mai multe candidat, una primar i nici una, una, sau
mai multe alternante;
d. una sau mai multe candidat, una primar, nici una, una, sau
mai multe alternante i cel puin una strin.
2. O baz de date relaional se refer la:
a. colecii organizate de date;
b. colecii corelate din punct de vedere logic;
c. colecii organizate i corelate din punct de vedere logic;
d. colecii organizate i corelate fizic pe suportul de stocare.
3. Regula lui Codd specific reprezentrii fizice a datelor se refer la
faptul c:
a. programele de aplicaie pot fi afectate de modificrile realizate
asupra relaiilor bazei de date;
b. programele de aplicaie nu pot fi afectate de modificrile
realizate asupra relaiilor bazei de date;
c. programele de aplicaie pot fi afectate de modificrile realizate
n modul de reprezentare a datelor sau n metodele de acces;
d. programele de aplicaie nu pot fi afectate de modificrile
realizate n modul de reprezentare a datelor sau n metodele de
acces.
70

4. Cheia candidat reprezint:
a. un singur atribut care poate fi cheie primar sau cheie
alternant;
b. un atribut (grup de atribute) care poate deveni fie cheie primar,
fie cheie alternant;
c. un atribut (grup de atribute) care poate deveni fie cheie primar,
fie cheie strin;
d. un atribut (grup de atribute) care poate deveni fie cheie
alternant, fie cheie strin;
5. Cheia primar reprezint un atribut sau un grup de atribute care:
a. identific unic fiecare tuplu al unei relaii;
b. identific unic fiecare tuplu, n funcie de relaia n care
migreaz;
c. identific n mod unic toate celelalte atribute ale relaiei din care
face parte;
d. nu poate migra niciodat din relaia din care face parte.
6. Un tuplu se obine prin atribuirea de valori:
a. atributelor cheie;
b. atributelor unei relaii;
c. cheii strine;
d. pentru acele atributute care au valoarea NULL.
7. O relaie este printe dac:
a. unui tuplu din acea relaie nu-i corespunde nici un tuplu n
relaia cu care s-a asociat;
b. unui tuplu din relaia respectiv i corespunde un singur tuplu n
c. unui tuplu din relaia respectiv i corespund mai multe tupluri n
d. se asociaz cu nc dou relaii.
8. Fiecare relaie:
a. are o singur cheie primar;
b. are mai multe chei primare;
c. are o singur cheie primar, ns atunci cnd este nevoie, se
poate identifica cel mult nc una;
d. nu conteaz cte chei primare are o relaie.
71

9. Legtura de tipul unu-la-mai-muli se realizeaz atunci cnd:
a. unui tuplu din fiecare relaie i corespunde cel mult un tuplu din
cealalt relaie;
b. unui tuplu din prima relaie i corespund mai multe tupluri n cea
de-a doua relaie, n timp ce unui tuplu din a doua relaie i
corespunde un singur tuplu din prima;
c. unui tuplu din fiecare relaie i corespund mai multe tupluri din
cealalt relaie;
d. se asociaz cel puin trei relaii.
10. Operaia proiecie din algebra relaional:
a. se aplic unei singure relaii i se realizeaz dup diferite
atribute ale relaiei;
b. se aplic unei singure relaii i se realizeaz dup diferite
tupluri ale relaiei;
c. presupune existena a dou relaii cu aritate diferit i pe baza
unei condiii logice;
d. presupune existena a dou relaii cu scheme diferite, dar care
pot avea i atribute comune.
72
Bibliografie
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. [Gerald, 1999] Gerald, P., Database Management Systems, ed. Mc Graw
Hill, 1999.
10. [Harrington, 2002] Harrington, J.L., Relational Database Design Clearly
Explained, ediia a II-a, Morgan Kaufman, Amsterdam, 2002.
11. [Hoffer et al., 2002] Hoffer, J.A., Prescott, M.B., McFadden, F.R., Modern
Database Management, Prentice-Hall, 2002.
12. [Lungu, Bodea, 1995] Lungu, I., Bodea, C., Baze de date organizare,
proiectare i implementare, Editura All, Bucureti, 1995.
13. [Popa et al., 1994] Popa, Ghe., Stanciu, A., Ivancenco, V., Mare, V.,
SGBD, Editura All, Bucureti, 1994.
14. [Popescu, 2001] Popescu, I., Modelarea bazelor de date, Editura Tehnic,
Bucureti, 2001.
15. [Ramakrishnan, Gehrke, 2000] Ramakrishnan, R., Gehrke, J., Database
Management Systems, ed. Mc Graw Hill, 2000.
16. [Riccardo, 2001] Riccardo, G., Principles of Database Systems with
Internet and Java Application, ed. Addison Wesley, 2001.
17. [Riordan, 1999] Riordan, R., Designing Relational Database Systems,
Microsoft Press, 1999.
18. [Silbershartz, Korth, 1997] Silbershartz, A., Korth, H., Database system
concepts, ed. Addison Wesley, 1997.
19. [Simsion, 2001] Simsion, G., Data Modeling Essentials. Analysis, Design
and Innovation, ediia a II-a, Addison Wesley, 2001.
73
Bibliografie
20. [Trandafir et al., 2007] Trandafir, R., Nistorescu, M., Mierlu-Mazilu, I.,
Baze de date relaionale, Bucureti, 2007.
21. [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.
22. [Velicanu et al., 2003] Velicanu, M., Lungu, I., Muntean, M., Ionescu, S.,
Sisteme de baze de date teorie i practic, Editura Petrion, Bucureti,
2003.
23. http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_2.pdf.
74

Baze Date Economie Lupasc

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Baze Date Economie Lupasc

Încărcat de

Drepturi de autor:

Formate disponibile

Universitatea Dunrea de Jos Galai

Baze de date aplicate n economie

Departamentul pentru nvmnt la Distan i cu Frecven Redus

Capitolul II Proiectarea i administrarea unei baze de date.................................13

Capitolul III Sisteme de gestiune a bazelor de date ..............................................24

Capitolul IV Abordarea relaional a bazelor de date ..........................................43

Algebra relaional operatorii relaionali ...................................................................56

Fundamente ale bazelor de date

Capitolul I Fundamente ale bazelor de date

Baze de date aplicate n economie

Fundamente ale bazelor de date

Baze de date aplicate n economie

Fundamente ale bazelor de date

organizat, pe niveluri de organizare a datelor (conceptual, logic, fizic), aa

coerent, conform restriciilor de integritate i a legturilor dintre date, care

structurat, conform unui model de date pentru bazele de date;

cu redundan minim i controlat, care este asigurat prin modelul de

Profesorul M. Fotache prezint i analizeaz o definiie academic a

Fundamente ale bazelor de date

Baze de date aplicate n economie

Fundamente ale bazelor de date

Figura 1.1. Arhitectura pe componente a unui sistem de baze de date

Aa cum se observ, componentele specifice arhitecturii din figura 1.1

colecii de date propriu-zise;

dicionarul de date (structura de date, restriciile de integritate,

fiierele anexe, aa cum sunt cele de index.

b. software-ul este aferent realizrii i exploatrii bazei de date i

sistemul de gestiune a bazei de date;

programele de aplicaie dezvoltate, n cea mai mare parte, ntr-un

c. elementele auxiliare sunt componentele care contribuie la realizarea

Baze de date aplicate n economie

Fundamente ale bazelor de date

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

n arhitectura prezentat n figura 1.2 sunt redate nivelurile de

administratorul realizeaz structura conceptual a bazei de date,

structura conceptual se obine utiliznd un anumit model de date

structura conceptual este o reprezentare n interiorul sistemului a

viziunea administratorului asupra bazei de date este independent de

rezultatul nivelului conceptual este schema conceptual;

realizarea schemei corespunde unei activiti de modelare pentru c

odat definit, schema conceptual trebuie confruntat cu lumea real

SGBD Sistem de Gestiune a Bazelor de Date

Baze de date aplicate n economie

Fundamente ale bazelor de date

programatorul realizeaz programele de aplicaie pentru descrierea i

programele implementeaz structura extern (logic) a datelor;

structura extern este dedus din structura conceptual;

structura extern reprezint viziunea programatorului asupra bazei de

viziunea programatorului este independent de suportul tehnic de

rezultatul nivelului logic este schema extern, ca parte din schema

c. nivelul fizic este dat de viziunea analistului (inginerului) de sistem

analistul de sistem este cel cruia i revine sarcina de a realiza

structura intern corespunde descrierii datelor pe suportul fizic de

rezultatul la nivelul fizic este schema intern (fizic) care se definete

implementarea schemei interne se face cu ajutorul sistemului de

perspectiva utilizatorului, care lucreaz cu diferite pri

perspectiva administratorului bazei de date, care integreaz toate

perspectiva implementatorului bazei de date n foarte multe

Fundamente ale bazelor de date

c. apariia tehnicilor bazate pe gandirea orientat-obiect;

Baze de date aplicate n economie

Fundamente ale bazelor de date

b. viziunea programatorului este independent de suportul tehnic de