Baze de date relationale

Baze de date relationale

Bazele de date relationale (BDR) utilizeaza modelul de date relational si notiunile aferente. BDR au o solida fundamentare teoretica, in special prin cercetarile de la IBM conduse de E.F.Codd.

BDR este un ansamblu organizat de tabele (relatii) impreuna cu legaturile dintre ele.   Conceptele utilizate la organizarea datelor in BDR si respectiv fisiere sunt prezentate in tabelul 3.1.

Concepte utilizate in organizarea datelor

Tabelul 3.1.

Avantajele BDR fata de fisiere sunt prezentate in tabelul 3.2.

Avantajele BDR

Tabelul 3.2.

Atunci cand dorim sa realizam o baza de date relationala trebuie sa stim clar ce avem de facut, adica sa stabilim obiectivele activitatii noastre. In acest sens, cateva dintre cele mai importante obiective, le prezentam in continuare:

Partitionarea semnifica faptul ca aceleasi date trebuie sa poata fi folosite in moduri diferite de catre diferiti utilizatori;

Deschiderea se refera la faptul ca datele trebuie sa fie usor adaptabile la schimbarile care pot aparea (actualizarea structurii, tipuri noi de date etc.);

Eficienta are in vedere stocarea si prelucrarea datelor, care trebuie sa se faca la costuri cat mai scazute, costuri care sa fie inferioare beneficiilor obtinute;

Reutilizarea inseamna faptul ca fondul de date existent trebuie sa poata fi reutilizat in diferite aplicatii informatice;

Regasirea este o activitate frecventa pe bazele de date si de aceea cererile de regasire trebuie sa poata fi adresate usor de catre toate categoriile de utilizatori, dupa diferite criterii;

Accesul inseamna modul de localizare a datelor si acest lucru trebuie sa poata fi realizat prin diferite moduri de acces, rapid si usor;

Modularizarea presupune faptul ca realizarea BDR trebuie sa se poata face modular pentru generalitate si posibilitatea lucrului in echipa;

Protectia bazei de date trebuie asigurata sub ambele aspecte: securitatea si integritatea datelor;

Redundanta se asigura in limite acceptabile prin implementarea unui model de date pentru baze de date si prin utilizarea unei tehnici de proiectare a BDR. Se asigura astfel, o redundanta minima si controlata;

Independenta datelor fata de programe trebuie asigurata atat la nivel logic cat si fizic.

Bazele de date relationale au evoluat ca un tip special de aplicatii informatice, si anume cele care au organizarea datelor in memoria externa conform unui model de date specific. De aceea, in metodologia de realizare a BDR se parcurg, in cea mai mare parte, cam aceleasi etape ca la realizarea unei aplicatii informatice, cu o serie de aspecte specifice. Pe de alta parte, in literatura de specialitate, sunt diferite propuneri de metodologii de realizare a bazelor de date.

Tinand cont de cele doua aspecte de mai sus, sunt propuse cateva activitati care trebuie parcurse la realizarea unei baze de date. Aceste activitati vor fi regasite, sub aceeasi denumire sau sub denumiri diferite, in majoritatea metodologiilor de realizare a bazelor de date, din literatura de specialitate.

Activitatile (etapele) parcurse pentru realizarea unei BDR sunt: analiza de sistem, proiectarea noului sistem, realizarea componentelor logice, punerea in functiune, dezvoltarea.

1) Scopul analizei de sistem este de a evidentia cerintele aplicatiei si resursele utilizate (studiul), precum si de a evalua aceste cerinte prin modelare (analiza).

Studiul situatiei existente se realizeaza prin: definirea caracteristicilor generale ale unitatii, identificarea activitatilor desfasurate, identificarea resurselor existente (informationale, umane, energetice, echipamente, financiare etc.), identificarea necesitatilor de prelucrare.

Analiza este o activitate de modelare (conceptuala) si se realizeaza sub trei aspecte: structural, dinamic si functional.

a) Analiza structurala evidentiaza, la nivel conceptual, modul de structurare a datelor si a legaturilor dintre ele. Cea mai utilizata tehnica este entitate-asociere. Aceasta contine:

Identificarea entitatilor: fenomene, procese, obiecte concrete sau abstracte (substantivele din prezentarea activitatii descrise) (exemple de entitati: Persoane, Produse, Beneficiari).

Identificarea asocierilor dintre entitati ca fiind legaturile semnificative de un anumit tip (verbele din prezentarea activitatii descrise).

Identificarea atributelor ce caracterizeaza fiecare entitate in parte (exemple de atribute: Marca, Nume, Adresa).

Stabilirea atributelor de identificare unica a realizarilor entitatii, drept chei.

Rezultatul analizei structurale este modelul static (structural) numit si diagrama entitate-asociere. Diagrama entitate-asociere (Entity-Relationship) poate fi generata cu produse software tip CASE (Computer Aided Software Engineering), ca de exemplu Oracle Designer. Pornind de la o astfel de diagrama, se pot construi, in activitatea de proiectare, schemele relatiilor (tabelelor).

b) Analiza dinamica evidentiaza comportamentul elementelor sistemului la anumite evenimente. Una din tehnicile utilizate este diagrama stare-tranzitie. Aceasta presupune:

Identificarea starilor in care se pot afla componentele sistemului.

Identificarea evenimentelor care determina trecerea unei componente dintr-o stare in alta.

Stabilirea tranzitiilor admise intre stari.

Construirea diagramei stare-tranzitie.

Rezultatul analizei dinamice este modelul dinamic.

c) Analiza functionala evidentiaza modul de asigurare a cerintelor informationale (fluxul prelucrarilor) din cadrul sistemului, prin care intrarile sunt transformate in iesiri. Cea mai utilizata tehnica este diagrama de flux al datelor. Conform acestei tehnici se delimiteaza:

Aria de cuprindere a sistemului.

Se identifica sursele de date.

Se identifica modul de circulatie si prelucrare a datelor.

Se identifica apoi rezultatele obtinute.

Rezultatul analizei functionale este modelul functional.

2) Proiectarea structurii bazei de date se face pe baza modelelor realizate in activitatea de analiza. Inainte de proiectarea bazei de date se alege tipul de sistem de gestiune a bazei de date. Alegerea SBGD-ului se face tinand cont de doua aspecte: cerintele aplicatiei (utilizatorului) si performantele tehnice ale SGBD-ului.

Cerintele aplicatiei se refera la: volumul de date estimat a fi memorat si prelucrat in BDR; complexitatea problemei de rezolvat; ponderea si frecventa operatiilor de intrare/iesire; conditiile privind protectia datelor; operatiile necesare (incarcare/validare, actualizare, regasire etc.); particularitatile activitatii pentru care se realizeaza baza de date.

Performantele tehnice ale SGBD-ului se refera la: modelul de date pe care-l implementeaza; ponderea utilizarii SGBD-ului pe piata si tendinta; configuratia de calcul minima ceruta; limbajele de programare din SGBD; facilitatile de utilizare oferite pentru diferite categorii de utilizatori; limitele SGBD-ului; optimizarile realizate de SGBD; facilitatile tehnice; lucrul cu mediul distribuit si concurenta de date; elementele multimedia; instrumentele CASE; interfetele de comunicare; posibilitatea de autodocumentare; instrumentele specifice oferite.

Proiectarea BDR se realizeaza prin proiectarea schemelor BDR si proiectarea modulelor functionale specializate.

Schemele bazei de date sunt: conceptuala, externa si interna.

a) Proiectarea schemei conceptuale porneste de la identificarea setului de date necesar sistemului. Aceste date sunt apoi integrate si structurate intr-o schema (exemplu: pentru BDR relationale cea mai utilizata tehnica este normalizarea). Pentru acest lucru se parcurg pasii:

Stabilirea schemei conceptuale initiale care se deduce din modelul entitate-asociere (vezi analiza structurala). Pentru acest lucru, se transforma fiecare entitate din model intr-o colectie de date (fisier), iar pentru fiecare asociere se definesc cheile aferente. Daca rezulta colectii izolate, acestea se vor lega de alte colectii prin chei rezultand asocieri (1:1, 1:m, m:n).

Ameliorarea progresiva a schemei conceptuale prin eliminarea unor anomalii (exemplu: cele cinci forme normale pentru BDR relationale).

Stabilirea schemei conceptuale finale trebuie sa asigure un echilibru intre cerintele de actualizare si performantele de exploatare (exemplu: o forma normala superioara asigura performante de actualizare, dar timpul de raspuns va fi mai mare).

Tehnica de normalizare este utilizata in activitatea de proiectare a structurii BDR si consta in eliminarea unor anomalii (neajunsuri) de actualizare din structura.

Anomaliile de actualizare sunt situatii nedorite care pot fi generate de anumite tabele in procesul proiectarii lor:

Anomalia de stergere semnifica faptul ca stergand un tuplu dintr-o tabela, pe langa informatiile care trebuie sterse, se pierd si informatiile utile existente in tuplul respectiv;

Anomaliile de adaugare semnifica faptul ca nu pot fi incluse noi informatii necesare intr-o tabela, deoarece nu se cunosc si alte informatii utile (de exemplu valorile pentru cheie);

Anomalia de modificare semnifica faptul ca este dificil de modificat o valoare a unui atribut atunci cand ea apare in mai multe tupluri.

Normalizarea este o teorie construita in jurul conceptului de forme normale (FN), care amelioreaza structura BDR prin inlaturarea treptata a unor neajunsuri si prin imprimarea unor facilitati sporite privind manipularea datelor.

Normalizarea utilizeaza ca metoda descompunerea (top-down) unei tabele in doua sau mai multe tabele, pastrand informatii (atribute) de legatura.

FN1. O tabela este in FN1 daca toate atributele ei contin valori elementare (nedecompozabile), adica fiecare tuplu nu trebuie sa aiba date la nivel de grup sau repetitiv. Structurile de tip arborescent si retea se transforma in tabele cu atribute elementare. O tabela in FN1 prezinta inca o serie de anomalii de actualizare datorita eventualelor dependente functionale incomplete.

Fiecare structura repetitiva genereaza (prin descompunere) o noua tabela, iar atributele la nivel de grup se inlatura, ramanand doar cele elementare.

FN2. O tabela este in FN2 daca si numai daca este in FN1 si fiecare atribut noncheie al tabelei este dependent functional complet de cheie. Un atribut B al unei tabele depinde functional de atributul A al aceleiasi tabele, daca fiecarei valori a lui A ii corespunde o singura valoare a lui B, care ii este asociata in tabela. Un atribut B este dependent functional complet de un ansamblu de atribute A in cadrul aceleiasi tabele, daca B este dependent functional de intreg ansamblul A (nu numai de un atribut din ansamblu). O tabela in FN2 prezinta inca o serie de anomalii de actualizare, datorita eventualelor dependente tranzitive.

Eliminarea dependentelor incomplete se face prin descompunerea tabelei initiale in doua tabele, ambele continand atributul intermediar (B).

FN3. O tabela este in FN3 daca si numai daca este in FN2 si fiecare atribut noncheie depinde in mod netranzitiv de cheia tabelei. Intr-o tabela T, fie A,B,C trei atribute cu A cheie. Daca B depinde de A (A 􀃆 B) si C depinde de B (B 􀃆 C) atunci C depinde de A in mod tranzitiv. Eliminarea dependentelor tranzitive se face prin descompunerea tabelei initiale in doua tabele, ambele continand atributul intermediar (B).

O tabela in FN3 prezinta inca o serie de anomalii de actualizare, datorate eventualelor dependente multivaloare.

O definitie mai riguroasa pentru FN3 a fost data prin forma intermediara BCNF (Boyce Codd Normal Form): o tabela este in BCNF daca fiecare determinant este un candidat cheie. Determinantul este un atribut elementar sau compus fata de care alte atribute sunt complet dependente functional.

FN4. O tabela este in FN4 daca si numai daca este in FN3 si nu contine doua sau mai multe dependente multivaloare. Intr-o tabela T, fie A,B,C trei atribute. In tabela T se mentine dependenta multivaloare A daca si numai daca multimea valorilor lui B ce corespunde unei perechi de date (A,C), depinde numai de o valoare a lui A si este independenta de valorile lui C.

FN5. O tabela este in FN5 daca si numai daca este in FN4 si fiecare dependenta jonctiune este generata printr-un candidat cheie al tabelei. In tabela T (A,B,C) se mentine dependenta jonctiune (AB, AC) daca si numai daca T mentine dependenta multivaloare A -->> B sau C.

Dependenta multivaloare este caz particular al dependentei jonctiune. Dependenta functionala este caz particular al dependentei multivaloare.

b) Proiectare schemei externe are rolul de a specifica viziunea fiecarui utilizator asupra BDR. Pentru acest lucru, din schema conceptuala se identifica datele necesare fiecarei viziuni. Datele obtinute se structureaza logic in subscheme tinand cont de facilitatile de utilizare si de cerintele utilizator. Schema externa devine operationala prin construirea unor viziuni (view) cu SGBD-ul si acordarea drepturilor de acces. Datele intr-o viziune pot proveni din una sau mai multe colectii si nu ocupa spatiul fizic.

c) Proiectarea schemei interne presupune stabilirea structurilor de memorare fizica a datelor si definirea cailor de acces la date. Acestea sunt specifice fie SGBD-ului (scheme de alocare), fie sistemului de operare. Proiectarea schemei interne inseamna estimarea spatiului fizic pentru BDR, definirea unui model fizic de alocare (a se vedea daca SGBD-ul permite explicit acest lucru) si definirea unor indecsi pentru accesul direct, dupa cheie, la date.

Proiectarea modulelor functionale tine cont de conceptia generala a BDR, precum si de schemele proiectate anterior. In acest sens, se proiecteaza fluxul informational, modulele de incarcare si manipulare a datelor, interfetele specializate, integrarea elementelor proiectate cu organizarea si functionarea BDR.

3) Realizarea componentelor logice. Componentele logice ale unei BD sunt programele de aplicatie dezvoltate, in cea mai mare parte, in SGBD-ul ales. Programele se realizeaza conform modulelor functionale proiectate in etapa anterioara. Componentele logice tin cont de iesiri, intrari, prelucrari si colectiile de date. In paralel cu dezvoltarea programelor de aplicatii se intocmesc si documentatiile diferite (tehnica, de exploatare, de prezentare).

4) Punerea in functiune si exploatarea. Se testeaza functiile BDR mai intai cu date de test, apoi cu date reale. Se incarca datele in BDR si se efectueaza procedurile de manipulare, de catre beneficiar cu asistenta proiectantului. Se definitiveaza documentatiile aplicatiei. Se intra in exploatare curenta de catre beneficiar conform documentatiei.

5) Dezvoltarea sistemului. Imediat dupa darea in exploatare a BDR, in mod continuu, pot exista factori perturbatori care genereaza schimbari in BDR. Factorii pot fi: organizatorici, datorati progresului tehnic, rezultati din cerintele noi ale beneficiarului, din schimbarea metodologiilor etc.