. Topici de Modelare Avansate In Baza de Date
INTRODUCERE
MOTIVAREA ALEGERII TEMEI IMPORTANTA TEMEI IN ACTUALITATE
La inceputul anilor '50, singurul mod de a programa un calculator era folosirea codului masina,secvente ordonate de cifre binare care ii spuneau masinii de calcul ce are de facut.Complexitatea programelor crescand ,oamenii s'au gandit sa creeze un program in cod masina care sa stie sa interpreteze secvente de caractere si sa le transforme la randul lor in cod matematicienii si inginerii electronisti care au creat primele masini electronice de calcul.
Progamele in ansamblare au inceput cu timpul sa devina din ce in ce mai sofisticate,incat limbajul de ansamblare s'a dovedit la randul sa insuficient. Nivelul sau era foarte jos,apropiat de masina. A aparut primul limbaj de programare de inalt nivel. Au inceput sa fie elaborate programe care contineau seturi de instructiuni complexe pentru operarea cu hardware-ul. Utilizatorii de calculatoare au inceput sa apara si dintre nespecialistii in electronica: software-ul executat era mai inteligent in sensul ca isi asuma responsabilitatea pentru relatia cu hardware-ul.
Experienta anilor de programare a dus la stabilirea unor reguli generale nescrise cu privire la modalitatea de a realiza un program performant. Oamenii au ajuns la concluzia ca orice problema ,oricat de complexa ar fi,poate fi descompusa in subproblemerezolvabile mult mai usor decat problema initiala. Asa au aparut modulele si programarea modulara.S-a stabilit apoi ca unele practici de programare sunt folositoare si altele,dimpotriva,sunt neproductive si ar trebui evitate ,chiar excluse. S-a ajuns la un set de instructiuni necesar si suficient pentru crearea oricarui tip de program si la trei structuri :structura secventiala, cea alternativa si cea repetitiva.Pornind de le aceste structuri se pot crea programe clare si de o complexitate controlabila. Urmatorul si ultimul concept de programare este programarea orientata pe obiecte care foloseste conceptul de obiect ca entitate esentiala si indivizibila a programului ,gruparea obiectelor de acelasi fel facande-se in clase.
Obiectele au incluse (incapsulate) in interior atat datele continute cat si codul actiunilor pe care le pot executa.Obiectele interactioneaza unele cu altele prin mesaje,comunicandu-si actiunile pe care le au de executat.De asemenea ,in cadrul programarii obiectuale au aparut conceptele de mostenire si polimorfism care duc spre reutilizarea codului.Aceasta reutilizare este idealul in ceea ce priveste programarea ;inca de la inceputuri programatorii realizau ca produsele program cele mai bine facute ar fi acelea in care programatorii nu fac decat sa asambleze componente deja create.
Se creaza biblioteci de clase reutilizabile ,generice,din care programatorii isi vor putea crea propriile clase si obiecte.In ultimul deceniu a capatat o mare importanta sistemul bazelor de date orientate-obiect.Sistemele orientate obiect isi au originile in limbajele de programare orientate obiect si sunt privite de unii oameni ca fiind un concurent serios pentru sistemele relationale ,cel putin pentru anumite tipuri de aplicatii.
De ce este un asa de mare interes in sistemele orientate obiect? Se stie ca sistemele clasice SQL sunt inadecvate intr-o multime de directii.Cateva dintretrasaturile de care avem nevoie in SGBD exista de multi ani in limbajele de programare orientate obiect cum ar fii C++ si Smalltalk,si deci este natural sa investigam ideea de incorporare a acestor trasaturi in sistemele de baze de date.Si multi cercetatori au facut exact acest lucru.
Ideea de baza este aceea ca utilizatorii trebuie sa fie capabili sa se descurce cu obiecte ,acestea avand mai mult un corespondent in lumea reala.
Acum ,marirea nivelului de abstractizare este un scop ,si paradigma obiectuala a fost de succes in atingerea obiectivului in domeniul limbajelor de programare .Ideea manipularii unei baze de date ce este facuta din "obiecte complexe" in locul manipularii "relvar-uri" si "inserari de tupluri" si "chei straine" este, evident,mai atractiva din punctul de vedere al utilizatorului-cel putin la prima vedere.
Desi limbajele de programare si gestiunea bazelor de date au multe in comun ,ele lucreaza diferit din anumite puncte de vedere importante.Mai exact:
Un program de aplicatie -prin definitie -este destinat sa rezolve anumite probleme specifice
Dimpotriva ,o baza de date -prin definitie-este destinata sa rezolve o varietate de probleme diferite
In mediul programarii aplicate ,bagand multa "inteligenta" in obiecte complexe este clara o idee buna:reduce cantitatea de cod care trebuie scrisa pentru a se folosii aceste obiecte,imbunatateste productivitatea programatorului s.a.m.d. in mediul bazelor de date;din contra,impachetand multa inteligenta in baza de date poate fii sau nu o idee buna:ar putea simplifica unele probleme ,dar in acelasi timp ar putea crea altele mai dificile sau chiar imposibile.Multi cred ca sistemele obiect reprezinta un salt important in tehnologia bazelor de date.In particular se crede ca tehnicile orientate obiect sunt aproape de alegerea din arii de aplicatie "complexe" cum ar fii:
CAD/CAM-Proiectare si manufacturare asistata de computer
CIM-Manufacturare cu computer integrat
CASE-Inginerie soft cu ajutorul computerului
GIS-Sisteme informationale geografice
Stiinta si medicina
Depozite de date si Data mining
Si asa mai departe (nu sunt acestea toate domeniile in care QSL-ul clasic tinde sa aiba probleme).Desigur au fost numeroase lucrari tehnice cu aceste chestiuni,de'a lungul anilor ,si,mai recent,cateva produse comerciale au intrat pe piata.Visual FoxPro se incadreaza in toate conceptele de mai sus:este un mediu de programare vizual orientat pe obiecte,specializat pe lucrul cu baze de date.Pentru un programator ce doreste sa realizezeo aplicatie orientata spre lucrul cu baze de date de dimensiuni medii/mari,cooperarea cu severe SQL sau Oracle,sau schimbul de date cu exteriorul prin intermediul unui server Web in Internet,Visual FoxPro va fi solutia.
Visual FoxPro:
poate fi folosit la oricare dintre cele trei nivele ale arhitecturii DNA
poate oferi interfata utilizator.formularele si componentele lor sunt obiecte,cu o intreaga paleta de proprietati,metode si evenimente.Controalele ActiveX pot fi folosite pe form-uri si pot fi chiar derivate in subclase pentru a le extinde functionalitatea
poate fi folosit pentru a scrie componente din stratul de mijloc.Accesarea datelor si manipularea acestora,interogarea(querying) si crearea de rapoarte au fost de mult timp unele din punctele forte ale limbajului
poate fi folosit la crearea de componente COM consistente ce pot fi apelate de pe orce server Internet
are integrate instrumente deosebit de rapide de regasire a datelor care pot accesa imense cantitati de date
Ultima versiune a Visual FoxPro,avand numele de cod Tahoe,a aparut odata cu lansarea ultimei versiuni a pachetului Microsoft Visual Studio-un instrument oferit de Microsoft programatorilor pentru a crea solutii scalabile la mii de utilizatori ,pentru a crea aplicatii distribuite bazate pe componente;el integreaza programarea client/server si Internetul prin Web.
Pe langa suportul complet pentru Transaction Server ,Tahoe suporta standardul Active Documents,permitand formularelor Visual FoxPro sa fie rulate intr-un browser Internet.Acest lucru ofera o cale simpla de a migra aplicatiile existente pe Wep.
In aceasta lucrare vom examina in detaliu sistemul bazelor de date orientate obiect ,vom introduce si explica conceptele de baza ,vom analiza aceste concepte in profunzime si vom oferii cateva opinii privind convenabilitatea incorporarii acestor sisteme in sistemele de baze de date ale viitorului.
CAPITOLUL I
SISTEME RELAȚIONALE EXTINSE
1.1 Introducere
În multe domenii noi, aplicarea SGBDR este determinată de restricțiile impuse de modelul relațional. Dintre acestea amintim : omogenitatea, ordonarea înregistrărilor, atomizarea atributelor etc. Siguranța aplicațiilor necesită limbaje cu o mare putere de expresie, cum sunt SQL sau algebra relațională. Modelul orientat pe obiecte este o cale de eliminare a acestor restricții dar el sacrifică multe din avantajele modelului relațional, în special cele legate de procesul de interogare. În continuare vor fi prezentate extensii ale modelului relațional ce ge
neralizează aplicabilitatea modelului și care respectă fundamentele modelului relațional.
Modalitățile de extindere a sistemelor relaționale se referă, pe de o parte, la limbajele de interogare și accesare a datelor, ca de exemplu limbajul de prelucrare a datelor logice DATALOG, ce permite interogări recursive, și pe de altă parte, la modelul relațional "nested" (modelul n-relații) ce permite relații care nu sunt în prima formă normală.
1.2 Sisteme extensibile
Sistemele relaționale au un sistem de tipuri simple. Tipurile atomice conțin tipul integer, real, boolean și string și servesc numai la definirea tipului tuplu. O relație este o colecție omogenă de tupluri.
Sistemele comercializate au mai adăugat tipurilor atomice câteva elemente suplimentare cum ar fi : de tip dată (an,lună,zi), de tip devize sau intervale de valori cu operatorii elementari de utilizare pentru aceste tipuri. Se poate, de exemplu, converti o dată din format englez într-o dată de format francez. Se poate calcula și diferența între două date și obținerea rezultatelor în zile. Cu toate aceste extensii suplimentare, numeroase aplicații necesită utilizarea de alte tipuri noi, adaptate unor nevoi specifice ale unei aplicații. Conceptul de tip abstract răspunde la aceasta, permițând definirea de noi tipuri cu operații asociate. Elementele esențiale ale acestui concept le vom aminti în continuare.
Un tip abstract este definit de o structură de date și de o mulțime de operații ce permit să regăsească sau să modifice informația referitoare la această structură. Prin urmare un tip abstract cuprinde atât datele și cât și operațiile ce acționează asupra acestor date. Operațiile constituie interfața tipului abstract. Procedând în acest fel, atributele unei relații pot lua ca domeniu valori ce corespund unui tip abstract.
Modelul relațional astfel constituit este mult mai bogat. Totuși, trebuie observat că aceste tipuri sunt atașate numai atributelor unei relații și că ele nu constituie un mecanism general de construcție de tipuri așa cum arată exemplul următor.
Fie o aplicație de fond funciar. O zonă este definită printr-o dată care are două elemente : un dreptunghi ce închide zona și un poligon convex care reprezintă zonă. Pentru simplificare, se face referire la regiuni convexe, fără gropi.
Pentru a defini un tip parcelă este nevoie de un limbaj de definire. Se va folosi o sintaxă de următoarea formă :
type parcelă=[ rec:dreptunghi, contur: poligon ]
type dreptunghi=[ sv:punct, ne:punct ]
type punct=[ x:float, y:float]
type poligon= array of punct
O parcelă este un tuplu cu două câmpuri <<rec>,<contur>>. La fel, un dreptunghi este definit printr-o dată care are două puncte numite <<sw>,<ne>> și un punct este determinat prin coordonatele sale. În sfârșit, un poligon este declarat ca un tablou de puncte. Această reprezentare a unui poligon nu este decât una din soluțiile posibile. Administratorul bazei de date va fi acela care va alege definiția cea mai potrivită pentru aplicație. După ce au fost definite tipurile de date, trebuie precizate și operațiile care se aplică acestor tipuri. Aceste operații sunt văzute ca funcții cărora li se definește “signatura”, adică tipul argumentelor de intrare și de ieșire. Se pot astfel defini funcțiile următoare :
rec(zonă) : dreptunghi
contur(parcelă) : poligon
sv(dreptunghi) : punct
ne(dreptunghi) : punct
x(punct) : float
y(punct) : float
surface(parcelă) : float
fereastra(parcelă,dreptunghi) : parcelă
intres(parcelă, parcelă) : parcelă
intersrect(dreptunghi, dreptunghi) : dreptunghi
ein(poligon, punct) : booleaunghi, dreptunghi) : dreptunghi
ein(poligon, punct) : boolean
inter(parcelă, parcelă) : boolean
inrect(dreptunghi, dreptunghi) : boolean
intrerect(dreptunghi, dreptunghi) : boolean
Semnificația acestor funcții este evidentă. Primele 6 ilustrează faptul că un atribut poate fi văzut ca o funcție. Funcția <<fereastra>> are două argumente : o zonă și un dreptunghi. Funcția <<inters>> calculează intersecția a două zone și rezultatul este o zonă căci regiunile sunt convexe.
În cazul în care zonele sunt unele oarecare, intersecția a două zone nu este în mod necesar o zonă, dar poate fi o mulțime de zone. Funcția <<ein>> indică dacă un punct este în interiorul unei zone, în timp ce funcția <<inter>> verifică dacă intersecția a două zone nu este vidă. La fel, <<inrect>> și <<interrect>> verifică dacă un dreptunghi este conținut în interiorul altui dreptunghi și dacă două dreptunghiuri au o intersecție nevidă.
Plecând de aici, o schemă relațională extinsă poate fi declarată utilizând o sintaxă de tip SQL :
create table Oraș(nume-oraș:string, plan-oraș:zonă)
create table Monument(nume-mon:string,loc:punct)
create table Pădure(nume-pădure:string,plan-pădure:zonă)
Într-o astfel de schemă, atributele <<plan-oraș>>, <<loc>> și <<plan-pădure>> fac referire la noi tipuri. Dacă r1 desemnează o instanță de tip zonă, atunci tuplul [nume-oraș:Craiova,plan-pădure:r1] este o instanță a tabelei Oraș.
Folosind această schemă utilizatorul poate exprima următoarele cereri :
Care sunt monumentele orașului Craiova?
Care sunt orașele care au pe teritoriul lor o pădure mai mare de 100 ha ?
Care sunt planurile orașelor care au o intersectare cu dreptunghiul 10:20, 20:60 ?
Fără a anticipa ceva despre expresia limbajului de cereri, nici despre procedura de construcție a răspunsului, se poate remarca, cel puțin, că toate aceste cereri utilizează funcțiile care sunt asociate declarațiilor de tipuri. De exemplu, un monument răspunde la prima întrebare dacă coordonatele sale sunt situate în interiorul dreptunghiului orașului Craiova.
Pentru a oferi, plecând de la un sistem relațional existent, un sistem de tipuri extensibil, trebuie să rezolvăm mai multe probleme :
Cum se definește un tip abstract? Aceasta are în vedere nu numai structura tipului, dar și operațiile ce-i sunt asociate
Cum să implementezi aceste tipuri într-un sistem relațional de baze de date? Sistemele relaționale nu furnizează funcționalitățile pentru a utiliza aceste noi tipuri. Ele pot numai stoca elementele necesare specificărilor acestor noi tipuri și valoarea instanțelor
Este deci necesar să definim mecanismele care transformă un tip abstract într-o interpretare internă proprie bazei de date
Cum să modificăm limbajele relaționale pentru această extensie? În particular, SQL poate fi extins prin a încorpora o nouă structură de tipuri și operații specifice acestor tipuri?.
În sistemele relaționale tradiționale, utilizatorul poate defini indecși ce sunt construi\i pentru tipuri atomice. Se pot prevedea indecși pentru câmpurile descrie de noile tipuri. De exemplu, putem avea un index spațial pentru monumente, plecând de la tipul punct.
1.2.1 Utilizarea tipurilor abstracte
Implementarea unui tip abstract într-un sistem relațional cuprinde două părți :
prima descrie modul în care sunt reprezentate componentele tipului în baza de date,
a doua definește funcțiile și/sau operațiile aplicabile instanțelor tipului.
Pentru a realiza această sarcină sunt posibile diferite soluții. Una ar consta în furnizarea simultană a definiției tipului și a mecanismelor de conversie între reprezentările interne și externe ale tipului. Reprezentarea internă corespunde codajului tipului în baza de date și reprezentarea externă este cea care se referă la limbajul de aplicație.
Astfel tipul dreptunghi poate fi definit prin comanda :
create type dreptunghi
(Internallength=16,
InputProc=Char to Rectangle,
OutProc =Rectangle to Char,
Default =“ “)
În acest exemplu s-a decis că reprezentarea externă a unui dreptunghi este un șir de caractere ce conține cele două puncte opuse ale dreptunghiului.Codificarea “20,50:10,70” corespunde unui dreptunghi ale cărui vârfuri au drept coordonate (20,50) și (10,70). Procedura <<ChartoRectangle>> ia la intrare un șir de caractere de această formă și închide o reprezentare internă a dreptunghiului codificată pe 16 octeți. În mod invers, procedura <<RectangletoChar>> ia reprezentarea internă stocată în baza de date și o convertește într-o reprezentare externă, accesibilă programului de aplicație. Rolul acestor proceduri de conversie intervine în momentul în care este efectuată interpretarea limbajului de interogare.
1.2.2 Implicații asupra limbajului de interogare
Introducerea de tipuri abstracte într-un sistem relațional provoacă modificări asupra limbajului de interogare. Dacă luăm ca limbaj de referință SQL-ul și, ne limităm la o submulțime a lui, se pot examina consecințele. Pentru aceasta, se poate considera o expresie generală de selecție SQL de forma :
select X1.A1, X2.A2, …, Xk.Ak
from r1 X1, …, rn Xn
where F(X1,…,Xn)
unde F este o expresie booleană și a fost construită plecând de la termenii booleeni SQL și de la operatorii logici elementari and, or și not ; Xi,(i=1,…,n) sunt variabile ce arată tuplurile asociate relațiilor ri și Aj(j=1,…,k) sunt nume de atribute.
Pentru a extinde limbajul de interogare, ne putem baza pe următoarele principii :
Să considerăm o operație asociată unui tip abstract și signatura sa f:t→t’. Această signatură exprimă faptul că funcția f are ca argument de intrare o variabilă de tip t și dă un rezultat de tip t’. Dacă t’ este un tip atomic, atunci în orice expresie SQL în care există o expresie atomică compatibilă cu t’, se poate substitui acestei expresii o expresie de forma f(x) în care x este de tipul t.
Al doilea principiu este cel al compunerii funcțiilor. Dacă f și g sunt două funcții f:t→t’ și g:t’→t”, atunci g(f) este o expresie a limbajului cu signatura : t→t”
Dacă tipul t’ al funcției f:t→t’ este o mulțime de tupluri, atunci peste tot pe unde apare o expresie de relație, se poate substitui o expresie funcțională cu f.
Prin aplicarea acestor principii asupra exemplelor de cereri date mai sus, se obțin :
1. Care sunt monumentele orașului Craiova?
Pentru a construi răspunsul, se verifică dacă coordonatele unui monument sunt în interiorul conturului unui oraș :
select X.nume-mon
from Monument X, Oraș Y
where Y.nume-oraș=“Craiova” and e în (contur(Y.plan-oraș)
X. loc)
2. Care sunt orașele care au pe teritoriul lor o pădure mare de 100 ha?
select Y nume-oraș
from Oraș Y, Pădure Z
where suprafața (intersecție(Y,plan-oraș,Z,
plan-pădure))100
3. Care sunt planurile orașelor care au o intersecție cu dreptunghiul 10:20, 20:60 ?
select Y plan-oraș
from Oraș Y
from interrect (rec (Y, plan-oraș), “10:20:60 “)
În exemplul prezentat la începutul acestui paragraf, noile tipuri de date introduse nu făceau apel în mod explicit la constructorul mulțime de tupluri. În consecință, exemplele de cereri nu au utilizat cel de-al treilea principiu de extensie și această posibilitate nu a fost exploatată aici.
1.2.3 Interpretarea limbajului extins
Urmărind implementarea tipurilor abstracte, interpretarea limbajului de interogare . face apel la conversii între reprezentarea internă și externă a tipului pe care o vom descrie în continuare .
Operațiile ce se pot aplica unui tip sunt definite într-un limbaj de programare, argumentele de intrare și de ieșire sunt de asemenea exprimate în sistemul de tipuri ale limbajului care nu ține seama de reprezentările interne ale acestor tipuri în SGBD. Când un limbaj de interogare invocă o funcție f, această funcție nu se poate interpreta prin SGBD și trebuie căutată imaginea fb a funcției f în SGBD. Există două soluții posibile pentru a construi această funcție fb. Prima constă în implementarea codului funcției f în reprezentarea internă a SGBD. Pentru a face acest lucru se presupune că programatorul are cunoștințe foarte precise despre structurile interne ale acestui tip. Această soluție are avantajul să fie eficace pentru că ține seama direct de reprezentările interne. În schimb, ea este rezervată numai specialiștilor. A doua soluție are meritul de a putea fi generalizată și este independentă de utilizarea de un programator specializat.
Fig. 10.1 Diagrama de conversie între tipuri
Diagrama de echivalență dată în figura anterioară stabilește corespondența între tipurile externe (nivel limbaj de programare) și tipurile externe (nivel SGBD). Unui tip extern t facem să-i corespundă tipul său intern tb, indicele b indicând că suntem la nivelul bazei de date. Dacă in[t] și out[t] sunt procedurile de conversie respectiv ale lui t către tb și invers, diagrama de conversie ne arată că f și fb se obțin prin compunere de funcții :
fb= in[t] f out[t]
f = out[t] fb in[t]
Acest demers este simplu și se bazează numai pe implementarea procedurilor de conversie. De exemplu, funcția intersecție se traduce :
intersection b(O.Zona1,O.Zona2) = in[Zona]
(intersecție (out [Zona](O.Zona1),out [Zona](O.Zona2))
în care O.Zona1 și O.Zona2 sunt variabile ce arată instanțe ale tipului Zonă.
Acest demers bazat pe conversie de tipuri poate conduce la performanțe slabe dacă prețul este prea mare. Totuși, câteva optimizări sunt posibile. De exemplu, în cazul compunerii de funcții nu este necesar să se aplice în mod sistematic transformările “in” și “out”.
Dacă “in” și “out” sunt cele două funcții generice de bază care permit generarea interfeței între baza de date și limbajul de programare al aplicației, este indispensabilă de asemenea o funcție asociată expresiilor constante ale limbajului de interogare; expresia constantă a limbajului de interogare este o expresie care arată, de exemplu, instanța unui tip dat plecând de la valorile atomice. De exemplu, expresia “10,20:20,60” este o expresie constantă ce arată un exemplu de tip Dreptunghi.
Se va numi con[t] funcția generică ce asociază unei funcții constante reprezentarea internă a acestui tip t. Cu ajutorul acestor elemente se poate efectua interpretarea limbajului de interogare. Fie ca exemplu una din cererile prezentate mai sus.
Care sunt planurile orașelor care au o intersecție cu dreptunghiul “10,20:20,60” ?
select Y.plan-oraș
from Oraș Y
from interrect(rec(Y.plan-oraș), “10,20:20,60”)
Această cerere este tradusă în :
select out[Regiune](Y.plan-oraș)
from Oraș Y
from interrectb(recb(Y.plan-oraș),con[Dreptunghi]
("10:20,20:60"))
Expresia out[Regiune] transformă reprezentarea internă a unei regiuni și echivalentul ei la nivelul limbajului de aplicație. Funcțiile interrectb și recb sunt derivate din funcțiile interrect și rec după regulile definite mai sus. În plus, funcția con[Dreptunghi] transformă expresia constantă într-o reprezentare internă a unui dreptunghi. Acest demers necesită o analiză completă a tipurilor cererii.
1.2.4 Metode de acces și de extindere
Paragrafele precedente au prezentat soluțiile folositoare pentru a îmbogăți sistemul de creare de noi tipuri și ca să definească operațiile ce trebuie asociate acestor noi tipuri.
Dacă bazele de date sunt utilizate pentru a crea noi aplicații, ele trebuie de asemenea să răspundă unor cerințe de acces eficiente la aceste date.
Cererea de metode de acces specializate este cu siguranță consecința acestei evoluții. Aceasta înseamnă că, conceptul de extensibilitate nu trebuie să se refere numai la tipurile de date. În particular, mecanismele de indexare trebuie să poată fi adaptate noilor tipuri de date. Dacă se consideră schema propusă la începutul acestui capitol, pot să se aibă în vedere diferite cazuri de indexare.
Prin relația Oraș, un index despre numele orașului intră în categoria a ceea ce toate sistemele de baze de date știu să facă cu un B-arbore. În schimb, dacă vrem un index despre suprafața orașului, problema este mult mai complexă. Ca să ajungem la acest lucru este suficient să calculăm suprafața fiecărui oraș utilizând funcția <<suprafața>> și de a lua rezultatul ca index.De câte ori va fi modificat un oraș sau va fi introdus un oraș nou, va trebui recalculată suprafața și reactualizat indexul.
Folosirea acestor indecși baza\i pe o funcție și nu pe un atribut atomic, poate fi realizată bazându-ne pe procedurile de indexare furnizate de SGBD. Extensiile ce trebuie făcute sunt limitate și se bazează numai pe un mecanism de declanșare de reactualizări.
În sfârșit, pot fi dezvoltate tehnici de indexare mult mai complicate pentru a trata tipuri de date cu caracter geometric.
Au fost dezvoltate de exemplu structuri specializate cu acest efect : R-arborii. Datorită acestui tip de indexare, întrebări de forma “care sunt orașele situate într-o regiune dată ?” sunt tratate într-un mod eficient. În acest caz extensiile ce trebuie făcute sistemului sunt mult mai importante.
Fig. 1.2 Extensie autogenă
Nu este vorba de o simplă adaptare sau reutilizare de mecanisme deja implementate, trebuie furnizată totalitatea procedurilor de acces și de gestiune de memorie. Aceste două nivele de complexitate în extensiile posibile sunt ilustrate în figurile următoare. Ele scot în evidență diferența între o metodă de indexare autogenă (primul caz) sau exogenă (al doilea caz).
Fig 1.3 Extensie exogenă
În cazul unei metode autogene tehnicile de indexare sunt furnizate de SGBD. De exemplu, indexul dat de suprafață va fi creat sub forma unui B-arbore; numai un mecanism de observare va fi adăugat și va provoca reactualizarea indexului.
Într-o metodă exogenă, extensia are loc în același timp atât asupra structurii de acces cât și asupra sistemului de observare pentru a declanșa reactualizările.
1.2.5 Concluzii despre extinderi
Au fost prezentate în acest paragraf elementele cele mai importante privind extensibilitatea. Aceasta se bazează pe faptul că plecând de la un sistem existent este posibil să fie oferite noi funcționalități. Aceste extinderi au în vedere sistemele de tipuri, limbajul de interogare și structurile de acces. Alte aspecte nu au fost abordate ca de exemplu consecințele asupra tehnicilor de optimizare ale limbajului de interogare sau asupra metodelor de gestiune ale concurenței.
1.3 Modelul relațional "nested"
Definirea primei forme normale necesită ca toate atributele să aibă domenii atomice. Un domeniu este atomic dacă elementele domeniului sunt considerate a fi unități indivizibile. De exemplu, mulțimea întregilor este un domeniu atomic dar mulțimea tuturor mulțimilor de întregi este un domeniu neatomic. Diferența este aceea că în mod normal nu se consideră că întregii au subpărți, dar se consideră că mulțimea întregilor are subpărți. Dacă ar fi considerat fiecare întreg ca fiind o listă ordonată de cifre binare atunci domeniul tuturor întregilor poate fi considerat neatomic. Astfel, important în prima formă normală (1NF) nu este domeniul însuși, ci modul în care se folosește domeniul elementelor din baza de date.
Vizualizând baza de date ca o mulțime de înregistrări, utilizatorii noilor aplicații vor vedea baza de date ca o mulțime de obiecte. Aceste obiecte pot avea nevoie de mai multe înregistrări pentru reprezentarea lor. Aceasta va părea o interfață ușor de utilizat ce necesită o corespondență unu la unu între noțiunile intuitive ale utilizatorului referitoare la obiect și noțiunile sistemului bazei de date referitoare la elementul de dată.
Modelul relațional nested este o extensie a modelului relațional în care domeniile pot fi atomice fie relație-valoare extinsă. Astfel, valoarea unui tuplu pe un atribut poate fi o relație și relațiile pot fi memorate în interiorul relațiilor. Aceasta recunoaște obiectul complex ca fiind reprezentat de un singur tuplu al n-relației, unde prin n-relație se înțelege relația nested asociată modelului relațional nested.
Dacă se va vedea un tuplu al n-relației ca element al datei, va exista o corespondență unu la unu între elementul datei și obiectele expuse utilizatorului bazei de date.
1.3.1 Exemplul de refacere a unui document
Se va ilustra modelul relațional nested pe un exemplu luat din sistemul informatic.
Fie un sistem de actualizare a unui document în care se memorează pentru fiecare document următoarele informații :
titlul documentului
lista de autori
data
lista cuvintelor-cheie
Se va vedea că, dacă se va defini o relație pentru informațiile de mai sus, câteva domenii vor fi neatomice.
Autorii : un document poate avea o mulțime de autori. Cu toate acestea se pot găsi toate documentele pentru care Barbu este unul dintre autori. Astfel, interesează numai o submulțime a domeniului elementelor "mulțime de autori".
Cuvinte-cheie : dacă se va memora mulțimea cuvintelor cheie pentru un document, e posibil să se poată reface toate documentele ale căror cuvinte-cheie includ unul sau sau mai multe cuvinte-cheie după care se face căutarea. Astfel, se privește domeniul "listei de cuvinte-cheie" ca neatomic.
Fig. 1.4 Relația " document non-1NF ", doc
Data : spre deosebire de “cuvinte-cheie” și “autori”, “data” nu are un domeniu mulțime-evaluată; totuși, se poate privi data ca fiind formată din subcâmpurile : zi, luna, an, aceasta făcând ca domeniul datelor să fie neatomic.
Figura 1.4 prezintă un exemplu de relație-document, doc, ce poate fi reprezentată și în prima formă normală (1NF), ca în figura 1.5. De aceea, trebuie să fie domeniu atomic în 1NF, iar dacă se dorește accesul la autori individuali, va trebui să fie un tuplu pentru fiecare pereche (cuvânt-cheie, autor). Atributele datei sunt înlocuite în 1NF cu trei atribute, câte unul pentru fiecare subcâmp al datei.
Multe din inconvenientele relației doc pot dispărea dacă se presupune că sunt următoarele dependențe multivoce :
titlu –» autor ; titlu –» cuvânt-cheie; titlu –» zi-luna-an
Atunci, se poate descompune relația în a 4-a formă normală (4NF) folosind schemele :
(titlu,autor)
(titlu,cuvânt-cheie)
(titlu,zi,luna,an)
Fig. 1.6 arată proiecția relației doc din figura 1.5 prin descompunerea de mai sus.
Deși exemplul considerat se poate reprezenta în 1NF folosind o bază de date adecvată, reprezentarea non-1NF poate fi un model ușor de înțeles; utilizatorii obișnuiți ai sistemului de "restabilire a documentului" gândesc baza de date în termenii modelului nostru non-1NF.
Modelul 4NF poate cere utilizatorilor să includă legături în întrebările lor, astfel complicând interacțiunea cu sistemul. Se poate defini o fereastră ce elimină necesitatea scrierii de către utilizatori a legăturilor în propriile întrebări. Oricum, într-o astfel de fereastră se va pierde corespondența unu-la-unu între tupluri și documente.
Fig. 1.5 doc', versiunea 1NF a relației non- 1NF doc
Fig. 1.6 Exemplu de relație în FN4
1.3.2 Definiția schemei n-relației
În modelul relațional, se definește schema unei baze de date printr-o listă de scheme de relație pentru relațiile din baza de date. Similar, în modelul n-relațional (nested) se va defini o listă a schemelor de n-relații (relații nested). Această definiție este mult mai complexă decât cea pentru schema relației non-nested (neextinsă), trebuind definite schemele fiecărui nivel de extindere.
De exemplu, se definește schema Doc-Schema pentru relația doc astfel :
Doc-Schema=(titlu,listă-autori,data,listă-cuvinte-cheie)
listă-autori=(autor)
data=(zi,luna,an)
listă-cuvinte-cheie=(cuvinte-cheie)
Această definiție stabilește că schema Doc-Schema are 4 atribute : titlu, listă-autori, data, listă-cuvinte-cheie. Atributul titlu are un domeniu neatomic. Cu toate că toate celelalte 3 atribute au domenii "relații-evaluate", schema trebuie definită pe ele ca bună. Privind schema din punct de vedere relațional, listă-autori este o simplă mulțime a autorilor, ceea ce înseamnă că ea este o relație cu un atribut, autor. Similar, lista-cuvintelor-cheie este o relație cu un atribut, cuvânt-cheie. Schema data este cu 3 atribute : zi, luna, an. Se observă că definind schema data în acest mod, se admite o mulțime de tupluri (zi,luna,an) chiar dacă exemplul are o singură dată pentru fiecare document.
În general, o schemă a bazei de date n-relaționale este definită de o mulțime de reguli, unde fiecare regulă este de forma : Ri=(Ri1,…,Rin).
În această regulă, Ri este referită ca partea stângă a regulei. Într-o schemă a unei baze de date, două reguli nu pot avea aceeași parte stângă.
Rs este denumit numele și aceasta poate referi sau scheme, sau atribute.
Un nume care nu apare în partea stângă a regulei este un atribut. Un nume care nu apare în partea dreaptă a regulei se numește nume exterior (schema exterioară). Numele exterioare sunt scheme pentru nivelul cel mai înalt al ierarhiei nested. Toate celelalte nume sunt scheme interioare.
În schema considerată, numele accesibile din Ri sunt acelea care sau sunt unul din Ri sau sunt accesibile dintr-un nume din Rij. Dacă Rij este accesibil din el însuși, schema bazei de date este recursivă.
Multe sisteme de baze de date relaționale nested solicită ca schema bazei de date să fie nerecursivă.
1.3.3. Limbaje de interogare bazate pe n-relație
Așa cum s-a văzut, operatorii algebrei relaționale se aplică n-relațiilor. La acești operatori se adaugă alții doi, pentru restructurarea n-relațiilor :
operatorul nest : simbolizat cu , împarte tuplurile unei relații în grupuri, fiecare dintre membrii unui grup fiind "agregat" într-un singur tuplu
operatorul unnest : simbolizat cu , operează astfel : un tuplu separat este generat pentru fiecare tuplu al subrelației n-relație
În continuare este prezentată folosirea acestor operatori.
Se presupune că se dorește să se genereze o relație 1NF doc (figura 1.5) dintr-o relație non-1NF doc (figura 1.7). Sunt 3 subrelații ale n-relației ce trebuie făcute unnest, iar aceasta se poate face în orice ordine.
Dacă se începe cu subrelația listă-autori :
lista-autori=(autor) (doc)
și se obține relația doc1 ca în figura 1.7.
Observație : În relația doc primul tuplu conține o listă autori conținând două tupluri : (Mihai) și (Barbu). În doc1 oricum este un tuplu pentru fiecare autor. Valorile pentru celelalte atribute sunt repetate. Astfel, că să se genereze relația doc, trebuie mai departe să se aplice operatorul unnest :
data= (zi,luna,an) ( (lista-cuvinte-cheie)=(cuvânt-cheie) (doc1))
Se presupune că trebuie generată o relație doc non-1NF (figura 1.4) dintr-o relație doc în 1NF (figura 1.5). Aceasta poate fi făcută prin intermediul mai multor operații nest.
Considerăm relația doc din figura 1.5. Expresia :
lista-autori = (autor)_(doc')
ia pe doc' și grupează tuplurile pentru a avea aceeași valoare pe toate atributele, cu excepția atributului autor.
De exemplu, tuplurile :
(plan-vânzări, Mihai, 1, aprilie, 79, profit)
(plan-vânzări, Barbu, 1, aprilie, 79, profit)
sunt grupate împreună. Pentru fiecare grup este creat un singur tuplu în care autorii pentru grup sunt așezați în mulțimea valorilor atributului. Rezultatul este relația arătată în figura 1.18.
Fig. 1.7 Relația doc1 (unnest doc pe lista-autori=autor)
Fig. 1.8 n-relația relației din fig. 1.4 pe lista-autori=autori
Se poate genera doc mai departe prin aplicarea operatorului nest :
data=(zi,luna,an) (lista-cuvinte-cheie=(cuvânt-cheie) (lista-autori=(autor) (doc')))
Aceste exemple ale operatorilor nest și unnest pot ajuta să se înțeleagă exact definiția lor.
Fie r o relație (posibil n-relație) cu o schemă R=(A1,…,An) și se consideră B=(B1,…, Bm)(r), unde fiecare Bi este distinct de Aj, pentru fiecare j.
Fie C1,…,Cn-m acele Aj care nu sunt egale cu Bi, oricare ar fi Bi.
Prin urmare, rezultatul expresiei de mai sus este o relație r' cu schema R'.
Regula B=(B1,…,Bn) este adăugată la schema bazei de date
Regula R'=(C1,…,Cn-m,B) este adăugată la schema bazei de date
Relația r' este rezultatul următorilor pași :
se împarte r în grupuri de tupluri ce satisfac C1,…,Cn-m ; fie G1,…,Gp aceste grupuri;
se include în r' un tuplu ti pentru fiecare grup Gi, unde ti ia valorile lui pe C1,…,Cn-m din valoarea comună conținută de toate tuplurile în Gi și ti[B] este mulțimea valorilor (B1,…,Bm) conținute de tuplurile în Gi.
Se poate exprima r' printr-un calcul relațional bazat pe tupluri sub forma :
{t/ u r(t[C1,…,Cn-m]=u[C1,…,Cn-m]
t[B]={v[B1,…,Bm]/ wr(w[B1,…,Bm]=v[B1,…,Bm]
w[C1,…,Cn-m]=t[C1,…,Cn-m])})}
Se va analiza în continuare operatorul unnest.
Fie r o relație cu schema R=(A1,…,Ai,B,Ai+1,…,An) și fie regula B=(B1,…,Bm) o parte a schemei bazei de date.
Fie B=(B1,…,Bn)(r) rezultatul acesteia fiind o relație r' cu schema R'.
Regula R'=(A1,…,Ai,B,Ai+1,…,An) este adăugată la schema bazei de date
Relația r' se obține parcurgând următorii pași :
for fiecare u in r do
for fiecare v in t[B] do
include tuplul t in r' cu t[A1,…,An] = u[A1,…,An]
t[B1,…,Bm] = v[B1,…,Bm]
Se poate exprima r' printr-un calcul relațional al tuplului sub forma :
{t/ ur(t[A1,…,An]=u[A1,…,An] t[B1,…,Bm] u[B])}
Cu toate că operatorii nest și unnest sunt necesari pentru restructurarea n-relațiilor, este uzual și mai convenabil să se opereze direct pe n-relații.
Se va prezenta aplicarea n-relației considerând limbajul SQL/NF care este o versiune a limbajului SQL extins să includă operații relaționale nested.
O interogare SQL are forma :
select A1,…,An
from r1,…,rm
where P
unde Ais reprezintă numele atributului, iar ris reprezintă numele relației.
Fie relația doc din figura 10.9 și întrebarea : "Găsi\ți titlurile documentelor scrise de Mihai în legătură cu profitul". În SQL aceasta poate fi scrisă astfel :
select titlu
from doc
where "Mihai" in lista-autori
and "profit" in lista-cuvinte cheie
Observație : S-au folosit atribute relație-evaluare în poziția de unde SQL poate necesita subexpresii de forma select-from-where. În particular, se notează să se folosească in la testul pentru membrii subrelației lista-cuvinte-cheie a lui doc.
Fie următoarea modificare în întrebarea de mai sus : "Găsiți titlul și anul publicării documentelor scrise de Mihai în legătură cu profitul".
Se observă că se întreabă numai anul publicării, nu și data completă :
select titlu, (select an from data)
from doc
where Mihai in lista-autori
and profit in lista-cuvinte-cheie
În exemplul de mai sus data este un atribut al relației doc. Deoarece data este o relație-evaluată, se poate aplica o selecție la ea. Pentru fiecare tuplu t al lui doc care satisface clauza where, întrebarea dă titlul și rezultatul selecției nest pe relația data a lui t.
Folosidu-se operatorii nest și unnest care permit restructurarea relațiilor ca părți ale interogării, pentru unnest, doc complet se poate scrie :
unnest doc on lista-autori, lista-cuvinte-cheie
N-relația necesită specificarea regulilor folosite la început. Expresia :
nest doc' on autor as lista-autori
rezultă din relațiile din figura 11.13.
Generând relațiile din figura 11.4, se poate scrie :
nest(nest doc' on autor as lista-autori) on cuv`nt-cheie as lista-cuvinte-cheie
Operația nest este folosită în exprimarea întrebărilor implicând operațiile de agregare. Clauza group by din SQL este o n-relație temporară pe care o valoare este calculată de o funcție de agregare. Se va vedea cum n-relațiile permit ca agregarea întrebărilor să fie simplificată considerabil.
Funcțiile de agregare (avg, min, max, sum, count) iau o mulțime ca argument și returnează o valoare ca rezultat al lor.
Fie pentru început o întrebare simplă : "Găsiți titlul și numele autorilor pentru fiecare document".
Aceasta se poate scrie astfel :
select titlu, count (lista-autori)
from doc
Deoarece lista-autori este un atribut relație-evaluare ce conține un tuplu pentru fiecare autor, un număr al acestei subrelații a n-relații dă numărul autorilor.
Dacă mulțimea pe care se dorește să se aplice o funcție de agregare nu există, poate fi folosit un operator nest pentru a o crea.
De exemplu, fie întrebarea anterioară folosită în schema banca : "Găsiți numele și media balanței de conturi a tuturor filialelor".
Se construiește o relație (nume-filială,balanță), apoi se construiește o n-relație ale cărei tupluri sunt perechi de forma (nume-filială,mulțimea tuturor balanțelor de conturi la acea filială). În final, se aplică funcția de agregare avg. Rezultatul interogării este :
select nume-filială, avg(balanță-conturi)
from nest select nume-filială, balanța
from depozit
on balanță
as balanță-conturi
O definiție explicită a n-relației permite predicatelor n-relației să apară în clauza where. Aceste eliminări sunt necesare pentru construirea clauzelor group by și having din SQL.
Fie întrebarea de mai sus cu precizarea restricțiilor la filialele în care media balanței de conturi depășește 120.000 lei. Se poate scrie :
select nume-filială, avg(balanță-conturi)
from nest select nume-filială, balanță
from depozit
on balanță
as balanță-conturi
where avg (balanță-conturi)>120.000
1.4 Sisteme expert de baze de date
În subcapitolul 1.1 s-a discutat despre integrarea regulilor "logic-based" în bazele de date relaționale. În general vorbind, astfel de reguli stabilesc că, dacă într-o bază de date există o mulțime de tupluri certe, atunci oricare alt tuplu trebuie să fie și el cert.
Sistemele expert de baze de date iau acest concept ca pas suplimentar, permițând ca acțiunile arbitrare să fie luate.
Un sistem expert de baze de date include reguli de forma : "Dacă mulțimea de tupluri este sigură (adică este formată din tupluri certe) în baza de date, atunci procedura specifică este executată". Această procedură poate modifica baza de date. Ca un rezultat al acestei modificări, clauza if a celorlalte reguli poate deveni adevărată, iar acest proces poate continua la nesfârșit. Sistemele de această formă se numesc baze de date active.
Structura unui sistem de baze de date expert este similară cu cea a unui sistem expert de inteligență artificială. Deosebirea principală între acestea două este folosirea mai exactă a bazei de date ca memorie principală (sau virtuală).
În forma lui simplă, un sistem expert de baze de date constă dintr-un sistem de baze de date standard și un sistem expert standard. Sistemul expert prezintă interogările în limbajul bazei de date ca SQL și așteaptă un răspuns din partea sistemului de baze de date. Cu toate că acesta este ușor de implementat, nu este un model optim pentru că regulile în baza de cunoștințe nu se folosesc în procesarea interogării bazei de date. În plus, în cazul potrivit, acel sistem expert pune întrebări iar sistemul bazei de date nu are avantajul asemănării întrebărilor și trebuie să proceseze fiecare întrebare individual.
Pentru că eficiența acestei forme a sistemului expert interacționează cu sistemul bazei de date, mai multe alternative au început a fi luate în considerare, incluzând aici :
încărcarea în sistemul expert a acelei părți a bazei de date care este necesară pentru procesarea regulilor; baza de date însăși este memorată și păstrată separat de sistemul expert; periodic, copii ale datelor sistemului expert sunt actualizate;
implementarea sistemului de baze de date în interiorul sistemului expert;
traducerea în algebra relațională a întrebărilor logice puse sistemului expert; rezultatul expresiei algebrice este trecut la sistemul bazei de date pentru optimizare și execuție.
Integrarea bazelor de date manageriale și a sistemelor expert duce la o creștere rapidă a ariei de dezvoltare și cercetare.
1.5 Concluzii
Modelul bazei de date logice folosit în Datalog permite specificarea relațiilor derivate din relațiile de bază folosind regulile if-then. Aceste reguli pot fi recursive. Evaluarea interogării nerecursive Datalog poate fi făcută construind graful regulei.
Acest graf arată pentru fiecare relație obținută mulțimea de bază și relațiile obținute de care ea depinde. Din acest graf se poate calcula rezultatul din relațiile de bază în maniera bottom-up. Dacă interogările Datalog sunt recursive, atunci graful regulei trebuie să conțină un ciclu.
Au fost utilizate două tehnici interactive pentru evaluarea interogărilor recursive :
evaluarea naivă
evaluarea semi-naivă
Modelul nested relațional extinde modelul relațional la domenii neatomice (relațiile nu sunt în prima formă). Aceste domenii neatomice sunt relație-evaluare. Astfel, se formează o ierarhie a n-relațiilor (relațiilor nested). Algebra operațiilor este adaptată la n-relațiile restructurate încorporate în algebra relațională. SQL/NF este un limbaj modificat al lui SQL pentru n-relații fiind folosit să prezinte întrebările în n-relații.
Sistemul expert de baze de date constă din reguli if-then. Spre deosebire de Datalog, clauza then poate fi o tranzacție arbitrară în baza de date. Un sistem de baze de date expert își continuă testele pentru satisfacerea condițiilor if ale regulilor. Când se întâmplă aceasta, una sau mai multe reguli sunt alese și corespondența clauzei then este executată. Astfel de sisteme sunt similare cu sistemele expert cu o prezentare suplimentară a interacțiunii "intime" cu baza de date.
CAPITOLUL II
BAZE DE DATE ORIENTATE OBIECT
2.1 Introducere
În ultimul deceniu a căpătat o mare importanță sistemul bazelor de date orientate-obiect. Sistemele obiect sunt privite de unii oameni ca fiind un concurent serios pentru sistemele relaționale, cel puțin pentru anumite tipuri de aplicații. În acest capitol, vom examina in detaliu sistemele obiect; vom introduce si explica conceptele de bază, vom analiza aceste concepte in profunzime, si vom oferi câteva opinii privind convenabilitatea incorporării acestor sisteme în sistemele de baze de date ale viitorului.
De ce este un așa de mare interes în sistemele orientate obiect? Se știe că sistemele clasice SQL sunt inadecvate într-o mulțime de direcții. Cîteva dintre trăsăturile de care avem nevoie în SGBD există de mulți ani în limbajele de programare orientate obiect cum ar fi C++ și Smalltalk, și deci este natural să ivestigăm ideea de incorporare a acestor trăsături în sistemele de baze de date. Și mulți cercetători au făcut exact acest lucru.
Sistemele orientate obiect își au originile în limbajele de programare orientate obiect. Ideea de bază este aceeași în ambele cazuri – utilizatorii trebuie să fie capabili să se descurce cu obiecte și operații cu aceste obiecte, acestea având mai mult un corespondent în lumea reală. De exemplu, în loc să se gândească în termeni la un ‘tuplu DEPT’ plus o colecție de ‘tuplu EMP’ care include ‘valori chei străine’, ca ‘referința’ la ‘valoarea cheie elementară’ în ‘tuplul DEPT’, utilizatorul ar trebui să fie capabil să gândească în termenii unui obiect departament care actual conține o mulțime corespunzătoare de obiecte funcționale. Și în loc să ‘insereze’ un ‘tuplu’ în ‘EMP relvar’ cu ‘valori cheie străine’ potrivită care ‘referă’ ‘valoarea cheie elementară’ a unor tupluri din ‘DEPT relvar’, utilizatorul ar trebui să fie capabil să angajeze un obiect funcțional direct în obiectul departament relevant. Ideea este de a mari nivelul de abstractizare.
Acum, mărirea nivelului de abstractizare este un scop, și paradigma obiectuala a fost de succes în atingerea obiectivului în domeniul limbajelor de programare. Ideea manipulării unei baze de date ce este făcută din ‘obiecte complexe’ în locul manipulării ‘relvar-uri’ și ‘inserări de tupluri’ și ‘chei străine’ este, evident, mai atractivă din punctul de vedere al utilizatorului—cel puțin la prima vedere.
Ideea este că, deși limbajele de programare și gestiunea bazelor de date au multe în comun, ele lucrează diferit din anumite puncte de vedere importante. Mai exact:
Un program de aplicatie – prin definiție – este destinat să rezolve anumite probleme specifice;
Dinpotrivă, o bază de date – prin definiție- este destinata să rezolve o varietate de probleme diferite, câteva dintre acestea putând fi chiar necunoscute în momentul în care baza de date este stabilită.
În mediul programării aplicate, băgând multă ‘inteligență’ în obiecte complexe este clar o idee bună: Reduce cantitatea de cod care trebuie scrisă pentru a se folosi aceste obiecte, îmbunătățește productivitatea programatorului, ș.a.m.d. în mediul bazelor de date, din contră, împachetând multă inteligență în baza de date poate fi sau nu o idee bună: ar putea simplifica unele probleme, dar în același timp ar putea crea altele mai dificile sau chiar imposibile.
(Din întâmplare, exact același argument a fost adus împotriva sistemelor de baze de date prerelaționale cum ar fi IBM-ul din 1970)
Mulți cred că sistemele obiect reprezintă un salt important în tehnologia bazelor de date. În particular se crede că tehnicile orientate obiect sunt aproape de alegerea din arii de aplicații ‘complexe’ cum sunt următoarele:
Design și manufacturare cu ajutorul computerului (CAD/CAM);
Manufacturare cu computer integrat (CIM);
Inginerie soft cu ajutorul computerului (CASE);
Sisteme informaționale geografice (GIS);
Știință și medicină;
Stocare și refacere de documente;
Și așa mai departe (nu sunt acestea toate ariile în care QSL-ul clasic tinde să aibă probleme). Desigur au fost numeroase lucrări tehnice cu aceste chestiuni, de-a lungul anilor, și, mai recent, câteva produse comerciale au intrat pe piață.
În acest capitol vom arunca o privire asupra a ceea ce reprezintă tehnologia bazelor de date orientate obiect. Scopul nostru este să introducem cele mai importante concepte și în particular să descriem aceste concepte din perspectiva bazelor de date (majoritatea cărților, din contră, prezintă ideile foarte mult dintr-o perspectivă de programare) . structura capitolului este următoarea: în următoarea secțiune vom prezenta un exemplu de motivare – un exemplu cu care un produs al SQL-ului tradițional nu se descurcă foarte bine iar tehnologia orientată obiect are șanse de a se descurc mai bine. Următoarea secțiune 4.2 prezintă o recapitulare a obiectelor, claselor, mesajelor și metodelor și secțiunea 4.3 se concentrează pe anumite aspecte ale acestor concepte și le discută în profunzime. Secțiunea 4.4 prezintă un exemplu ‘cradle-to-grave’. Secțiunea 4.5 discută apoi câteva topici amestecate, și secțiunea 4.6 prezintă un sumar.
O ultimă remarcă preliminară: în ciuda faptului că sistemele obiect au fost inițial pentru aplicații ‘complexe’ cum ar fi CAD/CAM, din motive evidente vom baza exemplele pe aplicații simple. Desigur, această simplificare nu invalidează în nici un fel prezentarea – și în orice caz, bazele de date orientate obiect ar trebui să poată manevra, de asemenea și aplicații ‘simple’.
Exemplu motivant
În această subsecțiune prezentăm un exemplu simplu, inițial lucrând laa Stonebreaaker și elaborat de scriitorul prezent în referință [4.17], care ilustrează câteva dintre problemele produselor convenționale SQL. Baza de date privește dreptunghiuri, toate, după cum presupunem pentru simplitate, sunt cu toate laturile fie orizontale, fie verticale. Orice dreptunghi poate fi identificat după coordonatele colțurilor stânga-jos și dreapta-sus: (x1, y1) și (x2, y2). În SQL:
CREATE TABLE RECTENGLE
( X1 . . . , Y1 . . . , X2 . . . ,Y2 . . . , . . . ,
UNIQUE( X1, Y1, X2, Y2 ) );
Fig.1 Dreptunghiul (x1, y1, x2, y2)
Fig.2 Pătratul unitate (0, 0, 1, 1)
Acum considerăm următoarea intrebare:
‘Să se returneze toate dreptunghiurile care se intersecteza pătratul unitate (0, 0, 1, 1) (Figura.2)’. Iată formularea acestui algoritm:
SELECT . . .
FROM RECTENGLE
WHERE (X1>= 0 AND X1<= 1 AND Y1>=0 AND Y1<=1)
– vârful stânga-jos să fie în interiorul pătratului unitate
OR (X2>= 0 AND X2<= 1 AND Y2>=0 AND Y2<=1)
– vârful dreapta-sus să fie în interiorul pătratului uniate
OR (X1>= 0 AND X1<= 1 AND Y2>=0 AND Y2<=1)
– vârful stânga-sus să fie în interiorul pătratului uniate
OR (X2>= 0 AND X2<= 1 AND Y1>=0 AND Y1<=1)
– vârful dreapta-jos să fie în interiorul pătratului uniate
OR (X2>= 1 AND X1<= 0 AND Y1<=0 AND Y2>=1)
– dreptunghiul total să fie în interiorul pătratului uniate
OR (X1<= 0 AND X2>= 1 AND Y1>=0 AND Y1<=1)
– latura de jos traversează pătratul uniate
OR (X1>= 0 AND X1<= 1 AND Y1<=0 AND Y2>=1)
– latura stângă traversează pătratul uniate
OR (X2>= 0 AND X2<= 1 AND Y1<=0 AND Y2>=1)
– latura dreaptă traversează pătratul uniate
OR (X1<= 0 AND X1>= 1 AND Y2>=0 AND Y2<=1)
– latura de sus traversează pătratul uniate
Se poate vedea că algoritmul poate fi scris mai simplu după cum urmează:
SELECT . . .
FROM RECTENGLE
WHERE ( X1<= 1 AND Y1<=1
– vârful stânga-sus este mai jos de (1, 1)
X2>= 0 AND Y2>=0);
– vârful dreapta-sus este mai jos de (1, 1)
Problema este următoarea: Poate optimizatorul sistemului să transforme forma originală lungă a algoritmului în forma scurtă corespunzătoare? Cu alte cuvinte, să presupunem că utilizatorul exprimă algoritmul în ‘evidenta’ formă lungă; est optimizatorul capabil să reducă algoritmul la o formă scurtă
Mai eficientă înainte să îl execute? Referința [4.17] sugerează în mod evident că răspunsul este mai degrabă nu, cel puțin până în prezent.
În orice caz, deși am descris forma scurtă ca fiind mai ‘eficientă’, performanța acesteia este mică în multe produse, dând structurile uzuale de stocare.
Astfel am văzut că produsele convenționale SQL sunt inadecvate în anumite scopuri.
2.2 Obiecte, clase, metode și mesaje
În această secțiune vom introduce câteva dintre conceptele principale ale abordării obiect, numite obiecte, clase, metode și mesaje. Vom asocia aceste concepte cu unele mai familiare când este posibil sau potrivit. Este, probabil, util să arătăm o aplicație aproximativă a termenilor obiect prin terminologia tradițională .
Înainte de a intra în detalii, ar trebui să precizăm că nu este, în mediul orientat-obiect o precizie ca în mediul relațional. Multe concepte orientate obiect, sunt chiar imprecise.
În particular, nu exista notiunea abstracta definita formal de “model de obiect de date”. Pentru astfel de motive pe parcursul acestui capitol plasam cuvintele “modelul de obiect” in ghilimele. De fapt, se pare, surprinzator de altfel, pentru a exista confuzie pe nivelurile abstractizarii, asupra crucialei distinctii dintre model si implementare. Studiati capitolul I daca doriti sa va reimprospatati memoria in legatura cu aceasta distinctie.
Trebuie sa fiti de asemenea avertizat ca, ca o consecinta a starii miscatoare a afacerilor, definitiile si explicatiile prezentate in acest capitol nu sunt acceptate in unanimitate si nu corespund suta la suta cu modul in care lucreaza de fapt un model. Intr-adevar, aproape fiecare din aceste definitii si explicatii pot fi contrazise de alt scriitor din domeniu, si probabil ca asa se va intimpla.
O privire asupra Tehnologiei Obiect
Intrebare: ce este un obiect? Raspuns: orice!
Unele obiecte sunt imutabile; exemple: intregii (3, 42) si sirurile de caractere (“Mozart”). Alte obiecte sunt mutabile. In terminologia traditionala, deci, obiectele imutabile corepund valorilor, iar cele mutabile variabilelor – unde valorile si variabilele in discutie pot fi de complexitate arbitrara (se pot folosi de unele sau chiar de toate tipurile de date folosite in limbajele de programare si generatorii de tipuri: numere, stringuri, liste, siruri, stive. In unele sisteme termenul obiect este rezervat pentru cazul mutabil numai (termenul valoare este folosit deci pentru cele imutabile). Si chiar in sistemele in care obiect se refera la ambele cazuri, trebuie sa stiti ca trebuie sa considerati ca obiecte doar pe cele mutabile.
Orice obiect are un tip. Obiectele individuale sunt numite de obicei instante de obiect, pentru a le deosebi clar de tipul de obiecte in discutie. Folosim aici termenul “tip” in sensul sau obisnuit; in particular, utilizam termenul pentru a include setul de operatori care poate fi aplicat asupra obiectelor de tipul specificat. Nota: Unele sisteme obiect fac distinctia intre tipuri si clase, si vom reveni asupra acestor siteme mai tirziu.
Obiectele sunt incapsulate adica reprezentarea fizica a unui astfel de obiect, sa zicem un DEPT obiect, nu este vizibila utilizatorilor obiectelor de acest tip. Utilizatorii stiu numai ca obiectul este capabil sa execute anumite operatii. De exemplu, metodele care se aplica la obiectele DEPT ar putea fi HIRE_EMP.FIRE_EMP.CUT_BUDGET. Observati ca astfel de metode constituie singurele operatii care se pot aplica asupra obiectelor in cauza. Codului care implementeaza aceste metode i se permite sa vada reprezentarea interna a obiectelor – acestui cod ii este permis sa sparga incapsularea – dar bineinteles acest cod nu este vizibil utilizatorilor.
Avantajul incapsularii este ca permite reprezentarii interne a obiectelor sa se schimbe fara a cere aplicatii care folosesc aceste obiecte sa se rescrie (orice astfel de schimbare in reprezentarea interna este acompaniata de schimbarea corespunzatoare a codului care implementeaza metodele aplicabile). Cu alte cuvinte, incapsularea implica independenta datelor fizice.
Acum, caracterizarea incapsularii in termeni de independenta de date are sens din perspectiva bazelor de date, dar conceptul nu este descris astfel in literatura obiectuala. In loc, obiectele incapsulate sunt descrise ca avind o memorie privata si o interfata publica:
Memoria privata consta in instantele de variabile (cunoscute ca membrii sau atribute), ale caror valori reprezinta starea interna a obiectelor. Acum, intr-un sistem “pur”, instantele de variabile sunt complet private si ascunse de utilizatori, desi sunt vizibile codului care implementeaza aceste metode. Multe sisteme nu sunt “pure” in acest sens dar care expun instante de variabile utilizatorilor.
Interfata publica consta in definitiile de interfata pentru metodele care se aplica acestui obiect. Aceste definitii de interfata corespund semnaturilor de specificatie, desi sistemele obiect insista de obicei ca astfel de semnaturi sa fie legate doar de o “tinta” specifica de tip de clasa. Codul care implementeaza aceste metode, la fel ca instantele de variabile, este ascuns de utilizatori. Ar fi mai propriu spus ca interfata publica face parte din definirea obiectelor pentru obiectul in discutie, mai mult decit parte a obiectului in sine (dupa toate, interfata publica este comuna tuturor obiectelor clasei in discutie, decit fiind specifica unui obiect individual anume). Definitia obiectului este obiectul care defineste clasa a carei instanta este obiectul in cauza.
Metodele sunt invocate prin mijloace de mesaje. Un mesaj este doar o
invocare de operatori, in care un argument, tinta, este distins si chiar i se acorda tratament sintactic special. De exemplu, urmatorul ar putea fi un mesaj catre departamentul D, cerind angajarea lucratorului E:
D HIRE_EMP (E)
Tinta este aici departamentul notat aici prin D. Analogul acestui mesaj intr-un limbaj de programare mai conventional arata astfel:
HIRE_EMP (D, E)
In practica, un sistem obiect va fi echipat cu citeva clase si metode incluse. Sistemul va elibera clase precum NUMERIC (cu metodele “=”, “<”, “+”, “-“ si altele), CHAR (cu metodele: “=”, “<”, “||”, SUBSTR) si asa mai departe. De asemenea sistemul va oferi facilitati pentru utilizatori sa defineasca si sa implementeze clasele si metodele lor.
Instantele de variabile
Vom aruca acum o privire asupra conceptului de instante de variabile. Acestea sunt ascunse de utilizator intr-un sistem pur. Din pacate, majoritatea sistemelor nu sunt pure in acest sens. Ca o consecinta, este necesar in practica sa se faca distinctie intre instante de variabile publice si private; cele private sunt cu adevarat ascunse ,dar cele publice nu sunt.
Ca exemplu, presupunem ca avem o clasa de segmente de linie si ca acestea sunt reprezentate fizic prin punctele lor START si END. Sistemul ii va permite utilizatorului sa utilizeze expresii de forma ls.START si ls.END pentru a avea acces la punctele START si END pentru un segment ls. Deci, START si END sunt instante de variabile publice. Daca reprezentarea fizica a segmentelor de linie se schimba acum, sa zicem la combinatia MIDPOINT, LENGTH si SLOPE, orice program care contine expresii ca ls.START si ls.END se vor sparge. Cu alte cuvinte am pierdut independenta datelor.
Observam ca instantele de variabile publice sunt logic neinteresante. Presupunem ca definim metode GET_START, GET_END, GET_MIDPOINT, GET_LENGTH si GET_SLOPE pentru segmentele de linii. Atunci utlizatorul poate avea acces la punctul de plecare, puntul de sfirsit, punctul de mijloc, etc. pentru segmentul de linie ls prin mijloace apropiate invocarii metodelor: GET_START(ls), GET_END(ls), GET_MIDPOINT(ls) etc. Si acum nu conteaza ce este reprezentarea fizica a segmentelor de linie – atita timp cit metodele GET_ sunt corect implementate si reimplementate corect daca reprezentarea fizica se schimba. Nu ar fi nimic gresit in a-i da posibilitatea utilizatorului sa prescurteze GET_START(ls) la ls.START ca o “shorthand”: observati ca acest lucru nu insemna ca START devine o instanta de variabila publica. In mod trist, sistemele reale nu opereaza in aceasta maniera: de obicei, instantele de variabile publice expun intr-adevar reprezentarea fizica (sau o parte din ea, la orice rata, desi ar fi unele instante de variabile suplimentare care sunt cu adevarat private si ascunse). In acord cu practica, vom presupune in ceea ce urmeaza ca obiectele tipice expun anumite instante de variabila publice, desi conceptul este logic nenecesar.
Este un punct de legatura care trebuie mentionat aici de asemenea. Presupunem ca anumite argumente sunt cerute sa creeze obiecte dintr-o clasa particulara. Atunci nu urmeaza ca aceste “instante de variabile” pot fi utilizate pentru scopuri arbitrare. Presupunem, de exemplu, crearea unui segment de linie ne cere sa specificam punctele START si END. Atunci nu urmeaza ca putem obtine toate segmentele cu punctul de inceput START; aceasta metoda va fi legala numai daca a fost definita in prealabil o metoda potrivita.
Observati ca aceste sisteme suporta o variatie de instante de variabila private numite instante de variabile protejate. Daca obiectele clasei C au o instanta de variabila protejata P, atunci P este vizibila codului care implementeaza metodele definite pentru clasa C si codului care implementeaza metodele definite ale tuturor subclaselor clasei C (la orice nivel).
Identitatea obiectelor
Fiecare obiect are un unic identificator numit obiect ID sau OID. Obiectele imutabile ca, de exemplu, intregul 42 se identifica singure. In contrast, obiectele mutabile au adrese ca propriul lor OID, si aceste adrese pot fi utilizate oriunde altundeva in baza de date ca pointeri la obiectele in discutie. Aceste adrese nu sunt expuse utilizatorului, dar de exemplu ele pot fi asignate la unele variabile de program in cadrul altor obiecte.
2.3 O privire mai atenta
Presupunem ca vrem sa definim 2 clase, DEPT si EMP. Presupunem ca clasele MONEY si JOB au fost deja definite si la fel clasa CHAR. Definitiile claselor DEPT si EMP arata cam asa:
CLASS DEPT
PUBLIC ( DEPT# CHAR,
DNAME CHAR,
BUDGET MONEY,
MGR REF(EMP),
EMPS REF(SET(REF(EMP))))…..
METHODS(HIRE_EMP(REF(EMP))…….code…….,
FIRE_EMP(REF(EMP))……..code…….,….)….;
CLASS EMP
PUBLIC (EMP# CHAR,
ENAME CHAR,
SALARY MONEY,
POSITION REF(JOB))….
METHODS (…..)….;
Obiectele din clasa DEPT includ o instanta de variabila publica numita MGR, reprezentind managerul departamentului, si una numita EMPS reprezentind angajatii departamentului. Mai precis, obiectele din clasa DEPT includ o instanta de variabila publica numita MGR a carei valoare este o referinta la un manager si inca una numita EMPS a carei valoare este o referinta la un set de angajati.
Am decis sa nu includem o instanta de variabila in obiectele din clasa EMP a carei valoare este sau un departament OID sau o valoare DEPT#. Inseamna ca nu exista drum direct de la un obiect dat EMP la obiectul DEPT corespunzator. Observati ca fiecare definitie de clasa include definitii ale metodelor care se aplica obiectelor clasei in discutie. Clasa tinta pentru astfel de metode este bineinteles clasa care incorporeaza definitia metodei in discutie.
Consideram intii un obiect EMP care contine:
Un obiect imutabil “E001” al clasei CHAR in instanta ei de variabila publica EMP#
Un obiect imutabil “Smith” al clasei CHAR in instanta ei de variabila publica ENAME
Un obiect imutabil “$50.000” al clasei MONEY in instanta ei de variabila publica SALARY
OID-ul unei obiect mutabil al clasei JOB in instanta ei de variabila publica POSITION
Contine de asemenea 2 instante de variabila private, una continind OID
-ul eee obiectului EMP si una continind OID-ul clasei definitoare a obiectului. Aceste 2 OID-uri pot fi stocate fizic impreuna cu obiectul. De exemplu, valoarea eee nu este stocata impreuna cu obiectul EMP; implementarea trebuie insa sa aiba un mijloc de a localiza obiectul care are valoarea eee. Conceptual, utilizatorul poate considera OID-ul ca parte a obiectului.
Acum consideram obiectul DEPT cu OID-ul ddd. Acest obiect contine:
Un obiect imutabil “D01” al clasei CHAR in instanta ei de variabila publica DEPT#
Un obiect imutabil “Mktg” al clasei CHAR in instanta ei de variabila publica DNAME
Un obiect imutabil “$1.000.000” al clasei MONEY in instanta ei de variabila publica BUDGET
OID-ul eee al unui obiect mutabil al clasei EMP in instanta ei de variabila publica MGR
OID-ul sss al unui obiect mutabil al clasei SET(REF(EMP)) in instanta ei de variabila publica EMPS
2 instante de variabila private continind OID-ul ddd al obiectului DEPT si OID-ul clasei definitoare
Obiectul cu OID-ul sss contine un set de OID-uri de obiecte individuale
EMP, plus instantele de variabila private.
Obiectele de obicei contin nu obiecte ci OID-uri adica pointeri la alte obiecte. Obiectul DEPT pentru departamentul D01 include obiectul EMP pentru angajatul E001 de 2 ori (si astfel salariatul ar putea avea 2 salarii diferite). Definitiile de clase de obicei nu definesc instantele de variabila ca si “REF”-uri dar in loc reflecta direct interpretarea ierarhica. Instanta de variabila EMPS in obiectul DEPT poate fi definit nu ca REF(SET(REF(EMP))) ci doar ca SET(EMP). Pe de o parte, se considera ca obiectele sunt ierarhii. Pe de alta parte, este clar ca obiectele nu sunt ierarhii ci tupluri, unde un tuplu poate fi:
Subobiecte imutabile
OID-uri ale subobiectelor mutabile
Liste, siruri, plus alte obiecte ascunse OID, CDO.
Sistemele de obiecte de obicei suporta generatori de tip ca SET, LIST, ARRAY, BAG si acesti generatori pot fi combinati in moduri diferite.
Identificatori de obiecte
SGBD-urile relationale se bazeaza pe chei controlate de utilizatori. Aceste chei sufera de unele probleme. SGBD-urile relationale ar trebui sa suporte sisteme definite de chei in loc. Surogatele sunt valori si sunt vizibile pentru utilizatori, in timp ce OID-urile sunt adrese si sunt ascunse utilizatorului.
Se ridica urmatoarele intrebari:
OID-urile nu evita nevoia de chei de utilizatori;
Care este OID-ul pentru un obiect derivat? Care este proiectia unui DEPT peste BUDGET sau peste MGR?
Obiectele arata ca niste CODASYL -uri supraincalzite. Termenul CODASYL se refera la o anumita retea de sisteme de baze de date ca IDMS. Sistemele CODASYL sunt mai apropiate de sistemele obiect decit sistemele relationale. Sistemele relationale sunt bazate pe valori pe cind sistemele obiect sunt bazate pe identitate.
2.4 Clasa vs Instanta vs Colectie
O clasa este la baza un tip de date de complexitate arbitrara. Fiecare clasa intelege un mesaj NEW, care cauzeaza o instanta a clasei. De exemplu:
E:=EMP NEW(‘E001’, ‘Smith’, MONEY(50000),POS);
Aici POS este o variabila care contine OID-ul unui obiect JOB. Metoda NEW este invocata asupra obiectului EMP; creeaza o noua instanta a acelei clase, initializata cu valorile specificate, si returneaza OID-ul instantei noi, care este alocat variabilei E.
Obiectele pot apartine unei oarecare colectii de obiecte in acelasi timp. Exemplu:
CLASS EMP_COLL
PUBLIC(EMPS REF(SET(REF(EMP))))…..;
ALL_EMPS:=EMP_COLL NEW();
ALL_EMPS ADD(E);
Explicatie:
un obiect al clasei EMP_COLL contine o singura instanta de variabila publica, numita EMPS a carei valoare este un pointer la un obiect mutabil a carei valoare este un set de pointeri la obiecte EMP
ALL_EMPS este o variabila a carei valoare este OID-ul unui obiect al clasei EMP_COLL. El contine OID-ul unui obiect a carei valoare este OID-ul unui set gol de obiecte EMP;
ADD este o metoda care este inteleasa de obiecte EMP_COLL. In exemplu, metoda este aplicata obiectului clasei al carei OID este dat in variabila ALL_EMPS; are ca efect adaugarea OID-ului obiectului EMP al carui OID este dat invariabila E setului de OID-uri al carui OID este dat in obiectul EMP_COLL al carui OID este dat in variabila ALL_EMPS.
Variabila ALL_EMPS contine o colectie de EMP-uri care contine doar
un EMP:angajatul E001:
PROGRAMMERS:=EMP_COLL NEW();
PROGRAMMERS ADD (E);
……….
HIGHLY_PAID:=EMP_COLL NEW();
HIGHLY_PAID ADD(E);
De exemplu comanda SQL:
CREATE TABLE EMP
(EMP# ….,
ENAME ….,
SALARY….,
POSITION……)….;
creeaza un tip si o colectie in acelasi timp. Comanda SQL:
INSERT INTO EMP(……) VALUES (…..);
creeaza un EMP individual si il adauga simultan la colectia EMP.
In SQL:
Nu se poate ca un obiect EMP sa existe fara sa faca parte dintr-o colectie , de fapt una singura
Nu se pot crea 2 colectii diferite ale aceleiasi clase de obiecte EMP
Nu se pot imparti aceleasi obiecte intre mai multe colectii.
Mai putem defini doua tabele numite PROGRAMMERS si
HIGHLY_PAID, fiecare continind doar numarul angajatilor. Exemplu:
CREATE VIEW PROGRAMMERS
AS SELECT EMP#, ENAME, SALARY, POSITION
FROM EMP
WHERE POSITION=’Programmer’;
CREATE VIEW HIGHLY_PAID
AS SELECT EMP#, ENAME, SALARY, POSITION
FROM EMP
WHERE SALARY>sa zicem 75000;
Si acum, este posibil pentru un angajat sa apartina mai multor colectii.
Incheiem aceasta discutie mentionind o paralela intre obiectele mutabile si variabilele explicite dinamice ale anumitor limbaje de programare. Pot exista orice numar de variabile dinamice explicite de un anume tip. Aceste variabile distincte nu au nume si deci pot fi indicate numai prin intermediul pointerilor. In PL/I putem scrie:
DCL XYZ INTEGER BASED; /* DCL este o variabila BASED */
DCL P POINTER; /* P este un pointer */
ALLOCATE XYZ SET(P); /* creeaza o noua instanta XYZ */
/* si ii da valoarea P */
p->XYZ=3;
2.5 Un exemplu Cradle-to-Grave
Exemplul nostru se bazeaza pe produsul GemStone si limbajul sau OPAL care este bazat pe Smalltalk. Baza de date contine informatii despre o companie de educatie si o schema de antrenament. Pentru acest curs, baza de date contine detalii despe acel curs, de asemenea detalii despre toti studentii si profesorii. Baza de date contine de asemenea informatii despre toti angajatii. O versiune relationala a bazei de date arata cam asa:
COURSE {COURSE#, TITLE}
OFFERING {COURSE#, OFF#, OFFDATE, LOCATION}
TEACHER {COURSE#, OFF#, EMP#}
ENROLLMENT {COURSE#, OFF#, EMP#, GRADE}
EMP {EMP#, ENAME, SALARY, POSITION}
2.5.1 Definirea datelor
Definirea unui obiect din clasa EMP:
1 OBJECT SUBCLASS : ‘EMP’
2 INSTVARNAMES : #[‘EMP#’, ‘ENAME’, ‘POSITION’]
3 CONSTRAINTS : #[#[#EMP#,STRING],
4 [#ENAME,STRING],
[#POSITION,STRING]].
Explicatie: Linia 1 defineste un obiect EMP, o subclasa a clasei OBJECT( In termenii limajului OPAL, linia 1 trimite un mesaj obiectului OBJECT, cerindu-i sa invoce metoda SUBCLASS; INSTVARNAMES si CONSTRAINTS specifica argumente ale acelei metode. Definirea unei noi clase in OPAL se face trimitind un mesaj unui obiect). Linia 2 spune ca obiectele clasei EMP au trei instante de variabila private, denumite EMP#, ENAME si POSITION. Liniile 3-5 constring aceste instante de variabila sa contina obiecte din clasa STRING .
Instantele de variabila EMP#, ENAME si POSITION sunt private pentru clasa EMP. Prezentam in continuare definirea metodelor ‘get si set’ pentru numarul de angajati:
METHOD : EMP
GET_EMP#
^EMP#
%
METHOD : EMP
SET_EMP : EMP#_PARAM
EMP#:=EMP#_PARAM
%
Iata definitia clasei COURSE:
1 OBJECT SUBCLASS : ‘COURSE’
2 INSTVARNAMES : #[‘COURSE#’, ‘TITLE’, ‘OFFERINGS’]
3 CONSTRAINTS : #[#[#COURSE#, STRING],
4 [#TITLE, STRING],
[#OFFERINGS, OSET]].
Explicatie: Linia 5 aici specifica faptul ca instanta de variabila privata OFFERINGS va contine OID-ul unui obiect din clasa OSET. Informal, OFFERINGS va denota multimea tuturor offering-urilor pentru cursul in cauza: cu alte cuvinte, am ales sa modelam relatia curs-offering ca o ierarhie de continut, in care offering-urile sunt continute conceptual in cursurile corespunzatoare .
Apoi clasa OFFERING:
1 OBJECT SUBCLASS : “OFFERING’
2 INSTVARNAMES : #[‘OFF#’, ‘ODATE’, ‘LOCATION’,
‘ENROLMENTS’, ‘TEACHERS’]
4 CONSTRAINTS : #[#[#OFF#, STRING],
5 [#ODATE, DATETIME],
[#LOCATION, STRING],
[#ENROLLMENTS, NSET],
[#TEACHERS, TSET]].
Explicatie: Linia 7 specifica faptul ca instanta de variabila privata ENROLLMENTS va contine OID-ul unui obiect al clasei NSET; informal, ENROLLMENTS va denota multimea tuturor angajarilor pentru offering-ul in discutie. De asemenea, TEACHERS va denota mulimea tuturor profesorilor pentru offering-ul in cauza. Din nou adoptam o ierarhie de continut.
Urmeaza clasa ENROLLMENT:
1 OBJECT SUBCLASS : ‘ENROLLMENT’
2 INSTVARNAMES : #[‘EMP’, ‘GRADE’]
3 CONSTRAINTS : #[#[#EMP, EMP],
[#GRADE, STRING]].
Explicatie: Instanta de variabila privata EMP (linia 3) va contine OID-ul unui obiect din clasa EMP, reprezentind angajatul individual pentru care are loc angajarea. Am plasat obiectul EMP inauntrul obiectului ENROLLMENT corespunzator pentru a continua cu ierarhia de continut
In sfirsit, profesorii pe care ii tratam ca pe o subclasa a angajatilor:
1 EMP SUBCLASS : ‘TEACHER’
2 INSTVARNAMES : #[‘COURSES’]
3 CONSTRAINTS : #[#[#COURSES, CSET]].
Explicatie: Linia 1 defineste un obiect al clasei TEACHER, o subclasa a clasei EMP. Deci, fiecare obiect individual TEACHER are instantele de variabila private EMP#, ENAME si POSITION, plus COURSES care va contine OID-ul unui obiect din clasa CSET; acest obiect CSET va denota multimea tuturor cursurilor pe care acest profesor poate sa le predea. Fiecare obiect TEACHER va mosteni de asemenea toate metodele clasei EMP .
Se presupune existenta anumitor clase de colectie ca ESET CSET, OSET, NSET si TSET.
Iata declaratiile acestor clase:
1 SET SUBCLASS : ‘ESET’
2 CONSTRAINTS : EMP
Explicatie: Linia 1 defineste un obiect al clasei ESET, o subclasa a clasei definite SET. Linia 2 constringe obiectele clasei ESET sa fie multimi de OID-uri ale obiectelor clasei EMP. In general pot fi un numar nelimitat de obiecte ale clasei ESET, dar noi vo crea numai unul, care va contine multimea OID-urilor tuturor obiectelor EMP care exista actual in baza de date. Informal, singurul obiect ESET poate fi privit ca obiectul analog al clasei EMP.
Definitiile pentru celelalte sunt asemanatoare. In fiecare din aceste cazuri va trebui sa cream citeva obiecte ale clasei de colectie corespunzatoare, nu doar una:
SET SUBCLASS : ‘CSET’
CONSRTAINTS : COURSE
SET SUBCLASS : ‘OSET’
CONSRTAINTS : OFFERING
SET SUBCLASS : ‘NSET’
CONSRTAINTS : ENROLLMENT
SET SUBCLASS : ‘TSET’
CONSRTAINTS : TEACHER
2.5.2 Popularea bazei de date
Vrem sa colectam la un loc OID-urile tuturor obiectelor EMP existente intr-un obiect ESET, deci mai intii trebuie sa cream obiectul de tip ESET:
OID_OF_SET_OF_ALL_EMPS:=ESET NEW
Expresia de la stinga acestei relatii returneaza OID-ul unei instante noi, neinitializate a clasei ESET; OID-ul apoi este asignat variabilei de program OID_OF_SET_OF_ALL_EMPS. Formal, vom spune ca OID_OF_SET_OF_ALL_EMPS denota multimea tuturor angajatilor.
Acum, de fiecare data cind cream un obiect EMP vrem ca OID-ul sau sa fie introdus in obiectul de tip ESET identificat prin OID-ul salvat in variabila de program OID_OF_SET_OF_ALL_EMPS. Definim deci o metoda pentru a crea un astfel de obiect EMP si pentru inserarea OID-ului sau in ESET . Iata metoda:
1 METHOD : ESET “anonim”
2 ADD_EMP# : EMP#PARM “parametri’
3 ADD_ENAME : ENAME_PARM
4 ADD_POS : POS_PARM
5 | EMP_OID| “variabila locala”
6 EMP_OID:=EMP NEW “nou angajat”
7 EMP_OID SET_EMP# : EMP#PARM; “initializare”
8 SET_ENAME :ENAME_PARM
9 SET_POS : POS_PARM
10 SELF ADD : EMP_OID “insert”
11 %
Explicatii:
linia 1 defineste codul care urmeaza sa fie o metoda care se aplica obiectelor de tipul ESET
liniile 2-4 definesc trei parametri, cu nume externe ADD_EMP#, ADD_ENAME si ADD_POS. Aceste nume sunt folosite in mesaje care invoca metoda. Numele interne corespunzatoare sunt EMP#_PARM, ENAME_PARM si POS_PARM care sunt folosite in codul care implementeaza metoda
linia 5 defineste variabila locala EMP_OID si linia 6 asigneaza variabilei OID-ul unui obiect nou EMP, neinitializat
liniile 7-9 trimit un mesaj instantei noi EMP; mesajul specifica metodele care vor fi invocate(SET_EMP#, SET_ENAME si SET_POS) si paseaza argumentul fiecareia dintre ele (EMP#_PARM la SET_EMP#, ENAME_PARM la SET_ENAME si POS_PARM la SET_POS). Presupunem ca metodele SET_ENAME si SET_POS – analoage metodei aratate SET_EMP# – au fost definite inainte.
Linia 10 trimite un mesaj lui SELF, care este un simbol special care denota obiectul asupra caruia ii este aplicata metoda definita in momentul rularii. Mesajul face ca metoda ADD sa se aplice acelui obiect; efectul in acest caz este inserarea OID-ului obiectului identificat de EMP_OID in obiectul identificat de SELF (care va fi obiectul ESET continind OID-ul tuturor obiectelor EMP care exista la momentul actual). Motivul pentru care variabila speciala SELF este utilizata este ca parametrul corespunzator obiectului tinta nu are un nume propriu.
Acum avem o metoda pentru a insera noi EMP-uri in baza de date, dar nu am inserat inca nici unul. Deci:
OID_OF_SET_OF_ALL_EMPS ADD_EMP# : ‘E09’
ADD_ENAME : ‘Helms’
ADD_POS : ‘Janitor’
Comanda de mai sus creeaza un obiect EMP pentru angajatul E09 si adauga OID-ul acestui EMP la multimea OID-urilor tuturor EMP-urilor existente.
Acum ne reintoarcem la cursuri. Angajatii reprezinta cu adevarat cel mai simplu caz posibil caci ei corespund la entitati regulare si nu contin alte obiecte incorporate in ele. Ne mutam acum la cazul mai complex al cursurilor care includ in ele alte obiecte mutabile. Pasii de urmat sunt urmatorii:
Aplicati metoda NEW clasei CSET pentru a crea multimea cursurilor initial goala.
Definiti o metoda pentru a crea un nou obiect COURSE si sa adunati OID-ul sau la multimea de cursuri. Metoda va lua un COURSE# si un TITLE ca argumente si va crea un obiect COURSE cu valorile specificate. Va aplica de asemenea metoda NEW clasei OSET pentru a crea o multime de OFFERING OID-uri initial goala, si va plasa OID-urile acelei multimi goale de OID-uri in pozitiile de OFFERING-uri in noul obiect de tip COURSE
Invocati metoda nou creata pentru fiecare curs in parte.
Acum ne indreptam atentia asupra offering-urilor. De data aceasta pasii sunt urmatorii:
Definiti o metoda pentru a crea un obiect OFFERING nou. Metoda va lua ca argumente OFF#, ODATE si LOCATION si va crea un obiect nou OFFERING cu valorile specificate. De asemenea va:
aplica metoda NEW clasei NSET sa creeze o multime de ENROLLMENT OID-uri initial goala si apoi va plasa OID-urile acelei multimi goale in pozitiile ENROLLMENT in cadrul obiectului OFFERING.
aplica metoda NEW clasei TSET sa creeze o multime initial goala de TEACHER OID-uri si va plasa OID-urile acelei multimi goale in pozitiile TEACHER in cadrul obiectului OFFERING.
Metoda de asemenea va lua ca argument un COURSE# si va utiliza aceasta valoare pentru a:
localiza obictul COURSE corespunzator pentru noul obiect OFFERING. Bineinteles, metoda va refuza orice incercare de a crea un nou offering daca cursul corespunzator nu este gasit
localiza multimea tuturor offering-urilor pentru acel obiect COURSE
adauga OID-ul noului obiect OFFERING multimii potrivite.
Invoca metoda definita pentru fiecare offering in parte.
Mai departe, angajarile. Diferenta dintre obiectele de tip offering si cele de tip angajare este ca obiectele ENROLLMENT includ o instanta de variabila, EMP, a carei valoare este OID-ul obiectului EMP. Secventa de pasi necesara este urmatoarea:
Definiti o metoda pentru crearea unui obiect nou ENROLLMENT. Metoda va lua ca parametri COURSE#, OFF#, EMP#, si GRADE si va crea un obiect nou de tip ENROLLMENT cu valoarea GRADE specificata. Deci va:
folosi valorile COURSE# si OFF# pentru a localiza obiectul OFFERING corespunzator noului obiect ENROLLMENT
localiza multimea tuturor angajarlor pentru acel obiect OFFERING
adauga OID-ul noului obiect ENROLLMENT multimii corespunzatoare
folosi valoarea EMP# sa localizeze obiectul EMP
plasa OID-ul acelui obiect EMP in acea pozitie EMP in cadrul noului obiect ENROLLMENT
Invoca metoda nou creata pentru fiecare angajare in parte
In final profesorii. TEACHER este facut de noi o subclasa a lui EMP. Deci:
Definiti o metoda pentru a crea un obiect TEACHER. Metoda va lua ca parametri COURSE#, OFF#, si EMP#. Va:
folosi valoarea EMP# pentru a localiza obiectul EMP relevant
schimba cea mai relevanta clasa a acelui obiect EMP cu TEACHER. Cum se realizeaza aceasta schimbare de clasa depinde de sistemul avut in discutie
folosi valorile COURSE# si OFF# sa localizeze obiectul OFFERING corespunzator obiectului TEACHER
localiza multimea tuturor profesorilor pentru obiectul de tip OFFERING
adauga OID-ul obiectului TEACHER multimii de profesori
Multimea cursurilor pe care acest profesor poate sa le predea va fi specificata cumva. Omitem detaliile acestui pas din acest motiv
Invoca metoda creata pentru fiecare profesor in parte.
2.5.3 Operatii de recuperare
Consideram un singur exemplu – “Get all New York offering of course C001”. Presupunem ca avem o variabila cu numele OOSOAC a carei valoare este OID-ul multimii tuturor curselor. Iata codul:
1 | COURSE_C001, C001_OFFS, C001_NY_OFFS |
2 COURSE_C001
3 :=OOSOAC DETECT : [ :CX | (CX GET_COURSE#)=’C001’]
4 C001 OFFS
5 :=COURSE_C001_GET_OFFERINGS
6 C001 NY_OFFS
7 :=C001_OFFS SELECT :
8 [ :OX \ (OX GET_LOCATION)=’New York’]
9 C001_NY_OFFS
Explicatii:
Linia 1 declara variabilele locale COURSE_C001, care va fi folosita sa pastreze OID-ul cursei C001; C001_OFFS, care va pastra OID-ul multimii OID-urilor offering-urilor cursei C001; si C001_NY_OFFS care va pastra OID-ul multimii OID-urilor offering-urilor cerute.
Liniile 2-3 trimit un mesaj obiectului prin variabila OOSOAC. Mesajul aplica metoda DETECT colectiei. DETECT este o expresie de forma:
[:x|p(x)]. Aici p(x) este o expresie conditionala iar x este o variabila care ia valori in multimea membrilor colectiei asupra careia este aplicat DETECT. Resultatul lui DETECT este OID-ul primului obiect x intilnit in acea multime astfel incit p(x) ia valoarea true. OID-ul acelei curse este asignat variabilei COURSE_C001
liniile 4-5 asigneaza OID-ul multimii tuturor offering-urilor pt cursa C001 variabilei C001_OFFS
linile 6-8: metoda SELECT este asemanatoare cu cea DETECT, dar returneaza OID-ul multimii de OID-uri ale tuturor obiectelor x astfel incit p(x) este true. In exemplu, se asigneaza OID-ul multimii OID-urilor offering-urilor New York ale cursei C001 variabilei C001_NY_OFFS
linia 9 returneaza OID-ul
Cind spunem ca DETECT returneaza OID-ul primului obiect intilnit astfel incit p(x) este adevarata, trebuie sa tinem seama de secventa de cautare pe care o foloseste OPAL. Metodele in OPAL nu au nume. Totusi noi vom folosi expresii de genul “metoda DETECT”.
2.5.4 Operatii de update
Update: Operatiile de update sunt executate in aceeasi maniera ca si operatiile de recuperare, cu exceptia utilizarii metodelor SET_ in locul celor GET_ .
Delete: Metoda REMOVE este folosita pentru a sterge obiecte. Cind un obiect nu mai poseda nici o referinta prin care sa se poata ajunge la el, atunci OPAL il sterge automat folosind un “garbage collector”. Iata un exmplu:
E001:= OID_OF_SET_OF_ALL_EMPS
DETECT :[:EX | (EX GET_EMP#)=’E001’]
OID_OF_SET_OF_ALL_EMPS REMOVE : E001
Putem de asemenea care sterge un angajat si de asemenea toate angajarile pentru acel angajat. Obiectele OFFERING nu inlud OID-ul obiectului COURSE corespunzator si deci offering-urile nu restrictioneaza pe DELETE. De fapt avem de-a face cu o regula ON DELETE CASCADE, in afara cazului cind utilizatorul include OID-ul parintelui copilului sau cind include OID-ul copilului intr-un alt obiect in baza de date .
2.6 Interogari Ad Hoc
Daca singurele metode definite pentru clasa DEPT sunt HIRE_EMP, FIRE_EMP si CUT_BUDGET atunci o interogare ca “Cine este managerul departamentului de programare?” este imposibila. Solutia pe care noi o recomandam este:
Definiti o multime de operatori care expun o posibila reprezentare pentru obiectele in discutie.
Includeti obiectele intr-o fereastra de lucru relationala.
Se ridica o alta importanta intrebare din interogarile ad hoc si anume ce clasa rezulta?. De exemplu presupunem ca executam interogarea “Numele si salariul pentru angajatii din departamentul de programare”. Posibil ca rezultatul sa fie ENAME si SALARY. Dar nu este nici o clasa in baza de date care sa aiba o asemenea structura. Trebuie noi sa predfinim o asemenea clasa inainte d a executa interogarea? Si daca in final cream o astfel de clasa ce meode i se aplica? Intrebari analoage se ridica si in cazul operatiilor de alaturare.
2.6.1 Integritate
Consideram urmatorul exemplu de constringere: “Nici un finantator cu un status mai mic de 20 nu poate finanta nici o parte cu o cantitate mai mare de 500”. Codul procedural care sa realizeze acest lucru trebuie sa includa cel putin urmatoarele metode:
Metoda care sa creeze o livrare
Metoda care sa schimbe cantitatea unei livrari
Metoda care sa schimbe status-ul unui livrator
Metoda care sa asigneze o livrare la un livrator diferit
Intrebari care se ridica:
Am pierdut posibilitatea ca sistemul sa determine singur cind sa faca verificarea integritatii
Cum ne asiguram ca toate metodele necesare includ toate liniile de cod necesare
Cum prevenim utilizatorul sa treaca peste metoda de creare a livrarii si sa aceeseze direct metoda NEW direct asupra obiectului livrare si deci sa treaca peste verificarea integritatii?
Daca constringerea se sshimba cu gasim metodele care trebuie sa fie rescrise?
Cum ne asiguram daca codul scris este corect?
Cum ramine cu constringerile de tranzitie?
Cum interogam sistemul sa gaseasca toate interogarile care se aplica asupra unui obiect?
Cum ramine cu optimizarea semantica?
2.6.2 Relatii
Intr-un sistem obiect sunt trei posibilitati:
Angajatii pot include un OID al departamentelor.
Departamentele pot include o multime de OID-uri ale angajatilor
2 si 3 pot fi combinate ca mai jos:
CLASS EMP…
(…DEPT REF(DEPT) INVERSE DEPT.EMPS)…;
CLASS DEPT….
(…EMPS
REF (SET(REF(EMP))) INVERSE EMP.DEPT)….;
Instantele de variabila EMP.DEPT si DEPT.EMPS sunt una inversa celeilalte. EMP.DEPT este o variabila referinta si DEPT.EMPS este o variabila multime de referinte.
Este o intrebare evidenta care se ridica: Cum procedeaza sistemele obiect in cazul in care relatiile sunt intre mai multe clase, spre exemplu livrator, parte si proiecte? Cel mai bun raspuns este crearea unei clase SPJ astfel incit fiecare obiect SPJ are o relatie de tip “variabile inverse” cu livratorul apropiat, cu partea apropiata si cu proiectul apropiat. Dar acum ne intrebam de ce relatiile de gradul doi nu sunt tratate in acelasi mod?
De exemplu, obiectele analoage ale expresiilor rationale:
SP.P# WHERE SP.S#=S#(‘S1’)
SP.S# WHERE SP.P#=S#(‘P1’)
Arata cam asa:
S.PARTS.P# WHERE S.S#=S#(‘S1’)
P.SUPPS.S# WHERE P.P#=P#(‘P1’)
Integritate referentiala: Avem urmatoarele posibilitati:
Nici un suport de sistem: Integritatea referentiala este responsabilitatea codului scris de utilizator
Validarea referintelor: Sistemul verifica daca toate referintele pointeaza la obiecte de tip corect, caz in care s-ar putea ca stergerea obiectelor sa nu fie permisa, fiind totusi permisa utilizarea unui colectionar de deseuri. Acest nivel de suport este echivalent cu o regula de tipul ON DELETE CASCADE pentru subobiectele neimpartite si cu o regula ON DELETE RESTRICT pentru alte obiecte
Mentinerea sistemului: Acest nivel de suport este echivalent cu regula ON DELETE SET NULL
Semantici particulare: Un exemplu ar fi ON DELETE CASCADE.
2.7 Sumar
Iata o lista a principalelor elemente ale modelului obiect pe care l-am prezentat:
Clase obiect – esentiale
Obiecte – mutabile si imutabile sunt esentiale
ID-ul obiectelor – nenecesare si de nedorit pentru ca pina la urma sunt doar pointeri.
Incapsulare – inseamna doar “scalar”
Instante de variabile – de tip private sau protected nu sunt relevante pentru definirea unui model abstract, ceea ce ne intereseaza pe noi aici. Instante de variabila publice nu exista intr-un sistem obiect pur si dci nu ne intereseaza. Deci ele pot fi ignorate.
Ierarhia de continut – este irelevanta caci contine OID-urile obiectelor si nu obiectele in sine.
Metodele – conceptul este esential bineinteles, desi am prefera sa utilizam mai degraba termenul de operatori. Preferam sa definim clase si metode separat. Sunt anumiti operatori asupra carora insistam: selectorii(operatiile THE_), operatorii de asignare, de testarea egalitatii. Constructorii construiesc variabile. Singurul constructor de care avem nevoie este cel care creeaza un relvar(CREATE TABLE sau CREATE VIEW in SQL). Selectorii, prin contrast, selecteaza valori. In timp ce constructorii returneaza pointeri la obiectele create, selectorii returneaza valoarea selectata.
Mesaje – conceptul este esential, desi am prefera sa folosim termenul de invocare.
Ierarhia de clase – de dorit insa ortogonala
Clasa vs mostenire vs colectie – de dorit, insa ortogonale
Relatii
Limbaje de programare cu baze de date integrate – bune de avut, insa ortogonale. In zilele noastre limbajele suportate actual sunt procedurale(3GL)
Si iata acum o lista a elementelor pe care modelul obiect nu le suporta sau nu le suporta bine:
Interogari ad hoc
View-uri – nesuportate
Constringeri declarative de integritate – de obicei nesuportate
Chei straine – exemple ca ON DELETE RESTRICT sau ON DELETE CASCADE
Inchiderea
Catalogarea
CAPITOLUL III
TOPICI DE MODELARE AVANSATE
IN BAZA DE DATE
In acest capitol se prezinta un model de date orientat-obiect care apartine lui Manojit Sarkar si lui Steven P. Reiss[ ].Acest model de date reprezinta toate entitatile ca obiecte.Un obiect este complet identificat printr-un identificator de obiect.Un obiect este caracterizat de o stare(instanta) si o comportare.Fiecare obiect aprtine la o clasa.Clasa defineste structura instantei obiectelor si comportarea lor.Clasele sunt organizate prin ierarhii de mostenire in sensul ca un obiect al clasei ά poate fi utilizat in locul unui obiect al oricarei supraclase a lui ά.
Polimorfismul de mostenire este dat de ultimele legaturi ale metodelor de baza pentru clasa actuala de obiecte.Modelul de date elimina dihotomia obiect-versus-valori prin reprezentarea tuturor entitatilorca obiecte.Acesta este un atribut al performantei si al puterii de modelare.
3.1 Introducere
Bazele de date orientate obiect au fost dezvoltate ca raspuns la nevoile de modelare a datelor complexe din diferite domenii de activitate ca:medii de programare,CAD,grafica etc. Ne vom limita la sistemele de gestiune a bazelor de date orientate obiect ,de construire a informatiilor abstracte despre programe numite abstractii program.Modelul de date al sistemului de programe de vizualizare este orientat obiect si am dorit o baza de date cu un model de date compatibil.Obiectul initial al modelului este acela de a combina simplitatea ,puterea de modelare si performanta.Aceasta elimina dihotomia obiect-versus-valoare care se intalneste la modelele de date din O2 si EXTRA.Vom arata ca este posibil sa satisfaca domenii diverse de modelare ca:obiecte compuse din ORION si obiecte own si ref din EXTRA,impreuna cu paradigma orientata obiect.Pe de alta parte nici O2 si nici EXTRA nu dau acces exclusiv la obiecte cu OID si cu compunerea.Simplitatea conceptuala a modelului de date nu micsoreaza performanta.Este posibil sa se proiecteze optimizari interne cu performante bune.
3.2 VALORI
Vom incepe descrierea formala a modelului de date cu urmatoarele multimi de puncte:
– D -o multime finita de tipuri de baza
– O -o multime infinita si numarabila de identificatori de obiecte
– A -o multime finita de nume de atribute
– M -o multime finita de nume de metode
– C -o multime finita de nume de clase
Fiecare obiect este identificat in mod unic de un identificator de obiect sau oid. Obiectul poate avea o valoare sau valoarea sa poate fi nedefinita.Fiecare obiect apartine unei clase.Numai valorile structurate pot fi valori de obiecte.Valorile structurate sunt compuse din valori atomice.
3.2.1 VALORI ATOMICE
Exista patru tipuri de baza;acestea sunt:
-Integer
-Float
-Boolean
-String
Prin urmare D={Integer,Float,Boolean,String}.
Domeniile tipurilor de baza vor fi numite domenii de baza.Fiecare domeniu consta dintr-o multime numarabila infinita de valori atomice.De exemplu domeniul tipului integer constra din multimea tuturor valorilor intregi.Valorile atomice din domeniile de baza sunt numite valori de baza,pentru a le deosebi de identificatori(oid-uri).
Un tip este fie o clasa fie un tip de baza.Clasele sunt generate din tipuri de baza si clase care utilizeaza constructorii de :tupluri,multimi si liste.O clasa construita prin utilizarea tuple se numeste clasa-tuplu,respectiv clasa-multime si clasa-lista pentru ceilalti constructori.
Exista trei termeni speciali:
– nulltuple
– nullset
– nulllist
Cu aceste elemente speciale sunt notate toate obiectele nedefinite ale claselor de tip tuplu respectiv multime si lista.Valoarea unui obiect nedefinit este presupusa necunoscuta sau o multime vida sau o lista vida care depind de clase de obiecte.
Fiecare element al lui O este deasemenea o valoare atomica.
3.2.2 VALORI STRUCTURATE
Valorile structurate sunt construite din valori atomice utilizand constructorii Tuple,List si Set.Exista o valoare structurata speciala [ ] care este utilizata pentru a nota valoarea oricarui tuplu cu zero atribute.Trebuie observat ca semnul [ ] si tuplul null nu au aceleasi valori ,primul noteaza o valoare structurala ,in timp ce al doilea este o valoare atomica si oid-ul unui obiect a carui valoare este nedefinita . Valorile structurate sunt definite formal dupa cum urmeaza:
– valoarea [ ] este o valoare structurata;
– fiecare tuplu de valori atomice[A1:V1,A2:V2,……..A.n:Vn] este o valoare tuplu unde: n>0,Ai A siVi sunt nume de atribute si
respectiv valori atomice pentru i=1,2,….n
– fiecare multime de valori atomice {V0,V1,…,Vn} este o valoare -multime unde:n>0, si Vi sunt valori atomice pentru
i=1,2,….n
– fiecare lista de valori atomice <V0,V1,…,Vn> este o valoare-lista,unde:n>0, si Vi pentru i=1,2,…..n sunt valori atomice
Nu exista o ordine printre elementele unei multimi.Numai omogene(liste) sunt permise ,adica tipurile tuturor elementelor oricarei multimi(liste) trebuie sa fie aceleasi.Un obiect -multime a carui valoare este multimea vida este echivalent cu un obiect nedefinit al unei clase multime.Similar un obiect -lista a carui valoare este o lista vida este echivalent cu un obiect nedefinit al unei clase-lista.
Vom nota multimea tuturor valorilor structurate ,care este o multime infinita si numarabila,cu V.
3.3 CLASE
Fiecare obiect este instantierea unei clase.Clasa care descrie structura valorilor obiectelor si comportarea obiectelor.Sintaxa de definire a clasei este urmatoarea:
<declaratie clasa> Class <nume-clasa>
Class<nume-clasa> <definitie – clasa>
<definitie clasa> [inheriths <nume – superclasa>]
<structura clasa >
[Methods {<metoda – clasa>}]
<structura clasa> Tuple '( ' {<definitie- atribut >}' ) '
Set '( ' <tip- de -baza > ' ) '
Set '( '<[own] < nume – clasa> ' ) '
Set '( '<[own] <structura – clasa> ') '
List '( ' <tip – de- baza>') '
List '( ' [own] < nume – clasa > ') '
List '( ' [own] <structura – clasa >') '
<definitie – atribut><nume – atribut> ': ' <tip – de – baza>
<[own] <nume – atribut > ': ' <nume – clasa>
<[own] <nume – atribut > ':' <structura – clasa>
<metoda – clasa> <antet – metoda> <corp – metoda>
<antet – metoda> <nume – metoda> '( '<definitie – parametru>)
' : ' <definitie – rezultat>
<definitie – parametru> <tip-de-baza>
<nume-structura>
<structura-clasa>
<definitie-rezultat> <tip-de-baza>
<nume-clasa>
<structura-clasa>
<corp-metoda> '{ ' <code > '} '
O clasa poate fi definita prin specificarea unui nume ,unei superclase si a metodelor.Superclasele si metodele sunt optionale.Este posibil sa definim clase implicit fara nume,superclasa si metode.
In exemplul 1 sunt definite explicit opt clase :Punct,Varf,Nod,Muchie,Segment,Curba,Retea si Graf.Sunt deasemenea declarate implicit cateva clase fara nume,fara superclase si fara metode.
Clasa care corespunde punctelor de curbura a clasei muchie_dreapta este o astfel de clasa cu structura list.Este posibil sa definim recursiv astfel de clase ca de exemplu clasa Nod din exemplul 1.Se permite ca un nume de clasa sa fie declarat si utilizat inainte de a fi definit ca de exemplu clasa Muchie din acelasi exemplu 1.
Exemplul 1
Class Punct
Tuple ( x: Float ,y : Float )
methods {distanta (punct) : {………} };
Class muchie ;
Class Varf
Tuple ( own pozitie : punct,
eticheta : String ,
raza : Float ) ;
Class Nod
Inherit Varf ;
Tuple ( succesori : Set (Nod) );
Class Muchie
Tuple ( inceput :Varf,
end : Varf,
eticheta : String)
Methods {(lungime ( ) : Float {…}}
Class Muchie-dreapta
Inherit Muchie
Tuple (own punct- de- curbura :List(punct) )
Methods{lungime ( ) :Float {…} };
Class Muchie-curba
Inherit Muchie
Tuple (own punt-de -control :Lista(punct) )
Methods {lungime ( ) : Float {…} };
Class Retea Set (varfuri) ;
Class Graf Set (nod) ;
3.3.1 Structura clasei
Toate clasele trebuie sa aiba o structura.Cum s'a aratat mai sus structurile sunt construite prin utilizarea constructorilor Tuple,Set,List din tipuri de baza si din nume de clase deja declarate.O clasa construita numai prin utilizarea constructorului Tuplu se numeste clasa tuplu.Similar o clasa construita numai prin utilizarea constructorului Set se numeste clasa set(multime)si o clasa generata prin utilizarea constructorului List se numeste clasa lista.Valoarea oricarui obiect a oricarei clase tuplu poate fi numai o valoare tuplu.Similar ,valoarea unui obiect a oricarei clase multime poate fi numai o valoare multime si valoarea unui obiect a oricarei clase lista poate fi numai o valoare lista.Orice obiect poate fi referit de mai multe alte obiecte.Uneori este necesar sa se interzica aceasta impartire si sa permita ca o clasa de obiecte sa fie referita de alte obiecte.Aceasta restrictie poate fi specificata utilizand in definitia atributului calificativul own.Un obiect ce are un atribut specificat cu own(adica propriu) nu poate fi referit de mai mult de un obiect.
3.3.2 Metode
O declaratie a unei clase poate avea una ,mai multe sau nici o metoda.Metodele definesc comportamentul obiectelor.Fiecare metoda este o functie care are un antet si un corp.Corpul metodei este o parte a codului scris intr-un limbaj de programare.
Exemplul 2
In exemplul 1 sunt definite patru metode pentru clasele :Punct,Muchie,Muchie-dreapta,Muchie-curba. Anteturile acestor metode sunt:
Point : distanta (Punct) Float ;
Muchie : lungime ( ) Float ;
Muchie – dreapta : lungime ( ) Float ;
Muchie – curba : lungime ( ) Float ;
3.3.3 Mostenirea
O definitie a unei clase poate cuprinde o superclasa ca o parte a definitiei sale.Mostenirea permite utilizatorului sa obtina noi clase din clasele existente.In modelul de date prezent in acest capitol nu este permisa decat mostenirea directa ,adica o clasa poate sa aiba cel mult o superclasa.
Relatia de mostenire este o ordine partiala pe clase adica este reflexiva ,antisimetrica si tranzitiva.Deoarece superclasele sunt optionale,ierarhia de clase care rezulta nu poate fi reprezentata ,de obicei,de un singur arbore,ci de mai multi arbori disjuncti.
O clasa mosteneste atribute si metode ale superclasei sale prin lipsa.Structura si own-ul de metoda al unei clase mostenite,include din acel motiv,atributele mostenite si metodele respective.
Clasele care mostenesc pot avea in plus atribute si metode sau pot redefini metode si atribute mostenite.Totusi structura care rezulta si multimea de metode a unei clase care mosteneste trebuie sa fie compatibile cu structura si multimea de metode ale superclasei.
3.3.4 Relatia de subclasa
Relatia de subclasa este notata cu simbolul < .Daca c este o subclasa a lui c' atunci c<c'.Compatibilitatea setului de structuri si metode permit ca numai doua clase sa fie legate prin relatia subclasa-superclasa.
>Substituire
Relatiile (legaturile) de subclasa permit ca un obiect al clasei c sa fie utilizat in orice context care necesita un obiect din clasa c' cand c' este o superclasa a lui c.Cu alte cuvinte ,un obiect al oricarei clase c este totodata un obiect al tuturor superclaselor din c.
>Legatura dinamica(Late binding )
Deoarece un obiect al unei anumite clase poate fi atribuit unei variabile a superclasei sale,dandu'se o metoda care face apel la o variabila ,uneori metoda care se executa poate fi determinata doar in timpul executiei programului pe baza clasei careia apartine obiectul.Acest mod de lucru e cunoscut sub numele de Late binding.
>Supraincarcarea
Numele de metoda poate fi de asemenea supraincarcat (supradefinit) prin definirea metodelor cu acelasi nume in mai mult de o clasa nelegate prin legatura dintre subclasa-superclasa.Astfel,selectarea metodei "adecvate" dintre metodele cu acelasi nume se face in timpul compilarii pe baza anteturilor metodelor.
>Clase declarate implicit
Prin urmare clasele declarate implicit nu au nume,ele nu pot fi declarate ca subclase sau superclase ale altei clase.Sistemul poate presupune ca o clasa declarata implicit nu are subclase si poate optimiza reprezentarea si accesul acestor clase pentru a mari performanta.
>Echivalenta claselor
Doua clase sunt echivalente daca si numai daca au acelasi nume.Sistemul da nume generat intern,clasele declarate implicit drept clase asociate,ca de exemplu punct-de-ramificare din exemplul 1.Clasele declarate implicit care au aceeasi structura primesc acelasi nume intern si prin urmare sunt echivalente.
>Functia de definire a clasei
Vom defini o functie partiala care face sa corespunda unui nume de clasa din C o definitie a clasei.Ca de exemplu dupa ce am definit clasele in exemplul 1 avem :
(Punct) = Tuple (x:Float,y:Float)
methods {distanta (Punct) {. . . . .} }
Functia este admisa pentru clasele care au fost declarate dar nu au fost definite.Schemabazei de date include aceasta functie.
3.4 Obiecte
Valoarea unui obiect poate fi definita sau nedefinita.Un obiect a carei valoare este definita este un triplet (o,v,c) unde o apartine lui O si este identificatorul obiectului (oid),v apartine lui V si este valoarea obiectului,iar c este o clasa de obiecte si aprtine lui C.
Daca valoarea obiectului este nedefinita atunci identificatorul lui trebuie sa fie nulltuple,nullset sau nulllist.Un obiect al carui identificator este nulltuple este un obiect al clasei de tupluri.Similar ,un obiect cu identificatorul nullset este un obiect al unei clase multime si un obiect cu identificatorul nulllist este un obiect al clasei lista. Un obiect a carui valoare este nedefinita este numit obiect nedefinit.
Consideram functia partiala : O v ,functia care face sa corespunda unui identificator al unui obiect valoarea sa pentru orce obiect din baza de date.Interpretarea valorii depinde de clasa. De aici incolo vom presupune ca valoarea v a unui obiect(o,v,c) este definita.
Definim functia astfel:
daca o este identificatorul unui obiect dintr-o clasa tuplu oarecare atunci (O) este o valoare tuplu;
daca o este identificatorul unui obiect dint-o clasa lista oarecare atunci (O) este o valoare lista;
daca o este identificatorul unui obiect dint-o clasa multime oarecare atuci (O) este o valoare multime;
Ori de cate ori cand un obiect al unei clase este creat in baza de date cu o valoare definita aplicatia este actualizata.Instanta unei scheme a unei baze de date include functia .
Sistemul ofera trei operatori de egalitate si doi operatori de copiere .Operatorii de egalitate testeaza "id-equality" ,"shallow equality"(egalitatea slaba) si "deep equality"(egalitatea tare).
3.4.1 Operatorii de egalitate
Sistemul este inzestrat cu trei operatori de egalitate care testeaza id-galitate,egalitatea-slaba si egalitatea-tare:
id-egalitate : doua valori de baza sunt id-egale daca ele au aceleasi valori.Doua obiecte sunt id-egale cand ele sunt definite si au acelasi identificator(oid).Pentru notarea id-egalitate se utilizeaza simbolul "= " .
egalitatea -slaba: se noteaza cu simbolul "=s". Doua valori de baza sunt slab-egale daca ele sunt id-egale.Doua obiecte sunt slab-egale daca ele sunt id-egale.Daca nu sunt id-egale atunci sunt slab-egale numai daca valorile lor sunt id-egale.Ovaloare poate fi o valoare-tuplu,o valoare -multime sau o valoare lista.Daca valorile sunt valori tuplu ,atunci numele de atribute corespunzatoare trebuie sa fie id-egale.Daca doua valori sunt valori multime atunci ele trebuie sa aiba aceeasi cardinalitate si exista o aplicatie bijectiva intre elementele multimilor si elementele corespunzatoare sunt id-egale.Daca valorile sunt liste de valori lungimile listelor trebuie sa aiba aceeasi lungime si elementele listelor trebuie sa fie aceleasi.
egalitatea-tare: se noteaza cu simbolul "" . Orice doua valori de baza sunt tare egale daca ele sunt id-egale.Orice doua obiecte sunt tare egale daca sunt slab egale.Daca ele nu sunt slab egale atunci ele sunt tare egale daca valorile contin iod-uri si obiectele reprezentate prin oid-urile corespunzatoare sunt slab egale.
3.4.2 Copiere
Asemanator operatorilor de egalitate sistemul da doi operatori de copiere:
s-copiere : O s-copie (copie slaba) a unui obiect este un obiect cu aceeasi valoare si clasa cu obiectul dat ,dar oid diferit
d-copiere :O d-copie (copie tare) a unui obiect este un obiect care are o aceeasi clasa cu obiectul dat,dar oid diferit si posibil o valoare diferita creata aplicand recursiv operatorul de d-copiere.
Operatiile de copiere sunt utile atata timp cat asignam valori la atributele own prin copierea obiectelor existente.
>Redefinirea operatorilor de egalitate si copiere
Numai operatorii de slaba egalitate ,tare egalitate si ambii operatori de copiere pot fi redefiniti de metodele definite in clase.Acestea permit utilizatorului sa defineasca operatori de egalitate si operatori de copiere potriviti pentru diferite clase de obiecte.
3.5 Baza de date
O baza de date consta dintr-o schema si o instanta.Schema bazei de date este notata cu S. O instanta a schemei bazei de date este notata cu I.
Exista o separare evidenta intre schema si instanta in modelul prezentat aici. O schema a bazei de date declara in mod explicit o mostenire de clase c din C. Sistemul pastreaza o extensie pentru fiecare clasa din C.
3.5.1 Schema
O schema a bazei de date este un triplet (c,,G) unde:
cC este o multime de nume de clasa
este functia care face sa corespundaunui nume de clasa o definitie de clasa
G este o multime de variabile globale pentru clasele asociate
Multimile c si G actioneaza ca puncte de intrare in baza de date.
Orice obiect cu un nume global in G este persistent.
Orice obiect care este o parte a unui obiect persistent este persistent.
Functia aplica unui nume de clasa o definitie de clasa.Ierarhia de clase poate fi construita din informatii disponibile la definitia claselor.
3.5.2 Instante
O instanta a unei scheme a bazei de date consta dintr-o multime finita de obiecte si urmatoarele patru functii: ,Π , ,v care au semnificatiile:
:functia de atribuire disjuncta de oid-uri;
Π :functia de atribuire de oid-uri mostenita din ;
:functia care face sa corespunda oid-urilor valorile tuturor obiectelor din instantierea bazei de date;
v :functia care face sa corespunda numelor din G obiecte ca valori atribuite curent variabilelor;
BIBLIOGRAFIE
1. C.J. Date –- "An Introduction to Database Systems",ADDISON-WESLEY PUBLISHING COMPANY,2002
2. J. Edgar, M. Ester –-"Databases Systems and Structures",ACADPRESS,2001
3. W.Luk–"Databases Systems", UNIV. OF BRITISH COLUMBIA ,2001
4. M. Stonebraker–"Object / Oriental Databases" ,CAMPUS PRESS,2001
5. Michael Hernandez–"Proiectarea baxelor de date ",tEORA ,1998
6. Paul Petrus–"Microsoft Visual FoxPro" ,Promedia-Plus,1998
7.******–"Microsoft Visual FoxPro-Professional Features",Microsoft Corporation,1998
8.******–"Microsoft Visual FoxPro-Programmer's Guide ",Microsoft Corporation,1998
9. http:/www.microsoft.com
10.http:/www.internetindicators.com
CAPITOLUL IV
PREZENTAREA APLICAȚIEI CASA DE AMANET
Pentru rezolvarea acestei probleme s-au folosit cunoștințele asimilate la orele de teorie și în laboratorul de informatică, au fost în vizită la diverse case de amanet pentru a studia modul de lucru și pentru a înțelege specificul activităților desfășurate de acestea.
Componentele aplicației
Baza de date a aplicației utilizează 3 tabele : clienti, contracte și produse.Tabelul clienti reține toti clienții casei de amanet la un moment dat, având următoarele câmpuri :
Unde : ID – este cheie primară și reprezintă codul clientului ;
NUME – reține numele clientului ;
PRENUME – reține prenumele acestuia ;
DATA NASTERII – reține data de naștere a clientului (acesta trebuie sa aibă peste 18 ani – condiție de validare a datelor);
SRADA – reține strada clientului ;
NR – reține numărul străzii clientului ;
BLOC – reține blocul acestuia ;
LOCALITATEA – reține localitatea acestuia ;
SERIE B.I – reține seria B.I al clientului ;
NR B.I – reține nr B.I al clientului ;
Tabelul contracte reține contractele încheiate între casa de amanet și clienții acesteia, având următoarele câmpuri :
Unde : ID – reprezintă codul clientului ;
NR_CONTRACT – reprezintă nr. contractului (cheie primară );
COD_PRODUS – reprezintă codul produsului amanetat de client ;
DATA_ADUCERII PRODUSULUI – reține data la care produsul a fost adus de client ;
LEI –suma pe care clientul a primit-o pentru obiectul adus ;
Tabelul produse reține obiectele clienților aduse la casa de amanet, având următoarele câmpuri :
Unde : COD_PRODUS – este cheie primară și reprezintă codul produsului amanetat de client ;
NUME – retine numele obiectului amanetat ;
La lansarea în execuție a aplicației se va afișa meniul principal :
– iese din aplicație folosind un macro;
– deschide submeniul :
– deschide submeniul în care se găsesc toate formularele :
– deschide formularul în care se adaugă contractele:
– închide formularul;
– deschide formularul în care se adaugă clienții:
– deschide formularul în care se adaugă produsele:
– deschide formularul care are la baza interogarea de selecție contractele unei anumite persoane care are ca parametru numele și prenumele unei persoane furnizând informații despre persoana respectivă:
– deschide formularul care are la bază interogarea contracte expirate, afișând contractele expirate existente la data respectivă:
– deschide formularul care are la bază interogarea contracte neexpirate, afișând contractele neexpirate existente la data respectivă ;
– închide formularul;
– deschide submeniul cu toate rapoartele:
– fiecare buton asociat acestui formular deschide raportul respectiv (clienti – raportul “Clienți”; contracte expirate – raportul “Contracte expirate”; informații despre clienți – are la baza o interogare de selecție, care are ca parametru numele și prenumele unei persoane), mai puțin care închide formularul folosind o macrocomandă;
– deschide interogarea de ștergere
BIBLIOGRAFIE
1. Connolly Thomas., Begg Caroline
DATABASE SYSTEMS A Practical Approach to Design Implementation and Management ADDISON WESLY 2002
2. Date, C. J.
AN INTRODUCTION TO Database Systems fourth Edition
ADDISON-WESLEY PUBLISHING COMPANY 1997
3. Date, C. J.
Baze de date Editia a opta E+ 2006
4. Despi Ioan, Luca Lucian
BAZE DE DATE ORIENTETE PE OBIECTE
Mirton Timisoara 1996
5. Dolinger R.
Baze de date distribuite Ed. Albastra 2001
6. Fehily Chris
SQL visual quicstart guide B.I.C. ALL 2002
7. Fotache Marin
SQL Dialecte DB2,Oracle,VisualFoxPro Publirom 2001
8. Fotache Marin
Proiectarea bazelor de date Normalizare si postnormalizare Polirom
9. Fotache Marin, Strimbei Catalin Cretu Liviu
ORACLE 9i2 Ghidul dezvoltarii aplicatiilor profesionale POLIROM
10. Grant Tom
Oracle Power Objects Teora 1997
11. Halpin Terry
Information Modeling and Relational Databases From Conceptual to
Logical Design Morgan Kaufman Publisher
12. Henderson Ken
Transact-SQL Teora 2000
13. Henderson Ken
Proceduri stocate in SQL Server.XML, HTML Teora 2003
14. Ionescu Felicia
Baze de date relationale si aplicatii
EDITURA TEHNICA 2006
15. Ipate Florin.Popescu Monica
Dezvoltarea aplicatiilor de baze de date I ORACLE 8 si FORMS 6
ALL 2000
16. Ju Patricia Databases on the Web Designing and Programming for
Network Access Pencom Web Works 1997
17. Korth H, Silberschatz A.
Systemes de bases de donnees Mcgraw 1988
18. Luers Tom
Bazele oracle 7.2 Teora 1997
19. Lupsoiu Constantin
Baze de date (note de curs)
20. Lupsoiu Constantin
Baze de date distribuite si orientate-obiect
21. Lupsoiu Constantin
Baze de date client/server (note de curs)
22. Martin James, Leben Joe
23. C.J. Date –- "An Introduction to Database Systems",ADDISON-WESLEY PUBLISHING COMPANY,2002
24. J. Edgar, M. Ester –-"Databases Systems and Structures",ACADPRESS,2001
25. W.Luk–"Databases Systems", UNIV. OF BRITISH COLUMBIA ,2001
26. M. Stonebraker–"Object / Oriental Databases" ,CAMPUS PRESS,2001
27. Michael Hernandez–"Proiectarea baxelor de date ",tEORA ,1998
28. Paul Petrus–"Microsoft Visual FoxPro" ,Promedia-Plus,1998
29.******–"Microsoft Visual FoxPro-Professional Features",Microsoft Corporation,1998
30.******–"Microsoft Visual FoxPro-Programmer's Guide ",Microsoft Corporation,1998
31. http:/www.microsoft.com
32.http:/www.internetindicators.com
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: . Topici de Modelare Avansate In Baza de Date (ID: 148999)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.