TEHNICI PRIVIND ORGANIZAREA LOGICA A BAZELOR DE DATE PENTRU MODELUL RELATIONAL

Pe parcursul acestui capitol se va prezenta etapa cu etapa o tehnologie de proiectare logica a BD pentru modelul relational. Aceasta tehnologie incepe prin a rafina modelele de date conceptuale locale, transpunandu-le in modele de date logice locale, apoi, cu ajutorul lor, se obtine un set de relatii.

Proiectarea logica a bazelor de date reprezinta procesul de construire a 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 constructii de ordin fizic.

Etapele metodologiei de organizare logica a bazelor de date pentru modelul relational sunt:

Construirea si validarea modelului de date logic pentru fiecare vedere a utilizatorilor;

Construirea si validarea modelului de date logic global.

Prima etapa are ca obiectiv realizarea unui model de date logic - bazat pe modelul de date conceptual al vederii utilizatorului asupra intreprinderii - urmat de validarea acestuia prin utilizarea tehnicii de normalizare si conform tranzactiilor cerute.

Operatiile efectuate in cadrul acestei etape sunt:

transpunerea modelului de date conceptual local in model de date logic local;

extragerea relatiilor din modelul de date logic local;

validarea modelului prin utilizarea normalizarii;

validarea modelului conform tranzactiilor utilizatorului;

desenarea diagramei Entitate-Relatie (E-R);

definirea constrangerilor de integritate;

revizuirea modelului de date logic local, impreuna cu utilizatorii.

La incheierea acestei etape trebuie sa se obtina un model al vederilor utilizatorului care sa fie: riguros, corespunzator si fara echivoc. Daca sunt respectate aceste cerinte, se va dispune, in acest stadiu, de un fundament solid pentru a putea trece la cea de-a doua etapa, ce consta in combinarea modelelor de date logice locale individuale, pentru a realiza un model de date logic global al intreprinderii.

Transpunerea modelului de date conceptual local in model de date logic local

La sfarsitul primei etape se dispune de un model de date conceptual local, corespunzator vederii utilizatorului asupra intreprinderii. Dar, trebuie mentionat faptul ca modelul de date poate contine unele structuri de date care nu pot fi modelate cu usurinta de catre sistemele de gestiune ale BD conventionale. In cadrul acestei etape se transforma aceste structuri de date intr-o forma care sa fie manipulata cu mai multa usurinta de aceste sisteme de gestiune conventionale.

Acest proces determina utilizatorul sa se gandeasca mai profund la semnificatia datelor si, in final, are ca efect o reprezentare mai reala a intreprinderii.

Obiectivele acestei etape sunt:

Eliminarea relatiilor de tip M:N

In cazul in care o relatie de tip M:N este reprezentata in modelul de date conceptual, aceasta trebuie descompusa pentru a identifica o relatie intermediara. Relatia de tip M:N este inlocuita cu doua relatii de tip 1:M, corespunzatoare entitatii nou identificate.

Eliminarea relatiilor complexe

O relatie complexa este cea formata din trei sau mai multe entitati. In cazul in care in modelul conceptual este identificata o reprezentare complexa, ea trebuie descompusa pentru a identifica o entitate intermediara. Relatia complexa este inlocuita cu numarul necesar de relatii de tip 1:M (binare), corespunzatoare noii entitati identificate.

Eliminarea relatiilor recursive

O relatie recursiva este un tip particular de relatie, in care un tip de entitate are o relatie cu ea insasi. In acest caz, aceasta se descompune pentru a identifica o entitate intermediara.

De exemplu, pentru a reprezenta situatia in care un membru al personalului supravegheaza alti membri, se poate defini o relatie recursiva de tip unu-la- multi (1:M): Personal Supervizeaza Persona.

Natura recursiva a acestei relatii necesita o tratare speciala, pentru a permite reprezentarea sa atat in proiectarea logica a bazei de date, cat si in implementarea fizica a acestuia. Pentru a simplifica aceasta relatie recursiva de tip 1:M se va inlocui cu o entitate slaba denumita Personal_Alocat si o relatie aditionala de tip 1:1, denumita SupravegheatDe.

In figura 1 este reprezentata o relatie de tip M:N Publicatie FaceReclama la un anumit articol de uz casnic care se decompune de forma descrisa in figura 2, in doua relatii de tip 1:M Listeaza si ReclamaIn si entitatea Reclama.

		Fig.2

Eliminarea relatiilor cu atribute

In cazul in care in modelul de date conceptual este reprezentata o relatie cu atribute, ea trebuie sa fie descompusa pentru a identifica o entitate. De exemplu, se considera situatia in care se doreste sa se inregistreze numarul de ore lucrate de catre personalul angajat temporar la fiecare filiala, asa cum arata figura 3. Relatia Personal LucreazaLa Filiala are un atribut Ore_Lucrate. Descompunerea relatiei se face intr-o entitate slaba, denumita Alocatie_Filiala, careia ii este alocat atributul Ore_Lucrate si se creeaza doua relatii noi de tipul 1:M asa cum se arata in figura 4.

			Fig.4 Descompunerea Relatiei LucreazaLa, pentru a  realiza entitatea Alocatie_Filiala si doua relatii de tip 1:M (AtributLa si Necesita)

Eliminarea atributelor cu valori multiple

Un atribut cu valori multiple contine mai multe valori pentru o singura entitate.

In cazul in care in modelul de date conceptual este reprezentat un atribut cu valori multiple, el trebuie descompus pentru a identifica o entitate.

De exemplu, pentru a reprezenta situatia in care o singura filiala are mai multe numere de telefon, se va defini atributul Nr_Tel al entitatii Filiala ca atribut cu valori multiple, asa cum apare in figura 5.

Se elimina acest atribut cu valori multiple, asa cum rezulta din figura 6 si se identifica o noua entitate, denumita Telefon, cu Nr_Tel, reprezentat acum ca atribut simplu, si o noua relatie de tipul 1:M denumita Are.

	Fig.5 Entitatea Filiala cu un atribut cu valori multiple, denumit Nr_Tel

	Fig.6 Descompunerea atributului cu valori multiple, Nr_Tel intr-o relatie de tip 1:M, denumita Are si o entitate denumita Telefon, cu un atribut simplu, denumit Nr_Tel

Relaxarea reatiilor de tip 1:1

La identificarea entitatilor, pot apare cazuri in care doua entitati sa reprezinte acelasi obiect din cadrul intreprinderii. Un exemplu poate fi urmatorul: se identifica entitatile Filiala si Departament, care, de fapt, reprezinta acelasi lucru, deoarece "Filiala" este un sinonim pentru "Departament". In acest caz cele doua entitati trebuie imbinate. Daca cheile primare sunt diferite, trebuie sa alegem una dintre ele, cealalta ramanand cheie alternativa.

Eliminarea relatiilor redundante

O relatie este redundanta daca aceeasi informatie poate fi obtinuta prin intermediul altor relatii. Obiectivul este de a realiza un model de date minimal, deci relatiile redundante nu sunt necesare, acestea trebuind sa fie eliminate. Se poate determina cu usurinta daca exista mai mult decat o cale intre doua entitati. Totusi, aceasta nu inseamna ca una dintre relatii este redundanta, deoarece ele pot reprezenta diferite asociatii din cadrul intreprinderii. Estimarea redundantei este determinata de dimensiunea temporala a relatiilor.

Se considera ca exemplu modelarea relatiei dintre entitatile Copil, Femeie, Barbat asa cum este reprezentata in figura 7.

	Fig.7 Relatie neredundanta

Din figura se observa ca exista doua cai intre entitatile Barbat si Copil: una directa, prin intermediul relatiei TatalLui, iar cealalta prin intermediul relatiilor CasatoritCu si MamaLui. Aparent, se poate crede ca relatia TatalLui nu este necesara. Aceasta presupunere este incorecta din doua motive:

tatal ar putea avea copii dintr-o casatorie anterioara, iar atunci se modeleaza numai casatoria curenta printr-o relatie de tip 1:1;

este posibil ca tata si mama sa nu fie casatoriti, sau tatal ar putea fi casatorit cu altcineva decat mama copilului (sau mama este casatorita cu cineva care nu este tatal copilului), astfel incat, din nou, relatia ceruta nu poate fi modelata fara o relatie de tip TatalLui.

Rezulta ca, atunci cand se estimeaza redundanta, este foarte important sa se analizeze semnificatia fiecarei relatii dintre entitati.

Aceasta etapa a prezentat metodele prin care poate fi simplificat modelul de date conceptual local, prin eliminarea structurilor de date care sunt dificil de implementat in bazele de date relationale.

Aceasta etapa se refera la modelul de date conceptual rafinat cu denumirea de model de date logic local.

Extragerea relatiilor din modelul de date logic local

In aceasta etapa se extrag relatiile din modelul de date logic local pentru a reprezenta entitatile si relatiile descrise in vederea utilizatorului asupra intreprinderii.

Va fi descrisa componenta fiecarei relatii utilizand un limbaj de definire a bazelor de date din punct de vedere logic (DBDL) pentru baze de date relationale (BDR).

Cu ajutorul limbajului DBDL se specifica urmatoarele:

denumirea relatiei, urmata de o lista a denumirii atributelor sale simple, cuprinsa intre paranteze;

se identifica cheia primara, cheile alternative si/sau cheile straine ale relatiei respective; dupa identificarea unei chei straine este afisata, deasemenea, relatia care o contine drept cheie primara;.

Se va evidentia faptul ca relatiile care reprezinta entitatile si relatiile acestora sunt extrase din structurile de date posibile, prezente in modelul de date logic (fig.8).

O relatie intre doua entitati este reprezentata prin mecanismul cheie primara/cheie straina.

Atunci cand se decide unde se va expedia sau plasa atributul (atributele) cheii straine, trebuie sa se identifice entitatile "parinte" si "copil" implicate in relatie.

Entitatea "parinte" se refera la entitatea care plaseaza o copie a cheii sale primare in relatia care reprezinta entitatea "copil", unde va actiona ca o cheie straina.

	Fig.8 Un exemplu de model de date logic

Tipuri de entitati tari

Pentru fiecare entitate tare (obisnuita) din modelul de date logic, se creeaza o relatie care cuprinde toate atributele simple ale acelei entitati. Pentru atributele compuse, cum ar fi Adresa, se introduc in relatie numai atributele constituente simple, si anume: Strada, Oras si CodP.

De exemplu, compozitia relatiei Personal din Fig.8 este:

Personal (Nr_Personal, Prenume, Nume, Strada, Oras, CodP, Functie, Sex, Salariu)

Cheie primara: Nr_Personal

Tipuri de entitati slabe

Pentru fiecare entitate din modelul de date logic se creeaza o relatie care sa cuprinda toate atributele simple ale acelei entitati. In plus, se include cheia primara a entitatii proprietar ca o cheie straina. Cheia primara a unei entitati slabe este partial sau total derivata din entitatea proprietar.

Din fig.8 se observa ca entitatea Personal este proprietarul entitatii slabe Ruda_Apropiata. Compozitia acesteia din urma este:

Ruda_Apropiata (Nr_Personal, Nume_R, Adresa, Nr_Tel, Rudenie)

Cheie primara: Nr_Personal, Nume_R

Cheie straina: Nr_Personal se refera la Personal (Nr_Personal)

Se observa ca atributul cheie straina al relatiei Ruda_Apropiata formeaza o parte a cheii primare corespunzatoare acestei entitati. In aceasta situatie, cheia primara a relatiei Ruda_Apropiata nu poate fi identificata decat dupa ce cheia straina a fost expediata din relatia Personal in relatia Ruda_Apropiata. In finalul acestei etape trebuie sa se identifice orice cheie primara sau cheie candidat care a fost formata in procesul de extragere a relatiilor din modelul de date logic.

Tipuri de relatii binare unu-la-unu (1:1)

Pentru fiecare relatie binara de tipul 1:1 dintre entitatile E1 si E2 din modelul de date logic, se expediaza o copie a atributului (atributelor) cheie primara al entitatii E1 in relatia care reprezinta entitatea E Identificarea entitatilor parinte si copil depinde de constrangerile de participare ale entitatilor E1 si E2 din cadrul relatiei.

Entitatea care participa partial in relatie este desemnata drept entitate parinte, iar cea care participa total este desemnata drept entitate copil. O copie a cheii primare a entitatii parinte este plasata in relatia care reprezinta entitatea copil.

In cazul in care ambele tipuri de entitati participa total sau partial intr-o relatie de tip 1:1 desemnarea entitatilor parinte si copil este arbitrara. Mai mult, atunci cand ambele entitati participa total intr-o relatie, exista optiunea de a reprezenta aceasta relatie utilizand legatura cheie primara/cheie straina ca mai sus sau de a imbina atributele asociate ambelor entitati intr-o singura relatie.

In general, exista tendinte de a imbina cele doua tipuri de entitati atunci cand ele nu sunt implicate in alte relatii.

Mai jos dam un exemplu care ilustreaza modul in care se poate reprezenta o relatie de tip 1:1 in relatiile extrase dintr-un model de date logic.

Relatia Personal Administreaza Filiala, reprezentata in fig.8 este de tip 1:1, deoarece un singur mebru al personalului administreaza o singura filiala.

Entitatea Personal participa partial la relatia Administreaza, in timp ce entitatea Filiala participa total, asa ca entitatea Personal este desemnata drept entitate parinte si Filiala drept entitate copil. Prin urmare, o copie a cheii primare a entitatii Personal (parinte) si anume Nr_Personal este plasata in relatia Filiala (copil).

Compozitia relatiilor Personal si Filiala este:

Personal (Nr_Personal, Prenume, Nume, Strada, Oras, CodP, Functie, Sex, Salariu)

Cheie primara: Nr_Personal

Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)

Cheie primara: Nr_Filiala

Cheie alternativa: Nr_Tel sau Nr_Fax

Cheie straina: Nr_Personal_Manager se refera la Personal (Nr_Personal)

De observat ca atributul Nr_Personal, care reprezinta managerul unei filiale, a fost redenumit Nr_Personal_Manager pentru a indica mai clar scopul cheii straine in relatia Filiala.

Tipuri de relatii binare unu-la-multi (1:M)

Pentru fiecare relatie binara de tipul 1:M dintre entitatile E1 si E2 din modelul de date logic, se expediaza o copie a atributului (atributelor) cheie primara al entitatii E1 in relatia E2 pentru a actiona ca o cheie straina. Entitatea aflata in partea "singulara" a relatiei este desemnata drept entitate parinte, iar cea din partea "multipla" drept entitate copil.

Ca si anterior, pentru a reprezenta aceasta relatie, o copie a cheii primare a entitatii parinte este plasata drept cheie straina in relatia reprezentand entitatea copil.

In exemplul urmator se ilustreaza modul in care se poate reprezenta o relatie de tip 1:M prin relatii derivate dintr-un model de date logic.

Relatia Filiala Are Personal, prezentata in fig.8, este de tip 1:M, deoarece o singura filiala are mai multi membri de personal. In fig.8 se observa ca entitatea Filiala se afla in partea singulara si reprezinta entitatea parinte, iar entitatea Personal se afla in partea multipla si reprezinta entitatea copil. Relatia dintre aceste entitati este stabilita prin plasarea unei copii a cheii primare a entitatii Filiala (parinte) - si anume Nr_Filiala - in relatia Personal (copil).

Compozitia relatiilor Filiala si Personal este:

Personal (Nr_Personal, Prenume, Nume, Strada, Oras, CodP, Functie, Sex, Salariu, Nr_Filiala)

Cheie primara: Nr_Personal

Cheie straina: Nr_Filiala se refera la Filiala (Nr_Filiala)

Filiala (Nr_Filiala, Adresa, Nr_Tel, Nr_Fax, Nr_Personal_Manager)

Cheie primara: Nr_Filiala

Cheie alternativa: Nr_Tel sau Nr_Fax

Cheie straina: Nr_Personal_Manager se refera la Personal (Nr_Personal)

Relatii de tip superclasa/subclasa

In modelul de date logic pentru fiecare relatie de tip superclasa/subclasa se identifica entitatea de tip superclasa drept entitate parinte, iar cea de tip subclasa drept entitate copil.

Exista o serie de optiuni privind modul in care se poate reprezenta o astfel de relatie, sub forma uneia sau mai multor relatii. Alegerea celei mai adecvate optiuni depinde de constrangerile de disjunctie si de participare ale relatiei de tip superclasa/subclasa.

De exemplu, se considera entitatile Proprietate_de_Inchiriat si Proprietate_de_Vanzare, avand la baza existenta atributelor comune si relatiile asociate fiecareia.

Prin urmare, se vor prezenta entitatile Proprietate_de_Inchiriat si Proprietate_de_Vanzare drept subclase diferite ale superclasei Proprietate asa cum rezulta din figura 9.

	Fig.9 Superclasa Proprietate, cu subclasele Proprietate_de_Inchiriat si Proprietate_de_Vanzare (atributul Adresa nu este descompus)

Exista diverse modalitati de reprezentare a acestei relatii, dupa cum se prezinta in continuare:

Optiunea 1.        

Toata_Proprietatea (Nr_Proprietate, Adresa, Tipul, Chirie, Pret)

Cheie primara: Nr_Proprietate

Optiunea 2.        

Proprietate_de_Inchiriat (Nr_Proprietate, Adresa, Tipul, Chirie)

Cheie primara: Nr_Proprietate

Proprietate_de_Vanzare (Nr_Proprietate, Adresa, Tipul, Pret)

Cheie primara: Nr_Proprietate

Optiunea 3.        

Proprietate (Nr_Proprietate, Adresa, Tipul)

Cheie primara: Nr_Proprietate

Proprietate_de_Inchiriat (Nr_Proprietate, Chirie)

Cheie straina: Nr_Proprietate se refera la Proprietate (Nr_Proprietate)

Proprietate_de_Vanzare (Nr_Proprietate, Pret)

Cheie straina: Nr_Proprietate se refera la Proprietate (Nr_Proprietate

Aceasta variaza de la plasarea tuturor atributelor proprietatii intr-o singura relatie (Optiunea 1), pana la impartirea lor in trei relatii (Optiunea 3). Cea mai adecvata reprezentare a relatiei de tip superclasa/subclasa este determinata de constrangerile impuse acesteia.

Relatia pe care o are superclasa Proprietate cu subclasele sale este total disjuncta, intrucat fiecare membru al superclasei Proprietate trebuie sa fie membru al uneia dintre subclase (Proprietate_de_Inchiriat sau Proprietate_de_Vanzare), dar nu poate apartine ambelor. Altfel spus, pentru o relatie de tip superclasa/subclasa care este total disjuncta, se creeaza cate o relatie separata care sa reprezinte fiecare subclasa si se include cate o copie a atributului (atributelor) cheie primara al superclasei in fiecare dintre acestea. Prin urmare, se va alege Optiunea 2 drept cea mai buna reprezentare a acestei relatii.

Totusi, mai exista si alti factori care pot influenta alegerea finala, cum ar fi faptul ca subclasele pot sa fie implicate in relatii diferite.

Documentarea relatiilor si atributelor chei straine

Compozitia relatiilor extrase din modelul de date logic se documenteaza utilizand limbajul DBDL. Se constata ca sintaxa limbajului DBDL poate fi extinsa pentru a reprezenta constrangerile de integritate asupra cheilor straine. De asemenea, dictionarul de date trebuie reactualizat pentru a reflecta orice atribute cheie noi care au fost identificate in decursul acestei etape.

Validarea modelului de date logic prin utilizarea normalizarii

Normalizarea este utilizata pentru a imbunatati modelul, astfel incat acesta sa satisfaca diverse constrangeri care evita dublarea inutila a datelor. Normalizarea garanteaza ca modelul este mai apropiat de intreprindere, este coerent, are o redundanta minima si o stabilitate maxima. Normalizarea are rolul de a stabili atributele care apartin unui tip de entitate. Conceptul fundamental al teoriei relationale este acela ca atributele sunt grupate impreuna intr-o relatie, deoarece intre ele exista o legatura logica. Uneori se argumenteaza ca un proiect normalizat al unei baze de date nu prezinta o eficienta de prelucrare maxima. In general, in favoarea normalizarii pledeaza urmatoarele argumente:

proiectul normalizat organizeaza datele conform dependentelor lor functionale, altfel spus, procesul se afla situat undeva intre proiectarea conceptuala si cea fizica;

proiectarea logica poate sa nu conduca la proiectul final, ea trebuind sa reprezinte cea mai buna conceptie a proiectantului, privind natura si semnificatia datelor din cadrul intreprinderii; in momentul in care exista criterii specifice privind performantele, proiectarea fizica poate sa fie diferita;

un proiect normalizat este robust si fara anomalii de reactualizare;

calculatoarele actuale sunt mult mai performante fata de cele din anii anteriori, fapt care face ca implementarea unui proiect sa exceleze prin facilitati flexibile de utilizare, pe baza unui tip de prelucrare suplimentar;

cel mai important beneficiu al normalizarii este ca implica intelegerea in totalitate a fiecarui atribut care trebuie sa fie reprezentat in baza de date, acesta reprezentand;

normalizarea realizeaza un proiect al bazei de date flexibil, care poate fi extins cu usurinta.

In etapa anterioara au fost extrase relatiile din modelul de date logic local, iar in aceasta se va examina gruparile atributelor din fiecare din aceste relatii.

Altfel spus, se va valida compozitia fiecarei relatii, utilizand regulile de normalizare.

Procesul de normalizare contine urmatoarele etape principale:

q      prima forma normala (1NF), care elimina gruparile repetitive;

q      a doua forma normala (2NF), care elimina dependentele partiale de cheia primara;

q      a treia forma normala (3NF), care elimina dependentele tranzitive de cheia primara;

q      forma normala Boyce-Codd (BCNF), care elimina anomaliile ramase din dependentele functionale.

Obiectivul acestei etapei este de a garanta ca fiecare relatie extrasa din modelul de date logic se afla cel putin in forma normala Boyce-Codd (BCNF).

In cazul in care se identifica relatii care nu se gasesc in BCNF, acest lucru ar putea indica faptul ca o parte din modelul de date logic este gresita sau ca a fost introdusa o eroare la extragerea relatiei din model. In acest caz, daca este necesar, trebuie restructurat modelul de date, pentru a garanta faptul ca acesta este o reprezentare "adevarata" a sectorului de intreprindere care este modelat.

Validarea modelului conform tranzactiilor utilizatorului

Aceasta consta in garantarea faptului ca modelul de date logic accepta tranzactiile cerute de catre vederile utilizatorului. Tranzactiile cerute de catre fiecare vedere a utilizatorilor pot fi determinate din specificatia cerintelor acestora. Prin folosirea diagramei ER, a dictionarului de date si a legaturilor cheie primara/cheie straina prezentate in relatii, se incearca efectuarea manuala a operatiilor. In cazul cand toate tranzactiile pot fi rezolvate in acest mod, se realizeaza o validare a modelului de date logic conform tranzactiilor. Daca o tranzactie nu poate fi efectuata manual, inseamna ca exista o problema in cadrul modelului de date, care este necesar sa fie rezolvata.

In acest caz, este posibil sa se fi omis o entitate, o relatie sau un atribut din componenta modelului de date.

Pentru a garanta faptul ca modelul de date logic local accepta tranzactiile cerute se vor analiza doua abordari posibile.

Prima abordare necesita verificarea faptului ca modelul furnizeaza informatiile (entitati, relatii si atributele acestora) cerute de catre fiecare tranzactie, prin documentarea unei descrieri a cerintelor acestora. Ca exemplu putem lua tranzactiile corespunzatoare entitatii Manager din cadrul unei filiale, care ar putea cuprinde urmatoarele operatii:

inserarea detaliilor referitoare la un nou mebru al personalului; cheia primara a relatiei Personal este atributul Nr_Personal si, mai intai, se verifica daca nu cumva noul numar de personal exista deja, daca exista se interzice inserarea si se abandoneaza procesul; in caz contrar, se insereaza detaliile referitoare la noul membru al personalului; se controleaza apoi ca fiecare detaliu sa fie reprezentat de catre un atribut din relatia Personal;

stergerea detaliilor referitoare la un membru al personalului, cunoscandu-se numarul de personal; in acest caz, se cauta valoarea respectiva in coloana corespunzatoare a relatiei Personal; daca nu exista, a aparut o eroare a utilizatorului si detaliile nu pot fi sterse; in caz contrar, se sterge tuplul din relatia Personal si se reactualizeaza cheile straine ale tuplurilor din relatia Proprietate, corespunzatoare proprietatii alocate acelui membru al personalului pentru a fi administrata.

A doua abordare in validarea modelului de date conform tranzactiilor cerute presupune reprezentarea schematica a caii urmate de fiecare tranzactie, direct in diagrama ER. In figura 10 se prezinta o astfel de abordare, in care se utilizeaza tranzactiile (a), respectiv (b).

		Fig.10 O reprezentare schematica a tranzactiilor (a) si (b)

Aceasta abordare permite vizualizarea zonelor din model care nu sunt cerute de catre tranzactii, precum si a acelor zone care sunt de importanta critica pentru acestea.

Prin urmare, este necesar a se revedea direct suportul oferit de catre modelul de date pentru tranzactiile cerute.

In cazul in care exista zone ale modelului care nu par sa fie utilizate de vreo tranzactie, se poate pune in discutie rostul reprezentarii acestor informatii in modelul de date. Pe de alta parte, daca exista zone ale modelului care nu sunt adecvate pentru furnizarea caii corecte a unei tranzactii, s-ar putea sa fie necesara analizarea posibilitatii ca anumite tipuri de entitati sau de relatii de importanta critica sa fi fost omise.

Desenarea diagramei Entitate-Relatie

Obiectivul acestei etape consta in desenarea unei diagrame Entitate-Relatie (E-R) finale, care sa constituie o reprezentare logica locala a datelor dintr-o vedere a utilizatorului asupra intreprinderii. Aceasta diagrama a fost validata prin utilizarea procesului de normalizare si conform tranzactiilor pe care trebuie sa le accepte.

Definirea constrangerilor de integritate din cadrul unei vederi a utilizatorului asupra intreprinderii

Constrangerile de integritate sunt acelea care trebuie impuse pentru a proteja baza de date fata de situatia de a deveni incoerenta.

In aceasta etapa se vor specifica numai ce constrangeri de integritate sunt necesare, fara a stabili modul in care se vor realiza acestea. Se considera cinci tipuri de constrangeri de integritate privind:

datele necesare: se identifica atributele care trebuie sa contina o valoare valabila, adica atributele care nu au voie sa contina informatii lipsa sau null-uri; de exemplu, atributele Nr_Persoana si Nume_Prenume din entitatea Personal trebuie sa contina intotdeauna o valoare si nu pot contine null-uri; totusi, atributul Nr_Tel din entitatea Personal nu este necesar sa contina intotdeauna o valoare si, prin urmare, poate contine null-uri ce pot reprezenta informatii lipsa, necunoscute sau inaplicabile; detaliile despre atributele din modelul de date corespunzator vederii supervizorului au fost descrise in sectiunea 1.1.3.

domeniile atributelor: domeniul corespunzator unui atribut identifica multimea de valori permise pe care le poate contine acesta; de exemplu, multimea de valori corespunzatoare atributului Nr_Client din entitatea Client este formata din variabile de tip sir de cinci caractere care contin valorile cuprinse intre CR1 si CR999; exemple de domenii ale atributelor din modelul de date logic local al supervizorului au fost descrise in sectiunea 1.1.4.

integritatea entitatilor: cheia primara a unei entitati nu trebuie sa admita null-uri; de exemplu, fiecare aparitie a entitatii Filiala trebuie sa contina o valoare a atributului cheie primara Nr_Filiala; atributele care constituie cheia primara a fiecarei entitati au fost identificate in sectiunile 1.1.5. si

integritatea referentiala: in general, relatiile dintre entitati sunt reprezentate prin plasarea unei copii a cheii primare a entitatii parinte in relatia copil; integritatea referentiala semnifica faptul ca, daca cheia straina a unei relatii copil contine o valoare, acea valoare trebuie sa se refere la o aparitie existenta si valabila din relatia parinte; de exemplu, daca atributul Nr_Filiala (cheie straina) din relatia (copil) Personal contine valoarea B3, aceasta valoare trebuie sa fie continuta in atributul Nr_Filiala (cheie primara) din relatia (parinte) Filiala; se va sigura integritatea referentiala prin specificarea unor constrangeri de existenta asupra cheilor primare si straine; aceste constrangeri definesc conditiile in care sunt reactualizate sau sterse aparitiile unei chei primare, respectiv inserate sau reactualizate aparitiile unei chei straine.

Inserarea unei noi aparitii a unei chei primare sau stergerea unei aparitii a unei chei straine nu constituie cauza unor probleme privind integritatea referentiala.

Pentru fiecare cheie straina a unei relatii, trebuie definite conditiile de reactualizare sau stergere a cheii primare corespunzatoare. In definirea acestor conditii se poate alege dintr-o serie de strategii si anume: NO ACTION; CASCADE, SET NULL, SET DEFAULT si NO CHECK.

Constrangerile de existenta asupra cheilor straine ale relatiei Proprietate_de_Inchiriat vor fi descrise utilizand limbajul de definire al bazelor de date (DBDL):

Proprietate_de_Inchiriat (Nr_Proprietate, Strada, Zona, Oras, CodP, Tipul, Camere, Nr_Proprietar, Nr_Personal, Nr_Filiala)

Cheie primara: Nr_Proprietate

Cheie straina: Nr_Proprietar se refera la Proprietar_Privat (Nr_Proprietate) si Proprietar_Afacere(Nr_Proprietar), la stergere NO ACTION, la reactualizare CASCADE

Cheie straina: Nr_Personal se refera la Personal (Nr_Personal), la stergere SET NULL, la reactualizare CASCADE

Cheie straina: Nr_Filiala se refera la Filiala (Nr_Filiala), la stergere NO ACTION, la reactualizare CASCADE

constrangerile intreprinderii: sunt definite de catre regulile intreprinderii, care controleaza tranzactiile din "lumea reala"; de exemplu, o agentie specifica faptul ca un supervizor poate supraveghea minim 5 si maxim 10 membri de personal in acelasi timp; regulile intreprinderii din specificatia cerintelor utilizatorului sunt enumerate anterior; in modelul de date logic corespunzator vederii supervizorului se documenteaza detaliile referitoare la toate constrangerilor de integritate.

Revizuirea modelului de date logic local, impreuna cu utilizatorul

In cadrul acestei etape se valideaza modelul de date logic local, corespunzator vederii supervizorului, prin revizuirea acestuia impreuna cu utilizatorul (utilizatorii). Este foarte important ca modelul sa constituie o reprezentare "adevarata" a "lumii reale" asa cum este perceputa de catre supervizor. Diagrama E-R actioneaza ca un mijloc de comunicare intre realizatorul (realizatorii) modelului si utilizator (utilizatori).

Este foarte important ca utilizatorii sa analizeze documentatia care sustine modelul. In cazul in care utilizatorii constata un punct slab in model sau documentatie, trebuie repetate etapele necesare. Modelul de date logic local, corespunzator vederii supervizorului din studiul evolutiv, cuprinde un model E-R ca cel prezentat in figura 11 (anexa 1) si documentatia care descrie componentele acesteia.