Notiuni introductive in baze de date distribuite

Notiuni introductive in baze de date distribuite

Intr-un sistem de baze de date centralizat, toate componentele sistemului rezida pe un singur computer sau site. Prin componente intelegem: date, software-ul aferent sistemului de gestiune a bazelor de date, periferice secundare asociate: discuri, benzi pentru memorarea si salvarea bazei de date. Baza de date centralizata poate fi accesata de la distanta. In ultimii ani, o data cu distributia componentelor in mai multe locatii si interconectarea prin retele, au aparut si sistemele de baze de date distribuite, prescurtat SBDD si sistemele de gestiune a bazelor de date distribuite, prescurtat SGBDD.

Concepte de baza

O baza de date distribuita este o colectie de date care apartin logic aceluiasi sistem, dar fizic sunt raspandite in nodurile unei retele de calculatoare.

Se precizeaza in continuare cateva avantaje ale sistemelor de gestiune a bazelor de date distribuite:

1. Natura distribuita a anumitor aplicatii de BD:

De exemplu, o companie poate avea locatii in diferite orase, sau o banca poate avea mai multe filiale. Este natural pentru bazele de date utilizate in astfel de aplicatii sa fie distribuite in aceste locatii. Pot exista utilizatori locali care acceseaza numai datele dintr-o locatie si utilizatori globali, ca de exemplu conducatorii companiei care pot cere ocazional accesul la date memorate in diferite locatii. Datele din fiecare locatie descriu mini universul" din acea locatie.

2. Cresterea sigurantei si disponibilitatii

Atunci cand datele sunt distribuite pe mai multe site-uri, unul poate sa cada, dar celelalte sunt

in continuare operabile. Numai datele si softul care exista pe site-ul cazut nu pot fi accesate. Este imbunatatita atat siguranta, cat si disponibilitatea. Aceste proprietati sunt imbunatatite printr-o replicare judicioasa a datelor si software-ului pe mai multe site-uri.

3. Este permisa partajarea datelor si un control local

In anumite SGBDD este posibila controlarea datelor si a software-ului local la fiecare site, iar anumite date pot fi accesate de la distanta. Este permisa controlarea partajarii prin intermediul sistemului distribuit.

4. Performanta crescuta

Cand o baza de date este distribuita in mai multe noduri, practic in fiecare nod exista o baza de date mai mica. Ca urmare, interogarile locale si tranzactiile care acceseaza datele de la un site local au o performanta mai buna pentru ca baza de date este mai mica. De asemenea, in fiecare nod exista in general un numar mai mic de tranzactii care se executa decat cele care sunt executate pe o singura baza de date centralizata. Tranzactiile care implica accesul la mai multe site-uri, se pot executa in paralel, reducandu-se timpul de raspuns.

Distributia implica o complexitate crescuta a sistemului de gestiune a bazelor de date, ca atare el trebuie sa aiba niste functii suplimentare:

posibilitatea de a accesa site-uri la distanta si de a transmite interogari si date intre noduri prin intermediul retelei;

posibilitatea de a gestiona distributia si replicarea datelor in catalogul SGBDD;

posibilitatea de a stabili strategiile de executie a interogarilor si tranzactiilor care acceseaza date din mai multe noduri;

posibilitatea de a decide ce copie dintre datele replicate sa acceseze;

posibilitatea de a mentine consistenta copiilor datelor replicate;

posibilitatea de refacere la caderea unui nod individual sau a unei legaturi.

La nivel fizic, factorii principali care deosebesc un sistem de baze de date distribuit de

unul centralizat sunt:

exista mai multe computere, numite site-uri sau noduri;

nodurile trebuie conectate printr-o retea. Nodurile pot fi apropiate fizic (in aceeasi cladire sau cladiri apropiate) si se conecteaza printr-o retea locala (cabluri), sau pot fi la distante mari si conectate printr-o retea corespunzatoare (linii telefonice, satelit). Retelele pot avea topologii diferite, pot fi de tipuri diferite, dar pot influenta semnificativ performanta si astfel strategiile de procesare a intrarilor distribuite si proiectarea bazei de date distribuite.

Fragmentarea datelor

Unitatile logice in care este sparta baza de date si care se memoreaza in  diferite noduri se

numesc fragmente. In sistemele de baze de date distribuite trebuie sa se decida: in ce noduri se memoreaza portiuni din baza de date. Se presupune ca inca nu exista replicarea datelor, adica fiecare portiune din baza de date este memorata intr-un singur nod.

In cele ce urmeaza ne referim la baze de date relationale, desi concepte similare se aplica si la alte modele ale datelor.

Trebuie determinate unitatile logice ale bazei de date care vor fi distribuite. Cele mai simple unitati logice sunt chiar relatiile, deci, relatia ca un intreg poate fi memorata intr-un anume mod. In unele cazuri, insa, relatia poate fi impartita in unitati logice mai mici in vederea distributiei. Sa presupunem baza de date pentru o companie si existenta a trei noduri, cate unul in cele 3 departamente ale companiei. Se poate dori sa se memoreze in fiecare nod informatia din baza de date corespunzatoare numai nodului respectiv, caz in care se aplica tehnica de fragmentare orizontala.

Un fragment orizontal a unei relatii este un subset de tuple ale relatiei. Tuplele din fragmentul orizontal sunt specificate printr-o conditie peste unul sau mai multe atribute ale relatiei. De obicei, se utilizeaza un singur atribut. Daca de exemplu exista 3 departamente 1,5,4, relatia Angajat poate fi impartita in 3 fragmente orizontale. La fel si relatia Proiecte, fiecare fragment orizontal combinand proiectele controlate la fiecare departament. Aceste fragmente pot fi apoi asignate la diferite noduri din sistemul distribuit.

Fragmentare verticala

Un fragment vertical contine numai anumite atribute ale relatiei. De exemplu, relatia Angajat poate fi impartita in 2 fragmente verticale: primul contine informatii personale (nume, data nastere, adresa, sex) si al doilea fragment informatii legate de serviciu (cod numeric personal, codul numeric personal al superiorului, numarul departamentului in care lucreaza). Aceasta fragmentare verticala nu este chiar cea mai indicata, pentru ca daca cele 2 fragmente sunt memorate separat, nu putem reuni informatia, pentru ca nu exista un atribut comun. Deci, este necesar sa includem atributul cheie primara in ambele fragmente verticale, astfel incat relatia sa poata fi reconstruita din fragmente.

Fiecare fragmentare orizontala pe relatie R poate fi definita prin .

O multime de fragmente orizontale definite de conditiile care cuprinde toate tuplele din R si fiecare tuplu din R satisface se numeste fragmentare orizontala completa a lui R. In multe cazuri fragmentarea completa este si disjuncta, adica nu exista nici un tuplu care sa satisfaca .

In cele 2 exemple anterioare, fragmentarea orizontala a relatiilor Angajat si Proiecte este completa si disjuncta. Pentru a reconstrui relatia R din fragmentarea orizontala completa trebuie sa aplicam operatia de UNION asupra fragmentelor.

O fragmentare verticala pe relatia R poate fi specificata prin . Un set de fragmente verticale avand listele de proiectie L1, L2,. Ln care includ toate atributele din R si partajeaza numai cheia primara din R se numeste fragmentare verticala completa.

Pentru a recontrui relatia R dintr-o fragmentare verticala completa se poate aplica OUTER UNION sau FULL OUTER JOIN.

Exemplu: Fragmentare verticala completa a relatiei Angajat.

L₁=

L₂=

Fragmentarea mixta - rezulta prin combinarea celor 2 tipuri de fragmentari. In cazul nostru rezulta 6 fragmente.

In general, un fragment al relatiei R poate fi specificat printr-o combinatie de operatii Selectie - Proiectie. . Daca C=TRUE si L ≠ Atributele (R) avem un fragment vertical, iar daca C ≠ TRUE si L = Atributele (R) avem un fragment orizontal. Daca C ≠ TRUE si L ≠ Atributele (R) avem un fragment mixt. Si relatia poate fi considerata un fragment cu C=TRUE si L = Atributele (R).

Schema de fragmentare a unei baze de date este data de definitia unui set de fragmente care include toate atributele si tuplele din baza de date si satisface conditia ca intreaga baza de date poate fi reconstruita din fragmente prin aplicarea unei secvente de operatii OUTER UNION (sau FULL OUTER JOIN) si UNION.

Replicarea si alocarea datelor

Replicarea este utila in cresterea disponibilitatii datelor.

Cazul extrem este acela cand intreaga baza de date este replicata in fiecare nod al sistemului distribuit, creandu-se o baza de date distribuita total replicata. Sistemul este functional atat timp cat macar un nod este functional. Este imbunatatita si performanta interogarilor globale, pentru ca rezultatul poate fi obtinut de la orice site, daca exista un modul server.

Dezavantajul replicarii totale este acela ca operatiile de actualizare date sunt drastic incetinite, pentru ca actualizarea trebuie facuta pe fiecare copie a bazei de date, pentru a pastra copiile constituite. De asemenea, tehnicile de refacere si control al concurentei sunt mai costisitoare.

Cealalta extrema este aceea cand nu exista deloc replicare, adica, fiecare fragment este stocat intr-un singur nod. In acest caz, fragmentele trebuie sa fie disjuncte, cu exceptia cheii primare. In fragmentarea verticala sau mixta se mai numeste si alocare neredundanta.

Intre aceste doua extreme, exista o serie de replicari partiale ale datelor, unele fragmente pot fi replicate, altele nu. Numarul de copii pentru fiecare fragment poate merge de la 1 pana la un numar total de noduri din sistemul distribuit.

Descrierea nodului de replicare a fragmentelor se numeste schema de replicare.

Fiecare fragment sau copie a sa trebuie asignat unui nod din sistemul distribuit, proces numit distributia sau alocarea datelor.

Alegerea nodurilor si gradul de replicare depind de doi factori urmariti:

performanta si disponibilitatea sistemului

tipurile si frecventele tranzactiilor executate la fiecare nod

De exemplu, daca se cere disponibilitate mare iar tranzactiile pot fi executate de la fiecare nod si cele mai multe sunt interogari, atunci o baza de date complet replicata poate fi o buna solutie. Daca anumite tranzactii care acceseaza o anume parte din baza de date se executa in special de la un anumit nod, setul respectiv de fragmente poate fi alocat numai la acel site. Daca se executa multe actualizari, este bine sa se limiteze replicarea.

Tipuri de sisteme de baze de date distribuite

Clasificarea se face in functie de mai multi factori:

1. Gradul de omogenitate al software-ului SGBDD

Daca toate serverele (sau SGBD locale) utilizeaza acelasi software si toti clientii utilizeaza software identic, SGBDD este omogen, astfel este heterogen.

2. Gradul de autonomie locala - legat de gradul de omogenitate.

Daca accesul la SGBDD trebuie obtinut prin intermediul unui client, atunci sistemul nu are autonomie locala. Daca este insa posibil accesul direct prin intermediul unor tranzactii locale la un server, atunci sistemul are o oarecare autonomie locala.

La o extrema a autonomiei, exista un SGBDD care arata, pentru utilizator, ca un SGBD centralizat. Exista o singura schema conceptuala, accesul la sistem este obtinut prin intermediul unui client, deci nu exista autonomie locala. La cealalta extrema intalnim un tip de SGBDD numit federativ sau sistem multibaze de date in care fiecare server este un SGBD independent si autonom care are utilizatorii locali proprii, tranzactii locale si un administrator de baze de date si deci un grad mare de autonomie locala.

Fiecare server poate autoriza accesul la o anumita portiune din baza sa de date prin specificarea asa numitei scheme de export, care specifica ce parte din baza de date poate fi accesata de utilizatorii nelocali.

Un sistem federativ este un sistem hibrid intre sistemele distribuite si centralizate; este centralizat pentru utilizatorii autonomi locali si distribuit pentru utilizatorii globali.

Intr-un sistem multi-baze de date heterogen, un server poate fi un SGBD relational, altul retea, s.a.m.d., deci este necesar un limbaj canonic care sa includa translatoare care traduca interogarile din limbajul canonic in limbajul fiecarui server.

3. Gradul de trasparenta a distributiei sau gradul de integrare a schemei

Daca utilizatorul vede o singura schema integrala fara nici o informatie despre fragmentare, replicare, distributie, se spune ca SGBDD are un inalt grad de transparenta a distributiei, in caz contrar nu exista transparenta distributiei. In acest ultim caz, utilizatorul trebuie sa se refere la un anume fragment de la un anume nod, atunci cand specifica interogarea, prin adaugarea numelui nodului inainte de numele relatiei sau fragmentului. Utilizatorul trebuie sa specifice intr-un mod neambiguu numele relatiei sau fragmentului. Problema este si mai dificila in sistemele multi-baze de date unde fiecare server a fost dezvoltat independent si pot aparea conflicte in denumiri. In cazul sistemelor care ofera o schema integrata utilizatorul dispune de o schema fara ambiguitati. Sistemul memoreaza toate corespondentele intre schema integrata si obiectele distribuite in catalogul distributiei (distribution catalog).

In continuare se prezinta un exemplu de fragmentare si alocare a datelor. Presupunem ca exista doua relatii Angajat si Departamente aflate in legatura 1:m. In relatia Angajat campul NRD este cheie externa si reprezinta numarul departamentului in care lucreaza angajatul.

Presupunem, de asemenea, ca in companie exista trei departamente 1, 2 si 3, la se doreste alocarea datelor legate de departamentul respectiv. De asemenea, presupunem ca in cadrul fiecarui departament exista doua servicii, unul de personal si celalalt de salarizare. Serviciul personal este interesat de anumite date ale angajatilor, adica, CNP, NUME, DATA_NAST, ADRESA, SEX si NRD. Serviciul salarizare este interesat numai de salariul angajatilor si sporul de vechime (SALARIU, SPOR_VECH).

Angajat

Departamente

Se propune in primul rand o fragmentare pe orizontala a relatiilor Angajat si Departamente, in 3 fragmente orizontale care vor cuprinde din fiecare relatie numai inregistrarile corespunzatoare departamentului respectiv.

A1

CNP	NUME	DATA_ NAST	ADRESA	SEX	SALARIU	SPOR_VECH	NRD
	Popa I.		Craiova	M
	Ana I.		Craiova	M
	Vasile C.		Craiova	F

A2

A3

D1

D2

D3

Daca am presupus ca la nivelul fiecarui departament exista 2 servicii Personal si Salarizare interesate de anumite date ale angajatului, atunci se propune si o fragmentare pe verticala a relatiilor A1, A2 si A3, rezultand 6 fragmente. Fragmentele A1p, A2p, A3p vor fi alocate la compartimentele de personal din fiecare departament, iar A1s,A2s si A3s la compartimentele de salarizare din fiecare departament. Se observa ca fragmentele verticale de la serviciul personal si salarizare din fiecare departament contin cheia primara CNP.

A1p

A2p

A3p

A1s

A2s

A3s

Ca urmare, alocarea fragmentelor rezultate se va face astfel:

La departamentul 1, compartimentul Personal se aloca fragmentele A1p si D1.

La departamentul 1, compartimentul Salarizare se aloca fragmentele A1s si D1.

La departamentul 2, compartimentul Personal se aloca fragmentele A2p si D2.

La departamentul 2, compartimentul Salarizare se aloca fragmentele A2s si D2.

La departamentul 3, compartimentul Personal se aloca fragmentele A3p si D3.

La departamentul 3, compartimentul Salarizare se aloca fragmentele A3s si D3.

Se recomanda, de asemenea, ca la conducerea societatii, de exemplu, sa fie alocate relatiile Angajat si Departamente in intregime, pentru ca aceasta sa aiba acces la toate informatiile din societate si pentru a creste siguranta datelor. In conditiile in care unul dintre noduri, nu functioneaza, accesul la datele nodului respectiv sa fie directionat catre aceasta copie.