Fundamente ale bazelor de date

Transcript

1 BAZE DE DATE

2 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 clientserver, 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

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

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

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. Vederi ale bazei de date Manipulare date Descriere date Niveluri de organizare date Programator de aplicatie Program aplicatie 1 Structura externa... (logica)... Logic Administrator baza de date SGBD S.O. Structura conceptuala... Conceptual Inginer (analist) de sistem Bază de date Structura interna (fizica) Fizic Figura 1.2. Arhitectura pe niveluri a unui sistem de baze de date În arhitectura prezentată în figura 1.2 sunt redate nivelurile de organizare (reprezentare) a datelor în baza de date şi 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: 6 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

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

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

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 ] 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-R 1, relaţional, OO 2, OR 3 ), 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

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

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: 12 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 ] 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

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 întrun 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 datelor 5. Manipularea datelor este cea mai folosită funcţie în bazele de date, fiind cea mai bine suportată de sistemul de gestiune a bazelor de date faţă de oricare alt sistem de gestionare a datelor din memoria externă. Practic, un SGBD manipulează datele într-o manieră eficientă, folosind în acest scop diferite tehnici şi metode de optimizare a accesului şi a 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

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

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 Student ( cnp nr_matr nume pren facult spec )

16 Popa Dan FSE IE Darie Alina FD AP 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

17 Popa Dan FSE IE Darie Dan FD AP 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 ) Popa Dan FSE IE Darie Dan FD AP 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 ) 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 ) Popa Dan FSE IE 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

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