ARHITECTURA SISTEMELOR DE BAZE DE DATE
Arhitectura este divizata pe trei niveluri numite, de regula, nivel intern, extern, respectiv conceptual. Īn linii mari:
Nivelul intern (cunoscut si sub denumirea de nivel de stocare) este cel aflat cel mai aproape de mediul de stocare fizica - adica, se refera la modul īn care sunt stocate datele īn sistem.
Nivelul extern (cunoscut si sub denumirea de nivel logic al utilizatorului) este cel aflat cel mai aproape de utilizatori - adica, se refera la modul īn care sunt vizualizate datele de catre utilizatorii individuali.
Nivelul conceptual (cunoscut si sub denumirea de nivel logic colectiv sau, uneori, pur si simplu ca nivel logic) este un nivel intermediar īntre celelalte doua.
Observam ca nivelul 444h78e extern se refera la perceptiile utilizatorilor individuali, īn timp ce
nivelul conceptual se refera la perceptia comuna a tuturor utilizatorilor. Majoritatea utilizatorilor nu sunt interesati de īntreaga baza de date ci doar de o portiune restrānsa din aceasta; astfel, vor exista mai multe "vederi externe" diferite, fiecare formata dintr-o reprezentare mai mult sau mai putin abstracta a unei portiuni din baza de date completa, si exact o "vedere conceptuala", formata dintr-o reprezentare abstracta similara īntregii baze de date. Apoi, va exista exact o "vedere interna", reprezentānd baza de date asa cum este stocata intern.
Nivelul extern este nivelul utilizatorului individual. Utilizatorul poate fi ori un programator de aplicatii, ori un utilizator final cu orice nivel de detaliere. (Administratorul DBA este un caz special important; spre deosebire de alti utilizatori, acesta va trebui sa fie interesat si de nivelul conceptual si de cel intern.)
Fiecare utilizator are la dispozitie un limbaj:
Pentru programatorul de aplicatii, acesta va fi un limbaj de programare conventional (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 cerintelor utilizatorului respectiv.
Aceste limbaje vor include un sublimbaj de date - adica un subset al limbajului complet care se refera īn mod specific la obiectele si operatiile bazei de date. Sublimbajul de date (prescurtat DSL) se spune ca este īnglobat īn limbajul gazda corespunzator. Limbajul gazda este responsabil de furnizarea unor facilitati care nu sunt specifice bazelor de date, cum ar fi variabilele locale, operatiile de calcul, logica ramificata s.a.m.d. Unul dintre sublimbajele de date care este acceptat de catre aproape toate sistemele curente, este SQL. Majoritatea acestor sisteme permit ca limbajul SQL sa fie folosit atāt interactiv - ca limbaj de interogare autonom - cāt si īnglobat īn alte limbaje, cum ar fi Java, C++ etc.
Īn principiu, orice sublimbaj de date este, de fapt, o combinatie a cel putin doua limbaje subordonate: un limbaj de definire a datelor (DDL), care sustine definirea sau "declararea" obiectelor bazei de date si un limbaj de manipulare a datelor (DML), care sustine prelucrarea sau "manipularea" acestor obiecte.
Utilizatorul individual va fi interesat numai e o portiune din īntreaga baza de date; mai mult chiar, vederea utilizatorului asupra portiunii respective va fi, īn general, oarecum abstracta, comparativ cu modul īn care datele sunt stocate fizic. Termenul folosit pentru vederea unui utilizator individual este vedere externa. Astfel, vederea externa reprezinta continutul bazei de date vazut de un anumit utilizator. De exemplu, un utilizator de la Departamentul Resurse Umane ar putea privi baza de date ca pe o colectie de aparitii ale īnregistrarilor despre departamente si angajati, fara a cunoaste aparitiile īnregistrarile despre furnizori si componente, vizualizate de catre cei de la Departamentul Aprovizionare.
Īn general, vederea externa este formata din mai multe aparitii ale tipurilor de īnregistrari externe (nu neaparat acelasi lucru ca o īnregistrare stocata).
Fiecare vedere externa este definita prin intermediul unei scheme externe, care, īn esenta, este formata din definitiile fiecaruia dintre tipurile de īnregistrari externe din vederea externa respectiva. Schema externa este scrisa folosind portiunea DDL din sublimbajul de date al utilizatorului (de aceea, acesta este numit uneori limbaj DDL extern).
Nivelul conceptual
Vederea conceptuala este o reprezentare a īntregului continut informational al bazei de date, īntr-o forma care este oarecum abstracta comparativ cu modul īn care datele sunt stocate fizic. De asemenea, īn general, va fi substantial diferita de modul īn care sunt vizualizate datele de catre utilizatori. Īn mare, intentia este ca vederea conceptuala sa fie o vedere a datelor "asa cum sunt ele īn realitate", nu a modului īn care sunt fortati sa le vada utilizatorii.
Vederea coneptuala este formata din mai multe aparitii ale tipurilor de īnregistrari conceptuale. De exemplu, poate fi formata dintr-o colectie de aparitii ale īnregistrarilor despre departament, plus o colectie a aparitiilor īnregistrarilor despre angajati, plus o colectie a aparitiilor īnregistrarilor despre componente etc. Īnregistrarea conceptuala nu este neaparat identica nici cu īnregistrarea externa, pe de o parte, nici cu īnregistrarea stocata, pe de alta parte.
Vederea conceptuala este definita prin intermediul schemei conceptuale, care include definitiile fiecaruia dintre diversele tipuri de īnregistrari conceptuale. Schema conceptuala este scrisa folosind un alt limbaj de definire a datelor, limbajul DDL conceptual. Daca se are īn vedere realizarea independentei fizice de date, atunci aceste definitii DDL conceptuale nu trebuie sa implice deloc vreo consideratie privind reprezentarea fizica sau tehnica de acces - acestea trebuie sa fie numai definitii ale continutului informational. Astfel, īn schema conceptuala nu trebuie sa existe vreo referire la reprezentarea cāmpului stocat, secventa īnregistrarii stocate, indexuri, pointeri sau alte detalii privind memoria si accesul. Daca schema conceptuala este cu adevarat independenta de date īn acest mod, atunci schemele externe - care sunt definite īn functie de schema conceptuala - vor fi, de asemenea, independente de date.
Astfel, vederea conceptuala reprezinta o vedere a īntregului continut al bazei de date iar schema conceptuala este o definitie a acestei vederi. Definitiile din schema conceptuala sunt create astfel īncāt sa includa mult mai multe caracteristici suplimentare, cum ar fi restrictiile de securitate si de integritate.
Nivelul intern
Al treilea nivel al arhitecturii este cel intern. Vederea interna este o reprezentare de nivel inferior a īntregii baze de date; este formata din mai multe aparitii ale tipurilor de īnregistrari interne (īnregistrari stocate)
Vederea interna este descrisa prin intermediul schemei interne, care nu numai ca defineste diversele tipuri de īnregistrari stocate, ci specifica si indexurile care exista, modul īn care sunt reprezentate cāmpurilor stocate, īn ce secventa fizica se afla īnregistrarile stocate etc. aceasta schema interna este scrisa folosind un alt limbaj de definire a datelor: limbajul DDL intern.
Corespondente
Īn afara de cele trei niveluri, arhitectura din Figura 2.1 presupune anumite corespondente - īn general, o corespondenta conceptual / intern si mai multe corespondente extern / conceptual.
Corespondenta conceptual - intern defineste relatia dintre vederea conceptuala si baza de date stocata; ea specifica modul īn care īnregistrarile si cāmpurile conceptuale sunt reprezentate la nivel intern. Daca structura bazei de date stocate este modificata - adica, daca este efectuata o schimbare a definitiei structurii de stocare - atunci corespondenta conceptual - intern trebuie modificata īn consecinta, astfel īncāt schema conceptuala sa ramāna invariabila. Cu alte cuvinte, efectele unor astfel de modificari trebuie izolate sub nivelul conceptual, pentru a mentine independenta fizica de date.
Corespondenta extern - conceptual defineste relatia dintre o anumita vedere externa si vederea conceptuala. Īn general, diferentele care pot exista īntre aceste doua niveluri sunt analoge celor care pot exista īntre vederea conceptuala si baza de date stocata. De exemplu, cāmpurile pot avea diverse tipuri de date; numele cāmpurilor si īnregistrarilor pot fi schimbate; mai multe cāmpuri conceptuale pot fi combinate īntr-un singur cāmp extern s.a.m.d. Pot exista simultan oricāte vederi externe; oricāti utilizatori pot partaja o vedere externa data; diversele vederi externe se pot suprapune.
La fel cum corespondenta conceptual - interna reprezinta cheia obtinerii independentei fizice de date, tot asa corespondentele extern - conceptual sunt cheia independentei logice de date. Dupa cum am aratat īn Capitolul 1, sistemul prezinta independenta fizica de date daca utilizatorii si programele acestora sunt imune fata de modificarile din structura fizica a bazei de date stocate. Similar, sistemul prezinta independenta logica de date daca utilizatorii si programele acestora sunt imune si fata de modificarile din structura logica a bazei de date (ceea ce īnseamna modificarile la nivel conceptual).
Īn afara de cele de mai sus, majoritatea sistemelor permit definirea anumitor vederi externe īn functie de altele (practic, prin intermediul corespondentelor extern - extern), fara a necesita īntotdeauna o definitie explicita a corespondentei cu nivelul conceptual.
Utilizator A1 Utilizator A2 Utilizator B1 Utilizator B2 Utilizator B3
Schema Schema
externa externa
A B
Corespondenta extern/conceptual Corespondenta extern/conceptual
pentru A pentru B
Vederea conceptuala
Schema
conceptuala
Corespondenta conceptual/intern
Definitia
structurii de
stocare
(schema
interna)
Figura 2.3 Arhitectura sistemului de baze de date
Administratorul bazei de date
Dupa cum am aratat īn Capitolul 1, administratorul datelor (DA) este persoana care ia decizii strategice iar administratorul bazei de date (DBA) este persoana care ofera 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 cāteva din sarcinile administratorului DBA.
Definirea schemei conceptuale
Sarcina administratorului de date este de a decide exact ce informatii vor fi pastrate īn baza de date - cu alte cuvinte, sa identifice entitatile de interes pentru īntreprindere si informatiile care vor fi īnregistrate despre acestea. De obicei, acest proces este numit proiectare logica a bazei de date (proiectare conceptuala). Dupa ce administratorul de date a decis astfel care va fi continutul bazei de date la nivel abstract, administratorul DBA va crea schema conceptuala corespunzatoare, folosind limbajul DDL conceptual.
Īn practica, s-ar putea ca lucrurile sa nu fie atāt de clare cum sugereaza observatiile de mai sus. Īn unele cazuri, administratorul de date poate crea direct schema conceptuala; īn altele, administratorul DBA poate realiza proiectarea logica.
Definirea schemei interne
De asemenea, administratorul DBA trebuie sa decida cum vor fi reprezentate datele īn baza de date stocata. De obicei, acest proces este numit proiectare fizica a bazei de date. Dupa ce a realizat proiectarea fizica, administratorul DBA trebuie sa creeze schema interna corespunzatoare, folosind limbajul DDL intern. Īn plus, trebuie sa defineasca corespondenta conceptual - intern asociata.
Legatura cu utilizatorii
Sarcina administratorului DBA este de a mentine legatura cu utilizatorii, pentru a garanta ca datele de care acestia au nevoie sunt disponibile si pentru a scrie schemele externe necesare, folosind limbajul DDL extern. Īn plus, trebuie definite si corespondentele extern - conceptuale respective.
Alte aspecte ale functiei de realizare a legaturii cu utilizatorii cuprind documentarea proiectarii aplicatiilor, furnizarea educatiei tehnice, asistenta īn identificarea si solutionarea problemelor si alte servicii profesioniste similare.
Definirea restrictiilor de securitate si de integritate
Restrictiile de securitate si de integritate pot fi privite ca parti ale schemei conceptuale. Limbajul DDL conceptual trebuie sa cuprinda facilitati pentru specificarea acestor restrictii.
Definirea politicilor de vidare si de refacere
Īn cazul unei deteriorari a oricarei portiuni din baza de date - cauzata, de exemplu, de o eroare umana sau de o cadere a unui element de hardware sau a sistemului de operare - este esential ca datele respective sa poata fi remediate, cu o īntārziere minima si cu un efect cāt mai mic posibil asupra restului sistemului. Administratorul DBA trebuie sa defineasca si sa implementeze o schema adecvata de control al avariilor care, de regula, presupune:
a) Descarcarea sau "vidarea" periodica a bazei de date pe dispozitivul de stocare de siguranta.
b) Reīncarcarea sau "refacerea" bazei de date conform cu cea mai recenta vidare, atunci cānd este necesar.
Monitorizarea performantelor si raspunsul la modificarea cerintelor
Administratorul DBA este responsabil de organizarea sistemului astfel īncāt sa obtina performantele care "sunt cele mai bune pentru īntreprindere" si de efectuarea modificarilor adecvate - adica reglarea, pe masura ce se schimba cerintele. De exemplu, ar putea fi necesar ca, din cānd īn cānd, sa se reorganizeze baza de date stocata pentru a garanta ca nivelul performantelor ramāne īn limitele acceptabile.
Sistemul de gestiune a bazelor de date
Acum vom prezenta putin mai detaliat functiile sistemului SGBG. Aceste functii cuprind suportul pentru cel putin urmatoarele aspecte:
Definitia datelor
Sistemul SGBD trebuie sa fie capabil sa accepte definitiile datelor (schemele externe, schema conceptuala, schema interna si toate corespondentele asociate) īn forma-sursa si sa le transforme īn forma-obiect adecvata. Cu alte cuvinte, sistemul SGBD trebuie sa includa componenta procesorul DDL sau compilatorul DDL, pentru fiecare dintre diversele limbaje de definire a datelor (DDL).
Manipularea datelor
Sistemul SGBD trebuie sa fie capabil sa manipuleze cerintele de consultare, modificare sau stergere a datelor existente īn baza de date sau sa adauge noi date īn baza de date. Cu alte cuvinte, sistemul SGBD trebuie sa includa o componenta de forma unui procesor DML sau compilator DML, care sa trateze limbajul de manipulare a datelor (DML).
Optimizarea si executia
Cererile DML trebuie sa fie prelucrate de catre un optimizator, al carui scop este sa determine o modalitate eficienta de implementare a cererii.
Securitatea si integritatea datelor
Sistemul SGBD trebuie sa monitorizeze cererile utilizatorilor si sa respinga orice īncalcare a restrictiilor de securitate si de integritate definite de catre administratorul DBA.
Refacerea datelor si concurenta
Sistemul SGBD - sau, mai probabil, o alta componenta software legata de acesta, numita manager de tranzactii sau monitor TP - trebuie sa impuna anumite elemente de control al refacerii si al concurentei.
Dictionarul de date
Sistemul SGBD trebuie sa puna la dispozitie o functie pentru dictionarul de date. Dictionarul de date poate fi privit ca o adevarata baza de date (dar mai degraba o baza de date pentru sistem decāt pentru utilizator). Dictionarul contine "date despre date" (numite uneori si metadate sau descriptori) - adica definitii ale altor obiecte din sistem, īn loc de simple date "brute". Īn particular, toate diversele scheme si corespondente (externe, conceptuale etc.) si toate diversele restrictii de securitate si de integritate vor fi stocate īn dictionar, atāt sub forma sursa cāt si sub forma de obiect. Un dictionar complet va cuprinde si multe informatii suplimentare aratānd, de exemplu, ce programe utilizeaza diversele parti ale bazei de date, ce utilizatori cer rapoarte s.a.m.d. Desigur ca trebuie sa fie posibil sa se interogheze dictionarul la fel ca orice baza de date, astfel īncāt, de exemplu, sa se poata afla ce programe si/sau utilizatori este probabil sa fie afectati de o modificare propusa a sistemului.
Performantele
Se subīntelege ca sistemul SGBD trebuie sa īndeplineasca toate sarcinile īntr-un mod cāt mai eficient posibil.
|
