04/06/2004 Sikha Bagui

Dezvoltarea sistemelor de baze de date orientate pe obiect a început la mijlocul anilor 1980 ca răspuns la nevoia de a îndeplini cerințele aplicațiilor diferite de cele deservite și deservite de sistemele de baze de date relaționale. Să ne uităm la progresele în tehnologia bazelor de date orientate pe obiecte, precum și la provocările pe care comunitatea de dezvoltare încă trebuie să le depășească pentru ca tehnologia bazelor de date orientate pe obiecte să devină la fel de răspândită ca tehnologia bazelor de date relaționale.

Dezvoltarea sistemelor de baze de date orientate pe obiect (așa-numitele tehnologii de baze de date de generația a cincea) a început la mijlocul anilor 1980 din cauza necesității de a îndeplini cerințele altor aplicații decât cele ale aplicațiilor de procesare a datelor care sunt caracteristice sistemelor de baze de date relaționale ( tehnologia bazelor de date a patra generație). Încercările de a utiliza tehnologiile de baze de date relaționale în aplicații complexe, cum ar fi proiectarea asistată de computer (CAD); fabricație asistată de calculator (CAM); tehnologie de programare; sistemele bazate pe cunoștințe și sistemele multimedia au expus limitările sistemelor baze de date relaționale (RDB). Odată cu apariția unei noi generații de aplicații de baze de date, au apărut nevoi în cel mai bun mod posibil satisfăcut la cerere baze de date orientate pe obiecte (OODB).

Au fost propuse multe definiții ale orientării obiectelor și ale bazelor de date orientate pe obiecte, dar vom defini bazele de date orientate pe obiecte ca fiind acelea care combină orientarea obiectelor cu capabilitățile bazei de date. Orientarea obiectelor face posibilă reprezentarea și modelarea mai directă a problemelor din lumea reală și funcționalitatea bazei de date necesare pentru a asigura stabilitatea datelor și accesul paralel al mai multor utilizatori la informațiile aplicației.

În prezent, pe piață există peste 25 de sisteme OBD. Printre acestea se numără sistemul GemStone de la Servio, ONTOS de la Ontos, ObjectStore de la Object Design și multe altele. În plus, sistemele de gestionare a bazelor de date relaționale dezvoltate de Oracle, Microsoft, Borland și Informix au inclus instrumente orientate pe obiecte. Multe dintre aceste produse au apărut în a doua jumătate a anilor 80, iar astăzi, după aproape un deceniu și jumătate de dezvoltare, nu au ajuns încă la maturitate; Acesta este unul dintre motivele pentru care până astăzi piața mondială pentru aplicații reale nu se grăbește să accepte sisteme OBD. Printre OODB-urile moderne, aproape nu există sisteme cu drepturi depline comparabile cu sistemele moderne de baze de date relaționale. Să discutăm principalele realizări și probleme asociate cu starea actuală a OBD.

Model OOBD

Motivul apariției sistemelor de baze de date orientate pe obiect a fost necesitatea unei reprezentări și modelări mai adecvate a entităților din lumea reală, deoarece OODB-urile oferă un model de date mult mai dezvoltat decât bazele de date relaționale tradiționale. Paradigma OODB se bazează pe o serie de concepte de bază, cum ar fi obiectul, identificabilitatea, clasă, moștenirea, supraîncărcarea și legarea leneșă.

Într-un model de date orientat pe obiecte, orice entitate din lumea reală este reprezentată de un singur concept - obiect. Un obiect are o stare și un comportament asociat cu el. Starea unui obiect este determinată de valorile proprietăților sale - atribute. Valorile proprietăților pot fi valori primitive (cum ar fi șiruri de caractere sau numere întregi) și obiecte neprimitive. Un obiect non-primitiv, la rândul său, constă dintr-un set de proprietăți. Prin urmare, obiectele pot fi definite recursiv în termenii altor obiecte. Comportamentul unui obiect este determinat folosind metode, care operează asupra stării unui obiect.

Fiecare obiect are un sistem definit identificator unic. Obiectele care au aceleași proprietăți și comportament sunt grupate în clase. Un obiect poate fi o instanță a unei singure clase sau a mai multor clase.

Clasele sunt organizate într-o ierarhie de clasă. Subclasa moștenește proprietățile și metodele superclasei; În plus, subclasele pot avea proprietăți și metode individuale. În unele sisteme, cum ar fi ORION, o clasă poate avea mai multe superclase (moștenire multiplă), în timp ce în alte sisteme numărul de superclase este limitat la una (moștenire unică).

Majoritatea modelelor permit suprasarcina proprietăți și metode moștenite. Supraîncărcarea constă în înlocuirea unui domeniu de proprietate cu un domeniu nou sau înlocuirea unei implementări a unei metode cu o altă implementare a acesteia.

Avantajele modelului OOBD

Bazele de date orientate pe obiecte permit ca obiectele complexe să fie reprezentate într-un mod mai direct decât sistemele relaționale. Să ne uităm la câteva dintre realizările existente în domeniul OOBD. Sistemele OODB permit utilizatorilor să definească abstracții; facilita proiectarea unor conexiuni; elimină necesitatea cheilor definite de utilizator; susține un nou set de predicate de comparație; în unele cazuri nevoia de conexiuni este eliminată; în unele situații oferă performanțe mai bune decât sistemele bazate pe model relațional; oferi suport pentru versiuni și tranzacții de lungă durată. În cele din urmă, algebra obiectelor a fost dezvoltată - deși poate nu încă la fel de detaliat ca algebra relațională.

Definirea abstracțiilor personalizate

Bazele de date orientate pe obiecte oferă capacitatea de a defini noi abstracții și de a controla implementarea acelor abstracții. Aceste noi abstracții pot corespunde structurilor de date necesare în probleme complexe, noi tipuri de date abstracte. Cu alte cuvinte, pachetele moderne OODB oferă utilizatorului posibilitatea de a crea o nouă clasă cu atribute și metode, să aibă clase care moștenesc atribute și metode din superclase, să creeze instanțe ale clasei, fiecare cu un identificator de obiect unic, să recupereze aceste instanțe una câte una. unul sau în grupuri și încărcați și executați metode. În plus, OODB-urile permit definirea obiectelor ca colecții ale altor obiecte, iar colecțiile permit mai multe niveluri de imbricare. Proprietățile pot avea, de asemenea, o structură complexă și sunt definite folosind constructorul de colecție. Mai mult, ele pot avea ca valori obiecte non-primitive, ceea ce face posibilă formarea de structuri de obiecte profund imbricate.

Proprietățile cu mai multe valori sunt utilizate în modelele de date orientate pe obiecte pentru a exprima structuri complexe de date. În modelul relațional, acest lucru se realizează prin relații și îmbinări suplimentare.

Un exemplu de pachet OODB care are toate capabilitățile menționate este ENCORE. Modelul de date din ENCORE se bazează în principal pe abstractizarea datelor. ENCORE permite subtiparea (moștenirea), încapsularea, structurile complexe, identificarea obiectelor și legarea metodei leneșe. În plus, ENCORE oferă posibilitatea de a lega obiecte folosind proprietăți. În sistemul ENCORE, o proprietate p asociază un obiect x cu un set de obiecte S, fără nicio indicație despre modul în care este calculată asocierea. Poate fi calculat prin specificarea directă a identificatorului set S (sau a identificatorilor membrilor săi) sau prin potrivirea valorilor altor proprietăți, ca într-o îmbinare.

Design ușor al unor conexiuni

Bazele de date orientate pe obiecte suportă o facilitate de relație inversă pentru a exprima referințe reciproce între două obiecte (relație binară). Un astfel de sistem asigură integritatea referenţială prin stabilirea unui backlink adecvat imediat după crearea legăturii directe. Există chiar și o opțiune de a propaga automat eliminările prin aceste link-uri. Un exemplu de pachet OODB care asigură întreținerea automată a relațiilor inverse este ObjectStore.

Nu este nevoie de chei definite de utilizator

Modelul OODB are conceptul de identificatori de obiect, generați automat de sistem și garantați a fi unici pentru fiecare obiect. Acest lucru, împreună cu faptul că modelul OODB elimină necesitatea cheilor definite de utilizator, oferă bazelor de date orientate pe obiect alte avantaje. În primul rând, identificatorul obiectului nu poate fi modificat de aplicație. În al doilea rând, conceptul de identificabilitate a unui obiect implică un concept separat și consistent de identitate, independent de modul în care este accesat obiectul sau de modul în care obiectul este modelat prin date descriptive. Prin urmare, două obiecte nu sunt identice dacă au identificatori de obiect diferiți; în acest caz, obiectele pot avea aceleași structuri, iar toate proprietățile lor au aceleași valori. În modelul RDB, în care identificarea obiectelor se realizează prin chei definite de utilizator, astfel de obiecte ar fi considerate același obiect.

Prezența predicatelor de comparație

În RDB, comparația se bazează întotdeauna doar pe valori. În acest model, două tupluri sunt aceeași entitate dacă toate atributele lor cheie au aceleași valori. Cu toate acestea, în modelul OODB au fost dezvoltate și definite și alte tipuri de comparații.

1. Egalitatea obiectelor în funcție de identitatea lor. Două obiecte, S1 și S2 sunt egale dacă sunt același obiect (adică au același identificator de obiect).
2. Egalitatea obiectelor pe baza valorilor. Acest lucru poate fi determinat în doi pași - (a) două obiecte primitive sunt egale dacă au aceeași valoare; (b) două obiecte neprimitive sunt egale dacă au același număr de proprietăți, iar pentru fiecare proprietate pi a obiectului S1 există o proprietate pj a obiectului S2 egală cu aceasta ca valoare.
3. Egalitatea proprietății bazată pe valoare.
4. Egalitatea proprietăților în funcție de identitatea lor.

Mai puțină nevoie de conexiuni

Abilitatea de a naviga prin structurile obiectelor și expresiile de cale rezultate în ceea ce privește atributele obiectului ne oferă o nouă modalitate de a privi problema conexiunilor în OODB. O îmbinare relațională este un mecanism care potrivește două relații bazate pe valorile perechilor corespunzătoare de atribute din acele relații. Deoarece în OODB două clase pot avea perechi corespunzătoare de atribute, poate fi încă nevoie de o îmbinare relațională (sau unire explicită) în acest model. De exemplu, să presupunem că avem clasele Student și School, iar fiecare dintre aceste clase are atributele Nume și Vârstă. Deşi domeniile Atributele numeluiși Vârsta clasei de școală poate să nu fie aceeași cu domeniile atributelor Nume și Vârstă ale clasei Student, este posibil să dorim să asociem aceste clase pe baza valorilor acestor atribute (să zicem găsiți toți elevii a căror vârstă este mai mică decât vârsta școlii pe care o frecventează elevul).

Dar, după cum sa menționat deja, suportul pentru expresiile de cale poate reduce semnificativ nevoia de conectare a claselor în comparație cu situația dintr-un RDB. Există chiar și situații în care necesitatea unei îmbinări relaționale poate fi eliminată în totalitate. De exemplu, când domeniul unui atribut al clasei A este clasa B, preluarea identificatorilor de obiect ai unei clase care sunt stocate ca valori de atribut ale unei alte clase elimină necesitatea îmbinărilor implicite de obiecte.

Astfel, în bazele de date orientate pe obiecte, îmbinările implicite, care sunt generate de imbricarea ierarhică a obiectelor, sunt diferite de îmbinările explicite. Acestea din urmă seamănă cu îmbinări relaționale: două obiecte sunt comparate explicit prin valori de atribut sau identificatori de obiect. Mai mult, toate îmbinările explicite (bazate pe comparații de valori sau identificatori) nu pot fi exprimate într-un limbaj de interogare relațională, deoarece într-un RDB orice predicat poate conține numai atribute atomice.

Câștig de performanță

OODB-urile moderne nu sunt sisteme de baze de date complet în comparație cu RDB-urile moderne au mai multe caracteristici care le oferă beneficii de performanță.

1. Într-un OODB, valoarea unui atribut al unui obiect X al cărui domeniu este un alt obiect Y este identificatorul obiectului Y. Prin urmare, dacă o aplicație a preluat deja obiectul X și acum ar dori să recupereze obiectul Y, atunci DBMS poate prelua obiectul Y prin găsirea identificatorului său. Dacă acest identificator este adresa fizică a unui obiect, atunci obiectul poate fi preluat direct; dacă identificatorul este o adresă logică, atunci obiectul prin găsirea elementului tabel hash corespunzător (presupunând că sistemul menține un tabel hash care mapează identificatorul obiectului la o adresă fizică). Într-un RDB, acest lucru s-ar putea să nu fie atât de ușor, deoarece RDB nu acceptă identificatori de obiect.
2. A doua caracteristică a OODB care oferă beneficii de performanță este că în majoritatea OODB-urilor, atunci când un obiect este încărcat în memorie, identificatorii de obiect stocați în acel obiect sunt convertiți în pointeri de memorie. Deoarece RDB-urile nu stochează identificatori de obiect, ele nu pot stoca pointeri de memorie către alte tupluri. Incapacitatea de a naviga prin obiectele conținute în memorie este o proprietate fundamentală a RDB-urilor, iar scăderea rezultată a performanței nu poate fi compensată prin simpla creștere a cantității de memorie tampon. Deci, atunci când rulează aplicații care implică navigarea repetată a obiectelor înrudite încărcate în memorie, OODB-urile pot depăși semnificativ RDB-urile în performanță.
3. În plus, chiar dacă OODB-urile nu sunt indexate, poate fi convenabil să se efectueze interogări arbitrare care se potrivesc cu structura obiectului prin scanare secvențială, de exemplu. utilizați căi de referință între obiecte. Atunci când o solicitare este formulată într-o direcție nesuportată de legături, cererea respectivă va fi procesată prin crawling secvențial. Cu toate acestea, interogările formulate pe baza relațiilor de obiecte care nu sunt modelate direct prin referințe funcționează ineficient.

Suport pentru versiuni și tranzacții de lungă durată

RDB nu acceptă versiunea sau tranzacțiile de lungă durată. Un astfel de suport este disponibil în unele OODB-uri, deși cu capacități limitate.

Algebră obiect

Algebra obiect nu este la fel de detaliată sau matură ca algebra relațională. Dar oricum ar fi, o astfel de algebră există și definește cinci operații fundamentale care păstrează obiectele: unire, diferență, selectare, generare și mapare. Pe baza acestor operații fundamentale, pot fi definite și alte operații, cum ar fi intersecția. Regulile de transformare pentru optimizarea logică a expresiilor de algebră obiect păstrând echivalența sunt derivate în și . În timp ce operațiunile de unire, diferență și hartă produc în principal o mapare unu-la-unu, operațiunile de selectare și generare produc o mapare unu-la-mulți. Persistența obiectelor înseamnă că operațiile algebrice returnează obiecte care aparțin claselor de baze de date definite anterior și nu creează obiecte noi. Operatorul de unire returnează obiectele conținute în mulțimea P sau în mulțimea Q, sau în ambele mulțimi. Operatorul de diferență returnează un set de obiecte care aparțin mulțimii P dar nu și setului Q. select returnează un subset al mulțimii introduse. generate generează obiecte din cele care aparțin setului de intrare. map returnează setul de obiecte rezultat din fiecare aplicare a unei secvențe de metode.

Dezavantajele modelului OOBD

Era de așteptat ca metodele orientate pe obiecte să permită tehnologiei bazelor de date să facă un fel de salt cuantic. Cu toate acestea, în ciuda realizărilor de mai sus, OBD nu a reușit să aibă un impact semnificativ asupra stării de fapt în acest domeniu. Atât modelul, cât și tehnologia OOBD au încă puncte slabe.

Bazele de date orientate pe obiecte nu au facilitățile de bază cu care utilizatorii sistemelor de baze de date sunt obișnuiți și, prin urmare, se așteaptă să le vadă. Printre altele, putem observa: lipsa de interoperabilitate între RDB și OODB; optimizare minimă a interogărilor; lipsa algebrei de interogare standard; lipsa mijloacelor de susținere a cererilor; lipsa sprijinului pentru opinii; probleme de siguranță; lipsa suportului pentru schimbările dinamice ale definițiilor clasei; suport limitat pentru constrângerile de integritate; oportunități limitate setări de performanță; suport insuficient pentru obiecte complexe; integrare limitată cu sistemele de programare orientate pe obiecte existente; câștig limitat de performanță.

Lipsa interoperabilității între RDB și OODB

Pentru ca OODB să aibă un impact semnificativ asupra pieței bazelor de date, trebuie îndeplinite o serie de condiții.

1. Transformați OODB în sisteme de baze de date cu drepturi depline, care sunt suficient de compatibile cu RDB. Este necesară o cale de migrare pentru a asigura coexistența produselor existente și noi, precum și tranzitie lina de la primul la al doilea.
2. Oferiți instrumente de dezvoltare a aplicațiilor și mijloace de accesare a bazelor de date orientate pe obiecte.
3. Unificați arhitecturile RDB și OODB.
4. Unificați modelele Date RDBși OOBD.

Mijloace insuficiente pentru optimizarea interogărilor

Una dintre cele mai semnificative probleme în OODB este optimizarea interogărilor declarative. Optimizarea interogărilor OODB este îngreunată de complexitatea suplimentară a modelului de date orientat pe obiecte în sine. Această complexitate suplimentară se datorează mai multor factori.

1. Capacitatea utilizatorilor de a defini noi tipuri și clase folosind moștenirea face optimizarea interogărilor atât mai ușoară, cât și mai dificilă. Un exemplu în care această caracteristică ajută la optimizare este o interogare care implică intersecția seturilor de angajați și supraveghetori. Dacă Employee este o superclasă de Supervisor, atunci optimizatorul poate presupune că Supervisors este propriul său subset de Angajați și poate simplifica procedura de intersecție a setării. Un exemplu în care tipurile de date suplimentare limitează opțiunile de optimizare este unirea setului Studenți și Angajați; Superclasa pentru ambele clase este clasa Persoană. Dacă am dori să găsim toți supervizorii studenților și angajaților, am face mai întâi unirea și am folosi supervisor() .
2. Interogările se pot baza pe operații asupra colecțiilor, dar tipurile de optimizare care afectează seturi (sau multiseturi, sau liste etc.) trebuie combinate cu optimizarea tipurilor de obiecte conținute în aceste seturi. Un optimizator de interogări orientat pe obiecte trebuie să fie capabil să aplice rutine de optimizare care sunt specifice unor tipuri date, precum și rutine de optimizare care iau în considerare relațiile dintre obiecte de diferite tipuri.
3. Complexitatea procesării interogărilor în OODB este agravată de prezența obiectelor, metodelor și încapsulării complexe. Obiectele complexe generează expresii de cale, ceea ce face procesarea interogărilor mai complexă. Crearea de indici pe expresiile de cale, mai ales atunci când expresiile conțin metode arbitrare, complică procesarea interogărilor. Problema este și mai complicată dacă metodele au efecte secundare. O altă problemă cu expresiile de cale este că ele impun o ordine în care sunt apelate metodele de expresie de cale, iar această ordine poate fi destul de ineficientă. De exemplu, expresia cale Orders.part.name este mai bine evaluată de la dreapta la stânga dacă sunt multe Comenzi și puține Piese, dar dacă sunt multe părți și puține comenzi, expresia este mai bine evaluată de la stânga la dreapta. În plus, uneori expresiile de cale sunt procesate mai eficient folosind Join. Luați în considerare, de exemplu, o interogare cu o expresie cale s.comp.name, unde s aparține setului Students. Ar putea fi mai eficient (dacă numărul de companii, comp, este mic) să calculați mai întâi numele pentru fiecare companie și să stocați rezultatul într-un tuplu. Apoi, evaluarea expresiei de la student la numele companiei ar implica unirea setului Students la un set de tupluri prin potrivirea proprietății comp a clasei de studenți cu valoarea atributului Company al unui tuplu.
4. Limbile de interogare OODB acceptă utilizarea structurilor imbricate, care din nou pot complica semnificativ procesul de optimizare, deoarece îl transformă de la problema localaîntr-o problemă globală, deoarece este necesară cunoașterea globală a întregii expresii de interogare.
5. Când obiectele au identificabilitate, se pune întrebarea ce se înțelege prin egalitatea a două obiecte. Această problemă se transferă în limbile în care operatorii de comparație de egalitate sunt utilizați în predicate și în care trebuie luate decizii cu privire la crearea de noi obiecte atunci când se execută o interogare. Un optimizator de model orientat pe obiecte trebuie să fie capabil să facă față problemelor asociate cu crearea de noi obiecte și cu definiții alternative ale egalității.

Aceste probleme indică faptul că optimizarea interogărilor orientate pe obiecte este extrem de dificilă și este încă un domeniu de cercetare. Sistemele de baze de date orientate pe obiecte de astăzi oferă strategii de optimizare destul de simple. Problema optimizării conexiunilor necesită, de asemenea, mai multă atenție.

Lipsa algebrei de interogare standard

Un alt dezavantaj serios al OODB este lipsa standardelor de algebră de interogare. Această circumstanță face, de asemenea, dificilă optimizarea interogărilor. Pentru OODB au fost propuse mai multe limbaje formale de interogare bazate pe algebre și calcul. Aceste algebre și calcule diferă în mai multe privințe, atât prin expresivitate, cât și prin suportul lor pentru optimizarea regulilor de rescriere. Aproape toate aceste algebre se bazează pe variabile, adică. utilizați variabile pentru a stoca rezultate intermediare. KOLA, unul dintre pachetele OBD, este un produs pur funcțional; nu folosește variabile. Autorul susține că tocmai datorită absenței variabilelor algebra KOLA permite construirea unor sisteme de reguli mai puternice.

În RDB există o corespondență strânsă între operațiile algebrice și primitivele sistemului fizic de nivel scăzut. Această corespondență strictă se realizează prin mapări între relații și fișiere și între tupluri și înregistrări. Cu toate acestea, în OODB nu există o corespondență intuitivă similară între operațiile de algebră obiect și primitive sisteme fizice. Ori de câte ori se discută despre generarea planului de execuție, este, de asemenea, necesar, în primul rând, să se definească primitive de manipulare a obiectelor de nivel scăzut.

Lipsa suportului pentru interogări

Majoritatea OODB-urilor nu au suport pentru interogări. Pe puținele sisteme care au suficiente facilități disponibile, limbajul de interogare nu este compatibil cu ANSI SQL. Printre aceste instrumente de suport pentru interogări, nu există subinterogări imbricate, interogări cu seturi (unire, intersecție, diferență), funcții de agregare și GROUP BY, care unesc mai multe clase - caracteristici care sunt pe deplin suportate în RDB.

În plus, nu există un standard pentru interogările obiect, deși trebuie spus că s-au făcut încercări de a dezvolta un limbaj obiect, SQL. Este posibil ca SQL3 să fie întârziat cu câțiva ani.

Lipsa suportului pentru vizualizări

OODB nu acceptă vizualizări. Deși au fost făcute mai multe propuneri pe acest subiect, nu s-a ajuns la un consens asupra modului în care mecanismul de vizualizare ar trebui să funcționeze în OODB. Dezvoltarea unui mecanism de reprezentare orientat pe obiecte este complicată de proprietățile modelului precum identificabilitatea obiectelor. Care este identificatorul unui obiect dintr-o vedere? Pe de altă parte, există opinia conform căreia capacitatea de a încapsula date și moștenire face posibilă evitarea definițiilor explicite ale vederilor.

Probleme de siguranță

RDB-urile acceptă autorizarea, în timp ce majoritatea OODB-urilor nu. RDB-urile permit utilizatorilor să acorde și să revoce drepturi de citire sau modificare a definițiilor și tuplurilor în relații și vederi. OODB-urile vor putea deveni mai răspândite în afaceri doar dacă această funcționalitate este îmbunătățită.

Unele sisteme OODB solicită utilizatorilor să seteze și să elibereze în mod explicit blocările. Sistemele RDB setează și eliberează automat blocaje atunci când procesează interogări ale utilizatorilor și declarații de actualizare.

Lipsa suportului pentru modificări dinamice ale definițiilor clasei

În plus față de faptul că un singur model de date standard nu a fost încă dezvoltat pentru OODB, majoritatea OODB nu permit modificări dinamice ale schemei bazei de date, cum ar fi adăugarea unui nou atribut sau metodă la o clasă, adăugarea unei noi superclase la o clasă , ștergerea unei superclase a unei clase, adăugarea unei noi clase și ștergerea clasei. RDB-urile permit utilizatorului să schimbe dinamic schema bazei de date folosind comanda ALTER; pot fi adăugate la relație coloană nouă, relația poate fi ștearsă, iar în unele cazuri este posibilă eliminarea unei coloane din relație.

Majoritatea OODB-urilor nu au, de asemenea, controlul automat al extensiilor de clasă. Dacă este necesară o extensie de clasă, utilizatorul trebuie să definească o colecție pentru aceasta și să se asigure că toate inserările și ștergerile sunt înregistrate în colecție în timp util.

Suport limitat pentru constrângerile de integritate

Nu există mecanisme de declarare a proprietăților cheie ale atributelor (de exemplu, un atribut de clasă nu poate fi declarat ca cheie primară a unei clase), sau constrângeri de unicitate, constrângeri explicite de integritate sau pre- și postcondiții ale metodei. Deși toate acestea pot fi făcute folosind metode, restricțiile explicite ar fi mai ușor de utilizat și ar crea mai putine greseliși ar fi mai accesibil pentru testare și modificare.

Opțiuni limitate de reglare a performanței

Majoritatea OODB-urilor oferă doar mijloace limitate de reglare parametrizată a performanței. În RDB, instalatorilor li se oferă posibilitatea de a personaliza performanța sistemului prin specificarea unui număr mare de parametri care pot fi setați administrator de sistem. Acești parametri includ numărul de memorie tampon, cantitatea de spațiu liber rezervat în pagina de date pentru inserarea viitoare a datelor etc. .

Suport insuficient pentru obiecte complexe

Funcționalitatea completă a obiectelor complexe nu este încă acceptată. Puteți naviga prin linkuri și operați de codificare folosind acele linkuri, dar nu există operații generice predefinite care să utilizeze diferite tipuri de semantică a legăturilor. Se presupune că toate referințele indică obiecte independente, iar semantica relațiilor speciale din cadrul obiectelor complexe este ascunsă în operațiunile furnizate de utilizator.

Integrare limitată cu sistemele de programare orientate pe obiecte

Este dificil să rescrieți programe orientate pe obiecte pentru a gestiona date stabile. Aici apar o serie de probleme: conflicte de nume; necesitatea refacerii ierarhiilor claselor; tendința OODB de a supraîncărca operațiunile sistemului.

Câștig limitat de performanță

Dacă toate aplicațiile de bază de date ar trebui doar să caute obiectele bazei de date prin identificatori de obiect și lucru rapid cu obiectele din memoria principală folosind pointeri, atunci OODB-urile ar depăși de fapt RDB-urile cu două până la trei ordine de mărime. Cu toate acestea, majoritatea aplicațiilor care necesită acces la obiecte prin identificatori necesită, de asemenea, accesul la baza de date și capabilitățile de actualizare oferite de RDB. Aceste caracteristici includ încărcarea în bloc a bazei de date; crearea, actualizarea și ștergerea obiectelor individuale (pe rând); preluarea din clasa a unuia sau mai multor obiecte care satisfac anumite conditii de cautare; conectarea mai multor clase; înregistrarea tranzacțiilor etc. OODB-urile nu oferă niciun avantaj de performanță față de RDB-urile atunci când rulează astfel de aplicații.

Funcțiile care nu sunt încă acceptate în OODB includ, de asemenea, declanșatoare, controale pentru metadate și constrângeri de integritate, cum ar fi UNIQUE și NULL.

***

Din cauza acestor puncte slabe, OODB-urile nu au reușit să se ridice la înălțimea așteptărilor lor: să ofere toate caracteristicile importante dorite de aplicațiile țintă. Aplicabil majorității sisteme moderne Termenul „OOBD” este folosit incorect. Aproape toate OODB-urile moderne nu sunt atât sisteme de baze de date, cât sisteme stabile de stocare a datelor pentru un limbaj de programare orientat pe obiecte. Deci, deși modelul de date orientat pe obiect este în multe privințe mai bogat decât modelul relațional, modelul orientat pe obiect nu și-a atins încă pe deplin maturitatea. Astăzi, în sistemele OOBD există în mod clar mai multe dezavantaje decât avantaje.

Literatură

1. S. Abiteboul, A. Bonner, „Obiecte și vederi”. ACM SIGMOD Int. Conf. Despre managementul datelor, 1991.
2. M. Atkinson și colab., „Manifestul sistemului de baze de date orientat pe obiecte”. Construirea unui sistem de baze de date orientat pe obiecte: Povestea lui O2. Morgan Kaufman, 1992.
3. F. Bancilhon, „Sisteme de baze de date orientate pe obiect”. a VII-a Conf. ACM SIGART/SIGMOD, 1988.
4. J. Banerjee, et al., „Probleme ale modelului de date pentru aplicațiile orientate pe obiect”. ACM Trans. Despre sistemele informaționale de birou, ianuarie 1987.
5. J. Banerjee, W. Kim, K.C. Kim, „Interogări în bazele de date orientate pe obiect”. IEEE Data Engineering Conf., feb. 1988.
6. D. Beech, „Fundația pentru evoluție și baze de date relaționale cu obiecte”. Proc. Tehnologia extinsă a bazelor de date, mar. 1988.
7. E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, „Limbaje de interogare orientate pe obiecte: noțiune și probleme”. Tranzacții IEEE privind ingineria cunoștințelor și a datelor, mar. 1992.
8. A.W. Brown, baze de date orientate pe obiecte, aplicații în inginerie software. New York: McGraw-Hill, 1991.
9. R.G.G. Cattell, Object Data Management, Sisteme de baze de date relaționale și orientate pe obiecte extinse. Addison-Wesley, 1991.
10. M. Cherniack, „Form(ers) over Function(s): KOLA Query Algebra.” Raport tehnic, Universitatea Brown, Dec. 1995.
11. S. Cluet, et al., „Reloop, limbaj de interogare bazat pe algebră pentru un sistem de baze de date orientat pe obiecte”. 1 int. Conf. Despre baze de date deductive și orientate pe obiecte, Dec. 1989.
12. DACĂ. Cruz, DOODLE: Limbajul vizual pentru baze de date orientate pe obiecte. ACM SIGMOD Int. Conf. Despre managementul datelor, 1992.
13. U. Dayal, „Interogări și vederi în modelul de date orientat pe obiecte”. al 2-lea int. Muncă. Despre limbaje de programare a bazelor de date, iunie 1989.
14. K.A. Dittrich, K.R. Dittrich, „Unde SGBD-urile orientate pe obiecte ar trebui să facă mai bine: o critică bazată pe experiențele timpurii.” Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
15. U. Erlingsson, „Object-Qriented Query Optimization”, manuscris nepublicat.
16. L. Fegaras, D. Maier, „Către un calcul eficient pentru limbajele de interogare obiect”. ACM SIGMOD Int. Conf. on Management of Data, San Jose, California, mai 1995.
17. L. Fegaras, D. Maier, T. Sheard, „Specifying Rule-based Query Optimizers in a Reflective Framework.” al 3-lea int. Conf. despre baze de date deductive și orientate pe obiecte, Phoenix, Arizona, Dec. 1993.
18. S. Heiler, S. Zdonik, „Object Views: Extending the vision.” al 6-lea Int. Conf. Despre ingineria datelor, 1990.
19. J.G. Hughes, Baze de date orientate pe obiecte. New York: Prentice-Hall, 1991.
20. S. Khoshafian, „Insight Into Object-Oriented Databases.” Tehnologia informației și software-ului, apr. 1990.
21. S. Khoshafian, Baze de date orientate pe obiecte, New York: John Wiley & Sons, 1993.
22. S. Khoshafian, G. Copeland, „Identitatea obiectului”. 1 int. Conf. Despre sistemele, limbaje și aplicații de programare orientată pe obiecte, oct. 1986.
23. W. Kim, „Fundația pentru baze de date orientate pe obiecte”. MCC Tech. Rep., N. ACA-ST-248-88, aug. 1988.
24. W. Kim, Introducere în bazele de date orientate pe obiecte. MIT Press, 1991.
25. W. Kim, „Sisteme de baze de date orientate pe obiecte: promisiuni, realitate și viitor”. Modern Database Systems: Object Model, Interoperability and Beyond, ACM Press, Addison Wesley, 1995.
26. T.W. Leung, et al., „Aqua Data Model and Algebra”. Raport tehnic CS-93-09, Universitatea Brown, Mar. 1993.
27. G. Mitchell, S.B. Zdonik, U. Dayal, „Optimizarea interogărilor orientate pe obiecte – Care este problema?” Raport tehnic CS-91-41, Universitatea Brown, iunie 1991.
28. E.A. Rudensteiner, „Multiview: Metodologie pentru susținerea mai multor vizualizări în bazele de date orientate pe obiecte”. 18 Int. Conf. Pe baze de date foarte mari, 1992.
29. M. Scholl, H. Schek, „Model de obiect relațional”. al 3-lea int. Conf. Despre teoria bazelor de date, LNCS, voi. 470, Springer Verlag, 1990.
30. P.G. Selinger, et al, „Selectarea căii de acces într-un sistem de gestionare a bazelor de date relaționale”. ACM SIGMOD Int. Conf. Despre managementul datelor, 1979.
31. M. Stefik, D.G. Bobrow, „Programare orientată pe obiecte: teme și variații”. Mag. AI, ian. 1986.
32. M. Stonebraker și colab., „Manifestul sistemului de baze de date din a treia generație”. Comitetul pentru funcția DBMS avansată, Universitatea din California, Berkeley, 1990.
33. D.D. Straube, M.T. Ozsu, „Interogările și procesarea interogărilor în sistemele de baze de date orientate pe obiecte”. Tranzacții ACM pe sistemele informaționale, oct. 1990.
34. D.D. Straube, M.T. Ozsu, „Generarea planului de execuție pentru modelul de date orientat pe obiecte”. al 2-lea int. Conf. despre baze de date deductive și orientate pe obiecte, München, Germania, dec. 1991.
35. S.Y.W. Su, M. Guo, H. Lam, „Association Algebra: Mathematical Foundation for Object-Oriented Databases.” Tranzacții IEEE privind ingineria cunoștințelor și a datelor, oct. 1993.
36. S.B. Zdonik, D. Maier, eds., Readings in Object-Oriented Database Systems, Morgan Kauffman, 1989.
37. S.B. Zdonik, P. Wegner, „Limbajul și metodologia pentru mediile de baze de date orientate pe obiecte”. Hawaii Int. Conf. despre științe de sistem, ian. 1986.

Sikha Bagui([email protected]) este lector la Departamentul de Informatică de la Universitatea din West Florida. Coautor a trei cărți despre baze de date: Learning SQL: A Step-by-Step Guide Using Oracle, Learning SQL: A Step-by-Step Guide Using Access (Addison Wesley) și Database Design Using Entity Relationship Diagrams (CRC Press) .

Tradus din „Realizări și puncte slabe ale bazelor de date orientate pe obiecte” de Sikha Bagui în Journal of Object Technology (JOT), vol. 2, nr. 4, iulie-august 2003, paginile 29-41. Tradus în rusă pentru Otkrytye Systemy cu permisiunea specială a editorului original. Copyright JOT, 2003. Articolul original la http://www.jot.fm/issues/issue_2003_07/column2.

De la editorul de traduceri

OOBD - maturitate sau declin?

Serghei Kuznețov

A existat o pauză remarcabilă în domeniul bazelor de date orientate pe obiect în ultimii ani, pe care unii tind să o perceapă ca declinul tehnologiei, iar alții ca tranziția tehnologiei la o stare matură și stabilă. Conform observațiilor mele, o astfel de pauză duce uneori la apariția unor concepții greșite și chiar mituri în rândul persoanelor apropiate IT, dar care nu sunt specialiști în baze de date. Una dintre aceste concepții greșite este că o persoană ia setul de termeni pe care îi are în cap (obiect, atribut, metodă, clasă, moștenire etc.) pentru un model de date orientat pe obiecte general acceptat.

Aceasta explică decizia noastră de a publica o traducere a unui articol destul de obișnuit al lui Sikha Bagui. O astfel de publicație se justifică cel puțin prin faptul că întrerupe această pauză și arată, în primul rând, că domeniul OOBD nu numai că nu a intrat într-un timp de maturitate, dar continuă să rămână un conglomerat de idei eterogene și confuze care sunt unite la nivelul sloganurilor mai degrabă decât al tehnologiei.

Articolul se bazează pe o analiză a 36 de publicații dedicate bazelor de date orientate pe obiecte și publicate în perioada 1986-1995. Prin urmare, caracteristica des folosită a OODB „modern” nu este în întregime corectă. Citatele, uneori date la timpul prezent, uneori par destul de suspecte.

Desigur, numeroasele surse au folosit o terminologie diferită, iar în acest sens recenzia lor este extrem de variată. În plus, multe dintre articole sunt destul de complexe din punct de vedere tehnic, iar citarea lor fără a furniza context nu face decât să fie mai dificil de înțeles. Cel mai frapant exemplu este subsecțiunea despre dezvoltarea algebrei obiectelor. Primele trei operații „fundamentale” - unire, diferență, selectare - sunt intuitive (deși, în realitate, autorii articolului original au permis o opțiune de eșantionare nu foarte evidentă sub forma unei semi-uniuni), dar ultimele două - generează și harta – sunt operațiuni greu de definit și neevidente.

Aș dori să notez încă o trăsătură ciudată a articolului lui Bagui. Până în 2001, a existat un consorțiu internațional, Object Data Management Group, care a publicat trei versiuni de propuneri de standardizare a modelului de date orientat pe obiecte; cea mai recentă versiune, ODMG 3.0, a fost publicată în 2000. Acesta este singurul document care oferă o terminologie relativ consistentă și, într-o oarecare măsură, un model de date orientat pe obiecte. Păcat că Bagui nu folosește acest material.

Rețineți că revista DBMS a publicat un articol dedicat primei versiuni a standardului, ODMG-93. Scurtă recenzie Standardul ODMG 3.0 poate fi găsit în . De asemenea, vă putem recomanda traducerea Manifestului sistemelor de baze de date orientate pe obiecte și o prezentare foarte frumoasă a tehnologiei OODB.

Literatură

1. Standardul de date obiect: ODMG 3.0. R.G.G. Cattel, D.K. Barry, eds., Morgan Kauffmann, 2000.
2. LA. Kalinichenko, . // DBMS, nr. 1, 1996.
3. S.D. Kuznețov. „Trei manifeste de baze de date: retrospectivă și perspective”. Raport la conferința „Baze de date și tehnologii informaționale ale secolului XXI”, Moscova, septembrie 2003, http://www.citforum.ru/database/articles/manifests.
4. M. Atkinson şi colab., // DBMS, nr. 4, 1995.
5. Ark Andreev, Dmitri Berezkin, Roman Samarev, . // Sisteme deschise, № 3, 2001.

Primul model de date formalizat și general acceptat a fost modelul relațional Codd. În acest model, ca și în toate cele care urmează, s-au distins trei aspecte - structural, holistic și manipulativ. Structurile de date din modelul relațional se bazează pe relații normalizate plate, constrângerile de integritate sunt exprimate folosind logica de ordinul întâi și, în sfârșit, manipularea datelor este efectuată pe baza algebrei relaționale sau a calculului relațional echivalent. După cum notează mulți cercetători, modelul de date relaționale își datorează succesul în mare măsură faptului că s-a bazat pe aparatul matematic riguros al teoriei mulțimilor, relațiilor și logicii de ordinul întâi. Dezvoltatori de orice specific sistem relațional au considerat de datoria lor să arate corespondența modelului lor specific de date cu modelul relațional general, care acționa ca o măsură a „relaționalității” sistemului.

Principalele dificultăți ale modelării datelor orientate pe obiecte provin din faptul că un astfel de aparat matematic dezvoltat pe care s-ar putea baza un model general de date orientat pe obiecte nu există. Acesta este în mare parte motivul pentru care încă nu există un model de bază orientat pe obiecte. Pe de altă parte, unii autori susțin că un model de date general orientat pe obiect în sensul clasic nu poate fi definit deoarece conceptul clasic de model de date este nepotrivit paradigmei orientate pe obiect.

Unul dintre cei mai cunoscuți teoreticieni în domeniul modelelor de date, sugerează Beeri în schiță generală baza formală a OODB, care este departe de a fi completă și nu este un model de date în sensul tradițional, dar permite cercetătorilor și dezvoltatorilor de sisteme OODB să macar vorbesc aceeași limbă (dacă, desigur, propunerile lui Beeri sunt dezvoltate și au primit sprijin). Indiferent de soarta ulterioară a acestor propuneri, considerăm că este util să le relatăm pe scurt.

În primul rând, urmând practica multor OODB-uri, se propune să se distingă două niveluri de modelare a obiectelor: inferior (structural) și superior (comportamental). La nivel structural sunt susținute obiectele complexe, identificarea lor și tipurile de relații „isa”. O bază de date este o colecție de elemente de date legate de o relație „este membru al unei clase” sau „este un atribut”. Astfel, baza de date poate fi considerată ca un grafic direcționat. Un punct important este menținerea conceptului de valoare împreună cu conceptul de obiect (mai târziu vom vedea cât de mult este construit pe acesta într-unul dintre SGBD-urile de succes orientate pe obiecte O2).

Un aspect important este separarea clară a schemei bazei de date și a bazei de date în sine. Conceptele primare ale nivelului circuitului OODB sunt tipurile și clasele. Se observă că în toate sistemele care utilizează un singur concept (fie un tip, fie o clasă), acest concept este inevitabil supraîncărcat: un tip presupune prezența unui anumit set de valori, determinat de structura de date de acest tip; o clasă presupune și prezența multor obiecte, dar acest set este definit de utilizator. Astfel, tipurile și clasele joacă roluri diferite, iar rigoarea și neambiguitatea necesită suport simultan pentru ambele concepte.

Beeri nu prezintă un model formal complet al nivelului structural al OODB, dar își exprimă încrederea că nivelul actual de înțelegere este suficient pentru a oficializa un astfel de model. În ceea ce privește nivelul comportamental, se propune doar o abordare generală a aparatului logic necesar pentru aceasta (logica primului nivel nu este suficientă).

Presupunerea importantă, deși nu bine întemeiată, a lui Beeri este că cele două niveluri tradiționale - schema și datele - nu sunt suficiente pentru OODB. Pentru a defini cu precizie un OODB, este necesar un nivel de meta-schemă, al cărui conținut trebuie să definească tipurile de obiecte și relații permise la nivelul de schemă a bazei de date. Meta-schema ar trebui să joace același rol ca și pentru OODB parte structurală model de date relaționale pentru scheme de baze de date relaționale.

Există multe alte publicații legate de subiectul modelelor de date orientate pe obiecte, dar ele fie ating probleme destul de specifice, fie folosesc aparate matematice care sunt prea serioase pentru această recenzie (de exemplu, unii autori definesc un model de date orientat pe obiecte bazat pe teoria categoriilor).

Pentru a ilustra starea actuală a lucrurilor, vom lua în considerare pe scurt caracteristicile unui model de date specific utilizat în SGBD-ul O2 orientat pe obiecte (desigur, acesta nu este nici un model de date în sensul clasic).

O2 acceptă obiecte și valori. Un obiect este o pereche (identificator, valoare), iar obiectele sunt încapsulate, i.e. valorile lor sunt accesibile numai prin metode - proceduri legate de obiecte. Valorile pot fi atomice sau structurale. Valorile structurale sunt construite din valori sau obiecte reprezentate de identificatorii lor folosind constructori de set, tuplu și listă. Elementele de valoare structurală sunt accesate folosind operații predefinite (primitive).

Există două tipuri posibile de organizare a datelor: clase, ale căror instanțe sunt obiecte care încapsulează date și comportament și tipuri, ale căror instanțe sunt valori. Fiecare clasă este asociată cu un tip care descrie structura instanțelor clasei. Tipurile sunt definite recursiv pe baza unor tipuri atomice și a unor tipuri și clase definite anterior folosind constructori. Latura comportamentală a unei clase este determinată de un set de metode.

Obiectele și valorile pot fi denumite. Denumirea unui obiect sau a unei valori este asociată cu durabilitatea stocării acestuia (persistența): orice obiect sau valoare numită este durabilă; orice obiect sau valoare care face parte dintr-un alt obiect sau valoare numită este durabilă.

Folosind o instrucțiune specială specificată la definirea unei clase, puteți realiza stocarea pe termen lung a oricărui obiect din această clasă. În acest caz, sistemul generează automat o valoare setată al cărei nume se potrivește cu numele clasei. Acest set este garantat să conțină toate obiectele unei clase date.

O metodă este un cod de program legat de o anumită clasă și aplicabil obiectelor acestei clase. Definirea unei metode în O2 se face în doi pași. În primul rând, se declară semnătura metodei, adică. numele, clasa, tipurile sau clasele de argumente ale acestuia și tipul sau clasa de rezultat. Metodele pot fi publice (accesibile din obiecte din alte clase) sau private (accesibile numai în cadrul unei clase date). În a doua etapă, implementarea clasei este determinată într-unul dintre limbajele de programare O2 (limbajele sunt discutate mai detaliat în secțiunea următoare a recenziei noastre).

Modelul O2 acceptă moștenirea mai multor clase bazată pe relația supertip/subtip. O subclasă permite adăugarea și/sau suprascrierea de atribute și metode. Posibilele ambiguități în moștenirea multiplă (în denumirea atributelor și metodelor) sunt rezolvate fie prin redenumire, fie prin indicarea explicită a sursei moștenirii. Un obiect subclasă este un obiect al fiecărei superclase din care este derivată subclasa.

Este acceptată o clasă predefinită „Obiect”, care este rădăcina rețelei de clasă; orice altă clasă este un succesor implicit al clasei „Object” și moștenește metode predefinite („is_same”, „is_value_equal”, etc.).

O caracteristică specifică a modelului O2 este capacitatea de a declara atribute și metode „exclusive” suplimentare pentru obiectele numite. Aceasta înseamnă că un anumit obiect numit reprezentativ al unei clase poate avea un tip care este un subtip al tipului clasei. Desigur, metodele de clasă standard nu funcționează cu astfel de atribute, dar metodele suplimentare (sau standard) pentru care sunt deja disponibile atribute suplimentare pot fi definite special pentru un obiect numit. Se subliniază că atributele și metodele suplimentare sunt legate nu de un obiect specific, ci de un nume, care poate fi, în general, urmat de diferite obiecte în momente diferite. Implementarea atributelor și metodelor exclusive necesită dezvoltarea unor tehnici de legare târzie.

În secțiunea următoare, vom analiza, printre altele, caracteristicile limbajelor de programare și interogările sistemului O2, care, desigur, sunt strâns legate de specificul modelului de date.

Într-un model orientat pe obiecte (OOM), la prezentarea datelor, este posibilă identificarea înregistrărilor individuale ale bazei de date. Relațiile sunt stabilite între înregistrările bazei de date și funcțiile lor de procesare folosind mecanisme similare cu facilitățile corespunzătoare din limbajele de programare orientate pe obiecte.

OOM standard descrise în recomandările standardului ODMG-93 (Object Database Management Group - grup de management al bazelor de date orientat pe obiecte). Nu a fost încă posibilă implementarea completă a recomandărilor ODMG-93. Pentru a ilustra ideile cheie, luați în considerare un model oarecum simplificat al unei baze de date orientate pe obiecte.

Structura unei baze de date orientate pe obiecte poate fi reprezentată grafic ca un arbore, ale cărui noduri sunt obiecte. Proprietățile obiectelor sunt descrise de unii tip standard(de exemplu, un șir) sau un tip construit de utilizator (definit ca o clasă).

Valoarea proprietății tip șir este un șir de caractere. Valoarea unei proprietăți de tip clasă este un obiect care este o instanță a clasei corespunzătoare. Fiecare obiect de instanță al unei clase este considerat un copil al obiectului în care este definit ca proprietate. Un obiect de instanță al unei clase aparține clasei sale și are un părinte. Relațiile generice din baza de date formează o ierarhie conectată de obiecte.

Un exemplu de structură logică a unei baze de date OO de biblioteconomie este prezentat în Fig. 3.14. Aici, un obiect de tip LIBRARY este părintele obiectelor de instanță ale claselor SUBSCRIBER, DIRECTORY și ISSUE. Diferite obiecte de tip BOOK care au același părinte trebuie să difere cel puțin prin numărul de acces (unic pentru fiecare instanță a cărții), dar să aibă aceleași valori de proprietate isbn, udk, titluȘi autor.

Fig.3.14.Structura logică baze de date de biblioteconomie

Structura logică a unei baze de date orientate pe obiect este superficial similară cu structura unei baze de date ierarhice. Principala diferență dintre ele este metodele de manipulare a datelor. Pentru a efectua acțiuni asupra datelor dintr-o bază de date MOO, sunt utilizate operații logice, îmbunătățite de mecanisme orientate pe obiect de încapsulare, moștenire și polimorfism. Operațiuni similare cu comenzile SQL pot fi utilizate într-o măsură limitată (de exemplu, pentru a crea o bază de date).

Crearea și modificarea unei baze de date este însoțită de formarea automată și ajustarea ulterioară a indicilor (tabele de indici) care conțin informații pentru recuperarea rapidă a datelor.

Să luăm în considerare pe scurt conceptele de încapsulare, moștenire și polimorfism în relație cu bazele de date OOM.

Încapsulare limitează domeniul de aplicare al unui nume de proprietate la limitele obiectului în care este definit. Deci, dacă adăugați o proprietate la un obiect de tip DIRECTORY care specifică numărul de telefon al autorului cărții și are numele telefon, apoi vom obține proprietăți cu același nume pentru obiectele SUBSCRIBER și DIRECTORY. Semnificația unei astfel de proprietăți va fi determinată de obiectul în care este încapsulată.

Moştenire, dimpotrivă, extinde sfera proprietății la toți descendenții obiectului. Astfel, tuturor obiectelor de tip BOOK care sunt descendenți ai unui obiect de tip DIRECTORY li se pot atribui proprietățile obiectului părinte: isbn, udk, titluȘi autor. Dacă este necesar să se extindă mecanismul de moștenire la obiecte care nu sunt rude imediate (de exemplu, între doi copii ai aceluiași părinte), atunci o proprietate abstractă de tip abs este definită în strămoșul lor comun. Astfel, definirea proprietăților abstracte biletȘi numărîn obiectul LIBRARY face ca aceste proprietăți să fie moștenite de toate obiectele copil SUBSCRIBER, BOOK și ISSUE. Nu întâmplător valoarea proprietății bilet clasele Abonat și EMITERE prezentate în figură vor fi aceleași - 00015.

Polimorfismîn limbaje de programare orientate pe obiecte înseamnă capacitatea de același lucru codul programului lucrează cu diferite tipuri de date. Cu alte cuvinte, înseamnă că este permis ca obiectele de diferite tipuri să aibă metode (proceduri sau funcții) cu aceleași nume. În timpul execuției unui program obiect, aceleași metode operează pe obiecte diferite în funcție de tipul argumentului. În raport cu baza noastră de date orientată pe obiecte, polimorfismul înseamnă că obiectele din clasa BOOK care au părinți diferiți de clasa DIRECTORY pot avea un set diferit de proprietăți. În consecință, programele de lucru cu obiecte din clasa BOOK pot conține cod polimorf.

Căutarea într-o bază de date orientată pe obiecte constă în aflarea asemănărilor dintre un obiect specificat de utilizator și obiectele stocate în baza de date. Un obiect definit de utilizator, numit obiect obiectiv (proprietatea obiectului este de tip obiectiv), poate fi, în general, un subset al întregii ierarhii de obiecte stocate în baza de date. Obiectul țintă, precum și rezultatul interogării, pot fi stocate în baza de date însăși. În Fig. 3.15.

Principal demnitate OOM de date în comparație cu relaționale este capacitatea de a afișa informații despre relațiile complexe dintre obiecte. OOM de date vă permite să identificați o înregistrare individuală a bazei de date și să determinați funcțiile pentru procesarea acestora.

Dezavantaj OOM-urile se caracterizează prin complexitate conceptuală ridicată, inconvenient de procesare a datelor și viteză scăzută de execuție a interogărilor.

Fig.3.15. Fragment de bază de date cu obiect țintă

Să ne întoarcem din nou la sarcina Comenzi, prezentată sub forma unui model de date relaționale în Fig. 3.8 și luați-o în considerare în termenii unei baze de date orientate pe obiecte. Există trei clase în exemplu: „ Clienții», « Comenzi" Și " Bunuri" Obiecte ale clasei " Clienții» sunt clienți specifici; proprietăți ale clasei - numărul clientului, numele clientului Orașul, statutul etc. Metode de clasă - " Creați o comandă», « Plăti factura" și așa mai departe. O metodă este o operație care poate fi aplicată unui obiect; o metodă este ceea ce ar trebui să facă un obiect. Clasa corespunzătoare tabelului " Comanda Detalii", nu este necesar. Datele din tabel pot face parte din clasa " Comenzi" Disponibilitate in clasa " Clienții"metodă" Creați o comandă„conduce la interacțiunea cu obiectele clasei” Comenzi" Și " Bunuri" În acest caz, utilizatorul nu trebuie să știe despre această interacțiune a obiectelor. Utilizatorul accesează doar obiectul " Comenzi"și folosește metoda" Creați o comandă" Faptul de impact asupra altor baze de date poate fi ascuns utilizatorului. Dacă metoda " Creați o comandă", la rândul său, numește metoda " Verificați bonitatea clientului„, atunci acest fapt poate fi ascuns și utilizatorului. ÎN baze de date relaționale date pentru a îndeplini aceleași funcții necesită proceduri de scriere în limbă Visual Basic pentru aplicație (VBA).

În anii 90, existau prototipuri experimentale ale sistemelor de management al bazelor de date OO. În prezent, astfel de sisteme sunt răspândite. În special, acestea includ următoarele DBMS: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Research and Production Center), precum și Iris , Orion și Postgres.

Noțiuni de bază

Definiția 1

Model orientat pe obiecte prezentarea datelor face posibilă identificarea înregistrărilor individuale ale bazei de date.

Înregistrările bazelor de date și funcțiile lor de procesare sunt legate prin mecanisme similare celor implementate în limbajele de programare orientate pe obiecte.

Definiția 2

Reprezentare grafică Structura unei baze de date orientate pe obiecte este un arbore ale cărui noduri reprezintă obiecte.

Tip standard (de exemplu, șir - şir) sau tipul creat de utilizator ( clasă), descrie proprietățile obiectului.

În Figura 1, obiectul LIBRARY este părintele obiectelor de instanță ale claselor DIRECTORY, SUBSCRIBER și ISSUE. Diferite obiecte de tip CARTE pot avea parinti aceiasi sau diferiti. Obiectele de tip BOOK care au același părinte trebuie să aibă cel puțin numere de acces diferite (unice pentru fiecare instanță de carte), dar aceleași valori de proprietate autor, Nume, udkȘi isbn.

Structurile logice ale unei baze de date orientate pe obiecte și ierarhice sunt superficial similare. Ele diferă în principal prin metodele de manipulare a datelor.

Când se efectuează acțiuni asupra datelor, modelul orientat pe obiecte utilizează operații logice care sunt îmbunătățite prin încapsulare, moștenire și polimorfism. Cu unele limitări, puteți utiliza operațiuni care sunt similare cu comenzile SQL (de exemplu, când creați o bază de date).

La crearea și modificarea unei baze de date, sunt generați automat și ulterior ajustați indici (tabelele de index) care conțin informații pentru căutarea rapidă a datelor.

Definiția 3

Ţintă încapsulare– limitarea domeniului de aplicare a numelui proprietății la limitele obiectului în care este definit.

De exemplu, dacă la obiectul DIRECTORY este adăugată o proprietate care specifică numărul de telefon al autorului și are numele telefon, atunci obiectele DIRECTORY și SUBSCRIBER vor avea aceleași proprietăți. Sensul unei proprietăți este determinat de obiectul în care este încapsulată.

Definiția 4

Moştenire, inversul încapsulării, este responsabil pentru propagarea domeniului unei proprietăți în raport cu toți descendenții obiectului.

De exemplu, tuturor obiectelor BOOK care sunt descendenți ai obiectului DIRECTORY li se pot atribui proprietățile obiectului părinte: autor, Nume, udkȘi isbn.

Dacă este necesar să se extindă mecanismul de moștenire la obiecte care nu sunt rude imediate (de exemplu, la doi descendenți ai unui părinte), o proprietate abstractă de tip este definită în strămoșul lor comun. abs.

Deci proprietățile numărȘi bilet din obiectul LIBRARY sunt moștenite de toate obiectele copil ISSUE, BOOK și SUBSCRIBER. De aceea, valorile acestei proprietăți a claselor SUBSCRIBER și ISUING sunt aceleași - 00015 (Figura 1).

Definiția 5

Polimorfism permite aceluiași cod de program să lucreze cu diferite tipuri de date.

Cu alte cuvinte, permite obiectelor de diferite tipuri să aibă metode (funcții sau proceduri) cu aceleași nume.

Căutareîntr-o bază de date orientată pe obiect este de a determina asemănarea dintre obiectul pe care îl specifică utilizatorul și obiectele care sunt stocate în baza de date.

Avantajele și dezavantajele modelului orientat pe obiecte

Bazele avantaj Un model de date orientat pe obiecte, spre deosebire de un model relațional, este capacitatea de a afișa informații despre relațiile complexe dintre obiecte. Modelul de date luat în considerare ne permite să definim o înregistrare separată a bazei de date și funcțiile pentru procesarea acesteia.

LA neajunsuri Modelul orientat pe obiecte se caracterizează prin complexitate conceptuală ridicată, procesare incomodă a datelor și viteză scăzută de interogare.

Astăzi, astfel de sisteme sunt destul de răspândite. Acestea includ DBMS:

• Postgres,
• Orion,
• Iris,
• ODBJupiter,
• Versant,
• Obiectivitate/DB
• ObjectStore
• Statice,
• Piatră preţioasă
• G-Base.

Model orientat pe obiecte

Într-un model orientat pe obiecte, la prezentarea datelor, este posibilă identificarea înregistrărilor individuale ale bazei de date. Relațiile sunt stabilite între înregistrările bazei de date și funcțiile lor de procesare folosind mecanisme similare cu facilitățile corespunzătoare din limbajele de programare orientate pe obiecte.

Modelul standardizat orientat pe obiecte este descris în recomandările standardului ODMG-93 (Object Database Management Group). Nu a fost încă posibilă implementarea completă a recomandărilor ODMG-93. Pentru a ilustra ideile cheie, luați în considerare un model ușor simplificat al unei baze de date orientate pe obiecte.

Structura unei baze de date orientate pe obiecte (de exemplu, Versant Object Database, Object Store etc.) este reprezentată grafic ca un arbore, ale cărui noduri sunt obiecte. Proprietățile obiectelor sunt descrise de un tip standard (de exemplu, șir) sau un tip construit de utilizator (definit ca clasă).

Valoarea unei proprietăți de tip șir este un șir de caractere. Valoarea unei proprietăți de tip clasă este un obiect care este o instanță a clasei corespunzătoare. Fiecare obiect - o instanță a unei clase este considerat un descendent al obiectului în care este definit ca proprietate. Un obiect este o instanță a unei clase care aparține clasei sale și are un părinte. Relațiile generice din baza de date formează o ierarhie coerentă a obiectelor.

Structura logică a unei baze de date orientate pe obiect este superficial similară cu structura unei baze de date ierarhice. Principala diferență dintre ele este metodele de manipulare a datelor.

Pentru a efectua acțiuni asupra datelor din modelul de bază de date luat în considerare, se folosesc operații logice, îmbunătățite de mecanisme orientate pe obiect de încapsulare, moștenire și polimorfism.

Operațiuni similare cu comenzile SQL pot fi utilizate într-o măsură limitată (de exemplu, pentru a crea o bază de date).

Crearea și modificarea unei baze de date este însoțită de formarea automată și ajustarea ulterioară a indicilor (tabele de indici) care conțin informații pentru recuperarea rapidă a datelor.

Să luăm în considerare pe scurt conceptele de încapsulare, moștenire și polimorfism în relație cu modelul bazei de date orientate pe obiecte.

Încapsularea limitează domeniul de aplicare al unui nume de proprietate la limitele obiectului în care este definit.

Moștenirea, dimpotrivă, extinde sfera unei proprietăți la toți descendenții obiectului.

Polimorfismul în limbajele de programare orientate pe obiect înseamnă capacitatea aceluiași cod de program de a lucra cu diferite tipuri de date. Cu alte cuvinte, înseamnă că este permis ca obiectele de diferite tipuri să aibă metode (proceduri sau funcții) cu aceleași nume. În timpul execuției unui program obiect, aceleași metode operează pe obiecte diferite în funcție de tipul argumentului. Căutarea într-o bază de date orientată pe obiect presupune găsirea de asemănări între un obiect specificat de utilizator și obiectele stocate în baza de date. Un obiect definit de utilizator, numit obiect obiectiv (proprietatea obiectului este de tip obiectiv), poate fi, în general, un subset al întregii ierarhii de obiecte stocate în baza de date. Obiectul țintă, precum și rezultatul interogării, pot fi stocate în baza de date însăși.

Principalul avantaj al unui model de date orientat pe obiecte în comparație cu unul relațional este capacitatea de a afișa informații despre relațiile complexe dintre obiecte. Un model de date orientat pe obiecte vă permite să identificați înregistrările individuale ale bazei de date și să definiți funcții pentru procesarea lor.

Dezavantajele modelului orientat pe obiecte sunt complexitatea conceptuală mare, procesarea incomodă a datelor și viteza scăzută de interogare.

Tipuri de date

Inițial, SGBD-urile au fost folosite în primul rând pentru a rezolva probleme financiare și economice. În acest caz, indiferent de modelul de prezentare, în bazele de date au fost utilizate următoarele tipuri principale de date:

• numeric. Exemple de valori ale datelor: 0,43; 328; 2E+5;
• simbolic (alfanumeric). Exemple de valori de date: „Vineri”, „șir”, „programator”;
• date, specificate folosind tipul special de dată sau ca date de caractere obișnuite. Exemple de valori ale datelor: 12/1/97, 23/2/1999.

În diferite SGBD, aceste tipuri pot diferi ușor unele de altele în ceea ce privește numele, intervalul de valori și tipul de reprezentare. Ulterior, au început să apară sisteme specializate de prelucrare a datelor în noi domenii de aplicare, precum sistemele de geoinformații, procesarea imaginilor video etc. În acest sens, dezvoltatorii au început să introducă noi tipuri de date în SGBD-urile tradiționale. Tipurile de date relativ noi includ următoarele:

• temporare și date-temporale, concepute pentru a stoca informații despre oră și (sau) dată. Exemple de valori de date: 31/01/85 (data), 9:10:03 (ora), 06/03/1960 12:00 (data si ora);
• caractere cu lungime variabilă destinate stocării informații text lungime mare, de exemplu un document;
• binar, conceput pentru stocarea obiectelor grafice, informații audio și video, spațiale, cronologice și altele informatii speciale. De exemplu, în MS Access, acest tip este tipul de date „Field”. obiect OLE„, care vă permite să stocați date grafice în format BMP (Bitmap) în baza de date și să le afișați automat atunci când lucrați cu baza de date;
• hyperlinkuri concepute pentru a stoca link-uri către diverse resurse(noduri, fișiere, documente etc.) situate în afara bazei de date, de exemplu pe Internet, un intranet corporativ sau pe hard diskul unui computer.

ÎN SGBD modern Toate tipurile de date enumerate pot fi utilizate cu diferite modele de date.