1

4. NORMALIZAREA


4.1. Relatii/tabele, domenii, atribute, valori nule

La modul simplist, o baza de date rela tionala (BDR) poate fi definita ca un ansamblu de relatii
(tabele); fiecare tabela (sau tabel), alcatuita din linii (tupluri), are un nume urnc si este stocata pe suport
extern (de obicei disc). La intersectia unei linii cu o coloana se gaseste o valoare atomica. O relatie
contine informa tii omogene legate de anumite entitati, procese, fenomene: CARTI, ELEVI,
LOCALITATI, PERSONAL, FACTURI etc. Spre exemplu, n figura 4.1 este reprezentata tabela
STUDENTI ce stocheaza informatii privitoare la studentii nscrisi la cursurile unei facult ati.
n teoria relat ionala se foloseste termenul relatie. Practica nsa a consacrat termenul tabela (engl.
table). Un tuplu sau o linie este o succesiune de valori de diferite tipuri. n general, o linie grupeaza
informatii referitoare la un obiect, eveniment etc., altfel spus, informatii referitoare la o entitate: o carte
(un tit lu sau un exemplar din depozitul unei biblioteci, depinde de circumstante), un/o student(a), o
localitate (oras sau comuna), un angajat al firmei, o factura emisa etc. n figura este pus n evidenta al
saselea tuplu din tabela STUDENTI, tuplu referitor la studentul Ionescu Y. Vasile. Linia respectiva este
alcatuita din noua valori ce desemneaza: matricolul studentului; numele, initiala tatalui si prenumele;
codul numeric personal (CNP-ul), adresa (stabila); anul de studiu; modulul (daca e n anul 1 sau 2) sau
specializarea (daca e n anii 3, 4 sau 5) la care este nscris studentul; seria de curs; grupa; tipul de bursa
de care beneficiaza.
Teoretic, orice tuplu reprezinta o relatie ntre clase de valori (n cazul nostru, ntre noua clase de
valori); de aici provine sintagma baze de date relationale, n sensul matematic al relatiei, de asociere a
doua sau mai multe elemente. Fireste, toate tuplurile relatiei au acelasi format (structura). Ordinea
tuplurilor nu prezinta importanta din punctul de vedere al continutului informational al tabelei.


Matricol Nume-
Prenume
CNP Adresa An
studiu
Modul-
Specializare
Seria Grupa Tip bursa
M1 A R. B 12221 Vaslui, 1 1 A 1 M
M2 W D. E 22222 Botosani, 1 1 A 2 NULL
M3 O F. D 22223 Iasi, 1 2 A 2 S1
M4 P H. J 12224 NULL 3 C C 3 NULL
M5 R T. U 12225 Sibiu, 4 T G 3 S2
M6 I Y. V 22226 Cluj, 2 2 D 2 S1
M7 J G. F 12227 Arad, 3 D E 1 NULL

Figura 4.1. Relatia (tabela) STUDENTI

Fiecare atribut este caracterizat printr-un nume si un domeniu de valori pe care le poate lua.
Domeniul poate fi definit ca ansamblul valorilor acceptate (autorizate) pentru un element component al
relatiei :
2

ntr-o tabela destinata datelor generale ale angajatilor, pentru atributul Sex, domeniul este
alcatuit din doua valori : femeiesc si barbatesc ;
domeniul atributului Judet este alcatuit din numele fiecarui judet (plus Bucuresti) ;
domeniul unui atribut precum PretUnitar, care se refera la pretul la care a fost vndut un
produs/serviciu, este cu mult mai larg, fiind alcatuit din orice valoare cuprinsa ntre 1 si 99999999999
lei.
Retinem corespondenta notiunilor relat ie-tabela, tuplu- linie si atribut-coloana.
Numarul de tabele pe care le contine o baza de date, atributele "adunate" n fiecare tabela,
domeniul fiecaruia dintre atribute prezinta diferente majore de la o baza la alta, chiar daca uneori
reflecta acelasi tip de procese. Intram astfel n sfera proiectarii bazelor de date, a dependentelor si
normalizarii.
n figura 4.1 se observa ca atributul Adresa contine, pe linia (tuplul) 4, o valoare curioasa, notata
NULL. Valoarea NULL este considerata o metavaloare si indica faptul ca, n acel loc, informatia este
necunoscuta sau inaplicabila. n cazul nostru, studentului P H. J nu i se cunoaste adresa. Valoarea
NULL este diferita de valorile 0 sau spatiu.
n ncheiere, principalele caracteristici ale unei relatii sunt sistematizate dupa cum urmeaza:
n cadrul unei baze de date, o relatie prezinta un nume distinct de al celorlalte relatii;
valoarea unui atribut ntr- un tuplu oarecare cont ine a singura valoare (o valoare atomica) ;
fiecare atribut are un nume distinct;
orice valoare a unui atribut face parte din domeniul pe care a fost definit acesta ;
ordinea dispunerii atributelor n relatie nu prezinta importanta ;
fiecare tuplu este distinct, adica nu pot exista doua tupluri identice ;
ordinea tuplurilor nu influenteaza continutul informational al relatiei.

4.2. Restrictii ale bazei de date

Principalele restrictii definibile n modelul relational sunt: de domeniu, de nenulitate, de
atomicitate, de unicitate, referentiala si cele definite de utilizator.

Restrictia de domeniu
Dupa cum am vazut n paragraful anterior, un atribut este definit printr-un nume si un domeniu.
Orice valoare a atributului trebuie sa se ncadreze n domeniul definit. Exista mai multe moduri de
perceptie a acestei restrictii. O parte din informaticieni substituie domeniul tipului atributului: numeric,
sir de caractere, data calendaristica, logic (boolean) etc., si, eventual, lungimii (numarul maxim de
pozitii/caractere pe care se poate "ntinde" un atribut). Dupa cum se observa, este luat n calcul numai
aspectul sintactic al domeniului. Faptul ca anul de studiu al unei clase poate fi una dintre valorile 9, 10,
11, 12 reprezinta o restrict ie de comportament sau, mai simplu, o restrictie definita de utilizator.
Cea de-a doua categorie priveste deopotriva domeniile sintactic si semantic. Astfel, domeniul
sintactic al atributului LitClasa (litera) dintr-o relatie precum ELEVI_LICEU este un caracter,
obligatoriu litera,si chiar mai restrictiv, litera e obligatoriu majuscula. Din punct de vedere semantic,
3

LitClasa poate lua una dintre valorile: A, B, C, ... , n functie de numarul de clase dintr- un an de studiu
(cinci clase de a IX-a, patru de a X-a etc.).
Majoritatea SGBD-urilor permit definirea tuturor elementelor ce caracterizeaza domeniul
(sintactic si semantic) atributelor prin declararea tipului si lungimii atributului si prin asa-numitele reguli
de validare la nivel de cmp (field validation rules). Sunt nsa si produse la care domeniul poate fi
definit explicit, sintactic si semantic, dndu-i-se un nume la care vor fi legate atributele n momentul
crearii tabelelor.

Nenulitatea
Desi inventata de nsusi E.P. Codd, valoarea nula este vehement contestat a de cea mai mare parte
a liniei purist-relationale (Date, Darwen, Pascal). Nu discutam aici legitimitatea unei asemenea meta-
valori, ci doar amintim ca, ntr-o baza de date, unora dintre atribute li se poate interzice valoarea NULL.

Atomicitate
Conform teoriei bazelor de date relationale, orice atribut al unei tabele oarecare trebuie sa fie
atomic, n sensul imposibilitatii descompunerii sale n alte atribute.
n aceste conditii, se spune ca baza de date se afla n prima forma normala sau prima forma
normalizata (lNF). n tabela STUDENTI un atribut cu valori neatomice poate fi considerat, pentru
majoritatea situatiilor, Adresa, ntrucat valorile sale ngramadesc elemente ce pot fi si individualizate:
strada, numar, bloc, scara, etaj, apartament, localitate si judet.
Astazi, atomicitatea valorilor atributelor a devenit o tinta predilecta a "atacurilor dusmanoase" la
adresa modelului relational, datorita imposibilitatii nglobarii unor structuri de date mai complexe,
specifice unor domenii ca: proiectare asistata de calculator, baze de date multimedia etc.

Unicitate
ntr-o relatie nu pot exista doua linii identice (doua linii care prezinta aceleasi valori pentru toate
atributele). Mai mult, majoritatea relat iilor prezinta un atribut sau o combinatie de atribute care
diferentiaza cu siguranta un tuplu de toate celelalte tupluri ale relat iei. Cheia primara a unei relatii
(tabele) este un atribut sau un grup de atribute care identifica fara ambiguitate fiecare tuplu (linie) al
relatiei (tabelei). Exista trei restrictii pe care trebuie sa le verifice cheia primara :
o unicitate: o cheie identifica un singur tuplu (linie) al relatiei ;
o compozitie minimala: atunci cnd cheia primara este compusa, niciun atribut din cheie nu
poate fi eliminat fara distrugerea unicitatii tuplului n cadrul relatiei; n cazuri limit a, o
cheie poate fi alcatuita din toate atributele relatiei ;
o valori nenule: valorile atributului (sau ale ansamblului de atribute) ce desemneaza cheia
primara sunt ntotdeauna specificate, deci nenule; mai mult, niciun atribut din compozitia
eheii primare nu poate avea valori nule. Cea de-a treia conditie se mai numeste si
restrictie a entitatii.
Domeniul unui atribut care este cheie primara ntr-o relatie este denumit domeniu primar. Daca
ntr-o relat ie exista mai multe combinatii de atribute care confera unicitate tuplului, acestea sunt
4

denumite chei candidate. O cheie candidata care nu este identificator primar este referita ca fiind cheie
alternativa. n tabela STUDENTI exista doua chei candidate, Matricol si CNP. Pe baza unor criterii
necunoscute (deocamdata), am ales Matricol drept cheie primara, CNP-ul devenind cheie alternativa.
Daca cheia primara a tabelei STUDENTI este una simpla, exista nsa suficiente eazuri n care
cheia primara este compusa din doua, trei s.a.m.d. sau, la extrem, toate atributele relatiei. Sa luam spre
analiza o relatie PERSONAL care contine date generale despre angajatii firmei. Fiecare tuplu al relatiei
se refera la un angajat, atributele fiind: Nume, Prenume, DataNasterii, Vechime, SalariuTarifar.
o Atributul Nume nu poate fi cheie, deoareee chiar si ntr-o ntreprindere de talie mijlocie
este posibil sa existe doi angajati cu acelasi nume.
o Daca aparitia a doua persoane cu nume identice este posibila, atunci aparitia a doua
persoane cu acelasi Prenume este probabil.
o Niciunul dintre atributele DataNasterii, Vechime si SalariuTarifar nu poate fi "nzestrat"
cu functia de identificator.
o n acest caz, se ncearca gruparea a doua, trei, patru s.a.m.d. atribute, pna cnd se obtine
combinatia care va permite diferentierea clara a oricarei linii de toate celelalte.
o Combinatia Nume +Adresa pare, la prima vedere, a ndeplini "cerintele" de identificator.
Ar fi totusi o problema: daca n aceeasi firma (organizatie) lucreaza mpreuna sotul si
sotia? Ambii au, de obicei, acelasi nume de familie si, tot de obicei, acelasi domiciliu.
Este adevarat, cazul ales nu este prea fericcit. Dar este suficient pentru compromiterea
combinatiei.
o Urmatoarea tentativa este grupul Nume + Prenume + Adresa, combinat ie neoperanta daca
n organizatie lucreaza tatal si un fiu (sau mama si o fiica), avand aceleasi nume si
prenume si domiciliul comun.
o Ar ramne de ales una dintre solutiile (Nume +Prenume +Adresa +Vechime) sau (Nume
+ Prenume +Adresa + DataNasterii).
Oricare dintre cele doua combinatii prezinta riscul vio larii restrictiei de entitate, deoarece este
posibil ca, la preluarea unui angajat n baza, sa nu i se cunoasca adresa sau data nasterii, caz n care
atributul respectiv ar avea valoarea NULL. Dificultatile de identificare fara ambiguitate a angajatilor au
determinat firmele ca, la angajare, sa aloce fiecarei persoane un numar unic, numar denumit Marca. Prin
adaugarea acestui atribut la cele existente, pentru relatia PERSONAL, problema cheii primare este
rezolvata mult mai simplu. Actualmente, sarcina este simplificata si prin utilizarea codului numeric
personal (CNP), combinatie de 13 cifre care prezinta avantajul ca ramne neschimbata pe tot parcursul
vietii persoanei.

Restrictia referentiala
O baza de date relationala este a1catuita din relatii (tabele) aflate n legatura. Stabilirea legaturii
se bazeaza pe mecanismul cheii straine si, implicit, al restrictiei referentiale. Figura 4.2 prezinta o relatie
n care sunt implicate tabelele TIP_BURSE si STUDENTI. Atributul Tip_Bur sa joaca un rol de "agent
de legatura" ntre cele doua relatii. Pentru tabela TIP_BURSE, atributul Tip_Bursa este cheie primara, n
timp ce n tabela STUDENTI, Tip_Bursa reprezinta o coloana de referinta sau cheie straina (externa),
5

deoarece numai pe baza valorilor sale se poate face legatura cu relatia-parinte TIP_BURSE. Cheile
straine sau coloanele de referinta sunt deci atribute sau combinat ii de atribute care pun n legatura linii
(tupluri) din relatii diferite. Tabela n care atributul de legatura este primar se numeste tabela-parinte (n
cazul nostru, TIP_BURSE), iar ceala ta, tabela-copil.
Legat de notiunea de cheie straina apare conceptul de restrictie referentiala. O restrictie de
integritate referentiala apare atunci cnd o relatie face referinta la o alta relatie. Cnd doua tabele
(relatii), T1 si T2, prezinta atributul sau grupul de atribute notat CH, care pentru Tl este cheie primara,
iar pentru T2 - cheie straina, daca n T2 se interzice aparitia de valori nenule ale CH care nu exista n
niciun tuplu din T1, se spune ca ntre T2 ~i T1 s-a instituit o restrictie referentiala.
Instituirea restrictiei referentiale ntre tabelele TIP_BURSE (parinte) si STUDENTI (copil)
permite cunoasterea, pentru fiecare student, a denumirii bursei si a cuantumului lunar. Daca n
STUDENTI ar exista vreo linie n care valoarea atributului Tip_Burse ar fi, spre exemplu S3, este clar
ca acea linie ar fi orfana (nu ar avea linie corespondenta n tabela-parinte).



TIP BURSE
Tip bursa Denumire
bursa
Cuantum
bursa
M Merit 700
NULL
S1 Studiu 1 500


STUDENTI
Matricol Nume-
Prenume
CNP Adresa An
studiu
Modul-
Specializare
Seria Grupa Tip bursa
M1 A R. B 12221 Vaslui, 1 1 A 1 M
M2 W D. E 22222 Botosani, 1 1 A 2 NULL
M3 O F. D 22223 Iasi, 1 2 A 2 S1

Fig. 4.2. Mecanismul de legare a tabelelor

Observatii
Pentru multi utilizatori si profesionisti ai bazelor de date, denumirea de "relational" desemneaza
faptul ca o baza de date este alcatuita din tabele puse n legatura prin intermediul cheilor straine.
Aceasta este, de fapt, a doua acceptiune a termenului de BDR, prima, cea clasica, av nd n
vedere perceptia fiecarei linii dintr-o tabela ca o relatie ntre clase de valori.
Majoritatea SGBD-urilor prezinta mecanisme de declarare si gestionare automata a restrictiilor
referentiale, prin actualizari n cascada si interzicerea valorilor care ar indica aceste restrictii.
Respectarea restrictiilor referentiale este una dintre cele mai complicate sarcini pentru
dezvoltatorii de aplicatii ce utilizeaza baze de date. Din acest punct de vedere, tentatia este de a
6

"sparge" baza de date n ct mai putine tabele cu putinta, altfel spus, de a avea relatii ct mai
"corpolente". Gradul de fragmentare a bazei tine de normalizarea bazei de date, care, ca parte a
procesului de proiectare a BD, se bazeaza pe dependentele func tionale, multivaloare si de
jonctiune ntre atribute.

Restrictii-utilizator
Restrictiile- utilizator mai sunt denumite si restrictii de comportament sau restrictii ale
organizatiei. De obicei, aceste restrictii iau forma unor reguli de validare la nivel de atribut, la nivel de
linie sau de tabela sau a unor reguli implementate prin declansatoare (triggers). Spre exemplu, se poate
institui o regula care interzice emiterea unei noi facturi (o noua vnzare) daca datoriile firmei client sunt
mai mari de 2.ooo.ooo.ooo lei, iar directorul acesteia nu este membru n partidul/partidele de
guvernamnt.

4.3. Nevoia de normalizare
Unul dintre cele mai bune argumente n favoarea normalizarii tine de punerea n evidenta a ceea
ce s-ar ntmpla n absenta sa. Sa luam un prim exemplu, cel din figura 2.3, care este dedicat stocarii
datelor privitoare la studentii unei facultati, mai ales n ceea ce priveste situa tia scolara a acestora.
Fiecare student are un identificator unic - Matricol -, este nscris la o specializare ntr- un an de studii si
sustine examenele la disciplinele din planul de nvatamnt. Orice disciplina are alocat un numar de
credite prin planul de nvatamnt al specializarii. Fiecare student poate sustine un examen de mai multe
ori, pna l promoveaza (sau este exmatriculat). Astfel, Ionescu I. Ion a picat examenul la Baze de date
n prima sesiune (pe 29 ianuarie 2oo9), dar l-a promovat n restante (pe 12 septembrie).


STUDENTI EXAMENE
Matricol NumePrenume An Specializare CodDisc DenumireDisc NrCredite DataExamen Nota
M1 Ionescu I. Ion 3 Retele D31 Baze de date 4 29.01.09 4
M2 Popescu P. Petre 3 Retele D31 Baze de date 4 29.01.09 7
M3 Georgescu G. George 3 Retele D31 Baze de date 4 29.01.09 6
M4 Florescu F. Florin 3 Retele D31 Baze de date 4 29.01.09 9
M5 Ionescu I. Ion 3 Retele D31 Baze de date 4 29.01.09 8
M5 Costescu C. Costin 3 Retele D31 Baze de date 4 12.09.09 6

Figura 4.3. Relatie supusa normalizarii

Deoarece fiecare linie se refera la un examen sus tinut la o anumita data de un student, cheia
primara a relatiei este combinatia (Matricol, CodDisc, DataExamen).

4.3.1. Redundante
Este lesne de observat ca relatia de mai sus contine redundante. Astfel, daca un student sustine,
pe parcursul primelor n semestre de studii, 25 de examene, atunci matricolul, numele, anul si
7

specializarea sunt prezente n toate cele 25 de linii. Daca pentru o disciplina s-au consemnat n baza de
date 15oo de examinari, atunci nu numai codul, ci si denumirea si numarul de credite alocat disciplinei
apar de acelasi numar de ori.
Cu ct baza de date este mai mare, cu att risipa de spatiu este mai importanta.Chiar daca spatiul
de stocare nu mai este o problema din punctu1 de vedere al costului, obezitatea unei tabele precum cea
de mai sus poate atrage serioase probleme de viteza n exp1oatare (timpi de asteptare 1a preluarea noilor
note etc.).

4.3.2. Anomalii la inserare
Sa luam n discutie studentii din anul I. Dupa examenul de admitere, ce are loc n lunile iulie si
septembrie, acestia sunt nmatriculati. Daca nsa baza de date are schema relatiei de mai sus, preluarea
este imposibila pna n momentul primului examen al studentului respectiv. Aceasta deoarece n cheia
primara sunt incluse si atributele CodDisc si DataEx, iar modelul relat ional interzice valori nule pentru
atributele-cheie (restrictia de entitate). Or, la data nmatricularii, studentii din anul I nu au nici un
examen sustinut, iar prima sesiune e abia n ianuarie, anul urmator, asa ca si CodDisc si DataEx sunt n
acel moment NULL.

4.3.3. Anomalii la modificare
Presupunem ca ntr-o sedinta de catedra se decide ca disciplina Programarea calculatoarelor sa
fie redenumita Programare I, titulatura sub care va aparea si n foile matricole ale studentilor din actualul
an al III- lea, care vor absolvi specializarea Retele. n baza de date exista cteva sute de nregistrari
referitoare la studentii examinati la aceasta disciplina si toate trebuie modificate. Daca, dintr-un motiv
sau altul, modificarea se face numai pe o parte dintre liniile cu pricina, putem afirma ca datele si pierd
consistenta. Avem de-a face cu o anomalie de modificare ntr-o relatie atunci cnd modificarea valorii
unui atribut atrage obligativitatea actualizarii aceleeasi valori pe mai multe linii.

4.3.4. Anomalii la stergere
Anomaliile la stergere se manifesta atunci cnd, prin eliminarea unei linii dintr-o tabela, se pierd
involuntar nu numai informatiile despre entitatea reflectata de linia respectiva, ci si alte informatii.
Astfel, daca stergem ultima linie din relatia de mai sus, cea care contine nota examenului la Baze de date
sustinut de studentul Georgescu G. George pe 29 ianuarie 2oo9, se pierd nu numai datele despre
examenul respectiv, ci si toate informatiile despre studentul Georgescu G. George., deoarece aceasta era
singura linie n care aparea studentul cu pricina.

4.5. Normalizarea
Proiectarea bazelor de date relationale (BDR) presupune definirea atributelor, gruparea lor n
tabele, stabilirea legaturilor dintre ele, a mecanismelor de integritate si securitate, fiind un proces dificil
n care cuno stintele teoretice, experienta, inteligenta, intuitia si creativitatea proiectantilor se mbina ntr-
un mod mai mult sau mai putin armonios.
8

Structura finala a BD trebuie sa asigure un echilibru ntre, pe de o parte, obtinerea unui volum
maxim de informatii ntr-un interval de timp ct mai scurt si, pe de alta parte, eliminarea anomaliilor de
stocare si actualizare, toate n conditiile unui grad apreciabil de securitate si integritate.
Elaborarea schemei unei BD poate ncepe (si) cu gruparea tuturor atributelor bazei de date ntr-o
singura tabela (relatie universala). Dincolo de avantajul compactitatii, lucrul cu o singura relatie
atotcuprinzatoare ridica serioase probleme privind redundanta datelor si genereaza anomalii importante
la adaugarea, modificarea sau stergerea unor linii (tupluri).
Ca o consecinta directa, este necesara spargerea bazei n mai multe tabele care sa fie legate prin
restrictii de integritate referentiala. Este tocmai obiectivul central a1 normalizarii. Spargerea relatiei nu
trebuie facuta oricum, deoarece apare riscul pierderilor de informatii. De asemenea, un numar prea mare
de tabele necesita un efort sporit pentru controlul bazei si respectarea restrictiilor. n plus, trebuie sa
tinem seama de faptul ca obtinerea multor informatii dintr-o baza de date fragmentata este posibila prin
operatiunea de jonctiune, mare consumatoare de resurse.
ntr-o enumerare, principalele obiective ale normalizarii sunt:
o minimizarea spatiului necesar stocarii datelor ;
o minimizarea riscului aparitiei de date inconsistente n cadrul BD ;
o minimizarea anomaliilor ce pot aparea la actualizare (inserarea datelor, dar mai ales
modificari si stergeri) ;
o ameliorarea structurii bazei, reprezentarea diverselor conexiuni dintre atributele bazei;
o diminuarea nevoii de reorganizare periodica a modelului.

Obiect al numeroase studii, nu se poate afirma ca exista o unanimitate de idei si instrumente
privind normalizarea. Importanta normalizarii nu trebuie absolutizata, deoarece aceasta vine adesea n
contradictie cu parametri extrem de importanti ai aplicatiilor de lucru cu bazele de date: viteza de acces,
securitate marita, resurse hard/soft disponibile, reducerea traficului pe retea etc. Se poate spune ca o BD
riguros normalizata nu este neaparat una optima.
Teoria clasica a normalizarii este construita n jurul a doua forme care n literatura sunt referite
ca normale sau normalizate. Desi termenul original este normal form (si nu normalized form), mai
uzuala este sintagma forma normalizata. Pentru a fi ntr-o anumita forma normala/normalizata, o baza
de date trebuie sa respecte un anumit set de restrictii.
Codd, parintele modelului relational, a definit initial trei forme normale, notate prin 1NF, 2NF ti
3NF. ntrucat, ntr-o prima formulare, definitia 3FN ridica ceva probleme, Codd si Boyce au elaborat o
noua varianta, cunoscuta sub numele Boyce-Codd Normal Form (BCNF). Desi este vorba, n principiu,
despre o formulare mai riguroasa a aceleeasi 3FN, BCNF este prezentata separat n majoritatea
lucrarilor.
Formele 4 si 5, legate de numele lui Ronald Fagin, sunt tratate mai cu retinere n literatura
consacrata analizei si proicetarii bazelor de date. Unele lucrari cu tenta mai pragmatica se opresc
declarat la 3FN, pe care o considera suficienta n elaborarea BDR.


9

4.5.1. Etapele normalizarii
Fundamentul normalizarii BDR l constituie dependentele dintre atribute. Primele trei forme
normale pot fi determinate pe baza dependentelor functionale elementare (totale) si tranzitive. Forma a
patra (4FN) se bazeaza pe dependentele multivaloare, n timp ce a cincea forma normala (5FN) - pe
dependentele de jonctiune. Problema este ca dependentele multivaloare si (mai ales) cele de jonctiune
sunt dificil de identificat si rar ntlnite n practica.
Normalizarea BDR poate fi imaginata ca un proces prin care, pornindu-se de la relatia initiala R
(universala), se realizeaza descompunerea succesiva a acesteia n subrelatii, dupa succesiunea din figura
4.4. Relatia R poate fi ulterior reconstruita din cele n relatii obtinute n urma normalizarii, prin operatii
de jonctiune aplicate asupra acestora.






























Relatie universala R
Exista grupuri
repetitive?
da
nu
Atomizarea atributelor
Reletia R are cheie
primara?
da nu
1FN
Exista DF
partiale?
Atomizarea atributelor
Descompunerea n relatii
ce au cheie primara
da
2FN
nu
1
10








































Fig. 4.4 Etapele clasice ale normalizarii bazelor de date relationale
1
Exista DF
tranzitive?
da
nu
Aducerea relatiilor n 3FN
Toti determinantii
sunt chei candidate?
da nu
BCFN
Exista DF
multivaloare?
Aducerea relatiilor n 4FN
Aducerea relatiilor n
BCFN
da
4FN
nu
3FN
da
Exista dependente
de jonctiune ?
Aducerea relatiilor n 5FN
5FN
nu
11

Concluzionnd, o relatie este ntr-o forma normala daca satisface o multime de constrngeri
specificata n figura 4.5. De exemplu, se spune ca o relatie se afla n a doua forma normala 2FN daca si
numai daca se afla n 1FN.

Fig. 4.5. Formele normale ale relatiilor dintr-o BDR
Normalizarea bazei de date relationale poate fi imaginata ca un proces prin care pornindu-se de la
relatia initiala/universala R se realizeaza descompunerea succesiva a acesteia n subrelatii, aplicnd
operatorul de proiectie. Relatia R poate fi ulterior reconstruita din cele n relatii obtinute n urma
normalizarii, prin operatii de jonctiune.
4.5.2. Prima forma normala (1FN)
1FN este strns legata de notiunea de atomicitate a atributelor unei relatii. Astfel, aducerea unei
relatii n 1FN presupune introducerea notiunilor de:
? atribut simplu;
? atribut compus;
? grupuri repetitive de atribute.

? Atributul simplu- Atribut compus
Prin atribut simplu (atribut atomic) se ntelege un atribut care nu mai poate fi descompus n alte
atribute, n caz contrar, atributul este compus (atribut neatomic).
Exemplu: Urmatoarele exemple de atribute pot fi considerate simple sau compuse n functie de
circumstante si de obiectivele bazei de date.
? Data calendaristica este un atribut n care apar cmpurile: zi, luna, an;
? Adresa este un atribut n care apar cmpurile: strada, nr, bloc, scara, etaj, apartament, localitate,
judet;
? Data operatiunii bancare este un atribut n care apar cmpurile data, ora;
? Buletin/carte identitate este un atribut n care apar cmpurile: seria, nr.
Relatia universala
1FN
2FN
3FN
BCFN
4FN
5FN
12

Aceste atribute pot fi atomice sau neatomice. Astfel adresa clientilor agentiei imobiliare
intereseaza la nivel global, pe cnd pentru adresa ofertei sau a cererii de imobile este vitala prelucrarea
separata a fiecarui cmp considerat.
Analog, atributul nume reprezenta un atribut simplu al acestei baze de date, deoarece numele
clientului intereseaza la nivel global.
? Grupuri repetitive de atribute
Un grup repetitiv este un atribut (grup de atribute) dintr-o relatie care apare cu valori multiple
pentru o singura aparitie a cheii primare a relatiei nenormalizate.
Exemplu: Fie relatia nenormalizata (primara) FACTURI. Dorim sa stabilim o structura de tabele care sa
permita stocarea informatiilor continute n document (factura) si obtinerea unor situatii sintetice privind
evidenta sumelor facturate pe produse, pe clineti, pe anumite perioade de timp.












Fig. 4.6. Relatia FACTURI nenormalizata

n cazul n care o factura contine mai multe produse, relatia de mai sus va avea grupurile
repetitive: cod_produs, denumire_produs, cantitate, pret_unitar, valoare, valoare_tva.

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
total_valoare_factura
total_valoare_tva

13

Aducerea unei relatii universale la 1FN
1FN este tratata n general cu superficialitate, deoarece principala cerinta atomicitatea valorilor
este usor de ndeplinit (cel putin la prima vedere).
Dintre toate formele normale, doar 1FN are caracter de obligativitate. Se spune ca o baza de date
este normalizata daca toate relatiile se afla macar n 1FN.
O relatie este n 1FN daca domeniile pe care sunt definite atributele relatiei sunt constituite
numai din valori atomice. Un tuplu nu trebuie sa contina atribute sau grupuri de atribute repetitive.
Aducerea relatiilor n 1FN presupune eliminarea atributelor compuse si a celor repetitive.
Se cunosc trei solutii pentru determinarea grupurilor repetitive:
? eliminarea grupurilor repetitive pe orizontala (n relatia R initiala, n locul atributelo r compuse se
trec componentele acestora, ca atribute simple);
? eliminarea grupurilor repetitive prin adaugarea de tupluri;
? eliminarea grupurilor repetitive prin construirea de noi relatii
Primele doua metode genereaza relatii stufoase prin duplicarea fortata a unor atribute, respectiv
tupluri, crendu-se astfel redundante masive cu multiple anomalii de actualizare.
Metoda a treia presupune eliminarea grupurilor repetitive prin construirea de noi relatii, ceea ce
genereaza o structura ce ofera cel mai mic volum de redundanta.
Etapele de aducere a unei relatii n 1FN

sunt:
1. se construieste cte o relatie pentru fiecare grup repetitiv;
2. n schema fiecarei noi relatii obtinute la pasul 1 se introduce si cheia primara a relatiei R
nenormalizate;
3. cheia primara a fiecarei noi relatii va fi compusa din atributele chei ale relatiei R, plus unul
sau mai multe atribute proprii.

Exemplu: Deoarece o factura poate avea unul sau mai multe produse nscrise pe aceasta, informatiile
legate de produse vor fi separate ntr-o alta tabela. Aplicnd etapele de aducere la 1FN, se obtin doua
relatii:












Fig. 4.7. Relatia FACTURI adusa n forma normala 1FN

FACTURI
nr_factura#
data_factura
nume_client
adresa_client
banca_client
nr_cont_client
delegat
total_valoare_factura
total_valoare_tva

LINII_FACTURI
nr_factura#
cod_produs#
denumire_produs
unitate_de_masura
cantiate
pret_unitar
valoare
valoare_tva


14

Observatia1:
Cmpul adresa_client curpinde informatii despre judetul, localitatea, strada si numarul
domicililului clientului. Daca se considera ca este de interes o evidenta a sumelor factorizate pe judete
sau localitati, se vor pune n locul cmpului adresa_client trei cmpuri distincte: judet_client,
localitate_client, adresa_client, usurnd n acest fel interogarile.
Observatia2:
ntre tabela FACTURI si tabela LINII_FACTURI exista o relatie de unu la multi, adica unui
numar unic de factura i pot corespunde unul sau mai multe produse care sunt memorate ca nregistrari
n tabele LINII_FACTURI. Cheia primara n aceasta tabela este o cheie compusa, formata din doua
cmpuri: nr_factura si cod_produs.
Eliminarea grupurilor repetitive, adica aducerea unei relatii la 1FN, nu rezolva complet problema
normalizarii.
4.5.3. A doua forma normala (2FN)

2FN este strns legata de notiunea de dependenta functionala.
O relatie se afla n a doua forma normala 2FN daca:
1. se afla n forma normala 1FN si
2. fiecare atribut care nu este cheie este dependent de ntreaga cheie primara.
Etapele de aducere a unei relatii de la 1FN la 2FN sunt:
I. Se identifica posibila cheie primara a relatiei aflate n 1FN;
II. Se identifica toate dependentele dintre atributele relatiei, cu exceptia acelora n care sursa este un
atribut component al cheii primare;
III. Se identifica toate dependentele care au ca sursa un atribut sau subansamblu de atribute din cheia
primara;
IV. Pentru fiecare atribut (sau subansamblu) al cheii de la pasul III se creeaza o relatie care va avea
cheia primara atributul (subansamblul) respectiv, iar celelalte atribute vor fi cele care apar ca
destinatie n dependentele de la etapa III.

Exemplu:
Relatia care contine date redundante (de exemplu, modificarea denumirii unui produs atrage
dupa sine modificarea n fiecare tuplu n care apare acest produs) este relatia LINII_FACTURI. Se
observa ca nu exista nici o dependenta functionala ntre atributele necomponente ale cheii. n schimb,
toate atributele care nu intra n alcatuirea 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 formeaza nca doua relatii.






15















Fig. 4.8. Relatia FACTURI n a doua forma normala 2FN

Chiar daca au fost eliminate o parte din redundante, mai ramn si alte redundante ce se vor
elimina aplicnd alte forme normale.
4.5.4. A treia forma normala (3FN)

O relatie este n forma normala trei 3FN daca:
1. se gaseste n 2FN si
2. fiecare atribut care nu este cheie (nu participa la o cheie) depinde direct de cheia primara.
A treia regula de normalizare cere ca toate cmpurile din tabele sa fie independente ntre ele.
Etapele de aducere a unei relatii de la 2FN la 3FN sunt:
I. Se identifica toate atributele ce nu fac parte din cheia primara si sunt surse ale unor dependente
functionale;
II. Pentru aceste atribute, se construieste cte o relatie n care cheia primara va fi atributul respectiv,
iar celelalte atribute, destinatiile din DF considerate;
III. Din relatia de la care s-a pornit se elimina atributele destinatie din DF identificata la pasul I,
pastrndu-se atributele surse.

Exemplu:
n relatia FACTURI se observa ca atributul nume_client determina n mod unic atributele
adresa_client, banca_client si nr_cont_client. Deci pentru atributul nume_client se construieste
o relatie CLIENTI n care cheia primara va fi acest atribut, iar celelalte atribute vor fi adresa_client,
banca_client si nr_cont_client. Cmpurile valoare si valoare_tva depind de cmpurile
cantitate, pret_unitar, si de un procent fix de TVA. Fiind cmpuri ce se pot calcula n orice moment
ele vor fi eliminate din tabela LINII FACTURI deoarece constituie informatie memorata redundant.


FACTURI

nr_factura#
data_factura
nume_client
adresa_client
banca_client
nr_cont_client
delegat
total_valoare_factura
total_valoare_tva

LINII_FACTURI

nr_factura#
cod_produs#
cantiate
pret_unitar
valoare
valoare_tva

PRODUSE

cod_produs#
denumire_produs
unitate_de_masura

16











Fig. 4.9. Relatia FACTURI n a treia forma normala 3FN

Observatia 1:
Aceasta a treia forma normala mai poate suferi o serie de rafinari pentru a putea obtine o
structura performanta de tabele ale bazei de date. De exemplu se observa ca nume_client este un cmp
n care este nscris un text destul de lung format dintr-o succesiune de litere, semne speciale (punct,
virgula, cratima), spatii, numere. Ordonarea si regasirea informatiilor dupa astfel de cmpuri este lenta
si mai greoaie dect dupa cmpuri numerice. Din acest motiv se poate introduce un nou atribut
cod_client care sa fie numeric si care sa fie cheia primara de identificare a pentru fiecare client.
Observatia 2:
O alta observatie care poate fi facuta n legatura cu tabelele aflate n cea de a treia forma normala
este aceea ca total_valoare_factura este un cmp care ar trebui sa contina informatii sintetice obtinute
prin nsumarea valorii tuturor ofertelor aflate pe o factura. Este de preferat ca astfel de cmpuri sa fie
calculate n rapoarte sau interogari si sa nu fie memorate n tabelele bazei de date.









Fig. 4.9. Relatia FACTURI n a treia forma normala 3FN (modificata)

Verificarea aplicarii corecte a procesului de normalizare se realizeaza astfel nct uniunea
acestora sa produca relatia initiala, cu alte cuvinte, descompunerea este fara pierderi.
Celelalte forme normale se ntlnesc mai rar n practica. Aceste forme nu sunt respectate, n
general, pentru ca beneficiile de eficienta pe care le aduc nu compenseaza costul si munca de care este
nevoie pentru a le respecta.
FACTURI

nr_factura#
data_factura
nume_client
delegat
total_valoare_factura
total_valoare_tva

LINII_FACTURI

nr_factura#
cod_produs#
cantiate
pret_unitar

PRODUSE

cod_produs#
denumire_produs
unitate_de_masura

CLIENTI

nume_client#
adresa_client
banca_client
nr_cont_client

FACTURI

nr_factura#
data_factura
delegat

LINII_FACTURI

nr_factura#
cod_produs#
cantiate
pret_unitar
PRODUSE

cod_produs#
denumire_produs
unitate_de_masura

CLIENTI

cod_client#
nume_client
adresa_client
banca_client
nr_cont_client