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