BAZE DE DATE CURS 1

Concepte i problematica bazelor de date

1.1 Aspecte privind organizarea datelor 1.2 Definirea unei baze de date 1.3 Arhitecturi standardizate pentru bazele de date 1.4 Limbaje pentru baze de date 1.5 Avantajele utilizarii bazelor de date 1.6 Clasificarea sistemelor de baze de date 1.1 Aspecte privind organizarea datelor Organizarea datelor ocup un loc important n proiectarea sistemelor informatice. De modul n care sunt organizate datele depinde eficien#a sistemului. Procesul de organizare a datelor presupune urm toarele activit #i: - definirea, structurarea, ordonarea $i gruparea n colec#ii de date; - stabilirea rela#iilor ntre date, ntre elementele unei colec#ii sau ntre colec#ii de date; - reprezentarea lor pe un suport informa#ional Pentru reprezentarea unui fenomen al lumii reale n vederea proces rii informa#iilor ata$ate, este nevoie s se defineasc un model de date. Definirea unui model de date impune precizarea urm toarelor elemente: - structurile de date $i stabilirea rela#iilor ntre date; - operatorii care ac#ioneaz asupra structurilor de date; - restric#ii pentru men#inerea corectitudinii datelor, numite $i restric#ii de integritate Multitudinea rela#iilor care se pot stabili ntre date este de mare varietate. Din punct de vedere al modului n care sunt legate ntre ele prin rela#iile respective, se deosebesc urm toarele tipuri de rela#ii: rela#ia de tip unu- la- unu sau one-to-one, notat (11); De exemplu, rela#ia dintre apartamentele construite cu credit de la stat $i proprietari este o rela#ie one-to-one. ntr-adev r, un asemenea apartament poate avea un singur proprietar, iar un proprietar poate beneficia de un singur apartament construit cu credit de la stat. rela#ia de tip unu- la- mul i sau one-to-many, notat (1n); De exemplu, un elev poate face parte dintr-o singur clas , o clas poate avea mai mul#i elevi. rela#ia de tip mul i- la- mul i sau many-to-many, notat (mn). De exemplu, un produs este achizi#ionat de mai mul#i clien#i $i un client poate achizi#iona mai multe produse. Operatorii care ac#ioneaz asupra structurilor de date reprezint cel de-al doilea element al unui model de date $i pot fi de citire, inserare, modificare, join etc. Restric iile de integritate, cel de-al treilea element al unui model de date sunt restric#ii menite s asigure corectitudinea datelor. Exemple de astfel de restric#ii: s nu se accepte memorarea valorilor asociate atributelor unui produs dac nu se cunoa$te valoarea cheii lui, sau s nu se permit $tergerea unui produs dac clientul nu l-a achitat. n func#ie de modul n care se definesc elementele de mai sus, modelele de date se clasific astfel: modele ierarhice sau arborescente, modele re ea, modele rela ionale, modele distribuite (acestea se bazeaz pe primele trei modele cu particularit #i legate de distribuirea datelor), modele orientate obiect, modele logice de date (bazate pe logica de ordinul nti). 1

1.2 Definirea unei baze de date Evolu#ia metodelor $i tehnicilor de organizare a datelor a fost determinat de necesitatea de a avea un acces ct mai rapid $i u$or la un volum din ce n ce mai mare de informa#ii precum $i de perfec#ionarea echipamentelor de culegere, memorare, transmitere $i prelucare a datelor. Scopul principal al unei baze de date const n stocarea datelor n vederea satisfacerii facile a cerin#elor utilizatorului, utiliznd tehnica de calcul. Deci, baza de date apare ca un sistem de nmagazinare, reg sire, actualizare $i ntre#inere a datelor necesare procesului de fundamentare a deciziei. Defini#ia 1. O baz de date este o colec ie structurat! de date ata$ate unui fenomen al lumii reale pe care ncerc!m s! l model!m. Exemplul 1. Pentru o facultate pot fi pastrate de exemplu pe perioade mari de timp informatii privind studentii, personalul, salile, planul de invatamant, aparatura si alte elemente despre care diferite persoane pot cere informatii la un moment dat. Intre aceste elemente exista diferite relatii cum ar fi: unii studenti fac anumite cursuri, unele cursuri se tin in anumite sali, unele aparate se afla in anumite sali, unele persoane pot tine cursuri si alte relatii asemanatoare. Definirea sistemului de gestiune a bazei de date O baz de date este o colec#ie de date stocate pe memorii adresabile, folosit de o mul#ime de utilizatori. ns o baz de date care nu are asociat un sistem de gestiune al acesteia nu are sens, ea nu $i poate atinge obiectivele pentru care a fost creat . Defini#ia 2. Sistemul de gestiune a bazei de date (SGBD) reprezint software-ul care asigur realizarea urm toarelor activit #i: - definirea structurii bazei de date; - nc rcarea datelor n baza de date; - accesul la date (interogare, actualizare); - ntre#inerea bazei de date ( colectarea $i refolosirea spa#iilor goale, refacerea bazei de date n cazul unui incident); - reorganizarea bazei de date (restructurarea datelor $i modificarea strategiei de acces); - securitatea datelor. A$adar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe care asigur interfa#a ntre o baz de date $i utilizatorii acesteia. Privit ntr-un sens larg, baza de date implic patru componente: date hardware software utilizatori Datele sunt memorate pe purt tori tehnici de informa#ii, hardware-ul se compune din volume de memorie pe care rezid baza de date, iar software-ul asociat bazei de date se nume$te sistem de gestiune a bazei de date (SGBD). Toate cererile de acces la baza de date sunt tratate prin intermediul SGBD. Figura 1. reprezint o viziune simplificat a unei baze de date BD format din colec#iile de date Ci, gestionat sub controlul unui produs software care este sistemul de gestiune SGBD, iar Pi sunt programe de aplica#ii pentru baza BD.

SGBD

BD C1 C2 C3

P1

mesaje

P2 C4 C6 C5 P3

rapoarte

colec\ii de date

Utilizatori finali

Programe de aplica\ie

Figura 1. Arhitectura simplificat a unei bazei de date Utilizatorii bazei de date pot fi grupa#i n trei mari categorii: - utilizatorii finali sunt cei ce interac#ioneaz cu baza de date prin intermediul unui limbaj de interogare, sau care apeleaz programe scrise de programatorii de aplica#ii; - programatorii de aplica ii sunt cei care realizeaz programele de aplica#ii ale bazei de date, utiliznd un limbaj de manipulare a datelor; - administratorul bazei de date este o persoan sau un grup de persoane responsabil cu controlul general al SGBD-ului. Un rol important n proiectarea $i implementarea unui SGBD l are administratorul de sistem. Acesta are urm toarele responsabilit #i mai semnificative: decide con#inutul informa#iilor din baza de date (define$te schema conceptual ). decide structura de memorare $i strategia de acces, definind schema intern . Prin definirea structurii de memorare se stabile$te modul de descriere a stoc rii datelor pe suportul extern, care se poate referi la: - fi$iere care compun baza de date (nume, dimensiune, mod de organizare, etc.); - articole care compun aceste fi$iere (lungime, cmpuri componente, mod de plasare, etc.); - c ile de acces la articole (tabele de indec$i, nl n#uiri, etc.). - stabile$te leg turile cu utilizatorii, definind schemele externe; - define$te verific rile de autorizare $i procedurile de validare; - define$te strategia de refacere a bazei de date dup incidente; -monitorizeaz performan#ele $i realizeaz schimb rile cerute pentru a m ri performan#a. Pentru ndeplinirea sarcinilor administratorul de sistem are nevoie de o serie de instrumente $i anume: rutine de nc rcare, pentru crearea primei versiuni a bazei de date; rutine de reorganizare, prin care se realizeaz colectarea $i eliminarea golurilor, rezultate n urma $tergerilor de nregistr ri din baza de date. Tot n cadrul acestor rutine intr $i 3

componentele care asigur reorganizarea bazei de date atunci cnd apar modific ri n schema conceptual ; rutine de jurnalizare, pentru refacerea bazei de date dup incidente hardware sau software. Jurnalele reprezint fi$iere n care sunt nregistrate, n timpul lucrului cu baza de date, informa#ii privind tranzac#iile de actualizare, opera#iile acestor tranzac#ii asupra bazei de date, nregistr rile pe care urmeaz s le modifice $i nregistr rile modificate. Toate aceste informa#ii sunt utilizate la refacerea bazei de date; rutine de refacere, pentru a realiza din cnd n cnd copii ale bazei de date pe un suport de memorie extern . rutine de analiz statistic pentru nregistrarea datelor statistice privind func#ionarea $i performan#ele sistemului de baze de date. Un ultim instrument puternic pentru administratorul bazei de date l reprezint dic#ionarul datelor, ce con#ine informa#ii privind structurile conceptuale, externe $i interne ale datelor, restric#iile de integritate, securitatea datelor, etc. 1.3 Arhitecturi standardizate pentru bazele de date Pe plan interna#ional exist mai multe grupuri specializate n standardizarea conceptelor ce apar n dezvoltarea bazelor de date, cele mai importante fiind DBTG, CODASYL, ANSI/X3/SPARC, grupul IBM. Arhitectura bazelor de date eviden#iaz componentele acestora $i a fost standardizat interna#ional. n Figura 1.1.2 se prezint o arhitectur detaliat a unei baze de date n sens larg n cadrul c reia, se eviden#iaz o serie de componente cum ar fi: nivele de definire cu schema corespunz toare fiec rui nivel, utilizatorii bazei de date, administratorul bazei de date, ca utilizator special, sistemul de gestiune a bazei de date (SGBD), etc. n general, o arhitectur cuprinde urm toarele componente: baza de date propriu-zis n care se memoreaz colec#ia de date; sistemul de gestiune al bazei de date, care este un ansamblu de programe ce realizeaz gestiunea $i prelucrarea complex a datelor; un dic#ionar al bazei de date, ce con#ine informa#ii despre date, structura acestora, elemente de descriere a semanticii, statistici, etc; mijloace hard utilizate (comune, specializate, etc.); personal implicat: utilizatori finali (neinformaticieni) sau de specialitate (administratorul de sistem), programatori $i operatori. Conform standardului ANSI/X3/SPARC datele pot fi definite pe trei nivele: nivelul intern nivelul conceptual nivelul extern Nivelul intern corespunde structurii interne de memorare a datelor. Schema intern permite descrierea datelor unei baze sub forma n care sunt stocate n memoria calculatorului. Sunt definite fi$ierele care con#in aceste date, articolele din fi$iere, metodele de acces la aceste articole. La acest nivel schemele descriu o baz de date. Nivelul conceptual este nivelul central. Acesta corespunde structurii canonice a datelor ce caracterizeaz procesul de modelat, adic structura semantic a datelor f r implementarea pe calculator. La nivel extern schemele descriu doar o parte din date $i anume, cele ce prezint interes pentru un utilizator sau un grup de utilzatori. Schema extern reprezint o descriere a unei p r#i a bazei de date ce corespunde viziunii unui program sau utilizator. Modelul extern folosit este dependent de limbajul utilizat pentru manipularea bazei de date.

Pot ap rea diferen#e ntre definirile din schema extern $i cele din schema conceptual (alt reprezentare, alt nume, alt ordine, etc.). Prin urmare este necesar o transformare extern/conceptual care va defini coresponden#a dintre viziunea conceptual $i baza de date memorat . Dac se schimb structura de memorare a bazei de date, se va schimba corespunz tor aceast transformare, astfel nct schema conceptual $i aplica#iile s r mn neschimbate. Structurarea bazei de date pe cele trei nivele (extern, conceptual $i intern) asigur independen#a datelor. O baz de date are mai multe sheme externe, o singur schem conceptual $i o singur schem intern , corespunz tor celor trei nivele de structurare a datelor.

Utilizator A1 Limbaj gazd

Utilizator A2 Limbaj gazd

Utilizator B1 Limbaj gazd

Utilizator B2 Limbaj gazd

Utilizator B3 Limbaj gazd

Viziune extern A

Schem extern A

Viziune extern B

Schem extern B

Transformarea extern/conceptual A

Transformarea extern/conceptual B

Schema conceptual

Viziune conceptual

SGBD

Transformarea Conceptual/intern

Schema intern

BAZA DE DATE MEMORAT{ (viziune intern ) ((vizz

Figura .2 Arhitectura unui sistem de baze de date

1.4 Limbaje pentru baze de date La limbajele de programare uzuale (Pascal, C, Fortran), declara#iile $i instruc#iunile executabile apar#in aceluia$i limbaj. n lumea bazelor de date, func#iile de declarare $i de manipulare a datelor sunt realizate cu ajutorul unor limbaje diferite. 1. Limbaje pentru definirea datelor (LDD) Descrierea concret a unui LDD este specific fiec rui sistem de gestiune, dar func#iile principale sunt acelea$i. La nivel conceptual, LDD realizeaz definirea entit #ilor $i a atributelor acestora prin nume, form de memorare, lungime- descriind astfel natura datelor. Sunt precizate rela#iile dintre date $i strategiile de acces la ele, sunt stabilite criterii de confiden#ialitate $i de validare automat a datelor utilizate. Acest limbaj perimite ob#inerea meta-datelor stocate n dic#ionarul de date. 2. Limbaje pentru manipularea datelor (LMD) Opera#iile pe baze de date solicit un limbaj specializat, n care comenzile se exprim prin fraze ce descriu ac#iuni asupra bazei. n general, o comand are urm toarea structur : - opera#ia, care poate fi calcul aritmetic sau logic, editare, extragere, manipulare (ad ugare, $tergere, modificare, etc.); - criterii de selec#ie (for, while, where, etc.); - mod de acces (secven#ial, indexat, etc.); - form de editare. 3. Limbaje pentru controlul datelor (LCD) Controlul unei baze de date se refer la asigurarea confiden#ialit #ii $i integrit #ii datelor, la salvarea informa#iei n cazul unor incidente, la ob#inerea unor performan#e, la rezolvarea unor probleme de concuren# . n Figura 3 se prezint modul cum un program de aplica#ie poate interac#iona cu o baz de date. Datele locale apar#in programului de aplica#ie $i sunt manipulate de acesta. Aceste date pot fi utilizate pentru a insera, modifica sau extrage informa#ii n/din baza de date. Interfa#a ntre un utilizator $i un SGBD poate fi realizat n dou moduri: cu ajutorul unui mecanism de apel inserat n programul aplica#ie. Acest mecanism poate fi un CALL sau au alt cuvnt cheie. Un SGBD care permite acest tip de mecanism se nume$te SGBD cu limbaj gazd!. cu ajutorul unor comenzi speciale, utilizate independent. n acest caz, SGBD se nume$te autonom. Exist totu$i o interfa# special , care este n m sur s interpreteze comenzile limbajului de cereri. program de aplica#ie apelare de proceduri care permit accesul la baza de date

date locale

BD

Figura 3. Interac#iunea program de aplica#ie-baz de date.

1.5 Avantajele utiliz$rii bazelor de date Memorarea datelor ntr-o baz de date ofer posibilitatea realiz rii unui control centralizat asupra acestora. Un astfel de control asupra datelor ofer urm toarele avantaje: poate fi redus redundan a datelor. Nu se recomand eliminarea total a redundan#ei; uneori, pentru a realiza performan#e sporite sub aspectul vitezei de reg sire a datelor sau din alte considerente de ordin practic (datorate de cele mai multe ori caracteristicilor de implementare a SGBD-ului), se accept un anumit grad de redundan# . Deci, ntr-o baz de date se recomand o redundan# minim $i controlat a datelor. se poate evita inconsisten a datelor. Acest avantaj este un corolar al punctului anterior. Cnd redundan#a este nl turat nu pot ap rea inconsisten#e, iar cnd exist , este controlat $i sistemul asigur propagarea actualiz rii la fiecare copie a aceleia$i date. datele pot fi partajate. Partajarea datelor trebuie n#eleas nu numai sub aspectul asigur rii accesului mai multor utilizatori la acelea$i date ci $i sub aspectul dezvolt rii de noi aplica#ii f r s se modifice structura bazei de date. se poate ob#ine standardizarea. Utiliznd baza de date, administratorul bazei de date poate asigura aplicarea standardelor n reprezentarea datelor. Aceste standarde sunt: standardele ntreprinderii, ale echipamentelor de tehnic de calcul, ale ramurii de activitate, ale economiei na#ionale, interna#ionale, etc. se pot aplica restric ii de securitate a datelor. Avnd o jurisdic#ie complet asupra datelor opera#ionale, administratorul bazei de date poate asigura c accesul la baza de date se face numai prin canale corespunz toare. n acest sens se pot defini verific ri de autorizare, care s fie executate oricnd se ncearc un acces la anumite date. poate fi men#inut integritatea datelor prin existen#a unor proceduri de validare sau a unor protocoale de control concurent precum $i a unor proceduri de refacere a bazei de date dup incidente. pot fi echilibrate cerin ele conflictuale. Cunoscnd cerin#ele de ansamblu ale ntreprinderii, n opozi#ie cu cerin#ele fiec rui utilizator individual, administratorul bazei de date poate structura baza de date n a$a fel nct s satisfac cerin#ele tuturor utilizatorilor n condi#ii de redundan# minim $i controlat a datelor, pe de o parte, iar pe de alt parte, pot fi definite o serie de criterii de reg sire care s permit un acces rapid pentru aplica#iile mai importante. independen a datelor. Multe din avantajele de mai sus sunt evidente. Un aspect nu a$a de evident, care este mai degrab un obiectiv dect un avantaj, l constituie asigurarea independen ei datelor. Se spune c o aplica#ie este dependent de date, dac este imposibil de schimbat structura de memorare a datelor (modul cum sunt nregistrate fizic datele) sau strategia de acces la date f r a afecta aplica#ia. ntr-o baz de date nu se dore$te ca aplica#iile s fie dependente de date, cel pu#in din urm toarele motive: - diferite aplica#ii au nevoie de viziuni diferite ale acelora$i date. De exemplu, o aplica#ie utilizeaz acela$i cmp de dat drept o dat zecimal n timp ce o alt aplica#ie utilizeaz acela$i cmp de dat ca fiind reprezentat n binar. Sistemul va asigura automat conversia ntre reprezentarea intern a acelei date $i reprezentarea necesar fiec rei aplica#ii. - administratorul bazei de date trebuie s aib libertatea s schimbe structura de memorare sau strategia de acces, ca r spuns la cerin#ele de schimbare (ntreprinderea trebuie s -$i schimbe standardele, priorit #ile aplica#iilor, unit #ile de memorie, etc.), f r s modifice aplica#iile existente. organizarea datelor pe dou niveluri, fizic $i logic.

1.6 Clasificarea sistemelor de baze de date Se pot lua n considera#ie mai multe criterii de clasificare ale sistemelor de baze de date. Clasificare dup modelul de date. Majoritatea sistemelor de baze de date actuale sunt realizate n modelul de date rela#ional sau n modelul de date obiect. Dezvoltarea continu a acestor modele a condus c tre o nou categorie de baze de date, numite obiect-rela ionale, care combin caracteristicile modelului rela#ional cu cele ale modelului obiect. De asemenea, mai sunt nc n func#iune baze de date n modele mai vechi (modelul ierarhic sau modelul re ea). Modelele de date utilizate de sistemele SGBD vor fi prezentate n sec#iunea urm toare. Clasificare dup num rul de utilizatori. Majoritatea sistemelor de baze de date sunt sisteme multiutilizator, adic permit accesul concurent (n acela$i timp) a mai multor utilizatori la aceea$i baz de date. Un num r redus de sisteme de baze de date sunt de tip monoutilizator, adic suport accesul doar al unui singur utilizator (la un moment dat). Clasificare dup num rul de sta#ii pe care este stocat baza de date. Exist dou categorii de sisteme de baze de date: centralizate $i distribuite. Un sistem de baze de date centralizat (Centralized Database System) este un sistem de baze de date n care datele $i sistemul de gestiune sunt stocate pe o singur sta#ie (calculator). Un sistem centralizat poate suporta unul sau mai mul#i utilizatori, dar, n orice situa#ie, datele $i sistemul de gestiune rezid n ntregime pe o singur sta#ie. Un sistem de baze de date distribuit (Distributed Database System) poate avea att datele, ct $i sistemul de gestiune, distribuite n mai multe sta#ii interconectate printr-o re#ea de comunica#ie. Sistemele de baze de date pot fi reprezentate din punct de vedere al func#ion rii lor printr-o arhitectur de tip client-server.

Fig. 4. Sisteme de baze de date centralizate: a- monoutilizator; b- multiutilizator.

ntr-un sistem centralizat (fig. 4) exist un singur server, care este chiar sistemul SGBD, ce r spunde cererilor unui singur client (n sistemele mono-utilizator, fig. 4, a) sau mai multor clien i (n sistemele multi-utilizator, fig. 4, b), care acceseaz baza de date respectiv . Clien ii sunt programe de aplica#ii oferite de furnizorul sistemului de gestiune sau dezvoltate de programatori. Aplica#iile client pot fi executate pe sta#ii diferite, conectate printr-o re#ea de comunica#ie cu sta#ia pe care ruleaz serverul. Aceast arhitectur permite o prelucrare distribuit a datelor $i, mai mult, o configurare a sistemului adaptat cerin#elor de calcul 8

particulare. Astfel, serverul bazei de date poate fi un sistem puternic, echipat corespunz tor (cu volum mare de memorie secundar ), n timp ce fiecare client este o sta#ie personal , cu putere de calcul adecvat aplica#iei executate. Sistemele de baze de date distribuite pot fi reprezentate ntr-un mod asem n tor din perspectiva structur rii client-server (fig. 5). O baz de date distribuit este o colec#ie de date care apar#in din punct de vedere logic aceluia$i sistem, dar care pot s fie, din punct de vedere fizic, memorate n mai multe sta#ii de calcul (loca#ii - sites) conectate printr-o re#ea de comunica#ie. Sistemul software care gestioneaz o astfel de baz de date se nume$te Sistem de Gestiune a Bazei de Date Distribuite - SGBDD - (Distributed Database Management System - DDBMS). Aplica#iile client ruleaz pe alte sta#ii din re#ea $i solicit servicii de la sistemul de gestiune distribuit.

Fig.5 Sistem de baze de date distribuit Exist numeroase avantaje ale sistemelor de baze de date distribuite (cre$terea capacit #ii de stocare $i prelucrare a datelor, cre$terea disponibilit #ii $i a partaj rii datelor, etc.), dar $i o cre$tere considerabil a complexit #ii acestora. Cea mai important cerin# pe care trebuie s o ndeplineasc sistemele de gestiune a bazelor de date distribuite este de a asigura administrarea transparent a datelor. Transparen#a se refer la capacitatea unui sistem distribuit de a ascunde detaliile de implementare, astfel nct utilizatorii s poat accesa datele pe baza unui model de nivel nalt, f r a fi necesar cunoa$terea exact a modului de amplasare, replicare sau comunicare a datelor. Sistemele de gestiune a bazelor de date distribuite comerciale nu ofer n momentul de fa# un nivel suficient de transparen# a localiz rii datelor, dar dezvoltarea continu a acestora va putea s asigure n viitor aceast cerin# .

BAZE DE DATE CURS 2 ASPECTE PRIVIND PROIECTAREA BAZELOR DE DATE 2.1 Proiectarea schemei conceptuale n ultima decad a mileniului trecut s-a realizat o cre$tere rapid a num rului de sisteme de baze de date (SGBD), dar mai ales a sistemelor care permit stocarea a mari cantit #i de informa#ii $i dezvoltarea de aplica#ii complexe. Aceast cerere continu de sisteme complexe $i de mare precizie a fost stimulat de concepte de nivel nalt, de instrumente $i de tehnici de proiectare $i dezvoltare a bazelor de date. Metodologia de proiectare a bazelor de date, ce a fost dezvoltat n ultimii ani, constituie pentru proiectant un mijloc de modelare a unei ntreprinderii la un nivel nalt de abstractizare, mai nainte de a proceda la proiectarea logic $i fizic detaliat a bazelor de date. Pentru baze de date de dimensiuni mici, care sunt folosite de un singur utilizator sau de un num r redus de utilizatori, proiectarea este destul de simpl . ns , pentru baze de date de dimensiuni medii sau mari, care fac parte din sistemul informatic al unei organiza#ii extinse, proiectarea este mult mai complicat . Astfel de baze de date, care trebuie s satisfac cerin#ele a numeroase aplica#ii $i utilizatori trebuie s fie proiectate cu mult grij $i testate ct mai riguros. Numeroase institu#ii $i servicii ca: asigur rile, serviciile bancare, serviciile de transport, companiile de comunica#ii, etc. sunt total dependente de func#ionarea corect $i nentrerupt a sistemelor lor de baze de date. n organiza#iile mari comerciale, industriale sau guvernamentale, sistemul de baze de date face parte din sistemul informatic al organiza#iei respective. Sistemul informatic (Information system) include toate resursele unei organiza#ii care sunt implicate n colectarea, administrarea, utilizarea $i diseminarea informa#iilor. Crearea, utilizarea $i ntre#inerea sistemelor de baze de date comport mai multe etape, care pot fi prezentate succint astfel: a) Definirea sistemului: definirea scopului sistemului de baze de date, a utilizatorilor $i a aplica#iilor acestuia. b) Proiectarea sistemului: n aceast etap se realizeaz proiectul logic $i proiectul fizic al sistemului, pentru un anumit SGBD ales. c) Implementarea: este etapa n care se scriu defini#iile obiectelor bazei de date (tabele, vederi, etc.) $i se implementeaz aplica#iile software. d) nc!rcarea (sau conversia) datelor, popularea bazei de date, fie prin nc rcarea direct a datelor, fie prin conversia unor date existente sub diferite alte forme (fi$iere, alte sisteme de gestiune a bazelor de date). e) Conversia aplica iilor, toate aplica#iile software existente n sistemele informatice precedente ale organiza#iei se convertesc n noul sistem. f) Testarea $i validarea: noul sistem de baze de date este testat $i validat ct mai riguros posibil. g) Operarea: sistemul de baze de date este pus la dispozi#ia utilizatorilor s i, cu toate aplica#iile realizate, n cadrul sistemului informatic al organiza#iei. h) Monitorizarea $i ntre inerea: pe tot parcursul etapei de operare sistemul de baze de date trebuie s fie n mod permanent monitorizat $i ntre#inut, pentru a asigura consisten#a $i securitatea datelor $i pentru a permite att cre$terea con#inutului de date ct $i dezvoltarea de noi aplica#ii software. Pot fi necesare, la anumite intervale de timp, revizii $i reorganiz ri ale sistemului de baze de date.

10

Etapele de conversie (d) $i (e) nu sunt necesare dac baza de date $i aplica#iile sunt noi. n continuarea acestei sec#iuni se vor detalia diferite aspecte cu caracter general ale etapei (b), de proiectare a bazelor de date $i a aplica#iilor software pentru acestea. Etapa de proiectare se refer n general la modelarea semantic! ale datelor pentru aplica#iile bazei de date. Modelele de date sunt esen#iale n tehnologia bazelor de date $i constituie o baz formal pentru dezvoltarea limbajelor $i sistemelor de implementare a sistemelor de baze de date. Modelarea datelor este un proces n dou etape, care implic : 1. faz$ de proiectare conceptual$, cnd se proiecteaz schema conceptual ce constituie o abstractizare a universului real $i a situa#iei considerate. 2. proiectarea structurii logice a datelor, ce constituie schema care va fi implementat . Pe parcursul activit #ii de proiectare trebuie s fie satisf cute mai multe cerin#e, multe dintre ele fiind contradictorii $i dificil de ndeplinit: ob#inerea unui timp de r spuns la interog ri ct mai mic, $i, n acela$i timp, utilizarea unui spa#iu de memorare ct mai redus; asigurarea unui mod de acces la date ct mai simplu dar intuitiv, etc. Problema proiect rii bazelor de date este complicat $i de faptul c , de cele mai multe ori, procesul de proiectare ncepe cu cerin#e foarte generale $i imprecis formulate. Prin contrast, proiectul rezultat trebuie s con#in schema bazei de date precis definit , dat fiind c , dup implementarea aplica#iilor, modificarea bazei de date este mult mai dificil . n general, se consider c etapele de proiectare $i implementare a unei baze de date se pot diviza, la rndul lor, n mai multe faze: l Colectarea $i analiza cerin#elor. l Proiectarea conceptual a bazei de date. l Alegerea unui SGBD. l Proiectarea logic a bazei de date. l Proiectarea fizic a bazei de date. l Implementarea bazei de date.

Figura 2.1 Etapele proiectarii $i implementarii unei baze de date n mod tipic, proiectarea unei baze de date const din desf $urarea a dou categorii de activit #i paralele, a$a cum se poate vedea n figur . 11

Prima categorie de activit #i se refer la proiectarea structurii $i a con inutului bazei de date, iar cea de-a doua categorie se refer la proiectarea modului de prelucrare a datelor. Cele $ase faze de proiectare $i implementare enumerate mai sus nu se desf $oar strict ntr-o singur secven# . n multe cazuri este necesar modificarea proiectului dintr-o faz ini#ial ntr-una din fazele ulterioare, pentru a se ob#ine rezultatele dorite. Fazele cele mai importante de proiectare a unei baze de date sunt fazele 2, 4 $i 5. Faza 1, n care se colecteaz informa#iile despre cerin#ele de utilizare a bazei de date $i faza 6, de implementare a datelor $i a tranzac#iilor, pot s nu fie considerate ca parte a procesului de proiectare a bazei de date, ci ca parte a ciclului de viat al sistemului informatic din care face parte baza de date respectiv . Faza 3, de alegere a sistemului de gestiune a bazei de date, este mai pu#in o faz de proiectare, ci mai curnd o faz de decizie. Terminologia folosit n domeniul proiect rii bazelor de date este destul de variat . Cel mai frecvent, pentru proiectul conceptual al unei baze de date se folosesc denumirile de schem! conceptual! de nivel nalt sau schem! conceptual! independent! de SGBD sau, chiar mai simplu, schem! conceptual!. Proiectul logic al unei baze de date este denumit schem! logic! sau schem! conceptual! dependent! de SGBD. 2.1.1 Cerin#e generale nainte de a se proiecta efectiv o baz de date, este necesar s se cunoasc ce rezultate se a$teapt utilizatorii poten#iali s ob#in de la baza de date respectiv $i ce informa#ii primare sunt disponibile pentru aceasta. De asemenea, este necesar s se cunoasc ce aplica#ii se vor efectua (aplica#ii de gestiune a stocurilor, aplica#ii contabile, aplica#ii de urm rire a consumurilor, aplica#ii de salarizare, etc). n aceast faz de colectare $i analiz a cerin#elor, se desf $oar urm toarele activit #i: Identificarea grupurilor de utilizatori poten iali $i a aplica iilor. De regul , persoana cea mai avizat din cadrul fiec rui grup de utilizatori este cooptat ca participant n activit #ile ulterioare de colectare $i analiz a cerin#elor. Revederea documenta iei existente privind aplica iile dorite. n afar de documenta#iile aplica#iilor dorite se studiaz $i alte documenta#ii (diagramele de organizare a ntreprinderii, formularele existente de introducere a datelor, rapoartele utilizate n controlul activit #ii respective, etc), pentru a decide dac acestea influen#eaz cerin#ele bazei de date. Analiza mediului de operare $i a cerin elor de prelucrare a datelor. Aceast activitate include analiza fluxului de informa#ii n cadrul sistemului, precum $i analiza tipurilor de tranzac#ii $i a frecventei de lansare a acestora. Deosebit de important este $i stabilirea volumului de date con#inute n mod tipic de baza de date, a volumului $i frecven#ei datelor actualizate precum $i a volumului datelor returnate de interog ri $i a frecven#ei acestora. Chestionare $i interviuri. Se colecteaz r spunsuri scrise de la utilizatorii poten#iali la diferite seturi de ntreb ri $i se organizeaz interviuri cu persoanele care reprezint diferitele grupuri de utilizatori. Aceast faz este puternic consumatoare de timp, dar este crucial pentru succesul sistemului informatic. Faza de proiectare conceptual a bazelor de date implic dou activit #i paralele: proiectarea schemei conceptuale $i a schemelor externe ale bazei de date $i proiectarea tranzac iilor. a. Proiectarea schemei conceptuale Scopul proiect rii schemei conceptuale este n#elegerea ct mai complet a structurii bazei de date, a asocierilor $i a constrngerilor de c tre proiectan#i $i programatori. Acest deziderat se ob#ine mult mai bine independent de un anumit SGBD, deoarece un model de date de nivel nalt este mult mai general $i mai expresiv, n timp ce fiecare SGBD are propriile restric#ii $i solu#ii particulare, care nu trebuie s influen#eze proiectul schemei conceptuale. 12

Schema conceptual de nivel nalt independent de SGBD este o descriere stabil $i inavuabil a bazei de date. Alegerea unui SGBD $i deciziile ulterioare de proiectare se pot schimba f r ca aceasta s se schimbe. Descrierea diagramatic a schemei conceptuale poate servi ca un excelent mijloc de comunica#ie ntre anali$tii, proiectan#ii, programatorii $i utilizatorii bazei de date, deoarece modelele de date de nivel nalt sunt bazate pe concepte mai u$or de n#eles dect un model de date de nivel mai sc zut, specific unui anumit SGBD. Pentru proiectarea schemei conceptuale se identific elementele esen#iale ale acesteia, tipurile de entit #i $i atributele lor precum $i asocierile dintre aceste tipuri. Acest proiect conceptual de nivel nalt este realizat pe baza cerin#elor definite n prima etap de proiectare $i se reprezint , n general printr-o diagram Entitate-Asociere (extins ). Exist dou aspecte privind modul de abordare a proiect rii conceptuale: 1. proiectarea prin integrarea cerin elor (care se mai nume$te $i proiectare centralizat!); se realizeaz mai nti integrarea (combinarea) tuturor cerin#elor de proiectare ntr-un singur set de cerin#e, pe baza c ruia se proiecteaz schema conceptual a bazei de date. Din aceast schema conceptual (unic ) proiectat se deduc schemele externe (vederile) corespunz toare diferitelor grupuri de utilizatori $i aplica#ii. 2. proiectarea prin integrarea vederilor (schemelor) externe; se proiecteaz cte o schem corespunz toare fiec rui grup de utilizatori $i aplica#ii, pe baza cerin#elor acestora, dup care se combin aceste scheme ntr-o singur schem conceptual global , pentru ntreaga baz de date. Fiind dat un set de cerin#e, pentru un singur utilizator sau pentru mai mul#i utilizatori ai bazei de date, proiectarea schemei conceptuale care s satisfac aceste cerin#e se poate aborda ntr-o varietate de strategii, dintre care cele mai relevante sunt proiectarea descendent (topdown) $i proiectarea ascendent (bottom-up). n proiectarea descendent a bazelor de date se porne$te de la o schem conceptual dezvoltat n modelul Entitate-Asociere (extins) n care sunt cuprinse aspectele de baz (tipuri de entit #i $i asocieri ale acestora). Dezvoltarea $i rafinarea acestui model se face prin ad ugarea de noi atribute $i constrngeri, crearea unor subtipuri (prin specializare) $i asocierea acestora cu tipurile de baz . n proiectare ascendent a bazelor de date se porne$te de la o schem! conceptual! universal! care con#ine toate atributele, care sunt apoi grupate pentru a forma tipuri de entit #i $i asocierile dintre acestea. Proiectul poate fi rafinat prin grup ri ulterioare $i creare de supertipuri $i subtipuri ale tipurilor existente. A$adar, n aceast faz de proiectare se ob#ine schema conceptual de nivel nalt a bazei de date, care este independent de orice model de date specific (ierarhic, re#ea, rela#ional, etc), $i de orice sistem de gestiune care poate fi folosit pentru realizarea bazei de date. b. Proiectarea tranzac iilor Atunci cnd se proiecteaz o baz de date, se cunosc n mare parte $i ce tipuri de aplica#ii se vor executa. Un aspect important n proiectarea bazelor de date este specificarea caracteristicilor func#ionale ale acestor aplica#ii ct mai devreme n cursul procesului de proiectare, astfel nct schema bazei de date s includ toate informa#iile necesare cu privire la aceste aplica#ii. In plus, cunoa$terea importan#ei relative a diferitelor tranzac#ii executate de aplica#iile bazei de date, precum $i a frecven#ei de invocare a acestora, permite luarea unor decizii n etapa de proiectare fizic a bazei de date. Dup implementarea sistemului de baze de date vor mai fi identificate $i implementate noi tranzac#ii. Totu$i, cele mai importante tranzac#ii sunt cel mai adesea cunoscute nainte de implementarea sistemului. Una din tehnicile cele mai obi$nuite de specificare a tranzac#iilor la nivel conceptual $i independent de sistemul de gestiune este de a identifica intr!rile $i ie$irile lor $i comportarea 13

func ional!. Tranzac#iile sunt grupate n trei categorii: tranzac#ii de interogare, tranzac#ii de actualizare $i tranzac#ii mixte, care execut att interog ri ct $i actualiz ri. 2.1.2 Metode de proiectare conceptual$ bazate pe descompunerea func#ional$. Metoda TOP-DOWN a fost aplicat cu mult nainte de existen#a informaticii ca $tiin# . Abordarea acesteia n informatic a fost determinat de schimb rile iminente ce trebuiau s se produc pentru propulsarea informaticii spre stadiul n care se afl ast zi $i pentru rezolvarea problemelor majore cu care se confruntau proiectan#ii de software, n sensul c produsele pe care le realizau erau de nest pnit sub aspectul complexit #ii lor. Dezvoltarea metodei a fost determinat de lucr rile lui Jacopini, Djikstra, Hoare, Mills, Wirth $i Dahl care au impus-o $i au definit-o riguros, rezultnd submetode specifice ariei de aplicabilitate, cum ar fi: - metoda top-down structurat ; - metoda deciziilor multicriteriale n condi#ii de certitudine; - metoda de c utare n adncime; - metoda deciziilor top-down structurate $.a.m.d. Pentru elaborarea modelului metodei TOP-DOWN vom considera simbolurile din figura 2.2.

Figura 2.2 Simboluri pentru schemele TOP-DOWN. a) secven#a terminat logic, direct programabil ; b) decizie care define$te problemele de tratat; c) subproblem care va fi tratat ulterior, dar care acum se define$te. Metoda const n descompunerea problemei de rezolvat n subprobleme legate ntre ele prin marcarea punctelor decizionale care se constituie ca repere n abordarea problemei. Aceast descompunere este ntemeiat pe definirea pentru fiecare subproblem n parte a unei func#ii specifice care o individualizeaz n contextul dat. Pe baza simbolurilor o problem abstract de proiectare, ca n figura 2.3, poate fi descompus n blocuri corelate ntre ele prin puncte decizionale $i a$a poate fi evaluat stadiul n care se afl abordarea problemei.

Figura 2.3. Exemplu de descompunere a unei aplica#ii. 14

Abordarea top-down a problemei definite n figura 2.3, presupune reprezentarea din fig. 2.4.

Figura 2.4. Abordarea TOP-DOWN

Observa#ie: Toate schemele de mai sus $i cele care urmeaz pseudocod, folosind numai enun#urile de l atribuire: v'<expresie>; l ramificare: IF <expresie logic$> THEN <Instr1> ELSE <Instr2>; l apelare proceduri: CALL <nume procedur$>;

pot fi descrise n

Pentru o abordare bottom-up a aceleia$i probleme, reprezent m succesiunea de etape prin figurile 2.5. - 2.6.

Figura 2.5. Abordarea BOTTOM-UP. Etapa 1.

Figura 2.6. Abordarea BOTTOM-UP. Etapa 2. 2.1.3 Metode de proiectare conceptual$ bazate pe structuri de date Metoda Jackson se bazeaz pe coresponden#a dintre structura datelor $i structura programelor. n elaborarea ei s-a pornit de la premiza c programele corecte nu pot fi ob#inute pe baza test rii unor programe incorecte. Prin coresponden#a care se stabile$te ntre structura 15

datelor $i structura programelor se ajunge la o descompunere a programelor n procese distincte. Aceast metod mbin armonios principiile program rii modulare, ale program rii structurate cu principiul coresponden#ei ntre structura datelor $i structura programelor. Prin procedee constructive, structura programelor este derivat din structura datelor. Componentele specifice unui program structurat sunt folosite de c tre Jackson nu numai pentru structura programelor ci $i pentru structura datelor. De aici, deriv faptul c adaug n construirea programelor un principiu suplimentar fa# de principiile program rii structurate, $i anume: structura programelor se bazeaz n ntregime pe structura datelor prelucrate. Pentru reprezentarea proiectului software se folose$te: - reprezentarea grafic sub forma unor diagrame de structur att pentru date ct $i pentru programe; - reprezentarea textual sub forma unui pseudocod specific.

Figura 2.7 Reprezentarea secven#ei n metoda Jackson: a) reprezentarea grafic a unei secven#e simple; b) reprezentarea grafic a unei secven#e compuse; c) reprezentarea n pseudocod a secven#ei.

Figura 2.8. Reprezentarea itera#iei n metoda Jackson:

Figura 2.9. Reprezentarea selec#iei n metoda Jackson: 16

n ceea ce prive$te proiectarea, metoda Jackson este constructiv , n sensul c poate fi descompus n pa$i distinc#i, executarea corect a fiec rui pas trebuind s asigure executarea corect a ntregii metode, deci $i corectitudinea produsului software care rezult prin folosirea metodei. Dificultatea major rezid din faptul c trebuie ca execu#ia corect a unui pas s fie verificabil f r a face referiri la pa$ii care nu au fost executa#i de c tre proiectant. n forma cea mai simpl aplicarea metodei poate fi eviden#iat n trei pa$i: - descrierea structurii datelor de intrare $i de ie$ire sub forma unor diagrame de structur ; - compunerea structurii datelor ntr-o structur de program; - listarea opera#iilor executabile necesare $i introducerea lor n locul corect din structura programului. 2.1.4. Metode de proiectare conceptual$ bazate pe structura programelor i flux de date Aceast metod de proiectare a fost propus de G. J. Myers $i este legat de proiectarea structurat , diferen#ele dintre cele dou metode constnd n reprezentarea proiectului. Atributele fundamentale ale unui program, conform proiect rii compuse, sunt urm toarele: structura, a c rei definire se realizeaz pe baza fluxului datelor; func ia, care descrie caracteristicile programului; performan a, care descrie modul n care programul realizeaz func#ia, folosind ca m rimi: viteza de execu#ie, dimensiunea memoriei, utilizarea resurselor, fiabilitatea $.a.m.d. Proiectarea compus! refer structura programelor, exprimat prin module, date, interfe#e ntre module, ntr-un proces de descompunere. Ca rezultat al acestei abord ri se ob#in programe de complexitate minimal , ceea ce determin mbun t #irea fiabilit #ii, mentenabilit #ii $i adaptabilit #ii programelor. Aplicarea principiului modularit! ii permite descompunerea unei aplica#ii n mai multe module puternic independente. Independen#a modulelor poate fi atins prin metode de optimizare, cum ar fi: maximizarea rela iilor n interiorul fiec!rui modul $i minimizarea rela iilor dintre module. Proiectarea compus cuprinde un proces numit analiz! compus!, care implic o analiz a structurii problemei $i a modului n care datele sunt transformate. Aceast informa#ie determin descompunerea problemei ntr-un set de module, fiecare modul fiind considerat ca subproblem , analiza fiind aceea$i ca $i problema ini#ial . Analiza compus este un proces de proiectare top-down. Fiecare modul are trei atribute de baza: 1. n elegerea exact! a func iei unui modul este un element cheie pentru n#elegerea proiect rii compuse. De regul , func#ia se identific cu transformarea intr rilor n ie$iri, care are loc la apelul modulului. 2. Logica se refer la controlul fluxului din interiorul modulului $i arat cum se realizeaz func#ia la apelul modulului; 3. Interfa a. Consisten#a unui modul este o m rime folosit pentru a aprecia rela#ia dintre elementele componente ale unui modul individual. A maximiza consisten#a unui modul nseamn a organiza elementele componente n a$a fel nct elementele care sunt strns legate s fac parte din acela$i modul, iar elementele nelegate s fac parte din module distincte. n practic modulele pot avea una dintre urm toarele tipuri de consisten#e: Consisten a ntmpl!toare apare n cadrul unui modul atunci cnd nu exist nici un fel de rela#ie ntre elementele acestuia Consisten a logic! apare n cazul unui modul care, la fiecare apel, execut o func#ie selectat din mai multe func#ii similare.

17

 Consisten a clasic! este similar cu consisten#a logic . Un modul cu consisten# clasic este un modul cu consistent logic n care func#iile componente se execut secven#ial. Aceste func#ii sunt controlate n timp. Consisten a procedural! este similar cu consisten#a clasic ; se execut mai multe func#ii corelate, iar corelarea acestora este f cut n raport cu o procedur $i nu n raport cu o procedur a programului ca n cazul consisten#ei clasice. De exemplu, un modul care afi$eaz graficul unei func#ii x $i tip re$te un raport y are o consisten# procedural , n sensul c cele dou func#ii nu sunt legate ntre ele, dar corelate prin faptul c n cadrul problemei care a stat la originea programului ele apar una dup alta. Consisten a comunica ional! presupune construirea de module cu consisten# procedural n care func#iile comunic ntre ele. Comunicarea poate fi de dou tipuri: 1. toate func#iile pot referi acela$i set de date definite n cadrul modulului; 2. datele rezultate dintr-o func#ie sunt folosite ca date de intrare pentru o alt func#ie. Cuplajul modulelor caracterizeaz mecanismul de transmitere a datelor $i a atributelor acestora ntre module. A maximiza independen#a modulelor nseamn a reduce cuplajul dintre acestea. Cuplajele dintre module pot fi ordonate dup cum urmeaz : 1.Cuplajul prin con inut apare ntre dou module dac modulul apelant refer direct elemente din cuprinsul modulului apelat. 2. Cuplajul prin date presupune a transmite ca parametrii ntre module doar date elementare. M rimile consisten# $i cuplaj pot fi folosite pentru evaluarea unui proiect existent sau pentru a evalua diversele solu#ii de proiectare pentru o aplica#ie nou . Sintetic, rela#ia dintre cuplaj $i atribute (independen#a ntre module, susceptibilitatea la erori, reutilizarea modulelor n alte contexte, extensibilitatea aplica#iilor) poate fi prezentat astfel: Cuplaj Independen#$ Susceptibilitate Reutilizare n Extensibilitate prin fa#$ de erori la aplica#ii alte module mare mic mare Mic Date medie medie medie Medie Structuri de date medie medie Medie Date de medie control mic -medie mare mic -medie Mic Date extreme mic mare mic Mic Date comune foarte mic foarte mare mic Mic Con#inut Tabelul 2.1. Propriet #ile cuplajului. Pe lng consisten# $i cuplaj exist $i alte m rimi, care alese convenabil, pot avea un efect pozitiv asupra independen#ei modulelor: dimensiunea modulelor poate mbun t #i claritatea aplica#iilor $i poate elimina dificult #ile test rii acestora; simplitatea solu#iei care presupune proiectarea problemei de rezolvat f r aplicarea generalit #ii; recursivitatea care simplific logica modulelor; predictibilitatea execu#iei; un modul este predictibil dac func#ia lui este independent de evolu#ia utiliz rii lui anterioare, ceea ce presupune c pentru intr ri identice va opera identic de fiecare dat cnd este apelat. n proiectarea compus acest element asigur independen#a modulelor de context. 18

 structura de decizie. Ori de cte ori execu#ia unor module este afectat de o decizie, este de dorit ca modulele afectate direct de aceast decizie s fie subordonate direct modulului care con#ine decizia. n acest fel se evit utilizarea unor parametrii speciali reprezentnd decizii. accesul la date se cuantific prin cantitatea poten#ial de date pe care un modul le poate referi. Aceast m rime trebuie minimizat n procesul de proiectare, astfel nct fiecare modul s nu poat referi dect datele de care are nevoie. Utilizarea modulelor cu consisten# informa#ional $i evitarea cuplajelor prin date comune, date externe $i structuri de date constituie principalele c i prin care acest parametru poate fi minimizat. izolarea opera#iilor de intrare-ie ire ntr-un num r mic de module este un obiectiv important al proiect rii, n sensul c toate func#iile primitive relative la intr ri pot fi cuprinse ntr-un modul cu consisten#a informa#ional . Aceast strategie conduce la programe portabile $i extensibile. Pe parcursul procesului de proiectare, n metoda proiect rii compuse, se folosesc trei tipuri de diagrame pentru reprezentarea proiectului: 1. Diagrame de flux de date sunt reprezent ri grafice neprocedurale ale transform rilor pe care le sufer datele n structura problemei. O astfel de diagram este compus din s ge#i $i cercuri. S ge#ile definesc transferuri de date ntre procesele de transformare, iar cercurile reprezint transform rile pe care le sufer datele n structura problemei (figura 2.10.).

Figura 2.10. Diagrame pentru urm rirea fluxului datelor.

Figura 2.11. Simboluri pentru reprezentarea diagramelor de structur . 2. Diagrame cu structura modulelor se definesc pe baza diagramelor fluxurilor de date, fiecare modul avnd o func#ie care descrie transform rile ce au loc atunci cnd acesta este apelat. Pentru construirea acestor diagrame se folosesc simbolurile din figura 2.11. 3. Diagrame ce definesc interfe#ele dintre module sunt tabele n care fiecare intrare corespunde unei interfe#e din diagrama de structur asociat . Fiecare intrare cuprinde dou 19

p r#i: o parte care define$te datele care sunt transmise modulului apelat de c tre modulul apelant $i o parte pentru datele transmise modulului apelant de c tre modulul apelat dup terminarea func#iei acestuia (figura 2.12.).

Figura 2.12. Diagrame pentru definirea interfe#elor. Procesul prin care, plecnd de la structura unei probleme se ajunge la structura unei aplica#ii sau sistem informatic, se nume$te analiz compus . Acest proces presupune analiza structurii problemei $i mai exact a modulului n care datele sunt transformate. Aceast informa#ie este folosit pentru descompunerea problemei ntr-un set de module, func#ia unui modul corespunznd unei transform ri pe fluxul datelor. Fiecare modul este considerat apoi ca o problem de sine st t toare, analiza fiind repetat dup acelea$i principii. 2.1.5 Metode bazate pe abstrac#ii Procesul de abstractizare joac un rol important n cadrul activit #ii de realizare a aplica#iilor, constituind unul dintre cele mai nsemnate mijloace pentru controlul complexit #ii programelor. Se poate spune c tehnica program rii structurate are ca baz procesul de abstractizare. Elaborarea proiectului unui program complex nu se poate realiza dintr-o dat . De regul , se procedeaz la prezentarea problemei printr-un enun general. Prin abstractizare $i descompunere n pa$i succesivi se ajunge la enun ul de detaliu, adic la date $i opera#ii care pot fi descrise direct cu ajutorul unui limbaj de programare. Dac not m cu N nivelul limbajului putem spune c el permite programatorului s descrie problema pentru o ma$in abstract M care va fi simulat pe o ma$in real R. No#iunea de abstractizare se g se$te sub dou forme: forma implicit!, bazat pe elemente predefinite n cadrul limbajelor, cum ar fi: masivele, structurile de control if-then-else $.a.m.d., care uneori constituie bariere pentru procesul de abstractizare; forma explicit!, bazat pe elemente introduse de proiectant, folosind mecanisme speciale, numite $i mecanisme de extensie. Aceast form duce la o cre$tere considerabil a productivit #ii muncii de proiectare $i programare. Prin asocierea la un limbaj a unui mecanism de extensie se pot defini tipuri noi de enun#uri $i de date specifice domeniului de aplica#ie, prin urmare noi obiecte abstracte. Ca urmare a aplic rii conceptului de abstractizare se ajunge la definirea unei clase de obiecte abstracte caracterizat n mod complet de opera#iile posibile asupra acestora. Procesul de abstractizare, aplicat la nivel func#ional se manifest n mod curent n activitatea de programare prin utilizarea conceptelor de procedur sau subrutin . Procedura poate fi considerat ca o "cutie neagr " ce realizeaz o func#ie abstract . Prin abstractizare se separ ceea ce se face, de cum se face. n programul apelant este suficient s se $tie ce se face. Prin subrutinele imbricate se poate dezvolta o ierarhie de abstrac#ii.

20

La nivelul func#ional procesul de abstractizare este pus n valoare de tehnicile de proiectare top-down. Astfel, n cadrul elabor rii prin rafinare n pa$i succesivi ai programului se face abstrac#ie de modul n care este realizat o anumit func#ie sau ac#iune $i se re#in numai specifica#iile efectelor sale. Ceea ce se re#ine de la nceput este ndeosebi determinarea comportamentului unei proceduri numai n func#ie de efectele sale externe. Abstractizarea presupune delimitarea unei ierarhii de nivele, rafinarea sau detalierea acestora f cndu-se pn la nivelul cel mai de jos, respectiv nivelul opera#iilor executabile de c tre ma$in . Important este ca abstractizarea func#ional s pun ct mai bine n rela#ie aspectele func#ionale cu cele procedurale $i s asigure eficien#a n dialogul utilizator - informatician pe linia elabor rii specifica#iilor $i programelor. Actualele limbaje de definire a specifica#iilor sunt rezultate ca urmare a preocup rilor pe linia extinderii abstractiz rii n programare. Subrutinele sunt foarte potrivite pentru a descrie func#ii, opera#ii sau evenimente abstracte, dar nu convin pentru descrierea obiectelor abstracte. Ca urmare a faptului c aplica#iile manipuleaz o cantitate apreciabil de date, aceasta contribuie la cre$terea complexit #ii algoritmilor. No#iunea de dat abstract se introduce pentru a facilita procesul proiect rii sau pentru a asigura generalitatea algoritmilor. 2.2. Proiectarea schemei externe Schema extern a BD reprezint forma sub care apare schema conceptual pentru un utilizator oarecare. Programele de aplica#ie opereaz asupra elementelor schemei conceptuale prin intermediul schemei externe, avnd acces doar la acele elemente care sunt incluse n schema extern . n general, elementele care compun schema extern sunt similare celor care compun schema conceptual , depinznd totu$i de tipul de SGBD utilizat. n concep#ia CODASYL, schema extern reprezint o parte a schemei conceptuale. Articolele care compun grupurile $i nregistr rile din schema extern pot diferi de articolele care compun grupurile $i nregistr rile din schema conceptual . n cazul BDR, schema extern este realizat , n principal cu ajutorul viziunilor (viewurilor) $i al mecanismelor de acordare a drepturilor de acces la BD. 2.3. Proiectarea schemei interne Este cunoscut faptul c schema conceptual ncarc diferite forme de structurare a datelor: liniar , arborescent , re#ea, rela#ional . Memorarea datelor pe suportul fizic mbrac numai forma unei structuri liniare. De aceea, la proiectarea schemei interne a BD se pune problema modului n care s fie liniarizat schema conceptual . Metoda de liniarizare a schemei conceptuale este specific SGBD-ului utilizat. O serie de SGBD-uri, de exemplu INGRES fac apel la metodele de memorare a datelor pe suportul de informa#ie pe care le folosesc sistemele de operare gazd . Alte SGBD-uri utilizeaz metode proprii de stocare a datelor pe suportul fizic. Aceste SGBD-uri depind mai pu#in de sistemele de operare gazd , ceea ce le imprim o portabilitate sporit , comparativ cu SGBD-urile din prima categorie.

21

BAZE DE DATE CURS 3 PROIECTAREA LOGIC( A BAZELOR DE DATE 3.1 Introducere 3.1.1 Clasificarea general a modelelor de date 3.1.2 Modele logice orientate pe nregistr ri 3.1.3 Scheme $i instante 3.2 Modele logice de date 3.2.1 Obiectivele modelarii logice 3.2.2 Utilizarea modelarii logice a datelor 3.2.3 Caracteristicile tehnicilor de modelare logic a datelor 3.3 Tehnici de modelare a datelor. Modelul Entitate-Asociere 3.3.1 Entitate, atribut $i asociere 3.3.2 Modelul entitate-asociere 3.3.3 Modelul entitate-asociere extins 3.1. Introducere 3.1.1. Clasificarea general$ a modelelor de date Modelarea este o tehnic important pentru a defini cerin#ele de a analiza proiect rile alternative. Un model reprezint caracteristici de interes particular suprimnd detalii considerate relativ neimportante. Diferitele tehnici de modelare se concentreaz asupra diferitelor tipuri de caracteristici ale unui sistem, de exemplu asupra datelor, sau asupra proceselor sau asupra dinamicii. Modele de date logice. Un model de date logice este o reprezentare riguroas a semnifica#iei datelor ntr-un anumit domeniu de interes. Se mai nume$te model semantic de date deoarece accentul modelului cade pe semnifica#ia datelor (i.e. semantic ). Un model de date logice tipic reprezint entit #i, atribute $i rela#ii. O entitate este ceva care exist n lumea real , un concept, o persoan , un loc, un lucru sau un eveniment despre care noi vrem s p str m fapte. Un atribut este o proprietate sau o caracteristic a unei entit #i. Un model de date logice este reprezentat tipic folosind o tehnologie grafic . De exemplu, cutiile pot reprezenta entit #i iar s ge#ile pot reprezenta rela#ii ntre entit #i. Modele de date fizice. Modelele de fizice reprezint implementarea structurilor de date $i vizeaz optimizarea resurselor, cum ar fi spa#iul de memorie $i timpii de acces. Elementele lor includ, n general, nregistr ri fizice, fi$iere, adrese $i pointeri. Modele de activitate. Modelele de date logice $i fizice pot fi contrastate cu modele de activitate (numite $i modele func#ie sau modele proces) care reprezint procese (mai de grab dect date) $i rela#iile lor. Aceste modele se reprezint tipic printr-o nota#ie grafic n care cutiile (sau cercurile) reprezint activit #i iar arcele ntre cutii reprezint fluxul activit #ilor. Un model de actvitate se focalizeaz pe procese mai mult dect pe fluxul ntre procese. Modelele de date, pe de alt parte, se focalizeaz pe semnifica#iile entit #ilor, atributelor $i a rela#iilor de date. Tehnicile de modelare a datelor reprezint , uzual activitit #ile care folosesc datele. Dac nu indic m altfel, vom folosi termenul de model de date pentru a referi un model de date logic (mai de grab dect model de date fizic) ceea ce este consistent cu terminologia general folosit n domeniul bazelor de date.

22

3.1.2. Modele logice orientate pe nregistr$ri Modelele logice orientate pe nregistr ri descriu datele la nivel logic $i extern. Sunt utilizate trei modele de acest tip: modelul rela#ional - datele $i leg turile care le unesc sunt organizate sub forma unui tabel. Ilustr m acest model lund, ca exemplu, baza de date Conturi-Clien#i din figura 3.1: Client NUME Lupu I. Ursu D. Ursu D. Popa C. Popa C.

STRADA Oltului 2 Jiului 17 Bega 22 Dun rii 5 Some$ 10

ORAS Craiova Timisoara Timisoara Bucuresti Cluj

NUMAR 2020 3030 4040 5050 6060

Cont NUMAR POZITIE 2020 300 3030 1300 4040 1000 5050 2000 6060 600 Figura 3.1. Rela#iile client $i cont
Lupu I. Ursu D.
2020 300 3030 1300 4040 1000

Figura 3.2. Exemple de leg turi modelul re#ea - datele sunt organizate n re#ea prin nregistr ri, iar rela#iile dintre ele sunt reprezentate prin leg turi, care pot fi considerate ca pointeri. nregistr rile sunt afi$ate ca o colec#ie de grafuri oarecare. O structur re#ea este dat n figura 3.2. modelul ierarhic - datele $i rela#iile sunt reprezentate prin nregistr ri $i leg turi. nregistr rile sunt organizate sub form de arbori. 3.1.3. Scheme i instan#e n orice model este important s se fac o distinc#ie ntre descrierea bazei de date $i baza de date ns $i. Descrierea bazei de date formeaz schema bazei de date. Schema bazei de date este specificat n timpul proiect rii BD $i nu se modific niciodat . Cele mai multe modele cuprind anumite conven#ii $i metareguli pe baza c rora se construiesc schemele bazei de date, care sunt numite diagrame schem!. Fiecare element din diagrama schemei se nume$te constructor de schem! sau component! constructiv!. Conceptul de schem dintr-o baz de date corespunde no #iunii de 23

declara#ie de tip dintr-un limbaj de programare. Cnd o variabil de un tip dat ia o anumit valoare la un moment dat se spune c ea este o instan iere. n figura 3.3 se d diagrama schemei unei BD cu patru instan#e. O diagram a schemei cuprinde numai anumite aspecte ale schemei: numele fi$ierului, elemente de date $i anumite tipuri de restric#ii. Totu$i, diagrama nu specific tipul fiec rui element de date $i alte restric#ii, de exemplu, c un student din anul I trebuie s urmeze cursul de algoritmi. Datele actuale dintr-o baz de date pot fi frecvent schimbate, de exemplu, pentru baza de date din figura 3.3 se adaug noi note. studen i
NUME, PRENUME, NRLEG., GRUPA, FACULTATE , NOTE

cursuri
COD.DIS, DISCIPLINA, SECTIE , AN, FACULTATE

sec ii
COD SECTIE, DENUMIRE, FACULTATE

facultate
COD FACULTATE,NUME.FAC, ADRESA

Figura 3.3. Diagrama schemei BD studen#i Datele dintr-o baz de date la un anumit moment de timp formeaz o instan ! a bazei (stare, ocuren !). O mul#ime de instan#e a bazei corespunde la o schem! a bazei de date. n orice moment cnd vom insera, modifica valori sau $terge nregistr ri vom schimba instan a bazei de date ntr-o alt instan# a bazei de date. Cnd definim o nou baz de date, vom specifica schema bazei de date. n acest moment instan#a bazei de date este vid (nu are nici o alt dat ). Datele nc rcate prima dat n baza de date constituie instan a ini ial!. 3.2. Modele logice de date 3.2.1 Obiectivele model$rii logice Modelele de date au dou scopuri principale: de a facilita comunica#iile despre date $i de a ajuta n descoperirea semanticii datelor. Comunicarea semnifica#iei datelor. Doarece ele sunt reprezent ri riguroase, modelele de date pot fi folosite pentru a transmite unei alte persoane n#elegerea semnifica#iei datelor. Atta timp ct persoanele ce comunic sunt familiare cu nota#ia folosit n model, comunicarea va fi n#eleas . Descoperirea semanticii datelor. Construirea unui model de date cere a se r spunde la ntreb ri despre entit #i $i rela#ii. F cnd a$a, modelatorii descoper semnifica#ia datelor organiza#iei, care exist indiferent dac se ntmpl sau nu ca ele s fie nregistrate ntr-un model formal de date. Entit #ile $i rela#iile lor sunt fundamentale pentru toate organiza#iile; totu$i, semnifica#ia datelor poate r mne nedescoperit ($i probabil prost n#eleas ) pn cnd organiza#ia nu le documenteaz cu succes. 3.2.2 Utilizarea model$rii logice de date Facilitnd comunica#iile $i descoperind semantica datelor, modelarea datelor este util pentru:
l l l

cre$terea n#elegerii datelor unei organiza#ii $i a opera#iilor asupra lor documentarea resurselor de date folosirea pachetelor software 24

proiectarea sistemelor informatice integrarea resurselor de date l proiectarea $i implementarea bazelor de date n#elegerea datelor. Atunci cnd se dezvolt modele de date, att personalul de prelucrare date ct $i utilizatorii care sunt exper#i n domeniul modelului, sunt necesari. Un model de date construit de personalul care prelucreaz datei $i f cut pentru a portretiza date despre produse este diferit de unul f cut de ingineri, produc tori $i distribuitori. De fapt, modelul de date construit numai de personalul de prelucrare date este incorect $i/sau inexact. Astfel utilizatorii sunt cruciali pentru dezvoltarea cu succes a modelelor de date. Documentarea datelor. Un model de date este adesea un bun mod de a explica documentat datele. Dac tehnica de modelare este capabil $i clar , atunci modelele sale pot fi considerabil mai valabile ca $i documentare dect limbajele naturale. Evaluarea software-ului. Pe m sur ce pachetele software devin mai populare, companiile se ntreab tot mai des: " Se va potrivi acest software n mediul nostru?". R spunsul depinde de ce face software-ul $i de modelul de date rezultat. De exemplu, un pachet de contabilitate care presupune c un angajat este pl tit dintr-un singur cont (al proiectului la care lucreaz ) nu se va potrivi bine ntr-o companie ai c rei angaja#i sunt pl ti#i din mai multe conturi. Planificarea sistemelor informatice. Deoarece faciliteaz comunica#iile $i descoperirea, modele de date sunt instrumente puternice pentru planificarea sistemelor informatice $i a bazelor de date. Modelele de date sunt folosite n BSP (Business Systems Planning - IBM), SPM (Strategic Planning Methodology - Janus Martin) $i RAP (Requirements Analysis and Planning - DACOM) pentru a identifica ariile principale de date ale unei ntreprinderi. Proiectarea sistemelor informatice. Un proiect de implementare poate ad uga la un model de planificare date de nivel nalt detalii despre atribute, volume $i frecven#e de acces pentru datele din domeniul s u. Modelul detaliat rezultat poate fi transformat ntr-o proiectare de baz de date fizic . Modelarea datelor poate fi folosit! efectiv pentru a documenta mediul existent de date $i de a ajuta la proiectarea viitorului mediu de date. Modelarea datelor folosit pentru a captura mediul prezent este un proces de descoperire, iar modelarea datelor folosit pentru a proiecta viitorul mediu este o inven#ie. De exemplu, Figura 3.4. ilustreaz n mod simplu modelele prezent $i viitor. F r a explica tehnica de diagramare n acest punct, figura scoate n eviden# un mediu nou descoperit n care un distribuitor vinde numai un singur tip de produs (de ex. ma$ini de scris) $i un mediu n care responsabilit #ile distribuitorului au fost expandate pentru a include mai multe tipuri de produse (de ex. ma$ini de scris, procesoare de texte, calculatoare). n general, un model de date pentru viitor nu este o pur inven#ie ci el mp rt $e$te mult din modelul r d cin al prezentului.
l

a) mediul prezent
a) modelul prezent

b) mediul viitor
b) modelul viitor

Figura 3.4. Modelele prezent $i viitor Integrarea resurselor de date. Modelele de date pot ajuta, de asemenea, la integritatea resursei de date $i sunt folosite pentru a reprezenta schemele conceptuale. Dac 25

modelele produse de c tre proiectele de implementare folosesc o sintax consistent $i clar , atunci aceste modele mpreun dau o vedere de ansamblu despre modul n care se potrivesc datele lor mpreun , iar inconsistentele $i redundan#ele pot fi identificate $i rezolvate. Modelul de date integrate dezvoltat de c tre o ntreprindere este schema sa conceptual . Aceast vedere neutr de date poate fi mapat pe diferite structuri de baze de date fizice (scheme interne), a$a cum sunt ele implementate $i pe vederi utilizator (scheme externe). Poate fi dificil a integra resursele de date f r a folosi modele de date. Structurile fizice, de exemplu, nu prezint o imagine complet . Sus#inerea proiect$rii bazelor de date fizice. Un model de date d proiectantului de baze de date fizice informa#ii despre ce date ar trebui incluse n baza de date, ce tipuri de rela#ii structureaz baza de date $i cum se leag baza de date de alte baze de date. A construi un model de date nseamn n primul rnd a introduce date corecte n baza de date. Tehnicile de proiectare baz de date fizice se folosesc apoi pentru a asigura un acces eficient la date. 3.2.3. Caracteristicile tehnicilor de modelare logic$ a datelor O tehnic de modelare logic a datelor trebuie: s produc diagrame grafice; l s ofere o reprezentare explicit a semanticii; l s aib un nivel potrivit de detaliere; l s fie independent de Sistemul de Gestiune a Bazei de Date (SGBD); l s aib un suport automatizat; l s fie u$or de nv #at $i folosit. Diagrame grafice. Majoritatea tehnicilor de modelare de date aflate n folosin# ast zi ofer att un limbaj de modelare (cu o sintaxa bine definit , cuvinte cheie, etc.) ct $i diagrame grafice ale modelelor. Pictogramele constau din dreptunghiuri sau cercuri pentru a reprezenta entit #i $i din arce sau linii pentru a reprezenta rela#ii. Unele tehnici folosesc forme diferite pentru categorii diverse de entit #i: dreptunghiuri $i dreptunghiuri rotunjite pot fi folosite n acela$i model pentru a distinge ntre entit #i independente de identificator $i entit #i dependente de alte entit #i. Anumite tehnici folosesc conven#ii distincte pentru linii pentru diferite tipuri de rela#ii; de exemplu, linii unice pentru grup ri $i linii duble pentru rela#ii "...este un fel de...". Alte tehnici folosesc un simbol special, ca de exemplu un cerc, pentru a ar ta atributele. Reprezentarea explicit$ a semanticii. Exist un domeniu de preferin# personal pentru a reprezenta grafic ct mai bine semantica datelor. Anumite persoane prefer o mul#ime de simboluri diferite, fiecare cu o semnifica#ie special , pe cnd al#ii prefer un mun r mai mic de simboluri, care fac ca diagramele modelului s apar mai simple. Tehnica ideal de modelare de date produce diagrame model care reprezint clar semnifica#iile datelor. Diagramele pot s fie neschimb toare, dar un simbol nu poate avea mai multe semnifica#ii diferite. Nivelul potrivit de detaliere. O tehnic de modelare trebuie s ofere detalii la nivelul potrivit pentru folosin#a utilizatorului. Modelele de date pentru planificarea sistemelor informatice de nivel nalt (la nivelul companiei sau diviziei) trebuie s p streze mai pu#ine detalii dect modelele pentru proiectarea bazelor de date fizice. Tehnicile de modelare de date cele mai flexibile suport diferite nivele de detalii. De exemplu, ele pot fi folosite pentru a construi modele care arat numai entit #ile $i rela#iile de nivel nalt, dar $i modele care arat toate entit #ile, atributele detaliate $i rela#iile rafinate. Independen#a SGBD-ului. O tehnic de modelare de date trebuie s fie independent de orice SGBD particular $i trebuie s fie capabil s reprezinte modele care pot fi suportate de o varietate de SGBD-uri. Multe din tehnicile de modelare a datelor sunt independente de SGBD. Uneori, tehnicile de modelare a datelor folosite cu un SGBD particular sunt considerate de nivel general, a$a cum sunt modelul ierarhic, modelul re#ea $i modelul rela#ional.
l

26

Problema major a acestor trei tehnici este existen#a de limit ri n semantica datelor pe care le pot reprezenta. Suport automatizat. Tehnica de modelare de date ideal are suport automatizat pentru a desena diagrame, a g si inconsisten#e $i redondan# n modele, a combina modele din mai multe surse; a raporta pe model componente $i caracteristici, $i a$a mai departe. A avea suport automatizat nseamn , n general, a oferi att un limbaj pentru modele specificate ct $i a oferi interfe#e utilizator bazate pe grafic . Tehnicile de modelare de date aflate ast zi n folosin# sunt par#ial automatizate. 3.3. Tehnici de modelare a datelor. Modelul Entitate-Asociere.

3.3.1 Entitate, atribut i asociere Un model este o abstractizare a unui sistem, care capteaz cele mai importante tr s turi caracteristice ale sistemului (concepte), relevante din punct de vedere al scopului pentru care se define$te modelul respectiv. Tehnica de identificare a tr s turilor caracteristice esen#iale ale unui sistem se nume$te abstractizare. Un model de date stabile$te regulile de organizare $i interpretare a unei colec#ii de date. n proiectarea bazelor de date se folosesc, de regul , mai multe modele de date, care se pot clasifica n dou categorii: modele conceptuale de nivel nalt $i modele specializate. Un model conceptual de nivel nalt al datelor con#ine o descriere concis a colec#iilor de date care modeleaz activitatea dorit (numit schem! conceptual! de nivel nalt), f r s detalieze modul de reprezentare sau de prelucrare a datelor. Modelele specializate de date (cum sunt: modelul ierarhic, modelul re#ea, modelul rela#ional, etc.) impun anumite structuri speciale de reprezentare a mul#imilor de entit #i $i a asocierilor dintre acestea, structuri pe baza c rora sunt dezvoltate sistemele de gestiune a bazelor de date. ntr-un astfel de model de date, o baz de date este reprezentat printr-o schem conceptual (logic ) specific . Trecerea de la modelul conceptual de nivel nalt la un model de date specific reprezint etapa de proiectare logic! a bazei de date care asigur coresponden#a dintre schema conceptual de nivel nalt a bazei de date $i schema conceptual specific modelului de date respectiv. Cel mai utilizat model conceptual de nivel nalt este modelul Entitate-Asociere (E-A) care reprezint schema conceptual de nivel nalt a bazei de date prin mul#imi de entit #i $i asocieri dintre acestea. Dezvoltarea acestui model, astfel nct s permit extinderea tipurilor de entit #i, este cunosut sub numele de model Entitate-Asociere Extins (E-AE). Proiectarea modelului E-A sau al modelului E-AE este, de regul , una din primele etape n proiectarea bazelor de date, etap numit proiectarea schemei conceptuale Modelul Entitate-Asociere (Entity-Relationship Model), introdus n 1976 de P.S. Chen, este un model conceptual de nivel nalt al unei baze de date, care define$te mul#imile de entit #i $i asocierile dintre ele, dar nu impune nici un mod specific de structurare $i prelucrare (gestiune) a datelor. Elementele esen#iale ale modelului Entitate-Asociere folosit n proiectarea bazelor de date sunt entit! ile (entities) $i asocierile dintre acestea (relationships). O entitate (entity) este orice poate fi identificat n mod distinctiv"; o entitate se refer la un aspect al realit #ii obiective care poate fi deosebit de restul universului $i poate reprezenta un obiect fizic, o activitate, un concept abstract, etc. Ea se identific n mod unic printr-un nume. Orice entitate trebuie definit f r ambiguit #i $i este descris $i identificat n mod unic prin atributele sale. Un atribut (attribute) este o proprietate care descrie un anumit aspect al unei entit #i.

27

Atributele prin care este descris o entitate se aleg pe baza criteriului relevan ei relativ la domeniul de interes pentru care se define$te modelul respectiv, astfel nct s asigure diferen#ierea acelei entit #i fa# de restul universului. Toate entit #ile similare, care pot fi descrise prin acelea$i atribute, apar#in unui acela$i tip de entitate (entity type), iar colec#ia tuturor entit #ilor de acela$i tip dintr-o baz de date constituie o mul ime de entit! i (entities set). n general, n modelul E-A se folose$te aceea$i denumire att pentru un tip de entitate ct $i pentru mul imea entit! ilor de acel tip. De exemplu, tipul de entitate angajat (al unei institu#ii) reprezint orice persoan angajat a institu#iei, care are o anumit func#ie $i prime$te un anumit salariu. Acest tip de entitate poate fi descris prin mai multe atribute, dintre care o parte sunt atribute de identificare a persoanei (Nume, Prenume, DataNasterii, Adresa), iar altele sunt atribute legate de activitatea acesteia n institu#ia respectiv (Functie,Salariu). n proiectarea bazelor de date se consider dou categorii de entit #i: entit #i normale (puternice, obi$nuite - regular entities) $i entit #i slabe (dependente - weak entities). Entit #ile normale au o existen# proprie n cadrul modelului, n timp ce entit #ile slabe nu pot exista dect dac exist o entitate normal (puternic ) cu care sunt asociate. De exemplu, o entitate dependent poate s reprezinte o persoan care depinde de un angajat al unei institu#ii (adic se afl n ntre#inerea acestuia). O entitate angajat este o entitate puternic , deoarece ea exist n mod normal n modelul activit #ii institu#iei, n timp ce o entitate dependent este o entitate slab : nu se va nregistra o astfel de persoan dect dac p rintele (sus#in torul) acesteia este angajat n acea institu#ie. n proiectarea bazelor de date se definesc asocieri ntre mul#imile de entit #i componente, pentru a reprezenta anumite aspecte ale realit #ii pe care baza de date o modeleaz . O asociere (relationship) este o coresponden# ntre entit #i din dou sau mai multe mul#imi de entit #i. Gradul unei asocieri este dat de num rul de mul#imi de entit #i asociate. Asocierile pot fi binare (de gradul 2, ntre dou mul#imi de entit #i) sau multiple (ntre k mul#imi de entit #i, k > 2). Asocierile binare sunt, la rndul lor, de trei categorii, dup num rul elementelor din fiecare dintre cele dou mul#imi puse n coresponden# de asocierea respectiv (fig. 3.5). Fiind date dou mul#imi de entit #i, E1 $i E2, se definesc urm toarele categorii de asocieri binare: Asocierea unul-la-unul (one-to-one) este asocierea prin care unui element (entitate) din mul#imea E1 i corespunde un singur element din mul#imea E2, $i reciproc; se noteaz cu 1:1. Asocierea unul-la-multe (one-to-many) este asocierea prin care unui element din mul#imea E1 i corespund unul sau mai multe elemente din mul#imea E2, dar unui element din E2 i corespunde un singur element n mul#imea E1; se noteaz cu 1:N. Asocierea multe-la-multe (many-to-many) este asocierea prin care unui element din mul#imea E1 i corespund unul sau mai multe elemente din mul#imea E2 $i reciproc; se noteaz cu M:N. Cardinalitatea (multiplicitatea) unei asocieri fa# de o mul#ime de entit #i (cardinality, multiplicity) este num!rul maxim de elemente din acea mul ime care pot fi asociate cu un element din alt! mul ime a asocierii.

28

Fig. 3.5. Categorii de asocieri ntre dou mul#imi de entit #i: a - asociere 1:1; b - asociere 1:N; c- asociere M:N. De exemplu, asocierea 1:N dintre mul#imile E1 $i E2 prezint multiplicitatea 1 fa# de mul#imea E1 $i multiplicitatea N (se n#elege o valoare oarecare N > 1) fa# de mul#imea E2. Raportul dintre valorile cardinalit #ilor unei asocieri binare fa# de cele dou mul#imi de entit #i se nume$te raport de cardinalitate (cardinality ratio). Se poate observa c cele trei categorii de asocieri descrise mai sus difer ntre ele prin raportul de cardinalitate. Asocierile multiple (k-are, k > 2) prezint cte un raport de cardinalitate pentru fiecare pereche de mul#imi de entit #i pe care le asociaz . O asociere ntre dou sau mai multe mul#imi de entit #i este, n acela$i timp, o asociere ntre tipurile de entit #i corespunz toare. 3.3.2 Modelul Entitate-Asociere Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezint modelul Entitate-Asociere prin mul#imile de entit #i $i asocierile dintre acestea. Exist numeroase variante de nota#ii pentru redarea diagramei E-A. Una dintre cele mai folosite nota#ii reprezint un tip de entitate (precum $i mul#imea de entit #i de acel tip) printr-un dreptunghi, iar atributele tipului de entitate prin elipse conectate printr-o linie continu la acesta (fig. 3.6). Pentru entit #ile puternice se utilizeaz un dreptunghi ncadrat cu o linie simpl , iar pentru entit #ile slabe se utilizeaz un dreptunghi ncadrat cu linie dubl .

Fig. 3.6. Nota#iile diagramei Entitate-Asociere (E-A). O asociere (tip de asociere) dintre dou sau mai multe tipuri de entit #i se reprezint printr-un romb conectat prin link-uri (linii continue, formate din unul sau mai multe segmente) 29

la tipurile de entit #i asociate. O asociere poate s aib sau nu un nume; dac are un nume, acesta poate fi nscris n rombul respectiv sau n vecin tatea acestuia. Categoria asocierii se noteaz prin nscrierea multiplicit #ii pe fiecare link care conduce la un tip de entitate. Este posibil ca o asociere s prezinte ea ns $i atribute, $i aceste atribute se reprezint prin elipse conectate la asocierea respectiv . Exemplul 3.1. n continuare se exemplific dezvoltarea modelului conceptual de nivel nalt al unei baze de date a unei institu#ii $i diagrama E-A corespunzatoare, definind cteva tipuri de entit #i $i asocierile ntre acestea. Diagrama E-A a acestui mic model de baz de date este prezentat n figura. 3.7

Fig. 3.7. Exemplu de diagram E-A. Tipul de entitate sec#ie reprezint o unitate de organizare a institu#iei $i este un tip de entitate puternic (de sine st t toare). Acest tip se caracterizeaz prin mai multe atribute, de exemplu, un num r al sec#iei, numele sec#iei $i bugetul alocat. Mul#imea de entit #i care grupeaz toate entit #ile de acest tip se poate denumi SECTIE sau SECTII (oricare variant poate fi folosit ) $i este caracterizat prin acelea$i atribute care caracterizeaz tipul entit #ii: SECTIE(Numar, Nume,Buget) Tipul de entitate angajat reprezint o persoan angajat n institu#ie $i este de asemenea un tip de entitate puternic . Acest tip de entitate, ca $i mul#imea de entit #i care grupeaz toate entit #ile de acest tip, se poate defini astfel ANGAJAT(Nume, Prenume, DataNasterii, Adresa, Functie, Salariu) Tipul de entitate proiect reprezint o activitate a institu#iei, $i este de asemenea un tip de entitate puternic , care poate fi caracterizat prin numele proiectului, data nceperii, termen de realizare, bugetul proiectului: PROIECT(Nume, DataInceperii, Termen,Buget) Tipul de entitate dependent reprezint o persoan care depinde de un angajat al institu#iei (adic se afl n ntre#inerea acestuia). Acest tip de entitate este un tip de entitate slab : nu se va nregistra o astfel de persoan dect dac ntre#in torul acesteia este angajat n acea institu#ie. Acest tip se poate defini astfel: DEPENDENT(Nume, Prenume, DataNasterii, GradRudenie) Asocierea SECTIE-ANGAJAT este o asociere 1:N, dac se consider c o sec#ie cuprinde mai mul#i angaja#i, iar un angajat apar#ine unei singure sec#ii. Asocierea ANGAJAT-PROIECT este o asociere M:N, dac se consider c la fiecare proiect lucreaz! mai mul#i angaja#i, $i fiecare angajat poate lucra la mai multe proiecte.

30

Asocierea ANGAJAT-DEPENDENT este o asociere de tipul 1:N, deoarece un angajat poate ntre ine mai multe persoane (fii, p rin#i etc.), iar o persoan dependent este n ntre#inerea unui singur sus#in tor. Raportul de cardinalitate al unei asocieri este stabilit de proiectant astfel nct s reflecte ct mai corect modul de organizare a activit #ii modelate. De exemplu, asocierea ANGAJATI-PROIECTE are raportul de cardinalitate M:N dac n institu#ia respectiv se admite ca un angajat s lucreze la mai multe proiecte; dac s-ar impune ca un angajat s lucreze la un singur proiect, atunci asocierea respectiv ar avea raportul de cardinalitate N:1. n ambele situa#ii se admite c la un proiect lucreaz mai mul#i angaja#i. Sunt de remarcat cteva caracteristici generale ale modelului E-A: a) Modul de stabilire a tipurilor de entit #i $i a asocierilor dintre acestea nu este unic, deoarece grani#a dintre entit #i $i asocieri nu este, n general, una bine precizat . Aceea$i func#ionalitate se poate ob#ine printr-o varietate de diagrame E-A, depinznd de felul n care proiectantul dezvolt modelul conceptual. O asociere poate fi considerat $i ca un tip de entitate. De exemplu, pentru baza de date a unei facult #i ($coli) se definesc tipurile (mul#imile) de entit #i: STUDENTI(Nume, Prenume, Adresa,...) DISCIPLINE(Denumire, Credite,...) ntre aceste mul#imi de entit #i se poate defini asocierea STUDENTI-DISCIPLINE, cu raportul de cardinalitate M:N. Aceast asociere reprezint (n general) studierea unor discipline de c tre studen#i, cu atribute ca: Nota (examenului la disciplina respectiv ), DataExamen, etc. Dar, la fel de bine, este posibil s se defineasc tipul de entitate NOTE, aflat n asociere N:1 cu fiecare din tipurile de entit #i STUDENTI $i DISCIPLINE (fig. 3.8).

Fig. 3.8. Diferite moduri de definire a tipurilor de entit #i $i a asocierilor: a- asociere M:N ntre mul#imile de entit #i STUDENTI $i DISCIPLINE; b - mul#imea de entit #i EXAMENE este asociat cu raportul de cardinalitate N:1 cu fiecare din mul#imile de entit #i STUDENTI $i DISCIPLINE. b) n modelul E-A, tipul de entitate ($i mul#imea de entit #i corespunz toare) semnific un substantiv, n timp ce o asociere semnific un verb. Binen#eles, nu este obligatoriu ca numele dat unei asocieri s fie un verb ($i, de cele mai multe ori, nici nu este), dar o asociere reprezint o interac#iune ntre tipurile de entit #i ($i mul#imile de entit #i corespunz toare), care poate fi exprimat printr-un verb. De exemplu, n diagrama E-A din figura 3.7, asocierea SECTIE-ANGAJAT poate fi exprimat prin verbul cuprinde, asocierea ANGAJATIDEPENDENTI poate fi exprimat prin verbul ntre ine, asocierea ANGAJATI-PROIECTE poate fi exprimat prin verbul lucreaz! etc. c) Modelul E-A nu precizeaz modul cum sunt realizate asocierile ntre mul#imile de entit #i. Acest aspect depinde de modelul de date specializat utilizat pentru definirea bazei de date. De exemplu, n modelele ierarhic $i re#ea, asocierile sunt realizate explicit, prin pointeri de la o entitate la entit #ile asociate, n timp ce n modelul rela#ional asocierea se realizeaz prin egalitatea valorilor unor atribute comune ale entit #ilor (chei).

31

3.3.3 Modelul Entitate-Asociere Extins Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model) permite definirea de subtipuri ale unui tip de entit #i, care mo$tenesc atribute de la tipul de entitate pe care l extind ($i care, n acest context, se nume$te supertip) $i au n plus atribute specifice semnifica#iei lor. Prin definirea tipurilor $i a subtipurilor de entit #i se pot crea ierarhii de tipuri de entit #i pe mai multe niveluri. Modelul E-A prezentat mai sus este suficient pentru modelarea aplica#iilor de baze de date tradi#ionale, adic bazele de date utilizate pentru activit #i financiare $i industriale, n care se folosesc tipuri de date simple. Odat cu dezvoltarea sistemelor de baze de date, domeniile n care acestea se folosesc au devenit tot mai numeroase, ca, de exemplu: telecomunica#iile, proiectarea tehnologic , sistemele de informa#ii geografice, seviciul Web, etc. Tipurile de entit #i definite n astfel de baze de date sunt mult mai complexe $i pentru reprezentarea lor ct mai intuitiv $i mai compact au fost propuse mai multe concepte noi, care au fost introduse n modelul E-A extins. Modelul E-A extins se reprezint printr-o diagram E-A extins . Ierarhiile de tipuri se pot crea prin specializare sau generalizare. Specializarea (specialization) este un proces de abstractizare a datelor prin care, pornind de la un tip de entitate dat, se definesc unul sau mai multe subtipuri, diferen iate ntre ele n func ie de rolul specific pe care l au n modelul de date. De exemplu, pornind de la tipul de entitate ANGAJAT se definesc prin specializare subtipurile SECRETARA, TEHNICIAN, INGINER, pentru a diferen#ia func#iile pe care angaja#ii le pot avea n ntreprinderea respectiv (fig. 3.9). Litera d din marcajul de specializare a tipurilor indic o constrngere de disjunc#ie impus specializ rii, care va fi descris mai jos. Subtipurile de entit #i mo$tenesc atribute ale tipului ini#ial $i fiecare dintre ele are atribute suplimentare, specifice rolului lor. De exemplu, atributele (Nume, Prenume, DataNasterii, Adresa, Salariu) ale tipului de entitate ANGAJAT sunt mo $tenite de fiecare din subtipurile acestuia. Atributul Functie nu este mo $tenit, deoarece specializarea subtipurilor s-a efectuat dup acest atribut. Ca atribute specifice, subtipul SECRETARA are atributul VitezaRedactare, care este o m sur a calific rii, subtipul TEHNICIAN are atributul Calificare, care reprezint gradul de calificare, iar subtipul INGINER are atributul Specialitate, care este o precizare a domeniului n care lucreaz (mecanic, electric, etc.). Generalizarea (generalization) este procesul de abstractizare invers specializ!rii, prin care se creaz! un supertip de entitate pornind de la mai multe tipuri de entit! i. Pentru definirea unei generaliz ri, se identific atributele comune ale mai multor tipuri de entit #i $i aceste atribute vor caracteriza supertipul de entitate, iar atributele care difer de acestea r mn specifice fiec rui tip. De exemplu, dac au fost definite tipurile de entit #i: AUTOMOBIL (NrInregistrare, Marca, VitezaMaxima, Pret, NumarPasageri) $i CAMION (NrInregistrare, Marca, VitezaMaxima, Pret, Tonaj) se poate defini un supertip al acestor tipuri: VEHICUL(NrInregistrare,Marca, VitezaMaxima, Pret). Acest tip va cuprinde toate atributele comune, iar tipurile ini#iale, AUTOMOBIL $i CAMION, devin subtipuri ale tipului VEHICUL, fiecare con#innd atributele specifice (NumarPasageri pentru tipul AUTOMOBIL $i Tonaj pentru tipul CAMION). Rezultatul ob#inut prin generalizare este, ca $i n cazul specializ rii, o ierarhie de tipuri de entit #i; ceea ce difer este modul n care se definesc nivelurile ierarhiei.

32

Fig. 3.9. Diagrama E-A extins cu ierarhie de tipuri de entit #i. Mo$tenirea atributelor. Proprietatea principal a ierarhiilor de tipuri de entit #i create prin specializare sau generalizare este mo$tenirea atributelor: atributele tipurilor de entit #i de nivel ridicat (supertipuri) sunt mo$tenite de tipurile de entit #i de nivel sc zut (subtipuri). Mo$tenirea dintre un subtip de entit #i $i supertipul acestuia se reprezint n diagrama E-A extins printr-o leg tur (link) ntre subtip $i supertipul de entitate corespunz tor pe care este plasat un semicerc orientat c tre subtip (a$a cum se poate vedea n figura 3.9). Este evident asem narea dintre ierarhiile de tipuri de entit #i din modelul E-A extins $i ierarhiile de clase din modelul obiect-orientat, dar modelul E-A extins este un model de date mult mai general (de nivel inalt), care poate fi transpus n diferite modele de date specializate, inclusiv modelul obiect-orientat. Aceste transpuneri se fac n func#ie de suportul oferit de modelul specializat respectiv pentru reprezentarea entit #ilor, asocierilor, mo$tenirilor, etc.

33

BAZE DE DATE CURS 4 BAZE DE DATE CU STRUCTURI IERARHICE *I RE,EA 4.1. Modelul ierarhic $i baze de date ierarhice 4.2. Modelul retea $i baze de date retea

4.1. Modelul ierarhic i baze de date ierarhice Modelul ierarhic reprezint unul dintre primele modele de date $i are ca structur de baz , structura arborescent . Propriet #ile acestei structuri de date determin caracteristicile $i restric#iile modelului ierarhic. n modelul ierarhic fiec rui nod al arborelui i corespunde un tip de nregistrare, format din unul sau mai mute cmpuri, reprezentnd atribute ce descriu entit #i. Descrierea acestei structuri poate fi f cut utiliznd diagrame de structur!. n Figura 4.1 se observ c un nod p rinte poate avea subordonate mai multe noduri copil, n timp ce un nod copil poate avea un singur p rinte, ceea ce nseamn c rela#ia p rintecopil ntre tipurile de nregistr ri va fi 1 la m (unu la mul#i) $i cea copil-p rinte va fi de tipul 1 la 1 (unu la unu). Unui tip de nregistrare din diagrama de structur a modelului ierarhic i corespunde n baza de date un anumit num r de realiz!ri. Rela#iile ntre realiz rile unui cuplu p rinte-copil sunt indicate de arcele care leag cele dou componente ale diagramei. Astfel, arcul ce leag TIP_NREG_1 de TIP_NREG_2 indic faptul c unei realiz ri a tipului p rinte (TIP_NREG_1) i se pot asocia n realiz ri ale tipului copil (TIP_NREG_2) $i c o realizare a tipului copil e asociat cu o singur realizare a tipului p rinte. ntre TIP_NREG_3 $i TIP_NREG_4, rela#ia de 1 la 1 este reciproc . Acestea sunt singurele tipuri de rela#ii permise ntre realiz rile tipurilor de nregistr ri ale modelului ierarhic. TIP_NREG_1

6 TIP_NREG_2

TIP_NREG_3

TIP_NREG_4

TIP_NREG_4

Figura 4.1. Diagram de structur ierarhic Defini#ia 4.1. O baz de date ierarhic poate fi definit! ca fiind o mul ime ordonat! de realiz ri ale unui singur tip arbore. Un tip arbore const dintr-un singur tip de nregistrare r d cin , la care se adaug o mul#ime ordonat alc tuit din unul sau mai multe tipuri de subarbori dependen#i. Un tip subarbore const dintr-un tip de nregistrare r d cin $i o mul#ime ordonat alc tuit din unul sau mai multe tipuri de subarbori dependen#i $.a.m.d. Exemplul 4.1. Consider m o baz de date cu informa#ii despre sistemul de instruire a angaja#ilor unei mari companii industriale. Compania are un departament de nv # mnt care 34

desf $oar cursuri de preg tire pentru angaja#i. Fiecare curs poate fi organizat la filiale diferite ca localizare geografic .Baza de date con#ine informa#ii despre cursurile desf $urate deja $i despre cele programate a se desf $ura, informa#ii structurate ca n Figura 4.2. Tipul arbore pentru aceast baz de date are ca tip nregistrare r d cin CURS $i dou tipuri subarbore: PRELIMINAR $i PROGRAMARE. Aceast mul#ime format din dou tipuri subarbore este ordonat , adic tipul PRELIMINAR precede tipul PROGRAMARE. Tipul PRELIMINAR e alc tuit doar din r d cin . Tipul subarbore PROGRAMARE are dou tipuri subarbore dependente, ambele alc tuite din r d cin : PROF $i ANGAJAT ( de asemenea, ordonate astfel nct PROF precede ANGAJAT). Deci, baza de date con#ine cinci tipuri de nregistr ri (entit #i): CURS, PRELIMINAR, PROGRAMARE, PROF $i ANGAJAT, n care CURS este tipul de nregistrare r d cin , iar celelalte sunt tipuri de nregistr ri dependente. CURS este p rinte pentru tipurile PRELIMINAR $i PROGRAMARE. PROGRAMARE este p rinte pentru tipurile PROF $i ANGAJAT.

CURS

COD_CURS#

TITLU

PRELIMINAR COD_PRELIM# COD_P#

PROGRAMARE DATA LOCUL

COD#

PROF NUME

COD#

ANGAJAT NUME NOTA

Figura 4.2 Schema conceptual a bazei de date cu informa#ii despre sistemul de instruire a anga#ilor unei companii O realizare a arborelui const dintr-o singur realizare a tipului nregistrare r d cin mpreun cu o mul#ime ordonat alc tuit din una sau mai multe realiz ri ale fiec rui tip subarbore imediat dependent de tipul r d cin . Deci, pentru orice realizare a unui tip nregistrare p rinte, exist n realiz ri ale tipurilor nregistrare copil (n0). De exemplu, o realizare p rinte CURS poate avea dou realiz ri copil PRELIMINAR $i trei realiz ri copil PROGRAMARE (Figura 4.3). Prima realizare PROGRAMARE este la rndul ei p rinte, cu o realizare copil PROF $i trei realiz ri copil ANGAJAT. Celelalte dou realiz ri PROGRAMARE nu au copii. Toate realiz rile unui tip copil care au aceea$i realizare p rinte, se numesc gemeni. Deci, cele trei realiz ri PROGRAMARE sunt gemeni. Observ m c realiz rile PRELIMINAR nu sunt gemeni cu realiz rile PROGRAMARE, deoarece sunt de tip diferit, de$i au acela$i p rinte. Consider m un (sub)arbore T cu r d cina R $i subarborii S1, S2,,Sn n aceast ordine. Fie t o realizare a lui T cu r d cina r (o realizare a lui R) $i subarborii s1, s2,,sn, realiz ri ale lui S1, S2,, Sn. Definim recursiv secven a ierarhic! pentru t, ca fiind secven#a ob#inut al turnd nregistr rii r, toate nregistr rile lui s1, s2,,sn luate n ierarhia lor. Fiecare arbore individual din baza de date poate fi privit ca un subarbore al unei nregistr ri r d cin ini#iale. Deci baza de date poate fi considerat ca un singur arbore. 35

CURS

M23

DINAMICA

PRELIMINAR PRELIMINAR M19 M16 1 2 2001/08/13 3 2001/05/14 2001/07/12 ROGRAMARE PROGRAMARE PROGRAMARE

PROF 421633 Ionescu C.

761620

Tudor I. Vlad D.

8 9 8

183009 102141

ANGAJAT ANGAJAT ANGAJAT

Popescu M.

Figura 4.3 Realizare a arborelui asociat bazei de date din Exemplul 4.1 Secven#a ierarhic pentru arborele din Figura 4.3 este: CURS M23 PRELIMINAR M16 PRELIMINAR M19 PROGRAMARE 1 PROF 421633 STUDENT 102141 STUDENT 183009 STUDENT 761620 PROGRAMARE 2 PROGRAMARE 3 Un limbaj de manipulare a datelor ierarhice const dintr-o mul#ime de operatori de prelucrare a datelor reprezentate arborescent. Exemple de operatori: operatori pentru localizarea unui anumit arbore n baza de date (exemplu: localizarea arborelui pentru cursul M23); operatori pentru trecerea de la un arbore la altul n baza de date (exemplu: trecerea de la arborele M23 la cel care urmeaz n secven#a ierarhic n baza de date); operatori de trecere de la o nregistrare la alta ntr-un arbore, cu posibilit #i de parcurgere n sus sau n jos pe diferite c i ale ierarhiei (exemplu: operator de trecere de la nregistrarea pentru cursul M23 la prima nregistrare PROGRAMARE); operatori de trecere de la o nregistrare la alta corespunz tor secven#ei ierarhice din baza de date (exemplu: operator de trecere de la o nregistrare PROF din cadrul PROGRAMARE la o nregistrare ANGAJAT din aceea$i realizare PROGRAMARE); operatori pentru inserarea unei noi nregistr ri la o pozi#ie specific ntr-un astfel de arbore (exemplu: inserarea unei noi realiz ri PROGRAMARE); operatori de $tergere a unei nregistr ri specificate (exemplu: $tergera unei realiz ri PROGRAMARE). O caracteristic a modelului ierarhic este aceea c nici o realizare a unui nod copil nu poate s existe f r a avea asociat o realizare a nodului p rinte. Aceasta nseamn c dac un nod p rinte este $ters, automat sistemul va $terge ntregul subarbore ce are ca p rinte acel nod precum $i c o realizare a nodului copil nu poate fi inserat dac o realizare a nodului p rinte nu exist deja.

36

Avnd n vedere aceasta, precum $i rela#iile permise ntre realiz rile tipurilor de nregistr ri, pot fi enun#ate urm toarele restric ii de integritate ale modelului ierarhic: o realizare copil este ntotdeauna asociat unei singure realiz ri p rinte; dac un tip de nregistrare nu are realiz ri, atunci nici tipurile descendente de nregistr ri nu au realiz ri. Pentru ilustrarea acestor restric#ii de integritate, s consider m o baz de date cu informa#ii despre comenzile lansate de clien#i unei firme (Figura 4.4 ). CLIENTI
CLIEN'I COD_CLIEN' I# ADRESA ALTE_INF

COMENZI
COMENZI COD_COMANDA# DATA_NREG DATA_LIVR VALOARE

LEG

LEG
COD_COMANDA# COD_PROD# CANT VAL

PRODUSE
PRODUSE COD_PROD# DESCRIERE VAL

a)

b) Figura 4.4 Schema conceptual a BD

Nodul r d cin este CLIENTI, nregistrarea copil este COMENZI, iar rela#ia p rintecopil este de tipul 1: m (unu la mul#i), adic un client poate lansa mai multe comenzi firmei considerate. O comand poate s includ mai multe produse iar acela$i produs poate apare n mai multe comenzi ale aceluia$i client sau ale unor clien#i diferi#i. Deci, ntre tipurile de nregistrare COMENZI $i PRODUSE rela#ia este de tip n : m (mul#i la mul#i). Deoarece modelul ierarhic nu permite reprezentarea rela#iei de acest tip, s-a optat pentru transformarea acesteia n dou rela#ii, prin introducerea tipului de nregistrare LEG, astfel: o rela#ie de tip 1:n ntre COMENZI $i LEG $i o alta de tip 1 la 1 ntre LEG $i PRODUSE (se respect astfel restric#ia 1 conform c reia o realizare copil poate fi asociat unei singure realiz ri p rinte ). Se observ c ntr-o realizare un nod copil poate apare de 0,1 sau n ori, n timp ce n diagrama de structur , tipul de nregistrare corespunz tor apare o singur dat . n acela$i timp, dac n COMENZI nu exist realiz ri care s se refere la un produs T, nu vor exista informa#ii despre acest produs n PRODUSE. Deci informa#iile despre produse vor putea fi stocate n baza de date a firmei, numai dac exist comenzi pentru acele produse. 4.2. Modelul re#ea i baze de date re#ea Modelul re ea utilizeaz ca structur de date, structura re#ea. Re#eaua este un graf orientat alc tuit din noduri conectate prin arce. Nodurile corespund tipurilor de nregistrare $i arcele pointerilor. Modelul re#ea folose$te nregistr rile pentru a reprezenta entit #ile $i pointerii ntre nregistr ri pentru a reprezenta rela#iile dintre entit #i. Structura de date re#ea (Figura. 4.5) seam n cu structura de date arborescent , cu diferen#a c un nod dependent (copil) poate avea mai mult dect un singur p rinte. 37

O baz de date re#ea const dintr-un num r oarecare de tipuri de nregistr!ri. O nregistrare e constituit dintr-un num r oarecare de cmpuri. Un cmp este cea mai mic unitate de date care are un nume. Fiecare cmp are un tip de dat asociat. Cmpul corespunde unui atribut $i nregistrarea unei entit #i (Figura 4.6). n Figura 4.7 este reprezentat , prin intermediul unei diagrame de structur!, structura re#ea a unei baze de date cu informa#ii despre proiectele unei firme $i angaja#ii antrena#i n realizarea lor. Diagrama corespunde unui graf re#ea n care nodurile au fost nlocuite de dreptunghiuri care reprezint nregistr rile. Arcele reprezint rela#ii de tip 1:1 sau 1:n ntre nregistr ri. O tr s tur a modelului este conceptul de set utilizat ca modalitate de exprimare a rela#iilor. Un tip set (Figura 4.8) const dintr-un singur tip de nod proprietar $i unul sau mai multe tipuri de noduri dependente legate de acesta, numite tipuri membre. Figura 4.8 ilustreaz un tip set numit DEPT_STU n care DEPT este tipul propritar $i STU tipul membru. Acest set reprezint n fapt o rela#ie 1:m ntre nregistr rile DEPT $i STU. O realizare a setului este o colec#ie de nregistr ri avnd o realizare proprietar $i un num r oarecare de realiz ri membre asociate. Deci, exist o realizare a setului DEPT-STU pentru fiecare realizare a nregistr rii DEPT n baza de date (Figura 4.9).

A C D

G Figura 4.5 Structur re#ea

a)STUDENT CODS# b)STUDENT

NUMES

CODC#

PUNCTE

ADR_STU CODS# NUMES STR ORAS COD CODC# PUNCTE

Figura 4.6 Exemplu de nregistrare Dac exist un departament f r studen#i avem o realizare cu proprietar $i f r membrii. O astfel de realizare a setului se nume$te vid!.

38

PROIECT CODP# DENP

BUGET

DEPT CODD#

DEND

COD_SEF#

PROIECT-ANG CODA# ANGAJATI ADRESA

DEPART-ANG

NUMEA

SALARIU

ANG-COPII COPII CODA# NUME VRSTA

Figura 4.7 Diagram re#ea Modelul de re#ea impune restric#ia conform c reia o nregistrare nu poate fi membr a dou realiz ri ale aceluia$i tip set. Rezult c , n exemplul considerat, un student nu poate fi inclus n mai multe departamente. Totu$i, o nregistrare poate s apar#in mai multor tipuri set. Un tip de nregistrare poate fi un tip proprietar ntr-un set $i un tip membru n altul. De exemplu, n diagrama de structur din Figura 4.7, ANGAJAT este membru a dou tipuri set, PROIECT_ANG $i DEPART_ANG $i proprietar al unui tip set ANG_COPII. DEPT

DEPT-STU STU Figura 4.8 Tipul SET Astfel, o anume nregistrare ANGAJAT poate fi conectat cu nregistr rile PROIECT, DEPT $i COPII. Din setul DEPT-STU prezentat n Figura 4.8, putem spune c rui departament i apar#ine un student cunoscnd in ce realizare a setului DEPT-STU este nregistrarea STU. Un set esen ial transmite informa#ii p strnd o conexiune logic datorat existen#ei sale. Alternativa unui set esen#ial este s #inem valoarea unuia sau mai multora dintre cmpurile realiz rilor nregistr rilor proprietar, n realizarea membrului. Normal, acest cmp este o cheie extern . Un set cu astfel de informa#ii n nregistr rile membre se nume$te set pe baz! de valoare. Dac dorim s reducem redundan#a pentru a asigura integritatea datelor $i a folosi eficient spa#iul, alegem seturi esen iale. Dac nu dorim ca informa#iile s fie pierdute sau distruse, alegem seturi pe baz! de valoare.

39

MATEMATIC(

ISTORIE

S1015

S1002

S1013

S1005

S1001

Figura 4.9 Exemple de realiz ri Pentru c seturile sunt doar metode de reprezentare a rela#iilor dintre nregistr ri $i pentru c un set poate avea un singur proprietar, nu exist o cale direct de a reprezenta rela#iile de tip m:n n acest model. Deci, nu putem reprezenta rela#ia STU-CURS din Figura 4.10a) n mod direct. Totu$i exist un mod indirect pentru solu#ionarea acestei situa#ii. Astfel, cnd ntre dou tipuri de nregistr ri exist o rela#ie de tip m:n, pentru reprezentarea acesteia, vom crea un nou tip de nregistrare, numit nregistrare de intersec ie sau leg!tur!, constnd din cheile asociate, plus informa#ia de intersec#ie, adic atribute descriptive ale c ror valori depind de asociere. n Figura 4.11 apare nregistrarea de leg tur creat pentru fiecare interac#iune ntre o nregistrare STU $i un CURS. Aceast diagram arat trei tipuri de nregistr ri $i dou tipuri de seturi. Fiecare nregistrare de leg tur apar#ine celor dou seturi. STU STU

STU_CURS

a)

CURS

CURS b) Figura 4.10 Reprezentarea rela#iilor.

STU CODS# NUMES

CODC#

PUNCTE

CURS CODC# TITLU

CODFAC

AN

CODS#

CODC#

APRECIERE

LEGATURA Figura 4.11 Diagram cu dou tipuri de seturi

40

Modelul re#ea, este un model complex, dificil de folosit. Implementarea lui se face pentru limbaje de prelucrare secven#ial a nregistr rilor, ceea ce determin o prelucrare dificil a bazelor de date, o vitez redus de lucru $i spa#iu de memorie ocupat ineficient. Deoarece o re#ea este o extensie a unei ierarhii, propriet #ile semantice ale modelului re#ea sunt similare cu cele ale modelului ierarhic. De aceea, dependen#ele din re#ea sunt pu#in clare, din cauza posibilit #ii existen#ei mai multor p rin#i/proprietari. Modelul re#ea nu posed un mod explicit de tratare a agreg rii semantice, rela#iile ntre nregistr ri fiind folosite att pentru reprezentarea semantic ct $i pentru alte scopuri.

41

BAZE DE DATE CURS 5 BAZE DE DATE RELA IONALE 5.1 Considera ii generale privind modelul rela ional al datelor 5.2 Structura rela ional! a datelor. Rela ii, domenii, atribute $i schema unei rela ii. 5.3 Opera ii informatice $i booleene 5.4 Constrngeri de integritate ale rela iilor 5.5 Indexarea rela iilor 5.1 Considera!ii generale privind modelul rela!ional al datelor Modelul rela ional al datelor a fost acceptat aproape f!r! rezerve de att de speciali$tii din domeniul bazelor de date ct $i de utilizatori, nc! de la apari ia primului articol al lui Codd E. F., prin care erau puse bazele acestui model. Ideea unui model asamblist al datelor a fost lansat! de c!tre Childs D. F. n 1968, care a subliniat faptul c! orice structur! de date poate fi reprezentat! printr-una sau mai multe tabele de date, n cadrul c!rora este necesar s! existe $i informa ii de leg!tur!, n vederea stabilirii unor leg!turi ntre acestea. Acest model beneficiaz! de o solid! fundamentare matematic! (bazat pe teoria matematic! a rela iilor) $i pentru care abord!rile teoretice sunt nu numai posibile, dar $i extrem de utile. S-a constatat c!, prin utilizarea sistemelor rela ionale este posibil! atingerea unor obiective importante ale organiz!rii datelor n compara ie cu modelele ierarhice $i re ea: 1. Asigurarea unui grad sporit de independen ! a programelor de aplica ie fa ! de modul de reprezentare intern! a datelor $i metodele de acces la date. n precizarea prelucr!rilor asupra datelor, programele nu fac apel la pointeri sau alte elemente ale schemei interne a bazei de date. 2. Furnizarea unor metode $i tehnici eficiente de control a coeren ei $i redundan ei datelor. Modelul rela ional, prin tehnica normaliz!rii rela iilor permite definirea unei structuri conceptuale optime a datelor, prin care se minimizeaz! riscurile de eroare la actualizare, reducndu-se redundan a datelor. 3. Oferirea unor facilit ! i multiple de definire $i manipulare a datelor. n primul rnd modelul rela ional ofer! posibilitatea utiliz!rii unor limbaje procedurale, bazate pe algebra rela ional!, precum $i a unor limbaje neprocedurale ce au la baz! calculul rela ional. 4. Ameliorarea integrit! ii $i confiden ialit! ii datelor. Modelul rela ional realizeaz! acest lucru prin mecanisme flexibile $i eficace de specificare $i utilizare a restric iilor de integritate $i a rela iilor virtuale. Componentele modelului rela ional sunt: structura rela ional! a datelor, prin care datele sunt organizate sub forma unor tablouri bidimensionale (tabele) de date, numite rela ii, operatorii modelului rela ional, ce definesc opera iile care se pot efectua asupra rela iilor, n scopul realiz!rii func iilor de prelucrare asupra bazei de date, respectiv consultarea, inserarea, modificarea $i $tergerea datelor, precum $i restric iile de integritate care permit definirea st!rilor coerente ale bazei de date. 5.2. Structura rela!ional" a datelor. Rela!ii, domenii, atribute %i schema unei rela!ii Prezentarea structurii rela ionale a datelor impune definirea no iunilor de domeniu, atribut, rela ie $i schem! a unei rela ii.

n Figura 5.1 se prezint! un model rela ional ce corespunde unei mul imi concrete de caracteristici despre lumea real!. Orarul de zbor al avioanelor posed! o structur! de date rela ional!. Pentru fiecare linie aerian! din orarul de zbor sunt date caracteristicile: num!rul cursei, aeroportul de decolare, aeroportul de aterizare, ora decol!rii, ora ateriz!rii. Fiecare avion este determinat de mul imea valorilor de fiecare linie. Trebuie s! ne limit!m numai la acele date care pot sa apar! n definirea coloanei. Coloana cu numele, Punct de decolare (PD) con ine numele aeroporturilor liniilor aeriene considerate. Coloana Ora decolarii (OD) (respectiv, Ora ateriz!rii (OA)) exprim! ora la care are loc decolarea (respectiv, aterizarea). Coloana cu numele Punct de aterizare (PA) con ine denumirea aeroportului unde se aterizeaz!. orar Nr. Zbor(NR) 70 75 80 85 90

Punct de Decolare(PD) Bucure$ti Craiova Bucure$ti Timi$oara Timi$oara

Punct de Ora de Aterizare(PA) Decolare(OD) Craiova 16:59 Bucuresti 07 :25 Timi$oara 17 :30 Bucure$ti 07 :15 Craiova 10 :15

Ora de Aterizare(OA) 17:50 08 :25 19 :30 09 :25 13 :20

Figura 5.1 Orarul de zbor al avioanelor unei companii Defini!ia 5.1 Domeniul reprezint! o mul ime de valori, caracterizat printr-un nume $i este definit fie explicit prin enumerarea tuturor componentelor sale, fie printr-o proprietate distinctiv! a valorilor din domeniul respectiv. Pentru tabelul din Figura 5.1 se pot da urm!toarele exemple: D1={ Bucure$ti, Craiova, Timi$oara} D2={ x / xN, x [1,100]} Atributul reprezint! coloana unei tabele de date, caracterizat! printr-un nume. Numele coloanei (atributului) exprim! de obicei semnifica ia valorilor din cadrul coloanei respective. Fiec!rui nume de atribut i corespunde un domeniu Di numit domeniul atributului Ai, 1 in $i se va nota cu dom(Ai). Pentru a diferen ia coloanele care con in valori ale aceluia$i domeniu $i a elimina astfel dependen a de pozi ie n cadrul tabelei, se asociaz! fiec!rei coloane un nume distinct. Pentru tabelul din Figura 5.1 avem atributele NR, PD, PA, OD, OA $i domeniile asociate dom(NR), dom(PD), dom(PA), dom(OD), dom(OA). De exemplu, dom(PD)= { Bucure$ti, Craiova, Timi$oara} . Fie D1,D2, ,Dn domenii finite, nu neap!rat disjuncte. Produsul cartezian D1D2Dn al acestora este definit de mul imea tuplurilor <v1,v2, ,vn>, unde v1D1, v2D2, ,vnDn. Num!rul n define$te aritatea tuplului. Defini!ia 5.2 O rela ie r pe mul imile D1,D2, ,Dn este o submul ime a produsului cartezian D1D2 Dn, deci o mul ime de tupluri. Exist! $i un alt mod de a defini o rela ie, $i anume, ca o mul ime finit! de func ii. Asociem fiec!rui domeniu Di un atribut Ai $i definim rela ia r ca fiind o mul ime de tupluri { t1,t2, ,tn} , unde ti: { A1,A2, ,An}D1D2 Dn $i ti(Aj) Dj pentru orice valori ale lui i $i j. ntr-o rela ie, tuplurile trebuie s! fie distincte (nu se admit duplic!ri ale tuplurilor). De obicei, vom nota rela ia cu r sau r[A1,A2, ,An]. 2

Orarul din Figura 5.1 reprezint! un exemplu de rela ie pe care o numim orar. Con inutul informa ional al liniei nu depinde de ordinea coloanelor, de exemplu coloanele PD si PA pot fi interschimbate. Definirea unei rela ii ca o mul ime de tupluri sau ca o mul ime de func ii se refer! la mul imi care variaz! n timp (se adaug!, se $terg sau se modific! elemente). Pentru a caracteriza o rela ie este nevoie de un element nvariant n timp, iar acest invariant este dat de structura rela iei (schema rela iei). Defini!ia 5.3 Mul imea tuturor atributelor R={ A1,A2, ,An} corespunz!toare unei rela ii r o numim schema rela iei $i o not!m r(A1,A2, ,An). Schema rela iei orar se define$te astfel: orar(NR, PD, PA, OD, OA). Schema unei rela ii mai este cunoscut! $i sub numele de intensia unei rela ii, ca expresie a propriet! ilor comune $i invariante ale tuplurilor care compun rela ia. Spre deosebire de intensie, extensia unei rela ii reprezint! mul imea tuplurilor care compun la un moment dat rela ia, mul ime care este variabil! n timp. De obicei, extensia unei rela ii este stocat! fizic n spa iul asociat bazei de date, caz n care rela ia se nume$te rela ie de baz!. Exist! situa ii n care extensia nu este memorat! n baza de date. Este cazul a$a numitelor rela ii virtuale, cunoscute $i sub numele de rela ii derivate sau viziuni. Acestea sunt definite implicit, pe baza altor rela ii, prin intermediul unei expresii rela ionale iar stabilirea tuplurilor care o compun se face prin evaluarea expresiei. A$adar, putem reprezenta o rela ie printr-un tabel bidimensional n care fiecare linie corespunde unui tuplu $i fiecare coloan! corespunde unui domeniu din produsul cartezian. Num!rul atributelor define$te gradul rela iei, iar num!rul de tupluri cardinalitatea rela iei. Fiecare linie a rela iei este o multime de valori, cte una pentru fiecare nume de atribut. Linia rela iei se nume$te tuplu. n Figura 5.1 rela ia orar este format! din 5 tupluri. Unul dintre acestea, notat cu t, este definit astfel: t(NR)=75, t(PD)=Craiova, t(PA)=Bucure$ti, t(OD)=7.25, t(OA)=8.25 Valoarea concret! a tuplului t pentru atributul A o numim A-valoarea tuplului t, iar dac! t este considerat! ca func ie, atunci A-valoarea tuplului t o vom nota cu t(A). Pentru XR, restric ia tuplului t la X o not!m cu t/X sau t(X) $i o vom numi X-valoarea tuplului t. Pentru rela ia orar, consider!m un tuplu t oarecare, de exemplu primul tuplu din rela ie. { PD, PA} - valoarea tuplului t este tuplul t' pentru care t'(PD)=Bucure$ti, t'(PA)=Craiova. 5.3 Opera!ii informatice %i booleene Asupra tuplurilor unei rela ii se pot efectua urm!toarele opera ii informatice: 1. Ad"ugarea. Permite ad!ugarea de noi tupluri la o rela ie. Astfel, pentru rela ia r[A1A2, ... ,An] opera ia are forma: ADD ( r :A1=d1, A2=d2, ... ,An=dn) De exemplu, ad!ugarea unui tuplu la rela ia orar se face astfel: ADD ( orar : NR =99, PD=Oradea, PA=Bucuresti, OD=20, OA=22). Cnd ordinea atributelor este fixat! aceasta poate fi scris! n forma: ADD (orar : 99, Oradea, Bucuresti, 20,22 ) Scopul opera iei de ad!ugare este de a ad!uga un tuplu la o anumit! rela ie r, dar rezultatul ad!ug!rii nu este conform cu scopul acesteia n urm!toarele cazuri : - tuplul de ad!ugat nu corespunde schemei rela iei ; - anumite valori ale tuplului nu apar in domeniului respectiv; - tuplul de ad!ugat coincide dup! cheie cu un tuplu din rela ie. De exemplu, ad!ugarea n rela ia orar, a tuplului: 3

ADD(orar : NR:90, PD:Ia$i, PA:Sibiu, PD:16, PA:12) nu este permis!, deoarece nu se respect! prima condi ie. 2.(tergerea. Aceast! opera ie se introduce pentru a elimina anumite tupluri din rela ie. Pentru o rela ie r, opera ia are forma : DEL( r: A1=d1, A2=d2 , ... ,An=dn) Atunci cnd numele atributelor sunt ordonate, se poate scrie mai simplu: DEL(r:d1, d2 , ... ,dn) De exemplu, pentru rela ia orar, $tergerea primului tuplu, se realizeaz! astfel: DEL(orar : 70, Bucure$ti, Craiova, 16:59, 17:50) Deoarece, ntr-o rela ie, tuplurile sunt identificate unic prin valoarea unei chei, este suficient pentru a realiza $tergerea, s! definim numai valoarea cheii. Dac! K={ B1,B2,...,Bn} este o cheie, atunci se poate utiliza urm!toarea form! direct !: DEL(r : B1=c1, B2=c2, .... ,Bn=cn ) De exemplu, varianta scurt! a opera iei de $tergere din rela ia orar este: DEL( orar : 70) Dac! tuplul ce se dore$te a fi $ters, nu exist! n rela ia r atunci se genereaz! o eroare. 3. Modificarea. Se refer! la faptul c! anumite valori dintr-un tuplu se pot modifica. Pentru o rela ie oarecare r $i pentru submul imea {C1, C2, ... ,Cp} {A1, A2, ... ,An} , opera ia de modificare are forma : CH ( r : A1=d1,A2=d2,...,An=dn ; C1=c1,....,Cp=cp ) Dac! K={B1, ... ,Bn}este o cheie, atunci opera ia de modificare se poate scrie: CH ( r : B1=d1, ... ,Bm=dm; C1= c1,...,Cp=cp) Pentru rela ia orar, opera ia de modificare a primului tuplu are forma : CH( orar : NR=70, PD=Bucure$ti, PA=Craiova, OD=16:59,OA=17:50;OD=18, OA=19) sau utiliznd numai cheia rela iei: CH (orar : NR=70, OD=18, OA= 19). Asupra rela iilor dintr-o baz! de date se pot efectua urm!toarele opera ii booleene: 1. Reuniunea. Este o opera ie definit! pe dou! rela ii r $i s cu aceea$i schem! R $i const! n construirea unei noi rela ii q, cu aceea$i schem! R $i avnd drept extensie tuplurile din r $i s luate mpreun! o singur! dat !. Nota iile uzuale pentru aceast! opera ie sunt: rs, OR(r,s), UNION(r,s). Considernd tuplurile ca transform!ri, avem urm!toarea defini ie formal! a reuniunii: rs={ t | tr}{ t | ts} Exemplul 5.1 Fie orar1 $i orar2 dou! rela ii cu aceea$i schem! R(NR, PD, PA, OD, OA). orar1 NR PD PA OD OA 75 Craiova Bucuresti 07:15 08 :25 80 Bucure$ti Timi$oara 17:30 19 :30 85 Timi$oara Bucure$ti 07:15 09 :25 90 Timi$oara Craiova 10 :15 13 :20 orar2 NR 75 80 95 96

PD Craiova Bucure$ti Timi$oara Timi$oara

PA Bucuresti Timi$oara Arad Oradea

OD 07 :15 17 :30 11 :15 12 :15

OA 08 :25 19 :30 11 :25 13 :20

Prin opera ia de reuniune a celor dou! rela ii se ob ine: (orar1 orar2) NR PD PA OD 75 Craiova Bucuresti 07 :15 80 Bucure$ti Timi$oara 17 :30 85 Timi$oara Bucure$ti 07 :15 90 Timi$oara Craiova 10 :15 95 Timi$oara Arad 11 :15 96 Timi$oara Oradea 12 :15

OA 08 :25 19 :30 09 :25 13 :20 11 :25 13 :20

2. Diferen!a. Reprezint! o opera ie definit! pe dou! rela ii r $i s cu aceea$i schem! R, $i const! n construirea unei noi rela ii q, cu aceea$i schem! R $i avnd drept extensie tuplurile din r care nu se reg!sesc n s. Nota iile uzuale pentru aceast! opera ie sunt: r-s, REMOVE(r,s), MINUS(r,s). Considernd tuplurile ca transform!ri, avem urm!toarea defini ie formal! a diferen ei: r-s = { t | tr} -{ t | ts} sau r-s = { t | tr ts} Diferen a rela iilor orar1 $i orar2 din Exemplul 5.1 ne conduce la urm!toarea rela ie: NR 85 90 PD Timi$oara Timi$oara PA Bucure$ti Craiova OD 07 :15 10 :15 OA 09 :25 13 :20

3. Intersec!ia. Reprezint! o opera ie definit! pe dou! rela ii r $i s cu aceea$i schem! R, $i const! n construirea unei noi rela ii q, cu aceea$i schem! R $i avnd drept extensie tuplurile comune din r $i s. Nota iile uzuale pentru aceast! opera ie sunt: , INTERSECT(r,s), AND(r,s). Considernd tuplurile ca transform!ri, avem urm!toarea defini ie formal! a diferen ei: rs = { t | tr ts} Intersec ia rela iilor orar1 $i orar2 din Exemplul 5.1, ne conduce la rela ia: NR 75 80 PD Craiova Bucure$ti PA Bucuresti Timi$oara OD 07 :15 17 :30 OA 08 :25 19 :30

Intersec ia reprezint! o opera ie derivat!, care poate fi exprimat! prin intermediul diferen ei astfel: rs=r-(r-s) sau rs=s-(s-r). 4. Produs cartezian. Reprezint! o opera ie definit! pe dou! rela ii r $i s de schem! R, respectiv S, $i const! n construirea unei noi rela ii q, a c!rei schem! Q, se ob ine din concatenarea schemelor rela iilor r $i s iar extensia lui q se ob ine din toate combina iile tuplurilor din r cu cele din s. Nota iile uzuale pentru aceast! opera ie sunt: rs, PRODUCT(r,s), TIMES(r,s). Considernd tuplurile ca transform!ri, avem urm!toarea defini ie formal! a produsului cartezian: rs={ t | (t1r) (t2s) (t(R)=t1) (t(S)=t2)} sau rs={ t |t=t1t2 t1r t2s }

Fie pilot o rela ie cu urm!toarea extensie: pilot NUME Popa Vigu Produsul cartezian al urm!toarea rela ie: NR 75 80 85 90 75 80 85 90 PD Craiova Bucure$ti Timi$oara Timi$oara Craiova Bucure$ti Timi$oara Timi$oara

VARSTA 35 40

rela iilor orar1 din Exemplul 5.1 $i pilot, ne conduce la

PA Bucuresti Timi$oara Bucure$ti Craiova Bucuresti Timi$oara Bucure$ti Craiova

OD 07 :15 17 :30 07 :15 10 :15 07 :25 17 :30 07 :15 10 :15

OA 08 :25 19 :30 09 :25 13 :20 08 :25 19 :30 09 :25 13 :20

NUNE Popa Popa Popa Popa Vigu Vigu Vigu Vigu

VARSTA 35 35 35 35 40 40 40 40

5.4 Constrngeri de integritate ale rela!iilor Restric iile de integritate definesc condi ii pe care trebuie s! le satisfac! datele din baza de date, pentru a fi considerate corecte, coerente n raport cu lumea real! la care se refer!. Restric iile de integritate reprezint! principalul mod de integrare a semanticii datelor n cadrul modelului rela ional al datelor, mecanismele de definire $i verificare a acestor restric ii reprezentnd principalele instrumente pentru controlul semantic al datelor. Exist! dou! tipuri de restric ii, $i anume restric ii structurale care sunt inerente model!rii datelor $i restric ii de func ionare (comportament) care sunt specifice unei anumite baze de date. Restric iile structurale sunt de patru tipuri: de cheie, de referin !, de entitate $i de dependent! ntre date, din care primele trei, constituie mul imea minimal! de restric ii de integritate pe care trebuie s! le respecte un SGBD rela ional. Aceste restric ii sunt definite n raport de no iunea de cheie a unei rela ii. Defini!ia 5.4 O cheie a unei rela ii r, este o mul ime KR, astfel nct: (i) pentru orice dou! tupluri t1, t2 ale lui r t1(K)t2(K); (ii) nu exist! nici o submul ime proprie a lui K cu proprietatea (i). Altfel spus, cheia reprezint! o mul ime minimal! de atribute ale c!ror valori identific! n mod unic un tuplu ntr-o rela ie. Fiecare rela ie are cel pu in o cheie. Dac! exist! mai multe chei posibile, ele se numesc chei candidat. Una din cheile candidat va fi aleas! de administratorul bazei de date pentru a identifica efectiv tupluri $i ea va primi numele de cheie primar!. Cheia primar! nu poate fi reactualizat!. Restul cheilor vor purta numele de chei alternative sau alternate. Atributele care reprezint! cheia primar! pot fi subliniate sau urmate de semnul # n schema rela iei respective. Un grup de atribute din cadrul unei rela ii care con ine o cheie a rela iei se nume$te supercheie. Exemplul 5.2 n rela ia orar din Figura 5.1 mul imile {NR} $i {PD, PA} sunt chei. Dac! se alege {NR}drept cheie primar!, atunci {PD, PA} devine cheie alternativ!. Acest fapt se reprezint! astfel : orar(NR, PD, PA, OD, OA) sau orar(NR#, PD, PA, OD, OA). Mul imea de atribute {NR, PA} este o supercheie. Consider!m rela ia local, ce contine o mul ime de ora$e cu anumite caracteristici: 6

local Punct de Decolare(PD) Craiova Bucure$ti Timi$oara

Cod Localitate(CL) 1100 1200 1300

Jude! (JD) Dolj Ilfov Timi$

O cheie identific! tupluri $i este diferit! de un index care localizeaz! tupluri. O cheie secundar! este folosit! ca index pentru a accesa tupluri. Fie schemele rela ionale orar(NR#, PD, PA, OD, OA) $i local(PD#, CL, JD), unde NR $i PD sunt chei primare respectiv secundare pentru orar, iar PD este cheie primar! pentru rela ia local. n acest caz vom spune c! PD este cheie extern! pentru orar. n acest context, orar este denumit! rela ie care refer!, n timp ce local poart! numele de rela ie referit!. O cheie primar! poate con ine o cheie extern!. De asemenea, valorile atributului PD din rela ia orar, care reprezint ! o cheie extern! pentru aceast! rela ie, trebuie ori s! corespund! la o valoare a cheii primare din rela ia local, ori s! aib! valoarea null. De multe ori un atribut este necunoscut sau neaplicabil. Pentru a reprezenta acest atribut a fost introdus! o valoare conven ional! n rela ie, $i anume valoarea null. Modelul rela ional respect! trei restric ii de integritate structural!: - unicitatea cheii - cheia primar! trebuie s! fie unic! $i minimal!, adic! pentru o rela ie r cu cheia K, oricare ar fi tuplurile t1 $i t2, s! avem t1(K)t2(K); - integritatea entit! ii - atributele cheii primare trebuie s! fie diferite de valoarea null, deoarece unicitatea cheii impune ca la nc!rcarea unui tuplu, valoarea cheii trebuie s! fie cunoscut! pentru a putea verifica dac! tuplul figurez! deja n baza de date; - integritatea referirii - ntr-o rela ie r1 care refer! o rela ie r2 valorile cheii externe s! figureze printre valorile cheii primare din rela ia r2 sau s! fie null. n categoria, alte tipuri de restric ii se pot men iona restric iile de comportament $i dependen ele func ionale. Pentru o anumit! baz! de date, utilizatorii pot defini mai multe tipuri de restric ii de comportament: de domeniu, temporale, etc. De exemplu, n rela ia local o restric ie de domeniu se poate referi la atributul CL, $i care impune ca valorile acestui atribut s! se ncadreze ntre anumite limite. 5.5 Indexarea rela!iilor Unul din avantajele sistemelor de gestiune este acela de a elibera proiectantul bazei de date de necesitatea de a cunoa$te detaliile de organizare a datelor, prin asigurarea independen ei datelor. Totu$i, aceast! independen ! nu este complet! $i, n stadiul actual de realizare a sistemelor de baze de date, programatorii de aplica ii trebuie s! ia n considera ie influen a pe care modul de stocare $i de reg!sire a datelor l are asupra performan elor aplica iilor. ntr-o rela ie, privit! ca o colec ie de elemente n care nu sunt admise elemente duplicat (deoarece este o mul ime), opera iile de baz! sunt, ca n orice colec ie de elemente, c!utarea, inserarea $i $tergerea unui element, c!rora, desigur, le corespund opera iile (interogare, inserare, $tergere) din limbajele de manipulare a datelor n rela ii. Rela iile unei baze de date sunt memorate n fi$iere pe disc, iar comenzile de manipulare a datelor sunt transformate de SGBD n opera ii asupra fi$ierelor care stocheaz! rela iile bazei de date. Modul $i timpul de execu ie a acestor opera ii de baz! depind de modul de reprezentare a mul imii de elemente (tupluri) ale rela iei. n cazul unei mul imi reprezentate printr-o colec ie neordonat ! de elemente, timpul de c!utare a unui element cre$te propor ional cu num!rul de elemente ale mul imii, deoarece, n 7

cazul cel mai defavorabil, este necesar s! fie parcurse toate elementele colec iei pentru a g!si elementul dorit. Timpul de c!utare a unui element poate s! fie mic$orat semnificativ dac! elementele mul imii sunt ordonate; de exemplu, la reprezentarea unei mul imi ca arbore binar ordonat, limita asimptotic! a timpului de c!utare este n O(log N). Pentru inserarea unui element ntr-o mul ime, trebuie mai nti s! fie c!utat elementul respectiv n colec ia (ordonat ! sau nu) prin care este reprezentat! mul imea respectiv!; dac! exist! deja un element identic, se interzice inserarea noului element; dac! nu exist!, atunci se introduce noul element. Timpul de inserare a unui element ntr-o mul ime este compus din timpul de c!utare al unui element, la care se adaug! timpul de memorare propriu-zis. Observa ii similare se pot face privind timpul de $tergere a unui element dintr-o mul ime. n general, opera iile de c!utare, inserare $i $tergere a elementelor ntr-o mul ime se execut! mai rapid dac! elementele mul imii sunt reprezentate printr-o colec ie ordonat!. Astfel se ajunge la situa ia c!, de$i o rela ie nu presupune ordonarea tuplurilor sale, pentru accelerarea opera iilor de c!utare, inserare $i $tergere, se folosesc colec ii ordonate, ca de exemplu arbori binari ordona i sau tabele de dispersie (hash table). Un index al unei rela ii (index) este o structur! auxiliar! memorat! n baza de date care permite accesul rapid la nregistr!rile (tuplurile) rela iilor prin ordonarea acestora. La definirea unei rela ii se stabilesc dou! categorii de indexuri: indexul primar al rela iei, care determin! localizarea tuplurilor n fi$ierele bazei de date, $i zero, unul sau mai multe indexuri secundare, care nu modific! localizarea tuplurilor, dar sunt folosi i pentru reg!sirea tuplurilor dup! un criteriu dat. Index primar Indexul primar (primary index) se define$te pe unul sau mai multe atribute ale rela iei $i reprezint! cheia (eticheta) dup! care ordoneaz! tuplurile rela iei. Fiecare SGBD prevede o anumit! modalitate de reprezentare a indexului primar. n continuare se va folosi termenul de etichet! de ordonare, iar termenul de cheie de ordonare va fi evitat, pentru a nu se confunda cu cheia rela iei, ntruct este posibil s! nu reprezinte acela$i lucru, de$i, n general, sistemele SGBD definesc n mod implicit indexul primar pe cheia primar! a rela iei. Opera iile de c!utare sau $tergere n care se specific! valoarea atributului index primar se execut! de asemenea eficient: se calculeaz! mai nti grupul c!ruia i apar ine tuplul, prin aplicarea func iei de dispersie h asupra valorii atributului index, apoi se caut! pozi ia tuplului n lista nl!n uit! corespunz!toare grupului. Dup! aceasta, se continu! cu execu ii specifice opera iei: se $terge sau se cite$te tuplul g!sit. De exemplu, pentru rezolvarea interog!rii "Care este ora$ul de domiciliu al studentului cu identificatorul 200?" se g!se$te tuplul (200,Marin,Dan,Craiova) folosind valoarea indexului primar (200). Dac! ntr-o opera ie de c!utare sau $tergere nu se specific! valoarea atributului index primar, atunci c!utarea unui anumit tuplu presupune parcurgerea (n cazul cel mai defavorabil) a tuturor listelor tuturor grupurilor tabelei de dispersie. De exemplu, interogarea "Care este ora$ul de domiciliu al studentului cu numele Marin?" g!se$te tuplul (200, Marin, Dan, Craiova) parcurgnd toate tuplurile $i comparnd valoarea atributului Nume cu constanta Marin, pn! este g!sit tuplul care ndepline$te aceast! condi ie. Astfel de situa ii sunt frecvent ntlnite n aplica ii, dat fiind c! interog!rile se formuleaz! de obicei folosind un nume, nu un identificator (care este probabil cheie primar!, deci con ine indexul primar, dar este necunoscut utilizatorilor). Pentru rezolvarea mai eficient! a unor astfel de interog!ri se pot defini indexuri secundare pe acele atribute care intervin frecvent n interog!ri.

Index secundar Un index secundar pe un atribut A al unei rela ii (secondary index) este o structur! care con ine o mul ime de perechi (v,L) ordonate dup! v; fiecare pereche corespunde unui tuplu al rela iei, v este valoarea atributului A, iar L este adresa tuplului respectiv n structura indexului primar al rela iei. Un index secundar nu modific! adresa de memorare a unui tuplu (care este con inut! n structura indexului primar), dar con ine informa ii suplimentare care permit identificarea rapid! a unui tuplu dup! valoarea atributului indexului. Din punct de vedere al eficien ei opera iilor de c!utare n rela ii este avantajos s! fie definite orict de multe indexuri secundare, dar fiecare index secundar ocup! spa iu de memorare suplimentar $i trebuie s! fie actualizat la fiecare opera ie de inserare $i $tergere a unui tuplu, ceea ce nseamn! timp de execu ie suplimentar. n general, se recomand! utilizarea unui num!r ct mai mic de indexuri secundare, defini i pe atributele care intervin cel mai frecvent n condi iile de interogare. Aceast! decizie o ia proiectantul bazei de date prin analiza cerin elor din domeniul pentru care se dezvolt! baza de date $i aplica iile corespunz!toare. Dat fiind c! indexurile sunt folosite n special pentru mbun!t! irea performan elor bazelor de date $i nu fac parte din modelul rela ional de baz!, ei nu sunt cuprin$i n standardul limbajului SQL. ns! majoritatea sistemelor SGBD ncorporeaz! indexuri, con innd instruc iuni pentru crearea indexurilor de forma: CREATE [optiuni] INDEX nume_index ON tabel (lista_atribute); Forma exact! $i op iunile acestei instruc iuni variaz! de la un sistem SGBD la altul. Una din op iunile care se pot introduce n instruc iunea CREATE INDEX este op iunea UNIQUE, care specific! faptul c! nu pot exista dou! tupluri cu aceea$i combina ie de valori ale atributelor indexului, deci acele atribute reprezint! o cheie unic! a rela iei. Unele sisteme SGBD adaug! cte un index secundar pentru fiecare cheie unic!, definit! prin constrngerea UNIQUE din comanda CREATE TABLE.

BAZE DE DATE CURS 6 LIMBAJE DE INTEROGARE A DATELOR PENTRU MODELUL RELA IONAL 6.1 Algebra relationala si extensiile sale 6.1.1 Operatii ale algebrei relationale 6.2 Calculul relational 6.2.1 Calculul relational orientat pe tupluri 6.2.2 Calculul relational orientat pe domenii 6.3 Criterii de optimizare a interogarilor 6.1 Algebra rela!ional" %i extensiile sale Modelul rela ional ofer! dou! colec ii de operatori pe rela ii, $i anume: algebra rela ional! (AR) $i calculul rela ional (CR). E. F. Codd a introdus algebra rela ional! (AR) ca o colec ie de opera ii pe rela ii, fiecare opera ie avnd drept operanzi una sau mai multe rela ii $i avnd ca rezultat o rela ie. Unele opera ii ale AR pot fi definite prin intermediul altor opera ii. n acest sens, putem vorbi de opera ii baz!, precum: reuniunea, diferen a, produsul cartezian, etc. dar $i de opera ii derivate: intersec ia, diviziunea, etc. Ulterior, la opera iile standard au fost ad!ugate $i alte opera ii, numite extensii ale AR standard, precum: complementarea, splitarea (spargerea), nchiderea tranzitiv!, etc. n general, opera iile AR pot fi grupate n: - opera ii tradi ionale pe mul imi (reuniunea, intersec ia, diferen a, produsul cartezian); - opera ii rela ionale speciale (selec ia, proiec ia, join-ul etc.). n continuare vom prezenta principalele opera ii ale AR, precum $i modul lor de utilizare. 6.1.1 Opera!ii ale algebrei rela!ionale 1. Selec!ia. Reprezint! o opera ie definit! asupra unei rela ii r, $i const! n construirea unei rela ii s, cu schema identic! cu cea a rela iei r $i a c!rei extensie este constituit ! din acele tupluri din r care satisfac o condi ie men ionat! explicit n cadrul opera iei. Condi ia este n general de forma: < atribut operator de compara ie valoare>. Nota iile uzuale pentru aceast! opera ie sunt: conditie(r), r[conditie] sau RESTRICT(r,conditie). Considernd tuplurile ca transform!ri, operatorul de selec ie se poate defini astfel: A=a(r)={ tr | t(A)=a} Selec ia PD=Timisoara(orar1) aplicat! rela iei orar1 din Exemplul 5.1, ne conduce la urm!toarea rela ie: NR 85 90 PD Timi$oara Timi$oara PA Bucure$ti Craiova OD 07 :15 10 :15 OA 09 :25 13 :20

2. Proiec!ia. Reprezint! o opera ie definit! asupra unei rela ii r $i const! n construirea unei rela ii s, n care se reg!sec numai acele atribute din r specificate explicit n 10

cadrul opera iei. Suprimarea unor atribute din r poate avea ca efect apari ia unor tupluri duplicate ce vor trebui eliminate. Prin opera ia de proiec ie se trece de la o rela ie de grad n la o rela ie de grad m, mai mic dect cel ini ial. Nota iile uzuale pentru aceast! opera ie sunt: A1, A2, ,Am(r), PROJECT(r, A1, A2, ,Am). Considernd tuplurile ca transform!ri, operatorul de proiec ie se poate defini astfel: X={ t(X) | tr} Aplicarea operatorului PD,PA(orar1) rela iei orar1 din Exemplul 5.1, ne conduce la urm!toarea rela ie: PD Craiova Bucure$ti Timi$oara Timi$oara PA Bucuresti Timi$oara Bucure$ti Craiova

3. Join(Jonc!iunea sau unirea). Reprezint! o opera ie definit! pe dou! rela ii r $i s, opera ie care const! din construirea unei noi rela ii q, prin concatenarea unor tupluri din r cu tupluri din s. Se concateneaz! acele tupluri din r $i s care satisfac o anumit! condi ie. Extensia rela iei q va con ine acele tupluri care satisfac condi ia de concatenare. Nota iile uzuale pentru aceast! opera ie sunt: r><condities sau JOIN(s, r, condi ie). n general condi ia de concatenare are urm!toarea form!: < atribut din r operator de compara ie atribut din s>. n func ie de operatorul de compara ie, join-ul poate fi de mai multe tipuri. Cel mai important tip, n sensul celei mai frecvente utiliz!ri este echijoin-ul, care reprezint! o opera ie de join, dirijat! de o condi ie de forma urm!toare: <atribut din r = atribut din s>. Defini!ia 6.1 Fie rela iile r $i s de schem! R respectiv S, cu Ai R $i Bi S, dom(Ai)=dom(Bi), i=1, ... ,m. Rela ia: q(RS)={ t : tr r, ts s, astfel nct t(R)= tr , t(S)= ts , t(Ai)=t(Bi), i=1, ... ,m } se nume$te echijoin-ul rela iilor r $i s n raport cu A1=B1=,...,=Am=Bm $i se noteaz! cu r[A1=B1=,...,=Am=Bm] s. Consider!m rela ia oras, de forma urm!toare: oras PD JUDET Timisoara Timis Craiova Dolj Oradea Bihor Opera ia orar1><PD=PDoras aplicat! rela iilor orar1 din Exemplul 5.1 $i oras definit! mai sus, ne conduce la urm!toarea rela ie: NR 75 85 90 PD Craiova Timi$oara Timi$oara PA Bucuresti Bucure$ti Craiova OD 07 :15 07 :15 10 :15 OA 08 :25 09 :25 13 :20 PD Craiova Timi$oara Timi$oara JUDET Dolj Timi$ Timi$

Opera ia de join se poate exprima cu ajutorul opera iilor de produs cartezian $i selec ie, rezultatul unui join fiind acela$i cu rezultatul unei selec ii operate asupra unui produs cartezian, adic!: JOIN(r,s,condi ie)=RESTRICT(PRODUCT(r,s), condi ie) 11

Produsul cartezian reprezint! o opera ie laborioas! $i foarte costisitoare, ceea ce face ca n locul produsului s! fie utilizat join-ul ori de cte ori acest lucru este posibil. n cazul echijoin-ului, schema rela iei rezultat, con ine toate atributele celor doi operanzi $i de aceea vor exista cel pu in dou! valori egale n fiecare tuplu. Join-ul natural elimin! aceast! redundan !, fiind definit! n mod similar cu echijoin-ul cu observa ia c! atributele cu acela$i nume se trec o singur! dat! n rela ia rezultat iar extensia se compune din concatenarea tuplurile lui r cu tuplurile lui s care prezint! acelea$i valori pentru atributele cu acela$i nume. Nota ia uzual! pentru aceast! opera ie este: r><s. Joinul natural al rela iilor orar1 din Exemplul 5.1 $i oras definit! mai sus, ne conduce la urm!toarea rela ie: NR 75 85 90 PD Craiova Timi$oara Timi$oara PA Bucuresti Bucure$ti Craiova OD 07 :15 07 :15 10 :15 OA 08 :25 09 :25 13 :20 JUDET Dolj Timi$ Timi$

Join extern. Atunci cnd rela iile care particip! la join nu au proiec ii identice pe atributul de jonc iune (atributul nu are acelea$i valori n rela iile care se jonc ioneaz!), opera ia de join conduce la pierderea de tupluri, cel pu in dintr-o rela ie. Pentru a evita pierderile de informa ie a fost definit join-ul extern, ca opera ie prin care din dou! rela ii r $i s se ob ine o nou! rela ie q prin join-ul rela iilor s $i r , rela ie la care se adaug! $i tuplurile din r $i s care nu au participat la join. Aceste tupluri sunt completate n rela ia q cu valori "null" pentru atributele rela iei corespondente (r, respectiv s). Nota iile uzuale pentru desemnarea unei join extern sunt: r><s sau EXT-JOIN(r, s). Join-ul extern al rela iilor orar1 $i oras conduce la urm!toarea rela ie: NR 75 80 85 90 Null PD Craiova Bucure$ti Timi$oara Timi$oara Oradea PA Bucuresti Timisoara Bucure$ti Craiova Null OD 07 :15 17.30 07 :15 10 :15 Null OA 08 :25 19.30 09 :25 13 :20 Null JUDET Dolj Null Timi$ Timi$ Bihor

Semi-join. Aceast ! opera ie a fost introdus! de Bernstein P. A., fiind necesar! la definirea procesului de optimizare a interog!rilor. Semi-jonc iunea conserv! atributele unei singure rela ii participante la join $i reprezint! o opera ie pe dou! rela ii r $i s n urma c!reia rezult! o nou! rela ie ce con ine numai tuplurile din rela ia r care particip! la join. Nota iile uzuale pentru aceast! opera ie sunt: r >< s sau SEMIJOIN(r,s). Astfel, orar1 >< oras conduce la urm!toarea rela ie: NR 75 85 90 PD Craiova Timi$oara Timi$oara PA Bucuresti Bucure$ti Craiova OD 07 :15 07 :15 10 :15 OA 08 :25 09 :25 13 :20

4. Diviziunea. Reprezint! o opera ie din AR definit! asupra unei rela ii r de schem!: R(A1:D1 , ,Ap:Dk,Ap+1 :D1, ,An:Dm), opera ie care const! din construirea, cu ajutorul unei rela ii s(Ap+1:D1, ,An:Dm) a rela iei q(A1:D1, ,Ap:Dk). Tuplurile rela iei q, concatenate cu tuplurile rela iei s permit ob inerea tuplurilor rela iei r. 12

Nota iile uzuale pentru aceast! opera ie sunt: r s sau DIVISION(r,s). Defini!ia 6.2 Fie r $i s dou! rela ii de schem! R respectiv S, cu SR $i R'=R - S. Rela ia: r'(R')={t: ts s, trr astfel nct tr(S)=ts, tr(R')=t} se nume$te diviziunea rela iei r la s. Opera ia de diviziune este o opera ie derivat!, care se poate exprima prin intermediul diferen ei, produsului cartezian $i proiec iei astfel: rs=A1, A2, ,Ap(r) - A1, A2, ,Ap((A1, A2, ,Ap(r) s) -r) Consider!m rela iile drept $i tip de forma urm!toare: drept Pilot Dan Dan Ion Ion Mihai Tip avion AIRBUS TU154 TU154 AIRBUS TU154 tip Tip avion AIRBUS TU154

Dac! dorim s! ob inem pilo ii care au drept de zbor pe toate tipurile de avioane, calcul!m drepttip, $i rezult! rela ia: Pilot Dan Ion 5. Complementarea. Complementul unei rela ii reprezint ! mul imea tuplurilor din produsul cartezian al domeniilor asociate atributelor rela iei, care nu figureaz! n extensia rela iei considerate. Este obligatoriu ca domeniile s! fie finite. Cardinalitatea rezultatului poate fi extrem de mare, ceea ce face ca opera ia s! fie destul de rar utilizat!. Nota iile uzuale pentru aceast! opera ie sunt: r, NOT(r) sau COMP(r). S! consider!m, de exemplu, pentru rela ia drept definit! la opera ia de diviziune, urm!toarele valori ale domeniilor: Pilot={ Dan, Ion, Mihai, Andrei} Tip avion={ AIRBUS, TU154, IAR500} Complementul rela iei drept este: Pilot Dan Ion Mihai Mihai Andrei Andrei Andrei Tip avion IAR500 IAR500 AIRBUS IAR500 IAR500 AIRBUS TU154

6. Splitarea (spargerea). Este o opera ie adi ional! din AR definit! asupra unei rela ii r, $i care, pe baza unei condi ii definite asupra atributelor lui r permite construirea a dou! rela ii r1 $i r2, cu o aceea$i schem! cu r. Extensia lui r1 con ine tuplurile din r care ndeplinesc condi ia specificat!, iar r2 pe cele care nu verific! aceast! condi ie. 13

Pentru rela ia drept definit! mai sus $i condi ia Pilot="Dan", opera ia de splitare produce ca rezultat rela iile drept1 $i drept2: drept1 Pilot Dan Dan drept2 Pilot Ion Ion Mihai

Tip avion AIRBUS TU154

Tip avion TU154 AIRBUS TU154

7. nchiderea tranzitiv". Este o opera ie adi ional! din AR prin care se pot ad!uga noi tupluri la o rela ie. Opera ia de nchidere tranzitiv! presupune efectuarea n mod repetat a secven ei de opera ii: join-proiec ie-reuniune. Num!rul de execu ii depinde de con inutul rela iei. nchiderea tranzitiv! se define$te asupra unei rela ii r, a c!rei schem! con ine dou! atribute A1 $i A2 cu acela$i domeniu, $i const! n ad!ugarea la rela ia r a tuplurilor care se ob in succesiv prin tranzitivitate, n sensul c!, dac! exist! n r tuplurile <a, b> $i <b, c> se va ad!uga la r $i tuplul <a, c>. Nota iile uzuale pentru aceast! opera ie sunt: (r), r+, CLOSE(r). Prezent !m mai jos, o rela ie legatura ce ne arat ! leg!turile aeriene ntre anumite localit! i precum $i nchiderea tranzitiv! a rela iei (legatura). Legatura PD Bucuresti Bucure$ti Timi$oara Timi$oara (legatura) PD Bucuresti Bucure$ti Timi$oara Timi$oara Bucure$ti Bucure$ti

PA Ia$I Timi$oara Arad Craiova

PA Ia$i Timi$oara Arad Craiova Arad Craiova

Algebra rela!ional" O expresie a AR este constituit! dintr-o serie de rela ii, legate prin opera ii din AR. S! consider!m, de exemplu dou! rela ii r $i s cu schemele r(A, B) $i s(B, C). Cu ajutorul acestor rela ii putem defini o expresie E1 , astfel: E1=C(A=a(r><s)). n formularea unei expresii se pot introduce rela ii intermediare. De exemplu, expresia E1 se poate reprezenta cu ajutorul unor rela ii intermediare X1 $i X2, astfel: X1= r><s X2=A=a(X1) E1=C(X2) Prin calcularea unei expresii algebrice E se ob ine o rela ie unic!. Prin urmare, E reprezint! o transformare a unei mul imi de rela ii ntr-o singur! rela ie. n expresii se admit paranteze rotunde $i se presupune c! nici un operator binar nu are prioritate n execu ie fa ! de un altul cu excep ia intersec iei fa a de reuniune. Fie U mul imea tuturor atributelor care descriu un univers, D o mul ime de domenii $i fie dom o func ie complet! din U n D. Fie n continuare R={R1, R2,. .., Rp} o mul ime de scheme de rela ii diferite, unde Ri U, 1 i p $i d= {r1,r2 ,. .., rp} o mul ime de rela ii astfel nct rela ia ri este de schem! Ri. Fie o mul ime de comparatori defini i pe domeniile din D care con ine cel pu in o rela ie de egalitate $i de inegalitate pentru fiecare domeniu.

14

Defini!ia 6.3. Se nume$te algebra rela ional! n raport cu U, D, dom, R, d $i septetul B=(U, D, dom, R, d,, O), unde O este mul imea operatorilor enun a i mai sus ce folosesc atributele din U $i rela iile din d. Defini!ia 6.4. Se nume$te expresie algebric! n raport cu B orice expresie corect construit! din rela ii care apar in lui d $i rela ii constante cu schem! din U care folosesc operatori din O. Schema unei expresii depinde de schemele rela iilor care o compun. Not!m cu sch(E) schema expresiei algebrice E, care se poate defini recursiv conform urm!toarelor reguli : 1. Dac! E este ri atunci sch(E)=Ri. 2. Dac! E=E1 E2, E1 E2, E1- E2, sau c(E1) unde c reprezint! condi ii, atunci sch(E)=sch(E1). 3. Dac! E=x(E1) atunci sch(E)=X. 4. Dac! E=E1 >< E2, atunci sch(E)= sch(E1) sch(E2). 5. Dac! E=E1 E2 atunci sch(E)= sch(E1) - sch(E2). Dou! expresii sunt echivalente, dac! n urma evalu!riilor se ob ine ca rezultat aceea$i rela ie. De exemplu, expresiile: E1=C(A=a(r1><r2) E3=C(B( A=a(r1))><r2) sunt echivalente, considernd r1(A, B) $i r2(B, C). 6.2 Calculul rela!ional Calculul rela ional (CR) reprezint! o adaptare a calculului cu predicate la domeniul bazelor de date rela ionale. Ideea de baz! o constituie identificarea unei rela ii cu un predicat. Pe baza unor predicate (rela ii) ini iale, prin aplicarea unor operatori ai calculului cu predicate se pot defini noi predicate (rela ii). Spre deosebire de derivarea "procedural!" a rela iilor din cadrul AR, CR permite definirea neprocedural!, "declarativ!" a rela iilor, n sensul preciz!rii lor prin intermediul propriet! ilor tuplurilor $i nu prin maniera de derivare efectiv! acestor tupluri. 6.2.1 Calculul rela!ional orientat pe tuplu (CRT) Reprezint! varianta ini ial!, introdus! de Codd E., n care CR utilizeaz! variabile definite asupra rela iilor, variabile ale c!ror valori reprezint! tupluri de rela ie. Din acest motiv, variabilele au fost denumite variabile tuplu, iar calculul rela ional a primit numele de calculul rela ional orientat pe tuplu. Cea mai simpl! construc ie a calculului rela ional se nume$te atom (sau formul! atomic!). Un atom este constituit din termeni (constante, variabile tuplu $i operatori) $i poate avea una din urm!toarele forme: r(v), unde r numele unuei rela ii, v variabil! tuplu reprezentnd un tuplu al rela iei r. De exemplu, orar(z). v[i] comp w[j], unde v $i w sunt variabile tuplu iar comp este un operator de comparare (<, =, <=, >, >=, <>). Semnifica ia atomului este: a i-a component! a tuplului v se afl! n rela ia comp cu a j-a component! a tuplului w. De exemplu, v[2]=w[3].

15

 v[i] comp k sau k comp v[i], unde v variabil! tuplu, comp este un operator de comparare iar k o constant!. Semnifica ia atomului este: a i-a component! a tuplului v se afl! n rela ia comp cu constanta k. De exemplu, v[2]>5 sau 5< v[2]. Pe baza atomilor cu ajutorul unor operatori se pot construi formule mai complexe. n cadrul calculului rela ional orientat pe tuplu sunt utiliza i urm!torii operatori: conectorii uzuali (conjunc ia, disjunc ia, nega ia) precum $i cuantificatorii universali () $i existen iali (). Se nume$te variabil! tuplu liber! o variabil! asupra c!reia nu ac ioneaz! nici un cuantificator. O variabil! tuplu legat! reprezint! o variabil! asupra c!reia ac ioneaz! un cuantificator universal sau existen ial. Dac! F1 $i F2 sunt formule, atunci F1F2, F1 F2, F1, F2 , (sF1), (sF2), (vF1) $i (vF2) sunt formule, n care s $i v sunt variabile tuplu care apar n F1 respectiv F2 . Se nume$te expresie a calculului rela ional orientat pe tuplu o construc ie E de forma: E={ t | F(t)} unde F reprezint! o formul! din calculul rela ional orientat pe tuplu, iar t este o variabil! tuplu $i anume singura variabil! tuplu liber! din formula F. Ca $i expresiile din AR, expresiile din calculul rela ional orientat pe tuplu reprezint! defini ii ale unor rela ii. n forma prezentat! anterior, aceste expresii permit exprimarea unor rela ii infinite, adic! rela ii cu un num!r infinit de tupluri. De exemplu, expresia: Ei={ t | r(t)} semnific! rela ia format! din toate tuplurile care nu apar in lui r. Deoarece este imposibil de precizat "toate tuplurile posibile", se impune o defini ie mai clar! a expresiilor din calculul rela ional orientat pe tuplu. Se nume$te expresie bine format! o expresie de forma: E={ t | F(t)} unde F reprezint! o formul! din calculul rela ional orientat pe tuplu, iar t este singura variabil! liber! din formula F, $i n plus fiecare component! a lui t este un element al lui DOM(F). DOM(F) reprezint! o mul ime de simboluri care, fie apar explicit n F, fie sunt componente ale tuplurilor unei rela ii r, men ionat! n F. Mul imea DOM(F) este finit !. O expresie din calculul rela ional orientat pe tuplu se consider! bine format! dac! satisface urm!toarele condi ii: Fiecare component! a lui t apar ine lui DOM(F). Dac! ntr-o expresie de forma: (v)F(v), fiecare component! a variabilei v apar ine lui DOM(F), atunci v satisface F. Dac! ntr-o expresie de forma: (v)F(v), fiecare component! a variabilei v apar ine lui DOM(F), atunci v satisface F. O expresie din calculul rela ional orientat pe tuplu reprezint! defini ia unei rela ii, defini ie formulat ! prin intermediul propriet! ilor pe care le au tuplurile care compun rela ia. De exemplu, considernd rela iile r1 $i r2, cu schemele R1(A, B) $i R2(B, C) putem defini o expresie bine format! Ee, astfel: Ee={ t | (v) (s) (r(t) r1(v) r2(s) (v[1]=a) (s[1]= v[2]) (t[1]= s[2]) } Expresia Ee reprezint ! defini ia unei rela ii care con ine ca tupluri acele valori ale atributului C care au asociate n join-ul rela iilor r1 $i r2 valoarea "a" pentru atributul A. Se observ! c! expresia Ee exprim! propriet! ile tuplurilor care intr! n componen a unei rela ii $i nu modul de derivare efectiv! a acestei rela ii, a$a cum este cazul expresiilor E1 $i E3 definite mai sus, care sunt defini ii procedurale ale rela iei Ee. Exemplul 6.1. Consider!m rela iile orar1 $i oras definite mai sus. Dac! dorim s! afl!m jude ul n care se afl! un anumit Punct de decolare(PD), de exemplu Timi$oara, putem s! utiliz!m expresia E1. Aceasta se rescrie astfel: E1=JUDET(PD=Timisoara(orar1><oras)) Prin join-ul natural orar1><oras se ob ine rela ia cursa: 16

cursa NR 75 85 90

PD Craiova Timi$oara Timi$oara

PA Bucuresti Bucure$ti Craiova

OD 07 :15 07 :15 10 :15

OA 08 :25 09 :25 13 :20

JUDET Dolj Timi$ Timi$

Prin selec ia PD=Timisoara(cursa) se ob ine rela ia: aero NR PD PA OD OA 85 Timi$oara Bucure$ti 07 :15 09 :25 90 Timi$oara Craiova 10 :15 13 :20 n final, prin JUDET(aero) se ob ine rela ia: JUDET Timis

JUDET Timi$ Timi$

Aceea$i problem! o putem rezolva $i prin evaluarea expresiei Ee, care se rescrie astfel: Ee={ t | (v) (s) (r(t) orar1(v) oras(s) (v[1]=Timisoara) (s[1]= v[2]) (t[1]= s[2]) } Se observ! faptul c! s[1] identific! atributul PD din rela ia oras, v[2] identific! atributul PD, din rela ia orar1, deci se poate realiza join-ul natural al celor dou! rela ii $i apoi pe rezultatul join-ului se aplic! selec ia v[1]=Timisoara, iar pe acest rezultat se identific! t[1] cu atributul s[2] (adic! JUDET) $i proiec ia pe acest atribut conduce la rela ia: JUDET Timis Deci, cele dou! expresii conduc la acela$i rezultat. 6.2.2 Calculul rela!ional orientat pe domeniu(CRD) Calculul rela ional orientat pe domeniu utilizeaz! n construc iile sale aceia$i operatori ca $i calculul orientat pe tuplu, dar variabilele care apar n aceste construc ii sunt variabile domeniu, adic! variabile definite asupra domeniilor. O formul! atomic! reprezint! o construc ie elementar! din calculul rela ional orientat pe domeniu care poate avea una din formele: r(x1, x2, ,xn), unde r este o rela ie n-ar! $i xi, i=1, ,n sunt constante sau variabile domeniu. Semnifica ia atomului este n acest caz, urm!toarea: "Valorile variabilelor xi trebuie alese astfel nct < x1, x2, ,xn> s! fie un tuplu al rela iei r". x comp y, unde x $i y sunt constante sau variabile domeniu, iar "comp" este un operator de de compara ie (<, =, <=, >, >=, <>). n aceast! form!, atomul are semnifica ia : "Variabilele x $i y trebuie s! aib! acele valori care s! fac! expresia x comp y adev!rat!". O formul! compus! se define$te similar calculului rela ional orientat pe tuplu. O expresie din calculul rela ional orientat pe domeniu este o construc ie de forma: E={ x1x2xn | F(x1x2xn } unde x1x2xn sunt singurele variabile libere din F. S! consider!m, de exemplu dou! rela ii binare r1 $i r2, cu ajutorul c!rora definim urm!toarea expresie din calculul rela ional orientat pe domeniu: 17

E={ xy | r1(xy) (z) (r2(xy) r2(yz))} Expresia E reprezint! defini ia unei rela ii, constituit! din acele tupluri ale rela iei r1 pentru care nici una din componente nu figureaz! pe prima pozi ie n tuplurile din rela ia r2. Astfel, pentru dou! rela ii ruta1 $i ruta2 definite mai jos, expresia E se scrie: E={ xy / ruta1(xy) (z) (ruta2(xy) ruta2(yz))} ruta2 PD PA PD PA Arad Cluj Timisoara Bucuresti Iasi Bucuresti Oradea Bucuresti Timiso ara Iasi Constanta Oradea

ruta1

Evaluarea expresiei E conduce la urm!toarea rela ie: ruta PD PA Arad Cluj Iasi Bucuresti O expresie bine format! din calculul rela ional orientat pe domeniu se define$te similar expresiei bine format! din calculul rela ional orientat pe tuplu. Dup! cum se poate observa, ntre formulele din CRD $i CRT nu exist! deosebiri de fond, ci doar de nota ie (variabilelor de domeniu din CRD le corespund componentele variabilelor de tuplu din CRT $i invers). Orice formul! din CRT se poate translata ntr-o formul! din CRD $i deci ntr-o expresie algebric!. Deci, folosind algebra rela ional!, sau formule din CRD sau din CRT se pot exprima acelea$i interog!ri $i deci toate aceste formalisme sunt echivalente din punctul de vedere al puterii de expresie. Limbajul de interogare SQL este la fel de expresiv ca Algebra rela ional!, CRT $i CRD. 6.3 Criterii de optimizare a interog"rilor Utilizarea limbajelor rela ionale de manipulare bazate pe calculul rela ional sau a celor bazate pe mapping face necesar! prezen a, unor mecanisme care s! transforme cererile ntr-o form! adaptat! prelucr!rilor eficiente. Aceste mecanisme sunt de fapt ni$te mecanisme de rescriere a cererilor de date $i sunt necesare pentru optimizarea prelucr!rilor de BD, ct $i la realizarea bazelor de date distribuite, la care se folosesc mai multe tipuri de limbaje rela ionale. Optimizarea cererilor de date se realizeaz! prin parcurgerea urm!toarelor etape: - exprimarea cererilor sub forma unor expresii algebrice rela ionale; - aplicarea unor transform!ri algebrice asupra expresiilor ob inute n etapa precedent!, n scopul ob inerii unor expresii echivalente celor ini iale, dar care s! fie executate mai eficient. Exprimarea cererilor de date sub forma unor expresii din algebra rela ional! are la baz! echivalen a dintre calculul rela ional $i algebra rela ional!. Procesul de transformare a cererilor de date se realizeaz! conform unor strategii de optimizare. Opera iile din algebra rela ional!, posed! o serie de propriet! i care permit implementarea strategiilor generale de optimizare. Aceste propriet! i sunt:

18

P1. Comutativitatea opera!iilor de join %i produs cartezian E1 >< E2 E2 >< E1 E1 E2 E2 E1 P2. Asociativitatea opera!iilor de join %i produs cartezian (E1 ><E2) ><E3 E1 >< (E2 ><E3) (E1 E2) E3 E1 (E2 E3) P3. Compunerea proiec!iilor A1,,An (B1,,Bm(E)) A1,,An (E) unde: A1,..,An trebuie s! apar in! lui B1,..,Bm P4. Compunerea selec!iilor F1 (F2(E)) F1 F2 (E) Deoarece F 1 F 2 = F 2 F 1, selec iile se pot comuta: F1 (F2 (E)) F2 (F1 (E)) P5. Comutarea selec!iei cu proiec!ia Dac!, condi ia F implic! numai atributele A1,..,An, atunci: A1,,An (F (E)) F ( A1,,An (E)) Dac!, condi ia F implic! $i atributele B1,,Bm, care nu apar in de A1,,An, atunci: A1,..An (F (E)) A1,,An (F ( A1,..An, B1,..,Bm (E))). P6. Comutarea selec!iei cu produsul cartezian Dac! toate atributele men ionate n F sunt atribute ale lui E1 atunci: F (E1 E2) F (E1) E2 Dac!, n plus F este de forma F=F1 F2 $i F1 implic! numai atribute din E1, iar F2 implic! numai atribute din E2, atunci: F (E1 E2) F1 (E1) F2 (E2). Dac! F1 implic! numai atributele din E1, dar F2 implic! atribute att din E1 ct $i din E2, atunci: F (E1 E2) F2(F1(E1) E2). P7. Comutarea selec!iei cu reuniunea F(E1 E2) F (E1) F (E2) P8. Comutarea selec!iei cu diferen!a F(E1-E2) F (E1)-F (E2) P9. Comutarea proiec!iei cu produsul cartezian Dac! A1,,An reprezint ! o list! de atribute din cadrul a dou! expresii rela ionale: E1 $i E2, list ! format! din atributele apar innd lui E1 $i notate cu: B1,,Bm $i din atributele apar innd lui E2 notate cu: C 1,,Ck, atunci: A1,..,An(E1 E2) B1,,Bm(E1) C1,,Ck(E2)) P10. Comutarea proiec!iei cu reuniunea A1,..,An(E1 E2) A1,..,An(E1) A1,..,An(E2) Aceste transform!ri permit definirea unor strategii generale de optimizare a cererilor de date, strategii care se refer! la posibilit! ile de cre$tere a performan elor de execu ie a cererilor de date prin reordonarea opera iilor implicate de aceste cereri. De exemplu, prin deplasarea 19

opera iilor de selec ie ct mai n stnga expresiilor algebrice se reduce num!rul de tupluri care trebuie manipulate n procesul de executare a cererii. Se pot men iona urm!toarele strategii generale de optimizare a cererilor de date: Deplasarea opera iilor de selec ie naintea opera iilor de join. Join-ul $i produsul cartezian ac ioneaz! ca generatori de tupluri. Prin selec ie se reduce dimensiunea rela iilor la care se aplic! ace$ti generatori de tupluri, deci $i a rezultatelor ob inute. Pentru deplasarea selec iei n fa a join-ului se vor aplica propriet! ile men ionate anterior, innd cont de faptul c! un join poate fi exprimat sub forma unui produs cartezian urmat de o selec ie, iar n cazul joinului natural printr-un produs cartezian urmat de o selec ie $i o proiec ie. Deplasarea opera iilor de proiec ie naintea opera iilor de join. Este realizat ! cu ajutorul propriet ! ii de comutare a selec iei cu produsul cartezian. Prin deplasarea proiec iei n fa a join-ului se ob in o serie de avantaje $i anume: - dac! proiec ia las! intact ! cheia, opera ia de join se poate realiza mai rapid ntruct s-a redus num!rul de tupluri ce trebuie memorate $i eventual sortate; - proiec ia implic! eliminarea tuplurilor duplicate, care se poate realiza relativ u$or, de exemplu cu ajutorul unui index. Dup! eliminarea tuplurilor duplicate, join-ul va fi mai simplu, pentru c! rela iile sunt mai mici. Combinarea selec iilor multiple. Se realizeaz! cu ajutorul rela iei de compunere a selec iilor. Nu toate selec iile sunt la fel de u$or de realizat. Din aceast! cauz!, numai selec iile mai rapide trebuie grupate $i mutate n fa a opera iilor de join. Selec iile rapide sunt cele realizate cu ajutorul unor tehnici de acces direct(indexare, hash, etc). n acest caz, timpul pentru realizarea selec iilor va depinde numai de num!rul de tupluri selectate, nu $i de m!rimea ntregii rela ii. Nu se recomand! gruparea selec iilor rapide cu cele lente. De aceea, este necesar, ca nainte de combinarea selec iilor s! se estimeze viteza de realizare a fiec!rei selec ii n parte. Deplasarea selec iilor n fa a proiec iilor. Regula de mutare a selec iilor n fa a proiec iilor este dat! de proprietatea de comutare a selec iei cu proiec ia. Realizarea deplas!rii este util! atunci cnd: - exist! o serie de facilit! i n realizarea selec iei, precum accesul direct, facilit! i care ar putea fi inhibate prin opera ia de proiec ie ; - eliminarea tuplurilor duplicate ob inute prin proiec ie se realizeaz! prin sortarea tuplurilor. Selec ia reduce num!rul de tupluri care trebuie sortate, facilitnd astfel realizarea opera iei de proiec ie.

20

BAZE DE DATE CURS 7 RESTRIC II DE INTEGRITATE N BAZELE DE DATE 7.1 Dependente functionale 7.1.1 Introducere 7.1.2 Axiome de inferenta 7.1.3 Completitudinea sistemului de inferente 7.1.4 Secven e derivate 7.2 Dependente multivoce 7.3 Dependente generalizate 7.1 Dependen!e func!ionale 7.1.1 Introducere Dependen ele ntre date, ca restric ii de integritate, constituie un suport teoretic solid pentru problema de modelare informatic!. n acest sens, dependen ele func ionale au permis definirea conceptului de "structur! rela ional! optim!", $i stau la baza teoriei optimiz!rii structurii rela ionale a datelor, respectiv teoria normaliz!rii rela iilor. Cnd descriem un univers real sau conceptual printr-un model rela ional ne confrunt!m cu urm!toarea problem!: Care este mul imea de rela ii care va fi o reprezentare fidel! a schemei conceptuale $i deci a universului real f!r! ca s! risc!m problemele de consisten ! Plecnd de la regulile semantice care traduc restric iile universului modelat, proiectantul trebuie s! defineasc! dependen ele $i s! le introduc! n defini ia schemei de rela ie. Propriet ! ile dependen elor sunt propriet! i pentru schema de rela ie a bazei de date $i nu pentru o extensie oarecare, adic! aceste dependen e constituie invarian i care trebuie s! fie satisf!cute de toate extensiile legale de rela ii ale schemei. Crearea unei baze de date are dou! obiective esen iale: s! reduc! excedentul de date $i s! m!reasc! siguran a n exploatare. Orice cuno$tin ! apriori despre diferite tipuri de restric ii referitoare la totalitatea datelor poate fi de mare folos pentru atingerea acestor obiective. Un procedeu de formalizare a unor cuno$tin e despre date este dat de dependen e.n aceast! sec iune vom considera numai un singur tip de dependen e $i anume dependen a func ional!, pe care o vom numi F-dependen !, care este o generalizare a no iunii de cheie. Exemplul 7.1. Fie rela ia grafic( PILOT CURSA DATA ORA-DECOLARE ) care arat! ce pilot particip! la o cursa dat!, la o anumit! dat! $i ora la care are loc decolarea. grafic(PILOT CURSA DATA Drago $ 75 9-03 Drago$ 80 10-03 Mihai 80 8-03 Mihai 87 12-03 Mihai 75 11-03 Mircea 75 13-03 Mircea 80 12-03 Costin 85 9-03 Costin 85 13-03 Costin 90 5-03 ORA-DECOLARE ) 10:15 13:25 13:25 18:50 10:15 10:15 13:25 5:50 5:50 13:25

21

Se au n vedere urm!toarele restric ii: -o curs! are aceea$i ora de decolare (cursa 85 decoleaz! ntotdeauna la ora 5:50 ); - un pilot nu se poate afla dect ntr-o singur! curs! la o anumit! ora de decolare. Aceste restric ii sunt exemple de F-dependen e. Intuitiv vorbind, o F-dependen ! are loc cnd valorile tuplurilor dup! o mul ime de atribute definesc n mod unic valorile unei alte mul imi de atribute. Astfel, restric iile ar!tate mai sus pot fi astfel formulate: - ORA-DECOLARE depinde func ional de CURSA , - CURSA depinde func ional de { PILOT DATA ORA-DECOLARE }, - PILOT depinde func ional de { CURSA DATA }. n mod obi$nuit, ordinea acestor secven e se poate schimba $i spunem c!: { CURSA DATA} define$te n mod func ional pe { PILOT }, sau simbolic {CURSA DATA} { PILOT }. Vom da o defini ie strict! a dependen ei func ionale folosind operatorii rela ionali. Defini!ia 7.1. Fie rela ia r de schem! R, X $i Y submul imi ale lui R. Rela ia r satisface dependen a func ional! XY dac! Y(X=x(r)) are nu mai mult de o singur! ocuren ! pentru fiecare X-valoare x. n F-dependen a XY submul imea X se nume$te partea stng! iar Y se nume$te partea dreapt!. Un procedeu de a verifica c! o relatie satisface XY este dat de urm!toarea proprietate : Dac! pentu orice dou! tupluri t1,t2 r, cu t1(X) = t2(X) rezult! t1(Y)=t2(Y) atunci r satisface XY. Aceast! caracterizare st! la baza procedurii satisfie dat! mai jos. Presupunem c! rela ia r este ordonat! dup! valorile lui X , apoi dup! ale lui Y. procedure satisfie(X,Y;v) vtrue Input (t) While not eof (r) 3.1 Input { t'} 3.2 If t(X) = t'(X) then 3.2.1 If t(Y)t'(Y) then 3.2.1.1 vFalse 3.2.2 continue else 3.2.3 tt' 3.3 continue 4 Return Tabelul de mai jos arat! rezultatul aplic!rii algoritmului satisfies rela iei grafic. grafic( PILOT CURSA DATA ORA-DECOLARE ) Drago$ 75 9-03 10:15 Mihai 75 11-03 10:15 Mircea 75 13-03 10:15 22 0 1 2 3

Drago$ Mircea Mihai Costin Costin Mihai Costin

80 80 80 85 85 87 90

10-03 12-03 8-03 9-03 13-03 12-03 15-03

13:25 13:25 13:25 5:50 5:50 18:50 13:25

Rezultatul aplic!rii algoritmului satisfie este True. 7.1.2 Axiome de inferen!" Pentru orice rela ie r(R) exist! la un moment dat o familie de F-dependen e pe care le satisface r. Trebuie remarcat c!, o stare a unei rela ii poate satisface o mul ime anumit! de F-dependen e iar o alt! stare poate s! nu o satisfac!. Trebuie s! determin!m familia F de F-dependen e care satisface toate st!rile admisibile ale rela iei. Pentru a determina F sunt necesare cuno$tin e semantice despre rela ia r. De aceea trebuie s! consider!m c! familia F de F-dependen e este dat! pentru schema de rela ie R. n acest caz orice rela ie r(R) trebuie s! satisfac! toate F-dependen ele din F. Nu este evident care dintre afirma iile urm!toare este mai important! : - care este mul imea de st!ri admisibile ale unei rela ii r care define$te o F-dependen !, - care F-dependen e determin! restric iile impuse schemei de rela ie R. Num!rul de F-dependen e care pot fi aplicate unei rela ii este finit, deoarece exist! numai un num!r finit de submul imi ale lui R. Prin urmare ntotdeauna se poate determina toate F-dependen ele pe care le poate satisface o rela ie r prin triere cu ajutorul procedurii satisfie. Totu$i acest procedeu necesit! mult timp deoarece trebuie generate $i apoi testate toate submul imile schemei R. Dac! ns! sunt cunoscute cteva F-dependen e din F atunci adesea se pot g!si cele r!mase. O mul ime de F-dependen e F implic! F-dependen a XY (notat! F'(XY ) dac! orice rela ie care satisface F satisface XY . Defini!ia 7.2. O inferen ! este o regul! care arat! c!, dac! o rela ie satisface un grup de F-dependen e atunci ea satisface de asemenea un alt grup. Vom introduce $ase axiome de inferen ! pentru dependen ele func ionale. n formularea axiomelor se folosesc urm!toarele nota ii : - r - pentru rela ii $i - X, Y, Z,W - pentru submul imi ale lui R. Axioma I ( Reflexivitate ): Rela ia X(X=x(r)) are cel mult un tuplu pentru orice X-valoare x, prin urmare are loc XX. Axioma II ne d! posibilitatea s! extindem partea din stnga a unei F-dependen e XY. Axioma II ( Augmentare ): Dac! Y(X=x(r)) are cel mult un tuplu pentru orice X-valoare x $i Z este o submul ime oarecare a lui R atunci : Y(XZ=xz(r)) are nu mai mult de un tuplu $i prin urmare : XZY.

23

Exemplul 7.2. Se consider! rela ia r care satisface F-dependen a AB r(A B C D ) a1 b1 c1 d1 a2 b2 c1 d1 a1 b1 c2 d1 a3 b3 c2 d3 si prin urmare rezult! c! sunt adev!rate urm!toarele F-dependen e:AB B, AC B, DB, ACDB, ABCD B. Axioma III (Aditivitate ): Aceast! axiom! ne permite s! unim dou! F-dependen e care au partea stnga aceea$i. Dac! rela ia r satisface F-dependen ele XY $i X Z atunci ambele proiec ii Y(X=x(r)) $i Z(X=x(r)) au cel mult un tuplu pentru orice X-valoare x. Dac! YZ(X=x(r)) ar avea mai mult de un tuplu atunci cel pu in una din rela iile Y(X=x(r)) $i Z(X=x(r)) ar avea mai mult de un tuplu penntru orice X-valoare x. Prin urmare XYZ. Exemplul 7.3. Fie rela ia r din exemplul 7.2 care satisface $i F-dependen a AC atunci din axioma din A3 rezult! c! r satisface A BC. Axioma IV ( Proiectivitate ): Dac! r satisface XYZ, atunci YZ(X=x(r)) are cel mult un singur tuplu pentru orice X-valoare x. Atunci Y(YZ(X=x(r)))= Y(X=x(r)) are cel mult un tuplu, prin urmare r satisface X Y $i Z(YZ(X=x(r)))= Z(X=x(r)), deci X Z. Exemplul 7.4. Rela ia din exemplul 7.2 satisface rela ia ABC. Conform axiomei IV, r satisface rela iile AB $i AC. Axioma V ( Tranzitivitate ): Fie rela ia r care satisface F-dependen ele XY $i YZ. S! consider!m tuplurile t 1 $i t 2 din r. Dac! t 1(X)= t2(X) atunci t1(Y)= t2(Y) din care rezult ! t1(Z)= t2(Z) deci XZ. Exemplul 7.5. Rela ia r dat! mai jos satisface F-dependen ele AB $i BC. Din axioma V rezult! c! r satisface AC . r( A a1 a2 a3 a4 B b1 b2 b1 b1 C c2 c1 c2 c2 D) d1 d2 d1 d3

Axioma VI ( Pseudotranzitivitate ): Fie rela ia r care satisface F-dependen ele XY $i YZW, $i dou! tupluri t1 si t2 din r. Din condi ia t1(X)= t2(X) rezult ! t 1(Y)= t2(Y) $i analog din t1 (YZ)= t2(YZ) rezult! t1(W)= t2(W). Din t1(XZ)= t 2(XZ) rezult! t1(X)= t2(X) ceea ce implic! t1(Y)= t2(Y) $i t1(YZ)= t 2(YZ) de unde rezult! t1(W)= t 2(W). Prin urmare XZW. Prin urmare , dac! X,Y,Z $i W sunt submul imi ale lui R atunci pentru orice rela ie r de schem! R sunt adev!rate urm!toarele axiome de inferen !: A1. Reflexivitate: XX, A2. Augmentare: XY XZ Y, A3. Aditivitate : X Y %i X Z X YZ, A4. Proiec!ie: XYZ XY %i XZ, A5. Tranzitivitate: XY,YZ XZ, A6. Pseudotranzitivitate: XY ,YZW XZW. 24

Folosind axiomele A1-A6 se poate ob ine alte F-dependen e. Exemplul 7.6. Fie rela ia r de schem! R $i X,Y R. Din axioma A1 rezult! YY, aplicnd axioma A2 ob inem XYY. Din proiec ie rezult! c! dac! YXR atunci XY pentru orice rela ie. Exemplul 7.7. Fie rela ia r de schem! R $i X,Y,ZR. Presupunem c! r satisface F dependen ele XY $i XY Z atunci din axioma A6 rezult! c! XX Z adic! XZ. Exemplul 7.8. Pentru a nega o afirma ie referitoare la o F-dependen ! este suficient s! ar!t!m c! , exist! cel putin o rela ie care nu satisface aceast! inferen !. Dac! neg!m afirma ia, c! din XY WZ rezult! X Z d!m contraexemplul dat de rela ia r care satisface ABCD dar nu pe AC. r(A B C D) a1 b1 c1 d1 a2 b2 c2 d1 a1 b2 c2 d1 Anumite axiome pot fi deduse unele din altele. De exemplu tranzitivitatea rezult! din axioma A6 lund Z=. Axioma de pseudotranzitivitate rezult! din axiomele A1, A2, A3 $i A5. 1 X Y (dat!) 2 YZW (dat!) 3 ZZ ( A1 ) 4 XZZ (A2 la 3) 5 XZ Y ( A2 la 1) 6 XZYZ (A3 la 4 $i 5) 7 XZW (A5 la 2 $i 6). n paragraful urm!tor vom ar!ta c! sistemul de axiome A1-A6 este complet, adic! orice F-dependen ! implicat! de F poate fi ob inut! prin aplicarea de un num!r finit de ori a axiomelor A1-A6 unor F- depende e din F.

7.1.3. Completitudinea sistemului de axiome Fie F o mul ime de F-dependen e pentru rela ia r de schem! R. Defini!ia 7.3. Se nume$te nchidere a lui F, notat! F+, cea mai mic! mul ime de Fdependen e pe R care con ine F $i orice aplicare a axiomelor A1-A6 la elementele ei, nu mai genereaz! o alt! F-dependen ! care s! nu o con in!. Deoarece F+ este finit! o putem calcula plecnd de la F, prin aplicarea axiomelor A1,A2,A6 pn! nu mai rezult ! nici o nou! F-dependen !. nchiderea lui F depinde de schema R, de exemplu dac! R=AB atunci F+ va con ine pe B B dar nu $i pe C C. Cnd schema R nu este definit! explicit se presupune c! este format! din mul imea tuturor atributelor utilizate n dependen ele care compun pe F.

25

Defini!ia 7.4. O F-dependen ! XY este derivat! din F dac! XYF+ (sau c! F determin! pe XY). Definitia 7.5. Spunem c! F implic! XY ($i se noteaz! cu F'( XY) dac! orice rela ie care satisface F atunci satisface XY. Din Axiomele lui armstrong se pot deduce $i alte reguli. Dintre care foarte utile sunt lemele urm!toare. Lema 7.1. Este adev!rat! urm!toarea formul! (descompunerea): dac! F'( XY $i ZY, atunci F'( XZ Demonstra ie. Din ZY rezult! prin reflexivitate YZ $i aplicnd tranzitivitatea se ob ine XZ. Lema 7.2. X A1,A2, , AkX Ai pentru 1 i k. Demonstra ia se face prin induc ie dup! k aplicnd lema 7.1 $i A3(aditivitatea). Deoarece axiomele de inferent! sunt adev!rate $i dac! F determin! XY atunci F implic! XY. n continuare vom ar!ta c! axiomele A1-A6 ne permit s! deducem toate Fdependen ele implicate de F. Pentru a demonstra acest rezultat va trebui s! ar!t!m cum se construie$te pentru F o rela ie care satisface F+ $i nici o alt ! rela ie n plus. Definitia 7.6. Spunem c! XY este o F-dependent! pe R dac! X,YR. F este o mul ime de F-dependen e pe R dac! pentru orice F- dependent! XY din F atunci X,Y R. Definitia 7.7. Dac! F este o multime de F-dependen e pe R $i G multimea tuturor Fdependen elor posibile pe R, atunci se nume$te exterior a lui F mul imea F- =G-F+. F-depeneden a XY pe R se nume$te trivial! dac! XY. Orice rela ie r(R) satisface dependen a trivial! XY. Dac! F este o mul ime de F-dependen e pe R $i X este o submul ime a lui R atunci exist! o F-dependen ! XY n F+ astfel nct Y s! fie maximal!. Pentru orice alt! F-dependen ! XZ din F+ rezult! c! ZY. Acest rezultat se nume$te nchiderea lui X n raport cu F, se noteaz! cu X+ $i con ine ntodeauna pe X. Lema 7.3. XY rezult! din axiomele lui Armstrong daca $i numai dac! YX+. Demonstra ia rezult! din defini ii $i aplicnd lema 7.2. Exemplul 7.9. Fie F={A D, AB DE, CE G, E H} atunci AB+= ABDEH. Intr-adev!r ABAB ABDE ABABDE ABE EH ABABDEH Teorema 7.1. (completitudine). Sistemul de axiome A1-A6 este complet. Adic! F'(X Y XYF+.

26

Demonstra ie. Fie F o mul ime de F-dependen e pe R. Pentru orice XYF- vom determina o rela ie r(R) care satisface F+ dar nu pe XY. Prin urmare nu exist! F-depenedn ! implicat! de F care s! nu fie derivat! din F. Fie schema R= A1A2...An $i ai,bi elemente distincte din dom(Ai), 1 i n $i rela ia r format! din dou! tupluri t $i t. Tuplul t=< a1, a2, ,an> iar tuplul t este definit de t=
+ a i daca Ai X + bi daca Ai X

Mai nti vom ar!ta c! r nu satisfce XY. Din defini ia lui r rezult! c! t(X)=t(X). Presupunem prin absurd c! t(Y)=t(Y). Atunci t(Y) are numai componente ai $i prin urmare Y.X+. Dar X X+ $i din proiectivitate rezult! c! X+Y $i din tranzitivitate rezult! c! XYF+ contradic ie cu faptul c! XYF-. Vom ar!ta c! r satisface toate F-dependen ele din F+. Va trebui s! consider!m numai acele F-dependen e WZ n care WX+.Din proiectivitate rezult! c! X+W $i din tranzitivitate rezult! c! X+Z prin urmare Z X+ $i deci t(Z)=t(Z), deci r satisface F+. Corolar 7.1. Pentru orice mul ime de F-dependen e F pe schema R exist! o rela ie r( R) care satisface F+ dar nu satisface F-. Pentru a verifica c! mul imea de F-dependen e F'(XY va trebui s! verific!m dac! XYF+. Aceast! variant! dureaz! foarte mult. Este de dorit un procedeu de verificare a apartenen ei lui XY la F+ f!r! a genera toate dependen ele care o compun. Nucleul algoritmului l reprezint! o procedur! de calcul a nchiderii lui X n raport cu F. Dup! ce s-a calculat X+ se verific! dac! F'(XY. Procedura closure dat! mai jos returneaz! X+ n raport cu F. 1 PROCEDURE Closure(X,F;X+) 2 DV 3 DNX 4 WHILE DVDN 4.1 DV DN 4.2 FOR fiecare W ZF IF DN W THEN DNDN Z CONTINUE 4.3 CONTINUE 5 X+DN 6 RETURN Procedura closure este utilizat! n func ia termen de testare a apartenen ei lui XY la F+. 0 FUNCTION termen(F, XY) 1 CALL closure(X,F;X+) 2 IF Y X+ THEN 2.1 termen true ELSE 2.2 termen false 3 RETURN 27

Un alt algoritm, utilizat pentru a decide dac! o dependen ! XY poate fi dedus! logic din F, arat! c! este suficient s! calcul!m X+ $i s! vedem, conform lemei 7.3 dac! Y X+ sau nu. Algoritmul 7.1. Fie X o mul ime de atribute $i F o mul ime de dependen e func ionale. 1. Se face X(0)=X $i i=0. 2. Dac! exist! n F o dependen ! VW cu VX(i) $i W-X(i) , atunci se face X(i+1)=X(i) W; i=i+1 $i se reia pasul 2; altfel STOP(X+=X(i)). Exemplul 7.10. Fie X=BD $i F avnd urm!toarele dependen e func ionale: 1)ABC, 2)CA, 3)BCD, 4)ACDB, 5) DEG, 6) BEC, 7)CGBD, 8) CEAG. Aplicnd algoritmul 7.1, se ob ine mai nti X(0)=BD, apoi folosind dependen a 5), X(1)=BDEG, $i n continuare, folosind dependen a 6), X(2)=BCDEG. Folosind dependen a 2) se ob ine X(3)=ABCDEG pentru care nu mai sunt ndeplinite condi iile din pasul 2. Deci (BD)+=ABCDEG. 7.1.4. Secven!e derivate Dac! F'( XY atunci XY fie este con inut! n F, fie poate fi ob inut! prin aplicarea unei secven e de inferen e la anumite F-dependen e din F. Aceas a secven ! de aplicare a axiomelor $i a F-dependen elor rezultate se nume$te derivata lui XY din F. Defini!ia 7.8. O secven ! P de F-dependen e pe R este derivat! din F, dac! orice F-dependen ! din P este fie un termen din F, fie este rezultat! din F-dependen ele care o preced n secven ! prin aplicarea uneia dintre axiomele de la A1 la A6. Defini!ia 7.9. Se nume$te derivat! a F-dependen ei XY din F o secven ! de Fdependen e derivate din F care o con in. Deci F '( XY dac! exist! o derivat! din F care o con ine. Exemplul 7.10. Fie F ={AB C, AD G, BC E, C D, DE K }. Urm!toarea secven ! este o derivat! a lui ABDK: 1. ABC (dat!) 2. CD (dat!) 3. ABD (tranzitivitate din 1 $i 2) 4. BB ( reflexivitate) 5. ABB (augmentare din 4) 6. ABBC (trazitivitate din 4 $i 5) 7. BC E (dat!) 8. ABE (tranzitivitate din 6 $i 7) 9. ABDE (aditivitate din 6 $i 8) 10. DEK (dat!) 11. AB K (tranzitivitate din 9 $i 10) 12. ABDK (aditivitate din 3 $i 11 ) 13. ABBE (aditivitate din 1 $i 8)

28

n continuare se folose$te o alt! mul ime complet! de inferen e care nu este o submul ime a lui A1...A6 unde inferen ele sunt numite B_axiome. Fie r(R) $i submul imile X,Y,Z,W ale schemei R $i un atribut A din R Vom ar!ta apoi c! axiomele lui Armstrong A1,A2,A6 se deduc din B_axiomele B1, B2,B3 : B1. Reflexivitatea : XX, B2. Acumularea : XYZ, ZAW XAYZ, B3. Proiec!ie : X YZ X Z sau XY. A1. Reflexivitatea, aceea$i cu B1. A2. Augmentarea : 1: XZXZ (B1) 2: XY=A1 A2 ..An (dat!) 3: XXYZ (aplic!m de n ori B2 la 1 $i 2) 4: XZY (aplicam B3 la 3) A6. Pseudotrazitivitate : 1. XZXZ 2. XY=A1A2..Am 3. XZXYZ 4. YZW= C1C2..Ck 5. XZXYZW 6. XZW

(B1) (dat!) (aplic!m de m ori B2 la 1 $i 2) (dat!) (aplic!m de k ori B2 la 3 $i 4) (aplic!m B3 la 5)

Deoarece sistemul de B-axiome este complet ntotdeauna se poate g!si o derivare care s! utilizeze numai B1,B2,B3 dac! F'(XY. Exemplul 7.11. Fie F mul imea din exemplul 7.10. Atunci: 1. CE CE (reflexivitate) 2. CD (dat!) 3. CECDE (acumulare din 1 $i 2) 4. CEDE (proiectivitate din 3) 5. DEK (dat!) 6. DEDEK (acumulare din 4 $i 5) 7. AB AB (reflexivitate) 8. ABC (dat!) 9. AB ABC (acumulare 7 $i8) 10. BC E (dat!) 11. ABABCE (acumulare din 10 $i 11) 12. ABABCDE (acumulare din 4 $i 12) 13. ABABCDEK (acumulare din 5 $i 12) 14. ABDK (proiectivitate din 13) este o derivat! pentru care se utilizeaz! numai B-axiome.

29

7.2 Dependen!e multivoce Exist! situa ii n care $i n lipsa dependen elor func ionale se poate da o descompunere a schemei care mic$oreaz! redundan a $i conserv! informa iile. Se consider! schema de rela ie R=[Uzina, Vnz!tor, Produs] notat! pe scurt R=[U,V,P] $i rela ia r( U V P ) u1 v1 p1 u1 v2 p2 u1 v1 p2 u1 v2 p1 u2 v2 p1 Un tuplu t=<u,v,p> din rela ia r arat! c! uzina u fabric! produsul p $i l aprovizioneaz! pe vnz!torul v. Se presupune c! o uzin! fabric! mai multe produse $i aprovizioneaz! mai mul i vnz!tori. Avem dou! func ii independente, de fabricare $i vnzare. fabricare ( U u1 u1 u2 P) p1 p2 p2 vnzare(U u1 u1 u2 V) v1 v2 v2

Evident c! rela ia r con ine o anumit! redundan !. Prin urmare, dac! uzina u1 aprovizioneaz! un nou vnz!tor v3 , este necesar s! creeze dou! tupluri pentru fiecare produs. Defini!ia 7.10. Fie schema de rela ie R= [A1,A2,,An] $i o parti ie [X,Y,Z] a schemei R cu X $i Y care nu se intersecteaz!. Se spune c! rela ia r satisface dependen a multivoc! (MV-dependen a) X Y sau X Z dac! din apartenen a tuplurilor <x,y,z> $i <x,y,z> la rela ia r rezult! c! $i tuplurile <x,y,z> $i <x,y,z> apar in lui r. Pentru rela ia r avem U P $i U V. dac! un vnz!tor se aprovizioneaz! de la uzin! el are n vedere toate produsele fabricate de uzin!. dac! un produs este fabricat de o uzin! el trebuie avut n vedere de to i vnz!torii care se aprovizioneaz! de la uzina respectiv!. toate produsele fabricate de o uzin! sunt comercializabile de to i vnz!torii care se aprovizioneaz! de la uzin!. D!m n continuare o defini ie formal!: Defini!ia 7.11. Fie schema de rela ie R $i X,YR ,XY=, Z=R-XY. Rela ia r(R) satisface dependen a multivoc! (pe scurt: MV-dependen !) X Y dac!: (i) () t1 ,t2 r, t1(X)=t2(X) () t3r astfel nct t3(X)=t1(X), t3 (Y)=t1(Y), t3(Z)=t2(Z) (ii) () t1 ,t2r, t1(X)=t2 (X) () t4r astfel nct t4(X)=t1(X), t4(Y)=t2(Y), t4(Z)=t1(Z). Exemplul 7.12 Pentru a n elege mai bine acest tip de dependen ! ntre atributele unei rela ii se va considera o rela ie CSL (Curs-Student-Laborator) cu urm!toarea ipotez! de lucru: "Studen!ii utilizeaz! pentru un anumit Curs acela$i material pentru Laborator". Este evident c! n rela ia CSL nu exist! dependen e func ionale n schimb setul de valori pentru Laborator care corespund unei singure valori pentru Curs este independent de valorile pentru atributul Student. Aceast ! proprietate este considerat ! o restric ie foarte important ! numit ! dependen ! multivaloare.

30

CSL Curs C1 C1 C1 C1 C1 C1 C2 C2 Student S1 S1 S1 S2 S2 S2 S3 S4 Laborator Ll L2 L3 Ll L2 L3 L4 L4

Pentru exemplul considerat dependen a mutivaloare implic! faptul c! n cazul n care apar n rela ia CSL tuplurile (C1,S1,L1) $i (C1,S2,L3) trebuie s! apar! obligatoriu $i tuplurile (C1,S2,L1) respectiv (C1,S1,L3). Din punct de vedere semantic acest lucru este posibil dac! accept!m ipoteza de lucru "Laboratorul pentru un curs trebuie s! fie aceea$i indiferent de student". Dependen a multivaloare poate fi abordat ! $i din alt punct de vedere, n scopul punerii n evident! a unei metode de testare a existen ei acesteia ntr-o rela ie dat!. Fie R(XYZ) o rela ie cu m+n+r atribute, unde X={Xl,X2 ,...,Xm}, Y{Yl,Y2 ,...,Yn} $i Z={Zl,Z2 ,...,Zr} sunt seturi de atribute disjuncte dou ! cte dou!. Un m-tuplu (x1x2 ... xm) de valori ale atributelor X1, X2, ... ,Xm se noteaz! x, un n-tuplu (y0 y2 ...yn) de valori ale atributelor Yl, Y2, ... ,Yn se noteaz! y iar un r-tuplu (z1 z0 ...zr) de valori ale atributelor Z0, Z2, ... ,Zr se noteaz! z. Se noteaz! Yxz=={y(x,y,z)R} Folosind aceste nota ii, dependen a multivaloare poate fi redefinit!: n rela ia R(XYZ) exist! o dependen ! multivaloare X Y dac! $i numai dac! n orice moment Yxz = Yxz pentru fiecare x,z $i z pentru care Yxz $i Yxz sunt seturi nenule de atribute. Se observ! imediat c! aceast ! defini ie implic! independen a setului de valori pentru atributul Y puse n coresponden ! cu o valoare a atributului X de valorile atributului Z, deci cele dou! defini ii ale dependen ei multivaloare sunt echivalente. Cea de a doua defini ie are avantajul c! permite testarea imediat! a existen ei dependen ei multivaloare ntr-o rela ie dat!. Exemplul 7.13 Se consider! rela ia CSL din exemplul anterior. Aplicnd a doua defini ie pe e$antionul de date prezentat, se ob ine: LABORATORC1S1={L1,L2,L3} LABORATORC1S2={L1,L2,L3} LABORATORC2S3={L4} LABORATORC2S4={L4} LABORATOR C1S1 = LABORATOR C1S 2 CURS LABORATOR C 2T 3 = LABORATOR C 2T 4

LABORATOR

Dependen ele multivaloare au urm!toarele propriet"!i: P1) Dac! X $i Y sunt mul imi disjuncte ale atributelor din rela ia R(XYZ) $i exist! dependen a func ional! X>Y, atunci exist! $i dependen a multivaloare X Y, deci dependen a func ional! este un caz particular de dependen ! multivaloare. 31

Demonstra ie: Proprietatea rezult ! imediat din analiza defini iilor pentru cele dou! tipuri de dependen e. Din defini ia dependen ei func ionale rezult! imediat c! pentru o valoare dat! a lui X, Yxz va con ine ntotdeauna o valoare unic!. Se poate deci spune c! dependen a func ional! este un caz particular al dependen ei multivaloare $i anume cazul n care setul de valori asociat unui atribut se reduce la o valoare unic!. P2) Dac! n rela ia R(XYZ) exist! X Y atunci obligatoriu exist! $i X Z.

Demonstra ie: X Y nseamn! c! n orice moment valorile lui Y care corespund unei anumite valori a lui X formeaz! o mul ime independent! de valorile lui Z ata$ate aceleea$i valori a lui X. Dar aceasa nseamn! c! este adev!rat! $i afirma ia invers! adic! mul imea valorilor lui Z ata$ate unei anumite valori a lui X nu depinde de valorile lui Y ata$ate aceleea$i valori a lui X adic! X Z. Observa !ie: Aceast ! proprietate justific! nota ia X Y/Z.

Exemplul 7.14 n rela ia CSL mul imea studen ilor ce audiaz! un curs $i mul imea laboratoarelor la un curs sunt independente conform ipotezei de lucru considerate, deci: CURS STUDENT $ i CURS LABORATOR Cele dou! expresii pot fi scrise ntr-o singur! expresie $i anume: CURS STUDENT/LABORATOR P3) O rela ie R(XYZ) unde X,Y,Z sunt seturi de atribute, poate fi descompus! f!r! pierdere de informa ie din proiec iile sale R[XY] $i R[XZ] printr-o jonc iune natural! dup! X dac! $i numai dac! rela ia R suport! dependen a multivoc! X Y/Z. Formal aceast! proprietate poate fi scris! sub forma: X Y/Z R(XYZ)=R[XY] ><X R[XZ] Exemplul 7.15 Fie rela ia CSL $i proiec iile sale: CS CURS C1 C1 C2 C2 CL CURS C1 C1 C1 C2

STUDENT S1 S2 S3 S4

LABORATOR L1 L2 L3 L4

Atunci FINAL=CS><CURSCL FINAL CURS C1 C1 C1 C1 C1 C1 C2 C2

STUDENT S1 S1 S1 S2 S2 S2 S3 S4

LABORATOR L1 L2 L3 L1 L2 L3 L4 L4

32

P4) n orice rela ie R(XY) unde XY=) exist! dependen e multivaloare X Y numite $i dependen e triviale. Axiome de inferen!" pentru dependen!e multivoce

$i

Primele $ase axiome de inferen ! introduse mai jos sunt analoage cu axiomele pentru Fdependen e, dar numai primele trei sunt afirma ii identice cu cele de la F-dependen e. Fie r o rela ie de schem! R $i X,Y,Z,W submul imi ale lui R . Y. M1. Reflexivitate: Rela ia r satisface X M2. Augmentare: Dac! r satisface X Y , atunci ea satisface XZ Y, pentru orice ZR. M3. Aditivitate: Dac! r satiface X Y $i X Z atunci ea satisface X YZ. M4. Proiectivitate: Dac! r satisface X Y $i X Z atunci ea satisface X YZ $i Y-Z. X M5. Tranzitivitate : Dac! r satisface X Y $i X Z atunci r satisface X Z-Y. M6. Pseudotranzitivitate : Dac! r satisface X Y $i YW Z atunci r satisface XW Z-(YW). M7. Complementaritate : Dac! r satisface X Y $i Z=R-XY atunci r satisface X Z. Axiomele M1 $i M2 rezult! direct din prima defini ie a MVdependen elor. Ar!t!m c! axioma M3 este adev!rat !. Fie rela ia r care con ine tuplurile t1 $i t2 pentru care t 1(X)=t2(X). Trebuie s! ar!t!m c! r con ine tuplul t astfel ca t(X)=t1(X), t(YZ)=t1(YZ) $i t(U)=t2(U) unde U=R=(XYZ). ntruct r satisface X Y ea trebuie s! con in! tuplul t3 astfel ca: t 3(X)=t1(X), t3(Y)=t1(Y), t3(V)=t2(V) unde V=R-(XY). Din rela ia X Z rezult! c! exist! tuplul t4 astfel ca: t 4(X)=t1(X), t4(Z)=t1(Z), t4(W)=t2(W) unde W=R-(XZ. Lu!m t=t4 . Evident t(X)=t4(X), t4(Z)=t1(Z)=t(Z), t4(XW)=t2 (XW)= t1(XW)=t(XW) astfel ca t 4(XZ)=t(XZ) . ntruct UWV avem t4(U)=t3(V)=t 2(V)=t(V). Deoarece R=XYZU, atunci t4=t. Axiomele M3 $i M7 pot fi folosite la demonstrarea axiomei M4. Dac! r satisface X Y $i X Z atunci conform axiomei M3 X YZ $i conform axiomei M7 r satisface X V, V=R-(XYZ). Folosind din nou M3 rezult! c! r satisface X VZ. Din ultima aplica ie a axiomei M7 rezult! c! X R-(XVX). Prin schimbare $i ordonare rezult! M4. R-(XVZ)=R(X{R-(XYZ)}Z)=R-(X{R-Y}Z)= Y-(XZ)=(Y-Z)-X. Prin urmare r satisface X (Y-Z)-X, de aici rezult! X Y-Z. Din X Y cu ajutorul axiomei M7 ob inem X W, unde W=R-(XY). Combinat! cu X Y-Z cu ajutorul axiomei M3 ob inem X W(Y-Z). Din nou folosind axioma M7, avem X R(XW(Y-Z)). Schimbnd ordinea ob inem : R-(WX(Y-Z))=R-(X{R-(XY)}(Y-Z))=R-(X{R-Y}(Y-Z))=Y-(X(Y-Z))=(YZ)-X. Prin urmare satisface X (YZ)-X $i prin urmare X YZ. Pentru demonstrarea axiomei M5 la nceput ar!t!m c! dac! n r exist! tuplurile t1 $i t2 astfel ca t1 (X)=t2(X), atunci r con ine tuplul t astfel ca t(X)=t1(X), t(YZ)=t 1(YZ), t(W)=t2(W). Din X Y rezult! c! exist! tuplul t3 pentru care t3(X)=t1(X), t3(Y)=t1(Y) $i t3(V)=t2(V), unde V=R-(XY). Prin urmare X Z rezult! c! exist! tuplul t4 pentru care t4(Y)=t1(Y), t4(Z)=t1 (Z) $i t 4(U)=t3(U), unde U=R-(XZ) . ntruct pentru fiecare atribut AX, tuplurile t1, t2, t3 au acelea$i valori avem t4(X)=t1(X). Evident t4(YZ)=t 1(YZ). Dar deoarece WU-XV atunci t4(W)=t2(W). Prin urmare t 3 este tuplul c!utat. Noi ar!t!m c! r satisface X YZ. Folosind axioma M4 $i X Y ob inem c! X Z-Y. Exemplul 7.16. Fie R=ABCDE $i F={A BC,DE C}. Din A complentarit! i ob inem A DE. Mai departe din tranzitivitate avem A 33 BC cu ajutorul C. Cu ajutorul

axiomei de augmentare ob inem c! DA C. Prin urmare aplicarea repetat! a axiomelor BE. Prin urmare F|=AD BE . atrage dup! sine AD Ne vom limita la numai formularea rezultatelor despre completitudinea sitemului de inferen e pentru MV-dependen e. Teorema 7.2 Sistemul de inferen e M1-M7 pentru MV-dependen e este complet . Demonstra ia este asem!n!toare ca la F-dependen e. Ca $i n cazul dependen elor func ionale, exist! un criteriu foarte simplu pentru a vedea dac! o descompunere n dou! componente este f!r! pierderi la uniune $i n cazul dependen elor multivoce, dup! cum rezult! din teorema urm!toare. Teorema 7.3. Fie R o schem! rela ional!, D o mul ime de dependen e func ionale $i multivoce pe mul imea atributelor lui R $i =(R1,R2) o descompunere a lui R. Atunci este f!r! (R1-R2). pierderi la uniune dac! $i numai dac! (R1R2) Demonstra ie. Descompunerea este f!r! pierderi la uniune dac! $i numai dac!, pentru orice rela ie r ce satisface D $i pentru orice dou! tupluri t $i s din r, exist! un tuplu astfel nct u[R1]=t[R1] $i u[R2]=s[R2]. Dar tuplul u exit! dac! $i numai dac! t[R1R2]=s[R1R2], ceea ce duce la dependen a multivoc! din enun ul teoremei. Se ntlnesc situa ii cnd sunt valabile dependen e multivoce pe componente ale unei descompuneri f!r! a fi valabile pe rela ia ini ial!. Aceste dependen e se numesc dependen e ascunse. O rela ie r de tipul schemei rela ionale R satisface o dependen ! multivoc! ascuns! X Y|z dac! dependen a multivoc! X Y este satisf!cut! de rela ia XZY(r). 7.3. Dependen!e generalizate Pn! acum am definit dependen ele func ionale $i dependen ele multivaloare. n afar! de acestea, se mai poate considera dependen a impus! de condi ia de descompunere f!r! pierderi la uniune a unei scheme rela ionale, numit! dependen ! de uniune $i notat! >< (RhR2,...,Rk), care este satisf!cut! de rela ia r con inut actual al rela iei R1 ... Rk dac! $i numai dac! uniunea natural! a proiec iilor lui r pe fiecare Ri este egal! cu r. Toate aceste tipuri de dependen e pot fi exprimate unitar prin dependen ele generalizate pe care le definim n continuare. O dependen ! generalizat! peste schema rela ional! A1...An este o expresie de forma (t1,...,tk)|t, unde fiecare ti, este un n-tuplu de simboluri $i t este fie un alt tuplu, caz n care avem o dependen ! generatoare de tupluri, fie o expresie x = y cu x $i y dintre simbolurile ce apar anterior, n acest caz avnd o dependen ! generatoare de egalit! i. Numim (t1,...,tk) ipoteza dependen ei $i t concluzia dependen ei. Un simbol din concluzie care nu mai apare n alt! parte se nume$te simbol unic. O dependen ! generalizat! se nume$te ascuns! dac! are cel pu in un simbol unic $i se nume$te complet! dac! nu con ine nici un simbol unic. O dependen ! func ional! nebanal! X Y se exprim! printr-un num!r de dependen e generalizate egal cu num!rul elementelor mul imii Y-X, cu ipoteza format! din dou! tupluri ce con in simboluri comune pentru atributele din X $i simboluri distincte pentru celelalte atribute, iar concluzia con ine o egalitate ntre simboluri din cele dou! tupluri pentru un atribut din Y-X. O dependen ! multivaloare de tipul X Y se exprim! ca o dependen ! generalizat ! cu ipoteza format! din dou! tupluri care au acelea$i simboluri pentru atributele din X $i 34

simboluri distincte n rest, iar concluzia este un tuplu cu simboluri din primul tuplu pentru atributele XY $i cu simbolurile din al doilea tuplu n rest. O dependen ! multivaloare ascuns! X Y|z se poate reprezenta ca o dependen ! generalizat ! cu ipoteza format ! din dou ! tupluri care au acelea$i valori pentru atributele lui X $i valori diferite pentru celelalte atribute, iar concluzia coincide cu ipotezele pe atributele lui X, are valorile din primul tuplu pentru atributele lui Y, are valorile din al doilea tuplu pentru atributele din Z $i simboluri unice n rest. O dependen ! de uniune se poate reprezenta ca o dependen ! generalizat! n care ipoteza con ine un num!r de tupluri egal cu num!rul rela iilor din descompunere ce includ simboluri comune pentru apari iile unui atribut n mai multe rela ii pentru tuplurile corespunz!toare rela iilor n care apare acel atribut $i simboluri diferite n rest, iar concluzia con ine simbolul asociat fiec!rui atribut n ipotez!. Evident, concluzia nu are simboluri unice deoarece fiecare atribut apare cel pu in ntr-o component!. Pentru simplificarea nota iei, n tabelele asociate dependen elor generalizate se convine s! nu se mai noteze simbolurile care au o singur! apari ie (ipotez! + concluzie). Fie S $i T dou! mul imi de simboluri. Spunem c! h este o aplica ie de simboluri dac! pentru fiecare a din S se define$te h(a) ca fiind un element al lui T. Dac! s = a1a2...an este un tupltu de simboluri, se define$te h(s) ca fiind cuvntul ob inut prin concatenarea h(a1)h(a2)...h(an). Dac! s1s2...sk este o mul ime de tupluri cu simboluri din S $i t1 t2...tm este o mul ime de tupluri cu simboluri din T, vom spune c! exist! o aplica ie de simboluri de la prima mul ime de tupluri la a doua mul ime de tupluri dac! $i numai dac! exist! o aplica ie de simboluri h de la S la T astfel nct, pentru orice i, s! existe un j cu h(si) = tj. Exemplul 7.17. Fie A = {abc, ade, fbe} $i B = {xyz, wyz}. Exist! mai multe aplica ii de simboluri de la A la B. De exemplu, aplica ia h cu h(a) = h(f) = x, h(b)= h(d) = y $i h{c) = h(e) = z are drept imagine, pentru toate cele trei elemente ale lui A, elementul xyz din B. Aplica ia g(a) = x, g(b) = g(d) =y, g(c) = g(e) = z $i g(f) = w transform! abc $i ade n xyz $i pe fbe n wyz. Nu exist! o aplica ie de simboluri care s! duc! abc n xyz $i ade n wyz dac! x $i w sunt simboluri distincte, deoarece astfel lui a i s-ar asocia att x, ct $i w, ceea ce nu este posibil. O rela ie r satisface o dependen ! generalizat! (t1,...,tk)|t, dac!, pentru orice aplica ie de simboluri h de la mul imea tuplurilor din ipoteza dependen ei generalizate la r, se poate extinde h la orice simbol unic din t astfel nct h(t) s! apar in! lui r. Analog, spunem c! r satisface dependen a generalizat! (t1,...,tk)|a=b dac!, pentru orice aplica ie de simboluri h de la ipotez! la r, s! aib! loc egalitatea h{!) = h(b). Exemplul 7.18. Fie d dependen a din fig.7.1.a. $i rela ia r din fig.7.1.b. Deoarece n prima coloan! a tuplurilor din ipotez! figureaz! acela$i simbol a1, rezult! c! aplica ia de simboluri trebuie s! transforme tuplurile din ipotez! n tupluri care s! aib! pe primul loc acelea$i valori. Dac! se ia h(a1) = 5, rezult! c! ambele tupluri sunt duse n tuplul 514 al lui r $i deci h(b1) = h(b2) = 1 $i h(c1) = = h(c2) = 4, care se poate extinde lund h(a2) = 5, ob innd h(a2b1c2) = 514, care este un tuplu din r. Dac! h(a1) = 0, o aplica ie de simboluri transform! cele dou! tupluri din ipotez! n mul imea primelor trei tupluri ale lui r $i deci h(b1) este 1 sau 3 $i h(c2 ) este 2 sau 4, dar pentru combina iile 12, 32 $i 34 se poate lua h(a2)=0 $i pentru combina ia 14 se poate lua h(a2)=5, ob innd de fiecare dat! pentru h(a2b1c2) un tuplu al lui r. Deci r satisface d. a) a1 b1 c1 a1 b2 c2 a2 b1 c2 Figura 7.1. 35 b) 0 0 0 5 1 3 3 1 2 4 2 4

Fie dependen a d = (s1 ,...,sk )|a=b $i o rela ie r= { t1 ,...,tm}. Spunem c! se poate aplica d Ia r dac! exist! o aplica ie de simboluri h de la mul imea s1s2...sk la mul imea t1t2...tm. Efectul aplic!rii lui d la r folosind aplica ia de simboluri h este ob inut prin identificarea simbolurilor h(a) $i h(b) ori de cte ori apar n r. Pentru dependen e d= (sh...,sk)|s se aplic! d la r folosind aplica ia de simboluri h, ad!ugnd la r tuplul h(s). Pentru fiecare simbol unic c din s se creeaz! un simbol care nu mai apare n r $i se define$te h(c) noul simbol creat. Exemplul 7.19. Aplicarea dependen ei generalizate (abc, ade, fbe)|a=f la rela ia r = { xyz, wyz} folosind aplica ia de simboluri g din exemplul 7.17 cu g(a) = x $i g(f) = w identific! n r pe w cu x, ob innd r = {xyz}. Dac! se aplic! dependen a (abc, ade, fbe) |abq lui r folosind g, atunci se adaug! lui r tuplul xyu deoarece g(a)=x, g(b) = y $i, q fiind un simbol unic, se introduce un nou simbol u $i se define$te h(q) = u.

36

BAZE DE DATE CURS 8 MODELAREA BAZELOR DE DATE RELA IONALE 8.1 Forme normale n baze de date 8.1.1 Prima forma normala (FN1) 8.1.2 A doua forma normala (FN2) 8.1.3 A treia forma normala (FN3) 8.1.4 Forma normala Boyce-Codd (FNBC) 8.1.5 A patra forma normala (FN4) 8.1.6 A cincea forma normala (FN5) 8.2 Metode $i tehnici de normalizare a rela iilor 8.2.1 Descrierea procesului de ameliorare a schemei conceptuale 8.2.2 Aducerea rela iilor n FN1 8.2.3 Aducerea rela iilor n FN2 8.2.4 Aducerea rela iilor n FN3 8.2.5 Aducerea rela iilor n FNBC 8.2.6 Aducerea rela iilor n FN4 8.2.7 Aducerea rela iilor n FN5 Modelarea bazelor de date rela!ionale Modelarea bazei rela ionale este una din cele mai importante sarcini ale proiectantului, utilizatorului $i administratorului bazei de date. Ea prezint! dou! aspecte semnificative: 1. Aspectul static al model!rii- se stabile$te structura datelor (rela ii, filtre), se stabilesc restric ii independente de timp (chei, domenii); 2. Aspectul dinamic al model!rii- se descriu ac iunile ce opereaz! pe aceste structuri de date. Procesul model!rii este bazat pe tehnica top-down $i are urm!toarele faze: Ob inerea $i formalizarea solicit!rilor beneficiarului. Se identific! entit ! i, rela ii, cardinalitate $i propriet! i relevante ale acestora; Integrarea $i sinteza acestei solicit!ri, adic! elaborarea unei scheme conceptuale globale neredundant!, coerent! $i unic!; Normalizarea rela iilor conceptuale, adic! ob inerea unor rela ii mai mici, f!r! a pierde din informa ie, pentru a elimina redundan a $i anomaliile la actualizare; Optimizarea schemei interne care deriv! din aspectul dinamic al model!rii $i care este specific! reprezent!rii fizice a bazei de date. Se fac denormaliz!ri, se realizeaz! compuneri, se alege modul de organizare a fi$ierelor, metode de acces, etc. 8.1. Forme normale n baze de date n lucrul cu bazele de bate se manifest! o serie de anomalii datorit! dependen elor "nedorite" ce se manifest! ntre datele din cadrul rela iilor bazei. Aceste dependen e determin! cre$terea redundan ei datelor $i reducerea flexibilit! ii structurii bazei de date. Formele normale ale rela iilor sunt definite n raport de anomaliile care pot apare n lucrul cu aceste rela ii, deci n func ie de anumite dependen e "nedorite". O rela ie este ntr-o form! normal! particular! dac! satisface o mul ime specificat! de restric ii. Pn! n prezent se cunosc cinci forme normale ale rela iilor dintr-o baz! de date. 37

Fie r[A1, ,An] o rela ie $i X={ Ai1, ,Aip }{ A1, ,An } o mul ime de atribute. Reamintim c!, prin proiec ia rela iei r pe X se n elege r'[Ai1, ,Aip] = Ai1 ,..., Aiip (r) unde pentru p=(a1, a2, ,an)r, avem Xp=p[X]= (ai1 , ai2, ,aip) r' ($i toate elementele din r sunt distincte). Fie rela iile r(X,Y), s(Y,Z) $i X, Y, Z mul imi de atribute, XZ=. Prin join-ul natural al rela iilor r $i s se n elege: r><s={ (X(t), Y(t), Z(v)) | tr, vs, Y(t)= Y(v)} O rela ie r se poate descompune n mai multe rela ii noi: r1, r2, ,rm. Aceast! descompunere este corect!, dac!: r= r1><r2>< ><rm. Vom da un exemplu de descompunere care nu este corect !. Fie rela iile: r [NUME, VARSTA, SALARIU, LOCALITATE] r1 [NUME, SALARIU] r2 [VRSTA, SALARIU, LOCALITATE]. $i presupunem c! pentru r avem urm!toarea extensie: NUME Ionescu Popescu Georgescu C!linescu VRSTA 30 40 60 25 SALARIU 800000 1200000 1500000 1200000 LOCALITATE Arad Oradea Ia$i Arad

n acest caz se ob ine: r1 NUME Ionescu Popescu Georgescu C!linescu SALARIU 800000 1200000 1500000 1200000 r1><r2 NUME Ionescu Popescu Popescu Georgescu C!linescu C!linescu r2 VRSTA 30 40 60 25 SALARIU 800000 1200000 1500000 1200000 LOCALITATE Arad Oradea Ia$i Arad

VRSTA 30 40 40 60 25 25

SALARIU 800000 1200000 1200000 1500000 1200000 1200000

LOCALITATE Arad Oradea Arad Ia$i Arad Oradea

8.1.1 Prima form" normal" (FN1) Este posibil, ca n diverse aplica ii practice s! apar! atribute (simple sau compuse), ce au mai multe valori pentru un element din rela ie. Aceste atribute formeaz! un atribut repetitiv. Prin atribut simplu vom n elege un singur atribut din rela ie, iar prin atribut compus o mul ime de atribute (cel pu in dou!). Consider!m, de exemplu rela ia: persoana[NUME, AN -NA)TERE, PROFESIA, NUME-COPIL, AN-NA)TERE-COPIL] 38

cu atributul NUME cheie primar!. Perechea { NUME-COPIL, AN-NA)TERE-COPIL} este un grup repetitiv, deoarece rela ia poate avea urm!toarea extensie: Popa 1970 Daniel 1992 Anca 1994 Viorel 1998 Ionescu 1966 economist Andrei 1989 Magda 1993 De asemenea, rela ia: Carte[COTA, AUTOR, TITLU, EDITURA, AN-APARITIE, CUVINTE-CHEIE] cu atributul COTA cheie primar!, are atributele repetitive AUTOR $i CUVINTE-CHEIE. O carte poate avea mai mul i autori $i mai multe cuvinte cheie. Grupele de atribute repetitive creeaz! greut ! i n memorarea diverselor rela ii $i de accea se ncearc! eviterea lor, f!r! a pierde ns! din informa ii. Dac! r[A1, ,An ] este o rela ie, unde Am+1, ,An formeaz! un grup repetitiv, atunci rela ia r se poate descompune n dou! rela ii f!r! atribute repetitive. Dac! A1, ,Ap, p<m, este o cheie pentru rela ia r atunci cele dou! rela ii n care se descompune r sunt: r [ A1 , A2 ,..., Am ] = A1 , A2 ,..., Am (r ) r A1 , A2 ,..., A p , Am +1 ,..., An = A1 ,..., A p , Am +1 ,..., An (r ) inginer

Astfel, rela iile persoana $i carte se descompun n dou!, respectiv trei rela ii: p!rinte[NUME, AN-NA)TERE, PROFESIA] copil [NUME, NUME-COPIL, AN-NA)TERE-COPIL] autori [COTA, AUTOR] c!rti [COTA, TITLU, EDITURA, AN-APARITIE] cuvinte [COTA, CUVNT-CHEIE] Defini!ia 8.1. O rela ie este n prima form ! normal! (FN1) dac! nu con ine grupuri (de atribute) repetitive. 8.1.2 A doua form" normal" (FN2) Urm!toarele forme normale utilizeaz! no iunea de dependen a func ional! ntre submul imi de atribute. Stabilirea dependen elor func ionale este sarcina administratorului bazei $i depinde de semnifica ia datelor care se memoreaz! n rela ie. Opera iile de actualizare a datelor (ad!ugare, modificare, $tergere) nu trebuie s! modifice dependen ele func ionale existente. Defini!ia 8.2. Fie r[A1, ,An] o rela ie $i X,Y { A1, ,An } . Atributul Y este complet dependent func ional de X, dac! Y este dependent func ional de X (XY) $i nu este dependent func ional de nici o submul ime de atribute din X (pentru aceast! dependen ! func ional! trebuie ca X s! fie un atribut compus). Fie r[A1, ,An] o rela ie $i C A= { A1 , ,An } o cheie. Presupunem c! exist! Y A, YC= (Y nu este cheie), Y dependent func ional de XC (Y este complet dependent func ional de o submul ime strict! de atribute din cheie). Dependen a X Y se poate elimina dac! rela ia r se descompune n urm!toarele dou! rela ii: r [XY]= XY(r) r [AY]= AY(r)

39

Defini!ia 8.3. O rela ie este n a doua form ! normal! (FN2) dac! este de prima form! normal! $i orice atribut (simplu sau compus) este complet dependent de cheie sau este inclus n cheie. Exemplul 8.1. Se consider! urm!toarea rela ie (cu rezultatele la examene): examen[NUME-STUDENT, DISCIPLINA, NOTA, PROFESOR] n care cheia este { NUME-STUDENT, DISCIPLINA} $i unei discipline i corespunde un singur cadru didactic, iar unui cadru didactic pot s!-i corespund! mai multe discipline, deci avem dependen a func ional! DISCIPLINAPROFESOR. De aici deducem c! atributul PROFESOR nu este complet dependent func ional de cheie. Atunci, rela ia examen se poate descompune n urm!toarele dou! rela ii: apreciere[NUME-STUDENT, DISCIPLINA, NOTA] $i stat-func ii[DISCIPLINA, PROFESOR] Dac! dependen a func ional! DISCIPLINAPROFESOR nu este respectat !, atunci poate apare o inconsisten !. Fie dou! elemente din rela ie: T t1 t2 ..Disciplina.Profesor .. Analiza Popa Analiza Popa ...

Dac! n t 1 valoarea atributului PROFESOR se schimb!, dar n t 2 nu se face schimbarea, atunci dependen a func ional! nu este respectat! $i apare o inconsisten ! (la aceea$i disciplin! apar cadre didactice diferite). 8.1.3 A treia form" normal" (FN3) Defini!ia 8.4 Un atribut Z este tranzitiv dependent de atributul X dac! exist! Y astfel nct XY, YZ, iar YX nu are loc $i Z nu este inclus n XY. Dac! C este o cheie $i Y un atribut tranzitiv dependent de cheie, atunci exist! un X care verific! CX $i XY. Deoarece rela ia este n forma normal! FN2, ob inem c! Y este complet dependent de C, deci XC= $i exist! o dependen ! XY, iar X nu este cheie. Dac! r[A 1 ,,A n ] are cheia C $i exist ! atributul Y {A1 ,..., An } , tranzitiv dependent de C $i care nu este cheie (adic! Y C = ), atunci rela ia r se poate descompune n urm!toarele rela ii (se elimin! dependen a func ional! XY): r [ X Y ] = X Y (r ) r [ A Y ] = AY (r ) Defini!ia 8.5. O rela ie r este n a treia form! normal! (FN3) dac! $i numai dac! rela ia r este n a doua form! normal! $i fiecare atribut care nu este cheie (nu particip! la o cheie) nu este tranzitiv dependent de nici o cheie a lui r. Exemplul 8.2 Se consider! urm!toarea rela ie (cu rezultatele ob inute de absolven i la lucrarea de diplom!): diploma[NUME-ABSOLVENT, NOTA,CADRU-DID-NDR, CATEDRA] cu cheia NUME-ABSOLVENT. 40

Se observ! c! avem urm!toarele dependen e func ionale: CADRU-DID-NDRCATEDRA NUME-ABSOLVENTCADRU-DID-NDR Rela ia ini ial! se poate, atunci descompune n urm!toarele dou! rela ii: rezultate[NUME-ABSOLVENT, NOTA, CADRU-DID-NDR] ndrumatori[CADRU-DID-NDR, CATEDRA]. 8.1.4 Forma normal" Boyce-Codd (FNBC) Dup! defini ia formei normale FN3 dat! de E. F. Codd, ulterior, au mai ap!rut o serie de noi defini ii: O rela ie r este n fom" normal" Boyce-Codd (FNBC) dac! orice determinant este cheie (principal! sau secundar!). O rela ie este n a treia form" normal" C. J. Date (FN3 Date) dac! orice atribut care nu este cheie, nu este tranzitiv dependent de cheia principal!. Exemplul 8.3 Transportul local pe timp de o s!pt!mn! dintr-un ora$ este specificat de rela ia: transport [ZI, NR-TRASEU, NR-MASINA, COND-AUTO] unde COND-AUTO este numele conduc!torului auto (el conduce o singur! ma$in!, dar pe acea ma$in! o poate conduce $i un alt conduc!tor). Avem cheia: { ZI, NR-TRASEU, NRMASINA} $i dependen a COND-AUTONR-MASINA. Rela ia definit! este n FN3 Date (NR-MASINA) apare n cheie, dar nu este n FNBC $i se poate descompune n urm!toarele dou! rela ii: traseu[ZI, NR-TRASEU, NR-MASINA] $oferi[NR-MASINA, COND-AUTO] Defini!ia 8.6. O rela ie este n forma normal! Boyce-Codd dac! dependen ele func ionale netriviale care se manifest! n cadrul rela iei con in n partea stng! (ca determinant) o cheie candidat!. Exist! mai mul i algoritmi pentru aducerea unei rela ii n forma normal! Boyce-Codd, unul dintre ace$tia fiind prezentat n sec iunea prind tehnica normaliz!rii rela iilor. Orice rela ie n forma normal! Boyce-Codd este n a treia form! normal!, dar reciproca nu este adev!rat!, dup! cum se ovserv! din exemplul urm!tor. Exemplul 8.4. Rela ia R=ABC cu dependen ele func ionale F={ ABC, CA} este n a treia form! normal!, dar nu este n forma normal! Boyce-Codd, deoarece cheile acestei rela ii sunt AC $i BC, iar pentru dependen a CA partea stng! nu con ine nici una din cele dou! chei. 8.1.5 A patra form" normal" Defini!ia 8.7 Fie rela ia r[A 1 ,A 2 ,,A n ] $i dou! mul imi de atribute X,Y{ A1,,An} . Spunem c! Y este multiplu dependent func ional de X (X Y) dac! $i numai dac! pentru orice t1,t2 r pentru care X(t1) = X(t2) exist! t3 $i t4r astfel nct:

41

X(t1) = X(t2)= X(t3) = X(t4) Y(t1) = Y(t3) ; Y(t2) = Y(t4) A-X-Y(t1) = A-X-Y(t4) ; A-X-Y(t2) = A-X-Y(t3) Dependen a X Y se nume$te dependen ! func ional! multipl! sau dependen ! multivaloare $i se poate se poate reprezenta astfel: X v v v v Y u1 u2 u1 u2 A-X-Y w1 w2 w2 w1

t1 t2 t3 t4

Dac! A=XY sau YX, atunci dependen a XY se nume$te trivial!. Defini!ia 8.7. O rela ie r este n a patra form ! normal! (FN4), dac! pentru toate dependen ele func ionale multiple, avem X Y este dependen ! trivial! sau X este cheie pentru r sau: O rela ie R este n FN4 dac! n cadrul ei nu se manifest! mai mult de o dependen ! multivaloare. Aceast! defini ie difer! de defini ia formei FNBC doar prin folosirea dependen elor func ionale multiple n locul celor simple. Exemplul 8.5. Consider!m rela ia carte n care se observ! c! avem urm!toarele dependen e func ionale: COTA COTA AUTOR; COTA CUVNT-CHEIE; { TITLU, EDITURA, AN-APARITIE}

carte AUTOR Popescu I. Slavici I. Popescu I. Slavici I. Tudor P Ioan S. Vigu T. Tudor P. Ioan S. Vigu T.

COTA 1 1 1 1 2 2 2 2 2 2

TITLU Mara Mara Mara Mara Baze de date Baze de date Baze de date Baze de date Baze de date Baze de date

EDITURA ALL ALL ALL ALL Teora Teora Teora Teora Teora Teora

AN APARITIE 1990 1990 1990 1990 1993 1993 1993 1993 1993 1993

CUVINTE CHEIE Rom Rom Roman Roman Bdate Bdate Bdate Rom Rom Rom

Pentru a fi n forma FN4, vom descompune rela ia n urm!toarele rela ii: COTA 1 2 TITLU Mara Baze de date EDITURA ALL Teora AN-APARITIE 1990 1993

42

COTA 1 1 2 2 2

AUTOR Popescu I. Slavici I. Tudor P. Ioan S. Vigu T.

COTA 1 1 2 2

CUVANT-CHEIE Rom Roman Bdate Rom

8.1.6 A cincea form" normal" (FN5) Defini!ia 8.8 Fie rela ia r[A1, A2, ,An] $i r1[X1], , rm[Xm] o descompunere a rela iei r. Rela ia r satisface dependen a join notat! (r1, ,rm), dac! r = r1><r2>< ><rm. Dac! una din rela iile ri este egal! cu r, atunci aceast! dependen ! este trivial!. S! consider!m o rela ie r $i o dependen ! join (r1, r2) unde r1[X], r2[Y] sunt rela ii. Cu aceste presupuneri, avem: r= r1><r2. Fie t1,t2r $i valorile lor date prin urm!torul tabel: X(t1) X(t2) Y(t1) Y(t2) X-Y u1 u2 X Y v v v v Y-X w1 w2

Dac! se calculeaz! r1><r2, care este egal! cu r, rezult! faptul c! mai avem dou! elemente t3 $i t4 din r cu valorile urm!toare: X-Y u1 u2 u1 u2 X Y v v v v Y-X w1 w2
w2 w1

t1 t2 t3 t4

De aici, se deduce c! XY X sau XY echivalent! cu dependen a func ional! multipl!.

Y, deci dependen a join (r1 , r2) este

Defini!ia 8.9. O rela ie este n forma normal! cinci (FN5) cu respectarea unei mul imi D de dependen e func ionale multiple sau join, dac! fiecare dependen ! (r1 ,..., rm ) este fie trivial!, fie X i este cheie (avem ri[Xi]) pentru r, pentru toate valorile lui i. Cu alte cuvinte, o rela ie r este n FN5 dac! orice dependen ! join definit! pe r este implicat! de cheile candidat ale lui r. Exemplul 8.6. Fie rela ia cursa [CP#, CA#, PD, PA], unde CP-codul pilotului, CAcodul avionului, PD $i PA punctul de decolare, respectiv aterizare. 43

n aceast! rela ie, care este n FN4, nu exist ! dependen e func ionale multiple, dar exist! o redundan ! logic! care va ridica probleme la actualizare. cursa PA PD CP# CA# 11 100 Sibiu Ia$i 10 100 Ia$i Sibiu 10 100 Sibiu Ia$i 10 101 Sibiu Ia$i Descompunem rela ia cursa prin proiec ie n: r1 (CP#, CA#) r2 (CP#, PD, PA) r3 (CA#, PD, PA) Se observ! c!, cursa r1><r2 ; cursa r2><r3; cursa r1><r3), dar cursa = r1><r2><r3. n rela ia r1><r2 a ap!rut un tuplu (10, 101, Ia$i, Sibiu) care nu exist! n cursa. Dac! ar CA $i astfel descompunerea reversibil! a fi existat, ar fi avut loc multidependen a CP rela iei cusa n r1 $i r2 . r1 CP# 11 10 10 r1><r2 CP# 11 10 10 10 10 CA# 100 100 101 r2 PD CP# 11 Sibiu 10 Ia$i 10 Sibiu PA Ia$i Sibiu Ia$i r3 PD CA# 100 Sibiu 100 Ia$i 101 Sibiu PA Ia$i Sibiu Ia$i

CA# 100 100 100 101 101

PD Sibiu Ia$i Sibiu Ia$i Sibiu

PA Ia$i Sibiu Ia$i Sibiu Ia$i

n practic! se utilizeaz! destul de rar formele normale 4 $i 5 deoarece acestea conduc la o descompunere a unei rela ii n multe subrela ii, ceea ce m!re$te timpul de r!spuns la interog!ri precum $i spa iul de memorare. 8.2. Metode %i tehnici de normalizare a rela!iilor 8.2.1 Descrierea procesului de ameliorare a schemei conceptuale Proiectarea schemei conceptuale a unei baze de date presupune parcurgerea urm!toarelor etape: 1. Determinarea formei normale n care trebuie s! se afle rela iile din baza de date. n majoritatea cazurilor bazele de date rela ionale sunt constituite din rela ii aflate n FN1 sau FN2. Acest lucru se explic! prin faptul c! formele normale superioare, de$i reduc dificultatea de realizare a opera iilor de actualizare, reduc n acela$i timp $i performan ele opera iilor de reg!sire a datelor. Rela iile aflate n forme normale superioare con in un num!r mic de atribute 44

$i acest lucru favorizeaz! opera iile de actualizare a datelor, dar ngreuneaz! procesul de reg!sire a lor, deoarece satisfacerea cererilor de date impune interogarea simultan! a mai multor rela ii, deci efectuarea unor opera ii de join, care sunt costisitoare n termenii resurselor de calcul solicitate. 2. Stabilirea rela iilor care s! fac! parte din BD, n forma normal! precizat! la etapa anterioar!. Presupune definirea schemei rela iilor $i a restric iilor de integritate. Modul prin care se stabile$te mul imea de rela ii din baza de date, se nume$te tehnica normaliz!rii rela iilor. 3. Descrierea schemei conceptuale n limbajul de descriere a datelor utilizat de SGBDul rela ional ce se utilizeaz!. n ob inerea unei baze de date performant!, un rol important l are tehnica normaliz!rii rela iilor. Aceast! tehnic! permite ob inerea schemei conceptuale printr-un proces de ameliorare progresiv! a unei scheme concepute ini ial, prin utilizarea formelor normale. Dup! fiecare etap! de ameliorare, rela iile din baz! ating un anumit grad de perfec iune prin eliminarea unui anumit tip de dependen e nedorite (dependen e func ionale par iale, tranzitive, multivaloare), deci se afl! ntr-o anumit! form! normal!. Procesul de ameliorare, trebuie s! satisfac! urm!toarele cerin e: s! garanteze conservarea datelor, adic! n schema conceptual! final! trebuie s! figureze toate datele din schema ini ial!; s! garanteze conservarea dependen elor dintre date, adic! n schema final! fiecare dependen ! trebuie s! aib! determinantul $i determinatul n schema aceleia$i rela ii; s! reprezinte o descompunere minimal! a rela iilor ini iale. Nici una din rela iile care compun schema final! nu trebuie s! fie con inut! ntr-o alt! rela ie din aceast! schem!. Necesitatea normaliz!rii este ilustrat! n exemplul urm!tor. Fie schema rela ional! avion (NR, TIP, CAPACITATE, LOCALITATE), cu cheia primar! num!rul avionului (NR). avion NR 100 101 102 103

TIP IAR500 IAR500 ROMBAC TU154

CAPACITATE 90 90 100 200

LOCALITATE BRA)OV ARAD BUCURE)TI TIMI)OARA

Presupunem c! n cadrul companiei, exist! restric ia: toate avioanele de acela$i tip au aceea$i capacitate care este de fapt o dependen ! func ional! de forma TIPCAPACITATE. Datorit! acestei dependen e, pot exista redundan e n date sau pot s! apar! anomalii la reactualizare. Astfel, n rela ia de mai sus, avem o redundan ! logic! (perechea <IAR 500, 90> apare de mai multe ori) precum $i anomalii la reactualizare: dac! dorim s! $tergem avionul cu num!rul 102, vom pierde informa ia care ne arat! c! un avion ROMBAC are capacitatea 100. De asemenea, dac! modific!m capacitatea avionului IAR 500, de la 90 la 190 de locuri putem ntlni urm!toarele anomalii: modificnd un singur tuplu, rela ia devine incoerent! (restric ia nu mai este verificat!), iar dac! modific!m toate tuplurile cu IAR 500, costul modific!rii cre$te semnificativ. Prezent!m n continuare procedeul de ameliorare a schemei conceptuale ini iale, care const! n aducerea acesteia la diferite forme normale.

45

Schema conceptuala initiala

Aducerea relatiilor in FN1

Schema conceptuala in FN1

Aducerea relatiilor in BCNF

Aducerea relatiilor in FN2

Schema conceptuala in FNBC

Schema concptuala in FN2

Aducerea relatiilor in FN3

Schema concptuala in

FN3

Aducerea relatiilor in BCNF

Schema conceptuala in FNBC

Aducerea relatiilor in FN4

Schema conceptuala in FN4

Aducerea relatiilor in FN5

Schema conceptuala in FN5

Fig. 8.1 Etapele procesului de ameliorare a schemei conceptuale

8.2.2 Aducerea rela!iilor n FN1

46

Presupune eliminarea atributelor compuse $i a celor repetitive. Aducerea unei rela ii n FN1 se realizeaz! astfel: 1. Se trec n rela ie, n locul atributelor compuse componentele acestora, ca atribute simple. 2. Se plaseaz! grupurile de atribute repetitive, fiecare n cte o nou! rela ie. 3. Se introduce n schema fiec!rei noi rela ii creat! n pasul 2 cheia primar! a rela iei din care a fost extras grupul repetitiv. 4. Se stabile$te cheia primar! a fiec!rei rela ii creat! n pasul 2. Aceasta va fi compus! din atributele ad!ugate la rela ie n pasul 3, precum $i din unul sau mai multe atribute proprii rela iei. Pentru exemplificarea procesului de aducere a unei rela ii n FN1 se consider! rela ia Persoana, cu schema prezentat! n fig. 8.2. Persoana Marca Numep Adresa Prenc1 Data na$terec1 Prenc2 Data na$terec2 ... Str Loc Cod Fig.8.2. Schema rela iei nenormalizate Persoana Rela ia Persoana are un atribut compus, denumit "Adresa" $i un grup de atribute repetitive, format din atributele "Prenc" $i "Datana$terec". Rezultatele aducerii rela iei Persoana n FN1 sunt prezentate n fig. 8.3. Pers Marca Numep Stradr Locadr Codadr

Copil Precopil: Data nasterec

Marca

Fig. 8.3. Rela iile ob inute prin aducerea rela iei din fig. 8.2. n FN1 8.2.3 Aducerea rela!iilor n FN2 Presupune eliminarea dependen elor func ionale par iale din rela iile aflate n FN1. Procesul de aducere a unei rela ii din FN1 n FN2 se desf!$oar! astfel: 1. Pentru fiecare dependen ! func ional! par ial! se creaz! o nou! rela ie, cu schema constituit! din determinantul $i determinatul acestei dependen e. 2. Dac! n rela ia ini ial! exist! mai multe dependen e func ionale par iale cu acela$i determinant, pentru toate acestea se creeaz! o singur! rela ie cu schema constituit! din determinantul, luat o singur! dat! $i din determina ii dependen elor considerate. 3. Se determin! cheia primar! a fiec!rei noi rela ii creat ! n pasul 1. Aceasta va fi format! din atributul/atributele din determinantul dependen ei func ionale par iale, care a stat la baza constituirii rela iei. 4. Se analizeaz! rela iile rezultate la pasul 1. Dac! aceste rela ii con in dependen e func ionale par iale se reia procesul de aducere n FN2, altfel procesul s-a terminat.. Pentru exemplificare s-a recurs la o rela ie Reper, a c!rei schem! este prezentat! n fig. 8.4. Reper 47

Codprod Codreper Codsec ie Codma$in! Nroper Codoper Categoper Timp Timp preg. exec.

Fig. 8.4. Schema rela iei Reper Rela ia R are dou! chei candidate $i anume: (Codreper, Codma$in!, Codoper) (Codreper, Codma$in!, Nroper) Dintre acestea, prima se alege drept cheie primar!. n rela ia din fig. 8.4. se manifest! urm!toarele dependen e func ionale par iale: Codoper Categoper Nroper Categoper Prin aplicarea opera iilor de aducere a acestei rela ii n FN2 se ob in rela iile din fig. 8.5. Reper1 Codprod Codreper Codsec ie Codmasina Nroper: Codoper

Timp preg. Timp exec.

R1 Codoper

Categoper

R2 Nroper Categoper Fig. 8.5. Rela iile ob inute prin aducerea rela iei din fig. 8.4. n FN2 Dependen ele func ionale par iale din cadrul rela iei din fig. 8.4. au fost ransformate n urm!toarele dependen e func ionale complete: Codoper Categoper, n cadrul rela iei R1 Nroper Categoper, n rela ia R2 Dac! se noteaz! cu R o rela ie n FN1 care trebuie adus! n FN2 $i cu (A,B) cheia acestei rela ii R(A, B, C, D, ...) $i dac! se consider! dependen a B C drept singura dependen ! func ional! par ial! care se manifest! n R, atunci aducerea lui R n FN2 determin! descompunerea rela iei n dou! rela ii R l $i R2, cu schemele: R1(A, B, D, ...) R2(B, C) 8.2.4 Aducerea rela!iilor n FN3 Presupune aducerea unei rela ii FN2 n FN3 prin eliminarea dependen elor tranzitive. 1. Pentru fiecare dependen ! func ional! tranzitiv! se transfer! atributele implicate n dependen ! tranzitiv! ntr-o nou! rela ie. 2. Se determin! cheia primar! a fiec!rei noi rela ii creat! la pasul 1. 3. Se introduc n rela ia ini ial! n locul atributelor transferate, cheile primare determinate la pasul 2. 4. Se reanalizeaz! rela ia ini ial!. Dac! n cadrul ei exist! noi dependen e tranzitive, atunci se face transfer la pasul 1, altfel procesul de aducere la FN3 s-a terminat. 48

Dac! se noteaz! cu R o rela ie n FN2 care trebuie adus! n FN3 $i cu X cheia acestei rela ii R(X, A, B, ...) $i dac! se consider! dependen a A B singura dependen ! func ional! tranzitiv! care se manifest! n R, atunci procesul de aducere a lui R n FN3 determin! descompunerea lui R n dou! rela ii R1 $i R2, cu schemele: R1(X, A, ...) R2(A, B) A treia form! normal! poate fi ob inut! $i cu ajutorul unei scheme de sintez!. Algoritmul de sintez! construie$te o acoperire minimal! F+ a dependen elor func ionale totale. Se elimin! atributele $i dependen ele func ionale redundante. Mul imea F este parti ionat ! n grupuri Fi, astfel nct n fiecare grup Fi sunt dependen e func ionale care au acela$i membru stng $i nu exist! dou! grupuri cu acela$i membru stng. Fiecare grup Fi produce o schem! FN3. Algoritmul realizeaz! o descompunere ce conserv! dependen ele. Vom ilustra algoritmul pe un exemplu. Fie A1 , A2 ,..., Am o mul ime de atribute $i fie E o mul ime de dependen e func ionale f1 , f 2 ,.., f n de forma f i : X i Y j , unde X i = Ai1 , Ai2 ,.., Aik $i Y j = A j1 , A j 2 ,..., A jl . Concret, fie : f1 : F N ; f 2 : F P; f 3 : P, F , N U ; f 4 : P C ; f 5 : P T ; f 6 : C T ; f 7 : N F o mul ime de dependen e func ionale. Ideea schemei de sintez! este de a regrupa dependen ele func ionale cu acela$i membru stng: F1 = { f 1 , f 2 }; F2 = { f 3 }; F3 = { f 4 , f 5 }; F4 = { f 6 }; F5 = { f 7 } care conduc la schemele rela ionale: r1(F#, N, P) r2(P#, F#, N#, U) r3(P#, C, T) r4(C#, T) r5(N#, F) Aceste rela ii nu sunt n FN3. De exemplu, N este atribut redundant n f 3 deoarece F N ; r 4 r 3 $i exist! tranzitivitatea P C , C T ; r 5 r1 $i F N , N F . Prin urmare, trebuie eliminate atributele $i dependen ele redundante. Algoritmul de sintez! $i propune: 1. Suprimarea atributelor redundante. Atributul Ai este redundant n dependen a func ional! A 1 ,..., Ai ,..., An Y dac! putem genera dependen a func ional! A1 ,..., Ai 1 , Ai +1 ,..., An Y plecnd de la mul imea ini ial! E de dependen e func ionale $i de la axiomele lui Amstrong. Pentru exemplul considerat: f1 : FN; f3 : P, F, N U sau N, P, F U. Aplicnd axioma 3 se ob ine F, P, F U deci P, F U 2. Suprimarea dependen elor func ionale redundante. Dependen a func ional! f este redundant! n E dac! E+=(E - f)+ unde E+ reprezint! nchiderea lui E. n cazul exemplului considerat se observ! c! f5 este redundant !, deoarece poate fi ob inut! din f 4 $i f6. La sfr$itul acestei etape se ob ine: f1 : FN; f2 : FP; f3 : P,FU; f4 : PC; f6 : CT; f7 : NF 3. Gruparea dependen elor cu acela$i membru stng. n cazul exemplului considerat: F1={ f1, f2} ; F2={ f3} ; F3={ f4} ; F4 ={ f6} ; F5={ f7} 49

4. Regruparea mul imilor Fi $i Fj dac! exist ! dependen e de forma XY$i YX, unde X este partea stng! a dependen ei lui Fi $i Y este partea stng! a dependen ei lui Fj. Grupnd F1 $i F5 se ob ine: F1 = { f1, f2, f3 } ; F2={ f3} ; F3={ f4} ; F4={ f6} 5. Generarea rela iilor FN3. Pentru exemplul considerat, se ob in schemele rela ionale: r1(F#, N, P), r2(P#, F#, U), r3(P#, C), r4(C#, T). Algoritmul BFN3 permite aducerea unei rela ii n FN3 $i corespunde schemei de sintez! comentate anterior. Algoritmul solicit! determinarea unei acoperiri minimale (algoritm ELIMA $i ELIMF) $i determinarea nchiderii A+ a unei mul imi de atribute A n raport cu o mul ime de dependen e func ionale E (algoritm INCHID). Algoritmul INCHID 1. Se caut! dac! exist! n mul imea E dependen e func ionale XY pentru care determinantul reprezint! o submul ime a lui A, iar determinatul nu este inclus n mul imea A (XA, YA). 2. Pentru fiecare astfel de dependen ! func ional! se adaug! mul imii A, atributele care constituie determinantul dependen ei. 3. Dac! nu mai exist! nici o dependen ! func ional! de tipul dependen elor de la pasul 1, atunci A+=A. Fie E o mul ime de dependen e func ionale. Un atribut A este redundant dac! prin eliminarea lui din partea stng! a dependen ei func ionale XY se ob ine dependen a func ional! X{ A}Y care de asemenea este n E. Algoritmul ELIMA permite eliminarea atributelor redundante din determinantul dependen elor func ionale. Algoritmul ELIMA Pentru fiecare dependen ! func ional! din E $i pentru fiecare atribut din partea stng! a unei dependen e func ionale: 1. Se elimin! atributul considerat; 2. Se calculeaz! nchiderea p!r ii stngi reduse; 3. Dac! aceast ! nchidere con ine toate atributele din determinantul dependen ei func ionale, atunci atributul eliminat la pasul 1 este redundant $i r!mne eliminat. n caz contrar, atributul nu este redundant $i se reintroduce n partea stng! a dependen ei func ionale. Algoritmul ELIMF elimin! dependen elor func ionale redundante din mul imea E. Algoritm ELIMF Pentru fiecare dependen ! func ional! XY din E: 1. Se elimin! dependen a din E; 2. Se calculeaz! nchiderea X + , n raport cu mul imea redus! de dependen e; 3. Dac! Y este inclus n X + , atunci dependen a XY este redundant! $i r!mne eliminat!. n caz contrar, dependen a nu este redundant! $i se reintroduce n mul imea E. Determinarea acoperirii minimale a unei mul imi de dependen e func ionale presupune: - eliminarea atributelor redundante (algoritm ELIMA); - eliminarea dependen elor func ionale redundante (algoritm ELIMF). Acoperirea minimal! nu este unic! $i depinde de ordinea n care sunt eliminate atributele $i dependen ele func ionale redundante.

50

Dou! mul imi de atribute X, Y sunt chei echivalente dac! n mul imea de dependen e E exist! att dependen a XY, ct $i dependen a YX

Algoritm BFN3 1. Se determin! F o acoperire minimal! a lui E. 2. Se descompune mul imea F n grupuri notate F i , astfel nct n cadrul fiec!rui grup s! existe dependen e func ionale ce au aceea$i parte stng!. 3. Se determin! perechile de chei echivalente (X, Y) n raport cu F. 4. Pentru fiecare pereche de chei echivalente: - se identific! grupurile FI $i Fj care con in dependen ele func ionale cu partea stng! X $i respectiv Y; - se formeaz! un nou grup de dependen e Fij, care va con ine dependen ele func ionale ce au membrul stng (X, Y); - se elimin! grupurile Fi $i Fj, iar locul lor va fi luat de grupul Fij. 5. Se determin! o acoperire minimal! a lui F, care va include toate dependen ele XY, unde X $i Y sunt chei echivalente (celelalte dependen e sunt redundante). 6. Se construiesc rela ii FN3 (cte o rela ie pentru fiecare grup de dependen e func ionale). 8.2.5 Aducerea rela!iilor n FNBC Presupune eliminarea dependen elor func ionale care ncalc! cerin ele formei normale Boyce-Codd, $i anume a dependen elor a c!ror determinan i nu sunt chei candidat. Aceste dependen e func ionale mai sunt cunoscute $i sub numele de dependen e noncheie. Pentru ca o rela ie s! fie adus! n FNBC nu trebuie, n mod obligatoriu s! fie n FN3. Se pot aduce n FNBC $i rela ii aflate n FN1 sau FN2. Acest lucru este posibil ntruct dependen ele func ionale par iale $i cele tranzitive sunt de fapt, tot dependen e noncheie. Exist! trei categorii de dependen e noncheie $i anume: - dependen e func ionale par iale; - dependen e func ionale tranzitive; - dependen e noncheie, altele dect cele din categoriile 1 $i 2. ntr-o rela ie aflat! n FN3 se manifest! numai dependen e noncheie din categoria 3 (cele din categoriile 1 $i 2 au fost eliminate n procesul aducerii rela iei n FN3). ntr-o rela ie aflat! n FN2 se pot manifesta dependen e noncheie din categoriile 2 $i 3, iar ntr-o rela ie n FN1 pot exista dependen e noncheie din toate cele trei categorii. A aduce o rela ie n FNBC nseamn! a elimina toate tipurile de dependen e noncheie care se manifest! n cadrul ei. n general, se consider! ca puncte de plecare n procesul de aducere la BCNF, FN1 $i FN3. n cazul rela iilor n FN1, procedura de aducere n FNBC recurge la un procedeu unitar pentru eliminarea tuturor categoriilor de dependen e noncheie. Cnd se lucreaz! cu rela ii n FN3, procedura de aducere n FNBC utilizeaz! o metod! specific! de eliminare a dependen elor noncheie din categoria 3. n acest din urm! caz, dependen ele noncheie din cadrul unei rela ii se elimin! treptat $i anume: prin procedura de aducere a rela iei n FN2, prin cea de aducere in FN3 $i, respectiv prin procedura de aducere din FN3 n FNBC. Procesul de aducere a unei rela ii din FN1 n BCNF este urm!torul: 1. Se analizeaz! rela ia, pentru a se identifica dependen ele noncheie. Astfel, dac! rela ia con ine numai unul sau dou! atribute nu pot exista dependen e noncheie, deci rela ia se afl! n FNBC. Dac! rela ia con ine mai mult de dou! atribute, se identific! eventualele 51

dependen e noncheie. Dac! exist! astfel de dependen e se trece la pasul urm!tor. Dac! nu, rela ia este n FNBC $i procesul s-a terminat. 2. Se reduce progresiv schema rela iei ini iale $i se aplic! opera iile de identificare a dependen elor noncheie de la pasul 1. Ori de cte ori, prin reducerea schemei rela iei ini iale se ob ine o rela ie n FNBC, se consider! c! aceasta face parte din descompunerea rela iei ini iale, n procesul aducerii ei la FNBC. Procesul de aducere a unei rela ii din FN3 n FNBC se desf!$oar! astfel: 1. Se analizeaz! rela ia, pentru a se identifica dependen ele noncheie. Astfel, dac! rela ia con ine unul sau cel mult dou! atribute nu pot exista dependen e noncheie, deci rela ia este n FNBC $i procesul a luat sfr$it. Dac! rela ia con ine mai mult de dou! atribute n cadrul ei pot exista dependen e noncheie $i se trece la identificarea lor. Dac! nu exist! astfel de dependen e, rela ia este n FNBC $i procesul a luat sfr$it, altfel se trece la pasul 2. 2. Pentru fiecare dependen ! noncheie XY se creaz! dou! rela ii, una cu schema format! din atributele reprezentate prin X $i Y $i cealalt !, cu schema constituit! din toate atributele rela iei ini iale, mai pu in atributele reprezentate prin Y. Aceste dou! rela ii reprezint! descompunerea rela iei ini iale n procesul aducerii ei n FNBC. 3. Se reia procesul de aducere n FNBC pe rela iile ob inute la pasul 2. Pentru exemplificarea procedurilor de aducere a unei rela ii n BCNF se consider! rela ia forma, cu schema prezentat! n fig. 8.6. forma K1

K2

Fig. 8.6. Rela ie aflat! n FN3 S! presupunem c! n cadrul rela iei forma se manifest! urm!toarele dependen e: (K1, K2) B dependen ! func ional! complet! (K1, K2) D dependen ! func ional! complet! D K1 dependen ! noncheie (categoria 3) Rela ia forma se afl! n FN3 $i prin aplicarea procedurii de aducere n BCNF se ob in rezultatele din fig. 8.7. Se observ! c! descompunerea rela iei forma n rela iile forma1 $i forma2 conserv! datele $i este minimal!, dar nu conserv! dependen ele ntre date, ntruct nici una din rela ii nu nglobeaz! dependen a func ional! (K1, K2) B. forma1 D K1 forma2 K2

Fig. 8.7. Rela iile ob inute prin aducerea rela iei din fig. 8.6. n FNBC

8.2.6 Aducerea rela!iilor n FN4

52

Presupune eliminarea dependen elor multivaloare, atunci cnd sunt mai mult de una n cadrul unei rela ii. Procesul de aducere a unei rela ii din FNBC n FN4 cuprinde urm!torii pa$i: Y din cadrul rela iei considerate. 1. Se identific! dependen ele multivaloare X 2. Se izoleaz! fiecare atribut multivaloare Y, mpreun! cu atributele care depind func ional de acesta, ntr-o rela ie separat !. n cadrul rela iei Reper1 din fig.8.5. se manifest! urm!toarele dependen e multivaloare: Codreper Codprodus Codma$in! Codsec ie Deci rela ia Reper1 nu se afl! n FN4. Rezultatele aducerii rela iilor din fig. 8.5 n FN4 sunt prezentate n fig. 8.8. ReperFN4 Codreper Codma$in! Nroper R1 Codoper R2 Nroper R3 Codreper R4 Codmasina

Codoper

Timppreg Timpexec:

Categoper

Categoper

Codprod

Codsectie:

Fig. 8.8. Rela iile ob inute prin aducerea rela iilor din fig. 8.5. n FN4 8.2.7 Aducerea rela!iilor n FN5 Presupune eliminarea dependen elor join din cadrul rela iilor aflate n FN4. Procesul de aducere a unei rela ii din FN4 n FN5 se desf!$oar! astfel: 1. Se identific! dependen ele join. ntre mul imile de atribute A, B $i C din cadrul unei rela ii exist! o dependen ! join atunci cnd exist! dependen e multivaloare ntre fiecare dintre perechile de mul imi: (A, B), (B, C) $i (A, C). Prin urmare, o dependen ! join poate exista numai n cadrul acelor rela ii n FN4 care prezint! chei compuse $i atribute comune n chei. Dac! exist! dependen e join n cadrul rela iei considerate se trece la pasul 2. Dac! nu, procesul de aducere a rela iei n FN5 se ncheie. 2. Se descompune rela ia ini ial!, n scopul ob inerii FN5. Considernd c! schema rela iei con ine mul imile de atribute A, B $i C $i c! ntre fiecare pereche (A, B), (B, C), (A, C) exist! dependen e multivaloare, rela ia trebuie descompus! n trei rela ii: r1(A,B), r2(B,C) $i r3(A,C).

53

BAZE DE DATE CURS 9 STRUCTURA FIZIC A BAZELOR DE DATE 9.1 Consideraii privind structura fiierelor 9.2 Tipuri de organizare a fiierelor 9.3 Metode de cutare in fiiere 9.4 Metode de memorare pentru nregistrri cu lungime variabila 9.1 Consideraii privind structura fiierelor n acest capitol vom descrie nivelul fizic al bazelor de date. Plecnd de la necesitatea reprezentrii informaiilor i a legturilor ntre informaiile ce constituie o baz de date vom descrie metode de organizare i de operare cu astfel de structuri folosind mediile de memorare. Nivelul la care se face gestionarea informatiilor de catre sistemele de operare actuale este cel de fiier. Dup coninut, fiierele se mpart n mai multe clase dintre care cele mai des utilizate sunt cele ce urmeaz: - directoarele sunt fiierele care dau informatii despre alte fiiere; cu ajutorul directoarelor se pot contrui structuri arborescente ce permit accesul la oricare fiier din sistem plecnd de la un director initial numit radacina; orice nod interior al arborelui de structura corespunzator fiierelor este un director; de obicei, directoarele nu sunt frunze n arbore (exceptie sunt doar directoarele vide); - fiierele de date contin informatii ce pot fi prelucrate de programe; - fiierele text contin informatii alfanumerice de informare a utilizatorilor sau diferite documente memorate n sistem; - fiierele cod sursa contin programe scrise intr-un limbaj de programare; - fiierele cod obiect contin programe compilate. - fiierele executabile contin programe ce pot fi lansate n executie; un caz particular il reprezinta fiierele de comenzi care contin o succesiune de comenzi ale sistemului de operare sau lansari de alte programe. Principalele caracteristici ce definesc fiecare fiier sunt numele fiierului, tipul fiierului, lungimea, locul de memorare, modul de acces, data crearii sau a ultimei modificari i alte informatii. Tipul acestor informatii i modul lor de reprezentare difera de la sistem la sistem. Elementele componente ale unui fiier sunt nregistrrile. Fiecare nregistrare contine informatiile corespunzatoare unui obiect de tipul celor pentru care s-a construit fiierul. Fiecarei informatii i corespunde un tip, un domeniu de valori posibile, o lungime de reprezentare i o pozitie n nregistrare. Toate acestea definesc un cmp al nregistrrii. Structura nregistrrilor este descrisa de formatul nregistrrii asociat fiecarui fiier. Operatiile curente cu un fiier se reduc de cele mai multe ori la patru tipuri: inserare, tergere, modificare i cutare. Inserarea presupune introducerea unei noi nregistrri, tergerea presupune eliminarea unei nregistrri i modificarea presupune schimbarea unor valori ale unor cmpuri intr-o nregistrare. Aceste operatii nu schimba modul de organizare i modul de acces asociate fiierului. Cutarea presupune determinarea unor valori sau localizarea unor valori sau o combinatie a lor n functie de anumite calitati sau proprietati pe care trebuie sa le indeplineasca. Unitatea de transfer de informatii ntre fiier, memorat pe un mediu i memoria interna este blocul. Un bloc are de obicei lungimea o putere a lui 2 cuprins ntre 29 i 212 octeti. 1

Fiecarui bloc i se asociaza o adresa. Un bloc poate sa contina una sau mai multe nregistrri. De regula o nregistrare nu se poate memora n mai mult decat un bloc cu exceptia nregistrrilor cu lungimi mai mari decat lungimea blocului (caz rar intalnit) dar n acest caz nu pot apare informatii pentru doua nregistrri diferite n acelai bloc. nregistrrile pot sa fie localizate n mai multe feluri: prin adresa absoluta pe mediu de memorare care se face indicnd cilindrul, pista, sectorul i adresa n sector a inceputului nregistrrii (metoda mai rar utilizata n diferitele limbaje de programare), prin indicarea numarului asociat nregistrrii n cadrul fiierului, prin indicarea distantei fata de inceputul fiierului a inceputului nregistrrii, prin indicarea blocului i a adresei relative n bloc ( numarul nregistrrii din bloc sau distanta pana la capatul blocului). Referirea nregistrrilor (pointeri la nregistrare) se poate face prin oricare din metodele de adresare de mai sus. Un alt mod de adresare este prin intermediul valorilor unor cmpuri ale nregistrrilor, de cele mai multe ori ale cmpurilor corespunzatoare cheilor. Performantele unui sistem depind n foarte mare masura de timpul necesar accesului la bloc. Acest timp este determinat de caracteristicile fizice ale sistemului de calcul, de sistemul de operare folosit, de limbajul de programare utilizat i de modul de organizare a fiierului. Pentru gestionarea blocurilor i a nregistrrilor n blocuri, fiecare bloc are la inceput o eticheta care poate sa contina numarul nregistrrilor ocupate, biti de ocupare sau biti de tergere. 9.2 Tipuri de organizare a fiierelor n organizarea fiierelor se tine seama de mai muli factori cum ar fi frecventa cu care se efectueaza anumite tipuri de operatii asupra fiierelor, cmpurile implicate n operatiile de cutare (cheile fiierului) sau relatia n care se afla nregistrrile fiierului cu alte informatii din sistem. Dac exita ponteri la unele nregistrri din fiier se spune ca fiierul este cu nregistrri fixate i n acest caz fiecare nregistrare ramane, de obicei pe locul pe care a fost introdusa, locul ocupat de o astfel de nregistrare nu mai poate fi refolosit dup eliminarea nregistrrii. n caz contrar se spune ca fiierul este cu nregistrri nefixate, nregistrrile putand fi mutate sau spaiul eliberat prin eliminarea unor nregistrri putand fi reutilizat. Cele mai des utilizate tipuri de organizare a fiierelor sunt: secvential, cu dispersie, cu index rar, cu index dens, cu structura de B-arbore. Aceste cinci tipuri de organizare a fiierelor vor fi descrise pe scurt n cele ce urmeaza. 9.2.1 Fiiere secveniale Fiierele secventiale (heap files) presupun nregistrrile memorate ca elementele unei liste liniare de cele mai multe ori n blocuri consecutive, legate ntre ele prin pointeri sau prin construirea unui tabel separat cu adresele acestor blocuri ce permit accesul la ele. Inserarea unui element se face de cele mai multe ori prin adaugarea noului element la sfaritul listei (n special n cazul fiierelor cu nregistrri fixate i neordonate). Inserarea se mai poate face prin includerea noii nregistrri pe primul loc disponibil pentru fiiere cu nregistrri nefixate i cu biti de tergere, prin includerea noii nregistrri intr-un bloc existent sau unul nou i legarea ei n lista pentru nregistrri fixate sau ordonate, prin deplasarea fizica a unor nregistrri pentru a face loc noii nregistrri n cazul fiierelor cu nregistrri nefixate i ordonate sau prin alte tehnici asemanatoare. tergerea unui element se face prin inlocuirea elementului care se elimina cu ultimul element al fiierului, prin deplasarea elementelor care urmeaza nregistrrii care se elimina cu un element catre inceputul fiierului pentru fiiere cu nregistrri nefixate i fara bit de tergere, eventual ordonate, prin modificarea bitului de tergere sau prin eliminarea din lista cu legaturi i marcarea nregistrrii ca libera. Pentru fiierele cu nregistrri nefixate pentru care unele blocuri nu mai contin nregistrri, acele blocuri sunt eliberate i pot fi reutilizate. 2

Modificarea unui element se face de obicei prin citirea nregistrrii corespunzatoare, modificarea cmpurilor implicate i rescrierea n acelai loc a valorilor rezultate. Pentru fiierele ordonate pentru care sunt afectate cmpuri ce contribuie la ordonare operatia de modificare presupune citirea valorilor nregistrrii implicate, tergerea nregistrrii din fiier, modificarea valorilor cmpurilor i inserarea unei noi nregistrri cu valorile reactualizate. Cutarea unui element se poate face prin parcurgerea secventiala a tuturor elementelor fiierelor i verificarea conditiilor de selectionare a nregistrrii examinate. Aceasta metoda presupune n medie examinarea a (N+1)/2 nregistrri la o cutare cu succes i a N nregistrri la o cutare fara succes, unde N este numarul de nregistrri din fiier. Dac fiierul este ordonat i se face cutaredup cheie (cmpuriledup care s-a facut ordonarea) se obine o eficienta mai buna n cazul cautarii secventiale la cutarea fara succes i anume n medie (N+1)/2 nregistrri examinate dar mai eficiente sunt cautarile binare care dau n medie log N nregistrri examinate sau cautarile cu calculul adresei care dau n medie log log N nregistrri examinate. Avantaje: programe simple de organizare i utilizare, nefolosirea sau folosirea n mica masura a spaiului suplimentar pentru legaturi sau alte informatii, posibilitati multiple de reorganizare, uneori permit operare simpla utilizabila pentru fiiere dinamice. Dezavantaje: numarul mare de elemente examinate n medie la cutare, operatii dificile n cazul fiierelor ordonate. Utilizare: Dac n cazul unor fiiere mari organizarea secventiala este practic ineficienta, n cazul unor fiiere de dimensiuni mici se poate utiliza cu succes aceasta organizare. 9.2.2. Fiiere cu dispersie Fiierele cu dispersie (hashed files) grupeaza nregistrrile n clase de nregistrri fiecare clas fiind memorat n unul sau mai multe blocuri de memorie. Apartenena unei nregistrri la una din clase este determinat rapid (de obicei printr-un proces de calcul) n functie de valoarea pe care o are cheia nregistrrii. Funcia care determin aceasta coresponden se numeste functie de dispersie. Fiecare clas este organizat prin metode de organizare secvenial. Numrul de clase i modul de calcul al clasei asociate unei nregistrri se aleg n aa fel nct s asigure pe de o parte o distributie ct mai uniform n clase i pe de alt parte ca numrul mediu de nregistrri ntr-o clas s nu fie prea mare pentru a da un timp rezonabil la cutare. O funcie de dispersie des utilizat este cea care interpreteaz irul de bii corespunzator chei ca un numar natural iar clasa asociata elementului este data de restul mpartirii acestui numar la numarul de clase (eventual adunat cu 1 dac numerotarea ncepe de la 1 i nu de la 0). n implementarea fiierelor cu dispersie se construieste o list numita director cu pointeri la blocul de ncepere corespunzator fiecarei clase, blocurile unei aceleiai clase fiind nlnuite ultimul bloc avnd pointer nul. Directorul este memorat n blocuri ale fiierului i dac este de dimensiuni mici este incarcat n memoria principala de cate ori se lucreaza cu fiierul respectiv pentru a micsora numarul de accese la memoria externa. Operatiile cu fiiere cu dispersie se fac analog cu operaiile cu fiiere secventiale, singura deosebire fiind data de localizarea clasei corespunzatoare nregistrrii implicate. Dac clasele devin prea mari se pune problema reorganizarii fiierului cu mrirea numarului de clase. O buna alegere a funciei de calcul a clasei permite ca n cazul unei mriri de un numar de ori a numarului claselor, noua funcie de calcul s stabileasca drept noi clase partitii ale vechilor clase. De exemplu dac se dubleaza numarul de clase i functia de imprastiere este obtinuta ca restul unei impartiri la numarul de clase, atunci orice clasa i se imparte n doua clase distincte i anume i i n+i unde n este numarul initial de clase. Deci n acest caz operatia de reorganizare se poate face clasa cu clasa. 3

Avantaje: timp relativ redus de acces pentru clase de dimensiuni mici, programe relativ simple de gestionare i utilizare, posibilitati de organizare n cazul fiierelor cu nregistrri fixate. Dezavantaje: spaiu suplimentar pentru organizarea claselor, posibile reorganizari, dificila parcurgerea n ordine a nregistrrilor din tot fiierul. Utilizare: organizare destul de des utilizata n tehnicile de implementare a bazelor de date mai ales pentru modelele retea i ierarhic; cu posibilitati bune de operare n cazul fiierelor dinamice. 9.2.3. Fiiere cu index rar Fiierele cu index rar sau indexat secventiale presupun memorarea nregistrrilor intrun fiier numit fiierul principal n ordinea crescatoare a cheilor i grupate pe pagini. Se adauga un alt fiier, numit fiierul index ce contine pentru fiecare pagina din fiierul principal cate o nregistrare cu valoarea celei mai mari chei din pagina i adresa de inceput a paginii. Fiierul index este ordonat crescator n raport cu valoarea cheii folosind pentru el o metoda de organizare oarecare. De cele mai multe ori pagina corespunde cu un bloc. nlnuirea blocurilor n ordinea crescatoare a cheilor permite parcurgerea secventiala ordonata a fiierului. Din necesitati practice se pot nlnui i blocurile corespunzatoare fiierului index. Cutarea se face cu o cutare n fiierul index prin metode adecvate organizarii lui (cutare liniara, cutare binara sau cutare prin calculul adresei) pentru gasirea unei nregistrri ce contine cea mai mica cheie mai mare sau egala cu cheia cautata. Adresa din acea nregistrare da posibilitatea acesului la pagina care poate contine nregistrarea cautata. Apoi se face o cutare secventiala sau prin alta metoda n acea pagina. Eventual se testeaza bitul de existenta sau bitul de tergere dac acestia exista. Inserarea se face urmand procedeul de la cutare pentru determinarea paginii unde urmeaza sa apara noua nregistrare i dac mai este loc n pagina se aplica procedeul de inserare n fiier ordonat, altfel se introduce un bloc nou cu distribuirea nregistrrilor implicate i modificarea corespunzatoare a fiierului index. Dac cheia noii nregistrri este mai mare decat cea mai mare cheie existenta n fiier trebuie modificata cheia ultimei pagini din index punand cheia ultimei nregistrri introduse. tergerea unui element se face prin eliminarea elementului din lista ordonata corespunzatoare paginii n care apare acea nregistrare. Dac blocul nu mai contine nici-o nregistrare se elimina blocul respectiv din fiierul principal cu modificarea corespunzatoare a indexului. Se observa ca n cazul n care se elimina nregistrarea cu cheia cea mai mare din pagina sistemul functioneaza corect i dac lasam neschimbat indexul n acest caz. Modificarea se face prin citire, schimbarea valorilor i rescriere cnd nu sunt afectate cmpuri ce apartin cheii sau prin tergere i inserare n cazul afectarii unor cmpuri ce apar n cheie. Pentru fiierele cu nregistrri fixate indexul nu se schimba iar noile nregistrri introduse i care nu mai incap n blocurile corespunzatoare lor n blocuri noi legate de acestea formand clase ca la fiierele prin dispersie. Dac clasele devin foarte mari trebuie aplicata o reorganizare. Parcurgerea n ordine a nregistrrilor se poate face dac se asociaza fiecarei nregistrri un pointer la nregistrarea urmatoare. Avantaje: spaiu supimentar pentru reprezentarea fiierului index relativ redus, permite determinarea nregistrrilor cu chei intr-un interval dat, bine adaptabil pentru fiiere dinamice, fiierele index nu sunt cu nregistrri fixate ceea ce permite reorganizari mai simple i permite aflarea nregistrrii cu cheia cea mai mica dintre cele cu chei mai mari decat o valoare data (cheia ce acopera o valoare v data). Dezavantaje: uneori poate sa consume spaiu suplimentar mult dac paginile nu sunt incarcate pana aproape de capacitatea maxima, operatii de depasire a capacitatii unei pagini dificil de manevrat. 4

Utilizare: Se folosesc n special la organizarea unor fiiere statice sau pentru imbunatatirea timpului de acces la alte fiiere index. 9.2.4. Fiiere cu index dens Organizarea cu index dens presupune asocierea la un fiier numit fiierul de baza a unui alt fiier numit fiier index cu acelai numar de nregistrri ca fiierul de baza. nregistrrile din fiierul index contin, ca i n cazul fiierelor cu index rar, perechi formate din cheile nregistrrilor fiierului de baza i pointeri la aceste nregistrri dar de data aceasta pentru toate nregistrrile fiierului de baza. Pentru fiierul index se poate folosi oricare dintre tipurile de organizari prezentate. Avantaje: nregistrrile fiierului index sunt nefixate ceea ce permite o organizare mai eficienta, nregistrrile fiierului index fiind mai scurte decat ale fiierului de baza numartul de blocuri ce trebuiesc accesate este mai mic pentru diferitele operatii cu fiierul, la acelai fiier de baza pot fi asociate mai multe fiiere index corespunzatoare diferitelor chei. Poate fi utilizat n transformarea unui fiier cu nregistrri fixate intr-un fiier cu nregistrri nefixate. Dezavantaje: spaiu suplimentar ocupat, necesitatea combinarii cu alte metode, neasigurarea unei bune acoperiri a spaiului alocat. 9.2.5. Fiiere cu structura de B-arbore Pentru fiierele de dimensiuni foarte mari se poate privi indexul din organizarea indexat secventiala ca un fiier de baza i pentru el sa se organizeze un fiier index rar. Procedand recursiv pana se obine un fiier index ce ocupa un singur bloc obinem o structura indexata pe mai multe nivele foarte flexibila i eficienta de arbore echilibrat care are drept frunze blocuri ce contin pointeri la nregistrrile fiierului sau eventual chiar nregistrrile dac fiierul nu este cu nregistrri fixate. Numele de B-arbore al acestor structuri vine de la denumirea n limba engleza a lor balanced trees. Pentru a asigura o ocupare eficienta a spaiului toate operatiile care se fac n B-arbori respecta conditia de a lasa n toate blocurile cu exceptia eventual a radacinii a unui numar de nregistrri mai mare decat jumatate din capacitatea blocului respectiv. Dac de exemplu un nod intern poate memora 2d-1 nregistrri (cheie+adresa bloc) i o frunza poate sa memoreze 2e-1 nregistrri atunci nodurile interne cu exceptia eventual a radacinii trebuie sa aiba cel putin d nregistrri i frunzele trebuie sa aiba cel putin e nregistrri. Se observa ca intr-un B-arbore ultima cheie a fiecarui bloc nu este necesara presupunandu-se ca orice nregistrre cu cheia mai mare decat penultima cheie a blocului se afla n blocul dat de ultimul pointer. Cutarea se face incepand de la radacina i lund n continuare blocul dat de adresa corespunzatoare celei mai mici valori a unei chei dintre cele mai mari sau egale cu cheia cautata (n cutarea liniara este prima cheie mai mare sau egala cu cheia cautata) apoi aplicnd acest procedeu recursiv pana se ajunge la o frunza unde poate fi gasita nregistrarea cautata. Inserarea se face prin localizarea ca la cutare a blocului unde ar trebui sa se afle noua nregistrare i prin inserarea acelei nregistrri n blocul gasit dac mai este loc. Dac toate nregistrrile blocului sunt ocupate se creaza un nou bloc cele doua blocuri impartindu-i n mod egal nregistrrile i apoi inseranu-se la nivelul imediat superior adresa noului bloc impreuna cu cea mai mare cheie a lui (se presupune ca n blocul nou introdus s-au pus nregistrrile cu cele mai mici chei. Dac se ajunge astfel la radacina arborele creste numarul nivelelor cu unu noua radacina avnd n acest caz doi fii: un bloc nou introdus i vechea radacina. tergerea se face prin localizarea nregistrrii care se elimina ca la cutare i se elimina aceasta nregistrare din bloc. Dac n bloc raman mai mult de jumatate nregistrri 5

ocupate atuci procesul se termina, altfel blocul respectiv se combina cu un bloc vecin fie redistribuind nregistrrile fie, dac i acel bloc este la limita inferioara se formeaza din cele doua blocuri unul singur. Combinarea a doua blocuri poate produce modificari sau tergeri i la nivelele superioare uneori (foarte rar) putand micsora inaltimea arborelui (cazul unei radacini cu numai doi fii care se combina intr-un singur bloc). Modificarea se face la fel ca i pentru celelalte metode n functie de faptul dac sunt afectate sau nu cmpurile cheie. Pentru operatiile cu B-arbori se fac un numar de citiri/scrieri de blocuri de ordinul lui (log n - log e)/log d unde n este numarul de nregistrri din fiier, o frunza poate sa contina cel mult 2e-1 nregistrri i un nod intermediar poate sa contina cel mult 2d-1 perechi cu chei i adrese. Avantaje: aplicabil cu foarte bune rezultate n cazul fiierelor dinamice datorita numarului mic de blocuri accesate n operatii i a numarului mic de operatii la reactualizari, permite furnizarea listei elementelor n ordinea data de cheie, se poate aplica oricarui fiier unul sau mai muli B-arbori care sa lucreze ca fiiere index, o buna ocupare a spaiului alocat (n medie circa 75% spaiu ocupat). Dezavantaje: dificil de programat operatiile cu B-arbori, folosire spaiu suplimentar pentru nodurile interne. 9.3. Metode de cutare n fiiere Operaia cel mai des utilizat n lucrul cu fiierele este operaia de cutare. Unele din problemele privind cutarea au fost discutate mai sus. Vom prezenta i alte probleme specifice pentru bazele de date. 9.3.1. Fiiere cu index secundar Nu toate cautarile din bazele de date se fac dup cheia principal. Dac un atribut sau un grup de atribute apar des n cereri atunci pentru acel atribut sau grup de atribute se construieste un index numit index secundar ce permite accesul rapid la nregistrrile corespunzatoare valorilor date. Un fiier cu un index secundar corespunzator unui atribut sau grup de atribute F, se spune ca este fiier inversat n raport cu F. n indexul secundar nregistrrile sunt indicate fie prin pointeri la ele fie prin valorile cheilor principale corespunzatoare lor. Referirea la nregistrri prin pointeri are avantajul accesului mai rapid la informatie dar produce constrangeri din cauza fixarii nregistrrilor pe locul pe care au fost introduse sau la nivel de bloc sau la nivel de clasa. Referirea prin cheia principala asociata are dezavantajul unui acces mai lent dar nu mai fixeaza nregistrrile. 9.3.2. Indicarea parial a chei de cutare Dac ne intereseaza nregistrrile care au valorile a1,a2,...,ak pentru atributele A1,A2,...,Ak care nu constituie o cheie, aceasta revine la determinarea intersectiei mulimilor S1,S2,...,Sk unde Si este mulimea tuturor nregistrrilor care au valoarea ai corespunzatoare atributului Ai. O metod utilizat n acest caz este metoda indecilor secundari multipli. Din indecii asociati atributelor A1,A2,...,Ak se determina mulimile de pointeri P1,P2,...,Pk ale pointerilor catre nregistrrile mulimilor S1,S2,...,Sk i dac acestea nu au prea multe elemente se face intersectia lor n memoria principala. O varianta este alegerea unui indice i pentru care mulimea Si are cele mai putine elemente (de obicei se ia mulimea pentru care atributul poate lua cele mai multe valori) i apoi se verifica pentru aceste elemente dac indeplinesc i 6

celelalte conditii. Dac pointerii sunt la nivel de bloc, metoda intersectiei mulimilor de pointeri poate sa produca i elemente false i se fac verificari suplimentare. A doua metoda utilizata n acest caz este o generalizare a fiierelor cu dispersie ce folosesc functii de dispersie partitionate. n aceasta metoda la calculul clasei unui element contribuie toate cmpurile nregistrrii. Cu functii de dispersie bine construite se poate limita numarul de clase n care se poate afla o nregistrare pentru care cunoastem numai o parte dintre cmpuri. Aceasta se obine impartind bitii unui numar de clasa n mai multe parti componente i atribuind fiecarui atribut posibilitatea de a determina o anumita parte asociata din adresa. Sa presupunem de exemplu ca numarul de clase este o putere a lui 2 i anume 2B, deci adresa unei clase este un ir de B biti. Vom imparti cei B biti n grupe, cate o grupa pentru fiecare atribut (eventual unele grupe nu au nici-un bit). Dac atributele sunt A1,A2,...,Ak i atributului Ai i sunt atribuiti bi biti, determinam clasa nregistrrii (a1,a2,...,ak) calculand hi(ai) pentru i=1,...,k unde hi este o functie de dispersie pentru atributul Ai cu valori ntre 0 i 2bi-1 iar numarul clasei nregistrrii se obine prin concatenarea acestor adrese deci este irul de B biti h1(a1)h2(a2)...hk(ak). Pentru cutare se construiesc numere de clase cu valori fixate, obinute aplicnd functia de dispersie unei valori cunoscute pentru atributele pentru care se cunosc valorile i luand toate posibilitatile pentru grupele asociate atributelor pentru care nu se cunosc valorile. Dac se cunosc probabilitatile cu care atributele apar intr-o cerere atunci se pot stabili proprietati interesante dup cum urmeaz. Teorema 9.1. Dac valorile unui atribut sunt egal probabile cnd se specifica o valoare pentru acest atribut, atunci se obine n medie un numar minim de clase de examinat pentru a obine raspunsul la o cerere dac, pentru anumite numere n1,n2,...,nk al caror produs este numarul de clase, adresa clasei asociate nregistrrii (a1,a2,...,ak) se exprima cu formula hk(ak)+nk(hk-1(ak-1)+nk-1(hk-2(ak-2)+...+n2h1(a1)...)) unde functia de dispersie hi(ai) ia valori ntre 0 i ni. Din aceasta teorema se deduce ca alegand fiecare ni ca o putere a lui 2 putem sa obinem o aproximatie a unei solutii optime. Alegerea puterilor lui 2 este o alta problema care a fost rezolvata numai n cazuri particulare. Dac n cereri se considera valoarea unui singur atribut atunci valorile b1,b2,...,bk se aleg dup cum urmeaz din teorema: Teorema 9.2. Dac toate cererile specifica doar cate un atribut i pi este probabilitatea ca Ai sa fie atributul specificat, atunci, presupunand ca nici-un bi nu este mai mic decat 0 sau mai mare ca B, numarul mediu de clase cercetate este minim dac bi=(B - (log p1 + log p2 +...+ log pk))/k + log pi unde p este numarul de atribute, 2B este numarul de clase i logaritmii sunt n baza 2. Demonstratia acestei teoreme se face utilizand metoda multiplicatorilor lui Lagrange i poate fi gasita n Ullman. Formula din teorema permite aflarea valorilor elementelor bi aplicnd urmatoarele reguli: - dac un bi este mai mare decat B se face acel bi egal cu B i se fac 0 celelalte valori; - dac o valoare bi este negativa se elimina atributul corespunzator din calcule i se reaplica teorema; - se trunchiaza valorile bi (luandu-se partea ntreaga a lor) i eventualele unitati ramase se adauga la valorile acelor bi care au partea zecimala cea mai mare. Exemplul 9.1. Sa consideram un fiier corespunzator entitatii STUDENT avnd atributele MATRICOLA, NUME i DATA_NASTERE care sunt cerute cu probabilitatile 0.24, 0.75 i respectiv 0.01. Presupunem ca formam 512 clase, deci B=9 i aplicnd formula 7

din teorema obinem bi=6.03 + log pi, de unde rezulta b1=3.98, b2=5.62 i b3=-0.61. Deoarece b3 este negativ se ia b3=0 i se refac calculele numai pentru primele doua cmpuri cu probabilitatile p1=0.24/(1-0.01)=0.242 i respectiv p2=0.75/(1-0.01)=0.758 de unde se obine bi=5.72+log pi rezultand b1=3.68 i b2=5.32 apoi prin trunchiere la 3 i respectiv 5 se obine disponibil o unitate care se adauga lui b1 care are partea fractionara cea mai mare obtinand n final b1=4, b2=5 i b3=0. Un alt caz n care se pot specifica valorile optime pentru bi este cel n care se cunosc probabilitatile cu care cmpurile sunt mentionate n cereri aceste probabilitati fiind independente de mentionarea altor cmpuri n aceeai cerere. Formulele de calcul pentru bi sunt date de teorema urmatoare: Teorema 9.3. Dac pi este probabilitatea cu care se specifica valoarea atributului Ai intr-o cerere independent de celelalte valori specificate, atunci, presupunand ca bi nu sunt negativi sau mai mari decat B, numarul mediu de clase de cautat este minim dac se ia bi=(B - (log q1 + log q2 +...+ log qk))/k + log qi unde qi=pi/(1-pi), i=1,2,...,k, restul conditiilor fiind ca la teorema 9.2. Algoritmul de calcul al valorilor bi, i=1,...,k este la fel ca n cazul precedent doar ca n loc de pi se ia pi/(1-pi) n calcule. Exemplul 9.2. Sa consideram fiierul corespunzator entitatii COMENZI care are atributele NUME, MARFA, CANTITATE i DATA specificate cu probabilitatile p1=0.8, p2=0.5, p3=0.01 i p4=0.2 i numarul de clase este 512, deci B=9. Facnd calculele se obine b1=5.91, b2=3.91, b3=-2.73 i b4=1.91. Cum b3 este negativ se elimina atributul CANTITATE din calcule i se face b3=0. Refacnd calculele se obine b1=5, b2=3, b3=0 i b4=1 i nu mai sunt necesare reajustari. Numarul de clase cercetate la o cerere este n acest caz de 58.3 n medie. 9.3.3. Cazuri speciale de cutare n cereri pot sa intervina i alte tipuri de conditii pentru determinarea unei nregistrri sau unei mulimi de nregistrri decat cele prezentate pana acum. Un astfel de caz il constituie indicarea limitelor ntre care trebuie sa se afle valorile corespunzatoare unor cmpuri pentru a selectiona nregistrrile. Acest tip de cereri le vom numi cereri dup marime. Pentru cererile dup marime se pot aplica metodele anterioare cu o alegere corespunzatoare o tehnicilor de lucru. De exemplu se poate adapta tehnica de dispersie partitionata alegand functiile de dispersie n asa fel incat elementele din clase diferite sa fie n aceeai relatie de ordine ca i adresele lor. Un exemplu de astfel de functie este urmatorul. Dac numarul de clase este M (deci adresele claselor sunt de la 0 la M-1) i valorile unui cmp sunt relativ uniform distribuite pe intervalul [a,b) se ia drept clasa pentru valoarea v numarul [(v-a)/(b-a)*M] unde prin [] am notat partea ntreaga a numarului respectiv. Pentru distributii neuniforme sau nespecificarea intervalului de variatie a valorilor cmpurilor se pot defini alte functii de dispersie mai bune (eventual tabelate). O alternativa de rezolvare este i folosirea B-arborilor construind cate un B-arbore pentru fiecare atribut n parte, selectionand din ei pointeri catre nregistrrile care au valori cuprinse ntre limitele precizate i apoi facnd intersectia acestor mulimi pentru a identifica toate nregistrrile care indeplinesc toate conditiile specificate. 9.4 Metode de memorare pentru nregistrri cu lungime variabila n practica apar situatii cnd o nregistrarte nu are o lungime fixa. Aceasta se intampla mai ales n cazul cnd un cmp sau o combinatie de cmpuri se repeta de mai multe ori. De exemplu, n cazul unei relatii de forma unu-la-mai-muli de la entitatea E1 la entitatea E2 8

poate fi implementata logic n felul urmator: fiecarui element al lui E1 i corespunde o nregistrare a unui fiier care include toate informatiile elementelor entitatii E2 care corespund n relatia data elementului din entitatea E1. La nivel fizic, fiierele cu nregistrri logice de lungime variabila sunt reprezentate tot prin fiiere cu nregistrri de lungime fixa. De obicei transformarea nregistrrilor logice de lungime variabila se face prin una din urmatoarele trei metode: metoda spaiului rezervat, metoda nlnuirii sau metoda mixta. Operatiile cu fiiere cu nregistrri de lungime variabila se fac la fel ca la celelalte fiiere tinand seama de modul de organizare a lor. n acest caz intervin operatii suplimentare ce privesc unele repetari ale grupului repetitiv. Aceste operatii sunt tratate ca operatii pe fiiere obisnuite interpretand repetarile unui grup repetitiv ca un mic fiier. 9.4.1. Metoda spaiului rezervat n metoda spaiului rezervat se rezervau pentru numarul maxim de ocurente posibile pentru atributul sau grupul de atribute care se repeta. Se poate decide care elemente sunt ocupate i care nu n ocurentele definite fie prin intermediul unui nou cmp care contine numarul de ocurente ce apar efectiv fie punand o valoare null n locurile neocupate. Aceasta metoda se poate aplica n cazul n care numarul maxim de repetari ale grupului de atribute este destul de apropiat de numarul mediu de repetari, pentru utilizarea eficienta a spaiului de memorie alocat, dar n acelai timp este destul de mic pentru a evita scrierea de mai multe ori a unor instructiuni din cauza numelor diferite date cmpurilor. 9.4.2. Metoda nlnuirii n metoda nlnuirii grupurile care se repeta sunt memorate intr-un fiier separat, n fiierul initial se pune legatura la primul bloc din al doilea fiier ce contine ocurente corespunzatoare acelei nregistrri (n cazul cnd nu exista astfel de ocurente se pune valoarea null). Dac repetarile ocurentelor depasesc capacitatea unui bloc, se folosesc blocuri suplimentare ce formeaza o lista cu legaturi. Aceasta metoda este utilizata mai ales n cazul n care numarul de ocurente este foarte mare sau numarul de repetari variaza foarte mult pentru nregistrrile logice. 9.4.3. Metoda mixt Cea de-a treia metoda este o combinatie a precedentelor doua metode i anume se rezerva loc n nregistrarea initiala pentru un numar nic de repetari ale grupului repetitiv i un pointer la primul bloc al lantului de blocuri (al altui fiier) ce contine celelalte repetari ce nu au putut fi puse aici. Acesta strategie se aplica mai ales n cazul cnd cele mai multe repetari sunt apropiate de numarul mediu de repetari n care caz numarul de rezervari de locuri este putin mai mare decat numarul mediu de rezervari urmand sa se apeleze la al doilea fiier numai n cazurile exceptie cnd numarul de repetari ale grupului repetitiv este mai mare decat numarul spaiilor rezervate.

BAZE DE DATE CURS 10 INTEGRITATEA I SECURITATEA BAZELOR DE DATE 10.1 Aspecte privind integritatea datelor 10.1.1 Integritatea semantica a datelor 10.1.2 Controlul accesului concurent la bazele de date 10.1.3 Salvarea si restaurarea bazei de date 10.2 Securitatea bazei de date 10.1 Aspecte privind integritatea datelor Protecia bazelor de date const ntr-un set de msuri umane i faciliti oferite de SGBD prin care se urmrete asigurarea integritii datelor, care se concretizeaz prin corectitudinea datelor introduse i manipulate, i a securitii datelor, ce vizeaz interzicerea accesului la date pentru persoanele ce nu au competene n folosirea lor. Aceasta capt o importan deosebit n contextul extinderii folosirii configuraiilor cu numr mare de utilizatori i cu un volum mare de date de prelucrat. n ceea ce privete protecia datelor, pot fi puse n eviden dou tendine: protecia mpotriva unor defecte sau erori accidentale i protecia complet care realizeaz n plus fa de prima i protecia contra unor aciuni voite. Teoretic, toate sistemele ar trebui s asigure protecia complet a datelor. n practic ns, costul proteciei, care crete pe msur ce sunt reduse posibilitile de apariie a unor erori i de violare a confidenialitii datelor, este cel care dicteaz complexitatea metodelor de protecie care vor fi utilizate. Aspectele proteciei bazelor de date ce vor fi prezentate n continuare se bazeaz pe presupunerea c protecia informaiei la nivelul sistemului de operare este asigurat. Corespunztor situaiilor care pot genera apariia unor date incorecte n baza de date, se disting trei aspecte ale asigurrii integritii datelor: 1. Asigurarea integritii semantice a datelor- presupune prevenirea introducerii unor date incorecte i a efecturii unor prelucrri greite. Dac acest lucru nu va fi mpiedicat sau semnalat imediat, datele vor fi utilizate n alte prelucrri, declanndu-se astfel un proces necontrolat de alterare a bazei de date. Cu ct sesizarea unei erori are loc dup o perioad mai mare, cu att efectele ei vor fi mai greu sau chiar imposibil de nlturat. 2.Controlul accesului concurent la date - presupune prevenire unor rezultate incorecte din execuia concurent a unor prelucrri multiutilizator. De exemplu, n cazul a dou prelucrri concurente cai n calcularea salariului mediu lunar al angajailor unei firme i respectiv unui procent de cretere de 10% salariilor angajailor, exist riscul ca salariului mediu s intervin valori actualizate i valori vechi ale salariu, rezultatul fiind evident fr semnificaie. 3.Salvarea i restaurarea bazei de date - presupun refacerea baza afectat de funcionarea anormal sau cderea SGBD sau SO sau ca urmare a unor defecte hardware. 10.1.1 Integritatea semantic a datelor Introducerea unor date incorecte sau prelucrrile ce furnizeaz rezultate greite trebuie prevenite prin includerea n programele de aplicaie a unor secvene de testare a datelor i prin utilizarea unor faciliti de asigurare a integritii semantice a datelor oferite de SGBD. Concret, orice operaie asupra datelor trebuie constrns s respecte anumite reguli, reguli care reprezint restricii de integritate. Restriciile de integritate se pot clasifica, dup modul n care sunt exprimate n: - restricii de integritate structurale; 10

- restricii de integritate de comportament. Restric iile de integritate structurale decurg din caracteristicile modelului utilizat pentru reprezentarea datelor i din elementele furnizate la structurii bazei de date. Astfel, la introducerea datelor nu vor fi acceptate valorile care nu aparin tipului de dat specificat pentru cmpurile respective din nregistrare. Dac exist conceptul de cheie unic, la inserare se va verifica unicitatea cheii. Structurile de date pot impune de asemenea rest tipurile de nregistrri. De exemplu, anumite sisteme impun o relaie de forma 1:N ntre printe i segmente dependente (dac segmentul rdcin conine date despre profesori i segmentele dependente date despre cursuri, sistemul impune automat restricia ca fiecare curs s aib un singur profesor). n modelul relaional, exist dou restricii de integritate asociate cheilor primare i celor externe i anume: 1. Integritatea entitii (entity integrity) - conform acesteia, nici un atribut care particip la formarea cheii primare a unei relaii nu poate primi o valoare NULL (valoare diferit de blanc sau 0, considerat n lipsa unei valori explicite pentru cmpul respectiv). Aceasta este o consecin a faptului c o cheie primar trebuie s identifice n mod unic tuplurile unei relaii. 2. Integritatea referenial (referenial integrity) - statueaz c orice valoare a unei chei externe din relaia care refer trebuie s aib corespondent o cheie primar cu aceeai valoare n relaia referit sau s fie NULL. Restriciile de integritate de comportament pot fi incluse n programele de aplicaie i verificate n momentul execuiei acestora sau pot fi memorate n dicionarul datelor i verificate automat de SGBD la fiecare operaie vizat asupra anumitor date. Aceast soluie, foarte frecvent n practic, prezint urmtoarele dezavantaje: - efortul de programare va fi mai mare i dimensiunea programelor va crete prin includerea prilor de cod pentru testarea restriciilor de integritate. - restriciile de integritate asociate anumitor date trebuie testate de fiecare program care lucreaz cu datele respective; o aceea i parte de cod va trebui repetat n toate aceste programe. - programele de aplicaie nu pot controla operaiile efectuate de utilizatori n limbajele de interogare de nivel nalt, existnd deci n continuare pericolul afectrii integritii datelor. - dac restriciile de integritate se schimb, efortul pentru modificarea tuturor programelor implicate va fi foarte mare. Toate aceste dezavantaje dispar n cazul specificrii restriciilor de integritate la nivelul SGBD. Acestea pot fi exprimate cu ajutorul limbajului de definire a datelor sau al limbajului de manipulare a datelor, n funcie de particularitile fiecrui SGBD. n diferite lucrri de specialitate, o regul de integritate este reprezentat printr-un tuplu forma: (o, t, c, p, pa) unde: o - reprezint obiectul asupra cruia se aplic restricia de integritate; t - indic tipul opera iei pentru care restric ia va fi invocat (INSERT, UPDATE, DELETE); c - este o condi ie care trebuie s fie adev rat pentru ca restric ia de integritate s se aplice obiectului o (de exemplu, dac restricia se refer doar la studenii din facultatea cu codul MAT, condiia va fi de de forma COD_S = 'MAT'); p - restricia de integritate, care trebuie s fie adevrat pentru o realizare a obiectului o, pentru ca operaia cerut s poat fi efectuat; pa - o procedur auxiliar care specific ce trebuie s fac sistemul dac p nu este adevrat (poate fi utilizat pentru efectuarea de verificri de integritate foarte complexe, 11

pentru realizarea unei jurnalizri selective ca i pentru ntreinerea automat a bazei de date). De exemplu, regula pentru o restricie de integritate care prevede la inserarea unui tuplu ntr-o relaie cu date despre studenii unei faculti, incrementarea numrului de studeni este: o - relaia STUDENT t - INSERT c - true p - false pa - NR_STUDENI = NR_STUDENI + 1 n practic, complexitatea relaiilor de integritate exprimare i de implementare difer de la un SGBD la altul. 10.1.2 Controlul accesului concurent la bazele de date Sistemele monoutilizator rspund unui numr redus de probleme practice care implic utilizarea bazelor de date. Cea mai mare parte a aplicaiilor trebuie concepute pentru a putea funciona n regim de lucru multiutilizator i implementate pe sisteme care prezint aceast caracteristic. Pe lng aspectele prezentate privind asigurarea integritii datelor, n acest caz apare i necesitatea controlului accesului concurent la date. n sistemele multiutilizator, sistemul de operare asigur accesul concurent al programelor n execuie la resurse dup o anumit disciplin intern. n cazul aplicaiilor care utilizeaz o aceeai baz de date, ntreruperea executrii unui proces pentru nceperea sau continuarea altora poate conduce la alterarea datelor. Asigurarea integritii datelor n acest context presupune existena unor faciliti speciale pentru controlul accesului concurent la date la nivelul SGBD. Pentru prezentarea acestora este necesar explicarea conceptului de tranzacie. Tranzacia este o secven de operaii care din punctul de vedere al SGBD constituie o unitate de prelucrare, aceasta nsemnnd c se va accepta fie executarea complet fie, n situaia n care acest lucru nu este posibil, nu va trebui reinut nici o modificare fcut de ea asupra bazei de date, SGBD efectund (automat sau la comand) derularea napoi a tranzaciei. O tranzacie este caracterizat de punctul su de nceput i de punctul de sfrit. Dup modul n care acestea sunt definite, tranzaciile se pot clasifica n: Tranzacii implicite - sunt acelea pentru care punctele de nceput i sfrit sunt automat definite. Pentru SQL-Server de exemplu, toate comenzile de modificare a datelor (INSERT, UPDATE i DELETE) sunt tratate ca tranzacii implicite. n consecin, nici una dintre aceste comenzi nu va putea lsa baza de ntr-o stare inconsistent. Acest lucru este ilustrat prin exemplul 10.1. Exemplul 10.1 Comanda de inserare INSERT student VALUES ( 101, Popescu, 221, 12-03-1989, Bucuresti) va avea efect asupra bazei de date doar dac va putea fi executat integral. Dac ns sistemul cade naintea terminrii execuiei acesteia, baza de date nu va fi lsat n starea n care doar unele dintre valorile coloanelor exist, sau n care un index nu este actualizat. Tranzacii explicite - presupun folosirea unor comenzi speciale pentru stabilirea punctelor de nceput i sfrit ale tranzaciei. n SQL - Server, tranzaciile explicite permit utilizatorului s grupeze un set de comenzi SQL ntr-o tranzacie folosind comenzile BEGIN TRANSACTION i COMMIT TRANSACTION pentru precizarea punctelor de nceput i sfrit. De asemenea, utilizatorul poate defini puncte de salvare (utile n cazul tranzaciilor foarte mari) folosind comanda SAVE TRANSACTION sau s deruleze napoi tranzacia pn 12

la punctul de nceput sau pn la puncte de salvare anterioare, folosind comanda ROLLBACK TRANSACTION. Exemplul 10.2 O tranzacie explicit poate fi reprezentat de nregistrarea unui transfer ntre dou conturi, fapt ce presupune debitarea contului X i creditarea contului Y. Aceste transformri vor fi grupate ntre comenzile BEGIN TRANSACTION i COMMIT TRANSACTION. Tranzacia fiind astfel definit, SGBD va garanta tratarea ei ca o secven unitar de prelucrri. BEGIN TRANSACTION Debit -100 din CONTUL X Credit +100 n CONTUL Y COMMIT TRANSACTION n anumite condiii, utilizatorul poate comanda derularea napoi a tranzaciei. Un exemplu l constituie o tranzacie care realizeaz creterea selectiv a valorilor dintr-o coloan a unei tabele, urmrindu-se meninerea unei limite pentru media acestor valori. n situaia n care aceast limit nu va fi respectat n urma modificrilor fcute, acestea vor fi anulate Exemplul 10.3 BEGIN TRANSACTION media IF (SELECT AVG (pre) FROM tabel) < 2000 BEGIN UPDATE tabel SET pret=pret*2 WHERE pret<1500 UPDATE tabel SET pret=pret*1.2 WHERE pret<2000 END IF(SELECT AVG (pre) FROM tabel) > 2000 BEGIN PRINT "Aceste modificri de preturi nu se realizeaz" ROLLBACK TRANSACTION END ELSE BEGIN PRINT "Media preturilor este < 2000" COMMIT TRANSACTION media END Pin controlul accesului concurent la date se urmrete pstrarea integritii de date n condiiile execuiei concurente a tranzaciilor. Efecte ale execuiei concurente necontrolate a tranzaciilor Efectele generate de execuia concurent necontrolat a tranzaciilor vor fi ilustrate prin urmtoarele exemple. Considerm, o tranzacie de actualizare a disponibilului n cont la banc (DISP) al clientului C, de 5000 RON iniial. Aceasta presupune efectuarea a dou operariuni asupra nregistrrii corespunztoare din baza de date: - citirea coninutului cmpului respectiv ntr-o zon de lucru din memorie - modificarea i scrierea noii valori n baza de date. Dac sunt iniiate dou tranzacii concurente: 13

T1- nregistrarea retragerii sumei de 500RON din cont T2 - nregistrarea depunerii sumei de 1000RON n cont din motive de performan, aciunile acestor tranzacii pot fi executate intercalat ca n fig. 10.1. t0 DISP T1 T2 5000 Citeste t1 5000 t2 5000 t3 4500 t4 4500 t5 6000 timp

DISP=DISP-500 Scrie DISP=DISP+1000 Scrie

Citeste

Fig.10.1. Execuia intercalat a unor tranzacii

n final, baza de date va conine pentru clientul C n cmpul DISP valoarea 6000 n loc de 5500 ct ar fi corect. Se observ deci c actualizarea realizat de T1 s-a pierdut ca efect al intercalrii aciunilor tranzaciilor T1 i T2. Un alt exemplu de inconsisten a datelor generat de lipsa controlului accesului concurent la date este ilustrat de fig. 10.2. Tranzaciile TI i T2 sunt executate serial ns, din anumite motive, transformrile efectuate de T1 trebuie anulate. n aceast situaie, valoarea utilizat n continuare de T2 nu va fi corect. Tranzaciei T2 ar fi trebuit s i se interzic citirea valorii lui x pn n momentul n care T1 ar fi fost ncheiat.

t0 VAL. x T1 T2 10

t1 10

t2 15 Scrie

t3 15

t4 15 Abort

t5 10

t6 25 timp

Citeste x=x+5

Citeste

x=x+10 Scrie

Fig.10.2. Execuia serial a unor tranzacii

Asemenea probleme se pot evita dac S.G.B.D. ofer posibilitatea blocrii datelor utilizate la un moment dat de o tranzacie, nelegnd prin aceasta interzicerea accesului celorlalte tranzacii concurente la aceste date.

Tehnica blocrii Aspectele prezentate sunt deci o consecin a execuiei concurente necontrolate a tranzaciilor. Execuia serial a tranzaciilor (una dup alta), care ar asigura consistena bazei de date, nu este posibil n regim multiutilizator. Ea st ns la baza criteriului formal de apreciere a efectelor execuiei concurente a tranzaciilor. Conform acestuia, o execuie neserial a unor tranzacii concurente va fi considerat corect dac este serializabil, adic dac produce acelai rezultat ca o execuie serial a acelor tranzacii. Dac SGBD va asigura doar execuii serializabile ale tranzaciilor, atunci consistena datelor va fi garantat. Tranzaciile considerate trebuie s fie independente, astfel ca orice execuie serial a lor s furnizeze acelai rezultat. n caz contrar, utilizatorul trebuie s se asigure c ele sunt date sistemului n secvena dorit.

14

Tehnica utilizat de SGBD pentru a asigura execuia serializabil a tranzaciilor tehnica blocrii. n cea mai simpl form, blocarea unor date de ctre o tranzacie interzice celorlalte tranzacii accesul la aceste date. Blocarea se poate aplica la nivelul ntregii baze de date, al unui fiier, grup de nregistrri sau nregistrare sau chiar cmp. Generic, n continuare vom vorbi despre resursa sau obiectul blocat. Soluia de blocare prezentat este prea restrictiv, ea fiind ns folosit de anumite SGBD. n exemplele prezentate, observm c trebuie urmrite dou aspecte: - accesul la datele pe care un utilizator intenioneaz s le actualizeze s fie interzis celorlali utilizatori pn la completarea procesului de actualizare; - accesul la datele pe care un utilizator le citete fr a le actualiza s fie interzis utilizatorilor pentru operaii de actualizare i permis pentru operaii de citire. Deci tipul de blocare trebuie difereniat n funcie de operaia care va fi executat asupra datelor respective astfel: - blocare pentru citire (partajabil) - datele vor putea fi folosite i de ctre ceilali utilizatori ns numai pentru operaii de citire; - blocare pentru scriere (exclusiv) - datele nu vor putea fi accesate de nici un utilizator. Efectiv, blocarea se realizeaz prin emiterea de ctre o tranzacie a unei cereri (explicite sau implicite) de blocare pentru SGBD. Cererea explicit poate fi exprimat n una din urmtoarele forme: - n cadrul unei comenzi de manipulare a datelor: UPDATE ANGAJAI WITH EXCLUSIVE LOCK SET SALARIU = SALARIU *1.1 - printr-o comand de nceput a unei tranzacii: BEGIN TRANSACTION WITH EXCLUSIVE LOCK BEGIN TRANSACTION WITH SHARED LOCK - printr-o comand de deschidere a unui fiier : OPEN FIIER FOR EXCLUSIVE UPDATE OPEN FIIER FOR SHARED READ Dac cererea este admis, tranzacia va continua. Altfel, cererea va fi pus ntr-olist de ateptare pn ce resursa vizat va fi eliberat. Situaiile n care o cerere pentru o anumit resurs poate fi admis, n condiiile n care exist deja o blocare pentru resursa respectiv, sunt ilustrate de matricea compatibilitii blocrilor partajabile i exclusive din fig. 10.3. T2 T1 Resursa X Blocare partajabil Blocare exclusiv DA NU NU NU Blocare partajabil Blocare exclusiv

Fig. 10.3. Matricea compatibilitilor Se observ deci c o blocare pentru citire poate fi acordat altor tranzacii chiar dac o tranzacie are deja o blocare partajabil pentru resursa respectiv; blocri exclusive nu pot fi ns acordate pn cnd toate blocrile partajabile nu sunt eliberate. Dac ns o tranzacie a obinut o blocare exclusiv pentru o resurs, nici o alt blocare (partajabil sau exclusiv) nu va mai putea fi garantat celorlalte tranzacii solicitante. 15

Accesul concurent la date pe de o parte i complexitatea mecanismului de blocare al unui SGBD pe de alt parte, sunt influenate de granularitatea blocarii. Considernd cele dou situaii extreme (baza de date i cmpul), putem sintetiza urmtoarele aspecte: - blocarea ntregii baze de date la o anumit operaie a utilizatorului i pune pe ceilali utilizatori n imposibilitatea de a accesa concurent datele, n timp ce gestiunea informaiilor de blocare se simplific foarte mult; - blocarea unui singur cmp al unei nregistrri las posibilitatea de acces concurent celorlali utilizatori chiar la cmpuri ale aceleiai nregistrri, ns face ca gestionarea informaiilor de blocare s fie foarte complex. Cele mai multe SGBD ofer posibilitatea blocrii la nivel de nregistrare, la nivelul unui grup de nregistrri pentru care s-a menionat un criteriu de selecie i la nivel de fiier. Pentru administrarea blocrilor se poate recurge la unul din urmtoarele moduri: - setarea unui bit pentru resursa respectiv, indicndu-se astfel c aceasta este blocat; - meninerea unei liste a resurselor blocate ce va trebui consultat ori de cte ori intervine o nou cerere de blocare; - meninerea resurselor blocate ntr-o zon special a memoriei. Interblocarea resurselor Interblocarea (deadlock) este un impas care rezult cnd dou tranzacii blocheaz anumite resurse, apoi solicit fiecare resursele blocate de cealalt. Aceast situaie este ilustrat n fig. 10.4. Tranzacia A va atepta la infinit eliberarea resursei Y, blocat de tranzacia B la pasul 2 i, la rndul ei, tranzacia B va intra ntr-o stare de ateptare infinit pentru resursa X, blocat de A la pasul 1. La nivelul SGBD trebuie s existe faciliti de prevenire sau rezolvare a acestor situaii. Astfel, poate fi implementat una din urmtoarele dou strategii: 1.Prevenirea interblocrii presupune ca programele s blocheze toate resursele de care au nevoie nc de la nceputul fiecrei tranzacii. n exemplul considerat, tranzacia A ar tebui s blocheze ambele nregistrri nc de la nceput. Dac una din resurse ar fi fost deja blocat, ar fi fost necesar s se atepte pn la eliberarea ei. Aceast strategie este dificil de implementat i adesea nu este aplicat, deoarece n cele mai multe cazuri, este imposibil de precizat nainte ce resurse vor fi necesare pentru o tranzacie. Tranzactia A 1 Blocare 3 Asteptare pana la elib. resursei y Resurse x Asteptare pana la elib. resursei x y Tranzactia B 4

2 Blocare

Fig. 10.4 Exemplu de interblocare 2. Soluionarea interblocrii - aceast strategie permite apariia interblocrii dar presupune existena unor mecanisme pentru detectarea i eliminarea acesteia. Intern, sistemul poate utiliza pentru aceasta un graf al precedenelor care reflect dependenele dintre procese din punctul de vedere al ordinii n care acestea trebuie executate. ntr-un astfel de graf, fiecare nod reprezint un proces activ. Arcele se traseaz conform urmtoarei reguli: dac procesul P deine resursa A i procesul Q o solicit, atunci n graf va fi trasat arcul Q P, care arat c 16

execuia procesului Q este condiionat de cea a procesului P. Existena unui interblocaj va fi semnalat prin prezena unui ciclu n graf. Fig. 10.5. prezint un astfel de graf i matricea asociat lui. P Q R S V1 V2 V3 P 0 1 0 0 1 1 1 Q 1 0 1 0 1 1 1 R 0 0 0 0 0 1 0 S 0 0 1 0 1 0 0 1 1 1 0

Fig.10.5 Graf i matricea asociat lui n matrice, cifra 1 arat c procesul de pe linia respectiv se afl n ateptare din cauza procesului de pe coloana corespunztoare. Algoritmul pentru determinarea interblocajului este urmtorul: 1. Se efectueaz operaia logic "SAU" ntre vectorii asociai liniilor matricei. Rezultatul va fi vectorul V1. 2. Se efectueaz operaia logic "SAU" ntre vectorii asociai coloanelor matricei. Rezultatul va fi vectorul V2; 3. Se efectueaz operaia "SI" ntre V1 i V2. Rezultatul va fi vectorul V3. Procesele S i R pentru care s-a obinut rezultatul 0 (vezi figura) vor fi eliminate din matrice. Ele nu pot fi implicate ntr-un blocaj ntruct S nu ateapt dup nici un alt proces (0 pe poziia corespunztoare din V1) i dup R nu ateapt nici un alt proces (0 pe poziia corespunztoare din V2); 4. Se elimin liniile i coloanele corespunztoare proceselor R i S i se reia algoritmul de la pasul 1, pn cnd nici un proces nu va mai fi eliminat. Procesele rmase n matrice vor fi cele ntre care a intervenit un interblocaj. n aceast situaie, unul dintre procesele implicate va fi ntrerupt, efectele lui de pn acum asupra bazei de date vor fi anulate, fiind posibil apoi continuarea celuilalt. Procesul ce va fi eliminat poate fi: - procesul cu cele mai puine resurse blocate; - procesul care nu a fcut nc actualizri asupra bazei de date ; - procesul cu cea mai mic prioritate; - procesul cel mai recent nceput; - procesul cel mai vechi; - procesul care a cerut ultimul utilizarea resursei. Procesul abortat urmeaz s fie reluat ulterior. 10.1.3 Salvarea si restaurarea bazei de date Salvarea i restaurarea bazei de date au ca scop readucerea datelor la o form consistent n urma unor evenimente care au alterat corectitudinea lor precum: - funcionarea anormal sau o cdere a SGBD sau SO; - o defeciune a suportului fizic pe care este memorat baza de date. n primul caz, prin ntreruperea tranzaciilor active n momentul respectiv, baza de date va rmne ntr-o stare de inconsisten. n cel de-al doilea caz, suportul pe care rezid baza de date va fi inutilizabil, deci toate datele se vor pierde.

17

n aceste situaii trebuie s fie posibil refacerea unei stri anterioare consistente a bazei de date. O stare consistent a bazei de date este starea n care sunt reflectate rezultatele finale ale execuiei unor tranzacii, nici o tranzacie nu este n curs de execuie i sunt satisfcute restriciile de integritate semantic. ndeplinirea cerinei formulate anterior presupune existena i utilizarea unor faciliti la nivelul SGBD. Aciunile ntreprinse n acest sens se nscriu n procesul de restaurare al bazei de date. Tehnici de baz folosite n procesul de restaurare O cdere a sistemului las baza de date ntr-o stare de inconsisten care poate consitui un punct de plecare n procesul de restaurare, n timp ce, n cazul unei defeciuni a suportului pe care este memorat baza de data, restaurarea va fi posibil doar dac exist o copie anterioar a bazei de date. Pe aceste baze deci, procesul de restaurare va trebui s asigure o stara consistent a bazei de date, minimiznd totodat volumul prelucrrilor pierdute. Pentru baza de date inconsistent, aceasta nseamn eliminarea efectelor tranzaciilor active n momentul cderii sistemului i reflectarea n baza de date a rezultatelor tranzaciilor terminate, dar care din motive ce vor fi prezentate ulterior nu apar n baza de date. Pentru o copie anterioar a bazei de date, va trebui s existe posibilitatea ca ntr-un timp ct mai scurt aceasta s fie adus la o stare consistent ct mai apropiat de momentul apariiei defeciunii. n ambele situaii este necesar existena unor informaii despre derularea tranzaciilor pn n momentul ntreruperii lucrului i aplicarea dup caz a uneia din urmtoarele tehnici de restaurare de baz: - derularea napoi a tranzaciilor necompletate (ROLLBACK) - care presupune anularea modificrilor efectuate de acestea asupra bazei de date; - derularea nainte a tranzaciilor completate dar nereflectate n baza de date (ROLLFORWARD) - care presupune efectuarea acelor transformri prin care baza de date restaurat s conin rezultatele acestora. Se observ deci c tranzacia poate fi considerat unitatea de restaurare, n sensul c baza de date restaurat trebuie fie s reflecte rezultatele finale ale tranzaciilor, fie s nu fie afectat de acestea. Procesul de restaurare utilizeaz o serie de informaii obinute prin aplicarea unei anumite strategii de salvare. Informaii utilizate n procesul de restaurare Salvarea, n contextul asigurrii integritii bazei de date, este procesul de stocare de date n vederea folosirii lor pentru restaurarea bazei de date. Volumul informaiilor ce se salveaz, natura lor i intervalul de timp dintre dou operaii succesive de salvare, determin strategia de salvare. Aceasta va influena procesul de restaurare a bazei de date. Astfel, stocarea unei cantiti mari de date, cu o frecven mare i n forme diferite (ceea ce are ca efect ntreruperi ale lucrului sau mrirea timpului de rspuns n exploatarea bazei de date) face posibil restaurarea simpl i rapid a bazei de date. n caz contrar, cu ct informaiile de care dispunem sunt mai srace, cu att procesul de restaurare va fi mai complicat i de durat. Datele salvate pot fi diferite combinaii ntre: - copii ale bazei de date i copii ale jurnalelor acesteia; - jurnale ale tranzaciilor; - jurnale ale imaginii nregistrrilor din baza de date. Copiile bazei de date pot fi realizate automat de ctre sistem la anumite intervale de timp, sau la comanda administratorului bazei de date, ori de cte ori este nevoie, de preferat pe suporturi magnetice diferite de cele pe care rezid baza de date. n cazul unei deteriorri a discului care pstraz baza de date, acestea constituie singura posibilitate de recuperare a 18

bazei de date. Ele pot fi utilizate ns ca unic surs de date n procesul de restaurare doar n situaia n care prelucrrile efectuate ntre momentul realizrii copiilor i cel al apariiei unei defeciuni pot fi reluate. Acest lucru este posibil dac prelucrrile sunt efectuate ntr-o secven cunoscut i timpul necesar pentru reprocesarea lor nu este foarte mare sau poate fi acceptat n contextul de lucru particular. Aceast limit, ca i rata mare a executrii unor astfel de copii face ca anumite SGBD s recurg la efectuarea de copii ale jurnalelor bazelor de date. Volumul datelor ce vor fi copiate este n acest caz mult mai mic, deci durata copierii va fi mai mic, iar procesul de restaurare implic doar ntr-o mic msur intervenia uman. Jurnalul tranzaciilor este un fiier special ntreinut de SGBD, n cure sunt memorate informaii despre tranzaciile efectuate asupra bazei de date, cum ar fi: - identificatorul sau codul tranzaciei; - momentul nceperii execuiei tranzaciei; - numrul terminalului sau identificatorul utilizatorului care a iniiat tranzacia; - datele introduse; - nregistrrile modificate i tipul modificrii. Pe baza lui va putea fi stabilit ulterior succesiunea corect i natura prelucrrilor efectuate n intervalul de timp pentru care trebuie s se asigure restaurarea bazei de date. Jurnalul imaginilor se deosebete de jurnalul tranzaciilor prin aceea c el nu conine descrierea operaiilor efectuate asupra bazei de date ci efectul acestora. Poate mbrca una din urmtoarele forme: -jurnalul cu imaginea nregistrrilor dup modificare (after image) - va conine copia fiecrei nregistrri ce este modificat n forma rezultat dup modificare; - jurnalul cu imaginea nregistrrilor naintea unei modificri (before image)-va cuprinde copia fiecrei nregistrri ce este modificat n forma iniial, anterioar efecturii modificrii; - jurnal care conine pe cele dou de mai sus. n prima form, jurnalul imaginilor permite restaurarea bazei de date prin derularea nainte a tranzaciilor ntr-un timp mai scurt dect n cazul utilizrii jurnalului tranzaciilor. Nu mai este necesar reprocesarea tranzaciilor, putnd fi utilizat direct rezultatul acestora, reprezentat de ultima imagine modificat a nregistrrii respective. n mod similar, cea de-a doua form a jurnalului imaginilor va putea fi utilizat pentru derularea napoi a tranzaciilor, fiind necesar doar regsirea nregistrrii memorate la nceputul fiecrei tranzacii. Derularea napoi a tranzaciilor este foarte dificil i uneori chiar imposibil dac se folosete doar jurnalul tranzaciilor. Cea de-a treia form faciliteaz mult procesul de restaurare, ns presupune meninerea unui volum mare de informaii redundante (pentru o nregistrare ceea ce constituie after image dup o modificare va deveni before image la urmtoarea modificare). n funcie de defeciunea care a determinat ntreruperea lucrului, restaurarea bazei de date se realizeaz automat de ctre SGBD, sau manual, nelegnd prin aceasta c procesul de restaurare va necesita intervenia uman. Restaurarea automat a bazei de date Restaurarea automat este determinat de SGBD dup oprirea i restartarea sistemului n urma unei cderi. Prin acest proces, baza de date este adus la o stare consistent, prin derularea napoi a tranzaciilor active n momentul defeciunii i continuarea tranzaciilor nregistrate ca finalizate n fiierul jurnal, dar care nu sunt nc reflectate n baza de date. Situaia n care efectele unei tranzacii completat naintea cderii nu se regsesc n baza de date ca i existena informaiilor necesare pentru restaurare n fiierele jurnal sunt explicate de modul n care este gestionat memoria principal. O cerere de aceea la date primit de SGBD va determina transferul unei pagini de disc n memoria principal. Eventualele modificri ale datelor, aflate acum n memoria principal, nu vor fi urmate imediat de rescrierea paginii respective pe disc. Acest lucru poate fi efectuat 19

periodic, la un anumit interval de timp, fie la o cerere explicit a sistemului sau pentru a face loc unei alte pagini de disc solicitat. Inlocuirea cu o alt pagin are la baz un algoritm de tipul LRN (least-recently-used). Astfel, va fi aleas pentru a fi nlocuit pagina de la a crei ultim actualizare s-a scurs cel mai mare interval de timp. Cu excepia situaiei n care este necesar nlocuirea unei pagini, rezult c paginile frecvent utilizate vor fi meninute n memorie, ceea ce duce la reducerea numrului de operaii de transfer ntre memoria principal si suportul extern de memorie, deci la creterea performanelor sistemului. Acelai regim de pstrare n memorie pn la un transfer ulterior pe disc se aplic i informaiilor de jurnalizare a tranzaciilor. SGBD trebuie ns s asigure nscrierea acestor informaii n fiierul jurnal nainte de scrierea datelor modificate n baza de date. Dac aceast ordine nu ar fi respectat, o cdere a sistemului dup scrierea n baza de date dar nainte de nregistrarea transformrilor respective n jurnal, ar face imposibil derularea napoi a tranzaciilor, cu alte cuvinte, chiar procesul de restaurare al bazei de date. De asemenea, paginile de memorie cu informaiile de jurnalizare a tranzaciilor, vor fi scrise pe disc automat n momentul execuiei unei comenzi de genul COMMIT TRANSACTION. Astfel se explic cum o tranzacie finalizat nu este reflectat de baza de date i cum jurnalul tranzaciilor poate oferi informaiile necesare procesului de restaurare automat a bazei de date. n afara aspectelor prezentate, sincronizarea memoriei cu baza de date i fiierul jurnal se realizeaz i prin executarea unui punct de verificare (checkpoint). SGBD poate executa puncte de verificare automat, la intervale fixe de sau ca rspuns la o comand explicit CHECKPOINT. Frecvena punctelor de verificare influeneaz durata procesului de restaurare automat a bazei de date. Aceasta din urm este direct proporional cu activitatea tranzacional a bazei de date desfurat de la cel mai recent punct de verificare pn la cderea sistemului. Restaurarea rapid a bazei de date va necesita deci o frecven mare a punctelor de verificare. Un punct de verificare presupune executarea urmtoarelor operaii: - nghearea proceselor active la momentul respectiv; - forarea scrierii paginilor de memorie n jurnale i apoi n baza de date; - scrierea unei nregistrri speciale n jurnalul tranzaciilor, necesar la restaurare i reluarea prelucrrilor, care indic: -starea fiecrui proces activ din momentul executrii punctului de verificare; - starea fiierelor temporare de lucru; - poziiile n fiierele secveniale; - pointeri la cozile de mesaje; - continuarea proceselor anterior ngheate. La nivelul SGBD pot exista parametrii de configurare care s influeneze procesul de restaurare automat. Pentru SQL - Server de exemplu, acetia sunt: 1. Intervalul de restaurare - reprezint timpul maxim admis pentru efectuarea restaurrii automate n momentul ncrcrii sistemului. Valoarea acestui parametru este folosit de SGBD n calculul frecvenei de executare a punctelor de verificare, calcul realizat pe baza unui algoritm special. Valoarea implicit a intervalului de restaurare este de 5 minute, ea putnd fi modificat n limitele intervalului 1 - 32767 minute. 2. Indicatorul de restaurare - determin ce informaii va scrie SGBD n fiierul de erori (error log file) n timpul restaurrii automate. Valoarea implicit este 0, n acest caz informaiile rezumndu-se la device-ul folosit, baza de date ce este supus procesului de restaurare, numrul tranzaciilor derulate nainte i a celor derulate napoi. Parametrul poate fi setat pe valoarea 1, i astfel informaiile vor include detalii despre modul n care este tratat fiecare tranzacie.

20

Ambii parametrii pot fi modificai folosind meniurile unui program utilitar SAF (Server Administration Facility) sau prin apelarea procedurii de sistem SP-configure, ca n exemplul urmtor: Sp_configure " recovery interval", 4 Sp_configure " recovery flag", 1 reconfigure Exemplul realizeaz setarea intervalului de restaurare la 4 minute i ba indicatorului de restaurare la valoarea 1. Comanda de reconfigurare este necesar deoarece setarea indicatorului de restaurare nu are efect dect dup rencrcarea sistemului. Dac se doresc informaii deepre valorile celor 2 parametrii. Pot fi folosite primele dup comenzi n forma: sp_configure "recovery interval" sp_configure "recovery flag" Restaurarea manual a bazei de date Restaurarea manual, denumit astfel pentru c implic intervenie uman i nu pentru c ar fi un proces manual, este necesar n situaia distrugerii suportului de memorie extern pe care rezid baza de date. n anumite SGBD, acest proces se bazeaz doar pe efectuarea de copii de siguran ale bazei de date. Restaurarea va consta n ncrcarea celei mai recente copii a bazei de date i reluarea prelucrrilor efectuate din momentul copierii pn la producerea defeciunii. Pentru realizarea acestor copii se poate recurge la una din urmtoarei modaliti: 1. Cea mai simpl i mai utilizat necesit deconectarea tuturor utilizatorilor de la baza de date, efectuarea copiei, dup care utilizatorilor le este permis reconectarea la baza de date i reluarea lucrului. 2. Mai eficient, dar necesitnd un cost de implementare mai mare, este efectuarea copiilor n mod dinamic, n timp ce utilizatorii acceseaz baza de date. Aceast facilitate este util n regim de lucru on-line, realizarea copiei fiind transparent pentru utilizatori. O astfel de copie a bazei de date determina executarea automat a unui punct de verificare. Copia va reflecta starea bazei date din momentul respectiv, inclusiv efectele tranzaciilor n curs de execuie. SGBD va realiza automat derularea napoi a acestor tranzacii n procesul ncrcrii bazei de date, obinndu-se astfel o stare consistent a acesteia. Timpul consumat de o operaie de copiere, dependent de mrimea bazei de date ca i de metoda de copiere utilizat (la nivelul logic sau la nivel fizic), determin stabilirea frecvenei de realizare a copiilor, care are implicaii asupra duratei procesului de restaurare. Astfel, cu ct copia bazei de date de care dispunem va fi mai recent, cu att restaurarea va fi mai rapid. Restaurarea manual poate fi facilitat dac, pe lng copii de siguran ale bazei de date, SGBD permite i efectuarea de copii ale fiierului jurnal, durnta de realizare a acestora fiind redus. Acestea se efectueaz dinamic i incremental (nu vor conine informaii redundante). n intervalul dintre dou copieri ale bazei de date se vor realiza mai multe copii ale fiierului jurnal, fiecare dintru aceste reprezentnd, din punct de vedere al informaiilor coninute, o continuare a cel anterioare. Efectuarea unei astfel de copii presupune execuia automat a unui punct de verificare, deci sincronizarea memoriei cu fiierul jurnal i cu baza de date. Tranzaciile inactive din jurnal (cele pentru care s-a executat COMMIT TRANSATION naintea punctului de verificare, deci sunt reflectate n baza de date) vor fi terse din fiier. Procesul de restaurare va presupune ncrcarea celei mai recente copii a bazei de date, urmat de ncrcarea copiilor jurnalului n ordinea n care au fost efectuate i actualizarea bazei de date pe baza acestora. Restaurarea va avea ca efect recrearea bazei de date din momentul reflectat de informaiile din ultima copie a jurnalului tranzaciilor. 21

Exemplificnd pentru SQL - Server, SGBD cu faciliti puternice pentru restaurarea bazelor de date, procesul de restaurare manual va consta n (fig. 10.6.): t0
DUMP DATABASE

t1

t2

t3

t4

t5 timp

DUMP DUMP TRANSACTION TRANSACTION

LOAD DATABASE LOAD TRANSACTION A LOAD TRANSACTION B

Fig. 10.6 Restaurarea manual a bazei de date 1. Realizarea de copii de siguran - efectuarea unei copii dinamice a bazei de date, prin comandDUMP DATABASE baza TO dumpdev(momentul t0) - efectuarea de copii ale jurnalului tranzaciilor DUMP TRANSACTION baza TO discdumpa(momentul t1) DUMP TRANSACTION baza TO discdumpb(momentul t2) 2. Restaurarea bazei de date pe baza copiilor anterioare n urma incidentului de la momentul t3 (presupunem c un nou disc a fost instalat i s-a alocat spaiu pentru baza de date) - ncrcarea copiei bazei de date LOAD DATABASE baza FROM dumpdev - ncrcarea copiilor jurnalelor tranzaciilor n ordinea n care au fost executate: LOAD TRANSACTION baza FROM discdumpa LOAD TRANSACTION baza FROM disdumpb 10.2. Securitatea bazei de date n general prin securitate a datelor se nelege acea funcie a unui SGBD prin care se asigur protecia datelor mpotriva unui acces neautorizat. Exist dou faete ale conceptului de securitate a datelor: protecia datelor i controlul autorizrii. Protecia datelor se realizeaz pentru a nu permite utilizatorilor neautorizai s neleag coninutul fizic al datelor sau pentru a preveni distrugerea voit a datelor. Protecia fiierelor simple se poate realiza prin facilitile oferite de sistemul de operare cu care se lucreaz sau prin diferite tehnici de protejare a informaiilor n reelele de calculatoare. Astfel, n sistemul de operare UNIX administratorul de sistem atribuie drepturi asupra fiierelor: dreptul de citire(deci de a vedea un fiier), dreptul de scriere (deci de a modifica fiierul) i dreptul de execuie. Cea mai simpl metod prin care se poate realiza protecia datelor este criptarea acestora. Aceast tehnic este utilizat att pentru fiierele stocate pe disc ct i pentru transmiterea n reea a informaiilor. Decriptarea datelor se poate realiza numai de ctre utilizatorii autorizai, adic acei utilizatori care cunosc codul utilizat. Exist dou scheme principale pentru criptare: Data Encryption Standard i schema de criptare cu cheie public. Controlul autorizrii trebuie s garanteze c numai utilizatorii autorizai pot realiza operaii asupra bazelor de date. Fie c este vorba de un SGBD centralizat sau un SGBDD, acestea trebuie s fie capabile s asigure accesul la o parte a bazelor de date numai pentru o parte a utilizatorilor. Controlul autorizrii se poate realiza prin intermediul sistemelor de operare i astfel obinem un control centralizat. Controlul autorizrii n sistemele de baze de date difer prin cteva aspecte de controlul tradiional pentru sistemele de fiiere. Astfel, n cazul sistemelor de baze de date trebuie s se asigure drepturi diferite de accesare a acelorai obiecte de ctre diferii utilizatori. Este posibil ca pentru anumite obiecte unii utilizatori s aib anumite drepturi, iar ali utilizatori s aib alte drepturi asupra acelorai obiecte. 22

n ceea ce privete controlul autorizrii trebuie s facem distincie ntre controlul asigurat n sistemele centralizate pe de o parte i pe de alt parte controlul asigurat n sistemele distribuite. a) Controlul autorizrii centralizate Urmtoarele trei entiti sunt implicate n controlul autorizrii: Utilizatorii, care sunt interesai n execuia programelor Operaiile implicate n programele de aplicaii Obiectele bazei de date asupra crora se execut operaiile. Fiind dat un triplet (utilizator, operaie, obiect), controlul autorizrii se poate enuna ca fiind funcia sistemului prin care se verific dac utilizatorul are voie (deci este autorizat) s execute operaia asupra obiectului. Introducerea unui utilizator n sistem se realizeaz n principal prin specificarea perechii (nume_utilizator, parol). n mod unic nume_utilizator identific un utilizator al sistemului, iar parola autentific utilizatorul. Pe de alt parte parola, cunoscut numai de utilizatorul respectiv, mpiedic intrarea n sistem a unui intrus. Granularitatea proteciei asigurat de un sistem de gestiune a bazelor de date este mai fin dect a sistemelor bazate pe fiiere. La acestea din urm, granula de protecie este fiierul. ntr-un SGBD mecanismul de vizualizare a obiectelor permite protecia chiar prin ascunderea unora dintre acestea. Astfel putem avea atribute, tupluri sau relaii hiden (ascunse) i care nu pot fi vizualizate de utilizatorii neautorizai. Un drept exprim o relaie dintre un utilizator i un obiect pentru o mulime precizat de operaii. ntr-un SGBD relaional bazat pe un SQL, o operaie este desemnat printr-o instruciune (de exemplu SELECTE, INSERT, UPDATE sau DELETE), iar drepturile sunt acordate sau revocate prin instruciuni de forma: GRANT < tip operaie> ON <obiect > TO < utilizator> REVOKE <tip operaie> FROM <obiect> TO < utilizator> sau alte variante n care se pot acorda/revoca mai multe tipuri de operaii pentru unul sau mai muli utilizatori. Cuvntul cheie public se utilizeaz pentru a desemna toi utilizatorii. Controlul autorizrii ridic urmtoarea problem: cine acord/revoc drepturile utilizatorilor? n controlul centralizat rspunsul este urmtorul: un singur utilizator, o clas de utilizatori sau administratorii bazei de date. Ei sunt aceia care au toate privilegiile asupra obiectelor bazei de date i ei sunt singurii care pot utiliza instruciunile GRANT i REVOKE. ntr-un sistem descentralizat problema aceasta este mai complex. n asemenea sisteme cel care creaz un obiect devine proprietarul acestuia i n consecin, are toate privilegiile de a acorda sau revoca drepturile asupra obiectului respectiv. Persoana care primete dreptul asupra obiectului are la rndul ei posibilitatea de a acorda acest drept altor persoane. Aceast procedur se generalizeaz i prin urmare aceste persoane pot acorda drepturi altor persoane .a.m.d. Problema care apare este aceea n cazul revocrii drepturilor. Dac persoana A acord dreptul persoanei B asupra efecturii unor operaiuni asupra obiectului O, iar B acord mai departe aceste drepturi persoanei C i A revoc dreptul lui B atunci automat i C pierde dreptul respectiv. De aceea, pentru a executa instruciunea REVOKE, sistemul de gestiune va trebui s memoreze ierarhia acordrii drepturilor, iar creatorul obiectului se afl n rdcina acestei ierarhii. Privilegiile acordate utilizatorilor sunt nregistrate ntr-un catalog sau director al regulilor de autorizare. Exist mai multe moduri de a defini aceste cataloage. Cel mai simplu este s specificm toate privilegiile ntr-o matrice a autorizrilor. O linie a acestei matrice definete utilizatorul, o coloan definete obiectul, iar elementul matricei de pe linia i coloana respectiv definete operaia autorizat. Operaia autorizat se specific prin tipul operaiei (de exemplu, SELECT, DELETE etc). Uneori alturi de tipul operaiei se precizeaz

23

un predicat care aduce anumite restricii cu privire la accesul la informaie. Ca exemplu s considerm urmtoarea matrice a autorizrilor: Petre Ana George ANG UPDATE NONE SELECT ASIG NONE SELECT WHERE RESP =Manager UPDATE

Din aceast matrice aflm c Petre are dreptul de a executa operaiuni de actualizare n relaia ANG, iar Ana are dreptul de a executa operaia SELECT n relaia ASIG numai pentru acele tupluri pentru care atributul RESP are valoarea Manager. Exist mai multe puncte de vedere cu privire la memorarea unei matrice a autorizrilor. Considerm c cel mai natural mod este acela prin care memorarea se face prin intermediul unei relaii ternare de forma ( nume_persoan, obiect, drept). b) Controlul autorizrii distribuite Problemele legate de controlul autorizrii ntr-un sistem distribuit rezid din faptul c entitile (obiectele, relaiile etc) sunt distribuite. Aceste probleme se refer la autentificarea utilizatorului la distan, gestiunea regulilor de autorizare distribuit i tratarea vizualizrilor i grupurilor de utilizatori. Autentificarea utilizatorilor la distan este necesar deoarece orice nod al unui sistem de gestiune a bazelor distribuite poate accepta programe iniiate n alt nod i autorizate n noduri aflate la distan. Pentru a preveni accesul unor utilizatori neautorizai, utilizatorul trebuie s fie identificat i autentificat de asemenea n nodul accesat. Sunt posibile dou soluii: Numele utilizatorului i parola acestuia trebuie s se gseasc memorate n toate nodurile din catalogul global Toate nodurile se identific pe ele nsele; n acest fel un utilizator autorizat de un nod n1 identificat de un nod n2 va fi autorizat de nodul n2. Regulile de autorizare distribuit sunt enunate la fel ca n cazul autorizrii centralizate. Aceste reguli se memoreaz n catalog i pot fi duplicate pe fiecare nod sau numai pe acel nod care proceseaz obiectele distribuite solicitate. O vizualizare a unor obiecte poate fi considerat de asemenea un obiect compus din toate obiectele respective. Prin urmare acordarea drepturilor asupra unei vizualizri se reduce la acordarea drepturilor asupra obiectelor componente. Aici o soluie poate fi legat de acordarea drepturilor de citire de ctre proprietarul obiectelor, aa cum s-a vzut mai nainte. Administrarea unei baze de date se poate simplifica dac utilizatorii sunt grupai n grupe de utilizatori. De obicei toi utilizatorii unei baze formeaz o clas numit public. Acest concept se utilizeaz att ntr-un SGBD centralizat ct i n unul distribuit. ns n cazul distribuit apare un nivel suplimentar care specific clasa public pentru un nod particular. Clasa public, chiar i pentru un nod particular formeaz un grup de utilizatori. Desigur se pot defini i alte grupe de utilizatori prin comenzi specifice.

24

BAZE DE DATE CURS 11 BAZE DE DATE ORIENTATE PE OBIECTE 11.1 Obiective, domenii de aplicare 11.2 Modelul de date orientat pe obiecte Concepte de baz Operatorii modelului de date orientat pe obiecte 11.3 Baze de date orientate pe obiecte Conceptul de baz de date orientat pe obiecte Proiectarea bazei de date orientat pe obiecte 11.4 Sisteme de gestiune a bazelor de date orientate pe obiecte Definiie. Caracteristici. Arhitecturi si limbaje pentru SGBD-OO 11.1 Obiective, domenii de aplicare. Aplicaiile din domeniile proiectrii asistate de calculator, a sistemelor informatice geografice i a sistemelor bazate pe cunotine, presupun stocarea unor cantiti mari de informaii cu o structur complex. Aceste aplicaii necesit suport pentru tipurile de date care nu pot fi reprezentate n sistemele clasice. De exemplu, baza de date a unui sistem de proiectare n domeniul ingineriei necesit stocarea unor cantiti mari de date sub form de diagrame i descrieri ale proiectului tehnic. De asemenea, aplicaiile de proiectare asistat de calculator pot solicita monitorizarea unor desene formate din grupuri de elemente complexe ce trebuie s fie combinate, separate, suprapuse i modificate astfel nct s permit rularea unor programe variate de proiectare. Orientarea spre multimedia aduce elemente noi n lumea informaticii. Grafica, imaginea fotografic, video, sunetul nu pot fi tratate n aceeai manier cu structurile tabelare de denumiri i numere. Recent, conceptele de obiect au fost nglobate i n tehnologia SGBD-urilor, rezultnd producia de sisteme de gestiune a bazelor de date orientate pe obiecte (SGBD-OO). Enumerm doar cteva din domeniile care se preteaz n mod deosebit la o tratare orientat pe obiecte: - proiectare CAD (Computer- Aided Design), CAM (Computer-Aided Manufacturing), CAE (Computer-Aided Engineering), CASE (Computer-Aided Software Engineering); - simulare i modelare; - sisteme informaionale spaiale: GIS (Geographic Information System); - administrarea documentelor: automatizarea muncii de birou, CAP (Computer-Aided Publishig), munca n echip; - multimedia: imagine, video, audio; - ingineria cunoaterii: baze de cunotine, sisteme expert. Obiectivele principale ale sistemelor de gestiune orientate pe obiecte sunt: 1. Puterea de modelare superioar a datelor. Aceasta se realizeaz prin: -deschiderea ctre noi aplicaii: CAO, FAO, cartografie, gestiune de documente, birotic; -facilitarea sarcinilor de concepie: economie n expresie, posibilitatea de generalizare i agregare a relaiilor, flexibilitate n modelare; -evoluie ctre multimedia (sunet, imagini, texte); 2. Posibiliti de deducie superioar (ierarhie de clase, motenire); 3. Ameliorarea interfeei cu utilizatorul; 25

4. Luarea n considerare a aspectelor dinamice, integrarea descrierii structurale i comportamentale. 11.2 Modelul de date orientat pe obiecte Concepte de baz Un model de date orientat pe obiecte are la baz noiunea de entitate conceptual i definete un obiect ca o colecie de proprieti care descriu entitatea. Principalele concepte care sta la baza unui model orientat pe obiecte sunt: obiectul, ncapsularea, persistena, clasa, tipul, motenirea, polimorfismul, identitatea, domeniul. Obiectele sunt abstractizri ale entitilor lumii reale i se caracterizeaz prin stare i comportament. Starea unui obiect este exprimat prin valorile atributelor sale. Colecia de atribute ales pentru un obiect trebuie s fie suficient pentru a descrie entitatea, adic trebuie s includ acele atribute pe care utilizatorii trebuie s le cunoasc. Comportamentul unui obiect reprezint un set de metode sau operaii care acioneaz asupra atributelor sale. Fiecare obiect are asociat un nume care coincide, de obicei, cu numele entitii reprezentate. Exemple de obiecte: un numr ntreg, un avion, un angajat, un sindicat. Exemplul 11.1 S considerm obiectul avion. Atributele unui avion pot fi direcia, altitudinea, viteza la sol (dac este n micare), greutatea i culoarea. Operaiile unui avion pot fi abilitatea de micare, viteza modificabil i riposta la stimuli, cum ar fi vntul sau temperatura exterioar. Obiectul AVION poate avea atribute pentru AVION-ALTITUDINE, AVION-DIRECIE, AVION-VITEZ, AVION-POZIIE, i AVION-CONSUM DE COMBUSTIBIL. AVION poate avea de asemenea definite proceduri care s ilustreze operaiile sale: SETARE_ALTITUDINE, PREZENTARE_DIRECIE, CALCUL_VITEZ, PREZENTARE_VITEZ, CALCUL_CONSUM DE COMBUSTIBIL etc. n general, pot fi identificate trei tipuri de obiecte: obiecte elementare: ntreg, boolean, ir de caractere, etc; obiecte compuse: nume, adres; obiecte complexe: avion, angajat. Un obiect nglobeaz urmtoarele elemente: structura de date; specificarea operaiilor; implementarea operaiilor. Structura unui obiect i operaiile (metodele) permise pentru acel obiect sunt definite mpreun. O metod reprezint un program ce manipuleaz obiectul sau indic starea sa. Metoda este ntotdeauna asociat unei clase. Specificarea metodei poart numele de semntur iar modul de implementare constituie corpul metodei. Secvena de program care implementeaz metoda poate fi compilat n orice moment al dezvoltrii aplicaiei, fr ca nici o alt recompilare s fie necesar. Metodele i atributele nu sunt vizibile din exteriorul obiectului. Astfel, un obiect are o implementare care este privat i o interfa care este public i poate fi vzut de utilizatori i de alte obiecte. Implementarea poate fi modificat fr a modifica interfaa. Un obiect rspunde la mesaje. Mesajele reprezint cereri adresate obiectului pentru a returna o valoare sau pentru a-i schimba starea. Ele constituie interfaa obiectului cu mediul. Un mesaj indic unul sau mai multe obiecte i o metod ce se aplic acestora. Mesajele cuprind: numele mesajului, numele obiectului pentru care au fost transmise i argumentele necesare, dac exist. Cnd un obiect primete un mesaj, una din procedurile sale

26

este apelat. Procedura realizeaz apoi o operaie care poate returna un rezultat. Mesajele sunt implementate prin intermediul metodelor. Pentru a vedea cum opereaz aceste elemente n Exemplul 11.1, un program simulnd zborul avioanelor poate modela efectul vntului asupra avionului prin trimiterea unui mesaj CALCULUL VITEZEI unui obiect AVION. Acest mesaj ar include argumente privind direcia i viteza vntului. Metoda CALCUL VITEZ pentru obiectul AVION este apelat i o nou vitez i direcie sunt calculate. Variabilele corespunztoare sunt actualizate, aceasta modificnd starea intern a obiectului. Obiectele pot fi compuse din alte obiecte. Obiecte compuse sau obiecte complexe sunt printre cele mai recente descoperiri n domeniul tehnologiei obiect. Un obiect compus este realizat din alte obiecte. Astfel, atributele unui obiect pot fi ele nsele obiecte. Un obiect compus are deci o structur ierarhic. De exemplu, un obiect AVION poate fi definit ca un obiect compus, coninnd pri separate ca MOTOR_JET, FUZELAJ, CABINA_PILOT etc. Fiecare parte component este un obiect i o instan a unei clase. Procesul poate fi extins pentru a realiza o ierarhie de pri, ilustrat n Figura 11.1. AVION FUSELAJ MOTOR_JET CABINA PILOT SCAUN PILOT

BORD COMENZI Figura 11.1 Ierarhie de pri

Componentele individuale se consider a fi ntr-o relaie de este parte din cu obiectul compus. De exemplu, BORD_COMENZI i SCAUN_PILOT sunt ntr-o relaie de este parte din cu CABINA_PILOT. Structura obiectului i modul de aciune al metodelor sale nu pot fi accesate i actualizate direct de ctre un agent extern, dar pot fi modificate indirect prin intermediul mesajelor. Aceast caracteristic ascuns a strii obiectului este cunoscut sub numele de ncapsulare. Un obiect este astfel divizat n dou pri: o parte de interfaa reprezentat de mesaje i o parte ascuns de implementare, reprezentat de starea intern i de metodele obiectului. Interfaa permite unui agent din exterior s solicite obiectului executarea unei aciuni trimind un mesaj corespunztor metodei asociate aciunii. Obiectele pot fi de asemenea considerate ca fiind date abstracte. Data abstract este o tehnic folosit n multe limbaje de programare n care operaiile i reprezentarea intern a unei entiti calculabile sunt parial ascunse din punct de vedere extern. Abstracia permite vizualizarea rezultatelor entitii calculabile dar ascunde modul prin care s-a efectuat calculul. Revenind la Exemplul 11.1, cnd obiectul AVION primete mesajul CALCUL_VITEZ, detaliile metodei de realizare a calculului i actualizrile strii interne a obiectului nu sunt vizibile. Oricum, noua vitez i direcie ale obiectului AVION pot fi obinute folosind protocolul obiectului, prin trimiterea mesajelor PREZENTARE_VITEZ i PREZENTARE_DIRECIE care fac ca valorile variabilelor AVION_VITEZ i AVION_DIRECIE s fie returnate. ncapsularea ascunde utilizatorului complexitatea unui obiect, oferindu-i n schimb o imagine funcional simplificat a acestuia, imagine care-i permite s modeleze i s rezolve cu mai mult uurin probleme complexe.

27

Proprietatea datelor sau a obiectelor de a avea o existena mai ndelungat dect procesul care le-a creat, se numete persisten. Este proprietatea prin care starea bazei de date asigur execuia unui proces pentru a fi refolosit ulterior n alt proces. Codul aferent metodelor-fcnd parte integrant din obiect- este stocat, ca i starea obiectului, n baza de date. Aceasta nseamn c, odat ce a fost descris, o metod devine permanent simplificnd astfel aplicaia i asigurndu-i independena fa da date. O modificare adus unei metode devine imediat operant i persist pn la o nou modificare. Obiectele care au acelai fel de atribute i comportament pot fi clasificate ca fcnd parte din acelai tip sau clas. n raport cu aceast caracteristic, exist dou categorii de sisteme orientate pe obiecte: 1. Cele care admit ca noiune de baz clasa, cum sunt: Smalltalk, Gemstone, Vision, Orion, G-Base; 2. Cele care admit ca noiune de baz tipul, precum: C + + , Simula, Vbase, O2. ntr-un sistem orientat pe obiecte, tipul sintetizeaz elementele comune ale unei mulimi de obiecte cu aceleai caracteristici. Corespunde noiunii de tip abstract de date i are dou componente: interfaa i implementarea. Pentru utilizator numai partea de interfa este vizibil, cea de implementare fiind obiectul activitii proiectantului. Interfaa const dintr-o list de operaii, n timp ce implementarea presupune dou activiti: - descrierea structurii interne a datelor obiectului; - realizarea procedurilor de implementare a operaiilor interfeei. Fie A un univers al atributelor i T o mulime de tipuri predefinite: integer, real, boolean, char, string etc. Un tip este construit recursiv, astfel: - orice element al mulimii T este un tip atomic (sau elementar); - dac t1, t2, ..., tn sunt tipuri de dat i a1, a2, ..., an o mulime de atribute din A, atunci t=[a1:t1, a2:t2, ..., an:tn] este un tip de dat tuplu; - dac t1 este un tip de dat, atunci: t= {t1}este un tip de dat mulime; - dac t1 este un tip de dat, atunci: t = (t1) este tip de dat list; - orice tip de date se poate obine prin aplicarea repetat a regulilor de mai sus. Vom exemplifica modul de declarare i implementare a operaiilor pentru aceste tipuri prin intermediul produsului O2 implementat n C + + . Declararea unui tuplu: type persoana: tuple (varsta: integer, nume : string, co_leg : persoana, copii : set (Persoana), oras : tuple (nume: string, cod: integer)) Declararea unei clase: class Populaie type list (tuple (nume : string, familie: set (Persoana))) Noiunea de clas dei are aceeai specificaie cu cea de tip, este diferit de aceasta, fiind legat mai mult de faza de execuie. Presupune dou aspecte: - generarea de obiecte (prin operaia new aplicat unei clase); - stocarea setului de obiecte care reprezint instanele clasei.

28

O clas are o descriere ce const dintr-un set de structuri de date comune, cunoscute ca variabile de instan, un protocol comun ce const dintr-un set de mesaje, la care instanele clasei vor rspunde i un set de metode pentru implementarea de operaii comune. Clasele sunt de asemenea referite uneori ca tip de dat abstract. Descrierea clasei servete ca ablon dup care vor fi create noile obiecte. O clas este deci un tip abstract de date care definete att structura obiectelor din clasa respectiv, ct i mulimea metodelor pentru aceste obiecte. Ca urmare, obiectele din aceeai clas au aceleai atribute i aceleai metode i rspund la acelai mesaj. Din aceast cauz putem spune c metodele aparin claselor i nu obiectelor n sine. Din punct de vedere al bazelor de date, o clas poate fi considerat ca un tip nregistrare constnd din metadata care asigur ntreaga informaie necesar pentru a construi i a folosi un anume obiect. Similar, e posibil de a considera instanele unei clase ca fiind nregistrri stocate ntr-un fiier. Noi nregistrri avnd diferite valori pot fi adugate n fiier. ntr-o baz da date orientat pe obiecte, clasele sunt aranjate ntr-o ierarhie n care fiecare clas motenete toate atributele i metodele superclasei din care face parte. Motenirea este un concept puternic care conduce la posibilitatea de reutilizare a unor secvene de program, i deci la creterea semnificativ a productivitii n proiectare. Deoarece unele obiecte sunt tipuri specifice, particulare, a altor obiecte, se pot realiza definiri de clas n care o clas specific poate mpri sau mprumuta o parte din descrierea unei clase mai generale. Mecanismul de realizare a definirii unei clase n care deriv variabile de instan i metode din alt definire de clas se numete motenire. Cnd o clas motenete variabile de instan i metode din alt clas, este considerat a fi o subclas. Clasa de la care variabilele de instan i metodele sunt motenite este supraclas. Conceptele de subclas i supraclas sunt analoge conceptelor de generalizare i specializare familiare metodologiilor de modelare a datelor. n Exemplul 11.1, AVION_PASAGERI i AVION_DE_MARF pot fi tipuri specializate ale AVION. Un AVION_DE_PASAGERI poate avea toate atributele i mare parte din comportamentul su derivate din AVION. Dar poate avea i atribute n plus, cum ar fi numrul de pasageri. AVION_DE_PASAGERI poate avea de asemenea un comportament specific diferit de AVION, determinat de restricii cum ar fi rata maxim de aterizare. AVION_DE_PASAGERI poate fi definit astfel, ca o subclas a obiectului AVION, motenind toate varibilele de instan din definirea clasei AVION, dar are i una proprie: NUMR_DE_PASAGERI. Toate instanele obiectului AVION_DE_PASAGERI vor avea variabilele de instan ale obiectului AVION dar vor avea, de asemenea, i NUMR_DE_PASAGERI. Exemplu de implementare a motenirii n sistemul O2: class Avion_de_pasageri type tuple ( numr : ntreg, plecare : Data, sosire : Data ) method public calc_tarif : real end; class Avion_tip_linie inherit Avion_tip_navet type tuple ( coef : real ) method public calc_tarif : real, public afis_coef end; Pentru clasa Avion_tip_linie metoda calc_tarif va fi redefinit deoarece tariful va include n acest caz o supratax. Formal noiunea de motenire se poate defini astfel. 29

Considerm o mulime T de tipuri de dat i o mulime A de atribute. Vom defini n mod recursiv relaia de ordine () pe mulimea tipurilor de dat, numit relaie de motenire sau relaie de subtipaj: dac t1, t2 sunt tipuri de dat atomice, iar a1 i a2 sunt atribute din A, atunci: - [a1: t1, a2: t2] [a1: t1]; - {t 1 , t 2 } {t 1 }; - (t1, t2) (t1). dac t1, t2 sunt tipuri de dat i a un atribut, atunci: [a : t1] [a : t2], dac t1 t2; dac t1 i t2 sunt tipuri de dat, atunci: {t1} {t2}, dac t1 t2; dac t1 i t2 sunt tipuri de dat, atunci (t1) (t2), dac t1 t2. Pe baza motenirii, pot fi create ierarhii de clase care reflect relaiile naturale regsite n domeniile lumii reale (Figura 11.2). AVION AVION DE MARF AVION DE PASAGERI AVION DE LINIE

AVION TIP NAVET

Figura 11.2 Ierarhie de clas Este de asemenea posibil ca o clas s aib mai mult dect o supraclas. Acesta este cunoscut ca motenire multipl. Pentru SGBD-OO noiunea de motenire este esenial. Ea poate fi simpl sau multipl. Dac avem n vedere doar relaia de motenire simpl, modelarea complex nu este posibil. De exemplu, o Persoan poate fi Student sau Salariat dar ntlnim i cazul StudentSalariat. Polimorfismul se refer la faptul c, la primirea unui mesaj, stabilirea metodei care se aplic se face n mod dinamic, n funcie de clasa obiectului n cauz. Astfel, instane ale unor clase diferite pot fi adresate uniform (primesc aceleai mesaje), dar manifest comportamente diferite. Acest fapt asigur manipularea simpl i coerent a seturilor eterogene de obiecte. Un alt tip de comportament polimorfic este asociat cu motenirea. Rspunsul unui obiect la un mesaj poate fi determinat de metodele motenite de la supraclas. Motenirea multipl permite definirea unor forme complexe de comportament polimorfic care pot antrena uneori combinarea metodelor de la dou sau mai multe supraclase. Identitatea este un mijloc de a distinge un obiect de altul. Prin identitate se asigur i persistena datelor. Oricare din obiectele unei baze de date orientate pe obiecte are identitate care este independent de valorile atributelor sale. Spre deosebire de modelul relaional, care utilizeaz unicitatea cheii primare pentru a identifica obiectul, tehnologia orientat pe obiecte permite modificarea valorilor oricrui atribut fr a-i afecta identitatea. Mai mult chiar, obiectele au contiina de sine, i anume pointerul Self, prin intermediul cruia obiectele se pot referi la ele nsele. Fiecare instan sau realizare a obiectului are un identificator de obiect intern, repartizat lui i cunoscut ca un ID obiect sau pointer. Acesta este independent de valorile atributelor sale. Fiind generat de sistem, identificatorul este unic i nu este accesibil utilizatorului. Deci, pot exista multe obiecte tip AVION, fiecare cu un ID obiect unic. Operatorii modelului de date orientat pe obiecte 30

Operaiile acestui model pot fi grupate astfel: - obiectele comunic ntre ele prin mesaje. Transmiterea i respectiv primirea de mesaje st la baza operaiilor modelului orientat pe obiecte; - un mesaj poate fi trimis instanelor mai multor clase. Comportamentul polimorfic presupune selectarea metodei adecvate definit pentru clasa obiectului respectiv sau pentru o superclas; - metodele pot fi definite, terse sau modificate; - clasele pot fi definite i actualizate prin operaii de creare, tergere i modificare; - instana unei clase poate fi actualizat prin metode ce modific valorile variabilelor propriei instane, aceasta modificnd starea intern a obiectului; ntr-o serie de implementri, definirile de clas sunt ele nsele obiecte, numite obiecte clas. Obiectele clas sunt instane ale unei clase generice sau ale unei supraclase. Deci, operaiile de creare, modificare i tergere a definirilor de clas pot fi implementate ca mesaje. Definiia 11.1 O baz de date este o mulime finit de clase B = {C1, C2, ..., Cn}, unde Ci este o mulime finit de obiecte Oi = {Oi1, Oi2, ..., Oim} de tip tI ce are o mulime Mi de metode, i {1, 2, ..., n}. Invocarea unei medode a clasei C i B se realizeaz printr-o funcie mi: Ci Ci, numit mesaj. Mulimea mesajelor m = {m1, m2, . . . , mp} care pot fi adresate clasei Ci se va numi protocol de mesaje. Clasele de obiecte sunt deci colecii de obiecte care respect un protocol comun de mesaje. Pentru exemplificarea operaiilor care vor fi definite, vom considera trei clase ale unei baze de date i anume: a) clasa Profesor, conine informaii despre profesori: curs_predat {Curs} nume string prenume string matricol integer b) clasa Student, conine informaii despre studeni: curs_luat {Curs} nume string prenume string matricol integer c) clasa Curs, conine informaii despre cursurile predate/luate: nume_curs string studeni {Student} profesori {Profesor} cu urmtoarele referine: studeni Referin ctre clasa Student. profesori Referin ctre clasa Profesor. Curs_luat Referin ctre clasa Curs. ntr-o baz de date orientat obiect se pot crea clase noi de obiecte care vor face referi la obiectele originale, i care vor filtra mesajele ctre obiectelor originale. mesaj extern protocol membri obiect original

Figura 11.3 O instan a unei CV

31

Prin aplicarea operaiilor algebrice se vor obine clase virtuale (CV) de obiecte, ale crei componente sunt obiecte ale claselor existente care sunt vzute mpreun deoarece posed aceleai caracteristici i recunosc aceleai mulimi de mesaje. O instan a clasei CV va conine dou variabile, indicate n Figura 11.3. Dac prin aplicarea unei operaii algebrice se creaz o clas CV, variabila membri reprezint lista obiectelor referite, iar variabila protocol reprezint mulimea mesajelor. Tabelul urmtor prezint notaiile utilizate n definirea formal a operaiilor. s, r S, R M S, M R M CV (s) CV (s, r) c CO Reprezint identificatori de obiecte Reprezint mulimi de obiecte din aceeai clas Protocoale de mesaje partajate de mulimile R i S o mulime a mesajelor o reprezentare pentru s, adic CV.membri conine s o reprezentare pentru s i r, adic CV.membri conine s i r o condiie clas de obiecte

n continuare vom defini principalele operaii ale algebrei relaionale, importante i pentru o baz de date orientat obiect:. 1. Selecia: (condiie) CO. Rezultatul acestei operaii este o submulime de obiecte din CO care satisfac condiia dat. Dac operaia se termin cu succes, mesajele din condiie trebuie s fie nelese de obiectele din CO. O definiie formal a seleciei este urmtoarea: (R, p) = {s s S p (s)} De exemplu, (nume = Popa prenume = Ion) studeni are ca rezultat o mulime de obiecte din clasa Student pentru care rspunsul la mesajul nume este Popa i rspunsul la mesajul prenume este Ion. Aceast operaie returneaz mulimea studenilor cu numele Popa i prenumele Ion. 2. Proiecia: (list_de_mesaje) CO. Rezultatul acestei operaii este o submulime a obiectelor clasei CV, cte un obiect pentru fiecare membru al mulimii CO. Obiectele din clasa CV neleg mesajele coninute n list_de_mesaje care trebuie s fie o submulime a mesajelor nelese de obiectele din CO. O definiie formal: (S, MS) ={CV(s)s S CV (s).protocol = MS}. De exemplu, (nume) studeni are ca rezultat o mulime a clasei de obiecte CV, unul pentru fiecare membru din clasa Student. Obiectele clasei CV neleg mesajul nume, care trebuie s fie neles de toate obiectele clasei Student. 3. Produs cartezian (): CO1 CO2. Rezultatul acestei operaii este o mulime a clasei de obiecte CV, cte unul pentru fiecare combinaie posibil de obiecte din CO1 i CO2. O definiie formal a acestei operaii este urmtoarea: SR= {CV (s, r) r R s S CV (s, r). protocol = MS MR} De exemplu, cursuri profesori are ca rezultat o mulime a clasei de obiecte CV, n toate combinaiile posibile ntre obiectele clasei Curs i ale clasei Profesor. 4. Reuniunea ( ): CO1 CO2. O definiie formal a acestei operaii este: SR = {tt S t i}

32

De exemplu, ((matricol > 100) studeni) ((nume = Ionescu) studeni) are ca rezultat mulimea studenilor pentru care numrul matricol este mai mare dect 100 sau au numele Ionescu. 5. Diferena ( ): CO1 CO2. Rezultatul acestei operaii este mulimea obiectelor care sunt n CO1 dar nu i n CO2. O definiie formal a acestei operaii este: S-R={tt S (t R)} De exemplu, ((matricol > 100) studeni) ((nume = Ionescu) studeni) are ca rezultat mulimea obiectelor din Student care furnizeaz un rspuns mai mare ca 100 pentru mesajul matricol i nu dau rspunsul egal cu Ionescu la mesajul nume. n continuare vom prezenta cteva operaii care deriv din operaiile de baz i deci se pot exprima cu ajutorul acestora. 6. Intersecia ( ): CO1 CO2. Rezultatul acestei operaii este mulimea obiectelor care sunt att n CO1 ct i n CO2. Pentru testarea apartenenei obiectelor la o anumit clas se utilizeaz identitatea obiect. Mulimile de obiecte trebuie s fie compatibile, iar aceast operaie este comutativ. O definiie formal este: SR= S-(S-R). De exemplu, ((matricol > 100) studeni) ((nume = Ionescu) studeni) are ca rezultat mulimea obiectelor din Student care furnizeaz un rspuns mai mare ca 100 pentru mesajul matricol i rspunsul egal cu Ionescu la mesajul nume. 7. Join: CO1 Join CO 2
conditie

unde condiie are forma: < list_de_mesaje1 operator_de_comparare list_de_mesaje2>. Rezultatul acestei operaii este o mulime de obiecte din clasa CV, fiecare coninnd un obiect din CO1 i un obiect din CO2, unde obiectele dau rspunsuri corespunztoare mesajelor din list_de_mesaje1 i list_de_mesaje2 care ndeplinesc condiiat. Obiectele din clasa CV vor nelege toate mesajele care pot fi nelese de fiecare dintre obiectele din CO1 i CO2. Dac operatorul din condiie este "=", spunem c avem un Join natural. O definiie formal a acestei operaii este: Join (S, R, c) = ( (S, R), c) De exemplu, studeni Join profesori are ca rezultat o mulime a clasei
cursuri _ luate = cursuri _ predate

de obiecte CV, fiecare coninnd un obiect al clasei Student i un obiect al clasei Profesor, i unde ambele obiecte furnizeaz acelai rspuns la mesajele cursuri_luate i respectiv cursuri_predate. 8. Semi-Join (SJ) : CO1 SJ CO 2
conditie

Rezultatul acestei operaii este o mulime de obiecte din clasa CO1 pentru care mesajele din list_de_mesaje1 furnizeaz valori care se compar cu rspunsurile corespunztoare mesajelor din list_de_mesaje2 care vizeaz un obiect din CO2. SJ genereaz o clas de obiecte CV, dar protocolul clasei CV este acelai cu protocolul de mesaje al obiectelor din CO1. O definiie formal este: SJ(S, R, MS,c) = (Join (S, R, c), MS). De exemplu, studeni SJ profesori are ca rezultat o mulime de obiecte din clasa
nume = nume

Profesor pentru care mesajul nume returneaz aceeai valoare cu mesajul nume al unui obiect din Student. 9. Diviziune obiect(Odiv): CO1 (Mesaj) Odiv CO2 Vom da o definiie formal pentru operatorul de diviziune Odiv, care utilizeaz operaia DIVISION preluat din algebra relaional: Odiv (S, R, MS,MR) = SJ(S, DIVISION (S, R, MS, MR), MS, c) 33

De exemplu, Studeni (cursuri_luate) Odiv Cursuri. are ca rezultat o submulime a clasei de obiecte Student, i anume studenii care iau toate cursurile. 11. 3. Baze de date orientate pe obiecte Conceptul de baz de date orientat pe obiecte Baza de date orientat pe obiecte poate fi definit ca rezultatul aplicrii tehnologiei orientate pe obiecte n domeniul stocrii i regsirii informaiilor6. Ea ofer posibilitatea de a reprezenta structuri de date foarte complexe cu ajutorul obiectelor. Definirea clasei este mecanismul de specificare a schemei bazei de date. Schema bazei de date const din toate clasele care au fost definite pentru o aplicaie particular. Definiiile de clas includ motenirea, relaiile de nrudire (superclasa, subclasa) i relaiile structurale dintre clase. O schem complet de baz de date poate consta din una sau mai multe ierarhii de clas mpreun cu relaiile structurale. Descrierile individuale ale schemei se refer la variabilele de instan ale claselor individuale. Schema bazei de date poate fi modificat dinamic, n funcie de necesitiile utilizatorilor. Modificarea schemei presupune: Definirea unei taxonomii i a unui model al modificrilor. Taxonomia definete un set de modificri semnificative ale schemei, iar modelul furnizeaz o baz pentru specificarea semanticilor acestei modificri; Implementarea modificrilor schemei. Pot fi identificate dou tipuri de modificare a schemei unei baze de date orientate pe obiecte: 1. Modificri referitoare la modul de definire al unei clase. Acestea includ schimbrile atributelor i metodelor definite pentru o clas, cum ar fi schimbarea numelui sau domeniului unui atribut, adugarea, tergerea unui atribut sau metode; 2. Modificri referitoare la structura ierarhiei de clase care include adugarea sau tergerea unei clase i schimbarea relaiilor superclasa/subclasa dintre o pereche de clase. Proiectarea bazei de date orientat pe obiecte Modul clasic de proiectare se bazeaz pe tehnica top-down. Se identific mai nti componentele majore, se stabilesc corelaiile ntre ele, iar apoi se trece la rafinri succesive, n cascad, a componentelor. Proiectarea orientat pe obiecte se bazeaz mai mult pe tehnica bottom-up. Se stabilesc mai nti componentele funcionale pe baza crora se va construi apoi ntregul sistem. Se identific n coleciile existente, obiectele care pot fi reutilizate pentru noul proiect. Acestea vor fi preluate ca atare sau, dac este cazul, vor fi ajustate. Cele ce nu exist vor fi create, dar de cele mai multe ori ca subclase ale unor clase existente. Odat creat ierarhia de clase potrivit, se testeaz componentele specifice, se pune la punct documentaia i se poate ncepe aciunea de implementare sau comercializare. Aceast metodologie modific n mod substanial planificarea lucrrilor i etapelor. Partea cea mai minuioas a proiectrii se afl la nceputul proiectului. Dac exist deja biblioteci de obiecte utilizate n alte aplicaii, realizarea unui prototip se poate face ntr-un timp foarte scurt. Pe baza lui se stabilesc aspectele funcionale i de interfa ale aplicaiei, dup care se trece la etapa de identificare a obiectelor, a claselor, a ierarhiei, a modului de comunicare ntre obiecte. Etapa final a proiectului const n asamblarea acestor elemente. Refacerea unor aplicaii clasice n noua tehnologie implic, de cele mai multe ori, refacerea aproape integral a aplicaiilor.

34

Pe de alt patre, metodologia orientat pe obiecte poate fi aplicat cu succes n proiectare chiar dac nu se urmrete utilizarea unor tehnici de realizare orientate pe obiecte. Avantajul const n faptul c aceasta oblig la o analiz mai atent a arhitecturii sistemului i, mai departe, la o proiectare modular, exprimat prin componentele aflate n interaciune. Adugarea sau nlocuirea ulteroiar a unor astfel de componente este mult mai uoar. 11. 4. Sisteme de gestiune a bazelor de date orientate pe obiecte 11.4.1 Definiie. Caracteristici. SGBD-OO conin n plus, fa de facilitile oferite de sistemele tradiionale, structuri i reguli orientate ctre lucrul cu obiecte. Ele includ: - un sistem de date abstracte pentru construirea de noi tipuri de date; - constructori de tip ir, secven, nregistrare, set, reuniune; - funcii, ca tip distinct; - o compunere recursiv a elementelor de mai sus. Principiile ce guverneaz un SGBD-OO sunt urmtoarele7: 1. ntr-un SGBD-OO se utilizeaz funcii ce conin metode i proceduri ale bazei de date cu restricia ca acestea s fie ct mai compacte, ncapsulate, ermetizate. ncapsularea funciilor l ajut pe programatorul de aplicaie s asocieze funciile pe care i le creaz cu coleciile utilizate. De exemplu: ANGAJARE (SALARIAT), SPOR_SAL (SALARIAT). Acest fapt ofer avantaje din punct de vedere al reducerii numrului de accese la informaia stocat n colecii precum i n activitatea de rescriere a procedurilor. A aprut astfel noiunea de opacitate susinut de adepii orientrii pe obiecte i ai folosirii n exclusivitate a funciilor ncapsulate, n opoziie cu cea de transparen promovat de adepii facilitilor limbajelor de interogare. 2. SGBD-OO i n general SGBD-urile din generaia a treia vor subsuma avantajele SGBDlor din a doua generaie. Generaia a doua de SGBD-uri a avut o contribuie pozitiv n dou direcii: Accesul nonprocedural. Existena unui limbaj de interogare prin intermediul cruia s putem interoga baza de date asupra unor atribute ale nregistrrii; Independena datelor. SGBD-urile din generaia a doua menin consistena tuturor cilor de acces la date prin intermediul unui optimizator. n plus exist posibilitatea definirii coleciilor virtuale. Cele dou caracteristici trebuiesc pstrate i n SGBD-urile din generaia a treia. Adepii SGBD-OO propun navigarea ctre informaia dorit prin intermediul unor proceduri de interfa de nivel sczut. De fapt se caut o modalitate de acces la o nregistrare poziionat ntr-o colecie oarecare, problema reducndu-se la un sistem de pointeri ctre identificatorii de obiecte. Practica a demonstrat c acest stil de navigare nu este indicat deoarece nlocuiete funcia de optimizare a evalurii cererilor, cu subrutine scrise de programator. Pot exista dou modaliti de a specifica o colecie: prin enumerarea membrilor si sau utiliznd limbajul de interogare pentru a stabili calitatea de membru. Prima form de stabilire a calitii de membru al unei colecii (metoda extins) are dezavantajul unui efort mare de programare. Avantajul l constituie posibilitatea de aplicare n cazul unor sisteme nestructurate i fr conexiuni ntre seturile de nregistrri. Cea de a doua form (metoda intensiv) este specific pentru seturi i prezint avantajul introducerii automate a unei noi nregistrri n setul corespunztor. Transformrile semantice pot fi executate de optimizator cruia i se las libertatea de decizie asupra cii de acces la informaie, fr a mai fi limitat de structura de pointeri. Modelul orientat pe obiecte utilizeaz prima metod cu toate c a doua este mai performant. 35

3. Un SGBD-OO trebuie s fie deschis ctre alte sisteme. Acest principiu se refer la posibilitatea conexiunii cu limbajele din generaia a patra, cu diferite instrumente de luare a deciziilor, cu sistemele de larg circulaie. Accesul la informaia stocat n baz se va face prin intermediul limbajelor de nivel nalt. Modalitatea universal valabil de interogare va fi un limbaj de tip SQL, iar dialogurile sub forma ntrebare/rspuns ntre utilizator i calculator vor constitui nivelul cel mai sczut de comunicare admis. Un SGBD orientat pe obiecte trebuie, n primul rnd, s satisfac dou criterii: s fie un sistem orientat pe obiecte, deci bazat pe paradigma modelrii orientate pe obiecte; s ndeplineasc cerinele unui sistem de gestiune a bazelor de date. Cele dou criterii genereaz un set de caracteristici sau reguli fundamentale ale modelului orientat pe obiecte. Aceste caracteristici pot fi grupate n trei categorii: obligatorii, opionale i deschise. Manipularea obiectelor complexe. Noiunea de obiect complex a aprut prin aplicarea de constructori asupra obiectelor simple. Este un proces asemntor celui de creare de structuri complexe din entiti simple cum sunt: ntregi, iruri de caractere de orice lungime, variabile de tip boolean. Mulimea minimal de constructori pe care sistemul trebuie s i conin cuprinde: setul, lista, tuplu (nregistrare). Identitatea obiectelor. Este o caracteristic a limbajelor de programare preluat ulterior i de proiectanii de SGBD-uri. Astfel, orice obiect exist independent de valorile atributelor sale, ceea ce conduce la dou relaii posibile: - identitatea a dou obiecte (ele sunt unul i acelai obiect); - egalitatea a dou obiecte (ele au aceeai valoare). Din cele dou relaii deriv noiunile de partajare i modificare a obiectelor. Partajarea obiectelor afirm faptul c dou obiecte pot mpri aceleai componente. n funcie de tipul sistemului cruia i se aplic (cu sau fr identitate) pot aprea interpretri diferite. Considerm de exemplu, nregistrarea de tip persoan cu atributele: nume, vrsta, copii de forma: (Petre, 40, {(Ion, 15 {})}) (Ana, 41, {(Ion, 15, {})}) n realitate pot exista dou situaii concrete descrise de aceste nregistrri: cea n care Petre i Ana sunt prinii aceluiai copil, sau cea n care este vorba de doi copii. ntr-un model ce accept identitatea obiectelor cele dou structuri pot avea sau nu n comun componenta (Ion, 15, {}) n timp ce un model fr identitate a obiectelor elimin alte forme de interpretare, conducnd ctre o structur de tip arborescent. Modificarea obiectelor. Pe exemplul de mai sus, acceptnd varianta n care Petre i Ana sunt prinii lui Ion, orice modificare asupra fiului Anei sau asupra fiului lui Petre se va aplica asupra lui Ion. ntr-un sistem care accept identitatea obiectelor, dac modificarea s-a efectuat asupra fiului Anei, automat ea va fi extins i asupra fiului lui Petre. ncapsularea. A aprut din dou motive: 1. Necesitatea de a diferenia specificarea unei operaii de implementarea acesteia; 2. Modularizarea ca obiectiv. La origine ncapsularea deriv din tipurile de date abstracte, presupunnd existena unei interfee i a implementrii corespunztoare. Partea de interfa reprezint specificarea unui set de operaii ce se pot aplica asupra unui obiect, fiind singura zon vizibil a obiectului. Implementarea se refer att la componenta de date ct i la cea de procedur. Partea de date este reprezentarea obiectului , n timp ce partea de procedur descrie, cu ajutorul limbajelor de programare, implementarea fiecrei operaii. 36

Considerm ncapsularea adus la o form final n momentul n care numai operaiile sunt vizibile, iar datele i implementarea operaiilor sunt mascate n obiect. Ierarhii sau clase de tipuri (motenire). Motenirea reduce efortul de programare. Exist patru modaliti de a moteni: 1. Prin substituie; dac tipul t motenete de la tipul t, atunci asupra obiectului de tip t se vor putea executa mai multe operaii dect asupra celui de tip t. Acest tip de motenire se bazeaz pe comportare, nu pe valori. 2. Prin incluziune; corespunde noiunii de clasificare. Un tip t este un subtip al lui t, dac orice obiect de tip t este un obiect de tip t. Aceast motenire se bazeaz pe structur, nu pe operaii. 3. Prin restricie; este un caz particular al motenirii prin incluziune. Un tip t este un subtip al tipului t dac, conine toate obiectele de tip t ce satisfac o restricie specificat. 4. Prin specializare; tipul t este un subtip al lui t dac obiectele din t, aparin i lui t, dar conin un surplus de informaie specific. Extensibilitate. SGBD-OO trebuie s includ pe lng clasele sau tipurile predefinite (clasa obiect, clasa dat etc.) i instrumentele care s permit utilizatorului definirea de noi clase sau tipuri. Completitudinea. Limbajul de interogare pentru baza de date orientat pe obiecte trebuie s permit exprimarea tuturor programelor posibile. Din acest punct de vedere putem spune c SQL nu este un limbaj complet. Persistena. Limbajele de programare orientate pe obiecte utilizeaz conceptul de obiecte. Totui, aceste obiecte exist numai n timp ce programul este executat. O baz de date orientat pe obiecte conine obiecte persistente care exist permanent n baza de date. Concurena n exploatare. Se refer la posibilitatea ca mai muli utilizatori s manipuleze datele concurent. 11.4.2. Arhitecturi si limbaje pentru SGBD-OO Termenul de arhitectur se refer la o descriere abstract a organizrii unui sistem n scopul de a prezenta componentele funcionale i interfeele dintre ele. Nu exist o prere comun privind arhitectura SGBD-OO. Mai mult, arhitectura poate fi o problem de perspectiv, fiind dependent de modul cum este vzut SGBD-OO de ctre cercettor, ca utilizator final sau ca administrator de sistem. Arhitectura SGBD-OO cuprinde trei componente majore: 1.Gestionarul de obiecte (Obiect Manager) care asigur interfaa dintre procesele externe i SGBD-OO; 2. Server-ul de obiecte care este responsabil cu asigurarea serviciilor de baz ale SGBDurilor, cum ar fi: gestiunea tranzaciei i gestiunea stocului de obiecte; 3. Stocul rezident de obiecte sau ODB-ul nsi. n Figura 11.4 se prezint componentele de baz ale arhitecturii SGBD-OO. Utilizatorii finali externi i cei care dezvolt aplicaii pot folosi instrumente soft, cum ar fi: editoare de texte, editoare grafice, browseri de obiecte i clase, accesorii de proiectare automat de baze de date i interfee pentru sisteme de proiectare CAD/CAM. Aceste sisteme pot servi ca instrumente front_end ce realizeaz interfa cu Gestionarul de obiecte. Gestionarul de obiecte asigur implementarea complet a modelului de date obiecte pentru utilizatorul extern. Aceasta ar include posibilitatea de a defini structurile i de a executa operaiile specificate prin model. Gestionarul de obiecte primete cereri de creare de definiri de clase, de modificare a definirilor de clase deja existente, de manipulare a mesajelor generate de un program de aplicaie n execuie i de prelucrare a cererilor ad-hoc folosind translatorul de cereri. De

37

asemenea realizeaz legturile dinamice i operaiile de verificare a sintaxei i tipului (datei) necesare. Cerinele sunt apoi transmise Server-ului de obiecte ca tranzacii. Funciile Gestionarului de obiecte, aa cum reies din Figura 11.4, constau n: - funciile de prelucrare a mesajelor, incluznd legtura la momentul execuiei i verificarea tipului, ca i translatarea cererilor; - faciliti de definire i modificare a schemei bazei de date, incluznd definiri de clas noi sau corectate n ierarhii sau reele de clas existente. Serverul de obiecte realizeaz recuperarea (refacerea), adugarea, tergerea i actualizarea obiectelor stocate n stocul rezident n obiecte. Un singur server poate manipula tranzacii transmise de la mai muli gestionari de obiecte. Funciile serverului de obiecte constau din: gestiunea tranzaciilor, incluznd controlul concurenei, gestiunea buffer-ului i servicii de refacere n caz de incident; gestiunea fizic a stocului, incluznd plasarea obiectelor i implementarea metodelor de acces: serviciile de arhivare i de asigurare a copiilor de rezerv, pot fi , de asemenea, asigurate prin serverul de obiecte. BROWSER

SQL-extins INSTRUMENTE UTILIZATOR Procesoarele limbajelor LPOO, LDD, LMD

GESTIONARUL DE OBIECTE

SERVER DE OBIECTE

STOC REZIDENT DE OBIECTE Figura 11.4 Arhitectura general a unui SGBD-OO Cerinele aplicaiilor de proiectare pot pretinde ca SGBD-ul s existe pe mai multe platforme hard care pot comunica printr-o reea de calculatoare. ntr-un sistem de proiectare CAD, proiectanii folosind instrumente soft dezvoltate i lucrnd pe diferite platforme, pot accesa date stocate n SGBD-OO. Folosind un instrument CAD, fiecare proiectant poate dirija o sesiune interactiv pentru care este creat o copie individual a gestionarului de obiecte. 38

Mai mult, un gestionar de obiecte poate transmite tranzacii, n mod curent, server-lui de obiecte. Serverul de obiecte cu care comunic gestionarul de obiecte poate exista de asemenea pe aceeai platform ca i gestionarul de obiecte sau gestionarul i server-ul pot exista pe platforme diferite. Similar, o organizare cu un set de activiti de proiectare intercorelate poate solicita mai mult dect un server de obiecte, fiecare dintre acestea gestionnd separat un stoc rezident de obiecte. Pentru a facilita comunicarea ntre platforme hard separate, pot fi solicitate softuri de comunicaii reea. Figura 11.5 ilustreaz un sistem reea cu mai muli gestionari i servere de obiecte. n vederea asigurrii prelucrrii distribuite, SGBD-OO trebuie s gestioneze automat accesul la obiecte stocate n platforme hard separate. Legtura dintre gestionarul de obiecte i server-ul de obiecte trebuie s fie iniiat explicit de utilizator. UTILIZATOR 1 GESTIONAR DE OBIECTE 1 UTILIZATOR 2 GESTIONAR DE OBIECTE 2

SERVER DE OBIECTE 1

STOC REZIDENT DE OBIECTE 1

EDITOR GRAFIC GESTIONAR DE OBIECTE 3

UTILIZATOR 3 GESTIONAR DE OBIECTE 4

SERVER DE OBIECTE 2

STOC REZIDENT DE OBIECTE 2

Figura 11.5 Arhitectur reea de SGBD-OO.

39

n prezent, SGBD-OO comerciale sunt accesate n primul rnd prin limbajele de programare orientate pe obiect, cum ar fi: Smaltalk, Common Lisp i C++. Interfaa dintre LP-OO (limbaje de programare orientate pe obiecte) i SGBD-OO o reprezint limbajul pentru baze de date. Un SGBD trebuie s asigure un limbaj pentru baze de date pentru a permite definirea i manipularea schemei bazei de date i a datelor. Un SGBD-OO trebuie s posede un limbaj pentru baze de date pentru a permite accesul i manipularea modelului de date obiect i regsirea i actualizarea obiectelor. Spre deosebire de SGBD-urile convenionale, limbajul pentru baze de date al SGBDOO este parte integrant a LP-OO. Deoarece LPT-OO au existat naintea SGBD-OO, numeroase declaraii ale LDD i LMD sunt adaptri ale declaraiilor LP-OO deja existente. Limbajul pentru baze de date al SGBD-OO const din urmtoarele: Limbaj de definire a datelor (LDD). SGBD-OO trebuie s asigure un LDD pentru definirea schemei. LDD-ul trebuie s permit definirea claselor inclusiv a legturilor de motenire i definirea metodelor care specific comportamentul obiectului. Limbaj de manipulare a datelor (LMD) Limbaj de manipulare a datelor(LMD). Un SGBD-OO trebuie s asigure un LMD pentru regsirea, crearea, tergerea i actualizarea obiectelor individuale. n cadrul SGBD-OO, acestea se realizeaz prin mecanismul de transmitere a mesajelor. Limbaj de interogare. Aproape orice SGBD asigur regsirea subseturilor unei baze de date prin specificarea condiiilor logice bazate pe valori, folosind un limbaj de interogare. Modelul de date obiect, permite regsirea obiectelor individuale prin referirea ID-ului obiectului. Pentru a asigura regsirea subsetului printre grupul de obiecte, unele SGBDOO-uri (i unele implementri al LP-OO) posed un limbaj de interogare. n numeroase implementri acest limbaj se bazeaz pe transmiterea unui mesaj pentru selectarea i regsirea obiectelor. SGBD-OO pot avea interfee cu unul sau mai multe limbaje de programare orientate pe obiect. Definirile de clas (inclusiv metode) sunt implementate ca obiecte clas. Declaraiile LDD de creare a definirilor de clas sunt mesaje ctre o clas generic, sau metaclas, pentru a crea o instan a ei nsi, de exemplu un obiect clas. Deci, n legtur cu paradigma obiect, toate operaiile specificate de limbajul pentru baze de date ale unui SGBDOO pot fi implementate prin transmiterea de mesaje.

40