BAZE DE DATE

Fundamente ale bazelor 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. Î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.

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.

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,

3

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.

4

Profesorul M. Fotache prezintă şi analizează o definiţie academică a bazei de date. Astfel, în opinia acestuia, baza de date reprezintă un ansamblu structurat de 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. Componentele specifice arhitecturii pe componente sunt:

a. datele – sunt organizate într-o bază de date care conţine:

• colecţii de date propriu-zise;

• dicţionarul de date (structura de date, restricţiile de integritate, vederile, etc.);

• fişierele anexe, aşa cum sunt cele de index.

5

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.

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 SGBD;

• 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ă);

6

• rezultatul nivelului conceptual este schema conceptuală;

• realizarea schemei corespunde unei activităţi de modelare pentru că este vorba despre o transpunere în termeni abstracţi a entităţilor lumii reale;

• odată definită, schema conceptuală trebuie confruntată cu lumea reală pentru identificarea şi soluţionarea neconcordanţelor sau a omisiunilor; datorită caracterului său global şi unitar, se recomandă ca schema conceptuală să fie gestionată de o singură persoană [Georgescu, Georgescu, 2005, p.67].

b. nivelul logic – este dat de viziunea programatorului asupra datelor. Legat de acest nivel se pot prezenta 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.

7

Proiectarea şi administrarea unei baze de date

Î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

8

cerinţelor mai largi ale organizaţiei. În acest context, ciclul de viaţă al sistemului informaţional dintr-o organizaţie este puternic legat de ciclul de viaţă al sistemului de baze de date care îl susţine. De obicei, etapele aferente ciclului de viaţă al unui sistem informaţional includ: planificarea, analiza cerinţelor, proiectarea (inclusiv a bazei de date), prototipizarea, implementarea şi întreţinerea.

Ciclul de viaţă al unui sistem de baze de date Etapele specifice ciclului de viaţă al unei aplicaţii de tip bază de date nu sunt strict

secvenţiale, ci pot presupune revenirea la o etapă anterioară şi repetarea lor. Spre exemplu, dacă apar anumite probleme în timpul proiectării bazei de date, se poate reveni la etapa anterioară care are drept obiectiv colectarea şi analiza cerinţelor.

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

9

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-R1, relaţional, OO2, OR3), dar independent de tipul SGBD-ului ales şi de alte aspecte fizice ale modelului;

• fizică – urmăreşte implementarea efectivă a bazei de date pe suportul de stocare, inclusiv acele aspecte care ţin de asigurarea şi garantarea securităţii datelor.

Proiectarea corespunzătoare bazei de date este o etapă foarte importantă, mai ales că trebuie să fie capabilă să garanteze buna funcţionare a acesteia şi a oricărei aplicaţii care o utilizează. În lipsa unei proiectări adecvate a bazei de date, aceasta poate prezenta mai multe deficienţe, cum ar fi:

• compromiterea integrităţii datelor deoarece restricţiile de integritate nu pot fi proiectate sau implementate corect;

• datele sunt redundante, iar aplicaţiile individuale se „aglomerează” în încercarea de a se asigura sincronizarea datelor;

• performanţele sunt afectate deoarece este posibil ca pentru finalizarea unei instrucţiuni (spre exemplu, instrucţiunea Select) să fie necesare interogări suplimentare.

1 E-R – Entitate – Relaţie 2 OO – Orientat Obiect 3 OR – Obiectual – Relaţional

10

Sisteme de gestiune a bazelor de date

În sens larg putem defini sistemul de gestiune a bazelor de date (SGBD) ca un sistem de programe care permite utilizatorilor definirea, generarea şi întreţinerea unei baze de date, precum şi accesul controlat la aceasta. În [Velicanu et al., 2003, p.94] SGBD-ul este definit ca un ansamblu complex de programe care asigură interfaţa între o bază de date şi utilizatorii acesteia. Totodată, autorii consideră SGBD-ul o componentă software a unui sistem de baze de date care este capabil să interacţioneze cu toate celelalte componente ale acestuia, 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.

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.

Există două tipuri de limbaje de manipulare a datelor:

• procedurale

• neprocedurale care se pot deosebi în funcţie de operaţiile de extragere. Principala diferenţă între ele constă în faptul că, de obicei, limbajele procedurale tratează bazele de date înregistrare cu înregistrare, în timp ce limbajele neprocedurale operează asupra unor seturi de

11

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

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;

12

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)4; limbaje de manevrare a datelor; limbaje de interogare a datelor din baza de date; editoare de cod; generatoare de cod care să permită definirea interfeţei cu utilizatorul, a rapoartelor,

meniurilor, etc.; un sistem de asistenţă on-line pentru autodocumentarea utilizatorului.

• subsistemul de 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 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. 4 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.

13

Descrierea datelor Prin intermediul funcţiei de descriere a datelor, fiecare SGBD permite definirea unei

structuri a bazei de date cu ajutorul limbajului de definire a datelor (LDD). Definirea datelor poate fi realizată la nivel conceptual, logic şi fizic. Se descriu atributele din cadrul structurii bazei de date, 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 datelor5. 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

5 În literatură întâlnim frecvent şi Limbaj de Manevrare a Datelor

14

diferite forme (punctuale, liste, rapoarte, grafice, imagini, sunet, video, etc) şi se pot obţine după cele mai diferite criterii de 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.

Administrarea bazei de date Funcţia de administrare este una destul de complexă şi din acest motiv se consideră

că este doar de competenţa administratorului bazei de date. Administratorul, care are o bogată experienţă de analiză, proiectare şi programare,

organizează şi administrează baza de date în toate etapele de realizare a acesteia. Astfel, el organizează baza de date conform unei anumite metodologii, realizează schema conceptuală a acesteia şi coordonează proiectarea ei. Pentru toate aceste aspecte, SGBD-ul oferă o serie de instrumente CASE, precum şi o serie de utilitare specializate.

În etapa de exploatare a bazei de date, administratorul î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.).

Pentru fiecare din activităţile menţionate mai sus, SGBD-ul oferă instrumente şi tehnici de lucru.

15

Abordarea relaţională a bazelor de date Î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 )

16

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 )

17

1701212120139 1234 Popa Dan FSE IE 2731210176143 1987 Darie Dan FD AP 1801009129145 4432 Popa Ion FSE IE

În continuare ne vom opri asupra celor două atribute 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

18

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

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

19

Astfel, prin descompunerea relaţiei iniţiale în cele trei relaţii din exemplul 4.8 am argumentat prima parte a definiţiei bazei de date relaţionale. 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

20

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

21

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:

22

Exemplul 4.13:

Factură ( serie_fact nr_fact val_fact data_fact ) DX 1111 100 10.10.2008 VR 2222 200 10.10.2008 DF 3333 300 12.10.2008

Produs ( cod_produs den_prod um stoc ) 11 Telefon Nokia Buc 0 22 TV Samsung Buc 2 33 Laptop Asus Buc 2

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.

23

Revenind la exemplul 4.8, vom asocia cele trei relaţii cu scopul de a putea preciza cu claritate facultatea şi specializarea la care este înmatriculat fiecare student. Exemplul 4.15

Student ( nr_matr nume pren ) 111 Preda Marin 222 Darie Alina 333 Ionescu 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. 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,

24

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 B7, notată , 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ă.

BA ∪

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

2. Diferenţa. Diferenţa a două relaţii A şi B8, notată , 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.

B\A

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

7 Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii. 8 Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii. 9 Schemele relaţiilor A şi B sunt diferite, dar pot exista atribute comune.

25

Disciplină ( cod_disc denumire tip_disc ) SE1 Baze de date curs SE2 Baze de date laborator SE3 Contabilitate Seminar

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

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

26

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 B10, 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ţii11 şi se notează

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

B |X | Ac

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.

10 Relaţiile A şi B trebuie să aibă aceeaşi schemă definită pe aceleaşi domenii. 11 În cazul uniunii, cele două atribute trebuie să fie câte unul din fiecare relaţie.

27

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 Comandă= ccantacant

X__

||<=

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

28

Exemplul 4.23: Echiuniunea relaţiilor Aprov şi Comandă.

Aprov Comandă= ccantacant

X__

||=

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

29

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

9. Uniunea externă. Uniunea externă (outer join) va include toate tuplurile uniunii naturale, la care se adaugă 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

30

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. [Lungu, Bodea, 1995] Lungu, I., Bodea, C., Baze de date – organizare, proiectare şi

implementare, Editura All, Bucureşti, 1995. 10. [Popa et al., 1994] Popa, Ghe., Stanciu, A., Ivancenco, V., Mareş, V., SGBD, Editura All,

Bucureşti, 1994. 11. [Popescu, 2001] Popescu, I., Modelarea bazelor de date, Editura Tehnică, Bucureşti,

2001. 12. [Trandafir et al., 2007] Trandafir, R., Nistorescu, M., Mierluş-Mazilu, I., Baze de date

relaţionale, Bucureşti, 2007. 13. [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. 14. [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. 15. http://vega.unitbv.ro/~cataron/Courses/BD/BD_Cap_2.pdf.

31