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
|
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.
|
