| CATEGORII DOCUMENTE |
In conditiile exploziei informationale cu privire la abordarea obiectuala in domeniul informaticii si legat de aparitia si distribuirea unor multitudini de produse softwer si hardwer, pentru a veni in sprijinul realizatorilor si utilizatorilor de astfel de produse s-a conturat din ce in ce mai mult preocuparea pentru elaborarea unor standarde in acest domeniu de interes. Astfel, in 1989 s-a format OMG (Object Management Group) ca un consortiu non-profit avand ca principal scop promovarea orientarii spre obiecte in ingineria programarii si dezvoltarea de standarde. Grupul reuseste peste 700 de unitati membre, ce includ aproape toti realizatorii de produse software si hardware din lume, cum ar fi: Microsoft, ORACLE, IBM, SAP, SUN, Apple, NCR, DEC, Hwlett-Packard, Object Design Inc., Objectivity etc.
De remarcat faptul ca OMG nu este un grup sau organizatie recunoscuta pentru standarde asa cum sunt: Organizatia Internationala de Standardizare (ISO), Institutul National American pentru Standarde (ANSI) sau Institutul de Inginerie Electrica si Electronica (IEEE) ci Consortiul OMG face propuneri de Standarde care ulterior sunt supuse spre acceptare de ISO sau ANSI.
Dintre realizarile consortiului OMG precizam faptul ca in anul 1990 a elaborat si publicat o documentatie intitulata "Object Management Arhitecture Guide". Ghidul are menirea de a specifica:
o terminologie unitara pentru limbaje, sisteme si baze de date orientate obiect;
un cadru abstract pentru sistemele orientate spre obiecte;
un set de scopuri tehnice si arhitecturale;
un model de referinta pentru aplicatiile distribuite utilizand tehnicile orientarii spre obiecte.
In cadrul modelului de referinta pentru aplicatii distribuite au fost identificate urmatoarele domenii ale standardizarii:
modelul de obiecte OM (Object Model);
brockerul de cereri de obiecte ORB (Object Request Brooker), pe baza caruia s-a definit Arhitectura brockerului de cereri comune cunoscuta sub denumirea de CORBA (Common Request Brocker Arhitecture);
serviciile de obiecte (memorie, administrarea tranzactiilor, integrarii, realizarea versiunilor si securitatea sistemului);
facilitati comune (help, E-mail si browser).
In 1989 cativa producatori de software pentru baze de date s-au reunit si au format un grup pentru administrarea bazelor de date orientate obiect ODMG - Object Database Management Grup, avand ca obiectiv de a defini standarde pentru SGBDOO. Din cadrul grupului faceau parte producatorii: Gemstone Systems, Object Design, O2 Technology, Versant Object Technology, UniSQL, POET Software, Objectivity, IBEX Computing SA, Lockheed Martin, Ontos, Itasca, Servio, Hewelt-Packard etc.
Grupul de lucru a conceput un model standard incluzand urmatoarele componente pentru SGBDOO:
modelul de obiecte (OM),
limbajul de definire a obiectelor (ODL - Object Definition Language),
limbajul de interogare a obiectelor (OQL - Object Query Language),
interfata cu limbajul C++,
interfata cu limbajul Smalltalk,
interfata cu limbajul Java.
Actualmente, sistemele comercializate ce suporta standardul ODMG 3.0 includ GemStone (https://www.gemstone.com), Objectstore (https://www.odi.com.), Poet (https://www.poet.com) etc.
In cele ce urmeaza ne propunem sa facem o trecere in revista doar a primelor trei componente iar pentru celelalte trei recomandam cititorilor interesati cateva surse mai insemnate de documentare (Catell and Barry 2000, www.odmg).
Modelul ODMG de obiecte reprezinta un superset al modelului OMG de obiecte, urmarind in mod deosebit de a asigura portabilitatea proiectarii si implementarii aplicatiilor pe diverse SGBDOO care accepta modelul de obiecte.
Elementele fundamentale care constituie suportul pentru modelare sunt:
Modelul ODMG este bazat pe obiecte, fiecare obiect avand un identificator unic;
Obiectele pot fi clasificate in tipuri. Multitudinea obiectelor de un tip dat prezinta un comportament si o stare comuna;
Starea obiectului este data de valorile pe care le iau proprietatile obiectului. O proprietate poate fi un atribut sau o relatie dintre unul sau mai multe alte obiecte;
Multitudinea operatiilor pe care le poate efectua un obiect sau alte obiecte asupra lui implementate intr-un limbaj oarecare de programare poarta denumirea de metoda;
Multitudinea metodelor apartinand unui obiect definesc comportamentul acelui obiect;
Fiecare metoda este insotita de o semnatura prin care se precizeaza denumirea operatiei, denumirea si tipul tuturor parametrilor de intrarea si iesire si situatii de exceptie ce pot interveni (conditii de eroare);
Baza de date ce stocheaza obiectele in concordanta cu schema acestuia, descrisa cu ajutorul unui limbaj de definirea a obiectelor (ODL).
Despre toate aceste elemente fundamentale gasim detalii in paragrafele anterioare, precum si alte lucrari de referinta (Craig Laorman - UML - 98, Cattell).
Limbajul de definire a obiectivelor - ODL (Object Definition Language) este destinat descrierii schemei bazei de date orientate obiect. El descrie tipuri si nu clase si este independent de limbajul de programare ales pentru implementarea claselor. El defineste atributele, relatiile dintre tipuri si specifica semnatura operatiilor (metodelor). De retinut faptul ca el nu se refera la implementarea semnaturilor. ODL a fost conceput de ODMG. Sintaxa ODL se bazeaza pe limbajul de Definire a Interfetei - IDL (Interface Definition Language), fiind o extensie a acestuia. IDL apartine OMG-ului si este parte integranta a lui CORBA (Common Object Request Broker).
ODMG a ales IDL ca baza de referinta, in loc de a inventa o noua sintaxa, pe considerentul ca prin aceasta alegere se asigura un grad sporit de compatibilitate cu recunoscutul si importantul standard CORBA pentru sisteme de baze de date distribuite.
Terminologia utilizata in ODL difera in anumite privinte de cea utilizata de CODM. Aceasta diferenta isi gaseste explicatia, intr-o oarecare masura, tocmai in obiectivul urmarit de ODMG si anume acela de a asigura o maximizare a portabilitatii schemei de date pentru mai multe limbaje de programare.
Ideea avuta in vedere de ODMG consta in faptul ca schema bazei de date definita de ODL trebuia sa permita accesarea obiectelor in mai multe limbaje de programare gazda. Acest lucru, pentru moment, este posibil in limbajele C++, Java si Smalltalk
In semnificatia ODMG, pentru fiecare legatura cu limbajele de programare gazda se prevede extinderea documentatiei sau adaptarea acesteia in contextul respectarii structurii comune ODMG.
Comunicarea se face printr-un set de variabile din limbajul gazda si un preprocesor special care modifica cadrul sursa pentru a inlocui afirmatiile ODL cu apelari la rutinele SGBD. Codul sursa poate fi apoi compilat si linkeditat in mod normal.
Faptul ca ODL defineste tipuri ce pot fi implementate in numeroase limbaje de programare ofera numeroase avantaje, astfel:
ODL permite ca o aceiasi baza de date sa fie partajata pe multiple limbaje de programare, sau cu alte cuvinte, o aceiasi aplicatie sa fie portabila pe numeroase limbaje de programare fara rescrierea definirii schemei bazei de date.
ODL este utilizat pentru analiza si conceperea schemei bazei de date inaintea descrierii datelor si operatiilor unei aplicatii independent de un limbaj de programare. Conceptia rezultata poate fi utilizata fie in mod direct fie translatata intr-un limbaj de descriere a datelor ales de programator;
Schema descrisa in ODL este acceptata de toate SGBD compatibile cu conceptia ODMG.
De remarcat faptul ca nu este posibil intotdeauna obtinerea unei compatibilitati de 100% a schemei bazei de date cu alte produse software, datorita unor diferentieri intrinseci a modelelor limbajelor de programare. Deci, ODL va comporta coloratura si specificul limbajului gazda cu care realizeaza legatura.
De exemplu, in cazul legaturii cu Java, ODL distinge doua feluri de clase. Prima este numita interfata iar a doua clasa. Pentru a evita confuzia cu clasele CODM recurge la numirea acestora interfata ODMG si respectiv clasa ODMG.
In termenii CODM, definitia interfetei si clasei ODMG specifica:
un nume de clasa (in sens CODM) impreuna cu partea relevanta a ierarhiei de mostenire;
un tip asociat clasei de referinta.
O colectie de astfel de definitii specifica schema intregii baze de date ODMG.
Principalele diferente dintre interfetele ODMG si clasele ODMG sunt:
O interfata ODMG nu poate include codul (programul) pentru metode; ceea ce inseamna ca sunt permise doar semnaturile metodei, acest aspect constituie tocmai motivul pentru care se numeste interfata. Clasele ODMG includ codul pentru metodele claselor de referinta. Semnatura si codul pot fi explicite specificate prin folosirea unui limbaj gazda sau pot fi mostenite de la o clasa din cadrul unei ierarhii de clase de obiecte;
O interfata ODMG nu poate avea propriile ei obiecte membre, adica instantele de obiecte ale interfetei nu pot fi create. Din contra, o clasa ODMG poate avea obiecte membre;
O interfata ODMG nu poate mosteni dintr-o clasa ODMG dar poate mosteni doar din alta interfata ODMG;
O clasa ODMG poate mosteni din multiple interfete ODMG dar nu poate avea decat cel mult o superclasa ODMG imediat.
Distinctia dintre clase si interfete se face din urmatoarele doua considerente:
In primul rand aceasta distinctie face ODL-ul un superset al IDL-ului CORBA, prin aceasta asigurand un grad sporit de compatibilitate cu acest important standard pentru sisteme distribuite.
In al doilea rand aceasta diferentiere permite ODL-ului sa depaseasca cateva dintre problemele asociate cu mostenirea multipla care apare cand o clasa mosteneste doua definiri diferite pentru o aceiasi metoda din superclase diferite.
Precizam faptul ca o prezentare completa a sintaxei unui limbaj ODL depaseste scopul acestei carti. Totusi, urmatorul exemplu va ilustra unele elemente ale limbajului. Cititorului interesat ii recomandam, pentru o definitie completa a ODL-ului, sa consulte [Catell-1997].
Pentru exemplificarea modului de utilizare a ODL ne vom referi la schema partiala prezentata in figura 7.3.
Interface UNIVERSITATE
Interface FACULTATE: UNIVERSITATE // Defineste interfata pentru
// entitatea/obiectul Facultati
// care mosteneste obiectul
// Universitate
Interfata SECTIE: UNIVERSITATE // Defineste interfata pentru
// obiectul sectie care
// mosteneste obiectul
// Facultate
Interface STUDENT // Defineste interfata pentru
// entitate/obiectul STUDENT
(extent STUDENT);
Key CNP)
sex;
Urmeaza definirea relatiilor
relationship FACULTATE urmeaza
inverse FACULTATE:: urmata de;
relationship SECTIE specialist in
inverse SECTIE:: specializeaza;
relationship CURS frecventeaza
inverse CURS:: frecventat de;
Urmeaza definirea operatiilor
inscrie la curs la sectia (in CURS, in SECTIE) raises
(cerere nesatisfacuta, curs plin, nr locuri ocupate);
Void transfer student (in from SECTIE, in to
SECTIE) raises (nu exita locuri disponibile
Interface CURS // Defineste interfata CURS
Urmeaza definirea atributelor
atribute integer cod curs;
atribute string Denumire curs;
atribute integer Nr. credite
Urmeaza definirea relatiilor
relationship SECTIE se preda la
inverse SECTIE:: are;
relationship STUDENT frecventat de
inverse STUDENT :: frecventeaza;
Urmeaza definirea operatiilor
Void sterge curs ( ) raises (nu exista acest curs):
Interface LABORATOR // Defineste interfata LABORATOR
atribute integer salariu;
Urmeaza definirea relatiilor
relationship UNIVERSITATE este la
inverse UNIVERSITATE:: are;
relationship CATEDARA apartine de
inverse CATEDARA:: dispune de;
Urmeaza definirea operatiilor
Void majorare salariu (in float);
In cele ce urmeaza vom cauta sa facem cateva precizari pe marginea exemplului de utilizare a Limbajului de Definire a Obiectelor, astfel:
Cuvantul cheie "interface" este utilizat pentru a defini o clasa si a asigura compatibilitatea cu OMG - IDL. Pentru fiecare interfata se poate declara un "extent" si specifica anumite Key. Extent ul precizeaza denumirea pentru setul curent de obiecte a acelei clase. El est analog cu instanta unei relatii si interfata este analoga schemei relatiei. Daca utilizatorul nu anticipeaza nevoia sa lucreze cu seturi de obiecte ale unei clase date, deci ca ar fi suficient sa manipuleze individual obiectele, atunci declararea "Extent-ului" poate fi omisa. Distinctia dintre numele interfetei (si numele extent-ului intr-un limbaj de definire a datelor este mai degraba folosit din punctul de vedere al uni SGBD relationale. Deci, intarim precizarea ca numele interfetei ar fi similar cu a da un nume schemei unei relatii (folosind comanda CREATE TABLE nume) si un nume diferit instantei relatiei actuale peste acea schema. Oricum, se apreciaza ca din punctele de vedere practic si conceptual, valoarea clauzei extent ramane o problema de discutat.
Clauza Key specifica faptul ca extent-ul are o cheie cu o anumita denumire. Exemplu, extent STUDENT are definita si o cheie cu denumirea CNP care nu permite existenta a doua instante cu o aceiasi cheie in cadrul extent-ului.
Proprietatile claselor de obiecte sunt specificate utilizand ODL si sunt de trei feluri: atributele, relatii si metode.
Atributele sunt definite ca fiind de tip integer, string, date, enum (pentru liste de valori) etc.
Relatiile dintre clasele de obiecte sunt specificate prin clauzele "Relationships" si corespondenta acesteia "inverse relationships"; deci observam ca avem de a face cu o definire bidirectionala.
La nivelul fiecarei interfete a fost precizata cu scop exemplificativ cate o 'semnatura de metoda", in cadrul carora apar specificate si situatiile de exceptie folosind clauza "raises".
In cadrul descrierii structurii BDOO se mai pot desprinde si alte aspecte evidentiate prin comentarii.
Limbajul de cereri obiect (Object Query Language) constituie o extensie a SQL, chiar daca asemanarile dintre cele doua limbaje sunt mai mult aparente decat reale, in mare masura depind de utilizarea acelorasi cuvinte-cheie.
OQL ca si SQL, este un limbaj pur pentru cereri. El nu include, de exemplu, controlul structurilor. Din OQL este posibil sa se invoce metode care sporesc puterea expresiva a acestora. In mod curent OQL nu include primitive pentru actualizarea starii obiectelor continute in baza de date, aceste actualizari urmand a se realiza cu ajutorul metodelor .
De remarcat faptul ca limbajul OQL initial a fost elaborat pentru O2, apoi a fost adaptat de catre ODMG, printr-o serie de modificari, astfel incat actualmente este considerat ca un limbaj de cereri standard pentru SGBDOO. El poate fi utilizat atat ca un limbaj autonom, cat si ca un limbaj inglobat in alt limbaj, pentru care este definita o legatura de tip ODMG. Limbajele acceptate in mod curent sunt Smalltalk, C++ si Java. Totodata este de precizat faptul ca limbajul OQL poate invoca operatii programate in limbajele amintite anterior.
O cerere/interogare OQL este o functie care furnizeaza un obiect, al carui tip poate fi dedus din operatorul care contribuie la expresia de interogare. Si de aceasta data facem precizarea ca rezultatul unei cereri OQL nu este obligatoriu sa fie un obiect sau o tabela, aceasta poate fi chiar un intreg, o lista de referinta a obiectelor, o structura, un ansamblu de numere reale sau intreaga structura de date definind un obiect.
O integrare poate fi compusa dintr-o multime, posibil vida, de expresii, cum ar fi: expresii de obiecte, de tip atomic, elementare, de definire a interogarii (de forma: DEFINE Q AS e; defineste o interogare cu denumirea Q, pentru o expresie de interogare e data), de multimi diverse, de conversii etc.
Expresiile pot fi compuse in diferite forme, cum ar fi: prin utilizarea cuantificatorului universal (for all), cuantificarea existentiala (exists), testul de apartenenta (in), clauza select from where, operatorul de sortare (sort), operatorii unari pentru multimi (min, max, count, sum, avg) si operatorul de grupare (group).
Formatul clauzei SELECT este foarte apropiat de cel din limbajul standard SQL, si anume:
SELECT [DISTINCT] <expresie>
FROM <din-lista>
[WHERE <extensie>]
[GROUP BY <atribute>]
[HAVING <predicat>]
[ORDER BY <expresie>]
unde, intr-o forma succesiva, elementele din <din-lista>:: =
<denumire_variabila> IN <expresie>]
<denumire_variabila> IN <expresie>,
<din-lista>]
<expresie] AS <denumire_variabila>]
<expresie] AS <denumire_variabila>,
<din-lista>]
In cele ce urmeaza vom cauta sa oferim cateva exemplificari pentru a observa modul de utilizare a limbajului OQL; referirile facandu-se la structura bazei de date orientate obiect din figura 7.3.
Exemplul 1, evidentiaza faptul ca nu intotdeauna este necesara utilizarea clauzei SELECT FROM WHERE; Este suficient a specifica doar: STUDENT, aceasta este o cerere completa si are ca efect obtinerea / listarea tuturor studentilor (ca obiecte cu identitate).
Exemplul 2, evidentiaza modul in care este utilizata clauza DISTINCT din fraza SELECT:
SELECT DISTINCT X.Adresa
FROM X IN STUDENT
WHERE X. Nume = 'IONESCU'
are ca efect returnarea setului adreselor tuturor studentilor ce au numele de IONESCU. Mai exact, datorita clauzei DISTINCT, se va returna o valoare de tip SET <ADRESE> in care valoarea unei adrese apare o singura data. Cu alte cuvinte, vor fi listate toate adresele la care se afla studenti cu numele IONESCU, fiecare adresa fiind luata o singura data. In modelul relational, mai precis in algebra relationala, clauza DSTINCT are semnificatia de operator de proiectie a relatiei STUDENTI pe atributul Adresa.
Daca, in cererea de mai sus, ar fi omisa clauza DISTINCT din fraza SELECT, cererea ar returna o valoare de tip Bag <ADRESE>; un Bag de adrese este similar cu un SET insa poate avea elemente duplicate.
Tipul SET vine cu metodele incorporate inauntru, care da programatorului accesul la elementele setului pentru a obtine functionalitatea asigurata de cursori in SQL (identificator/pointer, cu ajutorul caruia se manipuleaza o zona de memorie alocata si gestionata de sistem pentru a se executa o comanda).
Exemplul 3 evidentiaza modul de invocare a unei metode in faza SELECT:
SELECT T. adauga_un_nou_nr_tel ('031_456789')
FROM T IN UNIVERSITATE
WHERE T. Denumire = 'A.S.E.'
Are ca efect adaugarea unui nou numar de telefon in setul de numere. Cererea actualizeaza baza de date insa nu returneaza nimic apelantului metodei.
Exemplu 4 are ca scop evidentierea unei expresii de definire a unei interogari. Se cere sa se gaseasca toti studentii ce au domiciliul stabil in Bucuresti:
DEFINE Bucuresteni AS
SELECT X
FROM X IN STUDENTI
WHERE X.Adresa = 'Bucuresti'
SELECT X. Nume_Prenume FROM X IN Bucuresti.
Exemplul 5 are ca scop evidentierea modului de creare/cunoastere a unui obiect. Precizam faptul ca OQL accepta doua tipuri de obiecte in conceptia modelului ODMG: cu identitate sau mutabile, avand un OID si fara identitate sau literali, fara OID, in functie de care difera si modul de creare sau selectie.
In cele ce urmeaza vom exemplifica modul de creare a unui obiect cu identitate:
PROFESOR (CNP: 1012644400237, NUME-PRENUME: "BARBU DAN",
MARCA: 12233, SPECIALITATE: "INFORMATICA",
GRAD-DIDACTIC: "PROFESOR", SALARIU: 3500)
In situatia in care anumite proprietati/atribute nu sunt initializate, ele vor lua valori implicite.
Un obiect cu identitate mai poate fi creat/construit si in alte variante, dintre care una ar poate fi aceea care presupune un tip obiect predefinit, care apoi se va initializa cu valori preluate prin selectie dintr-un alt tip de obiecte. Astfel, presupunem ca ar prezenta interes de a avea si pastra separat un tip/clasa de obiecte referitoare la toate cadrele didactice avand specializarea "informatica" si descrise prin proprietatile: CNP, NUME-PRENUME si GRAD-DIDACTIC. Intr-o astfel de situatie, tipul de obiecte cu denumirea sugestiva de INFORMATICIAN ar putea fi initializat/populat cu valori preluate din tipul PROFESOR, de forma:
INFORMATICIAN (SELECT STRUCT (CNP;XNUME-PRENUME: XNUME-PRENUME, GRAD-DIDACTC: XGRAD-DIDACTIC)
FROM X IN PROFESOR
WHERE X SPECIALIZAREA = "INFORMATICA")
Cazuri asemanatoare regasim si in modelul relational.
Obiectele fara identitate sunt create cu ajutorul tipurilor literale structurate, de forma:
STRUCT (a : 7, b : 10, c : "BAZE DE DATE")
Deci, se creeaza o structura cu trei campuri a, b si c.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1004
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
