Cap.

2 ARHITECTURA SISTEMELOR DE BAZE DE DATE Arhitectura este divizat pe trei niveluri numite, de regula, nivel intern, extern, respectiv conceptual. n linii mari: Nivelul intern (cunoscut i sub denumirea de nivel de stocare) este cel aflat cel mai aproape de mediul de stocare fizic adic, se refer la modul n care sunt stocate datele n sistem. Nivelul extern (cunoscut i sub denumirea de nivel logic al utilizatorului) este cel aflat cel mai aproape de utilizatori adic, se refer la modul n care sunt vizualizate datele de ctre utilizatorii individuali. Nivelul conceptual (cunoscut i sub denumirea de nivel logic colectiv sau, uneori, pur i simplu ca nivel logic) este un nivel intermediar ntre celelalte dou. Observm c nivelul extern se refer la percepiile utilizatorilor individuali, n timp ce nivelul conceptual se refer la percepia comun a tuturor utilizatorilor. Majoritatea utilizatorilor nu sunt interesai de ntreaga baz de date ci doar de o poriune restrns din aceasta; astfel, vor exista mai multe vederi externe diferite, fiecare format dintr-o reprezentare mai mult sau mai puin abstract a unei poriuni din baza de date complet, i exact o vedere conceptual, format dintr-o reprezentare abstract similar ntregii baze de date. Apoi, va exista exact o vedere intern, reprezentnd baza de date aa cum este stocat intern. Nivelul extern Nivelul extern este nivelul utilizatorului individual. Utilizatorul poate fi ori un programator de aplicaii, ori un utilizator final cu orice nivel de detaliere. (Administratorul DBA este un caz special important; spre deosebire de ali utilizatori, acesta va trebui s fie interesat i de nivelul conceptual i de cel intern.) Fiecare utilizator are la dispoziie un limbaj: Pentru programatorul de aplicaii, acesta va fi un limbaj de programare convenional (de exemplu, Java, C++ etc.). Pentru utilizatorul final, limbajul va fi ori unul de interogare (probabil SQL), ori unul specializat eventual condus prin formulare sau meniuri adaptat cerinelor utilizatorului respectiv. Aceste limbaje vor include un sublimbaj de date adic un subset al limbajului complet care se refer n mod specific la obiectele i operaiile bazei de date. Sublimbajul de date (prescurtat DSL) se spune c este nglobat n limbajul gazd corespunztor. Limbajul gazd este responsabil de furnizarea unor faciliti care nu sunt specifice bazelor de date, cum ar fi variabilele locale, operaiile de calcul, logica ramificat .a.m.d. Unul dintre sublimbajele de date care este acceptat de ctre aproape toate sistemele curente, este SQL. Majoritatea acestor sisteme permit ca limbajul SQL s fie folosit att interactiv ca limbaj de interogare autonom ct i nglobat n alte limbaje, cum ar fi Java, C++ etc. n principiu, orice sublimbaj de date este, de fapt, o combinaie a cel puin dou limbaje subordonate: un limbaj de definire a datelor (DDL), care susine definirea sau declararea obiectelor bazei de date i un limbaj de manipulare a datelor (DML), care susine prelucrarea sau manipularea acestor obiecte.

Utilizatorul individual va fi interesat numai e o poriune din ntreaga baz de date; mai mult chiar, vederea utilizatorului asupra poriunii respective va fi, n general, oarecum abstract, comparativ cu modul n care datele sunt stocate fizic. Termenul folosit pentru vederea unui utilizator individual este vedere extern. Astfel, vederea extern reprezint coninutul bazei de date vzut de un anumit utilizator. De exemplu, un utilizator de la Departamentul Resurse Umane ar putea privi baza de date ca pe o colecie de apariii ale nregistrrilor despre departamente i angajai, fr a cunoate apariiile nregistrrile despre furnizori i componente, vizualizate de ctre cei de la Departamentul Aprovizionare. n general, vederea extern este format din mai multe apariii ale tipurilor de nregistrri externe (nu neaprat acelai lucru ca o nregistrare stocat). Fiecare vedere extern este definit prin intermediul unei scheme externe, care, n esen, este format din definiiile fiecruia dintre tipurile de nregistrri externe din vederea extern respectiv. Schema extern este scris folosind poriunea DDL din sublimbajul de date al utilizatorului (de aceea, acesta este numit uneori limbaj DDL extern). Nivelul conceptual Vederea conceptual este o reprezentare a ntregului coninut informaional al bazei de date, ntr-o form care este oarecum abstract comparativ cu modul n care datele sunt stocate fizic. De asemenea, n general, va fi substanial diferit de modul n care sunt vizualizate datele de ctre utilizatori. n mare, intenia este ca vederea conceptual s fie o vedere a datelor aa cum sunt ele n realitate, nu a modului n care sunt forai s le vad utilizatorii. Vederea extern este format din mai multe apariii ale tipurilor de nregistrri conceptuale. De exemplu, poate fi format dintr-o colecie de apariii ale nregistrrilor despre departament, plus o colecie a apariiilor nregistrrilor despre angajai, plus o colecie a apariiilor nregistrrilor despre componente etc. nregistrarea conceptual nu este neaprat identic nici cu nregistrarea extern, pe de o parte, nici cu nregistrarea stocat, pe de alt parte. Vederea conceptual este definit prin intermediul schemei conceptuale, care include definiiile fiecruia dintre diversele tipuri de nregistrri conceptuale. Schema conceptual este scris folosind un alt limbaj de definire a datelor, limbajul DDL conceptual. Dac se are n vedere realizarea independenei fizice de date, atunci aceste definiii DDL conceptuale nu trebuie s implice deloc vreo consideraie privind reprezentarea fizic sau tehnica de acces acestea trebuie s fie numai definiii ale coninutului informaional. Astfel, n schema conceptual nu trebuie s existe vreo referire la reprezentarea cmpului stocat, secvena nregistrrii stocate, indexuri, pointeri sau alte detalii privind memoria i accesul. Dac schema conceptual este cu adevrat independent de date n acest mod, atunci schemele externe care sunt definite n funcie de schema conceptual vor fi, de asemenea, independente de date. Astfel, vederea conceptual reprezint o vedere a ntregului coninut al bazei de date iar schema conceptual este o definiie a acestei vederi. Definiiile din schema conceptual sunt create astfel nct s includ mult mai multe caracteristici suplimentare, cum ar fi restriciile de securitate i de integritate.

Nivelul intern Al treilea nivel al arhitecturii este cel intern. Vederea intern este o reprezentare de nivel inferior a ntregii baze de date; este format din mai multe apariii ale tipurilor de nregistrri interne (nregistrri stocate) Vederea intern este descris prin intermediul schemei interne, care nu numai c definete diversele tipuri de nregistrri stocate, ci specific i indexurile care exista, modul n care sunt reprezentate cmpurilor stocate, n ce secven fizic se afl nregistrrile stocate etc. aceast schem intern este scris folosind un alt limbaj de definire a datelor: limbajul DDL intern. Corespondene n afar de cele trei niveluri, arhitectura din Figura 2.1 presupune anumite corespondene n general, o coresponden conceptual / intern i mai multe corespondene extern / conceptual. Corespondena conceptual intern definete relaia dintre vederea conceptual i baza de date stocat; ea specific modul n care nregistrrile i cmpurile conceptuale sunt reprezentate la nivel intern. Dac structura bazei de date stocate este modificat adic, dac este efectuat o schimbare a definiiei structurii de stocare atunci corespondena conceptual intern trebuie modificat n consecin, astfel nct schema conceptual s rmn invariabil. Cu alte cuvinte, efectele unor astfel de modificri trebuie izolate sub nivelul conceptual, pentru a menine independena fizic de date. Corespondena extern conceptual definete relaia dintre o anumit vedere extern i vederea conceptual. n general, diferenele care pot exista ntre aceste dou niveluri sunt analoge celor care pot exista ntre vederea conceptual i baza de date stocat. De exemplu, cmpurile pot avea diverse tipuri de date; numele cmpurilor i nregistrrilor pot fi schimbate; mai multe cmpuri conceptuale pot fi combinate ntr-un singur cmp extern .a.m.d. Pot exista simultan oricte vederi externe; orici utilizatori pot partaja o vedere extern dat; diversele vederi externe se pot suprapune. La fel cum corespondena conceptual intern reprezint cheia obinerii independenei fizice de date, tot aa corespondenele extern conceptual sunt cheia independenei logice de date. Dup cum am artat n Capitolul 1, sistemul prezint independen fizic de date dac utilizatorii i programele acestora sunt imune fa de modificrile din structura fizic a bazei de date stocate. Similar, sistemul prezint independen logic de date dac utilizatorii i programele acestora sunt imune i fa de modificrile din structura logica a bazei de date (ceea ce nseamn modificrile la nivel conceptual). n afar de cele de mai sus, majoritatea sistemelor permit definirea anumitor vederi externe n funcie de altele (practic, prin intermediul corespondenelor extern extern), fr a necesita ntotdeauna o definiie explicit a corespondenei cu nivelul conceptual. Utilizator A1 Utilizator A2 Utilizator B1 Utilizator B2 Utilizator B3

Limbajul gazdei + DSL

Limbajul gazdei + DSL

Limbajul gazdei + DSL

Limbajul gazdei + DSL

Limbajul gazdei + DSL

Schema extern A

Vederea extern A

Schema extern B

Vederea extern B

Corespondena extern/conceptual pentru A

Corespondena extern/conceptual pentru B

Schema conceptual

Vederea conceptual

Corespondena conceptual/intern

Sistemul de gestiune a bazelor de date (SGBD)

Definiia structurii de stocare (schema intern)

Baza de date stocat (vedere intern)

Figura 2.3 Arhitectura sistemului de baze de date

Administratorul bazei de date Dup cum am artat n Capitolul 1, administratorul datelor (DA) este persoana care ia decizii strategice iar administratorul bazei de date (DBA) este persoana care ofer suportul tehnic necesar pentru implementarea acestor decizii. Astfel, administratorul DBA este responsabil de controlul general al sistemului, la nivel tehnic. Acum putem descrie ceva mai detaliat cteva din sarcinile administratorului DBA. Definirea schemei conceptuale

Sarcina administratorului de date este de a decide exact ce informaii vor fi pstrate n baza de date cu alte cuvinte, s identifice entitile de interes pentru ntreprindere i informaiile care vor fi nregistrate despre acestea. De obicei, acest proces este numit proiectare logic a bazei de date (proiectare conceptual). Dup ce administratorul de date a decis astfel care va fi coninutul bazei de date la nivel abstract, administratorul DBA va crea schema conceptual corespunztoare, folosind limbajul DDL conceptual. n practic, s-ar putea ca lucrurile s nu fie att de clare cum sugereaz observaiile de mai sus. n unele cazuri, administratorul de date poate crea direct schema conceptual; n altele, administratorul DBA poate realiza proiectarea logic. Definirea schemei interne De asemenea, administratorul DBA trebuie s decid cum vor fi reprezentate datele n baza de date stocat. De obicei, acest proces este numit proiectare fizic a bazei de date. Dup ce a realizat proiectarea fizic, administratorul DBA trebuie s creeze schema intern corespunztoare, folosind limbajul DDL intern. n plus, trebuie s defineasc corespondena conceptual intern asociat. Legtura cu utilizatorii Sarcina administratorului DBA este de a menine legtura cu utilizatorii, pentru a garanta c datele de care acetia au nevoie sunt disponibile i pentru a scrie schemele externe necesare, folosind limbajul DDL extern. n plus, trebuie definite i corespondenele extern conceptuale respective. Alte aspecte ale funciei de realizare a legturii cu utilizatorii cuprind documentarea proiectrii aplicaiilor, furnizarea educaiei tehnice, asistent n identificarea i soluionarea problemelor i alte servicii profesioniste similare. Definirea restriciilor de securitate i de integritate Restriciile de securitate i de integritate pot fi privite ca pri ale schemei conceptuale. Limbajul DDL conceptual trebuie s cuprind faciliti pentru specificarea acestor restricii. Definirea politicilor de vidare i de refacere n cazul unei deteriorri a oricrei poriuni din baza de date cauzat, de exemplu, de o eroare uman sau de o cdere a unui element de hardware sau a sistemului de operare este esenial ca datele respective s poat fi remediate, cu o ntrziere minim i cu un efect ct mai mic posibil asupra restului sistemului. Administratorul DBA trebuie s defineasc i s implementeze o schem adecvat de control al avariilor care, de regul, presupune: a) Descrcarea sau vidarea periodic a bazei de date pe dispozitivul de stocare de siguran. b) Rencrcarea sau refacerea bazei de date conform cu cea mai recent vidare, atunci cnd este necesar. Monitorizarea performanelor i rspunsul la modificarea cerinelor Administratorul DBA este responsabil de organizarea sistemului astfel nct s obin performanele care sunt cele mai bune pentru ntreprindere i de efectuarea modificrilor adecvate adic reglarea, pe msur ce se schimb cerinele. De exemplu, ar putea fi necesar ca, din cnd n cnd, s se reorganizeze baza de date stocat pentru a garanta c nivelul performanelor rmne n limitele acceptabile. Sistemul de gestiune a bazelor de date

Acum vom prezenta puin mai detaliat funciile sistemului SGBG. Aceste funcii cuprind suportul pentru cel puin urmtoarele aspecte: Definiia datelor Sistemul SGBD trebuie s fie capabil s accepte definiiile datelor (schemele externe, schema conceptual, schema intern i toate corespondenele asociate) n form-surs i sa le transforme n forma-obiect adecvat. Cu alte cuvinte, sistemul SGBD trebuie s includ componenta procesorul DDL sau compilatorul DDL, pentru fiecare dintre diversele limbaje de definire a datelor (DDL). Manipularea datelor Sistemul SGBD trebuie s fie capabil s manipuleze cerinele de consultare, actualizare sau tergere a datelor existente n baza de date sau s adauge noi date n baza de date. Cu alte cuvinte, sistemul SGBD trebuie s includ o component de forma unui procesor DML sau compilator DML, care s trateze limbajul de manipulare a datelor (DML). Optimizarea i execuia Cererile DML trebuie s fie prelucrate de ctre un optimizator, al crui scop este s determine o modalitate eficient de implementare a cererii. Securitatea i integritatea datelor Sistemul SGBD trebuie s monitorizeze cererile utilizatorilor i s resping orice nclcare a restriciilor de securitate i de integritate definite de ctre administratorul DBA. Refacerea datelor i concurena Sistemul SGBD - sau, mai probabil, o alt component software legat de acesta, numit manager de tranzacii sau monitor TP trebuie s impun anumite elemente de control al refacerii i al concurenei. Dicionarul de date Sistemul SGBD trebuie s pun la dispoziie o funcie pentru dicionarul de date. Dicionarul de date poate fi privit ca o adevrat baz de date (dar mai degrab o baz de date pentru sistem dect pentru utilizator). Dicionarul conine date despre date (numite uneori i metadate sau descriptori) adic definiii ale altor obiecte din sistem, n loc de simple date brute. n particular, toate diversele scheme i corespondene (externe, conceptuale etc.) i toate diversele restricii de securitate i de integritate vor fi stocate n dicionar, att sub form surs ct i sub form de obiect. Un dicionar complet va cuprinde i multe informaii suplimentare artnd, de exemplu, ce programe utilizeaz diversele pri ale bazei de date, ce utilizatori cer rapoarte .a.m.d. Desigur c trebuie s fie posibil s se interogheze dicionarul la fel ca orice baz de date, astfel nct, de exemplu, s se poat afla ce programe i/sau utilizatori este probabil s fie afectai de o modificare propus a sistemului. Performanele Se subnelege c sistemul SGBD trebuie s ndeplineasc toate sarcinile ntr-un mod ct mai eficient posibil.