BAZE DE DATE

CURS nr. 7

2.1.4. Modele logice orientate pe obiecte

Descriu datele la nivelele conceptual i extern oferind o flexibilitate ridicat. Astfel de modele pot
specifica n mod explicit constrngerile aplicate datelor i se bazeaz pe urmtoarele concepte:
- entitate un obiect sau concept din lumea real ce are identitate proprie;
- atribut un set de proprieti utilizate la descrierea entitilor;
- relaie o asociere ntre dou sau mai multe entiti.
Din aceast categorie fac parte:
a. modelul entitate-relaie;
b. modelul orientat pe obiecte;
c. modelul obiectual-relaional;
d. modelul binar;
e. modelul semantic de date;
f. modelul infologic;
g. modelul funcional de date.
Dintre acestea se remarc modelele urmtoare:

Modelul entitate-relaie
Se bazeaz pe o percepie a lumii reale ca fiind alctuit dintr-o colecie de obiecte de baz sau
concepte (entiti) mpreun cu relaiile care se stabilesc ntre ele. Fiecare entitate are asociat un set
de atribute care o descriu, iar o relaie reprezint o asociere dintre dou sau mai multe entiti.
Mulimile tuturor entitilor sau relaiilor de acelai tip sunt cunoscute sub denumirea de tipuri de
entiti sau relaii. Un alt element important n cadrul diagramelor entitate-relaie l reprezint
precizarea constrngerilor de cardinalitate care exprim numrul de entiti asociate altui tip de
entitate prin intermediul unui tip de relaie.

Modelul orientat pe obiecte

Un astfel de model este utilizat doar n scopuri speciale, cele mai cunoscute produse de acest tip
fiind: ObjectStore, Gemstone, Ontos, O2, Jasmine, Cache. Modelul se bazeaz pe o colecie de
obiecte, la fel ca n cazul modelului entitate-relaie.
Un obiect conine valorile nmagazinate n cadrul unor variabile instaniate n interiorul acestor
obiecte. Spre deosebire de modelul entitate-relaie, valorile sunt ele nsele obiecte. Astfel de obiecte
conin alte obiecte imbricate pn la un nivel oarecare.
Obiectul mai conine elemente de cod ce opereaz asupra acestuia i care se numesc metode.
Obiectele ce conin acelai tip de valori i aceleai metode sunt grupate n clase. O clas poate fi
interpretat ca fiind definiia de tip a obiectului respectiv.
Singura modalitate prin care un obiect poate accesa datele altui obiect este prin invocarea metodelor
acelui obiect, ceea ce este cunoscut sub numele de trimitere de mesaje ctre obiectul respectiv.
Prile interne ale obiectului respectiv, variabilele i metodele, nu sunt vizibile n exterior,
obinndu-se astfel dou nivele de abstractizare a datelor. Spre deosebire de entitile din modelul
entitate-relaie, fiecare obiect are un identificator unic indiferent de valorile pe care le conine.
Dou obiecte ce au aceleai valori sunt distincte (polimorfism). Distincia se menine i la nivelul
fizic prin atribuirea unui identificator unic al obiectului respectiv.
Modelul orientat pe obiecte are toate caracteristicile limbajului de programare orientat pe obiecte,
fcnd ca modelul relaional s fie cobort la stadiul de depozit de date.
Esenial pentru un astfel de model este faptul c proiectantul bazei de date poate opera cu fiecare
element al bazei de date, inclusiv cu setul de operaii ce manipuleaz datele din cadrul bazei de date
n cadrul aplicaiei scrise ntr-un limbaj orientat pe obiecte.
De aceast dat ns nu mai exist o separare clar ntre date i aplicaie. Spre deosebire de modelul
relaional, care are un suport teoretic extrem de solid, modelul orientat pe obiecte nu prezint o

BAZE DE DATE

CURS nr. 7

astfel de caracteristic, ceea ce face s nu existe un consens n definirea lor. Totui, organizaia
OMG (Object Management Group) a depus mari eforturi, reuind s propun un model ce a devenit
standard pentru toate sistemele de gestiune a bazelor de date orientate pe obiecte.

Modelul obiectual-relaional
Acest model (cunoscut iniial sub numele de model de date relaional extins) a extins modelul
relaional prin introducerea unor serii de elemente i caracteristici specifice modelului obiectual,
cum ar fi: clase, ncapsulare, motenire. Cele mai cunoscute produse de pe pia sunt: Postgres,
Informix, DB2, Oracle.
Scopul acestei extinderi a fost acela de a permite bazelor de date relaionale s opereze cu tipuri
complexe de date, cum ar fi: imagini audio, video, elemente de proiectare. Modelul se afl nc la
stadiul incipient de dezvoltare, chiar dac este promovat de cei mai mari productori de pe pia de
produse de baze de date.
2.1.5. Modele fizice de date
Sunt modele utilizate la descrierea datelor la cel mai de jos nivel. Ele conin informaii despre
structura nregistrrilor, ordinea nregistrrilor, precum i cile de acces la date. Din aceast
categorie fac parte:
- modelul unificat al datelor;
- memoria cadru.
2.1.6. Avantajele bazelor de date relaionale
Sunt urmtoarele:
- Integritate ncorporat la mai multe nivele. Integritatea datelor este integrat n cadrul
modelului la nivel de cmp pentru a asigura precizia datelor. La nivel de tabel asigur faptul c
o nregistrare nu mai poate fi introdus nc o dat n baza de date, precum i detectarea lipsei
valorilor din cmpurile cheie primar. La nivel de relaie asigur validitatea acestora ntre
tabele. La nivel logic, asigur acurateea logic a datelor.
- Independena logic i fizic a datelor de programele aplicaie: nici modificrile efectuate
de ctre utilizator modelului logic al bazei de date, nici modificrile efectuate de ctre
productorul bazei de date implementrii fizice a acesteia, nu vor afecta programele aplicaiilor
care utilizeaz baza de date.
- Garanteaz consistena i precizia datelor: datele sunt consistente i precise datorit
multiplelor nivele de integritate ce pot fi introduse n baza de date.
- Extragerea cu uurin a datelor din baza de date. n urma comenzilor introduse de ctre
utilizator, datele din baza de date pot fi extrase fie dintr-un singur tabel, fie dintr-o multitudine
de tabele asociate prin intermediul relaiilor, ceea ce ofer posibilitatea prezentrii datelor ntrun numr nelimitat de moduri.
Acestea i alte avantaje au adus beneficii extrem de importante comunitii de afaceri i tuturor
acelora care au nevoie de colectarea i nmagazinarea de date. Deocamdat, bazele de date
relaionale dein supremaia pe piaa acestor produse, fiind alese n cele mai multe dintre cazuri.
Pn de curnd, cel mai mare dezavantaj al bazelor de date relaionale l reprezenta faptul c
programele aplicaie care le foloseau erau foarte lente n execuie. Problema nu era una a bazelor de
date relaionale, ci tehnologiei deficitare de care se dispunea la momentul introducerii modelului.
ncepnd cu anii 90 paii nainte fcui att n domeniul hardware ct i software au fcut ca o
astfel de problem s fie din ce n ce mai puin vizibil.
2.1.7. Chei
O cheie este un cmp ce are o valoare unic, corespunztoare fiecrei nregistrri dintr-un
tabel. Sunt mai multe tipuri de chei, fiecare avnd propriile caracteristici.

BAZE DE DATE

CURS nr. 7

2.1.7.1. Cheia candidat

Este un atribut sau un set de atribute ce identific n mod unic un tuplu dintr-un tabel.

2.1.7.2. Cheia primar

Reprezint una dintre cheile candidat desemnate n cadrul unui tabel. Orice tabel trebuie s aiba o
cheie primar.
O cheie primar trebuie s fie:
1. Stabil. Valoarea unei chei primare nu trebuie s se modifice sau s devin nul pe tot parcursul
existenei unei entiti (Brooks, 1992). O cheie primar stabil ajut la pstrarea unui model
stabil (Whitener, 1989). De exemplu, dac se analizeaz nregistrarea datelor unui student,
valoarea cheii primare nu trebuie s se modifice n timp, aa cum se ntmpl cu valorile din
cmpul n care se pstreaz vrsta acestuia.
2. Minimal. Cheia primar trebuie s fie alctuit dintr-un numr minim de cmpuri ce sunt
capabile s asigure unicitatea.
3. Centrat pe date, nu pe informaii. Nu trebuie s apar grupri de caracteristici n cadrul unei
valori a unei chei ce pstreaz meta-informaii adiionale, deoarece nu se respect principiul
atomicitii atributelor, crescnd astfel posibilitatea ca valorile cheii primare s se modifice.
4. Definitiv. n momentul introducerii unei noi nregistrri, trebuie s existe posibilitatea
introducerii unei valori. Cheia primar acioneaz ca un mecanism de constrngere suplimentar
a entitii deoarece nu poate fi introdus o instan a unui tip de entitate dac aceasta nu are o
valoare permis n cheia primar.
5. Accesibil. Oricine dorete s creeze, citeasc, sau tearg o nregistrare trebuie s poat
vizualiza valoarea cheii primare (Whitener, 1989).

2.1.7.3. Cheie alternativ

Este o cheie candidat ce nu a fost desemnat drept cheie primar. Ea poate deveni cheie primar
dac cheia primar aleas iniial nu mai corespunde la un moment dat.

2.1.7.4. Cheie extern

Exist doar n situaia n care se stabilesc dou sau mai multe relaii ntre tabelele bazei de date. Un
atribut al unui tabel trebuie s existe i n cellalt tabel legat de primul printr-o relaie.

2.2. Modele arhitecturale: mainframe, integrate, file-server, client-server,

distribuite
2.2.1. Introducere
De mult timp se cocheta cu ideea crerii unei baze de date universale, adic o baz de date care s
conin informaii din ct mai multe domenii i care s poat fi accesat de un numr ct mai mare
de persoane. Pn cu puin timp n urm acest ideal se meninea n domeniul viselor. Odat cu
apariia a ceea ce numim astzi World Wide Web un astfel de vis a devenit realitate.
nc din cele mai vechi timpuri oamenii au avut nevoie de informaii. O dat cu informaia a aprut
i necesitatea schimbului de informaii. Pentru aceasta era nevoie de un suport material care s
stocheze informaia i s o transmit mai departe. S-a nceput cu cioplirea informaiilor n piatr i
s-a continuat cu alte i alte soluii pn n zilele noastre, cnd asistm la decderea unui suport
(hrtia) i ridicarea altuia (suportul electromagnetic).
Odat cu evoluia omenirii, informaia a crescut ca dimensiune, punndu-se, prin urmare, problema
stocrii unei mari cantiti de date. De asemenea, o alt problem este regsirea informaiei i, odat

BAZE DE DATE

CURS nr. 7

cu aceasta, rapiditatea obinerii rezultatului. nc din zorii civilizaiei IT s-a observat c - pe lng
calculele ce erau preponderente n tehnologia informatic embrionar - computerele s-ar preta i la
nmagazinarea i exploatarea volumelor mari de informaii. Astfel, ncepnd cu anul 1948 s-au fcut
mai multe studii, cercetri i experimente privind stocarea datelor, iar de-a lungul timpului s-au
manifestat mai multe modele, arhitecturi i tehnologii privind bazele de date. Acceptnd un punct de
vedere oarecum teoretic, fr ns a intra in detalii aride, vom trece in revist principalele modele de
concepie i organizare a bazelor de date, dup care ne vom ocupa de arhitecturile de implementare
a sistemelor de gestiune a bazelor de date (SGBD).

2.2.2. Istoric
Pn spre anii 80 contau doar mainframe-urile, minisistemele i supercomputerele, bazele de date
fiind foarte mari (rspunznd unor cerine dure impuse de beneficiari pretenioi, pentru c doar
acetia aveau puterea financiar de a achiziiona tehnica motivat de probleme complexe i critice este uor s ne imaginm baze de date referindu-se la sute de mii sau milioane de entiti).
Tendinele forau mereu limite, iar de aici derivau problematici provocatoare privind performana,
accesibilitatea i mentenabilitatea. Prin anii 70, modelul relaional s-a cristalizat ca soluie viabil,
iar lupta concurenial dintre marii juctori de pe piaa bazelor de date se va da pn in vremea
noastr pe arena SGBDR i SQL.
Mult timp modelul de organizare centralizat (datele sunt depozitate pe un sistem central de unde
utilizatorii le acceseaz) a raspuns cel mai bine cerinelor de exploatare a bazelor de date. i astzi
pentru aproape orice mediu departamental (sau grup de lucru) organizarea centralizat a
informaiilor - i nu ne referim neaprat la baze de date (de exemplu, sistemele de gestiune i
control al circulaiei documentelor - unde documentele pot fi orice: documentaii, proiecte, desene
CAD, arhive etc.) - constituie o prim opiune.
Odat cu rspndirea i dezvoltarea calculatoarelor s-au deschis i orizonturile, iar ca o prima
tendin s-a dovedit necesitatea descentralizrii i interoperrii. Proliferarea diverselor platforme
(hardware i/sau sisteme de operare) au forat definirea de standarde de schimb de date i de
comunicaii, precum i dezvoltarea reelelor eterogene.
Iar pentru c lucrurile se ntmplau odat cu afluxul calculatoarelor personale, inevitabil
programatorii s-au gndit la ceva intre SGBD i spreadsheet, iar de aici la apariia unor baze de date
desktop de genul lui dBASE n-a fost dect pasul materializrii.
Evoluia ramurii desktop a bazelor de date s-a fcut in paralel cu mainstream-ul, dar influenndu-se
reciproc. Cele mai evidente tendine se pot descrie pe scurt astfel: bazele de date mici doreau s-i
dezvolte funcionaliti de sistem relaional (s poat defini relaii i s ncorporeze SQL) i s-i
extind limitele, iar cele mari i-au aplecat atenia asupra accesibilitii, materializat prin interfee
utilizator facile chiar i pentru activitile administrative (o interfa de calitate ajunge deseori un
argument de pia).

2.2.3. Modelul mainframe

Modelul centralizat iniial presupunea c baza de date este organizat i stocat integral pe un
sistem performant (denumit mainframe, sistem sau minisistem n funcie de criterii hardware) de
unde poate fi accesat de mai multe console utilizator (terminale de acces cu putere de calcul redus
conectate la calculatorul central) prin intermediul unor aplicaii de exploatare rezidente tot pe
mainframe.
Modelul s-a dovedit performant i sigur att n implementare, ct i n utilizare, dar au existat i
cteva puncte sensibile. Problema delicat la mainframe-uri nu este numrul de utilizatori suportai
(cum am fi tentai s credem), ci faptul c aplicaiile au o infrastructur rigida, a cror extindere
determin implicaii dure de organizare i administrare, pe lng creterile nedorite ale traficului de
date prin reea.

BAZE DE DATE

CURS nr. 7

Extincia dinozaurilor n-a fost deloc complet: muli nc mai fac fa aplicaiilor critice (care nici
nu pot fi ntrerupte fr pierderi), iar interoperabilitatea cu arhitecturile moderne nu-i incomodeaz
deloc, ba parca-i retriesc o a doua tineree...

2.2.4. Modelul integrat

Un mediu software independent, instalat pe un singur calculator, include att baza de date propriuzis, ct i interfaa de acces la date (un prim exemplu de astfel de mediu integrat este dBASE),
astfel c singurul utilizator va fi beneficiarul. Accesarea datelor se face fie printr-un limbaj de
generaia IV (4GL) sau printr-un macrolimbaj, fie prin elemente de interfa (comenzi la prompter,
dialoguri QBE, comenzi menu). Datele fiind organizate tabelar, exista posibilitatea de a proiecta
aplicaii relaionale.
Uzual, astfel de medii ngduie dezvoltarea de aplicaii nerelaionale, ceea ce se mai numete i
organizare plat sau bidimensional, spre deosebire de organizarea relaional, care este
multidimensional (atenie, exist pericolul confuziei cu denumirea de baza de date
multidimensional care corespunde uzual domeniului date warehouse sau aplicaiilor DSS decision support system - i OLAP - On-Line Analytical Processing, deservind analize economice
necesare deciziilor manageriale, adic extragerii ad-hoc de informaii sintetice, unde
dimensionalitatea are un caracter mai abstract i mai dinamic i nu contravine modului de stocare).
ntr-un sistem nerelaional (revenind la mediul independent), datele care altfel s-ar preta organizrii
n nomenclatoare (tabele cu nregistrri unice, legate de celelalte tabele prin relaii unu-la-n) cunosc
un grad excesiv de redundan, iar actualizarea lor presupune un efort considerabil. (Redundana
datelor, adic faptul c baza de date conine aceleai date stocate de mai multe ori, ridic att
problema spaiului ocupat, ct mai ales dificultatea asigurrii consistenei si actualitii).

2.2.4.3. Modelul File-server

n sistemele de gestiune a bazelor de date folosite astzi, se ntlnesc dou concepte ce definesc
modul de acces al clienilor la o baz de date centralizat. Primul este conceptul file-server n care
serverul lucreaz numai cu fiierele de date, fiind impropriu ca aplicaia s cear un transfer de date.
Cel de-al doilea concept este modelul client-server, n care serverul nelege natura datelor
cerute, fiind pregtit s execute astfel de cereri.
Soluia oferit de modelul file-server implic utilizarea unui server de fiiere centralizat aflat
undeva pe o reea, care pune la dispoziia clientului uniti de disc logic cu fiiere partajate. Serverul
de fiiere nu are cunotine despre cererile logice care se prelucreaz, dar acioneaz sub forma unui
disc ce poate fi accesat prin intermediul unei reele pentru a transfera date de la/spre client. Toate
aplicaiile ruleaz la client. Exemple de astfel de produse sunt FoxPro, dBase, MS Access. O baz
de date de acest tip are o fiabilitate foarte sczut deoarece ea se pstreaz sub forma unui fiier
ntr-un sistem de fiiere, fiind uor de distrus dac se produce o eroare n timpul unei prelucrri sau
a unei pierderi de conexiune n timpul efecturii unei tranzacii.

2.2.4.4. Modelul Client-server

n modelul client-server avem de a face cu o baz de date centralizat care prelucreaz cererile
logice provenite de la client.
Un astfel de server nelege att natura cererii ct i structura i localizarea datelor, majoritatea
calculelor fiind efectuate de motorul bazei de date.
Clientul are doar o interfa grafic cu care poate accesa baza de date de pe server, folosind aplicaii
pentru a transmite comenzi SQL serverului bazei de date, rezultatele fiind primite sub form de
tabele. Exemple de astfel de produse sunt: ORACLE, SQL Server, DB2, Sybase i Informix. Prin
inerea sub control, de ctre un server, a tuturor fiierelor bazelor de date, arhitectura client-server

BAZE DE DATE

CURS nr. 7

ofer o fiabilitate ridicat i o serie de alte caracteristici avantajoase ce nu pot fi oferite de

arhitectura file-server, cum ar fi:
1. Copie de siguran ce poate fi creat n timpul lucrului prin utilizarea unui planificator
automat ce face copii ale bazelor de date fr a fi necesar ntreruperea conexiunii cu
utilizatorii.
2. Tranzacii sigure prin jurnalizarea tranzaciilor, astfel nct actualizrile efectuate prin
intermediul unei tranzacii pot fi n orice moment refcute sau anulate, ajungndu-se astfel la
ultima stare consistent anterioar nceperii tranzaciei respective, indiferent dac eroarea se
produce la client sau la server. Dei motorul Microsoft Jet i fiierele .mdb ofer posibilitatea
efecturii de tranzacii, acestea nu sunt gestionate prin intermediul unui jurnal separat, iar datele
pot fi distruse fr a mai fi posibil refacerea lor.
3. Fiabilitate i protecie sporit a datelor. O baz de date n model file-server poate fi
reparat, n cazul apariiei unei erori, dar n acest caz utilizatorul trebuie deconectat, lucru care
se ntmpl foarte rar n cazul modelului client-server.
4. Procesarea mai rapid a interogrilor. Dac se folosete un fiier .mdb prin intermediul unei
reele, trebuie ncrcat motorul Jet al bazei de date la clientul la care se face cererea de
prelucrare. n acest fel traficul pe reea este foarte mare, fiind necesar transportul unei mari
cantiti de date, mai ales atunci cnd baza de date este foarte mare. n cazul modelului clientserver, prelucrrile se efectueaz direct pe server, care de obicei, este mult mai performant
dect maina clientului. Prelucrarea pe server duce la o ncrcare mult mai mare a acestuia dect
n cazul modelului file-server, dar traficul pe reea va fi substanial sczut. Prezentnd un
exemplu cu 5 utilizatori, se constat faptul c n situaia modelului file-server este posibil
blocarea reelei, deoarece toate bazele de date trebuie aduse pe calculatorul local. Din acest
motiv, atunci cnd utilizatorii pun ntrebri complexe serverului se poate ca reeaua s nu mai
fac fa solicitrilor.
n concluzie, soluiile file-server nu sunt recomandate ntreprinderilor de mari dimensiuni sau
aplicaiilor extinse, preferndu-se n acest caz soluia client-server care scade traficul de pe reea
i asigur o fiabilitatea mult crescut a sistemelor.
n acelai timp, suntem ispitii s credem, ca un reflex al superficialitii (acesta fiind unul dintre
marile riscuri actuale ale informatizrii), c dac se implementeaz o baza de date ce depete - s
zicem - un milion de nregistrri, baza de date desktop (mediu integrat) nu mai face fa i trebuie s
ne orientam ctre un alt tip de SGBDR. Pentru operarea n regim monoutilizator lucrurile nu se
prezint chiar aa: performanele (viteze de accesare i procesare a datelor) sunt ct se poate de
comparabile dac este vorba de un hardware bine echilibrat (un PC care s suporte fr probleme un
SGBDR mare va favoriza i baza de date integrat). n acest caz altele sunt criteriile care ne
orienteaz catre SGBDR-uri mari organizate in model client/server:
- operarea multiuser concurenial (considerat punctual, nici aici avantajele nu sunt nete deoarece
un FoxPro/LAN cu file-server face fa onorabil);
- descongestionarea traficului prin reea datorit transmiterii doar a datelor int (adic un minim);
- controlul drepturilor utilizatorilor i monitorizarea activitii (conectare i aplicaii);
- implementri unice de logic centralizat (reguli, proceduri, declanatoare - existente doar la
nivelul serverului);
- gestionarea tranzaciilor, aspect care devine capital/critic atunci cnd se administreaz un sistem
complex de date distribuite sau un mediu OLTP (on-line transactions processing); ceva mai recent sub influena Internetului - tranzaciile au loc prin comunicaie asincron (conversaionala) sau chiar
fr confirmare ("fire-and-forget);
- serverul asigura integritatea, consistena i actualitatea datelor (propagri de actualizri prin
mecanismele de integritate referenial);
- optimizarea organizrii fizice a datelor (colaborarea la un nivel ct mai jos cu sistemul de operare
i cu sistemul de fiiere) i optimizarea accesului la date. (Un exemplu de colaborare la nivel fizic
este posibilitatea SGBD-urilor de a face duplicri ale datelor - copiile de siguran fiind unul dintre

BAZE DE DATE

CURS nr. 7

primele niveluri ale toleranei la defectri. Desigur ca i un LAN desktop - Novell, Windows NT poate face mirroring, ins nuanele difer.)
- recuperarea datelor n caz de blocare/cdere a sistemului i refacerea tranzaciilor neterminate;
- jurnalizarea acceselor, tranzaciilor i a sesiunilor de lucru sau de administrare;
- economicitatea upgrade-ului: ridicarea performanelor globale rezid n principal n creterea
puterii calculatorului pe care ruleaz serverul bazei de date, privind mai puin calculatoarele client
pe care se afla software-ul front-end etc.
Client si server pot fi vzute i ca dou procesoare distincte rulnd pe maini diferite (mai rar pe
aceeai main), bazate eventual (dar nu obligatoriu) pe acelai sistem de operare. Comunicaia prin
care partea "client a aplicaiei solicit servicii prii server se face prin mesaje (messagepassing), fiind complet transparent utilizatorului. Posturile de lucru pot fi uzual PC-uri, laptop-uri,
staii UNIX sau Macintosh, iar serverul poate fi un mainframe, un server departamental sau chiar un
PC bine dopat. Software-ul bazelor de date implementate prin arhitectura client/server se prezint
generic astfel: SGBD-urile asigur partea de server, iar aplicaiile de exploatare a datelor se afl
uzual la nivelul client (sculele de editare a aplicaiilor utilizator aparin de productorii SGBD-urilor
implementate sau pot fi din familia celor bazate pe specificaii deschise: ODBC, JDBC, Embeded
SQL, DCOM, OLE etc.).
Repartizarea datelor i a aplicaiei (logicii) ntre straturile "client i "server nu este preimpusa,
fiecare implementare fiind susceptibila de un optim.
Arhitectura client/server dovedete suplee (modularitatea i scalabilitatea oferind disponibilitate
crescut la reorganizri i extinderi) i deschidere (chiar se consider ca ea a aprut din necesitatea
de a asigura o deschidere i interoperabilitate superioare modelului centralizat cu mainframe).
Modelul client/server a fost i el susceptibil de perfecionri de principiu, iar una dintre cele mai
interesante este impunerea de niveluri/straturi intermediare intre client i server (n-tier), ca raspuns
la dilema legata de poziionarea programelor de aplicaie (logica de operare/afacere): care dintre
pri trebuie sa fie mai "groase, clientul sau serverul? ntruct avantajele locale erau permanent
necomplementare, s-a dezvoltat ideea unui strat intermediar, concretizat ntr-un server de aplicaii
interpus ntre clientul subire i serverul bazei de date (middle-tier), ambele capete fiind astfel
descongestionate de partea de logica. Interesant este i observaia unor analiti care asociau
tendina modern de accentuare a clientului subire cu revenirea la modelul mainframe cu terminale
"chioare. Oricum, cerinele actuale privind deschiderea mediilor informaionale determin diluarea
graniei dintre modele, reelele eterogene fiind vzute ca soluia cea mai viabil de a menine
echilibrul ntre permanentele inovaii i conservarea investiiilor anterioare.
ns cele mai deranjante dezavantaje ale arhitecturii client/server deriv din complexitatea ei
(cerine asupra personalului implicat: nelegerea conceptual a arhitecturii de ctre persoanele de
decizie, precum i cunotine aprofundate pentru cei care implementeaz/dezvolt efectiv
sistemul/aplicaiile) i din standardizarea insuficient.
Majoritatea serviciilor Internetului se desfoar n regim client/server (banala navigare nseamn
un utilizator accesnd datele dintr-un site-server prin intermediul unei aplicaii client, care este
browserul de Web), astfel c devine natural implicarea SGBDR-urilor n aplicaii Internet (de
genul e-business sau e-commerce). S ne imaginm urmtorul scenariu: un furnizor de produse i
organizeaz un catalog de produse (magazin virtual) pe care utilizatorii l pot consulta prin
navigatorul de acas. Lucrurile se desfoar prin pagina HTML pe care serverul de Internet o
trimite clientului, la rndul ei respectiva pagina acionnd ca ablon (formular/form) de accesare a
informaiilor comerciale din baza de date deservit de un server legat la site-server (cel mai frecvent
baza de date conine i imagini dac nu chiar i alte date multimedia). Iar daca utilizatorul va
comanda din produsele expuse completnd un formular din pagina Web (controlat printr-un script),
se declaneaz o alt serie de comunicaii ntre client i server.

2.2.6. Baze de date distribuite

Adevratul sens al atributului "distribuit n contextul SGBD-urilor corespunde nu faptului c
sistemul permite accesarea datelor de la distan (prin reea), ci acelor implementri care ngduie

BAZE DE DATE

CURS nr. 7

aplicaiilor i utilizatorilor s trateze baza de date ca pe un singur depozit logic chiar dac datele
constituente sunt repartizate n mai multe locaii ale reelei (transparena complet a localizrii
datelor). Totui problema este delicat i pentru c - din punctul de vedere al analizei - se poate
oricnd crea o aplicaie care s trateze unitar tabele de date situate pe calculatoare diferite. Dar
pentru c adevrata baz de date se dorete independent de limbaje (sau de mediile de dezvoltare)
sunt de apreciat acele SGBD-uri care conin integrate funcionaliti care s asigure distribuirea
datelor n nodurile reelei.
innd cont c de obicei volumul i complexitatea datelor spulber idealul "un computer foarte
performant cumulnd ntreaga baza de date i deservind toi utilizatorii ntreprinderii/organizaiei
i trebuie gsit o soluie de compromis, devine foarte interesant colecia de criterii practice de
distribuire a datelor n cazul fiecrei implementri, particularitile cernd un optim jalonat de
urmtoarele aspecte:
- nu trebuie niciodat pierdut din vedere dezideratul vitezei;
- limita de stocare i puterea calculatoarelor gazda;
- limita de transfer a reelei;
- preferabil ca fiecare aplicaie s acceseze uzual un singur depozit al bazei de date (fr a
mpiedica accesarea cu frecven redusa a celorlalte noduri ale reelei);
- folosirea funciilor two-phase-commit existente pentru a asigura integritatea datelor
actualizate distribuit;
- planificarea, controlul i minimizarea duplicrii de obiecte ale bazei de date;
- corelarea organizrii cu facilitile de optimizare distribuit ale SGBD-ului.
Cercetatorul Chris Date (coleg de proiecte cu E.F. Codd) a enunat cele 12 cerine ideale crora
trebuie s li se supun bazele de date distribuite; dintre acestea 9 sunt urmtoarele:
0. Autonomia local: datele locale sunt deinute i administrate local - nici un post nu depinde
de altele pentru a funciona.
1. Toate posturile sunt egale: nici un post nu se bazeaz pe o staie central.
Funcionare nentrerupt: nu trebuie s fie necesar o oprire planificat (instalrile/tergerile
efectuate la un post nu afecteaz funcionarea celorlalte).
2. Transparena amplasrii: utilizatorii nu sunt obligai s tie unde sunt amplasate datele
pentru a le extrage. Transparena fragmentrii: relaiile dintre componentele bazei de date
pot fi fragmentate pentru stocare, dar acest lucru rmne transparent pentru utilizator.
3. Transparena duplicrii: relaiile i fragmentele pot fi reprezentate fizic prin copii multiple
stocate separat, dar transparent pentru utilizator.
4. Prelucrarea interogrilor distribuite: operaiile de citire/scriere se pot desfura la mai multe
posturi, permind optimizarea locala i global a interogrilor.
5. Actualizrile distribuite: tranzaciile singulare pot executa codul la mai multe posturi.
6. Independena de hardware: toate calculatoarele particip ca membri egali.
7. Independena de sistemul de operare: sunt suportate mai multe sisteme de operare
conectabile la reea. Independena de reea: sunt suportate mai multe reele prin protocoale
comune.
8. Independena de bazele de date: se asigur accesul uniform (interfaare unic) pentru datele
provenind din SGBD-uri diferite.