Introducere

Domeniul bazelor de date suferă de o explozie informaţională. Iată, de

exemplu, o listă parţială a publicaţiilor ce apar regulat în Statele Unite în
domeniu:
1. ACM Transactions on Database Systems - trimestrial cu
aproximativ 500 pp/an.
2. ACM SIGMOD Record, trimestrial aproximativ 250 pp/an.
3. Proc. of the Annual SIGMOD Intl. Conference on Management
of Data, aproximativ 450 pp/an.
4. Proc. of the Annual SIGACT - SIGMOD Sym. on Principles of
Database Systems, aproximativ 350 pp/an.
5. Proc. of the Annual Intl. Conf. on Very Large Databases,
aproximativ 450 pp/an.
Adăugând la acestea conferinţele mai specializate, ca de exemplu
asupra bazelor de date distribuite, a bazelor de date CAD/CAM, a sistemelor
de date expert sau orientate pe obiecte, cam 8 - 10 conferinţe pe an, cu lucrări
publicate însumând în jur de 350 de pagini fiecare şi adăugând şi numărul
mare de rapoarte care apar în universităţi şi laboratoare de cercetare, precum
şi lucrări ce apar ocazional în publicaţii înrudite (Database Newsletter,
Database Review, InfoDB, Database Programming and Design, etc.), precum
şi manualele şi documentaţiile firmelor vânzătoare de DBMS-uri comerciale,
ajungem cam la 100.000 de pagini pe an. Este clar că este aproape imposibil
să ţinem pasul cu tot ce se întâmplă în domeniul nostru de interes. Există însă
fără îndoială o bază comună un alfabet necesar înţelegerii dezvoltărilor în
domeniu. De la această bază fiecare specialist face paşii inevitabili spre
supraspecializare. Cursul nostru de baze de date se vrea doar o introducere în
subiect şi nu o tratare exhaustivă, o prezentare a acelei baze de cunoştiinţe
absolut necesare lucrului în domeniul bazelor de date şi înţelegerii
problematicii bazelor de date, precum şi un mic pas mai departe.
Obiectul principal al lucrării de faţă este deci de a oferi o bază
pentru o educaţie solidă în fundamentele bazelor de date şi de a da o
deschidere către direcţiile noi de cercetare.
Cursul este împărţit în mai multe părţi:
• proiectarea logică a bazelor de date
• proiectarea fizică a bazelor de date
• probleme de control a bazelor de date
• noi tendinţe în bazele de date

1
 Capitolul 1. Concepte de bază

1.1. Ce este un sistem bază de date?

Tehnologia bazelor de date a fost descrisă ca fiind una din ariile ştiinţei
calculatoarelor cu o dezvoltare deosebit de rapidă.
Ca domeniu ea este încă tânără având începutul pe la mijlocul anilor
60’. În ciuda tinereţii, ea a devenit de o importanţă covârşitoare, atât teoretică
cât şi practică. Cantitatea totală de date din bazele de date a devenit acum
posibil a fi măsurată în miliarde de octeţi; efortul financiar implicat este
deasemenea uriaş. Nu este exagerat a spune că multe mii de organizaţii au
devenit critic dependente de operarea continuă şi cu succes a sistemelor de
baze de date.
Deci, ce este exact un sistem de baze de date? Simplu, nu e nimic
mai mult decât un sistem de păstrare a înregistrărilor bazat pe calculator,
adică un sistem al cărui scop suprem este de a înregistra şi menţine
informaţii. Informaţia implicată poate fi orice entitate căreia noi îi conferim o
semnificaţie, adică ceva care poate fi necesar în procesele de luare de decizii
implicate în gestionarea unei organizaţii.
Figura 1.1. doreşte să arate că un sistem bază de date implică patru
componente majore: date, hardware, software şi utilizatori. Le vom considera
pe rând în continuare:

Date
Datele memorate (stocate) într-un sistem sunt partiţionate într-una sau mai
multe baze de date.Pentru scopuri didactice, este convenabil să presupunem
că există numai o bază de date, conţinând totalitatea datelor stocate în sistem.
Există totuşi raţiuni puternice pentru care această restricţie nu este folosită
decât arareori în practică.
Definiţie: O bază de date este un depozit pentru date memorate. În
general ea este atât intergrată cât şi partajată. Prin “integrată” înţelegem că
baza de date poate fi gândită ca o unificare de mai multe fişiere de date, altfel
distincte, cu redundanţele dintre aceste fişiere total sau parţial eliminate.
De exemplu, o bază de date ar putea conţine atât înregistrări
ANGAJAT, conţinând nume, adresă, departament, salariu, etc. cât şi
înregistrări PERFECŢIONĂRI reprezentând înrolarea angajaţilor în cursuri
de perfecţionare. Să presupunem că pentru administrarea cursurilor este
necesară cunoaşterea departamentului fiecărui angajat înscris. Este clar că nu

2
este necesar să se introducă această informaţie redundantă în înregistrările
PERFECŢIONĂRI, deorece ea este deja cuprinsă în datele ce se găsesc la
ANGAJAT-ul corespunzător.

Data Base Management System DBMS

Programe
aplicaţie End Users

Fig. 1.1. Schema simplificată a unui sistem bază de date.

Prin “partajarea” unei baze de date se înţelege că bucăţile

individuale de date din baza de date pot fi partajate între mai mulţi utilizatori
individuali, în sensul că fiecare dintre ei poate avea acces la aceaşi bucată de
date (şi o poate folosi în scopuri diferite). Astfel, partajarea este o consecinţă
a faptului că baza de date este integrată. În exemplul de mai sus, informaţia
despre departamentul din înregistrările ANGAJAT este partajată de utilizatori
din departamentul personal şi de utilizatori din departamentul pregătire cadre.
O altă consecintă a faptului că baza de date este integrată este că un
utilizator dat va utiliza numai o parte (o submulţime) a bazei de date, Mai
mult, submulţimile diferiţilor utilizatori se vor acoperi în diferite moduri.
Termenul “partajat” este extins pentru a acoperi adesea partajarea
concurentă: adică abilitate mai multor utilizatori de a accesa baza de date -
posibil chiar aceaşi bucată de date - în acelaşi timp. Astfel de sistem se
numesc sisteme multiutilizator.

Hardware
Hardul unui sistem bază de date şi constă din volumele de memorare
secundare discuri, dischete, benzi pe care rezidă baza de date, împreună cu
aparatele, unităţile de control, canalele respective. O baze de date se poate

3
presupune fără riscuri ca fiind prea mare pentru a putea fi stocată în memoria
centrală a unui calculator.
Cursul de faţă nu vizează aspectele hard ale domeniului.

Software
Între baza de date fizică (adică datele aşa cum sunt ele memorate pe suport) şi
utilizatorii sistemului există un nivel de software, numit uzual sistem de
gestionare a bazei de date (SGBD sau în engleză, data base management
system DBMS).
Toate cererile utilizatorilor pentru accede baza de date sunt
îndreptate către DBMS. O funcţie generala oferită de către DBMS este de a
feri utilizatorii de detaliile la nivel hardware, adică de a le da posibilitatea să
se ridice peste acestea şi de a suporta operaţii utilizator (de exemplu “citeşte
înregistrarea ANGAJAT pentru angajatul Ionescu”) care se exprimă in
termenii unui nivel superior celui hard.

Utilizatori
Vom considera trei mari categroii de utilizatori. În primul rând, există
programatorul de aplicaţie, responsabil a scrie programe aplicaţie care
folosesc baza de date, tipic în limbaj de programare (Cobol, C, etc.) sau
limbaj propriu al bazei de date (bDase, FoxPro, etc.). Aceste aplicaţii
program operează asupra datelor în toate modurile obişnuite: regăsirea
informaţiilor, crearea informaţiilor noi, modificarea sau ştergerea
informaţiilor existente. Toate aceste funcţii se realizează emiţând cereri
potrivite către DBMS.
O a doua clasă de utilizatori sunt end-userii ce accesează baza de
date de la un terminal. Ei folosesc un limbaj de interogare (query language)
oferit ca o parte integrantă a sistemului sau utilizează aplicaţiile scrise de
programatorii de aplicaţie.
A treia clasă de utilizatori este administratorul bazei de date, pe
scurt DBA.

1.2. Date operaţionale

Datele din baza de date se zic operaţionale pentru a le distinge de cele de

intrare, de ieşire şi de alte tipuri de date.
Definiţie (Engles) O bază de date este o colecţie de date
operaţioanale folosite de către aplicaţiile sistem ale unei intreprinderi
particulare.
Această definiţie cere câteva explicaţii. “Intreprindere” este
termenul general convenabil pentru orice organizaţie comercială, ştiinţifică,
tehnică, etc. Exemple ar putea fi companii productive, banci, spitale,
universităţi, departamente guvernamentale.

4
 Orice intreprindere trebuie să întreţină în mod curent o mulţime de
date despre operarea sa. Acestea sunt date operaţionale. Exemple ar fi datele
de producţie, de contabilitate, datele despre pacienţi sau studenţi, datele de
planificare, etc.
Precum am menţionat, datele operaţionale nu includ date de intrare
şi de ieşire, cozi de lucru sau orice informaţie tranzientă. “Datele de intrare”
se referă la informaţia introdusă în sistem din lumea exterioară, de obicei prin
terminale. Acestă informaţie poate cauza o modificare în datele operaţionale,
dar ea insăşi nu este o parte a bazei de date. Similar, “datele de ieşire” se
referă la mesaje şi rapoarte emanând din sistem (tipărite sau afişate pe
terminal). Din nou, un astfel de raport conţine informaţii din datele
operaţionale, dar nu sunt ele însele parte a bazei de date.
Pentru a exemplifica conceptul de date operaţionale considerăm
cazul unei fabrici. O astfel de intreprindere va dori să reţină informaţii despre
proiectele pe care le are în derulare; părţile (componente, subansamble, etc.)
folosite în aceste proiecte; furnizorii care livrează părţile; magaziile în care se
depozitează părţile; angajaţii care lucrează la proiecte; etc.
Acestea sunt entităţile de bază despre care se înregistrează date în
baza de date. Este important de notat că, în general, vor exista asociaţii sau
relaţii legând aceste entităţi de bază împreună. Ele se reprezintă prin săgeţi
ca în fig. 1.2.
De exemplu există o asociaţie între furnizori şi părţi. Fiecare
furnizor dă anumite părţi şi reciproc, fiecare parte este dată de anumiţi
furnizori. Similar părţile sunt folosite în proiect, şi invers proiectele folosesc
părţi; părţile sunt depozitate în magazii şi magaziile conţin părţi, etc. Să
notăm că aceste relaţii sunt toate bidirecţionale: adică ele, toate pot fi
traversate în ambele direcţii. De exemplu, relaţia între angajaţi şi
departamente poate fi folosită pentru a răspunde la următoarele întrebări:
1. Fiind dat un angajat, să se găsească departamentul în care lucrează.
2. Fiind dat un departament, să se găsească toţi angajaţii corespunzători lui.
Elementul semnificativ depre relaţii ca cele de mai sus este că ele
sunt o parte a datelor operaţionale, chiar mai mult decât entităţile asociate.
Deci ele trebuie să fie reprezentate în baza de date (vom vedea mai târziu
cum).
1. Cu toate că majoritatea relaţiilor din diagramă asociază două tipuri de
entităţi, există şi relaţii care asociază entităţi de trei tipuri, precum şi
relaţii care asociază un singur tip de entitate.
2. O aceaşi entitate poate fi asociată în oricâte relaţii.
Entităţile şi relaţiile sunt două tipuri disimilare fundamentale de obiecte.
Totuşi, o asociaţie între entităţi poate fi considerată ea însăşi o entitate, dacă
luăm ca definiţie pentru entitate: “un obiect despre care vrem să înregistrăm
informaţii” şi deci asociaţia se potriveşte cu această definiţie. Vom vedea
deci relaţiile ca un tip special de entitate.
Figura 1.2. ilustrează şi un număr de alte puncte:

5
 Furnizori Proiecte

Părţi

Magazii Angajaţi

Locaţii Departamente

Fig. 1.2. Asociatii între entitatile de baza

1.3. De ce bază de date?

De ce ar trebui o intreprindere să aleagă a-şi memora datele operaţionale într-

o bază de date integrată? Răspunsul direct este acela că un sistem bază de
date oferă intreprinderii un control centralizat asupra datelor sale
operaţionale, ceea ce este un scop demn de atins. Aceasta nu este cazul în
situaţia actuală a intreprinderilor în care adesea fiecare aplicaţie are propriile
fişiere private, adesea propriile sale discuri şi benzi iar datele operaţionale
sunt astfel larg dispersate şi probabil greu de controlat şi corelat. Cele de mai
sus implică faptul că într-o intreprindere cu un sistem bază de date trebuie să
existe o persoană identificabilă care are această reponsabilitate centrală faţă
de datele operaţionale. Această persoană este administratorul bazei de date
(DBA), menţionat în secţiunea 1.1. Vom discuta în detalii rolul lui mai târziu.
Acum este suficient să menţionăm că slujba lui implică atât un grad înalt de
experienţă tehnică cât şi abilitatea de a înţelege şi interpreta cerinţele de
manager. ( În practică DBA este adesea o echipă şi nu o singură persoană).
Avantajele care rezultă din controlul centralizat sunt:
1. Redundanţa poate fi redusă
În sistemele non-bază de date fiecare aplicaţie îşi are fişierele sale
private, ceea ce duce adesea la redundanţa datelor înregistrate şi ca
rezultat un mare spaţiu de memorare. Nu sugerăm ca întreaga
redundanţă să fie eliminată, dar ea trebuie controlată de către DBA.
2. Inconsistenţa poate fi evitată
Corolar al lui 1.: Nu sunt permise două intrări pentru aceaşi entitate
în baza de date, căci, la actualizare una poate fi omisă.
3. Datele pot fi partajate

6
 Nu înseamnă numai că aplicaţiile existente pot partja date din baza
de date (vezi 1.1.) dar şi că noile aplicaţii pot fi dezvoltate pentru a
opera asupra datelor existente.
4. Standardele vor fi respectate
DBA impune în reprezentarea datelor standarde unice.
5. Pot fi aplicate restricţii de securitate
6. Poate fi menţinută integritatea datelor
7. Cererile conflictuale pot fi balansate

1.4. Independenţa datelor

Independenţa datelor poate fi înţeleasă uşor dacă considerăm la început

opusul ei. Multe din aplicaţiile de astăzi sunt dependente de date. Aceasta
înseamnă că modul în care datele sunt organizate pe suportul secundar de
stocare şi modul în care ele sunt accesate sunt ambele dictate de cerinţele
aplicaţiei şi mai mult ştiinţa organizării datelor şi tehnicile de acces sunt
construite în logica aplicaţiei. De exemplu, se poate decide (din raţiuni de
performanţă) ca un fişier particular să fie memorat în forma secvenţial-
indexată. Aplicaţia, apoi, trebuie să ştie că indexul există şi trebuie să ştie
secvenţa fişierului (aşa cum e definită de către index) iar structura internă a
aplicaţiei se va construi în jurul acestei cunoaşteri. În plus, forma precisă a
variantelor procedurii de acces şi de verificare-excepţie, din cadrul aplicaţiei,
vor depinde de detaliile interfeţei prezentate de către software-ul secvenţiel
indexat.
Spunem că o aplicaţie ca cea de mai sus este dependentă de date
deoarece este imposibil să modificăm structura de memorare (modul în care
sunt stocate înregistrările) sau strategia de acces fără a afecta, probabil drastic
aplicaţia.
De exemplu, nu ar fi posibil să înlocuim fişierul secveţial indexat de
mai sus cu, să zicem, hash-file, fără a face modificări majore în aplicaţie.
Într-un sistem bază de date, totuşi, este de nedorit ca aplicaţiile să fie
dependente de date, din cel puţin două motiv:
1. Diferitele aplicaţii au nevoie de viziuni diferite asupra aceloraşi date.
2. DBA trebuie să aibă libertatea de a alege structura de memorare sau
strategia de acces ( sau amândouă) ca răspuns la cerinţele de modificare
fară a modifica aplicaţiile existente. De exemplu, intreprinderea poate
adopta noi standarde; priorităţile aplicaţiilor se pot schimba; noi tipuri de
periferice devin disponibile, etc. Dacă aplicaţiile sunt dependente de date,
astfel de schimbări implică modificări corespunzătoare în programe.
Rezultă că independenţa datelor este un obiectiv major pentru sistemul bază
de date. Definiţia independenţei datelor ar putea fi “imunitatea aplicaţiilor
la modificări de structură a memorării şi a stategiei de acces”.

7
 Să considerăm, pentru început, tipurile de modificări pe care un
DBA doreşte să le facă (şi la care dorim ca aplicaţiile să fie imune). Începem
cu câteva definiţii:
Un câmp este cea mai mică unitate de date stocate în baza de date.
Baza de date va conţine, în general, mai multe ocurenţe sau instanţe pentru
fiecare din tipurile de câmpuri.
O înregistrare este o colecţie de nume de câmpuri asociate. Facem
din nou distincţie între tip şi ocurenţă. O ocurenţă sau instanţă de
înregistrare constă dintr-un grup de ocurenţe de câmp înrudite (asociate) şi
reprezintă o asociere între ele. Un fişier este o colecţie a tuturor
înregistrărilor de unul sau mai multe tipuri.

Reprezentarea datelor numerice

Un câmp numeric poate fi memorat în forma internă aritmetică (de ex:
zecimal împachetat) sau ca un şir de caractere. În fiecare caz, DBA trebuie să
aleagă o bază potrivită (de ex: binară sau zecimală), o scală (fixă sau flotantă)
un mod (real sau complex) şi o precizie (număr de cifre). Oricare din aceste
aspecte poate fi schimbat pentru a înbunătăţi performanţa sau pentru a se
conforma la un nou standard sau pentru altă raţiune.

Reprezentare datelor caracter

Un câmp şir de caractere poate fi memorat în mai multe coduri de caractere
(de ex. EBCDIC, ASCII)

Unităţi pentru datele numerice

Unităţile într-un câmp numeric se pot schimba - din inches în centimetrii, de
exemplu, în timpul procesului de metrizare.

Codificarea datelor
În anumite situaţii, este de dorit a reprezenta datele prin valori codificate.

Materializarea datelor
În mod normal, câmpul logic văzut de o aplicaţie corespunde cu un anumit
câmp unic dintr-o înregistrare. Într-un astfel de caz, procesul materializării -
adică construcţia unei ocurenţe corespunzătoare a câmpului memorat şi
prezentarea ei aplicaţiei - se poate spune că este directă.
Totuşi ocazional, un câmp logic nu va avea numai un singur câmp
memorat, ci valorile lui se vor materializa cu ajutoarul unor calcule efectuate
asupra unei mulţimi de câmpuri memorate. De exemplu un câmp “cantitate
totală”. Atunci câmpul logic se zice că este indirect.

Structura înregistrărilor memorate.

Două tipuri de înregistrări pot fi combinate într-unul singur. De exemplu,
tipurile de înregistrări (parte, număr, culoare) şi (parte, număr, greutate) pot fi

8
integrate pentru a da (parte, număr, culoare, greutate). Aceste probleme apar
atunci când aplicaţii de dinainte de a avea o bază de date sunt integrate într-
un sistem bază de date.
Aceasta implică faptul că înregistrarea logică a unei aplicaţii poate
consta dintr-o submulţime a unei înregistrări memorate, adică faptul că
anumite câmpuri memorate pot fi invizibile pentru o aplocaţie particulară.
Alternativ, un singur tip de înregistrare memorată poate fi spart în două. În
cazul nostru (parte, număr, culoare, greutate) poate da (parte, număr, culoare)
şi (parte, număr, greutate).
O astfel de despicare permite ca porţiuni mai puţin folosite să fie
memorate pe periferice mai lente, de exemplu. Implicaţia este că înregistrarea
logică a unei aplicaţii poate conţine câmpuri din mai multe tipuri de
înregistrări memorate.

Structura fişierelor memorate

Un fişier dat poat fi implementat fizic în memorie într-o sumedenie de
moduri. De exemplu, poate fi în întregime conţinut într-un volum de
memorare (ex: disc) sau poate fi impărţit pe mai multe volume de mai multe
tipuri diferite. El poate fi sau nu fizic secvenţial în concordanţă cu valorile
unui anumit câmp; poate avea unul sau mai mulţi indecşi asociaţi; poate fi
construit cu pointeri; înregistrările pot fi blocate sau nu, etc. Nici una din
aceste consideraţii nu afectează aplicaţia (mai puţin performanţa). Lista de
mai sus implică că baza de date trebuie să fie în stare să crească fără a afecta
aplicaţiile existente, aceasta fiind raţiunea majoră a independenţei datelor.
Adică să putem adăuga în baza de date noi tipuri de câmpuri şi înregistrări.

1.5. O arhitectură pentru un sistem bază de date

Suntem acum în poziţia de a evidenţia o arhitectură pentru un sistem bază de

date.
Nivel exterior
(Vederi utilizatori individuali)

Nivel conceptual
(Vedere comunitate utilizatori)

Nivel intern
(Vedere storage=memorare)

Fig.1.3. Cele trei nivele ale bazei de date

9
Scopul nostru în prezentarea acestei arhitecturi este de a oferi un cadru pe
care ne putem construi celelalte capitole şi de a înţelege, în general baza de
date. Arhitectura este împărţită în trei nivele generale: intern, conceptual şi
extern. Grosier vorbind, nivelul intern este acela care e cel mai apropiat de
memorarea fizică, adică cel legat de modul de memorare al datelor. ivelul
extern este cel mai apropiat de utilizatori, adică de modul în care datele se
văd de către utilizatorii individuali. Nivelul conceptual este “nivelul de
indirectare” între celelalte două viziuni.
Exemplu: La nivelul conceptual, baza de date conţine informaţii
despre un tip de entitate numit ANGAJAT. Fiecare ANGAJAT are un
NUMAR-ANGAJAT (6 caractere), NUMAR-DEPARTAMENT (4
caractere) şi un SALARIU (5 cifre). La nivelul intern, angajaţii sunt
reprezentaţi printr-un tip de înregistrare STORED-ANG de 18 octeţi.
STORED-ANG conţine patru tipuri de câmpuri: un prefix de 6 octeţi (posibil
cu informaţii de control, flags, pointers, etc.), şi trei câmpuri de date
corespunzătoare celor trei proprietăţi ale lui ANGAJAT. În plus,
înregistrările STORED-ANG sunt indexate prin câmpul EMP# de un index
numit EMPX. La nivelul extern, un utilizator poate vedea numai două
câmpuri (NUMAR-ANGAJAT şi SALARIU) iar un alt utilizator poate vedea
numai (NUMAR-ANGAJAT şi NUMAR-DEPARTAMENT).
Să notăm că obiectele corespunzătoare pot avea nume diferite la cele
trei nivele.
Să examinăm acum mai în detaliu componentele arhitecturii.
Utilizatorii sunt fie programatorii de aplicaţii fie utilizatorii de la
terminale. DBA este un caz special şi important. Fiecare utilizator are un
limbaj la dispoziţia sa: programatorii au limbaje de programare COBOL, C,
etc. iar utilizatorii au un limbaj de interogare, un query language.
Pentru scopurile noastre lucrul important relativ la limbajul
utilizator este ca acesta va include un sublimbaj date (Data SubLanguage
DSL), adică un subset al limbajului total care este legat de obiectele şi
operaţiile bazei de date. Spunem că sublimbajul de date este scufundat într-un
limbaj gazdă.
În principiu, orice sublimbaj de date este o combinaţie a două
limbaje: un limbaj de definiţie date (Data Definition Language DDL), care
defineşte obiectele bazei de date (aşa cum sunt ele percepute de către
utilizator) şi un limbaj de manipulare date (Data Manipulation Language
DML), care prelucrează astfel de obiecte.
Să revenim însă la arhitectură.
Am indicat deja că un utilizator individual va fi interesat, în general,
numai de o anumită porţiune a bazei de date totală; mai mult vederea
utilizatorului asupra acelei porţiuni va fi ceva abstract dacă o comparăm cu
modul în care datele respective sunt memorate fizic. Viziunea utilizatorului
individual se numeşte vedere externă. O vedere externă este astfel conţinutul

10
bazei de date aşa cum este ea văzută de un utilizator particular (adică pentru
acel utilizator, vederea externă este baza de date).
De exemplu, un utilizator din departamentul personal va vedea baza
de date ca o colecţie de ocurenţe de înregistrări departament plus o colecţie
de ocurenţe de înregistrări angajat (şi nu ştie de ocurenţele de înregistrări
clienţi, părţi, etc.). În general, deci, o vedere externă constă din mai multe
ocurenţe de multiple tipuri de înregistrări externe. O înregistrare externă nu
este necesar aceaşi cu înregistrarea memorată. Sublimbajul de date al
utilizatorului este definit în termenii înregistrărilor externe. De exemplu, o
operaţie DML “get” va găsi o ocurenţă de înregistrare externă şi nu una de
înregistrare memorată. Vedem acum că termenul de înregistrare logică din
secţiunea 1.4. este de fapt sinonim celui de înregistrare externă.
Fiecare vedere externă este definită cu ajutorul unei scheme externe
care constă din definiţii pentru fiecare din variatele tipuri de înregistrări
externe din vederea externă.
Schema externă este scrisă folosind porţiunea DDL a sublimbajului
de date. De aceea, DDL-ul este numit adesea DDL extern.
De exemplu, tipul de înregistrare externă angajat poate fi definit ca
având un câmp de 6 caractere pentru numărul angajatului, plus un câmp fix
binar pentru salariu, etc. În plus, trebuie să existe o definiţie pentru maparea
între schema externă şi schema conceptuală.
Vederea conceptuală este o reprezentare a întregii informaţii
conţinute în baza de date, din nou într-o formă care este ceva abstract în
comparaţie cu modul în care datele sunt stocate fizic. Ea poate fi şi puţin
diferită de modul în care datele sunt văzute de un utilizator particular. Grosso
modo vorbind, ea se doreşte a fi o vedere a datelor aşa cum sunt în realitate,
mai degrabă decât modul în care un utilizator este forţat să le vadă. Vederea
conceptuală constă din multiple din multiple ocurenţe de multiple tipuri de
înregistrări conceptuale.
De exemplu, poate consta dintr-o colecţie de ocurenţe de înregistrări
departament, plus o colecţie de ocurenţe de înregistrări angajat plus o colecţie
de ocurenţe de înregistrări furnizor, o colecţie de ocurenţe de înregistrări
părţi, etc.
O înregistrare conceptuală nu este necesar aceaşi cu o înregistrare
externă sau o înregistrare memorată.
Vederea conceptuală este definită cu ajutorul unei scheme
conceptuale care include definiţii pentru fiecare din variatele tipuri de
înregistrări conceptuale. Schema conceptuală se scrie folosind un alt limbaj
de definiţie de date DDL-ul conceptual.
Dacă se doreşte să se obţină independenţa datelor, aceste definiţii
trebuie să nu implice nici o considerare despre structura de memorare sau
strategia de acces - ele trebuie să fie definiţii referitaoare numai la conţinutul
informaţiei. Astfel, trebuie să nu fie nici o referinţă la reprezentarea în

11
memorie a unui câmp, secvenţă fizică, indexare sau orice alt detaliu de
memorare/acces.
Vederea conceptuală este, apoi, o vedere a conţinutului întregii baze
de date iar schema conceptuală este o definiţie a acestei vederi. Ea este puţin
mai mult decât o simplă reuniune a tuturor vederilor utilizator individuale,
posibil cu adăugarea unor proceduri simple de autorizare şi validare.
Al treilea nivel de arhitectură este nivelul intern. Vederea internă
este o reprezentare de nivel foarte jos a întregii baze de date. Ea constă din
multiple ocurenţe de multiple tipuri de înregistrări interne, adică ceea ce noi
am numit înregistrări memorate. Ea este totuşi deasupra nivelului fizic,
deoarece nu lucrează în termeni de înregistrări fizice sau blocuri şi nici cu
restricţii specifice perifericelor ca de exemplu mărime cilindru sau pistă.
Vederea internă presupune un spaţiu de adrese liniar şi infinit.
Detaliile despre modul în care este mapat acest spaţiu de adrese pe
memoria fizică este specific implementării şi nu este adresat direct în
arhitectură.
Vederea internă este descrisă cu ajutorul schemei interne care nu
numai că defineşte tipuri variate de înregistrări memorate, dar specifică
deasemenea ce indecşi există, cum se reprezintă câmpurile memorate, etc.
Schema internă se scrie folosind un alt limbaj de definiţie date,
DDL-ul intern.
Maparea conceptuală/internă defineşte corespondenţa dintre
vederea conceptuală şi baza de date memorată (vederea internă), specificând
modul în care se mapează câmpurile şi înregistrările conceptuale în
corespondente lor. Dacă structura bazei de date memorate se modifică - adică
a apărut o schimbare în definiţia structurii de memorare - maparea
conceptuală/internă trebuie să se schimbe corespunzător, astfel încât schema
conceptuală să rămână aceaşi. Cade în responsabilitatea lui DBA să
controleze astfel de schimbări. Cu alte cuvinte, efectele unor astfel de
schimbări trebuie să fie conţinute sub nivelului conceptual, astfel ca
independenţa datelor să fie atinsă.
Maparea externă/conceptuală defineşte corespondenţa dintre o
vedere externă particulară şi vederea conceptuală. În general acelaşi fel de
diferenţe pot exista între aceste două nivele ca şi cele care există între vederea
conceptuală şi baza de date memorată. De exemplu, câmpurile pot avea
diferite tipuri de date, înregistrările pot fi secvenţializate diferit, etc. În
acelaşi timp pot exista oricâte vederi externe; oricâţi utilizatori pot partaja o
vedere externă dată; diferitele vederi externe se pot acoperi.
Sistemul de gestiune al bazei de date (Data Base Management
System DBMS) este softul care mânuieşte toate accesele la baza de date.
Conceptual, se întâmplă astfel:
1. Un utilizator emite o cerere de acces, folosind un limbaj patricular de
manipulare date.
2. DBMS-ul interceptează cererea şi o interpretează.

12
3. DBMS-ul inspectează, pe rând, schema externă, maparea
externă/conceptuală, schema conceptuală, maparea conceptuală/internă şi
definiţia de structură de memorare.
4. DBMS-ul realizează operaţiile necesare asupra bazei de date memorate.
De exemplu, să considerăm ceea ce este implicat în regăsirea unei
ocurenţe de înregistrare externă particulară. În general câmpurile vor fi cerute
din mai multe ocurenţe de înregistrări conceptuale. Fiecare ocurenţă de
înregistrare conceptuală, la rândul ei, poate cere câmpuri din mai multe
ocurenţe de înregistrare memorată. Cel puţin conceptual, atunci DBMS
trebuie să regăsească toate ocurenţele de înregistrare memorată, să
construiască ocurenţele de înregistrare conceptuală cerute şi apoi să
construiască ocurenţa de înregistrare externă cerută. La fiecare nivel sunt
necesare conversii de tipuri de date.
Din nou, responsabilităţile DBA includ:
1. Decizia asupra conţinutului informaţiei conţinute în baza de date.
DBA identifică entităţile de interes pentru intreprindere şi identifică
informaţia care se înregistrează despre aceste entităţi. DBA
defineşte apoi conţinutul bazei de date scriind schema conceptuală
(folosind limbajul DDL conceptual). Forma obiect (compilată) a
acestei scheme este folosită de către DBMS în răspunsul la cererile
de acces. Forma scrisă (necompilată) acţionează ca un document de
referinţă pentru utilizatorii din sistem.
2. Decizia asupra structurii de memorare şi a structurii de acces.
DBA decide asupra modului încare datele sunt reprezentate în baza
de date şi trebuie să specifice reprezentarea scriind definiţia de
structură de memorare (folosind DDL-ul intern). În plus trebuie să
specifice maparea între definiţia structurii de memorare şi schema
conceptuală. În practică, atât DDL-ul intern cât şi cel extern vor
include, probabil, mijloacele pentru a specifica această mapare, dar
definiţiile diferite trebuie să fie clar separate. Ca şi schema
conceptuală, schema internă şi maparea coresunzătoare trebuie să
existe atât în forma scrisă cât şi în forma obiect.
3. Legătura cu utilizatorii.
Pentru a se asigura că datele pe care le achiziţionează utilizatorii
sunt corecte, DBA păstrează legătura cu aceştia şi pentru a scrie
schemele externe necesare, folosind DDL-ul extern. În plus,
maparea între orice schemă externă dată şi schema conceptuală
trebuie specificată de asemenea. În practică, DDL-ul extern va
include, probabil, mijloacele pentru a specifica această mapare, dar
schema şi maparea trebuie să fie clar distincte. Fiecare schemă
externă şi maparea corespunzătoare vor exista atât în sursă cât şi în
obiect.
4. Definirea procedurilor de verificări autorizate şi de validări.

13
 Aşa cum am mai spus, acestea pot fi considerate ca extensii logice
ale schemei conceptuale. DDL-ul conceptual va include facilităţi
pentru a specifica astfel de verificări şi proceduri.
5. Definirea unei strategii pentru salvări şi restaurări.
Odată ce o intreprindere a decis să folosească un sistem bază de
date, ea devine critic dependentă de succesul operării sistemului. În
eventualitatea unei deterioarări a oricărei porţiuni a bazei de date -
cauzate de o eroare umană, eşec hardware sau al sistemului de
operare - este esenţial să fie capabil să repare datele implicate, cu un
minimum de întârziere şi cu un efect cât mai mic asupra restului
sistemului. DBA trebuie să definească şi să implementeze o strategie
de restaurare potrivită, implicând, de exemplu, salvarea periodică a
bazei de date pe bandă şi proceduri de reâncărcare de porţiuni
relevante ale bazei de date din ultima bandă.
6. Monitorizarea performanţei şi răspunsuri la schimbările în cerinţe.
DBA este responsabil pentru a organiza sistemul astfel încât să
obţină performanţa care este “cea mai bună pentru interprindere” şi
pentru a face ajustările potrivite, după cum se schimbă cerinţele. Aşa
cum am spus, orice schimbare în detaliile memorării şi accesului
trebuie să fie acompaniată de o schimbare corespunzătoare în
definiţia mapării la memorare, astfel încât schema conceptuală să
rămână constantă.
Este clar că DBA cere un număr de programe utilitare pentru a se ajuta în
aceste sarcini. Astfel de utilitare vor fi o parte esenţială a sistemului bază de
date real. Iată câteva exemple de astfel de utlitare.
1. Rutina de încărcare (pentru a crea versiunea iniţială a bazei de date)
2. Rutina de reorganizare (pentru a reorganiza baza de date, de exemplu de a
elimina datele perimate)
3. Rutine jurnaliere (pentru a nota orice operaţie asupra bazei de date
împreună cu identificarea utilizatorului ce a efectuat-o)
4. Rutine de restaurare (pentru a restaura baza de date la o stare anterioară
unui eşec hard sau de programare)
5. Rutine de analiză statistică (pentru a asista în monitorizarea performanţei)
Programele utilitare se vor gândi ca aplicaţii speciale oferite de sistem, cu
excepţia rutinelor jurnaliere, care trebuie să fie parte a lui DBMS însuşi.
Anumite rutine vor opera direct la nivelul intern.
Unul dintre cele mai importante instrumente ale DBA este
dicţionarul de date. El este o bază de date, conţinând date despre date,
adică, descrieri ale obiectelor sistemului. În particular, toate schemele
(externă, conceptuală şi internă) sânt memorate fizic în dicţionar. Un
dicţionar comprehensiv va include, de asemenea, informaţii referinţe
încrucişate.
Ultima componentă la care ne vom referi în acest capitol este
interfaţa utilizator. Ea poate fi definită ca o margine în sistem sub care totul

14
 devine invizibil pentru utilizator. Prin definiţie interfaţa utilizator este la
nivelul extern.

UserA1 UserA2 UserB1 UserB2 UserB3

Limbaj Limbaj Limbaj Limbaj Limbaj
gazdă+ gazdă+ gazdă+ gazdă+ gazdă+
DSL DSL DSL DSL DSL

Schema Vedere Schema Vedere

externă A externă externă B externă
A B

Scheme şi
mapări Mapare externã/conceptualãA Mapare externã/conceptualãB
construite
şi
menţinute
Schema Vedere
de către
conceptuală conceptuală DBMS
DBA

Vedere internă Baza de date memorată

Interfaţa utilizator

Fig.1.4. Arhitectura sistemului bază de date.

1.6. Baze de date distribuite.

O bază de date distribuită este, tipic, o bază de date care nu este memorată în
totalitate într-o singură locaţie fizică ci, mai degrabă, este împăştiată într-o
reţea de calculatoare. Ca un exemplu simplificat, să considerăm un sistem
bancar în care baza de date cu conturile clienţilor este distrubuită la
sucursalele băncii, astfel încât înregistrarea contului unui client particular este
memorată la sucursala locală a clientului. Cu alte cuvinte, datele sunt
memorate la locaţia la care sunt folosite mai des, dar ele sunt disponibile,
prin reţeaua de comunicaţii, şi utilizatorilor din alte locaţii (de exemplu cei de

15
la sediul central al băncii). Avantajele unei astfel de distribuţii sunt clare: ea
combină eficienţa prelucrării locale (fără regie de comunicare) pentru
majoritatea operaţiilor cu avantajele discutate mai înanite (în particular
partajarea datelor) oferite de un sistem centralizat. Un obiectiv cheie pentru
un sistem distribuit este acela că el seamănă cu un sistem centralizat pentru
utilizator. Adică, utilizatorul nu trebuie în mod normal săştie unde este
memorată fizic o bucată dată de date (astfel că aplicaţiile sunt independente
de maniera în care sunt datele distribuite, făcând posibilă schimbarea
distribuţiei fără a afecta acele aplicaţii). Astfel, faptul că baza de date este
distribuită va fi relevant numai la nivelul intern şi nu la nivelurile conceptual
şi extern.

Memento

Bază de date, integrare, partajare Schema externă, vedere, DDL

Sistem bază de date Schema conceptuală, vedere, DDL
DBMS Schema internă, vedere, DDL
Câmp, Înregistrare, Fişier memorat Entitate
DML Relaţie
Sublimbaj de date Independenţa datelor
Securitate Dicţionar de date
Integritate

Bibliografie

1. Date, C.J. An Introduction to Database Systems 3rd Ed., Addison Wesley,

1982
2. Ross, R.G. Database Systems: Design, Implementation and Management,
Armacom, NY, 1978
3. Cardenas, A.F. Data Base Management Systems, Allyn & Bacon, Boston,
1979

16