| CATEGORII DOCUMENTE |
SISTEME DE GESTIUNE PENTRU BAZE DE DATE ORIENTATE PE OBIECTE
Obiectivul major al unui Sistem de Gestiune pentru Baze de Date Orientate Obiect (SGBDOO) este sa permita aplicatii complexe ca : ingineria, birotica sau administrarea retelelor, cu un castig semnificativ in performanta si in productivitate, comparativ cu SGBD-urile clasice.
Putem defini un SGBDOO drept un SGBD care suporta conceptul de obiect, ceea ce ne permite sa introducem diferite modele de BDOO. Un SGBDOO aduce cu el functii noi, cum ar fi : functii pentru obiecte complexe, functii pentru tranzactii mari si functii pentru gestiuni de obiecte.
Aplicatiile SGBDOO functioneaza intr-o arhitectura client-server, cu statii de lucru de mare putere. Pentru aceasta, el exploateaza capacitatile client-server prin utilizare de interfete grafice puternice si orientate pe obiecte.
In acest capitol vom prezenta aspectele comune din punct de vedere al problematicii si al solutiilor tehnice : arhitectura client-server, tehnicile de baza de implementare si interfatare sau utilitare grafice pentru SGBDOO -uri.
Din punct de vedere structural, arhitectura unui SGBD cuprinde doua parti :
. partea functionala, care descrie sistemul la nivel de software si de module;
. partea operationala, care cuprinde nivelurile hardware.
La nivel functional, functiunile diferitelor SGBD-uri sunt, in mod necesar, aceleasi. Din contra, arhitectura operationala poate fi foarte diferita, din cauza aplicarii modelului client-server si a obiectivelor de performanta.
SGBDR-urile au inceput sa foloseasca arhitectura client-server inca din anul 1980. Ea exploateaza intreaga putere a server-ului pentru gestiona o baza de date distribuita si accesibila printr-o interfata SQL si printr-o retea rapida. Aplicatiile si utilitarele de tipul 4GL se executa pe calculatoare client si ele fac apel la serviciile server-ului pentru manipularea datelor, prin mecanismul clasic de apelare a procedurilor la distanta (remote procedure call, RPC).
Acest tip de arhitectura s-a adaptat natural pentru un SGBDOO. In acelasi timp, datorita cresterii puterii statiilor de lucru, este interesant de a transfera o parte din functiile server-ului clientului.
In continuare, vom prezenta si vom compara cele doua arhitecturi mai cunoscute pentru OODBMS :
. server de obiecte
. server de pagini, precum si generalizarea lor
. multiserver
Pentru aceasta, si pentru precizarea arhitecturior functionale si operationale, ne-am inspirat din studiul lui [DeWitt 90].
Arhitectura functionala a unui SGBDOO, prezentata in figura 1, arata functiile oferite unui dezvoltator de aplicatii. Bineinteles, un utilizator final (client) nu are nevoie decat de o submultime a acestor functii.
Cele trei nivele principale sunt :
. utilitarele
. limbajele
. gestiunea obiectelor
Limbaj pt. cereri
LP1
LP2
Alte limbaje
Gestiunea schemei
Gestiunea obiectelor
Figura 1: Arhitectura functionala a unui OODBMS
Utilitarele pentru dezvoltare de aplicatii, in mod esential grafice, permit proiectarea interactiva a lui BDOO (definirea schemei) si generarea de aplicatii, cu interfetele lor grafice.
Nivelul limbaje cuprinde un limbaj de definire a datelor (DDL) care ne ajuta sa defininim schema, un limbaj de interogare si unul sau mai multe limbaje de programare, pentru a scrie metode si aplicatii. In cazul sistemelor cu obiecte persistente, limbajele de definitie si de programare se pot confunda. Tot la acest nivel pot fi disponibile interfete pentru interoperabilitatea cu alte sisteme.
Nivelul de gestiune a obiectelor furnizeaza toate functiile de acces si de manipulare a obiectelor, necesare limbajelor si utilitarelor. El include si gestiunea schemei, care se poate baza pe instrumente de gestiune a obiectelor.
Arhitectura operationala a unui SGBDOO este prezentata simplificat in figura Ea pune in evidenta functiile susceptibile de a fi distribuite intre client si server. Totodata, sunt aratate nivelurile de abstractizare, plecand de la memoria secundara, care permit unei aplicatii sa manipuleze obiectele.
Prin aplicatie, intelegem un cod executabil de catre SGBDOO, indiferent daca este vorba de un program utilizator compilat sau de un utilitar de interfata 4GL catre SGBDOO.
Am ignorat in aceasta schema aspectele de compilare, care implica verificarea tipurilor, optimizarea cererilor si gestiunea catalogului (care contine schema bazei de date).
Aplicatia se executa la nivel de obiecte, ea gestioneaza si manipuleaza obiecte in conformitate cu modelul dat. Acest nivel da mecanismele pentru creare si manipulare de obiecte persistente si rezerva un spatiu de adrese de obiecte pentru aplicatie. Tot acest nivel furnizeaza baza necesara gestiunea naturala a schemei (clase, metode, etc.), prin aceleasi mecanisme de sistem, ca o metabaza.
Nivelul fisiere furnizeaza operatiile traditionale pentru manipularea fisierelor, a indecsilor si a inregistarilor care contin obiectele. Un fisier permite, in principiu, regruparea fizica a obiectelor care au caracteristici comune, cum ar fi apartenenta la aceeasi clasa.
Fata de un SGF traditional, sunt necesare extensiuni importante :
. suport pentru obiecte foarte mari
. mentinerea conexiunilor intre obiecte
. noi structuri de indecsi
Gestiunea tranzactiilor multiutilizator se bazeaza pe un mecanism de control al concurentei, pe baza de blocari, si pe un mecanism de jurnalizare, care permite reluarile dupa pene. Aceste doua funcsii de gestiune sunt, in general, partajate intre nivelurile de obiecte si de fisiere, folosind gestionarul de pagini.
Nivelul pagini corespunde unui mecanism de gestiune a memoriei virtuale sub controlul lui SGBDOO. Pagina este unitatea de alocare din memoria principala si ea reprezinta o fractiune din blocul (unitatea) de intrare/iesire de pe disc. De obicei, ea are 4 kocteti. Acest nivel contine un cache pentru a pastra paginile cele mai utile aplicatiilor, tocmai pentru a evita accesul la disc. Acest nivel se bazeaza pe sistemul de intrari/iesiri care gestioneaza discurile (alocarea de spatiu disc, citirea blocurilor, scrierea paginilor).
Arhitectura server-ului pentru obiecte este cea a unui SGBDR. Unitatea de transfer intre server si o statie de lucru client este un obiect sau un grup de obiecte. Aceasta arhitectura a fost implementata in toate SGBDR-urile prin inlocuirea conceptului de tuplu prin cel de obiect, ca in Orion [Kim 90], Ontos [Ontologic 90], Versant [Versant 91] etc.
Figura 3 ilustreaza aceasta arhitectura cu un client, unde se executa aplicatia, si cu un server care gestioneaza baza de date de pe disc. Nivelul obiect este duplicat in intregime atat in client cat si in server, fiecare avand propriul cache cu obiectele cele mai recent accesate. Cache-ul clientului incearca sa reduca accesul la distanta - la server - pe cand cache-ul server-ului are ca scop reducerea numarului de accese la disc.
Atunci cand aplicatia cere un acces la un obiect care nu se afla in cache-ul local al statiei client, se trimite un apel RPC server-ului, care raspunde trimitand obiectul cerut.
Interfata dintre client si server ofera urmatoarele posibilitati :
. de creare sau de stergere a unui obiect
. de citire sau de scriere a unui obiect
. de trimitere a unui mesaj la un obiect
Daca obiectul este o colectie, aceste operatii pot fi de tip multime si sa se aplice, de asemenea, elementelor. De exemplu, citirea obiectului multime de angajati din orasul Bucuresti permite a cere o multime de obiecte.
Arhitectura server-ului pentru obiecte concentreaza in server toate functiile baza de date si desface in intregime gestiunea interfetelor si a utilitarelor 4GL ale clientului. Functiile dedicate, care asigura partajabilitatea si integritatea datelor, se simplifica prin aceasta centralizare.
Aceasta abordare a conceptului de obiect de catre server are avantaje semnificative pentru performanta sistemului. In primul rand, server-ul poate aplica blocarea si jurnalizarea la nivel de obiect, pentru a mari gradul de concurenta a multimii de utilizatori si, de asemenea, numarul de clienti potentiali ai server-ului. In al doilea rand, posibilitatea de a executa metodele pe server ce favorizeaza filtrarea obiectelor utile aplicatiei. De exemplu, server-ul poate executa o metoda SELECT asupra unei colectii foarte mari de obiecte pentru a restitui clientului numai obiectele selectionate.
In al treilea rand, executia unei metode complexe de mentinere a integritatii, cum ar fi verificarea dependentelor functionale, poate sa se faca in intregime pe server. Ca si pentru SGBD-urile relationale, aceasta arhitectura este excelenta pentru accesul de tip multime.
O aplicatie BDOO imbina accesul ansamblist cu navigarea pe obiecte. Arhitectura server ridica probleme serioase de performanta pentru navigare care pot conduce la cate un apel RPC pe obiect, in cel mai rau caz.
Un alt inconvenient al acestei arhitecturi se datoreaza posibiltatii de a executa metodele utilizator in server. In primul rand, codul utilizator nu este sigur si poate ameninta securitatea si fiabilitatea bazei de date. Problema este si mai sensibila in cazul in care server-ul este multithread, adica daca task-urile utilizator partajeaza spatiul adreselor SGBDOO-ului. Pana unui task poate implica pana server-ului. In al doilea rand, executia pe server a unei metode asupra unei multimi de obiecte distribuite intre client si server poate ridica probleme de consistenta caci obiectele ar fi putut sa fie deja modificate pe server. Solutia acestei probleme este foarte complexa si costisitoare, de exemplu repatrierea ultimelor imagini ale obiectelor de la clienti pe server. Ca un ultim dezavantaj major, aceasta arhitectura sufera de o centralizare excesiva, care poate gatui server-ul. Cu statiile de lucru de putere mare, numarul de cereri la server poate fi important si poate incetini clientii care asteapta obiecte de pe server. Solutia imediata consta in a inlocui server-ul saturat printr-un server mai putemic. Oricum, puterea cumulata a statiilor de lucru este mai mare decat a serverului si, deci, solutia este suspecta.
4 Server-ul de pagini
Arhitectura cu server de pagini muta majoritatea functiilor baza de date de pe server pe client. Utilitatea de transfer intre server si client este pagina. SGBDOO-uri recente, cum ar fi ObjectStore [Lamb 91] si O2~[ODeux 91] au folosit aceasta arhitectura pentru a putea exploata mai bine puterea statiilor de lucru si repartizarea geografica a aplicatiilor BDOO.
Arhitectura server-ului de pagini este aratata in figura 4. In aceasta arhitectura, clientul suporta singur nivelurile obiecte si fisiere, precum si nivelul pagini si practic duplica pe client server-ul. Server-ul devine un fel de controlor de disc inteligent care gestioneaza un cache de pagini partajate, aplicand blocarile si jurnalizaerea la nivel de pagina. Clientul emite cereri de pagini server-ului, care nu le trimite decat dupa ce a realizat blocarile necesare.
Interfata intre client si server ofera urmatoarele avantaje :
. alocarea/dezalocarea unei pagini
. citirea/scrierea unei pagini
Mentinerea a cate un cache de pagini pe client, in loc de un singur cache de obiecte, permite o aceeasi reprezentare a obiectelor, de la disc pe interfata utilizator. De asemenea, actualizarea unui obiect se poate face direct in pagina de pe client si ea se poate intoarce in baza de date printr-o simpla scriere a paginii pe server.
Exista si alte avantaje ale folosirii unui server de pagini. In primul rand, aceasta abordare exploateaza intreaga putere a statiei de lucru pentru functiile baza de date cele mai mari consumatoare de timp in calcul (gestiunea obiectelor si a fisierelor). In al doilea rand, simplificand si limitand activitatea server-ului la gestiunea inteligenta a unui cache de disc, acesta poate servi un numar mai mare de clienti. In al treilea rand, executia codului utilizator pe client izoleaza server-ul de penele datorate metodelor utilizator.
Pe langa aceste avantaje, server-ul de pagini aduce si o serie de dezavantaje. Primul este impiedicarea tratarii ansambliste a cererilor pe server. De exemplu, selectarea obiectelor unei multimi necesita citirea multimii pagina cu pagina pe client. Ca o observatie, sa notam ca, totusi, indexul nu permite decat accesul la paginile susceptibile de a contine obiectele utile. Al doilea dezavantaj consta in faptul ca blocarile si jurnalizarea trebuie aplicate la nivel de pagina, ceea ce poate limita gradul de concurenta a unei multimi de utilizatori. De exemplu, doua obiecte de pe aceeasi pagina nu pot fi accesate de doi clienti diferiti.
Comparand cele doua arhitecturi [DeWitt 90], pentru o aceeasi putere de calcul, arhitectura server de pagini este superioara, deoarece statiile au o memorie principala mare si fiindca aplicatiile folosesc o puternica localizare a referintelor. In caz contrar, predomina server-ul de obiecte.
In concluzie este recomandabila o abordare hibrida, care sa duplice pe serverul de pagini anumite functii ale nivelului obiect, inainte de a permite blocari la nivel de obiect (in plus fata de cele de pagini).
Arhitectura multiserver reprezinta o evolutie naturala a celor precedente, in care fiecare masina poate fi folosita drept server sau client, sau amandoua. Singura restrictie pentru a putea fi server este de a dispune de un disc local.
Figura 5 arata arhitectura multiserver, cu doua statii care au exact aceleasi functii.
Aplicatie Obiecte
distribuite Fisiere Pagini Aplicatie Obiecte
distribuite Fisiere Pagini
I
Arhitectura multiserver face posibile mai multe variante. Unitatea de transfer intre servere poate fi obiectul sau pagina, in concordanta cu nivelul de interfata furnizat. Nivelul obiecte trebuie sa asigure transparenta fata de distribuirea fizica a obiectelor lor, adica aplicatiile trebuie sa se poata executa intr-o maniera similara, indiferent daca acced obiecte locale sau la distanta.
Nivelul obiecte distribuite transforma cererile de obiecte nelocale in apeluri RPC catre serverele implicate. Pentru aceasta, fiecare server are propriul sau spatiu de adrese de obiecte si un catalog care contine informatii despre repartitia obiectelor. Acest catalog este duplicat pe fiecare server si el permite localizarea obiectelor nelocale. Pentru simplificare, unitatea de localizare nu este obiectul, ci baza de date. Cu aceasta abordare, folosita de GemStone si Ontos, un obiect si toate obiectele conectate la el trebuie sa fie locale, adica un obiect nu poate referi un alt obiect nelocal.
O alternativa recenta consta in a pastra un singur spatiu global de obiecte in care fiecare obiect poseda un identificator unic in sistemul distribuit. Este posibil, asadar, ca un obiect local sa faca referinta la un obiect la distanta. Principalul dezavantaj al acestei abordari este costul gestiunii identificatorilor globali. O solutie ar fi o gestiune uniforma a obiectelor prin reprezentarea lor intr-o memorie virtuala distribuita. Aceasta abordare este folosita de sistemul Eos [Gruber 92].
6 Tehnici de baza
Desigur, tehnicile pentru a realiza un SGBDOO se bazeaza pe tehnicile folosite pentru un SGBD relational sau de navigare. In acelasi timp, functiile noi introduse de catre DBOO cer extensii importante in domeniile urmatoare : suportul pentru persistenta, gestiuni de obiecte, gestiuni de tranzactii si optimizarea interogarilor. Vom prezenta pe scurt aceste tehnici.
6.1 Suportul pentru persistenta
Modelele posibile de persistenta se realizeaza prin mostenire si prin referinta, iar persistenta prin referinta ofera un nivel mai bun de transparenta pentru programator.
Tehnicile de implementare a persistentei, chiar daca sunt relativ independente fata de modelul de persistenta, afecteaza direct complexitatea compilatorului limbajului BDOO, precum si performantele de acces la obiecte.
Problema persistentei se poate reduce la gestionarea corespondentei intre OID-uri si pointerii corespunzatori din memonia principala, deoarece activarea unui obiect persistent plecand de la OID-ul sau stabileste o corespondenta cu adresa sa de memorie. Din ratiuni evidente de performanta, ar trebui sa putem accesa un obiect in memorie plecand de la OID-ul sau si evitand inca un acces disc.
Exista doua tehnici pentru gestionarea acestei corespondente :
. gestiunea descriptorilor de obiecte
. memorie virtuala a obiectelor
Gestiunea descriptorilor obiectelor este ilustrata in figura 6. Odata ce un obiect este activat si, deci, transferat de pe disc in memorie, se creaza un descriptor care stabileste o corespondenta intre OID si pointerul obiectului. Acest descriptor poate contine si alte informatii despre starea obiectului, de exemplu faptul ca a fost modificat. Pentru a accelera accesul la obiectele din memorie - plecand de la referinta lor indicata intr-o expresie de cale - se creeaza o tabela de descriptori, indexata dupa OID. Asadar, costul accesului unui obiect in memorie prin referinta este o indirectare. Aceasta tehnica este compatibila cu arhitecturile server de obiecte si server de pagini.
Pentru a optimiza accesul prin referinta, majoritatea SGBDOO-urilor folosesc o tehnica numita swizzling (mixaj), care converteste referintele interobiecte, implementate prin OID-uri, in pointeri de memorie. Odata ce un obiect este adus in memorie, toate referintele (obtinute in obiect) spre alte obiecte din memorie, precum si toate referintele spre acest obiect sunt convertite in pointeri.
La dezactivarea obiectului, o operatie inversa converteste pointerii in OID-uri. Evitand accesul la tabela de descriptori, tehnica swizzling permite accesarea obiectelor persistente prin pointeri la fel de rapid ca si a obiectelor din tranzactii.
Dezavantajul acestei tehnici se vede in situatia in care obiectele sunt activate/ dezactivate des si trebuie conversii numeroase intre OID-uri si pointeri. In acelasi timp, obiectele convertite trebuie sa ramana fixe si astfel se impiedica reorganizarea spatiului memoriei.
In concluzie, tehnica swizzling este foarte buna pentru aplicatiile care folosesc o mare localizare a referintelor la obiecte, ceea ce, de fapt, este o caracteristica pentru noile domenii ale BDOO.
Memoria virtuala a obiectelor, dezvoltata de ObjectStore, are toate avantajele tehnicii swizzling, evitand insa gestiunea unei tabele de descriptori si conversiile OID-pointer. Fiecare obiect al bazei de date este creat intr-un segment de memorie virtuala astfel incat OID-ul sau sa fie omogen cu adresa sa de memorie. Atunci cand un obiect este actualizat, pagina care il contine trebuie sa fie transferata in acelasi segment de memorie virtuala.
Implementarea acestei tehnici este delicata, deoarece SGBDOO trebuie sa trateze defectele din pagini care intervin atunci cand o referinta cauzeaza un acces invalid (obiectul si pagina sa nu fie in memorie). De asemenea, uneori o pagina trebuie incarcata la un alt amplasament in memoria virtuala, daca spatiul sau este ocupat de catre o pagina din alt segment. In acest caz, trebuie convertite toate referintele interobiecte, ceea ce face sa avem un cost aproximativ egal cu swizzling.
Metoda memoriei virtuale a obiectelor are mai multe avantaje. In primul rand, navigatia interobiecte este foarte eficienta, la fel de rapida ca cea prin pointeri. In al doilea rand, tratarea uniforma a obiectelor tranziente si a celor persistente simplifica programarea. In al treilea rand, metodele scrise pentru obiecte tranziente se pot adauga in SGBDOO pentru a opera asupra obiectelor persistente, fara modificare.
Metoda are si dezavantaje. In primul rand, ea nu este compatibila decat cu arhitectura server de pagini, interzicand extinderea blocarilor la nivel de obiect. In al doilea rand, obiectele sunt fixe pe disc inca de la crearea lor, facand dificila orice reorganizare dinamica.
In SGBDOO-uri, gestiunea obiectelor inseamna mecanismele de acces la obiectele persistente. Scopul lor este de a organiza obiectele astfel incat sa fie nevoie de cat mai putine accese disc pentru a accede la obiecte.
In principiu, un SGBDOO trebuie sa suporte accesul pnin referinta (OID), colectorul de stergeri si metode de acces la obiectele complexe si foarte mari. Performanta accesului prin referinta la obiectele de pe disc depinde de modul de implementare al OID-ului : fizic sau logic.
Tehnica OID logic este imprumutata din limbajele orientate pe obiecte (Smalltalk) pentru a atinge obiectele din memorie. Ea este folosita de catre GemStone si Orion. OID este un index intr-o tabela care da adresa fizica a obiectului pe disc (figura 7).
Figura 7 : OID logic
Aceasta solutie garanteaza teoretic unicitatea si invarianta OID-urilor in spatiul obiectelor persistente si permite reorganizarea spatiului pe disc prin mutarea obiectelor. Daca tabela cu OID-urile este rezidenta in memorie, accesul la un obiect costa in plus un acces la disc. In acelasi timp, tabela cu OID-urile este o resursa partajata de catre toate tranzactiile si ea poate deveni rapid o gatuire pentru performanta. Pe de alta parte, daca granularitatea obiectelor este prea fina, tabela poate deveni foarte mare, ceea ce implica constructia unui index pentru a o accesa pe bucati. De asemenea, stergerea obiectelor face gauri care trebuie recuperate prin reorganizari periodice.
Datorita celor spuse mai sus, majoritatea SGBDOO-urilor folosesc OID fizice. Un OID fizic este compus dintr-o adresa unica de pagina disc si dintr-un index intr-o tabela din aceasta pagina, care da adresa reala a obiectului in pagina (figura 8).
Figura 8 : OID fizic
Aceasta solutie evita gestiunea unei tabele globale. Pretul ei este o indirectare suplimentara atunci cand obiectul este deplasat, ceea ce aduce in plus doua accesari de disc.
Colectorul de stergeri este o functie majora in limbaje de programare precum Lisp sau Smalltalk. Ea permite recuperarea automata a spatiului de memorie ocupat de obiecte devenite inaccesibile pentru variabilele program.
Mecanismul persistentei prin referinta - adic atribuirea de persistenta numai obiectelor care sunt legate direct sau indirect de nume persistente - poate conduce la obiecte inaccesibile in spatiul persistent, ca urmare a modificarii obiectelor (figura 9).
 |
O prima solutie, folosita in C si C++, consta in a lasa responsabilitatea dezalocarii obiectelor pe seama programatorului. Ea este o solutie buna in cazul limbajelor de programare, caci spatiul obiectelor este in intregime privat programului si poate fi deci, controlat de programator. In cazul spatiului persistent multiutilizator se poate ca un obiect sa devina inaccesibil pentru un program (ca urmare a modificarilor) insa el ramane accesibil altor programe, plecand de la numele dintr-un catalog privat. Dezalocarea unilaterala a unui astfel de obiect poate viola integritatea bazei de date si poate cauza erori de executie pentru alte programe. Pentru a evita aceasta problema, in ceea ce priveste abordarea manua1a, s-a convenit sa se interzica gestiunea cataloagelor private. Aceasta abordare este folosita de majoritatea SGBDOO-urilor bazate pe C++.
O solutie consta in a lasa pe seama sistemului dezalocarea obiectelor, prin intermediul asa zisului colector de stergeri. Ea are avantajul de a elibera programatorul de o sarcina delicata, insa costul este destul de mare. Intr-adevar, colectorul de stergeri ar putea determina daca un obiect din spatiul persistent nu mai este atasat la nici un obiect persistent. Solutia triviala si ieftina consta in a atasa fiecarui obiect un contor de referinte a carui punere pe zero ar permite dezalocarea obiectului. Din nefericire, aceasta tehnica nu permite dezalocarea obiectelor implicate intr-un ciclu (contorul nu devine zero niciodata). Solutia generala consta in a marca obiectele care se vor distruge si in a parcurge periodic graful obiectelor plecand de la nume persistente pentru a dezaloca obiectele marcate si inaccesibile. Aceasta parcurgere se implementeaza printr-o tranzactie care blocheaza toate obiectele bazei de date si impiedica accesul altor tranzactii. Colectorul de stergeri este suportat de catre sistemele GemStone si O
Plasarea obiectelor pe disc trebuie sa tina cont de obiectele voluminoase, cum ar fi imaginile si obiectele cu o structura complexa (ierarhie sau graf). Mecanismele de acces la obiecte atomice voluminoase (BLOB = Binary Long Object) trebuie sa rezolve doua probleme. In primul rand, un BLOB nu se poate tine in memoria principala, el generand si trimitand inapoi pe disc, prin mecanismul memoriei virtuale. Apoi, modificarea a cativa octeti se face prin recopierea intregului obiect, ceea ce este foarte scump in termeni de accesari la disc.
Solutia cea mai simpla consta in a trata un BLOB ca lista de octeti de marime variabila, cu o interfata de acces prin pozitie. De asemenea, un BLOB poate fi accesat prin blocuri de octeti, tinute cate unul in memorie. Primele sisteme care au suportat un BLOB au fost Orion, Exodus [Carey 86] si O
Plasarea obiectelor complexe combina tehnici relationale si de navigare. Tehnicile relationale se aplica la plasarea obiectelor in segmente monoclasa, ca in cazul tabelelor. Tehnicile de navigare se aplica la plasarea multiclasa sau la plasarea prin proximitate (de obiectele tata). Aceasta din urma poate fi controlata complet de catre programator, care precizeaza, inca de la crearea obiectului, obiectul langa care acesta va fi plasat.
Pentru a accelera expresiile de cale, se pot imbunatati indecsii secunzi, prin asa zisii indecsi de cale, care asociaza valori de atribute - obtinute prin expresii de cale la obiectele originale corespunzatoare. De exemplu, printr-un index de cale se pot regasi direct OID-urile Angajatilor care lucreaza pentru un Sef de nume dat. Ca pentru orice index, exista un pret de intretinere, datorita actualizarilor.
In aplicatiile de gestiune, tehnologia bazata pe tranzactii si-a dovedit de mult utilitatea. In general, aplicatiile de gestiune se pot clasifica in doua categorii distincte :
. tranzactionale
. decizionale
Aplicatiile tranzactionale (de exemplu, sisteme pentru rezervari de locuri) se caracterizeaza printr-un numar mare de tranzactii care acced date putine, in mod esential, doar pentru actualizari. Ele cer o granularitate fina (de obicei, tuplul) pentru gestiunea tranzactiilor, tocmai pentru a maximiza debitul sistemului, adica numarul de tranzactii in unitatea de timp.
Aplicatiile decizionale (de exemplu, previziunile) se caracterizeaza printr-un numar limitat de tranzactii care acced date multe, cu putine actualizari. Ele cer o granularitate mai mare (de obicei, tabele) pentru a reduce timpul de raspuns. Nici in teorie si nici in practica nu apar probleme daca un sistem a optat pentru una din aceste doua situatii. Problemele apar in clipa in care un sistem este obligat - datorita problematicii pe care o rezolva - sa combine cele doua tipuri de tranzactii, deoarece tranzactiile decizionale au tendinta de a se lega de date pentru un timp indelungat in detrimentul tranzactiilor scurte. Solutia banala consta in a decupa aplicatiile decizionale in tranzactii scurte, pentru a elibera frecvent datele [Shasha 92].
In aplicatiile de inginerie (domeniu predilect pentru BDOO), problema se complica, deoarece, in faza de proiectare, sunt emise o sumedenie de tranzactii scurte asupra unei multimi mari de obiecte, in faza de validare se emit tranzactii lungi in citire, iar in faza de punere in productie, se pot genera tranzactii multe de citire. Pentru a-si gestiona tranzactiile, un SGBDOO are la dispozitie mai multe tehnici imprumutate de la SGBDR. Este vorba de blocarea in doua faze (two-phase locking) si jurnalizarea inainte de scriere (write-ahead logging). De asemenea, majoritatea SGBDOO propune extensii care sa ia in calcul comportamentul nou al aplicatiilor BDOO : tehnici optimiste de control concurent, suport cooperativ de lucru, gestiunea tranzactiilor mari, gestiunea versiunilor obiectelor.
Blocarea in doua faze este considerata o tehnica pesimista, deoarece obiectele trebuie sa fie blocate inainte de a fi atinse si se elibereaza dupa terminarea tranzactiei. Chiar daca exista putine conflicte, cererile sistematice de blocari, precum si detectarea interblocarilor (dead-lock) micsoreaza mult din performante.
Din contra, tehnicile optimiste de control concurent permit accesul fara control la obiecte. La sfarsitul tranzactiei, se executa o procedura de validare pentru a abandona orice tranzactie care acceseaza un obiect intr-un mod incompatibil. Avantajul acestei tehnici este absenta asteptarii dupa eliberarea blocarii precum si simplitatea validarii, prin intersectie de liste cu OID-uri. Dezavantajul metodei consta in cresterea numarului de conflicte, care poate genera foarte multe abandonuri, care costa mult in cazul unei jurnalizari inainte de scriere. In consecinta, un SGBDOO ca GemStone, care ofera un control optimist al concurentei, trebuie sa suporte de asemenea, si blocarea in doua faze, alegerea ramanand la nivelul programatorului sau a administratorului de retea.
Munca prin cooperare este esentiala in
aplicatiile de proiectare asistata (CAD,
Un mecanism de notificare permite a indica utilizatorului bazei de date private nevoia de acces la anumite obiecte si, deci, de a colabora cu alti proiectanti. Tranzactiile mari sunt si ele produse colective. Cu notiunea traditionala de tranzactie, actualizarile sunt integrate in baza de date doar la sfarsitul tranzactiei (comitere). Orice pana care apare inainte de terminarea tranzactiei implica reluarea tranzactiei, ceea ce are ca efect refacerea actualizarilor anterioare panei. Aceasta este inacceptabila pentru o tranzactie care poate dura foarte mult (de la minute la saptamani). Solutia consta in a introduce puncte de reluare intermediare in interiorul tranzactiei prin ordine commit. In caz de pana, este suficient a reveni la ultimul punct de reluare pentru a gasi o stare consistenta
Generalizarea acestei tehnici prin tranzactii imbricate creste flexibilitatea controlului concurent si al reluarilor. Operatiile individuale ale unei tranzactii imbricate sunt ele insele tranzactii, obtinandu-se o ierarhie de subtranzactii. Este atunci posibil de a controla reluarea partiala sau abandonul partial al subtranzactiilor. Pentru a pastra proprietatea de atomicitate a tranzactiei, validarea unei subtranzactii este conditionata de validarea tranzactiei mama. Problema este a costului necesar pentru mostenirea blocarilor si a jurnalelor in sensul ierarhiei pentru a pastra aceasta proprietate. Acest model e folosit de ObjectStore.
In aplicatiile de proiectare asistata, mai multi utilizatori, responsabili cu proiectarea de obiecte diferite, au nevoie, totusi, de a accesa aceleasi obiecte, de exemplu pentru a conecta obiecte proiectate separat. Prin mecanismul de check-in - chek-out nu este posibil sa se acceseze simultan aceleasi obiecte de utilizatori diferiti. Solutia consta in a permite diferitelor versiuni ale unui acelasi obiect de a fi folosite de tranzactii diferite. Aceasta tehnica este folosita, de exemplu, de catre Versant. El distinge intre o versiune curenta si mai multe versiuni alternative. Versiunea curenta este prioritara fata de celelalte. Aceasta permite fuzionarea automata a versiunilor in absenta actualizarilor conflictuale asupra acelorasi obiecte, sistemul poate produce o noua versiune V3 ca reuniune a versiunilor V1 si V In caz de conflict, V1 este versiunea valida
Un limbaj de interogare pentru BDOO, cum ar fi OQL [Cattel 93] sau SQL3 [ISO 93] permite exprimarea de interogari asociative pentru a accesa obiecte. Dupa cum se stie, optimizarea automata a interogarilor este un avantaj esential al SGBD-urilor. Transpusa in modelul obiect, optimizarea interogarilor trebuie sa poata determina cea mai buna cale de acces la obiecte, prin exploatarea indecsilor, prin ordonantarea operatiilor algebrice aplicate colectiilor si, eventual, prin alegerea celui mai bun algoritm pentru fiecare operatie. Pentru a face acestea, un optimizator trebuie sa exploateze cunostintele despre sistem (in termeni de functii de cost) precum si schema fizica a bazei de date (in termeni de statistica). De fapt, cu cat aceste cunostinte sunt mai precise, cu atat deciziile de optimizare devin mai pertinente. In cazul abordarii bazate pe relational sau a celei integrate, optimizarea interogarilor este elaborata. Din contra, sistemele cu obiecte persistente se limiteaza la selectionarea cailor de acces, fara a utiliza informatii despre costuri.
Comparativ cu abordarea relationala, optimizarea limbajului de interogare este complicata de doi factori. In primul rand, predicatele care servesc drept baza pentru accesul declarativ pot fi exprimate prin metode generale. Euristica traditionala a optimizatorilor relationali, care trateaza selectiile cat mai repede posibil, nu se aplica in cazul metodelor costisitoare, deoarece dureaza mult in functie de cost [Lanzelotte 92]. O problema deschisa este estimarea precisa a costului unei metode in functie de argumentele sale (care pot fi colectii). Al doilea factor de complicare este posibilitatea expresiile de cale sa fie vazute ca join-uri precalculate.
Urmarirea sistematica a expresiilor de cale pare naturala; ea poate fi optimizata simplu prin exploatarea indecsior de cale. In acelasi timp, existenta legaturilor inverse intre obiecte ofera cai de acces alternative, care si ele trebuie luate in calcul de catre optimizor. Solutia generala consta in a considera toate traversarile posibile ale grafului cererilor de interogare si de a alege pe cea mai buna in functie de index si de costul sau estimat.
Cresterea puternica a populatiei utilizatorilor de baze de date se traduce si printr-o mai mare exigenta fata de interfetele pentru utilizatorii finali, programatorii de aplicatii si de administrare a bazei de date. SGBDR-urile au introdus termenul de 4GL, adica utilitare de dezvoltare si de utilizare de aplicatii pentru bazele de date scrise in limbajele de generatia a patra. Obiectivul utilitarelor 4GL este de a imbunatati productivitatea dezvoltatorilor de aplicatii, precum si calitatea interfetelor utilizator. Interfetele grafice, in mod tipic orientate pe obiecte, joaca un rol din ce in ce mai important in aceste utilitare.
Si SGBDOO-urile ofera utilitare de tipul 4GL obiect, care stiu sa integreze uniform gestiunea obiectelor persistente si gestiunea obiectelor interfata. Aceasta este o deosebire majora fata de utilitarele 4GL din SGBDOO, care sufera de disfunctionalitati care conduc la gestionarea a doua cataloage separate, unul pentru obiectele grafice si altul pentru tabele.
Utilitarele de proiectare ale unui SGBDOO permit crearea si editarea schemei, reprezentata de catre graful claselor.
Aportul metodologiei obiect este de a furniza definirea claselor pentru obiectele persistente la nivel logic. Implementarea acestor clase in SGBDOO furnizeaza nivelul operational.
Anumite SGBDOO-uri se pot cupla cu utilitare metodologice pentru a genera automat definitiile claselor operationale. Un mediu pentru BDOO se bazeaza pe o interfata grafica, interactiva si multiferestre, deoarece ea faciliteaza navigarea si editarea grafului claselor. In general, mediul ofera doua utilitare complementare pentru proiectarea unei BDOO :
. un proiectant de schema
. un browser
Proiectantul de schema permite crearea, modificarea si suprimarea claselor organizate sub forma de graf dupa relatia de mostenire si dupa asociatii. Graful este afisat intr-o fereastra in care proiectantul se poate deplasa in toate directiile pentru a modifica structura si continutul. Continutul unei clase (definitia tipurilor si metodelor) poate fi afisat si el intr-o fereastra la sfarsitul editarii si dupa compilare. In practica, utilitarul permite afisarea si manipularea grafica a tuturor informatiilor pertinente ale unei scheme BDOO, precum si generarea automata a documentatiei.
Browser-ul permite navigarea intr-o BDOO si manipularea continutului sau, reprezentat printr-un graf de obiecte. El poate accesa in mod uniform atat datele utilizator, cat si schema bazei de date, vazandu-le ca obiecte, si plecand de la diferite puncte de intrare, cum ar fi un nume persistent sau un nume de clasa si le poate manipula cu ajutorul metodelor asociate. El este utilizat in mod sistematic in dezvoltarea unei BDOO pentru pozitionare pe obiectele de manipulat.
Utilizarea coordonata a acestor doua utilitare favorizeaza o dezvoltare incrementala a bazei de date, creand pe rand clasele si instantele claselor. Toate clasele aplicatiei se pot adauga la BDOO ca si obiecte si ele pot deveni accesibile si partajate cu alti utilizatori, facilitand reutilizarea.
Dupa ce clasele au fost definite cu ajutorul utilitarelor de mai sus, productia de aplicatii implica in mod esential, interfata grafica utilizator. Un utilitar grafic, orientat pe obiecte, amelioreaza puternic productivitatea dezvoltatorului de interfete utilizator, gratie functionalitatilor urmatoare :
. mecanisme implicite, furnizate de catre clasele predefinite, pentru prezentarea si editarea obiectelor;
. personalizarea acestor mecanisme prin mostenire;
. construirea dialogului prin mesaje si evenimente;
. prototiparea interfetei, care necesita accesul uniform la obiectele interfetei si la cele ale bazei de date.
Aceste functiuni sunt tipice unui generator de prezentari care furnizeaza prezentari de obiecte in mod implicit si le adapteaza in functie de nevoi. Accesul la aceste obiecte se poate specifica prin apelul de metode definite la nivel de clasa utilizator.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1327
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
