PRINCIPIILE LUI DATE REFERITOARE LA SD

PRINCIPIILE LUI DATE REFERITOARE LA SD

Chris J. Date - "reguli" care privesc SD → set - de fapt sunt doua seturi, care alcatuiesc o duzina - de astfel de principii pe care SD trebuie / ar trebui sa le respecte. Acestea sunt completate de un principiu fundamental, intitulat "Principiul 0" sau "Regula 0"

Principiul fundamental al bazelor de date distribuite "pentru utilizator, SD trebuie sa arate la fel cu unul nedistribuit" → indiferent daca utilizatorul doreste sa acceseze sau sa prelucreze date care sunt stocate in situl X, Y sau Z, acesta sa nu perceapa faptul ca de oriunde si-ar lansa cererile - din A, B sau C - sistemul se comporta ca si cum datele ar fi fost locale (de pe A, B sau C). Conceptul fundamental - succint, dar prea sumar pentru un domeniu complex ca SD → 12 principii (obiective) pe care un sistem trebuie sa le indeplineasca.

Autonomia locala Un SD trebuie sa-i confere fiecarui sit implicat o autonomie locala → fiecare sit trebuie sa-si gestioneze singur propriile datele, iar pentru a functiona nu trebuie sa depinda de alte situri. Chiar daca, pentru o mai buna functionare, are nevoie de datele dintr-unul sau mai multe situri, propria functionare nu este conditionata de acele situri. Ce ne-am face daca unul sau mai multe situri ar fi avariate? In cazul interdependentelor de functionare, incet-incet fenomenul s-ar propaga, astfel incat intregul SD sa devina inoperabil. In realitate, cel putin pana acum, acest obiectiv nu a fost atins 100%. Intre situri trebuie sa existe o anumita ierarhie → acest lucru conditioneaza intr-o oarecare masura acest principiu al autonomiei. Totusi, chiar si Date este de acord ca momentan s-ar impune o reformulare si anume ca autonomia siturilor trebuie respectata "in cea mai mare masura posibila".

Absenta unei dependente de un sit central. Chiar daca intre situri exista o anumita ierarhie, acest lucru nu trebuie dus la extrem - nu trebuie sa existe un sit de care toate celelalte situri trebuie sa depinda. Mai mult, in SD nu are voie sa existe un sit care sa fie in totalitate raspunzator de o anumita functie sau subactivitate a SD. → nu putem avea un nod in care sa se realizeze controlul centralizat al tranzactiilor, gestiunea centralizata a interogarii, comandarea accesului concurent pentru intreg sistem, rezolvarea concurentei etc. SD isi propun sa nu aloce o astfel de functie "suprema" niciunui sit. Dependenta totala fata de un anumit sit supraincarca nodul respectiv si nu permite functionarea normala, atat a acestuia, cat si posibil al intregului sistem si dedicarea unui nod pentru o astfel de functie, va creste cheltuielile globale ale sistemului. O alta problema - faptul ca o cadere a unui astfel de nod ar periclita intreaga activitate a sistemului. O astfel de abordare - cu nod central - ar fi periculoasa si datorita Krakerilor, care si-ar putea directiona in special atacurile inspre astfel de noduri.

Operarea continua - doua aspecte majore ce privesc performantele SD, si anume: fiabilitatea si disponibilitatea.

a)     Fiabilitatea - capacitatea unui sistem de a functiona fara intrerupere cu respectarea unor parametri de calitate. SD, spre deosebire de tranzactii, nu functioneaza pe principiul atomicitatii - operand neintrerupt si in cazul aparitiei unor defectiuni a unor componente, cum ar fi un sit sau mediul de comunicatie. Aceasta proprietate - urmare a indeplinirii dezideratului de autonomie locala pentru globalizata la nivelul tuturor nodurilor sistemului.

b)    Disponibilitatea - aspectul functionarii sistemului pe perioada prestabilita, fara ca o parte din date sa fie inaccesibile. Datorita proprietatii de replicare datele vor fi disponibile chiar si la caderea unuia sau mai multor situri. Faptul ca un nod s-a defectat nu inseamna ca datele care erau stocate pe acesta nu vor mai putea fi accesate. Intr-un SD trebuie sa se regaseasca si in alte situri datele stocate local.

Nici un incident nu trebuie sa afecteze SD, sub aspectul functionarii, sau al completitudinii datelor. Mai mult, sistemul trebuie sa fie capabil sa-si continue functionarea chiar si in timpul procedurilor de mentenanta, fie de natura software, fie de natura hardware.

Independenta de fragmentare fragmentele - raspandite in sistem - maresc performanta. → cresterea concurentei bazei de date, deoarece utilizatorul in momentul in care doreste sa faca o actualizare, va bloca pentru o scurta perioada de timp o parte a unui fragment, o infima parte din baza de date globala. Fragmentarea - dupa diferite criterii - fragmentele trebuie dispersate statiile de lucru - acolo unde e cel mai mult nevoie de ele - fragmentele vor putea in orice moment sa recompuna BD initiala → utilizatorul nu va simti ca ceea ce acceseaza sunt fragmente stocate in diferite situri si nu BD din nodul local. Independenta de fragmentare/ transparenta la fragmentare - reprezinta miezul central al transparentei la distribuire. Utilizatorul nu trebuie sa se comporte diferit de un utilizator al unei BD centralizate. El va lansa cererile in mod identic cu acesta, fara a trebui sa faca un efort suplimentar in a mentiona explicit in interogare ce fragmente solicita datele si nici locatia acestora. Accesarile BDD - prin consultarea schemei globale → transparenta la fragmentare - nivelul suprem al transparentei la distribuire. Din punctul de vedere al utilizatorului nu - importanta modul in care s-a facut fragmentare sau locul de amplasare a fragmentelor si nici faptul ca unele dintre acestea ar putea avea replici in diverse situri.

Independenta de localizare/transparenta la localitie - Locul in care au fost stocate sau accesate datele trebuie sa fie transparent, atat pentru utilizator, cat si pentru aplicatiile care ruleaza. Utilizatorul trebuie sa se comporte de aceeasi maniera si sa fie servit de catre sistem, chiar daca el lanseaza cereri de pe situl A, iar datele solicitate se afla pe situl A, X sau Y. Este nivelul mediu al transparentei la distribuire - utilizatorul va sti ca relatia globala este fragmentata si ce anume contine fiecare fragment, insa locul unde fragmentele sunt plasate nu tine de competenta sa. → nu 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 faptul ca ar putea exista replici ale acestora.

Independenta de replicare/ transparenta la replicare - Din motive de securitate si de disponibiltate a datelor, anumite fragmente trebuie sa fie copiate in mai multe situri. Utilizarea replicilor si alocarea lor pe diferite situri trebuie sa se faca transparent pentru utilizator. Acesta trebuie sa fie in continuare convins ca lucreaza pe intreaga BD pe situl local si sa se comporte de asa maniera. Acest lucru este posibil daca replicile sunt plasate acolo unde sunt directionate cererile specifice cel mai frecvent. Utilizatorul va trebui sa transmita cereri catre fragmente bine delimitate, fara a fi obligat sa cunoasca localizarea si nici faptul ca fragmentele consultate ar mai avea si alte amplasarile posibile in retea. Transparenta la replicare - legata de conceptul de transparenta de alocare. Exista insa sisteme care se "bucura" doar de transparenta la replicare, nu si de cea de alocare. Exista si cazuri - improprii pentru un SD - cand utilizatorul trebuie sa aiba cunostinte temeinice nu numai in ce priveste denumirea, continutul, dar si locatia unde se afla fragmentele solicitate. Aceasta este cunoscuta sub denumirea "transparentei la transformarile locale". Utilizatorul este obligat sa cunoasca si detaliile locatiei fragmentelor. Acest tip de transparenta reprezinta nivelul cel mai scazut al transparentei la distribuire, foarte apropiat de nivelul fizic. Problemele de transparenta la distribuire enuntate anterior, implica o dependenta mai mica sau mai mare de problema alocarii si gestionarii numelor obiectelor din cadrul unui SD. Connolly transeaza aceasta problema prin asa-numita "transparenta la denumire", pe cand Chris Date ii confera o abordare mai complexa precum cea de "administrare a catalogului". Intr-un mediu distribuit, catalogul sistemului contine pe langa informatii precum numele de tabele, vederi si modul lor de definire, constrangeri, permisiuni de acces si utilizare, cat si informatiile necesare pentru asigurarea nivelului de transparenta la distribuire dorit. In cazul unui sistem centralizat locatia catalogului nu reprezenta decat un aspect usor de intuit - nodul central - in cazul unui SD lucrurile se complica. Cateva solutii pentru cataloage:

a)     Localizare centralizata - specifica sistemelor centralizate si presupune memorarea si gestiunea unui singur catalog in nodul central. Incalca principiul autonomiei si cel al independentei fata de un sit central. Fiabilitatea si disponibilitatea sunt puse sub semnul intrebarii;

b)     Replicare totala - plasarea unei copii a intregului catalog pe fiecare statie. Dezavantajul - un trafic si un control al integritatii suplimentar. Mai mult, afecteaza si autonomia siturilor prin aceasta nevoie continua de propagare a actualizarilor in fiecare sit;

c)     Fragmentare. Siturile sunt responsabile de gestionarea propriului catalog. Catalogul global = reuniune a cataloagelor locale. Chiar daca pentru principiul autonomiei si cel al independentei fata de un nod central este o abordare acceptabila, pentru continutul redundant, dar mai ales pentru prelucrarea telecerilor reprezinta o varianta inacceptabila;

d)     Localizare centralizata si fragmentare - o varianta hibrida intre a) si c) → atat un catalog global cat si cataloage individuale. Sporeste performantele de prelucrare la distanta ale fragmentarii, insa incalca independenta de situl central. Actualizarea catalogului necesita - spre deosebire de replicarea totala - doar doua cataloage. De ce este atat de importanta totusi problema denumirii obiectelor? In sistemele centralizate baza de date era memorata intr-un singur loc. Daca dorim sa accesam o relatie stim unde o gasim.

Dar, in conditiile unui SD in care un fragment F il gasim atat in situl A, cat si in situl B, o referire de genul F nu ne este indeajuns, pentru ca nu stim exact care dintre fragmente vrem sa fie accesat. Cea mai la indemana solutie ar fi calificarea fragmentului cu numele sitului, adica A.F, respectiv B.F, care elimina ambiguitatea, insa, deoarece suntem intr-un SD vom incalca transparenta la locatie. Asadar, in practica suntem obligati sa alegem o alta solutie. In timp ce Connolly opteaza pentru o solutie mai simpla de identificare a relatiilor dupa numele local precalificat de locul sitului in care a fost creat si cu eventuala specificare a numelui fragmentului si a numarului replicii pe care acesta o reprezinta (S1.STUDENT.F4.R3 - replica a treia a fragmentului cu numarul 4 a relatiei STUDENT creata in situl S1), Date dezvaluie strategia utilizata in sistemul R*. El evita sa ofere detalii despre posibilele denumiri ale replicilor sau fragmentelor. R* trebuie sa faca distinctie intre numele tiparit - numele local sau un sinonim -  al obiectului si numele de sistem. → ca pentru numele de sistem care trebuie sa fie unic in cadrul SD, sunt necesare urmatoarele elemente de identificare:

Identificatorul utilizatorului care a creat obiectul;

Identificatorul sitului in care s-a facut operatia de creare;

Denumirea locala a obiectului;

Identificatorul sitului in care a fost stocat initial obiectul.

Deci, daca noi am fi creat relatia STUDENT de pe situl din Cluj-Napoca si am fi stocat-o initial la Sighetu-Marmatiei, numele de sistem ar fi:

IONESCU @ CLUJ . STUDENT @ SIGHET

Chiar daca ulterior crearii, relatia se va plimba spre alte locatii, numele de sistem devine intangibil, pastrandu-se pe tot parcursul existentei obiectului. Utilizatorilor pot  referi un obiect cu un nume simplu, cum ar fi de exemplu cel local (STUDENT). Deoarece numele local este valabil doar local, se impune crearea unui sinonim pentru acesta, nume care sa fie memorat in tabela de sinonime:

CREATE SYNONIM CJSTUDENT FOR [email protected]@ SIGHET

In interogari utilizatorul poate sa refere tabela STUDENT fie cu numele local (doar pentru cereri locale), fie cu numele sinonimului (CJSTUDENT), indiferent de locatie → tabelele de sinonime - elemente de baza ale catalogului - memorate in fiecare sit si pentru fiecare utilizator recunoscut local. Au rolul de a face corespondenta intre numele de sistem si sinonime, facilitand astfel accesul la date. Pe langa tabelele de sinonime, in sistemul R vor mai fi necesare 2 intrari. Una va jurnaliza obiectele care au fost create aici (1), iar cea de-a doua obiectele stocate in mod curent in sit (2). Utilizatorul are acces pe una din statii, → va avea si un catalog propriu de sinonime. Se va face o cautare locala si se va afla ca obiectul a fost stocat initial la SIGHET. Pentru accesarea acestui sit, abia acum s-ar putea sa avem nevoie de prima cerere la distanta. Daca tabela STUDENT nu si-a "tradat" originile inseamna ca o vom gasi aici, conform regulii intrarii (1). Daca insa intre timp ea a migrat spre un alt sit - sa zicem BAIAMARE - atunci, dupa Date intrarea din catalog memorata in SIGHET ar trebui sa mentioneze acest fapt, datorita memorarii intrarilor de tipul (2).