Universitatea Al.I.

Cuza Iași
Facultatea de Economie și Administrarea Afacerilor
Catedra de Informatică Economică

FORMELE
NORMALE
1, 2 ŞI 3
Normalizarea prin descompunere şi sinteză.
Două cazuri practice
 Scopul normalizării
Pornind de o problemă reală (practică), încercăm să
construim o schemă rezonabilă a bazei de date
(dedicate acestei probleme)
O schemă rezonabilă este o schemă care preia în BD
(şi, ulterior, prelucrează şi furnizează celor interesaţi)
informaţiile relevante, utile, necesare organizaţiei
Cine decide dacă o schemă rezonabilă ?
◦ Echipa de proiectare
◦ Utilizatorii aplicaţie/BD, atât la proiectare, cât şi la începutul
şi pe parcursul folosirii BD
◦ Profesorii (în cazul cursului de faţă)
 Exemple de probleme (reale)
Gestiunea unei farmacii
Salarizarea la o companie sau organizaţie
Gestiunea vânzărilor
Evidenţa stocurilor
Gestiunea activităţii unui cabinet veterinar
Facturarea serviciilor pentru o firmă de
televiziune, telefonie şi internet prin cablu
Informaţiidespre UEFA Champions League (sau,
coborând mult nivelul discuţiei, Liga lui Mitică)
 De la ce pornim în normalizare ?
De la specificaţiile problemei
Specificaţiile sunt reguli şi restricţii după care se
organizează şi derulează activităţile, procesele,
evenimentele, operaţiunile (pentru problema dată)
Specificaţiile depind de:
◦ Legislaţie
◦ Practica managerială, financiar-contabilă, operaţională
din companie etc.
◦ Domeniul de activitate şi mărimea companiei
◦ Cerinţele clientului (companiei)
 Munca de analist/proiectant
Mai întâi, analistul/proiectantul studiază
specificul problemei (colaborând cu clienţii,
experţii (profesioniştii din domeniul problemei),
viitorii utilizatori ai aplicaţiei şi alţi analişti),
 apoi construieşte un model (mai mult sau mai
puţin riguros) al cerinţelor problemei
Modelul final se va prezenta sub forma unor
diagrame de date şi procese (pe care le veţi
studia la Analiza/Proiectarea SI, sau SIFC1+2)
 Cum va decurge normalizarea
Pornim de la specificaţiile problemei (simplificându-le,
mai ales în primele cazuri practice)
Inventariem toate informaţiile necesare (informaţii care
vor deveni atribute ale BD)
Stabilim dependenţele dintre atribute (funcţionale, de
incluziune, ...)
Obţinem BD într-o formă normală cât mai avansată
(ideal ar fi 5NF, dar ne vom mulţumi de multe ori şi cu
3NF)
Folosind normalizarea prin descompunere aducem BD
succesiv în 1NF, 2NF ...
Folosind normalizarea prin sinteză aducem BD direct în
 Caz practic 1 – Biblioteca FEAA

Scop:
Stocarea de informaţii privind cărţile aflate în rafturile
bibliotecii FEAA (Corp B UAIC, Etaj 1)

Specificaţii minimale:
• Fiecare carte publicată (în România şi străinătate) este
identificată în mod unic la nivel mondial prin ISBN
• Cărţile sunt publicate de edituri
• O editură îşi are sediul principal într-o localitate
• Biblioteca FEAA poate avea unul sau mai multe
exemplare ale unei cărţi (ale unui “titlu”)
 Biblioteca FEAA (continuare)
Specificaţii minimale (continuare):
• Biblioteca FEAA gestionează fiecare exemplar
atribuindu-i o Cotă
• Nu există două exemplare ale unei cărţi (sau ale două) cu
aceeaşi cotă (valoarea cotei unui exemplar este unică )
• Biblioteca FEAA nu împrumută cărţi la domiciliu (sau
birou/laborator) şi nici nu gestionează cititorii
• Pentru fiecare carte se preiau toţi autorii
• Pentru a înlesni căutarea, bibliotecarii FEAA asociază
fiecărei cărţi cuvinte cheie (care semnalizează ce
subiecte tratează cartea respectivă)
 Caz practic 2 – FACTURARE (1)
Scop:
Stocarea de informaţii privind facturile emise de o companie,
facturile ce reflectă vânzări de produse.

Specificaţii minimale:
• Compania îşi numerotează strict facturile emise, fără a mai
refolosi vreodată numerele deja alocate;
• O factură este adresată unui singur client; în timp, unui client
îi pot fi adresate oricâte facturi;
• Clienţii sunt exclusiv persoane juridice (organiza-
ţii/companii); pentru fiecare client există o singură persoană
de contact, despre care ne interesează numele, telefonul şi
adresa de e-mail ;
 FACTURARE (2)
Specificaţii minimale (continuare):
• Pe o factură se consemnează vânzarea a unu, două sau
mai multe produse;
• Informaţiile care ne interesează despre produse sunt:
Codul (intern), Denumirea, Unitatea de măsură şi
Procentul TVA; procentul de TVA se aplică la fiecare
vânzare a produsului (19%, 9%, 0% sau, mai nou 24%).
• Pe o factură, un produs apare o singură dată;
• BD trebuie să furnizeze informaţii precum: TVA colectată
pentru o factură, valoarea fără şi cu TVA a facturii etc.
I. Normalizare
prin
descompunere
 Prima formă normalizată (1)
Codd: O relaţie este în prima formă normală
dacă… nici unul dintre domeniile sale nu
conţine elemente care sunt, la rândul lor, seturi
(ansambluri)
O relaţie aflată în 1FN ca acea relaţie în care
fiecare atribut prezintă numai valori atomice,
adică toate atributele sunt ne-decompozabile;
R.Riordan: o relaţie este în 1FN dacă domeniile
pe care sunt definite atributele relaţiei sunt
scalare
 Prima formă normalizată (2)

Connoly şi Begg: O relaţie în 1FN este o

relaţie în care intersecţia oricărei linii cu
oricare coloană conţine o valoare şi numai una
O relaţie în 1FN nu trebuie să conţină grupuri
repetitive.

Obs: orice relaţie în 1FN trebuie să posede cheie

primară (atributele din componenţa cheii
primare nu pot avea valori nule)
 Biblioteca FEAA
(o (mică) porţiune)
BIBLIOTECA – Relaţia universală
(iniţială)
Atribute:
ISBN
Obs:
Titlu
O linie a tabelei BIBLIOTECA se
Editură referă la un titlu de carte din care s-au
LocSediuE achiziţionat unul, două sau mai multe
d
AnApariţie exemplare
Autori Cheia primară a tabelei poate fi
atributul ISBN
Cote
Trei dintre atribute – Autori, Cote şi
CuvinteCheie CuvinteCheie nu sunt atomice
Deocamdată nu atomizăm cele trei
atribute neatomice (deşi ne-am
pricepe)
 Relaţia BIBLIOTECA nu este în
prima forma normală !!!
Motivul: trei dintre atribute nu sunt atomice (ci
seturi sau grupuri repetitive)
Trei soluţii:
◦ Constituirea de grupuri repetitive pe orizontală – ex.
înlocuirea atributului Autor cu atributele Autor1, Autor2,
Autor3...
◦ Constituirea de grupuri repetitive pe verticală şi
modificarea cheii primare din ISBN în (ISBN, Autor,
Cotă, CuvântCheie)
◦ Spargerea relaţiei universale (RU) în câte o tabelă pentru
fiecare atribut neatomic (plus o tabelă cu ceea ce râmâne
din RU)
BIBLIOTECA 1 - Grupuri repetitive pe
orizontală
BIBLIOTECA1 – Grupuri repetitive pe
orizontală (continuare)
Atribute:
ISBN CuvântCheie1 CuvintCheie5
CuvântCheie2 CuvintCheie6
Titlu CuvântCheie3 CuvintCheie7
Editură CuvântCheie4 CuvintCheie8
LocSediuE
d
AnApariţie Obs:
Autor1 Cheia primară a tabelei rămâne atributul ISBN
Autor2 Pentru cărţile cu mai puţin de patru autori, mai
Autor3 puţin de trei exemplare (cote) şi mai puţin de
opt cuvinte cheie o să avem valori NULL
Autor4
Pentru cărţile cu mai mult de patru autori, mai
Cota1
Cota2 mult de trei exemplare (cote) şi mai mult de
opt cuvinte cheie AM ÎNCURCAT-O !!!
Cota3
 BIBLIOTECA1 - Grupuri repetitive pe
orizontală (continuare)
Soluţia este destul de stupidă, însă baza de date este în
1NF !
Trebuie să luăm în calcul numărul maxim de:
◦ Autori
◦ Cote
◦ Cuvinte Cheie
pentru o carte şi obţinem o structură complet ineficientă
Soluţia poate fi aplicată doar când numărul de membri
ai setului este cunoscut şi fix; de ex:, în loc de
atributul (neatomic) Părinţi putem folosi
IdPărinte1_Mama şi IdPărinte2_Tata pentru
descrierea copiilor întru BD
 BIBLIO-
TECĂ2 -
Grupuri
repetitive pe
verticală
(fragment)
BIBLIOTECA2 - Grupuri repetitive pe
verticală (continuare)
Atribute:
ISBN Obs:
Titlu Numărul de atribute este redus, însă numărul
Editură de înregistrări creşte ameţitor (este nevoie de
o linie pentru fiecare combinaţie exemplar
LocSediuE (carte) – autor – cuvânt cheie
d
AnApariţie O înregistrare descrie un subiect (cuvânt
Autor cheie) tratat într-un exemplar al unei cărţi
Cota scrise de unul dintre autori (ciudat, nu ?)
CuvântCheie Cheia primară a tabelei se modifică: (Cota,
Autor, CuvântCheie)
Am scăpat de ne-atomicitate, adică avem BD
în 1NF, dar costul este destul de mare !!!
BIBLIOTECA2 este în 1NF !
 BIBLIOTECA3 – Spargerea relaţiei
universale (pt. fiecare atribut neatomic)
 BIBLIOTECA3 (continuare)
CĂRȚI {ISBN, Titlu, Editura, LocSediuEd,
AnApariţie}
COTE {ISBN, Cota}
AUTORI_CĂRȚI {ISBN, Autor}
CĂRȚI_CUVINTECHEIE {ISBN,
CuvântCheie}
Obs:
Este prima variantă de spargere a BD în mai multe tabele
Toate cele patru tabele sunt în 1NF
Această manieră de spargere a nu este întotdeauna funcţională
Între tabelele obţinute există câteva diferenţe; spre ex., în tabela
COTE cheia primară e simplă (atributul Cota), în timp ce în
celelalte tabele construite pe baza neatomicităţii cheia primară
este compusă
 BD BIBLIOTECA în 1 NF
(recapitulare)
Înprima formă normală (1NF) baza de date BIBLIOTECA
poate să aibă (cel puţin) trei configuraţii:
◦ Tabela BIBLIOTECA1 {ISBN, Titlu, Cota1, Cota2, Cota3, Autor1,
Autor2, Autor3, Autor4, Editura, LocSediuEd, AnApariţie,
CuvântCheie1, CuvântCheie2, CuvântCheie3, CuvântCheie4,
CuvântCheie5, CuvântCheie6, CuvântCheie7} (varianta 1)
◦ Tabela BIBLIOTECA2 {ISBN, Titlu, Cotă, Autor, Editura,
LocSediuEd, AnApariţie, CuvântCheie} (varianta 2)
◦ Tabelele CĂRŢI, COTE, AUTORI_CĂRŢI și
CĂRŢI_CUVINTECHEIE (varianta 3)
Prima variantă este descalificată (inoperabilă)
Variantele2 și 3 vor fi duse în formele normale
(normalizate) 2, 3...
FACTURARE – Relaţia universală
Cantit
NrFact
NumeCl PretUnit
CodFiscalCl
Atribute calculate (le eliminăm):
AdresaCl
CodPersContact ValoareFărăTVA
NumePersContact TVAFactură
TelPersContact ValoareTotalăFactură
EMailPersContact Obs:
LocalitCl Relaţia este în 1FN
DataFact O linie din FACTURARE se referă la
CodProd un produs vândut în cadrul unei
DenProd facturi
UM - Cheia primară în FACTURARE :
ProcTVAProd (NrFact, CodProd)
BD FACTURARE în prima forma
normală – 1NF

R {NrFact, DataFact, CodFiscalCl,

NumeCl, AdresaCl, LocalitCl,
CodPersContact, NumePersContact,
TelPersContact, EMailPersContact,
CodProd, DenProd, UM,
ProcTVAProd, Cant, PretUnit}
 Probleme ale bazelor de date
aflate în 1NF
Teoretic,o BD este normalizată dacă este
măcar în prima formă normală (1NF)
De obicei, însă, o BD aflată în 1NF prezintă
câteva probleme majore:
◦ Grad mare de redundanţă (repetabilitate) a datelor
◦ Imposibilitatea adăugării unor categorii de
informaţii (anomalii la inserare)
◦ Pierderea coerenţei datelor la anumite modificări de
informaţii (anomalii la modificare)
◦ Pierderea uneor informaţii la ştergerea unor
înregistrări (anomalii la ştergere)
 Anomalii în BD BIBLIOTECA2
{ISBN, Titlu, Cotă, Autor, Editura,
LocSediuEd, AnApariţie, CuvântCheie}
Redundanţe:
◦ Pe fiecare înregistrare trebuie specificată şi valoarea
atributului ISBN, şi pe cea a atributului AnApariţie, chiar
dacă un titlu are o singură primă apariţie
◦ Pe fiecare înregistrare trebuie specificată şi valoarea
atributului Editură, şi pe cea a atributului LocSediuEd,
chiar dacă o editură are un singur sediu
◦ Pentru corectitudinea interogărilor, toţi autorii unei cărţi
trebuie combinaţi cu toate cuvintele cheie ale cărţii şi toate
exemplarele (cotele) cărţii; dacă o carte are 5 exemplare, 7
autori şi 10 cuvinte cheie, în tabela BIBLIOTECĂ2 vor fi
inserate 5 * 7 * 10 = 350 de înregistrări
 Anomalii în BD BIBLIOTECA2 – cont.
{ISBN, Titlu, Cotă, Autor, Editura, LocSediuEd,
AnApariţie, CuvântCheie}
Ex. de anomalii la inserare:
 I1: o editură nu poate fi adăugată în tabelă până nu avem măcar
o carte tipărită la această editură
 I2: o carte (titlu) nu nu poate fi adăugată în tabelă fără măcar
(cel puţin) un autor, măcar un exemplar şi măcar un cuvânt
cheie
Ex. de anomalii la modificare:
 M1: Dacă modificăm într-o înregistrare valoarea unuia dintre
atributele Titlu, Editură, LocSediuEd, AnApariţie şi există şi
alte înregistrări pentru cartea (titlul) respectivă, cum ştim care
dintre valorile acestor atribute pe celelalte înregistrări
(corespunzătoare cărţii respective) sunt corecte ?
 Anomalii în BD BIBLIOTECA2 – cont.
{ISBN, Titlu, Cotă, Autor, Editura, LocSediuEd, AnApariţie, CuvântCheie}

Ex. de anomalii la modificare (continuare):

 M2: Dacă, am precizat greşit cota unei cărţi şi descoperim
greşeala după câtva timp, va trebui să o reparam în toate
înregistrările în care cota greşită apare combinată cu toate
valorile atributelor Autor şi CuvântCheie (corespunzătoare
cărţii respective)
Ex. de anomalii la ştergere:
 S1: Dacă ştergem singura carte pe care o avem apărută la o
editură, odată cu cartea pierdem şi informaţiile despre editura
respectivă
 Anomalii în BD BIBLIOTECA3
CĂRȚI {ISBN, Titlu, Editura, LocSediuEd,
AnApariţie}
COTE {ISBN, Cota}
AUTORI_CĂRȚI {ISBN, Autor}
CĂRȚI_CUVINTECHEIE {ISBN, CuvântCheie}
Princomparaţie cu BIBLIOTECA2, gradul de
redundanţă şi numărul anomaliilor la inserare,
modificare, ştergere sunt incomparabil mai mici
Rămân valabile anomaliile
 I1
 S1
 Anomalii ale BD FACTURARE în 1NF –
relaţia R (1)
Risipă de spaţiu: la fiecare linie dintr-o factură,
trebuie introduse şi:
 Numele, codul, şi adresa clientului
 Datele despre persoana de contact
 Data facturii
Anomalii la inserarea de înregistrări în RF:
◦ Niciun client nu poate introdus în tabela RF până nu
avem factură pentru acesta
◦ Niciun produs nu poate fi adăugat în tabela RF până nu
apare pe o factură
 Anomalii ale BD FACTURARE în
1NF – relaţia R (2)
La modificarea de înregistrări în RF:
◦ Dacă după câţiva ani (şi 200 de facturi) o firmă
client îşi schimbă persoana de contact (sau adresa
sediului), pe câte linii trebuie să operăm
modificarea?
La ştergerea de înregistrări din RF:
◦ Dacă ştergem singura factură a unui client, ştergem
şi datele despre acesta
◦ Analog în cazul produselor
 A doua forma normală – 2NF
O relaţie se află în 2NF dacă:
Este deja în 1NF
Nu conţine dependenţe funcţionale parţiale
O bază de date este în 2NF dacă toate relaţiile
care o alcătuiesc se află în 2FN
Orice relaţie care conţine DF parţiale trebuie
descompusă (spartă) pentru a fi conformă cu
2FN
 Cum testăm dacă o BD este sau nu în a
doua forma normală ?
Tabelele care au cheia primară alcătuită dintr-un
singur atribut sunt deja în 2FN
Luăm în discuţie fiecare tabelă a BD din prima
formă normală în care cheia primară este compusă
◦ Inventariem dependenţele funcţionale ce decurg automat
din cheia primară
◦ Dacă măcar una dintre aceste DF este parţială, atunci
tabela (şi, în consecinţă, baza de date) nu este în 2FN !!!
Dacă niciuna dintre tabelei primei forme normale
nu conţine vreo dependenţă funcţională parţială,
spunem ca baza este date este în 2FN
 DF ale cheii primare în
BIBLIOTECA2
{ISBN, Titlu,
Cotă, Autor, Editura,
LocSediuEd, AnApariţie, CuvântCheie}

(Cotă, Autor, CuvântCheie) ISBN

(Cotă, Autor, CuvântCheie) Titlu
(Cotă, Autor, CuvântCheie) Editura
(Cotă, Autor, CuvântCheie) LocSediuE
d
(Cotă, Autor, CuvântCheie) AnApariţie
 BIBLIOTECA2 nu este în 2FN !
Toate cele patru DF sunt parţiale întrucât,
singur, atributul Cota implică funcţional cele
patru destinaţii Cotă ISBN
Cotă Titlu Cotă LocSediuE
Cotă Editura Cotă d nApariţie
A
Deci:

parțială
(Cotă, Autor, CuvântCheie) Titlu
parțială
(Cotă, Autor, CuvântCheie) Editura
parțială
(Cotă, Autor, CuvântCheie) LocSediuE
parțială d
(Cotă, Autor, CuvântCheie) AnApariţie
 Cum aducem o tabelă în a doua forma
normală ?
O spargem !
Se constituie câte o tabelă distinctă pentru fiecare sub-
ansamblu (un atribut, două atribute, ...) din cheia primară
a tabelei aflate în1NF, subansamblu care are măcar o
destinaţie funcţională (o destinaţie poate fi oricare
atribut al tabelei care nu este membru al cheii primare) –
subansamblul va fi cheia primară a noii tabele
Din tabela iniţială (aflată în 1 NF), de obicei, rămân doar
atributele care nu sunt destinaţii funcţionale ale surselor
de la punctul anterior
Există situaţii când din tabela iniţială nu mai rămâne
nimic !
 BIBLIOTECA2 adusă în 2FN
În 1NF: BIBLOTECA2 {ISBN, Titlu, Cotă, Autor,
Editura, LocSediuEd, AnApariţie,
PeCuvântCheie}
baza destinaţiilor funcţionale ale atributului
(subansamblului din cheie) Cotă obţinem tabela:
BIBLIOTECA2_1 {Cotă, ISBN, Titlu,
Editura, LocSediuEd, AnApariţie}
Din BIBLIOTECA2 rămâne tabela:
BIBLOTECA2_2 { Cotă, Autor, CuvântCheie}
Concluzie: în 2FN tabela BIBLIOTECA2 se sparge
în tabelele BIBLIOTECA2_1 şi BIBLIOTECA2_2
 BIBLIOTECA3 este deja în 2NF !

Cheile primare ale tabelelor CĂRȚI şi COTE

sunt simple (alcătuite dintr-un singur atribut)
Cheile primare ale tabelelor AUTORI_CĂRȚI
şi CĂRȚI_CUVINTECHEIE sunt compuse,
însă aceste tabele nu mai conţin niciun alt
atribut (posibilă destinaţie funcţională a
vreunui sub-ansamblu al cheii primare)

Concluzie: BD BIBLIOTECA3 are în 2 NF

aceaşi structură ca şi în 1 NF !
 Este BD FACTURARE în 2FN ?
În 1 NF, BD FACTURARE are structura relaţiei R
Trebuie identificate dependenţele funcţionale ce decurg din
calitatea de cheie primară a ansamblului (NrFact, CodPr)
Din vreuna dintre DF de mai sus este parţială, R nu este în
2 NF
Dacă R nu este în 2 NF va trebui spartă
Cheia primară a lui R este formată din două tabele, deci
numărul maxim de tabele ce ar putea fi obţinute în 2 NF
este trei:
◦ R1 {NrFact, ….}
◦ R2 {CodPr, …}
◦ R3 {NrFact, CodPr} – ceea ce rămâne din R
 DF în relaţia R ce decurg din cheia
primară (1)
R {NrFact, DataFact, CodFiscalCl, NumeCl,

AdresaCl, LocalitCl, CodPersContact,

NumePersContact, TelPersContact,

Sursa
DF
EMailPersContact, CodProd, DenProd,

UM, ProcTVAProd, Cant, PretUnit}

Destinaţii sunt toate celelalte
atribute
DF în relaţia R ce decurg din cheia
primară (2)

(NrFact, CodProd) DataFact

(NrFact, CodProd) CodFiscalCl
(NrFact, CodProd) NumeCl
(NrFact, CodProd) AdresaCl
(NrFact, CodProd) LocalitCl
(NrFact, CodProd) CodPersContact
(NrFact, CodProd) NumePersContact
DF în relaţia R ce decurg din cheia
primară (3)

(NrFact, CodProd) TelPersContact

(NrFact, CodProd) EMailPersContact
(NrFact, CodProd) DenProd
(NrFact, CodProd) UM
(NrFact, CodProd) ProcTVAProd
(NrFact, CodProd) Cant
(NrFact, CodProd) PretUnit
 DF parţiale în R (1)
P
(NrFact, CodProd) DataFact
P
(NrFact, CodProd) CodFiscalCl

(NrFact, CodProd) P NumeCl

(NrFact, CodProd) P AdresaCl

(NrFact, CodProd) P LocalitCl

(NrFact, CodProd) P CodPersContact

(NrFact, CodProd) P NumePersContact

 DF parţiale în R (2)

P
(NrFact, CodProd) TelPersContact

P
(NrFact, CodProd) EMailPersContact

P
(NrFact, CodProd) DenProd

(NrFact, CodProd) PUM

(NrFact, CodProd) PProcTVAProd

FACTURARE -Trecerea din 1NF în 2NF
R { NrFact
NrFact, DataFact , CodFiscalCl, NumeCl , AdresaCl, LocalitCl

, CodPersContact , NumePersContact , TelPersContact , EMailPersContact

, CodProd , DenProd, UM, ProcTVAProd , Cant , PreţUnit }

R1{

R2{ }
 FACTURARE - Schema în 2NF

R1 {NrFact, DataFact, CodFiscalCl, NumeCl,

AdresaCl, LocalitCl, CodPersContact,
NumePersContact, TelPersContact,
EMailPersContact}

R2 {CodProd, DenProd, UM, ProcTVAProd}

R3 {NrFact, CodProd, Cant, PretUnit}

 Anomalii ale BD BIBLIOTECA2 în 2
NF
BIBLIOTECA2_1 {Cotă, ISBN, Titlu,
Editura, LocSediuEd, AnApariţie}
BIBLIOTECA2_2 { Cotă, Autor, CuvântCheie}
Redundanţe:
◦ Pe fiecare înregistrare trebuie specificată şi valoarea
atributului ISBN, şi pe cea a atributului AnApariţie, chiar dacă
un titlu are o singură primă apariţie
◦ Pe fiecare înregistrare trebuie specificată şi valoarea
atributului Editură, şi pe cea a atributului LocSediuEd, chiar
dacă o editură are un singur sediu
◦ Dacă dintr-un titlu (ISBN) se cumpără 10 exemplare, vor
exista 10 cote, dar se vor repeta de 10 ori şi titlul, editura...
 Anomalii ale BD BIBLIOTECA2 în
2 NF - continuare
Ex. de anomalii la inserare:
 I1: o editură nu poate fi adăugată în tabela BIBLIOTECA2_1
până nu avem măcar o carte tipărită la această editură
 I3: o carte (titlu) nu poate fi adăugată în tabela BIBLIOTECA2_1
fără a avea măcar un exemplar (cotă)
Ex. de anomalii la modificare:
 M2: Dacă, am precizat greşit cota unei cărţi şi descoperim
greşeala după câtva timp, va trebui să o reparam în toate
înregistrările din tabela BIBLIOTECA2_1 în care cota greşită
apare combinată cu toate valorile atributelor Autor şi CuvântCheie
Ex. de anomalii la ştergere:
 S1: Dacă ştergem singura carte pe care o avem apărută la o
editură, odată cu cartea pierdem şi informaţiile despre editura
respectivă
 Anomalii ale schemei BD
BIBLIOTECA3 în 2 NF
CĂRȚI {ISBN, Titlu, Editura, LocSediuEd,
AnApariţie}
COTE {ISBN, Cota}
AUTORI_CĂRȚI {ISBN, Autor}
CĂRȚI_CUVINTECHEIE {ISBN, CuvântCheie}
Rămân valabile anomaliile descrise anterior (întrucât
schema bazei nu se modifică în 2 ND)
 I1
 S1
Anomalii ale BD FACTURARE în 2NF
Comparativ cu 1NF au fost eliminate o serie de
anomalii
◦ Putem introduce un produs înainte de a apărea pe o
factură
◦ Dacă am şterge singura linie pe care apare un
produs, acesta rămâne (în tabela R2)
Rămân anomalii de inserare, modificare şi
ştergere pentru clienţi (adresa, persoană
contact)
 A treia forma normală – 3NF
Definiţii:

O relaţie se află în 3NF dacă:

 Este deja în 2NF
 Nu conţine dependenţe funcţionale
tranzitive

O bază de date este în 3NF dacă toate relaţiile

care o alcătuiesc se află în 3FN
 Cum testăm dacă o BD este sau nu în a
treia forma normală ?
Luăm în discuţie fiecare tabelă a BD aflate în a
doua formă normală
◦ Inventariem dependenţele funcţionale ce decurg
automat din cheia primară
◦ Dacă măcar una dintre aceste DF este tranzitivă, atunci
tabela (şi, în consecinţă, baza de date) nu este în
3FN !!!
Dacă niciuna dintre tabelei primei forme normale
nu conţine vreo dependenţă funcţională
tranzitivă, spunem ca baza este date este în 3FN
 Cum aducem o tabelă în a treia forma
normală (3 NF) ?
O spargem (de-acum avem experienţă) !
Inventariem toate dependenţele funcţionale în care sursa
este un atribut (sau grup de atribute) din afara cheii primare,
iar destinaţia este, de asemenea, un atribut din afara cheii
Se constituie câte o tabelă distinctă pentru fiecare sursă de
tipul celor de mai sus – sursă ce va fi cheia primară a noii
tabele
Din tabela “spartă” (aflată în 2 NF), de obicei, rămân doar
atributele care nu sunt destinaţii funcţionale ale surselor de
mai sus
Există situaţii când din tabela “spartă” nu mai rămâne nimic
!
Problema 3 NF pt. BD BIBLIOTECA2
BIBLIOTECA2_1 {Cotă, ISBN, Titlu,
Editura, LocSediuEd, AnApariţie}
BIBLIOTECA2_2 { Cotă, Autor, CuvântCheie}
Există DF în care nici sursa nici destinaţia să
nu fie atribute-cheie ? DA !!!
ISB Titlu ISB LocSediuE
N
ISB Editura N
ISBN d nApariţie
A
N
Rezultă că în tabela BIBLIOTECA2_1 toate DF
ce decurg din cheia primară sunt tranzitive
tranzitivă
Cotă ISB Titlu
N
şi, deci, BIBLIOTECA2_1 nu este în 3 NF !
 BIBLIOTECA2 în 3FN (1)
Pe baza destinaţiilor funcţionale ale atributului non-
cheie ISBN obţinem tabela:
BIBLIOTECA2_1_1 {ISBN, Titlu, Editura,
LocSediuEd, AnApariţie}
Din BIBLIOTECA2_1 rămâne tabela:
BIBLIOTECA2_1_2 {Cotă, ISBN}
Supriză ! Şi în “proaspăta” tabela BIBLIOTECA2_1_1 una
dintre DF ce decurg din cheia primară este tranzitivă
(deoarece o editură are un singur sediu)
ISB Editura LocSediuE
N ce înseamnă că tabela BIBLIOTECA2_1_1
ceea d nu este
în 3 FN !
 BIBLIOTECA2 în 3FN (2)
Pe baza sursei Editura construim tabela
BIBLIOTECA2_1_1_1 {Editura, LocSediuEd}
Eliminăm LocSediuEd din tabela BIBLIOTECA2_1_1
şi rămânem cu:
BIBLIOTECA2_1_1_2 {ISBN, Titlu, Editura,
AnApariţie}
Tabela BIBLIOTECA2_2 este deja în 3 NF:
BIBLIOTECA2_2 { Cotă, Autor, CuvântCheie}
Concluzie: în 3FN baza de date BIBLIOTECA2
este alcătuită din tabelele:
BIBLIOTECA2_1_1_1, BIBLIOTECA2_1_1_2,
BIBLIOTECA2_1_2 şi BIBLIOTECA2_2
 BIBLIOTECA2 în 3FN (3)
În final, putem folosi nume sugestive pentru fiecare tabelă, aşa
că schema “finală” 3FN este:
EDITURI {Editura, LocSediuEd}
CĂRȚI {ISBN, Titlu, Editura, AnApariţie}
COTE {Cotă, ISBN}
EXEMPLARE_AUTORI_CC { Cotă, Autor,
CuvântCheie}
Problema 3NF pt. BD BIBLIOTECA3
În 2 NF schema BD BIBLIOTECA3 era compusă din:
CĂRȚI {ISBN, Titlu, Editura, LocSediuEd, AnApariţie}
COTE {ISBN, Cota} AUTORI_CĂRȚI {ISBN,
Autor}
CĂRȚI_CUVINTECHEIE {ISBN, CuvântCheie}
Pe baza discuţiei de la trecerea BIBLIOTECA2 în 3
NF spargem numai tabela CĂRȚI în:
EDITURI { Editura, LocSediuEd }
CĂRȚI2 {ISBN, Titlu, Editura, AnApariţie}
iar tabelele COTE, AUTORI_CĂRȚI şi
CĂRȚI_CUVINTECHEIE rămân neschimbate
 Este BD FACTURARE în 3FN ?
În 2 NF, BD FACTURARE are structura:
R1 {NrFact, DataFact, CodFiscalCl, NumeCl, AdresaCl,
LocalitCl, CodPersContact, NumePersContact,
TelPersContact, EMailPersContact}
R2 {CodProd, DenProd, UM, ProcTVAProd}
R3 {NrFact, CodProd, Cant, PretUnit}
În toate cele trei tabele trebuie identificate dependenţele
funcţionale ce decurg din calitatea de cheie primară (nu-i
chiar aşa de greu)
Din vreuna dintre DF de mai sus este tranzitivă, tabela
respectivă nu este în 3 NF
Dacă oricare din R1, R2, R3 nu este în 3 NF va trebui spartă
(chiar de mai multe ori, în unele cazuri)
DF tranzitive în BD FACTURARE (1)
CodCl
T
NrFact NumeCl
CodCl
T
NrFact AdresaCl
CodCl
NrFact T
LocalitCl
CodCl
T
NrFact CodPersContact
CodCl
NrFact T
NumePersContact
DF tranzitive în BD FACTURARE (2)
CodCl
T
NrFact TelPersContact

CodCl
T
NrFact EMailPersContact
CodPersContact
T
CodFiscalCl NumePersContact
CodPersContact
T
CodFiscalCl TelPersContact
CodPersContact
T
 Trecerea BD FACTURARE
din 2NF în 3NF (1)
T
T T T
R1 { NrFact, DataFact , CodFiscalCl , NumeCl, AdresaCl, LocalitCl , CodPersContact
T T
T
, NumePersContact , TelPersContact, EMailPersContact }

R2 { CodProd , DenProd, UM, ProcTVAProd }

R3 { NrFact ,CodProd , Cant, PreţUnit }

R1’ {
 Trecerea BD FACTURARE
din 2NF în 3NF (2)

R1’ {CodFiscalCl , NumeCl , AdresaCl , LocalitCl , CodPersContact }

T T
T
, NumePersContact , TelPersContact , EMailPersContact }

R12’ {

R1 { NrFact , DataFact , CodFiscalCl}

R2 { CodProd , DenProd, UM, ProcTVAProd }

R3 { NrFact,CodProd , Cant , PreţUnit }

 BD FACTURARE în 3FN

R12’ {CodPersContact, NumePersContact,

TelPersContact, EMailPersContact}

R1’ {CodFiscalCl, NumeCl, AdresaCl,

LocalitCl, CodPersContact}

R1 {NrFact, DataFact, CodFiscalCl}

R2 {CodProd, DenProd, UM, ProcTVAProd}

R3 {NrFact, CodProd, Cant, PretUnit}

 BD FACTURARE în 3FN
(forma finală)
PERS_CON {CodPersContact, NumePersContact,
TelPersContact, EMailPersContact}

CLIENTI {CodFiscalCl, NumeCl, AdresaCl, LocalitCl,

CodPersContact}

FACTURI {NrFact, DataFact, CodFiscalCl}

PRODUSE {CodProd, DenProd, UM, ProcTVAProd}

PROD_FACT {NrFact, CodProd, Cant, PretUnit}

 Forma normală Boyce-Codd
În 2 NF se elimină (prin spargerea tabelei)
dependenţele în care sursele sunt sub-ansambluri
ale cheii primare (csau candidat) iar destinaţiile
atribute ne-cheie
În 3 NF se elimină (tot prin spargerea tabelei)
dependenţele în care sursele sunt atribute ne-cheie
iar destinaţiile tot atribute ne-cheie
Forma normală Boyce-Codd (BCNF) vizează
rezolvarea situaţiilor în care sursele DF sunt
atribute ne-cheie, însă destinaţiile sunt atribute din
cheie (vezi prezentarea 007)

 O problemă a schemei
BIBLIOTECA2 în 3 NF
Dintre tabele 3 NF ale BD BIBLIOTECA2,
una conţine un evident grad de redundanţă
EXEMPLARE_AUTORI_CC { Cotă, Autor,
CuvântCheie}
Pentru fiecare exmplar cumpărat dintr-o
carte, trebuie introduse în tabela
EXEMPLARE_AUTORI_CC înregistrări
pentru toate combinaţiile valorilor Cote-
Autori-CuvinteCheie pentru cartea respectivă
 A patra formă normală
Destul de rar întâlnită în practică
Se bazează pe eliminarea Dependenţelor
Multi-Valoare (vezi prezentarea 004)

O relaţie se află în 4NF dacă:

 Este deja în 3NF (sau BCNF)
 Nu conţine dependenţe multivaloare

O bază de date este în 4NF dacă toate relaţiile

care o alcătuiesc se află în 4FN
 Tabela care conţine o DMV
Dintre toate tabele discutate/obţinute în 3 NF,
una singură conţine DMV:
EXEMPLARE_AUTORI_CC { Cotă, Autor,
CuvântCheie}
Cotă Autor | CuvântCheie

Pe baza DMV tabela se descompune astfel:

EXEMPLARE_AUTORI { Cotă, Autor}
EXEMPLARE_CC { Cotă, CuvântCheie}
Schema BD BIBLIOTECĂ2 în 4 NF
EDITURI {Editura, LocSediuEd}
CĂRȚI {ISBN, Titlu, Editura, AnApariţie}
COTE {Cotă, ISBN}
EXEMPLARE_AUTORI { Cotă, Autor}
EXEMPLARE_CC { Cotă, CuvântCheie}

Pentru celelate BD – BIBLIOTECA3 şi

FACTURARE, schema 3NF se păstrează şi
în 4 NF
 O problemă din BIBLIOTECA3
nerezolvată nici în 4 NF
Dintre tabele 4NF ale BD BIBLIOTECA2, două
conţin un evident grad de redundanţă:
EXEMPLARE_AUTORI { Cotă, Autor}
EXEMPLARE_CC { Cotă, CuvântCheie}
Intuitiv, ne dăm seama că autorii şi cuvintele
cheie corespund unei cărţi (titlu, ISBN), şi nu
fiecărui exemplar (cotă) al cărţii
Situaţia este una mioritică întrucât, chiar dacă am
sesizat problema, nu avem ce face (noi am aplicat
corect principiile normalizării prin descompunere)
II. Normalizare
prin sinteză
 Precizări privind normalizarea prin
sinteză
Se bazează tot de dependenţele dintre atribute
◦ Funcţionale
◦ De incluziune
◦ Multi-valoare
Singura cerinţă de pornire este ca atributele să fie
atomice, fără a ne mai interesa care ar putea fi
eventuala cheie primară a relaţiei iniţiale
(universale) ce grupează toate atributele BD
Obţine schema BD direct în 3 NF (sau 4 NF)
Chiar dacă au fost propuse o serie de algoritmi,
noi de vom baza exclusiv pe graful dependenţelor
 Graful dependenţelor
Reprezintă grafic DF, DI şi DMV
Pentru DF:
◦ Baza săgeţii – sursa DF
◦ Vârful săgeţii – destinaţia DF
◦ Când sursa DF este compusă – conector
◦ DF parţiale şi tranzitive se identifică vizual în
diagramă/graf
Pentru DI folosim un simbol grafic care să
sugereze incluziunea
Pentru DMV folosim săgeţi cu vârful dublu
 Graful DF – BD FACTURARE

NrFact CodProd

ProcTVAProd
DataFact
CodFiscalCl UM
Cantit PretUnit
NumeCl DenProd
AdresaCl CodPersContact

LocalitCl
TelPersContact

NumePersContact EMailPersContact
 Cum se obţine din graf schema BD direct
în 4 NF
Pentru DF: fiecare sursă de DF (simplă sau
compusă) va genera o tabelă separată, în care
sursa va fi cheie primară, iar toate destinaţiile
sale vor fi atribute ne-cheie
Pentru DI: dependenţele de incluziune nu
generează tabele sau atribute, ci numai restricţii
referenţiale
Pentru DMV: se va crea câte o tabelă pentru
fiecare DMV, tabelă în care cheia primară va fi
alcătuită atât din sursă cât şi din destinaţie
 Decuparea tabelelor din graful BD
FACTURARE
NrFact CodProd

ProcTVAProd
DataFact
CodFiscalCl
R3{ , , , }
PretUnit UM
Cantit
NumeCl DenProd
2{ , , , }
AdresaCl CodPersContact
1{ ,
LocalitCl , }
TelPersContact
1’{ , , ,
, EMailPersContact }
NumePersContact
12’{ , , ,
}
FACTURARE - Schema obţinută pe
baza grafului (1)
PERS_CON {CodPersContact, NumePersContact,
TelPersContact, EMailPersContact}
CLIENTI {CodFiscalCl, NumeCl, AdresaCl, LocalitCl,
CodPersContact}
FACTURI {NrFact, DataFact, CodFiscalCl}

PRODUSE {CodProd, DenProd, UM, ProcTVAProd}

PROD_FACT {NrFact, CodProd, Cant, PretUnit}
FACTURARE - Schema obţinută
pe baza grafului (2)
BD FACTURARE şi, implicit, graful dependenţelor
nu conţine nici dependenţe de incluziune (DI), nici
dependenţe multivaloare (DMV)
Cele două scheme ale BD FACTURARE obţinute
prin descompunere şi prin sinteză sunt identice
Chiar dacă “desenarea” grafului este mai dificilă la
început, sinteza are câteva avantaje importante:
◦ Eventualele DF parţiale şi tranzitive pot fi identificate
vizual
◦ BD se obţine din graf direct în 3 NF (care este, în acest caz
şi 4 NF)
 Graful dependenţelor pentru BD
BIBLIOTECĂ
LocSediuEd Titlu
CuvântCheie
Editura
ISBN Autor
AnApariţie

Cotă
EDITURI {Editura, LocSediuEd}

CĂRȚI {ISBN, Titlu, Editura, AnApariţie}

CĂRȚI_CC { ISBN, CuvântCheie} COTE {Cotă, ISBN}

CĂRȚI_AUTORI { ISBN, Autor}

 Consideraţii privind schema BD
BIBLIOTECA obţinută prin sinteză
Întrucât la sinteză nu ne-am pus problema
cheii primare a relaţiei universale (iniţiale), ci
doar a atomicităţii atributelor BD, nu am mai
fost nevoiţi să urmărim, în paralel, cele două
filiere – BIBLIOTECA2 şi BIBLIOTECA3
Schema obţinută prin sinteză (graf) nu conţine
problema semnalată în 4 NF a BD
BIBLIOTECA2
Autorii şi cuvintele cheie sunt introduse la
nivel de titlu, nu la nivel de exemplar (cotă)
Descompunere versus sinteză - concluzii
Normalizarea prin descompunere este mai
“didactică”, dar cea prin sinteză mai simplă
Ambele se bazează pe dependenţe între atribute
Cea prin decompunere presupune trecerea
succesivă prin toate formele normale, în ce ce
filiera prin sinteză obţine schema BD direct în
3NF (sau chiar BCNF, 4FN, 5FN)
În cazul BD VÂNZĂRI, structura obţinută este
identică, în timp ce în cazul BD BIBLIOTECĂ
(“filiera” BIBLIOTECA2) nu
Schema obţinută prin sinteză este mai bună !
 Tutoriale video
 Normalization video
http://www.youtube.com/watch?v=c-Zfgg5Ayyc&feature=related

 NormalisationStreaming
http://www.youtube.com/watch?v=RJdBLASKZwg

 Normalisation Demonstration
http://www.youtube.com/watch?v=fg7r3DgS3rA&feature=related

 The Process of Normailisation in a Relational Database

http://www.youtube.com/watch?v=nQwgtLQG0hU&feature=related


Lecture - 8 Functional Dependencies and Normal Form
http://www.youtube.com/watch?v=YD8dhOmuVnY&feature=related

 UHCL 30a Graduate Database Course - Bernsteins Synthesis Algorithm

http://www.youtube.com/watch?v=Xslub-nHVss