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

Baze de date aplicate în economie 3

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.



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.



Î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.



DateSoftware

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



Manipulare dateVederi alebazei de date Descriere date

Niveluri deorganizare

date

Programatorde aplicatie

Administratorbaza de date

Inginer(analist) de

sistem

Logic

Conceptual

Fizic

Programaplicatie 1

Structura externa(logica)

SGBD

S.O.

Structuraconceptuala

Structura interna(fizica)Bază de date

... ...

...

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

În arhitectura prezentată în figura 1.2 sunt redate nivelurile de 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ă

de aplicaţiile care vor fi dezvoltate; b. viziunea administratorului asupra bazei de date este independentă

de aplicaţiile care vor fi dezvoltate; c. viziunea utilizatorului final asupra bazei de date este independentă

de aplicaţiile care vor fi dezvoltate; 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 ****************************************************************************************

Obiectivele capitolului 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.



Proiectareabazei de date

Planificareabazei de date

Delimitarea granitelorsistemului

Colectarea sianaliza cerintelor

Proiectarea conceptuala

Proiectarea logica

Proiectarea fizica

Prototipizarea Implementarea

Testarea

Întretinere operationala

Alegerea SGBD-ului

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

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



Întrebări recapitulative

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 ****************************************************************************************

Obiectivele capitolului 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.



Întrebări recapitulative 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 manipulare a datelor;

d. limbajele procedurale se bazează pe limbajele de descriere a datelor, în timp ce cele neprocedurale lucrează cu limbajele de manipulare a datelor;

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 ****************************************************************************************

Obiectivele capitolului 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

Student ( cnp nr_matr nume pren facult spec ) 1701212120139 1234 Popa Dan FSE IE 2731210176143 1987 Darie Dan FD AP 1801009129145 4432 Popa Ion FSE IE

În continuare ne vom opri asupra celor două atribute rămase, şi anume cnp şi nr_matr. Cu siguranţă, că la întrebarea „Sunt atributele cnp şi



nr_matr chei candidat?” am primi un singur răspuns: „DA”. Aşa să fie oare? Nu este aşa. Iar argumentul este dat de exemplul 4.4. Exemplul 4.4

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

Aşa cum observăm, pe domeniul aferent atributului cnp, avem două

valori identice: este situaţia în care o persoană este studentă la două facultăţi diferite (şi nu este singura situaţie posibilă). Deci, nici atributul cnp nu poate fi cheie candidat. De ce am ajuns să facem o astfel de greşeală şi să considerăm că cnp poate fi cheie? Probabil că ne-am gândit la faptul că nu pot existat două persoane cu acelaşi CNP. Este adevărat: nu există două persoane cu acelaşi CNP, însă schema relaţiei Student nu conţine doar atribute despre o persoană, ceea ce înseamnă că trebuia să ne gândim dacă pentru un anume CNP putem identifica cel puţin o valoare a unui alt atribut care să se modifice faţă de tuplul de la care am plecat.

În ceea ce priveşte atributul nr_matr, putem spune că el este cheie candidat. Cum arătăm asta? Să plecăm de la situaţie din exemplul 4.5. Exemplul 4.5

Student ( Cnp nr_matr nume pren facult spec ) 1701212120139 1234 Popa Dan FSE IE ? 1234 ? ? ? ?

Astfel, considerăm că avem un tuplu care reprezintă un student cu

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

Student ( cnp nr_matr nume pren facult spec ) 1701212120139 1234 Popa Dan FSE IE 1701212120139 1234 Popa Dan FSE IE



Odată identificată o cheie candidat, procesul nu este finalizat. În continuare va trebui să căutăm şi diferite combinaţii de atribute care ar putea fi cheie. Singurul lucru clar este 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ă BA∪ , este o relaţie care va avea schema identică cu a relaţiilor reunite şi care va include ca tupluri, toate tuplurile celor două relaţii, considerate o singură dată. Exemplul 4.17

Stud1 ( nr_matr nume pren ) 111 Preda Marin 222 Darie Alina 333 Ionescu Cătălin

Stud2 ( nr_matr nume pren ) 444 Manea Oana 333 Ionescu Cătălin 555 Dragomir Alina

=∪ Stud2Stud1 ( nr_matr Nume pren ) 111 Preda Marin 222 Darie Alina 333 Ionescu Cătălin 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ă B\A , 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:

= Stud2\Stud1 ( 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 BA × este o relaţie care are aritatea a+b şi care va conţine toate tuplurile rezultate prin concatenarea unui tuplu din A cu fiecare tuplu din B. Trebuie menţionat faptul că atunci când schemele celor două relaţii includ şi atribute comune, atunci în schema produsului cartezian, cele două atribute vor apare de două ori, însă cu nume diferite (o relaţie nu poate avea două atribute cu acelaşi nume). Exemplul 4.18

Student ( nr_matr nume pren ) 111 Preda Marin 222 Darie Alina 333 Ionescu Cătălin

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 DisciplinăStudent × va avea şase atribute), aşa cum se observă mai jos:

DisciplinăStudent × ( 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 Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii. 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:

=(Student) pren nume, nr_matr,π ( 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:

=>= )(8 Studentmediaσ ( 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ă BA∩ , este o relaţie care va avea schema identică cu a relaţiilor intersectate, iar ca realizări doar tuplurile comune celor două relaţii. Exemplul 4.21

Stud1 ( nr_matr nume pren ) 111 Preda Marin 222 Darie Alina 333 Ionescu Cătălin

Stud2 ( nr_matr nume pren ) 444 Manea Oana 333 Ionescu Cătălin 555 Dragomir Alina

=∩Stud2 Stud1 ( nr_matr nume pren ) 333 Ionescu Cătălin

7. Uniunea. Uniunea se defineşte pentru două relaţii A şi B (de aritate a, respectiv b), o condiţie logică între două valori ale unor atribute ce aparţin celor două relaţii24 şi se notează B |X | A

c. Rezultatul uniunii va fi o relaţie de

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 Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii. 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 ccantacant

X__

||<=

Comandă= ( s_fact nr_fact cod_prod cant_a cod_cmd 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 ccantacant

X__

||=

Comandă= ( s_fact nr_fact cod_prod cant_a cod_cmd cant_c )

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

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

Student ( nr_matr nume pren ) 111 Popa Dan 222 Darie Alin 333 Moga Dana

Disc ( den_disc nr_matr notă ) Finanţe 333 9 Birotică 222 10 Birotică 333 8

a. Se realizează produsul cartezian al celor două relaţii:

Student X Disc = ( s.nr_matr nume pren den_disc d.nr_matr notă ) 111 Popa Dan Finanţe 333 9 111 Popa Dan Birotică 222 10 111 Popa Dan Birotică 333 8 222 Darie Alin Finanţe 333 9 222 Darie Alin Birotică 222 10 222 Darie Alin Birotică 333 8 333 Moga Dana Finanţe 333 9 333 Moga Dana Birotică 222 10 333 Moga Dana Birotică 333 8

b. La acest pas va trebui să determinăm condiţia după care se va realiza selecţia. Aşa cum observăm, atributul comun celor două relaţii este nr_matr, ceea ce înseamnă că uniunea naturală se va face pe baza condiţiei Student.nr_matr = Disc.nr_matr. c. După identificarea condiţiei, ea se va aplica asupra produsului cartezian realizat la punctul a:



== Disc) X StudentmatrnrDiscmatrnrStudent (_._.σ

( s.nr_matr nume pren den_disc d.nr_matr notă ) 222 Darie Alin Birotică 222 10 333 Moga Dana Finanţe 333 9 333 Moga Dana Birotică 333 8

d. În final, se realizează o proiecţie asupra relaţiei obţinute la punctul c după mulţimea atributelor celor două relaţii, considerate o singură dată. După realizarea proiecţiei, vom obţine:

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

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

Student |⊗ | Disc = (nr_matr nume pren den_disc notă ) 111 Popa Dan NULL NULL 222 Darie Alin Birotică 10 333 Moga Dana Finanţe 9 333 Moga Dana Birotică 8

Aşa cum se observă, în relaţia Student există un singur tuplu care nu

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



vor fi adăugate uniunii naturale doar tuplurile relaţiei din dreapta (exemplul 2.26). Exemplul 4.25

Student |⊗ Disc = (nr_matr nume pren den_disc notă ) 111 Popa Dan NULL NULL 222 Darie Alin Birotică 10 333 Moga Dana Finanţe 9 333 Moga Dana Birotică 8

Exemplul 4.26

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

Î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:

Student ( nr_matr nume pren ) 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:

Student ( nr_matr nume pren cod_spec ) 111 Popa Alin 76 222 Marin Daniela 75 333 Mihnea Ioana 76

cheia straina

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ă.



Întrebări recapitulative 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

relaţia cu care s-a asociat; c. unui tuplu din relaţia respectivă îi corespund mai multe tupluri în

relaţia cu care s-a asociat; 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

Documents

Transcript of Baze Date