Capitol 7

Capitol 7

Baze de date orientate obiect

Capitol 7

Baze de date orientate obiect (BDOO)7.1. Conceptul de BDOO

Pentru definirea unei BDOO vom pleca tot de la definirea unei baze de date la modul general, i anume:

O baz de date orientat obiect este format dintr-una sau mai multe clase de obiecte cu asocierile dintre acestea.

Ca i n alte tipuri de baze de date, o BDOO dispune de o schem i instane ale acestuia.

Schema BDOO conine specificaiile fiecrei clase de obiecte ce pot fi stocate n baza de date. Pentru fiecare clas C, aceasta include:

tipul asociat clasei C. Acest tip determin structura fiecrui obiect al clasei C; semntura metodelor din cadrul clasei C, care precizeaz denumirea metodei, tipul i ordinea argumentelor permise metodei i tipul rezultatului oferit de acea metod; relaiile subclaselor care permit identificarea superclasei a lui C; restriciile de integritate i restriciile refereniale, sau mai mult afirmaii generale care sunt similare constrngerilor din modelul bazelor de date relaionale.

O instan a unei BDOO este un set de obiecte pentru multitudinea claselor specificate n cadrul schemei bazei de date.

7.2. Premisele BDOO

Utilizarea conceptului de obiect n informatic dateaz din jurul anilor 1960, cnd au fost elaborate primele Limbaje de programare orientate obiect, dintre care amintim: Simula, EIFFEL, SmallTalk, Ada, C, C++, Common LISP, CLOS, OPAL, O2C, O2SQL, O2API, SQL++, ACTOR, Object Pascal etc.

De remarcat, faptul c aceste limbaje de programare nu i-au gsit o larg utilizare pentru aplicaii ce lucreaz cu volume mari de date datorit faptului c nc nu existau metode corespunztoare de organizare a datelor. O astfel de problem a fost rezolvat n jurul anilor 1980 cnd au aprut primele sisteme de gestionare a bazelor de date orientate obiect (SGBDOO) cum ar fi: ONTOS, ObjectStore, O2, GemStore, ORION, ITASCA, Objectivity/DB, VERSANT, POET etc. Nici n astfel de mprejurri, abordarea obiectual a sistemelor de gestiune a bazelor de date nu i-au gsit o utilizare extins pentru aplicaii complexe sau pentru cele ce implicau volume mari de date. Acest lucru s-a datorat faptului c nc nu existau Metode, tehnici i metodologii de analiz i proiectare orientate obiect a sistemelor informatice. Acestea au aprut n jurul anilor 1990 i dintre ele enumerm:

Object Oriented Design (OOD), elaborat de Grady Booch, este o metodologie similar metodologiei OMT, dezvolt aceeai idee analiza i proiectare iterativ insistnd asupra prii de proiectare [BDOOC94];

Object Oriented Analysis (OOA) elaborat de Peter Coad i Edward Yourdon;

Object Oriented Structured Design (OOSD) elaborat de Wasserman;

Object Oriented System Analysis (OOSA) este o metodologie de proiectare a sistemelor n timp real propus de Sally Shaler i Steven Mellor. Autorii au continuat s mbunteasc aceast metodologie, publicnd chiar i o lucrare despre cum se pot utiliza notaiile UML n cadrul metologiei Shaler/Mellor;

Responsability Driven Design (RDD), aparinnd lui Wirfs - Brock, Wilkesson i Wienner;

Object Oriented Role Analysis, Synthesis and Structuring aparinnd lui Reens Kaugh;

Object Oriented Systems Analysis (OOSA) aparinnd lui Embley;

Object Modeling Techinque (OMT) elaborat de James Rumbaugh, Michael Blaha i alii, prezentat n lucrarea [RUMB94]. Metodologia a fost iniial utilizat de General Electric and Development Center;

Object Oriented Software Engineering (OOSE) conceput de Ivar Jacobson.

n plus, multe organizaii i-au dezvoltat propria metodologie intern, utiliznd diagrame i tehnici din diverse surse. Exemple de astfel de metodologii sunt Catalyst creat de Computer Sciences Corporation (CSC) i Worldwide Solution Design and Delivery Method (WSDDM), creat de IBM. Aceste metodologii difer, dar n general combin analiza fluxurilor, identificarea cerinelor, modelarea proceselor de afaceri i modelarea obiectual utiliznd diverse notaii (OMT, Booch etc.) i uneori includ tehnici adiionale specifice modelrii orientate obiect, cum ar fi fiele CRC sau cazurile de utilizare.

Toate aceste metodologii prezentau o serie de limite precum i multiple diferenieri de simboluri, notaii sau tipuri de diagrame. Aceste aspecte generau dificulti n privina nelegerii, prelurii i folosirii lor de diferite grupuri de utilizatori, n crearea de noi sisteme sau n procesul de mentenan a sistemelor. Mare parte dintre aceste deosebiri au fost nlturate n 1997 prin elaborarea unui standard cu privire la simboluri, notaii, tipuri de diagrame, tipuri de modele etc., numit UML (Unified Modeling Language).

Majoritatea corporaiilor au adoptat UML ca notaii pentru propria lor metodologie. Unii utilizeaz doar un subset al UML-ului pentru a modela ceea ce i intereseaz, de exemplu, doar diagrama claselor sau doar cazurile de utilizare. Alii au preluat ntreg setul UML, utiliznd inclusiv diagramele de stare i de activitate pentru a modela sisteme n timp real i diagrama de implementare pentru a modela sisteme distribuite.

Dintre premisele ce au dus la abordarea obiectual, n general, a analizei i proiectrii sistemelor informatice i n special, a bazelor de date orientate obiect, enumerm:

limitele abordrii structurate n analiza i proiectarea sistemelor informatice (bazele de date fcnd parte dintr-o disciplin mai larg i anume sisteme informatice);

limitele modelului relaional de organizare a datelor;

schimbrile n ceea ce privete orientarea aplicaiilor ce puneau accent pe stocarea datelor, spre aplicaii care pun accent pe prelucrarea mai eficient a datelor cu algoritmi mai performani; succesele dobndite de ctre sistemele expert sub aspectul stocrii cunotinelor; progresele dobndite n domeniul instrumentelor de tip CASE; multiplele avantaje oferite de limbajele de programare orientate obiect, dintre care precizm: facilitile de refolosire a codului, modularitate crescut i extensibilitate sporit; apariia unor noi tipuri de aplicaii, cu cerine i particulariti specifice, pentru care sistemele de gestiune a bazelor de date relaionale (SGBDR) s-au dovedit inadecvate. Dintre acestea enumerm: proiectarea asistat de calculator (CAD Computer Aided Design), aplicaii din domeniul meteorologiei, sisteme informaionale geografice (GIS Geographic Information Systems), ingineria programrii asistate de calculator (CASE Computer Aided Software Engineering), sisteme informaionale de birou (OIS Office Information Systems), aplicaii multimedia n cinematografie i televiziune, extinderea aplicaiilor informaticii n domeniul medicinei, cercetrii tiinifice etc. Toate aceste tipuri de aplicaii presupun preluri, stocri, regsiri i prelucrri de evenimente, tranziii, stri, imagine/poz, voce/sunet, culoare, animaie etc., care la rndul lor presupun utilizarea i manipularea unor noi tipuri de date pe lng cele tradiionale (primitive), dintre care amintim:

tipuri de date abstracte (ADTs) definite de utilizator,

tipuri structurate,

tipuri de obiecte mari (LOB Large Object) cu cele dou variante numite BLOB (Binary Large Object) i respectiv CLOB (Character Large Object).

Astfel de noi tipuri de date pot fi regsite i tratate n cadrul acestui capitol i chiar n urmtoarele capitole.

7.3. Avantajele i dezavantajele BDOO

Ca orice alt mod de organizare a datelor i BDOO prezint avantaje i dezavantaje. n cele ce urmeaz vom recurge la evidenierea celor dou aspecte:

Avantajele BDOO. ntr-o form sintetic, avantajele BDOO ar putea fi enunate astfel:

Ofer faciliti cu privire la extensibilitatea bazei de date. Extensibilitatea apare ca un avantaj cheie a BDOO deoarece tipurile de date pot fi extinse folosind proprietatea de motenire. Se pot aduga noi subtipuri fr a fi necesar restructurarea poriunilor existente ale bazei de date. Aa dup cum s-a mai artat, n acest mod activitatea de programare se transform ntr-o activitate de programare doar a diferenelor, sporind productivitatea muncii. Se are n atenie valorificarea proprietii de motenire prin definirea, sau prin generalizarea, de superclase de obiecte cu includerea n aceasta a tot ceea ce este comun, iar apoi partajarea acestora n subclase de obiecte n care vor fi precizate doar elementele prin care se difereniaz fiecare subclas de celelalte subclase de obiecte. Efectele benefice rezultate dintr-o astfel de abordare constau n reutilizarea codului, reducerea redundanei datelor din baza de date, ntreinerea facil a bazei de date, uurin n dezvoltarea i implementarea de noi aplicaii etc.

Reflect mai bine realitile din mediul nconjurtor. Lumea real nu este format dintr-o colecie de tabele, ci un model a lumii reale apare ca o ierarhie de ansambluri concretizate n articole de prelucrat. Aici o parte e descompus n prile ei constituente ca subpri, care la rndul lor sunt descompuse n alte subpri mai mici. Astfel de structuri sunt greu de reprezentat i manipulat utiliznd tabele. De fapt prin folosirea unui SQL standard, toate subprile unei pri date nu pot fi determinate tipic cu o singur instruciune de cereri. n contrast, o baz de date orientat obiect suport capacitatea obiectelor de a se referi direct unele la altele ct i facilitatea de calcul a limbajelor orientate obiect de a procesa obiecte.

Totodat, un model de ntreprindere ar trebui s fie un model ce descrie tipuri de obiecte, de afaceri, subtipuri, comportarea lor, relaiile dintre obiecte, strile obiectelor, evenimentele ce determin schimbrile de stri, reguli de afaceri etc. Modelul ntreprinderii trebuie translatat direct n software care face ca ntreprinderea s funcioneze. O astfel de situaie necesit baze de date care stocheaz obiecte i fac metodele asociate s fie operative.

BDOO permit obiectelor s se refere direct unele la altele pe baz de pointeri. O astfel de adresare (referire) face BDOO mai rapide n a ajunge de la obiectul X la Y dect bazele de date relaionale, care trebuie s foloseasc un operator de JOIN pentru a realiza acest lucru. Chiar un JOIN optimizat e tipic mai ncet dect o referire direct la obiect pe baz de pointeri.

BDOO ofer performane sporite referitoare la clasterarea (cluster) fizic a datelor. Majoritatea sistemelor de baze de date permit proiectantului s plaseze structurile legate aproape una de alta pe suportul de memorie extern. Prin clasterare se urmrete sporirea vitezei de rspuns la cererile utilizatorilor ce implic operaia de jonciune a unor structuri de date. Se reduce astfel n mod considerabil timpul de regsire pentru datele solicitate, prin reducerea numrului de accese pentru citirea datelor de pe harddisc. Exemplu, pentru a da rspuns facil la o cerere de aplicaie de forma: care sunt subpri la componente ale unui produs oarecare sau care sunt salariaii unei societi comerciale ce lucreaz ntr-un anumit departament?

n astfel de situaii proiectanii recurg la definirea de clastere (Clusters). n condiiile BDOO clasterarea fizic se realizeaz la un singur nivel, de unde rezult i performanele sporite sub aspectul timpului de regsire. Logica de clasterare se bazeaz pe clase i ierarhii de agregare. Obiectele care formeaz grupe sunt stocate laolalt cu obiectele compozite i ntr-un sistem bine proiectat, structurile de clasificare sunt folosite ca baz natural de clasterizare. Pe cnd, n condiiile BDR se impune un al doilea nivel de claster. Un prim nivel pentru a grupa tuplurile reprezentnd obiectele individuale i un al doilea pentru grupurile de tupluri reprezentnd obiectele referite.

BDOO sporesc extinderea domeniilor de aplicabilitate prin posibilitatea folosirii diverselor structuri de stocare i prelucrare a datelor. ntr-o baz de date relaional, datele care nu pot fi exprimate n form tabelar sunt dificil de stocat i accesat eficient. Ori, exist o multitudine de aplicaii care implic date complexe, sunet, imagini, text neformatat etc. Modul de stocare pentru BDOO este nelimitat, din moment ce sistemul este extensibil prin natura sa. BDOO pot asigura diferite mecanisme de stocare pentru diferite tipuri de date. Drept urmare ele s-au dovedit foarte eficiente att pentru aplicaii multimedia ct i CAD.

n general, se poate spune c BDOO ofer o mai bun performan atunci cnd avem de a face cu obiecte complexe i relaii complexe, deoarece nu este nevoie s spargem obiectele mari n tabele normalizate i apoi s le reasamblm n momentul execuiei programelor de aplicaii.

Dezavantajele BDOO. n ciuda unor multiple avantaje pe care le ofer BDOO totui acestea nc nu au reuit s se impun sub aspectul ponderii implementrii lor n diferite domenii de aplicabilitate. Acest lucru se datoreaz unor dezavantaje ale lor, dintre care enumerm:

Lipsa unor standarde ale arhitecturii de SGBDOO, de modelare a datelor sau de limbaje de integrare standard orientate obiect. Exist totui preocupri i chiar anumite realizri de standardizare pe domeniile amintite, n mare parte aparinnd grupului de administrare a bazelor de date orientate obiect (ODMG).

SGBDOO nu ofer o gam larg de instrumente (TOOLS) utilizatorilor firmei sau proiectanilor de dezvoltri i ntreineri de aplicaii, comparativ cu SGBDR. SGBDOO nu ofer suficient siguran n ceea ce privete rezolvarea problemelor de acces concurent n condiiile lucrului cu volume mari de date. Nu sunt rezolvate n suficient msur problemele referitoare la asigurarea integritii bazei de date sub aspectul refacerii acesteia n caz de incident. ncapsularea poate genera dificulti sub aspectul optimizrii integrrii bazei de date. Felul n care sunt definite i stocate datele i metodele precum i limitele Limbajelor de interogare orientate obiect pot influena n sens negativ performanele de ordin fizic ale bazei de date. Acelai lucru poate s apar i n situaia n care avem de a face cu anumite cerine informaionale care nu au fost prestabilite. Cu alte cuvinte, apare ntrebarea: Cum pot fi cutate i regsite anumite obiecte a cror structur este ncapsulat (ascuns), dac o astfel de cerin nu a fost prevzut nc din faza de proiectare. Remarcm faptul c unele SGBDOO de dat mai recent accept interogrile de tip AD-HOC ns, acest lucru l realizeaz prin distrugerea ncapsulrii sau prin impunerea unor limite privind interogrile posibile. Lipsa de experien n domeniu, comparativ cu experien dobndit n sistemele tradiionale. Aceast lips de experien poate fi datorat cel puin de urmtorii factori:

este un domeniu mai nou de preocupare; SGBDOO prin componentelor lor sunt mai mult orientate spre programatori dect spre utilizatorii finali neinformaticieni; se simte o trecere abrupt de la sistemele tradiionale la cele orientate obiect, iar, nelegerea i nsuirea noului mod de abordare impune eforturi sporite din partea proiectanilor i utilizatorilor. Acest aspect genereaz o oarecare rezisten n acceptarea tehnologiei orientate obiect.

7.4. Comparaii ntre abodarea obiectual i cea relaional privind modelarea datelor

Prezentarea asemnrilor i deosebirilor dintre modelarea relaional i modelarea orientat obiect a datelor este semnificativ i de mare importan att pentru proiectanii de baze de date ct i pentru utilizatori.

Proiectanii, cunoscnd foarte bine modelul relaional i apoi sesiznd asemnrile i deosebirile dintre cele dou moduri de abordare a modelrii datelor, vor putea valorifica i folosi experiena dobndit anterior ca baz substanial pentru nelegerea i nsuirea metodologiei de proiectare a bazelor de date orientate obiect. Totodat, prin cunoaterea asemnrilor i deosebirilor dintre cele dou moduri de abordare apare posibilitatea conversiei unui model relaional n obiectual i invers. De altfel, o astfel de practic o regsim n mod frecvent.

n cele ce urmeaz vom recurge la o prezentare comparativ a modelrii datelor, lund n considerare conceptele folosite precum i obiectivele urmrite.

n tabelul 7.1 se prezint o comparaie ntre principalele concepte utilizate n modelarea obiectual i relaional a datelor.

Tabelul 7.1. Compararea BDOO i BDR sub aspectul conceptelor folosite

Modelul orientat pe obiecteModelul relaionalDiferene

ObiectEntitateObiectul precizeaz i comportamentul

Clasa de obiecteTipuri de entitiClasa de obiecte include i comportamentul comun obiectelor din clasa respectiv

Ierarhia de claseSchema bazei de dateIerarhia de clase implic motenirea iar schema implic chei externe

Instan de clasEntitate, tuplu sau nregistrareInstana poate avea un caracter mai restrictiv

AtributAtributFr diferene

RelaiiRelaiiFr diferene

Au semnificaia de descrieri, ns n BDOO motenirea include att starea ct i comportamentul

Mesaje / interfaNu exist

ncapsulareNu exist

Identificatorul de obiect (OID)Cheie primarn modelul relaional dac nu se definete cheia primar sistemul genereaz n mod automat un identificator

Deosebirile dintre modelul BDOO i modelul BDR pot fi evideniate i sub aspectul obiectivelor urmrite sau prin alte caracteristici, aa cum se poate observa din tabelul 7.2.

Tabelul 7.2. Compararea BDOO i BDR sub aspectul obiectivelor urmrite

BDOOBDR

Obiective principale: ncapsularea i independena datelor.Obiectiv principal: asigurarea independenei datelor fa de programele de aplicaii.

Independena claselor: pot fi reorganizate fr a afecta modul de folosire a lor.Independena datelor: datele pot fi reorganizate i modificate fizic fr a afecta modul de folosire.

BDOO stocheaz date i metode.BDR stocheaz numai date.

ncapsularea: datele pot fi folosite numai prin metodele claselor.Partiionarea datelor: datele pot fi partiionate n funcie de cerinele i specificul aplicaiilor utilizatorilor.

Obiecte active: obiectele sunt active. Cerinele cauzeaz obiectelor executarea metodelor acestora.Date pasive: datele sunt pasive. Anumite operaii limitate pot fi n mod automat antrenate cnd datele sunt folosite.

Complexitate: structura datelor poate fi complex, implicnd multiple tipuri de date.Simplicitate: utilizatorii percep datele sub form de coloane, rnduri / tupluri i tabele.

Date nlnuite. Datele por fi nlnuite aa nct metodele claselor ofer performane sporite. Datele structurate precum i BLOB (binary larrge objects) sunt folosite pentru sunet, imagine, video etc.Tabele separate: fiecare relaie / tabel este separat. Operatorul de JOIN refer date din tabele separate.

Neredundana metodelor: neredundana datelor i metodelor sunt realizate prin ncapsulare i motenire. Motenirea ajut la reducerea redundanei metodelor.Neredundana datelor: Normalizarea datelor are ca scop de a elimina sau reduce redundana datelor. Ea este folosit n faza de proiectare a bazei de date i nu n faz de dezvoltare a aplicaiilor.

Optimizarea datelor: datele pentru un obiect pot fi inter legate i stocate mpreun, astfel nct ele pot fi accesate mpreun de mecanismul de acces.Performana BDR este legat de nivelul de complexitate a structurii datelor.

Modul conceptul consistent: modelele folosite pentru analiz, proiectare, programare i accesul bazei de date sunt similare. Conceptele aplicatiilor sunt in mod direct reprezentate prin clasele de obiecte.Model conceptul diferit: modelul structurii datelor i acces reprezentat prin tabele i JOIN-uri este diferit de cel n analiz, proiectare i programare. Proiectul trebuie s fie convertit n tabele relaionale i acces conform SQL.

Analiznd cele dou tipuri de baze de date, obiectuale i relaionale, por fi desprinse o serie de concluzii, dintre care amintim [Date, Sabu, Kifer]:

O baz de date relaional este format din relaii, care sunt seturi de tupluri, n timp ce o baz de date orientata pe obiecte este format din clase, care sunt seturi de obiecte;

ntr-o baz de date relaional, componentele unui tuplu trebuie s fie tipuri primitive (real, integer, strings etc.), n timp ce ntr-o baz de date orientat pe obiecte, componentele unui obiect pot fi att tipuri primitive ct i tipuri complexe (seturi, tupluri, liste, BLOB-uri etc.);

Bazele de date orientate pe obiecte au anumite proprieti pentru care nu gsim analogie n bazele de date relaionale, cum ar fi proprietatea de motenire i metodele aparinnd obiectelor;

n anumite sisteme de baze de date orientate pe obiecte, limbajul de manipulare a datelor i limbajul gazd sunt aceleai;

Bazele de date relaionale au ca obiectiv principal asigurarea independenei datelor. Datele normalizate sunt separate de prelucrri iar, prelucrrile corespunztoare satisfacerii cerinelor informaionale nu este obligatoriu s fie n totalitate predefinite deci se accept i cerine ad-hoc;

Bazele de date orientate obiect au ca obiectiv principal ncapsularea, fiind stocate mpreun datele / i metodele. Ele sunt inseparabile. Se spune c avem de a face cu independena claselor nu cu independena datelor;

Nevoia unui SGBDOO i nu unul relaional apare atunci cnd n aplicaiile de referin avem de a face cu date complexe;

Limbajele de programare necesit o nou sintax; mixarea, reproducerea i noile metode de acces necesit de asemenea continuarea cercetrilor; trebuie realizate caracteristici mai solide ale limbajelor de interogare; se simte nevoia continurii n domeniul controlului concurenei, semantica mrcilor de timp i concurenei bazate pe obiectele [2, Oracle 2004 A];

Limbajul C++ nu este un limbaj prea adecvat pentru implementarea bazelor de date ntruct prezint probleme legate de mecanica definirii atributelor, mecanica referirii la obiecte ntr-un mod sistematic. Totodat, SGBD actuale bazate pe limbajul C++ duc lipsa unor importante funcii ale bazei de date i, pentru a compensa aceasta s-a recurs la implementri simple ale funciilor standard ale sistemelor de gestiune, cum ar fi: nregistrarea n jurnal a tranzaciilor pentru refacerea prin derulare nainte; un monitor multifir al tranzaciilor, un limbaj de interogare i un procesor de interogri [5,6];

Piaa bazelor de date orientate obiect va continua s creasc, dar va rmne nc doar o fraciune din piaa tradiional a bazelor de date [2I.S3];

Se apreciaz c SGBDR dein ponderea cea mai mare pe piaa bazelor de date. ns ca perspectiv ele vor coexista nc mult timp mpreun cu SGBDOO.

7.5. Moduri de abordare ale dezvoltrii sistemelor de BDOO

innd seama de multitudinea avantajelor oferite de modelul BDOO, se pune problema cum anume se poate trece de la ceva existent la BDOO sau alte variante ce pot fi adoptate. Rspunsul la o astfel de ntrebare const n faptul c pot fi adoptate diverse abordri, cum ar fi:

Folosirea unui sistem de gestiune de baz de date convenional existent i adugarea unui strat (layer) pentru procesarea cerinelor orientate obiect i metodelor de stocare. ntr-o astfel de abordare sistemul de gestiune a bazei de date nu se schimb, ceea ce nseamn c se pot folosi componentele software ale acestuia precum i vechile persoane de aplicaii n curs de exploatare. Totodat, se poate implementa o baz de date orientat obiect mult mai repede dect dac s-ar porni de la conceperea i dezvoltarea tuturor componentelor sistemului de gestiune a bazei de date.

Adugarea de funcionaliti orientate obiect unui sistem de gestiune a bazei de date relaional. ntr-o astfel de situaie se conteaz pe instrumentele, tehnicile i experiena vast a tehnologiei relaionale care pot fi folosite pentru a reconstrui un nou sistem de gestiune a bazelor de date. Pot fi adugai pointri (pointers) la tabelele relaionale legndu-le de Obiectele mari lineare (BLOB Binary Large Object).

Regndirea n totalitate a arhitecturii sistemelor de gestiune a bazelor de date i producerea unei noi arhitecturi care s fac fa noilor tehnologii orientate obiect. Conform acestei variante se are n atenie sporirea substanial a performanelor de ordin fizic a bazelor de date comparativ cu modelul relaional n ceea ce privete stocarea informaiilor complexe.

7.6. Modelul conceptual al datelor obiect (CDOM()

Modelarea reprezint un proces de abstractizare a mediului nconjurtor n scopul simplificrii nelegerii i redrii mai facile a acestuia.

Abstractizarea presupune ignorarea anumitor aspecte considerate nesemnificative n favoarea reinerii a celor mai interesante i reprezentative.

Mediul nconjurtor poate fi considerat ca un sistem, subsistem sau parte a acestuia.

Pentru modelarea unor realiti, activiti, procese sau fenomene economice din domeniul de interes se recurge la utilizarea a diferite metode, tehnici sau instrumente, cum ar fi:

utilizarea anumitor tipuri de diagrame sau grafice ;

prezentarea textual a problematicii de referin;

redarea fenomenelor i proceselor economice n limbaje formale;

sintetizarea i redarea aspectelor de interes sub form de scheme logice etc.

n contextul sistemelor informatice n general, i n special al bazelor de date, se poate recurge la modelarea i implicit elaborarea a o serie de modele, cum ar fi:

Modelarea domeniului (The Domain Model),

Modelarea proceselor de afaceri (The Business Process Model),

Modelarea structurii statice a sistemului (The Static Model),

Modelarea dinamicii sistemului (The Dynamic Model),

Modelarea datelor (The Date Model).

Remarcm faptul c modelarea tuturor aspectelor amintite anterior se refer la acelai sistem, ns prin fiecare tip de model se urmrete satisfacerea cerinelor informaionale de interes a unei anumite categorii de utilizatori. Pentru a modela astfel de procese sau activiti, in concepia abordrii orientate obiect, n cele ce urmeaz vom evidenia i defini conceptele cu care se va opera n ideea realizrii acestui scop. Acest lucru se va face n contextul UML (Unified Modeling Language).

7.6.1. Conceptul de obiect

Un obiect este o entitate cu un rol bine definit n sistem, caracterizat de proprieti, stare, comportament i identitate. La modul general, prin obiect vom nelege ceva asupra cruia se poate ntreprinde o aciune, sau care poate declana / efectua o aciune.

Exemplu: persoan, main, factur, contract, salariat, chitan cas etc. Obiectul poate fi concret (o entitate tangibil i vizil, de exemplu o persoan, o mas, o floare etc.), o entitate abstract (un concept, un eveniment, idee, un departament etc.) sau un artifact al procesului de proiectare (de exemplu, interfa cu utilizatorul, control, planificare).

Proprietile unui obiect sunt date de atributele prin care se descriu caracteristicile obiectului respectiv. Starea unui obiect este dat de valorile pe care le iau proprietile sale la un moment dat. Comportamentul arat modul n care un obiect acioneaz sau reacioneaz la evenimente. O operaie este o simpl aciune pe care o execut un obiect asupra altui obiect pentru a primi un rspuns. Multitudinea operaiilor pe care le poate efectua un obiect sau se efectueaz asupra acelui obiect implementate ntr-un limbaj de programare poart denumirea de metode, iar multitudinea metodelor se spune c definirea comportamentul obiectului de referin. Un obiect i expune comportamentul prin intermediul operaiilor care i pot afecta starea.

S considerm cazul unui student ION, reprezentat de un obiect. Obiectul student are urmtoarele atribute: nume, data-naterii, adresa i telefonul. Starea obiectului este dat de valorile asociate acestor atribute: ,,ION, ,,23-03-85, ,,Mihai Braun nr.6, ,,4438601. Comportamentul studentului este dat de operaii cum ar fi: schimbare-domiciliu, schimbare telefon, trecerea ntr-un nou an de studii etc.

Toate obiectele au o identitate, astfel c nu exist dou obiecte identice. Dac exist dou obiecte (instante) de tip student cu aceleai valori asociate atributelor (aceleai nume, aceeai adres, acelai telefon i aceiai dat de natere) este vorba, totui, de dou obiecte diferite. Chiar dac obiectele au valori identice ale atributelor, ele au identiti diferite. Un obiect i pstreaz identitatea de-a lungul existenei sale. Exemplu, dac studentul ION se cstorete sau i schimb domiciliul, el va fi reprezentat de acelai obiect.

n mod formal un obiect reprezint o pereche de forma (Oid, Val(, unde (Oid( este identificatorul obiectului, iar (val( este o valoare aparinnd obiectului. Valoarea (Val( poate lua una dintre urmtoarele forme:

Valoarea primitiv. Un membru de tip de dat Integer, String, Float sau Boolean; exemplu: ,,B 54 PDD;

Valoare referin. Un OID a unui obiect, exemplu: ( 123;

Valoare tuplu de forma , unde sunt nume de atribute distincte i sunt valori asociate atributelor;

Set de valori, de forma unde sunt valori. Exemplu , numere de telefoane ale unei persoane: 021-3348601, 021-1234567.

Exemplu: presupunem un obiect, din cadrul sistemului bancar romnesc, BCR, cu urmtoarea descriere:(( 11, [cod fiscal: 123456,

Denumirea: BCR,

Preedinte: Rdulescu,

Nr. telefon: (021-1234567, 021-7654321(,

Sucursale: (( 333, ( 444, ( 555, ( 666(,

Localitate: Bucureti])

unde:

simbolul ( 11 reprezint OID-ul obiectului cu denumirea BCR;

ntre paranteze drepte [ ] se definesc atributele cu valorile asociate acestora, ele pe ansamblu reprezentnd o valoare a tupului;

ntre parantezele acolade ( (, se specific seturi de valori cum sunt numerele de telefoane i OID-urile sucursalelor bncii;

referinele ctre sucursalele ce aparin bncii mam-BCR, sunt precizate prin OID-urile acestora (( 333, ( 444, ( 555, ( 666(.

Obiectele pot fi simple sau complexe. Un obiect simplu apare ca un articol sau entitate din mediul nconjurtor ce nu poate fi descompus sau nu se justific descompunerea acestuia; el este tratat ca un ntreg.

Exemplu: persoana, porumbel, medicament etc. Un articol complex apare ca o entitate sau articol din mediul nconjurtor care este privit ca un singur obiect ns acesta se poate combina cu alte obiecte printr-un set de relaii, cum ar fi: B este parte a lui A sau A este format din B, C, D . Obiectele B, C, D, coninute de A, la rndul lor pot fi complexe, ceea ce n final face s asistm la o ierarhie de obiecte. Exemplu, un obiect complex, Automobil poate fi privit ca un obiect format dintr-o serie de componente care la rndul lor sunt privite ca obiecte, de forma (figura 7.1).Gruparea obiectelor n cele dou categorii prezint interes cel puin sub aspectul manipulrii obiectului coninut. Un obiect coninut poate fi manipulat n dou moduri. ntr-un prim mod, obiectul coninut poate fi ncapsulat n obiectul complex i astfel formeaz o parte a acestuia. ntr-o astfel de situaie, structura obiectului coninut reprezint o parte a structurii obiectului complex, iar obiectul coninut poate fi accesat numai cu metodele obiectului complex. n al doilea mod, un obiect coninut poate fi considerat ca avnd o existen independent de cea a obiectului complex. n acest caz, n obiectul printe nu este stocat direct obiectul membru, ci doar identificatorul su OID. Obiectul coninut are structura i metodele lui proprii i poate fi deinut de diverse obiecte printe.

Fig. 7.1. Obiect complex

7.6.2. Identificatorii obiectelor

Aa dup cum s-a mai precizat, fiecare obiect are o identitate unic i stabil, numit identificatorul obiectului OID (Object Identifier), care este independent de valoarea actual a obiectului.

OID-ul este generat de ctre sistem i atribuit obiectului n momentul crerii/ncrcrii bazei de date. El este invizibil pentru utilizatori, independeni de valorile atributelor sale i stabil pe toat durata de existen a obiectului i chiar mai mult dect att, dac obiectul respectiv este ters din baza de date OID-ul acelui obiect nu se atribuie ulterior unui alt obiect.

Observm asemnarea i deosebirea dintre OID i cheia primar a unei relaii. Ca i OID-ul cheia primar ofer posibilitatea identificrii unice a oricrui tuplu/obiect, ns valoarea cheii primare este unic doar la nivelul unei tabele i nu la nivelul ntregului sistem ca i OID-ul, iar pe de alt parte, valoarea cheii primare poate fi schimbat n timp.

Exemplu, presupunem un obiect automobil avnd cheia primar numrul de nmatriculare n circulaie. Totodat presupunem faptul c proprietarul vinde automobilul unei alte persoane. Cu aceast ocazie poate fi schimbat numrul de nmatriculare, deci implicit valoarea cheii primare, dei automobilul rmne fizic acelai i chiar n aceiai baz de date la poliie. n contextul bazelor de date orientate obiect OID-ul automobilului rmne acelai doar c se schimb proprietarul.

Faptul c OID-ul este unic la nivelul ntregului sistem i invariabil n timp prezint o importan deosebit sub aspectul asigurrii mai facile a integritii entitilor i a celor refereniale.

Dac n urma tergerii unui obiect din baza de date OID-ul acelui obiect ar fi atribuit unui alt obiect, o referin anterioar la OID-ul obiectului ters s-ar putea menine, ns de aceast dat OID-ul referit ar aparine unui alt obiect. Deci n realitate nu ar fi respectat i meninut integritatea referenial. Exemplu: presupune o relaie referenial ntre obiectul Parinte i Copil. Dac Printele unui copil ar fi ters din baza de date i OID-ul acestui ulterior ar fi atribuit altui Printe, n contextul posibil de a se menine relaia referenial s-ar ajunge la situaia n care un copil ar aparine unui alt printe dect cel iniial declarat.

O alt problem ce merit a fi prezentat, izvorete din faptul c identificatorii OID ca mecanism pentru identitatea obiectelor sunt independente de coninut, n sensul c identificatorii OID nu depind n nici un fel de datele coninute n obiect. ntr-o astfel de situaie, dou obiecte pot prea utilizatorului aceleai (ele avnd toate valorile atributelor aceleai) i totui au identificatori OID diferii, fiind astfel obiecte diferite. innd seama de faptul c identificatorii OID sunt vizibili pentru utilizatori, atunci ne ntrebm cum poate distinge utilizatorul aceste dou obiecte? Dintr-o astfel de stare putem desprinde concluzia c sunt nc necesare cheile primare, pentru a permite utilizatoului s disting obiectele.

n ncheierea acestui paragraf, facem precizarea c exist o serie de mecanisme, tehnici i algoritmi pentru identitatea obiectelor, cum ar fi: identitatea obiectelor bazate pe valoare, identitatea folosind numele variabilelor i pointerii sau adresele de memorie virtual, identificatoi OID logici i fizici, tehnici de mixare a pointerilor etc. Despre astfel de probleme, i chiar mai multe, cei interesai pot consulta o serie de alte materiale [1, 2, 3, 4].

7.6.3. Atribute proprieti ale obiectelor

Fiecare obiect din mediul nconjurtor comport o anumit descriere ce se realizeaz cu ajutorul atributelor. Multitudinea atributelor prin care se descrie un obiect definesc proprietile acelui obiect.

Atributele pot fi simple sau complexe, care la rndul lor pot fi refereniale, de colecii i derivate.

Pentru exemplificarea ne vom referi la descrierea a dou entiti, astfel (figura 7.2.):

DEPARTAMENT: (Denumire: STRING;

Cod - dep: INTEGER;

ef - dep: SALARIAT;

Nr. telefoane: SET [STRING];

Angajai: LIST [SALARIAT](SALARIAT: (Marca: INTEGER;

Nume: STRING;

Prenume: STRING;

Profesia: STRING;

Data-naterii: DATE;

Funcia: STRING;

Loc-munc: DEPARTAMENT (Fig. 7.2. Exemple de atribute

Atributele simple pot fi un tip de date atomic, care include tipurile de date clasice prezente n limbaje de programare, cum ar fi: ntreg real, boolean iruri de caractere. n exemplul din fig. ., denumire, cod-dep, marca, funcia pot fi considerate ca atribute simple.

Atributele refereniale sau de asociere, sunt folosite pentru a defini relaii refereniale ntre obiecte. Ele sunt echivalente pointerilor din limbajele de programare sau cheilor externe n cazul sistemelor relaionale, ns prezint i diferene importante, astfel:

Contrar pointerilor, atributele refereniale sunt incoruptibile sau nealterabile, n sensul c dac obiectul referit a fost ters din baza de date atunci atributul referenial n mod automat va fi invalidat;

Contrar cheilor externe, atributele refereniale nu sunt asocieri de valori vizibile utilizatorilor. n exemplul nostru din figura 7.2., atributele Sef-dep: SALARIAT i Loc-munc: DEPARTAMENT sunt atribute refereniale.

Atributele colecii fcnd parte din categoria atributelor complexe pot fi la rndul lor grupate n seturi, liste i tablouri de valori.

Atributele colecii vor conine fie valori ale atributelor simple fie referine.

n exemplul din figura 7.2. Nr.-telefoane este un atribut de tip SET i va conine multitudinea numerelor de telefon pe care le are un Departament, iar Angajai este un atribut de tip LIST i va conine ca valori multitudinea identificatorilor OID ale Salariailor ce lucreaz ntr-un anumit Departament.

Atributele derivate le mai regsim i cu denumirea de atribute de proceduri. Uneori, n practic, in loc de a stoca n mod explicit valoarea unui atribut, este de preferat de al determina sau calcula printr-o procedur oarecare i apoi a-l da disponibil i a-l face cunoscut celor interesai. Pe considerentul c valoarea unui atribut derivat se determin printr-o metod de tip procedur sau funcie, atributul respectiv mai poart denumirea de atribut procedur. n exemplul nostru de referin nu apare un atribut derivat, ns ar putea fi definit unul cu denumirea sugestiv Vrsta salariatului. ntr-o astfel de situaie Vrsta ar putea fi determinat cunoscnd Data-naterii i apoi prelund data curent de sistem. Prin diferen se obine vrsta.

7.6.4. Tipuri i clase de obiecte

7.6.4.1. Tipuri de obiecte

n literatura de specialitate nu exist o unanimitate de preri cu privire la definirea i semnificaia conceptelor de tipuri i clase de obiecte. Astfel, ntlnim situaii n care unii autori folosesc doar conceptul de tipuri, ali de clas iar o alt categorie folosesc att conceptul de clas ct i conceptul de tipuri, aa dup cum se va putea vedea n cele ce urmeaz.

R.G.G. Catell [10] folosete doar conceptul de tip dei recunoate i conceptul de clas, ns pentru a nltura anumite ambiguiti n lucrare, renun la folosire termenului de clas, acesta avnd cel puin urmtoarele semnificaii:

O clas definete un tip care este o intensie, adic structura i comportamentul obiectelor de un tip particular. Conceptul de tip este folosit pentru a proiecta o intensie. Intensia va regrupa structura (atributele i relaiile obiectului) precum i comportamentul (metodele asociate tipului); O clas definete o extensie, adic un ansamblu de obiecte de un tip particular; O clas la rndul ei poate fi considerat ca fiind tot un obiect sau meta-obiect dispunnd de atribute, relaii i metode proprii. Aceste proprieti, relaii i metode au semnificaie doar la nivelul ntregii clase i nu la nivelul obiectelor ce fac parte din clas. Exemplu, un atribut avnd semnificaia de suma valorilor tuturor factorilor din clasa FACTURI, are semnificaie doar la nivelul ntregii clase de obiecte i nu la nivelul fiecrui obiect.

R.G.G. Catell pentru a defini conceptul de tip recurge la o analogie cu modelul relaional, considernd c tabelele din modelul relaional sunt definiri de tipuri iar tuplurile (liniile) unei tabele sunt instane de tupluri.

Thomas Connolly [81] precizeaz c, adesea, n literatura de specialitate, termenii de tip i clas sunt sinonimi, cu toate c anumii autori fac o distincie ntre ei, aa cum se va preciza n continuare. Un tip corespunde noiunii de tip de date abstract [ ] Attkinson i Buneman, [1989]. Pe de alt parte, o clas definete modul de creare a obiectelor i formeaz metode care pot fi aplicate acestora. n acest mod o clas se refer mai degrab la modul de implementare a proprietilor i comportamentului obiectelor. ntr-un astfel de context, pe parcurs au fost create dou modele de sisteme de gestiune a bazelor de date orientate obiect, astfel:

unele care folosesc ca termen de baz clasa, dintre care amintim Smalltalk, Orion, ITASCA, Object Store, Vision etc.; altele care folosesc ca termen de baz conceptul de tip, dintre care amintim: Versant, Ontos, Simula, O2 etc.

O astfel de situaie o ntlnim i la nivelul limbajelor de programare. De exemplu, limbajul C++ folosete conceptul de clas, pe cnd SQL3 recurge la utilizarea conceptului de tip. n acest fel definirea tipului n SQL3 este similar cu definirea simplificat a clasei n C++.

Susintorii i realizatorii lui SQL3 folosesc conceptul de tip preferabil celui de clas pe considerentul c cel din urm a fost suprancrcat pentru a se referi la un tip sau la o colecie de instane de un anumit tip.

Din cele constatate se pare c exist o mare majoritate de autori care consider c tipurile i clasele de obiecte sunt nrudite (legate) ns concepte distincte. Din aceast categorie amintim civa [Michael Kifer, Pool Alzeni ]ntr-o baz de date orientat obiect tipurile permit definirea proprietilor obiectelor, att cele statice (descrierea structurii obiectelor) ct i dinamice (descrierea comportamentului obiectelor ca metode aplicabile obiectelor). Referitor la partea static a tipurilor, aceasta este construit utiliznd constructorii de tip i un set larg de tipuri de date atomice, care includ tipurile de date clasice prezente n limbajele de programare, cum ar fi: ntreg, real, boolean i iruri. Tipurile de date atomice includ i identificatorii de obiecte (OID).

Constructorii de tipuri permit definirea tipurilor numii tipuri de date complexe, care dicteaz structura instanelor (numite obiecte complexe) a unei baze de date obiect.

Reprezentarea unui tip se face conform unei expresii de forma:

[CNP: integer, Nume: String, Nr. telefon: (string(, copii: (PERSOANA(]

Aceast definire de tip precizeaz faptul c atributele: CNP accept valori de tip integer, Nume accept valori din domeniul primitiv string (ir de caractere), Nr. telefon trebuie s ia valori ce sunt set de iruri de caractere, iar valorile atributului copii sunt seturi de obiecte ce aparine clasei PERSOANA. Totodat, se poate observa c expresia anterioar descrie un tip (model) n care structuri complexe pot fi incluse n interiorul altor structuri. De exemplu, valorile pentru Nr. telefon sunt seturi de valori primitive, n timp ce valorile pentru copii sunt seturi de obiecte provenite din clasa PERSOANA.

n mod intuitiv se poate deduce faptul c, tipul unui obiect este tocmai colecia tipurilor componentelor acestuia. Constructorii tip permit definirea de tipuri numite tipuri de date complexe, care dicteaz structura instanelor numite obiecte complexe a unei baze de date obiect. Mai precis, o definire recursiv a tipurilor de date complexe corespunztoare structurii obiectelor complexe, bazat pe constructori de tip, apare astfel:

tipuri de baz (valori primitive): ntreg, ir, real i boolean; exemplu: B10XYZ ar putea fi valoarea asociat atributului numrului de nmatriculare n circulaie a autovehiculului descris astfel Nr. MAINA: STRING;

tipuri referin: Numele claselor definite de utilizator, cum ar fi SALARIAI i ECONIMITI, unde ECONOMITII refer SALARIAII, sau un alt exemplu ar pute fi de forma unui OID al unui obiect.

tipuri set i liste: Constructorii de tip SET i LISTE permit definirea de tipuri ale cror instane sunt colecii de valori (posibil complexe) de acelai tip. Seturile sunt colecii neordonate ce nu accept duplicri, iar listele sunt colecii ordonate cu posibile duplicri. Valorile din cadrul setului pot fi de orice tip. n exemplul anterior au fost ntlnite urmtoarele seturi:

Nr. telefon: (string(, reprezint un set de iruri de caractere cu semnificaia c stocheaz multitudinea numerelor de telefoane pe care le are o persoan, de forma: (040-021-334861, , 040-021-3359211(; Copii: (PERSOANA(, reprezint un set de obiecte aparinnd clasei PERSOANA.

tipuri nregistrare / tuplu: un constructor nregistrare permite definirea de tipuri a cror instane sunt tupluri de valori de diferite tipuri posibile. Constatm faptul c i n aceast privin unii autori folosesc doar conceptul de constructor tuplu nu i nregistrare [40], ns sub aspectul formalizrii matematice lucrurile sunt foarte apropiate. Dac T1, , Tn, sunt denumiri de tipuri i A1, , An sunt denumiri de atribute distincte, atunci: T = nregistrare de [A1:T1, , An:Tn] este un tip nregistrare.

Deosebirea dintre cele dou alternative se observ doar la nivelul limbajelor de definire a datelor, n funcie de specificul acestora.

Exemplu:

[CNP: ntreg, Nume: string, An-studii: integer, Adresa:

[Localitate: string, Strada: string, Numr: integer]]

Aceast definire reprezint un tip nregistrare (RECORD) n care primele trei componente (atribute) au tipuri de date de baz, iar al patrulea (Adresa) este de tip tuplu. Deci, se poate constata faptul c avem de a face cu un tip tuplu n cadrul cruia apare un subtip tuplu Adresa, n mod intuitiv se poate desprinde concluzia c puteam avea de a face cu subtipul i supertipuri de date complexe, corespunztoare obiectelor complexe. Totodat precizm faptul ca n mod obinuit n cele mai multe sisteme obiect o definire de tip de dat are constructorul nregistrare (RECORD) la nivelul cel mai nalt.

Din punctul de vedere al bazelor de date orientate obiect, o clas poate fi considerat ca un tip nregistrare constnd din metadata care asigur ntreaga informaie necesar pentru a construi i a folosi un anume obiect. Totodat e posibil de a considera instanele unei clase ca fiind nregistrri stocate ntr-un fiier. Noile nregistrri avnd diferite valori pot fi adugate n fiier. Un dicionar de date pentru SGDB poate conine descrieri a mai multor tipuri diferite de nregistrri, fiecare cu un set diferit de atribute, aa dup cum se va putea constata i n exemplul ce urmeaz.

Pentru exemplificare vom considera un obiect complex referitor la structura unei Universiti, unde:

O universitate poate avea cel puin dou faculti regsite n aceeiai localitate cu sediul Universitii sau n localiti diferite; O facultate poate avea sau nu specializari pe secii; n cadrul unei Universiti pot exista unul sau mai multe laboratoare pe care le pot folosi oricare dintre faculti, dac prezint interes i exist un acord n acest sens; La nivelul unei Universiti pot exista una sau mai multe biblioteci, amplasate ntr-un singur corp sau n mai multe corpuri de cldiri; Catedrele ca departamente, din punct de vedere administrativ i al coordonrii acestora sunt arondate facultilor; O Universitate dispune de un corp didactic propriu, organizai pe Catedre de specialitate;

Un profesor poate preda una sau mai multe discipline la o facultate sau la mai multe faculti.

n situaia n care la nivelul Ministerului nvmntului i Cercetrii ar prezenta interes proiectarea unei baze de date care s permit evidenierea multitudinei unitilor de nvmnt superior din Romnia, precum i a altor aspecte, necesare elaborrii unor studii de analiz, prognoze, evaluri comparative etc., diagrama claselor de obiecte ar putea fi redat astfel (figura 7.3.).

Pe baza diagramei claselor de obiecte, se poate trece la definirea structurii bazei de date orientate obiect, ns ne vom limita doar la o parte a acesteia, astfel (figura7.4.).

Universitate:racord of (

Denumire:string,

Nume-rector:string,

Adresa:record of (

Ora: string,

Strada: string,

Nr,: string)

Faculti;set of (

record of (

Denumire: string

Nume decan: string

Ora: string))

Secii:set of (

record of (

Denumire: string

Nr - studeni: string))

Biblioteci:set of (

record of (

Corp - cldire: string

Profil: string

Bibliotecari: set of (

record of (

Nume: string

Studii: string))]

Fig. 7.4. Exemplu de definire de tip de obiect complex

Asociind valori compatibile cu definirea tipului, situaia ar putea apare de forma:

I1: [ASE, Brbulescu, [Bucureti, Piaa Roman, 6]

([CSIE, Popescu, Bucureti, (Informatic, 600], [Cibernetic, 500], [Statistic, 500], [Economie, 400(](,

([Dorobani 2700, Informatic, ([Dan, superioare], [Vasile, medii](],

[Eminescu 1000, Management, ([Barbu, superioare], [Tudor, medii](](]

unde:

nregistrrile sunt definite prin paranteze drepte iar seturile prin acolade; I1 reprezint o instan din cadrul definirii tipului de obiect complex.

Fig. 7.3. Diagrama claselor de obiecteDe remarcat faptul c un obiect poate include referiri explicite la un alt obiect, pe baz de OID (Object Identifications). Incluznd referiri n structura din figura 7.4., noua definire de tip obiect complex va apare astfel (figura 7.5):

Universitate:record of (Denumire: string,

Nume-rector: string,

Adresa: record of (

Ora: string,

Strada: string,

Numr: integer),

Faculti:set of (( Faculti),

Biblioteci:set of ((Biblioteci))

Faculti:record of(Denumire: string,

Nume-decan: string,

Ora: string

Secii: set of (( Secii))

Secii:record of(Denumire: string,

Nr - studeni: integer),

Biblioteci:record of(corp cldire: string,

Profil: string,

Biblioteci: set of (( Bibliotecari))

Bibliotecari:record of(nume: string,

studii: string)

Fig. 7.5. Exemplu de definire implicnd i referine de obiecte

Un set de instane pentru definirile de mai sus, implicnd i referinele la alte obiecte, apare astfel (fig. 7.6.):

01:

02:

03:

04:

05:

06:

07:

08: