Programul de studii CONTABILITATE SI INFORMATICA DE GESTIUNE [623856]

Universitatea SPIRU HARET
Programul de studii CONTABILITATE SI INFORMATICA DE GESTIUNE
Anul al II -lea

SINTEZA DISCIPLINEI
BAZE DE DATE

Cadru didactic titular
Conf.univ.dr. Mihai Andronie

3Prezentarea lec Ńiei / capitolul 1:
1.1 No Ńiuni fundamentale utilizate în organizarea datelor
Datele sunt stocate în memoria intern ă și memoria extern ă a oric ărui sistem de
calcul. Organizarea datelor se refer ă la procesul de definire și structurare a datelor în
colec Ńii de date , precum și la realizarea leg ăturilor între elementele unei colec Ńii și între
colec Ńiile de date. Organizarea datelor se proiecteaz ă în scopul reg ăsirii automate a
acestora dup ă diverse criterii .
Obiectivele organiz ării datelor sunt, în principal, urm ătoarele:
• timp de acces minim la date;
• apari Ńia o singur ă dat ă a datelor în sistem;
• spa Ńiu de memorie intern ă și extern ă pentru date cât mai mic;
• reflectarea prin organizare a tuturor leg ăturilor dintre procesele economice pe
care aceste date le reprezint ă;
• posibilitatea modific ării structurii datelor și a rela Ńiilor dintre date fără a produce
schimb ări în programele care le gestioneaz ă.
Tehnicile de organizare a datelor în colec Ńii de date sunt: fi șierul de date și baza
de date .
Fi șierul de date reprezint ă o colec Ńie de date memorat ă pe un suport tehnic într-o
succesiune de înregistr ări. Accesul la o înregistrare din fi șierul de date se ob Ńine prin
parcurgerea înregistr ărilor fi șierului în secven Ńa în care au fost stocate ( acces secven Ńial )
sau pe baza unei chei de identificare care s ă permit ă reg ăsirea rapid ă a înregistr ării ( acces
direct ). Accesul direct se ob Ńine prin indexarea fi șierelor, adic ă prin crearea unor tabele
de indec și care pentru fiecare valoare a atributului cheie p rimar ă (atribut care permite
identificarea în mod unic a unei înregistr ări din fi șier) s ă con Ńin ă adresa corespunz ătoare
(în cadrul fi șierului) a fiec ărei înregistr ări.
Aceast ă organizare a datelor în fi șiere de date prezint ă urm ătoarele dezavantaje :
• redundan Ńă mare (stocarea acelora și date în mai multe fi șiere);
• acces dificil la date ; exploatarea multiutilizator a datelor necesita op era Ńii suplimentare
de sortare, fuziune, ventilare etc.;
• izolarea datelor , adic ă nu pot fi realizate programe pe calculator care s ă acceseze datele
într-o manier ă global ă;
• actualizarea datelor, prin ad ăugare , modificare , ștergere , genereaz ă conflicte atunci
când mai mul Ńi utilizatori doresc s ă modifice simultan acelea și date;
• dependen Ńa programelor fa Ńă de date ; deoarece datele se descriu în programe,
modific ările din structura datelor oblig ă la efectuarea de corecturi în programele pe
calculator;
• problemele neprev ăzute nu ob Ńin răspunsuri rapide ;
• fiecare dat ă este descris ă independent în toate fi șierele în care apare; dac ă într-un fi șier
se modific ă formatul și valoarea unei date, acea modificare nu se transmi te automat,
pentru aceea și dat ă, în toate fi șierele de date; ca urmare, pentru aceea și dat ă se creeaz ă
posibilitatea apari Ńiei de valori diferite în fi șiere diferite ( inconsisten Ńa datelor);
• nu se men Ńine integritatea datelor, atunci când fi șierul este realizat cu limbaje diferite.
Cre șterea necesarului de date, informa Ńii și cuno știn Ńe pentru agen Ńii economici și
progresele tehnologiilor informa Ńiei și ale comunica Ńiilor (IT&C) au determinat
organizarea datelor în baze de date .

4No Ńiunile fundamentale folosite în organizarea datelor sunt entitatea, atributul și
valoarea . Între acestea exist ă leg ături de interdependen Ńă astfel:
/head2right o entitate are mai multe atribute, iar atributele a u o anumit ă mul Ńime de valori;
/head2right entitatea reprezint ă un obiect concret sau abstract definit prin propri et ăŃile sale;
/head2right orice proprietate a unui obiect este exprimat ă printr-o pereche (ATRIBUT,
VALOARE).
Exemplul a) – „ materialul M are lungimea mare” unde „lungimea” este atributu l,
iar „mare” este valoarea. (LUNGIMEA, MARE);
Exemplul b) – un client – persoan ă fizic ă al unei societ ăŃi comerciale poate fi
reprezentat prin mul Ńimea de perechi: (NUME, POPESCU); (PRENUME, ION);
(LOCALITATE, BUCURE ȘTI); (TELEFON, 0213211231); (BANCA, BCR);
(CONT_BANCAR, RO15RZBR0000070002170022).
1.2. Rela Ńii între date.
Între date exist ă rela Ńii sau leg ături diferite. Între datele care apar Ńin unor tipuri de
entit ăŃi se pot realiza dou ă feluri de leg ături:
• prim ă leg ătur ă se exprim ă prin apartenen Ńa datelor la entitate;
• a doua leg ătur ă se define ște pentru entit ăŃile de acela și tip sau de tipuri diferite .
Exemple:
a) Dac ă se noteaz ă cu SALARIATI mul Ńimea salaria Ńilor unei societ ăŃi
comerciale, între datele a1 și a2 ce apar Ńin acestei mul Ńimi, se pot defini rela Ńii de tipul:
/head2right a1 are aceea și func Ńie de încadrare cu a2;
/head2right a1 are acela și salariu cu a2;
/head2right a1 are aceea și vârst ă cu a2 etc.
b) Se consider ă dou ă clase de entit ăŃi: PRODUSE_BANCARE și CLIENTI. Între
datele acestor dou ă clase de entit ăŃi se pot defini rela Ńiile:
/head2right un produs bancar poate fi achizi Ńionat de unul sau mai mul Ńi clien Ńi ai b ăncii;
/head2right un client al b ăncii poate achizi Ńiona unul sau mai multe produse bancare.

1.3. Structuri de date
Structura de date este o colec Ńie de date între care s-au stabilit un ansamblu de
rela Ńii pe baza c ărora func Ńioneaz ă un mecanism de selec Ńie și identificare a
componentelor. Altfel exprimat, o structur ă de date reprezint ă un anumit aranjament al
datelor atunci când sunt stocate în memoria unui ca lculator. Datele din structurile de date
pot fi manipulate cu ajutorul algoritmilor, în mai multe moduri, sortând datele sau
căutând un anumit element. Structurile de date, în af ara situa Ńiei de instrumente de
programare, servesc pentru stocarea și modelarea unor date din universul real.
Mul Ńimea de date, asociat ă structurii de date, poate cuprinde datele unui tip sau
ale mai multor tipuri de entit ăŃi. Componentele structurii se identific ă prin nume sau prin
pozi Ńia pe care o de Ńin în structur ă în raport cu ordinea specificat ă.
În situa Ńia în care pentru localizarea unei componente se pa rcurg toate celelalte
componente dinaintea ei, structura are acces secven Ńial . În schimb, atunci când o
component ă poate fi selectat ă f ără a Ńine seama de celelalte, structura are acces direct .
Componentele unei structuri de date sunt date elem entare sau sunt ele însele
structuri de date.
Asupra unei structuri de date se pot efectua urm ătoarele opera Ńii :
• crearea (înseamn ă memorarea datelor ini Ńiale pe suportul de stocare);

5• actualizarea (schimbarea st ării structurii prin ad ăugare, modificare sau ștergere de
elemente, modificarea valorii sau rela Ńiilor dintre elemente);
• consultarea (accesarea componentelor structurii de date);
• sortarea (aranjarea elementelor unei structuri de d ate în conformitate cu criterii
prestabilite);
• ventilarea (divizarea unei structuri de date în dou ă sau mai multe structuri de
date);
• fuzionarea (formarea unei structuri de date noi din dou ă sau mai multe structuri
de date) etc.
Structurile de date care prezint ă aceea și organizare și asupra c ărora se execut ă
acelea și opera Ńii formeaz ă un anumit tip de structuri de date. Tipul de structur ă de date
reprezint ă o mul Ńime ordonat ă de date între care s-au stabilit anumite rela Ńii și pentru care
realizarea opera Ńiilor se efectueaz ă cu un grup de operatori de baz ă care au o anumit ă
semantic ă.
Dac ă se ia în considerare tipul componentelor , structurile de date se clasific ă în:
• omogene (componentele sunt de acela și tip);
• eterogene (componentele au tipuri diferite).
Când structura de date se descompune în structuri d e date de acela și tip, atunci
structura ob Ńinut ă este denumit ă recursiv ă.
Dup ă nivelul de structurare al datelor , se deosebesc:
• structura fizic ă (structura de date care se refer ă la modul de implementare pe
supor Ńi tehnici informa Ńionali);
• structura logic ă (modul de ordonare a datelor și modul de folosire a operatorilor
de tratare a datelor).
Dac ă se ia în considerare posibilitatea modific ării valorilor și a structurilor , se
identific ă:
• structuri statice (pe tot parcursul existen Ńei acestora prezint ă acela și num ăr de
componente și în aceea și ordine (adic ă au cardinalitate finit ă, prin cardinalitate
în Ńelegând num ărul elementelor mul Ńimii);
• structuri dinamice (permit modificarea valorilor și a structurii de date prin
aplicarea unor operatori; aceste structuri de date au cardinalitate infinit ă deoarece
prezint ă un num ăr nelimitat de componente).
O structur ă logic ă poate fi implementat ă atât ca structur ă static ă cât și ca structur ă
dinamic ă. Exist ă îns ă și structuri logice ce nu pot fi implementate static . În organizarea
datelor trebuie definit ă atât structura logic ă, cât și cea fizic ă, deorece cele dou ă nivele se
condi Ńioneaz ă reciproc.
Din punctul de vedere al tipului de structur ă de date , se deosebesc:
• structura de date punctual ă (o entitate de grup izolat ă);
• structura de date liniar ă (când exist ă o rela Ńie de ordine total ă între elementele
colec Ńiei de date; primul element nu are predecesori; ult imul element nu are succesori;
între date se stabilesc rela Ńii de tipul “unu-la-unu”; când ultimul element coin cide cu
primul element, structura liniar ă devine structur ă circular ă sau inelar ă);
• structura de date arborescent ă (este denumit ă și structur ă de date ierarhic ă sau
descendent ă; acest tip de structur ă de date se define ște când exist ă o rela Ńie de ordine
între elementele colec Ńiei de date; exist ă un element unic care este denumit nodul
rădăcin ă (root node); orice nod diferit de nodul r ădăcin ă prezint ă un predecessor imediat

6unic; orice nod care nu este terminal prezint ă un num ăr finit de succesori imedia Ńi; între
noduri se stabilesc rela Ńii de tipul “unu-la-mul Ńi);
• structura de date re Ńea (acest tip de structur ă de date se define ște când exist ă o rela Ńie
de preordine între elementele colec Ńiei de date; un nod prezint ă mai mul Ńi predecesori ; un
nod poate fi predecesor pentru propriul s ău predecesor ; între elementele re Ńelei se
stabilesc rela Ńii de tipul “mul Ńi-la-mul Ńi);
• structura de date rela Ńional ă (acest tip de structur ă de date este format ă din mai multe
tabele , rela Ńii sau tablouri de date elementare).
Datele și structurile de date pot fi predefinite sau definite de utilizator .
Lista subiectelor pentru preg ătirea în vederea evalu ării finale:
Întreb ări:
1. Care sunt no Ńiunile fundamentale în organizarea datelor?
2. Ce opera Ńii se pot efectua asupra structurilor de date?
3. Cum se clasific ă structurile de date?
4. Ce semnific ă rela Ńiile între date?

7Prezentarea lec Ńiei / capitolul 2:
2. Teoria bazelor de date și a sistemelor de gestiune a bazelor de date
Organizarea datelor în baze de date. Sisteme de ges tiune a bazelor de date.
Un sistem de calcul din compunerea sistemului infor matic are organizate datele
într-o ierarhie care începe cu bi Ńi și octe Ńi (bytes ) și continu ă cu câmpuri , înregistr ări ,
fi șiere , baze de date și depozite de date .
Sistemul baz ă de date se define ște ca fiind ansamblul de colec Ńii organizate de
date , împreun ă cu descrierea datelor și a rela Ńiilor dintre ele , care reprezint ă, complet,
corect și coerent, universul real al organiza Ńie economice (compartimentului specializat
al acesteia) prin caracteristicile relevante (reprezentative) ale elementelor sale, percepute
de sistem prin semantica lor (semnifica Ńia lor real ă) și prin leg ăturile dintre aceste
caracteristici (fig. 2.1).
Conceptul de baz ă de date a fost introdus în anul 1969, cu prilejul prezent ării
primului raport CODASYL.
Ulterior și alte grupuri de lucru specializate (IIBM, ANSI, D BTG) și-au adus
contribu Ńia la standardizarea conceptelor din teoria bazelor de date.

Fig. 2.1 Definirea conceptului de baz ă de date

Colec Ńia de date , se define ște ca fiind mul Ńimea de valori (date) pe care le iau
caracteristicile reprezentative ale unui element din universul real al organiza Ńiei
economice , dac ă la fiecare moment de timp se aplic ă asupra lor un predicat, o ac Ńiune din
realitatea organiza Ńiei economice , împreun ă cu domeniile de defini Ńie reale ale acestor
caracteristici.
Într-un sistem baz ă de date, descrierea datelor const ă în descrierea structurii de
date a sistemului baz ă de date și în descrierea regulilor care asigur ă coeren Ńa datelor , în
raport cu universul real al organiza Ńiei economice reprezentat. Se reaminte ște c ă tipurile

UNIVERS
REAL DOMENIUL CONCEPTUAL

COLEC łII
DE DATE DOMENIUL
SEMANTIC

**********

CARACTE-
RISTICI BAZA
DE
DATE

SGBD Percep Ńie
Re
Percep Ńie
Reprez

8de structuri logice de date sunt: punctual ă, liniar ă, arborescent ă, re Ńea, rela Ńional ă,
orientat ă pe obiecte (OO).
Structura de date a unui sistem baz ă de date este determinat ă de modelul abstract
de reprezentare a datelor folosit, numit baz ă de date . În func Ńie de tipul stabilit pentru
leg ăturile dintre datele din colec Ńiile de date (ierarhic, re Ńea, rela Ńional, orientat pe
obiecte), s-au realizat mai multe modele abstracte de reprezentare a datelor , dar fiec ăruia
îi corespunde o singur ă structur ă de date a sistemului baz ă de date. Din acest motiv s-a
generalizat utilizarea conceptului de baz ă de date, BD sau DB (DataBase), care este
folosit atât pentru denumirea structurii de date a unui sistem baz ă de date , cât și pentru
denumirea modelului abstract de reprezentare a datelor care o determin ă. Mai mult
chiar, conceptul de baz ă de date denume ște atât colec Ńia organizat ă, cît și structura de
date folosit ă pentru reprezentarea acesteia în sistemul baz ă de date.
Sistemul de gestiune a bazei de date, SGBD sau DBMS (Data-Base Management
System ) reprezint ă un ansamblu complex de programe care asigur ă interfa Ńa dintre baza
de date și utilizator.
O baz ă de date trebuie s ă satisfac ă urm ătoarele condi Ńii :
• structura bazei de date trebuie s ă asigure informa Ńiile necesare și suficiente pentru
îndeplinirea cerin Ńelor de informare și decizie;
• să asigure o independen Ńă sporit ă a datelor fa Ńă de programe și invers;
• să se realizeze o redundan Ńă (cardinalitatea informa Ńiilor colec Ńiilor de date) minim ă
și controlat ă a datelor memorate;
• accesul la datele stocate în baza de date s ă fie rapid și eficace.
O baz ă de date poate s ă fie exploatat ă, de regul ă, în regim de prelucrare pe loturi
(batch) și în regim conversa Ńional. Accesarea bazei de date se realizeaz ă prin aplica Ńii
generale, programe de aplica Ńie, limbaje de manipulare autonome (procedurale și
neprocedurale), interfe Ńe specializate cu limbajele de programare clasice e tc., local sau de
la distan Ńă , prin utilizarea calculatoarelor singulare sau a r e Ńelelor de calculatoare.
Rezultatele interog ărilor utilizatorilor se prezint ă sub form ă vizual ă, listat ă, prin
memorare pe diver și supor Ńi tehnic de date, local sau la distan Ńă .
Sistemul baz ă de date are rolul de organizare și stocare a unor volume mari de
date, în vederea gestion ării, prelucr ării, distribuirii și utiliz ării multiple, folosind
sistemele de calcul, programele utilitare și programele de aplica Ńie.
Pornind de la func Ńia sa, un sistem baz ă de date este format, ca structur ă
general ă, din: colec Ńii de date, baza de date, SGBD, programe de aplica Ńie și utilitare,
precum și utilizatori . Dac ă conceptul de baz ă de date denume ște atât colec Ńiile de date
cît și structura de date folosit ă pentru reprezentarea acesteia, atunci structura ge neral ă a
sistemului baz ă de date este baza de date, SGBD, programe de utilizare, utilizat ori.
Arhitectura unui sistem baz ă de date este prezentat ă în fig.4.2. În conformitate cu
specifica Ńiile utilizatorilor finali ( end-users ), programatorii de aplica Ńie, având la
dispozi Ńie utilitare (programe specializate de proiectare) și prin colaborarea cu
administratorul bazei de date (acesta lucreaz ă nemijlocit cu schema bazei de date), pun la
punct programele de aplica Ńie. A șa cum s-a precizat deja, interfa Ńa dintre baza de date și
schema BD, utilitare și programele de aplica Ńie este sistemul de gestiune a bazei de date,
SGBD.
Obiectivele unui SGBD sunt, în principal, urm ătoarele:
• asigurarea independen Ńei datelor fa Ńă de aplica Ńie;

9• asigurarea redundan Ńei minime și controlate a datelor;
• asigurarea tuturor facilit ăŃilor posibile de exploatare a datelor;
• asigurarea securit ăŃii și protec Ńiei datelor împotriva accesului neautorizat (inclusiv
prin criptarea datelor);
• asigurarea coeren Ńei și integrit ăŃii datelor împotriva ștergerilor accidenta șle sau
inten Ńionate;
• asigurarea partaj ării datelor (accesul concurent al utilizatorilor la baza de da te);
• asigurarea nivelului de performan Ńă global ă (volum mare de date complexe
gestionate cu un timp de r ăspuns acceptabil la adresarea cererilor de interoga re din partea
utilizatorilor multipli).
Func Ńiile generale ale unui SGBD sunt:
1. descrierea datelor (definirea structurii bazei de d ate prin intermediul limbajului de
definire a datelor);
2. manipularea datelor (înc ărcarea, actualizarea, prelucrarea și reg ăsirea datelor cu
ajutorul limbajului de manipulare a datelor);
3. utilizarea bazei de date (de c ătre toate categoriile de utilizatori);
4. administrarea bazei de date.
Fiecare grup de lucru pentru standardizarea bazelor de date (CODASYL și ANSI,
în principal) a propus o arhitectur ă proprie a unui SGBD .
Comenzile SGBD (DBMS) pot fi grupate în trei categorii de limbaje:
a) limbajul de definire a datelor (DDL, Data Defini tion Language);
b) limbajul de manipulare a datelor (DML, Data Mani pulation Language);
c) limbajul de descriere a stoc ării datelor (DSDL, Data Storage Description
Language).
Limbajul de definire a datelor asigur ă, în principal:
• definirea tuturor tipurilor de înregistr ări și de câmpuri de date, precum și asocierea
coresponden Ńei acestora cu nivelul conceptual;
• specificarea ordinii logice a câmpurilor de date;
• definirea câmpurilor ce vor fi folosite drept chei de c ăutare;
• definirea drepturilor de acces;
• definirea leg ăturilor între tipurile de înregistr ări.
Limbajul de manipulare a datelor permite:
• parcurgerea structurilor și a leg ăturilor existente;
• accesul la înregistr ări prin adres ă sau prin con Ńinutul acestora;
• actualiz ări ale înregistr ărilor;
• reordon ări ale câmpurilor de date;
• definirea tranzac Ńiilor și a condi Ńiilor de eroare.
Limbajul de descriere a stoc ării datelor ofer ă posibilit ăŃi de:
• asociere a fi șierelor la programele de aplica Ńie, a dispozitivelor fizice, alocare de
spa Ńii de memorie;
• specificarea zonelor de lucru permanente și tranzitorii;
• definirea și izolarea datelor confiden Ńiale;
• specificarea structurilor de memorare, a mecanismel or de adresare, a modului de
translatare a înregistr ării logice în înregistrare fizic ă;
• crearea indec șilor asocia Ńi cheilor de c ăutare.

10 Opera Ńiile ce se execut ă asupra unei baze de date sunt:
• creare;
• înc ărcare (populare);
• consultare: c ăutare (selec Ńie);
• actualizare: modificare, ad ăugare articole noi, ștergerea unor articole,
ordonare (sortare, indexare), prelucrare etc.

Fig.2.2 Arhitectura unui sistem baz ă de date

Dic Ńionarul de date (Data Dictionary ) este un fi șier care memoreaz ă defini Ńiile
datelor și caracteristicile lor ca: folosirea, reprezentarea fizic ă, proprietatea (cine este
responsabil pentru între Ńinerea lor), autorizarea și securitatea. Prin faptul c ă reprezint ă un
inventar a datelor con Ńinute într-o baz ă de date, dic Ńionarul de date este un important
instrument de management organiza Ńional. În realizarea acestor dic Ńionare de date se
folosesc metadatele . Metadatele reprezint ă date despre date ( nume, con Ńinut,
semnifica Ńie, proprietar etc .).
O baz ă de date este compus ă dintr-o mul Ńime de atribute (câmpuri, coloane) și
are asociat ă o mul Ńime de date (linii, rânduri, înregistr ări, articole). O înregistrare
(record) reprezint ă o asociere a valorilor pentru fiecare câmp ( field ) al bazei de date.
Cele trei nivele de organizare a datelor într-o baz ă de date sunt logic, virtual și
fizic (fig.2.3).

Baza
de
date

SGBD PROGRAM DE
APLICA łIE
SC
HEMA
UT
ILITARE UTI
LIZATORI
ADMINISTRATOR
PROGRAMATOR
DE APLICA łIE

11

Fig.2.3 Niveluri de organizare a datelor într-o baz ă de date

Nivelul logic sau extern (nivelul programatorului de aplica Ńie) calific ă o structur ă
de date ce are o realitate în planul semnifica Ńiei sau utiliz ării, dar nu și în implementarea
fizic ă; calific ă forma în care fiecare utilizator vede structurarea datelor, în func Ńie de
aplica Ńia pe care o folose ște sau în func Ńie de resursele de date pe care administratorul
bazei de date i le pune la dispozi Ńie. Nivelul virtual sau conceptual (nivelul
administratorului bazei de date ) se refer ă la definirea structurii datelor din baza de date
astfel încât aceasta s ă îndeplineasc ă cerin Ńele tuturor utilizatorilor, în condi Ńii de
redundan Ńă minim ă și controlat ă a acesteia. Nivelul fizic (nivelul inginerului de sistem)
prive ște modul de stocare și de structurare a datelor pe suportul fizic de mem orare a
datelor (volum magnetic, cilindru, pist ă, sector, bloc, octet și bit). Structura virtual ă
reprezint ă schema bazei de date , iar structura logic ă este denumit ă subschema bazei de
date (concep Ńia CODASYL). Astfel, se poate concluziona c ă SGBD (DBMS) asigur ă
leg ătura dintre nivelul conceptual (virtual) și nivelul fizic.
O înregistrare virtual ă se poate prezenta sub forma a una sau mai multe
înregistr ări fizice și poate participa la construirea unei sau mai multo r înregistr ări logice.
Într-o baz ă de date ideal ă datele sunt definite o singur ă dat ă și folosite ori de câte
ori este necesar.
În func Ńie de locul în care sunt memorate colec Ńiile de date ce formeaz ă baza de
date , se deosebesc:
• baze de date centralizate , CDB (Centralized DataBases), în situa Ńia în care
toate colec Ńiile care formeaz ă baza de date sunt stocate pe un singur calculator;
• baze de date distribuite , DDB (Distributed DataBases), în situa Ńia în care
colec Ńiile care formeaz ă baza de date sunt r ăspândite în nodurile unei re Ńele de
calculatoare și de comunica Ńii. Dup ă orientare , bazele de date pot fi generalizate
și specializate .
În cadrul DDBMS, accesarea bazelor de date distribu ite, DDB se realizeaz ă, în
principal, prin intermediul limbajului structurat de interogare, SQL (Structured Querry
Language ) și al arhitecturii Client/Server (acestea sunt prezentate pe larg în capitolul 7 al
lucrării).
Realizarea unei baze de date se ob Ńine prin parcurgerea unor etape. SCHEMA
EXTERN Ă 1
SCHEMA
EXTERN Ă 2
SCHEMA
EXTE RN Ă n

SCHEMA
CONCEPTUAL Ă

SCHEMA
FIZIC Ă NIVEL LOGIC NIVEL VIRTUAL NIVEL FIZIC

12 Con Ńinutul acestor etape este dependent, de regul ă, de tipul bazei de date și de
domeniul în care este ea folosit ă. Activitatea de analiz ă a sistemului economic presupune:
a. analiza componentelor sistemului și a leg ăturilor dintre acestea sau analiza
structural ă în urma c ăreia se define ște modelul structural sau static al sistemului
economic;
b. analiza st ărilor sistemului și a tranzac Ńiilor posibile între aceste st ări în raport cu
anumite evenimente. În urma acestei analize rezult ă modelul dinamic sau
temporal;
c. analiza cerin Ńelor informa Ńionale , în urma c ăreia se define ște modelul func Ńional
al sistemului economic;
d. integrarea modelelor sistemului economic (structural, dinamic și func Ńional) în
scopul corel ării și complet ării lor.
Se face men Ńiunea c ă analiza func Ńional ă a sistemului are ca scop determinarea
transform ărilor de date care se produc în cadrul sistemului î n scopul satisfacerii cerin Ńelor
informa Ńionale specifice acestui sistem. Transform ările de date se vor prezenta sub forma
unei diagrame de flux a prelucr ărilor (modelul func Ńional), în care nodurile reflect ă
procesele de prelucrare informa Ńional ă și arcele fluxurile informa Ńionale ale datelor în
baza de date.
La proiectarea unei baze de date, procesul de normalizare ajut ă proiectantul bazei
de date s ă creeze o structur ă a bazei de date care poate economisi spa Ńiul de memorare a
datelor și poate conduce la cre șterea eficien Ńei prelucr ării datelor. Scopul normaliz ării
este de a minimiza redundan Ńa datelor.
Erorile de introducere a datelor pot s ă compromit ă precizia și validitatea bazei de
date. Utilizatorul poate s ă fie uneori în situa Ńia de a nu con știentiza faptul c ă el introduce
date incorecte. Datele incorecte pot proveni, în pr imul rând, de la ap ăsarea gre șit ă a unor
taste. Cele mai multe SGBD-uri pot preveni, dar nu pot elimina introducerile incorecte de
date. Informa Ńia furnizat ă de rutinele de prelucrare și de rapoarte este la fel de precis ă și
corect ă în m ăsura în care aceste caracteristici sunt prezente și la datele stocate în bazele
de date.
Formatul de câmp men Ńine consisten Ńa datelor prin asigurarea unei structuri de
introducere a datelor, a șa cum se arat ă în figura urm ătoare:

Formatul de câmp p entru CONT LA BANCA

Proiectantul bazei de date poate s ă preîntâmpine introducerea datelor incorecte
prin: Format câmp
CONT LA BANC Ă
ROXXAAAAXXXXXXXXXXXXXX
XX
Exemplu RO96RXBR00000004312679 X – cifr ă,
A – liter ă

13 – specificarea unui anumit format de câmp destinat pentru introducerea datelor
(formatul de câmp este de fapt o imagine a cum treb uie s ă arate data atunci
când aceast ă dat ă este introdus ă în baza de date);
– utilizarea regulilor de validare a câmpurilor (acele specifica Ńii prin care se
filtreaz ă datele introduse într-un anumit câmp), a casetelor cu liste sau a
formatelor predefinite.
Lista subiectelor pentru preg ătirea în vederea evalu ării finale:
Întreb ări:
1. Cum se define ște un sistem baze de date?
2. Ce condi Ńii trebuie s ă satisfac ă o baz ă de date?
3. Care sunt obiectivele unui SGBD?
4. Caracteriza Ńi nivelele de organizare a datelor într-o baz ă de date.
5. Preciza Ńi etapele de realizare a unei baze de date.

14 Prezentarea lec Ńiei / capitolul 3:
3.1 Genera Ńii de baze de date și de sisteme de gestiune a bazelor de date
asociate
În evolu Ńia istoric ă, bazele de date și sistemele de gestiune a bazelor de date
(SGBD) asociate au cunoscut trei genera Ńii:
• sistemele ierarhice și re Ńea;
• sistemele rela Ńionale;
• sistemele în tehnologie avansat ă (orientate obiect, rela Ńionale orientate obiect,
deductive, distribuite, multibaze, active, multimed ia, online etc.).
Sistemele ierarhice și re Ńea reprezint ă datele la nivel de articol, prin leg ături
ierarhice (arbore) sau de tip graf re Ńea. Deoarece datele prezint ă o slab ă independen Ńă
fizic ă, SGBD (DBMS) este mai complicat și mai greoi în compara Ńie cu celelalte sisteme.
Drumurile de acces la date sunt specificate prin in termediul limbajului de manipulare a
datelor. Diagrama structurii de date (graf orientat ce reprezint ă tipuri de entit ăŃi și leg ături
func Ńionale dintre ele) serve ște pentru descrierea, la nivel logic, a structurilo r de date
specifice sistemelor ierarhice și re Ńea.
Sistemele rela Ńionale trateaz ă entit ăŃile ca ni ște rela Ńii. Modelul rela Ńional (ce
apar Ńine lui E.F.Codd) reprezint ă un model formal de organizare conceptual ă a datelor, ce
realizeaz ă reprezentarea leg ăturilor dintre date, având la baz ă teoria matematic ă a
rela Ńiilor. Un sistem rela Ńional este compus formal dintr-o baz ă de date rela Ńional ă, o
colec Ńie de operatori rela Ńionali, regulile de integritate care guverneaz ă utilizarea cheilor
în model și un set de asocieri. Elementele de definire a mode lului rela Ńional corespund
celor trei componente ale ingineriei software: info rma Ńie, proces, integritate.
Problematica de detaliu a sistemelor de gestiune a bazelor de date rela Ńionale este tratat ă
în paragraful urm ător.
Sistemele de gestiune a bazelor de date în tehnolog ii avansate elimin ă cea mai
mare parte a acestor dezavantaje. A șa cum s-a ar ătat, în programarea orientat ă pe obiecte,
OOP ( Object-Oriented Programming ), efortul esen Ńial este direc Ńionat pentru definirea
obiectelor. Obiectele de acela și tip formeaz ă o clas ă ce cuprinde, al ături de date, și
metodele de acces la aceste date. Datele sunt trans parente numai pentru metodele asociate
clasei respective (încapsularea datelor). Prin func Ńiile denumite constructori și destructori,
se realizeaz ă controlul asupra creerii și ștergerii unui anumit obiect. Prin mo ștenire, se
ob Ńin clase derivate ce mo ștenesc propriet ăŃile (date și func Ńii) claselor-părinte. Prin
reunirea tehnicilor bazelor de date cu acelea ale l imbajelor orientate obiect s-au ob Ńinut
bazele de date orientate obiect și sistemele de gestiune aferente acestora, OODBMS
(Object-Oriented DBMS) . Se realizeaz ă astfel o organizare coerent ă a obiectelor partajate
între utilizatori concuren Ńi. OODBMS prezint ă urm ătoarele avantaje:
• integrarea descrierii structurale și comportamentale;
• posibilit ăŃi superioare de deduc Ńie (ierarhie de clase, mo ștenire);
• considerarea aspectelor dinamice în cadrul aplica Ńiilor;
• îmbun ătăŃirea interfe Ńei cu utilizatorii.
Se apreciaz ă, totu și, c ă administrarea obiectelor complexe este mai dificil ă decât
accesul la rela Ńii prin cereri SQL, specific bazelor de date rela Ńionale.
Avantajele incontestabile ale tehnologiei orientate obiect au fost combinate cu
acelea ale modelului rela Ńional, rezultând bazele de date rela Ńionale orientate obiect .

15 Rela Ńiile sunt mul Ńimi de înregistr ări ce reprezint ă fapte. Cuno știn Ńele se definesc
ca ase Ńiuni generale și abstracte asupra faptelor. Pe baza faptelor cunos cute tezaurizate în
cuno știn Ńe, se pot deduce noi fapte printr-un proces de ra Ńionamente. Bazele de date
deductive ce folosesc programarea logic ă (specific ă inteligen Ńei artificiale) administreaz ă
cuno știn Ńe relativ la baze de date ce sunt, de regul ă, RDB .
Sistemele multibaze de date sunt compuse din mai multe sisteme de baze de date
ce sunt integrate pe baza schemelor globale. Se rea lizeaz ă astfel accesul uniform și
integrat la fiecare dintre bazele de date component e.
Dac ă se consider ă scopul esen Ńial de analiz ă a datelor, inclusiv istorice, pentru
toat ă organiza Ńia, o baz ă de date optimizat ă în acest scop define ște o Data Warehouse
(depozit de date), dup ă principiul proces ării analitice, OLAP ( On-Line Analytical
Processing ). Sistemele tranzac Ńionale (ce se folosesc pentru prelucrarea datelor
opera Ńionale ale organiza Ńiei economice) au la baz ă principiul proces ării tranzac Ńionale
online , OLTP ( On-Line Transactional Processing ), de control la un moment dat al unei
singure tranzac Ńii. Data Warehouse admite interog ări ce nu sunt predefinite și ofer ă
răspunsuri ad-hoc pe baza analizelor datelor ce se refer ă la întreaga organiza Ńie. Data
Warehouse se subdivide în baze de date departamentale (domen ii de gestiune ale
organiza Ńiei) denumite rafturi de date (Data Marts ).
Realizarea sistemelor de sprijin al deciziilor, DSS (Decision Support Systems )
implic ă un proces laborios de descoperire a informa Ńiilor utile din cadrul bazelor mari de
date. Procesul este denumit Data Mining (« mineritul datelor ») sau de descoperire a
cuno știn Ńelor în baza de date, KDD ( Knowledge Discovery in Databases ).
O baz ă de date OLAP poate s ă fie baz ă de date rela Ńional ă, dar și baz ă de date
multidimensional ă. Structura unei baze de date multidimensionale con Ńine obiecte de
urm ătoarele tipuri: variabile, dimensiuni, niveluri, ie rarhii, atribute.
Lista subiectelor pentru preg ătirea în vederea evalu ării finale:
Întreb ări:
1. Câte sisteme de gestiune a bazelor de date exist ă?
2. Prin ce se caracterizeaz ă sistemele de gestiune rela Ńionale?
3. Prin ce se caracterizeaz ă sistemele de gestiune a bazelor de date în tehnolo gie
avansat ă?
4. Prin ce se caracterizeaz ă sistemele multibaze de date?

16 Prezentarea lec Ńiei / capitolul 4:
4.1 Baze de date rela Ńionale .
Termenul de baz ă de date rela Ńional ă (BDR) a fost introdus de E.F.Codd de la
firma IBM în anul 1969. Modelul rela Ńional este fundamentat pe reguli, structuri și
opera Ńii . Regulile stabilesc modul de manipulare a datelor, structurile sunt obiecte
definite ce con Ńin date și care sunt accesibile utilizatorului, iar opera Ńiile reprezintă
ac Ńiuni prin care sunt manipulate datele sau obiectele schemei bazei de date. E.F.Codd a
formulat în anul 1985 cele 13 reguli de baz ă care definesc o baz ă de date rela Ńional ă și
care sunt prezentate în tabelul urm ător:

Nr.
regulii Con Ńinutul regulii Comentarii
R0 SGBD gestioneaz ă datele la nivel de
rela Ńie (exclusiv pe baza
caracteristicilor rela Ńionale). Conceptul de baz ă este rela Ńia .
R1 Toate datele din baza de date
rela Ńional ă se reprezint ă explicit sub
forma unor valori într-un tabel (regula
reprezent ării logice a datelor). Catalogul con Ńine denumiri de
tabele, coloane, domenii, restric Ńii
de integritate etc.
R2 Datele individuale dintr-un tabel sunt
accesate prin specificarea numelui
tabelului, a valorii cheii primare și a
coloanei (regula garant ării accesului la
date) Datele sunt accesibile prin numele
tabelului, a liniei și a coloanei.
R3 Valorile NULL (inexisten Ńa datelor)
sunt tipuri de date acceptate (regula
referitoare la valorile NULL). Valoarea NULL semnific ă „nimic”.
A nu se confunda cu zero (0).
R4 Baza de date rela Ńional ă reprezint ă
descrierea bazei de date în format logic
simplificat sub form ă de tabele (regula
metadatelor). Metadatele sunt date despre date.
Regula nu face diferen Ńieri între
tratarea datelor și a metadatelor.
R5 Modelul rela Ńional permite
implementarea mai multor limbaje
(regula de permisiune a limbajelor
multiple). SQL este limbajul de baz ă pentru
realizarea interog ărilor asupra bazei
de date.
R6 Dac ă vederea curent ă reprezint ă un
tabel, toate vederile (view-urile) sunt
actualizabile (regula actualiz ării
vederilor). Toate tabelele virtuale ce teoretic
sunt posibil de actualizat, trebuie s ă
fie în mod practic actualizate.
R7 În opera Ńiile de schimbare a
con Ńinutului bazelor de date, se
lucreaz ă la un moment dat pe toat ă
rela Ńia (regula referitoare la
actualiz ări, inser ări și ștergeri în baza
de date). Modelul rela Ńional abordeaz ă
rela Ńiile de baz ă și pe cele derivate
ca pe un singur operand destinat
opera Ńiilor de actualizare ( update ),
inserare ( insert ) și ștergere ( delete )
efectuate asupra datelor.
R8 Structura logic ă a bazei de date se Programele de aplica Ńie nu trebuie

17 prezint ă complet separat ă de structura
fizic ă a bazei de date (regula
referitoare la independen Ńa fizic ă a
datelor). să fie influen Ńate de schimb ările
survenite în modul de reprezentare a
datelor sau în metodele de acces.
R9 Atunci când bazei de date i se aduc
modific ări neconforme, datele se
conserv ă ( regula referitoare la
independen Ńa logic ă a datelor). Programele de aplica Ńie nu trebuie
să fie influen Ńate de schimb ările
efectuate asupra rela Ńiilor bazelor de
date.
R10 Restric Ńiile de integritate sunt definte în
limbajul folosit de sistem (regula
referitoare la restric Ńiile de integritate). Restric Ńiile de integritate sunt create
în limbajul SQL și se stocheaz ă în
dic Ńionarul bazei de date și nu în
aplica Ńiile individuale.
R11 Accesarea datelor pe server de c ătre
client se produce în mod continuu
(regula referitoare la distribuirea
geografic ă a datelor). Este presupus ă producerea unui
proces de copiere a datelor dintr-o
baz ă de date localizat ă la distan Ńă .
R12 Regulile și restric Ńiile de integritate nu
pot fi evitate de nici un limbaj de acces
la date (regula referitoare la
prelucrarea datelor la nivel de baz ă). Nu trebuie folosit un limbaj de nivel
sc ăzut orientat pe prelucrarea pe
tupluri.

Trebuie precizat faptul c ă nici un SGBD actual nu respect ă în totalitate cele 13
reguli ale lui Codd.
Așa cum s-a ar ătat, o baz ă de date rela Ńional ă reprezint ă o colec Ńie de rela Ńii
(tabele în accep Ńiunea uzual ă, memorate fizic în fi șiere). Coloanele tabelului se numesc
atribute , iar liniile se numesc tupluri .
Baza de date rela Ńional ă (RDB) este compus ă dintr-o mul Ńime de domenii și o
mul Ńime de rela Ńii peste care se aplic ă o mul Ńime de asocieri. Domeniul este definit ca
mul Ńimea obiectelor de acela și tip. Rela Ńia este o mul Ńime rezultat ă ca urmare a agreg ării
(coresponden Ńei) a dou ă sau mai multe mul Ńimi. O rela Ńie în accep Ńiunea bazelor de date
pe domeniile Di const ă dintr-un cap de tabel și un corp de tabel. Asocierea se realizeaz ă
pe baz ă de atribute (din capul de tabel).
Un astfel de exemplu este tabelul (rela Ńia) referitor la MATERIALE:
Cod_material Denumire_material Cantitate Pret_unitar
01212 Tabl ă 1200 180000
03214 Cornier 400 420000
04301 Cherestea 850 210000

Fiecare linie descrie un anumit material. Coloanele con Ńin etichete ce reprezint ă
nume ale atributelor (Cod_material, Denumire_material, Cantitate, Pret_un itar ).
Domeniul ce reprezint ă codurile materialelor este:
D1: {“01212”,”03214”,”04301”}.
iar domeniul pentru tipurile de materiale (delimita te prin denumire_material) este:
D2: {“TABLA”,”CORNIER”,”CHERESTEA”}.
Domeniul pentru cantitate este:
D3: {“1200”,”400”,”850”}.

18 Domeniul pre Ńurilor unitare, în acest caz, este:
D4: {pret_unitar pret_unitar ∈[180000,420000]}.
Mul Ńimea tuplurilor este definit ă prin produsul cartezian al domeniilor
D1 X D2 X …X Dn. Exemplu de tuplu: <”01212”,”TABLA”,”1200”,”180000” >.
Rela Ńia L se define ște prin tupluri corespunz ătoare din tabel:
L: {<”01212”,”TABLA”,”1200”,”180000”>, <”03214”,”CORNIE R”,”400”,”420000”> }.
Într-o rela Ńie , este necesar ca tuplurile s ă fie distincte (nu se permit valori duplicate). Ca
urmare, se observ ă c ă rela Ńia este reprezentat ă prin tabelul bidimensional în care
coloanele sunt domenii iar liniile sunt tupluri. Nu m ărul tuplurilor unei rela Ńii este
cardinalul rela Ńiei . Num ărul valorilor unui tuplu este gradul rela Ńiei . Schema unei rela Ńii
este format ă din numele rela Ńiei și lista atributelor (pentru fiecare atribut este ne cesar ă
specificarea domeniului asociat).
Modelul rela Ńional este format din dou ă mul Ńimi de operatori pe rela Ńii: algebra
rela Ńional ă și calculul rela Ńional .
E.F.Codd a definit algebra rela Ńional ă ca o colec Ńie de opera Ńii pe rela Ńii , astfel
încât o anumit ă opera Ńie dispune de operanzi de tipul rela Ńie și are ca rezultat tot o rela Ńie.
Tipurile de opera Ńii acceptate de algebra rela Ńional ă sunt opera Ńii de baz ă (reuniunea,
diferen Ńa, proiec Ńia, produsul cartezian ș.a.), opera Ńii derivate (intersec Ńia și diviziunea) și
opera Ńii suplimentare (selec Ńia, splitarea unei rela Ńii, complementarea unei rela Ńii,
închiderea tranzitiv ă, jonc Ńiunea etc.). Algebra rela Ńional ă permite derivarea procedural ă
a rela Ńiilor .
Se prezint ă ca exemplu reuniunea . Reuniunea (notat ă cu OR , ∪∪ ∪∪, APPEND sau
UNION ) este o opera Ńie definit ă pe rela Ńiile Rel1 și Rel2 (cu aceea și schem ă), ce
genereaz ă o nou ă rela Ńie Rel3 (cu schema identic ă cu a rela Ńiilor Rel1 și Rel2 ) care este
format ă din reuniunea tuplurilor rela Ńiilor Rel1 și Rel2 din figura de mai jos.
Calculul rela Ńional con Ńine mul Ńimea operatorilor din modelul rela Ńional și este o
adaptare a calculului cu predicate (o rela Ńie este identificat ă cu un predicat) pentru
domeniul BDR. Calculul rela Ńional asigur ă definirea neprocedural ă, declarativ ă a
rela Ńiilor. Rela Ńiile sunt precizate prin propriet ăŃile tuplurilor. Ini Ńial, în BDR, variabilele
definite asupra rela Ńiilor aveau valori care reprezentau tupluri de rela Ńie (variabile tuplu),
ob Ńinându-se calculul rela Ńional orientat pe tuplu . Când variabilele opereaz ă asupra
domeniilor – așa cum se petrec lucrurile în prezent – ele sunt var iabile domeniu și
determin ă calculul rela Ńional orientat pe domeniu. Regulile de integritate sunt aser Ńiuni
pe care datele ce formeaz ă baza de date trebuie s ă le satisfac ă și sunt în num ăr de trei:
unicitatea cheii (cheia primar ă trebuie s ă fie unic ă și minimal ă), integritatea entit ăŃii
(atributele cheii primare trebuie s ă fie diferite de null) și integritatea referirii (o cheie
extern ă trebuie s ă fie null în întregime sau s ă corespund ă unei valori a cheii primare
asociate). Constrângerile structurale sunt de trei tipuri: de cheie, de referin Ńă și de entitate.

Rel1
R
Rel2 Rel3

19

Diagrama opera Ńiei reuniune

Cheia unei rela Ńii reprezint ă o mul Ńime minimal ă de atribute ale c ăror valori
identific ă în mod unic un tuplu într-o rela Ńie. Diferitele chei posibile se numesc chei-
candidat . Cheia candidat aleas ă pentru a identifica efectiv tupluri se nume ște cheie
primar ă.
Conceptele folosite pentru descrierea formal ă, uzual ă și fizic ă a elementelor de
baz ă ale organiz ării datelor în baze de date rela Ńionale sunt prezentate în tabelul 4.2 [44].

Tabelul 4.2
Formal Uzual Fizic
Rela Ńie tablou Fi șier
Tuplu linie Inregistrare
Atribut coloan ă Câmp
Domeniu tip de dat ă tip de dat ă

Definirea propriet ăŃilor structurale ale rela Ńiilor se realizeaz ă prin tehnica
normaliz ării . Se afirm ă c ă o rela Ńie se g ăse ște într-o form ă normal ă particular ă dac ă
îndepline ște un num ăr specificat de restric Ńii . Normalizarea se ob Ńine printr-un num ăr de
pa și succesivi, în cadrul unui proces reversibil, pân ă la realizarea formei dorite. Forma
normal ă a unei rela Ńii este necesar ă deoarece formele normale nu produc anomalii în
actualizarea datelor unei baze de date rela Ńionale. Tipurile de restric Ńii folosite la formele
normale ale rela Ńiilor sunt restric Ńiile asupra valorilor atributelor, restric Ńiile referitoare la
dependen Ńa atributelor secundare de chei, restric Ńiile cu privire la dependen Ńa atributelor
principale de toate atributele. Se folosesc urm ătoarele forme normale:
• 1NF (forma normal ă 1). O rela Ńie se g ăse ște în 1NF dac ă domeniile pe care
sunt definite atributele rela Ńiei sunt formate numai din valori elementare. Un tu plu
nu trebuie s ă con Ńin ă atribute sau grupuri de atribute repetitive (nu se admit
duplicate).
• 2NF (forma normal ă 2). O rela Ńie se afl ă în 2NF dac ă este în 1NF și oricare
dintre atributele non-cheie este dependent func Ńional complet de cheia primar ă a
rela Ńiei.
• 3NF (forma normal ă 3). O rela Ńie se g ăse ște în 3NF dac ă este în 2NF și
atributele non-cheie nu sunt dependente tranzitiv d e cheia primar ă a rela Ńiei.
• BCNF (forma normal ă Boyce-Codd). O rela Ńie este în BCNF dac ă
dependen Ńele func Ńionale netriviale ce pot apare în cadrul rela Ńiei con Ńin, în partea
stâng ă, ca determinant, o cheie-candidat.

20 • 4NF (forma normal ă 4). O rela Ńie se g ăse ște în 4NF dac ă în cadrul acesteia nu
se manifest ă mai mult decât o dependen Ńă multivaloare.
• 5NF (forma normal ă 5). O rela Ńie L se g ăse ște în 5NF dac ă fiecare dependen Ńă
jonc Ńiune este implicat ă printr-o cheie-candidat a lui L.
Bazele de date rela Ńionale con Ńin structuri de date simple și intuitive. Ele prezint ă
avantaje legate de existen Ńa unui ansamblu integrat de utilitare bazat pe un l imbaj evoluat
de programare (generatoare de meniuri, generatoare de forme, generatoare de aplica Ńii,
generatoare de etichete), de existen Ńa unor limbaje speciale de definire și de manipulare a
datelor, precum și de independen Ńa complet ă în descrierea logic ă a datelor (în termeni de
rela Ńii) și în descrierea fizic ă a datelor (în termen de fi șiere). Dintre dezavantajele bazelor
de date rela Ńionale, se men Ńioneaz ă imposibilitatea utiliz ării obiectelor complexe și
dinamice, a administr ării datelor distribuite și a cuno știn Ńelor.
Lista subiectelor pentru preg ătirea în vederea evalu ării finale:
Întreb ări:
1. Care sunt genera Ńiile de baze de date si de SGBD-uri?
2. Din ce se compune baza de date rela Ńional ă?
3. Cum se define ște rela Ńia?
4. Care sunt formele normale și prin ce se caracterizeaz ă?
Studiu de caz:
Stabili Ńi tabelele necesare și structura îregistr ărilor pentru proiectarea unei baze de
date rela Ńionale care se refer ă la activit ăŃi din domeniul administra Ńiei publice.

21 Prezentarea lec Ńiei / capitolul 5:
5.1 Baze de date orientate obiect
Bazele de date orientate pe obiecte, OODB (Object-O riented DataBase) și SGBD
asociate asigur ă crearea de obiecte complexe formate din componente simple, fiecare
prezentând atribute și comportament propriu. Aceste sisteme se mai numes c și sisteme de
obiecte , cu originea în limbajele de programare orientate pe obiecte, OOP. Prin aceste
tipuri de baze de date se ridic ă nivelul de abstractizare. Se face men Ńiunea c ă între partea
de limbaje de programare și partea de baze de date exist ă multe elemente comune; cu
toate acestea, aceste p ărŃi sunt diferite:
• un program pe calculator este gândit s ă rezolve o anumit ă problem ă;
• o baz ă de date este realizat ă pentru a rezolva o multitudine de probleme, inclus iv cu
elemente de pornire nedeterministe.
Pentru un program, obiectele complexe simplific ă problema, în timp ce în situa Ńia
bazelor de date orientate pe obiecte, de regul ă, problemele se complic ă. Ca urmare, se
cuvine s ă se judece în mod nuan Ńat atunci când se încearc ă reliefarea avantajelor utiliz ării
OOP și OODB.
Sistemul de gestiune al bazelor de date orientate pe obiect ( SGBD-OO sau
OODBMS ) are ca principale obiective [18]:
1. Modelarea superioar ă a datelor , ceea ce semnific ă dezvoltarea de noi aplica Ńii;
extinderea posibilit ăŃilor de generalizare și agregare a rela Ńiilor; evolu Ńia c ătre multimedia
și hipermedia (sunet, imagine, texte).
2. Capacitatea de deduc Ńie superioar ă (ierarhie de clase, mo ștenire);
3. Îmbun ătăŃirea interfe Ńei cu utilizatorul:
4. Capacitatea de tratare dinamic ă, concomitent cu integrarea descrierii structurale și
comportamentale.
Modelul de dat ă-obiect asigur ă reprezentarea unor structuri de date complexe și a
unor ierarhii model, creind posibilitatea de defini re a unor tipuri de date care combin ă
atât structura de date cât și definirea procedurii. Un model de date orientat p e obiecte are
la baz ă no Ńiunea de entitate conceptual ă și define ște un obiect ca o colec Ńie de propriet ăŃi
care descriu entitatea. O compara Ńie între no Ńiunile clasice și cele asociate bazelor de date
orientate pe obiecte este prezentat ă, dup ă Date, în tabelul urm ător:

Nr.crt No Ńiunea specific ă obiectelor No Ńiunea clasic ă de compara Ńie
1. Obiect nemutabil (care nu se poate muta) Valoare
2. Obiect mutabil (care se poate muta) Variabil ă
3. Clasa de obiecte Tip
4. Metoda Operator
5. Mesaj Invocarea de operator

Obiectul reprezint ă conceptual o unitate identificabil ă cu con Ńinut propriu, care se
deosebe ște de ceea ce o înconjoar ă. Fiecare obiect dispune de un identificator unic,
denumit ID al obiectului, OID (Object ID ). Dou ă obiecte cu OID diferi Ńi sunt diferite,
chiar dac ă sunt identice sub toate aspectele transparente uti lizatorului.
De și tenta Ńia ini Ńial ă este de a considera obiecte doar unit ăŃile ce se pot muta, prin
obiecte se desemneaz ă atât unit ăŃile fixe cât și cele mutabile. Fiecare obiect posed ă un tip

22 care semnific ă o clas ă de obiecte . Instan Ńa unui obiect reprezint ă un obiect individual.
Obiectele sunt încapsulate . Structura obiectului și modul de ac Ńiune al metodelor sale nu
pot fi accesate și actualizate direct de un agent extern, dar pot fi modificate indirect prin
intermediul mesajelor. Aceast ă caracteristic ă ascuns ă a obiectului se nume ște
încapsulare . Încapsularea presupune independen Ńa fizic ă de date. Astfel, prin
încapsulare, reprezentarea intern ă a unui obiect poate s ă fie modificat ă f ără a fi nevoie ca
aplica Ńiile care utilizeaz ă obiectul s ă fie rescrise.
Starea unui obiect este exprimat ă prin valorile atributelor sale. Colec Ńia de atribute
trebuie aleas ă astfel încât s ă descrie entitatea, adic ă s ă cuprind ă atribute pe care
utilizatorul trebuie s ă le cunoasc ă. Metoda reprezint ă un program care manipuleaz ă
obiectul sau indic ă starea sa. Ea este asociat ă unei clase, iar specificarea metodei se
nume ște „ semn ătur ă”.
Comportamentul unui obiect reprezint ă un set de metode sau opera Ńii care
ac Ńioneaz ă asupra atributelor sale.
Obiectele se clasific ă în:
• obiecte elementare ca: întreg, boolean, șir de caractere;
• obiecte compuse ca: nume, adres ă;
• obiecte complexe ca: autoturism, angajat.
Un obiect înglobeaz ă urm ătoarele elemente:
a. structura de date;
b. specificarea opera Ńiilor;
c. implementarea opera Ńiilor.
Structura unui obiect și opera Ńiile (metodele) permise pentru acel obiect sunt
definite împreun ă.
Metodele și atributele nu sunt vizibile din „exteriorul” obie ctului. Un obiect
răspunde la mesaje care reprezint ă cereri adresate obiectului pentru a returna o valo are
sau pentru a-și schimba starea.
Un obiect este divizat în interfa Ńă public ă și în memorie privat ă. Interfa Ńa public ă
este compus ă din defini Ńiile interfe Ńelor (corespunz ătoare semn ăturilor specifica Ńiei ).
Interfa Ńa public ă nu face parte din obiectul corespunz ător. Aceast ă interfa Ńă public ă este
inclus ă în obiectul de definire a clasei, CDO (Class-Defining Object) . CDO este obiectul
ce define ște clasa pentru care obiectul considerat reprezint ă o instan Ńă (este similar unui
descriptor ). Memoria privat ă este compus ă din variabile de instan Ńă (atribute sau
membri ) ale c ăror valori reprezint ă starea intern ă a obiectului. Deoarece sistemele baze
de date orientate pe obiecte reale nu sunt „pure” ( cu variabile instan Ńă care sunt
netransparente utilizatorului), variabilele de inst an Ńă apar ca transparente utilizatorului.
Se deosebesc variabile de instan Ńă publice (transparente utilizatorului) și variabile de
instan Ńă private (cele netransparente utilizatorului).
Persisten Ńa este o proprietate a datelor sau a obiectelor care presupune existen Ńa
lor pe o durat ă mai mare în compara Ńie cu aceea a procesului care le-a generat. Persist en Ńa
reprezint ă proprietatea prin care starea bazei de date asigur ă execu Ńia unui proces pentru a
fi refolosit ulterior în alt proces. Deoarece face parte integrant ă din obiect, codul aferent
metodelor este stocat în baza de date (ca și starea obiectului).

23 Tipuri și clase
Obiectele care prezint ă acela și fel de atribute și acela și comportament fac parte
din acela și tip sau clas ă. În raport cu aceast ă caracteristic ă exist ă dou ă categorii de
sisteme orientate pe obiecte :
a) sisteme care admit ca no Ńiune de baz ă clasa, cum ar fi: VISION, ORION, G-
BASSE;
b) sisteme care admit ca no Ńiune de baz ă tipul, cum sunt: C ++ , Simula, O 2.
Într-un sistem orientat pe obiecte, tipul sintetizeaz ă elementele comune ale unui
set de obiecte cu acelea și caracteristici. Acest sistem are ca și componente, interfa Ńa și
implementarea . Interfa Ńa este partea vizibil ă pentru utilizator și const ă într-o list ă de
opera Ńii. Implementarea presupune descrierea structurii interne a datelor obiectului și
realizarea procedurilor de implementare a opera Ńiilor interfe Ńei.
Un tip este construit recursiv, începând cu tipurile de b az ă: caracter, întreg, real,
șir de caractere, boolean. Constructorii de tipuri s unt: tuplul, lista, setul și clasa. O list ă
este o colec Ńie ordonat ă de obiecte ale aceleia și clase sau de valori ale aceluia și tip.
Elementele unei liste sunt accesibile direct prin r angul lor.
Opera Ńiile permise asupra listelor sunt: afectarea (=), compara Ńia (= =),
concatenarea (+), accesul direct ([i]), apartenen Ńa (in), sublista ([i ; j]), num ărarea
(count ( ) ), înlocuirea , ștergerea (list ( ) ), inserarea ([:i]+=), itera Ńia ( { }).
No Ńiunea de clasă, de și are aceea și specifica Ńie cu cea de tip, este asociat ă cu faza
de execu Ńie. Ea presupune generarea de obiecte prin opera Ńia „ new ” aplicat ă unei clase și
stocarea setului de obiecte care reprezint ă instan Ńele clasei. Descrierea clasei serve ște ca
șablon pentru crearea obiectele noi.
O clas ă este un tip abstract de date care define ște atât structura obiectelor din
clasa respectiv ă, cât și mul Ńimea metodelor existente pentru aceste obiecte . Astfel,
obiectele din aceea și clas ă prezint ă acelea și atribute și acelea și metode și r ăspund la
acela și mesaj.

Mo ștenirea
Într-o baz ă de date orientat ă pe obiecte , clasele sunt aranjate într-o ierarhie în
care fiecare clas ă mo ștene ște toate atributele și metodele superclasei din care face parte.
Mo ștenirea conduce la reutilizarea codului. Mo ștenirea reprezint ă mecanismul de
realizare a definirii unei clase în care deriv ă variabilele de instan Ńă și metodele din alt ă
definire de clas ă. Când o clas ă mo ștene ște, ea este considerat ă ca subclas ă. Conceptele de
subclas ă și superclas ă sunt analoge conceptelor de generalizare și specializare.
Obiectele , clasele și mo ștenirea formeaz ă baza modelului de date orientat pe
obiecte și presupune urm ătoarele aspecte:
• obiectele sunt entit ăŃi de baz ă care înglobeaz ă structuri de date și opera Ńii;
• fiecare obiect are asociat un identificator care este unic și asigurat de sistem;
• clasele descriu tipuri generice de obiecte , toate obiectele sunt membrii unei clase;
• clasele sunt înrudite prin mo ștenire ;
• definirea unei clase este mecanismul de specificare a schemei bazei de date ;
• definirea unei clase poate include variabile de ins tan Ńă , având tipuri de date definite de
sistem sau de utilizator;
• schema bazei de date poate fi extins ă dinamic prin definirea de noi clase.

24 Opera Ńiile modelului de date orientat pe obiecte
Opera Ńiile se pot grupa în modul urm ător:
a) obiectele comunic ă între ele prin mesaje;
b) un mesaj poate fi trimis instan Ńelor mai multor clase;
c) metodele pot fi definite, șterse sau modificate;
d) clasele pot fi definite și actualizate prin opera Ńii de creare, ștergere și modificare;
e) instan Ńa unei clase poate fi actualizat ă prin metode care modific ă valorile variabilelor
propriei instan Ńe, aceasta modificând starea intern ă a obiectului.
Într-o serie de implement ări, definirile de clas ă sunt ele însele obiecte, numite
obiecte de clas ă. Obiectele clas ă sunt instan Ńe ale unei clase generice sau ale unei
metaclase . Opera Ńiile de creare, modificare și ștergere ale definirilor de clas ă pot fi și
implementate ca mesaje. În modelul de date orientat pe obiecte, regulile de integritate
reprezint ă o consecin Ńă a structurii modelului și a urm ătoarelor opera Ńii:
• toate obiectele trebuie s ă respecte protocolul specificat de definirile lor d e clas ă;
• obiectele sunt încapsulate , acest lucru presupunând accesul limitat la obiect e prin
folosirea protocolului de mesaje definit pentru cla sa obiectului;
• identificatorul obiectului asigur ă integritatea referirii la un obiect. Ca atare, un obiect
nu exist ă f ără s ă aib ă asignat un identificator. Dac ă un obiect este șters sau mutat,
identificatorul s ău trebuie și el șters sau mutat.
O schem ă complet ă a unei baze de date orientat ă pe obiecte poate consta din una
sau mai multe ierarhii de clas ă, împreun ă cu rela Ńiile structurale.
Modificarea schemei presupune :
1. Definirea unei taxonomii și a unui model al schimb ărilor . Taxonomia define ște un set
de schimb ări semnificative ale schemei, iar modelul furnizeaz ă o baz ă pentru specificarea
semanticilor schimb ărilor schemei;
2. Implementarea schimb ărilor schemei . Aceste schimb ări pot fi:
a) schimb ări referitoare la modul de definire al unei clase . Acestea includ schimb ările
atributelor și metodelor definite pentru o clas ă, cum ar fi: schimbarea numelui sau
domeniul unui atribut, ad ăugarea, ștergerea unui atribut sau a unei metode;
b) schimb ări referitoare la structura ierarhiei de clase care includ ad ăugarea sau
ștergerea unei clase și schimbarea rela Ńiilor superclas ă/subclas ă dintre o pereche de
clase.

Proiectarea bazei de date orientat ă pe obiecte
Pentru proiectarea unei baze de date orientat ă pe obiecte se folose ște tehnica top-
down care const ă în identificarea componentelor dup ă care se stabilesc corela Ńiile între
ele și se rafineaz ă succesiv în „cascad ă” componentele sale. Se poate utiliza și metoda
bottom-up prin care mai întâi se identific ă componentele func Ńionale pe baza c ărora se
vor identifica, în colec Ńiile existente, obiectele, care pot fi reutilizate pentru noul proiect.
Componentele care nu exist ă vor fi create ca subclase ale unor clase existente . O dat ă
creat ă o ierarhie potrivit ă, se testeaz ă componentele specifice.
Sistemul de gestiune al bazelor de date orientate pe obiecte (SGBD-OO sau
OODBMS) con Ńine structuri și reguli orientate c ătre lucrul cu obiecte, incluzând:
• un sistem de date abstracte pentru construirea de n oi tipuri de date;
• un constructor de tip șir;
• un constructor de tip secven Ńă ;

25 • un constructor de tip înregistrare;
• un constructor de tip set;
• func Ńii;
• un constructor de tip reuniune;
• o compunere recursiv ă a elementelor anterioare.
În proiectarea SGBD-OO se au în vedere urm ătoarele:
Principiul 1. SGBD-OO utilizeaz ă func Ńii care con Ńin metode și proceduri ale
bazei de date, cu restric Ńia ca acestea s ă fie cât mai compacte, încapsulate, ermetizate.
Încapsularea func Ńiilor îl ajut ă pe programatorul de aplica Ńie s ă asocieze func Ńiile pe care
și le creeaz ă cu colec Ńiile utilizate.
Principiul 2. SGBD-OO și în general SGBD–urile din genera Ńia a treia vor prelua
avantajele SGBD–urilor din genera Ńia a doua. În plus, se caut ă o modalitate de acces la o
înregistrare existent ă într-o colec Ńie oarecare și aceasta se poate realiza prin utilizarea
unui sistem de pointeri c ătre identificatorii de obiecte.
Principiul 3. SGBD-OO trebuie s ă poat ă conecta și limbaje din genera Ńia a patra.
Un SGBD-OO lucreaz ă cu obiecte complexe, obiecte care se ob Ńin prin aplicarea
de constructori asupra obiectelor simple.
Identitatea obiectelor . Orice obiect exist ă independent de valorile atributelor sale,
ceea ce conduce la dou ă rela Ńii posibile:
– identitatea a dou ă obiecte, adic ă sunt unul și acela și obiect;
– egalitatea a dou ă obiecte, adic ă au aceea și valoare.
Arhitectura SGBD-OO cuprinde trei componente:
1. Gestionarul de obiecte (Object Manager ) furnizeaz ă interfa Ńa dintre procesele
externe și SGBD-OO.
2. Server-ul de obiecte (asigur ă gestiunea tranzac Ńiei și gestiunea stocului de
obiecte);
3. Stocul rezident de obiecte .
Gestionarul de obiecte asigur ă implementarea complet ă a modelului de date-
obiecte pentru utilizatorul extern. Acest lucru inc lude posibilitatea de a defini structurile
și de a executa opera Ńiile specificate prin model. El prime ște cereri de creare de definiri
de clase, de modificare a definirilor de clase deja existente, de manipulare a mesajelor
generate de un program de aplica Ńie în execu Ńie.
Server-ul de obiecte asigur ă refacerea, inser Ńia, ștergerea și actualizarea obiectelor
în stocul rezident de obiecte. Un singur server poa te manipula tranzac Ńii transmise de la
mai mul Ńi gestionari de obiecte.
Limbajul de definire a datelor este realizat prin mecanismul de transmitere a
mesajelor. Limbajul pentru cereri ad-hoc se bazeaz ă pe transmitere de mesaj pentru
selectarea și reg ăsirea obiectelor.
Prelucrarea mesajelor. Gestionarul de obiecte asigur ă interfa Ńa dintre procesele
externe și SGBD-OO. El prime ște mesaje pentru obiecte individuale, realizeaz ă leg ături
dinamice și opera Ńii de verificare a tipului și expediaz ă cerin Ńa extern ă pentru obiecte,
către server-ul de obiecte.
Transmiterea de mesaje și prelucrarea cererii poate fi reprezentat ă astfel:
– controlul sesiunii (men Ńinerea spa Ńiului local de lucru al utilizatorului extern pentr u
opera Ńii efectuate asupra bazei de date);

26 – leg ătura dinamic ă (selectarea unei metode pentru un mesaj trimis unu i obiect în
momentul execu Ńiei);
– crearea de noi obiecte sau instan Ńe de clas ă trebuie ini Ńiat ă de gestionarul de obiecte;
– transmiterea cerin Ńelor obiectului și actualizare acestuia;
– transmiterea cererii . Cererile pot fi translatate în planuri de execu Ńie în care selec Ńia și
reg ăsirea obiectelor sunt realizate prin transmiterea d e mesaje. Aceasta presupune c ă
protocolul de mesaje al clasei obiectului este defi nit pentru a permite accesul la
variabilele de instan Ńă necesare pentru a selecta obiectul. Obiectele, def inirile de clas ă și
metodele cerute de gestionarul de obiecte sunt reg ăsite de server -ul de obiecte din stocul
rezident de obiecte .
Definirea și modificarea schemei const ă din urm ătoarele etape :
1. Asigurarea accesului la definirile de clas ă existente . Definirile tuturor claselor
asigurate de SGBD-OO, ca și a claselor create de utilizatorii umani, pot fi s tocate
permanent în SRO, într-o bibliotec ă de clas ă sau într-un dic Ńionar de date.
2. Extensibilitatea schemei bazei de date . Aceasta include prelucrarea declara Ńiilor
limbajului de baza de date, specificând crearea, mu tarea sau identificarea definirilor de
clas ă. 3. Redefinirea dinamic ă a clasei (evolu Ńiei schemei).
Gestionarul de obiecte trimite cerin Ńe pentru reg ăsirea și actualizarea definirilor de
clas ă, server-ului de obiecte. Gestiunea tranzac Ńiilor este asigurat ă de server -ul de
obiecte. Gestiunea stocului de obiecte se refer ă la men Ńinerea nivelului fizic de organizare
a bazei de date obiect (ODB) și la asigurarea c ăilor de acces necesare realiz ării accesului
eficient la stocul de obiecte.
Func Ńiile de baz ă ale stocului de date-obiect se caracterizeaz ă ca fiind:
1. Suport pentru reziden Ńă , adic ă obiectele create și ad ăugate trebuie re Ńinute și
dup ă ce se încheie sesiunea.
2. Suport pentru obiecte mari . SGBD-OO trebuie s ă poat ă suporta stocarea și
manipularea obiectelor de lungime variabil ă și de orice dimensiune.
3. Facilit ăŃi de arhivare și asigurare de rezerve (dubluri).
Caracteristicile care asigur ă reg ăsirea și actualizarea obiectelor stocate pot fi:
a) suport pentru c ăi de acces care este necesar pentru a asigura reg ăsirea și actualizarea
eficient ă a datelor stocate în baze de date mari. Aceasta in clude indexarea obiectelor
pentru a permite reg ăsirea eficient ă a obiectelor individuale, dar și indexarea obiectelor
prin valorile variabilelor de instan Ńă , pentru reg ăsirea subseturilor de obiecte pentru
satisfacerea cererilor;
b) tipuri de indec și specializa Ńi pentru obiecte;
c) gruparea obiectelor în acela și sector de stoc secundar.
d) segmentarea obiectelor stocate .
Lista subiectelor pentru preg ătirea în vederea evalu ării finale:
Întreb ări:
1. Cum se definesc bazele de date orientate obiect?
2. Care sunt no Ńiunile fundamentale utilizate în modelul de date or ientat pe
obiecte?
3. Cum se clasific ă obiectele?
4. Defini Ńi tipurile, clasele, mo ștenirea.
5. Care sunt opera Ńiile modelului de date orientat pe obiecte?
6. Cum se face proiectarea bazei de date orientat ă pe obiecte?

27 Studiu de caz: Stabili Ńi obiectele și tipurile de evenimente la care acestea
ac Ńioneaz ă, pentru o aplica Ńie de taxe și impozite în administra Ńia public ă utilizând
o baz ă de date orientat ă pe obiecte.

28 Prezentarea lec Ńiei / capitolul 6:
6. Elemente fundamentale ale serverelor de baze de date.
6.1 Arhitectura Client/Server
Într-o re Ńea de calculatoare și de comunica Ńii dintr-o organiza Ńie economic ă, unul dintre
modelele de baz ă pe care se fundamenteaz ă func Ńionarea re Ńelei este constituit de modelul
client/server, sus Ńinut de arhitecturi adecvate în func Ńie de num ărul de entit ăŃi
componente ale lan Ńului de lucru în re Ńea a unei aplica Ńii ale c ărei elemente – prezentare,
procesare și date – se g ăsesc pe acela și calculator sau sunt distribuite pe calculatoare
diferite (în varianta standard, datele sunt stocate pe server , procesarea este divizat ă între
server și client , iar prezentarea apar Ńine clientului ). Aceste arhitecturi client/server pot fi
cu dou ă entit ăŃi ( two-tier ), cu trei entit ăŃi ( three-tier ) sau cu mai multe entit ăŃi ( n-tier ).
Toate calculatoarele care se g ăsesc între server și client alc ătuiesc ceea ce se denume ște
generic middleware (mediul de mijloc).
Serverul , ca no Ńiune de baz ă, prezint ă dou ă accep Ńiuni:
• un calculator dedicat pe care este instalat un soft pentru gestionarea accesului într-o
re Ńea local ă de calculatoare (LAN), inclusiv gestionarea accesu lui la resursele din re Ńea
din partea calculatoarelor – sta Ńii de lucru ( workstations );
• un program (conceput pe un model de proces distinct ) sau un calculator care r ăspunde
cererilor (requests ) adresate de entitatea denumit ă client ; clientul , în acest caz, este un
proces care are nevoie de un serviciu pe care trebuie s ă i-l furnizeze serverul .
Ca urmare, no Ńiunea de server trebuie considerat ă în re Ńea sub cele dou ă aspecte hard-soft
(dualitatea hard-soft). Cea de-a doua accep Ńiune prezentat ă mai sus pentru server ,
caracterizeaz ă arhitectura client/server ce permite divizarea procesului specific aplica Ńiei
în dou ă componente distincte, denumite client (« front-end ») și server (« back-end »). De
regul ă, componenta client este reprezentat ă de un calculator mai pu Ńin preten Ńios,
independent, ce se prezint ă utilizatorului cu toate resursele la dispozi Ńie. Spre deosebire
de aceasta, componenta server este un sistem de calcul (microcalculator puternic ,
minicalculator sau un calculator mare – mainframe ) cu caracteristici tehnologice
maximale momentului implement ării în mediu distribuit (gestionare date, partajare
resurse între clien Ńi, securitate sporit ă, administrare avansat ă în cadrul re Ńelei de
calculatoare și de comunica Ńii).
Cu ajutorul arhitecturii client-server se ob Ńine: conectarea în re Ńea a mai multe
calculatoare de diferite tipuri (mainframe și microcalculatoare), tratarea unitar ă a bazelor
de date aflate pe diferite calculatoare din re Ńea, colaborarea categoriilor de utilizatori
(utilizatori finali, administratori ai bazelor de d ate, programatori).
Între entitatea client și cea de server se poart ă un dialog permanent sau în anumite
momente, de tipul cerere (request) – r ăspuns (response) . Clientul, prin adresarea cererii
de serviciu c ătre server, interogheaz ă baza de date ce se g ăse ște stocat ă pe server.
Serverul gestioneaz ă baza de date și r ăspunde interog ării adresate de client. În dialogul
client-server, pot exista urm ătoarele cazuri: client-server, client pasiv și server pasiv.
Cazul cu client pasiv se întâlne ște atunci când se realizeaz ă conexiuni cu prelucrare gazd ă
(host procesing ) pe un server de tip mainframe, iar clientul este un terminal cu rol
neimportant în execu Ńia opera Ńiilor necesare efectu ării dialogului. Cazul cu server pasiv
se constat ă atunci când cele mai multe aplica Ńii se efectueaz ă de c ătre client, serverul
îndeplind doar rolul de server de fi șiere ( File Server ) și/sau server de imprimare ( Print

29 Server ). Cel mai eficient este cazul client-server când activit ăŃile sunt divizate în mod
echilibrat între client și server.
Exist ă și situa Ńia în care cele dou ă entit ăŃi, server și client , sub aspect software,
pot coexista pe acela și calculator. Dac ă cele dou ă entit ăŃi sunt instalate pe acela și
calculator, atunci acest calculator are instalat un sistem de operare pentru multi-
procesare, deoarece clientul și serverul reprezint ă procese distincte. În re Ńeaua de
calculatoare și de comunica Ńii, un client poate adresa cereri c ătre mai multe servere. De
asemenea, un server poate r ăspunde la cererile adresate de mai mul Ńi clien Ńi.
În evolu Ńia sa, arhitectura client-server a cunoscut mai multe genera Ńii:
• genera Ńia I , care se caracterizeaz ă prin faptul c ă server-ul stocheaz ă baza de date
rela Ńional ă, iar clientul stocheaz ă și execut ă aplica Ńia client. Cererile SQL sunt formulate
de aplica Ńia client către SGBDR de pe server . Execu Ńia acestor cereri de interogare și
transmiterea r ăspunsului se efectueaz ă de c ătre entitatea server . Entitatea client poate
executa urm ătoarele apeluri la transport:
– SendRequest , ceea ce înseamn ă: clientul anun Ńă serverul asupra opera Ńiilor ce
urmeaz ă a fi executate;
– ReceiveReply , prin care se asigur ă recep Ńionarea r ăspunsului de la server de c ătre client .
În acela și timp, la entitatea server , apelurile specifice sunt urm ătoarele:
– ReceiveRequest , care semnific ă faptul c ă entitatea server recep Ńioneaz ă cereri de
interogare de la entitatea client ;
– SendReply , care înseamn ă c ă serverul transmite r ăspunsul c ătre entitatea client ,
răspuns ce corespunde cererii de interogare adresate anterior.
• genera Ńia a II-a, caracteristic ă anilor ’90, orientat ă pe obiecte. Entitatea server asigur ă
mai multe clase de servicii clien Ńilor: execu Ńia aplica Ńiilor; interfe Ńe grafice destinate
dialogului cu utilizatorul; accesul la fi șierele și bazele de date administrate de SGBDR
de pe server .
Exist ă mai multe tipuri de client-server , în func Ńie de importan Ńa acordat ă unei sau alteia
dintre componentele « triadei » stocare – prelucrare – prezentare :
1) client – server de prezentare , în care un proces este destinat func Ńiei de asigurare a
dialogului cu utilizatorul, iar celelalte procese c onsiderate realizeaz ă gestionarea datelor
și execu Ńia aplica Ńiilor;
2) client – server de date , în care utilizatorul are acces la datele administ rate de server
utilizând o aplica Ńie-client, cu ajutorul cererilor de interogare SQL;
3) client – server de proceduri pentru prelucrare, în care aplica Ńia-client poate realiza
controlul execu Ńiei procedurilor stocate pe server prin intermediul unei interfe Ńe
specializate.
Cel mai r ăspândit este tipul combinat client-server de date, de prezentare și de proceduri
pentru prelucrare care prezint ă urm ătoarele componente (fig.7.1):
• clien Ńii , care se ocup ă cu gestionarea codului aplica Ńiei client și care dispun de interfa Ńe
interactive și prietenoase cu utilizatorii finali;
• serverul , care stocheaz ă baza de date, gestioneaz ă conectarea și accesul la baza de date,
gestioneaz ă logica aplica Ńiei, asigur ă securitatea bazei de date;
• re Ńeaua , care asigur ă conectarea și comunicarea dintre clien Ńi și server (1) și între
servere (2).
În general, aplica Ńiile client-server pot fi aplica Ńii cu baze de date distribuite, aplica Ńii de
po ștă electronic ă, aplica Ńii groupware (ce permite unui grup de utilizatori dintr-o re Ńea s ă

30 colaboreze la realizarea unui anumit proiect și care ofer ă servicii de comunica Ńii (e-mail),
de planificare și de administrare a proiectelor, de elaborare în co mun a documentelor de
diferite tipuri – text, multimedia) etc.
Avantajele utiliz ării arhitecturii client-server sunt multiple, drintre acestea men Ńionându-
se: administrarea centralizat ă, de pe server, a bazei de date; mic șorarea dimensiunilor
aplica Ńiilor; reducerea traficului în re Ńea; securitate sporit ă a bazelor de date stocate pe
server; manipularea de c ătre utilizatori, conform drepturilor de acces, a pr ocedurilor
stocate.
În aplica Ńiile de baze de date pe Web se utilizeaz ă arhitectura cu trei niveluri: client ,
aplica Ńie și date . Nivelul client permite unui utilizator s ă comunice cu baza de date prin
Web, cu ajutorul unei interfe Ńe specializate asigurate de c ătre browser-ul Web la
dispozi Ńie.

Fig.6.1 Arhitectura client-server de date, de preze ntare și de proceduri pentru
prelucrare

Nivelul aplica Ńie reprezint ă nivelul cu aplica Ńii la îndemâna utilizatorului final, pe
serverul Web care, prin intermediul protocolului HT TP, recep Ńioneaz ă cererile clien Ńilor,
le prelucreaz ă și le transmite c ătre o alt ă aplica Ńie sau/ și c ătre nivelul de date. Nivelul
date con Ńine sistemul de gestiune a bazelor de date (SGBD), care con Ńin, de regul ă, date
multimedia .
Lista subiectelor pentru preg ătirea în vederea evalu ării finale:
Întreb ări:
1. Cum se define ște arhitectura client-server?
2. Defini Ńi no Ńiunea de client și cea de server.
3.Care sunt genera Ńiile de arhitecturi client-server?

• Stocare baz ă de date
• Conectare și acces la baza de date
• Gestionare logic ă aplica Ńie
• Asigurare securitate baz ă de date • Gestionare cod aplica Ńie client
• Interfa Ńă interactiv ă cu
utilizatorul final

31 Prezentarea lec Ńiei / capitolul 7:
7.1 . Serverul de baze de date Microsoft SQL Server
Produsul Microsoft SQL Server face parte din categoria serverelor de baze de
date, care lucreaz ă cu aplica Ńii de tipul client-server și care presupune acces concurent la
o anumit ă baz ă de date. Referirile se efectueaz ă la versiunea Microsoft SQL Server2000
care a fost precedat ă de versiunea Microsoft SQL Server 7.0 . În momentul redact ării
prezentei lucr ări, este anun Ńat ă versiunea Microsoft SQL Server 2005.
Stocarea informa Ńiilor pe serverul de baze de date Microsoft SQL Server se face în
baze de date, fi șiere și grupuri de fi șiere. Microsoft SQL Server dispune de un sistem de
securitate propriu, pe baz ă de identificatori și conturi de utilizatori ai bazelor de date.
SQL Server asigur ă crearea și gestionarea rolurilor la nivel de server, la nivelul
unei baze de date și la nivel de aplica Ńie; de asemenea, asigur ă permisiuni care pot fi
alocate utilizatorilor și rolurilor. Rolurile SQL Server asigur ă gruparea numelor
utilizatorilor bazelor de date (grupuri Windows, ut ilizatori Windows sau identificatori
SQL Server). Atribuirea unui identificator pentru r ol la nivel de server se efectueaz ă cu
ajutorul SQL Enterprise Manager. Rolurile la nivel de aplica Ńie asigur ă aplicarea
permisiunilor la un nivel mai înalt decât nivelul p e care se g ăse ște fiecare utilizator.
Atunci când o aplica Ńie activeaz ă un rol la nivel de aplica Ńie, se produce suspendarea
tuturor permisiunilor utilizatorului. Activarea rol urilor necesit ă parole. Fiecare baz ă de
date cuprinde roluri (exist ă nou ă roluri fixe sau predefinite și pot exista roluri ale
utilizatorului) pentru care exist ă proceduri. Fiecare rol al unei baze de date acord ă
utilizatorilor un num ăr de permisiuni și capabilit ăŃi. Numele rolului este necesar s ă fie
unic la baza de date. Apartenen Ńa la un rol fix al unei baze de date nu are leg ătur ă cu
permisiunile acordate pentru o alt ă baz ă de date.
SQL Server permite realizarea salv ărilor de siguran Ńă ( backup ).
SQL Server este înso Ńit de utilitare și instrumente care asigur ă urm ătoarele
servicii:
1. MSSQLServer ce reprezint ă serverul propriu-zis de baze de date;
2. MSSearch care asigur ă indexarea câmpurilor de tip text care opereaz ă sub SQL
Server;
3. SQLServerAgent ce realizeaz ă planificarea opera Ńiilor, gestionarea evenimentelor,
replicarea, generarea avertismentelor;
4. MSDTC (Microsoft Distributed Transaction Coordinato r) adic ă coordonatorul
tranzac Ńiilor distribuite pe mai multe servere;
5. MSSQLServerOLAPService ce asigur ă serviciile de analiz ă a datelor prin OLAP;
6. MSSQLServerADHelper ce realizeaz ă integrarea activ ă a directoarelor pentru SQL
Server .
Instan Ńa în SQL reprezint ă o copie independent ă a unui server de baze de date pe
un calculator din categoria platformelor Microsoft Windows. Microsoft SQl Server
permite execu Ńia a cel mult 16 astfel de instan Ńe. Instan Ńele SQL Server pot fi prestabilite
(este acceptat ă o singur ă instan Ńă prestabilit ă pe un anumit calculator) sau pot fi denumite
(acele instan Ńe c ărora li s-a dat un nume la instalare). Doua instan Ńe denumite de pe
acela și calculator nu sunt acceptate cu acela și nume.
Firma Microsoft a realizat controlul fiec ărui serviciu prin mai multe metode
realizabile prin utilitare și instrumente asociate SQL Server (instalate într-o copie unic ă,

32 indiferent de num ărul de instan Ńe instalate ale SQL Server). Utilitarele asociate SQL
Server sunt urm ătoarele:
• SQL Server Books OnLine ce reprezint ă manuale electronice sub form ă de pagini
HTML (de exemplu: Getting Started, SQL Server Architecture, Creating and
Maintaining dataBases, Creating and Using Data Ware houses etc.).
• SQL Server Service Manager care este un utilitar pentru controlul serviciilor pentru
SQL Server ( SQL Server, MSDTC, SQL ServerAgent și MSSearch ).
• Client Network ce reprezint ă un utilitar care deserve ște procesul de conectare a unui
calculator client la SQL Server).
• Server Network care este un utilitar pentru indicarea bibliotecilo r de re Ńea pe care le
poate utiliza SQL Server (pentru bibliotecile ce co n Ńin date confiden Ńiale la care nu se
permite accesul, se execut ă criptarea de c ătre server a c ăilor de conectare la bibliotecile
respective).
• SQL Server Query Analyser care este utilitarul destinat execut ării interog ărilor sau a
procedurilor memorate Transact-SQL.
• SQL Server Enterprise Manager ce reprezint ă un utilitar de tipul MMC ( Microsoft
Management Console ), adic ă consol ă de Management Microsoft ce asigur ă interfa Ńa
grafic ă de dezvoltare și administrare din SQL Server.
• SQL Server Profiler ce reprezint ă utilitarul pentru monitorizarea întregii activit ăŃi
executate de SQL Server.
Utilitarele prezentate mai sus se g ăsesc în meniul Start al SQL Server. În afar ă de aceste
utilitare de baz ă, au fost realizate instrumente pentru conectare, p entru diagnosticarea
serverului și pentru între Ńinere.
No Ńiunea de replicare a fost explicat ă par Ńial în capitolul destinat SGBD Microsoft
Access. Procesul de replicare în SQL Server este un proces complex ce utilizeaz ă un
scenariu de tip editor-abonat la care sunt asociate articole și publica Ńii . Abona Ńii sunt
calculatoarele utilizatorilor ale datelor. Un siste m SQL Server poate juca în scenariul de
tip editor-abonat unul, dou ă sau trei roluri din mul Ńimea de roluri {editor, abonat,
distribuitor}. Rolul de distribuitor presupune recep Ńionarea tuturor modific ărilor efectuate
de abona Ńi sau editori, memorarea acestor date și apoi trimiterea lor la editori sau abona Ńi,
la un anumit moment. Articolul reprezint ă un tabel sau o mul Ńime de date dintr-un tabel,
ob Ńinut ă prin parti Ńionare. Publica Ńia este ansamblul mai multor articole combinate.
Articolele și publica Ńiile pot fi primite de abona Ńi prin efectuarea de abonamente.
Abonamentele pot fi configurate în abonamente de intrare (confi gurate la nivelul fiec ărui
abonat) și abonamente de ie șire (configurarea abonamentului se produce simultan cu
crearea publica Ńiei).
Replicarea asigur ă un mediu de lucru ce faciliteaz ă duplicarea și distribuirea mai
multor copii (replici) ale acelora și date, în mai multe baze de date din re Ńea (în mai multe
loca Ńii). În distribuirea datelor prin aceast ă metod ă se au în vedere autonomia loca Ńiei ,
consisten Ńa tranzac Ńional ă (care nu trebuie s ă afecteze consisten Ńa datelor) și laten Ńa
distribuirii (întârzierea).

SQL Server permite utilizarea urm ătoarelor metode de distribuire a datelor :
• replicarea cu combinare (fiecare loca Ńie î și poate modifica copia local ă a datelor
replicate, astfel încât editorul combin ă modific ările primite de la aceste loca Ńii);

33 • replicarea copiilor integrale (prin transferul unei copii de ansamblu a datelor
replicate de la editor la abona Ńi);
• replicarea tranzac Ńional ă ( adic ă tranzac Ńiile sunt copiate de pe serverul editor la
abona Ńi, f ără existen Ńa reversului de la abona Ńi la editor);
• abonarea cu actualizare (la care acualizarea poate fi imediat ă, cu fir de a șteptate sau
combinat ă – imediat ă și cu fir de a șteptare);
• replicarea copiilor integrale cu actualizare la abo na Ńi ( prin aceasta, abonatul nu este
necesar s ă se afle în contact permanent cu editorul);
• replicarea tranzac Ńional ă cu actualizare la abona Ńi ;
• tranzac Ńiile distribuite (cu MSDTC, cu aplicarea simultan ă a tranzac Ńiilor la to Ńi
abona Ńii).
Replicarea este asigurat ă de cinci agen Ńi: agent de distribu Ńie, agent de citire din
jurnalele de tranzac Ńii specifice tuturor bazelor de date publicate, age nt de combinare,
agent de copiere și agent de citire din firul de a șteptare.
Datele pot fi publicate pe Internet prin mai multe metode. Se apreciaz ă c ă una
dintre cele mai sigure metode este tehnologia re Ńelei private virtuale , VPN ( Virtual
Private Network ). Prin VPN se pot conecta dou ă re Ńele prin utilizarea Internetului, cu
protocoalele specifice, folosind servere proxy (intermediare) c ătre serverele SQL.
SQL Server folose ște patru baze de date astfel:
– master , ce con Ńine configur ările SQL Server-ului, precum și date care privesc utilizatorii
bazei de date;
– model , ce reprezint ă o baz ă de date model , care se duplic ă de fiecare dat ă când
utilizatorul creeaz ă o baz ă de date nou ă;
– tempdb , ce este o baz ă de date care stocheaz ă tabele temporare și rezultatele
intermediare ale unor interog ări;
– msdb, ce este utilizat ă de SQLServerAgent pentru memorarea datelor cu privire la
sarcinile periodice (salvarea bazei de date, salvar ea jurnalului etc).
O baz ă de date SQL Server este organizat ă pe mai multe niveluri : componente
logice ce sunt transparente utilizatorilor; tabele ( tables ) care con Ńin înregistr ări ale bazei
de date; vederi ( views ); indec și ( indexes ); proceduri stocate ( procedures ); declan șatori
(triggers ). Fizic, o baz ă de date include cel pu Ńin dou ă fi șiere (fi șier primar de date,
primary data file, cu date și referin Ńe asupra celorlalte fi șiere ale bazei de date; fi șierul
jurnal care înregistreaz ă toate modific ările efectuate în baza de date). În cazul bazelor d e
date foarte mari, pot exista și fi șiere secundare ( secondary data file ).
La fiecare instalare a produsului Microsoft SQL Server sunt generate mai multe baze de
date: master , model , tempdb și msdb , precum și baze de date utilizator ( pubs, Northwind ).
Metodele de creare a unei baze de date Microsoft SQL Server 2000 sunt
urm ătoarele:
• Database Creation Wizard
• SQL Server Enterprise Manager
• Cu ajutorul instruc Ńiunii CREATE DATABASE.
Crearea unei noi baze de date este echivalent ă cu execu Ńia unei copii a bazei de
date model, prin extinderea pân ă la dimensiunea dorit ă, spa Ńiul suplimentar fiind
completat cu pagini goale. Baza de date astfel crea t ă utilizeaz ă fi șiere pentru stocarea
fizic ă a datelor pe discul magnetic.

34 Salvarea bazelor de date în SQL Server se efectueaz ă complet, diferen Ńial și prin
salvarea jurnalelor de tranzac Ńii cu ajutorul SQL Server Enterprise Manager sau cu
Transact-SQL (ce va fi prezentat în paragraful urm ător). Copiile de siguran Ńă ( backup )
servesc pentru o restaurare a bazelor de date în ca z de defect ări ale serverului.
SQL Server are pus la punct un scenariu de restaurare a bazelor de date în caz de
dezastre. Se poate realiza recuperare automat ă sau manual ă. Recuperarea automat ă
reprezint ă un proces care se deruleaz ă la fiecare pornire a serviciului SQL Server . Ca
urmare, atunci când serverul se decupleaz ă din diferite motive, inclusiv la avarii, procesul
de recuperare automat ă se porne ște la repornirea serverului. La terminarea acestui proces
de recuperare automat ă, bazele de date r ămân într-o form ă consistent ă din punct de
vedere logic. Pentru recuperarea tuturor bazelor de date, SQL Server utilizeaz ă baza de
date model , dup ă care se creeaz ă baza de date tempdb , se restaureaz ă baza de date msdb
și, în final, bazele de date ale utilizatorilor. Recuperarea manual ă reprezint ă procesul de
recuperare a unei baze de date a utilizatorului, pr in restaurarea unei copii complete a
bazei de date (sau copie diferen Ńial ă) sau restaurarea uneia sau mai multor copii pentru
jurnalul de tranzac Ńii, în ordinea în care au fost generate. În momentu l restaur ării baza de
date nu trebuie s ă fie în uz (s ă nu fie activ ă comanda USE ). Pentru aceasta, trebuie reperat
setul corespunz ător de copii de siguran Ńă (cu comenzile RESTORE LABELONLY, RESTORE
HEADERONLY, RESTORE FILELISTONLY ). În continuare, se verific ă dac ă setul salvat este
utilizabil ( RESTORE VERIFYONLY ), se restaureaz ă complet sau diferen Ńiat baza de date și
jurnalul de tranzac Ńii. Scenariile de recuperare sunt construite pentru diferite situa Ńii ca
recuperarea datelor dup ă defectarea unui disc, recuperarea datelor dup ă pierderea bazei
de date master ,
SQL Server asigur ă, a șa cum s-a precizat mai sus, servicii de extragere a datelor
din bazele de date opera Ńionale și de construire a depozitelor de date, dup ă care aceste
date din depozite sunt supuse analizei de tip OLAP. Acest serviciu este tratat în capitolul
consacrat bazelor de date în tehnologii avansate.
Microsoft SQL Server prezint ă urm ătoarele avantaje :
– portabilitatea , adic ă capacitatea de a func Ńiona pe o mare varietate de platforme
hardware;
– compatibilitatea modelului de programare cu modelele folosite în întreaga gam ă
de sisteme de operare Microsoft Windows (95, 98, 20 00, XP);
– optimizarea capabilit ăŃilor sale pentru lucrul cu baze de date mari;
– execu Ńia rapidă a interog ărilor SQL ;
– posibilitatea de extragere și analiz ă a datelor pentru baze de date multidimensionale ;
– facilitatea de integrare cu alte produse software Microsoft.
Lista subiectelor pentru preg ătirea în vederea evalu ării finale:
Întreb ări:
1. Ce asigur ă SQL Server prin crearea și gestionarea rolurilor?
2. Ce reprezint ă instan Ńa în SQL?
3. Ce reprezint ă replicarea în SQL?
4. Care sunt metodele de distribuire a datelor utiliza te ]n SQL?
5. Care sunt metodele de creare a unei baze de date Mi crosoft SQL Server 2000?