INTRODUCERE IN METODOLOGIA DE PROIECTARE A BAZELOR DE DATE (BD)

Metodologia de proiectare consta intr-o abordare structurata, in care se utilizeaza proceduri, tehnici, instrumente si documentatii pentru a sustine si facilita procesul de proiectare.

O metodologie de proiectare consta in mai multe faze, continand etape care indruma proiectantul in alegerea tehnicilor adecvate fiecarei etape a proiectului; de asemenea il ajuta la: planificarea, administrarea, controlul si evaluarea proiectelor de dezvoltare a bazelor de date. In final, are loc o abordare structurata de analiza si modelare a unui set de cerinte privind BD, intr-o maniera standardizata si organizata.

Metodologia de proiectare a BD consta din trei faze principale:

Proiectarea conceptuala a BD - reprezinta procesul de construire a unui model al informatiilor utilizate in cadrul unei intreprinderi, independent de toate consideratiile de ordin fizic;

Proiectarea logica a BD - consta in construirea unui model al informatiilor utilizate in cadrul unei intreprinderi, bazat pe un anumit model de date, dar independent de un anumit SGBD si de alte considerente de ordin fizic;

Proiectarea fizica a BD - reprezinta procesul de realizare a unei descrieri a implementarii bazei de date intr-o capacitate de memorare secundara; descrie structuri de memorare si metode de acces utilizate pentru realizarea unui acces eficient la date.

Urmatoarele aspecte s-ar putea dovedi factori importanti in proiectarea cu succes a BD:

lucrul interactiv cu utilizatorii cat de mult posibil;

urmarirea unei metodologii structurate de-a lungul procesului de modelare a datelor;

utilizarea unei abordari coordonata prin date;

incorporarea consideratiilor structurale si de integritate in modelul de date;

combinarea tehnicilor de conceptualizare, normalizare si validare a tranzactiilor in metodologia de modelare a datelor;

utilizarea diagramelor, pentru a reprezenta cat mai mult din modelul de date;

utilizarea unui limbaj de proiectare a BD - Data Base Design Language (BDDL) pentru reprezentarea semantica suplimentara a datelor;

construirea unui dictionar care sa suplimenteze diagramele modelului de date;

disponibilitatea de a repeta anumite etape.

Proiectarea conceptuala a bazelor de date

Prima etapa in proiectarea conceptuala a BD este construirea modelului de date conceptual local, pentru fiecare vedere a utilizatorului. Aceasta consta din urmatoarele subetape:

Identificarea tipurilor de entitati;

Identificarea tipurilor de relatii;

Identificarea si asocierea atributelor cu tipurile de entitati sau relatii;

Determinarea domeniilor atributelor;

Determinarea atributelor chei candidat si primare;

Specializarea/generalizarea tipurilor de entitati;

Desenarea diagramei Entitate-Relatie;

Revizuirea modelului de date conceptual local impreuna cu utilizatorul.

Faza de proiectare conceptuala a bazelor de date incepe cu crearea unui model da date conceptual al intreprinderii, care este total independent de detaliile privind implementarea, cum ar fi: elementele de software ale SGBD-ului tinta, programele aplicatie, limbajele de programare, platforma hardware sau orice consideratii de ordin fizic.

In continuare, se va prezenta etapa cu etapa realizarea unui proiect conceptual al unei BD.

Proiectarea conceptuala si logica a BD este impartita in trei etape principale:

Obiectivul acestei prime etape este de a descompune proiectarea in activitati mai usor manevrabile, prin examinarea diverselor perspective ale utilizatorilor asupra intreprinderii sau, cu alte cuvinte, ale vederilor utilizatorilor. O vedere este rezultatul dinamic al uneia sau mai multor operatii relationale, care actioneaza asupra relatiilor de baza in vederea realizarii unei alte relatii. O vedere este o relatie virtuala care, in realitate nu exista in BD, ci este produsa in momentul respectiv, la cererea unui anumit utilizator.

In cadrul acestei etape se traspun modelele conceptuale locale in modele de date logice locale pentru modelul relational. In aceasta etapa se elimina caracteristicile indezirabile din modelul conceptual, acestea fiind dificil de implementat intr-un SGBD relational. Modelele logice sunt apoi validate prin utilizarea tehnicilor de normalizare. Normalizarea este o tehnica de realizare a unui set de relatii cu proprietati dezirabile, date find cerintele unei intreprinderi. Procesul de normalizare a fost realizat prima data de catre E.F. Codd (1972). In genereal, normalizarea consta dintr-o serie de teste asupra unei relatii, pentru a se constata daca aceasta satisface sau violeaza cerintele unei anumite forme normale. Initial, au fost introduse trei forme normale denumite astfel: prima (1NF), a doua (2NF) si a treia (3NF) forma normala. Toate aceste forme normale se bazeaza pe dependentele functionale dintre atributele unei relatii. Mai tarziu, au fost introduse forme normale superioare, cum ar fi cea de-a patra (4NF) si cea de-a cincea (5NF) forma normala. Normalizarea constituie un mijloc eficient de garantare a faptului ca modelele sunt coerente si logice din punct de vedere structural si au o redundanta minima. Modelele de date sunt validate si pentru tranzactiile pe care este necesar sa le accepte. Validarea reprezinta procesul de garantare a faptului ca se realizeaza un model "corect". Dupa cea de-a doua etapa modelele de date logice ar putea fi utilizate, daca este necesar, pentru a realiza implementarea de prototipuri ale BD pentru vederile utilizatorilor.

Aceasta etapa implica imbinarea modelelor de date logice locale (care reprezinta vederi diferite ale utilizatorilor), pentru a obtine un model date logic global unic al intreprinderii (care reprezinta vederile tuturor utilizatorilor).

Pe parcursul intregii metotologii, utilizatorii joaca un rol foarte important in revizuirea si validarea continua a modelului de date si a documentatiei de sustinere a acestuia. Proiectarea BD este un proces interactiv, care are un punct de plecare si numeroase procese de imbunatatire. Este posibil ca deciziile luate in cadrul unei etape sa conduca la modificarea deciziilor luate in decursul unei etape anterioare.

Metodologia trebuie sa actioneze ca un ghid eficient in activitatea de proiectare a BD.

Proiectarea conceptuala consta in construirea modelului de date conceptual local pentru fiecare vedere a utilizatorului specificata. O vedere a utilizatorului reprezinta datele cerute de catre un anumit utilizator pentru a lua o decizie corecta sau a efectua o anumita activitate.

De obicei, vederea unui utilizator constituie o zona functionala a intreprinderii, cum ar fi: productia, marketing, vanzari, personal, contabilitate sau controlul aprovizionarii. Un utilizator poate fi o persoana reala sau un grup de persoane care utilizeaza in mod direct sistemul. Utilizatorul se poate referi la un raport produs de catre sistem sau poate solicita rezultatele unei tranzactii care trebuie acceptata de catre acesta. Vederile utilizatorilor pot fi identificate utilizand diverse metode: pot fi examinate diagramele de flux de date care au fost realizate anterior in scopul de a identifica zonele functionale, ar putea fi chestionati utilizatorii, se pot examina procedurile, rapoartele si formularele si/sau observa intreprinderea in functiune.

Se realizeaza o referire la modelul de date conceptual, corespunzator fiecarei vederi a utilizatorilor pe care urmeaza sa o modeleze, cu termenul de model de date conceptual local corespunzator vederii respective. Fiecare model de date conceptual local cuprinde: tipuri de entitate, tipuri de relatii, atribute, domeniile atributelor, cheile candidat, cheile primare.

Identificarea tipurilor de entitati

Obiectivul aceastei etape a proiectarii conceptuale este identificarea principalelor tipuri de entitati din vederea utilizatorului asupra intreprinderii. Modelul de date conceptual consta in definirea principalelor obiective care pot prezenta interes pentru utilizator. O metoda de identificare a entitatilor consta in examinarea specificatiei cerintelor corespunzatoare unei anumite functii a utilizatorului in cadrul intreprinderii.

Din aceasta specificatie se identifica substantivele sau expresiile substantivale mentionate. De asemenea, se cauta obiectele principale, cum ar fi: persoanele, locurile sau conceptele de interes, excluzandu-se substantivele care reprezinta doar calitati ale altor obiecte.

O modalitate alternativa de identificare a entitatilor este de a cauta obiectele care exista pe cont propriu.

Uneori, entitatile sunt greu de identificat, datorita modului in care sunt prezentate in cadrul specificatiei cerintelor utilizatorului, uneori utilizatorii exprimandu-se prin exemple sau analogii. Nu este intotdeauna evident daca un anumit obiect este o entitate, o relatie sau un atribut.

Proiectantii de baze de date trebuie sa aiba o vedere selectiva asupra lumii si sa clasifice informatiile pe care le observa despre intreprindere.

Exista situatii in care nu poate fi definit un set unic de tipuri de entitati dintr-o anumita specificatie a cerintelor dar, prin iteratii succesive ale procesului de analiza, trebuie sa se ajunga la alegerea entitatilor care sa fie cel putin adecvate pentru sistemul cerut.

Pe masura ce se identifica entitatile, li se atribuie denumiri care sa aiba semnificatie si sa fie evidente pentru utilizatori. Denumirea si descrierile entitatilor sunt reunite intr-un dictionar de date. Atunci cand este posibil, se documenteaza numarul estimat de aparitii ale fiecarei entitati. O entitate poate fi cunoscuta sub denumiri diferite, numite alias-uri sau sinonime si sunt inregistrate in dictionarul de date.

Identificarea tipurilor de relatii

Obiectivul aceastei etape este identificarea relatiilor importante care exista intre entitatile identificate. Dupa ce entitatile sunt identificate, urmatoarea etapa consta in identificarea relatiilor care exista intre acestea. Pentru identificarea entitatilor, o metoda este de a cauta substantivele in specificatia cerintelor utilizatorului. In cazul relatiilor trebuie cautate expresiile verbale.

In general, relatiile sunt binare (intre doua entitati), totusi, trebuie sa se determine si relatiile complexe, care ar putea include mai mult de doua tipuri de entitati, precum si relatiile recursive, care implica un singur tip de entitate.

O atentie deosebita trebuie acordata la detectarea tuturor relatiilor explicite sau implicite din specificatiile utilizatorului. Totusi, relatiile lipsa trebuie sa iasa la iveala cand se valideaza modelul conform tranzactiilor pe care trebuie sa le accepte.

Dupa identificarea relatiilor care trebuie modelate, urmeaza:

a)     determinarea cardinalitatii si constrangerilor de participare a tipurilor de relatii; cardinalitatea unei relatii poate fi: unu-la-unu (1:1), unu-la-multi  (1: M) sau multi-la multi (M : M); constrangerile de participare ale fiecarei entitati din cadrul unei relatii pot fi totale sau partiale; un model care include cardinalitatea si constrangerile de participare reprezinta mai explicit semantica relatiei respective; cardinalitatea si participarea sunt forme de constrangeri folosite pentru verificarea si mentinerea calitatii datelor.

b)     documentarea tipurilor de relatii; pe masura ce se identifica tipurile de relatii, li se atribuie denumiri care au semnificatie si sunt evidente pentru utilizator; de asemenea, se inregistreaza in dictionarul de date descrierile relatiilor si constrangerilor de cardinalitate si de participare.

c)     utilizarea modelarii Entitate-Relatie (E-R); uneori este mai usor sa vizualizezi un sistem complex decat sa descifrezi descrieri textuale lungi din specificatia cerintelor utilizatorilor; diagramele Entitate-Relatie (E-R) se utilizeaza pentru a reprezenta mai usor entitatile si modul in care sunt legate intre ele; in cadrul fazei de proiectare a BD se recomanda modelul E-R oriunde este necesar, pentru a servi la construirea unei imagini a sectorului din intreprinderea care urmeaza sa fie modelata.

Identificarea si asocierea atributelor cu tipurile de entitati sau relatii

Obiectivul acestei etape consta in asocierea atributelor cu tipurile de entitati sau relatii adecvate. Aceasta etapa din cadrul metodologiei consta in identificarea tipurilor de fapte privind entitatile si relatiile care trebuie reprezentate in BD.

Atributele pot fi identificate acolo unde substantivul sau expresia substantivala exprima o proprietate, calitate, identificator sau caracteristica a unei entitati sau relatii.

Atributele se pot imparti astfel:

Atribute simple/compuse - este foarte importanta determinarea caracterului simplu sau compus al unui atribut; atributele compuse sunt formate din atrbute simple; de exemplu, atributul Adresa poate fi simplu, daca ar contine toate detaliile adresei ca o singura valoare, dar acesta poate fi si compus, daca ar fi format din atribute simple care contin detaliile adresei ca valori separate ca atribute (Strada, Zona, Oras si CodP); optiunea de a reprezenta detaliile adresei ca un atribut simplu sau compus este determinata de cerintele utilizatorului; in cadrul acestei etape este important de identificat toate atributele simple care vor fi reprezentate in modelul de date conceptual, inclusiv acela care formeaza atributele compuse.

Atribute derivate - sunt acele atribute ale caror valori pot fi deduse din valorile altor atribute (se mai numesc si calculate); exemple de atribute derivate sunt:

numarul de membri ai personalului care lucreaza in cadrul unei anumite filiale;

varsta unui membru al personalului;

salariile lunare totale ale tuturor membrilor personalului din cadrul unei anumite filiale;

numarul de proprietati pe care le administreaza un membru al personalului;

Uneori, aceste atribute nu sunt prezente in modelul conceptual de date. Atributele derivate trebuie sa fie prezente in modelul de date pentru a evita pierderea potentiala de informatii. Reprezentarea atributelor derivate va fi luata in considerare in decursul proiectarii fizice a BD. In functie de modul de utilizare a atributului pot fi calculate noi valori ale atributului derivat de fiecare data cand acesta este accesat sau cand valoarea din care deriva se modifica.

Exista situatii in care atributele par sa fie asociate mai multor tipuri de entitati, deoarece aceasta poate indica urmatoarele:

au fost identificate o serie de entitati cum ar fi: Manager, Supervizor, Secretar, care pot fi identificate ca o singura entitate, denumita Personal;

a fost identificata o relatie intre tipuri de entitati; in acest caz, trebuie asociat atributului o singura entitate, si anume cea parinte.

Documentarea atributelor - pentru fiecare atribut se inregistreaza urmatoarele informatii:

denumirea si descrierea atributului;

orice alias-uri sau sinonime cunoscute ale atributului;

tipul de date si lungimea lor;

valorile prestabilite ale atributelor (daca sunt specificate);

daca atributul trebuie specificat sau nu;

daca atributul este compus si, in acest caz, care sunt atributele simple din care este format;

daca atributul este derivat si, in acest caz, cum trebuie calculat;

daca atributul are valori multiple.

Determinarea domeniilor atributelor

In aceasta etapa obiectivul este determinarea domeniilor atributelor din modelul de date conceptual local.

Un domeniu este un recipient de valori din care unul sau mai multe atribute isi iau valorile. De exemplu s-ar putea defini:

domeniul atributelor ce reprezinta numerele de filiala valabile, ca fiind un sir de trei caractere, de lungime variabila, in care primul caracter este o litera, iar urmatorul sau urmatoarele doua sunt cifre de la 1 la 99;

domeniul atributelor corespunzatoare numerelor de telefon si de fax valabile, ca fiind un sir de cifre;

valorile posibile ale atributelor Sex din entitatea Personal, ca fiind "B" sau "F"; domeniul acestui atribut este un sir format dintr-un singur caracter cu valorile "B" sau "F".

Intr-un model de date complet se specifica domeniul corespunzator fiecaruia dintre atributele acestuia, care include:

setul de valori impuse pentru atribut;

dimensiunea si formatele campurilor atributelor.

Se pot specifica si alte informatii referitoare la domenii, cum ar fi operatiile permise asupra unui atribut.

Documentarea domeniului atributelor se realizeaza dupa ce acesta a fost identificat, prin inregistrarea caracteristicilor lui in dictionarul de date.

Intrarile de atribute din dictionarul de date se reactualizeaza pentru a inregistra domeniile acestora.

Determinarea atributelor cheie candidat si primare

In aceasta etapa, obiectivul consta in identificarea cheii sau cheilor candidat pentru fiecare entitate si, daca exista mai mult de una, selectionarea celei care va fi cheia primara.

O cheie candidat este un atribut sau un set minimal de atribute ale unei entitati care identifica in mod unic fiecare aparitie a acesteia. Se pot identifica mai multe chei candidat dar, in acest caz, trebuie sa alegem una dintre ele drept cheie primara, celelalte ramanand chei alternative.

La alegerea unei chei primare din cele candidat trebuie sa se tina seama de urmatoarele:

se alege cheia candidat cu setul minim de atribute;

se alege cheia candidat a carei probabilitate de modificare a valorii este minima;

se alege cheia candidat cu cel mai mic numar de caractere;

se alege cheia candidat cea mai prietenoasa din punctul de vedere al utilizatorului;

In procesul de identificare al cheilor primare, se constata daca o entitate este tare sau slaba.

O entitate se numeste tare daca i se poate asocia o cheie primara si slaba in caz contrar.

Cheia primara a unei entitati slabe poate fi identificata numai atunci cand relatia slaba se transforma intr-o entitate si legaturile ei cu entitatea de care apartine, prin plasarea unei chei straine in cadrul acelei relatii.

Procesul de transformare in relatii a entitatilor si a legaturilor lor este foarte important, prin urmare, identificarea cheilor primare pentru entitati slabe nu poate avea loc inainte de a ajunge la aceasta etapa.

Este indicat sa se inregistreze identificarea cheilor primare si alternative (atunci cand exista) in dictionarul de date.

Specializarea/generalizarea tipurilor de entitati

Obiectivul este identificarea tipurilor de entitati superclasa si subclasa atunci cand este adecvat.

In cadrul acestei etape exista optiunea de a dezvolta modelul E-R prin utilizarea proceselor de specializare sau de generalizare a entitatilor identificate pe parcursul primei etape.

Daca se alege tratarea prin specializare, se evidentiaza diferentele prin definirea uneia sau a mai multor subclase ale unei entitati denumita superclasa de specializare.

In cazul cand se alege tratarea prin generalizare, se incearca o identificare a caracteristicilor comune ale entitatilor, pentru a defini o entitate generalizata denumita superclasa de generalizare. In general, se opteaza pentru generalizarea entitatilor, bazandu-se pe existenta atributelor comune si a relatiilor asociate fiecaruia.

De obicei, nu exista indicatii stricte privind situatiile in care este recomandabila realizarea modelului E-R prin specializare sau generalizare, deoarece aceasta alegere este adeseori subiectiva si depinde de caracteristicile particulare a situatiei de modelat.

Ca o indicatie utila in alegerea specializarii sau generalizarii este recomandabil ca in realizarea modelului E-R trebuie sa se incerce reprezentarea entitatilor importante si a relatiilor lor cat mai riguros posibil. Gradul de specializare/generalizare afisat intr-o diagrama E-R trebuie sa fie dictat de lizibilitatea diagramei si de claritatea cu care aceasta modeleaza tipurile importante de entitati si relatii. Conceptul de specializare/generalizare este asociat modelarii extinse.

Datorita faptului ca aceasta etapa este optionala se vor utiliza doar termenii de "diagrama E-R" sau "model E-R" atunci cand se fac referiri la reprezentarea schematica a modelelor de date.

Desenarea diagramei Entitate-Relatie

Obiectivul acestei etape consta in desenarea unei diagrame Entitate-Relatie   (E-R) care sa fie o reprezentare conceptuala a vederii unui utilizator asupra intreprinderii.

Revizuirea modelului de date conceptual local impreuna cu utilizatorul

Aceasta se efectueaza pentru a garanta ca modelul este o reprezentare "reala" a punctului de vedere al utilizatorului asupra intreprinderii. Inainte de finalizarea primei etape este necesar ca, impreuna cu utilizatorul, sa se treaca in revista modelul de date conceptual local, care include diagrama E-R si documentatia de sustinere care-l descrie.

In cazul ca exista anomalii in modelul de date, trebuie efectuate modificarile necesare, care ar putea necesita reluarea unor etape elementare anterioare. Se va repeta acest proces pana cand utilizatorul este gata de a "parafa" modelul drept o reprezentare "corecta" a sectorului de intreprindere care trebuie modelat.

In rezumat, o metodologie de proiectare reprezinta o structura in care se utilizeaza: proceduri, tehnici, instrumente si documentatii care sustin si faciliteaza procesul de proiectare.

Exista o serie de factori critici pentru succesul etapei de proiectare a bazelor de date, exemplu putand fi luat lucrul interactiv cu utilizatorul si disponibilitatea de a repeta o serie de etape elementare intermediare.

Obiectivul principal al acestei etape de proiectare a fost construirea unui model de date conceptual local al unei intreprinderi, corespunzator unei anumite vederi a utilizatorului si in atingerea lui s-a urmarit ca:

vederile utilizatorilor sa se poata identifica utilizand diagrame de flux de date;

modelul de date conceptual sa cuprinda tipurile de entitati, tipurile de relatii, atributele, domeniile atributelor, cheile candidate si cheile primare;

modelul de date conceptual sa fie sustinut de catre o documentatie precum dictionarul de date, realizat in decursul dezvoltarii modelului.