Ministerul Educaiei al Republicii Moldova

Universitatea Tehnica a Moldovei

Facultatea: Calculatoare Informatica si Microelectronica
Catedra: Automatica i Tehnologii Informaionale

Lucrare de curs
Disciplina: Baze de date i cunotine
Tema: Fragmentarea bazelor de date distribuite

A efectuat:

st. gr. SI-121

Serioghina Valeria

A verificat:

Saranciuc Dorian

Chiinu 2015

Introducere
O baz de date, proiectat corespunztor, furnizeaz acces la
informaii precise, actualizate. Deoarece o proiectare corect este esenial
pentru atingerea scopurilor utilizrii unei baze de date, capacitatea de a
proiecta baze de date i aplicaii asociate este critic pentru succesul oricrei
ntreprinderii moderne. Elaborarea automat i dezvoltarea bazei de date i a
sistemului informaional, n ntregime, const dintr-o serie de etape, care
necesit cercetri metodologice, modele i algoritmi eficieni i instrumente
software de proiectare.
Se constata in ultima perioada in tehnologia informatiei si implicit in domeniul bazelor de
date existenta a doua curente aparent contradictorii: centralizarea si respectiv distribuirea. Chiar
daca ambele urmaresc obtinerea unor avantaje, este cunoscut faptul ca pentru orice avantaj se
plateste un pret. Pentru baze de date centralizate avantajele majore sunt determinate de o buna
integritate a datelor cu redundanta minima, asigurarea consistentei prelucrarilor, gestiunea facila
a tranzactiilor cu respectarea stricta a proprietatilor ACID. Din perspectiva bazelor de date
distribuite, ca efect al descentralizarii, integritatea datelor, redundanta minima si indeplinirea
proprietatilor ACID trebuiesc relaxate fiind foarte greu de indeplinit, insa cresterea disponibilitati
constituie un avantaj major. Decizia de utilizarea a uneia sau alteia dintre solutii poate fi luata
doar dupa o atenta analiza a cerintelor aplicatiei, a dimensiunii bazei de date, a caracteristicilor
infrastructurii disponibile impreuna cu evaluarea performatelor globale pentru intregul sistem.
O baza de date distriuita (BDD) este reprezentata de o colectie de date partajate ce sunt
distribuite fizic pe nodurile unei retele de calculatoare. Gestiunea unei baze de date distribuite
este realizata de un sistem de gestiune al bazei de date distribuite (SGBDD), capabil sa opereze
cu baza de date similar cu un SGBD centralizat, fara ca utilizatorii sa cunoasca unde sunt
localizate datele pe care le acceseaza. Se mai spune ca baza de date este constituita din insule de
informatii distribuite.

Reguli date
Pentru ca un sistem de gestiune al bazei de date sa fie cu adevarat distribuit, el ar trebui sa
respecte in totalitate cele 12 reguli introduse de C.J. Date in 1987 [Dat87]. Putem afirma ca
aceste reguli sintetizeaza motivele principale pentru care este necesara distribuirea datelor pe mai
multe calculatoare intr-o retea si constituie in acelasi timp si obiectivele principale ale unui
SGBDD. Cele 12 reguli formulate de Date se constituie ca o metrica de evaluarea a bazelor de
date distribuite, cu toate ca nu se cunoaste inca nici un produs care sa satisfaca toate aceste
cerinte. Sintetizate cele 12 reguli sunt:
Autonomia locala. Un sistem de baze de date distribuit trebuie sa ofere pentru fiecare
locatie implicata un grad inalt al autonomiei locale. Ca urmare, fiecare locatie trebuie
sa-si gestioneze propriile date si sa ofere functionalitate independent de celelalte
locatii. Chiar daca uneori, pentru o completa functionare, o locatie are nevoie de
datele pastrate la alte locatii, nu inseamna ca propria functionare este conditionata de
acele locatii. Existenta dependentelor functionale stranse duce la propagarea conditionalitatilor
astfel incat intregul sistem devine inoperabil. In realitate, acest
obiectiv nu este indeplinit 100%. Uzual, intre locatii exista o anumita ierarhie si intr-o
oarecare masura conditioneaza principiul autonomiei. De regula, sunt asigurate local
securitatea, functiile de backup si refacre.Conceptul este totusi putin relaxat chiar de
autor prin formularea: autonomia locatiilor trebuie respectata in cea mai mare
masura posibila.
Absenta unei dependente de o locatie centrala.Este de dorit ca toate locatiile sa aiba
aceleasi capabilitati. Chiar daca intre locatii exista o anumita ierarhie, nu trebuie
exagerat. Intr-un sistem distribuit nu trebuie sa existe o locatie raspunzatoare in
totalitate de realizarea unei anumite functii sau activitati. Nu putem avea un nod in
care sa se realizeze controlul centralizat al tranzactiilor, gestiunea centralizata a
interogarilor, gestionrea accesului concurent pentru intreg sistemul, rezolvarea
problemelor de concurenta etc. Absenta dependentei de locatia centrala poate fi
rezumata prin inexistenta unui singur dictionar de date. Dependenta totala fata de un
anumit nod este nedorita pentru ca ar supraincarca nodul si nu se asigura o
functionare normala, atat a nodului, cat si a intregului sistem. Locatiile dedicate duc
la cresterea cheltuielilor globale ale sistemului, dar si la disfunctionalitati pentru
intreg sistemul atunci cand un astfel de nod devine nefunctional.
Operare continua sau independenta la defectare. Obiectivul operarii continue se
refera la doua aspecte majore ce privesc indeaproape performantele sistemelor
distribuite, si anume: fiabilitatea si disponibilitatea. Fiabilitatea reprezinta capacitatea
unui sistem de a functiona fara intrerupere cu asigurarea unor parametri de calitate.
Sistemele distribuite, spre deosebire de sistemele tranzactionale, nu urmaresc
principiul atomicitatii. Acestea opereaza neintrerupt, chiar si in cazul aparitiei unei
defectiuni la componente sau la mediul de comunicatie. Disponibilitatea se refera la
aspectul functionarii sistemului pe o perioada prestabilita, fara posibilitatea ca, din
anumite motive, o parte din date sa fie inaccesibile. In principal cerinta presupune
capabilitatea de ajustare a bazei de date fara a necesita trecerea acesteia offline.
3

Multe baze de date permit actualizarea schemei locale si backup pentru date chiar cu
baza online. Faptul ca un nod s-a defectat nu inseamna ca datele care erau stocate pe
acesta nu vor mai putea fi accesate, intrucat prin relaxarea redundantei datele se
gasesc si la alte locatii. Este de dorit ca sistemul sa nu fie afectat de nici un incident si
capabilitatea de functionare sa fie mentinuta chiar si in timpul procedurilor de
mentenanta.
Independenta de localizare. Locul in care au fost stocate sau de unde sunt accesate
datele trebuie sa fie transparent, atat pentru utilizator, cat si pentru aplicatiile care
ruleaza. Utilizatorul trebuie sa se comporte in aceeasi maniera si sa fie servit de catre
sistem in consecinta, chiar daca el lanseaza cereri de pe nodul A, iar datele solicitate
se afla la nodul A, X sau Y. Acest principiu poarta uneori numele de transparenta la
localizare. Acesta se constituie in nivelul mediu de transparenta la distribuire, ceea ce inseamna
ca utilizatorul va sti ca relatia globala este fragmentata, si ce anume
contine fiecare segment, fara insa a cunoaste locul unde fragmentele sunt plasate.
Asadar, nu mai este suficienta o cerere adresata schemei globale, utilizatorul trebuind
sa precizeze si denumirea fragmentelor din care se vor extrage informatiile. Totusi,
operatorul nu trebuie sa fie preocupat de locul in care sunt distribuite fragmentele si
nici de faptul ca ar putea exista replici ale acestora.
Independenta de fragmentare. Spre deosebire de bazele de date centralizate, destinate
unui nod central, baza de date distribuita este impartita in fragmente ce sunt
distribuite pe toate locatiile sistemului. Aceste portiuni ale bazei globale se numesc
fragmente si datorita dimensiunii lor in raport cu sursa din care provin vor duce la
cresterea performantelor sistemului. Fragmentarea bazei de date are impact direct
asupra cresterii concurentei bazei de date, intrucat in momentul in care un utilizator
doreste sa faca o actualizare, va bloca pentru o scurta perioada de timp doar o mica
parte a unui fragment, deci o parte nesemnificativa a bazei de date globale.
Fragmentarea se poate face dupa diferite criterii, iar fragmentele rezultate trebuiesc
dispersate pe statiile de lucru astfel incat sa fie atribuite locatiilor la care este cea mai
mare nevoie. Mai mult, din fragmente in orice moment se va putea recompune baza
de date initiala. Daca aceste deziderate sunt realizate, utilizatorul nu va simti
niciodata ca ceea ce acceseaza el sunt de fapt fragmente stocate in diferite locuri si nu
baza de date in totalitate, aflata pe nodul local. Independenta de fragmentare
reprezinta elementul central al transparentei la distribuire. Chiar daca utilizatorul stie
ca datele sunt fragmentate, el nu trebuie sa se comporte diferit fata de un utilizator al
unei baze de date centralizate. El trebuie sa lanseze cereri identice cu cele de la bazele
centralizate, fara a trebui sa faca un efort suplimentar in a cauta si mentiona explicit
in interogare ce fragmente solicita si evident locatia acestora. Pentru acces la baza de
date distribuita se va consulta schema globala fara implicarea utilizatorului.
Transparenta la distribuire este asigurata prin transparenta la fragmentare. Din
punctul de vedere al utilizatorului nu prezinta importanta modul in care s-a facut
fragmentarea, locul unde sunt amplasate fragmentele si nici faptul ca unele dintre
fragmente pot avea replici in diverse locatii. In general bazele de date ofera suport
pentru fragmentarea pe orizontala, insa suport ineficient pentru fragmentare pe
verticala.
Independenta la replicare.Atat din motive de securitate cat si de disponibilitate a
4

datelor, anumite fragmente trebuie sa fie copiate la mai multe locatii. Aceste copii se
numesc replici sau reproduceri. Utilizarea replicilor si alocarea lor pe diferite locatii
trebuie sa fie facuta transparent fata de utilizator. Acesta trebuie sa fie in continuare
convins ca lucreaza de fapt pe intreaga baza care se afla stocata local. Acest lucru este
posibil daca replicile sunt plasate acolo unde sunt directionate frecvent cererile
specifice. Independenta de replicare se mai numeste si transparenta la replicare.
Conform acesteia, utilizatorul va trebui sa transmita cereri catre fragmente bine fara a fi obligat
totusi sa cunoasca localizarea si nici faptul ca fragmentele
consultate ar mai avea si alte amplasari posibile in retea. Replicarea datelor scade
performantele atunci cand cererile trebuie sa se propage prin retea. Existenta
replicilor locale creste performanta accesului la date intrucat nu necesita comunicare
in retea. Daca se face actualizarea unei replici sunt posibile mai multe modalitati
pentru actualizarea tuturor replicilor. O replica poate fi actualizata sincron, prin
protocolul numit si commit in doua faze,cu efect actualizarea tuturor replicilor sau
asincron, atunci cand nu este necesar ca modificarile sa fie reflectate imediat in toate
replicile. Unele medii de baze de date ofera suport doar pentru replicare asincrona,
altele cer ca aplicatiile sa includa triggeri pentru actualizarea replicilor. Acest tip de
transparenta reprezinta ultimul nivel al transparentei la distribuire, foarte apropiat de
nivelul fizic.
Prelucrarea distribuita a interogarilor. De cele mai multe ori, atunci cand se
formuleaza o interogare, oricat de bine ar fi plasate fragmentele si replicile, rareori se
vor obtine interogari pur locale. Datele pe care in general, o cerere le solicita sunt
plasate in cel putin doua locatii diferite. Pentru a raspunde unei astfel de solicitari in
mod eficient trebuiesc executate cat se poate de multe operatii asupra datelor stocate
la fiecare locatie, in conformitate cu principiul autonomiei. In vederea optimizarii
interogarilor, problema trebuie tratata atat la nivel global prin stabilirea strategiei
functie de datele problemei, coordonarea tuturor operatiunilor aferente, transmiterea
si preluarea de mesaje catre si dinspre locatii, cat si la nivel local prin strategia interna
de prelucrare a interogarilor, comunicare rezultate partiale si verificari. Daca cererea
a fost emisa de locatia X, acesta o va transmite si locatiei Y pentru a executa
operatiile necesare dupa care va returna un rezultat partial. In functie de cardinalitatea
rezultatelor partiale, a dimensiunii unui n-uplu cat si a vitezei de transfer pe
infrastructura fizica sau virtuala de comunicatie, una dintre locatii va trimite catre
cealalta rezultatul partial pentru efectuarea prelucrarilor finale. In cazul distributiei la
doua locatii este necesara transmiterea a doar doua mesaje (cererea de prelucrare si
rezultatul in sens invers). Cu cat numarul de locatii creste numarul de mesaje creste
datorita cererilor multiple catre locatii si a raspunsurilor de la acestea. O alta
problema vine de la multitudinea modalitatilor de rezolvare a interogarii, stiut fiind
faptul ca pot exista mai multe solutii de procesare a unei cereri. Cu toate ca
prelucrarea unei interogari intr-un mediu distribuit presupune o activitate mai
complexa, asta nu presupune ca raspunsul este intarziat, ci poate fi chiar mai prompt
decat in cazul sistemelor centralizate datorita puterii crescute de calcul distribuit.
Algoritmii de optimizare pentru executia tranzactiilor trebuie sa tina cont suplimentar
de viteza retelei de comunicatie. In general, se urmareste ca tratarea cererilor sa fie
cat mai apropiata, ca performante,de cea a cererilor locale.
5

Gestionarea distribuita a tranzactiilor. Gestiunea tranzactiilor are ca obiect de studiu

controlul accesului concurent si problematica tolerantei la defecte. Fata de abordarea cu un
singur nod central, in cazul sistemelor distribuite lucrurile devin mult mai
complicate. O tranzactie lansata in sistemul distribuit are nevoie de agenti, care sa
verifice rezultatul finalizarii tranzactiei in fiecare din locatiile implicate. Evident ca si
in mediul distribuit proprietatile tranzactiilor (ACID - Atomicitate, Coerenta, Izolare,
Durabilitate) trebuie sa fie respectate. Pentru ca o tranzactie sa corespunda pretentiilor
de atomicitate trebuie ca fiecare agent al tranzactiei sa-si indeplineasca sarcina, in caz
contrar toti sunt nevoiti sa execute o tranzactie in compensare pentru a pastra
consistenta bazei. Similar cu bazele de date centralizate metoda cea mai raspandita de
control al accesului concurent se bazeaza pe blocare. Gestionarea distribuita a
tranzactiilor este strans legata de problematica transparentei tranzactiilor. Fara a lua in
considerare aspectele privitoare la controlul concurentei si a rezistentei la defecte,
intr-un mediu distribuit, descompunerea unei tranzactii in subtranzactii duce la
cresterea performantelor atat la nivelul vitezei de executie, cat si din punctul de
vedere al concurentei. Referitor la transparenta la defectare si capacitatea de refacere,
trebuie sa se tina cont de atomicitatea tranzactiilor si de caracterul durabil al
modificarilor facute. Un SGBD distribuit trebuie sa garanteze ca tranzactia globala
este atomica, adica toate tranzactiile locale pe care le implica fie s-au terminat cu
succes, fie au fost toate anulate. Nu putem avea situatii de compromis, deoarece
datorita caracterului durabil al subtranzactiilor se poate ajunge la inconsistente. Pe
langa problemele cu care se confrunta sistemele centralizate (caderea sistemului, pene
de comunicatie, erori software, neglijenta, dezastre fizice, naturale sau sabotajul) un
sistem distribuit trebuie sa tina cont si de: pierderea unui mesaj, defectarea legaturilor
de comunicatie, defectarea unui nod sau de partitionarea retelei. Un sistem distribuit
trebuie sa furnizeze un mecanism de refacere, care indiferent de aparitia unor posibile
accidente, de genul celor enumerate, trebuie sa sustina atomicitatea tranzactiei
globale. In general, aceasta cerinta este asigurata prin protocolul commit in doua faze
(two phase commit).
Independenta de hardware. De mai mult timp aplicatiile software trebuie sa satisfaca
criteriul transparentei fata de hardwareul utilizat. Nici sistemele distribuite nu trebuie
sa faca rabat de la aceasta caracteristica. Infrastructura hardware poate fi compusa din
echipamente de la diferiti producatori in configuratii si cu performante diferite.
Utilizatorul nu trebuie sa sesiseze vreo diferenta in functionarea sistemului nici chiar
daca lucreaza alternativ pe masini cu tehnologii de fabricatie diferite. Multe baze de
date opereaza pe o varietate de platforme.
Independenta de sistemul de operare. Un sistem distribuit trebuie sa poate functiona
atat pe masini diferite din punct de vedere al tehnologiei hardware, cat si pe
calculatoare pe care sunt instalate sisteme de operare diferite. Utilizatorul nu trebuie
sa resimta amprenta sistemelor de operare diferite, instalate pe masini diferite, sau
chiar pe acelasi echipament. Indiferent ca e vorba de sistemul de operare Unix,
Windows, OS/2, de versiuni diferite, sistemul distribuit trebuie sa poata rula pe oricare dintre
acestea, fara ca operatorul sa sesiseze diferente de utilizare intre masini
cu sisteme de operare diferite.
Independenta de infrastructura de comunicatie. Nodurile sistemului distribuit sunt
6

conectate logic la aceeasi retea de comunicatie. Chiar daca topologiile, vitezele de

transfer, dimensiunile pachetelor, metodele de acces la mediu sau tehnologia
subretelelor, peste care acesta se intinde, sunt diferite, acestea nu trebuie sa devina un
impediment in buna functionare a sistemului.
Independenta de sistemul de gestiune al bazei de date. Acest deziderat este unul
dintre cel mai greu de atins. Ideal ar fi ca pe toate masinile sistemului distribuit sa
ruleze acelasi SGBD. Nu intotdeauna acest lucru poate fi pus in practica datorita
eterogenitatii echipamentelor si a sistemelor de operare, fara a ne putea detasa si de
latura financiara. Chiar daca SGBD-urile sunt diferite, ar fi cel putin recomandat ca sa
nu existe problema incompatibilitatii canalelor de comunicare intre locatiile avand
SGBD-uri diferite. Pentru acessta, fiecare locatie ar trebui sa recunoasca acelasi
standard SQL. Sistemul distribuit ideal ar fi acela care ar putea asigura transparenta
fata de orice SGBD utilizat. In general, cerinta este asigurata prin instalarea unui
gateway (componenta software) pentru adaptarea de la un SGBD la altul.
Din punctul de vedere al sistemului fizic ce constituie suportul pentru o baza de date distribuita
se includ: calculatoare personale, minicalculatoare, statii de lucru, dispositive mobile etc, toate
conectate intr-o retea de comunicatie si numite generic noduri, site-uri sau locatii. Cu aceste
precizari definitia unui sistem de baze de date distribuite poate fi reformulata ca o colectie de
noduri, fiecare putand participa la executarea tranzactiilor care acceseaza datele stocate la un
nod sau la mai multe noduri.
Regulile formulate de Date sunt destul de restrictive, motiv pentru care acestea trebuiesc relaxate
in sistemele de baze de date distribuite. Principalele cerinte ce trebuie asigurate intr-un sistem de
baze de date distribuite sunt:
autonomia locala in organizarea si prelucrarea datelor;
neutilizarea unei centralizari pentru evidenta si accesarea datelor;
posibilitatea operarii continuea nodurilor independent de schimbarile in configuratiile de
lucru (adaugarea sau eliminarea unor noduri);
independenta fata de localizarea si modul de fragmentare a datelor sau altfel spus
transparenta fizica;
asigurarea de facilitati pentru copierea sau replicarea datelor cu pastrarea independentei
copiiilor;
cresterea performantelor prin prelucrarea distribuita pe nodurile sistemului a cererilor;
capabilitatea de administrare distribuita a executiei tranzactiilor;
independenta sistemului de componentele hardware, de sistemul de operare, de topologia
retelei si de sistemul de gestiune a bazelor de date ce ruleaza pe nodurile sistemului.
Intr-un sistem de baze de date distribuit baza de date este descompusa in fragmente, unele
fragmente pot fi multiplicate, astfel ca un fragment sau o copie a acestuia este stocat pe unul sau
mai multe noduri sub controlul unui SGBD local. La fiecare nod pot fi procesate interogari
locale cerute de utilizator fara a implica alte noduri ale retelei, sau nodul participa la procesarea
unor date gazduite de alte noduri din retea, indiferent de SGBD-ul instalat pe acestea. Atunci
cand o cerere implica si date distante spunem ca este o cerere globala iar din punctual de vedere
al executiei avem o executie distribuita. Similar cu sistemele de baze de date cetralizate
operatiile asupra bazei de date sunt grupate in tranzactii. Intr-o baza de date distribuita
7

tranzactiile se impart in:

tranzactii locale acele tranzactii pentru executia carora nu sunt necesare resurse stocate
pe un alt nod si tranzactia este ceruta de un utilizator conectat la baza de date locala
tranzactii distante (remote) sunt tranzactii cerute de un utilizator conectat la baza de
date de la alt nod, dar pentru executia sa sunt necesare numai resurse aferente unui singur
nod distant;
tranzactii distribuite tranzactii lansate de un utilizator conectat la baza de date aferenta
unui nod pentru a caror executie sunt necesare resurse gazduite de cel putin doua noduri,
indifferent daca ambele sunt distante sau unul este local;
Obs. Pentru executia tranzactiilor remote si a tranzactiilor distribuite se impune ca fiecare nod
sa stie de existenta celorlalte noduri si de capabilitatea acestora de a participa la executia
tranzactiilor.

Avantaje i dezavantaje baze de date distribuite

In primul rand prin distribuirea datelor unei baze de date pe mai multe noduri obtinem o
extensie a spatiului de stocare si in acelasi timp oferim resurse de procesare multiple. Chiar daca
puterea de calcul a crescut foarte mult in ultimii ani, la prelucrarea volumelor mari de date
performantele devin inacceptabile. Prin distributia datelor pe mai multe centre de procesare se
obtin avantaje considerabile privind performantelein principal datorata prelucrarii paralele pe
mai multe noduri, dar garantarea indeplinirii proprietatilor ACID este mult mai greu de realizat.
Pe langa acestea sistemele de baze de date distribuite ofera o serie de avantaje aditionale:
Se identifica cu structura organizationala a multor organizatii, pe care o modeleaza mult
mai bine, avand in vedere ca multe companii sunt localizate "distribuit" din punct de
vedere geografic;
Cu toate ca datele sunt partajabile, administrarea lor se bucura de un grad inalt de
autonomie locala. Datele pastrate pe fiecare site pot fi administrate independent de catre
administrator diferiti;
Ofera o disponibilitate ridicata pentru accesul la baza de date fata de sistemele
centralizate. Chiar si in cazul in care apar erori de comunicatie sau defectari de noduri
sistemul poate continua sa functioneze in conditii satisfacatoare;
Se imbunatateste fiabilitatea sistemului intrucat pot fi refacute rapid fisierele distruse
utilizand replici gazduite de alte noduri;
Diminuarea costurilor de implementare si intretinere prin utilizarea de echipamente
uzuale in nodurile de prelucrarea fata de un sistem centralizat care sa ofere aceeasi putere de
prelucrare. Prin realizarea a cat mai multe prelucrari locale, arunci cand aplicatiile
permit acest lucru, scade costul de exploatare prin diminuarea costului comunicatiilor.
Cresterea scalabilitatii sistemului prin posibilitatea de adaugare sau extragere a noi
noduri, functie de necesitatile de exploatare. Ajustarea puterii de calcul la sistemele
centralizate este mult mai costisitoare si in plus necesita timpi de oprire a
functionalitatilor;
Nu trebuie insa sa minimalizam efectele negative ale distributiei, dintre care principalele sunt:
Cresterea complexitatii cu efecte in ceea ce priveste complicatiile de implementare si
gestionare, necesitatea existentei unui personal specializat, necesitatea unei infrastructuri
de comunicatie;
Sensibilitatea la erori datorata algoritmilor de procesare distribuita pentru care consistenta
datelor este greu de mentinut;
Necesitatea unor prelucrari suplimentare pentru asigurarea schimburilor de mesaje intre
noduri si pentru coordonarea activitatii acestora;
Deschiderea de noi brese de securitate in comparatie cu un sistem centralizat. Sistemul,
prin distributia sa geografica nu poate fi ascuns in spatele unui firewall, o serie de date
sensibile sunt schimbate intre noduri pe infrastructura de comunicatie;
Existenta mai multor entitati de administrare cu politici de administrare diferite;
Asigurarea integritatii datelor este greu de realizat fata de sistemul centralizat. Din cauza
costurilor mari de comunicatie, dar si atimpilor de raspuns, de cele mai multe ori se
9

renunta la o parte din regulile ce trebuie verificate pentru datele din baza.
Probleme legate de standardizare. Chiar daca nu se poate vorbi de o lipsa totala de
standardizare putem afirma ca nu sunt inca standarde internationale unanim acceptate
care sa garanteze comunicarea eficienta, proiectarea, gestionarea si exploatarea datelor in
sisteme distribuite.
Este posibila aparitia unui flux mare de informatii intre noduri care sa necesite rezolvarea
problemelor legate de sincronizarea mesajelor, detectarea erorilor, inconsistenta datelor
redundante.

10

Proiectarea unei baze de date relationale distribuite

Pentru proiectarea unei baze de date distribuita avand ca model al datelor modelul
relational se parcurg de regula, in prima faza aceleasi etape ca si pentru o baza de date
centralizata prin care se obtine schema relationala sau modelul relational al bazei de date. Daca
la o baza de date centralizata, schema relationala se particularizeaza functie de SGBD si se
transpune apoi in modelul intern care defineste structura tabelelor bazei de date, la sistemele
distribuite principale problema de proiectare ce trebuie rezolvata consta in luarea deciziei privind
plasarea datelor si a programelor pe nodurile de calcul sau eventual chiar reproiectarea retelei de
calculatoare.
Un astfel de process presupune decizii privind SGBD-ul ce ruleaza pe fiecare nod, a
datelor ce vor fi stocate pe fiecare nod si a aplicatiilor care ruleaza baza de date. La acest
moment discutam doar despre distributia datelor. Desigur ca in proiectarea bazei de date
distribuite sunt posibile mai multe strategii determinate in principal de situatia actuala concreta.
Daca baza de date este nou proiectata se va porni de la cerinte si are ca rezultat, de cele mai
multe ori un sistem omogen, pe cand daca anumite componente ale bazei de date exista deja pe
un numar de locatii acestea trebuie conectate pentru a rezolva sarcinile cerute.
Partea centrala, specifica pentru baze de date distribuite, este cea privind proiectarea
distributiei, celelalte activitati fiind similare ce cele ale proiectarii bazelor de date centralizate.
Principalul obiectiv pentru proiectarea distributiei consta in decizia privind modul de alocarea a
relatiilor sau a subrelatiilor pe noduri. Doua aspecte sunt importante si trebuie abordate cu mare
atentie:
Fragmentarea operatia prin care o relatie este impartita intr-un numar de subrelatii ce
urmeaza a fi distribuite;
Alocarea determinarea locului in care un fragment este stocat pentru o distributie
optima si eventual a numarului de copii ale fragmentului pe mai multe noduri. In situatia
in care se decide ca un fragment sa fie stocat intr-un numar de copii pe langa problema
alocarii intervine si problema replicarii.

11

Fragmentarea
O intrebare obisnuita vrea sa dea un raspuns la intrebarea Cum este mai rezonabil sa
distribuim o relatie sau un fragment al unei relatii? Desigur ca raspunsul este greu de stabilit,
intrucat sunt motive intemeiate pentru a distribui relatii si la fel de intemeiate pentru a distribui
fragmente. O analiza este necesara pentru a determina situatiile in care este avantajoasa
distributia relatiei, respectiv a fragmentelor. In cazul in care se distribuie intreaga relatie sunt
posibile urmatoarele situatii:
O intreaga relatie replicata intr-un numar mare de copii va genera probleme la
actualizarea datelor pentru sincronizarea tuturor replicilor, mai ales in situatia in care
datele se modifica la mai multe locatii;
Daca relatia nu este replicata, pentru accesul la date de la distanta se va genera un volum
mare al traficului si datele vor fi disponibile cu mare intarziere. Sunt situatii in care
intreaga tabela trebuie transmisa unui alt nod;
Relatia se pastreaza la un singur nod daca cererile necesita toate datele stocate in relatie si
datele se stocheaza pe nodul care utilizeaza datele;
Un principiu universal valabil arata ca este mult mai usor sa distribuim programe in
sensul ca datele sa se gaseasca in acelasi loc cu programele decat sa transportam date.
Descompunerea relatiilor in fragmente si distribuirea fragmentelor este rezonabila daca:
Aplicatiile acceseaza usual numai anumite subseturi de date ale relatiei;
Descompunerea relatiiilor in fragmente si distributia lor permite executarea de tranzactii
in paralel intrucat fiecare operatie are nevoie de acces la un set deferit de date din relatie;
Cererile contin subcereri ce pot fi executate in paralel.
Cu toate aceste avantaje pastrarea integritatii unei relatii descompuse in fragmente si distribuite
intre mai multe noduri este greu de asigurat. Din cele analizate rezulta ca atat fragmentele cat si
relatiile sunt unitati corespunzatoare pentru distributie, insa decizia privind distributia trebuie
foarte bine analizata. Fragmentarea bazei de date asigura suplimentar o serie de alte avantaje
cum sunt: cresterea fiabilitatii, cresterea performantelor, scaderea costurilor de comunicatie,
cresterea securitatii prin politici de securitate diferite la noduri, utilizarea eficienta a capacitatii
de stocare. Alte criterii ce trebuie luate in consideratie la decizia de fragmentare constau in
analizarea locului in care o cerere se executa, ce seturi de date necesita, care este fvrecventa de
executie a unor cereri specifice, modul in care datele sunt accesate: read sau write.
Se cunosc mai multe tipuri de fragmentare, indiferent de modul in care fragmentarea este
efectuata trebuie sa existe o succesiune de operatii prin care relatia fragmentata sa poate fi
refacuta. Fragmentarea poate fi:
Orizontala atunci cand n-uplurile relatiei sunt segmentate in mai multe fragmente
fiecare dintre acestea avand aceleasi attribute cu cele ale relatiei originale. In aceasta
situatie sunt puse intr-un fragment n-uplurile care indeplinesc o anumita conditie,
respectiv celelalte in alt fragment. Din punctul de vedere al reconstructiei o simpla
12

operatie UNION reface relatia initiala. In principal, fragmentarea orizontala decupeaza o

tabela pe orizontala pastrand in fiecre fragment inregistrarile satisfacand o anumita
conditie ce defineste setul de inregistrari. Fragmentarea orizontala nu afecteaza
redundanta in sensul ca fragmentele pot sa contina date distincte si nu sunt pastrate
aceleasi n-upluri in mai multe fragmente. Pentru descompunerea unei relatii in fragmente
se executa operatii similar cu operatiaSELECT din algebra relationala. Daca o relatie R a
fost fragmentata orizontal in fragmentele R1, R2, R3, putem a recompune relatia initiala
prin = 1 2 3;
Verticala partitonarea relatiei dupa atributele sale. Un fragement contine toate nuplurile
relatiei, insa numai anumite atribute ale acesteia. Pentru refacerea relatiei initiale
este necesara o operatie de tip join insa pentru realizarea acesteia fragmentele trebuie sa
contina ca informatie redundanta macar atributul cheie al relatiei initiale. Se observa ca
fragmentarea pe verticala necesita un grad mai mare de redundanta pentru pastrarea in
fiecare fragment a atributului cheie. Fie o relatie R si S1, respectiv S2 doua subseturi de
atribute ale lui R, ambele subseturi contin cel putin un atribut cheie si reuniunea celorlalte
atribute contine toate atributele lui R, prin fragmentarea pe verticala vom obtine
fragmentele R1 si R2 astfel: 1 = 1() si 2 = 2(), iar = 1 2, in care am
notat cu * simbolul operatiei NATURAL JOIN.
Hibrida vazuta ca o combinatie intre fragmentarea orizontala si verticala sau invers. In
functie de ordinea in care fragmentarea a fost facuta refacerea relatiei initiale se face fie
printr-o operatie JOIN urmata de UNION, fie UNIONurmate de JOIN. Daca consideram
relatia Angajat in care am facut fragmentarea pe orizontala avand in relatia Ang1
angajatii cu un salariu mai mare de 1000 lei si in relatia Ang2 angajatii cu un salariu mai
mic de 1000 lei dupa care angajatii din Ang1 sunt impartiti dupa D_nr in doua relatii,
cei care apartin D_nr 2 sau 5 si restul, respectiv cei din Ang2 ca apartinand
departamentelor 6 sau 4, respective ceilalti se va obtine structura din fig. 3.1.

Indiferent de modul de fragmentare pentru proiectarea unei baze de date distribuite se au in

vedere urmatoarele:
Realizarea pe cat posibil a accesului la date local, adica plasarea fragmentelor pe nodurile
care utilizeaza datele si eventual utilizarea de copii ale fragmentelor daca aplicatia
permite;
Replicarea fragmentelor astfel incat sa se asigure o fiabilitate si o disponibilitate cat mai
mare;
Optimizarea utilizarii resurselor astfel incat incarcarea nodurilor sa fie cat mai
echilibrata;
Diminuarea pe cat posibil a costurilor comunicatiei prin minimizarea interogarilor ce
13

implica mai multe noduri. Realizarea dezideratului duce la cresterea redundantei prin
replicarea fragmentelor, dar are dezavantajul major al costurilor si complicatiilor privind
asigurarea consistentei datelor.
Indiferent de modul de fragmentare, baza de date initiala trebuie sa poata fi refacuta din
fragmente printr-un set de operatii. Fragmentarea unei baze de date trebuie sa satisfaca un set
minimal de reguli:
Completitudinea prin descompunerea in fragmente a unei relatii sa nu se piarda date.
Daca o relatie R se descompune in fragmentele R1, R2, , Rk, orice data care se gaseste
in relatia R trebuie sa poata fi gasita in fragmentele descompunerii;
Reconstructia Daca o relatie R este descompusa in fragmentele R1, R2, , Rk, exista un
operator (un set de operatii) prin care relatia R este reconstruita din fragmentele sale fara
a pierde nici o informatie;
Disjunctia acceasi informatii nu se gaseste in mai multe fragmente. Exceptie la
fragmenatarea verticala atributul cheie primara.

14

Implicatiile fragmentarii asupra executiei cererilor

Daca pentru distributia bazei de date aceasta se descompune in fragmente ce sunt
gazduite de nodurile componente ale sistemului, operatiile de recompunere se realizeaza functie
de modul in care relatia a fost fragmentata. In figura 4.1 se ilustreaza mai intai cazul fragmentarii
pe orizontala a relatiei R in fragmentele R1 si R2, dupa care R1 este fragmentat pe verticala in R11
si R12, iar R2 in R21 si R22. Pentru refacerea relatiei R se vor executa operatii de join obtinand R1
si R2 si prin reuniune se va obtine R. Al doilea arbore descrie procesul de reconstructie a relatiei
initiale.

Sa luam pentru exemplificare urmatoarea structura a tabelelor in baza de date centralizata:

Angajat(Nume, Ang_Id)
Lucreaza(Ang_Id,Ore, P_nr, Responsabil, ..)
Cererea prin care se doreste sa se obtina numele angajatilor care lucreaza la proiecte la care
responsabil este Popescu se va scrie:
SELECT A.Nume
FROM Angajat A, Lucreaza L
WHERE A.Ang_Id = L.Ang_Id and Responsabil =Popescu
In algebra relationala cererea implica o operatie Project efectuata asupra rezultatului operatiei
Select avand conditia Responsabil=Popescu din rezultatul operatiei Join intre Lucreaza si
Angajat, ca in exemplul:
PNume (SResponsabil = Popescu (Lucreaza >< Angajat)
Daca vom considera baza fragmentata orizontal in fragmentele Ang1, Ang2, Lucr1, Lucr2 ce
sunt stocate la locatiile N1, N2, N3, N4 si cererea este formulata de catre un utilizator aflat la
locatia 5 se obtine urmatoarea schema de executie (fig. 4.2):

15

Desigur ca, aceasta nu este singura varianta de executie a cererii. O alta varianta poate fi
reuniunea fragmentelor Ang1 si Ang2, dupa care join cu rezultatul operatiei SELECT avand
conditia responsabil=Popescu din rezultatul reuniunii fragmentelor Lucr1 si Lucr2, urmate
de o operatie PROJECT ce are in lista de atribute atributul Nume:
P Nume ((Ang1 U Ang2) >< (Sresponsabil = Popescu (Lucr1 U Lucr2)))
In general, o procesare a cererii urmareste executia dupa s schema similara cu cea ilustrata in
figura 4.3.

etapa extrem de importanta in executia cererilor distribuite este cea de decompozitie prin care
se procedeaza la: scrierea in forma normalizata (forma conjunctiva), analiza sintactica,
simplificarea (eliminarea predicatelor redondante), restructurare in forma algebrica facuta pe
baza schemei globale a bazei de date. Toate aspectele discutate pana in prezent nu au luat in
consideratie actualizarile datelor din baza de date. Atunci cand punem si problema actualizarii
este foarte importanta consistenta datelor si modul in care se face sincronizarea.

16

Problematica fragmentarii verticale a bazei de date

O baz de date distribuit ar trebui s apar utilizatorilor exact ca o baz de date
nedistribuit. Datele de pe fiecare calculator sunt gestionate independent de ctre SGBD, care
este responsabil pentru meninerea integritii lor.
Proiectarea bazelor de date distribuite reprezint o activitate complex, ce trebuie s ia n
considerare o mulime de factori, precum cerinele de accesare ale aplicaiilor, restriciile de
integritate definite la nivelul ntregii baze de date, configuraia nodurilor din sistem, precum i a
reelei. Natura distribuit a datelor implic, pe lng activitile care privesc proiectarea bazelor
de date centralizate, alte dou: fragmentarea i alocarea.
Motivele de fragmentare a unei relaii sunt: uzana, eficienta, paralelismul i securitatea.
Referitor la uzan, trebuie menionat c aplicaiile lucreaz mai bine cu viziuni , dect cu
relaii ntregi. Prin urmare, pentru distribuirea datelor, pare mai adecvat s se lucreze cu
submulimi ale relaiilor ca uniti de distribuire.
Eficiena este mai nalt datorit faptului c datele sunt stocate in apropierea locului unde
sunt cel mai frecvent utilizate, iar datele care nu sunt necesare pentru aplicaiile locale nu sunt
stocate.
Fragmentele fiind uniti de distribuire, tranzacia poate fi mprit n mai multe
subinterogri, care opereaz asupra fragmentelor. Aceasta are ca efect mrirea concurenei din
sistem, permind executarea n siguran a tranzaciilor care pot fi executate n paralel.
Securitatea se explic prin faptul c datele care nu sunt necesare pentru aplicaiile locale
nu sunt stocate i, in consecin, nu sunt disponibile pentru utilizatorii neautorizai.
Soluionarea problemei fragmentrii trebuie s se gseasc n strns legtur cu defragmentarea.
Defragmentarea complet sau parial este, uneori, necesar n cazul cnd performantele
aplicaiilor care utilizeaz date din mai multe fragmente, aflate pe staii diferite, care pot fi
sczute. n afar de aceasta, controlul integritii poate fi mai dificil, dac datele i dependenele
funcionale sunt fragmentate n staii diferite.

17

Un fragment vertical al unei relaii este format dintr-o mulime de atribute ale acesteia.
Prin fragmentarea vertical, se grupeaz laolalt atributele care sunt utilizate de ctre unele
aplicaii. Se definete cu ajutorul operaiei de proiecie din algebra relaional.
Fragmentarea, n general, precum i fragmentarea vertical, n particular, nu poate fi
efectuat la ntmplare. n decursul fragmentrii, este necesar s fie urmate trei reguli. La fel ca
i alte tipuri de fragmentri, cea vertical trebuie s respecte caracterul complet, care garanteaz
c nu au loc pierderi de date n decursul fragmentarii, adic fiecare atribut al relaiei iniiale
trebuie s fac parte cel puin dintr-un fragment.
n afar de aceasta, fragmentarea vertical trebuie s pstreze constrngerile de
integritate, fiind reconstruibil. Adic, trebuie s fie posibil s se defineasc o expresie
relaional, care va reconstrui relaia iniial din fragmente.
n ceea ce privete caracterul disjunct al fragmentrii, fragmentarea vertical reprezint o
excepie de la aceast regul, n care atributele cheii primare trebuie repetate pentru a permite
reconstrucia relaiei iniiale. Prin aceast regul, se garanteaz redundana minim a datelor.
Dar cnd baza de date proiectat trebuie s fie distribuit? Exist multe motive pentru care pot
impune proiectarea i folosirea unei baze de date distribuite. Cele mai importante dintre acestea
sunt urmtoarele:
Necesitatea de a plasa datele accesate frecvent n apropierea aplicaiilor-client, care
au nevoie de acestea i reduce astfel numrul de mesaje n reea i timpul de acces.
Dorina de a plasa datele variabile ntr-un singur loc, astfel, reducndu-se la minim problemele
asociate cu prezena mai multor exemplare actualizate ale datelor.
Necesitatea de a reduce impactul, cum ar fi cderea unui singur server, pe care se gsete
baza de date server.
Dac aceti factori sunt eseniali pentru funcionarea cu succes a aplicaiilor ce trebuie
elaborate pentru un domeniu de interes, bazele de date distribuite pot fi exact lucrul de care este
nevoie. Totui, proiectarea unei baze de date distribuite, ntreinerea acesteia i dup punerea n
funciune nu pot fi numite triviale.
Exist mai multe moduri de a organiza distribuirea datelor.
Hoffer i Severance au introdus conceptul de afinitate a atributelor. Acest concept
msoar frecvena de accesare simultan a unei perechi de atribute. Atributele, avnd afinitate
mare, sunt grupate mpreun folosind algoritmul BEA (Bond Energy Algorithm) elaborat de
McCormick i alii.
Hammer i Niamir au propus o euristic n cazul n care intrarea reprezint un set de
blocuri care corespunde fiecare unui atribut. Aceasta este partiia iniial. La fiecare pas, sunt
generate o serie de modificri ale partiiilor i apoi sunt depuse la un evaluator de cost. Dac una
din partiiile modificate devine partiia-candidat curent, iar procesul de cutare continu pn
cnd nu este posibil nici o modificare. Modificarea unei partiii poate fi obinut prin dou
moduri diferite: prin gruparea a dou blocuri sau prin extragerea unui atribut dintr-un bloc i
introducerea acestuia n altul.
n literatura de specialitate, sunt propui civa algoritmi de fragmentare vertical. Se
msoar afinitatea dintre perechi de atribute i se ncearc s se grupeze atributele mpreun
conform afinitii ntre perechi de atribute, cu ajutorul algoritmului BEA. Astfel, Navathe i alii
au extins lucrarea, aplicnd matricea de afinitate a atributelor i algoritmul BEA. Algoritmul de
fragmentare presupune dou etape. La prima etap, fragmentarea este obinut prin aplicarea
iterativ a unui algoritm de partiionare binar. La acest pas, nu este considerat factorul de cost. La
18

a doua etap, estimrile costului, care reflect o schimbare a mediului fizic, sunt incluse cu
scopul de a optimiza fragmentele iniiale. Complexitatea algoritmului este O(n2 log n) , unde n
este numrul de atribute.
Majoritatea algoritmilor utilizeaz matricea de afinitate a atributelor care este derivat din
matricea de utilizare a atributelor. Aceast matrice are atribute ca i coloane i tranzacii ca i
linii, iar frecvena accesrii tranzaciilor ca valori n matrice.
Cornell i Yu au propus un algoritm de partiionare vertical care minimizeaz numrul
de accesri ale discului. Algoritmul se bazeaz pe metodele de programare cu numere ntregi.
Partiionarea unei relaii necesit cunoaterea mai multor parametri n ceea ce privete relaia
(lungimea, selectivitatea i numrul de atribute), precum i tipurile de tranzacii i
comportamentul acestora (frecvena i atributele accesate).
Ceri i alii propun dou instrumente pentru fragmentarea vertical: "Divide" si
"Conquer". Instrumentul "Divide" realizeaz numai fragmentarea i alocarea datelor i pune n
aplicare algoritmul de partiionare propus. Instrumentul "Conquer", n afar de fragmentarea i
alocarea datelor, asigur optimizarea i alocarea operaiunilor.
Navathe i Ra au mbuntit lucrarea anterioar privind fragmentarea vertical prin
propunerea unui algoritm folosind o tehnic grafic. Matricea de afinitate a atributelor este
considerat ca un graf complet, unde nodurile reprezint atributele, iar ponderile muchiilor
reprezint valorile de afinitate. Algoritmul, prin adugarea succesiv a muchiilor, genereaz toate
fragmentele ntr-o singur iteraie, considernd un ciclu drept un fragment. Algoritmul are o
complexitate de O(n2 ) , unde n este numrul de atribute i are avantajul c nu utilizeaz o funcie
obiectiv.
Lin i alii extind rezultatele din despre partiionarea grafic. n calitate de date de
intrare ale algoritmului, figureaz graful de afinitate a atributelor. Autorii au propus cutarea unui
subgraf cu cel puin dou noduri pentru care valorile de afinitate sunt mai mari dect cele de la
fiecare muchie incident. Chakravarthy i alii au prezentat un evaluator al partiiei pentru a
msura calitatea unei fragmentri verticale prin utilizarea a dou costuri: costul de acces la
atributele locale irelevante (prezente pe staia de executare a tranzaciei, dar care nu sunt utilizate
de tranzacia n cauz) i costul de acces la atributele ndeprtate irelevante (care nu sunt
prezente pe staia de executare a tranzaciei, dar necesare pentru executarea acesteia).
Navathe i alii au propus o tehnic de fragmentare mixt. Datele de intrare ale
algoritmului sunt un tabel de afinitate a predicatelor i un tabel de afinitate a atributelor. Ma i
alii au folosit o matrice de frecven a utilizrii atributelor i un model de cost pentru
fragmentarea vertical.
Abdalla i alii au utilizat matricea de afinitate a atributelor pentru a genera grupuri
bazate pe valorile de afinitate.
Abuelyaman a propus un algoritm static, StatPart, pentru fragmentarea vertical. n
aceast lucrare, a fost furnizat o soluie pentru fragmentarea iniial a relaiilor ntr-o baz de
date distribuit. O matrice de reflexivitate, o matrice de simetrie i un modul de tranzitivitate,
generate n mod aleatoriu, au fost folosite pentru a produce fragmente verticale ale relaiilor i nu
pentru fragmentarea orizontal. Din pcate, nu poate fi justific ipoteza c tehnica propus va
produce o fragmentare bun.
Rezultatele diferiilor algoritmi sunt, deseori, diferite, chiar dac, pentru aceeai matrice
de afinitate a atributelor, se indic faptul c funciile obiective folosite sunt diferite. Majoritatea
19

algoritmilor de fragmentare vertical nu dispun de o funcie-obiectiv pentru evaluarea

corectitudinii partiiilor care se obin n urma aplicrii acelor algoritmi. De asemenea, nu exist
vreun criteriu comun sau o funcie-obiectiv care s evalueze rezultatele acestor algoritmi de
partiionare vertical.
Dac fragmentarea orizontal a schemei logice globale este o problem rezolvabil ntrun
timp acceptabil, atunci pentru fragmentarea vertical i mixt nu poate fi argumentat vreun
algoritm c se obine o soluie bun. Prin urmare, este necesar utilizarea tehnicilor inteligente.
Cu toate c metodele inteligenei artificiale, rareori, schimb natura problemei din punctul de
vedere al complexitii temporale i nu produc soluii optimale, acestea aduc, ntr-un timp
acceptabil, o soluie bun, aproape de cea optimal.
ndat ce schema logic global este fragmentat i alocat, apar problemele ce trebuie
soluionate la faza de proiectare logic pe fiecare staie aparte, care, de fapt, nu se deosebesc, n
principiu, de problemele de proiectare logic n sistemele centralizate sau cu arhitectur client
server.

Bibliografie
Abdalla H., AlFares M., Marir F. Vertical Partitioning for Database Design: A
Grouping Algorithm. In Proc. International Conference on Software
Engineering and Data Engineering (SEDE), 2007
Abuelyaman E. S. An optimized scheme for vertical partitioning of a
distributed database. Int. Journal of Computer Science & Network
Security, V.8, N.1, 2008
Ceri S., Pernici S., Weiderhold G. Optimization Problems and Solution
Methods in the Design of Data distribution. Information Sciences, V.14
N.3, 1989
Chakravarthy S., Muthuraj J., Varadarajan R., Navathe S. B. An objective
function for vertically partitioning relations in distributed databases
and its analysis. Distributed and Parallel Databases, Springer, V.2, N.2,
1994
Cotelea V. Principii de proiectare conceptual interactiv a bazelor de
date. Cibernetica i informatica economic. A.S.E., Chiinu, 1996
Lin X., Orlowska M., Zhang Y. A Graph Based Cluster Approach for Vertical
Partitioning in Database Design. Data and Knowlegde Engineering,
V.11, N2, 1993
Ma H. Schewe K. D, Kirchberg M. A heuristic approach to vertical
fragmentation incorporating query information. In Proc. 7th
International Baltic Conference on Databases and Information Systems
(DB&IS), 2006
Navathe S. B., Ra M. Vertical partitioning for database design: A graphical
Algorithm. ACM SIGMOD Record, V.14, N.4, 1989
20

 Navathe S., Karlapalem K., Ra M. A mixed fragmentation methodology for

initial distributed database design. Journal of Computer and Software
Engineering, V.3, N.4, 1995
zsu M.T., Valduriez P. Principles of Distributed Database Systems, ed.
Dorling Kindersley (india) Pvt Ltd, 2006
Cotelea V. Unele aspecte de proiectare a bazelor de date distribuite.
A.S.E., Chiinu, 2012
Crstoiu D. Sisteme de baze de date distribuite, Conspress, Bucureti, 2013

21

Concluzii
Astzi, multe aplicaii cer ca bazele de date s evolueze independent
de intervenia utilizatorului, ci ca rspuns la un eveniment sau la o situaie
determinat. n sistemele de gestiune a bazelor de date tradiionale (pasive),
evoluia bazei de date se programeaz n codul aplicaiilor, n timp ce, n
sistemele de gestiune a bazelor de date active, aceast evoluie este
autonom i se definete n schema bazei de date. Astfel, schemele bazelor
de date trebuie proiectate cu caracteristici care pot evolua, n mod autonom,
n funcie de influena mediului constituit din aplicaii i interaciuni ale
utilizatorilor. Prin sistemele de baze de date active,
se constituie un nou nivel de independen a datelor: independena
cunotinelor.
Din aceast perspectiv, provocarea pentru cercettorii din domeniul
bazelor de date const n a identifica i a unifica cadrul teoretic, care ar
integra diferite faze ale proiectrii bazelor de date ntr-un mod coerent.
Privitor la soluionarea problemei fragmentrii, se poate constata c:
majoritatea algoritmilor cunoscui de fragmentare vertical nu dispun de o
funcie-obiectiv pentru evaluarea
corectitudinii partiiilor; nu exist vreun criteriu comun sau o funcie-obiectiv,
care s evalueze
rezultatele acestor algoritmi de partiionare; rezultatul diferiilor algoritmi
sunt, deseori, diferite,
chiar dac pentru aceeai matrice de afinitate a atributelor se indic faptul
c funciile-obiectiv
folosite sunt diferite; nu pentru toi algoritmii poate fi justific ipoteza c
tehnica propus va produce o fragmentare bun. innd cont de faptul c, n
caz general, problema fragmentrii verticale este una exponenial, sunt
necesare cercetri orientate spre utilizarea tehnicilor inteligente i anume
algoritmii genetici.
Aceste tehnici trebuie s ofere soluii acceptabile, aproape de cele
optimale, n timp rapid.
Cu acest scop sunt necesare investigaii privind reprezentarea indivizilor i
crearea populaiei
iniiale, determinarea gradului de adaptare a indivizilor, aplicarea
operatorilor i parametrilor
genetici i regulile de utilizare a acestora. Sunt necesare, de asemenea,
experimente asupra unor
exemple mici, pentru care pot fi calculate toate variantele posibile de
fragmentare, i s se arate c algoritmul produce soluii care se situeaz
printre cele care respect pragul de vigilen.

22

Cuprins

Introducere..................................................................................................................... 2
Reguli date..................................................................................................................... 3
Avantaje i dezavantaje baze de date distribuite........................................................................9
Proiectarea unei baze de date relationale distribuite.................................................................11
Fragmentarea................................................................................................................ 12
Implicatiile fragmentarii asupra executiei cererilor...............................................................15
Problematica fragmentarii verticale a bazei de date..............................................................17
Bibliografie............................................................................................................... 20
Concluzii................................................................................................................. 21

23