Introducere

Domeniul bazelor de date sufer de o explozie informaional. Iat, de exemplu, o list parial a publicaiilor ce apar regulat n Statele Unite n domeniu: 1. ACM Transactions on Database Systems - trimestrial cu aproximativ 500 pp/an. 2. ACM SIGMOD Record, trimestrial aproximativ 250 pp/an. 3. Proc. of the Annual SIGMOD Intl. Conference on Management of Data, aproximativ 450 pp/an. 4. Proc. of the Annual SIGACT - SIGMOD Sym. on Principles of Database Systems, aproximativ 350 pp/an. 5. Proc. of the Annual Intl. Conf. on Very Large Databases, aproximativ 450 pp/an. Adugnd la acestea conferinele mai specializate, ca de exemplu asupra bazelor de date distribuite, a bazelor de date CAD/CAM, a sistemelor de date expert sau orientate pe obiecte, cam 8 - 10 conferine pe an, cu lucrri publicate nsumnd n jur de 350 de pagini fiecare i adugnd i numrul mare de rapoarte care apar n universiti i laboratoare de cercetare, precum i lucrri ce apar ocazional n publicaii nrudite (Database Newsletter, Database Review, InfoDB, Database Programming and Design, etc.), precum i manualele i documentaiile firmelor vnztoare de DBMS-uri comerciale, ajungem cam la 100.000 de pagini pe an. Este clar c este aproape imposibil s inem pasul cu tot ce se ntmpl n domeniul nostru de interes. Exist ns fr ndoial o baz comun un alfabet necesar nelegerii dezvoltrilor n domeniu. De la aceast baz fiecare specialist face paii inevitabili spre supraspecializare. Cursul nostru de baze de date se vrea doar o introducere n subiect i nu o tratare exhaustiv, o prezentare a acelei baze de cunotiine absolut necesare lucrului n domeniul bazelor de date i nelegerii problematicii bazelor de date, precum i un mic pas mai departe. Obiectul principal al lucrrii de fa este deci de a oferi o baz pentru o educaie solid n fundamentele bazelor de date i de a da o deschidere ctre direciile noi de cercetare. Cursul este mprit n mai multe pri: proiectarea logic a bazelor de date proiectarea fizic a bazelor de date probleme de control a bazelor de date noi tendine n bazele de date

31

Capitolul 1. Concepte de baz

1.1. Ce este un sistem baz de date? Tehnologia bazelor de date a fost descris ca fiind una din ariile tiinei calculatoarelor cu o dezvoltare deosebit de rapid. Ca domeniu ea este nc tnr avnd nceputul pe la mijlocul anilor 60. n ciuda tinereii, ea a devenit de o importan covritoare, att teoretic ct i practic. Cantitatea total de date din bazele de date a devenit acum posibil a fi msurat n miliarde de octei; efortul financiar implicat este deasemenea uria. Nu este exagerat a spune c multe mii de organizaii au devenit critic dependente de operarea continu i cu succes a sistemelor de baze de date. Deci, ce este exact un sistem de baze de date? Simplu, nu e nimic mai mult dect un sistem de pstrare a nregistrrilor bazat pe calculator, adic un sistem al crui scop suprem este de a nregistra i menine informaii. Informaia implicat poate fi orice entitate creia noi i conferim o semnificaie, adic ceva care poate fi necesar n procesele de luare de decizii implicate n gestionarea unei organizaii. Figura 1.1. dorete s arate c un sistem baz de date implic patru componente majore: date, hardware, software i utilizatori. Le vom considera pe rnd n continuare: Date Datele memorate (stocate) ntr-un sistem sunt partiionate ntr-una sau mai multe baze de date.Pentru scopuri didactice, este convenabil s presupunem c exist numai o baz de date, coninnd totalitatea datelor stocate n sistem. Exist totui raiuni puternice pentru care aceast restricie nu este folosit dect arareori n practic. Definiie: O baz de date este un depozit pentru date memorate. n general ea este att intergrat ct i partajat. Prin integrat nelegem c baza de date poate fi gndit ca o unificare de mai multe fiiere de date, altfel distincte, cu redundanele dintre aceste fiiere total sau parial eliminate. De exemplu, o baz de date ar putea conine att nregistrri ANGAJAT, coninnd nume, adres, departament, salariu, etc. ct i nregistrri PERFECIONRI reprezentnd nrolarea angajailor n cursuri de perfecionare. S presupunem c pentru administrarea cursurilor este necesar cunoaterea departamentului fiecrui angajat nscris. Este clar c nu este necesar s se introduc aceast informaie redundant n nregistrrile PERFECIONRI, deorece ea este deja cuprins n datele ce se gsesc la ANGAJAT-ul corespunztor.

32

Data Base Management System DBMS

Programe aplicaie

End Users

Fig. 1.1. Schema simplificat a unui sistem baz de date. Prin partajarea unei baze de date se nelege c bucile individuale de date din baza de date pot fi partajate ntre mai muli utilizatori individuali, n sensul c fiecare dintre ei poate avea acces la aceai bucat de date (i o poate folosi n scopuri diferite). Astfel, partajarea este o consecin a faptului c baza de date este integrat. n exemplul de mai sus, informaia despre departamentul din nregistrrile ANGAJAT este partajat de utilizatori din departamentul personal i de utilizatori din departamentul pregtire cadre. O alt consecint a faptului c baza de date este integrat este c un utilizator dat va utiliza numai o parte (o submulime) a bazei de date, Mai mult, submulimile diferiilor utilizatori se vor acoperi n diferite moduri. Termenul partajat este extins pentru a acoperi adesea partajarea concurent: adic abilitate mai multor utilizatori de a accesa baza de date posibil chiar aceai bucat de date - n acelai timp. Astfel de sistem se numesc sisteme multiutilizator. Hardware Hardul unui sistem baz de date i const din volumele de memorare secundare discuri, dischete, benzi pe care rezid baza de date, mpreun cu aparatele, unitile de control, canalele respective. O baze de date se poate presupune fr riscuri ca fiind prea mare pentru a putea fi stocat n memoria central a unui calculator. Cursul de fa nu vizeaz aspectele hard ale domeniului.

33

Software ntre baza de date fizic (adic datele aa cum sunt ele memorate pe suport) i utilizatorii sistemului exist un nivel de software, numit uzual sistem de gestionare a bazei de date (SGBD sau n englez, data base management system DBMS). Toate cererile utilizatorilor pentru accede baza de date sunt ndreptate ctre DBMS. O funcie generala oferit de ctre DBMS este de a feri utilizatorii de detaliile la nivel hardware, adic de a le da posibilitatea s se ridice peste acestea i de a suporta operaii utilizator (de exemplu citete nregistrarea ANGAJAT pentru angajatul Ionescu) care se exprim in termenii unui nivel superior celui hard. Utilizatori Vom considera trei mari categroii de utilizatori. n primul rnd, exist programatorul de aplicaie, responsabil a scrie programe aplicaie care folosesc baza de date, tipic n limbaj de programare (Cobol, C, etc.) sau limbaj propriu al bazei de date (bDase, FoxPro, etc.). Aceste aplicaii program opereaz asupra datelor n toate modurile obinuite: regsirea informaiilor, crearea informaiilor noi, modificarea sau tergerea informaiilor existente. Toate aceste funcii se realizeaz emind cereri potrivite ctre DBMS. O a doua clas de utilizatori sunt end-userii ce acceseaz baza de date de la un terminal. Ei folosesc un limbaj de interogare (query language) oferit ca o parte integrant a sistemului sau utilizeaz aplicaiile scrise de programatorii de aplicaie. A treia clas de utilizatori este administratorul bazei de date, pe scurt DBA. 1.2. Date operaionale Datele din baza de date se zic operaionale pentru a le distinge de cele de intrare, de ieire i de alte tipuri de date. Definiie (Engles) O baz de date este o colecie de date operaioanale folosite de ctre aplicaiile sistem ale unei intreprinderi particulare. Aceast definiie cere cteva explicaii. Intreprindere este termenul general convenabil pentru orice organizaie comercial, tiinific, tehnic, etc. Exemple ar putea fi companii productive, banci, spitale, universiti, departamente guvernamentale. Orice intreprindere trebuie s ntrein n mod curent o mulime de date despre operarea sa. Acestea sunt date operaionale. Exemple ar fi datele de producie, de contabilitate, datele despre pacieni sau studeni, datele de planificare, etc.

34

Precum am menionat, datele operaionale nu includ date de intrare i de ieire, cozi de lucru sau orice informaie tranzient. Datele de intrare se refer la informaia introdus n sistem din lumea exterioar, de obicei prin terminale. Acest informaie poate cauza o modificare n datele operaionale, dar ea insi nu este o parte a bazei de date. Similar, datele de ieire se refer la mesaje i rapoarte emannd din sistem (tiprite sau afiate pe terminal). Din nou, un astfel de raport conine informaii din datele operaionale, dar nu sunt ele nsele parte a bazei de date. Pentru a exemplifica conceptul de date operaionale considerm cazul unei fabrici. O astfel de intreprindere va dori s rein informaii despre proiectele pe care le are n derulare; prile (componente, subansamble, etc.) folosite n aceste proiecte; furnizorii care livreaz prile; magaziile n care se depoziteaz prile; angajaii care lucreaz la proiecte; etc. Acestea sunt entitile de baz despre care se nregistreaz date n baza de date. Este important de notat c, n general, vor exista asociaii sau relaii legnd aceste entiti de baz mpreun. Ele se reprezint prin sgei ca n fig. 1.2. De exemplu exist o asociaie ntre furnizori i pri. Fiecare furnizor d anumite pri i reciproc, fiecare parte este dat de anumii furnizori. Similar prile sunt folosite n proiect, i invers proiectele folosesc pri; prile sunt depozitate n magazii i magaziile conin pri, etc. S notm c aceste relaii sunt toate bidirecionale: adic ele, toate pot fi traversate n ambele direcii. De exemplu, relaia ntre angajai i departamente poate fi folosit pentru a rspunde la urmtoarele ntrebri: 1. Fiind dat un angajat, s se gseasc departamentul n care lucreaz. 2. Fiind dat un departament, s se gseasc toi angajaii corespunztori lui. Elementul semnificativ depre relaii ca cele de mai sus este c ele sunt o parte a datelor operaionale, chiar mai mult dect entitile asociate. Deci ele trebuie s fie reprezentate n baza de date (vom vedea mai trziu cum). 1. Cu toate c majoritatea relaiilor din diagram asociaz dou tipuri de entiti, exist i relaii care asociaz entiti de trei tipuri, precum i relaii care asociaz un singur tip de entitate. 2. O aceai entitate poate fi asociat n oricte relaii. Entitile i relaiile sunt dou tipuri disimilare fundamentale de obiecte. Totui, o asociaie ntre entiti poate fi considerat ea nsi o entitate, dac lum ca definiie pentru entitate: un obiect despre care vrem s nregistrm informaii i deci asociaia se potrivete cu aceast definiie. Vom vedea deci relaiile ca un tip special de entitate. Figura 1.2. ilustreaz i un numr de alte puncte:

35

Furnizori

Proiecte

Pri

Magazii

Angajai

Locaii

Departamente Fig. 1.2. Asociatii ntre entitatile de baza

1.3. De ce baz de date? De ce ar trebui o intreprindere s aleag a-i memora datele operaionale ntro baz de date integrat? Rspunsul direct este acela c un sistem baz de date ofer intreprinderii un control centralizat asupra datelor sale operaionale, ceea ce este un scop demn de atins. Aceasta nu este cazul n situaia actual a intreprinderilor n care adesea fiecare aplicaie are propriile fiiere private, adesea propriile sale discuri i benzi iar datele operaionale sunt astfel larg dispersate i probabil greu de controlat i corelat. Cele de mai sus implic faptul c ntr-o intreprindere cu un sistem baz de date trebuie s existe o persoan identificabil care are aceast reponsabilitate central fa de datele operaionale. Aceast persoan este administratorul bazei de date (DBA), menionat n seciunea 1.1. Vom discuta n detalii rolul lui mai trziu. Acum este suficient s menionm c slujba lui implic att un grad nalt de experien tehnic ct i abilitatea de a nelege i interpreta cerinele de manager. ( n practic DBA este adesea o echip i nu o singur persoan). Avantajele care rezult din controlul centralizat sunt: 1. Redundana poate fi redus n sistemele non-baz de date fiecare aplicaie i are fiierele sale private, ceea ce duce adesea la redundana datelor nregistrate i ca rezultat un mare spaiu de memorare. Nu sugerm ca ntreaga redundan s fie eliminat, dar ea trebuie controlat de ctre DBA. 2. Inconsistena poate fi evitat Corolar al lui 1.: Nu sunt permise dou intrri pentru aceai entitate n baza de date, cci, la actualizare una poate fi omis. 3. Datele pot fi partajate

36

Nu nseamn numai c aplicaiile existente pot partja date din baza de date (vezi 1.1.) dar i c noile aplicaii pot fi dezvoltate pentru a opera asupra datelor existente. 4. Standardele vor fi respectate DBA impune n reprezentarea datelor standarde unice. 5. Pot fi aplicate restricii de securitate 6. Poate fi meninut integritatea datelor 7. Cererile conflictuale pot fi balansate 1.4. Independena datelor Independena datelor poate fi neleas uor dac considerm la nceput opusul ei. Multe din aplicaiile de astzi sunt dependente de date. Aceasta nseamn c modul n care datele sunt organizate pe suportul secundar de stocare i modul n care ele sunt accesate sunt ambele dictate de cerinele aplicaiei i mai mult tiina organizrii datelor i tehnicile de acces sunt construite n logica aplicaiei. De exemplu, se poate decide (din raiuni de performan) ca un fiier particular s fie memorat n forma secvenialindexat. Aplicaia, apoi, trebuie s tie c indexul exist i trebuie s tie secvena fiierului (aa cum e definit de ctre index) iar structura intern a aplicaiei se va construi n jurul acestei cunoateri. n plus, forma precis a variantelor procedurii de acces i de verificare-excepie, din cadrul aplicaiei, vor depinde de detaliile interfeei prezentate de ctre software-ul secveniel indexat. Spunem c o aplicaie ca cea de mai sus este dependent de date deoarece este imposibil s modificm structura de memorare (modul n care sunt stocate nregistrrile) sau strategia de acces fr a afecta, probabil drastic aplicaia. De exemplu, nu ar fi posibil s nlocuim fiierul secveial indexat de mai sus cu, s zicem, hash-file, fr a face modificri majore n aplicaie. ntr-un sistem baz de date, totui, este de nedorit ca aplicaiile s fie dependente de date, din cel puin dou motiv: 1. Diferitele aplicaii au nevoie de viziuni diferite asupra acelorai date. 2. DBA trebuie s aib libertatea de a alege structura de memorare sau strategia de acces ( sau amndou) ca rspuns la cerinele de modificare far a modifica aplicaiile existente. De exemplu, intreprinderea poate adopta noi standarde; prioritile aplicaiilor se pot schimba; noi tipuri de periferice devin disponibile, etc. Dac aplicaiile sunt dependente de date, astfel de schimbri implic modificri corespunztoare n programe. Rezult c independena datelor este un obiectiv major pentru sistemul baz de date. Definiia independenei datelor ar putea fi imunitatea aplicaiilor la modificri de structur a memorrii i a stategiei de acces.

37

S considerm, pentru nceput, tipurile de modificri pe care un DBA dorete s le fac (i la care dorim ca aplicaiile s fie imune). ncepem cu cteva definiii: Un cmp este cea mai mic unitate de date stocate n baza de date. Baza de date va conine, n general, mai multe ocurene sau instane pentru fiecare din tipurile de cmpuri. O nregistrare este o colecie de nume de cmpuri asociate. Facem din nou distincie ntre tip i ocuren. O ocuren sau instan de nregistrare const dintr-un grup de ocurene de cmp nrudite (asociate) i reprezint o asociere ntre ele. Un fiier este o colecie a tuturor nregistrrilor de unul sau mai multe tipuri. Reprezentarea datelor numerice Un cmp numeric poate fi memorat n forma intern aritmetic (de ex: zecimal mpachetat) sau ca un ir de caractere. n fiecare caz, DBA trebuie s aleag o baz potrivit (de ex: binar sau zecimal), o scal (fix sau flotant) un mod (real sau complex) i o precizie (numr de cifre). Oricare din aceste aspecte poate fi schimbat pentru a nbunti performana sau pentru a se conforma la un nou standard sau pentru alt raiune. Reprezentare datelor caracter Un cmp ir de caractere poate fi memorat n mai multe coduri de caractere (de ex. EBCDIC, ASCII) Uniti pentru datele numerice Unitile ntr-un cmp numeric se pot schimba - din inches n centimetrii, de exemplu, n timpul procesului de metrizare. Codificarea datelor n anumite situaii, este de dorit a reprezenta datele prin valori codificate. Materializarea datelor n mod normal, cmpul logic vzut de o aplicaie corespunde cu un anumit cmp unic dintr-o nregistrare. ntr-un astfel de caz, procesul materializrii adic construcia unei ocurene corespunztoare a cmpului memorat i prezentarea ei aplicaiei - se poate spune c este direct. Totui ocazional, un cmp logic nu va avea numai un singur cmp memorat, ci valorile lui se vor materializa cu ajutoarul unor calcule efectuate asupra unei mulimi de cmpuri memorate. De exemplu un cmp cantitate total. Atunci cmpul logic se zice c este indirect. Structura nregistrrilor memorate. Dou tipuri de nregistrri pot fi combinate ntr-unul singur. De exemplu, tipurile de nregistrri (parte, numr, culoare) i (parte, numr, greutate) pot fi 38

integrate pentru a da (parte, numr, culoare, greutate). Aceste probleme apar atunci cnd aplicaii de dinainte de a avea o baz de date sunt integrate ntrun sistem baz de date. Aceasta implic faptul c nregistrarea logic a unei aplicaii poate consta dintr-o submulime a unei nregistrri memorate, adic faptul c anumite cmpuri memorate pot fi invizibile pentru o aplocaie particular. Alternativ, un singur tip de nregistrare memorat poate fi spart n dou. n cazul nostru (parte, numr, culoare, greutate) poate da (parte, numr, culoare) i (parte, numr, greutate). O astfel de despicare permite ca poriuni mai puin folosite s fie memorate pe periferice mai lente, de exemplu. Implicaia este c nregistrarea logic a unei aplicaii poate conine cmpuri din mai multe tipuri de nregistrri memorate. Structura fiierelor memorate Un fiier dat poat fi implementat fizic n memorie ntr-o sumedenie de moduri. De exemplu, poate fi n ntregime coninut ntr-un volum de memorare (ex: disc) sau poate fi imprit pe mai multe volume de mai multe tipuri diferite. El poate fi sau nu fizic secvenial n concordan cu valorile unui anumit cmp; poate avea unul sau mai muli indeci asociai; poate fi construit cu pointeri; nregistrrile pot fi blocate sau nu, etc. Nici una din aceste consideraii nu afecteaz aplicaia (mai puin performana). Lista de mai sus implic c baza de date trebuie s fie n stare s creasc fr a afecta aplicaiile existente, aceasta fiind raiunea major a independenei datelor. Adic s putem aduga n baza de date noi tipuri de cmpuri i nregistrri. 1.5. O arhitectur pentru un sistem baz de date Suntem acum n poziia de a evidenia o arhitectur pentru un sistem baz de date. Nivel exterior (Vederi utilizatori individuali) Nivel conceptual (Vedere comunitate utilizatori) Nivel intern (Vedere storage=memorare)

Fig.1.3. Cele trei nivele ale bazei de date

39

Scopul nostru n prezentarea acestei arhitecturi este de a oferi un cadru pe care ne putem construi celelalte capitole i de a nelege, n general baza de date. Arhitectura este mprit n trei nivele generale: intern, conceptual i extern. Grosier vorbind, nivelul intern este acela care e cel mai apropiat de memorarea fizic, adic cel legat de modul de memorare al datelor. ivelul extern este cel mai apropiat de utilizatori, adic de modul n care datele se vd de ctre utilizatorii individuali. Nivelul conceptual este nivelul de indirectare ntre celelalte dou viziuni. Exemplu: La nivelul conceptual, baza de date conine informaii despre un tip de entitate numit ANGAJAT. Fiecare ANGAJAT are un NUMAR-ANGAJAT (6 caractere), NUMAR-DEPARTAMENT (4 caractere) i un SALARIU (5 cifre). La nivelul intern, angajaii sunt reprezentai printr-un tip de nregistrare STORED-ANG de 18 octei. STORED-ANG conine patru tipuri de cmpuri: un prefix de 6 octei (posibil cu informaii de control, flags, pointers, etc.), i trei cmpuri de date corespunztoare celor trei proprieti ale lui ANGAJAT. n plus, nregistrrile STORED-ANG sunt indexate prin cmpul EMP# de un index numit EMPX. La nivelul extern, un utilizator poate vedea numai dou cmpuri (NUMARANGAJAT i SALARIU) iar un alt utilizator poate vedea numai (NUMARANGAJAT i NUMAR-DEPARTAMENT). S notm c obiectele corespunztoare pot avea nume diferite la cele trei nivele. S examinm acum mai n detaliu componentele arhitecturii. Utilizatorii sunt fie programatorii de aplicaii fie utilizatorii de la terminale. DBA este un caz special i important. Fiecare utilizator are un limbaj la dispoziia sa: programatorii au limbaje de programare COBOL, C, etc. iar utilizatorii au un limbaj de interogare, un query language. Pentru scopurile noastre lucrul important relativ la limbajul utilizator este ca acesta va include un sublimbaj date (Data SubLanguage DSL), adic un subset al limbajului total care este legat de obiectele i operaiile bazei de date. Spunem c sublimbajul de date este scufundat ntr-un limbaj gazd. n principiu, orice sublimbaj de date este o combinaie a dou limbaje: un limbaj de definiie date (Data Definition Language DDL), care definete obiectele bazei de date (aa cum sunt ele percepute de ctre utilizator) i un limbaj de manipulare date (Data Manipulation Language DML), care prelucreaz astfel de obiecte. S revenim ns la arhitectur. Am indicat deja c un utilizator individual va fi interesat, n general, numai de o anumit poriune a bazei de date total; mai mult vederea utilizatorului asupra acelei poriuni va fi ceva abstract dac o comparm cu modul n care datele respective sunt memorate fizic. Viziunea utilizatorului individual se numete vedere extern. O vedere extern este astfel coninutul

40

bazei de date aa cum este ea vzut de un utilizator particular (adic pentru acel utilizator, vederea extern este baza de date). De exemplu, un utilizator din departamentul personal va vedea baza de date ca o colecie de ocurene de nregistrri departament plus o colecie de ocurene de nregistrri angajat (i nu tie de ocurenele de nregistrri clieni, pri, etc.). n general, deci, o vedere extern const din mai multe ocurene de multiple tipuri de nregistrri externe. O nregistrare extern nu este necesar aceai cu nregistrarea memorat. Sublimbajul de date al utilizatorului este definit n termenii nregistrrilor externe. De exemplu, o operaie DML get va gsi o ocuren de nregistrare extern i nu una de nregistrare memorat. Vedem acum c termenul de nregistrare logic din seciunea 1.4. este de fapt sinonim celui de nregistrare extern. Fiecare vedere extern este definit cu ajutorul unei scheme externe care const din definiii pentru fiecare din variatele tipuri de nregistrri externe din vederea extern. Schema extern este scris folosind poriunea DDL a sublimbajului de date. De aceea, DDL-ul este numit adesea DDL extern. De exemplu, tipul de nregistrare extern angajat poate fi definit ca avnd un cmp de 6 caractere pentru numrul angajatului, plus un cmp fix binar pentru salariu, etc. n plus, trebuie s existe o definiie pentru maparea ntre schema extern i schema conceptual. Vederea conceptual este o reprezentare a ntregii informaii coninute n baza de date, din nou ntr-o form care este ceva abstract n comparaie cu modul n care datele sunt stocate fizic. Ea poate fi i puin diferit de modul n care datele sunt vzute de un utilizator particular. Grosso modo vorbind, ea se dorete a fi o vedere a datelor aa cum sunt n realitate, mai degrab dect modul n care un utilizator este forat s le vad. Vederea conceptual const din multiple din multiple ocurene de multiple tipuri de nregistrri conceptuale. De exemplu, poate consta dintr-o colecie de ocurene de nregistrri departament, plus o colecie de ocurene de nregistrri angajat plus o colecie de ocurene de nregistrri furnizor, o colecie de ocurene de nregistrri pri, etc. O nregistrare conceptual nu este necesar aceai cu o nregistrare extern sau o nregistrare memorat. Vederea conceptual este definit cu ajutorul unei scheme conceptuale care include definiii pentru fiecare din variatele tipuri de nregistrri conceptuale. Schema conceptual se scrie folosind un alt limbaj de definiie de date DDL-ul conceptual. Dac se dorete s se obin independena datelor, aceste definiii trebuie s nu implice nici o considerare despre structura de memorare sau strategia de acces - ele trebuie s fie definiii referitaoare numai la coninutul informaiei. Astfel, trebuie s nu fie nici o referin la reprezentarea n

41

memorie a unui cmp, secven fizic, indexare sau orice alt detaliu de memorare/acces. Vederea conceptual este, apoi, o vedere a coninutului ntregii baze de date iar schema conceptual este o definiie a acestei vederi. Ea este puin mai mult dect o simpl reuniune a tuturor vederilor utilizator individuale, posibil cu adugarea unor proceduri simple de autorizare i validare. Al treilea nivel de arhitectur este nivelul intern. Vederea intern este o reprezentare de nivel foarte jos a ntregii baze de date. Ea const din multiple ocurene de multiple tipuri de nregistrri interne, adic ceea ce noi am numit nregistrri memorate. Ea este totui deasupra nivelului fizic, deoarece nu lucreaz n termeni de nregistrri fizice sau blocuri i nici cu restricii specifice perifericelor ca de exemplu mrime cilindru sau pist. Vederea intern presupune un spaiu de adrese liniar i infinit. Detaliile despre modul n care este mapat acest spaiu de adrese pe memoria fizic este specific implementrii i nu este adresat direct n arhitectur. Vederea intern este descris cu ajutorul schemei interne care nu numai c definete tipuri variate de nregistrri memorate, dar specific deasemenea ce indeci exist, cum se reprezint cmpurile memorate, etc. Schema intern se scrie folosind un alt limbaj de definiie date, DDL-ul intern. Maparea conceptual/intern definete corespondena dintre vederea conceptual i baza de date memorat (vederea intern), specificnd modul n care se mapeaz cmpurile i nregistrrile conceptuale n corespondente lor. Dac structura bazei de date memorate se modific - adic a aprut o schimbare n definiia structurii de memorare - maparea conceptual/intern trebuie s se schimbe corespunztor, astfel nct schema conceptual s rmn aceai. Cade n responsabilitatea lui DBA s controleze astfel de schimbri. Cu alte cuvinte, efectele unor astfel de schimbri trebuie s fie coninute sub nivelului conceptual, astfel ca independena datelor s fie atins. Maparea extern/conceptual definete corespondena dintre o vedere extern particular i vederea conceptual. n general acelai fel de diferene pot exista ntre aceste dou nivele ca i cele care exist ntre vederea conceptual i baza de date memorat. De exemplu, cmpurile pot avea diferite tipuri de date, nregistrrile pot fi secvenializate diferit, etc. n acelai timp pot exista oricte vederi externe; orici utilizatori pot partaja o vedere extern dat; diferitele vederi externe se pot acoperi. Sistemul de gestiune al bazei de date (Data Base Management System DBMS) este softul care mnuiete toate accesele la baza de date. Conceptual, se ntmpl astfel: 1. Un utilizator emite o cerere de acces, folosind un limbaj patricular de manipulare date. 2. DBMS-ul intercepteaz cererea i o interpreteaz. 42

3. DBMS-ul inspecteaz, pe rnd, schema extern, maparea extern/conceptual, schema conceptual, maparea conceptual/intern i definiia de structur de memorare. 4. DBMS-ul realizeaz operaiile necesare asupra bazei de date memorate. De exemplu, s considerm ceea ce este implicat n regsirea unei ocurene de nregistrare extern particular. n general cmpurile vor fi cerute din mai multe ocurene de nregistrri conceptuale. Fiecare ocuren de nregistrare conceptual, la rndul ei, poate cere cmpuri din mai multe ocurene de nregistrare memorat. Cel puin conceptual, atunci DBMS trebuie s regseasc toate ocurenele de nregistrare memorat, s construiasc ocurenele de nregistrare conceptual cerute i apoi s construiasc ocurena de nregistrare extern cerut. La fiecare nivel sunt necesare conversii de tipuri de date. Din nou, responsabilitile DBA includ: 1. Decizia asupra coninutului informaiei coninute n baza de date. DBA identific entitile de interes pentru intreprindere i identific informaia care se nregistreaz despre aceste entiti. DBA definete apoi coninutul bazei de date scriind schema conceptual (folosind limbajul DDL conceptual). Forma obiect (compilat) a acestei scheme este folosit de ctre DBMS n rspunsul la cererile de acces. Forma scris (necompilat) acioneaz ca un document de referin pentru utilizatorii din sistem. 2. Decizia asupra structurii de memorare i a structurii de acces. DBA decide asupra modului ncare datele sunt reprezentate n baza de date i trebuie s specifice reprezentarea scriind definiia de structur de memorare (folosind DDL-ul intern). n plus trebuie s specifice maparea ntre definiia structurii de memorare i schema conceptual. n practic, att DDL-ul intern ct i cel extern vor include, probabil, mijloacele pentru a specifica aceast mapare, dar definiiile diferite trebuie s fie clar separate. Ca i schema conceptual, schema intern i maparea coresunztoare trebuie s existe att n forma scris ct i n forma obiect. 3. Legtura cu utilizatorii. Pentru a se asigura c datele pe care le achiziioneaz utilizatorii sunt corecte, DBA pstreaz legtura cu acetia i pentru a scrie schemele externe necesare, folosind DDL-ul extern. n plus, maparea ntre orice schem extern dat i schema conceptual trebuie specificat de asemenea. n practic, DDL-ul extern va include, probabil, mijloacele pentru a specifica aceast mapare, dar schema i maparea trebuie s fie clar distincte. Fiecare schem extern i maparea corespunztoare vor exista att n surs ct i n obiect. 4. Definirea procedurilor de verificri autorizate i de validri.

43

Aa cum am mai spus, acestea pot fi considerate ca extensii logice ale schemei conceptuale. DDL-ul conceptual va include faciliti pentru a specifica astfel de verificri i proceduri. 5. Definirea unei strategii pentru salvri i restaurri. Odat ce o intreprindere a decis s foloseasc un sistem baz de date, ea devine critic dependent de succesul operrii sistemului. n eventualitatea unei deterioarri a oricrei poriuni a bazei de date cauzate de o eroare uman, eec hardware sau al sistemului de operare - este esenial s fie capabil s repare datele implicate, cu un minimum de ntrziere i cu un efect ct mai mic asupra restului sistemului. DBA trebuie s defineasc i s implementeze o strategie de restaurare potrivit, implicnd, de exemplu, salvarea periodic a bazei de date pe band i proceduri de rencrcare de poriuni relevante ale bazei de date din ultima band. 6. Monitorizarea performanei i rspunsuri la schimbrile n cerine. DBA este responsabil pentru a organiza sistemul astfel nct s obin performana care este cea mai bun pentru interprindere i pentru a face ajustrile potrivite, dup cum se schimb cerinele. Aa cum am spus, orice schimbare n detaliile memorrii i accesului trebuie s fie acompaniat de o schimbare corespunztoare n definiia maprii la memorare, astfel nct schema conceptual s rmn constant. Este clar c DBA cere un numr de programe utilitare pentru a se ajuta n aceste sarcini. Astfel de utilitare vor fi o parte esenial a sistemului baz de date real. Iat cteva exemple de astfel de utlitare. 1. Rutina de ncrcare (pentru a crea versiunea iniial a bazei de date) 2. Rutina de reorganizare (pentru a reorganiza baza de date, de exemplu de a elimina datele perimate) 3. Rutine jurnaliere (pentru a nota orice operaie asupra bazei de date mpreun cu identificarea utilizatorului ce a efectuat-o) 4. Rutine de restaurare (pentru a restaura baza de date la o stare anterioar unui eec hard sau de programare) 5. Rutine de analiz statistic (pentru a asista n monitorizarea performanei) Programele utilitare se vor gndi ca aplicaii speciale oferite de sistem, cu excepia rutinelor jurnaliere, care trebuie s fie parte a lui DBMS nsui. Anumite rutine vor opera direct la nivelul intern. Unul dintre cele mai importante instrumente ale DBA este dicionarul de date. El este o baz de date, coninnd date despre date, adic, descrieri ale obiectelor sistemului. n particular, toate schemele (extern, conceptual i intern) snt memorate fizic n dicionar. Un dicionar comprehensiv va include, de asemenea, informaii referine ncruciate. Ultima component la care ne vom referi n acest capitol este interfaa utilizator. Ea poate fi definit ca o margine n sistem sub care totul 44

devine invizibil pentru utilizator. Prin definiie interfaa utilizator este la nivelul extern.

User A1 UserA2 UserA1 Limbaj Limbaj gazd+ gazd+ DSL DSL

UserB1 Limbaj gazd+ DSL

UserB2 Limbaj gazd+ DSL

UserB3 Limbaj gazd+ DSL

Vedere Schema extern A extern A

Schema extern B

Vedere extern B

Scheme i mapri Mapare extern/conceptualA Mapare extern/conceptualB construite i meninute Schema Vedere de ctre DBMS conceptual conceptual DBA

Vedere intern Baza de date memorat

Interfaa utilizator Fig.1.4. Arhitectura sistemului baz de date. 1.6. Baze de date distribuite. O baz de date distribuit este, tipic, o baz de date care nu este memorat n totalitate ntr-o singur locaie fizic ci, mai degrab, este mptiat ntr-o 45

reea de calculatoare. Ca un exemplu simplificat, s considerm un sistem bancar n care baza de date cu conturile clienilor este distrubuit la sucursalele bncii, astfel nct nregistrarea contului unui client particular este memorat la sucursala local a clientului. Cu alte cuvinte, datele sunt memorate la locaia la care sunt folosite mai des, dar ele sunt disponibile, prin reeaua de comunicaii, i utilizatorilor din alte locaii (de exemplu cei de la sediul central al bncii). Avantajele unei astfel de distribuii sunt clare: ea combin eficiena prelucrrii locale (fr regie de comunicare) pentru majoritatea operaiilor cu avantajele discutate mai nanite (n particular partajarea datelor) oferite de un sistem centralizat. Un obiectiv cheie pentru un sistem distribuit este acela c el seamn cu un sistem centralizat pentru utilizator. Adic, utilizatorul nu trebuie n mod normal stie unde este memorat fizic o bucat dat de date (astfel c aplicaiile sunt independente de maniera n care sunt datele distribuite, fcnd posibil schimbarea distribuiei fr a afecta acele aplicaii). Astfel, faptul c baza de date este distribuit va fi relevant numai la nivelul intern i nu la nivelurile conceptual i extern. Memento Baz de date, integrare, partajare Sistem baz de date DBMS Cmp, nregistrare, Fiier memorat DML Sublimbaj de date Securitate Integritate Bibliografie 1. Date, C.J. An Introduction to Database Systems 3rd Ed., Addison Wesley, 1982 2. Ross, R.G. Database Systems: Design, Implementation and Management, Armacom, NY, 1978 3. Cardenas, A.F. Data Base Management Systems, Allyn & Bacon, Boston, 1979 Schema extern, vedere, DDL Schema conceptual, vedere, DDL Schema intern, vedere, DDL Entitate Relaie Independena datelor Dicionar de date

46

Capitolul 2. Abordarea cu baze de date

2.1. Concepte de baz Fiind dat prezentarea general a domeniului mpreun cu succinte incursiuni n teorie din capitolul precedent, vom continua prin a detalia conceptele deja prezentate, alturi de altele noi i a familiariza cititorul cu conceptul abordrii cu baze de date. Abordarea cu baze de date recunoate c datele sunt gestionate analog altor resurse ale intreprinderii, cum ar fi personalul, mijloacele fixe, captalul. Organizaiile cheltuiesc mari sume de bani pentru a colecta i a manipula date ncercnd s extrag informaia necesar n luarea deciziilor. Unul din obiectivele abordrii cu baze de date este pstrarea acestei investiii n resurse de date prin protecia i gestionarea datelor mai degrab, dect a aplicaiilor care acced datele. Gestionarea datelor implic att gestionarea factorilor reprezentai de iruri de bii pe medii magnetice de memorare ct i gestionarea semnificaiei acestor factori. Semnificaiile sunt gestionate prin organizarea lor n structuri logice de entiti. 2.2. Semnificaii O entitate sunt datele despre un obiect specific, fie real, fie abstract. O entitate are proprieti, ea este ceva despre care se cunoate ceva. Un exemplu de entitate este angajatul Ion Ionescu, ale crei cteva proprieti sunt: Nume angajat = Ion Ionescu Numr marc = 1271 nlime = 175 Greutate = 78 Data naterii = 25 Aprilie 1960 Localitatea naterii = Timioara, TM Data angajrii = 1 Septembrie 1986 Funcia = economist Compartiment = plan O colecie de entiti cu proprieti similare se numete tip de entitate sau cteodat, clas de entitate. De exemplu, Ion Ionescu, Ion Iliescu i Ion 47

Popescu sunt entiti angajat. Ei au cu toii proprietile de nume angajat, numr marc, nlime, greutate, data naterii, localitatea naterii, data angajrii, funcia, compartimentul. Ei sunt, astfel, membri ai tipului de entitate angajat. Gestionarea datelor este gestionarea entitilor, a tipurilor de entiti i a relaiilor ntre ele. De fapt, ne vom focaliza pe gestionarea tipurilor de entiti mai degrab dect pe ocurene individuale de entitate. Un tip de entitate reprezint semnificaie, pe cnd o instan de entitate reprezint fapte. Proprietile unei entiti se vor numi atributele sale. Alte surse numesc atributele elemente de date sau item-uri de date sau cmpuri. Datele sunt fapte plus semnificaii iar faptele sunt valori ale atributelor. Se poate cunoate semnificaia unui fapt cunoscnd de la ce atribut i la ce entitate se aplic faptul. n plus, o entitate trebuie s aib unul sau mai multe atribute ale cror valori identific n mod unic o instan de entitate. Aceste atribute revelatoare se numesc cheie primar a entitii. Numrul de marc din exemplul de mai sus ar putea fi cheia primar a entitii angajat. 2.3. Baze de date Datele dintr-o colecie de entiti pot fi agregate i rezumate n moduri diferite pentru a produce informaie. Informaia este data plasat n context care poate fi furnizat de ctre o situaie sau de alte date. Cine decide care informaie este valabil pentru o afacere? Aceast povar cade n general n sarcina decidentului (decision maker). Cunotine Decizii Aciuni Informaii Fapte

Date

Fig.2.1. Datele ca parte integrant n procesul decizional.

48

De fapt, decidentul poate ncerca mai multe seturi posibile de informaii nainte de a decide care este ntr-adevr util. Pentru a complica lucrurile, s menionm c informaia util de astzi este frecvent diferit de informaia util de mine sau de ieri. Informaia pertinent poate fi reinut ca parte a memoriei persoanei i poate deveni parte a cunotiinelor persoanei. Pentru a crete (a mri) bazele noastre de cunotiine mentale memorate, noi colectm i memorm date n form automat. O astfel de colecie se numete baz de date. Ea poate fi partajat de mai muli utilizatori i ea este paratajat i gestionat pentru a-si pstra valoarea i calitatea n timp. O baz de date reprezint nu numai date despre entiti dar i date despre relaiile dintre entiti. 2.4. Baze de date fizice i logice Exist dou forme de baze de date: Baze de date fizice, care sunt reprezentri pe medii de memorare a entitilor, atributelor i a relaiilor dintre ele Baze de date logice care reprezint entiti, atribute i relaii independente de modul n care datele i relaiile sunt reprezentate i memorate ntr-o baz de date fizic. Proiectarea bazelor de date logice este topica prii I. a cursului iar proiectarea bazelor de date fizice estre topica parii a II-a a cursului de fa. 2.5. Gestionarea datelor Gestionarea datelor include toate activitile care ne asigur c datele de o nalt calitate sunt disponibile pentru a produce informaia i cunotiinele dorite. Obiectivele unei gestionri a datelor sunt de a pstra datele integre, flexibile i adaptabile. Responsabilitile n gestionarea datelor includ: reprezentarea, memorarea i organizarea datelor astfel nct ele s poat fi accesate selectiv i eficient. manipularea i prezentarea datelor astfel nct ele s poat sprijini efectiv mediul utilizator. protejarea datelor astfel nct ele poat s-i pstreze valoarea. Sistemul de gestionare a bazei de date DBMS este un instrument pentru implementarea efectiv a gestionrii datelor. 2.6. Abordarea cu baze de date Aceast abordare recunoate c datele sunt absolut necesare n ciclurile de luare de decizii (fig. 2.1.). Cine decide care date vor fi fcute disponibile pentru decident? n multe organizaii, personalul care prelucreaz datele i programatorii decid care date vor fi date i cui. Dar tiu programatorii ntotdeauna de ce informaii au nevoie decidenii? Din pcate, departamentele 49

de prelucrare date prea adesea rspund la cererile de informaii de la utilizatori spunnd ba c informaia nu este disponibil ba c le-ar trebui trei luni penteru a o extrage, atunci cnd utilizatorii au nevoie de ea n ziua respectiv. Gestionarea efectiv a resurselor de date ar trebui condus de nevoile utilizator i nu de capacitile hard i soft de prelucrare date. Aceasta sugereaz, pentru nceput, c grupul de prelucrare date nu este important. Din contr, el este foarte important, dar el nu-i poate promova propria existen. El trebuie s sprijine i s rspund la cererile de informaii ale utilizatorilor. Abordarea cu baze de date se axeaz pe gestionarea datelor i nu a aplicaiilor. Ea elibereaz programatorii de multe responsabiliti n definirea i protejarea datelor, iar efortul grupului de prelucrare date pare mai eficient n ochii comunitii utilizatorilor. 2.7. Medii tradiionale Mediile tradiionale (sau orientate pe aplicaii) se focalizeaz pe procedur. Datele curg dintr-un program n altul. Timpul de via al datelor orientate pe aplicaii depinde puternic de durata programului. Fiecare program i gestioneaz propriile sale fiiere: un fiier este o colecie de date gestionate i accesate ca o unitate. El nu trebuie s fie partajabil. Relaiile ntre diferitele tipuri de date i ntre fiiere sunt stabilit de logica aplicaiei program i nu sunt parte inerent a fiierului nsui. Datele cerute pentru prelucrare ntr-un program sunt adesea necesare i n alt program, chiar dac cele dou programe nu ateapt datele n acelai format. Rezultatul este aceleai date n mai multe fiiere, deoarece fiecare fiier este esenial n proprietatea unui program (fig. 2.2.). Aceast redundan cauzeaz dificulti n corelarea i consistena datelor.

Aplicaia1

Aplicaia2

Aplicaia3

Fiier 1_A

Fiier 1_B

Fiier 2_A

Fiier 2_B

Fiier 3_A

Fiier 3_B

Fig.2.2. Abordarea orientat pe fiiere Probleme de consisten Este dificil de a pstra mai multe copii actualizate dup orice tranzacie. De exemplu, s presupunem c avei trei calendare: unul pe birou, unul n buctrie i altul n camera de zi. Care este probabilitatea ca toate s conin 50

aceai nregistrare de ntlnire? Acest tip de inconsisten afecteaz i mediile n care datele sunt duplicate n fiiere. Metoda orientat pe aplicaii implic faptul c variate fiiere de date sunt formate i organizate pentru a se potrivi cu necesitile programelor particulare (sau ale programatorilor). Fiierele tradiionale organizate pe tehnici secveniale, relative sau secvenial-indexate suport numai un numr limitat de tipuri de acces. Dezvoltarea unui alt program care s foloseasc aceleai date nseamn crearea unui nou fiier i astfel exist dou copii care trebuie s fie consistente. Probleme de corelaie Diferite aplicaii i programe folosesc scheme diferite pentru a codifica date. n consecin, ncercarea de a corela date ntre fiiere poate fi consumatoare de timp i frustrant. De exemplu, pot exista cinci (sau mai multe) seturi de coduri folosite pentru a identifica departamentele academice ntr-o universitate: un cod pe patru cifre, un cod pe cinci cifre, un cod pe patru caractere, un cod pe cinci caractere, un cod de 2 caractere urmat de trei cifre. Poate s nu existe nici un mijloc evident de a traduce schemele de codifcare astfel ca fiecare s fie corect la un moment dat dar s fie inconsistent cu un altul. ntr-o astfel de situaie un cod are 60 de intrri, altul 63, altul 58. Numai cineva de la administraie tie cheia de traducere. Inflexibilitatea inerent a abordrii tradiionale orientat pe aplicaii este raiunea pentru care informaia nu este disponibil ntotdeauna, chiar dac utilizatorii tiu c au obinut deja datele ntr-o alt form. Abilitatea de a corela informaia peste marginile aplicaiilor tradiionale i de a oferi informaii pentru toate nivelurile decidente, de la operaional prin tactic la strategic, este din ce n ce mai important. datele trebuie s fie disponibile pentru operaii zilnice ale intreprinderii, la fel ca i pentru planificarea medie i de lung durat. Abordarea cu baze de date poate umple nevoile utilizatorilor de informaie. 2.8. Medii baze de date n mediile cu baze de date, focalizarea este pe date, nu pe procedur. Resursa de date este separat de programul care se ntmpl s o acceseze astzi, ea existnd pentru a satisface nevoile de informaie ale utilizatorului att astzi ct i mine. Nu funcia de prelucrare date este proprietara datelor ci, mai degrab, utilizatorii. Resursa de date este implementat fizic astfel nct ea poate fi partajat de mai muli utilizatori. Astfel nu este nevoie de a face mai multe copii de date pentru tipuri diferite de acces, deoarece datele sunt integrate n loc de a servi numai anumite programe. Sisteme de gestiune baze de date

51

Pentru a primi un retur satisfctor la investiiile mari i crescnde n prelucrarea datelor, o organizaie trebuie s se asigure c resursa de date este bine definit i documentat, bine organizat i controlat, partajabil i relevant pentru deciziile care trebuie s se ia. Un sistem de gestiune a bazelor de date (DBMS) este un software (adesea i hardware) special proiectat pentru a proteja i gestiona bazele de date. Un DBMS poate: defini datele i relaiile ntre ele. documenta definiii de date i structuri. reprezenta, organiza i memora date pentru acces selectiv i eficient. proteja resursa de date astfel nct aceasta s fie asigurat, sigur, consistent i corect. separa nivelurile logic de fizic astfel nct schimbnd implementarea fizic a bazei de date s nu oblige utilizatorii s-i modifice viziunea lor asupra datelor. oferi partajarea datelor, dnd diferiilor utilizatori acces concurent la resursa de date.

Aplicaia1

Aplicaia2

Aplicaia3

DBMS

Fig. 2.3. Abordarea orinetat pe baze de date. Un DBMS rezid, n general, pe sistemul de operare gazd pentru a oferi accesul la bazele de date fizice. Programele sunt scrise pentru a interaciona cu bazele de date prin DBMS i nu direct. Dezvoltarea n mediul baz de date se focalizeaz pentru nceput n proiectarea bazei de date logice, apoi n implementarea ei ca o baz de date fizic, i n final, asupra programelor suportate de baza de date. Din contr, n mediul tradiional orientat pe aplicaii, datelor li se d o importan secundar. Din cauza orientrii sale, mediul baz de date este mai capabil de a se adapta la soluii noi, noi date i noi tipuri de acces. Implicaii 52

Exist mai multe implicaii de domniu larg n stabilirea mediului baze de date i n gestionarea corect a datelor. Funcia de prelucrare de date trebuie s fie capabil a rspunde mai rapid i mai eficient la nevoile de modificare de informaii. Calitatea datelor, accesibilitatea i relevana s-ar nbunti i att utilizatorii ct i personalul de prelucrare date ar deveni mai productivi.

2.9. Obiective ale abordrii cu baze de date Adoptarea unei abordri orientate pe baze de date pentru a gestiona resursele de date ale unei organizaii are mai multe obiective. 1. Protejarea valorii datelor 2. Facerea resursei de date responsabil pentru necesitile de schimbri de informaii 3. Permiterea organizaiei de prelucrare date de a suporta mai bine planurile i scopurile de afaceri ale companiei 4. Reducerea costului de nbuntire a performanei 1. Protejarea valorii datelor nseamn controlul integritii, securitii i siguranei datelor. DBMS ofer aceste faciliti. 2. Anumite DBMS-uri includ tehnici flexibile de structur de date care se pot acomoda cu noile cerine de informaii cauzate de modificarea nevoilor organizaiei. Ele ofer limbaje de interfa standard pentru a accede baza de date, elibernd astfel programatorii de necesitatea de a ti n detaliu memorarea i structura fizic a datelor. Abordarea cu baze de date folosete tehnici de modelare date care permit ca resursele de date s fie definite independent de implementarile lor fizice. Ea se bazeaz mai mult pe gestionarea semnificaiei datelor dect pe cea a faptelor. 3. Al treilea obiectiv spune c gestionarea resurselor de date i a planificrii datelor trebuie s fie aliniate cu planurile de afaceri ale organizaiei. Facilitile de teleprelucrare, cele de telecomunicaii , cele de automatizri ale locurilor de munc trebuie s duc la mrirea productivitii organizaiei. Metodologiile de proiectare logic a bazelor de date folosesc obiectivele organizaiei ca i restriciile n sistemele de informaii de planificare. 4. Al patrulea obiectiv spune c un DBMS care ofer independena datelor ne asigur toate aplicaiile pot continua s se execute chiar i dac datele memorate sunt reorganizate pentru a da o mai bun performan unor aplicaii sau dac se schimb mediile de memorare fizic, apariia unar medii noi. 2.10. Beneficii ale abordrii cu baze de date 53

Abordarea cu baze de date poate nbunti: controlul datelor accesibilitatea datelor calitatea datelor partajarea datelor sigurana datelor securitatea datelor performana

Controlul datelor. Controlul nbuntit al datelor ofer mai mult consisten n descrierea datelor, faciliteaz standardizarea conveniilor de numire date i reduce efortul de programare cerut pentru a schimba implementarea de date. Accesibilitatea datelor. Accesibilitatea datelor este abilitatea utlizatorului de a extrage informaia necesar din resursa date. Accesibilitatea datelor este mrit de ctre limbajele de interfa prietenoase i de ctre bine proiectatele ecrane de intrare i de ieire. Calitatea datelor. Calitatea datelor este msurat de ctre consistena i comletitudinea bazei de date. Conine ea date relevante pentru nevoile de decizie ale utilizatorului? Conine ea toate interrelaiile cerute ntre tipurile de date i satisface ea toate restriciile specifice? Partajabilitatea datelor. Partajabilitatea datelor este necesar pentru a ine n comun datele ntr-adevr comune. Fr partajabilitate, datele prolifereaz iar calitatea lor devine necontrolabil. Fr partajabilitate, datele sunt private i personale, fr nici un control asupra calitii lor. Partajabilitatea datelor se refer nu numai la coninutul bazei de date dar i la logica care acceseaz i gestioneaz datele. Duplicarea redus a datelor grbete accesul la date, faciliteaz programarea cerut pentru actualizarea datelor, reduce posibilitatea de a apare date inconsistente. Mai puin redundan n efortul de gestionare a datelor nbuntete, deasemenea, productivitatea personalului de prelucrare date. Sigurana datelor. Refacerea datelor (data recovery) este necesar pentru a pstra resursa de date n siguran fa de posibilele erori. Erorile pot fi detectate i corectate sau, mai bine, pot fi prevenite. Partea de dificultate n oferirea unei resurse de date sigure rezid n posibilitatea de a face datele disponibile utilizatorilor n timp ce sunt refcute dup erori.

54

Securitatea datelor. Securitatea datelor previne accese neautorizate la date. Nu toate mediile cer aceleai scheme elaborate de securitate dar aproape toate datele organizaiei trebuie s aib protecie la acces. Anumite baze de date (de ex. rapoartele Dow Jones) sunt deschise publicului numai pentru afiare, altele (de ex. Serviciile de burs numite Internal Revenue Service) cer o autentificare strict pentru afiare. Multe baze de date au restricii mult mai stringente pentru modificri n coninutul bazei de date. Performan. Performana resursei de date se refer la eficiena sa i la efectivitatea sa. Eficiena msoar utilizarea resurselor fizice ale calculatorului, iar efectivitatea msoar ct de bine sistemul de date se ntlnete cu nevoile de informaii ale utilizatorului. Aceste caracteristici sunt puternic nlnuite. De exemplu, un utilizator poate fi nesatisfcut de sistem dac timpul sau de rspuns se msoar n ore i nu n secunde sau minute. Timpul de rspuns este considerat, n general ca fiind o msur a eficienei, dar sigur el afecteaz i efectivitatea.

2.11. Costurile unei abordri cu baze de date Costurile pentru a stabili i opera un mediu baz de date includ 1. Costurile tehnologiei DBMS 2. Costurile operrii bazei de date 3. Costurile de conversie logic i fizic 4. Costurile de planificare 5. Costurile de risc Costurile tehnologiei DBMS. Software-ul DBMS este scump, costul lui variind n concordan cu mrimea calculatorului gazd. De exemplu, un DBMS care se va executa pe un mainframe (calculator central) mare poate costa uor $40.000 i uzual cost $100.000. Puini oameni vor cheltui atea bani pe un software pentru un calculator personal. Un DBMS pentru un astfel de calculator poate fi ieftin, cam $150, dar cel mai adesea este cuprins n plaja $600 - $1.500. Funcionalitatea unui DBMS pentru un micro este n general, un subset al funcionalitii unui DBMS pentru un mainframe. Costurile tehnologiei DBMS includ software, hardware i personal. Folosirea efectiv a posibilitilor software ale unui DBMS, n special n mediile cu un mainframe mare, pot cere o investiie substanial n achiziionarea i/sau antrenarea programatorilor, analitilor de sistem, administratorilor de date. Aceste costuri par s scad pe msur ce DBMS-ul devine mai familiar personalului de prelucrare date i altor tipuri de utlizatori, dar ele nc rmn semnificative. 55

Costurile operrii. Costurile operrii unui mediu baze de date includ costuri hardware pentru resursele CPU, mediile de memorare i comunicai, la fel ca i costurle software pentru ntrinerea DBMS-ului i a programelor care acced bazele de date. Folosirea unui DBMS cere n mod normal un overhead (regie) software i hardware mai mare dect n cazul folosirii organizrii convenionale cu fiiere, nu numai n timpul implementrii sistemului dar i n continuare. Multe organizaii dedic un mainframe pentru memorarea i accesul la bazele de date. Costuri de conversie. Conversia de la mediu orientat pe aplicaii la un mediu orientat pe baze de date implic: 1. datele trebuie extrase din sistemele cu fiiere convenionale i aduse ntrun DBMS 2. logica aplicaiilor trebuie modificat pentru a lucra cu facilitile DBMS. Multe organizaii nu-i pot permite s converteasc toate fiierele i programele deodat. O soluie rezonabil pentru probleme de conversie masiv este de a lsa sistemele orientate pe aplicaii s-i triasc intervalul de via (n general 7 - 10 ani) i s le converteasc pe msur ce ciclul lor de via se apropie de sfrit. Aceast abordare cere o planificare atent cci elementele de date i relaiile neidentificate n ciclurile de nceput ale implementrii pot da restructurri de baz de date costisitoare. Costuri de planificare. Pentru a asigura o longevitate a bazelor de date i o efectivitate continu a cheltuielilor legate de prelucrarea datelor, planificarea resursei de date trebuie s adreseze: controlul i metodele de transfer ntr-un mediu condus de date identificarea i stabilirea de prioriti pentru proiectele de implementare nevoile, achiziia i controlul tehnologiilor hard i soft Controlul i metodele includ standarde i proceduri, metodologii de dezvoltare sisteme, tehnici de modelare date, roluri i responsabiliti n administrarea datelor precum i metode de a selecta din tehnologiile hard i soft pentru a rspunde efectiv i eficient la nevoile de informaii ale utilizatorilor. Costuri de risc. Exist, de asemenea, i costuri de risc asociate cu un mediu baze de date. Un mediu baze de date slab proiectat poate rni (vtma) mult din comunitatea utilizatorilor, pe cnd un fiier prost proiectat ntr-un mediu orientat pe proces, n special unul pentru o aplicaie care se execut n mod batch, afecteaz utilizatorii mai puin. Fr o proiectare, structurare i ntrinere adecvat, un mediu baze de date nu poate s rspund la nevoile utilizatorilor i va fi mai scump dect face. Iar o aplicare nepotrivit a posibilitilor DBMS-ului va vtma performana pentru o lung perioad. 2.12. Indicaii pozitive i negative Un mediu baze de date ajut o organizaie cu: 56

 o nevoie de interogare interactiv i capacitate de actualizare o cretere ateptat a volumului de date o expansiune ateptat a domeniului de decizii care se suport de ctre sistemele informatice un comitet pentru gestionarea resurselor de date Nu toate organizaiile care prelucreaz date sunt gata de a folosi un DBMS efectiv pentru a implementa un mediu baze de date. Cteva din indicaiile pe care o abordare tradiional orientat pe aplicaii care sunt ns stisfctoare pentru o organizaie includ: volume relativ mici de date cu o cretere n volum ateptat mic o redundan mic sau de loc n cerinele datelor de aplicaie un mediu de prelucrare date relativ fix cu o prelucrare batch extensiv i o dorin mic pentru acces interactiv

2.13. Ce nu poate face un DBMS? Instalarea unui DBMS nu garanteaz c nenorocirile mnuirii datelor din organizaie vor lua sfrit sau c integritatea, partajabilitatea, accesibilitatea, sigurana, securitatea i performana datelor vor fi atinse. Ceea ce nseamn este c organizaia are un instrument promitor pentru a controla resursa de date. Interfee software. Anumite DBMS-uri sunt vndute ca i sistem de baz la care cumprtorul poate aduga opiuni, iar alte DBMS-uri se vnd ca i pachete complete. n ambele cazuri, DBMS-ul trebuie s interfaeze cu alt software din mediu. De exemplu, multe DBMS-uri nu au monitor de comunicaii inclus ci, mai degrab, o interfa cu un monitor. Anumite DBMS-uri au numai rudimente de faciliti de descriere de date incluse, care pot cere sisteme dicionar de date separate. Alte DBMS-uri nu au posibiliti de gestionare ecrane incluse iar organizaia de prelucrare date utilizator trebuie s cumpere sau s scrie programe screen painter. Multe organizaii se ndreapt spre pachete DBMS care ofer un evantai complet de posibiliti. Muli din vnztorii majori de DBMS-uri (de ex. Cullinet Software Inc.)

57

ofer, de asemenea, software de aplicaii care interfaeaz bine cu pachetele lor DBMS. Muli clieni gsesc aceasta compatibilitatea confortabil i atractiv, cu toate c ea cost scump! Startul. O organizaiecare cumpr un DBMS poate s nu tie cum s-l foloseasc. Anumii vnztori DBMS ofer servicii de consultan pentru a ajuta clienii s-i porneasc prima baz de date dar e rar cnd ajut la stabilirea unui mediu solid de baze de date. Organizaia trebuie apoi s aplice metodologia de dezvoltare sisteme care folosete avantajele suportului DBMS: Alte probleme. Un mediu baze de date trebuie s fie ngrijit de oameni pentru a supravieui. DBMS-ul este doar un instrument care face ngrijirea mai uoar dar el poate gsi cauzele datelor de proast calitate, nu poate reconcilia preteniile de proprietate asupra datelor, nu poate decide cine are nevoie de care informaie, nu poate decide cum ar trebui proiectate bazele de date, nu poate decide care strategie de evoluie a bazelor de date va avea cel mai mare impact asupra afacerilor, nu poate decide asupra politicilor potrivite i asupra procedurilor pentru administrarea datelor i nu poate converti un mediu orientat pe aplicaii ntr-unul orientat pe date. Mai de grab, un DBMS este chiar o parte a gestionrii cu succes a datelor. Instrumente i metode. Instrumentele i metodologiile disponibile cvare permit ca un DBMS s fie folosit mai eficient sunt: sistemele dicionar de date monitoare de performan instrumente de dezvoltare aplicaii i tranzacii utilitare pentru validarea structurilor de memorare a bazelor de date caracteristici de interogare i scriere rapoarte metode de proiectare baze de date Unele din acestea pot fi oferite de ctre vnztorul DBMS; altele trebuie scrise sau cumprate din alt parte. 2.14. Personalul Ca i n alte tehnologii, cheia succesului ntr-un DBMS const din oamenii care lucreaz zilnic cu ea. Personalul de prelucrare date i utilizatorii i partajeaz responsabilitatea pentru o efectivitate a mediului baze de date. Utilizatorii. Utlizatorii trebuie s ajute la definirea cerinelor de date i la proiectarea bazelor de date pentru a sprijini sistemele lor de informaie. Dac ei vor sta n expectativ, vor avea numai ce le este oferit. Fr influena utilizatorilor, programatorii vor ncerca numai s ghiceasc cerinele organizaiei. Administratorii de date. O funcie utilizator necesar ntr-un mediu baze de date efectiv este aceea de administrator de date. Administratorul de date (DA) asigur c bazele de date ale intreprinderii continu s ofere serviciu eficient utilizatorilor lor. Responsabilitile sale primare sunt de a 58

controla i gestiona resursa de date, de a stabili standarde de numire date, de a construi i ntreine sistemul dicionar de date, de a rezolva probleme de incompatibilitate i comunicare ntre grupuri de utilizatori, de a stabili prioriti de dezvoltare, de a planifica i implementa antrenamente pentru utilizatori, de a dezvolta materiale documentare pentru utilizatori, de a proiecta baze de date logice. Acestea cer o persoan care poate fi o legtur ntre DP i comunitile de utilizatori. Analitii. Unul din rolurile prelucrrii de date este jucat de ctre analistul de sistem, care este responsabil att pentru proiectarea bazei de date ct i pentru proiectarea aplicaiilor program. Analistul bazei de date cere nsuiri n: folosirea dicionarului de date metodologia de proiectare baz de date logic sarcini de proiectare baz de date logice, incluznd recunoaterea i catalogarea entitilor i atributelor precum i identificarea relaiilor ntre entiti. instrumente baze de date, incluznd ajutoare de proiectare baze de date, capaciti interogare/rapoarte, ajutoare de dezvoltare aplicaii i interfee utilizator comunicaii cu utilizatorii i administratorii de date Conversia la un mediu baze de date nu numai c lrgete domeniul responsabilitilor analitilor de aplicaii; el modific, de asemenea, abordarea analistului a sistemelor de dezvoiltare. Metoda de dezvoltare prototip este cea a succesului cresctor n care o baz de date este proiectat mai de grab rapid i apoi reglat n timp pentru a saitisface cerinele de efectivitate i eficien. Programatorii. n mediul baze de date programatorii sunt responsabili cu generarea codului care accede bazele de date utilizator. Principalele diferene ntre sarcinile programatorului ntr-un mediu baze de date i cele dintr-un mediu convenional orientat pe aplicaii sunt urmtoarele: Responsabilitile de codificare tradiional pentru descrierea atributelor i a caracteristicilor lor fizice sunt eliminate pentru datele rezidente n baza de date. Aceast nseamn reducerea cu 30-50% a timpului de codificare aplicaie, depinznd de ct efort este cheltuit n scrierea descrieirilor de fiiere. Limbajele de codificare tradiionale, de exemplu COBOL, sunt n general mbogite cu comenzi pentru a accede baza de date, cernd ca programatorul s ctige deprinderi i cunotiine noi. Anumite DBMS-uri ofer un limbaj programatorilor-utilizatori, care poate mpiedica nevoia de codificare n limbaje tradiionale ca i COBOL. Aceste limbaje programator-utilizator sunt distincte de orice alt facilitate disponibil de limbaj utilizator (end-user)

59

 Programatorul transfer utilizatorilor mai mult sau mai puin responsabilitate pentru a genera cod. Utilizatorii i pot scrie propriile lor accese la baza de date folosind limbaje nonprogramator adaptate. Programatorii pot deveni, de asemenea, mai productivi deoarece DBMS presupune responsabiliti pentru controale de refacere i securitate asupra datelor, eliminnd aceast codificare din ndatoririle programatorului. Dect s codifice definiii de date i rutine pentru salvare-restaurare i protecii de securitate, programatorul poate utiliza DBMS-ul pentru a face aceasta. Pregtirea programatorului (i a analistului) este cerut nu numai pentru folosirea unui DBMS particular dar i pentru a cunoate, n general, avantajele i dezavantajele mediului baze de date. Aceast pregtire conceptual trebuie fcut nainte de cea a vnztorului de DBMS care este mai detaliat. Un impact adiional, adesea traumatic, asupra programatorilor l constituie marea independen a utilizatorilor, datorat noii abiliti de a accede baza de date prin ei nii, folosind interfee end-user. Administratorii bazei de date. Administratorul bazei de date DBA a fost deja menionat n introducerea fcut n primul capitol. DBA este responsabil cu proiectarea fizic a bazei de date (proiectarea logic a bazei de date fiind responsabilitatea administratorului de date). Similaritatea n titluri a condus anumite organizaii s numeasc DA ca IRA (Information Research Administrators). DBA gestioneaz i controleaz proiectarea bazei de date fizice, evalueaz performana bazei de date, reorganizeaz baza de date aa cum e nevoie pentru a menine o performan satisfctoare, i evalueaz noi caracteristici DBMS. n multe organizaii DA i DBA sunt aceai persoan (sau grup de persoane).

2.15. Comentarii finale Principalul obiectiv al mediului baze de daet este de a oferi o mulime de date consistente, exact, accesibil, sigur, controlabil i extensibil pentru a servi nevoile de informaie ale unei comuniti de utilizatori n cretere. Investiia iniial n software DBMS, efortul de proiectare baz de date logic i fizic, persoanele superpregtite, toate i vor avea justificarea dei poate nu imediat evident. Beneficiul real al mediului de baze de date este calitatea nbuntit a datelor, precum i disponibilitatea i costurile reduse pentru suportarea n continuare a nevoilor de date a utilizatorilor. Memento 60

Accesibilitate Aplicaie program Atribut Dat Administrator de date DA Baz de date Administrator baz de date DBA Sistem de gestionare baze de date DBMS Monitor de comunicaii date Sistem dicionar de date Element de dat Independena datelor Integritatea datelor Gestiunea datelor

Entitate Fiier Informaie Integritate Baze de date logice Metodolgie Performan Baz de date fizic Cheie primar Interogare Refacere Editor de rapoarte Securitate Partajabilitate Tranzacie

Bibliografie 1. Durrel, W. Data Administration, McGraw-Hill, New York, 1985 2. Kahn, B.K. Some realities of data administration, Comm.ACM 26 (Oct. 1983) 3. Weldon, J.L. Data Base Administration, Plenum Press, New York, 1981

61

Partea 1. Proiectarea logic a bazelor de date

Capitolul 3. Procesul de proiectare al bazei de date

Succesul unui mediu de baze de date este puternic determinat de ct de bine a fost structurat logic baza de date. Acest capitol introduce concepte de baz n proiectarea bazelor de date. 3.1. Ciclu de via. Durate de via (lifecycles) Sintagma ciclu de via este folosit ca loc comun n analiza sistemelor i n prelucrarea datelor pentru o secven de faze n evoluia software-ului. Conceptele de ciclu de via sunt folosite pentru a explica dezvoltarea sistemelor, pentru a organiza proiecte de sisteme, pentru a standardiza documentaia i pentru a comunica progresul sistemelor. n general, nu exist concordan asupra ceea ce nseamn faz n ciclul de via al sistemului. Unii vorbesc de 17 faze pentru a descrie dezvoltarea sistemului, alii nu folosesc mai mult de trei faze. Multe propuneri cad pe undeva ntre aceste limite. Urmtoarele faze descriu percepia tipic a procesului de dezvoltare a sistemului: Definirea problemei: recunoaterea faptului c este nevoie de un sistem nou, identificarea scopurilor i a obiectivelor, redactarea (ntocmirea) costurilor i a restriciilor de livrare.

62

Studiu de fezabilitate: decizia asupra magnitudinii efortului de dezvoltare, urmrirea disponibilitii resurselor, estimarea costurilor i planificrii preliminare, evaluarea costurilor versus beneficii. Analiza sistemului existent: revederea documentaiei de sistem, a soft-ului i a procedurilor existente i identificarea deficienelor i insuficienelor sistemelor existente. Proiectarea preliminar: identificarea subsistemelor majore, a funciile lor, a interfeelor subsisteme, descrierea fiierelor de baz i a fluxului n sistem, analizarea mediilor de calculator gazd i de comunicaii precum i a formelor de baz pentru intrri i ieiri. Proiectarea detaliat: identificarea modulelor de codificat, dezvoltarea algoritmilor detaliai, a procedurilor, a controalelor, a fiierelor, a organizrii rapoartelor i a formelor de intrare. Programarea: scrierea codului pentru a implementa modulele identificate n faza de proiectare detaliat i testarea unitilor. Testarea: dezvoltarea datelor de test pentru integrarea sistemului, testerea sistemului, evaluarea performanei sistemului i obinerea acceptrii pentru sistem. Conversia: transferarea sistemului n starea de producie; convertirea fiierelor n noile formate, conducerea operaiilor paralele i realizarea despririi de cel vechi. Operarea: gestionarea sistemului colectarea de rapoarte de probleme, oferirea de rapoarte i de date operaionale, proiecia ncrcrilor de lucru. Documentarea, antrenarea i gestionarea proiectului se realizeaz n paralel cu aceste faze ale ciclului de via. Definirea problemei 1 Operare 9

Studiu de fezabilitate 2

Conversie 8

Analiza sistemului existent 3

Testare 7

Proiectarea preliminar 4

Programare 6 63

Proiectarea detaliat 5

Fig.3.1. Durata de via convenional pentru dezvoltarea de sisteme

Aceasta este o vedere tradiional a dezvoltrii sistemelor, care statueaz dezvoltarea sistemelor pe instruciuni precise de cerine funcionale i apoi o prelucreaz de la proiectarea preliminar la cea detaliat pn cnd sistemul terminat este livrat utilizatorilor si. Ea presupune s sistemele se nasc, triesc i apoi, eventual, se nbolnvesc i mor, dup care sunt nlocuite cu mai tinere i nbuntite generri de cod. Ciclul de via al codului aplicaiilor sistem este de aproximativ 10 ani, dar n scdere. Datele, ca i sistemele au ciclu de via. Cnd datele se nasc, ele sunt personale, cci sunt proprietatea persoanei care le-a creat i sunt complet sub controlul persoanei. Dac datele persoanei se dovedesc utile, exist o presiune care le face cunoscute din ce n ce mai multor persoane, aa c datele personale devin date partajate. Datele nu mor niciodat. Datele istorice pot fi arhivate, dar ele nu dispar. Ele nu sunt nlocuite de date noi, cu toate c pot primi roluri diferite (de ex. arhivare) atunci cnd noi date sunt achiziionate. Noile sisteme de aplicaii nu sunt create pentru a nlocui datele vechi cu date noi ci pentru a nbunti modul de prelucrare i gestionare a datelor. Atunci cnd datele sunt partajate, calitatea lor trebuie s fie mai bine controlat. Cu ct o dat se maturizeaz, nevoia de control crete. Cu ct oamenii se ncred mai mult n dat, cu att devine mai important ca datele s fie protejate, accesibile i de o nalt calitate. Recunoaterea unui ciclu de via a datelor conduce la nelegerea faptului c datele au viei distincte de cele ale sistemului construit pentru a le manipula i accesa. 3.2. Necesitatea unei metodologii de dezvoltare a sistemelor axate pe date Dac bazele de date sunt implementate folosind orientarea tradiional pe aplicaii, discutat n capitolul precedent, atunci proiectele de baze de date vor urma ciclul de via tradiional. Din nou, acest ciclu presupune c bazele de date vor muri i lucrul acesta este pregtit nc din start. O alternativ este de a lsa resursa de date s evolueze, fr a o constrnge la limitele de astzi ale aplicaiilor i organizaiilor. ntr-adevr, anumite companii mut oamenii pentru a nbunti comunicarea n cadrul organizaiei i nelegerea de ctre angajai a afacerii companiei. Marginile naturale ale aplicaiei au tendina de a mica mai ncet dect cele ale organizaiei, dar totui ele se mic. O modalitate de a implementa un mediu efectiv orientat pe date este de a adopta un cadru care 1. explic tipurile de relaii de date pertinente n mediile de baze de date.

64

2. accentueaz independena aspectelor utilizator i implementare n gestionarea datelor. 3. este independent de orice abordare de modelare date particular unui vnztor de DBMS. Un astfel de cadru este abordarea cu trei scheme pe care am prezentat-o sumar n capitolul introductiv al acestui curs. Vom reveni acum mai pe larg asupra acestei arhitecturi propuse la mijlocul anilor 70 i publicate n 1977 ntr-unraport ANSI The ANSI/X3/SPARC DBMS Framework: Report of the Study Group on Database Management Systems. O definiie de dicionar a schemei este diagram, plan, proiect, schi. ntrun context de gestionare de date, cuvntul schem nseamn ns o structur de date care este formalizat n concordan cu o mulime de reguli. O schem este un model, pictat uzual n diagrame i cteodat nsoit de descrieri n cuvinte. Abordarea cu trei scheme are trei tipuri de scheme, fiecare cu un scop specific. n plus, abordrile alternative pot fi mapate pe abordarea cu 3 scheme, ceea ce vom vedea n capitolele urmtoare. 3.3. Abordarea cu trei scheme Abordarea cu trei scheme se bazeaz pe presupunerile c: calculatoarele i utilizatorii au nevoie de a vedea aceleai date n moduri diferite diferii utilizatori au nevoie de a vedea diferite pri ale ansamblului de date este de dorit pentru calculatoare i utilizatori s fie posibil a schimba modurile n care ei vd datele nu este de dorit ca un calculator s dicteze sau s restrng modurile n care utilizatorii vd datele Astfel, este necesar s fim n stare s oferim diferitele vederi ale resursei de date. Separarea vederilor utilizator de vederile de implementare. Utilizatorii au nevoie s lucreze cu reprezentri de date care sunt independente de modurile n care datele sunt memorate i gestionate n calculator. Utilizatorul vede datele ca entiti de nivel nalt, de exemplu instrumente, vehicule, produse, clieni. Deocamdat, facilitil calculatorului (incluznd metodele de acces, sistemele de operare i DBMS-urile) sunt n stare s lucreze cu reprezentri fizice. Ele vd datele n termeni de nregistrri i fiiere, cu structuri index, B-arbori, liste nlnuinte, pointeri, adrese, pagini, etc. Aceste cerine ne conduc s concluzionm, pentru nceput, c exist dou tipuri diferite de vederi asupra datelor, vederi utilizator i vederi implementare. Vederile utilizator sunt modele ale lumii reale; ele comunic cu utilizatorii. Vederile de implementare, pe de alt parte, sunt orientate spre calculator.

65

Folosind terminologie abordrii cu trei scheme, schemele externe sunt vederi utilizator asupra datelor aa cum sunt vzute de una sau mai multe apicaii, iar schemele interne sunt vederi de implementare ale bazelor de date. Schemele conin metadate, adic, date despre date. De exemplu, NUME_CLIENT i CHARACTER(17) sunt metadate descriind valoare dat ION IONESCU. Metadatele dau semnificaii; valorile de date dau fapte; semnificaiile i faptele mpreun dau datele. Mapri interscheme. Obiectivul gestionrii datelor este de a permite utilizatorilor s accead date computerizate. Astfel, trebuie s existe mapri sau transformri intre vederile utilizator i vederile de implementare. Aceste mapri ar putea fi simple dac exist numai o schem extern i numai o schem intern. n exemplul simplificat din capitolul introductiv am considerat existena unei singure scheme interne. Totui n cazul real nu numai c exist o multitudine de scheme externe, dar i numrul schemelor interne n intreprindere poate fi mai mare. Fiecare schem extern poate fi mapat direct pe baza de date. Aceast soluie sufer, totui, atunci cnd oricare din tipurile de schem se modific. De exemplu, dac o baz de date fizic este restructurat pe disc pentru a oferi o performan mai mare, atunci maparea pe fiecare schem extern care refer baza de date poate fi afectat. Dac o schem extern este revizuit pentru a prezenta datele ntr-o manier oarecum diferit, atunci maparea pe fiecare din bazele de date referite poate fi afectat. Folosirea pamrii directe schem intern - schem extern previne independena ntre aplicaii i implementare. Factorii de calculator fizic restricioneaz astfel modurile n care utilizatorii vd datele lor. Pentru a permite diferiilor utilizatori s-i partajeze resursa de date care poate fi implementat pe mai multe baze de date fizice, abordarea cu trei scheme insereaz o vedere neutr, integrat ntre schemele externe i cele interne. n termenii abordrii cu trei scheme, aceast vedere este schema conceptual sau vederea intreprinderii sau vederea comunitii.

Vedere utilizator 1

Baza de date A

Baza de date B

Vedere utilizator 2 Baza de date C 66

Fig. 3.2. Maparea direct a vederilor utilizator pe vederile de implementare

Schema extern 1

Schema intern1

Schema extern 2

Schema conceptual

Schema intern2

Schema extern N

Schema internM

Fig. 3.3. Arhitectura cu trei scheme: o schem conceptual oferit pentru integrarea i independena multitudinii de scheme externe i interne Schema conceptual. O schem conceptual este extensibil, consistent, accesibil i partajabil i ea permite ca resursa de date s evolueze dup cum se modific i se maturizeaz nevoile. Fig. 3.3. ilustreaz relaiile ntre cele trei tipuri de scheme. Schemele i maprile ntre ele permit att independena datelor ct i suportul pentru vederi multiple. O schem intern poate fi modificat pantru a nbunti performana i pentru a profia de noile dezvoltri tehnice, fr a altera schema conceptual sau schemele externe. Schemele externe pot fi modificate pentru a reflecta schimbri n vederea unei aplicaii sau folosirea datelor, fr a afecta schema conceptual 67

sau schemele interne. Schema conceptual reprezint cunotiine despre date partajabile. Pot exista controale de acces i restricii de securitate asupra acestor date comune, dar ele nu sunt restricionate la a fi cunoscute numia de un utilizator. Schema conceptual nu descrie date personale ci, mai degrab, date partajate controlate de intreprindere. Domeniul schemei conceptuale se expandeaz n timp. Abordarea bazat pe date a proiectelor baze de date, care este discutat n seciunea urmtoare, expandeaz continuu schema conceptual pentru a include cunotiine despre tot mai multe date partajate. Un proiect baz de date n abordarea bazat pe date nu redefinete resursa de date i nici nu creaz o nou baz de date de sine stttoare. n loc de acestea, fiecare proiect trebuie s determine modul n care datele din domeniul su se leag de ceea ce este deja cunoscut din schema conceptual. Rezultatul este o resurs de date integrat al crui domeniu este expandat gradat. Resursele de date ale unei organizaii nu pot fi integrate toate deodat; sarcina trebuie executat pe buci, iar schema conceptual este integratorul. 3.4. Ciclul de via al unui proiect bazat pe date (data-driven) Obiectivul primar al ciclului de via al unui proiect bazat pe date este de a implementa bazele de date i software-ul utilizator pe baza unei scheme conceptuale integrate. Modelul de mai jos nu este singurul ciclu de via posibil pentru un proiect bazat pe date, dar este unul care a fost testat i s-a artat de succes ntr-o varietate de medii. Ciclul de via al proiectului bazat pe date nu este acelai cu cel convenional pentru dezvoltarea sistemelor, introdus la nceputul capitolului. Mai degrab, abordarea convenional construiete baze de date i fiiere separate, pe cnd abordarea bazat pe date construiete baze de date integrate. Abordarea convenional se bizuie pe declaraii complete i corecte de cerine nainte de a oferi ceva concret utilizatorului. Abordarea bazat pe date promoveaz prototiparea pentru a ajuta la descoperirea de cerine, iar utilizatorii contribuie activ i esenial n acest proces de prototipare. Prototipurile ofer posibiliti de un cost relativ sczut pentru a determina care ar trebui s fie funcia sistemului obiectiv, cci ele permit experimentarea nainte ca proiectarea s fie realizat n form final. Fazele. Fazele dintr-un proiect bazat pe date (fig. 3.4.) sunt: 1. Examinarea: a stabili domeniul i planificarea proiectului, a colecta i analiza informaii despre datele din domeniul proiectului, a dezvolta modele de date logice de nivel nalt, a identifica posibiliti de nbuntire. 2. Proiectarea: a dezvolta modele de date logice detaliate pentru noul mediu, a planifica procesul de prototipare, a redacta schia cu specificaiile tranzaciilor bazei de date. 3. Prototipare: a proiecta structura bazei de date fizice pentru prototipul iniial al bazei de date, a ncrca prototipul, a folosi prototipul pentru a 68

rafina i valida vederile utilizator i a defini tranzaciile cerute, a dezvolta tranzaciile i a transfera prototipul n starea de lucru. 4. Integrare: a integra modele de date logice prototip cu schema conceptual i a ajusta maprile interscheme. 5. Reglaj: a rafina structurile bazei de date fizice i a optimiza software-ul. 6. Revizie: a monitoriza calitatea ieirilor proiectului i a transfera prototipul din starea de pregtire n starea de producie. Aceast abordare a proiectrii se bazeaz puternic pe construcia modelelor de date care reprezint resursele de date din diferite perspective. Accentul, n fazele de examinare, proiectare, prototipare i integrare cade pe modelele de date logice, care reprezint semnificaia datelor. Prototiparea bazei de date. S notm buclele de feedback din ciclul de via din fig.3.4. Buclele de feedback din faza de prototipare permit modifcarea vederilor utilizator i a acestor contribuii la schema conceptual nainte de a muta baza de date n starea de producie. Utilizatorii sunt puternic imlpicai n faza de prototipare, nainte ca baza de date s devin o declaraie complet de cerine. Aceasta este n contrast cu ciclul de via al dezvoltrii sistemelor convenionale. care ateapt pn cnd toate cerinele sunt cunoscute i abia apoi ncepe proiectarea. Folosind acest ciclu de via al proiectului, se pot construi prototipuri i se pot pune n lucru rapid, de ordinul zilelor. Ciclul de via lucreaz, de asemenea, cu prototipuri de domeniu larg, n care trebuiesc luni de zile pentru a ajunge din stadiul de iniiere al proiectului la o baz de date n lucru. Structura fizic prototip a bazei de date poate fi modificat astfel nct ea s acopere mai eficient performanele de producie cerute. Modelul su de date logice, totui, nu este abandonat ci este integrat n schema conceptual i mapat pe structura fizic, adic pe versiunea de producie a schemei interne. Echipele proiectului. Abordarea bazat pe date n dezvoltarea bazelor de date cere echipe de proiect compuse att din personal de prelucrare date ct i din utilizatori. Dect s-i trimit cerinele lor departamentului de prelucrare date i apoi s vad ce primesc de acolo, utilizatorii (end-users) ajut la determinarea relaiilor i tranzaciilor de date. Ei sunt implicai n sistem ca i creatori i nu numai dup ce acesta a fost dezvoltat, ca i indivizi ce trebuie s triasc cu el. 3.5. Integrarea i schema conceptual Una dintre cele mai importante caracteristici ale acestui ciclu de via al dezvoltrii este aceea c fiecare proiect nu trebuie s-i recreeze propria sa baz de date separat. Mai degrab, fiecare proiect trebuie s examineze cum se leag datele din domeniul su cu datele din schema conceptual existent. Schema conceptual evolueaz dup cum apar proiecte adiionale bazate pe date. Fiecare proiect i poate crea propria baz de date fizic prototip separat, dar se urmrete integrarea acestor baze de date. Cteodat se 69

inieaz un proiect i apoi se descoper c datele necesare pentru a-l susine sunt deja disponibile i descrise n schema conceptual. Se poate dezvolta atunci o nou schem extern i ea se poate mapa pe schema conceptual care este mapat pe una sau mai multe scheme interne. Cele de mai sus nu implic crearea unei baze de date uria pentru a conine toate informaiile de producie necesare, deoarece n concordan cu abordarea cu trei scheme, schema conceptual poate fi mapat pe oricte scheme interne, fiecare reprezentnd o baz de date fizic. Aceste baze de date fizice pot fi rezidente pe mai multe calculatoare i pot fi distribuite geografic pe tot cuprinsul unei intreprinderi. Schema conceptual integreaz aceste componente distribuite. Astfel, schema conceptual integreaz vederile

70

Schema conceptual extern

Conducerea examinrii operaionale

Modele este-ca as-is Dezvoltarea proiectrii conceptuale

Modele a fi Prototiparea bazei de date i a tranzaciilor Model de date validat Integrarea proiectului model de date n schema conceptual Baza de date i tranzaciile

Noua schem conceptual Baza de date i tranzac A revedea iile calitatea de producie

A potrivi eficiena

Fig.3.4.Ciclul de via al unui proiect bazat pe date, cu prototipuri.

71

orientate pe aplicaie, reprezentate de schemele externe, sau dintr-o alt perspectiv, ea integreaz vederile orientate pe implementare, reprezentate de schemele interne. Scheme conceptuale pasive i active. Datele nu sunt integrate pn cnd legtura ermetic dintre schemele interne i externe nu este spart. Schema conceptual trebuie s controleze accesul la manipularea resurselor de date, i nu aplicaiile program. Spargerea legturii ntre schemele interne i externe nu este simpl. Exist doi pai intermediari care superimpun, la nceput a schem conceptual pasiv i apoi o vedere complet cu trei scheme n vrful legturii directe intern-extern. Motenirea majoritii mediilor de aplicaii baze de date este artat n fig.3.5.a. Schemele interne i externe sunt unite prin codul aplicaiei program. Nu exist nici o vedere intreprindere a resursei de date. Notaia cu punct mare folosit n figura 3.5. arat tipul de relaie posibil ntre entitile din cutii. Un punct mare nseamn mai multe. Fig. 3.5.a spune c o schem intern poate suporta direct mai multe scheme externe i c o schem extern poate fi suportat direct de mai multe scheme interne. n pasul 1. (fig.3.5.b) se introduce schema conceptual iar schemele interne i externe continu s fie legate direct. O schem conceptual descrie toate datele disponibile n toate schemele interne, ntr-o vedere integrat, neutr i pasiv a resurselor de date. Orice control pe care l are schema conceptual asupra resurselor de date depinde complet de politicile, procedurile i administrarea resurselor. Schema conceptual rezid ntr-un dicionar de date (vezi cap. 1.) i este descris ca un model de date logice (vezi cap. 4.). Pasul 2. (fig.3.5.c) ofer o alt punte spre integrare. Schemele externe sunt mapate pe schema conceptual iar dicionarul de date poate fi folosit pentru a determina cine accede la date. Pasul 3 (fig.3.5.d) arat o schem conceptual activ. Atunci cnd se folosete o schem conceptual activ, software-ul de gestionare date realizeaz operaiile necesare pentru a prelua o cerere utilizator n forma din schem extern i a o mapa pe schema conceptual i apoi pe cele interne. Aplicaiile program se confrunt numai cu schemele externe. O aplicaie program sau o tranzacie particular poate accesa date din mai multe baze de date, fr a se preocupa de locul unde se gsesc datele. Baza de date poate s fie distribuit pe mai multe calculatoare ale reelei. Transformrile interscheme nu se realizeaz n codul aplicaiei program ci n software-ul de gestionare date care ofer controlul activ al schemei conceptuale. Logica poate fi astfel partajat de mai muli utilizatori i de mai multe aplicaii. Cu toate c software-ul de gestionare date care s realizeze transformrile interscheme n medii de date distribuite nu exist nc n forma de producie, prototipuri au fost construite de ctre mai multe proiecte de cercetare. Eforturile depuse n construcia schemelor conceptuale pasive astzi vor fi rspltite att pe distan scurt ct i pe distan lung prin planificarea i implementarea nbuntit a sistemelor informatice.

72

Schema intern Schema conceptual descrie descrie pasiv pasiv

Schema conceptual

suport direct Schema extern Schema extern Schema intern suport direct

descrie pasiv Schema intern

suport direct Schema conceptual este este implementat accesat de prin Schema extern

Schema extern

Schema intern

Fig.3.5. Paii n controlul schemei conceptuale.

73

3.6. Planificarea pentru un mediu baze de date Probabilitatea de a implementa cu succes un mediu baze de date poate fi mrit dac se urmeaz sugestiile: 1. Recunoate c un DBMS reprezint un instrument pentru gestionarea resursei de date i nu o metod extravagant de acces la fiiere. 2. Formeaz un comitet adecvat de gestionare a resurselor. 3. Pstreaz domeniul fiecrui proiect de implementare rezonabil i reliazabil. Rezultatele vor fi disponibile n ase luni. 4. Planific procesul de dezvoltare i stabilete puncte de revizie. 5. Fazeaz implementarea (i evoluia schemei conceptuale) n incremente realiste de atins cu un plan de fazare conservator. 6. Deplaseaz responsabilitile spre experi i fii sigur c utilizatorii i definesc cerinele lor i valideaz posibilitile sistemului. 7. Antreneaz o echip tehnic n tehnologia bazelor de date, devreme i continuu. 8. Stabilete o funcie de administrare date. 9. Cnd ester potrivit, folosete prototipuri pentru a defini cerine. 10. Cere i accept ajutor de la un distribuitor de baze de date. 11. Ferete-te de ncurcturi, inclusiv de supradependena de distribuitorul DBMS. Planificarea pentru un mediu baze de date nseamn nelegerea abordrii bazate pe date n gestionarea datelor. O baz de date trebuie proiectat pentru generalitate, flexibilitate i extensibilitate. Dup ce baza de date a fost proiectat, programele orientate pe aplicaii i tranzacii care depind de acea baz de date pot fi specificate. Mai important pentru succesul pe termen lung al proiectului este neutralitatea i calitatea proiectrii bazei de date logice dect programarea. Planificarea pentru un mediu baze de date nseamn deasemenea recunoaterea faptului c un DBMS este un instrument pentrz acel mediu i nu un obiectiv. Memento ANSI/X3/SPARC Schem conceptual Bazat pe date (data-driven) Vedere intreprindere Bibliografie 1. Appleton, D.S. Data driven prototyping, Datamation, Nov. 1959, pp. 259268 2. Tsichritzis, D.; Klug, A. The ANSI/X3/SPARC DBMS framework report of the study group on database management systems, Info Systems, 1978 93 Vedere logic Schem extern Schem intern Vedere fizic Prototip Mapare Metadat Schema

Capitolul 4. Modelarea datelor logice

Modelarea datelor logice este una din cele mai puternice metode de a stabili i a menine controlul asupra resurselor de date. Exist mai multe tehnici de modelare a datelor logice. La sfritul capitolului vom enumera cteva dintre ele. Pentru a ilustra proprietile datelor unei intreprinderi pe care un model de date logice le poate captura, vom descrie o tehnic grafic, care va explica, de asemenea, i multe din celelalte abordri de modelare. Modelele de date logice pot fi reprezentate att prin diagrame ct i prin instruciuni de limbaj. Noi am ales diagramele. 4.1. Introducere Modelarea este o tehnic important pentru a defini cerinele de a analiza proiectrile 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 semnificaiei datelor ntr-un anumit domeniu de interes. Se mai numete model semantic de date deoarece accentul modelului cade pe semnificaia datelor (i.e. semantica). Un model de date logice tipic reprezint entiti, atribute si relaii. Asa cum am spus in capitolul 1, o entitate este ceva care exist in lumea reala, un concept, o persoana, un loc, un lucru sau un eveniment despre care noi vrem s pstrm fapte. Un atribut este o proprietate sau o caracteristic a unei entiti. Un model de date logice este reprezentat tipic folosind o tehnologie grafic. De exemplu, cutiile pot reprezenta entiti iar sgeile pot reprezenta relaii intre entiti (fig. 3.5.). Modele de date fizice. Modelele de fizice reprezint implementarea structurilor de date i vizeaz optimizarea resurselor, cum ar fi spaiul de memorie i timpii de acces. Elementele lor includ, n general, nregistrri fizice, fiiere, adrese i pointeri. Le vom discuta n capitolul 10. Modele de activitate. Modelele de date logice i fizice pot fi contrastate cu modele de activitate (numite i modele funcie sau modele proces) care reprezint procese (mai de grab dect date) i relaiile lor. Aceste modele se reprezint tipic printr-o notaie grafic n care cutiile (sau cercurile) reprezint activiti iar arcele ntre cutii reprezint fluxul activitilor. Fig.3.5. reprezint un model de activitate. 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 94

semnificaiile entitilor, atributelor i a relaiilor de date. Tehnicile de modelare a datelor reprezint, uzual activititile care folosesc datele. Dac nu indicm 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. 4.2. Folosirea modelelor de date logice Modelele de date au dou scopuri principale: de a facilita comunicaiile despre date i de a ajuta n descoperirea semanticii datelor. Comunicarea semnificaiei datelor. Doarece ele sunt reprezentri riguroase, modelele de date pot fi folosite pentru a transmite unei alte persoane nelegerea semnificaiei datelor. Atta timp ct persoanele ce comunic sunt familiare cu notaia folosit n model, comunicarea va fi neleas. Companiile i standardizeaz modul n care modeleaz datele, selectnd o abordare particular pentru modelarea datelor i folosind-o peste tot n eforturile lor de dezvoltare a sistemelor i a bazelor de date. Descoperirea semanticii datelor. Construirea unui model de date cere a se rspunde la ntrebri despre entiti i relaii. Fcnd aa, modelatorii descoper semnificaia datelor organizaiei, care exist indiferent dac se ntmpl sau nu ca ele s fie nregistrate ntr-un model formal de date. Entitile i relaiile lor sunt fundamentale pentru toate organizaiile; totui, semnificaia datelor poate rmne nedescoperit (i probabil prost neleas) pn cnd organizaia nu le documenteaz cu succes. Un model de date face mai uoar descoperirea semanticii datelor. Fr un mod de a reprezenta entiti i relaii, este uor s spunem. O, da, suntem cu toii de acord c aceasta arat cum se leag produsele cu distribuitorii, fr a ti ntr-adevr cu ce suntem de acord i nici nu este simplu ca distribuitorii reprezint produsele. De exemplu, anumii distribuitori pot reprezenta anumite produse; anumite tipuri de produse pot fi reprezentate numai de anumii distribuitori; distribuitorii unui produs se pot schimba n timpul vnzrii, i aa mai departe. 4.3. Aplicarea modelrii de date logice Facilitnd comunicaiile i descoperind semantica datelor, modelarea datelor este util pentru: creterea nelegerii datelor unei organizaii i a operaiilor asupra lor documentarea resurselor de date folosirea pachetelor software planificarea sistemelor de informaii proiectarea sistemelor informatice integrarea resurselor de date

95

 proiectarea i implementarea bazelor de date nelegerea datelor. Atunci cnd se dezvolt modele de date, att personalul de prelucrare date ct i utilizatorii care sunt experi n domeniul modelului, sunt necesari. Un model de date construit de personalul care prelucreaz date singuri i fcut pentru a portretiza date despre produse este diferit de unul fcut de ingineri, productori i distribuitori. De fapt, modelul de date construit numai de personalul de prelucrare date este incorect i/sau inexact. Astfel utilizatorii cruciali pentru dezvoltarea cu succes a modelelor de date. Documentarea datelor. Ca un vehicul de comunicaii, 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 msur ce pachetele software devin mai populare, companiile se ntreab tot mai des: Se va potrivi acest software n mediul nostru?. Rspunsul depinde de ce face software-ul i de modelul de date rezultat. De exemplu, un pachet de contabilitate care presupune un angajat este pltit dintr-un singur cont (al proiectului la care lucreaz) nu se va potrivi bine ntr-o companie ai crei angajai sunt pltii din mai multe conturi. Dac pachetul de contabilitate a fost bine documentat cu un model de date logice i dac cumprtorul candidat este familiar cu modelul de date logice i dac cumprtorul poate prezice mai bine dac un pachet particular de contabilitate este sau nu alegerea potrivit. Planificarea sistemelor informatice. Deoarece faciliteaz comunicaiile 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 intreprinderi. Ca parte a procesului de planificare, entitile de nivel nalt sunt apoi mapate pe uniti organizatorice (cine este responsabil pentru ce date?), activitate (ce funcii se fac pentru ce date?) i fiiere i sisteme existente (unde sunt datele stocate i gestionate?). Planificarea sistemelor informatice poate include identifcarea proiectelor de implementare i descrierea domeniului datelor care se implementeaz de ctre fiecare proiect. Proiectarea sistemelor informatice. Un proiect de implementare poate aduga la un model de planificare date de nivel nalt detalii despre atribute, volume i frecvene de acces pentru datele din domiul su. Modelul detaliat rezultat poate fi transformat ntr-o proiectare de baz de date fizic. Modelarea datelor poate fi folosit efectiv pentru a documenta mediul pertinent 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 96

mediu cere invenie. De exemplu, fig.4.1. ilustreaz n mod simplu modelele prezent i viitor. Fr 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. maini de scris) i un mediu n care responsabilitile distribuitorului au fost expandate pentru a include mai multe tipuri de produse (de ex. maini de scris, procesoare de texte, calculatoare). n general, un model de date pentru viitor nu este o pur invenie ci el imprtete mult din modelul rdcin al prezentului. Figura 4.2. arat un mediu existent n care studentii fr licena (undergraduate) nu se pot nscrie la cursuri postuniversitare i un mediu viitor n care cursurile graduate au fost deschise pentru acetia.
Produs

Produs

este vndut de Vnztor

este vndut de Vnztor

a)mediul prezent

b) mediul viitor

Fig.4.1. 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, aa cum s-a artat n capitolul 3. Dac modelele produse de ctre 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 inconsistenele i redundanele pot fi identificate i rezolvate. Modelul de date integrate dezvoltat de ctre o intreprindere este schema sa conceptual. Aceast vedere neutr de date poate fi mapat pe diferite structuri de baze de date fizice (scheme interne), aa cum sunt ele implementate i pe vederi utilizator (scheme externe), aa cum sunt ele identificate. Poate fi dificil a integra resursele de date fr a folosi modele de date. Structurile fizice, de exemplu, nu prezint o imagine complet. 97

Structurile baze de dat fizice, ca i structurile de fiiere convenionale, sunt proiectate pentru a se ntlni cu obiectivele de performan ale aplicaiilor particulare i nu pentru a oglindi structurile logice. De exemplu n figura 4.3. nregistrarea PARTE din fiierul A conine un grup repretitiv cu distribuitorii acelei pri. Aplicaiile care folosesc fiierul A acceseaz datele despre distribuitori pentru pri particulare. Fiecare parte are mai muli distribuitori asociai. Din contr nregistrarea DISTRIBUITOR din fiierul B este ntr-o structur de nregistrare care spune s fiecare distribuitor ofer mai multe pri. Aplicaiile care folosesc fiierul B acceseaz date despre pri pantru distribuitori particulari. Fiecare distribuitor are mai multe pri asociate. Student Curs postuniversitar

Fr diplom

Cu diplom

ia/este luat de

Fig.4.3a. Relaii mai muli la mai muli Combinaia acestor dou vederi indic faptul c exist mai multe relaii mai muli la mai muli ntre pri i distribuitori, aa cum se arat n fig.4.3.c. Fiecare cutie din figur reprezint o entitate iar arcul repreint o relaie ntre entiti. Punctele groase de la sfritul arcului indic c relaia este mai muli la mai muli. Aceast structur nseamn c o parte particular poate fi oferit demai muli distribuitori i c orice distribuitor poate oferi mai multe pri. Nici o structur de fiier fizic nu arat imaginea complet ci numai modelul de date logice superpus arat integrarea celor dou orientri vedere de date. Detectarea structurii logice adevrate a datelor din structurile fizice devine chiar mai grea atunci cnd relaiile inter-nregistrri sunt ngropate n codul aplicaiilor. De exemplu, dac prile din fiierul PARTI sunt legate de distribuitorii din fiierul DISTRIBUITORI printr-o tabel codificat 98

complicat ntr-o aplicaie program, atunci descoperirea relaiei logice ntre pri i distribuitori depinde de descifrarea acelei tabele. O prim abordare n proiectarea bazei de date este de a construi modelul de date i apoi de a-l folosi ca temelie pentru proiectarea i implementarea bazei de date fizice. Utilizatorii trebuie s contribuie la modelarea datelor, chiar dac ei nu trebuie s fie implicai n proiectarea bazei de date fizice. Ar putea fi util, de asemenea, s se construiasc un model de date pentru un domeniu deja suportat de ctre fiierele i bazele de date fizice. Acest model de date poate fi apoi mapat pe structurile fizice; structurile fizice sunt folosite pentru domeniu; modelul de date este folosit pentru documentarea semanticii datelor; maparea este folosit pentru a documenta modul de stocare al datelor. Modelul de date poate arta cum sunt legate datele din diferite baze de date fizice i fiiere. Student ia este luat Curs postuniversitar

Fr diplom

Cu diplom

Fig.4.3b. Relaii mai muli la mai muli Susinerea proiectrii bazelor de date fizice. Un model de date d proiectantului de baze de date fizice informaii despre ce date ar trebui incluse n baza de date, ce tipuri de relaii 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.

99

Pstrarea consistent a tehnicii. Organizaiile care folosesc modelarea datelor au avut beneficii folosind consistent o tehnic de modelare particular pentru planificarea sistemelor informatice, planificarea proiectrii i a implementrii bazelor de date. Invers, atunci cnd mai multe tehnici de modelare sunt folosite pentru aceste diferite faze ale dezvoltrii sistemelor, pot apare probleme n traducerea semnificaiei modelului construit cu o tehnic ntr-un model reprezentat ntr-o alt tehnic. 4.4. Caracteristicile tehnicilor de modelare de date logice O tehnic de modelare date tehnice trebuie: s produc diagrame grafice s ofere o reprezentare explicit a semanticii s fie la un nivel potrivit de detaliere s fie independent de DBMS s aib un suport automatizat s fie uor de nvat i folosit Diagrame grafice. Majoritatea tehnicilor de modelare de date aflate n folosin astzi ofer att un limbaj de modelare (cu o sintaxa bine definit, cuvinte cheie, etc.) ct i diagrame grafice ale modelelor. Pictogramele constau din cutii sau cercuri pentru a reprezenta entiti i din arce sau linii pentru a reprezenta relaii. Anumite tehnici folosesc forme diferite pentru diferite forme de entiti: dreptunghiuri i dreptunghiuri rotunjite pot fi folosite n acelai model pentru a distinge ntre entiti independente de identificator i entiti dependente de alte entiti pentru identificarea lor. Anumite tehnici folosesc convenii diferite pentru linii pentru diferite tipuri de relaii, de exemplu, linii unice pentru grupri i linii duble pentru relaii este un fel de. Alte tehnici folosesc un simbol special, ca de exemplu un cerc, pentru a arta atributele. Reprezentarea explicit a semanticii. Exist un domeniu de preferin personal pentru a reprezenta grafic ct mai bine semantica datelor. Anumite persoane prefer o mulime de simboluri diferite, fiecare cu o semnificaie special, pe cnd alii prefer un munr 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 semnificaiile datelor. Diagramele pot s fie neschimbtoare, dar un simbol nu poate avea mai multe semnificaii diferite. Nivelul potrivit de detaliere. O tehnic de modelare trebuie s ofere detalii la nivelul potrivit pentru folosina utilizatorului. Modelele de date pentru planificarea sistemelor informatice de nivel nalt (la nivelul companiei sau diviziei) trebuie s pstreze mai puine 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 100

pentru a construi modele care arat numai entitile i relaiile de nivel nalt, dar i modele care arat toate entitile, atributele detaliate i relaiile rafinate. Independena DBMS-ului. O tehnic de modelare de date trebuie s fie independent de orice DBMS particular i trebuie s fie capabil s reprezinte modele care pot fi suportate de o varietate de DBMS-uri. Multe din tehnicile de modelare a datelor sunt independente de DBMS. Cte o dat, tehnicile de modelare a datelor folosite cu un DBMS particular sunt considerate de nivel general, aa cum sunt modelul ierarhic, modelul reea i modelul relaional. Problema major a acestor trei tehnici este existena de limitri n semantica datelor pe care le pot reprezenta. Suport automatizat. Tehnica de modelare de date ideal are suport automatizat pentru a desena diagrame, a gsi inconsistene i redondan n modele, a combina modele din mai multe surse, a raporta pe model componente i caracteristici, i aa mai departe. A avea suport automatizat nseamn, n general, a oferi att un limbaj pentru modele specificae ct i a oferi interfee utilizator bazate pe grafic. Tehnicile de modelare de date aflate astzi n folosin sunt parial automatizate. 4.5. Concepte de baz n modelarea datelor Conceptele de baz n modelarea datelor, introduse n primele capitole, sunt conceptele de entiti, instane de entiti i atribute: o instan de entitate descrie un obiect specific, fie acesta real sau abstract este util s distingem ntre entiti i instane de entiti. instanele sunt obiecte, iar entitile clase de obeicte care au toate aceleai proprieti. proprietile unei instane se numesc atribute o entitate are un nume, care este un substantiv o entitate are unul sau mai multe atribute ale cror valori identific unic, sau disting, o instan de entitate de alta. 4.6.Entiti Entitatea este conceptul de baz n modelarea datelor i ea poate fi o clas de obiecte reale sau abstracte. De exemplu, urmtoarele sunt nume de entiti care reprezint obiecte reale:
ANGAJAT PROFESOR INVESTITIE VANZARE CONSTRUCTIE CLIENT ANGAJARE CUMPARARE DEPARTAMENT STUDENT IST_SALARIU EXP_MUNCA CAMERA PRODUS PROGRAM_GRADAT OPIUNE_CULOARE

pe cnd urmtoarele sunt nume de entiti care reprezint obiecte abstracte: Fiecare din obiectele abstracte au o semnificaie real dar ele nu sunt obiecte fizice. Tehnicile de modelare date nu disting ntre entiti reale i abstracte ci le reprezint n acelai mod. Noi vom folosi DMT - Data Modeling

101

Tehnique al D. Appleton Company, Inc. (DACOM). Ea se bazeaz pe Logical Database Design Tehnique, creat de Robert G. Brown n 1984 ntrun produs numit Janus, dezvoltat de DACOM i DBDG (Data Base Design Group, Inc.) pentru Bank of America. Aici, o entitate este ntotdeuna reprezentat de o cutie dreptunghiular. Numele entitii este scris deasupra cutiei i entitii i poate fi asigurat un numr de etichet, care apare dup nume, separat prin slash. (fig. 4.4.a). Din punctul de vedere al gestiunii datelor, este mportant s distingem ntre ocurene individuale de lucruri i clase de lucruri care au aceleai proprieti. Instanele de entiti individuale nu se reprezint niciodat ntr-un model de date, acesta fiind conceput pentru reprezentarea claselor. 4.7. Atribute Proprietile unei entiti se numesc atributele sale. Fiecare instan de entitate are cte o valoare pentru fiecare din atributele sale. Atributele se reprezint ntr-o diagram model ptrintr-o list cu numele lor n cutia entitii. (fig.4.4.b). Angajat / 49 Angajat / 49 Numr_buletin Nume_Angajat Marca_Angajat Data_Naterii Locul_Naterii Greutatea Data_Angajrii Funcia Compartimentul

Fig.4.4. Entiti i atribute Tehnicile de modelare de date presupun c dou atribute cu un acelai nume sunt acelai atribut. Astfel, dac LOCUL apare ca un atribut n entitatea ANGAJAT ct i n entitatea DEPARTAMENT, software-ul de modelare de date trebuie s semnaleze atributul ca fiind redundant sau inconsistent folosit sau chiar s tearg una din apariiile atributului. Dac dou apariii nu par a fi acelai atribut, atunci trebuie folosite nume de atribute mai precise. De exemplu, se pot folosi LOCUL_ NASTERII n entitatea ANGAJAT i LOCUL_COMPARTIMENTULUI n entitatea DEPARTAMENT. Mai 102

ncolo, vorbind despre atributele cheie strin vom arta c uneori ntr-un model, un atribut poate s apar n mai mult de o entitate. n aceste cazuri, apariiile multiple au o semnfifcaie definit i indic o relaie ntre entitile n care apar. Nuluri. Este important de tiut cnd poate avea un atribut o valoare nul. Cu toate c s-a depus mult munc n definirea tipurilor de valori nule, este suficient pentru scopurile noastre s nelegem c o valoare nul este o valoare necunoscut sau inaplicabil, i nu o valoare numeric egal cu zero! Un atribut cu o valoare nul nu are o valoare cunsocut la un moment dat dar ea exist conceptual n modelul de date. n tehnica noastr de modelare de date, un atribut care poate avea o valoare nul este adnotat cu (0). De exemplu, dac un angajat poate sau nu poate avea o valoare pentru atributul NUMAR_TELEFON_PRIVAT_# atunci atributul poate fi listat ca NUMAR_TELEFON_PRIVAT _# (0). Domenii. Valorile unui atribut sunt luate dintr-un domeniu care determin mulimea valid de valori pentru unul sau mai multe atribute. Anumite atribute pot avea toate acelai domeniu. De exemplu, atributele DATA_NASTERII, DATA_ANGAJARII, DATA_INTALNIRII sunt toate luate din domeniul DATE iar PRET_VANZARE i LISTA_PRETURI sunt luate din domeniul BANI. Un domeniu arat domeniul de valori al unui atribut. Un domeniu poate avea mai multe reprezentri alternative pentru valorile sale. De exemplu, valorile din domeniul BANI pot fi reprezentate n diverse monede (dolari, marci, lei, etc.), valorile din domeniul LUNGIMI pot fi reprezentate n cm, metri, mile, etc. iar cele din domeniul DATE ca date n diferite formate, american (luna-zi-an), european (zi-luna-an), etc. Pot exista moduri de a converti valorile dintr-o reprezentare a domeniului n alta. Domeniile pot fi deasemenea, compuneri de domenii. De exemplu, domeniul DATE ar putea fi compus din trei subdomenii LUNA, ZI si AN i la rndul lui, domeniul LUNA ar putea avea mai multe reprezentri: numerice (1, .., 12) i alfabetice (JAN, .., DEC sau Ianuarie, .. ,Decembrie). Un model de date complet dezvoltat implic domenii pentru fiecare din atributele modelului. Un model de date folosit pentru a ghida proiectarea bazei de date fizice trebuie condus pn la acest nivel. Domeniile: 1. determin operaiile permise asupra unui atribut 2. determin care atribute pot fi comparate sau folosite n combinaii 3. determin mulimea permis de valori pentru un atribut 4. pot fi folosite pentru a determina mrimile i formatele pentru cmpurile din baza de date fizic corespunztoare. 4.8. Chei candidate

103

Instanele unei entiti se disting ntre ele prin valorile cheilor lor candidate. O cheie candidat este pur i simplu o mulime de atribute ale cror valori identific unic instanele unei entiti. Pot exista mai multe chei candidate pentru o entitate. De exemplu, cheile candidate pentru entitatea ANGAJAT pot fi atributul MARCA_ANGAJAT sau colectiv NUME_ANGAJAT, DATA_NASTERII, LOCUL_NASTERII. Oricare din aceste chei candidate identific unic instanele entitii ANGAJAT. Dou instane diferite ale unei entiti nu pot avea aceai valoare a cheii candidate, deoarece astfel cheia candidat nu ar fi un identificator unic. Termenul cheie se folosete ca prescurtare pentru cheie candidat. S notm c o cheie candidat nu trebuie s fie un unic atribut. Se pot folosi mai multe atribute, ale cror valori formeaz mpreun identificatorul unic. O cheie candidat construit din mai mult de un atribut se numete cheie compus. O parte a unei chei candidate nu poate fi, de asemenea, cheie candidat. Ce este i ce nu este potrivit pentru o cheie candidat depinde de domeniul de interes. De exemplu, dac baza de date include angajai dintr-un holding avnd n componen mai multe intreprinderi, atunci probabil MARCA_ANGAJAT nu ar fi suficient pentru o cheie candidat. MARCA_ANGAJAT i NUME_COMPANIE mpreun ar putea fi cerute pentru a forma identificatorul unic. Identificarea cheilor candidate depinde, deci de datele care se modeleaz. Angajat /49 NUMAR_BULETIN MARCA_ANGAJAT(Ak1) NUME_ANGAJAT(Ak2) DATA_NATERII(Ak2) LOCUL_NATERII(Ak2) GREUTATE DATA_ANGAJRII FUNCIA NUME_COMPARTIMENT

Fig.4.5. Exemple de chei. Chei primare i chei alternate. Una din cheile candidate ale unei entiti este selectat ca fiind cheia primar. n exemplul cu entitatea ANGAJAT, MARCA_ANGAJAT ar putea fi cheia primar. Celelalte chei candidate sunt chei alternate. n exemplul nostru, DMT, cheile sunt afiate 104

n acelai mod ca i celelalte atribute n cutia entitii. Cheia primar apare deaspura liniei, iar cheile alternate apar sub linie, sufixate de notaia AK (Alternate Key). Specificaie FILE# DRAWING(Ak1) PART#(Ak1,Ak2) SPEC#(Ak2) Proprietate

SUBDIVIZIE# LOT#(Ak1) NUME_ORA#(Ak1) NUME_SUBDIVIZIE(Ak1) COD_ZON b)Cheie primar care coincide n parte cu cheie alternat

a)Chei alternate care coincid n parte

Fig.4.6. Exemple de chei care coincid n parte. Fig.4.5. arat entitatea ANGAJAT, cu NUMAR_BULETIN ca i cheie primar. MARCA_ANGAJAT este o cheie alternat iar o alt cheie alternat este colectiv, NUME_ANGAJAT, DATA_NASTERII, LOCUL_NASTERII. Deoarece pot exista mai multe chei alternate, DMT le distinge ntre ele asignndu-le cte un numr. Fig.4.6. arat dou chei alternate, notate AK1 i AK2, respectiv Fig.4.6.a cu chei alternate care coincid n parte, iar cheia primar a entitii SPECIFICATIE este FISIER#. O cheie alternat este DESEN#, PARTE# iar alt cheie alternat este PARTE#, SPEC#. Fig.4.6.b arat o cheie alternat care coincide n parte cu cheia primar. O PROPRIETATE poate fi identificat prin cheia sa primar SUBDIVIZIE#. LOT#, NUME_ORAS sau prin cheia sa alternat NUME_SUBDIVIZIE, LOT#, NUME_ORAS. Dou sau mai multe entiti pot avea acelai atribute pentru cheile lor primare. De exemplu, STUDENT i STUDENT_DSA sunt entiti diferite deoarece ele au atribute diferite. Ele pot avea, totui aceeai cheie primar, NUMAR_MATRICOL. Similar ANGAJAT i PRESTATOR_SERVICII sunt entiti diferite, dar au aceai cheie primar NUMAR_BULETIN. Conceptele de baz ale cheilor candidate ntr-un model de date sunt, astfel, urmtoarele: 1. Instantele unei entiti sunt distinse una de alta prin valorile cheilor lor candidate. 2. O cheie candidat este o mulime de unul sau mai multe atribute ale cror valori mpreun identific n mod unic instanele unei entiti. 105

3. Nici o parte a unei chei candidate nu poate fi ea nsi o cheie candidat. 4. Dac dou instane ale unei entiti au aceai valoare a cheii candidate, atunci ele sunt aceai instan. 5. Pentru o entitate pot exista mai multe chei candidate. 6. Una din cheile candidate este selectat ca fiind cheia primar. 7. Celelalte chei sunt cunoscute a fi chei alternate. 8. Fiecare instan de entitate trebuie s aib una i numai una valoare de cheie primar. 9. Un atribut cheie primar nu poate avea niciodat valoare nul. 10. Entiti multiple pot avea aceai cheie primar. 4.9. Relaii Relaiile ntr-un model de date sunt asociaii ntre entiti i sunt reprezentate n mod uzual prin linii ntre cutiile cu entiti (fig.4.7.a). Alte tehnici de modelare date folosesc un simbol special, ca un diamant, pentru a reprezenta relaiile (fig.4.7.b). Departament DEPARTAMENT

angajeaz Angajat

Angajeaz

ANGAJAT

a)Sintax reprezentat prin linie artnd o relaie

b)Sintax artnd o relaie

reprezentat de diamant Fig.4.7. Sintaxa relaiei

Exist dou tipuri de relaii, conectare i categorie. O relaie de conectare asociaz entiti diferite, de exemplu, DEPARTAMENT i ANGAJAT. O relaie de categorie asociaz entiti similare, de exemplu,

106

STUDENT, STUDENT_COLEGIU i STUDENT_4ANI. Categoriile pot fi gndite ca relaii este de tipul. De exemplu: studentul la nvmnt de lung durat este un tip de student studentul la colegiu este de asemenea un tip de student un student poate fi nscris la colegiu sau la nvmnt de lung durat. Conectrile, pe de alt parte, nu reprezint relaii de subtipuri. Interpretarea lor ar fi: departamentul angajeaz angajai angajatul lucreaz la un departament studentul este nscris la un curs cursul este frecventat de student. 4.10. Relaii de conectare O relaie de conectare: are un nume de verb are o cardinalitate, care arat cte instane ale uneia din entiti sunt legate de cte instane ale celeilalte entiti. n plus, o relaie de conectare ntre entitile A i B: poate avea o dependen de existen, ceea ce nseamn c entitatea B nu poate exista dac nu exist entitatea A. poate avea o dependen de identificator, ceea ce nseamn c cheia primar a entitii B include cheia primar a entitii A. Dependena de identificator implic dependena de existen. O relaie de conectare cu dependen de existen trebuie s adere la regula integritii refereniale: Instanele entitii B nu pot exista fr ca o instan a entitii A s existe de asemenea i valorile atributelor particulare ale entitii B trebuie s se potriveasc cu cheia primar din entitatea A. n DMT, o relaie de conectare este desenat prin linie cu punct mare. Figura 4.7.a a prezentat o relaie de conectare. Linia terminat cu un punct mare la un capt se citete: O instan a entitii DEPARTAMENT este conectat prin relaia ANGAJEAZA la mai multe instane ale entitii ANGAJAT. Mai uzual, se citete: Fiecare departament angajeaz mai muli angajai. S notm c interpretarea corect a relaiei este aceea c fiecare angajat este conectat de un singur departament. Figura.4.8. are o linie de conectare cu cte un punct mare la ambele capete. Aceast relaie poate fi citit ca mai multe instane ale entitii DEPARTAMENT sunt conectate prin relaia ANGAJEAZA la mai multe instane ale entitii ANGAJAT. Dar, n mod uzual se va citi: Fiecare departament angajeaz mai muli angajai i fiecare angajat poate fi angajat la mai multe departamente sau Exist o relaie mai muli la mai muli ntre departamente i angajai. Toate acestea sunt interpretri ale diagramei.

107

Exist o diferen major ntre relaiile de conectare unul-la-maimuli (fig.4.7.a) i relaiile de conectare mai-muli-la-mai-muli (fig.4.8.): ele nu au aceai semnificaie. Cea care reprezint corect ntre departamente i angajai este determinat de ctre regulile de afaceri din lumea real care se modeleaz. Cardinalitate. O tehnic de modelare de date care folosete linii pentru a reprezenta relaii ntr-o diagram de model utilizeaz, n mod tipic, un simbol le sfritul liniei pentru a reprezenta cardinalitatea relaiei. Cardinalitatea oricrei conectri date ntre entitile A i B este una din urmtoarele: o instan a lui A este conectat la mai multe instane ale lui B. o instan a lui A este conectat la cel puin o instan a lui B. o instan a lui A este conectat exact la n instane ale lui B. o instan a lui A este conectat la ntre n i m instane ale lui B. Departament Student graduate

angajeaz Angajat

are la dosar P Scrisoare recomandare

Fig.4.8. Relaii de conectare mai-muli-la-mai-muli

. Fig.4.9. Relaie de conectare cu

cardinalitate pozitiv (P). De exemplu, n fig.4.7.a. linia terminat fr un simbol la o cutie de entitate nseamn o instan a acestei entiti. Simbolul terminal punct mare nseamn mai multe instane ale acestei entiti. Mai precis, punctul mare nseamn 0,1 sau mai muli. Cardinalitatea unei relaii de conectare poate fi specificat mai precis prin adnotarea punctului mare. De exemplu, figura 4.9. prezint faptul c un student la DSA trebuie s aib la dosar cel puin o scrisoare de recomandare. Punctul mare este acompaniat de p, indicnd pozitiv. n anumite relaii de conectare, o instan a uneia din entiti este conectat la un anumit numr de instane ale celeilalte entiti. n acest caz n 108

DMT punctul mare se adnoteaz cu numrul respectiv. De exemplu, n figura 4.10. linia de conectare este terminat cu un punct mare adnotat cu numrul 12, i poate fi citit o instan a entitii DEPARTAMENT se conecteaz prin relaia ARE la 12 instane ale entitii BUGET_LUNAR. Mai uzual, ea se poate citi Fiecare departament are 12 bugete lunare. S notm, din nou, c fiecare buget lunar este pentru un singur departament. n anumite relaii de conectare, o instan a uneia din entiti poate fi conectat la un domeniu de numr de instane al altei entiti i n DMT se adnoteaz punctul mare cu acel domeniu de numere. Departament Luna

are 12 Buget lunar

are 28-31 Zi

Fig.4.10. Relaie de conectare cu

Fig.4.11. Relaie de conectare cu

cardinalitate exact (n = 12). domeniu de cardinalitate (28 - 31) De exemplu, figura 4.11. prezint o linie de conectare terminat cu un punct mare i intervalul 28 - 31. Acest exemplu poate fi citi ca Fiecare lun are ntre 28 i 31 de zile. Ocazional, un domeniu de cardinalitate este zero-la-unu. DMT noteaz acest caz special printr-un punct mare cu un z, aa cum se vede n fig.4.12., care poate fi citit ca Fiecare manager are fie o secretar, fie nici una. S notm c interpretarea corect a modelului implic de asemenea c o secretar nu lucreaz pentru mai mult de un manager. Alte convenii pentru a reprezenta domenii de cardinalitate sunt prezentate n figurile 4.13.a i 4.13.b. Prima poate fi citit: Fiecare curs poate avea maximum 45 de studeni iar fiecare student se poate nscrie la maximum 7 cursuri. A doua poate fi citit Fiecare profesor ine cel puin dou cursuri i fiecare curs este inut de cte un singur profesor. Manager are Z 109 Secretara

Fig.4.12. Relaie de conectare cu cardinalitate zero-la-unu (2)

S notm c un model cu cardinalitate reprezint mai explicit semantica datelor dect o face un model fr cardinalitate i c, cardinalitatea este o form de restricie care poate fi folosit pentru a verifica i menine calitatea datelor. Grupa Profesor

<=7 inroleaz <=45 Student

Pred >=2 Grupa

a) Domeniu de cardinalitate n relatii de conectare mai-multi-lamai-multi Fig.4.13. Exemple de cardinaliti.

b) Cardinalitate minim ntr-o relatie de conectare unul-la-maimulti

110

Cardinalitatea unei relaii este o aseriune asupra instanelor entitii. Aceast aseriune poate fi aplicat atunci cnd baza de date este actualizat, pentru a determina dac actualizrile violeaz sau nu regulile stabilite de semantica datelor. De exemplu, s considerm aseriunile fcute de cardinalitatea relaiilor din fig.4.13. i 4.9. O actualizare care ncearc s adauge al 46-lea student la un curs va fi respins, la fel ca una care ncearc s adauge un al 8-lea curs la un student sau o actualizare care ncearc s tearg singura scrisoare de recomandare de la dosarul unui student. Rezolvarea relaiilor mai-muli-la-mai-muli. Relaiile mai-mulila-mai-muli sunt rezolvate (imprite) n componente relaii unul-la-maimuli atunci cnd modelul de date este rafinat pentru a prezenta mai multe detalii. Rezoluia acestor relaii este prezentat n fig.4.14. care sparge relaia mai-muli-la-mai-muli ntre entitile GRUPA i STUDENT din fig.4.13.a n dou relaii unul-la-mai-muli care au aceai entitate de baz. O instan a acestei entiti de baz INSCRIERE reprezint nscrierea unui student la o grup de studii. Fiecare grup are mai multe nscrieri din acestea, pn la numrul maxim de 45. Fiecare student are mai multe nscrieri, pn la maximum 7. Grupa Student

are <=45

se nroleaz n <=7 nrolare

Fig.4.14. Rezoluia relaiei mai-muli-la-mai-muli din fig.4.13.a n dou conectri unul-la-mai-muli. 111

Un alt exemplu de rezolvare a relaiei mai-muli-la-mai-muli este prezentat n fig.4.15. Aici conectarea mai-muli-la-mai-muli ntre entitile CONSILIER i CURS este spart n dou relaii unul-la-mai-muli care partajeaz o aceai entitate ASISTENT. O instan a acestei entiti de baz reprezint un sfat al consilierului unei clase particulare cu un asistent. Entitatea de la un capt al relaiei unul-la-mai-muli (unul) se numete uzual entitatea tat a relaiei iar entitatea de la captul mai muli se numete entitate copil (sau fiu). CONSILIER CONSILIER CURS

Z conduce

supervizeaz

are

CURS

ASISTENT

a)

b)

Fig.4.15. Rezoluia unei relaii zero-sau-unul-la-mai-muli.

Atribute cheie strin. Dup ce relaiile mai-muli-la-mai-muli au fost rezolvate, pot fi identificate atributele cheie strin. Un atribut al unei entiti care se gsete n cheia primar a unei alte entiti se numete atribut cheie strin. Partajarea acelui atribut indic o relaie ntre entiti. Regula este: Cnd dou entiti sunt asociate (nlnuite) printr-o relaie de conectare, atributele de cheie primar a entitii tat migreaz n entitatea fiu, devenind acolo atribute de cheie strin. 112

S notm c nu apare nici o migraie cu o relaie de conectare mai-muli-lamai-muli, deoarece nu se poate face o distincie ntre entiti tat i fiu. De exemplu, n fig.4.13.b atributul cheie primar al lui PROFESOR, ID_FACULTATE migreaz n entitatea CURS, devenind un atribut de cheie strin. n fig.4.9. atributul cheie primar al lui STUDENT_DSA MATRIC#, migreaz n entitatea SCRISOARE_DE_RECOMANDARE, devenind acolo un atribut de cheie strin. Cheile nu pot, totui, s migreze prin relaia maimuli-la-mai-muli din fig.4.13.a. Unul din testele de validitate ale atributului de cheie strin este: O instan de entitate poate avea numai o singur valoare pentru fiecare din atributele sale de cheie strin. Aceasta indic direcia n care migreaz cheia ntr-o relaie. De exemplu, dac cheia primar a lui CURS - CURS#, SECTIE# - trebuie s migreze n PROFESOR, acolo devenind un atribut cheie strin, acest test nu va fi satisfcut. Fiecare profesor pred cel puin dou seciuni de curs i deci fiecare instan a entitii PROFESOR trebuie s aib cel puin dou valori pentru CURS#, SECTIE#. Regula este: Cheia primar migreaz ntotdeauna de la entitatea din partea cu o instan la entitatea din partea cu mai multe instane ale unei relaii, devenind acolo o cheie strin. Ora Ora Cod_ora

Este plecare pentru

Este sosire pentru

Este plecare pentru

Este sosire pentru Segment zbor

Segment zbor

ZBOR# COD_ORA_PLECARE.COD_ORA(FK) COD_ORA_SORIRE.COD_ORA(FK) ORA_PLECARE.PLANIFICARE ORA_SOSIRE.PLANIFICARE TIP_AVION

a) dup relaii conectnd dou entiti b)Folosirea numelor de roluri pentru COD_ORA ca i atribute 113 cheie strin

Fig.4.16. Nume de roluri.

Nume de roluri. Cnd exist mai mult de o relaie ntre o pereche de entiti, atributelelor cheie strin li se asigneaz nume de roluri. Acestea permit distincia ntre diferitele apariii ale unui nume de atribut cheie strin ntr-o entitate. Deoarece entitile migreaz n diferite relaii, ele au semnificaii diferite. De exemplu, fig.4.16.a modeleaz dou relaii gsite ntr-o planificare de zboruri. Fiecare ora poate s fie ora de plecare pentru mai multe segmente de zbor i ora de sosire pentru alte segmente de zbor. Fiecare segment de zbor are exact un ora de plecare i un ora de sosire. Modelul prezint dou entiti, ORAS i SEGMENT_ZBOR de dou ori. Cheia primar a lui ORAS migreaz n SEGMENT_ZBOR de dou ori, o dat prin relaia ESTE_PUNCT_DE_PLECARE_PENTRU i o dat prin relaia ESTE_PUNCT_DE_SOSIRE_PENTRU. Pentru a distinge ntre cele dou apariii ale atributului cheie strin COD_ORAS n entitatea SEGMENT_ZBOR, unei apariii i este dat numele de rol COD_ORAS_PLECARE iar celeilalte i este dat numele de rol COD_ORAS_SOSIRE. Fr nume de roluri, COD_ORAS ar fi aprut de dou ori n SEGMENT_ZBOR. O ocuren ar fi fost eliminat de regula acelai nume, aceeai semnificaie i una din relaii ar fi fost pierdut n proces. Fig.4.16.b prezint mai complet numele de roluri asumate de ctre atributul COD_ORAS n entitatea SEGMENT_ZBOR. DMT folosete convenia de punctare a numelui de rol, de exemplu COD_ORAS_PLECARE.COD_ORAS pentru a arta, de asemenea, numele su surs. Dependena de existen. O relaie de conectare poate avea dependen de existen. Dac exist o dependen de existen ntre dou entiti A i B, atunci regula este: Fiecare instan a entitii B trebuie s aib o instan corespunztoare a entitii A. Entitatea B se spune a fi dependent n existen de entitatea A. S notm c entitatea A trebuie s fie tatl entitii B n relaia de conectare i c o dependen de existen apare cnd cheia strin pentru relaie nu poate fi nul. Dac exist o dependen de existen n fig.4.13.b asociat cu relaia pred atunci o instan de entitate GRUPA nu poate exista fr a fi

114

asociat cu o instan de entitate PROFESOR. Fiecare instan de entitate GRUPA trebuie s aib un non-nul FACULTATE# pentru profesorul su. Dac exist o dependen de existen n fig.4.9. asociat cu relaia are la dosar, atunci o instan de entitate SCRISOARE_DE_RECOMANDARE nu poate exista fr a fi asociat cu o instan de entitate STUDENT_DSA. Fiecare instan de SCRISOARE_DE_RECOMANDARE trebuie s aib un non-nul MATRIC# pentru studentul asociat cu ea. Relaiile de conectare mai-muli-la-mai-muli nu evideniaz dependene de exiaten. De exemplu, nu exist nici o dependen de existen asociat cu relaia inscrie din fig.4.14. a. O grup va exista chair fr studeni nscrii n ea (cel puin pn cnd este tears) i un student va exista chiar dac nu este nscris n nici o grup. S notm, totui, c exist dependen de existen n rezoluia acestei relaii mai-muli-la-mai-muli din fig.4.14. O instan INSCRIERE nu poate exista fr a fi asociat cu o instan GRUPA i cu o instan student. Un alt exemplu de relaii de conctare fr dependen de existen este prezentat n fig.4.15.a. Acest model poate fi citit astfel: un consilier poate conduce mai multe cursuri, dar un curs nu poate fi condus de mai mult de un consilier. Astfel, un curs exist dac este condus sau nu de un consilier iar un consilier va continua s existe dac conduce sau nu un curs. Aceast relaie poae fi rezolvat n dou relaii care au dependen de existen, aa cum se vede n fig.4.15.b. Aici entitatea ASISTENT este dependent de existena att a entitii CONSILIER ct i de cea a entitii CURS. O persoan nu poate fi asistent dac nu i se asigneaz un curs de ctre consilier. S notm c procesul de rezoluie folosit aici este acelai cu cel folosit n obinerea fig.4.14 din fig.4.13.a. Relaiile mai-muli-la-mai-muli i relaiile de conectare zero-sauunul-la-mai-muli sunt numite uneori relaii nespecifice, deoarece ele mascheaz dependenele de existen. Aceste relaii sunt specificate prin rezoluia unei relaii nespecifice n dou relaii specifice, transformnd o conectare mai-muli-la-mai-muli n dou conectri unul-la-mai-muli. O conectare zero-sau-unu-la-mai-muli devine o relaie unu-la-mai-muli i o relaie unu-la-zero-sau-unu. Notm cu E1 entitatea tat a unei relaii i cu E2 entitata fiu. Cheia primar a lui E1 este mulimea de atribute A, care este deasemenea o cheie strin n E2. Dac atributele A din E2 nu pot fi nule, atunci E2 este dependent de existena lui E1. Dac exist o instan a lui E2, ea trebuie s fie asociat cu o instan a lui E1. Pe de alt parte, dac unul sau mai multe atribute ale lui A n E2 pot fi nule, atunci E2 nu este dependent de existena lui E1. O instan a lui E2 poate exista fr ca ea s fie asociat cu o instan a lui E1. Dependena de identificator. O relaie de conectare poate avea dependent de identificator. Dac exist o relaie ntre entitile A i B, atunci 115

entitatea B se zice dependent de identificator de entitatea A, dac i numai dac: cheia primar a lui A, aprnd ca un atribut de cheie strin n B, este complet coninut n cheia primar a lui B. Cheia migratoare a entitii A este astfel o parte esenial a identificatorului entitii B. n DMT, distincia ntre relaiile care au dependen de identificator i cele care nu au, este fcut prin linie continu i linie punctat. De exemplu, modelul din fig.4.14. cu atributele de chei este prezentat fig.4.17. Ambele relaii sunt relaii de identificare iar cheile primare apar ambele n cheia primar a relaiei fiu. GRUPA SECIE# CURS# STUDENT MATRIC#

INROLARE SECIE# CURS# MATRIC#

Fig.4.17. Model de date logice cu dou relaii de conectare de identificare.

n fig.4.18. una din relaii are dependen de identificator i una nu o are. Cheia primar a lui PO_LINE include cheia primar a lui PO dar nu include cheia primar a lui PART. DMT are o opiune care suprim tiprirea atributelor de cheie strin pe diagrame. Atunci cnd aceast opiune se folosete, trebuie s existe o distincie, alta dect plasarea atributelor, pentru a indica dependena de identificator. Aici distincia este fcut prin arce solide sau ntrerupte. O entitate care nu este dependent de identificator de nici o alt entitate este desenat cu coluri drepte, iar o entitate care este dependent de identificator de cel puin o alt entitate este desenat cu coluri rotunjite. Entitile care nu sunt dependente de identificator pot sta singure, dar entitile dependente de identificator sunt ntotdeauna gsite cu alte entiti. S notm c dependena de identificator implic ntotdeauna dependena de existen.

116

Integritatea referenial. Integritatea referenial este o restricie care trebuie s fie satisfcut pentru relaii de conectare cu dependen de existen (sau de identificator). Integritatea referenial este aseriunea c, dac entitatea B este dependent de existena entitii A, atunci valorile atributelor de cheie strin ntr-o instan a entitii B trebuie s fie egale cu valoarea cheii primare din instana asociat a entitii A. De exemplu, dac ANGAJAT este dependent de existen de DEPARTAMENT n fig.4.7., integritatea referenial spune c: pentru orice instan a entitii ANGAJAT, valoarea atributului de cheie strin DEPARTAMENT# trebuie s se potriveasc cu valoarea de cheie primar DEPARTAMENT# din instana de entitatea DEPARTAMENT asociat. Similar, pentru relaiile din fig.4.15.b. dac ASISTENT este dependent de existena lui CONSILIER i CURS, atunci integritatea referenial spune c pentru fiecare instan a entitii ASISTENT, valoarea atributului de cheie strin CONSILIER_ID trebuie s se potriveasc cu valoarea din cheia primar din instana de entitate CONSILIER asociat, i pentru fiecare instan a entitii ASISTENT, valoarea atributului CURS# trebuie s se potriveasc cu valoarea din cheia primar din instana de entitate CURS asociat Po Po# Part Part#

conine Po_Line Po#(Fk) Line# Part#(Fk) Qty

apare n

Fig.4.18. Model de date logice cu o relaie de identificare i una de neidentificare.

117

Reprezentarea restriciei de integritate referenial ntr-un model de date este important deoarece 1. un model care exprim restricia de integritate referenial reprezint mai explicit semantica datelor dect unul care nu o face. 2. integritatea referenial poate fi folosit pentru a verifica i menine calitatea datelor. Integritatea referenial este o aseriune despre instanele entitilor. Aceast aseriune poate fi aplicat atunci cnd baza de date este actualizat, pentru a determina dac actualizarea violeaz regulile semantice stabilite. De exemplu, o actualizare a bazei de date modelat n fig.4.7. poate fi rejectat dac ea ncearc s adauge o instan ANGAJAT cu un DEPARTAMENT# care nc nu exist ca i o cheie primar a unei instane din DEPARTAMENT. Orice actualizare care leag o instan de ANGAJAT cu o instan de DEPARTAMENT, fr o potrivire de DEPARTAMENT# va fi de asemenea rejectat. O actualizare va fi rejectat dac ea ncearc s tearg o instan de DEPARTAMENT pentru care continu s existe instane de ANGAJAT. Instanele de ANGAJAT nu pot s existe fr a fi asociate cu instane de DEPARTAMENT. S notm c modificarea valorii DEPARTAMENT# din instana ANGAJAT este o modalitate valid de a asocia instan cu o alt instan DEPARTAMENT. Angajat

Tip_compensaie

Angajat cu ora

Angajat cu salariu

Fig.4.19.a. Exemple de relaii de categorie. 118

Pentru baza de date modelate n fig.4.15.b., urmtoarele actualizri vor fi rejectate: adugarea unei instane ASISTENT pentru care ori CURS# ori CONSILIER_ID nu se potrivete cu cheia dintr-o instan CURS sau CONSILIER existent. legarea unei instane ASISTENT de o instan CURS sau CONSILIER fr o potrivire n CURS# respectiv CONSILIER_ID. tergerea unei instane CURS pentru care exist o instan ASISTENT. tergerea unei instane CONSILIER pentru care exist instane ASISTENT. 4.11. Relaii de categorie Relaiile de conectare asociaz tipuri diferite de entiti, pe cnd relaiile de categorie asociaz entiti similare. O relaie de categorie are urmtoarele caracteristici: 1. este numit TREBUIE_SA_FIE_UN sau POATE_FI_UN. 2. leag o entitate generic de o entitate subtip. 3. are o cardinalitate unu-la-zero-sau-unu. 4. are un discriminator de subtip. 5. atributele entitii generice sunt motenite implicit de entitatea subtip. 6. are dependen de existen. 7. trebuie s se conformeze restriciei de integritate referenial. 8. poate avea dependen de identificator. DMT folosete un cerc pentru a reprezenta o relaie de categorie. Fig.4.19.a. modeleaz o situaie n care exist dou tipuri de angajai, cu ora i salariai. Fiecare angajat poate fi un angajat cu ora sau un angajat salariat, dar nu poate fi amndou la un loc. Atributele entitii generice ANGAJAT sunt aplicabile, de asemenea, entitilor subtip ANGAJAT_CU_ORA i ANGAJAT_CU_SALAR. Fig.4.19.b. modeleaz o alt situaie n care exist trei tipuri de angajai student, profesor i personal administrativ. Un angajat poate fi un student, un profesor, un membru al personalului administrativ sau nici unul dintre acetia. n lumea real, o instan a entitii STUDENT reprezint exact acelai obiect ca i instana entitii ANGAJAT cu care ea este asociat n aceast relaie. Pe de alt parte, o relaie de conectare asociaz ntotdeauna instane care reprezint obiecte diferite din lumea real. De exemplu, o instan SEGMENT_ZBOR din fig.4.16. reprezint un obiect din lumea real diferit de cele reprezentate de instanele ORAS cu care el este legat. Discriminator de subtip. O diagram a unei relaii arat entitatea generic n vrf, cu un cerc coninnd un atribut al entitii generice ale crei valori determin n ce subtip rezid o instan de entitate dependent 119

particular. Acest atribut se numete discriminator de subtip. n fig.4.19.a disciminatorul de subtip este atributul TIP_COMPENSATIE ale crei valori determin dac un angajat particular este angajat cu ora sau permanent. n fig.4.19.b. disciminatorul de subtip este atributul STATUS, a crui valoare determin cnd un angajat particular este un student, un profesor sau un administrator. S notm c discriminatorul de subtip este un atribut al entitii generice, i nu al relaiei.

Angajat

Status

Student

Profesor

Administrativ

Fig.4.19.b. Exemple de relaii de categorie.

O mulime de relaii de categorii cu acelai discriminator de subtip se numete clas de categorii. Fig.4.19.a. are dou relaii de categorii, ambele ntr-o clas. Fig.4.19.b. are trei relaii de categorie, toate n aceai clas. Fiecare cerc de categorie ntr-o diagram DMT reprezint o clas de relaii de categorie. O entitate poate avea mai muli discriminatori de subtip, ca n fig.4.20. Aici exist dou subclasificri de cldiri: TIP_FOLOSIRE dintr-o instan CLADIRE indic dac aceasta este rezidenial, birouri, magazine sau alte scopuri; TIP_CONSTRUCTIE indic dac este din crmizi, prefabricate sau altele. O instan cladire dat poate avea valori att pentru TIP_FOLOSIRE ct i pentru TIP_CONSTRUCTIE, de exemplu o

120

cladire din caramid pentru birouri sau o cladire din prefabricate rezidenial. Punnd mpreun modelele din fig.4.19.a. i 4.19.b. obinem de asemenea, o entitate cu mai mult de un singur discriminator de subtip. Exclusivitate mutual. Un discriminator de subtip poate avea numai o valoare pentru orice instan a entitii generice. Astfel, o instan a entitii generice poate fi legat dfe o singur instan de subtip ntr-o clas de categorii. n concordan cu fig.4.20. o construcie nu poate fi att una de birouri ct i una rezidenial, i nici nu poate fi construit att din crmizi ct i din prefabricate. Dac aceste reguli nu sunt adevrate, atunci modelul nu reflect corect realitatea. Acest model nu reprezint o cladire care e parial de birouri, parial rezidenial i parial magazine. Cldire

Tip construcie Tip folosire

Cldire rezidenial

Cldire de birouri

Cldire de vnzare

Cldire din crmizi

Cldire din prefabricate

Fig.4.20. Exemplu de entitate cu dou ierarhii de categorii.

Similar, modelul din fig.4.21.a. spune c o persoan poate fi sau un student sau un profesor i nu poate prezenta situaia n care o persoan poate fi att profesor ct i student. Fig.4.21.b. modeleaz aceast situaie adugnd o regul atributului discriminator, indicnd c instana PERSOANA poate avea mai mult de o valoare pentru STATUS. Aceast convenie pentru a

121

relaxa restricia de exclusivitate mutual este rar folosit, o categorizare mai judicioas eliminnd deasemenea problema. Exclusivitatea mutual poate fi folosit pentru a verifica i menine calitatea datelor. Astfel, o actualizare a bazei de date modelate n fig.4.20. va fi rejectat dac ea ncearc s descrie o cldire att de birouri ct i rezidenial. Totalitate. O clas de categorii se spune a fi total dac orice valoare valid a discriminatorului de subtip are o etichet subtip corespunztoare. DMT reprezint o clas total de categorii desennd o linie dubl sub cercul de relaie de categorie.

Persoana

Persoana

Status Student Profesor Student

Status(>=0) Profesor

a) Subtipuri mutual exclusive

b) Relaxarea regulii de exclusivitate mutual prin adugarea regulii >=0 pentru

Fig.4.21. Exemple de ierarhie de categorie. atributul discriminator De exemplu, fig.4.22. arat o mulime complet de subtipuri de student. Domeniul valorilor pentru discriminatorul de subtip i entitile subtip prezentate n model determin mpreun dac o clas de categorii este total.

122

Dependena de existen. Dependena de existen are loc ntotdeuna ntr-o relaie de categorie. Pentru ca o instan a unui subtip s existe, ea trebuie s aib o instan asociat a entitii generice. O cladire de birouri nu poate exista fr a fi o cldire; un angajat cu ora nu poate exista fr a fi un angajat. Dac pentru un discriminator de subtip se permite a avea o valoare nul i/sau mulimea valorilor este mai mare dect numrul subtipurilor (adic, clasa categoriilor nu este total) atunci existena unei entiti generice nu implic necesar existena entitii subtip corespunztoare. De exemplu, o valoare nul n TIP_CONSTRUCTIE din fig.4.20. va indica faptul c o instan dat de CLADIRE nu este nici din caramizi, nici din prefabricate. Tipul de construcie poate fi de asemenea necunoscut sau nedisponibil.

Student

Status

Doctorand

Undergraduate

Neclasificat

Fig.4.22. Exemple de relaii de categorie cu mulime total de subtipuri. Fiecare valoare a acestui atribut discriminator are o entitate subtip potrivit.

Integritatea referenial. O relaie de categorie trebuie s se conformeze ntotdeauna restriciei de integritate referenial. Cheile primare migreaz pentru a deveni atribute de cheie strin n relaiile de categorie n acelai mod cum o fac i n relaiile de conectare. O instan de entitate subtip

123

trebuie s fie asociat cu o instan de entitate generic a crei valoare de cheie primar se potrivete cu valoarea atributului de cheie strin a subtipului. Dependena de identificator. O relaie de categorie poate sau nu poate avea dependen de identificator. De exemplu, fig.4.23. prezint o situaie n care dependena de identificator nu are loc. Entitatea generic este INVESTITIE, cu cheia primar DATA, SURSA i TIPUL. Entitile subtip sunt BURSA, CONTRACT, IMOBILIAR i C.D. Cu toate c ele motenesc cheia primar a entitii generice (la fel, implicit, restul atributelor sale) atributul de cheie strin nu este parte a cheilor primare ale subtipurilor. Acest exemplu arat c o entitate subtip poate fi la rndul ei o entitate generic. Entitatea IMOBILIAR are dou entiti subtip, PROP_COMERCIALA i PROP_REZIDENTIALA. Dac se cere pentru toate relaiile de categorie a avea dependen de identificator atunci va fi posibil s modelm numai ierarhii de categorii i nu reele de categorii. Toate exemplele prezentate au fost n fapt ierarhii. Investiie Data Sursa

Tip. investiie

Bursa Companie Grad Data(Fk) Sursa(Fk)

Contract Contract# Data(Fk) Sursa(Fk)

Imobiliar Locaia Data(Fk) Sursa(Fk)

C.D. C.D.I.D Data(Fk) Sursa(Fk)

Prop_comercial Locaia(Fk)

Prop_rezidenial Locaia(Fk)

124

Fig.4.23. Exemplu de ierarhie de categorii.

4.12. Alte tehnici de modelare disponibile n literatura tehnic despre baze de date au fost propuse multe tehnici de modelare date, dar numai cteva sunt folosite de ctre companii i organizaii. n aceast seciune vom descrie tehnicile cele mai cunoscute. Modelul reea. Modelul reea a fost dezvoltat de ctre CODASYL (Conference on Data System Languages) DBTG (Data Base Task Group) la sfritul anilor 60 i la nceputul anilor 70 i de ctre Cincom Systems, Inc., cu sistemul su comercial de gestiune a bazelor de date TOTAL. Modelul reea ncearc s ridice preocuparea de gestiune a datelor deasupra nivelului de structuri de fiiere fizice, considernd structuri logice. Astzi, el nu este considerat n totalitate a fi o tehnic semantic de modelare a datelor deoarece este puternic legat de capacitile unui DBMS particular i are posibiliti limitate de expresii semantice. El lucreaz cu tipuri de nrgistrri. item-uri de date i tipuri de mulimi care sunt n mare analoage cu entiti, atribute i relaii. Pn la sfritul anilor 70 exista un amestec puternic de parametri de baz de date logic i fizic ntr-un singur model reea. l vom studia n detaliu n capitolele 7 i 12. Modelul relaional. Modelul relaional a fost introdus de ctre E.F. Codd de la IBM la nceputul anilor 70 i el ofer o abordare simpl i totui riguroas matematic a modelrii datelor. El lucreaz cu datele n termeni de tabele iar relaiile n tabele se formeaz prin partajarea atributelor, uzual prin atribute de cheie strin. Modelul relaional a reinut atenia multor cercettori n baze de date i este nc n vog prntre DBMS-uri comerciale. Dar, n ciuda largii sale folosiri, astzi modelul relaional nu mai este n general considerat o tehnic logic de modelare date, n primul rnd datorit posibilitilor sale reduse de exprimare semantic. l vom studia n detaliu n capitolele 5, 6 i 11. Modelul Entitate-Mulime. Una din tehnicile de nceput n modelarea logic a datelor a fost modelul entitate-mulime introdus n 1973 de ctre cercetorii de la IBM. Acest model recunoate entitile ca i colecii de perechi nume-entitate = valoare-entitate. Ne exist conceptul de atribut, orice (de ex: nume, vrst, departament) este o entitate. Relaiile sunt binare, adic orice relaie poate asocia numai dou entiti. O dezvoltare a acestei tehnici este produsul Information Analysis (IA) al lui Control Data Corporation.

125

Modelul Entitate-Relaie. A fost introdus n 1975 de ctre Peter Chen ca o alternativ la modelele relaional, reea i entitate-mulime. El deseneaz entiti, atribute i relaii. Relaiile sunt n-are, adic orice relaie dat poate asocia una, dou sau mai multe entiti iar un model poate prezenta dependena de existen ntre entiti. Modelul abstractizrii al lui Smith. Prima constribuie a acestui model publicat n 1977 este distincia ntre relaiile de agregare i generalizare, pe care noi le denumim relaii de conectare i de categorie. Modelul introduce convenia ca entitile s aib un nume de substantiv i include o notaie grafic pentru reelele agregare i generalizare. Modelul de date semantice. Modelul de date semantice publicat n 1978 introduce un alt nivel de explcitare n reprezentarea constructelor de modelare date loghice, recunoscnd trei tipuri de entiti (numite clase): obiecte concrete (fizice), abstractizri (generalizri) i agregate (colecii omogene). Acest model introduce, de asemenea conceptul de evenimente, care sunt aciuni la care particip obiectele i identific trei tipuri de atribute. IDEF1. IDEF1 (ICAM - Integrated Computer-Aided Manufacturing - Definition Language -1) a fost dezvoltat la sfritul anilor 70 sub auspiciile U.S.Air Force. El este un hibrid practic ntre modelul entitate-relaie i modelul relaional i are metode companion pentru modelarea activitilor IDEF0 i a dinamicii sistemelor IDEF2. O generaie ulterioar a lui IDEF1 este IDEF1-Extended (IDEFIX) i este derivat din DMT, care i are rdcinile n IDEF1. Modelul de date funcionale. Modelul de date funcionale i limbajul su de modelare DAPLEX, publicate n 1981 ofer un cadru riguros pentru a modela date ca entiti. El exprim relaiile ntre entiti ca funcii care pot fi imbricate, de exemplu Rang (Instructor (Curs)). Ca i modelul entitate-mulime, aici nu exist conceptul de atribut, mai mult, proprietile unei entiti rezult aplicnd funcii entitii. DAPLEX poate fi folosit pentru a descrie modele de date, pentru a defini restricii ntr-un model de date i pentru a pune ntrebri modelelor de date. Proiectantul de date (Data Designer). Este un produs comercial sub licen Knowledgeware, Inc., fostul Database Design, Inc. (DDI). Este un instrument de proiectare automat i combin modelele de date cu vederi utilizator. El se bazeaz pe tehnica diagramelor cu bule dezvoltat de James Martin (bubble - charting), n care ovalele reprezint entiti, iar arcele reprezint relaii. Proiectantul de date genereaz modele de date normalizate (vezi cap.6) bazate pe dependene de intrare ntre atribute. Gestionarul de proiectare (Design Manager). Este un produs comercial sub licen MPS, Ltd. care lucreaz n conjuncie cu dicionarul de date MPS, Data Manager, pentru memorarea i analiza modelelor de date. Ofer suport automat pentru descrierea modelelor de date i pentru transformarea lor n proiectri de baze de date.

126

4.13. Comentarii finale Succesul tehnicilor de modelare de date comerciale certific recunoaterea crescnd a importanei modelrii datelor n comunicaii i n descoperirea semanticii datelor. Modelarea datelor este folosit rutinier pentru: a crete nelegerea datelor i a semnficaiei lor de ctre o organizaie. a documenta resursele de date. a evalua din exterior pachete software. a planifica sisteme informatice. a proiecta sistemele informatice. a integra resursele de date a proiecta i a implementa baza de date fizice Modelarea datelor logice este o parte esenial a ciclului de via al proiectului baz de date i este folosit pentru a documenta mediile existente i pentru a planifica viitoarele resurse de date. Modelarea datelor este folosit, de asemenea, pentru a dezvolta proiecte modele de date i pentru a integra aceste modele ntr-o schem conceptual n dezvoltare, care este un scop special al modelului de date logice. Rezultatele modelrii datelor pot fi apoi transformate n proiectri de baze de date fizice. Memento Model de activitate Relaie de agregare Cheie alternat Aseriune Atribut Cheie candidat Relaie de categorie Clas de categorii Cheie compus Relaie de conectare Entitate Dependen de existen Atribut cheie strin Model funcie Model semantic de date Discriminator de subtip Bibliografie 1. D. Appleton Company, Inc. (1985) Data Modeling Technique Reference Manual, PCFS - DMT 3.0, Manhattan Beach, CA. Relaie de generalizare Entitate generic Model ierarhic Dependen de identificator Cheie Model de date logice Model reea Model de date fizice Cheie primar Model de proces Integritate referenal Model relaional Relaie Nume de rol Semantic

127

2. Database Design Inc. (1981) Data Designer. User Guide, Ann Arbor, Mich. 3. Martin, J. (1977) Computer Data Base Organisation, Englewood Cliffs, N.J. Prentice Hall.

Capitolul 5. Maparea pe modelul relaional

Acest capitol descrie cum poate fi folosit modelarea datelor logice pentru a proiecta baze de date relaionale. Modelul relaional a fost propus de ctre E.F. Codd n 1970. Ideile sale s-au bazat pe teoria mulimilor i calculul relaional i ntre 1970 i 1980 acest model s-a bucurat de atenia multor cercettori n baze de date. Baza de date relaional este un concept important pe piaa actual de DBMS-uri. Multe organizaii i implementeaz baze de date relaionale pentru sistemele de luare de decizii.

5.1. Obiective Obiectivele originale ale modelului relaional au fost simplitatea, independena datelor i tratarea riguroas a derivabilitii, redunandanei i consistenei. Simplitatea. Modelul relaional de baz este mai simplu dect sunt alte tehnici de modelare a datelor deoarece el vede datele ca i cnd acestea ar fi formatate n tabele. Coloanele tabelei reprezint proprietile tabelei iar liniile tabelei reprezint valorile acestor proprieti. Conectrile ntre tabele se formeaz prin coloane care au acelai nume sau valori comparabile. Oamenilor li se pare natural s vad datele n tabele: contabilitatea general, liste de preuri, liste de clase, cri de telefon sunt doar cteva exemple de tabele comune. Independena datelor. Modelul relaional ofer mai mult independe datelor dect o face orice alt abordare de modelare date care este legat direct de un DBMS comercial. Modelul relaional izoleaz aplicaiile program de creterea resursei de date i de schimbrile n reprezentarea datelor, astfel nct utilizatorii unei baze de date relaionale nu trebuie s tie nimic despre caracteristicile bazei de date fizice. Consideraiile despre bazele de date logic i fizic sunt separate. Modelul relaional adreseaz numai caracteristici logice, cele fizice fiind lsate pe seama celui care implementeaz baza de date. A vedea datele logice ca tabele nu nseamn c ele sunt memorate ca tabele. Rigoarea. Modelul relaional are o solid fundamentare matematic care permite ca cererile s fie adresate mai concret dect n modelele care nu 128

au aceast fundamentare. Astfel de ntrebri includ: Ce date sunt derivabile din alte date?, Exist redundan n aceste date?, Exist inconsisten n aceste date?. 5.2. Structura relaional Componentele structurale ale modelului relaional sunt relaii, atribute, domenii, tuple, chei i reprezentri. n mod formal, o baz de date relaional se definete ca: o colecie finit de relaii variind n timp, definite n concordan cu o colecie finit de domenii. O relaie pe n mulimi domeniu D 1, D2, ..., Dn (nu necesar distincte) este o mulime de elemente de forma (d1, d2, ..., dn). Fiecare dj este o valoare din domeniul Dj. Relaii. O relaie este o tabel cu nume, cu linii i coloane. Un exemplu de relaie numit PROFESOR este prezentat n fig.5.1. Gradul relaiei este numrul su de coloane. Relaia din fig.5.1. are opt coloane, deci gradul su este opt. Ea poate fi numit, de asemenea, o relaie 8-ar, gradul putnd fi numit i aritate. PROFESOR
Nume Marca# profesor Buse C. 62186 Cristea H. 71248 Birauas S. 19217 Lala I. 52163 Luta G. 42137 Mihai I. 47713 Megan M. 34218 Func. Nume catedra Asist. Analiza Prof. Finante Lector Analiza Asist. Finante Asist. Probab. Prof. Finante Prof. Analiza Nume facultate Matem. St.Econ Matem. St.Econ Matem. Matem. Matem. Telefon Data nasterii 112235 15.12.63 152793 07.03.44 132579 03.11.56 114222 15.12.59 112916 03.04.61 141612 23.04.40 157713 02.01.47 Data angajarii 01.10.90 15.09.69 01.08.86 01.10.90 01.10.90 01.09.67 01.09.70

Fig.5.1. Exemplu de tabel cu instane de relaie. Atribute. Fiecare coloan sau atribut (vezi def. cap.4) al unei relaii are un nume. Atributele relaiei PROFESOR din fig.5.1. sunt NUME_PROFESOR, MARCA#; FUNCTIE, NUME_CATEDRA, NUME _FACULTATE, TELEFON, DATA_NASTERII, DATA_ANGAJARII. Atributele pot apare n orice ordine ntr-o relaie i relaia va comunica aceai semnificaie. De exemplu, comutnd ordinea ntre MARCA# i DATA_NASTERII n relaia PROFESOR nu se schimb semnficaia. Domenii. Valorile unui atribut aparin unui domeniu, folosind aceai terminologie ca i n cap.4. Exist opt mulimi domeniu reprezentate n relaia de mai sus. Totui, dou atribute i iau valorile din acelai domeniu. DATA_NASTERII i DATA_ANGAJARII sunt ambele cu valori n domeniul DATA.

129

Tuple. Elementele unei relaii sunt liniile tabelei, numite i tuple. Fiecare linie conine n valori, cte una pentru fiecare atribut. Atunci cnd o relaie rprezint o entitate, fiecare linie reprezint o instan de entitate. Liniile, sau tuplele, pot s apar n orice ordine i tabela va transmite aceai semnificaie. S notm c independena de ordine nu se gsete n toate modelele. De exemplu, modelul reea CODASYL (vezi cap. 7.) permite ca o colecie de instane de entiti nrudite (numite nregistrri) s fie puse ori FIFO (coad) ori LIFO (stiv), astfel c ordinea lor va transmite semnificaie. Chei. Orice relaie are o mulime de chei candidate, din care una se selecteaz pentru a fi cheia primar. Cheile candidate, cheia primar i cheile alternate au aceleai definit n modelul relaional ca cele folosite n cap.4. Reprezentri. O convenie comun pentru reprezentarea unei relaii este de a-i da numele, urmat de numele atributelor sale, cu cheia primar subliniat. De exemplu, relaia din fig.5.1. este
PROFESOR (NUME_PROFESOR, MARCA#, FUNCTIE, NUME_CATEDRA,NUME_FACULTATE, TELEFON, DATA_NASTERII, DATA_ANGAJARII)

Tabela din fig.5.1. este numit formal o tabel de instane i d exemple de linii ale relaiei PROFESOR. O structur a relaiei se numete adesea intensiunea sau schema. Pe de alt parte, o tabel de instane pentru o relaie reflect liniile relaiei la un anumit moment dat. Valorile atributelor n aceste linii se numesc extensiunea relaiei, i ele se modific dup cum se schimb populaia n baza de date. Intensiunea unei relaii este fix, dac nu se schimb semnificaia relaiei pentru a include sau exclude atribute. Intensiunea transmite semnificaii, extensiunea transmite fapte. Nu este posibil s ne uitm doar la o tabel de instane i s determinm dac cheia primar a relaie a fost desemnat corect. Dac exist valori duplicate pentru cheia selectat este clar c s-a fcut o greeal. Absena valorilor duplicate, totui, nu implic faptul c cheia este corect ci doar c aceast cheie este suficient pentru aceast mulime de linii. Atta timp ct nu vedem toate instanele posibile valide (i.e. linii), nu este posibil s determinm dac cheia primar poate avea valori duplicate. Ca i n alte aspecte ale modelrii datelor logice, este necesar s cunoatem caracteristicile lumii reale care se modeleaz, pentru a identifica cheile candidate. 5.3. Aseriuni relaionale Exist dou aseriuni n modelul relaional care protejeaz integritatea unei mulimi de relaii. O aseriune este doar o constrngere sau o afirmaie sau o restricie care se aplic modelului. prima aseriune se refer la valorile de cheie primar iar a dou la valorile de atribut de cheie strin.

130

Aseriunea despre cheia primar. Aseriunea despre cheia primar este: Nici o component a valorii de cheie primar nu poate fi nul. n cap.4., cheia primar a unei entiti a fost definit ca un identificator unic pentru instanele unei entiti, i aceai terminologie se folosete n modelul relaional. Astfel, dac o cheie primar are o valoare nul, atunci tuplul su (i.e. instana entitii) nu ar avea un singur identificator. Similar, prile unei valori de cheie primar compus nu pot fi nule, deoarece identificarea unic nu ar fi posibil. n relaia PROFESOR (fig.5.1.), MARCA# este cheia primar, i astfel fiecare MARCA# dintr-un tuplu PROFESOR trebuie s aib valoare nenul. Aseriunea despre atribut de cheie strin. Aseriunea despre atribut de cheie strin folosete din nou terminologia introdus n cap.4., termenul relaie de origine (home relation) referindu-se la relaia de la care migreaz atributul de cheie strin. Aseriunea este: Valoarea unui atribut de cheie strin trebuie s fie sau nul sau egal cu valoarea cheii primare a unui anumit tuplu din relaia de origine. Atunci cnd aceast aseriune este extins pentru a exclude valorile nule de atribut de cheie strin, ea devine restricia de integritate referenial, care a fost prezentat n cap.4. S presupunem c n exemplul PROFESOR, NUME_CATEDRA, NUME_FACULTATE este un atribut de chei strin compus, legnd relaia PROFESOR de relaia UNIVERSITATE: UNIVERSITATE (NUME_FACULTATE, NUME_CATEDRA, DECAN#, DATA_INFIINTARII) n concordana cu aseriunea de atribut de cheie strin, ori fiecare tuplu PROFESOR are o valoare nul pentru NUME_FACULTATE, NUME_CATEDRA ori trebuie s existe un tuplu n UNIVERSITATE cu acea valoare pentru cheia sa primar. Dac restricia de integritate referenial funcioneaz, atunci opiunea de valoare nul nu este permis. 5.4. Operatori relaionali Orice DBMS relaional ar trebui s ofere posibiliti de manipulare cel puin la fel de puternice ca i operatorii modelului relaional. Operanzii operatorilor relaionali sunt ntotdeauna relaii irezultatul aplicrii unui operator relaional este ntotdeauna o relaie. Exist mai multe notaii pentru operatorii relaionali. Vom folosi aici una din acestea. Cei trei operatori relaionali de baz sunt PROJECT, SELECT i JOIN. Multe limbaje ofer comenzi de nivel nalt, folosind operatorii relaionali de baz ca primitive.

131

Project. Operatorul PROJECT extrage atribute dintr-o relaie formnd o nou relaie.
R2 := PROJECT (R1) (A1, A2, ..., An);

Relaia surs este R1 iar relaia rezultat este R2 coninnd n atribute A1, A2, ..., An, care sunt proiectate (i.e. extrase) din R1. Orice tuple duplicate care pot rezulta n relaia proiectat sunt scoase i nu apar n R2. De exemplu:
INVATARE:=PROJECT(PROFESOR)(NUME_CATEDRA,NUME_FACULTATE);

va crea o nou relaie, numit INVATARE cu dou atribute, NUME_CATEDRA i NUME_FACULTATE. Aceste coloane sunt extrase din relaia PROFESOR iar noua relaie reprezint acele catedre i faculti care au profesori n tabela surs. Fiecare linie din relaia INVATARE este distinct; orice tuple duplicate NUME_CATEDRA, NUME_FACULTATE vor fi rejectate n timpul proieciei. Fig.5.2. prezint tabela de instane pntru relaia INVATARE. O variant a acestui operator PROJECT permite ca atributele din relaia rezultat s fie redenumite.
NUME CATEDRA Analiza Probabilitati Finante NUME FACULTATE Matem. Matem. St.Econ.

Fig.5.2. Tabela de instane dup aplicarea PROJECT(PROFESOR)(NUME_CATEDRA, NUME_FACULTATE) tabelei de instane din fig.5.1. Select. Operatorul SELECT sau RESTRICT extrage linii dintr-o relaie, selectndu-le pe acelea care satisfac anumite criterii i formeaz o nou relaie. R2 := SELECT (R1) (condiie); Relaia surs este R1 i relaia rezultat R2 conine aceleai atribute. Se folosesc numai liniile lui R1 care satisfac condiia impus i orice linii duplicate care ar putea rezulta sunt rejectate i nu apar n R2. De exemplu:
PROFESOR_SUP := SELECT (PROFESOR) (FUNCTIA = Prof OR Conf);

creaz o nou relaie, numit PROFESOR_SUP cu aceleai opt atribute ca i PROFESOR, dar cu o submulime din liniile relaiei. Aceste linii sunt extrase din relaia PROFESOR i noua relaie reprezint acei profesori a cror funcie este Profesor sau Conferentiar. Fiecare linie din relaia

132

PROFESOR_SUP este distinct; orice tuple duplicate sunt rejectate n timpul seleciei. Fig.5.3. prezint tabela de instane pentru PROFESOR_SUP. Exemplul urmtor prezint un SELECT urmat de un PROJECT:
TEMPORAR := SELECT (PROFESOR) (NUME_CATEDRA = Analiza); NUME_PROF_ANALIZA := PROJECT (TEMPORAR) (NUME_PROFESOR);

Acestea creaz o relaie numit NUME_PROF_ANALIZA care conine numele profesorilor din catedra de analiz. PROFESOR_SUP
Nume prof. Cristea Mihai Megan Marca# Func. Nume catedra 71248 Prof Finante 47713 Prof. Finante 34218 Prof. Analiza Nume facultate St.Econ Matem. Matem. Telefon Data nasterii 152793 07.03.44 141612 23.04.40 157713 02.01.47 Data angajarii 15.09.69 01.09.67 01.09.70

Fig.5.3. Tabela cu instane dup aplicarea SELECT (PROFESOR) (FUNCTIE = Prof OR Conf) tabelei de instane din fig.5.1. Join. Operatorul JOIN extrage linii din dou relaii potrivindu-le dup anumite criterii i formnd o nou relaie cu acestea. R3 := JOIN (R1) (condiie) (R2); Relaiile surs sunt R1 i R2 iar relaia rezultant R3 conine atributele combinate ale lui R1 i R2. Liniile din R1 i R2 sunt potrivite n concordan cu condiia impus; orice linie duplicat care ar putea rezulta este rejectat i nu apare n R3. De exemplu, putem folosi ca surse urmtoarele relaii:
STUDENT MATRIC#); (NUME_STUDENT, VIRSTA, GRAD_STIINTIFIC,

PROFESOR (NUME_PROFESOR, MARCA#, FUNCTIE, NUME_CATEDRA, NUME_FACULTATE, TELEFON, DATA_NASTERII, DATA_ANGAJARII); UNIVERSITATE (NUME_FACULTATE, NUME_CATEDRA; DECAN#, DATA_INFIINTARII); Operaia STUDENT_PROFESOR := JOIN (STUDENT) (NUME_STUDENT = NUME_ PROFESOR) (PROFESOR); creaz o nou relaie numit STUDENT_PROFESOR cu 12 atribute (patru provenind din STUDENT i opt din PROFESOR). Fiecare linie din

133

STUDENT_PROFESOR este rezultatul combinrii unei linii din STUDENT cu o linie din PROFESOR care au aceai valoare pentru NUME_STUDENT i NUME_PROFESOR. Noua relaie reprezint acei studeni care sunt, deasemenea i profesori. Un alt exemplu:
TEMP1 := JOIN (PROFESOR) (MARCA# = DECAN#) (UNIVERSITATE); TEMP2 := SELECT (TEMP1) (DATA_ANGAJARII > 01/01/70); INFO_DECAN := PROJECT (TEMP2) (NUME_PROFESOR, FUNCTIE);

Rezultatul este o relaie cu toi decanii angajai dup 1. ianuarie 1970. Exemplele STUDENT_PROFESOR i INFO_DECAN ilustreaz EQUI-JOINS, adic operaii JOIN ale cror condiii sunt comparaii de egalitate. Relaia JOIN general se numete adesea i THETA-JOIN; unde theta este <, >, <=, >= n concordan cu operatorul de condiie. Forma general a lui JOIN este:
R3 := JOIN (R1) (A1 operator1 T1, A2 operator2 T2, ..., Aj operatorj Tj)(R2);

unde A1, A2, ..., Aj sunt atribute din R1, iar T1, T2, ..., Tj atribute din R2. De exemplu:
TEMP3 := JOIN (PROFESOR) (DATA_NASTERII < DATA_INFIINTARII) (UNIVERSITATE);

UNITATE_TINARA := PROJECT (TEMP3) (NUME_FACULTATE, NUME_CATEDRA); folosete o relaie LESS-THAN-JOIN pentru a gsi toate unitile care sunt mai tinere dect anumii profesori. Pentru a gsi unitile care au cel puin un profesor care este mai btrn dect unitatea am putea folosi, de exemplu:

TEMP4 := JOIN (PROFESOR) (DATA_NASTERII < DATA_INFIINTARII, NUME_CATEDRA = NUME_CATEDRA, NUME_FACULTATE = NUME_FACULTATE) (UNIVERSITATE);
REZULTAT := PROJECT (TEMP4) (NUME_FACULTATE; NUME_CATEDRA);

Natural Join. Un caz special al operaiei JOIN este cel numit NATURAL JOIN, care potrivete relaiile sale operand pe valorile egale ale atributelor cu nume care se potrivesc. Este folosit pentru a combina relaii pentru care atributele de cheie primar al uneia apar ca atribute de cheie

134

strin ale celeilalte. Cu toate c poate exista un numr arbitrar de coloane care se potrivesc uzual exist numai una sau dou. Nu trebuie dat nici o condiie deoarece implicit A1 = T1, unde A1 i T1 sunt numele de atribute care se potrivesc. Coloanele care se potrivesc apar numai o dat n relaia rezultant. NATURAL JOIN ntre relaiile R1 i R2 se noteaz de obicei:
R1 | X | R2

De exemplu:
INFO := PROFESOR | X | UNIVERSITATE;

creaz o relaie numit INFO care adaug DECAN#, DATA_INFIINTARII din UNIVERSITATE fiecrui tuplu PROFESOR. Potrivirea ntre cele dou relaii se face pe valori egale ale lui NUME_CATEDRA i NUME_FACULTATE, acestea fiind atributele pe care le partajeaz relaiile. Relaia rezultat are 10 atribute; NUME_FACULTATE i NUME_CATEDRA apar numai o dat. Operatori de mulime. Operatorii de mulime UNION, INTERSECT i DIFFERENCE se pot aplica de asemenea, la relaii, cu toate c trebuie s ne asigurm c relaiile operand sunt, ntr-adevr, comparabile. Operaiile corespund reuniunii, interseciei i diferenei mulimilor de linii ale relaiei. De exemplu, reuniunea relaiilor UNIVERSITATE i STUDENT nu are sens. Operatori de actualizare tuple. Ali operatori actualizeaz tuple n relaii i permit inserarea de noi tuple n relaii existente, tergerea tuplelor din relaii existente i modificarea tuplelor n relaii existente. Nici unul din aceti operatori nu modific intensiunea relaiei. 5.5. Definirea schemei Limbajul folosit pentru a descrie structura bazei de date ntr-un DBMS se numete adesea data definition language - DDL sau schema definition language. Limbajul de definire a schemei pentru o baz de date relaional trebuie s fie n stare s creeze, s modifice i s tearg descrieri de relaii i de atribute ale lor. Exist mai multe limbaje de definire a schemei pentru baze de date relaionale, dar noi vom folosi aici partea limbajului SQL (citit uzual see-quel), limbajul de date relaionale, care este orientat spre definirea schemei. SQL permite, de asemenea, inserarea, modificarea i tergerea de tuple din relaii i ofer o facilitate de control a datelor care: permite utilizatorilor s autorizeze ali utilizatori pentru a accede date; specific aseriuni despre integritatea datelor; specific tranzacii care se declaneaz de ctre anumite evenimente; SQL este baza pentru multe limbaje comerciale de date relaionale i de asemenea pentru limbajele de date relaionale dezvoltate de ctre

135

ANSI/X3H2, comitetul care propune standarde pentru limbaje calculator. Pachete software care permit introducerea de comenzi SQL includ i Oracle, dBase, FoxPro, Delphi, Magic, etc. Pentru a defini o nou relaie, utilizatorul trebuie s specifice numele tabelei, numele atributelor sale i tipul datei pentru fiecare atribut. De exemplu:
CREATE TABEL STUDENT (NUME_STUDENT (CHAR (20) VAR NOT NULL) VIRSTA (INTEGER) GRAD_STIINT (CHAR (4)) MATRIC# (CHAR (6) NOT NULL UNIQUE));

construiete schema pentru relaia:

STUDENT (NUME_STUDENT, VIRSTA, GRAD_STIINT, MATRIC#);

Urmtoarea instruciune expandeaz relaia STUDENT cu o coloan adiional, pentru atributul MEDIE:
EXPAND TABLE STUDENT ADD COLUMN MEDIE (DECIMAL (3,2));

Definiia tabelei STUDENT se poate elimina cu urmtoarea instruciune: DROP TABLE STUDENT; Definirea vederilor. SQL include, de asemenea, faciliti pentru a forma o submulime a relaiei, definim o vedere, care este o fereastr pe relaia de baz. Atunci cnd valorile se modific n relaia de baz, ele se modific i n vederile definite de utilizator pentru acea relaie. De exemplu, urmtoarea instruciune creaz o vedere a relaiei STUDENT care include numai studenii cu media mai mare ca 7.5.

DEFINE VIEW AS SELECT NUME_STUDENT; VIRSTA; MATRIC#; MEDIA FROM STUDENT WHERE MEDIE > 7.5;

Clauza SELECT este o expresie de interogare SQL care specific aici o restricie (RESTRICT) pe STUDENT (cu MEDIE > 7.5). Vederea include numai patru coloane (NUME_STUDENT, VIRSTA; MATRIC#; MEDIE). Coloanele vederii au aceleai nume ca i coloanele relaiei de baz. O variant a definiiei vederii modific numele coloanelor. Majoritatea sistemelor relaionale nu permit actualizarea unei vederi care nu corespunde direct cu o relaie de baz. O vedere poate rezulta dintr-un JOIN ntre dou 136

relaii de baz, n cazul specificrii a dou clauze FROM i a unei clauze WHERE potrivite. n acest caz vederea nu poate fi actualizat. La fel este cazul vederilor care rezult din PROJECT asupra unei relaii de baz. Domenii i aseriuni. Domeniile sunt suportate n anumite versiuni ale lui SQL ca un tip de aseiune. De exemplu, urmtoarea instruciune limiteaz mulimea valid de valori pentru MEDIE:
ASSERT A1 ON STUDENT: MEDIE BETWEEN 1.00 AND 10.00;

Aseriunile pot fi de asemenea, folosite pentru a specifica restricii de integritate referenial. De exemplu, dac NUME_CATEDRA a fost un atribut cheie strin n STUDENT, cu relaia originar CATEDRA, integritatea referenial poate fi exprimat astfel:
ASSERT A2: (SELECT NUME_CATEDRA FROM STUDENT) IS IN (SELECT NUME_CATEDRA FROM CATEDRA);

5.6. Mapri din modele de date logice Proiectarea unei baze de date, introdus n cap.3. dezvolt la nceput un model de date logice folosind o tehnic independent de orice DBMS (vezi i cap.4). Ea mapeaz apoi modelul de date logice pe modelul suportat direct de ctre DBMS pentru a fi folosit pentru implementare. DBMS-urile relaionale suport modelul relaional. Maparea dintr-un model de date logice pe un model relaional este relativ direct atta timp ct nu se ntlnesc relaii de categorie. Modelul relaional rezultat, totui, pierde anumite informaii semantice explicitate n modelul de date logice. Deoarece ele nu se gsesc n modelul nativ al DBMS-ului, aceste semantici trebuie forate de ctre codul aplicaiei program i nu de ctre DBMS-ul nsui. Adesea ns ele nu sunt implementate de loc. 5.7. Entiti, atribute i relaii de conectare Regulile de baz pentru maparea entitilor, atributelor i a relaiilor de conectare dintr-un model de date logice pentru o baz de date relaional sunt: o entitate este reprezentat de o relaie; fiecare atribut al unei entiti este reprezentat de un atribut din relaie; o relaie de conectare este reprezentat prin prezena unui atribut de cheie strin n relaia fiu Este relativ simplu a dezvolta o mulime de relaii care corespund la un model de date n care:

137

 relaiile nespecifice au fost rezolvate; cheile au migrat (formnd atribute cheie strin) nu se folosesc nume de roluri Fig.5.4. prezint un astfel de model de date i relaiile sale corespunztoare. Modelul de date nu are relaii mai-muli-la-mai-muli sau relaii zero-sauunul-la-mai-muli. Fiecare entitate a fost tradus ntr-o relaie, cu cte o coloan pentru fiecare atribut al entitii iar relaiile nu apar separat ci ca atribute de cheie strin n relaiile entiti. Maparea unui model de date n care relaiile nespecifice nu au fost rezolvate i n care cheile nu au migrat pentru a forma atribute cheie strin nu este direct. Chiar reprezentarea entitilor prin relaii exclude informaia structural despre relaii, cci atributele de cheie strin sunt necesare pentru a arta asocierile logice ntre relaii. O alternativ pentru a rectiga aceast informaie este de a introduce o relaie pentru fiecare relaie. O astfel de relaie ar conine chiar cheile entitilor care se leag i cheia relaiei rezultate ar fi determinat de ctre cardinalitatea relaiei. Fig.5.4.b listeaz relaiile care rezult aplicnd aceast alternativ modelului de date din fig.5.4.a, care este o versiune preliminar a modelului rezolvat i migrat din fig.5.5.a.
TEXT (NUME_AUTOR, ISBN, TITLU, EDITOR, AN); CURS (CURS#, SECTIE#, NUME_CURS); PROFESOR (MARCA#, TELEFON, BIROU); STUDENT (MATRIC#, NUME_STUDENT, GRAD_STIINT, MEDIE); DONATOR (NUME_DONATOR, NUME_CONTACT, TELEFON_CONTACT); ESTE_FOLOSIT_IN (ISBN, CURS#, SECTIE#); ESTE_PREDAT_DE (CURS#, SECTIE#, MARCA#); ESTE_URMAT_DE (CURS#, SECTIE#, MATRIC#); ESTE_SPONSORIZAT_DE (MATRIC#, NUME_DONATOR);

Fig.5.4. Model de date logice i relaii

TEXT (NUME_AUTOR, ISBN, TITLU, EDITOR, AN); CURS (CURS#, SECTIE#, NUME_CURS); PROFESOR (MARCA#, TELEFON, BIROU); ASIGNARE (ISBN, CURS#, SECTIE#); RESPONSABILITATE (CURS#, SECTIE#, MARCA#, TOPICA); STUDENT (MATRIC#, NUME_STUDENT, GRAD_STIINT, MEDIE); INSCRIERE (CURS#, SECTIE#, MATRIC#, CREDITE); DONATOR (NUME_DONATOR, NUME_CONTACT, TELEFON_CONTACT); RECOMPENSA (MATRIC#, NUME_DONATOR, AN_REC, ID_REC);

Fig.5.5. Model de date logice i relaii.

138

Relaii de categorie. O relaie de categorie nu este mnuit convenabil ntr-un model relaional. Reprezentarea este ca i pentru relaiile de conectare, n care fiecare entitate se mapeaz direct pe o relaie, iar o relaie este reprezentat de atribute de cheie strin. Ierarhia de categorie din fig.4.19.b. este reprezentat de urmtoarele relaii:
ANGAJAT (SSN#, NUME_ANGAJAT, DATA_NASTERII, #DEPENDENTI, ADRESA, STARE); STUDENT (SSN#, AN_STUDII, GRAD_CALIFICARE, SALARIU_ORAR); ADMINISTRATIV (SSN#, COD_EXCEPTIE, BENEFICII, SALARIU_LUNAR); PROFESOR (SSN#, FUNCTIE, SALARIU_ANUAL, DATORII_CLUB);

Prima problem ce apare n aceast reprezentare a categoriei este c s-a pierdut structura ierarhic. Din mulimea de relaii nu este clar care relaie reprezint entitatea generic i care reprezint entitile subtipuri. De asemenea, nu este clar care relaii motenesc implicit atribute de la alte relaii. Modelul de date logice spune c entitile STUDENT, ADMINISTRATIV i PROFESOR motenesc toate atributele de la entitatea ANGAJAT. O alternativ este de a moteni explicit atributele generice:
STUDENT (SSN#, NUME_ANGAJAT, DATA_NASTERII, #DEPENDENTI, ADRESA, STARE AN_STUDII, GRAD_CALIFICARE, SALARIU_ORAR); ADMINISTRATIV (SSN#, NUME_ANGAJAT, DATA_NASTERII, #DEPENDENTI, ADRESA, STARE, COD_EXCEPTIE, BENEFICII, SALARIU_LUNAR); PROFESOR (SSN#, NUME_ANGAJAT, DATA_NASTERII, #DEPENDENTI, ADRESA, STARE, FUNCTIE, SALARIU_ANUAL, DATORII_CLUB);

Aceast abordare ascunde i ea structura ierarhic, cci nu este clar c STUDENT, ADMINISTRATIV i PROFESOR sunt subtipuri ale unei singure entiti generice. O a doua problem ridicat de relaiile de categorie apare la operatorii relaionali. Pentru a lista toate valorile de atribut ale instanelor entitii STUDENT, se pot folosi urmtoarele operaii:
R1 := SELECT (ANGAJAT) (STATUS = 'student'); RASPUNS := R1 | X | STUDENT;

S ncercm acum s listm mulimea complet (i.e. proprii i motenite implicit) de valori de atribut ale angajatului, fr a cunoate ntreg setul de

139

valori pentru atributul STATUS. Sau s incercm s listm mulimea complet de valori de atribut pentru angajaii cu STATUS = input_status (o variabil). Urmtoarea sintax nu poate fi prelucrat de nici un DBMS relaional:

R2 := SELECT (ANGAJAT) (STATUS = input_status); RASPUNS := R2 | X | input_status;

Analizorul sintactic ateapt numele a dou relaii ca operanzi pentru un JOIN, aici 'input_status este ns numele unei variabile. Dependene de identificator. Modelul relaional reprezint dependena de identificator n schemele bazelor sale de date. Dac o relaie este dependent de identificator de o alt relaie, atunci cheia primar a independentului este coninut complet (i ca atribut de cheie strin) n cheia primar a dependentului relaiei. De exemplu, relaia BUGET_LUNAR este dependent de identificator de relaia DEPARTAMENT, dar relaia ANGAJAT nu este:
DEPARTAMENT (DEPARTAMENT#, NUME_DEPARTAMENT, LOCATIE); BUGET_LUNAR (DEPARTAMENT#, LUNA, AN, VALOARE); ANGAJAT (DEPARTAMENT#, ANGAJAT#, NUME_ANGAJAT);

Modelul relaional nu este n stare s reprezinte dependena de identificator dac se folosesc nume de roluri pentru atributele de cheie strin. De exemplu, relaiile corespunztoare modelului fin fig.4.16.b. sunt:
ORAS (COD_ORAS, LONGIT, LATIT; NUME_AEROPORT); SEGMENT_ZBOR (COD_ORAS_PLECARE, COD_ORAS_SOSIRE, ORA_PLECARE, ORA_SOSIRE, TIP_AVION); ZBOR#,

Din aceste relaii nu este clar c relaia SEGMENT_ZBOR are dou atribute cheie strin: COD_ORAS_PLECARE i COD_ORAS_SOSIRE, ambele nume de roluri pentru COD_ORAS, care este cheie a lui ORAS. Fr a ti c acestea sunt nume de roluri, nu este posibil s identificm dependena de identificator. Multe din limbajele de definire a schemelor pentru DBMS-uri relaionale nu specific nici chei nici nume de roluri i astfel dependenele de identificator nu sunt explicite. Restricii de integritate referenial. Modelul relaional presupune teoretic c dac un atribut de cheie strin nu poate avea o valoare nul, atunci restricia de integritate referenial (i deci dependena de existen) va avea loc ntotdeuna. Valoarea unui atribut cheie strin trebuie s se

140

potriveasc cu o valoare a atributului cheie primar corespunztor din relaia dependent care s nu fie legat direct de o linie de relaia originar din baza de date. DBMS-urile care implementeaz modelul relaional, totui, nu foreaz uzual restricia de integritate referenial. Multe nu ofer mcar facilitatea de aseriune, pentru a specifica restriciile de integritate referenial. Dar, dac ele foreaz integritatea referenial, atunci: la inserarea de tuplu, vor verifica valorile atributului de cheie strin pentru a fi cuprinse n mulimea valorilor atributului de cheie primar a relaiei originare. la tergerea de tuplu, vor verifica dac valoarea atributului de cheie primar nu este prezent n nici o valoare de atribut cheie strin a relaiei dependente. Dac restricia de integritate referenial este forat, ea este introdus uzual prin codul aplicaiei. Procesul de mapare. O secven uzual de evenimente n proiectarea bazei de date este construcia la nceput a unui model de date logice i apoi maparea ntr-o form care poate fi implementat de un DBMS. Paii n maparea pe o baz de date relaional sunt: 1. construirea unui model de date din aria de interes; 2. rezolvarea relaiilor mai-muli-la-mai-muli i zero-sau-unul-la-mai-muli; 3. migrarea cheilor primare, formnd atribute de cheie strin n entiti dependente; 4. definirea relaiei pentru fiecare entitate, atributele entitii devenind coloanele relaiei; 5. potrivirea structurilor relaiei, pentru a mri performanele fizice. Ultimul pas va fi tratat n cap.11. (proiectarea fizic a bazelor de date relaionale). El include: combinarea relaiilor (ex.: colapsarea relaiilor unu-la-zero-sau-unu); divizarea relaiilor (ex.: cnd anumite atribute dintr-o relaie sunt accesate mai frecvent dect altele) specificarea cilor de acces (ex.: construirea de indeci pentru cheile primarea ori alte atribute) asigurarea relaiilor la spaiul fizic (ex.: relaii grupate cluster, folosite tipic mpreun), Adesea, n loc de a construi la nceput un model de date nou, se construiete un model de date care corespunde la o mulime de relaii care deja exist n baza de date. Aceasta ajut la clarificarea tipurilor de informaie coninute n baza de date la momentul curent. Reprezentarea grafic a unui model de date logice este un mod convenabil pentru a identifica relaiile duse de atributele de cheie strin ale unei mulimi de relaii. n plus, ntrebrile de la construcia unui model de date logice vor scoate la iveal orice relaie de categorie care se ascunde n baza de date relaional.

141

5.8. Introducere pentru DBMS-uri relaionale comerciale Numeroase DBMS-uri comerciale se autonumesc relaionale. Printele tuturor este System R, dezvoltat n anii 70 la IBM San Jose Research Laboratory. Acest sistem experimental a investigat nu numai implementarea structurilor modelului relaional i a operaiilor asupra lui, dar i facilitile de protecie date ntr-un mediu relaional. System R a condus la multe publicaii tiinifice despre acces partajat, control concurenial, salvare i restaurare, control tranzacii, faciliti interfa utilizator. El a condus i la proiectul System R* , tot de la IBM San Jose Research Lab., care a studiat gestionarea datelor relaionale distribuite n reele de calculatoare. System R a dus nti la dou produse comerciale ale lui IBM, SQL/DataSystem (SQL/DS) i Database2 (DB2). SQL/DS a devenit disponibil comercial n 1982 i se execut pe calculatoare IBM medii, incluznd System/370, 303x, 43xx i procesoare compatibile DOS/VSE. DB2 a devenit disponibil comercial n 1984 i se execut pe calculatoare IBM mari, incluznd MVS/XA i MVS/370. Dou produse insoitoare sunt Query Management Facility (QMF), care ofer acces interactiv la baza de date DB2 i SQL/DS i Data Extract (DXT) care ofer o metod de extragere selectiv de date din baze de date existente IMS/VS sau din fiiere secveniale sau fiiere VSAM pentru a fi ncrcate n baze de date DB2 sau SQL/DS. Dou din implementrile comerciale de nceput ale modelului relaional au fost ORACLE, de la Oracle, Inc. (fost Relational Software, Inc.) i INGRES, de la Relational Technology, Inc. ORACLE a fost dezvoltat pe baza System R, iar INGRES provine din proiectul omonim al University of California, Berkeley. Ambele au fost iniial implementate pe maini VAX ale lui DEC, sub VMS. INGRES Berkeley se execut pe sistemul de operare UNIX. ORACLE are versiuni att pentru sisteme de operare UNIX, ct i MVS al lui IBM, i mai de curnd i Windows. Ambele sunt disponibile pe mai multe tipuri de microcalculatoare. Exist multe alte DBMS-uri care suport o vedere tabular a datelor. Printre aceste produse, pentru calculatoare mainframe enumerm IDMS/R de la Cullinet, ADABAS de la Software AG, Model204 de la Computer Corporation of America. Produsele relaionale pentru microcalculatoare includ Unify, de la Unify Corporation, Informix, de la Relational Database Systems, Inc., Seuitur, de la Pacific Software Manufacturing Company, R:base de la Microrim, Inc., etc. Suportul de model relaional este acum disponibil comercial pe calculatoare dedicate, numite maini baz de date, care sunt specializate hard i soft pentru a manipula eficient accesul i memorarea bazelor de date. De pe aceast pia amintim IDM de la Britton-Lee i DBC/1012 de la Teradata. 5.9. Comentarii finale 142

Dezvoltarea modelului relaional a constrituit o secven de jaloane n cercetarea gestionrii datelor. Simplitatea modelului relaional i separarea vederilor de implementare i de utilizator l-au fcut atractiv pentru cel puin 15 ani, n primul rnd n comunitatea cercettorilor i apoi pe pia. Cele mai bune caracteristici ale modelului relaional sunt: viziunea sa simpl, tabelar supra datelor; mulimea complet de operatori de manipulare date; separarea modelului logic de implementarea fizic. Dezavantajele de baz ale modelului relaional sunt: suprancrcarea semantic, ntr-o singur structur tabelar se reprezint o varietate de construcii de modelare de date logice; demonetizarea, prin caracterizarea DBMS-urilor comerciale ca relaionale chiar dac ele nu utilizeaz anumite restricii ale modelului relaional, ca de exemplu integritatea referenial; operatorii relaionali care sunt la un nivel procedural, de programator i trebuie acoperii prin comenzi de nivel nalt, care sunt mai uor de folosit de ctre nespecialiti; implementarea ineficient, relativ la alte proiectri, pentru anumite tipuri de structuri de date. Prima problem poate fi ameliorat prin folosirea unei tehnici de modelare a datelor logice n modelul relaional. A doua problem nu ine chiar de modelul relaional ci de folosirea de ctre industrie a terminologiei. La a treia problem este mai mult de lucruiar a patra se rezolv prin specializarea hardului i soft-ului bazei de date, vezi cap. 11. DBMS-urile relaionale comerciale continu s aib probleme de performan n mediile baze de date mari i complexe. Memento Cheie alternat Atribut Relaie de categorie Relaie de conectare Limbaj de definire date Domeniu Dependen de existen Extensiunea unei relaii NATURAL JOIN Nul Cheie primar Aseriune cheie primar PROJECT Aseriune cheie strin Atribut cheie strin Relaie originar Dependen de identificator Tabel de instane Intensiunea unei relaii OIN Model de date logice Schem Limbaj de definire schem SELECT SQL System R

143

Integritate referenial Relaie Bibliografie

Tuplu Vedere

1. Astrahan, M.M. e.a. (1976) System R: relational approach to data base management, ACM Trans. Database Systems 1 (June 1976): 97-137. 2. Brodie, M.L.; Schmidt, J.W. (ed.) (1982) Final report of the relational database task group ANSI/X3/SPARC/DBSSG, ACM SUGMOD Record 12 (July 1982). 3. Chamberlin, D.D. e.a. (1976) SEQUEL 2: An unifiedapproach to data definition, manipulation and control, IBM J.of.Res. and Development 20 (Nov. 1976): 560-576. 4. Codd, E.F. (1979) Extending the database relational model to capture more meaning, ACM Trans. Database Systems 4 (Dec. 1979): 397-434. 5. Date, C.J. (1982) A formal definition of the relational model,ACM SIGMOD Record 13 (Sept. 1982).

Capitolul 6. Normalizarea

Normalizarea este un proces dezvoltat n conjuncie cu modelul de date relaional, cu toate c ea este aplicabil modelrii logice a datelor n general. Ea poate fi util n rspunsul la dou ntrebri majore despre date: Ce nseamn o proiectare bun de baz de date logic? i Ce nseamn o proiectare bun de baz de date fizic?. 6.1. Obiective Normalizarea relaional este un proces pentru identificarea atribute stabile, cu o mare interdependen i afinitate. incorporeaz principiile modelrii semantice a datelor i extensive de baze de date logice. Ea poate conduce, de proiectri flexibile de baze de date fizice, pstrnd separate fizice i logice. 6.2. Dependene Normalizarea se bazeaz pe conceptele de dependene ntre atribute i ea impune un set de reguli guvernnd structura semnificaiei datelor. Aceste reguli, bazate pe condiii de dependen, ajut la stabilizarea definiiilor semnificaiilor i prezic reprezentrile faptelor. Cele mai importante dou gruprilor de Normalizarea d proiectri asemenea, la consideraiile

144

tipuri de dependene de atribute sunt, pentru scopurile noastre, dependena funcional i dependena multivaloric. Dependena funcional. S considerm urmtoarea relaie: PROFESOR (NUME_POFESOR, MARCA#, FUNCTIE, NUME_CATEDRA, NUME_FACULTATE, TELEFON, DATA_NASTERII, DATA_ANGAJARII); S presupunem c fiecare valoare MARCA# este asociat cu una i numai cu o valoare a lui DATA_NASTERII. Dar, deoarece doi profesori pot avea exact aceeai zi de natere, fiecare valoare DATA_NASTERII poate fi asociat cu mai mult de o valoare MARCA#. DATA_NASTERII se spune atunci a fi dependent funcional de MARCA#. Aceasta se noteaz, uneori: MARCA# DATA_NASTERII i se citete MARCA# determin funcional DATA_NASTERII. S considerm relaia R cu atributele A i B. Atributul B se spune a fi dependent funcional de atributul A dac i numai dac fiecare valoare a lui A n liniile lui R are asociat cu ea la un moment dat fix o valoare a lui B n R. Adic: liniile lui R cu o valoare dat pentru A, trebuie s aib toate aceai valoare pentru B. atunci cnd dou linii ale lui R au aceai valoare a lui B, ele nu trebuie s aib aceai valoare pentru A. Dependen multivaloric. S considerm relaia RESPONSABILITATE (MARCA#, CURS#, NUME_COMITET); S presupunem c fiecare valoare MARCA# are asociate cu ea una sau mai multe valori CURS#. Mulimea valorilor CURS# asociate cu o valoare MARCA# dat este, totui aceeai pentru oricare COMITET# care este de asemenea asociat cu acea MARCA#. S presupunem c MARCA# = 12345 apare n trei linii n relaia RESPONSABILITATE, cu valorile CURS#: 100. 200 i 300. Pentru a aduga c MARCA# servete COMITET# = 12 ar cere ca trei linii MARCA#, CURS#, NUME_COMITET s fie adugate relaiei RESPONSABILITATE: 12345, 100, 12 12345, 200, 12 12345, 300, 12 Mulimea valorilor CURS# asociate cu o valoare MARCA# dat (aici 12345) trebuie s fie exact aceai pentru orice valoare COMITET#. Astfel COMITET# = 12 nu poate apare cu MARCA# = 12345 i numai cu una din valorile CURS# din mulimea {100, 200, 300}. CURS# se spune a fi dependent multivaloric de MARCA#, i se noteaz: MARCA# CURS# i citim MARCA# determin multivaloric CURS#.

145

S considerm acum relaia R cu atributele A, B i C. Atributul B se spune a fi dependent multivaloric de atributul A dac i numai dac mulimea valorilor lui B n R care se potrivesc cu o pereche de valori <A, C> n R este independent de valoarea lui C. Adic, urmtoarele sunt adevrate: nu toate liniile lui R cu o valoare dat a lui A trebuie s aib aceeai valoare a lui B (B-valorile din aceste linii sunt referite ca mulimea Bvalorilor determinate de A-valoare); ori de cte ori dou linii ale relaiei R au aceai valori pentru A, ele nu trebuie s aib aceeai valori pentru B, dar valorile lor pentru B trebuie s fie elemente ale mulimii de valori determinate de valoarea lui A; schimbarea valorii lui C ntr-o linie a lui R nu poate afecta valoarea lui B n acea linie; cnd dou linii ale relaiei R au aceai valori pentru B, ele nu trebuie s aib n mod necesar aceleai valori pentru A; s considerm dou valori ale lui C, C1 i C2. Mulimea valorilor lui B n liniile lui R cu o valoare dat pentru A i cu C-valoarea C1 trebuie s fie exact aceeai ca i mulimea valorilor lui B n liniile lui R cu aceeai Avaloare i cu C-valoarea C2. 6.3. Prima form normal Teoria relaional folosete termenul de forme normale pentru a descrie extinderea la care au fost grupate atributele n relaii stabile. Au fost propuse numeroase forme normale, fiecare ncercnd s obin o grupare de atribute ct mai stabil. Interesul nostru se restrnge la ase forme normale - primele cinci purtnd numere de ordine i forma normal Boyce/Codd. O relaie este n prima form normal (1NF) dac i numai dac fiecare atribut din fiecare linie poate conine numai o singur valoare. O relaie nu poate avea nici o linie care conine un grup repetitiv de valori de atribut. S considerm relaia: FACULTATE_1 (NUME_PROFESOR, MARCA#, NUME_STUDENT, MATRIC#, NUME_CATEDRA, CURS#, TEXT, GRAD, COMITET#, ZI_INTILNIRE. ORA_INTILNIRE); Nu este posibil s determinm dac aceast relaie este n 1NF fr a verifica o tabel de instane sau a rspunde la ntrebarea: Pentru o linie dat din aceast relaie, pot exista valori multiple pentru un atribut? O tabel de instane pentru relaia FACULTATE_1 este dat n fig.6.1. Relaia nu este n 1NF cci exist mai multe valori pentru NUME_STUDENT (i pentru alte atribute de asemenea) n linia cu MATRIC# = 12751.

146

Producerea lui 1NF. Pentru a normaliza o relaie n forma 1NF este necesar s netezim liniile, astfel nct nici o linie s nu conin atribute care se repet. Fig.6.2. d o tabel de instane pentru relaia FACULTATE_1, modificat pentru a fi 1NF. S notm c schema relaiei nu s-a modificat. Cheia primar pentru relaia exemplu este MARCA#, NUME_CATEDRA, CURS#, MATRIC# i toate patru atribute sunt necesare pentru a identifica liniile. Obiectivele lui 1NF. Cele dou raiuni principale sunt c semantica unei relaii 1NF este mai explicit - nici un atribut nu poate avea mai mult de o valoare n orice linie dat i pentru a folosi relaii 1NF n loc de relaii nenormalizate c operatorii relaionali sunt aplicabili relaiilor plate, adic 1NF. Schema unei relaii nenormalizate nu permite stabilirea atributelor cu valori multiple. Pe de alt parte, cunoscnd c o relaie este n 1NF tim c nici un atribut nu poate avea valori multiple. 6.4. A doua form normal O relaie este n a doua form normal (2NF) dac i numai dac ea este n 1NF i orice atribut non cheie este dependent funcional complet de cheia primar. Adic, o relaie 2NF nu poate avea un atribut care este dependent funcional numai de o parte a cheii primare. Nu este posibil a stabili dac o relaie este n 2NF pe baza schemei ei; cunoaterea dependenelor funcionale existente fiind de asemenea necesar. S considerm din nou relaia FACULTATE_1, care este acum n 1NF:
FACULTATE_1 (NUME_PROFESOR, MARCA#, NUME_STUDENT, MATRIC#, NUME_CATEDRA, CURS#, TEXT, GRAD, COMITET#, ZI_INTILNIRE. ORA_INTILNIRE);

S presupunem c au loc urmtoarele dependene funcionale: MARCA# NUME_PROFESOR MARCA# COMITET# MARCA# NUME_CATEDRA, CURS# MARCA# ZI_INTILNIRE MARCA# ORA_INTILNIRE MATRIC# NUME_STUDENT MATRIC#, NUME_CATEDRA, CURS# GRAD NUME_CATEDRA, CURS# TEXT Putem acum determina c relaia FACULTATE_1 nu este n 2NF, deoarece exist atribute non cheie care nu sunt determinate de ntreaga cheie primar. De exemplu:

147

NUME_PROFESOR este dependent funcional de numai o parte a cheii: MARCA#. NUME_STUDENT este dependent funcional de numai o parte a cheii: MATRIC#. GRAD este dependent funcional de numai o parte a cheii: MATRIC#, NUME_CATEDRA, CURS#. TEXT este dependent funcional de numai o parte a cheii: NUME_CATEDRA, CURS#. Producerea 2NF. O relaie poate fi rezolvat n 2NF imprind-o n relaii componente, fiecare satisfcnd condiia 2NF. Relaia R (A, B, C, D) cu dependenele: AC A, B D poate fi separat n dou relaii: R1 (A, C); R2 (A, B, D);

148

FACULTATE_1
NUME_ PROF.

MARC A#
12751

NUME_ STUDENT

MATRIC#

NUME_ CATEDRA

CURS

TEXT

GRAD

COMITET#

ZI_ ORA_ INTILNIRE INTILNIRE

Luca

Matei Novac

21936 51326

Albu Barbu Tatu Albu Sandu

469213 532162 112146 469213 513251

IT IT MF EG IT

231 231 201 512 531

Unu Unu Doi Patru Unu

A B B A A

12 20 12 20 18 5

L J L J J V

9 8 9 8 9 8

Oprea

31962

Cociu 219623 MF 200 Doi A Lupu 319216 EG 512 Patru B Fig.6.1. Tabela de instane pentru relaia FACULTATE_1. FACULTATE_1
NUME_ MATRIC# NUME_ STUDENT CATEDRA CURS TEXT GRAD COMITET#

NUME_ PROF.

MARC A#
12751 12751 12751 21936 51326 51326 51326 31962 31962

ZI_ ORA_ INTILNIRE INTILNIRE

Luca Luca Luca Matei Novac Novac Novac Oprea Oprea

Albu Barbu Tatu Albu Sandu Sandu Sandu Cociu Lupu

469213 532162 112146 469213 513251 513251 513251 219623 319216

IT IT MF EG IT IT IT MF EG

231 231 201 512 531 531 531 200 512 97

Unu Unu Doi Patru Unu Unu Unu Doi Patru

A B B A A A A A B

12 20 20 12 20 18 5 5

L J J L J J V V

9 8 8 9 8 9 8 8

Fig.6.2. Tabela de instane pentru relaia FACULTATE_1 n 1NF.

98

Rezolvarea relaiei FACULTATE_1 d urmtoarele patru relaii:

FACULTATE_2 (MARCA#, NUME_PROFESOR, COMITET#, ZI_INTILNIRE, ORA_INTILNIRE, NUME_CATEDRA, CURS#); STUDENT (MATRIC#, NUME_STUDENT); CURS_STUDENT (NUME_CATEDRA, CURS#, MATRIC#, GRAD); CURS (NUME_CATEDRA, CURS#, TEXT);

n toate relaiile, toate atributele non cheie sunt dependente de ntreaga cheie primar. S notm c NUME_CATEDRA , CURS# este un atribut cheie strin compus n FACULTATE_2 , care arat o relaie unu-lamai-muli ntre CURS i FACULTATE_2. Ea este de asemenea un atribut cheie strin compus n relaia CURS_STUDENT. CURS_STUDENT are un alt atribut cheie strin, MATRIC#, care arat o relaie unu-la-mai-muli i ntre STUDENT i CURS_STUDENT. Fig.6.3. este o diagram model de date pentru relaia FACULTATE_1 iar fig.6.4. este o diagram model de date pentru mulimea de relaii 2NF rezultate din rezolvarea n 2NF a lui FACULTATE_1. O relaie 1NF cu o cheie dintr-un singur atribut este ntotdeuna n 2NF. Atributul respectiv fiind cheia primar, nu vor putea exista dou linii ale relaiei pentru care atributul respectiv s aib aceai valoare, ca atare orice alt atribut va fi dependent funcional de acesta.

Facultate_1
Marca# Matric# Nume_catedr Curs# Nume_profesor Nume_student(0) Text(0) Grad(0) Comitet#(0) Zi_ntlnire(0) Ora_ntlnire(0)

Fig.6.3. Model de date logic corespunztor lui FACULTATE_1 (n forma din 1NF). Obiectivele lui 2NF. Cele dou raiuni pentru a folosi relaii 2NF n loc de relaii 1NF sunt:

100

 semantica unei relaii 2NF este mai explicit - toate atributele sunt dependente de ntreaga cheie primar; o baz de date proiectat cu relaii 2NF ca evita anumite anomalii de actualizare prezente n relaiile 1NF. Schema unei relaii 1NF nu permite stabilirea dependenelor funcionale dintre atribute. Pe de alt parte, cunoscnd c o relaie este n 2NF tim c orice atribut non cheie este dependent de ntreaga cheie. Actualizarea faptelor ntr-o relaie 1NF poate cauza anomalii care nu apar n cazul 2NF. Aceste situaii pot apare atunci cnd se insereaz noi linii, se terg linii sau se modific linii. Curs Nume_catedr Curs# Z este predat de Facultate_2 Marca# Nume_profesor Comitet#(0) Zi_ntlnire(0) Ora_ntlnire(0) Nume_catedr(Fk,0) Curs#(Fk,0) Text a nrolat ia Student Matric# Nume_student

Curs_student Nume_catedr(Fk,0) Curs#(Fk) Matric#(Fk) Grad

Fig.6.4. Model de date logic a lui FACULTATE_1 normalizat n 2NF. S considerm din nou relaia FACULTATE_1, care este n 1NF. Nu este posibil inserarea unei noi linii pentru un profesor care nc nu are studeni nscrii la cursul pe care l pred. MATRIC# este o parte a cheii prmare i deci nu poate avea valoare nul. Similar, o linie pentru un student nou nu poate fi inserat pn cnd acesta nu s-a nscris la un curs. Dac o linie din relaia FACULTATE_1 pentru un profesor dat se terge i ea este singura linie pentru un anumit student, informaia despre acesta va fi de asemenea pierdut, chiar dac intenia a fost tergerea informaiei despre profesor. Un MATRIC# nu poate exista n relaie fr a fi 101

asociat cu un MARCA#, NUME_CATEDRA i CURS#, deoarece toate aceste patru atribute formeaz cheia primar. Dac este necesar s modificm numele unui student, atunci orice linie din FACULTATE_1 n care apare numele studentului trebuie s fie modificat, altfel relaia va conine date contradictorii. Studentul poate apare n mai multe linii, deoarece el poate lua mai multe cursuri. Sprgnd relaia FACULTATE_1 n FACULTATE_2 i STUDENT evitm aceste probleme. Argrumente similare pot fi aduse pentru spargerea n relaiile CURS_STUDENT i CURS. 6.5. A treia form normal O relaie este n a treia form normal (3NF) dac i numai dac ea este n a doua form normal i nici un atribut non cheie nu este dependent tranzitiv de cheia primar. Adic, o relaie 3NF nu poate avea nici un atribut non cheie dependent de un alt atribut non chie. De exemplu, relaia precedent
FACULTATE_2 (MARCA#, NUME_PROFESOR, COMITET#, ZI_INTILNIRE, ORA_INTILNIRE, NUME_CATEDRA, CURS#);

nu este n 3NF dac au loc urmtoarele dependene funcionale n plus fa de cele deja introduse: COMITET# ZI_INTILNIRE COMITET# ORA_INTILNIRE Dou din atributele non cheie (ZI_INTILNIRE, ORA_INTILNIRE) sunt dependente de alte atribute non cheie (COMITET#). S presupuem c celelalte atribute non cheie nu sunt interdependente. Producerea 3NF. O relaie poate fi rezolvat n 3NF mprind-o n relaii componente, fiecare satisfcnd condiia de 3NF. Relaia R (A, B, C) cu dependenele: AB BC AC poate fi divizat n dou relaii: R1 (A, B) R2 (B, C) Rezolvarea relaiei FACULTATE_2 d urmtoarele dou relaii:
COMITET (COMITET#, ZI_INTILNIRE, ORA_INTILNIRE);
FACULTATE_3 (MARCA#, NUME_PROFESOR, COMITET#, NUME_CATEDRA, CURS#);

S notm c atributul COMITET# a fost reinut n relaia FACULTATE_3; el este un atribut cheie strin pentru relaia COMITET. Fr COMITET# n

102

relaia FACULTATE_3 nu este posibil stabilirea comitetului asignat unui profesor. Fig.6.5. prezint un model pentru mulimea rezultat de relaii 3NF.

103

Comitet Comitet# Zi_ntlnire Ora_ntlnire Z Z Nume_catedr Curs# Text a nrolat ia este predat de

Student Matric# Nume_student

este compus din Facultate_3 Marca# Nume_profesor Comitet#(Fk,0) Nume_catedr(Fk,0) Curs#(Fk,0) 104

Curs_student

Nume_catedr(Fk,0) Curs#(Fk) Matric#(Fk) Grad

Fig.6.5. Model de date logic normalizat n 3NF.

105

O relaie 2NF cu numai un atribut non cheie (sau cu nici unul) este ntotdeuna o relaie 3NF. Nici un atribut non cheie nu poate fi dependent de un altul dac nu exist cel puin dou atribute non cheie n relaie.

Obiectivele lui 3NF. Cele dou raiuni principale pentru folosirea de relaii 3NF n locul celor 2NF sunt: semantica unei relaii 3NF este mult mai explicit - toate atributele sunt dependente numai de cheia primar; baza de date proiectat cu relaii 3NF va evita numite anomalii de actualizare prezente la relaii 2NF. Schema unei relaii 2NF nu specific dac atribute non cheie sunt dependente de alte atribute non cheie. De pe alt aprte, cunoscnd faptul c o relaie este n forma 3NF tim c nici un atribut non cheie nu este dependent de un alt atribut non cheie. Anumite situaii de anomalie apar la actualizarea unor fapte ntr-o relaie 2NF i sunt evitate n cazul relaiilor 3NF. Acestea apar atunci cnd se insereaz linii noi, se terg linii sau se modific linii n anumite condiii i sunt aproape similare cu anomaliile care apar n actualizarea relaiilor 1NF. S considerm relaia FACULTATE_2 care este 2NF. Nu este posibil inserarea unor informaii despre ziua i ora ntlnirii unui nou comitet pn cnd nu exist profesori asignai acestui comitet; adic, datele despre comitete nu pot exista fr a avea o marc asociat. Dac o linie FACULTATE_2 pentru un profesor dat este tears i se ntmpl ca ea s fie singura linie pentru un anumit comitet, atunci datele despre acel comitet se vor peirde, chiar dac intenia a fost acea de a terge date despre profesor. Aceasta are loc deoarece un comitet nu poate exista fr a avea o MARCA# asociat. Dac este necesar schimbarea orei de ntlnire a unui comitet, orice linie din FACULTATE_2 n care acest comitet apare va trebui modificat, altfel relaia va conine date contradictorii. Comitetul poate apare n mai multe linii, deoarece mai muli profesori pot fi asignai la el. Sprgnd relaia FACULTATE_2 n relaiile FACULTATE_3 i COMITET evitm aceste probleme.

106

6.6. Forma normal Boyce-Codd Forma normal Boyce-Codd BCNF este o variant a lui 3NF, lund n considerare i posibila existen a unor chei candidate. Nu toate relaiile aflate n BCNF sunt n 3NF i nu toate relaiile din 3NF se afl n BCNF. Totui BCNF este considerat mai puternic prin adecvarea mai bun la situaiile reale. Un atribut sau un set de atribute de care este complet dependent funcional un alt atribut se numete determinant. O relaie este n BCNF dac i numai dac fiecare determinant este o cheie candidat. BCNF difer de 3NF n aceea c ea cere o dependen funcional complet pentru fiecare cheie candidat, pe cnd 3NF cere o astfel de dependen numai pentru cheia primar. Regulile sunt echivalente, dac relaia nu are mai multe chei candidate. Relaiile COMITET i FACULTATE_3 sunt ambele att n 3NF ct i n BCNF, cu mulimea dependenelor funcionale propus. Dac ns se introduce i NUME_PROFESOR ca i cheie candidat pentru relaia FACULTATE_3, aceasta nu mai este n 3NF. COMITET#, NUME_CATEDRA i CURS# sunt determinate de un atribut non cheie NUME_PROFESOR ca i de cheia primar MARCA#. BCNF potrivete aceast anomalie, deoarece NUME_PROFESOR este o cheie candidat. S considerm, de asemenea, urmtoarea relaie: DEALER (ORAS, MASINA, NUME_DEALER); cu dependenele: NUME_DEALER ORAS Fiecare dealer este ntr-un singur oras. MASINA, ORAS NUME_DEALER Pentru fiecare oras i fiecare masin exist un singur dealer autorizat. S presupunem c fiecare main poate fi vndut n mai multe orae i c fiecare ora poate avea mai muli dealer-i autorizai. Cheile candidate sunt ORAS, MASINA i MASINA, NUME_DEALER. Urmtoarea tabel arat dependena atributelor: ORAS Arad Oradea Arad Oradea MASINA Dacia Dacia Aro Aro NUME_DEALER Ionescu Popescu Ionescu Iliescu

Relaia DEALER nu este n BCNF deoarece NUME_DEALER este un determinant dar nu este o cheie candidat.

107

Producerea BCNF. Dac o relaie dat are mai multe chei candidate care coincid n parte n atributele lor, atunci ea trebuie s fie descompus pentru a ajunge BCNF. Dou chei candidate coincid n parte atunci cnd ambele sunt compuse i partajeaz cel puin un atribut. Relaia R (A, B, C) cu dependenele: A, B C CB i cheile candidate A, B, C poate fi descompus n relaiile R1 (B, C) i R2 (A, C). Rezolvnd astfel relaia DEALER, obinem: LOC_DEALER (NUME_DEALER, ORAS); PRODUS (NUME_DEALER, MASINA); O relaie 3NF cu o singur cheie candidat (care este ca atare i cheia primar) este ntotdeuna o relaie BCNF. O relaie 3NF numai cu chei candidate care nu coincid n parte este ntotdeuna n BCNF. Obiectivele lui BCNF. Cele dou raiuni principale pentru a folosi relaii BCNF n loc de relaii 3NF sunt: semantica cheilor candidate multiple este mai explicit - toate atributele sunt dependente numai de chei candidate; baza de date proiectat cu relaii BCNF va evita anumite anomalii de actualizare ce apar la relaii 3NF. Definirea tuturor cheilor candidate ale unei relaii este important atunci cnd se stabilesc aseriuni de unicitate. Aceste aseriuni ar putea fi forate atunci cnd se insereaz, se terg sau se modific linii n relaie. Toate cheile candidate, i nu numai cheia primar trebuie s aib valori unice. Exist anomalii ce apar cnd se actualizeaz fapte ntr-o relaie 3NF i pot fi evitate la relaii BCNF. De exemplu, n relaia DEALER, nu putem terge faptul c Dacia este vndut n Oradea. MASINA este parte a cheii. Neconsidernd chei candidate ea este desemnat ca i cheie primar. O informaie ora i o informaie dealer nu pot exista fr informaie main, cci MASINA nu poate fi nul. Similar, nu este posibil inserarea informaiei cum c Milescu este dealer la Arad fr a desemna i MASINA. Problema este c NUME_DEALER este un determinant, dar nu o cheie candidat, astfel c relaia nu este n BCNF. Nu exist atribute non cheie dependente de alte atribute non cheie (NUME_DEALER), atributul ORAS dependent funcional de NUME_DEALER fiind parte din cheie. Relaia e deci n 3NF. Sprgnd relaia n LOC_DEALER i PRODUS vom evita aceste probleme. 6.7.A patra form normal

108

O relaie este n a patra form normal (4NF) dac i numai dac ori de cte ori exist o dependen multivaloric de un determinant, toate atributele sunt dependente funcional de determinant. O relaie 4NF nu poate avea mai mult de o dependen multivaloric. De exemplu, s considerm din nou relaia FACULTATE_3 (MARCA#, NUME_PROFESOR, COMITET#, NUME _CATEDRA, CURS#); Dependenele indicau c un profesor este asignat unui singur comitet i pred un singur curs. S schimbm situaia astfel nct un profesor s poat fi asignat la mai multe comitete i s predea mai multe cursuri, introducnd astfel dou dependene multivalorice: MARCA# COMITET# MARCA# NUME_CATEDRA, CURS# Relaia trebuie s aib acum pentru cheia sa pe MARCA#, COMITET#, NUME_CATEDRA, CURS#. Relaia nu este n 4NF, cci ea conine mai mult de o dependen multivaloric. De fapt ea nu este nici mcar n 2NF deoarece axist un atribut non cheie dependent de numai o parte a cheii. Desprind atributul care este dependent numai de MARCA# de rest, obinem dou relaii:
FACULTATE (MARCA#, NUME_PROFESOR) FACULTATE_4 (MARCA#, COMITET#, NUME_DEPARTAMENT, CURS#);

FACULTATE este acum n 4NF, din urmtoarele motive: conine numai atribute cu o singur valoare; fiecare atribut non cheie este dependent de ntreaga cheie; nu exist dependene ntre atribute non cheie; nu exist dependene multivalorice. FACULTATE_4 este n BCNF, dar nu este n 4NF. Dependenele implic faptul c mulimea valorilor COMITET# asociate cu o valoare MARCA# dat este total independent de mulimea valorilor NUME_CATEDRA, CURS# asociate cu acea valoare MARCA#. NU exist nici o dependen ntre COMITET# i NUME_CATEDRA, CURS#. Dac nu ar fi aa, nu ar fi dou dependene multivalorice. Producerea 4NF. O relaie ca aceasta poate fi rezolvat n 4NF prin descompunere n relaii care satisfac fiecare 4NF. Relaia R (A, B, C) cu dependenele: A B

109

A C poate fi mprit n dou relaii R1 (A, B) i R2 (A, C). Rezolvarea relaiei FACULTATE_4 va duce la dou relaii: FACULTATE_COMITET (MARCA#, COMITET#); FACULTATE_CURS (MARCA#, NUME_DEPARTAMENT, CURS#); S notm c MARCA# este un atribut cheie strin n ambele relaii. COMITET# este atribut cheie strin n FACULTATE_COMITET i NUME_CATEDRA, CURS# este atribut cheie strin compus n FACULTATE_CURS. Aceste atribute cheie strin reprezint relaiile de conectare n mulimea relaiilor. Fig.6.6. prezint un model de date pentru o mulime complet de relaii 4NF.

110

Marca#(Fk) Comitet#(Fk)

Marca#(Fk) Nume_catedr(Fk) Curs#(Fk)

Nume_catedr(Fk) Curs#(Fk) Matric#(Fk) Grad

Comitet Comitet# Zi_ntlnire Ora_ntlnire Z

Profesor_membru Marca# Z Nume_profesor

Curs

Student Matric#

Nume_departament# Curs# Text

Nume_student

este compus din

servete n pred

este predat de

a nrolat

ia

Facultate_Comitet

Facultate_Curs

Curs_student

111

Fig.6.6. Model de date logice, normalizat n 4NF n cazul adugrii de dependene multivalorice

112

Obiectivele lui 4NF. Cele dou raiuni principale pentru a prefera relaii 4NF n loc de relaii BCNF sunt: semantica unei relaii 4NF este mai explicit - toate dependenele sunt nlnuite; o baz de date proiectat cu relaii 4NF va evita anumite anomalii de actualizare prezente n 3NF precum i n BCNF. Schema unei relaii BCNF nu evideniaz dependenele multivalorice i nici dac componentele cheii primare sunt mutual independente. De pe alt parte, tiind c o relaie este n 4NF suntem asigurai c nici o component a cheii nu este independent de orice alt component. S urmrim ce tipuri de anomalii ce pot aprea la actualizarea unei relaii BCNF sunt evitate n cazul relaiilor 4NF. Aceste situaii pot aprea att la inserarea de linii noi, la tergerea de linii ct i la modificarea unor linii i sunt similare cu anomaliile care le-am trecut n revist n cazurile 1NF, 2NF i 3NF. S considerm relaia FACULTATE_4, care este n BCNF. S presupunem c profesorul cu MARCA# = 12345 pred cinci cursuri i servete n patru comitete. Nu este posibil inserarea unor date despre asignarea profesorului la un alt comitet fr a insera cinci linii, cte una pentru fiecare curs pe care profesorul numit l pred. Aceleai valori NUME_CATEDRA, CURS# trebuie s existe n relaie pentru fiecare valoare COMITET# asociat cu MARCA#. Dac o asignare de comitet pentru profesorul numit este tears, atunci acea tergere nseamn n fapt tergerea a cinci linii, cte una pentru fiecare curs. Aceeai mulime de valori COMITET# trebuie s existe n relaie pentru fiecare valoare NUME_CATEDRA, CURS# asociate cu MARCA#. Dac este necesar schimbarea unui CURS# pentru un curs predat de profesorul respectiv, atunci aceast schimbare trebuie s se reflecte n patre linii, cte una pentru fiecare comitet pe care l servete profesorul. Din nou, aceeai mulime de valori NUME_CATEDRA, CURS# trebuie s existe n relaie pentru fiecare valoare COMITET# asociat cu MARCA#. Spargerea relaiei FACULTATE_4 n relaiile FACULTATE_COMITET i FACULTATE_CURS evit aceste probleme. 6.8. A cincea form normal O relaie este n a cincea form normal (5NF) dac ea nu poate fi spart n relaii mai mici i apoi reunit fr a-i schimba faptele i semnificaiile. Ea este n forma ei cea mai elementar, reprezentndu-i datele numai prin folosirea a ctorva atribute, ct mai puine posibil. O relaie care este n 5NF este i n 4NF. Deoarece proprietile lui 5NF par a fi neclare, vom explica aceast ultim form normal pe baza unui exemplu mai extins. S considerm relaia: 210

PARADA_CAINI (JUDECATOR, RASA, EVENIMENT); Aceast relaie este n 5NF dac ea nu poate fi descompus fr pierdere n:
ASIGNARE (JUDECATOR, RASA); INTRARE (RASA, EVENIMENT); CALIFICARE (JUDECATOR, EVENIMENT);

Dac relaia iniial nu era n 5NF, cele trei relaii de mai sus se vor putea reuni pentru a forma o relaie cu trei atribute cu exact aceai tabel de instane ca i cea a relaiei PARADA_CAINI. Dac PARADA_CAINI este n 5NF atunci cele trei atribute combinate sunt necesare pentru a exprima semantici valide. Dac este n 5NF, PARADA_CAINI poate fi interpretat incluznd aseriuni ca: o persoan este calificat pentru a juriza evenimente despre anumite rase; numai anumitor rase li se pot asigna anumite evenimente. O tabel de instane valide este dat n fig.6.7. PARADA_CAINI RASA Ciobanesc german Pudel Ciobanesc german Pudel St.Bernard Ciobanesc german Pudel Pudel

JUDECATOR Albu Albu Morar Morar Morar Petrisor Vasiu Vasiu

EVENIMENT Confirmatie Ascultare Ascultare Dresaj Dresaj Confirmatie Dresaj Ascultare

Fig.6.7. Tabela de instane pentru relaia PARADA_CAINI Albu poate judeca evenimentul confirmaie pentru ciobnesc german i evenimentul ascultare pentru pudel dar nu este calificat s judece ascultare pentru ciobanesc german sau confirmatie pentru pudel. Ciobanescul german are intrare pentru evenimentele confirmatie i ascultare, dar nu pentru dresaj. Pe de alt parte, dac relaia PARADA_CAINI nu este n 5NF i poate fi descompus n cele trei relaii ASIGNARE, INTRARE i CALIFICARE i apoi recombinat fr a-i modifica semantica, aseriunea operativ va fi: Dac o persoan este calificat s judece un eveniment i unei rase i se permite s introduc un eveniment atunci persoana este calificat s judece acea ras n respectivul eveniment. Tabelele de instane valide pentru relaiile ASIGNARE, INTRARE i CALIFICARE i rezultatul reuniunii acestor relaii sunt date n tabelele din fig.6.8. S notm diferenele ntre relaia combinat i relaia PARADA_CAINI din fig.6.7. Modelele de date pentru aceste patru relaii sunt prezentate n fig.6.9. 211

O relaie care este n 4NF i are numai dou atribute n cheia sa primar este n 5NF deoarece nu exist nici un mod de a o descompune fr a pierde date.

ASIGNARE JUDECATOR RASA Albu Ciobanesc german Albu Pudel Morar Ciobanesc german Morar Pudel Morar St.Bernard Petrisor Ciobanesc german Vasiu Pudel

INTRARE RASA EVENIMENT Ciobanesc german Confirmatie Ciobanesc german Ascultare Pudel Ascultare Pudel Dresaj St.Bernard Dresaj

CALIFICARE EVENIMENT

JUDECATOR
Albu Albu Morar Morar Petrisor Vasiu Vasiu Confirmatie Ascultare Ascultare Dresaj Confirmatie Dresaj Ascultare

Fig. 6.8.a. Tabele de instane pentru trei relaii binare proiectate din PARADA_CAINI

Obiectivele lui 5NF. Exist trei raiuni principale pentru a prefera relaii 5NF n locul celor din 4NF. semantica lui 5NF este mai explicit - nu exist dependene nelegate ntre grupuri de atribute;

212

 o baz de date proiectat cu relaii 5NF va evita anumite anomalii prezente la relaii 4NF; relaiile 5NF sunt n forma cea mai granular i aceasta este un avantaj la modificri ulterioare ale schemei. Judector Nume_judector Rasa Nume_rasa

poate judeca Parada_cini

poate introduce Nume_judector(Fk) Nume_rasa(Fk) Nume_eveniment(Fk)

poate avea Eveniment Nume_eveniment

Fig. 6.9.a Exist anomalii ce apar la actualizarea unor relaii din 4NF care pot fi evitate la relaiile din 5NF. Ele apar att la inserare de linii noi, ct i la tergere sau modificare de linii i sunt aproape similare cu cele de la formele normale precedente. n relaiile 4NF, anomaliile sunt cauzate de redundane n tabela de instane a relaiei.

213

Judector Nume judector

Rasa Nume rasa

Eveniment Nume eveniment

poate judeca

este judecat de

poate introduce Intrare

poate avea

Parada_cini Nume_judector(Fk) Nume_rasa(Fk) Nume_eveniment(Fk)

Nume_rasa(Fk) Nume_eveniment(Fk)

Calificare Nume_judector(Fk) Nume_eveniment(Fk) este judecat de

poate judeca

Fig.6.9. Dou modele de date logice reprezentnd semantici diferite.

214

Reuniunea relaiilor ASIGNARE, INTRARE, CALIFICARE JUDECATOR RASA EVENIMENT Albu Ciobanesc german Confirmatie Albu Ciobanesc german Ascultare Morar Ciobanesc german Ascultare Vasiu Ciobanesc german Ascultare Petrisor Ciobanesc german Confirmatie Albu Pudel Ascultare Albu Pudel Dresaj Morar Pudel Ascultare Vasiu Pudel Ascultare Morar Pudel Dresaj Morar St.Bernard Dresaj
Fig.6.8.b. Proiecii i reuniunea relaiilor binare din relaia PARADA_CAINI

Att 4NF ct i 5NF se ocup de dependene multivalorice i 5NF recunoate c dependene multivalorice pot exista ntre trei sau mai multe atribute pe cnd 4NF recunoate numai perechi de atribute cu dependene multivalorice. 6.9. Procesul de normalizare Normalizarea relaional poate fi abordat prin sintez sau descompunere. Sinteza. Sinteza ncepe cu o mulime de atribute i o declaraie de dependene i combin atributele astfel nct s rezulte o mulime de relaii normalizate. Aceast abordare a aprut nainte de dezvoltarea formelor normale Boyce-Codd, a patra i a cincea. Deci ea adreseaz n special sinteza relaiilor 3NF. Descompunerea. Descompunerea ncepe cu o mulime de relaii (poate fi i una singur) i o declaraie de dependene i sparge aceste relaii iniiale ntr-o mulime de relaii normalizate. Explicarea formelor normale n acest capitol folosete abordarea bazat pe descompunere. Descompunerea este, n general, preferabil sintezei deoarece algoritmii de sintez folosesc patterne de dependene declarate (i.e. cu sintax) i nu cu semantic. Pe de alt parte, descompunerea folosete atribute n contextul relaiilor, ceea ce ofer un cadru semantic. Presupunerea c toate atributele pot fi considerate ca fiind ntr-o relaie universal are implicaii nedorite. Astfel, identificarea gruprilor iniiale de atribute din relaii care au sens semantic ca entiti, nainte de aplicarea procedurii de descompunere poate fi complicat. n cap.9. vom discuta obinerea acestor relaii.

215

6.10. Aplicaii ale teoriei normalizrii Am vzut mai nainte c normalizarea relaional are ca obiectiv de baz obinerea unor grupri stabile de atribute n relaii i c exist dou motivaii primare pentru acest obiectiv: proiectarea bazei de date logic extensibil i proiectarea bazei de date fizic flexibil. Modelarea datelor logice. Normalizarea relaional ajut la stabilirea rspunsului la ntrebarea ce se pune n modelarea datelor logice: Ce este o entitate bine definit? Dac obiectivul normalizrii este reformulat ca obinerea de grupri stabile de atribute n entiti, atunci aplicabilitatea normalizrii relaionale n proiectarea bazelor de date logice devine mai evident. Fiecare relaie ntr-un model normalizat reprezint o entitate; deci normalizarea relaional devine un instrument de modelare date logice. Principiile normalizrii pot fi aplicate pentru a ajuta la determinarea entitii n care ar trebui s rezide un atribut. Fiecare form succesiv de normalizare mrete explicitatea semanticii relaiilor rezultate i mai mult informaie semantic este exprimat de o schem relaional tiind c ea este de o form normal particular. Dac entitile unui model de date logice se conformeaz regulilor normalizrii, atunci modelul poate transmite mai mult informaie semantic dect dac conceptele normalizrii n-ar fi aplicate. Principala dificultate practic ntlnit n aplicarea normalizrii relaionale pentru a construi modele de date logice este identificarea dependenelor funcionale i multivalorice n lumea real. Normalizarea se bazeaz complet pe declaraii valide de dependene; utilizatorii ns pot avea dificulti n dezvoltarea acestor declaraii. Valoarea normalizrii relaionale ca o parte a modelrii datelor logice nu trebuie interpretat ca un sprijin al modelului relaional pentru modelarea datelor logice. De fapt, anumite concepte importante n modelarea datelor sunt dificil de reprezentat n modelul relaional. Un exemplu de concept care nu este bine tratat n modelul relaional este relaia de categorie. Mai mult, regulile de normalizare nu sunt singurele reguli ce pot fi aplicate pentru a identifica entiti stabile, cu toate c alte reguli sunt n afara ariei de interes a textului de fa. Utilitatea normalizrii relaionale pentru modelarea datelor logice este astfel n domeniul intensiunii (i.e. schemei) relaiilor. Proiectarea bazei de date fizice. O justificare major a formelor normale relaionale este evitarea diferitelor anomalii de actualizare. Acestea apar n cazurile n care memorarea faptelor ntr-o baz de date este afecta de structura relaiilor. Utilitatea normalizrii relaionale pentru proiectarea bazelor de date fizice rezid n principal n extensiunea (i.e. populaia) relaiilor. La prima vedere pare ineficient s spargem o tabel n mai multe tabele pentru a satisface restriciile regulilor de normlizare, cu toate c o 216

astfel de descompunere poate nbunti performana prin reducerea numrului de linii din fiecare tabel. Mai important ns, integritatea datelor poate fi meninut mai eficient dac relaiile din baza de date sunt proiectate pentru a satisface regulile normalizrii. Dar proiectarea fizic a bazelor de date relaionale nseamn n fapt mai mult dect identificarea relaiilor de baz. De exemplu, indecii i structurile de cutare pot fi selectate i distribuia relaiilor n fiiere fizice poate fi specificat. n fine s menionm c aplicarea principiilor normalizrii pentru a reduce replicarea datelor poate conduce la baze de date relaionale fizice mai eficiente i mai flexibile. 6.11. Comentarii finale Normalizarea relaional este o abordare riguroas, exact pentru a grupa atribute n relaii stabile i poate fi aplicat proiectrii logice a tuturor bazelor de date, nu numai a celor relaionale. ntrebrile cele mai comune care se pun atunci cnd se descompune o relaie nenormalizat sunt: (1NF) Poate un atribut s aib valori multiple? Dac da, rafinai relaia n 1NF. (2NF) Exist atribute dependente de numai o parte a cheii? Dac da, descompunei relaia pn cnd toate atributele sunt dependente de ntreaga lor cheie. (3NF) Exist atribute dependente de atribute non cheie? Dac da, descompunei relaia pn cnd toate atributele sunt dependente numai de cheia lor. (BCNF) Conine relaia vreo dependen n afara cheilor candidate? Dac da, descompunei relaia pn cnd toate atributele sunt dependente numai de cheile candidate. (4NF, 5NF) Conine relaia dependene multivalorice independente? Dac da, descompunei relaia pn cnd nu mai rmn dependene independente. Probabil modul cel mai simplu de a rezuma regulile de normalizare este: fiecare atribut non cheie este dependent de ntreaga cheie i numai de ea; nici o relaie nu conine dependene nelegate. Memento Form normal Boyce-Codd Cheie candidat Descompunere Determinant Extensiunea unei relaii A cincea form normal (5NF) Prima form normal (1NF) 217 Tabel de instane Intensiunea unei relaii Cheie Dependen multivaloric Normalizare Cheie primar A doua form normal (2NF)

Atribut cheie strin A patra form normal (4NF) Dependen funcional Bibliografie

Sinteza A treia form normal (3NF)

1. Aho, A.V.; Beeri, C.; Ullman, J.D. (1979) The theory of joins in relational databases, ACM Trans. on Database Systems 4 : 297-314. 2. Armstrong, W.W. (1974) Dependency structurea of database relationships, Proc.IFIP Congress. 3. Brown, R.G. (1982) Logical Database Design Techniques, Mountain View, CA: The DBDG July 1982. 4. Codd, E.F. (1979) Extending the database relational model to capture more meaning, ACM Trans. on Database Systems (Dec. 1979) 397-434. 5. *** (1971) Normalized database structure: a brief tutorial, Proc. ACM SIGFIDET. 6. Date, C.J. (1981) Further normalization, Chapter 14 in An Introduction to Database Systems, Addison Wesley, 232-272.

Capitolul 9. O abordare parctic a modelrii datelor logice

n prezentrile noastre legate de o abordare practic a modelrii datelor logice, vom introduce conceptul de echip de modelare, vom enumera rezultatele unui proiect de modelare, vom descrie colecia de date i tehnicile de revizuire a modelului i vom considera tipurile posibile de modele de date logice. Abordarea noastr se face cu Data Modelling Technique (DMT) al lui D. Appleton Company Inc. (DACOM). DMT s-a folosit efectiv ntr-o varietate de organizaii, iar sintaxa grafic a DMT am folosit-o deja n capitolele precedente la diagramarea modelelor de date. Avantajele DMT sunt: modelele sunt dezvoltate de echipe i nu de personal. utilizatorii particip n procesul de modelare. desenele rezultate sunt uor de neles, att de ctre utilizatori ct i de ctre programatori. tehnica distinge diferite nivele de detaliere, care se pot afia n diferite stagii ale procesului de modelare date.

218

 modelele rezultate pot fi folosite pentru a dezvolta proiectri de baze de date fizice pentru o varietate de DBMS-uri. Un proiect DMT produce un model de date logice care este revizuit i validat de ctre experi n domeniu. Un proiect de modelare de date logice este uzual parte a unui proiect mai mare, de exemplu planificarea sau implementarea resurselor de date. Intenia modelului de date determin nivelul de detaliere. 9.1. Echipe de modelare date Cele mai eficiente eforturi de modelare date sunt cele ale unor echipe i nu ale unor personal. Rezultatul este modelul care reflect sinteza unor puncte de vedere variate i nu perspectiva unei singure persoane. Un model de date logice este dezvoltat n cazul optimal de ctre o echip de proiect compus din: un manager de proiect, care este responsabil cu planificarea i controlul muncii echipei proiectului, astfel nct proiectul s se ncadreze n limitele bugetului i timpului afectat. modelatorii, care pun mpreun informaii despre aria de interes care se modeleaz i pregtesc diagramele modelului precum i documentaia. surse, care sunt experi n aria de interes, oferind informaii despre subiectul care se modeleaz. revizori, care sunt experi n subiect, judecnd validitatea diagramelor modelului i a documentaiei. n majoritatea cazurilor aceste responsabiliti pot fi distribuite ntre mai muli participani, cu toate c trebuie s existe un modelator principal i un manager de proiect. Scopul proiectului este de a avea modelul de date aprobat de revizori. Cu toate acestea i revizorii se subordoneaz managerului de proiect. Modelatorii nu trebuie s fie experi n subiectul care se modeleaz, ci trebuie s fie n stare s extrag din surse informaiile necesare pentru a modela aria de interes. Ei sunt responsabili cu structurarea informaiei pe care le-o ofer sursele. n mod tipic, fiecare surs va aduce un punct de vedere diferit n procesul de modelare. Modelatorii sintetizeaz aceste puncte de vedere i extrag semantica datelor. Cel mai ru lucru care se poate ntmpla n procesul de modelare a datelor este de a exclude inputuri de la experi n domeniu. Proiectele de modelare de date logice nu trebuie conduse numai de ctre experin n informatic ci i de ctre utilizatori. 9.2. Ieirile dintr-un proiect de modelare date logice Cele dou ieiri de baz dintr-un proiect de modelare de date logice sunt diagramele modelului de date i un glosar. Tipic, exist mai multe diagrame model de date, fiecare reprezentnd un punct de vedere, i o diagram care 219

reprezint modelul integrat. Modelele intermediare sunt referite n mod normal ca vederi, deoarece ele reprezint puncte de vedere mai degrab dect un model integrat i neutru. Pot exista, de asemenea, diferite nivele de diagramare. Un alt produs al proiectului de modelare date este un glosar, care definete termenii din diagramele modelului. Fiecare entitate i fiecare atribut sunt listate mpreun cu o definiie i descriere scurt i clar. Diagramele i glosarul se pot pregti manual sau cu un suport software. Software-ul pentru a captura definiii i structuri model de date se numete data dictionary system (vezi cap.14). Anumite proiecte de modelare produc, de asemenea, reguli de afaceri care sunt instruciuni despre politicile de afaceri reprezentate ntr-un model de date. Ele trebuie s poat fi uor nelese i verificate de ctre oameni care nu sunt antrenai n sintaxa de modelare date. 9.3. Colectarea datelor de modelat Informaiile pentru proiectul de modelare date pot veni din: citirea documentelor. observarea intreprinderii n operaii. cercetri ale experilor n aria de interes, folosind chestionare. convorbiri cu experii n aria de interes. folosirea a ceea ce se cunoate deja de ctre echipa de modelare. Cea mai important dintre acestea este interaciunea fa n fa cu experii n domeniu. Adesea, toate informaiile necesare pot fi obinute astfel i conductorul proiectului de modelare este capabil s introduc experii n procesul de modelare. Aceasta se va face dificil n acele organizaii n care dezvoltarea de sisteme cade exclusiv n sarcina unui oficiu de calcul. Experii pot fi intervievai fie individual, fie n grup. 9.3.1. Interviuri Interviurile individuale: vor evidenia fapte despre operaiile curente. vor identifica probleme n disponibilitatea datelor curente. vor cuta soluii privitoare la capacitile sistemului viitor. Pregtirile pentru interviu includ: selectarea celor ce vor fi intervievai. stabilirea ntlnirilor. stabilirea agendei. revizuirea informaiilor de fond despre cei intervievai. Pot fi intervievai oameni din diferite arii de responsabilitate i din diferite nivele ale organizaiei. Interviurile cu civa oameni indispensabili pot

220

adesea aduce mai multe informaii dect cele cu muli oameni care sunt mai vag familiari cu aria de interes. Interviurile pot dura ntre o jumtate de or i o or. Agenda interviurilor include: domeniul, obiectivele i punctul de vedere al proiectului de modelare. scopul interviului. ntrebri generale despre aria de interes. ntrebri specifice despre aria de interes. Cei care fac interviuri trebuie s fie familiarizai cu terminologia folosit n aria de interes. Ei trebuie s neleag prile pertinente ale structurii organizaiei i s aib idee despre funciile realizate de ctre persoana intervievat. Dac este un al doilea interviu, rezultatele precedentului trebuie revzute. nregistrarea interviului este mai uoar dac majoritatea ntrebrilor au fost decise dinainte, precum i dac cei care fac interviurile lucreaz n perechi, una ntrebnd i cealalt nregistrnd. nregistrarea se poate face i sub forma schielor de diagrame. Dup interviu, echipa de modelare trebuie s sintetizeze informaiile, s schieze diagramele modelului i glosarul, s le revizuiasc cu sursele. 9.3.2. Sesiuni de modelare n grup O sesiune de modelare n grup pune mpreun ntre trei i apte experi n domeniu pentru a schia o poriune a modelului de date logice. Aceti experi reprezint, n general, o singur arie funcional. O sesiune de modelare n grup cere aceeai pregtire minuioas ca i interviurile. Sesiunile pot fi inute ntr-o camer cu tabl sau cu hrtie mare, etc. pentru a nregistra schiele de diagrame ale modelului, pe msur ce sunt create. O sesiune de modelare n grup este condus uzual de ctre doi membrii ai echipei de modelare. Un modelator ntreab i apoi schieaz modelul de date implicat, iar cellalt nregistreaz definiiile i problemele nerezolvate. 9.4. Gestionarea unui proiect de modelare date nainte de a planifica un proiect de modelare date, managerul de proiect trebuie s discute domeniul proiectului, obiectivele lui i punctele de vedere cu oamenii care au iniiat proiectul. Dac proiectul de modelare date este parte a unui proiect mai mare care planific sau implementeaz resursele de date, atunci managerul trebuie s neleag necesitile. De exemplu, poate fi vorba de un proiect mare de planificare date, care folosete modele de date de nivel nalt pentru a defini n continuare proiecte de implementri de baze de date. Sau ar putea fi vorba de un proiect mai mare de implementare de baze 221

de date care folosete modele detaliate de date pentru a dezvolta proectri de baze de date logice i fizice. Domeniul proiectului determin tipurile de date necesare echipei proiectului. De exemplu, un domeniu al modelului ar putea fi toate datele legate de contabilitate iar obiectivul ar putea fi s ajute la identificarea proiectelor de implementare baze de date pentru integrarea automat a datelor de contabilitate ale bncii. Un alt domeniu al modelului ar putea fi contractele de marketing i datele de vnzare iar obiectivul lui ar putea fi susinerea proiectrii logice i a implementrii fizice pentru baza de date cu contracte de marketing, care este integrat logic cu celelalte baze de date legate de vnzri ale organizaiei. Managerul de proiect pregtete planul proiectului, indicnd sarcinile care trebuie realizate, bugetul i planificarea pentru fiecare dintre ele. Domeniul modelului, obiectivele i punctele de vedere constituie ghidul managerului de proiect. Managerul se ghideaz, de asemenea, dup nivelul dorit de detaliere n modelul final de date i dup faptul dac modelul va fi integrat sau nu cu alte modele de date disponibile. Dac, pentru aria de interes, este disponibil un model de proces sau de funcionare el poate fi folosit pentru a identifica domeniile vederilor intermediare i strategia pentru a integra acele vederi. De exemplu, arborele din fig.9.1. prezint faptul c gestionarea conturilor - cecuri cuprinde patru activiti: deschiderea de noi conturi, conturi de debit/credit, rapoarte stare conturi i cretere servicii conturi. Fiecare vedere ca fi dezvoltat de ctre oamenii care realizeaz activitatea pertinent i va modela datele necesare pentru susinerea acelei activiti. Cele patru vederi individuale luate mpreun vor reprezenta datele necesare pentru a susine gestionarea cecurilor pe conturi. Gestionarea cecurilor pe conturi

Deschidere de noi conturi

Conturi de debit/credit

Rapoarte stare conturi

Creterea serviciilor de conturi

Fig.9.1. Arbore de activiti. 222

Managerul de proiect asigneaz persoanele care acioneaz ca modelatori, ca surse i ca revizori, care n mod uzual sunt luai din mai multe departamente sau uniti organizatorice. Anumite oficii de calcul (sau departamente de procesare de date) au un grup de experi modelatori de date, care pot fi asignai proiectelor de modelare date ale utilizatorilor. 9.5. Dezvoltarea vederilor modelului de date Exist patru etape ale crerii unei vederi a modelului de date: 1. dezvoltarea unei vederi entitate - relaie, care reprezint modelul la nivelul cel mai superficial de entiti i relaii. 2. redactarea unei vederi bazate pe chei. 3. producerea unei vederi normalizate, cu toate atributele. 4. adugarea detaliilor de tranzacii i de volum pentru a susine informaia ntr-o proiectare de baz de date fizic. O parte a planificrii proiectului o constituie determinarea nivelului potrivit de detaliere pentru modelele livrate. Vederile entitate - relaie pot fi eficiente pentru comunicaii spre direciune, vederile bazate pe chei sunt eficiente pentru eforturile de planificare date, iar vederile cu atribute complete sunt necesare pentru eforturile de implementare baze de date. 9.5.1. Dezvoltarea vederilor entitate - relaie Modelatorii analizeaz materialul disponibil i redacteaz o vedere coninnd entiti i relaii. Materialul disponibil se obine intervievnd utilizatorii, studiind procedurile, formele i rapoartele pertinente precum i participnd la sesiunile de modelare. n primul rnd, experii n aria de interes sunt ncurajai, s discute aria lor de expertiz. Modelatorii ntreab: Ce tipuri de date sunt necesare pentru activitile din aceast arie de interes? Ce tipuri de date sunt produse de aceste activiti? Obiectivul este de a identifica obiecte, concepte, persoane, lucruri sau evenimente din domeniul modelului. Modelatorul listeaz entitile candidate pe msur ce ele sunt descoperite, fiecare entitate candidat trebuie s aib un nume de substantiv. Fiecare entitate candidat este verificat pentru identificare. Modelatorii ntreab: Cum este distins o instan a acestei entiti candidate de o alta? Nu se selecteaz chei primare, dar existena unei chei primare trebuie s fie validat pentru fiecare entitate, ca o verificare a statutului acesteia de entitate.Anumite entiti candidate sunt scoase de pe list. De exemplu, ANGAJAT este o antitate candidat rezonabil, cci angajaii se disting prin SSN# sau prin MARCA#, sau prin alt identificator. 223

Tag

Cerere Cump- Vnzcump- rtor tor rare x x x x x x

Ordin cumprare

Parte

Aprobare

Entitate Cerere cumprare Cumprtor Vnztor Ordin cumprare Parte Aprobare

1 2 3 4 5 6

x x x

Fig.9.2. Matrice entitate pentru a identifica relaiile Pe de alt parte, PROBLEMA ar putea s nu fie o entitate candidat rezonabil. Relaiile entitii sunt identificate cu ajutorul schielor de diagrame ale modelului. Cteodat, o matrice entitate entitate (fig.9.2.) este util pentru a ajuta la a decide dac o entitate este legat de alta. n tabelul de mai sus, un x marcheaz o pereche de entiti legate. Modelatorii i sursele determin apoi natura fiecrei relaii i i asigneaz cte un nume potrivit. Modelatorul pune dou tipuri de ntrebri care vor ajuta la identificarea relaiilor de categorie, de conectare i a entitilor adiionale. Care entiti sunt subtipuri ale cror entiti? Exist categorii de entiti? Care entiti sunt acelai tip de obiect? Care entiti sunt tipuri diferite de lucruri, dar sunt asociate ntre ele? Ce propoziie poate fi folosit pentru a lega numele entitilor prin verbe? De exemplu, prima mulime de ntrebri poate ajuta la identificarea a dou entiti subtipuri ANGAJAT_PERMANENT i ANGAJAT_CU_ORA ca i categorii pentru ANGAJAT. A doua mulime de ntrebripoate ajuta la identificarea relaiei LUCREAZA_LA ntre entitile ANGAJAT i PROIECT. Fiecare relaie de categorie este schiat pe diagram cu entitile sale generic i subtipuri. La fel, i fiecare relaie de conectare este schiat pe diagram cu entitile sale legate u cu un nume de verb.

224

Aria_afacerii

Proiect are buget n

Cont_natural

are

Proiect_direct

Proiect_indirect

Fig.9.3. Diagram entitate - relaie. Terminatorii de baz se adaug apoi la relaiile de conectare i fiecrui capt al unei relaii de conectare i se ataeaz simbolul indicnd unu sau mai muli. Modelatorul ntreab, de exemplu: Poate un angajat s lucreze la mai multe proiecte sau numai la unul? Poate un proiect s aib mai muli angajai care lucreaz la el sau numai pe unul? O diagram entitate - relaie este prezentat n fig.9.3. Modelatorii i sursele definesc apoi fiecare entitate din vedere. Modele preexistente pot fi consultate pentru a vedea dac definiiile pentru enumite entiti cu nume sunt potrivite. Dificultatea n dezvoltarea de definiii nu trebuie subestimat. n general, e mai greu ca oamenii din diferite pri ale unei organizaii s fie de acord cu o definiie, dect cu nume de entiti sau relaii.

9.5.2. Dezvoltarea vederilor bazate pe chei O vedere bazat pe chei este mult mai detaliat dect o vedere entitate relaie, cci ea reprezint o nelegere mai profund a semanticii datelor. Modelatorii rezolv la nceput toate relaiile nespecifice din vederea entitate - relaie. Cele mai comune relaii nespecifice sunt relaiile mai-muli-

225

la-mai-muli, unu-la-unu i zero-sau-unu-la-mai-muli. Relaiile mai-muli-lamai-muli i zero-sau-unu-la-mai-muli se elimin prin introducerea entitilor intersecie i a relaiilor specifice (vezi fig.9.4.). Relaiile unu-launu se elimin colapsnd entitile ntr-o singur entitate sau introducnd o relaie zero-sau-unu-la-unu. Modelatorii lucraz apoi de sus n jos pe model, examinnd fiecare entitate i ntrebnd: Ce atribut are valori care identific unic instanele acestei entiti? Ce grup de atribute are valori care mpreun identific unic instanele acestei entiti? Care este identificatorul primar? Astfel, modelatorii specific cheia primar i orice chei alternate. Atributele de cheie primar sunt migrate apoi prin relaii n entitile dependente, unde ele devin atribute de cheie strin, care la rndul lor pot fi parte a cheii primare din entitatea dependent. Numele de roluri se asigneaz atunci cnd este necesar. Pentru fiecare atribut de cheie strin, modelatorii ntreab: Exist un nume mai bun pentru a exprima semnificaia acestui atribut i rolul su n stabilirea unei relaii cu entitatea tat? Modelatorii urmresc n de aproape entitile la care un atribut migreaz prin mai multe relaii diferite. n aceste cazuri, numele de roluri trebuie definite dac dou apariii ale unui atribut trebuie pstrate separat. Modelatorii ntreab:

226

A R

C Z

C A

R1

R2

Z CD_RES

AB_RES

Fig.9.4. Rezolvarea relaiilor nespecifice. Aceste dou apariii ale atributului A au ntotdeuna valori care se potrivesc n orice instan a acestei entiti? Au ele aceeai semnificaie sau au semnificaii diferite? Fig.9.5. ilustreaz vederea bazat pe chei care rezult din rafinarea vederii entitate - relaie din fig.9.3. Apoi pot fi pregtite regulile de afaceri. Aceste instruciuni citesc relaiile de pe diagram, dup cum urmeaz: o structur de categorie cu entitatea generic A i entitile subtipuri B, C, D, ... produce urmtoarea regul de afaceri: Un <A> poate fi un <B> sau un <C> sau un <D> sau un ...

227

De exemplu un <angajat> poate fi un <angajat permanent> sau un <angajat cu ora> o relaie de conectare mai-muli-la-mai-muli ntre entitile A i B produce urmtoarea regul de afaceri: Un <A> <R> mai muli <B>; Un <B> <R> mai muli <A>. De exemplu, un <angajat> <poate lucra la> mai multe <proecte>; un <proiect> <poate fi lucrat de> mai muli <angajati>. o relaie unu-la-mai-muli ntre entitile A i B produce urmtoarea regul de afaceri: Un <A> <R> mai muli <B>; fiecare <B> <R> un <A>.

Aria_afacerii Aria_Id

Proiect Proiect#

Cont_natural Cont#

Buget are Proiect# Cont#

Proiect_direct Proiect# Aria_Id

Proiect_indirect Proiect#

Fig.9.5. Vedere bazat pe chei, corespunztoare fig.9.3. De exemplu, un <departament> <angajeaz> mai muli <angajai>; fiecare <angajat> <este angajat> de un <departament>. Regulile de afaceri sunt teste asupra calitii numelor modelului i asupra validitii relaiilor modelului. Dac regulile de afaceri nu sunt semnificative, numele pot fi schimbate. Cteva din regulile de afaceri legate de fig.9.5. sunt: Un <proiect> poate fi un <proiect direct> sau un <proiect indirect>. 228

Un <proiect> <are> mai multe <bugete>, fiecare <buget> este ntrun <cont natural>. Un <cont natural> <are> mai multe <bugete>; fiecare <buget> este pentru un <proiect>. O <arie de afaceri> <are> mai multe <proiecte directe>; fiecare <proiect direct> <aparine la> o <arie de afaceri>. Modelatorii i sursele definesc ambii fiecare din noile entiti din vedere precum i nou introdusele atribute. Modelele existente pot fi consultate pentru a determina dac definiiile pentru entitile i atributele numite la fel sunt potrivite. 9.5.3. Dezvoltarea vederilor cu atribute complete Modelatorii i sursele pot acum aduga modelului atributele noncheie, n mod normal prin sesiuni de grup n care experii n aria de interes vorbesc despre tipurile de informaii de care au ei nevoie n fiecare entitate. Modelatorii pun ntrebri care ajut la definirea atributelor noncheie. De exemplu: Ce dorii s cunoatei despre aceast entitate? Care sunt caracteristicile instanelor acestor entiti? Care sunt proprietile acestei entiti? Ce tipuri de fapte trebuie pstrate despre instanele acestei entiti? Modelatorii i sursele definesc apoi fiecare din atribute i le adaug glosarului. Modelele existente pot fi consultate pentru a determina dac definiiile lor pentru atribute cu aceleai nume sunt potrivite. La fel ca i pentru definiiile entitilor, procesul de definire a atributelor poate fi dificil n decizie. Modelatorii i sursele adaug, de asemenea, cardinaliti precise relaiilor de conectare. Pentru fiecare relaie unu-la-mai-muli ntre entitile A i B modelatorii ntreab: Poate aceast relaie fi fcut mai precis? Trebuie ca o instan a lui A s fie legat la cel puin o instan a lui B? Trebuie ca o instan a lui A s fie legat la exact zero sau o instan a lui B? Relaia este indicat ca avnd o cardinalitate pozitiv (unu-la-unusau-mai-muli), o cardinalitate exact (n), o cardinalitate minimal (unu-lazero-sau-unu) sau o cardinalitate general (unu-la-mai-muli). Noi entiti pot fi descoperite n timpul documentrii atributelor noncheie i a cardinalitii precise a relaiilor. Modelatorii pun ntrebri care confirm faptul c atributele au fost plasate n entitile corecte i pentru a descoperi orice entiti ascunse. Aceste ntrebri adreseaz: atributele cu valori multiple atributele cu valori nule interaciunile ntre atributele de cheie primar interaciunile ntre atributele noncheie. 229

Aceste ntrebri au intenia de a da echipei de modelare oportunitatea de a reexamina munca lor i de a detecta orice entitate uitat din eforturile precedente de modelare. 9.5.4. Atribute cu valori multiple n cap.4. am artat c orice instan de entitate poate avea numai o valoarea pentru fiecare din atributele sale. Aceast regul nici o repetiie se aplic atributelor fiecrei entiti din model, ca parte a validitrii faptului c toate entitile au fost descoperite. Modelatorii ntreab: Poate acolo exist mai mult de o valoare a acestui atribut pentru orice instan a entitii? Dac rspunsul este afirmativ, o nou entitate dependent cu o relaie de conectare unu-la-mai-muli poate fi introdus pentru a pstra acest atribut. Un astfel de exemplu este entitatea ORDIN_CUMPARARE prezentat n fig.9.6.a. Dac s-a determinat c atributele STARE i DATA pot cteodat avea mai mult de o valoare pentru o instan dat de ORDIN_CUMPARARE, atunci se pot introduce o nou entitate i o nou relaie, iar atributele care se repet, STARE i DATA, pot fi mutate n noua entitate, aa cum apare n fig.9.6.b. Scoaterea atributelor cu valori care se repet pune entitatea ORDIN_CUMPARARE n prima form normal (vezi cap.6). S notm c cheia primar a entitii ORDIN_CUMPARARE devine un atribut de cheie strin n noua entitate. Aceast introducere a unei noi entiti trebuie s fie ntotdeuna urmat de identificarea cheii sale primare i a atrributelor de chei alternate.

230

Ordin_cumprare Oc# Parte# Valoare# Cumprtor_Id Cumprtor_telefon Cumprtor_rat Furnizor# Cantitate Stare Data

Ordin_cumprare Oc# Parte# Valoare# Cumprtor_Id Cumprtor_telefon Cumprtor_rat Furnizor# Cantitate

Stare Ordin_cumprare a fost verificat ca Oc# Data Stare

a)

b) Fig.9.6. Mutarea atributelor cu valori multiple.

9.5.5. Atribute cu valori nule Un alt mod de a descoperi entitile ascunse este de a determina care atribute pot avea valori nule. Modelatorii ntreab: Exist o valoare a acestui atribut pentru orice instan a entitii? Exist vreo instan a entitii care nu are o valoare pentru acest atribut?

231

Student Matric# Nume Adresa Data_naterii Telefon Cond_diploma Prima_spec A doua_spec Ultima_absolvire

Student Matric# Nume Adresa Data_naterii Telefon

Graduate_student Matric# Cond_diploma Ultima_absolvire

Undergraduate_student Matric# Prima_spec A doua_spec

a)

b)

Fig.9.7. Folosirea atributelor cu valori nule pentru a identifica categorii. Dac rspunsul la cea de a doua ntrebare este afirmativ, o entitate subtip ascuns ar putea exista. O nou entitate dependent poate fi introdus ntr-o relaie de categorie cu entitatea original devenit entitate generic. S considerm de exemplu, entitatea STUDENT din fig.9.7.a. S presupunem c s-a determinat c atributele COND_DIPLOMA, ULTIMA_ABSOLVIRE, PRIMA_SPEC, A_DOUA_SPEC pot cteodat avea valori nule. Modelatorii vor descoperi atunci c n realitate exist dou tipuri de studeni, aa cum se arat n structura de categorie din fig.9.7.b. Se introduc dou noi entiti, posibilele atribute nule separndu-se. Introducerea unor noi entiti trebuie urmat ntotdeuna de identificarea cheii sale primare i a atributelor de cheie alternat. n mod uzual, o entitate subtip are aceleai atribute de cheie primar ca i entitatea generic. Investigarea atributelor cu valori nule poate conduce i la identificarea de noi atribute. Un atribut cu valoare nul poate indica o relaie de categorie pentru care poate fi identificat o singur entitate subtip.

232

Adesea modelatoriinu sparg atributele cu valoare nul n entiti separate, pentru a nu limita posibilitile modelului de a exprima relaii n care particip fie entitatea generic, fie entitatea subtip. Dac valorile nule au fost mutate n entiti separate, le trebuie identificate ca permind valori nule. Acest identificator (flag) este o aseriune care poate fi mai trziu forat de DBMS. Parte Parte# Nume_parte Tip_parte Mrime_parte este furnizat de Ordin_cumprare Oc# Parte#(Fk,Ak1) Rat_cumprtor Cantitate_parte Furnizor#(Ak1) Valoare_Oc Id_cumprtor Tel_cumprtor Nume_furnizor Ora_furnizor Zona_orar Data_livrrii_atept

Fig.9.8.a

9.5.6. Interaciuni ntre atribute cheie Entitile ascunse sau lips pot fi descoperite cutnd interaciunile ntre atributele cheilor compuse. Pentru fiecare entitate cu o cheie compus, modelatorul ntreab: Identific o parte a acestei chei o entitate adiional?

233

Parte Parte#
Nume_parte Tip_parte Mrime_parte

Furnizor Furnizor#
Nume_furnizor Ora_furnizor Zona_orar Data_livrrii_atept

Ordin_cumprare Oc#
Parte#(Fk,Ak1) Furnizor#(Fk,Ak1) Valoare_Oc Id_cumprtor Tel_cumprtor Rata_cumprtor Cantitate_parte

Fig.9.8. Folosirea interaciunilor atributelor de cheie pentru a identifica entiti ascunse Dac rspusul este afirmativ i dac nu exist nici o entitate cu acea cheie n model, atunci trebuie introdus o nou entitate. Aceast nou entitate va participa ntr-o relaie de conectare unu-la-mai-muli mpreun cu entitatea original. S considerm, de exemplu, modelul din fig.9.8.a. PARTE#, FURNIZOR# este o cheie alternat pentru entitatea ORDIN_CUMPARARE. S presupunem c un studiu a identificat c FURNIZOR# este un identificator pentru o entitate adiional, FURNIZOR, care este parte a modelului. O nou entitate este introdus n fig.9.8.b. Fiecare din atributele noncheie ale lui ORDIN_CUMPARARE s-a examinat pentru a vedea dac ntr-adevr sunt propritatea lui ORDIN_CUMPARARE sau a noii entiti FURNIZOR. Analiza interaciunilor ntre atribute cheie arat c cele trei entiti sunt n 2NF. Fiecare atribut noncheie depinde de ntreaga cheie a entitii. Nu fiecare situaie de cheie compus cere prezena unei entiti identificate de fiecare component a cheii. De exemplu, n fig.9.9. nu este necesar introducerea unei entiti cu cheia primar DATA, dac nu sunt fapte care s se nregistreze n DATA ca o entitate.

234

Angajat Marca# Nume_angajat are Istorie_salariu Marca#(Fk) Data Salariu

Fig.9.9. Modelatorii ntreab: Exist cel puin un atribut noncheie interesant pentru aceast nou entitate candidat? Exist fapte care ar trebui pstrate despre entitatea n plus fa de faptul c exist valorile sale de cheie? Dac o nou entitate nu are atribute noncheie, atunci trebuie decis dac, ntradevr, entitatea candidat identific anumite fapte care ar trebui nregistrate. 9.5.7. Interaciunea ntre atributele noncheie n final modelatorii verific faptul c nici o entitate nu s-a ascuns n atributele noncheie, cutnd dependene ntre atribute. Ei ntreab: Identific vreun artibut noncheie alte atribute noncheie? Determin valoarea oricrui atribut noncheie valorile unuia sau mai multor artibute noncheie? Dac rspunsul este afirmativ i dac modelul nu are deja o entitate cu acel atribut noncheie ca i cheia sa primar, atunci se poate introduce o nou entitate. Noua entitate particip ntr-o relaie unu-la-mai-muli cu entitatea iniial, deoarece cheia sa apare n entitatea iniial ca i o cheie strin. De exemplu, s considerm entitatea din fig.9.10.a.

235

Ordin_cumprare Oc# Parte#(Ak1) Furnizor#(Ak1) Valoare_Oc Cumprtor Telefon Rata Cantitate_parte

Cumprtor Id_cumprtor Telefon Rata este reprezentat pt.

Ordin_cumprare Oc# Parte#(Ak1) Furnizor#(Ak1) Valoare_Oc Id_cumprtor(Fk) Cantitate_parte

a)

b)

Fig.9.10. Folosirea interaciunii ntre atribute noncheie pentru a identifica entiti ascunse. Examinarea ei cu atenie relev faptul c CUMPARATOR determin valorile pentru TELEFON i RATA. Atributul CUMPARATOR ar fi atunci mai bine numit ID_CUMPARATOR aa cum apare el n noua entitate care se adaug modelului (vezi fig.9.10.b). Analiza interaciunii ntre atributele noncheie duce entitile CUMPARATOR i ORDIN_CUMPARARE n BCNF. Toate dependenele din entiti depinde de chei candidate. 9.5.8. Verificarea normalizrii n final se valideaz normalizarea modelului, n general cu un suport software. Softul caut inconsistene independente implicate de ctre cheile primare i de ctre plasarea atributelor noncheie n entiti. El detecteaz un acelai nume aprnd n model cu semnificaii aparent deosebite, gsete entitile fr chei primare i identific entitile fr atribute noncheie. Toate erorile sunt corectate iar rezultatul este o vedere cu atribute complete, normalizate. 9.5.9. Pregtirea pentru proiectarea bazei de date fizice. Modelatorii i sursele adaug acum modelului detalii despre folosirea datelor, pregtind proiectarea fizic a bazei de date. Obiectivul lor este de a documenta caracteristicile de folosire a modelului, care vor afecta structura fizic a bazei de date. Cele trei tipuri principale de detalii adugate sunt domeniile pentru atribute, volumele de date pentru entiti i frecvenele de acces pentru entiti. 236

Domeniile trebuie specificate pentru atribute nainte de a construi structura bazei de date. n mod tipic, principala distinsie care se face este ntre valori numerice i caracter. Depinznd de DBMS-ul int, se pot specifica tipuri de date mai precise (ex: dat, monetar, timp, flotant, imagine, etc.) Volumele de date se estimeaz pentru entitile cele mai importante i aceste estimri se bazeaz pe volumele de date cunoscute din fiierele existente. Patternele de acces la entitile modelului pot fi descoperite n mai multe moduri. Unul dintre cele mai eficiente este de a specifica logica tranzaciilor ateptate ntr-un limbaj formal, structurat. Frecvenele tranzaciilor pot fi apoi estimate i nregistrate i totalul de volum i frecvene pot fi calculate i aduagate modelului. Aceast analiz se face n general cu un software, iar rezultatul este o vedere complet caracterizat. 9.6. Integrarea vederilor de model de date logice Vederile de date avnd domenii i puncte de vedere diferite pot fi puse mpreun ntr-un model de date logice neutru i integrat. Atunci cnd se integreaz vederile modelului de date., modelatorii trebuie s identifice i s rezolve omonimele, sinonimele, inconsistenele relaiilor i ale atributelor. In cursul acestei activiti, pot apare probleme care cer colectarea mai multor date de modelare sau reexaminarea vederilor componente. De fapt, integrarea a dou vederi de date poate fi mai dificil dect dezvoltarea uneia noi singure. Vederile pot fi integrate la orice nivel. Componentele pot fi diagrame entitate - relaie, vederi bazate pe chei, vederi cu atribute complete sau vederi complet caracterizate. n primul rnd integratorii trebuie s fie siguri de faptul c neleg domeniul fiecrei vederi de date componente, precum i domeniul modelului integrat. Ei studiaz instruciunile de domeniu, obiectivele i punctele de vedere i apoi scriu instruciuni de domeniu, obiective i puncte de vedere pentru modelul integrat. Vederile pot fi combinate prin software care identific acoperirile pariale i inconsistenele. Principala regul este: acelai nume trebuie s poarte aceai semnificaie. 9.6.1. Identificarea i rezolvarea omonimelor Integratorii modelului determin cnd acelai nume este folosit n vederile componente pentru a semnifica lucruri diferite i consult definiiile pentru a verifica semnificaiile. Cnd se detecteaz omonime, fiecrei definiii trebuie s i se dea propriul nume. De exemplu, dac ANGAJAT este folosit n dou vederi, dar cu semnificaii diferite, atunci numele trebuie s fie mai specific. Astfel, una din ele ar putea folosi SALARIAT i cealalt ANGAJAT. Integratorii verific, de asemenea, diferitele definiii cutnd nume ce apar n 237

mai multe vederi. Nume ca CONT#, PARTE#, NUME_VANZATOR, ADRESA, etc. pot fi suspecte, ele putnd nsemna lucruri diferite pentru persoane diferite. Glosarele modelului pot ajuta la gsirea i rezolvarea omonimelor ipot ajuta la prevenirea lor. Astfel, cei care dezvolt o nou vedere de date pot consulta glosarele cu definiii din eforturile anterioare de modelare date, evitnd a refolosi nume cu alte semnificaii. O modalitate de a evita omonimele este de a folosi nume descriptive precise pentruentiti i atribute. De exemplu, NUME_ORAS_FIRMA este mai precis dect ORAS. Omonimele pot s apar atunci cnd dou entiti sau atribute au acelai nume i semnificaii diferite, cnd un atribut i o entitate au acelai nume i cnd dou relaii ntre perechi de entiti au acelai nume i semnificaii diferite. Angajat Angajai

lucreaz la

lucreaz la

Proiect

Proiect

Fig.9.12. Dou vederi ale cardinalitii unei relaii 9.6.2. Identificarea i rezolvarea sinonimelor Integratorii modelului determin cnd nume diferite sunt folosite n vederile componente pentru a semnifica acelai lucru i consult definiiile pentru a verifica semnificaiile. n general, este mai greu de a identifica sinonime dect omonime. Sinonimelese gsesc prin potriviri de semnificaii, e cnd omonimele prin potriviri de nume. De exemplu, investigaia poate releva faptul c COD_DESEN este acelai lucru ca i NUMAR_SPECIFICATIE

238

dintr-o alt vedere, sau c ORDIN_INGINERESC este tot una cu ORDIN_TEHNIC. Atunci cnd se detecteaz sinonime, se selcteaz un nume cu rol de nume primar. Celelalte nume pot fi pstrate ca alias. Se pstreaz numai una dintre definiii. 9.6.3. Identificarea i rezolvarea inconsistenelor din relaii Integratorii modelului determin n continuare dac o aceai relaie este reprezentat prin cardinaliti diferite sau prin dependene diferite n vederile componente. Modelul final poate reprezenta numai o cardinalitate pentru o relaie. De exemplu, relaia LUCREAZA_LA ntre entitile ANGAJAT i PROIECT poate fi unu-la-mai-muli ntr-o vedere i mai-muli-la-mai-muli n alt vedere (fig.9.12.). Integratorii trebuie astfel s gseasc cardinalitatea i dependenele corecte pentru relaie. O alt inconsisten posibil n cadrul vederilor de date este o relaie care apare ntr-o vedere ca o relaie de identificare i n alt vedere ca o relaie de neidentificare. (fig.9.13.) n versiunea identificatoare a relaiei INCLUDE, cheia primar a lui DIVIZIE apare ca i parte a cheii primare a lui DEPARTAMENT. n versiunea neidentificatoare a relaiei, cheia primar a lui DEPARTAMENT nu mai include cheia primar a lui DIVIZIE. Divizie Id_divizie Divizie Id_divizie

include

include

Departament Id_divizie(Fk) Departament#

Departament Departament# Id_divizie(Fk)

Fig.9.13. Dou vederi ale dependenei de identificator. 239

9.6.4. Identificarea i rezolvarea inconsistenelor atributelor Integratorii modelului determin n final cnd un atribut apare inconsistent n vederile componente. O surs pentru discrepanele atributelor o reprezint domeniile sale. O alt inconsisten posibil apare n indicatorii nonnuli. Un atribut din modelul integrat fie permite fie nu permite valori nul. Un al treilea tip de inconsisten apare atunci o entitate are o cheie primar ntr-o vedere i o alt cheie primar n alt vedere. Unul din atribute este selectat ca i cheie primar a entitii n vederea integrat, iare cellalt devine o cheie alternat. 9.7. Revizuirea vederilor de date n puncte potrivite din procesul de dezvoltare a modelului, experii n subiect pot revizui vederile de date pentru a se asigura c ele sunt complete i exacte. Cele dou modaliti sunt revizuirea kit-ului i parcurgerea (walktrough); o revizuire de kit cere feedback de la indivizi iar parcurgerea extrage feedback-ul dintr-un grup. 9.7.1. Revizuiri de kit O revizuire de kip se bizuie pe ciclarea n timp a documentelor ntre modelatori i revizori. Un kit poate conine diagrame, text, glosare, reguli de afaceri, sumare de decizii, informaii de fond sau orice altceva mpachetat pentru revizie i comentariu. Ciclul de revizuire a kitului se desfoar astfel: Modelatorii selecteaz documente particulare ale modelului pentru a le include ntr-un kit. Ei asambleaz materialul i pregtesc o copert pentru a identifica kit-ul i pentru a indica revizorilor data la care au de prezentat comentariile. Copii ale kit-ului se distribuie tuturor revizorilor. n perioada specificat de rspuns, revizorii citesc kit-ul i-i scriu comentariile direct pe copie. Se folosete cerneal roie, pentru a fi sigur, c regsirea comentariilor este facil. Kit-ul adnotat este returnat modelatorilor. Modelatorii rspund scriind direct pe fiecare copie a revizorilor. Modelatorii pot s fie de acord cu comentariile, notnd aceasta pe copia de lucru, i incorpornd modificarea n urmtoarea versiune de lucru a modelului. Dac nu sunt de acord, ei noteaz aceasta pe kit (de obicei cu verde). Kit-ul este returnat revizorilor. Revizorii citesc rspunsurile modelatorilor. Dac sunt satisfcui, arhiveaz kit-ul. Dac nu, se aranjeaz o ntlnire pentru a rezolva diferendele.

240

Acest ciclu continu pn cnd se creaz un model care reprezint opiunea tuturor membrilor echipei. n final, revizorii verific exactitatea tehnic a modelului, fiind responsabili de gsirea de erori i sugernd nbuntiri. 9.7.2. Sesiuni de parcurgere Sesiunile de parcurgere pot fi eficiente atunci cnd toi participanii potrivii pot fi pui mpreun. Modelatorii selecteaz documentele care se folosesc n parcurgere, uzual aceleai ce cele din kit-ul de revizie, i pregtesc prezentarea i materialele. Managerul de proiect planific parcurgerea, aranjeaz facilitile necesare (camer, proiector, etc.) i notific revizorii. n timpul sesiunii, modelatorii prezint modelul iar revizorii l comenteaz. Pot fi propuse corecii la orice pas i ele pot fi notate pentru a fi incorporate mai trziu sau pot fi adoptate imediat. O parcurgere este un proces ordonat, uzual coninnd urmtorii pai: se revizuieasc entitile i definiiile lor. ntr-un model complex, se revizuiesc entitile generice i entitile subtipuri. se revizuiesc relaiile. se revizuiesc cheile primare pentru vederile bazate pe chei i vederile cu atribute complete. se revizuiesc cardinalitile pentru vederile cu atribute complete. se revizuiesc atributele noncheie pentru vederile cu atribute complete. La fiecare pas, revizorii verific dac modelul este complet i exact. 9.8. Comentarii finale Acest proces de dezvoltare, integrare i revizuire a modelelor de date a fost folosit cu succes ntr-o varietate de organizaii i este eficient n special n ariile de modelare mari, care nu pot fi nelese complet de un grup mic de indivizi. Acest proces traverseaz capacitatea de expresie a tehnicilor de modelare date, de la listarea preliminar a entitilor candidate pn la pregtirea detaliat a proiectrii fizice a bazei de date. Construirea unui model de date logice la orice nivel cere participarea experilor n domeniu: implicarea lor i expertiza modelatorilor determin calitatea modelelor finale. Memento Atribut Regul de afaceri Relaie de categorie Relaie de conectare Omonim Interviu 241 Sesiune de grup de modelare Vedere bazat pe chei Relaie nespecific Relaie specific Entitate Glosar

Kit Modelator Sistem dicionar de date Diagram model de date Data Modeling Technique DMT Vedere entitate - relaie Vedere cu atribute comlete Vedere complet caracterizat Sesiune de parcurgere

Atribut noncheie Normalizare Cheie primar Manager de proiect Relaie Revizor Sinomin Vedere

Bibliografie 1. Brown, R.G. (1982) Logical Databases Design Techniques, The Database Design Group. 2. D.Appleton Company, Inc. (1982) INFO Model - ER Reference Manual, Manhattan Beach CA. 3. D.Appleton Company, Inc. (1985) Data Modeling Technique Reference Manual PCFS - DMT- 3.0., Manhattan Beach CA. 4. SofTech (1981) ICAM Architecture Part II, Vol 5: Information Modeling Manual (IDEFI) AFWAL - TR - 81 - 4023, Wright Patterson Air Force Base, OH

Partea 2. Proiectarea fizic a bazelor de date

Aceast a doua parte a crii noastre const din patru capitole care discut princiile proiectrii bazelor de date fizice. Cap.10. introduce proiectarea bazelor de date fizice revizuind crmizile de baz ale structurilor de date fizice, iar capitolele 11, 12, 13 descriu proiectarea fizic a bazelor de date care implementeaz modelele prezentate n prima parte a crii: bazele de date relaionale, reea i ierarhice. Proiectarea logic a bazelor de date este, uzual, n responsabilitatea administratorilor de date iar proiectarea fizic n cea a administratorilor bazei de date. Ambele aspecte ale proiectrii bazei de date sunt importante i de neevitat.

Capitolul 10. Structuri fizice

Implementarea unei baze de date inseamn, n principiu, transformarea unui model de date logice ntr-o structur fizic. Componentele acestei structuri ntruchipeaz principiile a dou arii din cmpul gestionrii datelor, i anume

242

structurile de date i organizrile de fiiere. Ele pot fi aplicate att bazelor de date centralizate ct i celor distribuite, care se implementeaz pe reele de calculatoare posibil eterogene. 10.1. Concepte de baz Majoritatea bazelor de date sunt prea mari pentru a fi memorate economic n memoria central a unui calculator. n loc de aceasta, ele rezid pe aparate secundare, care ofer volume mai mari de memorare la un pre mai mic per bit. Bazele de date sunt memorate tipic pe aparate cu acces direct (discuri) i nu pe aparate cu acces secvenial (benzi, casete magnetice). Structura fizic a bazei de date determin ntinderea sau configurarea sa pe aparatul de memorare. 10.1.1. nregistrri i fiiere Unitatea de baz de transfer de date ntre mediul secundar de memorare i memoria principal este nregistrarea. Toate cmpurile unei nregistrri sunt citite sau scrise ntr-un singur acces la mediul secundar de memorare. Atunci cnd un program cere ca o nrgistrare s fie citit de pe mediul secundar de memorare (tipic folosind o instruciune READ), managerul de date: 1. se asigur c aparatul de memorare potivit este pregtit (ready). 2. cere transferul nregistrrii de pe aparat n zona buffer a programului. 3. returneaz controlul programului. Programul ateapt pn cnd nregistrarea a fost adus complet n buffer. Aceasta este zona n care programul i ine datele de transfer de la/spre aparatul secundar de memorare. Aceiai pai sunt urmai atunci cnd un program cere ca o nregistrare s fie scris (tipic, folosind o instruciune WRITE). Tehnica cea mai comun pentru a reduce numrul de accese la aparat i timpul de ateptare al programului este de a grupa nregistrrile n blocuri. Astfel mai multe nregistrri pot fi scrise sau citite printr-un singur acces la aparat. Dac exist n nregistrri per bloc, numrul de accese la aparat ar putea scdea de n ori. Un fiier este o colecie de blocuri care sunt gestionate mpreun. Deciziile de proiectare fiiere precizeaz cte cmpuri formeaz un tip de nregistrare, ce tipuri de nregistrri se memoreaz mpreun ntr-un fiier, care este factorul de blocare al fiierului (i.e. numrul de nregistrri per bloc). 10.1.2. Aparate de memorare

243

Cele dou modaliti princpale de a memora fiiere sunt aparatele de memorare n acces secvenial i aparatele de memorare n acces direct. Un aparat de memorare n acces secvenial cere ca nregistrrile s fie accesate n ordinea fizic consecutiv i astfel timpul cerut pentru a accesa nregistrarea R2 dup nregistrarea R1 depinde de distana fizic dintre ele. Diferitele tipuri de benzi magnetice sunt cele mai larg folosite aparate de memorare cu acces secvenial. Memorarea n acces secvenial este potrivit pentru fiiere care vor fi accesate secvenial, adic o nregistrare dup alta, de-a lungul ntregului fiier. De exemplu, un fiier cu nume i adrese pentru etichete de coresponden poate fi memorat ca un fiier secvenial pe un aparat de memorare n acces secvenial. Un aparat de memorare n acces direct ofer accesul n orice ordine la nregistrri i astfel timpul cerut pentru a accesa nregistrarea R2 dup nregistrarea R1 nu depinde de distana fizic dintre ele. Discul magnetic este cel mai larg folosit aparat de memorare n acces direct. Memorarea n acces direct este potrivit pentru fiierele care vor fi accesate ntr-o ordine nepredictibil. De exemplu,. un fiier cu date de credit pentru aperluri telefonice cu cari de credit va fi memorat pe un aparat de memorare n acces direct. 10.1.3. Baze de date fizice O baz de date fizic este o colecie de fiiere care implementeaz mpreun un model de date logice. Fiierele sunt integrate de ctre structura logic a bazei de date i ele se pot referi ntre ele. O cerere a unui utilizator poate implica date din mai multe fiiere ntr-o singur baz de date fizic i depinznd de organizarea bazei de date, un fiier poate conine nregistrri care implementeaz una sau mai multe entiti. Relaiile logice ntre entiti sunt implementate prin referine ntre nregistrri i/sau ntre fiiere, care ofer ci pentru a accesa o nregistrare din alta. Cele dou tipuri de fiiere ntr-o structur baz de date fizic sunt fiierele de date i fiierele index. Fiierele de date memoreaz fizic faptele care sunt baza de date. Fiierele index (directoare) susin accesul la fiierele de date dar, uzual, nu memoreaz fapte altele dect valori de chei. Semnificaiile sunt oferite de ctre structura logic a bazei de date, care la rndul ei este folosit pentru a determina care fapte pot fi accesate i cum se leag ele ntre ele. 10.2. Structuri de fiiere de date Fiierele de date au trei structuri principale bazate pe faptul dac nregistrrile au pointer intrafiier, pointeri interfiier sau nu au pointer. Care dintre aceste alternative este folosit va ajuta la determinarea modului n care relaiile 244

logice ntre entiti vor fi implementate n baza de date fizic. Un pointer este pur i simplu o adres memorat i este memorat ntr-o nregistrare astfel nct accesele se pot prelucra de la o nregistrare la alta.

First

Next

Next

Next

Next

Next

Fig.10.1.
First Next Next Next Next Next

Fig.10.2. Fig.10.1. ilustreaz o list liniar nlnuit, n care fiecare nregistrare pointeaz la urmtoarea nregistrare din secven. S notm c secvena fizic a nregistrrilor nu trebuie s fie identic cu secvena lor logic. Pointerul este cheia pentru a accesa nregistrrile direct i nu serial. Fr a ti unde este localizat o nregistrare n memorie, ea poate fi accesat direct urmnd un pointer la locaia ei. O problem n proiectarea unei structuri de date fizice este a determina nregistrrile care vor pointa la alte nregistrri i o cerin n gestionarea structurilor de date este asigurarea c pointerii pointeaz acolo unde trebuie. O valoare de pointer poate fi o adres absolut sau o adres relativ. O adres absolut este adresa propriu-zis a unei nregistrri i poate fi folosit fr modificri pentru a gsi nregistrarea int. Dac nregistrarea se afl pe un disc magnetic, atunci adresa absolut este, n general: <nr. cilindru, nr. suprafa, nr. nregistrare> sau <nr. sector, nr. nregistrare> Un pointer care este o adres absolut ofer un acces foarte rapid, cci aproape nu mai este nevoie de timp pentru determinarea locaiei nregistrrii int. Dezavantajele folosirii pointerilor adrese absolute pot ns depi avantajele folosirii lor:

245

 adresele absolute sunt dependente de aparat. Dac se schimb aparatul pe care rezid fiierele, valorile de adrese absolute probabil c vor trebui schimbate. adresele absolute sunt dependente de spaiul de adresare. Dac se aloc fiierului mai mult sau mai puin spaiu sau se colecteaz spaiul ocupat de gunoi (thrash sau garbage), valorile de adrese absolute probabil c se modific. O adres relativ indic locaia nregistrrii n cadrul fiierului, i nu pe aparatul de memorare. De exemplu, o adres relativ a celei de a o suta nregistrare dintr-un fiier poate fi <100> iar adresa relativ a celei de a patra nregistrri din al 80-lea bloc va putea fi <80, 4>. O adres relativ trebuie translatat ntr-o adres absolut nainte ca nregistrarea int s poat fi accesat. Prelucrarea cerut pentru aceast traducere este, n general, minimal i flexibilitatea ctigat prin creterea independenei fa de caracteristicile fizice ale aparatului este important. Exemplele noastre vor folosi de acum ncolo adrese relative. 10.2.1. Pointeri intrafiier Anumite baze de date fizice folosesc pointeri intrafiier pentru a prezenta relaiile ntre nregistrri. Fiecare nregistrare conine att cmpuri de date ct i cmpuri pointer. Un cmp pointer conine adresa urmtoarei nregistrri i astfel se spune c nregistrrile formeaz o list nlnuit sau un lan. Ordinea nregistrrilor ntr-un lan este determinat de aplicaie. De exemplu, ele pot fi sortate dup valoarea unui cmp de date sau pot fi nlnuite n ordinea n care au fost create. Ordinea logic a nregistrrilor nu trebuie s fie aceai cu ordinea lor fizic. Fiecare list nlnuint are un pointer la prima sa nregistrare. Ultima nregistrare din list are uzual un pointer nul, indicnd c nu exist o nregistrare urmtoare. ntr-un fiier de date pot exista mai multe liste nlnuite. De exemplu, nregistrrile cu DEPT# = 10 sunt ntr-un lan, cele cu DEPT# = 20 n alt lan, etc. Fig.10.2. prezint o list dublu nlnuit. Fiecare nregistrare are nu numai un pointer spre urmtoarea nregistrare ci i unul spre precedenta. Fig.10.3. ilustreaz un fiier n care nregistrrile sunt nlnuite n ordine dup SERIAL# i dup VOLUM. Adresa 1 2 3 4 5 Serial# 34567 21922 51362 24923 51466 Serial Urm# 8 4 5 10 6 Volum 12 14 10 10 3 Volum Urm 2 0 4 1 10 Culoare Albastru Verde Verde Galben Albastru

246

6 7 8 9 10

61234 71911 51361 12111 21934

7 0 3 2 1

5 6 7 8 4

7 8 9 3 6

Roz Albastru Verde Galben Mov

Fig.10.3. Un fiier cu dou liste nlnuite. Un fiier poate conine nregistrrile reprezentnd una sau mai multe entiti. S presupunem acum c o entitate este reprezentat de un tip de nregistrare. Relaiile ntre ocurenele entitii ordoneaz, n general, aceste ocurene dup valorile unui anumit cmp. De exemplu, nregistrrile ANGAJAT pot fi nlnuite n ordine ascendent a cmpului SSN#. Dac un fiier conine att nregistrri ANGAJAT ct i nregistrri DEPARTAMENT, atunci relaia ntre entitile lor respective poate fi reprezentat de liste nlnuite. Fiecare nregistrare DEPARTAMENT poate pointa la un lan de nregistrri ANGAJAT asociate, aa cum se arat n fig.10.4. Astfel, pointerii unui fiier pot conecta nregistrri de acelai tip sau de tipuri diferite. Structura logic a datelor determin care nregistrri sunt conectate.
Prim Ang.

Departament

Angajat Angajat

Next Ang.

Angajat

Next Ang.

Angajat

Next Ang.

Departament

Prim Ang.

Angajat

Next Ang.

Angajat

Next Ang.

247

Fig.10.4. Pointeri de tip intrafiier 10.2.2. Pointeri interfiiere Pointeri interfiiere pot fi folosii i ei pentru a reprezenta relaii. O baz de date fizic poate conine mai multe fiiere. n mod tipic, toate nregistrrile de un tip dat apar ntr-un singur fiier. Fiecare fiier conine unul sau mai multe tipuri de nregistrri. Cazul general este modelat n fig.10.5. Extinznd modelul precedent, un alt fiier poate conine nregistrri PROIECT iar relaiile ntre proiecte i departamente pot fi reprezentate prin pointeri interfiiere. S considerm modelul de date din fig.10.6. Fiecare departament poate avea mai multe proiecte, dar fiecare proiect ine de un singur departament. Aceast relaie poate fi implementat n cel puin trei moduri: fiecare nregistrare PROIECT poate pointa la o nregistrare DEPARTAMENT, ca n fig.10.7. fiecare nregistrare DEPARTAMENT poate pointa la o list nlnuit de nregistrri PROIECT potrivite, ca n fig.10.8. fiecare nregistrare DEPARTAMENT poate avea un tablou de pointeri la nregistrrile sale PROIECT, ca n fig.10.9. Pointerii interfiiere sunt n esen la fel ca pointerii intrafiier dar ei trebuie s indice, de asemenea, care este fiierul care se pointeaz.

248

Baz de date fizic

Fiier

poate conine

poate conine Tip nregistrare

Fig.10.5. Relaii generale ntre baze de date fizice, fiiere i tipuri de nregistrri.

Proiect

249

Fig.10.6. Model de date logice.

Departament

Proiect

Dept.

Proiect

Dept.

Departament

Proiect

Dept.

Proiect

Dept.

Proiect

Dept.

Fig.10.7. Fiecare proiect pointeaz la departamentul su. Departament

First Proiect

Proiect

Next Proiect

Proiect

Next Proiect

Proiect

Next Proiect

Fig.10.8. Fiecare departament pointeaz la o list nlnuit de proiecte.

250

Departament

Proiec te

Proiect

Proiect

Departament

Proiec te

Proiect

Proiect

Proiect

Fig.10.9. Fiecare departament pointeaz la o list nlnuit de proiecte. 10.2.3. Fr pointeri Anumite DBMS-uri implementeaz relaiile fr a folosi pointeri, ntr-o abordare numit uneori adresare indirect. n loc de a folosi cmpuri pointer, care conin adrese relative sau absolute, DBMS-ul folosete cmpuri de referin coninnd valori de date. De exemplu, relaia ntre o nregistrare ANGAJAT i o nregistrare DEPARTAMENT poate fi reprezentat potrivind valorile DEPT# n cele dou nregistrri, ceea ce este exact abordarea cu atribute de cheie strin ntr-un model de date logice. ns folosirea cmpurilor referin nu evit translatarea valorilor de cmp n adrese de nregistrare, care uneori se face innd o tabel separat de perechi: <valoare cheie de acces, adres nregistrare> n loc de a accesa direct nregistrarea DEPARTAMENT a angajatului, folofind o adres relativ memorat n ANGAJAT, nregistrarea 251

DEPARTAMENT poate fi accesat indirect via indexul <DEPT#, adres nregistrare>, ca n fig.10.10. Valoarea DEPT memorat n nregistrarea ANGAJAT este folosit pentru a gsi intrarea dorit n indexul DEPT#, care conduce la o nregistrare DEPARTAMENT potrivit. nregistrri Angajat Angajat Dept#

Index Dept# Dept# Adresa nregistrrii

Fig.10.10. Acces indirect la nregistrri DEPARTAMENT prin accesarea indexului DEPT# din valorile ANGAJAT. DEPT#.

10.3. Organizri de fiiere Unul din serviciile unui DBMS este gestionarea structurilor de date fizice, incluznd aici interpretarea relaiilor reprezentate de pointerii intrafiier, cei interfiiere i de structuri fr pointeri. Programatorul sau utilizatorul nu trebuie s in cont de reprezentarea relaiilor n structura bazei de date fizice ci numai de structura logic a datelor. n majoritatea configuraiilor de calculatoare, un DBMS lucreaz cu sistemul de operare pentru a oferi servicii de gestionare date. DBMS-ul apeleaz posibilitile sistemului de opearare pentru a realiza operaii de I/O asupra datelor memorate pe aparatele sistemului. Aceste servicii de I/O includ: meninerea directorilor, astfel nct fiierele s poat fi gsite.

252

 stabilirea cilor, astfel nct datele s poat s circule ntre memoria secundar i cea intern. coordonarea comunicaiilor ntre aparatele de memorare secundar i CPU. pregtirea (ready) fiierelor pentru intrri i ieiri. tratarea fiierelor, atunci cnd intrarea sau ieirea s-a terminat. Modul n care aceste servicii sunt oferite pentru un fiier particular depinde de structura fiierului i de felul n care el este manipulat. O structur de fiier se mai numete organizare de fiier. Organizarea fiierului determin secvenialitatea fizic i configuraiile nregistrrilor sale. nregistrrile pot fi aranjate ntr-o ordine aleatoare oarecare, sau ntr-o ordine sortat n concordan cu valoarea unui anumit cmp. Organizarea fiierului determin, de asemenea, tipurile de operaii necesare pentru a gsi nregistrri cu valori de cmp particulare. Aceste operaii pot oferi acces direct la nregistrri bazat pe o varietate de cmpuri, acces direct bazat pe un singur cmp sau acces secvenial la nregistrri. Cele trei organizri fundamentale de fiiere sunt secvenial, relativ i secvenial-indexat. 10.3.1. Fiiere secveniale Cel mai simplu mod de a organiza colecia de nregistrri care formeaz un fiier este de a folosi organizarea de fiier secvenial. nregistrrile sunt scrise n ordine fizic consecutiv atunci cnd fiierul este creat i ele trebuie s fie accesate n aceai ordine atunci cnd, mai trziu, fiierul este folosit (fig.10.11.) Un fiier secvenial poate fi memorat pe un mediu de memorare cu acces secvenial (de ex. band magnetic) sau pe un mediu de memorare cu acces direct (de ex. disc magnetic).

253

nregistrare1 nregistrare2 . . . nregistrareI-1 nregistrareI nregistrareI+1 . . .

nceputul fiierului

nregistrareN-1 nregistrareN Sfritul fiierului

Fig.10.11. Organizarea de fiier secvenial. Adesea, nregistrrile sunt oferite n ordine sortat atunci cnd fiierul este creat. Un astfel de fiier se numete fiier sortat. Cmpurile ale cror valori se folosesc pentru a determina ordinea nregistrrilor se numesc chei de sortare. Un fiier secvenial poate avea numai o cheie de sortare: nregistrrile nu pot fi n dou ordini deoarece secvena logic trebuie s fie exact aceai cu secvena fizic. Natura fiierelor secveniale le face potrivite pentru prelucrri batch, deoarece este mult mai rapid a accesa urmtoarea nregistrare dect a accesa o nregistrare a crei valoarea de cheie este dat. n medie, trebuiesc citite jumtate din nregistrrile fiierului pentru a gsi o nregistrare dat prin valoarea ei de cheie. Fiierele secveniale sunt potrivite n special pentru memorarea copiilor de arhiv i de transport ale bazelor de date. O copie arhivat memoreaz starea bazei de date la un anumit moment, s spunem la sfritul anului. O copie backup este folosit pentru a restaura baza de date ca parte a unei refaceri dintr-o proast funcionare a sistemului, iar o copie de transport este folosit pentru a trimite baza de date de pe o main sau instalare pe alta. Copiile de arhiv, backup sau transport se memoreaz uzual pe benzi magnetice. Organizarea secvenial de fiier este atractiv pentru aceste scopuri deoarece a poate fi folosit cu medii de memorare iefine i ea are o regie mic (i.e. ea memoreaz numai date, nu i indeci). Totui, pentru a ncrca o 254

structur de baz de date nonsecvenial dintr-un fiier secvenial se consum mult timp de prelucreare, dar probabil c aceast situaie nu apare des. Prelucrarea arhivei, refacerea sistemului i instalarea bazei de date sunt evenimente care apar cu caracter excepional n majoritatea mediilor. 10.3.2. Fiiere relative Organizarea de fiier relativ folosete valoarea unui cmp din nregistrare pentru a determina locaia fizic a acesteia n fiier. Secvena logic a nregistrrilor nu este determinat n vreun fel de secvena lor fizic (fig.10.12.) Dac nregistrrile apar fizic n ordine sortat dup un anumit cmp, aceasta este pur accidental. n contrast cu fiierele secveniale, nu este necesar a accesa nregistrrile unui fiier relativ n ordine consecutiv. Un fiier relativ trebuie s fie memorat pe un aparat de memorare cu acces direct, deorece posibilitile de acces direct ale unui fiier relativ nu pot fi exploatate dac acesta este memorat pe un aparat de memorare cu acces secvenial. Organizarea de fiier relativ este bazat pe meninerea unei relaii predictibile ntre valoarea cheii de acces la nregistrare i locaia sa n mediul de memorare. Funcia folosit pentru a traduce o valoarea de cheie ntr-o adres de memorare este proiectat atunci cnd fiierul este creat. Aceast funcie este folosit pentru a gsi memorie pentru nregistrare atunci cnd aceasta este creat (adugat fiierului) i penrtu a gsi nregistrarea atunci cnd aceasta este modificat, tears sau regsit. Fiierele relative sunt n general folosite pentru a sprijini accesul interactiv. O nregistrare particular poate fi gsit rapid dac se cunoate valoarea cheii sale de acces. Gsirea unei nregistrri particulare bazate pe un alt cmp dect cheia de acces nu d ins nici un ctig de performan fa de accesul secvenial, deoarece numai cheia de acces poate fi tradus direct ntro locaie de memorie. S exemplificm. Fie o companie cu opt angajai, identificai printrun cod SSN. Cel mai simplu calcul de adres este: cheie de acces = adres. Fiecare locaie a nregistrrii ANGAJAT este astfel unic determinat de valoarea din nregistrare a lui NR_BI, reprezentnd numrul buletinului de identitate. Folosind aceast abordare simpl, totui ar rezulta un fiier cu zone neutilizate. Exist un milion de valori posibile pentru un cod NR_BI de 6 cifre din care doar 8 sunt folosite de companie. Totui, spaiul trebuie alocat pentru toate valorile posibile, deoarece nu se poate prevede ce numere NR_BI vor avea noi angajai. Un calcul mai potrivit const n a folosi numai ultimele dou cifre ale fiecurui NR_BI de angajat, astfel existnd numai 100 de valori posibile, ceea ce este sufucient pentru toi angajaii, dar ceea ce poate eventual duce la suprapuneri de adrese. Funciile de calcul a adreselor folosite de ctre DBMS-uri sunt mult mai complexe dect cele de mai sus i sunt referite ca: algoritmi CALC 255

tehnici de adresare direct metode de tabele hash hashing metode de transformare cheie-n-adres tehnici aleatoare tehnici de memorie mprtiat (scatter - storage)

nregistrarea I . . . nregistrarea N nregistrarea 2 nregistrarea N-1 nregistrarea 1 . . . nregistrarea I+1 . . nregistrarea 3

nceputul fiierului

Sfritul fiierului

Fig.10.12. Organizarea de fiier relativ. Vom folosi termenul de hashing i ne vom referi la funciile de calcul a adreselor ca funcii hash. Indiferent de funcie folosit pentru memorarea nregistrrilor, aceeai funcie trebuie folosit atunci cnd nregistrrile sunt accesate pentru regsire, modificare sau tergere. Dac valorile NR_BI sunt folosite de ctre funciile hash ca i valori de cheie de acces atunci cnd se memoreaz nregistrrile ANGAJAT, atunci utilizatorii trebuie s furnizeze ei valorile NR_BI cnd doresc s regrseasc nregistrri. Accesul prin valoarea oricrui alt cmp cere o cutare secvenial n fiier. Fiierele pur relative nu sunt potrivtie pentru structurile bazelor de date fizice, deoarece bazele de date cer accesibilitate dup mai multe cmpuri. Principiile fiierelor relative sunt totui aplicabile aproape tuturor structurilor bazelor de date fizice.

256

10.3.3. Coliziuni n exemplul nostru simplu apare o problem atunci cnd numerele de BI ale unor angajai se termin cu aceai dou cifre, de ex.: 654321 i 678921. Dou nregistrri nu pot fi memorate ambele n cea de a 21-a poziie. Atunci cnd o funcie hash d pentru dou valori de cheie de acces aceai valoare de adres, se spune c a aprut o coliziune, iar cele dou valori de cheie de acces se numesc sinonime. Tot aa cume exist multe funcii hash posibile, exist i variate tehnici de rezolvare a coliziunilor. De exemplu, folosind funcia hash precedent, dac prima nregistrare prelucrat este cea cu cheia 654321, ea va fi memorat la locaia 21, care este adresa cas (home address). Atunci cnd se adaug nregistrarea cu 678921, adresa cas a acesteia (21) este deja ocupat. Dac adresa 22 este liber, a ar putea fi memorat aici. Dac i aceasta este ocupat, se ncearc n continuare n mod secvenial pn se gsete una liber. Metoda aceasta se numete ncercare linear (linear probing). Spaiul adreselor este cutat secvenial de la adresa cas i nregistrarea este memorat n prima locaie disponibil. O alt abordare pentru rezolvarea coliziunilor const n a aplica o a dou funcie de calcul a adresei, o tehnic numit hashing dublu. Dac primul hash, care e cel ce d adresa cas duce la o coliziune, o a doua funcie va fi folosit pentru a calcula o locaie la a doua alegere. Obiectivul unei tehnici de calculare a adresei i al abordrii nsoitoare de rezolvare a coliziunilor este de a minimiza numrul de accese cerute pentru a regsi orice nregistrare dat.

257

987654321 21 22 58

345678921 59

Spre sinonimul urmtor

Fig.10.13. nlnuirea sinonimelor O modalitate bun pentru a face aceasta const n a nlnui toate nregistrrile cu o aceai adres cas. De exemplu, s presupunem c n final, nregistrarea cu 678921 s-a memorat n locaia 59. Atunci cnd utilizatorul dorete s acceseze aceast nregistrare, funcia hash va da adresa cas 21. Aceast locaie nu conine ns nregistrarea cerut i astfel va ncepe o ncercare liniar pn cnd nregistrarea int va fi localizat. Dup mai multe accese, nregistrarea va fi ntlnit la locaia 59. Dac ns nregistrarea 678921 a fost nlnuit cu locaia sa cas atunci cnd a fost memorat, vor fi necesare doar dou accese: unul la adresa cas i apoi unul pentru a urma pointerul ctre urmtorul sinonim. Chiar dac locaia int a fost victima mai multor coliziuni atunci cnd a fost memorat, urmnd o list nlnuit de sinonime sunt necesare mai puine accese dect n cazul ncercrii liniare. Metoda se numete nlnuirea sinonimelor (chaining). O cerin a acestei metode este aceea ca o nregistrare s nu poat fi deplasat din adresa cas de ctre o nregistrare care nu i este sinonim.

258

10.3.4. Adresarea blocurilor. O alt abordare pentru a mnui problema coliziunilor este adresarea blocurilor, adic a face hash pe blocuri de spaiu care pot cuprinde mai multe nregistrri n loc de a face hash pe locaii de nregistrri individuale. De exemplu, unui fiier I se pot aloca 100 de blocuri, fiecare suficient de mare pentru a memora 10 nregistrri. Funcia hash genereaz adrese de la 0 la 99. Zece nregistrri care dau aceai adres hash se regsesc n acelai bloc fr a cauza probleme de coliziune. Atunci cnd un utilizator dorese s acceseze o nregistrare particular, se aplic funcia hash valorii de cheie de acces, rezultnd numrul blocului de cas (home block). Acel bloc este apoi parcurs secvenial pentru a gsi nregistrarea cu valoarea cheii de acces date. Problema coliziunii apare atunci cnd blocul este plin. Abordrile problemei depirii blocului sunt n principal aceleai ca i cele de la rezolvarea coliziunilor nregistrrilor simple. Spaiul poate fi cutat n blocul urmtor, folosind cutarea liniar, sau ntr-un alt bloc folosind hashing dublu. Uneori se aloc un bloc de depire i el se leag de blocul de cas sau o mulime de blocuri de depire in lanuri de sinonime din toate blocurile cas. Un avantaj al folosirii blocurilor care pot ine mai multe nregistrri este acela c nregistrrile de lungime variabil se pot potrivi uor. DBMSurile folosesc n mod uzual aceast abordare, deoarece un fiier poate conine diferite tipuri de nregistrri, care au uzual dimensiuni diferite. Cu adresarea blocurilor i cu nregistrri de lungime variabil, gsirea spaiului disponibil ntr-un bloc pentru o nregistrare nou, devine o problem mai complex dect cutarea secvenial a primei arii libere. Spaiul gsit trebuie s fie suficient de mare pentru a adposti noua nregistrare. Spaiul dintr-un bloc este gestionat uzual meninnd o list nlnuit de zone libere, care constituie spaiul disponibil. Fig.10.14. arat un bloc coninnd nregistrri i un lan de zone libere. Atunci cnd o nou nregistrare trebuie scris n bloc, lanul de zone libere este analizat pentru a gsi spaiu disponibil. Este convenabil a ordona lista de zone libere dintr-un bloc n concordan cu mrimea lor, n ordine cresctoare. O scanare secvenial n lanul de zone libere se poate opri atunci cnd s-a gsit prima locaie liber suficient de mare pentru a conine noua nregistrare. Antet bloc

259

Numrul blocului Prima gaur

Bloc de depire Mrimea gurii celei mari

Mrime gaur

Mrime gaur

Mrime gaur

Fig.10.14. Un bloc coninnd nregistrri i un lan de zone libere. Aceast locaie este scoas apoi din list, iar spaiul este folosit pentru memorarea noii nregistrri. Orice spaiu rmas neocupat din zona liber poate fi apoi inserat n lista de zone libere n locul potrivit pentru a pstra ordonarea acesteia. Fiecare bloc are o nregistrare antet care include un pointer la prima zon liber din lanul respectiv (vezi fig.10.14). Antetul include, de asemenea, mrimea celei mai mari zone libere din bloc. Dac aceasta este prea mic pentru a satisface cererea de spaiu, atunci cutarea poate trece direct la blocul urmtor sau la un bloc de depsire. Atunci cnd o nrgistrare este tears, spaiul ei se poate aduga la lanul de zone libere. Dac acest spaiu liber este contiguu cu o locaie liber existent, atunci spaiul poate fi combinat ntr-o locaie mai mare. Sunt de preferat zone libere mai mari i mai puine dect zone multe i mici. Procesul de recunoatere a nregistrrilor terse i de combinare a spaiului eliberat se numete colectarea gunoilui (garbage collection). 10.3.5. Fiiere secvenial indexate

260

Organizarea de fiier secvenial indexat combin tipurile de acces suportate de ctre fiierele secveniale i cele relative. nregistrrile pot fi accesate att secvenial ct i direct prin valoarea cmpului de cheie de acces. Un fiier secvenial indexat este n realitate format din dou fiiere. Unul este fiierul de date , iar cellalt este fiierul index de pointeri la fiierul de date (fig.10.15) Fiierul de date este n general structurat folosind adresarea blocurilor. ntr-un bloc, nregistrrilese gsesc n ordine secvenial, n concordan cu valoarea cmpului cheie de acces. Fiecare bloc de date are un pointer la urmtorul bloc din secvena sortat, cu toate c blocurile de date nu sunt n mod necesar n vreo secven fizic particular. O intrare index este o pereche: <valoare cheie de acces, adresa> Adresa este locaia unui bloc de date, iar valoarea cheie de acces corespunztoare este prima valoare cheie de acces care apare n acel bloc de date. n fiierul index intrrile sunt sortate n ordinea cheilor de acces. S considerm fiierul din fig.10.15. S presupunem c dorim s localizm nregistrarea angajatului al crui nume este Igor. Prima dat cutm n index. n aceast tabel index simpl, valorile cheii de acces vor fi analizate pn cnd se ntlnete una mai mare dect Igor. Pointerul la intrarea precedent va fi folosit apoi pentru a gsi blocul de date n care se va citi secvenial pn cnd se gsete nregistrarea Igor sau se determin c nu exist o astfel de nregistrare. Dac dorim s accesm secvenial toate nregistrrile ANGAJAT, vom urma pointerul la primul bloc, vom citi n secven toate nregistrrile de acolo, apoi vom urma pointerul la blocul urmtor, vom citi n secven toate nregistrrile, etc. pn cnd vom termina de citit i ultimul bloc. Lista nlnuit de blocuri ofer o cale secvenial pentru datele nregistrate. Atunci cnd o nregistrare este adugat fiierului, ea trebuie poziionat astfel nct posibilitile de regsire s nu se altereze. Indexul este folosit pentru a gsi blocul n care va trebui s rezide nregistrarea. Dac exist spaiu n acel bloc, noua nregistrare va fi memorat acolo. Alte nregistrri din bloc trebuie uneori s fie mutate mai jos pentru a pstra coninutul blocului n ordine secvenial.

261

Fiier de date Freddy Gale Gondalf Fiier index Bertha Eloise Floris Gondalf Jona Maude Nanci Paulette Zelda

Georgia Holly Igor Ivan Jona

Julie Lana Laura Lisa Maude

Nada Nan Nanci

Fig.10.15. Fiier secvenial indexat. 262

Fiier de date Freddy Gale Gondalf Fiier index Bertha Eloise Floris Gondalf Jona Laura Maude Nanci Paulette Zelda

Georgia Holly Igor Ivan Jona

Julie Lana Laura

Lisa Mara Maude

Fig.10.16. Fiier secvenial indexat. Un bloc de date a fost divizat adugnd o intrare n fiierul index.

Nada Nan Nanci

263

Dac nu exist loc n blocul cas, se ncepe un nou bloc, desprind n mod uzual blocul cas n dou blocuri. Jumtate din nregistrrile blocului cas rmn pe loc iar jumtate sunt mutate n noul bloc. nregistrarea nou este inserat n zona potrivit pentru a pstra secvenialitatea. Atunci cnd un bloc este divizat, fiierul index trebuie s conin o nou intrare pentru ca noul bloc s fie localizabil. Fig.10.16. prezint fiierul exemplu ajustat pentru a include o nrgistrare pentru Mara. S notm c apare o intrare adiional n index. Un fiier secvenial indexat pur nu este, n general, o structur potrivit pentru o baz de date fizic, deoarece ofer acces direct pe baza unei singure chei de acces, pe cnd bazele de date au nevoie s ofere acces direct bazat pe mai multe valori de cmpuri diferite. 10.4. Organizarea fiierului multichei Abilitatea de a cuta dup mai multe chei de acces este posibil construind fiiere index multiple n vrful fiierului de date. Baza de date fizic const apoi din unul sau mai multe fiiere index i fiecare fiier de date conin unul sau mai multe tipuri de nregistrri. Fiecare fiier index ntreine accesul printr-un cmp particular sau un grup de cmpuri. S considerm la nceput un fiier de date cu un tip de nregistrare. Unul din fiierele index este uzual un index primar i ofer accesul bazat pe un cmp sau un grup de cmpuri numt cheie primar. Cheia primar pentru un tip de nregistrare dintr-o baz de date fizic identific unic ocurenele acelei nregistrri i uzual este aceai cu cheia primar a entitii logice corespunztoare. Dac structura de fiier suport de asemenea accesul secvenial la nregistrrile de date cu ajutorul valorii de cheie primar, atunci el are o organizare de fiier secvenial indexat. Dac nu suport accesul secvenial prin valoarea de cheie primar, atunci fiierul de date poate fi unul relativ. Un index primar este n general folosit n calculul adreselor ntr-un fiier relativ pentru a evita rezolvarea coliziunilor. n loc de a folosi un lan de sinonime pentru locurile unde au fost memorate nregistrrile, indexul primar reine perechi de forma: <valoare cheie primar, adres> Pentru a gsi o nregistrare folosind indexul primar, se localizeaz nti valoarea de cheie primar i apoi adresa indicat este folosit pentru a gsi nregistrarea pe mediul secundar de memorare. Pentru a memora o nregistrare nou, se calculeaz nti adresa cas folosind funcia hash i apoi se rezolv coliziunile. nregistrarea este memorat i valoarea cheii i adresa sunt plasate n index. Accesele ulterioare la nregistrare pot fi mnuite direct de ctre index fr a aplica funcia hash, a rezolva coliziuni i a detecta

264

sinonime. Organizarea de fiier multichei mrete suportul de index primar cu unul sau mai muli indeci secundari. 10.4.1. Indeci secundari Un index care ofer acces dup un cmp sau cmpuri, altele dect cheia primar se numete index secundar sau index alternat. Cmpul de acces se numete cheie secundar sau cheie alternat sau intrare de inversiune. S presupunem c este necesar s accesm datele angajatului nu numai direct dup NR_BI ci deasemenea, dup DEPT# i JOBCODE. Fig.10.17, schieaz fiierul de date i indecii si primar i secundar asociai. Pentru a gsi nregistrarea ANGAJAT cu NR_BI = 654321, trebuie consultat indexul primar, iar pentru a gsi nregistrrile ANGAJAT cu JOBCODE = DBA, trebuie cutat n indexul secundar potrivit. Un index secundar poate avea mai mult de o singur nregistrare int pentru fiecare valoare de cheie secundar, ceea ce poate fi rezolvat astfel: o intrare n indexul secundar pentru fiecare pereche <valoare cheie secundar, adres> o intrare n indexul secundar pentru fiecare pereche <valoare cheie secundar, adres> cu o list asociat de intrri <adres>, cte una pentru fiecare nregistrare calificat. o intrare n indexul secundar pentru prima pereche <valoare cheie secundar, adres> cu un pointer n nregistrarea de date int spre urmtoarea nregistrare cu aceai valoare de cheie secundar, care la rndul ei are un pointer spre urmtoarea nregistrare cu aceai caracteristic, i aa mai departe. Primele dou abordri nu afecteaz fiierul de date i sunt uneori referite ca i structuri de inversiune. A treia abordare cere ca fiierul de date s conin o list nlnuit de nregistrri pentru fiecare din valorile cheii secundare i este referit uneori ca i structur multilist. Atunci cnd se adaug o nregistrare ANGAJAT locaia sa de memorare trebuie prima dat determinat folosind funcia hash a sistemului. Dac apare vreo coliziune, aceasta trebuie rezolvat. Valoarea NR_BI a nregistrrii i locaia de memorie a nregistrrii pot apoi fi introduse n indexul primar. Noua nregistrare trebuie s fie fcut accesibil i din indecii DEPT# i JOBCODE. n aceti indeci se fac noi intrri dac s-a folosit o abordare pe inversiune. Cu abordri multilist noua nregistrare trebuie s fie adugat listelor nlnuite potrivite pentru valorile sale DEPT# i JOBCODE. O nou intrare trebuie s fie fcut ntr-un index secundar dac aceasta este prima nregistrare cu o valoare anumit a lui DEPT# sau JOBCODE.

265

Index SSN Index primar 214689102 489230000 652134821 999821000

nregistrri angajat

Index Jobcode Analist DBA Programator Indeci secundari

Index Dept# 10 20 30

Fig.10.17. Fiier de date cu index primar i cu doi indeci secundari. 10.4.2. Adresare indirect O intrare n indexul secundar poate folosi fie la adresare direct sau la adresare indirect. Cu adresare direct, o intrare index este o pereche: <valoare cheie secundar, adres> iar cu adresare indirect, o intrare index este o pereche: <valoare cheie secundar, valoare cheie primar> Fig.10.18. schieaz structura fiierelor exemplu cu o adresare indirect, n contrast cu fig.10.17., care presupune o adresare direct. Cu adresarea indirect; un acces via un index secundar cere, de asemenea, un acces la indexul primar. De exemplu, n loc de a avea o intrare index secundar <DBA, 59>, indicnd c un angajat cu JOBCODE = DBA se afl memorat la localia 59, intrarea n indexul secundar va fi <DBA, 654321> indicnd c un angajat cu JOBCODE = DBA are NR_BI = 654321. Indexul secundar va fi de fapt o pereche <JOBCODE, NR_BI>, iar indexul primar al exmplului de mai sus a fost desigur <654321, 59> ceea ce indic faptul c nregistrarea int este la locaia 59. 266

Aproape toate DBMS-urile suport att index primar ct i indeci secundari. Multe dintre ele folosesc adresarea indirect pentru indecii secundari i unele dintre ele cer ca s nu se foloseasc pointeri. Este de la sine neles, totui, c o adres indirect este un tip special de pointer, un indicator sau o referin la o alt intrare dintr-un index sau dintr-o nregistrare ntr-un fiier de date. Intrrile din indexul principal ofer transformrile din adrese indirecte n adrese relative. Beneficiul adresrii indirecte const n nivelul de independen nrte intrrile din fiierul index i aezarea fizic a fiierului de date. Cu adresarea indirect, reorganizarea spaial a fiierului de date cere ca noile locaii de nregistrri s fie reflectate n indexul principal dar nu i n indecii secundari. Costul adresrii indirecte este nevoia de a accesa nc un fiier atunci cnd trebuie localizate nregistrri de date.

Index Jobcode Analist DBA Programator

nregistrri angajat

Index SSN 214689102 489230000 652134821 999821000

Index Dept# 10 20 30

Fig.10.18. Fiier de date cu un index primar i cu doi indeci secundari folosind adresare indirect.

10.5. Structuri de indeci Structurile fiierelor index suport toate cutri rapide dup o valoare de cheie de acces. Tipurile de baz sunt indeci tabel, indeci arbore binar de cutare i indeci B-arbori.

267

Indeci tabel. n forma sa cea mai simpl, un index este implementat ca i o tabel sau un tablou de nregistrri de forma <valoare cheie de acces, adres>, ca n fig.10.19. Dac nregistrrile nu sunt sortate este necesar o cutare secvenial pentru a gsi nregistrarea cu o valoare anumit de cheie de acces. n medie, este necesar s fie citite jumtate din intrri pentru a localiza intrarea dorit. n cazul cel mai defavorabil, trebuie citite toate nregistrrile pentru a determina c valoarea dorit de cheie de acces nu se afl n tabela index. <valoare cheie de acces> <adres> Fig.10.19. Tablou de indeci. Dac nregistrrile index sunt sortate dup valoarea cheii de acces, atunci poate fi folosit o cutare binar pentru a reduce timpul necesar gsirii intrrii cerute. Tabela este mprit n dou pn cnd valoarea dorit a cheii de acces este mijlocul sau pn cnd mrimea tabelei rmase este zero, implicnd c valoarea cutat a cheii de acces nu se afl n tabel. Numrul maxim de comparaii cerute pentru o cutare binar ntr-o tabel sortat de n intrri este log2n. Numrul mediu de comparaii este jumtate din acesta, ceea ce este mai bine dect n cazul secvenial, n special la tabele mari. Costul este regia de a pstra nregistrrile tabelei sortate dup valorile cheii de acces. Indeci arbori binari de cutare. O abordare menit s obin beneficiul performanei cutrii binare, evitnd n acelai timp pstrarea nregistrrilor din tabel ntr-o ordine fizic secvenial dup valorile cheii de acces, o constituie indexul arbore binar de cutare. Un arbore este o structur de date n care fiecare nregistrare pointeaz la una sau mai multe nregistrri. Aceti pointeri pot fi folosii pentru a accesa nregistrrile ntr-o ordine alta dect secvena lor fizic. Un arbore binar este un tip special de arbore n care fiecare nregistrare poate pointa la maximum dou alte nregistrri. Exist mai multe moduri pentru a

268

organiza un arbore astfel nct accesul la nregistrrile lui s fie convenabil. Un mod este cel numit arbore binar de cutare, n care nregistrrile sunt aranjate pentru a simplifica cutarea n arbore. Un arbore binar de cutare este prezentat n fig.10.20. O cutare a unei valori particulare de cheie de acces ncepe la rdcina arborelui. Dac valoarea este cheii de acces este egal cu valoarea cheii de acces a nregistrrii rdcin, nregistrarea a fost regsit. n caz c valoarea cutat este mai mic dect dect valoarea cheii din rdcin, cutarea va continua n subarborele stng, altfel ea se va desfura n subarborele drept. Aceste comparaii i selectri de direcii de cutare se fac n fiecare nod al arborelui pn cnd valoarea int a cheii de acces este regsit sau se determin c aceasta nu se afl n arbore. Fiecare pas de cutare restricioneaz numrul de nregistrri rmase la cele din subarborele selectat. Toate valorile cheii de acces din subarborele stng trebuie s fie mai mici dect valoarea cheii de acces a rdcinii subarborelui, iar toate valorile cheii de acces din subarborele drept trebuie s fie mai mari dect valoarea cheii de acces a rdcinii subarborelui. Aceste dou reguli trebuie s se aplice fiecrui nod din arbore i ele trebuie s fie impuse atunci cnd o nregistrare se adaug, se terge sau se modific. Fiecare nregistrare dintr-un index arbore binar de cutare conine un pointer adiional la un fiier de date (fig.10.21.). Fiecare nregistrare conine deci o valoare de cheie de acces i trei pointeri, doi spre subarbori i unul spre fiierul de date. Cei mai eficieni arbori binari de cutare sunt cei perfect balansai, la care doar nodurile frunze nu au cte doi subarbori.

269

stnga

cheie 51236

dreapta

stnga

cheie 31112

dreapta

stnga

cheie 82917

dreapta

stnga

cheie 21032

dreapta

stnga

cheie 47363

dreapta

stnga

cheie 92643

dreapta

Fig.10.20. Arbore binar de cutare.

270

stnga

cheie 51236

dreapta

stnga

cheie 31112

dreapta

stnga

cheie 82917

dreapta

stnga

cheie 21032

dreapta

stnga

cheie 47363

dreapta

stnga

cheie 92643

dreapta

Fiier de date

Fig.10.21. Index arbore binar de cutare. Indeci B-arbori. Pentru a nbunti performanele cutrii se folosete o form general a arborelui binar de cutare pentru a structura un index, anume arborele multici, sau m-ci (m > 2). Dac m = 4, atunci fiecare comparaie va rejecta trei ptrimi din spaiul de cutare rmas. ntr-un arbore binar fiecare rejecta doar jumtate din spaiul de cutare. Fiecare nregistrare index dintr-un arbore de cutare cu m ci conine maximum m-1 valori de cheie de acces i m pointeri. Valorile cheii de acces din fiecare nregistrare sunt sortate i toate valorile cheii de acces din subarborele pointat de ctre cel de al i-lea pointer sunt mai mici dect a ia valoare a cheii de acces. Valorile cheii de acces ale subarborelui pointat de cel de-al m-lea pointer sunt mai mari dect ultima valoare a cheii de acces (i.e. m-1) Fiecare cheie de subarbore este de asemenea un arbore de cutare cu m ci. Un B-arbore de ordinul m este un arbore de cutare cu m ci cu urmtoarele proprieti:

271

 fiecare nregistrare, cu excepia rdcinii i a frunzelor, are cel puin m/2 subarbori i nu mai mult de m subarbori, adic este cel puin jumtate plin. rdcina fie nu are nici un subarbore, fie are cel puin doi subarbori, adic arborele se ramific devreme. toate frunzele sunt la acelai nivel, adic la acceai distan de rdcin. Fig.10.22. prezint un B-arbore cu 3 ci. Fiecare nregistrare conine maximum dou valori de cheie de acces i trei pointeri i fiecare frunz este la o distan de 3 de la rdcin. Pentru a gsi valoarea de cheie de acces 42, se efectueaz urmtoarea secven de comparaii: deoarece 42 este strict mai mic dect prima valoare a cheii de acces (69) n nregistrarea a, se urmeaz primul pointer din aceast nregistrare. deoarece 42 este mai mare dect prima valoare de cheie de acces (19) din nregistrare b, nu se urmeaz primul pointer din b. deoarece 42 este mai mic dect a doua valoare de cheie de acces din b (43) se urmeaz al doilea pointer din b. deoarece 42 este mai mare dect prima valoare de cheie de acces din e (26) nu se urmeaz primul pointer din e. deoarece 42 este mai mare dect a doua valoare de cheie de acces din e (40) nu se urmeaz al doilea pointer din e. se urmeaz al treilea pointer din e. nregistrarea n (o frunz) este cutat secvenial pentru a gsi 42 i pointerul corespunztor la nregistrarea de date. Atunci cnd se adaug o intrare la un B-arbore, regulile structurii de arbore trebuie urmate. O nou pereche <valoare cheie de acces, pointer> poate fi adugat unei nregistrri care nu este plin. Dac intrarea index potrivit (intrarea cas) nu mai are loc pentru o nou valoare cheie de acces i pointer, trebuie creat o nou intrare. Jumtate din perechile <valoare cheie de acces, pointer> din intrarea cas sunt mutate n noua intrare. Pointerii din urmtorul nivel al indexului trebuie, de asemenea, ajustai pentru a include o cale spre noua intrare. Dac intrarea index tat este de asemenea plin, trebuie spart i ea. n cel mai ru caz, introducerea unei noi ntrri ntr-un B-arbore poate s nsemne spargerea tuturor nodurilor de pe calea pn la rdcin, lungind astfel toate drumurile de cutare cu unu. O variant a B-arborelui este B+-arborele. ntr-un B+-arbore, intrrile frunze sunt conectate pentru a forma o list nlnuit de valori de cheie de acces n ordine secvenial. (fig.10.23.) Valorile cheii de acces din frunze sunt valorile cheii de acces ale nregistrrilor din fiierul de date iar valorile cheii de acces din restul arborelui orienteaz accesul spre frunze. Astfel, o cheie de acces care apare ntr-o intrare non-frunz va apare de asemenea ntr-o frunz, dac ea corespunde valorii cheii de acces a unei nregistrri din fiierul de date.

272

B+-arborii suport att accesul direct ct i cel secvenial dup valorile cheii de acces. Att B-arborii ct i B+-arborii sunt larg folosii de ctre DBMS-uri. Ei ofer ci de acces relativ scurte, fr a fi nevoie de regie mare atunci cnd nregistrrile sunt introduse sau terse. Se poate construi orice numr de B-arbori sau B+-arbori, ca i indeci n vrful unui fiier relativ sau secvenial-indexat, oferind astfel accesul dup chei multiple. DBMS-urile folosesc conbinaii variate de structuri fizice pentru a implementa modelele lor de date logice. Caracteristicile de performan ale bazelor de date sunt determinate de gradul n care acestea suport accesele la date. Aceast performan este afectat de: 1. volumul datelor: bazele de date mici lucreaz mai bine dect bazele de date mari. 2. patternurile de folosire: o structur care este potrivit pentru a mnui o mare varietate de cereri de interogare este uzual mai slab performant pentru accese de actualizare i reciproc. 3. combinarea de tranzacii: o structur de date poate fi potrivit pentru a realiza bine o mulime cunoscut de tranzacii. Dac combinarea de tranzacii se schimb, se schimb i performanele. 4. cerine de cretere: o structur de date care este privit pentru o baz de date mic poate s se comporte mai puin bine atunci cnd volumul nregistrrilor crete. 5. caracteristicile restului sistemului de calcul: un calculator care este ncrcat puternic va prelucra mai ncet baza de date dect unul dedicat DBMS-ului. 6. politicile de gestionare a bufferelor: o strategie de gestionare a datelor care basculeaz nregistrrile de date n index ntre memoria central i un mediu secundar de memorare are performane mai slabe dect o strategie care ine n general nregistrrile int n memorie. Proiectantul bazei de date trebuie s creeze structurile bazei de date fizice care ofer nivele acceptabile de performan. Structurile i tranzaciile bazei de date trebuie s fie monitorizate pentru a detecta cerinele de modificare. Structurile fizice pot fi apoi rafinate pantru a continua s se comporte adecvat. DBMS-ul ascunde utilizatorilor i programatorilor de aplicaii detaliile de gestionare a structurilor de date fizice. DBMS-ul gestioneaz pointerii. Folosind serviciile DBMS-ului, utilizatorii se reorienteaz de la focalizarea pe gestionearea structurilor de date fizice la focalizarea pe suportul de gestionare a aplicaiilor logice.

273

a 69 b 19 43 c 120

d 16 7 15 18 15

e 26 20 22 40 30 41 42

f 50 46 53 54

g 100 70 75 110

h 123 121122 126

Fig.10.22. Un B-arbore cu 3 ci.

274

65

20

53

120

15 7 15 18 20 24

25

42 32 40 46 52

55 55

63 6162 8183

84 92 95

95 101

101

113 115 0

110113

Fig.10.23. Un B+-arbore cu 3 ci.

275

10.6. Comentarii finale

Memento Adres absolut Funcie de calcul a adresei B-arbore Index arbore binar de cutare Buffer Tehnic de rezolvare a coliziunilor Tehnic de adresare direct Colectarea gunoilui nregistrare antet Organizare de fiier secvenial-indexat Intrare de inversiune Metod de transformare cheie n adres Arbore de cutare cu m ci Index primar nlnuirea sinonimelor Index secundar Aparat de memorare cu acces secvenial Sinonim Arbore Cheie de acces Cheie alternat B+-arbore Bloc Algoritm CALC Fiier de date Hashing dublu Funcie hash Gaur Fiier index Structur de inversiune List nlnuit Pointer nul Cheie primar Organizare de fiier relativ Cheie secundar Cheie de sortare Tehnic de acces Copie de arhiv Cutare binar Adresarea blocurilor Lan Aparat de memorare acces direct List dublu nlnuit Hashing Adres cas Adresare indirect ncercare liniar Memorie principal Baz de date fizic Tehnici de randomizare Adres relativ Memorie secundar Fiier sortat Tabel index Index alternat Copie de backup Arbore de cutare binar Factor de blocare Coliziune Direct Organizare de fiier Metoda tabel hash Index Pointer interfiiere Pointer intrafiier Organizare de fiier multilist Pointer Adresarea nregistrrilor Tehnici memorare mprtiat Organizare de fiier secvenial Subarbore Copie de transport

243

Bibliografie 1. Cohen, J. (1981) Garbage collection of linked data structures, ACM Computing Surveys, 13. 2. Comer, D. (1979) The ubiquitous B-tree, ACM Computing Surveys, 11. 3. Knuth, D.E. (1973) The Art of Computer Programming, Vol.3: Sorting and Searching, Addison Wesley, Reading, Mass. 4. Loomis, M.E.S. (1983) Data Management and File Processing, Prentice Hall, Englewood Cliffs, N.J. 5. Nievergelt, J. (1974) Binary search trees and file organisation, ACM Computing Surveys, 6. Tannenbaum, A.M.; Augenstein, M.S. (1981) Data Structures Using Pascal, Prentice Hall, Englew

Capitolul 11. Proiectarea fizic a bazelor de date relaionale.

Proiectarea fizic a bazelor de date va fi prezentat comparnd mai multe abordri pentru memorarea datelor relaionale. Vom folosi ca baz pentru aceste alternative sisteme reale, fr a da ns toate detaliile acestora. Intenia noastr este mai degrab de a arta cum se leag ntre ele abordrile i care sunt implicaiile lor pentru proiectarea bazelor de date fizice. Unul din obiectivele discutrii variatelor alternative de implementare fizic a bazelor de date relaionale este de a sublinia n continuare distincia dintre proiectarea logic i cea fizic. Aproape niciodat nu exist o modalitate unic pentru implementarea unei proiectri logice. Pe de alt parte, proiectarea fizic determin costul de execuie al sistemului i trebuie s satisfac necesitile de date ale utilizatorului n mod eficient. Eficiena este msurat prin resursele calculatorului pe care sistemul baz de date le folosete: timpul de calcul, accesul la mediul secundar, traficul de comunicaii, spaiul de memorare, etc. 11.1. Cerinele de baz pentru o baz de date relaional fizic Implementarea fizic a unei baze de date realionale trebuie: 1. s fie translatabil n tabele. 2. s fie accesibil dup valoarea oricrui atribut, i nu numai dup identificatorii unici. 3. s suporte operatorii relaionali.

244

Translatabil n tabele. Pentru a implementa relaii logice se pot folosi o variatate de structuri de date, una dintre ele fiind o simpl tabel (i.e. un tablou) pentru fiecare relaie. n acest, caz, structura fizic oglindete structura logic. Alte structuri de date sunt listele nlnuite i arborii. Indiferent de structura de date fizic folosit, ea trebuie s fie invizibil utilizatorului, adic acesta trebuie s vad datele ca i cnd ele ar fi aezate n tabele, fr a-i psa de modul n care acestea sunt memorate efectv. Accesibil dup orice atribut. Indiferent de structura de date fizic folosit, utilizatorul trebuie s poat s cear acces la date specificnd valoarea oricrui atribut al relaiei.. De exemplu, s considerm relaia: PROFESOR (NUME_PROFESOR, MARCA#, RANG, NUME_CATEDRA, NUME_FACULTATE, TELEFON, DATA_NASTERII, DATA_ANGAJARII). Utilizatorul trebuie s poat cere liniile din PROFESOR cu o valoare oarecare a lui NUME_PROFESOR, sau a lui MARCA# sau a oricrui atribut i nu trebuie s fie restricionat n aceasta la atributele ce identific unic cheia. Suport operatorii relaionali. Structura de date fizic trebuie s fie capabil a suporta operaiile de SELECT, PROJECT i JOIN, fr a cere utilizatorului poziionri n structura de date prin pointeri i adrese. Managerul bazei de date trebuie s fie n stare s regseasc o submulime a liniilor tabelei care satisfac criteriul de calificare bazat pe valori de atribute, s regseasc o submulime specific de coloane ale tabelei, precum i s combine tabele potrivind valorile atributelor de legtur. Operatorii relaionali de baz trebuie s fie suportai fr ca utilizatorul s trebuiasc s specifice ci de acces prin structura de date fizic i utilizatorul nu trebuie s tie care nregistrri pointeaz la care sau cum se obine un tuplu din altul. DBMS-urile relaionale ofer diferite limbaje pentru a manipula tabele. Operatorii specifici SELECT, PROJECT i JOIN nu trebuie s apar neaprat, funciile lor trebuie ns oferite. 10.2. Transformrile logico-fizice de baz Exist mai multe abordri legate de maparea relaiilor logice n relaiile fizice. Cea mai direct transformare logic-fizic este de a implementa fiecare tabel a schemei conceptuale ca o singur relaie de baz. ns, pentru a nbunti performana sistemului, proiectantul bazei de date fizice trebuie s determine dac una din urmtoarele transformri logic-n-fizic ar fi mai potrivit: partiionarea vertical a unei tabele: spargerea tabelei n mai multe relaii de baz, fiecare cu o parte din atributele (coloanele) relaiei iniiale (fig.11.1).

245

 partiionarea orizontal a unei tabele: spargerea tabelei n mai multe relaii de baz, fiecare cu o parte din tuplele (liniile) relaiei iniiale (fig.11.2.) reuniunea tabelelor: combinarea tabelelor ntr-o singur relaie de baz (fig.11.3.) Aceste transformri vor avea ca rezultat relaii de baz care nu corespund exact cu tabelele de start. 11.2.1. Partiionarea vertical. Partiionarea vertical proiecteaz anumite coloanele tabelei ntr-o relaie i celalalte coloane n alt relaie. Coloanele cu cheia primar apar n ambele relaii de baz, astfel nct tabela logic original poate fi reconstituit. Partiionarea vertical poate fi potrivit dac anumite coloane ale tabelei sunt accesate mai frecvent dect celelalte. Separnd coloanele accesate mai rar de cele accesate mai des se reduce volumul de date care trebuie copiate de pe memoria secundar ca rspuns la o cerere. Astfel tranzaciile care cer date numai din partiia frecvent accesat nu trebuie s transfere i coloanele de care nu au de fapt nevoie. Partiionarea vertical poate fi de asemenea potrivit atunci cnd anumite coloane ale tabelei sunt accesate n primul rnd de un alt grup. Aceast form de partiionare este n special util atunci cnd aceste grupuri de utilizatori sunt separate geografic. Rezultatul este o baz de date distribuit, cu anumite relaii bazate pe un calculator i altele pe altul (fig. 11.4.). De exemplu, coloanele tabelei ANGAJAT care conin date despre compnesaii pot fi memorate pe calculatorul departamentului Salarizare iar celelalte coloane ale aceleai tabele pe calculatorul departamentului Personal. O baz de date distribuit eficient memoreaz datele acolo unde acestea vor fi accesate. Accesul la date memorate local evit costurile de comunicare cu alte calculatoare i alte partiii ale bazei de date distribuite. O alt aplicaie a partiionrii verticale este de a fora restriciile de baz. Un utilizator are acces fie la o relaie de baz n ntregul ei, fie nu are acces de loc. Dac anumite coloane ale tabelei sunt necesare utilizatorilor cu un nivel de autorizare, iar celelalte utilizatorilor cu un alt nivel de autorizare, atunci punnd coloanele n relaii de baz diferite vom putea permite managerului bazei de date s impun restriciile de securitate.

246

247

Cont Cont# Nume_ Zona_ client client Balana Telefon client

Cont_client Cont# Nume_ Zona_ client client Telefon client

Balan_cont Cont# Balan

Fig. 11.1. Partiionarea vertical a relaiei CONT n dou relaii CONT_CLIENT i BALANTA_CONT. CONT_CLIENT = SELECT CONT#, NUME_CLIENT, ZONA_CLIENT, TELEFON_CLIENT FROM CONT; BALANTA_CONT = SELECT CONT#, BALANTA FROM CONT;

248

Cont Cont# Nume_ client Zona_ client Balana Telefon client

Cont_nord Cont# Nume_ client Zona_ client Balana Telefon client

Cont_sud Cont# Nume_ Zona_ client client Balana Telefon client

Fig. 11.2. Partiionarea orizontal a relaiei CONT n dou relaii CONT_NORD i CONT_SUD. CONT_NORD = SELECT ALL FROM CONT WHERE ZONA_CLIENT = NCA OR OR; CONT_SUD = SELECT ALL FROM CONT WHERE ZONA_CLIENT = 'SCA OR NV;

249

Cont Cont# Nume_ Zona_ client client Balana Telefon client

Info_cont Cont Zona Nume Agent # client client Balana Telefon Tip Data client cont

Istorie_cont Cont# Tip Data Agent

Fig. 11.3. Reuniunea relaiilor CONT i ISTORIE_CONT pentru a forma relaia INFO_CONT. INFO_CONT = SELECT ALL FROM CONT, ISTORIE_CONT WHERE CONT.CONT# = ISTORIE_CONT.CONT#;

250

11.2.2. Partiionarea orizontal. Partiionarea orizontal pune mai multe linii ale unei tabele ntr-o relaie de baz i celelalte linii n alt relaie. Tabela logic original poate fi reconstruit fcnd reuniunea celor dou relaii de baz. (fig.11.2) Partiionarea orizontal poate fi potrivit dac anumite linii ale tabelei sunt accesate mult mai frecvent dect celelalte linii. Separnd liniile frecvent accesate de cele accesate mai rar reducem volumul de date care trebuie copiate pe/ de pe memoria secundar ca rspuns la cerere. Astfel, tranzaciile care cer date numai din partiia frecvent accesat nu trebuie s trag dup ele datele din cealalt partiie. Partiionarea orizontal poate fi de asemenea util atunci cnd anumite linii ale tabelei sunt accesate de un anumit grup de utilizatori iar celelalte de ctre un alt grup. Ca i n cazul partiionrii verticale, dac cele dou grupuri sunt separate geografic, rezultatul va fi o baz de date distribuit. De exemplu, liniile din tabela CONT ar putea fi memorate n Timiora pentru Banatul de Sud i n Arad pentru Banatul de Nord. 11.2.3. Reuniunea. Liniile mai multor tabele pot fi combinate ntr-o relaie de baz, o transformare care cere ca tabelele constituente s aib un atribut comun. (fig.11.3). Uzual, acest atribut este atributul de cheie primar al unei tabele i atributul de cheie strin a celeilalte tabele. Reuniunea este potrivit atunci cnd cele dou tabele sunt aproape ntotdeauna accesate mpreun, cu o operaie de JOIN pe atributul comun. De exemplu, s considerm modelul de date din fig.11.5. i relaiile sale corespunztoare din fig.11.6. Dac liniile JOB i APTITUDINI_JOB asociate sunt aproape ntotdeauna accesate mpreun, atunci relaia din fig.11.7. ar fi potrivit. S notm c datele din JOB se repet pentru fiecare linie APTITUDINI_JOB. Reuniunea fizic poate conduce att la nbuntirea performanei ct i la dificulti de meninere a consistenei, deoarece ea reduce nivelul de normalizare.

352

Calculator1 Relaii de baz B1 B2 B3 B4

Calculator2 Relaii de baz B1 B5 B6

Calculator3 Relaii de baz B1 B2 B6 B8 B9

Fig. 11.4. O baz de date distribuit cu relaii memorate pe mai multe calculatoare conectate printr-o reea de comunicaii.

Job Cod_Job Titlu_Job

cere Aptitudini_Job Cod_Job Aptitudine# Descr_aptitudine

Fig. 11.5. Un model de date.

353

JOB COD_JOB 60 70 80

TITLU_JOB Secretar Programator Manager

APTITUDINI_JOB COD_JOB APTITUDINE# 60 463 60 231 70 231 70 801 60 333

DESC_APTITUDINE Tehnoredactare Editare Editare C Procesare date

Fig. 11.6. Relaiile corespunztoare modelului de date din fig.11.5.

APTITUDINI_JOB_DE_BAZA COD_JOB TITLU_JOB APTITUDINE# 60 Secretar 463 60 Secretar 333 60 Secretar 231 70 Programator 231 70 Programator 801 80 Manager 0

DESC_APTITUDINE Tehnoredactare Procesare date Editare Editare C 0

Fig.11.7. Relaia de baz format prin reuniunea relaiilor din fig.11.6. 11.2.4. Aplicabilitatea transformrilor. Faptul c o transformare particular este potrivit pentru o tabel dat depinde de mai muli factori, incluznd: limea tabelei (i.e. numrul de bytes dintr-o linie). lungimea tabelei (i.e. numrul de linii). patternurile de acces la tabel: unele linii sunt mai frecvent accesate dect altele. unele coloane sunt mai frecvent accesate dect altele. unele tabele sunt accesate frecvent mpreun.

354

Putem face anumite generalizri ale efectelor factorilor de mai sus, dac considerm fiecare factor n mod independent, pe fondul nemodificrii celorlali. Cu ct o tabel e mai larg, probabilitatea ca ea s poat fi partajat vertical este mai mare. Cu ct o tabel e mai lung, probabilitatea ca ea s poat fi partajat orizontal este mai mare. Cu ct accesul este ndreptat mai mult spre o submulime a liniilor unei tabele cu att mai mare va fi probabilitatea ca ea s poat fi partiionat orizontal. Cu ct accesul este ndreptat mai mult spre o submulime a coloanelor unei tabele cu att mai mare va fi probabilitatea ca ea s poat fi partiionat vertical. Cu ct dou tabele sunt accesate mai frecvent mpreun cu att va fi mai mare probabilitatea ca ele s poat fi reunite ntr-o singur relaie de baz. 11.2.5. Vederi utilizator. ntr-un mediu cu trei scheme, vederile utilizator (i.e. schemele externe) sunt construite prin operaii relaionale asupra tabelelor schemei conceptuale: selectarea de linii care satisfac anumite criterii de calificare, proiecia anumitor coloane, reuniunea tabelelor dup valori de atribute care se potrivesc. Maparea ntre tabelele schemei conceptuale i relaiile de baz ale schemei interne este folosit apoi pentru a localiza datele pentru o vedere utilizator particular. ntr-un mediu cu dou scheme, vederile utilizator sunt mapate direct pe relaiile de baz, neexistnd schema conceptual. Fiecare vedere utilizator poate lua date din mai multe relaii i fiecare relaie de baz suport mai multe vederi utilizator. Definiia vederilor permite ca accesul utilizatorilor s fie restricionat la submulimi ale bazei de date i combinaii diferite de date pot fi folosite pentru a suporta diferite aplicaii. 11.3. nbuntirea performanei. Fiecare din aceste transformri ntre tabele i relaii de baz ncearc s nbunteasc performana bazei de date, reducnd volumul datelor transferate la/ de la memoria secundar i reducnd cerinele de comunicaii ntr-o reea de calculatoare. Atunci cnd se dezvolt o structur eficient a bazei de date fizice mai trebuiesc luate i alte decizii: Accesul la atribut: care atribute trebuie s aib ci de acces rapide preconstruite?

355

 Reuniuni preconstruite: care reuniuni ntre relaiile de baz trebuie s aibe ci de acces rapide preconstruite? Buffere: ct de mare trebuie s fie spaiul buffer pentru a transfera relaiile de baz ntre memoria principal i cea secundar? Gruparea relaiilor fizice: ce relaii de baz ar trebui memorate mpreun n acelai fiier? 11.3.1. Accesul la atribut. Multe in DBMS-urile relaionale permit proiectantului bazei de date s specifice care atribute vor avea ci de acces rapide preconstruite. Aceste atribute sunt acelea pentru care utilizatorii specific valori atunci cnd ei doresc s accead anumite linii din tabel. Proiectantul bazei de date analizeaz patternurile de acces la tabel, determinnd ct de frecvent urmtorul tip de acces este specificat: SELECT list de nume de atribute FROM nume tabel WHERE nume atribut1 = valoare1 AND nume atribut2 = valoare2 AND ... Cu ct apare mai frecvent un nume de atribut n clauzele WHERE a cererilor de regsire i de actualizare, cu att mai mult trebuie spre el o cale de acces rapid preconstruit. Prezena unei astfel de ci poate afecta semnificativ performana bazei de date. Prelucrarea unei cereri care calific liniile pe baza valorilor atributelor pentru care nu exist cale de acces rapid implic tipic o analiz secvenial a poriunii bazei de date coninnd tabela cerut. ntr-o ncercare de a nbunti performana pentru cererile urmtoare, anumite DBMS-uri construiesc i memoreaz automat ci de acces rapid atunci cnd o cerere calific liniile pe baza unui atribut care nu a avut deja o cale preconstruit. Cile de acces rapid preconstruite sunt implementate fie prin structuri de indeci, fie prin hashing pe valorile atributului desemnat. Structurile de indeci sunt, n general, variante ale structurilor B-arbori (vezi cap.10). Structurile hash sunt calcule de adrese pe buci sau pe blocuri dintrun fiier (de asemenea prezentate n cap.10). n majoritatea DBMS-urilor comerciale, numai un atribut al unei relaii de baz poate avea o cale de acces rapid preconstruit prin hashing. Valorile acestui atribut determin locaiile de memorie ale liniilor relaiei. n contrast, multe din atributele unei relaii de baz pot avea ci de acces rapid preconstruite implementate prin structuri de indeci. Fiecare structur de index pointeaz la o mulime de linii din relaie, n concordan cu valorile de atribut ale acestor linii.

356

Atributele care cer cel mai adesea ci de acces rapid preconstruite sunt atributele de cheie primar, atributele de cheie alternat i atributele de cheie strin. Atributele de cheie primar trebuie s aib aproape ntotdeauna ci de acces rapid preconstriute. Identificatorul unic al unei linii al tabelei este n general folosit n cererea de acces la acea tabel. Dac o relaie de baz are calea de acces rapid preconstruit implementat ca i o funcie hash, atunci acea cale de acces este ntotdeauna implementat pe atributul de cheie primar. Dac cheia primar este compus, atunci calea de acces rapid este construit pe mulimea de atribute care alctuiesc cheia primar. De exemplu, dac cheia primar este COD_DIVIZIE, ID_DEPARTAMENT atunci hashingul sau indexarea se face pe combinaia celor dou atribute. Calea de acces cheie primar nu ar fi implementat corect cu un index pe COD_DIVIZIE i un alt index pe ID_DEPARTAMENT. Atributele de cheie alternat pot avea ci de acces rapide, dac ele sunt folosite n comun n loc de cheie primar pentru accesul la tabel. De exemplu, ANGAJAT# este cheia primar a tabelei ANGAJAT, dar cheia alternat SSN# este mai folosit pentru a califica liniile, atunci pot exista o cale de acces la ANGAJAT# i una la SSN#. Utilizatorii pot astfel accesa uor datele din ANGAJAT bazndu-se pe oricare din cele dou atribute. Atributele de cheie strin pot avea ci de acces rapid preconstruite dac valorile lor sunt folosite uzual pentru a califica liniile tabelei i/sau dac tabela este reunit frecvent cu tabela n care atributul de cheie strin apare ca i cheie primar. Cele dou tabele pot fi reunite mai eficient dac exist indeci pentru atributele de reuniune. Alte atribute pot avea ci de acces rapide dac ndeplinesc toate condiiile urmtoare: valorile lor sunt folosite n mod obinuit pentru a califica linii. valorile lor nu sunt actualizate frecvent. valorile lor sunt discriminatorii. Meninerea unei ci de acces rapid pentru un atribut ale crui valori se actualizeaz des este costisitoare. Dac un atribut este indexat, atunci de fiecare dat cnd valoarea lui se schimb pentru linie, structura de index trebuie modificat. Dac liniile sunt n hashing, atunci schimbnd valoarea atributului hash aproape ntotdeauna apare necesar i o mutare a nregistrrii liniei. Un atribut discriminator este unul pentru care un procent relativ mic din liniile tabelei au o valoare particular a acelui atribut. De exemplu, n relaia ANGAJAT, atributul COD_SEX nu este un atribut discriminator, cci exist doar dou valori posibile pentru acest atribut. Astfel construind un index dup COD_SEX ar fi costisitor i nu va reduce numrul de nregistrri analizate ca rspuns la o cerere utilizator. Pe de alt parte, COD_JOB probabil s este un atribut discriminator. Dac exist 100 de valori posibile 357

pentru COD_JOB, atunci un index care suport accesul direct pe COD_JOB reduce o cutare la 1% din nregistrri. 11.3.2. Reuniuni preconstruite. Un alt mod de a nbunti performana este de a construi ci de acces rapide la tabele JOIN (reuniune) nainte de a primi cererea utilizatorului pentru reuniune. Reuniunea a dou tabele mari poate fi un proces consumator de resurse, cci pentru fiecare valoare a atributului de reuniune dintr-o tabel trebuie gsit linia cu valoarea atributului de reuniune din cealalt tabel. Dac aceai reuniune va fi cerut n viitor, atunci reinnd corespondena dintre cele dou tabele, evitm refacerea potrivirilor. Corespondena dintre tabelele reunite poate fi reinut n mai multe moduri, incluznd: un director cu valori atribut - reuniune, cu pointri la liniile pertinente din fiecare din cele dou tabele (fig.11.8). liste nlniute, cu un lan de pointeri de la fiecare linie dintr-o tabel la liniile potrivite din cealalt tabel (fig.11.9). Nu toate DMBS-urile relaionale suport reuniuni preconstruite. Proiectantul bazei de date fizice trebuie s determine care reuniuni ar putea fi preconstruite, pe baza beneficiilor prezise. DIRCTOR Valoare B b1 b1 b2 b3 b3 b4 b5

Pointer R 1 2 3 4 5 0 0

Pointer S 1 1 2 3 3 4 5

R A a1 a2 a3 a4 a5

B b1 b1 b2 b3 b3

C c1 c2 c3 c4 c5

358

S B b1 b2 b3 b4 b5

D d1 d2 d3 d4 d5

E e1 e2 e3 e4 e5

Fig.11.8. Director coninnd valorile atribut - reuniune cu pointeri la dou tabele de baz. Relaiile R i S sunt reunite prin atributul B. S B b1 b2 b3 b4 b5 R A a1 a2 a3 a4 a5

D d1 d2 d3 d4 d5

E e1 e2 e3 e4 e5

Primul R cu valoarea B 1 3 4 0 0

B b1 b1 b2 b3 b3

C c1 c2 c3 c4 c5

Urmtorul R cu valoarea B 2 0 0 5 0

Fig.11.9. List nlniut de reuniuni preconstruite pe atributul B n relaiile de baz R i S. 11.3.3. Buffere. O alt cerin este gestionarea bufferelor pentru transferul relaiilor de baz ntre memoria principal i cea secundar. Multe DBMS-uri relaionale dau proiectantului bazei de date posibilitatea de a specifica mrimea fiecrui buffer i numrul de buffere. Obinuit, mrimea unui buffer este aceai cu mrimea unei pagini din memoria principal, care este determinat de ctre sistemul de operare. Numrul de buffere trebuie s fie suficient de mare pentru a pstra n memoria principal setul de lucru de linii folosite n 359

servirea unei cereri, aceasta depinznd de caracteristicile cererii i de coninutul bazei de date. 11.3.4. Gruparea relaiilor de baz. Un DBMS relaional folosete posibilitile sistemului de gestiune a fiierelor din sistemul de operare pentru a memora i accesa relaii de baz. Un fiier este ntr-un spaiu de adrese compus dintr-o colecie de pagini de aceai mrime i poate s fie rezident n memoria principal sau secundar. Astfel de fiiere se folosesc pentru a memora datele utilizator, structurile de date pentru cile de acces, date din directorii interni, rezultate intermediare generate ca rspuns la interogaii. Managerii bazelor de date relaionale difer prin modul n care ei mapeaz aceste relaii n fiiere: o relaie de baz - un fiier. Fiecare fiier conine linii dintr-o relaie de baz i o relaie de baz apare ntr-un singur fiier. N relaii de baz - un fiier. Fiecare fiier conine linii din mai multe relaii de baz, dar fiecare relaie de baz apare ntr-un singur fiier. N relaie de baz - M fiiere. Fiecare fiier conine linii din mai multe relaii de baz i fiecare relaie de baz poate apare n mai multe fiiere. o relaie de baz - M fiier. Fiecare fiier conine linii dintr-o relaie de baz, dar o relaie de baz poate apare n mai multe fiiere. Schema care este folosit este determinat de ctre DBMS i nu de ctre proiectantul bazei de date fizice. Cunoaterea ei ajut proiectantul n luarea de decizii. Dac un fiier conine linii din mai multe relaii de baz, atunciproiectantul bazei de date poate grupa acele date care se pare c se vor accesa mpreun. De exemplu, dac tuplele din dou relaii de baz sunt frecvent accesate mpreun, s spunem din cauza unui join ntre ele, atunci proiectantul trebuie s ia n considerare posibilitatea de a le memora mpreun. Astfel vor fi necesare mai puine accese la memoria secundar pentru a rspunde cererilor de date. Dac tuplele din dou relaii de baz sunt numai rar accesate mpreun, atunci ele trebuie memorate n fiiere separate. Obiectivul este de a grupa pe o pagin tuplele care par a fi accesate mpreun. O alt posibilitate pentru gruparea fizic este de a plasa pe o aceai pagin liniile care par a fi accesate mpreun. Aceste linii pot fi de la aceai relaie sau de la relaii diferite, presupunnd c un fiier poate memora mai multe de o relaie. Gruparea fizic este facut uzual, de: valoare atribut, astfel c liniile cu valori similare pentru un atribut desemnat sunt memorate mpreun. timpul de memorare, astfel c liniile pot fi regsite fie n secven FIFO, fie n sceven LIFO.

360

 asociaie, astfel nct ocurenele entitii fiu s fie memorate aproape de ocurena entitii lor tat. 11.3.5. Dimensionarea fiierelor. Fiecrui fiier trebuie s i se aloce suficient spaiu pentru a ncpea relaiile sale n viitorul imediat plus cel puin 20% spaiu liber. Alocarea de spaiu adiional la un fiier poate fi scump, n special dac utilizatorilor li se interzice s accead datele n timpul reorganizrii. Prea mult spaiu nseamn a plti pentru exces de capacitate, iar prea puin spaiu nseamn a nu gsi spaiu pentru noile tuple i a mnui depirile din pagini pline. 11.4. Exemple de DBMS-uri relaionale. 11.4.1. System R. System R a nceput s fie proiectat pe la mijlocul anilor 70 la IBM San Jose Res.Lab i formeaz baza pentru dou produse ale lui IBM, DBMS-urile SQL/DB i DB2. SQL/DB a devenit disponibil n 1982. Se execut pe DOS/VSE pe o varietate de calculatoare IBM de capacitate medie, inclusiv s/370, 3031, 3033, 4311, 4341. Exist utilitare pentru transferul unei baze de date DL/1 (ierarhic) ntr-o baz de date SQL, dar ele cer o mic analiz a datelor i, mai ales, reformatarea lor. DB/2 a devenit disponibil la sfritul lui 1984. Se execut pe MVS pe calculatoare IBM medii i mari. Exist utilitare care extrag o structur IMS (ierarhic) ntr-una DB2. Arhitectura. Arhitectura fundamental a lui System R este prezentat n fig.11.10. i include: Interfee de date relaionale (RDI) ntre utilizator i RDS. Sistem de date relaionale RDS. Interfa de memorare relaional (RSI) ntre RDS i RSS. Sistem de memorare relaional (RSS). RDI poate fi apelat direct dintr-un limbaj de programare (PL/I, COBOL, FORTRAN, asamblor) sau din alt interfa utilizator (SQL, QBE). Programatorul sau utilizatorul folosete facilitile limbajului RDI. Utilizatorul interacioneaz cu poriuni (i.e. vederi) ale bazei de date relaionale, care sunt de interes pentru aplicaia lui i consistente cu autorizrile de acces. RDS suport RDI i realizeaz maparea ntre relaiile de baz i vederile utilizator. El ofer i verificarea i forarea autorizrii precum i a restriciilor de integritate. RSI este o interfa intern care ofer acces la linii unice din relaiile de baz. El trimite cte o linie la un moment dat ntre Rss i RDS. RSS gestioneaz aparatele de memorare, alocarea spaiului, consistena i ncuierea tranzaciilor, detectarea de deadlock, etc. El menine

361

indecii att pentru cile de acces rapid pe baz de atribute selectate, ct i pe reuniuni preconstruite. Faciliti interfa limbaj de programare Faciliti interfa end_user RDI

Relational Data System RDS Relational Storage System RSS

RSI

Fig.11.10. Arhitectura de baz a lui System R. Structura de fiiere. System R folosete abordarea cu N relaii, un fiier. Fiecare relaie de baz este memorat ntr-un fiier i mai multe relaii de baz pot fi grupate n acelai fiier. Un singur buffer poate, astfel, conine linii din mai multe tabele. Dac aceast grupare fizic se potrivete cu nevoile utilizatorilor, atunci performana poate fi mai bun dect n cazul n care tabelele se gsesc n fiiere separate. System R face distincie ntre fiierele care pot fi partajate i cele care sunt fiiere cu o regie mai mic, pentru relaii temporare. La fiierele temporare nu este permis accesul parajat i nici nu pot fi refcute. Structura paginii. Fiecare tuplu este memorat ca o secven contigu de valori de cmp, ntr-o singur pagin. Exist dou tipuri de 362

cmpuri, cmpuri pentru date memorate i cmpuri interne (prefix). Cmpurile pentru date memorate conin date utilizator i pot fi de lungime fix sau variabil. depinznd de definirea lor. Cmpurile interne se folosesc pentru gestionarea memoriei i accesul la linii, i includ identificatorul relaiei, cmpuri pointer nlnuind aceast linie cu alte linii precum i informaii interne adiionale. Exist dou tipuri de pagini: pagini de date i pagini rezervate. Paginile de date sunt folosite pentru a memora liniile relaiilor de baz, iar cele rezervate sunt folosite pentru a memora intrri director intern i intrri index. O pagin de date are trei seciuni: antet, corp i pointer-slot (fig.11.11.). Seciunea antet conine numrul paginii i alte date sistem; seciunea corp conine valorile cmpurilor liniei, iar seciunea pointer-slot conine pointeri la seciunea corp. Exist ct un pointer-slot per linie memorat n pagin i valoarea lui este deplasamentul locaiei liniei de la nceputul paginii. Identificatorul tuplului. La fiecare linie memorat este asociat un identificator de tuplu TID. Aceti identificatori sunt folosii de ctre RSS ca un mijloc de a adresa liniile, i nu sunt folosii de aplicaii sau utilizatori. TID-ul unei linii este numrul paginii n care este memorat linia i numrul pointer-slot-ului. Astfel, valorile TID i de pointer-slot pointeaz mpreun la locaia liniei. TID pointeaz la pointer-slot, iar acesta indic nceputul liniei. (fig.11.12.). TID sunt folosii de ctre RSS pentru a referi liniile din structurile de indeci i din lanurile de pointeri. Sistemul de pointer-slot i permite lui RSS s-i reorganizeze spaiul pe pagini dup cum este nevoie, fr a afecta valorile TID. Cu toate c valorile lor se pot schimba, slot-urile nsi nu sunt mutate din poziiile lor. Dac o linie se modific i devine prea mare pentru a ncpea n spaiul disponibil din pagina sa, atunci valoarea TID va pointa spre o nregistrare special etichetat, care la rndul ei pointeaz la locaia de depire. Accesul la o linie prin valoarea TID implic ntotdeuna accesul la o singur pagin de date i eventual o pagin de depire. Ci de acces rapid preconstruite. System R suport dou tipuri de ci de acces rapid preconstruite: imagini, care suport accesul prin valori de atribut i nlnuiri binare, care suport reuniuni preconstruite. O imagine ofer acces direct i secvenial pentru unul sau mai multe atribute i este implementat printr-o structur index multipagin similar cu un B+-arbore. Fiecare intrare n arbore este o pereche: <valoare atribut, pointer> i pointerul este orientat spre pagina index coninnd valorile atributului mai mici sau egale cu cea dat. Fiecare frunz este o pereche: <valoare atribut, TID> pointnd spre linia potrivit a relaiei de baz. Frunzele arborelui index sunt legate ntr-o list dublu nlnuit, astfel c arborele index suport att accesul secvenial ct i direct la linii dup valorile atributului. 363

Page# 100 Linia3

Alte date sistem

Antet de pagin

Linia8 Linia2 Linia5 ....... ................ Slot9 Slot8 .. ... Slot4 Slot3 Slot2 Slot1 ..... 160 120 80 40 Pointeri slot Corp pagin

Fig.11.11. Formatul paginii de date n System R.

Valoare Tid Linie 3 8 2 5 Pagin Slot 100 100 100 100 1 2 3 4 Slot 1 2 3 4

Valoare Slot Offset octei 40 80 120 160

Fig.11.12. Valori TID i valori pointer-slot. O nlnuire binar ofer o cale de acces la liniile unei relaii i liniile legate ale altei relaii. S considerm urmtoarele dou relaii:

364

DEPT (COD_DEPT, LOC_DEPT, TIP_DEPT). ANGAJAT(MARCA#, SSN#, COD_DEPT, COD_JOB, NUME_ANGAJAT) O aplicaie a nlnuirii liniare este de a prestructura reuniunile. De exemplu, o nlnuire binar poate lega fiecare linie din relaia DEPT de mulimea de linii din relaia ANGAJAT care au aceai valoare COD_DEPT. Fiecare linie DEPT are un pointer la una din liniile ANGAJAT potrivite i fiecare linie ANGAJAT are un pointer la o alt linie ANGAJAT cu acelai COD_DEPT ca i ea. O alt aplicaie a unei nlnuiri binare este ordonarea liniilor dintr-o relaie. De exemplu, o nlnuire binar poate lega fiecare linie din relaia DEPT de linia cu urmtoarea valoare de COD_DEPT n ordinea mrimii. Aceste nlnuiri binare se numesc nlnuiri unare deoarece ele nlnuie liniile ntr-o relaie i nu ntre dou relaii. 11.4.2. Ingres. Proiectul INGRES (Interactive Graphics and Retrieval System) de la University of California, Berkeley a fost baza DBMS-ului relaional comercial INGRES al lui Relational Technology. Inc. Versiunea comercial se execut pe sistemele de operare VMS i UNIX. Structura director. Baza de date relaional este descris ntr-un catalog sistem care este el nsui o mulime de relaii. Exist dou relaii sistem RELATION i ATTRIBUTE pe care le descriem mai pe larg. Relaia RELATION are cte o linie pentru fiecare relaie de baz i sistem din baza de date. Atributele relaiei RELATION includ: RELID - numele relaiei. OWNER - identificatorul utilizator al proprietarului relaiei. SPEC - cod indicnd tipul de memorare folosit de relaie. INDEXD - flag indicnd c exist un index la relaie. PROTECT - flag indicnd setarea proteciei pentru relaie. INTEG - flag indicnd forarea restriciilor de integritate pentru relaie. SAVE - timpul de via planificat pentru relaie. TUPLES - numr de linii ale relaiei. ATTS - numr de atribute ale relaiei. WIDTH - numr de octei n linie. PRIM - numr de pagini n fiierul primar al relaiei. Relaia ATTRIBUTE descrie coloanele fiecrei relaii de baz i sistem. Exist cte o linie n relaia ATTRIBUTE pentru fiecare atribut din fiecare relaie din baza de date. Atributele relaiei ATTRIBUTE includ. RELID - numele relaiei. OWNER - identificatorul utilizator al proprietarului relaiei. ATT_NAME - numele atributului. ATT_NO - poziia ordinal a atibutului n relaie. 365

OFFSET - numrul de octei de la nceputul liniei pn la atribut. TYPE - tipul de dat al atributului (ntreg, flotant, caracter, etc.) LENGTH - numrul de octei alocai atributului. KEYNO - dac atributul e parte dintr-o cheie, atunci numrul lui n cheie. Alte relaii din catalogul sistem sunt: INDEX - avnd cte o linie pentru fiecare structur index din baza de date. PROTECTION - descrie restriciile de protecie a securitii. INTEGRITY - descrie restriciile de integritate a datelor. VIEW - descrie relaiile de vederi utilizator (schema extern). Deoarece directorul este structurat ca un grup de relaii, INGRES poate opera pe directorul su cu aceleai faciliti pe care le folosete pentru datele utilizator. Structura de fiiere. INGRES folosete abordarea o relaie de baz - un fiier. Aceasta permite ca structura fiecrui fiier s fie croit dup caracteristicile unei relaii specifice. Schema de memorare folosit pentru un fiier poate fi selectat pentru a corespunde tipului de activitate ateptat de la acea relaie de baz. INGRES suport o varietate de scheme de memorare fiier: fr chei, hash, hash comprimat, ISAM i ISAM comprimat.

Urmtoarea Urmtoarea Urmtoarea linie pagin primar pagin de depire disponibil Linia3

Antet de pagin

Linia8 Linia2 Linia5 Aria de linii

...... Linia8 Linia5 ...

Linia10 Linia2 80

Linia9

Tabela de linii

Linia4 Linia3 160 1 20

deplasament n Linia1 octei al liniei n 40 pagin

Fig.11.13. Formatul paginii de date pentru INGRES. 366

Ordinea liniilor ntr-un fiier fr chei este aceai cu ordinea lor de intrare n fiier. Fiecare linie nou este adugat dup ultima linie din fiier i fiecare linie are un identificator unic (TID), care reprezint deplasamentul su, n octei, n fiier. Un fiier fr chei cere o regie mic i este potrivit pentru relaiile foarte mici. S notm c locaia de memorare a unei linii este independent de oricare din valorile atributelor sale, Aceast schem de memorare este folosit de ctre INGRES, de asemenea, pentru import i export.

George Refno=8

Alice Refno=4

Tom Refno=12

Bob Refno=6

Henry Refno=10 Herry Refno=9

Zelda Refno=14

REFNO

NUME_DEPT

1 2 3 4 5

Software Admin Operaii Vnzri Marketing

Fig.11.14. Dou fiiere baz de date, unul memorat ca arbore binar de cutare i cellalt ca tablou.

367

Structurile de memorare cu chei folosesc valoarea cheii primare a unei linii pentru a-i determina poziia de memorare. i aici fiecare linie are un TID, care este numrul paginii i numrul liniei. O linie n INGRES este echivalent cu un slot n System R. Sistemele folosesc n mod esenial aceai structur de pagin (vezi fig.11.11. i 11.13.). O diferen este aceea c INGRES are numai o relaie pe pagin, pe cnd System R are mai multe relaii pe o pagin. Alt diferen este modul de alocare a paginilor de depire. n schema de memorare hash, valoarea cheii primare este folosit pentru a calcula numrul paginii n care se memoreaz linia (vezi cap.10.). Schema hash comprimat este la fel ca schema hash, cu excepia faptului c se folosesc tehnici de comprimare a memoriei. Ele sunt utile pentru relaiile mari de date text. Schema de memorare ISAM suport accesul secvenial ct i direct bazat pe valori de cheie primar a relaiei (vezi cap.10.). Schema de memorare ISAM comprimat adaug tehnici de comprimare a memoriei la schema ISAM. Toate cele patru scheme de memorare cu chei, care ofer ci de acces rapid preconstruite prin chei primare, suport, de asemenea si ci de acces rapid preconstruite prin alte atribute. Aceste ci de acces sunt implementate prin structuri de indeci i sunt descrise de ctre relaia sistem INDEX. 11.4.3. RDMS. Abordarea RDMS (Relational Data Management System) a fost dezvoltat la mijlocul anilor 70 la MIT. RDMS a constituit baza pentru MULTICS de la Honeywell Information Systems, Inc. Structura de fiier. O baz de date fizic RDMS este compus din dou tipuri de fiiere: relaii i clase de date. O clas de date este un domeniu. Aa cum am prezentat n cap. 4. multe atribute pot s-i ia valorile dintr-un singur domeniu i un domeniu determin o mulime de valori permisibile. Deorece fiecare clas de date este memorat n propriul su fiier, structura de memorare a acelui fiier poate fi croit dup caracteristicile clasei de date. Dou exemple de tipuri de structur de memorare sunt tabloul i arborele binar de cutare. Tablourile sunt potrivite pentru memorarea mulimilor relativ mici de valori a cror secven este neesenial. Fiecare valoare nou se adaug la sfritul tabloului. Arborii de cutare binar (vezi cap. 10.) sunt potrivii pentru memorarea valorilor alfanumerice care trebuie accesate att direct ct i secvenial. Fiecare clas de date are un model de strategie de date (DSM) asociat care guverneaz procesul de accesare i gestionare a structurii de memorare pentru fiierul clasei de date. De exemplu, patru din modulele de strategie de date sunt: dsm_astring, pentru gestionarea arborilor binari. 368

 dsm_table, pentru gestionarea tablourilor. dsm_integer, pentru gestionarea memorrii ntregilor. dsm_ciph_integer, pentru gestionarea memorrii criptice a ntregilor. Fig.11.14. ilustreaz dou fiiere clas de date. Fiierul clas de date NUMEDEPT este memorat ca un tablou i este gestionat de ctre modulul de strategie dsm_table. Fiierul clas de date NUME_ANGAJAT este memorat ca i un arbore binar de cutare i este gestionat de ctre modulul de strategie de date dsm_astring. S notm c fiecrei intrri n fiecare fiier clas de date i este asignat un numr de referin (REFNO), care poate fi folosit oriunde pentru a pointa la intrare. Fiecare relaie este memorat n propriul su fiier i este structurat ca o tabel de valori REFNO. Fiecare linie a unei tabele are cte un REFNO pentru fiecare atribut din relaie. REFNO sunt att pointeri spre fiierele clas de date potrivite ct i valori ntregi pentru un atribut. Relaie:Angajat Nume angajat 8 4 14 12 Nume_dept_ curent 1 1 5 5 Nume_ultim_ dept 0 3 4 3 Procent_ asignat 100 80 50 100

Fig.11.15. Fiier relaie: intrrile sunt REFNO pointnd la fiiere clase de date. Fig.11.15. prezint un fiier relaie. Relaia are patru atribute: NUME_ANGAJAT, NUME_DEPT_CURENT, NUME_ULTIM_DEPT i PROCENT_ASIGNAT. REFNO-urile din coloana NUME_ANGAJAT sunt pointeri spre fiierul clas de date NUME_ANGAJAT; REFNO_urile din coloanele NUME_DEPT_CURENT i NUME_ULTIM_DEPT sunt pointeri spre fiierul clas de date NUME_DEPT. REFNO-urile din coloana PROCENT_ASIGNAT sunt valori actuale. Cteva din avantajele acestei abordri de implementare sunt urmtoarele: compactitate: fiecare valoare domeniu (i.e. clas de date) este memorat numai o dat i nu de fiecare dat cnd este folosit ca valoare de atribut. uniformitate i simplitate: gestionarea datelor unei relaii nseamn mnuirea REFNO-urilor, care sunt valori ntregi. eficien: operaiile relaionale pot fi prelucrate eficient deoarece structurile fiierelor claselor de date sunt proiectate pe msur. 369

Fiier System_Data Nume_Angajat Nume_Dept Procent Date Performan angajat .

Director baz de date System_Data Nume_Angajat Nume_Dept Proiecte Angajat Performana

Nume_Angajat Fiier clas de date

Nume_Dept Fiier clas de date Angajat

Fiier relaie

Performan Fiier relaie

Fig.11.16. Relaii interfiiere.

370

Principalul dezavantaj al acestei abordri este c ea cere un volum mare de manipulare de fiiere pentru a opera pe relaii i pentru a afia valori de atribute. Implementarea acestei versiuni pe un sistem de operare cu un SGF ineficient poate duce la un sistem foarte lent, n ciuda proiectrii structurilor de clase de date. Structura director. Directorul pentru o baz de date RDMS este o tabel cu trei tipuri de intrri (fig.11.16.): pointeri la fiierul de date sistem, pointeri la fiierele clase de date i pointeri la fiierele relaii. Fiierul de date sistem include numele tuturor relaiilor i tuturor claselor de date precum i modulele de strategie de date asociate lor. Fiierele clas de date i relaie sunt structurate aa cum se indic n figuri. 11.4.4. Maini baz de date. O alternativ pentru a implementa o baz de date relaional este de a folosi o main baz de date, care este un calculator cu hardware specializat pentru funciile DBMS-ului. Obiectivul unei maini baz de date este de a oferi funciile DBMS-ului fr a mri resursele unui calculator de scop general i de a nbunti performana sistemului baz de date n proces. nbuntirea poate fi o combinaie ntre timp de acces mai rapid, cost hardware mai mic, ntreinere uoar a herdware-ului i software-ului, funcionalitate crescut, etc. Exist multe modaliti de a configura un sistem de maini de baze de date i calculatoare cu scop general. O configuraie simpl este prezentat n fig.11.17.: o singur gazd de tip general i o singur main baz de date. Obiectivul acestei configuraii este de a descrca prelucrarea bazei de date din gazd, un obiectiv care este aproape acelai cu cel a unui procesor de comunicaii frontend (fig.11.18.) care descarc prelucrarea comunicaiilor de date. Un procesor de comunicaii poate fi responsabil pentru oricare din urmtoarele sarcini legate de comunicaii: controlul fluxului traficului de mesaje nuntru i n afara gazdei. potrivirea diferitelor viteze de transmisie. potrivirea diferitelor scheme de codare a mesajelor. detectarea i controlarea erorilor mesajelor. sondarea terminalelor pentru traficul de mesaje. rutarea mesajelor n afara gazdei. Dnd aceste responsabiliti unui procesor de comunicaii se elibereaz resursele gazdei pentru prelucrri. Similar, o main baz de date poate fi responsabil pentru oricare din urmtoarele sarcini legate de baze de date: analiza i interpretarea cererilor utilizatorilor pentru regsirea sau actualizarea datelor. 371

selectarea cilor de acces la date. gestionarea memorrii fizice. accesarea datelor. pregtirea rezultatelor pentru livrare ctre utilizatori. oferirea refacerii datelor i a proteciei de securitate. forarea restriciilor de integritate de date. Cereri Calculator de date gazd de scop general

Main baz de date backend

Memorare a bazei de date

Fig.11.17. O configuraie cu main baz de date ca i backend la un calculator gazd de scop general.

mesaje Procesor de /cereri comunicaii frontend

Calculator gazd de scop general

Memorare de date

Fig.11.18. Folosirea unui procesor de comunicaii frontend pentru a descrca calculatorul gazd de scop general. Dnd aceste responsabiliti unei maini baz de date se elibereaz, de asemenea, resursele gazdei pentru prelucrri. O main baz de date cere, n mod uzual, un software specializat pe calculatorul gazd. Software-ul acesta este parte a interfeei dintre gazd i maina baz de date. El poate ajuta analiza i planifica execuia cererilor utilizator sau poate numai minimiza prelucrarea cererilor. Maina baz de date ideal:

372

 va face cereri minime de prelucrare ctre gazd. Un apel baz de date va fi pasat ct mai simplu posibil de la gazd la maina baz de date ntr-o form ct mai apropiat de primit de ctre gazd de la utilizator. va trimite napoi date relevante ctre maina gazd pentru a minimiza timpul i costul comunicaiilor intermaini i volumul datelor mnuite de gazd. se va bizui ct mai mult pe protocoalele de comunicaii standard, pentru a nu mai aduga software le gazd. O main baz de date ideal nu se bizuie pe serviciile gazdei. Un mediu intensiv baze de date poate fi suportat chiar i de o configuraie n care nu exist nici o dependen fa de un calculator gazd de scop general (fig.11.19). O reea de terminale, calculatoare personale sau calculatoare gazd acceseaz direct maina baz de date prin comunicaii frontend. Maina baz de date servete aici ca i server baz de date pentru reea.

Reea de comunicaii

Procesor de comunicaii

Main baz de date

Fig.11.19. Main baz de date fr dependen de gazd. Arhitectura. O arhitectur reprezentativ pentru o main baz de date este prezentat n fig.11.20. Controllerul mainii baz de date comunic cu mai multe procesoare sclav i aparate de memorare prin unul sau mai multe canale de comunicaii. Datele sunt distribuite pe aparatele de memorare, aa c ele pot fi localizate i prelucrate paralel. n general, paralelismul poate nbunti performana. De fapt, extinderea la cutarea i prelucrarea paralel este una din cele mai clare diferene ntre abordrile folosite de mainile baz de date i cele ale calculatoarelor de scop general. O main baz de date ncearc s localizeze datele mult mai eficient aducnd asociaia dintre valorile datelor i adresele aparatelor mult mai aproape de nivelul hardware. Sistemele DBMS soft mapeaz valorile pe adrese folosind tehnici cu structuri de index, ca cele prezentate n cap.10. Mainile baz de date fie folosesc tehnici bazate pe coninutul memoriei adresabile (aparate al 373

cror controllere cunt n stare s gseasc nregistrrile direct prin examinarea coninutului lor, i nu urmnd pointeri i adrese) fie i mresc viteza procesului de gestionare a indecilor codificndu-i hard i nu soft. Interfa cu gazda Procesor de limbaj Controlor

Procesor sclav 1

Procesor sclav 2

Procesor sclav 3

Procesor sclav 4

Fig.11.20. O arhitectur reprezentativ pentru o main baz de date. Tehnici de distribuire a datelor. Pentru prelucrarea n paralel datele trebuie s fie partiionate cu grij pentru accesul de la mai multe procesoare. Mainile baz de date folosesc diferite tehnici pentru partiionarea datelor ntre aparate. Pentru a simplifica discuia asupra anumitor tehnici, s presupunem c exist numai dou procesoare i numai dou relaii de baz: DEPT i ANGAJAT. Un mod de a distribui datele este de a memora liniile DEPT pe un procesor i liniile ANGAJAT pe cellalt procesor (fig.11.21.). Aceast alternativ nu ofer multe oportuniti pentru paralelism, accesele fiind fie la o relaie, fie la cealalt. O alt alternativ este de a folosi ct de multe aparate se poate pentru a memora liniile oricrei relaii, folosind mai multe fiiere pentru a memora o relaie. De exemplu, memornd jumtate din liniile lui DEPT i jumtate din liniile lui ANGAJAT pe un procesor i celelalte jumtti pe cellalt procesor, aa cum se prezint n fig.11.22. Exist acum un potenial pentru paralelism ntr-un acces la relaia DEPT sau la relaia ANGAJAT, i chiar la reuniunea celor dou relaii.

374

Procesor 1

Angajat

Dept Procesor 2

Fig.11.21. Distribuirea intregilor relaii pe procesoare.

Angajat Procesor 1

Dept

Angajat Procesor 2

Dept

Fig.11.22. Distribuirea de partiii de relaii pe procesoare. Partiionarea unei relaii ntre aparate poate fi orizontal (anumite linii accesate de un procesor, alte linii de alt procesor), vertical (anumite coloane accesate de un procesor, alte coloane de alt procesor) sau o combinaie de partiionare orizontal i vertical. Partiionarea orizontal este cea mai frecvent utilizat. Partiiile pot fi distribuite pe aparate astfel nct ncrcarea s fie echilibrat ntre procesoare. Dac un procesor devine excesiv solicitat, avnd mai multe date de accesat dect celelalte procesoare, atunci oportunitile pentru paralelism vor fi diminuate. O modalitate de a distribui liniile este de a folosi hashing pe blocuri (vezi cap.10.) pe aparatele de memorare. Fiecare aparat este tratat ca i un bloc i apoi trebuie folosit un al doilea hash pentru a determina adresa de memorare n bloc. Structura director. Directorul sistem pentru o main baz de date trebuie s conin nu numai corespondena dintre relaii i aparatele pe care sunt memorate, ci i localizarea de memorare a partiiilor acestora.

375

Directoarele mainii baz de date includ indeci pentru a facilita localizarea partiiilor i aceti indeci pot fi implementai: soft sau hard la nivelul controllerului pentru a reduce volumul datelor accesate i numrul de procesoare care servesc o cerere. hard la nivelul bus-ului de comunicaii pentru a reduce volumul datelor accesate i numrul de procesoare care servesc o cerere. Liniile unei partiii pot fi cutate secevnial, folosind un index local disponibil procesorului sau folosind o memorare adresabil dup coninut. Prelucrarea interogaiilor. Probabil partea cea mai dificil n implementarea unei maini baz de date este dezvoltarea strategiilor de control necesare pentru a coordona aciunile multor procesoare. Cu procesoare paralele, maina baz de date trebuie s fie capabil s refac o cerere care se distribuie ntre procesoare i trebuie s fie capabil s previn interferene atunci cnd mai multe cereri actualizeaz date n partiii implicnd mai multe procesoare. Aceste strategii de control sunt similare cu acelea cerute pentru gestionarea bazelor de date distribuite implementate pe reele de calculatoare. Vederea utilizator. Din punctul de vedere al utilizatorului, interaciunea cu o main baz de date nu ar trebui s fie diferit de folosirea unui DBMS pe un calculator gazd cu scop general. Limbajele i facilitile ar trebui s fie aceleai i activitatea de modelare logic a datelor este aceai. Nu exist un consens asupra necesitii mainilor baz de date. Anumii experi consider c costurile mici i performana nbuntint a hardului convenional cuplat cu nbuntirile din softul DBMS au eclipsat avantajele revendicate de ctre furnizorii de maini baz de date. Ali experi susin c performanele i costurile oferite de mainile baz de date sunt eseniale n gestionarea eficient a volumelor mereu n cretere de date pe care societatea le colecteaz. Maini baz de date comerciale. Mainile baz de date au devenit disponibile comercial mai de curnd. Rdcinile lor se gsesc n sistemele de cercetare dezvoltate la diferite universiti (Toronto, Florida, Utah, Ohio, etc.) precum i n laboratoarele marilor firme productoare. Mainile baz de date comerciale includ: DBC/1012 - Teradata Corp. IDM (Intelligent Database Machine) - Britton-Lee. iDBP Data Processor i iDIS Database Information System - Intel. DBC/1012 ofer suport baz de date backend pentru calculatoare IBM mari i include subsisteme bazate pe microprocesor interconectate de un subsistem de comunicaii inteligent. Maina baz de date poate fi expendat modular adugnd subsisteme disc i procesor. DBC/1012 a devenit disponibil n 1984. IDM ofer suport baz de date backend pentru o varietate de calculatoare medii i mari, incluznd aici VAX, PDP - 11, IBM 43xx, 30xx i 376

370. IDM poate fi de asemenea interfaat, fr o gazd de scop general, cu o reea de unul sau mai multe IBM PC. A devenit disponibil n 1981. iDBP este n intenia lui Intel un integrator de posibiliti gestiune baze de date pentru afaceri mici sau sisteme de birou. El folosete comunicaii i interfa soft ntr-un mini sau microsistem. iDIS este o main baz de date frontend care ofer o interfa ntre calculatoare sau terminale distribuite i o baz de date de pe un calculator gazd. El suport i dezvoltarea unei baze de date locale servind calculatoare personale. 11.5. Baze de date relaionale distribuite. Baza de date descris de un singur model de date logice poate fi implementat fizic pe mai multe calculatoare, conectate printr-o reea de comunicaii. Rezultatul este o baz de date distribuit. Nu toate datele rezid ntr-o baz de date fizic, dar exist un model logic care leag datele mpreun. Datele pot fi distribuite n mai multe moduri, incluznd: partiii ntregi, n care o relaie este memorat n ntregime ntr-o baz de date fizic. partiii orizontale, n care anumite linii ale unei relaii sunt memorate ntro baz de date fizic i celelalte ntr-alta. partiii verticale, n care anumite coloane ale unei relaii sunt memorate ntr-o baz de date fizic iar altele ntr-alta. partiii cu acoperiri, n care o parte sau tot coninutul unei partiii este replicat ntr-o alt partiie. 11.5.1. De ce s distribuim o baz de date? Raiunea primar pentru o baz de date distribuit este aceea c o intreprindere descentralizat trebuie s partajeze informaii ntre diferitele pri distribuite. Operaiile distribuite pot conduce la urmtoarele situaii: datele pot fi generate n mai multe pri, cernd acces local rapid i rezumate de date dincolo de local. datele pot fi generate central, carnd acces rapid la distan. Att central ct i prile trebuie s actualizeze datele. datele pot fi generate n multe pri, cernd acces rapid att la datele locale ct i la cele memorate la distan. n toate aceste situaii, distribuirea bazei de date poate conduce la o mai bun performan dect centralizarea ei ntr-o locaie. Aceasta are loc deoarece distribuirea reduce volumele de comunicaii de date, majoritatea acceselor fiind locale i reduce volumul de date memorate pe orice main dat,

377

reducnd astfel cerinele de capacitate i nbuntind responsabilitaile locale. 11.5.2. De ce s nu distribuim o baz de date? Contrar raiunilor de mai sus, bazele de date distribuite sunt destul de rare. Tehnologia de gestionare a bazelor de date nu include nc soluii comerciale satisfctoare la problemele de coordonare a aciunilor pe mai multe procesoare i cu o singur baz de date logic. Trebuie s fie posibil ca, la o singur cerere s se accead sau s se actualizeze date memorate n mai multe partiii ale bazei de date, fr ca utilizatorul s trebuieasc s specifice ce partiii sunt implicate sau unde sunt ele memorate. Pentru a mnui o actualizare distribuit, trebuie s existe coordonarea necesar pentru a preveni ca actualizrile dintr-o partiie s nu intre n conflict cu cele din alt partiie i trebuie s existe o sincronizare a operaiilor de refacere n partiii multiple. Ceea ce astzi se numete baz de date distribuit sunt n realitate baze de date descentralizate care nu au un singur i integrat model logic al resursei de date. Ele nici nu pot mnui o cerere utilizator la mai multe partiii i cer ca utilizatorul s specifice ce partiii sunt implicate. 11.5.3. Decizii de proiectare de baz. Deciziile de baz ntlnite n proiectarea unei baze de date distribuite sunt: Cum ar trebui partiionate datele ntre procesoare? Ce redundan a datelor ntre partiii este permis? Ce copie a datelor va fi accesat ca rspuns la o cerere de date? Aceste ntrebri trebuie puse indiferent de modelul de date ales. De fapt, fiecare din partiiile bazei de date pot fi reprezentate local folosind un model diferit. 11.6. Comentarii finale. Exist o variatate de abordri pentru a implementa fizic baze de date relaionale. Cele dou alternative iniiale sunt de a folosi un software relaional sau un hardware specializat pentru gestionarea bazelor de date relaionale. Aceste alternative pot fi combinate pentru a distribui relaiile pe mai multe calculatoare, ca o baz de date distribuit. Toate DBMS-urile relaionale software disponibile ofer n general acelai nivel de suport enduser. Ele difer, totui, n abordrile lor pentru a localiza datele n memorie i n gestionarea accesului la date. Abordrile introduse n text includ o relaie de baz pe fiier, mai multe relaii de baz pe fiier, mai multe relaii de baz n mai multe fiiere i mai multe fiiere pentru o relaie de baz.

378

Mainile baz de date sunt calculatoare specializate pentru a gestiona bazele de date. Astzi ele suport toate modelul relaional i deci sunt candidate pentru implementarea bazelor de date relaionale. Obiectivele lor sunt de a reduce cerinele de prelucrare pentru calculatoarele cu scop general i de a nbunti performana sistemelor de baze de date. Bazele de date distribuite memoreaz partiiile relaiilor pe mai multe calculatoare, conectate printr-o reea de comunicaii. O baz de date este distribuit fizic pentru a nbunti performanele sistemelor baz de date n medii descentralizate. Capitolul 5. a prezentat maparea modelului de date logice pe baze de date relaionale, care pot fi implementate fizic folosind oricare din tipurile de suport de gestionare a bazelor de date prezentate n acest capitol. Memento Procesor backend Procesor de comunicaii Baz de date descentralizat Atribut discriminator Baz de date distribuit Relaie de baz Main baz de date Procesor front-end Hashing Reuniune preconstruit Bibliografie 1. Astrahan, M.M. e.a. (1976) System R. Relational approach to database management, ACM Transactions on Database Systems, 1. 2. Hsiao, D. (1983) Advanced Database Machine Architecture, PrenticeHall, Englewood Cliffs, NJ. 3. Neches, P.M. (1984) Hardware support for advanced data management systems, Computer, 17. 4. *** (1974) RDMS Design Principles. RDMS Reference Guide, MIT, Cambridge, Mass. 5. Stonebraker, M. e.a. (1974) The design and implementation of INGRES, ACM Transactions on Database Systems, 1. 6. Todd, S. (1975) An efficient implementation for large relational databases, Proc. International Conf. on Very Large Databases, Framigham Mass. Arbore B+ Index Fiier Partiionare orizontal Partiionare vertical Buffer List nlnuit Pagin Pointer

379

Partea 3. Administrarea i protecia bazelor de date

Capitolul 14. Sisteme directoare/dicionare de date

Unul din instrumentele cele mai importante pentru protecia i administrarea resurselor de date este sistemul director/dicionar de date. Sistemele director/dicionar de date au o varietate de nume ca dicionar/director, dicionar i director. Noi le vom numi sisteme D/D. Acest capitol discut funciile principale ale unui sistem D/D precum i tipurile de date pe care acesta le conine. De asemenea, acest capitol introduce configuraii ale sistemului D/D i domeniul posibil de interdependene ntre un sistem D/D i un DBMS. El descrie rolurile sistemelelor D/D n medii baze de date distribuite i centralizate, n transferarea dintr-un mediu orientat pe procese ntr-unul orientat pe date, precum i n activitile de suport a tranzaciilor i a proiectrii bazelor de date. Aceste posibiliti sunt apoi comparate cu tipurile de suport oferite de ctre sistemele D/D comerciale de astzi. 14.1. Obiective. Un sistem D/D este folosit pentru a controla accesul la resursele de date, pentru a controla costurile pentru dezvoltarea i meninerea bazelor de date i a software-ului i pentru a preveni efectele adverse datorate modificrilor de hard i soft. Sistemele D/D disponibile comercial au mai mult sau mai puin succes, depinznd se configuraiile i posibilitile lor. Inima unui sistem D/D este ea nsi o baz de date, numit director/dicionar sau simplu D/D. Aceast baz de date conine metadate, menionate i n capitolul 3., ca date despre date. Domeniu. Domeniul util al metadatelor se extinde dincolo de descrierea n limbaj de programare a cmpurilor, la date care descriu utilizatorii care pot accede datele (pentru a controla accesul la date), la procesele care manipuleaz datele (pentru a controla calitatea datelor) i la mediul hardware i software (pentru a reaciona la schimbrile din mediu). Utilizatorii. Cel puin ase tipuri de utilizatori pot beneficia direct de un sistem D/D: Administratorii de date, care folosesc sistemul D/D pentru a inventaria resurse de date, pentru a implementa standarde, pentru a proiecta scheme externe (vederi utilizator) i a construi modele de date care se dezvolt n schema conceptual.

380

 Administratorii bazei de date, care folosesc sistemul D/D ca o surs de informaii pentru proiectarea, monitorizarea i potrivirea structurilor bazelor de date fizice. Analitii de sistem i programatorii, care folosesc sistemul D/D pentru a proiecta sisteme, pentru a analiza schimbrile n sisteme i pentru a reduce codul programului. Echipa de operare, care regsete informaii despre job-uri n D/D. Utilizatorii, care obin din D/D descrieri despre datele din schemele lor externe. Auditorii de date, care examineaz documentaia oferit de ctre sistemul D/D. Nu toate aceste tipuri de utilizatori beneficiaz n momentul actual de suportul D/D din toate nterprinderile. Adesea, D/D nu este disponibil n afara funciei de prelucrare date sau nu poate suporta necesitile acestei diversiti de utilizatori. Dar o parte din gestiunea datelor folosete instrumente de tipul sistem D/D pentru a-i potena funciile. 14.2. Coninut. Baza de date D/D poate conine metadate despre domeniul complet al resurselor de date dintr-o nterprindere. Structura logic a unui D/D poate fi reprezentat folosind entiti, atribute i relaii; oricare din tehnicile de modelare date discutate n cap.4. poate fi folosit. Dac sistemul D/D este puternic aliniat cu un DBMS particular, atunci structura D/D se poate reprezenta folosind modelul de date natural al DBMS-ului. De exemplu, Integrated Data Dictionary (IDD) al lui Cullinet este construit ca o schem IDMS (CODASYL) iar structura dicionarului de date a lui INGRES (de la Relational Technologies) este construit ca o tabel (relaional) INGRES. Un D/D tipic are structura logic din fig. 14.1. Entitile din acest model descriu: structurile bazei de date fizice: baze de date, subscheme, fiiere. structurile fiierelor: nregistrri, grupuri, cmpuri. activiti: tranzacii, rapoarte. utilizatori. echipament: procesoare, linii, terminale. programe. Fig.14.1. prezint un set minimal de relaii ntre aceste entiti. Anumite D/D suport relaii mai-muli-la-mai-muli ntre entiti, iar altele i rafineaz tratamentul lor pentru structurile bazei de date, pentru activiti sau programe.

381

Baza de date

Utilizator

are

Subschema acceseaz apeleaz este memorat n

Program

execut

Procesor

este punct de plecare pt.

Fiier Linie
conine

este punct de terminare

nregistrare

produce

suport conine

servete

Grup

este accesat de

Tranzacie

Raport

Terminal

conine

conine este accesat de

apare pe

Cmp

apare pe

Fig.14.1. Structura logic a unui D/D. Entitatea UTILIZATOR poate fi legat de toate celelalte entiti.

382

Fiecare entitate ntr-un D/D tipic (i cteodat i relaiile lor) poate fi descris de numeroase atribute, care caracterizeaz tipul particular al entitii. De exemplu, atributele tipice ale entitii tranzacie (frecven, volum de date ateptat, etc.) sunt diferite de atributele entitii cmp (tip de dat, mrime, nul/nenul, etc.) Multe din sistemele D/D ofer o caracteristic de extensibilitate care permite ca administratorul de date s expandeze structura D/D-ului definind entiti, atribute i relaii adiionale. Aspectele definite de utilizator ale structurii D/D permit pachetului standard s corespund necesitii utilizatorilor. De exemplu, un administrator de date ar putea aduga sistemului D/D capacitatea de a stoca i menine modele de date. Pentru a implementa abordarea cu trei scheme, discutat n primele capitole, un D/D trebuie s fie n stare a descrie toate cele trei tipuri de scheme: conceptual, interne i externe precum i de a include maparile interscheme. Modelul din fig.14.1. nu include aceste entiti; ele trebuie adugate folosind caracteristica de extensibilitate a sistemului D/D. Nu exist sisteme D/D comerciale disponibile care s suporte n totalitate toate cele trei scheme, dar exist interese remarcabile de cercetare n domeniu. Majoritatea produselor comerciale descriu numai schemele interne i cteodat schemele externe; ele nu au conceptul de schem conceptual. n mod tipic, ele numesc schemele externe subscheme i schemele interne fiiere. 14.3. Funcii principale Principalele trei funcii ale unui D/D sunt glosarul, catalogul i controlerul. Glosarul. Glosarul D/D: ncarc i actualizeaz coninutul unui D/D. raporteaz coninutul unui D/D, documentnd astfel resursa de date. Aceast raportare poate conine toate tipurile de nregistrri dintr-o mulime de baze de date, cu cmpurile lor de date, listate n ordine alfabetic. analizeaz coninutul unui D/D, documentnd efectele schimbrii ntr-o parte a sistemului, fa de celelalte pri. De exemplu, dac codul potal este modificat pe zece cifre, care programe trebuie modificate i recompilate? creaz, menine i raporteaz noile structuri D/D, atunci cnd se folosete extensibilitatea. Glosarul suport att planificarea datelor ct i dezvoltarea datelor i eficiena sa variaz n concordan cu domeniul metadatelor. Anumite DBMS-uri au glosar D/D preconstruit. Anumite sisteme D/D pot citi metadate din programe surs sau biblioteci i pot folosi aceste metadate pentru a n crca direct D/D-ul. Aceast caracteristic poate fi util atunci cnd se stabilete un D/D pentru 383

prima dat, evitnd astfel reintroducerea de metadate care deja exist ntr-o form automatizat. Caracteristica aceasta poate captura totui numai metadatele disponibile din surse. De exemplu, un program COBOL sau FORTRAN nu ofer metadate depre autoritile de regsire sau actualizare pentru elemente de date. Utilitarele care ncarc un D/D din programe surs n mod tipic nu analizeaz metadatele pe care le gsesc. De exemplu, utilitarul nu identific, n general, ce tranzacii sau programe acceseaz un element de dat sau n care raport apare un element de dat. Catalogul. Urmtoarea funcie principal a unui sistem D/D este un catalog, care genereaz: 1. instruciuni n limbajul de definire date (DDL). 2. logica standard de manipulare a datelor. Ambele tipuri de instruciuni sunt copiate direct n programe i tranzacii n momentul compilrii. Generarea de instruciuni de definire de date i de manipulare dintr-un D/D este un pas important nainte n controlul efectelor modificrilor i al costurilor noii dezvoltri n mediul de date. De exemplu, odat ce codul potal este descris n D/D ca avnd 10 cifre, toate programele i tranzaciile ale cror DDL este generat de ctre sistemul D/D vor avea aceeai ntelegere a formatului codului potal. Administratorul de date poate folosi glosarul sistemului D/D pentru a determina ce programe i tranzacii folosesc codul potal, cci acestea sunt programele i tranzaciile care trebuie recompilate. Noua descriere a codului potal va fi extras direct din D/D. Cataloagele sunt utile, n primul rnd, pentru dezvoltarea i meninerea sistemelor. Multe sisteme D/D comerciale disponibile, n special cele puternic legate de un anume DBMS au att catalog ct i glosar. Unele DBMS-uri au sisteme D/D cu cataloage preconstruite. Controlerul. A treia funcie principal a unui D/D este un controler care direcioneaz execuia actual a programelor i tranzaciilor. Controlerele: 1. direcioneaz programele i tranzaciile spre locaiile fizice de date cerute. 2. transform cererile de date din forma schemei externe n forma schemei conceptuale i apoi n forma schemei interne i invers, n cazul rspunsului. Controlerele sunt utile att pentru dezvoltarea sistemului, ct i pentru execuia programului. Este util s considerm controlerul D/D ca o extensie a DBMS-ului convenional. Anumite DBMS-uri au preconstruite sisteme D/D care ofer prima parte a unui controler, niciunul nu are preconstruit transformarea cu trei scheme. Controlerele sunt valabile, n special, ntr-o reea de calculatoare cu mai multe baze de date. ntr-un mediu baze de date distribuite, transformarea conceptual intern poate descompune o cerere n mai multe cereri, fiecare ctre o singur baz de date, i selecteaz o strategie pentru a obine i agrega

384

rspunsurile de la bazele de date int ntr-un singur rspuns, pentru a-l prezenta utilizatorului. Fr controlerul D/D, ntr-un mediu baze de date distribuite, un programator trebuie s fac personal transformrile interscheme i strategia de descompunere/agregare. Controlerul D/D este important, n special, ntr-un mediu cu reele de DBMS-uri eterogene care, de exemplu, suport modelele reea, relaional i ierarhic (procurate de la diverse suporturi soft i rulnd pe diferite tipuri de calculatoare). Controlerul permite utilizatorilor s cear date din resursa de date distribuit, fr s tie n ce baz de date se gsesc. Cererea poate fi formulat ntr-un limbaj neutru, independent de orice DBMS individual i utilizatorul nu trebuie s tie care din DBMS-uri gestioneaz data cerut. Nu exist sisteme D/D comerciale disponibile astzi care s ofere funcia complet a controlerului, dar aceasta este o arie de interes tiinific considerabil. Probabil, cea mai capabil din ofertele comerciale este cea din sistemul Tandem Corporation Encompass care opereaz pe un mediu omogen de calculatoare Tandem i servicii de gestionare baze de date. Acesta nu este ns un sistem D/D separat. Sisteme de cercetare pertinente sunt i subsistemul Common Data Model Preocessor al firmei Integrated Information Support System (IISS), dezvoltat de General Electric cu sprijinul ICAM (Integrated Computer Aided Manufacturing de la U.S. Air Force) i sistemul Multibase dezvoltat de ctre U.S. Navy. Ambele sisteme de dezvoltare opereaz n medii eterogene cu variate DBMS-uri. 14.4. Configuraii fundamentale. Sistemele D/D depind de DBMS-uri particulare pentru serviciile de gestionare date i de D/D ca surs pentru metadate. Cele trei configuraii sunt: independent. aplicaie DBMS. scufundat. Sisteme D/D independente. Un sistem D/D care are o abordare independent este autonom; el nu se bazeaz pe un DBMS particular, ci gestioneaz propria sa baz de date (D/D). El este responsabil pentru protecia sa la refaceri, controlul accesului partajat, limbaje de acces, prelucrarea interogaiilor, gestionarea spaiului, etc. Sisteme D/D independente comerciale sunt Data Catalogue 2 (de la TSI International), Datamanager (de la Management Systems and Programming, Ltd.) i Pride/Logik (de la M.Bryce & Associates). Principalul avantaj al abordrii independente este acela c sistemul D/D poate fi folosit cu o varietate de pachete DBMS (fig.14.2.). Clientul sistemului D/D nu trebuie s aib un DBMS anume. Sistemul D/D se potrivete ntr-un mediu DBMS existent i mediul poate fi extins n viitor pentru a include noi servicii DBMS. Aceast 385

abilitate este n particular important pentru controlul D/D centralizat ntr-o reea de DBMS-uri eterogene. Principalul dezavantaj al abordrii independente este acela c DBMS-urile nu trebuie s-i obin metadatele lor din D/D. Ele i menin propriile lor scheme; exist astfel redudan pentru metadate. Administratorul de date trebuie, de asemenea, s ia precauii speciale pentru a coordona coninuturile surselor de metadate.

DB1 DBMS1 Sistem D/D Schema1

D/D DBMS2

DB2

Schema2

Fig.14.2. Configuraie D/D independent. Sisteme D/D aplicaie DMBS. Un sistem D/D care este o aplicaie DBMS se bizuie pe suportul de gestionare a datelor al unui anume DBMS. Aceste sisteme pot sau nu s fie comercializate de aceai firme. D/D apare pentru DBMS ca o alt baz de date (fig.14.3.) i este accesat de ctre DBMS n acelai fel ca i celelalte baze de date. Multe din funciile sistemului D/D sunt oferite de ctre utilitarele DBMS-ului i funcii adiionale sunt, n general, oferite de ctre programele i tranzaciile sistemului D/D. Sistemul D/D depinde, evident, de un DBMS particular i, n anumite cazuri, sistemele D/D folosind aceast abordare pot descrie de asemenea, date gestionate de alte DBMS-uri. Sistemele D/D bazate pe aplicaii DBMS includ ADABAS Data Dictionary (Software AG) DB/DC Data Dictionary (IBM, dependent de IDMS DBMS), IDD (Cullinet, dependent de IDMS DBMS), IDD (Intel, dependent de System 2000/80), UCC Ten (UCC, dependent de IBM IMS). Avantajul principal al acestor sisteme este faptul c codul sistemului D/D tinde s fie relativ compact.

386

DB

Sistem D/D

DBMS

D/D

Fig.14.3. Configuraie D/D aplicaie DMBS. Un alt avantaj este c sistemul poate fi cumprat de la acelai furnizor ca i DBMS-ul, i deci pachetele au tendina de a lucra bine mpreun. Principalul dezavantaj este acel c D/D nu este singura surs de metadate pentru DBMS. De fapt, DBMS-ul menine scheme separate pentru celelalte baze de date sub control. Din nou, administratorul de date trebuie s coordoneze sursele de metadate. Sisteme D/D scufundate. Un sisteme D/D scufundat este o component integrat a DBMS-ului (fig.14.4.). DBMS-ul ofer faciliti de gestiune date iar D/D ofer metadate. Sistemul D/D nu poate fi separat de DBMS, el fiind o parte a acestuia.

DB

DBMS Sistem D/D

D/D

Fig.14.4. Configuraie D/D scufundat.

387

Un exemplu de sistem D/D scufundat este TIS Dictionary (al lui TIS Cincom). TIS nu poate fi procurat fr componenta Directory, care este esenial pentru restul operrii sistemului. Principalul avantaj al unui sistem D/D scufundat este acela c exist numai o surs de metadate, D/D-ul, care este folosit pentru a accesa bazele de date utilizator. Nu exist nici o problem de coordonare a resurselor redundante de metadate. Principalul dezavantaj al sistemelor D/D scufundate este acela c ele lucreaz cu un singur DBMS, ceea ce poate fi o problem ntr-un mediu care are deja mai multe DBMS-uri. Deoarece arhitectura sistemelor D/D scufundate pune n centru D/Dul i nu DBMS-ul, acest dezavantaj poate fi eliminat dac furnizorul de D/D ofer interfee cu alte DBMS-uri. (fig.14.5.).

Software specific aplicaiei

Software pentru dezvoltare aplicaii

Sistem de control/protecie baz de date

Baze de date

Sistem dicionar de date

Sistem dicionar de date

Sistem de comunicaii

Fig.14.5. Rolul central al unui sistem D/D. 14.5. Rolurile sistemelor D/D n medii conduse de procese i conduse de date. Sistemele D/D joac roluri diferite n cele dou tipuri de medii i rolul lor este mai important n abordarea bazat pe date.

388

Medii conduse de procese. ntr-un mediu condus de procese, D/D servete, n primul rnd, ca un glosar, cu toate c el acioneaz i ca un catalog. Orientarea este prezentat n fig.14.6. Atunci cnd un utilizator cere un acces nou pentru a incorpora date sau dorete s manipuleze date incorporate folosind un pachet de sine-stttor (de exemplu, software pentru analiz statistic, afiare grafic, etc.), se scrie un program de extracie pentru a obine date din baza de date de producie i a le pune ntr-un fiier de extracie nou creat. Fiierul de extracie este apoi formatat pentru a se potrivi necesitilor software-ului int. Formatul fiierelor de extracie uzual nu este cunoscut de ctre D/D.

Instrument software

Fiier extras

Program de extracie

Baza de date producie

Fig.14.6. Mediu condus de procese cu fiier de extracie. Medii conduse de date. Pe de alt parte, ntr-un mediu condus de date, sistemul D/D servete ca un intermediar ntre datele de producie i utilizatori. Aa cum se prezint n fig.14.7. D/D acioneaz ca un catalog pentru a oferi descrieri de date pentru programele de extracie i apoi pentru a construi baze de date extrase. Aceste baze de date nu sunt pstrate curent i tranzaciile care se efectueaz asupra bazelor de date productive, nu se manifest i asupra lor. Dac este nevoie de mai multe date, se face o nou extracie. Formatul bazelor de date extrase este cunoscut de ctre D/D. El traduce din bazele de date extrase informaiile cerute de manipularea cu diferite pachete software i prezint rezultatele utilizatorului. Sistemul acioneaz ca un buffer pentru baza de date de extracie, fr a ine cont de detaliile i caracteristicile pachetelor individuale i de cerinele interfeelor utilizator specifice. Baza de date extras este gestionat ca o resurs de date i nu ca un fiier temporar care se transmite programelor. Datele din bazele de date extrase sunt actualizate periodic din bazele de date de producie. Evident, cu ct sunt mai frecvente actualizrile, cu att extracia va fi mai curent. Aceast configuraie este similar cu cea gsit n multe medii de centre de informare. Dat o mulime corect de instrumente i de limbaje interfa utilizator, utilizatorii sunt capabili s accead datele mai mult sau mai puin dirct, evitnd procesul de dezvoltare de sisteme tradiional, i adesea, lung.

389

Interfa utilizator

D/D

Sistem D/D Instrumente

Program de extracie Baz de date de producie

Baz de date extras

Fig.14.7. Mediu condus de date, cu baze de date extrase. Medii distribuite. Pe msur ce funciile unui sistem D/D cresc, bazele de date de producie vor migra ntr-un mediu centru de informaii. Astzi, bazele de date de producie au tendina de a fi controlate compact de ctre organizaiile de prelucrare date. Pe msur ce utilizatorii devin mai familiari cu instrumentele centrului de informare i cu propriile lor necesiti de prelucrare date, bazele de date de producie vor fi mai des implementate n centrul de informaii (fig.14.8.). Mediu de producie

Interfa utilizator Sistem D/D DBMS Instrumente D/D Baz de date de producie i prototipuri Transformator

Bd de producie

Fig.14.8. Mediu condus de date, integrat cu centru de informaii.

390

Ele suport muli utilizatori i sunt controlate pentru a ne asigura c ele respect standardele de siguran i predictabilitate. Codul este dezvoltat cu revizuirea strict a cerinelor, a proiectrii i a performanei i este modificat prin proceduri de actualizare formale (release notes). Aceste baze de date ncep normal ca prototipuri, pe care grupul de prelucrare date presupune c le va abandona, astfel ca bazele de date de producie s poat fi implementate folosind metode convenionale de dezvoltare de sisteme. Pe msur ce utilitatea lor este dovedit de ctre utilizatori, prototipurile se transform n sisteme de producie. Un mediu de prelucrare date distribuit rezult, chiar dac intenia iniial a fost de a avea toate datele de producie centralizate ntr-un computer mainframe, n fiierele de extracie alimentnd facilitile centrului de informaii de la distan numai pentru a acces n interogare. Alegerea const n a oferi instrumente i controale necesare pentru a integra un mediu cu baze de date distribuite viabil. Cnd este bine construit, un centru de informaii va fi capabil ca, ntr-o singur cerere, s regseasc date att din bazele de date de producie rezidente local, ct i din extraciile memorate local, din bazele de date rezidente pe un mainframe central, fr a face distincie ntre ele. Actualizrile n bazele de date, att locale ct i centrale, de producie, pot fi gestionate ntr-o integritate complet i sistemul D/D poate oferi mult din inteligena necesar pentru a gestiona astfel de medii. Unul din obiective este de a oferi un mediu de date integrat n care: bazele de date sunt partajate de diferii utilizatori, pe baza conexiunilor logice de date, fr restriciile din organizaii i aplicaii. utilizatorii pot accesa date fr a le psa de localizarea lor sau de DBMSul care le gestioneaz. datele sunt consistente i replicate ntre bazele de date. baza de date fizic se poate modifica, pentru a-i nbunti eficiena, fr a se schimba, ns, modul n care utilizatorii acced datele. 14.6. Suportul de tranzacii i D/D-ul. Rolul D/D-ului n suportarea tranzaciilor n medii de date integrate este complex. Diferitele funcii pe care le poate realiza un D/D sunt prezentate n fig.14.9. i sunt urmtoarele:

391

Interpretarea tranzaciei Maparea VP --> SE Prezentarea rezultatelor Traduce SE --> SC SE -->VP Traduce SE --> SI Descompune

Traduce SC --> SE

D/D

Traduce SI --> SC Agreg Planific i supervizeaz execuia

Identific ci de acces la baza de date Genereaz cod executabil

Fig.14.9. Funcionalitatea D/D-ului pentru suportul de tranzacii. VP = vedere de prezentare, SE = schema extern, SC = schema conceptual, SI = schema intern. o tranzacie este primit printr-o facilitate de interfa utilizator. D/D poate oferi informaia despre cadrul utilizatorului sau referina sa, pentru a ajuta la clarificarea tranzaciei i la rezolvarea omonimelor. De exemplu, utilizatorul A poate nelege prin DATA data angajrii, pe cnd utilizatorul B, data expedierii prin pot. D/D-ul poate oferi informaii de mapare pentru a transforma tranzacia utilizatorului dintr-o vedere de prezentare (pe ecran) ntr-o form de schem extern. D/D-ul poate oferi informaii de mapare pentru a transforma forma de schem extern a tranzaciei n forma ei de schem conceptual. D/D-ul poate oferi informaii de mapare despre locaiile datelor pentru a descompune tranzacia schem conceptual n pri, fiecare din ele accesnd o singur baz de date fizic. D/D-ul poate oferi informaii de mapare pentru a transforma tranzaciile cu o singur baz de date n formele lor de scheme interne, identificnd cile de acces n bazele de date fizice corespunztoare. sistemul D/D poate genera cod executabil pentru accesul la bazele de date fizice participante. sistemul D/D poate planifica accesul la bazele de date participante, decidnd ce combinaie de acces paralel i serial va da cea mai bun performan, i apoi superviznd execuia prilor tranzaciei. D/D-ul poate oferi informaii de mapare pentru a transforma rezultatele locale din forma schemei interne n forma schemei conceptuale i apoi de

392

a integra aceste rezultate intermediare, formnd eventual, rspunsul complet al tranzaciei. Pe msur ce rezultatele sunt transformate, sistemul D/D poate aplica restriciile de verificare a integritii potrivite. D/D-ul poate oferi informaii de mapare pentru a transforma rspunsul din forma schemei conceptuale n forma sa de schem extern. D/D-ul poate oferi informaii de mapare pentru a transforma forma de schem extern a rspunsului n forma de vedere de prezentare pentru a o afia celui care a cerut-o. Doarece D/D-ul este depozitul pentru descrierea celor trei scheme ale mediului de date, software-ul care acceseaz D/D-ul, adic sistemul D/D, poate oferi servicii de suport tranzacii care mapeaz dintr-o form a unei schem n alta. Sistemul D/D devine inima mediului de gestionare date, fie el centralizat, fie distribuit. Acest nivel de suport de tranzacii pentru medii distribuite nu este oferit de ctre sistemele D/D comerciale disponibile astzi. Conceptele au fost, totui, testate n numeroase proiecte de cercetare. Chiar dac nu sunt oferite de software numit sistem D/D, ele sunt oferite de ctre DBMS-uri distribuite. Cteva din funcii sunt oferite i n DBMS-uri cu sisteme D/D scufundate. 14.7. Suportul de proiectare i D/D-ul. Multe din funciile D/D-ului pot fi aplicate prelucrrii tranzaciilor i proiectrii de sisteme. Diferitele funcii pe care un D/D le poate realiza sunt prezentate n fig. 14.10. i sunt urmtoarele:
Construire de MD Dezvoltarea tranzaciilor Integrare MD cu SC Construire de SE i mapri SE - SC

Servicii de identificare Construire de MA

D/D

ncrcare SI i mapri SC-SI

Proiectare BD

Fig.14.10. Funcionalitatea D/D-ului pentru suportul de proiectare.

393

 D/D-ul poate memora modele de date i asista modelatorul n construirea i modificarea modelelor. sistemul D/D poate integra un nou model de date cu schema conceptual existent. sistemul D/D poate ajuta administratorul de date la construirea de scheme externe i poate memora aceste scheme i maprile lor pe schema conceptual. sistemul D/D poate ajuta administratorul de date la proiectarea bazei de date fizice i poate memora schemele interne i maprile lor pe schema conceptual. sistemul D/D poate memora modele de activitate i asista modelatorul n construirea i modificarea modelelor. sistemul D/D poate ajuta utilizatorul/analistul la identificarea cerinelor de servicii de informaii i dezvoltarea tranzaciilot pentru a acoperi aceste necesiti. Sistemul D/D poate apoi prelucra tranzaciile pentru a genera cod executabil pentru implementarea cerinelor de servicii de informaii cerute. Din nou, nu toate aceste funcii de proiectare sunt disponibile la sistemele D/D comerciale de astzi. 14.8. Suportul D/D din DBMS-urile actuale. Toate DBMS-urile actuale pot descrie bazele de date pe care le gestioneaz. Partea I. a prezentei cri a menionat cteva DDL-uri oferite de ctre DBMSuri. Reamintim c majoritatea acestora descriu numai entiti, atribute i relaii, uzual n termeni de baze de date fizice, potrivii pentru descrierea schemelor interne. Instruciunile DDL sunt folosite pentru a crea fiiere schem care ofer informaii (descrieri) de compilare i de execuie ale bazelor de date fizice. Aceste fiiere schem nu ofer nici o informaie pe care nu o transmite i DDL-ul. Furnizorii de DBMS-uri au recunoscut piaa creat de creterea cererii pentru administrarea i gestionarea datelor. Muli furnizori de DBMS-uri ofer, de asemenea, i module sau pachete de sisteme D/D care sunt compatibile cu DBMS-urile lor. n anumite cazuri, aceste posibiliti D/D sunt scufundate n DBMS-uri, n majoritatea cazurilor ns sistemele D/D sunt aplicaii DBMS. 14.9. Sisteme D/D comerciale. Datamanager. Cu peste 500 de instalri, este cel mai folosit sistem D/D independent i lucreaz n medii hardware IBM. Poate defini scheme i subscheme pentru o varietate de DBMS-uri, incluznd Adabas, IDMS, IMS (DL/1), System 2000, TOTAL i poate defini cod-surs pentru a fi incorporat n COBOL, PL/I i asamblorul BAL. Comenzile pot fi activate de un utilizator de la un terminal sau prin instrucioni CALL din programe. n plus 394

fa de independena sa, o alt caracteristic a lui Datamanager este extensibilitatea sa, care depete posibilitile de glosar i catalog convenionale. A fost folosit pentru ajutor n proiectarea automat, gestionare de text, etc. Sistem D/D Adabas Data Dictionary Data Catalogue 2 Data Control System Data Control System DDS 1100 DDS Datadictionary Datamanager DB/DC Data Dictionary Dictionary/204 EDICT IDD IDD PRIDE - Logik TIS Directory UCC Ten Furnizor D/D Software AG TSI Cincom Systems Haverly Sperry Univac ICL ADR MSP IBM CCA Infodata Cullinet SAS Institute M.Bryce & Assoc. Cincom Systems UCC DBMS compatibil Adabas independent TOTAL DMS-1100 DMS-1100 IDMS Datacom/DB independent IMS Model 204 la cerere sau independent IDMS System 2000 independent TIS IMS

DB/DC Data Dictionary. Este un sistem pentru aplicaii n IMS, destinat mediilor IMS sau DL/I. El descrie cod-surs pentru a fi incorporat n programe COBOL, PL/I i BAL i memoreaz metadate despre 6 categorii: sistem, job, program, modul, tranzacie i PSB. Poate marca metadatele cu status de producie sau de testare. TIS Dictionary. Este o parte integrant a mediului DBMS TIS (Total Information System, o extensie a lui TOTAL). Facilitile de interogare i rapoarte din TIS pot fi folosite pentru a accesa metadate din TIS Directory. TIS Directory ofer metadate pentru toate componentele unui mediu TIS, incluznd programe surs n COBOL sau PL/I, subsisteme de vederi logice utilizator, faciliti de interogare, de rapoarte, ajutor de proiectare baze de date i generator de aplicaii. 14.10. Comentarii finale. Sistemele D/D au un mare potenial ca i instrumente pentru gestionarea resurselor de date. Cuvntul cheie aici este potenial, cci sistemele D/D actuale nu sunt folosite la ntreaga lor posibilitate, din dou motive: pachetele 395

nsi nu ofer toate funciile pe care le-ar putea oferi i utilizatorii nu folosesc posibilitile existente. Pentru o lung perioad, sistemele D/D au fost considerate ca neinteresante, probabil fiindc au fost echivalate cu glosare automate. Dar posibilitatea de gestionare de metadate este la fel de important ca i posibilitatea de gestionare a datelor. Aceasta pentru a obine independena, integritatea, accesibilitatea, partajabilitatea, securitatea, performana i administrarea resursei de date. Memento Catalog Controler Model de date Glosar Metadat Schem Administrator de date Administrator de baz de date Sistem D/D aplicaie DBMS Sistem D/D scufundat Bibliografie 1. Allen, F.W., Loomis, M.E.S., Mannino, M.V. (1982) The integrated dictionary/directory system, ACM Computing Surveys 14. 2. Curtice, R., Dickman, E. (1981) A survey of data dictionaries, Datamation 27. 3. Hammond, L.W. (1982) Management considerations for an information center, IBM Systems Journal 21. 4. *** (1981) Information Center Implementation Guide, Document no. Gh 09 - 0187 IBM Canada. 5. Leong-Hong, B.W., Plagman, B.K. (1982) Data Directory/Dictionary Systems: Administration, Implementatiom and Usage, John Wiley, New York. 6. Ross, R. (1981) Data Dictionaries and Data Administration, AMACOM, New York. Orientare bazat pe proces Sistem D/D independent Abordare cu trei scheme Orientare bazat pe date Dicionar/director Sistem dicionar/director Centru de informaii Baz de date de producie Subschem Tranzacie

396

Capitolul 15. Protecia datelor.

Un mediu eficient de baze de date cere mai mult dect un model de date logice valid din punct de vedere semantic i o implementare eficient de baze de date fizice: baza de date trebuie de asemenea, s fie disponibil utilizatorilor atunci cnd ei au nevoie de ea; trebuie oferit un anume nivel de partajabilitate; accesul neautorizat trebuie prevenit. Acest capitol prezint cele trei principii de baz pentru aceste servicii: refacerea, controlul concurenial (controlul accesului partajat) i securitatea. 15.1. Conceptul de tranzacie. Protecia datelor are ca obiectiv primar o nalt calitate a mediului de baze de date. Regulile de calitate pentru o baz de date pot include instruciuni ca: A este ntotdeuna egal cu B, NUMAR_DEPARTAMENT trebuie luat din mulimea { ... }, Dac COD_JOB este mai mare dect COD_RECLASIFICARE, atunci ELIGIBIL trebuie s fie mai mic dect COMPENSARE, Suma salariilor ANGAJATI_DEPARTAMENT nu poate depi BUGET_SALARII_ DEPARTAMENT, etc. Este de dorit ca toi utilizatorii (persoane fizice sau programe) s aib vederi consistente asupra bazelor de date la orice moment. Aceasta este ns imposibil, dac consistena este definit n reguli individuale, precum au fost cele de mai sus. S considerm, de exemplu, aseriunea A este ntotdeuna egal cu B. Dac un utilizator dorete s adauge 2 att lui A, ct i lui B, va exista o perioad de timp n care A va fi deja actualizat i B nc nu (sau invers). Adic, cele dou aciuni nu pot avea loc simultan, cu excepia procesoarelor multiple i sincronizate. Dac considerm starea iniial consistent (de ex.: A = B = 10), n momentul n care vom avea A = 12 i B = 10, datele vor fi inconsistente ele nesatisfcnd restricia. Consistena nu poate fi impus dup fiecare aciune individual i, n loc de aceasta, o serie de aciuni va fi verificat pentru pstrarea consistenei. Fiecare serie de aciuni de acest tip duce datele dintr-o stare consistent ntr-o stare temporar posibil inconsistent i apoi ntr-o stare consistent. O astfel de serie de aciuni se numete tranzacie, sau uneori, unitate logic de lucru. O tranzacie are urmtoarele proprieti: se conformeaz regulilor de consisten a bazei de date. Ea se lanseaz cu baza de date ntr-o stare consistent i aciunile ei se conformeaz regulilor de consisten ale sistemului. Astfel, starea consistent iniial este transformat ntr-o nou stare consistent.

397

 se execut n ntregime sau de loc. Ori toate rezultatele sale sunt nregistrate i tranzacia se spune c s-a svrit (sau s-a comis, n englez to commit) sau nici unul din efectele tranzaciei nu se pstreaz i tranzacie este abortat. odat ce tranzacia este svrit, ea nu poate fi anulat. Efectele unei tranzacii pot fi alterate numai prin execuia unei alte tranzacii. O tranzacie se ncheie cu unul din dou rezultate: svrire sau abortare. Fie s-a terminat cu succes sau nu a avut nici un efect asupra bazei de date. O tranzacie care se presupune a actualiza 25 de nregistrri nu se poate termina cu actualizarea a doar 12. O tranzacie svrit este garantat complet i are efectele memorate n baza de date. Utilizatorul trebuie s specifice marginile tranzacie. De exemplu, numai utilizatorul poate determina dac toate cele 25 de nregistrri trebuie actualizate mpreun. Dac actualizrile se pot face separat, atunci se pot specifica 25 de tranzacii separate. Majoritatea limbajelor de baze de date au comenzile BEGIN TRANSACTION i END TRANSACTION sau echivalente. Dac aceste margini nu sunt specificate, atunci ele se presupun a fi nceputul i sfritul unitii de execuie al programului. Tranzaciile sunt uniti de baz pentru refacerea i controlul concurenial al bazei de date. Refacerea asigur c nici o tranzacie nu este lsat parial efectuat. Accesul partajat controleaz faptul c tranzaciile nu interfereaz ntre ele. 15.2. Necesitatea refacerii bazei de date. Obiectivul refacerii bazei de date este de a face fa la eecuri sau la comportri nespecifice ale unui sistem. Eecurile pot avea multe cauze i efectul lor const n a introduce erori n sistem, i posibil, n a face sistemul inaccesibil. Pentru a face fa la eecuri, un DBMS trebuie s fie capabil s s detecteze i s corecteze erorile. Ideal, un DBMS ar trebui s notifice utilizatorii care au accesat date eronate n timpul dintre apariia erorii i remedierea ei. De fapt, acesta este un serviciu foarte greu de oferit. Procesul de corectare a erorilor datorate eecurilor se numete refacere (recovery) i obiectivul lui este de a restaura baza de date ntr-o stare acceptabil pentru utilizatori. Aici, statutul de acceptabil este judecat prin corectitudinea i consistena coninutului datelor. O tehnic de refacere suport refacerea din anumite tipuri de eecuri. Un sistem de gestiune a bazelor de date poate oferi o sumedenie de tehnici de refacere, fiecare adresnd un anumit tip de eec. Tipuri de eecuri. Tipurile de eecuri posibile ntr-un sistem baze de date includ urmtoarele: 1. eec de mediu: de exemplu, cdere de tensiune, terminarea sistemului de operare datorit erorilor, oprirea sistemului ca urmare a aciunii operatorului. 398

2. eec software: de exemplu, terminarea falsificat a DBMS-ului, distrugerea DBMS-ului. 3. eec program: de exemplu, terminarea datorat depirii timpului de execuie sau a limitelor de spaiu. 4. eec n logica programului: de exemplu, actualizarea incorect a bazei de date datorat erorilor de programare sau de validare a datelor. 5. eec de aparat fizic: de exemplu, defect capete de disc, fiiere necitibile pe disc. Cele mai insinuoase din aceste probleme sunt eecurile din logica programului, deoarece ele sunt dificil de detectat. De exemplu, poate dura sptmni sau luni pentru a descoperi c logica incorect de validare date a permis ca date eronate s fie introduse ntr-o baz de date. Este uor s determinm c o eroare a aprut dac sistemul s-a oprit, dac a aprut un cod de eroare sistem sau dac un disc este defect, dar este mult mai greu s gsim c date eronate au fost scrise n baza de date datorit unui eec n logica programului. Unele din simptomele datelor greite sunt: informaii inconsistente n rapoarte. ntrebri de la utilizatori. ntrebri de la auditorii sistemului. eec al altor programe sau tranzacii care acced baza de date. Legarea acestor simptome de cauza precis a datelor eronate este uzual imposibil. Cine tie de ce un debit dintr-un anume contul a fost prelucrat de dou ori? Cine tie de ce un loc preferat din avion este nregistrat greit n fiierul ageniei de vioaj? Refacerea din aceste situaii nu este realizat automat de ctre DBMS, se cere ca utilizatorii s realizeze tranzaciile corective pentru a nlocui valorile incorecte. Cea mai bun cale pentru a evita eecurile din logica programului este de a le preveni, folosind tehnici de dezvoltare de programe care ajut la asigurarea corectitudinii programelor. Alte tipuri de erori sunt mai uor de detectat i de corectat. n cazul cel mai nefavorabil, ele fac ca baza de date s fie complet necitibil sau inaccesibil. Ele pot de asemenea cauza ca refacerea datelor s fie neutilizabil i pot da seturi incomplete de modificri baze de date, cauzate de terminarea prematur a execuiei programului. Tipic, ele pot fi mnuite de tehnici de refacere mai mult sau mai puin automate. Motto: As far as we know, our computer never had an undetected error.1 Eecuri n medii distribuite. Exist multe posibiliti de eecuri pentru baze de date ntr-un mediu distribuit, din cauza complexitii crescute a serviciilor sistemului de operare distribuit i a serviciilor DBMS-ului distribuit. Cnd aceste elemente sunt sigure, potenialul de eec este aproximativ acelai ca i ntr-un mediu centralizat. De fapt, impactul de eec ntr-un mediu distribuit poate fi chiar mai mic dect ntr-un mediu centralizat.
1

din cte tim, calculatorul nostru nu a avut niciodat o eroare nedetectat (in limba englez). 399

Dac un calculator din reea se oprete, atunci, uzual, celelalte vor continua s funcioneze. O parte din baza de date poate deveni inaccesibil sau poate fi vtmat, fr ca restul datelor distribuite s fie afectate. Redundana componentelor (calculatoare, DBMS-uri, sisteme de operare, baze de date) inerent ntr-un mediu distribuit face ca sistemul s fie permisiv la eec (failsoft): eecul unei componente poate micora performana sistemului, nu l va face s se opreasc. 15.3. Tehnici de refacere. O tehnic de refacere menine date de refacere pentru a restaura baza de date. Aceste date de refacere nregistreaz coninutul i modificrile bazei de date, astfel nct tranzaciile pot, mai trziu, fi refcute (redo) sau nefcute (undo). Diferite tehnici de refacere menin diferite tipuri de date de refacere i sunt eficiente numai dac datele lor de refacere nu au fost i ele contaminate sau distruse de ctre eec. Date de refacere. Exist mai multe tipuri de date de refacere, incluzndu-le pe urmtoarele: 1. nregistrare tranzacie: o copie a tranzaciilor de actualizare a bazei de date, n secvena n care ele apar, uzual cu ora la care apar i cu notaii despre sarcina pe care o realizeaz. 2. imagine, nainte de: o copie a unei poriuni a bazei de date, nainte de prelucrarea uneia sau mai multor actualizri ale acelei poriuni. 3. imagine, dup ce: o copie a unei poriuni a bazei de date, dup prelucrarea uneia sau mai multor actualizri ale acelei poriuni. 4. copia de checkpoint (copia de salvare): o copie complet a unei baze de date pe un mediu de arhivare, de exemplu banda magnetic. 5. urma de revizie (audit trail): o nregistrare a aciunilor de actualizare ct i de regsire pentru a permite examinarea viitoare i verificarea activitii bazei de date. Nu orice DBMS menine toate aceste tipuri de date de revizie. Ce date de refacere se menin se determin de ctre tehnica de refacere pe care o folosete DBMS-ul. Fiierul n care se scriu imaginil nainte de sau imaginile dup ce se numete log file sau jurnal. nregistrrile tranzacie pot fi de asemenea nregistrate n jurnal. Tehnici de refacere UNDO i REDO. Tehnicile de refacere de baz sunt UNDO i REDO. S considerm situaia din fig.15.1. O copie de checkpoint a bazei de date a fost fcut la un moment T 1 i la momentul T2 a aprut un eec, fcnd ca tranzacia s fie prelucrat impropriu. La momentul T 3 eecul a fost depistat. O tehnic de refacere este UNDO (numit i backout sau rollback) adic de a nu face aciunile care s-

400

au prelucrat impropriu. Obiectivul este de a reface baza de date n starea dinaintea punctului de eec. nregistrrile tranzaciei

Copie Checkpoint

Bd fr erori

Bd cu erori

Timp T1 T2 Eec T3 Detectarea eecului

Fig.15.1. ntrziere ntre apariia i detectarea eecului. Aceast tehnic se bazeaz pe disponibilitatea datelor de refacere imagine nainte de. Procesul UNDO nlocuiete poriuni din baza de date cu imaginile lor nainte de, corespunztoare, n ordinea invers n care imaginile nainte de au fost scrise (fig.15.2.) S presupunem c au existat trei tranzacii legate de SALARIU nainte de T 2 i T3: 1. timpul T2 + a: SALARIU = SALARIU + 5000. 2. timpul T2 + a + b: SALARIU = SALARIU *1.05. 3. timpul T2 + a + b + c: SALARIU = SALARIU - 100. Dac valoarea lui SALARIU la momentul T2 a fost 40000, atunci imaginile nainte de au fost nregistrare astfel: 1. timpul T2 + a: SALARIU = 40000. 2. timpul T2 + a + b: SALARIU = 45000. 3. timpul T2 + a + b + c: SALARIU = 47250. La timpul T3, SALARIU = 47150 i secvena UNDO va fi: 1. SALARIU = 47250. 2. SALARIU = 45000. 3. SALARIU = 40000.

401

Rezultatul va fi refacerea SALARIU-lui la valoarea sa de la momentul T 2. S notm c imaginile nainte de dintr-un fiier log conin, tipic valori din mai multe cmpuri diferite de date din mai multe nregistrri. ntr-un mediu multitasking, imaginile nainte de pentru actualizri dintr-un task se pot ntreptrunde cu imaginile din alt task.

Bd cu erori Timp T1 T2 Eec T3 Detectarea eecului Undo Bd fr erori Date de refacere imagine nainte de

Fig.15.2. Procesul UNDO, folosind date de refacere imagine nainte de.

Copie Ceckpoint

Bd cu erori Timp

T1 nregistrrile tranzaciei

T2 Eec

T3 Detectarea eecului

Redo

Bd fr erori

Fig.15.3. Procesul REDO, cu reprelucrarea tranzaciilor.

402

Dect s se mute napoi n timp, de la baza de date curent la starea ei de mai de vreme, procesul REDO se mut nainte n timp, de la o copie checkpoint a bazei de date. Procesul REDO poate apare n una din modalitile: 1. Reprelucrarea tranzaciilor folosind copia de checkpoint a bazei de date i omind orice tranzacie care ar fi putut cauza eecul (fig.15.3.). 2. REDO se bazeaz pe disponibilitatea fie a tranzaciilor fie a imaginilor dup, plus o copie checkpoint a bazei de date. Copie Ceckpoint

Bd cu erori Timp

T1

T2 Eec

T3 Detectarea eecului

Date de refacere imagine dup

Redo Bd fr erori

Fig.15.4. Procesul REDO, folosind date de refacere imagine dup. S presupunem c tranzaciile relative la SALARIU ntre timpii T 1 i T2 au fost: 1. timpul T1 + a: SALARIU = SALARIU *1.10. 2. timpul T1 + a + b: SALARIU = SALARIU + 500. i c SALARIU = 35910 la momentul T 1. ncepnd cu momentul T1, imaginile dup ce au putut fi nregistrate astfel: 1. timpul T1 + a: SALARIU = 39500. 2. timpul T1 + a + b: SALARIU = 40000. Copia checkpoint la momentul T1 arat SALARIU = 35910 i secvena REDO va fi: 1. SALARIU = 39500. 2. SALARIU = 40000. Acestea aduc baza de date napoi n starea ei de la momentul T2. Diferena dintre REDO cu tranzacii i REDO cu imagini dup ce este aceea c prima variant cere ca tranzaciile s fie reexecutate. REDO cu

403

imagini dup ce se aplic rezultatelor acestor tranzacii, fr a le mai reexecuta. Care dintre cele dou tehnici de refacere, UNDO sau REDO este mai potrivit depinde de urmtorii factori: a) tipul de date de refacere disponibile: UNDO cere un fiier log cu imagini nainte de; REDO cu nlocuiri cere o copie checkpoint i un fiier log cu imagini dup ce; REDO cu reprelucrare cere o copie checkpoint i un fiier log cu tranzacii. b) momentul n care apare eecul: dac s-a efectuat un numr mic de tranzacii de la eec, UNDO cere mai puine prelucrri. Dac o eroare a aprut imediat dup ce s-a fcut ultima copie checkpoint i au avut loc totui multe tranzacii n acest interval, atunci REDO cere mai puine prelucrri. c) tipul de eec: anumit eecuri (de ex: eecurile de aparat fizic) pot afecta disponibilitatea datelor de refacere. Ambele tehnici de refacere date, UNDO i REDO, trebuie s respecte conceptul de tranzacie: efectele unei tranzacii nu pot fi parial refcute, indiferent dac se folosete UNDO sau REDO. Refacerea trebuie s lase efectele tranzaciei fie complet realizate, fie complet nerealizate. Un alt nume pentru tranzacie este unitate de refacere; un DBMS nu are voie s efectueze refaceri n uniti de tranzacii pariale. De exemplu, dac urmtoarele dou aciuni au fost pri ale aceleai tranzacii: 1. SALARIU = SALARIU + 500. 2. SALARIU = SALARIU * 1.15. atunci punctul n care baza de date a fost refcut nu poate fi dup una singur din operaiile de mai sus. Altfel baza de date va rmne ntr-o stare inconsistent sau va fi violat legea tranzaciei. Secvena de evenimente n aplicarea unei tehnici de refacere UNDO unui program activ i folosind un fiier log pe band magnetic (spooler) este urmtoarea: 1. Montai banda cu fiierul log. 2. Citii fiirul log nainte pn cnd ntlnii EOF. 3. Descuiai fiierele din prelucrarea programului. 4. Citii fiierul log napoi, aplicnd imaginile nainte de ale acestui program bazei de date. 5. Terminai refacerea atunci cnd ntlnii nregistrarea start-log a programului. 6. Restartai programul. Secvena de evenimente cerute pentru restaurarea unei baze de date dup o pierdere complet datorat unui eec de aparat fizic, folosind prelucrarea REDO cu imagini dup ce, este urmtoarea: 1. Copiai ultima copie checkpoint, ca punct de plecare pentru baza de date restaurat. 404

2. Citii fiierul log nainte, aplicnd imaginile dup bazei de date. 3. Restartai programul care a operat n punctul de eec, sau continuai prelucrarea, dac nici un program nu a operat. Alte tehnici de refacere. UNDO i REDO sunt cele mai folosite tehnici de refacere. Pe lnge ele mai exist ns i altele. Cnd toate tehnicile de refacere eueaz, se poate folosi un program de salvare. Acest program proiectat special scaneaz baza de date dup eec pentru a stabili daunele i a restaura a stare valid, salvnd datele care mai sunt recunoscute. El nu folosete date de refacere. O alt tehnic de refacere const n a pstra mai multe de o copie pentru fiecare fiier al bazei de date. Diferitele copii sunt identice, cu excepia procesului de actualizare. Actualizrile pot fi expediate tuturor copiilor, care vor fi consistente atunci cnd actualizrile se termin. Alternativ, o copie este activ i celelalte sunt de referin. Actualizrile se efectueaz pe copia activ i ntr-un moment ulterior, pe copiile de referin. Tehnici de refacere pentru medii distribuite. O dificultate n oferirea proteciei la eecuri pentru baze de date distribuite este coordonarea datelor de refacere i detectarea eecului ntre procesoare. Dac o tranzacie trebuie s fie nefcut (UNDO) problema este c aciunile ei au putut implica prelucrri la mai multe calculatoare, prin multe DBMS-uri, fiecare cu propriile date de refacere. Coordonarea devine, n special, dificil atunci cnd tranzaciile sunt refcute afectnd mai multe baze de date cu intervale de checkpoint diferite. O alt dificultate prezent ntr-un mediu distribuit apare n legtur cu procesoarele care sunt scoase temporar din reea alturi de poriuni ale unor baze de date. Scoaterea lor din reea se poate datora unor eecuri, unor operaii de ntreinere sau altor motive. Exist mai multe ci pentru a colecta actualizrile i a le aplica atunci cnd procesoarele reintr n reea. O problem de coordonare apare din cauza eecurilor adiionale din perioada n care procesorul a fost nedisponibil, atunci cnd actualizrile trebuie aplicate. Bazele de date distribuite pot avea o parte sau toat redundana lor memorat n reea. Dac o copie este inaccesibil din cauza unui eec, atunci poate fi folosit o alt copie. Atunci cnd apar eecuri, cererile utilizatorilor pot fi direcionate automat spre copia de salvare potrivit. O implicaie deosebit o constituie necesitatea unui dicionar de date distribuit de a lungul reelei, care furnizeaz locaiile datelor, statutul de copie primar sau secundar a datelor, starea datelor (ex: inaccesibile, accesibile noncurente, accesibile i curente). Nu toate cererile trebuie s fie servite cu cea mai curent versiune de date accesibile redundante. De exemplu, fie, balana de conturi o dat memorat redundant: o copie aflat la client i una la banc. Au copiile ntotdeuna acelai coninut? Care este copia primar? Care copie se actualizeaz de ctre client? Care copie se actualizeaz de ctre banc? Cum se determin balana dac se pierde o copie? 405

15.4. Stabilirea unei politici de refacere. Tehnicile de refacere trebuie s fie stabilite pentru medii individuale; nu exist o abordare general care poate fi folosit pentru toate situaiile. Echipa de administrare date trebuie s monitorizeze continuu politica de refacere a mediului i s o potriveasc pentru a satisface nevoile. Politica de refacere a unui mediu poate decide: I. Tehnicile de refacere care vor asigura protecia fa de oricare tip de eec. II. Datele de refacere care sunt cerute pentru a suporta aceste tehnici. III. Procedurile pe care le vor executa tehnicile de refacere. Pentru a determina cerinele politicii de refacere trebuie s se rspund la ntrebrile ca urmtoarele: 1. Ct de mult timp mort poate fi tolerat? 2. Ct de mult timp de refacere poate fi tolerat? 3. Ce tipuri de medii sunt disponibile pentru a memora datele de refacere? 4. Ce restricii sunt impuse de ctre sistemul de operare? 5. Ct de mult intervenie operator poate fi tolerat? 6. Ct de mult se consum din timpul sistemului cu refacerea? 7. Ce volum de costuri suplimentare e rezonabil s folosim? 8. Ct din procesul de refacere se face automat i ct manual? 9. Care este responsabilitatea administratorului de date n localizarea tranzaciilor eronate, i n identificarea eecurilor din logica programelor? Decizii de proiectare. Tehnicile de refacere folosite cu o baz de date particular sunt decise de ctre DBMS. Arareori, administratorii de date mresc aceste servicii cu tehnici adiionale. Tipic, DBMS-ul suport ambele tehnici REDO i UNDO, iar administratorul de date potrivete aceste tehnici pe mediul local i la cerinele locale. De exemplu, administratorul de date poate decide: Ct de des s se fac copiile de checkpoint? (sptmnal, zilnic, nainte de a executa sistemele majore, dup aceea, la nceputul fiecrui proces). Ct de des s se fac imaginile nainte de i dup ce? (nainte i dup fiecare program, nainte i dup fiecare tranzacie, nainte i dup fiecare actualizare a bazei de date). Ct este de mare poriunea din baza de date care se copiaz n imaginile nainte de i dup ce?`(o pagin ntreag, o nregistrare, un cmp). Att ntreinerea unui fiier jurnal ct i crearea copiilor de checkpoint concureaz pentru resursele sistemului cu prelucrarea tranzaciilor. Ele introduc costuri suplimentare (regie). Datele de refacere trebuie s fie scrise, gestionate i accesate. Utilizatorul resimte beneficiile acestor costuri doar indirect, prin abilitatea de refacere dup eecuri i ideal, nici nu trebuie informat despre apariia eecului.

406

15.5. Probleme i ameninri ale concurenei bazei de date. Unul din obiectivele unui mediu baze de date este de a permite utilizatorilor s accead concurent date partajabile. Accesul concurent este relativ uor de suportat de ctre un DBMS dac toate accesele sunt regsiri. Dac ns cel puin un utilizator face actualizri, atunci pot exista interferene, care dau situaii de inconsisten. Cele trei tipuri de inconsistene care pot fi evitate sunt actualizri pierdute, actualizri presupuse i citiri fantom. Actualizri pierdute. Un exemplu de actualizare pierdut este prezentat n fig.15.5. Tranzacia 1 intenioneaz s adauge 5 la valoarea lui A, iar tranzacia 2 intenioneaz s nmuleasc valoarea lui A cu 2. S presupunem c valoarea lui la A momentul T 0 este 10. Tranzacia 1 actualizeaz copia sa de lucru a lui A i memoreaz 15 n baza de date. n acelai timp, tranzacia 2 i actualizeaz copia de lucru a lui a i memoreaz 20 n baza de date. Efectul este pierderea actualizrii efectuate de tranzacia 1. Pierderea ar putea fi evitat dac tranzacia 2 nu ar citi valoarea lui A pn cnd actualizarea din tranzacia 1 nu s-a ncheiat. T0 Valoare A 10 Tranzacie1 Gsete pe A Tranzacie2 T1 10 T2 10 T3 15 T4 15 T5 Timp 20

A=A+5 Memoreaz A A=A*2 Memoreaz Gsete pe A A

Fig.15.5. Exemplu de actualizare pierdut. Actualizri presupuse. Un exemplu de actualizare presupus incorect este prezentat n fig.15.6.

407

T0 Valoare A 10 Tranzacie1 Gsete pe A

T1 10

T2 15

T3 15

T4 15

T5 30

T6 Timp 10 Undo

A=A+5 Memoreaz A Gsete pe A MeA=A*2 moreaz A

Tranzacie2

Fig.15.6. Exemplu de actualizare presupus. Folosind aceleai exemple, tranzaciile 1 i 2 se execut serial, cu aciunea tranzaciei 1 nefcut (UNDO) pentru refacerea unui eec. Efectul este presupunerea tranzaciei 1 ca fiind terminat cu succes. Problema poate fi evitat dac tranzacia 2 nu citete valoarea lui A dect dup ce s-a decis dac s se comit efectele tranzaciei 1 sau nu. Citiri fantom. O citire fantom apare n exemplul din fig.15.7. Tranzacia 4 este definit de urmtoarea secven: if POLICY exist then DEDUCTIE = 1 else DEDUCTIE = 0 iar tranzacia 5 este definit de: if POLICY nu exist then do creaz POLICY DEDUCTIE = 1 Execuia tranzaciilor las baza de date ntr-o stare inconsistent, n care POLICY exist i DEDUCTIE = 0. Presupunnd c POLICY nu exist iniial, atunci rezultatele consistente permise sunt: POLICY exist i DEDUCTIE = 1 (Tranzacia 4, apoi 5). POLICY nu exist i DEDUCTIE = 0 (Tranzacia 5, apoi 4) Problema este c exist dou stri definite pentru POLICY n timpul execuiei tranzaciei 4, chiar dac ea nu actualizeaz POLICY. Problema poate fi evitat dac tranzacia 5 nu actualizeaz POLICY pn cnd tranzacia 4 nu i termin secvena sa de aciuni dependente de nonexistena lui POLICY. Tranzacia 4 trebuie s fie n stare s ncuie nonexistena (fantoma) POLICY.

408

T0 Policy Valoarea lui deducie Tranzacie4 Tranzacie5 ~ 0

T1 ~ 0

T2 0

T3 1

T4 1 Actualizeaz deducie=0

Gsete Stare policy policy

Actualizeaz deducie=1

Fig.15.7. Exemplu de citire fantom. 15.6. Tehnici de control al concurenei. Mai multe tehnici i concepte pot mpreun, s controleze accesul concurent la date partajate. Aici se includ: 1. Execuie serializabil. 2. Administrarea ncuierilor. 3. Protocolul de ncuiere n dou faze. 4. Timpi mori (deadlock). 5. tampilarea (timestamping). 6. Tehnicile optimiste. 7. Protocolul de comitere n dou faze. Execuie serializabil. Atunci cnd tranzaciile se execut serial, toate aciunile unei tranzacii sunt realizate i de abia apoi se trece la realizarea aciunilor altei tranzacii. Astfel se elimin concurena. Aceasta se numete execuie serial. Atunci cnd se execut serial, tranzaciile nu pot interfera ntre ele, numai una fiind activ la un moment dat. Atunci cnd exist cereri de acces la baza de date concurente, ele n mod uzual nu se execut serial. DBMS-ul care deservete mai multe programe, realizeaz una sau mai multe aciuni pentru un program, apoi una sau mai multe aciuni pentru alt program, etc. pn cnd toate programele a fost deservite. Apoi se reia de la primul program. Exmplele din fig.15.5. 15.7. sunt astfel de tranzacii ntreptrunse. O execuie de tranzacii ntreptrunse se spune a fi serializabil dac ea d acelai rezultat ca i o execuie serial oarecare a acelorai tranzacii. Serializabilitatea este n general acceptat ca un criteriu formal de consisten. Dac un DBMS genereaz numai execuii serializabile, atunci el garanteaz consistena. Tranzaciile concurente serializabile asupra datelor partajate nu pot interfera.

409

Serializabilitatea nu implic faptul c exist un singur set de valori rezultat corecte. Un grup de n tranzacii are n! execuii seriale posibile, fiecare dnd un set de rezultate propriu. Deoarece serializabilitatea cere numai potrivirea rezultatelor cu o execuie serial oarecare, exist n! seturi posibile de rezultate corecte. S considerm dou tranzacii: tranzacia 1 mrete salariul tuturor angajailor cu 10%, iar tranzacia 2 calculeaz salariul mediu. Exist dou execuii seriale ale acestor dou tranzacii, fiecare dnd un rezultat diferit, dar consistent. Un rezultat inconsistent ar fi obinut dac calculul salariului mediu s-ar efectua dup ce doar salariul ar fi mrit doar la o parte a angajailor. Dac aciunile tranzaciei 1 s-au terminat nainte ca aciunile tranzaciei 2 s nceap, atunci ntregul set de aciuni poate fi o singur tranzacie. Este n general de dorit ca aciunile interdependente s fie grupate ntr-o tranzacie. Dac ordinea de execuie este semnificativ, exist dou modaliti de grupare a celor dou tranzacii ntr-una singur. Fig.15.8. este un exemplu de planificare serial, n care tranzacia 7 se execut dup ce s-a terminat tranzacia 6. Tranzacia 6 adaug 5 att lui A ct i lui B, iar tranzacia 7 i nmulete i pe A i pe B cu 2. Ambele tranzacii se conformeaz aseriunii de integritate A = B. Ca atare fiecare tranzacie are dou aciuni ce trebuiesc executate ca o singur unitate de refacere. nainte de execuia tranzaciilor A = B = 10. Dup execuia tranzaciei 6, A = B = 15, iar dup execuia tranzaciei 7, A = B = 30. Restriciile de consisten sunt nlnite nainte i dup fiecare tranzacie. T0 Valoarea lui A Valoarea lui B Tranzacie6 Tranzacie7 10 10 T1 15 10 A=A+5 T2 15 15 B=B+5 A=A*2 B=B*2 T3 30 15 T4 30 30

Fig.15.8. Exemplu de execuie serial a dou tranzacii. Fig.15.9. este o execuie serializabil a tranzaciilor 6 i 7, dar ea nu este o execuie serial, cci aciunile tranzaciilor 6 i 7 se ntreptrund. Totui, rezultatul este acelai ca i n cazul execuiei seriale. Astfel, rezultatul este consistent.

410

T0 Valoarea lui A Valoarea lui B Tranzacie6 Tranzacie7 10 10

T1 15 10 A=A+5

T2 30 10

T3 30 15 B=B+5

T4 30 30

A=A*2

B=B*2

Fig.15.9. Exemplu de execuie serializabil a dou tranzacii. Fig.15.10. prezint o execuie neserializabil a tranzaciilor 6 i 7. Ca i n exemplul din fig.15.9., aciunile tranzaciilor 6 i 7 se ntreptrund. Spre deosebire de exemplul din fig.15.9., rezultatul nu este acelai ca i n cazul execuiei seriale i nu este un rezultat consistent. A = 30 i B = 25. Aseriunea A = B a fost violat. T0 Valoarea lui A Valoarea lui B Tranzacie6 Tranzacie7 10 10 T1 15 10 A=A+5 A=A*2 B=B*2 T2 30 10 T3 30 20 T4 30 25 B=B+5

Fig.15.10. Exemplu de execuie neserializabil a dou tranzacii. ncuieri (locking). Abordarea cea mai comun pentru a garanta execuia serializabil este o tehnic numit ncuiere. n forma sa cea mai simpl, ncuierea unei pri a unei baze de date previne citirea sau scrierea ei de ctre orice alte tranzacii dect cea care a obinut ncuierea. La terminarea acestei tranzacii ncuierea este eliberat. n continuare ne vom referi la o poriune a bazei de date prin resurs de baz de date. Un DBMS poate administra ncuierile prin:

411

 setarea unui bit ntr-un cmp, nregistrare, pagin sau fiier al bazei de date, indicnd c acea resurs este ncuiat. pstrarea unei liste cu resursele bazei de date care sunt ncuiate. pstrarea resurselor ncuiate ale bazei de date ntr-o arie special de memorie. Exist ncuieri exclusive care permit numai celui care a fcut ncuierea s aib acces la resursa baz de date ncuiat i ncuieri partajate, care permit mai multor utilizatori s accead resursa baz de date ncuiat. Anumite DBMS-uri suport numai ncuieri exclusive i, n aceste sisteme, o resurs baz de date este fie ncuiat, fie liber. O tranzacie sau un program poate cere o ncuiere: 1. specificnd ncuierea n conjuncie cu o instruciune de manipulare de date, de ex: UPDATE EMP_REC WITH EXCLUSIVE LOCK SET SALAR = SALAR * 1.10. Acest tip de cerere de ncuiere este fcut adesea implicit. O cerere de actualizare poate cere implicit o ncuiere exclusiv pe datele care se vor modifica. 2. specificnd ncuierea n conjuncie cu o comand de ncepere a tranzaciei, de ex: BEGIN TRANSACTION WITH EXCLUSIVE LOCK sau BEGIN TRANSACTION WITH SHARED LOCK. 3. specificnd ncuierea n conjuncie cu deschiderea unui fiier baz de date, de ex: OPEN EMP_DATABASE FOR EXCLUSIVE UPDATE sau OPEN EMP_DATABASE FOR SHARED READ. Cererile de ncuieri a unei resurse baz de date sunt compatibile dac pot fi satisfcute mpreun (fig.15.11.). O cerere pentru o ncuiere exclusiv nu este compatibil cu nici o alt cerere pe aceai resurs. O cerere pentru o ncuiere partajat este compatibil cu o alte cereri de ncuiere partajat dar este incompatibil cu o cerere de ncuiere exclusiv. Partajat DA NU Exclusiv NU NU

Partajat Exclusiv

Fig.15.11. Matrice de compatibilitate pentru tipuri de ncuieri de baz. Exist cinci principii de control concurenial prin ncuiere, care mpreun, evit inconsistenele discutate mai nainte. Primul principiu de control concurenial este 1. Nici o tranzacie nu poate actualiza o resurs baz de date fr a dobndi nainte o ncuiere care previne ca alte tranzacii s actualizeze de asemenea resursa. O ncuiere exclusiv poate fi cerut de ctre o tranzacie care intenioneaz s citeasc sau s actualizeze o resurs baz de date. Nici o alt tranzacie nu poate s ctige accesul la acea resurs de date att timp ct ncuierea are loc.

412

ncuierile partajate pot fi cerute de mai multe tranzacii, toate intenionnd s accead o resurs specific. Pentru a preveni inconsistena, numai una din aceste tranzacii poate face actualizri, celelalte pot numai citi resursa baz de date ncuiat. 2. Dac o ncuiere nu poate fi obinut atunci cnd este cerut, tranzacia care o cere trebuie s atepte. Exist situaii n care o tranzacie cere o ncuiere pe o resurs asupra creia o alt tranzacie are deja drepturi exclusive. A doua tranzacie trebuie s atepte pn cnd ncuierea exclusiv este eliberat. A doua tranzacie se spune a fi blocat. Ea nu poate s-i nceap prelucrarea pn cnd nu obine ncuierea cerut. ncuierile partajate i exclusive administrate sub aceste dou principii previn actualizrile pierdute. Dou tranzacii nu-i pot avea aciunile ntreptrunse dac ambele actualizeaz aceai resurs baz de date. 3. Dup eliberarea unei ncuieri, o tranzacie nu poate obine o alt ncuiere. Orice tranzacie care elibereaz o ncuiere i ncearc apoi s seteze o alt ncuiere poate produce rezultate inconsistente. Situaiile din fig.15.5. i 15.10. pot rezulta ambele din cererea de ncuieri dup eliberarea altor ncuieri. Orice tranzacie care satisface principiile 1. i 3. se spune a fi n dou faze, iar principiile 1. i 3. formeaz protocolul de ncuiere n dou faze. Prima faz este faza de cretere, n care se obin ncuierile, iar faza a doua este faza de contracie, n care ncuierile sunt eliberate. 4. Schimbrile necomise trebui s rmn ncuiate pn cnd tranzacia se termin. Acest principiu asigur protecia fa de problema actualizrilor presupuse. O tranzacie nu-i poate elibera ncuierea sa de actualizare de date pn cnd aceste actualizri nu au fost comise, i odat ce au fost comise acestea nu mai pot fi nefcute (UNDO). Principiile de pn aici nu previn ns citirile fantom, cci date non-existente nu pot fi ncuiate. 5. Pentru protejarea la citirile fantom, trebuie obinute ncuieri exclusive nainte de a determina dac resursa exist. ncuierile administrate conform acestor cinci principii vor evita problemele de actualizri pierdute i presupuse, precum i citirile fantom. Deadlock. Numim deadlock o situaie n care dou (sau mai multe) tranzacii sunt blocate n ateptarea eliberrii de resurse pe care i le ocup reciproc. Nici una nu poate continua prelucrarea pn cnd nu dobndete o ncuiere inut de cealalt. Fig.15.12a. ilustreaz o situaie deadlock. Tranzacia 8 ine o ncuiere pe date SALARIU i este blocat n ateptarea eliberrii unei ncuieri pe data JOB_PERFORMANCE. n acelai timp, tranzacia 9 ine o ncuiere pe data JOB_PERFORMANCE i este blocat n ateptarea eliberrii unei ncuieri pe data SALARIU.

413

Fig.15.12b. prezint aceast situaie folosind un graf de cereri de resurse. Fiecare nod este o tranzacie i fiecare arc orientat indic c o tranzacie este blocat ateptnd dup o resurs care este ncuiat de o alt tranzacie.

Tranzacia 8 Cerere ncuiere pe Salariu

Controlorul de ncuieri

Tranzacia 9

Acordare ncuiere Acordare ncuiere

Cerere ncuiere pe Job_performanc e

Cerere ncuiere pe Job_performanc e

Wait Cerere ncuiere pe Salariu Wait

Fig.15.12a. Exemplu de secven de cereri care conduc la deadlock.

Job_performance Tranzacia 8 Salariu Tranzacia 9

Fig.15.12b. Graf de cereri de resurse prezentnd un deadlock. Deadlock-ul este detectat gsind cicluri n graful de cereri de resurse. Un DBMS menine, de obicei, o list de tranzacii cu tipuri de ncuieri pe care le in i resursele baz de date aferente, precum i o list cu tranzaciile ce sunt blocate ateptnd, de asemenea cu tipul de ncuiere solicitat i resursa aferent. Aceste liste, care reprezint grafuri de cereri de 414

resurse, pot fi analizate pentru a gsi situaiile de deadlock. ntr-un mediu baze de date cu multe tranzacii, verificarea continu a deadlock-urilor poate fi costisitoare. Pot exista i alte motive pentru care o tranzacie poate intra ntr-o stare de ateptare, de exemplu ateptnd activitate la un terminal, acces la imprimant, sau ateptnd un operator s monteze o band sau un disc. Anumite DBMS-uri caut situaiile de deadlock numai printre tranzaciile care au ateptat mai mult de un anumit timp. Odat ce un deadlock a fost detectat, DBMS-ul trebuie s-l rezolve. Tehnica cea mai comun pentru rezolvarea deadlock-ului este un UNDO pe una din tranzacii. DBMS-ul selecteaz una din tranzaciile din deadlock, aplic imaginile nainte pentru a derula napoi aciunile prelucrate, elibereaz ncuirile tranzaciei i astfel permite unei alte tranzacii s-i execute prelucrrile. Aici, UNDO este exact acelai proces ca i cel folosit pentru refacerea bazelor de date. Un al aselea principiu de control al concurenei prin ncuieri poate fi acum introdus: 6. Actualizrile se scriu ntotdeauna prima dat n fiierul jurnal i apoi n baza de date. Acest principiu face scrierea imaginilor nainte de i dup ce ntr-un fiier jurnal, parte a procesului de comitere i asigur c datele de refacere vor fi disponibile dac un eec ar apare n timpul actualizrii bazei de date. Exist mai multe modaliti de a preveni deadlock-ul, printre care: a permite unei tranzacii s ncuie numai o resurs la un moment dat. Aceasta este acceptabil numai dac o ncuiere poate asigura mari poriuni din baza de date i necesitatea de concuren este mic. a cere ca o tranzacie s foloseasc numai o operaie indivizibil pentru a ncuia toate resursele de care are nevoie; tranzacia nu poate pstra o ncuiere dac nu le-a obinut pe toate de care are nevoie. Aceasta nu este de obicei acceptabil deoarece resursele pe care o tranzacie le cere sunt determinate, n mod uzual, dinamic i nu pot fi prezise la nceputul tranzaciei. Exist i alte tehnici pentru a evita deadlock-ul n accesarea resurselor controlate de ctre sistemul de operare, dar, n mod uzual, ele nu sunt aplicabile la resursele baze de date. DBMS-ul trebuie s fie pregtit s detecteze deadlock-urile i s le rezolve pe msur ce apar. Timestamping. Metoda timestamping asigneaz fiecrei tranzacii un identificator unic, care poate fi gndit ca momentul de nceput al tranzaciei. El este referit ca timestamp. Tipic, valoarea sa este generat de ctre sistem pe baza ceasului sistemului. ntr-un mediu distribuit, numele gazdei este adugat valorii de timp, fcnd timestamp-ul unic n reea. ntr-un sistem cu timestamping, conflictele apar fie atunci cnd o tranzacie cere s citeasc o nregistrare care a fost actualizat de ctre o tranzacie mai tnr, fie cnd o tranzacie cere s actualizeze o nregistrare care a fost deja citit de o tranzacie mai tnr. 415

Conflictele se rezolv restartnd tranzacia solicitant. Tranzaciei mai tinere i se permite s continue iar tranzacia solicitant va primi un nou timestamp atunci cnd este restartat. Nu exist ncuieri i, deci nu poate apare deadlock. Pentru a preveni ca o tranzacie s aib actualizri necomise, nici o actualizare fizic nu poate fi scris n timpul comiterii. Restartarea tranzaciei nu cere niciodat rollback (UNDO) deoarece actualizrile nu au fost scrise fizic. Tehnica timestamp de baz const n a compara valoarea timestamp a tranzaciei solicitante (apelante) fa de valorile timestamp ale ultimelor tranzacii care au accesat nregistrarea cerut. fie LAST_READ, timestamp-ul ultimei tranzacii care a citit cu succes nregistrarea. fie LAST_COMMIT, timestamp-ul ultimei tranzacii care a actualizat cu succes nregistrarea. fie MY_START_TIME, timestamp-ul tranzaciei solicitante. Dac tranzacia solicitant cere s citeasc, atunci timestamp-ul ei va fi comparat cu LAST_COMMIT. if LAST_COMMIT < MY_START_TIME atunci tranzaciei solicitante i se permite s continue LAST_READ = MY_START_TIME else tranzacia solicitant este restartat. Dac tranzacia solicitant cere s comit, atunci timestamp-ul ei va fi comparat cu celelalte dou: if LAST_COMMIT < MY_START_TIME and LAST_READ < MY_START_TIME atunci tranzaciei solicitante i se permite s continue LAST_COMMIT = MY_START_TIME else tranzacia solicitant este restartat. Nici unei tranzacii apelante nu i se permite s interfereze cu o tranzacie mai veche care deja a citit sau a actualizat nregistrarea. Au fost propuse multe variaii ale tehnicii de baz de timestamping. Timestamping-ul, la fel ca i ncuierile, sincronizeaz execuia ntreptruns a unui set de tranzacii. Reamintim c ncuierile sincronizeaz tranzaciile astfel nct execuia lor s fie echivalent cu o execuie serial oarecare. Pe de alt parte, timetsamping-ul sincronizeaz tranzaciile astfel nct execuia lor s fie echivalent cu o execuie serial specific. Aceasta este ordinea serial cronologic a timestamp-urilor tranzaciilor. Tehnici optimiste. Tehnicile de control concurenial optimiste pornesc de la premisa c n bazele de date cu multe nregistrri conflictele ntre tranzacii sunt rare. Aceste tehnici elimin ncuierile i urmeaz presupunerea optimist c majoritatea ncuierilor setate n sistemele convenionale nu sunt necesare. Abordarea da baz const n a nu restriciona tranzaciile de citire ns a restriciona sever tranzaciile de actualizare. Fiecare tranzacie are dou sau trei faze: 416

1. Faza de citire de la nceputul tranzaciei pn chiar naintea comiterii sau a terminrii. Dac exist actualizri, acestea se vor face pe copii locale ale datelor. 2. Faza de validare, pentru tranzaciile de citire, sistemul va determina cnd este corect i actual rezultatul citirii. Pentru tranzaciile de actualizare, sistemul verific dac schimbrile fcute nu vor cauza o pierdere a integritii. 3. Faza de scriere: actualizrile locale se fac globale i sunt comise. Fiecarei tranzacii i se asigneaz un numr atunci cnd este terminat faza de citire. Pentru ca tranzacia apelant s treac testul de validare, trebuie s fie ndeplinit una din condiiile urmtoare: 1. Toate celelalte tranzacii trebuie s-i terminat fazele lor de scriere nainte ca tranzacia n cauz s-i fi nceput faza de citire. 2. Tranzaciile mai vechi trebuie s nu scrie aceleai date pe care tranzacia n cauz le citete i tranzaciile mai vechi trebuie s termine faza de scriere nainte ca tranzacia n cauz s nceap faza de scriere. 3. Tranzaciile mai vechi trebuie s nu scrie aceleai date pe care tranzacia n cauz le citete sau le scrie i tranzaciile mai vechi trebuie s termine faza de citire nainte ca tranzacia n cauz s nceap faza de citire. Tranzacii fac prelucrrile pe copii locale de date. Atunci cnd sunt gata de comitere, sistemul aplic testele de validitate i determin unde a fost un conflict care poate introduce date eronate. Sperana este c astfel de conflicte apar rar. Dac validarea eueaz, atunci tranzacia n cauz este salvat i restartat ca o nou tranzacie. Aceast abordare evit regia de administrare a ncuierilor i un deadlock nu poate s apar. Costul este acela al salvrii, atunci cnd apare un conflict. Tehnici pentru medii distribuite. Controlul concureial ntr-un mediu baze de date distribuit este semnificativ mai dificil dect ntr-un mediu baze de date centralizat. Principala problem este comunicarea informaiei de control, peste marginile bazei de date. ntr-un mediu distribuit de baze de date, o tranzacie poate include aciuni care sunt executate de mai multe procesoare, fiecare asupra unei poriuni a bazei de date. Dac se folosete ncuierea ca i tehnic de sincronizare, atunci o tranzacie poate ine ncuieri pe multe procesoare. Detectarea deadlock-ului nseamn atunci detectarea ciclurilor de proces-blocat de-a lungul reelei de calculatoare. O abordare const n a avea un manager de ncuieri global (lock manager), care contabilizeaz procesele care sunt ncuiate pe diferite maini. O alt problem ntr-un mediu distribuit este coordonarea comiterii tranzaciilor. O abordare este protocolul de comitere n dou faze. nainte de a comite actualizrile tranzaciei, fiecare subtranzacie (care este prelucrat pe o singur main sub controlul DBMS-ului) trebuie s indice c este gata s comit. Pentru a fi gata de a comite, toate aciunile sale trebuie s se fi terminat cu succes. Dac toate subtranzaciile indic faptul c sunt gata s se comit, atunci ele primesc ordinul s se comit. Dac oricare subtranzacie 417

indic faptul c pentru un motiv oarecare nu se poate comite, atunci toate subtranzaciile sunt abortate. Nici una din schimbri nu este comis. Fig.15.13. ilustreaz protocolul de comitere n dou faze. nainte de comitere, fiecare subtranzacie i scrie schimbrile n jurnalul su local. DBMS-ul distribuit cicleaz pentru gata de comitere i emite instruciuni pentru a ndeplini sau nu comiterea. Protocolul de comitere n dou faze are, aadar, o faz n care subtranzaciile devin gata de comitere. Odat ce fiecare dintre ele a spus c este gata de comitere, ele nu mai pot autoaborta. Ele trebuie s fie pregtite pentru comitere atunci cnd se d instruciunea de a o face. A doua faz este perioada pentru comitere efectiv sau de abortare. n timpul fazei de comitere se pot folosi numai zonele de memorare sigur i trebuie s fie posibil nregistrarea actualizrilor, indiferent de eecurile ce apar pe plan local n timpul procesului de comitere. S notm c protocolul de comitere n dou faze nu este acelai lucru cu protocolul de ncuiere n dou faze. ncuierea n dou faze se refer la regula c o tranzacie nu poate obine noi ncuieri dup ce le-a eliberat pe cele vechi; fiecare tranzacie are o faz cresctoare (achiziia de ncuieri) i o faz de contracie (eliberarea de ncuieri). Pe de alt parte, protocolul de comitere n dou faze guverneaz coordonarea procesoarelor implicate ntr-o tranzacie ntr-un mediu baze de date distribuit. O alt abordare pentru a mnui accesul concurenial ntr-un mediu distribuit de baze de date este de a segrega perioadele de acces numai pentru regsire de cele pentru actualizare. De exemplu, tranzaciile distribuite de regsire pot fi servite toate ziua fr a interfera ntre ele. Tranzaciile de actualizare pot fi prelucrate n mod batch noaptea. Aceast abordare nu este potrivit pentru toate mediile dar poate fi folosit n multe cazuri. Anumite bnci folosesc aceast abordare de muli ani chiar i cu baze de date centralizate. Exist, de asemenea, i alte metode pentru a reduce costurile suplimentare de gestionare a ncuierilor n sisteme distribuite de baze de date. De exemplu, metodele optimiste de control concurenial care se bazeaz pe apariia rar a conflictelor. Nu exist ncuieri n acest caz. O alt tehnic, numit analiza grafului de conflicte folosete ncuieri, dar numai cnd o analiz a tranzaciilor arat c ar putea fi interferene. Oferirea controlului de acces partajat este una dintre cele mai dificile probleme ale implementrii sistemelor distribuite de baze de date i ea este n special dificil n DBMS-urile distribuite care construiesc un coordonator global pe faciliti de gestionare baze de date locale existente. De exemplu, un DBMS local trebuie s poat indica gata de a comite o actualizare, unei tranzacii, dar comiterea actualizrii nu este permis pn cnd coordonatorul global nu d instruciunea de comitere.

418

Faza 1

Faza 2

T1
Comit done Yes or no

T2 T3

T1
go done Ready to commit?

T1
Yes or no

Yes

DBMS

T2

DBMS

T2

DBMS

All yes No Abort

T1 T2 T3

done

T3

T3

Yes or no

Fig.15.13. Protocolul de comitere n dou faze.

419

15.7. Stabilirea unei politici de partajare. Proiectanii unui sistem baze de date trebuie s pun n balan problema concurenei cu cea a consistenei. La o extrem se gsete starea de concuren total: oricine poate accesa orice parte a resursei de date la orice moment, att pentru a citi ct i pentru a modifica date. n majoritatea mediilor, din cauza inconsistenelor datele ar deveni n scurt timp de nefolosit. La cealalt extrem se gsete consistena total fr concuren: numai o tranzacie poate accesa baza de date la un moment dat. Aceast forare la execuie serial poate deveni dezastruoas n operaii de producie. Alte posibiliti includ: 1. Acces numai n citire cu o mare concuren n timpul zilei i actualizri realizate serial noaptea. 2. Partiionarea datelor astfel nct o tranzacie s poat accesa o partiie la orice moment dat. Balansarea concurenei cu consistena nseamn stabilirea unei politici de partajare care ofer o concuren suficient la un nivel acceptabil de costuri suplimentare. Politica de control a accesului partajat a unui mediu poate stabili tehnica de sincronizare a proceselor, astfel nct ele s nu interfereze, precum i procedurile de monitorizare a controlului accesului partajat. Trebuie s se ia decizii legate de problemele care urmeaz, pentru a determina cerinele politicii de control al accesului partajat: 1. Ce nivel de consisten este cerut? 2. Ce costuri suplimentare sunt necesare? 3. Care sunt cerinele de acces partajat pentru interogri ale bazei de date? 4. Care sunt cerinele de acces partajat pentru actualizri ale bazei de date? 5. Ct de predictibile sunt cerinele de date ale tranzaciilor? 6. Ct dureaz o tranzacie? 7. Ce tipuri de control al accesului partajat sunt oferite n medii de ctre DBMS? Ce tipuri de ncuieri sunt suportate? Ct de mult din resursa de date poate fi ncuiat ntr-o singur cerere? 8. Trebuie s fie suportat accesul partajat pentru bazele de date distribuite? Decizii de proiectare. Tehnicile de control al accesului partajat folosite cu un DBMS particular sunt decise n primul rnd de ctre DBMS. Rareori poate un administrator de date s mreasc aceste servicii prin tehnici adiionale i deci nivelul suportului de acces partajat trebuie investigat atunci cnd se alege un DBMS. Majoritatea DBMS-urilor suport att ncuieri partajate ct i ncuieri exclusive. Administratorul de date poate potrivi, de obicei, tehnicile de control al accesului partajat n urmtoarele domenii: 1. granularitatea ncuierii: ct de mult din resursa de date poate fi ncuiat ntr-o cerere?`(un fiier, o pagin, o nregistrare, un cmp)

420

2. tipuri de ncuieri: ce tipuri de ncuieri pot fi cerute? (partajate, partajate cu intenie de citire, partajate cu intenie de actualizare, exclusive cu intenie de citire, exclusive cu intenie de actualizare, altele) 3. granularitatea tranzaciei: poate o tranzacie s conin mai multe aciuni? Poate un program s conin mai multe tranzacii? Poate o tranzacie s implice mai multe programe? ncuierea fin, adic ncuierea obiectelor mici din baza de date (nregistrri sau cmpuri) permite mai mult concuren dect ncuierea grosier. Dar ea mrete, de asemenea, costurile suplimentare pentru tranzaciile care au nevoia de a accesa un lot de date i pune multe ncuieri. ncuierea grosier ofer un acces controlat, relativ ieftin la mari colecii de date. Controlul accesului partajat devine mai important pe msur ce tot mai muli utilizatori depind de serviciile bazei de date. Administratorul de date trebuie atunci s fie sigur de folosirea facilitilor potrivite de control pentru a oferi un nivel suficient de acces partajat. De asemenea el trebuie s fie garanteze protejarea calitii datelor la un cost acceptabil de regie. 15.8. Securitatea datelor. Obiectul securitii bazei de date este de a preveni modificarea i dezvluirea neautorizat a coninutului bazei de date. Securitatea se gsete pe primele locuri ntre problemele legate de calculatoare i practic oricine se lovete de ea. Chiar i aa, DBMS-urile actuale ofer numai cteva controale nesemnificative de securitate, i acelea dependente de sistemul de operare gazd. Un sistem de securitate a bazei de date trebuie s fie capabil s determine cine cere acces, ce date sunt cerute, ce tip de acces este cerut i dac cel care cere este autorizat pentru tipul respectiv de acces la datele cerute. Intenia este de a ne asigura c numai utilizatorii autorizai a accede tipuri particulare de date sunt capabili a accede acele date. Dac un utilizator nu este autorizat a actualiza tipuri particulare de date, atunci nu trebuie s existe nici o posibilitate ca utilizatorul s modifice aceste date. DBMS-urile suport de obicei cel puin accesul totul sau nimic pe poriuni ale bazei de date. n aceste cazuri, dac un utilizator poate accede o poriune a bazei de date, atunci att tranzaciile de citire, ct i cele de actualizare pentru acel utilizator vor fi acceptate. Nu se face distincie ntre diferitele tipuri de acces. Alte DBMS-uri fac distincia ntre accesul numai n citire i cel de actualizare, iar altele disting chiar i diferitele tipuri de acces de citire. n aceste cazuri, anumii utilizatori sunt autorizai a accede datele de pe linii, iar alii numai zonele de totaluri i datele de rezumat. De exemplu, un utilizator nu ar putea citi alte nregistrri individuale din baza de date guvernamental de impozite, le-ar putea ns citi pe ale lui. Oricine ar avea ns acces la rezumatul statistic: taxe medii, media scalaritii, media persoanelor per locuin, etc. 421

Probleme i ameninri de securitate. Ameninrile la securitatea bazei de date includ: 1. amenini accidentale: atunci cnd, n mod neintenionat, un utilizator obine un acces neautorizat, datorit unei erori sistem sau utilizator. 2. ameninri deliberate: atunci cnd un utilizator obine intenionat un acces neautorizat. Ameninrile accidentale la securitate sunt comune. De exemplu, un utilizator se conecteaz la un terminal la care un utilizator precedent nu a nchis sesiunea de lucru cu logout. Utilizatorul precedent poate avea alte drepturi dect utilizatorul nou. Exist mai multe tipuri de ameninri de securitate deliberate, incluznd urmtoarele: 1. Securitate fizic: mediile fizice de memorare pot fi furate. terminalele pot fi localizate n medii nesigure, unde sunt accesibile persoanelor neautorizate. Aceste persoane pot ctiga acces neautorizat pur i simplu examinnd ecranele sau listingurile de la terminal. un utilizator poate obine acces neautorizat ntr-o camer cu calculatoare i poate sri peste mecanismul de securitate al sistemului de operare sau al DBMS_ului. 2. Comunicaii: un utilizator poate s se conecteze direct, fizic, de linii de comunicaii. 3. Proceduri externe: mediile fizice de memorare pot fi copiate fr a folosi serviciile unui DBMS. Dac securitatea bazei de date este n singura responsabilitate a DBMS-ului, atunci copierea poate fi neautorizat. un programator de aplicaii poate scrie software care se comport diferit de specificaiile sale i codul rezultat poate s nu se conformeze politicii de securitate. un utilizator se poate masca ntr-unul mai privilegiat, folosind la login o parol privilegiat. un programator de sistem poate scrie cod care invalideaz mecanismele de securitate ale sistemului de operare sau ale DBMS-ului, permind accesul la date altfel inaccesibile. un administrator de date poate specifica incorect politica de securitate, dnd autorizaii improprii unor utilizatori. un utilizator autorizat poate vinde sau da date unui utilizator neautorizat. un utilizator poate infera date pe care el este neautorizat a le accede din datele pe care este autorizat a le accede.

422

Dintre aceste ameninri, cele mai dificil de controlat sunt procedurile externe. Compararea responsabilitilor. Att DBMS-urile ct i sistemele de operare sunt responsabile pentru protecia resurselor fa de referirea sau modificarea neautorizat, fa de autentificarea cererilor i pentru a oferi o tehnic de protecie simpl, sigur i eficient. Exist totui, diferene care fac mecanismul de protecie al sistemului de operare mai puin potrivit pentru securitatea bazei de date: sistemele de operare protejeaz resursele fizice, de exemplu: fiiere, pagini, discuri, etc. DBMS-urile trebuie s protejeze resursele logice, de exemplu: relaii, atribute, nrtegistrri i segmente. sistemele de operare protejeaz o resurs n totalitatea sa. DBMS-urile trebuie s fie capabile s protejeze pri din resurse, de exemplu: cmpuri, nregistrri i subscheme din aceai baz de date. sistemele de operare disting ntre acces n citire i acces n scriere. DBMS-urile trebuie s disting i ntre tipuri adiionale de acces: dependente de coninut i dependente de istorie. Controlul accesului dependent de coninut cere regsirea valorilor datelor din baza de date pentru a putea determina cnd este utilizatorul autorizat a accede acele valori. De exemplu, managerii pot fi autorizai s regseasc salariile unei pri a angajailor, acelora subordonai lor i nu a tuturor salariailor firmei. Atfel, pentru a determina cnd un utilizator particular este capabil s regseasc salariul lui Ion Popescu, DBMS-ul trebuie la nceput s regseasc nregistrarea lui Ion Popescu i apoi s determine dac Ion Popescu este un subaltern al apelantului. Controlul accesului dependent de context protejeaz fa de combinaiile de accese la valorile de date individuale. De exemplu, s considerm o baz de date care este gndit a fi sigur c nici un vnztor nu poate determina comisionul pltit altcuiva. Cineva, totui, poate determina totalul comisioanelor pltite pentru contractele unui departament, ce contracte sunt ale fiecrui departament, tipul fiecrui contract i totalul comisioanelor pltite pentru fiecare tip de contract. S presupunem c vnztorul tie: Contractele A, B i C aparin departamentului XYZ. Contractele A, B i D sunt contracte pe termen scurt. Comisionul contractului D este 10000, D fiind un contract pentru care se pltese comision. El poate atunci infera comisionul pltit contractului C, utiliznd interogrile: Ce valoare de comisioane s-au pltit pentru contractele departamentului XYZ? Rspuns: 65000. Ce valoare de comisioane s-au pltit pentru contractele pe termen scurt? Rspuns: 50000

423

Rezolvnd ecuaiile: A + B + C = 65000; A + B + 10000 = 50000; rezult C = 25000, ceea ce este o informaie la care vnztorul nu avea acces. Protecia fa de aceste accese se realizeaz prin limitarea numrului de cereri pe care un user neautorizat le poate pune bazei de date. Controlul accesului dependent de istorie previne ca un utilizator s fac o serie de cereri care mpreun s ofere date pe care utilizatorul este nu este autorizat s le obin. De exemplu, un individ poate fi autorizat s regseasc bugetul departamentului i bugetul pentru proiectele de cercetare dezvoltare, dar nimeni s nu fie autorizat s regseasc aceste bugete pentru toate departamentele. 15.9. Tehnici de control al securitii. Izolare fizic. Abordarea izolare fizic mut datele sensibile pe faciliti sigure, care au proceduri de intrare/ieire puternic controlate, nu suport accesul prin modem i care sunt monitorizate cu grij. Dac exist linii de comunicaii spre facilitate, ele sunt bine protejate i se execut pe terminale care sunt, de asemenea, din facilitatea sigur. ntr-un mediu distribuit de baze de date, se pot stoca date n faciliti cu diferite nivele de securitate. Atunci cnd aceasta are loc, variatele nivele de protecie trebuie s fie verificate atunci cnd se valideaz cererile. Sisteme cifrate. Sistemele cifrate adreseaz problema infiltrrilor de securitate prin liniile de comunicaii i pot fi folosite, de asemenea, pentru protecia la accese neautorizate la fiierele disc sau band. Un sistem cifrat codific datele pentru a le ascunde semnificaia real, adic pentru a le face neinteligibile cererilor neautorizate. Un sistem cifrat folosete un algoritm i o cheie criptografic. Algoritmul include o procedur de incriptare i una de decriptare. Procedura de incriptare ia datele reale i cheia criptografic i produce datele criptate. Datele codificate pot fi decodificate mai trziu cu procedura de decriptare utiliznd aceai cheie criptografic. Algoritmul unui sistem cifrat este, uzual, cunoscut public, cheia criptografic fiind pstrat secret. Pentru ca un sistem cifrat s fie eficient, nu trebuie s existe un mod simplu de a gsi cheia. Un sistem cifrat foarte simplu folosete urmtoare procedur de incriptare: 1. inversai ordinea cifrelor din datele reale. 2. inserai o cifr fals ntre perechi de cifre reale. 3. pentru fiecare cifr substituii litera ordinal corespunztoare din cheie. S presupunem c cheia este wryip<adgj. Valoarea 12323487 va fi incriptat astfel: 1. 78432321 2. 786432230217 3. dgapiyyiwyrd Dac cheia de criptare ar fi fost mcczljgdap, valoarea incriptat rezultat ar fi fost: daglzcczmcbd. 424

Cuvinte de trecere (parole). Parolele sunt folositoare pentru a autentifica utilizatorii i pentru a identifica un utilizator printr-o informaie ce doar el o tie. Sistemele de operare folosesc parole pentru a determina dac cineva este autorizat s se conecteze la sistem. Atunci cnd un utilizator se autoidentific, el ofer i parola sa. Sistemul verific parola oferit cu cea nregistrat n sistem, pentru a permite accesul. n mod clar, protecia cu parole este att de bun ct de bine se pstreaz secretul parolelor. ntr-un mediu baze de date, parolele se pot ataa fiierelor, dar nu nregistrrilor sau cmpurilor i pot exista parole diferite pentru acces n citire sau n scriere. Se poate ca un utilizator s dea la nceput o parol pentru a accede sistemul de operare i apoi parole adiionale pentru a accede resurse de date. Protecia cu parole este aproape ntotdeuna oferit de ctre sistemul de operare i nu de ctre DBMS. Atunci cnd un utilizator folosete o comand baz de date pentru a deschide un fiier baz de date, DBMS-ul prelucreaz cererea pasnd-o mpreun cu parola utilizatorului, sistemului de operare. Modificarea interogaiei. Modificarea interogaiei schimb cererile utilizatorului pentru a include reguli de protecie. Atunci cnd este primit o cerere utilizator, se verific prezena regulilor de protecie; se regsesc orice date necesare validrii condiiei specificate n regula de protecie; apoi cererea utilizatorului este prelucrat. De exemplu, dac regula de protecie este acea c un manager poate regsi numai salariile angajailor subordonai lui, atunci o cerere SELECT SALARY FROM ANGAJAT WHERE DEPT# = 10 va fi modificat n SELECT SALARY FROM ANGAJAT WHERE DEPT# = 10 AND MANAGER = nume_utilizator Restricia de protecie este adugat automat de ctre DBMS: Vederi. Vederile sunt partiii logice ale unei baze de date, ele se mai numesc subscheme. Uzual, o cerere la o baz de date acceseaz o vedere. Vederile sunt definite pentru diferii utilizatori n concordan cu nevoile lor de date i ele pot fi folosite pentru a controla accesul la date. Depinznd de facilitile DBMS-ului de a defini vederi, controlul poate fi mai mult sau mai puin precis. De exemplu, n sistemele relaionale, vederile se definesc uzual folosind limbajul de interogare. n aceste cazuri, granularitatea vederii poate fi att de fin sau de grosier ct se dorete. O vedere poate corespunde unei relaii de baz, poate combina relaii de baz, poate elimina anumite coloane dintr-o relaie de baz i poate elimina linii dintr-o relaie de baz, bazndu-se pe coninutul lor. 425

Pe de alt parte, n alte DBMS-uri, o vedere este implementat ca un fiier separat. n aceste cazuri, definirea vederilor foarte fine implic implementarea bazei de date cu mai multe fiiere mici. Definirea vederilor grosiere, pe de alt parte, implic faptul c baza de date va fi implementat cu mai puine fiiere i c protecia de securitate va fi grosier. Securitatea pe medii distribuite. Protecia de securitate devine ceva mai complicat ntr-un mediu distribuit de baze de date. Fie c toate procesoarele ar putea implementa acelai nivel de controale de securitate, fie c mai multe zone de control se implementeaz atunci cnd se valideaz cererile. Pot exista costuri ascunse atunci cnd se ofer protecie de securitate ntr-un mediu distribuit de baze de date. De exemplu, forarea controalelor de acces dependente de coninut poate nsemna accesarea datelor memorate pe diferite procesoare. De exemplu, s presupunem c data salariu este considerat a fi sensibil i este memorat n locaia sigur A. Datele despre cine o gestioneaz sunt memorate n locaia B. Pentru a prelucra cererea din exemplul de interogare de modificare, trebuie accesate ambele locaii, A i B. Datorit capacitii de a separa poriuni fizice dintr-o baz de date ntr-un mediu distribuit, securitatea este mai uor de oferit dect ntr-un mediu centralizat. La diferite nivele pot fi implementate diferite controale fizice, pot fi folosite diferite chei criptografice n algoritmi de incriptare la diferite nivele. Controalele de securitate pot fi potrivite cu cerinele de protecie pentru tipuri particulare de date. 15.10. Stabilirea unei politici de securitate. Tehnicile de securitate a bazelor de date ncearc s combat problemele cauzate de persoane fizice, iar tehnicile de control al accesului partajat i de refacere a bazelor de date ncearc s combat problemele cauzate de hard i soft. Stabilirea unei politici de securitate eficiente este, astfel, important n orice mediu interesat de evitarea scurgerii datelor spre persoane neautorizate. Majoritatea DBMS-urilor ofer o mic protecie de securitate n plus fa de cea oferit de ctre sistemul de operare gazd. Protecia de securitate se gsete cel mai adesea n politicile de securitate stabilite n afara softwareului. Politica de securitate poate decide: 1. Dac securitatea va fi controlat central de ctre un administrator de date sau dac va fi controlat de diferii administratori? 2. Procedurile pentru schimbarea controalelor de securitate i adugarea de noi utilizatori i resurse de date la sistem. 3. Cerinele minimale pentru capacitile de protecie a securitii ale DBMS-ului care se vor folosi n mediu. 4. Procedurile pentru forarea controalelor de securitate. 426

5. Responsabilii pentru fiecare tip de dat din sistem. 6. Tipurile de acces distincte n oferirea controlului de securitate. Pentru a stabili cerinele pentru politica de control a securitii, trebuie s se rspund unor ntrebri ca urmtoarele: 1. Ct de sensibile sunt datele? 2. Ct de dificil este pentru un utilizator a sparge protecia de securitate? 3. Ce nivel de control de securitate este cerut? 4. Ce costuri suplimentare este rezonabil a include pentru a oferi securitatea? 5. Ct de sigure fizic sunt facilitile de calculator i de terminal? 6. Exist cerine legate de securitate? 7. Exist cerine de securitate al contractantului? Decizii de proiectare. Un semn de pericol ntr-un mediu cu date presupuse sensibile este lipsa unei politici de securitate. Securitatea este o arie n care este cerut aciunea administratorului de date, cci DBMS-ul i sistemul de operare nu ofer prin ele nsele o protecie adecvat. DBMS-ul tipic folosete parole pentru a controla accesul la poriuni ale bazei de date. Un anumit control se bazeaz pe tipul de acces i datele ce se acceseaz. Consideraiile de securitate pot afecta marginile fiierelor, partiionarea bazei de date de-a lungul procesoarelor, ntr-un mediu distribuit, precum i folosirea incriptrii. Dac un DBMS se bazeaz n totalitate pe sistemul de operare pentru protecia de securitate, consideraiile de securitate se iau n considerare cnd se proiecteaz marginile fiierelor n sistemul baze de date. Dac procesoarele reelei ofer nivele diferite de protecie de securitate, atunci consideraiile de securitate pot deveni factorul primar n decizia repartizrii datelor pe procesoare. 15.11. Comentarii finale. Una din capacitile care disting un DBMS de o metod de acces bazat pe fiiere o constituie serviciile de protecie a datelor, care includ refacerea din diferite tipuri de eecuri, prevenirea conflictelor ntre tranzacii care acced date partajate, precum i prevenirea accesului neautorizat la resursa de date. Protecia datelor este o arie de cercetare activ de muli ani. Serviciile de protecie a datelor oferite n DBMS-uri vor continua s se dezvolte incorpornd cercetri noi. Cu ct vom deveni mai dependeni de suportul de baze de date cu att problema securitii datelor va sta mai mult n atenia noastr. Memento Abort Imagine dup Arhiv 427 Eec soft Granularitate Jurnal

Urm Backout Backup Imagine nainte Execuie serial ncuieri n dou faze Checkpoint Comitere Cheie criptografic Deadlock (blocare) Decriptare Incriptare ncuiere exclusiv Serializabilitate Protocol de comitere n dou faze Bibliografie

ncuiere Unitate logic de lucru Control concurenial optimist Parol ncuieri partajate UNDO Unitate de refacere Refacere Tehnic de refacere REDO Restart Rollback Rollforward Program de salvare Tranzacie

1. Bernstein, P.A.; Goodman, N. (1979) Approaches to concurency control in distributed database systems, Proceedings, 1979 National Computer Conference 2. *** (1980) Timestamp-based algorithms for concurency control in distributed database systems, Proceedings, Sixth International Conference on Very Large Databases, October 1980 3. Fernandez, E.B.; Summers, R.C.; Wood, C. (1981) Database Security and Integrity, Addison Wesley, Reading Mass. 4. Verhofstad, J.S.M. (1978) Recovery Techniques for database systems, ACM Computing Surveys 10. 5. *** (1981) The transaction concept: Virtues and Limitations, Proceedings, Seventh International Conference on Very Large Databases, Cannes, 1981.

Capitolul 16. Restricii de securitate i integritate.

n acest capitol vom discuta, pe scurt, dou teme care trebuie atinse atunci cnd se implementeaz un sistem baz de date. Prima, protecia i securitatea bazelor de date a fost deja tratat n capitolul precedent i include tehnicile folosite pentru protecia bazelor de date fa de accesele neautorizate. A doua, integritatea semantic a bazelor de date include tehnicile folosite pentru a pstra baza de date ntr-o stare consistent cu restriciile specificate asupra ei. Pentru a preveni a stare inconsistent a bazei de date, atunci cnd are loc o actualizare, partea de verificare a integritii semantice a sistemului va determina dac actualizarea cauzeaz o violare a restriciilor. 428

S notm c termenul de integritate este folosit cteodat pentru a acoperi att integritatea semantic ct i integritatea tranzaciilor. Al doilea concept include controlul concurenial i tehnicile de refacere discutate n capitolul precedent. n capitolul de fa vom folosi termenul de integritate pentru a ne referi numai la restricia de integritate semantic. Cu toate c conceptele de securitate i integritate sunt distincte, exist cteva similariti ntre ele. Ambele concepte pot fi definite n termeni de restricii dup cum urmeaz: securitatea este specificat n termeni de restricii de autorizare, pe cnd integritatea este specificat n termeni de restricii de integritate. ambele tipuri de restricii sunt memorate n catalogul DBMS astfel ca ele s poat fi impuse de ctre modulele software potrivite. DBMS-ul este responsabil cu monitorizarea interaciunii utilizatorului cu baza de date pentru a asigura ambele restricii, de securitate i de integritate. Prezentm, la nceput, tehnicile de securitate, iar apoi vom discuta tehnicile de impunere a restriciilor de integritate. 16.1. Securitatea i protecia bazelor de date. Securitatea bazelor de date este o problem foarte larg, care adreseaz multe chestiuni. Acestea includ urmtoarele: chestiuni legale i etice privind dreptul de a accede anumite informaii. Anumite informaii sunt socotite a fi private i nu pot fi accesate legal de ctre persoane neautorizate. n multe ri exist legi asupra aspectelor private ale informaiilor. chestiuni politice la nivel guvernamental, instituional sau de corporaie de selecie a informaiilor ce sunt publice. chestiuni legate de sistem, ca de exemplu, nivelele la care pot fi mnuite anumite funcii de securitate (nivel hard, nivel OS, nivel DBMS). Noi vom discuta aici securitatea la nivel DBMS. ntr-un sistem baze de date multiutilizator, DBMS-ul trebuie s ofere tehnici pentru a permite anumitor utilizatori s accead poriuni selectate ale bazei de date, fr a avea acces la restul bazei de date. n particular, aceasta este important atunci cnd o baz de date integrat mare trebuie folosit de mai muli utilizatori diferii din aceiai organizaie. Fiecare grup de utilizatori are, uzual, o mulime de aplicaii care acced numai o parte a bazei de date. Informaia sensibil trebuie pstrat confidenial pentru majoritatea utilizatorilor sistemului baz de date. Un DBMS include, de obicei, un subsistem de autorizare baz de date pentru a asigura securitatea poriunilor unei baze de date fa de accesele neautorizate. Un sistem pentru conferirea i revocarea privilegiilor la diferite clase de utilizatori este o tehnic obinuit pentru controlul autorizrilor la

429

baza de date. Vom discuta tehnicile care ofer diferite autorizri de acces la diferii utilizatori ai bazelor de date. O alt problem de securitate comun tuturor sistemelor de calcul este accea de a preveni accesul persoanelor neautorizate. Mecanismul de securitate al unui DBMS trebuie s includ msuri pentru a proteja accesul la sistemul baz de date n ntregimea sa. Aceste funcii reprezint controlul accesului i sunt efectuate prin crearea de conturi utilizator i parole pentru a controla procesul de login de ctre DBMS. O a treia problem de securitate asociat cu o baz de date este aceea de a controla accesul la o baz de date statistic. O baz de date statistic este folosit pentru a oferi informaii statistice sau rezumate de valori bazate pe diferite criterii. De exemplu, o baz de date pentru statistica populaiei poate fi folosit pentru a oferi statistici bazate pe grupuri de vrst, niveluri de impozite, de educaie, etc. Utilizatorilor bazelor de date statistice li se permite s accead baza de date pentru a regsi informaii statistice despre o populaie, dar nu i informaia confidenial detaliat despre indivizi specifici. Uneori se pot deduce fapte concrete ce privesc indivizi din informaii statistice, precum am prezentat ntr-un exemplu din capitolul precedent. Aceasta ar trebui, de asemenea, s nu fie permis. Problema n sine poart numele de securitate a bazelor de date statistice. O alt tehnic de securitate care poate fi aplicat bazelor de date i a fost deja menionat n capitolul precedent este criptarea datelor. Tehnica de criptare este n general folosit pentru a proteja datele sensibile care se transmit prin reele de comunicaii fa de accese neautorizate. Securitatea bazelor de date i DBA. Precum am prezentat n primele capitole, DBA este autoritatea central pentru gestionarea unui sistem baz de date. Responsabilitile unui DBA includ conferirea de privilegii utilizatorilor care folosesc sistemul. DBA are un cont privilegiat n DBMS numit uneori cont sistem (sau intern), care-i confer posibiliti puternice, pe care ali utilizatori nu le au. Acestea includ conferirea i revocarea de privilegii conturilor individuale, utilizatorilor, grupelor de utilizatori i conin urmtoarele tipuri de aciuni: 1. crearea contului: se creaz cu nou cont i o parol pentru un utilizator sau un grup de utilizatori, pentru a permite accesul la DBMS. 2. conferirea privilegiilor: permite ca DBA s confere anumite privilegii anumitor conturi. 3. revocarea privilegiilor: permite ca DBA s revoce (s tearg) anumite privilegii care au fost date anumitor conturi. DBA este responsabil cu securitatea total a sistemului baz de date. Prima din aciunile enumerate controleaz accesul la totalitatea sistemului, pe cnd a doua i a treia aciune sunt folosite pentru a controla autorizrile bazei de date. Conturi utilizator i revizii baz de date. Ori de cte ori o nou persoan sau un nou grup de persoane doresc s accead un sistem baz de 430

date, ei trebuie s cear un cont utiliztor. DBA va crea atunci un nou numr de cont (sau nume de cont) i o parol pentru persoan, dac cererea este legitim. Utilizatorul trebuie apoi s-i deschid o sesiune de lucru, s login n DBMS, introducnd numele de cont i parola de cte ori vrea s acceseze baza de date. DBMS verifica vaiditatea contului i a parolei i, n caz afirmativ, permite utilizatorului s foloseasc DBMS-ul i s accead baza de date. Aplicaiile program pot fi considerate, de asemenea ca utilizatori i li se pot cere parole. Este evident c trebuie pstrat o eviden a utilizatorilor bazei de date i a conturilor i parolelor lor, prin crearea unei tabele sau a unui fiier cu cel puin dou cmpuri: nume_cont i parol. Aceast tabel poate fi ntreinut uor de ctre DBMS. Ori ce cte ori se creaz un nou cont, o nou nregistrare este inserat n tabel. tergerea unui cont este tergerea linei respective din tabel. Sistemul baz de date trebuie s in de asemenea evidena tuturor operaiilor asupra bazei de date aplicate de un anumit utilizator n timpul fiecrei sesiuni de lucru (login session) care const din secvena de interaciuni baz de date pe care un utilizator le realizeaz de la deschiderea (login) i pn la nchiderea (logout sau logoff) sesiunii de lucru. Atunci cnd utilizatorul deschide o sesiune, DBMS-ul poate nregistra numele contului i terminalul de la care utilizatorul a deschis sesiunea. Toate operaiile aplicate de la acest terminal sunt atribuite contului utilizator pn la nchiderea sesiunii de lucru. Este, n particular, important s se in o eviden a operaiilor de actualizare care se aplic bazei de date astfel nct dac baza de date este corupt, s se poat cunoate utilizatorul responsabil de eveniment. Pentru aceast eviden se poate folosi system log (jurnalul sistemului). Acesta include o intrare pentru fiecare operaie aplicat bazei de date. Jurnalul este necesar pentru refacerea dintr-un eec tranzacie sau o cdere sistem. Se poate expanda jurnalul astfel nct s includ, de asemenea, contul utilizatorului i identificatorul terminalului. Dac este suspectat o corupere a bazei de date, se execut o revizie a bazei de date (audit), care const n examinarea tuturor acceselor i operaiilor aplicate bazei de date n timpul unei anumite perioade de timp, revizuind jurnalul. Dac se gsete o operaie ilegal sau neautorizat, DBA poate determina contul folosit pentru a realiza acea operaie. Reviziile bazei de date sunt importante, n particular, pentru bazele de date sensibile care sunt actualizate de multe tranzacii i utilizatori. Un jurnal baz de date folosit n principal pentru scopuri de securitate se numete uneori audit trail. DBA trebuie de asemenea, s poat s ofere diferite privilegii diferitelor conturi. Anumite conturi pot fi autorizate s foloseasc numai anumite fiiere din baza de date sau chiar numai anumite cmpuri. Mai mult, chiar dac dou conturi au acces la acelai fiier, unui cont i se pot permite operaii de actualizare, pe cnd altuia doar de citire. n seciunea urmtoare vom discuta tipurile de privilegii care pot fi date conturilor individuale i modul n care sunt controlate aceste privilegii. 431

Mecanisme de privilegii i autorizare. Metoda tipic pentru a impune autorizrile ntr-un sistem baze de date este bazat pe conferirea i revocarea de privilegii. S considerm privilegiile n contextul unui DBMS relaional. n particular, vom discuta un sistem de privilegii care este similar cu cel dezvoltat pentru limbajul SQL (cap.8.). Multe DBMS-uri relaionale folosesc variaii ale acestei tehnici. Ideea de baz este de a include instruciuni adiionale n limbajul de interogare care permit lui DBA i anumitor utilizatori s confere i s revoace privilegii. DBMS-ul trebuie s ofere acces selectiv la fiecare relaie din baza de date numai din conturi specifice. Operaiile trebuie de asemenea s fie controlate. Posedarea unui cont nu-i permite utilizatorului accesul la toate funciile oferite de DBMS. Exist dou nivele pentru asignarea privilegiilor pentru a folosi sistemul de baz de date: 1. nivelul cont: la acest nivel, DBA specific privilegiile particulare pe care le posed fiecare cont, independent de relaii din baza de date. 2. nivelul relaie: la acest nivel putem controla privilegiile de acces la fiecare relaie individual sau vedere din baza de date. Privilegiile de la nivelul cont se aplic posibilitilor oferite de contul nsui i pot include, privilegiul CREATE pentru a crea o relaie de baz, privilegiul CREATE VIEW, privilegiul ALTER pentru a aduga sau a terge atribute din relaii, privilegiul DROP pentru a terge relaii sau vederi, privilegiul MODIFY pentru a insera, terge sau modifica tuple, privilegiul SELECT pentru a regsi informaii din baza de date folosind o interogaie SELECT. S notm c toate aceste privilegii de cont se aplic contului n general. Dac un anumit cont nu are privilegiul CREATE, nici o relaie nu poate fi creat de acest cont. Dac contul nu are privilegiul MODIFY, nici o relaie nu poate fi actualizat din acel cont, etc. Privilegiile de la nivelul relaiei se aplic relaiilor individuale, fie acestea de baz sau virtuale (vederi). Putem considera privilegiile de la nivelul cont ca i conferind o funcionalitate general contului (tip de comand). Privilegiile de la nivelul relaie specific apoi relaiile individuale pe care poate fi aplicat fiecare tip de comand. Un anumit privilegiu pe o relaie individual nu poate fi conferit unui cont dac acesta nu are respectivul privilegiu de cont. De exemplu, un cont anume nu poate actualiza relaia DEPARTAMENT dac lui nu i este conferit privilegiul MODIFY n genere. Multe DBMS-uri comerciale nu fac distincie ntre cele dou nivele de privilegii oferind privilegii numai la nivel de relaie. Pentru a controla conferirea i revocarea de privilegii la nivel de relaie, fiecrei relaii R dintr-o baz de date i se asigneaz un cont proprieatar care este, de obicei, contul care s-a folosit atunci cnd relaia a fost creat. Proprietarul unei relaii are toate privilegiile asupra relaiei. Aceasta nseamn c toare relaiile care au fost create dintr-un cont pot fi accesate din acel cont. Cel care intr n contul proprietar poate pasa aceste privilegii altor utilizatori conferind privilegii conturilor acestora. n SQL 432

urmtoarele tipuri de privilegii pot fi conferite la nivelul unei relaii individuale R: 1. SELECT: contul are privilegiul de regsire. n SQL, contul poate folosi instruciunea SELECT pe tuplele din relaia R. 2. MODIFY: contul are posibilitatea de a modifica tuplele lui R. n SQL, acest tip de privilegiu este divizat n UPDATE, DELETE i INSERT pentru a se aplica comenzilor corespunztoare pe R. Privilegiul UPDATE poate restriciona dreptul de actualizare la anumite atribute ale lui R pentru un anumit cont. 3. ALTER: contul are posibilitatea de a modifica definiia lui R, adugnd sau tergnd atribute. n SQL contul poate folosi comanda ALTER pe R. S notm c pentru a crea o vedere, contul trebuie s aib privilegiul SELECT pe toate relaiile implicate. Specificarea autorizrii folosind vederi. Mecanismul pentru vederi este un mecanism de autorizare important. De exemplu, dac proprietarul A al unei relaii R dorete ca un alt cont B s fie capabil s regseasc numai anumite cmpuri ale lui R, atunci A poate crea o vedere V a lui R care include numai acele atribute i apoi confer SELECT pe V lui B. Acelai procedeu se aplic i pentru a limita accesul lui B numai la anumite tuple ale lui R. Se poate crea o vedere W definit printr-o interogaie care selecteaz numai acele tuple ale lui R pe care A dorete s le fac accesibile lui B. Vom discuta acest exemplu mai pe larg la sfritul seciunii. Revocarea privilegiilor. n anumite situaii dorim s conferim unui utilizator anumite privilegii pe o perioad limitat de timp. De exemplu, proprietarul unei relaii dorete s confere privilegiul SELECT unui utilizator pentru o sarcin specific i apoi s revoce privilegiul dup ce sarcina a fost ndeplinit. Deci, trebuie s avem un mecanism pentru revocarea privilegiilor care au fost conferite. n SQL, pentru a terge privilegii, se folosete comanda REVOKE. Propagarea privilegiilor i opiunea GRANT. Cnd proprietarul A al unei relaii R confer un privilegiu pe R unui alt cont B, privilegiul poate fi acordat cu sau fr opiunea GRANT. Dac se specific opiunea GRANT, aceasta nseamn c B va putea n continuare conferi de asemenea privilegiul obinut altor conturi. S presupunem c lui B i este dat GRANT OPTION de ctre A i c el confer apoi privilegiul pe R unui al treilea cont C, de asemenea cu GRANT OPTION. n acest mod, privilegiile pe R se pot propaga la alte conturi, fr tirea proprietarului lui R. Dac contul proprietar A revoc acum privilegiul conferit lui B, toate privilegiile pe care B le-a propagat pe baza acelui privilegiu vor fi automat revocate de ctre sistem. Deci, un DBSM care permite propagarea privilegiilor trebuie s in evidena modului n care au fost conferite toate privilegiile astfel ca revocarea lor s se fac corect. Au fost dezvoltate tehnici pentru a limita propagarea privilegiilor, cu toate c ele nu au fost nc implementate pe majoritatea DBMS-urilor. 433

Limitarea propagrii orizontale la un ntreg i nseamn c dndu-i unui cont B GRANT OPTION, el poate conferi privilegiul la cel mult i alte conturi. Propagarea vertical este mai complicat; ea limiteaz adncimea pn la care se confer privilegii. Conferirea unui privilegiu cu propagare vertical nul este echivalent cu conferirea privilegiului fr GRANT OPTION. Dac un cont A confer acest privilegiu contului B cu propagare vertical setat pe un ntreg j > 0, aceasta nseamn c contul B are GRANT OPTION pe acel privilegiu dar B poate conferi privilegiul altor conturi numai cu propagare vertical strict mai mic dect j. Deci, propagarea vertical limiteaz secvena de opiuni de conferire care pot fi date dintr-un cont n urmtorul pe baza unei singure conferiri de privilegii originale. Vom ilustra aceasta prin exemplul urmtor: ANGAJAT NUME SSN

DBATE

ADRESA

SEX

SALAR

DNO

DEPARTAMENT DNUMAR DNUME

MGRSSN

Fig.16.1. Cele dou relaii ANGAJAT i DEPARTAMENT. Un exemplu. n acest exemplu vom folosi, pe ct posibil, comenzile SQL de autorizare din DB2. S presupunem c DBA a creat patru conturi A1, A2, A3 i A4 i dorete ca A1 s fie capabil a crea relaii de baz; atunci DBA trebuie s emit urmtoarea comand GRANT n SQL: GRANT CREATETAB TO A1; Privilegiul CREATETAB (creare tabel) d contului A1 posibilitatea de a crea noi tabele baz de date (relaii de baz) i este deci un privilegiu de cont. Acum, s presupunem c A1 creaz cele dou relaii de baz ANGAJAT i DEPARTAMENT din fig.16.1. Atunci A1 este proprietarul acestor dou relaii i deci are toate privilegiile de relaie pe fiecare dintre ele. n continuare, s presupunem c contul A1 dorete s confere contului A2 privilegiul de a insera i terge tuple n ambele relaii. Totui, A1 nu dorete ca A2 s fie n stare s propage aceste privilegii unor conturi adiionale. Atunci A1 poate emite comanda: GRANT INSERT, DELETE ON ANGAJAT, DEPARTAMENT TO A2; S notm c contul proprietar A1 al unei relaii are automat GRANT OPTION, permiindu-i s confere privilegii pe relaie la alte conturi. A2 nu poate conferi privilegiile INSERT i DELETE pe tabelele ANGAJAT i DEPARTAMENT, deoarece A2 nu a primit opiunea GRANT OPTION n comanda de mai sus.

434

n continuare, s presupunem c A1 dorete s-i permit lui A3 s regseasc informaii din ambele tabele i ,de asemenea, s propage privilegiul SELECT altor conturi. Atunci A1 emite comanda: GRANT SELECT ON ANGAJAT, DEPARTAMENT TO A3 WITH GRANT OPTION; Clauza WITH GRANT OPTION nseamn c acum A3 poate propaga privilegiul spre alte conturi folosind GRANT. De exemplu, A3 poate conferi privilegiul SELECT pe relaia ANGAJAT lui A4 emiind urmtoarea comand: GRANT SELECT ON ANGAJAT TO A4; S notm c A4 nu poat propaga privilegiul SELECT altor conturi deoarece nu a obinut GRANT OPTION. S presupunem acum c A1 decide s revoce privilegiul SELECT pe relaia ANGAJAT de la A3. A1 emite comanda: REVOKE SELECT ON ANGAJAT FROM A3; DBMS-ul trebuie acum s revoce automat privilegiul SELECT pe ANGAJAT de la A4, deoarece A3 i-a conferit acest privilegiu lui A4, iar A3 nu mai are privilegiul. n continuare, s presupunem c A1 vrea s-i redea lui A3 o posibilitate limitat de SELECT pe relaia ANGAJAT. Limitarea const n reducerea numrului de atribute pe care A3 le poate regsi la NUME, BDATE i ADRESA i numai la tuplele cu DNO = 5. Atunci A1 creaz urmtoarea vedere: CREATE VIEW A3ANGAJAT AS SELECT NUME, BDATE, ADRESA FROM ANGAJAT WHERE DNO = 5; Dup ce a creat vederea, A1 poate conferi SELECT pe vederea A3ANGAJAT lui A3 astfel: GRANT SELECT ON A3ANGAJAT TO A3 WITH GRANT OPTION; n fine, s presupunem c A1 dorete s-i permit lui A2 s actualizeze numai atributul SALAR al lui ANGAJAT. Atunci, A1 emite comanda: GRANT UPDATE ON ANGAJAT (SALAR) TO A2; Privilegiul UPDATE poate specifica atributele particulare care pot fi actualizate ntr-o relaie. Alte privilegii (SELECT, INSERT, DELETE) nu sunt specifice atributelor, cu toate c aceast specificitate poate fi uor controlat crend vederi potrivite care includ numai atributele dorite. Totui, deoarece actualizrea vederilor nu este ntotdeuna posibil, privilegiul UPDATE are posibilitatea de a fi specificat cu atributele relaiei de baz care pot fi actualizate. S notm c este posibil pentru un utilizator s primeasc un anumit privilegiu de la dou sau mai multe surse. De exemplu, A4 poate primi privilegiul UPDATE R att de la A2 ct i de la A3. ntr-un astfel de

435

caz, chiar dac A2 i revoca privilegiul lui A4, A4 continu s aib privilegiul de la A3. Dac i A3 i revoc privilegiul, A4 l pierde efectiv. Ilustrm acum pe scurt limitele propagrii orizontal i vertical, care nu sunt disponibile n DBMS-uri relaionale. S presupunem c A1 confer SELECT lui A2 pe relaia ANGAJAT cu propagare orizontal 1 i propagare vertical 2. Apoi A2 poate conferi privilegiul SELECT cel mult unui cont, deoarece propagarea orizontal este limitat la 1. n plus A2 nu poate conferi privilegiul unui alt cont dect cu propagare vertical 0 (deci fr GRANT OPTION) sau 1 deoarece limita propagrii verticale a fost setat la 2 cnd i s-a dat privilegiul lui A2. Securitatea bazei de date statistice. Bazele de date statistice se folosesc n principal, pentru producerea de statistici asupra diferitelor populaii. Baza de date se presupune a conine date confideniale despre diveri indivizi, protejate fa de accesul utilizatorilor. Totui, acetia pot regsi informaii statistice despre populaie n ansamblul ei, ca medii, sume, contoare i deviaii standard. Tehnicile folosite pentru a proteja informaiile individuale private n bazele de date statistice nu fac obiectul acestui text. Vom ilustra doar, pe scurt, problema printr-un exemplu. n fig.16.2. prezentm relaia PERSOANA. PERSOANA NUME SSN

VENIT

ADR.

ORAS

JUDET

COD

SEX

EDUC

Fig.16.2. Relaia PERSOANA. O populaie este o mulime de tuple ale unui fiier care satisfac o anume condiie de selecie. Deci, fiecare condiie de selecie pe relaia PERSOANA va da o populaie specific de tuple PERSOANA. De exemplu, condiie SEX = M specific populaia brbteasc, iar condiia (SEX = F) AND (EDUC = DR) specific populaia feminin cu titlul de doctor. Interogaiile statistice implic aplicarea funciilor statistice la o populaie de tuple. De exemplu, putem dori d regsim numrul de indivizi dintr-o populaie sau venitul mediu pe o populaie. Totui, utilizatorilor statistici nu li permite s regseasc date individuale, de ex: venitul unei anumite persoane. Tehnicile de securitate a bazei de date statistice trebuie s interzic regsirea datelor individuale. Aceasta poate fi controlat uor interzicnd regsirea interogaiilor care regsesc valori de atribute i permiind numai interogaii care aplic funcii agregate statistice, ca de ex: COUNT, SUM, MIN, MAX, AVERAGE i STANDARD DEVIATION. Uneori, astfel de interogaii se numesc interogaii statistice. n anumite cazuri, este posibil s se deduc valorile tuplelor individuale dintr-o secven de interogaii statistice. Aceasta este n particular adevrat n cazul n care condiiile dau o populaie cu un mic numr de membri. Pentru ilustrare, s presupunem urmtoarele dou interogaii statistice: 436

SELECT COUNT (*) FROM PERSOANA WHERE <condiie>; SELECT AVERAGE (VENIT) FROM PERSOANA WHERE <condiie>; Acum, s presupunem c suntem interesai n salariul lui Ion Ionescu i tim c are doctorat i locuiete n Timisoara, judeul Timi. Emitem, atunci, interogaia statistic cu urmtoarea condiie: (EDU = DR AND SEX = M AND ORAS = Timisoara AND JUDET = Timis) Dac la interogaia COUNT obinem valoarea 1, putem emite a doua interogaie cu aceai condiie i vom regsi venitul lui Ion Ionescu. Chiar dac rezultatul numrrii este 2 sau 3 putem emite interogaii statistice folosind funciile MAX, MIN i AVERAGE i putem afla rezultatele. Posibilitatea de a deduce informaii individuale din interogaii statistice este redus dac nu se permit interogaii statistice pentru populaii cu un numr de tuple sub un prag. O alt tehnic pentru a interzice regsirea informaiilor individuale este de a interzice secvena de interogaii ce se refer repetitiv la aceai populaie de tuple. De asemenea, este posibil a se introduce inacuratei uoare sau zgomote deliberate n rezultatele interogaiilor statistice, pentru a face dificil deducerea informaiilor individuale din rezultat. 16.2. Specificarea i impunerea restriciilor de integritate. Atunci cnd se proiecteaz o schem pentru o aplicaie baze de date particular, una in activitile importante este identificarea restriciilor de integritate ce trebuiesc impuse bazei de date. n seciunea de fa vom discuta tipurile de restricii des ntlnite, apoi tehnicile folosite de ctre DBMS-uri pentru specificarea restriciilor. Vom compara modelele de date n termenii restriciilor i, n fine, vom discuta tehnicile de impunere a restriciilor de integritate. 16.2.1. Tipuri de restricii de integritate. De obicei, se implementeaz o baz de date pentru a stoca informaii despre o anume parte din lumea real, numit i minilume. n orice situaie din minilume exist mai multe reguli, numite restricii de integritate care guverneaz situaia respectiv. Dorim s specificm majoritii acestor restricii DBMS-ului i, dac este posibil, s-l facem responsabil cu impunerea lor. Restricii implicite, explicite i inerente ale unui model de date. n orice model de date exist cteva tipuri de restricii de integritate care pot fi reprezentate i specificate n schemele baz de date ale modelului. Ele se numesc restricii implicite ale modelului de date i se specific folosind DDL-ul. Fiecare model de date are o mulime diferit de restricii implicite care pot fi reprezentate direct n schemele sale. n general, modelele de date

437

de nivel nalt reprezint mai multe tipuri de restricii implicite dect modelele de date de nivel jos. Totui, nici un model de date nu este capabil s reprezinte toate tipurile de restricii care pot s apar n minilume. Este, ca atare, necesar s specificm restricii explicite adiionale pe fiecare schem particular de baze de date. Un al treilea tip de restricii l constituie restriciile inerente ale modelului nsi, care nu trebuie s fie specificate ntr-o schem i sunt presupuse a avea loc prin definiia construciei modelului. Am prezentat restriciile fiecrui model de date atunci cnd am prezentat diferitele modele de date. Exemple de restricii implicite i inerente n diferite modele de date sunt urmtoarele: modelul relaional: restriciile de integritate relaional, de integritate a cheilor i a entitilor sunt n general considerate a fi implicite n modelul relaional, cu toate c anumite sisteme relaionale nu reprezint implicit restriciile de integritate referenial. O restricie inerent n modelul relaional formal este aceea c o valoare atribut este indivizibil (atomic). modelul ierarhic: regulile ierarhice, ca de ex: regula c o rdcin nu poate avea un tat sau c o nregistrare nonrdcin are exact un tat sunt restricii inerente. modelul reea: restriciile de cheie unic pe cmpuri i regulile care guverneaz tipurile de mulimi (opiunile INSERTION i RETENTION) sunt specificate implicit. Restriciile inerente includ regula c o instan de nregistrare nu poate fi membru a mai mult de o instan de mulime a unui tip particular de mulime. n general, fiecare model de date este o mulime de concepte i reguli sau aseriuni care specific structura i restriciile impicite ale unei baze de date descriind o minilume. O implementare dat a unui model de date ntr-un DBMS particular suport, n mod uzual, numai cteva din restriciile implicite i inerente ale modelului de date automat. Suportul i impunerea restriciilor de integritate este un punct slab al multor DBMS-uri relaionale existente. Restricii de stare i tranziie ale unei aplicaii baze de date. Putem clasifica urmtoarele tipuri de restricii care apar frecvent n aplicaiile baze de date: 1. Restricii de stare ale bazei de date: acestea sunt restriciile asupra strii bazei de date. O stare sau o instan a bazei de date se refer la toate datele din baza de date la un moment dat. O stare a bazei de date este consistent dac ea satisface toate restriciile de stare. Exemple de restricii de stare: a) restricia pe mulimea valorilor (domeniul), adic pe valorile posibile pe care le poate lua un atribut. b) restricii de atribut cheie (unicitate), care specific dac un atribut (sau o mulime de atribute) este un atribut unic al unui tip 438

de entitate. Oricare dou instane de entitate ale tipului de entitate nu pot avea aceeai valoare pentru un atribut cheie. c) restricii de atribut structural, care specific dac un atribut este cu o singur valoare sau multivaloric i cnd este permis ca el s fie nul. d) restricii de structur a relaiei, ca de exemplu, cele care specific cardinalitatea i restriciile de integritate referenial. e) restricii de superclas/subclas, care specific disjunctivitatea sau totalitatea specializrilor/generalizrilor. f) restricii de integritate semantic general, adic restricii de stare care nu intr n nici una din categoriile de mai sus. Restriciile de stare se aplic unei stri particulare a bazei de date i trebuie s aib loc n fiecare stare n care baza de date nu este n tranziie, adic nu este n procesul de actualizare. Din aceast cauz ele se numesc uneori i restricii statice. Restriciile de stare pot fi verificate de cte ori starea bazei de date se modific de ctre o tranzacie de actualizare. O tranzacie trebuie s includ suficiente verificri pentru a garanta c ori de cte ori baza de date este ntr-o stare consistent nainte de execuia tranzaciei, tot aa trebuie s fie i dup execuia acesteia. Aa cum am mai specificat, o tranzacie este o unitate de actualizare atomic. Modelele de control concurenial i de refacere vor trebui s garanteze c ori toate operaiile tranzaciei se execut, ori nu se execut nici una. 2. Restricii de tranziie baze de date. O restricie de tranziie este o restricie pe tranziia dintr-o stare n alta, i nu pe o stare individual. Un exemplu este c SALARIUL unui angajat poate fi numai incrementat. Aceasta nseamn c orice actualizare a atributului SALARIU este acceptat numai dac noua valoare este mai mare dect cea veche. S notm c restricia nu este nici pe starea bazei de date nainte de actualizare i nici pe starea bazei de date de dup actualizare. Ea este specific pe tranziia ntre stri i implic valori de atribute att nainte ct i dup tranzacie. n general, restriciile tranziiei apar mai puin frecvent dect restriciile de stare i sunt numite uneori restricii dinamice. Din cauza naturii lor, ele sunt mult mai greu de impus i sunt specificate, n principal, ca i restricii explicite. Fig.16.3. rezum clasificare restriciilor.

439

Inerente

Implicite

Explicite

Restricii

Statice (de stare)

Dinamice (de tranziie)

Fig.16.3. Clasificarea restriciilor.

16.2.2. Specificarea restriciilor de integritate explicite. Restriciile inerente nu trebuie s fie specificate n DDL atunci cnd se definete o schem baz de date. Ele sunt proprieti inerente ale construciilor modelului de date. Restriciile implicite care sunt suportate de ctre un DBMS se specific n DDL n timpul definirii schemei. DBMS-ul este responsabil apoi cu impunerea lor automat. n aceast seciune vom discuta diferite abordri pentru a specifica restricii explicite, care sunt n afara domeniului DDL-ului n majoritatea DBMS-urilor. Specificarea procedural a restriciilor explicite n tranzacii. O metod de specificare a restriciilor explicite este de a include instruciuni de verificare n tranzaciile de actualizare. Aceasta se numete specificarea procedural a restriciilor (sau tehnica restriciilor codate). Restriciile sunt codate n tranzacii potrivite de ctre programator. De exemplu, s considerm restricia general c salariul unui angajat nu poate fi mai mare dect salariul managerului departamentului la care lucreaz acel angajat. Pentru a impune aceast restricie, ea trebuie s fie verificat n orice tranzacie de actualizare care poate viola restricia. Aceasta include orice tranzacie care modific salariul unui angajat, orice tranzacie care insereaz un angajat sau leag un nou angajat la un departament, orice tranzacie care asigneaz un nou manager unui departament, etc. n orice astfel de tranzacie, o parte a codului tranzaciei trebuie s verifice explicit dac restricia nu este violat. Dac restricia este violat, tranzacia trebuie s fie abortat fr a face nici o modificare n baza de date. Aceasta ne asigur c tranzacia se comport nu numai ca o unitate atomic pentru scopuri concureniale i de refacere ci i pentru controlul integritii semantice.

440

Tehnica de mai sus pentru restricii explcite este folosit de multe DBMS-uri existente. Ea este folosit, de asemenea, n modelarea orientat pe obiecte, unde restriciile explicite pot fi codate ca parte a modelelor sau operailor care sunt incapsulate cu obiectele. Aceast tehnic este complet general deoarece verificrile sunt programate de obicei ntr-un limbaj de programare de scop general. Tehnica aceasta permite de asemenea programatorului s codifice verificrile ntr-un mod eficient. Totui, ea nu este suficient de flexibil i plaseaz o povar suplimentar programatorului, care trebuie s cunoasc toate restriciile pe care le-ar putea nclca o tranzacie i trebuie s includ verificri pentru a se asigura c nici una din aceastea nu va fi violat. O proast nelegere, o omisiune sau eroare a programatorului poate lsa baza de date ntr-o stare inconsistent. Un alt neajuns al specificrii procedurale a restriciilor este c acestea se pot modifica n timp. Dac o restricie se schimb, este responsabilitatea DBA de a instrui programatorii potrivii pentru a recodifica toate tranzaciile afectate de schimbare. Aceasta las posibilitatea omiterii unor tranzacii i deci, a structurrii unei erori n reprezentarea restriciilor. Dac o tranzacie este modificat i alta nu, atunci cele dou tranzacii vor verifica restricii diferite, cauznd posibile inconsistene n baza de date. Specificarea declarativ a restriciilor explicite ca aseriuni. O a doua tehnic, mai formal, a fost sugerat pentru a reprezenta restriciile explicite. n aceast abordare, pentru a declara toate restriciile explicite care trebuie s aib loc pentru o schem, se folosete un limbaj de specificare a restriciilor, bazate pe cteva variaii ale calculului relaional. n aceast abordare declarativ exist o separare clar ntre baza de restricii, n care se memoreaz restriciile ntr-o form codificat potrivit i subsistemul de control al integritii al DBMS-ului, care accede baza de restricii pentru a aplica potrivit restriciile tranzaciilor afectate. Atunci cnd folosim aceast tehnic, restricile sunt numite adesea aseriuni de integritate sau simplu, aseriuni, iar limbajul de specificare se numete limbaj de specificare al aseriunilor. Termenul de aseriune este folosit n loc de restricie explicit, iar aseriunile sunt specificare ca instruciuni declarative. Tehnica aceasta s-a impus la DBMS-uri relaionale. Limbajul SQL include instruciunea ASSERT pentru specificarea aseriunilor, cu toate c aceast instruciune nu este implementat n multe DBMS-uri relaionale curente. Subsistemul de control al integritii va compila aseriunile, care se memoreaz apoi n catalogul DBMS de unde subsistemul de control al integritii le poate referi i impune automat. Tranzaciile de actualizare pot fi scrise acum fr nici o instruciune de verificare a vreunei restricii. Aceast abordare este mai atrgtoare din punctul de vedere al utilizatorilor i al programatorilor din cauza flexibilitii sale. Tranzaciile de actualizare sunt foarte uor de scris n acest sistem deoarece nu mai sunt necesare verificri ale violrii restriciilor. O restricie poate fi modificat independent de 441

tranzacii, fr a trebui recodificate acestea. Trebuie tears doar vechea aseriune i introdus n locul ei cea nou. Noua aseriune este compilat i nlocuiete aseriunea tears n catalogul DBMS-ului. Din nefericire, aceast tehnic s-a dovedit mai dificil de implementat, deoarece subsistemul de control al integritii este complex i ineficient. n continuare vom da un exemplu de declaraie de aseriune n SQL. S considerm o schem relaional ca n fig.16.1. Putem specifica restricia salariul unui angajat nu poate s fie mai mare dect salariul managerului departamentului pentru care lucreaz respectivul angajat. ASSERT RESTRICTIE_SALARIU ON ANGAJAT E, M, DEPARTAMENT: E.SALARIU < M.SALARIU AND E.DNO = DNUMBER AND MGRSSN = M.SSN; Cuvntul cheie ASSERT indic faptul c s-a definit o restricie i el este urmat de numele restriciei RESTRICTIE_SALARIU, care poate fi folosit pentru a referi sau elimina restricia mai trziu. Ceea ce urmeaz cuvntului cheie ON sunt relaiile afectate de restricie. n final, se specific condiia restriciei. O condiie de restricie este similar cu condiia unei clauze WHERE din SQL. De cte ori anumite tuple din baza de date fac ca o condiie a unei instruciuni ASSERT s nu fie ndeplinit, restricia este violat. Restricia este satisfcut de ctre o stare a bazei de date dac nici o combinaie de tuple din baza de date nu violeaz restricia. Triggere. n multe cazuri este convenabil s se specifice tipul aciunii de urmat n caz de violare a unei restricii. Pot fi disponibile i alte opiuni n afar de cea a abortrii tranzaciei care cauzeaz o violare. De exemplu, poate fi util a se specifica o restricie care, dac este violat, va fi informat un anumit utilizator. Un manager poate dori s fie informat dac cheltuielile de deplasri ale unui angajat depesc o anumit valoare. Aciunea pe care trebuie s o ia DBMS_ul n acest caz este de a trimite un masaj potrivit utilizatorului, iar apoi restricia este folosit pentru a monitoriza baza de date. Se pot specifica i alte aciuni, ca executarea unei anumite proceduri sau a altor actualizri. n abordarea procedural, toate aciunile de acest fel pot fi specificate prin codificarea lor n tranzaciile cu pricina. n abordarea declarativ, un mecanism numit trigger a fost propus pentru a implementa astfel de actiuni. Un trigger specific o condiie i o aciune care trebuie s aib loc dac se ndeplinete condiia. Uzual, condiia este specificat ca o aseriune care invoc sau declaneaz (n lb. englez, triggers) aciunea atunci cnd devine adevrat. Este de asemenea, posibil definirea unor condiii pentru triggere de tranzacii. De exemplu, putem defini o procedur trigger care este invocat atunci cnd o anume tranzacie i atinge punctul su de comitere pentru a verifica dac tranzacia trebuie comis sau abortat i dac tranzacia ar trebui abortat, trigger-ul poate determina un UNDO al tranzaciei. Pentru a specifica triggere n SQL, a fost propus o instruciune DEFINE TRIGGER, care ns nu este implementat n toate SQL-urile. 442

Pentru a ilustra cum poate fi specificat un trigger n SQL, s presupunem c dorim s specificm un trigger pentru a notifica managerul de departament dac un anagajat din departament are un salariu mai mare dect managerul. Putem defini urmtorul trigger: DEFINE TRIGGER RESTRICTIE_SALARIU ON ANGAJAT E, M, DEPARTAMENT: E.SALARIU > M.SALARIU AND E.DNO = DNUMBER AND MGSSN = M.SSN ACTION:PROCEDURE INFORM.MANAGER (MGSSN); Triggerul de mai sus specific faptul c procedura INFORM.MANAGER trebuie s se execute de cte ori apare condiia trigger-ului. S notm diferena dintre ASSERT i TRIGGER. O instruciune ASSERT poate interzice o actualizare care contravine condiiei aseriunii, pe cnd un trigger permite actualizarea, ns execut procedura specificat. S notm c triggerele combin abordrile declarativ i procedural. Condiia trigger este declarativ, n timp ce aciunea lui este procedural. n general, poate fi util s specificm triggere nu numai pentru restriciile explicite, ci i pentru unele implicite. De exemplu, n modelul reea aciunea de a terge nregistrrile membru atunci cnd s-a ters nregistrarea proprieatar poate fi specificat pe o mulime MANDATORY dac s-a folosit comanda DELETE ALL. S notm c este necesar s se verifice ciclitatea triggerelor; altfel pot apare bucle infinite. 16.2.3. Restricii de integritate n diferite modele de date. Vom compara acum, pe scurt, diferite modele de date n legtur cu modul n care ele reprezint restriciile i tipurile de restricii implicite asociate cu ele. O discuie implicit, dar mai complet a avut deja loc n capitolele care descriu fiecare din modelele de date. Modelul relaional. Restriciile implicite disponibile n modelul relaional includ restriciile de mulime de valori (domeniu) i restriciile de cheie pe atribute. Integritatea referenial este considerat i ea, uneori, a fi o restricie implicit n modelul relaional cu toate c ea nu este uzual, reprezentat ntr-o schem relaional sau n DDL-ul limbajelor relaionale populare, cum ar fi SQL i QUEL. Pentru a face integritatea referenial o restricie implicit, este necesar s se includ anumite instruciuni n DDL care s permit specificarea restriciilor de integritate refernial n schema bazei de date. S notm c integritatea referenial este o restricie structural pe relaiile de tuple. De asemenea, dac un DBMS relaional permite instruciunea ASSERT sau o alt construcie similar, integritatea referenial poate fi exprimat ca o restricie explicit prin instruciuni ASSERT potrivite. n modelul relaional toate celelalte tipuri de restricii sunt explicite i sunt specificate fie ca aseriuni, fie sunt codificate n tranzaciile de actualizare.

443

Modelul reea. n modelul reea, restriciile mulime de valori (tip de dat) i cheie (unic) sunt implicite, aa cum sunt anumite restricii structurale pe relaiile 1:N. Acestea din urm sunt specificate ca opiuni atunci cnd este declarat un tip de mulime. S ne amintim, c un tip de mulime este o relaie 1:N ntre dou tipuri de nregistrri. Opiunile INSERTION i RETENTION pe un tip de mulime sunt restricii structurale pe o relaie 1:N. De exemplu, un tip de mulime MANDATORY specific faptul c fiecare membru trebuie s fie legat de o nregistrare proprietar (apartenen total), pe cnd un tip de mulime OPTIONAL permite unei nregistrri membru s existe fr a fi legat de o nregistrare proprietar (apartenen parial). Restriciile structurale pe mulimi specific nregistrarea proprietar la care poate fi conectat un membru printr-o condiie pe atributele tipurilor de nregistrri proprietar i membru. Mai mult,sunt disponibile restricii structurale pe atribute, deoarece sunt permise atribute compuse (vectori) i atribute multivalorice (grup reportativ). Toate celelalte tipuri de restricii sunt codificate n programele de actualizare i deci, sunt specificate ca i restricii explicite n modelul reea. S notm c tipurile de mulimi AUTOMATIC sunt o form implicit de trigger. Aici, condiia este ca o nregistrare membru s fie inserat n baza de date. Aciunea care trebuie efectuat este gsirea unei nregistrri proprietar pentru membrul respectiv folosind procedura SET SELECTION i conectarea nregistrrii membru la nregistrarea proprietar gsit. Un alt exemplu de trigger implicit n modelul reea este comanda DELETE ALL, care terge nregistrarea specificat i toate nregistrrile membru din proprietarea acelei nregistrri. Modelul ierarhic. Restricia ierarhic inerent de baz este aceea c fiecare nregistrare dintr-o ierarhie trebuie s aib un tat, cu excepia nregistrrilor rdcin. Din nou, aceasta este o restricie structural pe o relaie 1:N. Restriciile de mulime de valori i de cheie sunt specificate implicit. Alte restricii inerente implic VPCR-uri, ca de exemplu restricia c un pointer trebuie s refere o nregistrare tat virtual existent. Majoritatea celorlalte restricii sunt codificate n programele de actualizare ca restricii explicite. 16.2.4. Impunerea restriciilor de integritate. Restriciile implicite sunt specificate DBMS-ului prin DDL n timpul procesului de creare a schemei bazei de date. Compilatorul DDL memoreaz aceste restricii n catalogul DBMS. Software-ul DBMS poate apoi impune automat restricia implicit potrivit de fiecare dat cnd apare o actualizare, referind catalogul. Dac DBMS-ul folosete un limbaj de specificare a aseriunilor, restriciile explicite care sunt specificate n limbaj sunt meninute n mod similar cu restriciile implicite, cu excepia c algoritmii sunt mai compleci dect cei pentru a impune o mulime mic de tipuri de restricii bine definite. 444

Altfel, restriciile explicite sunt codificate n tranzacii i este responsabilitatea programatorilor i a administratorului bazei de date s verifice dac ele sunt codificate corect. Memento Protecie Securitate Integritate semantic Restricii de autorizare Restricii de integritate Subsistem autorizare baz de date Controlul accesului Baz de date statistic Criptarea datelor Cont privilegiat Cont sistem Login Logout (Logoff) Revizia bazei de date Privilegii nivel cont Privilegii nivel relaie Cont proprietar Vedere Privilegiu Propagarea privilegiilor Populaie Interogaii statistice Restricii implicite Restricii explicite Restricii inerente Restricii de stare (statice) Restricii de tranziie (dinamice) Restricii semantice Specificare procedural a restriciilor Specificare declarativ a restriciilor Aseriuni de integritate Trigger

445