TEHNOLOGIA SISTEMELOR INFORMATICE ECONOMICE

TEHNOLOGIA SISTEMELOR INFORMATICE ECONOMICE

2.1. Organizarea datelor

2.1.1. Niveluri de organizare a datelor

Prin date întelegem valori ce pot fi stocate si care au semnificatie implicita. Ca exemplu, sa consideram numele, numarul de telefon, adresa persoanelor cunoscute. Se pot tine toate aceste informatii într-un carnet indexat alfabetic, sau pe o discheta într-un calculator personal utilizând programe specializate pentru aceasta.

Organizarea datelor presupune definirea si structurarea datelor în memoria interna sau în memoria externa (în colectii) si stabilirea legaturilor între date, conform unui model de date.

O structura de date defineste un grup de date (omogene sau eterogene) între care s-au stabilit o serie de legaturi în scopul realizarii unor mecanisme de identificare, selectie si prelucrare a componentelor acestui grup.

Organizarea datelor în structuri se realizeaza pe doua nivele: logic si fizic. Procesul de prelucrare a datelor (mai ales când acestea sunt de volum mare) impune necesitatea ca acestea sa fie uniform structurate, conform unor modele - nivelul logic. La nivel fizic forma de organizare si conservare a datelor este fisierul, care permite stocarea, identificarea si consultarea datelor memorate pe suporturile de stocare. Fiecare fisier cuprinde un grup de elemente numite înregistrari, articole (record). Înregistrarea este o entitate semantica care asociaza (prin legaturi) date de tip diferit, conform modelului de organizare utilizat.

Într-un calculator datele sunt stocate în memoria interna (temporar) si în memoria externa (persistent).

În memoria externa, evolutia modului de memorare a datelor a fost determinata de:

Accesul cât mai rapid si usor la date;

Stocarea unui volum cât mai mare de date;

Cresterea complexitatii datelor;

Perfectionarea echipamentelor de culegere, stocare, transmitere si prelucrare a datelor.

Evolutia organizarii datelor în memoria externa a avut în vedere câteva aspecte, tabelul 2.1.

Uzual datele sunt pastrate sub forma de înregistrari. O înregistrare este o colectie a valorilor datelor relationale, în care fiecare valoare este formata din unul sau mai multi bytes si corespund unui câmp particular al înregistrarii. Un câmp este o structura de date asociata grupurilor de înregistrari. Înregistrarile descriu entitati tip, valorile din câmpuri atributele lor, între înregistrari existând o serie de relatii.

Evolutia organizarii datelor în memoria externa

Tabelul 2.1.

Ca exemplu, înregistrarile corespunzatoare entitatii ANGAJAT, sunt formate din mai multe câmpuri, fiecare valoare a câmpului specifica aceleasi atribute sau relatii ale entitatii angajat cum sunt Nume, Salariu, etc. O colectie a numelor câmpurilor, împreuna cu tipul datelor corespunzatoare formeaza o înregistrare tip, sau format. O data tip asociata fiecarui câmp indica tipul valorilor câmpului respectiv.

Tipul de date pentru un câmp poate fi unul din tipurile standard utilizate în programare. Sunt astfel incluse date de tip numeric (întreg, real, real lung), caracter sau sir de caractere (de lungime fixa sau variabila), boolean (având valoarea 0 sau 1 logic, respectiv "false" sau "true"), precum si alte tipuri speciale de date, ca data calendaristica, variabile memorate etc. Numarul de bayti pentru fiecare data tip poate fi fixat sau este variabil pentru câmpurile de lungime variabila.

Una dintre schemele clasice de reprezentare a evolutiei organizarii datelor în aplicatiile complexe este cea din figura 1. Cele cinci elemente arhitecturale au fost înglobate, treptat, în "stratul" baza de date, trecând astfel în sarcina programatorilor. Prima etapa este repre­zentata de sisteme care utilizeaza modelul file-based (pre-baze de date), a doua - modelul retea, a treia - modelul relational, iar ultima, în curs de maturizare, este etapa SGBD-urilor orientate pe obiecte. Schemei i se poate reprosa absenta unui model important, din care a derivat cel de retea, si anume modelul ierarhic.

DATE FIsIERE PRELUCRĂRI IEsIRI

Fig.2. 2. Organizarea datelor în fisiere independente

Spre exemplu, Data2 este pre­zenta în doua fisiere de date, FIsIERl si FIsIER2. Daca, prin program, se modifica formatul sau valoarea acesteia în FIsIERl, modificarea nu se face automat si în FIsIER2; prin urmare, o aceeasi data, Data2, va prezenta doua valori diferite în cele doua fisiere, iar necazurile bat la usa: informatiile furnizate de sistemul informatic sunt redundante si pre­zinta un mare risc de pierdere a coerentei.

Acestui model de lucru i se pot imputa câteva dezavantaje majore, printre care:

o       redun­danta si inconsistenta datelor;

o       dificultatea accesului;

o       izolarea datelor;

o       complexitatea deosebita a actualizarilor;

o       probleme de securitate;

o       probleme legate de integritatea datelor;

o       imposi­bilitatea de a obtine raspunsuri rapide la probleme ad-hoc simple;

o       costul ridicat;

o       inflexibili­tatea fata de schimbarile ulterioare, ce sunt inerente oricarui sistem informational;

o       modelarea inadecvata a lumii reale.

Se poate defini un fisier ca o colectie de înregistrari, eventual similare ce tine cont de modul de stocare a datelor în calculator. Daca toate înregistrarile au exact aceeasi marime (în bytes), fisierul se spune ca este cu înregistrari de lungime fixa. Daca înregistrarile aceluiasi fisier au marimi diferite se spune ca fisierul este cu înregistrari de lungime variabila.

Fisierele cu înregistrari de lungime fixa sunt fisiere în care fiecare înregistrare contine aceleasi câmpuri în aceeasi ordine, fiecare câmp fiind identificat dupa pozitia sa fata de primul byte al înregistrarii (fig. 2.3). Desigur ca se pot reprezenta înregistrari de lungime variabila sub forma de înregistrari de lungime fixa daca în câmpurile optionale se va stoca valoarea speciala null, iar la câmpurile cu date de lungime variabila baitii neocupati vor avea valoarea speciala null.

12 14 30 39 48 52 61 66

Fig. 2.3. Înregistrare de lungime fixa

În fisierele cu înregistrari de lungime variabila fiecare înregistrare are valori pentru fiecare câmp, întrucât tot nu se cunoaste lungimea exacta a câmpurilor. Pentru a se determina pozitia si marimea fiecarui câmp se utilizeaza caracterele speciale de separatie între câmpuri (cum sunt !,%,$ @).

Fisierele cu înregistrari având lungime variabila pot fi formate în diverse moduri. Un mod de formare a unor astfel de înregistrari, este de a se pastra grupul câmpurilor cu aceeasi lungime fara separatori între câmpuri si grupul câmpurilor ce contin date de lungime variabila, fiind separate prin caractere speciale (fig. 2.4.a). Un alt mod este cel care încearca sa rezolve problemele câmpurilor optionale al caror nume variaza de la înregistrare la înregistrare, nume ce este specificat urmat de valoarea asociata acestui câmp în înregistrarea respectiva, asa cum se vede în figura 2.4.b.

Nume  SSN Salariu Dat_n Dep_nume a)

I Popescu Ion %I xxxxxxxxx I xxxx Ixx/xx/xx I Cercetare I%I

I NUME=Popescu Ion I%I SSN=123456789 I%I Depart=Cercetare I@I  b)

in care s-au folosit simbolurile I%I separator câmpuri

I@I separator înregistrari

Fig. 2.4 Înregistrari de lungime variabila

Fisierele ce contin mai multe tipuri de înregistrari necesita programe de aplicatie mult mai sofisticate. Pentru a facilita prelucrarea fisierelor de date cu mai multe tipuri de înregistrari o buna tehnica este cea de marcare la fiecare înregistrare a tipului sau.

Orice fisier este identificabil prin informatiile continute în eticheta de fisier. Se cunosc doua moduri de organizare a informatiilor în fisier:

organizare definita (fisier logic)

organizare nedefinita (fisier fizic).

Fisierul este tratat de sistemul de gestiune a fisierelor ca o colectie de înregistrari fizice organizate conform unei strategii cunoscute numai utilizatorului. Accesul la un fisier cu organizare nedefinita are ca obiect obtinerea unor înregistrari fizice.

Modul de organizare a datelor reprezinta de fapt modul de dispunere a înregistrarilor pe suportul fizic si presupune reguli de memorare a datelor.

Alegerea metodei de organizare va determina performantele relative ale sistemului. Deci, este necesara evaluarea metodei de organizare corespunzator unor criterii de baza:

stocarea unor cantitati mari de date;

accesul usor la date;

economia de spatiu la stocarea informatiilor;

fiabilitatea si protectia datelor;

capacitatea de reprezentare a structurilor lumii reale.

Se cunosc urmatoarele moduri de organizare

a) Standard, este cel mai vechi mod de organizare si exista pe toate tipurile de calculatoare, înregistrarea este formata dintr-un sir de caractere dispus pe o linie acceptata de periferic si toate limbajele recunosc fisiere standard de intrare si iesire.

b) Clasica (elementara) - organizarea se face pe medii magnetice sau optice.

Tipuri de organizare

     SECVENŢIALĂ

1. Înregistrarile sunt dispuse în fisier una dupa alta fara nici o ordine prestabilita.

2. Localizarea unei înregistrari se face prin parcurgerea tuturor înregistrarilor anterioare ei (secvential).

3. Toate sistemele de operare si limbajele de programare accepta organizarea secventiala.

Fisierul secvential (sequential file) este caracterizat de faptul ca înregistrarile de date sunt organizate într-o secventa specifica, iar aceleasi atribute sunt continute la toate înregistrarile în aceiasi ordine. Numele atributelor apar doar în descrierea fisierului. Valorile lor au asociate aceleasi nume, si ar corespunde unor coloane la o organizare tabelara. Înregistrarile în fisier pot fi ordonate dupa atributele cheie. Un atribut determina sortarea primara a fisierului, obtinând un grup de înregistrari ce vor fi sortate dupa un alt atribut, pâna când ordonarea este definitiva. Daca exista un atribut cheie fisierul poate fi ordonat dupa acesta.

Fisierele secventiale prezinta o serie de avantaje privind accesul eficient la înregistrari datorita înregistrarilor deja ordonate, accesul facil la înregistrarea urmatoare, posibilitatea de aplicare a metodelor de cautare binara.

     RELATIVĂ

v     Înregistrarile sunt dispuse în fisier una dupa alta si numerotate (de catre sistem) de la 0 sau 1 la câte sunt (numar de realizare)

v     Localizarea unei înregistrari se poate face secvential sau direct prin numarul de realizare.

     INDEXAT-SECVENŢIALĂ

Înregistrarile sunt dispuse în fisier în ordine strict crescatoare dupa o cheie (face parte din înregistrare).

Cheia este unul sau mai multe câmpuri care identifica în mod unic o înregistrare.

Fisierului îi este atasat o tabela de indecsi care face legatura între valoarea cheii si adresa fizica a înregistrarii.

Localizarea unei înregistrari se poate face secvential dar si direct prin cheie:

se compara cheia înregistrarii cautate cu indecsii din tabela de index si se localizeaza direct partea fizica a fisierului în care se afla înregistrarea cautata;

în partea fizica localizata se face o cautare secventiala a înregistrarii dorite.

c) Speciala (complexa), se bazeaza pe modurile de organizare clasice si sunt utilizate în baze de date si în sisteme de fisiere.

Tipuri (câteva):

PARTIŢIONAREA

Înregistrarile din fisier sunt grupate în partitii sub un nume.

În cadrul unei partitii înregistrarile sunt organizate secvential.

Se utilizeaza în biblioteci de programe

MULTIINDEXAREA

Este o extindere a indexarii prin utilizarea mai multor chei alese de programator.

Spatiul ocupat este mai mare

Se utilizeaza pentru fisiere care necesita regasiri intense multicriteriale.

INVERSĂ

Presupune existenta a doua fisiere: de baza si invers.

Fisierul de baza contine datele propriu-zise si are organizare secventiala. El este fisierul în care se cauta.

Fisierul invers este construit din cel de baza (printr-o tehnica de inversare) si are organizare relativa. El este fisierul prin intermediul caruia se cauta.

Spatiul ocupat necesar este cam de 3,5 ori mai mare fata de cât ocupa fisierul de baza.

Modul de acces este modul în care se determina locul ocupat de o înregistrare într-un fisier si depinde de modul de organizare.

Tipuri de moduri de acces:

     SECVENŢIAL = localizarea unei înregistrari se face prin parcurgerea tuturor înregistrarilor care o preced.

Este permis accesul secvential pentru toate tipurile de fisiere.

Se recomanda pentru fisierele din care sunt necesare, la o prelucrare, peste 50% din numarul total de înregistrari.

Pentru optimizare se recomanda ordonarea fisierului.

     DIRECT = localizarea unei înregistrari se face cu ajutorul unei chei definite de programator.

Nota. Accesul direct se poate face dupa numarul de realizare sau dupa o valoare a cheii.

     DINAMIC = la o singura deschidere de fisier se pot localiza, alternativ si repetat, înregistrari în acces secvential si direct.

O alta organizare primara ce asigura un acces rapid la înregistrari dupa criterii specificate este cea utilizând tehnica hash. În anumite situatii se foloseste termenul de acces direct, indicând accesul relativ prin pozitia înregistrarii. Criteriul de cautare este dat de egalitatea conditiei la un singur câmp numit si câmp hash, care este un câmp cheie, numit si cheie hash. Înregistrarile sunt organizate în grupuri ce ocupa unul sau mai multe blocuri. Functia hash aplicata câmpului cheie produce un întreg ce indica adresa blocului în care înregistrarea dorita este stocata, daca aceasta exista. Blocul respectiv este transferat în buffer, cautarea înregistrarii în cadrul blocului transferat în memorie fiind realizata prin metode de cautare liniara.

Trebuie facuta distinctia neta între organizarea fisierului si metoda de acces. Prin organizare fisier (file organization) se întelege organizarea datelor în înregistrari, blocuri si structuri de acces. Prin metoda de acces (acces metod) se întelege grupul de programe ce permite aplicarea operatiilor de mai sus asupra fisierului. În general metodele de acces sunt dependente de organizarea fisierului.

Inserarea într-un fisier este o sarcina mult mai complexa decât citirea datelor din fisierul respectiv. Adaugarea unor noi înregistrari este foarte facila daca aceasta presupune plasarea înregistrarii la sfârsitul fisierului. Daca însa inserarea se face într-o anumita pozitie este necesara localizarea acestei pozitii conform criteriului de ordonare, urmata de deplasarea înregistrarilor pentru a face loc înregistrarii inserate. Operatia presupune citirea mai multor blocuri, urmata de rescrierea lor. În anumite situatii eficienta inserarii poate fi crescuta prin utilizarea blocurilor overflow. Reorganizarea fisierului dupa modificarea unor înregistrari sau ca urmare a inserarii de noi înregistrari este în general o operatie ce se efectueaza off-line. Este mare consumatoare de timp necesitând de multe ori citirea întregului fisier, reorganizarea si scrierea acestuia.

În multe aplicatii este necesara citirea întregului fisier. Este de preferat organizarea sub forma de fisier dens, care fata de fisierele risipite si cele redondante, are avantajul volumului mai mic, implicând astfel si un timp de acces mai mic. Aplicatiile tipice necesitând citirea întregului fisier sunt cele prin care se efectueaza operatii de selectie date dupa anumite criterii sau operatii statistice.

2.1.3. Operatii cu fisiere de date

Operatiile specifice asociate fisierelor de date sunt în general grupate în cele doua categorii "retrieve" si "update". Accesul la una sau mai multe înregistrari se face pe baza unui criteriu de selectie ce specifica care conditii trebuiesc satisfacute de acestea. Daca vom considera fisierul entitatii tip ANGAJAT ce contine câmpurile definite mai sus, un criteriu de selectie poate invoca egalitatea valorii unui câmp cu o valoare constanta, operatii de ordine (>, <), precum si combinatii logice ale acestora. Daca mai multe înregistrari satisfac criteriul prima înregistrare din sirul acestora este localizata, trecerea la alte înregistrari ce satisfac acest criteriu se face invocând operatii aditionale. Ultima înregistrare localizata poarta numele de înregistrare curenta. O operatie de localizare ulterioara începe de la înregistrarea curenta, modul de implementare a operatiei de localizare difera de la un sistem la altul.

Cum asupra fisierelor de date sunt necesare o serie de operatii, se dau mai jos câteva dintre cele mai importante.

Find (Locate) operatie de cautare a primei înregistrari ce satisface criteriul de acces. Pentru aceasta se detecteaza mai întâi blocul în care aceasta se gaseste, dupa care înregistrarea respectiva devine înregistrare curenta. Operatia necesita transferul de blocuri în memoria interna.

Read (Get) operatia de copiere din buffer într-o variabila program sau zona de lucru pentru utilizator a unei înregistrari. Ca urmare a acestei comenzi se poate avansa la înregistrarea urmatoare. Este posibil ca read sa invoce mai întâi o operatie de tip find.

Find next operatie de cautare a urmatoarei înregistrari ce satisface criteriul de selectie. Operatia presupune citirea unui nou bloc daca înregistrarea nu exista în blocul curent. Noua înregistrare devine înregistrare curenta.

Delete stergere a înregistrarii curente sau a grupului de înregistrari ce satisfac criteriul de selectie, si eventual rearanjarea fisierului pe disc pentru a reflecta aceasta modificare. Se remarca faptul ca în multe situatii operatia 'delete' nu face stergerea efectiva, ci doar marcarea acelor înregistrari pentru a fi sterse.

Modify modifica valorile câmpurilor în înregistrarea curenta sau în înregistrarile ce satisfac criteriul de selectie, si eventual se reflecta aceasta în fisierul stocat pe disc.

Insert este operatia de adaugare a noi înregistrari în fisierul de date, localizând blocul unde înregistrarile vor fi inserate, transfera blocul în bufferul intern (daca nu este aici), înscrie înregistrarea în buffer, scrie bufferul pe disc pentru a reflecta aceasta modificare. Operatia poate afecta si alte blocuri ale fisierului de date si ca urmare operatia poate fi mare consumatoare de timp.

Operatiile de mai sus se efectueaza înregistrare cu înregistrare sau în grupuri de înregistrari. O serie de operatii aditionale vizând întregul fisier sunt posibile:

Find all operatie de localizare a tuturor înregistrarilor ce satisfac criteriul de selectie.

Find ordered operatie de prezentare a tuturor înregistrarilor din fisier în ordinea specificata prin criteriul de selectie.

Reorganize este operatia de reorganizare a fisierului ce se executa periodic, operatie ce priveste eliminarea înregistrarilor marcate la stergere, renumerotarea înregistrarilor dupa o operatie de sortare.

Doua operatii foarte importante privind pregatirea accesului la fisier sunt operatiile Open pentru deschiderea fisierului, respectiv Close pentru închiderea fisierului.

2.2. Baze de date

2.2.1. Definire, caracteristici

În prezent, agentii economici manipuleaza un volum foarte mare de informatii. Suportul principal prin care se transmit, se prelucreaza si se memoreaza informatiile îl reprezinta datele. Informatia se obtine din date prin diverse asocieri, prelucrari si interpretari ale acestora. În vederea prelucrarii rapide si eficiente a datelor, acestea trebuie organizate si structurate în colectii de date.

O baza de date este o colectie centralizata de date organizata în scopul optimizarii prelucrarii acestora în contextul unui set dat de aplicatii.

Definirea notiunii de baza de date trebuie sa tina cont de urmatoarele elemente:

gruparea datelor în fisiere de date;

descrierea legaturilor (asocierilor) între fisiere (fisier de descriere globala a datelor);

suportul fizic (hardware) pentru conservarea si prelucrarea interactiva a datelor;

sistemul de programe pentru descrierea structurii datelor astfel încât sa fie posibila actualizarea si securizarea acestora (Sistemul de Gestiune a Bazelor de Date = SGBD);

Utilizatorii bazei de date.

Notiuni (elemente) comparative între organizarea datelor în fisiere si baze de date:

sistem de fisiere fisiere înregistrari câmpuri valori

lumea reala

baza de date colectii de date familie de caracteristici domenii

(entitati) caracteristici de valori

Domeniul de valori= multimea valorilor posibile pentru o caracteristica (ex.: culorile posibile pentru un automobil).

Caracteristica= definirea si descrierea unui anumit aspect(proprietati) dintr-o entitate a lumii reale (ex.:marca auto)

Familia de caracteristici=ansamblul caracteristicilor care se refera la aceeasi entitate din lumea reala (ex.: multimea caracteristicilor prin care se poate descrie un automobil ).

Colectia de date(entitatea)=o familie de caracteristici asupra careia se aplica un predicat (care conduce la o relatie de ordine între caracteristici si la obtinerea informatiilor cu un anumit sens) caruia i se afecteaza anumite legaturi.

Conceptul de "baza de date" a aparut în 1969 cu ocazia prezentarii raportului CODASYL în cadrul unei conferinte legate de folosirea limbajelor de gestiune a datelor.

Baza de date poate fi definita ca un ansamblu de date stocate în unul sau mai multe fisiere de date, aflate în interdependenta, împreuna cu descrierea datelor si a relatiilor între ele.

Ideea principala este legata de necesitatea accesului oricarui utilizator la date, ceea ce impune realizarea independentei programelor (aplicatiilor) fata de date si a datelor fata de programe.

2.5. Reprezentarea bazei de date

Baza de date, astfel definita, trebuie sa îndeplineasca urmatoarele conditii:

. structura bazei de date trebuie sa fie astfel conceputa încât sa asigure informatiile necesare si suficiente de acces;

. sa asigure o redundanta minima si controlata a datelor;

. sa asigure accesul rapid la datele stocate;

. sa asigure independenta datelor fata de programele de prelucrare si invers.

Orice baza de date are urmatoarele proprietati implicite:

o baza de date este o colectie logica coerenta de date ce are cel putin un înteles.

baza de date este destinata, construita, si populata cu date despre un domeniu bine precizat. Ea are un grup inerent de utilizatori si se adreseaza unui anumit grup de aplicatii.

o baza de date reprezinta câteva aspecte ale lumii reale creând orizontul propriu. Schimbarile orizontului sunt reflectate în baza de date.

Fata de modelul file-based, noutatea o constituie existenta unui fisier de descriere globala a bazei, astfel încât sa se poata asigura independenta programelor fata de date, dupa cum o arata si figura 2.6.

Fig.2.6. Schema de principiu a unei baze de date

Avantajele organizarii informatiilor în baze de date decurg tocmai din existenta acestui fisier de descriere globala a bazei, denumit, în general, dictionar de date (cunoscut si ca repertoar de date sau catalog de sistem). Extragerea si modificarea datelor, altfel spus, lucrul cu fisierele de date, se deruleaza exclusiv prin intermediul dictionarului în care se gasesc informatii privitoare la structura datelor si restrictiile îndeplinite de acestea. Iata câteva dintre avantaje acestui mod de lucru:

un grad redus de redundanta si inconsistenta a datelor;

facilitarea partajarii informatiilor între toti utilizatorii acestora din cadrul organizatiei;

suport pentru standardizarea si securitatea informatiilor;

structurile de date sunt mai aproape de realitate si mai usor de manipulat;

întreprinderea poate fi abordata global, luându-se în considerare si interactiunile dintre compartimente (productie, marketing, personal, finante, contabilitate);

datele fiind separate de programele de consultare si actualizare a lor, procesul de dezvoltare a aplicatiilor-program este sensibil ameliorat, efortul de scriere a pro­gramelor (codarea) diminuându-se considerabil;

sistemele informatice ce utilizeaza baze de date sunt mai flexibile, reflecta mai bine specificul firmei, fiind adaptabile la modificarile ulte­rioare ale mediului economic.

O baza de date (BD) reprezinta un ansamblu structurat de fisiere, care grupeaza datele prelucrate în aplicatiile informatice ale unei persoane, grup de persoane, întreprinderi, insti­tutii etc. Formal, BD poate fi definita ca o colectie de date aflate în interdependenta, împre­una cu descrierea datelor si a relatiilor dintre ele sau o BD reprezinta o colectie de date utilizata într-o organizatie, colectie care este automatizata, partajata, definita riguros (for­malizata) si controlata la nivel central.

Bazele de date evolueaza în timp, în functie de volumul si complexitatea proceselor, fenomenelor si operatiunilor pe care le reflecta. Ansamblul informatiilor stocate în baza la un moment dat constituie continutul sau instantierea sau realizarea acesteia.

Organizarea bazei de date se reflecta în schema sau structura sa, ce reprezinta un ansamblu de instrumente pentru descrierea datelor, a relatiilor dintre acestea, a semanticii lor si a restrictiilor la care sunt supuse. în timp ce volumul prezinta o evolutie spectaculoasa în timp, schema unei baze ramâne relativ constanta pe tot parcursul utilizarii acesteia.

O baza de date poate fi de diverse marimi si complexitati. De exemplu, lista numelor, adreselor si numerelor de telefon pastrate de o persoana particulara poate avea sute de înregistrari fiecare cu o structura simpla. Pe de alta parte catalogul cartilor într-o mare biblioteca poate contine pâna la o jumatate de milion de înregistrari stocate în diverse moduri; ordonate dupa numele primului autor, dupa subiect sau dupa titlul cartii.

Definirea bazei de date presupune specificarea tipurilor de date ce vor fi stocate în baza de date, precum si descrierea detaliata a fiecarui tip de data. Prin manipulare se înteleg o serie de functii ce faciliteaza implementarea cererilor pentru gasirea datelor specificate, adaugarea de noi date ce reflecta modificarea contextului, generarea de rapoarte pe baza continutului bazei de date.

O caracteristica importanta a bazelor de date este aceea ca pot contine pe lânga datele propriu-zise si definitii sau descrieri. Definitiile sunt stocate în catalogul sistemului (system catalog) si contine informatii despre structura fiecarui fisier sau tabele, tipul si formatul de stocare a fiecarei date, diverse restrictii referitoare la date. Informatiile stocate în catalog se mai numesc si meta-data, si descriu structura bazei de date primare.

În prelucrarea datelor traditionala structura datelor se reflecta în procedurile asociate programelor de acces, asa ca schimbarea structurii fisierelor de date va determina schimbarea procedurilor de acces. În opozitie, programele DBMS de acces sunt oarecum independente de tipul datelor (se va vedea mai târziu în ce sens), asigurând astfel independenta programelor de date. Daca se modifica atributele unor înregistrari aceasta se reflecta în catalog, nu în programe. Aceasta independenta este totala atunci când tipul de data nu se modifica, dar se modifica formatul. În orice caz si în alte cazuri implicatiile sunt minore.

O baza de date poate avea mai multe utilizari, fiecare utilizator poate privi datele din mai multe unghiuri. Un subset al bazei de date poate fi format din date derivate ce nu sunt explicit stocate în fisiere.

În orice organizatie unde mai multe persoane utilizeaza aceleasi resurse este necesar un manager care administreaza aceste resurse. În mediul bazelor de date resursa primara este formata din datele însasi, resursa secundara este DBMS si programele aferente. Administrarea resurselor este sarcina database administrator (DBA), care este responsabilul autorizarii accesului la baza de date, a coordonarii si monitorizarii utilizatorilor sai.

Constructorii bazei de date (database designers) se ocupa de identificarea datelor ce se stocheaza în baza de date, de alegerea structurii de reprezentare si stocare a datelor. Aceste activitati se desfasoara înainte ca baza de date sa fie implementata. Constructorii bazei de date stabilesc cu potentialii utilizatori modul de acces la date si cererile de prelucrare ale fiecarui grup de utilizatori. În final proiectantii bazei de date sunt capabili sa rezolve cererile tuturor grupurilor interesate în utilizarea bazei de date. Persoanele care cer accesul la baza de date pentru modificare, generare de rapoarte, din baza de date primara apartin mai multor categorii, categorii ce pot fi grupate în:

casual users; utilizatori ocazionali ce pot cere informatii diferite la fiecare acces. Ei formuleaza cereri sofisticate si sunt în general programatori de nivel înalt.

naive or parametric users; acei utilizatori ce formuleaza cererile utilizând formularile standard ce au fost programate si testate. Un exemplu ar putea fi balantele de venituri si cheltuieli, stocuri în depozite. O categorie distincta este cea a cererilor de rezervare a biletelor de avion, spectacole, hotel.

sophisticated users; includ personalul specializat care cu ajutorul DBMS rezolva cereri complexe.

2.2.2. Niveluri de abstractizare a datelor

Una din caracteristicile fundamentale a bazelor de date este data de faptul ca produce câteva niveluri de abstractizare a datelor, prin ascunderea detaliilor legate de stocarea datelor, detalii ce nu sunt utile pentru operatorii cu baza de date. Se defineste modelul datelor ca un set de concepte ce poate fi utilizat in descrierea structurii datelor. Prin structura bazei de date se întelege tipul datelor, legatura dintre ele, restrictiile ce trebuiesc îndeplinite de date. Cele mai multe baze de date includ un set de operatii ce specifica modul de acces la date.

Informatia, care se reprezinta în calculator în memoria interna sau externa, se poate defini structural dupa schema:

are ca are ca are ca

INFORMAŢIA ENTITATEA ATRIBUTUL VALOAREA

obiect proprietate (CARACTERISTICA) masura

Modelul de structura = descrierea tuturor atributelor unei entitati în interdependenta. Valorile atributelor se materializeaza prin date, care dau o reprezentare simbolica a informatiilor.

Modelul de date = ansamblul de conceptie si instrumente pentru a realiza schema conceptuala a datelor.

Schema conceptuala = descrierea fenomenelor din realitatea înconjuratoare prin entitati si atribute, împreuna cu toate corelatiile (legaturile) dintre ele.

Definirea schemei este o activitate de modelare pentru ca traduce în termeni abstracti entitatile lumii reale.

Într-un sistem informatic ce utilizeaza BD, organizarea datelor poate fi analizata din mai multe puncte de vedere si pe diferite paliere. De obicei, abordarea se face pe trei niveluri: fizic sau intern, conceptual sau global si extern (fig.2.7.).

Fig. 2.7. Modele de date

Nivelul fizic (sau intern).

Structura datelor este descrisa foarte detaliat, fiind accesibila numai specialistilor (ingineri de sistem, programatori în limbaje de asamblare sau alte lim­baje apropiate de "masina"). Cele doua parti principale ale bazei la acest nivel sunt:

1) un set de programe care interactioneaza cu sistemul de operare pentru îmbunatatirea manage­mentului bazei de date

2) fisierele stocate în memoria externa a calculatorului.

Fisierele ce contin datele propriu-zise sunt alcatuite din articole sau înregistrari cu format comun. La acest nivel, structura BD se concretizeaza în schema interna.

Nivelul conceptual (sau global)

Este nivelul imediat superior celui fizic, datele fiind privite prin prisma semanticii lor; intereseaza continutul lor efectiv, ca si relatiile care le leaga de alte date. Reprezinta primul nivel de abstractizare a lumii reale observate. Obiecti­vul acestui nivel îl constituie modelarea realitatii considerate, asigurându-se independenta bazei fata de orice restrictie tehnologica sau echipament anume. întreaga baza este descrisa prin intermediul unui numar restrâns de structuri. Toti utilizatorii îsi exprima nevoile de date la nivel conceptual, prezentându-le administratorului bazei de date, acesta fiind cel care are o viziune globala necesara satisfacerii tuturor cerintelor informationale. La acest nivel, structura BD se concretizeaza în schema conceptuala.

Nivelul extern

Este ultimul nivel de abstractizare la care poate fi descrisa o baza de date. Structurile de la nivelul conceptual sunt relativ simple, însa volumul lor poate fi deconcertant. Iar daca la nivel conceptual baza de date este abordata în ansamblul ei, în practica un utilizator sau un grup de utilizatori lucreaza numai cu o portiune specifica a bazei, în functie de departamentul în care îsi desfasoara activitatea si de atributiile sale (lor). Simplificarea interactiunii utilizatori-baza, precum si cresterea securitatii bazei sunt deziderate ale unui nivel superior de abstractizare, care este nivelul extern. Astfel, structura BD se prezinta sub diferite machete, referite uneori si ca sub-scheme, scheme externe sau imagini, în functie de nevoile fiecarui utilizator sau grup de utilizatori.

Luând în considerare cele trei niveluri de abstractizare, schematizarea unui sistem de lucru cu o baza de date se poate face ca în figura 2.8[1].

Este importanta aceasta organizare pe trei niveluri pentru ca explica conceptul de independenta a datelor, prin posibilitatea de modificare a sistemului bazei de date la orice nivel fara a avea influenta la nivelele superioare. Independenta datelor se poate defini în doua moduri, ce sunt aferente nivelelor conceptual si intern.

Prin independenta logica se întelege capacitatea schimbarii schemei conceptuale fara a atrage dupa sine schimbari in schema externa sau în programele de aplicatii. Este posibila schimbarea schemei conceptuale prin expandarea bazei de date ca urmare a adaugarii de noi tipuri de înregistrari sau a datelor însasi, sau prin reducerea bazei de date ca urmare a reducerii înregistrarilor. Schema conceptuala dupa aceste operatii se refera la schema conceptuala a datelor existente.

Fig.2.8. Schematizarea unui sistem de lucru cu o baza de date

Independenta fizica este reprezentata prin capacitatea de schimbare a schemei interne fara schimbarea schemei conceptuale sau externe. Schimbarea schemei conceptuale poate surveni ca urmare a reorganizarii fizice a unor fisiere, prin crearea de noi structuri de acces menite sa asigure accesul eficient la date.

Accesul utilizatorului la informatiile din baza este posibil numai prin intermediul sistemului de gestiune a bazei de date (SGBD). În general, interfata utilizator-SGBD se poate realiza în doua moduri: printr-un mecanism de apel (cuvânt-cheie, ca de exemplu CALL) inserat în programele scrise într-un limbaj "traditional" (C, COBOL etc), acesta fiind cazul SGBD-urilor cu limbaj gazda sau prin comenzi speciale utilizate autonom (în afara aplicatiilor-program), în cazul SGBD-urilor autonome.

Modele de structurare a datelor în BD

2.2.3.1. Legaturi între date

Se defineste modelul datelor ca un mod de abstractizare a datelor ce este utilizat pentru reprezentarea conceptuala. Modelul datelor utilizeaza concepte logice despre obiecte, proprietatile lor, relatiile dintre ele. Deci, modelul datelor ascunde detaliile ce nu sunt interesante pentru cei mai multi utilizatori ai bazei de date. Detaliile de reprezentare sunt neesentiale daca referirea la date se poate face direct prin numele acestora.

Când mai multi utilizatori doresc accesul la o baza de date numai unii pot avea acces la toate datele. DBMS va trebui sa asigure accesul autorizat la date. De exemplu, datele financiare sunt considerate confidentiale, si deci, numai persoanele autorizate pot avea acces la ele. In plus un grup de persoane au acces numai la citirea acestor date, pe când alt grup este autorizat sa modifice datele. Accesul este protejat printr-o parola de acces.

Elementele (componentele) oricarui model de date sunt:

definirea structurii modelului (partea structurala):

definirea entitatilor si a atributelor asociate;

definirea legaturilor (asocierea) dintre entitati.

Elementele (numite si realizari) unei colectii de date intra în anumite legaturi (asocieri). Ele pot fi legaturi în cadrul aceleiasi colectii (legaturi interne) sau legaturi între colectii diferite (legaturi externe). De exemplu pentru colectiile de date Produse si Materiale legaturile interne rezulta prin aceea ca mai multe materiale apartin aceluiasi sortiment iar cele externe prin faptul ca mai multe materiale participa la realizarea unui produs, asa cum unul sau mai multe produse se pot obtine pe seama unui singur material.

Fig.2.9. Tipuri de legaturi

Legaturile între realizarile diferitelor colectii de date pot fi binare si n-are.

Legaturile binare sunt determinate de existenta a doua colectii de date numite domeniu si codomeniu (legaturile interne sunt relatii binare la care domeniul si codomeniul sunt identice). Se disting urmatoarele tipuri de legaturi:

. legaturi "unu la unu" (1 - 1 sau biunivoce). Unui element din domeniu îi corespunde un singur element din codomeniu si invers. Exemplu: relatia dintre colectiile de date Studenti si Matricole. O matricola este atribuita unui singur student, iar un student poate beneficia de o singura matricola.

2.10. Legaturi binare

. legaturi "unu la multi" (1- n). Unui element din domeniu îi corespund zero una sau mai multe realizari din codomeniu. De exemplu un student face parte dintr-o singura grupa, o grupa poate avea mai multi studenti.

2.11. Legaturi unu-la mai multi (1-n)

. legaturi "multi la multi" (m - n). Unui element din domeniu îi corespund mai multe realizari din codomeniu corespondenta realizându-se si invers. De exemplu un produs este realizat din mai multe materiale, acelasi material folosindu-se la fabricarea mai multor produse.

2.12. Legaturi multi-la multi (m-n)

Legaturile n-are sunt legaturile prin care sunt asociate mai multe colectii de date (ele pot fi descompuse în legaturi binare). Aceste tip de legaturi este luat în considerare în algebra relatiilor care constituie baza teoretica pentru tratarea bazelor de date relationale.

2.2.3.2. Tipuri de structuri de date si modelele lor de reprezentare

Principalele tipuri de structuri de date care impun modul de organizare al datelor sunt structura liniara, structura arborescenta, structura retea, si structura relationala. Modelele specifice acestora sunt: modelul de reprezentare liniara, modelul ierarhic, modelul retea, modelul relational,modelul orientat obiect.

2.2.3.2.1. Modelul de reprezentare liniara

Structura liniara este definita printr-o relatie de ordine pe un grup de date sub forma denumita lista.

2.13. Structura liniara

Realizarea fizica a modelului este lista, care poate fi asimetrica (când informatia corespunzatoare a fiecarei realizari are asociata adresa urmatoarei realizari sau simetrica (când, la fiecare realizare se asociaza doua adrese: precedenta si urmatoare).

Elementele unei liste sunt înlantuite conform urmatoarelor principii:

a. orice element neterminal al listei are un succesor unic (lista simplu înlantuita);

b. primul element nu are predecesori;

c. ultimul element nu are succesori;

d. daca ultimul element se înlantuie cu primul element lista se numeste lista circulara;

e. daca înlantuirea se defineste si în sens invers (de la fiecare element al listei spre predecesorul sau) lista se numeste lista dublu înlantuita.

Exemplu:

2.14. Structura de tip lista

În scopul optimizarii operatiilor de cautare a informatiilor în lista au fost elaborate structuri de reprezentare liniara specializate: stack (stiva) si queue (coada).

Stiva este o structura asimetrica care permite ca operatiile de adaugare, consultare si stergere sa se poata efectua în capul colectiei de date. Ea este bazata pe principiul LIFO (Last Input First Output), astfel încât ultima realizare adaugata sa fie prima consultata.

Coada este o structura simetrica care permite adaugari la sfârsitul listei si consultari/stergeri la începutul listei. Principiul se numeste FIFO (First Input First Output.

Un fisier de date construit pe baza modelului liniar consta într-o succesiune de înregistrari, de lungime variabila. De exemplu, pentru structura arborescenta prezentata anterior, luând în considerare posibilitatea descompunerii acesteia în structuri liniare, se poate constitui un fisier care contine urmatoarele înregistrari:

(P1,C1) (P1,C2) (P2,M3,Com1) (P2,M3,Com2) (P2,M1,F4) (P2,M1,F3)...

2.2.3.2.2. Modelul ierarhic (arborescent)

Structura arborescenta (ierarhica sau descendenta) este definita printr-o relatie de ordine pe un grup de date astfel:

a. elementele grupului de date se numesc noduri si sunt dispuse pe nivele;

b. exista un singur nod pe primul nivel - nod radacina;

c. orice nod diferit de radacina are un predecesor imediat unic;

d. orice nod neterminal are un numar finit de succesori imediati;

e. legaturile stabilite între noduri sunt de tipul 1 - n (o structura arborescenta definita numai prin legaturi de tip 1 -2 se numeste arbore binar).

2.15. Structura arborescenta

Caracteristici ale structurii ierarhice (arborescente):

Fiecare nod corespunde unui tip de înregistrare si fiecare drum corespunde unei legaturi (asocieri).

Orice acces la un nod se face prin vârful ierarhiei, numit radacina, pe o singura cale.

Un nod subordonat (copil) nu poate avea decât un singur superior (parinte).

Un superior poate avea unul sau mai multi subordonati.

Legatura copil-parinte este doar de tip 1:1 (la o realizare copil corespunde o singura realizare parinte).

Legatura parinte-copil poate fi de tip 1:1 sau 1:M.

În structura exista un singur nod radacina si unul sau mai multe noduri dependente situate pe unul sau mai multe niveluri.

O ierarhie de tipuri de înregistrari se numeste tip arbore.

O realizare a unui tip arbore este formata dintr-o singura realizare a tipului de înregistrare radacina împreuna cu o multime ordonata formata din una sau mai multe realizari ale fiecarui tip de înregistrare de pe nivelurile inferioare.

Ordonarea realizarilor dintr-un arbore conduce la o secventa ierarhica.

2.16. Modelul arborescent (ierarhic)

Aceasta structura se bazeaza pe existenta unei multimi de colectii de date si o multime de legaturi ierarhice. Fiecarui tip de colectie de date i se atribuie un numar de nivel (exista o singura colectie de date de nivel 1 numita radacina). Colectiile de date pe acelasi nivel formeaza o familie de date.

Exemplu:

Modelul de reprezentare arborescenta se poate realiza fizic cu ajutorul unor adrese care indica adresa primei realizari din cadrul colectiei si adresa urmatoarei realizari din cadrul colectiei (organizare FIU, FRATE).

2.17. Exemplu de structura ierarhica

Definirea structurii modelului ierarhic presupune:

Definirea entitatilor se face prin notiune de tip de înregistrare (clasa de entitati), care este formata din caracteristici (câmpuri).

Realizarea (instanta) unui tip de înregistrare este data de ansamblul valorilor pentru câmpurile acesteia (înregistrarea)..

Definirea legaturilor dintre entitati se face fizic si conduce la structura de tip ierarhic (arborescent) reprezentata sub forma unei diagrame (fig. 2.18.).

Fig.2.29. Structura generala a unui SBD

SBD face ca utilizatorul sa utilizeze o reprezentare conceptuala a datelor fara sa includa nici un detaliu asupra modului în care acestea sunt stocate. Deci, SBD include si subsistemul programelor de securitate si autorizare putând crea conturi la care se specifica restrictiile. Este remarcabil faptul ca nu toate mediile de baze de date ofera servicii intrinseci pentru securitate. În general aceste functii sunt specifice administratorului bazei de date, dar este necesar sa fie luate în consideratie si în faza de proiectare a aplicatiei.

SBD trebuie sa includa facilitati de refacere a datelor la defectarile hardware si software (backup). Daca sistemul se defecteaza in timpul operatiei de reactualizare date din baza, aceasta trebuie sa ramâna in forma pe care o avea înainte de operatie, prin crearea copiei acestuia. Facilitati suplimentare sunt asigurate pentru DBMS moderne in ceea ce priveste rollback si respectiv rollforward, facilitati care asigura translatarea bazei înainte si înapoi, pentru o serie de operatii de actualizare. O alta caracteristica importanta este cea de asigurare a caracterului tranzactional in interogarea bazei. Trebuie mentionat ca principalele diferente intre mediile comerciale si cele profesionale sunt cladite pe aceste facilitati si bineînteles caracteristicile legate de viteza de prelucrare.

Un SBD tipic ofera facilitati multiple pentru accesul la baza de date. Utilizatorii naivi pot învata foarte repede facilitatile oferite de SBD, deoarece ei utilizeaza in general numai anumite tipuri standard de tranzactii. Utilizatorii ocazionali învata acele facilitati de acces pe care apoi le folosesc de mai multe ori.

Întrucât categorii de utilizatori au cunostinte diferite în utilizarea bazelor de date, SBD faciliteaza aceasta printr-o varietate de interfete utilizator. Aceste tipuri de interfete includ interpretoare de cereri, limbaje de programare pentru programele de aplicatii, interfete sub forma de meniuri pentru utilizatori nespecializati, interfete în limbaje naturale. O baza de date contine o varietate de date ce sunt în diverse tipuri de relatii. SBD trebuie sa ofere capacitatea reprezentarii unei varietati de relatii complexe, precum si accesul la aceste date relationale într-o maniera eficienta. Este esential ca utilizatorul sa identifice si sa prelucreze date în relatii complexe.

Se vor trece in revista mai jos principalele tipuri de interfete oferite de SBD, interfete ce au ca scop sa faciliteze legatura utilizatorilor cu sistemul de baze de date.

Interfetele bazate pe meniuri ofera utilizatorului o lista de optiuni, numite meniuri ce ii ajuta in formularea cererilor. Nu este necesara memorarea unor comenzi deoarece o comanda specifica este formata pas cu pas prin compunerea optiunilor indicate prin meniu.

Interfetele grafice sunt acele interfete ce afiseaza utilizatorului o diagrama. Utilizatorul poate formula cererea prin manipularea acestei diagrame. In cele mai multe cazuri interfetele grafice sunt combinate cu meniuri. Selectia poate fi usurata la interfetele grafice prin utilizarea light pen sau prin mose in sensul ca astfel se poate alege o parte a diagramei.

Interfete bazate pe casete (form based interfece) sunt interfetele prin intermediul carora utilizatorul poate umple acele forme cu noile date pe care doreste sa le insereze, sau foloseste aceste forme pentru a cere DBMS sa obtina datele de interes. Formele sunt destinate utilizatorilor naivi si nu sunt tranzactionale.

Interfetele in limbaj natural (natural language interfece) accepta cereri scrise in limba engleza sau alte limbi de circulatie internationala. O interfata in limbaj natural contine uzual o schema proprie similara cu schema conceptuala a bazelor de date. Interpretarea cererilor se face pe baza unui set standard de cuvinte cheie ce sunt interpretate pe baza schemei interne. Daca interpretarea se realizeaza cu succes programul de interfata genereaza cererea de înalt nivel corespunzatoare celei in limbaj natural, ce va fi transmisa SBD. Altfel, se initiaza un nou dialog cu utilizatorul pentru a se clarifica.

Interfete specializate (interfeces for parametric users) aferente cererilor repetate de acelasi tip. Aceste interfete sunt destinate unei anumite categorii de utilizatori, cum sunt cele referitoare operatiilor dintr-o banca. Uzual un mic set de comenzi prescurtate sunt implementate pentru a scurta timpul necesar introducerii comenzii, sau chiar utilizarea de chei functionale. Aceste interfete implementeaza un limbaj numit si limbaj de comanda.

Interfete pentru DBA utilizate in implementarea comenzilor privilegiate ce sunt folosite numai prin intermediul DBA. Astfel de comenzi includ crearea de conturi, setarea parametrilor sistemului, autorizarea intrarii într-un anumit cont, reorganizarea structurii de stocare a datelor bazei de date, precum si o serie de facilitati legate de administrarea bazei de date cum sunt: accesul la tabele si înregistrari, facilitati de acces la câmpuri ale tabelelor de date.

Datele propriu-zise si catalogul SBD sunt uzual stocate pe disc. Controlul accesului la disc este în sarcina sistemului de operare prin sistemul de gestiune a fisierelor. Un modul de înalt nivel numit Stored Data Manager (SDM), modul component al SBD, controleaza accesul la informatiile stocate pe disc, informatii ce fac parte fie din catalog fie din datele însasi. Modulul SDM va utiliza componente ale sistemului de operare pentru controlul transferului intre disc si memoria interna prin intermediul bufferelor. Numai datele aflate în memoria principala pot fi prelucrate de celelalte module SBD. Compilatorul DDL prelucreaza definitiile schemei, specificate de catre DDL si stocheaza informatiile în catalogul SBD. Catalogul contine detalii despre numele fisierelor, datele însasi, detalii de stocare pentru fiecare fisier, restrictii.

Procesorul bazei de date (run time processor) controleaza accesul la baza de date in timpul rularii. El primeste cereri de reactualizare si adaugare a datelor pe care le implementeaza in baza de date.

Procesorul de cereri (query processor) manipuleaza cererile introduse interactiv de catre utilizator. El analizeaza cererea pe care o transmite sub o forma corespunzatoare procesorului de rulare in timp real.

Precompilatorul extrage din programele de aplicatii comenzile DML scrise in limbaj de nivel înalt. Comenzile sunt trimise compilatorului DML pentru compilare in cod obiect adecvat accesului la baza de date. Codul obiect al comenzilor DML si celelalte programe sunt legate pentru a fi executate de catre sistemul DBMS. Celelalte blocuri cuprinse in figura au fost explicate cu diverse ocazii pâna acum.

Pe lânga modulele descrise pâna acum in bazele de date se utilizeaza o serie de programe ajutatoare ce asigura formarea sistemului de baze de date. Aceste programe utilitare au in general functiile:

Loading utilitar utilizat pentru încarcarea fisierelor de date existente cum sunt fisiere text sau secventiale. Uzual, formatul curent al fisierului sursa si al fisierului de date dorit (destinatia) sunt comunicate utilitarului încarcator. Acesta va reforma automat datele pe care le stocheaza in baza de date.

Backup utilitar care creeaza o copie a datelor asigurând refacerea acestora in cazul unei catastrofe.

File reorganization utilitar ce poate fi utilizat pentru reorganizarea fisierelor bazei de date intr-o forma ce duce la cresterea performantelor.

Report generation utilizat pentru obtinerea rapoartelor referitoare la spatiul ocupat de baza de date, a sumarului calculat pe baza tuturor datelor, etc.

Performance monitoring utilitar ce monitorizeaza utilizarea bazei de date si furnizeaza statistici pentru DBA. Statisticile sunt utilizate de catre DBA pentru a lua decizii in legatura cu necesitatea reorganizarii fisierelor in vederea ameliorarii performantelor.

Sunt posibile si alte utilitare având in general functii de sortare fisiere, compresie de date, monitorizarea utilizatorilor. O facilitate importanta este cea de integrare a DBMS in comunicatii de date formând sistemele DB/DC.

2.3.4. Tipuri de SBD

SBD se pot clasifica dupa mai multe criterii, ce tin cont în general de principalele facilitati oferite.

Un prim criteriu, si poate cel mai important este oferit de modelul datelor pe care se bazeaza SBD. Modelele de date cele mai utilizate în bazele de date actuale sunt cele relationale, retea si ierarhizate. Se pot aminti ca realizari recente SBD bazate pe modele conceptuale sau modele orientate obiect. În conjunctie cu acest criteriu SBD poate fi împartit în relational, în retea, ierarhizat.

Alt criteriu de clasificare este cel al dat de numarul de utilizatori suportati de SBD, la aceeasi tabela de date, criteriu dupa care SBD se clasifica în sistem cu un singur utilizator, în general pentru calculatoare personale si SBD pentru mai multi utilizatori în sistemele multiuser.

Dupa locul în care baza de date este instalata se pot clasifica în baze de date centralizate pe un singur calculator si baze de date distribuite pe mai multe calculatoare conectate în retea, în care gradul de independenta locala a fiecarui SBD este variabil.

Criteriul costului face ca SBD sa se împarta, în general în doua categorii, o categorie pentru care costul este de la 10000 la 100000 $, respectiv de la 100 la 3000 $. În general produsele din a doua categorie sunt utilizate pentru calculatoare personale.

În fine, SBD poate fi cu utilizare generala, fara a implementa caracteristici specifice utilizatorilor particulari, sau cu utilizare particulara pentru un anumit domeniu, cum sunt de exemplu cele de rezervarea biletelor de calatorie, spectacole.

Schema evolutiei arhitecturale a SBD-urilor, este prezentata figura 2.30[5].

Fig.2.30. Evolutia arhitecturii SGBD-urilor[6]

Primul nivel, cel al independentei datelor, a fost posibil o data cu aparitia modelului relational care a facut posibila independenta logica a datelor fata de reprezen­tarea lor fizica, pe suportul de stocare. Maturizarea tehnologiilor relationale a însemnat gasirea a noi si rapide metode acces, indexare, scheme de stocare, a unor noi mecanisme de asigurare a securitatii, integritatii datelor si accesului concurent si, nu în ultimul rând, ela­borarea unor limbaje neprocedurale dedicate bazelor de date - definind faza de optimizare.

Implementarea unor arhitecturi capabile sa gestioneze datele companiilor dispersate teritorial, uneori în tari si continente diferite, a consacrat sintagma baze de date distribuite.

Extensibilitatea SGBD-urilor marcheaza trecerea de la o arhitectura monolitica, la una fle­xibila, în care este posibila adaugarea dinamica a unor module speciale, dedicate gestionarii diferitelor tipuri de date - spatiale, video etc. (ex. cartuse de date - Oracle, lame de date -Informix etc). Daca în anii '80 majoritatea arhitecturilor implementate se bazau pe produsele unei singure case de software, începând cu anii '90 practica legarii între ele a module­lor/aplicatiilor/bazelor de date eterogene (diverse platforme si, implicit, diversi producatori) a devenit una curenta, caracterizând faza de federare. A fost atins astfel obiectivul unui acces transparent si o gestionare unitara a unor surse de date dintre cele mai eterogene.

Explozia Internetului si a aplicatiilor dintre cele mai diversificate au pus în fata producatorilor de SGBD-uri si dezvoltatori de aplicatii dezideratul integrarii. Aceasta înseamna nu numai independenta datelor, optimizare, extensibilitate, federare, dar si posibilitatea de a defini noi tipuri de date, în functie de specificul problemei, cât si legarea strânsa a aplicatiilor din categorii dintre cele mai diferite: sisteme pentru gestiunea continu­tului, depozite de date, sisteme de tip workflow, proiectare asistata de calculator, groupware, în conditiile mobilitatii datelor, accesului din orice punct al planetei la informa­tiile necesare. Java, XML, extensii ale SQL, comunicatiile mobile si multe altele constituie câtiva dintre catalizatorii integrarii datelor[7].

Toti producatorii de servere de baze de date întreprind eforturi substantiale pe linia unui mariaj al relationalului cu tehnologia obiectuala. Includerea de noi tipuri de date, extensii ale nucleului relational "tra­ditional" al bazelor de date catre obiecte, suportul pentru web si comert electronic sunt doar câteva directii pe care s-au înscris majoritatea SGBDR actuale pentru a-si conserva sau ameliora pozitia de pe piata. Acesta este unul dintre aspectele integrarii.

Dupa Mary Roth si Dan Wolfson[8], o platforma robusta pentru integrarea datelor trebuie sa îndeplineasca urmatoarele cerinte:

integrare transparenta a datelor structurate, semistructurate si nestructurate provenind din multiple surse eterogene;

suport eficace pentru stocarea, schimbul si transformarea documentelor XML;

optiuni pentru cautari si analize ale datelor elementare si integrate;

includerea transparenta a accesului la informatii în cadrul proceselor întreprinderii;

suport pentru standarde si platforme multiple;

usurinta în utilizare si întretinere.

În actuala configuratie a pietei mondiale a software-ului, segmentul SBD-urilor este unul de mare anvergura. Spre exemplu, la nivelul anului 2001 acesta era evaluat la 17,4 miliarde de dolari, iar dupa IDC, în ciuda recesiunii actuale din IT, cifra a ajuns la 20 de miliarde în 2006[9]. Prognoza nu pare exagerata, daca ne gândim ca volumul de date de stocat creste, anual, în ultima perioada, cu procente cuprinse între 75 si 150% .

v      SBD-uri de categorie " usoara "

Primele produse de tip SBD vizau sisteme de calcul de mare putere si, fireste, costau enorm. De la mainframe-uri, s-a trecut apoi la minicalculatoare. Dar adevarata "democratizare" a SBD-urilor s-a produs o data cu dezvoltarea exploziva a PC-urilor. Produse precum dBase, RBase, Clipper, FoxPro, Paradox, Access etc. s-au vândut (si copiat ilegal) în milioane de exemplare. Destinate initial utilizatorilor de PC-uri cu un redus bagaj de cunostinte în domeniul bazelor de date, astazi aceste produse sunt dotate cu seturi puternice de instructiuni si functii si prezinta o interfata de lucru deosebit de prietenoasa, atuuri ce confera o mare dinamica acestui segment al pietei, denumit si cel al SBD-urilor micro.

Exploatabile pe platformele de lucru MS-DOS/Windows, reprezinta zona "de jos" care vizeaza deopotriva ne-profesionistii în ale informaticii, dar si dezvoltatorii de aplicatii la scara medie. Totodata, în retelele complexe (de întreprindere), SBD-urile micro pot fi utilizate ca medii de dezvoltare pentru statiile client, prin care se asigura accesul utilizatorilor la BD administrate printr-un SBD "profesional". Lumea SBD-urilor micro a suferit schimbari majore în ultimul deceniu, atât în fizionomie, dar si în modul efectiv de lucru, mai ales pentru cele din clasa XBase. Visual Objects (Computer Associates), Visual FoxPro, Visual dBase seamana putin cu ceea ce a fost altadata un produs XBase, fiind instrumente care înglobeaza tehnologii recente: client/server, replicare, programare orientata pe obiecte, dez­voltarea rapida a aplicatiilor (RAD), web etc.

Este greu de facut o ierarhizare, însa piata a consacrat la aceasta categorie produsul Access al firmei Microsoft., inclus în suita Office: este ieftin, intuitiv si bine integrat cu ceilalti "pilieri", Excel si Word. Astfel încât aria sa de utilizare este superioara oricarui alt produs competitor.

v      SBD-uri de categorie " medie "

Urcând la categoria superioara SBD-urilor micro, se cuvinte amintit ca piata a cochetat pe la mijlocul anilor '90 cu sintagma servere de date pentru grupuri de lucru[11]. Acest concept a fost pus în practica de firma Microsoft, prin comercializarea Ia un pret foarte avantajos a produsului SQL Server, un SBD ce permitea initial accesul simultan la baza de date a unui numar de 20-30 utilizatori. Fara a se ridica la pretentiile unui SBD Unix, SBDRurile pentru grupurile de lucru au fost declarate instrumentul ideal pentru firmele mici si mijlocii, acolo unde Paradox, FoxPro, Access îsi aratau limitele în materie de volum de date ce poate fi gestionat, securitate, pastrarea coerentei în caz de avarie etc. Prin lansarea unor produse sub eticheta Workgroup Databases, marii producatori de SBD-uri au creat o anumita confuzie în rândul utilizatorilor si chiar al distribuitorilor.

În ultimul timp, SBD-urile pentru grupuri de lucru au fost asimilate celor de "categoria grea", desi înca multi autori si profesionisti vad un segment de mijloc între SBD-urile pentru microcalculatoare si cele de categorie grea.

v      SBD-uri de categorie "grea " - servere de baze de date

În aceasta categorie sunt încadrati "pilierii" bazelor de date: Oracle (Oracle), DB2 (IBM), Sybase (Sybase), Informix (IBM), SQL Server (Microsoft) etc, produse orientate pe gestiunea informatizata a organizatiilor mari si foarte mari, asigurându-se accesul simultan a sute, chiar mii de utilizatori la o aceeasi baza de date. Daca, traditional, piata acestui segment era rezervata Unix-ului, în prezent Windows NT (2000) si mai nou Linux fac fata celor mai multe cerinte.

Cât priveste cota de piata detinuta de fiecare producator, anul 2005 a fost destul de agitat. De o buna bucata de vreme, Oracle era considerat liderul indiscutabil al pietii SBD, însa prin achizitionarea firmei Informix (si a cotei de piata a acesteia), firma IBM a atins procentul 34,6%, devansând Oracle care ar avea doar 32%. Pe locul trei ar urma Microsoft cu 16,3% din piata SBD-urilor. Dupa cum remarca si Craig Mullins, în urma acestui raport, fiecare producator si-a autodeclarat suprematia, Oracle pe piata "SGBD-urilor modeme"'[12], iar Microsoft pe platformele Windows . Toate afirmatiile par a fi, macar partial, adevarate, câta vreme studiul Garner nu se refera numai la serverele de baza de date relationale, ci si la cele de pe mainframe-uri (ierarhice, cum ar fi IMS si retea), precum si la cele de tip "micro" (ex. Access). Pe un segment strategic al SBD-urilor - Unix - Oracle detine 63%, iar IBM 25%.

Interesant este ca, la scurt timp dupa studiul Gartner, IDC a publicat o alta estimare a pietei SBD, în care Oracle are un avantaj de 10 procente fata de principalul concurent -IBM. Craig Mullins explica aceste diferente prin metodologia pe care o utilizeaza fiecare firma de analiza si prospectare a pietei, prin unele detalii ascunse si erori de analiza.

v      Servere de date de tip Free-SBD, adica (aproape) gratuite

PostgreSQL a fost elaborat la University of Carolina, Berkeley, principalii promotori ai sai fiind GreatBridge si Reh Hat. MySQL, produs de MySQL AB (Suedia) si distribuit cu o licenta Gnu (Gnu Public License), este, probabil, cel mai folosit SBD open source, desi functionalitatile sale sunt mai slabe decât ale Postgres-ului. Se remarca printr-o viteza mai buna si o functionalitate mai ridicata decât a concurentilor. Firebired/Interbase este un produs Borland devenit public (open source) în iulie 2000. Dintre alte SBD-uri din aceasta categorie, mai pot fi amintite HSQ si SQLLite[14]. De departe, cele mai folosite si cele care au polarizat, oarecum, comunitatea SBD open-source sunt MySQL si PostgreSQL.

Fara îndoiala, serverele de baze de date din categoria Open Source constituie o directie strategica în evolutia pietei bazelor de date, deoarece ofera o functionalitate rezonabila la preturi foarte mici, lucru cu atât mai dezirabil cu cât ne referim la organizatii care încearca sa-si implementeze arhitecturi informationale în conditiile unei situatii financiare cu puter­nica tenta gri sau rosu.

2.3.4.1. Sisteme de baze de date relationale

Organizatia americana de norme TRG (Realtional Task Group) a definit termenul de "relationalitate". Acesta propune un ansamblu de criterii care sa defineasca notiunea de SBD minimal relational si total relational. Creatorul modelului relational, E.F. Codd a propus 12 criterii de definire a SBD-urilor din punct de vedere al relationalitatii.

     SBD minimal relational

1. Structura tabelului de date

Toate datele unei baze de date sunt reprezentate prin valori în tabele.

2. Pointer-i (puncte de intrare) invizibili

Punctele de intrare ale tabelului de date sunt invizibili pentru utilizator.

3. Operatori de baza:

SBD-ul trebuie sa implementeze operatiile de selectie, proiectie si jonctiune (fara nici o restrictie).

     SBD total relational

Un SBD devine total relational daca la cele trei criterii enuntate anterior se adauga urmatoarele doua:

4. Operatori:

SBD-ul suporta toate operatiile algebrei relationale.

5. Restrictii

SBD permite respecta regula de unicitate a cheii si regula de restrictie referentiala.

Regulile lui Codd

1. Regula privind gestionarea unui SBDR

Toate functiile de manipulare a unui SBD au ca unitate de informatie relatia (tabelul).

2. Regula privind garantarea accesului la date

Fiecare element al unui SBD poate fi accesat într-o maniera unica cu ajutorul numelui relatiei, numelui atributului si a valorii cheii.

3. Regula privind valorile "null"

SBD trebuie sa permita declararea si manipularea sistematica a valorilor de null cu semnificatia unor date lipsa sau inaplicabile.

4. Regula privind metadatele (dictionarul)

Descrierea elementelor unei baze de date trebuie sa se faca, la nivel logic, în aceeasi maniera cu descrierea datelor propriu-zise.

Dictionarul este o baza de date specifica (fisier de descriere globala a datelor) care permite descrierea, la nivel general, a tabelelor de date în scopul manipularii si interogarii acestora.

5. Regula privind limbajele de programare utilizate

Un SBDR trebuie sa faca posibila utilizarea mai multor limbaje de programare. dintre care cel putin unul permite:

definirea tabelelor de date si a tabelelor de date virtuale;

manipularea datelor;

definirea restrictiilor de integritate;

definirea regulilor de acces;

precizarea limitelor tranzactiilor.

6. Regula privind actualizarea datelor

Tabelele de date virtuale (acele tabele construite pe baza tabelelor de date existente) trebuie sa fie efectiv actualizabile.

7. Regula privind manipularea datelor (inserari, modificari, stergeri)

SBD-ul trebuie sa mentina o stare coerenta a datelor din punct de vederea al manipularii lor (regasire, modificare, stergere, inserare).

8. Regula privind independenta fizica a datelor

Programele de aplicatie trebuie sa fie independente de modul si de suporturile de stocare a datelor.

9. Regula privind independenta logica a datelor

Programele de aplicatii trebuie sa fie independente de modificarile semantice ale tabelelor bazei de date.

10. Regula privind restrictiile de integritate a datelor

Limbajul de programare utilizat trebuie sa defineasca restrictiile de integritate ale datelor si trebuie sa fie le memoreze în fisierul de descriere globala (catalogul) a datelor.

11. Regula privind distribuirea geografica a datelor

SBDR trebuie sa permite manipularea datelor indiferent ca bazele de date sunt dispuse în acelasi loc (centralizate) sau dispuse în locuri diferite (distribuite).

12. Regula privind prelucrarea datelor la nivel de baza

Daca SBDR poseda un limbaj de programare de nivel scazut, orientat pe prelucrarea de tupluri (înregistrari) si nu pe prelucrarea la nivel de relatie, acesta nu trebuie utilizat pentru a face exprimari relationale.

2.3.4.2. Sisteme de baze de date distribuite

Tehnologia bazelor de date a evoluat pe parcursul timpului de la o paradigma a procesarii datelor conform careia fiecare aplicatie îsi definea si mentinea propriile date la una conform careia datele sunt definite si administrate centralizat. O data cu dezvoltarea rapida a retelelor si tehnologiei comunicatiilor, a Internetului, aplicatiilor mobile si a dispozitivelor inteligente, asistam la proliferarea bazelor de date distribuite ce combina tehnologii pentru a schimba modul de lucru centralizat într-unui descentralizat.

O baza de date distribuita pura este definita de C.J. Date astfel: "sprijinul complet pentru o baza de date distribuita presupune ca o aplicatie sa poata opera în mod transparent asupra datelor care sunt raspândite în baze de date diferite, gestionate de SBD-uri diferite ce ruleaza pe calculatoare diferite cu sisteme de operare diferite, interconectate prin intermediul unor retele de calculatoare diferite - în care notiunea transparent presupune ca din punct de vedere logic aplicatia va opera ca si cum datele ar fi gestionate de un singur SBD si s-ar afla pe un singur calculator[15]. Prin urmare, o baza de date distribuita poate fi definita ca o colectie de date distribuita fizic pe mai multe platforme hardware interconectate printr-o retea de comunicatie si care sunt accesate de aplicatiile locale de o maniera transpa­renta pentru utilizatorul aplicatiei.

Cu alte cuvinte, o baza de date distribuita e alcatuita dintr-o colectie de noduri inter­conectate printr-o retea de comunicatie si prezinta urmatoarele caracteristici:

o colectie de date integrate la nivel logic;

datele sunt grupate în fragmente;

fragmentele sunt rezidente pe diferite statii;

statiile sunt legate printr-o retea de comunicatii;

datele de pe fiecare statie sunt gestionate de un SGBD;

SGBD-ul fiecarei statii poate deservi aplicatiile locale în mod autonom si, în acelasi timp, poate participa la cel putin o aplicatie globala.

Exista doua tipuri de sisteme de baze de date distribuite:

sistem omogen - consta într-o retea de doua sau mai multe baze de date rezidente pe doua sau mai multe calculatoare pe care ruleaza local acelasi SGBD. O aplicatie poate accesa si modifica date din mai multe baze de date într-un singur mediu distribuit. Pentru o aplicatie-client, localizarea si platforma pe care se afla baza de date sunt absolut transparente;

sistem eterogen - pe noduri diferite pot sa ruleze SGBD-uri diferite care nu trebuie sa se bazeze pe acelasi model de organizare a datelor, fiind posibil ca sistemul sa fie format din SGBD-uri relationale, ierarhice si orientate-obiect.

Din punct de vedere al utilizatorului o baza de date distribuita (BDD) este o singura baza de date (BD) cu o schema unica. Programele de aplicatii care manipuleaza BDD au acces la date fara ca utilizatorul sa stie pe ce statie se afla fizic datele.

Arhitectura generala a unui sistem de gestiune a bazelor de date distribuite poate fi reprezentata ca în figura 2.31[16].

Fig. 2.31. Arhitectura generala a unui SBDD

Asa cum observam si în figura 2.31, un SBDD ar trebui sa furnizeze urmatoarele elemente:

Schema globala conceptuala - o descriere logica a întregii baze de date ca si cum nu ar fi distribuita. Aici trebuie sa regasim definirea entitatilor, relatiilor, constrânge­rilor, securitatii si integritatii datelor fara a intra în detaliile localizarii fizice a datelor.

Schema alocarii si schema fragmentarii. Fragmentele sunt portiuni logice ale relatii­lor globale ce pot fi rezidente pe una sau mai multe statii din retea. Schema fragmen­tarii este tocmai descrierea partitionarii logice a datelor, iar schema alocarii este descrierea localizarii fizice a datelor.

Scheme locale. Fiecare SBD local dispune de propriile scheme conceptuale si interne. Schema de mapare descrie fragmentele din schema de alocare prin intermediul unor obiecte externe în baza de date locala. Aceasta schema este independenta de SBD si constituie suportul pentru SGBD-uri eterogene.

Conceptele esentiale ce diferentiaza o baza de date distribuita de una centralizata sunt: fragmentarea, alocarea, replicarea, transparenta si tranzactiile distribuite.

Prin fragmentare întelegem ca o relatie poate fi divizata într-un numar de subrelatii, numite fragmente, care apoi sunt distribuite. Exista doua tipuri principale de fragmentare: orizontala (subset de tupluri - fragmente care au aceeasi structura ca si relatia globala dar difera prin înregistrari) si verticala (subset de atribute - fragmentele au acelasi numar de tupluri ca si relatia de baza dar structura diferita). Fragmentarea trebuie sa îndeplineasca trei conditii esentiale:

Completitudine: toate datele din relatia globala trebuie sa se regaseasca în cel putin unul dintre fragmente. Aceasta regula asigura imposibilitatea pierderii datelor.

Reconstructie: relatia de baza trebuie sa poata fi oricând reconstruita din fragmente. Aceasta regula asigura functionalitatea aplicatiilor la nivel global.

Disjunctie: o data ce apartine unui fragment nu poate apartine altora. Fragmentarea verticala este exceptia de la aceasta regula o data ce atributele cheii primare se repeta pentru a asigura reconstructia. Aceasta regula asigura redundanta minima a datelor.

Alocarea înseamna localizarea optima a fragmentelor pe diferite statii.

Termenul de localizare optima se refera la faptul ca proiectarea bazei de date distribuite trebuie sa aiba la baza informatii cantitative (frecventa tranzactiilor, statia de pe care este lansata o tranzactie si criterii de performanta ale tranzactiilor) si informatii calitative (atributele si tuplurile accesate de o tranzactie, tipul de acces - scriere sau citire - efectuat de tranzactie si predicatele operatiilor de citire).

Termenul replicare se refera la faptul ca exista copii ale datelor si ale obiectelor în mai multe baze de date locale apartinând sistemului distribuit. Astfel, într-un sistem pur dis­tribuit exista o singura copie a datelor si a tuturor obiectelor din baza de date. Asemenea sisteme lucreaza în mod curent prin tranzactii distribuite atât pentru a accesa datele rezi­dente local si cele rezidente pe un alt nod din retea cât si pentru a modifica datele la nivel global în timp real. Exista doua mari tipuri de replicare: asincrona si sincrona.

Replicarea asincrona, adeseori numita si replicare de tip acumuleaza-si-transmite, preia modificarile locale, le asaza într-o coada de asteptare si, la intervale regulate, le propaga catre alte statii. Ca urmare, va exista întotdeauna o anumita perioada de timp pâna când toate statiile de replicare vor asigura convergenta datelor.

Replicarea sincrona, cunoscuta si sub numele de replicare în timp real, aplica modifi­carile atât local cât si pe toate celelalte statii pe parcursul unei singure tranzactii. Daca actualiza­rea esueaza la nivelul unui nod, întreaga tranzactie este anulata. Ca urmare, spre deosebire

de replicarea asincrona, în acest caz nu exista perioade de timp în care datele din diverse locatii sa nu se potriveasca.

Prin transparenta întelegem ascunderea detaliilor de implementare fata de utilizator. Pornind de la principiul fundamental conform caruia "pentru un utilizator, un sistem distribuit trebuie sa apara ca si cum ar fi un sistem ne-distribuit", C.J. Date a formulat obiectivele SBDD-urilor[17]:

   Autonomie locala - ceea ce înseamna ca:

Datele locale sunt rezidente si gestionate local.

Operatiile de prelucrare locale sunt executate în întregime local.

Toate operatiile unui nod sunt controlate de acel nod.

   Nu exista dependenta fata de un nod central - nu trebuie sa existe vreun nod cu care sistemul sa nu poata opera.

   Functionare permanenta - în mod ideal, nu este necesara luarea în considerare a unor disfunctionalitati ale sistemului, a operatiilor de adaugare sau eliminare a unui nod sau pentru crearea sau stergerea fragmentelor de date.

   Transparenta fragmentarii - utilizatorul trebuie sa poata accesa datele, indiferent de modul de fragmentare a lor.

   Transparenta localizarii - utilizatorul trebuie sa poata accesa datele, indiferent de nodul pe care sunt localizate.

   Transparenta replicarii - utilizatorul trebuie sa poata accesa în mod direct o anumita copie a datelor, fara sa fie preocupat de actualizarea tuturor copiilor.

   Prelucrarea interogarilor distribuite - sistemul trebuie sa trateze tranzactiile ca unitate de prelucrare si restaurare.

   Transparenta platformei hardware - trebuie sa fie posibila rularea SGBDD pe platforme hardware diferite.

   Transparenta sistemului de operare - trebuie sa fie posibila rularea SGBDD într-o varietate de sisteme de operare.

   Transparenta retelei de comunicatie - SGBDD trebuie sa functioneze indiferent de tipul retelei de comunicatie.

   Transparenta sistemului de gestiune a bazelor de date - trebuie sa fie posibila existenta unui SGBDD format din SGBD locale diferite.

Într-o baza de date distribuita, un rol deosebit în privinta performantelor îl constituie tipul tranzactiei, care se poate încadra în una dintre urmatoarele categorii posibile: cereri la distanta, tranzactii la distanta, tranzactii distribuite, cereri distribuite. Cererile la distanta se refera la fraze SQL trimise catre o alta locatie din retea. Aceasta cerere se executa în totalitate pe statia destinatie si are acces numai Ia date locale. Tranzactiile la distanta pre­supun trimiterea întregului pachet de fraze SQL ce constituie o tranzactie catre un alt nod în retea. Comiterea tranzactiei va ramâne totusi în grija clientului. Tranzactiile distribuite înseamna trimiterea frazelor SQL ce definesc tranzactia catre mai multe statii din retea pentru a se executa la distanta. si în acest caz statia-client este responsabila de comiterea tranzactiei la nivel global. Cererile distribuite presupun ca o aceeasi fraza SQL va accesa date aflate în locatii diferite.

Pentru ca am vorbit ceva mai devreme de localizare optima a datelor, vom prezenta patru strategii alternative de alocare:

Centralizare - o singura baza de date si SBD central. Costurile de comunicatie sunt foarte mari.

Fragmentare - consta în partitionarea bazei de date în fragmente disjuncte, fiecare fragment fiind rezident pe o statie distincta acolo unde datele sunt utilizate foarte frecvent. Daca se realizeaza o proiectare corespunzatoare a fragmentelor, se pot obtine performante ridicate si costuri de comunicatii reduse.

Replicare completa - consta în mentinerea unei copii complete a bazei de date pe fiecare statie. Bineînteles ca în acest caz costurile de comunicatie (pentru asigurarea sincronizarii datelor) si de stocare sunt foarte mari. Pentru reducerea acestor costuri se poate recurge la replicarea asincrona si la snapshot-uri. Un snapshot este o oapie a bazei de date la un moment dat în timp, copiile fiind actualizate periodic.

Replicarea selectiva - este o combinatie a fragmentarii, replicarii si centralizarii. în aceasta arhitectura anumite date sunt fragmentate, altele sunt rezidente numai la nivel central, iar altele sunt replicate. Prin aceasta strategie, de altfel si cea mai utilizata în practica, se încearca eliminarea tuturor dezavantajelor celorlalte strategii.

Un aspect esential al bazelor de date distribuite se refera la atomicitatea tranzactiilor atât la nivel local cât si la nivel global. Prin atomicitate întelegem faptul ca o tranzactie globala nu va fi comisa ori anulata decât atunci când toate subtranzactiile au fost comise ori anulate cu succes. în acest sens au fost dezvoltate doua protocoale de comitere pentru bazele de date distribuite: comiterea în doua faze (2PC) si comiterea în trei faze (3PC).

Asa cum sugereaza si numele, protocolul de comitere în doua faze functioneaza în doua etape: etapa de votare si etapa de decizie. Ideea de baza consta în aceea ca initiatorul tran­zactiei (numit coordonator) lanseaza o cerere catre participanti pentru a afla daca sunt gata sa comita tranzactia. Daca macar unul dintre participanti voteaza pentru anulare sau nu raspunde, coordonatorul va trimite un mesaj de anulare tuturor subtranzactiilor. în caz ca toti participantii voteaza pentru comitere, coordonatorul va trimite tuturor un mesaj de comi­tere a tranzactiilor locale. Decizia globala trebuie adoptata de toti participantii, fiecare dintre acestia având însa libertatea de a anula imediat subtranzactia locala atât timp cât nu voteaza pentru comiterea ei (anulare unilaterala). Daca votul este favorabil comiterii atunci trebuie asteptat mesajul coordonatorului de comitere sau anulare globala. Protocolul 2PC implica asadar existenta unor procese care asteapta mesaje de la alte locatii din retea. Pentru a se evita blocajele exista si un timp maxim de asteptare dupa expirarea caruia se considera implicit vot de anulare. Problema principala a acestui protocol decurge din faptul ca în eventualitatea blocarii coordonatorului, participantii care au trimis votul de comitere si asteapta mesajul global vor fi la rândul lor blocati.

Protocolul de comitere în trei faze încearca sa elimine perioada de incertitudine pentru participantii care au votat COMMIT si asteapta mesajul global, prin introducerea unei faze inter­mediare (între votare si mesajul global), numita pre-commit. Pe masura ce coordonatorul primeste voturile de comitere de la participanti, trimite un mesaj global de pre-comitere pentru a înstiinta nodurile care au votat ca sunt pe cale de a comite tranzactia. O data ce au fost adunate toate voturile, coordonatorul va initia mesajul de comitere global. Anularea tran­zactiei este gestionata ca si în cazul protocolului 2PC.

În 1999, cercetarile efectuate de Standish Group reliefau ca 6% din toate disfunctionalitatile aplicatiilor au fost cauzate de bazele de date. Aceasta ar fi însemnat 30 milioane USD pierderi pe an. Conform datelor studiului efectuat la nivel international, gradul de utilizare a bazelor de date distribuite vor fi utilizate în aplicatiile economice se prezinta astfel: ERP (100%), aplicatiile e-commerce (71%), iar aplicatiile pentru managementul lantului de distributie

Acelasi studiu aprecia ca trebuie luate în considerare cinci obiective pentru a câstiga o cât mai mare disponibilitate a datelor: toleranta la erori, toleranta la restaurare, toleranta de întretinere, toleranta la utilizatori, toleranta la dezastre geografice.

Toleranta la erori. O tehnica rezonabila de prevenire a erorilor cere ca utilizatorul final sa nu fie constient de erorile aparute în acelasi timp cu mentinerea calitatii la un nivel acceptabil ceea ce necesita planificarea atenta a activitatilor, astfel: (1) întotdeauna trebuie sa existe macar doua copii ale fiecarei resurse; (2) fiecare dintre acestea trebuie sa fie capabila sa suporte un nivel maxim de încarcare a traficului; (3) resursele trebuie sa fie sincronizate continuu.

Exista trei caracteristici de baza ale unei aplicatii de baze de date care concura la preve­nirea erorilor:

sistemul trebuie sa poata redirectiona "din zbor" tranzactiile catre alt server sau baza de date;

sistemul trebuie sa permita balansarea dinamica a nivelului de încarcare între resurse multiple;

sistemul trebuie sa previna efectele unor false erori.

Toleranta la restaurare. Timpul de restaurare a unei baze de date în cazul aparitiei unor disfunctionalitati este considerat a fi critic în multe aplicatii în timp real. Ca rezultat, o planificare atenta trebuie sa ia în considerare urmatorii factori:

trebuie sa existe macar o copie a fiecarei resurse cu aceleasi capacitati de stocare si prelucrare ca si originalul;

baza de date trebuie sa fie complet replicata;

trebuie sa existe personal înalt calificat pentru a restaura rapid defectiunile.

De asemenea, baza de date trebuie sa furnizeze urmatoarele facilitati:

aplicatia trebuie sa poata "sari" la alta baza de date în cel mai scurt timp posibil;

abilitatea bazei de date de a trimite rapid modificarile si de a le anula la fel de rapid;

posibilitatea restaurarilor on-line (fara ca baza de date sa fie oprita).

Toleranta la întretinere. Asa cum spuneam si mai devreme, majoritatea operatiunilor de întretinere si management al bazei de date trebuie sa poata fi executate on-line. Aici inclu­dem încarcarea cu date si distribuirea acestora, crearea indecsilor, inserarea si eliminarea de tabele.

Toleranta fata de utilizatori. Utilizatorii sunt supusi prin natura lor erorii, iar erorile duc la timpi de inactivitate. De aceea este necesar un mediu grafic usor de utilizat pentru adminis­tratori.

Toleranta la dezastre geografice. Unele dezastre naturale pot afecta sever operatiunile curente ale unei companii. Timp de multi ani, un sistem informatic complet redundant era considerat mult prea scump si greu de întretinut. Oricum însa, în circumstantele actuale acest deziderat devine rezonabil datorita faptului ca: 1) Intemetul furnizeaza un schelet comun pentru o retea globala; 2) preturile echipamentelor sunt în scadere.

2.3.4.3. Sisteme de baze de date obiectuale

Tendintei actuale de extindere a bazelor de date relationale spre serverele universale îi stau în cale limitele modelului relational al datelor si cele ale SQL-ului clasic, mai ales în comparatie (inevitabila) cu forta tehnologiei obiectelor distribuite. Acest decalaj, asociat cu cresterea rapida a popularitatii Internet-ului si a conceptului Java, impune cautarea de directii noi si pentru domeniul bazelor de date, iar solutia momentului si a viitorului apropiat (incertitudinii îi putem asocia doua descrieri: suntem în perioada de tranzitie sau avem o evolutie cu panta abrupta - fiecare cititor va alege alternativa dupa gusturi) consta în bazele de date orientate obiect. Iar un efect al acestor tendinte se pare ca va consta în pierderea importantei conceptului de universal server în fata celui de baza de data obiectuala.

Tehnologia bazelor de date relationale îsi are suportul pe tranzactii bazate pe tabele (o forma destul de simpla, cu limitari din ce în ce mai evidente într-o lume interconectata si "macinând" date din ce în ce mai complexe), pe când bazele de date obiectuale sunt destinate sa suporte modele de obiecte complexe care permit functionalitati si performante superioare.

Se poate afirma fara nici un fel de riscuri ca bazele de date obiectuale sunt fundamental diferite de bazele de date relationale sau de serverele universale, datorita largii cuprinderi de facilitati tehnice destinate sa furnizeze suport pentru utilizarea distribuita a obiectelor. Însa noul concept nu înseamna neaparat un mars triumfal: nici una dintre bazele de date orientate obiect actuale nu implementeaza absolut toate functionalitatile specifice tehnologiei orientate obiect, putându-se totusi distinge mai multe niveluri pe scala completitudinii.

Cea mai evidenta facilitate a unei baze de date orientate obiect este viteza de acces la date în comparatie cu cea a sistemelor relationale sau relational extinse (servere universale sau chiar baze de date obiectual-relationale).

Bazele de date obiectuale stocheaza o harta a ierarhiilor si relatiilor claselor de obiecte, structura ce permite o accesare directa. Aceasta navigare nemijlocita prin date conduce la cea mai performanta abordare privind stocarea si consultarea informatiilor orientate obiect.

Ca efect al organizarii tabelare a datelor, un server universal trebuie sa dezasambleze obiectele pentru a le înmagazina în tabele, pentru ca mai apoi sa fie nevoit sa reuneasca componentele obtinute la faza de stocare pentru a permite accesul la obiecte în forma lor naturala, ceea ce înseamna complicatii deosebite si la nivelul programarii aplicatiilor. Este adevarat ca pentru sisteme orientate obiect de complexitate redusa serverul universal îsi face treaba fara probleme. Cum însa obiectele sunt deocamdata cele mai potrivite si expresive forme de organizare a datelor pentru modelarea evenimentelor lumii reale, tendinta de a se crea sisteme orientate obiect din ce în ce mai complexe este clara. Ceea ce duce la concluzia ca strategia serverelor universale va trebui regândita.

Un alt aspect care "înghesuie" serverul universal este dat de maparea relatiilor complexe dintre obiectele bazei de date, pentru care bazele de date orientate obiect nu trebuie sa se straduiasca, fiind un adeziv natural la ierarhiile de mostenire.

Clustering (grupare sau portionare a datelor):

Abilitatea bazei de date obiectuala de a realiza portionarea fizica de obiecte pentru a ridica performanta sistemului este legata de abilitatea sa nativa de a naviga. Astfel, obiectele - necesare la un moment dat unei cereri client sau altui server - sunt aduse integral în memoria locala. Deoarece acestea pot fi manevrate la un mult mai fin nivel de granularitate decât tabelele mapate ale serverului universal, baza de date obiectuala câstiga avantaj prin strategia acordului fin, ceea ce are ca efect practic si minimizarea traficului prin retea. Tot clustering-ul este cel care permite unei baze de date obiectuale sa acceseze eficient toate obiectele, astfel încât sa permita simultan mai multor utilizatori si aplicatii sa aiba fiecare o imagine a modelului obiect original.

Bazele de date orientate obiect ofera functionalitati unice când se pune problema datelor distribuite. Cheia acestui avantaj consta în existenta unui identificator unic care izoleaza numele logic al obiectului de locatia fizica a acestuia, de unde rezulta si posibilitatea ca o baza de date singulara sa fie separata pentru a rula pe sisteme cu mai multe procesoare, respectiv pe o aceeasi masina (de exemplu, prin SMP - Symmetric MultiProcessing) sau într-o retea de calculatoare. Granularitatea fina permisa de tehnologia bazelor de date orientate obiect ajuta la replicarea eficienta a datelor.

Distribuirea datelor astfel încât mai multe calculatoare sa aiba parti distincte ale unei aceleiasi baze de date logice este destul de dificil de implementat pe serverele universale întrucât acestea trebuie sa mentina constrângerile specifice definitiei tabelare a datelor pentru întreaga retea, iar când manevreaza date orientate obiect, acest lucru devine un handicap.

Replicarea datelor (solutie prin care baza de date este segmentata în componente discrete ce sunt mentinute legate prin sincronizare) este obtinuta mult mai eficient în cadrul bazei de date orientate obiect datorita aceluiasi transfer de informatie mult mai granular. În cazul bazelor de date relationale, nivelul replicarii este substantial mai ridicat pentru ca se tranzactioneaza cu tabele, aceasta însemnând si costuri mai ridicate pentru serverele care trebuie sa suporte un trafic intens.

În mod firesc, majoritatea bazelor de date orientate obiect destinate mediilor critice trebuie sa permita modificari asupra structurii datelor, ceea ce presupune reorganizarea ierarhiilor de mostenire sau a relatiilor dintre obiecte. Sistemele performante de baze de date orientate obiect contin functii prin care se poate modifica schema fara a scoate din functiune baza de date. Actualizarea on-line a schemei bazei de date prin algoritmi incrementali permite introducerea fara socuri a schimbarilor ce apar pe parcurs asupra organizarii sistemului. Exista chiar posibilitatea de a memora diferitele versiuni ale modelului obiectual pentru a facilita adaptarea aplicatiilor la cel mai potrivit dintre acestea.

Sistemele de gestionare a bazelor de date relationale folosesc uzual o strategie statica pentru modificarea bazei de date, ceea ce presupune oprirea aplicatiei pentru recompilarea schemei si pentru refacerea relatiilor si a dependentelor SQL.

Arhitectura client/server: este considerata una dintre cele mai subtile caracteristici ale bazelor de date obiectuale.

În mod frecvent, un server central se ocupa de accesul concurent si de integritatea bazei de date în timp ce clientul asigura alte functii. În cazul bazei de date obiectuale, functionalitatii clientului i se adauga capacitatea de a accesa date multiple si de a asambla obiectele servite pentru a crea o imagine locala unificata. Suportul pentru multithreading permite clientilor sa implementeze simultan mai multe task-uri specifice.

Natura distribuita a bazelor de date orientate obiect este evidentiata de capacitatea de a mentine copii locale ale obiectelor fara a suprasolicita serverul central sau reteaua. Accesarea obiectelor printr-o memorie cache locala s-a dovedit de câteva sute de ori mai rapida decât accesarea datelor organizate relational în cadrul aceleiasi configuratii de retea. În cazul serverelor universale, procesarile bazei de date au loc central. De fiecare data când o aplicatie client/server necesita date, ea trebuie sa le ceara de la server, existând doar posibilitatea de a oglindi la client tabele. Este foarte dificil sa se programeze o aplicatie care sa mapeze de partea clientului date sub forma de obiecte, atât timp cât tehnologia de nucleu nu opereaza decât cu tabele.

Arhitectura N-Tier: Luând in considerare perspectivele sistemelor orientate obiect si expansiunea Internet-ului si a intranet-urilor, specialistii prevad ca arhitectura sistemelor de aplicatii va evolua catre o structura N-Tier (serie-n). Unei astfel de organizari îi este caracteristic traficul intens de mesaj dintre numeroasele subsisteme componente: clientii unei aplicatii server solicita date pe care aceasta le cere serverului de Web sau de baze de date, iar acesta le colecteaza de la multe alte servere back-end pentru a completa raspunsul la cererea initiala. Prin chiar esenta ei, baza de date obiectuala are abilitatea de a lucra cu vederi logice ale obiectelor distribuite, constituindu-se într-o solutie naturala pentru aplicatii N-Tier, unde integritatea tranzactiilor si scalabilitatea aplicatiilor cântaresc mult.

De cealalta parte, pentru a deservi fluent un astfel de model distribuit ar fi necesare mai multe servere universale centralizate, cu performante si capacitati deosebite. De ceva timp suntem martorii efortului de armonizare dintre serverele universale si mediul distribuit prin Network Computer Architecture promovata de Oracle, al carui succes pe termen lung înca nu este foarte sigur.

Abilitatea de a rula o aplicatie a bazei de date constituie o cerinta importanta pentru multe sisteme. În lumea serverelor universale executia programelor se refera la procedurile si declansatoarele bazei de date relationale, ambele lucrând cu tabele de date. Aceste coduri executabile sunt solutii particulare, nesuportând o executie generalizata, de preferat într-un mediu deschis. Chiar folosind extensiile promovate de SQL3, aceste programe nu sunt ideale pentru aplicatii orientate obiect. Contrastul este banal, bazele de date obiectuale lucreaza cu limbaje de programare orientate obiect recunoscute ca standarde internationale: C++, Java si chiar Smalltalk.

Toata lumea a observat ca limbajul Java este promovat - atât la nivel înalt, cât si la nivel de masa - ca solutie ideala pentru dezvoltarea de software bazat pe componente (faptul ca sistemul este asamblat din blocuri de construire predefinite reduce timpul de dezvoltare si complexitatea abordarii) si de sisteme de comunicatii orientate obiect. Având ca premisa adoptarea universala a protocoalelor de comunicatii performante (TCP/IP si altele) devine posibil sa se creeze aplicatii orientate obiect dispersate, ale caror componente sa fie plasate în puncte cheie din perspectiva performantei, a flexibilitatii sau a altor cerinte tehnice.

Pentru ca penetrarea tehnologiei obiectuale este tot mai evidenta, comitetul de standarde care guverneaza limbajul SQL si-a propus sa ia în considerare asigurarea suportului pentru conceptele orientate obiect. Însa mentinerea compatibilitatii cu bazele de date existente si minimizarea efortului de tranzitie au determinat acest comitet sa recomande doar o extindere a lui SQL si pastrarea contextului orientat pe tabele.

2.4. Modelarea conceptuala a datelor

2.4.1. Aspecte generale privind modelarea conceptuala a datelor

Un model conceptual este format dintr-un set de concepte care alcatuiesc modelul formal, la care se adauga o anumita viziune a analistului asupra realitatii investigate referitoare la sistemul modelat.

Modelele conceptuale reprezinta de fapt un limbaj specializat, cu ajutorul caruia, sunt descrise aspectele calitative esentiale ale sistemelor reale, indiferent de gradul lor de complexitate. Ele pot sa preceada alte tipuri de modele si sunt utilizate pentru probleme slab sau prost structurate, sau chiar nestructurate (instabile, cu multe modificari) pentru care este dificil sau imposibil de elaborat alte tipuri de modele.

În afara acestui avantaj, modelele conceptuale sunt utile în analiza de sistem deoarece:

clarifica (precizeaza) viziunea analistului asupra sistemului analizat;

defineste structura si logica sistemului prin ilustrarea conceptuala, simbolica pe care o ofera;

constituie o premisa pe baza careia se poate realiza activitatea de proiectare a noului sistem.

Limbajul utilizat în cadrul metodelor conceptuale face apel la o serie de concepte fundamentale din teoria generala a sistemelor sau derivate din acestea, din care mentionam:

a) Procesul de transformare, care este reprezentat de multimea activitatilor necesare pentru transformarea intrarilor sistemului în iesirile dorite. Din acest punct de vedere, orice model conceptual trebuie sa contina cel putin un proces de transformare.

b) Gradul de conectivitate, reflecta dependenta logica, surprinsa de model, între activitatile sistemului în procesul de transformare.

De exemplu, activitatea de transformare a materiilor prime în produse finite trebuie precedata de activitati ca: stabilirea sortimentului si a cantitatii de produse finite, pregatirea fortei de munca, aprovizionarea cu materii prime si materiale etc., care sa asigure desfasurarea normala a fluxului tehnologic care defineste procesul studiat.

Dependenta sau conectivitatea activitatilor poate fi relevata pe baza unor premise teoretice, pornind de la fluxul tehnologic, sau apelând la cunostintele unor experti, consilieri etc. Una dintre cele mai importante conectivitati în analiza de sistem este cea informational-decizional.

d) Obiectivul sistemului modelat se afla într-o legatura directa cu rezultatele dorite ale proceselor de transformare pe care le include sistemul real si, din punct de vedere practic, reprezinta însasi ratiunea acestuia de a exista, finalitatea sa.

Astfel, asigurarea ritmica cu resursele necesare desfasurarii continue a procesului de productie, urmarirea operativa a stocurilor, reducerea stocurilor supranormative, urmarirea consumurilor specifice etc., reprezinta obiective specifice modelarii subsistemului de aprovizionare.

d) Performanta modelului/sistemului este un indicator care cuantifica gradul de îndeplinire a obiectivelor propuse ale sistemului. Informatiile obtinute pe baza indicatorilor de performanta sunt folosite pentru efectuarea unor actiuni de control în cadrul unor proceduri de luare a deciziilor (verificarea efectelor deciziilor luate), în vederea stabilirii corectiilor necesare pentru îmbunatatirea modelului. Totalitatea acestor proceduri formeaza mecanismul de decizie/control pentru îmbunatatirea performantelor sistemului.

De exemplu, daca obiectivul sistemului îl constituie satisfacerea unei cereri exprimate pe piata, atunci performanta sistemului poate fi data de nivelul de satisfacere a segmentului de piata, cuantificabil prin determinarea ponderii detinute de sistem pe aceea piata. Pe baza acestui indicator se pot adopta deciziile pentru îmbunatatirea calitatii produsului, a activitatilor de promovare si de vânzare a produsului (reclama, studii de piata) etc.

e) Granitele sistemului delimiteaza un cadru mai mult sau mai putin restrâns, în functie de scopul analizei, în care se iau actiunile de decizie-control si sunt definite de limitele pâna la care activitatile si elementele sistemului raspund mecanismului decizional propriu sistemului analizat.

f) Nivelul/gradul de rezolutie al modelului, reflecta gradul necesar de detaliere a sistemului conform procedurii de analiza structurala (descompunere) si depinde de obiectivele urmarite si de resursele disponibile.

g) Resursele (materiale, financiare, umane, de timp) sunt necesare atingerii obiectivelor sistemului si se afla sub controlul procedurilor decizionale.

h) Viziunea observatorului asupra realitatii. Multimea conceptelor enumerate si exemplificate, prezinta modelul formal al sistemului. Acelasi sistem poate fi descris în mod distinct de observatori diferiti, perceptia fiecaruia fiind influentata mai mult sau mai putin de factori obiectivi, subiectivi si de incertitudine

Obiectivul sistemului poate fi înlocuit printr-o asa numita definitie-radacina (de baza), care este mai mult decât o simpla reformulare a obiectivului, ea înglobând si viziunea analistului în raport cu care se face descrierea sistemului.

Modelele conceptuale apar ca o constructie logica asociata unei multimi de interactiuni specifice sistemelor cu activitate umana, care ofera un mijloc de analiza a oricarei probleme (situatii) indiferent de contextul organizational. Activitatile specifice fiecarui subsistem, implica o actiune efectiva, si de aceea, în limbajul de modelare conceptuala sistemele si subsistemele analizate sunt reprezentate prin verbe.

Modelul este o descriere a unei situatii problema prin care se evidentiaza varietatea fizica structurala (folosind chiar un limbaj matematic) si multimea interactiunilor care determina comportamentul sistemului.

Procesul de modelare conceptuala a unui sistem real se desfasoara în mod iterativ pâna la atingerea nivelului de rezolutie dorit si urmareste parcurgerea etapelor ilustrate sugestiv în fig.2.32.

Dupa n iteratii se obtine varianta finala a modelului conceptual, în conformitate cu nivelul de rezolutie dorit si cu setul de ipoteze si de criterii utilizate.

Fiecare model conceptual va fi derivat si dezvoltat de la o definitie de baza, care arata ce este sistemul respectiv si va desemna multimea de activitati pe care sistemul trebuie sa le desfasoare pentru atingerea obiectivelor sale. Apoi, fiecare activitate va fi detaliata la rândul ei, într-un numar de nivele, pornind de la propria sa definitie, si în functie de o viziune-sinteza a analistului si a fiecaruia din managerii compartimentelor implicate în analiza sistemului.

Fig.2.32. Procesul de modelare conceptuala

Procesele modelate prin analiza de sistem se preteaza mai greu abordarilor în sensul optimizarii, de aceea modelarea conceptuala are în vedere determinarea acelui rang al viziunii asupra sistemului, pe baza unui numar cât mai mare de modele echivalente, care sa ofere cea mai relevanta imagine asupra situatiei existente.

2.4.2. Modelul conceptual al datelor (diagramele entitate-relatie)

Modelul conceptual al datelor înseamna o modalitate de reprezentare a datelor organizatiei, având rolul de a scoate în relief toate regulile privind identitatea si legaturile existente între date.

Cea mai cunoscuta forma utilizata pentru modelarea datelor este diagrama entitate-relatie (DER). O modalitate aproape identica este folosita si în analiza si proiectarea orientata-obiect.

O grupare "traditionala" a modelelor utilizate în bazele de date delimiteaza trei cate­gorii: modele logice bazate pe obiect, modele logice bazate pe înregistrare si modele fizice.

Modelele logice bazate pe obiect permit descrierea datelor la nivelurile conceptual si extern. Se caracterizeaza prin flexibilitate si explicitate în reprezentarea structurilor de date] si a restrictiilor pe care trebuie sa le îndeplineasca acestea. Cele mai raspândite structuri aceasta grupa sunt:

entitati-asociatii (E-A), referita si ca entitati-relatii (E-R);

semantica;

functionala;

orientata pe obiecte.

Dintre acestea, o importanta deosebita o prezinta structura entitate-asociatie, considerata un instrument foarte util în analiza si proiectarea bazelor de date, precum si cea orientata pe obiecte, de mare actualitate, dar mai ales de mare viitor în ceea ce priveste evolutia BD.

Modelul E-R are la baza perceptia lumii reale sub forma unei colectii de obiecte denumite entitati, unite prin asociatii. O entitate este un obiect ce poate fi diferentiat de alte obiecte printr-un ansamblu de atribute care permit descrierea precisa a acestuia. De exem­plu, atributele Numar si Disponibil pot defini un cont deschis la o banca de catre o persoana fizica. O asociatie reuneste doua sau mai multe entitati. O asociatie "leaga" un client de fie­care din conturile pe care acesta le are deschise la banca respectiva. Ansamblul entitatilor de acelasi tip formeaza o clasa de entitati iar ansamblul asociatiilor de acelasi gen reprezinta o clasa de asociatii.

Structura de ansamblu a unei baze de date poate fi descrisa printr-o diagrama E-R care contine: dreptunghiuri, utilizate pentru reprezentarea claselor de entitati; elipse, pentru repre­zentarea atributelor; romburi, pentru clasele de asociatii; linii, ce pun în legatura, pe de o parte, atributele si clasele de entitati si, pe de alta parte, clasele de entitati si clasele de asociatii.

Modelarea datelor prin DER prezinta caracteristicile si structura datelor independent de modul în care acestea sunt memorate în calculator. Modelul se creeaza iterativ. De cele mai multe ori, operatiunea are loc la nivel de întreprindere, prin apelarea la o categorie foarte larga de date, neglijându-se detaliile exagerate.

Doar în etapele urmatoare, în speta când se trece la definirea proiectului, are loc construirea unui model anume entitate-relatie, prin care sa fie scoasa în evidenta aria de întindere a proiectului.

Fig. 2.33. Procesul de modelare a datelor si prelucrarilor

Modelul E-R asigura perceperea de catre utilizatori fara sa prezinte detaliile de stocare a datelor pastrate în calculator. A fost definit modelul datelor întrucât este compus dintr-un grup de concepte ce specifica structura bazei de date împreuna cu un set de operatii necesare manipularii lor. Modelul ER este o forma simpla de prezentare a structurii datelor, utilizat în procesul constructiei bazei de date, dar si în alte aplicatii în care apare entitati si relatii între acestea.

Modelul entitate-relatie urmareste obtinerea unei reprezentari fidele, utilizând concepte specifice, a realitatii (problemei de rezolvat ce urmeaza a fi informatizata). Aceasta reprezentare a lumii reale se va realiza facându-se abstractie de orice restrictie fie ea informatica sau organizatorica. Pornind de la semantica obiectelor lumii reale si a legaturilor stabilite între acestea modelul entitate-relatie serveste în egala masura ca un mijloc de comunicare între modelator (informatician) si viitorul utilizator al sistemului (beneficiarul), care descrie realitatea supusa modelarii în conformitate cu propria lui perceptie.

Concepte de baza utilizate de catre modelul entitate-relatie

În continuare, vom prezenta conceptele de baza utilizate de catre modelul entitate-relatie.

ENTITATEA reprezinta un obiect al realitatii modelate caracterizat printr-o existenta proprie, cu o identitate proprie (care-l face identificabil în raport cu celelalte obiecte de acelasi tip) si o multime de caracteristici care exprima proprietatile acestuia.

Pentru exemplificare, vom lua ca domeniu de studiu gestiunea produselor finite. Entitatile pe care le putem defini sunt: un produs, un bon de predare, o comanda (pentru lansarea în fabricatie a produselor etc.).

Entitatea comanda nr.1113 se defineste prin urmatoarele caracteristici: 20/09/03 (data lansarii), costum dama model A (denumirea produsului finit), 200 (numarul de bucati de fabricat), 2 (sectia de productie în care s-a lansat comanda) etc. Entitatea comanda 1113 are propria identitate, distingându-se clar de celelalte entitati de acelasi tip (celelalte comenzi lansate în executie) prin numarul sau si are o existenta de sine statatoare. (fig.2.34).

Fig.2.34. Entitati apartinând tipului Comanda

Fiecare comanda de productie reprezinta o entitate distincta si independenta în raport cu toate celelalte comenzi lansate.

În activitatea de modelare interesul se focalizeaza pe definirea tipurilor de entitati apartinând problemei de rezolvat si nu pe entitati care reprezinta realizarile tipurilor de entitati. Modelul abstract pe care ni-l ofera modelul entitate-relatie se bazeaza tocmai pe aceste tipuri generice de entitati si a legaturilor stabilite între acestea.

TIP DE ENTITATE reprezinta un concept generic desemnând multimea tuturor entitatilor prezentând aceleasi caracteristici constructive.

Tipul entitatii cunoscut si sub numele de clasa entitatii, este o colectie de entitati care au proprietati sau caracteristici comune. Fiecarui tip de entitate i se atribuie un nume, cât timp numele reprezinta o clasa sau un set de cazuri, el este singular. Cum referirea generala la elementele ce pot fi catalogate ca entitati se face prin notiunea de obiect (desi sensul lui poate fi altul în contextul analizei si proiectarii orientate-obiect), referirea la aceasta se va realiza printr-un substantiv la singular. Se vor folosi litere majuscule, plasate în interiorul dreptunghiului corespunzator entitatii.

Fig.2.35. Entitati si tip de entitate

O instantiere a entitatii sau instanta, numita caz al entitatii sau caz, este o manifestare singulara a unui tip de entitate. Un tip de entitate se descrie o singura data prin modelul datelor, în timp ce mai multe cazuri ale aceluiasi tip de entitate pot fi reprezentate prin datele stocate în bazele de date.

Exemple: produs, comanda, angajat, student, contract etc.

De aceasta data tipul de entitate produs desemneaza ansamblul produselor aflate în catalogul firmei, produse descrise plecând de la aceleasi caracteristici comune: codul produsului, denumirea, unitatea de masura, data omologarii, procent TVA.

Tipurile de entitate student desemneaza ansamblul studentilor caracterizati prin aceleasi trasaturi comune: numar matricol, nume, data nasterii, localitatea, facultatea, specializarea etc.

O entitate poate apartine mai multor tipuri de entitati diferite. De exemplu entitatea Popescu poate apartine si tipului de entitate contribuabil si tipului de entitate angajat si tipului de entitate student.

Fiecare tip de entitate se defineste prin multimea caracteristicilor comune apartinând entitatilor tipului.

ATRIBUTUL defineste o proprietate distincta a unei entitati. Fiecare atribut prezinta un domeniu, adica o multime de valori admise. Într-o entitate se regasesc realizari corespunzatoare caracteristicilor definitorii pentru tipul de entitate.

Prin intermediul atributelor entitatea poate fi descrisa din punct de vedere informational ca o componenta a structurii bazei informationale. În aceasta viziune atributul poate fi considerat ca o variabila careia i se pot asocia o multime de valori, cu mentiunea ca acestea pot fi grupate sub un identificator comun.

Atributele sunt reflectate printr-un continut concret denumit valoare, care reda nivelul real al fenomenelor si proceselor economice cuantificate prin intermediul entitatii.

Atributele pot fi clasificate în functie de mai multe criterii:

a) Din punct de vedere structural, al complexitatii, acestea pot fi elementare si compuse.

Atributele elementare sunt componente informationale ireductibile ce nu mai pot fi descompuse în alte atribute

(COD-MAT, DEN-MAT, UM, PREŢ etc.).

Atributele compuse sunt componente informationale reductibile ce pot fi descompuse în atribute elementare (DATA poate fi descompusa în atributele elementare ZI, LUNĂ, AN).

b) Din punct de vedere al stabilitatii în timp atributele pot fi constante, variabile si de stare.

Atributele constante îsi mentin valoarea neschimbata pe toata existenta bazei informationale fiind invariabile în timp în functie de semantica atributului (COD-MAT, DEN-MAT, UM etc.).

Atributele variabile îsi schimba valoarea pe parcursul existentei bazei informationale, fiind variabile în timp în functie de semantica atributului (NR.DOC, DATA-DOC, VALOARE etc.).

Atributele de stare îsi schimba valoarea numai la anumite intervale de timp ale existentei bazei informationale prin modificarea efectuata de atributele constante, variabile sau chiar de stare (STOC-INIT, STOC-FINAL, SOLD-DEBITOR, SOLD-CREDITOR etc

c) Dupa realizarile pe care le pot prezenta atributele pot fi: obligatorii, optionale, monovaloare si multivaloare.

Atributele obligatorii (trebuie sa prezinte obligatoriu o realizare, ceea ce corespunde sintagmei NOT NULL - orice realizare), exemplu: atributul data nasterii, nume student.

Atributele optionale (sunt atribute care pot sa nu prezinte nici o valoare (realizare) în cadrul unei entitati (de exemplu atributele numar telefon, fax, e-mail - nu toate persoanele au telefon, fax, e-mail).

Atributele monovaloare prezinta o singura valoare în cadrul unei entitati (nume student, nr.matricol, data nasterii, codul numeric personal)

Atributele multivaloare prezinta mai multe realizari în cadrul aceleiasi entitati (ANGAJAT, entitatea Ionescu Dan poate prezenta pentru atributul STUDII mai multe valori: Facultatea de Electrotehnica, facultatea de Drept).

Problema de modelat este adesea deosebit de complexa în cadrul ei putându-se identifica obiecte simple, compozite si/sau complexe.

În modelul entitate-relatie obiectelor lumii reale le corespund entitati, iar entitatile definite prin aceleasi caracteristici formeaza un tip de entitate, ceea ce înseamna ca obiectelor simple, le va corespunde în modelul conceptual al datelor câte un tip de entitate.

Exemplu: pentru conturile cuprinse în planul de conturi se poate defini în cadrul modelului conceptual al datelor tipul de entitate cont.

Obiectele compozite se caracterizeaza prin faptul ca ele contin una sau mai multe caracteristici multivaloare (carora în modelul entitate-relatie le vor corespunde atribute multivaloare). Aceasta va determina ca în modelul conceptual optimizat al datelor acestui obiect compozit sa-i corespunda mai multe tipuri de entitati (atributele multivaloare se vor regasi într-un tip de entitate distinct).

Obiectele compuse sunt decompozabile ele regrupând în structura lor obiecte simple între care exista o anumita legatura. Chiar daca în modelul entitate-relatie initial pentru un obiect compus s-a definit un singur tip de entitate, ulterior acesta se va descompune în tipuri de entitati de sine statatoare corespunzatoare obiectelor elementare care intra în structura obiectului compus.

Fiecare tip de entitate prezinta un IDENTIFICATOR reprezentat de un atribut sau un grup minimal de atribute al caror rol este de a permite identificarea în mod unic, fara echivoc, a entitatilor.

De multe ori identificatorul este reprezentat de un atribut de tip "numar de ordine" (incrementat cu 1 pentru fiecare noua valoare atribuita) sau de un cod (constructie artificiala având o anumita semnificatie).

Fig.2.36. Reprezentarea obiectelor compozite sub forma de tipuri de entitati

Exemple, pentru tipul de entitate PRODUS (descriind caracteristicile produselor din nomenclatorul de fabricatie) identificatorul va fi COD PRODUS (element codificat), în cazul entitatii BON CONSUM identificatorul va fi atributul numar (atribut de tip numar de ordine).

În reprezentarea grafica a tipului de entitate identificatorul este marcat distinct prin subliniere.

Fig.2.37. Reprezentarea grafica a tipului de entitate PRODUS

ASOCIEREA dintre entitati exprima legatura stabilita între acestea si rolul pe care îl joaca fiecare entitate participanta la legatura. O relatie este o asociere între cazurile/instantele uneia sau mai multor tipuri de entitati care prezinta interes pentru organizatie. Ele se pot simboliza printr-un romb. Relatiile sunt redate prin verbe. Exprimând o legatura între entitati ea nu are o existenta de sine statatoare.

O relatie poate prezenta unul sau mai multe atribute proprii cu rol de a caracteriza legatura stabilita între entitatile participante la asociere.

O clasa, este reprezentata printr-un dreptunghi divizat în trei parti: portiunea superioara reprezinta numele clasei, cea din mijloc atributele sale si cea inferioara operatiile asociate clasei. Atributele, trebuie sa fie date de tipuri simple (numerice, siruri de caractere etc.).

lucreaza

pentru

Fig.2.39. Asocierea multi-la-unu

Asocierea lucreaza pentru, este de ordinul multi-la-unu deoarece o companie poate angaja o multime de persoane în timp ce un angajat poate activa, în acelasi interval de timp, la o singura companie (cu carte de munca). Pot exista însa, si cazuri în care aceasta asociere sa fie de tipul multi-la-multi.

Multiplicitatea depinde de modul de abordare al problemei, deci de definire a frontierelor acesteia, fiind dependenta de context. Abordarea cea mai frecvent întâlnita, este reducerea multiplicitatii unei asocieri la una de tip unu-la-mai multi sau chiar unu-la-unu. Este important sa nu se piarda prea mult timp cu stabilirea exacta a ordinelor de multiplicitate în timpul analizei, deoarece aceasta se poate modifica în timpul proiectarii sistemului sau chiar implemetarii sale. O solutie sigura, este de a utiliza multiplicitatea de ordinul multi-la-multi.

O relatie care se poate întâlni din când în când este relatia unu la unu (one-to-one). Doua tabele unite printr-o relatie unu la unu sunt similare în practica, cu un tabel care cuprinde câmpurile din ambele tabele, dar cu toate acestea, devine oportuna utilizarea unei astfel de relatii, în conditiile utilizarii unor structuri foarte mari care au nevoie de peste 255 de câmpuri, când este necesara stocarea locala a unor date suplimentare (în cazul în care tabelul principal este un tabel asociat de pe un server, asigurarea unei securitati a datelor când câmpurile celui de-al doilea tabel vor fi facute disponibile pentru persoanele care supervizeaza.

Relatia de unu la mai multi (one-to-may), este cea mai cunoscuta si cea mai utila relatie. Tabelul din partea "unu" a relatiei trebuie sa aiba o cheie primara, iar tabelul din partea "mai multi" trebuie sa contina un câmp similar, indicând înregistrarea la care este legat. În mod normal, cheia straina trebuie sa fie de acelasi tip si sa aiba aceeasi dimensiune ca si cheia primara.

O factura poate avea mai multe rânduri de elemente, fiind nevoie de doua tabele denumite Facturi si Pozitii din Factura. În plus un client poate avea mai multe facturi, în consecinta va mai exista o relatie de unu la mai multi între tabelele Clienti si Facturi.

Unele situatii nu se potrivesc cu o relatie simpla de la unu la mai multi. De exemplu, considerând actualul sistem de credite de la Facultatea de stiinte Economice, sarcina administratorului acestei facultati este sa tina evidenta tuturor studentilor înscrisi la facultate, precum si a tuturor cursurilor pe care aceasta le ofera. Se pune întrebarea care este relatia dintre studenti si cursuri, deoarece un student este înscris la mai multe cursuri, dar de asemenea un curs este tinut pentru mai multi studenti. Deci putem spune ca aceasta relatie este de la mai multi la mai multi (many-to-many).

Pentru rezolvarea acestei relatii solutia consta în crearea unui tabel intermediar care "sparge" relatia de mai multi la mai multi într-o pereche de relatii de la unu la mai multi. În cazul exemplului anterior, tabelul intermediar ar putea fi denumit Înscrieri. Tabelul Înscrieri cuprinde numai doua câmpuri: IdentificatorStudent si IdentificatorCurs. De fiecare data când un student se înscrie la un curs, apare câte o înregistrare în tabelul Înscrieri, ceea ce determina existenta unei relatii de la unu la mai multi între tabelele Studenti si Înscrieri si tot a unei relatii de la unu la mai multi între tabelele Cursuri si Înscrieri.

Figura urmatoare prezinta acest tip de relatii sub forma unei diagrame:

	TabelulStudenti IdentificatorStudent NumeDeFamilie Prenume
			TabelInscrieri IdentificatorStudent IdentificatorCurs

Fig.2.41. Exemplu de diagrama pentru relatiile alternative

Citirea diagramei este:

o marfa se poate asocia sau cu un producator din afara, sau cu productia unitatii;

un producator din afara poate livra mai multe marfuri;

o linie proprie de productie poate livra mai multe marfuri.

Modelarea conceptuala a datelor este un proces pas-cu-pas pentru documentarea cerintelor informationale, concretizata în preocuparea de regasire a structurii datelor, dar si a regulilor prin care se ofera încredere în integritatea acestora.

Regulile economice constituie specificatii/descrieri care ofera integritatea modelului logic datelor. Exista patru tipuri de baza ale regulilor economice.

Restrictii de integritate

Restrictiile de integritate definesc cerintele pe care datele trebuie sa le respecte pentru a fi corecte si coerente în raport cu realitatea pe care o reflecta.

Restrictiile de integritate reprezinta o modalitate de integrarea a semanticii datelor în mod indirect în modelul entitate-asociere pe care astfel îl îmbogatesc.

CUPRINDE CANTITATE

DEPOZITAT STOC DATA STOC

Fig.2.42. Model entitate-relatie

Restrictiile de integritate privesc:

q       valorile pe care le pot lua atributele entitatilor si asocierilor;

q       valorile identificatorilor entitatilor;

q       rolurile jucate de entitati în asocierile la care participa;

q       asocierile stabilite între entitati

Pentru modelul prezentat în figura de mai sus, pot fi definite urmatoarele restrictii de integritate privitoare la realizarile atributelor: data documentului sa fie anterioara datei curente sau egala cu aceasta, cota de TVA poate fi 0% sau 19%, produsul cel mai vechi din nomenclatorul de fabricatie a fost omologat în 12.12. 2005, codul gestiunii poate lua valori în multimea M=, iar unitatile de masura sunt kg si BUC.

Restrictiile de integritate pot fi statice (se verifica permanent) sau dinamice (privesc evolutia în timp a datelor). De exemplu restrictiile referitoare la gestiune si unitatile de masura sunt statice. Restrictia privind cota de TVA este dinamica ea putându-se modifica în timp, în conformitate cu prevederile fiscale în vigoare.

În cazul entitatii STUDENT, alaturi de atributele numar matricol si nume poate fi definit si atributul fel student (bursier/nebursier). Atributul felul studentului este dinamic el modificându-si valoarea în timp.

Restrictii de domeniu

Un domeniu este un set al tuturor tipurilor de date si al intervalelor de valori în care trebuie sa se încadreze atributele.

Restrictiile de domeniu reprezinta conditii (reguli) care privesc ansamblul de valori admise pentru un atribut în cadrul tipului sau domeniului sau. Restrictiile pot viza realizarile unui/unor atribute apartinând unei aceleiasi entitati sau asocieri, caz în care se numesc restrictii intraentitate sau a unui/unor atribute apartinând unor entitati si/sau asocieri diferite, caz în care se numesc restrictii interentitati.

Restrictiile de domeniu se pot exprima cu privire la:

q       Continutul unui singur atribut al unei entitati sau asocieri

Unitate Masura = ;

TVA=;

Cantitate>0(cantitatea este un atribut definit pentru relatia din fig.2.39. (&&&Entitate)

DATA DOC apartine intervalului [01/01/05, 12/31/06]

q       Corelatiile ce trebuie sa se respecte între valorile mai multor atribute sau asocieri

De exemplu, daca GESTIUNE=1 atunci COD PRODUS =. În gestiunea 1 se stocheaza doar produsele având codurile în multimea .

Produsul având codul 17 se masoara în kg: cod produs = 17, UM = kg.

q       Corelatiile ce trebuie sa existe între atributele apartinând mai multor entitati sau relatii diferite

Data-stoc>Data omologarii

Cantitate<=Stoc

q       Corelatii realizate pe baza unor valori obtinute prin operatii de sintetizare (însumare, calculul mediei, valorile minime/maxime etc.) a unui ansamblu de entitati.

Valoarea medie a pretului<=1.000.000

Restrictii structurale

Identificarea entitatilor

Fiecare entitate va trebui sa poata fi identificata fara echivoc. Acest lucru impune ca identificatorul entitatii sa ia valori unice diferite de NULL (NULL înseamna ca nu s-a atribuit nici o valoare).

În definirea modelului entitate-relatie se pot întâlni cazuri mai speciale legate de identificarea entitatilor:

nu se poate defini un identificator sub forma unui atribut/grup de atribute pentru un anumit tip de entitate;

Tipul de entitate Prezenta are rolul de a retine informatia privitoare la prezenta fiecarui angajat. Daca analizam multimea atributelor apartinând acestui tip de entitate constatam ca nu exista nici un atribut/grup de atribute care sa poata juca rol de identificator. Identificarea se realizeaza prin rolul Realizeaza pe care îl joaca tipul de entitate ANGAJAT în tipul de asociere înregistreaza.

Înregistreaza Luna

Fig.2.43.

Identificarea prin rol a entitatilor se poate realiza doar daca asocierea în cauza nu este ciclica (unara) iar cardinalitatea cuplului entitate identificata-asociere este 1,1 iar cardinalitatea cuplului entitate identificator-asociere este 1,1 sau 0,1.

Identificarea unei entitati se poate realiza prin atributele proprii împreuna cu rolurile jucate de alte tipuri de entitati.

3. Restrictii de integritate pe roluri

Un rol, reprezinta o extremitate a unei asocieri. Asocierile binare au doua roluri, câte unul pentru fiecare clasa. Vom considera, clasele Personal si Companie. Exista o multime de asocieri posibile între aceste doua clase, în care instantele pot juca diferite roluri.

pentru Personal

angajat, manager, ofiter de securitate, programator, director

pentru Companie

angajeaza, membrul în consortiu, producator

1Angajati n 1 Compania

n

management functie nume asociat

performanta salariu

Fig.2.44.

Plecând de la rolurile jucate de entitati în cadrul relatiilor putem defini o serie de restrictii de integritate si anume: de egalitate, incluziune si excluziune de roluri.

Restrictia de incluziune de roluri statueaza faptul ca daca o entitate joaca rolul R1 în relatia A1 atunci va trebui sa joace si rolul R2 în asocierea A2. Rezulta ca rolul R1 include (implica prin incluziune) rolul R2.

Restrictia de egalitate pe roluri - egalitatea presupune ca restrictia de incluziune între roluri sa fie reciproca.

Restrictia de excluziune de roluri - excluziunea de roluri specifica faptul ca un rol R1 jucat de o entitate E1 în relatia A1 exclude existenta rolului R2 jucat în relatia A2.

În ceea ce priveste modelul obiectual de organizare a datelor, desi importanta acestuia pentru viitorul bazelor de date este indiscutabila, nu exista un model unic, unanim recu­noscut si utilizat, de baza de date obiectuala. Prin comparatie cu modelul relational, care este foarte bine fundamentat teoretic, se considera ca, de fapt, în ceea ce priveste "tehno­logia" obiectuala, practica a luat-o înaintea teoriei. Este si neajunsul cel mai des invocat de catre partizanii "relationalului".

În fapt, modelele de baze de date obiectuale deriva din limbajele-obiect si modelele de date semantice. Acestea din urma, inspirate din retelele semantice specifice inteligentei arti­ficiale, sunt rezultanta evolutiei modelelor de organizare a datelor, de la relational si "tre­când" prin modelul entitati-asociatii. Obiectivul comun al acestor modele este de a îngloba întreaga semantica a datelor, inclusiv concepte ca entitate, identitatea entitatii, asociatie, agre­gare si generalizare. Bazele de date orientate pe obiecte trebuie sa permita manipularea de obiecte persistente, plecând de la un limbaj obiectual. O BDO reprezinta o organizare coerenta de obiecte persistente care sunt partajate simultan de mai multi utilizatori. Compara­tiv cu ceea ce, în mod clasic, reprezinta schema unei BD, schema unei BDO contine defini­tiile structurale (atribute si tipuri sau clase) si comportamentul (metodele) fiecarui obiect.

Modelele orientate pe înregistrari permit descrierea datelor la nivel logic si extern. Spre deosebire de cele obiectuale, sunt utilizate pentru reprezentarea atât a structurii logice a bazei, cât si a continutului (sau realizarii) acesteia. Din pacate, cea mai mare parte a mode­lelor din aceasta clasa nu permit specificarea tuturor restrictiilor pe care trebuie sa le îndepli­neasca datele aflate în baza.

2.4.3. Modele conceptuale de nivel înalt

Se prezinta în figura 2.45. o descriere simplificata a procesului de constructie a unei baze de date. Asa cum se observa în figura un prim pas este cel al colectarii si analizei cererilor, etapa prin care proiectantul bazei de date prospecteaza utilizatorii în vederea stabilirii necesitatilor si documentarii asupra cererilor acestora. Rezultatul acestei etape este marcat de un set de cerinte clar formulate, într-o maniera concisa.

O data cererile formulate precis si concis se poate trece la elaborarea schemei conceptuale utilizând un model de nivel înalt. Schema conceptuala reprezinta o descriere concisa a datelor utilizatorului incluzând descrierea detaliata a tipurilor de date, a relatiilor si restrictiilor acestora. Deoarece pâna la acest moment nu se includ detalii de implementare, rezultatele pot fi comunicate utilizatorilor chiar daca sunt nespecializati în domeniu, si analizate de catre acestia, având ca obiectiv eliminarea eventualelor conflicte ce pot aparea.

Fig. 2.45. Structura procesului de modelarea datelor

Urmatoarea etapa, cea de constructie a bazei de date tinând cont de detaliile actuale, cu ajutorul unui SBD comercial. Astfel se transforma modelul de nivel înalt într-un model de implementare. În final, prin constructia efectiva a bazei de date se specifica structura de stocare interna si organizarea fisierelor în baza de date.

Se dau mai jos cerintele pentru constructia unei baze de date aferenta unei companii, baza de date numita COMPANIE, ce are ca scop ilustrarea procesului descris. Pe parcursul acestui capitol aceasta va fi rafinata ajungându-se in final la modelul ER. În faza preliminara se cunoaste faptul ca Compania are un numar de angajati organizati pe departamente, si urmareste realizarea unor proiecte. Pentru simplitate, se presupune ca dupa analiza cerintelor s-a decis urmatoarea descriere, ca elemente primare, pentru baza de date:

Compania este organizata în departamente, fiecare departament are un nume, un numar de cod, un numar de angajati, putând avea mai multe sedii.

Un departament este implicat în mai multe proiecte, fiecare din ele are un nume, un numar de cod, si o singura locatie.

Se pastreaza pentru fiecare angajat numele, numarul de cod (social security number - ssn), adresa, salariul, sex, data de nastere. Orice angajat este afiliat la un departament, însa poate lucra la mai multe proiecte ce nu sunt neaparat coordonate de acelasi departament. Trebuie deci stocat si numarul de ore alocate saptamânal pentru fiecare proiect. De asemenea, fiecare angajat are un sef direct, numit si supervizor.

Lista persoanelor în întretinerea fiecarui angajat este importanta întrucât este utilizata la calculul impozitului, lista contine numele, sex, data nasterii.

Se remarca faptul ca o astfel de organizare este specifica pentru multe societati comerciale, însa acest model este utilizat doar pentru ilustrarea principiilor generale în utilizarea modelului entitate relatie cât si pentru operatii cu tabele de date.

În figura 2.46. se arata o entitate cu atributele ei.

e₁=

e₂=

Fig. 2.46. Exemple de entitati

Entitatea e₁ reprezinta un angajat, o persoana fizica cu patru atribute, Nume, Adresa, Vârsta, Telefon.

Fiecare angajat este caracterizat de aceleasi atribute, dar fiecare entitate angajat va avea un set propriu de valori ce îl caracterizeaza. Entitatile ce sunt caracterizate de aceleasi atribute se numesc entitati tip. Pentru entitatea tip ANGAJAT având atributele Nume, Vârsta, Salariu, se dau mai jos ca exemplu doua entitati particulare.

e₁(Popescu Vasile, 43, 3880)

e₂(Dumitriu Petre, 32, 3240)

Descrierea atributelor entitatii tip este numita schema entitatii tip si specifica o structura comuna fixata a entitatilor de acelasi tip. Setul instantelor entitatilor individuale la un anumit moment este numita extensie a entitatii tip.

O entitate tip DEPARTAMENT având atributele Nume, Numar, Locatie (Sediu), Manager, Data de la care are aceasta functie. Pentru aceasta entitate atributele cheie pot fi fie Nume, fie Numar.

Entitatea tip PROIECT cu atributele Nume, Numar, Locatie, Departamentul ce coordoneaza proiectul, cu atribut cheie oricare dintre Nume sau Numar.

Entitatea tip ANGAJAT cu atributele Nume, SSN, Sex, Data nasterii, Adresa, Salariu, Departament si Supervizor. Atributele Nume si Adresa pot fi atribute compuse.

O entitate tip ÎNTRETINUT cu atributele Angajat, Nume, Sex, Data de nastere, Tip relatie (referitor la relatia dintre angajat si persoana aflata in întretinere).

În aceasta încercare de definire nu s-a tinut cont de faptul ca un angajat poate sa lucreze la mai multe proiecte, nu apare în acest caz indicat numarul de ore pe saptamâna alocate unui anumit proiect. Poate fi avut în vedere în cadrul entitatii ANGAJAT prin atributul compus Lucreaza_la ce ar avea componentele (Proiect,Ore). O alta alternativa poate fi introducerea unui atribut compus cu mai multe valori la entitatea PROIECT, atribut ce are componentele (Angajat, Ore). Se obtine astfel structura:

DEPARTAMENT

Nume, Numar, , Manager, Data_de_început

PROIECT

Nume, Numar, Locatie, Departament_coordonator

ANGAJAT

Nume(Nume, Initiala, Prenume), SSN, Sex, Adresa, Salariu, Data_nasterii, Departament, Supervizor,

INTRETINUT

Angajat, Nume_departament, Sex, Data_nasterii, Tip_relatie

În entitatile de mai sus atributele compuse s-au reprezentat Între paranteze rotunde, atributele ce pot lua mai multe valori între paranteze acolade. Este important sa existe un singur atribut cheie pentru fiecare entitate tip. În acest caz, formarea unui atribut cheie complex, este o indicatie ca entitatea poate fi sparta în mai multe entitati tip cu numar mai mic de atribute. Ori de câte ori un atribut al unei entitati indica o alta entitate se spune ca între cele doua entitati exista o relatie.

De exemplu relatia LUCREAZA_PENTRU între entitatile tip ANGAJAT si DEPARTAMENT asociaza fiecare angajat cu departamentul pentru care acesta lucreaza. În fig. 2.47. se ilustreaza un exemplu prin care se arata ca angajatii e₁,e₃ si e₆ lucreaza pentru departamentul d₁ si angajatii e₂ si e₄ lucreaza pentru departamentul d₂.

Fig. 2.47. Relatii binare intre entitati

Se defineste rangul sau gradul unei relatii tip ca numarul entitatilor tip participante. Relatia din fig. 2.48. are rangul doi motiv pentru care se spune ca este o relatie binara. O relatie de rangul trei se zice ternara. O astfel de relatie ternara este cea din fig. 2.45. unde fiecare relatie instanta r_i asociaza trei entitati s,p,j.

Fig. 2.48. Relatie de rang trei

Relatiile pot avea orice rang, si pot fi considerate ca fiind formate din mai multe relatii binare. Ca exemplu sa consideram relatia ternara din fig. 2.47. ce include instantele (s,p), (j,p) si (s,j). Cele trei relatii binare între proiectantii si partile unui proiect (instanta (s,p)), între proiect si parte (instanta (j,p)) si între proiectantii unei parti si proiect (instanta (s,j)) au fost reprezentate sub forma unei relatii ternare.

De multe ori este convenabil sa se considere relatia tip în termenii atributelor. Pentru relatia din fig. 2.47. se poate considera un atribut numit Departament al entitatii tip ANGAJAT ale carui valori pentru fiecare entitate angajat este entitatea departament la care angajatul lucreaza. Daca se considera o relatie binara ca un atribut, în particular pentru cea din fig. 2.47. se poate considera fie atributul multinivel Angajat al entitatii DEPARTAMENT, unde valorile pentru fiecare entitate departament contin setul de valori al entitatilor angajat care lucreaza pentru departamentul respectiv, fie un atribut multinivel Departament al entitatii ANGAJAT, unde valorile pentru fiecare entitate angajat contine setul de valori al entitatilor departament la care angajatul lucreaza.

Fiecare entitate tip ce participa într-o relatie tip joaca un rol particular în acea relatie. De exemplu în relatia LUCREAZA_LA entitatea ANGAJAT detine rolul angajatilor pe când entitatea DEPARTAMENT are rolul locului în care angajatii desfasoara activitatea. Este recomandabil ca numele relatiilor sa fie relevante, aceste nume sa indice pe cât posibil rolul jucat de entitati în relatie.

Daca relatia se stabileste între elementele aceleiasi entitati se spune ca s-a stabilit o relatie recursiva. Ca exemplu, relatia SUPERVIZOR se stabileste între angajati si supervizor, relatie în care ambii sunt membrii aceleiasi entitati. Ca exemplu în fig. 2.49. ce exemplifica relatia SUPERVIZOR liniile punctate reprezinta rolul de supervizor, pe când liniile pline reprezinta rolul de supervizat. Angajatul a₁ supervizeaza angajatii a₂ si a₃, angajatul a₄ supervizeaza angajatii a₆ si a₇ si angajatul a₅ supervizeaza angajatii a₁ si a₄.

Fig. 2.49. Relatii între elementele aceleiasi entitati

Restrictiile limiteaza combinatiile posibile ale entitatilor participante intr-o relatie instanta. Pentru baza de date COMPANIE un angajat lucreaza la un singur departament. Se pot distinge doua tipuri de restrictii în relatii si anume restrictia de cardinalitate si cea de participare.

Restrictia de cardinalitate este marcata de numarul relatiilor instanta la care o entitate poate sa participe. Relatia binara LUCREAZA_PENTRU între entitatile DEPARTAMENT si ANGAJAT poseda o cardinalitate de 1:N aratând ca fiecare entitate departament poate fi în relatie cu mai multe entitati angajat fiindca mai multi angajati lucreaza la acelasi departament, pe când un angajat lucreaza într-un singur departament. Obisnuitele cardinalitati sunt 1:1, 1:N, M:N. Un exemplu de cardinalitate 1:1 este relatia binara intre DEPARTAMENT si ANGAJAT stabilita de MANAGER, pentru ca un departament are un singur manager si un manager conduce un singur departament.

Restrictia de participare specifica conditia de existenta a unei entitati în relatie cu o alta entitate cu care este în relatie. Pot exista restrictii de participare partiala sau totala. Daca într-o companie este statuat faptul ca fiecare angajat trebuie sa lucreze la un proiect, atunci acea entitate angajat poate sa existe numai daca este participanta la relatia LUCREAZA_PENTRU. Participarea este numita totala pentru ca fiecare entitate a entitatii tip ANGAJAT este în relatie cu entitatea DEPARTAMENT. Nu acelasi lucru se poate spune despre relatia MANAGER ca implica o participare partiala pentru ca nu toti angajatii unui departament sunt manageri.

Constructia modelului ER pentru baza de date COMPANIE

Se poate la acest moment rafina modelul datelor pentru baza de date COMPANIE, tinând cont de relatiile între entitati tip. Procesul este iterativ in sensul ca daca nu se pot stabili restrictiile structurale se poate relua iterativ procesul pâna la stabilirea completa. La acest exemplu au fost stabilite urmatoarele relatii:

MANAGER - o relatie 1:1 între entitatile tip ANGAJAT si DEPARTAMENT, cu o participare partiala a angajatilor. Participarea departament nu este clar stabilita. Utilizatorul a stabilit ca orice departament are la orice moment un manager ceea ce implica participare totala. Atributul Data de început este asignat la aceasta relatie tip.

LUCREAZA_PENTRU - este o relatie 1:N intre DEPARTAMENT si ANGAJAT, cu participare totala.

CONTROL - o relatie între DEPARTAMENT si PROIECT în care participarea entitatii PROIECT este totala, pe când cea a entitatii DEPARTAMENT este partiala.

SUPERVIZARE - o relatie 1:N între entitatea tip ANGAJAT si aceeasi entitate tip ANGAJAT. În aceasta relatie entitatile particulare joaca rol de supervizor, respectiv supervizat. Ambele participari sunt partiale întrucât nu toti angajatii pot fi supervizori, precum si faptul ca nu toti angajatii sunt supervizati.

LUCREAZA_LA - relatie M:N între entitatile ANGAJAT si PROIECT având atributul Ore, cu participare totala. La un proiect pot lucra mai multi angajati, însa un angajat poate lucra la mai multe proiecte.

INTRETINUT_ANGAJAT - relatie 1:N intre entitatile ANGAJAT si INTRETINUT având ca scop identificarea entitatii slabe INTRETINUT. Participarea este totala pentru întretinuti si partiala pentru angajati.

Odata specificate cele sase relatii se pot elimina atributele redondante, cum sunt pentru baza de date specificata Manager si Data_de_început în entitatea DEPARTAMENT, Departament_coordonator în entitatea PROIECT, Departament, Supervizor si Lucreaza_la de la ANGAJAT, respectiv Angajat de la INTRETINUT. Este foarte important ca redondanta sa fie foarte redusa la momentul constructiei schemei conceptuale. Proiectantul bazei de date trebuie sa se concentreze asupra specificarii structurilor de date si respectarii restrictiilor impuse de utilizatorii bazei de date, asigurând în aceste conditii un optim.

În figura 2.50. este reprezentata diagrama entitate relatie a bazei de date COMPANIE. Entitatile tip sunt reprezentate în dreptunghiuri, relatiile sunt reprezentate prin romburi legate de entitati. Pentru reprezentarea atributelor s-a folosit elipsa indiferent daca atributul este simplu sau compus. Pentru atributele cu mai multe valori s-a utilizat elipsa dublata. Atributele cheie au fost marcate prin subliniere, atributele derivate sunt marcate prin linie întrerupta. Entitatile slabe sunt puse în evidenta prin plasarea în dreptunghiuri cu linii duble, pe când relatia de identificare este plasata în romb cu linii duble. Pe aceeasi diagrama se reprezinta si restrictia de cardinalitate prin atasarea pe fiecare arc de legatura între entitati a cifrelor corespunzatoare.

Fig. 2.50. Exemplu de model Entitate - Relatie

Restrictia structurala de participare este marcata prin linia de legatura dubla la participarea totala si cu linie simpla la participarea partiala. Este reprezentata si o relatie recursiva, cea de SUPERVIZOR. Perechile de numere asociate arcelor specifica restrictia de participare.

2.4.4. Dependentele functionale

Legaturile stabilite între entitatile bazei informationale permit continuarea analizei entitatilor în scopul stabilirii asocierilor dintre atributele componente prin intermediul dependentelor functionale care pot fi simple, multiple, izolate, duble, triple etc.

Dependenta functionala simpla dintre doua atribute este realizata daca în intervalul de existenta al bazei informationale o singura realizare a unuia dintre atribute permite o singura realizare a celuilalt. De exemplu, atributul codul materialului (COD-MAT) determina o singura realizare pentru atributul denumirea materialului (DEN-MAT), deoarece un material are un cod si o denumire unica.

Dependenta functionala multipla dintre doua atribute, este realizata daca în intervalul existent al bazei informationale o realizare a unuia dintre atribute determina mai multe realizari ale celuilalt atribut. De exemplu atributul cod sectie (COD-SECT) determina mai multe realizari pentru atributul codul atelierului (COD-ATEL), deoarece o sectie are mai multe ateliere.

În reprezentarea dependentelor functionale simple sau multiple pot fi utilizate combinatii ale acestora pentru evidentierea cât mai veridica a tuturor legaturilor dintre atribute.

Dependenta functionala izolata dintre atribute este realizata, daca în intervalul de existenta al bazei informationale o dependenta simpla sau multipla nu intra în combinatie cu alta dependenta, proprietate reflectata prin lipsa unor legaturi dintre atributele terminale ale dependentei.

Dependenta functionala dubla sau tripla dintre atribute este realizata prin intercombinarea a doua sau mai multe dependente functionale simple sau multiple. Rezulta ca dependenta este dubla daca se folosesc combinari ale altor doua dependente simple sau multiple si este tripla daca se folosesc trei tipuri de dependente.

Matricea dependentelor functionale

Matricea dependentelor functionale poate fi realizata în doua variante: simplificata si matricea completa.

Matricea simplificata reprezinta un tablou în care coloanele cuprind determinantii dependentelor functionale iar fiecare linie un atribut apartinând multimii atributelor supuse modelarii.

Matricea completa reprezinta un tablou asemanator matricei simplificate cu singura deosebire ca numarul de colane este egal cu numarul liniilor, cu alte cuvinte eticheta de coloana va fi orice atribut (regasit si ca o eticheta de linie) si nu doar atributele/grupurile de atribute cu rol de determinant într-o dependenta functionala.

De exemplu, daca luam un sistem informatic pentru calculatia costurilor, însa ne limitam datorita complexitatii problemei, la segmentul referitor la antecalcul si anume la determinarea consumurilor cu materiile prime si materialele pe comenzi. Ne propunem sa elaboram matricea simplificata a dependentelor functionale pentru atributele necesare elaborarii matricei complete privind consumul de materii prime si materiale, conform fisei tehnologice a produselor.

Multimea atributelor corespunzatoare problemei studiate este formata din: cod produs, denumire produs, cod um (cod unitate de masura), pret produs, cod reper, denumire reper, cantitate reper (în realizarea unui produs finit intra mai multe repere de acelasi fel sau diferite), cod material, denumire material, cantitate normata pe reper, denumire unitate de masura.

ATRIBUTE	DETERMINANŢI
1. Cod produs
2. Denumire produs
3. Cod um
4. Pret produs
5. Cod reper
6. Denumire reper
7. Cantitate reper
8. Cod material
9. Denumire material
10. Cantitate normata pe reper
11. Denumire unitate de masura

Fig.2.51. Matricea simplificata a dependentelor functionale

Analizând tabelul de mai sus, constatam ca fiecare coloana din matrice a fost rezervata unui determinant (se poate stabili anterior o lista a dependentelor functionale). Valoarea 1, la intersectia unei coloane cu o linie, marcheaza existenta unei dependente functionale între atributul determinat înscris la nivelul liniei.

Una din regulile modelului entitate-asociere specifica unicitatea atributelor adica, obligativitatea ca un atribut sa apartina unei singure entitati sau asocieri. Plasarea unui atribut într-o entitate sau alta este determinata de dependenta functionala la care participa în legatura cu identificatorul tipului de entitate. Aceasta înseamna ca în matricea dependentelor functionale, la nivelul fiecarei linii, va trebui sa fie înscrisa o singura valoare 1. În mod distinct, prin subliniere, în cadrul matricei au fost marcate câteva valori 1, care exprima proprietatea de reflexivitate a dependentelor functionale si sunt marcate la intersectia coloanei cu linia corespunzatoare acelorasi atribute (în cazul nostru determinantii). Existenta mai multor valori 1 pe o linie poate fi consecinta unor dependente functionale pure tranzitive care pun în evidenta asocieri ierarhice (numite si restrictii de integritate functionala) între entitatile ale caror identificatori sunt în dependenta functionala.

Matricea completa a dependentelor functionale

În cazul matricei complete numarul de coloane corespunde cu numarul liniilor.

ATRIBUTE

DETERMINANŢI

1. Cod produs

2. Denumire produs

3. Cod um

4. Pret produs

5. Cod reper

6. Denumire reper

7. Cantitate reper

8. Cod material

9. Denumire material

10. Cantitate normata pe reper

11. Denumire unitate de masura

Fig.2.52. Matricea completa a dependentelor functionale

Din analiza matricei complete a dependentelor functionale constatam existenta:

diagonalei de valori 1 care este rezultanta proprietatii de reflexivitate a dependentelor functionale;

dependentelor elementare (prezentând un determinant elementar, un atribut);

dependentelor neelementare al caror determinant este format dintr-un grup de atribute în cazul nostru: cod produs, cod-reper, si cod reper, cod material.

dependentelor tranzitive (cod produs cod material, deoarece cod produs cod reper si cod reper cod material) si multivaloare (cod produs cod reper, cod reper cod material, un produs este format din mai multe repere, iar un reper presupune utilizarea mai multor materiale la realizarea lui) care conduc la aparitia mai multor valori 1 în cadrul liniilor matricei.

Analiza informatiei din matrice (completa sau simplificata) va conduce la definirea unor tipuri de entitati optimizate în cadrul carora sa fie eliminate dependentele functionale complexe. O solutie de definire a tipurilor de entitati, plecând de la identificarea dependentelor functionale, este reprezentata de diagrama dependentelor.

Diagrama dependentelor functionale

Diagrama dependentelor functionale reprezinta un graf construit plecând de la dependentele functionale identificate, pe baza caruia se pot defini tipurile de entitati ale modelului entitate-relatie, astfel încât în cadrul acestora sa nu se mai manifeste dependente functionale complexe.

Cvasidependentele functionale sunt cele pentru care cunoasterea unei valori pentru determinant nu antreneaza sistematic cunoasterea unei valori a determinatului. De multe ori aceste cvasi dependente functionale sunt reciproce (asa cum este cazul dependentei dintre codul produsului si codul reperului).

COD PRODUS COD REPER

Fig. 2.53. Graf al dependentelor functionale

Un produs este format din mai multe repere, dar si un anumit reper participa la realizarea mai multor produse.

Un graf al dependentelor functionale pune în evidenta dependente functionale tranzitive, astfel dependenta tranzitiva df3 va trebui eliminata.

Studiul diagramei dependentelor functionale permite identificarea cu usurinta a urmatoarelor:

determinantii dependentelor functionale;

cvasi dependentele functionale

dependentele functionale prezentând determinantul format dintr-un grup de atribute.

Trecerea de la diagrama dependentelor functionale la modelul entitate-asociere se realizeaza pe baza urmatoarelor reguli:

R1. Pentru fiecare dependenta functionala în care determinantul este elementar se creeaza un tip de entitate în care determinantul df joaca rolul de identificator.

Exemplu:

COD-PRODUS PREŢLIVRARE

Rezulta ca se va defini un tip de entitate, numit PRODUS, în care COD PRODUS va avea rol de identificator. Pentru exemplu luat anterior, si aplicând prima regula, vom avea:

Fig. 2.54.Tipuri de entitati definite

R2. Toate atributele participând la dependentele functionale care prezinta acelasi determinant se vor grupa în cadrul aceluiasi tip de entitate prezentând drept identificator atributul cu rol de determinant în cadrul dependentelor functionale.

În urma aplicarii acestei reguli, obtinem:

Fig. 2.55.Gruparea atributelor în tipuri de entitati

R3. Fiecarei dependenta functionala între identificatorii tipurilor de entitati îi va corespunde în modelul entitate-relatie un tip de asociere. Aceasta asociere este ierarhica (restrictie de integritate functionala) când cardinalitatea maximala pentru cuplul E1A este 1 si pentru cuplul E2A este n.

Aplicând aceasta regula obtinem fig.2.56.

Are

Masurat

Prezinta

Fig. 2.56. Definirea tipurilor de asocieri

R4. Pentru fiecare dependenta functionala ne-elementara (cu determinantul format dintr-un grup de atribute, identificatorii în cadrul tipurilor de entitati definite) se creeaza un tip de asociere neierarhic (restrictie de integritate multipla) definita prin atributul cu rol de determinant în dependenta functionala.

Aplicând regula R4 obtinem fig.2.57.

Consum Cantitate

Format Cant reper

Prezinta

Fig.2.57. Modelul entitate-asociatie

Reguli de verificare si normalizare a modelarii conceptuale a datelor

A. Reguli de verificare a modelarii conceptuale a datelor

Realizarea modelului conceptual al datelor presupune respectarea anumitor reguli:

Regula de unicitate a numelor se aplica tuturor elementelor care participa la definirea modelarii conceptuale a datelor: tipuri de entitati, tipuri de asocieri, atribute roluri.Aceasta regula impune eliminarea omonimelor si sinonimelor din cadrul modelului. Nu trebuie sa existe elemente diferite care sa poarte acelasi nume sau doua nume diferite sa fie atribuite aceluiasi element.

Regula unicitatii atributelor (neredondantei) impune ca un atribut sa nu participe decât la definirea unui tip de entitate sau a unui tip de asociere.

Matricea dependentelor functionale semnaleaza când aceasta regula este încalcata (în afara determinantilor);

Regula de unicitate a asocierilor: pentru fiecare realizare a asocierii nu poate sa existe decât o singura realizare a fiecarei entitati participante la asociere si invers;

Regula proprietatilor si determinantului unei entitati: daca un atribut depinde de mai multi determinanti, acestia din urma reprezentând identificatorii mai multor tipuri de entitati, atunci el trebuie sa defineasca tipul de asociere dintre aceste tipuri de entitati;

Atributele derivabile se caracterizeaza prin faptul ca realizarile lor s-au obtinut prin algoritmi de calcul pe baza altor atribute. Se recomanda ca în modelarea conceptuala a datelor sa nu se regaseasca atribute calculate.

Atributele decompozabile pot fi mentinute în modelarii conceptuale a datelor daca prelucrarile nu impun descompunerea lor pe componente elementare. (adresa)

Minimizarea identificatorilor tipurilor de entitati este o regula aplicabila în cazul identificatorilor compusi (formati dintr-un grup de atribute) si urmareste eliminarea dependentelor partiale (un atribut al tipului de entitate este determinat de o parte a identificatorului).

Valoarea NULL prezentata de atribute care nu au un rol de identificator în cadrul entitatii (atribute cu realizari optionale) conduc la ideea rafinarii modelarii conceptuale a datelor prin definirea unor subtipuri de entitati care sa cuprinda doar atribute specifice acestuia. Atributele cu rol de identificator al entitatilor trebuie sa prezinte valori unice si nenule.

Reguli de normalizare

Normalizarea vizeaza atributele apartinând entitatilor pe care le analizeaza cu scopul eliminarii anomaliilor, reducerii redundantelor si definirii unor tipuri de entitati libere de dependentele functionale tranzitive si multivaloare. Prin analiza la nivelul entitatilor definite de modelul entitate-asociatie, procesul normalizarii conduce la definirea de tipuri de entitati suplimentare sau la modificarea unora deja definite.

Teoria normalizarii este fundamentata pe conceptul de forma normala definita drept stadiu de optimizare a tipurilor de entitati definite. Normalizarea se realizeaza prin parcurgerea succesiva a mai multor forme normale (FN) fiecare FN conservând cerintele formulate de FN precedenta.

Procesul normalizarii se poate desfasura în doua abordari:

Varianta top-down, caracterizata prin urmarirea respectarii formelor normale la nivelul entitatilor;

Varianta bottom-up caracterizata prin definirea unui tip de entitate unic înglobând toate atributele modelului entitate-relatie la nivelul caruia sa se identifice multimea dependentelor functionale existente între atribute - este mai putin aplicata în practica, fiind mult mai laborioasa.

Nu vom aborda aici, în detaliu, metodologia de normalizare a unei baze de date relationale (tehnica normalizarii tabelelor), ci o vom prezenta doar la nivel principial. Vom folosi pentru exemplificare o baza de date în care se doreste memorarea facturilor emise si primite de o unitate economica.

O factura însoteste actul de vânzare-cumparare a unuia sau mai multor articole (produse sau servicii), si este compusa dintr-un antet, care contine date referitoare la actul de vânzare în ansamblul sau (date despre vânzator si cumparator, data calendaristica când se face vânzarea, numarul de înregistrare al facturii etc.), si dintr-o sectiune în care sunt descrise articolele (produsele) ce fac obiectul vânzarii (denumirea, cantitatea si pretul unitar, TVA-ul etc.). Numarul de articole vândute printr-o singura factura difera de la caz la caz, fiind variabil de la o factura la alta.

Furnizor...........................  Cumparator...........................

.............. (den., forma jurid.)............ (den., forma jurid.)...............

Nr.ord.registru com........... Nr.ord.registru com.............

Localitatea.........................  Localitatea...........................

Judetul.......... ..... ......   Judetul.......... ..... ...... ..

Contul.......... ..... ...... .  Contul.......... ..... ...... ...

Banca.......... ..... ...... ..  Banca.......... ..... ...... ....

FACTURA Seria FE Nr. 408768

	Nr.factura.......... ..... ...... ................. Data (zi, luna, an).......... ..... ...... ..... Nr.aviz însotire marfa..............................

Nr. Crt.	Denumirea produselor sau serviciilor	U/M		Cantitate	Pret unitar	Valoare lei	Valoare TVA lei	Valoare factura
0		2			4	5	6	7
Semnatura si stampila Furnizorului			Date privind expeditia Numele delegatului.......... ..... ...... ..... Mijlocul de transport..................... Nr. ............................. Expedierea s-a facut la Data de............ ora................... Semnaturile..........				TOTAL Semnatura de primire

Vom propune pentru început o structura a bazei de date FACTURI, formata dintr-o singura tabela, cu urmatoarea structura:

FACTURI
Numar factura	Data	Seria	Vânzator (denumire, cod fiscal, cont, banca)	Cumparator (denumire,cod fiscal,cont, banca)	Mijloc de Transport

Observam ca fiecare factura este identificata printr-un cod numeric (numarul facturii), care pentru a putea fi folosit pe post de cheie primara a tabelei, trebuie sa fie unic în cadrul bazei de date - câmpul a fost subliniat, pentru a pune în evidenta aceasta functie a sa. În structura de mai sus nu a fost detaliata partea referitoare la articolele facturii.

Aducerea bazei de date la prima forma normala (FN1)

Fiecare entitate trebuie sa prezinte un identificator prezentând valori unice nenule.

Pentru a trece o baza de date la prima forma normala - FN1 trebuie eliminate câmpurile compuse (sau neatomice) si cele repetitive. Primul tip de câmpuri, cele compuse, este format din acele câmpuri care reprezinta o concatenare a mai multor valori. În exemplul de mai sus câmpul Vânzator (la fel ca si Cumparator) reprezinta de fapt o concatenare a mai multor câmpuri simple: codul vânzatorului, denumirea, codul sau fiscal, contul si banca.

Câmpul vânzator, fiind unul compus, se va sparge în mai multe câmpuri elementare, astfel:

FACTURI
Numar factura	Data	Seria	Cod Vânza-tor	Denumire Vânzator	Cod fiscal vânza-tor	Cont vânza-tor	Banca vânzator	Cod cumpa-rator
....	....		.......		......	......	.......

Cel de-al doilea tip de câmpuri care trebuie prelucrate în aceasta etapa (cea de trecere la prima forma normala) este cel al câmpurilor repetitive. Acestea descriu acelasi tip de entitati, numarul fiind însa variabil. Pentru a pune în evidenta câmpurile repetitive sa detaliem structura tabelei FACTURI, în sectiunea referitoare la articolele facturilor:

FACTURI
Numar factura		Articol 1					Articol 2		Articol  3
		Cod	Denumire	Unitate masura	Cantitate		Cod		Cod
	..

Se observa în structura de mai sus cum într-o înregistrare a tabelei FACTURI (în care este memorata complet o singura factura) sunt memorate date referitoare la trei articole. Prin urmare o factura memorata în aceasta baza de date poate contine maxim trei articole, ceea ce reprezinta pentru utilizator o serioasa limitare. Am putea mari acest numar la, sa zicem 20. Acum numarul de articole poate satisface un contabil nepretentios, dar ce se întâmpla daca majoritatea facturilor contin unul sau doua articole, în acest caz, majoritatea înregistrarilor bazei de date vor contine 18 sau 19 articole necompletate, ceea ce constituie o mare risipa de spatiu de memorare.

Câmpurile Articol 1, Articol 2, Articol 3 puse în evidenta în exemplul ales, reprezinta câmpuri repetitive. Ele trebuie eliminate din baza de date, operatie care se face astfel: se introduce în baza de date un singur asemenea câmp, o factura urmând a se întinde acum pe mai multe înregistrari ale tabelei (atâtea înregistrari câte articole are factura). Pentru a tine evidenta articolelor din cadrul unei facturi vom introduce în tabela un nou câmp, pe care îl vom denumi: Numar articol.

Noua structura a bazei de date Facturi va fi urmatoarea:

FACTURI
Numar factura	Data	Seria	Cod vânzator	Denumire vânzator		Nr articol	Cod art	Denumire articol
........	.....	......	.......			......

Observam în structura de mai sus, ca, pentru identificarea unei înregistrari din tabela, se folosesc doua câmpuri: numarul facturii si numarul articolului din cadrul acesteia. Prin urmare, noua cheie a tabelei va fi construita prin concatenarea celor doua câmpuri (subliniate în structura de mai sus).

Aducerea bazei de date la a doua forma normala (FN2)- toate atributele entitatii, altele decât identificatorul, trebuie sa fie în dependenta functionala completa si directa cu identificatorul entitatii.

Odata baza de date adusa la prima forma normala, se trece la urmatoarea etapa de optimizare (normalizare), cea de aducere la a doua forma normala FN2. Aceasta a doua forma a bazei de date se caracterizeaza prin faptul ca nu contine dependente functionale partiale, ceea ce înseamna ca toate câmpurile tabelei depind doar de cheia primara a acesteia (nu de parti ale ei).

Odata operate schimbarile anterioare, în tabela FACTURI se obtin o serie de anomalii, ce trebuie eliminate. Sa observam câmpul Data (si alte câmpuri din antetul facturii), care nu depind biunivoc de noua cheie primara a tabelei, formata din câmpurile Numar factura si Numar articol, ci doar de o parte a acesteia, adica de câmpul Numar factura. Acesta este un exemplu de dependenta functionala partiala, ce trebuie eliminata din tabela, pentru ca aceasta sa fie în FN2.

Solutia este mutarea câmpurilor care formeaza antetul facturii (care depind doar de Numar factura). Noile tabele le vom numi ANTET si ARTICOLE, pastrând numele de FACTURI pentru întreaga baza de date.

ANTET
Numar factura	Data	Seria	Cod vânzator

ARTICOLE
Numar factura	Numar articol	Cod articol
.....

Fiecare factura va fi memorata în baza de date (care acum este compusa din tabele) printr-o singura înregistrare în tabela ANTET si una sau mai multe înregistrari în tabela ARTICOLE (atâtea înregistrari câte articole contine factura). Legatura dintre cele doua tabele este realizata printr-un câmp comun, Numar factura.

Observam de asemenea, cheile celor doua tabele: Numar factura în tabela ANTET si combinatia Numar factura-Numar articol în tabela ARTICOLE.

Aducerea bazei de date la a treia forma normala (FN3) - toate atributele trebuie sa depinda complet de identificatorul asocierii (identificatorii entitatilor participante la asociere) iar fiecare atribut trebuie sa depinda de întregul identificator si nu de o parte a acestuia.

Forma normala trei, a unei baze de date se caracterizeaza prin aceea ca nu contine dependente functionale tranzitive. Aceste dependente se obtin atunci când un câmp X depinde de un alt câmp Y, care la rândul lui depinde de un altul Z. Aceste dependente din cadrul unei tabele trebuie eliminate, în caz contrar putând aparea o serie de anomalii nedorite.

Sa luam, de exemplu, câmpul Denumire vânzator, care depinde biunivoc de câmpul Cod vânzator (fiecare vânzator, identificat printr-un cod unic, are o denumire unica). La rândul lui câmpul Cod vânzator depinde biunivoc de câmpul cheie primara a tabelei ANTET, adica de câmpul Numar factura. Dar câmpul Denumire vânzator depinde direct si de câmpul Numar factura, deoarece fiecare factura are o singura denumire de vânzator.

Eliminarea acestei dependente se realizeaza prin construirea unei noi tabele folosita la memorarea datelor despre vânzatorii înscrisi pe facturi. Dar cum aceeasi situatie se întâlneste si în cazul datelor despre cumparatori, vom construi o tabela mai generala, în care vom introduce toti vânzatorii si cumparatorii, tabela pe care o vom denumi CLIENŢI. În aceasta tabela vom introduce toate câmpurile continând date despre clienti, împreuna cu codul acestora si cu cheia primara a tabelei din care au fost extrase aceste câmpuri (adica numar factura din tabele ANTET). În tabela ANTET ramâne Cod vânzator (si Cod cumparator), pentru a face astfel legatura dintre cele doua tabele.

Prin urmare vom avea urmatoarea structura a tabelei:

						CLIENŢI
						Cod client	Denumire	Cod fiscal
Numar factura	Data	Seria	Cod vânz.	Cod cump

ARTICOLE
Numar factura	Numar articol	Cod articol

Aceeasi problema apare si în cazul produselor din componenta articolelor, care sunt caracterizate de Cod, denumire si Unitate de masura. Câmpul Denumire (la fel si Unitate de masura) depinde de Cod articol, care la rândul lui depinde de cheia primara a tabelei ARTICOLE (combinatia dintre Numar factura si Numar articol). Prin urmare vom construi o noua tabela, numita PRODUSE, cu urmatoarea structura:

CLIENŢI

ANTET

PRODUSE

Cod

Denumire

U/M

ARTICOLE

Cod produs

Formele normale 4 si 5

În continuare, baza de date în FN3 mai poate fi optimizata, aducând-o în FN4 si FN5. Pentru aducerea unei tabele în FN4 este necesara eliminarea dependentelor multivaloare suplimentare (pentru o tabela este permisa numai una singura), iar FN5 implica lipsa dependentelor jonctiune. Nu vom intra aici în detaliile legate de aceste forme normale.

Concluzionând, putem spune ca am stabilit urmatoarea structura a bazei de date FACTURI:

tabela ANTET

Numar factura

Data

Seria

Cod vânzator

Cod cumparator

tabela ARTICOLE

Numar factura

Numar înregistrare

Cod produs

Cantitatea

tabela CLIENŢI

Cod client

Denumirea

Cod fiscal

Cont

Banca

Adresa

tabela PRODUSE

Cod produs

Denumire

Unitate de masura

2.4.5. Reguli de trecere de la modelul entitate-relatie la schema conceptuala a bazei de date relationale

Trecerea de la modelul entitate-relatie la schema conceptuala a bazei de date relationale (modelul logic al datelor în demersul de proiectare) se realizeaza aplicând o serie de reguli. Vom presupune ca s-au definit în etapele anterioare modelul prezentat în figura 2.58.

EMIT Cant_cda

MATERIAL COD_MAT DEN_MAT UM

CUPRINDE CANT-FACT PRET_FACT

DETERMINĂ

STINSĂ

Fig.2.58. Modelul conceptual al datelor

Pentru un material se pot emite mai multe comenzi de aprovizionare. unei comenzi trimise furnizorului, îi pot corespunde 0 (comanda s-a trimis, dar furnizorul nu a livrat marfa), 1 (furnizorul a onorat comanda printr-o singura livrare) sau mai multe facturi (livrarea s-a realizat în transe). O factura este platita printr-un singur document (cec, ordin de plata, etc).

Regula 1. Fiecarei entitati îi este asociata schema unei relatii formata din toate atributele entitatii. Identificatorul entitatii devine cheie primara a relatiei.

Din analiza modelului entitate-relatie prezentat în figura de mai sus, rezulta ca vom defini patru relatii: MATERIAL, COMANDĂ, FACTURA, DOCUMENT.

MATERIAL = (COD_MAT, DEN_MAT, UM)

COMANDA = (NR_COMANDA, DATA_CDA, FURNIZOR)

FACTURA = (NR_FACT, DATA_FACT)

DOCUMENT = (NR_DOC, DATA_DOC, TIP_DOC, SUMA)

Regula2. Daca într-o asociere binara A, fiecarei entitati, prezentând cuplul entitate-relatie, îi este asociata o cardinalitate (0,1) sau (1,1), se adauga în schema relatiei R1 corespunzând entitatii E1 cheia primara a celeilalte relatii, R2 corespunzatoare entitatii E2 participante la asociere.

Vom analiza urmatorul exemplu:

A

Fig.2.59. Asociere binara A

Prin aplicarea regulilor 1 si 2 putem obtine:

R1=(a,b,c,d)

unde atributul d reprezinta o cheie externa în relatia R1

R2=(d,e,f,g)

sau

R1= (a,b,c)

R2=(d,e,f,g,a)

unde a reprezinta o cheie externa în relatia R2

Cheia externa va trebui sa respecte restrictia de integritate referentiala, care cere ca o cheie externa apartinând unei relatii R sa prezinte aceleasi valori pe care acelasi atribut le are în relatia S unde are rolul de cheie primara.

În exemplul de mai sus, a doua regula vizeaza schemele relatiilor DOCUMENT si FACTURA care vor prezenta urmatoare forma:

FACTURA = (NR_FACT, DATA_FACT)

DOCUMENT = (NR_DOC, DATA_DOC, TIP_DOC, SUMA, NR_FACT)

Unde NR_FACT joaca în relatia DOCUMENT rol de cheie externa si va trebui sa respecte restrictia de integritate referentiala (valorile sale trebuie sa corespunda realizarilor pe care le prezinta în relatia FACTURA).

Regula 3. Daca într-o asociere A exista o singura entitate E pentru care cardinalitatea cuplului entitate asociere este egala cu (0,1) sau (1,1) se adauga în schema relatiei R1, ce corespunde entitatii E1 cheia primara a relatiei R2, care corespunde entitatii E2 participante la asociere.

Exemplu:

A

Fig.2.60.

Prin aplicarea regulii 1 si 3 obtinem, relatiile:

R1 = (a,b,c,d)

R2 = (d,e,f,g)

Acest transport al cheii relatiei R2 în schema relatiei R1 (unde va juca rolul de cheie externa) este impus de rolul dominant al primei relatii asupra celei de a doua. Întotdeauna când între doua entitati se stabileste o asociere 1:n înseamna ca entitatea care prezinta pentru cuplul entitate-relatie cardinalitatea (1,n) este dominanta, iar cea de-a doua va fi considerata entitate "fiu" si va primi drept cheie externa cheia primara a entitatii "parinte", iar daca sunt definite atribute pentru asocierea A ele vor fi cuprinse în schema relatiei fiu.

În cazul concret pe care-l analizam regula trei priveste entitatile COMANDA si FACTURA dominanta fiind entitatea COMANDA deoarece prezinta cardinalitatea (0,n) pentru cuplul entitate relatie. Vom obtine astfel:

COMANDA = (NR_COMANDA, DATA_CDA, FURNIZOR)

FACTURA = (NR_FACT, DATA_FACT, NR_COMANDA)

Regula 4. Daca într-o asociere A nu exista nici o entitate E pentru care cardinalitatea cuplului entitate-relatie sa fie egala cu (0,1) sau (1,1) se va defini o a treia relatie cuprinzând în schema sa cheile primare ale celorlalte doua relatii (corespunzatoare entitatilor participante la asociere) împreuna cu toate atributele definite pentru asocierea A.

Exemplu:

A n,i

Fig.2.61.

R1=(a,b,c)

R2=(d,e,f,g)

R3= (a,d,h,i)

În cazul aplicatiei considerate, regula patru se aplica entitatilor MATERIAL si COMANDA, pe de o parte, si MATERIAL si FACTURA, pe de alta parte. Vom obtine:

MATERIAL = (COD_MAT, DEN_MAT,UM)

COMANDA = (NR_COMANDA, DATA_CDA, FURNIZOR)

MATCOMANDAT = (COD_MAT, NR_COMANDA, CANT_CDA)

FACTURA = (NR_FACT, DATA_FACT, NR_COMANDA)

MATFACTURAT=(COD_MAT,NR_FACT, CANT_FACT, PRET_FACT)

Schema conceptuala a bazei de date relationale obtinute este în figura 2.62.