CAPITOLUL 2. PROIECTAREA MODELULUI RELAŢIONAL AL DATELOR PRIN NORMALIZARE

Size: px

Start display at page:

Download "CAPITOLUL 2. PROIECTAREA MODELULUI RELAŢIONAL AL DATELOR PRIN NORMALIZARE"

Daniel Franklin
6 years ago
Views:

1 CAPITOLUL 2. PROIECTAREA MODELULUI RELAŢIONAL AL DATELOR PRIN NORMALIZARE În literatura de specialitate, în funcţie de complexitatea bazei de date sunt abordate următoarele metode de proiectare: proiectarea modelului relaţional printr-un model static (utilizând limbajul UML); proiectarea modelului relaţional printr-un model conceptual (utilizând modelul entitate asociere); proiectarea modelului relaţional prin procesul de normalizare. În continuare este prezentată proiectarea modelului relaţional prin procesul de normalizare. Normalizarea este procesul care presupune descompunerea unui tabel relaţional alcătuit dintr-un set de atribute, în două sau mai multe tabele care vor forma baza de date, cu scopul de a elimina redundanţele (memorarea repetată a aceloraşi date) şi anomaliile care pot apărea în operaţiile de adăugare, modificare sau ştergere de înregistrări. Acest proces se fundamentează pe conceptele: dependenţă funcţională dependenţă multivaloare forme normale. Ideea centrală care stă la baza proiectării unei baze de date relaţionale este aceea de dependenţă a datelor [Dollinger]. Aceasta se referă la faptul că între atributele unei relaţii (tabel relaţional) sau între atribute din relaţii diferite pot exista anumite legături logice (dependenţe), iar aceste legături influenţează proprietăţile relaţiilor în raport cu operaţiile curente care apar în exploatarea bazei de date, cum ar fi: adăugarea, modificarea şi ştergerea înregistrărilor. Exemplu: Fie relaţia Aprovizionare (Cod_Fz, Nume-fz, Adresa_Fz, DenMarfa, PretFact): Cod_Fz Nume_Fz Adresa_Fz DenMarfa PretFact 100 SC ALFA SRL Bucuresti Portocale SC ALFA SRL Bucuresti Banane SC BETA SRL Brasov Portocale SC GAMA SRL Galati Kiwi Analizând această relaţie se observă o redundanţă a datelor pentru aprovizionările realizate cu acelaşi 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 apariţia următoarelor anomalii: Anomalia de adăugare nu se poate înregistra un furnizor atât timp cât acesta nu livrează o marfă.

2 Anomalia de ştergere dacă se şterg toate mărfurile livrate de un furnizor, atunci se pierd, în mod neintenţionat, şi caracteristicile acelui furnizor (numele furnizorului, adresa furnizorului). Anomalia de modificare dacă se modifică, spre exemplu, adresa unui furnizor, atunci este necesară parcurgerea întregii relaţii pentru a opera modificarea la nivelul tuturor înregistrărilor. Aceste anomalii pot fi eliminate, dacă tabelul iniţial Aprovizionare este supus unui proces de normalizare, în urma căruia va fi descompus în următoarele tabele: Furnizori (Cod_Fz, Nume_Fz, Adresa_Fz) Livrare (Cod_fz, DenMarfa, PretFact) Furnizori Cod_Fz Nume_Fz Adresa_Fz 100 SC ALFA SRL Bucureşti 101 SC BETA SRL Brasov 102 SC GAMA SRL Galaţi Livrare Cod_Fz Den_Marfa PretFact 100 Portocale Banane Portocale Kiwi 6

3 2.1. Dependenţe funcţionale Dependenţa funcţională simplă Între două atribute X şi Y există o dependenţă funcţională simplă, notată, dacă şi numai dacă fiecărei valori a atributului X îi corespunde o singură valoare a atributului Y. Atributul X se numeşte determinantul iar Y determinatul dependenţei. De exemplu, pentru o valoare asociată unui CodMarfa îi corespunde o singură valoare pentru DenMarfa. În acest caz, este vorba despre o dependenţă funcţională ce se stabileşte între cele două atribute, reprezentată astfel: CodMarfa DenMarfa. Alte exemple de dependenţe funcţionale sunt reprezentate mai jos: NrFact Datafact NrFact CodFz. CodMarfa, Nrfact PretFact Tipuri de dependenţe funcţionale: Dependenţa funcţională totală. Dependenţa funcţională X Y este totală dacă nu există nici un subset Z al atributului X astfel încât Z Y. Exemplu: NrFact Datafact NrFact CodFz CodMarfa, Nrfact PretFact Dependenţa funcţională parţială. Dependenţa funcţională este parţială dacă există un subset Z al atributului X (Z X) astfel încat Z Y. Exemplu: CodMarfa, Nrfact Codfz este o dependenţă parţială deoarece există subsetul Nrfact care determină funcţional CodFz. Dependenţa funcţională trivială. Dependenţa funcţională este trivială dacă există un subset Y al atributului X (Y X) astfel încat X Y. Exemplu: CodMarfa, Nrfact Nrfact este o dependenţă trivială, care nu aduce nici un plus de informaţie. Dependenţele funcţionale 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ă dependenţele funcţionale triviale. 2. Augmentare (Amplificare): Dacă X Y, atunci X Z Y Z Exemplu: Dacă NrFact CodFz, atunci (Nrfact, Nrdocplata) (Codfz, Nrdocplata).

4 3. Tranzitivitate: Dacă X Y şi Y Z, atunci X Z. Exemplu: Dacă NrFact CodFz şi Codfz Denfz, atunci Nrfact Denfz. Această axiomă este utilizată în aplicarea formelor normale Dependenţa funcţională multiplă Între două atribute X şi Y există o dependenţă funcţională 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ţă funcţională multiplă ce se stabileşte între cele două atribute, reprezentată astfel: CodFz NrFact. De asemenea, pe o factură se pot regăsi mai multe mărfuri aprovizionate, fapt pentru care putem spune că între atributele Nrfact şi CodMarfa se stabileşte o dependenţă funcţională multiplă (Nrfact CodMarfa) Dependenţe multivaloare Se consideră relaţia R(X,Y,Z), unde X,Y,Z sunt atributele acesteia (simple sau compuse). Fie x i,y i,z i valorile atributelor X,Y şi Z [Dollinger]. Spunem că există o dependenţă multivaloare a atributului Z faţă de Y, notată Y Z, dacă pentru orice valori x 1, x 2, y, z 1 şi z 2, x 1 x 2, z 1 z 2, astfel încât tuplurile (x 1,y,z 1 ) şi (x 2,y,z 2 ) fac parte din relaţia R, atunci şi tuplurile (x 1,y,z 2 ) şi (x 2,y,z 1 ) fac parte din relaţia R. Din simetria definiţiei rezultă că dependenţa multivaloare Y Z implică dependenţa multivaloare Y X. De exemplu, în relaţia R(Serie_Facultate, NrMatricolStudent, NumeProfesor) există dependenţe multivaloare, deoarece la seria unei facultăţi sunt înscrişi mai mulţi studenţi, care studiază cu mai mulţi profesori la materii diferite. Dacă fiecare student studiază cu toţi profesorii, atunci există următoarele dependenţe 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 dependenţele multivaloare sunt mai dificil de identificat şi mai rar întâlnite în practică, fapt ce ne determină să nu insistăm mai mult asupra lor.

5 2.3 Formele normale Teoria clasică a normalizării este construită în jurul a cinci forme normale. E.F.Codd, părintele modelului relaţional, a definit iniţial trei forme normale [Fotache]: FN1, FN2 şi FN3. Apoi, forma normală Boyce-Codd, numită astfel după numele celor doi specialişti în domeniu, s-a dorit a fi o formă generalizată a FN2 şi FN3. Aceste patru forme normale sunt asociate dependenţelor funcţionale. Formele normale 4 şi 5 (FN4, FN5), asociate în literatura de specialitate cu numele cercetătorului Fagin, se bazează pe dependenţele multivaloare. Mulţi specialişti consideră că pentru elaborarea unei baze de date relaţionale sunt suficient de parcurs primele trei forme normale. Plecând de la acestă prezumţie, în continuare vom prezenta doar primele trei forme normale (FN1, FN2 FN3). Forma normală 1 (FN1) O relaţie (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 când descompunerea lui nu prezintă interes pentru aplicaţia ce se va dezvolta. Exemplu: Fie tabelul Furnizor (CodFz, DenFz, Adresa) Localitate Strada Număr CodFz DenFz Adresa 1 SC Agro SA Bucureşti, str. Popa Nan, nr.3 2 SC Muntenia SA Bucureşti, str. Alexandriei, nr.36 3 SC Tram SA Braşov, str. Biserica Neagră, nr Tabelul Furnizor nu respectă FN1 dacă există cerinţe privind gruparea furnizorilor după localităţi, deoarece este mult mai greu să extragi această informaţie dintr-o adresă completă. Forma normală 2 (FN2). O relaţie este în cea de-a doua formă normală dacă respectă FN1 şi orice atribut non-cheie este total dependent faţă de cheia primară a relaţiei. Exemplu: Fie tabelul Marfuri_Facturi (NrFact, CodMarfa, DenMarfa, UM, Calitate, CantFact). NrFact CodMarfa DenMarfa UM Calitate CantFact Portocale kg Kiwi kg Pomelo buc 2 50

6 Portocale kg Analizând această relaţie, pot fi identificate următoarele dependenţe funcţionale: CodMarfa DenMarfa, UM, Calitate, deoarece fiecare cod unic de marfă determină o valoare pentru denumirea mărfii, unitate de măsură, calitate. NrFact, CodMarfa CantFact, atributul compus (Nrfact, CodMarfa) determină funcţional 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ţă funcţională. Pornind de la aceste dependenţe se deduce că relaţia 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 dependenţa funcţională a atributelor DenMarfa, UM, Calitate faţă de CodMarfa, ceea ce implică dependenţa parţială a acestor atribute faţă de cheia relaţiei formată din NrFact şi CodMarfa. Această dependenţă funcţională parţială are drept consecinţe o serie de anomalii: anomalia de adăugare nu se pot adăuga noi mărfuri atâta timp cât acestea nu sunt aprovizionate, altfel spus nu apar pe o factură; anomalia de ştergere - dacă se şterge înregistrarea corespunzătoare pentru o singură marfă existentă, atunci se pierd şi informaţiile referitoare la denumire marfă, unitate de măsură şi calitate; anomalia de modificare - dacă se cere modificarea calităţii pentru o marfă, trebuie căutate toate înregistrările în care se regăseşte aceasta, ceea ce implică parcurgerea relaţiei în întregime. Figura 2.1 Dependenţe funcţionale identificate Aceste anomalii se pot elimina prin descompunerea relaţiei Marfuri_Facturi în relaţiile: Marfuri (CodMarfa, DenMarfa, UM, Calitate) MarfurFacturate (NrFact, CodMarfa, CantFact)

Forma normală 3 (FN3). O relaţie este în FN3 dacă respectă FN2 şi toate atributele non-cheie sunt dependente direct de cheia primară. Altfel spus FN3 interzice dependenţele tranzitive.

7 Forma normală 3 (FN3). O relaţie este în FN3 dacă respectă FN2 şi toate atributele non-cheie sunt dependente direct de cheia primară. Altfel spus FN3 interzice dependenţele tranzitive. Exemplu: Fie tabelul Facturi_Furnizori (NrFact, DataFact, CodFz, DenFz, Localitate) NrFact DataFact CodFz DenFz Localitate 10 01/03/ SC Agro SA Bucureşti 11 05/03/ SC Agro SA Bucureşti 12 12/03/ SC Tram SA Braşov Pot fi identificate următoarele dependenţe funcţionale: NrFact DataFact, CodFz, deoarece fiecare număr 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 dependenţe tranzitive, fapt ce ne determină să afirmăm că tabelul Facturi_Furnizori nu respectă FN3. Aceste dependenţe funcţională tranzitive au drept consecinţe o serie de anomalii identificabile la adăugarea, modificarea sau ştergerea înregistrărilor din cadrul acestui tabel. Aceste anomalii pot fi eliminate prin descompunerea relaţiei Facturi_Furnizori în relaţiile: Facturi (NrFact, DataFact, CodFz) Furnizori (CodFz, DenFz, Localitate)

2.4 Cadrul metodologic de proiectare a modelului relaţional prin normalizare Proiectarea unei baze de date relaţionale prin normalizare se poate realiza prin: descompunerea tabelului relaţional

8 2.4 Cadrul metodologic de proiectare a modelului relaţional prin normalizare Proiectarea unei baze de date relaţionale prin normalizare se poate realiza prin: descompunerea tabelului relaţional iniţial în mai multe tabele, utilizând formele normale (FN1, FN2, FN3, FN4, FN5); descompunerea tabelului relaţional iniţial în mai multe tabele, utilizând matricea dependenţelor funcţionale sau graful dependenţelor Proiectarea modelului relaţional prin normalizare utilizând formele normale Paşii recomandaţi a fi realizaţi pentru proiectarea modelului relaţional prin normalizare, utilizând formele normale sunt [Fotache]: 1. Inventarierea atributelor şi constituirea tabelului relaţional iniţial (relaţiei universale). Se vor prelua toate atributele care fac obiectul problemei de rezolvat, din documentele primare şi situaţiile de ieşire. 2. Se determină cheia primară a relaţiei şi se reprezintă toate dependenţele funcţionale ce decurg de aici. 3. Se elimină atributele calculabile şi cele repetitive astfel încât tabelul iniţial să respecte FN1. 4. Se elimină dependenţele funcţionale parţiale prin descompunerea tabelului iniţial în tabele cu structuri mai simple, care să respecte FN2. 5. Se elimină dependenţele funcţionale tranzitive prin descompunerea tabelelor din etapa anterioară astfel încât acestea să respecte FN3. 6. Se identifică eventualele dependenţe multivaloare şi se elimină astfel încât să tabelele să respecte FN4, respectiv FN Proiectarea modelului relaţional prin normalizare utilizând matricea dependenţelor funcţionale Demersul metodologic de proiectare a unui model relaţional prin normalizare utilizând matricea dependenţelor funcţionale sau graful dependenţelor presupune parcurgerea următoarelor etape: 1. Inventarierea atributelor. Într-un dicţionar al datelor se vor prelua toate atributele care fac obiectul problemei de rezolvat, din documentele primare şi situaţiile de ieşire.

9 2. Specificarea regulilor de gestiune diverse restricţii/condiţii impuse datelor. La nivelul acestei etape, algoritmii de calcul sunt asociaţi şi ei regulilor de gestiune. 3. Întocmirea dicţionarului de date de către proiectantul bazei de date care va urmări respectarea următoarelor reguli: atributele sunt înscrise o singură dată; sunt eliminate atributele sinonime; sunt eliminate atributele calculate. 4. Stabilirea cheilor primare. 5. Stabilirea dependenţelor funcţionale ce pot fi descrise printr-un graf al dependenţelor sau în cadrul unei matrice a dependenţelor funcţionale. 6. Pentru atributele izolate se vor căuta grupuri de atribute ce pot constitui determinanţi 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 relaţional. EXEMPLU: O societate comercială doreşte să-şi informatizeze activitatea de aprovizionare cu mărfuri de la furnizori. Furnizorii societăţii, se identifică printr-un cod unic, nume, localitate, telefon şi cont bancar. Aprovizionarea cu mărfuri se realizează în baza facturilor primite de la furnizori, fiecare Factură identificându-se printr-un număr unic, dată factură, data scadenţei, codul, denumirea, contul bancar al furnizorului, codul, denumirea şi contul clientului, codul, denumirea, unitatea de măsură, cantitatea şi preţul mărfurilor facturate, valoarea acestora, valoare TVA şi valoarea totală a facturii. Pentru fiecare zi de întârziere (faţă de data scadenţei) a plăţii facturii, furnizorii percep o penalizare de 1% din valoarea totală a facturii. Nomenclatorul mărfurilor include referinţe la codul de marfă, denumire marfă, unitatea de măsură şi calitate. Nomenclatorul va conţine maxim 100 de mărfuri distincte ale căror unităţi de măsură sunt exprimate în kg, buc, litri. Plata facturii se realizează printr-o Chitanţă, conform facturii emise, în care se precizează numărul chitanţei, data chitanţei, suma plătită, denumirea şi contul emitentului, denumirea şi contul beneficiarului (furnizorului). Societatea plăteşte cu un astfel de document o singură factură. Se cere să se proiecteze baza de date relaţională prin normalizare utilizând matricea dependenţelor funcţionale. În acest scop s-au parcurs paşii următori (descrişi în cadrul metodologic de proiectare a modelului relaţional prin normalizare): 1. Inventarierea atributelor. Pe baza informaţiilor referitoare la activitatea de aprovizionare cu mărfuri de la furnizori, se poate întocmi dicţionarul de atribute:

10 Nr. Crt. Atribut Semnificaţie 1. CodFz Cod Furnizor 2. CodBenef Cod Beneficiar 3. NumeFz Nume Furnizor 4. Localitate Localitate Furnizor 5. Telefon Telefon Furnizor 6. ContBancar Cont Bancar Furnizor 7. NrFact Număr Factură 8. DataFact Data Facturii 9. DataScad Data Scadenţă Factură 10. CantitateFact Cantitate Facturată 11. PretFact Pret Facturare 12. CotaTVA Cota TVA 13 Valoaremarfa Valoare Marfă Facturată 14. TVA Valoare TVA 15. ValoareFactura Valore Totală Factură 16. CodMarfa Cod Marfă 17. DenMarfa Denumire Marfă 18. UM Unitate de Măsură 19. Calitate Calitate Marfă 20. Nrchit Număr Chitanţă 21. DataChit Data Chitanţă 22. SumaPl Suma Plătită 23. TotalSumePl Sume Totale Plătite 24. Penalizare Penalizare Factură 25 Nr_zile-intarz Nr. Zile de Întârziere 2. Specificarea regulilor de gestiune: O factură este emisă de un singur furnizor. O factură poate conţine mai multe mărfuri, iar o marfă se poate regăsi pe mai multe facturi.

11 O factură poate fi plătită eşalonat. 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 dicţionarului de date, se va realiza pe baza următoarelor reguli: fiecare atribut este înscris o singură dată; sunt eliminate atributele sinonime (în exemplul prezentat, CodFz şi CodBenef sunt sinonime, deci se va reţine doar unul dintre acestea CodFz); nu sunt preluate atributele calculate (Valoare_Marfa, TVA, ValoareFactura, Nr_zile_întarz, Penalizare, Totalsumepl). Dicţionarul 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 dependenţelor funcţionale. a. Graful dependenţelor funcţionale simple: b. Graful dependenţelor funcţionale multiple: Nrfact CodFz CodMarfa NrFact NrFact NrChit NrFact CodMarfa

12 6. Atributele izolate: CantitateFact, PretFact şi CotaTVA vor fi determinate de un grup de atribute aşa cum sunt reprezentate mai jos. Ne punem întrebarea De ce Nrfact nu determină funcţional, spre exemplu, Cantitatefact?. În mod practic, o factură poate conţine mai multe mărfuri achiziţionate ş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 cantitaţile, preţurile, CotaTva a mărfurilor facturate. Atributul compus (Nrfact, CodMarfa) reprezintă o cheie primară care se va adăuga cheilor identificate în etapa precedentă. Dependenţele funcţionale identificate anterior se vor reprezenta într-o Matrice a dependenţelor funcţionale (reprezentată într-o formă simplificată, fără a include dependenţele funcţionale multiple şi dependenţele funcţionale multiple tranzitive, în figura 2.2). Liniile şi coloanele acestei matrici sunt reprezentate de atributele din dicţionarul de date şi atributele 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 dependenţe funcţionale identificate astfel: 1- dependenţele funcţionale simple 1 T - dependenţele funcţionale simple tranzitive

13 Figura 2. 2 Matricea dependenţelor funcţionale 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 relaţional). 9. Definitivarea modelului relaţional. 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)

GRAFURI NEORIENTATE. 1. Notiunea de graf neorientat

GRAFURI NEORIENTATE. 1. Notiunea de graf neorientat GRAFURI NEORIENTATE 1. Notiunea de graf neorientat Se numeşte graf neorientat o pereche ordonată de multimi notată G=(V, M) unde: V : este o multime finită şi nevidă, ale cărei elemente se numesc noduri