3.

4 Simplificarea structurii datelor prin normalizare

3.4.1 Necesitatea structurării bazei de date

În figura 3.1, este prezentat un set de relaţii care formează o bază de date structurată, pentru a pune
în evidenţă principalele concepte specifice modelului relaţional. În acest moment, cititorul ar putea
formula trei întrebări: De ce este necesar ca o bază de date să fie structurată cu atenţie? Când putem
spune că o bază de date este bine structurată? Cum se obţine o bază de date structurată? Deocamdată ne
vom limita la a răspunde la prima întrebare, urmând ca, în paragraful 3.4, să lămurim şi ultimele două
întrebări.
Pentru a înţelege mai bine necesitatea structurării atente a unei baze de date, vom evidenţia
problemele care se ivesc într-o bază de date nestructurată. În figura 3.2 este prezentată baza de date din
figura 3.1, însă de data aceasta în formă nestructurată, toate atributele fiind reunite într-o singură relaţie,
pe care o vom numi VANZARE. Încercaţi să comparaţi acum cele două forme ale bazei de date.
VANZARE
NrFactura DataFactura CodClient NumeClient Adresa Sold CodProdus DenProdus UM Stoc Cantitate PretVanzare
81001 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0 100026 Pal furniruit mp 112,00 40,00 12,50
81002 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0 100001 Canapea Mircea buc 7,00 4,00 250,00
81002 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0 100018 Comoda Mia buc 12,00 8,00 140,00
81003 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500 100018 Comoda Mia buc 12,00 1,00 140,00
81004 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500 100026 Pal furniruit mp 112,00 28,00 12,50
81004 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500 100018 Canapea Mircea buc 7,00 4,00 250,00
81005 27/01/06 1003 Lux SRL Viilor, 45, Husi 2900 100034 Biblioteca Livia buc 4,00 1,00 980,00

Fig. 3.2 Exemplu de bază de date relaţională nestructurată

În exemplul de faţă, baza de date stochează date privitoare la vânzările dintr-o firmă. O operaţiune de
vânzare este consemnată într-o factură, al cărei identificator este numărul acesteia - NrFactura. O factură
este întocmită pentru un singur client, însă ea poate conţine mai multe produse vândute (facturile 81002 şi
81004). Un anumit produs poate fi vândut către mai mulţi clienţi, el putând fi regăsit pe mai multe facturi
(de exemplu produsul „Comodă Mia”). Se consideră că preţul de vânzare nu poate diferi de la o vânzare
la alta pentru acelaşi produs. Fiecare tuplu (linie) se referă la o anumită factură şi un anumit produs
conţinut în factura respectivă, motiv pentru care cheia primară a relaţiei este compusă din atributele
NrFactura şi CodProdus.
Se poate lesne observa că relaţia VANZARE înregistrează o redundanţă mare a datelor. Astfel, dacă o
factură ar conţine 5 produse, atunci numărul şi data facturii, codul, numele şi celelalte date privitoare la
client se vor repeta în toate cele cinci linii. De asemenea, dacă un produs face obiectul a 10 operaţiuni de
vânzare (se regăseşte pe 10 facturi), atunci datele privitoare la acel produs (cod, denumire, unitate de
măsură, stoc şi preţ) se vor repeta în toate cele 10 linii corespunzătoare. Pentru factura 81002 există două
linii deoarece ea conţine două produse, iar numărul şi data facturii, codul, numele, adresa şi soldul
clientului, sunt înregistrate de două ori. Similar, produsul „Comoda Mia” se regăseşte în două facturi,
toate datele referitoare la acest produs – cod, denumire, unitate de măsură, stoc şi preţ - fiind înregistrate
de două ori. Redundanţa datelor este cu atât mai mare, cu cât volumul datelor din bază este mai mare.
Redundanţa datelor ne duce imediat cu gândul la spaţiul ocupat pe disc. Totuşi, risipa de spaţiu de
stocare nu este atât de importantă cât timp astăzi dispunem de hard-discuri cu capacităţi de stocare de
ordinul zecilor sau sutelor de gigabytes, dar şi de alte dispozitive de stocare ieftine şi performante. Nici
problema timpului mai mare de răspuns aferent operaţiilor de acces la baza de date, asociat adesea cu
redundanţa datelor, nu este una foarte serioasă, decât în cazul bazelor de date de dimensiuni foarte mari,
când chiar şi o bază de date bine structurată poate fi neperformantă (după cum vom vedea în capitolul 4).
Aspectele negative importante derivate din redundanţa datelor sunt mai puţin vizibile în figura 3.2.
Ele sunt legate de aşa-numitele anomalii la actualizare, adică dificultăţi în ceea ce priveşte efectuarea
operaţiilor de adăugare (inserare), modificare sau ştergere a liniilor într-o bază de date nestructurată, aşa
cum este cea din figura 3.2. În continuare, vom explica şi exemplifica anomaliile ce se ivesc în legătură
cu fiecare din cele trei operaţiuni de actualizare.
Anomaliile la inserare constau în dificultatea, uneori chiar imposibilitatea, introducerii unor noi
date în bază, datorită încălcării uneia dintre cele trei restricţii privind cheia primară – neadmiterea
valorilor nule. Să presupunem că dorim să adaugăm un nou produs în relaţia VANZARE (figura 3.2).
Acest lucru nu este posibil decât atunci când intervine o operaţiune de vânzare pentru acel produs. Altfel,
nu s-ar cunoaşte valoarea pentru numărul facturii şi ar implica atribuirea valorii nule pentru atributul
NrFactura, ceea ce nu este permis, deoarece el face parte din cheia primară a relaţiei. Aceeaşi situaţie se
iveşte şi la adăugarea unui client nou. Revenind la forma structurată a bazei de date (figura 3.1),
adăugarea unui client nou sau a unui produs nou presupune inserarea unei înregistrări în tabela CLIENT,
respectiv PRODUS, înregistrarea acestor operaţii nefiind legată de existenţa unei facturi.
Anomaliile la modificare se referă la dificultatea modificării valorii unui atribut care se repetă în
mai multe linii. De exemplu, dacă clientul „Mota SRL” se mută la o altă adresă, suntem puşi în situaţia de
a căuta toate liniile în care se regăseşte clientul respectiv şi de a efectua modificarea în toate liniile (adică
3 linii). Mai mult, dacă modificarea se face numai pentru o parte din liniile cu pricina, atunci datele din
bază îşi vor pierde consistenţa. Concret, clientul nostru va apărea în baza de date atât cu adresa nouă, cât
şi cu cea veche. Această problemă este eliminată în baza de date din figura 3.1, schimbarea adresei
clientului „Mota SRL” presupunând modificarea unei singure linii. Aceeaşi situaţie se regăseşte şi în
cazul atributelor care descriu un produs, cum ar fi Stoc.
Anomaliile la ştergere se manifestă atunci când prin ştergerea unei linii din tabelă se pierd
involuntar şi informaţii care prezintă încă interes pentru utilizatorii aplicaţiei. Astfel, dacă ştergem ultima
linie din relaţia VANZARE, cea care conţine vânzarea produsului „Bibliotecă Livia” (factura cu numărul
81005), se pierd nu doar datele relative la factura respectivă, ci şi toate informaţiile despre produsul în
cauză. O astfel de problemă apare datorită existenţei unei singure linii în care apare produsul „Bibliotecă
Livia”. De asemenea, se observă că factura 81005 este singura emisă clientului „Lux SRL” şi, prin
urmare, ştergerea ei atrage după sine şi pierderea datelor referitoare la acest client. Apariţia unei astfel de
anomalii este evitată în baza de date din figura 3.1, deoarece ştergerea liniei care priveşte factura 81005
din tabela FACTURA nu atrage automat şi ştergerea liniei corespunzătoare produsului „Bibliotecă Livia”
din tabela PRODUS, nici a liniei cu date despre clientul „Lux SRL”, din tabela CLIENT.
Aşadar, o bază de date structurată oferă anumite avantaje legate, în primul rând, de minimizarea
anomaliilor la actualizarea datelor. Pentru definirea mai formală a ceea ce înseamnă o bază de date
structurată se apelează la conceptul de bază de date normalizată, iar procedura de aducere a bazei de date
într-o astfel de formă se numeşte normalizare. Prin aceste clarificări am început să răspundem la ultimele
două întrebări formulate la începutul acestui paragraf.
De formele normalizării bazelor de date şi de paşii parcurşi ne vom ocupa în continuare.
În procesul de analiză a cerinţelor unui sistem, pot fi identificate şi descrise punctele de vedere ale
unei mulţimi de utilizatori. Deseori numărul perspectivelor utilizatorilor despre aceeaşi bază de date poate
fi de ordinul zecilor sau sutelor. Fiecare are în vedere anumite date elementare din bază. De exemplu, într-
o „Situaţie lunară a vânzărilor” pot fi surprinse nouă date elementare: NrFactura, DataFactura, CodClient,
NumeClient, CodProdus, DenProdus, UM, Cantitate şi PretVanzare. Data elementară Valoare nu a fost
reţinută, deoarece este o dată calculată şi, ca regulă generală, nu este stocată în baza de date. La o analiză
atentă însă, rezultă că aceste date elementare aparţin câtorva entităţi, cum sunt: FACTURA, CLIENT,
PRODUS.
Problema de bază a proiectării logice a bazelor de date poate fi redată astfel: dată fiind dimensiunea
meta-datelor (date despre date) colectate în procesul de studiere a cerinţelor sistemului, se pune întrebarea
cum ar trebui să proiectăm modelul logic al datelor pentru a reprezenta meta-datele cât mai natural şi
complet, în cea mai simplă formă şi cu cea mai mică redundanţă posibilă? Cu alte cuvinte, cum ar trebui
combinate datele elementare pentru a forma relaţii (sau tipuri de înregistrări) care să descrie entităţile şi
relaţiile dintre entităţi?
Răspunsurile la întrebările anterioare sunt legate de forma normalizată (standardizată) a bazei de
date şi procesul de normalizare.
 Potrivit definiţiei din Dicţionarul explicativ al limbii române, „a normaliza” înseamnă:
„1) A face să devină sau a deveni ceva normal, a (re)aduce sau a reveni la starea normală.
2) A supune unei norme, a face să se conformeze unei norme.
3) A elabora norme interne; a standardiza”.
În The Grosset Webster Dictionary, „a normaliza” este definit prin a aduce ceva la un standard sau la
o formă bine definită. Aşadar, ultimele două sensuri definesc corect operaţiunea cu baze de date. Din
acest motiv, noi considerăm că este mai apropiată de sensul ei formularea „formă normalizată a bazei de
date”, în sensul de standardizată, reglementată, decât „forma normală a bazei de date”, întâlnită uneoi în
literatura de specialitate.
După descrierile făcute, se cuvine să revenim asupra procesului de norma-lizare a bazelor de date.
Forma standardizată a unei baze de date este definită prin intermediul a cinci forme normalizate (chiar
şase, dacă se consideră distinctă forma BCFN, care este o reformulare, mai riguroasă, a celei de-a treia
forme). Primele trei forme de normalizare analizează dependenţele funcţionale dintre atribute, iar a patra
şi a cincea se bazează pe dependenţele multivaloare, respectiv dependenţele de joncţiune. Normalizarea
este definită ca procesul de descompunere succesivă a relaţiei iniţiale într-un set de sub-relaţii structurate,
având la bază analiza dependenţelor dintre atribute. Succesiunea paşilor parcurşi în normalizare1 sunt
redaţi schematic în figura 3.3.

Imagini/viziuni
ale utilizatorilor

Relaţii
nenormalizate
Extragerea grupurilor
care se repetă
Relaţii normalizate
în prima formă (1NF)
Extragerea dependenţelor
parţiale
A doua formă normalizată
a relaţiilor (2NF)
Extragerea dependenţelor
tranzitive
A treia formă normalizată
a relaţiilor (3NF)
...
Fig. 3.3 Paşii normalizării
În figura de mai sus sunt prezentate numai primele trei forme de normalizare, întrucât se consideră
că, în majoritatea cazurilor, aducerea unei baze de date relaţionale în forma a treia de normalizare este
suficientă. Cazurile care să necesite trecerea dincolo de cea de-a treia formă sunt rar întâlnite în practică.
În cele ce urmează, ne vom opri doar asupra primelor trei forme de normalizare
Pentru a exemplifica procedura normalizării, vom porni de la relaţia generală iniţială VANZARE
(nenormalizată) din figura 3.2, reluată în figura 3.4. Analistul afişează datele fiecărei viziuni/imagini a
utilizatorilor într-o formă tabelară.

1
. Vezi şi McFadden, F.R., Hoffer, J.A. – Data Base Management, Second Edition, The Benjamin/Cummings Publishing
Company, Inc., Menlo Park, 1988; McFadden, F.R., Hoffer, J.A. – Modern Database Management, The
Benjamin/Cummings Publishing Company, Inc., Redwood City, 1994.
 VANZARE
NrFactura DataFactura CodClient NumeClient Adresa Sold CodProdus DenProdus UM Stoc Cantitate PretVanzare
81001 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0 100026 Pal furniruit mp 112,00 40,00 12,50
81002 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0 100001 Canapea Mircea buc 7,00 4,00 250,00
81002 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0 100018 Comoda Mia buc 12,00 8,00 140,00
81003 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500 100018 Comoda Mia buc 12,00 1,00 140,00
81004 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500 100026 Pal furniruit mp 112,00 28,00 12,50
81004 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500 100018 Canapea Mircea buc 7,00 4,00 250,00
81005 27/01/06 1003 Lux SRL Viilor, 45, Husi 2900 100034 Biblioteca Livia buc 4,00 1,00 980,00

Fig. 3.4 Relaţia generală iniţială VANZARE (nenormalizată)

Considerăm că imaginea asupra bazei de date reţinută în relaţia VANZARE corespunde unui utilizator
care solicită următoarele trei rapoarte:
„Situaţia lunară a vânzărilor”, care conţine ca date elementare NrFactura, DataFactura,
CodClient, NumeClient, CodProdus, DenProdus, UM, Cantitate, PretVanzare şi Valoare.
„Lista stocurilor de produse finite”, care are drept date elementare CodProdus, DenProdus, UM,
PretVanzare şi Stoc.
„Situaţia clienţilor firmei”, având ca date elementare CodClient, NumeClient, Adresa şi Sold.
Din analiza celor trei ieşiri (rapoarte) se poate alcătui mulţimea atributelor (datelor elementare) de
ieşire. Un atribut care se regăseşte în două sau mai multe rapoarte va fi reţinut o singură dată. Din
mulţimea atributelor de ieşire se determină mulţimea atributelor de intrare, prin eliminarea acelor atribute
de ieşire care se obţin prin calcule matematice. Atributele de intrare sunt cele care prezintă interes din
punctul de vedere al stocării. În exemplul nostru, va fi eliminat atributul Valoare, calculat prin înmulţirea
altor două atribute, respectiv Cantitate şi PretVanzare.
Un tratament aparte îl vor avea atributele Stoc şi Sold care, chiar dacă sunt obţinute prin calcule,
sunt considerate date de stare, adică reflectă starea unei entităţi la un moment dat (stocul pentru un
anumit produs, respectiv soldul unui anumit client). În plus, să ne gândim la complexitatea calculelor
necesare. De exemplu, pentru stoc ar trebui luate în calcul toate intrările şi toate ieşirile din gestiune de la
momentul începerii activităţii firmei, sau cel puţin de la momentul dării în exploatare a sistemului
informaţional!
De asemenea, trebuie să spunem că nu întotdeauna mulţimea atributelor de intrare este mai
restrânsă decât cea a atributelor de ieşire, ea putând include unele atribute care nu se regăsesc în rapoarte
dar care sunt necesare pentru calculul altor date elementare din rapoarte. De exemplu, dacă am fi avut în
primul raport şi ValoareTVA, pentru determinarea valorii acestui atribut ar fi fost necesară reţinerea
atributului CotaTVA în mulţimea atributelor de intrare.
Înainte de a trece la normalizare, trebuie să stabilim cheia primară a relaţiei iniţiale, întrucât doar
relaţiile pot fi supuse normalizării, iar orice relaţie trebuie să dispună de o cheie proprie pentru a fi
considerată ca atare.
Analizând relaţia VANZARE, este lesne de observat că nici unul dintre atribute nu poate juca
singur rolul de cheie primară. Fiecare tuplu din relaţie corespunde unui articol (produs) dintr-o factură
emisă unui anumit client. Ipotetic, putem lua în discuţie atributele CodClient, CodProdus şi NrFactura.
CodClient nu poate fi cheie primară întrucât unui client i se pot emite două sau mai multe facturi, caz în
care vom avea două sau mai multe tupluri ce vor avea aceeaşi valoare pentru CodClient. În plus, dacă o
factură conţine trei produse, atunci vom avea trei tupluri cu aceeaşi valoare pentru CodClient. Un
raţionament similar se aplică şi pentru CodProdus, acelaşi produs putând face obiectul mai multor
operaţiuni de vânzare (facturi), deci am avea mai multe tupluri cu aceeaşi valoare pentru acest atribut. În
mod curent, o factură poate conţine două sau mai multe articole, situaţie în care vom avea cel puţin două
tupluri cu valori identice pentru atributul NrFactura.
Dacă nici unul dintre atributele puse în discuţie nu îndeplineşte condiţiile de a fi cheie primară,
atunci se va continua cu căutarea unor combinaţii de două sau mai multe atribute care să constituie cheia
primară. Nu trebuie uitată una dintre cele trei restricţii privind cheia, respectiv cea care se referă la
compoziţia minimală a acesteia. Raţionamentul pentru analiza unor combinaţii posibile de atribute care să
alcătuiască cheia primară este asemănător cu cel efectuat anterior, pentru cele trei atribute.
Cheia primară a relaţiei noastre o vom considera formată prin combinaţia NrFactura + CodProdus.

3.4.2 Prima formă normalizată (1FN)

Prima formă normalizată este una relativ controversată. Aceasta se datorează, pe de o parte,
formulărilor diferite întâlnite în literatura de specialitate, principalele noţiuni utilizate fiind atomicitate
şi/sau grupuri repetitive, iar pe de altă parte, diferitelor accepţiuni „formale” atribuite atomicităţii. În plus,
în ultimul timp, unii autori propun renunţarea la atomicitatea atributelor unei relaţii, considerând-o ca o
limită serioasă a modelului relaţional, mai ales pentru aplicaţiile „complexe”, precum cele pentru
proiectarea şi fabricarea asistată de calculator (CAD/CAM), sistemele informaţionale geografice, stocarea
documentelor2. Chiar C. J. Date admite că a greşit în trecut şi recunoaşte „legalitatea” valorilor compozite
pentru atributele unei relaţii, pe care el le defineşte ca valori de tip-relaţie, adică „… putem avea relaţii cu
atribute ale căror valori, la rândul lor, sunt relaţii. Cu alte cuvinte, putem avea relaţii care să aibă
imbricate în interiorul lor alte relaţii”3.
O relaţie este considerată în prima formă normalizată, referită şi ca 1FN, dacă şi numai dacă toate
atributele care o formează sunt atomice, deci relaţia nu conţine grupuri repetitive. Un atribut este
considerat atomic dacă el nu mai poate fi descompus în alte atribute. Altfel spus, la intersecţia fiecărei
linii cu o coloană trebuie să existe întotdeauna exact o valoare, niciodată un grup de mai multe valori.
Deşi ar părea că atomicitatea atributelor este riguros definită şi că este uşor de obţinut, lucrurile nu
stau chiar aşa. Regula este simplă: oricare atribut trebuie să conţină o singură valoare pentru fiecare tuplu
(linie). Însă ce reprezintă o singură valoare? Întorcându-ne la relaţia VANZARE, la o primă vedere, se
poate considera că două atribute sunt compuse (deci ne-atomice) şi, drept consecinţă, relaţia nu se găseşte
în 1FN. Acestea sunt DataFactura şi Adresa.
Atributul DataFactura ar putea fi descompus în Zi, Luna şi An. Deşi se apela la această
descompunere acum mai bine de 15 ani, în vremea în care aplicaţiile economice erau dezvoltate
preponderent în limbajele COBOL şi FORTRAN, astăzi nimeni nu mai ia în seama o astfel de procedură.
Explicaţiile rezidă în facilităţile de declarare şi gestionare a atributelor de tip DATE (dată calendaristică)
disponibile astăzi în orice sistem de gestiune a bazelor de date. Orice mediu de dezvoltare oferă astăzi
funcţii speciale pentru a extrage ziua (DAY), luna (MONTH) sau anul (YEAR) dintr-o dată calendaristică.
Prin urmare, dacă dorim să prelucrăm toate facturile emise clienţilor dintr-o perioadă anume, de
exemplu luna noiembrie a anului 2004, vom apela la funcţiile MONTH şi YEAR pentru a extrage şi
prelucra doar tuplurile care îndeplinesc condiţia dată. Dacă nu am fi avut la dispoziţie cele două funcţii,
realizarea acestei prelucrări ar fi fost mai dificilă şi mai greoaie. În această situaţie erau puşi
programatorii în trecut, atunci când utilizau COBOL-ul, FORTRAN-ul sau alt mediu de programare al
acelor vremuri.
Un caz aparte îl reprezintă atributul Adresa. El poate fi considerat ca ne-atomic, atât timp cât poate fi
descompus în CodPostal, Strada, Numar, Bloc, Scara şi Apartament. Şi în acest caz, noţiunea atomicitate
este una relativă. De data aceasta, însă, vom lua în considerare cerinţele informaţionale identificate în faza
de analiză a sistemului şi care trebuie să stea la baza proiectării bazei de date. Altfel spus, trebuie să ne
punem întrebarea dacă este vitală descompunerea atributului Adresa din perspectiva cerinţelor
informaţionale. Mai concret, întrebarea anterioară poate fi reformulată astfel: Cerinţele informaţionale
impun prelucrarea facturilor emise clienţilor în funcţie de numele străzii (de exemplu, care este valoarea
facturilor emise clienţilor care au sediul pe o anumită stradă, indiferent de localitate?), numărul străzii sau

2
. O prezentare amplă a diverselor opinii exprimate în literatura de specialitate poate fi găsită în Fotache, M. – Proiectarea
bazelor de date. Normalizare şi postnormalizare, Editura Polirom Iaşi, 2005.
3
. Date, C.J. – Baze de date, Editura Plus, Bucureşti, 2005, traducere a lucrării Date, C.J. – An Introduction to Database Systems,
Eighth Edition, Pearson Education, Inc., Boston, 2004, p. 152.
numărul blocului? Dacă nu, atunci Adresa poate rămâne nedescompus, iar dacă da, este imperios necesară
descompunerea sa.
În exemplul nostru, considerăm că cerinţele informaţionale şi de prelucrare solicită tratarea
atributului Adresa ca un tot, deci el este atomic. Cu totul altfel ar fi stat lucrurile dacă prin baza de date s-
ar fi gestionat clienţii unei firme de televiziune prin cablu sau ai unei firme de distribuire a produselor
alimentare. În cazul primei firme, conducerea ar putea fi interesată la un moment dat de numărul
clienţilor-abonaţi de pe o anumită stradă. Această cerinţă informaţională sugerează descompunerea
atributului Adresa. Chiar şi în astfel de situaţii, necesitatea descompunerii este uşor pusă în discuţie, din
cauza numeroaselor funcţii dedicate şirurilor de caractere disponibile în mediile actuale de programare,
sau de operatorul LIKE din SQL.
În concluzie, atomicitatea atributelor este o noţiune „relativă”, în sensul că ea trebuie interpretată din
perspectiva cerinţelor informaţionale care stau la baza proiectării bazei de date, dar şi a mecanismelor de
gestiune a diferitelor tipuri de date existente în mediile de dezvoltare a aplicaţiilor (în special sisteme de
gestiune bazelor de date).
În ceea ce priveşte relaţia VANZARE, aşa cum este ea prezentată în figura 3.4, o considerăm în 1FN.
Înainte de a trece la următorul pas al normalizării, să clarificăm semnificaţia noţiunii de grup
repetitiv, aceeaşi cu cea a atomicităţii. Mai corectă considerăm formularea grup repetitiv de valori, pentru
a o delimita net de grup de atribute repetitive. Dacă revenim la atributul Adresa, valorile aferente numelui
străzii ar putea constitui un grup repetitiv de valori atât timp cât pot exista mai mulţi clienţi care îşi au
sediul pe aceeaşi stradă şi, în plus, am dori să prelucrăm datele care privesc numai pe aceşti clienţi. Deci,
se constată prezenţa unui grup repetitiv de valori în cadrul atributului Adresa care prezintă interes din
perspectiva prelucrărilor informaţionale. Altfel spus, există un nivel nedorit de redundanţă a datelor, care
generează efectele negative cunoscute. Cum vom actualiza baza de date dacă se modifică numele unei
străzi pe care îşi au sediul mai mulţi clienţi? Ne permitem să răspundem evaziv, tot printr-o întrebare: Cât
de frecvent se schimbă numele străzilor într-o localitate?
Pentru a rezolva problema, grupul respectiv trebuie extras şi se va introduce un nou atribut. De fapt,
ajungem la rezultatul anterior, când analizam atomicitatea atributului Adresa.
Totuşi, trebuie să spunem că noţiunea de grup repetitiv poate avea mai multe semnificaţii, în funcţie
de care se poate aplica un tratament sau altul. O situaţie aparte în care putem avea grupuri repetitive este
evidenţiată de exemplul din figura 3.54.

DenProdus Anul PrevazutIan RealizatIan PrevazutFebr RealizatFebr PrevazutM ar RealizatM ar

Pal furniruit 2005 115000 87000 0 0 0 0
Canapea Mircea 2005 85000 92000 0 0 0 0
Comoda Mia 2005 93000 93500 0 0 0 0
Biblioteca Livia 2005 250000 223000 0 0 0 0

Fig. 3.5 Exemplu de grup repetitiv

Deşi nu este o eroare gravă, multe aplicaţii funcţionând cu succes cu astfel de implementări în baza
de date, o asemenea structurare poate crea unele probleme. De exemplu, determinarea valorii totale a
vânzărilor pentru primul trimestru este mai dificil de obţinut, prin prisma prelucrărilor ce trebuie
efectuate. Totuşi, o asemenea structurare poate fi extrem de neplăcută, mai ales atunci când numărul
elementelor care se regăsesc pe coloane variază în limite largi.
O prezentare detaliată a acestui subiect poate fi găsită la Marin Fotache, care foloseşte pentru astfel
de situaţii noţiunea de grup repetitiv pe orizontală5.

4
. Riordan, R.M. – Designing Relational Database Systems, Microsoft Press, Redmond, Washington, 1999, p. 34.
5
. Fotache, M. – op.cit., pp. 55-61.
 3.4.3 A doua formă normalizată (2FN)
Deşi relaţia VANZARE este în prima formă normalizată, este lesne de observat că anomaliile la
actualizare, enunţate în paragraful 3.4.1, nu au fost îndepărate. Cu toate că aducerea ei în 1FN a rezolvat o
parte dintre problemele de gestiune a datelor, relaţia VANZARE nu este şi în 2FN, cu atât mai puţin în
forma 3FN, deci ea se află în continuare într-o formă indezirabilă (nestructurată). Pentru a elimina cel
puţin o parte din problemele de actualizare a datelor, este necesar să trecem la pasul următor al procedurii
de normalizare.
După cum reiese şi din schema generală a normalizării (figura 3.3), obiectivul celei de-a doua forme
de normalizare constă în extragerea dependenţelor funcţionale parţiale. O relaţie este în forma a doua
normalizată dacă şi numai dacă ea se află deja în prima formă şi nu conţine dependenţe funcţionale
parţiale. Ultima parte a definiţiei poate fi reformulată astfel: fiecare atribut non-cheie este dependent total
de cheia primară.
Înainte de a explica modul în care poate fi adusă o relaţie în 2FN, trebuie să clarificăm noţiunile
dependenţă funcţională, dependenţă funcţională parţială şi dependenţă funcţională totală.
Fiind date X şi Y, două atribute sau grupuri de atribute dintr-o relaţie (tabelă) oarecare, spunem că X
se află în relaţie de dependenţă funcţională cu Y atunci când cunoaşterea unei valori pentru X permite
cunoaşterea a maximum o valoare pentru Y. X se numeşte sursa sau determinantul relaţiei de dependenţă
funcţională, iar Y este referit ca destinaţia sau determinatul relaţiei. Relaţia de dependenţă funcţională se
poate scrie:
X Y
şi poate fi citită în ambele sensuri: X determină funcţional pe Y, sau Y este determinat funcţional de X.
Un prim exemplu de dependenţă funcţională în relaţia VANZARE este cel dintre atributele NrFactura
şi NumeClient. Cunoaşterea numărului facturii permite cunoaşterea cu certitudine a numelui clientului,
deoarece o factură este emisă pentru un singur client. Alte exemple sunt prezentate în figura 3.6.
NrFactura DataFactura
CodProdus Stoc
CodProdus DenProdus
CodClient Sold
CodClient NumeClient
Fig. 3.6 Exemple de dependenţe funcţionale în relaţia VANZARI
În orice tabelă există relaţii de dependenţă funcţională. Mai exact, cheia unei tabele determină
funcţional toate atributele non-cheie din acea relaţie. Astfel, combinaţia de atribute (NrFactura,
CodProdus), care formează cheia relaţiei VANZARE, determină funcţional toate celelalte atribute. Din
faptul că atributele se află în relaţie (de dependenţă funcţională) provine şi denumirea de relaţie şi,
implicit, cea de model relaţional..
Să mai spunem că o relaţie de dependenţă funcţională este denumită canonică dacă destinaţia este
reprezentată de un singur atribut (sursa poate fi simplă sau compusă). Toate relaţiile dintre cheia compusă
a relaţiei VANZARE şi fiecare dintre atributele sale non-cheie sunt în forma canonică.
Pentru o mai bună clarificare a conţinutului dependenţelor funcţionale, vom prezenta câteva contra-
exemple. Două atribute sau grupuri de atribute nu sunt în relaţie de dependenţă funcţională atunci când
cunoaşterea valorii lui X:
nu permite cunoaşterea nici uneia dintre valorile lui Y, caz în care nu există nici un fel de
relaţie de dependenţă între X şi Y, sau
permite cunoaşterea mai multor valori posibile pentru Y.
Un exemplu, pentru primul caz, îl reprezintă atributele DataFactura şi DenProdus: între cele două
atribute nu există o dependenţă funcţională, deoarece data întocmirii facturii nu spune absolut nimic
despre denumirea produsului facturat. Pentru al doilea caz, relevant este exemplul dintre NrFactura şi
CodProdus: într-o factură poate fi înregistrată vânzarea mai multor produse, iar unei valori pentru
NrFactura îi vor putea corespunde mai multe valori pentru atributul CodProdus. Modalitatea de scriere a
celor două contra-exemple, precum şi altele sunt prezentate în figura 3.7.
DataFactura DenProdus
DataFactura NrFactura
NrFactura CodProdus
NrFactura Cantitate
CodProdus Cantitate
CodProdus NrFactura
(NrFactura, CodClient) DenProdus
(NrFactura, CodClient) Cantitate
Fig. 3.7 Contra-exemple de dependenţe funcţionale în relaţia VANZARE
Între DataFactura şi NrFactura nu există o relaţie de dependenţă funcţională, întrucât într-o aceeaşi
zi pot fi emise mai multe facturi, iar, dacă vom cunoaşte valoarea pentru DataFactura, nu vom cunoaşte
cu certitudine care este valoarea pentru NrFactura. În mod similar, pentru un acelaşi produs, pot fi
înregistrate mai multe facturi ce consemnează operaţiuni de vânzare, deci valoarea atributului CodProdus
nu determină funcţional NrFactura.
Obiectul analizei, pentru forma a doua de normalizare, îl reprezintă un tip aparte de dependenţă
funcţională, respectiv :ependenţa funcţională parţială. Dependenţele funcţionale parţiale se manifestă
atunci când atributele non-cheie dintr-o relaţie (tabelă) depind funcţional numai de o parte a cheii
compuse. Fiind dată relaţia de dependenţă funcţională X Y , în care X reprezintă cheia
compusă a unei relaţii şi Y un atribut non-cheie, dacă există un subansamblu Z al lui X, pentru care
dependenţa funcţională Z Y este adevărată, atunci spunem că avem o relaţie de dependenţă
funcţională parţială. În caz contrar, spunem că atributul non-cheie Y este dependent total de cheia relaţiei.
Dependenţele totale mai sunt referite şi ca dependenţe elementare. Într-o relaţie în care cheia este simplă,
toate atributele non-cheie depind total de cheia relaţiei. Prin urmare, dependenţe funcţionale parţiale pot
exista numai în relaţiile care au cheie primară compusă.
Relaţia VANZARE are cheie primară compusă din două atribute, deci ar putea exista două grupuri de
dependenţe funcţionale parţiale. Fiecare grup va fi format din atributele non-cheie care depind funcţional
numai de NrFactura, respectiv CodProdus. Cele două grupuri sunt prezentate în figura 3.8.
NrFactura DataFactura CodProdus DenProdus
NrFactura CodClient CodProdus UM
NrFactura NumeClient CodProdus Stoc
NrFactura Adresa CodProdus PretVanzare
NrFactura Sold

Fig. 3.8 Dependenţele funcţionale parţiale din relaţia VANZARE

Doar atributul Cantitate depinde total de cheia primară, deoarece el nu depinde funcţional numai de
NrFactura sau CodProdus. Relaţia de dependenţă funcţională totală poate fi reprezentată astfel:
(NrFactura, CodProdus) Cantitate
Transformarea unei relaţii în 2FN presupune descompunerea acesteia, prin constituirea a câte o
relaţie pentru fiecare grup de dependenţe funcţionale parţiale, şi a unei relaţii care va conţine numai
dependenţele totale. Relaţiile din prima categorie vor avea drept cheie primară sursa dependenţelor
parţiale pentru fiecare grup în parte, iar ultima relaţie rezultată va prelua cheia primară a relaţiei înainte de
descompunere. Chiar dacă nu există nici o dependenţă totală, ultima relaţie tot va fi constituită, ea urmând
a avea ca atribute doar pe cele care formează cheia primară.
Descompunerea relaţiei VANZARE este prezentată în figura 3.9. S-au constituit trei noi relaţii:
1. VANZARE_2FN, care are drept cheie primară NrFactura şi care mai conţine atributele non-cheie
dependente parţial de NrFactura în relaţia VANZARE;
 2. PRODUS, care conţine CodProdus, cu rol de cheie primară, şi toate atributele non-cheie care în
relaţia VANZARE erau în relaţie de dependenţă parţială faţă de acesta;
3. ARTICOLFACTURA, în care se regăsesc atributele non-cheie din VANZARE aflate în relaţie de
dependenţă funcţională totală faţă de cheia compusă, împreună cu atributele cheii. Această tabelă
păstrează cheia primară compusă (NrFactura+ CodProdus), ea ar fi fost constituită şi dacă nu ar
fi existat atributul Cantitate.

VANZARE
NrFactura DataFactura CodClient NumeClient Adresa Sold CodProdus DenProdus UM Stoc Cantitate PretVanzare
81001 25/01/06 1001 M ota SRL Florilor, 21, Iasi 0 100026 Pal furniruit mp 112,00 40,00 12,50
81002 25/01/06 1001 M ota SRL Florilor, 21, Iasi 0 100001 Canapea M ircea buc 7,00 4,00 250,00
81002 25/01/06 1001 M ota SRL Florilor, 21, Iasi 0 100018 Comoda M ia buc 12,00 8,00 140,00
81003 26/01/06 1002 M obins SA Copou, 11, Vaslui 1500 100018 Comoda M ia buc 12,00 1,00 140,00
81004 26/01/06 1002 M obins SA Copou, 11, Vaslui 1500 100026 Pal furniruit mp 112,00 28,00 12,50
81004 26/01/06 1002 M obins SA Copou, 11, Vaslui 1500 100018 Canapea M ircea buc 7,00 4,00 250,00
81005 27/01/06 1003 Lux SRL Viilor, 45, Husi 2900 100034 Biblioteca Livia buc 4,00 1,00 980,00

ARTICOLFACTURA
NrFactura CodProdus Cantitate
81001 100026 40,00
81002 100001 4,00
81002 100018 8,00
81003 100018 1,00
81004 100026 28,00
81004 100018 45,00
81005 100034 1,00

PRODUS
CodProdus DenProdus UM Stoc PretVanzare
100001 Canapea Mircea buc 7,00 250,00
100018 Comoda Mia buc 12,00 140,00
100026 Pal furniruit mp 112,00 12,50
100034 Biblioteca Livia buc 4,00 980,00

VANZARE_2FN
NrFacturaDataFactura CodClient NumeClient Adresa Sold
81001 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0
81002 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0
81003 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500
81004 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500
81005 27/01/06 1003 Lux SRL Viilor, 45, Husi 2900

Fig. 3.9 Transformarea relaţiei VANZARE în forma a doua normalizată, prin extragerea celor două grupuri de
dependenţe funcţionale parţiale
În urma trecerii bazei de date în 2FN, relaţia VANZARE a fost înlocuită prin cele trei noi relaţii.
După cum se poate observa, operaţia de descompunere s-a realizat fără pierderea de informaţii, iar, pe
baza legăturilor dintre cele trei relaţii, relaţia iniţială VANZARE poate fi oricând reconstituită prin
operaţiunea de joncţiune. Legătura dintre VANZARE_2FN şi ARTICOLFACTURA se realizează pe baza
atributului comun NrFactura (acest atribut joacă rolul de cheie primară în prima relaţie şi pe cel de cheie
străină în cea de-a doua), iar legătura dintre PRODUS şi ARTICOLFACTURA, prin atributul CodProdus
(care este cheie străină în ARTICOLFACTURA).
Este evident că noua structură a bazei de date, care este în forma a doua normalizată, determină o
reducere a redundanţei datelor şi elimină o parte din anomaliile manifestate la actualizarea datelor în
relaţia VANZARE, prezentate în paragraful 3.4.1.
Anomalii la adăugare. Poate fi adăugat un nou produs, chiar dacă acesta nu este implicat încă în
nici o operaţiune de vânzare, prin simpla adăugare a unui tuplu (linie) în relaţia PRODUS.
Anomalii la modificare. Datele care privesc un anumit produs apar o singură dată, deoarece în
relaţia PRODUS există câte un tuplu pentru fiecare produs. Astfel, actualizarea atributului Stoc, pentru a
reflecta o operaţiune de vânzare, implică modificarea acestui atribut doar într-un singur tuplu, respectiv
cel din relaţia PRODUS, care conţine datele privitoare la produsul respectiv.
 Anomalii la ştergere. Putem şterge datele despre vânzarea consemnată prin factura 81005, din
relaţia VANZARE_2FN, fără a pierde datele relative la produsul „Bibliotecă Livia”, care rămân neşterse în
tabela PRODUS.

3.4.4 A treia formă normalizată (3FN)

Deşi lucrurile par a fi rezolvate, la o analiză şi mai atentă se poate constata că redundanţa datelor şi
anomaliile la actualizare încă îşi fac simţită prezenţa în relaţia VANZARE_2FN. În schimb, relaţiile
PRODUS şi ARTICOLFACTURA nu mai prezintă astfel de probleme, deoarece ele sunt deja în forma a
treia normalizată, ceea ce nu este valabil în cazul primei relaţii. Anomaliile la actualizare ale relaţiei
VANZARE_2FN sunt:
Anomalii la adăugare. Nu este posibilă adăugarea unui client nou până în momentul emiterii unei
facturi pentru clientul respectiv.
Anomalii la modificare. Dacă se doreşte modificarea datelor despre un client, de exemplu adresa,
atunci trebuie căutate şi modificate toate liniile în care apare clientul respectiv.
Anomalii la ştergere. În cazul ştergerii datelor privitoare la o factură, există posibilitatea pierderii şi
a datelor relative la clientul respectiv. Dacă privim schema bazei de date din figura 3.9, putem observa că,
prin ştergerea datelor privind factura 81005, din relaţia VANZARE_2FN, nu se mai pierd datele relative la
produsul „Biblioteca Livia”, în schimb se pierd datele care privesc clientul „Lux SRL”.
Redundanţa datelor ce încă se manifestă se datorează faptului că în relaţia VANZARE_2FN se
ascunde entitatea CLIENT. Datele referitoare la un client apar de atâtea ori câte facturi au fost emise
clientului respectiv. De exemplu, datele clientului „Mota SRL” se regăsesc în două linii din
VANZARE_2FN. Sursa acestei redundanţe o reprezintă existenţa unor relaţii de dependenţă funcţională
tranzitivă.
O relaţie de dependenţă funcţională tranzitivă poate fi definită astfel: fie X, Y şi Z trei atribute ale
unei relaţii; dacă în cadrul relaţiei sunt valabile dependenţele funcţionale X Y şi
Y Z , atunci este evident că se va verifica şi dependenţa funcţională X Z , care este
o dependenţă funcţională tranzitivă. Se mai spune că Z este dependent tranzitiv de X şi se poate nota sub
forma X Y Z . În caz contrar, se spune că Z este dependent funcţional direct de X.
Dacă se consideră că X este cheia primară a relaţiei în cauză, atunci este „ilegală” dependenţa
funcţională dintre Y şi Z, ambele fiind atribute non-cheie. Altfel spus, Y este sursă a unei dependenţe
funcţionale, deşi el este atribut non-cheie, conform reprezentării din figura 3.10.

X Y Z

Dependenţă funcţională
tranzitivă

Fig. 3.10 Diagrama de reprezentare generalizată a dependenţelor tranzitive

În relaţia VANZARE_2FN există un grup de dependenţe funcţionale tranzitive, care au drept sursă
CodClient. Toate aceste dependenţe sunt prezentate în figura 3.11.
NrFactura CodClient NumeClient
NrFactura CodClient Adresa
NrFactura CodClient Sold
Fig. 3.11 Dependenţele funcţionale tranzitive din relaţia VANZARE_2FN
 Se poate deduce deja că aducerea unei relaţii în forma a treia normalizată implică eliminarea
dependenţelor funcţionale tranzitive. Cu alte cuvinte, într-o relaţie toate atributele non-cheie trebuie să
depindă direct de cheia primară a relaţiei. O altă modalitate de formulare – într-o relaţie nu este permis ca
un atribut non-cheie să fie sursa unor dependenţe funcţionale.
Prin urmare, definiţia pentru cea de-a treia formă normalizată poate fi formulată în mai multe
moduri. Să reţinem una dintre ele: o relaţie se află în a treia formă normalizată dacă şi numai dacă ea se
află în cea de-a doua formă normalizată şi nu conţine dependenţe funcţionale tranzitive. De menţionat că
această definiţie presupune existenţa unei singure chei candidat, şi care va fi considerată cheia primară.
Transformarea unei relaţii din 2FN în 3FN se poate realiza în următoarea manieră:
1. identificarea grupurilor de dependenţe tranzitive în relaţia analizată. Un grup de dependenţe
tranzitive va conţine atributul non-cheie care este sursa dependenţelor funcţionale şi atributele
non-cheie care depind de el. În tabela VANZARE_2FN există un singur grup de dependenţe
tranzitive, format din CodClient, ca sursă, NumeClient, Adresa şi Sold, ca destinaţii ale
dependenţelor tranzitive.
2. extragerea grupurilor de dependenţe tranzitive şi constituirea a câte o relaţie nouă pentru fiecare
grup în parte. Sursa dependenţelor tranzitive din grupul respectiv va reprezenta cheia primară a
relaţiilor nou constituite. În exemplul nostru, s-a constituit relaţia CLIENT, iar cheia sa primară
este CodClient.
3. atributele rămase în relaţia iniţială (respectiv cele care depindeau în mod direct de cheie) vor
forma o nouă relaţie, care va avea aceeaşi cheie, şi în care vor fi reţinute şi atributele care
reprezentau sursele dependenţelor tranzitive pentru fiecare grup. Ele vor juca rolul de chei străine
şi vor permite stabilirea legăturilor între tabelele rezultate în urma procesului de descompunere.
În exemplul nostru se va forma relaţia FACTURA, în care NrFactura este cheie primară, iar
CodClient este cheie străină şi permite stabilirea legăturii cu tabela CLIENT, obţinută în pasul
anterior.
Rezultatul descompunerii relaţiei VANZARE_2FN este prezentat în figura 3.12.
Să observăm acum că anomaliile manifestate la actualizarea datelor din relaţia VANZARE_2NF,
prezentate la începutul paragrafului, au fost eliminate.
Anomalii la adăugare. Adăugarea unui client nou poate fi efectuată chiar dacă nu s-a emis încă o
factură pentru acel client, prin inserarea unei linii în tabela CLIENT.
Anomalii la modificare. Datele privitoare la un client anume vor apărea o singură dată, în tabela
CLIENT, iar modificarea unei anumite informaţii despre acesta, de exemplu adresa, va presupune
actualizarea unei singure linii.
Anomalii la ştergere. În cazul ştergerii unei facturi nu mai există posibilitatea pierderii informaţiilor
despre clientul respectiv, deoarece această operaţiune implică ştergerea unei linii din tabela FACTURA, nu
şi a liniei corespunzătoare clientului respectiv din tabela CLIENT.
 VANZARE_2FN
NrFacturaDataFactura CodClient NumeClient Adresa Sold
81001 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0
81002 25/01/06 1001 Mota SRL Florilor, 21, Iasi 0
81003 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500
81004 26/01/06 1002 Mobins SA Copou, 11, Vaslui 1500
81005 27/01/06 1003 Lux SRL Viilor, 45, Husi 2900

FACTURA
NrFactura DataFactura CodClient
81001 25.mai.04 1001
81002 25.mai.04 1001
81003 26.mai.04 1002
81004 26.mai.04 1002
81005 27.mai.04 1003

CLIENT
CodClient NumeClient Adresa Sold
1001 Mota SRL Florilor, 21, Iasi 0
1002 Mobins SA Copou, 11, Vaslui 15000000
1003 Lux SRL Viilor, 45, Husi 29000000

Fig. 3.12 Trecerea relaţiei VANZARE_2FN în cea de-a treia formă normalizată, prin extragerea dependenţelor
tranzitive
După toate operaţiunile efectuate până în acest moment, normalizarea este terminată. Din relaţia
nenormalizată VANZARE s-au desprins patru relaţii în 3FN: CLIENT, PRODUS, FACTURA şi
ARTICOLFACTURA. Baza de date rezultată în urma procesului de normalizare este imaginea fidelă a celei
prezentate în figura 3.1. Anomaliile descrise în paragraful 3.2.2 nu-şi mai pot face simţită prezenţa. De
reţinut este faptul că VANZARE, în forma nenormalizată, poate fi reconstruită din relaţiile 3FN, folosind
algebra relaţională.

3.4.5 Normalizarea relaţiilor cu ajutorul grafului dependenţelor funcţionale

În paragrafele anterioare a fost prezentat procesul normalizării sub forma unor transformări
succesive a relaţiei generale iniţiale în 1FN, 2FN şi 3FN. Aplicarea acestui proces prezintă mai curând
valenţe didactice decât practice. În cazul unor relaţii iniţiale mai complexe, descompunerea ei prin
transformări succesive este greoaie. Drept urmare, au fost elaborate diverse instrumente menite a
simplifica lucrul cu dependenţele funcţionale6. În continuare, vom prezenta unul dintre acestea, respectiv
graful dependenţelor funcţionale.
În acest graf, dependenţele funcţionale sunt reprezentate print săgeţi ce leagă atributul-sursă de
atributele-destinaţie. În cazul dependenţelor cu sursă compusă se utilizează un conector, în care săgeţile
spre acel conector evidenţiază atributele care formează sursa compusă, iar săgeţile dinspre conector
desemnează atributele-destinaţie.
În figura 3.13 este prezentat graful dependenţelor funcţionale pentru relaţia generală iniţială
VANZARE.

6
. Vezi Fotache, M. – op.cit.,
 NrFactura CodProdus

DataFactura CodClient DenProdus UM Stoc PretVanzare

NumeClient Adresa Sold Cantitate

Fig. 3.13 Graful dependenţelor funcţionale pentru relaţia VANZARE

În graf pot fi depistate relativ uşor toate tipurile de dependenţe funcţionale. Interpretarea lui relevă
următoarele:
mai întâi, trebuie remarcat că relaţia reprezentată în figura 3.13 prezintă o cheie compusă,
formată din cele două atribute de pe primul nivel;
apoi, se poate observa că există un singur atribut care depinde total de cheia relaţiei, respectiv
Cantitate. Prin urmare, vom trasa un contur în care vom cuprinde cele trei atribute, care vor
forma o relaţie distinctă, respectiv ARTICOLFACTURA;
în continuare, se observă un grup de atribute care depind funcţional de CodProdus, deci numai
de o parte a cheii primare compuse. Prin urmare, avem un grup de dependenţe parţiale care,
împreună cu sursa lor vor constitui o nouă relaţie (PRODUS), evidenţiată printr-un contur
separat;
un alt grup de dependenţe parţiale au drept sursă NrFactura. Însă, nu toate atributele pot fi
incluse într-o singură relaţie, deoarece graful dependenţelor funcţionale relevă că o parte din
atributele-destinaţie nu depind direct de NrFactura, ele formând un grup de dependenţe
tranzitive (prezentate în figura 3.11) având ca sursă CodClient. Aşadar, se vor trasa două
contururi, desemnând constituirea a două relaţii, FACTURA şi CLIENT.
În urma construirii şi analizei grafului dependenţelor funcţionale a relaţiei VANZARE se ajunge la
acelaşi rezultat cu cel obţinut prin aplicarea procedurii de normalizare discutat în paragrafele anterioare
însă, considerăm noi, într-o manieră mai simplă şi mai elegantă.