Capitolul 6.

Normalizarea

Normalizarea este un proces dezvoltat în conjuncţie cu modelul de date

relaţional, cu toate că ea este aplicabilă modelării logice a datelor în general.
Ea poate fi utilă în răspunsul la două întrebări majore despre date: “Ce
înseamnă o proiectare bună de bază de date logică?” şi “Ce înseamnă o
proiectare bună de bază de date fizică?”.

6.1. Obiective

Normalizarea relaţională este un proces pentru identificarea grupărilor de

atribute stabile, cu o mare interdependenţă şi afinitate. Normalizarea
incorporează principiile modelării semantice a datelor şi dă proiectări
extensive de baze de date logice. Ea poate conduce, de asemenea, la
proiectări flexibile de baze de date fizice, păstrând separate consideraţiile
fizice şi logice.

6.2. Dependenţe

Normalizarea se bazează pe conceptele de dependenţe între atribute şi ea

impune un set de reguli guvernând structura semnificaţiei datelor. Aceste
reguli, bazate pe condiţii de dependenţă, ajută la stabilizarea definiţiilor
semnificaţiilor şi prezic reprezentările faptelor. Cele mai importante două
tipuri de dependenţe de atribute sunt, pentru scopurile noastre, dependenţa
funcţională şi dependenţa multivalorică.
Dependenţa funcţională. Să considerăm următoarea relaţie:
PROFESOR (NUME_POFESOR, MARCA#, FUNCTIE,
NUME_CATEDRA, NUME_FACULTATE, TELEFON, DATA_NASTERII,
DATA_ANGAJARII);
Să presupunem că fiecare valoare MARCA# este asociată cu una şi
numai cu o valoare a lui DATA_NASTERII. Dar, deoarece doi profesori pot
avea exact aceeaşi zi de naştere, fiecare valoare DATA_NASTERII poate fi
asociată cu mai mult de o valoare MARCA#. DATA_NASTERII se spune
atunci a fi dependent funcţional de MARCA#. Aceasta se notează, uneori:
MARCA#  DATA_NASTERII
şi se citeşte “MARCA# determină funcţional DATA_NASTERII”.
Să considerăm relaţia R cu atributele A şi B. Atributul B se spune a
fi dependent funcţional de atributul A dacă şi numai dacă fiecare valoare a lui

93
A în liniile lui R are asociată cu ea la un moment dat fix o valoare a lui B în
R. Adică:
 liniile lui R cu o valoare dată pentru A, trebuie să aibă toate aceaşi valoare
pentru B.
 atunci când două linii ale lui R au aceaşi valoare a lui B, ele nu trebuie să
aibă aceaşi valoare pentru A.
Dependenţă multivalorică. Să considerăm relaţia
RESPONSABILITATE (MARCA#, CURS#, NUME_COMITET);
Să presupunem că fiecare valoare MARCA# are asociate cu ea una sau mai
multe valori CURS#. Mulţimea valorilor CURS# asociate cu o valoare
MARCA# dată este, totuşi aceeaşi pentru oricare COMITET# care este de
asemenea asociat cu acea MARCA#.
Să presupunem că MARCA# = 12345 apare în trei linii în relaţia
RESPONSABILITATE, cu valorile CURS#: 100. 200 şi 300. Pentru a
adăuga că MARCA# serveşte COMITET# = 12 ar cere ca trei linii
MARCA#, CURS#, NUME_COMITET să fie adăugate relaţiei
RESPONSABILITATE:
12345, 100, 12
12345, 200, 12
12345, 300, 12
Mulţimea valorilor CURS# asociate cu o valoare MARCA# dată
(aici 12345) trebuie să fie exact aceaşi pentru orice valoare COMITET#.
Astfel COMITET# = 12 nu poate apare cu MARCA# = 12345 şi numai cu
una din valorile CURS# din mulţimea {100, 200, 300}.
CURS# se spune a fi dependent multivaloric de MARCA#, şi se
notează:
MARCA#  CURS#
şi citim “MARCA# determină multivaloric CURS#”.
Să considerăm acum relaţia R cu atributele A, B şi C. Atributul B se
spune a fi dependent multivaloric de atributul A dacă şi numai dacă mulţimea
valorilor lui B în R care se potrivesc cu o pereche de valori <A, C> în R este
independentă de valoarea lui C. Adică, următoarele sunt adevărate:
 nu toate liniile lui R cu o valoare dată a lui A trebuie să aibă aceeaşi
valoare a lui B (B-valorile din aceste linii sunt referite ca “mulţimea B-
valorilor determinate de A-valoare”);
 ori de câte ori două linii ale relaţiei R au aceaşi valori pentru A, ele nu
trebuie să aibă aceeaşi valori pentru B, dar valorile lor pentru B trebuie să
fie elemente ale mulţimii de valori determinate de valoarea lui A;
 schimbarea valorii lui C într-o linie a lui R nu poate afecta valoarea lui B
în acea linie;
 când două linii ale relaţiei R au aceaşi valori pentru B, ele nu trebuie să
aibă în mod necesar aceleaşi valori pentru A;

94
 să considerăm două valori ale lui C, C1 şi C2. Mulţimea valorilor lui B în
liniile lui R cu o valoare dată pentru A şi cu C-valoarea C1 trebuie să fie
exact aceeaşi ca şi mulţimea valorilor lui B în liniile lui R cu aceeaşi A-
valoare şi cu C-valoarea C2.

6.3. Prima formă normală

Teoria relaţională foloseşte termenul de forme normale pentru a descrie

extinderea la care au fost grupate atributele în relaţii stabile. Au fost propuse
numeroase forme normale, fiecare încercând să obţină o grupare de atribute
cât mai stabilă. Interesul nostru se restrânge la şase forme normale - primele
cinci purtând numere de ordine şi forma normală Boyce/Codd.
O relaţie este în prima formă normală (1NF) dacă şi numai dacă
fiecare atribut din fiecare linie poate conţine numai o singură valoare.
O relaţie nu poate avea nici o linie care conţine un grup repetitiv de
valori de atribut.
Să considerăm relaţia:

FACULTATE_1 (NUME_PROFESOR, MARCA#, NUME_STUDENT, MATRIC#,

NUME_CATEDRA, CURS#, TEXT, GRAD, COMITET#, ZI_INTILNIRE.
ORA_INTILNIRE);

Nu este posibil să determinăm dacă această relaţie este în 1NF fără a

verifica o tabelă de instanţe sau a răspunde la întrebarea: Pentru o linie dată
din această relaţie, pot exista valori multiple pentru un atribut? O tabelă de
instanţe pentru relaţia FACULTATE_1 este dată în fig.6.1. Relaţia nu este în
1NF căci există mai multe valori pentru NUME_STUDENT (şi pentru alte
atribute de asemenea) în linia cu MATRIC# = 12751.

Producerea lui 1NF. Pentru a normaliza o relaţie în forma 1NF este necesar
să “netezim” liniile, astfel încât nici o linie să nu conţină atribute care se
repetă. Fig.6.2. dă o tabelă de instanţe pentru relaţia FACULTATE_1,
modificată pentru a fi 1NF. Să notăm că schema relaţiei nu s-a modificat.
Cheia primară pentru relaţia exemplu este MARCA#, NUME_CATEDRA,
CURS#, MATRIC# şi toate patru atribute sunt necesare pentru a identifica
liniile.
Obiectivele lui 1NF. Cele două raţiuni principale sunt că semantica
unei relaţii 1NF este mai explicită - nici un atribut nu poate avea mai mult de
o valoare în orice linie dată – şi pentru a folosi relaţii 1NF în loc de relaţii
nenormalizate că operatorii relaţionali sunt aplicabili relaţiilor plate, adică
1NF. Schema unei relaţii nenormalizate nu permite stabilirea atributelor cu
valori multiple. Pe de altă parte, cunoscând că o relaţie este în 1NF ştim că
nici un atribut nu poate avea valori multiple.

95
6.4. A doua formă normală

O relaţie este în a doua formă normală (2NF) dacă şi numai dacă ea este în
1NF şi orice atribut non cheie este dependent funcţional complet de cheia
primară. Adică, o relaţie 2NF nu poate avea un atribut care este dependent
funcţional numai de o parte a cheii primare.
Nu este posibil a stabili dacă o relaţie este în 2NF pe baza schemei
ei; cunoaşterea dependenţelor funcţionale existente fiind de asemenea
necesară. Să considerăm din nou relaţia FACULTATE_1, care este acum în
1NF:

FACULTATE_1 (NUME_PROFESOR, MARCA#, NUME_STUDENT, MATRIC#,

NUME_CATEDRA, CURS#, TEXT, GRAD, COMITET#, ZI_INTILNIRE.
ORA_INTILNIRE);
Să presupunem că au loc următoarele dependenţe funcţionale:
MARCA#  NUME_PROFESOR
MARCA#  COMITET#
MARCA#  NUME_CATEDRA, CURS#
MARCA#  ZI_INTILNIRE
MARCA#  ORA_INTILNIRE
MATRIC#  NUME_STUDENT
MATRIC#, NUME_CATEDRA, CURS#  GRAD
NUME_CATEDRA, CURS#  TEXT

Putem acum determina că relaţia FACULTATE_1 nu este în 2NF,

deoarece există atribute non cheie care nu sunt determinate de întreaga cheie
primară. De exemplu:
NUME_PROFESOR este dependent funcţional de numai o parte a cheii:
MARCA#.
NUME_STUDENT este dependent funcţional de numai o parte a cheii:
MATRIC#.
GRAD este dependent funcţional de numai o parte a cheii: MATRIC#,
NUME_CATEDRA, CURS#.
TEXT este dependent funcţional de numai o parte a cheii:
NUME_CATEDRA, CURS#.
Producerea 2NF. O relaţie poate fi rezolvată în 2NF impărţind-o în
relaţii componente, fiecare satisfăcând condiţia 2NF. Relaţia R (A, B, C, D)
cu dependenţele:
AC
A, B  D
poate fi separată în două relaţii:
R1 (A, C);
R2 (A, B, D);

96
97
 FACULTATE_1
NUME_ MARCA# NUME_ MATRIC# NUME_ CURS TEXT GRAD COMITET# ZI_ ORA_
PROF. STUDENT CATEDRA INTILNIRE INTILNIRE
Luca 12751 Albu 469213 IT 231 Unu A 12 L 9
Barbu 532162 IT 231 Unu B 20 J 8
Tatu 112146 MF 201 Doi B
Matei 21936 Albu 469213 EG 512 Patru A   
Novac 51326 Sandu 513251 IT 531 Unu A 12 L 9
20 J 8
18 J 9
Oprea 31962 Cociu 219623 MF 200 Doi A 5 V 8
Lupu 319216 EG 512 Patru B
Fig.6.1. Tabela de instanţe pentru relaţia FACULTATE_1.
FACULTATE_1
NUME_ MARCA# NUME_ MATRIC# NUME_ CURS TEXT GRAD COMITET# ZI_ ORA_
PROF. STUDENT CATEDRA INTILNIRE INTILNIRE
Luca 12751 Albu 469213 IT 231 Unu A 12 L 9
Luca 12751 Barbu 532162 IT 231 Unu B 20 J 8
Luca 12751 Tatu 112146 MF 201 Doi B 20 J 8
Matei 21936 Albu 469213 EG 512 Patru A   
Novac 51326 Sandu 513251 IT 531 Unu A 12 L 9
Novac 51326 Sandu 513251 IT 531 Unu A 20 J 8
Novac 51326 Sandu 513251 IT 531 Unu A 18 J 9
Oprea 31962 Cociu 219623 MF 200 Doi A 5 V 8
Oprea 31962 Lupu 319216 EG 512 Patru B 5 V 8
Fig.6.2. Tabela de instanţe pentru relaţia FACULTATE_1 în 1NF.

97
 Rezolvarea relaţiei FACULTATE_1 dă următoarele patru relaţii:
FACULTATE_2 (MARCA#, NUME_PROFESOR, COMITET#, ZI_INTILNIRE,
ORA_INTILNIRE, NUME_CATEDRA, CURS#);
STUDENT (MATRIC#, NUME_STUDENT);
CURS_STUDENT (NUME_CATEDRA, CURS#, MATRIC#, GRAD);
CURS (NUME_CATEDRA, CURS#, TEXT);
În toate relaţiile, toate atributele non cheie sunt dependente de
întreaga cheie primară. Să notăm că NUME_CATEDRA , CURS# este un
atribut cheie străină compusă în FACULTATE_2 , care arată o relaţie unu-la-
mai-mulţi între CURS şi FACULTATE_2. Ea este de asemenea un atribut
cheie străină compusă în relaţia CURS_STUDENT. CURS_STUDENT are
un alt atribut cheie străină, MATRIC#, care arată o relaţie unu-la-mai-mulţi şi
între STUDENT şi CURS_STUDENT. Fig.6.3. este o diagramă model de
date pentru relaţia FACULTATE_1 iar fig.6.4. este o diagramă model de date
pentru mulţimea de relaţii 2NF rezultate din rezolvarea în 2NF a lui
FACULTATE_1.
O relaţie 1NF cu o cheie dintr-un singur atribut este întotdeuna în
2NF. Atributul respectiv fiind cheia primară, nu vor putea exista două linii
ale relaţiei pentru care atributul respectiv să aibă aceaşi valoare, ca atare orice
alt atribut va fi dependent funcţional de acesta.

Facultate_1

Marca#
Matric#
Nume_catedră
Curs#

Nume_profesor
Nume_student(0)
Text(0)
Grad(0)
Comitet#(0)
Zi_întâlnire(0)
Ora_întâlnire(0)

Fig.6.3. Model de date logic corespunzător lui FACULTATE_1 (în forma

din 1NF).

Obiectivele lui 2NF. Cele două raţiuni pentru a folosi relaţii 2NF în
loc de relaţii 1NF sunt:

98
 semantica unei relaţii 2NF este mai explicită - toate atributele sunt
dependente de întreaga cheie primară;
 o bază de date proiectată cu relaţii 2NF ca evita anumite anomalii de
actualizare prezente în relaţiile 1NF.
Schema unei relaţii 1NF nu permite stabilirea dependenţelor funcţionale
dintre atribute. Pe de altă parte, cunoscând că o relaţie este în 2NF ştim că
orice atribut non cheie este dependent de întreaga cheie. Actualizarea faptelor
într-o relaţie 1NF poate cauza anomalii care nu apar în cazul 2NF. Aceste
situaţii pot apare atunci când se inserează noi linii, se şterg linii sau se
modifică linii.

Curs Student
Nume_catedră Matric#
Curs#
Nume_student
a înrolat
Z Text
este
predat
ia
de

Facultate_2 Curs_student
Marca# Nume_catedră(Fk,0)
Curs#(Fk)
Nume_profesor Matric#(Fk)
Comitet#(0)
Zi_întâlnire(0) Grad
Ora_întâlnire(0)
Nume_catedră(Fk,0)
Curs#(Fk,0)

Fig.6.4. Model de date logic a lui FACULTATE_1 normalizat în 2NF.

Să considerăm din nou relaţia FACULTATE_1, care este în 1NF.

Nu este posibilă inserarea unei noi linii pentru un profesor care încă nu are
studenţi înscrişi la cursul pe care îl predă. MATRIC# este o parte a cheii
prmare şi deci nu poate avea valoare nulă. Similar, o linie pentru un student
nou nu poate fi inserată până când acesta nu s-a înscris la un curs.
Dacă o linie din relaţia FACULTATE_1 pentru un profesor dat se
şterge şi ea este singura linie pentru un anumit student, informaţia despre
acesta va fi de asemenea pierdută, chiar dacă intenţia a fost ştergerea
informaţiei despre profesor. Un MATRIC# nu poate exista în relaţie fără a fi

99
asociat cu un MARCA#, NUME_CATEDRA şi CURS#, deoarece toate
aceste patru atribute formează cheia primară. Dacă este necesar să modificăm
numele unui student, atunci orice linie din FACULTATE_1 în care apare
numele studentului trebuie să fie modificată, altfel relaţia va conţine date
contradictorii. Studentul poate apare în mai multe linii, deoarece el poate lua
mai multe cursuri. Spărgând relaţia FACULTATE_1 în FACULTATE_2 şi
STUDENT evităm aceste probleme.
Argrumente similare pot fi aduse pentru spargerea în relaţiile
CURS_STUDENT şi CURS.

6.5. A treia formă normală

O relaţie este în a treia formă normală (3NF) dacă şi numai dacă ea este în a
doua formă normală şi nici un atribut non cheie nu este dependent tranzitiv
de cheia primară. Adică, o relaţie 3NF nu poate avea nici un atribut non cheie
dependent de un alt atribut non chie.
De exemplu, relaţia precedentă

FACULTATE_2 (MARCA#, NUME_PROFESOR, COMITET#, ZI_INTILNIRE,

ORA_INTILNIRE, NUME_CATEDRA, CURS#);

nu este în 3NF dacă au loc următoarele dependenţe funcţionale în plus faţă de

cele deja introduse:
COMITET#  ZI_INTILNIRE
COMITET#  ORA_INTILNIRE
Două din atributele non cheie (ZI_INTILNIRE, ORA_INTILNIRE)
sunt dependente de alte atribute non cheie (COMITET#). Să presupuem că
celelalte atribute non cheie nu sunt interdependente.

Producerea 3NF. O relaţie poate fi rezolvată în 3NF împărţind-o în

relaţii componente, fiecare satisfăcând condiţia de 3NF. Relaţia R (A, B, C)
cu dependenţele:
AB BC AC
poate fi divizată în două relaţii:
R1 (A, B)
R2 (B, C)
Rezolvarea relaţiei FACULTATE_2 dă următoarele două relaţii:
COMITET (COMITET#, ZI_INTILNIRE, ORA_INTILNIRE);
FACULTATE_3 (MARCA#, NUME_PROFESOR, COMITET#,
NUME_CATEDRA, CURS#);
Să notăm că atributul COMITET# a fost reţinut în relaţia FACULTATE_3; el
este un atribut cheie străină pentru relaţia COMITET. Fără COMITET# în
relaţia FACULTATE_3 nu este posibilă stabilirea comitetului asignat unui
profesor. Fig.6.5. prezintă un model pentru mulţimea rezultată de relaţii 3NF.

100
 Comitet Student
Comitet# Nume_catedră Matric#
Curs#
Z a înrolat
Zi_întâlnire Z Text Nume_student
Ora_întâlnire
este
predat ia
de
este compus
din Facultate_3 Curs_student
Marca# Nume_catedră(Fk,0)
Curs#(Fk)
Nume_profesor Matric#(Fk)
Comitet#(Fk,0)
Nume_catedrã(Fk,0) Grad
Curs#(Fk,0)

Fig.6.5. Model de date logic normalizat în 3NF.

101
 O relaţie 2NF cu numai un atribut non cheie (sau cu nici unul) este
întotdeuna o relaţie 3NF. Nici un atribut non cheie nu poate fi dependent de
un altul dacă nu există cel puţin două atribute non cheie în relaţie.

Obiectivele lui 3NF. Cele două raţiuni principale pentru folosirea

de relaţii 3NF în locul celor 2NF sunt:
 semantica unei relaţii 3NF este mult mai explicită - toate atributele sunt
dependente numai de cheia primară;
 baza de date proiectată cu relaţii 3NF va evita numite anomalii de
actualizare prezente la relaţii 2NF.
Schema unei relaţii 2NF nu specifică dacă atribute non cheie sunt dependente
de alte atribute non cheie. De pe altă aprte, cunoscând faptul că o relaţie este
în forma 3NF ştim că nici un atribut non cheie nu este dependent de un alt
atribut non cheie.
Anumite situaţii de anomalie apar la actualizarea unor fapte într-o
relaţie 2NF şi sunt evitate în cazul relaţiilor 3NF. Acestea apar atunci când se
inserează linii noi, se şterg linii sau se modifică linii în anumite condiţii şi
sunt aproape similare cu anomaliile care apar în actualizarea relaţiilor 1NF.
Să considerăm relaţia FACULTATE_2 care este 2NF. Nu este
posibilă inserarea unor informaţii despre ziua şi ora întâlnirii unui nou
comitet până când nu există profesori asignaţi acestui comitet; adică, datele
despre comitete nu pot exista fără a avea o marcă asociată.
Dacă o linie FACULTATE_2 pentru un profesor dat este ştearsă şi
se întâmplă ca ea să fie singura linie pentru un anumit comitet, atunci datele
despre acel comitet se vor peirde, chiar dacă intenţia a fost acea de a şterge
date despre profesor. Aceasta are loc deoarece un comitet nu poate exista fără
a avea o MARCA# asociată.
Dacă este necesară schimbarea orei de întâlnire a unui comitet, orice
linie din FACULTATE_2 în care acest comitet apare va trebui modificată,
altfel relaţia va conţine date contradictorii. Comitetul poate apare în mai
multe linii, deoarece mai mulţi profesori pot fi asignaţi la el. Spărgând relaţia
FACULTATE_2 în relaţiile FACULTATE_3 şi COMITET evităm aceste
probleme.

6.6. Forma normală Boyce-Codd

Forma normală Boyce-Codd BCNF este o variantă a lui 3NF, luând în

considerare şi posibila existenţă a unor chei candidate. Nu toate relaţiile
aflate în BCNF sunt în 3NF şi nu toate relaţiile din 3NF se află în BCNF.
Totuşi BCNF este considerată mai puternică prin adecvarea mai bună la
situaţiile reale.
Un atribut sau un set de atribute de care este complet dependent
funcţional un alt atribut se numeşte determinant. O relaţie este în BCNF dacă
şi numai dacă fiecare determinant este o cheie candidată. BCNF diferă de

102
3NF în aceea că ea cere o dependenţă funcţională completă pentru fiecare
cheie candidată, pe când 3NF cere o astfel de dependenţă numai pentru cheia
primară. Regulile sunt echivalente, dacă relaţia nu are mai multe chei
candidate.
Relaţiile COMITET şi FACULTATE_3 sunt ambele atât în 3NF cât
şi în BCNF, cu mulţimea dependenţelor funcţionale propusă. Dacă însă se
introduce şi NUME_PROFESOR ca şi cheie candidată pentru relaţia
FACULTATE_3, aceasta nu mai este în 3NF. COMITET#,
NUME_CATEDRA şi CURS# sunt determinate de un atribut non cheie
NUME_PROFESOR ca şi de cheia primară MARCA#. BCNF potriveşte
această anomalie, deoarece NUME_PROFESOR este o cheie candidată.
Să considerăm, de asemenea, următoarea relaţie:
DEALER (ORAS, MASINA, NUME_DEALER);
cu dependenţele:
NUME_DEALER  ORAS Fiecare dealer este într-un singur oras.
MASINA, ORAS  NUME_DEALER Pentru fiecare oras şi fiecare masină
există un singur dealer autorizat.
Să presupunem că fiecare maşină poate fi vândută în mai multe
oraşe şi că fiecare oraş poate avea mai mulţi dealer-i autorizaţi.
Cheile candidate sunt ORAS, MASINA şi MASINA,
NUME_DEALER.
Următoarea tabelă arată dependenţa atributelor:

ORAS MASINA NUME_DEALER

Arad Dacia Ionescu
Oradea Dacia Popescu
Arad Aro Ionescu
Oradea Aro Iliescu

Relaţia DEALER nu este în BCNF deoarece NUME_DEALER este

un determinant dar nu este o cheie candidată.
Producerea BCNF. Dacă o relaţie dată are mai multe chei
candidate care coincid în parte în atributele lor, atunci ea trebuie să fie
descompusă pentru a ajunge BCNF.
Două chei candidate coincid în parte atunci când ambele sunt
compuse şi partajează cel puţin un atribut.
Relaţia R (A, B, C) cu dependenţele:
A, B  C
CB
şi cheile candidate A, B, C poate fi descompusă în relaţiile R1 (B, C) şi R2
(A, C). Rezolvând astfel relaţia DEALER, obţinem:
LOC_DEALER (NUME_DEALER, ORAS);
PRODUS (NUME_DEALER, MASINA);

103
 O relaţie 3NF cu o singură cheie candidată (care este ca atare şi
cheia primară) este întotdeuna o relaţie BCNF.
O relaţie 3NF numai cu chei candidate care nu coincid în parte este
întotdeuna în BCNF.
Obiectivele lui BCNF. Cele două raţiuni principale pentru a folosi
relaţii BCNF în loc de relaţii 3NF sunt:
 semantica cheilor candidate multiple este mai explicită - toate atributele
sunt dependente numai de chei candidate;
 baza de date proiectată cu relaţii BCNF va evita anumite anomalii de
actualizare ce apar la relaţii 3NF.
Definirea tuturor cheilor candidate ale unei relaţii este importantă
atunci când se stabilesc aserţiuni de unicitate. Aceste aserţiuni ar putea fi
forţate atunci când se inserează, se şterg sau se modifică linii în relaţie. Toate
cheile candidate, şi nu numai cheia primară trebuie să aibă valori unice.
Există anomalii ce apar când se actualizează fapte într-o relaţie 3NF
şi pot fi evitate la relaţii BCNF. De exemplu, în relaţia DEALER, nu putem
şterge faptul că Dacia este vândută în Oradea. MASINA este parte a cheii.
Neconsiderând chei candidate ea este desemnată ca şi cheie primară. O
informaţie oraş şi o informaţie dealer nu pot exista fără informaţie maşină,
căci MASINA nu poate fi nul. Similar, nu este posibilă inserarea informaţiei
cum că “Milescu” este dealer la “Arad” fără a desemna şi MASINA.
Problema este că NUME_DEALER este un determinant, dar nu o cheie
candidată, astfel că relaţia nu este în BCNF. Nu există atribute non cheie
dependente de alte atribute non cheie (NUME_DEALER), atributul ORAS
dependent funcţional de NUME_DEALER fiind parte din cheie. Relaţia e
deci în 3NF. Spărgând relaţia în LOC_DEALER şi PRODUS vom evita
aceste probleme.

6.7.A patra formă normală

O relaţie este în a patra formă normală (4NF) dacă şi numai dacă ori de câte
ori există o dependenţă multivalorică de un determinant, toate atributele sunt
dependente funcţional de determinant.
O relaţie 4NF nu poate avea mai mult de o dependenţă
multivalorică.
De exemplu, să considerăm din nou relaţia
FACULTATE_3 (MARCA#, NUME_PROFESOR, COMITET#, NUME
_CATEDRA, CURS#);
Dependenţele indicau că un profesor este asignat unui singur comitet
şi predă un singur curs. Să schimbăm situaţia astfel încât un profesor să poată
fi asignat la mai multe comitete şi să predea mai multe cursuri, introducând
astfel două dependenţe multivalorice:
MARCA#  COMITET#
MARCA#  NUME_CATEDRA, CURS#

104
 Relaţia trebuie să aibă acum pentru cheia sa pe MARCA#,
COMITET#, NUME_CATEDRA, CURS#.
Relaţia nu este în 4NF, căci ea conţine mai mult de o dependenţă
multivalorică. De fapt ea nu este nici măcar în 2NF deoarece axistă un atribut
non cheie dependent de numai o parte a cheii.
Despărţind atributul care este dependent numai de MARCA# de
rest, obţinem două relaţii:
FACULTATE (MARCA#, NUME_PROFESOR)
FACULTATE_4 (MARCA#, COMITET#, NUME_DEPARTAMENT, CURS#);

FACULTATE este acum în 4NF, din următoarele motive:

 conţine numai atribute cu o singură valoare;
 fiecare atribut non cheie este dependent de întreaga cheie;
 nu există dependenţe între atribute non cheie;
 nu există dependenţe multivalorice.

FACULTATE_4 este în BCNF, dar nu este în 4NF. Dependenţele implică

faptul că mulţimea valorilor COMITET# asociate cu o valoare MARCA#
dată este total independentă de mulţimea valorilor NUME_CATEDRA,
CURS# asociate cu acea valoare MARCA#. NU există nici o dependenţă
între COMITET# şi NUME_CATEDRA, CURS#. Dacă nu ar fi aşa, nu ar fi
două dependenţe multivalorice.

Producerea 4NF. O relaţie ca aceasta poate fi rezolvată în 4NF prin

descompunere în relaţii care satisfac fiecare 4NF. Relaţia R (A, B, C) cu
dependenţele:
A  B
A  C
poate fi împărţită în două relaţii R1 (A, B) şi R2 (A, C).
Rezolvarea relaţiei FACULTATE_4 va duce la două relaţii:
FACULTATE_COMITET (MARCA#, COMITET#);
FACULTATE_CURS (MARCA#, NUME_DEPARTAMENT, CURS#);
Să notăm că MARCA# este un atribut cheie străină în ambele relaţii.
COMITET# este atribut cheie străină în FACULTATE_COMITET şi
NUME_CATEDRA, CURS# este atribut cheie străină compusă în
FACULTATE_CURS. Aceste atribute cheie străină reprezintă relaţiile de
conectare în mulţimea relaţiilor. Fig.6.6. prezintă un model de date pentru o
mulţime completă de relaţii 4NF.

105
 Marca#(Fk) Marca#(Fk) Nume_catedră(Fk)
Comitet#(Fk) Nume_catedrã(Fk) Curs#(Fk)
Curs#(Fk) Matric#(Fk)

Grad

Comitet Profesor_membru Curs Student

Comitet# Marca# Nume_departament# Matric#

Z Z Curs#
Zi_întâlnire Nume_student
Ora_întâlnire Nume_profesor Text

serveşte în este predat de a înrolat ia

este compus
din predã

Facultate_Comitet Facultate_Curs Curs_student

Fig.6.6. Model de date logice, normalizat în 4NF în cazul adăugării de dependenţe multivalorice

106
 Obiectivele lui 4NF. Cele două raţiuni principale pentru a prefera
relaţii 4NF în loc de relaţii BCNF sunt:
 semantica unei relaţii 4NF este mai explicită - toate dependenţele sunt
înlănţuite;
 o bază de date proiectată cu relaţii 4NF va evita anumite anomalii de
actualizare prezente în 3NF precum şi în BCNF.
Schema unei relaţii BCNF nu evidenţiază dependenţele
multivalorice şi nici dacă componentele cheii primare sunt mutual
independente. De pe altă parte, ştiind că o relaţie este în 4NF suntem
asiguraţi că nici o componentă a cheii nu este independentă de orice altă
componentă.
Să urmărim ce tipuri de anomalii ce pot apărea la actualizarea unei
relaţii BCNF sunt evitate în cazul relaţiilor 4NF. Aceste situaţii pot apărea
atât la inserarea de linii noi, la ştergerea de linii cât şi la modificarea unor
linii şi sunt similare cu anomaliile care le-am trecut în revistă în cazurile
1NF, 2NF şi 3NF.
Să considerăm relaţia FACULTATE_4, care este în BCNF. Să
presupunem că profesorul cu MARCA# = 12345 predă cinci cursuri şi
serveşte în patru comitete. Nu este posibilă inserarea unor date despre
asignarea profesorului la un alt comitet fără a insera cinci linii, câte una
pentru fiecare curs pe care profesorul numit îl predă. Aceleaşi valori
NUME_CATEDRA, CURS# trebuie să existe în relaţie pentru fiecare
valoare COMITET# asociată cu MARCA#. Dacă o asignare de comitet
pentru profesorul numit este ştearsă, atunci acea ştergere înseamnă în fapt
ştergerea a cinci linii, câte una pentru fiecare curs. Aceeaşi mulţime de valori
COMITET# trebuie să existe în relaţie pentru fiecare valoare
NUME_CATEDRA, CURS# asociate cu MARCA#. Dacă este necesară
schimbarea unui CURS# pentru un curs predat de profesorul respectiv, atunci
această schimbare trebuie să se reflecte în patre linii, câte una pentru fiecare
comitet pe care îl serveşte profesorul. Din nou, aceeaşi mulţime de valori
NUME_CATEDRA, CURS# trebuie să existe în relaţie pentru fiecare
valoare COMITET# asociată cu MARCA#. Spargerea relaţiei
FACULTATE_4 în relaţiile FACULTATE_COMITET şi
FACULTATE_CURS evită aceste probleme.

6.8. A cincea formă normală

O relaţie este în a cincea formă normală (5NF) dacă ea nu poate fi spartă în

relaţii mai mici şi apoi reunită fără a-şi schimba faptele şi semnificaţiile.
Ea este în forma ei cea mai elementară, reprezentându-şi datele
numai prin folosirea a câtorva atribute, cât mai puţine posibil.
O relaţie care este în 5NF este şi în 4NF.

107
 Deoarece proprietăţile lui 5NF par a fi neclare, vom explica această
ultimă formă normală pe baza unui exemplu mai extins. Să considerăm
relaţia:
PARADA_CAINI (JUDECATOR, RASA, EVENIMENT);
Această relaţie este în 5NF dacă ea nu poate fi descompusă fără
pierdere în:
ASIGNARE (JUDECATOR, RASA); INTRARE (RASA, EVENIMENT);
CALIFICARE (JUDECATOR, EVENIMENT);
Dacă relaţia iniţială nu era în 5NF, cele trei relaţii de mai sus se vor putea
reuni pentru a forma o relaţie cu trei atribute cu exact aceaşi tabelă de
instanţe ca şi cea a relaţiei PARADA_CAINI. Dacă PARADA_CAINI este în
5NF atunci cele trei atribute combinate sunt necesare pentru a exprima
semantici valide. Dacă este în 5NF, PARADA_CAINI poate fi interpretată
incluzând aserţiuni ca:
 o persoană este calificată pentru a juriza evenimente despre anumite rase;
 numai anumitor rase li se pot asigna anumite evenimente.
O tabelă de instanţe valide este dată în fig.6.7.

PARADA_CAINI
JUDECATOR RASA EVENIMENT
Albu Ciobanesc german Confirmatie
Albu Pudel Ascultare
Morar Ciobanesc german Ascultare
Morar Pudel Dresaj
Morar St.Bernard Dresaj
Petrisor Ciobanesc german Confirmatie
Vasiu Pudel Dresaj
Vasiu Pudel Ascultare

Fig.6.7. Tabela de instanţe pentru relaţia PARADA_CAINI

Albu poate judeca evenimentul confirmaţie pentru ciobănesc german

şi evenimentul ascultare pentru pudel dar nu este calificat să judece ascultare
pentru ciobanesc german sau confirmatie pentru pudel. Ciobanescul german
are intrare pentru evenimentele confirmatie şi ascultare, dar nu pentru dresaj.
Pe de altă parte, dacă relaţia PARADA_CAINI nu este în 5NF şi
poate fi descompusă în cele trei relaţii ASIGNARE, INTRARE şi
CALIFICARE şi apoi recombinată fără a-şi modifica semantica, aserţiunea
operativă va fi:
Dacă o persoană este calificată să judece un eveniment şi unei rase i
se permite să introducă un eveniment atunci persoana este calificată să judece
acea rasă în respectivul eveniment.
Tabelele de instanţe valide pentru relaţiile ASIGNARE, INTRARE
şi CALIFICARE şi rezultatul reuniunii acestor relaţii sunt date în tabelele din

108
fig.6.8. Să notăm diferenţele între relaţia combinată şi relaţia
PARADA_CAINI din fig.6.7. Modelele de date pentru aceste patru relaţii
sunt prezentate în fig.6.9.
O relaţie care este în 4NF şi are numai două atribute în cheia sa
primară este în 5NF deoarece nu există nici un mod de a o descompune fără a
pierde date.

ASIGNARE
JUDECATOR RASA
Albu Ciobanesc german
Albu Pudel
Morar Ciobanesc german
Morar Pudel
Morar St.Bernard
Petrisor Ciobanesc german
Vasiu Pudel

INTRARE
RASA EVENIMENT
Ciobanesc german Confirmatie
Ciobanesc german Ascultare
Pudel Ascultare
Pudel Dresaj
St.Bernard Dresaj

CALIFICARE
JUDECATOR EVENIMENT
Albu Confirmatie
Albu Ascultare
Morar Ascultare
Morar Dresaj
Petrisor Confirmatie
Vasiu Dresaj
Vasiu Ascultare

Fig. 6.8.a. Tabele de instanţe pentru trei relaţii binare proiectate din
PARADA_CAINI

Obiectivele lui 5NF. Există trei raţiuni principale pentru a prefera

relaţii 5NF în locul celor din 4NF.

109
 semantica lui 5NF este mai explicită - nu există dependenţe nelegate între
grupuri de atribute;
 o bază de date proiectată cu relaţii 5NF va evita anumite anomalii
prezente la relaţii 4NF;
 relaţiile 5NF sunt în forma cea mai granulară şi aceasta este un avantaj la
modificări ulterioare ale schemei.

Judecător Rasa

Nume_judecător Nume_rasa

poate judeca poate introduce

Parada_câini
Nume_judecător(Fk)
Nume_rasa(Fk)
Nume_eveniment(Fk)

poate avea

Eveniment
Nume_eveniment

Fig. 6.9.a

Există anomalii ce apar la actualizarea unor relaţii din 4NF care pot
fi evitate la relaţiile din 5NF. Ele apar atât la inserare de linii noi, cât şi la
ştergere sau modificare de linii şi sunt aproape similare cu cele de la formele
normale precedente. În relaţiile 4NF, anomaliile sunt cauzate de redundanţe
în tabela de instanţe a relaţiei.

110
Judecător Rasa Eveniment

Nume Nume Nume

judecător rasa eveniment

este poate
poate judeca poate avea
judecată introduce
de

Parada_câini Intrare
Nume_judecător(Fk) Nume_rasa(Fk)
Nume_rasa(Fk) Nume_eveniment(Fk)
Nume_eveniment(Fk)

Calificare

Nume_judecător(Fk)
Nume_eveniment(Fk) este
poate judecat
judeca de

Fig.6.9. Două modele de date logice reprezentând semantici diferite.

111
 “Reuniunea “ relaţiilor ASIGNARE, INTRARE, CALIFICARE
JUDECATOR RASA EVENIMENT
Albu Ciobanesc german Confirmatie
Albu Ciobanesc german Ascultare
Morar Ciobanesc german Ascultare
Vasiu Ciobanesc german Ascultare
Petrisor Ciobanesc german Confirmatie
Albu Pudel Ascultare
Albu Pudel Dresaj
Morar Pudel Ascultare
Vasiu Pudel Ascultare
Morar Pudel Dresaj
Morar St.Bernard Dresaj

Fig.6.8.b. Proiecţii şi reuniunea relaţiilor binare din relaţia

PARADA_CAINI

Atât 4NF cât şi 5NF se ocupă de dependenţe multivalorice şi 5NF

recunoaşte că dependenţe multivalorice pot exista între trei sau mai multe
atribute pe când 4NF recunoaşte numai perechi de atribute cu dependenţe
multivalorice.

6.9. Procesul de normalizare

Normalizarea relaţională poate fi abordată prin sinteză sau descompunere.

Sinteza. Sinteza începe cu o mulţime de atribute şi o declaraţie de
dependenţe şi combină atributele astfel încât să rezulte o mulţime de relaţii
normalizate. Această abordare a apărut înainte de dezvoltarea formelor
normale Boyce-Codd, a patra şi a cincea. Deci ea adresează în special sinteza
relaţiilor 3NF.
Descompunerea. Descompunerea începe cu o mulţime de relaţii
(poate fi şi una singură) şi o declaraţie de dependenţe şi sparge aceste relaţii
iniţiale într-o mulţime de relaţii normalizate. Explicarea formelor normale în
acest capitol foloseşte abordarea bazată pe descompunere.
Descompunerea este, în general, preferabilă sintezei deoarece
algoritmii de sinteză folosesc patterne de dependenţe declarate (i.e. cu
sintaxă) şi nu cu semantică. Pe de altă parte, descompunerea foloseşte
atribute în contextul relaţiilor, ceea ce oferă un cadru semantic.
Presupunerea că toate atributele pot fi considerate ca fiind într-o
relaţie universală are implicaţii nedorite. Astfel, identificarea grupărilor

112
iniţiale de atribute din relaţii care au sens semantic ca entităţi, înainte de
aplicarea procedurii de descompunere poate fi complicată. În cap.9. vom
discuta obţinerea acestor relaţii.

6.10. Aplicaţii ale teoriei normalizării

Am văzut mai înainte că normalizarea relaţională are ca obiectiv de bază

obţinerea unor grupări stabile de atribute în relaţii şi că există două motivaţii
primare pentru acest obiectiv: proiectarea bazei de date logică extensibilă şi
proiectarea bazei de date fizică flexibilă.
Modelarea datelor logice. Normalizarea relaţională ajută la
stabilirea răspunsului la întrebarea ce se pune în modelarea datelor logice: Ce
este o entitate bine definită? Dacă obiectivul normalizării este reformulat ca
obţinerea de grupări “stabile” de atribute în entităţi, atunci aplicabilitatea
normalizării relaţionale în proiectarea bazelor de date logice devine mai
evidentă. Fiecare relaţie într-un model normalizat reprezintă o entitate; deci
normalizarea relaţională devine un instrument de modelare date logice.
Principiile normalizării pot fi aplicate pentru a ajuta la determinarea entităţii
în care ar trebui să rezide un atribut.
Fiecare formă succesivă de normalizare măreşte explicitatea
semanticii relaţiilor rezultate şi mai multă informaţie semantică este
exprimată de o schemă relaţională ştiind că ea este de o formă normală
particulară. Dacă entităţile unui model de date logice se conformează
regulilor normalizării, atunci modelul poate transmite mai multă informaţie
semantică decât dacă conceptele normalizării n-ar fi aplicate.
Principala dificultate practică întâlnită în aplicarea normalizării
relaţionale pentru a construi modele de date logice este identificarea
dependenţelor funcţionale şi multivalorice în lumea reală. Normalizarea se
bazează complet pe declaraţii valide de dependenţe; utilizatorii însă pot avea
dificultăţi în dezvoltarea acestor declaraţii.
Valoarea normalizării relaţionale ca o parte a modelării datelor
logice nu trebuie interpretată ca un sprijin al modelului relaţional pentru
modelarea datelor logice. De fapt, anumite concepte importante în modelarea
datelor sunt dificil de reprezentat în modelul relaţional. Un exemplu de
concept care nu este bine tratat în modelul relaţional este relaţia de categorie.
Mai mult, regulile de normalizare nu sunt singurele reguli ce pot fi aplicate
pentru a identifica entităţi “stabile”, cu toate că alte reguli sunt în afara ariei
de interes a textului de faţă. Utilitatea normalizării relaţionale pentru
modelarea datelor logice este astfel în domeniul intensiunii (i.e. schemei)
relaţiilor.
Proiectarea bazei de date fizice. O justificare majoră a formelor
normale relaţionale este evitarea diferitelor anomalii de actualizare. Acestea
apar în cazurile în care memorarea faptelor într-o bază de date este afectaţă
de structura relaţiilor. Utilitatea normalizării relaţionale pentru proiectarea

113
bazelor de date fizice rezidă în principal în extensiunea (i.e. populaţia)
relaţiilor. La prima vedere pare ineficient să spargem o tabelă în mai multe
tabele pentru a satisface restricţiile regulilor de normlizare, cu toate că o
astfel de descompunere poate înbunătăţi performanţa prin reducerea
numărului de linii din fiecare tabelă. Mai important însă, integritatea datelor
poate fi menţinută mai eficient dacă relaţiile din baza de date sunt proiectate
pentru a satisface regulile normalizării. Dar proiectarea fizică a bazelor de
date relaţionale înseamnă în fapt mai mult decât identificarea relaţiilor de
bază. De exemplu, indecşii şi structurile de căutare pot fi selectate şi
distribuţia relaţiilor în fişiere fizice poate fi specificată. În fine să menţionăm
că aplicarea principiilor normalizării pentru a reduce replicarea datelor poate
conduce la baze de date relaţionale fizice mai eficiente şi mai flexibile.

6.11. Comentarii finale

Normalizarea relaţională este o abordare riguroasă, exactă pentru a grupa

atribute în relaţii stabile şi poate fi aplicată proiectării logice a tuturor bazelor
de date, nu numai a celor relaţionale.
Întrebările cele mai comune care se pun atunci când se descompune
o relaţie nenormalizată sunt:
(1NF) Poate un atribut să aibă valori multiple? Dacă da, rafinaţi relaţia în
1NF.
(2NF) Există atribute dependente de numai o parte a cheii? Dacă da,
descompuneţi relaţia până când toate atributele sunt dependente de
întreaga lor cheie.
(3NF) Există atribute dependente de atribute non cheie? Dacă da,
descompuneţi relaţia până când toate atributele sunt dependente
numai de cheia lor.
(BCNF) Conţine relaţia vreo dependenţă în afara cheilor candidate? Dacă da,
descompuneţi relaţia până când toate atributele sunt dependente
numai de cheile candidate.
(4NF, 5NF) Conţine relaţia dependenţe multivalorice independente? Dacă da,
descompuneţi relaţia până când nu mai rămân dependenţe
independente.
Probabil modul cel mai simplu de a rezuma regulile de normalizare este:
 fiecare atribut non cheie este dependent de întreaga cheie şi numai de ea;
 nici o relaţie nu conţine dependenţe nelegate.

Memento

Formă normală Boyce-Codd Tabelă de instanţe

Cheie candidată Intensiunea unei relaţii
Descompunere Cheie
Determinant Dependenţă multivalorică

114
Extensiunea unei relaţii Normalizare
A cincea formă normală (5NF) Cheie primară
Prima formă normală (1NF) A doua formă normală (2NF)
Atribut cheie străină Sinteza
A patra formă normală (4NF) A treia formă normală (3NF)
Dependenţă funcţională

Bibliografie

1. Aho, A.V.; Beeri, C.; Ullman, J.D. (1979) The theory of joins in
relational databases, ACM Trans. on Database Systems 4 : 297-314.
2. Armstrong, W.W. (1974) Dependency structurea of database
relationships, Proc.IFIP Congress.
3. Brown, R.G. (1982) Logical Database Design Techniques, Mountain
View, CA: The DBDG July 1982.
4. Codd, E.F. (1979) Extending the database relational model to capture
more meaning, ACM Trans. on Database Systems (Dec. 1979) 397-434.
5. *** (1971) Normalized database structure: a brief tutorial, Proc. ACM
SIGFIDET.
6. Date, C.J. (1981) Further normalization, Chapter 14 in An Introduction to
Database Systems, Addison Wesley, 232-272.

115