Reguli de evaluare a unui SGBDOO

Reguli de evaluare a unui SGBDOO

Asa dupa cum Codd E.F. [3,4] a definit o serie de reguli pentru ca un SGBD sa fie cu adevarat relational, tot la fel un grup de lucru de mare influenta a publicat, sub denumirea de "Manifestul sistemelor de baze de date orientate pe obiecte", o serie de cerinte sau principii pe care trebuie sa le indeplineasca un SGBD pentru a putea fi considerat obiectual [3]. In concordanta cu Manifestul sistemelor de baze de date orientate pe obiecte, sunt definite 13 principii ale SGBDOO , dintre care unele sunt obligatorii iar altele optionale.

Posibilitatea definirii structurilor complexe. O astfel de cerinta presupune capacitatea de a defini structuri complexe plecand de la tipuri de date atomice folosind o serie de tipuri de constructori, iar acestia sa fie ortogonali, in sensul ca fiecare constructor trebuie sa se aplice oricarui obiect. Exemplu, daca folosim constructori de forma SET (TUPLE( )), LIST (TUPLE ( )) atunci trebuie sa avem posibilitatea de a folosi si formele TUPLE (SET ( )) si TUPLE (LIST ( )). Dintre cei mai folositi constructori amintim:

ROW , unde un tip reprezinta un rand sau tuplu cu campurile     de tipurile ;

ARRAY: Tipurile array suporta o metoda "array index" pentru a permite utilizatorilor sa acceseze articolele array (colectiei);

seturi si multiseturi (Sets and multisets) . Obiectele set pot fi comparate utilizand setul de metode traditional <, ≤, =, ≥, >. Totodata, doua obiecte set (avand elementele de acelasi tip) pot fi combinate pentru a forma un nou obiect folosind operatorii     si - (diferenta).

Liste: Operatiile de liste traditionale includ capul de lista (head) care returneaza primul element, coada listei (tail) care returneaza adresa ultimului element din lista; inserare sau adaugare de noi elemente in lista si respectiv excluderea unui element din lista.

Mai exista o serie de operatori, cum ar fi operatorii agregati (COUNT, SUM, AVG, MAX, MIN), si operatori pentru conversia de tipuri (exemplu, pentru conversia unui obiect multiset intr-un obiect set prin eliminarea duplicatelor).

Identitatea obiectului, adica SGBD trebuie sa ofere posibilitatea identificarii, fara ambiguitate, a oricarui obiect din baza de date. In acest sens cu ocazia incarcarii oricarui obiect in baza de date se va recurge la generarea unui identificator unic al obiectului, numit OID.

Incapsularea, presupune faptul ca SGBD trebuie sa dispuna de capacitatea de a incapsula datele si metodele apartinand obiectelor iar utilizatorii pot avea acces la ele doar printr-o interfata ce citeaza o anumita metoda. La randul sau atat metodele cat si datele pot fi definite publice (+), protejate (#) sau private (-).

Tipuri si/sau clase. Cele doua concepte trebuie sa fie ambele prevazute. Primul concept reprezinta un mecanism de verificare pentru acuratetea programelor in timpul compilarii. Al doilea concept reprezinta un mecanism care colecteaza extensiile de obiecte si le defineste implementarea lor. Invers, nu e necesar sa fie doua forme diferite de a exprima tipuri si clase si astfel e posibil sa exprimam un concept in contextul celuilalt.

Clase si/sau tipuri de ierarhii, in contextul mostenirii, evidentiaza faptul ca un SGBDOO trebuie sa asigure ca un subtip sau subclasa sa poata mosteni atributele si metodele de la superclasele sau supertipurile lor.

SGBD trebuie sa ofere suport pentru legarea dinamica, in sensul ca metodele trebuie sa se aplice la obiecte de diferite tipuri iar implementarea unei metode va depinde de tipul de obiect caruia i se aplica. Acest aspect presupune faptul ca sistemul nu poate lega denumirea metodelor pana in momentul executiei (legare dinamica).

SGBD trebuie sa ofere un limbaj de manipulare a datelor LMD cu completitudine de calcul. In acest sens, de exemplu, se apreciaza ca standardul SQL3 poseda completitudine de calcul.

Extensibilitatea multimii tipurilor de date, ceea ce presupune capacitatea de a defini noi tipuri bazate pe cerintele utilizatorilor.

Durabilitatea sau persistenta datelor, ceea ce presupune capacitatea sistemului de a asigura/suporta persistenta datelor. La fel precum si in situatia SGBD conventionale, datele trebuie sa ramana dupa finalizarea aplicatiei care le-a creat. Deci utilizatorul nu trebuie sa deplaseze sau sa copieze explicit datele, pentru a le putea refolosi.

SGBD trebuie sa fie capabil si sa ofere facilitati in ceea ce priveste operarea si gestionarea unor volume mari de date (baze de date de mari dimensiuni).

Asigurarea accesului concurent la aceleasi resurse.

Asigurarea capacitatii de refacere a bazei de date in cazul unor caderi fizice de hardware sau software, asemanator sistemelor conventionale.

Asigurarea unor limbaje de cereri de nivel inalt cu multiple facilitati de integrare a bazei de date.

Manifestul bazelor de date orientate obiect mai face referiri la cateva caracteristici optionale, care sunt interesante si folositoare dar nu esentiale pentru un SGBDOO. Dintre acestea enumeram: mostenirea multipla, distributia datelor intr-o retea, posibilitatea verificarii unui program in timpul compilarii, managementul tranzactiilor si mecanisme pentru managementul versiunii lor.