PROIECTAREA BAZELOR DE DATE DISTRIBUITE

PROIECTAREA BAZELOR DE DATE DISTRIBUITE

Proiectarea bazelor de date este una dintre cele mai importante sarcini ale creatorului, utilizatorului si administratorului bazei de date. Aceasta implica luarea de decizii in ceea ce priveste plasarea datelor si programelor intr-o retea de calculatoare si posibilitatea proiectarii retelei insasi. In cazul SGBDD, distributia aplicatiilor presupune: distribuirea software-ului SGBD-urilor si distribuirea programelor care ruleaza pe acest software.

Este posibil ca reteaua sa fie proiectata deja sau va fi proiectata in functie de deciziile luate in legatura cu proiectarea BD.

Problemele legate de modelarea BDD, pe care le vom discuta in continuare scot in relief obiectivul principal al BDD si anume integrarea, nu centralizarea.

Exista doua strategii majore de modelare a BDD: modelarea top-down si modelarea bottom-up. Aceste doua alternative de modelare sunt diferite, dupa cum ne sugereaza si numele lor. Dar, in modelare trebuie aplicate ambele strategii.

1. MODELAREA TOP-DOWN

In cazul modelarii top-down sistemul se organizeaza ca si cand acesta ar fi o singura unitate. Fiecare nod al retelei coopereaza pentru executarea partilor unei singure probleme si ii este asociat un set de task-uri date, iar dezvoltarea aplicatiei se face intr-o maniera similara cu aplicatiile nedistribuite.

Pentru a intelege mai bine aceasta strategie de modelare, exemplificam printr-un model standard (fig. 1.).

Activitatea de proiectare incepe cu analiza cerintelor care definesc mediul de lucru al sistemului de gestiune. Aceste cerinte sunt ale potentialilor utilizatori ai bazelor de date si ele solicita cererile de acces si de prelucrare a informatiilor. Prin studiul cerintelor se poate specifica pana unde va    ajunge sistemul final. Acest lucru este posibil prin respectarea obiectivelor unui SGBDD.

Analiza cerintelor reprezinta intrarea pentru alte doua activitati paralele: proiectarea vizualizarii si proiectarea conceptuala. Prima activitate se refera la definirea interfetelor pentru utilizatori. Prin intermediul celei de a doua activitati este examinata baza de date, sunt determinate tipurile entitatilor si legaturile dintre acestea. Acest proces de proiectare conceptuala poate fi impartit in doua activitati: analiza entitatilor si analiza functiilor. Analiza entitatilor se ocupa de determinarea entitatilor, a atributelor lor si a relatiilor dintre acestea. Analiza functiilor presupune determinarea functiilor fundamentale implicate in procesul modelarii.

		Fig.1. : Modelarea top-down
			Proiectarea fizica

Intre proiectarea conceptuala si proiectarea vizualizarii exista o legatura stransa. Proiectarea conceptuala poate fi considerata ca parte integranta a proiectarii interfetelor utilizator. Aceasta integrare este posibila deoarece interfata utilizator trebuie sa constituie un suport nu numai pentru aplicatiile existente ci si pentru cele viitoare.

Integrarea interfetelor trebuie folosita pentru a asigura faptul ca cererile asupra entitatilor si relatiilor sunt acoperite in schema conceptuala. In cele doua tipuri de proiectare utilizatorul trebuie sa specifice entitatile ce ruleaza pe BD. In proiectarea conceptuala primul pas il reprezinta definirea schemei conceptuale globale (SCG). Din acest punct de vedere, procesul de proiectare este identic cu cel specific bazelor de date centralizate.

In cadrul proiectarii distribuite sunt considerate ca puncte de plecare schemele conceptuale globale si informatiile structurilor de acces, ca rezultat al proiectarii vizualizarii. Obiectivul major al acestei etape este proiectarea schemelor conceptuale locale (SCL) prin distribuirea entitatilor pe statiile sistemului distribuit. Fiecare entitate poate fi tratata ca o unitate a acestei distributii, astfel utilizandu-se modelul relational. Se foloseste impartirea relatiilor in subrelatii numite fragmente, care apoi vor fi distribuite. Din acest punct de vedere activitatea de proiectare distribuita consta in doua etape: fragmentarea si alocarea.

Ultimul pas in procesul de proiectare este proiectarea fizica. Intrarile la acest proiect sunt schemele conceptuale locale si informatiile structurilor de acces la fragmente.

Procesul de proiectare si dezvoltarea activitatilor de orice tip sunt procese care se modifica in timp. Ele necesita sisteme de monitorizare constanta, aceasta operatiune fiind considerata una majora in cadrul acestui proces. Se monitorizeaza nu numai comportamentul implementarii BD-ului ci si al vizualizarilor utilizatorului. Rezultatul este o forma de feedback, care se poate realiza prin intoarcerea la unul din pasii prezentati anterior in cadrul procesului de proiectare.

2. MODELAREA BUTTOM-UP

In modelarea buttom-up sistemul este dezvoltat prin interconectarea nodurilor care au fost initial independente. Sistemele distribuite formate astfel pot atinge nivele ridicate de interconectare. Pe langa problemele unui sistem uni-server, modelarea bazelor de date distribuite trebuie sa ia in considerare:

-numarul de utilizatori;

-frecventa de acces la informatii;

-complexitatea BD-urilor accesate;

si alte probleme specifice, cum ar fi: utilizarea BDD-urilor, frecventa utilizarii join-urilor, fragmentarea datelor pe orizontala sau verticala.

Modelarea buttom-up este folosita in sisteme de baze de date al caror specific consta in existenta mai multor BD, iar tehnica modelarii implica integrarea acestor BD intr-una singura.

Punctul de plecare in acest tip de modelare il constituie schemele conceptuale locale. Procesul consta in integrarea schemelor locale in schema conceptuala globala. Acest tip de proiectare a fost initial folosit in cazul BD-urilor eterogene. Cercetari importante au condus la folosirea lui in contextul BDD.

Cele mai importante etape in procesul de proiectare sunt: fragmentarea si alocarea. Vor aparea evident probleme legate de raspunsul la intrebari de tipul: de ce trebuie sa fragmentam, este bine sa fragmentam sau cat trebuie sa fragmentam ? De asemenea, cum trebuie sa alocam sau de ce informatii avem nevoie in fragmentare si alocare ?

FRAGMENTAREA

Incepem prezentarea    acestei probleme prin ilustrarea unor motive prin care se justifica folosirea fragmentarii. De exemplu, vizualizarile sunt de obicei submultimi ale unor relatii. De aceea, accesul la aplicatii se face nu prin intreaga relatie ci prin submultimi ale acesteia. Astfel, este natural sa consideram submultimile de relatii ca unitati de distributie. Daca aplicatiile care au view-uri se gasesc pe mai multe statii, trebuiesc urmate doua alternative: fie intreaga relatie reprezinta unitatea de distributie, fie relatia nu este replicata si este stocata pe o singura statie sau relatia este replicata    pe fiecare sau pe o parte din statiile pe care se gaseste aplicatia. Daca se alege prima alternativa, rezultatul final va fi un volum mare de date de acces. A doua alternativa se confrunta cu probleme in executia reactualizarilor. Nu este bine sa fie folosita atunci cand stocarea de date este limitata.

Impartirea unei relatii in mai multe fragmente, tratate ca niste unitati de distributie, permite executarea concurenta a unui numar mare de subcereri.

Exista si dezavantaje ale fragmentarii. De exemplu, putem mentiona problemele care apar in cazul aplicatiilor care au view-uri pe mai multe fragmente. Acestea duc la micsorarea performantei aplicatiilor ce ruleaza pe BD. Ar fi necesara regasirea unor date din tabele, prin intermediul uniunii sau join-ului, dar ar fi costisitor. Un alt dezavantaj este legat de controlul semantic al datelor, in special de verificarea integritatii.

Un fragment al unei relatii, existent intr-un anumit nod, poate fi interpretat ca o BD centralizata care poate fi administrata local. Fragmentarea BD reprezinta o decizie importanta care poate afecta executia cererilor.

Gradele fragmentarii trec de la o extrema si anume nefragmentarea relatiilor, la alta, adica fragmentarea la nivelul tuplurilor sau la nivelul atributelor individuale. Trebuie gasit un nivel de fragmentare care sa constituie un compromis intre cele doua extreme. Acestea se pot defini doar in concordanta cu aplicatiile care ruleaza pe BD. Aplicatiile pot fi caracterizate prin intermediul unor parametri. Fragmentele pot fi identificate in functie de valorile acestor parametri. Exista doua alternative de fragmentare: orizontala si verticala.

Exemplu: Pentru evidentierea acestui exemplu (dar si pentru exemplele urmatoare) consider o agentie de moda care are sedii in mai multe orase ale tarii.

Pentru gestiunea datelor in agentie, avem nevoie de informatii despre designerii din acea agentie.

DESIGNER( Cod-designer, nume, vechime, casa), unde:

Cod-designer = cheia primara ce identifica in mod unic entitatea DESIGNER;

nume = numele si prenumele designerilor ;

vechime = perioada de timp de cand a inceput sa lucreze in acest domeniu;

casa = casa de moda in care lucreaza ca designer;

Relatia de mai sus o putem reprezenta in felul urmator:

DESIGNER

Vom realiza fragmentarea orizontala a acestei relatii in doua subrelatii. Prima subrelatie contine informatii despre designerii care au o vechime mai mica de 6 ani (notata DESIGNER) iar cea de a doua contine informatii despre cei cu vechimea mai mare de 6 ani (DESIGNER).

DESIGNER

DESIGNER

Exemplu: Prezentam fragmentarea pe verticala a aceleiasi relatii. DESIGNER₁ va contine cheia primara a relatiei si informatii despre nume si vechime, iar DESIGNER₂ va contine cheia primara si informatii despre casa de moda.

DESIGNER

DESIGNER

In cazul fragmentarii verticale este necesara introducerea cheii primare in fiecare fragment obtinut pentru a putea fi posibila efectuarea operatiei de reconstructie a relatiei initiale.

Procesarea distribuita presupune implicarea mai multor factori si anume: organizarea logica a BD, locul in care ruleaza aplicatiile specifice BD-ului, proprietatile sistemului de calculatoare. Din aceasta cauza, o problema de distributie este destul de complicat de formulat.

Informatia de care avem nevoie in proiectarea distribuita, poate fi impartita in patru categorii: informatii despre BD, informatii despre aplicatii, informatii despre reteaua de comunicatie si informatii despre sistem.

ALTERNATIVELE ALOCARII

Cea de a doua problema importanta din cadrul modelarii, este alocarea. Sa presupunem ca BD a fost fragmentata. Trebuie decisa o modalitate de alocare a fragmentelor pe diferitele statii ale unei retele. Cand datele sunt alocate, pot fi si replicate sau mentinute intr-o singura copie. Daca exista mai multe copii ale datelor, este posibil ca o anumita copie sa fie accesibila, chiar daca apar unele probleme legate de sistem.

O BD partitionata, este o BD nereplicata care contine fragmente in fiecare statie din retea. Fiecare fragment apare intr-o singura copie.

Exista doua tipuri de replicare: replicare totala -in acest caz baza de date se gaseste in intregime in fiecare statie si replicare partiala-copii ale fragmentelor se gasesc pe statii diferite. In replicarea partiala, numarul de copii ale unui fragment constituie o intrare in algoritmii de alocare si variabilele de decizie, ale caror valori sunt determinate prin algoritm .In figura de mai jos, sunt comparate aceste trei alternative de replicare, respectandu-se diferitele functii ce intervin in cadrul SBDD.