1

CURSURILE 2-3
NORMALIZAREA BAZELOR DE DATE

Normalizarea BAZELOR DE DATE

Obiectivul central al normalizrii l reprezint conceperea

bazelor de date. O baz de date normalizat trebuie s conin tabele (relaii) n care s nu existe anomalii sau pierderi de informaii si s respecte att restriciile modelului relaional ct i cerinele definite de ctre utilizator. DE CE NORMALIZARE? PENTRU A EVITA EXISTENA UNEI SINGURE RELAII SUPRADIMENSIONATE PENTRU C DESCOMPUNEREA N RELAII DIMENSIONATE OPTIM ASIGUR OMOGENITATEA SEMANTIC LIMITEAZ DUPLICAREA INFORMAIILOR N TABELE I ELIMIN POTENTIALELE ANOMALII DE ACTUALIZARE !!! Descompunerea eronat conduce la PIERDERI DE INFORMAII I RECOMPUNERI ERONATE.

EXEMPLU DE DESCOMPUNERE ERONAT

Masina Numar 12 B113 13 B666 Model r4 2cv

Maini

Numr 12 B113 13 B666 11B999 13B777

Culoare alb verde negru alb

Model r4 2cv r4 ds

Marca Renault Citroen Renault Citroen

Nu rezult aceeai relaie!!!!

Masini numar 12 B113 12 B113 Culoare alb negru verde alb Model r4 r4 2cv r4 marca Renault Renault Citroen Renault

11B999
13B777 Constructor Model r4 2cv r4 ds Marca Renault Citroen Renault Citroen

r4
ds Culoare alb verde negru alb 11B999 13B666

COMPUNERE natural dac pe campul Model

11B999
13B777

negru
alb

r4
ds

Renault
Citroen

Maini

Numr 12 B113

Culoare alb verde negru alb

Model r4 2cv r4 ds

Marca Renault Citroen Renault Citroen

VEHICUL

Numr 12 B113 13 B666 11B999 13B777

Culoare alb verde negru alb

Model r4 2cv r4 ds
Marca
Renault Citroen Citroen

13 B666 11B999 13B777

Descompunere corect

Constructor

Model
r4 2cv ds

Prin recompunere rezult aceeai relaie!!!

Maini Numr 12 B113 13 B666 11B999 13B777 Culoare alb verde negru alb Model r4 2cv r4 ds Marca Renault Citroen Renault Citroen

COMPUNERE natural dac pe campul Model sunt valori egale

5
Serie factur Numar factura 1
2 3

Data factur

Cod furnizor

Denumire furnizor

Adres furnizor

A01
A02 A03

01/01/2008
12/05/2008 15/05/2008 Tabela Furnizori-Facturi

111
112 112

S.C. Alfa S.A.

S.C. Beta S.A. S.C. Beta S.A.

Bucureti
Braov Braov

Tabela Furnizori-Facturi prezint urmtoarele anomalii: Redundan pentru facturile emise de acelai furnizor; Anomalii la adugare: se refer la faptul c anumite date ce urmeaz a fi adugate, fac parte din tupluri incomplete (ex: nu pot fi adugai furnizori care nu au emis facturi) Anomalii la modificare: se refer la faptul c e dificil s se modifice o realizare, dac ea se repet n mai multe tupluri. Dac un furnizor i schimb denumirea, atunci, ea trebuie modificat n toate nregistrrile aferente facturilor emise de acel furnizor; Anomalii la tergere: constau n faptul c anumite informaii ce se doresc a fi terse, fac parte dintr-un tuplu ce conine i alte date care sunt utile n continuare. De exemplu, tergerea unei facturi din tabela Furnizori-Facturi, conduce la eliminarea din baza de date a furnizorului emitent.

Eliminarea acestor anomalii se poate realiza prin descompunerea relaiei n mai multe tabele, legate ntre ele prin restricia integritii refereniale. 2.2. Conceptul de dependene
Dependenele sunt legturi logice, ce se stabilesc ntre

atributele modelului relaional. Dependene funcionale ntre dou atribute A i B exist o dependen funcional dac fiecrei valori a lui A i corespunde o singur valoare a lui B (simbolizat AB).

CodFurnizor DenumireFurnizor CodMaterial DenumireMaterial

Unei realizri a cmpului CodFurnizor i corespunde o singur realizare a cmpului DenumireFurnizor. De asemenea, unei realizri a cmpului CodMaterial, i corespunde o singur realizare a cmpului
DenumireMaterial

Se numete dependen funcional complet, o

dependen funcional de forma A B n care B este dependent funcional de A, fr s fie dependent functional de nici una din componentele lui A.

De exemplu, ntre grupul de cmpuri (NrFactura,

CodProdus) i Cantitate exist o dependen funcional complet, deoarece cmpul Cantitate depinde funcional de ambele atribute ale grupului (NrFactur, CodProdus) fr s depind funcional numai de NrFactur sau de CodProdus. (NrFactur, CodProdus) Cantitate NRFactur Cantitate CodProdus Cantitate

 Dependene multivaloare

Exist o dependen multivaloare

ntre X i Y (XY) dac i numai dac pentru fiecare valoare a lui X pot fi asociate una sau mai multe valori a lui Y; Dependentele multivaloare presupun intotdeauna existenta a trei atribute.

 De exemplu, n relaia R1{CodSectie,

10

NumarInventarMijlocFix, MarcaAngajat}exist dependene multivaloare (ntr-o secie lucreaz mai muli muncitori, la mai multe mijloace fixe). Dac fiecare muncitor lucreaz la toate mijlocele fixe, atunci exist urmtoarele dependene multivaloare: CodSectieNumarInventarMijlocFix CodSectieMarcaAngajat

11 O dependenta tranzitiva poate fi stabilita pe baza dependentelor functionale dintre 3 atribute :A,B,C.

AB B C.

A----- > C

Dependena multipl: exist o dependen multipl de la A la B (A B) atunci cnd o realizare a lui A determin mai multe realizri ale lui B; Exemple: NrFactur CodProdus; DataFactur NrFactur Trebuie observat faptul, c dac ntre dou atribute A i B exist o dependen multivaloare (A B), atunci ntre A i B exist i o dependen multipl (A B). Dac ntre A i B exist o dependen multipl, asta nu nseamn c ntre cele dou atribute exist i o dependen multivaloare, deoarece n cazul dependenelor multivaloare sunt necesare trei atribute.

12

Formele normale
Formele normale sunt reguli, restricii care trebuie respectate pentru eliminarea

anomaliilor ce pot aprea n cadrul relaiilor unui modelul relaional.

O relaie este n forma normal 1 (FN1), dac i numai dac toate

atributele ei conin numai valori atomice (elementare sau indivizibile)

FN1 exclude apariia atributelor sau grupurilor de atribute repetitive n cadrul unei relaii. De exemplu, relaia Comenzi{Numr, Data, Material1, Material2} nu respect FN1, deoarece conine atribute repetitive.

13

Relatia PERSOANA
Cod Denumire Domiciliu

01
02

Ionescu
Popescu

Bucuresti, str. Stefan cel Mare,nr.2

Ploiesti, str. Viitorului, nr.4

Relatia Comanda
Numarcomanda 11 12 Data 01/01/2008 02/01/2008 Material1 Ciment Ciment Var Material2

13

02/01/2008

Var

Nisip

Relatiile Persoana, respectiv Comanda nu respecta FORMA NORMALA 1.

14

Pentru aducerea relaiilor n FN1, se parcurg urmtoarele etape: Atributele compuse sunt nlocuite cu atribute elementare; Pentru grupul de atribute repetitive, se formeaz o alt relaie; Cheia primar a noii relaii va fi compus din cheia primar a primei relaii i alte atribute adiionale din noua relaie. Cheia primar din prima relaie, va fi n noua relaie, cheie extern.

innd cont de aceste reguli, relaiile prezentate mai sus vor fi aduse n FN1 astfel: n relaia Persoan, atributul Domiciliu se descompune n atributele Localitate i Adres: Persoan{Cod, Denumire, Localitate, Adres} relaia Comenzi se descompune n relaiile Comand i MaterialeComandate : Comand{Numrcomanda, Dat} i MaterialeComandate{Numrcomanda, denumireMaterial}

15 Forma normal 2 (FN2) O relaie se afl in FN2 dac respect FN1 i dac orice atribut noncheie se afl n dependen funcional complet fa de cheia primar a relaiei. FN2 interzice existena dependenelor funcionale pariale ntre atributele cu rol de cheie primar i celelalte atribute. EX:Relaia PieseComandate{NumrComand, CodPies, Cantitate, PreUnitar, DenumirePies} nu se afl n FN2 pentru c ntre (NumrComand, CodPies) i DenumirePies exist o dependen parial: (NumrComand, CodPies) DenumirePies CodPies DenumirePies

OBS:Atribut noncheie este un atribut care nu intr n componena cheii primare

16
NumrComand 1 1 2 CodPies 01 02 01 Cantitate 100 150 200 PretUnitar 20 25 20 DenumirePies Saiba Rotor Saiba

Relaia MaterialeComandate Relaia MaterialeComandate prezint urmtoarele anomalii: Redundan pentru cmpurile care depind parial de cheia primar. Realizrile cmpului DenumirePies, se repet inutil. Anomalii la adugare: nu se pot aduga piese dac nu s-au fcut comenzi pentru acestea; Anomalii la modificare: dac se modific denumirea unei piese, atunci trebuie modificate toate nregistrrile care conin denumirea piesei respective; Anomalii la tergere: tergerea unei comenzi poate conduce la tergerea definitiv a unor piese.

17

Pentru aducerea relaiilor din FN1 n FN2, se parcurg urmtoarele etape: Se identific eventualele dependene funcionale pariale; Fiecare dependen funcional parial va genera cte o relaie nou. O relaie nou format va avea ca structur atributele participante n dependena funcional parial; Atributele determinante devin chei externe n relaiile iniiale i chei primare n relaiile nou formate.

 Parcurgnd aceste etape, relaia

18

PieseComandate{NumrComand, CodPies, Cantitate, PreUnitar, DenumirePies} se va descompune n urmtoarele relaii: PieseComandate{NumrComand, CodPies, Cantitate, PreUnitar} i Piese{CodPies, DenumirePies} Forma normal 3 (FN3)

O relaie verific FN3 dac se afl n FN2 i

dac toate atributele noncheie sunt dependente funcional netranzitiv de cheia primar a relaiei ( toate atributele care nu aparin cheii primare s nu depind funcional de un alt atribut sau ansamblu de atribute noncheie).

19

De exemplu, relaia Comand{NumrComand, Data,

CodClient, DenumireClient} nu respect FN3, pentru c ntre NumrComand i DenumireClient exist o dependen funcional tranzitiv: NumrComand CodClient DenumireClient NumrComand -------DenumireClient

Pentru aducerea unei relaii din FN2 n FN3, se parcurg urmtoarele etape: Se identific eventualele dependene funcionale tranzitive; Determinantul noncheie mpreun cu atributul sau atributele determinate funcional de ctre acesta, vor forma o nou relaie; Determinantul noncheie devine cheie primar n relaia nou format i cheie extern n relaia iniial.

20

Parcurgnd aceste etape, relaia iniial

Comand{NumrComand, Data, CodClient, DenumireClient}, se va descompune n urmtoarele relaii: Comand{NumrComand, Data, CodClient} i Client{CodClient, DenumireClient}

Forma normal Boyce-Codd (BCNF) Relaiile din baza de date trebuie proiectate astfel nct s nu aib nici dependene pariale, nici dependene tranzitive, deoarece acestea duc la apariia anomaliilor de actualizare. Formele FN2 i FN3 elimin dependenele pariale i tranzitive pe cheia primar. Forma normal Boyce-Codd se bazeaz pe dependenele funcionale care iau n consideraie toate cheile candidat dintr-o relaie. Pentru o relaie cu o singur cheie candidat, formele FN3 i BCNF sunt echivalente. Forma normal Boyce-Codd: o relaie se afl n BCNF dac i numai dac fiecare determinant este o cheie candidat. Pentru a testa dac o relaie este n BCNF, se identific toi determinanii i se verific dac sunt chei candidat. Amintim c un determinant este un atribut sau un grup de atribute, de care alte atribute sunt total dependente funcional.

21

22

Proiectarea modelului relaional prin normalizare

Proiectarea BD prin procedeul de normalizare presupune obinerea modelului relaionalal BD prin aplicarea formelor normale asupra unui set de atribute ce formeaz iniial un singur tabel. Aceast metod se poate aplica numai n cazul unor baze de date de dimensiuni mici. Conceperea bazelor de date prin normalizare se poate realiza prin: a. descompunerea relaiei universale iniiale n mai multe tabele; b.compunerea unei mulimi de atribute n tabele utiliznd matricea dependenelor c.Compunerea unei multimi de atribute in tabele utiliznd graful dependenelor.

23

Metoda matricii dependenelor funcionale i a grafului DF 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

 2. Specificarea regulilor de gestiune: diversele

24

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. Exemplu: RG5:Valoare_factura=Cantitate*Pret Unitar

25

3. Intocmirea dictionarului de date

Atributele inventariate se trec in dictionarul de date o singura data cu respectarea urmatoarelor reguli: -nu se trec atributele derivate/calculate -nu se trec atributele sinonime (Cod material, Simbol material) -nu se trec grupurile de atribute repetitive.

Nr. atribut 1. 2. 3. 4. 5.

Identificator CodFurnizor DenumireFurnizor AdresaFurnizor NrFactura DataFacturii

Explicatie Cod Furnizor Denumirea furnizorului Adresa Furnizorului Numar Factura Data Factura

26

4.Stabilirea dependentelor functionale A.Graful dependentelor functionale

Denumirefurnizor CodFurnizor AdresaFurnizor

Nrfactura

Data facturii

27

B.Matricea dependentelor functionale

Cod furnizor
Cod furnizor Denumire furnizor

Denumire furnizor

Adresa furnizor

Numar factura

Data facturii

1 1

1 1

Adresa furnizor
Numar factura

1
1

1
1T 1T 1

Data facturii

4. Pentru atributele rmase izolate se vor cuta grupuri de cmpuri ce 28 pot constitui determinani ai acestora. Toate atributele (grupuri de atribute) determinante devin 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 relaie (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)

29

Exemplu de proiectare a BD prin descompunerea relaiei universale

Relaia universal este o relaie alctuit din toate atributele identificate,

necesare aplicaiei. Normalizarea presupune descompunerea relaiei universale iniiale n alte relaii, prin trecerea gradual a acesteia prin fiecare form normal. Exemplu: n vederea obinerii unei baze de date necesare evidenei creditelor acordate clienilor, se au n vedere urmtoarele reguli de gestiune: un client poate ncheia mai multe contracte. Un contract e ncheiat de un singur client. rambursarea contractelor de credit, se poate realiza prin dispoziii de plat. O dispoziie de plat se refer la un singur contract de credit, iar pentru un contract, se pot ntocmi mai multe dispoziii de plat.
Se consider iniial, relaia universal R{CodClient, Denumire, Domiciliu,

NrContract, DataContract, ProcentDobanda,ProcentComision, ValoareCredit, NumrDP, DataDP, SumaDP}

30

FN1. Relaia nu respect FN1, deoarece nu toate atributele sunt elementare. Atributul Domiciliu se descompune n atributele Adresa i Localitate (intereseaz pentru aplicaie o grupare/selectare a informaiilor dup localiti). Astfel, relaia universal devine:
R{CodClient, Denumire, Localitate, Adres, NrContract, DataContract, ProcentDobanda,ProcentComision, ValoareCredit, NumrDP, DataDP, SumaDP} Se observ ca n relaia R, exist anomalii la actualizare. Acestea vor fi eliminate n urmtoarele forme normale. FN2: Relaia R respect FN2

31

FN3: Relaia R nu respect FN3. Exist urmtoarele

dependene funcionale tranzitive: (1)NumarDP CodClient Denumire (2)NumarDP CodClient Localitate (3)NumarDP CodClient Adresa (4)NumarDP NrContract DataContract (5)NumarDP NrContract ProcentComision (6)NumarDP NrContract ProcentDobanda (7)NumarDP NrContract ValoareCredit (8)NumarDP NrContract CodClient Vor rezulta urmtoarele relaii: Clieni(Codclient, Denumire, localitate, Adresa) Contract(NrContract,DataContract,ProcentComision,Proc entDobanda,ValoareCredit, Codclient)

32

Contract{NrContract,DataContract,ProcentDobanda, ProcentComision, ValoareContract, CodClient} i ce a mai rmas din relaia R: DispoziieDePlata{NumarDP, DataDP, SumaDP, CodClient, NumarContract} Datorit dependenei (8), cheia extern CodClient va fi eliminat (este o cheie extern derivat/tranzitiv), iar relaia va deveni: DispoziieDePlata{NumarDP,DataDP,SumaDP, NumarContract} FNBC: relaiile obinute n FN3, verific FNBC. Toi determinanii dependenelor sunt chei candidate.