CURS 6.

Tehnica normalizrii relaiilor

La proiectarea structurii unei baze de date relaionale trebuie stabilite (dup
cum s-a vzut n cursurile anterioare) n primul rnd tabelele n care vor fi memorate
datele i asocierile dintre tabele. Acestea sunt stabilite ntr-o form iniial, dup
care, prin rafinare succesiv se ajunge la forma definitiv. Acestei structuri iniiale
i sunt aplicate un set de reguli care reprezint paii de obinere a unei baze de
date normalizate. Dac o baz de date nu este normalizat ea nu poate fi utilizat
cu un maxim de eficien. Algoritmul de normalizare a bazelor de date relaionale
precum i paii acestuia au fost descrii de ctre E. F. Codd n 1972.
Normalizarea este procesul reversibil de transformare a unei relaii n
relaii de structur mai simpl. (Procesul este reversibil n sensul c nici o
informaie nu este pierdut n timpul transformrii). Scopul normalizrii este de a
suprima redundanele logice i de a evita anomaliile la reactualizare.
Exemplu: Pentru a evidenia cteva exemple de redundane i anomalii, se va
considera cazul relaiei iniiale OFERTANTI. Pentru a nu ncrca relaia, se vor
considera valori ale atributelor prescurtate.
OFERTANTI:

Fig.6.1. Relaia OFERTANTI

-

Redundana logic: Tripletul (N1, Str. Victoriei, nr.22/12, Baia Mare,

Maramures, Nr1) apare de dou ori.
Anomalii la inserare: Dac o persoan ofer spre vnzare mai multe
imobile, pentru nregistrarea ofertei trebuie rescris codul numeric personal nc o
dat, deci cheia devine duplicat.
Anomalii de tergere: tergerea unei persoane din baza de date atrage
dup sine pierderea informaiilor despre oferta respectiv.
Anomalii la modificare: Dac se modific numele strzii Victoriei din
localitatea Baia Mare n strada Independenei, modificarea trebuie efectuat pentru
fiecare ofert din Baia Mare amplasat pe strada Victoriei. Dac ar exista 25 de
oferte n aceast localitate pe strada Victoriei, costul modificrii ar fi mare pentru a
modifica toate nregistrrile. Aceast redundan este eliminat dac atributul
adresa este mprit n alte trei atribute: simbol_judet, cod_loc, id_strada.
Valorile acestea vor fi codul judeului, localitii, respectiv a strzii preluate din

relaiile deja existente JUDETE, LOCALITATI, respectiv STRAZI. n acest caz,

modificarea se face doar o singur dat, n tabela STRAZI.
Normalizarea
Codd a definit iniial 3 forme normale, notate prin FN 1, FN2 i FN3. ntruct ntro prim formulare, definiia FN3 ridic ceva probleme, Codd i Boyce au elaborat o
nou variant, cunoscut sub numele de Boyce-Codd Normal Form (BCNF). Astfel
BCNF este reprezentat separat n majoritatea lucrrilor. R. Fagin a tratat cazul FN 4
i FN5.
O relaie este ntr-o form normal dac satisface o mulime de constrngeri
specificat n figura 6.2. De exemplu, se spune c o relaie se afl n a doua form
normal FN2 dac i numai dac se afl n FN1.
Relaia universal
FN1
FN2
FN3
BCFN

FN4

FN5

Fig.6.2. Formele normale ale relaiilor dintr-o BDR

Normalizarea bazei de date relaionale poate fi imaginat ca un proces prin
care pornindu-se de la relaia iniial/universal R se realizeaz
descompunerea succesiv a acesteia n subrelaii, aplicnd operatorul de
proiecie. Relaia R poate fi ulterior reconstruit din cele n relaii obinute n urma
normalizrii, prin operaii de jonciune.

6.1 Prima form normal (FN1)

FN1 este strns legat de noiunea de atomicitate a atributelor unei relaii.
Astfel, aducerea unei relaii n FN1 presupune introducerea noiunilor de:
atribut simplu;
atribut compus;
grupuri repetitive de atribute.
Atributul simplu- Atribut compus

Prin atribut simplu (atribut atomic) se nelege un atribut care nu mai poate fi
descompus n alte atribute, n caz contrar, atributul este compus (atribut neatomic).

Exemplu: Urmtoarele exemple de atribute pot fi considerate simple sau compuse n

funcie de circumstane i de obiectivele bazei de date.
Data calendaristic este un atribut n care apar cmpurile: zi, lun, an;

Adresa este un atribut n care apar cmpurile: strada, nr, bloc, scara, etaj,
apartament, localitate, jude;
Data operaiunii bancare este un atribut n care apar cmpurile data, ora;
Buletin/carte identitate este un atribut n care apar cmpurile: seria, nr.
Aceste atribute pot fi atomice sau neatomice. Astfel adresa clienilor ageniei
imobiliare intereseaz la nivel global, pe cnd pentru adresa ofertei sau a cererii de
imobile este vital prelucrarea separat a fiecrui cmp considerat.
Analog, atributul nume reprezint un atribut simplu al acestei baze de date,
deoarece numele clientului intereseaz la nivel global.
Grupuri repetitive de atribute
Un grup repetitiv este un atribut (grup de atribute) dintr-o relaie care apare cu
valori multiple pentru o singur apariie a cheii primare a relaiei nenormalizate.
Exemplu: Fie relaia nenormalizat (primar) FACTURI. Dorim s stabilim o structur
de tabele care s permit stocarea informaiilor coninute n document (factur) i
obinerea unor situaii sintetice privind evidena sumelor facturate pe produse, pe
clieni, pe anumite perioade de timp.
FACTURI
nr_factura#
data_factura
nume_client
adresa_client
banca_client
nr_cont_client
delegat
cod_produs
denumire_produs
unitate_de_masura
cantitate
pret_unitar
valoare
valoare_tva
total_valoare_factura
total_valoare_tva

Fig. 6.3. Relaia FACTURI nenormalizat

n cazul n care o factur conine mai multe produse, relaia de mai sus va avea
grupurile repetitive: cod_produs, denumire_produs, cantitate, pret_unitar,
valoare, valoare_tva.
Aducerea unei relaii universale la FN 1
FN1 este tratat n general cu superficialitate, deoarece principala cerin
atomicitatea valorilor este uor de ndeplinit (cel puin la prima vedere).

Dintre toate formele normale, doar FN1 are caracter de obligativitate. Se

spune c o baz de date este normalizat daca toate relaiile se afl mcar n FN 1.
O relaie este n FN1 dac domeniile pe care sunt definite atributele
relaiei sunt constituite numai din valori atomice. Un tuplu nu trebuie s conin
atribute sau grupuri de atribute repetitive.
Aducerea relaiilor n FN1 presupune eliminarea atributelor compuse i a celor
repetitive.
Se cunosc trei soluii pentru determinarea grupurilor repetitive:
eliminarea grupurilor repetitive pe orizontal (n relaia R iniial, n locul
atributelor compuse se trec componentele acestora, ca atribute simple);
eliminarea grupurilor repetitive prin adugarea de tupluri;
eliminarea grupurilor repetitive prin construirea de noi relaii.
Primele dou metode genereaz relaii stufoase prin duplicarea forat a unor
atribute, respectiv tupluri, crendu-se astfel redundane masive cu multiple anomalii
de actualizare.
Metoda a treia presupune eliminarea grupurilor repetitive prin
construirea de noi relaii, ceea ce genereaz o structur ce ofer cel mai mic
volum de redundan.
Etapele de aducere a unei relaii n FN 1 sunt:
I. se construiete cte o relaie pentru fiecare grup repetitiv;
II. n schema fiecrei noi relaii obinute la pasul 1 se introduce i cheia
primar a relaiei R nenormalizate;
III. cheia primar a fiecrei noi relaii va fi compus din atributele chei ale
relaiei R, plus unul sau mai multe atribute proprii.
-

Exemplu: Deoarece o factur poate avea unul sau mai multe produse nscrise pe
aceasta, informaiile legate de produse vor fi separate ntr-o alt tabel. Aplicnd
etapele de aducere la FN1, se obin dou relaii:
FACTURI

LINII_FACTURI

nr_factura#
data_factura
nume_client
adresa_client
banca_client
nr_cont_client
delegat
toal_valoare_factura
toal_valoare_tva

nr_factura#
cod_produs#
denumire_produs
unitate_de_masura
cantitate
pret_unitar
valoare
valoare_tva

Fig. 6.4. Relaia FACTURI adus n forma normal FN1

Observaia1: Cmpul adresa_client cuprinde informaii despre judeul, localitatea,
strada i numrul domicililului clientului. Dac se consider c este de interes o
eviden a sumelor factorizate pe judee sau localiti, se vor pune n locul cmpului
adresa_client
trei
cmpuri
distincte:
judet_client,
localitate_client,
adresa_client, uurnd n acest fel interogrile.

Observaia2: ntre tabela FACTURI i tabela LINII_FACTURI exist o relaie de unu

la muli, adic unui numr unic de factur i pot corespunde unul sau mai multe
produse care sunt memorate ca nregistrri n tabele LINII_FACTURI. Cheia primar
n aceast tabel este o cheie compus, format din dou cmpuri: nr_factura i
cod_produs.
ns eliminarea grupurilor repetitive, adic aducerea unei relaii la FN 1, nu
rezolv complet problema normalizrii.

6.2. A doua form normal (FN2)

FN2 este strns legat de noiunea de dependen funcional. Noiunea de
dependen funcional a fost prezentat n cursul 5: Restricii de integritate ale
modelului relaional.
O relaie se afl n a doua form normal FN2 dac:
1. se afl n forma normal FN1 i
2. fiecare atribut care nu este cheie este dependent de ntreaga cheie primar.
Etapele de aducere a unei relaii de la FN 1 la FN2 sunt:
I. Se identific posibila cheie primar a relaiei universale aflat n FN1;
II. Se identific toate dependenele dintre atributele relaiei, cu excepia acelora
n care destinaia este un atribut component al cheii primare;
III. Se identific toate dependenele care au ca surs un atribut sau subansamblu
de atribute din cheia primar;
IV. Pentru fiecare atribut (sau subansamblu) al cheii de la pasul III se creeaz o
relaie care va avea cheia primar atributul (subansamblul) respectiv, iar
celelalte atribute vor fi cele care apar ca destinaie n dependenele de la
etapa III.
V. Din relaia iniial sunt eliminate toate atributele destinaie (noncheie) ale DF
gsite la pasul III.
Exemplu: Relaia care conine date redundante (de exemplu, modificarea denumirii
unui produs atrage dup sine modificarea n fiecare tuplu n care apare acest
produs) este relaia LINII_FACTURI. Se observ ca nu exist nici o dependen
funcional ntre atributele necomponente ale cheii. n schimb, toate atributele care
nu intr n alctuirea cheii compuse sunt dependente de aceasta, iar DF dintre
atributul component al cheii primare sunt: cod_produs --> denumire_produs,
cod_produs --> unitate_de_masura. Ca urmare se formeaz nc dou relaii.
FACTURI

LINII_FACTURI

PRODUSE

nr_factura#
data_factura
nume_client
adresa_client
banca_client
nr_cont_client
delegat
toal_valoare_factura
toal_valoare_tva

nr_factura#
cod_produs#
cantitate
pret_unitar
valoare
valoare_tva

cod_produs#
denumire_produs
unitate_de_masura

Fig. 6.5. Relaia FACTURI n a doua forma normal FN2

Chiar dac au fost eliminate o parte din redundane, mai rmn i alte
redundane ce se vor elimina aplicnd alte forme de normalizare.

6.3. A treia form normal (FN3)

O relaie este n forma normal trei FN3 dac:
1. se gsete n FN2 i
2. fiecare atribut care nu este cheie (nu particip la o cheie) depinde direct de cheia
primar.
A treia regul de normalizare cere ca toate cmpurile din tabele s fie
independente ntre ele.
Etapele de aducere a unei relaii de la FN 2 la FN3 sunt:
I. Se identific toate atributele ce nu fac parte din cheia primara i sunt surse
ale unor dependene funcionale;
II. Pentru aceste atribute, se construiete cte o relaie n care cheia primar va
fi atributul respectiv, iar celelalte atribute, destinaiile din DF considerate;
III. Din relaia de la care s-a pornit se elimin atributele destinaie din DF
identificat la pasul I, pstrndu-se atributele surse.
Exemplu: n relaia FACTURI se observ c atributul nume_client determin n mod
unic atributele adresa_client, banca_client i nr_cont_client. Deci pentru
atributul nume_client se construiete o relaie CLIENTI n care cheia primar va fi
acest atribut, iar celelalte atribute vor fi adresa_client, banca_client i
nr_cont_client. Cmpurile valoare i valoare_tva depind de cmpurile
cantitate, pret_unitar, i de un procent fix de TVA. Fiind cmpuri ce se pot calcula
n orice moment, ele vor fi eliminate din tabel LINII FACTURI, deoarece constituie
informaie memorat redundant.
FACTURI

LINII_FACTURI

PRODUSE

CLIENTI

nr_factura#
data_factura
nume_client
delegat
toal_valoare_factura
toal_valoare_tva

nr_factura#
cod_produs#
cantitate
pret_unitar

cod_produs#
denumire_produs
unitate_de_masura

nume_client#
adresa_client
banca_client
nr_cont_client

Fig. 6.6. Relaia FACTURI n a treia forma normal FN3

Observaia 1: Aceast a treia form normal mai poate suferi o serie de rafinri
pentru a putea obine o structur performant de tabele ale bazei de date. De
exemplu se observ c nume_client este un cmp n care este nscris un text
destul de lung format dintr-o succesiune de litere, semne speciale (punct, virgul,
cratim), spaii, numere. Ordonarea i regsirea informaiilor dup astfel de cmpuri
este lent i mai greoaie dect dup cmpuri numerice. Din acest motiv se poate
introduce un nou atribut cod_client care s fie numeric i care s fie cheia primar
de identificare pentru fiecare client.

Observaia 2: O alt observaie care poate fi fcut n legtur cu tabelele aflate n

cea de a treia form normal este aceea c total_valoare_factura este un cmp
care ar trebui s conin informaii sintetice obinute prin nsumarea valorii tuturor
ofertelor aflate pe o factur. Este de preferat ca astfel de cmpuri s fie calculate n
rapoarte sau interogri i s nu fie memorate n tabelele bazei de date.
FACTURI

LINII_FACTURI

PRODUSE

CLIENTI

nr_factura#
data_factura
cod_client
delegat

nr_factura#
cod_produs#
cantitate
pret_unitar

cod_produs#
denumire_produs
unitate_de_masura

cod_client#
nume_client
adresa_client
banca_client
nr_cont_client

Verificarea aplicrii corecte a procesului de normalizare se realizeaz astfel

nct uniunea acestor relaii s produc relaia iniial, cu alte cuvinte,
descompunerea este fr pierderi.
Celelalte forme normale se ntlnesc mai rar n practic. Aceste forme nu sunt
respectate, n general, pentru c beneficiile de eficien pe care le aduc nu
compenseaz costul i i munca de care este nevoie pentru a le respecta.