Capitol 7

Baze de date orientate obiect

Capitol 7Baze 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.6. Modelul conceptual al datelor obiect (CDOM[footnoteRef:1]) [1: CODM The Conceptual Object Data Model]

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.

AUTOMOBILMOTORROIASIUPISTOANECILINDRIIBUJIIFig. 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.):

DEPARTAMENTSALARIATare 1, 1.1apartine deDEPARTAMENT: 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: stringNume decan: stringOra: string))

Secii:set of (record of (Denumire: stringNr - studeni: string))

Biblioteci:set of (record of (Corp - cldire: stringProfil: stringBibliotecari: 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.

CARTECITITOR0,mprumutat degestioneaz1,1,gestionat deBIBLIOTECARofer cartesolicit carte1,1,1,are1,1angajat laBIBLIOTECA1,* are se afl n1,1,1,1dispune deaparine deUNIVERSITATEPROFESORLABORATOR1, areeste la 1,11,1 aparine dedispune de1,CURS SECIEare 10,1, frecventeazSTUDENT25,1,* predatlaspecializeaz25,specialist n1,1FACULTATECATEDRAcoordonate de1,1coordoneaz1,1,folosit defolosete0,dispune deaparine de1,11,2urmeazurmat de100,frecventat deFig. 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: stringSecii: 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:

>

Actualizare baz de date

Administrare

Comand articole

Login / Logout

Sistem

Fig. 7.43. Modelarea proceselor afacerii cu ajutorul diagramei cazurilor de utilizare

Fig. 7.44. Sistem de nregistrare studeniCazul de utilizare:nregistrare la curs

Actori:Student, Secretar

Descriere:

Acest caz de utilizare se declaneaz atunci cnd studentul solicit nscrierea la un curs. Secretara verific dac studentul a parcurs cursurile pregtitoare i a promovat examenele respective. Dac este vorba despre un curs special, secretara solicit studentului aprobarea instructorului. Secretara nregistreaz studentul la curs.

Fig. 7.45. Descrierea cazului de utilizare nregistrare la curs

Fig. 7.46. Diagrama claselor pentru sistemul de gestiune a comenzilor

Fig. 7.47. Reprezentarea unui scenariu cu ajutorul diagramei de secvenreturn ( ok )

Adaug_articol ( articol_id )

return ( info_articol )

return ( info_articol )

return ( list_articole )

Detalii_articol ()

* [ pentru fiecare articol din list ] Detalii_articol ( articol_id )

Caut_n_catalog ()

: Articol

Valideaz ()

Login ( user, parola )

: Co_comenzi

: Catalog_articole

: Cont_utilizator

: Utilizator

Fig. 7.48. Reprezentarea unui scenariu cu ajutorul diagramei de colaborare7. return ( info_art )

6.detalii_articol ()

4. return ( list_art )

8. return ( info_art )

3. Caut_n_catalog ()

5. detalii_articol ( art_id )

2. Valideaz ()

: Articol

9. Adauga_articol ( articol_id )

1. Login ( user, parola )

: Catalog_articole

: Co_comenzi

: Cont_utilizator

: Utilizator

Fig. 7.49. Diagram de stare