În modelul orientat pe obiecte (OOM), la prezentarea datelor, este posibilă identificarea înregistrărilor individuale ale bazei de date. Relațiile se stabilesc între înregistrările bazei de date și funcțiile lor de procesare folosind mecanisme similare celor din limbajele de programare orientate pe obiecte.

OOM standard este descris în recomandările standardului ODMG-93 (Object Database Management Group). Recomandările ODMG-93 nu au fost încă implementate pe deplin. Pentru a ilustra ideile cheie, luați în considerare un model oarecum simplificat al unei baze de date orientate pe obiecte.

Structura bazei de date OO este reprezentată grafic sub forma unui arbore, ale cărui noduri sunt obiecte. Proprietățile obiectelor sunt descrise de un tip standard (de exemplu, un tip șir) sau un tip construit de utilizator (definit ca o 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 instanță a unei clase este considerată un descendent al obiectului în care este definită ca proprietate. Un obiect de instanță al unei clase aparține clasei sale și are un singur părinte. Relațiile generice din baza de date formează o ierarhie a obiectelor înrudite.

Un exemplu de structură logică a OO DB a biblioteconomiei este prezentat în Fig. 3.14. Aici, un obiect de tip LIBRARY este părintele, de exemplu, obiectele claselor SUBSCRIBER, DIRECTORY și OUTPUT. Diferite obiecte de tip CARTE având același părinte trebuie să fie diferite cel puțin în numărul de inventar (unic pentru fiecare exemplar al cărții), dar să aibă aceleași valori de proprietate isbn, udk, numeși autor.

Figura 3.14. Structura logică a bazei de date a bibliotecii

Structura logică a bazei de date OO este similară în exterior cu structura unei baze de date ierarhice. Principala diferență dintre ele constă în metodele de manipulare a datelor. Pentru a efectua acțiuni asupra datelor dintr-o bază de date MOO se folosesc operații logice, întărite 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 bazei de date este însoțită de formarea automată și ajustarea ulterioară a indicilor (tabele de index) 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 restrânge domeniul de aplicare al numelui proprietății la limitele obiectului în care este definit. Deci, dacă adăugați o proprietate la un obiect de tip DIRECTORY care setează 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. Deci, 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, numeși autor. Dacă este necesar să se extindă efectul mecanismului de moștenire la obiecte care nu sunt rude imediate (de exemplu, între doi descendenți ai aceluiași părinte), atunci o proprietate abstractă de tip abs este definită în strămoșul lor comun. Deci, definiția proprietăților abstracte biletși camerăîntr-un obiect LIBRARY face ca aceste proprietăți să fie moștenite de către toate obiectele copil SUBSCRIBER, BOOK și REFERENCE. Nu este o coincidență că valorile proprietății bilet dintre clasele SUBSCRIBER și ISSUE prezentate în figură vor fi aceleași - 00015.

Polimorfismulîn limbaje de programare orientate pe obiecte, înseamnă capacitatea aceluiași cod de program de a lucra cu diferite tipuri de date. Cu alte cuvinte, înseamnă că este posibil să existe metode (proceduri sau funcții) cu aceleași nume în obiecte de diferite tipuri. În timpul execuției unui program obiect, aceleași metode operează pe obiecte diferite în funcție de tipul argumentului. Așa cum este aplicat la OO DB, polimorfismul înseamnă că obiectele clasei BOOK, având 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 în baza de date OO constă în aflarea asemănării dintre obiectul specificat de utilizator și obiectele stocate în baza de date. Un obiect definit de utilizator numit obiect obiectiv (proprietatea obiectului este de tip obiectiv), în cazul general, poate reprezenta un subset al întregii ierarhii de obiecte stocate în baza de date. Obiectul țintă, precum și rezultatul execuției interogării, pot fi stocate în baza de date însăși. În Fig. 3.15.

Principalul demnitate OOM versus datele relaționale este capacitatea de a afișa informații despre relațiile complexe cu obiectele. Datele OOM vă permit să identificați o singură înregistrare a bazei de date și să definiți funcțiile procesării acestora.

Dezavantaj OOM sunt complexitate conceptuală mare, inconveniente în procesarea datelor și viteză scăzută de interogare.

Figura 3.15. Fragment din baza de date cu obiectul ț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 total: " Clienții», « Comenzi" și " Bunuri". Obiecte ale clasei " Clienții»Sunt clienți anumiți; proprietăți ale clasei - nr. client, nume client oraș, statut etc. Metode de clasă - " Creați comanda», « Plătiți factura" etc. O metodă este un fel de 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". Prezenta in clasa " Clienții"Metodă" Creați comanda„Conduce la interacțiunea cu obiectele claselor” Comenzi" și " Bunuri". În acest caz, utilizatorul nu trebuie să știe despre această interacțiune a obiectelor. Utilizatorul se referă doar la obiectul " Comenzi„Și folosește metoda” Creați comanda". Impactul asupra altor baze de date poate fi ascuns utilizatorului. Dacă metoda " Creați comanda", La rândul său, se referă la metodă" Verificați solvabilitatea clientului”, Acest fapt poate fi ascuns și utilizatorului. În bazele de date relaționale, realizarea aceleiași funcționalități necesită scrierea de proceduri în Visual Basic for Application (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 SGBD-uri: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), O2 (Ardent Software), ODB-Jupiter (Inteltek Plus Research and Production Center) și Iris, Orion și Postgres.

Baza de date orientata pe obiecte(OODB) este o bază de date în care datele sunt modelate sub formă de obiecte, atributele, metodele și clasele acestora.

Bazele de date orientate pe obiecte sunt de obicei recomandate pentru acele cazuri în care este necesară procesarea de înaltă performanță a datelor cu o structură complexă.

Manifestul OODB propune caracteristicile cerute pe care trebuie să le îndeplinească orice OODB. Alegerea lor se bazează pe 2 criterii: sistemul trebuie să fie orientat pe obiecte și să fie o bază de date.

Caracteristici obligatorii

1. Suport pentru obiecte complexe. Sistemul ar trebui să ofere posibilitatea de a crea obiecte compuse prin utilizarea constructorilor de obiecte compuse. Constructorii de obiecte trebuie să fie ortogonali, adică orice constructor poate fi aplicat oricărui obiect.

2. Suport pentru individualitatea obiectelor. Toate obiectele trebuie să aibă un identificator unic care nu depinde de valorile atributelor lor.

3. Suport pentru încapsulare. Încapsularea corectă se realizează datorită faptului că programatorii au dreptul de a accesa doar specificația interfeței metodelor, iar datele și implementarea metodelor sunt ascunse în interiorul obiectelor.

4. Suport pentru tipuri și clase. OODB este necesar să sprijine cel puțin un concept de distincție între tipuri și clase. (Termenul „tip” este mai consecvent cu conceptul de tip abstract de date. În limbajele de programare, o variabilă este declarată cu indicarea tipului acesteia. Compilatorul poate folosi aceste informații pentru a verifica operațiunile efectuate asupra variabilei pentru compatibilitatea cu tipul său, care ajută la garantarea corectitudinii software-ului. Pe de altă parte, o clasă este un fel de șablon pentru crearea de obiecte și oferă metode care pot fi aplicate acelor obiecte. Astfel, conceptul de „clasă” este mai mult de un timp de execuție mai degrabă decât un timp de compilare.)

5. Sprijin pentru moștenirea tipurilor și claselor de la strămoșii lor. Un subtip, sau subclasă, trebuie să moștenească atribute și metode din supertipul sau, respectiv, superclasa.

6. Suprasarcină combinată cu legarea completă. Metodele ar trebui aplicate obiectelor de diferite tipuri. Implementarea unei metode trebuie să depindă de tipul de obiecte la care se aplică metoda. Pentru a oferi această funcționalitate, legarea numelor de metode pe sistem nu ar trebui să aibă loc până la momentul execuției programului.

7. Completitudine computațională. Limbajul de manipulare a datelor ar trebui să fie un limbaj de programare de uz general.

8. Setul de tipuri de date trebuie să fie extensibil. Utilizatorul trebuie să aibă mijloacele pentru a crea noi tipuri de date pe baza unui set de tipuri de sistem predefinite. Mai mult, nu ar trebui să existe nicio distincție între modul în care sunt utilizate tipurile de date de sistem și cele definite de utilizator.

OO SGBD

Baze de date orientate obiect- baze de date în care informațiile sunt prezentate sub formă de obiecte, ca în limbajele de programare orientate pe obiecte.

Să aplici sau să nu aplici sisteme de management al bazelor de date orientate pe obiecte (OODBMS) în proiecte reale de astăzi? În ce cazuri ar trebui utilizate și în ce cazuri nu?

Aici Beneficii folosind OODBMS:

· Nu există nicio problemă de nepotrivire între modelul de date din aplicație și baza de date (nepotrivire de impedanță). Toate datele sunt stocate în baza de date în aceeași formă ca și în modelul aplicației.

· Nu este necesar să se suporte separat modelul de date din partea DBMS.

· Toate obiectele la nivelul sursei de date sunt puternic tipizate. Gata cu numele coloanelor șir! Refactorizarea unei baze de date orientate pe obiecte și a codului care funcționează cu aceasta este acum automatizată, mai degrabă decât un proces plictisitor și plictisitor.

Standard ODMG

Primul manifest oficial a fost doar un articol la care i-a fost trimis Conferință despre baze de date orientate pe obiecte și deductive de un grup de indivizi. După cum puteți vedea în subsecțiunea anterioară, cerințele Manifestului au fost mai degrabă emoționale decât specificate în mod explicit. În 1991, s-a format consorțiul ODMG (apoi această abreviere a fost dezvăluită ca Grupul de gestionare a bazelor de date cu obiecte, dar mai târziu a căpătat o interpretare mai largă - Grupul de gestionare a datelor obiect). Consorțiul ODMG este strâns legat de consorțiul mult mai mare OMG ( Grupul de management al obiectelor), care a fost format cu doi ani mai devreme. Scopul inițial principal al ODMG a fost dezvoltarea standardului industrial pentru bazele de date orientate pe obiecte (model comun). Modelul de obiect de bază OMG COM ( Model de obiect de bază). Pe parcursul a mai bine de un deceniu, ODMG a publicat trei versiuni de bază ale standardului, cea mai recentă dintre acestea fiind numită ODMG 3.0. 16

În mod ironic, deși ODMG este (în opinia autorului) în afara OMG, în ultimii ani unele standarde OMG s-au bazat pe modelul obiect ODMG. În special, specificația limbajului OCL ( Limbajul constrângerii obiectului), care face parte din specificația generală a limbajului UML 1.4 (și UML 2.0). În acest articol, nu intenționăm să facem o comparație detaliată a abordărilor OMG și ODMG și să trimitem cititorii interesați la Enciclopediile lui Kogalovskyși materiale de pe site-urile acestor consorții. Ne vom limita la un scurt rezumat al ideilor principale conținute în standardul ODMG-3.

Arhitectura ODMG

Arhitectura ODMG propusă este prezentată în Fig. 2.1. Această arhitectură definește o modalitate de stocare a datelor și diferite tipuri de acces de utilizator la acest „magazin de date” 17. Un singur depozit de date este accesibil dintr-un limbaj de definire a datelor, un limbaj de interogare și un număr de limbaje de manipulare a datelor. 18 În fig. 2.1 ODL înseamnă Limbajul de definire a obiectelor, OQL - Limbajul de interogare obiectși OML - Limbajul de manipulare a obiectelor.

Orez. 2.1. Arhitectura ODMG

Centrul arhitecturii este modelul de date, reprezentând structura organizatorică în care sunt stocate toate datele gestionate de OODBMS. Limbajul de definire a obiectelor, limbajul de interogare și limbajele de manipulare sunt proiectate în așa fel încât toate capabilitățile lor să se bazeze pe modelul de date. Arhitectura permite o varietate de structuri de implementare pentru stocarea datelor modelate, dar o cerință importantă este ca toate bibliotecile software și toate instrumentele de suport să fie furnizate într-un cadru orientat pe obiect și să fie menținute în concordanță cu datele.

Componentele principale ale arhitecturii sunt următoarele.

• Model de date obiect. Toate datele stocate de un OODBMS sunt structurate în termeni de modele de date. Modelul de date definește semantica exactă a tuturor conceptelor (a se vedea mai jos pentru mai multe detalii).

• Limbajul de definire a datelor (ODL). Schemele bazelor de date sunt descrise în termenii limbajului ODL, în care constructele modelului de date sunt instanțiate sub forma unui limbaj de definiție. ODL vă permite să descrieți o schemă ca un set de interfețe tip obiect, care include descrierea proprietăților tipului și relațiile dintre ele, precum și numele operațiilor și parametrii acestora. ODL nu este un limbaj de programare complet; tipurile trebuie să fie implementate într-una dintre limbile din categoria OML. De asemenea, ODL este virtual limbaj în sensul că standardul ODMG nu necesită implementarea acestuia în produsele software OODBMS care sunt considerate a fi conforme cu standardul. Este permis ca aceste produse să accepte limbaje de definiție echivalente care includ toate capacitățile ODL, dar adaptate la specificul unui anumit sistem. Cu toate acestea, prezența specificației limbajului ODL în standardul ODMG este importantă deoarece limbajul specifică proprietățile modelului de date.

• Limbajul de interogare obiect (ODL). Limbajul are o sintaxă similară cu cea a SQL, dar se bazează pe semantica modelului obiect ODMG. Standardul permite utilizarea directă a OQL și încorporarea acestuia într-una dintre limbile din categoria OML.

Model de date relaționale

Aproape toate sistemele moderne se bazează pe relaționale model de management al bazei de date (relaționale). Nume relaționale este legat de faptul că fiecare înregistrare dintr-o astfel de bază de date conține informații referitoare la un singur obiect specific.

V relaționale Toate datele prelucrate în SGBD sunt prezentate sub formă de tabele plate. Informațiile despre obiectele de un anumit tip sunt prezentate sub formă de tabel: diferite atribute ale obiectelor sunt concentrate în coloanele tabelului, iar rândurile sunt destinate să reducă descrierile tuturor atributelor la instanțele individuale ale obiectelor.

Modelul creat în stadiul modelării infologice îndeplinește în cea mai mare măsură principiile relativității. Cu toate acestea, pentru a converti acest model într-un model relațional, trebuie să efectuați o procedură numită normalizare.

Teoria normalizării operează cu cinci forme normale... Aceste formulare sunt concepute pentru a reduce redundanța informațiilor, astfel încât fiecare formular normal ulterior trebuie să îndeplinească cerințele anterioare și unele condiții suplimentare. În proiectarea practică a bazelor de date, formele a patra și a cincea nu sunt utilizate în general. Ne-am limitat să luăm în considerare primele patru forme normale.

Să introducem conceptele necesare înțelegerii procesului de reducere a unui model la o schemă relațională.

Atitudine- abstracția obiectului descris ca un set de proprietăți ale acestuia. În etapa de proiectare infologică, am vorbit despre abstractizarea obiectelor și le-am atribuit unele proprietăți. Acum, cu designul conceptual, trecem la următorul nivel de abstractizare. În această etapă, obiectele, ca atare, nu mai există. Operăm cu un set de proprietăți care definesc obiectul.

Instanță de relație- un set de valori ale proprietăților unui anumit obiect.

Cheia principala- un set identificator de atribute, i.e. valoarea acestor atribute este unică în acest sens. Nu există două instanțe ale unei relații care să conțină aceeași valoare în cheia primară.

Atribut simplu- un atribut ale cărui valori sunt indivizibile.

Atribut complex- un atribut a cărui valoare este un set de valori ale mai multor proprietăți diferite ale unui obiect sau mai multe valori ale unei proprietăți.

Concepte de entitate ..

Domeniu

Domeniul este mai specific bazelor de date, deși are unele analogii cu subtipurile din unele limbaje de programare. În forma sa cea mai generală, un domeniu este definit prin specificarea unui tip de date de bază căruia îi aparțin elementele domeniului și o expresie logică arbitrară aplicată elementului tipului de date. Dacă această expresie booleană este evaluată la adevărat, atunci elementul de date este un articol de domeniu.

Cea mai corectă interpretare intuitivă a noțiunii de domeniu este înțelegerea unui domeniu ca un set potențial admisibil de valori de un anumit tip. De exemplu, domeniul „Nume” din exemplul nostru este definit pe tipul de bază al șirurilor de caractere, dar valorile sale pot include doar acele șiruri care pot reprezenta un nume (în special, astfel de șiruri nu pot începe cu un semn soft).

De asemenea, trebuie remarcată încărcarea semantică a conceptului de domeniu: datele sunt considerate comparabile doar dacă aparțin aceluiași domeniu. În exemplul nostru, valorile pentru domeniile „Numere Gap” și „Numere de grup” sunt de tip întreg, dar nu sunt comparabile. Rețineți că majoritatea SGBD-urilor relaționale nu folosesc conceptul de domeniu, deși Oracle V.7 îl acceptă deja.

Tehnologiile de baze de date bazate pe MD-urile de mai sus se bazează pe un concept static de stocare a informațiilor, axat pe modelarea datelor. Cu toate acestea, noi domenii de aplicare a tehnologiei cu obiecte de baze de date complexe, interconectate, cum ar fi:

Proiectare asistată de calculator;

Productie automatizata;

Dezvoltare automată de software;

Sisteme informatice de birou;

Sisteme multimedia;

Sisteme informatice geografice;

Sisteme de publicare și altele - au demonstrat capacitățile limitate ale conceptului static în ceea ce privește modelarea obiectelor în lumea reală.

Pentru noile tipuri de aplicații complexe de baze de date specializate, este eficient un concept dinamic de stocare a informațiilor, ceea ce face posibilă simularea datelor și proceselor care acționează asupra acestor date în paralel. Acest lucru vă permite să luați în considerare semantica domeniului și, prin urmare, să descrieți cel mai adecvat aceste aplicații. Acest concept se bazează pe abordarea orientată pe obiecte utilizată pe scară largă în dezvoltarea de software. MD care implementează acest concept și se bazează pe paradigma orientată pe obiect (OOP) se numește model de date orientat pe obiect (OOMD).

Construcția OOMD pornește de la presupunerea că domeniul poate fi descris de un set de obiecte. Fiecare obiect este o entitate identificabilă în mod unic care conține atribute care descriu starea obiectelor din „lumea reală” și acțiunile asociate acestora. Starea curentă a unui obiect este descrisă de unul sau mai multe atribute, care pot fi simple sau complexe. Un atribut simplu poate fi de tip primitiv (de exemplu, întreg, șir etc.) și poate lua o valoare literală. Un atribut compus poate conține colecții și/sau link-uri. Un atribut de referință reprezintă o relație între obiecte.

Proprietatea cheie a unui obiect este unicitatea identificării acestuia. Prin urmare, fiecare obiect dintr-un sistem orientat pe obiecte trebuie să aibă propriul său identificator.

Un identificator de obiect (OID) este un mod intern al bazei de date de etichetare a obiectelor individuale. Utilizatorii care lucrează cu programul de dialog pentru setarea interogărilor sau vizualizarea informațiilor, de regulă, nu văd acești identificatori. Ele sunt atribuite și utilizate de către SGBD în sine. Semantica identificatorului din fiecare SGBD este diferită. Poate fi fie o valoare aleatorie, fie conține informații necesare pentru a găsi un obiect în fișierul bazei de date, de exemplu, numărul paginii din fișier și decalajul obiectului de la începutul acestuia. Este identificatorul care ar trebui folosit pentru a organiza referințele la obiect.

Toate obiectele sunt încapsulate, adică reprezentarea sau structura internă a obiectului rămâne ascunsă utilizatorului. În schimb, utilizatorul știe doar că acest obiect poate îndeplini unele funcții. De exemplu, pentru obiectul WAREHOUSE pot fi folosite metode precum ACCEPT_PRODUCT, EXIT_TOBAP etc.. Avantajul încapsulării este că vă permite să schimbați reprezentarea internă a obiectelor fără a relua aplicațiile care folosesc aceste obiecte. Cu alte cuvinte, încapsularea implică independența datelor.

Un obiect încapsulează date și funcții (metode, conform OOP). Metodele definesc comportamentul unui obiect. Ele pot fi folosite pentru a schimba starea unui obiect prin modificarea valorilor atributelor acestuia sau pentru a interoga valorile atributelor selectate. De exemplu, ar putea exista metode pentru adăugarea de informații despre o nouă proprietate închiriată, actualizarea informațiilor despre salariu pentru un angajat sau tipărirea informațiilor despre un anumit articol.

Obiectele care au același set de atribute și răspund la aceleași mesaje pot fi grupate în Clasă(în literatură, termenii „clasă” și „tip” sunt adesea folosiți în mod interschimbabil). Fiecare astfel de clasă are propriul său reprezentant - un obiect, care este un element de date. Obiectele unei anumite clase sunt numite aceasta copii.

În unele sisteme orientate pe obiecte, o clasă este, de asemenea, un obiect și are propriile atribute și metode numite atribute de clasă și metode de clasă.

Conceptele POO importante sunt ierarhia claselor și ierarhia containerelor.

Ierarhia claselor implică posibilitatea ca fiecare clasă, numită în acest caz superclasă, să aibă propria sa subclasă. De exemplu, se poate da următorul lanț: toți programatorii unei întreprinderi sunt angajații acesteia, prin urmare, fiecare programator care este obiect al clasei PROGRAMĂTORI din cadrul OOMD este și un angajat care, la rândul său, este obiect al ANGAJATELOR. clasă. Astfel, PROGRAMTORII vor fi o subclasa, ANGAJATII vor fi o superclasa. Dar programatorii pot fi, de asemenea, împărțiți în sistem și aplicație. Prin urmare, PROGRAMMERS va fi superclasa subclaselor SIS_PROGRAMMERS și APPLICATION_PROGRAMMERS. Continuând acest lanț mai departe, obținem o ierarhie de clasă în care fiecare obiect al subclasei moștenește instanțele de variabile și metode ale superclasei corespunzătoare.

Există mai multe tipuri de moștenire - unică, multiplă și selectivă. Moștenirea unică este un caz în care subclasele moștenesc de la cel mult o superclasă. Moștenire multiplă - moștenire de la mai multe superclase. Moștenirea selectivă permite unei subclase să moștenească un număr limitat de proprietăți din superclasa sa.

Moștenirea instanței variabile este numită moștenirea structurală, mostenire metoda - moștenirea comportamentală, iar capacitatea de a folosi aceeași metodă pentru clase diferite sau, mai degrabă, de a aplica metode diferite cu același nume pentru clase diferite se numește polimorfism.

Arhitectura orientată pe obiecte are și un alt tip de ierarhie - ierarhia containerelor... Constă în faptul că unele obiecte pot fi cuprinse conceptual în altele. Astfel, un obiect al clasei DEPARTAMENT trebuie să conțină variabila publică HEAD, care este o legătură către obiectul clasei SALARIAȚI corespunzător șefului de secție, și trebuie să conțină și o legătură către un set de referințe la obiecte corespunzătoare angajații care lucrează în acest departament.

În unele sisteme orientate pe obiecte, o clasă este, de asemenea, un obiect și are propriile atribute și metode. Caracteristicile generale ale unei clase sunt descrise de atributele sale. Metodele claselor de obiecte sunt oarecum analoge cu proprietățile obiectelor din lumea reală. Fiecare obiect aparținând unei anumite clase are aceste proprietăți. Prin urmare, atunci când creați un obiect, trebuie să declarați clasa căreia îi aparține pentru a defini proprietățile sale inerente în acest fel.

Utilizatorul și obiectul interacționează prin mesaje. Ca răspuns la fiecare mesaj, sistemul execută metoda corespunzătoare.

Toate legăturile din modelul obiect sunt realizate folosind atribute de referință, care sunt de obicei implementate ca OID-uri.

Relațiile dintr-o bază de date relațională sunt reprezentate printr-o mapare a cheilor primare și externe. În baza în sine, nu există structuri pentru formarea de asocieri între tabele, legăturile sunt folosite după cum este necesar la unirea tabelelor. În schimb, relațiile formează coloana vertebrală a unei baze de date orientate pe obiect, deoarece fiecare obiect include identificatorii obiectelor cu care este asociat.

În OOMD pot fi implementate nu numai legăturile tradiționale, ci și legăturile condiționate de moștenire.

Comunicare unu-la-unu (1: 1)între obiectele A și B este implementat prin adăugarea unui atribut de referință la obiectul B la obiectul A și (pentru a menține integritatea referențială) un atribut de referință la obiectul A la obiectul B.

Relație unu-la-mulți (1: M)între obiectele A și B este implementat prin adăugarea la obiectul A a unui atribut de referință la obiectul B și a unui atribut care conține un set de referințe la obiectul A la obiectul B (de exemplu, se adaugă un atribut de referință B (OID2, OID3 ...) la obiectul A și la instanțele de obiect B cu OID2, OID3, ... se adaugă un atribut de referință A: OID1.

Relație multi-la-mulți (M: N)între obiectele A și B se implementează prin adăugarea fiecărui obiect a unui atribut care conține un set de legături.

În OOMD, puteți utiliza o relație întreg-la-parte, care descrie faptul că un obiect dintr-o clasă conține obiecte din alte clase ca părți ale sale. În cazul unei baze de date de producție, ar exista o relație întreg-la-parte între clasa PRODUCT și clasele PART și ASSEMBLY. Această relație este o variantă a unei relații multi-la-mulți cu o semantică specială. O relație întreg-la-parte este implementată ca orice altă relație multi-la-mulți, folosind un set de identificatori de obiect înrudiți. Cu toate acestea, spre deosebire de relația obișnuită multi-la-mulți, are o semnificație semantică diferită.

Deoarece paradigma orientată pe obiect suportă moștenirea, în OOMD este posibil să se utilizeze relația de tip „este” și relația de tip „extends”. Relația is, care este numită și relația generalizare-specializare, generează o ierarhie de moștenire în care subclasele sunt cazuri speciale de superclase. Acest lucru evită descrierea caracteristicilor re-moștenite. Când se utilizează relația „extinde”, subclasa dezvoltă funcționalitatea superclasei, mai degrabă decât să se limiteze la cazul său particular.

Luați în considerare modul în care componente precum constrângerile de integritate și operațiunile asupra datelor sunt implementate în OOMD.

Caracteristicile acestor componente sunt determinate de specificul modelului. Această specificitate în OOMD este dictată în primul rând de conceptele sale interne precum încapsularea obiectelor, adică secretul structurii interne, accesul la date numai prin metode predefinite, ierarhia de clasă și ierarhia containerului.

Specificitatea OOMD este dictată și de specificul obiectului. Se manifestă prin nevoia de a grupa obiectele în clase. Fiecare obiect este inclus într-una sau alta clasă în funcție de sarcină, iar un obiect poate aparține mai multor clase deodată (de exemplu, familiile PROGRAMĂTORI și FOND PÂTITE). O altă caracteristică specifică a unui obiect este că poate „pasa” de la o clasă (subclasă) la alta. Deci un PROGRAMATOR DE SISTEM poate deveni APLICAT în timp. Astfel, ierarhia claselor nu este analogă cu modelul ierarhic, așa cum ar putea părea mai devreme, ci necesită ca sistemul să poată schimba locația fiecărui obiect în ierarhia clasei, de exemplu, să se deplaseze „în sus” sau „în jos” în această ierarhie. Dar este posibil și un proces mai complex - sistemul trebuie să asigure posibilitatea unui obiect de a fi atașat (detașat) la un vârf arbitrar al ierarhiei în orice moment.

Constrângerile de integritate joacă un rol important în OOMD. Pentru ca legăturile dintr-un MD orientat pe obiecte să funcționeze, identificatorii de obiect de pe ambele părți ale legăturii trebuie să se potrivească. De exemplu, dacă există o relație între ANGAJATI și COPII lor, atunci trebuie să existe o anumită asigurare că atunci când un obiect care descrie un copil este inserat într-un obiect care reprezintă un angajat, identificatorul acestuia din urmă este adăugat la obiectul corespunzător. Acest tip de integritate a legăturii, oarecum analogă integrității referențiale într-un model de date relaționale, este stabilită folosind feedback-uri. Pentru a asigura integritatea legăturilor, proiectantului i se oferă o sintaxă specială necesară pentru a specifica locația identificatorului de obiect invers. Responsabilitatea de a stabili constrângeri asupra integrității legăturilor (precum și integrității referențiale într-o bază de date relațională) revine proiectantului.

În OOMD, atât descrierea datelor, cât și manipularea acestora au loc folosind același limbaj procedural orientat pe obiecte.

Grupul ODMG (Object Database Management Groop) se ocupă de problemele standardizării tehnologiei bazelor de date cu obiecte. Ea a dezvoltat un model de obiecte (versiunea ODMG 2.0 a fost adoptată în septembrie 1997) care definește un model standard pentru semantica obiectelor bazei de date. Acest model este important deoarece definește semantica încorporată pe care un SGBD orientat pe obiecte (OODBMS) o înțelege și o poate implementa. Structura bibliotecilor și aplicațiilor care utilizează această semantică ar trebui să fie portabilă între diferitele OODBMS-uri care suportă un anumit obiect MD. Principalele componente ale arhitecturii ODMG sunt Object Model (OM), Object Definition Language (ODL), Object Query Language (OQL) și capacitatea de a se conecta la C++, Java și Smalltalk.

Modelul de date obiect în conformitate cu standardul ODMG 2.0 este caracterizat de următoarele proprietăți:

Elementele de bază sunt obiectele și literalele. Fiecare obiect are un identificator unic. Un literal nu are un identificator propriu și nu poate exista separat ca obiect. Literalele sunt întotdeauna încorporate în obiecte și nu pot fi referite individual;

Obiectele și literalele diferă ca tip. Fiecare tip are propriul său domeniu, partajat de toate obiectele și literalele acelui tip. Tipurile pot avea și comportamente. Dacă un tip are un anumit comportament, atunci toate obiectele de acel tip au același comportament. În practică, un tip poate fi clasa din care este creat obiectul, o interfață sau un tip de date simplu (cum ar fi un număr întreg). Un obiect poate fi gândit ca o instanță a unui tip;

Starea unui obiect este determinată de un set de valori curente implementat de un set de proprietăți. Aceste proprietăți pot fi atribute ale unui obiect sau o relație între un obiect și unul sau mai multe alte obiecte;

Comportamentul unui obiect este determinat de un set de operații care pot fi efectuate asupra unui obiect sau asupra obiectului însuși. Operațiile pot avea o listă de parametri de intrare și de ieșire, fiecare fiind de un tip strict definit. Fiecare operație poate returna, de asemenea, un rezultat tastat;

O definiție a bazei de date este stocată într-o schemă scrisă în Object Definition Language (ODL). Baza de date stochează obiecte astfel încât să poată fi partajate de diferiți utilizatori și aplicații.

SGBD-urile bazate pe OOMD sunt numite SGBD-uri orientate pe obiecte (OODBMS). Aceste SGBD-uri sunt denumite SGBD-uri de a treia generație * (* Istoria dezvoltării modelelor de stocare a datelor este adesea împărțită în trei etape (generații): prima generație (sfârșitul anilor 1960 - începutul anilor 70) - modelele ierarhice și de rețea; a doua generație (cca. 1970-1980) - cea model relațional; a treia generație (anii 1980 - începutul anilor 2000) - modele orientate pe obiecte.).

Astăzi, bazele de date orientate pe obiecte sunt folosite în diverse organizații pentru a rezolva o gamă largă de sarcini. Analiza și generalizarea experienței acumulate în domeniul datelor din tehnologia informației a făcut posibilă identificarea aplicațiilor în care se justifică utilizarea bazelor de date orientate pe obiecte:

Aplicația constă dintr-un număr mare de părți care interacționează. Fiecare dintre ei are propriul său comportament, care depinde de comportamentul celorlalți;

Sistemul trebuie să gestioneze cantități mari de date nestructurate sau complexe;

Aplicația va oferi acces previzibil la date, astfel încât natura navigațională a bazelor de date orientate pe obiecte nu va reprezenta un dezavantaj semnificativ;

Necesitatea cererilor ad-hoc este limitată;

Structura datelor stocate este de natură ierarhică sau similară.

În prezent, pe piața de software există multe SGBD-uri orientate pe obiecte. Masa 10.6 prezintă unele dintre sistemele comerciale din această clasă.

Tabelul 10.6

OODBMS comercial modern,

companiile lor producătoare și domeniile de aplicare

Una dintre diferențele fundamentale dintre bazele de date cu obiecte și bazele de date relaționale este capacitatea de a crea și utiliza noi tipuri de date. O caracteristică importantă a OODBMS este că crearea unui nou tip nu necesită modificarea nucleului de bază și se bazează pe principiile programării orientate pe obiecte.

Nucleul OODBMS este optimizat pentru manipularea obiectelor. Operațiile naturale pentru acesta sunt stocarea în cache a obiectelor, versiunea obiectelor, separarea drepturilor de acces la anumite obiecte. SGBD-urile se caracterizează prin performanțe mai mari la operațiunile care necesită acces și regăsire a datelor împachetate în obiecte, în comparație cu SGBD-urile relaționale, pentru care nevoia de a prelua date conectate duce la operațiuni interne suplimentare.

De mare importanță pentru OODBMS este capacitatea de a muta obiecte dintr-o bază de date în alta.

Atunci când creați diverse aplicații bazate pe OODBMS, structura încorporată a claselor unui anumit SGBD este importantă. Biblioteca de clase acceptă, de regulă, nu numai toate tipurile de date standard, ci și un set extins de multimedia și alte tipuri de date complexe, cum ar fi video, sunet, secvență de cadre de animație. În unele biblioteci de clasă OODBMS au fost create care permit stocarea și căutarea integrală a informațiilor documentare (de exemplu, Jasmine, ODB-Jupiter). Un exemplu de structură de bază de clasă este prezentat în Fig. 10.17.

Poziția principală în ea este ocupată de clasa TOdbObject, care conține toate proprietățile și metodele necesare pentru a controla accesul la baza de date și a efectua indexarea. Toate celelalte clase își suprascriu metodele adăugând o verificare de validare pentru tipul pe care îl implementează și un indexator specific.

După cum se vede din fig. 10.17, există diferite clase în structură axate pe prelucrarea informațiilor documentare - TOdbText, TOdbDocument, TODBTextDocument etc. Fiecare document este reprezentat de un obiect separat. Astfel, se asigură păstrarea naturală a documentelor. Una dintre cele mai importante operațiuni este căutarea documentelor la cerere. Pentru majoritatea claselor, este implementată abilitatea de a căuta obiecte după valoarea unei chei specifice. Pentru clasa TOdbText, este implementată capacitatea de a forma o interogare de căutare pentru o expresie scrisă în limbaj natural.

Clasa TOdbDocument este specială, capabilă să conţină obiecte de diferite tipuri. Este format din câmpuri, fiecare dintre ele având un nume și este asociat cu un obiect de un anumit tip. Prezența acestei clase permite utilizatorului să extindă setul de tipuri. Prin modificarea obiectului container (document), puteți seta un anumit set de câmpuri și astfel obțineți un nou tip de Document.

Pe baza ODB-Jupiter, dezvoltatorii OODBMS au creat un sistem complet de recuperare a informațiilor ODB-Text, care are o structură universală de date stocate și un motor de căutare puternic. Sistemul ODB-Text este un instrument pentru procesarea colectivă a documentelor și menținerea unei arhive corporative. Printre aplicațiile posibile vom numi automatizarea gestiunii documentelor într-un birou modern, construcția de sisteme informaționale de referință (asemănătoare cu binecunoscutele baze de date Legal), întreținerea bazelor de date din rețea, evidențe de personal, bibliografie etc.

41. Caracteristici ale proiectării SI aplicate. Fazele dezvoltării IP. (Tema 11, pp. 100-103).

11.1.3. Caracteristicile proiectării sistemelor IC aplicate

Când construiți (alegeți, adaptați) un sistem informațional, puteți utiliza două concepte principale, două abordări principale (al treilea concept este o combinație a acestora):

1. orientarea către problemele care trebuie rezolvate cu ajutorul acestui sistem informaţional, i.e. abordare orientată pe probleme (sau abordare inductivă);

2. orientarea către tehnologia care este disponibilă (actualizată) într-un anumit sistem, mediu, i.e. abordare orientată către tehnologie (sau abordare deductivă).

Alegerea conceptului depinde de criterii strategice (tactice) și (sau) pe termen lung (pe termen scurt), probleme, resurse.

Dacă la început sunt studiate posibilitățile tehnologiei disponibile, apoi sunt determinate probleme reale care pot fi rezolvate cu ajutorul lor, atunci este necesar să ne bazăm pe o abordare orientată spre tehnologie.

Dacă, mai întâi, sunt identificate probleme reale, iar apoi este introdusă o tehnologie care este suficientă pentru a rezolva aceste probleme, atunci este necesar să se bazeze pe o abordare orientată spre problemă.

În același timp, ambele concepte de construire a unui sistem informațional depind una de alta: introducerea de noi tehnologii modifică problemele care se rezolvă, iar schimbarea problemelor care se rezolvă duce la necesitatea introducerii de noi tehnologii; ambele afectează deciziile luate.

Proiectarea (dezvoltarea) sistemului și utilizarea oricărui sistem informatic aplicat (corporativ) trebuie să treacă prin următorul ciclu de viață al sistemului informațional:

- analiza pre-proiectare (experienta in crearea altor sisteme similare, prototipuri, diferente si caracteristici ale sistemului in curs de dezvoltare etc.), analiza manifestarilor externe ale sistemului;

- analiza intrasistem, analiza interna (analiza subsistemelor de sistem);

- descrierea (prezentarea) sistemică (morfologică) a sistemului (descrierea scopului sistemic, relațiile și conexiunile sistemului cu mediul, alte sisteme și resurse ale sistemului - materiale, energetice, informaționale, organizaționale, umane, spațiale și temporale);

- determinarea criteriilor de adecvare, eficienţă şi stabilitate (fiabilitatea);

- descrierea functionala a subsistemelor sistemului (descrierea modelelor, algoritmi de functionare a subsistemelor);

- prototiparea (descrierea layout-ului) a sistemului, evaluarea interacțiunii subsistemelor sistemului (dezvoltarea unui layout - implementarea subsistemelor cu descrieri funcționale simplificate, proceduri și aprobarea interacțiunii acestor layout-uri pentru a satisface sistemul scop), în timp ce este posibil să se utilizeze „aranjamente” de criterii de adecvare, stabilitate, eficiență;

- „asamblarea” și testarea sistemului - implementarea subsistemelor și criteriilor funcționale cu drepturi depline, evaluarea modelului conform criteriilor formulate;

- functionarea sistemului;

- determinarea obiectivelor pentru dezvoltarea ulterioară a sistemului și a aplicațiilor acestuia;

- mentenanta sistemului - clarificarea, modificarea, extinderea capacitatilor sistemului in modul de functionare a acestuia (in scopul evolutiei acestuia).

Aceste etape sunt fundamentale pentru reingineria sistemelor informatice.

Dezvoltarea unui sistem de informații corporative, de regulă, se realizează pentru o întreprindere foarte specifică. Specificul activității subiectului întreprinderii va influența, fără îndoială, structura sistemului informațional. Dar, în același timp, structurile diferitelor întreprinderi sunt în general similare între ele. Fiecare organizație, indiferent de tipul său de activitate, este formată dintr-un număr de divizii care desfășoară direct unul sau altul tip de activitate a companiei. Și această situație este valabilă pentru aproape toate organizațiile, indiferent de tipul de activitate în care sunt angajate.

Astfel, orice organizație poate fi considerată ca un set de elemente (diviziuni) care interacționează, fiecare dintre ele putând avea propria sa structură destul de complexă. Relațiile dintre departamente sunt și ele destul de complexe. În general, există trei tipuri de legături între diviziile întreprinderii:

Conexiuni funcționale - fiecare departament realizează anumite tipuri de muncă în cadrul unui singur proces de afaceri;

Comunicații informaționale - departamentele fac schimb de informații (documente, faxuri, comenzi scrise și orale etc.);

Relații externe – unele unități interacționează cu sistemele externe, iar interacțiunea lor poate fi, de asemenea, atât informațională, cât și funcțională.

Generalitatea structurii diferitelor întreprinderi ne permite să formulăm câteva principii comune de construire a sistemelor informaționale corporative.

În general, procesul de dezvoltare a unui sistem informațional poate fi considerat din două puncte de vedere:

După timp sau pe etape ale ciclului de viață al sistemului în curs de dezvoltare. În acest caz, se are în vedere organizarea dinamică a procesului de dezvoltare, descrisă în termeni de cicluri, etape, iterații și etape.

Un sistem informatic al întreprinderii este dezvoltat ca un fel de proiect. Multe caracteristici ale fazelor de management al proiectelor și de dezvoltare a proiectelor (fazele ciclului de viață) sunt generale, nu depind nu numai de domeniul subiectului, ci și de natura proiectului (nu contează dacă este un proiect de inginerie sau unul economic) . Prin urmare, este logic să luăm în considerare mai întâi o serie de probleme generale de management de proiect.

Un proiect este o schimbare limitată în timp, intenționată a unui sistem separat, cu obiective inițial clar definite, a căror realizare determină finalizarea proiectului, precum și cu cerințele stabilite pentru termene, rezultate, risc, sfera de cheltuire a fondurilor și resurse și pentru structura organizatorică.

De obicei, pentru un concept complex (care, în special, este conceptul de proiect) este dificil să se ofere o formulare lipsită de ambiguitate care să acopere pe deplin toate trăsăturile conceptului introdus. Prin urmare, definiția dată nu pretinde a fi unică și completă.

Se pot distinge următoarele caracteristici distinctive principale ale proiectului ca obiect de management:

Variabilitatea este un transfer intenționat al unui sistem de la unul existent la un anumit

starea dorită, descrisă din punct de vedere al obiectivelor proiectului;

Limitarea scopului final;

Durată limitată;

Buget limitat;

Resurse limitate necesare;

Noutate pentru intreprinderea pentru care se implementeaza proiectul;

Complexitate - prezența unui număr mare de factori care afectează direct sau indirect progresul și rezultatele proiectului;

Suport juridic și organizatoric - crearea unei structuri organizatorice specifice pe durata proiectului.

Eficiența muncii se realizează prin gestionarea procesului de implementare a proiectului, care asigură alocarea resurselor, coordonarea succesiunii de lucru și compensarea influențelor perturbatoare interne și externe.

Din punctul de vedere al teoriei sistemelor de control, proiectul ca obiect de control trebuie să fie observabil și controlabil, adică se disting unele caracteristici prin care este posibilă monitorizarea constantă a progresului proiectului (proprietatea observabilității) . În plus, sunt necesare mecanisme de influență în timp util asupra cursului implementării proiectului (proprietatea controlabilității).

Proprietatea controlabilității este deosebit de importantă în condiții de incertitudine și variabilitate a domeniului subiectului, care însoțesc adesea proiectele de dezvoltare a sistemelor informaționale.

Fiecare proiect, indiferent de complexitatea și cantitatea de muncă necesară implementării lui, trece prin anumite stări în dezvoltarea sa: de la o stare în care „proiectul nu este încă” la o stare în care „proiectul nu mai este acolo”. Setul de etape de dezvoltare de la apariția unei idei până la finalizarea completă a proiectului este de obicei împărțit în faze (etape, etape).

Există unele diferențe în determinarea numărului de faze și a conținutului acestora, deoarece aceste caracteristici depind în mare măsură de condițiile de implementare a unui anumit proiect și de experiența principalilor participanți. Cu toate acestea, logica și conținutul principal al procesului de dezvoltare a sistemului informațional sunt în aproape toate cazurile aceleași.

Se pot distinge următoarele faze ale dezvoltării sistemului informațional:

Formarea conceptului;

Elaborarea specificațiilor tehnice;

Proiecta;

De fabricație;

Punerea în funcțiune a sistemului.

Să luăm în considerare fiecare dintre ele mai detaliat. Faza a doua și parțial a treia sunt de obicei numite faze de proiectare a sistemelor, iar ultimele două (uneori aceasta include faza de proiectare) - fazele de implementare.

Faza conceptuală

Formarea ideilor, stabilirea obiectivelor;

Formarea unei echipe cheie de proiect;

Studierea motivației și cerințelor clientului și a altor participanți;

Colectarea datelor de referință și analiza stării existente;

Determinarea cerințelor și restricțiilor de bază, a resurselor materiale, financiare și de muncă necesare;

Evaluarea comparativă a alternativelor;

Depunerea propunerilor, examinarea și aprobarea acestora.

Elaborarea unei propuneri tehnice

Dezvoltarea conținutului principal al proiectului, a structurii de bază a proiectului;

Elaborarea și aprobarea specificațiilor tehnice;

Planificarea, descompunerea modelului structural de bază al proiectului;

Estimarea si bugetarea proiectului, determinarea necesarului de resurse;

Elaborarea programelor și a programelor de lucru extinse;

Semnarea unui contract cu un client;

Punerea în funcțiune a mijloacelor de comunicare a participanților la proiect și controlul derulării lucrărilor.

Proiecta

În această fază se determină subsistemele, interrelațiile dintre ele și se selectează cele mai eficiente modalități de execuție a proiectului și de utilizare a resurselor. Lucrări tipice ale acestei faze:

Lucrări de bază de proiectare;

Elaborarea specificațiilor tehnice private;

Design conceptual;

Întocmirea specificațiilor tehnice și a instrucțiunilor;

Prezentarea designului, expertiza și aprobarea.

Dezvoltare a

În această fază se realizează coordonarea și controlul operațional al lucrărilor de proiect, se fabrică, se combină și se testează subsistemele. Conținut principal:

Implementarea lucrărilor de dezvoltare software;

Pregatirea pentru implementarea sistemului;

Controlul si reglementarea principalilor indicatori ai proiectului.

Punerea în funcțiune a sistemului

În această fază se efectuează teste, testează funcționarea sistemului în condiții reale, se poartă negocieri asupra rezultatelor proiectului și asupra eventualelor noi contracte. Principalele tipuri de munca:

Teste complexe;

42. Conceptul de ciclu de viață al PI. (Tema 11, pp. 103-105).

Introducere

Apariția direcției bazelor de date orientate pe obiect (OODB) a fost determinată, în primul rând, de nevoile practicii: necesitatea dezvoltării unor sisteme de aplicații informaționale complexe pentru care tehnologia sistemelor anterioare de baze de date nu era pe deplin satisfăcătoare. Desigur, OODB nu a apărut de nicăieri. Baza corespunzătoare a fost oferită atât de lucrările anterioare din domeniul bazelor de date, cât și de domeniile în lungă dezvoltare ale limbajelor de programare cu tipuri de date abstracte și limbaje de programare orientate pe obiecte.

În ceea ce privește relația cu lucrările anterioare din domeniul bazelor de date, cea mai puternică influență asupra muncii din domeniul OODB a fost dezvoltarea SGBD și următoarea familie de baze de date cronologice, în care a fost susținută gestionarea obiectelor complexe. Aceste activități au oferit baza structurală pentru organizarea OOBD. În acest rezumat, vor fi luate în considerare OOMD și OODBMS.

Model de date orientat pe obiecte

Luați în considerare una dintre abordările pentru construirea unei baze de date - folosind un model de date orientat pe obiecte (OOMD). Modelarea datelor în OOMD se bazează pe conceptul de obiect. ODM este de obicei utilizat în domenii complexe, cărora le lipsește funcționalitatea modelului relațional pentru modelare (de exemplu, pentru sisteme de automatizare a proiectării (CAD), sisteme de publicare etc.).

Modelul de date orientat pe obiecte ODMG diferă de alte modele, în primul rând, într-un aspect fundamental. În modelul de date SQL și modelul de date relaționale adevărate, o bază de date este o colecție de containere de date denumite de același tip generic: tabele sau, respectiv, relații. În modelul de date orientat pe obiecte, o bază de date este o colecție de obiecte (containere de date) de tip arbitrar.

La crearea SGBD orientat pe obiecte (OODBMS), sunt utilizate diferite metode, și anume:

încorporarea în limbajul orientat obiect a mijloacelor destinate lucrului cu o bază de date;

extinderea limbajului existent pentru lucrul cu baze de date cu funcții orientate obiect;

crearea de biblioteci orientate pe obiecte de funcții pentru lucrul cu o bază de date;

crearea unui nou limbaj și a unui nou model de date orientat pe obiecte.

Avantajele OOMD includ oportunități ample de modelare a domeniului, limbaj de interogare expresiv și performanță ridicată. Fiecare obiect din OOMD are un identificator unic (OID - identificator de obiect). Recuperarea OID este semnificativ mai rapidă decât căutările în tabele relaționale.

Printre dezavantajele OOMD, trebuie remarcate lipsa unui model general acceptat, lipsa experienței în crearea și funcționarea OODB, complexitatea utilizării și mijloacele insuficiente de protecție a datelor.

Acum să vedem cum este implementat suportul pentru modelele de date în sistemele reale de management al bazelor de date.

În modelul orientat pe obiecte (OOM), la prezentarea datelor, este posibilă identificarea înregistrărilor individuale ale bazei de date. Relațiile se stabilesc între înregistrările bazei de date și funcțiile lor de procesare folosind mecanisme similare celor din limbajele de programare orientate pe obiecte.

OOM standard este descris în recomandările standardului ODMG-93 (Object Database Management Group). Recomandările ODMG-93 nu au fost încă implementate pe deplin. Pentru a ilustra ideile cheie, luați în considerare un model oarecum simplificat al unei baze de date orientate pe obiecte.

Structura bazei de date OO este reprezentată grafic sub forma unui arbore, ale cărui noduri sunt obiecte. Proprietățile obiectelor sunt descrise de un tip standard (de exemplu, un tip șir) sau un tip construit de utilizator (definit ca o 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 instanță a unei clase este considerată un descendent al obiectului în care este definită ca proprietate. Un obiect de instanță al unei clase aparține clasei sale și are un singur părinte. Relațiile generice din baza de date formează o ierarhie a obiectelor înrudite.

Primul model de date formalizat și general acceptat a fost modelul relațional al lui 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 se bazează pe algebra relațională sau pe calculul relațional echivalent al acesteia. După cum notează mulți cercetători, modelul de date relaționale își datorează în mare parte succesul faptului că s-a bazat pe aparatul matematic riguros al teoriei mulțimilor, relațiilor și logicii de ordinul întâi. Proiectanții oricărui sistem relațional anume au simțit că este de datoria lor să arate că modelul lor particular de date corespunde modelului relațional general, care a acționat ca o măsură a „relaționalității” sistemului.

Principalele dificultăți ale modelării datelor orientate pe obiecte provin din faptul că nu există un astfel de aparat matematic dezvoltat pe care să se poată baza un model general de date orientat pe obiecte. În mare măsură, așadar, încă nu există un model de bază orientat pe obiecte. Pe de altă parte, unii autori susțin că modelul general de date orientat pe obiect în sensul clasic nu poate fi definit din cauza inadecvării conceptului clasic de model de date față de paradigma orientată pe obiect.

Unul dintre cei mai renumiți teoreticieni ai modelelor de date, Beeri, oferă o schiță a unui cadru formal pentru OODB, care este departe de a fi complet și nu este un model de date în sensul tradițional, dar le permite cercetătorilor și dezvoltatorilor de sisteme OODB să vorbească cel puțin una. limbaj (cu excepția cazului în care, desigur, propozițiile Beeri vor fi dezvoltate și susținute). Indiferent de soarta ulterioară a acestor propuneri, considerăm că este util să le rezumă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 suportate obiectele complexe, identificarea lor si tipurile de comunicare „isa”. O bază de date este o colecție de elemente de date legate prin relația „este într-o clasă” sau „este un atribut”. Astfel, DB poate fi considerat ca un grafic direcționat. Un punct important este menținerea, alături de conceptul de obiect, a conceptului de semnificație (mai târziu vom vedea cât de mult se construiește pe acesta într-unul dintre DBMS orientat pe obiecte de succes O2).

Un aspect important este o separare clară a schemei bazei de date și a bazei de date în sine. Conceptele primare ale nivelului de schemă 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, de asemenea, un set de obiecte, dar acest set este definit de utilizator. Astfel, tipurile și clasele joacă roluri diferite, iar pentru rigoare și lipsă de ambiguitate este necesar să se susțină ambele concepte în același timp.

Beeri nu prezintă un model formal complet al nivelului structural 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ă).

O presupunere importantă, deși insuficient fundamentată, a lui Beeri este că cele două straturi 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ă determine tipurile de obiecte și relații care sunt permise la nivelul schemei bazei de date. Meta-schema ar trebui să joace același rol pentru OODB-uri ca și partea structurală a modelului de date relaționale pentru schemele bazelor de date relaționale.

Există multe alte publicații legate de subiectul modelelor de date orientate pe obiecte, dar acestea fie ating probleme destul de specifice, fie folosesc un aparat matematic prea serios pentru această recenzie (de exemplu, unii autori definesc un model de date orientat pe obiecte). pe baza teoriei categoriilor).

Pentru a ilustra starea actuală a lucrurilor, vom lua în considerare pe scurt caracteristicile unui model de date specific utilizat în SGBD-ul orientat pe obiecte O2 (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ă. Membrii valorii structurale sunt accesibili folosind operații predefinite (primitive).

Există două moduri de organizare a datelor: clase, care sunt instanțiate de 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 din tipuri atomice și 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 persistența acestuia: orice obiect sau valoare numită este persistentă; orice obiect sau valoare care face parte dintr-un alt obiect sau valoare numită este durabilă.

Cu ajutorul unei instrucțiuni speciale date 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 este același cu numele clasei. Se garantează că acest set conține toate obiectele din această clasă.

Metodă - cod de program asociat cu o anumită clasă și aplicabil obiectelor acestei clase. Determinarea metodei în O2 se realizează în două etape. Î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 obiectele altor clase) sau private (accesibile numai în cadrul acestei clase). În a doua etapă, se determină implementarea clasei într-unul dintre limbajele de programare O2 (limbile sunt discutate mai detaliat în următoarea secțiune a recenziei noastre).

Modelul O2 acceptă moștenirea mai multor clase bazată pe relația supertip/subtip. Subclasei i se permite să adauge și/sau să suprascrie atribute și metode. Ambiguitățile posibile cu moștenirea multiplă (în denumirea atributelor și metodelor) sunt rezolvate fie prin redenumire, fie prin specificarea explicită a sursei moștenirii. Un obiect subclasă este un obiect al fiecărei superclase din care este derivată subclasa.

Este acceptată clasa predefinită „Obiect”, care este rădăcina rețelei de clasă; orice altă clasă este un moștenitor implicit al clasei „Object” și moștenește metodele 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 reprezentativ numit 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 metode suplimentare (sau standard) pot fi definite special pentru un obiect numit, pentru care sunt deja disponibile atribute suplimentare. Se subliniază că atributele și metodele suplimentare sunt atașate nu unui obiect anume, ci unui nume, în spatele căruia, în general, pot sta diferite obiecte în momente diferite. Dezvoltarea tehnicilor de legare tardivă este necesară pentru a implementa atribute și metode exclusive.

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