1.

CONCEPTE FUNDAMENTALE
1.1. Utilitatea i avantajele bazelor de

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

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.

Independena logic a datelor

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.

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

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.

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. ntradevr, 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, ntrunui 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. 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. 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

Facilitile de descriere a datelor

Facilitile de manipulare a datelor

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

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.

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 propriuzis. 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 Folosind generalizarea mpreun cu agregarea se poate generalizare. exprima att clasificarea obiectelor i tipurilor, ct i structura lor.
Fig.2.1. Ierarhie de generalizare Persoana Fig.2.3. Ierarhie de generalizare i agregare Student

Persoana
Student

Angajat Angajat Nume Adresa

Pers. Adm.

Cadru didactic

Salar

Pregtire

Localitate

Strada

Numr

An studiu

Secie

Secretar

Tehnician

Contabil

Preparator

Asistent

Lector

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
Fig.2.2. Ierarhie de agregare Persoana

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

Nume

Adresa

Data naterii

Localitate

Strada

Numr

Zi

Lun

An

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.

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

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 1:1 din M1 i corespunde o singur entitate din M2 i reciproc (relaie de tip so-soie). M1 M2 - 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). 1:N - relaie M:N, cnd unei entiti din M1 i corespund una sau mai multe entiti din M2 i reciproc M1 M2 (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 M:N de tip M:N, deoarece un profesor pred la mai muli studeni, iar M1 M2 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 SGBDurilor 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 ntuplelor 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 ntuplelor 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

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.

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

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 Pop Lupu Pop lonescu Costea Lupu Costea lonescu Costea Nea Costea Popescu STUDENT Nume Incadr Sit_c An

faculti

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 Sex aparinnd unor faculti inexistente. lonescu Zi B 1 M Un SGBD este considerat total relaional dac: Lupu Zi N 1 F asigur cele trei principii de integritate formulate mai sus; Pan Zi B 2 M furnizeaz utilizatorului un LMD cel puin echivalent ca Ilea S N 4 M putere de expresie cu algebra relaional (care urmeaz a fi Popescu S N 4 F prezentat ). Fig.2.11. Extensiunea bazei de date de tip relaional referitoare la

7 9 10 8 7 5 10

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:

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

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

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.

arcului. Dac n diagrama referenial complet a bazei de date Observaie: relaionale referitoare la faculti s-ar inversa sensul tuturor Exemplul de mai sus pune n eviden natura semantic a arcelor, atunci s-ar obine un graf care este similar cu diagrama constrngerilor refereniale care nu sunt altceva dect o reflectare structurii de date a bazei de date de tip reea referitoare la n modelul relaional a legturilor existente ntre diferitele tipuri faculti. de entiti reprezentate n baza de date. 3. Fie schema de relaie: Fie o baz de date referitoare la activitatea comercial a unor Descendent (Tat, Fiu), firme, reprezentat prin urmtoarea schem relaional: reprezentnd relaia de descenden tat-fiu. Cum orice fiu are Furnizor (CodF, Nume, Ora); un singur tat, rezult c orice tupl a relaiei Descenden este Beneficiar (CodB, Nume, Ora); univoc determinat de valoarea atributului Fiu care este cheie a Produs (CodP, Nume, UM); relaiei. Pe de alt parte orice tat este, la rndul lui, fiul cuiva, Oferte (CodF, CodP, Pre, Cantitate); deci orice valoare a atributului Tat se regsete printre valorile Cereri (CodB, CodP, Pre, Cantitate); atributului Fiu, ceea ce nseamn c atributul Tat este cheie Tranzacii (CodT,CodF, CodB, CodP, Pre, Cantitate). strin n relaia Descenden i reprezint o referin la aceeai Atributele CodF, CodB i CodP sunt chei (primare) n relaiile relaie. Relaia Descenden este autoreferit. Furnizor, Beneficiar i, respectiv, Produs. Atributele CodF i CodP din relaia Oferte sunt chei strine i reprezint referine 2.4.6. Operaii de adugare, tergere i ctre atributele omonime din relaiile Furnizor i Produs. actualizare Condiia de integritate referenial, exprim, n acest caz, faptul Operaiile de adugare, tergere i actualizare pot afecta 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. integritatea refeienial a unei baze de date. Evident, este necesar Similar, atributele CodB i CodP sunt chei strine n relaia ca aceasta s fie satisfcut permanent i s fie meninut. Cereri, n relaia Tranzacii avem trei chei strine: CodF, CodB, Necesitatea satisfacerii i meninerii condiiilor de integritate CodP care sunt referine la relaiile Furnizor, Beneficiar i referenial are o serie de consecine asupra modului n care Produs, ceea ce exprim faptul c pentru orice tranzacie trebuie trebuie realizate operaiile de adugare, tergere i actualizare. s existe un furnizor, un beneficiar i un produs care s constituie Aceste consecine se manifest att n cazul relaiilor de referin, ct i n cazul relaiilor referite. obiectul tranzaciei. Relaii de referin Referin Furnizor Beneficiar ele puse n Operaia de adugare - n cazul adugrii unei tuple la o eviden relaie de referin trebuie s ne asigurm c valorile tuturor mai sus nu atributelor care fac parte dintr-o cheie strin se regsesc printre sunt valorile atributelor pe care le refer n relaia(relaiile) referit(e). Tranzacii singurele Dac aceast condiie nu este satisfcut, atunci operaia de posibile adugare nu poate fi executat. pentru Exemplu: schema La relaia Oferte nu se poate aduga o nou ofert dac n Oferte Cereri relaional relaiile Furnizor i Produs nu exist furnizorul care face oferta, luat n respectiv produsul pe care acesta l ofer. discu ie. Operaia de tergere - n relaiile de referin se pot face Produs Existena tergeri fr nici un fel de restricii din punctul de vedere al unor condiiilor de integritate referenial. Fig.2.12. Diagrama referenial pentru baza de date constrnge Operaia de actualizare - poate fi privit ca o operaie de referitoare la activitatea comercial a unor firme ri tergere urmat de una de adugare. Regulile de meninere a refereniale, altele dect cele menionate, depinde de anumite integritii refereniale rezult, n acest caz, din combinarea celor considerente semantice, mai precis de semnificaia atribuit de dou reguli de mai sus. proiectant unora dintre structurile bazei de date. Astfel dac Relaii referite admitem ipoteza c orice furnizor are o ofert unic pentru un Operaia de adugare - la relaiile referite se pot face produs dat, atunci perechea de atribute CodF CodP este cheie n adugri fr nici un fel de restricii din punctul de vedere al relaia Oferte. Mergnd mai departe, putem considera c orice condiiilor de integritate referenial. tranzacie care se ncheie are la baz o ofert clar, ceea ce n Operaia de tergere - la tergerea unei tuple dintr-o relaie termenii schemei relaionale considerate nseamn c perechea de referit este posibil ca n relaiile de referin s existe tuple care atribute CodF CodP este, de asemenea, cheie strin n relaia fac referire la tupla care se terge. n acest caz, pentru a menine tranzacii. Aadar pentru a exista o tranzacie a unui furnizor F1 integritatea referenial a bazei de date, este posibil una dintre avnd ca obiect un produs P1, nu este suficient numai existena urmtoarele dou opiuni: tergerea restricionat ori tergerea furnizorului F1 i a produsului P1, ci trebuie s existe o ofert a cascadat. furnizorului F1 pentru produsul P1. tergere restricionat - conform regulii de tergere Pe baza unui raionament similar deducem c perechea de restricionat nu se accept tergerea unei tuple din relaia referit atribute CodB CodP din relaia Cereri este cheie n aceast relaie dac aceasta este referit de cel puin o tupl dintr-o relaie de i c perechea CodB CodP din Tranzacii este cheie strin n referin. aceast relaie. Exemplu: n concluzie, relaia Tranzacii conine 5 chei strine i Nu se poate terge un furnizor din relaia Furnizor atta timp anume: CodF, CodB, CodP, CodF CodP, respectiv CodB CodP. ct el are cel puin o ofert n relaia Oferte. Diagrama referenial complet pentru baza de date referitoare tergere cascadat - tergerea unei tuple dintr-o relaie la activitatea comercial a unor firme este prezentat n figura referit va fi urmat de tergerea tuturor tuplelor din relaiile de 2.12. referin care fac referire la tupla tears. Dac tuplele terse din

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 Cain Adam 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: R3 R2 R1 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.

al elementelor. Operatorii din aceast grup sunt o adaptare la relaii a operaiilor uzuale pe mulimi din matematic. operatori relaionali speciali, care iau n considerare caracterul tupl al elemetelor operanzilor lor. Pentru operaiile de reuniune, intersecie i diferen, cele dou relz operand trebuie s fie compatibile la reuniune, ceea ce nsemn c trebuie s de acelai grad, iar atributele corespondente trebuie s fie derivate din acela domeniu. Reuniunea a dou relaii A i B, notat AUB, este o relaie R care conine toate tuplele cu proprietatea c aparin relaiei A sau relaiei B. Intersecia a dou relaii A i B, notat AB, este o relaie R care conine toate tuplele cu proprietatea c aparin att relaiei A, ct i relaiei B. Diferena a dou relaii A i B, notat A-B, este o relaie R care conine toate tuplele cu proprietatea c aparin relaiei A i nu aparin relaiei B. Produsul cartezian a dou relaii, notat AXB, A fiind de gradul m i B de gradul n, este o relaie R de gradul m+n care conine toate tuplele obinute prin concatenarea fiecrei tuple din relaia A cu fiecare tupl a relaiei B. Fiind date dou tuple a(al,a2,...,am) i b(bm+1,bm+2,.-,bm+n), rezultatul concatenrii tuplelor a i b, n aceast ordine, este tupla r(a1, a2,..., am, bm+1, bm+n). Operatorii relaionali speciali sunt operatori unari (proiecia i selecia): operatori binari (cuplarea - join - i diviziunea). Selecia printr-un predicat P a unei relaii A, notat P(A), este o relaie care conine toate tuplele din relaia A cu proprietatea c satisfac predicatul P. Predicatul P este o formul ce poate conine: - operanzi care sunt nume de atribute sau constante; - operatori de comparaie: =, <, >, #, <=, >=; - operatori logici: &, |,!. Exemple: l. Bursieri=Situaia_colar=B(Student) este o selecie din relaia Student care conine studenii bursieri (figura 3.1.): Bursieri ncadr. Sit.c. Sex Nume_s tudent Ionescu Zi 1 B Pan Zi 2 B
Fig. 3.l. Relaia Bursieri

Operaii pe mulimi

Operatori relaionali speciali

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 acioneaz asupra relaiilor vzute ca mulimi de elemente fr a lua n considerare caracterul de tupl

2. Studenii bursieri din anul I de studiu pot fi obinui prin selecia: Bursieri1=Situaia_colar=B & An=1(Student), sau, folosind o condiie mai simpl, din relaia Bursieri, dac aceasta exist deja: Bursieri1 ==An=1(Bursieri). Proiecia pe atributele Ai,A2,...,An a unei relaii B de grad m>n i care cuprinde atributele A1,A2,...,An, notat A1,.,An(B), este o relaie R de grad n obinut din relaia B astfel: se elimin din relaia B atributele care nu sunt specificate n lista de proiecie, astfel nct rmn doar coloanele corespunztoare atributelor A1,A2,...An; se reordoneaz atributele rmase n ordinea specificat n lista de proiecie: A1,A2,...An; se elimin tuplele duplicat. Aadar proiecia unei relaii const dintr-o selecie vertical a acesteia (se selecteaz coloanele corespunztoare atributelor specificate) cu eliminarea tuplelor duplicat care ar putea apare n urma seleciei verticale. Ca efect secundar apare reordonarea atributelor rmase n ordinea specificat de lista acestora. Exemplu:

Putem obine notele date de fiecare cadru didactic din relaia Note printr-o proiecie a acesteia dup atributele Nume_profesor i Nota (figura 3.2.): Note_profesor=Nume_profesor, Nota(Note)
Nume_profesor a Pop Pop Pop Costea Costea Costea 7 9 10 8 7 5 Not

Nume Pop Pop Pop Costea Costea Costea Costea

Note_Disciplin Funcie Disciplina Nume_prof Nume stud. as programare Pop Pan as as lect lect lect lect progranare programare baze date baze date baze date baze date Pop Pop Costea Costea Costea Costea Lupu Ionescu Lupu Ionescu Ilea Popescu

Nota 7 9 10 8 7 5 8

2.Prin cuplarea natural a celor dou relaii Profesor i Note dup atributele indicate mai sus, rezult relaia Note_Disciplin_Natural n care coloana redondant Observaie: Din relaia Note s-au selectat coloanele atributelor Corespunztoare atributului Nume_profesor nu mai apare (figura Nume_profesor i Nota (s-a eliminat coloana Nume Student), 3.4.). dup care s-a eliminat tupla duplicat "Costea - 8". Nu s-au Note Disciplin Natural = Profesor >< Note Note Disciplin_Natural reordonat atributele rmase. Nume Func ie Disciplina Nume stud. Nota Cuplarea (JOIN) Fie un operator aritmetic de comparaie: =, #, <, > .a.m.d., Pop as programare Pan 7 fie X un atribut al relaiei A i Y un atribut al relaiei B, X i Y Pop as progranare Lupu 9 fiind atribute definite pe domenii compatibile. Pop as programare Ionescu 10 Numim cuplare a relaiilor A i B dup atributele X i Y, Costea lect baze date Lupu 8 A >< B lect Costea baze date Ionescu 7 notat o relaie R care conine acele tuple ale lect Costea baze date Ilea 5 XY lect Costea baze date Popescu 8 produsului cartezian AXB care au proprietatea c valorile x i y,
Fig-3.2. Proiecia relaiei Note

Fig.3.3. Cuplarea relaiilor Profesori i Note

corespunztoare atributelor X i respectiv Y sunt n relaia xy. Operatorul de cuplare este folosit pentru a combina tuple din dou relaii diferite pe baza unor informaii comune acestora. n particular, dac operatorul este chiar =, atunci operaia se numete echicuplare (equijoin). Cuplarea natural a dou relaii A i B, notat A >< B , avnd atributele X, respectiv Y definite pe domenii compatibile, se obine astfel: se calculeaz AXB; se selecteaz acele tuple din AXB pentru care valoarea corespunztoare atributului X este egal cu valoarea corespunztoare atributului Y; se efectueaz o proiecie a rezultatului obinut mai sus pentru a elimina coloana corespunztoare atributului Y. Este uor de observat c n cazul operaiei de echicuplare relaia rezultat conine dou coloane cu valori identice (cele dup care s-a fcut cuplarea); n cazul cuplrii naturale este eliminat coloana redondant corespunztoare atributului de cuplare a celei de-a doua relaii. Aadar cuplarea natural este de fapt o echicuplare urmat de o proiecie. Observaie: Dup cum se poate deduce i din definiia dat, operatorul de cuplare este echivalentul aplicrii a doi operatori definii anterior: produsul cartezian urmat de o selecie. Acest fapt este exprimat i prin urmtoarea egalitate:

Din relaia Student putem obine lista tuturor cuplurilor maritale posibile prin cuplarea relaiei Student cu ea nsi (de fapt ale celor dou copii Studeni i Student2 ale acesteia) folosind condiia > aplicat atributelor Sex, rezultnd o relaie pe care o denumim Student_Student.(figura 3.5.) Student_Student = Studeni >< Student2
Sex1> Sex 2

Fi.3.4. Cuplarea natural a relaiilor Profesori i Note

Student_Student
Nume1 Ionescu Ionescu Pan Pan Ilea Ilea I1 Zi zi Zi zt s s S1 An1 Sex1 B B B B N N 1 1 2 2 4 4 H M M M M M Nume2 Lupu Popescu Lupu Popescu Lupu Popescu I2 Zi S Zi S Zi S S2 An2 Sex2 N N N N N N 1 4 1 4 1 4 F F F F F F

Fig.3.5. Cuplarea relaiilor Studeni i Student2 - copii identice ale relaiei Student

A >< B = XY ( A B )
XY

Exemple: 1. Cuplnd prin echicuplare relaiile Profesor i Note dup atributele Nume i respectiv Nume_profesor, definite pe domeniul comun al numelor de persoane, obinem relaia Note >< Disciplina care ne arat nu numai de la cine ce note au obinut studenii, dar i disciplina la care au obinut notele respective. Se observ redondana atributului Nume_profesor. (figura 3.3.) Note Disciplin = Profesor >< Note
Nume = Nume _ profesor

Not: Ce relaie s.ar obine dac pentru cuplarea relaiilor Studeni i Student2 s-ar folosi condiia #? Diviziunea relaiei A de grad m, prin relaia B de grad n, notat AB, este o relaie R de grad m-n format din mulimea tuplelor r cu proprietatea c pentru orice tupl b din B exist o tupl a n A egal cu rezultatul concatenrii tuplelor r i b. Mulimea atributelor relaiei B trebuie s fie o submulime a mulimii atributelor relaiei A. Relaia R conine doar acele atribute din relaia A care nu apar n relaia B. O tupl din relaia A este reinut n urma operaiei de diviziune numai dac este legat de fiecare tupl din relaia B printr-o condiie predefinit. Din definiia de mai sus se deduce c relaia obinut prin produsul cartezian al relaiilor R i B este inclus n relaia A. Notnd prin Rest mulimea tuplelor din relaia A care nu apar n produsul cartezian al relaiilor B i R putem scrie urmtoarea egalitate asemntoare cu teorema mpriri din aritmetic: A=BXRRest. Exemple:

1. Diviziunea relaiei Student_Student prin relaia Studente consumului de memorie. Acest lucru necesit o bun cunoatere a definit prin tabelul din figura 3.6. este relaia: operatorilor algebrei relaionale i o oarecare experien practic. Studeni=Student_Student Studente La ora actual exist sisteme care realizeaz n mod automat optimizarea secvenelor de operatori. dat n tabelul din figura 3.7. S rezolvm urmtoarele interogri: Studente 1. "Numele profesorilor cu care studiaz studentul Lupu?" Sex Nume student ncadr. Sit. se. An Rspunsul poate fi obinut din relaia Note printr-o selecie F Lupu Zi N 1 urmat de o proiecie. Aplicarea succesiunii celor doi operatori F Popescu S N 4 poate fi exprimat fie prin folosirea unei variabile temporare T Fig.3.6. Relaia Studente creia i se atribuie rezultatul aplicrii primului operator: Studeni T = Nume_student=Lupu(Note) Nume student ncadr. Sit. c. An Sex R = Nume_profesor, Funcia(T) Ionescu Zi B 1 M fie mai concentrat prin imbricarea celor doi operatori: Pan Zi B 2 M = R Nume_profesor, Funcia(Nume_student=Lupu(Note)) Ilea S N 4 M Rezultatul este reprezentat prin tabelul din figura 3.9. Fig.3.7. Relaia Studeni Analog diviziunea relaiei Student_Student prin relaia Nume Pop Studeni va da ca rezultat relaia Studente. Observaie: Costea n cazul nostru particular relaia Student_Student este chiar produsul cartezian al relaiilor Studeni i Studente. Fig.3.9. Relaia rezultat pentru interogarea 1 Numele studenilor care au primit note de la toi profesorii 2. "Numele profesorilor care au cel puin un student bursier?" facultii de calculatoare se obine din diviziunea proieciei Pentru rezolvarea acestei interogri este necesar efectuarea relaiei Note pe atributele Nume_profesor i Numestudent, unei operaii de cuplare dintre relaiile Student i Note. ntruct reprezentat prin tabelul Profesori_Studeni (figura 3.8.), cu operaia de cuplare este mare consumatoare de timp de calcul i relaia Profesori_CalcuIatoare, coninnd numele profesorilor memorie este de dorit ca relaiile care se cupleaz s fie ct mai de la facultatea de calculatoare. Rezultatul operaiei de diviziune mici (ca numr de atribute i de tuple). Observnd c din relaia este reprezentat prin relaia: Student semnificativ pentru interogare este doar atributul Nume Absoveni_CalcuIatoare=Profesori_StudeniProfesori_Calculatoare. (student) din acele tuple pentru care Situaia colar = "B", vom n figura 3.8. este reprezentat i tabelul corespunztor relaiei aplica nti o selecie dup aceast condiie, urmat de o proiecie Rest din acest exemplu. pe atributul Nume. Profesori_Studeni Din acelai motiv vom folosi o proiecie a relaiei Note pentru Nume_profesor Nume_student a elimina atributul Nota. Pop Pan Pop Lupu Secvena de operaii este urmtoarea: Pop Ionescu T1 =Situaia_colar=B(Student) Costea Lupu T2 = Nume(Tl) Costea Ionescu Costea Ilea T3 = Nume profesor, Nume student(Note) Costea Popescu T4 = T3 >< T2, (cuplare natural dup Nume student) R=Nume_profesor(T4) Profesori Calculatoare n tabelele din figura 3.10. sunt prezentate, pentru o mai bun Nume nelegere, relaiile temporare obinute ca rezultate intermediare Pop dup aplicarea fiecrui operator din secven. Costea
T1
Absolveni_Calculatoare

Nume Lupu Ionescu

Rest

Nume Ionescu Pana

Incadr Zi Zi

Sit. se. B B

An 1 2

T2
Nume Ionescu

Nume_profesor Pop Costea Costea

Nume_student Pan Ilea Popescu

relaiei Profesori_Studcni prin relaia

Pan

T3

Nume_profesor Nume_student Pop Pop Pop Costea Costea Costea Costea

T4

Fig.3.8. Diviziunea Profesori_Calculatoarc

3.1.2. Formularea interogrilor n algebra relaional

Prezentm cteva exemple ilustrative pentru modul n care se pot exprima prin algebra relaional diverse interogri relative la o baz de date. Trebuie menionat faptul c, n general, soluia nu este unic. Orice interogare poate fi exprimat prin mai multe secvene echivalente posibile i este de dorit s se aleag secvena optim din punctul de vedere al volumului de calcul i al

Pan Lupu Ionescu Lupu Ionescu Ilea Popescu

Nume_profesor Nume_s tudent Pop Pan Pop Ionescu Costea Ionescu

n acest caz, rezultatul dorit se obine ca diviziunea proieciei relaiei Note pe atributele Nume_profesor i Nume_student printr-o relaie care conine numai numele studenilor bursieri. Secvena de rezolvare este urmtoarea: 3. "Numele studenilor bursieri care au luat note mai mici de T1 =Situaia_colar=B(Student) 8?" T2 = Nume(Tl) Este necesar cuplarea relaiilor Student i Note. Secvena T4 = Nume_profesor,Nume_student(Note) aplicrii operatorilor este urmtoarea: R = T3 T2 T1 =Situaia_colar=B(Student)
Nume_profesor Pop Costea

T2 = Nume_student(Tl) T3 = Nota<8(Note) T4 = Nume_student(T3) R = T2 >< T4, (cuplare natural dup Nume_student) Relaia T2 conine numele studenilor bursieri, iar relaia T4 conine numele studenilor care au luat note mai mici de 8. 4. "Numele studenilor de la zi care au luat note mai mici de 8 i disciplina la care au luat aceste note?" n aceast interogare intervin atribute din toate cele 3 relaii: Student, Profesori i Note; deci vor exista dou operaii de cuplare a relaiilor. T1 =ncadrare=Zi(Student) T2 = Nume_student(Tl) T3 = Nota<8(Note) T4 = Nume_profesor, Nume_student(T3) T5 = T2 >< T4, (cuplare natural dup Nume_student) T6 = Nume_profesor, Disciplina(Profesori) T7 = T5 >< T6, (cuplare natural dup Nume_profesor) R = Nume_student, Disciplina(T7) Relaia T5 conine numele studenilor i a profesorilor lor pentru studenii de la zi care au luat o not mai mic de 8. 5. "Numele studenilor i notele celor care au obinut o not mai mare la programare dect studentul Lupu?" Strategia de rezolvare este urmtoarea: Se determin studenii care au luat note la disciplina de programare. Acesta presupune cuplarea relaiei Profesori, restricionat la coloana numelor profesorilor de programare, cu relaia Note. Din relaia obinut mai sus se selecteaz tupla corespunztoare studentului Lupu. ntre aceast din urm relaie i cea de mai sus face o cuplare cu condiia > asupra atributelor reprezentnd notele. T1 =Disciplina=Programare(Profesori) T2 = Nume (Tl) T3 = Note >< T2(cuplare natural dup Nume_profesor) T4 = = Nume_student =Lupu(T3) T5 = T3 >< T4,

3.1.3. Limitri ale algebrei relaionale

Dup cum s-a menionat anterior, algebra relaional i formalismele echivalente cu aceasta sunt relaional complete. Puterea de expresie a limbajelor relaional complete este mult mai limitat dect cea a limbajelor computaional complete cum sunt PASCAL sau C care sunt echivalente cu maina Turing. Limbajele relaionale nu permit manipularea structurilor recursive i nici formularea de interogri cu caracter recursiv. Limita la care eueaz limbajele relaionale este dat de clasa problemelor care presupun calcularea nchiderii tranzitive a unei relaii binare. Exemplul clasic este problema legturilor aeriene ntre un grup de orae: Fiind dat o relaie binar care conine toate legturile aeriene directe pentru o mulime de orae, se cere s se determine toate legturile aeriene directe sau indirecte posibile ntre aceste orae?
Direct Sursa Destinaie Bucureti Berlin Bucureti Amsterdam Bucureti Roma Paris New-York Roma Madrid Berlin Paris Moscova Bucureti Fig.3.ll. Legturi aeriene directe

Pentru relaia Direct, dat prin tabelul din figura 3.11., ne punem ntrebarea dac putem ajunge cu avionul (eventual fcnd escale) de la Bucureti la Madrid? Consultnd tabelul se observ c nu exist legtur direct pentru acest traseu, dar exist o legtur indirect cu escal la Roma. Formal acest rezultat se poate obine prin cuplarea relaiei Direct cu ea nsi, deci calculnd relaia: Trasee2= Direct >< Direct. Relaia Trasee2 conine toate traseele aeriene formate din dou legturi directe. Perechea Bucureti-Madrid va apare n aceast relaie, ceea ce constituie rspunsul afirmativ la ntrebarea Nota 3> Nota 4 pe care ne-am pus-o mai sus. Pentru alte interogri posibile R = Nume_student, Nota3(T5) calcularea relaiei Trasee2 nu este nicidecum suficient, astfel 6. "Numele studenilor care au obinut la programare note pentru a determina dac exist un traseu aerian de la Bucureti la NewYork, care poate fi realizat prin 3 legturi directe, va trebui mai mari dect la baze de date?" s calculm relaia: O posibil secven pentru rezolvarea acestei interogri este: Trasee3=Trasee2 >< Direct, T1 =Disciplina=Programare(Profesori) iar pentru traseele care pornesc din oraul Moscova va trebui s T2 = Nume (Tl) T3 = Note >< T2(cuplare natural dup Nume_profesor) calculm relaiile Trasee4, Trasee5 .a.m.d. n general, pentru o relaie Direct dat nu se poate preciza T4 = Nume_student,Nota(T3) numrul de operaii de cuplare necesare pentru a stabili toate T5 = Disciplina=Baze Date(Profesori) traseele aeriene posibile (acest numr este dat de traseul cu cele T6 = Nume (T5) mai multe escale), deci nu se poate forma o expresie algebric T7 = Note >< T6(cuplare natural dup Nume_profesor) care s garanteze rezolvarea problemei formulate. Mulimea T8 = Nume_student,Nota(T7) traseelor posibile este dat de nchiderea tranzitiv a relaiei T9 = T4 >< T8(cuplare natural dup Nume_student) Direct, calculul creia presupune repetarea recursiv a operaiei T10 = Nota4>Nota8(T9) de cuplare de un numr de ori care este necunoscut. R = Nume_student(T10) 7 "Numele profesorilor care predau la toi studenii bursieri? "

3.2.

Limbajul SQL

Limbajul SQL (cunoscut iniial i sub numele SEQUEL) este limbajul de interogare al SGBD System R dezvoltat n cadrul laboratorului de cercetare din San Jose al firmei IBM. SQL a evoluat din predecesorul su numit SQUARE care a constituit prima etap n dezvoltarea unui limbaj de interogare pentru System R. Conceptele de baz ale celor dou limbaje sunt esen aceleai, deosebirea principal dintre ele fiind aceea c limbajul SQUARE are o sintax bazat n mare msur pe notaii matematice, n timp ce SQL are o sintax mai apropiat de limba englez aa cum arat i denumirea limbajului (SQL sau SEQUEL - Structured English Query Language). Aceast sintax este mai adecvat programrii pe calculator i totodat mai uor de asimilat pentru utilizatori. La ora actual SQL este una din cele mai rspndite interfee pentru SGBD-urile relaionale. n afar de System R limbajul SQL este disponibil i sub alte SGBD-uri relaionale cum ar fi SGBD ORACLE (pentru sisteme mari, dar i calculatoare personal profesionale) sau chiar DBase (ntr-o variant simplificat ncepnd cu versiunea IV). Din anul 1986 SQL a devenit standard ANSI pentru limbajele de interogare ale bazelor de date relaionale. Ulterior ANSI a mai publicat dou standarde n 1989 i 1992. Standardul n uz la ora actual este cel din anul 1992 cunoscut sub numele SQL'92 sau SQL2. n ultimii ani comitetele ANSI i ISO pentru standardizarea limbajului SQL adaug acestuia noi i noi faciliti pentru a adapta limbajul la cerinele aplicaiilor moderne din domeniul bazelor de date. Aceste faciliti se preconizeaz a face parte din noul standard SQL referit sub numele SQL3. Iniial, apariia standardului SQL3 a fost proiectat pentru anul 1995, dar obiectivele ambiioase propuse pentru acest standard au creat o serie de probleme dificile ceea ce a condus Ia amnarea apariiei noului standard pentru a dat care nu este nici pn n prezent cunoscut cu certitudine. Noul standard SQL3 preconizeaz o serie de extensii fat de standardul actual SQL2 n condiiile meninerii compatibilitii totale cu acesta: 1. Faciliti orientate obiect se refer la: posibilitatea de definire la nivel utilizator a tipurilor de date abstracte, incluznd metode, identitatea obiectelor, subtipuri i motenire, polimorfism .a. 2. Structuri de control specifice limbajelor complet computaionale: IF, FOR, WHILE etc, ceea ce va transforma SQL ntr-un limbaj de sine stttor a crui putere de expresie nu mai este limitat la nivelul limbajelor relaionale. 3. Faciliti pentru exprimarea prelucrrilor cu caracter recursiv. 4. Faciliti de comunicare n reea. 5. Faciliti de prelucrare distribuit, inclusiv pentru tehnologia client-server. Acesta presupune mecanisme pentru crearea, memorarea i execuia procedurilor la nivelul server-elor de date (stored procedures). 6. Faciliti multi-media care sunt nglobate n modulul specializat Multi-Media SQL (MMSQL). 7. Faciliti pentru tratarea timpului n bazele de date, faciliti care fac parte din componenta Temporal SQL (TSQL).

3.2.1. Sintaxa construciilor SELECT

SQL este un limbaj intermediar avnd unele caracteristici provenite din algebra relaional i altele care i au originea n calculul relaional al tuplelor. Operaia fundamental n SQL este maparea, reprezentat din punct de vedere sintactic printr-o construcie SELECT-FROMWHERE (pe scurt construcie SELECT). Aceast construcie

corespunde unei succesiuni de operatori algebrici de forma selecie-proiecie-cuplare foarte frecvent n algebra relaional. Clauza SELECT realizeaz operaia de proiecie i este urmat de lista atributelor care se rein n relaia rezultat. Ea nu trebuie confundat cu selecia din algebra relaional aa cum am putea fi tentai n mod eronat ca urmare a asemnrii ntre denumiri. De remarcat c proiecia SQL difer de operatorul de proiecie definit n cadrul algebrei relaionale prin faptul c nu elimin n mod automat tuplele duplicat. Eliminarea tuplelor duplicat, atunci cnd este necesar, trebuie solicitat n mod explicit de ctre utilizator prin folosirea operatorului DISTINCT. n SQL, ca de altfel i n alte limbaje de interogare, s-a adoptat aceast strategie din motive de eficien, operaia de eliminare a duplicatelor fiind relativ costisitoare. Operaia de cuplare poate fi realizat cu ajutorul clauzei FROM, atunci cnd ea este urmat de o list format din cel puin dou nume de relaie, mpreun cu condiia de cuplare formulat n cadrul predicatului din clauza WHERE. Selecia este realizat prin cea de-a treia clauz, WHERE, care de cele mai multe ori este urmat de un predicat (calificator) referitor la atributele relaiei (relaiilor) din clauza FROM. Clauza WHERE este ns mai complex dect operaia de selecie din algebra relaional, deoarece expresia care o urmeaz poate conine att comparaii de atribute i/sau expresii aritmetice, ct i operatori logici (AND, OR, NOT), operatori pe mulimi (UNION, INTERSECT, MINUS) i operatori de apartenen la mulimi cu negrile acestora (X IN S, X NOT IN S, S CONTAINS X, S DOES NOT CONTAIN X, unde S este o relaie, iar X este o tupl sau o relaie caz n care este vorba de operaii de incluziune ntre mulimi). Expresia care urmeaz clauzei WHERE poate de asemenea s conin operanzi care sunt relaii rezultate din alte construcii SELECT ceea ce asigur posibilitatea imbricrii acestora n interogri orict de complexe. Facilitile limbajului SQL provenite din calculul relaional al tuplelor se refer, n principal, la posibilitatea de a declara variabile de tupl asociate unor relaii. Asocierea se face n cadrul clauzei FROM sub forma: SELECT...FROM R T WHERE... unde R este o relaie, iar T o variabil de tupl. Variabila de tupl T poate fi apoi folosit n cadrul expresiei care urmeaz dup clauza WHERE, unde se pot face referiri la valoarea componentei A din tupla T prin notaia T.A. Sintaxa complet a construciei SELECT este urmtoarea: SELECT [DISTINCT] nume_atribut1... FROM numerelaie [variabil_de_tupl]... [WHERE calificator1] [GROUP BY nume_atribut2... [HAVING calificator2]] [ORDER BY nume_atribut3 [ASC|DESC]...] unde [] desemneaz o component opional a construciei, iar ... indic repetarea de unul sau mai multe ori a parametrului clauzei curente (list de parametri). Valoarea (valorile) corespunztoare parametrului (parametrilor) nume_atribut1 precizeaz n mod explicit atributele dup care se face proiecia. Dac exist ambiguiti referitor la relaiile din care fac parte atributele specificate, atunci acestea vor fi precedate de numele relaiei corespunztoare fiecrui atribut. Dac n locul acestei liste se folosete simbolul * atunci proiecia se face dup toate atributele relaiei (relaiilor) specificate n clauza FROM. n lipsa operatorului opional DISTINCT proiecia se face fr eliminarea duplicatelor, iar dac acesta apare, atunci se elimin eventualele duplicate rezultate n urma operaiei de proiecie propriu-zise. n cazul cel mai general, parametrul nume_atribut1 poate fi o expresie aritmetic

combinnd atribute i/sau funcii de agregare avnd ca operanzi unul sau mai multe atribute. Prin parametrul nume_relaie se specific relaia (relaiile) care constituie operandul (operanzii) operatorului de mapare. Prin parametrul variabil_de_tupl putem asocia fiecrei relaii cte o variabil de tupl. Parametrul calificator1 precizeaz criteriul de selecie al tuplelor unei relaii. Clauza GROUP BY are ca efect gruparea tuplelor unei relaii pe baza valorilor unui atribut sau grup de atribute. Parametrul nume_atribut2 furnizeaz criteriul de grupare (partiionare) al tuplelor unei relaii n submulimi de tuple, toate avnd aceeai valoare pentru atributul (atributele) nume_atribut2. Criteriul de grupare este format din unul sau mai multe atribute. Aceste submulimi sau grupuri de tuple urmeaz a fi tratate ca jn tot unitar n anumite operaii cum ar fi aplicarea funciilor de agregare care se calculeaz nu pe ntreaga relaie, ci pentru fiecare grup de tuple n parte. Relaia rezultat al oricrei interogri care are o clauz GROUP BY caracterizeaz aceste grupuri de tuple i nu tuple individuale. Parametrii clauzei SELECT dintr-o Construcie SELECT n care apare clauza GROUP BY trebuie s reprezinte o proprietate unic de grup. Prin aceasta nelegem fie un atribut de grupare, fie o funcie de agregare aplicat tuplelor unui grup, fie o expresie format pe baza primelor dou. Clauza HAVING, opiune a clauzei GROUP BY, este o form special a clauzei WHERE caracterizat prin faptul c se aplic nu unor tuple individuale, ci unor submulimi (grupuri) de tuple, rezultate ca urmare a partiionrii prin clauza GROUP BY. Parametrul calificator2 furnizeaz criteriul de selecie al grupurilor de tuple. Acest parametru se refer ntotdeauna la proprietile globale ale unui grup de tuple i nu la tuple individuale. Astfel tuplele unui grup sunt tratate mpreun, n bloc, conform criteriului dat de parametrul calificator2. Exprimarea acestui criteriu ge face cu ajutorul atributelor de grupare i al funciilor de agregare aplicate grupurilor. Clauza ORDER BY specific ordonarea tuplelor unei relaii rezultat dup valorile parametrului nume_atribut3, iar cuvintele cheie ASC i DESC indic modul n care se face ordonarea, dup valorile cresctoare, respectiv descresctoare ale atributului specificat.

eliminarea duplicatelor) a acestei relaii pe Nume_profesor. Secvena SQL corespunztoare este:

SELECT DISTINCT Nume_profesor FROM Note

atributul

3. Dac ne intereseaz toate informaiile cuprinse n relaia Note, arunci vom folosi secvena:
SELECT * FROM Note

unde simbolul * indic faptul c proiecia se face dup toate atributele relaiei date n clauza FROM. 4. Dac dorim ca informaiile de mai sus s fie ordonate n ordinea descrectoare a notelor, atunci vom aduga la interogarea precedent o clauz ORDER BY.
SELECT * FROM Note ORDER BY Nota DESC, Nume_student ASC, Nume_profesor ASC

Dac exist mai multe tuple cu aceeai valoare a notei acestea vor fi sortate r ordinea alfabetic a numelor studenilor, iar dac acelai student a obinu note similare de la profesori diferii, atunci tuplele corespunztoare vor f sortate n ordinea alfabetic a numelor profesorilor. 5. "Numele studenilor care au obinut note peste 8 i numele profesorilor de Ic care au obinut aceste note?"
SELECT Nume_profesor, Nume_student FROM Note WHERE Nota>8

n clauza WHERE se poate specifica o condiie compus folosind operatorii logici AND, OR i NOT, ca n exemplele care urmeaz: 6. "Numele studentelor de la zi care sunt bursiere?"
SELECT Nume FROM Student WHERE Incadr='Zi' AND Sit sc.='B' AND Sex='F'

7. "Numele studenilor din anul 1 sau bursieri?"

SELECT Nume FROM Student WHERE An=l OR Sit sc.='B'

8. "Numele studenilor bursieri i a studentelor din anul 1 ?"

SELECT Nume FROM Student WHERE Sit_c='B' OR An=l AND Sex='F'

ntr-o combinaie care conine operatorii AND i OR se evalueaz nti operatorii AND i doar apoi operatorii OR. 9. "Numele studentelor bursiere i a celor din anul/ ?"
SELECT Nume FROM Student WHERE (Sit_c='B' OR An=l) AND Sex='F'

Prin folosirea parantezelor se poate fora modificarea ordinii normale de evaluare a operatorilor logici cu schimbarea corespunztoare a sensului interogrii. A se compara interogarea Pentru o mai bun nelegere a limbajului SQL prezentm un de fa cu precedenta. set de exemple de interogri rezolvate prin construcii SELECT. 10. "Numrul studenilor din fiecare an de studiu?" Relaiile la care se fac referiri sunt cele din capitolele precedente. SELECT An, COUNT(Nume) FROM Student GROUP BY An Fr pretenia unei tratri exhaustive, prin aceste interogri se Remarcm absena clauzei WHERE, ntruct nu exist nici o urmrete prezentarea principalelor faciliti pe care ofer orice condiie care s restricioneze selectarea tuplelor, i de asemenea interfa SQL. folosirea clauzei GROUP BY pentru gruparea tuplelor dup 1. "Numele profesorilor cu care studiaz studentul Lupu?" atributul An. Ca parametrii ai clauzei SELECT dintr-o construcie Interogarea se exprim prin urmtoarea secven SQL: care conine clauza GROUP BY pot s apar doar acele atribute SELECT Nume_profesor care constituie proprieti unice de grup (avnd aceeai valoare FROM Note pentru fiecare tupl din grup, n spe atributele de grupare) sau WHERE Nume_student=Lupu Exprimarea interogrii n forma de mai sus este corect doar valori care caracterizeaz grupul n ansamblul su, valori care de n ipoteza c fiecare student are cel mult o not de la fiecare regul se obin prin aplicarea unui operator de agregare asupra profesor.n lipsa acestei ipoteze (Lupu ar putea avea mai multe tuplelor grupului (n cazul nostru COUNT(nume) care returneaz note la o anume disciplin) este necesar folosirea operatorului numrul de studeni din fiecare grup). Folosirea operatorului DISTINCT pentru a elimina eventualele repetri ale numelui DISTINCT pentru atributul de grupare nu este necesar. 11. "Numele profesorilor i media pentru profesorii la care aceluiai profesor. Deci interogarea corect va fi: media notelor acordate studenilor este mai mare de 8?" SELECT DISTINCT Nume_profesor

3.4.2. Formularea interogrilor n limbajul SQL

FROM Note WHERE Nume_student='Lupu'

SELECT Nume_profesor, AVG(Nota) FROM Note GROUP BY Nume_profesor HAVING AVG(Nota)>8

Operatorul de agregare AVG din interogarea de mai sus se 2. "Numele profesorilor care au dat cel puin o not?" Ne intereseaz de fapt numele tuturor profesorilor care apar n aplic grupurilor de tuple care au aceeai valoare a atributului relaia Note. Acest lucru se realizeaz printr-o proiecie (cu Nume_profesor i returneaz media notelor acordate de fiecare

WHERE Nume profesor=Profesori.Nume) profesor. Prin clauza HAVING i calificatorul care i urmeaz se IN selecteaz acele grupuri pentru care aceast medie este mai mare (SELECT Nume FROM Student WHERE Sit_sc.=B) de 8. Rezultatul seleciei este format din unul sau mai multe 15. "Numele profesorilor care predau la toi studenii grupuri de tuple avnd aceeai valoare a atributului bursieri?" Nume_profesor. Din fiecare grup se reine doar cte o singur Singura deosebire fa de interogarea precedent este c se dat valoarea atributului Nume_profesor i valoarea calculat pe inverseaz relaia de incluziune ntre cele dou mulimi de grup a mediei notelor. Nu este necesar folosirea operatorului studeni, deci operatorul IN va fi nlocuit prin CONTAINS. DISTINCT. SELECT Nume FROM Profesori WHERE (SELECT Nume_student FROM Note 12. "Media notelor obinute de fiecare student de la fiecare WHERE Nume_profesor=Profesori.Nume) CONTAINS profesor al su?" SELECT Nume_profesor, Nume_student, AVG(Nota) FROM Note GROUP BY Nume_profesor, Nume student (SELECT Nume FROM Student WHERE Sit_sc.='B')

n acest caz criteriul de grupare este format din perechea de atribute Nume_profesor i Nume_student, iar rezultatul returnat se refer, de fapt, la mediile obinute de studeni la diverse discipline. 13. "Numele profesorilor care au cel puin un student bursier?"
SELECT DISTINCT Nume_profesor FROM Note WHERE Nume_student IS IN (SELECT Nume FROM Student WHERE Sit SC.='B')

Observaie: n unele implementri ale limbajului SQL mai apar i operatorii ANY care poate fi folosit ca un cuantificator existenial ()i ALL care corespunde cuantificatorului universal (). Aceti operatori nu se aplic unor variabile, ci unor mulimi care de cele mai multe ori sunt definite prin construcii SELECT imbricate. Exemplu: "Numele studenilor care au o not mai mare dect cea mai mic note acordat?"
SELECT Nume_student FROM Note WHERE Nota > ANY (SELECT Nota FROM Note)

n general efectul operatorilor ANY i ALL poate fi simulat folosinc ceilali operatori prezentai mpreun cu funciile de Interogrile care implic mai multe relaii, dar returneaz date agregare MIN MAX. 16. "Numele studenilor care au luat note mai mici de 8 i dintr-o singur relaie pot fi rezolvate prin imbricarea a mai multe construcii SELECT. Datorit posibilitii de imbricare datele disciplina la care au luat aceste note?" SELECT Note.Nume_student, Profesori.Disciplina rezultate dintr-un tabel pot fi folosite la selecia datelor dintr-un FROM Note, Profesori alt tabel. Dei aceast facilitate este aproape similar cu WHERE Note.Nume_profesor=Profesori.Nume operatorul de cuplare, difer totui de acesta prin faptul c din AND Note.Nota<8 rezultatul final nu pot face parte dect datele rezultate din ultimul Pentru a returna valori din mai multe relaii simultan, este tabel (cel corespunztor blocului cel mai exterior). Majoritatea necesar efectuarea unei operaii de cuplare. Limbajul SQL are o implementrilor limbajului SQL permit imbricarea pe mai multe sintax specific pentru exprimarea unei operaii de cuplare, aa nivele, la cele mai performante fiind posibile pn la 16 nivele de cum se observ i n exemplul de mai sus. Acest lucru va fi mai imbricare a construciilor SELECT. uor de neles dac punem n eviden faptul c produsul n exemplul dat, construcia interioar returneaz mulimea cartezian al relaiilor A i B se exprim prin: SELECT * FROM A, B numelor studenilor bursieri. Construcia exterioar returneaz acele nume profesor pentru care numele student asociat aparine i ne reamintim c operaia de cuplare este echivalent cu mulimii returnate de construcia interioar, adic a studenilor produsul cartezian urmat de o selecie. bursieri. 17. "Numele studenilor de la zi care au luat note mai mici de Este necesar folosirea operatorului DISTINCT deoarece pot exista mai muli studeni bursieri care studiaz cu acelai 8 i disciplina la care au luat aceste note?" Exprimarea acestei interogri prin formalismul algebrei profesor. Limbajul SQL nu dispune de cuantificatori, aa cum apar acetia n calculul relaional, de aceea efectul acestora relaionale presupune, aa cum s-a vzut, efectuarea a dou trebuie simulat prin folosirea relaiilor de apartenen de tipul operaii de cuplare. Limbajul SQL ofer cel puin dou ci de element-mulime, de incluziune mulime-mulime sau de egalitate exprimare a acestei interogri: a. Prin efectuarea simultan a dou operaii de cuplare (de fapt ntre mulimi. un produs cartezian al celor trei relaii Note, Profesori, Student n SQL relaia de apartenen a unei valori la o mulime este urmat de selec ia adecvat): reprezentat prin operatorul IS IN sau simplu IN. La fel se SELECT Student.Nume, Profesori.Disciplina reprezint i relaia de incluziune ntre mulimi. Deci A IN B FROM Student, Note, Profesori semnific: "A aparine Iui B" dac A este o valoare, sau "A este WHERE Note.Nume_profesor=Profesori.Nume AND Student.Nume=Note.Nume_student inclus n B" dac A este o mulime. B trebuie s fie o mulime n AND Note.Nota<8 ambele cazuri. Simetricul operatorului IN este operatorul AND Student.Incadr.='Zi' CONTAINS. A CONTAINS B semnific: "A conine pe B" unde b. Prin folosirea unei operaii de cuplare i a unei imbricri: A este mulime, iar B este o valoare sau o mulime. SELECT Note.Nume_student, Profesori.Disciplina De asemenea se pot folosi i negaiile acestor operatori, FROM Note, Profesori WHERE Note.Nume_profesor=Profesori.Nume anume: NOT IN, DOES NOT CONTAIN. AND Note.Nota<8 Testarea egalitii sau a inegalitii a dou mulimi se face AND Note.Nume_student IN prin operatorii = i # (sau != sau <>). (SELECT Nume FROM Student WHERE Incadr.='Zi') 14."Numele profesorilor ai cror studeni sunt toi bursieri? " Observaie: Interogarea se poate reformula astfel: "Numele profesorilor Dup cum se observ i din exemplele de pn acum, pentru care mulimea studenilor crora le predau este inclus n calificarea numelor de atribute nu este obligatorie. Ea este mulimea studenilor bursieri?". Exprimarea acesteia n limbajul necesar doar atunci cnd pot s apar ambiguiti. Dac n SQL este: clauza FROM a unei construcii SELECT apare un singur nume SELECT Nume FROM Profesori de relaie, atunci implicit toate numele de atribute fr calificare WHERE (SELECT Nume_student FROM Note

din blocul curent se consider ca aparinnd acestei relaii. Dac un nume de atribut dintr-un bloc exterior este folosit ntr-un bloc imbricat sau n acelai bloc apar mai multe nume de relaii, atunci este necesar calificarea atributelor prin numele relaiilor crora le aparin. 18. "Numele studenilor i notele celor care au obinut o not mai mare la programare dect studentul Lupu?" i pentru aceast interogare prezentm dou soluii diferite: a. Prima soluie face apel la posibilitatea de a imbrica pe mai multe nivele construciile SELECT:
SELECT Nume_student, Nota FROM Note
WHERE Nume_profesor IN (SELECT Nume FROM Profesori WHERE Disciplina='Programare') AND Nota > (SELECT Nota FROM Note WHERE Nume_student='Lupu' AND Nume_profesor IN (SELECT Nume FROM Profesori WHERE Disciplina='Programare'))

operatorului cerut, fr a necesita folosirea opiunii DISTINCT. De menionat c operanzii, care n genen sunt relaii (mulimi de tuple), trebuie s satisfac condiia de compatibilitate la reuniune. 22. "Numele profesorilor care predau studenilor din anul 1 sau bursieri?" Presupunem c avem gata calculate relaiile Anul1 i Bursieri care cont datele studenilor din anul 1, respectiv ale studenilor bursieri. n aces condiii comparaia cu interogarea 7) ar putea sugera urmtoarea soluie:
SELECT DISTINCT Note.Nume_profesor FROM Note, Anul1, Bursieri WHERE Note.Nume_student=Anull.Nume OR Note.Nume_student=Bursieri.Nume

Rezultatul ateptat pentru interogarea dat este lista cu numele profesorilor care predau cel puin unui student din mulimea studenilor din anul 1 reunit cu mulimea studenilor bursieri. Secvena SQL de mai sus retuneaz rezultatul corect numai dac b. A doua soluie, poate mai puin eficient dect prima, relaiile Anul1 i Bursieri sunt ambele nevide. Dac, spre ilustreaz modu n care se pot folosi variabilele de tupl: exemplu, relaia Bursieri este vid, atunci nu va fi retumat nici SELECT Nl.Nume_student, N1.Nota un nume de profesor chiar dac exist profesori care predau la FROM Note N1, Note N2 anii 1. Aceast anomalie rezult din modul de interpretare al WHERE N1.Nota > N2.Nota AND N2.Nume_student='Lupu' interogrilor SQL. n cazul nostru se calculeaz nti (cel puin AND Nl.Nume_profesor IN aparent) produsul cartezian al relaiilor Note, Anul1 i Bursieri (SELECT Nume FROM Profesori dup care se analizeaz condiia din clauza WHERE. WHERE Disciplina='Programare') AND N2.Nume_profesor IN Pentru interogarea dat se poate obine un rezultat corect prin (SELECT Nume FROM Profesori secvena SQL de mai jos care folosete operatorul UNION:
WHERE Disciplina=' Programare')

Variabilele de tupl se pot folosi pentru calificarea atributelor la fel ca orice nume de relaie i, de multe ori, sunt considerate ca redenumiri (alias) al relaiilor crora le sunt asociate. 19. "Numele studenilor care studiaz cu cel puin doi profesori?"
SELECT DISTINCT Nume_student FROM Note XNote WHERE Numestudent IN (SELECT Nume_student FROM Note WHERE Nume_profesor#XNote.Nume_profesor)

(SELECT DISTINCT Note.Nume_profesor FROM Note, Anul1 WHERE Note.Nume_student=Anul1.Nume) UNION (SELECT DISTINCT Note.Numeprofesor FROM Note, Bursieri WHERE Note.Nume student=Bursieri.Nume)

3.2.2. Operaii de tergere, inserare i actualizare

Fiecare din cei trei operatori care urmeaz a fi prezentai n Remarcm folosirea variabilei de tupl XNote asociat relaiei coninuare acioneaz la un moment dat doar asupra unei singure Note. relaii. 20. "Numele i nota pentru primii 5 dintre studenii care au Operatorul SQL pentru efectuarea operaiilor de tergere este obinut cele mai mari note de la profesorul Pop?" DELETE FROM a crui sintax complet este: SELECT Nume_student, Nota DELETE FROM nume_relaie [variabil_de_tupl] FROM Note N [WHERE calificator] WHERE Nume_profesor='Pop' AND 5>(SELECT COUNT(*) Exemple: FROM Note 1. tergerea tuturor tuplelor din relaia Note:
WHERE Nume_profesor='Pop' AND Nota>N.Nota)

Construcia SELECT interioar returneaz numrul Relaia Note va exista n continuare, dar va fi vid. studenilor care au obinut de la profesorul Pop o not mai mare 2. tergerea din relaia Note a tuplelor n care nota este sub 5. dect studentul curent din construcia SELECT exterioar. De DELETE FROM Note WHERE Nota<5 remarcat faptul c dac exist 6 studeni care au obinut nota 10, Operatorul SQL pentru inserare este INSERT INTO i atunci toi acetia vor fi inclui n relaia rezultat. prezint dou variante: 21. "Numele studenilor care nu studiaz programare?" - inserare simpl pentru inserarea unei tuple individuale; (SELECT Nume_student FROM Note) MINUS - inserare multipl pentru inserarea a mai multe tuple. (SELECT Nume_student FROM Note Comanda pentru inserare simpl are sintaxa: WHERE Nume_profesor IN INSERT INTO numerelaie {nume_atribut...) VALUES (SELECT Nume FROM Profesori (valoare...) WHERE Disciplina='Programare')) ntre valori i numele de atribute trebuie s existe o Interogarea se exprim ca diferena a dou mulimi: coresponden unu la unu. Pentru atributele care accept valoarea - mulimea studenilor care studiaz cel puin o disciplin; NULL (vezi comanda CREATE TABLE) specificarea unei valori - mulimea studenilor care studiaz programare. n comanda de inserare este opional. Acestea vor fi omise din Remarcm folosirea operatorului MINUS pentru diferena a lista de atribute i vor lua implicit valoarea NULL, eventual, dou mulimi, n limbajul SQL mai sunt disponibili pentru urmnd a fi modificate ulterior cnd valorile lor vor fi cunoscute. operaii pe mulimi, operatorii: Valorile din lista de valori pot fi ori literale, ori expresii - UNION pentru reuniunea mulimilor de tuple a dou relaii; aritmetice. - INTERSECT pentru intersecie. Exemple: Fiecare din cei trei operatori accept ca operanzi doar 1. Inserarea n relaia Profesori a tuplei Popovici-conf.-limbaje mulimi, duplicatele sunt eliminate automat nainte de aplicarea se realizeaz astfel:

DELETE FROM Note

INSERT INTO Profesori (Nume, Funcie, Disciplina) VALUES ('Popovici', 'conf.', 'limbaje')

2. Comanda:
INSERT INTO Profesori (Nume) VALUES ('Popa')

SELECT Nurae_profesor, AVG(Nota) FROM Note GROUP BY Nume_profesor

are ca efect inserarea n relaia Profesori a tuplei Popa-NULLNULL (n ipoteza c atributul Nume este singurul declarat cu opiunea NOT NULL). Comanda pentru inserare multipl are sintaxa: INSERT INTO nume_relaie (nume_atribut...) construcie_SELECT i permite adugarea la relaia specificat a unei mulimi de tuple (relaie) care se obine ca rezultat al unei construcii SELECT. Exemplu: Presupunem c avem o relaie Bursieri cu atributele Nume i Media n care am inclus toi studenii cu media peste 8. Dac se coboar acest barem la 7 relaia Bursieri va fi completat astfel:
INSERT INTO Bursieri(Nume, Media) SELECT Nume_student, AVG(Nota) FROM Note GROUP BY Nume_student HAVING AVG(Nota)>7 AND AVG(Nota)<=8

3.2.4. Operatorul de asignare

Operatorul de asignare, ASSIGN TO, permite asignarea rezultatului returnat de o clauz SELECT unei variabile care va ndeplini funcia de nume a relaiei rezultat, nume cu ajutorul cruia aceast relaie poate fi referit n continuare. Sintaxa operatorului de asignare este: ASSIGN TO nume relaie: Aceast facilitate este util atunci cnd se dorete reinerea unor rezultate pariale din interogri mai complexe. Exemplu: Interogarea, "Numele studenilor i notele celor care au obinut not mai mare programare dect studentul Lupu?" se poate rescrie mai eficient folosind operatorul de asignare astfel:
SELECT Nume_student, Nota FROM Note WHERE Nume_profesor IN ASSIGN TO NPP: (SELECT Nume FROM Profesori WHERE Disciplina='Programare') AND Nota > (SELECT Nota FROM Note WHERE Nume_student='Lupu' AND Nume_profesor IN NPP)

Operatorul SQL pentru actualizarea tuplelor este UPDATE i are sintaxa: UPDATE numerelaie [variabil_de_upl] SET nume_atribut=expresie_de_actualizare... [WHERE calificator] Operatorul de actualizare ndeplinete dou funcii: Selecteaz prin condiia de cutare din clauza WHERE tuplele care urmeaz a fi actualizate (n lipsa clauzei WHERE se actualizeaz implicit toate tuplele relaiei specificate). n tuplele selectate modific valorile atributelor specificate. Expresiile de actualizare pot conine: constante, nume de atribute, valoare NULL sau expresii aritmetice construite cu acestea. n limbajul SQL este permis chiar i actualizarea atributelor care fac parte dintr-o cheie primar. Exemple: 1. Asistentul Pop este avansat ef de lucrri.
UPDATE Profesori SET Funcie='l' WHERE Nume=Pop

3.2.5. Definirea datelor n SQL

Teoretic, comenzile pentru definirea datelor fac parte din modulul corespunztor componentei LDD al SGBD-ului. Totui, n majoritatea implementrilor SQL comenzile de definire a datelor sunt prelucrate de acelai interpretor care rezolv interogrile i celelalte operaii de manipulare a datelor prezentate anterior. Aadar, componentele LMD i LDD ale SGBD-ului sunt implementate prin acelai modul software.

2. n relaia Note se mresc cu un punct toate notele mai mici de 5.

UPDATE Note SET Nota=Nota+l WHERE Nota<5

3.2.3.

Operatori de agregare

Operatorii de agregare definii n mod uzual n orice implementare a limbajului SQL sunt: COUNT (numrare), SUM (suma valorilor unei coloane), AVG (media valorilor unei coloane), MAX (valoarea maxim dintr-o coloan), MIN (valoarea minim dintr-o coloan). Toi aceti operatori pot fi folosii att n calificatori, ct i n clauze SELECT. Exemple: 1. "Care este numrul studenilor bursieri?"
SELECT COUNT(Nume) FROM Student WHERE Sit_sc.='B'

2."Care este cea mai mic not obinut de un student bursier?"

SELECT MIN(Nota) FROM Note WHERE Nume_student IN (SELECT Nume FROM Student WHERE Sit_sc. = 'B')

Definirea unei relaii se poate face prin comanda CREATE TABLE. Relaiile definite prin aceast comand sunt numite relaii de baz. Definiia acestor relaii este automat memorat ntr-un dicionar de date numit i catalog sistem. Sintaxa comenzii pentru definirea relaiilor este: CREATE TABLE nume_relaie (nume_atribut1 tip_dat [NOT NULL] [,nume_atribut2 tip_ dat [NOT NULL]]...) Comanda specific numele relaiei care se creeaz precum i una sau mai multe descrieri de atribute. Descrierea fiecrui atribut specific numele atributului i tipul de dat corespunztor (CHAR, INTEGER etc.) mpreun cu dimensiunea asociat. Opiunea NOT NULL, asociat unui atribut, indic faptul c n coloana corespunztoare acestuia nu pot s apar valori nedefinite (NULL). Aceast opiune este util n special la definirea atributelor care compun cheia primar a relaiei. Exemplu: n ipoteza c fiecare profesor acord oricrui student o singur not, relaia note poate fi definit astfel:
CREATE TABLE Note (Nume_profesor CHAR(20) NOT NULL, Nume_student CHAR(20) NOT NULL, Nota INTEGER(2))

Crearea tabelelor (relaiilor)

3."Care este media notelor obinute de studeni la programare?"

SELECT AVG(Nota) FROM Note WHERE Nume_profesor IN (SELECT Nume FROM Profesori WHERE Disciplina='Programare')

4. "Numele i media notelor acordate de fiecare profesor?"

Cu ipoteza de mai sus cheia relaiei Note este format din atributele Nume_profesor i Nume_student, iar pentru aceste atribute nu se accept valori nedefinite. Comanda simetric celei de creare a unei relaii este DROP TABLE care are ca efect eliminarea din catalogul sistem a relaiei

FROM Bursieri specificate. Dup executarea acestei comenzi nu se mai pot face WHERE Media>B.Media) nici un fel de referiri Ia relaia n cauz, descrierea acesteia Cititorul se poate convinge singur de faptul c rezolvarea mpreun cu informaiile coninute fiind terse. Sintaxa comenzii acestei interog ri prin invocarea direct a relaiilor de baz este: Student i Note este mai mult dect dificil. DROP TABLE numerelaie Spre deosebire de vederile din QBE care sunt de tip read-only, numele unei vederi SQL poate fi invocat nu numai n interogri ci Crearea vederilor i n comenzile DELETE, INSERT i UPDATE, caz n care O vedere este o relaie virtual care nu exist fizic n baza de relaiile de baz din definiia vederii pot suferi modificri. Pentru date. n SQL o vedere este definit ca o relaie derivat, al crei ca aceste operaii s aib sens este necesar s se respecte coninut este determinat din una sau mai multe relaii de baz urmtoarele restricii: conform definiiei vederii n cauz. Comanda pentru definirea vederea invocat s nu fie rezultatul unei operaii de cuplare unei vederi este CREATE VIEW i are sintaxa: (sau echivalent); CREATE VIEW nume_vedere (numeatribut...) construcia SELECT care definete vederea s nu conin AS construcie_SELECT clauza GROUP BY, opiunea DISTINCT sau funcii de agregare; Comanda CREATE VIEW creeaz n catalogul sistem o vederea s nu aib atribute calculate (definite printr-o intrare corespunztoare denumirii numevedere, creia i asociaz expresie aritmetic). definiia specificat prin comand: lista de atribute i construcia Chiar cu restriciile de mai sus, executarea comenzilor SELECT. Atunci cnd numele vederii este invocat ntr-o DELETE, INSERT i UPDATE asupra vederilor poate produce interogare definiia vederii este combinat cu interogarea dat fenomene mai puin obinuite de care utilizatorul avizat trebuie s pentru a obine o interogare n termenii relaiilor de baz. n in cont. general, construcia SELECT din definiia unei vederi poate avea Exemplu: orice form excepie fiind clauza ORDER BY care nu poate s Fie vederea Note_programare care este derivat din relaia de apar ntr-o comand CREATE VIEW. Aceast restricie este baz Note selectnd doar tuplele pentru care impus de necesitatea de a conferi vederilor un statut ct mai Nume_profesor='Pop' apropiat de cel al relaiilor de baz n care, prin definiie, ordinea CREATE VIEW Note_programare tuplelor este arbitrar. Deci definiia unei vederi nu poate conine (Nume_profesor, Nume_student, Nota) clauza ORDER BY, n schimb aceast clauz poate s apar ntrAS SELECT Nume_profesor,Nume_student,Nota FROM Note o construcie SELECT care face referire la o vedere, la fel ca n WHERE Nume_profesor='Pop' orice interogare obinuit. Vederea Note_programare poate fi invocat ntr-o operaie de Dac este omis lista nume_atribut din definiia vederii, inserare de forma: atunci atributele acesteia vor avea aceeai denumire cu cele INSERT INTO Noteprogramare specificate n construcia SELECT asociat. Acest lucru este (Nume_profesor, Nume_student, Nota) VALUES posibil numai dac atributele din construcia SELECT nu sunt (Costea, Lupu, 10) rezultatul unor funcii de agregare sau al unor expresii aritmetice, Comanda de mai sus este perfect legal, iar efectul concret al caz n care este necesar specificarea ntregii liste de atribute ale execuiei sale este inserarea n relaia de baz Note a tuplei vederii. ('Costea', 'Lupu', 10). Totui aceast tupl, dei aparent a fost Exemple: inserat n vederea Note_programare, nu poate face parte din 1. Vederile sunt adesea percepute ca mecanisme de limitare a aceasta deoarece nu corespunde definiiei vederii. n consecin accesului unor categorii de utilizatori la anumite date mai mult rezult produs de o interogare de forma: sau mai puin confideniale. Dac se dorete ca informaia SELECT * referitoare la funciile profesorilor s nu fi accesibil studenilor, FROM Note_programare atunci se interzice dreptul de acces la relaia Profesori a oricrui nu va conine tupla ('Costea', 'Lupu', 10), chiar dac este utilizator din categoria student. Totui studenii au nevoie s tie formulat dup execuia operaiei de inserare de mai sus. care profesor ce discipline pred, de aceea pentru uzul acestora se Efecte similare se pot evidenia i n cazul comenzilor de tip definet vederea Profesori_disciplin astfel: DELETE i UPDATE aplicate asupra vederilor (operaii de CREATE VIEW Profesori_disciplin (Nume, Disciplin) tergere a unor tuple ce nu exist n vedere sau actualizri care au AS SELECT Nume, Disciplin FROM Profesori ca efect "dispariia" din vedere a unor tuple). 2. Vederile sunt de asemenea utile pentru simplificarea tergerea unei vederi dintr-o baz de date se face cu comanda viziunii utilizatorilor asupra bazei de date. Putem crea o vedere DROP VIEW a crei sintax este: numit Bursieri cu atributele Nume, An i Media care s conin DROP VIEW nume_vedere toi studenii cu media notelor peste 8, folosim comanda: CREATE VIEW Bursieri (Nume, An, Media) AS SELECT Nume, An, AVG(Nota) FROM Student, Note WHERE Nume=Nume_student GROUP BY Nume HAVING AVG(Nota) > 8

Numele acestei vederi poate fi apoi invocat ntr-o serie de interogri implicnd studenii bursieri. Forma acestor interogri va fi simplificat prin folosirea vederii. Mai mult, putem modifica definiia conceptului de bursier fr a fi necesar s modificm interogrile n care apare. Exemplu: "Lista primilor 5 bursieri n ordinea descresctoare a mediilor obinute?"
SELECT Nume, An, Media FROM Bursieri B WHERE 5>(SELECT COUNT(*)

Folosirea indecilor permite creterea substanial a vitezei de acces la date fiind una din principalele ci pentru optimizarea interogrilor. Indecii permit accesul la date fr a fi necesar parcurgerea secvenial a relaiilor din care fac parte. Pentru o relaie se pot defini unul sau mai muli indeci, fiecare avand la baz unul sau mai multe dintre atributele relaiei. Comanda SQL pentru crearea unui index este CREATE INDEX i are sintaxa: CREATE [UNIQUE] INDEX nume_index ON nume_relaie (nume_atribut1 [DESC] [,nume_atribut2 [DESC]]...)

Crearea indecilor

Odat creat un index nu mai poate fi invocat n interogri sau programe utilizator. Indecii sunt folosii exclusiv de ctre sistemul SQL n procesul de optimizare a interogrilor pentru a gsi calea de acces cea mai rapid la date i sunt actualizai automat n cazul operaiilor de inserare, tergere sau actualizare a relaiilor. Intrrile unui index sunt ordonate implicit n ordinea cresctoare a valorilor atributelor specificate. Dac se dorete o ordonare descresctoare dup valorile unui anumit atribut, atunci pentru acesta se va specifica opiunea DESC. Opiunea UNIQUE specific faptul c n indexul corespunztor nu pot exista dou intrri avnd valori identice ale atributelor pe care acesta este definit Aceast condiie este verificat automat n cazul comenzilor INSERT i UPDATE, refuzndu-se execuia la apariia unui duplicat. Prin folosirea opiunii UNIQUE atributele care stau la baza indexului corespunztor vor forma o cheie n relaia asociat. Dac aceste atribute au fost, la rndul lor, definite cu opiunea NOT NULL, atunci vom avea o cheie primar. Aadar, n SQL, o cheie primar se definete ca un index unic fr valori nule. Exemple: 1. Crearea unui index cu numele lprof, definit pe atributul Nume_profesor din relaia Note se realizeaz prin comanda:
CREATE INDEX lprof ON Note (Nume_profesor).

4. NORMALIZAREA RELAIILOR
n acest capitol vom aborda o problem care face parte din proiectarea conceptual a oricrei baze de date i a bazelor de date relaionale n special; este vorba de normalizare. Pornind de la conceptele de dependen funcional i dependen multivaloric sunt prezentate formele normale ale relaiilor de la forma normal nti (FN1) pn la a cincea form normal (FN5), precum i principiile care stau la baza proiectrii unor scheme relaionale avnd anumite proprieti convenabile.

4.1.

Introducere

n relaia Note vor putea exista n continuare mai multe tuple cu aceeai valoare a atributului Nume_profesor. 2. Putem crea o cheie primar cu numele Inote, definit pe atributele Nume_profesor i Nume_student ale relaiei Note prin comanda:
CREATE UNIQUE INDEX Inote ON Note (Nume_profesor, Nume_student).

n comanda CREATE TABLE, prin care s-a creat relaia Note, atributele Nume_profesor i Nume_student au fost definite cu opiunea NOT NULL. Folosind opiunea UNIQUE la definirea indexului Inote, perechea de atribute Nume_profesor Nume_student capt statut de cheie primar. Prin indexul Inote se foreaz n relaia Note condiia ca oricare profesor s acorde cel mult a not fiecrui student. Eliminarea unui index dintr-o baz de date se face prin comanda DROP INDEX, avnd sintaxa: DROP INDEX nume_index. Indecii constituie instrumentul ideal pentru mbuntirea performanei unei baze de date atta timp ct este vorba numai de operaii de interogare. Cu ct avem mai muli indeci, definii pe atributele relaiilor de baz, cu att vom obine rspunsuri mai prompte la o gam mai variat de interogri. Cu toate acestea, dac lum n considerare operaiile de tegere, inserare i actualizare, atunci lucrurile apar ntr-o alt lumin. ntr-adevr orice modificare a unei tuple dintr-o relaie de baz necesit actualizarea tuturor indecilor definii peste aceea relaie (reindexare). Actualizarea fiecrui index implic, de regul, una sau mai multe accese suplimentare la disc. Acest fapt mrete costul oricrei operaii de modificare a bazei de date i acest cost este cu att mai mare cu ct avem un numr mai mare de indeci. Rezult c existena unui numr prea mare de indeci va diminua performanele bazei de date atunci cnd se fac operaii de inserare tergere i actualizare. Concluzia care se impune este c trebuie limitat numrul de indeci n cazul bazelor de date la care operaiile de inserare, tergere i actualizare sunt frecvente. n schimb, indecii pot fi folosii n mod extensiv pentru optimizarea accesului la date n cazul bazelor de date la care domin operaiile de tip regsire.

Normalizarea relaiilor face parte din problematica mai larg a proiectrii bazelor de date relaionale i a bazelor de date n general. Principalele elemente constitutive ale modelului conceptual al unei baze de date relaionale sunt schemele relaiilor care intr n componena bazei de date respective. Schema unei relaii descrie structura relaiei respective i cuprinde numele relaiei mpreun cu atributele asociate. n procesul de proiectare ai unei baze de date relaionale care s modeleze un anume segment al lumii reale, suntem confruntai cu problema alegerii setului de scheme de relaie prin care s modelm acele aspecte din lumea real pe care dorim s le cuprindem n baza de date. Cu alte cuvinte problema este de a alege schemele de relaie i modul de grupare al atributelor n relaii pentru a reprezenta tipuri de entiti sau legturi ntre tipuri de entiti. De regul, exist mai multe posibiliti n efectuarea acestor alegeri, iar anumite modele conceptuale (seturi de scheme de relaii) pot fi mai convenabile dect altele datorit unor proprieti care urmeaz a fi prezentate n continuare. Ideea central care st la baza criteriilor de proiectare a unei baze de date relaionale este aceea de dependen a datelor. Aceasta se refer la faptul c ntre atributele unei relaii sau ntre atribute din relaii diferite pot exista anumite legturi logice (dependene), iar aceste legturi influeneaz proprietile schemelor de relaie n raport cu operaiile curente care intervin n timpul exploatrii bazei de date: adugare, tergere, actualizare. Pn la ora actual cel mai intens studiate i cu implicaii majore asupra criteriilor de proiectare a schemelor relaionale sunt dependenele funcionale i dependenele multivalorice. Exemplu: Fie schema de relaie: Furnizor(Nume, Adresa, Produs, Pre) unde se observ existena unei dependene a atributului Adres fa de atributul Nume. Deci, n ipoteza rezonabil c fiecare furnizor are o singur adres, rezult c fiecare valoare a atributului Nume determin n mod univoc valoarea corespunztoare a atributului Adres. O prim observaie este aceea c schema de relaie de mai sus introduce o redondan relativ la atributul Adres a crei valoare este repetat pentru fiecare produs livrat de acelai furnizor. Aceast redondan conduce la apariia urmtoarelor anomalii: Anomalia de adugare Nu se poate nregistra adresa unui furnizor atta timp ct acesta nu livreaz cel puin un produs. Anomalia de tergere Este inversa anomaliei de adugare i se refer la faptul c dac se terg toate produsele livrate de un anumit furnizor atunci se pierde, n mod probabil neintenionat, adresa acestui furnizor. Anomalia de actualizare Ca o consecin a redondanei, relativ la atributul adres, atunci cnd se schimb adresa unui furnizor este necesar parcurgerea ntregii relaii pentru a depista i actualiza toate apariiile acestui furnizor. n caz contrar apare pericolul

introducerii unei inconsistene n baza de date datorit faptului c acelai furnizor apare la adrese diferite. Problemele puse n eviden mai sus se pot elimina dac se nlocuiete relaia Furnizor prin dou relaii FA i FPP avnd schemele de relaie: FA(Nume, Adresa) FPP(Nume, Produs, Pre). Relaia FA conine numele i adresa fiecrui furnizor, fr nici un fel de redondan. Relaia FPP arat produsele pe care le livreaz fiecare furnizor i preurile acestor produse. Anomaliile semnalate mai sus nu mai apar n cazul acestei scheme relaionale. Un dezavantaj al descompunerii efectuate este acela c pentru a determina adresa furnizorului unui produs dat este necesar efectuarea unei operaii costisitoare de cuplare a relaiilor FA i FPP. Aa cum se constat i din exemplul prezentat problema alegerii unui model conceptual corect pentru o baz de dat relaional este, de cele mai multe ori, formulat n termenii determinri unor descompuneri pentru nite scheme de relaii date, descompuneri care s izoleze dependenele existente i prin aceasta s elimine anomaliile care decurg din ele. n cele mai multe cazuri problematica normalizrii este prezentat n contextul bazelor de date relaionale. Trebuie ns menionat faptul c principiile de proiectare prezentate n acest capitol se aplic i n cazul celorlalte modele de date.

unde atributul Adresa este redondant n determinarea valorii atributului Pre, Nume Produs Pre Adresa Nume Produs Adresa Nume Pre Adresa Pentru a epuiza lista tuturor dependeelor funcionale posibile din schema de relaie Furnizor mai trebuie, s lum n considerare i dependenele triviale de forma: Nume Nume, Pre Pre,....a.m.d. precum i toate combinaiile acestora cu dependenele de mai sus, cum ar fi dependena funcional: Nume Produs Pre Adresa Adresa considerat de asemenea trivial, n sensul c nu conine nici un fel de informaie. Dependenele funcionale totale, netriviale din exemplul considerat sunt vizualizate prin diagramele din figura 4.1.
Nume Nume Adresa Produs Pre

Fig.4.1. Dependene funcionale n schema de relaie: Furnizor(Nume,Adresa,Produs,Pre)

4.2.

Dependene funcionale

Fie R(A1,A2,...,An) o schem de relaie, iar X i Y dou atribute, simple sau compuse, submulimi ale mulimii de atribute {A1, A2,..., An}. Definiie: Atributul X (simplu sau compus) determin funcional atributul Y (sau Y depinde funcional de X), i notm X Y, dac i numai dac oricrei valori (set de valori ale atributelor componente) a atributului X i corespunde o singur valoare a atributului Y. Dependena funcional X Y este total dac nu exist nici un subset Z al atributului X (ZX) astfel nct Z Y, respectiv este parial n caz contrar. Observaii: 1. Dac X Y atunci pentru orice subset Z, al lui Y, avem: X Z. 2. Dac X Y i X este un atribut simplu, atunci Y este dependent funcional total fa de X. 3. Dac Y este dependent funcional total fa de Z, atunci avem: X Y pentru orice atribut compus X care conine pe Z. Exemplu: n cazul schemei de relaie: Furnizor(Nume, Adresa, Produs, Pre) pot fi identificate urmtoarele dependene funcionale: a. Nume Adresa dependena funcional total a atributului Adresa fa de atributul Nume care este dedus pe baza ipotezei c fiecare furnizor are o singur adres; b. - Nume Produs Pre dependena funcional total a atributului Pre fa de atributul compus Nume Produs care se deduce pe baza ipotezei c fiecare furnizor are un pre propriu pentru fiecare produs pe care-l livreaz. Pe lng dependenele menionate n cadrul schemei de relaie Furnizor mai exist urmtoarele dependene funcionale pariale: Nume Adresa Produs Pre

Dup cum se poate observa i din exemplul de mai sus, pornind de la un set de dependene funcionale date se pot deduce o serie de alte dependene funcionale care sunt o consecin logic a celor iniiale. Aceste dependene funcionale pot fi deduse ntr-un mod sistematic folosind un set de reguli numite axiomele lui Armstrong. Fie X,Y i Z submulimi ale mulimii de atribute {A1, A2,..., An}. Cele 3 axiome ale lui Armstrong pentru dependenele funcionale se pot formula astfel: Al: (reflexivitate) Dac YX, atunci X Y. Aceast axiom genereaz dependenele triviale; ea nu aduce nici un plus de informaie despre lumea real, dar este util n combinaie cu celelalte dou axiome. A2: (augmentare) Dac X Y, atunci XZ YZ. A3: (tranzitivitate) Dac X Y i Y Z, atunci X Z. Aceasta este singura regul care conduce la obinerea de dependene noi i netriviale. Mulimea dependenelor funcionale care se pot obine prin aplicarea repetat, n toate modurile posibile, a regulilor A1-A3 asupra unui set iniial F de dependene funcionale poart numele de nchidere (tranzitiv) a setului de dependene funcionale F i se noteaz prin F* . Axiomele lui Armstrong constituie un set complet i sigur de reguli de inferen n sensul c permit deducerea tuturor dependenelor funcionale i numai ale acelora care sunt logic deductibile din setul iniial de dependene F. Aceasta nseamn c orice relaie care satisface setul iniial de dependene funcionale F va satisface de asemenea orice dependen din nchiderea tranzitiv F*. Existena n cadrul relaiilor a dependeelor funcionale este natural. n orice relaie atributele sunt dependente funcional fa de cheile acesteia deoarece, dup cum se tie, orice cheie are proprietatea c identific n mod unic fiecare tupl, deci determin n mod univoc valorile atributelor tuplei. Dependeele funcionale existente n cadrul unei scheme de relaie se datoreaz semanticii segmentului din lumea real care se modeleaz prin aceast schem i reprezint constrngeri referitoare la realitatea modelat. ntr-un anumit sens aceste constrngeri constituie informaii suplimentare asociate relaiei i care nu pot fi nglobate n reprezentarea relaiei, dei se reflect

indirect n aceast reprezentare prin valorile concrete pe care le iau atributele relaiei. Aceste dependene nu pot fi demonstrate, ele sunt aseriuni (ipoteze de lucru) relativ la lumea real i au implicaii n modelarea acesteia. Din acest motiv, atunci cnd dorim s determinm dependenele funcionale dintr-o relaie, trebuie s analizm ce anume reprezint relaia de fapt i care este semnificaia fiecrui atribut al ei. ntr-un fel stabilirea dependenelor constituie o decizie de proiectare, la fel ca stabilirea relaiilor i atributelor, i poate conduce la un model conceptual mai mult sau mai puin bun, dup cum ipotezele de lucru reflect mai mult sau mai puin fidel realitatea modelat. Pentru aceeai schem de relaie putem avea seturi diferite de dependene, dup cum adoptm unele sau altele dintre ipotezele de lucru referitoare la semnificaia atribuit componentelor relaiei. Revenind la exemplul din paragraful precedent se constat c ipoteza conform creia fiecrui furnizor i corespunde o singur adres permite evidenierea dependenei funcionale: Furnizor Adres care a dus la obinerea unei scheme relaionale cu proprieti mai bune. Pe de alt parte ns aceast constrngere face imposibil nregistrarea anumitor informaii. Astfel n cazul nostru-este imposibil s memorm dou adrese diferite pentru acelai furnizor dei n realitate asemenea situaii ar putea exista.

4.3. Descompunerea schemelor de relaie

Dup cum s-a menionat i anterior principala cale de eliminare a dependenelor funcionale din schemele de relaie i a consecinelor pe care aceste dependene le implic, redondana datelor, respectiv anomaliile de adugare, tergere i actualizare, o constituie descompunerea schemei date ntr-o colecie de scheme mai simple care evit aceste neajunsuri. n cele ce urmeaz este convenabil s asimilm o schem de relaie cu mulimea atributelor sale. O schem de relaie R(Al,A2,...,An) poate fi privit ca o mulime de atribute: R={A1,A2,...,An}. n continuare vom folosi alternativ aceste dou notaii n funcie de cerinele contextului dat. Prin descompunerea unei scheme de relaie R={A1,A2,...,An} se nelege nlocuirea acesteia printr-o colecie p={R1,R2,-.,Rk} de submulimi ale lui R astfel nct R=R1R2... Rk unde R1,R2,...,Rk nu sunt neaprat disjuncte. Relaiile corespunztoare schemelor R1, R2,..., Rk vor fi de fapt proiecii nedisjuncte ale relaiei corespunztoare schemei iniiale R. Din punct de vedere semantic o astfel de descompunere urmrete s realizeze o separare o coninutului de informaie din relaia iniial astfel nct fiecare din schemele de relaie rezultate s reprezinte un singur tip de entitate sau o legtur ntre dou tipuri de entiti. Dintre aceste descompuneri numai o parte au proprietatea c din relaiile corespunztoare schemelor descompunerii se poate reconstitui relaia iniial. Metoda uzual de realizare a unei asemenea reconstituiri este prin folosirea operatorului de cuplare. Posibilitatea de a reconstitui relaia iniiali refer att la coninutul de informaie, ct i la regsirea dependentelor funcionale existente n relaia iniial. O descompunere p a unei scheme de relaie R este considerat ca fiind echivalent cu R dac are proprietile: cuplare fr pierdere de informaie (lossless join property),.. conservarea dependenelor (dependency preservation). Cuplarea fr pierdere de informaie se refer la proprietatea unei descompuneri de a conserva coninutul de informaie al oricrei relaii asupra creia se aplic aceast descompunere.

Fie R o schem de relaie descompus n schemele R1,R2,...,Rk. Descompunerea are proprietatea de cuplare fr pierdere de informaie, dac pentru orice relaie r, valoare actual a schemei de relaie R, avem: r=R1(r) >< R2(r) >< ...Rk(r) adic r este rezultatul cuplrii proieciilor sale dup schemele de relaie R1,R2,...,Rk. Lipsa proprietii mai sus enunate se manifest n mod concret i aparent paradoxal prin apariia n urma cuplrii proieciilor rezultate din descompunere, a unor tuple suplimentare, inexistente n relaia iniial. Apariia acestor tuple suplimentare sau parazite are drept consecin pierderea unor informaii din relaia iniial prin efectul de "diluare" al informaiei coninut de tuplele legitime. Pentru cazul particular al descompunerii unei scheme de relaie R n dou proiecii R1 i R2 se poate formula o regul simpl pentru verificarea proprietii de conservare a coninutului de informaie. Aceast regul este dat de teorema lui Ullman: Teorem (Ullman): Fie ={R1,R2} o descompunere a schemei de relaie R, atunci constituie o descompunere fr pierdere de informaie, n raport cu un set dat de dependene funcionale iniiale, dac n urma descompunerii avem una din urmtoarele dependene funcionale: (R1R2) (R1-R2) sau (R1R2) (R2-R1) Un corolar al teoremei de mai sus este acela c dac intersecia celor dou proiecii ale unei descompuneri, R1R2, este sau conine o cheie a uneia dintre componentele R1 sau R2, atunci descompunerea este fr pierdere de informaie, lucru verificat prim existena cel puin uneia dintre dependenele: (R1R2) R1 (R1-R2) respectiv (R1R2) R2 (R2-R1) Din formularea teoremei de mai sus se constat c proprietatea de conservare a informaiei depinde nu numai de descompunerea , ci i de setul iniial de dependene funcionale existente n schema de relaie R. Exemplu: Fie schema de relaie: R(Contract, Manager, Angajat) cu urmtoarele ipoteze: pentru fiecare contract exist un singur manager, rezult dependena funcional: Contract Manager, fiecare angajat are un singur manager, rezult dependena funcional: Angajat Manager, un manager poate conduce mai multe contracte; un angajat poate lucra la mai multe contracte, dintre cele conduse de managerul su. S considerm urmtoarea descompunere a schemei R: Rl (Contract, Manager), R2(Manager, Angajat). Dac se face cuplarea dintre Rl i R2 dup atributul Manager se obine o relaie n care angajaii figureaz n cadrul tuturor contractelor conduse de managerul lor, deci vor figura i n cadrul unor contracte la care nu lucreaz de fapt. n consecin prin apariia unor tuple suplimentare n rezultatul cuplrii dintre Rl i R2 s-a pierdut informaia referitoare la contractul (contractele) la care lucreaz fiecare angajat. Descompunerea lui R n Rl i R2 se face deci cu pierdere de informaie. Acest lucru se poate verifica i cu ajutorul teoremei mai sus enunate. ntr-adevr avem: R1 R2=Manager, Rl-R2=Contract, R2-Rl=Angajat, dar niciuna dintre dependenele funcionale Manager Contract sau Manager Angajat nu este verificat. Dac se introduce restricia ca un manager s conduc doar un singur contract, ceea ce implic dependena funcional: Manager Contract, atunci este uor de verificat faptul c

descompunerea lui R n Rl i R2 se face fr pierdere de informaie. Din acest exemplu se poate constata ca aceeai descompunere poate s fie sau nu cu pierdere de informaie i acest lucru depinde de setul de dependene funcionale din schema de relaie iniial. Conservarea dependenelor se refer la proprietatea unei descompuneri de a permite deducerea tuturor dependenelor din relaia iniial pe baza dependenelor existente n descompunere. Fie R o schem de relaie i ={R1,R2.....Rk} o descompunere a sa. O parte dintre dependenele funcionale existente n R se vor regsi n cadrul schemelor de relaie Ri din descompunerea sa. Alte dependene, care implic atribute din componente diferite Ri i Rj ale descompunerii, nu vor putea fi regsite n cadrul schemelor individuale Ri, deci se pierd (de fapt se transform n dependene inter-relaii). Totui acestea ar putea fi deduse din dependenele funcionale rmase folosind axiomele lui Armstrong. Dac nchiderea tranzitiv a dependenelor funcionale din schemele de relaie ale descompunerii include toate dependenele funcionale din schema de relaie iniial R, atunci se spune c descompunerea are proprietatea de conservare a dependenelor. Practic pentru a verifica condiia de conservare a dependenelor funcionale este suficient s putem deduce din dependenele funcionale rmase n descompunere acele dependene funcionale din schema de relaie iniial care s-au pierdut prin procesul de descompunere. Conservarea dependenelor unei scheme de relaie este important din punctul de vedere al integritii bazei de date. Aceasta pentru c dependenele din cadrul unei scheme de relaie R pot fi privite ca nite constrngeri de integritate a datelor din cadrul schemei. De aceea dac se nlocuiete schema R printr-o descompunere a sa care nu conserv toate dependenele, este posibil ca n urma cuplrii valorilor actuale ri (relaii) ale componentelor Ri s rezulte o relaie r care nu respect constrngerile de integritate ale schemei R. Acest fenomen poate s apar n urma unor operaii de actualizare a datelor din cadrul unor scheme Ri, cu respectarea constrngerilor impuse de schema Ri, care ns nu garanteaz respectarea tuturor constrngerilor din R, dect n condiiile n care descompunerea are proprietatea de conservare a dependenelor. Exemplu: Fie schema de relaie: Telefoane(Jude, Ora, Prefix) n cadrul creia putem identifica urmtoarele dependene funcionale: - Jude Ora Prefix deoarece fiecrui ora i corespunde un prefix al numerelor de telefoane (este important de remarcat c nu exist dependena Ora Prefix pentru c exist n judee diferite orae avnd acelai nume); - Prefix Jude semnificnd faptul c acelai prefix nu este folosit pentru orae din judee diferite (de asemenea trebuie observat c dependena Prefix Ora nu exist, deoarece exist orae diferite n cadrul aceluiai jude care folosesc acelai prefix). Fie urmtoarea descompunere a schemei relaionale Telefoane: OP(Ora, Prefix) respectiv JP(Jude, Prefix). Pentru aceast descompunere se poate verifica uor c are proprietatea de cuplare fr pierdere de informaie (deci conserv coninutul de informaie din Telefoane). Observm c n cadrul schemelor OP i JP s-a conservat doar dependena: Prefix Jude i mai mult nu exist nici o cale de a deduce pe baza dependenelor din OP i JP dependena: Jude Ora Prefx

ceea ce nseamn c descompunerea schemei de relaie Telefoane n schemele OP i JP nu conserv dependenele funcionale. Din acest motiv dac se nlocuiete schema de relaie Telefoane prin schemele OP i JP apar probleme de integritate a datelor n cazul operaiilor de actualizare efectuate n cadrul schemelor OP i JP. Astfel n cazul modificrii prefixului unui ora din relaia OP nu exist posibilitatea de a verifica dac noul prefix este valid pentru judeul n care se afl oraul. Exist deci probabilitatea de a viola constrngerea impus de dependena: Jude Ora Prefix ceea ce, n cazul nostru, ar putea avea drept consecin situarea oraului n alt jude dect cel real, atunci cnd se face o cuplare ntre relaiile OP i JP dup atributul Prefix. Menionm c proprietile de conservare a informaiei i respectiv a dependenelor sunt independente ntre ele. Astfel pentru o schem de relaie R pot exista descompuneri care conserv informaia, dar nu i dependenele sau invers. Pentru realizarea unor descompuneri echivalente este evident faptul c prezint interes acele descompuneri care conserv att coninutul de informaie, ct i dependenele funcionale din relaia iniial. Dup cum s-a vzut se poate stabili dac o anume descompunere satisface fiecare dintre cele dou proprieti enunate, deci se poate testa echivalena unei descompuneri cu relaia iniial i se pot elimina acele descompuneri care nu satisfac cele dou condiii de echivalen: conservarea informaiei i conservarea dependenelor funcionale. Observaie: Cerina, destul de restrictiv, impus descompunerilor, de a conserva dependenele este o consecin a dificultii de a trata corespunztor i eficient dependenele inter-relaii.

4.4.

Forme normale

n cele artate mai sus s-a pus n eviden faptul c existena anumitor dependene n cadrul schemelor de relaie conduce la o serie de anomalii legate de operaiile uzuale de adugare, tergere i actualizare. De asemenea s-a vzut c aceste anomalii pot fi evitate dac se nlocuiesc schemele de relaie date prin altele, echivalente, n cadru! crora dependeele sunt supuse anumitor restricii. Aceste scheme de relaii echivalente poart numele de forme normale. Formele normale constituie criterii de ghidare a proiectantului bazei de date n ce privete alegerea schemelor de relaie. Regulile de normalizare sunt aplicate cu scopul de a evita anomaliile de adugare, tergere, actualizare, ct i inconsistena datelor. Efectul direct al normalizrii este reducerea redondanei datelor, redondan care constituie cauza diverselor anomalii. Datorit redondanei efectul unei operaii de adugare, tergere sau actualizare a unei valori dintr-o tupl are tendina de a se propaga i asupra altor tuple din cadrul relaiei. Prin reducerea redondanei se localizeaz efectul fiecrei operaii de actualizare la un numr ct mai restrns de tuple, ceea ce nseamn creterea gradului de independen reciproc a tuplelor. Din punctul de vedere al influenei asupra performanelor n exploatare a bazei de date, normalizarea afecteaz negativ eficiena cu care sunt rezolvate interogrile. Aceasta pentru c informaiile care ntr-o baz de date nenormalizat ar putea fi regsite ntr-o singur relaie, n cazul unei baze normalizate necesit, de cele mai multe ori, cuplarea a dou sau mai multe relaii. De aceea normalizarea este considerat necesar i util mai mult n situaiile n care operaiile de adugare, tergere i actualizare sunt frecvent utilizate. Normalizarea mbuntete integritatea datelor prin reducerea redondanei i a inconsistenei n detrimentul eficienei unor operaii de regsire a datelor. Exist mai multe nivele de normalizare a relaiilor, primele patru nivele sunt definite n termenii dependenelor funcionale, i

sunt: prima, a doua, a treia form normal i forma normal Boyce-Codd (notate FN1, FN2, FN3 i FNBC). A patra form normal (FN4) i a cincea form (FN5) normal sunt definite n termenii dependenelor multivalorice, respectiv a dependenelor de cuplare. Diferitele nivele de normalizare impun condiii din ce n ce mai restrictive asupra relaiilor. Astfel o relaie aflat pe un anumit nivel de normalizare satisface toate restriciile cerute de nivele inferioare de normalizare. Deci o relaie n FN4, este i n FN3, FN2 .a.m.d.

4.4.1. Prima form normal (FN1)

S relum schema de relaie: Furnizor(Nume, Adres, Produs, Pre) i s presupunem c atributul Adres este folosit pentru a nregistra informaii referitoare la strada, numrul i oraul unde se afl furnizorul. Aceast variant, dei aparent comod, este inacceptabil n cazul n care adresa sau componente ale sale ar trebui folosite ca i criterii de regsire i prelucrare a datelor. Dac, de exemplu, dorim lista furnizorilor dintr-un anumit ora putem avea serioase probleme: trebuie izolat numele oraului de numele strzii i de numr; mai mult schema de relaie nu ne spune nimic despre ordinea n care sunt nregistrate componentele adresei, deci s-ar putea confunda strada cu oraul i invers. Soluia care se impune este nlocuirea atributului Adres prin setul de atribute Strada, Numr i Ora, astfel nct fiecare atribut al relaiei Furnizor s ia numai valori atomice. Caracterul atomic al atributelor este totui relativ i depinde de proiectant, respectiv de nivelul de detaliere al modelrii lumii reale. n exemplul de mai sus atributul Adres ar putea fi acceptat ca atomic dac nu ne intereseaz structura sa, iar valorile pe care le conine sunt utilizate doar cu titlu informativ. Definie: O relaie R este n prima form normal (FN1) dac i numai dac toate atributele sale iau numai valori atomice. Condiia ca o relaie s fie n FN l introduce restricia ca domeniile pe care se definesc atributele relaiei R s conin doar elemente atomice, ceea ce nseamn c toate tuplele unei relaii au acelai numr de cmpuri i aceeai dimensiune. Teoria bazelor de date relaionale nu se ocup de relaii care au tuple de dimensiune variabil i aceasta este mai degrab o chestiune de definiie i mai puin de proiectare. Toate relaiile considerate ca exemple n aceast lucrare sunt n FN1.

iniiale, iar din dependenele funcionale ale componentelor se pot deduce dependenele funcionale eliminate prin descompunere. Aadar nlocuirea unei relaii printr-o descompunere a sa n relaii aflate n FN2 este un proces reversibil. Avantajul acestei nlocuiri este eliminarea unora dintre anomaliile legate de operaiile de adugare, tergere i actualizare. Exemplu: Fie schema de relaie: Profesori_note(Nume_prof, Funcie, Salar, Nume_stud, Nota) Pot fi identificate urmtoarele dependene funcionale: - Nume_prof Funcie deoarece fiecare cadru didactic are o funcie (asistent, lector .a.m.d.); - Funcie Salar pentru c salarizarea fiecrui profesor se stabilete dup funcia pe care o are; - Nume_prof Salar cu semnificaia c fiecrui profesor i corespunde o valoare a salariului; - Nume_prof Numestud Nota n ipoteza c fiecare profesor acord unui student o singur not. Aceste dependene funcionale sunt vizualizate prin diagrama din figura 4.2.
Funcie Nume_prof Nota Salar Fig.4.2. Diagrama dependenelor funcionale pentru schema de relaie: Profesori_note(Nume_prof,funcie,Salar.Numc_stud,Nota) Nume_stud

4.4.2. A doua form normal (FN2)

A doua i a treia form normal rezolv problemele cauzate de existena dependenelor funcionale dintre atributele prime (care fac parte dintr-o cheie a relaiei) i cele neprime (care nu aparin nici unei chei) din cadrul tuplelor. Trecerea unei relaii din FN1 n FN2 constituie primul pas n procesul de normalizare a relaiilor i const n eliminarea dependenelor funcionale pariale ale atributelor neprime fa de orice cheie a relaiei. Existena unor asemenea dependene pariale presupune faptul c relaia n discuie are cel puin o cheie compus din mai multe atribute. Definiie: O relaie R este n a doua form normal (FN2) dac este n FN 1 i orice atribut neprim este total dependent fa de orice cheie a relaiei. Pentru orice relaie n FN1 se poate gsi o descompunere n relaii aflate n FN2 care este echivalent cu relaia iniial. Aceasta nseamn c din relaiile descompunerii se poate reconstitui prin cuplare ntreg coninutul de informaie al relaiei

Pornind de la dependenele date se deduce c relaia Profesori_Note are o singur cheie compus, format din atributele Nume_prof i Nume_stud. Se poate observa dependena funcional a atributelor Funcie i Salar fa de atributul Nume_prof, ceea ce implic dependena parial a acestor atribute fa de cheia relaiei format din atributele Nume_prof i Nume_stud. Aceast dependen funcional parial are drept consecin o serie de anomalii: Anomalia de adugare Nu se poate nregistra un nou cadru didactic cu funcia i salariul su atta timp ct acesta nu acord cel puin o not unui student. Anomalia de tergere Dac se terge tupla corespunztoare singurei note acordate de un profesor, atunci se pierd i informaiile referitoare la funcia i salariul su. Anomalia de actualizare Se datoreaz redondanei informaiilor referitoare la funcia i salariul unui profesor care sunt nregistrate pentru fiecare not acordat de acesta. Astfel dac un profesor este avansat sau i se modific salariul este necesar cutarea tuturor tuplelor n care aceste informaii sunt nregistrate ceea ce implic parcurgerea relaiei n ntregime. n caz contrar apare riscul inconsistenei bazei de date deoarece acelai profesor ar putea ti nregistrat cu funcii i salarii diferite n tuple diferite. Anomaliile prezentate se pot elimina nlocuind schema de relaie Profesori_note prin dou proiecii ale sale, Profesori i Note date prin schemele de relaie: Profesori(Nume_prof, Funcie, Salar) avnd cheia Nume i Note(Nume_prof, Nume_Stud, Nota) avnd o cheie compus format din atributele Nume_prof i Nume_stud.

Dependenele funcionale pentru cele dou scheme de relaie Nu se poate nregistra valoarea salariului care corespunde unei sunt vizualizate prin diagramele din figura 4.3. anumite funcii atta timp ct nu exist n relaie cel puin un cadru didactic avnd funcia respectiv. Profesori Note Anomalia de tergere Dac se terge tupla corespunztoare singurului cadru didactic Funcie cu o anumit funcie se pierde informaia referitoare la salariul Nume_prof Nume_prof Nota corespunztor funciei respective. Nume_stud Anomalia de actualizare Salar Se datoreaz redondanei informaiei referitoare la salariul Fig.4.3. Dependenele funcionale pentru schemele de relaie: corespunztor unei funcii date, salariu a crei valoare este Profesori(Nume_prof,Funcie,Salar), Note(Nume_prof,Nume_stud,Nota) nregistrat pentru fiecare cadru didactic avnd funcia respectiv. Dac se modific salariul corespunztor unei funcii date atunci Relaiile Profesori i Note sunt n FN2 pentru c relaia trebuie parcurs ntreaga relaie Profesori pentru a modifica Profesori are o cheie format dintr-un singur atribut (deci nu pot aceast valoare n toate tuplele n care apar cadre didactice avnd exista dependene funcionale pariale fa de aceast cheie), iar n aceast funcie. n caz contrar exist riscul de a introduce o relaia Note atributul Nota este dependent funcional total fa de inconsisten n baza de date ca urmare a faptului c ar putea s cheia format din atributele Nume_prof i Nume_stud. apar cadre didactice avnd aceeai funcie, dar salarii diferite. Se poate verifica cu uurin c prin nlocuirea relaiei Aceste anomalii pot fi eliminate prin descompunerea relaiei Profesori_note cu descompunerea sa format din relaiile n FN2 Profesori n relaiile NF i FS date prin schemele: Profesori i Note se elimin anomaliile mai sus prezentate. NF(Nume_prof, Funcie) FS(Funcie, Salar) Conservarea coninutului de informaie rezult din corolarul cu cheia Nume_prof, respectiv cu cheia Funcie. teoremei lui Ullman, deoarece: ProfesoriNote=Nume_prof, NF FS iar atributul Nume_prof este cheie n relaia Profesori. Nume_prof Salar Nume_prof Funcie Condiia de conservare a dependenelor este de asemenea verificat deoarece prin descompunere nu se pierde nici una Fig.4.4. Dependenele funcionale pentru schemele de relaie: dintre dependenele funcionale existente n relaia NF(Nume_prof, Funcie) i FS(Funcie, Salar). Profesori_note. Dependenele funcionale dintre atributele acestor relaii sunt Mai observm c descompunerea relaiei Profesori_note n relaiile Profesori i Note corespunde principiului intuitiv date prin diagramele din figura 4.4. Relaiile NF i FS sunt n FN3 i elimin toate anomaliile conform cruia orice proces de normalizare urmrete separarea informaiilor n aa fel nct o relaie s reprezinte un singur tip de datorate existenei dependenelor funcionale dintre atribute entitate sau o legtur ntre dou tipuri de entiti, n cazul nostru neprime. De asemenea se poate arta c descompunerea relatiei fiind voiba de tipul de entitate profesori i de legtura note dintre Profesori n relaiile NF i FS este echivalent, ceea ce nseamn c se poate reconstitui coninutul de informaie (atributul Funcie profesori i studeni. este intersecia dintre NF i FS i este cheie n relaia FS) i setul de dependene funcionale ale relaiei Profesori din dependenele 4.4.3. A treia form normal (FN3) relaiilor NF i FS (prin aplicarea axiomei de tranzitivitate, A3, Trecerea unei relaii n FN3 are ca scop eliminarea asupra dependenelor funcionale: Nume_prof Funcie i dependenelor funcionale ale atributelor neprime fa de orice alt Funcie Salar, se deduce dependena: Nume_prof Salar). atribut neprim al relaiei. Descompunerea relaiei Profesori n cele dou componente Definiie: ale sale NF i FS pune n eviden faptul c separarea coninutului O relaie R este n a treia form normal (FN3) de informaie realizat prin trecerea la FN2 nu a fost complet. dac este n FN2 i nici un atribut neprim nu este ntr-adevr relaia Profesori conine dou tipuri de informaii funcional dependent fa de un alt atribut neprim al distincte: relaiei. - funcia corespunztoare fiecrui cadru didactic ntr-o relaie care este n FN3 un atribut neprim poate s - salariul corespunztor fiecrei funcii. depind funcional doar de cheile din relaia respectiv, deoarece Separarea complet este realizat prin descompunerea relaiei nici un atribut neprim nu poate fi dependent funcional fa de un Profesori n componentele sale NF i FS. atribut prim (simplu sau compus) dac acesta nu este cheie sau nu conine o cheie (condiia FN2) i nici fa de un alt atribut 4.4.4. Forma normal Boyce-Codd neprim. (FNBC) Ca i n cazul trecerii la FN2 se poate demonstra faptul c pentru orice relaie n FN2 exist o descompunere echivalent n Att FN2 ct i FN3 se caracterizeaz prin faptul c izoleaz componente aflate n FN3, deci procesul de trecere al unei relaii dependenele funcionale ale atributelor neprime, deci ale acelor n FN3 este reversibil. Aceast descompunere elimin o serie de atribute care nu fac parte din nici o cheie, fr a lua n considerare anomalii, cauzate de existena dependenelor funcionale dintre dependenele funcionale ale atributelor ce aparin unor chei atribute neprime, anomalii care se manifest la relaiile n FN2 n (atribute prime). Exist o alt form normal care trateaz n mod cazul operaiilor de adugare, tergere i actualizare. unitar toate atributele unei relaii indiferent de faptul c fac sau nu Exemplu: parte dintr-o cheie. Aceasta este forma normal Boyce-Codd Relaia Profesori din exemplul precedent prezint o serie de (FNBC) denumit astfel dup numele cercettorilor care au anomalii cauzate de existena dependenei funcionale dintre definit prima dat aceast form normal. FNBC stabilete cele atributele neprime Funcie i Salar: mai restrictive condiii care pot fi impuse unei relaii n termenii Anomalia de adugare dependenelor funcionale. Definiie:

O relaie R este n forma normal Boyce-Codd (FNBC) dac pentru orice dependen funcional X A din cadrul relaiei R, unde A este un atribut care nu face parte din X, atributul (posibil compus) X este o cheie n R sau include o cheie din R. Cu alte cuvinte, definiia dat precizeaz faptul c ntr-o relaie R care se afl n FNBC singurele dependene funcionale admise sunt cele n care o cheie determin un alt atribut. Nici un atribut prim sau neprim nu poate fi dependent funcional fa de un alt atribut dac acesta nu este sau nu conine o cheie. Este uor de artat c o relaie aflat n FNBC este n FN3 i deci i n FN2 sau FN1. Aceasta pentru c definiia dat pentru FNBC elimin posibilitatea existenei att a dependenelor funcionale pariale ct i a dependenelor fa de atribute neprime, att pentru atributele neprime ct i pentru cele prime. nseamn c prin trecerea unei relaii n FNBC se evit toate anomaliile care se pot elimina prin trecerea aceleiai relaii n FN2 i FN3. n schimb nu orice relaie n FN3 este n FNBC, iar relaiile aflate n FN3 pot prezenta anumite anomalii care se elimin prin trecerea la FNBC. Definiiile pentru FN3 i FNBC sunt echivalente doar n cazul n care relaia iniial R care se descompune are o singur cheie. Deosebirile ntre cele dou forme normale pot fi puse n eviden la acele relaii care au cel puin dou chei. Pentru aceste relaii este posibil ca trecerea n FN3 s nu nsemne automat trecerea i n FNBC. Din nefericire pentru o relaie dat R nu exist ntotdeauna o descompunere echivalent n relaii aflate n FNBC. Astfel se poate demonstra c dei exist ntotdeauna o descompunere n relaii aflate n FNBC care are proprietatea de cuplare fr pierdere de informaie (deci care conserv coninutul de informaie), este posibil s nu existe nici o descompunere care s conserve dependenele funcionale ale relaiei R. Aadar n anumite cazuri descompunerea unei relaii n componente aflate n FNBC se poate realiza doar cu preul pierderii unor dependene funcionale, deci procesul nu este ntotdeauna reversibil. Rezult c FNBC este, n anumite situaii, prea restrictiv prentru a putea fi aplicat n procesul de normalizare. n aceste situaii se folosete FN3 care elimin aproape toate anomaliile pe care le elimin FNBC i asigur totodat posibilitatea de conservare a dependenelor funcionale. Exemple: 1. Pentru exemplificarea afirmaiilor de mai sus s relum o schem de relaie prezentat n paragraful 4.3.: Telefoane(Jude, Ora, Prefix) cu dependenele funcionale: Jude Ora Prefix Prefix Jude, care sunt prezentate n figura 4.5.
Jude Ora Prefix

Fig.4.5. Diagrama dependenelor funcionale pentru Telefoane(Jude,Ora,Prefix).

Aceast relaie are dou chei: - o cheie format din atributele Jude i Ora, care mpreun determin funcional atributul Prefix (este o consecin a dependenei funcionale Jude Ora Prefix), - a doua cheie format din atributele Prefix i Ora care mpreun determin funcional atributul Jude (consecin a dependenei funcionale Prefix Jude care implic dependena funcional Prefix Ora Jude). Aceast relaie nu este n FNBC deoarece atributul Jude este dependent funcional fa de atributul Prefix, iar acesta nu este i

nici nu conine o cheie, n schimb aceast relaie este n FN3, n ciuda dependenei Preflx->Jude, deoarece Jude este un atribut prim, parte a cheii formate din atributele Judei Ora. Relaia Telefoane, dei este n FN3, prezint unele anomalii; de exemplu nu se poate nregistra prefixul destinat folosirii pe teritoriul unui anumit jude pn nu se cunoate cel puin un ora pentru care se va folosi acest prefix. Relaia Telefoane se poate descompune n relaiile OP i JP date prin schemele relaionale: OP(Ora, Prefix) avnd cheia format din atributele Ora i Prefix, JP(Jude, Prefix) avnd cheia Prefix. Este uor de verificat faptul c relaiile OP i JP sunt ambele n FNBC. Dup cum s-a artat n paragraful 4.3., descompunerea relaiei Telefoane n relaiile OP i JP conserv coninutul de informaie, dar nu conserv dependenele funcionale. Prin descompunere se pierde dependena: Jude Ora Prefix i este uor de verificat c orice alt descompunere a relaiei Telefoane are drept consecin pierderea acestei dependene funcionale. Din acest motiv este, poate, mai convenabil s se renune la descompunerea relaiei Telefoane, deoarece anomaliile prezentate de aceasta sunt mai puin grave dect problemele de inconsisten cauzate de pierderea dependenei funcionale amintite. De altfel trebuie remarcat c, de cele mai multe ori, dependenele funcionale care satisfac FN3, dar care violeaz condiiile impuse de FNBC sunt irelevante pentru proiectarea bazei de date. Astfel n exemplul considerat dependena Prefix Jude indic prefixele folosite pe teritoriul unui jude, informaie care este nerelevant pentru baza de date considerat deoarece prefixele sunt asociate oraelor din judee i nu judeelor. Deci am putea s renunm la aceast dependen caz n care relaia Telefoane este n FNBC (deoarece este n FN3 i are o singur cheie). 2. S considerm o variant modificat a relaiei Note dat de urmtoarea schem de relaie: Note(Nume_prof, Disciplina, Nume_stud, Nota) cu urmtoarele ipoteze: fiecare profesor pred doar o singur disciplin, ceea ce implic dependena: Nume_prof Disciplina fiecare profesor acord o singur not unui student, rezult dependena: Nume_prof Nume_stud Nota, fiecare student obine o singur not la o disciplin dat, rezult dependena: Disciplina Nume_stud Nota, fiecare student studiaz o anumit disciplin cu un singur profesor, rezult dependena: Disciplina Nume_stud Nume_prof. Din primele dou dependene de mai sus rezult c atributele Nume_prof i Nume_stud formeaz o cheie n relaia Note, iar din ultimele dou dependene rezult c atributele Disciplina i Nume_stud formeaz o a doua cheie n relaia Note. Relaia Note este n FN3 n ciuda dependenei funcionale pariale a atributului Disciplina fa de cheia format din atributele Nume_prof i Nume_stud, deoarece acest atribut aparine celei de-a doua chei a relaiei, deci este un atribut prim. n schimb aceast relaie nu este n FNBC tocmai din cauza dependenei Nume_prof Disciplina, deoarece atributul Nume_prof este cheie n relaia Note. Relaia Note prezint o serie de anomalii cum ar fi aceea legat de imposibilitatea de a nregistra disciplina predat de un profesor pn cnd acesta nu acord cel puin o not vreunui student.

Relaia Note se poate descompune n relaiile PD i PSN date prin schemele: PD(Nume_prof, Disciplina) care are cheia Nume_prof, PSN(Numej>rof, Nume stud, Nota) care are cheia Nume_prof Nume_stud. Se poate verifica faptul c relaiile PD i PSN sunt n FNBC i c descompunerea elimin anomalia prezentat precum i alte anomalii de acelai gen. Descompunerea are proprietatea de cuplare fr pierdere de informaie deoarece: PDPSN=Nume_prof i Nume_prof este cheie n relaia PD (vezi corolarul teoremei lui Ullman). Descompunerea nu are proprietatea de conservare a dependenelor funcionale. Pentru aceasta este suficient s observm c din dependenele existente n PD i PSN nu avem posibilitatea s deducem nici una dintre dependenele: Disciplina Nume_stud Nota, Disciplina Nume_stud Nume_prof.

4.5.

Dependene multivalorice

Dependenele funcionale nu sunt singurele tipuri de dependene care apar n cadrul relaiilor. Att n lumea real ct i n relaiile prin care modelm realitatea pot fi identificate alte tipuri de dependene mai puin restrictive dect cele funcionale. Un asemenea tip de dependene cu implicaii n normalizarea relaiilor sunt dependenele multivalorice. Fie schema de relaie R(X,Y,Z), unde X, Y i Z sunt atribute simple sau compuse. n cele ce urmeaz vom nota prin x, y i z (eventual cu indici) valori ale atributelor X, Y respectiv Z. Definiie: Spunem c exist o dependen multivaloric a atributului Z fa de Y sau c Y multidetermin pe Z, i notm Y Z, dac pentru orice valori x1, x2, y, z1 i z2, x1 x2, z1 z2, astfel nct tuplele (x1,y,z1) i (x2,y,z2) fac parte din relaia R, atunci i tuplele (x1,y,z2) i (x2,y,z1) fac parte din relaia R. Din simetria definiiei de mai sus rezult c dependena multivaloric: Y Z implic i dependena multivaloric complementar: Y X. Fie: Zy={z|(x,y,z)R} i Xy={x|(x,y,z)R}. Notaiile Zy i Xy reprezint mulimile de valori ale atributului Z, respectiv X, cu care o valoare dat y a atributului Y intr n combinaie pentru a forma tuple ale relaiei R. Intuitiv, definiia de mai sus arat c o valoare dat y a atributului Y formeaz o tupl cu fiecare pereche de valori (x,z) din produsul cartezian al mulimilor Xy i Zy. Aceasta nseamn c mulimile Xy i Zy sunt independente ntre ele. O consecin important a acestei independene, util n recunoaterea dependenelor multivalorice, este faptul c dac exist o dependen multivaloric de forma Y Z, mpreun cu dependena complementar Y X, atunci ntre atributele X i Z sau componente ale acestora nu poate exista nici un fel de dependen funcional. Orice dependen funcional este, prin definiie, i o dependen multivaloric. Astfel, ntr-un anumit sens, dependenele multivalorice generalizeaz dependenele funionale. Este posibil ca unul dintre seturile de atribute X sau Z s fie o mulime vid, caz n care dependena complementar Y Z, respectiv Y X se menine, dar este nerelevant pentru relaia dat deoarece nu aduce nici o informaie n plus. Exemplu:

Fie relaia numit Agenii care cuprinde ageniile matrimoniale dintr-un ora, dat prin urmtoarea schem de relaie: Agenii(Nume agenie, NumeF, Nume B). Pentru fiecare agenie se nregistreaz n atributele NumeF i NumeB numele femeilor, respectiv al brbailor care apar n evidenele ageniei n cauz. Existena dependenei multivalorice: Nume agenie NumeF i implicit a dependenei complementare: Nume agenie NumeB presupune faptul c pentru o agenie dat numele oricrei femei din evidena acelei agenii este asociat cu numele fiecrui brbat care a apelat la aceeai agenie. In aceste condiii relaia Agenii ne poate furniza lista cuplurilor maritale probabile din ora ca urmare a activitii ageniilor matrimoniale. Este evident faptul c o femeie i un brbat formeaz un cuplu probabil numai dac au apelat la aceeai agenie. Se observ cu uurin faptul c relaia Agenii poate fi privit ca rezultatul cuplrii dup atributul Nume_agenie a dou relaii de forma: AF(Nume agenie, NumeF) AB(Nume_agenie, NumeB). Un aspect important legat de dependenele multivalorice este senzitivitatea fa context ale acestora. Pentru a stabili existena unei dependene Y Z trebuie s lum n considerare i atributul complementar X mpreun dependenele, funcionale ori multivalorice, dintre acesta i atributele Y, respectiv Z. Exemplu: Fie schema de relaie: Aprovizionare(Beneficiar, Furnizor, Produs, Pre) prin care se dorete reprezentarea posibilitilor de aprovizionare a unor beneficiari. Fiecare beneficiar se poate aproviziona de la mai muli furnizori, dar ia n considerare numai pe aceia care furnizeaz toat gama de produse care l intereseaz. n lipsa atributului Pre din schema de relaie dat, pe baza ipotezelor de mai sus s-ar putea deduce dependenele multivalorice: Beneficiar Furnizor Beneficiar Produs. n prezena atributului Pre dependenele care se manifest depind de legturile acestuia cu celelalte atribute. Dac preul unui produs este acelai pentru toi furnizorii, deci avem dependena funcional: Produs Pre, atunci dependenele multivalorice din relaia Aprovizionare sunt: Beneficiar Furnizor Beneficiar Produs Pre. Dac, ns, preul unui produs difer de la un furnizor ia altul, atunci avem dependena funcional: Furnizor Produs Pre, caz n care singura dependen multivaloric posibil este: Beneficiar Furnizor Produs Pre, i care este nerelevant pentru relaia n cauz. Ca i n cazul dependenelor funcionale, atunci cnd se d un set de dependene multivalorice (n particular unele dintre acestea ar putea fi dependene funcionale) putem folosi un set de reguli pentru a determina sistematic toate dependenele multivalorice (i funcionale) care sunt o consecin logic a setului iniial. Aceste reguli sunt axiomele lui Armstrong pentru dependene funcionale i multivalorice; ele sunt o extensie a axiomelor lui Armstrong pentru dependenele funcionale. Fie X,Y i Z submulimi ale mulimii de atribute U={Al,A2,...,An}. Axiomele lui Armstrong pentru dependenele funcionale i multivalorice se pot formula astfel:

Al: (reflexivitate pentru dependenele funcionale) Dac YX, atunci X Y. A2: (augmentare pentru dependenele funcionale) Dac X Y, atunci XZ YZ. A3: (tranzitivitate pentru dependenele funcionale) Dac X Y i Y Z, atunci X Z. A4: (complementare pentru dependenele multivalorice) Dac X Y, atunci X U-(XY), unde U-(XY) este atributul complementar lui Y n raport cu atributul X. Aceast regul deriv din caracterul simetric al dependenelor multivalorice. A5: (augmentare pentru dependenele multivalorice) Dac X Y i VW, atunci WX VY. A6: (tranzitivitate pentru dependenele multivalorice) Dac X Y i Y Z, atunci X Z-Y. Ultimele dou axiome pun n legtur dependenele funcionale i cele multivalorice. A7: Dac X Y, atunci X Y. Aceast regul exprim faptul, menionat anterior, c orice dependen funcional este, n acelai timp, o dependen multivaloric. A8: Dac X Y, ZY i pentru W disjunct fa de Y avem: W Z, atunci X Z. Axiomele A1-A8 constituie un set complet i sigur de reguli de inferen n sensul c permit deducerea tuturor dependenelor (funcionale i multivalorice) i numai ale acelora care sunt logic deductibile din setul iniial de dependene. Aceasta nseamn c orice relaie care satisface setul iniial de dependene va satisface de asemenea orice dependen din nchiderea tranzitiv a acestui set.

Proprietatea de conservare a dependenelor este satisfcut dac din dependenele funcionale i multivalorice existente n descompunere se pot deduce toate dependenele att funcionale, ct i multivalorice folosind setul de axiome A1A8.(paragraful4.5.) Exemplu: Fie schema de relaie: Cursuri(Profesor, Disciplin, Limb) care conine informaii referitoare la cursurile i limbile strine n care ar putea fi susinute aceste cursuri de ctre un anumit colectiv de profesori. Se presupune c un profesor cunoate mai multe limbi strine i c ar putea susine cursuri pentru mai multe discipline. Mai mult este de ateptat ca un profesor care susine un anumit curs s poat face acest lucru n oricare dintre limbile strine pe care le cunoate. n aceste condiii n cadrul schemei de relaie Cursuri avem urmtoarele dependene muitivalorice: Profesor Disciplin Profesor Limb, iar atributele Disciplin i Limb sunt independente. O posibil instaniere a schemei de relaie Cursuri este dat de relaia din figura 4.6. Profesor Disciplina Limb Pop Programare Englez Costea Baze de date Englez Costea Baze de date Francez Costea Baze de date German Costea Limbaje Englez Costea Limbaje Francez Costea Limbaje German Popovici Programare Francez Popovici Programare German Relaia Cursuri are o singur cheie format din atributele Profesor, Disciplin i Limb. Nici un atribut nu depinde funcional de un alt atribut al relaiei ceea ce nseamn c relaia Cursuri n FNBC. Aceast relaie nu este ns n FN4, ca urmare a dependenelor muitivalorice artate, ceea ce implic un mare grad de redondan a datelor, dup cum se poate observa i n tabelul din figura 4.6., ct i unele anomalii legate de operaiile de adugare, tergere i actualizare. Anomalia de adugare Dac profesorul Costea accept s in cursuri i pentru disciplina Programare, atunci trebuie introdus cte o tupl pentru fiecare limb strin pe care o cunoate acesta. Anomalia de tergere tergerea tuplelor referitoare la singura disciplin predat de un anumit profesor conduce la pierderea informaiilor referitoare la limbile strine pe care acesta le cunoate. Anomalia de actualizare Orice operaie de actualizare presupune, de regul, modificarea a mai multor tuple i parcurgerea ntregii relaii, n caz contrar existnd riscul introducerii unor incosistene. Aceste anomalii se pot elimina prin descompunerea relaiei Cursuri n relaiile PD i PL date prin schemele: PD(Profesor, Disciplin) avnd cheia Profesor Disciplin, PL(Profesor, Limb) avnd cheia Profesor Limb. Relaia PD este n FN4 n ciuda dependenei Profesor Disciplin, unde Profesor nu este cheie n PD, dar ProfesorDisciplin conine toate atributele din PD (vezi definiia pentru FN4). Raionamentul este analog pentru relaia PL. Verificarea faptului c descompunerea conserv coninutul de informaie al relaiei iniiale se poate face folosind extinderea la dependenele muitivalorice a teoremei lui Ullman, avem: PDPL=Profesor,
Fig.4.6 Posibil instanere a relaiei cursuri

4.6.

A patra form normal

A patra form normal vizeaz problemele legate de existena dependenelor multivalorice. Dependenele multivalorice din cadrul unei relaii pot cauza anomalii de aceeai natur ca cele cauzate de dependenele funcionale. Trecerea unei relaii n a patra form normal (FN4) urmrete eliminarea dependenelor multivalorice i a anomaliilor cauzate de acestea. FN4 este o generalizare a FNBC pentru a cuprinde i cazul dependenelor multivalorice. Definiie: O relaie R este n a patra form normal (FN4) dac oricare ar fi dependena multivaloric X Y, unde Y nu este un subset a lui X i XY nu conine toate atributele lui R, atunci atributul (simplu sau compus) X este o cheie sau conine o cheie a lui R. Datorit faptului c orice dependen funcional este un caz particular de dependen multivaloric, din definiia dat rezult c FN4 impune condiii mai restrictive asupra relaiilor dect FNBC, ceea ce nseamn c orice relaie care este n FN4 este i n FNBC. Procesul de transformare al unei relaii ntr-o colecie de componente aflate n FN4 este analog cu trecerea n FNBC, dar avnd n vedere att dependenele funcionale ct i cele multivalorice. Ca i n cazul FNBC pentru orice relaie R exist o descompunere n relaii n FN4 care satisface condiia de cuplare fr pierdere de informaie, dar nu ntotdeauna exist o descompunere care s satisfac condiia de conservare a dependenelor funcionale sau multivalorice. Teorema lui Ullman se extinde i asupra dependenelor multivalorice (se substituie peste tot simbolul " " prin " ") i permite verificarea proprietii de conservare a coninutului de informaie n cazul descompunerii unei relaii n dou componente.

PD-PL=Disciplin, Proiect Angajat Salar din relaia R2 ne conduce la PL-PD=Limb, descompunerea: i este suficient una dintre dependenele: Profesor Disciplin sau Profesor Limb. R3(Proiect, Angajat, Salar) Pentru exemplul prezentat se poate verifica cu uurin faptul R4(Proiect, Furnizor, Produs, Localitate, Director). c se conserv i dependenele iniiale. Folosind n continuare dependena: Angajat Salar din relaia R3, aceasta se descompune n: R5(Angajat, Salar) R6(Angajat, Proiect). 4.7. Exemplu de normalizare La rndul ei relaia R4 se descompune, folosind dependena Pentru a ilustra procesul de normalizare s considerm funcional: Proiect Director, astfel: urmtoarea schem de relaie: R7(Proiect, Director) R(Proiect, Produs, Furnizor, Localitate, Cost, Angajat, R8(Proiect, Furnizor, Produs, Localitate). Director, Salar), cu urmtoarele dependene funcionale i n sfrit, relaia R8 se descompune, folosind dependena muitivalorice: funcional: Furnizor Localitate, astfel: Furnizor Produs Cost R9(Fumizor, Localitate) R10(Furnizor, Proiect, Produs). Proiect Director Descompunerea relaiei R const deci din urmtoarele Angajat Salar componente aflate n Furnizor Localitate R1(Furnizor, Produs, Cost) Proiect Angajat Salar. R5(Angajat, Salar) R6(Angajat, Proiect) Observaie: R7(Proiect, Director) Dependena multivaloric Proiect Angajat nu poate avea R9(Furnizor, Localitate) loc din cauza dependenei funcionale Angajat Salar, deci R10(Furnizor, Proiect, Produs). dependena corect este Proiect Angajat Salar. Descompunerea obinut este echivalent cu relaia iniial R. regul: ntr-adevr coninutul de informaie se conserv datorit regulii Procesul de normalizare se poate realiza aplicnd repetat dup care s-a fcut descompunerea la fiecare pas. n cazul nostru urmtoarea se conserv i dependenele deoarece, aa cum lesne se poate Dac n relaia R(X,Y,Z) avem o dependen funcional, verifica, la fiecare pas de descompunere este satisfcut condiia X Y sau multivaloric, X Y, atunci R se poate descompune ca ntre atributele care trec n relaii diferite s nu existe nici un n relaiile R1(X,Y) i R2(X,Z) fr pierdere de informaie. Dac fel de dependen. ntre atributele Y i Z (sau componente ale acestora) nu exist nici un fel de dependen, atunci descompunerea are i 4.8. Dependene de cuplare i a proprietatea de conservare a dependenelor. Relaia original R este rezultatul cuplrii naturale a lui R1 i cincea form normal R2 dup atributul X. Pn acum trecerea de la o form normal la alta s-a fcut prin Descompunerea conform regulii de mai sus const n izolarea descompunerea unei relaii n altele dou, urmrindu-se dependenei funcionale X Y sau multivalorice X Y. Dac eliminarea dependenelor funcionale i multivalorice. O relaie n cadrul atributelor X i Y nu exist nici un fel de alte aflat n forma normal patru nu mai poate fi descompus n dependene, atunci relaia R1 este n FN4. continuare pe baza acestei strategii. Cu toate acestea sunt situaii Descompunerea conserv coninutul de informaie deoarece: cnd relaii aflate n FN4 conin redondane i prezint anomalii X=R1R2 i X este cheie n R1. (vezi corolarul teoremei lui la operaiile de adugare, tergere i actualizare. Aceste probleme Ullman) sunt cauzate de existena dependenelor de cuplare i pot fi Conservarea dependenelor este garantat de condiia ca ntre eliminate prin descompunerea relaiei n 3 sau mai multe relaii a atributele Y i Z s nu existe nici un fel de dependen, (doar cror cuplare are ca rezultat relaia iniial. Se spune c o relaie acestea s-ar putea pierde prin descompunere!) Condiia este este n-decompozabil dac poate fi descompus fr pierdere de suficient, dar nu necesar. informaie n n componente, dar nu mai puine. Prin eliminarea n concluzie descompunerea unei relaii n componente FN4 dependenelor de cuplare se obin relaii aflate n forma normal se poate realiza aplicnd repetat regula de mai sus, deci izolnd, cinci (FN5). Trecerea la FN5 este un proces de normalizare care una cte una, depedenele funcionale sau multivalorice din relaia se aplic relaiilor n-decompozabile cu n>2. dat. Ordinea n care se izoleaz dependenele nu are influen asupra rezultatului final. Descompunerea conserv coninutul de 4.8.1. Dependene de cuplare informaie al relaiei iniiale, dar s-ar putea s nu conserve Eliminarea dintr-o relaie a dependenelor funcionale i dependenele. multivalorice nu garanteaz rezolvarea tuturor problemelor legate Pe baza primei dependene funcionale descompunem relaia de redondana datelor. Aa cum se va constata din exemplul R n: urmtor o relaie aflat n FN4 poate conine redondane ce R1(Fumizor, Produs, Cost) R2(Furnizor, Produs, Proiect, Localitate, Angajat, Director, conduc la apariia de anomalii. Exemplu: Salar). Fie schema de relaie: De remarcat faptul c ntre atributele Cost i Proiect PDL(Profesor, Disciplin, Limb) Localitate Angajat Director Salar nu exist nici un fel de care se refer la cursurile efectiv predate de ctre fiecare profesor dependen. Relaia R1 este n FN4, n timp ce R2 nu satisface aceast i limba n care acesta pred fiecare curs. Spre deosebire de relaia Cursuri din paragraful 4.6., aici atributele Disciplin i condiie i urmeaz a fi descompus n continuare. Limb nu sunt independente ntre ele, deoarece cursurile i Dependena multivaloric: limbile n care sunt predate aceste cursuri de ctre fiecare

profesor pot depinde de o serie de factori, cum ar fi de exemplu solicitrile studenilor. Prin urmare nu este necesar ca un profesor s predea un anumit curs n toate limbile pe care le cunoate, dei acest lucru ar fi posibil. Rezult c n cadrul schemei de relaie PDL dependenele multivalorice: Profesor Disciplin Profesor Limb, nu au loc, ceea ce nseamn c relaia PDL este n FN4. Profesor Disciplin Limb Pop Programare Englez Costea Baze de date Englez Costea Baze de date Francez Costea Limbaje Englez Costea Limbaje German Miron Limbaje Englez Popovici Programare Francez O posibil, instaniere a schemei de relaie PDL este dat de relaia din figura 4.7. Dei este n FN4, relaia din figura 4.7. conine mai multe redondane. Astfel aflm din cte dou tuple distincte faptul c profesorul Costea pred disciplinele "Baza de date" i "Limbaje", respectiv c este cunosctor al limbii engleze. Aceste redondane pot conduce, de exemplu, la anomalii de actualizare. Dac se constat c n cazul profesorului Costea s-a introdus n mod eronat disciplina "Limbaje" n locul disciplinei "Sisteme de operare", atunci n relaia PDL vor trebui s fie modificate mai multe tuple, fr a tii, n principiu, cte sunt acestea, operaie care necesit parcurgerea ntregii relaii. Pe de alt parte, relaia PDL nu poate fi nicicum descompus n dou componente din a cror cuplare s rezulte relaia iniial. n figura 4.8. sunt reprezentate toate proieciile posibile pe cte dou atribute ale acestei relaii. Analiznd toate posibilitile de descompunere netrivial a relaiei PDL n dou componente constatm urmtoarele: descompunerea relaiei PDL n PD i PL se face cu pierdere de informaie, deoarece la cuplarea relaiilor PD i PL apar tuple parazite cum ar fi (Costea Limbaje Francez), deci (De fapt, s observm c n caz de egalitate ar trebui s avem dependenele: Profesor Disciplin i Profesor Limb, ceea ce aa cum am artat mai sus nu este cazul); analog se observ c: PDL PD >< DL i PDL PL >< DL Din cele de mai sus rezult c nu exist nici o descompunere n dou componente a relaiei PDL astfel nct s se respecte condiia de conservare a informaiei, deci relaia PDL nu este 2-decompozabil. Mai mult, n lipsa unor ipoteze suplimentare, nu se poate stabili, n general, dac relaia PDL este 3-, 4-sau ndecompozabil. Totui, relaia PDL se dovedete a fi 3decompozabil dac este satisfcut urmtoarea constrngere: Dac o anumit disciplin este predat ntr-o anumit limb, atunci acest lucru este fcut de fiecare profesor care pred disciplina respectiv i cunoate limba n cauz. PD Profesor Disciplin Pop Programare Costea Baze de date Costea Limbaje Miron Limbaje Popovici Programare PL Profesor Limb Pop Englez
PDLPD >< PL
Fig. 4.7. Posibil instaniere a relaiei PDL

Costea Costea Costea Miron Popovici DL Disciplin Programare Baze de date Baze de date Limbaje Limbaje Programare

Englez Francez German Englez Francez Limb Englez Englez Francez Englez German Francez

Fig.4.8. Proieciile relaiei PDL

Formal, aceast constrngere se poate transcrie astfel: dac (p,d)PD (p pred d) i (p,l) PL (p cunoate 1) i (d,l)DL (d este predat n 1), atunci (p,d,l)PDL (p pred n limba 1). Dar cele de mai sus nu exprim altceva dect faptul c relaia PDL este rezultatul cuplrii relaiilor: PD, PL i DL, adic: PDL = PD ~> PL *+ DL. Aadar, dac este satisfcut constrngerea enunat mai sus, atunci relaia PDL se poate descompune, fr pierdere de informaie, n componentele sale PD, PL i DL, adic este 3decompozabil. Se observm c relaiile din figurile 4.7. i 4.8. verific constrngerea enunat, precum i condiia de conservare a coninutului de informaie. De fapt, constrngerea enunat exprim semantic anumite dependene care trebuie s existe ntre atributele PDL pentru ca aceasta s fie 3-decompozabil. O asemenea constrngere poart numele de dependen de cuplare. Definiie: Fie R(A1,A2,...,An) o schem de relaie i R1,R2,...Rk submulimi ale mulimii {A1,A2,,An}. Spunem c exist o dependen de cuplare notat *(R1,R2,,Rk), dac i numai dac orice instaniere r a lui R este rezultatul cuplrii proieciilor sale pe R1,R2,...,Rk, adic: r=R1(r) >< R2(r) >< R1(r) >< Rk(r) . Astfel spus, *(R1,R2,...,Rk) este o dependen de cuplare pe R dac i numai dac descompunerea lui R dup componentele R1,R2,...,Rk este fr pierdere de informaie. Exemplu: *(PD,PL,DL) este o dependen de cuplare pe relaia PDL. Dependenele multivalorice sunt cazuri particulare de dependene de cuplare. Orice relaie R(X,Y,Z) care satisface dependenele multivalorice X Y i X Z satisface, n egal msur, dependena de cuplare: *(XY,XZ). Exemplu: Relaia Cursuri din paragraful 4.6. satisface dependena de cuplare: *(PD,PL), deoarece Cursuri=PD >< PL ca o consecin direct a dependeelor multivalorice: Profesor Disciplin Profesor Limb.

4.8.2. A cincea form normal (FN5)

A cincea form normal este o generalizare a formei normale patni pornind de la conceptul de dependen de cuplare. Procesul de trecere a unei relaii n FN5 presupune eliminarea dependenelor de cuplare existente n cadrul relaiei, mpreun cu anomaliile pe care acestea le cauzeaz. Totui, nu toate

dependenele de cuplare prezint interes din punctul de vedere al procesului de normalizare. n cadrul unei relaii pot exista dependene de cuplare care nu conduc la rendondan n memorarea datelor i nu sunt cauzatoare de anomalii. Acestea sunt dependenele de cuplare implicate de o cheie a relaiei. Exemplu: Fie schema de relaie: Evidena(Profesor, Student, Disciplin, Limb, Not) unde pentru fiecare student i fiecare disciplin pe care acesta o studiaz sunt evideniate profesorul, limba de predare i nota primit de student. n ipoteza rezonabil c un student studiaz orice disciplin cu un singur profesor, ntr-o limb dat i primete o singur not pentru disciplina respectiv, avem urmtoarele dependene funcionale: Student Disciplin Profesor Student Disciplin Limb Student Disciplin Not. Din cele de mai sus rezult c perechea de atribute Student Disciplin este cheie a relaiei Evidena. Mai mult, relaia Evidena este n FN4, deoarece nu exist alte dependene funcionale sau multivalorice dect cele n care cheia relaiei determin un alt atribut. Cu toate acestea, relaia Evidena se poate descompune fr pierdere de informaie n componentele: SDP(Student, Disciplin, Profesor) SDL(Student, Disciplin, Limb) SDN(Student, Disciplin, Not), ceea ce nseamn c exist dependena de cuplare: *(SDP, SDL, SDN). Aceasta este o dependen implicat de cheia relaiei format din atributele Student i Disciplin. Prin trecerea la FN5 se urmrete eliminarea dependenelor de cuplare altele dect cele implicate de o cheie a relaiei. Definiie: O relaie este n forma normal cinci (FN5) dac i numai dac toate dependenele de cuplare existente n relaie sunt implicate de o cheie a acesteia. Conform definiiei de mai sus, ntr-o relaie aflat n FN5 singurele dependene de cuplare permise sunt cele implicate de o cheie a relaiei. Avnd n vedere faptul c dependenele multivalorice sunt un caz particular de dependene de cuplare, iar dependenele funcionale sunt un caz particular de dependene multivalorice, rezult c o relaie care este n FN5, va fi implicit n FN4, i deci n FN3 .a.m.d. Se poate arta c pentru orice relaie este posibil trecerea n FN5 cu respectarea condiiei de conservare a coninutului de informaie. Exemple: 1. n lipsa altor ipoteze dect cele menionate, relaia Evidena se dovedete a fi nu numai n FN4, ci chiar n FN5, deoarece toate dependenele de cuplare ce pot fi puse n eviden n cadrul acesteia sunt implicate de cheia relaiei. Rezult c descompunerea n continuare a acestei relaii nu prezint interes din punctul de vedere a normalizrii. De asemenea, se poate verifica faptul c existena dependenei de cuplare *(SDP, SDL, SDN) nu produce anomalii n cazul unor operaii de adugare, tergere sau actualizare. Relaia PDL din paragraful 4.8.1. conine dependena de cuplare *(PD, PL, DL) care nu este implicat de cheia relaiei, format din atributele Profesor, Disciplin i Limb. Rezult c, dei relaia PDL este n FN4, ea nu este n FN5, ceea ce constituie cauza apariiei de anomalii. Relaia PDL se poate descompune, cu conservarea coninutului de informaie, n cele 3 componente ale sale: PD, PL i DL care sunt n FN5.

FUNCTION Implic(K, DC); {DC - dependena de cuplare * (Ri, R2, . . ., Rn) ; K - setul de chei al lui R, K1 R, K2 R,...,Km R} BEGIN S:={R1,R2,...,Rn) WHILE "exist Ki,XS i YS astfel nct KiXZ" DO BEGIN elimin X i Y din S"; adaug XY la S" END; IF RS THEN Implic:="Adevrat" ELSE Implic:="False" END;(Implic) Fig.4.9. Algoritmul lui Fagin pentru testarea faptului dac o dependen de cuplare DC este implicat de setul de chei K

Din cele prezentate pn acum, rezult c pentru trecerea la FN5, respectiv pentru a putea stabili dac o relaie este sau nu n FN5, este necesar s putem stabili dac o dependen de cuplare este sau nu implicat de cheile relaiei din care face parte. Acest lucru se poate realiza prin algoritmul lui Fagin prezentat n figura 4.9. Funcia Implic are ca intrri setul K de chei al unei relaii i o dependen de cuplare DC din cadrul acesteia. Funcia returneaz "Adevrat" dac DC este implicat de vreuna dintre cheile din setul K i "Fals" n caz contrar. Fiind dat o relaie R, cheile acesteia i dependenele de cuplare existente n relaie, se poate stabili cu ajutorul funciei Implic dac o relaie R este sau nu n FN5, iar dac nu este se poate gsi o descompunere a ei. Problema dificil n cazul trecerii unei relaii n FN5 este determinarea dependenelor de cuplare existente n relaie, acestea fiind mult mai greu identificate dect dependenele funcionale sau cele multivalorice. A cincea form normal este punctul final al oricrui proces de normalizare care folosete descompunerea relaiei prin proiecie i recompunerea sa prin cuplarea componentelor sale. Se poate arta c nici o relaie n FN5 nu se mai poate descompune fr pierdere de informaie prin folosirea proieciei, respectiv a cuplrii pentru reconstituire (facem abstracie de posibilele descompuneri bazate pe o cheie a relaiei care nu prezint ns nici un interes din punctul de vedere al normalizrii). O relaiei FN5 nu conine nici un fel de redondan care s poat fi eliminat printr-un procedeu bazat pe proiecie-cuplare, motiv pentru care aceast form mai poart i numele de form normal proiecie-cuplare.

4.9.

Concluzii

Prin procesul de normalizare se realizeaz eliminarea din schemele de relaie a dependenelor (funcionale, multivalorice i de cuplare) cu scopul de a produce o schem relaional avnd proprieti mai bune din punctul de vedere al redondanei datelor i al posibilelor anomalii ce pot apare n cazul operaiilor de adugare, tergere i actualizare. De remarcat similaritatea evident ce exist ntre definiiile pentru FNBC, FN4 i FN5 care ar putea fi unificate n urmtoarea definiie global: Definiie: O relaie R este n FNBC (FN4, FN5) dac i numai dac singurele dependene funcionale (multivalorice, de cuplare) existente sunt cele implicate de o cheie a relaiei R. Aceasta pune n eviden faptul c orice dependen ntre atributele unei relaii, indiferent de tipul ei (funcional, multivaloric sau de cuplare), este productoare de redondane i

cauzeaz anomalii, atunci cnd nu este implicat de o cheie a relaiei. Teoria normalizrii trebuie privit, n primul rnd, ca un cadru de ghidare a proiectantului bazei de date n vederea realizrii de scheme relaionale mai bune. Noiunile de dependen i formele normale au un caracter semantic, fiind derivate din semnificaia pe care proiectantul o atribuie diferitelor categorii de date. Tocmai de aceea dependenele, indiferent de tipul lor, au fost formulate sub forma unor constrngeri care de fapt reflect caracteristici sau aspecte suplimentare ale lumii reale care se modeleaz prin schema de relaie. Prin procesul de normalizare aceste aspecte sunt nglobate n model, schema normalizat reflectnd mai bine realitatea. Rezult c teoria normalizrii ofer proiectantului un instrument de lucru care permite o mai bun reflectare a semanticii lumii reale n modelele create. Dei ideea de normalizare este util n proiectarea bazelor de date, ea nu constituie un panaceu i nu ofer reete pentru obinerea celor mai bune modele. Este la latitudinea proiectantului decizia de a aplica sau nu o anumit etap de normalizare i aceasta depinde de contextul existent. n unele cazuri normalizarea complet, pn la FN5, s-ar putea s fie dezavantajoas. Ca regul general, trebuie ns acceptat ideea c a normaliza este, n principiu, avantajos. Pe de alt parte, trebuie remarcat faptul c prin aplicarea corect a unei metodologii de proiectare descendent (de exemplu folosind modelul entitate-relaie) modelele rezultate au tendina de a fi gata normalizate.