Sunteți pe pagina 1din 119

UNIVERSITATEA “ŞTEFAN CEL MARE” SUCEAVA

FACULTATEA DE ŞTIINŢE ECONOMICE ŞI ADMINISTRAŢIE PUBLICĂ

BAZE DE DATE ŞI SISTEME INFORMAŢIONALE PENTRU AFACERI INTERNAŢIONALE

Curs Master Semestrul I

2011 - 2012

Program de studiu Economie şi Afaceri Internaţionale

1

Conf. univ. dr. Nicolae Morariu I. BAZE DE DATE

Capitolul 1

1.1. Organizarea şi gestionarea datelor în memoria externă

Datele rezultă din observaţii şi măsurători efectuate asupra lumii reale şi au un grad redus de abstractizare. Prin interpretarea datelor de către un anumit subiect se obţin informaţii care pot fi utilizate de către acesta în luarea deciziilor. Aceleaşi date pot fi interpretate în mod diferit de către subiecţi diferiţi şi deci pot genera informaţii diferite. După unii autori, datele reprezintă ceea ce este efectiv stocat pe suporturile de memorare, iar informaţia reprezintă semnificaţia acestor date pentru un anumit utilizator [DATE04]. În acest context se poate menţiona că sistemele de calcul prelucrează date şi nu informaţii. Cunoştinţele cuprind atât fapte ce reprezintă lucruri adevărate despre lumea reală, cât şi proceduri de raţionament care permit urmărirea raţionamentului între fapte. Diferenţa existentã între cunoştinţe şi date este ilustrată de E. Feigenbaum, un nume de referinţã în inteligenţa artificialã, prin urmãtorul exemplu [FLAM02]:

un medic care trateazã un pacient foloseşte cunoştinţe şi date. Datele sunt reprezentate de fişa pacientului: simptome, boli anterioare, tratament prescris, reacţie la tratament, etc. Cunoştinţele utilizate în tratarea pacientului reprezintã tot ceea ce medicul a învãţat în facultate şi în decursul întregii lui cariere prin practicã, studiu, experienţã, în legãturã cu modul de vindecare a bolii. Aceste cunoştinţe se referã la fapte, teorii, tratament şi, cel mai important, la cunoştinţe euristice. Astfel, cunoştinţele necesitã şi includ utilizarea datelor dar sunt mai mult decât acestea. Pentru luarea deciziilor corecte omul modern utilizează cunoaşterea acumulată în timp şi informaţiile rezultate din interpretarea datelor. În vederea obţinerii informaţiilor necesare luării de decizii corecte omul din societatea modernă se confruntă cu necesitatea prelucrării unui volum imens de date care trebuiesc culese, organizate şi stocate pe suporturi externe de memorare, apoi actualizate în permanenţă, regăsite şi prelucrate în timp util. Utilizarea sistemelor de calcul în vederea realizării dezideratelor mai sus menţionate presupune un anumit mod de organizare a datelor. Principalele metode de organizare a datelor pe suporturile externe de memorare sunt fişierul şi baza de date.

1.1.1. Concepte fundamentale în organizarea datelor

Se definesc următoarele concepte:

1. Data elementară, câmp elementar - este o dată care nu mai poate fi descompusă; Exemplu: nume (nume persoană din descrierea unui grup de persoane)

2. Data grupată, câmp grupat – este o grupare logică de date; Exemplu: - adresa:

- localitate

- strada

- număr;

3. Înregistrarea logică sau articolul – o colecţie de date ce descriu un acelaşi obiect;

4. Înregistrarea fizică sau pagina - unitatea de transfer între

memoria externă şi

şi poate conţine una sau mai multe înregistrări logice, nefiind

memoria internă

2

însă exclusă nici situaţia în care o înregistrare logică mare se poate întinde pe mai multe pagini. 5. Fişierul – un ansamblu de înregistrări logice

Fişierul – este o organizare a datelor preluată din sistemul manual şi adaptată la cerinţele impuse de utilizarea sistemelor de calcul. Un fişier poate fi privit din două puncte de vedere şi anume:

- la nivel logic, fişierul este un ansamblu de înregistrări logice sau articole ce reprezintă o clasă de obiecte definită printr-un set de proprietăţi;

- la nivel fizic, având în vedere modul în care sunt înregistrate datele pe suportul extern, fişierul este un ansamblu de înregistrări fizice (pagini).

Moduri de organizare a fişierelor:

- fişiere secvenţiale datele sunt înregistrate secvenţial pe suportul de memorare şi

pot fi consultate secvenţial (pentru a regăsi o înregistrare se parcurge fişierul de la început până la înregistrarea în cauză);

- fişiere secvenţial indexate - înregistrările sunt ordonate după valorile unui câmp

numit cheie de indexare (unu sau mai multe câmpuri ale înregistrării). Înregistrările pot fi accesate fie secvenţial fie direct pe o înregistrare de cheie dată. În afara datelor

propriu-zise fişierul mai conţine tabele de index care memorează corespondenţa între cheile înregistrărilor şi adresele fizice pe suportul de memorare (disc);

- fişiere în acces direct - înregistrările sunt stocate în pagini a căror adresă este

calculată cu ajutorul unei funcţii numită funcţie hash pe baza unuia sau mai multor câmpuri din înregistrare. Organizarea datelor în fişiere prezintă următoarele deficienţe:

- datele sunt izolate în fişiere separate, programele de aplicaţie trebuie să realizeze sincronizarea prelucrării a două sau mai multor fişiere;

- dependenţa de date - fiecare program de aplicaţie trebuie să descrie datele pe care le utilizează şi prin urmare, modificări în structura datelor necesită modificări în programe;

- formate de fişiere incompatibile - structura fişierelor fiind încorporată în programul

de

aplicaţie, este dependentă de limbajul în care este scrisă aplicaţia;

- nu este asigurat accesul concurent la date;

- aceleaşi date pot apare în fişiere diferite (redundanţa datelor);

- nu este asigurată protecţia şi securitatea datelor.

Aceste deficienţe se datorează următoarelor cauze:

1) – definiţia datelor este încorporată în programele de aplicaţie în loc să fie stocată separat şi independent; 2) – nu există un control privind accesul şi manipularea datelor în afara celuia impus de aplicaţie. O altă etapă o constituie trecerea de la organizarea datelor în fişiere specifice fiecărei aplicaţii la definirea şi utilizarea fişierelor integrate care reprezintă un ansamblu de fişiere definite plecând de la legăturile logice existente între date şi care sunt utilizate în comun de către mai multe aplicaţii. Principalul obiectiv urmărit la definirea fişierelor integrate este eliminarea redundanţei datelor. Un salt calitativ net superior are loc odată cu trecerea la un nou mod de organizare a datelor prin definirea conceptului de bază de date având în vedere eliminarea tuturor deficienţelor semnalate în organizarea datelor în fişiere. Baza de date este o colecţie partajată de date, care conţine datele propriu- zise, relaţiile logice dintre acestea, precum şi descrierea datelor (structura datelor).

3

O bază de date poate fi privită [COBS01] ca un depozit de date unic, definit o singură dată pentru a satisface necesităţile informaţionale ale unei organizaţii şi care poate fi utilizat simultan de către mai multe departamente şi utilizatori. O definiţie mai precisă, având în vedere noţiunea de persistenţă, este dată de C. J. Date [DATE04] astfel:

Baza de date este o colecţie de date persistente, care sunt folosite de către sistemele de aplicaţii ale unei organizaţii. Pe lângă datele operaţionale propriuzise, baza de date conţine şi descrierea datelor şi a legăturilor dintre acestea (structura datelor inclusiv constrângerile de integritate) cunoscută sub denumirea de catalog sau dicţionar de date sau meta-date (datele despre date). Dicţionarul de date mai poate conţine [ORA92] şi alte informaţii cum ar fi cele privind utilizatorii şi drepturile de acces, definiţiile unor interogări (vederile), indexuri şi structuri de stocare utilizate, etc. Memorarea dicţionarului de date în baza de date asigură independenţa programelor de datele pe care le prelucrează. În aplicaţiile de baze de date se urmăreşte stocarea unor volume mari de date pe suporturi externe de memorare adresabile, care să poată fi regăsite şi prelucrate în timp util de către utilizatori concurenţi cu vederi diferite asupra datelor, accentul fiind pus pe operaţiile de regăsire şi mai puţin pe operaţii complexe de prelucrare. De aceea, baza de date este după [DORO98] o formă de organizare centralizată a datelor asemănătoare organizării bibliotecilor tradiţionale. În cele ce urmează sunt prezentate o serie de concepte definite în domeniul bazelor de date.

1.1.2. Arhitectura unei baze de date

Organizarea datelor în baze de date impune adoptarea unei arhitecturi în care pot fi identificate următoarele 3 nivele de abstractizare [DORO98] (3 nivele distincte la care pot fi descrise datele) şi anume: nivelul extern (subschema, vedere), nivelul conceptual (schema conceptuală), nivelul intern. Schema generală a unei baze de date în contextul unei arhitecturi ANSI-SPARC pe cele 3 nivele este reprezentată în figura 1.1.

Utilizator 1 Utilizator 2 ……… Utilizator n … Nivel Subschema 1 Subschema 2 … Subschema
Utilizator 1
Utilizator 2
………
Utilizator n
Nivel
Subschema 1
Subschema 2
Subschema n
extern
(Vedere 1)
(Vedere 2)
(Vedere n)
Sistemul de Operare
(SO)
Schema
Nivel
Conceptuală
conceptual
Sistemul de
Gestiune a
Bazelor de Date
(SGBD)
Nivel
intern
Baza de date
fizică

Fig.1.1 Schema generală a unei baze de date

4

Nivelul extern reprezintă vederea utilizatorului asupra bazei de date (subschema, schema externă). Fiecare utilizator are o vedere asupra bazei de date, care include numai entităţile, atributele şi relaţiile din lumea reală de care este interesat utilizatorul respectiv. Utilizatori diferiţi pot avea vederi diferite asupra aceloraşi date (exemplu data calendaristică poate fi văzută de un utilizator sub forma an/lună/zi, iar de un alt utilizator sub forma zi/lună/an). În vederi pot fi incluse şi date derivate sau calculate din datele stocate în baza de date (ex. vârsta, plecând de la data naşterii şi data curentă). Nivelul conceptual – vederea generală a bazei de date. La acest nivel este reprezentată structura logică a întregii baze de date aşa cum este văzută de administratorul bazei de date (spre exemplu sunt definite concepte de tipul :

Angajaţi, Servicii, Produse, Beneficiari, Furnizori, precum şi relaţiile existente între aceste concepte, constrângeri de integritate, etc.). Nivelul intern – corespunde reprezentării fizice a datelor în baza de date. La acest nivel, baza de date este o colecţie de fişiere conţinând datele şi legăturile dintre acestea, la care se adaugă diverse structuri auxiliare (indecşi, pointeri, tabele de dispersie etc.) pentru asigurarea accesului operativ la date. Transformarea de la nivelul conceptual la nivelul intern şi invers se realizează prin comunicarea dintre SGBD şi sistemul de operare. Orice comunicare între nivele se realizează sub controlul SGBD. Adoptarea arhitecturii pe cele 3 nivele asigură independenţa logică şi fizică a datelor. Independenţa logică a datelor asigură independenţa schemelor externe (vederilor utilizatorilor) faţă de modificări efectuate în schema conceptuală. Adăugarea sau eliminarea de noi entităţi, atribute sau relaţii trebuie să fie posibilă fără a afecta schemele externe existente. Independenţa fizică a datelor asigură independenţa schemei conceptuale faţă de modificările efectuate în structura internă de memorare a datelor. Modificări efectuate în schema internă cum ar fi utilizarea unor organizări de fişiere diferite, a unor dispozitive diferite de stocare, modificarea de indecşi sau de algoritmi hash, trebuie să fie posibilă fără a fi necesară schimbarea schemei conceptuale sau a schemelor externe şi reciproc.

1.1.3. Sistemul de gestiune a bazelor de date (SGBD)

Sistemul de gestiune a bazelor de date referit prescurtat SGBD sau DBMS (Data Base Management System) este un sistem de programe care permite definirea, crearea şi întreţinerea bazei de date, precum şi accesul controlat la baza de date. Un SGBD oferă următoarele facilităţi pentru crearea şi exploatarea bazelor de date:

- facilităţi de descriere a datelor, prin intermediul unui limbaj de descriere a datelor DDL (Data Description Language) care permite utilizatorului să descrie structurile de date ce vor fi memorate în baza de date;

- facilităţi de manipulare a datelor, prin intermediul unui limbaj de manipulare a datelor DML (Data Manipulation Language) care permite utilizatorului să insereze, actualizeze, şteargă, să prelucreze şi să extragă date din baza de date;

- controlul accesului la baza de date prin intermediul unui limbaj de control DCL (Data Control Language) care asigură:

- sistem de securitate, previne accesarea bazei de date de către utilizatori

neautorizaţi;

- sistem de integritate, menţine concordanţa datelor stocate în baza de date;

- sistem de control al concurenţei, permite accesul partajat la baza de date;

5

- sistem de control al refacerii, permite recuperarea bazei de date în urma unor defecţiuni hard sau soft;

- mecanism de vizualizare, prin care un utilizator poate vedea acea parte a bazei de date care îl interesează. În majoritatea produselor comerciale de baze de date , cele trei limbaje se regăsesc reunite în cadrul unui singur limbaj (spre exemplu limbajul SQL).

1.1.4. Administratorul bazei de date

Administratorul bazei de date referit prescurtat DBA (Data Base Administrator), este o persoană sau un grup de persoane care coordonează şi răspunde de ansamblul activităţilor privind baza de date, începând din faza de proiectare şi continuând cu celelalte etape pe întreaga perioadă de viaţă a bazei de date. Astfel, în faza de proiectare a bazei de date, administratorul stabileşte SGBD-ul ce va fi utilizat, echipamentele necesare, structurile de date plecând de la necesităţile de informaţie ale tuturor utilizatorilor bazei de date, drepturile de acces la date ale fiecărui utilizator. Rezultatul fazei de proiectare este concretizat prin elaborarea modelului conceptual (schema generală a bazei de date), modelului extern (subschema proprie fiecărui utilizator) şi stabilirea modalităţilor de reprezentare a structurilor de date la nivel fizic pe suporturile de memorare externe utilizate. Drepturile de acces la baza de date pot fi definite [ORA92] fie pentru fiecare utilizator în parte, fie pentru grupuri de utilizatori (denumite Role), fiecare utilizator fiind apoi asignat unui grup. După proiectarea bazei de date, administratorul va menţine permanent legătura cu utilizatorii acesteia pentru rezolvarea cerinţelor utilizatorilor şi impunerea unei discipline în vederea alinierii la standardele existente. Administratorul va realiza, ori de câte ori se impune, reorganizarea structurii fizice a datelor în vederea optimizării parametrilor de funcţionare a întregului sistem şi va stabili proceduri de arhivare a datelor şi proceduri de recuperare a bazei de date la avarii şi defecte. Pentru a preveni accesul neautorizat la date, în cadrul sistemului de securitate pot fi prevăzute [DATE04] şi alte mecanisme şi anume: evidenţa de auditare, criptarea datelor. Evidenţa de auditare constă dintr-un fişier în care sistemul înregistrează automat toate operaţiile efectuate asupra datelor, fişier ce va putea fi consultat de către persoane autorizate pentru a verifica efectuarea unor operaţii neautorizate. O înregistrare din evidenţa de auditare va conţine următoarele informaţii: textul sursă al operaţiei neautorizate, terminalul de la care a fost lansată operaţia, utilizatorul care a lansat operaţia, data şi ora operării, obiectele bazei de date afectate, imaginile datelor afectate înainte de efectuarea operaţiei, imaginile datelor afectate după efectuarea operaţiei. Pentru a preveni accesul unor intruşi la baza de date, care încearcă să ocolească sistemul, se utilizează criptarea datelor, mecanism ce constă în stocarea şi transmiterea datelor pe căile de comunicaţie sub formă cifrată. Criptarea se realizează cu ajutorul unor algoritmi de criptare printre care cel mai recent este standardul american de criptare avansat AES (Advanced Encryption Standard).

1.1.5. Gestiunea tranzacţiilor şi controlul concurenţei

Tranzacţia este unitatea logică de prelucrare constând dintr-o secvenţă de operaţii efectuate asupra bazei de date de către un singur utilizator astfel încât să fie asigurată consistenţa şi siguranţa bazei de date. Consistenţa constă în respectarea tuturor constrângerilor de integritate definite asupra datelor, iar siguranţa constă în rezistenţa la defecte şi capacitatea de recuperare din avarii. O bază de date trebuie

6

să fie consistentă atât înaintea cât şi după execuţia unei tranzacţii, însă în timpul execuţiei tranzacţiei pot apare situaţii în care baza se află temporar într-o stare inconsistentă. O tranzacţie poate consta din execuţia uneia sau mai multor comenzi (instrucţiuni ale unui limbaj de programare) asupra bazei de date. Pentru a defini (delimita) explicit o tranzacţie, unele limbaje pentru baze de date (spre exemplu SQL) conţin instrucţiunile BEGIN TRANSACTION şi END TRANSACTION, iar pentru acceptarea (validarea) respectiv anularea (abortarea) tranzacţiei, instrucţiunile COMMIT respectiv ROLLBACK. Raportat la conceptul de tranzacţie, execuţia unui program sau aplicaţii poate reprezenta execuţia uneia sau mai multor tranzacţii. Se subliniază faptul că toate acţiunile efectuate asupra bazei de date în cadrul unei tranzacţii vor fi operate efectiv în baza de date numai după validarea tranzacţiei (execuţia instrucţiunii COMMIT), ceea ce înseamnă că operaţiile unei tranzacţii sau sunt executate în totalitate , sau întreaga tranzacţie este anulată (abortată), deci execuţia unei tranzacţii se bazează pe principiul “ori totul, ori nimic”. Dacă în cadrul unui program, tranzacţiile nu sunt delimitate, întregul program este considerat o tranzacţie şi SGBD-ul execută automat o instrucţiune COMMIT dacă programul s-a terminat normal, sau o instrucţiune ROLLBACK dacă programul s-a terminat anormal. O tranzacţie trebuie (Haerder şi Reuter, 1983) să satisfacă următoarele proprietăţi cunoscute în literatura de specialitate [DORO98], [COBS01], [DATE04] sub acronimul ACID:

- Atomicitatea – tranzacţia este indivizibilă (ori este efectuată în totalitate, ori nu este efectuată deloc);

- Consistenţa (Coerenţa) – tranzacţia trebuie să transforme baza de date dintr-o stare consistentă în altă stare consistentă;

- Izolarea – modificările efectuate de o tranzacţie sunt inaccesibile altei tranzacţii concurente până în momentul validării acesteia;

- Durabilitatea – după validarea unei tranzacţii, rezultatele acesteia devin permanente şi vor fi operate în baza de date chiar dacă în timpul scrierii în baza de date apare un incident care împiedică înregistrarea rezultatelor tranzacţiei, acestea vor fi operate în baza de date după reluarea activităţii. Pentru bazele de date accesate simultan de către mai mulţi utilizatori, se pune problema rezolvării situaţiilor de conflict care pot apare datorită accesului concurent la aceleaşi date. Dacă baza de date este accesată doar în citire de către utilizatorii concurenţi, atunci rezolvarea problemei privind accesul concurent se realizează prin secvenţializarea accesului utilizatorilor de către sistemul de operare care stabileşte ordinea de satisfacere a cererilor de acces având în vedere minimizarea timpului total de satisfacere a cererilor. Sistemele de operare care conţin mecanisme ce pot trata independent operaţiile de intrare/ieşire concomitent cu efectuarea altor operaţii de către unitatea centrală de prelucrare, permit executarea simultană a două sau mai multor tranzacţii. Însă dacă doi sau mai mulţi utilizatori concurenţi accesează simultan baza de date, iar unul dintre ei actualizează date care ar putea fi accesate de alţi utilizatori, pot apare interferenţe ce pot conduce la incoerenţe. Două tranzacţii T1, T2 pot conduce la interferenţe dacă rezultatul execuţiei lor secvenţiale diferă de rezultatul execuţiei lor concurente. Astfel de tranzacţii concurente şi care pot conduce la interferenţă sunt numite conflictuale. Pentru evitarea situaţiilor de conflict, în cadrul sistemelor SGBD se utilizează următoarele două metode:

- controlul concurenţei prin blocare;

- controlul concurenţei prin mărci de timp.

7

Pentru controlul concurenţei prin blocare, sistemele SGBD dispun de două funcţii primitive şi anume LOCK() şi UNLOCK(), sau de un mecanism de zăvorâre, care utilizate pentru o tranzacţie T prin intermediul componentei lock manager realizează blocarea respectiv deblocarea accesului altor tranzacţii la elemente

(unităţi de acces) din baza de date utilizate de tranzacţia T. Unităţile de acces sunt elemente ale bazei de date care pot constitui obiectul unei operaţii de blocare în timpul execuţiei tranzacţiei. O problemă sensibilă care poate apare prin mecanismul de blocare este interblocarea sau impasul, care apare în situaţia în care o tranzacţie T1 este blocată

de o altă tranzacţie T2 care la rândul său este blocată de tranzacţia T1, astfel încât

nici una din tranzacţii nu îşi poate continua execuţia. O astfel de situaţie nu poate fi rezolvată decât fie printr-o intervenţie din exterior, fie printr-un modul software special realizat în acest sens. O atenţie deosebită în sistemele concurente trebuie acordată prevenirii interblocărilor, care poate fi realizată prin impunerea unor condiţii pe care

trebuie să le satisfacă tranzacţiile, caz în care se introduc restricţii la resurse fapt ce poate conduce la scăderea nivelului de concurenţă al sistemului. Astfel, în locul metodelor de prevenire a interblocării se pune problema utilizării unor metode de evitare a interblocării prin utilizarea mărcilor de timp asociate tranzacţiilor prin care se stabileşte o ordine de prioritate pentru lansarea tranzacţiilor în execuţie şi evitarea interblocărilor prin abortarea tranzacţiilor după ordinea lor de prioritate, problemă ce trebuie tratată cu atenţie deosebită în cazul bazelor de date în timp real [IEEE101], [IEEE02]. Pentru evitarea interblocării se utilizează algoritmii cunoscuţi în literatura

de specialitate [DORO98] sub denumirile de WAIT-DIE şi WOUND-WAIT, care pot fi

descrişi prin următoarele reguli:

WAIT-DIE:

if m(Ti) < m(Tj) then Ti aşteaptă else abortează Ti

WOUND-WAIT: if m(Ti) < m(Tj) then abortează Tj else Ti aşteaptă unde cu m(T) s-a notat marca de timp a unei tranzacţii T. Având în vedere problemele prezentate în cadrul acestui paragraf, rezultă că

prin execuţia concurentă a unui set de tranzacţii se pot obţine rezultate diferite faţă

de cazul în care tranzacţiile respective ar fi executate independent. Pentru precizarea

condiţiilor de execuţie corectă a unui set de tranzacţii concurente se definesc noţiunile de serializabilitate şi planificare. Execuţia independentă a tranzacţiilor se numeşte execuţie serială. Execuţia concurentă a unui set de tranzacţii se consideră corectă numai atunci când rezultatul acesteia este acelaşi cu rezultatul execuţiei seriale. Se numeşte planificare a unui set de tranzacţii concurente, o secvenţă de operaţii care reprezintă ordinea de execuţie a paşilor elementari ai tranzacţiilor setului. Execuţia fiecărei tranzacţii constă din execuţia unui număr de operaţii (parcurgerea unor paşi elementari). În execuţia concurentă a unui set de tranzacţii paşii elementari ai unor tranzacţii diferite pot interfera, însă ordinea paşilor unei tranzacţii trebuie respectată. O planificare se numeşte serială dacă paşii fiecărei

tranzacţii apar în poziţii consecutive ale planificării (fără interferenţe ale tranzacţiilor).

O planificare serială a unui set de tranzacţii, determină o execuţie serială a

tranzacţiilor. O planificare a unui set de tranzacţii concurente se numeşte serializabilă dacă şi numai dacă rezultatul execuţiei sale este acelaşi cu rezultatul execuţiei seriale a tranzacţiilor.

1.1.6. Rezistenţa la defecte şi recuperarea din avarii În timpul exploatării curente a unei baze de date centralizate sau distribuite pot apare diverse incidente (defecte, avarii, pene), fie în funcţionarea echipamentelor , fie software. Se pune astfel problema utilizării unor instrumente şi tehnici pentru a

8

elimina sau măcar pentru a reduce la minimum efectele apariţiei unui defect. Comportarea unui sistem în condiţiile apariţiei unor astfel de incidente hardware sau software sau altfel spus toleranţa faţă de defecte şi capacitatea sistemului de recuperare din avarii este cunoscută în literatura de specialitate sub denumirea de rezistenţă la defecte. Atât pentru bazele de date centralizate cât mai ales pentru bazele de date distribuite se pune problema realizării unor sisteme fiabile care să funcţioneze corect într-un interval de timp dat. Există situaţii când astfel de sisteme trebuie să funcţioneze corect fără întreruperi, 7 zile pe săptămână, 24 ore pe zi (aşanumitele sisteme cu grad ridicat de disponibilitate cum ar fi spre exemplu sistemele pentru programele spaţiale sau sistemele pentru centralele nucleare). În cadrul unui sistem cu baze de date, principalele elemente utilizate sunt: memoria principală (buffer), memoria secundară (suportul extern de memorare), echipamentele şi liniile de comunicaţie, software de sistem şi software de aplicaţie. Astfel, principalele tipuri de defecte ce pot apare în funcţionarea sistemului sunt:

- defecte hardware (căderi ale memoriei principale, memoriei secundare sau a altor componente hardware ale sistemului de calcul);

- defecte software care se datorează funcţionării defectuoase ale unor componente ale sistemului de operare, sistemului SGBD, sau a unor programe de aplicaţie;

- defecte ale sistemului de comunicaţii, datorate unor căderi de linii de comunicaţie sau funcţionării defectuoase a unor echipamente de comunicaţie. În vederea asigurării funcţionării corecte în condiţiile apariţiei unor incidente, sistemul SGBD dispune de o componentă numită modulul de recuperare care permite recuperarea din avarii (refacerea bazei de date în urma apariţiei unor incidente) prin cooperare cu componenta numită buffer manager. Principalele funcţiuni realizate de modulul de recuperare sunt: commit, rollback, backup-recovery. Pentru a putea realiza recuperarea bazei de date, sistemul SGBD facilitează utilizarea unor mecanisme de asistenţă a refacerii şi anume:

- realizarea de copii de siguranţă periodice ale bazei de date;

- crearea fişierului jurnal (log) care este un fişier secvenţial ce conţine o istorie a tuturor actualizărilor, la nivel de tranzacţie, efectuate asupra bazei de date;

- crearea de puncte de control (puncte de reluare) prin care se salvează starea sistemului în memoria secundară la diverse momente de timp şi pentru fiecare punct de reluare se scrie în jurnal o înregistrare corespunzătoare. Punctele de reluare pot fi create fie la diverse momente de timp, fie după memorarea unui număr de înregistrări în fişierul jurnal. Dacă este necesară recuperarea bazei de date vor fi utilizate cel mult ultimele două puncte de reluare. O metodă mai convenabilă prin care să nu fie perturbată funcţionarea sistemului, este crearea de puncte de reluare fuzzy prin care salvarea stării sistemului în memoria secundară are loc în paralel cu operarea normală a tranzacţiilor în baza de date. Este posibil ca starea salvată în memoria secundară să nu îndeplinească condiţia de consistenţă, însă aceasta poate fi transformată într-o stare consistentă prin operarea asupra sa a tuturor modificărilor înscrise în jurnal pe durata creării punctului de reluare.

- Utilizarea mecanismului UNDO/REDO care permite recuperarea bazei de date după o cădere a sistemului atât pentru tranzacţiile încheiate în memoria principală dar netransferate în totalitate în memoria secundară, cât şi pentru tranzacţiile neterminate în momentul căderii sistemului. Pentru primul caz, pentru operarea tranzacţiilor în memoria secundară se parcurge fişierul jurnal înainte de la ultimul punct de reluare până la sfârşit şi se operează în baza de

9

date (operaţie de tip REDO), iar în cel de-al doilea caz pentru tranzacţiile nevalidate în momentul căderii sistemului, acestea vor trebui abortate, ceea ce se realizează prin parcurgerea fişierului jurnal de la sfârşit spre început şi anularea tuturor operaţiilor efectuate de tranzacţiile nevalidate (operaţie de tip UNDO).

1.1.7. Baze de date distribuite

Spre deosebire de o bază de date centralizată, care este stocată pe un singur calculator (server) şi aflată sub controlul unui singur sistem SGBD, o bază de date distribuită este o colecţie de date distribuită fizic pe mai multe baze de date gestionate de diverse sisteme SGBD pe mai multe maşini sub diverse sisteme de operare în cadrul unei reţele de calculatoare. Un sistem SGBD distribuit (SGBDD) este un sistem pentru gestiunea bazelor de date distribuite astfel încât distribuirea să fie transparentă pentru utilizatori. Din punct de vedere utilizator, baza de date distribuită este formată dintr-o singură bază de date logică constituită dintr-un număr de fragmente, fiecare fragment fiind stocat pe unul sau mai multe calculatoare (site, nod) interconectate în reţea, putând fi reprodus şi fiind controlat de un SGBD. Tratarea distribuită este motivată din următoarele considerente:

au apărut şi s-au dezvoltat din necesitatea

- reţelele

de

calculatoare

descentralizării;

- în mod natural o organizaţie este constituită din unităţi funcţionale distribuite local sau la distanţă;

- fiecare unitate funcţională din cadrul unei organizaţii îşi întreţine propriile date operaţionale;

- datele trebuie stocate şi întreţinute cât mai aproape de sursele care le generează.

Un sistem de baze de date distribuite poate fi omogen, caz în care în toate nodurile sistemului se utilizează acelaşi SGBD, sau poate fi eterogen, caz în care în noduri diferite pot fi utilizate sisteme SGBD diferite eventual de tipuri diferite (ierarhice, reţea, relaţionale, orientate obiect). Sistemele eterogene necesită realizarea comunicării între diverse tipuri de sisteme SGBD, care trebuie să fie transparentă pentru utilizator astfel încât acesta să poată formula cereri în limbajul sistemului SGBD local. Comunicarea între diverse SGBD-uri în cadrul unui sistem distribuit eterogen se realizează de regulă prin utilizarea unor porţi care translatează interogările dintr-un limbaj în alt limbaj fără a realiza controlul unor procese cum ar fi de exemplu administrarera tranzacţiilor, controlul concurenţei, etc. O modalitate privind accesul şi interoperabilitatea bazelor de date deschise în vederea comunicării între sisteme SGBD diferite o constituie utilizarea driver-elor ODBC (Open Data Base Connectivity). În cadrul arhitecturii de referinţă a unui sistem de baze de date distribuite, pot fi puse în evidenţă următoarele scheme [COBS01]: un set de scheme globale externe, o schemă conceptuală globală, o schemă de fragmentare, o schemă de alocare, un set de scheme pentru fiecare SGBD local după arhitectura ANSI-SPARC pe trei nivele. Schema conceptuală globală conţine descrierea la nivel logic a întregii baze de date. Schemele externe globale corespund vederilor utilizatorilor asupra bazei de date distribuite. Schema de fragmentare defineşte fragmentele de date la nivel logic. Schema de alocare descrie locul unde vor fi stocate datele şi reproducerile acestora. Fiecărui nod al reţelei în care sunt stocate date în cadrul sistemului SGBDD îi corespunde o schemă locală conform arhitecturii ANSI-SPARC pe 3 nivele, altfel

10

spus fiecărui SGBD local îi corespunde o arhitectură ANSI-SPARC pe 3 nivele (nivelul extern, nivelul conceptual, nivelul intern), în cadrul nivelului extern fiind realizată corespondenţa dintre fragmentele din schema de alocare şi obiectele externe din baza de date locală. Aplicaţiile locale (care nu necesită date din alte noduri ale reţelei) pot fi tratate autonom în cadrul SGBD-ului local. În cadrul sistemului pot exista noduri care să nu aibă propria lor bază de date locală. Aceste aspecte privind bazele de date distribuite sunt ilustrate în figura 1.2. În cele ce urmează vor fi prezentate o serie de strategii utilizate în proiectarea bazelor de date distribuite în cadrul modelului relaţional, privind fragmentarea bazei de date, alocarea fragmentelor; reproducerea fragmentelor, precum şi o serie de aspecte privind: transparenţa în sistemele de baze de date distribuite, implicaţii ale distribuirii datelor în administrarea tranzacţiilor, controlul concurenţei şi rezistenţa la defecte în sistemele de baze de date distribuite. În cadrul unui sistem multiutilizator, fiecare utilizator are acces, prin intermediul aplicaţiilor, la o anumită parte a datelor din baza de date, aspect care în sistemele SGBD relaţionale este tratat cu ajutorul vederilor. Având în vedere faptul că în cadrul modelului relaţional atât baza de date cât şi interogările bazei de date sunt reprezentate prin relaţii, o aplicaţie va prelucra subseturi de relaţii, iar pentru unele relaţii doar anumite tuple sau valori pentru anumite atribute ale relaţiei. Astfel apare necesitatea grupării relaţiilor în subseturi şi împărţirii unor relaţii în subrelaţii, operaţie care în cadrul sistemelor distribuite este numită fragmentare şi prin care, baza de date este împărţită în fragmente ca unităţi de distribuire a datelor având în vedere creşterea performanţelor în întreţinerea şi exploatarea datelor prin reducerea traficului în reţea astfel încât majoritatea operaţiilor să fie efectuate local.

……… Schemă S1 externă Schemă S2 externă Schema externă Sn globală globală globală Schema conceptuală
………
Schemă S1 externă
Schemă S2 externă
Schema externă Sn
globală
globală
globală
Schema conceptuală
globală
Schema de
fragmentare
Schema de
alocare
S1
S2
………
Sn
Nivel extern
Nivel extern
Nivel extern
Schemă locală
Nivel conceptual
Schemă Nivel conceptual locală
Schemă Nivel conceptual locală
Nivel intern
Nivel intern
Nivel intern
BD
BD
BD

Fig.1.2. Arhitectura de referinţă a unui sistem SGBDD (adaptare după [COBS01])

11

Prin fragmentare fiecare relaţie poate fi împărţită într-un număr de subrelaţii numite fragmente. Mulţimea tuplelor unei relaţii poate fi împărţită în submulţimi de înregistrări, sau în submulţimi de valori ale unor anumite atribute ale relaţiei şi corespunzător se va obţine o fragmentare orizontală respectiv o fragmentare verticală. Fragmentarea orizontală reprezintă o operaţie de selecţie, iar fragmentarea verticală o operaţie de proiecţie. Poate fi avută în vedere şi fragmentarea mixtă care poate fi realizată printr-o operaţie de selecţie aplicată asupra rezultatului unei operaţii de proiecţie aplicate asupra unei relaţii. Pentru definirea fragmentelor trebuie avute în vedere următoarele aspecte: modul de utilizare a datelor în cadrul aplicaţiilor, stocarea datelor cât mai aproape de locul unde sunt utilizate, evitarea redundanţei datelor, asigurarea consistenţei şi integrităţii bazei de date, creşterea gradului de concurenţă. Fragmentarea va trebui realizată astfel încât să se asigure posibilitatea obţinerii relaţiei iniţiale din fragmentele corespunzătoare cu păstrarea dependenţelor funcţionale şi fără pierdere de informaţie. Alocarea fragmentelor este operaţia prin care se efectuează amplasarea datelor pe serverele de date ale reţelei de calculatoare realizând astfel distribuirea datelor. Pentru aceasta pot fi utilizate [COBS01] următoarele patru strategii de alocare: centralizată, partiţionată, reproducere completă, reproducere selectivă. În strategia centralizată denumită şi prelucrare distribuită, se crează o singură bază de date amplasată pe un singur server central sub controlul unui singur SGBD cu utilizatori distribuiţi în cadrul reţelei. În strategia partiţionată sau fragmentată, baza de date este partiţionată în fragmente disjuncte, fiecare fragment fiind alocat unui server de date având în vedere precizările de mai sus privind fragmentarea. În strategia de reproducere completă se păstrează o copie completă (replică) a bazei de date în fiecare nod al reţelei. Pentru a reduce costurile de stocare şi de comunicaţie, uneori se utilizează instantanee, un instantaneu fiind o copie a datelor la un anumit moment de timp, datele urmând a fi actualizate periodic, fiind astfel posibil ca datele să nu fie întotdeauna la zi. În strategia de reproducere selectivă sunt combinate facilităţi ale celorlalte tipuri de strategii de alocare, astfel că unele articole de date sunt fragmentate, alte articole utilizate în mai multe noduri ale reţelei şi care nu sunt frecvent actualizate sunt reproduse în nodurile respective, iar celelalte articole de date sunt centralizate. Transparenţa unui sistem distribuit are în vedere ascunderea aspectelor privind distribuirea faţă de utilizator, astfel încât utilizarea unei baze de date distribuite este realizată în acelaşi mod ca utilizarea unei baze de date centralizate. În acest sens, un utilizator nu trebuie să ştie cum a fost realizată fragmentarea, unde sunt amplasate datele, cum sunt reproduse datele, ce sisteme SGBD sunt utilizate în celelalte noduri ale reţelei, etc. Referitor la controlul concurenţei în bazele de date distribuite, cea mai mare parte dintre conceptele şi algoritmii definiţi pentru bazele de date centralizate este utilizată cu eventuale extinderi pentru sistemele distribuite. Astfel pentru conceptul de planificare se defineşte câte o planificare locală pentru fiecare nod prin care se precizează ordinea de execuţie a tranzacţiilor în nodul respectiv şi conceptul de planificare globală ca reuniune a planificărilor locale. Pentru o bază de date nereplicată, dacă toate planificările locale sunt serializabile, atunci şi planificarea globală este serializabilă cu condiţia ca ordinea de serializare pentru tranzacţiile comune în planificările locale să fie aceeaşi. Pentru bazele de date replicate este

12

necesar ca actualizările să se efectueze asupra tuturor copiilor, ceea ce se realizează prin protocoale de control al replicilor. Pentru controlul concurenţei în bazele de date distribuite se utilizează, ca şi în cazul bazelor de date centralizate, mecanismul de blocare şi mărcile de timp, cu o serie de extensii şi protocoale specifice impuse de problemele suplimentare care apar în sistemele distribuite. Spre exemplu, referitor la crearea şi utilizarea mărcilor de timp, pentru fiecare nod local există un contor local care generează mărci de timp unice pentru nodul local, iar la nivel global mărcile de timp sunt perechi de forma:

<marcă de timp locală , identificator nod> identificatorul nodului fiind plasat pe poziţia a doua (mai puţin semnificativă) pentru a asigura că evenimentele sunt ordonate după apariţia lor şi nu după locul în care au fost declanşate. Rezistenţa la defecte a unei baze de date are în vedere validarea tranzacţiilor şi recuperarea bazei de date la apariţia unui defect. În cazul bazelor de date distribuite pentru realizarea acestor operaţii trebuie avută în vedere în plus faţă de cazul bazelor de date centralizate, coordonarea acţiunilor din nodurile în care se execută tranzacţiile. Funcţionarea unui sistem distribuit depinde de capacitatea de comunicare în siguranţă a tuturor nodurilor din reţea. Recuperarea unui nod din reţea necesită consultarea altor noduri în care se află tranzacţii în execuţie întrucât operaţia de recuperare trebuie să asigure atomicitatea şi durabilitatea atât pentru subtranzacţiile locale cât şi pentru tranzacţiile globale, sau altfel spus pentru tranzacţiile distribuite (tranzacţiile care se execută în mai multe noduri). La apariţia unui defect într-un nod al reţelei, sistemul SGBDD trebuie să realizeze următoarele operaţii:

- abortarea tuturor tranzacţiilor în execuţie afectate de defectul detectat;

- marcarea nodului în cauză ca inaccesibil pentru celelalte noduri din reţea pe durata recuperării sale;

- refacerea la repornire, a bazei de date locale din nodul defect şi a copiilor sale.

În acest sens, pentru validarea tranzacţiilor distribuite se utilizează protocolul de validare în două faze 2PC (two-phase commit) care este implementat în majoritatea sistemelor SGBDD. Acest protocol presupune existenţa unui nod coordonator care de regulă este nodul în care a fost iniţiată tranzacţia, iar celelalte noduri se numesc participanţi. Protocolul se execută în două faze şi anume:

- faza de consultare sau votare, în care toţi participanţii sunt întrebaţi de coordonator dacă sunt gata pentru a valida tranzacţia;

- faza de decizie, în care, în baza votului participanţilor, coordonatorul decide validarea tranzacţiei. Pe parcursul derulării protocolului, este posibilă blocarea unor noduri participante la efectuarea tranzacţiei, caz în care acest mod de lucru eşuează şi pentru astfel de situaţii a fost propus un protocol fără blocare numit protocolul în trei faze 3PC în care, între faza de votare şi faza de decizie, se introduce o a treia fază numită de pre-efectuare prin care, după primirea tuturor voturilor, coordonatorul trimite tuturor participanţilor un mesaj PRE-COMMIT şi aceştia confirmă coordonatorului primirea mesajului. După primirea tuturor confirmărilor de la participanţi, coordonatorul va decide validarea globală a tranzacţiei. Pentru recuperarea unui nod scos temporar din funcţiune în urma apariţiei unui defect, se va utiliza jurnalul propriu nodului respectiv, care trebuie să conţină toate informaţiile necesare recuperării, informaţii ce sunt înregistrate în jurnal prin protocoalele de validare a tranzacţiilor.

13

Având în vedere dificultatea soluţionării problemelor ridicate de utilizarea bazelor de date distribuite, la ora actuală sistemele SGBD distribuite nu sunt larg acceptate, fiind preferabilă o tratare simplificată a distribuirii datelor prin reproducerea datelor în servere de reproducere. Reproducerea constă în crearea şi întreţinerea mai multor copii ale datelor în unul sau mai multe noduri ale reţelei, oferind astfel o serie de facilităţi sporite privind disponibilitatea datelor, refacerea în urma unor incidente şi funcţionalitatea sistemului. Operaţia de reproducere a datelor poate fi realizată în două moduri şi anume:

- reproducerea sincronă, caz în care datele reproduse sunt actualizate imediat ce sunt actualizate datele sursă (exemplu protocolul 2PC);

- reproducerea asincronă, caz în care reproducerile datelor (instantanee) pot fi actualizate după o întârziere faţă de momentul actualizării datelor sursă, întârzierea putând fi de ordinul secundelor, orelor sau chiar zilelor acolo unde se pot utiliza reproduceri care nu trebuie să fie neapărat sincronizate sau întreţinute la zi. Reactualizarea unor seturi de date reproduse poate fi realizată, fie de către un singur nod numit master sau primar care pune la dispoziţie aceste date pentru citire altor noduri numite slave (modelul master/slave), fie în cadrul unui flux de activităţi prin care datele reproduse actualizate sunt mutate de la un nod la altul la diverse momente de timp însă la un moment dat un singur nod poate reactualiza acel set de date, fie în mai multe noduri ale reţelei (metoda reactualizare oriunde sau reproducere simetrică) caz în care mai multe noduri au drepturi egale de a reactualiza datele reproduse. O altă modalitate de tratare a reproducerilor o constituie crearea de către utilizatori a unor aplicaţii proprii de reproducere numite declanşatoare de baze de date, care conţin cod ce va fi executat la declanşarea anumitor evenimente cum ar fi spre exemplu inserarea unei înregistrări, modificarea unei înregistrări existente, etc.

1.1.8. Baze de date multimedia

Conceptul multimedia reprezintă capacitatea de achiziţionare, stocare, manipulare şi redare informaţii obţinute de la diverse surse ce conţin text, grafică, sunet, imagine statică sau dinamică, grupate în documente electronice. Organizarea informaţiei sub formă de documente electronice şi accesarea acestora a devenit posibilă odată cu apariţia Web-ului. Crearea documentelor electronice pe Web se realizează cu ajutorul limbajului HTML (HyperText Markup Language) bazat pe hiperlegături (legături către date stocate ierarhic), iar accesarea acestora se face cu ajutorul unor programe numite navigatoare (Internet Explorer, Netscape). Pentru realizarea de pagini Web dinamice se utilizează limbaje specializate cum ar fi JavaScript, care permit încorporarea unor programe simple în documentul HTML şi care vor fi executate de către programul navigator. Organizarea şi gestionarea eficientă a informaţiei multimedia se realizează în cadrul sistemelor de gestiune a bazelor de date multimedia (SGBD MM). În cadrul unor sisteme SGBD comerciale, informaţia multimedia poate fi stocată direct în baza de date în tipuri de câmpuri speciale, sau baza de date poate conţine locaţiile (căile de acces) la fişierele externe ce conţin informaţia multimedia. O bază de date multimedia trebuie să permită stocarea şi regăsirea informaţiei multimedia în condiţii optime privind necesarul de suport şi timpul de răspuns. Deşi există la ora actuală o serie de modele teoretice de obiecte multimedia, acestea sunt specifice anumitor aplicaţii, sunt limitate ca funcţionalitate şi nu au fost încă implementate în produse SGBD comerciale. Aceste produse au facilităţi de stocare, însă multe din operaţiile

14

de prelucrare a unor tipuri de date multimedia trebuie realizate în cadrul aplicaţiei multimedia prin intermediul unui limbaj gazdă.

15

1.1.9. Arhitecturi client-server pentru sistemele SGBD

Sistemele client-server au apărut ca urmare a descentralizării activităţii din diverse domenii, ceea ce presupune o repartizare a realizării sarcinilor pe cele două nivele: client, server. De obicei clienţii reprezintă utilizatorii finali care vor comunica cu serverul bazei de date în cadrul unei reţele de calculatoare. După rolul pe care îl are fiecare din componentele client, server, se pot distinge [COBS01] trei arhitecturi de bază pentru un sistem client-server (Loomis 1992) şi anume:

- arhitectura de tip server de obiecte – în care se distribuie prelucrarea între cele două componente (server, client). Serverul este responsabil de administrarea memoriei şi zăvoarelor, efectuarea operaţiilor în memoria secundară, securitatea, integritatea şi recuperarea bazei de date, executarea procedurilor stocate şi optimizarea interogărilor. Clientul este responsabil de administrarea tranzacţiilor şi realizarea interfeţei cu limbajul de programare;

- arhitectura de tip server de pagini – cea mai mare parte a prelucrărilor este realizată de către client. Serverul este responsabil de memoria secundară şi furnizează paginile corespunzător cererilor formulate de client;

- arhitectura de tip server de bază de date – cea mai mare parte din

prelucrările bazei de date este efectuată de către server. Clientul transmite cererea serverului, primeşte rezultatele şi le transmite aplicaţiei. Este modul utilizat frecvent de către sistemele relaţionale. În fiecare dintre cele trei cazuri serverul se găseşte pe aceeaşi maşină ca şi baza de date fizică. Clientul se poate afla pe aceeaşi maşină sau pe una diferită. În cazul bazelor de date distribuite pe mai multe maşini, clientul va comunica cu câte un server de pe fiecare maşină. De asemenea mai mulţi clienţi pot comunica concomitent cu acelaşi server (accesul concurent). Arhitectura tradiţională a sistemelor client-server este o arhitectură pe două nivele (etaje), în care la primul nivel (clientul) se realizează interfaţa cu utilizatorul şi logica principală a aplicaţiei, iar la al doilea nivel (serverul) se realizează validarea datelor şi accesul la baza de date. Necesitatea rezolvării unor probleme complexe care presupun accesul la baza de date a unui număr mare de utilizatori, utilizarea unor platforme hard-soft diferite, precum şi integrarea bazelor de date în mediul Web, au impus definirea unei noi arhitecturi client-server în care sunt definite trei nivele şi anume:

- nivelul client, la care se realizează interfaţa cu utilizatorul aplicaţiei;

- nivelul server de aplicaţie, la care se realizează logica aplicaţiei şi prelucrării datelor;

- nivelul server de baze de date, la care se realizează validarea datelor şi

accesul la baza de date. Un server de aplicaţie poate servi mai mulţi clienţi, fiind conectat fizic atât la nivelul client cât şi la nivelul server de baze de date. Spre exemplu în mediul Web, clientul poate fi un browser Web, iar serverul de aplicaţie poate fi un server Web.

16

Evoluţia sistemelor de baze de date

Modelarea datelor

Prin modelarea datelor se urmăreşte organizarea unei colecţii de date astfel încât pe de o parte să reprezinte cât mai fidel situaţia din lumea reală, iar pe de altă parte să faciliteze reprezentarea şi prelucrarea datelor pe calculator. O etapă importantă în definirea modelului conceptual al unei baze de date o constituie identificarea categoriilor de obiecte (tipuri de entităţi), a proprietăţilor (atributelor) caracteristice fiecărei categorii şi a legăturilor (relaţiilor) dintre tipurile de entităţi. Generalizarea şi formalizarea proprietăţilor caracteristice ale datelor, conduc la definirea conceptului de model de date. Un model de date este [DORO98] un instrument teoretic care permite identificarea semnificaţiei sau conţinutului de informaţie pentru o colecţie de date, văzută în ansamblul ei, prin contrast cu valorile individuale ale datelor. Din punct de vedere tehnic un model de date este un formalism având două componente:

- un set de reguli pentru organizarea şi structurarea datelor;

- un set de reguli (operaţii) pentru manipularea datelor.

Modelele de date se pot clasifica [DORO98] în:

- modele de date strict tipizate - sunt acele modele în care fiecare dată trebuie să aparţină unei categorii. Datele care nu se încadrează în mod natural într-o categorie vor trebui forţate în una din categoriile modelului;

- modele de date slab tipizate - sunt modele în care datele individuale pot exista prin ele însele şi pot fi legate de alte date. Categoriile sunt permise numai în măsura în care sunt utile. Modelele strict tipizate impun anumite restricţii asupra categoriilor de obiecte şi asupra legăturilor dintre acestea, ceea ce le face mai puţin expresive în modelarea situaţiilor din lumea reală faţă de modelele slab tipizate. Prin încadrarea obiectelor în categorii omogene, modelele strict tipizate facilitează transpunerea pe calculator în scopul prelucrării unor volume mari de date şi din acest motiv modelele de date care stau la baza proiectării SGBD-urilor sunt până la ora actuală modele strict tipizate. Un model conceptual sau schemă cuprinde numele categoriilor (tipurilor de entităţi), proprietăţile caracteristice ale acestora (atribute) şi legăturile dintre categorii. În cadrul unui model, un tip de entitate corespunde unei categorii de obiecte din lumea reală. Un obiect al unei categorii sau o entitate reprezintă o realitate obiectivă care există prin ea însăşi. Orice entitate aparţine unui tip de entitate şi este definită prin valorile atributelor ce definesc tipul de entitate corespunzător. După identificarea tipurilor de entităţi şi a legăturilor dintre acestea se identifică atributele ce definesc fiecare tip de entitate. Prima formă de structurare a datelor realizează asocierea atributelor pentru a descrie tipul de entitate. Toate modelele de date utilizate până în prezent realizează definirea entităţilor prin structuri de tip înregistrare care se obţin prin concatenarea valorilor atributelor ce definesc tipul de entitate respectiv. Un tip de entitate poate fi descris convenabil prin intermediul unui tabel astfel:

- capul de tabel descrie tipul de entitate;

- liniile tabelului definesc fiecare entitate în parte.

A doua formă de structurare a datelor în cadrul modelului conceptual al unei baze de date are în vedere reprezentarea legăturilor între mulţimile de entităţi ale bazei de date. Modelele de date utilizate până în prezent diferă între ele în principal prin modul de realizare a legăturilor dintre tipurile de entităţi. Între două tipuri de entităţi E1, E2 pot exista următoarele tipuri de legături:

17

- relaţie 1 : 1 – unei entităţi din E1 îi corespunde o singură entitate în E2 şi reciproc (relaţie de tip soţ – soţie , fig. 1.3).

E1 e11 e12 e13
E1
e11
e12
e13
E2 e21 e22 e23
E2
e21
e22
e23

Fig. 1.3. Reprezentare relaţie 1:1

Corespondenţa între elementele mulţimilor E1, E2 este dată mai jos.

e11 -> e21

e12 -> e22

e13 -> e23

- relaţie 1 : n – unei entităţi din E1 îi corespund una sau mai multe entităţi din

E2, dar fiecărei entităţi din E2 îi corespunde o singură entitate din E1 (relaţie de tip

tată – fiu, fig. 1.4). E1 E2 e21 e11 e22 e12 e23 e13 e24 e25
tată – fiu, fig. 1.4).
E1
E2
e21
e11
e22
e12
e23
e13
e24
e25
e26

Fig. 1.4. Reprezentare relaţie 1:n

Corespondenţa între elementele mulţimilor E1, E2 este dată mai jos.

e11 -> e21, e24, e25

e12 -> e22

e13 -> e23, e26

- relaţie m : n – unei entităţi din E1 îi corespunde una sau mai multe entităţi din E2 şi reciproc (relaţie de tip prieten–prieten, fig. 1.5).

E1 E2 e21 e11 e22 e12 e23 e24 e13 e25 e14 e26 Fig. 1.5. Reprezentare
E1
E2
e21
e11
e22
e12
e23
e24
e13
e25
e14
e26
Fig. 1.5. Reprezentare relaţie m:n

18

Corespondenţa între elementele mulţimilor E1, E2 este dată mai jos.

e14 -> e21 , e23

e11 -> e21 , e24

e12 -> e22

e13 -> e23 , e25

Orice relaţie de tip m-n poate fi descompusă în două relaţii de tip 1-n definind o legătură (relaţie) auxiliară L (E1->E2 este descompusă în E1->L , E2->L , fig. 1.6).

L L E1 E1 l1 l1 E2 E2 l2 l2 e21 e21 e11 e11 l3
L L
E1
E1
l1
l1
E2
E2
l2
l2
e21
e21
e11
e11
l3
l3
e22
e22
l4
l4
e12
e12
e23
e23
l5
l5
e24
e24
e13
e13
l6
l6
e25
e25
l7
l7
e14
e14
e26
e26
l8
l8
Fig. 1.6. Descompunere relaţie m:n în două relaţii 1:n

1.2.1. Modele de date utilizate în proiectarea SGBD-urilor

Funcţie de modul în care sunt reprezentate relaţiile (legăturile) între tipurile de entităţi au fost definite în ordine cronologică următoarele tipuri de modele de date [DORO98]: modelul ierarhic, modelul reţea, modelul relaţional.

Modelul de date ierarhic

Este primul model de date care a stat la baza realizării unor SGBD-uri. Cel mai reprezentativ SGBD realizat după acest model este sistemul IMS (Information Management System) al firmei IBM dezvoltat în cadrul programului de cercetări spaţiale APOLLO. Structurile de date sunt reprezentate prin intermediul diagramei structurii de date care este un graf orientat reprezentând tipurile de entităţi şi legături funcţionale între acestea. Nodurile grafului reprezintă tipurile de entităţi iar arcele grafului, legăturile între tipurile de entităţi de la extremităţile arcului respectiv. Un arc de la tipul de entitate origine către tipul de entitate extremitate reprezintă o legătură 1 : n ). În cadrul modelului există un tip de entitate numit rădăcină care nu este subordonat nici unui alt tip de entitate. Fiecare tip de entitate poate avea unul sau mai multe tipuri de entitate subordonate cu excepţia nodurilor finale (de la care nu mai pleacă arce). Deci nodurile sunt organizate pe nivele sub forma unui arbore ordonat. Fiecare nod cu excepţia nodului rădăcină are o singură legătură către nivelul imediat superior (nodul tată ) şi un număr de legături către noduri de pe nivelul imediat inferior (noduri fiu). O astfel de reprezentare poartă numele de arbore de definiţie ierarhic. În figura 1.7. este reprezentat un exemplu de arbore de definiţie (diagrama structurii datelor) pentru o structură de date pe trei nivele.

19

E0 (rădăcină)

E0 (rădăcină) E1 E2 … En E21 … E2k Fig. 1.7. Diagrama structurii datelor în modelul
E1
E1
E2
E2

En
En
E21
E21

E2k
E2k

Fig. 1.7. Diagrama structurii datelor în modelul ierarhic

Descrierea simplificată a structurii de date reprezentată în figura 1.7. în cadrul sistemului ierarhic IMS este redată în continuare.

TREE S3 RECORD E0 ROOT <Descriere atribute ce definesc tipul de entitate E0> RECORD E1 PARENT = E0 <Descriere atribute ce definesc tipul de entitate E1> RECORD E2 PARENT = E0 <Descriere atribute ce definesc tipul de entitate E2> …………………………… RECORD En PARENT = E0 <Descriere atribute ce definesc tipul de entitate En> RECORD E21 PARENT = E2 <Descriere atribute ce definesc tipul de entitate E21> ………………………………. RECORD E2k PARENT = E2 <Descriere atribute ce definesc tipul de entitate E2k>

O relaţie de tip 1: n între două tipuri de entităţi este reprezentată printr-o colecţie de arbori având în rădăcină o instanţiere a entităţii părinte şi ca descendenţi un număr de instanţieri a entităţii fiu. Reprezentarea relaţiilor de tip m:n introduce o mare redundanţă de date (înregistrarea corespunzătoare apare în baza de date de mai multe ori). Având în vedere că interogările se realizează prin parcurgerea arborilor, anumite interogări pot fi dificil de realizat. Modelul ierarhic este indicat pentru structuri natural-ierarhice (relaţii de tip 1 : n). Pot fi folosite pentru memorarea datelor şi suporturi cu acces strict secvenţial.

Modelul de date reţea

Standardul pentru bazele de date de tip reţea este definit în documentele emise de comisia DBTG (Data Base Task Group) înfiinţată cu ocazia conferinţei CODASYL din anul 1971. Reprezentarea structurii datelor în modelul reţea este realizată prin diagrama structurii datelor care este un graf oarecare în care nodurile reprezintă tipurile de entităţi iar arcele sunt etichetate şi reprezintă legăturile între tipurile de entităţi. In sistemul DBTG aceste arce se numesc tip de set şi reprezintă o legătură între două tipuri de înregistrări şi anume: tipul de înregistrare proprietar, tipul de înregistrare membru. Fiecare înregistrare de tip proprietar poate fi legată de zero, una sau mai multe înregistrări de tip membru, iar colecţia de arce corespunzătoare este numită set sau fan-set. Pot fi reprezentate doar legăturile de tip 1:1 şi 1: n. Spre deosebire de modelul ierarhic, în modelul reţea un tip de entitate poate fi legat

20

la unul sau mai multe tipuri de entitate părinte sau chiar prin mai multe arce la acelaşi

tip de entitate părinte (din acest motiv arcele sunt etichetate). Pot exista şi tipuri de entitate fără legături. Un exemplu de structură de tip reţea este reprezentat în figura

1.8.

E1

structură de tip reţea este reprezentat în figura 1.8. E1 LE1E2 E2 LE1E3 E3 LE1E4 E4
LE1E2 E2
LE1E2
E2
LE1E3 E3
LE1E3
E3
LE1E4 E4
LE1E4
E4
reprezentat în figura 1.8. E1 LE1E2 E2 LE1E3 E3 LE1E4 E4 LE3E6 L1E3E7 LE6E7 E6 E7
LE3E6 L1E3E7 LE6E7 E6 E7 LE8E6 LE9E7
LE3E6
L1E3E7
LE6E7
E6
E7
LE8E6
LE9E7

E8

E9

L2E3E7

LE1E5 E5 LE5E5
LE1E5
E5
LE5E5

E10

Fig. 1.8. Diagrama structurii datelor în modelul reţea În majoritatea sistemelor de tip reţea implementarea seturilor se realizează prin lanţuri de pointeri având drept cap de lanţ o înregistrare de tip proprietar şi se prezintă sub forma unei liste circulare cap_lanţ, înregistrare membru,…, cap_lanţ. Pot fi utilizate următoarele tipuri de pointeri:

- NEXT – realizează înlănţuirea înainte a înregistrărilor (este obligatoriu);

- PRIOR – realizează înlănţuirea înapoi a înregistrărilor (este opţional);

- OWNER – leagă o înregistrare de tip membru de înregistrarea proprietar

corespunzătoare (este opţional). Rezultă că pot fi definite: structuri cu pointeri NEXT, structuri cu pointeri NEXT şi PRIOR, structuri cu pointeri NEXT şi OWNER, structuri cu pointeri NEXT, PRIOR, OWNER

O reprezentare a celor trei tipuri de pointeri este ilustrată în figura 1.9. NEXT P
O reprezentare a celor trei tipuri de pointeri este ilustrată în figura 1.9.
NEXT
P
PRIOR
OWNER
M1
M2
Mn

Fig. 1.9. Tipuri de pointeri utilizaţi în modelul reţea

Utilizarea diferitelor tipuri de pointeri trebuie făcută justificat, deoarece afectează performanţele de timp şi spaţiu de stocare. Descrierea în limbajul LDD a unei structuri de tip reţea conform standardului DBTG va conţine descrierea fiecărui tip de entitate şi descrierea fiecărei legături între

două tipuri de entităţi. Astfel, pentru fiecare tip de entitate, se va realiza o descriere RECORD NAME IS <nume tip entitate> <descriere atribute>

şi pentru fiecare legătură între două tipuri de entităţi, o descriere

SET NAME IS <nume legătură>

21

OWNER IS <nume tip entitate proprietar> MEMBER IS <nume tip entitate membru> < tipuri de pointeri>

În cadrul modelului, o relaţie de tip m:n poate fi transformată în două relaţii de tip 1:n

cu ajutorul unei entităţi de legătură care poate conţine atribute sau poate fi vidă

(conţine doar pointerii de înlănţuire). Definirea unei relaţii de tip m:n poate fi realizată şi prin multiplicarea înregistrărilor. Dezavantajele modelului reţea sunt datorate următoarelor aspecte:

- gestionarea pointerilor de înlănţuire cade în sarcina utilizatorului;

- cu cât numărul de entităţi creşte cu atât structura devine mai complicată şi dificil de utilizat;

- posibilităţile de interogare sunt determinate de legăturile definite între tipurile de entităţi.

60 şi începutul anilor 70 au la bază

modelul ierarhic şi modelul reţea, constituind prima generaţie de sisteme SGBD. Principalele dezavantaje ale acestor două modele sunt:

realizarea

SGBD-urile realizate la sfârşitul anilor

scrierii

unor

- necesitatea

programe

complexe

pentru

interogărilor, bazate pe acces navigaţional orientat pe înregistrări;

- inexistenţa unui fundament teoretic;

- independenţa de date este minimală. Cercetările efectuate pentru eliminarea acestor neajunsuri au condus la definirea unui model de date care a revoluţionat domeniul bazelor de date.

Modelul de date relaţional

La începutul anilor 70 E.F. Codd a pus bazele modelului relaţional fundamentat pe algebra relaţiilor şi calculul relaţional. SGBD-urile realizate după acest model constituie a doua generaţie de sisteme SGBD cu o largă răspândire (există astăzi peste 100 de sisteme SGBDR atât pentru calculatoare mainframe cât şi pentru calculatoare PC). Întrucât modelul relaţional este fundamentat pe teoria matematică a relaţiilor, în cele ce urmează se va defini conceptul de relaţie şi o serie de noţiuni utilizate în cadrul acestui model. Se consideră mulţimile D1, D2, … Dn nu neapărat distincte. Se defineşte R ca fiind o relaţie pe aceste mulţimi dacă este o mulţime de tuple ordonate (d1, d2, …., dn) astfel încât d1 D1, d2 D2, …., dn Dn. D1, D2, …., Dn se numesc domeniile relaţiei R, iar n este gradul relaţiei R. O relaţie

R pe mulţimile D1, D2, …., Dn, este o submulţime a produsului cartezian

D1xD2x….xDn.

Un domeniu a unei relaţii R, este ansamblul valorilor admisibile pentru o componentă

a relaţiei. Un domeniu cu numele său reprezintă un atribut. O relaţie fiind o mulţime de tuple rezultă că asupra acestora se pot aplica proprietăţile din teoria mulţimilor. Următoarele două proprietăţi au o importanţă majoră în teoria relaţiilor:

1. O mulţime fiind o colecţie de elemente fără repetiţie rezultă că într-o relaţie nu pot exista două tuple identice.

2 Ordinea elementelor într-o mulţime fiind nerelevantă rezultă că prin schimbarea ordinii tuplelor unei relaţii, relaţia rămâne neschimbată. Din proprietatea 1 rezultă că fiecare tuplă poate fi identificată în mod unic prin valorile atributelor sale, cu menţiunea că poate exista un subset de atribute ale relaţiei prin

22

care să se realizeze identificarea unică a fiecărei tuple. Această observaţie conduce

la definirea noţiunii de cheie a unei relaţii.

O cheie a unei relaţii R este un subset K de atribute ale relaţiei, care satisface

proprietăţile:

1) – identifică unic tuplele relaţiei; 2) – subsetul K este minimal (eliminarea oricărui atribut din K duce la pierderea proprietăţii de identificare unică). Orice atribut ce face parte dintr-o cheie se numeşte atribut prim. Celelalte atribute ale relaţiei care nu fac parte din nici o cheie se numesc atribute neprime. Din precizările de mai sus rezultă că pentru o relaţie pot fi definite mai multe chei. Una dintre chei se desemnează ca fiind primară (celelalte numindu-se candidate) şi va fi folosită de SGBD pentru identificarea unică a tuplelor. Cheia primară este comunicată SGBD- ului prin limbajul LDD şi pentru atributele ce compun această cheie se impun

restricţiile:

-

nu sunt admise valori nedefinite pentru atributele ce compun cheia

primară;

-

nici o valoare a unui atribut ce compune o cheie primară nu poate fi

modificată în cadrul operaţiilor de actualizare.

O cheie a unei relaţii utilizată în alte relaţii poartă numele de cheie străină (foreign

key) în aceste relaţii şi este utilizată pentru definire legături între tuplele relaţiilor.

Reprezentarea structurii datelor în cadrul modelului relaţional se realizează prin schema relaţională care constă din una sau mai multe scheme de relaţie. O schemă de relaţie este definită de numele relaţiei şi atributele sale.

Fie schemele de relaţie R1(A1,B1,C1), R2(A2,B2) care reprezintă descrierea a două tipuri de entităţi E1 respectiv E2. Pentru reprezentarea legăturilor între tipurile de entităţi pot fi utilizate următoarele două tehnici:

1) propagarea cheilor (pentru relaţiile 1:1, 1:n) – spre exemplu, atributul A1 propriu tipului de entitate E1 este preluat în schema de relaţie R2(A2,B2) care devine R2(A1,A2,B2) pentru a reprezenta legăturile de tip 1:n. Dacă A1 este cheie primară în schema de relaţie R1(A1,B1,C1), atunci A1 va fi cheie străină în schema de relaţie R2(A1,A2,B2) 2) crearea unei scheme de relaţie separate (pentru reprezentarea legăturilor m : n) care va conţine cheile celor două tipuri de entităţi şi eventual şi alte atribute – spre exemplu R12(A1,A2), dacă se consideră că atributul A1 este cheie pentru tipul de entitate E1 iar atributul A2 este cheie pentru tipul de entitate E2 . Fiecare schemă de relaţie se poate reprezenta printr-un tabel în care coloanele sunt domeniile (atributele) relaţiei iar liniile (rândurile tabelului) sunt înregistrările corespunzătoare tipului de entitate descris de relaţia respectivă.

O posibilă descriere a schemei relaţionale de mai sus în limbajul SQL este redată

mai jos. CREATE TABLE R1(A1 INTEGER (3) NOT NULL, B1 CHAR (15), C1 CHAR (20)) CREATE TABLE R2(A2 INTEGER (5) NOT NULL, B2 CHAR (6) NOT NULL) În cele ce urmează sunt enumerate principalele caracteristici definitorii pentru modelul relaţional:

- în modelul relaţional atât tipurile de entităţi cât şi legăturile dintre ele sunt reprezentate prin relaţii;

- orice interogare a bazei de date este definită tot printr-o relaţie;

23

- fiecare relaţie conţine o mulţime de tuple care pot fi reprezentate

convenabil printr-un tabel în care fiecare tuplă este un rând al tabelului şi poate fi interpretată ca o propoziţie adevărată;

- fiecare relaţie are [DATE04] un titlu sau antet (un set de perechi nume-coloană, tip-dată) şi un cuprins (o mulţime de rânduri care se conformează titlului). Titlul poate fi privit ca un predicat în care argumentele sunt numele coloanelor, iar fiecare rând al cuprinsului poate fi interpretat ca fiind o propoziţie adevărată obţinută prin înlocuirea argumentelor predicatului cu valorile corespunzătoare;

- modelul dispune de operatori care permit procesul de inferenţă a unor propoziţii adevărate noi din propoziţiile existente la un moment dat. În acest sens, sunt deosebit de importanţi operatorii de restricţie (extragerea anumitor rânduri din tabelă), proiecţie (extragerea anumitor coloane din tabelă) şi uniune (combinarea a două tabele într-una singură pe baza valorilor comune din cadrul unor coloane comune), care utilizaţi pentru consultarea datelor, permit derivarea de tabele noi din tabele existente. Având în vedere faptul că rezultatele aplicării operatorilor sunt tot tabele, deci intrările şi ieşirile sunt de acelaşi tip (proprietate a sistemelor relaţionale numită de închidere), se pot construi expresii relaţionale imbricate (expresii relaţionale în care operanzii pot fi ei înşişi expresii relaţionale);

- o bază de date relaţională este o colecţie de relaţii de diverse grade

(gradul unei relaţii este dat de numărul de atribute ce definesc relaţia respectivă). Având în vedere faptul că prin operaţia de actualizare la momente diferite de timp conţinutul bazei de date se modifică, Date defineşte în [DATE04] variabila de relaţie ca fiind variabila care la un moment dat conţine valoarea relaţiei respective şi astfel o bază de date relaţională este definită de o colecţie de variabile de relaţie. Raportat la reprezentarea structurii datelor în modelul relaţional, variabilei de relaţie îi corespunde schema de relaţie. Variabilele de relaţie iniţiale se numesc variabile de relaţie de bază, iar cele definite prin intermediul unor expresii relaţionale utilizând variabile de relaţie de bază sunt numite variabile de relaţie derivate. O categorie importantă de variabile de relaţie derivate în modelul relaţional o constituie vederile, care sunt relaţii (tabele) virtuale pentru care în baza de date se va memora doar expresia relaţională de definire a vederii şi care vor putea fi utilizate ca şi tabelele reale. În mod analog cu vederile se definesc instantaneele prin care se realizează copii ale anumitor date din baza de date şi care pe lângă definiţia interogării conţin şi datele rezultate din interogare numai pentru citire, putând fi reîmprospătate periodic prin reluarea interogării corespunzătoare. SGBD-urile realizate după modelul relaţional constituie a doua generaţie de sisteme SGBD.

Majoritatea sistemelor SGBD comerciale din prima şi a doua generaţie, aflate în exploatare au fost proiectate pentru a satisface cerinţele aplicaţiilor din domeniul afacerilor şi anume: probleme de gestiune a întreprinderilor (personal, salarii, magazii, producţie), sisteme de rezervare a locurilor (transporturi, staţiuni, hoteluri, etc.), sisteme de gestiune biblioteci, sisteme financiar-bancare, aplicaţii care se caracterizează prin efectuarea unor operaţii relativ simple asupra unor volume mari de date. Limbajele de manipulare utilizate în cadrul acestor sisteme rezolvă problema accesului operativ la volume mari de date, însă au o putere de expresie limitată considerabil mai redusă faţă de cea a limbajelor de programare convenţionale cum ar fi: PASCAL, COBOL, FORTRAN etc. Spre exemplu, limbajele LMD utilizate în cadrul SGBD-urilor relaţionale, nu permit exprimarea operaţiilor cu

24

caracter recursiv. Limitarea limbajelor LMD la posibilitatea exprimării doar a unor operaţii simple s-a impus din următoarele două motive:

- optimizarea timpului de răspuns prin utilizarea optimizatoarelor; - simplitatea utilizării acestor limbaje le face accesibile unor categorii largi de utilizatori.

Întrebări

1. Principalele modalităţi de organizare a datelor pe suporturi externe de memorare sunt:

a) Fişierul;

b) Tabela;

2. O bază de date este:

c)Înregistrarea;

d) Dosarul;

e) Baza de date.

a) o colecţie de date organizată şi gestionată sub un software numit SGBD;

b) un ansamblu de date în memoria internă a calculatorului;

c) o aplicaţie care gestionează un volum mare de date.

3. Sistemul de Gestiune a Bazei de Date (SGBD) este:

a) Un pachet de programe pentru realizarea asistată de calculator a sistemelor informatice;

b) Un sistem de programe care permite definirea, crearea întreţinerea şi interogarea bazei de date precum şi accesul controlat la baza de date;

c) Un sistem de programe pentru interogarea bazei de date.

4. Prezentaţi cele 3 nivele ale arhitecturii ANSI-SPARC pe 3 nivele ale unei baze de date şi definiţi independenţa logică şi independenţa fizică de date.

5. Prezentaţi tipurile de legături care se pot defini între două mulţimi de entităţi.

6. Enumeraţi tipurile de aplicaţii din domeniul afacerilor.

7. Definiţi baza de date distribuită.

8. Definiţi conceptul multimedia în domeniul bazelor de date.

9. Definiţi arhitectura client-server pentru o bază de date.

10. Modelele de date utilizate în proiectarea SGBD-urilor sunt:

a)

Modelul conceptual;

b) Modelul fizic;

c) Modelul logic;

d)

Modelul relaţional;

e) Modelul semantic;

f) Modelul ierarhic;

g)

Modelul relaţional cu obiecte; h) Modelul orientat obiect;

i) Modelul reţea.

11. În modelul relaţional reprezentarea structurii datelor se realizează prin:

a) relaţii;

b) diagrama structurii datelor;

c) schema relaţională;

d) entităţi.

12. În modelul relaţional legăturile dintre tipurile de inregistrări pot fi realizate prin:

a)

Multiplicarea înregistrărilor;

b) Pointeri;

c) Propagarea cheilor;

d)

Crearea unor scheme de relaţie separate.

13. O cheie a unei relaţii poate fi:

a) Unul sau mai multe atribute oarecare, care identifică în mod unic tuplele relaţiei;

25

b) Orice atribut din cadrul relaţiei;

c) Un subset K de atribute din cadrul relaţiei care identifică unic tuplele relaţiei, subsetul K fiind minimal (eliminarea oricărui atribut din K duce la pierderea proprietăţii de identificare unică).

26

Capitolul 2 Tehnologii / Modele / Sisteme pentru aplicaţii avansate de baze de date

SGBD-urile realizate la sfârşitul anilor 60 şi începutul anilor 70 au la bază modelul ierarhic şi modelul reţea, constituind prima generaţie de sisteme SGBD. Principalele dezavantaje ale acestor două modele sunt: necesitatea scrierii unor programe complexe pentru realizarea interogărilor, bazate pe acces navigaţional orientat pe înregistrări, inexistenţa unui fundament teoretic, independenţa de date minimală. La începutul anilor 70 E.F. Codd a pus bazele modelului relaţional fundamentat pe algebra relaţiilor şi calculul relaţional. SGBD-urile realizate după acest model constituie a doua generaţie de SGBD-uri cu o largă răspândire (există astăzi peste 100 de sisteme SGBDR atât pentru sisteme mainframe cât şi pentru sisteme PC). Majoritatea sistemelor SGBD comerciale aflate în exploatare au fost proiectate pentru a satisface cerinţele aplicaţiilor din domeniul afacerilor şi anume :

-

probleme de gestiune a întreprinderilor (personal, salarii, magazii, producţie,

etc.);

-

sisteme de rezervare a locurilor (transporturi, staţiuni, hoteluri, etc.);

-

sisteme de gestiune biblioteci;

- sisteme financiar-bancare, etc. care se caracterizează prin efectuarea unor operaţii relativ simple asupra unor volume mari de date. Limbajele de manipulare utilizate în cadrul acestor sisteme, rezolvă problema accesului operativ la volume mari de date, însă au o putere de expresie limitată, considerabil mai redusă faţă de cea a limbajelor de programare convenţionale cum ar fi: PASCAL, COBOL, FORTRAN etc. Spre exemplu, limbajele LMD utilizate în cadrul SGBD-urilor relaţionale, nu permit exprimarea operaţiilor cu caracter recursiv. Reducerea limbajelor LMD la posibilitatea exprimării doar a unor operaţii simple s-a impus din următoarele două motive:

- optimizarea timpului de răspuns mai ales în cazul când se operează asupra unor volume mari de date - prin utilizarea optimizatoarelor care pot exploata informaţii privind structurile fizice auxiliare (indecşi, tabele de dispersie, etc.) de care utilizatorul nu trebuie să aibă cunoştinţă. Prin optimizare, se poate obţine o reducere considerabilă a timpului de răspuns la interogări (ex.100.000 ori ); - simplitatea (uşurinţa) utilizării acestor limbaje le face accesibile unor categorii largi de utilizatori. Una din deficienţele modelelor de date utilizate în proiectarea SGBD-urilor din prima şi a doua generaţie, o constituie posibilităţile limitate de modelare. Astfel a fost definit conceptul de model semantic sau model extins încă din 1976, când Chen a prezentat modelul Entitate-Relatie (E/R), care constituie astăzi o tehnică larg acceptată pentru proiectarea bazelor de date. Modelul E/R permite proiectantului bazei de date să elaboreze un model conceptual, fără a ţine seama de anumite constrângeri impuse de cele trei modele care stau la baza proiectării SGBD-urilor, ceea ce permite o reprezentare mai fidelă a realităţii avute în vedere. Modelul conceptual astfel realizat constă dintr-o diagramă E/R, care ulterior poate fi transpusă în cadrul unuia din modelele : ierarhic, reţea, relaţional. Deci modelul E/R constituie o etapă intermediară în proiectarea unei baze

27

de date, fiind din acest punct de vedere asemănător pseudocodului utilizat în activitatea de programare. Necesitatea rezolvării unor probleme complexe care nu se încadrează în clasa de probleme din domeniul afacerilor pentru care au fost proiectate SGBD-urile din prima şi a doua generaţie, impune elaborarea de limbaje de manipulare cu putere de expresie mult mai apropiată de cea a limbajelor de programare convenţionale. Aceste aplicaţii sunt cunoscute [COBS01] sub denumirea de aplicaţii avansate de baze de date, sau [DATE04] aplicaţii ”complexe” şi includ :

- Proiectarea asistată de calculator CAD (Computer Aided Design);

- Fabricarea asistată de calculator CAM (Computer Aided Manufacturing);

- Ingineria programării asistată de calculator CASE (Computer Aided Software Engineering);

- Sistemele informaţionale de birou OIS (Office Information Systems) şi sistemele multimedia;

-

ziarelor,

articolelor şi

Information

Systems);

- Sistemele

furnizarea lor la consumatori prin reţele foarte rapide);

Editarea

digitală

(stocarea

electronică

a

GIS

cărţilor,

revistelor,

informaţionale

geografice

(Geographical

- Aplicaţii ştiinţifice şi medicale (ex. date complexe pentru modelele

moleculare ale compuşilor chimici sintetici, date complexe privind materialul genetic, etc.);

- Sisteme expert (cunoştinţe şi baze de reguli pentru aplicaţii de inteligenţă

artificială). Aplicaţiile avansate de baze de date de tipul celora enumerate mai sus necesită accesarea şi manipularea unor volume mari de date ca şi în cazul SGBD-urilor clasice, precum şi efectuarea unor operaţii mai complexe decât cele posibile în cadrul SGBD-urilor clasice. Pentru soluţionarea acestor probleme cercetările sunt îndreptate în două direcţii [DORO98] şi anume:

- utilizarea tehnologiei orientate obiect;

- utilizarea limbajelor de programare logică.

Utilizarea tehnologiei orientate obiect are în vedere realizarea unor sisteme de gestiune a bazelor de date prin care structurile de date sunt definite şi manipulate ca obiecte complexe având fiecare o identitate proprie şi putând fi grupate în clase ierarhizate pe nivele cu moştenirea proprietăţilor dinspre nivelele superioare către nivelele inferioare ale ierarhiei şi cu posibilitatea de a defini proceduri specifice pentru accesarea şi manipularea obiectelor de un anumit tip astfel încât o parte din complexitatea prelucrărilor este memorată în cadrul structurii de date. Abordarea logică are în vedere dezvoltarea de sisteme denumite SGBC (Sisteme de Gestiune a Bazelor de Cunoştinţe) [DORO98], sau Sisteme de Baze de Date Inteligente [IDBS02], sau SGBD deductive [PARC02], [SPAS02], [DATE04], care să răspundă pe de o parte cerinţelor oferite de un SGBD şi pe de altă parte să posede un limbaj declarativ cu o putere de expresie apropiată de cea a limbajelor convenţionale. Cercetările desfăşurate în această direcţie au în vedere adaptarea limbajelor logice de tip PROLOG la cerinţele impuse de manipularea unor volume mari de date întâlnite în cadrul SGBD-urilor. În acest sens sunt avute în vedere limbajele din familia DATALOG, care sunt considerate a fi intermediare între limbajele relaţionale şi limbajul PROLOG. Aceste limbaje sunt privite din două puncte de vedere opuse şi anume:

- un limbaj DATALOG este o extensie recursivă a unui limbaj relaţional;

28

- un limbaj de tip DATALOG este un limbaj PROLOG liber de funcţii, rezultat

prin eliminarea argumentelor de tip funcţie ale predicatelor în programele

PROLOG.

2.1. Utilizarea tehnologiei orientate obiect

Tehnologia orientată spre obiecte reprezintă o disciplină importantă în domeniul ingineriei software şi are în vedere faptul că utilizatorii trebuie să poată manipula obiecte şi operaţii cu acestea cât mai apropiate de echivalentele lor din lumea reală. Pentru a reprezenta în memoria calculatorului obiectele fizice sau noţiunile din lumea reală trebuie să avem în vedere atât proprietăţile caracteristice acestora cât şi operaţiile care pot fi efectuate, deci trebuie să avem în vedere datele ce descriu proprietăţile precum şi operaţiile care pot fi aplicate datelor. În cadrul tehnologiei orientate obiect informaţiile specifice obiectelor din lumea reală trebuie să fie păstrate la un loc (într-o zonă compactă) şi să poată fi prelucrate ca un tot unitar. De asemenea trebuie să avem în vedere modul cum reacţionează obiectul atunci când este supus la acţiuni exterioare. Reprezentarea datelor se va realiza prin intermediul tipurilor de date, iar a operaţiilor ce acţionează asupra datelor, prin intermediul funcţiilor. Spre sfârşitul anilor 80 s-a pus problema utilizării acestei tehnologii şi în domeniul bazelor de date.

2.1.1. Concepte utilizate în tehnologia orientată obiect

Un obiect este o entitate unic identificabilă, definită de un set de proprietăţi (atribute) şi de acţiunile (operaţiile) asociate acestuia. Identificarea aspectelor esenţiale ale unei entităţi şi ignorarea proprietăţilor nesemnificative se realizează prin operaţia de abstractizare care presupune atât încapsularea cât şi ascunderea informaţiilor. Pentru a proteja proprietăţile unui obiect la accesul din exterior în vederea menţinerii coerenţei valorilor memorate în interiorul obiectului este preferabil ca acele proprietăţi să poată fi modificate doar de operaţii definite în cadrul obiectului, operaţii ce vor verifica noile valori înainte de a face modificarea (se consideră în acest caz că proprietăţile obiectului sunt încapsulate în interiorul

acestuia [ROEU96]). Altfel spus [COBS01], încapsularea presupune că un obiect conţine atât structura de date cât şi operaţiile care pot fi utilizate pentru a-l manipula, iar ascunderea informaţiilor presupune separarea aspectelor externe ale unui obiect de detaliile sale interne care sunt ascunse faţă de lumea exterioară, astfel încât detaliile interne să poată fi schimbate fără a afecta aplicaţiile care îl utilizează, cu condiţia ca detaliile externe să rămână aceleaşi. De asemenea obiectul încapsulează şi modul de funcţionare a operaţiilor lui specifice, din exterior putându-se observa doar modul de apelare a acestor operaţii şi rezultatele apelurilor. Protejarea şi încapsularea proprietăţilor şi operaţiilor unui obiect face ca utilizatorul obiectului respectiv să fie independent de detaliile constructive ale obiectului, structura internă a obiectului putând fi schimbată şi perfecţionată fără ca funcţionalitatea de bază să fie afectată. Pentru fiecare proprietate şi operaţie a unui obiect se va specifica care sunt utilizatorii care au acces şi cei care nu au acces. În unele limbaje de programare orientate obiect, încapsularea este realizată cu ajutorul unor tipuri de date abstracte ADT (Abstract Data Type), caz în care un obiect are [COBS01] :

- o parte de interfaţă – care asigură specificarea operaţiilor care pot fi

executate asupra

obiectului;

29

- o parte de implementare – care constă în structura de date pentru tipurile ADT şi funcţiile care realizează interfaţa. Numai partea de interfaţă este vizibilă pentru alte obiecte sau utilizator. În cazul bazelor de date, acesta este modul corect de încapsulare prin care se asigură accesul doar la partea de interfaţă, putând astfel să schimbăm implementarea internă a unui ADT fără a modifica aplicaţiile care îl utilizează. Starea unui obiect este descrisă de unul sau mai multe atribute numite şi variabile de instanţă, starea curentă a obiectului fiind dată de valorile pe care le iau atributele respective la un moment dat. Atributele pot fi:

- simple – tipuri simple de date (ex. întreg, şir, real, etc.) care pot lua valori de tip literal;

- complexe - pot conţine colecţii (descriu colecţii de obiecte) şi/sau referinţe (atribute de referinţă, descriu relaţii dintre obiecte, pot conţine o valoare sau o colecţie de valori ce identifică obiecte). Un obiect care conţine unul sau mai multe atribute complexe se numeşte obiect complex. Pentru reprezentarea atributelor se utilizează notaţia “punct” astfel:

Angajat.Nume (precizează atributul Nume al obiectului Angajat). Acţiunile asociate obiectului, numite şi metode, sunt operaţii (funcţii) ce se vor aplica asupra valorilor atributelor. Setul de operaţii specifice unui obiect împreună cu modul cum acesta reacţionează la stimuli externi defineşte comportamentul obiectului. Metodele pot fi utilizate pentru schimbarea stării obiectelor, sau pentru interogarea valorilor atributelor sale. Spre exemplu, putem avea metode pentru a adăuga o persoană în baza de date, pentru reactualizarea salariului unei persoane existente în baza de date, sau pentru tipărirea la imprimantă a datelor referitoare la o persoană din baza de date. Mijloacele prin care comunică obiectele sunt mesajele. Exemplu. Pentru a executa metoda Creste_salariu asupra unui obiect Angajat de tip Personal şi a transmite metodei o valoare de creştere de 250000 se va scrie

Angajat.Creste_salariu(250000),

iar într-un limbaj de programare un mesaj poate fi scris ca o apelare de funcţie astfel

Creste_salariu(Angajat,250000)

În timp ce un obiect modelează atât starea cât şi comportamentul, o entitate modelează doar starea. În sistemele orientate pe obiecte, la crearea fiecărui obiect se generează automat un identificator de obiect OID care satisface condiţiile: este generat de sistem, este unic pentru acel obiect, nu poate fi modificat şi nici utilizat pentru identificarea altui obiect chiar dacă obiectul iniţial a fost şters, este independent de valorile atributelor sale, este invizibil pentru utilizatori. Spre deosebire de modelul relaţional unde unicitatea este impusă la nivel de relaţie prin cheia primară formată din valori ale unor atribute, identificatorul de obiect OID asigură unicitatea la nivelul întregului sistem. Două obiecte sunt identice (se notează “=”) dacă şi numai dacă ele reprezintă acelaşi obiect (adică identificatorii lor OID sunt aceiaşi). Două obiecte sunt egale (se notează “= =”) dacă stările lor sunt aceleaşi (au aceleaşi valori ale atributelor). Există două tipuri de identificatori OID şi anume:

- identificatori OID logici – care sunt independenţi de localizarea fizică a obiectelor pe disc;

- identificatori OID fizici – care codifică localizarea obiectelor pe disc.

Un sistem orientat pe obiecte trebuie să poată converti identificatorii OID în pointeri

de memorie şi invers (operaţie numită “mixare de pointeri” sau “object faulting”) în

30

cadrul operaţiilor de transfer al paginilor din memoria secundară în memoria principală şi invers. Există situaţii în care un obiect complex din lumea reală este format din subobiecte (obiecte conţinute) legate printr-un set de relaţii de tip A-PART-OF (APO

= o parte din). La rândul lor subobiectele pot fi ele însele obiecte complexe, ceea ce permite construirea unei ierarhii de tip A_PART_OF. Un subobiect poate fi manipulat

în două moduri:

- poate fi încapsulat în obiectul complex formând o parte a acestuia şi în acest caz poate fi accesat numai cu metodele obiectului complex;

- poate fi considerat ca având o existenţă independentă de cea a obiectului

complex – caz în care în obiectul complex este stocat doar identificatorul OID al obiectului conţinut care are structura şi metodele lui proprii şi poate fi deţinut de diverse obiecte părinte. Astfel de tipuri de obiecte sunt denumite obiecte complexe structurate, spre deosebire de obiectele complexe nestructurate cunoscute în domeniul bazelor de date sub denumirea de obiecte binare mari (BLOB – Binary Large OBject) a căror structură poate fi interpretată doar de programe aplicaţie. În lumea reală se pot identifica clase (familii) de obiecte similare, definite de aceleaşi proprietăţi. Atributele şi metodele asociate sunt definite o singură dată pentru clasă şi nu separat pentru fiecare obiect al clasei. Deci atributele sunt aceleaşi pentru întreaga familie de obiecte, dar valorile atributelor pot diferi de la un obiect la altul. De asemenea operaţiile sunt întotdeauna aceleaşi însă rezultatul aplicării lor poate să difere în funcţie de valorile atributelor obiectului asupra cărora sunt aplicate. Rezultatul aplicării operaţiilor nu depinde numai de valorile atributelor obiectului respectiv, ci şi de unele valori exterioare acestuia. O clasă poate fi privită ea însăşi ca un obiect având propriile atribute şi metode ce descriu caracteristicile generale ale clasei (ex. totaluri, medii, etc.). Obiectele unei clase se numesc instanţe ale clasei. Există metode speciale ale clasei pentru crearea de noi instanţe şi distrugerea celor inutile. De obicei metodele pentru crearea de noi instanţe sunt numite constructori, iar cele de distrugere a instanţelor sunt denumite destructori. Unele obiecte pot avea atribute şi metode comune, deci se poate pune problema partajării acestora în vederea definirii unei clase mai generale. Cazurile speciale sunt numite subclase, iar cazurile mult mai generale superclase. Procesul de formare a unei superclase se numeşte generalizare, iar procesul de formare a unei subclase se numeşte specializare. În sistemele orientate pe obiecte, moştenirea permite ca o clasă să fie definită ca un caz special al unei clase mult mai generale. O subclasă moşteneşte

implicit toate proprietăţile (atributele şi metodele) superclasei sale şi în plus defineşte proprietăţi specifice. Toate instanţele subclasei sunt şi instanţe ale superclasei. Relaţia dintre subclasă şi superclasă este numită A-KIND-OF (AKO) în traducere “un fel de”, iar relaţia dintre o instanţă şi clasa ei este denumită IS-A (este un, o). Prin operaţia de definire a unei noi clase de obiecte pe baza uneia deja existente, operaţie numită şi derivare (sau extindere) [ROEU96], rezultă o ierarhizare

a claselor de obiecte. Este foarte dificil de definit o ierarhie de clase de obiecte

completă (care să reprezinte realitatea înconjurătoare în totalitatea ei), însă pentru o problemă dată se vor defini doar acele concepte implicate în rezolvarea problemei respective. Ierarhizarea se poate extinde pe mai multe nivele sub formă arborescentă. În cadrul ierarhiei se pot întâlni următoarele tipuri de moştenire

[COBS01]:

- moştenire simplă – subclasele moştenesc o singură superclasă;

31

- moştenire multiplă – o subclasă poate moşteni mai multe superclase. Nu

toate limbajele şi sistemele de gestiune a bazelor de date acceptă moştenirea multiplă, deoarece aceasta introduce un nivel de complexitate greu de administrat (ex. rezolvarea conflictelor care apar atunci când superclasele conţin aceleaşi atribute sau metode);

- moştenire repetitivă – caz special de moştenire multiplă în care superclasele

moştenesc o superclasă comună;

- moştenire selectivă – o subclasă moşteneşte doar anumite atribute şi metode ale superclasei. Unele dintre atributele şi operaţiile definite în superclasă pot fi redefinite în subclasele de obiecte derivate cu menţiunea că vechile atribute şi operaţii sunt disponibile în continuare, însă pentru a le putea accesa va trebui specificată explicit superclasa care deţine copia redefinită. Această redefinire a unor atribute sau operaţii se numeşte rescriere sau supracopiere, ceea ce conferă flexibilitate în definirea unei ierarhii, deoarece nici un atribut sau operaţie definite într-un punct al ierarhiei nu sunt impuse definitiv pentru conceptele derivate, permiţând manipularea cu uşurinţă a cazurilor speciale cu un impact minim asupra restului sistemului. Un caz mult mai general decât supracopierea, este supraîncărcarea, care permite ca numele de metode să fie reutilizate în definirea unei clase sau pe parcursul definirii claselor, ceea ce înseamnă că un singur mesaj poate avea diferite funcţii, depinzând de tipul obiectului ce primeşte mesajul şi de parametrii transmişi metodei. Spre exemplu pentru diverse clase se poate defini o metodă de tipărire a datelor relevante ale unui obiect. Astfel este posibil ca acelaşi nume să fie utilizat pentru aceeaşi operaţie, independent de tipul clasei asupra căreia acţionează. Se defineşte un concept mult mai general denumit polimorfism care poate fi de unul din următoarele trei tipuri [COBS01]:

- polimorfism de incluziune – cazul unei metode definite într-o superclasă şi moştenită în subclasele ei;

- polimorfism operaţional – supraîncărcarea;

- polimorfism parametric, sau generic – utilizează tipurile ca parametri în declaraţiile generice ale tipului sau clasei, descrierea generică acţionând ca un şablon pentru crearea ulterioară a uneia sau mai multor metode de tipuri diferite (ex. template). Selecţia metodei corespunzătoare pe baza tipului de obiect se numeşte legare. Dacă determinarea tipului de obiect poate fi făcută în momentul execuţiei (în loc de momentul compilării), atunci selecţia este denumită legare dinamică (întârziată). O categorie aparte a claselor de obiecte este constituită din acele clase ce reprezintă concepte care nu se pot instanţia direct întrucât nu avem suficiente informaţii pentru a construi instanţe. Astfel de clase neinstanţiabile sunt clase abstracte şi servesc pentru definirea unor proprietăţi sau operaţii comune mai multor clase şi pentru generalizarea operaţiilor referitoare la aceste clase. Dacă o clasă de obiecte are cel puţin o metodă abstractă, această clasă va fi în întregime o clasă abstractă şi nu va putea fi instanţiată. Clasele de pe orice nivel pot avea instanţe proprii cu condiţia să nu fie clase abstracte.

2.1.2. Modele de date bazate pe tehnologia orientată spre obiecte

Tehnologia orientată obiect stă la baza elaborării a două noi modele de date pentru rezolvarea problemelor puse de realizarea aplicaţiilor avansate de baze de date şi anume:

- Modelul de date orientat spre obiecte OODM (Object Oriented Data Model);

32

- Modelul de date relaţional cu obiecte ORDM (Object Relational Data Model).

SGBD-urile realizate după aceste modele reprezintă a treia generaţie de sisteme SGBD constituită din:

- Sisteme de Gestiune a Bazelor de Date Orientate Obiect (SGBDOO sau OODBMS - Object Oriented Data Base Management System);

- Sisteme de Gestiune a Bazelor de Date Obiect Relaţionale (SGBDOR sau ORDBMS - Object Relational Data Base Management System). Modelul de date orientat spre obiecte ODMG Un model de date orientat spre obiecte OODM (Object Oriented Data Model) este un model logic de date care conţine semantica obiectelor, acceptată în programarea orientată spre obiecte (Kim 1991). Până la această dată, nu există un model de date orientat spre obiecte, fundamentat teoretic, universal recunoscut, echivalent modelului de date care stă la baza sistemelor relaţionale. În vederea elaborării de standarde pentru sistemele SGBDOO, producători importanţi printre care: GemStone Systems, Object Design, O2 Technology, Versant Object Technology, UniSQL, POET Software, Objectivity, Lockheed Martin şi IBEX Computing, au format grupul de administrare a bazelor de date de obiecte ODMG. În 1993 grupul ODMG a realizat versiunea iniţială a standardului ODMG, iar în 1997 versiunea ODMG 2.0, având în vedere specificaţiile documentului “Object Management Architecture (OMA) Guide”, publicat în 1990 de grupul principalilor producători de hardware şi software OMG (Object Management Group), document

ce conţine specificaţii privind tehnologia orientată spre obiecte şi în cadrul căruia este definit modelul de obiecte OM (Object Model) care constituie un model abstract de proiectare pentru comunicarea cu sistemele orientate spre obiecte. În concepţia OMG, arhitectura unui sistem SGBDOO va conţine:

- modelul de obiecte OM (Object Model);

- limbajul de definire a obiectelor ODL (Object Data Language);

- limbajul de interogare a obiectelor OQL (Object Query Language);

- interfeţe cu limbajele C++, Smalltalk, Java. Modelul de obiecte OM conţine următoarele specificaţii pentru modelare:

- Primitivele de bază pentru modelare sunt obiectul şi literalul. Fiecare obiect are un identificator unic care nu poate fi modificat sau reutilizat pentru alte obiecte;

- Literalul şi obiectele pot fi clasificate în tipuri. Toate obiectele de un tip dat sunt caracterizate de un comportament şi o stare comună. Un tip de obiect este el însuşi un obiect. Tipurile de obiecte pot fi ierarhizate într-o reţea supertip-subtip în care proprietăţile şi operaţiile unui supertip sunt moştenite de subtipurile sale;

- Comportamentul unui obiect este definit de un set de operaţii care pot fi efectuate asupra obiectului sau de către obiect;

- Starea unui obiect este definită de valorile pe care le au proprietăţile obiectului la un moment dat, o proprietate putând fi, fie un atribut al obiectului, fie o relaţie dintre acel obiect şi unul sau mai multe alte obiecte;

- Baza de date este definită prin schemă care este creată cu ajutorul limbajului de definire a obiectelor (ODL) şi stochează instanţe ale obiectelor definite de schema sa ce pot fi partajate între utilizatori şi aplicaţii multiple. Pentru crearea instanţelor se utilizează metoda new(). Tipurile de obiecte sunt descompuse în tipuri atomice, colecţii şi tipuri structurate. O colecţie poate conţine un număr de elemente omogene de orice tip, fiecare putând fi o instanţă a unui tip atomic, o altă colecţie sau un tip literal. Există colecţii ordonate şi colecţii neordonate. Colecţiile ordonate trebuie parcurse de la

33

primul element până la ultimul element sau viceversa în procesul de iteraţie. În cadrul modelului sunt specificate 5 subtipuri de colecţii şi anume:

- Set

-

colecţii neordonate care nu permit duplicate;

- Bag

-

colecţii neordonate care permit duplicate;

- List

- Array - şir unidimensional a cărui lungime variază dinamic;

- Dictionary

- colecţii ordonate care permit duplicate;

- secvenţă neordonată a perechilor de valori cheie.

Fiecare subtip are operaţii pentru a crea o instanţă a tipului şi a introduce elemente

în colecţie.

Tipurile literale pot fi atomice, colecţii, structurate sau null. Tipurile literale nu au identificatori proprii şi singure nu pot constitui obiecte; fiind însă înglobate în obiecte. Tipurile literale structurate conţin un număr fix de elemente eterogene, fiecare element fiind o pereche <nume, valoare >, unde valoare poate fi orice tip literal.

Modelul defineşte două tipuri de proprietăţi şi anume: atribute şi relaţii. Un atribut este definit pentru un singur tip de obiect, iar relaţiile sunt definite între tipuri, modelul OM oferind suport doar pentru relaţiile binare 1:1, 1:n, m:n. În cadrul modelului sunt definite metadatele (date despre date). De asemenea este acceptat conceptul de tranzacţie – ca unitate logică de lucru ce transformă baza de date dintr-

o stare coerentă în alta. Modelul OM este [COBS01] “un model abstract de

proiectare portabil pentru comunicarea cu sistemele orientate spre obiecte” conform specificaţiilor OMG după schema din figura 2.1.

Solicitant

Cerere
Cerere

BROKER DE

CERERE

DE OBIECTE

(ORB)

Solicitant Cerere BROKER DE CERERE DE OBIECTE (ORB) Furnizori Mesaj Fig. 2.1. Modelul de obiecte OMG
Furnizori Mesaj
Furnizori
Mesaj

Fig. 2.1. Modelul de obiecte OMG (sursa [COBS01])

Brokerul ORB (Object Request Broker) este o magistrală software distribuită care permite obiectelor (solicitanţilor, aplicaţiilor) să emită cereri şi să recepţioneze răspunsuri de la furnizor. Solicitantul trimite o cerere la brokerul ORB, care ţine evidenţa tuturor obiectelor din sistem şi a tipurilor de servicii pe care le poate asigura. Brokerul expediază mesajul către furnizor care acţionează asupra mesajului şi transmite înapoi un răspuns la solicitant prin intermediul brokerului. Limbajul ODL permite definirea tipurilor de obiecte şi a relaţiilor dintre acestea, fiind echivalent cu limbajul de definire a datelor DDL al sistemelor SGBD tradiţionale. Limbajul OQL permite interogarea bazei de date de obiecte utilizând o sintaxă asemănătoare limbajului SQL. Nu conţine operatori de reactualizare a bazei, întrucât această sarcină va fi executată de operaţiile definite pentru tipurile de obiecte. Poate fi utilizat atât ca limbaj autonom cât şi ca limbaj înglobat într-un alt limbaj (C++, Smalltalk, Java).

2.1.3. Sisteme de gestiune a bazelor de date orientate spre obiecte (SGBDOO) Având în vedere specificaţiile prezentate mai sus şi din analiza unor sisteme SGBDOO comerciale printre care: GemStone, ObjectStore, Itasca, Ontos, O2, Poet,

34

Versant, se poate constata că în cadrul modelelor de date orientate spre obiecte sunt preluate o serie de concepte din diverse domenii astfel:

- Sisteme de baze de date tradiţionale: persistenţa, tranzacţii, controlul concurenţei, controlul refacerii, securitate, integritate, interogare;

- Modele de date semantice: generalizare, agregare;

- Programarea orientată spre obiecte: identitatea obiectelor, încapsulare, moştenire, tipuri şi clase, metode, obiecte complexe, polimorfism.

Probleme specifice sistemelor SGBDOO Probleme specifice sistemelor SGBDOO sunt: modele de tranzacţii avansate, administrarea versiunilor obiectelor, evoluţia schemei bazei de date. Tranzacţiile care operează cu obiecte complexe, întâlnite în aplicaţii avansate de baze de date, pot dura ore, zile sau mai mult, fiind numite şi tranzacţii de lungă durată, ceea ce necesită protocoale de control al concurenţei diferite de cele utilizate

pentru tranzacţiile de scurtă durată întâlnite în aplicaţiile obişnuite de baze de date. În acest sens, se utilizează protocoale bazate pe supraveghere prin care este evitată apariţia conflictelor, controlul concurenţei împiedicând interferarea accesărilor. Având în vedere faptul că în sistemele SGBDOO unitatea de control a concurenţei şi refacerii este obiectul, pentru a evita anularea tranzacţiilor datorită conflictelor de zăvorâre se utilizează două noi mecanisme şi anume: modele de tranzacţii avansate, administrarea versiunilor obiectelor. Se definesc următoarele modele de tranzacţii avansate: tranzacţii imbricate, saga, tranzacţii cu niveluri multiple. În modelul de tranzacţii imbricate (introdus de Moss în 1981), o tranzacţie este descompusă într-o ierarhie (arbore) de subtranzacţii care se execută de jos în sus şi în care subtranzacţiile unei tranzacţii părinte se execută ca şi cum ar fi tranzacţii separate. Saga este o tranzacţie cu un singur nivel de imbricare în care pentru fiecare subtranzacţie există o tranzacţie compensatoare. La execuţia unei saga poate avea loc una din următoarele două situaţii:

1. toate subtranzacţiile se execută cu succes;

2. o subtranzacţie eşuează, este abortată şi se rulează subtranzacţii compensatoare

pentru recuperare. Astfel de tranzacţii pot fi utilizate dacă subtranzacţiile sunt independente şi se pot defini subtranzacţii compensatoare. În modelul de tranzacţii cu niveluri multiple arborele subtranzacţiilor este echilibrat (Weikum şi Schek 1991), ceea ce presupune că două operaţii aflate la un anumit nivel pot să nu fie în conflict chiar dacă implementările lor de la nivelul imediat inferior sunt în conflict. Cunoscând informaţiile despre conflicte pe niveluri, utilizarea tranzacţiilor cu niveluri multiple permite un grad mai mare de concurenţă faţă de utilizarea altor tipuri de tranzacţii. Există situaţii care necesită accesul la versiuni anterioare ale unui obiect (spre exemplu în dezvoltarea unui proiect este necesar să se stocheze evoluţia obiectelor proiectate şi a modificărilor efectuate în proiect pe parcursul realizării acestuia). Metoda utilizată în astfel de situaţii este păstrarea evoluţiei obiectelor, proces cunoscut sub denumirea de administrarea versiunilor. O versiune a unui obiect este o stare identificabilă a acestuia, iar istoricul versiunilor reprezintă evoluţia obiectului. Versiunile unui obiect pot fi ordonate prin utilizarea mărcilor de timp şi utilizatori diferiţi pot lucra în acelaşi timp cu versiuni diferite ale aceluiaşi obiect, ceea ce reprezintă o alternativă în locul utilizării tranzacţiilor avansate pentru creşterea

35

gradului de concurenţă. Produse comerciale printre care: Ontos, Versant, ObjectStore, Objectivity/DB, Itasca, sunt prevăzute cu facilităţi de administrare a versiunilor. Având în vedere faptul că proiectarea este un proces care evoluează în timp, este necesară posibilatea definirii şi modificării dinamice a schemei bazei de date. În acest sens în cursul procesului de proiectare pot surveni următoarele tipuri de modificări:

- modificări în definiţia claselor (modificare atributelor, modificare metode);

- modificări în structura de moştenire (crearea unei superclase, eliminarea unei superclase, modificarea ordinii superclaselor unei clase);

- modificări în setul de clase (crearea unei noi clase, ştergerea unei clase,

modificarea numelui unei clase). Aceste schimbări trebuie să poată fi realizate fără oprirea sistemului sau fără implicaţii majore asupra sistemului. Pentru îndeplinirea acestor deziderate, unele produse comerciale printre care Itasca şi GemStone definesc o serie de reguli care trebuie respectate la efectuarea modificărilor schemei.

Reguli de bază pentru sistemele SGBDOO În 1989 Atkinson ş.a. au propus 13 reguli pe care trebuie să le îndeplinească un sistem SGBDOO, având în vedere pe de o parte faptul că un astfel de sistem trebuie să fie orientat spre obiecte şi pe de altă parte faptul că trebuie să

îndeplinească cerinţele unui SGBD. Primele 8 reguli se referă la partea privind orientarea spre obiecte, iar următoarele 5 reguli se referă la caracteristicile SGBD ale sistemului. Cele 13 reguli sunt enumerate în cele ce urmează:

1. Crearea obiectelor complexe prin aplicarea constructorilor SET, TUPLE, LIST sau ARRAY la obiectele de bază;

2. Asigurarea identităţii obiectelor, independentă de valorile atributelor lor;

3. Realizarea încapsulării;

4. Posibilitatea creării de tipuri sau clase;

5. Tipurile sau clasele trebuie să poată moşteni atributele şi metodele de la supertipurile sau superclasele lor;

6. Trebuie oferit suport pentru legarea dinamică;

7. Limbajul de manipulare DML trebuie să posede completitudine de calcul;

8. Mulţimea tipurilor de date trebuie să poată fi extinsă cu noi tipuri pe baza tipurilor predefinite de sistem fără deosebire de tratare între tipurile predefinite şi tipurile definite de utilizator;

9. Asigurarea persistenţei datelor (adică datele trebuie să rămână şi după finalizarea aplicaţiei care le-a creat, fără intervenţia utilizatorului);

10. Posibilitatea administrării unor volume foarte mari de date;

11. Asigurarea accesului concurent la date şi controlul concurenţei;

12. Asigurarea refacerii bazei de date în urma unor incidente hardware şi software;

13. Asigurarea unor modalităţi simple de interogare a datelor, independentă de aplicaţii. Opţional se propune: moştenire multiplă, distribuţia printr-o reţea, tranzacţii şi administrarea versiunilor. Nu sunt făcute precizări privind: securitatea, integritatea, vederile. Având în vedere aspectele prezentate mai sus privind sistemele SGBDOO, în cele ce urmează sunt puse în evidenţă avantaje şi dezavantaje ale acestora. Avantaje:

36

- facilităţi sporite de modelare (modelarea prin obiecte permite o reprezentare

mult mai fidelă a obiectelor din lumea reală şi a legăturilor dintre acestea);

- extensibilitate

moştenire

proprietăţi şi metode se pot extinde nelimitat elementele predefinite de sistem);

(prin

definirea

de

tipuri

de

date

abstracte

şi

- putere de expresie sporită pentru limbajele de interogare a bazei de date (prin utilizare de limbaje de tip navigaţional);

- suport pentru evoluţia schemei (facilităţi de modificare dinamică a schemei bazei de date pe parcursul procesului de proiectare);

- suport pentru tranzacţii de lungă durată (prin utilizarea unor modele de tranzacţii avansate şi/sau a versiunilor obiectelor);

- facilităţi sporite pentru proiectarea şi exploatarea aplicaţiilor avansate de baze de date. Dezavantaje:

- lipsa unui model de date fundamentat teoretic şi unanim acceptat;

- lipsa de experienţă, inaccesibilitate pentru utilizatorii începători şi limitarea utilizării la o piaţă restrânsă;

- lipsa de standarde pentru modele de date, limbaje de interogare;

- optimizarea interogării bazei de date contravine încapsulării informaţiilor;

- performanţe scăzute în accesul concurent mai ales în cazul ierarhiilor de obiecte (unitatea de acces şi control al concurenţei fiind obiectul, se impune zăvorârea la nivel de obiect);

- complexitatea ridicată conduce la creşterea preţului şi dificultăţi în utilizarea sistemului;

- lipsa de suport pentru securitate, integritate şi vederi.

şi ascunderii

Metode utilizate pentru realizarea unui SGBDOO Analizând produsele SGBDOO existente se constată (Khosafian şi Abnous, 1990) utilizarea uneia din următoarele metode pentru elaborarea unui SGBDOO:

- extinderea unui limbaj de programare orientat spre obiecte cu facilităţi ale

bazelor de date (GemStone extinde limbajele Smalltalk, C++, Java);

- realizarea de biblioteci SGBD extensibile orientate spre obiecte, ce conţin clase care susţin persistenţa, gruparea, tipuri de date, tranzacţii, securitatea etc. şi care vor putea fi apelate în cadrul unui limbaj de programare orientat spre obiecte. În acest mod sunt realizate produsele Ontos, Versant, Object Store;

- încapsularea construcţiilor limbajului de baze de date orientat spre obiecte

într-un limbaj gazdă convenţional (spre exemplu O2 furnizează extensii încapsulate pentru limbajul de programare C);

- extinderea unui limbaj de baze de date cu facilităţi de orientare spre obiecte

(ex. SQL3). Această strategie este utilizată şi în cadrul sistemelor relaţionale cu

obiecte. Standardul ODMG defineşte un standard pentru limbajul Object SQL. Produsele Ontos, Versant şi O2 dispun de o versiune a limbajului Object SQL;

- elaborarea unui nou model/limbaj original pentru bazele de date. În acest mod este realizat sistemul SIM (Semantic Information Manager) care se bazează pe modelul de date semantic şi are un limbaj DML/DDL original.

2.1.4. Sisteme de gestiune a bazelor de date relaţionale cu obiecte (SGBDOR) Având în vedere răspândirea largă şi popularitatea de care se bucură sistemele relaţionale, producătorii de sisteme relaţionale consideră că modalitatea

37

cea mai eficientă de a remedia insuficienţele modelului relaţional pentru rezolvarea aplicaţiilor avansate de baze de date, este de a-l extinde cu noi caracteristici de orientare spre obiecte şi anume: posibilitatea definirii de noi tipuri de date de către utilizator (UDT), încapsularea, moştenirea, polimorfismul, legarea dinamică a metodelor, obiecte complexe, identitatea obiectelor, stocarea de metode sau proceduri în baza de date în mod asemănător datelor. Se obţine astfel un hibrid dintre sistemul SGBDR şi sistemul SGBDOO denumit SGBDOR, care păstrează cunoştinţele şi experienţa obţinute cu sistemele relaţionale şi în plus înglobează o serie de caracteristici ale sistemelor orientate spre obiecte. Orientarea spre obiecte necesită suport adecvat pentru tipurile de date şi moştenirea tipurilor, suport care există deja în modelul relaţional, fiind reprezentat de domenii (tipuri) şi în acest context Date afirmă în [DATE04] că ”nu trebuie să facem nimic în modelul relaţional

afară de a le

pentru a obţine funcţionalitatea obiectelor în sistemele relaţionale

implementa în totalitate şi adecvat”. În acest sens încă din 1991 s-a trecut la extinderea standardului SQL2 cu facilităţi de orientare spre obiecte în vederea definirii standardului SQL3 finalizat la sfârşitul anului 1999, iar la sfârşitul anilor 90, producători importanţi de sisteme relaţionale au lansat produse SGBD obiect- relaţionale întitulate servere universale printre care: Universal Database a produsului DB2, Universal Data Option for Informix Dynamic Server, Oracle Universal Server.

în

Concluzii privind sistemele SGBDOR În SQL3 obiectele devin persistente doar atunci când sunt stocate în tabele şi întrucât identitatea obiectelor poate fi funcţie de poziţia în tabel rezultă că identitatea obiectelor poate fi modificată. De asemenea interogările în SQL3 se aplică numai tabelelor, ceea ce înseamnă că utilizatorii trebuie să realizeze trecerea de la instanţele obiectelor la tabele, să interogheze tabelele şi apoi să realizeze transformarea inversă. O altă deficienţă a limbajului SQL3 o constituie utilizarea indecşilor de tip arbori B+ care constituie o metodă de acces unidimensională pentru date alfanumerice şi neadecvată pentru accesul multidimensional întâlnit în sistemele GIS, telemetrie şi sisteme de creare a imaginilor. În vederea eliminării acestei deficienţe, unele sisteme SGBDOR încep să accepte tipuri suplimentare de indexuri cum ar fi:

- arbori B+ generici care permit construirea de arbori B+ pe orice tip de date şi nu numai pe cele alfanumerice;

- arbori R pentru accesul la datele bidimensionale şi tridimensionale (Gutman

1984).

Sistemele SGBDOR au avantaje şi dezavantaje, enumerate în cele ce urmează. Avantaje:

- păstrează cunoştinţele şi experienţa acumulate cu sistemele SGBDR;

- costul trecerii la orientarea spre obiecte este redus;

- standardul SQL3 este astfel proiectat încât să fie compatibil cu standardul

SQL2.

Dezavantaje:

- se pierde simplitatea şi puritatea modelului relaţional;

- nu sunt tratate modele de obiecte ci sunt extinse relaţiile din modelul

relaţional (obiectele persistă doar stocate în tabele şi interogările se aplică numai tabelelor);

- suport limitat pentru metode de acces multidimensional la date.

38

Având în vedere experienţa şi rezultatele obţinute cu sistemele SGBDR precum şi neajunsurile acestor tipuri de sisteme pentru rezolvarea unor aplicaţii avansate de baze de date, trei dintre producătorii importanţi de sisteme SGBDR şi anume Oracle, IBM şi Informix şi-au extins sistemele SGBDR pentru a deveni sisteme SGBDOR. În vederea definirii caracteristicilor sistemelor de baze de date din generaţia a treia, au fost publicate o serie de manifeste [COBS01] în care recomandările privind orientarea spre obiecte ocupă un loc important, însă din anumite puncte de vedere există poziţii diametral opuse. Astfel în “Manifestul sistemelor de baze de date din a treia generaţie” publicat de Comitetul pentru funcţii avansate ale sistemelor SGBD (CADF), referitor la limbajul SQL se face menţiunea : “…la bine şi la rău limbajul SQL constituie limbajul de date intergalactic, iar în “Cel de-al treilea manifest” realizat de Darwen şi Date (1995,1998) se menţionează că “modelul relaţional nu are nevoie de nici o extindere, corecţie, ipoteză suplimentară şi, mai presus de toate, de nici o transformare”, totuşi limbajul SQL este respins fără echivoc ca o transformare a modelului şi în schimb este propus un nou limbaj denumit D din care să poată fi utilizat limbajul SQL pentru utilizatorii existenţi ai acestuia.

2.2. Proiectarea conceptuală a bazelor de date Dependenţe în bazele de date, normalizarea relaţiilor, forme normale

Între atributele unei relaţii sau între atribute din relaţii diferite pot exista anumite legături logice (dependenţe), care influenţează proprietăţile schemelor de relaţie în raport cu operaţiile curente care intervin în timpul exploatării bazei de date:

adăugare, ştergere, actualizare. Aceste legături logice, cunoscute în literatura de specialitate sub denumirile de dependenţele funcţionale, dependenţele multivalorice şi dependenţe de cuplare, au implicaţii majore asupra criteriilor de proiectare a schemelor relaţionale. Alegerea unui model conceptual convenabil pentru o bază de date relaţională poate necesita realizarea unor descompuneri pentru anumite scheme de relaţie date, descompuneri care să izoleze dependenţele existente şi prin aceasta să elimine anomaliile care se datorează acestor dependenţe.

2.2.1. Dependenţe funcţionale Penru definirea acestui tip de dependenţe se consideră schema de relaţie Prestari_Servicii (Cod, Nume_client, Adresa, Serviciu_prestat, Valoare) definită pentru urmărirea serviciilor prestate de o firmă pentru diverşi clienţi. Atributul Adresa este dependent de atributul Nume_client (presupunând că fiecare client are o singură adresă, rezultă că fiecare valoare a atributului Nume_client determină în mod unic valoarea corespunzătoare a atributului Adresa). Analizând schema de relaţie de mai sus, se constată o redundanţă relativ la atributul Adresa a

cărei valoare este repetată pentru un client pentru fiecare serviciu prestat pentru acest client, ceea ce conduce la apariţia următoarelor anomalii:

- Anomalia la adăugare:

adresa unui client poate fi preluată numai după ce pentru acesta se prestează cel puţin un serviciu.

- Anomalia la ştergere:

dacă se şterg toate serviciile prestate pentru un anumit client, se pierde adresa acestui

client.

- Anomalia la actualizare:

39

datorită redundanţei relativ la atributul Adresa, dacă se schimbă adresa unui client este necesară parcurgerea întregii relaţii pentru a identifica şi actualiza toate apariţiile acestui client, în caz contrar baza de date devine inconsistentă (acelaşi client poate apare la adrese diferite). Aceste anomalii pot fi eliminate, dacă schema de relaţie Prestari_Servicii se înlocuieşte prin următoarele două scheme de relaţie:

Clienti(Cod, Nume_client, Adresa) Servicii(Cod, Serviciu_prestat, valoare) Relaţia Clienti conţine codul, numele şi adresa fiecărui client, fără nici un fel de redundanţă, iar relaţia Servicii conţine serviciile prestate pentru fiecare client şi valorile acestor servicii. Un dezavantaj al descompunerii relaţiei iniţiale în cele două relaţii este acela că pentru a determina adresa clientului pentru care s-a prestat un anumit serviciu este necesară efectuarea unei operaţii de cuplare a relaţiilor Clienti şi Servicii. Se consideră o schemă de relaţie R şi A,B două atribute simple sau compuse ale schemei de relaţie R. Atributul A determină funcţional atributul B sau B depinde funcţional de A, dacă şi numai dacă oricărei valori a atributului A îi corespunde o singură valoare a atributului B (se notează A->B). Dependenţa funcţională A->B este totală dacă nu există nici un subset C al atributului A (CcA) astfel încât C->B şi este parţială în caz contrar. În relaţia Prestari_Servicii, una din dependenţele funcţionale care poate fi pusă în evidenţă este Nume_client->Adresa. Deoarece într-o relaţie orice cheie identifică în mod unic fiecare tuplă a relaţiei, deci determină în mod univoc valorile atributelor tuplei, rezultă că în orice relaţie atributele sunt dependente funcţional faţă de cheile acesteia. Se pot face, până în acest moment, următoarele precizări:

Eliminarea dependenţelor funcţionale din schemele de relaţie şi a consecinţelor negative (redundanţa datelor; anomaliile de adăugare, ştergere, actualizare) se realizează prin descompunerea schemei date într-o colecţie de scheme mai simple în care sunt evitate neajunsurile mai sus menţionate. Reconstituirea relaţiei iniţiale se poate face prin operaţia de cuplare (uniune). Pentru ca descompunerea schemei de relaţie să fie echivalentă cu relaţia iniţială, trebuie să fie îndeplinite condiţiile:

- cuplare fără pierdere de informaţie;

- conservarea dependenţelor (dependenţele funcţionale din relaţia iniţială trebuie să se regăsească în relaţiile rezultate prin descompunere). Formele normale sunt scheme de relaţie echivalente obţinute prin descompunerea unor scheme de relaţie în vederea eliminării redundanţei datelor şi anomaliilor la adăugare, actualizare, ştergere înregistrări în baza de date. Descompunerile schemelor de relaţii în scheme de relaţii echivalente având în vedere dependenţele funcţionale conduc la definirea primelor 4 nivele de forme normale şi anume: prima formă normală (FN1), a doua formă normală (FN2), a treia formă normală (FN3) şi forma normală Boyce-Codd (FNBC). A patra formă normală (FN4) este definită având în vedere dependenţele multivalorice, iar a cincea formă normală (FN5) este definită având în vedere dependenţele de cuplare. Începând de la prima formă normală şi până la forma normală FN5 se impun condiţii din ce în ce mai restrictive asupra relaţiilor. Astfel o relaţie aflată pe un anumit nivel de normalizare (FN5) satisface toate restricţiile cerute de nivele inferioare de normalizare (FN1, FN2, FN3, FNBC, FN4). În cele ce urmează sunt date definiţiile formelor normale având în vedere dependenţele funcţionale.

40

O relaţie R este în prima formă normală (FN1) dacă şi numai dacă toate atributele

sale iau numai valori atomice (nu pot fi descompuse). Spre exemplu, atributul Adresa ar putea fi considerat un atribut neatomic dacă în cadrul adresei ne-ar interesa localitatea, strada etc., caz în care trebuie descompus în atribute atomice.

O relaţie R este în a doua formă normală (FN2) dacă este în FN1 şi orice atribut

neprim este total dependent faţă de orice cheie a relaţiei (atributele prime sunt atribute

care fac parte dintr-o cheie a relaţiei şi cele neprime sunt atributele care nu aparţin nici unei chei a relaţiei).

O relaţie R este în a treia formă normală (FN3) dacă este în FN2 şi nici un

atribut neprim nu este funcţional dependent faţă de un alt atribut neprim al relaţiei. O relaţie R se află în forma normală Boyce-Codd (FNBC) dacă singurele dependenţe funcţionale admise sunt cele în care o cheie determină un alt atribut (nici un atribut prim sau neprim nu poate fi dependent funcţional faţă de un alt atribut dacă acesta nu este sau nu conţine o cheie).

2.2.2. Dependenţe multivalorice Pentru ilustrarea acestui tip de dependenţe se ia în considerare următoarea schemă de relaţie:

Clase(Clasa, Discipline, Elevi) ce conţine clasele dintr-o instituţie de învăţământ, iar pentru fiecare clasă sunt

înregistrate disciplinele ce se predau şi elevii înmatriculaţi în clasa respectivă. Se poate constata că relaţia Clase poate rezulta prin operaţia de cuplare după atributul Clasa a următoarelor două relaţii:

CD(Clasa, Discipline) CE(Clasa, Elevi)

În relaţia Clase, presupunând că pentru o clasă dată, fiecare elev frecventează toate

disciplinele înregistrate pentru acea clasă, există dependenţele multivalorice:

Clasa ->> Discipline Clasa ->> Elevi. Ca şi în cazul dependenţelor funcţionale, existenţa dependenţelor multivalorice prezintă aceleaşi neajunsuri privind redundanţa datelor şi anomalii la efectuarea operaţiilor de adăugare, actualizare şi ştergere înregistrări în baza de date. O relaţie R este în a patra formă normală dacă singurele dependenţe multivalorice admise sunt cele determinate de un alt atribut care este o cheie sau care conţine o cheie a relaţiei.

Întrucât orice dependenţă funcţională este un caz particular de dependenţă multivalorică, rezultă că orice relaţie care se află în forma normală FN4, se află şi în forma normală FNBC. Transformarea unei relaţii într-o colecţie de relaţii care să se afle în FN4 este similară cu trecerea în FNBC, însă trebuie avută în vedere atât eliminarea dependenţelor funcţionale cât şi a dependenţelor multivalorice.

În

concluzie, putem afirma că în cazul formelor normale de la FN1 la FN4,

trecerea de la o formă normală la alta s-a făcut prin descompunerea unei relaţii în altele două, urmărindu-se eliminarea dependenţelor funcţionale şi multivalorice. O relaţie aflată în forma normală FN4 nu mai poate fi descompusă în continuare pe baza acestei metode. Există situaţii când relaţii aflate în FN4 conţin redundanţe şi prezintă anomalii la operaţiile de adăugare, ştergere şi actualizare. Aceste anomalii sunt cauzate de existenţa dependenţelor de cuplare şi pot fi eliminate prin descompunerea relaţiei în 3 sau mai multe relaţii a căror cuplare are ca rezultat relaţia iniţială.

41

2.2.3. Dependenţe de cuplare

Se consideră schema de relaţie:

SDS (Specializari, Discipline, Studenti) care conţine disciplinele care se predau la diverse specializări şi studenţii care le frecventează, cu precizarea că pot exista discipline opţionale care nu sunt frecventate de toţi studenţii de la specializarea respectivă. În aceste condiţii în cadrul schemei de relaţie SDS nu au loc dependenţele multivalorice:

Specializari ->> Discipline Specializari->> Studenti ceea ce înseamnă că relaţia SDS este în FN4. Deşi este în FN4, relaţia SDS conţine mai multe redundanţe care pot conduce la anomalii de actualizare. Pe de altă parte, relaţia SDS nu poate fi descompusă în două componente din a căror cuplare să rezulte relaţia iniţială cu conservarea informaţiei. Se constată însă că relaţia SDS poate fi descompusă în următoarele 3 relaţii:

SD(Specializari, Discipline) SS(Specializari, Studenti) DS(Discipline, Studenti) şi relaţia SDS este rezultatul cuplării relaţiilor: SD, SS şi DS fără pierdere de informaţie. SDS = SD►◄SS►◄DS. În acest caz spunem că în relaţia SDS există o dependenţă de cuplare. Dependenţele multivalorice sunt cazuri particulare de dependenţe de cuplare. A cincea formă normală este o generalizare a formei normale patru, trecerea unei relaţii în FN5 presupunând eliminarea dependenţelor de cuplare existente în cadrul relaţiei, împreună cu anomaliile pe care acestea le creează. În cadrul unei relaţii pot exista dependenţe de cuplare care nu conduc la redundanţă în memorarea datelor şi nu produc anomalii la operaţiile efectuate asupra înregistrărilor bazei de date (acestea sunt dependenţele de cuplare implicate de o cheie a relaţiei).

O relaţie este în forma normală cinci (FN5) dacă şi numai dacă toate

dependenţele de cuplare existente în relaţie sunt implicate de o cheie a acesteia. Relaţia SDS se poate descompune, cu conservarea conţinutului de informaţie, în cele 3 componente ale sale: SD, SS şi DS care sunt în FN5. Având în vedere similaritatea ce există între definiţiile pentru FNBC, FN4 şi FN5, acestea pot fi unificate în următoarea definiţie [DORO98]:

O relaţie R este în FNBC, FN4, FN5 dacă şi numai dacă singurele

dependenţe funcţionale, multivalorice, de cuplare existente sunt cele implicate de o

cheie a relaţiei R.

În

concluzie, prin procesul de normalizare se realizează eliminarea din

schemele de relaţie a dependenţelor (funcţionale, multivalorice şi de cuplare) cu

scopul de a obţine o schemă relaţională mai bună din punctul de vedere al redundanţei datelor şi al anomaliilor ce pot apare la operaţiile de adăugare, ştergere şi actualizare înregistrări în baza de date. Normalizarea unei scheme de relaţie R

înseamnă înlocuirea acesteia cu o mulţime de proiecţii R1,

echivalentă cu uniunea proiecţiilor R1,

proiectarea bazelor de date, aceasta nu oferă întotdeauna reţete pentru obţinerea celor mai bune modele şi de aceea este la latitudinea proiectantului decizia de a aplica sau nu o anumită etapă de normalizare după o analiză temeinică a avantajelor şi dezavantajelor modelului obţinut. În unele cazuri normalizarea completă, până la FN5, s-ar putea să fie dezavantajoasă. Având în vedere constatările de mai sus se poate afirma că deşi normalizarea nu reprezintă o soluţie general valabilă în orice situaţie, totuşi dacă pentru proiectarea bazei de date se aplică corect o

astfel încât R să fie

Deşi normalizarea este o operaţie utilă în

,Rn

,Rn.

42

metodologie de proiectare descendentă, modelul rezultat va fi de la sine normalizat. Cercetările în acest domeniu continuă, fiind definite şi alte forme normale printre care FN6 pentru baze de date temporale. O bază de date temporală, pe lângă datele curente, conţine şi date istorice, iar factorul (atributul) timp are un rol esenţial (exemple concludente de astfel de baze de date sunt depozitele de date). Astfel, în proiectarea unei baze de date temporale trebuie avute în vedere şi alte operaţii de descompunere a schemelor de relaţie şi anume:

- descompunerea orizontală – pentru separarea datelor curente de

datele istorice;

- descompunerea verticală – pentru separarea atributelor aceleiaşi

entităţi având în vedere valorile lor raportate la atributul temporal. În proiectarea unei baze de date nu este exclusă nici operaţia inversă normalizării numită denormalizare [DATE04], prin care se urmăreşte înlocuirea unei colecţii de scheme de relaţie cu o schemă de relaţie echivalentă în vederea eliminării necesităţii efectuării unor operaţii de cuplare care pot fi costisitoare. Dacă în cazul normalizării tendinţa este de a ajunge la nivele cât mai înalte (FN5), pentru denormalizare nu există criterii clare putând fi avute în vedere doar aspecte legate de performanţele anumitor aplicaţii. Un alt principiu care se urmăreşte în proiectarea unei baze de date este principiul proiectării ortogonale conform căruia în cadrul unei baze de date două scheme de relaţie reale (variabile de relaţie de bază) nu trebuie să aibă semnificaţii suprapuse. În timp ce prin normalizare se urmăreşte reducerea redundanţei din cadrul unei scheme de relaţie, prin proiectarea ortogonală se urmăreşte reducerea redundanţei dintre schemele de relaţie.

2.3. Integrarea bazelor de date în mediul Web Evoluţia tehnologiei informaţiei şi comunicaţiilor face ca bazele de date să nu mai fie izolate pe sisteme desktop, ci să poată fi disponibile oricui are acces fie la o reţea locală (Intranet) sau globală (Internet). Pentru aceasta cea mai potrivită interfaţă este Web-ul, care este independent de hardware sau de sistemul de operare folosit şi astfel baza de date este accesibilă cu ajutorul unui browser Web. În prezent reţeaua Web a devenit cel mai popular şi puternic sistem informaţional în reţea. În reţeaua Web, informaţiile sunt stocate în documente utilizând limbajul HTML (HyperText Markup Language), putând fi afişate de către un browser Web care schimbă informaţii cu un server Web utilizând protocolul HTTP (HyperText Transfer Protocol). Având în vedere faptul că la ora actuală multe situri Web sunt bazate pe fişiere, fiecare document fiind stocat într-un fişier separat, pot apare dificultăţi privind administrarea unui număr foarte mare de astfel de fişiere create şi întreţinute de autori diferiţi. De asemenea multe situri Web conţin informaţii care se modifică în timp şi prin urmare întreţinerea acestora atât în baza de date cât şi în pagini HTML separate poate constitui o sarcină dificil de realizat. De aceea se pune astăzi cu acuitate problema stocării informaţiilor Web în baze de date şi realizarea de pagini Web dinamice, deci se pune problema integrării Web-SGBD. În mediul Web, modelul client-server pe două etaje (1-clientul, 2-serverul de baze de date) a fost înlocuit cu un model pe trei etaje astfel:

- etajul 1 - interfaţa cu utilizatorul, care poate fi realizată de un browser Web;

- etajul 2 - logica afacerii şi prelucrarea datelor, care poate fi realizată pentru

a deservi mai mulţi clienţi prin intermediul unui server de aplicaţie care poate fi

spre exemplu un server Web;

- etajul 3 - serverul de baze de date (sistem SGBD distribuit pe calculatoare

43

diferite). Pentru crearea de pagini Web dinamice se poate utiliza fie tehnologia ASP (Active Server Page), fie tehnologia JSP (Java Server Page). Principala diferenţă între cele două metode de dezvoltare de pagini Web este faptul că ASP, în general, interacţionează cu medii construite cu tehnologii Microsoft, pe când JSP este funcţională în medii dezvoltate în Java. Tehnologia ASP facilitează crearea de pagini Web dinamice, însă funcţionează doar cu servere Web ale Microsoft (Internet Information Server sau Personal Web Server). Date statistice recente relevă că circa 22% din server-ele Web sunt bazate pe Windows NT. Internet Information Server, împreună cu driverul ODBC, face legătura între baza de date propriu-zisă şi cererea formulată de un browser. Driverul de tip ODBC asigură independenţa de tipul de server SQL. Tehnologia ASP permite folosirea mai multor limbaje scriptice (VBScript, Jscript, JavaScript etc.) şi conexiunea la multiple tipuri de baze de date prin drivere specifice sau prin intermediul ODBC. O bază de date (existentă chiar pe un alt calculator) poate fi interogată conform schemei din figura 2.2.

poate fi interogată conform schemei din figura 2.2. Baza de date Microsoft Internet Information Server [IIS]

Baza de date

Microsoft Internet Information Server [IIS]

Active Server Pages [ASP]

INTERNE T/ INTRANE T
INTERNE
T/
INTRANE
T
[IIS] Active Server Pages [ASP] INTERNE T/ INTRANE T We owse r Web Bro wser Web

Weowse

r

WebBro

wser

[ASP] INTERNE T/ INTRANE T We owse r Web Bro wser Web Fig. 2.2. Accesarea unei

Web Fig. 2.2. Accesarea unei baze de date prin reţeaua INTERNET

Limbajul de interogare a bazei de date este SQL. Indiferent de tipul bazei de date, formatul conţinut în script-urile aferente interogării este acelaşi, iar prin numele sursei de date se specifică baza de date utilizată care poate fi ORACLE, MySQL, SQL Server M.S., Microsoft Access, etc. Accesul la bazele de date este facilitat de folosirea tehnologiei ActiveX Data Objects (ADO), care face ca accesul prin Internet la o bază de date să nu fie mai lent decât citirea unei pagini de Web obişnuite. ADO este prima tehnologie Microsoft dezvoltată pe baza API-ului OLE DB (Object Linking and Embedding aplicat bazelor de date) şi permite scrierea de aplicaţii client care să acceseze şi să manipuleze datele unei baze de date aflate pe server, prin intermediul driver-elor ODBC care reprezintă un set de standarde, bazate pe SQL, destinat bazelor de date relaţionale, care leagă dialecte SQL distincte ale diverselor SGBD-uri. Tehnologia JSP este o tehnologie multiplatformă care îmbină performanţele tehnologiei Java la nivelul serverului, cu limbajul HTML/XML pentru crearea paginilor Web, paginile JSP putând fi create şi întreţinute cu ajutorul uneltelor pentru generat pagini HTML/XML uzuale. O pagină JSP este formată din:

- componente HTML/XML statice;

- taguri JSP;

- opţional, porţiuni de cod Java, numite „scripturi“. Pentru accesarea bazei de date JSP foloseşte JDBC în timp ce ASP foloseşte ADO. JSP poate folosi taguri definite de programator în timp ce ASP nu este extensibil.

44

Având în vedere faptul că limbajul de programare standard pentru Web este limbajul Java, în vederea integrării Web-SGBD au fost realizate limbajele JDBC, JSQL, JRB, ca mecanisme de conectare a limbajului Java la un sistem SGBD compatibil ODBC [JRB96], [JSQL97]. Dintre acestea (conform aprecierii date de Hamilton şi Cattell 1996) JDBC reprezintă cea mai puternică tratare în accesarea sistemelor SGBD relaţionale din limbajul Java., care se bazează pe SQL dinamic, ceea ce permite ca un program apelant să compună instrucţiuni SQL în momentul execuţiei. Limbajul JSQL propus de consorţiul Oracle, IBM şi Tandem în 1997, constă în extinderea limbajului Java cu limbajul SQL static înglobat. Alegerea tipului de SGBD pentru realizarea unei aplicaţii cu baze de date este o decizie extrem de importantă şi trebuie să rezulte în urma analizei tuturor aspectelor care trebuie avute în vedere pentru rezolvarea problemei formulate. Dacă avem în vedere sistemele mari distribuite în reţea (Intranet sau Extranet) organizate ierarhic pe nivele (servere de baze de date, aplicaţii client) ce vor trebui să facă faţă unui număr mare de utilizatori simultan, numărul SGBD-urilor care pot răspunde unor astfel de cerinţe este considerabil redus. Analizând evoluţia din ultimii ani a produselor soft pentru crearea şi administrarea bazelor de date se constată, privitor la noile facilităţi oferite de cele mai recente versiuni, tendinţa includerii de caracteristici orientate-obiect. Astfel, cele mai reprezentative sisteme în domeniul bazelor de date şi anume: Oracle, Sybase, Informix, care până nu demult erau în exclusivitate sisteme relaţionale, au încorporată, în ultimele versiuni realizate, tehnologie orientată-obiect care variază de la implementarea doar a unor servicii până la reproiectarea pe baze noi în sisteme hibride obiect-relaţionale. Trei dintre principalii producători de sisteme relaţionale convenţionale şi anume: Oracle, Informix, IBM şi-au extins propriile SGBD-uri cu „servere universale“ obiect- relaţionale denumite astfel:

Data Cartridges producător Oracle

„Cartuşul/încărcătura“ Oracle – componenta cheie a arhitecturii Oracle NCA (Network Computer Architecture) – este un obiect branşabil care oferă o interfaţă prin care el poate fi gestionat. Structura sa este definită cu SQL3, iar interfaţa prin care poate fi accesat poate fi identificată de alte obiecte prin intermediul IDL (Interface Definition Language). Cartridge-urile sînt de trei tipuri: localizate pe serverul de baze de date (aşa numitele servicii extensibile), localizate în serverul de aplicaţii şi cartridge-uri client care rulează pe calculatorul client şi au acces la serviciile standard din interfaţa utilizator.

Data Blades producător Informix

Data Blade-urile sau „lamele“ de date Informix sînt asemănătoare cu pachete orientate-obiect, cu biblioteci de clase C++ şi încapsulează definiţiile claselor de obiecte. Ele permit, pe lângă adăugarea de noi tipuri avansate de date, specificarea de metode de acces optimizate şi a unor opţiuni de procesare pentru aceste tipuri de date.

Relational Extenders producător IBM (DB2).

Extensiile relaţionale în DB2 sînt definite în SQL3 şi pot include tipuri şi funcţii definite de utilizator, obiecte de dimensiuni mari (LOBs), triggere, proceduri stocate şi variate constrângeri şi verificări asociate tipurilor de date. Compania Oracle are în vedere, în versiunile serverului de date Oracle, includerea maşinii virtuale Java în nucleu permiţând executarea applet-urilor Java direct în baza de date (nivelul client reprezentat de browser-ele Web include deja o maşină virtuală Java). Pînă la realizarea acestui deziderat, Oracle oferă programatorilor Java două drivere JDBC (Java DataBase Connectivity), care permit

45

accesul la bazele de date Oracle direct din aplicaţiile Java. Cele două drivere JDBC sunt:

1. JDBC/OCI (JDBC/Oracle Call Interface) - driver destinat dezvoltatorilor de

aplicaţii Java client/server sau de aplicaţii pentru serverul de aplicaţii (cartridge-uri)

în Java. Acest driver converteşte apelurile JDBC în apeluri OCI care sunt

transmise prin Net8 sau SQL*Net (protocoale de reţea Oracle) către serverul de date Oracle;

2. Thin JDBC - driver destinat dezvoltatorilor de applet-uri sau aplicaţii Java

(care rezidă pe un server în reţea şi trebuie descărcate la execuţie de client). Acest driver este scris complet în Java şi respectă în totalitate standardul JDBC. Fiind foarte mic, acest driver poate fi descărcat pe client o dată cu applet-ul Java la momentul execuţiei. La integrarea Web-SGBD apar următoarele două neajunsuri:

- funcţionalitatea limitată a limbajului HTML;

- securitatea scăzută. Utilizarea limbajelor de scriptare cum ar fi JavaScript şi VBScript, permite crearea de funcţii înglobate în limbajul HTML pentru a extinde atât browserul cât şi serverul. Într-un mediu Web securitatea este asigurată prin servere reprezentant (proxy), servere Kerberos (servere de nume de utilizatori şi parole securizate), parafocuri (previn accesul neautorizat la şi de la o reţea privată), semnături digitale (şiruri de biţi determinate din datele “semnate” şi cheia privată a persoanei sau organizaţiei), certificate digitale (date de identificare criptate ale unei persoane sau organizaţii), straturi şi protocoale de securizare. În concluzie, se poate afirma că integrarea Web - SGBD se impune din următoarele considerente:

- dificultăţi de administrare - număr mare de documente stocate în fişiere

separate create şi

- dificultăţi de întreţinere date-informaţii de natură dinamică (produse, preţuri,

etc.)

- interconectivitate globală - Internet, Intranet/Extranet + baze de date.

întreţinute de autori diferiţi;

întreţinute atât în baze de date cât şi în pagini HTML;

2.4. Baze de date deductive Una din direcţiile de cercetare desfăşurate în vederea rezolvării unor probleme complexe de baze de date este [DORO98] abordarea logică prin care se urmăreşte dezvoltarea de Sisteme de Gestiune a Bazelor de Cunoştinţe (SGBC) care să răspundă pe de o parte cerinţelor oferite de un SGBD obişnuit (acces eficient la volume mari de date, gestiunea tranzacţiilor, etc.) şi pe de altă parte să posede un limbaj declarativ cu putere de expresie apropiată de cea a limbajelor convenţionale. Cercetările desfăşurate în această direcţie au în vedere adaptarea limbajelor logice de tip PROLOG la cerinţele impuse de manipularea unor volume mari de date întâlnite în cadrul SGBD-urilor. În acest sens sunt avute în vedere limbajele din familia DATALOG, care sunt considerate a fi intermediare între limbajele relaţionale şi limbajul PROLOG. Rezultatele obţinute în cadrul cercetărilor în această direcţie au condus la definirea unei noi discipline denumită Baze de date deductive [ULLM90], [ZANI90], [MALE02], [PARC02], [SPAS02], [ADIT03], sau Baze de date bazate pe logică [DATE04]. Bazele de date deductive sunt [ADIT03] sisteme de programe logice destinate pentru aplicaţii cu volume mari de date şi constituie o extensie a bazelor de date relaţionale prin exploatarea puterii de expresie a regulilor logice , suportului pentru

46

recursivitate şi structurilor de date non-atomice, simplificând programarea aplicaţiilor care tradiţional erau realizate în SQL inclus într-un limbaj gazdă cum ar fi limbajul C. Datele sau faptele sunt reprezentate prin expresii atomice care nu conţin nici o variabilă (ground atoms). Un predicat este memorat extensional prin memorarea într-o relaţie a bazei de date a tuturor tuplelor adevărate pentru acest predicat. Partea extensională reprezintă componenta relaţională a bazei de date. Un predicat este memorat intensional prin memorarea secvenţei de reguli care îl definesc. Regulile sunt scrise în notaţie PROLOG astfel:

p: - q1,q2,…,qn Partea intensională reprezintă componenta deductivă a bazei de date. Formal o bază de date deductivă se compune [MALE02] din două părţi:

- o bază de date extensională EDB (extensional database) - este o mulţime de fapte de bază care descriu o parte a lumii reale avută în vedere; - o bază de date intensională IDB (intensional database) – este o mulţime de reguli, scrise într-un limbaj logic reprezentând propoziţii care permit deducerea de noi fapte din vechile fapte.

2.4.1. Extensii ale modelului relaţional Având în vedere bazele de date relaţionale, fiecare fapt r(c 1 ,c 2 ,…,c k ) din baza de fapte EDB poate fi pus în corespondenţă cu o tuplă <c 1 ,c 2 ,…,c k > a unei relaţii R. Pe de altă parte, o regulă care defineşte un predicat r poate fi gândită ca o definiţie implicită a unei relaţii R şi corespunde conceptului relaţional de vedere. O interogare a bazei de date este expresia unei formule logice particulare de demonstrat, răspunsul calculat pentru această demonstrare constituind rezultatul interogării. În acest sens, tuplurile relaţiilor sunt interpretate ca axiome de bază, cererile sunt interpretate ca teoreme, iar răspunsurile la cereri reprezintă demonstraţii de teoreme. Având în vedere rezultatele obţinute în calculul propoziţiilor şi calculul predicatelor se definesc reguli de inferenţă (axiome deductive) care se aplică asupra faptelor din baza de date pentru deducerea de noi fapte. În acest mod de lucru, datele din baza de date, constrângerile de integritate, axiomele deductive şi cererile de interogare vor fi reprezentate în acelaşi fel. Pentru definirea bazelor de date deductive plecând de la modelul relaţional de baze de date s-au realizat următoarele extensii [MALE02]:

- extensia modelului de baze de date cu reguli active (triggere) caracterizate de o condiţie şi o acţiune de executat, ceea ce permite descrierea de procesări reactive care se verifică automat la efectuarea operaţiilor de manipulare a datelor, bazele de date astfel realizate fiind numite baze de date active.

- extensia modelului de baze de date cu reguli deductive (de tip PROLOG) caracterizate de o condiţie şi de o consecinţă logică, ceea ce permite exprimarea în mod declarativ a deducerii de noi relaţii şi date plecând de la relaţii introduse explicit, bazele de date astfel definite fiind numite baze de date deductive. Importanţa regulilor active şi a regulilor deductive constă în posibilitatea exprimării multor operaţii care altfel erau codificate în aplicaţii. Aceste extensii, pe lângă independenţa fizică şi logică (independenţă realizată de sistemele tradiţionale de baze de date), pot fi considerate ca un ulterior nivel de independenţă de aplicaţii denumit independenţa de cunoştinţe (knowledge independence). Avantajul independenţei de cunoştinţe este faptul că regulile sunt automat utilizate pentru toate

47

aplicaţiile ceea ce conduce la simplificarea scrierii codului aplicaţiilor. Regulile sunt definite de administratorul bazei de date şi fac parte din schema bazei de date. Limbaje declarative cum ar fi SQL2 permit exprimarea în mod declarativ a derivării de noi relaţii prin intermediul vederilor logice, însă nu permit exprimarea interogărilor complexe ce presupun recursivitatea. În acest sens, noul standard SQL3 introduce o serie de extensii ale algebrei relaţionale şi anume:

- închiderea tranzitivă a unei relaţii – se obţine prin adăugarea de tuple,

deductibile prin tranzitivitate, la relaţia de plecare (exemplu: dacă se consideră tuplele t1=(a,b) şi t2=(b,c), prin tranzitivitate din cele două tuple se obţine tupla

t3=(a,c)).

- recursivitatea - se realizează cu comanda WITH astfel:

Fie o relaţie R(A1,A2). O interogare recursivă pe relaţia R are forma

WITH RECURSIVE RR(A1,A2) AS (SELECT A1, A2 FROM R) UNION (SELECT R1.A1, R2.A2 FROM RR AS R1, R AS R2WHERE R1.A2 = R2.A1) SELECT * FROM RR.

2.4.2. Limbajul DATALOG DATALOG este limbajul logic utilizat în cadrul bazelor de date deductive, atât

pentru definirea componentei extensionale EDB, cât şi pentru definirea componentei intensionale IDB. În formalismul DATALOG datele şi regulile sunt reprezentate prin clauze Horn care au forma generală

L 0 :- L 1 ,…,L n

(2.1)

L 0 se numeşte capul clauzei, iar - L1,…,Ln se numeşte corpul clauzei. Fiecare dintre L i este numit literal şi are forma p i (t 1 ,…,t k ), p i fiind un simbol numit predicat iar t i se numesc termeni, fiecare t i putând fi o constantă sau o variabilă. Regulile fără variabile sunt numite de bază (ground). Corpul unei clauze poate fi vid şi în acest caz clauza este un fapt. Faptele de bază sunt memorate în EDB. Regulile sunt clauze cu corpul nevid şi sunt memorate în IDB. Un program DATALOG P trebuie să satisfacă următoarele condiţii de securitate (safety conditions):

- orice fapt din P este de bază

- fiecare variabilă care apare în capul unei reguli trebuie de asemenea să apară în corpul aceleiaşi reguli Aceste condiţii garantează că mulţimea tuturor faptelor care pot fi derivate de un program DATALOG este finită. Semantica logică a limbajului DATALOG poate fi interpretată [MALE02] astfel:

- fiecare fapt DATALOG F poate fi identificat cu o formulă atomică F* din logica de ordinul 1;

- fiecare regulă DATALOG R de forma reprezintă o formulă de forma

2.1

X 1 ,…, X n (L 1 L n

L 0 )

(2.2)

unde X 1 ,…,X n sunt toate variabilele care apar în regulă;

- o mulţime S de clauze DATALOG corespunde mulţimii S* a tuturor formulelor C* astfel încât C aparţine lui S;

- baza lui Herbrand HB este mulţimea tuturor faptelor care se pot exprima în limbajul DATALOG, adică mulţimea tuturor literalelor de forma p(c 1 ,…,c n ) cu c i constante;

- EBH este partea extensională a lui HB (mulţimea predicatelor extensionale);

- IBH este partea intensională a lui HB (mulţimea predicatelor intensionale);

48

- S fiind mulţimea clauzelor DATALOG, cons(S) este mulţimea tuturor faptelor care sunt consecinţe logice ale lui S;

- Semantica unui program DATALOG P poate fi descrisă ca o aplicaţie

 

P : EBH

IBH

(2.3)

care asociază fiecărei baze de date extensionale E EBH mulţimea

 

P (E) = cons(P

E)

IBH

(2.4)

2.4.3. DATALOG şi algebra relaţională Având în vedere faptul că limbajul DATALOG poate fi privit ca o extensie recursivă a unui limbaj relaţional, este util de a pune în relaţie limbajul DATALOG cu algebra relaţională astfel încât să se poată utiliza în baze de date deductive concepte dezvoltate pentru baze de date relaţionale. Fiecare clauză a unui program DATALOG poate fi transformată într-o relaţie de incluziune a algebrei relaţionale. Mulţimea relaţiilor de incluziune care provin din reguli care definesc acelaşi predicat va forma deci o ecuaţie a algebrei relaţionale. Astfel, unui program DATALOG îi va corespunde un sistem de ecuaţii ale algebrei relaţionale. Fiecărui predicat EDB al programului DATALOG îi corespunde o relaţie constantă. Fiecărui predicat IDB al programului DATALOG îi corespunde o relaţie variabilă. Determinarea soluţiei sistemului corespunde determinării valorii relaţiilor variabile care satisface sistemul. În cele ce urmează este prezentat explicit cazul predicatelor IDB. Se consideră clauza:

C: p(a 1 ,…,a n ) :- q 1 (b 1 ,…,b k ),…,q m (b 1 ,…b h ) (2.5) Clauzei C îi corespunde în algebra relaţională o relaţie de incluziune de forma:

(2.6)

între relaţiile P,Q 1 ,…,Q m care corespund predicatelor p,q 1 ,…,q m cu convenţia că atributele fiecărei relaţii R sunt indicate cu numărul argumentului corespunzător al

predicatului r. Pentru fiecare predicat p, se consideră toate relaţiile de incluziune de tipul Expr(Q 1 ,…,Q m ) P şi se generează o ecuaţie algebrică de forma P= Expr 1 (Q 1 ,…,Q m ) Expr 2 (Q 1 ,…,Q m ) Expr mp (Q 1 ,…,Q m )

(2.7)

Expr(Q 1 ,…,Q m ) P

(2.8)

Transformarea unei mulţimi de subecuaţii într-o singură ecuaţie semnifică condiţia de

minimalitate a modelului Herbrand, care exprimă faptul că suntem interesaţi numai de acele fapte de bază care pot fi deduse de program. Este posibilă traducerea unui scop (goal) în interogări algebrice utilizând

selecţii şi proiecţii asupra unora din variabilele sistemului pentru afişarea rezultatului evaluării expresiei din partea dreaptă după înlocuirea valorilor curente ale variabilelor, astfel:

?- p(X)

este echivalentă cu interogarea algebrică

“P”;

?- q(a,X)

este echivalentă cu interogarea algebrică

1=a (Q)”.

Exemplu de traducere din limbaj DATALOG în ecuaţii ale algebrei relaţionale.

Program DATALOG

Ecuaţii algebrice traduse în algebra relaţională

----------------------------------------------------------------------------------------------------------------------------------------------------------------------

p

1 (X,Y) :- c 1 (X,Y)

p

1 (X,Y) :- p 1 (X,Z), p 3 (Z,Y)

p

1 (X,Z) :- p 2 (X,Y)

p

2 (X,Y) :- p 1 (X,Z), p 3 (Z,Y)

R 1 =C 1

1,4 (R 1  2=1 R 3 )

R 2 =

49

1,4 (R 1  2=1 R 3 )

C 3

R 2

p

2 (X,Y) :- c 3 (X,Y)

p

3 (X,Y) :- p 3 (X,Z), c 2 (Z,Y)

R 3 =

p

3 (X,Y) :- c 4 (X,Y)

1,4 (R 3  2=1 C 2 )

C 4

?- p 1 (a,X)

----------------------------------------------------------------------------------------------------------

1=a (R 1 )

2.4.4. SGBD deductive Sistemele deductive referite [PARC02], [SPAS02] sub denumirea de SGBD deductive, sau Sisteme de gestiune a bazelor de cunoştinţe KBMS, reprezintă o formă avansată a sistemelor DBMS relaţionale, inspirată din limbajul PROLOG şi în care limbajul de cereri şi structura de memorare sunt proiectate pe baza unui model logic al datelor. În cadrul unui SGBD deductiv pot fi puse în evidenţă următoarele componente:

- partea extensională a bazei de date EDB (componenta relaţională);

- partea intensională a bazei de date IDB (componenta deductivă);

- limbajul de programare logică (DATALOG) ce va fi utilizat pentru reprezentare

EDB şi IDB. Spre deosebire de sistemele tradiţionale de baze de date, sistemele deductive asigură independenţa de cunoştinţe, deoarece schema bazei de date, pe lângă datele propriuzise, va conţine şi regulile ce se vor aplica asupra datelor, reguli ce vor fi automat utilizate pentru toate aplicaţiile, ceea ce simplifică activitatea de scriere a codului pentru aplicaţii. Un sistem deductiv de baze de date este [BÂSC97] “un SGBD care permite construirea vederilor cu demonstrare teoretică”, fiind capabil să deducă noi fapte aplicând reguli de inferenţă faptelor existente în baza de date. Utilizarea limbajului DATALOG ca limbaj de programare logică şi privit ca o extensie recursivă a unui limbaj relaţional, permite uniformizarea reprezentării tuturor componentelor bazei de date şi utilizarea, în baze de date deductive, a unor concepte dezvoltate pentru baze de date relaţionale.

2.5. Modelul TransRelaţional O descoperire de importanţă majoră, poate cea mai semnificativă descoperire

în domeniu după inventarea cu peste 35 de ani în urmă a modelului relaţional de

către E. F. Codd care a constituit o adevărată revoluţie în domeniul bazelor de date,

o reprezintă metoda de transformare Tarin inventată de Steve Tarin în cadrul

companiei Required Technologies Inc. () şi patentată SUA la sfârşitul anului 1999 ca tehnologie de implementare pentru diverse sisteme de stocare şi regăsire date printre care: sisteme SQL, sisteme pentru depozite de date, motoare de căutare pe Web, sisteme XML native, etc [DATE04]. Modelul TransRelaţional referit sub denumirea prescurtată modelul TR reprezintă aplicarea metodei de transformare Tarin în implementarea sistemelor relaţionale având în vedere realizarea independenţei fizice de date prin intermediul unei transformări care va defini corespondenţa dintre nivelul logic şi nivelul fizic al sistemului şi invers. Necesitatea utilizării modelului TR este justificată plecând de la constatarea că majoritatea sistemelor SGBD actuale (sisteme cu imagine directă) nu realizează cu adevărat o independenţă fizică de date, fiind realizată doar corespondenţa dintre variabilele de relaţie de bază şi fişierele stocate şi dintre tuplurile din aceste variabile şi înregistrările memorate în aceste fişiere, iar pentru accesarea datelor în diverse

50

secvenţe în condiţii de performanţă acceptabile sunt necesare indexuri şi alte structuri auxiliare ceea ce complică procesele de optimizare a accesărilor şi administrarea bazei de date. Aceste neajunsuri sunt eliminate prin implementarea sistemelor relaţionale utilizând modelul TR. În cadrul unui sistem relaţional implementat cu ajutorul modelului TR pot fi evidenţiate [DATE04] următoarele trei nivele de abstractizare:

- nivelul relaţional (Relaţii – baza de date văzută de utilizator = relaţii definite de atribute şi conţinând tupluri);

- nivelul fişierelor (Fişiere – definite de câmpuri ce corespund atributelor şi conţinând înregistrări ce corespund tuplurilor, dar fără nici o legătură cu fişierele stocate fizic);

- nivelul TR (Tabele – baza de date văzută de modelul TR = structuri TR interne numite tabele formate din rânduri şi coloane fără nici o corespondenţă directă cu relaţiile, tuplurile sau atributele de la nivelul relaţional.

In concluzie se poate afirma că ideea fundamentală care stă la baza modelului TR poate fi formulată astfel [DATE04]: forma stocată a unei înregistrări din cadrul unui fişier de la nivelul fişierelor presupune o mulţime de valori ale câmpurilor şi o mulţime de informaţii de legătură care corelează valorile câmpurilor, iar pentru stocarea fizică a fiecăreia din cele două mulţimi pot fi utilizate diverse modalităţi. Astfel, spre deosebire de sistemele cu imagine directă, în care cele două mulţimi de date sunt memorate împreună (informaţiile de legătură sunt reprezentate prin contiguitatea fizică), în modelul TR cele două mulţimi de date sunt stocate separat şi anume: valorile câmpurilor sunt memorate în tabela valorilor câmpurilor, iar informaţiile de legătură sunt memorate în tabela de reconstrucţie a înregistrărilor care conţine pointeri către datele propriuzise. Sintetizarea problemelor abordate privind evoluţia sistemelor SGBD este prezentată în tabelul T2.6.

51

T2.6. EVOLUŢIA SISTEMELOR DE GESTIUNE A BAZELOR DE DATE

Modele

     

de date

 

SGBD

 

Tipuri de aplicaţii

 

Dezavantaje

 

Ierarhic

Prima

 

Aplicaţii din domeniul afacerilor

 

Reţea

generaţie

- probleme de gestiune a

 

- putere de expresie limitată a

 

întreprinderilor (salarii, personal, producţie)

limbajelor de manipulare utilizate

   

- sisteme de rezervare a locurilor

- posibilităţi

 

de

modelare

Relaţional

A

doua

 

(transporturi, hoteluri , etc.)

limitate

 

generaţie

- sisteme de gestiune biblioteci

 
 

- sisteme financiar-bancare

 

Modele

Permite elaborarea unui model conceptual fără a ţine seama de anumite constrângeri impuse de modelul de date ierarhic, reţea, relaţional – rezultă o reprezentare mai fidelă a realităţii în cadrul unei etape intermediare în proiectarea unei baze de date

semantice

Modelul E/R

     

Aplicaţii avansate de baze de date

- lipsa unui fundament teoretic

Modelul de

date orientat

-

proiectarea asistată de calculator CAD

- lipsa de experienţă

 

- lipsa de standarde

spre obiecte

-

fabricarea

asistată

de

calculator

- produse complexe dificil de utilizat şi cu costuri ridicate

OODM

SGBDOO

CAM

-

ingineria programării asistată de calculator CASE

- suport limitat

pentru

 

securitate, integritate şi vederi

-

sisteme informaţionale de birou OIS şi sisteme multimedia

editarea digitală

 

A

treia

 

generaţie

-

- se pierde simplitatea şi puritatea modelului relaţional

Modelul

de date

-

sisteme informaţionale geografice GIS

aplicaţii ştiinţifice şi medicale (ex.

- nu

sunt

tratate

modele

de

-

obiecte, sunt extinse relaţiile

din

modelul

relaţional

cu obiecte

SGBDOR

date complexe pt. modele moleculare, material genetic etc.)

(obiectele

stocate

în

relaţional

doar

şi

persistă

tabele

ORDM

-

sisteme expert (baze de cunoştinţe pt. aplicaţii de inteligenţă artificială)

interogările se aplică numai tabelelor)

Modelul TR

- suport limitat pentru metode de acces multidimensional la date

   

O

formă avansată a sistemelor DBMS relaţionale, inspirată din limbajul

PROLOG şi în care limbajul de cereri şi structura de memorare sunt

SGBD

proiectate pe baza unui model logic al datelor.

 

deductive

Componente:

 

- partea extensională a bazei de date EDB (componenta

relaţională);

 

Model logic

al datelor

(Sisteme de

- partea intensională a bazei de date IDB (componenta deductivă);

Gestiune a

Bazelor de

- limbajul de programare logică (DATALOG) ce va fi utilizat pentru reprezentare EDB şi IDB.

 

Cunoştinţe

Schema bazei de date, pe lângă datele propriuzise, va conţine şi regulile ce

SGBC)

se

vor aplica asupra datelor, reguli ce vor fi automat utilizate pentru toate

aplicaţiile, ceea ce simplifică activitatea de scriere a codului pentru aplicaţii (asigură independenţa de cunoştinţe).

52

Întrebări

1. Enumeraţi principalele tipuri de aplicaţii din domeniul afacerilor.

1. Enumeraţi tipurile de aplicaţii avansate de baze de date.

2. Enumeraţi tipurile de modele de date şi SGBD-uri corespunzătoare definite pentru rezolvarea aplicaţiilor avansate de baze de date.

3. Prezentaţi sumar conceptele utilizate în tehnologia orientată spre obiecte în domeniul bazelor de date.

în

normale

4. Enumeraţi

tipurile

de

dependenţe

bazele

de

date

şi

formele

corespunzătoare.

5. Definiţi baza de date temporală şi tipurile de descompunere care se realizează în bazele de date temporale.

6. Prezentaţi modelul de baze de date client-server pe 3 etaje (nivele) în mediul Web.

7. Prezentaţi sumar conceptul de bază de date deductivă (bază de date bazată pe logică).

8. Definiţi SGBD deductive.

9. Prezentaţi sumar modelul transrelaţional.

53

Capitolul 3 Tehnici avansate de explorare a datelor (1)

Societatea modernă este caracterizată de schimbări rapide şi inovare permanentă în toate domeniile cunoaşterii. Datorită facilităţilor de comunicare dincolo de graniţe, spaţiu şi timp oferite de reţeaua Internet, economia noului mileniu poate fi privită [DANA02] ca o “scenă digitală” în care noile afaceri devin e-bussines (afaceri electronice), comerţul devine e-commerce (comerţ electronic), apar noi servicii electronice (e-services) şi se nasc noi comunităţi de tip virtual (e- communities). În noua scenă cu calculatoare interconectate în reţele Internet, Intranet şi Extranet suntem “inundaţi de informaţie, dar flămânzi după cunoştinţe”. Pentru realizarea activităţilor dintr-un domeniu într-o manieră inteligentă, în cadrul procesului decizional, decidentul este pus permanent în situaţia de a evalua şi alege între două sau mai multe alternative în cadrul unor activităţi inteligente. Materia primă de bază prelucrată în cadrul activităţilor inteligente este cunoaşterea, care reprezintă conceptul fundamental pentru dezvoltarea sistemelor inteligente. În vederea obţinerii informaţiilor necesare luării de decizii corecte omul din societatea modernă se confruntă cu necesitatea prelucrării unui volum imens de date reprezentând fapte culese din lumea reală pe bază de observaţii şi măsurători, care trebuiesc organizate şi stocate pe suporturi externe de memorare, apoi actualizate în permanenţă, regăsite şi prelucrate în timp util. O ierarhizare a datelor, informaţiei şi cunoaşterii având în vedere gradul de abstractizare este realizată de profesorul E. Turban astfel [ANDO01]:

Metacunoaştere -> Cunoaştere -> Informaţii -> Date, iar procesarea datelor şi cunoştinţelor în informatică, poate fi exprimată prin ecuaţiile:

Structuri de date + Algoritmi = Programe; Cunoaştere + Inferenţe = Sistem inteligent. Reprezentarea şi procesarea datelor şi cunoaşterii reprezintă obiectul apariţiei şi dezvoltării a două tehnologii de importanţă majoră în informatică şi anume:

- Tehnologia bazelor de date;

- Tehnologia sistemelor inteligente.

În timp ce tehnologia bazelor de date are în vedere memorarea, întreţinerea şi accesarea unor volume mari de date, tehnologia sistemelor inteligente este axată pe rezolvarea unor probleme complexe în diverse domenii care necesită expertiză umană, fiind însă restricţionată de domenii bine delimitate şi ineficientă pentru procesări numerice şi gestiunea unor volume mari de date. Cele două tehnologii la ora actuală distincte, tind să evolueze convergent în cadrul conceptului de sistem informaţional inteligent care presupune elaborarea unui model unificat date- cunoştinţe. În acest sens, sistemele de baze de date au în vedere exprimarea semanticii în schemele lor conceptuale şi capacitatea de inferenţiere (baze de date deductive), iar sistemele bazate pe cunoştinţe tind să rezolve probleme care reclamă baze de cunoştinţe (fapte şi reguli) din ce în ce mai mari. Având în vedere cele două resurse informaţionale (bazele de date şi bazele de cunoştinţe), pentru exploatarea maximă a acestora nu este suficientă doar cuplarea sistemelor de gestiune a bazelor de date cu sistemele expert prin intermediul unor interfeţe în cadrul aplicaţiilor, fiind necesară proiectarea fiecăreia din cele două componente ca o extensie naturală a celeilalte astfel încât împreună să conducă la realizarea unui sistem integrat. În acest sens cercetările pot fi îndreptate în următoarele direcţii:

54

- dotarea SGBD cu instrumente suplimentare de structurare şi manipulare

având în vedere semantica datelor (un pas important în această direcţie îl

constituie bazele de date deductive);

- dotarea sistemelor expert cu instrumente care să permită accesarea şi manipularea eficientă a informaţiei stocate în bazele de date.

3.1. Integrarea tehnologiei bazelor de date cu tehnologia sistemelor inteligente Tehnologia bazelor de date are în vedere procesarea tranzacţiilor, ceea ce presupune stocarea, întreţinerea şi accesarea unor volume mari de date reprezentând fapte organizate în structuri adecvate, prin intermediul unor produse software specializate (SGBD). Sistemele realizate pentru automatizarea proceselor din cadrul unei organizaţii prelucrează datele operaţionale aferente tratării operaţiilor de zi cu zi. Aceste sisteme orientate spre prelucrarea tranzacţiilor, cunoscute [COBS01] sub denumirea de sisteme OLTP (OnLine Transaction Processing) generează date operaţionale care sunt orientate spre obiect. În cursul anilor organizaţiile au acumulat astfel cantităţi mari de date stocate în cadrul sistemelor lor operaţionale. În ultimii ani, atenţia este concentrată asupra modalităţilor de utilizare a datelor operaţionale, stocate în baze de date şi arhive , pentru a susţine procesul decizional în vederea câştigării unor avantaje competitive. Se pune deci problema transformării arhivelor de date în sursă de cunoştinţe care să prezinte utilizatorului o vedere unitară asupra datelor organizaţiei. În acest sens s-a definit magazia sau depozitul de date cunoscute şi sub denumirea de data warehouse, care se alimentează cu date de la multiple surse de date operaţionale şi care oferă posibilitatea realizării unui sistem capabil să susţină procesul decizional al organizaţiei, folosind tehnici avansate de explorare a datelor. Scopul principal urmărit la proiectarea magaziei de date este susţinerea interogărilor prin realizarea unor analize economice complexe, care să folosească întreaga valoare pe care o posedă datele colectate, în vederea furnizării informaţiilor necesare pentru luarea de decizii strategice. Se disting două modalităţi prin care se poate valorifica informaţia din depozitul de date şi anume:

- analiza multidimensională OLAP (OnLine Analytical Processing);

- “mineritul” în date DM (Data Mining).

3.1.1. Înmagazinarea datelor Spre sfârşitul anilor 60 şi începutul anilor 70 cercetători de la Harvard şi MIT (Massachusetts Institute of Technology) au pus problema utilizării calculatoarelor în susţinerea procesului decizional al unei organizaţii. Acumulând în timp cantităţi mari de date, organizaţiile şi-au concentrat atenţia asupra valorificării datelor acumulate pentru susţinerea procesului decizional în vederea obţinerii de avantaje competitive. Astfel au fost definite conceptele: înmagazinarea datelor, magazie de date, depozit de date (Data Warehouse), piaţă de date. Conceptul iniţial de magazie de date a fost inventat la compania IBM sub denumirea de „magazie de informaţii”, primele încercări în acest domeniu fiind însă respinse datorită complexităţii şi problemelor apărute în implementarea unor astfel de soluţii. Părintele noii tehnologii privind înmagazinarea datelor este considerat Bill Inmon care în 1993 defineşte magazia de date ca fiind „O colecţie de date orientată spre subiect, integrată, variabilă în timp şi nevolatilă, care susţine procesul decizional al administrării” [COBS01]. Această definiţie are în vedere următoarele aspecte (caracteristici):

55

- datele sunt orientate spre subiect – în magazia de date sunt memorate principalele subiecte ale organizaţiei (clienţii, produsele, vânzările, etc.) adică datele de susţinere a deciziilor şi nu datele orientate spre aplicaţii (stocurile, facturile clienţilor, etc.);

- colecţia de date este integrată deoarece reuneşte date generale utilizate în aplicaţii, de la surse diferite astfel încât să prezinte utiilizatorilor o vedere unificată a datelor;

- datele sunt variabile în timp - datele din magazia de date reprezintă o colecţie de instantanee fiind valabile la un anumit moment sau interval de timp;

- colecţia de date este nevolatilă – datele colecţiei sunt reâmprospătate din sistemele operaţionale la anumite intervale de timp şi nu sunt reactualizate în timp real, iar datele noi sunt adăugate în permanenţă colecţiei. Scopul principal urmărit prin înmagazinarea datelor este integrarea datelor generale din întreaga organizaţie într-un depozit unic (data warwhouse) ce va putea fi utilizat pentru interogări, elaborare rapoarte şi analize pentru susţinerea procesului decizional al organizaţiei. Se transformă astfel datele din sistemele operaţionale OLTP (OnLine Transaction Processing) în sursă de informaţii pentru procesul decizional al organizaţiei. Sursele de date pentru constituirea unei magazii de date pot fi:

- datele operaţionale de pe calculatoare mainframe memorate în baze de date de primă generaţie de tip ierarhic şi reţea (ocupă o pondere însemnată în volumul total al datelor operaţionale generale ale unei organizaţii);

- datele departamentale stocate în sisteme speciale de fişiere şi în baze de date relaţionale printre care INFORMIX şi ORACLE;

- datele cu caracter personal memorate pe staţiile de lucru şi serverele

personale;

- sisteme externe organizaţiei printre care Internet, baze de date comerciale,

baze de date ale furnizorilor şi clienţilor organizaţiei. Plecând de la aceste surse de date în magazia de date se vor reprezenta:

- datele detaliate - sunt stocate la diverse intervale în magazia de date pentru a

suplimenta datele grupate;

- datele cu grad înalt şi scăzut de rezumare – reprezintă datele predefinite grupate generate de către administratorul magaziei de date pentru a creşte performanţele interogărilor, aceste date fiind actualizate continuu pe măsură ce se încarcă date noi în magazia de date;

- datele arhivate şi copii de siguranţă – stochează toate datele detaliate şi

rezumate în arhive de date şi copii de siguranţă pe suporturi adecvate de memorare (benzi magnetice, discuri optice);

- meta-datele – reprezintă definiţia datelor (datele despre date) din magazia de

date şi această reprezentare este specifică fiecărui proces care operează asupra magaziei de date. Tipuri de instrumente utilizate pentru construirea şi utilizarea unei magazii de

date:

- instrumente de extragere, curăţare şi incărcare date în magazia de date;

- instrumente de access ale utilizatorilor finali: instrumente de raportare şi

interogare, instrumente de dezvoltare a aplicaţiilor, instrumente pentru sistemul informaţional executiv EIS, instrumente de prelucrare analitică on-line OLAP, instrumente de explorare a datelor (descoperirea de noi corelaţii, tipare şi tendinţe folosind tehnici din statistică, matematică şi inteligenţă artificială). Operaţiile ce trebuie efectuate pentru realizarea magaziei de date sunt:

56

- preluare date de la sursele de date (sistemele OLTP);

- curăţare date preluate de la sursele de date (sursele de date pot conţine date incoerente, incomplete, dubluri, etc.);

- restructurarea datelor (eliminare sau adăugare de câmpuri, denormalizare);

- rezumarea datelor (sortare şi grupare date după diverse criterii);

- împachetarea datelor (transformare date detaliate sau rezumate în diverse

formate cum ar fi:foi de calcul tabelar, documente text, diagrame, alte reprezentări grafice);

- arhivarea datelor vechi, realizarea copiilor de siguranţă, refacerea datelor din

magazia de date;

- elaborarea de instrumente de interogare pentru asigurarea accesului utilizatorilor în vederea exploatării magaziei de date. Sisteme SGBD pentru magazii de date În general sistemele SGBD relaţionale complexe răspund cerinţelor impuse de crearea magaziilor de date, singura problemă care trebuie avută în vedere fiind cea privind volumul datelor pentru magazia de date. Principalele cerinţe pe care trebuie să le îndeplinească un sistem SGBDR pentru o magazie de date sunt:

- performanţe de încărcare (sute de milioane de rânduri de gigaocteţi de date pe oră);

- prelucrarea încărcării (filtrarea, reformatarea, verificarea integrităţii, stocarea fizică, indexarea, reactualizarea meta-datelor);

- administrarea calităţii datelor (coerenţa locală, coerenţa globală, integritatea referenţială, abilitate de a răspunde la interogările utilizatorilor);

- performanţele interogărilor raportat la factorul timp de răspuns (utilizarea sistemelor SGBD paralele care permite utilizarea eficientă a multor resurse cum ar fi: procesoarele, memoria, discurile, legăturile în reţea);

- gestionarea unui volum imens de date (dimensiunea unei magazii de date poate varia de la câteva sute de gigaocteţi la dimensiuni de ordinul teracteţilor 10 12 octeţi, sau pentaocteţilor 10 15 octeţi);

- accesul concurent al unui număr mare de utilizatori (deşi în prezent accesul la magazia de date este limitat la un număr relativ scăzut de utilizatori manageriali în viitor acest număr poate fi de ordinul miilor de utilizatori concurenţi);

- lucrul cu multiple magazii de date în reţea;

- administrarea magaziei de date în condiţii optime;

- analiză multidimensionaă (facilităţi pentru creare de vederi multidimensionale cu instrumente OLAP relaţionale incluse în sistemul SGBD);

- posibilitatea realizării interogărilor avansate (sistemul SGBDR trebuie să

dispună de posibilitatea efectuării unui set complet de operaţii analitice avansate mai mult decât poate oferi limbajul SQL). Implementarea unei astfel de soluţii pentru o organizaţie necesită timp (până la 3 ani) şi costuri care pot varia între 50.000 şi 10.000.000 lire, dar şi beneficiile pot fi considerabile. Astfel, conform unui studiu al IDC (International Data Corporation) realizat în anul 1996 investiţiile întoarse după 3 ani au ajuns în medie la 401%, 90% dintre companiile studiate ajungând la peste 40%, jumătate din ele la peste 160%, iar un sfert la peste 600% (sursa [COBS01]). Având în vedere faptul că realizarea unei magazii de date poate însemna un proiect de lungă durată (până la 3 ani), unele organizaţii au preferat să-şi construiască propriile pieţe de date care au în vedere numai cerinţele unui singur

57

departament sau domeniu funcţional şi prin urmare pot fi realizate într-un timp mai scurt şi cu mai puţine resurse. 3.1.2. Analiza multidimensională (OLAP OnLine Analytical Processing) Bazele teoretice ale tehnologiei OLAP au fost definite de cercetătorul E.F.Codd ("părintele" bazelor de date relaţionale) încă din anul 1993. OLAP reprezintă [COBS01] sinteza, analiza şi consolidarea dinamică a unor volume vaste de date multidimensionale. Printre operaţiile analitice obişnuite care pot fi efectuate asupra datelor multidimensionale sunt avute în vedere: consolidarea, parcurgerea în jos, tranşarea şi tăierea. Consolidarea înseamnă gruparea datelor fie după simple criterii, fie prin expresii complexe pentru date intercorelate. Parcurgerea în jos reprezintă inversul consolidării şi presupune afişarea datelor detaliate corespunzător datelor consolidate. Tranşarea şi tăierea (pivotarea, vizualizarea unei tranşe din date) reprezintă vizualizarea datelor după diverse puncte de vedere. Pentru analiza tendinţelor şi descoperirea tiparelor, adesea consolidarea şi tranşarea sunt efectuate după atributul timp (de-a lungul axei temporale). Codd a realizat manifestul OLAP care includea un set de 12 reguli care trebuiau avute în vedere, cu prioritate, în implementarea acestei noi tehnologii. Dintre aceste reguli cele mai importante priveau: numărul nelimitat de dimensiuni şi niveluri de sintetizare a datelor, transparenţa operaţiunilor de accesare a datelor, suportul consistent pentru realizarea rapoartelor, modul intuitiv de exploatare a datelor, suportul pentru realizarea interogărilor multidimensionale, arhitectura client/server şi suportul multi-user. Aplicarea în practică a acestor elemente teoretice s-a realizat în perioada 1998 - 1999. Un pas important a fost realizat la începutul anului 1999, când IBM şi Oracle au realizat standardizarea tehnologiei OLAP la institutul ANSI. Pe parcursul anului 1999 au fost realizate diverse versiuni ale sistemelor relaţionale DB2 şi Oracle (exemplu: Express Server de la Oracle) care dădeau posibilitatea exploatării acestor noi facilităţi. Funcţiile OLAP au fost incluse treptat şi în alte sisteme relaţionale. Pentru a răspunde necesităţilor de interogare în cadrul instrumentelor OLAP limbajul SQL a fost extins cu o serie de funcţii specifice pentru prelucrarea şi analiza datelor din magazia de date. Astfel a fost adus amendamentul OLAP la standardul SQL, noile funcţii disponibile pentru susţinerea tehnologiei OLAP oferind o mulţime de noi posibilităţi de sinteză a datelor şi în acelaşi timp îmbunătăţind în mod substanţial instrumentele oferite de limbajul SQL. Principalele funcţii oferite de noua tehnologie sunt ROLLUP şi CUBE. Funcţia ROLLUP adaugă, la setul rezultat în urma executării unei operaţiuni Select standard, grade de totalizare pentru fiecare nivel de grupare stabilit prin intermediul instrucţiunii GROUP BY. Gradele de totalizare sunt prezentate începând cu nivelul cel mai de jos al ierarhiei şi continuând apoi cu nivelurile superioare ale acesteia. Pentru realizarea unei analize multidimensionale prin intermediul căreia să rezulte toate posibilităţile de combinaţie între diferite dimensiuni este necesar să se utilizeze instrucţiunea CUBE. OLAP presupune existenţa unui sistem de baze de date relaţionale, capabil să execute interogări mai complexe decât cele din bazele de date obişnuite realizate pe baza opţiunilor standard din instrucţiunea SELECT. Aceste operaţiuni se realizează prin structurarea multidimensională a datelor (vizualizarea acestora se face după mai multe criterii) prin utilizarea unor noi clauze în cadrul instrucţiunilor SQL (cum ar fi ROLLUP sau CUBE).

58

La compania Red Brick Systems s-a realizat limbajul Red Brick Intelligent SQL (RISQL) care conţine o serie de extensii ale limbajului SQL cu operaţii importante pentru analiza datelor şi susţinerea procesului decizional. În cadrul tehnologiei OLAP sunt utilizate structuri multidimensionale pentru stocarea datelor şi relaţiilor dintre acestea, structuri care sunt vizualizate sub forma unor cuburi de date şi a unor cuburi în cadrul cuburilor, fiecare faţă a unui cub reprezentând o dimensiune. Informaţiile incluse în bazele de date relaţionale sunt astfel reprezentate prin două elemente esenţiale şi anume:

- dimensiuni – reprezintă categoriile descriptive după care se realizează totalizarea şi gruparea datelor;

- valori - reprezintă datele asupra cărora se realizează operaţiunile de însumare, medie, minim, maxim sau respectiv orice altă operaţiune statistică sau matematică permisă de sistemul de gestiune a bazelor de date. Se mai defineşte şi termenul de ierarhie, care reprezintă nivelurile de detaliere pentru o dimensiune de date. Exemplul reprezentativ de analiză multidimensională îl constituie o bază de date a vânzărilor. Astfel, în cadrul unei asemenea baze de date organizarea informaţiilor pentru realizarea interogărilor prin intermediul OLAP presupune existenţa celor două elemente:

- dimensiunile - reprezentate în funcţie de necesităţile de analiză pe structura geografică (regiune, judeţ, oraş, client) sau pe structura produselor vândute (model, caracteristici model, data vânzării);

- valorile - reprezentate de vânzările cantitative sau valorice (cifra de afaceri) asupra cărora se vor aplica funcţiile statistico-matematice de consolidare a datelor (sum, average, min, max, etc.).

Spre exemplu, datele privind valoarea vânzărilor de locuinţe pe localităţi pe trimestre ale anului 2010 ar putea fi reprezentate într-o bază de date relaţională printr-un tabel cu trei coloane astfel:

LOCALITATE

TRIMESTRU

VALOARE VÂNZĂRI (mii lei)

(2010)

Suceava

T1

1256

Suceava

T2

1048

Suceava

T3

1512

Suceava

T4

1200

Rădăuţi

T1

810

Rădăuţi

T2

725

Rădăuţi

T3

820

Rădăuţi

T4

875

Fălticeni

T1

514

Fălticeni

T2

550

Fălticeni

T3

535

Fălticeni

T4

511

Gura Humorului

T1

623

Gura Humorului

T2

712

Gura Humorului

T3

594

Gura Humorului

T4

730

59

Datele de mai sus pot fi reprezentate mai natural printr-o matrice bidimensională după cum este ilustrat în Fig. 3.1.

TRIMESTRU T1 T2 T3 T4 LOCALITATE Suceava 1256 1048 1512 1200 Rădăuţi 810 725 820
TRIMESTRU
T1
T2
T3
T4
LOCALITATE
Suceava
1256
1048
1512
1200
Rădăuţi
810
725
820
875
Fălticeni
514
550
535
511
Gura Humorului
623
712
594
730

Fig. 3.1. Reprezentare date relaţionale printr-o matrice bidimensională

Datele privind valoarea vânzărilor de locuinţe pe tipuri de locuinţe pe localităţi pe trimestre ale anului 2010 ar putea fi reprezentate într-o bază de date relaţională printr-un tabel cu patru coloane astfel:

TIP

LOCALITATE

TRIMESTRU

VALOARE VÂNZĂRI (mii lei)

LOCUINŢĂ

(2010)

Garsonieră

Suceava

T1

256

Garsonieră

Suceava

T2

148

Garsonieră

Suceava

T3

520

Garsonieră

Suceava

T4

400

Apart. 2 camere

Suceava

T1

312

Apart. 2 camere

Suceava

T2

215

Apart. 2 camere

Suceava

T3

160

Apart. 2 camere

Suceava

T4

290

Apart. 3 camere

Suceava

T1

262

Apart. 3 camere

Suceava

T2

245

Apart. 3 camere

Suceava

T3

190

Apart. 3 camere

Suceava

T4

270

Garsonieră

Rădăuţi

T1

210

Garsonieră

Rădăuţi

T2

225

Garsonieră

Rădăuţi

T3

320

Garsonieră

Rădăuţi

T4

275

Garsonieră

Fălticeni

T1

127

Garsonieră

Fălticeni

T2

158

Garsonieră

Fălticeni

T3

215

Garsonieră

Fălticeni

T4

195

Datele de mai sus pot fi reprezentate mai natural printr-un cub tridimensional după cum este ilustrat în Fig. 3.2.

60

520 400
520
400

Fig. 3.2. Reprezentare date relaţionale printr-un cub tridimensional

În acest mod natural de reprezentare (matrice, cub) sunt puse în evidenţă dimensiunile (LOCALITATE, TRIMESTRU, în Fig.3.1.), respectiv (LOCALITATE, TIP LOCUINŢĂ, TRIMESTRU, în Fig.3.2.) şi valorile corespunzătoare realizând astfel structurarea datelor într-o bază de date multidimensională.

Alegerea modului de structurare a datelor este dictată de tipurile de interogări ce urmează a fi formulate de utilizator. Astfel, dacă utilizatorul formulează interogări simple de forma

Care este valoarea vânzărilor de locuinţe din trimestrul

pentru localitatea

atunci nu este necesară structurarea datelor într-o bază de date multidimensională, însă dacă utilizatorul formulează interogări cum ar fi:

Care este valoarea anuală totală a vânzărilor de locuinţe pentru fiecare localitate Care este valoarea anuală medie a vânzărilor de locuinţe pentru fiecare localitate atunci este necesară gruparea mai multor date şi efectuarea unor operaţii (suma, media, etc), ceea ce pentru volume mari de date (mii de localităţi, nr. mare de ani) necesită timp semnificativ de lucru în cazul datelor gestionate cu un SGBD relaţional.

Instrumente OLAP

Există trei tipuri de instrumente OLAP şi anume (sursa [COBS01]):

- instrumente OLAP multidimensionale (MOLAP);

- instrumente OLAP relaţionale (ROLAP);

- mediul de interogare MQE.

61

Instrumentele

MOLAP

utilizează

organizarea

datelor

în

structuri

multidimensionale şi au următoarea arhitectură:

Server baze de date

Încărcare

Cerere de interogare
Cerere de
interogare

Rezultat

interogare

date Încărcare Cerere de interogare Rezultat interogare Server MOLAP Instrumente de acces pentru utilizatorii
date Încărcare Cerere de interogare Rezultat interogare Server MOLAP Instrumente de acces pentru utilizatorii

Server

MOLAP

Cerere de interogare Rezultat interogare Server MOLAP Instrumente de acces pentru utilizatorii finali Exemple
Cerere de interogare Rezultat interogare Server MOLAP Instrumente de acces pentru utilizatorii finali Exemple

Instrumente de

acces pentru

utilizatorii finali

MOLAP Instrumente de acces pentru utilizatorii finali Exemple de produse MOLAP: - Analisys Server - Essbase

Exemple de produse MOLAP:

- Analisys Server

- Essbase realizat de compania Arbor Software;

- Express Server realizat de compania Oracle;

- Lightship Server realizat de compania Pilot Software;

- TM/1 realizat de compania Sinper;

- Gentium realizat de compania Planning Sciences;

- Multiway realizat de compania Kenan Technology.

realizat de compania Pilot Software;

Instrumentele ROLAP folosesc sistemele relaţionale SGBDR utilizând un strat de meta-date, permiţând crearea de vederi multidimensionale ale relaţiilor bidimensionale şi au următoarea arhitectură:

Server baze de date relaţionale

următoarea arhitectură: Server baze de date relaţionale Limbaj SQL Rezultat cerere SQL Server ROLAP Cerere de

Limbaj SQL

arhitectură: Server baze de date relaţionale Limbaj SQL Rezultat cerere SQL Server ROLAP Cerere de interogare

Rezultat

cerere SQL

Server

ROLAP

relaţionale Limbaj SQL Rezultat cerere SQL Server ROLAP Cerere de interogare Rezultat interogare Instrumente de

Cerere de

interogare

Rezultat

interogare

Instrumente de

acces pentru

utilizatorii finali

Instrumente de acces pentru utilizatorii finali Exemple de produse ROLAP: - Axsys Server realizat de

Exemple de produse ROLAP:

- Axsys Server realizat de compania Information Advantage;

- DSS Agent/DSS Server realizat de compania MicroStrategy;

- Beacon realizat de compania Platinum/Prodea Software;

- Metacube realizat de compania Informix/Stanford Technology Group;

- HighGate Project realizat de compania Sybase.

Mediul de interogare MQE furnizează datele extrase direct de la sistemele SGBDR sau printr-un server MOLAP intermediar sub forma unui cub de date care vor fi stocate analizate şi actualizate local la utilizatorul final. Arhitectura mediului MQE este reprezentată mai jos.

Server baze de date relaţionale

este reprezentată mai jos. Server baze de date relaţionale Încărcare Limbajul SQL Rezultat interogare Server MOLAP

Încărcare

Limbajul SQL

Rezultat interogare

relaţionale Încărcare Limbajul SQL Rezultat interogare Server MOLAP 62 Instrumente de acces pentru

Server

MOLAP

Încărcare Limbajul SQL Rezultat interogare Server MOLAP 62 Instrumente de acces pentru utilizatorii finali
Încărcare Limbajul SQL Rezultat interogare Server MOLAP 62 Instrumente de acces pentru utilizatorii finali
Încărcare Limbajul SQL Rezultat interogare Server MOLAP 62 Instrumente de acces pentru utilizatorii finali
Încărcare Limbajul SQL Rezultat interogare Server MOLAP 62 Instrumente de acces pentru utilizatorii finali

62

Instrumente de

acces pentru

utilizatorii finali

SQL Rezultat interogare Server MOLAP 62 Instrumente de acces pentru utilizatorii finali Cerere date Rezultat cerere

Cerere date

Rezultat cerere
Rezultat
cerere

Exemple de produse MQE:

- PowerPlay

- Pablo realizat de compania Andyne Software;

- Mercury Project realizat de compania Business Objects;

- CrossTarget realizat de compania Dimensional Insight;

- Media realizat de compania Speedware.

realizat de compania Cognos Software;

Această soluţie este preferată de realizatorii de astfel de produse deoarece este simplu de instalat şi utilizat şi necesită costuri reduse, însă oferă posibilităţi de analiză limitate şi necesită o redundanţă sporită a datelor.

Întrebări

1.

Prezentaţi sumar conceptul de sistem inteligent.

2.

Enumeraţi principalele direcţii de integrare a tehnologiei bazelor de date cu tehnologia sistemelor inteligente.

3.

Enumeraţi cele două modalităţi prin care se poate valorifica informaţia din depozitul de date.

4.

Definiţi conceptul OLTP (OnLine Transaction Processing).

5.

Care este scopul principal urmărit prin înmagazinarea datelor ?

6.

Prezentaţi definiţia dată de Bill Inmon pentru magazia de date.

7.

Prezentaţi principalele caracteristici ale unei magazii de date.

8.

Enumeraţi sursele de date pentru constituirea unei magazii de date.

9.

Enumeraţi tipurile de date care sunt reprezentate în magazia de date plecând de la sursele de date.

10.

Enumeraţi tipurile de instrumente magazii de date.

utilizate pentru construirea şi utilizarea unei

11.

Enumeraţi operaţiile ce trebuie efectuate pentru realizarea magaziei de date.

12. Prezentaţi principalele cerinţe pe care trebuie să le îndeplinească un sistem SGBDR pentru o magazie de date.

13.

Definiţi conceptul de piaţă de date şi motivaţi apariţia sa.

14.