MODELAREA DATELOR - Modele conceptuale de nivel inalt

MODELAREA DATELOR

Un model este o abstractizare a unui sistem, care capteaza cele mai importante trasaturi caracteristice ale sistemului (concepte), relevante din punct de vedere al scopului pentru care se defineste modelul respectiv. Tehnica de identificare a trasaturilor caracteristice esentiale ale unui sistem se numeste abstractizare.

Un model de date stabileste regulile de organizare si interpretare a unei colectii de date. In proiectarea bazelor de date se folosesc, de regula, mai multe modele de date, care se pot clasifica in doua categorii: modele conceptuale de nivel inalt si modele specializate.

Un model conceptual de nivel inalt al datelor contine o descriere concisa a colectiilor de date care modeleaza activitatea dorita (numita schema conceptuala de nivel inalt), fara sa detalieze modul de reprezentare sau de prelucrare a datelor.

Modelele specializate de date (cum sunt: modelul ierarhic, modelul retea, modelul relational, etc.) impun anumite structuri speciale de reprezentare a multimilor de entitati si a asocierilor dintre acestea, structuri pe baza carora sunt dezvoltate sistemele de gestiune a bazelor de date. Intr-un astfel de model de date, o baza de date este reprezentata printr-o schema logica (conceptuala) specifica. Trecerea de la modelul conceptual de nivel inalt la un model de date specific reprezinta etapa de proiectare logica a bazei de date care asigura corespondenta dintre schema conceptuala de nivel inalt a bazei de date si schema conceptuala specifica modelului de date respectiv.

1 Modele conceptuale de nivel inalt

Cel mai utilizat model conceptual de nivel inalt este modelul Entitate-Asociere (E-A) care reprezinta schema conceptuala de nivel inalt a bazei de date prin multimi de entitati si asocieri dintre acestea. Dezvoltarea acestui model, astfel incat sa permita extinderea tipurilor de entitati, este cunosuta sub numele de model Entitate-Asociere Extins (E-AE). Proiectarea modelului E-A sau al modelului E-AE este, de regula, una din primele etape in proiectarea bazelor de date, etapa numita proiectarea schemei conceptuale .

1.1 Modelul Entitate-Asociere

Modelul Entitate-Asociere (Entity-Relationship Model), introdus in 1976 de P.S. Chen, este un model conceptual de nivel inalt al unei baze de date, care defineste multimile de entitati si asocierile dintre ele, dar nu impune nici un mod specific de structurare si prelucrare (gestiune) a datelor.

Elementele esentiale ale modelului Entitate-Asociere folosit in proiectarea bazelor de date sunt entitatile (entities) si asocierile (relatiile) dintre acestea (relationships).

O entitate (entity) este "orice poate fi identificat in mod distinctiv'; o entitate se refera la un aspect al realitatii obiective care poate fi deosebit de restul universului si poate reprezenta un obiect fizic, o activitate, un concept, etc. Orice entitate este descrisa prin atributele sale.

Un atribut (attribute) este o proprietate care descrie un anumit aspect al unei entitati.

Atributele prin care este descrisa o entitate se aleg pe baza criteriului relevantei relativ la domeniul de interes pentru care se defineste modelul respectiv, astfel incat sa asigure diferentierea acelei entitati fata de restul universului.

Toate entitatile similare, care pot fi descrise prin aceleasi atribute, apartin unui acelasi tip de entitate (entity type), iar colectia tuturor entitatilor de acelasi tip dintr-o baza de date constituie o multime de entitati (entities set). In general, in modelul E-A se foloseste aceeasi denumire atat pentru un tip de entitate cat si pentru multimea entitatilor de acel tip.

De exemplu, tipul de entitate "angajat" (al unei institutii) reprezinta orice persoana angajata a institutiei, care are o anumita functie si primeste un anumit salariu. Acest tip de entitate poate fi descris prin mai multe atribute, dintre care o parte sunt atribute de identificare a persoanei (Nume,Prenume,DataNasterii,Adresa), iar altele sunt atribute legate de activitatea acesteia in institutia respectiva (Functie,Salariu).

Prin analogie cu modelul obiect, se poate spune ca un tip de entitate corespunde unei clase, o entitate este o instanta a unui tip de entitate si corespunde unui obiect, iar multimea entitatilor de un tip dat corespunde multimii obiectelor (instantelor) unei clase.

In proiectarea bazelor de date se considera doua categorii de entitati: entitati normale (puternice, obisnuite - regular entities) si entitati slabe (dependente - weak entities).

Entitatile normale au o existenta proprie in cadrul modelului, in timp ce entitatile slabe nu pot exista decat daca exista o entitate normala (puternica) cu care sunt asociate. De exemplu, o entitate "dependent" poate sa reprezinte o persoana care depinde de un angajat al unei institutii (adica se afla in intretinerea acestuia). O entitate "angajat" este o entitate puternica, deoarece ea exista in mod normal in modelul activitatii institutiei, in timp ce o entitate "dependent" este o entitate slaba: nu se va inregistra o astfel de persoana decat daca parintele (sustinatorul) acesteia este angajat in acea institutie.

In proiectarea bazelor de date se definesc asocieri intre multimile de entitati componente, pentru a reprezenta anumite aspecte ale realitatii pe care baza de date o modeleaza.

O asociere (relationship) este o corespondenta intre entitati din doua sau mai multe multimi de entitati.

Gradul unei asocieri este dat de numarul de multimi de entitati asociate. Asocierile pot fi binare (de gradul 2, intre 2 multimi de entitati) sau multiple (intre k multimi de entitati, k > 2).

Asocierile (relatiile) binare sunt, la randul lor, de mai multe categorii, dupa numarul elementelor din fiecare dintre cele doua multimi puse in corespondenta de asocierea respectiva (fig. 1.5).

Fiind date doua multimi de entitati, E₁ si E₂, se definesc urmatoarele categorii de asocieri binare:

Asocierea (relatia) de tip "unul-la-unul" (one-to-one) este asocierea prin care unui element (entitate) din multimea E₁ ii corespunde un singur element din multimea E₂, si reciproc; se noteaza cu 1:1.

Asocierea(relatia) de tip "unul-la-multe" (one-to-many) este asocierea prin care unui element din multimea E₁ ii corespund unul sau mai multe elemente din multimea E₂, dar unui element din E₂ ii corespunde un singur element in multimea E₁; se noteaza cu 1:N.

Asocierea "multe-la-multe" (many-to-many) este asocierea prin care unui element din multimea E₁ ii corespund unul sau mai multe elemente din multimea E₂ si reciproc; se noteaza cu M:N.

Cardinalitatea (multiplicitatea) unei asocieri fata de o multime de entitati (cardinality, multiplicity) este numarul maxim de elemente din acea multime care pot fi asociate cu un element din alta multime a asocierii.

De exemplu, asocierea 1:N dintre multimile E₁ si E₂ prezinta multiplicitatea 1 fata de multimea E₁ si multiplicitatea N (se intelege o valoare oarecare N > 1) fata de multimea E Raportul dintre valorile cardinalitatilor unei asocieri binare fata de cele doua multimi de entitati se numeste raport de cardinalitate (cardinality ratio). Se poate observa ca cele trei categorii de asocieri descrise mai sus difera intre ele prin raportul de cardinalitate.

Asocierile multiple (k-are, k > 2) prezinta cate un raport de cardinalitate pentru fiecare pereche de multimi de entitati pe care le asociaza.

O asociere intre doua sau mai multe multimi de entitati este, in acelasi timp, o asociere intre tipurile de entitati corespunzatoare.

Diagrama Entitate-Asociere (Entity-Relationship Diagram) reprezinta modelul Entitate-Asociere prin multimile de entitati si asocierile dintre acestea.

Exista numeroase variante de notatii pentru redarea diagramei E-A. Una dintre cele mai folosite notatii reprezinta un tip de entitate (precum si multimea de entitati de acel tip) printr-un dreptunghi, iar atributele tipului de entitate prin elipse conectate printr-o linie continua la acesta (fig. 1.6). Pentru entitatile puternice se utilizeaza un dreptunghi incadrat cu o linie simpla, iar pentru entitatile slabe se utilizeaza un dreptunghi incadrat cu linie dubla.

O asociere (tip de asociere) dintre doua sau mai multe tipuri de entitati se reprezinta printr-un romb conectat prin link-uri (linii continue, formate din unul sau mai multe segmente) la tipurile de entitati asociate. O asociere poate sa aiba sau nu un nume; daca are un nume, acesta poate fi inscris in rombul respectiv sau in vecinatatea acestuia. Categoria asocierii se noteaza prin inscrierea multiplicitatii pe fiecare link care conduce la un tip de entitate. Este posibil ca o asociere sa prezinte ea insasi atribute, si aceste atribute se reprezinta prin elipse conectate la asocierea respectiva.

Exemplul 1.1. In continuare se exemplifica dezvoltarea modelului conceptual de nivel inalt al unei baze de date a unei institutii si diagrama E-A corespunzatoare, definind cateva tipuri de entitati si asocierile intre acestea. Diagrama E-A a acestui mic model de baza de date este prezentata in figura. 1.7.

Tipul de entitate "sectie" reprezinta o unitate de organizare a institutiei si este un tip de entitate puternica (de sine statatoare). Acest tip se caracterizeaza prin mai multe atribute, de exemplu, un numar al sectiei, numele sectiei si bugetul alocat. Multimea de entitati care grupeaza toate entitatile de acest tip se poate denumi SECTIE sau SECTII (oricare varianta poate fi folosita) si este caracterizata prin aceleasi atribute care caracterizeaza tipul entitatii:

SECTIE(Numar,Nume,Buget)

Tipul de entitate "angajat" reprezinta o persoana angajata in institutie si este de asemenea un tip de entitate puternica. Acest tip de entitate, ca si multimea de entitati care grupeaza toate entitatile de acest tip, se poate defini astfel:

ANGAJAT(Nume,Prenume,DataNasterii,Adresa,Functie,Salariu)

Tipul de entitate "proiect" reprezinta o activitate a institutiei, si este de asemenea un tip de entitate puternica, care poate fi caracterizat prin numele proiectului, data inceperii, termen de realizare, bugetul proiectului:

PROIECT(Nume,DataInceperii,Termen,Buget)

Tipul de entitate "dependent" reprezinta o persoana care depinde de un angajat al institutiei (adica se afla in intretinerea acestuia). Acest tip de entitate este un tip de entitate slaba: nu se va inregistra o astfel de persoana decat daca intretinatorul acesteia este angajat in acea institutie. Acest tip se poate defini astfel:

DEPENDENT(Nume,Prenume,DataNasterii,GradRudenie)

Asocierea SECTIE-ANGAJAT este o asociere 1:N, daca se considera ca o sectie cuprinde mai multi angajati, iar un angajat apartine unei singure sectii.

Asocierea ANGAJAT-PROIECT este o asociere M:N, daca se considera ca la fiecare proiect lucreaza mai multi angajati, si fiecare angajat poate lucra la mai multe proiecte.

Asocierea ANGAJAT-DEPENDENT este o asociere de tipul 1:N, deoarece un angajat poate intretine mai multe persoane (fii, parinti etc.), iar o persoana dependenta este in intretinerea unui singur sustinator.

Raportul de cardinalitate al unei asocieri este stabilit de proiectant astfel incat sa reflecte cat mai corect modul de organizare a activitatii modelate. De exemplu, asocierea ANGAJATI-PROIECTE are raportul de cardinalitate M:N daca in institutia respectiva se admite ca un angajat sa lucreze la mai multe proiecte; daca s-ar impune ca un angajat sa lucreze la un singur proiect, atunci asocierea respectiva ar avea raportul de cardinalitate N:1. In ambele situatii se admite ca la un proiect lucreaza mai multi angajati.

Sunt de remarcat cateva caracteristici generale ale modelului E-A:

a) Modul de stabilire a tipurilor de entitati si a asocierilor dintre acestea nu este unic, deoarece granita dintre entitati si asocieri nu este, in general, una bine precizata. Aceeasi functionalitate se poate obtine printr-o varietate de diagrame E-A, depinzand de felul in care proiectantul dezvolta modelul conceptual. O asociere poate fi considerata si ca un tip de entitate. De exemplu, pentru baza de date a unei facultati (scoli) se definesc tipurile (multimile) de entitati:

STUDENTI (NUME, Prenume, Adresa,)

DISCIPLINE(Denumire,Credite,)

Intre aceste multimi de entitati se poate defini asocierea STUDENTI-DISCIPLINE, cu raportul de cardinalitate M:N. Aceasta asociere reprezinta (in general) studierea unor discipline de catre studenti, cu atribute ca: Nota (examenului la disciplina respectiva), DataExamen, etc. Dar, la fel de bine, este posibil sa se defineasca tipul de entitate NOTE, aflat in asociere N:1 cu fiecare din tipurile de entitati STUDENTI si DISCIPLINE (fig. 1.8).

b) In modelul E-A, tipul de entitate (si multimea de entitati corespunzatoare) semnifica un substantiv, in timp ce o asociere semnifica un verb. Bineinteles, nu este obligatoriu ca numele dat unei asocieri sa fie un verb (si, de cele mai multe ori, nici nu este), dar o asociere reprezinta o interactiune intre tipurile de entitati (si multimile de entitati corespunzatoare), care poate fi exprimata printr-un verb. De exemplu, in diagrama E-A din figura 1.7, asocierea SECTIE-ANGAJAT poate fi exprimata prin verbul cuprinde, asocierea ANGAJATI-DEPENDENTI poate fi exprimata prin verbul intretine, asocierea ANGAJATI-PROIECTE poate fi exprimata prin verbul lucreaza etc.

c) Modelul E-A nu precizeaza modul cum sunt realizate asocierile intre multimile de entitati. Acest aspect depinde de modelul de date specializat utilizat pentru definirea bazei de date. De exemplu, in modelele ierarhic si retea, asocierile sunt realizate explicit, prin pointeri de la o entitate la entitatile asociate, in timp ce in modelul relational asocierea se realizeaza prin egalitatea valorilor unor atribute comune ale entitatilor (chei).

1.2 Modelul Entitate-Asociere Extins

Modelul Entitate-Asociere Extins (Enhanced Entity-Relationship Model) permite definirea de subtipuri ale unui tip de entitati, care mostenesc atribute de la tipul de entitate pe care il extind (si care, in acest context, se numeste supertip) si au in plus atribute specifice semnificatiei lor. Prin definirea tipurilor si a subtipurilor de entitati se pot crea ierarhii de tipuri de entitati pe mai multe niveluri.

Modelul E-A prezentat in capitolul precedent este suficient pentru modelarea aplicatiilor de baze de date "traditionale", adica bazele de date utilizate pentru activitati financiare si industriale, in care se folosesc tipuri de date simple. Odata cu dezvoltarea sistemelor de baze de date, domeniile in care acestea se folosesc au devenit tot mai numeroase, ca, de exemplu: telecomunicatiile, proiectarea tehnologica, sistemele de informatii geografice, seviciul Web, etc. Tipurile de entitati definite in astfel de baze de date sunt mult mai complexe si pentru reprezentarea lor cat mai intuitiva si mai compacta au fost propuse mai multe concepte noi, care au fost introduse in modelul E-A extins.

Modelul E-A extins se reprezinta printr-o diagrama E-A extinsa. Ierarhiile de tipuri se pot crea prin specializare sau generalizare.

Specializarea (specialization) este un proces de abstractizare a datelor prin care, pornind de la un tip de entitate dat, se definesc unul sau mai multe subtipuri, diferentiate intre ele in functie de rolul specific pe care il au in modelul de date.

De exemplu, pornind de la tipul de entitate ANGAJAT se definesc prin specializare subtipurile SECRETARA, TEHNICIAN, INGINER, pentru a diferentia functiile pe care angajatii le pot avea in intreprinderea respectiva (fig. 1.9). Litera "d" din marcajul de specializare a tipurilor indica o constrangere de disjunctie impusa specializarii, care va fi descrisa mai jos.

Subtipurile de entitati mostenesc atribute ale tipului initial si fiecare dintre ele are atribute suplimentare, specifice rolului lor. De exemplu, atributele (Nume,Prenume,DataNasterii,Adresa,Salariu) ale tipului de entitate ANGAJAT sunt mostenite de fiecare din subtipurile acestuia. Atributul Functie nu este mostenit, deoarece specializarea subtipurilor s-a efectuat dupa acest atribut. Ca atribute specifice, subtipul SECRETARA are atributul VitezaRedactare, care este o masura a calificarii, subtipul TEHNICIAN are atributul Calificare, care reprezinta gradul de calificare, iar subtipul INGINER are atributul Specialitate, care este o precizare a domeniului in care lucreaza (mecanic, electric, etc.).

Generalizarea (generalization) este procesul de abstractizare invers specializarii, prin care se creaza un supertip de entitate pornind de la mai multe tipuri de entitati.

Pentru definirea unei generalizari, se identifica atributele comune ale mai multor tipuri de entitati si aceste atribute vor caracteriza supertipul de entitate, iar atributele care difera de acestea raman specifice fiecarui tip.

De exemplu, daca au fost definite tipurile de entitati:

AUTOMOBIL(NrInregistrare,Marca,VitezaMaxima,Pret,NumarPasageri)si CAMION(NrInregistrare,Marca,VitezaMaxima,Pret,Tonaj),se poate defini un supertip al acestor tipuri:

VEHICUL(NrInregistrare,Marca, VitezaMaxima,Pret).

Acest tip va cuprinde toate atributele comune, iar tipurile initiale, AUTOMOBIL si CAMION, devin subtipuri ale tipului VEHICUL, fiecare continand atributele specifice (NumarPasageri pentru tipul AUTOMOBIL si Tonaj pentru tipul CAMION).

Rezultatul obtinut prin generalizare este, ca si in cazul specializarii, o ierarhie de tipuri de entitati; ceea ce difera este modul in care se definesc nivelurile ierarhiei.

Mostenirea atributelor. Proprietatea principala a ierarhiilor de tipuri de entitati create prin specializare sau generalizare este mostenirea atributelor: atributele tipurilor de entitati de nivel ridicat (supertipuri) sunt mostenite de tipurile de entitati de nivel scazut (subtipuri).

Mostenirea dintre un subtip de entitati si supertipul acestuia se reprezinta in diagrama E-A extinsa printr-o legatura (link) intre subtip si supertipul de entitate corespunzator pe care este plasat un semicerc orientat catre subtip (asa cum se poate vedea in figura 1.9).

Este evidenta asemanarea dintre ierarhiile de tipuri de entitati din modelul E-A extins si ierarhiile de clase din modelul obiect-orientat, dar modelul E-A extins este un model de date mult mai general (de nivel inalt), care poate fi transpus in diferite modele de date specializate, inclusiv modelul obiect-orientat. Aceste transpuneri se fac in functie de suportul oferit de modelul specializat respectiv pentru reprezentarea entitatilor, asocierilor, mostenirilor, etc.

1.3 Modelul de date ierarhic

In modelul ierarhic (Hierarchical Model) o baza de date se reprezinta printr-o structura ierarhica de inregistrari de date (records) conectate prin legaturi (links).

Modelul de date ierarhic a fost primul model folosit pentru dezvoltarea bazelor de date. Cea mai cunoscuta realizare de SGBD ierarhic este sistemul IMS (Information Management System) dezvoltat de firma IBM in cadrul programului de cercetari Apollo, in perioada anilor 1960.

O inregistrare de date in modelul ierarhic este o instanta a unui tip de inregistrare (record type) si consta dintr-o colectie de campuri (fields), fiecare camp continand valoarea unui atribut. Un tip de inregistrare corespunde unui tip de entitate, iar o inregistrare corespunde unei entitati din modelul E-A.

Un tip de legatura in modelul ierarhic este un tip de asociere cu raportul de cardinalitate 1:N (de tip parinte-fiu) intre doua tipuri de inregistrari. Tipul de inregistrare din partea cu multiplicitatea 1 a asocierii este numit tip de inregistrare parinte, iar tipul din partea cu multiplicitatea N a asocierii este numit tip de inregistrare fiu.

Schema conceptuala a unei baze de date in modelul ierarhic se reprezinta printr-un numar oarecare de scheme ierarhice (fig. 1.12). O schema ierarhica este un arbore directionat, reprezentat pe mai multe niveluri, in care nodurile sunt tipurile de inregistrari, iar arcele sunt tipurile de legaturi. Fiecare nod (cu exceptia nodului radacina) are o singura legatura catre un nod de pe un nivel superior (nodul parinte) si fiecare nod (cu exceptia nodurilor frunza) are una sau mai multe legaturi catre noduri de pe nivelul imediat inferior (noduri fii).

Se poate stabili o corespondenta intre o schema conceptuala ierarhica si o diagrama E-A: tipurile de inregistrari corespund tipurilor de entitati, iar tipurile de legaturi corespund tipurilor de asocieri. (fig. 1.12, a si b).

In modelul ierarhic nu sunt admise decat legaturi de tipul parinte-fiu, care corespund asocierilor 1:1 si asocierilor 1:N din modelul E-A. Asocierile M:N din modelul E-A nu se pot reprezenta in mod direct in modelul ierarhic, ci numai prin multiplicarea inregistrarilor de tip fiu, atunci cand sunt referite de mai multe inregistrari de tip parinte. Acest lucru conduce la o mare redundanta a datelor.

Corespunzator schemei ierarhice a unei baze de date se pot reprezenta mai multi arbori de instantiere a datelor, care sunt, de asemenea, arbori directionati (fig. 1.12, c). Fiecare arbore de instantiere contine ierarhii pe mai multe niveluri de inregistrari intre care exista legaturi de tipul parinte-fiu.

Corespunzator schemei ierarhice a unei baze de date se pot reprezenta mai multi arbori de instantiere a datelor, care sunt, de asemenea, arbori directionati (fig. 1.12, c). Fiecare arbore de instantiere contine ierarhii pe mai multe niveluri de inregistrari intre care exista legaturi de tipul parinte-fiu.

Avantajele modelul ierarhic sunt simplitatea si eficienta de calcul, dar in momentul de fata, pentru realizarea bazelor de date sunt preferate modele de date mai puternice (modelul relational, modelul obiect-orientat).

1.4 Modelul de date retea

Modelul retea (Network Model) foloseste o structura de graf pentru definirea schemei conceptuale a bazei de date; nodurile grafului sunt tipuri de entitati (inregistrari - records), iar muchiile grafului reprezinta in mod explicit asocierile (legaturile-links) dintre tipurile de entitati.

Aparut dupa modelul ierarhic, modelul retea de reprezentare a bazelor de date a fost standardizat in 1971, de o comisie DBTG (Database Task Group). Modelul retea a avut mai multe implementari ca sisteme de gestiune comerciale: IDS II (Honeywell), UNISYS (Burroughs), IDMS (Computer Associates).

Deosebirea fata de modelul ierarhic consta in aceea ca in modelul retea asocierile M:N se reprezinta fara duplicarea inregistrarilor, fiecare inregistrare putand fi referita de mai multe inregistrari, ceea ce elimina redundanta.

La fel ca si la modelul ierarhic, dezavantajul principal al modelului retea este acela ca fiecare interogare trebuie sa fie prevazuta inca din faza de proiectare, prin memorarea explicita a legaturilor intre tipurile de entitati. In plus, complexitatea reprezentarii datelor in modelul retea este deosebit de ridicata, iar programatorii trebuie sa o cunoasca pentru a putea realiza aplicatiile necesare.

In momentul de fata modelul de date retea este foarte rar utilizat pentru baze de date de uz general (care implica operatii de interogare), dar exista unele domenii in care structurarea ca graf a datelor permite o parcurgere eficienta a acestora. De exemplu, majoritatea bazelor de date grafice folosite in modelarea scenelor tridimensionale din realitatea virtuala sunt baze de date retea.

1.5 Modelul de date relational

Modelul relational (Relational Model) se bazeaza pe notiunea de relatie (relation) din matematica, care corespunde unei multimi de entitati de acelasi tip.

Modelul de date relational a fost propus de cercetatorul E.F. Codd de la compania IBM, care a publicat in anul 1970 lucrarea 'Un model Relational de Date pentru Banci Mari de Date Partajate'. Alte lucrari ale lui Codd, ca si ale altor cercetatori (C.J. Date, P. Chen, R. Boyce, J.D. Ullman, R. Fagin, W.W. Armstrong, M. Stonebraker, etc.) au perfectionat modelul de date relational si au permis dezvoltarea fara precedent a sistemelor de gestiune a bazelor de date, datorita simplitatii si a fundamentarii matematice a modelului.

Primul Sistem de Gestiune a Bazelor de Date Relationale (SGBDR) a fost prototipul System R, dezvoltat la compania IBM in anii 1970, dupa care numeroase companii au realizat sisteme de gestiune relationale (Oracle, Microsoft, Ingres, Sybase, etc.) iar aplicatiile de baze de date relationale au capatat o amploare deosebita.

Pe langa avantajul unui model de date precis si simplu, sistemele de baze de date relationale mai beneficiaza si de un limbaj de programare unanim recunoscut si acceptat, limbajul SQL (Structured Query Language), pentru care au fost emise mai multe standarde de catre ISO (International Standardization Office). Majoritatea SGBD-urilor relationale actuale implementeaza versiunea SQL92 (sau SQL2).

Modelul relational constituie efectul tendintei de generalizare-dezvoltare a relatiilor din cadrul bazei de date. Modelul relational se bazeaza pe o multime interconectata de relatii definite in cadrul uneia sau mai multor colectii de date (relatii n-are). Structura conceptuala a modelului de date relational este formulata printr-o multime de tabele (liste sau fisiere) intre care exista o asociere logica. Asocierea se realizeaza prin asa numitele chei de legatura care constituie, totodata, calea de acces la inregistrarile subcolectiilor. Din punct de vedere fizic, subcolectiile de date sunt constituite din articole logice, inregistrate pe un suport tehnic de date.

1.5.1 Concepte utilizate de modelul relational

Conceptele utilizate in modelul relational sunt determinate de principiul fundamental al acestui model: tabelul bidimensional format din randuri si coloane. Aceste concepte sunt: inregistrarea (tuplul), campul (atributul, caracteristica), realizarea (instanta), domeniul, gradul, cardinalitatea, cheia.

Pentru a ilustra sinoptic elementele termonologiei utilizate de un model relational, consideram un exemplu de tabel (fig. 1).

Inregistrarea este definita ca fiind un rand din tabel.

Campul este dat de numele (antetul) unei coloane si exprima semnificatia valorilor coloanei.

Realizarea este o valoare luata de un camp din structura tabelului.

Domeniul este dat de multimea valorilor luate de un camp sau mai multe campuri (proprietati).

Gradul defineste numarul de coloane dintr-un tabel.

Cardinalitatea este data de numarul de inregistrari (rinduri) din tabel.

Cheia este definita de un camp sau mai multe cimpuri ale caror valori identifica inregistrarea.

In functie de rolul pe care il detin in cadrul tabelului, cheile sunt proiectate astfel (vezi tabelul 2):

►    Cheia primara (principala): este acel camp prin a carui realizare se poate identifica in mod unic o anumita inregistrare din cadrul unui tabel. In tabelul din figura 2 cheia primara o constituie codul beneficiarului (codbenef) pentru tabelul BENEFICIARI, numarul de comanda (nrcda) pentru tabelul COMENZI, codul produsului (codprod) pentru tabelul PRODUSE.

►    Cheia secundara: este reprezentata printr-unul sau mai multe campuri prin a caror realizare se identifica apartenenta mai multor inregistrari la o colectie de date. Cheia secundara permite identificarea tuturor inregistrarilor care au proprietati identice. De exemplu, cheie secundara ar putea fi codul beneficiarului (codbenef)  in tabelul COMENZI, oferind posibilitatea de returnare a comenzilor care apartin aceluiasi beneficiar.

►    Cheia externa: acel cimp prin a carui realizare se poate stabili asocierea logica cu alte tabele. Cheia externa poate fi, totodata, cheie primara sau cheie secundara intr-un alt tabel. Revenind la exemplul de tabel din fig. 2, cheile externe ale tabelului COMENZI sunt codbenef (prin care se obtine relatia logica cu tabelul BENEFICIARI) si codprod (prin care se obtine relatia logica cu tabelul PRODUSE).

►    Cheie candidat: unul sau mai multe campuri care ofera identificarea unei inregistrari. De exemplu, campul nume din tabelul BENEFICIARI (fig. 2) poate constitui o cheie candidat pentru identificarea unui anumit beneficiar.

1.5. Cerintele modelului relational

Cerintele esentiale ale modelului relational pot fi rezumate prin notiunile de "relatie", "atomizare", "sortare" si "restrictii (reguli) de integritate".

Modelul relational este reprezentat prin tabele bidimensionale. Relatiile sunt constituite in cadrul si intre tabelele bazei de date. Aceasta inseamna ca relatia constituie cerinta de baza a modelului relational, baza de date fiind un ansamblu de date intre care exista totdeauna o interdependenta logica (un ansamblu de relatii).

Reluand exemplul din fig. 2 si tinand cont de conceptul cheilor primare si externe, relatiile din cadrul unei asemenea baze de date sunt:

a). relatii stabilite in interiorul fiecarui tabel, prin conceptul entitatii ca unitate de observare; totalitatea atributelor care formeaza o inregistrare constituie relatia intrinseca a tabelului.

b). relatii stabilite intre tabele - ca relatii de asociere a elementelor componente ale unei entitati mai vaste (baza de date in intregul sau).

In concluzie principiul relatiei presupune relatia logica de inregistrare si relatia logica intre tabele.

In figura 3 se reprezinta posibilitatea de asociere a tabelelor prin valoarea (realizarea) cheilor externe.

Figura 3

Prin cele ilustrate in figura 3 se intelege faptul ca accesand tabela COMENZI pot fi exploatate si datele logic-inrudite din tabelele BENEFICIARI si/sau PRODUSE. Aceasta posibilitate este garantata prin unicitatea valorica a cheilor primare in cadrul fiecarui tabel.

Unicitatea valorica a cheii primare in cadrul tabelului impune evitarea redundantelor, adica a repetarii valorii unei inregistrari in cadrul altor inregistrari din cadrul aceluiati tabel. Ca cerinta a modelului relational, atomizarea inseamna nerepetarea unei relatii in cadrul bazei de date.

Inregistrarea trebuie sa fie atomica. Fiecare inregistrare trebuie sa fie distincta fata de toate celelalte inregistrari din cadrul tabelului din care face parte. Literatura de specialitate defineste aceasta cerinta a modelului relational drept atomizarea relatiilor. Atomizarea se obtine prin cheia principala a tebelului. Cheia principala este deci acel atribut care individualizeaza o inregistrare din cadrul multimii acestora, in cadrul unui tabel.

Nota: Nu trebuie confundata structura tabelului cu cerinta de atomizare a tuplurilor. Structura tabelului este aceeasi pentru toate inregistrarile (ordinea campurilor in cadrul inregistrarii). Realizarile (valorile) inregistrate in cadrul campurilor difera, insa, de la un tuplu la altul. Chiar daca am considera identitatea valorica a unor atribute in cadrul a doua sau mai multe inregistrari, inregistrarile difera, cel putin prin cheia principala a inregistrarii.

De exemplu:

nrcda codbenef codprod cantitate ....

11223 88 414 580 ....

11224 88 414 580 ...

O alta cerinta a modelului relational o constituie posibilitatea de sortare a inregistrarilor. Modelul relational, ca atare, nu cere o ordine predefinita a efectuarii inregistrarilor. Introducerea inregistrarilor in tabele nu impune o anumita ordine in functie de valoarea sau dimensiunea cimpurilor. Daca, ulterior, se va dori o sortare anume a inregistrarilor, in ordinea crescatoare a valorii unor campuri (de obicei a cimpurilor cheilor primare, secundare sau candidat) procedeul este deosebit de simplu.

Cerinta posibilitatilor de ordonare a inregistrarilor in cadrul tabelului este impusa prin sistem, in cazul nedeclararii cheii primare (principale) in procesul de constituire a tabelelor. Astfel, atunci  cand proiectantul bazei de date nu a impus o cheie principala, sistemul impune o cheie-tabelara, in ordinea numerelor naturale a inregistrarilor, ca un camp distinct fata de cele proiectate.

Avand in vedere cerintele modelului relational analizate anterior, acest model isi impune asa numitele reguli (restrictii) de integritate:

a). Denumirea tabelelor in cazul bazei de date si a domeniilor in cadrul tabelului trebuie sa fie diferite;

b). Cheia principala este obligatorie pentru oricare tabel. Ca integritate a relatiei de inregistrare, campul destinat cheii principale nu poate fi nul si nu poate fi egal cu cheia principala a altei inregistrari;

c). Cheile externe trebuie sa fie egale cu realizarea unui camp din tabelele asociate, ca relatie intre tabele. In situatia unor tabele neasociate (cazuri foarte rare in conceptia bazelor de date), nu este necesara definirea unor asemenea chei;

d). Domeniul este format din valori de acelasi tip (tip numeric, tip sir-caractere, tip data calendaristica, etc.). Nu este admisa combinarea acestor tipuri, caz in care sistemul va considera un asemenea camp drept sir-de-caractere.

e). Fiecare inregistrare constituie un ansamblu de campuri cu cel putin o realizare diferita de celelalte inregistrari.

Exista si unele restrictii particulare, impuse de utilizator, in functie de aplicatie. De exemplu data pensionarii sa nu fie anterioara datei angajarii, etc.

1.5.3 Elementele modelului relational

Elementele modelului relational sunt acelea care formuleaza relatia intrinseca a tabelelor si prin care se obtine relatia de interconectare a acestora, precum si operatorii care asociaza relatiile elementare in vederea unor relatii noi, prin care sa se asigure informarea utilizatorilor (cererile formulate de acestia).

Avand in vedere cerintele modelului relational, proiectantul bazei de date trebuie sa structureze datele elementare la nivelul fiecarui tabel si sa formuleze posibilitati de comunicare intre tabele.

Reluand exemplele din figurile 2 si 3, structurarea datelor la nivelul tabelelor este prezentata in cele care urmeaza, exemplificare in care cheile principale sunt marcate cu caractere ingrosate.

tabela BENEFICIARI

codbenef, nume, adresa, contbanca ..

tabela COMENZI

nrcda, codbenef, codprod, cantitate, datalivrarii....

tabela PRODUSE

codprod, denumire, um, pretlivrare....

Pe baza acestor structuri se prezinta schema relatiei, conform figurii 4

Proiectantul bazei de date poate impune anumite reguli de integritate particulare ca restrictii de integritate a datelor in cadrul tabelelor.

De exemplu:

pentru tabela BENEFICIARI:

- niciunul dintre campuri sa nu fie vid (valoare nula);

Pentru tabela COMENZI:

niciunul dintre campuri sa nu fie vid (valoare nula);

datalivrarii sa nu fie anterioara datei curente;

pentru tabela PRODUSE:

niciunul dintre campuri sa nu fie vid (valoare nula);

pretlivrare sa nu fie mai mare decat eventualul pret de achizitie sau cost de fabricatie, etc.

Operatorii prin care se asociaza datele din cadrul tabelelor unei baze de date sunt denumiti operatori relationali si sunt destinati satisfacerii cererilor avansate de catre utilizatorul final, cu structuri rezultate ale prelucrarilor. Acesti operatori sunt definiti ca elemente ale algebrei relationale.

Literatura de specialitate grupeaza operatorii relationali in operatori de baza, operatori unari si operatori de extensie:

Operatorii de baza sunt: reuniunea, produsul cartezian, intersectia si diferenta. Efectul aplicarii acestor operatori consta in obtinerea unei terte relatii din doua relatii sursa.

Operatorii de extensie sunt: compunerea si diferenta. Caracteristica acestor operatori este asemanatoare reuniunii si diferentei, procesand la nivelul structurilor intersectate.

Operatorii unari se refera la: proiectie si selectie. Caracteristica acestor operatori este obtinerea unei relatii derivate dintr-o singura relatie-sursa.

Avand in vedere varietatea fenomenelor economice care se cer stocate sub forma unor diverse structuri de date, este necesara interventia operatorilor algebrici pentru obtinerea unor relatii necesare constituirii bazei de date.

Pentru a elimina confuziile posibile, generate de efectul procedural al operatorilor relationali, stabilim ca pot exista:

Relatii (tabele) cu aceeasi structura, dar cu inregistrari suplimentare una fata de alte relatii;

Relatii cu structuri diferite, adica domenii neidentice si neintersectate;

Relatii (tabele) cu structuri intersectate, adica parte din domenii ale unei relatii se regasesc in cealalta relatie.

Reuniunea: obtine o relatie noua (RN) din doua relatii primare (R1 si R2), care:

au aceeasi structura;

au inregistrari diferite;

insumeaza relatiile.

Produsul cartezian: obtineo relatie noua (RN) din doua relatii primare (R1 si R2), care:

au structuri diferite, adica domenii diferite;

au inregistrari diferite;

multiplica relatiile.

Intersecția: obtineo relatie noua (RN) din doua relatii primare (R1 si R2), care:

au aceeasi structura;

au inregistrari diferite;

preia in terța relatie numai inregistrarile comune din R1 si R

Diferența: obtineo relatie noua (RN) din doua relatii primare (R1 si R2), care:

au aceeasi structura;

au inregistrari diferite;

preia in terța relatie numai inregistrarile care nu se confunda cu cele din relatia asociata.

Compunerea: obtineo relatie noua (RN) din doua relatii primare (R1 si R2), care:

au structuri intersectate;

insumeaza domeniile si realizarile inregistrarilor.

Divizarea: obtineo relatie noua (RN) din doua relatii primare (R1 si R2), care:

au structuri intersectate;

elimina domeniile comune din R1 si R

Proiectia: obtine o relatie noua (RN) dintr-o singura relatie sursa (RS) prin care conform unui criteriu de selectie, se valideaza anumite domenii, excluzandu-se altele:

Selectia: obtine o relatie noua (RN) dintr-o singura relatie sursa (RS) prin care conform unui criteriu de selectie, se valideaza anumite domenii, care indeplinesc (sau nu indeplinesc) anumite criterii de filtrare a datelor.

De exemplu a1< 500

d7 = 100000 ...etc.

1.5.4 Normalizarea relatiilor

Armonizand conceptele modelului relational cu cerintele impuse de acest model si avand in vedere posibilitatile oferite de de operatorii relationali, se impune procesul de normalizare a relatiilor.

Scopul normalizarii relatiilor este un sumum de reguli, printre care:

sa fie asigurata posibilitatea de compunere a relatiilor in vederea raspunsului la cererile avansate de catre utilizatorul final;

sa nu fie impietate principiile de atomizare a relatiilor;

sa excluda redundanta relatiilor;

sa asigure coerenta logica de asociere a datelor.

Utilizatorii finali solicita liste de informare cu un grad mai mare sau mai mic de complexitate in asocierea datelor (vezi exemplul din figura 5).

Datele incluse in lista exemplificata in figura 5 sunt o relatie normalizata, in sensul ca exista posibilitatea ca articolele incluse in asemenea lista:

sa repete acelasi produs contractat cu mai multi beneficiari;

sa repete acelasi beneficiar care a contractat mai multe produse prin mai multe contracte.

Dar, pe de alta parte, o asemenea lista de iesire trebuie sa fie posibil de realizat prin compunerea datelor din cadrul relatiilor care formeaza baza de date.

Se considera utile trei forme de normalizare a relatiilor, prin care sa fie satisfacut scopul acestui proces de proiectare a bazei de date: FN1, FN2, FN3.

In principiu, procedura de normalizare a relatiilor consta in descompunerea formularilor complexe de relatii in relatii elementare.

FN1 realizeaza forma de baza a cerintelor modelului relational, prin care:

nu sunt admise atribute compuse, de tipul:

se exclude repetarea atributelor compuse, prin formularea unei relatii distincte si atomice;

se stabileste o cheie primara pentru fiecare relatie.

Dar aceasta solutie nu este corecta, deoarece in relatiile intertabelare nu exista chei externe. De aceea, cu riscul unei minime redundante la nivelul ansamblului de relatii din cadrul bazei de date, sunt necesare urmatoarele structuri (vezi figurile 6 si 7):

Aceasta formula se inscrie in FN1 si asigura relatiile externe, conform figurii 6.

La nivelul FN1 se poate constata urmatoarea imperfectiune: un contract cu un beneficiar poate sa includa mai multe produse contractate cu acel beneficiar, ceea ce impieteaza asupra unicitatii relatiilor. FN2 presupune existenta in FN1, in plus eliminarea dependentei uor atribute fata de cheia relatiei din FN1.

In conditiile descompunerii ilustrate in figura 8 relatia CONTRACT poate admite multiplicarea articolelor privind un produs la nivelul mai multor contracte si/sau mai multe contracte la nivelul unui beneficiar.

FN2 restrictioneaza astfel de posibilitati prin redistribuirea relatiilor in forme restranse. In figura 9 este prezentat modelul FN2 fata de relatia definita initial CONTRACT.

Totusi, FN2 pastreaza o dependenta tranzitiva a relatiilor, in sensul ca atributul BANCA poate avea multiplicari de relatii: un beneficiar poate avea conturi deschise la mai multe banci. Cum rezolvam problema? Trecem la a treia forma de normalizare FN3.

FN3 implica existenta relatiilor in FN1 si FN2, in plus faptul ca atributele care nu constituie cheia relatiei sa nu fie dependente de aceasta cheie.

Fata de exemplele precedente, FN3 presupune disocierea relatiilor care implica dependenta tranzitiva. In cazul in care un beneficiar are conturi deschise la mai multe banci, relatia FN2 (fig. 9) este redistribuita conform figurii 10.

Practica proiectarii bazelor de date admite normalizari in functie de situatie. Astfel, atunci cand nu este periclitata coerenta logica a relatiilor, nu este neaparat disocierea fortata a relatiilor.

1.6 Modelul de date obiect

Modelul obiect (Object Model) este un concept unificator in stiinta calculatoarelor, fiind aplicabil in programare, in proiectarea hardware-ului, a interfetelor, a bazelor de date, etc. Sistemele de baze de date obiect se bazeaza pe limbaje de programare orientate obiect cu capacitati de persistenta, in care datele sunt independente de timpul de viata al programelor care le creeaza, prin memorare pe suport magnetic (disc).

Oricat de folositor este modelul de date relational pentru realizarea bazelor de date, exista unele domenii (in special acele domenii in care se manevreaza tipuri de date complexe), in care modelul relational s-a dovedit a fi insuficient de expresiv si cu performante de executie reduse. Domenii ca: proiectarea asistata de calculator, sisteme de informatii geografice, medicina (si altele) au impulsionat cercetari pentru gasirea unor modele mai performante, dintre care modelul obiect-orientat si modelul obiect-relational au cunoscut si cunosc in continuare o dezvoltare semnificativa.

Dintre avantajele cele mai importante ale sistemelor de baze de date dezvoltate in modelul obiect se evidentiaza capacitatea acestora de a defini si manevra tipuri de date complexe (clase), care se pot extinde prin mecanismul de mostenire, ceea ce contribuie la cresterea performantelor in aplicatiile de baze de date avansate.

Exista, bineinteles, si dezavantaje ale sistemelor de baze de date obiect-orientate, care le fac sa aiba o utilizare limitata, mult mai redusa decat cea a sistemelor de baze de date relationale (sub 5% din piata sistemelor de baze de date). Principalul dezavantaj il constitue complexitatea de dezvoltare a bazei de date si a aplicatiilor, datorita faptului ca proiectantii si programatorii trebuie sa prevada in structura obiectelor toate asocierile (legaturile) necesare tuturor interogarilor. Cu cat interogarile sunt mai complexe, cu atat sunt necesare mai multe asocieri intre obiecte si deci se complica structura acestora. La acest dezavantaj se adauga si altele, cum ar fi lipsa unui standard de limbaj de interogare care sa fie unanim (sau cat mai larg) acceptat.

1.6.1 Conceptele modelului obiect

In esenta ei, baza de date este un sistem complex de date si relatii intre acestea.

Notiunea de sistem este definita, uneori, drept "un set de obiecte interconectate".

Sistemul este o entitate. Elementele sale structurale sunt ele insele entitati. Asadar, obiectele sunt entitati incorporate in cadrul unui sistem. Sistemul isi poate mentine si perpetua identitatea sa particulara printr-o stare de echilibru. Starea de echilibru a sistemului impune compatibilitatea relatiilor care se stabilesc intre subsistemele componente, adica intre obiectele constitutive. Starea generala a sistemului depinde de starea particulara a obiectelor, de comportamentul acestora.

Obiectul devine, astfel, unitatea de observare in conducerea unui sistem.

Modelul-obiect (denumit uneori model orientat-obiect) are la baza urmatoarele concepte:

obiect;

abstractizare;

incapsulare;

mostenire;

polimorfism.

Obiectul se caracterizeaza prin structura si interfata si este inmatriculat printr-o anumita identitate.

Structura consta in componenta elementelor constitutive. In cazul modelului-obiect, elementele constitutive ale obiectului sunt atributele (caracteristicile) acestuia.

De exemplu:

PRODUSE

- COD

- DENUMIRE

- UM

Interfata este fateta de prezentare a obiectului; este ceea ce reprezinta obiectul in exteriorul structurii sale. Prin interfata se poate patrunde in compozitia intima a obiectului. De exemplu, interfata unui tuplu poate fi reprezentata prin cheia sa principala. In principiu, interfata unui obiect este constituita din procedurile care se pot aplica elementelor sale structurale.

Identitatea obiectului este formalizata printr-o denumire si printr-o adresa logica. Prin identitate, un obiect al bazei de date este personalizat in mod distinct fata de celelalte obiecte. De exemplu, denumirea unei tabele.

Abstractizarea se refera la posibilitatea de generare a unor tipuri de date si care apartin unor asa-numite clase. Clasa este o abstractizare a datelor. Inscrierea unor date reale in modelul clasei conduce la realizarea instantelor de clasa, adica la un anumit tip de date elementare sau complexe.

Clasa este un model de reprezentare a obiectelor cu aceleasi caracteristici si comportament. Modelul este ideal, in sensul ca el exista prin reguli proprii de comportament, dar poate sa nu fie real, in sensul ca poate sa fie vid, adica sa nu cuprinda obiecte. Atunci cand se creeaza un obiect care respecta caracteristicile unei clase, obiectul devine o instantiere a clasei.

Avand in vedere caracteristicile comune si regulile de comportament ale obiectelor, exemplificam formularele: Structura acestui model conceptual este: antet, detalii, subsol. Exista posibilitati cum ar fi: antet cu detalii, detalii cu subsol, numai detalii. Asemenea modele derivate constituie subclase.

Subclasa are aceleasi reguli de comportament, ca metode ale clasei.

In figura 11. este prezentata compozitia functionala a claselor de obiecte, ca schema de principiu.

Abstractizarea, ca model al clasei de obiecte, implica notiunile de stare si comportament.

Starea obiectului consta in valorile reale care sunt atribuite caracteristicilor de structura.

De exemplu:

PRODUSE

- COD = 1234

- DENUMIRE = COOLER

- UM = BUC

Fiecare atribut are un nume si o anumita valoare asociata ca variabila de instanta. Variabila de instanta este o anumita compozitie a caracteristicilor obiectului la un moment dat. Variabilele de instanta definesc proprietatile obiectului.

Comportamentul defineste asa-numitele metode posibil de administrat obiectului. Metodele includ ansamblul de proceduri adresate atributelor unui obiect. Comportamentul vizeaza modul in care un obiect reactioneaza fata de o cerere care ii este adresata din exterior. Ansamblul raspunsurilor la asemenea mesaje constituie comportamentul obiectului.

De exemplu:

produse.Close

Raspunsul la acest mesaj va fi suprimarea accesului (Close) la datele din tabela cu identificatorul produse.

Metodele pot fi atasate si unei comenzi.

De exemplu:

DoCmd.OpenTable "produse", acViewDesign, acAdd

Raspunsul la acest mesaj va fi deschiderea tabelei cu identificatorul produse (OpenTable "produse"), in format de (re)proiectare (acViewDesign), in vederea adaugarii (acAdd).

Mesajul DoCmd solicita executarea unei comenzi. Metoda poate fi diferita si/sau poate fi transmisa asupra diversitatii obiectelor care compun baza de date. Metoda transmite obiectului cererea executarii unei anume actiuni.

Incapsularea poate fi considerata ermetizarea caracteristicilor proprii unui obiect fata de alte obiecte interconectate in sistem.

Structura unui obiect constituie o relatie interna, intima, protejata fata de mediul exterior. Structura si valorile caracteristicilor unui obiect nu pot fi cunoscute si nici modificate din exteriorul acestuia.

Si, totusi, obiectele - ca subsisteme ale bazelor de date - comunica prin mesaje. Ermetizarea caracteristicilor obiectelor poate fi sparta prin metode.

De exemplu:

DoCmd.OpenTable

Pe de alta parte, fiecare tip de obiect are metodele sale. Nu se poate aplica o anumita metoda la toate obiectele care formeaza o baza de date.

De exemplu, metoda OpenTable nu poate fi utilizata in cazul formularelor, al rapoartelor etc.

Metodele obiectului realizeaza accesul utilizatorului la variabilele de instanta ale obiectului.

Atunci cand se creeaza un obiect, el este inclus intr-o clasa de obiecte cu un anume comportament.

Metoda declanseaza o anumita procedura comportamentala a obiectului.

Procedurile sunt aplicate obiectului prin interfata acestuia.

Prin intermediul interfetei pot fi testate variabilele de instanta ale elementelor structurale. Structura este protejata.

Protectia structurii este relevata si prin imaginea din figura 11.

Sintaxa de adresare la un obiect apartinand unei anumite clase/subclase, in vederea selectarii acelui obiect prin proprietatile sale este:

clasa![subclasa!]obiect.proprietate

De exemplu:

Forms!formularX!filtru.Value = 5

In acest caz, se face apelul clasei/subclasei formulare (Forms), prin care se solicita obiectul formularX, a carui variabila de instanta filtru are valoarea 5. Variabilele structurale ale obiectului sunt testate, fara a fi afectate. Structura este, deci, incapsulata.

Prin faptul ca obiectul constituie o entitate care se poate crea, utiliza si distruge, este inevitabila si procedura de eliminare a obiectelor din sistemul bazei de date.

Mostenirea este conceptul prin care subclasa imprumuta atributele si metodele clasei din care face parte. Mostenirea nu exclude posibilitatea ca subclasele sa adauge alte atribute la cele mostenite din clasa. Subclasa devine, astfel, o instanta a clasei, iar obiectele pe care le cuprinde sunt instante ale subclasei.

Metodele pot fi suplimentate in functie de atributele adaugate subclaselor.

In figura 1 este reprezentat exemplul unei structuri, prin care se poate demonstra mostenirea elementelor de structura.

Mostenirea implica transmitere elementelor structurale ale clasei in subclase si de la acestea la diversele instantieri de subclasa.

De exemplu, subclasa PRODUSFINIT sau subclasa SEMIFABRICAT vor implica realizarile din SECTIE si VALOAREPROD. Tot astfel, instanta CARACTERISTICI implica pe cele din subclasa PRODUSFINIT.

Prin conceptul mostenirii, accesand instanta CARACTERISTICI, se vor putea returna toate valorile elementelor structurale din PRODUSFINIT si PRODUCTIE.

Prin exemplul din figura 1 se evidentiaza faptul ca subclasele si cele derivate din acestea pot adauga atribute fata de structura clasei de origine.

In mod implicit, metodele aplicate subclaselor se multiplica, in functie de elementele structurale suplimentare sau diferite. De exemplu, daca se utilizeaza ca metoda actualizeaza, aceasta se va referi distinct in subclasele PRODUSFINIT, respectiv SEMIFABRICAT, fata de atributele pretlivrare, respectiv costprod.

In concluzie, mostenirea se adreseaza unei ierarhii de clasa, conform cu figura 13.

Polimorfismul consta in efectul diferit pe care poate sa-l genereze un mesaj asupra unei clase (considerand intreaga ierarhie a acesteia).

De exemplu, recurgand la structura prezentata in figura 12, prin cererea de a sterge codul 12345, va fi eliminat numai produsul cu acest cod.

Dar daca se va cere stergerea (aceeasi metoda) produsului cu pretul de livrare 1534,00 vor fi eliminate toate produsele care au acest pret de livrare.

In concluzie, o anumita metoda particulara unei clase poate avea efecte diferite in subclase, in functie de parametrii care sunt specificati.

1.7.1 Trecerea de la modelul obiect la modelul obiect-relational

Intre modelul obiect si cel relational exista o similitudine conceptuala.

Modelul obiect isi propune focalizarea actiunilor asupra obiectelor. Modelul relational isi propune actionarea prin relatii. Daca vom considera tuplul - ca notiune a modelului relational - drept obiect - ca unitate de observare in modelul orientat-obiect, atunci:

cheile primare ale tabelelor sunt identificatorii de obiect;

caracteristicile (atributele) unui tuplu sunt variabile de instanta;

relatiile dintre tabelele bazei de date sunt mesajele de comunicare intre obiecte;

categoriile de obiecte relationale sunt clasele de obiecte, fiecare element component fiind o instanta de clasa.

Ne propunem, in continuare, sa relevam particularitatile simbiotice intre modelul de reprezentare relational si modelul obiect, rezultand modelul obiect-relational.

Modelul relational este, actualmente, cel mai utilizat in proiectarea bazelor de date.

Modelul obiect-relational este destinat sa imbogateasca modelul relational cu sistemul conceptelor modelului-obiect.

Conceptul de abstractizare a datelor sta la baza conceperii tabelelor. Tabelele raman relatia fundamentala si reala a modelului, dar sunt supuse unei tipologii abstracte. Tipul abstract de date poate constitui un model de clasa pentru definirea structurii unei categorii de tabele care pot avea aceleasi reguli de comportament.

Tipurile abstracte de date sunt abreviate, in literatura de specialitate, prin TAD. Un TAD este conceput de proiectant in functie de ceea ce isi doreste utilizatorul drept comportament al obiectului fata de solicitarile pe care i le va adresa.

Tabela isi pastreaza tipurile de date cunoscute (numeric, sir-de-caractere, data-calendaristica etc.), in timp ce TAD-ul reprezinta o structura generalizata pentru mai multe instante tabelare.

De exemplu: Tabela Productie, cu atributele:

- cod (numeric)

- denumire (sir-de-caractere)

- um (sir-caractere)

poate raspunde solicitarilor de returnare a realizarilor, ca variabile de instanta, atat pentru cazul produselor finite, cat si pentru cazul semifabricatelor. Aspectul comportamental al celor doua cazuri este identic.

Tipul abstract de date se poate realiza in:

. tabela PRODUSFINIT       . tabela SEMIFABRICAT

- cod                                       - cod

- denumire                            - denumire

- um                                        - um

continand, suplimentar:

- pretlivrare                           - costproductie

Cazul exemplificat demonstreaza, pe de alta parte, adoptia conceptului mostenirii in modelul obiect relational (fig. 14.).

Modelul obiect-relational admite includerea altor relatii de tip abstract sau colectie de date (set de inregistrari).

De exemplu, avand ca TAD tipul VANZARI cu structura cod, pretvanzare, campul cod refera la un alt TAD: Productie (fig. 15.).

In mod similar, pot fi incluse si seturile de inregistrari.

Atunci cand un TAD contine un alt TAD sau o colectie - set de inregistrari, acel TAD incapsuleaza celelalte structuri de date.

Trecerea de la modelul obiect la modelul obiect-relational implica pe de o parte simbioza intre conceptele modelului-obiect si relatiile dintre tabele iar, pe de alta parte, utilizarea unor limbaje specializate.

Relatiile dintre tabelele bazei de date, ca model relational, devin relatii complexe intre tipurile abstracte de date, care admit mostenirea structurilor si comportamentului.

Conform celor ilustrate in figura 15, se observa elementul relational, ca legatura intre cheile tabelei VANZARI si PRODUCTIE si, pe de alta parte, relatiile TAD intre PRODUCTIE, PRODUSFINIT si SEMIFABRICAT. Asemenea relatii implica, in principal, mostenirea si incapsularea.

Limbajul utilizat in domeniul sistemelor de gestiune a bazelor de date obiect-relational este PL/SQL (Procedural Language/Structured Query Language).

1.7 Modelul de date obiect-relational

Modelul obiect-relational (Object-Relational Model) reprezinta extinderea modelului relational cu caracteristici ale modelului obiect, extindere necesara pentru realizarea bazelor de date care definesc si prelucreaza tipuri de date complexe.

In esenta, modelul obiect-relational pastreaza structurarea datelor in relatii (reprezentate ca tabele), dar adauga posibilitatea definirii unor noi tipuri de date, pentru domeniile de valori ale atributelor. Tipurile de date definite de utilizator pot fi extinse prin mecanismul de mostenire si pentru fiecare tip sau subtip se pot defini metode pe care le pot executa obiectele de acel tip.

In general, dezvoltarea sistemelor de gestiune a bazelor de date obiect-relationale (SGBDOR) se realizeaza prin extinderea sistemelor relationale, de cele mai multe ori in mod gradat, adaugandu-se de la o versiune la alta cat mai multe caracteristici posibile ale modelului obiect si pastrand in continuare toate caracteristicile modelului relational.

O astfel de abordare asigura rularea in continuare a aplicatiilor relationale existente in noile versiuni de sisteme SGBDOR, ceea ce permite producatorilor sa-si pastreze clientii si domeniile de utilizare. Mai multi dintre principalii producatori de sisteme de gestiune (Oracle, Informix si IBM) au extins in acest mod sistemele lor relationale pentru a deveni sisteme obiect-relationale. Este o tendinta fireasca, dat fiind ca prin aceasta se pastreaza toata experienta si rezultatele obtinute cu sistemele relationale si se pot dezvolta si aplicatii complexe, obiect-relationale.

Standardele limbajelor de programare pentru sistemele de gestiune obiect-relationale sunt extensii ale standardului SQL (ca de exemplu, versiunea din anul 1999, denumita SQL3).

1.8 Complexitatea datelor si a interogarilor

M. Stonebraker a oferit o reprezentare in patru cadrane a universului bazelor de date (fig. 1.13) deosebit de simpla si de interesanta, bazata numai pe complexitatea datelor si a interogarilor. Propusa in anul 1996, aceasta clasificare nu include modelele prerelationale (modelul ierarhic si modelul retea), considerate depasite in aceasta faza de dezvoltare a bazelor de date.

Pe abscisa diagramei este reprezentata capacitatea de definire a tipurilor de date complexe, iar pe ordonata este reprezentata capacitatea de interogare a bazelor de date.

In cadranul din stanga jos sunt acele aplicatii care prelucreaza tipuri de date simple si nu necesita interogarea datelor. Astfel de tipuri de aplicatii (cum sunt procesoarele de texte - Word, Framemaker) folosesc direct sistemul de fisiere al sistemului de operare pentru memorarea datelor persistente.

In cadranul din stanga sus sunt sistemele de gestiune a bazelor de date relationale (SGBDR), care prelucreaza tipuri simple de date, dar permit interogari complexe.

In cadranul din dreapta jos sunt sistemele de gestiune a bazelor de date obiect-orientate (SGBDOO), care prelucreaza tipuri de date complexe, dar in care rezolvarea interogarilor este destul de dificila, dat fiind ca pentru fiecare interogare trebuie sa fie prevazute legaturile necesare in structura obiectelor.

In cadranul din dreapta sus sunt reprezentate sistemele obiect-relationale (SGBDOR), care permit prelucrarea datelor complexe si rezolvarea interogarilor complexe. Modelul obiect-relational este, evident, cel mai complet, deoarece admite atat tipuri de date definite de utilizator cat si interogari complexe. In aceeasi lucrare, Stonebraker denumeste sistemele de gestiune a bazelor de date obiect-relationale ca fiind sisteme de baze de date universale.

In momentul de fata este evidenta tendinta producatorilor de sisteme de gestiune a bazelor de date de a trece la sisteme obiect-relationale si, in general, aceasta trecere se realizeaza prin adaugarea treptata a caracteristicilor modelului obiect in sistemele de gestiune relationale. Oferta de sisteme de gestiune a bazelor de date este deosebit de generoasa, pe o scara extinsa de performante si costuri, de la sisteme care se pot folosi gratuit (fara licenta sau cu licenta publica), pana la sisteme cu inalte performante, a caror utilizare necesita plata licentelor respective. Chiar si pentru astfel de sisteme exista versiuni de test (trial versions) care pot fi obtinute gratuit prin Internet (de la adrese care sunt indicate in Bibliografie), astfel incat pot fi folosite pentru a intelege si a executa exemplele propuse in aceasta lucrare.

Sistemul Oracle este un sistem de gestiune a bazelor de date multi-utilizator puternic, cu implementari pe toate platformele (Windows, Unix, Linux), care ofera atat performante de executie ridicate, cat si un grad inalt de protectie si securitate a datelor. In toate versiunile, Oracle ofera implementarea completa a caracteristicilor modelului relational (conform standardului SQL2), iar ultimele versiuni (Oracle8i, Oracle9i si Oracle 10g) sunt sisteme de gestiune obiect-relationale distribuite, implementand extensiile obiect-orientate prevazute in standardul SQL3 si oferind posibilitatea de dezvoltare a bazelor de date distribuite. Sistemele de gestiune Oracle, ca si diferite instrumente de dezvoltare a aplicatiilor de baze de date (Oracle Application Server, JDeveloper, Oracle Forms etc.), se pot obtine de la adresa http://www.oracle.com si termenii licentei permit utilizarea acestor sisteme in scopuri necomerciale pe o perioada nelimitata; pentru utilizarea in scopuri comerciale trebuie sa fie platite licentele corespunzatoare

SQL Server este sistemul de gestiune a bazelor de date relationale dezvoltat de firma Microsoft pentru sistemele de operare Windows. Au existat mai multe versiuni, versiunea actuala (2007) fiind SQL Server 2005. In toate versiunile sistemul SQL Server suporta complet standardul SQL2, cu implementarea performanta a trasaturilor avansate de stocare si prelucrare a datelor (integritate referentiala, subinterogari, triggere, gestiunea tranzactiilor, etc). De la adresa http://www.microsoft.com/sql se poate obtine gratuit o versiune de test a sistemului SQL Server sau se poate cumpara o versiune completa. In plus, pachetul de dezvoltare .NET SDK (.NET Software Development Kit), care se poate obtine gratuit de la adresa http://msdn.microsoft.com/downloads contine o versiune mai simpla de server de baze de date numit Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) care poate fi folosita pentru dezvoltarea si executia exemplelor prezentate in lucrare.

Microsoft Access este unul din cele mai cunoscute sisteme de gestiune a bazelor de date relationale pe platforme de calculatoare personale. MS Access dispune de un sistem de control al bazei de date (database engine) si o interfata grafica pentru interactiunea cu utilizatorul. Aplicatiile de baze de date in MS Access se pot dezvolta cu multa usurinta datorita generatoarelor de aplicatii (Wizards) care permit proiectarea vizuala a bazelor de date si a formularelor (forms) pentru interfetele grafice. MS Access este folosit in special pentru aplicatii personale sau pentru mici afaceri si licenta acestuia se poate cumpara odata cu licenta produsului Microsoft Office.

MySQL este un sistem de gestiune a bazelor de date relationale cu implementari pentru sistemele de operare Windows, Linux, Unix. La adresa http://www.mysql.com se gaseste ultima versiune si documentatia sistemului de gestiune a bazelor de date MySQL care se poate utiliza gratuit (este open source). Acest sistem este compatibil cu standardul SQL2, dar unele prevederi ale standardului sunt implementate partial. Versiunea actuala 2007) este versiunea 5.0 care ofera vederi, proceduri stocate, triggere (caracteristici care lipseau in versiunile precedente).