1. CONCEPTE FUNDAMENTALE

1.1. Utilitatea i avantajele bazelor de date

Caracteristica principal a aplicaiilor de baze de date const n faptul c accentul este pus pe operaiile de memorare i regsire, efectuate asupra unor volume mari de date, i mai puin asupra operaiilor de prelucrare a acestora aa cum este cazul n alte domenii de aplicare a informaticii (calcule tehnico-tiinifice, proiectare, comand-control .a.m.d.). Principala operaie care apare n orice aplicaie de baze de date este cea de regsire a datelor, n scopul obinerii de informaii din baza de date. Aceasta este finalitatea i sensul existenei oricrei baze de date. O baz de date este creat pentru a putea fi interogat! Alturi de operaiile de regsire apar mai mult sau mai puin frecvent operaii de memorare, pentru introducerea de noi date n baz, operaii de tergere pentru datele devenite inutile, ct i operaii de actualizare a unor date existente deja n baz.

Organizarea datelor n baze de date constituie o form de centralizare a acestora, fiind un echivalent informatic al bibliotecilor tradiionale. Aceasta implic existena unui "bibliotecar" care n cazul bazelor de date poart numele de administrator al bazei de date (ABD) - este vorba de o persoan sau un grup de persoane, avnd atribuii bine definite n organizarea i ntreinerea bazei de date.

Centralizarea datelor prezint o serie de avantaje cum ar fi: l. Reducerea redondanei datelor memorate n situaia n care fiecare aplicaie lucreaz cu fiierele sale

proprii este posibil ca aceleai date s apar de mai multe ori n fiiere diferite aparinnd unor aplicaii diferite. Aceasta nseamn o mare risip a spaiului de memorare. n cazul centralizrii datelor ABD poate sesiza eventualele suprapuneri ntre diverse aplicaii i poate interveni n organizarea datelor n aa fel nct, aplicaii diferite avnd aceleai date, s utilizeze, n comun, un singur fiier pentru memorarea acestora.

2. Evitarea inconsistenei datelor memorate Este o consecin a celor artate mai sus, ca urmare a faptului

c o dat anume este memorat doar ntr-un singur loc. Atunci cnd exist mai multe copii ale aceleai date este

posibil, prin actualizarea doar a unora dintre ele, s avem valori diferite pentru una i aceeai dat, ceea ce atrage dup sine inconsistena bazei de date.

3. Posibilitatea partajrii datelor Legat de punctele 1) i 2), se refer nu numai la posibilitatea

utilizrii n comun a datelor de ctre mai multe aplicaii, ci i Ia posibilitatea de a dezvolta aplicaii noi folosind datele deja existente n baz.

4. ncurajarea introducerii standardelor ABD, prin atribuiile sale, poate impune alinierea la anumite

standarde, ceea ce are un rol important n transferul datelor de la o baz de date la alta.

5. Posibilitatea aplicrii restriciilor de securitate Avnd controlul centralizat al datelor, ABD poate introduce

verificri de autorizare a accesului la date. Se pot impune restricii diferite pentru fiecare tip de acces la date (regsire, actualizare, tergere, etc), pentru fiecare dat i la nivelul fiecrui utilizator.

6. Meninerea integritii datelor Integritatea datelor reflect cerina ca baza de date s conin

date corecte. Aceasta presupune att consistena datelor, ct i plauzibilitatea lor prin introducerea unor proceduri de validare corespunztoare.

1.2. Independena datelor Independena datelor este o problem a crui rezolvare

constituie un scop n sine n concepia i organizarea oricrei baze de date. Independena datelor nseamn c exist o delimitare net ntre reprezentarea fizic a datelor i imaginea pe care o are utilizatorul asupra acestor date. Aceasta nseamn c modul concret n care este realizat memorarea i organizarea datelor este transparent pentru utilizator. Acesta trebuie s fie preocupat doar de problema concret pe care o are de rezolvat i pe care o modeleaz ntr-un anumit fel; utilizatorul lucreaz la nivelul bazei de date cu acest model propriu, detaliile de implementare, care de fapt nu sunt nici eseniale, nici specifice problemei de rezolvat, rmn n sarcina sistemului.

De remarcat faptul c problema independeei datelor aa cum a fost formulat mai sus este un ideal aflat, ntr-o msur mai mic sau mai mare, n stadiul de deziderat n cazul celor mai multe baze de date. Realizarea unei

independene totale ridic probleme deosebite de implementare care la ora actual sunt doar parial rezolvate.

Problema independenei datelor prezint dou aspecte: independena fizic a datelor, independena logic a datelor. Independena fizic a datelor Este o msur a imunitii aplicaiilor fa de modificrile n

structura fizic de memorare a datelor. O modificare a acestei structuri nu va afecta aplicaia i reciproc modificri ale aplicaiei vor lsa structura fizic de date nealterat. Structura fizic a datelor este determinant pentru strategiile de acces care pot fi folosite pentru regsirea datelor. O aplicaie care este independent fa de structura fizic de date nu conine nici o referire la tipul fiierelor folosite pentru memorarea datelor (fiiere secveniale, fiiere indexate sau n acces direct prin tabele de dispersie), Ia tipul dispozitivului de memorare folosit (band magnetic, disc magnetic .a.) sau la strategia de acces la date; din punctul de vedere al aplicaiei datele sunt entiti cu nume, iar orice referire la date n cadrul aplicaiei se face prin aceste nume. Rmne n sarcina sistemului i a ABD de a alege modul de organizare optim al datelor, ct i strategia de acces cea mai potrivit pentru aceast organizare. Aceste detalii nu trebuie s fie cunoscute de utilizator, iar ABD poate lua, de exemplu, decizia modificrii strategiei de acces la date fr ca utilizatorul s tie acest lucru.

Independena logic a datelor Se refer la imunitatea modelului propriu al fiecrui utilizator

fa de modificri n structura logic global a bazei de date. Independena logic este legat n primul rnd de problema adugrii de noi uniti logice (cmpuri, nregistrri) la structura bazei de date i/sau de modificarea relaiilor existente ntre ele. Astfel este posibil dezvoltarea bazei de date (prin definirea de noi cmpuri sau nregistrri i adugarea de date) fr a afecta utilizatorii care nu au nevoie de aceste date. De asemenea independena logic permite reorganizarea bazei de date (regruparea cmpurilor n nregistrri, definirea de noi nregistrri pe baza cmpurilor din nregistrrile existente) pentru a face fa cerinelor unor utilizatori noi fr a afecta utilizatorii deja existeni. Este nerezolvabil problema eliminrilor de entiti logice din baza de date ntruct orice operaie de acest gen se repercuteaz n mod inerent asupra utilizatorilor care fac referire la entitatea eliminat.

Din punctul de vedere al utilizatorului problema independenei logice intervine prin operaiile pe care sistemul i permite s le efectueze asupra datelor din modelul propriu, n aa fel nct aceste operaii s nu afecteze modelul altor utilizatori care folosesc, parial sau total aceleai date. Mai precis este vorba

de restriciile introduse de sistem pentru a asigura protecia reciproc a datelor partajate. Prin independena logic a datelor se urmrete a se crea iluzia fiecrui utilizator c este singurul beneficiar al unor date pe care n realitate le folosete n comun cu ali utilizatori.

Independena logic a datelor este mult mai greu de realizat dect cea fizic, iar modul de realizare al ei este n mare msur depedent de modelul de date folosit (ierarhic, reea sau relaional).

1.3. Arhitectura unei baze de date

ntre calculatorul care opereaz asupra datelor care se prezint sub form de bii i utilizatorul unei baze de date care manipuleaz concepte, mai mult sau mai puin abstracte, de genul intreprindere, furnizori, angajai, conturi, etc. se inteipun mai multe nivele de abstractizare a datelor. Asigurarea independenei fizice i logice a datelor impune adoptarea unor arhitecturi de baze de date organizate pe cel puin trei nivele:

- nivelul intern (baza de date fizic); - nivelul conceptual (modelul conceptual, schema

conceptual): - nivelul extern (modelul extern, subschema, vedere). Schema general a unei baze de date care respect o asemenea

organizare este prezentat n figura 1.1. Nivelul intern Poart i numele de baz de date fizic, este o colecie de

fiiere, coninnd datele fizice, la care se adaug diverse structuri auxiliare menite s asigure accesul operativ la aceste date. Structurile auxiliare pot fi: directoare, indeci, pointeri, tabele de dispersie .a.m.d. Baza de date fizic este rezident n memoria secundar a calculatorului, n general pe discuri magnetice sau, mai recent, pe discuri optice. Modul de organizare al bazei de date fizice este n mare msur influenat de configuraia echipamentelor hardware care suport baza de date (tipul de calculator, numrul i tipul perifericelor, etc.) i de sistemul de operare. Schimbarea sistemului de operare sau modificri n configuraia echipamentelor hardware pot atrage modificri ale bazei de date fizice. Totui, dac este satisfcut condiia de independen fizic a datelor, aceste modificri n nivelul intern al bazei de date nu vor afecta nivelele superioare ale acesteia.

Fig.1.1. Schema general a unei baze de date Modelul conceptual Este o abstractizare a unei pri din lumea real i const din

descrierea structurii logice a datelor dintr-o baz de date. Fiecare baz de date are un model conceptual propriu prin care sunt numite i descrise toate unitile logice din baza de date, mpreun cu legturile dintre acestea. Prin uniti logice nelegem aici concepte de tipul celor cu care opereaz utilizatorii bazei de date, concepte prin care acetia i modeleaz aplicaiile.

Exemple: 1. n descrierea unei baze de date a unei intreprinderi vor

apare concepte de genul: Angajat, Manager, Produse, Beneficiari, Furnizori, etc.

2. Conceptele din baza de date a facultii vor fi: Studeni, Profesori, Bursieri, Note, Orar .a.m.d.

Modelul conceptual integreaz viziunile tuturor utilizatorilor asupra bazei de date, fiind rezultatul unui compromis ntre cerinele, adesea conflictuale, ale diverselor categorii de utilizatori. Realizarea unui asemenea compromis este absolut necesar pentru a fi posibil folosirea n comun a datelor.

Modelul conceptual specific ce anume poate face parte din baza de date (adic ceea ce corespunde descrierii), respectiv ce anume nu poate face parte din baza de date, iar aceasta rezult din specificarea unor constrngeri explicite asupra datelor. Constrngerile reprezint proprieti ale datelor care nu pot fi exprimate prin descrieri de structur. Aceste proprieti se refer la restricii asupra valorilor pe care le pot lua datele sau la restricii privind legturile dintre diferite uniti logice. Constrngerile pot fi declarate de ctre proiectantul bazei de date i integrate n modelul conceptual al acesteia. naintea oricrei operaii de actualizare a bazei de date sunt verificate n mod automat constrngerile aferente. Dac actualizarea conduce la violarea vreuneia din constrngeri, atunci execuia acesteia este interzis. Mecanismul de mai sus este total transparent fa de programele de aplicaii ale utilizatorilor care nu trebuie s cunoasc existena i natura acestor constrngeri i nici nu trebuie s includ proceduri speciale pentru verificarea explicit a constrngerilor. Tot n modelul conceptual sunt specificate anumite msuri de securitate i integritate, cu caracter general, referitoare la anumite uniti logice.

Trebuie subliniat faptul c modelul conceptual este o descriere a coninutului de informaie al bazei de date i nu cuprinde nici un fel de referire la modul de memorare al datelor sau la strategia de acces. Prin modelul conceptual se realizeaz o gestiune independent a structurii logice generale a bazei de date, gestiune care cade n sarcina administratorului bazei de date, utilizatorul fiind astfel degrevat de necesitatea de a cunoate ntreaga structur a bazei de date.

Prin modelul conceptual este realizat independena fizic a datelor. Modelului conceptual i se asociaz o transformare care definete modul n care structura logic de date este transpus n structura fizic de memorare. Aceasta este interfaa dintre modelul intern i ce! conceptual. La nivelul acestei interfee se specific structurile fizice de date folosite pentru inplementarea structurilor logice, strategiile de acces la aceste structuri fizice, organizarea pe suportul de memorare, indexrile folosite .a.m.d. Modificri n structura de memorare sau schimbarea suportului magnetic pot afecta doar interfaa model conceptual-model intern implicnd de exemplu modificarea strategiilor de acces, dar nu afecteaz modelul conceptual. Acesta este mecanismul de realizare al independenei fizice a datelor.

Modelul extern Poate fi privit ca o descriere a unei "baze de date virtuale"

corespunztoare viziunii unui utilizator sau grup de utilizatori. Aceast descriere este fcut n termenii unitilor logice din modelul conceptual. De regul, un model extern cuprinde o parte a unitilor logice dintr-un model conceptual, dar poate conine i uniti logice care nu exist n modelul conceptual i care nu au corespondent direct n baza de date fizic. Acestea din urm sunt uniti logice vituale i pot fi obinute prin modificarea unor uniti logice reale sau prin combinarea a dou sau mai multe uniti logice reale.

Modelul extern este nivelul cel mai apropiat de utilizator. Fiecrui utilizator sau grup de utilizatori i corespunde un model extern propriu, individualizat n raport cu cerinele sale specifice. Modelul extern corespunztor unui utilizator este ceea ce vede acesta din baza de date sau modul n care vede acesta baza de date. Modelul extern este derivat din modelul conceptual, dar poate prezenta deosebiri substaniale fa de acesta. Prin folosirea modelelor externe se realizeaz o relaxare a situaiei de conflict

care apare atunci cnd se dorete integrarea punctelor de vedere ale diverilor utilizatori ntr-un model conceptual unic.

Termenul tehnic adesea folosit pentru modelul extern este acela de vedere. Vederile au mai multe utilizri n cadrul bazelor de date. Una dintre acestea este asigurarea securitii bazei de date prin limitarea accesului la date a anumitor categorii de utilizatori. ntr-adevr, prin vederi utilizatorii au acces, de regul, doar la pri bine definite din baza de date fiindu-Ie ascunse acele pri pe care nu trebuie s le "vad" sau care nu i ntereseaz. Pe de alt parte, n general, un utilizator poate avea diferite drepturi de acces definite n cadrul a mai multe vederi. Prin unele vederi poate avea doar drept de consultare a datelor, n timp ce prin altele ar putea avea i drepturi de modificare. Astfel, prin vederi, sunt controlate posibilitile de acces la date ale utilizatorilor.

O alt funcie important a vederilor este de a oferi utilizatorilor nu numai o viziune individualizat, dar i simplificat asupra bazei de date. Fiind descrieri care se refer, de obicei, la fragmente ale bazei de date, vederile ascund utilizatorului acele pri din descrierea general a bazei de date care nu-1 intereseaz pe acesta. Mai mult, prin facilitatea de definire a unitilor logice virtuale, vederile se evideniaz ca un nivel de abstractizare mai ridicat dect modelul conceptual. ntr-adevr, o unitate logic virtual poate fi un concept derivat din una sau mai multe uniti logice existente n cadrul modelului conceptual. De regul, aceste concepte derivate sunt mai apropiate de utilizator, astfel nct pentru acesta este mai simplu s gndeasc i s opereze cu conceptele derivate dect n termenii unitilor logice din care au fost derivate.

Exemple: 1. Fie o baz de date care conine date referitoare la personalul

unei intreprinderi. Vrsta fiecrui angajat este o informaie care poate interesa n mai multe situaii: pentru vizualizare direct (rapoarte), pentru elaborarea de statistici, pentru stabilirea unor drepturi bneti sau pentru stabilirea listei celor susceptibili de a fi pensionai. Pe de alt parte este total impractic s se memoreze ca atare vrsta fiecrui angajat n baza de date deoarece aceasta ar impune, probabil, actualizarea zilnic a bazei de date (pentru a incrementa vrsta tuturor celor care-i srbtoresc naterea chiar n acea zi!). Soluia care se impune n aceast situaie, este de a memora nu vrsta, ci data naterii fiecrui angajat, iar pentru utilizatorii interesai de vrst se definete o vedere n care apare definit conceptul vrst calculat ca diferena dintre data curent i data naterii angajatului.

2. n baza de date a unei faculti sunt definite conceptele Student, reprezentnd informaii referitoare la studeni, i Note, reprezentnd notele acestora. Fiecrui concept i corespunde la nivelul bazei de date fizice cte un fiier coninnd datele respective. La secretariatul facultii funcioneaz o aplicaie referitoare la studenii bursieri. Aceast aplicaie opereaz cu conceptul Bursier, definit astfel:

"Este bursier orice student avnd media notelor peste 8." Este limpede c lista studenilor bursieri se determin din

datele corespunztoare conceptelor Student i Note. Rezult c putem defini conceptul Bursier ca fiind o unitate logic virtual derivat din conceptele Student i Note. Pentru lucrtorii de la secretaritul facultii este mult mai simplu s opereze cu conceptul Bursier, dect s combine conceptele Student i Note ori de cte ori doresc s se refere la Bursieri. Mai mult nici nu este necesar ca acetia s cunoasc definiia conceptului Bursier care se poate modifica fr a afecta aplicaiile care l utilizeaz. Conceptului Bursier nu i va corespunde un fiier propriu la nivelul bazei de date fizice. Un fiier separat cu studenii bursieri ar nsemna un consum suplimentar de spaiu de memorare, dar i introducerea redondanei datelor cu multiple consecine nedorite care vor fi analizate n capitolele urmtoare.

n principiu, o unitate logic virtual poate fi invocat i poate participa la operaii la fel ca orice alt unitate logic. De obicei, o operaie asupra unei uniti logice virtuale este transpus n operaii corespunztoare asupra unitilor logice din care aceasta este derivat. Astfel o operaie care implic vrta unui angajat (vezi exemplul 1) de mai sus) se traduce printr-o operaie similar asupra diferenei dintre data curent i data naterii angajatului respectiv. Totui, exist situaii n care o asemenea transpunere nu este posibil. n cazul unitilor logice virtuale definite pe baza a mai multe uniti logice din modelul conceptual, anumite operaii nu sunt permise deoarece nu pot fi transpuse n mod univoc n operaii asupra unitilor logice din care sunt derivate, ceea ce nseamn c nu li se poate atribui o semnificaie bine definit. Astfel, operaia de tergere a unei nregistrri, invocat la nivelul conceptului Bursier, poate s nsemne faptul c acesta nu mai este bursier (a luat note mici i a pierdut bursa!), dar poate nsemna i faptul c respectivul a renunat la facultate. n primul caz este nu este necesar o tergere din fiierul corespuztor conceptului Student, iar n al doilea caz o asemenea operaie este necesar. La nivelul conceptului Bursier, nu se poate face distincie ntre cele dou situaii, motiv pentru care operaia de tergere este interzis.

Prin modelul extern se realizeaz independena logic a datelor. Fiecrei vederi i corespunde o descriere n termenii unitilor logice din modelul conceptual. Aceast descriere definete transformrile prin care din structura logic de la nivelul modelului conceptual rezult modelul extern. Aceste transformri definesc interfaa dintre modelul conceptual i modelul extern. Modificrile modelului conceptual pot determina modificri ale acestei interfee, deci modificri ale descrierii vederii, dar nu pot afecta vederea n sine aa cum este ea perceput de utilizator. Acesta este mecanismul de realizare al independenei logice a datelor.

Exemplu: Modelul conceptual al bazei de date din cadrul facultii ar

putea fi modificat prin reunirea conceptelor Student i Note, ntr-unui singur, Student_note care s reprezinte att datele personale ale studenilor, ct i notele acestora. n aceste condiii modul de derivare al conceptului Bursier se modific, el nu va fi derivat din dou uniti logice distincte, ci din conceptul reunit Student_note. La nivelul utilizatorilor din secretariatul facultii semnificaia conceptului Bursier rmne aceeai, cu toate c descrierea lui din cadrul vederii s-a modificat. Vederea corespunztoare conceptului Bursier i aplicaiile care l utilizeaz sunt neafectate de modificarea de mai sus.

1.4. Sistemul de gestiune al bazei de date

Sistemul de gestiune al bazei de date - SGBD, (n englez Data Base Management System - DBMS) este ntregul ansamblu software care trateaz toate cererile de acces la baza de date.

O cerere de acces la baza de date, de exemplu o interogare, este formulat de ctre utilizator n termenii conceptelor de la nivelul uneia din vederile definite n sistem. Aceast cerere este interceptat de ctre SGBD i interpretat de ctre o component a acestuia interpretorul LMD. Rezultatul este o reprezentare n format intern a interogrii. n continuare interogarea parcurge o serie de etape succesive de prelucrare prin care dintr-o interogare formulat n termenii unor concepte de la nivelul vederilor rezult o serie de comenzi de acces la fiierele fizice din baza de date. n etapele succesive de transformare SGBD folosete informaiile de descriere de la toate nivelele bazei de date (modelul extern, modelul conceptual, nivelul intern), mpreun cu descrierile interfeelor model extern-model conceptual i model conceptual-

nivel intern. Pe lng acestea SGBD mai poate consulta o serie de tabele cum ar fi: tabelele de autorizare a accesului la date, tabelele coninnd informaiile de control al accesului concurent .a.m.d. De asemenea, pe toate nivelele de prelucrare, pe lng transformarea dintr-o form de reprezentare n alta, mai apar i pai de prelucrare care au drept scop optimizarea execuiei interogrii respective. Aceste prelucrri de optimizare, sunt de natur diferit de la un nivel de prelucrare la altul, iar la fiecare nivel sunt valorificate informaiile adecvate de la nivelul de descriere corespunztor.

Cererile de acces la fiierele fizice, rezultate din transformarea interogrii, sunt preluate i rezolvate de ctre un sistem de gestiune al fiierelor. Acesta poate fi un sistem general, parte a sistemului de operare care gzduiete baza de date sau un sistem specializat, adaptat cerinelor speciale ale sistemului de gestiune al bazei de date.

Datele extrase din fiierele fizice, sub forma unor iruri de bii, parcurg apoi calea invers, rezultatul transformrilor succesive fiind un rspuns formulat n termenii cunoscui de utilizator (sub form de tabele, rapoarte, etc.)

De remarcat c o cerere, aparent simpl la nivelul utilizatorului, poate conduce la operaii complexe pe nivelele inferioare, ajungnd la accesarea a mai multe fiiere de la nivelul fizic, eventual, cu consultarea structurilor ajuttoare i chiar la operaii complexe de manipulare, calcul, comparaii .a.m.d.

Exemplu: O interogare de forma: Numele studenilor bursieri din anul II? adresat bazei de date a facultii, implic o serie de manevre

i operaii care, intuitiv i foarte simplificat, s-ar putea rezuma astfel:

- transformarea interogrii iniiale, exprimat n termenii conceptului Bursier, ntr-o interogare echivalent care invoc conceptele Student i Note;

- transformarea interogrii rezultate la pasul precedent n operaii de acces la fiierele corespunztoare conceptelor Student i Note;

- selectarea studenilor din anul II; - calculul mediei notelor pentru fiecare student din anul II; - selectarea din lista rezultat la pasul precedent a studenilor

cu media peste 8. SGBD cuprinde dou faciliti importante pentru proiectarea

i exploatarea bazelor de date: - faciliti de descriere a datelor, - faciliti de manipulare a datelor. Facilitile de descriere a datelor Sunt materializate, n esen, prin limbajul de descriere a

datelor - LDD (n englez Data Description Language - DDL). LDD servete

pentru descrierea modelelor externe, al modelului conceptual i a interfeelor dintre cele trei nivele de organizare a bazei de date. De multe ori, LDD conine i faciliti pentru descrierea unor aspecte legate de structura fizic de date. Alte faciliti ale LDD se refer la anumite operaii de ntreinere cum ar fi: ncrcarea bazei de date, specificarea restriciilor de integritate .a.

Facilitile de manipulare a datelor Se refer, n principal la limbajele de manipulare a datelor -

LMD (n englez Data Manipulation Language - DML), numite adesea printr-un abuz de exprimare i limbaje de interogare. Acestea constituie interfaa dintre SGBD i utilizatori. Un LMD const dintr-un set de comenzi primitive care corespund operaiilor uzuale n exploatarea bazei de date cum sunt: formularea cererilor de acces la date (interogri), adugarea, tergerea i actualizarea datelor.

1.5. Perspective n dezvoltarea sistemelor de gestiune a bazelor de date

SGBD-urile clasice, aa cum sunt majoritatea covritoare a sistemelor comerciale aflate astzi n exploatare, au fost proiectate pentru a satisface cerinele unui anumit gen de aplicaii, destul de limitat. Aceste aplicaii provin, de cele mai multe ori, din domeniul economic. Cteva exemple tipice ar fi: probleme de gestiune a ntreprinderilor (personal, magazii, salarii, producie, etc), sisteme de rezervare a locurilor, sisteme de gestiune biblioteci, aplicaii financiar-bancare .a. Caracteristica comun a tuturor acestor aplicaii este volumul mare de date asupra crora se aplic o serie de operaii care, n esen, sunt relativ simple. Prelucrrile din aceste aplicaii sunt dominate de operaii de tip adugare, tergere, actualizare, respectiv operaii simple de regsire a unor nregistrri care satisfac nite condiii date. Limbajele de manipulare din cadrul acestor sisteme au fost adaptate cerinelor clasei de aplicaii crora le sunt destinate. Ele rezolv cu eficien problema accesului operativ la volume mari de date, dar au o putere de expresie limitat, considerabil mai redus dect cea a limbajelor de programare convenionale cum sunt: C, PASCAL, FORTRAN sau COBOL. Aceasta nseamn c exist numeroase probleme care pot fi rezolvate n cadrul acestor limbaje, dar pentru care nu se poate exprima o soluie folosind exclusiv operaiile disponibile ntr-un LMD. Aa cum se va vedea n capitolul 3., LMD nu permit exprimarea unor operaii cu caracter recursiv. Limitarea sever a puterii de expresie a LMD-urilor din bazele de date nu este deloc ntmpltoare, ci este vorba de un compromis care a fost absolut necesar pentru ca SGBD-urile s poat deveni ceea ce sunt astzi. ntr-adevr a efectua operaii complexe implicnd volume mari de date este o problem pentru care, n general, nu se cunosc soluii eficiente. Deci reducerea LMD-urilor la cteva operaii simple a fost necesar pentru a putea menine n limite acceptabile timpul de rspuns al SGBD-urilor chiar i n cazul cnd se opereaz cu volume mari de date. Pe de alt parte, simplitatea LMD-urilor face posibil utilizarea optimizatoarelor automate capabile s transforme interogrile formulate de utilizator n altele, echivalente, dar care se execut mult mai eficient. Aceste optimizatoare pot exploata informaii referitoare la structurile fizice auxiliare (indeci, tabele de dispersie, etc.) de care utilizatorul nu are i nici nu trebuie s aib cunotin (vezi independena fizic a datelor).n urma fazei de optimizare a interogrilor reducerea timpului de execuie poate fi destul de drastic, o reducere de 100.000 de ori fiind ceva obinuit. Este deci limpede c ar fi de neconceput funcionarea SGBD-urilor fr asemenea optimizatoare. Alternativele ar fi fost fie timpi de execuie prohibitivi pentru interogri, fie complicarea inacceptabil a sarcinilor utilizatorului care ar fi trebuit s cunoasc mult mai multe detalii despre structura fizic a datelor pentru a putea ncerca optimizarea sau mcar ameliorarea manual a interogrilor. De remarcat faptul c pentru limbajele de programare convenionale nu se cunosc termici de optimizare care s conduc la reduceri att de masive a costurilor de execuie ca n cazul LMD-urilor.

n ultimul timp apar tot mai multe aplicaii de baze de date care prin caracteristicile lor nu se mai ncadreaz n clasa aplicaiilor pentru care sunt destinate SGBD-urile actuale. Multe dintre aceste aplicaii provin din domeniul proiectrii, dar nu numai. Cteva exemple tipice ar fi: proiectarea circuitelor VLSI, CAD, baze de date grafice, ingineria programelor .a. Aplicaiile de baze de date din aceste domenii se caracterizeaz prin necesitatea de a accesa i manipula volume mari de date, la fel ca

n cazul SGBD-urile clasice, dar i prin necesitatea de a efectua operaii mult mai complexe dect n cazul acestora. n cazul acestor aplicaii este tot mai evident necesitatea de a dispune de limbaje de manipulare cu o putere de expresie mult mai apropiat de sau chiar egal cu cea a limbajelor de programare convenionale.

La ora actual se contureaz dou alternative pentru soluionarea acestei probleme:

1. Abordarea orientat pe obiect este concretizat prin sistemele de gestiune a bazelor de date orientate pe obiect (SGBD-OO). Aceste sisteme ncearc s rezolve problema artat mai sus prin a transfera o parte din complexitatea prelucrrilor n structura de date. La ora actual exist numeroase SGBD-OO cum ar fi: Iris, Orion, GemStone, O2, sau Ontos; unele dintre acestea se afl n faz de prototip, n timp ce altele sunt deja produse comerciale. Principalele caracteristici comune ale acestor sisteme se pot rezuma astfel:

a. Posibilitatea de manipulare a obiectelor complexe. n sistemele orientate pe obiect se pot defini tipuri de date avnd structuri complexe, fiind posibil imbricarea tipurilor de date. Aceasta ofer posibilitatea definirii de ierarhii de tipuri n care tipurile pot avea subtipuri derivate cu proprieti speciale.

b. ncapsularea const n posibilitatea de a defini proceduri care se aplic doar obiectelor de un anumit tip. Mai mult, aceste proceduri constituie singura posibilitate de a accesa i manipula obiectele tipului respectiv, ncapsularea nseamn c fiecare obiect are dou componente: o interfa i o implementare. Implementarea poate fi modificat fr a afecta interfaa. Astfel programele de aplicaii vor fi independente fa de modul de implementare al obiectelor.

c. Identitatea obiectelor se refer la faptul c se poate face distincie ntre dou obiecte identice, avnd aceleai proprieti i aceleai valori ale proprietilor. Cele dou obiecte nu se vor confunda, ci va avea fiecare o identitate proprie sistemul tratndu-le ca obiecte distincte.

2. Abordarea logic este reprezentat prin sistemele de gestiune a bazelor de cunotine (SGBC). Un SGBC satisface dou condiii:

- furnizeaz toate serviciile oferite de un SGBD obinuit (acces eficient la volume mari de date, gestiunea tranzaciilor .a.m.d.);

- posed un limbaj declarativ a crui putere de expresie este apropiat sau chiar egal cu cea a limbajelor convenionale.

Sistemele din aceast categorie sunt, deocamdat, n faz de proiect. Majoritatea lor pornesc de la ideea de a adapta limbajele logice de tip PROLOG la cerinele impuse de exploatarea bazelor de date. De fapt, cercetrile referitoare la SGBC urmresc gsirea unui compromis ntre cerinele impuse de un limbaj logic complet cum este PROLOG, i cerinele de manipulare a volumelor mari de date. n acesta direcie se nscriu i cercetrile referitoare la familia de limbaje DATALOG (vezi paragraful 3.1.3.).

2. MODELE DE DATE Utilitatea oricrei colecii de date n obinerea de informaii

depinde n mare msur de modul de organizare al acestor date. Regulile dup care sunt organizate i manipulate datele depind de modelul de date utilizat. n acest capitol prezentm cteva noiuni de baz legate de modelarea datelor precum i o scurt trecere n revist a principalelor modele de date utilizate n proiectarea SGBD-urilor:

- modelul ierarhic; - modelul reea; - modelul relaional.

2.1. Modelarea datelor Dup cum s-a artat deja, datele n sine nu constituie

informaie. Pentru a fi utile n procesul de inferare a informaiei, datele trebuie s fie organizate ntr-un anumit mod. Posibilitile de organizare a datelor sunt foarte variate. Prin modelarea datelor se urmrete organizarea acestora n aa fel nct s fie ndeplinite urmtoarele dou cerine:

s se reprezinte ct mai fidel situaia din lumea real; datele s fie adaptate reprezentrii i prelucrrii pe

calculator. Aceste dou cerine sunt foarte adesea conflictuale. Modelarea

datelor, n vederea organizrii lor pentru a fi utilizate n aplicaii, presupune identificarea celor mai importante caracteristici ale datelor, caracteristici care surprind esena semnificaiei acestora. Generalizarea i formalizarea acestor caracteristici a condus la definirea conceptului de model de date. Un model de date este un instrument teoretic care permite obinerea unei interpretri adecvate a datelor. Modelul de date ne ajut s identificm semnificaia sau coninutul de informaie al unei colecii de date, vzut n ansamblul ei. prin contrast cu valorile individuale ale datelor. Din punct de vedere tehnic un model de date este un formalism avnd dou componente:

1. Un set de reguli pentru organizarea i structurarea datelor. 2. Un set de reguli (operaii) pentru manipularea datelor. Modelele de date se pot mpri n dou grupuri:

modele de date strict tipizate Sunt cele n care fiecare dat trebuie s aparin unei categorii.

Datele care nu se ncadreaz n mod natural ntr-o categorie vor trebui s fie forate ntr-una din categoriile modelului n caz contrar aceste date nu pot fi tratate n cadrul modelului considerat. De asemenea, pentru unele dintre aceste modele se presupune c gama categoriilor disponibile este predefinit i nu poate evolua dinamic. modele de date slab tipizate

Sunt cele care nu fac nici o presupunere referitor la categorii. Categoriile sunt permise numai n msura n care se dovedesc utile. Datele individuale pot exista prin ele nsele i pot fi legate de alte date. Informaiile referitoare la categorii, dac exist, sunt tratate n acelai mod ca i informaiile despre date.

Modelele de date strict tipizate au dezavantajul lipsei de flexibilitate, ceea ce face dificil reprezentarea deosebirilor semantice mai subtile. S considerm de exemplu datele despre categoria ANGAJAT. ntr-un model strict tipizat aceast categorie trebuie s fie omogen, adic toate obiectele acestei categorii trebuie s aib aceleai proprieti, aceeai structur .a.m.d. Totui, a.igajaii cstorii au proprieti diferite fa de cei necstorii, dup cum este cazul i cu angajaii temporari fa de cei permaneni i exemplele ar putea continua. n ciuda acestor dificulti, modelele de date strict tipizate au marele avantaj c proprietile datelor pot fi abstractizate i cercetate n termenii categoriilor crora le aparin. Altfel spus. bazat pe aceste categorii se poate formula o teorie care cuprinde proprietile datelor. Deoarece unele dintre proprietile categoriilor sunt motenite de ctre datele care fac parte din ele, a demonstra un anumit lucru despre o categorie constituie o demonstraie i pentru datele din aceast categorie. De asemenea, categoriile fiind omogene, toate obiectele au acelai nume i aceleai proprieti, astfel c numele comun al obiectelor i numele proprietilor pot fi asociate categoriei, evitndu-se repetarea lor pentru fiecare obiect, respectiv proprietate a sa.

Pentru a obine omogenitatea datelor orice model strict tipizat impune anumite restricii asupra categoriilor de obiecte i asupra legturilor dintre acestea care sunt reprezentabile prin modelul respectiv. Prin restriciile pe care le impun, modelele de date strict

tipizate sunt mai puin expresive n modelarea situaiilor din lumea real dect modelele de date slab tipizate, dar prin ncadrarea obiectelor n categorii omogene ele se dovedesc a fi adecvate pentru transpunerea pe calculator n scopul prelucrrii unor cantiti mari de date. Iat de ce modelele de date care stau la baza proiectrii SGBD-urilor sunt, cel puin pn la ora actual, modele strict tipizate.

Un model conceptual sau schem cuprinde numele categoriilor (ex: PERSOANE, MAINI), proprietile acestora (ex: Nume persoan, Marc main) i legturile dintre categorii (ex: PERSOANA POSEDA MAINA). Deci orice model conceptual este o descriere a unei anumite structuri de date. Regulile dup care este construit un model conceptual, deci regulile de organizare i structurare a datelor sunt definite n cadrul unui model de date.

Structura de organizare a datelor nu furnizeaz o interpretare complet a semnificaiei acestora. Semnificaia datelor depinde i de modul n care acestea sunt utilizate. De aceea este necesar s se specifice i operaiile permise asupra datelor. De exemplu, o list de obiecte poate fi o stiv sau o coad funcie de tipul operaiilor permise asupra obiectelor listei. Natura general a operaiilor care sunt permise asupra datelor sunt precizate tot n cadrul modelului de date i este dependent de structurile de date corespunztoare acestui model. n concluzie, putem defini un model de date ca fiind un ansamblu de reguli pentru organizarea datelor, mpreun cu un set de operaii permise asupra acestor date.

Baza de date este o colecie de date organizate ntr-o structur descris printr-un model conceptual (schem).

Regulile de structurare a datelor (de construire a schemei) i operaiile permise asupra datelor sunt definite n cadrul modelului de date.

Orice model de date constituie un model al lumii nconjurtoare i ncearc s cuprind proprietile acesteia. Aceste proprieti se mpart n dou clase: statice i dinamice. Proprietile statice sunt cele care nu se modific deci sunt invariante n timp. Proprietile dinamice ncearc s surprind natura evolutiv a lumii nconjurtoare.

Un model de date, notat M, poate fi definit ca fiind compus din dou pri:

un set de reguli de structurare a datelor, numite i reguli generatoare, notate G. Aceste reguli exprim proprietile statice ale modelului de date i sunt materializate n cadrul unui SGBD prin limbajul de descriere a datelor (LDD),

un set de operaii permise asupra datelor, notate O. Aceste operaii exprim proprietile dinamice ale modelului de date i sunt materializate n cadrul unui SGBD prin limbajul de manipulare a datelor (LMD).

Limbajul de descriere date se folosete pentru descrierea structurilor de date permise n cadrul unui model de date M. Structurile permise pot fi specificate n dou moduri complementare:

1. Prin specificarea obiectelor permise i a relaiilor permise dintre ele folosind reguli generice de definire.

2. Prin specificarea obiectelor i relaiilor nepermise care sunt excluse nrin definirea unor restricii numite constrngeri.

Unele modele de date partiioneaz regulile generatoare G n dou pri: partea de specificare a structurii, Gs, i partea de specificarea constrngerilor, Gc. Regulile generatoare Gs genereaz structura unei scheme, iar regulile generatoare Gc genereaz constrngerile asociate schemei. n consecin o schem S va consta din dou pri: o parte de structur Ss i o parte de constrngeri Sc care cuprinde o list explicit de constrngeri care trebuie respectate. Pe lng constrngerile explicite un model de date introduce i unele constrngeri

implicite, inerente modelului, care sunt ncorporate n partea de structur Ss. Altfel spus structura nsi, prin definiia sa, poate exclude anumite obiecte sau poate limita anumite relaii ntre obiecte. De exemplu, n cazul modelului ierarhic relaiile dintre obiecte sunt restricionate la cele care corespund unei structuri de arbore.

Limbajul de manipulare date cuprinde operaii care produc o schimbare n starea bazei de date. Starea unei baze de date este specificat prin totalitatea valorilor datelor din baz la un moment dat. la care se adaug valorile indicatorilor de poziie curent folosii pentru regsirea datelor. Starea unei baze de date reflect aspectul dinamic al unui mode! de date prin faptul c se schimb ca urmare a unei operaii asupra bazei de date. Aceast schimbare poate afecta fie datele din baz (n cazul operaiilor de adugare, tergere, actualizare), fie valoarea indicatorilor de poziie curent (n cazul operaiilor de localizare a unei date, operaii de tipul "get next" .a.).

Este important de remarcat faptul c operaiile din cadrul LMD nu pot afecta structura bazei de date, deci aceste operaii conserv modelul conceptual al bazei de date asupra creia acioneaz.

LDD i LMD constituie principalele faciliti ale unui SGBD. Orice SGBD are la baz un anumit model de date, M, care constituie fundamentul teoretic al construirii acestuia, iar LDD i LMD sunt materializri ale celor dou pri componente G i O ale modelului de date M. Deci, n principiu, orice SGBD va putea fi caracterizat pe baza modelului de date asociat. De exemplu, SGBD System R are la baz modelul de date relaional i este cunoscut ca un sistem relaional care gestioneaz baze de date relaionale.

2.2. Abstractizare Una dintre principalele ci de structurare i vizualizare a

datelor este prin folosirea abstractizrii. Abstractizarea const n neglijarea aspectelor nerelevante i

concentrarea asupra proprietilor care prezint interes dintr-un anumit punct de vedere.

Coninutul oricrei forme de abstractizare este legat de criteriul de relevan i este determinat de anumite obiective. Orice form de abstractizare are n vedere un anumit scop. Prin procesul de abstractizare se rein acele aspecte care sunt relevante pentru scopul propus.

n modelarea datelor, abstractizarea este folosit pentru a obine categorii de date sau pentru a combina categorii de date n categorii mai generale. O form elementar de abstractizare este tipizarea prin care se definete un tip pornind de la o clas de obiecte similare. Abstractizarea se poate face pe mai multe nivele, tipurile de pe un nivel constituind obiecte pentru nivelul superior de abstractizare. Se obin astfel ierarhii de tipuri, rezultnd structuri de o mare putere expresiv n cadrul crora tipurile generate i legturile existente ntre acestea sunt mai uor de neles i de vizualizat. Relativ la obiectele din bazele de date se folosesc dou forme de abstractizare:

Generalizarea care asociaz unei mulimi de obiecte sau unei mulimi de tipuri un singur tip generic. Prin generalizare sunt scoase n eviden similitudinile dintre obiecte sau tipuri i sunt neglijate deosebirile dintre acestea. De obicei, se face distincie ntre generalizarea obiect-tip, care este numit clasificare, i generalizarea tip-tip considerat ca fiind generalizarea propriu-zis. De exemplu, reunirea unei mulimi de studeni n tipul generic STUDENT se face prin clasificare, iar reunirea tipurilor STUDENT i PROFESOR n tipul generic PERSOANA este considerat generalizare. Instanierea este opusul procesului de clasificare, iar specializarea este opusul generalizrii. Prin

aplicarea pe mai multe nivele a generalizrii se obin ierarhii de generalizare.

Un tip generalizat poate s reuneasc, de obicei, toate proprietile comune ale obiectelor i tipurilor constituente. Reciproc, toate proprietile tipului generalizat pot fi motenite de tipurile i obiectele constituente. Totui, motenirea anumitor proprieti poate fi explicit invalidat pentru unii dintre constitueni. De asemenea, pentru tipul generalizat pot fi definite proprieti specifice acestuia care nu se motenesc. De exemplu, n ierarhia din figura 2.1., proprietile tipului PERSOANA cum sunt NUME i ADRESA se motenesc de ctre toi constituenii pe toate nivelele: STUDENT, CADR. DID., SECRETARA, CONF. .am.d. Proprietatea oricrui ANGAJAT de avea un singur loc de munc este motenit de ctre personalul administrativ, de ctre asisteni, dar nu i de profesori. n sfrit tipul ANGAJAT poate avea proprietatea specific SALAR MEDIU care nu este motenit de ctre nici unul dintre constitueni.

Agregarea este o form de abstractizare prin care un obiect este construit din prile sale componente. De exemplu, o

persoan poate fi caracterizat prin nume, adres i vrst. Agregarea se aplic att la nivelul tipurilor, ct i la nivelul valorilor individuale. Astfel tipul PERSOANA poate fi construit prin agregare din tipurile NUME, ADRESA i VRSTA. O valoare concret a tipului PERSOANA se construiete printr-o agregare izomorf cu cea a tipului creia i aparine din valorile corespunztoare ale tipurilor constituente. De exemplu persoana lonescu, instan a tipului PERSOANA, este constituit prin agregare din valorile Ionescu, Cluj, 34. Tipurile NUME. ADRESA i VRSTA sunt proprietile intensionale ale tipului PERSOANA. Valorile Ionescu, Cluj i 34 sunt proprietile extensionale ale acelei instanieri a tipului PERSOANA care caracterizeaz persoana cu numele Ionescu.

Agregarea permite punerea n eviden a structurii unui obiect n mod gradat i arat modul n care prile constituente se raporteaz la acesta, respectiv relaiile ntre aceste pri constituente. La fel ca i generalizarea, agregarea se poate aplica repetat pe mai multe nivele rezultnd ierarhii de agregare. n figura 22. constituentul ADRESA al tipului agregat PERSOANA este la rndul lui un tip agregat avnd constituenii LOCALITATE, STRADA i NUMR.

Folosind generalizarea mpreun cu agregarea se poate exprima att clasificarea obiectelor i tipurilor, ct i structura lor.

n ierarhia din figura 2.3. PERSOANA este o generalizare a tipurilor ANGAJAT i STUDENT. Ca urmare, exceptnd cazul n care motenirea anumitor proprieti este invalidat, tipurile ANGAJAT i STUDENT vor moteni proprietile NUME, ADRESA i VRSTA care constituie componentele de agregare pentru tipul PERSOANA.

Generalizarea i agregarea sunt legate de conceptele ISA i PARTOF din inteligena artificial. Conceptul ISA corespunde generalizrii i exprim faptul c un tip este o specializare (form particular) a unui alt tip. (De exemplu, STUDENT este o PERSOANA.) Conceptul PARTOF corespunde agregrii i exprim faptul c un obiect sau tip este parte a unui alt tip. (De exemplu, NUME este parte din PERSOANA.)

2.3. Entiti, legturi ntre entiti Un model conceptual cuprinde descrierea tuturor entitilor

unei baze de date mpreun cu toate legturile existente ntre ele. O entitate este un coninut de sine stttor, o realitate obiectiv care exist prin ea nsi. Orice entitate este caracterizat prin proprietile sale. n cadrul modelelor de date aceste proprieti sunt reprezentate prin atribute. Entitile, la rndul lor, sunt reprezentate prin tipuri de entiti. Un tip de entitate este o reprezentare n cadrul unui model de date care corespunde unei categorii de obiecte din lumea real i constituie intensiunca acestei categorii. Din punct de vedere tehnic tipul de entitate corespunde definiiei unei entiti n termenii atributelor sale, fiind rezultatul agregrii acestor atribute. Prin prisma generalizrii, un tip de entitate poate fi considerat rezultatul clasificrii (generalizare tip-obiect) unei mulimi de entiti avnd proprieti comune, fiind reprezentarea intensional a grupului de entiti de acelai fel. De asemenea, un tip de entitate poate corespunde generalizrii unuia sau mai multor tipuri de entiti.

rezentat prin tipul de entitate Exemplu: Mulimea de entiti student poate fi re Student avnd

urmtoarele atribute: - Nume; - ncadrare (zi, seral); - Situaia_colar (bursier, nebursier); - An (1,2,3,4, 5); - Sex (M, F). Analog mulimea de entiti profesor poate fi reprezentat prin

tipul de entitate Profesori avnd atributele: - Nume; - Funcie (preparator, asistent, lector, confereniar, profesor); - Disciplina (programare, baze de date, etc). Trebuie menionat faptul c pentru reprezentarea unei mulimi

de entiti din lumea real printr-un tip de entitate se iau n considerare doar acele proprieti care sunt relevante pentru baza de date n care este inclus tipul de entitate.

Extensiunea unui tip de entitate este format din mulimea entitilor, avnd proprieti comune, descrise prin tipul de

Persoana

Nume Adresa

Fig.2.3. Ierarhie de generalizare i agregare

Numr Localitate Strada

Angajat Student

Pregtire An studiu

Secie Salar Pers. Adm.

Secretar

Persoana

Angajat Student

Cadru didactic

Tehnician Contabil Preparator Asistent Lector

Fig.2.1. Ierarhie de generalizare

Persoana

Nume Adresa

Fig.2.2. Ierarhie de agregare

Data naterii

Numr Localitate Strada Zi An Lun

entitate dat. Fiecare entitate din aceast mulime este o instaniere a tipului de entitate creia i aparine. Entitile individuale, aparinnd unui anumit tip de entitate, se deosebesc ntre ele prin valorile diferite ale atributelor lor.

Exemplu: O entitate aparinnd tipului de entitate Profesor (deci o

instaniere a acestui tip) este: - Pop; - asistent; - programare. n cadrul diferitelor modele de date intervin dou forme de

structurare a datelor. Prima form de structurare a datelor se refer la modalitatea

de asociere a atributelor pentru a forma descrierile tipurilor de entiti crora le aparin. Toate modelele de date care vor fi prezentate n continuare reprezint tipurile de entiti prin structuri de tip nregistrare obinute prin simpla concatenare a valorilor atributelor tipului de entitate, operaie ce corespunde agregrii proprietilor tipului de entitate. Mulimile de entiti se modeleaz convenabil prin tabele a cror descriere (capul de tabel) este dat de descrierea tipului de entitate, iar liniile tabelului constau din reprezentrile entitilor din mulime (instanieri). ntre mulimile de entiti dintr-o baz de date exist diferite legturi (relaii). Aceste legturi trebuie s fie descrise n modelul conceptual al bazei de date.

A doua form de structurare a datelor se refer la modul n care sunt reprezentate legturile existente ntre diferitele mulimi de entiti ale bazei de date. Modelele de date difer ntre ele tocmai prin modul n care se poate realiza reprezentarea legturilor dintre mulimi de entiti.

ntre oricare dou mulimi de entiti M1 i M2 pot exista trei tipuri de legturi (relaii) (figura 2.4.):

- relaie 1:1, cnd unei entiti din M1 i corespunde o singur entitate din M2 i reciproc (relaie de tip so-soie).

- relaie 1:N, cnd unei entiti din M1 i corespund una sau mai multe entiti din M2, dar fiecrei entiti din M2 i corespunde o singur entitate din M1, (relaie de tip tat-fiu).

- relaie M:N, cnd unei entiti din M1 i corespund una sau mai multe entiti din M2 i reciproc (relaie de tip prieten-prieten).

Exemplu: Considernd mulimile de

entiti Student i Profesori ntre ele exist o relaie definit de activitatea de nvmnt care este de tip M:N, deoarece un profesor pred la mai muli studeni, iar fiecare student audiaz cursurile a mai muli profesori.

Funcie de modul n care sunt reprezentate relaiile ntre entiti distingem trei tipuri eseniale de modele de date:

- modelul ierahic; - modelul reea; - modelul relaional. Dintre aceste modele vom aprofunda doar modelul relaional.

2.4. Modelul de date relaional Modelul relaional a aprut relativ trziu n teoria i practica

bazelor de date. A fost necesar atingerea unui anumit nivel de performan a echipamentelor de calcul pentru a contientiza faptul c modelul relaional poate constitui nu numai un valoros instrument de studiu n teoria bazelor de date, ci i punctul de pornire pentru realizarea unor SGBD-uri competitive din punctul de vedere al performanelor.

Primul model de date bazat pe relaii i pe reprezentarea acestora sub form de tabele a fost propus de ctre cercettorul american E. F. Codd. Ideile sale au fost publicate ntr-o suit de lucrri de referin aprute cu ncepere din anul 1970. Principiile care stau la baza modelului de date relaional pornesc de la teoria matematic a relaiilor extins n mod logic pentru a satisface cerinele activitii de gestionare a datelor. Fundamentarea matematic a modelului relaional permite definirea i deducerea elegant i concis a proprietilor acestuia. Numeroase rezultate din teoria relaiilor i gsesc aplicabilitatea practic n cazul diferitelor probleme legate de bazele de date relaionale.

Modelul de date relaional st la baza majoritii SGBD-urilor comerciale care exist i apar la ora actual. Popularitatea crescnd a modelului relaional i rspndirea tot mai larg a bazelor de date relaionale se datoreaz, n mare parte, faptului c acestea dispun de limbaje pentru manipularea datelor de nivel nalt, simple, dar foarte puternice. Caracteristica principal a acestor limbaje, numite generic limbaje relaionale, este capacitatea lor de a permite definirea de relaii noi pe baza unor relaii existente. Pornind de la aceste limbaje n cadrul SGBD-urilor relaionale au fost dezvoltate interfee flexibile i prietenoase care deschid calea spre exploatarea direct a bazelor de date pentru categorii mult mai largi de utilizatori dect n cazul sistemelor bazate pe modelele de date ierarhic sau reea.

2.6.1. Relaii-definiii Definiie:

Fiind dat o colecie de mulimi D1,D2,...,Dn (nu neaprat distincte), spunem c R este o relaie pe aceste n mulimi, dac este o mulime de n-tuple ordonate (d1,d2,...,dn) astfel nct d1D1, d2D2,..., dnDn. Mulimile D1, D2, ,Dn sunt domeniile relaiei R. Valoarea n este gradul sau aritatea relaiei R. Cardinalitatea relaiei R este dat de numrul n-tuplelor coninute n relaie.

O definiie echivalent a noiunii de relaie are la baz noiunea de produs cartezian.

Definiie: Definim produsul cartezian D1XD2X...XD al mulimilor D1, D2,...,Dn ca fiind mulimea tuturor n-tuplelor ordonate (d1,d2,...,dn) astfel nct d1D1, d2D2,..., dnDn. O relaie R pe mulimile D1,D2,...,Dn este o submulime a produsului cartezian D1XD2X...XDn.

Din definiiile de mai sus rezult c orice relaie este o mulime ale crei elemente sunt n-tuple, nseamn c o relaie are o serie de proprieti care deriv din caracterul de mulime al acesteia.

O prim proprietate este acea c mulimile sunt colecii de elemente fr repetiie. n contentul relaiilor aceasta nseamn c ntr-o relaie nu exist dou n-tuple identice, ceea ce implic faptul c oricare dou n-tuple difer prin cel puin o valoare a

M2 M1

1:1

M2 M1

1:N

M2 M1

M:N

elementelor lor. Aceast proprietate st la baza definiri conceptului de cheie a unei relaii,

A doua proprietate a mulimilor care prezint interes pentru noi, se refer la faptul c ordinea elementelor ntr-o mulime este nerelevant. n consecin ordinea de niruire a n-tuplelor ntr-o relaie este arbitrar, iar prin schimbarea ordinii n-tuplelor relaia rmne neschimbat. Deci oricnd este posibil reordonarea convenabil a n-uplelor din cadrul unei relaii.

2.4.1. Domenii i atribute Definiie:

Un domeniu reprezint ansamblul de valori admisibile pentru o component a unei relaii.

Domeniile sunt mulimi de elemente mai mult sau mai puin omogene, din care anumite obiecte semnificative i proprietile lor pot lua valori n timp.

Exemple: 1. Domeniul numelor de orae. 2. Domeniul numelor de persoane. 3. Domeniul notelor care pot fi acordate studenilor; acesta

este specificat prin mulimea: {1,2,3,4,5,6,7,8,9,10}. n cadrul roodelului relaional conceptul de domeniu este

important n realizarea legturilor semantice dintre relaii. Definiie:

Dou domenii sunt declarate compatibile dac ele sunt comparabile din punct de vedere semantic, deci dac mulimile de valori care le definesc nu sunt disjuncte.

Observaie: Conform acestei definiii dou domenii identice sau aflate n relaie de incluziune sunt compatibile.

Orice operaie de cuplare a dou relaii sau, mai general, de comparare a unor valori din dou domenii are sens numai dac cele dou domenii sunt compatibile. De exemplu nu are nici un sens s comparm numele unei cu un nume de ora. Problema compatibilitii domeniilor poate fi pus ntr-un sens restrictiv prin introducerea noiunii de domeniu interpretat. Folosind concept se pot declara incompatibile domenii care au valori comune i conform definiiei de mai sus ar fi compatibile.

Exemplu: Fie dou domenii: 1. Domeniul numerelor de telefon - ntregi de 6 cifre. 2. Domeniul salariilor pentru personalul de conducere - ntregi

de 5 sau 6 cifre. n principiu, nu are nici un sens compararea a dou atribute

definite domeniile de mai sus, dei o asemenea operaie ar putea fi efectuat anumii utilizatori fie voluntar, fie involuntar.

Din acest motiv, unele SGBD-uri, cum este i System R, dispun de faciliti ale LDD prin care proiectantul poate specifica n mod explicit dac are sau nu semnificaie comparaia valorilor din dou domenii date. Prin declararea explicit a compatibilitilor dintre domenii, utilizatorul va fi mpiedicat s efectueze anumite operaii considerate ca fiind fr sens n raport cu semnificaia atribuit datelor.

Conceptul de atribut a fost introdus pentru a explicita rolul jucat de un domeniu n cadrul unei relaii. Este important s se fac distincia ntre un domeniu i atributele derivate dintr-un domeniu.

Definiie: Un atribut este un domeniu cu nume sau mai precis o utilizare sub nume oarecare a unui domeniu.

Din acelai domeniu pot fi derivate mai multe atribute avnd nume diferite, iar ntr-o relaie pot exista mai multe atribute derivate din acelai domeniu. n termenii abstractizrilor, un

domeniu este o generalizare a unor atribut. Atributele avnd acelai domeniu motenesc proprietile domeniului. Reciproc, un domeniu are toate proprietile care sunt comune tuturor atributelor definite pe acesta.

Atributele nu apar izolate ci ca parte a unor obiecte. Atributele si asociate prin agregare pentru a forma obiecte agregate care corespund obiect din lumea real.

2.4.2. Chei S-a fcut mai sus precizarea c n-tuplele unei relaii sunt

unice, ceea ce nseamn c fiecare n-tupl poate fi identificat n mod unic prin valorile atributelor sale. De obicei, pentru identificarea unic a unei n-tuple nu sunt necesare valorile tuturor componentelor sale, ci sunt suficiente doar valorile unui subset al atributelor relaiei corespunztoare.

Definiie: Numim cheie a unei relaii R un subset K al atributelor relaiei R care satisface proprietile:

1. Identificare unic - fiecare tupl a relaiei R este identificat n mod unic de valorile atributelor care compun cheia K.

2. Neredondan - subsetul K este minimal n sensul c eliminarea oricrui atribut din K duce la pierderea proprietii I).

n orice relaie exist cu certitudine o cheie, pentru c setul complet al atributelor oricrei relaii satisface proprietatea 1) (deci n cel mai defavorabil caz cheia este ntreaga n-tupl). n consecin, problema gsirii unei chei se reduce la determinarea setului minimal de atribute care satisface proprietatea 1).

Orice atribut al unei relaii R care face parte din cel puin o cheie se numete atribut prim. Toate celelalte atribute ale relaiei R sunt neprime.

ntr-o relaie pot exista mai multe chei. Pentru fiecare relaie din cadrul unei baze de date se desemneaz dintre acestea, dup anumite criterii, o cheie privilegiat numit cheie primar. Distincia dintr-o o cheie primar i celelalte chei (dac exist), numite i chei candidate, este important numai din punct de vedere operaional, cheia primar avnd un rol important n implementarea strategiilor de cutare i regsire a datelor. Cheia primar este acea dintre cheile unei relaii care este folosit de SGBD n identificarea unic a tuplelor. Statutul de cheie primar al unei chei canditate este stabilit de utilizator i comunicat SGBD-ului prin intermediul LDD.

Asupra cheii primare SGBD-ul impune o serie de restricii: nu sunt admise valori nedefinite pentru atributele unei chei

primare. Orice alt cheie a unei relaii poate avea valori nedefinite pentru unele dintre atributele sale.

nici o valoare a unui atribut dintr-o cheie primar nu poate fi modificat n cadrul operaiilor de actualizare.

La selectarea unei chei primare din mulimea cheilor candidate se va ine seama de necesitatea ca numrul atributelor cheii primare s fie ct mai mic Posibil, deci va fi desemnat drept cheie primar cheia candidat care are definite toate valorile atributelor sale i care are cel mai mic numr de atribute.

2.4.3. Structuri de reprezentare Modelul relaional folosete o singur form de structuare a

datelor i anume relaiile. ntr-o baz de date relaional toate datele sunt reprezentate prin relaii.

Intensiunea unei baze de date relaionale este specificat printr-o schem relaional care const din una sau mai multe scheme de relaie. Deci schema relaional este modelul conceptual al bazei de date relaionale. O schem de relaie cuprinde numele relaiei i atributele acesteia. Schemele de relaie

sunt folosite att pentru reprezentarea tipurilor de entiti ct i pentru reprezent legturilor dintre tipurile de entiti.

Exemplu: O posibil schem relaional pentru baza de date coninnd

info referitoare la faculti este urmtoarea: Facultate (Codf, Nume, Adresa), Personal (Codf, Nume, Funcie, Salar), Profesori (Codf, Nume, Funcie, Disciplin), Sala (Codf, Numr, Adresa, Capacitate), Student (Nume, ncadrare, Sit_colar, An, Sex), Note (Nume_profesor, Numestudent, Nota). Dup cum se poate observa i n exemplele date o schem de

relaie poate fi folosit n mod direct pentru reprezentarea unui tip de entitate. Pentru reprezentarea legturilor dintre tipurile de entiti n modelele relaionale se utilizeaz dou tehnici: - propagarea cheilor dintr-o schem de relaie ntr-alta

Aceast tehnic se poate folosi pentru reprezentarea legturilor de tip funcional (relaii de tip 1:1 sau 1 :N).

S considerm legtura funcional dintre tipurile de entiti Personal i Facultate. Putem s reprezentm aceast legtur adugnd atributul Codf din Facultate la schema de relaie Personal. Procedeul poart numele de propagare a cheii deoare cheia din schema de relaie Facultate a fost plasat n schema de relaie Personal. Apariia lui Codf n Personal este considerat cheie strin a schemei de relaie Facultate n schema de relaie Personal. Reprezentarea conserv n mod inerent natura funcional a legturii de la Personal la Facultate dac se impune condiia ca atributul Codf n Personal s aib cel mult o singur valoare pentru fiecare instaniere a tipului de entitate Personal. Deci n relaia Personal nu pot exista dou tuple care s difere numai prin valorile atributului Codf.

Prin aceeai tehnic sunt reprezentate i legturile funcionale dintre tipurile de entiti Profesori i Facultate, respectiv Sala i Facultate. - crearea unei scheme de relaie separate prin care se reprezint legtura dintre dou tipuri de entiti

Aceast tehnic se poate utiliza pentru a reprezenta orice tip de legtur inclusiv cele M:N.

Considernd legtura de tip M:N dintre tipurile de entiti Profesori i Student aceasta poate fi reprezentat printr-o schem de relaie separat, n cazul nostru Note, care are ca atribute cheile celor dou tipuri de entiti considerate, atributele Nume din schemele de relaie Profesori i Student, rebotezate Nume_profesor i Nume_student n schema de relaie Note. Pe lng cele dou chei mai pot s apar i alte atribute care, ca i n cazul modelului reea, caracterizeaz n mod natural legtura ntre cele dou tipuri de entiti considerate. n cazul nostru un asemenea atribut este Nota.

Aadar ntr-o schem relaional o legtur ntre dou tipuri de entiti poate fi reprezentat prin propagare de chei sau prin scheme de relaie separate. De obicei legturile funcionale se reprezint prin propagarea cheilor, n timp ce legturile de tip M:N se reprezint prin scheme de relaie separate.

Extensiunea unei baze de date relaionale este reprezentat sub form de tabele. Fiecare tabel corespunde unei scheme de relaie din cadrul schemei relaionale. n aceste tabele nu sunt permise duplicatele, iar ordinea liniilor este arbitrar. Un asemenea tabel corespunde unei relaii n sens matematic i este denumit relaie n sensul bazelor de date. O coloan a tabelului corespunde unui atribut al unui tip de entitate i se numete atribut. O linie a tabelului reprezint o instaniere a unui tip de entitate sau a unui tip de legtur i se numete n-tupl sau simplu tupl. ntregul tabel reprezint fie o mulime de entiti de un tip dat, fie mulimea legturilor existente ntre dou sau mai multe mulimi de entiti.

Observaie: De obicei, atributele unei relaii au asociate nume. O relaie

poate fi privit i ca o coresponden ntre o colecie de atribute i mulimile de valori ale acestora. Bazat pe aceast coresponden, n contextul bazelor de date se poate folosi o versiune mai relaxat a conceptului de relaie. Definiia matematic riguroas a relaiilor presupune faptul c tuplele acestora sunt ansambluri ordonate de valori, deci ordinea atributelor este fix. Folosind atribute cu nume ordinea acestora nu mai are importan, esenial fiind corespondena dintre numele atributelor i coloanele de valori corespunztoare. Rezult deci c putem schimba, dup necesiti, ordinea atributelor unei relaii, mpreun cu coloanele de valori corespunztoare, fr ca aceast operaie s conduc la o nou relaie din punctul de vedere al bazelor de date, dei n sens strict matematic acest lucru nu este adevrat.

Exemplu: Extensiunea bazei de date de tip relaional referitoare la

faculti este reprezentat n figura 2.11. Definirea modelului conceptual pentru o baz de date

relaional presupune specificarea fiecrei scheme de relaie din cadrul schemei relaionale. Acesi lucru se realizeaz prin folosirea facilitilor limbajului de definire date (LDD). In cazul SGBD-urilor relaionale, pe lng definirea relaiilor, LDD include i faciliti pentru definirea vederilor i a indecilor, pentru stabilirea de constrngeri asupra datelor, pentru specificarea cheilor primare .a. n majoritatea sistemelor relaionale LDD este integrat n modulul software care implementeaz LMD. Aceasta este o soluie care s-a dovedit a fi util n practic deoarece mai multe funciuni ale LDD (definirea vederilor, definirea unor tipuri de constrngeii .a.) fac apel la facilitile de formulare a interogrilor din LMD. n plus, prin integrarea LMD i LDD va exista un singur modul pentru implementarea acestora, cu o interfa utilizator unitar pentru ambele tipuri de funciuni. Ca exempl ficare vom descrie schema relaional a bazei de date referitoare la faculti folosind LDD din SGBD relaional System R. Acest sistem nu face excepie de la regula prezentat mai sus, avnd LDD implementat n cadrul interfeei SQL carej materializeaz LMD din System R (vezi capitolul 3.4.). Comanda SQL pentru definirea relaiilor este CREATE TABLE i permite specificarea complet i unei scheme de relaie, adic: numele relaiei, numele atributelor i domeniile corespunztoare acestor atribute. Sintaxa complet a acestei comenzi va fi prezentat n paragraful 3.4.6.1.

FACULTATE Cod Nume Adresa 01 Calculatoare Baritiu 02 Electronic Baritiu

PERSONAL Cod Nume Funcie Salar 02 Popa Tehnician 320000 01 Pana Operator 400000

SALA Cod Nr. Adresa Capacitate 01 209 Obsv 16 02 302 Obsv 30 01 40 Barit 120

PROFESOR Cod Nume Funcie Discip 01 Pop Asist Prog 01 Costea SefLucr BD 02 Miron Conf El

NOTE Nume profesor Nume st Nota

Pop Pan 7 Pop Lupu 9 Pop lonescu 10 Costea Lupu 8 Costea lonescu 7 Costea Nea 5 Costea Popescu 10

STUDENT Nume Incadr Sit_c An Sex lonescu Zi B 1 M Lupu Zi N 1 F Pan Zi B 2 M Ilea S N 4 M Popescu S N 4 F

Fig.2.11. Extensiunea bazei de date de tip relaional referitoare la faculti

O posibil descriere a bazei de date considerat ca exemplu este urmtoarea:

CREATE TABLE Facultate (Codf INTEGER(3) NOT NOLL, Nume CHAR(15), Adresa CHAR(20))

CREATE TABLE Personal (Codf INTEGER(3), Nume CHAR(15) NOT NULL, Funcie CHAR(IO), Salar DECIMAL(7))

CREATE TABLE Profesori (Codf INTEGER(3), Nume CHARI15) NOT NULL, Funcie CHAR(IO), Disciplin CHAR(20))

CREATE TABLE Sala (Codf INTEGER(3) , Numr DECIMAL(3) NOT NULL, Adresa CHAR(20), Capacitate INTEGERP))

CREATE TABLE Student (Nume CHAR(15) NOT NULL, ncadrare CHAR(2), Situaiacolar CHAR(l), An DECIMAL(l), Sex CHAR(l))

CREATE TABLE Note (Nume_profesor CHAR(15) NOT NULL, Numestudent CHAR(15) NOT NULL, Nota DECIMAL(2))

Specificaia NOT NULL, din definiia unui atribut, semnific faptul c toate liniile din tabelul corespunztor trebuie s aib o valoare specificat pentru acest atribut De obicei, aceast specificare este necesar pentru acele atribute care particip la identificarea unic a tuplelor unei relaii (de exemplu fac parte dintr-o cheie primar).

2.4.4. Sisteme total relaionale Pentru orice SGBD relaional se pune problema realizrii a

trei principii de integritate: 1. Principiul integritii domeniului - se refer la

posibilitatea SGBD-ului de a verifica din punct de vedere sintatic i semantic orice valoare din baza de date sau operaie efectuat asupra acesteia folosind definiia domeniului din care face parte. Realizarea acestui principiu face imposibil nregistrarea unor valori din afara domeniului corespunztor unui atribut, precum i efectuarea unor operaii (de comparare, aritmetice, etc.) ntre valori din domenii incompatibile.

2. Principiul integritii entitii (sau al relaiei)- se refer la condiiile impuse cheilor primare de a avea valori unice i nenule.

3. Principiul integritii referinei - a fost enunat prima dat de Codd n 1979 sub urmtoarea form:

Definiie: Dac A este o cheie primar monoatribut n relaia R i B este o component a unei chei primare miltiatribut n relaia R2, B fiind definit pe acelai domeniu cu atributul A, arunci mulimea valorilor lui B n R2 trebuie s fie inclus n mulimea valorilor lui A n R,.

n 1981 Date extinde acest principiu i asupra atributelor B care nu fac parte dintr-o cheie, dar sunt definite pe un domeniu primar. Un domeniu poate fi declarat primar dac i numai dac pe acesta exist definit o cheie primar monoatribut.

n particular dac B este o cheie strin n R2 rezultat prin propagarea unei chei primare A din R1 atunci orice valoare a lui B din R2 trebuie s se regseasc printre valorile lui A din R1.

Exemplu: Pentru baza de date considerat mai sus principiul integritii

referinei cere ca orice valoare a atributului Codf din relaiile: Personal, Profesori sau Sala s se regseasc printre valorile atributului Codf din relaia Facultate. n caz contrar am putea avea personal angajat la o facultate care nu exist sau sli aparinnd unor faculti inexistente.

Un SGBD este considerat total relaional dac: asigur cele trei principii de integritate formulate mai sus; furnizeaz utilizatorului un LMD cel puin echivalent ca

putere de expresie cu algebra relaional (care urmeaz a fi prezentat).

2.4.5. Chei strine, integritate referenial

Am vzut n paragrafele precedente c, n cadrul modelului de date relaional, legturile dintre relaiile ce reprezint tipuri de entiti se realizeaz prin mecanismul de propagare a cheilor, ceea ce ne conduce ia conceptul de cheie strin. Tradiional, conceptul de cheie strin a fost legat de cel de cheie primar, majoritatea lucrrilor care prezint modelul relaional considernd cheile strine ca fiind rezultatul propagrii unor chei primare. Acest lucru nu este ns necesar, aa cum rezult din Date (1995) unde sunt aduse argumente n favoarea unei definiii mai relaxate a conceptului de cheie strin:

Definiie: Un subset, FK, al atributelor unei relaii R2, este o cheie strin dac: exist o relaie Rl (nu neaprat distinct) avnd o cheie K; pentru fiecare valoare a Iui FK din relaia R2 exist o valoare identic a cheii K din relaia Rl.

Din definiia de mai sus rezult c o cheie strin poate fi rezultatul propagrii oricrei chei, fie ea cheie primar ori cheie candidat. Valoarea unei chei strine reprezint o referin la tupla a crei cheie are o valoare identic cu cea a cheii strine. Relaia care conine cheia strin poart numele de relaie de referin, iar relaia care conine cheia din care aceasta s-a propagat poart numele de relaie referit. Condiia de integritate referenial cere ca toate valorile unei chei strine s se regseasc printre valorile cheii corespunztoare din relaia referit. Aceast condiie introduce n baza de date nite constrngeri ntre relaii numite constrngeri refereniale.

Constrngerile refereniale pot fi reprezentate prin diagrame refereniale. Acestea sunt grafuri ale cror noduri reprezint relaii, iar arcele reprezint constrngeri refereniale. Sensul arcului este de la relaia de referin ctre relaia referit. n general, structura diagramelor refereniale este de graf oarecare, deci pot exista cicluri numite cicluri refereniale i chiar cicluri de lungine unitar caz n care relaia de referin i cea referit este una i aceeai. O asemenea relaie poart numele de relaie autoreferit.

Exemple: 1. n cazul bazei de date referitoare la faculti pentru

constrngerile refereniale dintre relaiile: FACULTATE, PROFESOR, NOTE i STUDENT avem urmtoarea diagram referenial.

FACULTATE PROFESOR NOTE STUDENT. Observaie: n diagramele refereniale sensul arcelor coincide cu sensul

funcionalitii legturii existente ntre relaiile de la capetele

arcului. Dac n diagrama referenial complet a bazei de date relaionale referitoare la faculti s-ar inversa sensul tuturor arcelor, atunci s-ar obine un graf care este similar cu diagrama structurii de date a bazei de date de tip reea referitoare la faculti.

Fie o baz de date referitoare la activitatea comercial a unor firme, reprezentat prin urmtoarea schem relaional:

Furnizor (CodF, Nume, Ora); Beneficiar (CodB, Nume, Ora); Produs (CodP, Nume, UM); Oferte (CodF, CodP, Pre, Cantitate); Cereri (CodB, CodP, Pre, Cantitate); Tranzacii (CodT,CodF, CodB, CodP, Pre, Cantitate). Atributele CodF, CodB i CodP sunt chei (primare) n relaiile

Furnizor, Beneficiar i, respectiv, Produs. Atributele CodF i CodP din relaia Oferte sunt chei strine i reprezint referine ctre atributele omonime din relaiile Furnizor i Produs. Condiia de integritate referenial, exprim, n acest caz, faptul c nu este posibil existena unei oferte dac nu exist un furnizor care s fac aceast ofert i un produs care s fie oferit de acesta. Similar, atributele CodB i CodP sunt chei strine n relaia Cereri, n relaia Tranzacii avem trei chei strine: CodF, CodB, CodP care sunt referine la relaiile Furnizor, Beneficiar i Produs, ceea ce exprim faptul c pentru orice tranzacie trebuie s existe un furnizor, un beneficiar i un produs care s constituie obiectul tranzaciei.

Referinele puse n

eviden mai sus nu

sunt singurele posibile

pentru schema

relaional luat n

discuie. Existena

unor constrnge

ri refereniale, altele dect cele menionate, depinde de anumite considerente semantice, mai precis de semnificaia atribuit de proiectant unora dintre structurile bazei de date. Astfel dac admitem ipoteza c orice furnizor are o ofert unic pentru un produs dat, atunci perechea de atribute CodF CodP este cheie n relaia Oferte. Mergnd mai departe, putem considera c orice tranzacie care se ncheie are la baz o ofert clar, ceea ce n termenii schemei relaionale considerate nseamn c perechea de atribute CodF CodP este, de asemenea, cheie strin n relaia tranzacii. Aadar pentru a exista o tranzacie a unui furnizor F1 avnd ca obiect un produs P1, nu este suficient numai existena furnizorului F1 i a produsului P1, ci trebuie s existe o ofert a furnizorului F1 pentru produsul P1.

Pe baza unui raionament similar deducem c perechea de atribute CodB CodP din relaia Cereri este cheie n aceast relaie i c perechea CodB CodP din Tranzacii este cheie strin n aceast relaie.

n concluzie, relaia Tranzacii conine 5 chei strine i anume: CodF, CodB, CodP, CodF CodP, respectiv CodB CodP.

Diagrama referenial complet pentru baza de date referitoare la activitatea comercial a unor firme este prezentat n figura 2.12.

Observaie: Exemplul de mai sus pune n eviden natura semantic a

constrngerilor refereniale care nu sunt altceva dect o reflectare n modelul relaional a legturilor existente ntre diferitele tipuri de entiti reprezentate n baza de date.

3. Fie schema de relaie: Descendent (Tat, Fiu), reprezentnd relaia de descenden tat-fiu. Cum orice fiu are

un singur tat, rezult c orice tupl a relaiei Descenden este univoc determinat de valoarea atributului Fiu care este cheie a relaiei. Pe de alt parte orice tat este, la rndul lui, fiul cuiva, deci orice valoare a atributului Tat se regsete printre valorile atributului Fiu, ceea ce nseamn c atributul Tat este cheie strin n relaia Descenden i reprezint o referin la aceeai relaie. Relaia Descenden este autoreferit.

2.4.6. Operaii de adugare, tergere i actualizare

Operaiile de adugare, tergere i actualizare pot afecta integritatea refeienial a unei baze de date. Evident, este necesar ca aceasta s fie satisfcut permanent i s fie meninut. Necesitatea satisfacerii i meninerii condiiilor de integritate referenial are o serie de consecine asupra modului n care trebuie realizate operaiile de adugare, tergere i actualizare. Aceste consecine se manifest att n cazul relaiilor de referin, ct i n cazul relaiilor referite.

Relaii de referin Operaia de adugare - n cazul adugrii unei tuple la o

relaie de referin trebuie s ne asigurm c valorile tuturor atributelor care fac parte dintr-o cheie strin se regsesc printre valorile atributelor pe care le refer n relaia(relaiile) referit(e). Dac aceast condiie nu este satisfcut, atunci operaia de adugare nu poate fi executat.

Exemplu: La relaia Oferte nu se poate aduga o nou ofert dac n

relaiile Furnizor i Produs nu exist furnizorul care face oferta, respectiv produsul pe care acesta l ofer.

Operaia de tergere - n relaiile de referin se pot face tergeri fr nici un fel de restricii din punctul de vedere al condiiilor de integritate referenial.

Operaia de actualizare - poate fi privit ca o operaie de tergere urmat de una de adugare. Regulile de meninere a integritii refereniale rezult, n acest caz, din combinarea celor dou reguli de mai sus.

Relaii referite Operaia de adugare - la relaiile referite se pot face

adugri fr nici un fel de restricii din punctul de vedere al condiiilor de integritate referenial.

Operaia de tergere - la tergerea unei tuple dintr-o relaie referit este posibil ca n relaiile de referin s existe tuple care fac referire la tupla care se terge. n acest caz, pentru a menine integritatea referenial a bazei de date, este posibil una dintre urmtoarele dou opiuni: tergerea restricionat ori tergerea cascadat. tergere restricionat - conform regulii de tergere

restricionat nu se accept tergerea unei tuple din relaia referit dac aceasta este referit de cel puin o tupl dintr-o relaie de referin.

Exemplu: Nu se poate terge un furnizor din relaia Furnizor atta timp

ct el are cel puin o ofert n relaia Oferte. tergere cascadat - tergerea unei tuple dintr-o relaie

referit va fi urmat de tergerea tuturor tuplelor din relaiile de referin care fac referire la tupla tears. Dac tuplele terse din

Furnizor Beneficiar

Tranzacii

Oferte

Produs

Cereri

Fig.2.12. Diagrama referenial pentru baza de date referitoare la activitatea comercial a unor firme

relaia de referin sunt, la rndul lor, referite de alte tuple, atunci tergerea se propag, n cascad, asupra tuplelor care fac referire la cele din urm .a.m.d.

Exemplu: 1. Dac se terge un furnizor din relaia Furnizor, atunci se

vor terge toate ofertele acestuia din relaia Oferte precum i tranzaciile sale din relaia Tranzacii.

Efectul de tergere n cascad poate fi evideniat n cazul relaiei Descenden, unde tergerea unei tuple din relaie poate declana un proces de tergere recursiv a unui numr de alte tuple din relaie. O posibil instaniere a relaiei Descenden este dat n figura 2.13.

Tat Fiu ?

Adam Adam

Adam Cain Abel

Fig.2.13. Posibil instaniere a relaiei Descenden Lsnd la o parte problema originii lui Adam (din punctul de

vedere al SGBD-ului simbolul ? ar putea fi nlocuit printr-o valoare NULL sau prin valoarea Adam) se poate observa cu uurin faptul c n urma tergerii primei tuple din relaie i propagarea n cascad a efectelor acestei tergeri toate tuplele din relaia Descenden vor fi terse.

Operaia de actualizare - actualizarea unei chei dinir-o reia referit se poate face n dou moduri:

- actualizare restricionat - nu se accept modificarea valorii unui atribut din relaia referit atta timp ct exist cel puin tupl n relaiile de referin care face referire la ace valoare.

Exemplu: Nu putem modifica codul unui furnizor din relaia Furniz_.

dac acesta are cel puin o ofert n relaia Oferte sau o tranzacie n relaia Tranzacii.

- actualizare cascadat - modificarea valorii unui atribut dintr-relaie referit va fi urmat de modificarea corespunztoare tuturor tuplelor din relaiile de referin la care face referire valoarea modificat. Este posibil manifestarea unui efect de modificare n cascad n cazurile n care cheile strine modificate intr n componena unei chei (candidate) a relaiei de referin.

Exemplu: Dac n relaia Furnizor se modific codul furnizor FI n FI 1,

atunci n relaia Oferte se vor modifica toate tuplele care pentru atributul CodF au valoarea FI schimbnd aceasta valoare n FI 1. Modificrile din relaia Oferte vor avea, la rndul lor, ca efect modificarea tuplelor corespunztoare din relaia Tranzacii. Aceasta n ipoteza c ele nu au fost nc modificate ca o consecin a referinei directe de la relaia Tranzacii la relaia Furnizor.

Problema integritii refereniale poate fi abordat, la nivelul SGBD-lui, n dou variante: declarativ sau procedural.

Din ce n ce mai multe SGBD-uri relaionale permit definirea n cadrul descrierii bazei de date a cheilor strine care apar n relaii i odat cu acestea a regulilor pentru meninerea integritii refereniale. Elementele specificate la definirea unei chei strine din cadrul unei relaii sunt lista atributelor componente i relaia referit. La acestea se pot aduga, sub form de opiuni, regulile de aplicat, restricionare sau cascadare, n cazul operaiilor de tergere i actualizare. Aceasta constituie varianta declarativ, modul de tratare al constrngerilor refereniale fiind precizat prin descrierea bazei de date.

n varianta procedural apare posibilitatea unei tratri mai nuanate, specializat de la caz la caz, a constrngerilor refereniale, avnd n vedere c opiunile de restricionare i cascadare nu epuizeaz toate modalitile posibile de meninere a integritii refereniale. Acest lucru se realizeaz atand cheilor strine nite proceduri permanente care se activeaz n mod

automat ori de cte ori se execut o operaie de tergere sau modificare asupra cheii strine creia i este ataat procedura (triggeredprocedures).

In final subliniem un aspect care pune n eviden caracterul atomic al operaiilor de tergere i actualizare din cadrul bazelor de date. Fie urmtorul lan de referine:

R3R2R1 unde cheia strin din relaia R3 are ataat opiunea de

tergere restricionat, iar cheia strin din relaia R2 are ataat opiunea de tergere cascadat. S presupunem acum c s-a dat o comand de tergere a unei tuple din relaia Rl. Aceasta ar putea conduce la tergerea unor tuple din relaia R2, ca urmare a opiunii de tergere cascadat asociat cheii strine din aceast relaie. n continuare lucrurile devin mai complicate din cauza opiunii de tergere restricionat asociat cheii strine din relaia R3 care impune restricii relativ la tergerea tuplelor din relaia R2. Dintre tuplele din relaia R2 candidate la tergere ca urmare a operaiei de tergere din relaia Rl, vor fi terse acelea care nu sunt referite de o valoare a cheii strine din relaia R3. Dac, ns printre tuplele candidate la tergere din relaia R2, exist cel puin una care este referit din relaia R3, atunci din cauza opiunii de tergere restricionat asociat cheii strine din relaia R3 aceast tupl nu poate fi tears. Acest lucru conduce ns la euarea comenzii iniiale de tergere a unei tuple din relaia Rl. n consecin tuplele deja terse din relaia R2 i cea din relaia Rl trebuie recuperate i ntreaga operaie va fi revocat.

Din cele de mai sus rezult c operaiile de tergere sau actualizare se fac dup regula "totul sau nimic", adic trebuie s aib, din punct de vedere logic, un caracter atomic, avnd aparena unor operaii elementare, chiar i atunci cnd este vorba de operaii complexe implicnd mai multe relaii distincte.

3. LMD RELAIONALE Partea esenial a oricrui LMD este cea prin care se

formuleaz interogrile adresate bazei de date. De aceea, uneori, prin abuz de limbaj se folosete termenul de limbaj de interogare n loc de LMD. Partea din LMD relaionale care nu este strict legat de formularea interogrilor este destul de restrns i se refer la operaiile de inserie, tergere i modificare a ruplelor.

Limbajele de interogare pentru modelul relaional se mpart n dou grupe I principale care au la origine cele dou formalisme abstracte, numite i limbaje I abstracte, folosite pentru a exprima interogrile adresate bazelor de date j relaionale. Aceste formalisme sunt:

1. Algebra relaional, unde interogrile sunt exprimate prin aplicarea unor operatori specializai asupra relaiilor. Limbajele derivate se numesc limbaje algebrice.

2. Calculul relaional, unde interogrile descriu mulimea ruplelor rezultat prin specificarea unui predicat (condiie) pe care aceste tuple trebuie s-1 satisfac.

Funcie de natura obiectelor primitive cu care se opereaz i care reprezint fie tuple, fie valori din domenii calculul relaional se mparte n: calcului relaional al ruplelor, respectiv calculul relaional al domeniilor. Aadar avem: limbaje bazate pe calculul relaional al ruplelor, respectiv limbaje bazate pe calculul relaional al domeniilor.

Algebra relaional, calculul relaional al tuplelor i calculul relaional al domeniilor sunt limbaje abstracte care nu sunt implementate ca atare n nici un SGBD existent. Ele servesc ca referin pentru evaluarea limbajelor reale existente n diferite SGBD-uri, limbaje care sunt derivate din aceste formalisme abstracte. Cele trei formalisme sunt echivalente din punctul de vedere al puterii de expresie n sensul c pentru orice interogare exprimat n cadrul unuia din formalisme exist interogri care

realizeaz acelai lucru n fiecare din celelalte dou. Aceste formalisme au fost propuse de ctre Codd ca referine care cuprind facilitile minime pe care trebuie s le posede orice limbaj de interogare relaional. Despre un limbaj care posed aceste faciliti minime se spune c este relaional complet. In general, limbajele reale din diversele implementri sunt mai mult dect relaional complete, deoarece cuprind toate facilitile prevzute de aceste formalisme precum i o serie de faciliti suplimentare care vor fi prezentate pentru fiecare caz n parte.

Facilitile suplimentare, necuprinse n formalismele abstracte, de care dispun limbajele reale includ comenzi de inserare, tergere i modificare, dar i o serie de faciliti cum ar fi:

- posibilitatea efecturii de calcule aritmetice; - funcii de tiprire a relaiilor i de atribuire a acestora unor

nume de variabile; - funcii de agregare care efectueaz operaii cum ar fi: media,

suma, minimul sau maximul valorilor unei coloane dintr-o relaie. Ca exemple reprezentative de limbaje reale derivate din

fiecare formalism pot fi amintite urmtoarele: Limbajul ISBL {Information System Base Language),

dezvoltat n cadrul firmei IBM la centrul tiinific al acesteia din Peterlee, Marea Britanie, este un limbaj de interogare bazat pe algebra relaional.

Limbajul QUEL este limbajul de interogare al SGBD relaional INGRES dezvoltat n cadrul universitii Berkeley din California, sub sistemul de operare UNIX i este bazat pe calculul relaional al tuplelor.

Limbajul QBE (Query-by-Example) este un limbaj dezvoltat n cadrul firmei IBM i are la baz calculul relaional al domeniilor. Acest limbaj se distinge de celelalte i ctig tot mai mult teren, ndeosebi n cadrul utilizatorilor neprofesioniti, datorit interfeei sale deosebit de prietenoase care faciliteaz exprimarea celor mai complexe interogri ntr-o manier foarte simpl i uor de neles.

Pe lng cele amintite o meniune special trebuie acordat limbajelor SQUARE i SEQUEL (SQL) care sunt limbaje intermediare ntre algebra relaional i calculul relaional. Aceste limbaje au fost dezvoltate la secia din San Jose a firmei IBM ca limbaje de interogare pentru SGBD relaional System R. SQL este de fapt urmaul perfecionat al limbajului SQUARE i este recunoscut la ora actual ca un cvasistandard al limbajelor de interogare relaionale fiind prevzut cel puin ca opiune sau limbaj alternativ n marea majoritate a SGBD-urilor relaionale.

3.1. Algebra relaional Algebra relaional este unul din cele trei formalisme

abstracte propuse de Codd pentru interogarea bazelor de date relaionale. Are la baz un set de operatori care se folosesc ca primitive pentru construirea interogrilor. Algebra relaional este considerat un limbaj (abstract) de tip procedural ntruct interogrile exprimate cu ajutorul ei nu sunt altceva dect secvene de operatori prin care se specific n mod explicit modul de obinere al relaiei rezul corespunztoare fiecrei interogri.

3.1.1. Operatorii algebrei relaionale Algebra relaional este o colecie de operatori, unari sau

binari acioneaz asupra relaiilor. Rezultatele care se obin n urma aplicrii operatorilc relaionali asupra relaiilor operand sunt tot relaii ceea ce permite asocierea imbricarea acestor operatori pentru a forma interogri complexe.

Aceti operatori se pot mpri n dou grupe: operaii pe mulimi, care acion