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, de a evita anomaliile la reactualizare i rezolvarea
problemei reconexiunii.
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:

cnp#numeleadresa_ clientnr_
telefonofertaadresa_ imobilCnp1N1Str. Victoriei, nr.22/12, Baia
Mare, MaramuresNr1casaA_imobil1Cnp1N1Str. Victoriei, nr. 4/5,
Cluj-Napoca, ClujNr1halaA_imobil2Cnp2N2Str. Viilor, nr.55/4,
Oradea, BihorNr2casaA_imobil3Cnp3N3Str. Grii, nr. 14, Bucuresti
Nr3terenA_imobil4

Fig.7.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
1

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 FN1, FN2 i FN3. ntruct
ntr-o 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 FN4 i FN5.
O relaie este ntr-o form normal dac satisface o mulime de
constrngeri specificat n figura 7.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.7.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.

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

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 reprezent 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 clinei, 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
cantiate
pret_unitar
valoare
valoare_tva
toal_valoare_factura
toal_valoare_tva
Fig. 7.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 FN1
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
FN1.
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 FN1 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
cantiate
pret_unitar
valoare
valoare_tva

Fig. 7.4. Relaia FACTURI adus n forma normal FN1

Observaia1: Cmpul adresa_client curpinde 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.

7.2. A doua form normal (FN2)

5

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 FN1 la FN2 sunt:
I. Se identific posibila cheie primar a relaiei aflate n FN1;
II. Se identific toate dependenele dintre atributele relaiei, cu excepia
acelora n care sursa 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.
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#
cantiate
pret_unitar
valoare
valoare_tva

cod_produs#
denumire_produs
unitate_de_masura

Fig. 7.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 normale.

A treia form normal

7.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 FN2 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#
cantiate
pret_unitar

cod_produs#
denumire_produs
unitate_de_masura

nume_client#
adresa_client
banca_client
nr_cont_client

Fig. 8.1. 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
7

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 a 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.
LINII_FACTURI
PRODUSE
CLIENTI
FACTURI
nr_factura#
data_factura
delegat

nr_factura#
cod_produs#
cantiate
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 acestora 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 munca de care este nevoie pentru a le respecta