CAPITOLUL 2.

PROIECTAREA MODELULUI RELAIONAL AL DATELOR PRIN NORMALIZARE

n literatura de specialitate, n funcie de complexitatea bazei de date sunt abordate urmtoarele metode de proiectare: proiectarea modelului relaional printr-un model static (utiliznd limbajul UML); proiectarea modelului relaional printr-un model conceptual (utiliznd modelul entitate asociere); proiectarea modelului relaional prin procesul de normalizare. n continuare este prezentat proiectarea modelului relaional prin procesul de normalizare. Normalizarea este procesul care presupune descompunerea unui tabel relaional alctuit dintr-un set de atribute, n dou sau mai multe tabele care vor forma baza de date, cu scopul de a elimina redundanele (memorarea repetat a acelorai date) i anomaliile care pot aprea n operaiile de adugare, modificare sau tergere de nregistrri. Acest proces se fundamenteaz pe conceptele: dependen funcional dependen multivaloare forme normale.

Ideea central care st la baza proiectrii unei baze de date relaionale este aceea de dependen a datelor [Dollinger]. Aceasta se refer la faptul c ntre atributele unei relaii (tabel relaional) sau ntre atribute din relaii diferite pot exista anumite legturi logice (dependene), iar aceste legturi influeneaz proprietile relaiilor n raport cu operaiile curente care apar n exploatarea bazei de date, cum ar fi: adugarea, modificarea i tergerea nregistrrilor. Exemplu: Fie relaia Aprovizionare (Cod_Fz, Nume-fz, Adresa_Fz, DenMarfa, PretFact):
Cod_Fz 100 100 101 102 Nume_Fz SC ALFA SRL SC ALFA SRL SC BETA SRL SC GAMA SRL ----------Adresa_Fz Bucuresti Bucuresti Brasov Galati ---------DenMarfa Portocale Banane Portocale Kiwi --------PretFact 5 3 4.8 6 --------

Analiznd aceast relaie se observ o redundan a datelor pentru aprovizionrile realizate cu acelai furnizor. Altfel spus valorile asociate atributelor Nume_Fz i Adres_Fz se repet la fiecare marf livrat de acel furnizor. Mai mult aceast redundan a datelor conduce la apariia urmtoarelor anomalii: Anomalia de adugare nu se poate nregistra un furnizor att timp ct acesta nu livreaz o marf.

Anomalia de tergere dac se terg toate mrfurile livrate de un furnizor, atunci se pierd, n mod neintenionat, i caracteristicile acelui furnizor (numele furnizorului, adresa furnizorului). Anomalia de modificare dac se modific, spre exemplu, adresa unui furnizor, atunci este necesar parcurgerea ntregii relaii pentru a opera modificarea la nivelul tuturor nregistrrilor.

Aceste anomalii pot fi eliminate, dac tabelul iniial Aprovizionare este supus unui proces de normalizare, n urma cruia va fi descompus n urmtoarele tabele: Furnizori (Cod_Fz, Nume_Fz, Adresa_Fz) Livrare (Cod_fz, DenMarfa, PretFact) Furnizori Cod_Fz 100 101 102 Livrare Cod_Fz 100 100 101 102 Den_Marfa Portocale Banane Portocale Kiwi PretFact 5 3 4.8 6 Nume_Fz SC ALFA SRL SC BETA SRL SC GAMA SRL Adresa_Fz Bucureti Brasov Galai

2.1. Dependene funcionale 2.1.1. Dependena funcional simpl ntre dou atribute X i Y exist o dependen funcional simpl, notat , dac i numai dac fiecrei valori a atributului X i corespunde o singur valoare a atributului Y. Atributul X se numete determinantul iar Y determinatul dependenei. De exemplu, pentru o valoare asociat unui CodMarfa i corespunde o singur valoare pentru DenMarfa. n acest caz, este vorba despre o dependen funcional ce se stabilete ntre cele dou atribute, reprezentat astfel: CodMarfa DenMarfa. Alte exemple de dependene funcionale sunt reprezentate mai jos: NrFact Datafact NrFact CodFz. CodMarfa, Nrfact PretFact Tipuri de dependene funcionale: Dependena funcional total. Dependena funcional XY este total dac nu exist nici un subset Z al atributului X astfel nct ZY. Exemplu: NrFact Datafact NrFact CodFz CodMarfa, Nrfact PretFact Dependena funcional parial. Dependena funcional exist un subset Z al atributului X (Z X) astfel ncat ZY. este parial dac

Exemplu: CodMarfa, Nrfact Codfz este o dependen parial deoarece exist subsetul Nrfact care determin funcional CodFz. Dependena funcional trivial. Dependena funcional exist un subset Y al atributului X (Y X) astfel ncat XY. este trivial dac

Exemplu: CodMarfa, Nrfact Nrfact este o dependen trivial, care nu aduce nici un plus de informaie. Dependenele funcionale pot fi deduse folosind un set de reguli, numite axiomele lui Armstrong [Dollinger]: 1. Reflexivitate: Dac Y X, atunci X Y. Exemplu: Dac Nrfact (CodMarfa, Nrfact), atunci (CodMarfa, Nrfact) Nrfact. Aceast axiom genereaz dependenele funcionale triviale. 2. Augmentare (Amplificare): Dac X Y, atunci X Z Y Z Exemplu: Dac NrFact CodFz , atunci (Nrfact, Nrdocplata) (Codfz, Nrdocplata).

3. Tranzitivitate: Dac XY i YZ, atunci XZ. Exemplu: Dac NrFact CodFz i Codfz Denfz, atunci NrfactDenfz. Aceast axiom este utilizat n aplicarea formelor normale. 2.1.2. Dependena funcional multipl ntre dou atribute X i Y exist o dependen funcional multipl, notat X Y, dac i numai dac pentru o valoare a atributului X corespund dou sau mai multe valori a atributului Y. De exemplu, pentru o valoare asociat unui CodFz vor corespunde mai multe valori pentru NrFact, deoarece la date calendaristice diferite unui furnizor i se pot emite mai multe facturi. n acest caz, este vorba despre o dependen funcional multipl ce se stabilete ntre cele dou atribute, reprezentat astfel: CodFz NrFact. De asemenea, pe o factur se pot regsi mai multe mrfuri aprovizionate, fapt pentru care putem spune c ntre atributele Nrfact i CodMarfa se stabilete o dependen funcional multipl (Nrfact CodMarfa). 2.2. Dependene multivaloare Se consider relaia R(X,Y,Z), unde X,Y,Z sunt atributele acesteia (simple sau compuse). Fie xi,yi,zi valorile atributelor X,Y i Z [Dollinger]. Spunem c exist o dependen multivaloare a atributului Z fa de Y, notat YZ, dac pentru orice valori x1, x2, y, z1 i z2, x1x2, z1z2, astfel nct tuplurile (x1,y,z1) i (x2,y,z2) fac parte din relaia R, atunci i tuplurile (x1,y,z2) i (x2,y,z1) fac parte din relaia R. Din simetria definiiei rezult c dependena multivaloare YZ implic dependena multivaloare YX. De exemplu, n relaia R(Serie_Facultate, NrMatricolStudent, NumeProfesor) exist dependene multivaloare, deoarece la seria unei faculti sunt nscrii mai muli studeni, care studiaz cu mai muli profesori la materii diferite. Dac fiecare student studiaz cu toi profesorii, atunci exist urmtoarele dependene multivaloare: Serie_Facultate NrMatricolStudent Serie_Facultate NumeProfesor n mod practic, dac exist tuplurile (EAM_SeriaA, NrMatricol1, Profesor_Info) i (EAM,_SeriaA, NrMatricol2, Profesor_Mate) atunci vor exista i tuplurile (EAM_SeriaA, NrMatricol1, Profesor_Mate) i (EAM_SeriaA, NrMatricol2, Profesor_Info). n general dependenele multivaloare sunt mai dificil de identificat i mai rar ntlnite n practic, fapt ce ne determin s nu insistm mai mult asupra lor.

2.3 Formele normale Teoria clasic a normalizrii este construit n jurul a cinci forme normale. E.F.Codd, printele modelului relaional, a definit iniial trei forme normale [Fotache]: FN1, FN2 i FN3. Apoi, forma normal Boyce-Codd, numit astfel dup numele celor doi specialiti n domeniu, s-a dorit a fi o form generalizat a FN2 i FN3. Aceste patru forme normale sunt asociate dependenelor funcionale. Formele normale 4 i 5 (FN4, FN5), asociate n literatura de specialitate cu numele cercettorului Fagin, se bazeaz pe dependenele multivaloare. Muli specialiti consider c pentru elaborarea unei baze de date relaionale sunt suficient de parcurs primele trei forme normale. Plecnd de la acest prezumie, n continuare vom prezenta doar primele trei forme normale (FN1, FN2 FN3). Forma normal 1 (FN1) O relaie (tabel) este n prima form normal dac toate atributele sale sunt atomice (elementare, care nu se mai pot descompune) i nerepetitive. Un atribut este considerat elementar atunci cnd descompunerea lui nu prezint interes pentru aplicaia ce se va dezvolta. Exemplu: Fie tabelul Furnizor (CodFz, DenFz, Adresa) Localitate Strada Numr CodFz
1 2 3 ----------

DenFz
SC Agro SA SC Muntenia SA SC Tram SA --------------

Adresa
Bucureti, str. Popa Nan, nr.3 Bucureti, str. Alexandriei, nr.36 Braov, str. Biserica Neagr, nr.10 --------------

Tabelul Furnizor nu respect FN1 dac exist cerine privind gruparea furnizorilor dup localiti, deoarece este mult mai greu s extragi aceast informaie dintr-o adres complet. Forma normal 2 (FN2). O relaie este n cea de-a doua form normal dac respect FN1 i orice atribut non-cheie este total dependent fa de cheia primar a relaiei. Exemplu: Fie tabelul Marfuri_Facturi (NrFact, CodMarfa, DenMarfa, UM, Calitate, CantFact). NrFact 10 10 11 CodMarfa 100 200 400 DenMarfa Portocale Kiwi Pomelo UM kg kg buc Calitate 1 1 2 CantFact 70 90 50

11 ---------

100 ---------------

Portocale

kg

1 -----------

100 ---------------

---------------- ----

Analiznd aceast relaie, pot fi identificate urmtoarele dependene funcionale: CodMarfa DenMarfa, UM, Calitate, deoarece fiecare cod unic de marf determin o valoare pentru denumirea mrfii, unitate de msur, calitate. NrFact, CodMarfa CantFact, atributul compus (Nrfact, CodMarfa) determin funcional CantFact.n mod practic, unei facturi nu i se poate asocia o cantitate facturat total, altfel spus ntre NrFact i CantFact nu poate exista o dependen funcional.

Pornind de la aceste dependene se deduce c relaia Marfuri_Facturi are o cheie primar compus, format din atributele NrFact i CodMarfa. n mod practic, tabelul Marfuri_Facturi nu respect FN2 deoarece se poate observa dependena funcional a atributelor DenMarfa, UM, Calitate fa de CodMarfa, ceea ce implic dependena parial a acestor atribute fa de cheia relaiei format din NrFact i CodMarfa. Aceast dependen funcional parial are drept consecine o serie de anomalii: anomalia de adugare nu se pot aduga noi mrfuri atta timp ct acestea nu sunt aprovizionate, altfel spus nu apar pe o factur; anomalia de tergere - dac se terge nregistrarea corespunztoare pentru o singur marf existent, atunci se pierd i informaiile referitoare la denumire marf, unitate de msur i calitate; anomalia de modificare - dac se cere modificarea calitii pentru o marf, trebuie cutate toate nregistrrile n care se regsete aceasta, ceea ce implic parcurgerea relaiei n ntregime.

Figura 2.1 Dependene funcionale identificate Aceste anomalii se pot elimina prin descompunerea relaiei Marfuri_Facturi n relaiile: Marfuri (CodMarfa, DenMarfa, UM, Calitate) MarfurFacturate (NrFact, CodMarfa, CantFact)

Forma normal 3 (FN3). O relaie este n FN3 dac respect FN2 i toate atributele non-cheie sunt dependente direct de cheia primar. Altfel spus FN3 interzice dependenele tranzitive. Exemplu: Fie tabelul Facturi_Furnizori (NrFact, DataFact, CodFz, DenFz, Localitate) NrFact 10 11 12 DataFact 01/03/2009 05/03/2009 12/03/2009 CodFz 1 1 2 ---------DenFz SC Agro SA SC Agro SA SC Tram SA -------------Localitate Bucureti Bucureti Braov --------------

Pot fi identificate urmtoarele dependene funcionale: NrFact DataFact, CodFz, deoarece fiecare numr de factur determin o valoare pentru data facturii i codul furnizorului care a emis acea factur. CodFz DenFz, Localitate, deoarece fiecare cod unic de furnizor determin o valoare pentru denumirea furnizorului i Localitatea acestuia.

Se observ ca ntre atributele NrFact i DenFz, Localitate apar dependene tranzitive, fapt ce ne determin s afirmm c tabelul Facturi_Furnizori nu respect FN3. Aceste dependene funcional tranzitive au drept consecine o serie de anomalii identificabile la adugarea, modificarea sau tergerea nregistrrilor din cadrul acestui tabel. Aceste anomalii pot fi eliminate prin descompunerea relaiei Facturi_Furnizori n relaiile: Facturi (NrFact, DataFact, CodFz) Furnizori (CodFz, DenFz, Localitate)

2.4 Cadrul metodologic de proiectare a modelului relaional prin normalizare Proiectarea unei baze de date relaionale prin normalizare se poate realiza prin: descompunerea tabelului relaional iniial n mai multe tabele, utiliznd formele normale (FN1, FN2, FN3, FN4, FN5); descompunerea tabelului relaional iniial n mai multe tabele, utiliznd matricea dependenelor funcionale sau graful dependenelor.

2.4.1 Proiectarea modelului relaional prin normalizare utiliznd formele normale Paii recomandai a fi realizai pentru proiectarea modelului relaional prin normalizare, utiliznd formele normale sunt [Fotache]: 1. Inventarierea atributelor i constituirea tabelului relaional iniial (relaiei universale). Se vor prelua toate atributele care fac obiectul problemei de rezolvat, din documentele primare i situaiile de ieire. 2. Se determin cheia primar a relaiei i se reprezint toate dependenele funcionale ce decurg de aici. 3. Se elimin atributele calculabile i cele repetitive astfel nct tabelul iniial s respecte FN1. 4. Se elimin dependenele funcionale pariale prin descompunerea tabelului iniial n tabele cu structuri mai simple, care s respecte FN2. 5. Se elimin dependenele funcionale tranzitive prin descompunerea tabelelor din etapa anterioar astfel nct acestea s respecte FN3. 6. Se identific eventualele dependene multivaloare i se elimin astfel nct s tabelele s respecte FN4, respectiv FN5. 2.4.2 Proiectarea modelului relaional prin normalizare utiliznd matricea dependenelor funcionale Demersul metodologic de proiectare a unui model relaional prin normalizare utiliznd matricea dependenelor funcionale sau graful dependenelor presupune parcurgerea urmtoarelor etape: 1. Inventarierea atributelor. ntr-un dicionar al datelor se vor prelua toate atributele care fac obiectul problemei de rezolvat, din documentele primare i situaiile de ieire.

2. Specificarea regulilor de gestiune diverse restricii/condiii impuse datelor. La nivelul acestei etape, algoritmii de calcul sunt asociai i ei regulilor de gestiune. 3. ntocmirea dicionarului de date de ctre proiectantul bazei de date care va urmri respectarea urmtoarelor reguli: atributele sunt nscrise o singur dat; sunt eliminate atributele sinonime; sunt eliminate atributele calculate.

4. Stabilirea cheilor primare. 5. Stabilirea dependenelor funcionale ce pot fi descrise printr-un graf al dependenelor sau n cadrul unei matrice a dependenelor funcionale. 6. Pentru atributele izolate se vor cuta grupuri de atribute ce pot constitui determinani ai acestora. 7. Formarea tabelelor - cu fiecare cheie primar i atributele determinate direct i netranzitiv se va forma un tabel. 8. Identificarea atributelor cu rol de cheie extern. 9. Definitivarea modelului relaional. EXEMPLU: O societate comercial dorete s-i informatizeze activitatea de aprovizionare cu mrfuri de la furnizori. Furnizorii societii, se identific printr-un cod unic, nume, localitate, telefon i cont bancar. Aprovizionarea cu mrfuri se realizeaz n baza facturilor primite de la furnizori, fiecare Factur identificndu-se printr-un numr unic, dat factur, data scadenei, codul, denumirea, contul bancar al furnizorului, codul, denumirea i contul clientului, codul, denumirea, unitatea de msur, cantitatea i preul mrfurilor facturate, valoarea acestora, valoare TVA i valoarea total a facturii. Pentru fiecare zi de ntrziere (fa de data scadenei) a plii facturii, furnizorii percep o penalizare de 1% din valoarea total a facturii. Nomenclatorul mrfurilor include referine la codul de marf, denumire marf, unitatea de msur i calitate. Nomenclatorul va conine maxim 100 de mrfuri distincte ale cror uniti de msur sunt exprimate n kg, buc, litri. Plata facturii se realizeaz printr-o Chitan, conform facturii emise, n care se precizeaz numrul chitanei, data chitanei, suma pltit, denumirea i contul emitentului, denumirea i contul beneficiarului (furnizorului). Societatea pltete cu un astfel de document o singur factur. Se cere s se proiecteze baza de date relaional prin normalizare utiliznd matricea dependenelor funcionale. n acest scop s-au parcurs paii urmtori (descrii n cadrul metodologic de proiectare a modelului relaional prin normalizare): 1. Inventarierea atributelor. Pe baza informaiilor referitoare la activitatea de aprovizionare cu mrfuri de la furnizori, se poate ntocmi dicionarul de atribute:

Nr. Atribut Crt. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25 CodFz CodBenef NumeFz Localitate Telefon ContBancar NrFact DataFact DataScad CantitateFact PretFact CotaTVA Valoaremarfa TVA ValoareFactura CodMarfa DenMarfa UM Calitate Nrchit DataChit SumaPl TotalSumePl Penalizare Nr_zile-intarz

Semnificaie Cod Furnizor Cod Beneficiar Nume Furnizor Localitate Furnizor Telefon Furnizor Cont Bancar Furnizor Numr Factur Data Facturii Data Scaden Factur Cantitate Facturat Pret Facturare Cota TVA Valoare Marf Facturat Valoare TVA Valore Total Factur Cod Marf Denumire Marf Unitate de Msur Calitate Marf Numr Chitan Data Chitan Suma Pltit Sume Totale Pltite Penalizare Factur Nr. Zile de ntrziere

2. Specificarea regulilor de gestiune: O factur este emis de un singur furnizor. O factur poate conine mai multe mrfuri, iar o marf se poate regsi pe mai multe facturi.

 O factur poate fi pltit ealonat. O chitan este conform cu o factur emis de furnizor. Algoritmi de calcul: Valoare_Marf=CantitateFact*PretFact TVA=CotaTVA*Valore_Marfa ValoareFactura=Valoare_Marfa+TVA Nr_zile_ntarz=DataChit - DataScad Penalizare =Nr_zile_intarziere*ValoareFactura*1/100 Totalsumepl= suma pl 3. ntocmirea dicionarului de date, se va realiza pe baza urmtoarelor reguli: fiecare atribut este nscris o singur dat; sunt eliminate atributele sinonime (n exemplul prezentat, CodFz i CodBenef sunt sinonime, deci se va reine doar unul dintre acestea CodFz); nu sunt preluate atributele calculate (Valoare_Marfa, TVA, ValoareFactura, Nr_zile_ntarz, Penalizare, Totalsumepl).

Dicionarul de date (DD): CodFz, NumeFz, Localitatea, ContBancar, Telefon, NrFact, DataFact, DataScad, CantitateFact, PretFact, CotaTVA, CodMarfa, DenMarfa, UM, Calitate, NrChit, DataChit, SumaPl. 4. Stabilirea cheilor primare: CodFz, NrFact, CodMarfa, NrChit. 5. Stabilirea dependenelor funcionale. a. Graful dependenelor funcionale simple:

b. Graful dependenelor funcionale multiple: Nrfact NrFact CodFz NrChit CodMarfa NrFact NrFact CodMarfa

6. Atributele izolate: CantitateFact, PretFact i CotaTVA vor fi determinate de un grup de atribute aa cum sunt reprezentate mai jos.

Ne punem ntrebarea De ce Nrfact nu determin funcional, spre exemplu, Cantitatefact?. n mod practic, o factur poate conine mai multe mrfuri achiziionate i, prin urmare, Nrfact nu va determina o singur valoare pentru CantitateFact. Pentru o factur (NrFact) se poate asocia o valoare total facturat, dar nu se pot nsuma cantitaile, preurile, CotaTva a mrfurilor facturate. Atributul compus (Nrfact, CodMarfa) reprezint o cheie primar care se va aduga cheilor identificate n etapa precedent. Dependenele funcionale identificate anterior se vor reprezenta ntr-o Matrice a dependenelor funcionale (reprezentat ntr-o form simplificat, fr a include dependenele funcionale multiple i dependenele funcionale multiple tranzitive, n figura 2.2). Liniile i coloanele acestei matrici sunt reprezentate de atributele din dicionarul de date i atribut ele compuse care au fost identificate ca fiind chei primare. Cheile primare sunt marcate prin caracterul #. Pentru fiecare cheie primar, pe acea linie, sunt reprezentate tipurile de dependene funcionale identificate astfel: 1- dependenele funcionale simple 1T - dependenele funcionale simple tranzitive

Figura 2. 2 Matricea dependenelor funcionale 7. Formarea tabelelor. Fiecare cheie primar i atributele determinate direct i netranzitiv vor forma un tabel. 8. Identificarea cheilor externe (atributele subliniate prin linie discontinu la nivelul modelului relaional). 9. Definitivarea modelului relaional. FURNIZORI (CodFz, NumeFz, Localitate, Telefon, ContBancar) FACTURI (NrFact, DataFact, DataScad, CodFz) MARFURI(CodMarfa, DenMarfa, UM, Calitate) MARFURIFACTURATE (CodMarfa, NrFact, CantitateFact, PretFact, CotaTVA) CHITANTE (NrChit, DataChit, SumaPl, NrFact)