Arhitectura Sistemelor DE Gestiune A Bazelor DE Date

CUPRINS

CAPITOLUL I

SISTEME DE GESTIUNE A BAZELOR DE DATE (SGBD) 2

Obiectivele unui SGBD 2

Arhitectura SGBD-urilor 5

Evoluția SGBD-urilor 11

CAPITOLUL II

ARHITECTURA ȘI FUNCȚIUNILE MAȘINILOR BAZE DE DATE 17

Mașini baze de date 17

Arhitectura mașinilor baze de date 19

CAPITOLUL III

MODELUL RELAȚIONAL 21

3.1 Scurtă descriere a modelului relațional 21

3.2 Caracteristicile modelului relațional 22

3.3 Operatorii modelului relațional 22

CAPITOLUL IV

BAZE DE DATE DISTRIBUITE 24

Definiție, obiective și caracteristici generale 24

Arhitectura unui SGBDD 27

Gestiunea datelor distribuite 35

CAPITOLUL V

BAZE DE DATE ORIENTATE OBIECT 40

Caracteristicile fundamentale ale unui SGBDO 41

Arhitectura unui SGBDO 44

CAPITOLUL VI

BAZE DE DATE DEDUCTIVE 50

Caracteristicile bazelor de date inteligente 51

Arhitectura SGBDI 53

CAPITOLUL VII

APLICAȚIA PRACTICĂ. 55

BIBLIOGRAFIE SELECTIVĂ 61

CAPITOLUL I

SISTEMELE DE GESTIUNE A BAZELOR DE DATE (SGBD)

O bază de date apare ca o colecție de date stocate pe memoria externă adresabile, folosite de o multitudine de utilizatori. Însă o bază de date care nu are asociat un sistem de gestiune al acesteia, nu are sens, ea nu iși atinge obiectivele pentru care a fost creată.

Sistemul de gestiune al bazei de date reprezintă software-ul propriu-zis al acesteia care asigură realizarea următoarelor activități:

definirea structurii bazei de date;

încărcarea datelor in baza de date;

accesul la date (interogare, actualizare);

întreținerea bazei de date (colectarea și refolosirea spațiilor goale, refacerea bazei de date în cazul unui incident);

reorganizarea bazei de date (restructurea și modificarea strategiei de acces);

securitatea datelor.

Așadar, sistemul de gestiune al bazei de date apare ca un sistem complex de programe care asigură interfața între o bază de date și utilizatorii acestora.

În sens mai larg, sistemul de gestiune al bazelor de date este o componentă activă a băncilor de date, ce interacționează cu toate celelalte componente, cu toate categoriile de personal implicat în funcționarea băncii de date.

1.1. Obiectivele unui SGBD

După cum este cunoscut, obiectivul informaticii îl constituie culegerea, verificarea, transmiterea, stocarea si prelucrarea automată a datelor cu ajutorul mijloacelor electronice de calcul, în scopul satisfacerii diferitelor nivele de conducere cu informații necesare luării deciziilor, în condiții de eficiență economică sporită.

În aceste condiții, necesitatea acută de informare trebuie satisfăcută ținând seama de o serie de cerințe prin care să se asigure: minimizarea costului procesului de prelucrare a datelor; creșterea vitezei de răspuns la întrebările solicitate de utilizator; adaptarea facilă a sistemului informatic la evoluția în timp a sistemului informațional din care face parte; posibilitatea răspunsului la anumite întrebări neanticipate de către proiectanții de sisteme; posibilitatea folosirii sistemului de informare dispunând de un minim de cunoștințe despre modul de organizare a lui în general și informatică în special; integritatea și securitatea datelor etc.

În acest context, sistemului de gestiune a bazei de date îi revin o serie de obiective, cum sunt:

1. Asigurarea independenței datelor. O aplicație, în general, este dependentă de date în sensul că modificarea structurii de memorare a datelor sau a strategiei de acces la date afectează și aplicația.

Independența datelor față de aplicație este totuși necesară cel puțin din următoarele considerente: diferite aplicații au nevoie de viziuni diferite ale acelorași date; administratorul bazei de date trebuie să aibă libertatea de a schimba structura de memorare sau strategia de acces, ca răspuns la cerințe (schimbări de standarde, prioritățile aplicațiilor, unitățile de memorare etc.), fără a modifica aplicațiile existente; baza de date existentă; precum și programele de exploatare a ei, care au fost folosite o perioadă de timp, reprezintă o investiție majoră la care nu trebuie să se renunțe prea usor.

De aceea, se impune ca atunci când apar noi cerințe în cadrul sistemului informațional, sistemele informatice să poată funcționa cu programele și procedurile existente, iar datele existente să poată fi convertite. Deci, modificările care se fac la nivel de structură de date nu trebuie să modifice programele de aplicație.

Independența datelor trebuie privită din două puncte de vedere: independența fizică; independența logică a datelor.

Independența fizică a datelor face ca memorarea datelor și tehnicile fizice de memorare să poată fi modificate fără a determina rescrierea programelor de aplicație.

Independența logică a datelor se referă la posibilitatea adăugării de noi articole de date sau extinderea structurii conceptuale (globale), fără ca aceasta să impună rescrierea programelor existente.

2. Asigurarea unei redundanțe minime si controlate a datelor din baza de date. Spre deosebire de sistemele clasice de prelucrare automată a datelor, stocarea datelor în cazul bazelor de date se face asfel încât fiecare dată să apară o singură dată. Totuși, nu sunt excluse nici cazurile în care, pentru a realiza performanțe sporite, referitoare la timpul de acces la date și răspuns la solicitările utilizatorilor, să se accepte o anumită redundanță a datelor, însă în acest caz se va institui un control automat asupra ei în vederea asigurării coerenței datelor din baza.

3. Asigurarea unor facilități sporite de utilizare a datelor. Aceasta presupune:

folosirea datelor de către mai mulți utilizatori în diferite scopuri (aplicații);

accesul cât mai simplu al utilizatorilor la date, fără ca aceștia să fie nevoiți să cunoască structura întregii baze de date, acest lucru rămânând în sarcina administratorului bazei de date;

existența unor limbaje performante de regăsire a datelor; care permit exprimarea sub forma unei conversații, a unor criterii de selecție a datelor și indicarea unor reguli cât mai generale pentru evitarea informațiilor solicitate;

spre deosebire de sistemul clasic de prelucrare pe fișiere, unde există un singur criteriu de adresare (cel care a stat la baza organizarii fișierului) în cazul bazelor de date, sistemul de gestiune trebuie să ofere posibilitatea unui acces multicriterial, fără sortări suplimentare, în timp ce modificarea criteriului la fișierele clasice implică reorganizarea lor;

utilizarea unui limbaj cât mai apropiat de limbajul natural, cu posibilitatea exploatării bazei de date în regim conversațional. Aceasta ar oferi posibilitatea exploatării în mod facil a bazei de date și de către utilizatorii neinformaticieni.

4. Sporirea gradului de securitate a datelor împotriva accesului neautorizat la ele. În condițiile bazelor de date, administratorul bazei de date poate prevedea ca accesul la bază de date să se facă numai prin canale corespunzătoare, și poate, totodată, defini, verificări de autorizare realizate oricând se încearcă accesul la anumite date.

5. Asigurarea integrității datelor împotriva unor ștergeri intenționate sau neintenționate, prin intermediul unor proceduri de validare, a unor protocoale de control concurent și a unor proceduri de refacere a bazei de date după incident.

6. Asigurarea partajabilității datelor. Partajabilitatea datelor trebuie înțeleasă nu numai sub aspectul asigurării accesului mai multor utilizatori la aceleași date, ci și acela al posibilității dezvoltării unor aplicații fără a se modifica structura bazei de date.

1.2. Arhitectura SGBD-urilor

Pentru a simplifica fuziunea utilizatorilor SGBD trebuie să asigurăm abstractizarea datelor stocate pe diferite suporturi. Grupul ANSI / X3 / SPARC a considerat pentru descrierea datelor o arhitectură pe trei nivele (conceptual, intern, extern).

Nivelul central este nivelul conceptual. Acesta corespunde structurii canonice a datelor ce caracterizează procesul de modelat, adică structura semantică a datelor fără implementarea pe calculator. Schema conceptuală permite definirea tipurilor de date care caracterizează proprietățile elementare ale entităților, definirea tipurilor de date compuse care permit regruparea atributelor pentru a descrie entitățile modelului și legături între aceste entități, definirea regulilor care trebuie să le respecte datele etc.

Nivelul intern corespunde structurii interne de stocare a datelor. Schema internă permite descrierea datelor unei baze sub forma în care sunt stocate în memoria calculatorului. Sunt definite fișierele care conțin aceste date, articolele din fișiere, drumurile de acces la aceste articole.

La nivelul conceptual sau intern, schemele descriu o bază de date. La nivel extern schemele descriu doar o parte din date care prezintă interes pentru un utilizator sau un grup de utilizatori. Schema externă reprezintă o descriere a unei părți a bazei de date ce corespunde viziunii unui program sau utilizator. Modelul extern folosit este dependent de limbajul utilizat pentru manipularea bazei de date.

Schema externă permite asigurarea unei securități a datelor. Un grup de lucru va accesa doar datele descrise în schema sa externă, iar restul datelor sunt protejate împotriva accesului neprotejat sau rău intenționat. Pentru o bază de date particulară există o singură schemă internă, o singură schemă conceptuală, dar există mai multe scheme externe.

Vom analiza arhitectura funcțională de referință propusă de grupul de lucru ANSI / X3 / SPARC. Ea este axată pe dicționarul datelor și cuprinde două părți: o parte ce permite descrierea datelor, deci compoziția dicționarului datelor și o parte ce permite manipularea datelor, deci interogarea și reactualizarea bazei. În fiecare parte se regăsesc cele trei nivele: intern, conceptual și extern. Aceste trei nivele nu sunt neapărat distincte pentru orice SGBD.

Interfețele numerotate din figura 1.1 corespund la următoarele transformări:

Limbaj. de descriere a datelor conceptuale, format sursă – acest limbaj permite administratorului întreprinderii să definească schema conceptuală, format sursă.

Limbaj de descriere a datelor conceptuale, format obiect – acest limbaj se obține din compilarea celui precedent și permite aranjarea schemei obiect în dicționarul datelor

Descrierea datelor conceptuale, format editare – această interfață pemite administratorilor aplicațiilor și a bazelor să consulte schema conceptuală pentru a defini reguli de corespondență.

Limbaje de descriere a datelor externe, format sursă – aceste limbaje permit administratorilor aplicațiilor să defineasca scheme externe și date corespunzând schemei conceptuale. Deoarece sistemele de gestiune pot suporta mai multe modele externe, pot exista mai multe limbaje de descriere a datelor externe.

Limbaje de descriere a datelor externe, format obiect – aceste limbaje corespund formelor compilate ale celor precedente și permit aranjarea schemelor externe (obiect) în dicționarul datelor.

Limbaje de descriere a datelor interne, format sursă – acest limbaj permite administratorului bazei de date să definescă schema internă și regulile de corespondență cu schema conceptuală.

Limbaj de descriere a datelor interne, format obiect – acest limbaj corespunde formei compilate a celui precedent și permite aranjarea schemei interne (obiect) în dicționarul datelor.

Limbaj de manipulare a datelor externe, format sursă – aceste limbaje permit programatorilor de aplicație sau utilizatorilor neinformaticieni să manipuleze date externe (VIEW).

Limbaje de maipulare a datelor externe, format obiect – aceste limbaje corespund formelor compilate ale celor precedente.

Limbaj de manipulare a datelor conceptuale, format obiect – acest limbaj unic este produs de proceorul de transformare extern / conceptual pentru a manipula datele externe.

Limbaj de manipulare a datelor interne, format obiect – acest limbaj unic este produs de procesorul de transformare conceptual / intern pentru a manipula datele interne.

Limbaj de stocare a datelorma internă și regulile de corespondență cu schema conceptuală.

Limbaj de descriere a datelor interne, format obiect – acest limbaj corespunde formei compilate a celui precedent și permite aranjarea schemei interne (obiect) în dicționarul datelor.

Limbaj de manipulare a datelor externe, format sursă – aceste limbaje permit programatorilor de aplicație sau utilizatorilor neinformaticieni să manipuleze date externe (VIEW).

Limbaje de maipulare a datelor externe, format obiect – aceste limbaje corespund formelor compilate ale celor precedente.

Limbaj de manipulare a datelor conceptuale, format obiect – acest limbaj unic este produs de proceorul de transformare extern / conceptual pentru a manipula datele externe.

Limbaj de manipulare a datelor interne, format obiect – acest limbaj unic este produs de procesorul de transformare conceptual / intern pentru a manipula datele interne.

Limbaj de stocare a datelor, format obiect – acest limbaj corespunde interfeței cu sistemul de stocare a datelor.

memorii secundare

Figura 1.1 – Arhitectura de referință a unui SGBD

Interfața cu memoria secundară – această interfață permite efectuarea de intrări în unitatea de memorie secundară sau de ieșiri din unitatea de memorie secundară.

Interfața de acces la dicționarul datelor – această interfață permite diverșilor procesori de transformare să acceseze scheme obiect și reguli de corespondență.

Procesorii din figura 1.1 au următoarele funcții:

Procesorul schemei conceptuale compilează schema conceptuală și dacă nu sunt erori depune schema compilată în dicțioanrul datelor.

Procesorul de transformare extern/conceptual transformă manipulările externe în manipulări conceptuale și invers, datele conceptuale în date externe.

Procesorul schemei externe compilează schemele externe și regulile de corespondență externă și dacă nu sunt erori aranjează schema compilată și regulile de corespondență în dicționarul datelor.

Procesorul schemei interne are un rol similar pentru schema internă.

Procesorul de transformare conceptual/intern transformă manipularile conceptuale în manipulări interne și invers, datele interne în date conceptuale.

Procesorul de transformare intern/stocare transformă manipulările interne în primitive ale sistemului de stocare și invers, eliberează datele stocate într-un format corespunzător schemei interne.

Gardarin a propus o arhitectură funcțională apropiată de arhitectura sistemelor de gestiune actuale care are la bază doar două nivele: schema și vizualizările (figura 1.2). Schema corespunde integrării schemelor interne și conceptuale, iar vizualizarea este o schemă externă.

SGBD gestionează un dicționar de date care este alimentat prin comenzi de definire a schemei (de exemplu, CREATE ENTITY, CREATE INDEX) și prin comenzi de definire a vizualizărilor (de exemplu, CREATE VIEW). Aceste comenzi, precum și cererile de manipulare (de exemplu, APPEND, DELETE, MODIEY) sunt analizate și tratate de un procesor numit analizor.

Analizorul face analiza sintactică și semantică a cererii și o traduce în format intern. O cerere în format intern care face referință la o vizualizare este tradusă în una sau mai multe cereri care fac referință la obiecte ce există în baza de date (modificarea cererilor).

Figura 1.2

Există un procesor, numit translator, care realizează modificarea cererilor, asigură controlul drepturilor de acces și controlul integrității în cazul reactualizărilor. Controlul integrității constă în a verifica ca regulile de coerență sunt respectate și după reactualizare.

Componența cheie a sistemului de gestiune este procesorul optimizor care elaborează un plan de acces optim pentru a trata cererea. Acest procesor descompune cererea în operații de acces elementare și alege o ordine de execuție optimală. De asemenea, evaluează costul planului de acces înaintea execuției sale. Planul de acces ales și elaborat de optimizer este executat de un procesor numit executor. La acest nivel este gestionat controlul concurenței.

Tehnicile utilizate depind de arhitectura operațională a sistemului de gestiune. Arhitecturile operaționale care s-au impus după apariția sistemelor distribuite sunt arhitecturile client-server și arhitecturile federale.

Arhitectura client-server include nucleul unui sistem de gestiune numit DMCS (Description Manipulation and Control Sub-system) care funcționează în regim server. În figura 1.3 este reprezentată o arhitectură client-server. Limbajul DL (Data Language) este limbajul standard de acces la SGBD, iar SO reprezintă un server de obiecte.

CLIENT

Utilitare pentru gestiunea datelor

DL

SERVER

Figura 1.3

Există diferite variante de arhitecturi client-server după cum fiecare utilizator are un server asociat (server mono-sarcină) sau mai mulți utilizatori partajează în paralel același server (server multi-sarcină). Arhitecturile client-server permit ca mai multe stații să partajeze aceleași date. Procesul client gestionează aplicațiile utilizatorului care emit cereri server-ului. Un client poate oferi mai multe servere (arhitectura client-multiserver). Dezavantajul acestei arhitecturi este că centralizează gestiunea datelor la nivelul server-ului.

Arhitectura federală (figura 1.4) adaugă unei arhitecturi client-server un SGBD care se găsește în stația client. Datele dintr-un server pot fi scoase pentru a fi tratate pe stația client, iar după tratament vor fi retrimise de unde au fost luate.

CLIENT

Utilitare pentru gestiunea datelor SERVER

BD personală

SERVER SERVER

BD partajată BD personală

Figura 1.4

1.3 Evoluția SGBD-urilor

Un SGBD este un sistem de programare de bază dintr-un sistem informatic de gestiune care intuitiv permite utilizatorilor concurenți să manipuleze (insereze,modifice, caute) eficient datele conținute în baza de date. Istoria SGBD poate fi rezumată în trei generații:

modele ierarhice și retea;

modele relaționale;

sisteme avansate: SGBD orientate obiect, SGBD deductive, SGBD distribuite.

Pentru modele ierarhice și rețea, datele sunt reprezentate la nivel de articol prin legături ierarhice (arbore) sau de tip graf. Slaba independență fizică a datelor complică administrarea și manipularea acestora. Limbajul de manipulare a datelor impune programatorului să specifice drumurile de acces la date.

A doua generație de SGBD este legată de apariția modelelor relaționale (1970), care tratează entitățile ca niște relații. Piața actuală de baze de date este acoperită în majoritate de sisteme relaționale. Acestea, ca și modelele de primă generație, au fost concepute pentru aplicații clasice: contabilitate, gestiunea stocurilor etc.

Bazele de date relaționale sunt caracterizate de structuri de date simple, intuitive, inexistența pointerilor vizibili pentru utilizator, constrângeri de integritate, o mulțime de operatori aplicați relațiilor care permit definirea, căutarea și reactualizarea datelor.

Bazele de date relaționale oferă avantaje precum:

independența completă în descrierea logică a datelor (în termen de relații) și în descrierea fizică a datelor (în termen de fișiere);

un ansamblu integrat de utilitare bazat pe un limbaj de generația a 4-a, și anume generatoare de meniuri, generatoare de aplicații, generatoare de forme, generatoare de etichete;

existența unor limbaje speciale de definire și manipulare a datelor.

Dintre sistemele de gestiune relaționale reprezentative amintim: DB2, SQL/DS, INGRES, SABRINA, ORACLE, INFORMIX, UNIFY, TIS, RAPPORT.

Bazele de date relaționale nu folosesc însa obiecte complexe și dinamice, nu realizează gestiunea datelor distribuite și nici gestiunea cunoștințelor. A treia generație de SGBD ce cuprinde sistemele avansate încearcă să depășească aceste limite ale sistemului relațional.

a) Gestiunea obiectelor complexe (baze de date orientate obiect).

Suportul obiectelor complexe și dinamice și manipularea lor este dificilă pentru sistemele relaționale, deoarece tipul datelor este limitat la câteva domenii alfanumerice, iar structura datelor este simplă. Sistemele relaționale nu modelează obiecte complexe ca grafuri, liste etc.

Un obiect complex poate să fie descompus în relații, dar apar dificultăți și la descompunere și la refacerea lui prin compunere (join). De asemenea, limbajele modelului relațional permit manipularea cu dificultate a obiectelor complexe.

O aplicație are un aspect static (reprezentat prin date) și un aspect dinamic (reprezentat prin tratamentul acestor date). Obiectele manipulate de sistemele relaționale sunt în general statice, iar comportamentul lor (dinamica lor) este dat separat prin programele de aplicație care le manipulează

Un sistem relațional nu suportă obiecte dinamice care încorporează atât partea de date (informații) efectiv cât și o parte relativ la tratamentul lor.

În programarea orientată pe obiect, efortul constă în definirea obiectelor. Obiectele de același tip formează o clasă care este generalizarea noțiunii de tip de date definit de utilizator. Clasa include, pe langă date, și metodele de acces la ele. Datele sunt vizibile doar metodelor asociate clasei respective. Acesta este așa numitul principiu al încapsulării datelor.prin funcții numite constructori și destructori, programatorul deține controlul asupra operațiilor necesare la crearea, respectiv dispariția unui anumit obiect. Un alt concept fundamental este cel al derivării, adică putem defini o clasă care să “moștenească” proprietățile (care constau în date și funcții) uneia sau mai multor clase “părinte”.

Îmbinarea tehnicii limbajelor orientate obiect cu a bazelor de date a permis realizarea bazelor de date orientate obiect. Aceste baze permit organizarea coerentă a obiectelor partajate între utilizatori concurenți.

Sistemele de gestiune orientate obiect prezintă următoarele avantaje:

– realizează o modelare superioară;

– furnizează posibilități superioare de deducție (ierarhie de clase, moștenire);

– permit luarea în considerare a aspectelor dinamice și integrarea descrierii structurale și comportamentale;

– îmbunătățesc interfața cu utilizatorul.

b) Gestiunea cunoștințelor (baze de date deductive)

O relație este o colecție de tupluri ce reprezintă fapte. Cunoștințele sunt aserțiuni generale și abstracte asupra faptelor. De exemplu, “Costică este medic” este un fapt, iar “Toți medicii sunt bogați”este o cunoștință. Cunoștințele permit să raționezi, ceea ce permite deducerea de noi fapte, plecând de la fapte cunoscute (“Costică este bogat”) și obținerea de răspunsuri inteligente (putem răspunde la intrebarea “Cine sunt bogați?”, prin forma “Toți medicii”).

Un SGBD relațional suportă o formă limitată de cunoștințe, și anume constrângerile de integritate, iar restul de cunoștințe trebuie integrate în programele de aplicație. Aceasta generează probleme, fie că trebuie codificate cunoștințele în programe, fie că apare imposibilitatea de a partaja cunoștințe între utilizatori. Totul se complică dacă există un volum mare de fapte.

Bazele de date deductive, utilizând programarea logică, gestionează cunoștințe relativ la baze de date care, în general, sunt relaționale. Bazele de date deductive permit deducerea de noi informații, plecând de la informațiile stocate în bază.

Un SGBD deductiv posedă:

Un limbaj de definire a datelor care permite definirea structurii predicatelor sub formă de relații și constrângeri de integritate asociate.

Un limbaj de manipulare a datelor care permite efectuarea reactualizărilor asupra datelor și formularea unor cereri.

Un limbaj de reguli de deducție care permite ca, plecând cu predicatele definite anterior, să se specifice cum pot fi construite predicate derivate necesare filtrărilor cerute de utilizator. Un exemplu de limbaj de reguli care permite specificarea relațiilor deduse cu ajutorul clauzelor HORN fără simboluri de tip funcție este limbajul DATALOG .

c) Gestiunea datelor distribuite (baze de date distribuite)

Un sistem distribuit este un ansamblu de mașini interconectate printr-o rețea de comunicație și utilizate într-un scop global. Administrarea și manipularea datelor distribuite, situate pe diferite calculatoare și exploatate de sisteme eterogene este obiectivul fundamental al bazelor de date distribuite.

Baza de date distribuită este un sistem de baze de date cooperante care rezidă pe mașini diferite, în locuri diferite. Această mulțime de baze de date este exploatată de utilizator ca și cum ar fi o singură baza de date.

Un sistem paralel este un sistem conceput pentru a exploata capacitățile unui calculator multiprocesor. Implementarea unui SGBD ca un sistem paralel permite exploatarea paralelismului inerent care există în bazele de date.

Modelul relațional a rămas instrumentul prin care se realizează prelucrarea datelor distribuite, deoarece:

Bazele relaționale oferă flexibilitate de descompunere în vederea distribuirii. Tabelele se pot descompune orizontal, vertical și se pot regrupa.

Operatorii relaționali pot fi folosiți pentru combinații dinamice ale informațiilor descentralizate.

Limbajele sistemelor relaționale sunt concise și asigură o economie considerabilă a transmiterii datelor. Ele fac posibil, pentru un nod oarecare al rețelei, să analizeze intenția unei tran-zacții, să o descompună rapid în componenete ce pot fi realizate local și componente ce pot fi transportate altor noduri.

Soluția pentru a descentraliza prelucrarea datelor, în scopul evitării saturării memoriei și a procesoarelor calculatorului central, a fost apariția calculatoarelor baze de date și a mașinilor baze de date. Descentralizarea presupune transferarea unei părți din funcțiile unui SGBD către un calculator periferic (calculator backend) adică deplasarea algoritmilor de căutare și a celor de actualizare a datelor mai aproape de memoria secundară. Acest calculator periferic permite utilizarea optimă a resurselor și realizarea paralelismului în tratarea cererilor de informații. Calculatorul periferic poate fi un calculator clasic, dar cu un software specific de SGBD (calculator bază de date) sau poate fi o mașina cu hardware specializat în gestiunea bazelor de date (mașina bază de date).

În figura 1.5 este prezentată arhitectura funcțională a unei mașini bază de date și a calculatorului central.

Mașinile baze de date sunt înzestrate cu arhitecturi paralele special adaptate pentru gestionarea unui volum mare de date. Tratarea paralelă a cererilor permite reducerea timpului total de execuție a acestora. O execuție în paralel solicită, fie descompunerea unui program în module care pot fi executate în paralel (descompunerea funcțională), fie descompunerea datelor în subgrupe astfel încat toți procesorii să execute același lucru, dar pe date diferite. Performanțele tratării paralele depind de modul în care sunt efectuate descompunerile.

Baze de date distribuite

pe mai multe discuri

utilizatori

calculator gazdă mașina baza de date

Figura 1.5

CAPITOLUL II

ARHITECTURA ȘI FUNCȚIUNILE MAȘINILOR BAZE DE DATE

2.1 Mașini baze de date

Calculatoarele “baze de date” și “mașinile baze de date” au apărut ca soluții de îmbunătățire a lucrului cu bazele de date, de ameliorare a performanțelor sistemelor de gestiune a bazelor de date. Ideea de bază o constituie descentralizarea prelucrării datelor, în scopul evitării saturării memoriei și a procesoarelor calculatorului central. Această descentralizare înseamnă transferarea unei părți importante din funcțiile unui SGBD unui calculator periferic (unui așa numit “calculator backend”), realizându-se astefel deplasarea algoritmilor de căutare și a celor de actalizare a datelor mai aproape de memoria secundară, deci de locul unde sunt memorate datele.

Figura 2.1 Calculatorul backend

Calculatorul backend poate fi un calculator clasic, dar cu un soft specific (de SGBD), caz în care poartă numele de calculator bază de date sau poate fi o mașină cu hard specializat în gestiunea bazelor de date (în efectuarea operațiilor pe o bază de date), situație în care este numit mașina bază de date.

Prin introducerea unui backend se obțin următoarele avantaje în lucrul cu baze de date:

se transferă în memoria calculatorului central numai datele utile, evitându-se astfel saturarea acesteia;

specializarea backend-ului în prelucrări pe baze de date determină performanțe sporite în gestionarea bazelor de date, în raport cu ale unui calculator general (central);

posibilitatea unor tehnologii speciale, de înaltă performanță în realizarea hardului specializat în lucrul cu baze de date;

utilizarea unor tehnici avansate de prelucrare sau acces la date, precum prelucrarea paralelă.

Există mai multe variante de utilizare a calculatoarelor backend, dintre care: utilizarea unui singur calculator bază de date; utilizarea unei mașini bază de date.

Utilizarea unui singur calculator bază de date. În această variantă, se recurge la utilizarea unui singur hard convențional (calculator bază de date) drept calculator backend. Acest hard poate fi, de exemplu, un minicalculator. Softul pentru realizarea funcțiilor de gestiune a bazei de date este plasat pe calculatorul bază de date. Softul de interfață (inclusiv cel de comunicații date) se află plasat atât pe calculatorul central, cât și pe backend. La nivelul calculatorului central, interfața programelor de aplicații cu baza de date apare în același mod ca la lucrul convențional cu baza de date (cu sistemul de gestiune a bazelor de date operând pe calculatorul central). Cu ajutorul softului de interfață, se transmit către calculatorul bază de date toate cererile de lucru pe baza de date.

Utilizarea mai multor calculatoare baze de date. Funcțiile calculatorului central sunt similare celor pe care le are acesta în varianta anterioară. Deosebirea dintre aceste două variante constă în faptul că drept calculator backend figurează mai multe harduri convenționale, atașate la un controler. Această variantă de lucru oferă posibilități de paralelism în prelucrarea datelor și/sau accesul la date. Fiecare calculator bază de date poate dispune de software-ul complet pentru realizarea funcțiilor de gestiune a bazei de date, având însă dreptul să lucreze numai pe anumite partiții ale bazei de date sau poate deține o parte din software-ul de gestiune a bazei de date (specializare în realizarea anumitor funcții), caz în care are dreptul să lucreze pe întreaga baza de date.

Utilizarea unei mașini bază de date. Calculatorul backend este realizat special pentru efectuarea de operații pe bazele de date. Software-ul mașinilor baze de date conține procedurile de control a modului de efectuare a acestor operații.

Este posibil ca o parte din funcțiile de gestiune a bazelor de date (în special de nivel înalt, precum: interfața cu utilizatorul, optimizarea cererilor de date) să fie realizate de calculatorul central, mașinii bază de date fiindu-i transferate, în acest caz, numai operațiile de nivel scăzut (accesul la date).

Fig. 2.2. Utilizarea mai multor calculatoare bază de date

Cel mai adesea, o mașina bază de date realizează în totalitate funcțiile de gestionare a bazelor de date.

Avantajul utilizării mașinilor bază de date rezidă în faptul că în acest caz, nu se manifestă nici un fel de restricții în realizarea unor performanțe sporite de lucru cu baze de date (mașinile bază de date permit utilizarea unor tehnologii mai avansate, a unor arhitecturi mai bine adaptate cerințelor lucrului cu baze de date, în special pentru prelucrările și accesul paralel la date).

2.2 Arhitectura mașinilor bază de date

Figura 2.3 reprezintă arhitectura tipică a unei mașini bază de date. În cadrul acestei arhitecturi, pot fi puse în evidență următoarele componente: gestionarul de comunicații; gestionarul de cereri; gestionarul memoriei asociative.

Comunicarea între calculatorul central și mașina bază de date se realizează cu ajutorul gestionarului de comunicații, care este localizat atât la nivelul mașinii bază de date cât și la nivelul calculatorului central. La nivelul calculatorului central se mai află plasat și gestionarul interfeței care are sarcina de a lua în considerare, de a analiza și de a codifica cererile de lucru cu baza de date.

Calculatorul central Mașina bază de date

gestionarul de gestionarul de

comunicații protocol manipulare date comunicații

Utilizatori(PA)

Fig.2.3. Arhitectura tipică a unei mașini bază de date

Ansamblul de mesaje prin care se realizează dialogul dintre calculatorul central și mașina bază de date poartă numele de protocol de manipulare a datelor.

Gestionarul de cereri reprezintă o componentă importantă a mașinii bază de date, și are rolul de a descompune cererile de lucru cu baza de date (de căutare și de actualizare a datelor), în operații mai simple, pe care apoi, în scopul executării lor, le ordonează într-o secvență convenabilă. Totodată, gestionarul de cereri execută o serie de sortări și/sau calcule aritmetice. Tot gestionarul de cereri este și cel care determină care sunt căile de acces cele mai scurte către date.

Având în vedere funcțiile realizate, gestionarul de cereri poate fi considerat drept optimizatorul de cereri al mașinii baza de date.

CAPITOLUL III

MODELUL RELAȚIONAL

3.1 Scurtă descriere a modelului relațional

Modelul relațional a fost conceput și dezvoltat de Codd. El este un model formal de organizare conceptuală a datelor, destinat reprezentării legăturilor dintre date, bazat pe teoria matematică a relațiilor. Este modelul cel mai accesibil pentru utilizatorul bazei de date deoarece are aceeași structură fizică cu datele care trebuie prelucrate. În general, datele se prezintă sub forma unor tabele (relații) în care liniile constituie entități, iar coloanele sunt atribute ce caracterizează aceste entități.

Spre deosebire de modelul ierarhic și rețea unde apar două elemente, și anume tipul entității și relațiile dintre două entități, modelul relațional este alcătuit numai din relații și prin urmare, orice interogare asupra bazei de date este tot o relație.

Modelul relațional a fost definit cu o deosebită rigoare matematică, furnizând un mijloc performant de studiu al proprietăților logice ale unui sistem de baze de date.

Referitor la partea de manipulare a datelor, modelul relațional este orientat spre mulțimi, în timp ce modelele ierarhic și rețea sunt orientate spre fișiere. Pentru modelele ierarhic și rețea, programatorul trebuie să proiecteze programe care să acceseze baza de date, înregistrare cu înregistrare, utilizând legături fizice între înregistrări. Modelul relațional a permis introducerea unor limbaje neprocedurale de manipulare a datelor.

Modelul relațional nu este orientat spre sistemul de calcul, deci modelul nu include regulile, structurile și operațiile referitoare la implementarea fizică a unui sistem de baze de date. De fapt, unul dintre obiectivele modelului este acela de a face o distincție clară între aspectele fizice și logice ale unei baze de date (independența datelor).

Modelul relațional, deși are unele imperfecțiuni, a fost adoptat în ultimul deceniu de majoritatea programatorilor din domeniu, tocmai datorită acestor trei calități: este simplu, este riguros din punct de vedere matematic și nu este orientat spre sistemul de calcul.

Definirea unui SGBD relațional impune analizarea caracteristicilor pe care trebuie să le prezinte un model de date pentru a fi considerat relațional. Există diferite modalități pentru a defini acest concept:

prezentarea datelor în tabele supuse anumitor operații: proecție, selecție, reuniune, compunere, intersecție etc. (definiție simplă);

un sistem de baze de date ce suportă un limbaj de tip SQL-Structured Query Language (definiție practică);

un sistem de baze de date care respectă principiile modelului relațional introdus de Codd (definiția cea mai frecvent folosită).

Codd a publicat un set de 13 reguli, în raport cu care un SGBD poate fi apreciat ca relațional. Ulterior, cele 13 reguli de fidelitate ale lui Codd au fost extinse la un număr de 100. Trebuie remarcat că nu există un SGBD care respectă toate regulile definite de Codd. De fapt, nu trebuie să apreciem un SGBD ca fiind relațional sau nu, ci măsura în care acesta este relațional, deci numărul regulilor pe care le respectă.

3.2 Caracteristicile modelului relațional

Un model relațional este caracterizat de trei elemente: structura relațională a datelor, operatorii modelului relațional și regulile de integritate care guvernează folosirea cheilor în model. Aceste trei elemente corespund celor trei componente ale ingineriei software: informație, proces, integritate.

3.3 Operatorii modelului relațional

Operatorii modelului relațional definesc operațiile care se pot efectua asupra relațiilor, în scopul realizării funcțiilor de prelucrare asupra bazei de date.

Modelul relațional oferă două mulțimi de operatori pe relații, și anume: algebra relațională și calculul relațional. La rândul său, calculul relațional este de două tipuri: orientat pe tupluri sau orientat pe domenii.

Operatorii algebrei relaționale sunt fie operatori tradiționali pe mulțimi (UNION, INTERSECT, PRODUCT,DIFFERENCE), fie operatori relaționali speciali (PROJECT, SELECT, JOIN, DIVISION).

Calculul relațional reprezintă o adaptare a calculului predicatelor la domeniul bazelor de date relaționale. Ideea de bază este de a identifica o relație cu un predicat. Pe baza unor predicate inițiale, prin aplicarea unor operatori ai calculului cu predicate (conjuncția, disjuncția, negația, cuantificatorul existențial și cel universal) se pot defini noi predicate, noi relații. Variabilele care apar în construcțiile calculului relațional orientat pe domenii sunt variabile definite asupra domeniilor, iar cele care apar în construcțiile calculului relațional orientat pe tupluri sunt variabile definite asupra relațiilor, adică valorile acestora reprezintă tupluri.

Echivalența dintre algebra relațională și calculul relațional a fost demonstrată de Ullman. Această echivalență arată că orice relație posibil de definit în algebra relațională poate fi definit și în cadrul calculului relațional, și reciproc.

CAPITOLUL IV

BAZE DE DATE DISTRIBUITE

4.1 Definiție, obiective și caracteristici generale

În ultimii ani, bazele de date distribuite (BDD) au devenit un sector important al prelucrării informației și se poate anticipa că importanța lor va crește rapid. Această tendință este motivată atât organizatoric cât și tehnologic întrucât BDD elimină multe din neajunsurile BD centralizate și sunt bine venite pentru descentralizarea structurilor organizatorice.

O BDD poate fi definită ca o colecție de date integrate din punct de vedere logic dar fizic distribuite pe stațiile unei rețele de calculatoare.

Această definiție pune în evidență două aspecte importante ale BDD:

Integrarea logică a colecțiilor de date. Din punct de vedere al utilizatorului există o singură bază de date cu care utilizatorul interacționează la fel ca și în cazul bazelor de date centralizate (BDC).

Distribuirea fizică se referă la partiționarea fizică a bazei de date pe stații ale unei rețele de calculatoare.

Ambele aspecte sunt destul de vagi pentru a realiza deosebirile între BDD și un set de BD locale. Fiecare computer împreună cu BD locală constituie o stație sau un nod al BDD, iar computerele sunt conectate prin sistemul de comunicație al rețelei. În timpul operațiilor obișnuite, cererile de aplicații de la terminalele fiecarei stații necesită numai accesul la BD locală. Aceste aplicații care sunt executate în întregime de computerul stației sunt numite aplicații locale.

Ceea ce deosebește un set de BD locale de o BD este existența unor aplicații care accesează date din mai multe stații. Aceste aplicații sunt numite aplicații globale sau aplicații distribuite.

Putem însuma considerațiile pe care le-am facut într-o definiție de lucru.

O BDD reprezintă o colecție de date integrate din punct de vedere logic care sunt fizic distribuite pe stații ale unei rețele de calculatoare. Fiecare stație a rețelei are autonomie de prelucrare care îi permite să realizeze aplicații locale. De asemenea, fiecare stație participă la execuția aplicațiilor globale care necesită accesarea datelor din mai multe stații.

BDD nu sunt simple implementări distribuite ale BDC, ele impun proiectarea unor sisteme care prezintă obiective comune cu sistemele centralizate dar și specifice. În acest sens este interesant de a compara obiectivele tipice ale BD tradiționale cu cele corespunzătoare ale BDD.

Obiectivele BD tradiționale se referă la: controlul centralizat, independența datelor, redundanța minimă și controlată a datelor, accesul eficient și, nu în ultimul rând, integritatea, securitatea și siguranța datelor.

Controlul centralizat. Posibilitatea de a realiza un control centralizat asupra resurselor informaționale ale unei intreprinderi sau structuri organizatorice a fost considerată una din cele mai puternice motivații pentru introducerea BD. Funcția fundamentală a administratorului BD este de a garanta protecția și siguranța datelor; datele în sine fiind recunoscute ca o investiție importantă a intreprinderilor care necesită un control centralizat.

În cazul BDD ideea controlului centralizat este puțin accentuată. Acest lucru depinde și de arhitectură. În general, putem să identificăm o structură de control ierarhic bazată pe un administrator global care are responsabilitatea centrală a întregii BDD și pe administratorii locali cărora le revin responsabilități legate de BD locale. Administratorii locali pot avea un grad înalt de autonomie care poate merge până la realizarea coordonării între stații. BDD diferă foarte mult în ceea ce privește autonomia stațiilor de la autonomia completă a stațiilor, fără existența administratorului global, până la cel mai complet control centralizat.

Independența datelor. În cazul BDD asigurarea independenței datelor față de programele de aplicații are aceeași importanță ca și în cazul BDC, dar apare un nou aspect legat de transparența distribuției. Prin transparența distribuției programele pot fi scrise făcând abstracție de distribuirea fizică a datelor. Mutarea datelor dintr-o stație în alta afectează numai viteza de execuție, nu și corectitudinea programului. Ca și în cazul independenței datelor, transparența distribuției este obținută printr-o arhitectură multinivel cu diferite descrieri ale datelor.

Asigurarea unei redundanțe minime și controlate. În cadrul BDD există mai multe motive pentru a considera redundanța datelor o caracteristică dezirabilă:

localizarea este mai rapidă atunci când datele sunt replicate la toate stațiile unde sunt cerute de aplicații;

disponibilitatea, siguranța sistemului crește atunci când datele sunt replicate.

În cazul căderii unei stații, aplicațiile pot fi dirijate la stațiile unde datele sunt replicate.

Redundanța datelor reduce efortul de regăsire a datelor dar crește efortul de actualizare. Evaluarea unui grad optim al redundanței trebuie să țină seama de raportul între accesele de regăsire și accesele de actualizare a datelor.

Integritatea, restaurarea datelor și controlul concurenței. În cazul BDD, realizările în domeniul integrității, restaurării datelor și controlului concurenței, deși se referă la probleme diferite, sunt puternic interconectate. Într-o mare măsură, soluțiile la aceste probleme sunt legate de modul de realizare a tranzacțiilor. O tranzacție este o unitate atomică de execuție, o secvența de operații care fie sunt realizate în întregime, fie nu sunt realizate. În cadrul BDD, problema atomicității tranzacțiilor capătă un aspect particular legat de modul în care trebuie să se comporte sistemul atunci când una din stații nu este operațională: să aborteze întreaga tranzacție sau să încerce să execute corect tranzacția chiar dacă ambele stații nu sunt simultan operaționale.

Siguranța și securitatea datelor. În BD tradiționale, administratorul BD care are controlul centralizat permite numai un acces autorizat la date. În BDD, administratorii se confruntă cu aceleași probleme ca administratorii BD tradiționale. Sunt de menționat două aspecte particulare:

în BDD, cu un grad ridicat de autonomie a stațiilor, BD locale sunt mai protejate deoarece administratorii locali își realizează propria protecție fără să depindă de un administrator centralizat;

problemele securității sunt intrinseci sistemelor distribuite deoarece comunicația în rețea poate reprezenta un punct slab în realizarea protecției.

Avantajele BDD față de BDC:

Creșterea adaptabilității sistemului. În orice moment baza de date poate fi extinsă prin adăugarea de noi structuri de baze de date cu un impact minim asupra structurii BDD și fără a afecta aplicațiile existente. În cazul sistemelor centralizate, dimensiunile inițiale ale sistemului trebuie să prevadă viitoarele expansiuni, lucru greu de realizat și costisitor de implementat.

Reducerea relativă a overhead-ului de comunicație prin creșterea numărului de aplicații realizate local (analize de sistem, aplicații, operare și introducere de date).

Sporirea performanțelor sistemului deoarece partajarea și replicarea datelor ca și existența mai multor procesoare au ca rezultat creșterea gradului de paralelism în executarea aplicațiilor.

Creșterea siguranței sistemului. Sistemul distribuit este proiectat astfel încât căderea unei stații nu afectează întregul sistem.

Disponibilitatea sporită a datelor asigurată de replicarea lor. Chiar dacă o stație cade, datele sunt încă disponibile prin copiile memorate pe alte stații.

BDD prezintă și o serie de dezavantaje legate mai ales de costul ridicat al implementării, de complexitatea proceselor și de dificultatea realizării controlului concurenței și al tranzacțiilor.

4.2. Arhitectura unui SGBDD

SGBDD promovează o arhitectură multinivel pentru a realiza unul din principalele sale obiective: transparența distribuției. În figura 4.1 este prezentată arhitectura SGBDD de tip ANSI/SPARC. Această arhitectură de referință nu este implementată explicit în toate sistemele de baze de date distribuite dar nivelele ei prezentate conceptual ne ajută să înțelegem modul de organizare a BDD.

Distingem două nivele de organizare a datelor: nivelul global și nivelul local.

1. Nivelul global permite integrarea bazelor de date locale într-o bază de date globală prin intermediul schemei globale, schemei de fragmentare și schemei de alocare.

Schema globală definește toate datele conținute în BDD. Modelele de date ce pot fi utilizate în descrierea schemei sunt aceleași ca și în cazul BD centralizate. Pentru exemplificare vom utiliza în continuare modelul relațional care este cel mai utilizat. În cadrul modelului relațional, schema globală este descrisă de un set de relații globale.

Fiecare relație globală poate fi împărțită în mai multe părți disjuncte numite fragmente. Corespondența între relația globală și fragmente este definită în schema de fragmentare. Această corespondență este tipul “unul la mulți” (mai multe fragmente corespund unei relații globale dar numai o relație globală corespunde unui fragment).

Fragmentele sunt porțiuni logice ale relațiilor globale care pot fi alocate fizic pe una sau mai multe stații ale rețelei. Schema de alocare definește stația sau stațiile unde sunt alocate fragmentele. Maniera de definire a schemei de alocare determină dacă BDD este redundantă sau neredundantă.

Două imagini fizice ale unei relații globale pot fi identice.

Nivel global

stația 1 stația 2

alte stații Nivel local

Nivel

local

Figura 4.1. Arhitectura SGBDD

2. Nivelul local permite tratarea fiecarei baze de date locale ca o bază de date centralizată. La acest nivel este necesară realizarea corespondenței între imaginea fizică și obiectele manipulate de SGBD-urile locale. Acest lucru este realizat de schema locală de reprezentare a datelor care depinde de tipul de SGBD local.

Transparența distribuției, în concordanță cu arhitectura prezentată, se realizează pe mai multe nivele.

Transparența fragmentării este cel mai înalt grad de transparență și se referă la faptul că utilizatorii sau programatorii aplicațiilor lucrează pe relațiile globale.

Transparența alocării (localizării) este un nivel de transparență mai scăzut și presupune ca programatorii de aplicații să lucreze cu fragmente fără să cunoască însă localizarea acestor fragmente. Separarea conceptului de fragmentare de conceptul de alocare a datelor este util în proiectarea BDD pentru ca în acest fel determinarea fragmentelor relevante este delimitată de problema alocării optime a datelor.

Un alt tip de transparență legat de transparența alocării este transparența replicării. Transparența replicării se referă la faptul că utilizatorii nu au informații despre replicarea fragmentelor. În anumite cazuri este posibil ca utilizatorul să nu aibă transparența alocării dar să aibă transparența replicării. De exemplu atunci când utilizatorul actualizează o singură copie iar sistemul operează aceleași modificări și pentru celelalte copii.

Transparența locală promovează independența față de SGBD- le locale permițând studierea problemelor SGBD-lor locale fără a ține seama de modelele de date utilizate.

În figura 4.2 este considerată organizarea ideală a unei BDD care suportă toate nivelele de independență și care este o extensie a arhitecturii pe trei nivele, propusă de grupul ANSI/X3/SPARC. În schemă se disting două nivele de organizare a datelor:

Nivel global, care permite integrarea bazelor de date locale într-o bază de date globală;

Nivelul local, care permite tratarea fiecărei baze locale inclusă în BDD ca o bază centralizată.

Schema globală este o descriere globală și unificată a tuturor datelor aparținând unei BDD, independent de orice bază locală. O schemă globală are trei nivele:

Schema conceptuală globală (SCG) definește toate relațiile aparținand BDD și furnizează independența fizică a datelor.

Schema externă globală (SEG) asigură independența logică a datelor și suportă solicitările unei clase de utilizatori particulari. Regulile de definire a solicitărilor permit transformarea datelor de la nivelul schemei externe globale în date la nivelul schemei conceptuale globale.

Schema de alocare (SA) precizează modul în care relațiile sunt alocate în rețea în diferite stații. Schema conține informații referitoare la localizare, fragmentare, dubluri.

Stație 1 Stație 2

Figura 4.2

Nivelele schemei care descriu o bază de date locală se numesc locale. O schemă locală are trei nivele: schema externă locală (SEL), schema internă locală (SIL), schema conceptuală locală (SCL). Spre deosebire de schema globală, care este unică, există atâtea scheme locale câte stații sunt în rețea.

Un utilizator global interacționează cu BDD în același mod în care ar interacționa cu o bază de date centralizată (figura 4.3).

tranzacție nivel global

globală

tranzacție nivel local

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

locală răspuns local

baza de utilizator

date local

locală

Figura 4.3

Utilizatorul își exprimă cererile sub forma unor tranzacții globale. Tranzacțiile sunt evaluate și descompuse cu ajutorul informațiilor conținute în dicționarul sistemului distribuit (DSD). Tranzacțiile sunt plasate supervizorului execuției distribuite. Acesta plasează fiecare cerere nodului în care se află baza locală pe care trebuie să o interogheze și primește răspunsuri de la diferite baze interogate. Cererea trebuie adaptată la cerințele sistemului de gestiune a nodului local care va trata cererea primită ca o cerere locală. Fiecare bază locală poate fi exploatată local de utilizatori locali prin intermediul unor SGBD locale.

Cererile de acces pot solicita date situate în noduri diferite. Pentru a superviza execuția unei astfel de cereri, un nod trebuie să-și asume rolul de coordonator (celelalte sunt noduri cooperante). Un nod poate fi în același timp și coordonator (pentru cereri lansate din acel nod) și cooperant (pentru cereri lansate din celelalte noduri, care solicită acces la acel nod).

Controlul execuției cererii la distanță se realizează prin schimb de mesaje (protocol) între coordonatorul cererii și cooperanții acelei cereri.

Execuția fiecarei cereri de actualizare este realizată în două etape:

i) Pregătirea execuției, adică citirea datelor, scrierea în jurnale locale a datelor neactualizate și a datelor actualizate (imagini “înainte” și “după”);

ii) Realizarea cererii, adică introducerea actualizărilor în BDD dacă sistemul funcționează corect, sau nerealizarea cererii la apariția oricărui incident.

Algoritm RCD (realizarea unei cereri)

Nodul coordonator trimite mesajul “PREGATEȘTE” tuturor nodurilor cooperante.

Fiecare nod cooperant realizează faza (i) la primirea mesajului și returnează nodului coordonator mesajul pregătit.

La primirea acestui mesaj de la toate nodurile cooperante, nodul coordonator transmite mesajul “REALIZEAZĂ”.

La primirea acestui mesaj, nodul cooperant realizează faza (ii), iar la încheierea cu succes a lui (ii), fiecare nod cooperant trimite mesajul “REALIZAT”. Insuccesul este marcat cu “ABORT”, ceea ce determină ca nodul cooperant să emită mesaj “REVENIRE”. În acest caz, se declanșează procesul de refacere a bazei de date la starea în care se află înaintea lansării cererii.

Execuția cererilor, în ordinea enunțării lor, în toate nodurile cooperante este asigurată prin utilizarea unor mecanisme speciale, cum ar fi mărcile de timp sau inelul virtual.

Mărcile de timp. La emiterea ei, fiecare cerere primește în mod automat o marcă de timp (identificatorul nodului + timpul ceasului local). Fiecare articol din BDD are o marcă de timp care este modificată la fiecare actualizare a cererii care l-a referit. Sistemul de gestiune asigură execuția cererilor în ordinea crescătoare a mărcilor de timp. O cerere este executată dacă marca sa de timp este mai mare decât marca de timp a articolelor la care solicită accesul.

Inelul virtual. Nodurile rețelei sunt înlănțuite logic, formând un inel virtual. Fiecare nod are un predecesor și un succesor. Pe inel circulă un tichet. Nodul la care se află tichetul poate emite un mesaj (dacă este liber). Tichetul trece apoi pe la toate nodurile, iar mesajul este preluat de nodul căruia îi este adresat (nod cooperant). Când tichetul ajunge din nou la nodul care a emis mesajul, acesta devine liber, iar tichetul trece la nodul următor.

Figura 4.4 ilustrează arhitectura funcțională simplificată a unei BDD. Funcțiile sunt grupate pe două componente sistem diferite prezente în fiecare stație: administratorul aplicațiilor (client) și administratorul datelor (server). În general, o cerere a unui utilizator solicită administratorul aplicațiilor din stația client și administratorii de date din una sau mai multe stații server.

Interfața utilizator primește o cerere de la utilizator și verifică dacă datele specificate în cerere sunt conform cu SEG.

Controlul semantic al datelor transformă cererea exprimată prin tabele view în SEG, într-o cerere exprimată sub forma unor relații conceptuale globale definite prin SCG.

Evaluarea cererilor distribuite transformă o cerere într-un plan de acces distribuit, alege localizarea optimă a copiilor de fragmente, ordonează cererile astfel încât să minimizeze funcția cost.

Gestiunea tranzacțiilor distribuite coordonează execuția unei cereri distribuite, asigură controlul concurenței și validarea tranzacțiilor.

Evaluarea cererilor locale permite traducerea cererii exprimate conform schemei de alocare, într-o cerere exprimată conform schemei de alocare, într-o cerere exprimată conform SEL.

răspunsuri ale cereri al

client sistemului utilizatorului

server

Figura 4.4

Gestiunea subtranzacțiilor permite sincronizarea execuției subtranzacțiilor unei tranzacții. Accesul la date implică funcțiile normale de gestiune ale unui SGBD.

Gestiunea datelor într-o BDD ridică probleme tehnice dintre care amintim:

repartiția și duplicarea datelor fac dificilă funcția de gestiune a dicționarului datelor, definiția datelor și controlul datelor.

existența unui număr mare de resurse (stații multiple, rețea de comunicație) afectează funcțiile de evaluare a cererilor și toleranță la defecțiuni.

fiecare stație are informații parțiale despre tranzacțiile globale executate de BDD. Gestiunea tranzacțiilor trebuie să se bazeze pe colaborarea și sincronizarea mai multor stații.

4.3 Gestiunea datelor distribuite

Intuitiv, o bază de date distribuită (BDD) este o mulțime de date corelate logic, dar distribuite fizic pe mai multe mașini interconectate printr-o rețea de comunicație. Din punct de vedere al utilizatorului, o BDD reprezintă o singură bază de date, o singură schemă conceptuală globală (integrare logica a mulțimilor de date). Programul de aplicație care manipulează o BDD poate avea acces la date rezidente pe mai multe mașini, fără ca programatorul să cunoască localizarea acestor date (distribuire fizică).

O gestiune orientată pe BDD are avantaje apreciabile, dintre care enumerăm:

Fiecare grup de persoane care dispune de un calculator are un control direct asupra datelor locale administrate de acest calculator. Aceasta implică un tratament eficient al datelor.

Comparativ cu modul centralizat în care datele, pentru a fi tratate, trebuiau transferate de la fiecare grup spre calculatorul central, tratamentul local al datelor reduce costul comunicării.

Performanțele și fiabilitatea gestiunii datelor pot fi mărite utilizând procesarea paralelă și redundanța oferită de mai multe mașini.

Bazele de date distribuite reprezintă soluția naturală a gestionării datelor puternic distribuite geografic.

Baza de date la distanță este o bază de date situată pe un calculator diferit de calculatorul utilizatorului și care este accesată datorită comenzilor de comunicație specificate de utilizator (figura 4.5). Accesul la distanță este în general limitat la consultarea bazei, iar reactualizarea este făcută centralizat.

Baza de date distribuită este o mulțime de baze de date cooperante care rezidă pe mașini diferite, deci în locuri (stații) diferite, interconectate printr-o rețea de comunicație. Această mulțime este accesată și manipulată de catre utilizator, ca și cum ar fi o singură bază de date centralizată (figura 4.6). Repartiția datelor este transparentă pentru utilizator.

terminale

. . .

puncte de lucru

. . .

rețea

Figura 4.5

Gestiunea unei baze de date necesită ca în fiecare stație (loc) să fie instalat un sistem de comunicație a datelor (responsabil de interfața cu rețeaua), un SGBD local și un administrator (soft) al datelor distribuite.

terminale terminale

. . . . . .

Stație 1 Stație 2

Figura 4.6

Sistemul de baze de date distribuite are următoarele componente software:

Sistemul de gestiune al bazei de date locale (SGBDL), care este un sistem standard de gestiune a datelor. Acesta cuprinde propriul dicționar pentru datele locale.

Componenta de comunicație (CC), care realizează legăturile în cadrul rețelei. Această componentă cuprinde descrierea completă a nodurilor și legăturilor din cadrul rețelei.

Dicționarul de date locale (DDG), care cuprinde informații despre baza de date distribuită referitoare la localizarea, structura, disponibilitatea și modul de utilizare a datelor.

Sistemul de gestiune al bazei de date distribuită (SGBDD), care asigură interfața între baza de date distribuită și utilizatorii acesteia. Baza de date distribuită omogen este compusă din baze de date locale administrate de același SGBD (figura 4.7). Ea se obține prin diviziunea bazei în baze de date locale.

Baza de date distribuită eterogen se obține prin integrarea bazelor existente, administrate de SGBD diferite, într-o singură bază de date (figura 4.8). Există două nivele de eterogenitate. Bazele de date sunt de același tip (de exemplu, relațional), dar sunt administrate de SGBD diferite (ORACLE, INGRES, SABRINA etc.). Bazele de date sunt de tipuri diferite (de exemplu, relațional și ierarhic) și sunt administrate de SGBD diferite (IMS, SABRINA etc.).

. . . . . .

Figura 4.7 Figura 4.8

BDD reprezintă deci o mulțime de baze de date puternic corelate, administrate și manipulate ca o singură bază de date. Această abordare integrată ridică două probleme majore:

Administrarea centralizată poate fi deosebit de complexă dacă există multe baze locale.

Accesul utilizatorului la propria sa bază locală este încetinit de mecanismul și costul suplimentar al gestiunii datelor distribuite. Orice acces la baza de date distribuită se face prin SGBD.

Aceste probleme sunt rezolvate de bazele de date federale (BDF), numite și multibaze de date (figura 4.9). BDF reprezintă mulțimi de baze autonome, slab corelate, pe care un utilizator poate să le manipuleze cu ajutorul unui limbaj specific.

Păstrând avantajele bazelor de date distribuite, bazele federale permit:

Slăbirea legăturii dintre bazele de date locale;

Furnizarea unui limbaj necesar utilizatorului pentru a defini relațiile dintre diferite baze și pentru a manipula mai multe baze concurent.

Un SGBD federal (SGBDF) diferă de un SGBD deoarece:

Nu administrează un dicționar global care conține informații referitoare la bazele de date distribuite;

Suportă un limbaj pentru a defini dependențele care pot exista între diferite baze de date;

Suportă un limbaj pentru a defini și manipula baze de date care aparțin federației.

terminale terminale

. . . . . .

Figura 4.9

Arhitectura unui SGBDF cuprinde un sistem global de gestiune a datelor și o interfață cu baza locală care asigură translatarea unei cereri în limbajul de manipulare a datelor al sistemului local, execuția cererii și transmiterea rezultatului.

Baza de date paralelă este o BDD omogenă în care stațiile sunt nodurile unui calculator paralel (multiprocesor). Stațiile comunică între ele prin mesaje. Diferența față de o BDD omogenă este că un nod al calculatorului paralel nu este o stație unde utilizatorul poate executa explicit un program aplicație. Programele sunt executate pe calculatorul gazdă sau pe stații de lucru care comunică cu calculatorul paralel printr-o interfață specifică (PI: procesor interfață). Pentru utilizator, acest calculator paralel este ca o cutie neagră (figura 4.10).

Componentele sistemului sunt specializate și pot exploata mai bine arhitectura materială (în particular, paralelismul) pentru manipularea optimă a datelor (PA: procesor acces).

rețea

…

Figura 4.10

CAPITOLUL V

BAZE DE DATE ORIENTATE OBIECT

Bazele de date relaționale, care în 1990 acopereau 70% din piața bazelor de date, oferă prea puțin suport pentru tipurile neconvenționale de date. Necesitatea gestiunii obiectelor complexe (texte, grafice, hărți, imagini, sunete etc.) și a gestiunii obiectelor dinamice (programe, simulări) care nu pot fi realizate cu ajutorul sistemelor relaționale a condus la introducerea conceptului de obiect în tehnologia sistemelor informatice.

Bazele de date orientate obiect (BDOO) permit crearea unor obiecte complexe din componente mai simple, fiecare având atribute proprii și comportament specific. Înglobarea conceptului de obiect în tehnologia SGBD a generat producerea unor SGBD orientate obiect (SGBDO). Aceste sisteme combină posibilitatea de definire și manipulare a structurilor complexe de date cu funcționalitatea unui limbaj de programare și tehnologia de gestiune a bazelor de date.

Modelarea orientată obiect încearcă să integreze principiile limbajelor de programare orientate obiect (Smalltalk, C++) și a bazelor de date, pentru a rezolva problema interfeței limbaj de programare – SGBD, pentru a oferi un limbaj unic și general.

Există tendințe, fie de a extinde SGBD pentru a suporta obiecte complexe cu funcții speciale pentru manipularea datelor, fie de a dezvolta limbajul de cereri în jurul unui SGBD clasic. O soluție bună este crearea unui SGBD relațional care să suporte majoritatea principiilor modelării orientate obiect.

Comparativ cu un SGBD relațional, un SGBDO oferă funcționalități superioare referitoare la:

modelarea dinamică a obiectelor;

organizarea schemei sub forma unei ierahii de clase;

modelarea obiectelor complexe și a obiectelor de dimensiuni mari (multimedia);

utilizarea unui limbaj unic pentru programarea întregii aplicații;

gestiunea dinamică a schemei;

gestiunea versiunilor pe obiecte.

Limbajul de bază al acestor sisteme este un limbaj de programare procedural (C, Smalltalk, LISP) extins prin posibilități obiect. De asemenea, folosirea unor cereri declarative (de exemplu, de tip SQL) într-un SGBDO permite optimizarea acceselor (exprimate prin predicate ce leagă colecții de date).

Cu toate avantajele incontestabile oferite de SGBDO, impunerea lor pe piață nu va fi ușoară. Cele mai importante cauze sunt:

absența unei fundamentări teoretice face imposibilă definirea unui SGBDO de referință. În consecință, sistemele, modelele de date și limbajele sunt diversificate, iar evaluarea lor este dificilă din cauza lipsei unor criterii precise.

problema performanțelor, care este inerentă oricărei tehnologii moderne, este încă nerezolvată. Sistemelor relaționale le-au trebuit mai mult de zece ani pentru a obține performanțele actuale. Evident, gestiunea obiectelor complexe și persistente accesate prin programe generale este o problemă mai dificilă decât accesul prin cereri SQL. Tehnicile de optimizare legate de extinderea standardului SQL, problema concurenței în cazul tranzacțiilor lungi (o tranzacție de concepție poate să dureze câteva ore) sunt doar la început de drum.

utilizatorii au investit sume uriașe în sistemele relaționale și nu le pot abandona cu ușurință. Trecerea la noua tehnologie orientată obiect implică investiții mari și nu păstrează aproape nimic din vechile soluții.

5.1 Caracteristicile fundamentale ale unui SGBDO

Vom defini conceptul de bază de date orientată obiect (BDOO) și vom comenta caracteristicile unui SGBD orientat obiect (SGBDO).

Un obiect persistent este un obiect stocat în baza de date care are o durată de viață mai mare decât a programului care l-a creat. Un obiect tranzitoriu este un obiect depus în memorie, a cărui durată de viață nu depășește durata de viață a programului care l-a creat.

Baza de date orientate obiect este o organizare coerentă de obiecte persistente, partajate de utilizatorii concurenți. Prin urmare, BDOO este rezultatul aplicării tehnologiei orientate obiect în domeniul stocării și regăsirii informațiilor. Schema unei BDOO trebuie să includă definițiile structurale (atribute și tipuri) și comportamentele (metode) ale obiectelor. Prin urmare:

Schema unei BDOO = {clase + asocieri între clase}.

Schema bazei constă din toate clasele care au fost definite pentru o aplicație particulară. Definițiile claselor include moștenirea, relațiile de înrudire (supraclase, subclase) și relațiile structurale dintre clase (asocieri).

Asocierile dintre clase sunt necesare pentru a reflecta constrângerile de integritate referențiale la nivelul claselor. O asociere între două clase este reprezentată prin două legaturi, una fiid inversa celeilalte. În exemplul următor este ilustrată asocierea dintre clasele Functionar și Loc prin legătura dintre funcționar și stația la care a fost afectat și, de asemenea, legătura (inversă) între stație și elementele sale.

Class Functionar {

String nume;

Loc Inverse link Loc.elemente atașare

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

Class Loc {

String nume;

Funcționar șef;

Funcționar Inverse link Functionar.atașare elemente;

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

Schema bazei de date poate fi modificată dinamic în funcție de necesitățile utilizatorilor. Pot fi identificate două tipuri de schimbări ale schemei unei BDOO:

schimbări referitoare la structura ierarhiei de clase, care includ adăugarea sau ștergerea unei clase și schimbarea relațiilor supraclasă/subclasă dintre două clase;

schimbări referitoare la modul de definire a unei clase, care includ schimbările atributelor și metodelor definite pentru o clasă (de exemplu, schimbarea numelui sau domeniului unui atribut, adăugarea, ștergerea unui atribut sau unei metode).

Un SGBDO trebuie să îndeplinească cerințele unui SGBD și să fie, în plus, un sistem orientat pe obiecte. Aceste două criterii generează o mulțime de caracteristici ale unui SGBDO. Putem accepta ca definiție minimală:

SGBDO = SGBD + obiect + moștenire + polimorfism.

Caracteristicile obligatorii ale unui SGBDO sunt:

Manipularea obiectelor atomice și complexe (colecții imbricate). Un constructor este o funcție asociată unei clase care permite crearea și inițializarea unui obiect (în memorie). Un destructor este o funcție asociată unei clase care permite distrugerea unui obiect. Noțiunea de obiect complex s-a născut prin aplicarea de constructori asupra obiectelor simple. O condiție privind constructorii, referitoare la MDOO, o constituie ortogonalitatea care presupune ca fiecare constructor să fie aplicabil fiecărui obiect.

Persistența obiectelor. Obiectele pot persista mai mult decât programul care le-a creat.

Concurența acceselor. BDOO poate să fie partajată simultan de către tranzacțiile care o consultă și o modifică.

Fiabilitatea obiectelor. Obiectele trebuie restaurate în cazul unei defecțiuni la starea pe care au avut-o înainte de defecțiune.

Ușurința interogării. Un obiect poate fi găsit utilizând valorile atributelor sale, legăturile cu alte obiecte sau metode aplicate obiectului.

Identitatea obiectelor. Orice obiect trebuie să aibă un identificator sistem.

Moștenirea (simplă). O clasă poate fi specializarea unei alte clase și, prin urmare, poate să o moștenească. Moștenirea reduce efortul de programare. Există diferite modalități de a moșteni și anume prin: substituție, incluziune, restricție, specializare.

Polimorfism. Codul unei metode trebuie ales în funcție de parametrii săi.

Extensibilitate. SGBDO trebuie să includă pe lângă clasele sau tipurile predefinite (clasă obiect, clasă dată etc.) și instrumente care să permită utilizatorului definirea de noi clase și tipuri.

Dintre caracteristicile opționale ale unui SGBDO amintim:

Distribuția obiectelor. Aceasta permite gestionarea obiectelor în diferite spații.

Modelarea tranzacțiilor evaluate. Ideea este de a accepta tranzacții imbricate care pot fi descompuse în subtranzacții.

Versiuni ale obiectelor. Plecând de la un anumit obiect, prin modificări succesive sau paralele, pot fi obținute mai multe versiuni ale obiectului. Acestea generează un graf al versiunilor unui obiect care este gestionat de sistem.

Moștenirea multiplă. O clasă (subclasă) poate fi specializarea directă a două sau mai multe supraclase și să moștenească proprietățile acestora.

Mesaje eroare. Este vorba de un mecanism special pentru tratarea erorilor, introdus deja in C++ 3.0. Dacă într-o metodă apare o eroare, atunci este trimis un mesaj unei clase speciale, numită clasa EROARE, pentru înregistrarea erorii respective.

Un SGBDO se bazează pe două tehnologii: bazele de date și limbajele orientate obiect. În funcție de combinarea acestor două tehnologii există diferite moduri pentru a concepe un SGBDO. Vom comenta trei abordări:

Extinderea unui SGBD relațional și a limbajului interfață cu conceptul obiect. Se realizează o extensie a standardului SQL care suportă conceptul obiect și implicit se extinde algebra relațională. Este ideea propusă de sistemul de gestiune ORACLE pentru versiunea 8.

Duala primei idei este abordarea care pleacă de la un limbaj orientat obiect (C++ sau Smalltalk) ce este extins pentru a permite definirea schemei unei BDOO și scrierea unor programe aplicație care includ apeluri ale SGBDO. Este tehnica folosită de sistemul ObjectStore cu C++ și GemStone cu Smalltalk.

Contrara tehnicilor precedente este abordarea integrată care nu se bazează pe extinderea modelului relațional sau a limbajului obiect. În acest caz, sistemul de gestiune suportă un nou model care integrează conceptele semantice și obiectul. Sistemul integrat (de exemplu, sistemul O2) poate fi independent de orice limbaj de programare și poate oferi o interfață multilimbaj.

5.2 Arhitectura unui SGBDO

Arhitectura funcțională a unui SGBD se referă la o descriere abstractă a organizării sistemului în scopul de a prezenta componentele funcționale și interfețele dintre acestea. În figura 5.1 este reprezentată arhitectura funcțională a unui SGBDO marcând cele trei componente de bază: utilitare, limbaje și gestiunea obiectelor. Utilizatorul final are nevoie doar de o submulțime a acestor funcții.

Utilizatorii finali externi și cei care dezvoltă aplicații pot folosi diferite utilitare, cum ar fi: editoare de texte, editoare grafice, browser-e (vizualizatori) de obiecte și clase, accesorii pentru proiectare automată de baze de date, interfețe pentru sisteme de proiectare, generatoare de aplicații, interfețe grafice tipic orientate obiect. L4G este un termen generic care desemnează utilizare pentru dezvoltare și utilizare de aplicații referitoare la baze de date.

SGBDO sunt accesate prin limbaje de programare orientate obiect (de exemplu, C++, Smalltalk). Interfața dintre limbajele de programare orientate obiect (LPO) și SGBDO o reprezintă limbajul pentru baze de date. Pentru un SGBD clasic limbajul pentru bază de date permite definirea și manipularea schemei bazei de date și a datelor. Pentru un SGBDO limbajul pentru baze de date permite accesul și manipularea modelului de date obiect, regăsirea și actualizarea obiectelor. Deoarece LPO au existat înaintea SGBDO, numeroase declarații din LDD și LMD sunt adaptări ale declarațiilor LPO existente.

Limbajul pentru baze de date al SGBDO cuprinde:

Limbajul de definire a datelor (LDD) permite definirea claselor, a legăturilor de moștenire, definirea metodelor ce specifică comportamentul obiectului, specificarea unor reguli adiționale de constrângere și integritate etc.

Limbajul de manipulare a datelor (LMD) permite regăsirea, crearea, ștergerea și actualizarea obiectelor individuale utilizând mecanismul de transmitere a mesajelor.

Limbajul de cereri permite regăsirea subseturilor unei baze de date. Regăsirea obiectelor individuale se face prin referirea identificatorului obiectului (OID).

UTILITARE

LIMBAJE

GESTIUNEA OBIECTELOR

Figura 5.1

Pentru selectarea și găsirea obiectelor, limbajul de cereri se bazează pe transmiterea de mesaje.

SGBDO poate avea interfețe cu unul sau mai multe LPO și interfețe cu alte SGBD (de exemplu, relaționale).

Administratorul obiectelor (AO) asigură interfața dintre procesele externe și SGBDO. El permite definirea structurilor și executarea operațiilor specificate prin modelul de date obiect. AO primește cereri de creare de definiri de clase, de modificare de definiri de clase deja existente, de manipulare a mesajelor generate de o aplicație, de prelucrare a cererilor folosind translatorul de cereri.

AO primește mesaje pentru obiecte individuale, realizează funcții de prelucrare a mesajelor, legături dinamice, operații de verificare a tipului de date, permite anumite facilități de definire și modificare a schemei bazei de date. Cerințele externe sunt transmise apoi, sub formă de tranzacții, server-ului de obiecte (SO).

Pentru a realiza transmiterea de mesaje și prelucrarea cererii, AO efectuează urmatoarele acțiuni:

menține spațiul local de lucru al utilizatorului extern (controlul sesiunii);

selectează o metodă pentru un mesaj transmis unui obiect în momentul execuției (legătura dinamică);

creează noi obiecte;

expediază cerințele și actualizările obiectului (ca tranzacții);

optimizează și translatează cererile.

Obiectele, definirile de clasă și metodele cerute de AO sunt regăsite de SO în stocul resident de obiecte.

Definirea și modificarea schemei presupune:

asigurarea accesului la definirile de clasă existente;

extensibilitatea schemei bazei de date (crearea, mutarea sau modificarea definirilor de clasă);

redefinirea dinamică a clasei, consistența structurală dintre definirile modificate și obiectele clasei existente anterior.

AO trimite cereri server-ului de obiecte pentru regăsirea și actualizarea definirilor de clasă.

Server-ul de obiecte (SO) realizează refacerea, inserția, ștergerea și actualizarea obiectelor ce se găsesc în stocul rezident de obiecte. Un singur SO poate manipula tranzacții primite de la mai mulți AO. SO asigură gestiunea tranzacțiilor și gestiunea fizică a stocului. Gestiunea tranzacțiilor se bazează pe gestiunea stocului în realizarea regăsirii și actualizării obiectelor stocate. Gestiunea tranzacțiilor presupune:

controlul concurenței și partajarea concurentă a datelor de către mai mulți utilizatori;

transferul obiectelor între stocul de obiecte și spațiul de lucru al utilizatorului;

refacerea în cazul căderii tranzacției sau a unei componente fizice;

controlul tranzacțiilor cooperante (comunicare între tranzacții individuale a unor utilizatori ce cooperează);

urmărirea și înregistrarea schimbărilor de date (în timp) prin gestiunea versiunilor unui obiect.

Gestiunea stocului se referă la asigurarea cailor de acces necesare realizării accesului eficient la stocul de obiecte și la menținerea nivelului fizic de organizare a BDOO (suport pentru rezidența obiectelor, facilități de arhivare și asigurare de dubluri). Prima din aceste funcții include indexarea obiectelor pe baza identificatorului obiectului (OID), indexarea obiectelor prin valorile variabilelor de instanță sau forme speciale de indecsi pentru obiecte. De exemplu, o variabilă de instanță a unui obiect trebuie să aibă ca valoare identificatorul de obiect (OID) a unuia sau a mai multor obiecte diferite. Crearea indecșilor permite accesul rapid la grupuri de obiecte.

Este permisă gruparea obiectelor în același sector de stoc pentru regăsirea eficientă a grupurilor de obiecte ce sunt accesate împreună. Similar, pentru ușurința prelucrării, obiectele mari pot fi segmentate, împărțite și stocate în structuri fizice separate.

Arhitectura prezentată, bazată pe server de obiecte, este specifică primelor SGBDO pentru care unitatea de transfer între server și stația de lucru client este obiectul sau grupul de obiecte. Arhitectura a fost implementată în SGBD relaționale extinse (substituind tuplul prin obiect) și în sistemele Orion, Ontos, Versant etc. În acest tip de arhitectură, interfața dintre client și server permite:

crearea sau distrugerea unui obiect;

citirea sau scrierea unui obiect;

trimiterea unui mesaj către obiect.

Am subliniat deja că acestă arhitectură concentrează toate funcțiile bazei de date în server, iar gestiunea interfeței ți exploatarea utilitarelor (L4G) o face obiectul. Centralizarea simplifică funcții precum integritatea și partajarea datelor, dar tot centralizarea are dezavantajul că dacă sistemul are stații de lucru puternice, numărul de cereri adresate server-ului poate fi mare și, prin urmare, clienții pot aștepta un timp semnificativ obiectele server-ului. Server-ul aplică blocarea la nivel de obiect, ceea ce permite un nivel înalt de concurență dacă dimensiunea obiectelor este mică (mai mică decât dimensiunea paginii). De exemplu, două obiecte continute în aceeași pagină pot fi accesate simultan de doi clienți diferiți.

Există arhitecturi care utilizează un server de pagină și deci pentru care unitatea de transfer între client și server este pagina. SGBDO recente, precum ObjectStore și O2, folosesc această arhitectură pentru a putea exploata puterea stațiilor de lucru. Server-ul gestionează o memorie cache de pagini aplicând mecanismul blocării la nivel de pagină. Clientul emite cereri de pagină server-ului iar acesta blochează pagina și apoi satisface cererea.

Figura 5.2

Aplicarea blocării la nivel de pagină limitează gradul de concurență. De exemplu, două obiecte continute în aceeași pagină nu pot fi accesate simultan de doi clienți diferiți. Un alt dezavantaj este legat de modul de tratare a cererilor. De exemplu, selecția obiectelor dintr-o colecție cere citirea colecției pagină de pagină.

Interfața client-server permite alocarea sau dezalocarea de pagini și citirea sau scrierea unei pagini. În figura 5.2 este reprezentată o arhitectură server de obiecte iar în figura 5.3 este reprezentată o arhitectură server de pagini. Schemele sunt simplificate pentru a putea marca deosebirile dintre cele două.

Arhitectura ideală este evoluția naturală a acestor două arhitecturi, deci o arhitectură hibridă, în care fiecare mașină poate fi considerată server, client sau ambele, în același timp. În figura 5.4 este prezentată o arhitectură multi-server cu două stații de lucru având aceleași funcționalități.

arhitecturi.

Figura 5.3

obiecte sau pagini

Figura 5.4

Unitatea de transfer între server-e poate fi obiectul sau pagina. Aplicația ar trebui să se execute accesând într-o manieră similară obiecte locale sau situate la distanță. Arhitectura este utilizată în SGBD distribuite (de exemplu, GemStone).

Fiecare server are spațiul sau propriu pentru adresarea obiectelor și un catalog ce conține informații referitoare la repartiția obiectelor. Acest catalog permite localizarea obiectelor nelocale. Există sisteme (Ontos) în care, pentru simplificare, se consideră că unitatea de localizare este baza de obiecte și nu obiectul. Pentru acest tip de arhitectură trebuie ca un obiect și toate obiectele legate de acesta să fie locale, adică un obiect nu poate referi alt obiect care este nelocal.

CAPITOLUL VI

BAZE DE DATE DEDUCTIVE

Anii optzeci au marcat apariția și consolidarea unui nou concept în cadrul tehnologiei bazelor de date: bazele de date inteligente (BDI). Dintre realizările extrem de convingătoare din domeniul bazelor de date inteligente pot fi menționate bazele de date deductive (BDDe).

Prin intermediul BDI s-a urmărit realizarea unei gestionări naturale a datelor, adică a unei memorări, accesări și utilizări firești și facile a datelor, în scopul satisfacerii cât mai depline a cerințelor informaționale ale utilizatorilor, deci a îmbunătățirii procesului decizional economic. Se poate afirma, prin urmare că BDI au apărut ca rezultat al eforturilor de ameliorare și perfecționare a tehnologiei bazelor de date, reprezentând un rezultat al cercetărilor întreprinse în domeniul bazelor de date.

Trebuie menționat, totodată faptul că interesul pentru BDI s-a manifestat nu numai în domeniul bazelor de date, ci și în domeniul inteligenței artificiale, în legatură cu eforturile de realizare a bazelor de cunoștințe. Realizarea sistemelor de inteligență artificială a impus și soluționarea problemelor legate de gestionarea și utilizarea unor volume mari de cunoștințe. Soluția la care s-a ajuns, în mod natural a fost organizarea acestor cunoștințe sub forma unor baze de cunoștințe, după modelul organizării datelor în baze de date. Bazele de cunoștință prezintă caracteristici structurale și funcționale distincte de cele ale bazelor de date. Cu toate acestea, s-a constatat că eforturile întreprinse pe linia realizării BDI pot fi valorificate în cadrul eforturilor de realizare a bazelor de cunoștințe, existând o serie de puncte de convergență între cele două tehnologii.

Se poate afirma, deci că cercetările din domeniul bazelor de cunoștințe și cele din domeniul BDI se susțin reciproc, fiind posibilă o trecere de la tehnologia bazelor de date la cea a bazelor de cunoștințe, prin intermediul BDI. Uneori, BDI sunt considerate drept baze de cunoștințe într-o formă “primară” sau chiar baze de cunoștințe propriu-zise.

Caracteristicile BDI precum și soluțiile de realizare efectivă variază extrem de mult, ceea ce creează dificultăți în însăși definirea conceptului de BDI, direcția de activitate cu cele mai convingătoare rezultate fiind cea a bazelor de date deductive.

BDDe reprezintă un tip de BDI pentru care există constituită o bază teoretică solidă, precum și realizări practice semnificative.

6.1 Caracteristicile bazelor de date inteligente

BDI trebuie să permită tratarea unei mari cantități de date, provenind din diferite surse, sub diferite forme de prezentare (text, imagine, sunet etc). BDI reclamă, deci utilizarea tehnologiilor multimedia. Trebuie subliniat faptul că diferite medii, precum imaginile sau sunetele, atunci când sunt aduse în formă digitizată, consumă o mare cantitate de suport de memorie. De exemplu, o pagină obișnuită de caractere memorat sub formă de text ASCII reclamă în jur de 2KB de memorie, în timp ce reprezentarea picturală (de tip imagine) a aceleiași pagini reclamă 500KB memorie. În situația în care o persoană vorbește timp de două minute, pentru a citi aceeași pagină, digitizarea vocii reclamă, pentru memorare 1MB. Pe lângă suport de memorare, tehnologiile multimedia reclamă dispozitive speciale pentru introducerea / extragerea datelor (cititor optic de caractere, scanner, plotter, sintetizator de voce etc).

O mare cantitate de date poate fi cu adevărat utilă numai în condițiile utilizării unor metode adecvate de organizare și regăsire. Modelul datelor utilizat în cadrul unei BDI trebuie să ofere datelor o structură flexibilă care să permită încorporarea în BD atât a caracteristicilor structurale, cât și a celor comportamentale ale realității reflectate informațional. Totodată, BDI trebuie să poată încorpora cât mai mult din semantica datelor în scopul transformării BD dintr-un ansamblu de date amorf, greu de tratat, într-un ansamblu posibil de interpretat drept răspunsuri la potențialele întrebări ale utilizatorilor. Transferarea semanticii datelor din cadrul programelor de aplicație în cadrul BD facilitează întreținerea coerenței și consistenței datelor, precum și utilizarea BD în sensul facilitării scrierii programelor de aplicație, evitându-se duplicarea programelor cu funcționalitate apropiată. Ținând seama de aceste cerințe, BDI recurg adesea la utilizarea modelelor orientate obiect pentru organizarea datelor.

A ști unde se găsește o anumită dată și cum trebuie accesată, reprezintă în cazul BDI de multe ori o sarcină extrem de dificilă. Se știe ca în cadrul BD tradiționale pentru regăsire se utilizează modelul datelor, un sistem de indexare și un limbaj de cereri, toate având un caracter static, astfel încât actualizarea lor nu se poate realiza decât prin procese externe, la anumite intervale de timp. În cazul BDI se utilizează frecvent procese de căutare inteligente, bazate pe inferențe care permit determinarea nevoilor informaționale ale utilizatorilor și a modului în care aceste nevoi pot fi satisfăcute. Este posibil ca informațiile necesare unui anumit utilizator nici să nu fie memorate explicit în BDI, fiind necesară inferențierea, derivarea lor de către SGBDI prin procese de raționament.

Nu numai procesul de căutare a datelor în cadrul BDI poate fi prezentat drept un proces inteligent, ci și procesele de asigurare a calității datelor din BDI, de gestionare a tranzacțiilor atc. BDI presupun, deci înglobarea în cadrul SGBDI a unor puternice facilități de raționament automat. Aceste facilități de inferențiere fac ca BDI să dobândească un caracter dinamic. BDI sunt în mod necesar BD active, cu un comportament relativ autonom, care inițiază acțiuni fără intervenții externe asupra ei.

În sfârșit, SGBDI trebuie să încorporeze o serie de facilități de asistare a procesului de modelare a datelor, precum și facilități de interacțiune cu utilizatorii, atât în ceea ce privește formularea cererilor de date, cât și în explicarea structurii BD și a comportamentului acesteia.

Aceste caracteristici ale BDI le fac extrem de utile în aplicații de o mare complexitate în care volumul, structura și dinamica datelor ridică probleme deosebite în utilizarea bazelor de date convenționale. Caracterul activ al BDI, precum și facilitățile de modelare și de interacțiune cu utilizatorii fac ca efortul de realizare și întreținere a BDI să se distribuie mai echilibrat între om și mașină, decât la BD convenționale.

Se știe că, în prezent factorul uman are responsabilități deosebite în proiectarea, implementarea, exploatarea și întreținerea unei BD, raportul dintre contribuția calculatorului și cea a omului fiind net în favoarea celui din urmă. Cu cât omul este degrevat mai mult de o serie de sarcini, care să fie transferate mașinii, cu atât gradul de inteligență al BD este mai ridicat.

Din prezentarea caracteristicilor BDI se poate constata faptul că realizarea BDI presupune utilizarea mai multor tehnologii informatice, precum: tehnologia bazelor de date, programarea orientată obiect, tehnologii de realizare a raționamentelor automate (de exemplu, programarea logică), tehnologii multimedia etc.

6.2 Arhitectura SGBDI

În ipoteza unei integrări a tehnologiilor prezentate un SGBDI poate fi gândit ca un ansamblu de componente, organizate pe trei nivele și anume:

nivelul instrumentelor de nivel înalt;

nivelul interfeței utilizator;

nivelul de bază (motorul SGBDI).

Figura 6.1 Arhitectura unui SGBDI

Instrumente de nivel înalt oferă utilizatorului o serie de facilități, referitoare la căutarea inteligentă, controlul integrității datelor, calitatea datelor, analiza datelor și descoperirea automată a cunoștințelor etc. În general, acest nivel poate fi organizat ca o bibliotecă externă, pe care unii utilizatori o vor găsi utilă și o vor utiliza, alții nu.

Interfața utilizator reprezintă nivelul cu care interacționează utilizatorul. Acest nivel crează modelul mediului BD, precum și al activității pe care o are de realizat utilizatorul. Asociat acestui nivel există un set de instrumente de reprezentare a acestor modele.

Se pot distinge două nivele ale interfeței utilizator și anume:

nivelul fizic, cel al dispozitivelor de intrare/ieșire;

nivelul cognitiv, cel al modelelor utilizate pentru prezentarea informațiilor, interpretare dată de utilizator acestor informații, formularea intențiilor utilizatorului.

O interfață trebuie să fie transparentă, în sensul ca utilizatorul trebuie să se concentreze asupra a ceea ce are de făcut și nu asupra modului în care poate comunica acest lucru mașinii.

De asemenea, interfața trebuie să fie naturală, compatibilă cu stilul de lucru și cu așteptările utilizatorului.

Realizarea unei interfețe utilizator inteligența presupune utilizarea mai multor medii de comunicare între utilizator, cu implicații asupra modului de formulare a cererilor de date și a actualizărilor, lucrul cu obiecte reprezentate direct în interfață și nu indirect, prin anumite limbaje de comandă.

Motorul SGBDI conține instrumentele prin care datele sunt reprezentate și utilizate într-o manieră deductivă. Aceste instrumente sunt mecanismele inferențiale, compilatoarele pentru optimizare etc.

Motorul SGBDI reprezintă componenta care asigură funcționarea efectivă a SGBDI, conferindu-i acestuia atributul de inteligență menționat în denumire. Motorul SGBDI-ului permite reprezentarea datelor, astfel încât acestea să reflecte cât mai bine realitatea modelată și să poată fi utilizate cât mai eficient, într-un mod “inteligent”.

CAPITOLUL VII

APLICAȚIA PRACTICĂ

BAZE DE DATE PRIVIND APROVIZIONAREA CU MATERIALE A UNEI SOCIETĂȚI COMERCIALE

Baza de date este structurata pe următoarele fișiere:

1.NOMENCLATOR MATERIALE cu structura:

cod material;

denumire;

unitate de măsură;

preț;

2.TRANZACȚII cu structura:

cod material;

tip operație, cu valorile:

intrare {I};

ieșire {O} ;

3.STOCURI cu structura:

cod material;

cantitate (stoc inițial);

stoc final;

stoc de siguranță (minim);

Aplicația permite actualizarea interactivă a nomenclatorului de materiale și a fișierului de tranzacții iar pe baza acestora se determină stocurile.

Se obțin următoarele rapoarte:

Balanța mișcării materialelor:

Cod material:…., Denumire:…., Pret:…., Stoc initial:…. .

Stoc final:…. .

2. Situația materialelor de aprovizionat (cele care sunt sub stocul minim)

BIBLIOGRAFIE SELECTIVĂ

1 A. Abdellatif, A.Zeroual. INFORMIX, le SGBD relationnel sous UNIX, Editura Eyrolles, 1991.

2 A. Aho, J. Ullman. Concepts fondamentaux de l’informatique, Editura Dunod, Paris, 1993.

3 C. Boboilă. Modelarea relațională și obiectuală a informațiilor, Editura Mondo Ec, Craiova, 2003.

4 E. F. Codd. A Relational Data Model for Large Shared Data Banks, Communications of the ACM, 13 (6), iunie 1970, pag. 377-387.

5 E. F. Codd. Relational completeness of data base sublanguages, Data Base Systems, Prentice-Hall, Englewood Cliffs, New Jersey, pag. 65-98.

6 R. Elmasri, S. Navathe. Fundamentals of database systems. Benjamin-Cummings, 1989.

7 G. Gardarin. Bases de Données: les systèmes et leurs langages, Editura Eyrolles,1992.

8 I. Lungu, C. Bodea, G. Bădescu, C. Ioniță. Baze de date. Organizare, proiectare și implementare, ALL Educațional, București, 1995.

9 Gr. Moldovan. Modelul relațional pentru baze de date, Metodologii și tehnici moderne de proiectare și scriere a programelor, București, 1981.

10 N. Țăndăreanu. Introducere în programarea logică. Limbajul Prolog. Editura Intarf, 1994.

11 L. Țîmbulea. Structuri de date și bănci de date, Univ. “Babeș-Bolyai” Cluj-Napoca, 1994.