38
Ministerul Educaţiei al Republicii Moldova Universitatea Tehnica a Moldovei Facultatea: Calculatoare Informatica si Microelectronica Catedra: Automatica și Tehnologii Informaţionale Lucrare de curs Disciplina: Baze de date și cunoștinţe Tema: Fragmentarea bazelor de date distribuite A efectuat: st. gr. SI- 121 Serioghina Valeria 1

Fragmentarea Bazelor de Date Distribuite

Embed Size (px)

DESCRIPTION

Proiect de curs

Citation preview

Ministerul Educaiei al Republicii Moldova

Universitatea Tehnica a MoldoveiFacultatea: Calculatoare Informatica si Microelectronica Catedra: Automatica i Tehnologii Informaionale

Lucrare de cursDisciplina: Baze de date i cunotineTema: Fragmentarea bazelor de date distribuite

A efectuat: st. gr. SI-121Serioghina Valeria

A verificat: Saranciuc Dorian

Chiinu 2015

IntroducereO 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 datedistribuite, ca efect al descentralizarii, integritatea datelor, redundanta minima si indeplinireaproprietatilor 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 suntdistribuite fizic pe nodurile unei retele de calculatoare. Gestiunea unei baze de date distribuiteeste realizata de un sistem de gestiune al bazei de date distribuite (SGBDD), capabil sa operezecu baza de date similar cu un SGBD centralizat, fara ca utilizatorii sa cunoasca unde suntlocalizate datele pe care le acceseaza. Se mai spune ca baza de date este constituita din insule deinformatii distribuite.

Reguli datePentru ca un sistem de gestiune al bazei de date sa fie cu adevarat distribuit, el ar trebui sarespecte in totalitate cele 12 reguli introduse de C.J. Date in 1987 [Dat87]. Putem afirma caaceste reguli sintetizeaza motivele principale pentru care este necesara distribuirea datelor pe maimulte calculatoare intr-o retea si constituie in acelasi timp si obiectivele principale ale unuiSGBDD. Cele 12 reguli formulate de Date se constituie ca o metrica de evaluarea a bazelor dedate distribuite, cu toate ca nu se cunoaste inca nici un produs care sa satisfaca toate acestecerinte. Sintetizate cele 12 reguli sunt:Autonomia locala. Un sistem de baze de date distribuit trebuie sa ofere pentru fiecarelocatie implicata un grad inalt al autonomiei locale. Ca urmare, fiecare locatie trebuiesa-si gestioneze propriile date si sa ofere functionalitate independent de celelaltelocatii. Chiar daca uneori, pentru o completa functionare, o locatie are nevoie dedatele pastrate la alte locatii, nu inseamna ca propria functionare este conditionata deacele locatii. Existenta dependentelor functionale stranse duce la propagarea conditionalitatilor astfel incat intregul sistem devine inoperabil. In realitate, acestobiectiv nu este indeplinit 100%. Uzual, intre locatii exista o anumita ierarhie si intr-ooarecare masura conditioneaza principiul autonomiei. De regula, sunt asigurate localsecuritatea, functiile de backup si refacre.Conceptul este totusi putin relaxat chiar deautor prin formularea: autonomia locatiilor trebuie respectata in cea mai maremasura posibila.Absenta unei dependente de o locatie centrala.Este de dorit ca toate locatiile sa aibaaceleasi capabilitati. Chiar daca intre locatii exista o anumita ierarhie, nu trebuieexagerat. Intr-un sistem distribuit nu trebuie sa existe o locatie raspunzatoare intotalitate de realizarea unei anumite functii sau activitati. Nu putem avea un nod incare sa se realizeze controlul centralizat al tranzactiilor, gestiunea centralizata ainterogarilor, gestionrea accesului concurent pentru intreg sistemul, rezolvareaproblemelor de concurenta etc. Absenta dependentei de locatia centrala poate firezumata prin inexistenta unui singur dictionar de date. Dependenta totala fata de unanumit nod este nedorita pentru ca ar supraincarca nodul si nu se asigura ofunctionare normala, atat a nodului, cat si a intregului sistem. Locatiile dedicate ducla cresterea cheltuielilor globale ale sistemului, dar si la disfunctionalitati pentruintreg sistemul atunci cand un astfel de nod devine nefunctional.Operare continua sau independenta la defectare. Obiectivul operarii continue serefera la doua aspecte majore ce privesc indeaproape performantele sistemelordistribuite, si anume: fiabilitatea si disponibilitatea. Fiabilitatea reprezinta capacitateaunui sistem de a functiona fara intrerupere cu asigurarea unor parametri de calitate.Sistemele distribuite, spre deosebire de sistemele tranzactionale, nu urmarescprincipiul atomicitatii. Acestea opereaza neintrerupt, chiar si in cazul aparitiei uneidefectiuni la componente sau la mediul de comunicatie. Disponibilitatea se refera laaspectul functionarii sistemului pe o perioada prestabilita, fara posibilitatea ca, dinanumite motive, o parte din date sa fie inaccesibile. In principal cerinta presupunecapabilitatea de ajustare a bazei de date fara a necesita trecerea acesteia offline.Multe baze de date permit actualizarea schemei locale si backup pentru date chiar cubaza online. Faptul ca un nod s-a defectat nu inseamna ca datele care erau stocate peacesta nu vor mai putea fi accesate, intrucat prin relaxarea redundantei datele segasesc si la alte locatii. Este de dorit ca sistemul sa nu fie afectat de nici un incident sicapabilitatea de functionare sa fie mentinuta chiar si in timpul procedurilor dementenanta.Independenta de localizare. Locul in care au fost stocate sau de unde sunt accesatedatele trebuie sa fie transparent, atat pentru utilizator, cat si pentru aplicatiile careruleaza. Utilizatorul trebuie sa se comporte in aceeasi maniera si sa fie servit de catresistem in consecinta, chiar daca el lanseaza cereri de pe nodul A, iar datele solicitatese afla la nodul A, X sau Y. Acest principiu poarta uneori numele de transparenta lalocalizare. Acesta se constituie in nivelul mediu de transparenta la distribuire, ceea ce inseamna ca utilizatorul va sti ca relatia globala este fragmentata, si ce anumecontine fiecare segment, fara insa a cunoaste locul unde fragmentele sunt plasate.Asadar, nu mai este suficienta o cerere adresata schemei globale, utilizatorul trebuindsa precizeze si denumirea fragmentelor din care se vor extrage informatiile. Totusi,operatorul nu trebuie sa fie preocupat de locul in care sunt distribuite fragmentele sinici de faptul ca ar putea exista replici ale acestora.Independenta de fragmentare. Spre deosebire de bazele de date centralizate, destinateunui nod central, baza de date distribuita este impartita in fragmente ce suntdistribuite pe toate locatiile sistemului. Aceste portiuni ale bazei globale se numescfragmente si datorita dimensiunii lor in raport cu sursa din care provin vor duce lacresterea performantelor sistemului. Fragmentarea bazei de date are impact directasupra cresterii concurentei bazei de date, intrucat in momentul in care un utilizatordoreste sa faca o actualizare, va bloca pentru o scurta perioada de timp doar o micaparte a unui fragment, deci o parte nesemnificativa a bazei de date globale.Fragmentarea se poate face dupa diferite criterii, iar fragmentele rezultate trebuiescdispersate pe statiile de lucru astfel incat sa fie atribuite locatiilor la care este cea maimare nevoie. Mai mult, din fragmente in orice moment se va putea recompune bazade date initiala. Daca aceste deziderate sunt realizate, utilizatorul nu va simtiniciodata ca ceea ce acceseaza el sunt de fapt fragmente stocate in diferite locuri si nubaza de date in totalitate, aflata pe nodul local. Independenta de fragmentarereprezinta elementul central al transparentei la distribuire. Chiar daca utilizatorul stieca datele sunt fragmentate, el nu trebuie sa se comporte diferit fata de un utilizator alunei baze de date centralizate. El trebuie sa lanseze cereri identice cu cele de la bazelecentralizate, fara a trebui sa faca un efort suplimentar in a cauta si mentiona explicitin interogare ce fragmente solicita si evident locatia acestora. Pentru acces la baza dedate distribuita se va consulta schema globala fara implicarea utilizatorului.Transparenta la distribuire este asigurata prin transparenta la fragmentare. Dinpunctul de vedere al utilizatorului nu prezinta importanta modul in care s-a facutfragmentarea, locul unde sunt amplasate fragmentele si nici faptul ca unele dintrefragmente pot avea replici in diverse locatii. In general bazele de date ofera suportpentru fragmentarea pe orizontala, insa suport ineficient pentru fragmentare peverticala.Independenta la replicare.Atat din motive de securitate cat si de disponibilitate adatelor, anumite fragmente trebuie sa fie copiate la mai multe locatii. Aceste copii senumesc replici sau reproduceri. Utilizarea replicilor si alocarea lor pe diferite locatiitrebuie sa fie facuta transparent fata de utilizator. Acesta trebuie sa fie in continuareconvins ca lucreaza de fapt pe intreaga baza care se afla stocata local. Acest lucru esteposibil daca replicile sunt plasate acolo unde sunt directionate frecvent cererilespecifice. 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 fragmenteleconsultate ar mai avea si alte amplasari posibile in retea. Replicarea datelor scadeperformantele atunci cand cererile trebuie sa se propage prin retea. Existentareplicilor locale creste performanta accesului la date intrucat nu necesita comunicarein retea. Daca se face actualizarea unei replici sunt posibile mai multe modalitatipentru actualizarea tuturor replicilor. O replica poate fi actualizata sincron, prinprotocolul numit si commit in doua faze,cu efect actualizarea tuturor replicilor sauasincron, atunci cand nu este necesar ca modificarile sa fie reflectate imediat in toatereplicile. Unele medii de baze de date ofera suport doar pentru replicare asincrona,altele cer ca aplicatiile sa includa triggeri pentru actualizarea replicilor. Acest tip detransparenta reprezinta ultimul nivel al transparentei la distribuire, foarte apropiat denivelul fizic.Prelucrarea distribuita a interogarilor. De cele mai multe ori, atunci cand seformuleaza o interogare, oricat de bine ar fi plasate fragmentele si replicile, rareori sevor obtine interogari pur locale. Datele pe care in general, o cerere le solicita suntplasate in cel putin doua locatii diferite. Pentru a raspunde unei astfel de solicitari inmod eficient trebuiesc executate cat se poate de multe operatii asupra datelor stocatela fiecare locatie, in conformitate cu principiul autonomiei. In vederea optimizariiinterogarilor, problema trebuie tratata atat la nivel global prin stabilirea strategieifunctie de datele problemei, coordonarea tuturor operatiunilor aferente, transmitereasi preluarea de mesaje catre si dinspre locatii, cat si la nivel local prin strategia internade prelucrare a interogarilor, comunicare rezultate partiale si verificari. Daca cerereaa fost emisa de locatia X, acesta o va transmite si locatiei Y pentru a executaoperatiile necesare dupa care va returna un rezultat partial. In functie de cardinalitatearezultatelor partiale, a dimensiunii unui n-uplu cat si a vitezei de transfer peinfrastructura fizica sau virtuala de comunicatie, una dintre locatii va trimite catrecealalta rezultatul partial pentru efectuarea prelucrarilor finale. In cazul distributiei ladoua locatii este necesara transmiterea a doar doua mesaje (cererea de prelucrare sirezultatul in sens invers). Cu cat numarul de locatii creste numarul de mesaje crestedatorita cererilor multiple catre locatii si a raspunsurilor de la acestea. O altaproblema vine de la multitudinea modalitatilor de rezolvare a interogarii, stiut fiindfaptul ca pot exista mai multe solutii de procesare a unei cereri. Cu toate caprelucrarea unei interogari intr-un mediu distribuit presupune o activitate maicomplexa, asta nu presupune ca raspunsul este intarziat, ci poate fi chiar mai promptdecat in cazul sistemelor centralizate datorita puterii crescute de calcul distribuit.Algoritmii de optimizare pentru executia tranzactiilor trebuie sa tina cont suplimentarde viteza retelei de comunicatie. In general, se urmareste ca tratarea cererilor sa fiecat mai apropiata, ca performante,de cea a cererilor locale.Gestionarea distribuita a tranzactiilor. Gestiunea tranzactiilor are ca obiect de studiucontrolul accesului concurent si problematica tolerantei la defecte. Fata de abordarea cu un singur nod central, in cazul sistemelor distribuite lucrurile devin mult maicomplicate. O tranzactie lansata in sistemul distribuit are nevoie de agenti, care saverifice rezultatul finalizarii tranzactiei in fiecare din locatiile implicate. Evident ca siin mediul distribuit proprietatile tranzactiilor (ACID - Atomicitate, Coerenta, Izolare,Durabilitate) trebuie sa fie respectate. Pentru ca o tranzactie sa corespunda pretentiilorde atomicitate trebuie ca fiecare agent al tranzactiei sa-si indeplineasca sarcina, in cazcontrar toti sunt nevoiti sa execute o tranzactie in compensare pentru a pastraconsistenta bazei. Similar cu bazele de date centralizate metoda cea mai raspandita decontrol al accesului concurent se bazeaza pe blocare. Gestionarea distribuita atranzactiilor este strans legata de problematica transparentei tranzactiilor. Fara a lua inconsiderare aspectele privitoare la controlul concurentei si a rezistentei la defecte,intr-un mediu distribuit, descompunerea unei tranzactii in subtranzactii duce lacresterea performantelor atat la nivelul vitezei de executie, cat si din punctul devedere al concurentei. Referitor la transparenta la defectare si capacitatea de refacere,trebuie sa se tina cont de atomicitatea tranzactiilor si de caracterul durabil almodificarilor facute. Un SGBD distribuit trebuie sa garanteze ca tranzactia globalaeste atomica, adica toate tranzactiile locale pe care le implica fie s-au terminat cusucces, fie au fost toate anulate. Nu putem avea situatii de compromis, deoarecedatorita caracterului durabil al subtranzactiilor se poate ajunge la inconsistente. Pelanga problemele cu care se confrunta sistemele centralizate (caderea sistemului, penede comunicatie, erori software, neglijenta, dezastre fizice, naturale sau sabotajul) unsistem distribuit trebuie sa tina cont si de: pierderea unui mesaj, defectarea legaturilorde comunicatie, defectarea unui nod sau de partitionarea retelei. Un sistem distribuittrebuie sa furnizeze un mecanism de refacere, care indiferent de aparitia unor posibileaccidente, de genul celor enumerate, trebuie sa sustina atomicitatea tranzactieiglobale. 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 satisfacacriteriul transparentei fata de hardwareul utilizat. Nici sistemele distribuite nu trebuiesa faca rabat de la aceasta caracteristica. Infrastructura hardware poate fi compusa dinechipamente de la diferiti producatori in configuratii si cu performante diferite.Utilizatorul nu trebuie sa sesiseze vreo diferenta in functionarea sistemului nici chiardaca lucreaza alternativ pe masini cu tehnologii de fabricatie diferite. Multe baze dedate opereaza pe o varietate de platforme.Independenta de sistemul de operare. Un sistem distribuit trebuie sa poate functionaatat pe masini diferite din punct de vedere al tehnologiei hardware, cat si pecalculatoare pe care sunt instalate sisteme de operare diferite. Utilizatorul nu trebuiesa resimta amprenta sistemelor de operare diferite, instalate pe masini diferite, sauchiar 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 masinicu sisteme de operare diferite.Independenta de infrastructura de comunicatie. Nodurile sistemului distribuit suntconectate logic la aceeasi retea de comunicatie. Chiar daca topologiile, vitezele detransfer, dimensiunile pachetelor, metodele de acces la mediu sau tehnologiasubretelelor, peste care acesta se intinde, sunt diferite, acestea nu trebuie sa devina unimpediment in buna functionare a sistemului.Independenta de sistemul de gestiune al bazei de date. Acest deziderat este unuldintre cel mai greu de atins. Ideal ar fi ca pe toate masinile sistemului distribuit saruleze acelasi SGBD. Nu intotdeauna acest lucru poate fi pus in practica datoritaeterogenitatii echipamentelor si a sistemelor de operare, fara a ne putea detasa si delatura financiara. Chiar daca SGBD-urile sunt diferite, ar fi cel putin recomandat ca sanu existe problema incompatibilitatii canalelor de comunicare intre locatiile avandSGBD-uri diferite. Pentru acessta, fiecare locatie ar trebui sa recunoasca acelasistandard SQL. Sistemul distribuit ideal ar fi acela care ar putea asigura transparentafata de orice SGBD utilizat. In general, cerinta este asigurata prin instalarea unuigateway (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 distribuitase includ: calculatoare personale, minicalculatoare, statii de lucru, dispositive mobile etc, toateconectate intr-o retea de comunicatie si numite generic noduri, site-uri sau locatii. Cu acesteprecizari definitia unui sistem de baze de date distribuite poate fi reformulata ca o colectie denoduri, fiecare putand participa la executarea tranzactiilor care acceseaza datele stocate la unnod sau la mai multe noduri.Regulile formulate de Date sunt destul de restrictive, motiv pentru care acestea trebuiesc relaxatein sistemele de baze de date distribuite. Principalele cerinte ce trebuie asigurate intr-un sistem debaze 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 delucru (adaugarea sau eliminarea unor noduri);independenta fata de localizarea si modul de fragmentare a datelor sau altfel spustransparenta fizica;asigurarea de facilitati pentru copierea sau replicarea datelor cu pastrarea independenteicopiiilor;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 topologiaretelei 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, unelefragmente 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 interogarilocale cerute de utilizator fara a implica alte noduri ale retelei, sau nodul participa la procesareaunor date gazduite de alte noduri din retea, indiferent de SGBD-ul instalat pe acestea. Atuncicand o cerere implica si date distante spunem ca este o cerere globala iar din punctual de vedereal executiei avem o executie distribuita. Similar cu sistemele de baze de date cetralizateoperatiile asupra bazei de date sunt grupate in tranzactii. Intr-o baza de date distribuitatranzactiile se impart in:tranzactii locale acele tranzactii pentru executia carora nu sunt necesare resurse stocatepe un alt nod si tranzactia este ceruta de un utilizator conectat la baza de date localatranzactii distante (remote) sunt tranzactii cerute de un utilizator conectat la baza dedate de la alt nod, dar pentru executia sa sunt necesare numai resurse aferente unui singurnod distant;tranzactii distribuite tranzactii lansate de un utilizator conectat la baza de date aferentaunui 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 nodsa stie de existenta celorlalte noduri si de capabilitatea acestora de a participa la executiatranzactiilor.

Avantaje i dezavantaje baze de date distribuiteIn 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 multmai bine, avand in vedere ca multe companii sunt localizate "distribuit" din punct devedere geografic;Cu toate ca datele sunt partajabile, administrarea lor se bucura de un grad inalt deautonomie locala. Datele pastrate pe fiecare site pot fi administrate independent de catreadministrator diferiti;Ofera o disponibilitate ridicata pentru accesul la baza de date fata de sistemelecentralizate. Chiar si in cazul in care apar erori de comunicatie sau defectari de nodurisistemul poate continua sa functioneze in conditii satisfacatoare;Se imbunatateste fiabilitatea sistemului intrucat pot fi refacute rapid fisierele distruseutilizand replici gazduite de alte noduri;Diminuarea costurilor de implementare si intretinere prin utilizarea de echipamenteuzuale 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 aplicatiilepermit acest lucru, scade costul de exploatare prin diminuarea costului comunicatiilor.Cresterea scalabilitatii sistemului prin posibilitatea de adaugare sau extragere a noinoduri, functie de necesitatile de exploatare. Ajustarea puterii de calcul la sistemelecentralizate este mult mai costisitoare si in plus necesita timpi de oprire afunctionalitatilor;Nu trebuie insa sa minimalizam efectele negative ale distributiei, dintre care principalele sunt:Cresterea complexitatii cu efecte in ceea ce priveste complicatiile de implementare sigestionare, necesitatea existentei unui personal specializat, necesitatea unei infrastructuride comunicatie;Sensibilitatea la erori datorata algoritmilor de procesare distribuita pentru care consistentadatelor este greu de mentinut;Necesitatea unor prelucrari suplimentare pentru asigurarea schimburilor de mesaje intrenoduri 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 datesensibile 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 cauzacosturilor mari de comunicatie, dar si atimpilor de raspuns, de cele mai multe ori serenunta 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 destandardizare putem afirma ca nu sunt inca standarde internationale unanim acceptatecare sa garanteze comunicarea eficienta, proiectarea, gestionarea si exploatarea datelor insisteme distribuite.Este posibila aparitia unui flux mare de informatii intre noduri care sa necesite rezolvareaproblemelor legate de sincronizarea mesajelor, detectarea erorilor, inconsistenta datelorredundante.

Proiectarea unei baze de date relationale distribuitePentru 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 ceurmeaza a fi distribuite;Alocarea determinarea locului in care un fragment este stocat pentru o distributieoptima si eventual a numarului de copii ale fragmentului pe mai multe noduri. In situatiain care se decide ca un fragment sa fie stocat intr-un numar de copii pe langa problemaalocarii intervine si problema replicarii.

FragmentareaO 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 laactualizarea datelor pentru sincronizarea tuturor replicilor, mai ales in situatia in caredatele se modifica la mai multe locatii;Daca relatia nu este replicata, pentru accesul la date de la distanta se va genera un volummare al traficului si datele vor fi disponibile cu mare intarziere. Sunt situatii in careintreaga tabela trebuie transmisa unui alt nod;Relatia se pastreaza la un singur nod daca cererile necesita toate datele stocate in relatie sidatele se stocheaza pe nodul care utilizeaza datele;Un principiu universal valabil arata ca este mult mai usor sa distribuim programe insensul 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 tranzactiiin 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 distribuiteintre mai multe noduri este greu de asigurat. Din cele analizate rezulta ca atat fragmentele cat sirelatiile sunt unitati corespunzatoare pentru distributie, insa decizia privind distributia trebuiefoarte bine analizata. Fragmentarea bazei de date asigura suplimentar o serie de alte avantajecum sunt: cresterea fiabilitatii, cresterea performantelor, scaderea costurilor de comunicatie,cresterea securitatii prin politici de securitate diferite la noduri, utilizarea eficienta a capacitatiide stocare. Alte criterii ce trebuie luate in consideratie la decizia de fragmentare constau inanalizarea locului in care o cerere se executa, ce seturi de date necesita, care este fvrecventa deexecutie 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 esteefectuata trebuie sa existe o succesiune de operatii prin care relatia fragmentata sa poate firefacuta. Fragmentarea poate fi:Orizontala atunci cand n-uplurile relatiei sunt segmentate in mai multe fragmentefiecare dintre acestea avand aceleasi attribute cu cele ale relatiei originale. In aceastasituatie sunt puse intr-un fragment n-uplurile care indeplinesc o anumita conditie,respectiv celelalte in alt fragment. Din punctul de vedere al reconstructiei o simplaoperatie UNION reface relatia initiala. In principal, fragmentarea orizontala decupeaza otabela pe orizontala pastrand in fiecre fragment inregistrarile satisfacand o anumitaconditie ce defineste setul de inregistrari. Fragmentarea orizontala nu afecteazaredundanta in sensul ca fragmentele pot sa contina date distincte si nu sunt pastrateaceleasi n-upluri in mai multe fragmente. Pentru descompunerea unei relatii in fragmentese executa operatii similar cu operatiaSELECT din algebra relationala. Daca o relatie R afost fragmentata orizontal in fragmentele R1, R2, R3, putem a recompune relatia initialaprin = 1 2 3;Verticala partitonarea relatiei dupa atributele sale. Un fragement contine toate nuplurilerelatiei, insa numai anumite atribute ale acesteia. Pentru refacerea relatiei initialeeste necesara o operatie de tip join insa pentru realizarea acesteia fragmentele trebuie sacontina ca informatie redundanta macar atributul cheie al relatiei initiale. Se observa cafragmentarea pe verticala necesita un grad mai mare de redundanta pentru pastrarea infiecare fragment a atributului cheie. Fie o relatie R si S1, respectiv S2 doua subseturi deatribute 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 obtinefragmentele R1 si R2 astfel: 1 = 1() si 2 = 2(), iar = 1 2, in care amnotat cu * simbolul operatiei NATURAL JOIN.Hibrida vazuta ca o combinatie intre fragmentarea orizontala si verticala sau invers. Infunctie de ordinea in care fragmentarea a fost facuta refacerea relatiei initiale se face fieprintr-o operatie JOIN urmata de UNION, fie UNIONurmate de JOIN. Daca consideramrelatia Angajat in care am facut fragmentarea pe orizontala avand in relatia Ang1angajatii cu un salariu mai mare de 1000 lei si in relatia Ang2 angajatii cu un salariu maimic 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 apartinanddepartamentelor 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 invedere urmatoarele:Realizarea pe cat posibil a accesului la date local, adica plasarea fragmentelor pe nodurilecare utilizeaza datele si eventual utilizarea de copii ale fragmentelor daca aplicatiapermite;Replicarea fragmentelor astfel incat sa se asigure o fiabilitate si o disponibilitate cat maimare;Optimizarea utilizarii resurselor astfel incat incarcarea nodurilor sa fie cat maiechilibrata;Diminuarea pe cat posibil a costurilor comunicatiei prin minimizarea interogarilor ceimplica mai multe noduri. Realizarea dezideratului duce la cresterea redundantei prinreplicarea fragmentelor, dar are dezavantajul major al costurilor si complicatiilor privindasigurarea consistentei datelor.Indiferent de modul de fragmentare, baza de date initiala trebuie sa poata fi refacuta dinfragmente printr-un set de operatii. Fragmentarea unei baze de date trebuie sa satisfaca un setminimal 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 gasestein relatia R trebuie sa poata fi gasita in fragmentele descompunerii;Reconstructia Daca o relatie R este descompusa in fragmentele R1, R2, , Rk, exista unoperator (un set de operatii) prin care relatia R este reconstruita din fragmentele sale faraa pierde nici o informatie;Disjunctia acceasi informatii nu se gaseste in mai multe fragmente. Exceptie lafragmenatarea verticala atributul cheie primara.

Implicatiile fragmentarii asupra executiei cererilorDaca 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 relatieiinitiale.

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 careresponsabil este Popescu se va scrie:SELECT A.NumeFROM Angajat A, Lucreaza LWHERE A.Ang_Id = L.Ang_Id and Responsabil =PopescuIn algebra relationala cererea implica o operatie Project efectuata asupra rezultatului operatieiSelect avand conditia Responsabil=Popescu din rezultatul operatiei Join intre Lucreaza siAngajat, ca in exemplul:PNume (SResponsabil = Popescu (Lucreaza >< Angajat)Daca vom considera baza fragmentata orizontal in fragmentele Ang1, Ang2, Lucr1, Lucr2 cesunt stocate la locatiile N1, N2, N3, N4 si cererea este formulata de catre un utilizator aflat lalocatia 5 se obtine urmatoarea schema de executie (fig. 4.2):

Desigur ca, aceasta nu este singura varianta de executie a cererii. O alta varianta poate fireuniunea fragmentelor Ang1 si Ang2, dupa care join cu rezultatul operatiei SELECT avandconditia responsabil=Popescu din rezultatul reuniunii fragmentelor Lucr1 si Lucr2, urmatede 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 infigura 4.3.

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

Problematica fragmentarii verticale a bazei de dateO 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 nconsiderare 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 curelaii ntregi. Prin urmare, pentru distribuirea datelor, pare mai adecvat s se lucreze cusubmulimi 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 multesubinterogri, 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.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 fiefectuat 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 oexcepie de la aceast regul, n care atributele cheii primare trebuie repetate pentru a permitereconstrucia 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 potimpune 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, careau 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 gsetebaza 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. Semsoar 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 defragmentare 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 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 dinmatricea 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 ialocarea datelor, asigur optimizarea i alocarea operaiunilor.Navathe i Ra au mbuntit lucrarea anterioar privind fragmentarea vertical prinpropunerea unui algoritm folosind o tehnic grafic. Matricea de afinitate a atributelor esteconsiderat ca un graf complet, unde nodurile reprezint atributele, iar ponderile muchiilorreprezint 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 deintrare 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. Majoritateaalgoritmilor 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 ntruntimp acceptabil, atunci pentru fragmentarea vertical i mixt nu poate fi argumentat vreunalgoritm 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 trebuiesoluionate la faza de proiectare logic pe fiecare staie aparte, care, de fapt, nu se deosebesc, nprincipiu, de problemele de proiectare logic n sistemele centralizate sau cu arhitectur clientserver.

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 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

ConcluziiAstzi, 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 evaluareacorectitudinii partiiilor; nu exist vreun criteriu comun sau o funcie-obiectiv, care s evaluezerezultatele acestor algoritmi de partiionare; rezultatul diferiilor algoritmi sunt, deseori, diferite,chiar dac pentru aceeai matrice de afinitate a atributelor se indic faptul c funciile-obiectivfolosite 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 populaieiiniiale, determinarea gradului de adaptare a indivizilor, aplicarea operatorilor i parametrilorgenetici i regulile de utilizare a acestora. Sunt necesare, de asemenea, experimente asupra unorexemple 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.

Cuprins

Introducere2Reguli date3Avantaje i dezavantaje baze de date distribuite9Proiectarea unei baze de date relationale distribuite11Fragmentarea12Implicatiile fragmentarii asupra executiei cererilor15Problematica fragmentarii verticale a bazei de date17Bibliografie20Concluzii21

19