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.

Maini

EXEMPLU DE
DESCOMPUNERE
ERONAT
Masina

Constructor

Numar

Model

12 B113

r4

13 B666

2cv

11B999

r4

13B777

ds

Model

Marca

Culoare

r4

Renault

alb

2cv

Citroen

verde

r4

Renault

negru

ds

Citroen

alb

COMPUNERE natural
dac pe campul Model

Numr

Culoare

Model

Marca

12 B113

alb

r4

Renault

13 B666

verde

2cv

Citroen

11B999

negru

r4

Renault

13B777

alb

ds

Citroen

Nu rezult aceeai relaie!!!!

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

Maini

VEHICUL

Constructor

Numr

Culoare

Model

Marca

12 B113

alb

r4

Renault

Numr

Culoare

Model

13 B666

verde

2cv

Citroen

12 B113

alb

r4

11B999

negru

r4

Renault

13 B666

verde

2cv

13B777

alb

ds

Citroen

11B999

negru

r4

13B777

alb

ds

Model

Marca

r4

Renault

2cv

Citroen

ds

Citroen

Descompunere corect

Prin recompunere rezult

aceeai relaie!!!
Maini

COMPUNERE natural dac

pe campul Model sunt valori
egale

Numr

Culoare

Model

Marca

12 B113

alb

r4

Renault

13 B666

verde

2cv

Citroen

11B999

negru

r4

Renault

13B777

alb

ds

Citroen

5
Serie factur

Numar
factura

Data factur

Cod furnizor

Denumire furnizor

Adres furnizor

A01

01/01/2008

111

S.C. Alfa S.A.

Bucureti

A02

12/05/2008

112

S.C. Beta S.A.

Braov

A03

15/05/2008

112

S.C. Beta S.A.

Braov

Tabela Furnizori-Facturi

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

A----- > C

B 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.

Formele normale

12

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

Ionescu

Bucuresti, str. Stefan cel Mare,nr.2

02

Popescu

Ploiesti, str. Viitorului, nr.4

Relatia Comanda
Numarcomanda

Data

Material1

11

01/01/2008

Ciment

12

02/01/2008

Ciment

13

02/01/2008

Var

Material2
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

CodPies

Cantitate

PretUnitar

DenumirePies

01

100

20

Saiba

02

150

25

Rotor

01

200

20

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}

21

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.

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 n 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

Identificator

Explicatie

1.

CodFurnizor

Cod Furnizor

2.

DenumireFurnizor

Denumirea furnizorului

3.

AdresaFurnizor

Adresa Furnizorului

4.

NrFactura

Numar Factura

5.

DataFacturii

Data Factura

26

Graful dependentelor functionale

Denumirefurnizor
CodFurnizor
AdresaFurnizor

Nrfactura

Data facturii

27

Matricea dependentelor
functionale
Cod furnizor
Cod
furnizor

Denumire
furnizor

Adresa
furnizor

Denumire
furnizor

Adresa
furnizor

Numar
factura

1T

Data facturii

Numar
factura

Data facturii

1T

28 pot
4. Pentru atributele rmase izolate se vor cuta grupuri de cmpuri ce
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

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.