Sunteți pe pagina 1din 15

2 MEDIUL BAZELOR DE DATE

2.1 Arhitectura bazei de date cu 3 nivele Asigurarea independenei fizice i logice a datelor impune adoptarea unei arhitecturi organizat pe cel puin 3 nivele (arhitectura ANSI-SPARC): 1. nivelul intern (baza de date fizic) 2. nivelul conceptual 3. nivelul extern Obiectivul arhitecturii cu 3 nivele este separarea vederii fiecrui utilizator asupra bazei de date de modul n care este ea reprezentat fizic. Utilizator 1 Nivelul extern Nivelul conceptual Nivelul intern Vedere 1 Utilizator 2 Vedere 2 Utilizator 3 Vedere n

Schema conceptual

Schema intern

Organizarea fizic a datelor

Baza de date

Fig. 2.1 Arhitectura bazei de date cu 3 nivele

Modul n care utilizatorii percep datele este numit nivel extern. Modul n care SGBD i sistemul de operare percep datele este numit nivel intern. Nivelul conceptual realizeaz att transpunerea ct i independena dorit dintre nivelul extern i cel intern. 2.1.1 Nivelul intern Nivelul intern Reprezentarea fizic a bazei de date pe calculator. Acest nivel descrie CUM sunt stocate datele n baza de date.

Nivelul intern (baza de date fizic) este o colecie de fiiere coninnd datele fizice la care se adaug diverse structuri auxiliare menite s asigure accesul operativ la date. Structurile auxiliare pot fi: directoare, indexuri, pointeri, tabele de dispersie. Modul de organizare a bazei de

date fizice este n mare msur influienat de configuraia echipamentelor hardware care suport baza de date i de sistemul de operare. Schimbarea sistemului de operare sau modificri n configuraia hardware pot atrage modificri ale bazei de date fizice. Dac este satisfcut condiia de independen fizic, aceste modificri n nivelul intern al bazei de date nu vor ataca nivelele superioare ale acesteia. Nivelul intern trateaz chestiuni cum ar fi: alocarea spaiului de stocare pentru date i indexuri descrierea nregistrrilor pentru stocare (cu dimensiunile de stocare pentru date) plasarea nregistrrilor tehnici de comprimare a datelor i de codificare a acestora 2.1.2 Nivelul conceptual Este o vedere general a baz de date. Acest nivel descrie CE date sunt stocate n baz de date i RELAIILE dintre acestea.

Nivelul conceptual

Nivelul conceptual conine structura logic a bazei de date, aa cum este ea vzut de administratorul bazei de date. Fiecare baz de date are un model conceptual propriu prin care sunt numite i descrise toate entitile logice din baza de date mpreun cu legturile dintre acestea. El reprezint o imagine complet a cerinelor organizaiei privind datele. Ex: n descrierea bazei de date a unei intreprinderi pot aprea concepte ca: angajat, produse, furnizor, beneficiar, etc. Modelul conceptual integreaz viziunile tuturor utilizatorilor asupra bazei de date, fiind rezultatul unui compromis ntre cerinele diferiilor utilizatori. Nivelul conceptual reprezint: toate entitile, atributele i relaiile dintre ele constrngeri asupra datelor informaii semnatice asupra datelor informaii privind securitatea i integritatea De reinut c modelul conceptual este o descriere a coninutului de date din baza de date i NU cuprinde nici un fel de referire la modul de memorare a datelor sau la strategia de acces. De ex. descrierea unei entiti trebuie s conin numai tipurile de date (integer, real, character) i lungimea lor (numrul maxim de cifre sau caractere) dar nici o informaie privind stocarea, cum ar fi numrul de octei ocupat. 2.1.3 Nivelul extern Reprezint vederea utilizatorului asupra baz de date. Acest nivel descrie acea parte a bazei de date care este relevant pentru fiecare utilizator.

Nivelul extern

Nivelul extern este cel mai apropiat utilizatorului. Este ceea ce vede acesta din baza de date, sau modul cum vede acesta baza de date. Modelul extern este derivat din cel conceptual dar poate prezenta deosebiri substaniale fa de acesta. Un termen deseori folosit pentru modelul extern este acela de vedere sau viziune. Prin aceste viziuni, utilizatorii au acces doar la pri bine definite din baza de date, fiindu-le ascunse prile care nu intereseaz. Prin modelul extern se

realizeaz independena logic a datelor. Fiecrei viziuni i corespunde o descriere n termenii entitilor logice din modelul conceptual. Diferite vederi pot avea reprezentri diferite ale acelorai date. De ex, un utilizator poate vedea datele calendaristice n format an-lun-zi, altul le poate vedea ca zi-lun-an.Vederile pot include chiar date combinate sau derivate din entiti diferite. 2.2 Limbajele bazelor de date

Limbajele bazelor de date sunt mprite n 2 categorii: limbaje de definire a datelor (DDL) i limbaje de manipulare a datelor (DML). DDL este utilizat pentru a specifica schema bazei de date, iar DML este utilizat pentru citirea i reactualizarea bazei de date. Aceste limbaje sunt numite sublimbaje de date deoarece ele nu includ construcii pentru toate necesitile de calcul, cum sunt cele asigurate de limbajele de nivel nalt. Multe SGBD au o facilitate de ncorporare a sublimbajului ntr-un limbaj de programare de nivel nalt, cum sunt COBOL, Pascal, C, etc. n acest caz, limbajul de nivel nalt se numete limbaj gazd. Pentru a compila fiierul ncorporat, mai nti comenzile specifice sublimbajului de date sunt nlocuite prin apelri de funcii. Apoi fiierul preprocesat este compilat i rezultatul este plasat ntr-un modul obiect, legat legat la o librrie care conine funciile nlocuite. 2.2.1 Limbajul de definire a datelor (DDL)

DDL Este un limbaj descriptiv, care permite administratorului bazei de date sau utilizatorului s descrie i s denumeasc entitile cerute de aplicaie i relaiile care pot exista ntre diferitele entiti. Rezultatul compilrii instruciunilor DDL este un set de tabele stocate n fiiere speciale, denumite global catalog de sistem. Acesta conine meta-datele adic datele care descriu obiectele din baza de date. 2.2.2 DML Limbajul de manipulare a datelor (DML) Asigur un set de procedee ce permit operaii de baz pentru manipularea datelor din baz de date: inserarea de date noi modificri de date regsirea datelor tergerea de date

Limbajele DML pot fi de dou tipuri: procedurale i neprocedurale. procedurale specific modul cum trebuie s fie obinut rezultatul unei instruciuni DML neprocedurale descriu numai ce rezultat trebuie obinut De ex, SQL este un limbaj neprocedural.

2.3 Model de date

Modele de date i modelarea conceptual

Curs 3

Este o colecie integrat de concepte necesare descrierii datelor, relaiilor dintre date i constrngerilor impuse datelor.

Ne putem imagina c un model de date are urmtoarele trei componente: 1. o parte structural, constnd dintr-un set de reguli conform crora sunt construite bazele de date; 2. o parte de manipulare, definind tipurile de operaii care sunt permise asupra datelor 3. un set de reguli de integritate, care garanteaz c datele sunt corecte. Scopul unui model este s reprezinte datele i s le fac nelese. Pentru arhitectura ANSI - SPARC a bazei de date, se pot identifica trei modele de date: 1. un model de date extern, pentru a reprezenta vederea fiecrui utilizator 2. un model de date conceptual, pentru a reprezenta vederea logic, general, care este independent de SGBD 3. un model de date intern, pentru a reprezenta schema conceptual, n aa fel nct s poat fi neleas de SGBD Modelele de date se pot clasifica n trei categorii principale: 1. modele de date bazate pe obiecte 2. modele de date bazate pe nregistrri 3. modele de date fizice Ultima categorie, modelele de date fizice descriu cum sunt stocate datele pe calculator. Reprezint informaii despre structura i ordinea nregistrrilor i cile de acces. Nu exist la fel de multe modele de date fizice ca cele logice, motiv pentru care vom prezenta mai amnunit numai primele dou categorii de modele de date. 2.3.1 Modele de date bazate pe obiecte n modelele de date bazate pe obiecte se utilizeaz concepte ca: entitate, atribut, relaie. O entitate este un obiect distinct (persoan, loc, lucru, concept, eveniment) care va fi reprezentat n baza de date. Un atribut este o proprietate care descrie un anumit aspect al obiectului pe care dorim s-l nregistrm. O relaie este o asociere ntre entiti. Cele mai obinuite modele de date bazate pe obiecte sunt: Entitate Relaie constituie una din tehnicile principale de proiectare conceptual a bazelor de date semantic funcional orientat spre obiecte extinde definiia unei entiti, pentru a include i atributele care descriu starea obiectului i aciunile acestuia, respectiv comportamentul. Se spune c obiectul ncapsuleaz att starea ct i comportamentul

2.3.2

Modele de date bazate pe nregistrri

ntr-un astfel de model, baza de date const dintr-un numr de nregistrri cu format fix, posibil de tipuri diferite. Fiecare tip de nregistrare definete un numr fix de cmpuri, fiecare avnd o lungime fix. Exist 3 tipuri principale de modele de date bazate pe nregistrri relaional n reea au fost realizate cu aproape 10 ani naintea celui relaional, aa nct legturile lor cu conceptele tradiionale de prelucrare a fiierelor sunt mai evidente ierarhic Modelul de date relaional Se bazeaz pe conceptul de relaii matematice Datele i relaiile sunt reprezentate sub form de tabele, fiecare avnd un numr de coloane cu o denumire unic Observm ca modelul de date relaional necesit ca utilizatorul s perceap baza de date ca fiind format din tabele. Dar aceast percepie se aplic numai la structura logic (Nivelul Extern i Nivelul Conceptual din arhitectura pe 3 nivele a bazei de date), nu i structurii fizice, care poate fi implementat utiliznd o varietate de modaliti de stocare. Majoritatea sistemelor moderne sunt bazate pe modelul relaional. Exemplu: presupunem c din baza de date a unei organizaii cu mai multe filiale alegem s reprezentm datele despre filiale i personalul angajat prin dou tabele, cu urmtoarea structur: Filiale
NrFil F3 F4 F5 F6 Adresa Rozelor 25 Stejeri 19 Eroilor 35 Unirii 10 Orasul Timioara Braov Timioara Focani CodPostal Telefon 1700 121212 2200 232323 1700 434343 1500 454545 Fax 121222 232333 434333 454555

Angajai
NrMarca 214 215 216 217 Nume Burcea Gheorghe Turcea Vasile Prenume Ion Alina Elena Valentin Adresa Orasul Lalelelor 12 Timioara Ceti 21 Timioara Varte 8 Braov Grii 32 Timioara Functia manager contabil secretara portar Salariul 5000 4000 3000 200 NrFil F3 F3 F4 F5

Modelul de date n reea Datele sunt reprezentate printr-o colecie de nregistrri Relaiile sunt reprezentate prin direcii Spre deosebire de modelul relaional, aici relaiile sunt modelate explicit prin direcii, care devin pointeri n implementrea propriu-zis. Modelul poate fi asemnat cu o structur de grafuri, cu nregistrrile reprezentate ca noduri i direciile ca muchii. S vedem exemplul de mai sus transpus ntr-un model de date n reea:

F3

Rozelor 25

Timioara

1700 121212 121222 Ion Alina


Lalelelor 12

214 Burcea 215 Gheorghe

Timioara Timioara

manager contabil

5000 F3 4000 F3

Ceti 21

F4

Stejeri 19

Braov

2200 232323 232333 Elena Varte 8 Braov secretara 3000 F4

216 Turcea

F5

Eroilor 35

Timioara

1700 434343 434333 Valentin Grii 32 Timioara portar 200 F5

217 Vasile

F6

Unirii 10

Focani

1500 454545 454555

Modelul de date ierarhic Constituie un tip restrns de model n reea. Datele sunt reprezentate printr-o colecie de nregistrri Relaiile sunt reprezentate prin direcii Permite ca un nod s posede numai un singur printe Poate fi reprezentat ca un graf de tip arbore. S vedem acelai exemplu de mai sus transpus ntr-un model de date ierarhic:

F3

Rozelor 25

Timioara F4 F5

1700 121212 121222 Stejeri 19 Eroilor 35 Braov Timioara F6 2200 232323 232333 1700 434343 434333 Unirii 10 Focani 1500 454545 454555

Modele de date bazate pe nregistrri sunt utilizate pentru a specifica structura general a bazei de date i o descriere de nivel superior a implementrii acesteia. Principalul lor dezavantaj este c nu pun la dispoziie faciliti de specificare explicit a constrngerilor asupra datelor. Modelele relaionale adopt o abordare declarativ pentru procesarea bazei de date (adic specific ce date vor fi regsite), iar modelele n reea i ierarhice adopt o abordare navigaional (specificnd cum vor fi regsite datele).

2.3.3

Modelarea conceptual

Printr-o examinare a arhitecturii cu trei nivele, se poate observa c schema conceptual este inima bazei de date. Ea suport toate vederile externe i este suportat de schema intern. Totui, schema intern este doar o implementare fizic a schemei conceptuale. Schema conceptual trebuie s fie o implementare complet i corect a cerinelor companiei (organizaiei) privind datele. Dac acest lucru nu este realizat, o serie de informaii despre companie vor lipsi sau vor fi reprezentate incorect, ceea ce va crea dificulti n implementarea complet a uneia sau mai multor vederi externe. Modelarea conceptual sau proiectarea conceptual a bazei de date este procesul de construire a unui model de informaii utilizate ntr-o companie, care este independent de detaliile de implementare, cum ar fi sistemul SGBD, programele aplicaie, limbajele de programare sau orice alte tipuri de consideraii fizice. Acest model de date se numete model de date conceptual. 2.4 Funciile unui SGBD

Au fost stabilite 8 servicii pe care trebuie s le furnizeze un SGBD complet. 1. stocarea, regsirea i reactualizarea datelor. Aceasta este funcia fundamental a unui SGBD. Pentru asigurarea ei, sistemul SGBD trebuie s ascund fa de utilizator detaliile privind implementarea fizic intern (organizarea fiierelor i structurile de stocare). 2. catalog accesibil utilizatorului 3. asigurarea tranzaciilor Un SGBD trebuie s furnizeze un mecanism care s garanteze c sunt efectuate toate reactualizrile corespunztoare unei anumite tranzacii sau c nu se efectueaz nici una. O tranzacie const ntr-o serie de aciuni realizate de un singur utilizator sau un program aplicaie, prin care se acceseaz sau se schimb coninutul bazei de date. 4. servicii de control concurente Un SGBD trebuie s furnizeze un mecanism care s garanteze c baza de date este corect reactualizat, atunci cnd mai muli utilizatori efectueaz simultan astfel de operaii 5. servicii de reconstituire Un SGBD trebuie s furnizeze un mecanism de reconstituire a bazei de date dac aceasta este deteriorat ntr-un fel oarecare. 6. servicii de autorizare Un SGBD trebuie s furnizeze un mecanism care s garanteze c numai utilizatorii autorizai pot accesa baza de date. 7. suport pentru comunicarea datelor Un SGBD trebuie s poat fi integrat unui software de comunicaie. 8. servicii de integritate Un SGBD trebuie s furnizeze mijloace care s asigure c, att datele din baza de date, ct i modificrile acestora respect anumite reguli. Integritatea se refer la corectitudinea i coerena datelor stocate. 2.5 Componentele software ale unui SGBD

Din punct de vedere software, sistemele SGBD sunt foarte complexe i sofisticate, deoarece modulele software din componena unui SGBD trebuie s permit furnizarea tuturor serviciilor analizate n paragraful precedent. Structura componentelor software ale unui SGBD nu poate fi generalizat, deoarece ea variaz foarte mult de la un sistem de gestiune la altul.

Totui este util s ncercm o trecere n revist a componentelor soft i a relaiilor dintre ele. n acest scop vom prezenta o posibil arhitectur pentru un SGBD. Un SGBD este partiionat n diverse componente software (module), responsabile de cte o operaie specific. Cteva dintre funciile SGBD sunt susinute de sistemul de operare. Dar sistemul de operare ofer numai serviciile de baz, iar SGBD trebuie construit peste acesta. Principalele componente software ale unui mediu SGBD sunt reprezentate n Fig. 2.2. S explicitm semnificaia urmtoarelor componente: Procesorul de interogare transform interogrile ntr-o serie de instruciuni de nivel jos, adresate administratorului bazei de date. Administratorul bazei de date realizeaz interfaa bazei de date cu programele aplicaie i interogrile lansate de utilizatori. Administratorul de fiiere manipuleaz fiierele de stocare aflate la baz i administreaz alocarea spaiului de stocare pe disc. El stabilete i menine lista de structuri i indexuri definite n schema intern. El nu gestioneaz direct intrrile i ieirile de date, ci transmite cererea ctre o metod de acces corespunztoare, care fie citete datele din bufferul sistemului, fie le scrie n acesta. Preprocesorul DML. Acest modul convertete instruciunile DML ncorporate ntrun program aplicaie n apelri de funcii standard din limbajul gazd. Preprocesorul DML trebuie s interacioneze cu procesorul de interogare, pentru a genera codul corespunztor. Compilatorul DDL transform instruciunile DDL ntr-un set de tabele care conin meta-datele. Aceste tabele sunt ulterior stocate n catalogul de sistem, iar informaiile de control sunt stocate n anteturile fiierelor de date. Administratorul de catalog gestioneaz accesul i ntreinerea catalogului de sistem. Catalogul de sistem este accesat de majoritatea componentelor sistemului SGBD.

Fig. 2.2 Componentele principale ale unui SGBD

2.6

Arhitecturi multiutilizator

Pentru implementarea SGBD multiutilizator, uzual se folosesc trei tipuri de arhitecturi, pe care le vom prezenta n continuare. 2.6.1 Teleprocesarea

Arhitectura tradiional pentru sistemele multiutilizator a fost teleprocesarea, la care exist un calculator cu o singur unitate CPU i un numr de terminale, aa cum este ilustrat n Fig. 2.3. Toat procesarea este efectuat pe acelai calculator. De obicei, terminalele utilizatorilor sunt netiutoare, incapabile s funcioneze singure. Ele sunt legate la calculatorul central. Prin intermediul subsistemului de control al comunicaiilor din sistemul de operare, terminalele trimit mesaje la programele aplicaie ale utilizatorilor, care la rndul lor, utilizeaz serviciile sistemului SGBD. n acelai mod, mesajele sunt transmise napoi la terminalul utilizatorului. Din pcate, aceast arhitectur a plasat o povar teribil asupra calculatorului central, care, pe lng rularea programelor aplicaie PA i a sistemului SGBD, trebuie s preia i o cantitate semnificativ de munc din partea terminalelor (cum ar fi formatarea datelor pentru afiarea pe ecran).

PA SGBD

Fig. 2.3 Teleprocesarea

O dat cu dezvoltarea calculatoarelor personale de nalt performan i cu dezvoltarea reelelor de comunicaie dintre calculatoare, n industrie exist o tendin major spre miniaturizare, care nseamn nlocuirea calculatoarelor mainframe scumpe cu reele de calculatoare personale - mai avantajoase ca pre - care obin rezultate identice sau chiar superioare. Aceast tendin a dat natere la urmtoarele dou arhitecturi - fiier-server i clientserver - care vor fi analizate n continuare. 2.6.2 Arhitectura fiier server

ntr-un mediu fiier-server, procesarea este distribuit n reea, de obicei, o reea local (LAN). Arhitectura fiier-server cuprinde fiierele cerute de programele aplicaii PA i sistemul SGBD. Totui, aplicaiile i sistemul SGBD sunt executate pe fiecare staie de lucru, solicitnd, cnd este necesar, fiiere de la serverul de fiiere, aa cum este ilustrat n Fig. 2.4.
PA SGBD PA SGBD PA SGBD

Fig. 2.4 Arhitectura fiier - server

In acest mod, serverul de fiiere acioneaz pur i simplu ca o unitate de hard-disc partajat. Sistemul SGBD de pe fiecare staie de lucru trimite serverului de fiiere cererile pentru toate datele necesare, care sunt stocate pe disc. Aceast abordare poate genera un trafic intens pe reea, ceea ce poate duce la apariia unor probleme privind performanele. De exemplu, s considerm cererea unui utilizator, care conine numele membrilor personalului care lucreaz la filiala din 163 Main St. n limbajul SQL (a se vedea Capitolul 13) aceast cerere este exprimat astfel: SELECT Prenume, Nume FROM Filiala b, Personal s WHERE b.nrFil=s.nrPer AND b.Strada='163 Main St';

Cum serverul de fiiere nu cunoate limbajul SQL, sistemul SGBD trebuie s-i cear fiierele corespunztoarere relaiilor Filiala i Personal n locul numelor membrilor personalului care satisfac interogarea. Rezult c arhitectura fisier-server are trei dezavantaje principale: 1. Exist un trafic intens pe reea; 2. Este necesar o copie complet a sistemului SGBD pe fiecare staie de lucru; 3. Controlul simultaneitii, reconstituirii i integritii este mult mai complex, deoarece acelai fisier poate fi accesat de mai multe sisteme SGBD. 2.6.3 Arhitectura client server Arhitectura client - server a fost dezvoltat pentru a depi dezavantajele primelor dou abordri. Arhitectura client - server se refer la modul n care interacioneaz componentele de software pentru a forma un sistem: exist un proces client, care necesit cteva resurse, i un server, care ofer resurse. Nu exist nici o cerin ca att clientul, ct i serverul s se afle pe acelai calculator. In practic, se obinuiete s se plaseze serverul pe un sit din reeaua local i clienii pe alte situri. In Fig. 2.5 se ilustreaz arhitectura client - server, iar n Fig. 2.6 sunt prezentate cteva combinaii posibile ale topologiei client server.

PA PA PA

Fig. 2.5 Arhitectura client server

n contextul bazelor de date, clientul administreaz interfaa cu utilizatorul i logica aplicaiei, acionnd ca o staie de lucru, sofisticat, pe care sunt executate aplicaiile bazei de date. Clientul preia cererea utilizatorului, verific sintaxa i genereaz cererea pentru baza de date n limbajul SQL sau n alt limbaj de baze de date, adecvat logicii aplicaiei. Pe urm, transmite mesajul serverului, ateapt un rspuns i l formateaz pentru utilizatorul final. Serverul accept i proceseaz cererea pentru baza de date, dup care transmite rezultatul napoi clientului. Procesarea implic: 1. 2. 3. 4. 5. verificarea autorizrii asigurarea integritii meninerea catalogului de sistem execuia proceselor de interogare i reactualizare asigurarea controlului simultaneitii i reconstituirii.

Operaiile clientului i serverului sunt prezentate n Tabelul 2.1. Acest tip de arhitectur are urmtoarele avantaje: permite un acces mai larg la bazele de date existente; are performane crescute - dac clienii i serverul se afl pe calculatoare diferite, atunci diferite unitti CPU pot procesa aplicaii n paralel; reglarea serverului este mai uor de efectuat, dac singura sa sarcin este de a efectua prelucrarea bazei de date; reduce costurile dispozitivelor hardware - numai serverul necesit o capacitate de stocare i o putere de prelucrare suficiente pentru a stoca i gestiona baza de date; reduce costurile comunicaiilor - aplicaiile execut o parte din operaii la client, care trimite prin reea numai cererea de acces la baza de date, ceea ce face ca pe reea s circule mai putine date; mrete coerena - serverul poate trata verificrile de integritate, deoarece constrngerile trebuie definite i validate ntr-un singur loc, fr s fie necesar ca fiecare program aplicaie s execute propriile verificri; se transpune destul de natural ntr-o arhitectur de sisteme deschise.

Observaie Cu toate c arhitectura client-server poate fi utilizat pentru a oferi sisteme SGBD distribuite, totusi ea nsi nu constituie un sistem SGBD distribuit. Sistemele SGBD distribuite vor fi ulterior analizate n detaliu. Atunci se va examina o extensie a arhitecturii client-server pe dou etaje care scindeaz funcionalitatea clientului lrgit n dou. n arhitectura client-server pe trei etaje, clientul restrns manevreaz numai interfaa cu utilizatorul, n timp ce stratul de mijloc manevreaz logica aplicaiilor. Al treilea strat l constituie serverul bazei de date. Aceast arhitectur pe trei etaje s-a dovedit a fi mai convenabil pentru unele medii, cum ar fi Internet i reelele intranet ale companiilor, unde un browser Web poate fi utilizat drept client.
Tabelul 2.1 Sumar al funciilor client - server

Client Administreaz interfaa cu utilizatorul Accept i verific sintaxa intrrilor utilizatorilor Proceseaz aplicaiile Genereaz cerinele pentru baza de date i le transmite serverului Transmite rspunsul napoi la utilizator

Server Primete i proceseaz cerinele clienilor pentru baza de date Verific autorizarea Asigur respectarea contrngerilor de integritate Efectueaz procesarea interogare/reactualizare i transmite clientului rspunsul ntreine catalogul de sistem Ofer acces simultan la baza de date Ofer controlul reconstituirii

Fig. 2.6 Configuraii posibile client server a) un singur client i un singur server b) mai muli clieni i un singur server c) mai muli clieni i mai multe servere

2.7

Catalogul de sistem

n paragraful 2.4 s-a stabilit c un sistem SGBD trebuie s posede un catalog de sistem sau un dicionar de date accesibil utilizatorilor. n ncheierea acestui capitol despre mediul bazelor de date, vom examina mai detaliat cataloagele de sistem. Catalogul de sistem Este un depozit de informaii care descriu datele din baza de dateadic meta-datele sau datele despre date. Catalogul de sistem SGBD este una din componentele de baz ale sistemului. Volumul de date coninut i modul n care sunt utilizate informaiile variaz de la sistem la sistem. De regul, catalogul de sistem stocheaz: denumirile, tipurile i dimensiunile articolelor de date denumirile relaiilor constrngerile de integritate asupra datelor numele utilizatorilor autorizai care au acces la date articolele de date pe care le poate accesa fiecare utilizator i tipurile de acces

permise schemele externe, conceptuale i interne i transpunerile dintre ele statistica utilizrii, cum ar fi frecvena tranzaciilor i contorizarea numrului de accesri ale obiectelor din baza de date

Atenie: termenul de dicionar de date este adesea utilizat pentru a face referire la un sistem software mai general dect catalogul unui sistem SGBD. Un sistem de dicionare de date poate s fie activ sau pasiv. Un sistem activ este ntotdeauna coerent cu structura bazei de date, deoarece este ntreinut automat de sistem. n schimb, un sistem pasiv poate s nu fie coerent cu baza de date, deoarece schimbrile sunt iniiate de utilizatori. Dac dicionarul de date este o parte a sistemului SGBD, atunci va fi folosit denumirea de dicionar de date integrat. Un dicionar de date autonom are propriul su sistem SGBD specializat. Un dioionar de date autonom poate fi preferabil n stadiile iniiale ale proiectrii, deoarece acesta ntrzie ct mai mult posibil decizia asupra unui anumit sistem SGBD al organizaiei. Totusi, exist dezavantajul c, o dat ce sistemul SGBD a fost selectat si baza de date implementat, este mult mai difiicl s se menin dicionarul de date autonom coerent cu baza de date. Aceast problem ar putea fi minimizat dac ar fi posibil transferarea dicionarului de date din proiectare n catalogul de sistem SGBD. S analizm pe scurt un standard pentru dicionarul de date. 2.7.1 Sistemul de informatii al dicionarului de resurse (IRDS)1 n multe sisteme, dicionarul de date este o component intern a sistemului SGBD, care stocheaz numai infonnaiile direct legate de baza de date. Totui, datele coninute de sistemul SGBD reprezint, de obicei, numai o parte a cerinelor informaionale totale ale unei organizaii. De regul, exist informaii adiionale coninute n alte instrumente, cum ar fi CASE, instrumentele de documentare i instrumentele de configurare i administrare a proiectului. Fiecare dintre aceste instrumente va avea propriul dicionar de date intern, care poate fi ascesat de alte instrumente externe. Din pcate, nu a existat nici o modalitate general de partajare a acestor seturi diferite de informaii ntre diversele grupuri de utilizatori sau aplicaii. Recent, s-a fcut o tentativ de a standardiza interfaa la dicionarele de date, pentru a le face mai accesibile i cu posibiliti superioare de partajare. Aceasta a condus la dezvoltarea sistemului de informaii al dicionarului de resurse (IRDS). Un sistem IRDS este un instrument software care poate fi utilizat pentru a controla i documenta o resurs de informaii a unei organizaii. El ofer o definiie pentru tabelele care conin dicionarul de date i operaiile care pot fi utilizate pentru accesarea acestor tabele. Operaiile ofer o metod coerent de accesare a dictionarului de date i o modalitate de transferare a definiiilor datelor de la un dicionar la altul. De exemplu, informaiile stocate ntr-un dicionar de date de tip IRDS al unui sistem DB2 pot fi transferate la un dicionar de date de acelai tip al unui sistem ORACLE sau pot fi accesate de o aplicaie DB1, utiliznd serviciile IRDS. Unul dintre punctele forte ale sistemului IRDS l reprezint extensibilitatea dicionarului de date. Astfel, dac un utilizator al unui sistem SGBD dorete s stocheze definiiile corespunztoare unui nou tip de infonnaie ntr-un instrument - de exemplu rapoartele de administrare a proiectelor dintr-un sistem SGBD, - atunci sistemul IRDS al SGBD poate fi extins pentru a include aceast informaie. Sistemul IRDS a fost adoptat ca standard de ctre Organizaia Internaional pentru Standardizare (ISO). Standardele IRDS definesc un set de reguli referitoare la modul n care sunt stocate i accesate infonnaiile n dicionarul. de date. Sistemul IRDS are trei obiective: extensibilitatea datelor;
1

Acronim pentru Information Resource Dictionary System. 2 International Organization for Standardization

integritatea datelor; accesul controlat la date. Sistemul IRDS se bazeaz pe o interfa de servicii, alctuit dintr-un set de funcii care pot fi apelate pentru a accesa dicionarul de date. Interfaa de servicii poate fi invocat de urmtoarele componente ale interfeei cu utilizatorul: tablou; limbaj de comand; fiiere de export/import; programe aplicaie. Interfaa cu tabloul const ntr-un set de tablouri saa ecrane, fiecare dintre ele oferind acces la un set prescris de servicii. Aceast interfa poate fi similar limbajului QBE (Query-byExample) i permite utilizatorului s rsfoiasc i s modifice datele din dicionar. Interfaa cu limbajul de comand (CLI2) const ntr-un set de comenzi sau instruciuni, care permit utilizatorului s efectueze operaii asupra datelor din dicionar. Interfaa CLI poate fi invocat interactiv de la un terminal sau poate fi ncorporat ntr-un limbaj de programare de nivel nalt. Interfaa export/import genereaz un fiier care poate fi mutat ntre sistemele de tip IRDS. Standardul definete un format general pentru interschimbarea de informaii. Standardul nu necesit ca baza de date a dicionarului s se conformeze unui anumit model de date, astfel nct interfaa cu serviciile IRDS poate s conecteze sisteme SGBD heterogene (vezi fig. Fig. 7).

Fig. 7 Interfaa cu serviciile IRDS.

Acronim pentru Command Language Interface.