Biologie	Chimie	Didactica	Fizica	Geografie	Informatica
	Istorie	Literatura	Matematica	Psihologie

Baze de date

Index » educatie » » informatica » Baze de date
» Arhitectura software-lui pentru baze de date

Arhitectura software-lui pentru baze de date

 

Service Interface

I

Fig.4.5. Modelul interfetei standard a unei BD distribuite

Software-ul dintr-un calculator client include un administrator de drivere care introduce doua interfete standard

Interfata de serviciu Acesta este un API ce utilizeaza drivere pentru interfata cu administratorul de drivere. Vanzatorii de software de baze de date scriu drivere ce se conformeaza cu interfata de serviciu pentru a permite software-ului lor sa interactioneze cu administratorul de drivere.

Interfata programelor aplicatie -Acesta este API ul pe care programatorii de aplicatii il folosesc pentru a face cereri de serviciu unei baze de date. Din cauza dependentei fata de drivere si de administratorul de drivere, modelul interfetei standard e numit uneori model driver. Modelul interfetei standard are multe asemanari cu modelul gateway. Diferentele majore sunt ca acest model depinde de interfata API standard pe care toate aplicatiile bazei de date il folosesc. Producatorii de aplicatii BD ce doresc sa participe intr-un mediu distribuit bazat pe un model de interfata standard, trebuie sa programeze ca API-ul standard sau sa foloseasca soft ce converteste un alt API la API-ul standard. Microsoft a creat o interfata standard BD numita ODBC.

Conectivitatea bazelor de date deschise ale Microsoft (ODBC)

Pentru ca un model de driver sa fie util intr-un mediu eterogen, cateva organizatii suficient de puternice, au trebuit sa creeze si sa publice un API cerut si o interfata driver standard, iar o multime de utilizatori suficient de mare si de vanzatori de software au trebuit sa fie de acord sa adere la acele standarde.

Producatorii de aplicatii beneficiaza de pe urma abordarii ODBC a bazelor de date distribuite, prin faptul ca sunt capabile sa dezvolte aplicatiile bazelor de date fara legatura cu sursele specifice ale datelor ce vor fi folosite.

4.3 Modelul protocolului standard

Protocol standard

Comunicatii

client

Fig.4.6. Modelul protcolului standard pentru o baza de date distribuita

Fig 4.6 arata modelul arhitectural al unui protocol de acces la baza de date. Acest model arhitectural, in loc sa standardizeze interfetele programabile ale interfetelor pentru care sunt folosite, depind de standardizarea protocoalelor folosite in comunicatiile dintre diferite calculatoare din mediul distribuit. Modelul protocolului standard permite oricarei API sa fie folosit atata timp cat software-ul se conformeaza protocolului standard.

Termenul protocol este larg folosit in retele de calculatoare. Este folosit cand se face referire la forma mesajelor ce sunt schimbate intr-o retea, intre doua calculatoare ce comunica si regulile ce guverneaza modul in care cele doua mesaje se schimba.

Arhitectura bazelor de date relationale distribuite de la IBM (DRDA)

Pentru ca un protocol standard de implementare sa fie folosit, cateva companii suficient de puternice au trebuit sa publice protocolul standard. In mediul mainframe o astfel de organizatie este IBM. IBM a creat un protocol standard de acces la baza de date numit DRDA. IBM a creat DRDA initial pentru ca mainframe sa suporte software-ul DB2.

4.4.1 Nivele de acces la baze de date distribuite

DRDA-ul de la IBM defineste patru nivele de acces la baze de date distribuite bazate pe complexitatea tranzactiilor pe care le pot construi aplicatiile, pe numarul de functii pe care software-ul bazei de date il suporta pentru a manipula fiecare tranzactie si pe capacitatea protocoalelor standard de a comunica intre componente. Cele patru nivele sunt:

Cererea la distanta. Cu acest nivel de acces, software-ul bazei de date suporta tranzactii ce contin fiecare o singura instructiune SQL ce acceseaza o singura baza de date aflata la distanta. Software-ul bazei de date nu are nevoie de functii de prelucrare a tranzactiilor speciale pentru a suporta acest nivel de acces.

Unitate de lucru la distanta. La acest nivel de acces, software-ul bazei de date suporta tranzactii care pot contine o serie de instructiuni SQL legate, ce acceseaza toate aceeasi baza de date la distanta. Software-ul BD trebuie sa fie capabil sa coordoneze toate procesele Rollback pentru toate instructiunile SQL.

Unitate de lucru distribuita. La acest nivel de acces, software-ul bazei de date suporta tranzactii ce pot contine fiecare o serie de instructiuni SQL, ce pot accesa fiecare o baza de date la distanta. Oricum fiecare instructiune individuala SQL trebuie sa faca referire la o singura baza de date. Aceast nivel cere ca software BD sa suporte capabilitati de actulizare distribuite in care o singura tranzactie poate sa actualizeze o baza de date rezidenta pe mai multe masini.

Cereri distribuite. Acest nivel de acces e similar cu unitatea de lucru distribuita, cu exceptia ca fiecare instructiune SQL poate referi informatii ce sunt stocate in uniri de baze de date distribuite

Cererea la distanta. Configuratia unei cereri la distanta cere un software baza de date, care nu e proiectat special pentru accesul la distanta pentru baza de date, sa fie folosit intr-un mediu distribuit. Cu aceasta tehnica, un program aplicatie ce ruleaza pe un sistem local, genereaza o cerere pentru accesul la o baza de date si paseaza cererea unei componente de comunicatie client.

Programul de aplicatie si componenta client de comunicatie, ruleaza ambele pe sistemul local. Apoi, componenta client de comunicatie trimite un mesaj prin retea la o functie software complementara, numita serverul bazei de date. Un protocol standard definit de DRDA e folosit pentru comunicarea intre componentele client si server. Componenta de comunicare server, software-ul bazei de date si baza de date insasi se afla pe sistemul de calcul la distanta.

fig. 4.7. Configuratia cererii de la distanta

Componenta de comunicatie server ce ruleaza pe sistemul de calcul la distanta admite cereri pentru accesul la baza de date, care sunt primite de soft-ul bazei de date ce ruleaza acolo. Serverul de comunicatie trimite inapoi rezultatele la componenta de comunicatie client din sistemul local. Componenta de comunicatie client trece apoi datele cerute programului de aplicatie local. Orice interfata API a bazei de date poate fi folosita si in calculatorul server si in client cat timp componentele de comunicatie client si server utilizeaza un protocol standard DRDA. Cu procesarea de cereri la distanta, toate functiile de distributie sunt manipulate de componentele client si server. Software-ul bazei de date din calculatoarele la distanta nu are nevoie sa stie ca are loc un acces la baza de date distribuita. Serverul de comunicatie apare pentru software-ul bazei de date ca un program de aplicatie care ruleaza pe calculatoare la distanta. Software-ul bazei de date ce ruleaza pe calculatoare la distanta poate bloca si elibera un dispozitiv de blocare ce permite accesul pe baza unei chei potrivite si poate face orice prelucrare de recuperare a bazei de date, ceruta de functiile serverului de comunicatie. Oricum, daca exista o eroare in retea, daca programul aplicatie ce apeleaza componenta bazei de date client cade, de eroare trebuie sa se ocupe programul aplicatie sau componenta de comunicatie client sau componenta de comunicatie server.

Unitatea de lucru la distanta

Cu o configuratie de lucru la distanta, este implementat un software de baze date complementar pe calculatorul local sau pe calculatorul la distanta. Cu aceasta abordare insusi software ul bazei de date are functiile de comunicare client si server si implementeaza protocolul DRDA, pentru transmiterea si primirea mesajelor prin retea.

Fig. 4.8 arata unitatea de lucru la distanta a unei configuratii de acces la o baza de date la distanta. Cu prelucrarea unitatii de lucru la distanta, o aplicatie data poate accesa o singura baza de date relationala ce rezida pe un singur sistem de calcul la distanta.

Cele doua componente software complementare sunt capabile sa manipuleze concomitent si sa deruleze prelucrari pentru tranzactii ca un intreg.

Fig. 4.8. Configuratia unitatii de lucru la distanta

Configuratia unitatii de lucru la distanta face vizibile multe erori ale programului aplicatie. Odata ce comunicatiile intre cele doua calculatoare sunt facute chiar de software-ul bazei de date, acesta poate fi proiectat sa recupereze din erorile ce apar in calculator.

Configuratii de baze de date distribuite

Fig.4.9 Configuratii de BD distribuite

Cele doua nivele anterioare ale accesului la bazele de date la distanta prin suport DRDA, permit unui program sa apeleze o singura baza de date ce rezida pe un singur calculator. Urmatoarele doua nivele de suport permit unui program sa acceseze o baza de date distribuita ce poate exista pe mai multe calculatoare la distanta. Cele doua abordari ale prelucrarii bazelor de date distribuite pot introduce o configuratie ce arata ca in fig.4.9.

Unitati de lucru distribuite. Intr-o configuratie data de o unitate distribuita de lucru, un program aplicatie poate apela date mentinute intr-o baza de date aflata la distanta, impartita pe doua sau mai multe calculatoare. Programul de aplicatie poate folosi un numar oarecare de instructiuni SQL, potrivite pentru scopul fiecarei tranzactii. Cu aceasta abordare, fiecare instructiune individuala SQL, trebuie sa se refere la datele care sunt stocate pe un singur sistem de calcul aflat la distanta. Software-ul bazei de date ce ruleaza pe calculatorul local si software-ul bazei de date ce ruleaza pe calculatorul la distanta lucreaza impreuna la coordonarea procesului de recuperare.

Cereri distribuite. Cererea distribuita este forma DRDA cea mai putin restrictiva din procesul de prelucrare a bazelor de date distribuite. Intr- o configuratie de cereri distribuite, baza de date poate fi pusa pe mai multe calculatoare la distanta si o singura instructiune SQL este permisa sa faca referinta la date ce pot fi stocate pe mai multe calculatoare. Software-ul bazei de date trebuie sa puna la dispozitie suportul necesar pentru a face posibil un acces transparent la datele mentinute pe sistemul de calcul la distanta.

4.5 Standard acces la baze de date relationale al X OPEN

Un alt exemplu de protocol standard de acces la baze de date este standardul RDA care a fost definit de X/OPEN, o organizatie internationala de standarde. RDA-ul X/OPEN se conformeaza aceluiasi nivel general ca si DRDA-ul de la IBM si are aceleasi scopuri generale, dar defineste un protocol diferit de DRDA.

Coexistenta modelelor arhitecturale

Se poate ca o organizatie sa foloseasca produse ce sunt conforme cu mai mult de un nivel arhitectural al software-ului bazei de date. Cum am vazut ODBC ul de la Microsoft standardizeaza API-ul in timp ce DRDA-ul de la IBM standardizeaza protocolul de acces la baza de date. Cele doua modele arhitecturale sunt mai degraba complementare decat competitive, iar folosirea unui model nu exclude folosirea celuilalt. Unele software-uri de baze de date folosesc protocoalele ODBC, API, DRDA pentru comunicatii. E posibil deasemenea ca ODBC-ul sa fie folosit in conjunctie cu un RDA X/OPEN.

Obiectivele bazelor de date distribuite

Scopul suprem ce ar trebui sa guverneze proiectarea oricarei baze de date distribuite este sa faca sistemul distribuit sa arate pentru utilizatorul final exact ca un sistem nedistribuit. Cu alte cuvinte, toate mecanismele ce sunt folosite sa se ajunga la distributia bazelor de date trebuie ascunse pur si simplu de utilizator. O baza de date distribuita ar trebui sa prezinte imaginea unei singure baze de date logice care este fizic distribuita pe mai multe site-uri (grup de documente HTML conexe). Punctul principal este ca, daca distributia este facuta corect, cu un mecanism software de BD corect, utilizatorul nu va face diferenta dintre o singura baza de date locala si una distribuita pe un numar de calculatoare la distanta. In continuare sunt prezentate cateva obiective pentru sistemul de baze distribuit

Autonomia locala. Este de dorit pentru diversele locatii dintr-un sistem de baze de date distribuit sa fie folosite independent una de cealalta. Acesta inseamna ca operatiile ce au loc intr-o locatie trebuie sa fie controlate de software-ul care ruleaza pe o singura locatie. Operatiile ce au loc pe un singur site nu ar trebui sa depinda de operatiile ce au loc altundeva in sistemul distribuit.

Nici un sprijin de la site-ul central. Obiectivul autonomiei locale presupune ca toate locatiile dintr-un sistem distribuit sa opereze ca egale si sa nu faca nici o cerere care sa se bazeze pe o singura locatie pe care o poate face un serviciu central pentru sistemul distribuit.

Operatiile continue. Ar trebui sa fie posibil sa fie proiectat intregul sistem al bazelor de date distribuit astfel incat sa nu trebuiasca niciodata ca o cerere sa inchida intregul sistem pentru a realiza o functie ceruta, cum ar fi adaugarea unei noi locatii la sistemul distribuit.

Independenta locatiilor. Un utilizator final sau un program aplicatie nu ar trebui sa fie preocupati de locatia fizica a datelor cand cer o operatie de acces la date. Sistemul de date distribuit ar trebui sa faca datele distribuite sa apara ca si cand ar fi date stocate intr-o singura baza de date logica ce rezida in locatia utilizatorului final.