curs 2-3 Fabbv

CURSURILE 2-3

NORMALIZAREA BAZELOR DE DATE

1

Normalizarea BAZELOR DE DATE • Obiectivul central al normalizării îl reprezintă conceperea

bazelor de date optimizate. O bază de date normalizată trebuie să conţină tabele (relaţii) în care să nu existe anomalii sau pierderi de informaţii si să respecte atât restricţiile modelului relaţional cât şi cerinţele definite de către utilizator.

• DE CE NORMALIZARE?• …PENTRU A EVITA EXISTENŢA UNEI SINGURE RELAŢII

SUPRADIMENSIONATE• …PENTRU CĂ DESCOMPUNEREA ÎN RELAŢII

DIMENSIONATE OPTIM ASIGURĂ OMOGENITATEA SEMANTICĂ

• …LIMITEAZĂ DUPLICAREA INFORMAŢIILOR ÎN TABELE ŞI ELIMINĂ POTENTIALELE ANOMALII DE ACTUALIZARE

!!! Descompunerea eronată conduce la PIERDERI DE INFORMAŢII ŞI RECOMPUNERI ERONATE.

2

3

EXEMPLU DE DESCOMPUNEREERONATĂ

COMPUNERE naturală dacă pe campul Model sunt valori egale

Maşini Număr Culoare Model Marca

12 B113 alb r4 Renault

13 B666 verde 2cv Citroen

11B999 negru r4 Renault

13B777 alb ds CitroenMasina Numar Model

12 B113 r4

13 B666 2cv

11B999 r4

13B777 ds

Constructor Model Marca Culoare

r4 Renault alb

2cv Citroen verde

r4 Renault negru

ds Citroen alb

Masini numar Culoare Model marca

12 B113 alb r4 Renault

12 B113 negru r4 Renault

13B666 verde 2cv Citroen

11B999 alb r4 Renault

11B999 negru r4 Renault

13B777 alb ds Citroen

Nu rezultă aceeaşi relaţie!!!!

4

Maşini Număr Culoare Model Marca

12 B113 alb r4 Renault

13 B666 verde 2cv Citroen

11B999 negru r4 Renault

13B777 alb ds Citroen

VEHICUL Număr Culoare Model

12 B113 alb r4

13 B666 verde 2cv

11B999 negru r4

13B777 alb ds

Constructor Model Marca

r4 Renault

2cv Citroen

ds Citroen

COMPUNERE naturală dacă pe campul Model sunt valori egale

Descompunere corectă

Maşini Număr Culoare Model Marca

12 B113 alb r4 Renault

13 B666 verde 2cv Citroen

11B999 negru r4 Renault

13B777 alb ds Citroen

Prin recompunere rezultă aceeaşi relaţie!!!

Serie factură Numar factura

Data factură Cod furnizor Denumire furnizor Adresă furnizor

A01 1 01/01/2008 111 S.C. Alfa S.A. Bucureşti

A02 2 12/05/2008 112 S.C. Beta S.A. Braşov

A03 3 15/05/2008 112 S.C. Beta S.A. Braşov

5

Tabela Furnizori-Facturi

Tabela Furnizori-Facturi prezintă următoarele anomalii:Redundanţă pentru facturile emise de acelaşi furnizor;Anomalii la adăugare: se referă la faptul că anumite date ce urmează a fi adăugate, fac parte din tupluri incomplete (ex: nu pot fi adăugaţi 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 înregistrările aferente facturilor emise de acel furnizor;Anomalii la ştergere: constau în faptul că anumite informaţii ce se doresc a fi şterse, fac parte dintr-un tuplu ce conţine ş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 relaţiei în mai multe tabele, legate între ele prin restricţia integrităţii referenţiale.

2.2. Conceptul de dependenţe

• Dependenţele sunt legături logice, ce se stabilesc între atributele modelului relaţional.

Dependenţe funcţionale• Între două atribute A şi B există o dependenţă funcţională dacă fiecărei valori a lui A îi corespunde o singură valoare a lui B (simbolizată A→B).

6

• CodFurnizor → DenumireFurnizor• CodMaterial → DenumireMaterial

Unei realizări a câmpului CodFurnizor îi corespunde o singură realizare a câmpului DenumireFurnizor. De asemenea, unei realizări a câmpului CodMaterial, îi corespunde o singură realizare a câmpului

DenumireMaterial

• Se numeşte dependenţă funcţională completă, o dependenţă funcţională de forma A→ B în care B este dependent funcţional de A, fără să fie dependent functional de nici una din componentele lui A.

7

• De exemplu, între grupul de câmpuri (NrFactura, CodProdus) şi Cantitate există o dependenţă funcţională completă, deoarece câmpul Cantitate depinde funcţional de ambele atribute ale grupului (NrFactură, CodProdus) fără să depindă funcţional numai de NrFactură sau de CodProdus.

• (NrFactură, CodProdus) → Cantitate• NRFactură → Cantitate • CodProdus → Cantitate

8

• Dependenţe multivaloare

•Există o dependenţă multivaloare între X şi Y (X→→Y) 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.

9

•De exemplu, în relaţia R1{CodSectie, NumarInventarMijlocFix, MarcaAngajat}există dependenţe multivaloare (într-o secţie lucrează mai mulţi muncitori, la mai multe mijloace fixe). Dacă fiecare muncitor lucrează la toate mijlocele fixe, atunci există următoarele dependenţe multivaloare:

•

CodSectie→→NumarInventarMijlocFix• CodSectie→→MarcaAngajat

10

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

11

B → C.

A → B A----- > C

Dependenţa multiplă: există o dependenţă multiplă de la A la B (A »B) atunci când o realizare a lui A determină mai multe realizări 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 dependenţelor multivaloare sunt necesare trei atribute.

Formele normale • Formele normale sunt reguli, restricţii care trebuie respectate pentru eliminarea

anomaliilor ce pot apărea în cadrul relaţiilor unui modelul relaţional.

• O relaţie este în forma normală 1 (FN1), dacă şi numai dacă toate atributele ei conţin numai valori atomice (elementare sau indivizibile)

12

FN1 exclude apariţia atributelor sau grupurilor de atribute repetitive în cadrul unei relaţii.

De exemplu, relaţia Comenzi{Număr, Data, Material1, Material2} nu respectă FN1, deoarece conţine atribute repetitive.

Cod Denumire Domiciliu

01 Ionescu Bucuresti, str. Stefan cel Mare,nr.2

02 Popescu Ploiesti, str. Viitorului, nr.4

Numarcomanda Data Material1 Material2

11 01/01/2008 Ciment Var

12 02/01/2008 Ciment

13 02/01/2008 Var Nisip

13

Relatiile Persoana, respectiv Comanda nu respecta FORMA NORMALA 1.

Relatia PERSOANA

Relatia Comanda

Pentru aducerea relaţiilor în FN1, se parcurg următoarele etape:• Atributele compuse sunt înlocuite cu atribute elementare;• Pentru grupul de atribute repetitive, se formează o altă relaţie;• Cheia primară a noii relaţii va fi compusă din cheia primară a

primei relaţii şi alte atribute adiţionale din noua relaţie. Cheia primară din prima relaţie, va fi în noua relaţie, cheie externă.

Ţinând cont de aceste reguli, relaţiile prezentate mai sus vor fi aduse în FN1 astfel:

• în relaţia Persoană, atributul Domiciliu se descompune în atributele Localitate şi Adresă:

Persoană{Cod, Denumire, Localitate, Adresă}• relaţia Comenzi se descompune în relaţiile Comandă

şi MaterialeComandate :

Comandă{Numărcomanda, Dată} şi MaterialeComandate{Numărcomanda, denumireMaterial}

14

Forma normală 2 (FN2)• O relaţie se află in FN2 dacă respectă FN1 şi dacă orice atribut noncheie se află în dependenţă funcţională completă faţă de cheia primară a relaţiei.

FN2 interzice existenţa dependenţelor funcţionale parţiale între atributele cu rol de cheie primară şi celelalte atribute.

EX:Relaţia PieseComandate{NumărComandă, CodPiesă, Cantitate, PreţUnitar, DenumirePiesă} nu se află în FN2 pentru că între (NumărComandă, CodPiesă) şi DenumirePiesă există o dependenţă parţială:

• (NumărComandă, CodPiesă) → DenumirePiesă• CodPiesă → DenumirePiesăOBS:Atribut noncheie este un atribut care nu intră în componenţa

cheii primare

15

NumărComandă CodPiesă Cantitate PretUnitar DenumirePiesă

1 01 100 20 Saiba

1 02 150 25 Rotor

2 01 200 20 Saiba

16

Relaţia MaterialeComandate prezintă următoarele anomalii:Redundanţă pentru câmpurile care depind parţial de cheia primară. Realizările câmpului DenumirePiesă, se repetă inutil.Anomalii la adăugare: nu se pot adăuga piese dacă nu s-au făcut comenzi pentru acestea;Anomalii la modificare: dacă se modifică denumirea unei piese, atunci trebuie modificate toate înregistrările care conţin denumirea piesei respective;Anomalii la ştergere: ştergerea unei comenzi poate conduce la ştergerea definitivă a unor piese.

Relaţia MaterialeComandate

Pentru aducerea relaţiilor din FN1 în FN2, se parcurg următoarele etape:

• Se identifică eventualele dependenţe funcţionale parţiale;

• Fiecare dependenţă funcţională parţială va genera câte o relaţie nouă. O relaţie nou formată va avea ca structură atributele participante în dependenţa funcţională parţială;

• Atributele determinante devin chei externe în relaţiile iniţiale şi chei primare în relaţiile nou formate.

17

• Parcurgând aceste etape, relaţia PieseComandate{NumărComandă, CodPiesă, Cantitate, PreţUnitar, DenumirePiesă} se va descompune în următoarele relaţii:

PieseComandate{NumărComandă, CodPiesă, Cantitate, PreţUnitar} şi

Piese{CodPiesă, DenumirePiesă}Forma normală 3 (FN3)

• O relaţie verifică FN3 dacă se află în FN2 şi dacă toate atributele noncheie sunt dependente funcţional netranzitiv de cheia primară a relaţiei ( toate atributele care nu aparţin cheii primare să nu depindă funcţional de un alt atribut sau ansamblu de atribute noncheie).

18

• De exemplu, relaţia Comandă{NumărComandă, Data, CodClient, DenumireClient} nu respectă FN3, pentru că între NumărComandă şi DenumireClient există o dependenţă

funcţională tranzitivă:

19

NumărComandă → CodClient→ DenumireClientNumărComandă -------DenumireClient

Pentru aducerea unei relaţii din FN2 în FN3, se parcurg următoarele etape:

Se identifică eventualele dependenţe funcţionale tranzitive;Determinantul noncheie împreună cu atributul sau atributele

determinate funcţional de către acesta, vor forma o nouă relaţie;

Determinantul noncheie devine cheie primară în relaţia nou formată şi cheie externă în relaţia iniţială.

• Parcurgând aceste etape, relaţia iniţială Comandă{NumărComandă, Data, CodClient, DenumireClient}, se va descompune în următoarele relaţii:

Comandă{NumărComandă, Data, CodClient} şi

Client{CodClient, DenumireClient}

20

Forma normală Boyce-Codd (BCNF)• Relaţiile din baza de date trebuie proiectate astfel încât să nu

aibă nici dependenţe parţiale, nici dependenţe tranzitive, deoarece acestea duc la apariţia anomaliilor de actualizare. Formele FN2 şi FN3 elimină dependenţele parţiale şi tranzitive pe cheia primară.

• Forma normală Boyce-Codd se bazează pe dependenţele funcţionale care iau în consideraţie toate cheile candidat dintr-o relaţie.

• Pentru o relaţie cu o singură cheie candidat, formele FN3 şi BCNF sunt echivalente.

• Forma normală Boyce-Codd: o relaţie se află în BCNF dacă şi numai dacă fiecare determinant este o cheie candidat.

• Pentru a testa dacă o relaţie este în BCNF, se identifică toţi determinanţii ş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 funcţional.

21

Proiectarea modelului relaţional prin normalizare

Proiectarea BD prin procedeul de normalizare presupune obţinerea modelului relaţional al BD prin aplicarea formelor normale asupra unui set de atribute ce formează iniţial 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 relaţiei universale iniţiale în mai multe tabele;

b.compunerea unei mulţimi de atribute în tabele utilizând matricea dependenţelor

c.Compunerea unei multimi de atribute in tabele utilizand graful dependenţelor.

22

Metoda matricii dependenţelor funcţionale şi a grafului DF

Etape:

1. Inventarierea atributelor: Proiectantul va selecta atributele din diverse documente utilizate în circuitul informaţional: nomenclatoare (nomenclatorul materialelor, lista furnizorilor etc.), documente primare şi centralizatoare (facturi, chitanţe, situaţia aprovizionărilor, balanţa stocurilor etc.).

Exemplu:• Număr factură• Data factură• Cod furnizor• Denumire furnizor• Adresa

23

• 2. Specificarea regulilor de gestiune: diversele restricţii/condiţii impuse datelor sunt atent studiate deoarece vor constitui logica dependenţelor dintre atribute şi a regulilor de validare.

Exemplu:- o factură este emisă de un singur furnizor;- codul materialului este unic;- o factură conţine mai multe materiale ;- furnizorii pot fi numai persoane juridice etc.• Algoritmii de calcul sunt asimilaţi regulilor de gestiune.Exemplu:RG5:Valoare=Cantitate*Pret Unitar

24

3. Intocmirea dictionarului de dateAtributele 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.

25

Nr. atribut

Identificator Explicatie

1. CodFurnizor Cod Furnizor

2. DenumireFurnizor Denumirea furnizorului

3. AdresaFurnizor Adresa Furnizorului

4. NrFactura Numar Factura

5. DataFacturii Data Factura

4.Graful dependentelor functionale

26

CodFurnizor

Denumirefurnizor

AdresaFurnizor

Nrfactura Data facturii

4.Matricea dependentelor functionale

Cod furnizor Denumire furnizor

Adresa furnizor

Numar factura

Data facturii

Cod

furnizor1 1

Denumire furnizor 1 1

Adresa furnizor 1 1

Numar factura 1 1T 1T 1

Data facturii

27

Pentru atributele rămase izolate se vor căuta grupuri de câmpuri ce pot constitui determinanţi ai acestora.

5.Toate atributele (grupuri de atribute) determinante devin chei candidate. Cheile candidate ce vor aparţine aceluiaşi tabel sunt caracterizate prin dependenţe funcţionale reciproce.

(CodFurnizor<->DenumireFunizor, CodFurnizor<->Adresa)

6. Se stabilesc cheile primare dintre atributele candidate. Exemplu:CodFurnizor,NumărFactură

7. Cu fiecare cheie primară şi atributele determinate direct (netranzitiv) de aceasta se va forma o relaţie (un tabel).

Exemplu:Furnizor(CodFurnizor, DenumireFurnizor, AdresaFurnizor)Factură(NumărFactură, Data, CodFurnizor)

8. Se stabilesc cheile externe (câmpuri ce sunt chei primare în alte tabele)Exemplu:Furnizor(CodFurnizor, DenumireFurnizor, AdresaFurnizor)Factură(NumărFactură, Data, CodFurnizor)

28

Exemplu de proiectare a BD prin descompunerea relaţiei universale• Relaţia universală este o relaţie alcătuită din toate atributele identificate,

necesare aplicaţiei. Normalizarea presupune descompunerea relaţiei universale iniţiale în alte relaţii, prin trecerea graduală a acesteia prin fiecare formă normală.

Exemplu: În vederea obţinerii unei baze de date necesare evidenţei creditelor acordate clienţilor, se au în vedere următoarele 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 dispoziţii de plată. O dispoziţie de plată se referă la un singur contract de credit, iar pentru un contract, se pot întocmi mai multe dispoziţii de plată.

• Se consideră iniţial, relaţia universală R{CodClient, Denumire, Domiciliu, NrContract, DataContract, ProcentDobanda,ProcentComision, ValoareCredit, NumărDP, DataDP, SumaDP}

29

• FN1. Relaţia nu respectă FN1, deoarece nu toate atributele sunt elementare. Atributul Domiciliu se descompune în atributele Adresa şi Localitate (interesează pentru aplicaţie o grupare/selectare a informaţiilor după localităţi). Astfel, relaţia universală devine:

R{CodClient, Denumire, Localitate, Adresă, NrContract, DataContract, ProcentDobanda,ProcentComision, ValoareCredit, NumărDP, DataDP, SumaDP}

Se observă ca în relaţia R, există anomalii la actualizare. Acestea vor fi eliminate în următoarele forme normale.

• FN2: Relaţia R respectă FN2

30

• FN3: Relaţia R nu respectă FN3. Există următoarele dependenţe funcţionale 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 următoarele relaţii:• Clienţi(Codclient, Denumire, localitate, Adresa)• Contract(NrContract,DataContract,ProcentComision,Proc

entDobanda,ValoareCredit, Codclient)

31

Şi ce a mai rămas din relaţia R:

DispoziţieDePlata{NumarDP, DataDP, SumaDP, CodClient, NumarContract}

Datorită dependenţei (8), cheia externă CodClient va fi eliminată (este o cheie externă derivată/tranzitivă), iar relaţia va deveni:

DispoziţieDePlata{NumarDP,DataDP,SumaDP, NumarContract}• FNBC: relaţiile obţinute în FN3, verifică FNBC. Toţi determinanţii dependenţelor sunt chei candidate.

32