Gestiunea Unor Obiecte Intr Un Mediu Multiuser
Cap. 1. Introducere
1.1. Contextul temei
1.2. Domeniul temei
Cap. 2. Modelul bazelor de date orientate pe obiecte
2.1. Baze de date relationale
2.2. Elemente de algebra relationala
2.3. Trecerea la dezvoltarea obiectelor
2.4. Maparea relational-obiectuala
2.5. Baze de date orientate pe obiecte. Definitii. Principii
2.6. Realizarile bazelor de date orientate pe obiect
2.7. Puncte slabe ale bazelor de date orientate pe obiect
2.8. Asemanari si deosebirii intre bazele de date relationale si cele orientate pe obiecte
Cap. 3. Proiectarea aplicatiei
3.1. Sistemul de fisiere
3.2. Matisse
3.3. Matisse Php extins
3.4. Adobe Flex
3.5. Arhitectura Multitier
Bibliografie
29 pagini
=== bdoo ===
Cap. 1. Introducere
1.1. Contextul temei
1.2. Domeniul temei
Cap. 2. Modelul bazelor de date orientate pe obiecte
2.1. Baze de date relationale
2.2. Elemente de algebra relationala
2.3. Trecerea la dezvoltarea obiectelor
2.4. Maparea relational-obiectuala
2.5. Baze de date orientate pe obiecte. Definitii. Principii
2.6. Realizarile bazelor de date orientate pe obiect
2.7. Puncte slabe ale bazelor de date orientate pe obiect
2.8. Asemanari si deosebirii intre bazele de date relationale si cele orientate pe obiecte
Cap. 3. Proiectarea aplicatiei
3.1. Sistemul de fisiere
3.2. Matisse
3.3. Matisse Php extins
3.4. Adobe Flex
3.5. Arhitectura Multitier
Bibliografie
29 pagini
Introducere
Contextul temei
Proiectul are ca scop gestiunea unor obiecte intr-un mediu multiuser cu aplicabilitate in mai multe domenii. Poate fi folosit pentru mai multe tipuri de servicii, cum ar fi: sharing system ,content management system etc.
Pentru aceasta exista utilizatori care la creare vor primi drepturi de acces. Fiecare utilizator are resurse proprii, aranjate intr-o structura arborescenta si poate da la randul sau anumite drepturi altor utilizatori pentru resursele pe care le detine, sau le poate transfera.
Fiecare nod din arbore reprezinta cate un obiect din baza de date (entitate). Nodurile frunza
reprezinta entitati propriu-zise cum ar fi: text, imagine, aplicatii, servicii, obiecte multimedia ,iar restul nodurilor sunt cataloage.
1.2 Domeniul temei
Sistemele de baze de date sunt o componentă esențială a vieții de zi cu zi în societatea modernă.
Față de vechile metode de înregistrare a datelor privind diferite activități pe fișe (documente scrise) sau chiar în fișiere pe disc, sistemul de baze de date oferă avantaje considerabile, ceea ce explică extinsa utilizare a acestora. Câteva dintre avantajele oferite sunt prezentate în continuare :
Viteză mare de regăsire și actualizare a informațiilor
Compactitate ridicată : volumul ocupat de sistemele de baze de date este mult mai redus decât volumul ocupat de documente scrise sau de fișiere necorelate
Redundanță scăzută a datelor memorate, care se obține prin partajarea datelor între mai mulți utilizatori și aplicații. În stocarea pe fișe sau în fișiere a datelor, fiecare aplicație conținea propriile seturi de date. În sistemele de baze de date, mai multe aplicații pot folosi date comune, memorate o singură dată
Menținerea integrității datelor prin politica de securitate (drepturi de acces diferențiate în funcție de rolul utilizatorilor), prin gestionarea tranzacțiilor și prin refacerea datelor în caz de funcționare defectuoasă a diferitelor componente hardware sau software
Independența datelor față de suportul hardware utilizat. Sistemele de gestiune a bazelor de date oferă o vedere (view) externă a datelor, care nu se modifică atunci când se schimbă suportul de memorare fizic, ceea ce asigură imunitatea structurii bazei de date și a aplicațiilor la modificări ale sistemului hardware utilizat
Modelul bazelor de date orientate pe obiecte
Sistemele de baze de date orientete pe obiect,pot fi considerate a cincea generatie de baze de date in curs de dezvoltare.A inceput la mijlocul anilor 80 dintr-o necesitate de a indeplini cererile
aplicatiilor de prelucrare a datelor, caracteristice sistemelor bazelor de date relationale ( a patra generatie de baze de date ).
Incercarile de a utiliza bazele de date relationale pentru aplicatiile avansate ,cum ar fi proiectarea asistata de calculator (CAD), fabricatia asistata de calculator (CAM), inginerie software ,sisteme bazate pe cunoastere, sisteme multimedia a expus neajunsuri ale sistemelor de baze de date relationale. Necesitatea de a efectua manipulari complexe in bazele de date existente si noua generatie de aplicatii de baze de date a facut ca bazele de date orientate obiect sa fie necesare.
De-a lungul anilor au fost invocate mai multe definiti a bazelor de date orientate pe obiect, dar noi vom defini bazele de date orientate obiect ca baze de date care integreaza capabilitatile orientarii pe obiecte cu bazele de date. Orientarea pe obiecte permite o reprezentare si modelare mai directa a problemelor lumii reale, iar functionalitatea bazelor de date este necesara pentru a asigura persistenta si “aratarea” concomitent a informatiilor in aplicatii.
Astazi exista peste 25 de produse baze de date orientate obiect pe piata, incluzand GemStone de la Servio Corporation, ONTOS, ObjectStone de la Object Design, Inc si multe altele.
In plus,fata de sistemele de gestionare a bazelor de date relationale de la Oracle, Microsoft, Borland, Informix, si alte sisteme relationale au inclus orientarea pe obiecte. Lipsa de maturitate a unor astfel de produse existente au dus dupa zeci de ani de dezvoltare la acceptarea bazelor de date orientate obiect pe piata la nivel mondial.
Nici cele mai actuale baze de date orientate obiect nu sunt inca pe deplin dezvoltate comparabil cu bazele de date relationale.
Sistemele de baze de date orientate obiect au evoluat de la nevoia de a satisface cererea pentru o reprezentare si modelare mai apropiata a entitatilor lumii reale, astfel incat s-a ajuns la un model de date mai bogat decat cel relational.Paradigma bazelor de date orientate obiect se bazeaza pe o serie de concepte de baza cum ar fi: conceptul de obiect, identitatea obiectului, clasa, mostenire, inlocuirea si legarea tarzie.
In modelul de date orientate pe obiect, orice entitate din lumea reala este reprezentata doar de conceptul de obiect.Un obiect are asociata o stare si un comportament.Starea unui obiect este definita de valoarea atributelor sale.Atributele pot avea valori primitive (cum ar fi siruri de caractere si numere intregi) si non-primitive,obiecte care la randul sau sunt formate dintr-un set de proprietati.
Prin urmare ,obiectele pot fi definite recursiv in termen de alte obiecte. Comportarea unui obiect este specificat de metodele care opereaza asupra starii obiectului.
Fiecare obiect este identificat de un identificator unic al obiectului numit OID,generat la incarcarea obiectului in baza de date.Obiectele care au aceeasi proprietati si comportament sunt grupate in clase.Un obiect poate fi instanta unei singure clase sau a mai multor clase. Clasele sunt organizate in clase ierarhice.O subclasa mosteneste proprietatile si metodele unei superclase, si in plus subclasa poate avea proprietati si metode specifice subclasei. In anumite sisteme,cum ar fi ORION se permite mostenirea multipla, o clasa poate avea mai multe subclase,sau cu alte cuvinte o clasa poate mosteni proprietatile si metodele de la mai multe clase. Unele sisteme permit doar mostenirea simpla.
Cele mai multe modele permite inlocuirea proprietatilor si a metodelor mostenite de la superclasa. Vorbim de inlocurea atunci cand intr-o clasa derivata (subclasa) este redefina o metoda din clasa de baza (superclasa).
Baze de date relationale
Piața actuală de baze de date este acoperită în majoritate de sisteme relaționale. Acestea, ca și modelele de prima generație, au fost concepute pentru aplicații clasice: contabilitate, gestiunea stocurilor etc.
Bazele de date relaționale sunt caracterizate de:
– structuri de date simple, intuitive;
– inexistența pointer-ilor vizibili pentru utilizatori;
– constrângeri de integritate;
– mulțime de operatori aplicați relațiilor care permit efectuarea operațiilor asupra datelor.
Bazele de date relaționale oferă avantaje precum:
– independența completă în descrierea logică a datelor (în termen de relații) și în descrierea fizică a datelor (în termen de fișiere);
– un ansamblu integrat de utilitare bazat pe un limbaj de generația a 4-a, și anume generatoare de meniuri, generatoare de aplicații, generatoare de forme, generatoare de etichete etc.; existența unor limbaje speciale de definire și manipulare a datelor.
Bazele de date relaționale nu folosesc însă obiecte complexe și dinamice, nu realizează gestiunea datelor distribuite și nici gestiunea cunoștințelor. Suportul obiectelor complexe și dinamice și manipularea lor este dificilă pentru sistemele relaționale, deoarece tipul datelor este limitat la câteva domenii alfanumerice, iar structura datelor este simplă. Sistemele relaționale nu modelează obiecte complexe ca grafuri, liste etc.
Sistemul bazelor de date orientate pe obiecte încearcă să depășească aceste limite ale sistemului relațional.
Un obiect complex poate să fie descompus în relații, deși apar dificultăți la descompunerea și la refacerea lui prin compunere (join). De asemenea, limbajele modelului relațional permit manipularea cu dificultate a obiectelor complexe.
O aplicație are un aspect static (reprezentat prin date) și un aspect dinamic (reprezentat prin tratamentul acestor date). Obiectele manipulate de sistemele relaționale sunt, în general, statice, iar comportamentul lor (dinamica lor) este dat separat prin programele aplicație. Un sistem relațional nu suportă obiecte dinamice care încorporează atât partea de date (informații) efective, cât și o parte relativă la tratamentul lor.
Este stiut faptul că în prezent există o multitudine de sisteme de baze de date relaționale, ele fiind chiar de ordinul sutelor. Unele dintre acestea sunt declarate de realizatori ca fiind relaționate însă, în realitate ele nu întrunesc criteriile de a putea fi considerate cu adevărat relaționale.
E.F. Codd, din dorința de a menține nealterat modelul relațional, a elaborat 13 reguli după
care ar putea fi apreciat orice SGBD dacă este cu adevărat sau nu relațional.
Vom recurge la o enumerare a acestora.
Regula O – Regula fundamentală
Un SGBD pentru a fi considerat relațional el trebuie să fie capabil să gestioneze în întregime
bazele de date prin capacitățile sale relaționale.Regula amintită accentează un aspect esențial și anume că un SGBD nu trebuie să recurgă la nici un fel de operații neraleționale pentru a realiza sarcinile ce îi revin cu privire la definirea, utilizarea și manipularea datelor.
Regula 1 – Regula de nonsubversiune
Dacă un sistem relațional are un limbaj de nivel scăzut, acel nivel scăzut nu poate fi utilizat
pentru a submina sau ocoli regulile de integritate și constrângerile exprimate în limbajul
relațional de nivel mai înalt.O astfel de regulă imprimă constrângeri în sensul că întregul acces la baza de date trebuie să fie controlat de către SGBD, astfel încât integritatea bazei de date să nu poată fi compromisă fără cunoștința utilizatorilor sau administratorului bazei de date.
Regula 2 – Reprezentarea informațiilor
La nivel logic, toate informațiile dintr-o bază de date relațională sunt reprezentate într-un
singur mod și anume prin valorile din tabele. O astfel de regulă impune ca toate informațiile, chiar și meta-datele, conținute în dicționarul de sistem să fie stocate ca relații și gestionate de către aceleași funcții operaționale care ar fi utilizate pentru întreținerea datelor.
Regula 3 – Reactualizarea vederilor
Toate vederile care sunt teoretic reactualizate pot fi reactualizate și de către sistem. Prin această regulă se stabilește că, dacă o vedere poate fi teoretic reactualizată, atunci sistemul de gestiune trebuie să fie capabil de a efectua reactualizarea respectivă.
De remarcat faptul că deși Codd precizează o astfel de regulă, practic nici un sistem nu acceptă
cu adevărat această caracteristică, deoarece nu au fost încă descoperite condițiile pentru identificarea tuturor vederilor care pot fi teoretic reactualizate.
Regula 4 – Tratarea sistematică a valorilor null
Valorile null, deosebite de șirul nul de caractere sau de un șir de caractere nule, ca și de zero sau orice alt număr, sunt acceptate pentru a reprezenta informațiile lipsă și cele care nu pot fi aplicate în mod sistematic, indiferent de tipul de date.
Regula 5 – Independența de integritate
Constrângerile de integritate specifice unei anumite baze de date relaționale trebuie să
poată fi definite în sublimbajul relațional de date și stocate în catalog, sau în programele
de aplicație.
Regula 6 – Accesul garantat
Se garantează că fiecare element de dată/ valoare atomică dintr-o bază de date relațională este accesibil din punct de vedere logic, prin apelarea la o combinație de nume de tabel, valoare a cheii primare și nume de coloană.
Regula 7 – Catalog dinamic on-line, bazat pe modelul relațional
Descrierea bazei de date este reprezentată la nivel logic în același mod ca și datele obișnuite,
astfel încât utilizatorii autorizați pot aplica la interogarea acesteia același limbaj relațional ca cel aplicat datelor curente.
Regula 8 – Sublimbaje de date cuprinzătoare
Un sistem relațional poate accepta mai multe limbaje și diverse moduri de utilizare a terminalelor. Totuși, trebuie să existe cel puțin un limbaj ale cărui instrucțiuni să poată exprima
următoarele chestiuni:
(1) definirea datelor,
(2) definirea vederilor,
(3) manipularea datelor,
(4) constrângerile de integritate,
(5) autorizarea,
(6) limitele tranzacțiilor (begin, commit și rollback).
Regula 9 – Operații de inserare, reactualizare și ștergere de nivel înalt
Capacitatea de tratare a unei relații de bază sau a unei relații derivate (adică o vedere) ca pe un singur operand se aplică nu numai regăsirii de date, ci și inserării, reactualizării și ștergerii acestora.
Regula 10 – Independența fizică de date
Programele de aplicație și activitățile de la terminal rămân logic intacte, ori de câte ori sunt făcute modificări, fie în reprezentările de stocare, fie în metodele de acces.
Regula 11 – Independența logică de date
Programele de aplicație și activitățile de la terminal rămân logic intacte, ori de câte ori sunt efectuate în tabelele de bază orice fel de modificări privind păstrarea informațiilor, care, teoretic, permit deteriorarea acestora.
Regula 12 – Independența de distribuție
Sublimbajul de manipulare a datelor dintr-un SGBD relațional trebuie să permită programelor de aplicație și înregistrărilor să rămână aceleași din punct de vedere logic, dacă și ori
de câte ori datele sunt centralizate sau distribuite fizic.
Elemente de algebra relationala
Principiile algebrei relationale au fost stabilite de E.F.Codd in 1970 pentru a formaliza matematic bazele de date.In conceptia relationala o baza de date este fromata dintr-un numar de tabele ( relatii, fisiere ) asupra carora se aplica o colectie de operatori utiizati pentru a manipula datele continute in tabele.[Jia98]
Operatorul se aplica asupra tabelelor si rezultatul este o noua rabela (relatie). Nu se permite accesul direct asupra inregistrarilor din tabela sau pozitionarea pe o anumita inregistrare din tabela.
Constituantii (camp, atribut, aracteristica ) sunt informatiile elementare ale unei relatii.Notam constituantii cu , , … .
Exemplu: CODP, Nume, Adresa, Salar, Data_nasterii.
Domeniul este ansamblul valorilor pe care il poate lua un constituant si se noteaza dom().Domeniul poate fi definit separat ca un tip abstract si mai multi constituanti pot avea acelasi domeniu: tel_acasa, tel_serv, fax.Domeniul este un set de valori atomice (indivizibile).
N-upletul de constituanti este un ansamblu de constituanti (, , ,…,) ce se poate nota cu X si se poate considera ca un constituant compus.
N-upletul (de date) este un element (,,, … , ), unde dom() pentru
i=1,2, … ,n.
N-upletul este un articol de fisier format din valori ale constituantilor.
Relatia n-ara R se defineste prin 3 elemente:
precizarea unui N-uplet de constituanti (, , ,…,);
definirea domeniului relatiei R pentru fiecare constituant ;
un predicat care pentru orice N-uplet (,,, … , ), unde dom() pentru
i=1,2, … ,n da o propozitie adevarata sau falsa.
Notam aceasta relatie cu R(,,, … ,) sau R(X).
Relatia R(X) este formata din ansamblul n-upletilor pentru care predicatul da propozitii adevarate.
Relatia STUD(CODS, Nume, Adresa, Data_n) va cuprinde toti n-upletii (inregistrarile) pentru care conditiile (predicatul) de student sunt indeplinite (admis, neexmatriculat, netransferat, nu a absolvit, etc).Nu orice combinatie de valori care apartine domeniilor constituantilor ne da un n-uplet valid.
Notam cu // R(,,, … , )// o evaluare a predicatului pentru un n-uplet.Daca n-upletul apartine relatiei atunci // R(,,, … , ),//=DA.
O relatie este o tabela de valori unde fiecare rand reprezinta un set al valorilor datelor din reatie.Valorile pot fi interpretate ca descriind o entitate sau o legatura data. Numele tabelei si coloanelor servesc la interpretarea sensului valorilor din fiecare rand al tabelei.
Gradul relatiei este dat de numarul atributelor din relatie.
Modelul (schema) relatiei R este notat R(,,, … ,) si este un set de atribute (constituanti) R={,,, … ,}. Un atribut este numele care indica un anumit domeniu D intr-un model de relatie R. Dom() indica domeniul atributului . Modelul de relatie STUD(CODS, Nume, Adresa, Data_n) este abstract si se refera la mai multe relatii concrete, care cuprind studentii unor universitati diferite.
O relatie concreta (instance) r a modelului de relatie R(,,, … ,), notata r(R) este un set de n-upleti r = {,,, … ,} unde fiecare n-uplet este o lista ordonata de n valori:
t = {,,, … ,} unde fiecare valoare dom() pentru i=1,2, … ,n sau =nul.
O relatie r poate fi definita ca un subset al produsului cartezian al domeniilor care definesc relatia: r(R) dom() X dom() X … X dom().
Daca fiecare domeniu este finit , avand un numar de valori, atunci numarul de valori posibile ale relatiei, este: |dom()| * |dom()| * … * |dom()| unde prin |dom()| s-a notat cardinalitatea domeniului .
O relatie data r, reflecta numai n-upletii valizi, care reprezinta o stare a lumii reale care se poate modifica in timp.Modelul relatiei R ramane stabil pana la modificarea atributelor sau predicatelor.
Caracteristici ale relatiilor
a) N-upletii in relatie sunt neordonati ca elementele unei multimi matamatice.Relatia se memoreaza ca un fisier unde unui n-uplet ii corespunde o inregistrare cu un numar de ordine rezultat in momentul inregistrarii.O relatie ca tabel poate fi afisata un orice ordine a randurilor.Relatia poate fi ordoanta logic dupa orice atribut.
b) Ordonarea valorilor in n-upleti este data de ordinea atributelor in modelul relatiei.Toti n-upletii unui fisier vor avea aceeasi ordine a valorilor.Ordinea valorilor se precizeaza intr-o tabela prin numele atributelor,data in informatiile de descriere.
c) Valorile atributelor in n-upleti sunt atomice.Un atriut din n-uplet nu poate avea valori multiple.Valorile nule sunt permise si pot fi valori necunoscute, inexistente (nu are telefon) sau nu se aplica n-upletului (nu poate avea telefon).
d) Relatia se poate interpreta ca o declaratie de tip specificata la definirea structurii.N-upletii relatiei sunt realizari ale entitatii sau legaturii.
Atribute cheie ale relatiei
O relatie este definita ca un set de n-upleti distincti.Nu pot exista doi n-upleti care au toate valorile atributelor identice.Uzual exista grupe de atribute pentru care valorile corespunzatoare difera, nu exista doua valori identice in n-upleti diferit.
Supercheie (SK) este un grup de atribute care identifica univoc n-upletii relatiei
(SK) ≠ (SK) pentru orice i,j unde i≠j. Pot exista relatii care au o singura supercheie formata din toate atributele.
Cheie (K) a relatiei R este o supercheie minima, care are proprietatea ca inlocuind oricare atribut A din K cu A obtinem un set de atribute K, care nu mai sunt superchei in R.Cheia este un invariant, daca se adauga noi n-upleti ea nu se modifica.
Cheie candidat este oricare din cheile relatiei daca sunt mai multe.
Cheie primara (PK) este o cheie candidat aleasa de administratorul bazei de date pentru identificarea inregistrarilor.Ea se subliniaza in relatie si se alege din cele care contin un singur atribut, sau un numar redus de atribute.Are lungime minima si esre bine sa aiba un sens functional.Definim ca atribut prim cel care face parte din cheia primara.
Cheie externa (FK- Foreign Key) este un atribut care este cheie primara PK in alta relatie si serveste la realizarea unor legaturi intre inregistrarile celor doua relatii.
Definitie: Un set de atribute FK din relatia este o cheie externa in daca satisface urmatoarele conditii:
atributele din FK au acelasi domeniu ca si atributele cheii primare PK a relatie .Cheia FK refera relatia .
O valoare a lui FK intr-un n-uplet din sa gaseasca o valoare a cheii PK pentru un anumit n-uplet din sau FK=nul
(PK) ≠ (PK) pentu i=1,2, … ,n.
O cheie externa poate referi chiar si propria relatie (cod sef, cod parinte).
La adaugarea inregistrarilor trbuie verificate valorile cheiilor externe in relatia referita pentru a asigura coerenta bazei de date (integritatea referintei).
Operatiile algebrei relationale
Algebra relationala cuprinde o colectie de operatori, care sunt aplicati pe relatii intregi obtinand o relatie rezultat.Se realizeara :
selectia n-upletilor din relatii individuale pe baza unor conditii;
combinarea n-upletilor din diferite relatii pentru a raspunde la intrebari in baza de date;
relatiile rezultat pot fi supuse la noi operatii
Exista doua clase de operatii in algebra relationala:
operatii din teoria multimilor: UNION, INTERSECT, DIFERENCE, PRODUS, CARTEZIAN;
operatii speciale algebrei relationale: SELECT, PROJECT SI JOIN.
Selectia notata σ
Trecerea la dezvoltarea obiectelor
Istoric
Managementul sistemelor de baze de date orientate obiect s-a dezvoltat la inceputul pana la mijlocul anilor 1970.Termenul de „baze de date orientate pe obiect” a aparut in jurul anilor 1985
Cea mai importanta tendinta in dezvoltarea sofware-ului in ultimul deceniu a fost trecerea la dezvoltarea obiectelor, metodelor darotita aparitiei limbajului Java.Dezvoltatorii au descoperit ca dezvoltarea bazata pe obiecte ofera avantaje imense in dezvoltarea aplicatiilor care modeleaza problemele lumii reale.Concepte ca mostenire, incapsulare, mostenire multipla, polimorfism furnizeaza un mod rapid si natural pentru dezvoltatori de a reprezenta direct date complexe si relatiile dintre ele.
Dezvoltarea a fost accelerata, fara a da semne de incetinire in viitor.Recent un raport a IDC-ului a indicat ca exista peste peste 2.6 milioane de dezvoltatori din lumea intreaga, utilizand C/C++ si peste un milion de dezvoltatori profesionisti la nivel mondial utilizand Java.Acest lucru inseamna ca peste 37% din dezvoltatori folosesc aceste limbaje si numarul lor este in constinua crestere.
In scopul de a valorifica trecerea la orientarea pe obiect, s-a incercat sa se creeze sisteme de gestiune a bazelor de date care sa poata oferi un suport pentru aplicatiile bazate pe obiecte,dar in mare masura nu s-a reusit sa se ajunga la nivelul asteptarilor dezvoltatorilor si organizatiilor IT. Aceste baze de date se incadreaza in doua categorii: baze de date orientate pe obiect (ODBMS) si baze de date relationale (RDBMS) .
Bazele de date orientate pe obiecte au fost pe aproape,dar…
Avantajele programarii orientate pe obiect, mai multi furnizori de baze de date au introdus prima generatie de baze de date orientate pe obiect incepand cu mijlocul anilor '90.De la începutul aparitiei bazelor de date orientate pe obiecte au avut numeroase deficiențe care a scazut dramatic sansa de a fi considerat vrednic de a fi dezvoltat.
Ironic,una din deficientele primei generatii de baze de date orientate pe obiect nu a fost vazuta initial ca o deficienta.Aceasta prima generatie, avand necesitatea unei OR (object-relational) a extins limbajul de programare orientat pe obiect.Acest lucru a permis dezvoltatorilor sa creeze si sa stocheze obiecte in baza de date in mod simplu, prin declararea acestora in codul aplicatiilor , fara a fi nevoie de a utiliza o baza de date separata, o interfata separata sau limbaj.Acesta este motivul pentru care bazele de date orientate pe obiect refera un obiect stocat persistent.
Cei mai multi dintre furnizorii ODBMS au folosit aceasta persistenta deoarece obiectele puteau fi mapate direct in baza de date ,dar persistenta in cele din urma a devenit un pret scump.
Principalele motive pentru care ODBMS a esuat, au devenit fundatia pentru dezvoltatorii de aplicatii.In timp ce prototipul a aparut rapid si functiona bine , sistemele de productie au suferit .
O alta deficienta a primelor ODBMS-uri a fost lipsa suportului SQL .Bazele de date orientate obiect fara SQL au esuat in cele mai multe companii.Acest lucru a fortat companiile de a absorbi timpul aditional si costul de formare a dezvoltatorilor .Aceste ODBMS-uri care au implementate SQL pe partea de client a avut probleme pe partea de retea care a limitat utilitatile si a creat probleme in termeni de performanta.
Pe partea de client, implementarea Sql, toate clasele si subsecventele contin referite ale SELECT-urilor care trebuiesc transmise de pe server, prin retea la client.Acestea au creat mari volume de trafic de retea pentru fiecare interogare, mai mult, avand impact asupra performantei si portiuni a bazelor de date care trebuiau a fi blocate in vederea interzicerii incercarii de a executa scrieri pe acele portiuni.Procesarea interogarii de catre server si filtrarea rezultatelor inainte de a fi trimise catre client, face ca informatia neutila sa nu fie transmisa astfel ca impactul negativ asupra performantei este minimizat.
Primele sisteme de baze de date orientate pe obiect nu au reusit sa ofere o platforma de baze de date optima pentru dezvoltarea obiectuala.Performanta slaba, lipsa suportului SQL, banda de latime innadecvata, precum si consistenta obiectelor a dus la abandonarea acestui tip de baze de date de catre dezvoltatori. Incercand o alta cale, furnizorii RDBMS au reabilitat produsele obiect-relationale a bazelor de date si au adaugat capabilitati cum ar fi mapare OR in ideea de a sprijini folosirea obiectelor.Aceasta noua incercare de asemenea a esuat.
Bazele relationale nu au fost tocmai gata
În scopul de a reprezenta un obiect design într-o bază de date relationale, toateclasses must be mapped to relational tables, a process known as clase trebuie să fie mapate in tabele relationale, un proces fiind cunoscut sub numele de mapareobject-relational mapping. obiect-relational. With OR mapping, each object must be Cu mapare OR, fiecare obiect trebuie să fie represented by two-dimensional tables; there is no way to directlyreprezentat de un tablou bidimensional, nu există nici o alta cale de a reprezenta sau stoca direct tionships between multiple objects.obiecte , si nici relatiile dintre multiple obiecte cum e de exemplu mostenirea.
Maparea OR de asemenea a creat o problemă de performanță because related data had to be split (deconstructed) into multiplepentru că datele au trebuit să fie împărțite în mai multe tabelerelational tables. relationale. Each time objects were stored, they had to beDe fiecare dată când obiectele sunt stocate, acestea trebuit să fie impartite in mai multe tabele, si reconstituite atunci cand trebuie citite. Rconstrucția obiectului implica combinarea datelor from multiple tables using complex-relational joins andde la mai multe tabele, folosind join-uri relationale complexe.mately slowed systems to a crawl.
În timp ce pare să ofere o soluție pentru problema dintre obiect si relational, maparea OR s-a dovedit să fie în mod notoriu complex și consumatoare de timp. In an attempt to Într-o încercare de a evita acest lucru, bazele de date relational-obiectuale introduce instrumente de mapare relationale-obiectuale,a layer of software that translates between application objects representand un strat software care realizeaza conversia între aplicatiile obiectuale si tabelele and relational database tables.bazelor de date relationale. However, the same process of Cu toate acestea, în același proces de converting between objects and tables still occurred within theconversie între tabele și obiecte a apărut probleme de performanta.
Ca și în cazul sistemelor aparute la începutul ODBMS, măsurile de prevenire au aparut datorita comerciantilor de sisteme de baze de date relationale care au adaugat la costul total al implementarii si costul mentineri aplicatiei, dar au esuat din nou.
Individual, RDBMS și ODBMS nu au putut răspunde nevoilor object developers.dezvoltatorilor. Some hybrid of the two was necessary to pro- Unul dintre cele doua insa, trebuia să ofere cu exactitate facilitatile necesare dezvoltatorilor de obiecte si IT .
Cel mai bun din cele doua
vide developers and IT with the exact capabilities required to facil-
Soluția a fost o baza de date SQL-obiectuala, care combina cu ușurință of object development and the ubiquity of SQL – the ultimate dezvoltarea obiectuala . Proiectata ground up to handle objects and to enable the rapid developmentsă se ocupe de obiecte și pentru a permite dezvoltarea rapidă deof complex object applications that model and solve real worldaplicatii
bazate pe obiecte complexe care modeleaza și rezolva problemele din lumea realaproblems..
Pozitionat unic pentru a oferi baza optima pentru dezvoltarea si implementarea obiectelor, o baza de date SQL-obiectuala ar sucede acolo unde generatiile anterioare a bazelor de date ar esua.
Dezvoltatori vor putea creea aplicatii si servicii mai rapide, mai ieftine si mai eficiente in timp ce permite IT-ului sa implementeze si sa administreze aceste aplicatii.Astfel de baze de date nu au existat pana la aparitia lui Matisse.
Baza de date SQL-obiectuala Matisse furnizează suport pentru maparea de la obyecto laobject mapping, ANSI SQL, standards, UML, while offering high obiect, ANSI SQL, standarde, UML, în timp ce oferă mari performance and zero administration.performanțe și administrare zero. Matisse is the only data- Matisse este singara base that has been able to bridge the gap between object devel-bază de date, care a fost în măsură să reduca decalajului dintre dezvoltatorii de obiecte si managementopers and object management.. Matisse has taken the best capa- Matisse a luat cele mai bune capabilities of object and relational databases and created The Objectbilitati ale obiectelor și a bazelor de date relationale si a creat baza de date dezvoltatoare de obiecte.
Maparea relational-obiectuala
Maparea relațional-obiectuală sau obiectual-relațională ( O/RM ) este o tehnică de
programare care leagă bazele de date de limbajele de programare orientate-obiect, creând o bază
virtuală de obiecte. Există pachete comerciale și gratuite disponibile pe piață care efectuează
maparea între obiect și relațional, deși unii programatori preferă să-și realizeze și utilizeze propriul cod pentru mapare.În programarea orientată-obiect, obiectele reprezintă entități din lumea reală. Problema intervine la realizarea de obiecte persistente,atunci când este necesară translatarea acelor obiecte sub forme care să poată fi stocate în fișiere sau în baze de date, și, ulterior, obținerea obiectelor inițiale din fișiere sau baze de date, cu toate proprietățile și relațiile existente. Din punct de vedere istoric, au existat câteva soluții pentru rezolvarea problemei, dintre care cele mai importante sunt : programele de mapare relațional-obiectual, sistemele de baze de date obiectuale. Bazele de date relaționale tradiționale un permit stocarea obiectelor. Folosirea acestora este totuși posibilă, dar duce la un efort dublu de programare : programatorii trebuie să asegure funcționarea programelor de aplicații cu baze de date la două nivele diferite : procesarea datelor s-ar face într-o manieră orientatăobiect, pe de o parte, iar aceleași trebuie stocate într-o bază de date după modelul relațional,pe de altă parte. Necesitatea acestei conversii constante a acelorași date între cele două forme nu numai că are efecte asupra performanțelor programelor, dar aduce și greutăți d.p.d.v. al programării programatorilor, întrucât modelul obiectual și cel relațional implică limitări unul asupra celuilalt. De exemplu, bazele de date relaționale transpun relațiile complexe între entități într-o manieră destul de complicată și dificilă și pot fi cu greu mapate în modelul obiectual, neputând să implementeze tipuri definite de utilizator.
În bazele de date relaționale un obiect din lumea reală este deseori stocat pe părți în mai multe tabele, iar obținerea obiectului respectiv în vederea procesării de către programele de aplicații
necesită reunirea acestor date din toate tabelele. În modelul obiectual relațiile între componentele unui obiect sunt mult mai clare și mai ușor de reprezentat, se poate lua exemplul unei persoane dintr-o agendă telefonică care are un număr de telefon ce poate fi stocat în cadrul obiectului persoană. Acest lucru nu este valabil pentru modelul relațional în care numărul de telefon al persoanei este stocat într-un tabel separat, tabelele un au nici o idee de modul în care sunt relaționate cu alte tabele la un nivel fundamental. Utilizatorul trebuie, în schimb, să emită o
interogare cu join și să specifice modul de relaționare al tabelelor pentru a colecta informațiile, pentru că tabelele ca atare în baza de date nu pot să se relaționeze între ele. De fapt, la nivelul bazei de date se cunosc într-o anumită măsură relațiile dintre tabele prin intermediul restricțiilor, dar o interogare SQL este independentă de acestea.
Modelul relațional poate fi translatat într-un model obiectual dacă se au în vedere următoarele aspecte :
o entitate din modelul relațional poate fi replicată sub forma unei entități din modelul obiectual, ambele fiind descrise prin intermediul unor atribute ;
o instanță a unei entități este reprezentată în modellu relațional printr-o înregistrare într-o tabelă, iar în modelul obiectual printrun obiect ;
relațiile între entități sunt reprezentate în același mod în ambele modele, doar că sunt implementate în mod diferit ;
Unele sisteme de mapare O/R mențin obiectul încărcat în memorie în legătură constantă cu baza de date. Acest lucru este posibil astfel: datele obținute prin interogare din baza de date sunt copiate în câmpurile unui obiect de tipul corespunzător ; odată obținut obiectul, la fiecare modificare a atributelor sale, acesta trebuie să realizeze procesul invers de scriere a modificărilor înapoi în baza de date. Având în vedere cele două lumi foarte diferite, codul (orientat-obiect) necesar pentru a lucra cu bazele de date relaționale tinde să devină foarte complex și predispus la erori.
Dezvoltatorii de soft pentru aplicații cu baze de date au căutat soluții mai bune pentru a
obține persistența obiectelor lor.Au fost dezvoltate o serie de pachete comerciale care realizează maparea între relațional și obiectual în locul programatorului. Aceste sisteme oferă biblioteci de clase care efectuează automat maparea. Având o listă de tabele dintr-o bază de date și o listă de clase de obiecte într-un pogram, sistemele mapează automat cererile dintre acestea. De exemplu,
obținerea numerelor de telefon ale unei persoane se înseamnă crearea și trimiterea interogării
corespunzătoare serverului de baze de date, recepționarea rezultatelor și transpunerea lor automată în obiecte de tipul numărului de telefon în cadrul programului de aplicații.
Din punctul de vedere al programatorului, obiectele par persistente. Programatorul poate
crea obiecte și poate lucra cu ele ca și când ar fi obiecte obișnuite iar în final, acestea vor ajunge automat în baza de date, fără alte bătăi de cap. În realitate, lucrurile nu stau tot timpul așa.
Toate sistemele O/RM se fac vizibile într-o oarecare măsură, reușind mai mult sau mai puțin să ignore existența bazei de date. În unele cazuri, operația automată de conversie se dovedește a fi lentă, mare consumatoare de memorie și ineficientă, fiind mai convenabilă scrierea de cod propriu pentru rezolvarea problemei.
Numeroase sisteme de mapare relațional-obiectuale au fost create de-a lungul timpului
și acestea s-au impus mai mult sau mai puțin pe piață. Unul dintre cele mai bune astfel de sisteme a fost considerat Enterprise Objects Framework al companiei NeXT. Succesul lui nu a durat însă prea mult, asta în principal din cauză că era integrat și strâns legat de întregul pachet OpenStep. Un alt sistem de acets gen, mult mai performant este Caché. Acesta este de fapt un sistem de gestiune a bazelor de date post-relaționale care incluye utilitățile uzuale ale unui sistem de mapare O/R în software-ul pentru baza de date, pentru a maximiza performanța. Nu în ultimul rând, merită amintit tot în acestă categorie un sistem mai recent, Java Data Objects (JDO) , care a devenit un standard și este disponibil în mai multe versiuni.
Soluția ideală pentru nepotrivirea dintre cele două abordări – relațională și obiectuală – a
datelor este un sistem de management al bazelor de date orientat-obiect (OODBMS), care, după cum arată numele, este un sistem proiectat special pentru lucrul cu date și programme din perspectiva obiectuală. Folosirea unui OODBMS elimină necesitatea de a converti datele în și din forma relațională, întrucât acestea sunt stocate în baza de date direct sub formă de obiecte. Această tehnică este într-adevăr convenabilă și de mare ajutor în multe situații. Una din limitările ei este că,
trecerea de la un sistem relațional la unul pur obiectual implică pierderea capacității de a folosi interogări SQL. Din această cauză, unii programatori rămân la sistemele relaționale de baze de date și la un sistem de mapare.
Totuși, multe OODBMS sunt capabile să proceseze interogări SQL cu un grad de
complexitate limitat.relational vendors were unwieldy, added to the overall cost of
Baze de date orientate pe obiecte. Definitii. Principii
Așa după cum Codd E.F. a definit o serie de reguli pentru ca un SGBD să fie cu
adevărat relațional, tot la fel un grup de lucru să fie de mare influență a publicat, sub denumirea
de ,,Manifestul sistemelor de baze de date orientate pe obiecte”, o serie de cerințe sau principii pe care trebuie să le îndeplinească un SGBD pentru a putea fi considerat obiectul [3]. În concordanță cu Manifestul sistemelor de baze de date orientate pe obiecte, sunt definite 13 principii ale AGBDOO, dintre care unele sunt obligatorii iar altele opționale.
1. Posibilitatea definirii structurilor complexe
O astfel de cerință presupune capacitatea de a defini structuri complexe plecând de la tipuri
de date atomice folosind o serie de tipuri de constructori, iar aceștia să fie ortogonali, în sensul că fiecare constructor trebuie să se aplice oricărui obiect. Exemplu, dacă folosim constructori de forma SET (TUPLE ( )), LIST (TUPLE ( )) atunci trebuie să avem posibilitatea de a folosi și formele TUPLE (SET( )) și TUPLE (LIST ( )).
Dintre cei mai folosiți constructori amintim:
– ROW (, . . ., ), unde un tip reprezintă un rând sau tupleu de n câmpuri au câmpurile , . . .,de tipurile , . . .,;
– ARRAY: Tipurile array suportă o metodă ,,array index” pentru a permite utilizatorilor să acceseze articolele array (colecției);
– seturi și multiseturi (Sts and multisets).Obiectele set pot fi comparate utilizând setul
de metode tradițional <, ≤, =, ≥, >.Totodată, două obiecte set (având elementele de același tip) pot fi combinate pentru a forma un nou obiect folosind operatorii I ,U , și
– (diferență).
– Liste: Operațiile de liste tradiționale include capul de listă (head) care returnează primul
element, coada listei (tail) care returnează adresa ultimului element din listă, inserare sau adăugare de noi elemente în listă și respectiv excluderea unui element din listă. Mai există o serie de operatori, cum ar fi operatorii agregați (COUNT, SUM, AVG, MAX, MIN) și operatori pentru conversia de tipuri (exemplu, pentru conversia unui obiect multiset într-un obiect set prin eliminarea
duplicatelor).
2. Identitatea obiectului, adică SGBD trebuie să ofere posibilitatea identificării, fără ambiguitate, a oricărui obiect din baza de date. În acest sens cu ocazia încărcării oricărui obiect în baza de date se va recurge la generarea unui identificator unic al obiectului, numit OID.
3. Încapsularea, presupune faptul că SGBD trebuie să dispună de capacitatea de a încapsula
datele și metodele aparținând obiectelor iar utilizatorii pot avea acces la ele doar printr-o interfață ce citează o anumită metodă. La rândul său atât metodele cât și datele pot fi definite publice (+), protejate (≠) sau private (-).
4. Tipuri și/sau clase. Cele două concepte trebuie să fie ambele prezente. Primul concept reprezintă un mecanism de verificare pentru acuratețea programelor în timpul compilării. Al doilea concept reprezintă un mecanism care colectează extensiile de obiecte și le definește implementarea lor. Invers, nu e necesar să fie două forme diferite de a exprima tipuri și clase și astfel e posibil să
exprimăm un concept în contextul celuilalt.
5. Clase și/sau tipuri de ierarhii, în contextul moștenirii, evidențiază faptul că un SGBD
trebuie să asigure ca un subtip sau subclasă să poată moșteni atributele și metodele de la superclasele sau supertipurile lor.
6. SGBD trebuie să ofere suport pentru legarea dinamică, în sensul că metodele trebuie
să se aplice la obiecte de diferite tipuri iar implementarea unei metode va depinde de tipul de obiect căruia i se aplică. Acest aspect presupune faptul că sistemul nu poate lega denumirea metodelor până în momentul execuției (legea dinamică).
7. SGBD trebuie să ofere un limbaj de manipulare a datelor LMD cu completitudine
de calcul. În acest sens, de exemplu, se apreciază că standardul SQL3 posedă completitudine
de calcul.
8. Extensibilitatea mulțimii tipurilor de date, ceea ce presupune capacitatea de a defini
noi tipuri bazate pe cerințele utilizatorilor.
9. Durabilitatea sau persistența datelor, ceea ce presupune capacitatea sistemului de a
asigura / suporta persistența datelor. La fel precum în situația SGBD convenționale, datele trebuie să rămână după finalizarea aplicației care le-a creat. Deci, utilizatorul nu trebuie să deplaseze sau să copieze explicit datele, pentru a le putea refolosi.
10. SGBD trebuie să fie capabil și să ofere facilități în ceea ce privește operarea și gestionarea unor volume mari de date (baze de date de mari dimensiuni).
11. Asigurarea accesului concurent la aceleași resurse.
12. Asigurarea capacității de refacere în cazul unor căderi fizice de hardware sau software,
asemănător sistemelor convenționale.
13. Asigurarea unor limbaje de acces de cereri de nivel înalt cu multiple facilități de
interogare a bazei de date. Manifestul bazelor de date orientate direct mai face referiri la câteva caracteristici opționale, care sunt interesante și folositoare dar nu esențiale pentru un SGBDOO, dintre acestea enumerăm: moștenirea multiplă, distribuția datelor într-o rețea, posibilitatea verificării unui program în timpul compilării, managementul tranzacțiilor și mecanisme pentru managementul versiunilor.
Realizarile bazelor de date orientate pe obiect
Bazele de date orientate obiect permite reprezentarea obiectelor complexe intr-un mod mai simplu.Realizarile bazelor de date orientate pe obiect pana acum sunt: permite utilizatorilor sa defineasca abstractiuni, facilitatea de a dezvolta relatii, elimina nevoia de a defini chei, s-a dezvoltat un nou set de predicate, elimina necesitatea in unele cazuri a join-urilor, sunt mai performate decat bazele de date relationale in unele cazuri, si au suport pentru tranzactiile de lunga durata. In plus, in cele din urma a fost dezvoltata si algebra obiect.
1. permite utilizatorilor sa defineasca abstractiuni
Au abilitatea de a defini noi abstractiuni si de a controla implementarea lor. Pachetele
bazelor de date orientate obiect permite utilizatorului de a crea noi clase cu atribute si metode noi, pot mosteni atributele si metodele de la superclase, permite sa se creeze instante a claselor definite fiecare avand un identificator de obiect unic, si sa incarce si sa ruleze fiecare metoda.
Modelul orientat pe obiect de asemenea permite definirea de obiecte ca agregate de alte obiecte, agregatele la randul lor pot fi imbricate pe mai multe niveluri.Proprietatile pot avea structuri complexe fiind definite folosind constructorii, mai mult pot avea ca valori obiecte nonprimitive.
Proprietatile cu mai multe valori sunt folosite pentru a exprima structurile de date complexe.
In modelul relational acest lucru este obtinut prin utilizarea relatiilor suplimentare si prin join-uri.
Un exemplu de astfel de pachet care sa includa toate caracteristicile de mai sus ar fi Encore.
Acesta se bazeaza pe datele abstracte, permite definirea subtipurilor (mostenirea), incapsularea, structurile complexe, identitatea obiectelor si legarea dinamica pentru metode (asa numita legare tarzie ).In Encore, o proprietate p refera un obiect x a unui set de obiecte S fara a face nici o declaratie modul in care aceasta relatie este compusa.
2. permite dezvoltarea unor relatii
Un exemplu de pachet care ofera suport in acest sens este ObjectStore. Bazele de date orientate obiect permite exprimarea unei referinte mutuale intre doua obiecte.
3. elimina nevoia de a defini key
Modelul bazelor de date orientate obiect are un OID ( identificator de obiect) care este generat automat de catre sistem si garanteaza unicitatea pentru fiecare obiect.Acest lucru pe langa faptul ca elimina necesitatea de a mai defini chei a mai adus si alte avantaje:
OID-ul nu poate fi modificat in aplicatie
doua obiecte sunt diferite in cazul in care au OID diferite, chiar daca au aceleasi structuri si aceleasi valori pentru toate proprietatile lui.
4. dezvoltarea de predicate egale
In bazele de date relationale egalitatea se bazeaza doar pe valori.In bazele de date orientate
obiect dezvolta si defineste diferite tipuri de egalitati:
egalitatea identitatilor a obiectelor : doua obiecte sunt egale daca au acelasi OID
egalitatea valorilor unor obiecte : poate fi determinata in doua moduri (a) doua obiecte primitive sunt egale daca au aceeasi valoare, (b) doua obiecte nonprimitive sunt egale daca au acelasi numar de proprietati si daca pentru orice proprietate a lui exista o proprietate a lui care este egala ca valoare.
egalitatea valorilor proprietatilor
egalitatea identitatii a proprietatilor
5. reduce nevoia Join-urilor
Capacitatea de navigare prin intermediul structurilor de obiecte si rezultatul expresiilor
atributelor obiectelor ofera perspectiva de a inlatura folosirea join-urilor. Join-ul relational este un mecanism care coreleaza doua relatii pe baza valorilor sau atributelor. In bazele de date orientate pe obiect ,doua clase pot avea perechi corespunzatoare de atribute in care join-ul relational (explicit sau implicit) sa fie necesar.
De exemplu ,sa presupunem ca avem o clasa Studenti si o clasa Scoala si ambele au atribute nume si varsta. Desi atributele nume si varsta ale clasei Scoala pot sa un aibe acelasi domeniu ca nume si varsta din clasa Student sau invers,am dori sa se refere la cele doua clase pe baza valorilor acestor atribute (exemplu: sa gasim toate obiectele student a caror varsta este mai mica decat varsta la care un student merge la scoala).
Dar asa cum am mentionat mai devreme se poate reduce nevoia join-urilor in mod semnificativ in comparatie cu bazele de date relationale.De exemplu cand domeniul unui atribut a unei clase A este de clasa B, preluarea OID-ului a obiectelor intr-o clasa in care sunt stocate valori a unui atribut intr-o alta clasa elimina necesitatea implicita a unui join intre cele doua obiecte.
In bazele de date orientate obiect exista o distinctie intre join-urile implicite, provenite din ierarhia de obiecte imbricate ( nested ) si join-urile explicite care sunt similare cu cele ale relationalului cand doua obiecte sunt comparate in mod explicit utilizand compararea intre valori sau identitate.
In plus, toate join-urile explicite (utilizand egalitatea de valoare sau egalitatea de identitate) un pot fi definite limbajul relational ca interogare pentru ca orice predicat in RBD poate implica numai atribute atomice.
6. Performanta castigata
Desi baze de date orientate obiect curente nu sunt cele mai dezvoltate sisteme de baze de
date in comparatie cu bazele de date relationale curente, au cateva surse de performante care castiga in fata bazelor de date relationale :
in OODB valoarea unui atribut a unui obiect X, a carui domeniu este un alt obiect Y, OID este identificatorul de obiect a obiectului Y. De aceea ,daca o cerere a preluat deja obiectul X si acum ar dori sa preia obiectul Y ,sistemul bazei de date poate prelua obiectul Y cautand dupa OID-ul sau. In cazul in care OID este o adresa fizica a unui obiect, obiectul poate fi preluat direct. In cazul in care OID refera o adresa logica obiectul poate fi preluat cautand in tabela de intrare.Acest lucru un ar fi posibil atat de usor la bazele de date relationale deoarece nu contin OID.
o a doua sursa de castig este ca majoritatea bazelor de date orientate obiect convertesc OID-ul , stocat intr-un obiect in pointeri atunci cand obiectul este incarcat in memorie.Deoarece RDB un pastreaza OID-urile , nu ii pot converti ca pointeri. Sistemele RBD prezinta astfel dezavantajul ca rezultatele nu le putem avea intr-un tampon din memorie. Prin urmare , pentru aplicatii care necesita cautari repetate a unor obiecte din memorie, bazele de date orientate obiect pot castiga in mod evident in fata celor relationale.
chiar daca OODB nu sunt indexate, poate fi convenabil sa execute interogari arbitrare prin exploatarea referintelor dintre obiecte.Atunci cand interogarile sunt formulate in directia in care nu exista suport pentru referinte, interogarea va fi procesata in mod secvential.
7. ofera sprijin pentru transactiile de lunga durata
Versiunea pentru aceste tranzactii de lunga durata lipseste din modelul relational. Modelul
orientat pe obiecte ofera suport pentru acest timp de tranzactii,dar facilitatile si aici sunt limitate.
8. dezvoltarea algebrei obiect
Desi nu este atat de dezvoltata ca algebra relationala, algebra obiectuala defineste cinci
fundamente : uniune, diferenta, select, generate si map.Alti operatori ca intersectie pot fi definit plecand de la acesti cinci operatori descrisi mai sus.
Operatorul uniune returneaza obiecte care sunt in ambele seturi P si Q.Diferenta returneaza un set de obiecte care se afla in setul P, dar un si in setul Q. Select returneaza un subset al setului dat ca intrare. Generate va genera obiecte , iar map returneaza un set de obiecte care rezulta din fiecare secventa a aplicatiei.
Puncte slabe ale bazelor de date orientate pe obiect
In ciuda realizarilor bazelor de date orientate obiect discutate anterior , bazele de date orientate pe obiecte nu au fost capabile de a produce un impact major din cauza punctelor slabe inca prezente in modelul si tehnologia bazelor de date orientate obiect.
Punctele slabe sunt : lipsa de interoperabilitate intre bazele de date relationale si cele orientate pe obiect, optimizarea interogarilor minima, lipsa algebrei standard a interogariilor, lipsa facilitatilor interogarilor, nu ofera suport pentru vederi si pentru securitate, nu ofera sprijin pentru definiti de clase dinamice, ofera suport limitat pentru constrangeri, ofera sprijin putin pentru obiecte complexe, limita de integrare cu sistemele existente de programare orientat pe obiect si printre altele si castigurile de performanta sunt limitate.
1. interoperabilitatea intre RDB si OODB
Bazele de date orientate pe obiect pentru a avea un impact major asupra pietei bazelor de date,
au decis sa dezvolte urmatoarele:
trebuia sa dezvoltat pe deplin sistemul bazelor de date astfel incat sa fie suficient de compatibil cu sistemul de baze de date relational (trebuia efectuata o cale de migrare de la produsele curente la produsele noi)
instrumentele de dezvoltare a aplicatiilor si de acces la baza de date trebuiau sa fie dezvoltate pentru astfel de sisteme
arhitecturile bazelor de date relationale trebuie unificate cu cele orientate pe obiecte
de asemenea modele datelor reloationale cu cele orientate pe obiec trebuiesc unificate
2. Optimizarea interogarilor
Una dintre cele mai mari probleme in bazele de date orientate obiect o constituie optimizarea interogarilor declarative.Complexitatea modelului orientat pe obiecte complica optimizarea interogarilor. Aceasta complexitate suplimentarea a bazelor de date orientate obiect se datoreaza:
tipurilor de date suplimentare – utilizatorul defineste noi tipuri de date si clase, iar prin
mostenire acestea pot optimiza interogarile.Un astfel de exemplu ar putea fi o interigare care implica operatia de intersectie intre obiecte de tip Employees si Supervisors.Daca Employee superclasa a clasei Supervisor, optimizatorul poate presupune ca Supervisor este un subset a lui Employee si astfel poate simplifica join-ul care ar trebui realizat.
In cazul in care tipurile de date suplimentare poate implica operatia de uniune a unor obiecte Students si Employees cu obiecte Person, optimizarea se face definind ambele clase ca fiind subclase a clasei Person.
schimbarea varietatii tipurilor – interogarile se pot baza pe operatii asupra colectiilor, dar o optimizare referitoare la seturi ( sau liste) trebuie sa fie combinate cu optimizari asupra tipurilor de obiecte continute in set. Un optimizator a interogarilor orientat pe obiecte trebuie sa fie capabil sa aplice optimizari specifice fiecarui tip si optimizari care tine cont de relatiile dintre obiectele de tipuri diferite.
complexitatea obiectelor, metodele si incapsularea fac interogarile mai complexe.Obiectele complexe creeaza cai a caror expresii complica procesul de interogare,care poate fi si mai dificil in cazul in care metodele au efecte secundare. Un exemplu care poate creea probleme : calea Order.path.name poate fi evaluata in mod corect de la dreapta la stanga daca sunt multe comenzi, si invers daca sunt putine comenzi.De asemenea o cale poate fi parcursa mai eficient cu ajutorul unui Join.
interogarile bazelor de date orientate pe obiect sprijina utilizarea structurilor imbricate, ceea ce poate complica din nou optimizarea procesului de interogare, putand ajunge de la o problema locala la o problema globala.
identitatea obiectului – cand obiectele au identitati se pune problema cand doua obiecte sunt egale.Optimizatorul orientat pe obiecte trebuie sa ofere posibilitatea de a crea noi obiecte si de a defini echivalenta.
Datorita celor discutate mai sus ,optimizarea interogarilor in cazul bazelor de date orientate
pe obiecte este extrem de greu de realizat si inca se afla in stadiu de cercetare.In ziua de astazi OODB se afla in stagiu de optimizare destul de simpla.Optimizarea Join-urilor este un alt aspect la care este nevoie de atentie mare.
Lipsa interogarilor algebrice standard.
Lipsa interogarilor algebrice standard este o alta slabiciune a bazelor de date orientate pe
obiect.
Lipsa facilitatilor interogarilor
In acele putine sisteme cateva ofera facilitati semnificative interogarilor, limbajul interogarii nu este compatibil cu ANSI SQL. Facilitatile interogarilor nu include subinterogari imbricate, interogari set (uniune, intersectie, diferenta ), functii de agregare si GROUP BY, si nici JOIN-uri a claselor, facilitati sustinute pe deplin in cazul bazelor de date relationale.
De asemenea, nu exista nici un obiect interogare standard, cu toate ca a existat efortul cu cativa ani in urma de a aduce un obiect SQL.
Nu ofera suport pentru vederi
Bazele de date orientate obiect nu au suport pentru vederi.Desi au existat mai multe propuneri , nu s-a ajuns la o intelegere asupra mecanismului cu care o vedere opereaza in bazele de date orientate pe obiecte.Dezvoltarea acesteia este complicata, ridicand intrebari de genul : “care sunt identitatile obiectelor intr-o vedere?” .Pe de alta parte conceptele de incapsulare si mostenire pe care bazele de date orientate pe obiecte le ofera , face ca definirea vederilor sa fie inutila.
Securitatea
Bazele de date relationale permite utilizatorilor sa acorde sau sa restrictioneze posibilitatea de citire sau modificare a definitiilor relatiilor sau a vederilor.Daca bazele de date orientate pe obiecte se va intampla sa extinda in mai multe domenii, aceasta facilitate ar putea fi realizata.
Nu ofera suport pentru clase dinamice
În plus față de faptul că nici un model standard de date nu a fost încă realizat pentru bazele
de date orientate pe obiecte, cele mai multe nu permit modificări dinamice la schema bazei de date, cum ar fi adaugarea unui atribut sau a unei metode la o clasa, adaugarea unei noi superclase, stergerea unei superclase, adaugarea sau stergerea unei clase de obiecte.Bazele de date relationale permite utilizatorilor modificarea schemei bazei de date folosind comanda ALTER, ofera posibilitatea adaugarii si stergerii unei coloane.
Suport limitat a constrangerilor
Nu exista mecanisme pentru a declara o proprietate a unui atribut ca fiind cheie ( de
exemplu un atribut al unei clase nu poate fi definita ca o cheie primara a unei clase) sau pentru unicitatea constrangerilor.Desi toate aceste se pot realiza utilizand metode , constrangerile explicite sunt mai prietenoase, in sensul ca sunt mai putin predispuse la erori si mai accesibile in vederea verificarilor si a modificarilor.
9. Reglarea capacitati
Bazele de date relationale permite reglarea performantei sistemului oferind un numar mare de parametri care pot fi setati de catre administratorul de sistem. Parametrii include numarul de memorii tampon, cantitatea de spatiu liber rezervat pentru insertii de date si asa mai departe.
10. Suport putin pentru obiecte complexe
Funtionalitatea completa a obiectelor complexe nu este inca acceptat pe deplin.Odata ce s-a trecut dincolo de referinta si cod utilizat nu se gasesc operatii generice de exploatare. Toate referintele sunt independente de obiecte ,iar semantica relatiilor speciale cu obiectele complexe sunt ascunse.
11. Integrarea limitata cu sistemele existente de programare orientate pe obiecte
În cazul în care toate aplicatiile bazelor de date necesita numai OID cu obiecte de baze de date sau de memorie – indicii alungare a altor obiecte în memorie, de două până la trei ordine de magnitudine de performanță avantaj pentru OODBs peste RDBs ar fi valabil. Cu toate acestea, cele mai multe aplicații care necesită OID lookups au, de asemenea, acces la baza de date și actualizarea cerințelor care au RDBs fost proiectat pentru a răspunde.Aceste cerințe includ vrac de baze de date de încărcare; crearea, actualizare și ștergere de obiecte individuale (unul la un moment dat); recuperarea de la o clasă de unul sau mai multe obiecte care să îndeplinească anumite condiții de căutare; alătură de mai mult de o clasă; tranzacție se angajeze, și așa mai departe.Pentru astfel de aplicații, OODBs nu au nici o avantaje față de performanță RDBs.
12. Alte caracteristici pe care OOBD inca nu le-a dezvoltat
Acestea sunt trriger-ele, gestionarea meta data,constrangeri cum ar fi UNIQUE si NULL.
Asemanari si deosebirii intre bazele de date relationale si cele orientate pe obiecte
Evidentierea asemanarilor si a deosebirilor dintre modelarea relațională și modelarea
orientată obiect a datelor este semnificativă și de mare importanță atât pentru proiectanți de
baze de date cât și pentru utilizatori. Proiectanții, cunoscând foarte bine modelul relațional și apoi sesizând asemănările și deosebirile dintre cele două moduri de abordare a modelării datelor, vor putea valorifica și folosi experiența dobândită anterior ca bază substanțială pentru înțelegerea și însușirea metodologiei de proiectare a bazelor de date orientate obiect. Totodată, prin cunoașterea
asemănărilor și deosebirilor dintre cele două moduri de abordare apare posibilitatea conversiei
unui model relațional în obiectual și invers. De altfel, o astfel de practică a regăsirii în mod frecvent.
În cele ce urmează vom recurge la o tratare comparativă SGBDR și SGBDOO luând în
considerare regulile de evaluare a celor două tipuri de sisteme precum și modelarea datelor
sub aspectul conceptelor folosite și obiectivelor urmărite.
Comparații între abordarea obiectuală și cea relațională privind modelarea datelor
Deosebirea esențială între cele două tipuri de modelare a datelor o reprezintă încapsularea
în obiect atât a stării cât și a comportamentului acestuia, în vreme ce modelul Entitate –Relație evidențiază numai starea și nimic despre comportament.
În tabelul 1 se prezintă o comparație între principalele concepte utilizate în modelarea
obiectuală și relaționată a datelor.
Deosebirile dintre modelul BDOO și modelul BDR pot fi evidențiate și sub aspectul obiectivelor urmărite sau prin alte caracteristici, așa cum se poate observa din tabelul 2.
Proiectarea aplicatiei
Sistemul de fisiere
Sistemele multiuser si multitasking au nevoie de o delimitare foarte clara a permisiunilor.
S-a implementat sistemul de permisiuni a fisierelor (implicit si al directoarelor), astfel, un fisier se poate comporta in diferite moduri in functie de persoana care il acceseaza. Daca un fisier este accesat de proprietarul fisierului se comporta intr-un anumit fel, daca este accesat de altcineva dar care face parte din grupul care asociat fisierului se comporta in alt fel, iar daca este accesat de oricine altcineva (care nu are nici o legatura cu fisierul) se comporta intr-un mod diferit.
Acest lucru se realizeaza printr-un sistem relativ simplu. Fisierele au 3 cateogrii de utilizatori si anume: proprietarul fisierului, membrii grupului asociat fisierului, si restul utilizatorilor. Fiecarei categorii i se pot da 3 drepturi si anume: executare, citire, scriere (sau combinatii ale acestor 3 categorii).
De exemplu:
drwxr-xr-x 2 root wheel 512 Jun 25 21:00 ./
Fiecare linie incepe cu o secventa de 10 caractere. Primul caracter arata daca ceea ce vedem este un fisier simplu (-) sau daca e director (d). Urmatoarele 9 caractere sunt grupe de cate 3 corespunzatoare celor 3 categorii de utilizatori (proprietar, membru al grupului, utilizator simplu). Fiecare grup de 3 caractere prezinta permisiunile asupra fisierului.
Adica, caracterele 2, 3, 4 ne arata ce drepturi are proprietarul fisierului, caracterele 5, 6, 7 ne arata ce drepturi au utilizatorii din grupul asociat (in cazul nostru wheel) iar caracterele 8, 9, 10 ne arata ce drepturi au ceilalti utilizatori.
In cazul nostru, proprietarul (root) are drepturile rw- adica citire (r – read) si scriere (w – write). Linia de dupa rw ne arata ca proprietarul NU are dreptul de executie asupra fisierului. Acest lucru inseamna ca fisierul respectiv poate fi citit sau modificat de proprietar dar sistemul de operare nu il vede ca script sau program executabil. Utilizatorii din grupul asociat fisierului si restul utilizatorilor au aceleasi drepturi (r–), adica au doar dreptul de citire.
In cazul unor sisteme mai exista si alte drepturi asupra fisierelor, cu mar fi protectia la stergere. Daca un fisier este protejat la stergere, nici un utilizator (incluzand proprietarul si utilizatorul root) nu poate sterge acel fisier indiferent de drepturile care le are.
Matisse
Matisse este prima baza de date care pune impreuna dezvoltarea obiectuala cu gestionarea si furnizeaza capabilitatile necesare de catre dezvoltarea obiectuala si IT pentru a depasi deficientele primelor baze de date aparute.
Direct object management
Matisse sprijina pe deplin modelul obiectual,incluzand caracteristici cum ar fi clase, mostenire si incapsulare.In termeni de management, Matisse a adus impreuna cele mai bune aspecte obiectuale si relationale modelului sistemelor bazelor de date eliminand nevoia maparii si permitand obiectelor sa fie accesate in mod direct.Indepartarea dependentei maparii obiect-relational, permite sa mapeze obiecte direct in baza de date.Acest lucru inseamna ca de asemenea nu este necesar translatarea dintre obiecte si tabelele relationale, nu intervin Join-urile.
Suport UML
In mod traditional, Matisse a folosit ODL (object definition language) ca limbaj de definire a obiectelor.ODL este acum inlocuit de UML (Unified Modeling Language), preferat pentru a defini si modela obiecte.Pentru a se asigura ca dezvoltatorii de obiecte pot utiliza toate beneficiile pe care UML le ofera, Matisse preia iesirea UML direct de la instrumente cum ar fi Rational Rose o converteste in schema bazei de date a lui Matisse(ocolind ODL).
Acces la SQL
Gestionarea datelor in Matisse este posibila, putand fi citite, actualizate sau sterse utilizand SQL.Astfel ca dezvoltatorii se pot folosi de experienta cu diferite limbaje, incluzand si SQL.
Performanta
Matisse asigura coerenta datelor in timp ce perimite aplicatiilor sa efectueze citiri.Matisse ofera posibilitatea de a incarca sau actualiza un volum mai mare de date in acelasi timp in care alte aplicatii citesc date, in comparatie cu bazele de date relationale care nu ofera aceasta posibilitate.
Acest lucru inseamna ca Matisse poate suporta tranzactii si analiza datele unui singur sistem.
Cand un obiect este actualizat, noua versiune a sa se creeaza intr-o noua locatie.Aplicatiile pot citi versiunea anterioara a obiectului in timp ce noua versiune este creata ,si deoarece toate referintele la vechile obiecte au ramas intacte, va exista o viziune uniforma a bazei de date.Odata ce noua versiune a obiectului a fost creata, iar transactiile s-au terminat, cererile vor fi transferate catre noua versiune.In cazul in care o tranzactie a esuat, se va redirecta spre vechiul obiect., astfel nemai fiind necesara o operatie de Roll Back pentru a realiza consistenta bazei de date.
Ca un beneficiu suplimentar, aplicatiile pot examina istoria datelor in orice moment, oferindu-se acces la versiunile anterioare a obiectelor, daca aplicatiile au cerut acest lucru in mod explicit, sau mai pot identifica obiectele care au suferit schimbari, au fost sterse sau adaugate.O aplicatie de analiza financiara ar putea folosi aceasta caracteristica pentru a urmari de exemplu schimbarile de pret.
Bazele de date relationale au probleme de performanta cand datele sunt preluate din mai multe tabele, executand join-uri pentru a stabili legaturile datelor din tabele.Performanta aplicatiilor bazate pe SQL este uneori substantiala fata de bazele de date relationale deoarece arhitectura lui Matisse elimina necesitatea executarilor Join-urilor cand acceseaza datele.
Aceasta se datoreaza faptului ca Matisse foloseste pre-calcule relationale (join-uri rapide) pentru a localiza si accesa rapid datele din mai multe tabele.Referintele intre obiecte face posibila existenta a join-urilor rapide.
Atunci cand o clasa este definita in Matisse, sunt definite de asemenea si relatiile cu alte clase ale acesteia. Aceste relatii permit ca Matisse sa acceseze direct datele, proces transparent aplicatiilor.
Scalabilitatea
Matisse este scalabil deoarece serverul implementeaza fire de executie in partea de sus a nucleului.
Stocarea de progeduri, triggere, mentinerea integritatii
Asa cum ar fi de asteptat de la cele mai importante baze de date relationale, Matisse de asemenea prevede stocarea de proceduri SQL, triggere si mentinerea integritati.Procedurile sunt secvente de declaratii SQL ce se executa pe server si sunt folosite pentru a face scrierea de cod mai eficienta si pentru performante.O procedura stocata pe server poate fi folosita de mai multe aplicatii.
Triggerele sunt proceduri stocate a caror executie este initiata atunci cand este efectuata o anumita operatie asupra bazei de date, sau atunci cand rezultatul unei operatii este o conditie predefinita a bazei de date.Spre deosebire de proceduri, acestea nu pot fi apelate in mod direct de catre o aplicatie.Triggerele sunt utilizate pe scara larga la implementarea constrangerilor bazei de date si pentru a mentine integritatea bazei de date.
Mentinerea integritatii bazelor de date relationale a creat necesitatea unei munci suplimentare a dezvoltatorilor.Atunci cand datele dintr-o tabela sunt sterse sau mutate,alte tabele care refera la acele date trebuie de asemenea sa fie actualizate.De exemplu daca un client este eliminat, ordinele de asemenea trebuiesc sterse.La Matisse, mentinerea integritatii este mult simplificata prin relatiile dintre obiecte.Relatiile sunt bidirectionale.Acest lucru asigura pastrarea integritatii in mod automat, iar daca un obiect este sters ,toate referintele la el sunt actualizate.
Standards compliance
Obiectele in Matisse si interfata Sql asigura compatibilitatea si portabilitatea software-ului.
Accesul ODL, Java si C++ este relaizat prin ODMG si UML.Matisse sprijina un set complet de caracteristici accesibile prin aceste limbaje standarde incluzand mostenirea multipla, incapsularea si polimorfismul.Matisse de asemenea ofera ca suport standardul JDBC/ODBC pentru acces la SQL din aplicatii Java sau alte limbaje.Matisse are suport si pentru standardele EJB si J2EE.
Chiar daca o organizatie de dezvoltare este focalizata in principal pe Java sau un alt limbaj orientat pe obiecte, este adesea nevoie de existenta unui sofware bazat pe SQL.Produse cum ar fi PowerBuilder si Crystal Reports furniza o cale rapida de a genera rapoarte si aplicatii.Multe organizatii utilizeaza aplicatii de analiza a datelor care se bazeaza pe SQL pentru a extrage informatii din baza de date.
Matisse prevede urmatoarele avantaje pentru dezvoltatori si profesionistii IT:
asigura consistent datelor, permite recuperarea datelor in cazul in care o tranzactie esueaza si
asigura accesul la istoricul datelor
permite citirea in timpul scrieri si simultan poate incarca/actualiza o mare cantitate de date
in timp ce suporta interogari la nivel inalt.
arhitectura Matisse incarca automat resursele disponibile de pe disk ,facand ca baza de date
sa fie adecvata pentru sistemele embedded sau pentru cele distribuite.
este extreme de flexibil, modificarile pot fi effectuate in orice moment,chiar si cand baza de
date este online.
contine caracteristici extinse de stocare, manipulare si indexare a diverselor tipuri de date
cum ar fi text ,sir de caractere.
Matisse este o fuziune intre relational si tehnologia orientata pe obiect.Aceasta a fost
conceputa de la inceput sa se ocupe de obiecte si de a permite dezvoltarea rapida a aplicatiilor orientate pe obiect ca model si de a rezolva problemele lumii reale.
ofera suport pentru maparea directa a obiectelor, ANSI SQL, standard, pentru Unified
Modeling Language (UML), performanta inalta si administrare zero, ceea ce inseamna ca Matisse a fost capabil sa treaca peste decalajul dintre dezvoltatorii obiect si managementul obiectelor.
este pozitionat pentru a oferi baza optima pentru dezvoltarea si implementarea obiectului.
Aceasta permite dezvoltatorilor si IT de a creea ,implementa si administra mai rapid,mai ieftin si mai eficient aplicatiile si serviciile.
Cu succesul lui Matisse in Europa, si cu succesul solutiei Matisse-powered, dezvoltatorii de obiecte obisnuiti cu generatiile anterioare a bazelor de date obiectuale si baze de date relational-obiectuale, au gasit in Matisse un SQL compatibil pe deplin si care depaseste performanta si scalabilitatea bazelor de date relationale.
Matisse Php extins
Matisse PHP extins prevede o interfata intre Matisse baze de date orientate pe obiect si
limbajul PHP.Acesta consta dintr-un set de clase care ofera acces la obiectele Matisse.Obiectele sunt stocate pe o platforma independent de format, astfel incat obiectele pot fi create utilizand limbajele C, C++, Java etc.Interfetele pot fi accesate cu ajutorul PHP-ului fara a fi nenvoie de conversii.De asemenea obiectele create sau modificate de catre Matisse-PHP extins sunt accesibile din orice alta platforma sau limbaj in mod transparent.
Extensia Matisse-PHP este formata din doua niveluri :
Un nivel scazut este o extensie PHP scrisa in limbajul C care mapeaza fiecare functie Matisse C in functii PHP.Acest nivel se gaseste in “php_matisse.so” ( sau in biblioteca “php_matisse.dll” pentru platformele Windows ) si va fi dinamic incarcat de catre PHP.
Al doilea nivel este un modul PHP numit matisse.php. Acest modul contine un set de clase PHP care incapsuleaza toate functiile primului nivel. Acest nivel ofera coerenta si o modalitate usoara de a accesa din PHP obiecte Matisse.
Matisse PHP extins ofera posibilitatea de a crea clase, atribute, relatii etc., dar in general este preferabil sa se scrie fisiere ODL sau un set SQL pentru a face acest lucru.
Accesarea baze de date
Clasa Database permite gestiunea conexiunii la baza de date.
// establish the connection Conectarea la o baza de date cu un anumit nume de utilizator/parola se poate face uzitand de metoda Open.Metoda SetConnectionOption permite setarea unei optiuni pentru conexiunea stabilita.
$ db = new Database ( "aHostName", "aDatabaseName");
$db->open $db->setOption(MT_DATA_ACCESS_MODE, MT_DATA_DEFINITION);
$db->open("aUsername", "aPasswd");
Mai multe baze de date pot fi usor gestionate deschizand mai multe conexiuni si trecand de la o conexiune la alta.
$db1 = new Database("aHostName","aDatabaseName");
$db2 = new Database("aHostName_2","aDatabaseName_2");
// stabilirea conexiunilor
$db1->open();
$db2->open();
// selectarea bazei de date curente
$db2->select();
// deselectarea bazei de date curente si selectarea altei baze de date
$db2->unselect();
$db1->select();// close the connect
Pentru actualizarea unei baze de date trebuie pornita o tranzactie.O tranzactie poate fi deschisa doar cand este stabilita o conexiune.In momentul cand este accesata o baza de date nu este stabilita si o tranzactie implicit, tranzactia trebuind deschisa in mod explicit cu ajutorul metodei startTransaction, apoi se pot face actualizarile.
Doar o tranzactie sau accesul versiune poate fi dechis pe o conexiune la un moment dat.
Versiunea bazei de date corespunzatoare unei tranzactii commit poate fi creata. Se poate defini prefixul numelui unei versiuni a unei baze de date atunci cand se executa commit pe o tranzactie.
Metoda commit returneaza un nume unic pentru baza de date, evitand astfel conflictele de nume.
$dbVersionName = $db->commit("Monday");
O tranzactie poate fi oprita in orice moment utilizand metoda rollback.
Argumentul metodei startVersionAcces ,atunci cand este specificata trebuie sa fie numele versiuni bazei de date generat.Daca nu este specificat explicit atunci va fi accesat versiunea curenta.
Modul de deschidere si inchidere a unei versiuni pentru acces este urmatorul:
$db->startVersionAccess("Monday00000561");
$db->endVersionAccess();
PHP nu intercepteaza exceptii, astfel ca dupa fiecare apel a unei metode Matisse ar trebui verificata variabila mt_sts utilizand functiile MtFailed() sau MtSuccess() astfel:
if (MtFailed()) {
// Management of the error
}
Erorile sunt raportate de indata ce acestea apar.Daca fisierul php.ini nu s-a setat in mod corespunzator , raportarea erorilor va fi vizibila in fisierul standard de iesire.In caz contrar se poate prelua cu ajutorul functiei MtError().
Pentru crearea obiectelor se pot utilize constructorii definite in clasa MtObject:
$cl = $db->getMtClass("Person");
$obj = new MtObject(cl);
O alta modalitate de a defini o clasa Person este descrisa mai jos:
Person extends MtObject {
function Person($firstname, $lastname) { function Person($firstname, $lastname) {
$this->MtObject($db->getMtClass("Person")) $ this->MtObject ($ db->getMtClass ( "Person"))
$this->setValue("FirstName",$firstname); $ this->setValue ( "firstname", $firstname);
$this->setValue("LastName",$lastname); $ this->setValue ( "lastname", $lastname);
} }
}
In exemplu de mai sus clasa Peson extinde clasa MtObject.Pentru a creea o instanta a clasei Person definita mai sus se va proceda astfel:
$p = new Person("John", "Smith");
Manipularea valorilor atributelor poate fi efectuata utilizand metodele getValue(), setValue() si clearValue().De exemplu pentru a seta valorile atributelor firstname si lastname a clasei Person vom scrie codul urmator:
$att = $db->getMtAttribute("LastName");
$cl = $db->getMClass("Person");
// crearea unui obiect
$aPerson = new MtObject($cl);
// setarea valorilor atributelor
$aPerson->setValue("FirstName","John");
$aPerson->setValue($att,"Smith");
Metoda setValue() permite setarea unei valori a unui atribut cu specificarea tipului de date a atributului.Setarea variabilei Age a unei instante Person :
$att = $db->getMtAttribute("Age");
$aPerson->setValue($att, 21, MT_SHORT);
Metoda clearValue permite eliminarea valorii curente a unui atribut.Atunci cand vom accesa atributul respectiv va returna valoarea implicita.
$aPerson->clearValue($att);
Accesarea valorilor atributelor a unei instante Person se va realiza in felul urmator:
$dict = $db->getMtEntryPointDictionary("LastNameDict");
$aPerson = $db->lookup("Smith", $dict);
$firstName = $aPerson->getValue("FirstName");
$lastName = $aPerson->getValue($att);
Metoda getExtValue returneaza descrierea completa a valorii.Aceasta metoda returneaza un tablou care contine urmatoarele cheii:
value – valoarea efectiva
default – o valoare booleana care indica daca value reprezinta valoarea implicita
dims – dimensiunile elementelor listei sau a tabloului
type – tipul datei.
Matisse stocheaza datele ca intregi, iar pentru a converti o data MtType intr-un sir de caractere se poate face uz de functia mt_type_to_string.Pentru compararea tipurilor exista predefinite constantele: MT_CHAR, MT_STRING, MT_INTEGER etc.A nu se folosi caracterul '$' inainte de definirea acestora.
$att = $db->getMtAttribute("LastName");
$dict = $db->getMtEntryPointDictionary("LastNameDict");
$aPerson = $db->lookup("Smith", $dict);
$lastNameVal = aPerson->getExtValue($att);
$type = $lastNamVal["type"];
echo "Type=" . mt_type_to_string($type);
if ($type == MT_STRING)
$lastName = $lastNameVal["value"];
Matisse –PHP extins prevede metode de citirea si actualizarea partilor unui atribut.Aceste metode ofera suport numai pentru MT_BYTES, MT_VIDEO, MT_AUDIO si LIST,cum ar fi MT_INTEGER_LIST, MT_SHORT_LIST, MT_TIMESTAMP_LIST… .
Metoda getListElements returneaza un tablou a carui elemente reprezinta valorile atributelor,inceputul tabloului fiind valoarea offset-ului.La sfarsitul tabloului se ajunge atunci cand lungimea valoarii citite este mai mica decat lungimea num care s-a dorit a fi citita.Acest lucru este ilustrat in exemplul de mai jos:
MtObject.getListElements($attr, $type, $num, $offset=MT_CURRENT_OFFSET)
Pentru actualizarea listei de valori a atributelor se poate folosi functia setListElements.
Aceasta va actualiza lista cu elementele elements,incepand de la offset-ul specificat.Cand discardAfter este adevarat, ultimul element din elements va deveni ultimul element al listei,alfel retul listei ar ramanea nemodificata.
MtObject.setListElements($att, $type, $elements, $offset=CURRENT_OFFSET, $discardAfter=1) )
Manipularea valorilor unor relati se poate realiza cu ajutorul metodei get/setSuccessors(). Valoarea returnata de catre aceasta este un tablou a carui elemente reprezinta instante a clasei MtObject.
$rel = $db->getMRelationship("Siblings");
// initializarea sau suprascrierea relatiei Siblings
$aPerson->setSuccessors($rel,array($brother));
// adaugarea unui obiect successor a relatiei Siblings
$aPerson->addSuccessors($rel,array($brother, $sister));
// stergerea relatiei
$aPerson->clearSuccessors($rel);
Accesarea instantelor clasei Person intre care exista relatia Siblings se face in felul urmator:
$siblings = $aPerson->getSuccessors($rel);
Un cursor reprezinta un set de obiecte, accesibile unul cate unul utilizand metoda de mai jos:
// deschiderea unui cursor
$cursor = $xxx->openXXXCursor(…)
// parcurgerea cursorului
while ($obj = $cursor->next()) {
}
// inchiderea cursorului
$cursor->close();
Atunci cand toate elementele unui cursor au fost vizitate, metoda next() va returna valoarea NULL.Inchiderea cursorului se va face cu metoda close().
Pentru a deschide un cursor cu o anumita cheie numita 'entry-point' stocata in entryPointDictionary se va apela metoda openEPCursor pe conexiunea curenta.
MtObjectCursor = MtObject.openEPCursor(string $key, MtEntryPointDictionary $dict, MtClass $cl=NULL)
Argumentul $cl filtreaza obiectele returnate de cursor.De exemplu pot fi selectate obiectele unei subclase. Mentionarea acestuia este optional.
$dict = $db->getMtEntryPointDictionary("LastNameDict")
$cl = $db->getMtClass("Person")
$cursor = $db->openEPCursor("Smith", $dict, $cl)
In exemplul de mai sus sunt preluate toate persoanele care se numesc Smith.
In cazul in care intrarea este un entry-point unic se va returna un singur obiect.
Metoda lookup returneaza obiectul prin care se poate accesa entry-point-ul.Daca acesta nu exista, metoda va returna valoarea NULL, iar daca exista mai mult de un singur obiect se va returna o eroare specificata prin InvalidOperation.
Metoda openInstanceCursor returneaza un cursor care permite vizitarea tuturor instantelor unei clase.
Putem accesa obiecte si folosind o declaratie SQL SELECT ,uzitand de metoda executeQuery astfel:
$stmt = new MtStatement();
$stmt->execute("SELECT * FROM Person WHERE LastName = 'Smith'");
$result = $stmt->getResultSet() ;
$num_col = $result->getColumnCount();
while ($result->next()) {
for ($col=1; $col <= $num_col; $col++) {
$type = $result->getType($col);
$val = $result->getValue($col);
…
}
}
$result->close();
$stmt->free();
Pentru a sterge din baza de date un obiect exista metoda remove().De exemplu daca se doreste stergerea obiectului aPerson a clasei Person vom scrie:
$aPerson->remove();
Clasa Discovery ( DOI ) ofera o interfata prin care se poate descoperi clasa unui obiect si permite manipularea continutului acesteia.
Matisse-Php extins permite extinderea schemei bazei de date in mod dinamic.Pentru aceasta, conexiunea bazei de date trebuie sa fie deschisa sub modul MT_DATA_DEFINITION.
Adobe Flex
Adobe Flex este un kit de dezvoltare software-ul lansat de Adobe Systems pentru
dezvoltarea și desfășurarea de aplicatii cross-platform rich Internet bazate pe platforma Adobe Flash. Flex applications can be written using Adobe Flex Builder or by using the freely available Flex compiler from Adobe. Aplicațiile pot fi scrise folosind Adobe Flex Builder sau prin utilizarea compilatorului Flex disponibil gratuit de la Adobe.
Inițial, în martie 2004, Macromedia a inclus un kit de dezvoltare software, un IDE, și o aplicatie integrata J2EE cunoscuta ca servicii de date Flex. Since Adobe acquired Macromedia in 2005, subsequent releases of Flex no longer require a license for Flex Data Services, which has become a separate product rebranded as LiveCycle Data Services . De cand Adobe a achiziționat Macromedia în 2005, pentru versiunile ulterioare de Flex nu mai este nevoie de o licenta pentru servicii de date Flex, care a devenit un produs separat ca LiveCycle Data Services.
In February 2008, Adobe released the Flex 3 SDK under the open source Mozilla Public License . Adobe Flash Player , the runtime on which Flex applications are viewed, and Adobe Flex Builder , the IDE built on the open source Eclipse platform and used to build Flex applications, remain proprietary. În februarie 2008, Adobe a lansat Flex 3 SDK deschisa sub Mozilla Public License. Aplicatiile Flex pot fi rulate cu ajutorul lui Adobe Flash Player, și cu Adobe Flex Builder, IDE poate fi construit pe platforma Eclipse și folosite pentru a construi aplicatii Flex.
Aplicatiile traditionale scrise de catre programatori a suferit o serie de schimbari pentru a se adapta la animațiile pentru care Flash Platforma a fost proiectat inițial. Flex seeks to minimize this problem by providing a workflow and programming model that is familiar to these developers. MXML , an XML -based markup language, offers a way to build and lay out graphic user interfaces . Flex încearcă să reducă la minimum această problemă prin furnizarea unui flux de lucru și a unui modelul de programare care este familiarizat cu acesti dezvoltatori. MXML, reprezinta un XML bazat pe limbaj de marcare, care oferă o modalitate de a construi și expune interfețe grafice pentru utilizatori. Interactivity is achieved through the use of ActionScript , the core language of Flash Player that is based on the [[ ECMAScript ]] standard. Interactivitatea este realizata prin utilizarea lui ActionScript, bazat pe limbajul Flash Player care la gandul sau este bazat pe standardul ECMAScript.
Flex SDK vine cu un set de componente de interfață cu utilizatorul, inclusiv butoane, list box-uri, trees, rețele de date, mai multe controale de tip text, precum și diverse containere layout, Charts and graphs are available as an add-on. diagrame și grafice. Other features like web services , drag and drop, modal dialogs, animation effects, application states, form validation, and other interactions round out the application framework. Alte caracteristici ca servicii web, glisați și fixați, dialoguri, efecte de animatie, form de validare, precum și Framework-uri.
In a multitiered model , Flex applications serve as the presentation tier.În modelele multitiered, aplicatiile Flex pot servi ca prezentare.Unlike page-based HTML applications, Flex applications provide a stateful client where significant changes to the view don't require loading a new page.Spre deosebire de aplicațiile bazate pe HTML, aplicatiile Flex ,în cazul în care au loc schimbări semnificative nu necesită încărcarea unei pagini noi. Similarly, Flex and Flash Player provide many useful ways to send and load data to and from server-side components without requiring the client to reload the view. În mod similar, Flex si Flash Player ofera multe modalități utilebde a trimite și de a încărca datele către și de la partea de server, fără a necesita incarcarea componentelor client. Though this functionality offered advantages over HTML and JavaScript development in the past, the increased support for XMLHttpRequest in major browsers has made asynchronous data loading a common practice in HTML-based development as well.Cu toate că această funcționalitate a oferit avantaje față de HTML și JavaScript în trecut, necesitatea suportului pentru XMLHttpRequest în majoritatea browsere-lor a făcut incarcarea datelor sa fie asincrone în dezvoltarea HTML.
Technologies that are commonly compared to Flex include OpenLaszlo , Ajax , XUL , JavaFX and Windows Presentation Foundation technologies such as Silverlight . Tehnologiile care sunt frecvent comparate cu Flex includ OpenLaszlo, Ajax, XUL, JavaFX și tehnologii Windows Presentation Foundation, cum ar fi Silverlight.
Although popular as a rich internet application development environment, Flex is not without its detractors. Deși cunoscut ca un mediu de dezvoltare pentru aplicații de Internet, In February, 2009, analyst firm CMS Watch criticized the use of Flex for enterprise application user interfaces [ 1 ] . in februarie, 2009, firma CMS Watch a criticat utilizarea Flex pentru interfețe.
Beneficiile lui Flex 3
experienta utilizatorului bogata
Flex permite dezvoltatorii de aplicații web a crea în mod eficient interactivitatea, interfețe expresive pentru aplicații web și aplicatii desktop. Aplicațiile construite cu Flex pot ajunge la mai mulți utilizatori, care au posibilitatea de a îmbunătăți si satisface productivitatea și pentru a genera creșterea profitului.
Cross-platform, accesibile aplicațiilor
Instalat în peste 98% din calculatoarele conectate la Internet, Flash Player oferă in mod unic, consecvent, si accesibil utilizatorului browsere și platforme. Aceasta este o întreprindere de clasa client runtime avansat cu grafică vectorială, capabilea de a manipula cele mai dificile, intensive aplicații de date în timp ce efectuează aplicațiile la viteza de desktop.
Adobe AIR integration
Noul Adobe AIR runtime client permite aplicațiilor Internet bogate (RIAs) a rula în spațiul de lucru, crearea de noi oportunități pentru aplicatii interesante de înaltă performanță online / offline. Flex framework oferă suport nativ pentru noul AIR API-uri, și pentru software-ul Adobe Flex Builder ™ 3 , oferă toate instrumentele necesare pentru a construi, depana, inpacheta și a semna cererile construite pe Adobe AIR.
Developer productivity
Asamblarea și RIAs build, foloseste mai mult de 100 de componente bogate, pentru aplicatii. Utilizeaza puternicul Eclipse bazat pe Flex Builder pentru a accelera dezvoltarea, depanare și testare a aplicatiilor web și desktop.
Adobe Creative Suite 3 integration
Asocierea lui Flex cu Adobe Creative Suite ® 3 software prevede în concordanță cu fluxurile de lucru, cele mai bune instrumente. Utilizeaza Adobe Flash, Fireworks ®, Illustrator ® Photoshop ® pentru a crea bunuri în formate Flex. Utilizeaza Flex Builder pentru a importa ușor în interfața de RIA.
Usurinta in utilizare
Se poate incepe rapid cu o biblioteca de componente, skin, containere, precum și aplicatii. Se poate utiliza Wizards pentru a se conecta la serviciile web sau pentru a genera baze de date în Adobe ® ColdFusion, PHP, ASP.NET, și Java ™.
Open source, standards-based framework
Flex 3 este disponibil ca software open source prin intermediul Open Source Flex SDK proiect. Flex provides a modern, standards-based language and programming model supporting common design patterns. Flex oferă o moderne, bazate pe standarde de limbă și de modelul de programare sprijinirea modele comune de design. You can extend and enhance the open source framework to suit your needs and contribute to the evolution of Flex. Puteți extinde și consolida open source cadru pentru a se potrivi nevoilor dumneavoastră și de a contribui la evolutia Flex.
Arhitectura Multitier
In ingineria software, arhitectura multi-tier (adesea denumită arhitectura n-tier) este o
arhitectura client-server, în care prezentarea, prelucrarea aplicatiilor, precum și administrarea datelor sunt procese separate logic. Vom lua ca exemplu o aplicație care utilizează middleware pentru a raspunde cererilor serviciilor de date între un utilizator și o bază de date de angajați arhitectură multi-tier. Cea mai răspândită utilizare de "arhitectura multi-tier" se referă la trei niveluri de arhitectura. [***08,b]
Conceptele de strat și niveluri sunt adesea folosite alternativ.Cu toate acestea, un punct de vedere comun este faptul ca nu există o diferență, și că un strat este un mecanism de structurare logica pentru elementele solutiei produsului software, în timp ce un nivel fizic este un mecanism de structurare a sistemului de infrastructura.
“Three-tier” este o arhitectura client-server, în care interfața cu utilizatorul, procesul logic functional ( "reguli de afaceri"), stocarea datelor și accesul la date sunt dezvoltate și întreținute ca module independente, de cele mai multe ori pe platforme separate.
Modelul three-tier este considerat a fi o arhitectura software si un model de design software.
În afară de avantajele obisnuite a software-ului modular cu interfețe bine definite, pe trei nivele de arhitectura este destinat pentru a permite oricarui din cele trei niveluri de a fi modernizate sau înlocuite independent, in functie de cererea tehnologiei. De exemplu, o schimbare a sistemului de operare în prezentarea tier ar afecta numai codul interfetei cu utilizatorul.
De obicei, interfața cu utilizatorul rulează pe un desktop PC sau stații de lucru și utilizează o interfața utilizator grafică standard, procesul logic functional poate consta din una sau mai multe module separate, care rulează pe o stație de lucru sau pe o aplicatie server, și un RDBMS pe un server de baze de date sau mainframe conține datele stocate logic. Nivelul de mijloc poate consta din mai multe niveluri (caz în care arhitectura globală se numește "n-tier arhitecture").
Arhitectura three-tier consta din următoarele trei niveluri:
Presentation Tier
Acesta este cel mai de sus nivel al aplicatiei.Nivelul prezentare afișează informații referitoare la servicii precum navigarea marfi, servicii de achiziție, precum și conținutul coșului de cumpărături. Comunică cu celelalte niveluri prin afișarea rezultatelor la browser-ul client, precum și toate celelalte niveluri în rețea.
Application Tier
Logica Tier este scosa din nivelul prezentare, ca si propriul nivel,controlează functionalitatea aplicatiilor prin detalierea prelucrarii performantei.
Data Tier
Acest nivel constă din serverul de baze de date. Aici, informațiile sunt stocate și extrase. Acest nivel păstrează neutru și independent date, de la aplicatiile server. Ofera date propriului nivel si de asemenea îmbunătățește scalabilitatea și performanta.
Comparatie cu arhitectura MVC
La prima vedere, cele trei niveluri pot părea similare cu conceptul MVC (Model View Controller), cu toate acestea, din punct de vedere topologic acestea sunt diferite.O regulă fundamentală în arhitectura three-tier este faptul ca nivelul client nu comunică niciodata direct cu nivelul date; în model cu trei nivele comunicarea trebuie să treacă prin nivelul middleware. Conceptual arhitectura three-tier este liniară. Cu toate acestea, arhitectura MVC este triunghiulara: nivelul View trimite actualizari la nivelul Controller, Controller-ul actualizeaza nivelul Model, și nivelul View primeste actualizari direct de la Model. [***08,b]
Dintr-o perspectivă istorică conceptul de arhitectura three-tier a apărut în anii 1990, de la observațiile facute de sistemele distribuite (de exemplu, aplicatii web) unde nivelul client, middleware si nivelul de date au mers pe platforme separate fizic. Întrucât MVC vine din deceniile de dinainte (lucrandu-se la Xerox PARC la sfârșitul lui 1970 și începutul lui 1980) și se bazează pe observațiile aplicațiilor care au mers pe o singura statie de lucru; MVC a fost utilizat la aplicatii distribuite mult mai târziu în istoria sa .
Utilizarea WEB Development
In dezvoltarea domeniului Web, modelul three-tier este adesea folosit atunci cand se face referire la pagini Web, de obicei la comertul electronic,care sunt construite folosind trei niveluri :
Un front-end server web care serveste continutului static
Un mijloc de prelucrare a conținutului dinamic si nivelul generației Application Server, de exemplu, Java EE, ASP.net, platforma PHP.
Un back-end database, care cuprinde ambele seturi de date si sistemul de gestionare a bazei de date sau software-ul care gestioneaza si ofera acces la date RDBMS.
Transfer de date între niveluri este responsabilitatea arhitecturii. Protocoalele poat include unul sau mai multe dintre SNMP, CORBA, Java RMI,. NET Remoting, Windows Communication Foundation, Sockets, UDP, Web Services sau alte protocoale standard. De cele mai multe ori middleware este utilizat pentru a conecta nivelurile separate. Nivelurile separate de multe ori (dar nu neapărat) pot rula pe servere separate fizic, iar fiecare nivel poate rula pe un Cluster.
BIBLIOGRAFIE
[Jia98] Ionel Jian, Liliana Jian, Baze de date , Editura MIRTON, Timisoara, 1998
[***08,a] Adobe Flex,
http://en.wikipedia.org/wiki/Adobe_Flex, 2008
[***08,b] Multitire arhitecture,
http://en.wikipedia.org/wiki/Multitier_architecture,2008
[***06,b] Matisse PHP Extension Reference,
http://www.matisse.com/pdf/developers/php_pg.pdf ,2006
[***03,c] The emergence of the Object-SQL Database,
http://www.matisse.com/pdf/product_information/collateral/the_emergence_of
theobject-sql_database.pdf , 2003
[Sik03] Sikha Bagui,Achievements and Weaknesses of Object -Oriented Database,
Journal of Object Technology, Vol.2, Nr.4,Iulie-August 2003
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: Gestiunea Unor Obiecte Intr Un Mediu Multiuser (ID: 134320)
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.