Baze Date

Universitatea “Dunărea de Jos” Galaţi
Baze de date aplicate în economie
Lect. dr. Lupaşc Adrian
Departamentul pentru Învăţământ la Distanţă şi cu Frecvenţă Redusă

Galaţi - 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 informaţionale...................................................................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 tranzacţiilor..................................................................................................19
Capitolul III – Sisteme de gestiune a bazelor de date ..............................................24
Evoluţia sistemelor de gestiune a bazelor de date .........................................................24
Facilităţi oferite de un SGBD ..........................................................................................27
Avantajele şi dezavantajele SGBD-urilor ......................................................................29
Componentele unui SGBD...............................................................................................35
Funcţiile SGBD-ului .........................................................................................................36
Capitolul IV – Abordarea relaţională a bazelor de date ..........................................43
Regulile lui Codd ..............................................................................................................43
Fundamente ale modelului relaţional .............................................................................45
Legături între relaţii.........................................................................................................50
Legătura binară 1-1 (unu la unu) .................................................................................................51
Legătura binară 1-n (unu la mai mulţi)........................................................................................52
Legătura binară n-n (mai mulţi la mai mulţi) ..............................................................................53
Legătura dintre trei sau mai multe relaţii.....................................................................................55
Algebra relaţională – operatorii relaţionali ...................................................................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ă evoluţia şi

ascensiunea până î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ă poziţionăm teoria bazelor de date în cadrul
tehnologiilor informaţionale, am prezentat câteva definiţii relevante ale
conceptului de bază de date formulate de cercetători şi profesori care s-au
remarcat cu preocupări î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
înţelegere generală a ceea ce reprezintă astăzi baza de date.
****************************************************************************************
Tehnologiile informaţionale influenţează continuu şi produc modificări

substanţiale asupra mijloacelor de lucru din întreaga lume. Informaţii care
erau altădată stocate în depozite pline de dulapuri, pot fi accesate astăzi prin
intermediul unei singure apăsări a butonului mouse-ului. Astfel, pentru
stocarea informaţiilor din orice mediu imaginabil în zilele noastre sunt folosite
sistemele de baze de date. De la bazele de date mari, aşa cum sunt
sistemele care permit rezervarea on-line a biletelor pentru companiile aeriene
şi până la fişele dintr-o bibliotecă, sistemele de baze de date sunt folosite
pentru memorarea şi distribuirea datelor de care încep să depindă tot mai
mult vieţile noastre.
Până în urmă cu câţiva ani, sistemele mari de baze de date se găseau
numai pe calculatoare de tip mainframe 1 . Însă, aşa cum era şi firesc,
proiectarea, achiziţionarea sau întreţinerea unei astfel de maşini reprezenta o
sarcină costisitoare şi dificil de realizat. Odată cu apariţia calculatoarelor din
clasa staţiilor de lucru, pe care le întâlnim la tot pasul (biblioteci, laboratoare
de informatică, departamente de lucru, etc.) şi care sunt puternice şi în
acelaşi timp destul de ieftine, programatorii au posibilitatea de a proiecta
rapid şi la costuri reduse produse informatice care să permită întreţinerea şi
distribuirea datelor.
1
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 aplicaţii
asemănătoare, care necesită o capacitate de stocare foarte mare şi o interacţiune puternică
cu un număr mare de utilizatori, concretizată printr-un volum foarte mare de comunicaţii de
date.
Baze de date aplicate în economie 3
Cercetarea aferentă bazelor de date are aproape 35 de ani de istorie,
ani care au condus în mod inevitabil la cele mai relevante şi importante
dezvoltări ale ingineriei software. În mod natural, tehnologiile specifice
bazelor de date, arhitecturile şi cadrele conceptuale au fost tot mai bine
consolidate în ultimile decade. Mai mult, în ultimii ani, managementul bazelor
de date a evoluat astfel încât bazele de date au devenit o componentă cheie
a sistemelor informaţionale moderne. Acest aspect a provocat un impact
adânc precum şi modificări semnificative în modul de lucru al instituţiilor şi
organizaţiilor, contribuind într-o măsură relevantă la adoptarea celor mai
adecvate decizii care să le poată garanta succesul în afaceri şi nu numai. În
acest context, este important să menţionăm anumiţi factori care au contribuit
la această explozie: noile tehnici şi instrumente de modelare, cele mai
importante, fiind cele care se bazează pe o gândire orientată obiect, apariţia
procesării de tipul client-server, diminuarea semnificativă a preţurilor aferente
atât componentei hardware cât şi a celei software şi, nu în ultimul rând,
necesitatea unei administrări eficiente şi corecte a cantităţilor tot mai mari de
informaţii care caracterizează activităţile fiecărei organizaţii din zilele noastre.
În prezent, bazele de date fac parte tot mai mult din viaţa noastră de zi
cu zi în aşa măsură, încât uneori nici măcar nu mai conştientizăm că le
utilizăm. Atunci când cumpărăm ceva de la un supermarket, probabil că va fi
accesată o bază de date. Casierul va trece un cititor de coduri de bare peste
fiecare dintre articolele pe care le achiziţionăm. Acesta este conectat la un
sistem informatic pentru baze de date, care utilizează codul de bare pentru a
identifica preţul produsului pe care l-am ales, evident dintr-o bază de date
care gestionează produsele. De asemenea, dacă stocul pentru un produs
scade sub o anumită limită, este posibil ca sistemul să emită în mod automat
o comandă către un furnizor, pentru a obţine un stoc suplimentar din acel
articol.
Atunci când vizitaţi o bibliotecă (!dacă se mai întâmplă acest lucru…)
constataţi că există o bază de date care conţine informaţii detaliate despre
cărţile care formează fondul de carte al bibliotecii. Practic, pentru a
preîntâmpina anumite cerinţe, 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 naştere începând cu o listă într-un
editor de texte sau într-o foaie de calcul. La momentul respectiv, suntem
tentaţi să credem că a fost aleasă cea mai bună soluţie, atât timp cât
necesităţile informaţionale sunt satisfăcute, este adevărat, în contextul unei
cantităţi reduse de informaţii. În timp însă, acest volum creşte (spre exemplu,
odată cu creşterea activităţii unei organizaţii, ceea ce face ca soluţiile (privite
iniţial ca fiind cele mai adecvate) să nu mai fie potrivite. Mai mult, pe măsură
ce lista devine tot mai mare, încep să apară redundanţe şi inconsistenţe la
nivelul datelor gestionate. Datele devin greu de înţeles sub forma listei, iar
posibilităţile de căutare, regăsire şi extragere a subseturilor de date pentru
revizuire, actualizare sau utilizare devin extrem de limitate. Odată cu apariţia
acestor probleme, o idee bună, chiar o necesitate în anumite situaţii, ar fi
aceea al transferului acestor date într-o bază de date creată cu ajutorul unui
sistem de gestiune al bazelor de date.
4 Baze de date aplicate în economie

În prezent ne este tot mai clar faptul că explozia informaţională este de
ani buni trăsătura definitorie care caracterizează activităţile fiecărei
organizaţii sau instituţii, indiferent de domeniul său de activitate. Volumul tot
mai însemnat de informaţii nu mai poate fi utilizat eficient cu ajutorul
mijloacelor tradiţionale. Practic, constatăm că procesul de prelucrare
automată a datelor prin intermediul sistemelor electronice de calcul a devenit
o necesitate pentru majoritatea domeniilor de activitate. În acest context,
putem afirma că cea mai evoluată metodă de organizare a datelor în vederea
prelucrării lor automate o întâlnim la bazele de date.
În literatura de specialitate există numeroase definiţii aferente
conceptului de bază de date. În continuare vom prezenta câteva dintre ele,
care, în opinia noastră, acoperă cel mai bine conceptul de bază de date.
„O bază de date conţine toate informaţiile necesare despre obiectele
ce intervin într-o mulţime de aplicaţii, relaţii logice între aceste informaţii şi
tehnicile de prelucrare corespunzătoare. În bazele de date are loc o integrare
a datelor, în sensul că mai multe fişiere sunt privite în ansamblu, eliminându-
se pe cât posibil acele informaţii redundante. De asemenea, este permis
accesul simultan la aceleaşi date, care se regăsesc în acelaşi loc sau sunt
distribuite spaţial, a mai multor persoane de pregătiri diferite, fiecare cu stilul
personal de lucru” [Bâscă, 1997, p.11].
Referitor la definiţia prezentată anterior, putem spune că avem unele
reţineri în ceea ce priveşte utilizarea conceptului de informaţie. Astfel, autorul
vede baza de date ca un ansamblu de informaţii, părere pe care o
împărtăşim parţial şi numai în cazul în care se face referire la baza de date în
general, dar nu şi la o bază de date relaţională. Este cert faptul că atunci
când facem referire la baza de date relaţională, nu putem vorbi de informaţii,
ci numai de date.
„Totodată, putem privi baza de date ca ansambluri unitare de date,
structurate, corelate logic între ele şi memorate împreună cu descrierea
formală a structurii lor şi a legăturilor logice dintre ele, a cărui gestionare este
realizată de un sistem software unitar şi specializat, numit sistem de gestiune
a bazei de date” [Georgescu, Georgescu, 2005, p.63].
O definiţie completă şi explicativă a noţiunii de bază de date este
oferită în [Velicanu et al., 2003, p.51]. Astfel, aceasta reprezintă un ansamblu
de colecţii de date:
• organizat, pe niveluri de organizare a datelor (conceptual, logic, fizic), aşa
cum reiese şi din arhitectura pe niveluri a unui sistem de baze de date;
• coerent, conform restricţiilor de integritate şi a legăturilor dintre date, care
rezultă din modelul logic aferent;
• structurat, conform unui model de date pentru bazele de date;
• cu redundanţă minimă şi controlată, care este asigurată prin modelul de
date implementat şi prin tehnicile de proiectare ale bazei de date;
• accesibil mai multor utilizatori în timp real, adică mai mulţi utilizatori,
concomitent, pot obţine informaţiile dorite atunci când au nevoie de ele.
Profesorul M. Fotache prezintă şi analizează o definiţie academică a
bazei de date. Astfel, în opinia acestuia, baza de date reprezintă un
ansamblu structurat de fişiere care grupează datele prelucrate în aplicaţiile
informatice ale unei persoane, grup de persoane, întreprinderi, instituţii, etc.
Din punct de vedere formal, defineşte baza de date ca „o colecţie de date
aflate în interdependenţă, împreună cu descrierea datelor şi relaţiilor dintre
ele sau, similar, o colecţie de date folosită într-o organizaţie, colecţie care
este automatizată, partajată, definită riguros (formalizată) şi controlată la
nivel central” [Fotache, 2005, p.14].
Plecând de la definiţiile prezentate anterior, putem afirma că o bază de
date relaţională reprezintă o colecţie partajată de date, între care există
diferite legături logice (împreună cu o descriere a acestora), proiectată pentru
a satisface necesităţile informaţionale ale fiecărei organizaţii. Totodată,
putem privi o bază de date ca un instrument pentru organizarea şi colectarea
tuturor informaţiilor, astfel încât să se satisfacă toate necesităţile
informaţionale ale utilizatorilor ei.
Definiţia prezentată anterior trebuie analizată în detaliu pentru a putea
fi în măsură să dobândim o mai bună înţelegere a conceptului de bază de
date. Baza de date reprezintă un depozit de date unic, larg, care este definit
o singură dată şi este utilizat simultan de diferite departamente sau utilizatori.
Această soluţie substituie crearea mai multor fişiere separate cu date de cele
mai multe ori considerate a fi redundante şi presupune integrarea tuturor
datelor necesare, dublarea lor fiind în acest caz minimală. De aici decurge un
prim avantaj semnificativ: baza de date nu mai este deţinută de un singur
departament, ci constituie acum o resursă comună, partajată. Pe de altă
parte, baza de date conţine nu numai datele operaţionale ale unei organizaţii
sau instituţii, ci şi o descriere a acestora, întâlnite în literatură sub denumirea
de metadate (date despre date).
Atunci când analizăm necesităţile informaţionale ale unei organizaţii,
avem în vedere în principal identificarea entităţilor, atributelor şi relaţiilor.
Putem privi o entitate ca un obiect distinct (o persoană, un departament, un
concept sau un eveniment) care aparţine unei organizaţii şi care trebuie
reprezentat în baza de date. Atributul este o proprietate care descrie un
aspect oarecare al obiectului pe care dorim să-l înregistrăm, iar relaţia se
referă la o asociaţie între diferite entităţi. Astfel, putem spune că baza de
date conţine entităţile, atributele, dar şi relaţiile (legăturile) logice dintre ele. În
capitolul 4 vom arăta cum se concretizează din punct de vedere practic
legăturile logice dintre relaţii, prin introducerea conceptului de cheie străină.
Arhitecturi ale sistemelor de baze de date

În literatura de specialitate sunt prezentate mai multe tipuri de
arhitecturi ale sistemelor de baze de date. Nouă ne-au atras atenţia cele
prezentate în [Velicanu et al., 2003, p.13]. Astfel, conform autorilor, rolul unei
arhitecturi este de a realiza o reprezentare grafică a elementelor sistemului,
precum şi a legăturilor dintre ele. În funcţie de ceea ce se evidenţiază grafic,
se folosesc două tipuri de arhitecturi:
1. arhitectura pe componente – oferă o imagine asupra elementelor care
formează un sistem de baze de date, dar şi a inter-dependenţelor dintre
ele, aşa 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
Aşa cum se observă, componentele specifice arhitecturii din figura 1.1

sunt:
a. datele – sunt organizate într-o bază de date care conţine:
• colecţii de date propriu-zise;
• dicţionarul de date (structura de date, restricţiile de integritate,
vederile, etc.);
• fişierele anexe, aşa cum sunt cele de index.
b. software-ul – este aferent realizării şi exploatării bazei de date şi
conţine:
• sistemul de gestiune a bazei de date;
• programele de aplicaţie dezvoltate, în cea mai mare parte, într-un
sistem de gestiune a bazelor de date.
c. elementele auxiliare – sunt componentele care contribuie la realizarea
şi funcţionarea întregului sistem de baze de date:
1. un set de proceduri automate (rutine) şi manuale;
2. reglementări legale şi administrative;
3. mijloace hardware utilizate;
4. persoane implicate pe categorii de utilizatori.
2. Arhitectura pe niveluri structurează un sistem de baze de date pe trei

niveluri şi oferă o imagine despre modul de organizare şi funcţionare al
acestuia (figura 1.2).

Niveluri de
Vederi ale
Manipulare date Descriere date organizare
bazei de date
date
Program Structura externa

Programator aplicatie 1 (logica)
de aplicatie ... ... Logic
SGBD
Administrator Structura
baza de date conceptuala Conceptual
S.O. ...
Inginer
Structura interna
(analist) de Bază de date (fizica) Fizic
sistem
Figura 1.2. Arhitectura pe niveluri a unui sistem de baze de date
În arhitectura prezentată în figura 1.2 sunt redate nivelurile de

organizare (reprezentare) a datelor în baza de date şi legăturile dintre ele:
nivelul conceptual, nivelul logic şi nivelul fizic.
a. nivelul conceptual – este dat de viziunea administratorului bazei de date
asupra datelor. Legat de acest nivel, se pot menţiona următoarele
aspecte:
• administratorul realizează structura conceptuală a bazei de date,
eventual cu ajutorul instrumentelor oferite de un SGBD2;
• structura conceptuală se obţine utilizând un anumit model de date
pentru baza de date, precum şi o tehnică de proiectare cât mai
adecvată;
• structura conceptuală este o reprezentare în interiorul sistemului a
realităţii pe care baza de date o transcrie;
• viziunea administratorului asupra bazei de date este independentă de
aplicaţiile care vor fi dezvoltate (independenţa logică);
• rezultatul nivelului conceptual este schema conceptuală;
• realizarea schemei corespunde unei activităţi de modelare pentru că
este vorba despre o transpunere în termeni abstracţi a entităţilor lumii
reale;
• odată definită, schema conceptuală trebuie confruntată cu lumea reală
pentru identificarea şi soluţionarea neconcordanţelor sau a omisiunilor;
datorită caracterului său global şi unitar, se recomandă ca schema
conceptuală să fie gestionată de o singură persoană [Georgescu,
Georgescu, 2005, p.67].
2
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 următoarele aspecte:
• programatorul realizează programele de aplicaţie pentru descrierea şi
manipularea datelor, scrise într-un SGBD;
• programele implementează structura externă (logică) a datelor;
• structura externă este dedusă din structura conceptuală;
• structura externă reprezintă viziunea programatorului asupra bazei de
date pentru o anumită aplicaţie;
• viziunea programatorului este independentă de suportul tehnic de
informaţie (independenţa fizică);
• rezultatul nivelului logic este schema externă, ca parte din schema
conceptuală, implementată cu ajutorul unui SGBD.
c. nivelul fizic – este dat de viziunea analistului (inginerului) de sistem
asupra datelor şi are rolul de a descrie modul în care sunt stocate datele
în baza de date. Aferent nivelului fizic putem menţiona următoarele:
• analistul de sistem este cel căruia îi revine sarcina de a realiza
structura internă (fizică);
• structura internă este dedusă din cea externă conform unor tehnici şi
metode de alocare pe suport fizic;
• structura internă corespunde descrierii datelor pe suportul fizic de
informaţie;
• rezultatul la nivelul fizic este schema internă (fizică) care se defineşte
în termeni de fişiere şi înregistrări;
• implementarea schemei interne se face cu ajutorul sistemului de
gestiune a fişierelor (SGF) din cadrul SGBD-ului şi/sau din sistemul de
operare, prin gestiunea fizică a perifericelor.
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 părţi
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 răspunsuri 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
situaţii, el coincide cu administratorul bazei de date, care priveşte
baza de date ca pe o colecţie de fişiere memorate pe diferite medii
externe. Acesta constituie nivelul fizic al bazei de date şi care este
practic singurul nivel care există efectiv.
Întrebări recapitulative
1. Ce reprezintă o bază de date?

2. Menţionaţi factorii care au permis domeniului bazelor de date să devină o
componentă cheie a sistemelor informaţionale moderne.
3. Identificaţi 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. Definiţi conceptul de entitate.
5. Definiţi conceptul de atribut.
6. Care sunt componentele specifice arhitecturii pe componente?
7. Prezentaţi rolul nivelului conceptual aferent arhitecturii pe niveluri.
8. Prezentaţi rolul nivelului logic aferent arhitecturii pe niveluri.
9. Prezentaţi rolul nivelului fizic aferent arhitecturii pe niveluri.
10. Căror 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 numără:
a. necesitatea unei administrări mai eficiente a unei cantităţi mai mari
de informaţii;
b. creşterea semnificativă a preţurilor aferente componentelor
hardware şi software;
c. apariţia tehnicilor bazate pe gandirea orientată-obiect;
d. dezvoltarea prelucrărilor bazate pe tehnologia client-server.
2. Referitor la o bază de date relaţională, putem afirma că va conţine:
a. colecţii organizate de date între care pot exista diferite legături;
b. colecţii organizate de date între care pot exista legături, iar dacă
există, ele sunt legături logice;
c. colecţii organizate de date fără legături logice;
d. colecţii organizate de date între care există legături logice.
3. Componenta software specifică arhitecturii pe componente a unui sistem
de baze de date poate conţine:
a. dicţionarul de date;
b. sistemul de gestiune al bazei de date;
c. datele;
d. fişierele anexă.

4. Elementele auxiliare specifice arhitecturii pe componente se referă la:
a. realizarea şi funcţionarea întregului sistem de baze de date;
b. programe de aplicaţii dezvoltate într-un sistem de gestiune a
bazelor de date;
c. realizarea şi exploatarea bazei de date;
d. structura datelor, restricţiile 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 aplicaţie pentru
descrierea şi manipularea datelor, scrise într-un SGBD;
b. viziunea programatorului este independentă de suportul tehnic de
informaţie;
c. viziunea administratorului asupra bazei de date este independentă
de aplicaţiile care vor fi dezvoltate;
d. implementarea schemei interne se face cu ajutorul sistemului de
gestiune a fişierelor din cadrul SGBD-ului şi/sau din sistemul de
operare, prin gestiunea fizică a perifericelor.
7. Independenţa 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 aplicaţiile care vor fi dezvoltate.
8. Independenţa fizică se referă la faptul că:
a. viziunea administratorului bazei de date este independentă de
suportul tehnic de informaţie;
b. viziunea programatorului şi al administratorului bazei de date este
independentă de suportul tehnic de informaţie;
c. viziunea programatorului este independentă de suportul tehnic de
informaţie;
d. independenţa fizică se realizează indiferent de viziunea
programatorului, utilizatorului sau a administratorului.

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. Independenţa logică este specifică:
a. nivelului logic;
b. nivelului conceptual;
c. nivelului fizic;
d. independenţa logică este specifică nivelului conceptual sau
nivelului logic, în funcţie de modul de proiectare al bazei de date.

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 – urmăreşte atingerea următoarelor
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 tranzacţiilor.
****************************************************************************************
În prezent observăm că avalanşa produselor software o depăşeşte net

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

soluţionarea problemelor menţionate anterior, a fost propusă o nouă
abordare structurată privind dezvoltarea produselor software, numită ciclu de
viaţă al sistemelor informaţionale.
Ciclul de viaţă al sistemelor informaţionale

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

Etapele specifice ciclului de viaţă al unei aplicaţii de tip bază de date
sunt prezentate în figura 2.1. Trebuie menţionat că etapele ciclului de viaţă
ale unei astfel de aplicaţii nu sunt strict secvenţiale, ci pot presupune
revenirea la o etapă anterioară şi repetarea lor. Spre exemplu, dacă apar
anumite probleme în timpul proiectării bazei de date, se poate reveni la etapa
anterioară care are drept obiectiv colectarea şi analiza cerinţelor.

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 aplicaţii de tip bază de date
Principalele activităţi asociate fiecărei etape din ciclul de viaţă al

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

Proiectarea bazelor de date
Connoly şi colaboratorii săi [Connoly et al., 2002, p.281-282] identifică
şi descriu trei tipuri de proiectări:
• conceptuală, care se referă la dezvoltarea unui model informaţional
independent de orice considerent privitor la aspectul fizic al datelor;
• logică, care vizează construirea unui model informaţional bazat pe unul
din modelele tradiţionale (E-R3, relaţional, OO4, OR5), dar independent de
tipul SGBD-ului ales şi de alte aspecte fizice ale modelului;
• fizică – urmăreşte implementarea efectivă a bazei de date pe suportul de
stocare, inclusiv acele aspecte care ţin de asigurarea şi garantarea
securităţii datelor.
Proiectarea corespunzătoare bazei de date este o etapă foarte
importantă, mai ales că trebuie să fie capabilă să garanteze buna funcţionare
a acesteia şi a oricărei aplicaţii care o utilizează. În lipsa unei proiectări
adecvate a bazei de date, aceasta poate prezenta mai multe deficienţe, cum
ar fi:
• compromiterea integrităţii datelor deoarece restricţiile de integritate nu pot
fi proiectate sau implementate corect;
• datele sunt redundante, iar aplicaţiile individuale se „aglomerează” în
încercarea de a se asigura sincronizarea datelor;
• performanţele sunt afectate deoarece este posibil ca pentru finalizarea
unei instrucţiuni (spre exemplu, instrucţiunea Select 6 ) să fie necesare
interogări 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 doreşte a fi modelată (parte din activitatea unei
organizaţii). Acest model de date va fi construit prin utilizarea informaţiilor
aferente specificaţiilor cerinţelor 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 aplicaţie, platforma hardware sau orice alte consideraţii fizice. Totodată,
trebuie să menţionăm că este important ca pe tot parcursul procesului de
realizare a modelului conceptual de date, acesta să fie permanent testat şi
validat conform cerinţelor utilizatorului. Practic, acest model constituie o
sursă importantă de informaţii pentru faza de proiectare logică.
Proiectarea logică
Această fază are ca rezultat crearea unui model de date logic aferent
activităţilor sau proceselor pe care dorim să le modelăm. Modelul de date
3
E-R – Entitate – Relaţie
4
OO – Orientat Obiect
5
OR – Obiectual – Relaţional
6
Select este o instrucţiune specifică limbajului SQL – Structured Query Language – care
permite extragerea datelor din baza de date.
conceptual creat în faza precedentă este rafinat şi transpus într-un model de
date logic. Acesta este influenţat de către modelul de date avut în vedere
pentru baza de date (spre exemplu, modelul de date relaţional pe care îl vom
detalia în capitolul IV).
Spre deosebire de celălalt model, care este independent de toate
consideraţiile fizice, modelul logic este creat plecând de la modelul de date
principal al sistemului SGBD ţintă. Cu alte cuvinte, ştim că SGBD-ul este, de
exemplu, relaţional, ierarhic sau orientat spre obiecte. Însă, se ignoră alte
aspecte ale SGBD-ului ales şi, mai ales, fiecare detaliu fizic, aşa cum sunt
structurile de stocare.
Pe parcursul realizării modelului logic de date, se efectueză testarea şi
validarea permanentă a acestuia în conformitate cu cerinţele utilizatorului.
Tehnica de normalizare este utilizată pentru a testa corectitudinea modelului
logic de date. Practic, normalizarea garantează că relaţiile derivate din
modelul de date nu prezintă redundanţe, care pot cauza anomalii (la
implementare) la actualizarea bazei de date. Altfel spus, normalizarea este
procesul prin care se elimină redundanţa datelor din baza de date şi se
construieşte un model de bază de date care susţine diverse cerinţe
funcţionale şi structuri alternative ale bazei de date.
Normalizarea presupune împărţirea unei relaţii (care include la
momentul respectiv toate atributele necesare problemei) în mai multe relaţii
între care se definesc diferite legături logice. Principalele obiective ale
normalizării sunt [Fotache, 2005, p.41-42]:
• minimizarea spaţiului necesar stocării datelor;
• minimizarea riscului apariţiei de date inconsistente în cadrul bazei de
date;
• minimizarea numărului de anomalii ce pot apărea la actualizare
(inserarea datelor, dar mai ales modificări şi ştergeri);
• ameliorarea structurii bazei de date, reprezentarea diverselor
conexiuni dintre atributele acesteia;
• diminuarea nevoii de reorganizare periodică a modelului.
Există un număr de reguli care se aplică în normalizare. În continuare
vom prezenta doar primele trei reguli care sunt în măsură să garanteze
definirea unei structuri logice a bazei de date într-o formă acceptabilă (în
care însă redundanţa 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 relaţiei
pe care o descrie (forma II normală). Această regulă se realizează prin
repartizarea atributelor într-o relaţie, astfel încât fiecare dintre ele va
depinde în totalitate de cheia primară.
3. Pentru a putea fi în forma III normală, fiecare relaţie trebuie să aibă o
singură cheie primară.
Totodată, modelul logic de date reprezintă o sursă importantă de
informaţii pentru faza de proiectare fizică, punând la dispoziţia 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 întreţinere
operaţională din ciclul de viaţă al unei aplicaţii cu baze de date. Dacă este
întreţinut şi îmbunătăţit adecvat, modelul de date permite efectuarea unor
modificări viitoare în programele aplicaţie şi reprezentarea corectă şi eficientă
a datelor de către 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 stabileşte cum va fi ea
implementată. Aşa cum am vazut deja, faza precedentă presupunea
realizarea unei structuri logice, cu alte cuvinte se referea la definirea relaţiilor,
atributelor şi legăturilor dintre ele. Cu toate că această structură este
independentă de SGBD-ul ales, ea se realizează conform unui model de
date, aşa cum este cel relaţional. În realizarea proiectării fizice, trebuie iniţial
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 legătură, deoarece pe parcursul proiectării fizice sunt
luate decizii referitoare la îmbunătăţirea performanţelor, care pot însă afecta
structura modelului logic de date.
În cele mai multe situaţii, obiectivul principal al proiectării fizice este de
a descrie cum se intenţionează realizarea implementării fizice a proiectului
logic al unei baze de date. Astfel, în cazul modelului relaţional, aceasta
presupune:
• extragerea unui set de tabele relaţionale (relaţii) şi de constrângeri asupra
acestora, din informaţiile prezentate în modelul logic de date (modelul
global);
• identificarea structurilor de stocare specifice şi metodelor de acces la date,
astfel încât să se garanteze obţinerea unor performanţe optime cu
sistemul respectiv;
• proiectarea mijloacelor care să asigure securitatea sistemului.
Proiectarea tranzacţiilor
În sens larg, putem defini o tranzacţie ca o acţiune sau o serie de
acţiuni efectuate de utilizator sau de un program de aplicaţie, care accesează
sau actualizează o bază de date. De asemenea, în [Georgescu, Georgescu,
2005, p.71] tranzacţia este definită ca unitatea logică de prelucrare asupra
unei baze de date care include setul complet de operaţii elementare ce
trebuie executat în vederea realizării unei tranziţii, pentru asigurarea
consistenţei şi siguranţei bazei de date. Aceeaşi autori consideră că o
tranziţie se referă la trecerea de la o realizare la alta a unei baze de date şi
poate fi produsă de modificarea conţinutului unei tabele a bazei de date, de
modificarea structurii acesteia, de adăugarea unei noi tabele, etc.
Tranzacţiile reprezintă evenimente din lumea reală, cum ar fi
adăugarea unui nou angajat, înregistrarea unui nou client, înregistrarea unei
note obţinute de un student la o disciplină, etc. Aceste tranzacţii trebuie
aplicate bazei de date, pentru a garanta că datele conţinute în aceasta
rămân „la curent” cu situaţia din lumea reală, dar şi pentru a susţine nevoile
informaţionale ale utilizatorilor.
O tranzacţie poate fi formată din mai multe operaţii, cum ar fi spre
exemplu, transferul banilor dintr-un cont în altul. Totuşi, din punctul de vedere
al utilizatorului, aceste operaţii realizează o singură sarcină. Din perspectiva
SGBD-ului, o tranzacţie transferă baza de date dintr-o stare în alta. SGBD-ul
asigură coerenţa bazei de date, chiar în cazul unei defecţiuni. Totodată,
SGBD-ul garantează şi faptul că odată tranzacţia finalizată, modificările
realizate sunt stocate permanent în baza de date şi nu pot fi pierdute sau
anulate. Dacă dintr-un motiv oarecare, tranzacţia nu poate fi terminată,
SGBD-ul este în măsură să garanteze că modificările realizate de acesta
sunt anulate. În exemplul menţionat anterior, cel al transferului de bani, dacă
banii sunt debitaţi într-un cont şi tranzacţia eşuează înaintea creditării
celuilalt cont, SGBD-ul va anula şi debitarea. În cazul în care am defini cele
două operaţii (debitarea şi creditarea) ca tranzacţii separate, atunci, odată
debitat primul cont şi încheiată tranzacţia, modificarea nu ar mai putea fi
anulată (pentru situaţia în care creditarea nu s-ar realiza).
Trebuie să mai menţionăm şi faptul că proiectarea unei tranzacţii se
bazează pe informaţiile din specificaţiile cerinţelor utilizatorului. Există
numeroase tehnici de preluare şi generare a specificaţiilor cerinţelor, care
includ şi o notaţie pentru specificarea tranzacţiilor cerute de către utilizatori.
Aceste tranzacţii pot constitui operaţii complexe care, atunci când sunt
analizate, se dovedesc a fi compuse, de fapt, din mai multe operaţii, fiecare
dintre acestea constituind câte o singură tranzacţie.

1. Ce reprezintă sistemul informaţional?

2. Identificaţi şi prezentaţi pe scurt principalele scopuri ale proiectării unei
baze de date.
3. Ce reprezintă întreţinerea operaţională?
4. Care sunt principalele tipuri de proiecări în viziunea cercetătorului
Connoly şi a colaboratorilor săi?
5. Proiectarea conceptuală.
6. Proiectarea logică.
7. Proiectarea fizică.
8. Proiectarea tranzacţiilor.
9. Ce reprezintă tranzacţia?
10. Ce reprezintă tranziţia?
Teste grilă
1. Rolul sistemului informaţional este de a asigura legătura dintre:

a. sistemul decizional şi cel operaţional;
b. sistemul operaţional şi cel informatic;
c. sistemul de conducere şi cel de execuţie;
d. toate sistemele organizaţiei.
2. Etapele ciclului de viaţă al unui sistem de baze de date:
a. nu pot fi mereu secvenţiale;
b. sunt mereu secvenţiale;
c. depinde de maniera de proiectare a sistemului informatic: în
funcţie de aceasta, etapele ciclului de viaţă se pot derula
secvenţial 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. întreţinere operaţională.

4. Întreţinerea operaţională se referă la:
a. monitorizarea şi testarea continuă a aplicaţiei;
b. monitorizarea continuă a aplicaţiei şi încorporarea unor noi
cerinţe, atunci când este cazul;
c. monitorizarea continuă a aplicaţiei şi încorporarea permanentă
a unor noi cerinţe;
d. monitorizarea continuă a aplicaţiei, fără însă a se mai putea
adăuga funcţionalităţi suplimentare aferente noilor cerinţe.
5. Prototipizarea este:
a. o etapă obligatorie specifică proiectării bazei de date care
permite numai proiectantului să evalueze modul de funcţionare
a aplicaţiei;
b. o etapă opţională specifică proiectării bazei de date care
permite numai proiectantului să evalueze modul de funcţionare
a aplicaţiei;
c. o etapă obligatorie specifică proiectării bazei de date care
permite proiectantului şi utilizatorului să evalueze modul de
funcţionare a aplicaţiei;
d. o etapă opţională specifică proiectării bazei de date care
permite proiectantului şi utilizatorului să evalueze modul de
funcţionare a aplicaţiei.
6. Proiectarea bazei de date se referă şi la:
a. oferirea unui model de date care să permită realizarea
tranzacţiilor;
b. oferirea unui model de date care să permită realizarea tuturor
tranziţiilor necesare;
c. oferirea unui model de date care să permită realizarea
tranzacţiilor şi a tranziţiilor 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 informaţional dependent de fiecare
considerent privitor la aspectul fizic al datelor;
b. construirea unui model informaţional independent de fiecare
considerent privitor la aspectul fizic al datelor;
c. construirea unui model informaţional independent bazat pe unul
din modelele tradiţionale;
d. implementarea efectivă a bazei de date.

8. Proiectarea incorectă a bazei de date poate conduce la următoarele
deficienţe:
a. lipsa performanţelor dorite;
b. neredundanţa datelor;
c. afectarea integrităţii datelor;
d. imposibilitatea proiecării corecte a restricţiilor de integritate
asupra datelor.
9. Realizarea unui model de date logic este specific:
a. proiectării conceptuale;
b. proiectării fizice;
c. proiectării logice;
d. proiectării tranzacţiilor.
10. Tranzacţia se referă la:
a. acţiuni care numai accesează baza de date;
b. acţiuni care numai actualizează baza de date;
c. acţiuni care accesează sau actualizează baza de date;
d. trecerea de la o realizare la alta a bazei de date.

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 informaţionale şi a modificat fundamental modul de
operare al unei organizaţii. Astfel, în cadrul capitolului trei, am definit sistemul
de gestiune a bazelor de date, am descris evoluţia în timp a acestora şi am
prezentat principalele facilităţi pe care le oferă. Totodată, am tratat
componentele unui sistem de gestiune a bazelor de date, funcţiile 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 întreţinerea unei baze de date, precum şi accesul controlat la
aceasta. În [Velicanu et al., 2003, p.94] SGBD-ul este definit ca un ansamblu
complex de programe care asigură interfaţa între o bază de date şi utilizatorii
acesteia. Totodată, autorii consideră SGBD-ul o componentă software a unui
sistem de baze de date care este capabil să interacţioneze cu toate celelalte
componente ale acestuia, asigurând legătura şi independenţa între
elementele sistemului.
Un SGBD oferă utilizatorului posibilitatea de a accesa datele prin
intermediul unui limbaj de nivel înalt, apropiat de modul obişnuit de exprimare,
pentru a obţine informaţii, utilizatorul făcând abstracţie de mijloacele şi
metodele folosite pentru alegerea datelor implicate şi a modului de memorare
a lor. SGBD-ul este practic o interfaţă între utilizatori şi sistemul de operare.
Termenul de bază de date se va referi la datele de prelucrat, la modul
de organizare a acestora pe suportul fizic de memorare, iar termenul de
gestiune va semnifica totalitatea operaţiilor ce se aplică asupra datelor din
baza de date [Trandafir et al., 2007, p.10].
Evoluţia sistemelor de gestiune a bazelor de date

Aşa cum se ştie, predecesorul SGBD-ului a fost sistemul bazat pe
fişiere. Totuşi, nu a existat un moment bine definit, în care să înceapă
tratarea prin baze de date şi să înceteze sistemul bazat pe fişiere. De fapt,
sistemul bazat pe fişiere mai există încă şi astăzi în anumite domenii. S-a
sugerat că SGBD-ul îşi are rădăcinile în proiectul de aselenizare Apollo din

anul 1960, care a fost iniţiat ca răspuns la obiectivul preşedintelui J.F.
Kennedy de a trimite un om pe lună până la sfârşitul deceniului. În acel
moment, nu exista nici un sistem capabil să trateze şi să administreze
cantităţile vaste de informaţii 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 părţi ale unor componente
mai mari şi aşa mai departe, până la asamblarea produsului final. Această
structură, care seamănă 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 informaţiilor). Motivul pentru care cei de la
IBM au restrâns sistemul IMS la administrarea ierarhiilor înregistrărilor 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ă
restricţie 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 apariţia
sistemului IDS8 (depozitul de date integrate), realizat de compania General
Electric. Acest proiect a fost condus de către unul dintre pionierii sistemelor
de baze de date, Charles Bachrnann. Această realizare a dus la apariţia unui
nou tip de sistem de baze de date, cunoscut sub denumirea de sistem SGBD
în reţea, care a avut un efect profund asupra sistemelor informaţionale din
acea generaţie. Baza de date în reţea a fost realizată, parţial, pentru a
răspunde necesităţii de reprezentare a unor relaţii dintre date mai complexe
decât se puteau modela cu ajutorul structurilor ierarhice şi, parţial, pentru a
impune un standard pentru bazele de date. Pentru a contribui la stabilirea
unor astfel de standarde, la Conferinţa despre Limbajele Sistemelor de Date
(CODASYL9) din 1965, la care au participat reprezentanţi ai guvernului SUA
şi ai lumii afacerilor şi comerţului, s-a format Forţa 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 specificaţii
standard pentru un mediu care să permită crearea de baze de date şi
manipularea datelor. În 1969 a apărut un raport preliminar, iar în 1971
raportul definitiv. Propunerea grupului DBTG a identificat trei componente:
• schema de reţea - organizarea logică a întregii baze de date, aşa cum
este văzută de către administratorii bazei de date şi include o definire a
denumirii bazei de date, a tipului fiecărei înregistrări şi a componentelor
fiecărui tip de înregistrare;
• subschema - partea din baza de date, aşa cum este văzută de către
utilizator sau de către programul aplicaţie;
• un limbaj de gestionare a datelor, care să definească caracteristicile şi
structura datelor şi care să le manipuleze.
7
Acronim pentru Information Management System
8
Acronim pentru Integrated Data Store
9
COnference on DAta SYstems Language
10
Data Base Task Group
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 aplicaţie 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 către Institutul
Naţional American pentru Standarde (ANSI11), ulterior s-a realizat un număr
de sisteme conform propunerii DBTG. Acestea sunt cunoscute acum sub
denumirea de sisteme CODASYL sau DBTG. Abordările de tip CODASYL şi
ierarhice au reprezentat prima generaţie de SGBD-uri. Totuşi, aceste două
modele prezintă câteva dezavantaje fundamentale, printre care cele mai
importante sunt:
• trebuie scrise programe complexe pentru a răspunde chiar şi la interogări
simple, bazate pe accesul navigaţional orientat spre înregistrări;
• 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 relaţional. Acest
articol, apărut exact la momentul potrivit, analizează dezavantajele
abordărilor prezentate mai sus. De atunci, au fost implementate multe
sisteme SGBD relaţionale experimentale, primele produse comerciale
apărând la sfârşitul anilor 1970 şi începutul anilor 1980. De remarcat este
proiectul System R, de la Laboratorul de Cercetare IBM din San Jose,
realizat la sfârşitul anilor 1970 [Astrahan et al., 1976]. Acest proiect a fost
îndeplinit pentru a demonstra caracterul practic al modelului relaţional, prin
realizarea unei implementări a structurilor de date şi a operaţiilor acestuia,
fapt care a avut două consecinţe majore:
• dezvoltarea unui limbaj de interogare structurat, denumit SQL, care de
atunci a devenit limbajul standard pentru sistemele SGBD relaţionale;
• producerea de diverse sisteme SGBD relaţionale la scară comercială, în
decursul anilor 1980; de exemplu, sistemele DB2 şi SQL/DS de la IBM şi
Oracle de la compania cu acelaşi nume .
În prezent, există câteva sute de sisteme SGBD relaţionale, atât
pentru medii mainframe, cât şi pentru microcalculatoare, cu toate că multe
dintre ele extind definiţia modelului relaţional. Alte exemple de sisteme SGBD
relaţionale multiutilizator sunt: CS-OpenIngres de la compania Computer
Associates şi Informix de la Informix Software Inc. Câteva exemple de
sisteme SGBD relaţionale pentru microcalculatoare sunt: Access şi FoxPro
ale companiei Microsoft, Paradox şi Visual dBase ale companiei Borland şi
R:Base al companiei Microrim. Sistemele SGBD relaţionale sunt denumite
sisteme SGBD din a doua generaţie.
Cu toate acestea, modelul relaţional a cunoscut şi eşecuri - în
particular, datorită capacităţilor sale de modelare limitate. De-a lungul
11
Acronim pentru American National Standards Institute
timpului, s-au efectuat multe cercetări care au încercat să rezolve această
problemă. În 1976, Chen a prezentat modelul Entitate-Relaţie, care
reprezintă acum o tehnică de proiectare a bazelor de date larg acceptată. În
1979, însuşi Codd a încercat să rezolve câteva dintre esecurile din lucrarea
sa initială, printr-o versiune extinsă a modelului relaţional, denumită RM/T
(1979), urmată mai recent de RM/V2 (1990). Încercările 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 răspuns la complexitatea crescândă a aplicaţiilor bazelor de date,
au apărut două „noi” sisteme: sistemele SGBD orientate spre obiecte
(OODBMS12) şi sistemele SGBD de obiecte relaţionale (ORDBMS13). Totuşi,
spre deosebire de modelele anterioare, compoziţia acestora nu este clară, iar
această evoluţie reprezintă a treia generaţie de sisteme SGBD.
În prezent, datorită facilităţilor pe care le oferă, constatăm că cea mai
mare partea bazelor de date sunt realizate cu ajutorul unor SGBD-uri
relaţionale şi tot mai puţine se bazează pe cele de generaţia I. Totodată,
trebuie remarcat şi evidenţiat interesul tot mai mare faţă de utilizarea în
practică a SGBD-urilor orientate obiect.
Facilităţi oferite de un SGBD

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

Aşa cum vom arăta în continuare, utilizarea în practică a sistemelor de
gestiune a bazelor de date beneficiază de promiţătoare avantaje potenţiale,
însă, din păcate, există şi unele dezavantaje.
Avantajele SGBD-urilor
1.Controlul redundanţei datelor

Aşa cum am mai menţionat, în sistemele tradiţionale bazate pe fişiere
se făcea risipă de spaţiu prin stocarea aceloraşi informaţii în mai multe fişiere.
Prin contrast, în tratarea prin baze de date se încearcă eliminarea
redundanţei prin integrarea fişierelor, astfel încât să nu se stocheze mai
multe copii ale aceloraşi date. Totuşi, în tratarea prin baze de date nu se
elimină în întregime redundanţa, ci se controlează volumul inerent al acesteia
în baza de date. Uneori, pentru modelarea relaţiilor, este necesară dublarea
unor articole de date cheie. Alteori, pentru îmbunătăţirea performanţelor, este
de dorit să se dubleze unele articole de date.
2.Coerenţa datelor
Prin eliminarea sau controlul redundanţei se reduce riscul apariţiei
incoerenţei 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 toţi utilizatorii. Dacă un
articol de date este stocat de mai multe ori, iar sistemul este „conştient” de
aceasta, el poate garanta că toate copiile articolului respectiv sunt menţinute
coerente. Din păcate, multe dintre sistemele SGBD actuale nu garantează
automat acest tip de coerenţă.
3.Mai multe informaţii de la aceeaşi cantitate de date

Odată cu integrarea datelor operaţionale, ar putea fi posibil ca
organizaţia respectivă să extragă informaţii suplimentare din aceleaşi date.
4.Partajarea datelor
În general, fişierele sunt deţinute de către persoanele sau
departamentele care le utilizează. Pe de altă parte, baza de date aparţine
întregii organizaţii sau instituţii şi poate fi partajată de către toţi utilizatorii
autorizaţi. În acest mod, mai mulţi utilizatori partajează o cantitate mai mare
de date. Mai departe, se pot construi noi aplicaţii bazate pe datele existente
în baza de date, în timp ce datele adiţionale (care nu sunt stocate în mod
curent) se pot adăuga fără a fi necesară definirea repetată a tuturor cerinţelor
referitoare la acestea. Noile aplicaţii se pot baza şi pe funcţiile oferite de
către sistemul SGBD (cum ar fi definirea şi manipularea datelor şi controlul
concurenţei ş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 coerenţa datelor
stocate. De obicei, integritatea este exprimată în termeni de constrângeri,
care reprezintă reguli de coerenţă, pe care baza de date trebuie să le
respecte. Constrângerile se pot aplica articolelor de date dintr-o singură
înregistrare sau relaţiilor dintre diferite înregistrări. Spre exemplu, o
constrângere 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 obţine 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ă
întărească) constrângerile privind integritatea.
6.Securitate sporită
Securitatea se referă la protecţia bazei de date faţă de utilizatorii
neautorizaţi. Fără măsuri de securitate clare şi adecvate, integrarea face ca
datele să fie mult mai vulnerabile decât în cazul sistemelor bazate pe fişiere.
Totuşi, integrarea va permite administratorului bazei de date să definească
(iar bazei de date să întărească) 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 funcţie de poziţia pe care o are în organizaţie, un
anumit set de date). Accesul la date permis unui utilizator autorizat poate fi
limitat de tipul operaţiei 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
Vânzări ar putea avea acces numai la datele referitoare la proprietăţi, dar nu

şi la datele „sensibile”, cum ar fi detaliile despre salariile angajaţilor 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, organizaţionale, naţionale sau internaţionale
(pentru diferite aspecte, cum ar fi formatul datelor) care să faciliteze schimbul
de date între sisteme, convenţiile privind denumirile, standardele de
documentare, procedurile de reactualizare şi regulile de acces.
8.Economia de scală
Combinarea tuturor datelor operaţionale ale organizaţiei într-o singură
bază de date şi crearea unui set de aplicaţii care să funcţioneze pentru
această unică sursă de date pot avea ca rezultat micşorarea costurilor. În
acest caz, s-ar putea combina bugetele care ar fi fost alocate în mod normal
fiecărui departament pentru dezvoltarea şi întreţinerea propriului sistem
bazat pe fişiere, ceea ce ar putea duce la un total mai scăzut al cheltuielilor,
având ca rezultat o economie de scală. Bugetul combinat poate fi utilizat
pentru achiziţionarea unei configuraţii a sistemului mai adecvate cerinţelor şi
necesităţilor organizaţiei respective. Aceasta ar putea consta într-un
calculator cu o configuraţie mai bună, cu o putere de calcul sporită sau într-o
reţea de calculatoare mai mici.
9.Echilibrul între cerinţele aflate în conflict

Fiecare utilizator sau departament are propriile sale cerinţe, 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 operaţională a acesteia, care să ducă la folosirea
optimă a resurselor pentru organizaţia luată în ansamblu. Aceste decizii vor
realiza performanţe optime ale aplicaţiilor majore, posibil în detrimentul celor
mai puţin importante.
10.Îmbunătăţirea accesibilităţii datelor şi capacităţii de răspuns

Ca rezultat al integrării, datele care depăşesc graniţele unui
departament sunt direct accesibile utilizatorilor finali. Aceasta creează un
sistem cu o mult mai mare funcţionalitate potenţială decât ar putea fi folosită,
de exemplu, pentru furnizarea unor servicii mai bune utilizatorului final sau
clienţilor organizaţiei. Multe SGBD-uri oferă limbaje de interogare sau
generatoare de rapoarte, care permit utilizatorilor să formuleze întrebări ad-
hoc şi să obţină aproape imediat afişarea informaţiilor cerute la terminal, fără
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 următoarei comenzi SQL la un terminal:

SELECT*
FROM proprietate_de_inchiriat
WHERE type = 'Apartament' AND chirie> 400;
11.Productivitate crescută
Aşa cum am menţionat anterior, un SGBD oferă multe dintre funcţiile
standard, pe care ar trebui să le scrie în mod normal programatorul, în cazul
unei aplicaţii bazate pe fişiere. La nivel fundamental, SGBD-ul oferă toate
rutinele de nivel jos pentru manevrarea fişierelor, tipice în programele
aplicaţie. Furnizarea acestor funcţii permite programatorului să se
concentreze mai mult asupra funcţionalităţii specifice cerute de către
utilizatori, fără însă a se preocupa de detaliile de nivel jos privind
implementarea. Multe sisteme SGBD furnizează şi un mediu din a patra
generaţie, care constă în instrumente de simplificare a dezvoltării de aplicaţii
în domeniul bazelor de date. Aceasta are ca rezultat o productivitate crescută
a programatorului şi un timp redus de programare (împreună cu reducerea
corespunzătoare a costurilor).
12.Întreţinere îmbunătăţită datorită independenţei datelor

Descrierile datelor şi logicii de accesare a lor în cadrul sistemelor
bazate pe fişiere erau încorporate în fiecare program aplicaţie, ceea ce făcea
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 schimbări
importante în programele afectate de modificările produse. Prin contrast, într-
un SGBD, descrierile datelor sunt separate de aplicaţii, ceea ce face ca
acestea să fie imune la modificările din descrierea datelor. Această
caracteristică este cunoscută sub denumirea de independenţă faţă de date
(sau independenţa datelor). Realizarea independenţei datelor simplifică
substanţial întreţinerea aplicaţiilor din baza de date.
13.Concurenţă îmbunătăţită
Majoritatea sistemelor bazate pe fişiere se confruntau adesea cu o
problemă importantă, cu influenţe negative asupra ceea ce înseamnă
gestionarea eficientă a conţinutului unui baze de date. Astfel, dacă doi sau
mai mulţi utilizatori aveau permisiunea de a accesa simultan acelaşi fişier, se
întâmpla ca cele două accesări să se suprapună, ceea ce avea evident ca
rezultat pierderea informaţiilor sau chiar alterarea integrităţii datelor
respective. În ceea ce priveşte 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ţă garanţia evitării apariţiei unor astfel
de probleme.
14.Îmbunătăţirea serviciilor de salvare de siguranţă şi refacere

Multe sisteme bazate pe fişiere lasă în sarcina utilizatorului
responsabilitatea de a lua măsuri de protecţie a datelor, în cazul unor
defecţiuni ale sistemului de calculatoare sau ale programului aplicaţie.
Aceasta ar putea presupune realizarea unei copii de siguranţă a datelor la
intervale scurte de timp (spre exemplu, în fiecare zi). Apariţia unei defecţiuni
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ă facilităţi de minimizare a pierderilor (aferente prelucrărilor realizate) ca
urmare a unei defecţiuni.
Dezavantaje SGBD-urilor
Pe lângă avantajele menţionate anterior, fiecare SGBD comportă şi un
număr de dezavantaje, iar cele mai importante sunt menţionate în continuare.
1.Complexitatea
Proiectarea funcţionalităţii unui SGBD optim face ca acesta să devină
un element software extrem de complex. Proiectanţii ş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ă funcţionalitate, pentru a
putea profita de ea la maximum. Eşecul în înţelegerea sistemului poate
cauza fundamentarea şi luarea unor decizii greşite aferente etapei de
proiectare, care, în mod cert, pot conduce la consecinţe negative importante
pentru fiecare organizaţie sau instituţie specializată care dispune de un astfel
de sistem.
2.Costul
Costul unui SGBD variază semnificativ, în funcţie de mediu şi de
funcţionalitatea 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 deserveşte sute de utilizatori,
poate fi extrem de scump. Mai există şi cheltuielile periodice anuale de
întreţinere care reprezintă, de regulă, un procent din preţul acestuia. În acest
caz, este clar că vom alege un SGBD pentru gestionarea unei activităţi
numai în concordanţă cu necesităţile curente: nu are sens să achiziţionăm un
SGBD scump dacă nevoia nu o cere, însă nu recomandăm nici
achiziţionarea unui SGBD ieftin atunci când volumul de date, dar şi cel al
prelucrărilor de realizat este mare (mai ales în cazul gestionării datelor la
nivelul bazelor de date distribuite14).
3.Costurile adiţionale specifice componentelor hardware

Cerinţele de stocare pe suport fizic pentru un SGBD şi baza de date ar
putea necesita achiziţionarea unui spaţiu de stocare suplimentar. Mai mult,
pentru obţinerea performanţelor dorite, ar putea fi necesară cumpărarea unui
calculator mai performant, poate chiar unul destinat rulării SGBD-ului. Astfel,
14
Baza de date distribuită reprezintă un set de baze de date aflate pe mai multe calculatoare
şi care este văzut de către aplicaţie ca fiind o singură bază de date (aflată pe un singur
calculator) – adică baza de date văzută de către aplicaţie este fragmentată şi împărţită pe
mai multe calculatoare din reţea. O bază de date se spune că este distribuită dacă diferitele
componente ale acesteia sunt memorate în staţiile şi/sau serverul reţelei.
este clar că achiziţionarea de componente hardware adiţionale conduce la
creşterea cheltuielilor.
4.Costul conversiei
În unele cazuri, costul unui SGBD şi al componentelor hardware
adiţionale poate fi nesemnificativ, comparativ cu costul conversiei aplicaţiilor
existente, necesare ca acestea să poată funcţiona în noul SGBD şi în noua
configuraţie hardware. Acest cost include şi preţul instruirii personalului
pentru a putea utiliza noile sisteme şi, posibil, angajarea unui personal
specializat, care să ajute la conversia şi funcţionarea sistemului. Aceste
cheltuieli reprezintă unul dintre motivele principale pentru care unele
organizaţii se „împiedică” de sistemele existente şi nu pot trece la tehnologia
modernă specifică bazelor de date. Termenul de sistem moştenit este utilizat
uneori pentru a se face referire la un sistem mai vechi, de obicei inferior din
punct de vedere al funcţionalităţii.
Totodată, există şi situaţii în care anumite organizaţii renunţă la
actualizarea permanentă a componentelor hardware, determinate de
conversiile realizate la nivel software în detrimentul achiziţionării unui produs
software nou şi care este în concordanţă cu necesităţile cerute. Însă, această
soluţie este una importantă, cu implicaţii 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 funcţionalităţii fac din SGBD-uri elemente
software destul de cuprinzătoare, ce ocupă mult spaţiu pe suportul fizic şi
necesită o memorie15 substanţială pentru a funcţiona eficient şi corect.
6.Performanţa
De obicei, un sistem bazat pe fişiere este realizat pentru o anumită
aplicaţie, cum ar fi facturarea. Ca rezultat, performanţele sunt, de regulă,
foarte bune. Totuşi, SGBD-ul este creat pentru a fi mai general, pentru a oferi
mai multe funcţionalităţi, nu una singură. Rezultatul este că unele aplicaţii ar
putea să nu mai funcţioneze tot atât de rapid sau la fel de eficient.
7.Impactul crescut al unei defecţiuni

Centralizarea resurselor măreşte vulnerabilitatea sistemului. Din
moment ce toţi utilizatorii şi toate aplicaţiile se bazează pe disponibilitate din
partea SGBD-ului, eşecul oricărei componente a acestuia poate duce la
sistarea tuturor operaţiilor.
15
Evident, ne referim la memoria RAM (Random Access Memory) a calculatorului pe care
se găseşte şi rulează SGBD-ul respectiv.
Componentele unui SGBD
Principalele componente ale unui SGBD sunt [Georgescu, Georgescu,
2005, p.75-81]:
• motorul SGBD – este componenta care asigură interfaţa dintre
subsistemul de proiectare şi cel de execuţie pe de o parte, şi datele bazei
de date pe de altă parte şi are rolul de a asigura accesul fizic la datele
bazei de date. Toate acţiunile motorului SGBD sunt realizate unitar şi
respectă restricţiile impuse de legăturile dintre date, dar şi de regulile de
integritate ale bazei de date definite în dicţionarul de date. Principalele
responsabilităţi ale motorului SGBD sunt:
realizează gestionarea tranzacţiilor la nivelul unei baze de date;
permite regăsirea datelor pe baza informaţiilor de adresare din
fişierele de index;
salvarea şi restaurarea datelor;
blocarea şi deblocarea datelor în cazul operaţiilor fizice la nivelul
memoriei externe;
• subsistemul instrumentelor de proiectare – dispune de un set de
instrumente software care permit proiectarea şi generarea bazei de date
şi a aplicaţiilor care descriu modul de utilizare a bazei de date. Această
componentă permite definirea:
structurii tabelelor din baza de date;
machetelor de interfaţă cu utilizatorul;
a formatului rapoartelor şi cererilor de interogare a bazei de date.
Subsistemul instrumentelor de proiectare poate include:
limbaje de descriere a datelor (LDD)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 interfeţei cu
utilizatorul, a rapoartelor, meniurilor, etc.;
un sistem de asistenţă on-line pentru autodocumentarea
utilizatorului.
• subsistemul de execuţie – permite execuţia aplicaţiilor sau cererilor de
consultare a bazei de date, formulate prin utilizarea instrumentelor
subsistemului de proiectare, prin consultarea dicţionarului de date şi
generarea tranzacţiilor. Aceasta este componenta care garantează
autonomia logică a datelor în baza de date şi are rolul de a intermedia
operaţiile cu baza de date prin consultarea descrierii organizării logice a
datelor memorate în structura bazei de date. Practic, fiecare operaţie de
actualizare sau consultare a bazei de date se realizează prin identificarea
16
Un limbaj de descrierea a datelor permite descrierea componenţei bazei de date, a structurii
acesteia , a relaţiilor dintre componentele ei, precum şi a tuturor drepturilor de acces ale utilizatorilor
la baza de date.
formatelor de descriere a datelor din dicţionarul de date şi conectarea
acestor descrieri din schema internă a bazei de date
Funcţiile SGBD-ului
În [Velicanu et al., 2003, p.104-107] se arată că îndeplinirea tuturor
obiectivelor unui SGBD se realizează prin intermediul unor componente care
permit efectuarea unor operaţii specifice. În funcţie de natura lor, dar şi de
scopul urmărit, operaţiile pot fi grupate pe activităţi. Activităţile acceptă şi ele
o grupare pe funcţii astfel încât, una sau mai multe activităţi, relativ omogene,
vor realiza o funcţie anume. Ţinând cont de complexitatea unui SGBD, de
facilităţile pe care le pune la dispoziţie, de limbajele utilizate, precum şi de
modul de implementare al modelului de date, gruparea activităţilor pe funcţii
are un anumit caracter relativ.
Plecând de la modelul de date pe care îl implementează, SGBD-urile
se caracterizează printr-un număr de particularităţi identificate prin operaţii şi
activităţi specifice. În pofida acestor particularităţi, există câteva funcţii
general valabile pentru toate tipurile de SGBD; acestea sunt funcţii
importante, pe care un sistem software, dacă nu le are în totalitate, nu poate
fi considerat SGBD. Astfel, principalele funcţii pe care le putem atribui unui
SGBD sunt: descrierea datelor, manipularea datelor, utilizarea şi
administrarea bazei de date.
Descrierea datelor
Prin intermediul funcţiei de descriere a datelor, fiecare SGBD permite
definirea unei structuri a bazei de date cu ajutorul limbajului de definire a
datelor (LDD). Definirea datelor poate fi realizată la nivel conceptual, logic şi
fizic. Se descriu atributele din cadrul structurii bazei de date, legăturile dintre
entităţile acesteia sau dintre atributele aceleiaşi entităţi, se definesc criteriile
de validare a datelor (dacă este cazul), metodele care asigură accesarea
datelor, precum şi aspectele care se referă la asigurarea integrităţii datelor.
Concretizarea acestei funcţii este schema bazei de date, memorată în cod
intern. Memorarea se face într-un fişier, ceea ce permite afişarea şi
actualizarea structurii bazei de date, în orice moment de timp.
Această funcţie a fost mult automatizată în timp, limbajul de descriere
a datelor beneficiind în prezent de puţine comenzi. Acest limbaj este specific
fiecărui SGBD, dar el mereu realizează descrierea lor conform elementelor
modelului de date pe care îl implementează SGBD-ul respectiv. Astfel se
realizează definirea şi descrierea entităţilor şi a caracteristicilor lor, definirea
legăturilor dintre obiectele identificate (asocierile) şi a regulilor de integritate
specifice modelului de date.
Manipularea datelor
Funcţia de manipulare a datelor este cea mai complexă şi realizează
actualizarea şi regăsirea datelor din baza de date, cu ajutorul limbajului de
manipulare a datelor17.
17
În literatură întâlnim frecvent şi Limbaj de Manevrare a Datelor
Manipularea datelor este cea mai folosită funcţie în bazele de date,
fiind cea mai bine suportată de sistemul de gestiune a bazelor de date faţă
de oricare alt sistem de gestionare a datelor din memoria externă. Practic, un
SGBD manipulează datele într-o manieră eficientă, folosind în acest scop
diferite tehnici şi metode de optimizare a accesului şi a alocării spaţiului din
memoria calculatorului.
Menţionam în paragraful anterior că limbajul de manipulare a datelor
este cel care asigură realizarea acestei funcţii. În ceea ce-l priveşte, acest
limbaj trebuie să respecte restricţiile de integritate a datelor şi să
implementeze operatorii din modelul de date pe care se bazează SGBD-ul
căruia îi aparţine.
Această funcţie presupune derularea următoarelor activităţi:
• încărcarea datelor în baza de date - se realizează prin operaţii
automatizate sau programate ce asigură şi criteriile de validare necesare;
• actualizarea bazei de date – se referă la operaţiile de adăugare,
modificare şi ştergere de înregistrări. La operaţiile de adăugare şi de
modificare se păstrează aceleaşi criterii de validare care s-au folosit şi la
activitatea de încărcare a datelor. Actualizarea se realizează numai
autorizat, prin asigurarea unei protecţii corespunzătoare a datelor, pentru
a se păstra coerenţa bazei de date.
• prelucrarea datelor – presupune realizarea operaţiilor de selecţie,
ordonare, etc. efectuate asupra entităţilor bazei de date. Acestea sunt, de
obicei, operaţii pregătitoare activităţii de regăsire a datelor. Multe din
operaţiile de prelucrare sunt realizate cu ajutorul operatorilor din modelul
de date pe care îl implementează SGBD-ul.
• regăsirea (interogarea) datelor – presupune realizarea operaţiilor de
vizualizare (afişare pe ecran, imprimare pe hârtie), răsfoire, editarea unor
documente de ieşire (rapoarte). Documentele de ieşire pot fi intermediare
sau finale şi se pot obţine pe diferiţi suporţi tehnici de informaţie (ecran,
hârtie, mediu magnetic, mediu optic). Ele pot avea cele mai diferite forme
(punctuale, liste, rapoarte, grafice, imagini, sunet, video, etc) şi se pot
obţine după cele mai diferite criterii de regăsire.
Funcţia de utilizare
Această funcţie are rolul de a asigura interfeţele necesare care să
permită comunicarea utilizatorilor cu baza de date (cu alte cuvinte, să asigure
legătura dintre utilizator şi baza de date). Pentru realizarea acestei funcţii,
SGBD-ul trebuie să ofere facilităţi pentru mai multe categorii de utilizatori ai
bazei de date, şi anume: neinformaticieni, specialişti (informaticieni) şi
administratorul.
Utilizatorii neinformaticieni reprezintă principala categorie a
beneficiarilor de informaţii (utilizatori finali şi intensivi) din baza de date.
SGBD-ul le oferă acestora limbaje neprocedurale, dar şi alte facilităţi de
interogare (generatoare, utilitare, etc.) a bazei de date într-o formă simplă şi
interactivă. Aceşti utilizatori nu trebuie să cunoască structura bazei de date şi
nu trebuie să ştie să programeze, SGBD-ul sprijinindu-i în manieră interactivă
în utilizarea bazei de date. În acest sens SGBD-ul oferă:

• meniuri cu opţiuni sugestive;
• ferestre de lucru;
• şabloane pentru diferite forme;
• asistenţi tip Wizard;
• autodocumentarea (help-uri, mesaje/ferestre explicative).
Spre deosebire de utilizatorii neinformaticieni, cei specialişti în
informatică sunt în măsură să creeze structura bazei de date şi să realizeze
proceduri complexe de exploatare a acesteia. SGBD-ul oferă acestor
utilizatori limbajul de descriere şi limbajul de manipulare a datelor precum şi
interfeţe cu limbaje universale. Acestea sunt de complexitate şi putere diferită,
de la un SGBD la altul, oferind atât elemente neprocedurale cât şi
procedurale specialistului în informatică. Cu aceste elemente el poate să
descrie schema bazei de date şi să asigure manipularea complexă a datelor.
Administratorul bazei de date este un utilizator special şi are un rol
hotărâtor în ceea ce priveşte funcţionarea optimă a întregului sistem. Datorită
importanţei acestei categorii de utilizatori, SGBD-ul are o funcţie distinctă în
acest sens.
Administrarea bazei de date

Funcţia de administrare este una destul de complexă şi din acest
motiv se consideră că este doar de competenţa administratorului bazei de
date.
Administratorul, care are o bogată experienţă de analiză, proiectare şi
programare, organizează şi administrează baza de date în toate etapele de
realizare a acesteia. Astfel, el organizează baza de date conform unei
anumite metodologii, realizează schema conceptuală a acesteia şi
coordonează proiectarea ei. Pentru toate aceste aspecte, SGBD-ul oferă o
serie de instrumente CASE18, precum şi o serie de utilitare specializate.
În etapa de exploatare a bazei de date, administratorul îndeplineşte
mai multe roluri:
• de a autoriza accesul la date (crează conturi de acces, parole, etc.);
• de a reface baza de date în caz de incidente (prin jurnalizare, copii de
siguranţă);
• de a utiliza eficient spaţiul de memorie internă şi externă (prin organizare,
rutine de optimizare);
• de a realiza o serie de analize statistice din baza de date (număr şi tip de
utilizatori, număr de accese, număr de actualizări, etc.).
18
Instrumentele CASE (Computer Aided Software Engineering) sunt aplicaţii 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 aplicaţii. Obiectivul principal al instrumentelor CASE constă în
punerea în practică a produselor–program de proiectare şi realizarea software–lui cu ajutorul
calculatorului. Instrumentele oferite de CASE sunt utilizabile din faza de definire a cerinţelor până la
întreţinerea fizică a produsului informatic [Oprea, 1999, p.123].

Pentru fiecare din activităţile menţionate mai sus, SGBD-ul oferă
instrumente şi tehnici de lucru.
În cazul lucrului în reţea, 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 reţelei, iar utilizatorii
sunt de toate tipurile şi în număr mare.

1. Ce este SGBD-ul?
2. Care este diferenţa dintre limbajele procedurle şi cele neprocedurale?
3. Ce reprezintă coerenţa 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. Prezentaţi pe scurt componentele unui SGBD.
8. Ce este motorul SGBD?
9. Prezentaţi principale caracteristici ale subsistemului instrumentelor de
proiectare.
10. Prezentaţi principale caracteristici ale subsistemului de execuţie.
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 găsesc pe platforme
diferite;
c. utilizatori şi sistemul de operare;
d. două sisteme de operare care rulează pe platforme diferite.
2. SGBD-urile relaţionale sunt denumite SGBD-uri din:
a. I-a generaţie;
b. a II-a generaţie;
c. a III-a generaţie;
d. a IV-a generaţie.
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 prin intermediul limbajului de
manipulare a datelor;
d. actualizarea datelor şi extragerea lor prin intermediul limbajului
de manipulare a datelor.

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 înregistrări;
b. limbajele neprocedurale tratează datele unei baze de date
înregistrare cu înregistrare, în timp ce cele procedurale
lucrează cu seturi de înregistrări;
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 fişiere;
b. conversia componentelor hardware în unele mai performante;
c. conversia aplicaţiilor existente la un moment dat într-o
organizaţie;
d. conversia unei componente hardware în una software.
6. Motorul SGBD este componenta care:

a. permite proiectarea şi generarea bazei de date şi a aplicaţiilor
care descriu modul de utilizare a bazei de date;
b. are rolul de a asigura accesul fizic la datele bazei de date;
c. permite execuţia aplicaţiilor 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.

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 execuţie al SGBD-ului este componenta care:
a. permite proiectarea şi generarea bazei de date şi a aplicaţiilor
care descriu modul de utilizare a bazei de date;
b. are rolul de a asigura accesul fizic la datele bazei de date;
c. permite execuţia aplicaţiilor sau cererilor de consultare a bazei
de date;
d. permite definirea structurii tabelelor din baza de date.

Abordarea relaţională a bazelor de date
Capitolul IV – Abordarea relaţională a bazelor de date
****************************************************************************************
Principalul obiectiv al capitolului IV este acela de a oferi o viziune generală

asupra relaţionării datelor dintr-o bază de date. Astfel, în acest capitol am
urmărit:
• prezentarea regulilor lui Codd pe care se bazează întreaga abordare
relaţională;
• identificarea şi prezentarea fundamentelor specifice modelului
relaţional;
• definirea tipurilor de chei întâlnite la nivelul unei relaţii;
• definirea tipurilor de legături dintre relaţii; înţelegerea mecanismului
cheii străine;
• prezentarea principalilor operatori ai algebrei relaţionale.
****************************************************************************************
Aşa cum reiese din literaura de specialitate, au existat în timp mai

multe modele de reprezentare a informaţiilor la nivel logic şi de operare:
• reţea;
• ierarhic;
• relaţional.
În cadrul acestui capitol vom analiza detaliat cel mai utilizat model de
reprezentare, utilizat în prezent pe scară largă, şi anume modelul relaţional.
Regulile lui Codd

Pentru a fi considerat relaţional, fiecare sistem de gestiune a bazelor
de date trebuie să respecte nişte reguli, întâlnite în literatură sub numele de
regulile lui Codd. Modelul de stocare a datelor sub forma unei baze de date
relaţionale s-a dezvoltat pornind de la un articol apărut în anul 1970, „A
relational Model of Data for Large Shared Data Banks”, şi care aparţine
cercetătorului Codd [Codd, 1970, p.377-387]. Astfel, regulile enunţate de
cercetător sunt prezentate în continuare:

R0 – Gestionarea datelor la nivel de relaţie.
Toate informaţiile din baza de date sunt gestionate numai prin mecanisme
relaţionale. Rezultă că SGBD-ul trebuie să-şi îndeplineacă toate funcţiile
utilizând ca unitate de informaţie mulţimea, cu alte cuvinte, să utilizeze
diferite limbaje, aşa cum este şi SQL, care să opereze la un moment dat pe o
relaţie.
R1 – Reprezentarea logică a datelor.
Informaţiile bazei de date relaţionale 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ă.
Informaţiile referitoare la numele tabelelor, al coloanelor, domeniilor,
definiţiilor tabelelor virtuale, al restricţiilor de integritate trebuie să fie
memorate tot în tabelele de date.
R2 – Garantarea accesului la date
Accesarea tuturor informaţiilor 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
semnificaţia unor date lipsă sau care nu pot fi aplicate. Valorile NULL (care
sunt diferite de şirurile de caractere spaţiu sau de cele vide) sunt importante
pentru implementarea restricţiilor de integritate (integritatea entităţii şi
integritatea referenţială) aferente modelului relaţional.
R4 – Regula specifică metadatelor

Informaţiile referitoare la descrierea bazei de date – metadatele – trebuie
specificate la nivel logic în manieră identică cu descrierea datelor propriu-
zise. Practic, utilizatorul va aplica asupra descrierii bazei de date aceleaşi
operaţii ca şi la datele obişnuite. Sistemul nu trebuie să facă diferenţe între
descrierea datelor şi a metadatelor utilizând o singură structură, şi anume
cea relaţională.
R5 – Facilităţi ale limbajelor utilizate
Un sistem relaţional trebuie să facă posibilă utilizarea mai multor limbaje, în
diferite moduri. Trebuie să existe cel puţin un limbaj de nivel înalt ale cărui
instrucţiuni să poată exprima oricare din următoarele operaţii: definirea
tabelelor, a tabelelor virtuale, manevrarea datelor, definirea tuturor restricţiilor
de integritate, garantarea şi autorizarea accesului la date, precum şi
prezentarea limitelor tranzacţiilor.
R6 – Actualizarea bazei de date
Fiecare SGBD trebuie să permită manipularea unei tabele (de bază sau
virtuală), atât în cazul actualizării datelor în baza de date, cât şi pentru
operaţii de regăsire a acestora. În cazul unei operaţii care va modifica
conţinutul unei baze de date, trebuie să se lucreze la un moment dat pe o
relaţie întreagă.

R7 – Independenţa fizică a datelor
Programele de aplicaţie nu trebuie să fie afectate de modificările realizate în
modul de reprezentare a datelor sau în metodele de acces. O schimbare a
structurii fizice a datelor nu trebuie să blocheze funcţionarea programelor de
aplicaţie.
R8 – Independenţa logică a datelor
Programele de aplicaţie nu trebuie să fie afectate de modificările efectuate
asupra relaţiilor care formează baza de date.
R9 – Regula aferentă restricţiilor de integritate
Toate restricţiile 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 aplicaţie să fie logic
aceleaşi cu cele utilizate în cazul în care datele sunt fizic centralizate. Practic,
în această situaţie, utilizatorul ar trebui să perceapă aceste date ca fiind
centralizate şi nu aparţinând unor staţii diferite de lucru, aflate în zone
geografice diferite.
R11 – Actualizarea tabelelor virtuale
În cadrul abordării relaţionale, 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 scăzut orientat pe
prelucrarea tuplurilor şi nu pe cea a relaţiilor, atunci acest limbaj nu trebuie
folosit pentru a se evita restricţiile de integritate sau restricţiile introduse prin
utilizarea limbajelor relaţionale de nivel înalt.
Fundamente ale modelului relaţional

Înainte de a prezenta principalele aspecte care caracterizează modelul
relaţional, considerăm că este oportună definirea conceptului de bază de
date relaţională. După o îndelungă analiză şi sinteză a definiţiilor formulate
de cercetătorii consacraţi ai domeniului, dar şi profesori de seama care au
analizat această paradigmă, putem afirma pe scurt că o bază de date
relaţională reprezintă colecţii organizate de date şi corelate din punct de
vedere logic. La o simplă analiză a definiţiei, observăm că ea impune două
direcţii de studiu:
1. colecţii organizate de date;
2. colecţii corelate logic.
În acest context, pe parcursul capitolului, plecând de la prezentarea
aspectelor fundamentale care caracterizează modelul relaţional al bazelor de
date, vom argumenta definiţia prezentată anterior şi implicit cele două direcţii
de studiu.
Atunci când luăm în discuţie abordarea relaţională a bazelor de date,
vom analiza în principal trei direcţii:

• structura datelor – are în vedere definirea domeniilor şi a relaţiilor
corespunzătoare acestor domenii;
• integritatea datelor – se referă la definirea restricţiilor de integritate
care au rolul de a proteja datele bazei de date; lipsa unor restricţii de
integritate ar putea avea ca efect alterarea conţinutului bazei de date şi
obţinerea unor rezultate eronate;
• prelucrarea datelor – se realizează prin intermediul operaţiilor
specifice algebrei relaţionale sau calculului relaţional.
După cum sugerează şi numele, modelul relaţional se bazează pe
noţiunea de relaţie care este definită din punct de vedere matematic ca o
submulţime a produsului cartezian a unei liste (finite) de mulţimi, numite
domenii. Fiecare element al unei relaţii poartă numele de tuplu, iar numărul
de domenii se numeşte aritate. Într-o relaţie, fiecare domeniu se identifică
printr-un nume, numit atribut, iar mulţimea numelor atributelor unei relaţii
formează schema acesteia. Fie relaţia din exemplul 4.1:
Exemplul 4.1. Student (cnp, nr_matr, nume, pren, facult, spec)
Astfel, în exemplul anterior am definit relaţia Student care include atributele:

• cnp – definit pe domeniul cod numeric personal;
• nr_matr – definit pe domeniul număr_matricol;
• nume – definit pe domeniul nume;
• pren – definit pe domeniul prenume;
• facult – defint pe domeniul facultate;
• spec – definit pe domeniul specializare;
De asemenea, formulând altfel, putem spune că în exemplul 4.1 am
definit relaţia Student cu schema dată de atributele cnp, nr_matr, nume, pren,
facult, spec. În exemplul 4.2 sunt prezentate trei tupluri pentru relaţia Student
defintă în exemplul 4.1.
Exemplul 4.2
Student ( cnp nr_matr nume pren facult spec )
1701212120139 1234 Popa Dan FSE IE
2731210176143 1987 Darie Alina FD AP
1801009129145 4432 Mihnea Ion FSE FB
În ceea ce priveşte o relaţie, ordinea de apariţie a atributelor este

absolut nesemnificativă şi acelaşi lucru îl putem spune şi despre tupluri.
Aşa cum se observă, un tuplu se obţine prin atribuirea de valori
atributelor relaţiei. În ceea ce priveşte tuplurile unei relaţii (care se mai
numesc şi realizări) trebuie spus că nu pot exista două sau mai multe tupluri
identice. Altfel spus, toate tuplurile unei relaţii trebuie să difere cel puţin prin
valoarea unui atribut: cheia.

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

nr_matr chei candidat?” am primi un singur răspuns: „DA”. Aşa să fie oare?
Nu este aşa. Iar argumentul este dat de exemplul 4.4.
Exemplul 4.4
1701212120139 1234 Popa Dan FSE IE
2731210176143 1987 Darie Dan FD AP
2731210176143 5634 Darie Dan FSE FB
Aşa cum observăm, pe domeniul aferent atributului cnp, avem două

valori identice: este situaţia în care o persoană este studentă la două facultăţi
diferite (şi nu este singura situaţie posibilă). Deci, nici atributul cnp nu poate fi
cheie candidat. De ce am ajuns să facem o astfel de greşeală şi să
considerăm că cnp poate fi cheie? Probabil că ne-am gândit la faptul că nu
pot existat două persoane cu acelaşi CNP. Este adevărat: nu există două
persoane cu acelaşi CNP, însă schema relaţiei Student nu conţine doar
atribute despre o persoană, ceea ce înseamnă că trebuia să ne gândim dacă
pentru un anume CNP putem identifica cel puţin o valoare a unui alt atribut
care să se modifice faţă de tuplul de la care am plecat.
În ceea ce priveşte atributul nr_matr, putem spune că el este cheie
candidat. Cum arătăm asta? Să plecăm de la situaţie din exemplul 4.5.
Exemplul 4.5
Student ( Cnp nr_matr nume pren facult spec )
1701212120139 1234 Popa Dan FSE IE
? 1234 ? ? ? ?
Astfel, considerăm că avem un tuplu care reprezintă un student cu

numărul matricol 1234, care este la facultatea FSE, specializarea IE. Dacă
vom putea înlocui semnul întrebării aferent unui atribut cu o valoare diferită
de cea aflată pe celălalt tuplu (evident, pentru acelaşi atribut), atunci cele
două tupluri diferă, ceea ce înseamnă că putem avea valori duplicate pe
domeniul respectiv de valori. În mod cert, un student cu o anumită matricolă
(în cazul nostru 1234) nu poate avea alt cod numeric personal, alt nume sau
alt prenume. De asemenea, un student nu poate fi la două specializări
diferite (în aceeaşi facultate sau în facultăţi diferite) având aceeaşi matricolă.
Asta înseamnă că dacă pe tuplul doi am avea 1234 ca matricolă, atunci toate
celelalte valori ar fi identice cu cele de la primul tuplu, situaţie care ar face ca
cele două tupluri să fie identice şi aşa cum aminteam în prima parte, o astfel
de situaţie nu este permisă (acest aspect este reprezentat în exemplul 4.6).
Deci, atributul nr_matr este cheie candidat a relaţiei Student.
Exemplul 4.6
1701212120139 1234 Popa Dan FSE IE
1701212120139 1234 Popa Dan FSE IE
Odată identificată o cheie candidat, procesul nu este finalizat. În

continuare va trebui să căutăm şi diferite combinaţii de atribute care ar putea
fi cheie. Singurul lucru clar este acela că atributul nr_matr nu poate face
parte din nici o cheie compusă (cheia trebuie să fie formată din numărul
minim de atribute care identifică în mod unic tuplurile unei relaţii). Dacă vom
avea în vedere algoritmul descris anterior, vom mai identifica o cheie
candidat: cnp+facult+spec. De ce toate trei? Dacă ne-am gândi la atributele
cnp+facult am vedea că un student într-o facultate, poate fi la mai multe
specializări (spre exemplu, la forme diferite de învăţământ) în timp ce pentru
combinaţia de atribute cnp+spec ar putea apare valori duplicate în cazul în
care mai multe facultăţi ar avea o aceeaşi specializare. Însă, în situaţia în
care le analizăm pe toate trei am ajunge la concluzia că o persoană nu poate
face aceeaşi specializare de două ori într-o facultate19.
Sintetizând, pentru relaţia Student am identificat două chei candidat:
• nr_matr;
• cnp+facult+spec.
Dintre cele două chei candidat, vom alege cheia primară ca fiind
nr_matr deoarece are mai puţine atribute decât cealaltă cheie, ceea ce
înseamnă că, în final vom avea:
• chei candidat: nr_matr, cnp+facult+spec;
• cheie primară: nr_matr;
• cheie alternantă: cnp+facult+spec.
Astfel, în final, relaţia noastră ar arăta astfel:
Exemplul 4.7. Student (cnp, nr_matr, nume, pren, facult, spec)
Aşa cum observăm, atributul/atributele care formează cheia primară a

relaţiei vor apare subliniate.
În mod normal, relaţia de mai sus este una nenormalizată şi este
evident că ea introduce redundanţă. Astfel, ar fi mai simplu dacă datele
referitoare la facultăţi, respectiv specializări, le-am gestiona separat, în relaţii
de sine stătătoare. În acest caz, redundanţa ar fi în mare măsură înlăturată,
iar procesul de identificare a cheilor ar fi mult simplificat. Astfel, în exemplul
4.8 vom descompune relaţia în alte trei relaţii:
19
Mecanismul de identificare corectă şi completă a cheilor unei relaţii se va realiza numai după
parcurgerea şi înţelegerea procesului de normalizare a unei baze de date relaţionale (la pagina 18 au
fost prezentate succint câteva aspecte de bază specifice normalizării). Pentru cei interesaţi să ştie mai
multe despre procesul de normalizare şi postnormalizare, recomandăm cartea profesorului M. Fotache:
Proiectarea bazelor de date: Normalizare şi postnormalizare. Implementări SQL şi Oracle.
Exemplul 4.8
Student (cnp, nr_matr, nume, pren)
Facultate (facult, profil)
Specializare (spec, formă_înv)
În relaţia Facultate, atributul facult este cheie primară deoarece
considerăm că nu pot exista două facultăţi cu acelaşi nume în cadrul unei
universităţi. De asemenea, atributele spec şi formă_înv formează cheia
primară în relaţia Specializare numai luate împreună deoarece o anumită
specializare poate apare la diferite forme de învăţământ (spre exemplu,
specializarea Contabilitate şi Informatică de Gestiune are studenţi şi la forma
de învăţământ Zi, şi la Ifr).
Astfel, prin descompunerea relaţiei iniţiale în cele trei relaţii din
exemplul 4.8 am argumentat prima parte a definiţiei bazei de date relaţionale.
Aşa cum observăm, în acest moment structura noastră este formată din trei
colecţii organizate în care:
• Student conţine doar date de strudenţi;
• Facultate include ca realizări (tupluri) doar facultăţile gestionate;
• Specializare care se referă la specializările fiecărei facultăţi gestionate.
Legături între relaţii
Dacă analizăm cu atenţie relaţiile din exemplul 4.8 observăm că

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

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

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

12121 2
23456 2
187654 3
Prin intermediul relaţiilor Client şi Legitimaţie încercăm să modelăm

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

Exemplul 4.10:
Client ( cnp nume pren localitate nr_leg )
1701212120139 Popa Dan Galaţi 23456
2711010120121 Darie Alina Brăila 12121
1721209145123 Preda Marin Galaţi 187654
Legitimaţie ( nr_leg valabilitate cnp )

12121 2 2711010120121
23456 2 1701212120139
187654 3 1721209145123
După migrarea cheii primare sub forma cheii străine, putem spune că
am realizat legătura între relaţiile asociate, astfel încât să putem spune
despre un client ce număr de legitimaţie are, sau plecând de la numărul
legitimaţiei, să putem identifica fără ambiguitate care este deţinătorul
acesteia.
Legătura binară 1-n (unu la mai mulţi)

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

61 CIG ZI
51 FB ZI
52 FB IFR
Pentru a avea o evidenţă clară a apartenenţei unui student la o

specializare, va trebui să realizăm legătura dintre cele două relaţii. Ca şi în
cazul primului tip de legătură, şi de această dată vom pleca de la
identificarea tipurilor de relaţii, răspunzând pe rând la întrebarea: „Unui tuplu
din relaţia X câte tupluri în relaţia Y îi pot corespunde”, unde X şi Y sunt cele
două relaţii pe care le asociem.
a. Identificarea tipului pentru relaţia Student: întrebarea la care trebuie să
răspundem este: „Un student la câte specializări poate fi?”. La această
întrebare, o parte din cititori ar putea spune că un student poate fi la una
sau mai multe specializări, în timp ce alţii consideră că un student nu
poate fi decât la o singură specializare. Răspunsul corect este cel de-al
doilea deoarece un student, care are asociată o anumită matricolă, nu

poate fi la mai multe specializări. Este clar că o persoană, cu un anume
cod numeric personal, poate fi la mai multe specializări, caz în care
numărul matricol este altul. Altfel spus, studentul Popa Dan cu matricola
1111 nu poate aparţine decât unei singure specializări. Concluzionând
vom afirma despre Student că este relaţie fiu.
b. Identificarea tipului pentru relaţia Specializare – în acest caz, răspunsul la
întrebarea: „La o specializare câţi studenţi pot fi înmatriculaţi?” este „mai
mulţi”, ceea ce înseamnă că unui tuplu din relaţia Specializare îi
corespund mai multe tupluri din relaţia Student. În acest caz, Specializare
este relaţie părinte.
Plecând de la analiza făcută anterior, am stabilit că relaţia Student
este fiu în timp ce relaţia Specializare este părinte: legătura dintre cele două
se va realiza prin migrarea cheii primare din relaţia părinte (cod_spec din
Specializare) sub formă de cheie străină în relaţia Student, iar modelul va
arăta ca în exemplul 4.12.
Exemplul 4.12:
Student ( nr_matr cnp nume pren cod_spec )
1111 1701212120139 Popa Dan 61
2222 2711010120121 Darie Alina 52
3333 1721209145123 Preda Marin 61
Specializare ( cod_spec spec formă_înv )

61 CIG ZI
51 FB ZI
52 FB IFR
În exemplul 4.12 observăm că, după crearea legăturii, suntem în

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

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

Exemplul 4.13:
Factură ( serie_fact nr_fact val_fact data_fact )
DX 1111 100 10.10.2008
VR 2222 200 10.10.2008
DF 3333 300 12.10.2008
Produs ( cod_produs den_prod um stoc )

11 Telefon Nokia Buc 0
22 TV Samsung Buc 2
33 Laptop Asus Buc 2
Considerăm că relaţia Factură permite gestionarea facturilor primite de

un comerciant, în timp ce în relaţia Produs sunt gestionate produsele
comercializate. Odată ce am considerat atributul cod_produs ca fiind cheia
primară a relaţiei Produs vom presupune că nu vor exista două produse care
să aibă acelaşi cod, garantându-se astfel (prin semantica specificată)
unicitatea valorilor pe domeniul atributului cod_produs. Totodată, atributul
stoc are rolul de a gestiona cantitatea aferentă unui produs care se găseşte
la un moment dat în stocul comerciantului.
Plecând de la cele două relaţii, dorim să punem în evidenţă care este
conţinutul fiecărei facturi (produsele şi cantităţile conţinute de fiecare factură).
Iniţial, vom identifica tipul relaţiilor pentru a putea realiza legătura dintre ele.
Astfel, relaţia Factură este părinte deoarece considerăm că o factură poate
conţine unul sau mai multe produse. Totodată, si relaţia Produs este tot
părinte deoarece un produs poate fi achiziţionat prin intermediul mai multor
facturi. Deci, ambele relaţii sunt de tipul părinte; asta înseamnă că se va crea
o nouă relaţie, care va avea cheia primară formată din cheile primare ale
celor două relaţii asociate.
Exemplul 4.14:
Aprovizionare ( serie_fact nr_fact cod_produs cant_aprov )
DX 1111 11 10
DX 1111 33 15
DF 3333 11 5
Aşa cum se observă, legătura de tipul mai mulţi la mai mulţi a fost
pusă în evidenţă prin noua relaţie generată: Aprovizionare. În cadrul acesteia,
pe primele două tupluri am pus în evidenţă faptul că o factură (DX 1111)
poate conţine mai multe produse (conţine produsele cu codul 11 şi 33) în
timp ce un produs (cel cu codul 11) poate fi achiziţionat prin intermediul mai
multor facturi (se găseşte atât pe factura DX 1111 cât şi pe DF 3333).
În cadrul relaţiei Aprovizionare observăm un nou atribut, care nu se
regăsea la nivelul relaţiilor pe care le-am asociat. Acest atribut apare în
cadrul acestei noi relaţii deoarece o realizare a acestuia are loc numai atunci
când asociem câte un tuplu din fiecare relaţie (nu putem avea o cantitate
aprovizionată dacă există produsul, dar nu există factura şi, în acelaşi timp,
nici dacă există factura şi nu există produsul).

Legătura dintre trei sau mai multe relaţii
Atunci când asociem mai mult de două relaţii, legătura dintre ele se
realizează prin definirea unei noi relaţii, care va avea cheia primară formată
din cheile primare ale tuturor relaţiilor, împreună cu alte atribute care reies
din contextul problemei modelate. Practic, este un caz particular al legăturii
binare mai mulţi la mai mulţi, fără însă să mai necesite în prealabil
identificarea tipului fiecărei relaţii.
Revenind la exemplul 4.8, vom asocia cele trei relaţii cu scopul de a
putea preciza cu claritate facultatea şi specializarea la care este înmatriculat
fiecare student.
Exemplul 4.15
Student ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina
333 Ionescu Cătălin
Facultate ( facult profil )

Ştiinţe Economice Economic
Drept Administrativ
Specializare ( cod_spec Spec formă_înv

751 FB ZI
752 FB IFR
662 AP IFR
În urma asocierii celor trei relaţii, se va genera o nouă relaţie care se

va identifica prin intermediul atributelor nr_matr, facult şi cod_spec, aşa cum
se observă în exemplul 4.16.
Exemplul 4.16
Studiu ( nr_matr facult cod_spec )
111 Ştiinţe Economice 751
222 Drept 662
333 Ştiinţe Economice 751
Cu ajutorul acestei noi relaţii, putem spune despre Preda Marin că

este student la facultatea de Ştiinţe Economice, la specializarea FB, forma
de învăţământ IFR.
Abia în acest moment putem spune că am argumentat pe deplin
definiţia bazei de date relaţionale: am creat diferite colecţii de date organizate,
după care am stabilit legăturile logice dintre acestea pentru a avea o viziune
completă asupra întregului volum de date care formează respectiva bază de
date. În acest fel, utilizatorul va putea, prin intermediul comenzilor de

interogare specifice SGBD-ului utilizat, să acceseze şi să utilizeze în acelaşi
timp toate datele gestionate în baza de date.
Algebra relaţională – operatorii relaţionali
Algebra relaţională se referă la diferiţi operatori care au ca operanzi

relaţiile, fiind concepută de cercetătorul E.F. Codd. În funcţie de aritatea
operatorului, rezultatul aplicării acestuia la una sau la două relaţii va fi tot o
relaţie. În prezentarea operaţiilor, vom pleca de la presupunerea că fiecare
relaţie are un număr finit de tupluri distincte şi sunt descrise prin intermediul
unei mulţimi finite de atribute [Riccardo, 2001, p.54].
Aceste operaţii specifice algebrei relaţionale sunt folosite pentru
formalizarea limbajului de cereri al sistemului de gestiune al bazelor de date
relaţionale. Ele sunt implementate în funcţiile de manevrare a datelor aferent
sistemului de gestiune şi sunt disponibile utilizatorului cu ajutorul comenzilor
limbajului de manevrare a datelor sau a limbajului de interogare ale
sistemului de gestiune [Georgescu, Georgescu, 2005, p.93].
Cererile specifice algebrei relaţionale se pot exprima prin cinci operaţii
asupra relaţiilor, întâlnite în literatură sub numele de operaţii de bază, şi
anume: reuniunea, diferenţa, produsul cartezian, proiecţia şi selecţia. Dintre
aceste cinci operaţii, primele trei presupun existenţa a două relaţii în timp ce
următoarele se aplică pentru o singură relaţie.
1. Reuniunea. Reuniunea a două relaţii A şi B20, notată A ∪ B , este o relaţie
care va avea schema identică cu a relaţiilor reunite şi care va include ca
tupluri, toate tuplurile celor două relaţii, considerate o singură dată.
Exemplul 4.17
Stud1 ( nr_matr nume pren )
111 Preda Marin
222 Darie Alina

444 Manea Oana
555 Dragomir Alina
Stud1 ∪ Stud2 = ( nr_matr Nume pren )

111 Preda Marin
222 Darie Alina
444 Manea Oana
555 Dragomir Alina
20
Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii.
2. Diferenţa. Diferenţa a două relaţii A şi B21, notată A \ B , este o relaţie care
va avea schema identică cu a relaţiilor iniţiale şi ca realizări toate tuplurile
primei relaţii care nu se regăsesc în cea de-a doua relaţie.
Astfel, dacă realizăm diferenţa relaţiilor Stud1 şi Stud2 din exemplul
4.17, rezultatul este următorul:
Stud1 \ Stud2 = ( nr_matr nume pren )

111 Preda Marin
222 Darie Alina
3. Produsul cartezian. Fie relaţiile A (cu aritatea a) şi B (cu aritatea b)22.

Produsul cartezian al celor două relaţii, notat A × B este o relaţie care are
aritatea a+b şi care va conţine toate tuplurile rezultate prin concatenarea unui
tuplu din A cu fiecare tuplu din B. Trebuie menţionat faptul că atunci când
schemele celor două relaţii includ şi atribute comune, atunci în schema
produsului cartezian, cele două atribute vor apare de două ori, însă cu nume
diferite (o relaţie nu poate avea două atribute cu acelaşi nume).
Exemplul 4.18
111 Preda Marin
222 Darie Alina
Disciplină ( cod_disc denumire tip_disc )

SE1 Baze de date curs
SE2 Baze de date laborator
SE3 Contabilitate Seminar
Aşa cum se observă, aritatea ambelor relaţii este 3, ceea ce înseamnă

că după realizarea produsului cartezian asupra celor două relaţii, aritatea va
fi 6 (relaţia rezultată în urma operaţiei Student × Disciplină va avea şase
atribute), aşa cum se observă mai jos:
Student × Disciplină ( nr_matr nume pren cod_disc denumire tip_disc )

111 Preda Marin SE1 Informatică curs
111 Preda Marin SE2 Informatică laborator
111 Preda Marin SE3 Contabilitate seminar
222 Darie Alina SE1 Informatică curs
222 Darie Alina SE2 Informatică laborator
222 Darie Alina SE3 Contabilitate seminar
333 Ionescu Cătălin SE1 Informatică curs
333 Ionescu Cătălin SE2 Informatică laborator
333 Ionescu Cătălin SE3 Contabilitate seminar
21
22
Schemele relaţiilor A şi B sunt diferite, dar pot exista atribute comune.
4. Proiecţia. Proiecţia se aplică unei singure relaţii A de aritate a, se notează
cu π şi se realizează după un număr de atribute, a1, a2, …, an, care trebuie
să fie incluse în schema relaţiei A. Noua relaţie va avea schema dată de
atributele după care se realizează proiecţia, Totodată, relaţia obţinută după
realizarea proiecţiei va avea acelaşi număr de tupluri ca relaţia iniţială.
Exemplul 4.19 Fie relaţia Student:

Student ( nr_matr cnp nume pren )
1111 1701212120139 Popa Dan
2222 2711010120121 Darie Alina
3333 1721209145123 Preda Marin
Plecând de la această relaţie, dorim să realizăm proiecţia după

atributele nr_matr, nume şi pren. Astfel, vom obţine următoarea relaţie:
π nr_matr, nume, pren (Student) = ( nr_matr nume pren )

1111 Popa Dan
2222 Darie Alina
3333 Preda Marin
5. Selecţia. Selecţia se defineşte pentru o singură relaţie A de aritate a, se

notează cu σ şi se realizează pe baza unei condiţii logice. Noua relaţie va
avea aceeaşi schemă ca relaţia iniţială şi va conţine doar acele tupluri care
respectă condiţia după care se realizează selecţia.
Exemplul 4.20 Fie relaţia Student:

Student ( nr_matr nume pren media )
1111 Popa Dan 7.00
2222 Darie Alina 8.00
3333 Preda Marin 9.00
Plecând de la relaţia de mai sus, dacă dorim să realizăm o selecţie a

studenţilor cu media mai mare sau egală cu opt, vom ajunge la următoare
relaţie:
σ media >=8 ( Student ) = ( nr_matr nume pren media )

2222 Darie Alina 8.00
3333 Preda Marin 9.00
Pe lângă operaţiile amintite anterior, se mai pot utiliza şi alte operaţii,

numite operaţii derivate şi care se bazează pe operaţiile de bază. Utilizarea
în practică a operaţiilor derivate oferă o flexibilitate sporită a cererilor de
interogare a bazei de date şi facilitează, în cele mai multe situaţii, obţinerea
unor răspunsuri mai rapide. Dintre operaţiile derivate utilizate mai frecvent
amintim:
6. Intersecţia. Intersecţia a două relaţii A şi B23, notată A ∩ B , este o relaţie
care va avea schema identică cu a relaţiilor intersectate, iar ca realizări doar
tuplurile comune celor două relaţii.
Exemplul 4.21
111 Preda Marin
222 Darie Alina

444 Manea Oana
555 Dragomir Alina
Stud1 ∩ Stud2 = ( nr_matr nume pren )

7. Uniunea. Uniunea se defineşte pentru două relaţii A şi B (de aritate a,

respectiv b), o condiţie logică între două valori ale unor atribute ce aparţin
celor două relaţii24 şi se notează A | X | B . Rezultatul uniunii va fi o relaţie de
c
aritate a+b, cu schema dată de reuniunea atributelor celor două relaţii şi care
va conţine toate tuplurile aferente produsului cartezian dintre A şi B care
respectă condiţia menţionată. Cu alte cuvinte, uniunea a două relaţii se
realizează în doi paşi:
a. realizarea produsului cartezian dintre relaţii;
b. selecţia tuplurilor conform condiţiei logice.
În cazul în care condiţia c este de egalitate, atunci operaţia se
numeşte echiuniune. În plus, dacă vom realiza o proiecţie după atributele
primei operaţii, operaţia se numeşte semi-uniune-stânga, iar dacă se face
după atributele relaţiei din dreapta (a doua relaţie) se va numi semi-uniune-
dreapta. În continuare vom exemplifica uniunea şi echiuniunea.
23
24
În cazul uniunii, cele două atribute trebuie să fie câte unul din fiecare relaţie.
Exemplul 4.22 Fie următoarele relaţii:
Aprov ( s_fact nr_fact cod_prod cant_a )
DX 1122 P1 20
DX 1122 P2 10
JZ 2233 P3 15
Comandă ( cod_cmd cand_c )

C1 20
C2 12
C3 10
În cadrul relaţiei Aprov se presupune că avem situaţia aprovizionărilor,

în relaţia Comandă avem o evidenţă a produselor comandate, iar semantica
atributelor este următoarea:
• s_fact – reprezintă seria unei facturi;
• nr_fact – reprezintă numărul facturii;
• cod_prod – codul produsului achiziţionat prin intermediul unei facturi;
• cant_a – se referă la cantitatea aferentă unui produs care se găseşte
pe o factură;
• cod_cmd – codul unei comenzi (se presupune că două comenzi
diferite vor avea coduri diferite);
• cant_c – reprezintă cantitatea comandată prin intermediul unei
comenzi.
Pentru a realiza uniunea celor două relaţii, aminteam anterior că
primul pas care trebuie făcut este realizarea produsului cartezian.
Aprov X Comandă= ( s_fact nr_fact cod_prod cant_a cod_cmd cant_c )

DX 1122 P1 20 C1 20
DX 1122 P1 20 C2 12
DX 1122 P1 20 C3 10
DX 1122 P2 10 C1 20
DX 1122 P2 10 C2 12
DX 1122 P2 10 C3 10
JZ 2233 P3 15 C1 20
JZ 2233 P3 15 C2 12
JZ 2233 P3 15 C3 10
După realizarea produsului cartezian, vom face selecţia tuplurilor pe

baza condiţiei cant_a <= cant_c.
Aprov | X | Comandă= ( s_fact nr_fact cod_prod cant_a cod_cmd cant_c )
cant _ a <=
cant _ c
DX 1122 P1 20 C1 20
DX 1122 P2 10 C1 20
DX 1122 P2 10 C2 12
DX 1122 P2 10 C3 10
JZ 2233 P3 15 C1 20

În cazul în care condiţia este cant_a=cant_c, atunci vom avea o
echiuniune a celor două relaţii, aşa cum se observă în exemplul 4.23:
Exemplul 4.23: Echiuniunea relaţiilor Aprov şi Comandă.

Aprov | X | Comandă= ( s_fact nr_fact cod_prod cant_a cod_cmd cant_c )
cant _ a =
cant _ c
DX 1122 P1 20 C1 20
DX 1122 P2 10 C3 10
8. Uniunea naturală. Uniunea naturală a relaţiilor A şi B, notată | A X B | se

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

111 Popa Dan
222 Darie Alin
333 Moga Dana
Disc ( den_disc nr_matr notă )

Finanţe 333 9
Birotică 222 10
Birotică 333 8
a. Se realizează produsul cartezian al celor două relaţii:

Student X Disc = ( s.nr_matr nume pren den_disc d.nr_matr notă )
111 Popa Dan Finanţe 333 9
111 Popa Dan Birotică 222 10
111 Popa Dan Birotică 333 8
222 Darie Alin Finanţe 333 9
222 Darie Alin Birotică 222 10
333 Moga Dana Finanţe 333 9
333 Moga Dana Birotică 222 10
b. La acest pas va trebui să determinăm condiţia după care se va realiza
selecţia. Aşa cum observăm, atributul comun celor două relaţii este nr_matr,
ceea ce înseamnă că uniunea naturală se va face pe baza condiţiei
Student.nr_matr = Disc.nr_matr.
c. După identificarea condiţiei, ea se va aplica asupra produsului cartezian
realizat la punctul a:

σ Student .nr _ matr = Disc.nr _ matr ( Student X Disc) =
( s.nr_matr nume pren den_disc d.nr_matr notă )
333 Moga Dana Finanţe 333 9
d. În final, se realizează o proiecţie asupra relaţiei obţinute la punctul c după

mulţimea atributelor celor două relaţii, considerate o singură dată. După
realizarea proiecţiei, vom obţine:
| Student X Disc |= (nr_matr nume pren den_disc notă )

222 Darie Alin Birotică 10
333 Moga Dana Finanţe 9
333 Moga Dana Birotică 8
9. Uniunea externă. Uniunea externă (outer join) va include toate tuplurile

uniunii naturale, la care se adaugă câte un tuplu pentru acele tupluri dintr-o
relaţie care nu au corespondent în cealaltă relaţie. Tuplurile adăugate au
valoarea NULL pentru toate atributele ce nu apar în relaţia din care provin.
Uniunea externă se notează astfel: A | ⊗ | B, unde A şi B sunt cele două
relaţii.
Plecând de la relaţiile Student şi Disc din exemplul 4.23 şi de la
uniunea naturală Student | X | Disc, vom avea următoarea uniune externă:
Exemplul 4.24
Student | ⊗ | Disc = (nr_matr nume pren den_disc notă )
111 Popa Dan NULL NULL
Aşa cum se observă, în relaţia Student există un singur tuplu care nu

are corespondent în relaţia Disc: în acest caz, tuplul va fi adăugat în relaţia
aferentă uniunii externe, iar valorile aferente atributelor din relaţia Disc pentru
care nu există corespondent vor primi valoarea NULL. În ceea ce priveşte
relaţia Disc, nu există nici un tuplu care să nu aibă corespondent în relaţia
Student (altfel spus, valorile 222 şi 333, ca realizări ale atributului nr_matr în
relaţia Disc, se regăsesc în relaţia Student pe domeniul de valori al atributului
nr_matr).
De asemenea, există două operaţii derivate din uniunea externă şi
anume uniune externă stânga (left outer join) şi uniune externă dreapta (right
outer join). În ceea ce priveşte uniunea externă stânga, relaţia va conţine
toate tuplurile uniunii naturale la care se vor adăuga cele ale primei relaţii
(considerată relaţia din stânga) care nu au corespondent în relaţia din
dreapta. În dreptul acestor valori se va trece valoarea NULL (exemplul 2.25).
În mod similar se realizează uniunea externă stânga, numai că în acest caz

vor fi adăugate uniunii naturale doar tuplurile relaţiei din dreapta (exemplul
2.26).
Exemplul 4.25
Student | ⊗ Disc = (nr_matr nume pren den_disc notă )
111 Popa Dan NULL NULL
Exemplul 4.26
Student ⊗ | Disc = (nr_matr nume pren den_disc notă )
În exemplul 4.26, uniunea externă dreapta este identică cu uniunea

naturală deoarece nu există tupluri în relaţia din dreapta (relaţia Disc în cazul
nostru) care să nu aibă corespondent în cealaltă relaţie.
Probleme rezolvate
1. Mai multe societăţi comercializează pe bază de factură diferite

produse. Folosind abordarea relaţionlă, să se pună în evidenţă
emitentul şi conţinutul fiecărei facturi.
Pentru a soluţiona problema propusă anterior, va trebui să parcurgem

următoarele etape:
a) identificarea atributelor care reies din contextul problemei;
b) definirea relaţiilor pe baza atributelor identificate la punctul a);
c) crearea legăturilor dintre relaţiile identificate la punctul b).
a) Pentru a avea garanţia unei rezolvări corecte a unei probleme, va

trebui ca înainte de a identifica atributele să răspundem la următoarea
întrebare: „Pentru problema dată, avem nevoie de atribute pentru cine, sau
pentru ce?” Astfel, pentru problema noastră, dacă încercăm să răspundem la
această întrebare, vom constata că va trebui să identificăm atribute despre
societăţi, produse şi facturi. Cu alte cuvinte, aceste colecţii pe care le-am
identificat acum vor reprezenta relaţiile pe care le vom defini la punctul b).
După ce am identificat aceste colecţii, va trebui să descriem minim
două atribute care caracterizează fiecare din aceste colecţii de date. Este
important ca atunci când identificăm atributele, să avem în vedere că fiecare
relaţie are în mod obligatoriu o cheie primară, ceea ce înseamnă că va trebui
să ne gândim încă de la acest pas care va fi atributul sau atributele care vor
avea rolul de a identifica în mod unic fiecare tuplu al relaţiilor 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
societăţile descrise) şi denumirea ei. În ceea ce priveşte produsul, dacă ne
gândim 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ă acelaşi cod. De
asemenea, tot referitor la un produs considerăm că ne mai interesează
denumirea acestuia, unitatea de măsură şi eventual cantitatea care există în
stoc la un moment dat.
În ceea ce priveşte factura, ştim cu toţii că aceasta se identifică printr-
o serie şi un număr şi că fiecare factură are o valoare şi o dată a emiterii.
Referitor la seria şi numărul facturii, trebuie să precizăm faptul că, numai
luate împreună, cele două atribute vor putea identifica unic fiecare factură25.
Totodată, dacă analizăm cu atenţie cerinţa problemei, vom constata
că mai avem nevoie de un atribut, astfel încât să putem evidenţia conţinutul
fiecărei facturi. Practic, prin conţinutul fiecărei facturi înţelegem că trebuie să
punem în evidenţă produsele care se găsesc pe fiecare factură primită de
societăţile gestionate şi cantităţile aferente; cu alte cuvinte, atributul de care
vom avea nevoie se va referi la cantitatea aprovizionată dintr-un produs pe o
factură.
Astfel sintetizând cele menţionate anterior, la punctul a) vom avea
următoarele atribute (pentru claritate, în dreptul fiecărui atribut vom menţiona
şi semantica corespunzătoare):
• cui – codul unic de identificare al fiecărei societăţi;
• den_s – denumirea societăţii;
• cod_prod – codul fiecărui produs; se presupune că nu există două
produse gestionate care să aibă acelaşi cod;
• den_prod – denumirea produsului gestionat;
• um – unitatea de măsură specifică fiecărui produs;
• cant – cantitatea (aferentă unui produs) care se găseşte în stoc la un
moment dat;
• serie – seria unei facturi;
• nr – numărul facturii;
• val – valoarea unei facturi;
• data – data emiterii facturii;
• cant_aprov – cantitatea aferentă unui produs aprovizionat prin
intermediul unei facturi. Referitor la acest atribut, menţionăm faptul că vom
avea o realizare a acestuia numai atunci când este emisă o factură pe care
se găseşte un produs gestionat. Altfel spus, ca să dispunem de o realizare a
acestui atribut va trebui să existe atât factura cât şi produsul.
25
Această regulă este întâlnită în literatură sub numele de regula entităţii şi menţionează
faptul că toate atributele care formează cheia primară trebuie să primească valori.
b) După identificarea atributelor, va trebui să definim relaţiile din cadrul
cărora ele vor face parte. Astfel, vom avea următoarele relaţii (pentru fiecare
relaţie, vom descrie şi trei tupluri care să ne ajute la identificarea corectă a
cheilor primare ale relaţiilor):
Societate ( cui den_s )

R111111 Rione SRL
R222222 Selena SRL
R333333 Select SRL
Produs ( cod_prod den_prod um cant )

11 Telefon Nokia B 2
22 Telefon Samsung B 3
33 Laptop Dell B 0
Factură ( serie nr val data )

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ă soluţionăm două cerinţe. Prima se referă la

punerea în evidenţă a emitentului fiecărei facturi. Pentru aceasta, vom asocia
relaţiile Societate şi Factură. Aşa cum am menţionat în subcapitolul în care
am descris legăturile dintre relaţii, pentru a identifica tipul legăturii va trebui
să vedem rolul fiecărei relaţii în cadrul modelului: fiu sau părinte. Analizând
cele două relaţii, observăm că Societate este relaţie părinte deoarece fiecare
societate poate primi una sau mai multe facturi, în timp ce Factură este
relaţie fiu deoarece o factură nu poate fi emisă decât unei singure societăţi
(reamintim că o relaţie este considerată fiu atunci când unui tuplu din acea
relaţie îi va corespunde un singur tuplu în relaţia cu care s-a asociat şi este
părinte atunci când îi vor corespunde mai multe tupluri).
Astfel, legătura este de tipul 1-n (unu la mai mulţi), ceea ce înseamnă
că atributele care formează cheia primară în relaţia părinte vor migra sub
forma cheii străine în relaţia fiu: atributul cui din relaţia Societate va migra
sub forma cheii străine în relaţia Factură.
A doua cerinţă este cea prin care ni se cere să punem în evidenţă
conţinutul fiecărei facturi. În acest caz, vom asocia relaţiile Factură şi Produs.
Aşa cum am procedat anterior, şi în acest caz va trebui să identificăm iniţial
tipul relaţiilor pentru a determina tipul legăturii. Astfel, legătura este de tipul
n-n (mai mulţi la mai mulţi) deoarece ambele relaţii sunt părinte: fiecare
factură poate conţine unul sau mai multe produse, în timp ce un produs
poate fi aprovizionat prin intermediul uneia sau a mai multor facturi. Conform
regulii menţionate, legătura se va realiza prin generarea unei noi relaţii care
va avea cheia primară formată din cheile primare ale celor două relaţii
asociate. De asemenea, această nouă relaţie va include şi atributul
cant_aprov care ne va permite să punem în evidenţă cantitatea aprovizionată
dintr-un produs pe o factură.

După crearea acestor legături, modelul relaţional va arătat astfel:
Societate ( cui den_s )

R111111 Rione SRL
R222222 Selena SRL
R333333 Select SRL
Produs ( cod_prod den_prod um cant )

11 Telefon Nokia B 2
22 Telefon Samsung B 3
33 Laptop Dell B 0
Factură ( serie nr val data cui )

DX 1111 2000 10.11.2008 R222222
DX 2222 8500 10.11.2008 R333333
JW 1111 6500 11.11.2008 R222222
Conţinut_factură ( serie nr cod_prod cant_aprov )

DX 1111 11 10
DX 1111 33 15
JW 1111 11 20
Astfel, prin intermediul atributului cheie străină cui din relaţia Factură
putem să punem în evidenţă care este emitentul fiecărei facturi (ce societate
a emis o factură). Spre exemplu, dacă dorim să aflăm cine a emis factura DX
2222, vom identifica în cadrul relaţiei 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
străine (în cazul nostru, R333333) şi vom căuta această valoare pe domeniul
de valori aferent atributului care este cheie primară în relaţia din care a
migrat. Pentru exemplul nostru, vom merge în relaţia Societate şi pe
domeniul cheii primare vom căuta acel tuplu pentru care valoarea atributului
cui este R333333. În acest fel vom constata că factura DX 2222 este emisă
de Select SRL.
Conţinutul fiecărei facturi este evidenţiat prin intermediul relaţiei
Conţinut_factură. În acest fel constatăm că produsul Telefon Nokia este
achiziţionat prin intermediul a două facturi (DX 1111 şi JW 1111), iar
cantitatea aprovizionată este de 10, respectiv 20 unităţi. Totodată, prin
intermediul acestei noi relaţii am pus în evidenţă faptul că o factură poate
conţine mai multe produse (factura cu seria şi numărul DX 1111 conţine
produsele cu codurile 11 şi 33), dar şi faptul că un produs se poate găsi pe
mai multe facturi (produsul cu codul 11 se găseşte atât pe factura cu seria şi
numărul DX 1111 cât şi pe JW 1111), ceea ce argumentează legătura de
tipul mai mulţi la mai mulţi.
De asemenea, în cadrul relaţiei Factură se argumentează şi regula
entităţii. 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
domeniul de valori respectiv să avem valori duplicate, ceea ce înseamnă că
nu mai poate îndeplini rolul de cheie primară a relaţiei. Spre exemplu, dacă
vom da valori numai atributului serie, atunci vom ajunge în situaţia în care
avem două valori duplicate pe domeniul respectiv de valori, ceea ce nu ar fi
permis. Deci, trebuie să nu omitem să dăm valori tuturor atributelor care
formează cheia primară a unei relaţii.
2. Fie descrierea studenţilor unei facultăţi care studiază diferite

discipline în funcţie de specializarea fiecăruia. Să se pună în evidenţă
specializarea de care aparţine fiecare student, precum şi disciplinele
studiate de aceştia.
a) Pentru problema menţionată anterior, va trebui să identificăm atribute

despre student, specializare şi disciplină. Deşi poate am fi tentaţi să credem
că am avea nevoie şi de atribute despre facultate, nu este aşa, deoarece, în
cazul în care am avea relaţia facultate, aceasta ar avea un singur tuplu şi nu
se justifică generarea unei relaţii care să aibă o singură realizare. Astfel,
pentru problema dată, am putea identifica următoarele atribute:
• nr_matr – numărul matricol al studentului;
• nume – numele studentului;
• pren – prenumele unui student;
• cod_spec – codul unei specializări care aparţine unei facultăţi; vom
presupune că nu există două facultăţi care să aibă acelaşi cod;
• den_spec – denumirea specializării;
• cod_disc – codul disciplinei; ca şi în cazul codului specializării, ş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 funcţie de
specializare, o disciplină poate fi studiată în semestre diferite de studenţii
acesteia.
b) Relaţiile pe care le identificăm sunt următoarele:

111 Popa Alin
222 Marin Daniela
333 Mihnea Ioana
Specializare ( cod_spec den_spec )

76 Contabilitate şi Informatică de Gestiune
75 Finanţe Bănci
70 Informatică Economică
Disciplină ( cod_disc den_disc tip_disc )

D11 Baze de date Curs
D12 Baze de date Laborator
D21 Contabilitate financiară Seminar
c) Pentru a evidenţia specializarea de care aparţine fiecare student,

vom asocia relaţiile Student şi Specializare. Relaţia Student este o relaţie fiu
deoarece un student cu o anumită matricolă nu poate fi înmatriculat la mai
multe specializări, în timp ce relaţia Specializare este una părinte întrucât, în
mod evident, fiecare specializare va avea mai mulţi studenţi. Astfel, legătura
dintre cele două relaţii este de tipul unu-la-mai-mulţi, ceea ce înseamnă că
va migra cheia primară din relaţia Specializare sub forma cheii străine în
relaţia Student. Astfel, prin intermediul atributului cod_spec din relaţia
Student putem să aflăm la ce specializare este înmatriculat fiecare student.
Dacă dorim să determinăm disciplinele studiate de fiecare student,
vom asocia relaţiile Student şi Disciplină. Cele două relaţii sunt părinte
deoarece un student studiază una sau mai multe discipline, iar fiecare
disciplină este studiată de nici un student (pot exista discipline opţionale care
nu se aleg din pachetul de opţionale) sau de mai mulţi studenţi, ceea ce
înseamnă că vom avea o legătură mai-mulţi-la-mai-mulţi. Aşa cum ştim deja,
în această situaţie se va genera o nouă relaţie. Astfel, după crearea
legăturilor, modelul relaţional este următorul:
cheia straina
Student ( nr_matr nume pren cod_spec )

111 Popa Alin 76
222 Marin Daniela 75
333 Mihnea Ioana 76
Specializare ( cod_spec den_spec )

76 Contabilitate şi Informatică de Gestiune
75 Finanţe Bănci
70 Informatică Economică
Disciplină ( cod_disc den_disc tip_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

Astfel, relaţia Studiu este cea care ne permite să identificăm
disciplinele studiate de fiecare student, dar şi perioada în care acestea sunt
parcurse, astfel:
• prin intermediul atributului nr_matr identificăm 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ă.

1. La ce se referă regula reprezentării logice a datelor?

2. Ce reprezintă baza de date relaţională?
3. Ce reprezintă cheia primară?
4. Ce reprezintă cheia străină?
5. Ce este relaţia fiu? Dar cea părinte?
6. Ce reprezintă legătura logică?
7. La ce se referă legătura de tipul unu-la-unu?
8. La ce se referă legătura de tipul unu-la-mai-mulţi?
9. La ce se referă legătura de tipul mai-mulţi-la-mai-mulţi?
10. Cum se realizează legătura dintre trei sau mai multe relaţii?
Teste grilă
1. Câte chei poate avea o relaţie?

a. una primară, una străină si una alternantă;
b. mai multe candidat, una primară şi cel puţin una străină;
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 puţin una străină.
2. O bază de date relaţională se referă la:
a. colecţii organizate de date;
b. colecţii corelate din punct de vedere logic;
c. colecţii organizate şi corelate din punct de vedere logic;
d. colecţii organizate şi corelate fizic pe suportul de stocare.
3. Regula lui Codd specifică reprezentării fizice a datelor se referă la
faptul că:
a. programele de aplicaţie pot fi afectate de modificările realizate
asupra relaţiilor bazei de date;
b. programele de aplicaţie nu pot fi afectate de modificările
realizate asupra relaţiilor bazei de date;
c. programele de aplicaţie pot fi afectate de modificările realizate
în modul de reprezentare a datelor sau în metodele de acces;
d. programele de aplicaţie nu pot fi afectate de modificările
realizate în modul de reprezentare a datelor sau în metodele de
acces.

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 străină;
d. un atribut (grup de atribute) care poate deveni fie cheie
alternantă, fie cheie străină;
5. Cheia primară reprezintă un atribut sau un grup de atribute care:
a. identifică unic fiecare tuplu al unei relaţii;
b. identifică unic fiecare tuplu, în funcţie de relaţia în care
migrează;
c. identifică în mod unic toate celelalte atribute ale relaţiei din care
face parte;
d. nu poate migra niciodată din relaţia din care face parte.
6. Un tuplu se obţine prin atribuirea de valori:
a. atributelor cheie;
b. atributelor unei relaţii;
c. cheii străine;
d. pentru acele atributute care au valoarea NULL.
7. O relaţie este părinte dacă:
a. unui tuplu din acea relaţie nu-i corespunde nici un tuplu în
relaţia cu care s-a asociat;
b. unui tuplu din relaţia respectivă îi corespunde un singur tuplu în
c. unui tuplu din relaţia respectivă îi corespund mai multe tupluri în
d. se asociază cu încă două relaţii.
8. Fiecare relaţie:
a. are o singură cheie primară;
b. are mai multe chei primare;
c. are o singură cheie primară, însă atunci când este nevoie, se
poate identifica cel mult încă una;
d. nu contează câte chei primare are o relaţie.

9. Legătura de tipul unu-la-mai-mulţi se realizează atunci când:
a. unui tuplu din fiecare relaţie îi corespunde cel mult un tuplu din
cealaltă relaţie;
b. unui tuplu din prima relaţie îi corespund mai multe tupluri în cea
de-a doua relaţie, în timp ce unui tuplu din a doua relaţie îi
corespunde un singur tuplu din prima;
c. unui tuplu din fiecare relaţie îi corespund mai multe tupluri din
cealaltă relaţie;
d. se asociază cel puţin trei relaţii.
10. Operaţia proiecţie din algebra relaţională:
a. se aplică unei singure relaţii şi se realizează după diferite
atribute ale relaţiei;
b. se aplică unei singure relaţii şi se realizează după diferite
tupluri ale relaţiei;
c. presupune existenţa a două relaţii cu aritate diferită şi pe baza
unei condiţii logice;
d. presupune existenţa a două relaţii cu scheme diferite, dar care
pot avea şi atribute comune.

Bibliografie
Bibliografie
1. [Bâscă, 1997] Bâscă, O., Baze de date, Editura All, Bucureşti, 1997.
2. [Connoly et al., 2002] Connoly, T., Begg, C., Strachan, A., Database
Systems – A practical Approach to Design, Implementation and
Management, Second Edition, Addison Wesley Limited, 2002.
3. [Date, 1994] Date, J., An introduction to Database Systems, ed. Addison
Wesley, 1994.
4. [Date, 2004] Date, J., An introduction to database systems, ediţia a VIII-a,
Pearson Addison Wesley, 2004.
5. [Diaz, 2000] Diaz, O., Advanced database technology and design, ed.
Piattini, 2000.
6. [Fotache, 2005] Fotache, M., Proiectarea bazelor de date. Normalizare şi
postnormalizare. Implementări SQL şi Oracle, Editura Polirom, Iaşi, 2005.
7. [Garsia-Molina et al., 2002] Garcia-Molina, H., Ullman, H., Widom, J.,
Database Systems. The complete Book, Prentice Hall, Upper Saddle
Riner, 2002.
8. [Georgescu, Georgescu, 2005] Georgescu, C., Georgescu, M., Baze de
date relaţionale şi multidimensionale, Editura Didactică şi Pedagogică
R.A., Bucureşti, 2005.
9. [Gerald, 1999] Gerald, P., Database Management Systems, ed. Mc Graw
Hill, 1999.
10. [Harrington, 2002] Harrington, J.L., Relational Database Design Clearly
Explained, ediţia 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, Bucureşti, 1995.
13. [Popa et al., 1994] Popa, Ghe., Stanciu, A., Ivancenco, V., Mareş, V.,
SGBD, Editura All, Bucureşti, 1994.
14. [Popescu, 2001] Popescu, I., Modelarea bazelor de date, Editura Tehnică,
Bucureşti, 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, ediţia a II-a, Addison Wesley, 2001.

Bibliografie
20. [Trandafir et al., 2007] Trandafir, R., Nistorescu, M., Mierluş-Mazilu, I.,
Baze de date relaţionale, Bucureşti, 2007.
21. [Velicanu et al., 2000] Velicanu, M., Bodea, C., Lungu, I., Ioniţă, I.,
Bădescu, G., Sisteme de gestiune a bazelor de date, Editura Petrion,
Bucureşti, 2000.
22. [Velicanu et al., 2003] Velicanu, M., Lungu, I., Muntean, M., Ionescu, S.,
Sisteme de baze de date – teorie şi practică, Editura Petrion, Bucureşti,
2003.
23. http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_2.pdf.

Baze Date

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Baze Date

Uploaded by

Copyright:

Available Formats

Universitatea “Dunărea de Jos” Galaţi

Baze de date aplicate în economie

Lect. dr. Lupaşc Adrian

Departamentul pentru Învăţământ la Distanţă şi cu Frecvenţă Redusă

Capitolul I – Fundamente ale bazelor de date............................................................3

Capitolul I – Fundamente ale bazelor de date

Capitolul I – Fundamente ale bazelor de date – prezintă evoluţia şi

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

Ce este baza de date?

4 Baze de date aplicate în economie

Arhitecturi ale sistemelor de baze de date

6 Baze de date aplicate în economie

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

Aşa cum se observă, componentele specifice arhitecturii din figura 1.1

2. Arhitectura pe niveluri structurează un sistem de baze de date pe trei

Baze de date aplicate în economie 7

Program Structura externa

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

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

Perspective asupra unei baze de date

1. Ce reprezintă o bază de date?

1. Printre factorii care au contribuit la adoptarea în masă a sistemelor de

10 Baze de date aplicate în economie

Baze de date aplicate în economie 11

12 Baze de date aplicate în economie

Capitolul II – Proiectarea şi administrarea unei baze de date

Proiectarea şi administrarea sistemelor de baze de date reprezintă o sarcină

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

Baze de date aplicate în economie 13

Ciclul de viaţă al sistemelor informaţionale

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

14 Baze de date aplicate în economie

Proiectarea logica Proiectarea aplicatiei

Figura 2.1. Ciclul de viaţă al unei aplicaţii de tip bază de date

Principalele activităţi asociate fiecărei etape din ciclul de viaţă al

16 Baze de date aplicate în economie

20 Baze de date aplicate în economie

1. Ce reprezintă sistemul informaţional?

1. Rolul sistemului informaţional este de a asigura legătura dintre:

Baze de date aplicate în economie 21

22 Baze de date aplicate în economie

Baze de date aplicate în economie 23

Capitolul III – Sisteme de gestiune a bazelor de date

Sistemul de gestiune a bazelor de date constituie în prezent un cadru de

În sens larg putem defini sistemul de gestiune a bazelor de date

Evoluţia sistemelor de gestiune a bazelor de date

24 Baze de date aplicate în economie

Facilităţi oferite de un SGBD

Avantajele şi dezavantajele SGBD-urilor

1.Controlul redundanţei datelor

3.Mai multe informaţii de la aceeaşi cantitate de date

5.Integritatea crescută a datelor

30 Baze de date aplicate în economie

9.Echilibrul între cerinţele aflate în conflict

10.Îmbunătăţirea accesibilităţii datelor şi capacităţii de răspuns

Baze de date aplicate în economie 31

12.Întreţinere îmbunătăţită datorită independenţei datelor

14.Îmbunătăţirea serviciilor de salvare de siguranţă şi refacere

3.Costurile adiţionale specifice componentelor hardware

7.Impactul crescut al unei defecţiuni

Baze de date aplicate în economie 37

Administrarea bazei de date

38 Baze de date aplicate în economie

Baze de date aplicate în economie 39