CURSUL 3- Proiectarea BD relationale Normalizarea relaiilor E. F.

Codd, a artat c ntr-o anumit form relaiile posed proprieti nedorite, pe care le-a numit anomalii de actualizare:

Anomalia de tergere const n faptul c anumite date care urmeaz s fie terse, fac parte din tupluri n care se gsesc i alte date care mai sunt necesare n continuare, ori tergerea fcndu-se la nivelul tuplului, acestea se pierd. Anomalia de adugare const n faptul c anumite date care urmeaz s fie adugate fac parte din tupluri incomplete (pentru care nu se cunosc toate datele), ceea ce face ca acestea s nu poat fi adugate. Anomalia de modificare rezult din faptul c este dificil de modificat o valoare a unui atribut atunci cnd ea apare n mai multe tupluri ale relaiei.

Pentru a nltura aceste anomalii, Codd a stabilit trei forme normale pentru relaii i a introdus procesul de normalizare care se bazeaz pe noiunea de dependen funcional (FD) ca relaie ntre atributele unei entiti ce are un caracter invariant. Fie date dou atribute D i E i notm domeniul valorilor lui D cu DOM (D) i domeniul valorilor lui E cu DOM (E) i o funcie f: DOM (D) DOM (E). Spunem c f este o dependen funcional, dac pentru () d DOM (D) distinct i corespunde o singur valoare e DOM (E). Atributul D se numete determinantul dependenei, iar dependena se simbolizeaz D E. Dependena funcional poate fi generalizat pe mai multe atribute: f: A1, A2, , An B1, B2, , Bm unde A1, A2, , An se numete partea stng iar B1, B2, , Bm se numete partea dreapt a FDului. O dependen funcional f: DOM (D) DOM (E) este elementar (complet), dac nu exist o alt dependen f: DOM (D) DOM (E), unde DOM (D) DOM (D) sau, altfel spus, dac partea stng nu mai poate fi descompus astfel nct rezultatul obinut s fie tot o dependen funcional. Dac f: D1, D2,, Dm, Dm + 1, , Dn E i g: D1, D2,, Dm E sunt dou FD-uri, unde m < n, atunci atributele Dm + 1, , Dn se numesc atribute superflue pentru f, deoarece atributele D1, D2,, Dm sunt suficiente pentru a-l determina funcional pe E. n aceast situaie spunem c E este dependent parial de D1, D2,, Dn. Fie R [A1, A2,, An] o relaie i K o submulime a mulimii de atribute (K {A1, A2,, An}). Spunem c submulimea K este cheie primar pentru relaia R dac sunt ndeplinite urmtoarele condiii:

() Ai K, Ai este dependent funcional pe K; () K K, Ai nu este dependent funcional pe K.

Armstrong a introdus un set de axiome i reguli de inferen, care permit prelucrarea dependenelor funcionale. Notnd cu M mulimea atributelor relaiei R, axiomele lui Armstrong sunt: A1. Reflexivitatea: dac A B M A B;

BD Cursul 3 NP

1/7

A2. Creterea: dac A B i X M AX BX; A3. Tranzitivitatea: dac A B i B C A C. Din cele trei axiome rezult urmtoarele reguli de inferen: R1. Reuniunea: dac A B i A C A BC; R2. Pseudotranzitivitatea: dac A B i XB C AX C; R3. Descompunerea: dac A BC A B i A C.
a) U P# X Q B# C L T U buc Kg m buc buc X 20 10 5 25 30 U P# X R2 P# P1 P1 P1 P1 P2 P2 P2 P3 P3 P4 P5 P# Q B# c) R31 B# B1 B2 B3 B4 B5 B# L Braov Alba Arad Braov Arad L R32 L Braov Alba Arad C 400 500 550 T 0268 0258 0257 C L T Figura 1 Normalizarea relatiilor BD Cursul 3 NP 2/7 B# B1 B2 B3 B4 B5 B2 B3 B1 B4 B5 B2 P# P1 P1 P1 P1 P2 P2 P2 P3 P3 P4 P5 U buc buc buc buc Kg Kg Kg m m buc buc X 20 20 20 20 10 10 10 5 5 25 30 Q 100 200 50 10 250 120 60 100 50 6 10 Q 100 200 50 10 250 120 60 100 50 6 10 B# B1 B2 B3 B4 B5 B2 B3 B1 B4 B5 B2 R3 B# B1 B2 B3 B4 B5 L Braov Alba Arad Braov Arad Alba Arad Braov Braov Arad Alba L Braov Alba Arad Braov Arad C 400 500 550 400 550 T 0268 0258 0257 0268 0257 C B# L T C 400 500 550 400 550 500 550 400 400 550 500 T 0268 0258 0257 0268 0257 0258 0257 0268 0268 0257 0258

b) R1 P# P1 P2 P3 P4 P5

O relaie este n forma normal 1 (1NF), dac i numai dac toate atributele ei conin numai valori atomice (fig. 1.a.). Cheia primar a relaiei R este compus din P# i B#, iar atributele U, X, C, L i T nu sunt complet dependente funcional de aceasta. De asemenea perechile de atribute (L, C) i (L, T) sunt mutual dependente. Aceast relaie posed anomaliile de actualizare prezentate mai nainte, de exemplu:

nu putem aduga un rnd pentru care nu cunoatem beneficiarul (B#) i localitatea (L), deoarece conform regulii de integritate a entitii nici o component a cheii primare (P#, B#) nu poate fi nul; dac produsul P5 nu mai poate fi fabricat temporar, deci trebuie ters rindul(P5, buc, 30, 10, B2, Alba, 500, 0258), nseamn c se pierd i informaiile despre beneficiarul B2, care mai sunt necesare n continuare; dac dup o perioad de timp intervine o schimbare a preurilor produselor, modificarea acestora se face greu datorit faptului c acelai pre intervine n mai multe rnduri din tabel (redundan mare).

Pentru a nltura anomaliile de actualizare, utiliznd operatorul de proiecie, descompunem relaia R n trei relaii R1, R2 i R3 (fig. 1.b.) care sunt n forma normal 2 (2NF) i care conserv datele din relaia R. O relaie este n forma normal 2 (2NF) dac i numai dac este n 1NF i orice atribut noncheie este complet dependent funcional de cheia primar. Analiznd diagrama dependenelor funcionale asociat relaiei R3 din fig. 1. b, observm existena dependenelor tranzitive B# L, L C i B# L, L T care genereaz i ele anomalii de actualizare, cum sunt:

dac tergem tuplul referitor la beneficiarul B1 (B1, Braov, 400, 0268) se pierd i datele referitoare la localitatea, codul potal i prefixul telefonic, care mai sunt necesare; modificarea codului potal (C) se face greu, datorit faptului c aceiai valoare apare n mai multe tupluri (redundan mare); nu putem aduga o nou localitate dac nu exist cel puin un beneficiar din localitatea respectiv.

Pentru a nltura aceste anomalii, descompunem relaia R3 n dou relaii R31 i R32 (fig. 1.c.) care sunt n forma normal 3NF. O relaie este n forma normal 3 ( 3NF ) dac i numai dac este n 2NF i fiecare atribut noncheie nu este dependent tranzitiv pe cheia primar. Relaiile R1, R2, R31 , R32 sunt n forma normal 3. Avantajele modelului relaional Fcnd o analiz a modelelor nerelaionale comparativ cu modelul relaional rezult urmtoarele avantaje n favoarea celui din urm:

BD Cursul 3 NP

3/7

modelul relaional este un model simplu care permite utilizatorului s vad baza de date ca o colecie de tabele (relaii) - o reprezentare mental larg accesibil att informaticienilor ct i neinformaticienilor; asigur independena fizic i logic a programelor de prelucrare fa de structura datelor, eliminnd din schema conceptual i schemele externe toate detaliile privind structura de memorare i strategiile de acces; operaia de normalizare introdus de modelul relaional asigur gsirea structurii optime a datelor prin nlturarea anomaliilor de actualizare i diminuare a redundanei. Prin introducerea conceptului de dependen funcional modelul relaional depete stadiul limitat al reprezentrii datelor n calculator, avansnd spre formalizarea elementelor de semantic ce guverneaz domeniul informaiilor; este un model omogen, deoarece reprezint legturile i asocierile dintre relaii tot prin relaii, spre deosebire de modelele ierarhic i reea care utilizeaz n acelai scop conexiunea i respectiv setul. suplee n comunicare cu utilizatorul neinformatician prin intermediul unor limbaje neprocedurale de nivel nalt.

n funcie de complexitatea bazei de date, exist doua metode de proiectare a modelului relaional:

Conceperea modelului relaional pe baza unui model conceptual semantic (Entitate-Asociere). Modelul entitate-asociere permite modelarea realitii prin intermediul unor concepte abstracte: entiti, asocieri i atribute. Aceasta este metoda cea mai utilizat n practic, mai ales n cazul unor baze de date complexe. Obinerea modelului relaional prin procesul de normalizare, care presupune aplicarea formelor normale asupra unui set de atribute ce formeaz iniial un singur tabel. n urma normalizrii va rezulta un set de tabele normalizate. Aceast metod se poate aplica numai n cazul unor baze de date de dimensiuni mici.

Proiectarea modelului relaional prin normalizzare Metoda se bazeaz pe primele trei forme normale (FN1, FN2, FN3) i presupune parcurgerea urmtoarelor etape: 1. Inventarierea atributelor: Proiectantul va selecta atributele din diverse documente utilizate n circuitul informaional: nomenclatoare (nomenclatorul materialelor, lista furnizorilor etc.), documente primare i centralizatoare (facturi, chitane, situaia aprovizionrilor, balana stocurilor etc.). Exemplu: Numr factur Data factur Cod furnizor Denumire furnizor Adresa

BD Cursul 3 NP

4/7

2. Specificarea regulilor de gestiune: diversele restricii/condiii impuse datelor sunt atent studiate deoarece vor constitui logica dependenelor dintre atribute i a regulilor de validare. Exemplu: - o factur este emis de un singur furnizor; - codul materialului este unic; - o factur conine mai multe materiale ; - furnizorii pot fi numai persoane juridice etc. Algoritmii de calcul sunt asimilai regulilor de gestiune. 3. Matricea dependeelor funcionale Cod Furnizor Cod Furnizor Denumire Furnizor Adresa Furnizor Numr Factur Data Factur Denumire Furnizor 1 1 1 1 1 1T 1T 1 Adresa Furnizor 1 1 Numr Factur Data Factur

n acest caz, dependenele funcionale dintre atribute sunt reprezentate prin valoarea 1 pe linie iar cele tranzitive au fost marcate cu 1T. Dependenele dintre aceleai atribute pot fi reprezentate i prin intermediul unui graf:
Denumire Furnizor Cod Furnizor Adresa Furnizor

Numr Factur
Graful dependeelor funcionale

Data Factur

n aceast variant, dependenele funcionale sunt reprezentate prin sgei iar cele tranzitive prin sgei punctate.

BD Cursul 3 NP

5/7

4. Pentru atributele rmase izolate se vor cuta grupuri de cmpuri ce pot constitui determinani ai acestora. Toate atributele (grupuri de atribute) determinante devine chei candidate. Cheile candidate ce vor aparine aceluiai tabel sunt caracterizate prin dependene funcionale reciproce (CodFurnizor<>DenumireFunizor, CodFurnizor<->Adresa) 5. Se stabilesc cheile primare dintre atributele candidate. Exemplu: CodFurnizor, NumrFactur 6. Cu fiecare cheie primar i atributele determinate direct (netranzitiv) de aceasta se va forma o relative(un tabel). Exemplu: Furnizor(CodFurnizor, DenumireFurnizor, AdresaFurnizor) Factur(NumrFactur, Data, CodFurnizor) 7. Se stabilesc cheile externe (cmpuri ce sunt chei primare n alte tabele) Exemplu: Furnizor(CodFurnizor, DenumireFurnizor, AdresaFurnizor) Factur(NumrFactur, Data, CodFurnizor) Exemplu Se dorete realizarea unei baze de date pentru gestiunea comenzilor primite de la clieni. Firma dispune de un catalog de produse n care sunt menionate codul, denumirea i unitatea de msur . Clienii firmei sunt persoane fizice despre care se cunosc: codul clientului, numele, localitatea, adresa, i numrul de telefon la care se pot cere detalii suplimentare. Comenzile primite sunt numerotate i datate consemnndu-se termenul de livrare exprimat n zile. Pe unele comenzi se poate specifica i un procent de discount ce se aplic la valoarea total a comenzii. Pentru fiecare produs solicitat pe comand se va preciza preul unitar i cantitatea comandat calculnd valoarea produsului. n final se consemneaz valoarea total, valoarea discountului i suma de plat. Reguli de gestiune: 1. Un client poate efectua oricte comenzi dar o comand aparine unui singur client 2. Pe o comand pot figura oricte produse 3. Preurile produselor sunt variabile n timp i negociabile cu clienii 4. Procentele de discount acordate sunt variabile Valoarea produsului I = Cantitate I * Pret unitar I ValoareTotal = Cantitatei * Preti Valoare Discount = ValoareTotala x ProcentDiscount SumaDePlat = ValoareTotal ValoareDiscount

BD Cursul 3 NP

6/7

Matricea dependenelor funcionale(nu sunt luate n considerare atributele calculate) Denumire atr 1.CodProdus 2. Denumire 3. Um 4. CodClient 5. NumeC 6. Localitate 7. Adresa 8. Telefon 9. NrCom 10. Data C 11. Termen 12. Discount 13. Pret U 14 Cant 15 1+ 9 1 2 1 3 1 4 5 6 7 8 9 10 11 12 13 14 15

1T

1T

1T 1T

Observaii: 1. n momentul crerii tabelelor se ine cont de faptul c atributele NumeC, Localitate, Adresa i Telefon sunt determinate tranzitiv de ctre NrFactur prin intermediul Codului de client (au fost marcate cu 1T). 2. ntruct pentru atributele Pret U i Cant nu s-a gsit nici un determinant s-a recurs la un determinant compus format din CodProdus i NrComand Modelul relaional rezultat este urmtorul: Produse(CodProdus, DenumireProdus, UM) Clienti (CodClient, Nume, Localitate, Adresa, Telefon) Comenzi(NrComanda, DataComanda, Termen, Discount, CodClient) ContinutComenzi(CodProdus, NrComanda, Cantitate, PretUnitar)

BD Cursul 3 NP

7/7