UNIVERSITATEA “ŞTEFAN CEL MARE” SUCEAVAFACULTATEA DE ŞTIINŢE ECONOMICE ŞI ADMINISTRAŢIE PUBLICĂ

TEHNICI AVANSATE DE ORGANIZARE

ŞI EXPLORARE A DATELOR

Curs Master Semestrul II 2012 - 2013

Program de studiu MAAFAD

Conf. univ. dr. Nicolae Morariu

1

Curs 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

memoria internă şi poate conţine una sau mai multe înregistrări logice, nefiind î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

2

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).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:

3

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.

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

4

Fig.1.1 Schema generală a unei baze de date

Nivelextern

Utilizator 1 Utilizator 2 ……… Utilizator n

Nivelconceptual

Nivelintern

…

…Subschema 1 (Vedere 1)

Subschema 2 (Vedere 2)

Subschema n (Vedere n)

Baza de date fizică

Sistemul de Gestiune a

Bazelor de Date(SGBD)

SchemaConceptuală

Sistemul de Operare(SO)

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;- 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ă.

5

Î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 dateAdministratorul 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 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

6

(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.

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

7

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 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.

8

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 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).

9

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:- reţelele de calculatoare au apărut şi s-au dezvoltat din necesitatea

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 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.

10

Î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.

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

11

S1 S2 ……… Sn

Schemă externă globală

Schemă externă globală

Schema externă globală

S1 S2 ……… Sn

Schema conceptuală globală

Schema de fragmentare

Schema de alocare

Schemă locală

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

Schemă locală

Schemă locală

Nivel extern

Nivel conceptual

Nivel internBD

Nivel extern

Nivel conceptual

Nivel internBD

Nivel extern

Nivel conceptual

Nivel internBD

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 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

12

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.

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

13

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 de prelucrare a unor tipuri de date multimedia trebuie realizate în cadrul aplicaţiei multimedia prin intermediul unui limbaj gazdă.

14

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.

15

1.2. 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:

16

- 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).

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).

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).

17

Fig. 1.3. Reprezentare relaţie 1:1

e11

e12

e13

e21

e22

e23

E1 E2

e11

e12

e13

e21

e22

e23

e24

e25

e26

E1 E2

Fig. 1.4. Reprezentare relaţie 1:n

e11

e12

e13

e14

e21

e22

e23

e24

e25

e26

E1 E2

Fig. 1.5. Reprezentare relaţie m:n

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

e11 -> e21 , e24 e12 -> e22 e13 -> e23 , e25 e14 -> e21 , e23

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).

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.

18

e11

e12

e13

e14

e21

e22

e23

e24

e25

e26

E1 E2l1

l2

l3

l4

l5

l6

l7

l8

L

e11

e12

e13

e14

e21

e22

e23

e24

e25

e26

E1 E2l1

l2

l3

l4

l5

l6

l7

l8

L

Fig. 1.6. Descompunere relaţie m:n în două relaţii 1:n

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

TREE S3RECORD 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

19

E0 (rădăcină)

E1 E2 … En

E2k E21 …

Fig. 1.7. Diagrama structurii datelor în modelul ierarhic

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.

Î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.

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ă>

20

P

M1 M2 Mn…

NEXT

PRIOR OWNER

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

LE1E2

E1

E2 E3 E4 E5

E9 E8

E7 E6

LE1E3 LE1E4 LE1E5

LE3E6

LE8E6

L1E3E7

LE9E7

LE6E7

LE5E5

E10

Fig. 1.8. Diagrama structurii datelor în modelul reţea

L2E3E7

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.

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 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

21

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;- 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ă;

22

- 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 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.

23

Întrebări

1. Principalele modalităţi de organizare a datelor pe suporturi externe de memorare sunt: a) Fişierul; b) Tabela; c)Înregistrarea; d) Dosarul; e) Baza de date.

2. O bază de date este: 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;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ă).

24

Curs 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 de date, fiind din acest punct de vedere asemănător pseudocodului utilizat în activitatea de programare.

25

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;- Editarea digitală (stocarea electronică a cărţilor, revistelor, ziarelor, articolelor şi

furnizarea lor la consumatori prin reţele foarte rapide);- Sistemele informaţionale geografice GIS (Geographical Information Systems);- 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;- 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.

26

2.1. Utilizarea tehnologiei orientate obiectTehnologia 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ă obiectUn 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;

- 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ă.

27

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 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:

28

- 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ă;- 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ă;

29

- 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 obiecteTehnologia 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);- 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).

30

Modelul de date orientat spre obiecte ODMGUn 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 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 - colecţii ordonate care permit duplicate; - Array - şir unidimensional a cărui lungime variază dinamic;- Dictionary - secvenţă neordonată a perechilor de valori cheie.

31

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.

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, 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.

32

Mesaj

Cerere

BROKER DE CEREREDE OBIECTE (ORB)

Solicitant

Furnizori

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

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 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);

33

- 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:- 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 (prin definirea de tipuri de date abstracte şi moştenire proprietăţi şi

metode se pot extinde nelimitat elementele predefinite de sistem);- 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

34

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 şi ascunderii

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.

Metode utilizate pentru realizarea unui SGBDOOAnalizâ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 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

35

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 pentru a obţine funcţionalitatea obiectelor în sistemele relaţionale...în afară de a le 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.

SQL3. Extensii ale limbajului SQL2 cu facilităţi de orientare spre obiecte (SQL3)În cele ce urmează vor fi prezentate succint principalele extensii ale

standardului SQL2 cu facilităţi de orientare spre obiecte şi anume: tipuri de rânduri (ROW), tipuri definite de utilizator (UDT), rutine definite de utilizator (UDR), subtipuri şi supertipuri, identitatea obiectelor, tipuri de referinţe, tipuri de colecţii, module stocate persistente, obiecte mari.

Tipuri de rânduri (ROW)Un tip de rând este un tip de dată compusă, definită printr-o secvenţă de

perechi denumire câmp / tip de date, care va putea fi utilizată la fel ca şi o dată elementară, astfel încât grupări de date sau rânduri complete vor putea fi: memorate în variabile, transmise ca argumente rutinelor, returnate ca valori din apelul funcţiilor, folosite ca valori ale unei coloane dintr-un tabel.

Tipuri definite de utilizator (UDT)Utilizatorul poate defini tipuri abstracte de date (ADT) numite tipuri definite de

utilizatori (UDT), care pot fi folosite în acelaşi mod ca şi tipurile predefinite (INT, CHAR, VARCHAR, FLOAT etc.). Tipurile definite de utilizator pot fi:- tipuri distincte ca de exemplu:

CREATE TYPE tip_Codf AS VARCHAR(3) FINAL;- tipuri structurate constând din una sau mai multe definiţii de atribute şi declaraţii de rutine .În afara definiţiei tipului sunt vizibile numai definiţiile atributelor şi rutinelor nu şi implementarea acestora. Protejarea atributelor şi rutinelor poate fi realizată cu ajutorul specificaţiilor public, private, protected astfel:- public – vizibile pentru toţi utilizatorii autorizaţi ai tipului UDT;- private – vizibile numai în cadrul definiţiei UDT care le conţine;- protected – vizibile în tipul UDT care le conţine cât şi în subtipurile acelui tip UDT.Opţiunea implicită în absenţa altei specificări este public şi este luată în considerare ultima specificaţie.

Pentru fiecare atribut sunt definite automat o funcţie observator (get) – care returnează valoarea curentă a atributului şi o funcţie mutator (set) – care stabileşte valoarea atributului la o valoare specificată ca parametru. De asemenea este definită automat o funcţie (public) constructor pentru a crea noi instanţe ale tipului UDT , funcţie ce are aceeaşi denumire şi tip ca şi UDT. Cele 3 funcţii pot fi redefinite de către utilizator în definiţia tipului UDT.Pot fi utilizate două tipuri de atribute şi anume:- atribute stocate – corespund datelor stocate şi sunt descrise prin denumire atribut urmat de tip de date (orice tip de date cunoscut sau alte tipuri UDT);

36

- atribute virtuale – nu corespund unor date stocate, ci unor date derivate din datele stocate (ex. vechime este derivat cu ajutorul funcţiei get_vechime şi atribuit cu ajutorul funcţiei set_vechime).Valoarea unui atribut poate fi specificată folosind o notaţie cu punct (“>>” sau “.”).Prin specificarea NOT FINAL se precizează faptul că pentru tipul respectiv pot fi definite subtipuri.

Rutine definite de utilizator (UDR –User Defined Routine)Rutinele definite de utilizator definesc metodele de manipulare a datelor, pot fi

definite ca parte a unui tip UDT, sau separat ca parte a unei scheme, pot fi proceduri, funcţii sau rutine iterative, pot fi definite complet în limbajul SQL, sau pot fi furnizate extern într-un limbaj de programare ca de exemplu C++.

O procedură poate fi apelată cu instrucţiunea SQL CALL şi poate avea zero, unul sau mai mulţi parametri: de intrare (IN), de ieşire (OUT), de intrare-ieşire (INOUT).

Pentru rutinele externe se utilizează instrucţiunea CREATE FUNCTION cu clauza EXTERNAL prin care se precizează fişierul obiect ce conţine codul obiect al funcţiei compilate, iar clauza NO SQL arată că această funcţie nu conţine instrucţiuni SQL.

Subtipuri şi supertipuriTipurile UDT pot fi organizate într-o ierarhie subtip/supertip utilizând clauza

UNDER.Este acceptată moştenirea multiplă (un tip poate avea mai multe supertipuri şi mai multe subtipuri). Un subtip moşteneşte toate atributele şi comportamentele supertipurilor sale, poate defini atribute şi funcţii suplimentare şi poate anula funcţii moştenite. O instanţă a unui subtip este considerată instanţă a tuturor supertipurilor sale. Pentru a crea un subtip este necesar ca utilizatorul să aibă privilegiul UNDER pentru fiecare tip definit de utilizator şi specificat ca supertip în definiţia subtipului.

Crearea tabelelorInstanţele obiectelor (tipuri UDT) create în SQL3 devin persistente numai dacă

sunt stocate în tabele. Pentru crearea unui tabel se va utiliza instrucţiunea CREATE TABLE. Este posibil ca în SQL3 să nu poată fi aplicată o interogare SQL tuturor instanţelor unui tip UDT dat, deoarece limbajul SQL3 nu dispune de un mecanism de stocare a tuturor instanţelor unui tip UDT, în afară de cazul când utilizatorul creează explicit un singur tabel în care sunt stocate toate instanţele. În astfel de situaţii problema poate fi rezolvată utilizând mecanismul de moştenire a tabelelor, care permite crearea unui tabel care moşteneşte toate atributele din unul sau mai multe tabele existente, cu ajutorul clauzei UNDER, facilitatea de subtabel/supertabel fiind independentă de facilitatea de moştenire a tipurilor UDT. Un tabel va moşteni toate coloanele din supertabelele sale, putând defini în plus şi alte coloane proprii. Ca şi în cazul subtipurilor pentru a putea crea un subtabel, utilizatorul trebuie să aibă privilegiul UNDER pentru fiecare supertabel referit.

Pentru interogarea şi reactualizarea tabelelor în SQL3 se utilizează instrucţiuni similare ca şi în SQL2 cu o serie de extensii pentru manipularea obiectelor.Spre exemplu în interogarea:

SELECT p.nume,p.get_vechime FROM profesori p WHERE p.este_decaneste utilizată funcţia virtuală get_vechime moştenită, iar în clauza WHERE este

37

utilizată funcţia este_decan definită de utilizator.

Tipuri de referinţe şi identitatea obiectelorSpre deosebire de SQL2 în care definirea relaţiilor dintre tabele se realizează

prin mecanismul cheie primară/cheie străină, în SQL3 pot fi utilizate tipurile de referinţe pentru a defini relaţiile dintre tipurile de rânduri şi a identifica în mod unic un rând din cadrul întregii baze de date. Valoarea tipului de referinţă poate fi stocată într-un tabel şi utilizată ca o referinţă directă la un anumit rând din alt tabel. Tipul de referinţă are o funcţionalitate similară identificatorului OID din sistemele SGBDOO (spre exemplu în INFORMIX un OID este un identificator unic de 64 biţi din care 24 biţi identifică tabelul, iar 40 biţi identifică rândul din tabel). Un tip de referinţă este specificat prin cuvântul cheie REF, iar în tabelele de bază se precizează VALUES ARE SYSTEM GENERATED. Pentru a limita referinţele la un anumit tabel se va utiliza clauza SCOPE la crearea tabelului astfel:

CREATE TABLE <nume tabelă 1> OF <tip dată> (PRIMARY KEY <nume atribut>, SCOPE FOR ,<nume referinţă> IS <nume tabelă 2>);.

Tipuri de colecţiiColecţiile pot fi utilizate pentru a crea tabele imbricate astfel încât o coloană

dintr-un tabel va conţine un alt tabel. SQL3 defineşte un tip de colecţie imbricat ARRAY, care reprezintă un şir unidimensional cu un număr maxim de elemente şi în plus sunt avute în vedere tipurile de colecţii parametrizate:

- LIST – colecţie ordonată care permite dubluri;- SET – colecţie neordonată care nu permite dubluri;- MULTISET – colecţie neordonată care permite dubluri.

Parametrul poate fi un tip predefinit, un tip UDT, un tip de rând sau o altă colecţie, însă nu poate fi un tip de referinţă sau un tip UDT care conţine un tip de referinţă. Într-o colecţie toate elementele trebuie să fie de acelaşi tip sau din aceeaşi ierarhie de tipuri.

Module stocate în baza de datePentru a conferi limbajului SQL completitudine de calcul, în standardul SQL3

au fost adăugate instrucţiuni noi astfel încât comportamentul obiectelor să poată fi stocat în baza de date sub formă de instrucţiuni SQL care pot fi grupate în proceduri (module) care ulterior pot fi apelate şi executate din cadrul bazei de date. Dintre instrucţiunile noi adăugate menţionăm:- instrucţiunea de atribuire DECLARE- instrucţiunea de prelucrare condiţionată IF…THEN…ELSE…END IF;- instrucţiunea de selecţie a unei alternative CASE…WHEN...THEN...END CASE;- instrucţiuni pentru iteraţii FOR…END FOR, WHILE…END WHILE, REPEAT…END REPEAT;- instrucţiunea CALL pentru apelul procedurilor.

Declanşatoare (trigger-e)Un declanşator (trigger) este o instrucţiune SQL compusă care este executată

ori de câte ori apare evenimentul declanşator. Declanşatoarele pot fi utilizate pentru validarea datelor de intrare, întreţinerea informaţiilor de audit (înregistrarea modificărilor efectuate asupra bazei de date şi de către cine), susţinerea avertizărilor (ex. utilizarea poştei electronice) în care este necesară întreprinderea unei acţiuni

38

atunci când un tabel este reactualizat într-un mod oarecare, realizarea reproducerii datelor (copierea şi întreţinerea datelor pe servere multiple, metodă preferată în locul distribuirii datelor). Un declanşator poate fi lansat înainte (BEFORE) sau după (AFTER) apariţia evenimentului asociat lui, pentru fiecare rând (FOR EACH ROW) afectat de eveniment, sau implicit o singură dată pentru întregul eveniment (FOR EACH STATEMENT). Evenimente declanşatoare pot fi de exemplu operaţiile INSERT, UPDATE, DELETE etc. Pentru a crea un declanşator, utilizatorul trebuie să aibă privilegiul TRIGGER pentru tabelul specificat, precum şi alte privilegii necesare pentru a executa instrucţiunile SQL din cadrul declanşatorului.

Obiecte mariUn obiect mare este un câmp dintr-un tabel în care poate fi memorată o

cantitate mare de date reprezentând fie un fişier text mare, fie un fişier grafic. În SQL3 sunt definite următoarele tipuri de obiecte mari:

- obiecte binare mari BLOB (Binary Large Object) reprezentând şiruri binare;- obiecte mari de tip caracter CLOB, NCLOB (Character Large Object, National

Character Large Object) reprezentând şiruri de caractere.Aceste tipuri de obiecte diferă de vechile obiecte BLOB din sistemele de baze de date tradiţionale în care câmpurile BLOB sunt şiruri de octeţi neinterpretabile, ceea ce necesită ca întregul obiect BLOB să fie transferat prin reţea de la serverul SGBD la client, fără nici o prelucrare chiar dacă astfel de câmpuri reprezintă tipuri de date structurate cum ar fi : imagini, imagini video, documente de prelucrare de texte Word sau pagini Web.

Spre deosebire de sistemele tradiţionale, în SQL3, asupra obiectelor mari se pot efectua unele operaţii pe serverul SGBD. Astfel operatorii standard de tip şir, care operează asupra şirurilor de caractere operează şi asupra obiectelor mari de tip caracter CLOB, NCLOB. Aceşti operatori sunt:- operatorul de concatenare şir1 || şir2 – concatenează cele două şiruri;- funcţia SUBSTRING(şir FROM poziţie FOR lungime) – returnează subşirul extras

din “şir” de la poziţia “poziţie” pe lungimea “lungime”;- funcţia de suprapunere a caracterelor OVERLAY(şir1 PLACING şir2 FROM

poziţie FOR lungime) – înlocuieşte un subşir din “şir1” începând din poziţia “poziţie” pe lungimea “lungime” cu “şir2”;

- funcţiile de pliere UPPER(şir) şi LOWER(şir) – transformă toate caracterele litere din “şir” în mari respectiv mici;

- funcţia de aranjare TRIM(LEADING | TRAILING | BOTH şir1 FROM şir2) – returnează “şir2” cu “şir1” premergător şi/sau posterior eliminat. Dacă nu este specificată clauza FROM, atunci toate spaţiile premergătoare şi posterioare sunt eliminate din “şir2”;

- funcţia CHAR_LENGTH(şir) – returnează lungimea şirului “şir”;- funcţia POSITION(şir1 IN şir2) – returnează poziţia de început a şirului “şir1” în

cadrul şirului “şir2”.Astfel de coloane CLOB nu pot fi utilizate în clauzele GROUP BY, ORDER BY, în definiţiile de constrângeri, sau în operaţiile cu mulţimi (UNION, INTERSECT, EXCEPT).

Obiectele binare mari BLOB sunt şiruri de octeţi asupra cărora pot fi efectuate următoarele operaţii similare celora definite pentru obiectele mari de tip şir:

- operatorul de concatenare pentru obiecte BLOB;- funcţia subşir pentru obiecte BLOB;- funcţia de suprapunere pentru obiecte BLOB;

39

- funcţia de aranjare pentru obiecte BLOB;- funcţia BLOB_LENGTH;- funcţia POSITION pentru obiecte BLOB.

Modalităţi de utilizare a limbajului SQLÎn majoritatea sistemelor SGBD, limbajul SQL poate fi utilizat atât direct ca

limbaj de sine stătător (interactiv de la un terminal), cât şi înglobat în cadrul unui alt limbaj de programare (host language) caz în care programul în limbaj gazdă va apela instrucţiuni SQL. În cazul utilizării în cadrul unui limbaj gazdă, instrucţiunile SQL pot fi, fie interpretate şi compilate în momentul rulării aplicaţiei, fie compilate în prealabil înainte de momentul rulării aplicaţiei (SQL înglobat dinamic) cu ajutorul instrucţiunilor PREPARE şi EXECUTE sau EXECUTE IMMEDIATE.

Utilizarea limbajului SQL înglobat necesită respectarea următoarelor cerinţe:

- toate variabilele din limbajul gazdă utilizate în instrucţiuni SQL trebuie declarate în cadrul unei secţiuni de declarare delimitată prin BEGIN DECLARE SECTION şi END DECLARE SECTION;

- fiecare instrucţiune SQL va fi precedată de cuvintele cheie EXEC SQL;- variabilele din limbajul gazdă referite în instrucţiuni SQL trebuie precedate de

caracterul ”:”;- în secţiunea de declarare se va defini o variabilă SQLSTARE care, după execuţia

fiecărei instrucţiuni SQL, va conţine un cod de stare (00000 instrucţiunea a fost executată cu succes, 02000 nu au fost găsite date , etc.) care va trebui testat în program;

- instrucţiunea SQL SELECT singulară (care returnează un singur rând) va conţine clauza INTO pentru specificarea variabilelor în care se va depune rezultatul interogării;

- pentru interogările din care rezultă mai multe rânduri se vor defini cursoare pentru accesarea rândurilor unul câte unul cu ajutorul instrucţiunilor DECLARE CURSOR, OPEN, FETCH, CLOSE.

Având în vedere aceste cerinţe, în continuare este prezentată structura generală a unui program de utilizare SQL înglobat.

EXEC SQL BEGIN DECLARE SECTION ; /* declarare variabile PL/I */

DCL SQLSTARE CHAR(5) ;

DCL SURSASQL CHAR VARYING (65000) ;

………………………………

EXEC SQL END DECLARE SECTION ;

EXEC SQL DECLARE <nume cursor> CURSOR FOR /* declarare cursor */

<instrucţiune SELECT> ;

………………………………………………………….

EXEC SQL SELECT <lista câmpuri> /* instrucţiune SELECT singulară */

INTO <lista variabile> FROM <lista tabele> WHERE <condiţie> ;

/* utilizare cursor */

EXEC SQL OPEN <nume cursor> ;

WHILE <condiţie> ;

40

EXEC SQL FETCH <nume cursor> INTO <lista variabile> ;

..................................................................................................

END WHILE ;

EXEC SQL CLOSE <nume cursor> ;

/* exemplu de utilizare a limbajului SQL înglobat dinamic */

SURSASQL =’DELETE FROM cadre WHERE data_angajarii < ”01/01/1940”’ ;

EXEC SQL PREPARE COMPILATSQL FROM :SURSASQL ;

EXEC SQL EXECUTE COMPILATSQL ;

O altă modalitate de utilizare a limbajului SQL înglobat mai eficientă decât utilizarea SQL înglobat dinamic o reprezintă interfeţele SQL/CLI (SQL Call-Level Interface) şi ODBC (Open DataBase Connectivity) Microsoft, care permit accesul la baza de date dintr-un program scris într-un limbaj gazdă (ca de exemplu C++), prin apelarea unor rutine furnizate de producător, rutine care vor utiliza SQL dinamic pentru efectuarea operaţiilor cerute în baza de date. Aceste interfeţe asigură independenţa de sistemul SGBD utilizat, ceea ce nu se întâmplă în cazul utilizării SQL înglobat dinamic deoarece necesită compilator SQL specific SGBD-ului.

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.

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

41

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ţionalePenru 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: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).

42

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.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.

43

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 multivaloricePentru 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ă.

2.2.3. Dependenţe de cuplareSe 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

44

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,...,Rn astfel încât R să fie echivalentă cu uniunea proiecţiilor R1,...,Rn. Deşi normalizarea este o operaţie utilă în 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 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

45

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 WebEvoluţ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 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.

46

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.

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.

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

47

Microsoft Internet Information Server [IIS]Active Server Pages [ASP]

Baza de date

INTERNET/INTRANET

Weowser WebBrowser Web

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

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 InformixData 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 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;

48

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 întreţinute de autori diferiţi;- dificultăţi de întreţinere date-informaţii de natură dinamică (produse, preţuri, etc.)

întreţinute atât în baze de date cât şi în pagini HTML;- interconectivitate globală - Internet, Intranet/Extranet + baze de date.

2.4. Baze de date deductiveUna 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 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.

49

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,…,qnPartea 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ţionalAvând în vedere bazele de date relaţionale, fiecare fapt r(c1,c2,…,ck) din baza

de fapte EDB poate fi pus în corespondenţă cu o tuplă <c1,c2,…,ck> 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 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)).

50

- 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 DATALOGDATALOG 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ă

L0 :- L1,…,Ln (2.1)L0 se numeşte capul clauzei, iar - L1,…,Ln se numeşte corpul clauzei. Fiecare dintre Li este numit literal şi are forma pi(t1,…,tk), pi fiind un simbol numit predicat iar ti se numesc termeni, fiecare ti 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 reguliAceste 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 2.1 reprezintă o formulă de forma

X1,…, Xn(L1…LnL0) (2.2) unde X1,…,Xn 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(c1,…,cn) cu ci

constante;- EBH este partea extensională a lui HB (mulţimea predicatelor extensionale);- IBH este partea intensională a lui HB (mulţimea predicatelor intensionale);- 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 : EBHIBH (2.3) care asociază fiecărei baze de date extensionale EEBH mulţimea

P(E) = cons(PE)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

51

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(a1,…,an) :- q1(b1,…,bk),…,qm(b1,…bh) (2.5)Clauzei C îi corespunde în algebra relaţională o relaţie de incluziune de forma:

Expr(Q1,…,Qm)P (2.6)între relaţiile P,Q1,…,Qm care corespund predicatelor p,q1,…,qm 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(Q1,…,Qm)P (2.7)şi se generează o ecuaţie algebrică de forma P= Expr1(Q1,…,Qm) Expr2(Q1,…,Qm) …Exprmp(Q1,…,Qm) (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ă----------------------------------------------------------------------------------------------------------------------------------------------------------------------

p1(X,Y) :- c1(X,Y)p1(X,Y) :- p1(X,Z), p3(Z,Y) R1=C11,4(R12=1R3) R2

p1(X,Z) :- p2(X,Y)

p2(X,Y) :- p1(X,Z), p3(Z,Y) R2=1,4(R12=1R3) C3

p2(X,Y) :- c3(X,Y)

p3(X,Y) :- p3(X,Z), c2(Z,Y) R3=1,4(R32=1C2) C4

p3(X,Y) :- c4(X,Y)

?- p1(a,X) 1=a(R1)----------------------------------------------------------------------------------------------------------

2.4.4. SGBD deductiveSistemele 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

52

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ţionalO 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 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);

53

- 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.

Implementarea unui sistem relaţional cu modelul TR este ilustrată în exemplul de mai jos.

Relaţia CadreCod Nume Incadrare Localitate

C3Ionescu profesor Suceava

C4 Antonescu conferentiar IasiC1 Florescu lector SuceavaC2 Popescu lector IasiC6 Georgescu lector SuceavaC5 Petrescu profesor Bucuresti

Secvenţa câmpuri

1 2 3 4Cod Nume Incadrare Localitate

Secvenţa înregistrări

1C3

Ionescu profesor Suceava

2 C4 Antonescu conferentiar Iasi3 C1 Florescu lector Suceava4 C2 Popescu lector Iasi5 C6 Georgescu lector Suceava6 C5 Petrescu profesor Bucuresti

Secvenţa coloane

1 2 3 4Cod Nume Incadrare Localitate

Secvenţa rânduri

1 C1 Antonescu conferentiar Bucuresti2 C2 Florescu lector Iasi3 C3 Georgescu lector Iasi4 C4 Ionescu lector Suceava5 C5 Petrescu profesor Suceava6 C6 Popescu profesor Suceava

T.2.2. Tabela de reconstrucţie a înregistrărilor

1 2 3 4Cod Nume Incadrare Localitate

1 2 1 2 52 6 3 5 43 4 2 4 24 1 6 3 15 5 5 1 66 3 4 6 3

54

Atribute

Tupluri

Nivelul Relaţional (Relaţii)

Nivelul Fişierelor (fişiere) Fişierul asociat relaţiei Cadre

Nivelul TR (tabele) T2.1. Tabela valorilor câmpurilor

Nivelul fişierelor este un nivel coordonator între nivelul relaţional şi nivelul TR astfel încât relaţiile de la nivelul relaţional sunt asociate fişierelor de la nivelul fişiere care apoi sunt asociate tabelelor de la nivelul TR, asocieri ce se realizează după algoritmul descris mai jos.

1. Pentru fiecare variabilă de relaţie de pe nivelul relaţional, realizarea corespondenţei între variabila de relaţie şi fişierul de pe nivelul fişierelor prin care atributelor din variabila de relaţie le corespund câmpurile din fişierul ataşat numerotate de la stânga la dreapta, iar tuplurilor din variabila de relaţie le corespund înregistrările din fişierul ataşat numerotate de sus în jos. Pentru o relaţie definită de n atribute şi care conţine k tuple există n! * k! posibilităţi distincte (versiuni) de ordonare deci n! * k! fişiere echivalente (conţin aceleaşi informaţii) care vor fi numite versiuni diferite ale aceluiaşi fişier (constatare foarte importantă pentru modelul TR).

2. Realizarea corespondenţei între fiecare fişier de pe nivelul fişierelor şi două tabele de pe nivelul TR (tabela valorilor câmpurilor şi tabela de reconstrucţie a înregistrărilor) astfel încât fiecare fişier de pe nivelul fişierelor să poată fi reconstruit din cele două tabele corespunzătoare. Fiecare din cele două tabele va avea tot atâtea coloane şi rânduri câte câmpuri şi înregistrări are fişierul corespunzător, coloanele numerotate de la stânga la dreapta şi rândurile numerotate de sus în jos, iar elementul aflat la intersecţia unui rând cu o coloană se va numi celulă şi va fi adresată cu ajutorul unor indici sub forma [i,j] unde i reprezintă numărul rândului iar j numărul coloanei. Fiecare coloană din tabela valorilor câmpurilor va conţine valorile câmpului corespunzător din fişierul corespunzător ordonate crescător, astfel că nu există nici o corespondenţă din punct de vedere al conţinutului între înregistrările din fişier şi rândurile din tabelă şi deci nici între rândurile din tabelă şi tuplurile relaţiei corespunzătoare de la nivelul relaţional. Fiecare celulă din tabela de reconstrucţie a înregistrărilor conţine un număr de rând care reprezintă un pointer spre un număr de rând din tabela valorilor câmpurilor sau din tabela de reconstrucţie a înregistrărilor sau din ambele tabele astfel încât parcurgând un algoritm general valabil să poată fi reconstruite înregistrările fişierului corespunzător de la nivelul fişierelor.

Crearea tabelei de reconstrucţie a înregistrărilor

Se constată că coloana 1 din tabela valorilor câmpurilor se obţine din coloana 1 a fişierului asociat conform secvenţei 3,4,1,2,6,5. Analog, pentru coloana 2 rezultă secvenţa 2,3,5,1,6,4, pentru coloana 3 rezultă secvenţa 2,5,3,4,6,1 şi pentru coloana 4 rezultă secvenţa 6,2,4,3,5,1. Aceste secvenţe sunt numite permutări, rezultând astfel tabela permutărilor T2.3.Definind inversa unei permutări ca fiind acea permutare care produce secvenţa ordonată 1,2,3,4,5,6 (exemplu pt. 3,4,1,2,6,5 inversa este tot 3,4,1,2,6,5 deoarece 1 din secvenţa 3,4,1,2,6,5 este pe rândul 3 din tabela permutărilor, 2 din secvenţă este pe rândul 4 din tabela permutărilor, 3 din secvenţă este pe rândul 1 din tabela permutărilor, 4 din secvenţă este pe rândul 2 din tabela permutărilor, 5 din secvenţă este pe rândul 6 din tabela permutărilor şi 6 din secvenţă este pe rândul 5 din tabela permutărilor; in acest caz se constată că întâmplător cele 2 secvenţe coincid), din tabela permutărilor se obţine tabela permutărilor inverse T2.4.

55

Plecând de la această tabelă se construieşte tabela de reconstrucţie a înregistrărilor astfel: pentru a construi coloana 1 din tabela de reconstrucţie a înregistrărilor se consideră celula [i,1] din tabela permutărilor inverse şi fie r conţinutul acestei celule, apoi se consideră celula [i,2] şi fie c conţinutul acestei celule care se va depune în celula [r,1] din tabela de reconstrucţie a înregistrărilor, pentru i=1,…,6. Analog se va proceda şi pentru celelalte coloane cu menţiunea că pentru ultima coloană se iau valorile c corespunzătoare din prima coloană.

Algoritmul de reconstrucţie a înregistrărilor

Pentru reconstrucţia unei înregistrări se parcurge tabela valorilor câmpurilor şi tabela de reconstrucţie a înregistrărilor după algoritmul zigzag ilustrat în exemplul de mai jos.1). Ne poziţionăm în tabela valorilor câmpurilor pe o celulă spre exemplu [1,1] obţinând astfel valoarea primului câmp al înregistrării dorite şi anume C1.2). Ne poziţionăm în aceeaşi celulă din tabela de reconstrucţie a înregistrărilor ([1,1]) şi preluăm valoarea memorată în celulă (2), care reprezintă numărul rândului din tabela valorilor câmpurilor în care se va găsi valoarea celui de-al doilea câmp al înregistrării în coloana 2, deci se preia valoarea din celula [2,2] din tabela valorilor câmpurilor şi anume Florescu.3). Ne poziţionăm în celula [2,2] în tabela de reconstrucţie a înregistrărilor din care preluăm conţinutul, adică 3, cea ce înseamnă că valoarea următorului câmp (Incadrare) a înregistrării se află pe rândul 3 în tabela valorilor câmpurilor, coloana 3, deci se preia valoarea din celula [3,3] şi anume lector.4). Ne poziţionăm în celula [3,3] din tabela de reconstrucţie a înregistrărilor din care preluăm conţinutul (adică 4) care reprezintă rândul din tabela valorilor câmpurilor care va conţine valoarea următorului câmp al înregistrării în coloana 4, deci se preia valoarea din celula [4,4] şi anume Suceava.5). Ne poziţionăm în celula [4,4] din tabela de reconstrucţie a înregistrărilor şi preluăm valoarea memorată (1) care reprezintă rândul din tabela valorilor câmpurilor care conţine valoarea primului câmp al înregistrării (ar fi urmat al cincilea câmp însă înregistrarea are doar patru câmpuri), deci celula [1,1] care este punctul de plecare în reconstrucţia înregistrării, deci ciclul se termină. Se constată că am obţinut înregistrarea C1, Florescu, lector, Suceava care este a treia înregistrare din fişierul ataşat relaţiei Cadre. Cele două cicluri, numite zigzaguri , parcurse în cele două tabele sunt reprezentate în figura 2.3.Parcurgând algoritmul şi pentru celulele [2,1],[3,1],...,[6,1] se realizează reconstrucţia tuturor înregistrărilor din fişierul ataşat relaţiei Cadre, cea ce realizează implementarea comenzii SQL

SELECT * FROM Cadre ORDER BY Cod

56

T2.4. Tabela permutărilor inverse1234CodNumeIncadrareLocalitate13466241

1231234426435632565551

T2.3. Tabela permutărilor 1234CodNumeIncadrareLocalitate13226243

5231534421435666565411

1 2 3 4

Cod Nume Incadrare Localitate1 C12 Florescu3 lector4 Suceava56

Tabela valorilor câmpurilor

1 2 3 4

Cod Nume Incadrare Localitate1 22 33 44 156

Tabela de reconstrucţie a înregistrărilor

Analog se poate realiza parcurgerea de jos în sus, sau plecând din oricare celulă a tabelei valorilor câmpurilor, obţinând astfel ordonarea înregistrărilor după diverse criterii fără a necesita sortare sau utilizarea vreunui index.

Utilizare coloane condensate şi coloane îmbinate pentru eliminarea redundanţei datelor

Redundanţa care se constată în tabela valorilor câmpurilor poate fi eliminată prin condensarea coloanelor cu specificarea domeniilor rândurilor după cum este ilustrat în tabelul T2.5.

T2.5. Condensare coloane, specificare domenii rânduri1 2 3 4

Cod Nume Incadrare LocalitateC1 Antonescu conferentiar [1:1] Bucuresti

[1:1]C2 Florescu lector [2:4] Iasi [2:3]C3 Georgescu profesor [5:6] Iasi [4:6]C4 IonescuC5 PetrescuC6 Popescu

Prin domenii se precizează rândurile care în coloana respectivă au aceeaşi valoare şi luând numărul de rânduri per domeniu drept unitate de măsură, fiecare coloană poate fi reprezentată printr-o histogramă, ca de exemplu coloana 3 poate fi reprezentată prin histograma din figura 2.4.

57

Fig. 2.3. Zigzaguri pentru reconstrucţia unei înregistrări

Astfel, tabela valorilor câmpurilor poate fi reprezentată printr-o mulţime de histograme, iar după cum am arătat anterior, tabela de reconstrucţie a înregistrărilor reprezintă o mulţime de permutări. Prin urmare, prin modelul TR se realizează reprezentarea unei colecţii de date printr-o mulţime de histograme şi o mulţime de permutări.

Utilizarea coloanelor îmbinate permite utilizarea unei coloane în tabela valorilor câmpurilor pentru două coloane de acelaşi tip din acelaşi fişier sau din fişiere diferite, caz în care acea coloană va conţine şi specificarea domeniilor pentru frecare din cele două coloane îmbinate. Utilizarea coloanelor îmbinate prezintă o serie de avantaje ca spre exemplu în efectuarea operaţiilor de uniune (join).

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.

58

conferentiar lector profesor

Nr. rânduri

Incadrare

Fig. 2.4. Histograma corespunzătoare datelor din coloana Incadrare

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

Modele de date

SGBD Tipuri de aplicaţii Dezavantaje

IerarhicReţea

Prima generaţie

Aplicaţii din domeniul afacerilor

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

- sisteme de rezervare a locurilor(transporturi, hoteluri , etc.)

- sisteme de gestiune biblioteci- sisteme financiar-bancare

- putere de expresie limitată a limbajelor de manipulare utilizate

- posibilităţi de modelare limitateRelaţional

A doua generaţie

Modele semanticeModelul E/R

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

Modelul de date orientat spre obiecte OODM

SGBDOO

A treia generaţie

SGBDOR

Aplicaţii avansate de baze de date

- proiectarea asistată de calculator CAD

- fabricarea asistată de calculator CAM

- ingineria programării asistată de calculator CASE

- sisteme informaţionale de birou OIS şi sisteme multimedia

- editarea digitală - sisteme informaţionale geografice

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

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

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

- lipsa unui fundament teoretic- lipsa de experienţă- lipsa de standarde- produse complexe dificil de

utilizat şi cu costuri ridicate- suport limitat pentru

securitate, integritate şi vederi

Modelulde date relaţionalcu obiecte ORDM

Modelul TR

- se pierde simplitatea şi puritatea modelului relaţional

- nu sunt tratate modele de obiecte, 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

Model logic al datelor

SGBD deductive

(Sisteme de Gestiune a Bazelor de Cunoştinţe SGBC)

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.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.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 (asigură independenţa de cunoştinţe).

59

Întrebări

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.

4. Enumeraţi principalele extensii ale limbajului SQL în cadrul standardului SQL3.

5. Enumeraţi tipurile de dependenţe în bazele de date şi formele normale corespunzătoare.

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

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

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

9. Definiţi SGBD deductive.

10. Definiţi modelul TransRelaţional.

60

Curs 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:

61

- 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 inteligenteTehnologia 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 datelorSpre 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):

62

- 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:- preluare date de la sursele de date (sistemele OLTP);

63

- 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 1012

octeţi, sau pentaocteţilor 1015 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 departament sau domeniu funcţional şi prin urmare pot fi realizate într-un timp mai scurt şi cu mai puţine resurse.

64

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).

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.

65

Î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(2010)

VALOARE VÂNZĂRI(mii lei)

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

66

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

T1 T2 T3 T4

Suceava 1256 1048 1512 1200Rădăuţi 810 725 820 875Fălticeni 514 550 535 511Gura Humorului 623 712 594 730............................ ............................ ............................ ............................ ............................

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:

TIPLOCUINŢĂ

LOCALITATE TRIMESTRU(2010)

VALOARE VÂNZĂRI(mii lei)

Garsonieră Suceava T1 256Garsonieră Suceava T2 148Garsonieră Suceava T3 520Garsonieră Suceava T4 400Apart. 2 camere Suceava T1 312Apart. 2 camere Suceava T2 215Apart. 2 camere Suceava T3 160Apart. 2 camere Suceava T4 290Apart. 3 camere Suceava T1 262Apart. 3 camere Suceava T2 245Apart. 3 camere Suceava T3 190Apart. 3 camere Suceava T4 270............................ .......................... ............................ ...................................Garsonieră Rădăuţi T1 210Garsonieră Rădăuţi T2 225Garsonieră Rădăuţi T3 320Garsonieră Rădăuţi T4 275............................ .......................... ............................ ...................................Garsonieră Fălticeni T1 127Garsonieră Fălticeni T2 158Garsonieră Fălticeni T3 215Garsonieră 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.

67

LOCALITATE

TRIMESTRU

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

Î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 localitateatunci 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.

68

520 400

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

Instrumentele MOLAP utilizează organizarea datelor în structuri multidimensionale şi au următoarea arhitectură:

Exemple de produse MOLAP:- Analisys Server realizat de compania Pilot Software;- 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.

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ă:

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.

69

Serverbaze de date

ServerMOLAP

Instrumente de acces pentru

utilizatorii finali

Încărcare

Cerere de interogare

Rezultat interogare

Serverbaze de daterelaţionale

ServerROLAP

Instrumente de acces pentru

utilizatorii finali

Limbaj SQLCerere de interogare

Rezultat interogare

Rezultat cerere SQL

Serverbaze de daterelaţionale

Instrumente de acces pentru

utilizatorii finali

Încărcare

Rezultat cerere

ServerMOLAP

Limbajul SQL

Rezultat interogare

Cerere date

Exemple de produse MQE:- PowerPlay realizat de compania Cognos Software;- Pablo realizat de compania Andyne Software;- Mercury Project realizat de compania Business Objects;- CrossTarget realizat de compania Dimensional Insight;- Media realizat de compania Speedware.

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 utilizate pentru construirea şi utilizarea unei magazii de date.

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. Definiţi conceptul OLAP (OnLine Analytical Processing) şi principalele operaţii analitice care pot fi efectuate asupra datelor multidimensionale.

15. Prezentaţi elementele utilizate în cadrul tehnologiei OLAP pentru reprezentarea structurilor de date multidimensionale (dimensiuni, valori, ierarhie).

16. Enumeraţi tipurile de instrumente OLAP.

17.Exemple de produse program MOLAP.

18. Exemple de produse program ROLAP.

19. Exemple de produse program MQE.

70

Curs 4

Tehnici avansate de explorare a datelor (2)

4.1. Data Mining (DM)Pentru extragerea cunoştinţelor din volume mari de date, a apărut o nouă

disciplină referită în publicaţiile din domeniu sub diverse denumiri şi anume: Data Mining (DM), Knowledge Discovery (KD), Knowledge Discovery in Databases (KDD), Information Discovery (ID), Information Archeology (IA).

Data Mining este [NISR97] o tehnică care vizează descoperirea unor "şabloane" (patterns) semnificative în structura datelor, care să indice în general tendinţe ale pieţei, utilizându-se în acest sens tehnici complexe din diverse domenii (inteligenţă artificială, statistică, matematică, etc). “DM este extragerea informaţiilor predictive ascunse din bazele mari de date”, sau “torturarea datelor până când acestea se confesează“.

Spre deosebire de alte dezvoltări ale informaticii, cum au fost Internetul, tehnologia orientată obiect, reţelele neuronale, algoritmii genetici, etc., care au pornit de la lumea academică, fiind ulterior preluate de cea a afacerilor, în cazul DM s-a întâmplat invers, a pornit de la firmele puternice, cum sunt IBM, Microsoft, GTE, etc.,(de la necesităţile de afaceri, mai exact, de la necesitatea extragerii cunoştinţelor din imensitatea de date în mijlocul căreia se află omul modern), lumea academică sesizând ulterior problema. Firme mari, cum sunt IBM, Microsoft, GTE etc., şi-au format grupuri proprii de cercetare sau au format grupuri de cercetare cu universităţi puternice ca MIT, Stanford, Rutgers, Santafe etc. pe acest domeniu. Cele mai apropiate domenii de DM şi KDD sunt OLAP (On Line Analitic Processing) şi DSS (Decision Support Systems).

Există diverse prezentări [NISR97] privind OLAP şi DSS pe de o parte şi DM sau KDD pe de altă parte. Conform acestora, OLAP este un mod de utilizare a depozitelor de date, utilizare care presupune pe de o parte un acces în timp real (OLTP - On Line Transactional Processing), iar pe de altă parte, o analiză multidimensională (vectorială) a bazelor de date mari.

DSS este un ansamblu format din baze şi depozite de date, precum şi alte ansambluri de informaţii utile, împreună cu produse soft pentru întocmirea rapoartelor, analiza datelor, precum şi implementarea unor algoritmi de optimizare în vederea sprijinirii actului decizional în cadrul organizaţiei.

În ceea ce priveşte răspunsurile, diferenţa dintre OLAP şi DSS, pe de o parte, şi DM şi KDD, pe de altă parte, se poate asemăna cu cea dintre răspunsurile date de o bază de date şi răspunsurile date de o bază de cunoştinţe. Răspunsurile din DM şi KDD sunt mult mai flexibile, putându-se obţine modele învăţând din experienţa trecută. Raţionarea în sistemele OLAP şi DSS este deductivă, în timp ce în DM şi KDD este inductivă.

Unul dintre domeniile de utilizare a DM, de către producătorii de DSS şi OLAP este valorificarea Internetului, având în vedere marea diversitate a bazelor şi depozitelor de date ce pot fi accesate.

Alte domenii în care se acumulează volume imense de date sunt [MDAN11]:- sistemul de urmarire orbitala de la NASA: 46 MB/sec, 4.000.000 MB/zi;- biblioteca de imagini cu amprente a FBI : 200.000 GB;- imagistica medicală: baze de date de ordinul 10TB.

71

Problemele generate de explozia de dateCăutarea în volume mari de date a tiparelor care prezintă interes dintr-un

anumit punct de vedere, este o necesitate în condiţiile în care în ultima perioadă de timp a avut loc o creştere exponenţială a volumului de date stocate în baze de date, depozite de date sau alte depozite de informaţii, în paralel cu dezvoltarea capacităţilor şi performanţelor sistemelor de calcul. Apariţia a noi tipuri complexe necesită tehnici speciale de manipulare. Calea pentru rezolvarea acestor probleme este Data Warehousing si Data Mining.

Explorarea datelor (Data Mining) este procesul de analiză a datelor brute dinbazele de date şi de sintetizare a informaţiilor utile în procesul luării deciziilor, astfel încât prin utilizarea informaţiilor existente să fie obţinute noi fapte şi să fie descoperite noi legături anterior necunoscute chiar şi pentru experţii complet familiari cu datele respective.

Explorarea datelor pentru descoperirea cunoştinţelor din bazele de date (KDD) reprezintă [MDAN11] procesul netrivial de identificare a tiparelor din date, tipare valide, noi, potenţial utile şi inteligibile.- datele - o mulţime de evenimente- tiparul -o expresie, într-un anumit limbaj care descrie un subset al datelor sau un model aplicabil acestui subset.- proces - descoperirea cunoştinţelor din date este o succesiune de paşi care implică iteraţii multiple pentru urmatoarele faze:

• pregatirea datelor;• cautarea tiparelor;• evaluarea cunoştinţelor şi rafinarea.

Tiparele descoperite trebuie să fie:• valide pe seturi de date noi, cu un anumit grad de certitudine;• noi şi potenţ ial folositoare în sensul ca trebuie să conducă la anumite beneficii pentru utilizator;• inteligibile, daca nu imediat, cel puţin după anumite operaţii de post-procesare.

Necesitatea definirii unor măsuri cantitative pentru evaluarea tiparelor extrase:• măsuri pentru certitudine (acurateţea predicţiei estimată pe date noi);• măsuri pentru utilitate (câştigul, evaluat ca profit obţinut de pe urma predicţiei mai bune sau a creşterii vitezei de răspuns a sistemului).

Noţiunile de noutate şi inteligibilitate sunt mult mai subiective.Interesul - este o masură globală a valorii unui tipar care combină validitatea, noutatea, utilitatea şi simplitatea.Funcţia de interes poate fi definită explicit sau se poate manifesta implicit prin intermediul unei ierarhii a tiparelor detectate sau a modelelor stabilită de sistemul de descoperire a cunoştinţelor din date.

KDD presupune o abordare multidisciplinară:- tehnologia bazelor de date;- statistică;- matematică;- inteligenţă artificială (recunoaştere forme, sisteme expert, învăţare automată).

Modele pentru KDD:- Modelul academic (Fayyad);- Modelul industrial (CRISP-DM).

72

Modelul industrial (CRISP-DM) constă dintr-o succesiune de paşi, parcurşi într-o manieră interactivă şi iterativă:1. analiza scopurilor declarate de utilizatorul final şi primirea tuturor cunostinţeloranterioare necesare;2. datele ţintă sunt pregătite şi curăţate de tot ceea ce înseamnă zgomote sau valori izolate;3. se identifică caracteristica utilă pentru reprezentarea datelor, funcţie de obiectivul sarcinii de descoperire;4. se alege şi se aplică un anumit algoritm de explorare a datelor în scopul de a prezice valorile viitoare ale variabilelor de interes sau de a găsi tiparele din date, interpretabile de factorul uman;5. tiparele sunt interpretate şi evaluate cu ajutorul unor instrumente specializate, cum ar fi cele de vizualizare.

Pregatirea datelor brute pentru explorare• Datele reale conţin erori;– sunt incomplete: lipsesc valori ale unor atribute, lipsesc atribute care pot fi de interes, pot conţine doar valori agregate;– conţin zgomote: conţin erori sau date în afara domeniului;– inconsistente: contin discrepanţe în coduri sau în nume.• Activităţi importante în pregătirea datelor;– curăţare - completarea valorilor lipsă, identificarea sau eliminarea datelor care nu sunt în gama admisă, rezolvarea inconsistenţelor;– integrare;– transformare - normalizare şi agregare;– reducerea datelor - prin filtrare sau eşantionare;– discretizarea datelor continui.

Pregătirea datelor pentru data mining consumă cea mai importantă parte a eforturilor depuse în procesul de KDD având în vedere activităţile: integrarea datelor din mai multe surse, extragerea caracteristicilor şi selecţia, discretizarea datelor, curăţarea datelor.

Sarcinile explorarii datelor- previziunea / predicţia - realizarea unui model din exemplele analizate şi utilizarea modelului dezvoltat pentru a prezice valorile viitoare ale variabilei ţintă;- clasificarea – găsirea funcţiilor care grupează înregistrările într-una sau mai multe clase discrete în vederea alocării de înregistrări noi claselor existente;- analiza legăturilor - dezvoltarea regulilor de asociere între seturi de articole;- modelarea explicită - găsirea formulelor explicite care descriu dependenţele dintre diferite variabile;- clustering-ul - gruparea articolelor în subseturi similare din punct de vedere statistic. Un cluster este definit ca un subset de date. Sarcina procesului de clustering este aceea de a diviza o bază de date în clustere de înregistrări similare.- detectarea deviaţiilor - determinarea schimbărilor semnificative a valorilor esenţiale, obţinute în urma masurătorilor, faţă de valorile anterioare sau faţă de cele aşteptate.

Metode şi tehnici generale de explorare a datelor• Clasificarea : găsirea unei funcţii care include un articol de date într-una din mai multe clase predefinite.

73

• Regresia: este utilizată la prezicerea unei valori a unei variabile continue bazată pe valorile altor variabile, presupunând un model de dependenţă liniar sau neliniar.• Gruparea (clusering-ul): identifică o mulţime finită de categorii sau clustere pentru a descrie datele.• Rezumarea: găseste o descriere compactă pentru o submulţime de date.• Modelarea dependenţelor: găseste un model care descrie dependenţele semnificative dintre variabile.• Detectarea schimbărilor şi a deviaţiei : descoperă cele mai semnificative schimbări produse în date în intervalul dintre două masurători.

Tipuri de probleme care se rezolvă prin Data Mining• 1. Ce le place clienţilor mei? (Clustering).• 2. Ce clienţi trebuie să ţintesc într-o promoţie? (Clustering).• 3. Ce produse ar trebui să folosesc în promoţie? (Asocieri sau tipare secventiale).• 4. Cum ar trebui să îmi plasez noile magazine? (Clustering şi asocieri).• 5. Cum pot detecta potenţialele fraude? (Clustering plus asocieri).

Aplicatii pentru Data Mining• Gestiunea relaţiilor cu clienţii – Customer Relationsip Management (CRM)– păstrarea clienţilor• Analiza pieţii– Găsirea pieţelor ţintă– Segmentarea pieţei– Vânzări încrucişate• Detecţia fraudelor– Detecţia fraudelor în domeniul sănătăţii– Detecţia fraudelor în cazul cărţilor de credit– Detecţia fraudelor în telecomunicaţii• Altele…

În general instrumentele de Data Mining procesează datele organizate ca fişiere flat în format tabelar cu linii şi coloane unde– Liniile reprezintă obiecte– Coloanele reprezintă caracteristicirezultă un fişier (text) ce conţine un masiv de date bidimensional.Acest fişier este generat din date stocate în alte formate mai complexe cum ar fi baze de date sau foi de calcul tabelar.Este indicată utilizarea unui depozit de date (Data Warehouse) deoarece:• Datele sunt organizate pe subiecte de interes pentru utilizatori (pacienti, tipuri de teste, diagnostic…);• Permite analize din perspectivă istorică;– Utilizează o structură multidimensională sub forma unui cub de date.

Exemple de sisteme SGBDR care dispun de instrumente pentru Data Mining:- ORACLE;- DB2 IBM.

74

Reprezentarea cunoştinţelor în procesul KDD

În procesul KDD termenul de cunoştinţă este asociat cu tiparele descoperite în pasul de Data Mining. Există mai multe moduri de reprezentare a tiparelor descoperite prin procesul de KDD şi anume:

- Tabele de decizie;- Arbori de decizie;- Reguli de clasificare;- Reguli de asociere;- Clustere;

Pentru fiecare din aceste moduri de reprezentare există algoritmi fundamentali de Data Mining.

Tabela de decizie este cel mai simplu mod de reprezentare a unui proces de învăţare în care procesul este descris prin 3 elemente şi anume:reguli, condiţii, acţiuni.

Arborii de decizie constituie modalitatea naturală de reprezentare a cunoştinţelor, dacă se face o abordare “divide et impera” a unei probleme de învăţare dintr-un set de instanţe independente. Arborii de decizie sunt utilizati pentru clasificarea exemplelor necunoscute, prin testarea valorilor atributelor exemplelor prin arborele de decizie. Arborele de decizie se crează printr-un proces inductiv. Majoritatea metodelor de generare a arborilor de decizie parcurg două faze şi anume:– faza de construcţie (creştere) a arborelui;– faza de tăiere (pruning).Faza de construcţie a arborelui de decizie este un proces iterativ care implică divizarea progresivă a datelor în subseturi mai mici. Prima iteraţie consideră că nodul rădăcină conţine toate datele. Următoarele iteraţii lucrează pe noduri derivate care vor conţine subseturi de date. La fiecare divizare, variabilele sunt analizate şi este aleasă cea mai bună divizare fără a se face o verificare dinainte în arbore să se vadă dacă o altă decizie ar produce un rezultat final mai bun. Faza de tăiere identifică şi înlătură ramurile care reflectă zgomote sau excepţii.

Regulile de clasificare constituie o alternativă la arborii de decizie care sunt astfel înlocuiţi cu un set de reguli de forma

If <condiţie> Then Class = <clasa>Regulile de asociere reprezintă forma de explorare a datelor care are în

vedere descoperirea de legături interesante între atribute din datele conţinute în baze sau depozite de date. Definite în 1993 plecând de la analiza datelor referitoare la coşul de piaţă unde sunt generate reguli de forma “Un client care cumpără produsele x1,x2,..xn va cumpăra de asemenea şi produsul y cu probabilitatea c%“, regulile de asociere au devenit una din cele mai populare metode de analiză în procesul descoperirii de cunoştinţe din bazele de date.

Clustering sau analiza cluster este o metodă de divizare a unui set de date (observaţii) reprezentând descrierea unei mulţimi de obiecte în subseturi de date reprezentând grupuri de obiecte similare, fiecare grup fiind numit cluster. Este o metodă de învăţare nesupervizată şi o tehnică de analiză statistică a datelor utilizată în diverse domenii printre care: învăţare automată, data mining, recunoaştere forme, analiză imagini, bioinformatică, etc.

75

Reprezentări ale bazei de cunoştinţe în sistemele inteligente bazate pe reguliÎntr-un sistem expert bazat pe reguli de producţie, baza de cunoştinţe este

compusă dintr-o mulţime de reguli care constituie baza de reguli şi o mulţime de fapte care constituie baza de fapte.

Analiza unei baze de cunoştinţe complexe poate fi efectuată în cadrul unei reprezentări grafice a acesteia şi în acest sens pot fi utilizate următoarele două metode de reprezentare grafică:

- reprezentarea prin arbori ŞI-SAU; - reprezentarea prin grafuri de dependenţe.

Pe de altă parte, unei baze de cunoştinţe îi corespunde o tabelă de decizie care poate fi utilizată fie ca instrument ajutător în construirea bazei de cunoştinţe, fie ca mod de reprezentare a acesteia.

Arbori ŞI-SAUUn arbore ŞI-SAU pentru reprezentarea unei baze de cunoştinţe este

constituit din noduri şi arce prin care se identifică faptele şi regulile ce compun baza de cunoştinţe. Într-un arbore ŞI – SAU pot fi definite următoarele tipuri de noduri : noduri SAU, noduri ŞI şi noduri frunză.

Un nod SAU reprezintă posibilitatea determinării valorii unui fapt prin aplicarea unei reguli din mai multe posibile şi este etichetat cu identificatorul faptului ce se găseşte în partea acţiune a regulilor respective.

Un nod ŞI reprezintă forma conjunctivă a unei expresii booleene prezente în partea condiţie; iar arcul care va părăsi nodul ŞI, nod ce este înnegrit în figură, va indica nodul ce reprezintă partea acţiune a regulii (în general nodurile ŞI nu sunt etichetate).

Într-un arbore ŞI-SAU arcele care pleacă dintr-un nod ŞI, sau cele care intră într-un nod SAU, pot fi etichetate cu identificatorii regulii respective. Modul de reprezentare a nodurilor SAU, ŞI, este ilustrat în figura 4.1.

Pentru exemplificare se consideră o bază de cunoştinţe simplificată pentru analiza impactului măsurilor economice asupra unei zone.

Baza de fapte:f1 - număr agenţi economici creşte – variabilă booleană (adevărat, fals)f2 - investiţii în forma privată – variabilă alfanumerică (da, nu)f3 - investiţii în formă mixtă – variabilă alfanumerică (da, nu)f4 - rata şomajului – variabilă alfanumerică (scade, creşte, constant)f5 - indice producţie industrială – variabilă alfanumerică (scade, creşte, constant)f6 - impactul măsurilor economice – variabilă numerică putând lua valorile:

1 pt. regres economic2 pt. Stagnare3 pt. creştere economică

f7 - produs intern brut pe locuitor - variabilă alfanumerică (scade, creşte, constant)

76

Eticheta

Nod SAU Nod ŞI

Fig. 4.1. Reprezentarea nodurilor SAU, ŞI într-un arbore ŞI-SAU

Baza de reguli:(R1) dacă f1 atunci f2 = “da”(R2) dacă f2 = “da” atunci f6 = 3(R3) dacă f3 = “da” şi f1 atunci f4 = “scade”(R4) dacă f4 = “creste” atunci f6 = 1(R5) dacă f5 = “constant” atunci f6 = 2(R6) dacă f4 = “creste” atunci f7 = “scade”(R7) dacă f7 = “scade” atunci f3 = “nu”

Se constată că în această bază de reguli faptele f1 şi f5 sunt fapte de bază, faptele f2, f3, f4 şi f7 sunt fapte intermediare, iar faptul f6 este un fapt concluziv, ce va fi considerat obiectivul expertizei. Reprezentarea grafică a arborelui ŞI-SAU pentru baza de cunoştinţe de mai sus este dată în figura 4.2.

Din reprezentarea de mai sus se observă că faptul f1 constituie eticheta a două noduri frunză, corespunzător celor două apariţii ale sale în părţile condiţie ale regulilor (R1) şi (R3). De asemenea faptul f4 apare în reprezentare de două ori (ca nod frunză şi ca element al unui nod SAU). Reprezentarea sub formă de arbore impune, în acest caz, ca două noduri să aibă aceeaşi etichetă (f1) şi din cauza unor astfel de situaţii se preferă reprezentarea sub formă de graf de dependenţe.

Grafuri de dependenţeUn graf de dependenţe pentru reprezentarea unei baze de cunoştinţe este un

graf orientat în care nodurile reprezintă faptele din baza de fapte (fiecare fapt din baza de fapte reprezintă un nod unic) la care se adaugă nodurile ŞI corespunzătoare regulilor cu părţi condiţie construite cu operatorul logic şi, iar arcele sunt definite astfel:Două noduri xi şi xj sunt legate printr-un arc orientat, de la xi la xj, dacă şi numai dacă:

- fie există o regulă (Rx) dacă xi atunci xj; - fie xi este un fapt aparţinând unei părţi condiţie scrisă în forma conjunctivă,

iar xj este un nod ŞI.Grafurile de dependenţe permit reprezentarea unei baze de cunoştinţe cu un număr minim de noduri precum şi reprezentarea ciclurilor. Graful de dependenţe corespunzător bazei de cunoştinţe din exemplul anterior este reprezentat în figura 4.3.

77

f6

f2 f4 f5

f1 f3 f1

R2 R5R4

R1 R3

f7

R7

f4

R6

Fig.4.2. Reprezentarea unui arbore ŞI-SAU

f1 f2f6

f4

f5

f3

f7

R1R2

R5

R4

R3

R6R7

Fig. 4.3. Reprezentarea unui graf de dependenţe

Din reprezentarea de mai sus se constată existenţa ciclului

f4 f7 f3 nodul_şi f4.Prezenţa ciclurilor într-o bază de cunoştinţe este o caracteristică negativă şi de aceea vor trebui eliminate prin înlăturarea unor reguli din baza de reguli şi eventual adăugarea de noi reguli. Etichetarea arcelor cu identificatorul regulii corespunzătoare nu este obligatorie, însă dacă se face, permite identificarea cu uşurinţă a conţinutului regulilor din baza de reguli.

Tabele de decizieConstruirea bazei de reguli este o problemă dificilă chiar şi pentru experţii în

domeniu şi în acest sens pot fi utilizate, ca instrumente ajutătoare, o serie de tehnici printre care cea mai cunoscută este tabela de decizie. Bazei de reguli din exemplul anterior îi corespunde tabela de decizie din figura 4.4.

Reguli: R1 R2 R3 R4 R5 R6 R7

Condiţii:

Dacă

f1 D D

f2 Df3 D

f4 D D

f5 D

f7 D

Acţiuni:

Atunci

f2 X

f3 X

f4 X

f6 X X X

f7 X

Pentru sistemele expert de dimensiune mare, elaborarea manuală a tabelei de decizie este dificilă, însă au fost elaborate programe (exemplu Logic Gem) care generează, testează şi elimină regulile contradictorii sau redundante.

78

Fig.4.4. Reprezentarea unei tabele de decizie

Întrebări

1. Ce este Data Mining ?

2. Enumeraţi domenii în care se acumulează volume imense de date.

3. Definiţi conceptul Explorarea datelor pentru KDD.

4. KDD presupune o abordare multidisciplinară:

5. Definiţi modelul industrial (CRISP-DM) pentru KDD.

6. Descrieţi în ce constă pregătirea datelor pentru explorare.

7. Prezentaţi sarcinile explorării datelor.

8. Prezentaţi metode şi tehnici generale utilizate în explorarea datelor.

9. Enumeraţi Tipuri de probleme care se rezolvă prin Data Mining.

10.Enumeraţi Aplicatii pentru Data Mining.

11.Daţi exemple de sisteme SGBDOR care dispun de instrumente pentru Data Mining.

12.Enumeraţi principalele moduri de reprezentare a cunoştinţelor (tiparelor) descoperite prin procesul de KDD.

13.Definiţi tabela de decizie.

14.Definiţi arborii de decizie.

15.Definiţi regulile de clasificare.

16.Definiţi regulile de asociere.

17.Definiţi tehnica clustering.

18.Ce este o bază de cunoştinţe într-un sistem inteligent bazat pe reguli de producţie ?

79

Bibliografie:

Nicolae Morariu, ”Teorie şi practică în dezvoltarea sistemelor bazate pe cunoştinţe”, Editura Didactică şi Pedagogică Bucureşti, ISBN 973-30-1042-1, 211p, 2005.

1. [COBS01]. Thomas Connolly, Carolyn Begg, Anne Strachan – Database Systems – A Practical Approach to Design, Implementation and Management Second Edition (trad. Ed. Teora: Baze de date Proiectare . Implementare . Gestionare, Buc. 2001)2. [CVA00] Conf.univ.dr. Virgil Chichernea, Sistemul ACCESS, Ed.SYLVI, vol.I, Buc.20003. [CVF00]. Conf.univ.dr. Virgil Chichernea, lector univ.dr. Cezar Botezatu, Sistemul FoxPro,Ed.SYLVI, vol.II, Buc.20004. [DATE04]. C. J. Date, An Introduction to Database Systems, 8th Edition, published by Pearson Education, Inc. Adison Wesley Higher Education, 2004.5. [DORO98]. Robert Dollinger-Baze de date şi gestiunea tranzacţiilor,ClujNapoca,19986. [FLAM02]. Sistemele bazate pe cunoştinţe, Adina Magda Florea www.agora.ro/open/open5/ia.html7. [FPV98]. FoxPro 2.6 pentru Windows. Ghidul programatorului, Traducere Ed. Teora, 19988. [FUS02]. Doina Fusaru, Arhitectura bazelor de date – Mediul SQL, Univ.Spiru Haret, Ed.Fundatiei România de mâine, Buc.20029. [HARK00] Utilizare Microsoft Access 2000 / Susan Sales Harkins, Ken Hansen şi Tom

Gerhart ; trad. de Marian Daniel Merezeanu şi Aurelia Nicoleta Merezeanu. - Bucureşti : Teora, cop.2000. - 527 p.

10. [JOJO97]. Jones John “Data Bases in theory and practice” Ed. Thompson Computer Press, UK 199711. [MOLH03] lector univ. Nicolae Morariu, lector univ. Valeriu Lupu, ing.ec. Ovidiu Hurjui, Baze de date, ISBN 973-8293-83-9, Editura Universităţii “Ştefan cel Mare” Suceava,117 p, Suceava, 2003.12. [MONI05] Nicolae Morariu, ”Baze de date - Îndrumar de laborator”, ISBN 973-666- 159-8, Editura Universităţii Suceava, 85 p, Suceava, 2005.13. [ORA92]. Introduction to ORACLE SQL, SQL* Plus and PL/SQL Course Notes, Glenn Maslen, Published by Oracle Corporation UK Ltd. 199214. [PASC94]. Totul despre SQL Interogarea bazelor de date, Corina Pascu, Adrian Pascu, Ed. Tehnică Buc. 199415. [SAM96]. Mircea Sârbu, Analiza multidimensională http:www.byte.ro/byte96-03/datawar4.html16. [SEKH94]. Khoshafian Setrag “Object Oriented Databasses”, pub. John Whiley 1994, UK17. [TAMB96] Access - pentru programatori / Leon Tâmbulea. - Cluj-Napoca : Promedia Plus, cop.1996. - 297 p.18. [UDRI98] Aplicaţii de gestiune : Access şi Visual Basic / Mioara Udrică. - Bucureşti : Naţional, 1998. - 197 p.19. [VFP00]. Microsoft Visual FoxPro 6.0 Ghidul programatorului Ed.Teora 200020. [MDAN11]. Mirela Danubianu, Tehnici de explorare a datelor (Data mining)

80

Bibliografie extinsă

[ADIT03]. The Aditi Deductive Database, Aditi Group, Dept. of Computer Science & Software Engineering, The University of Melbourn, 2003, www.cs.mu.oz.au/research/aditi

[ALUJ95]. J.Gill Aluja, Al. P. Tacu, H. N. Teodorescu, Fuzzy Systems and Expert Systems in Decision Making, Publishing House Expert, Bucharest-Romania, ISBN 973-97235-7-8, nov.1995.

[ANDO97]. Andone I., Ţugui Al., Baze de date inteligente în managementul firmei, Ed, Dosoftei, Iaşi, 1997.

[ANDO01]. Ioan I.Andone, Robert J.Mockler, Dorothy G.Dologite, Alexandru Al.Ţugui, Dezvoltarea sistemelor inteligente în economie. Metodologie şi studii de caz., Editura Economică, Bucureşti, 2001.

[ANDO02]. Ioan Andone, Sisteme inteligente hibride. Teorie. Studii de caz pentru aplicaţii economice. Ghidul dezvoltatorului, Editura Economică, Bucureşti, 2002.

[BASE96] Tudorel Baicu, Tatiana Eugenia Şesan, Fitopatologie Agricolă, Ed.Ceres, Bucureşti, 1996.

[BGSV97]. “Banca de Resurse Genetice Vegetale” Suceava, editată la Banca de gene Suceava, 1997.

[BGSV04]. Suceava Genebank – Romania, Databaseshttp://www.svgenebank.ro

[BÂSC97]. Octavian Bâscă,.Baze de date, Ed. ALL, !997.[CAPA00]. Ion Capanu, Constantin Anghelache, INDICATORI ECONOMICI

pentru managementul micro şi macroeconomic. Calcul. Prezentare. Analiză., Editura Economică, Bucureşti, 2000.

[COBS01]. Thomas Connolly, Carolyn Begg, Anne Strachan – Database Systems – A Practical Approach to Design, Implementation and Management Second Edition (trad. Ed. Teora: Baze de date Proiectare . Implementare . Gestionare, Bucureşti 2001).

[CRIS86] M. Cristea, Rasele de Porumb din România, Bucureşti, 1986. [CTCB91] T. Crăciun, I. Tomozei, N. Coleş, Galia Butnaru, GENETICĂ

VEGETALĂ Ed. Didactică şi Pedagogică, Bucureşti, 1991.[DANA02]. Prof.univ.dr.Doina Danaiata, asist.univ.drd. Camelia Margea, Rolul

agentului într-o lume digitală. Competiţia pe scena economiei digitale. Scenarii, actori şi roluri, www.feea.uaic.ro.

[DATE04]. C. J. Date, An Introduction to Database Systems, 8th Edition, published by Pearson Education, Inc. Adison Wesley Higher Education, 2004.

[DEJP86]. Delahaye, J.P. – Systemes experte: organisation et programmation des bases de connaissances en calcul propositionnel, Laboratoire d'Informatique Fondamentale de Lille, Université des Sciences et Technologies de Lille, 1986.

[DORO98]. Robert Dollinger-Baze de date şi gestiunea tranzacţiilor, Cluj Napoca, 1998.

[DNAE04]. Computer Made from DNA and Enzymeshttp://nationalgeographic.com/news/2003/02/0224_030224_DNAcomputer.html

[DUCO96]. D. Dumitrescu, Hariton Costin – Inteligenţa Artificială. Reţele neuronale teorie şi aplicaţii, Ed. Teora Bucureşti, 1996.

[DUMA97]. Adriana Dumitraş, Proiectarea reţelelor neurale artificiale Ed.ODEON, 1997.

[DUMI99]. Ion Dumitrache, Nicolae Constantin, Monica Drăgoicea, REŢELE NEURALE Identificarea şi Conducerea Proceselor, MATRIX ROM, Bucureşti 1999.

81

[EVAM99] Evaluation and Conservation of Barley Genetic Resource to Improve Their Accessibility to Breeders in Europe. Evaluation methods 1999, EU Project GENRES CT98-104, Genbank, IPK, Gatersleben, Germany, http//barley.ipk-gatersleben.de

[FKPE00]. Florea, Adina Magda, Kayser, Daniel, Pentiuc, St. Gh. – La représentation logiques des connaissances pour les agents intelligents, Cours interactif pour l’Université Virtuelle Francophone, 2000.

[FLAM02]. Sistemele bazate pe cunoştinţe, Adina Magda Florea,www.agora.ro/open/open5/ia.html

[FLAM98]. Agenţi inteligenţi Internet, Adina Magda, www.byte.ro/byte95-04adi.html

[FUS02]. Doina Fusaru, Arhitectura bazelor de date – Mediul SQL, Univ.Spiru Haret, Ed.Fundatiei România de mâine, Buc.2002.

[GBS04]. UCSC Genome Bioinformatics. http://genome.ucsc.edu[GDB04]. The Genome Database. An international collaboration in support of the

Human Genome Project. www.gdb.org[GOLI02]. Rule Based Networks, Prof.Rodney M. Goodman, Dr.John Lindal.

www.micro.caltech.edu/research/itrule/rulenet.html[GRBR96].McGraw,K.&Hobson-Briggs, K. “Knowledge Acquisition – Principles

and Guidelines” Prentice Hall, Englewood Clifs, Nj, 1996.[GURU87]. GURU Tutor – On-line System Documentation, Micro Data Base

Systems Inc., Lafayette Indiana, 1987.[HABD93]. Herve Abdi, Les Reseaux de Neurones, Universite de Bourgogne,1993.[HELU02].Artificial Inteligence. www.cs.tcd.ie/Lucy.Hederman/DIPHI[HILL01]. W. Daniel Hillis, Maşina care gândeşte. Cum funcţionează calculatoarele.

(trad. Mihai Cipu, Ed. Humanitas, Bucureşti, 2001).[HOVI94]. Ştefan Holban, Romul Vancea, Florin Iancu , Inteligenţa Artificială.

I – Programare logică, II – Tehnici de Inteligenţă Artificială, 1994.[IDBS02]. Inteligent Database Systems.

www.cms.dmu.ac.uk/~jennyc/Intell_db_notes.htm[IEEE101]. IEEE Transactions on Computers, vol.50 nr.7 july 2001. Abort-Oriented

Concurency Control for Real-Time Databases pp. 660-673.[IEEE201]. IEEE Transactions on Computers vol.50 nr.9 sept.2001. Neural Networks

- Stohastic Neural Computation pp. 891-905.[IEEE02]. IEEE Transactions on Computers – Real-Time Processing in Client-

Server Databases, vol.51, nb.3, march. 2002, pp.269-288.[JOJO97]. Jones John “Data Bases in theory and practice” Ed. Thompson Computer

Press, UK 1997.[JRB02]. O2 Technology. Java Relational Binding: A White Paper.

http:www.o2tech.fr/jrb/wpaper.html[JSQL97]. Oracle Corporation.(1997), JSQL: Embedded SQL for Java. Preliminary

Specification, http:www.oracle.com/nca/java_nca/jsql/html/jsql-spec.html[KQML]. UMBC KQML Web. KQML Papers and presentations.

http:www.cs.umbc.edu/kqml/papers/[LRUS00] Ing. Laurentiu-Virgil RUSAN, Consideratii privind structurile de date

specifice sistemelor informationale geografice. www.revistaie.ase.ro/content/13/rusan.pdf

[LUMO02]. Valeriu Lupu, Nicolae Morariu, “The computer assisted generation of the programmers for the numerical command equipment’s of the tools machines for the mill of complex profiles”, Proceedings 3rd International Conference on

82

Microelectronics and Computer Science – Tehnical University of Moldova, september 26-28 2002, Chişinău, Vol. II, pag.242-247.

[MALE02]. Prof.Donato Malerba, Course “Basi di Dati e Basi di Conoscenza – Le Basi di Dati Deduttive”, Universita degli Studi di Bary, Italy, 2002.www.di.uniba.it/~malerba/courses/

[MAPH92]. Mathieu, Ph. – La réalisation d'un générateur de Systemes expertes, Course imprimé, Laboratoire d'Informatique Fondamentale de Lille, Université des Sciences et Technologies de Lille, 1992.

[MIKE]. http://www-lia.deis.unibo.it/Courses/AI/Lucidi/mike.pdf [MNOO97]. Ion Sainiuc, Carmen Antonovici, Radu Ungureanu, Nicolae Morariu, ”GEO-GRAPH –

Sistem Informatic Geografic utilizat în realizarea cadastrului general finanţat de Banca Mondială”, Analele

ştiinţifice ale Universităţii ”Alexandru Ioan Cuza” din Iaşi Tom XLII-XLIII, 1996-1997, pag. 51-54.

[MNVS03]. Nicolae Morariu, Sorin Vlad , “Consideraţii privind dezvoltarea sistemelor inteligente în economie”, Economia românească prezent şi perspective. Sesiunea ştiinţifică naţională cu participare internaţională, Ed.Univ. Suceava, ISBN 973-666-035-4, 2003, pag.566-577.

[MOHV93]. N.Morariu, Şt.Holban, R.Vancea, ş.a. ”Asistarea activităţii de cercetare într-o bancă de gene”, faza “Realizare prototip”, temă de cercetare realizată în cadrul contractului nr.101/05.04.1993 între Societatea de Servicii Informatice Suceava S.A. şi Ministerul Cercetării şi Tehnologiei, 1993-1995.

[MONI95]. N. Morariu ş.a., ”Integrarea registrelor permanente. Registrul permanent al cadastrului general RCG”- temă de cercetare realizată în cadrul contractului 569/1995 cu Institutul de Cercetări în Informatică, 1995.

[MOHV97]. N.Morariu, Şt.Holban, R.Vancea, Dan Ciubotaru, ş.a. ”Proiectarea şi optimizarea structurilor moleculare destinate realizării medicamentelor”, temă de cercetare realizată în cadrul contractului 459B/1995 între Societatea de Servicii Informatice Suceava S.A. şi Ministerul Cercetării şi Tehnologiei, 1995-1997.

[MONI97]. N.Morariu, ş.a., ”Realizarea de instrumente informatice privind prevenirea evaziunii fiscale pentru deţinerea de terenuri şi valori imobiliare”, temă de cercetare realizată în baza contractului 125/1996 cu Ministerul Cercetării şi Tehnologiei în cadrul programului naţional de cercetare “ORIZONT 2000”, 1996-1997.

[MONI00]. N.Morariu, ş.a., ”Instrumente şi arhitecturi noi pentru determinarea obligaţiilor fiscale ale deţinătorilor de terenuri şi valori imobiliare utilizând B.D.U.”, temă de cercetare realizată în baza contractului 125/1996, act ad. 126/16.02.1999 cu Ministerul Cercetării şi Tehnologiei în cadrul programului naţional de cercetare “ORIZONT 2000”, 1998-2000.

[MONI98]. N.Morariu, ş.a., ”Cercetări experimentale privind reprezentarea digitală la nivelul judeţului Suceava, a zonelor expuse calamităţilor (inundaţii) ” – temă de cercetare realizată în baza contractului 1246/1996, act ad. 284/1998 cu Ministerul Cercetării şi Tehnologiei în cadrul programului naţional de cercetare “ORIZONT 2000”, 1996- 1998.

[MONI99]. N.Morariu, ş.a., ”Crearea unui sistem informatic geografic” - temă de cercetare realizată în baza contractului 125/1996, act adiţional 126/16.02.1999/I cu Ministerul Cercetării şi Tehnologiei în cadrul programului naţional de cercetare “ORIZONT 2000”, 1996-1999.

[MONI01]. N.Morariu, ş.a., “Cercetări privind asistarea şi evaluarea activităţilor de prevenire, protecţie şi reabilitare a Zonei inundabile a bazinului Prut utilizând tehnologii informatice” – temă de cercetare realizată în colaborare cu Universitatea Tehnică a Moldovei, în baza contractului 595/29.08.2000, act adiţional 1/16.03.2001

83

cu Ministerul Educaţiei şi Cercetării în cadrul programului naţional de cercetare “ORIZONT 2000”, 2000-2001.

[MONC01] N.Morariu, ş.a., “Cercetări privind utilizarea tehnologiei GIS în realizarea cadastrului general şi a cadastrelor de specialitate în România şi Republica Moldova” temă de cercetare realizată în colaborare cu Universitatea Tehnică a Moldovei, în cadrul contractului 616/9.10.2000, act adiţional 1/3.08.2001 cu Ministerul Educaţiei şi Cercetării, 2000-2001.

[MOLH03] lector univ. Nicolae Morariu, lector univ. Valeriu Lupu, ing.ec. Ovidiu Hurjui, Baze de date, ISBN 973-8293-83-9, Editura Universităţii “Ştefan cel Mare” Suceava,117 p, Suceava, 2003.

[MOLU02]. Nicolae Morariu,Valeriu Lupu, ”The computer assisted of the manufacture times for machine tools with numerical command”, Proceedings 3 rd International Conference on Microelectronics and Computer Science – Tehnical University of Moldova, september 26-28 2002, Chişinău, Vol. II, pag.99-104.

[MONI02]. Nicolae Morariu, “Înmagazinarea datelor. Tehnologiile OLAP şi DM în susţinerea procesului decizional din cadrul unei organizaţii”, Sesiunea ştiinţifică naţională cu participare internaţională “Economia românească prezent şi perspective”, Univ. “Ştefan cel Mare” Suceava, iunie 2002, pag.580-585.

[MOOV03]. Nicolae Morariu, Dumitru Ostafe, Sorin Vlad , “Consideraţii privind utilizarea unor instrumente ale inteligenţei artificiale în cercetarea aplicativă”, “Economia românească prezent şi perspective”, Sesiunea ştiinţifică naţională cu participare internaţională, Ed.Univ. Suceava, ISBN 973-666-035-4, 2003, pag.615-622.

[MOPE96]. N.Morariu, Şt.Gh.Pentiuc, ş.a., “Sistem de diagnosticare automată a proceselor prin tehnici de recunoaşterea formelor”, temă de cercetare realizată în cadrul contractului 126/21.02.1996 între Societatea de Servicii Informatice Suceava S.A. şi Ministerul Cercetării şi Tehnologiei, în cadrul programului naţional de cercetare “ORIZONT 2000”, 1996.

[MOPE01].Şt.Gh.Pentiuc, Nicolae Morariu, ş.a., Intelligent System for Prognosis and Estimation of Economic Decisions at Districtual Level, Advances in Electrical and Computer Engineering, Faculty of Electrical Engineering “Stefan cel Mare” University of Suceava, vol.1(8), nb.1(15), 2001, pp. 44-47.

[MOPE02] B.Tanasiciuc, N.Morariu, Şt.Gh.Pentiuc, ş.a., “Sistem expert destinat monitorizării impactului măsurilor economice asupra zonelor defavorizate - referinţă Judeţul Suceava”, faza “Realizarea şi testarea unui sistem experimental”, temă de cercetare realizată în cadrul contractului nr.158/1999 între Societatea de Servicii Informatice Suceava S.A. şi Ministerul Educaţiei şi Cercetării, 2002.

[MOPO97]. mat.Nicolae Morariu, prof.dr.ing.Nicolae Popovici, ing.Radu Ungureanu, ing.Ion Sainiuc, ing.Traian Teodorescu, fiz.Cătălin Zamfirescu; ”Sistem informaţional geografic (SIG) pentru monitorizarea zonelor expuse inundaţiilor”, Produse software pentru reprezentarea digitală şi monitorizare, Revista Hidrotehnica vol. 42 Nr. 10-12 1997, pag. 43-46.

[MOPO98]. N. Morariu, N. Popovici, R. Ungureanu, T. Teodorescu, I. Sainiuc, C. Zamfirescu; ”Sistem de reprezentare digitală a zonelor expuse inundaţiilor”, Simpozion ştiinţific jubiliar “65 ani ai Universităţii Agrare de Stat din Moldova”, vol. 2, 7-9 octombrie 1998 Chişinău, pag. 186-188.

[MOPO99]. Nicolae Morariu, Nicolae Popovici, Radu Ungureanu, Ion Sainiuc, Traian Teodorescu, Cătălin Zamfirescu; “Reprezentarea digitală la nivelul judeţului Suceava a zonelor expuse calamităţilor (inundaţii), Analele ştiinţifice ale Universităţii ”Alexandru Ioan Cuza” Iaşi, Tom XLIV-XLV, 1998-1999, pag. 73-82.

[MOPS02]. Nicolae Morariu,Şt.Gh.Pentiuc,Gh.Sandu,B.Tanasiciuc ş.a., “Sistem expert destinat monitorizării impactului măsurilor economice asupra zonelor defavorizate –

84

referinţă Judeţul Suceava”, Sesiunea ştiinţifică naţională cu participare internaţională “Economia românească prezent şi perspective”, Univ. “Ştefan cel Mare” Suceava, iunie 2002, pag.586-598.

[MORA01]. Ungureanu Radu, Morariu Nicolae, ş.a., “Cercetări privind utilizarea tehnologiei GIS în realizarea cadastrului general şi a cadastrelor de specialitate în România şi Republica Moldova”, faza “Cercetări privind achiziţia prelucrarea şi conversia datelor cadastrale obţinute din măsurători în teren”, temă de cercetare realizată în colaborare cu Universitatea Tehnică a Moldovei în cadrul contractului nr.616/2000 între Societatea de Servicii Informatice Suceava S.A. şi Ministerul Educaţiei şi Cercetării, 2001.

[MOR103]. Nicolae Morariu, “Aspecte privind distribuirea datelor în cadrul unui sistem informatic pentru integrarea registrelor permanente”, Tehnologii informaţionale, Editura Universităţii Suceava, ISBN 973-666-059-1, 2003 , pag.60-69.

[MOR203]. Nicolae Morariu, “Aspecte privind utilizarea de instrumente şi arhitecturi noi pentru determinarea şi urmărirea obligaţiilor fiscale ale deţinătorilor de bunuri imobile”, “Economia românească prezent şi perspective”, Sesiunea ştiinţifică naţională cu participare internaţională, Ed.Univ. Suceava, ISBN 973-666-035-4, 2003, pag. 545-552.

[MOR303]. Nicolae Morariu, “Integrarea tehnologiei bazelor de date cu tehnologia sistemelor inteligente”, Economia românească prezent şi perspective. Sesiunea ştiinţifică naţională cu participare internaţională, Ed.Universităţii Suceava, ISBN 973-666-035-4, 2003, pag.553-565.

[MOR403]. Nicolae Morariu, “Utilizarea tehnicilor de clasificare şi recunoaşterea formelor pentru diagnosticarea evoluţiei unor indicatori sintetici la nivel regional”, Sesiunea ştiinţifică naţională ”Teorie şi practică în dezvoltarea regională”, Societatea Română de Statistică, Suceava, 2003.

[MOR104]. Nicolae Morariu, “Utilizarea unor instrumente ale inteligenţei artificiale pentru diagnosticare şi predicţie în economie”, Simpozionul Internaţional al Tinerilor Cercetători Ediţia II - a, Academia de Studii Economice din Moldova, 29 – 30 aprilie 2004, Departamentul Editorial-Poligrafic al A.S.E.M. Chişinău, ISBN 9975-75-239-x, Vol.I pag.14-16.

[MOR204]. Nicolae Morariu, “REFORME – A software product for pattern clasification and recognition by joint use of pattern recognition techniques and multi-layer perceptron”, “The Proceedings of the Central and East European Conference in Business Information Systems”, Cluj-Napoca, may 2004, Ed. Risoprint, ISBN 973-656-648-X, pag.100-105.

[MOR304]. Nicolae Morariu, “Artificial Inteligence Techniques in an Evaluation and Decision System for Economic Activity”, SACI 2004, Budapest Polytechnic Nepszinhaz, Budapest, Hungary, Timişoara, 2004.

[MOR404]. Nicolae Morariu, Sorin Vlad, ”Online documentation and assisted research knowledge based system for vegetal genetics resources”, Proceedings of the Forth International Conference ”Internet Education Science IES-2004”, Baku State University Azerbaijan,Vinnytsia National Technical University Ukraine, St. Cyril and St. Methodius University of Veliko Turnovo Bulgaria, oct. 2004 Vinnytsia Ukraine, ISBN 966-641-104-0, Tom 2, pag. 513-516.

[MOTI01]. mat.drd.Nicolae Morariu, dr.ing.Doru Eugen Tiliuţe, asist.univ.Sorin Vlad, “Model de definire a unei structuri evolutive de date de tip universal”, A II-a Conferinţă internaţională ştiinţifico-practică de informatică şi economie INFECO2, Colegiul Financiar-Bancar “A. Diordiţă” Chişinău, octombrie 2001, pag. 45-51.

[MOVV03]. lector univ.drd.Nicolae Morariu, asist.univ. Sorin Vlad, lector univ.drd. Romulus Vancea, “Sistem bazat pe cunoştinţe în genetica vegetală”, “Economia

85

românească prezent şi perspective”, Sesiunea ştiinţifică naţională cu participare internaţională Ed.Univ. Suceava, ISBN 973-666-035-4, 2003, pag.604-612.

[NISR97]. Data mining, o nouã erã în informaticã Ştefan I.Nitchi şi Rodica Avram- Nitchi, http:www.byte.ro/byte97-02/18tend.html.

[OLAP01]. The OLAP Report sept.2001, What is OLAP ?http.www.olapreport.com/fasmi.htm

[ORA92]. Introduction to ORACLE SQL, SQL* Plus and PL/SQL Course Notes, Glenn Maslen, Published by Oracle Corporation UK Ltd. 1992.

[ORA99]. Oracle Corporation - Analytic Functions for Oracle8i, White Paper, Oct.1999.

[PASC94]. Totul despre SQL Interogarea bazelor de date, Corina Pascu, Adrian Pascu, Ed. Tehnică Buc. 1994.

[PARC02]. Christine Parent, SGBD deductifs, Ecole Polytechnique Federale de Lausanne, http//lbdwww.epfl.ch/f/teaching/courses/

[PIGB90]. Pigford D. V., Baur G., Expert Systems for Business. Concepts and Applications. Featuring VP-Expert, Boyd & Fraser Pub, Boston, 1990.

[PEDU95]. Elemente de teoria şi proiectarea bazelor de date. Note de curs, Stefan Gh. Pentiuc, Jean Michel Duthilleul, Univ. “Ştefan cel Mare” Suceava 1995.

[PENT94]. Pentiuc, Şt. Gh. – An Algorithm for the Generation of Symbolic Classifiers for Pattern Recognition Systems. Analele Universităţii "Ştefan cel Mare" Suceava, nr.1, 1994.

[PENT97]. Ştefan-Gheorghe Pentiuc, Aplicaţii ale recunoaşterii formelor în diagnosticul automat, 158 p. ISBN 973-31-1096-5, Editura Tehnică, Bucureşti, 1997.

[PENT98]. Pentiuc, Şt. Gh. – Sisteme expert. Note de curs, Facultatea de Inginerie Electrică, specializarea Calculatoare, Facultatea de Inginerie Mecanică, specializarea Mecatronică, Universitatea "Ştefan cel Mare" Suceava, 1994- 1998.

[PENT00]. Şt. Gh. PENTIUC, Generatoare de sisteme expert - Editura Hipparion, Cluj-Napoca, 2000, ISBN 973-9448-48-8, 112 pagini.

[ROEU96]. Eugen Rotariu – Limbajul Java, 1996.[RUBK82]. Rusu A, Boş N., Kiss A., Topografie-Geodezie EDP Bucureşti, 1982. [SAM96]. Mircea Sârbu, Analiza multidimensională.

http:www.byte.ro/byte96-03/datawar4.html[SEKH94]. Khoshafian Setrag “Object Oriented Databasses”, pub. John Whiley

1994, UK.[SIMA98]. Dicţionar modern de informatică, “Sisteme multiagenţi”, Universitatea

“Politehnica Bucureşti”, www.cs.pub.ro/~dict/sisteme_multiagenti/ sisteme_multiagenti.html[SPAS02]. Prof. Stefano Spaccapretra, Bases de Donnees Avancees - SGBD

deductifs, Ecole Polytechnique Federale de Lausanne,http//lbd.epfl.ch/f/teaching/courses/poly3/index.html

[SV1998]. Prefectura Judeţului Suceava – Carta verde a judeţului Suceava, vol. 1-III, 1998.

[SV2001]. Prefectura Judeţului Suceava – Judeţul Suceava. Programul de dezvoltare economică şi socială pe anul 2001, 2001.

[SV2003] Statistică Teritorială, Institutul Naţional de Statistică, Ediţia 2003.[TACU98]. Alecsandru Puiu Tacu, Romul Vancea, Ştefan Holban, Aurel Burciu,

Inteligenţa Artificială. Teorie şi aplicaţii în economie., Editura Economică, Bucureşti, 1998.[TEHN02]. prof. dr. ing. H. N .Teodorescu – Curs de Reţele Neuronale, Universitatea

„Gh. Asachi“, Iaşi.[THK95]. Kurt Thearling, From Data Mining to Data Base Marketing, White Paper,

95/02, October 1995, Data Inteligent Group Pilot Software.

86

http://www.santafe.edu/~kurt/wp9502.html [ULMM90]. Jeffrey D. Ullman, Deductive Databases: Achievements and Future

Directions, Stanford University, Stanford, California, 1990.www.cs.ucla.edu/~zaniolo/papers/

[VAHO89]. Romul Vancea, Ştefan Holban, Dan Ciubotariu, Recunoaşterea Formelor Aplicaţii, Ed. Academiei R.S.R. 1989.

[VAHO95].R.Vancea, Şt. Holban, V.Vajnovzki, F. Iancu, Considerations sur le systemes experts avec controle flou. Inteligence Artificielle, Universite de Bourgogne, mars 1995, pp.1-23 Dijon France.

[ZACS03]. Marian Zaharia, Claudia Cârstea, Liana Sălăgean, Inteligenţa artificială şi sistemele expert în asistarea deciziilor economice, ISBN 973-590-870-0, Ed. Economică, Bucureşti, 2003.

[ZANI90]. Carlo Zaniolo, Deductive Databases – Theory Meets Practice, 3500 West Balcones Center Drive, Austin, Texas, USA, 1990, www.cs.ucla.edu/~zaniolo/papers/

[ZEMK99]. Zemke, F., Kulkarni, K., Witkowski, A., Lyle, B. - Introduction to OLAP functions, ISO/IEC JTC1/SC32 WG3:YGJ, ANSI NCITS H2-99-154, Apr. 1999 .

87