Cap.

2 ARHITECTURA SISTEMELOR DE BAZE DE DATE

Arhitectura este divizat pe trei niveluri numite, de regul, 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.

1
 Utilizatorul individual va fi interesat numai de 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 nregistrri despre departamente i angajai, fr a cunoate 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 un limbaj de definire a
datelor numit DDL 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 conceptual este format din mai multe nregistrri conceptuale. De
exemplu, poate fi format dintr-o colecie de apariii ale nregistrrilor despre
departamente, plus o colecie a nregistrrilor despre angajai, plus o colecie a
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

2
 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 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 exist,
modul n care sunt reprezentate cmpurile 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 logic 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 Limbajul Limbajul Limbajul Limbajul

gazdei + DSL gazdei + DSL gazdei + DSL gazdei + DSL gazdei + DSL

3
 Schema Vederea extern Schema Vederea extern
extern A extern B
A B

Corespondena extern/conceptual Corespondena extern/conceptual

pentru A pentru B

Schema
Vederea conceptual Sistemul de
conceptual
gestiune a
bazelor de
Corespondena conceptual/intern date
(SGBD)

Definiia
structurii de
stocare
(schema
Baza de date stocat (vedere intern)
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

4
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:

5
 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, modificare
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).
Optimizare i execuie
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.