PROIECTAREA BAZELOR DE DATE

PROIECTAREA BAZELOR DE DATE

Proiectarea bazelor de date cuprinde doua aspecte principale.

Primul aspect, numit logic, se refera la crearea unui model conceptual al datelor care urmeaza sa fie pastrate în colectia reprezentata de baza de date.

Al doilea aspect, numit fizic, se refera la definirea conditiilor practice în care va functiona baza de date si abordeaza probleme ca: timpul de acces, dimensiunea bazei de date, necesarul de memorie de masa, sistemul de gestiune utilizat, echipamentele necesare, etc.

Proiectarea logica

Sunt cunoscute mai multe te 848h73i hnici de modelare prin care proiectantul îsi poate structura ideile relative la conceptia bazei de date. Dintre acestea, vor fi descrise:

- modelarea relatiilor entitate-atribut (EAR: Entity-Attribute Relationship);

modelarea prin normalizare.

Modelarea relatiilor entitate-atribut (EAR)

Aceasta metoda este larg utilizata datorita accesibilitatii si simplitatii sale. De asemenea, o calitate importanta a modelarii EAR este abordarea pornind de la general catre particular. Modelarea EAR se realizeaza, în general, în cadrul a trei etape:

a. Identificarea entitatilor

Entitatile sunt persoane, obiecte, lucruri, fenomene, având o existenta proprie si în legatura cu care este necesar sa se colectioneze date în vederea functionarii unui anumit sistem informatic.

Prima actiune care trebuie întreprinsa în cadrul modelarii EAR consta în alegerea entitatilor relevante pentru sistemul informatic preconizat. Aceasta selectie se materializeaza într-o lista care cuprinde numele entitatilor luate în considerare. De exemplu, pentru realizarea unui sistem de evidenta a cazarii într-un camin studentesc, entitatile ar putea fi:

Orice entitate poate avea multiple instante, adica diferite concretizari în lumea reala.

De exemplu, doua instante ale entitatii STUDENT ar putea fi Nicu Haralambie, din anul II Cadastru si Carmen sarpe din anul I Cadastru.

b. Identificarea relatiilor

A doua etapa consta în definirea relatiilor care exista între enti­tatile luate în considerare, adica a legaturilor stabilite în lumea reala între acestea.

De exemplu, un student este cazat într-o camera din camin, un sot este casatorit cu sotia sa, un curs este predat de un profesor (sau de mai multi profesori).

Relatiile sunt reprezentate, de regula, printr-o linie care uneste cele doua entitati implicate.

Pe linia respectiva se plaseaza o eticheta care expliciteaza tipul relatiei.

De exemplu:

sau

Tot în aceasta etapa se determina si gradul relatiei, adica numarul de instante care pot participa la relatia respectiva. Din acest punct de vedere, relatiile pot fi:

- unu la unu (1:1).

Aceasta relatie apare atunci când o instanta a uneia dintre entitati poate fi în legatura doar cu o singura instanta a celeilalte entitati. De exemplu, în societatile monogame, între soti exista (în mod legal) o legatura (1:1), pentru ca, la un moment dat, un barbat poate fi casatorit numai cu o sotie si o femeie poate fi casatorita cu un singur sot;

- unu la mai multi (1:n)

Este relatia care exista când o instanta a unei entitati poate fi pusa în legatura cu mai multe instante ale celeilalte entitati, fara ca reciproca sa fie adevarata. De exemplu, într-o camera de camin pot fi cazati mai multi studenti, dar (în principiu) un student nu poate fi cazat simultan în mai multe camere. De asemenea, o mama poate avea mai multi copii, dar (în mod normal) un om nu poate avea decât o singura mama. Relatia respectiva se reprezinta grafic prin multiplicarea liniilor de relatie sau prin înscrierea caracterelor 1 si n la extremitatile corespunzatoare ale liniei respective.

sau

mai multi la mai multi (n:n).

Aceasta relatie se stabileste când la ambele capete ale legaturii pot apare mai multe instante. De exemplu, în cadrul unui semestru, mai multi studenti audiaza mai multe cursuri universitare, în prezent, o persoana poate fi salariata de mai multe societati comerciale si o societate comerciala are, de regula, mai multi salariati. De asemenea, o persoana poate detine mai multe imobile si un imobil poate fi detinut, în indiviza, de mai multi proprietari:

sau

Se poate observa, inclusiv din exemplele date, ca relatiile dintre entitati deriva din regulile organizatiei în care acestea exista.

De exemplu, în unele tari musulmane un barbat poate avea, în mod legal, mai multe sotii, sau, în regimul existent în România înainte de 1990, o persoana nu putea, în mod oficial, sa fie salariat al mai multor institutii. Aceasta observatie reprezinta un anumit aspect al integritatii datelor, în sensul ca datele sunt valide (integre) daca interpretarea lor în cadrul bazei de date corespunde celei atribuite lor în organizatia sau mediul din care provin entitatile caracterizate prin datele respective.

c. Stabilirea atributelor

Cea de a treia etapa a modelarii EAR consta în specificarea, pentru fiecare entitate, a atributelor sau caracteristicilor considerate relevante pentru obiectivele sistemului informatic care include respectiva baza de date. Atributele pot fi privite ca adjective care caracterizeaza o entitate oarecare, considerata substantiv. La alegerea atributelor, aproape întotdeauna trebuie facut un compromis între dorinta de a detine cât mai multe caracteristici ale entitatilor reprezentate în bazele de date si posibilitatile practice de stocare, manipulare si - mai ales - de culegere a acestora. De altfel, este necesar ca odata cu alegerea atributelor sa se precizeze si sursa (sau sursele) din care se vor obtine valorile acestora. De exemplu, datele privind un student s-ar putea prelua dintr-o lista primita de la secretariatele facultatilor, din carnetul de student, din buletinul de identitate (cu exceptia numarului matricol), etc.

Grafic, atributele se pot reprezenta pe lânga entitatile pe care le caracterizeaza, asa cum este ilustrat în figura 1.

Pentru completarea celor trei etape mentionate mai sus, este necesar sa se analizeze posibilitatea organizarii datelor respective în mai multe tabele care vor constitui baza de date.

Figura 1

De exemplu, pentru evidenta cazarii într-un camin, datele amintite mai sus s-ar putea organiza în trei tabele, asa cum este ilustrat mai jos prin tabelele 1.a, 1.b si 1.c.

Tabelul 1.a

Tabelul 1.b

Tabelul 1.c

De regula, proiectarea bazei de date este un proces iterativ, în care ideile se clarifica si se sedimenteaza pe masura trecerii de la o etapa la alta, adeseori necesitând reluarea unor etape deja parcurse. De exemplu, facultatea, inclusa ca atribut al entitatii STUDENT ar putea fi tratata ca entitate cu atributele denumire, numar_studenti, etc. De asemenea, ar putea apare ca necesara introducerea unor atribute noi ca: tip_bursa la entitatea STUDENT sau cost_loc la entitatea CAMERA.

Modelarea prin normalizare

Normalizarea este o metoda de modelare derivata direct din modelul relational, urmarind constituirea unui set de tabele în care datele sa îndeplineasca toate cerintele acestuia. Normalizarea este o abordare de jos în sus în care se porneste de la totalitatea atributelor, de la care, cu ajutorul unei serii de reguli aplicate într-o ordine prestabilita, se ajunge la solutia corespunzatoare modelului ales, acesta fiind în principiu modelul relational.

Procesul de normalizare se desfasoara în cadrul urmatoarelor etape:

a. Stabilirea listei de atribute

De la început, se întocmeste o lista cu toate atributele considerate relevante si necesare pentru sistemul informatic considerat.

b. Formarea tabelelor initiale

Atributele din lista alcatuita în etapa precedenta sunt grupate în mai multe tabele, urmarind un anumit criteriu, de exemplu entitatea pe care o caracterizeaza fiecare atribut. De regula, aceste tabele reprezinta o aproximare grosiera a tabelelor definitive. Este foarte probabil ca, în aceasta etapa, tabelele, numite nenormalizate, sa nu se conformeze în totalitate modelului relational. Eventualele anomalii sau abateri de la model urmeaza sa fie eliminate în etapele care urmeaza.

c. Prima normalizare

Aceasta etapa consta în eliminarea grupelor de date care se repeta în tablourile formate în etapa anterioara. Grupele de date repetate (date redundante) apar, de regula, atunci când o entitate oarecare are legaturi multiple cu alte entitati. De exemplu, partida cadastrala este un document (un tabel) care evidentiaza toate proprietatile funciare care apartin unui anumit detinator. Principial, partida cadastrala s-ar putea prezenta sub forma din tabelul 2.

Tabelul 2

Se observa imediat ca ultima coloana (parcele în posesie) va contine o singura valoare numai în cazul particular al unui detinator care poseda o singura parcela. Aparent, o rezolvare ar putea fi cea ilustrata în tabelul 3, unde sunt prevazute zece coloane, câte una pentru fiecare proprietate. De fapt, aceasta solutie duce la risipa de spatiu prin faptul ca se rezerva zece pozitii pentru parcele, desi multi proprietari ar putea detine doar una sau doua parcele. Pe de alta parte, tabelul 4 este total inadecvat situatiilor în care un proprietar detine mai mult de zece parcele.

Tabelul 3

O solutie posibila pentru problema din acest exemplu consta în repartizarea datelor respective în mai multe tabele (DEŢINĂTOR, PARCELĂ si POSESIE), în loc de unul singur, asa cum se poate vedea în tabelele 3.a, 3.b si 3.c de mai jos.

Tabelul 3.a

Tabelul 3.b

Tabelul 3.c

d. A doua normalizare

În aceasta etapa sunt eventual eliminate dependentele partiale, existente atunci când într-un tabel cheia primara este o combinatie de coloane si nu o coloana unica.

Din punct de vedere practic, rezolvarea consta în stabilirea regulilor prin care valorile unei coloane sunt unice pentru fiecare rând. De exemplu, în tabelele 3 se considera ca atât codul personal, cât si codul parcelei, sunt chei primare (nu exista doi detinatori cu acelasi cod personal si nu exista doua terenuri cu acelasi cod de parcela).

e. A treia normalizare

Aceasta etapa se refera la eliminarea dependentelor tranzitorii.

Acestea apar atunci când valorile unei coloane sunt dependente de valorile alteia, ambele nefiind chei.

Rezumând cele aratate mai sus în legatura cu cele trei etape de normalizare, acestea s-ar putea concentra în urmatoarele reguli de baza care ar trebui respectate la constituirea tabelelor: • de regula, cheia trebuie sa fie constituita dintr-o singura coloana;

orice atribut care nu este cheie trebuie sa fie dependent de o cheie;

un atribut nu trebuie sa fie dependent de altul care nu este cheie.

Proiectarea fizica

Dupa proiectarea logica care consta în realizarea modelului conceptual al bazei de date, este necesar sa fie abordate aspectele practice privind implementarea efectiva a modelului respectiv pe o anumita configuratie. Principalele probleme care trebuie rezolvate în aceasta faza se refera la timpul de raspuns al bazei de date, adica timpul necesar pentru efectuarea operatiunilor specifice si la marimea bazei de date, adica volumul memoriei de masa necesar pentru stocarea datelor.

Timpul de raspuns

Unul dintre dezavantajele modelului relational în comparatie cu modelele arborescent si retea, consta în viteza mai mica de raspuns la regasirea unei date. Deficienta respectiva este datorata faptului ca într-o baza de date relationala nu exista nici o informatie privind pozitia (rândul) pe care se afla o anumita data, astfel ca, pentru a regasi toate entitatile caracterizate printr-o anumita valoare a unui atribut (de exemplu, toate punctele de triangulatie de ordinul II dintr-un inventar de coordonate), în principiu ar trebui parcurs întregul tabel începând cu primul rând si terminând cu ultimul.

Problema vitezei de raspuns include aspecte particulare în cazul bazelor de date distribuite, constituite pe retele de calculatoare, unde tabelele necesare unei operatii oarecare se pot gasi pe calculatoare diferite, în acest caz, este necesar sa se ia în considerare si viteza de transmisie, dependenta de tipul placilor de retea, de caracteristicile modemurilor si de calitatea mediului de transmisie (cablu).

Tabelul 4.a

Tabelul 4.b

Exista mai multe procedee de accelerare a vitezei de raspuns a unei baze de date.

Principala tehnica utilizata în acest scop este indexarea, în principiu, aceasta consta în crearea unui tabel (fisier) special, numit tabel de indecsi, care contine doua coloane.

Una dintre cele doua coloane contine valorile atributului pentru care s-a format indexul, iar cealalta contine numarul rândului (înregistrarii) pe care se afla restul atributelor entitatii respective, în tabela de indecsi, valorile atributului sunt ordonate, astfel ca regasirea poate fi accelerata prin utilizarea unui algoritm de cautare în liste ordonate.

De exemplu, registrul detinatorilor dintr-o evidenta cadastrala ar putea fi realizat sub forma unui tabel care contine pe o coloana numele sau denumirea entitatii proprietar, drept cheie primara (în realitate, nu este recomandabil ca numele sa fie utilizat în calitate de cheie primara, având în vedere ca pot exista mai multe persoane cu acelasi nume si prenume, în loc de aceasta s-ar putea utiliza codul personal, care este unic), precum si alte atribute ale acestei entitati, pe celelalte coloane, în mod firesc, înregistrarile din acest tabel sunt completate în ordinea aparitiei detinatorilor respectivi, adica aleatoriu.

Pentru regasirea mai rapida a unui proprietar indicat prin nume, este utila crearea unui index alfabetic, asa cum este ilustrat în tabelele 4.

Pentru regasirea informatiei privind un anumit detinator, de exemplu F.A.M. S.A., sistemul de gestiune al bazei de date va cauta mai întâi în tabelul de indecsi numele respectiv, va prelua de aici valoarea indexului (numarul de ordine al înregistrarii), dupa care, pe baza acestui numar, va accesa direct în tabelul DEŢINĂTORI înregistrarea co­respunzatoare entitatii cautate. Desi, aparent, mecanismul descris este mai complicat decât o cautare secventiala numai în tabelul DEŢINĂTORI, în realitate timpul de acces este, în medie, mult prin redus datorita faptului ca regasirea într-o lista ordonata, asa cum este tabelul de indecsi, este foarte rapida.

în legatura cu aceasta tehnica, se pot face urmatoarele precizari: - tabele de indecsi sunt create printr-o functie specifica sistemelor relationale de gestiune a bazelor de date (SRGBD), la cererea utilizatorului, care trebuie sa precizeze atributul pentru care se genereaza indexul (nume&prenume, în exemplul din tabelele 4);

- pentru aceeasi baza de date si chiar pentru acelasi tabel se pot crea mai multe tabele de indecsi pentru atribute diferite;

- tabelele de indecsi sunt organizate si prelucrate respectând principiile generale ale bazelor de date relationale, adica sunt tratate ca fiind componente ale bazei de date;

- un tabel de indecsi are un caracter temporar, el existând numai în perioada parcursa între momentul în care s-a cerut crearea sa si momentul în care fie se solicita explicit stergerea lui (pentru a elibera spatiu de memorie), fie se încheie sesiunea de lucru cu baza de date respectiva. Pastrarea lor permanenta este ineficienta datorita spatiului ocupat si mai ales pentru ca actualizarea lor este relativ dificila (Actualizarea tabelului originar pentru care s-a generat tabelul de indecsi ar trebui urmata imediat si de actualizarea acestuia din urma).

Tabelele de indecsi sunt liste ordonate si pentru cautarea în astfel de liste se utilizeaza algoritmi speciali. Evident, orice SGBD trebuie sa includa o functie de regasire bazata pe un algoritm specific.

Dimensionarea bazei de date

A doua problema principala a proiectarii fizice a bazelor de date consta în evaluarea capacitatii memoriei necesare pentru stocarea colectiei respective de date.

În general, rezolvarea acestei probleme implica parcurgerea urmatoarelor operatii:

- Calculul memoriei necesare fiecarui tabel (fisier)

Spatiul necesar unui rând (unei înregistrari) se determina prin însumarea lungimii tuturor atributelor (exprimata în octeti). Suma respectiva se înmulteste cu numarul de rânduri (care trebuie estimat) avut în vedere pentru tabelul respectiv. De exemplu, considerând tabelul 1.a, s-ar putea considera pentru atributele entitatii STUDENT urmatoarele valori:

Tabelul 5

Daca acum se estimeaza ca numarul total de studenti aflat în evidenta pentru acest sistem va fi 500, atunci volumul de memorie necesar pentru stocarea tabelului STUDENT va fi 500*144 = 72000 octeti ~ 70 Kb.

Calculul memoriei necesare pentru tabelele de indecsi

Se poate presupune ca pentru fiecare fisier din baza de date se va crea cel putin un tabel de indecsi. Se apreciaza ca, în medie, tabelul de indecsi acopera circa 20% din volumul tabelului pentru care a fost creat.

- Calculul memoriei totale

Se însumeaza valorile memoriei necesare pentru toate tabelele bazei de date.

Pentru dezvoltarile ulterioare, se considera un coeficient de siguranta de 1.15 ... 1.25.

Rezulta ca volumul total al memoriei necesare se poate calcula cu o relatie de forma:

în care:

n =    numarul de tabele (fisiere) din baza de date proiectata;

r_i numarul de rânduri (înregistrari) din fiecare tabel (estimativ);

s_i lungimea unui rând din fiecare tabel.

Lungimea unei înregistrari se obtine cu relatia:

în care:

k_i = numarul de coloane (câmpuri) din fiecare tabel (fisier);

a_i,j = lungimea exprimata în octeti (bytes) rezervata pentru valorile fiecarui atribut, stabilita la proiectare functie de semnificatia atributului (numele unei persoane, coordonata unui punct, o data calendaristica, etc.) si de tipul de data atribuit caracteristicii respective (întreg pe un byte, întreg pe 4 bytes, real simpla precizie, real dubla precizie, sir de caractere, etc.).