Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

CATEGORII DOCUMENTE





loading...

AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows
WordXml


Tipuri si clase de obiecte

baze de date

+ Font mai mare | - Font mai mic







DOCUMENTE SIMILARE

Trimite pe Messenger
Mostenirea - date obiect
Moduri de abordare ale dezvoltarii sistemelor de BDOO
ADMINISTRATORUL BAZEI DE DATE A RETELEI DE SERVICE-URI AUTO
Baze de date. Proiectare. Implementare. Gestionare
LIMBAJE DE DEFINIRE A DATELOR
LIMBAJE: VISUAL BASIC, ACCESS
Proiectarea BDOO – componenta a sistemului informatic
Formularele
Utilizatorii si Securitatea
Seminar Baze de date

Tipuri si clase de obiecte

7.6.4.1. Tipuri de obiecte



In literatura de specialitate nu exista o unanimitate de pareri cu privire la definirea si semnificatia conceptelor de tipuri si clase de obiecte. Astfel, intalnim situatii in care unii autori folosesc doar conceptul de tipuri, alti de clasa iar o alta categorie folosesc atat conceptul de clasa cat si conceptul de tipuri, asa dupa cum se va putea vedea in cele ce urmeaza.

R.G.G. Catell [10] foloseste doar conceptul de tip desi recunoaste si conceptul de clasa, insa pentru a inlatura anumite ambiguitati in lucrare, renunta la folosire termenului de clasa, acesta avand cel putin urmatoarele semnificatii:

O clasa defineste un tip care este o intensie, adica structura si comportamentul obiectelor de un tip particular. Conceptul de tip este folosit pentru a proiecta o intensie. Intensia va regrupa structura (atributele si relatiile obiectului) precum si comportamentul (metodele asociate tipului);

O clasa defineste o extensie, adica un ansamblu de obiecte de un tip particular;

O clasa la randul ei poate fi considerata ca fiind tot un obiect sau meta-obiect dispunand de atribute, relatii si metode proprii. Aceste proprietati, relatii si metode au semnificatie doar la nivelul intregii clase si nu la nivelul obiectelor ce fac parte din clasa. Exemplu, un atribut avand semnificatia de suma valorilor tuturor factorilor din clasa FACTURI, are semnificatie doar la nivelul intregii clase de obiecte si nu la nivelul fiecarui obiect.

R.G.G. Catell pentru a defini conceptul de tip recurge la o analogie cu modelul relational, considerand ca tabelele din modelul relational sunt definiri de tipuri iar tuplurile (liniile) unei tabele sunt instante de tupluri.

Thomas Connolly [81] precizeaza ca, adesea, in literatura de specialitate, termenii de ”tip” si ”clasa” sunt sinonimi, cu toate ca anumiti autori fac o distinctie intre ei, asa cum se va preciza in continuare. Un tip corespunde notiunii de tip de date abstract [ ] Attkinson si Buneman, [1989]. Pe de alta parte, o clasa defineste modul de creare a obiectelor si formeaza metode care pot fi aplicate acestora. In acest mod o clasa se refera mai degraba la modul de implementare a proprietatilor si comportamentului obiectelor. Intr-un astfel de context, pe parcurs au fost create doua modele de sisteme de gestiune a bazelor de date orientate obiect, astfel:

unele care folosesc ca termen de baza clasa, dintre care amintim Smalltalk, Orion, ITASCA, Object Store, Vision etc.;

altele care folosesc ca termen de baza conceptul de tip, dintre care amintim: Versant, Ontos, Simula, O2 etc.

O astfel de situatie o intalnim si la nivelul limbajelor de programare. De exemplu, limbajul C++ foloseste conceptul de clasa, pe cand SQL3 recurge la utilizarea conceptului de ”tip”. In acest fel definirea tipului in SQL3 este similara cu definirea simplificata a clasei in C++.

Sustinatorii si realizatorii lui SQL3 folosesc conceptul de ”tip” preferabil celui de ”clasa” pe considerentul ca cel din urma a fost supraincarcat pentru a se referi la un tip sau la o colectie de instante de un anumit tip.

Din cele constatate se pare ca exista o mare majoritate de autori care considera ca tipurile si clasele de obiecte sunt inrudite (legate) insa concepte distincte. Din aceasta categorie amintim cativa [Michael Kifer, Pool Alzeni ]

Intr-o baza de date orientata obiect tipurile permit definirea proprietatilor obiectelor, atat cele statice (descrierea structurii obiectelor) cat si dinamice (descrierea comportamentului obiectelor ca metode aplicabile obiectelor). Referitor la partea statica a tipurilor, aceasta este construita utilizand constructorii de tip si un set larg de tipuri de date atomice, care includ tipurile de date clasice prezente in limbajele de programare, cum ar fi: intreg, real, boolean si siruri. Tipurile de date atomice includ si identificatorii de obiecte (OID).

Constructorii de tipuri permit definirea tipurilor numiti tipuri de date complexe, care dicteaza structura instantelor (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: , copii:

Aceasta definire de tip precizeaza faptul ca atributele: CNP accepta valori de tip ”integer”, Nume accepta valori din domeniul primitiv ”string” (sir de caractere), Nr. telefon trebuie sa ia valori ce sunt ”set de siruri” de caractere, iar valorile atributului ”copii” sunt seturi de obiecte ce apartine clasei PERSOANA. Totodata, se poate observa ca expresia anterioara descrie un tip (model) in care structuri complexe pot fi incluse in interiorul altor structuri. De exemplu, valorile pentru ”Nr. telefon” sunt seturi de valori primitive, in timp ce valorile pentru ”copii” sunt seturi de obiecte provenite din clasa PERSOANA.

In mod intuitiv se poate deduce faptul ca, tipul unui obiect este tocmai colectia tipurilor componentelor acestuia. Constructorii tip permit definirea de tipuri numite tipuri de date complexe, care dicteaza structura instantelor numite obiecte complexe a unei baze de date obiect. Mai precis, o definire recursiva a tipurilor de date complexe corespunzatoare structurii obiectelor complexe, bazata pe constructori de tip, apare astfel:

tipuri de baza (valori primitive): intreg, sir, real si boolean; exemplu: ”B10XYZ” ar putea fi valoarea asociata atributului numarului de inmatriculare in circulatie a autovehiculului descris astfel – Nr. MASINA: STRING;

tipuri referinta: Numele claselor definite de utilizator, cum ar fi SALARIATI si ECONIMISTI, unde ECONOMISTII refera SALARIATII, sau un alt exemplu ar pute fi de forma unui OID al unui obiect.

tipuri set si liste: Constructorii de tip SET si LISTE permit definirea de tipuri ale caror instante sunt colectii de valori (posibil complexe) de acelasi tip. Seturile sunt colectii neordonate ce nu accepta duplicari, iar listele sunt colectii ordonate cu posibile duplicari. Valorile din cadrul setului pot fi de orice tip. In exemplul anterior au fost intalnite urmatoarele seturi:

Nr. telefon: , reprezinta un set de siruri de caractere cu semnificatia ca stocheaza multitudinea numerelor de telefoane pe care le are o persoana, de forma:

Copii: , reprezinta un set de obiecte apartinand clasei PERSOANA.

tipuri inregistrare / tuplu: un constructor inregistrare permite definirea de tipuri a caror instante sunt tupluri de valori de diferite tipuri posibile. Constatam faptul ca si in aceasta privinta unii autori folosesc doar conceptul de constructor tuplu nu si inregistrare [40], insa sub aspectul formalizarii matematice lucrurile sunt foarte apropiate. Daca T1, …, Tn, sunt denumiri de tipuri si A1, …, An sunt denumiri de atribute distincte, atunci: T = inregistrare – de [A1:T1, …, An:Tn] este un tip inregistrare.

Deosebirea dintre cele doua alternative se observa doar la nivelul limbajelor de definire a datelor, in functie de specificul acestora.

Exemplu:

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

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

Aceasta definire reprezinta un tip inregistrare (RECORD) in care primele trei componente (atribute) au tipuri de date de baza, iar al patrulea (Adresa) este de tip tuplu. Deci, se poate constata faptul ca avem de a face cu un tip tuplu in cadrul caruia apare un subtip tuplu ”Adresa”, In mod intuitiv se poate desprinde concluzia ca puteam avea de a face cu subtipul si supertipuri de date complexe, corespunzatoare obiectelor complexe. Totodata precizam faptul ca in mod obisnuit in cele mai multe sisteme obiect o definire de tip de data are constructorul inregistrare (RECORD) la nivelul cel mai inalt.

Din punctul de vedere al bazelor de date orientate obiect, o clasa poate fi considerata ca un tip inregistrare constand din metadata care asigura intreaga informatie necesara pentru a construi si a folosi un anume obiect. Totodata e posibil de a considera instantele unei clase ca fiind inregistrari stocate intr-un fisier. Noile inregistrari avand diferite valori pot fi adaugate in fisier. Un dictionar de date pentru SGDB poate contine descrieri a mai multor tipuri diferite de inregistrari, fiecare cu un set diferit de atribute, asa dupa cum se va putea constata si in exemplul ce urmeaza.

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

O universitate poate avea cel putin doua facultati regasite in aceeiasi localitate cu sediul Universitatii sau in localitati diferite;

O facultate poate avea sau nu specializari pe sectii;

In cadrul unei Universitati pot exista unul sau mai multe laboratoare pe care le pot folosi oricare dintre facultati, daca prezinta interes si exista un acord in acest sens;

La nivelul unei Universitati pot exista una sau mai multe biblioteci, amplasate intr-un singur corp sau in mai multe corpuri de cladiri;



Catedrele ca departamente, din punct de vedere administrativ si al coordonarii acestora sunt arondate facultatilor;

O Universitate dispune de un corp didactic propriu, organizati pe Catedre de specialitate;

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

In situatia in care la nivelul Ministerului Invatamantului si Cercetarii ar prezenta interes proiectarea unei baze de date care sa permita evidentierea multitudinei unitatilor de invatamant superior din Romania, precum si a altor aspecte, necesare elaborarii unor studii de analiza, prognoze, evaluari comparative etc., diagrama claselor de obiecte ar putea fi redata astfel (figura 7.3.).

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

Universitate:

racord – of (

Denumire:

string,

Nume-rector:

string,

Adresa:

record – of (

Oras: string,

Strada: string,

Nr,: string)

Facultati;

set – of (

record – of (

Denumire: string

Nume – decan: string

Oras: string))

Sectii:

set – of (

record – of (

Denumire: string

Nr - studenti: string))

Biblioteci:

set – of (

record – of (

Corp - cladire: 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, situatia ar putea apare de forma:

I1: [’ASE’, ’Barbulescu’, [’Bucuresti’, ’Piata Romana’, ’6’]

[’Eminescu – 1000’, ’Management’,

unde:

inregistrarile sunt definite prin paranteze drepte iar seturile prin acolade;

I1 reprezinta o instanta din cadrul definirii tipului de obiect complex.

Fig. 7.3. Diagrama claselor de obiecte

De remarcat faptul ca un obiect poate include referiri explicite la un alt obiect, pe baza de OID (Object Identifications). Incluzand referiri in 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 (

Oras: string,




Strada: string,

Numar: integer),

Facultati:

set – of ( Facultati),

Biblioteci:

set – of ( Biblioteci))

Facultati:

record – of

(Denumire: string,

Nume-decan: string,

Oras: string

Sectii: set – of ( Seciti))

Sectii:

record – of

(Denumire: string,

Nr - studenti: integer),

Biblioteci:

record – of

(corp – cladire: string,

Profil: string,

Biblioteci: set – of ( Bibliotecari))

Bibliotecari:

record – of

(nume: string,

studii: string)

Fig. 7.5. Exemplu de definire implicand si referinte de obiecte

Un set de instante pentru definirile de mai sus, implicand si referintele la alte obiecte, apare astfel (fig. 7.6.):

<OID1,

[’ASE’, ’Barbulescu’, [’Bucuresti’,’Piata Romana’, ’6’], OID2, OID7]>

<OID2,

[’CSIE’, ’Bucuresti’, ]>

<OID3,

[’Informatica’, ’600’] >

<OID4,

[’Cibernetica’, ’500’] >

<OID5,

[’Statistitica’, ’500’] >

<OID6,

[’economie - matematica’, ’400’] >

<OID7,

>

<OID8,

[’Dorobanti - 2700’, ’Informatica’,

<OID9,

[’Dan’, ’superioare’] >

<OID10,

[’Vasile’, ’medii’] >

<OID11,

[’Eminescu’, ’Management’,

<OID12,

[’Barbu’, ’superioare’] >

<OID13,

[’Tudor’, ’medii’] >

Fig. 7.6. Exemplu de instanta in care apar si referiri

7.6.4.2. Clase de obiecte

Multitudinea obiectelor ce se bucura de aceleasi proprietati si comportament formeaza o clasa de obiecte.

Obiectele din cadrul unei clase constituie instantieri ai clasei respective. In UML o clasa se reprezinta printr-un dreptunghi cu trei compartimente separate prin linii orizontale: numele clasei in primul compartiment, lista de atribute in al doilea compartiment si lista de operatii in al treilea compartiment.

Diagrama claselor indica structura statica a modelului orientat obiect, surprinzand clasele componente si relatiile dintre acestea. In figura 7.7. sunt reprezentate clasele STUDENT si    CURS.

O diagrama de obiecte este un graf de instante compatibile cu o diagrama de clase data. Intr-o diagrama de obiecte, un obiect este reprezentat de un dreptunghi cu doua compartimente. Numele obiectului este dat sub forma nume obiect: nume clasa, unde nume obiect poate lipsi.



Fig. 7.7. Exemplu de clase

In figura 7.8. este reprezentata diagrama de obiecte asociata diagramei claselor de mai sus.

Fig. 7.8. Exemplu de instante

Clasele joaca acelasi rol in CODM (Conceptual Object Data Model) ca si relatiile in baze de date relationale (BRD). In modelul relational baza de date este formata dintr-un set de relatii si fiecare relatie include un set de tupluri iar in CODM o baza de date este formata dintr-un set de clase si fiecare clasa include un set de obiecte. Asadar in BDR putem avea o relatie numita STUDENT cu tupluri continand informatii despre fiecare student iar in CODM putem avea o clasa STUDENT cu obiecte continand informatii despre fiecare student. Intr-o astfel de situatie apare posibilitatea convertirii unei baze de date relationale intr-o baza de date orientata obiect cu atasarea unui OID fiecarui tuplu si invers.

O clasa are un tip, care descrie structura comuna a tuturor obiectelor ce fac parte din aceiasi clasa, si semnaturi de metode, care sunt declaratii de operatii ce pot fi aplicate clasei de obiecte. De remarcat faptul ca    numai semnaturile metodelor sunt parte a CODM, implementarile nu sunt. Implementarea unei metode este o procedura scrisa intr-un limbaj gazda, ce este memorata pe serverul bazei de date.

Multitudinea obiectelor ce apartin unei clase formeaza un set de obiecte si constituie extensia (extent) clasei. [Michael Kifer, Arthur, Datey].

Intr-un astfel de context, prin analogie, se poate spune ca o clasa are rolul de container de obiecte in / din care obiectele in mod dinamic pot fi adaugate sau sterse.

In limbajele de definire a datelor (DDL) ex. in O2 definirile tipurilor sunt incluse ca parte a definirilor claselor de obiecte.

In general, definirea unei clase este separata in doua parti, si anume, partea de interfata si partea de implementare.

interfata descrie tipul obiectelor apartinand clasei, care include semnaturilor tuturor metodelor. Fiecare semnatura contine denumirea si tipul fiecarui parametru a metodei. Parametrii de intrare / iesire in / din metoda fac posibila invocare metodei in cadrul programelor de aplicatii.

implementarea descrie implementarea metodelor adica, transpunerea operatiilor intr-un limbaj de programare.

Interfata descrie numai operatiile aplicabile asupra obiectelor in timp ce implementarea ascunde programul corespunzator operatiilor. De remarcat faptul ca unele SGDBOO ofera posibilitatea abaterii de la interpretarea stricta a incapsularii permitand accesul de date si prin alte forme / interfete si nu numai prin intermediul metodelor, de exemplu utilizand limbajul de cereri.

Din cele prezentate se poate desprinde ideea ca tipurile sunt abstractizari ce permit atat descrierea proprietatilor (starilor) cat si comportamentul, in timp ce clasele descriu atat partea extensionala a obiectelor cat si implementarea metodelor referitoare la un tip. Tipul descrie proprietatile abstracte in timp ce clasa descrie implementarea acelor proprietati abstracte utilizand structuri de date si programe.

Asa dupa cum s-a mai aratat si in paragrafele anterioare, unii autori de SGBDOO sau de carti folosesc cu precadere conceptul de clasa, altii conceptul de tip iar altii utilizeaza ambele concepte, ele fiind inrudite insa distincte. Paolo Atzeni, Stefano Ceri, Rcardo Torlone, Michael Kifer si Arthur Bernstein, se situeaza pe o astfel de pozitie [ ¼ ], precizand ca:

tipurile si clasele sunt concepte distincte;

fiecare clasa este asociata la un singur tip;

conceptul de clasa descrie atat implementarea cat si extensia unui tip;

clasele ajuta la organizarea obiectelor intr-o categorie.

In figura 7.9 se sugereaza relatiile intre clasa, tip, obiect, valori, extensie, intensie etc.

descriere / atribute

 

Fig. 7.9. Relatia intre clasa si tip

Din figura 7.9 se poate desprinde concluzia ca tipul, clasa, extensia si intensia sunt inrudite insa diferite ca notiuni si semnificatie. Fiecare obiect are valori, asociate unor atribute ce apartinand unui tip. Fiecare obiect apartine unei clase care are un tip.

In cele ce urmeaza vom exemplifica modul de descriere a claselor de obiecte ce includ si definirile de tipuri. In acest scop vom face referiri la clasele, tipurile si conceptele redate in figurile 7.3., 7.4., 7.6 folosind limbajul O2, astfel :

add class Universitate

type tuplu    (Denumire: string,

Nume – rector: string

Adresa: tuplu (Oras: string,

Strada: string,

Numar: integer)

Facultati: set – of ( Facultati),

Biblioteci: set – of ( Biblioteci))

add class Facultati

type tuplu    (Denumire: string,

Nume – decan: string

Oras: string

Sectii: set – of ( sectii)

add class Sectii

type tuplu    (Denumire: string,

Nr – studenti: integer)

add class Biblioteci

type tuplu    (Corp - cladire: string,

Profil: string,

Bibliotecari: set – of ( Bibliotecari))

add class Bibliotecari

type tuplu    (nume: string,

studii: string)

De remarcat faptul ca in O2 avem de a face, pe de o parte, cu schema bazei de date, care include definirea proprietatilor si metodelor claselor, iar pe de alta parte cu baza de date propriu-zisa ce include datele efective. In acest context prin comanda ' add ' se adauga o clasa la schema bazei de date, presupusa ca a fost declarata anterior.



loading...







Politica de confidentialitate

DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 723
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2019 . All rights reserved

Distribuie URL

Adauga cod HTML in site