Bazele de date obiectual relaionaleStandardul SQL3

Modelul obiectual-relaional

Avnd n vedere faptul c att modelul relaional ct i modelul obiectual al bazelor de date prezint avantaje i dezavantaje, n jurul anilor 1990 s-a conturat pentru prima dat ideea de a reuni avantajele celor dou modele, prin extensia modelului relaional cu caracteristici ale modelului obiectual i crearea unui hibrid de model obiectual-relaional. Dup lungi dezbateri, n 1999 grupul de lucru SQL a finalizat i adoptat un subset a modelului de date obiectual-relaional. n 2003 grupul de lucru SQL a oferit suport deplin pentru submodelul obiectual-relaional cunoscut sub denumirea de SQL-3.

Corespunztor acestui model, o baz de date obiectual-relaional constituie un set de clase de nivel nalt, care sunt populate de obiecte tuplu.

Un obiect tuplu este de forma unde: este identificatorul unui obiect, este o valoare tuplu a crei componente pot fi valori atribuite, de genul: valori primitive, seturi, tupluri i referine ctre alte obiecte

Modelul SQL3 standard pentru BDOR

Modelul SQL3 constituie un alt standard de mare referin n materie de gestiunea datelor obiectual-relaionale.Comitetele de standardizare a SQL, ANSI (X3H2) i ISO (ISO/IEC/JTC1/SC21/WG3) au avut o preocupare continu de a aduga noi caracteristici specificaiilor SQL pentru ca acesta s devin suport al bazelor de date obiectual-relaionale (BDOR). Motivaia acestei preocupri a constituit-o tocmai faptul c trstura principal a unui model obiectual, comparativ cu modelul relaional, este bogia sistemului su de tipuri de date cu multiple avantaje oferite. Prima versiune a standardului SQL a fost numit SQL86. Ea era bazat n mare parte pe Limbajul SEQUEL, limbaj fcnd parte din proiectul System R al firmei IBM.

O versiune revizuit a lui SQL86 a fost publicat n 1989, versiune ce adaug i trateaz integritatea referenial.

n 1992 a fost o alt versiune, sub denumirea de SQL92, ce aduce noi caracteristici, cum ar fi: integritatea, domeniile, tabele temporare, noi tipuri de operaii de jonciune, actualizarea schemelor bazelor de date, cu faciliti pentru cursor privind navigarea n rezultatul unei cereri etc. n acest mod, SQL92 a ajuns a fi considerat limbajul standard pentru baze de date relaionale.

Ulterior, printr-o serie de extensii relevante privind modelarea obiectual s-a ajuns la SQL3 (SQL3 2003), considerat a fi standardul pentru baze de date obiectual-relaionale.

n cele ce urmeaz modelul de date utilizat de sistemele de gestiune a bazelor de date obiectual-relaionale (SGBDOR) va fi numit modelul de date SQL3, deoarece este definit prin limbajul de definire a lui SQL-3. El este compatibil cu modelul de date relaional, definit n SQL-2.

Astfel, n modelul SQL-3 este posibil s definim tabele SQL-2, cum ar fi tabela PERSOANA, cu constrngerile de integritate ale lui SQL-2:CREATE TABLE persoana(marcaINTEGER primary key,numeCHAR(30),prenumeCHAR(30),cnpINTEGER,data-nasteriiDATE,localitateaCHAR(25));

Totui, abordarea sugerat n modelul obiectual-relaional nseamn mai nti s se defineasc un tip pentru tupluri, care apoi s-l fac reutilizabil.

n definirea oricrui tip este posibil s folosim constructorii de tip complex, care n mod semnificativ extind noiunea de domeniu prezent n SQL-2. Disponibilitatea constructorilor de tip este prima mare diferen fa de bazele de date relaionale clasice.

Cele mai semnificative caracteristici cu care a venit SQL-3, ca suport pentru structurile orientate obiect sunt:- tipuri definite de utilizatori, regsite anterior sub denumirea de tipuri de date abstracte;- tipuri de rnd;- tipuri referin;- constructori pentru tipuri de rnd i tipuri de referin;- constructori de tip pentru tipuri de colecii (seturi, liste i multiliste);- funcii i proceduri definite de utilizator;- suport pentru obiecte mari (BLOB-uri i CLOB-uri);- valoarea de pe nivelul cel mai nalt a fiecrui obiect, n SQL3, este un tuplu. Tuplurile i seturile pot fi imbricate.

Noi tipuri de date n SQL3

Comparativ cu versiunile precedente, SQL3 ofer posibilitatea utilizrii unor noi tipuri de date, pe care le vom prezenta n cele ce urmeaz:

Tipuri rnd (tuplu). Un tip rnd reprezint o secven de perechi de denumire de cmp i tip de data asemntor definirii unei tabele. Dou rnduri sunt tipuri echivalente dac amndou au acelai numr de cmpuri i fiecare pereche de cmpuri de pe aceiai poziie au tipurile compatibile. Tipul rnd furnizeaz un tip de dat ce poate reprezenta tipuri de rnduri ntr-o tabel, astfel c acestea pot fi stocate n variabile, trecute ca argumente n rutine i returnnd astfel valori dintr-o funcie invocat. Aceast facilitate, de asemenea, permite coloanelor dintr-o tabel s conin valori rnd.

De exemplu:CREATE TABLE persoana(CNPINTEGER,NumeCHAR(30),AdresaROW(localitateCHAR(25), StradaCHAR(25), BloculROW(nrCHAR(4), scaraCHAR(2), etajINTEGER, apartINTEGER)));INSERT INTO persoanaVALUES (1950126400237, VASILE, (Bucureti,Cetate, (11, A2, 1, 79)));

n definirea tabelei PERSOANA, constatm prezena a dou atribute adresa i blocul care sunt de tip ROW i astfel ele pot lua valori rnd.

Tipuri de obiecte mari BLOB i CLOB. Tipurile de obiecte mari (Large Object LOB) pot fi grupate n BLOB-uri i CLOB-uri. Tipurile BLOB (Binary Large Object) i CLOB (Character Large Object) au fost definite ca suport pentru obiecte foarte mari. Instanele acestor tipuri sunt memorate direct n baza de date, mai degrab dect existnd menionate n fiiere externe.

De exemplu:CREATE TABLE persoana(CNPINTEGER,numeVARCHAR(25),profesiaVARCHAR(15),salariuINTEGER,caracterizareCLOB(90K),semnaturaBLOB(2M),pozaBLOB(15M));

Tipurile LOB nu accept anumite operaii cum ar fi mai mare dect sau mai mic dect, ns suport alte operaii cum ar fi cea de regsire, predicatul LIKE etc. Totodat, ele pot suporta o serie de operaii specifice obiectului. Exemplu, pentru o poz: mrete, micoreaz sau rotete poza.

Tipuri de date abstracte (TDA) n SQL3.

Precizm faptul c una din ideile de baz care se afl n spatele posibilitilor obiect aduse de SQL3 este aceea c pe lng tipurile de baza, cum ar fi INT, CHAR, FLOAT etc., construite nuntru definirilor n SQL, pot fi precizate i construite TDA.Tipurile de date abstracte (Abstract Data Type ADT) n SQL3 sunt numite tipuri Definite de Utilizator TDU.Crearea unui astfel de tip separat de un tabel, dei folosind o sintax aproape identic cu cea pentru crearea unui tabel, apare astfel:CREATE TYPE Adresa(localitateaCHAR(20),stradaCHAR(20),numarINTEGER,blocCHAR(3),apartamentINTEGER);

O utilizare a unui astfel de tip poate fi ca un tip de dat coloan n cadrul unei tabele, astfel:CREATE TABLE persoana(CNPCHAR(13),numeCHAR(15),prenumeCHAR(15),adresaAdresa,profesiaCHAR(20));

Tabela PERSOANA este primul nostru exemplu nonrelaional, ea avnd inclus un atribut adresa de tip compus, dup oricare regul rezonabil de compoziie. n acest mod utilizatorii au posibilitatea de a-i defini noi tipuri de date n mod arbitrar, a le stoca i regsi exact ca pe un obiect de alt tip, cum ar fi integer.

Un tip de date abstract definit de utilizator, precizeaz atribute i operaii ncapsulate ntr-o singur entitate. La modul general, un TDA este analog cu definirea unei clase ntr-un limbaj de programare orientat obiect, el specificnd un ansamblu de definiii de atribute i declaraii de rutine. Toate instanele unui TDA partajeaz atributele i rutinele acestuia.Aceste tipuri de date sunt etichetate abstracte pentru c sistemul de baz de date nu are nevoie s tie cum se stocheaz datele TDA i nici cum funcioneaz metodele TDA. El trebuie s tie doar ce metode sunt disponibile i tipurile de date de intrare/ieire pentru acele metode.

n SQL3 atributele sunt considerate atribute stocate si virtuale. Atributele stocate reprezint cazul general de atribute utilizate n multitudinea limbajelor de programare sub denumirea de cmpuri. Atributele virtuale, n alte limbaje de programare le regsim sub denumirea de atribute derivate.Totodat n SQL3 rutinele definite de utilizator (RDU) au semnificaia de metode.

Acum este uor s vedem cum se poate extinde SQL, ca sistem relaional, cu noi tipuri i trsturi necesare pentru ca el s fie calificat ca un sistem obiect:CREATE TYPE Persoanatip AS(PRIVATEData-naterii DATE CHECK(data-naterii

CREATE TYPE BODY Angajattip ASMEMBER FUNCTION ctig RETURN integer ISBEGINReturn salariu + comision;END;

Exemplu anterior arat modul de creare a unui subtip ANGAJATTIP al supertipului PERSOANATIP, recurgndu-se la proprietatea de motenire evideniat prin clauza UNDER (Angajattip UNDER Persoanatip). ntr-o astfel de situaie, subtipul ANGAJATTIP, pe lng proprietile i metodele sale, include i atributele motenite de la supertipul PERSOANATIP. Deci, de reinut faptul c o instan a unui subtip este considerat ca o instan a tuturor supertipurilor sale.

Limbajul SQL3 accept conceptul de substituionalitate adic ori de cte ori este de ateptat o instan a supertipului, n locul acestuia poate fi utilizat o instan a subtipului.Prima instruciune CREATE TYPE din punct de vedere sintactic este similar cu definirea unei tabele n concepia relaional (CREATE TABLE persoana). Deosebirea const n faptul c acum noi definim un alt tip dect o tabel, tip ce conine definiii proprii ale utilizatorului (exemplu tipul Adresa).

Comanda a doua este mult mai interesant. Ea definete un subtip Angajattip al supertipului Persoanatip, ceea ce este specificat prin clauza UNDER.

n ambele cazuri se ilustreaz utilizarea unor atribute publice i private. Atributele data-naterii, salariu i comision sunt private. Atributele private sunt utilizate doar prin intermediul unor rutine/metode imbricate n definirea TDA-ului. n mod implicit, vizibilitatea unui atribut public sau privat este aceea a atributului imediat precedent.Primul atribut a unui TDA, dac nu prevede specificarea vizibilitii, n mod implicit este public.

Definirea tipului ANGAJAT include i definirea unei metode tip funcie cu denumirea Ctig, prin intermediul creia sunt accesate dou atribute private Salariul i respectiv Comision.Referitor la TDU (n contextul SQL3) inem s facem urmtoarele precizri: - tipurile definite de utilizatori i justific utilitatea doar dac sunt incluse sau asociate unor tabele n care urmeaz a fi stocate i obiectele; - tipurile definite de utilizatori sunt necesare n urmtoarele dou principale situaii i anume:

b1) Pentru a specifica cazuri particulare ale domeniilor unor atribute dintr-o tabel, tocmai ca i tipurile primitive de ntregi sau iruri de caractere, astfel:CREATE TABLE LICENIAI(LiceniatREF(Angajattip),UniversitateaCHAR(20),FacultateaCHAR(25),LocalitateaCHAR(20));

Se poate observa c sintaxa instruciunii CREATE TABLE este similar cu sintaxa crerii unei tabele obinuite, cu unica deosebire c n definirea atributului Liceniat se specific domeniul ca fiind un tip complex (ANGAJATTIP). Tipul REF (Angajattip), tipul referin, precizeaz faptul c valoarea asociat atributului Liceniat trebuie s fie un OID a unui obiect de tip ANGAJATTIP.

b2) Un TDU poate fi folosit pentru a specifica tipul unei tabele complete. Acest lucru se realizeaz tot cu ajutorul instruciunii CREATE TABLE ns ntr-un alt mod. n acest caz, n loc de enumerarea coloanelor/atributelelor unei tabele se recurge la simpla precizare/citare a TDU. Aceasta nseamn c toate tuplurile tabelei trebuie s aib structura specificat de TDU.

Exemplul 1. Putem crea o urmtoare tabel bazat pe o definire prealabil a tipului, astfel:CREATE ANGAJAT OF ANGAJATTIP;n acest mod a fost creat tabela ANGAJAT plecnd de la un TDU numit ANGAJATTIP. Tabelele construite via CREATE TABLE ... OF ... sunt numite tabele tip. Rndurile unei tabele tip sunt considerate a fi obiecte.

Exemplul 2. Considerm tabela PERSOANA creat anterior. n actualul context, ea poate fi descompus n dou definiri, de forma:CREATE ROW TYPE persoanatip(MarcaINTEGER primary key,NumeCHAR(30),PrenumeCHAR(30),CnpINTEGER,Data-nasteriiDATE,LocalitateaCHAR(25));CREATE TABLE persoana of type persoanatip;

ntr-o astfel de situaie, tipul PERSOANATIP poate de asemenea fi utilizat i n definirea altor tabele, cum ar fi:CREATE TABLE student of type persoanatip;CREATE TABLE profesor of type persoanatip;

De remarcat faptul c n legtur cu metodele sau aa-numitele rutine definite de utilizator (UDR) exist o adevrat filozofie sub aspectele elaborrii lor n diferite limbaje de programare sau n legtur cu clasificarea acestora. Toate acestea comport anumite particulariti n funcie de limbajul de programare folosit, versiunile acestuia sau n funcie de sistemul de gestiune a bazei de date obiectual-relaional (SGBDOR) care le implementeaz. Ca o cerin, un SGBDOR trebuie s ofere o flexibilitate, sporit n ceea ce privete permisiunea ca rutinele UDR s returneze valori complexe, care s poat fi manipulate mai departe, cum ar fi tabelele. Totodat, un SGBDOR trebuie s ofere suportul pentru suprancrcarea denumirilor funciilor cu scopul de a simplifica dezvoltarea de aplicaii. n SQL metodele pot fi de tip procedur sau funcie, ca i n alte limbaje de programare. Ele la rndul lor pot fi clasificate ca metode constructor, de tergere sau de manipulare (denumirea acestora sugereaz i scopul fiecreia). Metodele pot fi definite complet n limbajul SQL sau ntr-un alt limbaj de programare standard, cum ar fi C/C++. n situaia n care definirea metodelor se realizeaz n SQL, codul metodei va fi ncadrat ntr-un bloc BEGIN ................. END iar n final va fi stocat mpreun cu schema bazei de date n dicionarul bazei de date.

Dac corpul metodei este scris n limbajul C se va recurge la specificarea unei clauze externe care va identifica codul compilat stocat ntr-un fiier al sistemului de operare. De exemplu, dac am dori s efectum o prelucrare a pozei persoanelor stocate n baza de date i cunoscnd faptul c limbajul SQL nu poate realiza acest lucru am fi nevoii s utilizm o metod furnizat din exterior, de forma:

METHOD poza ( ) RETURN BOOLEANCREATE METHOD poza ( ) FOR persoanaLANGUAGE CEXTERNAL NAME file:/home/admin/poza;

ntr-o astfel de situaie, definirea tipului persoana include doar semntura metodei nu i corpul acesteia. Actuala definire este dat folosind instruciunea CREATE METHOD, care este asociat cu tipul persoana prin clauza FOR. Instruciunea precizeaz faptul c metoda este scris n limbajul C i totodat indic mecanismelor SGBD legtura cu acea metod i unde poate fi gsit spre a fi lansat n execuie.

Limbajul SQL3 ofer aceleai operaii ca i SQL2 pentru integrarea i actualizarea tabelelor ns vine i cu anumite extensii pentru manipularea obiectelor, cum ar fi cele referitoare la invocarea unor metode definite de utilizatori.Exemplul 1. Se cere s se listeze numele, prenumele i ctigul angajailor care au studii superioare:SELECT A. Nume, A. Prenume, A. ctigFROM angajat AWHERE A. studii = superioare;n cadrul cererii se observ c este invocat i funcia Ctig definit de utilizator. Metoda era invocat n cadrul listei int a frazei SELECT.

Exemplul 2. Se cere s se listeze marca, numele i prenumele tuturor angajailor ce au un ctig mai mare de 2000 euro:SELECT A. marca, A. nume, A. prenumeFROM angajat AWHERE A. ctig > 2000;n acest caz metoda Ctig este invocat n construcia unui filtru (A. ctig > 2000).

Metodele n cadrul unui tip pot fi definite nc din faza de proiectare a bazei de date sau pot fi adugate n timp. n cele ce urmeaz vom ilustra modul n care poate fi adugat o nou metod la tipul ANGAJATTIP. n primul rnd este necesar adugarea unei declaraii la structura deja existent, astfel :ALTER TYPE AngajattipADD METHOD constructorangajat (data-nasteriiDATE,CNPINTEGER,marcaINTEGER,prenumeCHAR(15),numeCHAR(15),localitateaCHAR(20),stradaCHAR(20),numarINTEGER,blocCHAR(3),apartamentINTEGER,salariuINTEGER,comisionINTEGER,studiiCHAR(15),sexCHAR(1),RETURN Angajatip;

Urmeaz s definim corpul metodei, astfel:CREATE METHOD constructorangajat (data-nasteriiDATE,CNPINTEGER,marcaINTEGER,prenumeCHAR(15),numeCHAR(15),localitateaCHAR(20),stradaCHAR(20),numarINTEGER,blocCHAR(3),apartamentINTEGER,salariuINTEGER,comisionINTEGER,studiiCHAR(15),sexCHAR(1),FOR angajattipRETURN angajatip

LANGUAGE SQLBEGINRETURN NEW angajattip ( )data-nasterii(data-nasterii),CNP(CNP),marca(marca),prenume(prenume),nume(nume),localitatea(localitatea),strada(strada),numar(numar),bloc(bloc),apartament(apartament),salariu(salariu),comision(comision),studii(studii),sex(sex),END;

Compararea SGBDR cu SGBDOR

Comparnd SGBDR cu SGBDOR pot fi desprinse urmtoarele aspecte:- Un SGBDOR este SGBD relaional cu extensiile SQL3;- Extensiile SQL3, includ: tipuri rnd, tipuri definite de utilizator, rutine definite de utilizator, polimorfismul, motenirea, referine, identitatea obiectului, tipuri colecii (set, liste, ARRAY), noi construcii de limbaj ce fac SQL3 complet relaional, triggers i suport pentru obiecte mari Binary Large Objects (BLOBs) i Character Large Objects (CLOBs). n acest mod putem construi tipuri de date mult mai complexe plecnd de la tipuri atomice i tipuri definite de utilizatori utiliznd constructori de tip. Exist constructori de tip i operatori corespunztori tuturor tipurilor de date.- Prin multitudinea tipurilor de date precum i posibilitatea implementrii proprietii de motenire, SGBDOR ne ofer faciliti privind proiectarea unei structuri de baz de date mai apropiat de starea natural a lucrurilor i totodat mai eficient;- Un SGBDR se caracterizeaz printr-o simplitate i stabilitate sporit fa de un SGBDOR, ceea ce i confer o mai mare uurin de folosire;

- Ambele SGBD se caracterizeaz printr-o simplitate de dezvoltare datorit faptului c asigur independena datelor fa de programare (aplicaii);- Pentru SGBDR exist standardul SQL2 (ANSI X3H2), iar pentru SGBDOR exist standardul SQL3;- SGBDR apar ca produse software foarte mature, pe cnd SGBDOR sunt produse software nc n formare/perfecionare;- n ceea ce privete suportul pentru programare, n cazul limbajelor de programare aparinnd SGBDOR apare posibilitatea reutilizrii codului, datorit proprietii de motenire, ceea ce duce implicit la reducerea efortului de programare. - SGBDOR ncearc s adauge tipuri mai bogate de date unui SGBD relaional; - Un SGBDOR este indicat pentru aplicaii ce implic colecii mari de date, obiecte ce pot avea structuri complexe/bogate i relativ mari.