Proiectarea BD Tema 6 Normalizarea Relațiilor

NORMALIZAREA BAZELOR
DE DATE
1
Întrebări:
1. Esența normalizării bazelor de date
2. Normalizarea prin descompunere
3. Forme normale
4. Normalizarea prin sinteză
2
ESENȚA NORMALIZĂRII
BAZELOR DE DATE
3
Necesitatea normalizării
• Normalizarea precede etapa de implementare a BD deoarece

aceasta implică unele modificări de structură în modelul creat
(schimbări de entități, atribute sau relații).
• Forma nenormalizată (UNF – Unnormalized Form) a unui tabel
din BD include date repetitive. Un astfel de tabel nu este considerat
„relație” în BD sau BD respectiva nu poate fi considerată ca fiind
relațională.
• Erorile de actualizare care pot să apară într-o bază de date
nenormalizată se clasifica în trei categorii:
– erori de inserare de noi date sau înregistrări cauzate de
incoerența unor relații din schema relațională.
– erori de modificare sunt cauzate de dublarea datelor în tabele.
– erori de ștergere determină pierderea unor date din BD.
4
Anomaliile și erorile de actualizare, care apar în lucrul cu baza de date, se
produc datorita dependențelor care există între datele din cadrul relațiilor
bazei de date.
Să examinăm relația Avion în formă nenormalizată cu constrângerea:

toate avioanele cu acelasi nume au aceeasi capacitate.
Datorită dependenței introduse pot exista: anomalii la inserare,

modificare sau ștergere, redundanța in date, probleme de reconexiune.
5
1. Redundanta logica. Tuplul (AIRBUS, 250) apare de trei
ori.
2. Anomalie la inserție. S-a cumpărat un B727 cu 150 locuri.

El poate fi inserat in relația AVION doar daca se definește o
noua valoare pentru cheia primara.
6
3. Anomalie la ștergere. Daca este ștearsa înregistrarea
pentru care A# este 4, atunci se pierde informația ca un avion
CAR are capacitatea 100.
4. Anomalie la modificare. Daca se modifica capacitatea lui

B707 de la 150 la 170, atunci costul modificării este mare
pentru a modifica toate înregistrările, iar daca se modifică
doar o înregistrare, atunci constrangerea nu va mai fi
verificata.
7
5. Problema re-conexiunii. Consideram schemele relaționale:
AVION1 = PROJECT(AVION, A#, nume)
AVION2 = PROJECT(AVION, nume, capacitate, localitate)
AVION3 = JOIN(AVION1, AVION2).
Se observa ca schema AVION3 este diferita de AVION.

Apare un tuplu nou: (3, AIRBUS, 250, PARIS).
#A nume
nume capacitate localitate
1 AIRBUS
AIRBUS 250 PARIS
2 AIRBUS
AIRBUS 250 LONDRA
3 AIRBUS
CAR 100 PARIS
4 CAR
B707 150 LONDRA
5 B707
6 B707
8
Esența normalizării bazelor de date
În procesul modelării unei baze de date relaționale, o etapă
importantă o reprezintă normalizarea relațiilor conceptuale (Codd,
1972), adică obținerea de relații „moleculare“ fără a pierde nimic din
informație pentru a elimina:
• redundanța;
• anomaliile reactualizării informațiilor;
• rezolvarea problemei re-conexiunii
Tehnica normalizării permite obținerea unei scheme
conceptuale rafinate printr-un proces de ameliorare progresiva a
unei scheme conceptuale inițiale a bazei de date relaționale. După
fiecare etapa de ameliorare, relațiile bazei de date ating un anumit grad
de perfecțiune, deci se află intr-o anumită formă normală. Trecerea
unei relații dintr-o formă normală în alta, presupune eliminarea unor
dependențe nedorite de un anumit tip, care sunt transformate in
dependențe admisibile, adică dependențe care nu provoacă anomalii.
9
Esența normalizării bazelor de date
Normalizarea este un procedeu de identificare a setului
optim de relații, bazat pe dependentele functionale dintre
atribute, care are ca scop crearea unui model logic de date valid,
neredundant, care să elimine riscurile de apariție a anomaliilor
de reactualizare a datelor în baza de date.
Procesul de ameliorare a schemei conceptuale trebuie:
• să garanteze conservarea datelor, adică în schema conceptuală
finală trebuie sa figureze toate datele din cadrul schemei
inițiale;
• să garanteze conservarea dependențelor dintre date, adică in
schema finală fiecare dependență trebuie sa aibă
determinantul și determinatul în schema aceleiași relații;
• să reprezinte o descompunere minimală a relațiilor inițiale,
adică nici una din relațiile care compun schema finală nu
trebuie sa fie conținută intr-o altă relație din această schemă.
10
NORMALIZAREA PRIN
DESCOMPUNERE
11
Normalizarea prin descompunere
Exista doua metode pentru a modela baze de date relaționale fără
anomalii sau pierderi de informație.
• Schema descompunerii pleacă de la o schemă relațională
universală ce conține toate atributele BD. Schema se descompune
prin proiecții succesive în subrelatii. Descompunerea se oprește
când continuarea ei ar duce la pierderi de informatie. Algoritmii
de descompunere se bazează, în general, pe descrierea formală a
dependenței dintre atribute.
• Schema sintezei pleacă de la o mulțime de atribute independente
din mulțimea universală a bazei de date. Utilizând proprietăți de
semantică și legături între atribute se pot compune noi relații, astfel
încât, acestea să nu sufere de anumite anomalii. Algoritmii se
bazează, in general, pe teoria grafurilor pentru a reprezenta legătura
intre atribute.
12
• Teoria matematica a normalizării prin descompunere a

relațiilor a fost elaborată de E.F. Codd.
• Normalizarea este un proces reversibil de transformare a
unei relații, în relații de structură mai simplă (forme
normale).
• O relație este intr-o formă normală particulară dacă ea
satisface o mulțime specificată de constrângeri.
• Procesul normalizării se realizează plecând de la o relație
universală ce conține toate atributele sistemului de
modelat, plus o mulțime de anomalii.
• Orice forma normală se obține aplicând o schemă de
descompunere.
13
Exista doua tipuri de descompuneri:
• Descompuneri ce conserva dependentele. Aceasta descompunere
presupune desfacerea relației R in proiecțiile R1, R 2, ..., Rk , astfel
încât dependentele lui R sunt echivalente (au închideri pseudo-
tranzitive identice) cu reuniunea dependentelor lui R1, R2, ..., Rk.
• Descompuneri fără pierderi de informatie (L-join). Aceasta
descompunere presupune desfacerea relatiei R intr-o multime de
proiecții R1, R2, ..., Rj, astfel încât pentru orice realizare a lui R este
adevărată relația:
14
Regula Casey-Delobel
15
Regula Casey-Delobel
Pentru exemplul analizat anterior:

α = {nume},
β = {capacitate},
γ = {A#, localitate}.
Aplicând regula Casey-Delobel se obțin schemele:

AVION1(nume#, capacitate)
AVION2(A#, nume, localitate).
250
16
FORME NORMALE
17
Forme normale
Există 6 forme normale ale bazei de date relaționale:
· Prima formă normală (sau FN 1).
· A doua formă normală (sau FN 2).
· A treia formă normală (sau FN 3).
· Forma normală Boyce Codd (sau FNBC).
· A patra formă normală (sau FN 4).
· A cincea formă normală (sau FN 5).
Fiecare dintre cele 6 forme normale este mai restrictivă ca predecesoarea sa.
18
Reţeta clasică a normalizării
• se inventariază toate atributele şi se constituie astfel relaţia universală
(mulțimea tuturor atributelor BD);
• se determină cheia primară a relaţiei universale şi se reprezintă toate
dependențele funcţionale (DF) ce decurg de aici;
• se inventariază toate dependențele funcţionale revelate şi ireductibile
dintre atributele relaţiei universale;
• se elimină dependențele parţiale prin ruperea relaţiei universale în relaţii
cu schemă mai simplă;
• din relaţiile obţinute se elimină dependenţele tranzitive, prin spargerea
succesivă a relaţiilor în altele cu schema din ce în ce mai simplă, astfel
încât nici una din tabelele finale nu conţine dependențe parţiale sau
tranzitive;
• se identifică eventualele dependenţe multivaloare şi, dacă există
asemenea dependențe, se operează noi descompuneri ale tabelelor ce vor fi,
astfel, în FN4;
• se încearcă determinarea eventualelor dependenţe de joncţiune şi, pe baza
acestora, relaţiile sunt aduse în FN5;
19
FORMA NORMALĂ 1
20
Forma normală 1 (FN1)
O relație este in prima forma normală, daca fiecărui

atribut care o compune ii corespunde o valoare indivizibila
(atomica).
Scopul formei normale unu este acela de a simplifica
structura unei relaţii prin obţinerea asigurării că ea nu conţine
date care mai pot fi descompuse sau date generatoare de valori
repetitive, ceea ce înseamnă faptul că nici un atribut nu poate
avea o mulţime de valori.
Prin acţiunea specifică de descompunere, atributele ce nu
respectă aceste condiţii sunt plasate în relaţii separate,
păstrându-se atribute de legătură care au acelaşi tip de dată şi
aceeaşi dimensiune.
21
O bază de date este în forma normală unu (FN1) dacă
toate relațiile (tabelele) sunt în forma normală unu.
Pentru a transforma o relație în prima formă normală

trebuie să fie respectate câteva reguli simple :
❖Regula 1: Atributele au o valoare atomară.
❖Regula 2: Domeniul de valori ale atributului nu se
schimbă (în fiecare coloană, valorile stocate
trebuie să fie de același tip).
❖Regula 3: Se utilizează o denumire unică pentru
atribute (coloane).
❖Regula 4: Ordinea tuplurilor în relație (tabel) nu
contează.
❖Regula 5: Fiecare relație (tabel) are o cheie primară.
22
Exemplu 1. Tabel cu încălcări a FN1 (mai multe valori semnificative în același câmp)
23
Posibilele variante de tabele în forma normală 1 cu chei simple sau compuse:
24
Exemplu 2. Aducerea tabelului nenormalizat la FN1 cu cheie simplă
25
Exemplu 3. Aducerea tabelului nenormalizat la FN1 cu cheie simplă
26
Exemplu 4. Aducerea tabelului nenormalizat la FN1 cu cheie compusă
roll_no name subject # roll_no name # subject

101 Albu OS, PHP 101 Albu OS
103 Crudu Java 101 Albu PHP
102 Bunu C, C++ 103 Crudu Java
102 Bunu C
102 Bunu C++
Aducerea unei relații în forma normală unu duce la creșterea redundanței

datelor, deoarece vor exista multe coloane cu aceleași date în mai multe
rânduri, dar fiecare rând în ansamblu va fi unic.
27
FORMA NORMALĂ 2
28
O relație R este în forma normală doi (FN2) dacă și numai dacă:
• Relația R este în FN1;
• Fiecare atribut care nu este cheie (nu participă la cheia primară)
este dependent de întreaga cheie primară.
A doua forma normala cere ca toate elementele unui tabel să fie

dependente funcțional de toate atributele cheii primare. Cu alte
cuvinte – lipsește dependența parțială a atributelor de cheia primară.
Dacă unul sau mai multe atribute sunt dependente funcțional numai
de o parte a cheii primare, atunci ele trebuie sa fie separate in tabele
diferite.
Dacă tabelul are o cheie primară formată din numai un atribut,

atunci ea este automat in FN2 (a 2-a forma normala).
29
Exemplu 1 . Tabelul în FN1
Tabele în FN2
30
Exemplu 2 . În relația Comanda aflată în FN1 cheia primara este o
cheie compusa, formata din #ComandaID și #ReperID. ReperNume
depinde numai de #ReperID, nu și de #ComandaID.
Tabele în FN2
31
Exemplu 3. fie avem trei relații Student, Subiect și Scor în FN1
# student_id name branch address # subject_id subject_name

1 Java
10 Albu INFA Orhei
2 C++
11 Albu IT Chisinau
3 Php
#student_id #subject_id marks teacher

10 1 70 Java Teacher
10 2 75 C++ Teacher
11 1 80 Java Teacher
Relațiile Student și Subject sunt și in FN2. În relația Score atributul

Teacher depinde doar de subject_id, și nu de întreaga cheie.
32
Exemplu 3. Aducerea relațiilor Student, Subiect și Scor la FN2
# student_id name branch address

10 Albu INFA Orhei
11 Albu IT Chisinau
# subject_id subject_name teacher

1 Java Java Teacher
2 C++ C++ Teacher
3 Php Php Teacher
# student_id # subject_id marks

10 1 70
10 2 75
11 1 80
33
• Începând cu a doua formă normală, relaţiile pot fi decupate în sub-

relaţii, în scopul diminuării problemelor legate de stocare şi actualizare.
În general, atunci când într-o relaţie R există o dependență funcțională
de tip X → Y şi X nu este cheie candidată, este sigur că R conţine o
anumită doză de redundanţă.
• Savantul Jan Heath a demonstrat că orice relaţie alcătuită din trei
atribute, notat( R(X, Y, Z), în care există dependenţa funcţională X → Y
poate fi descompusă în două relaţii R1(X, Y) şi R2(X, Z); R1 şi R2
reprezentă proiecţiile relaţiile R pe atributele X şi Y, respectiv X şi Z.
• Esenţial este faptul că descompunerea să se facă fără pierdere de
informaţii, adică R să poată fi "recompusă" prin joncţiunea tabelelor R1
şi R2. Astfel, se poate rezolva problema cheii primare a relaţiei
universale, în cazurile încălcării restricţiei de entitate (un atribut din
cheia primară prezintă valori nule).
34
Regula Casey-Delobel pentru FN2.
Pentru a obține o relație FN2 se poate aplica regula Casey-Delobel.
Fie relația R(K1, K2, X, Y), unde K1 si K2 definesc cheia primară,

iar X si Y sunt mulțimi de atribute, astfel încât K1 → X.
Din cauza dependentei funcționale K1 → X care arată că R nu este

in FN2, se înlocuiește R (fără pierdere de informație) prin două
proiecții R1(K1, K2, Y) și R2(K1, X).
35
Exemplu 4. Presupunem că un șantier poate executa mai multe

lucrări de bază și că o lucrare poate fi executată pe mai multe
șantiere.
LUCRARE(cod_obiectiv#, cod_lucrare#, denumire);

ȘANTIER(nr_șantier#, șef);
EXECUTA(cod_obiectiv#, cod_lucrare#, nr_șantier#, descriere,
funcție, conducător, data_început, data_sfârsit).
Pentru relația EXECUTA sunt evidente dependențele:
{cod_obiectiv#, cod_lucrare#} → {data_început, data_sfârsit},

{cod_obiectiv#, cod_lucrare#, nr_șantier#} →{descriere,
funcție, conducător}.
36
Relatia EXECUTA este in FN1, dar nu este in FN2, deoarece

atributele data_început și dată_sfarsit nu depind de numărul
șantierului, deci nu depind de întreaga cheie primară.
Pentru a obține o relație in FN2 se aplica regula Casey Delobel

și relația EXECUTA se desface in:
EXECUTA_1(cod_obiectiv#, cod_lucrare#, nr_șantier#,

descriere, funcție, conducător)
EXECUTA_2(cod_obiectiv#, cod_lucrare#, data_început,

data_sfârsit).
37
Exemplu de descompunere în forma normală 2
• Să examinăm o relație LOCALITĂȚI în FN1 prezentată în tabel.

• Se aplică constrângeri:
– Un oraş sau o comună au un singur cod poştal:
– Într-o comună sunt mai multe sate.
CodPoştal OraşComună Sat Judeţ

5319 Vînători Vînători Vrancea
5319 Vînători Jorăşti Vrancea
5319 Vînători Mirceştii-Vechi Vrancea
5613 Roznov Roznov Neamţ
5613 Roznov Slobozia Neamţ
5300 Focşani NULL Vrancea
38
• Cheia primară a relaţiei LOCALITĂŢI (#CodPoştal, #Sat)
prezintă problema nulităţii unuia dintre atributele
componente, deoarece se încalcă restricţia de entitate (pentru
liniile care se referă la oraşe valoarea atributului Sat este
NULL).

39
• Cu toate acestea se poate scrie:
(1) (CodPoştal, Sat) —→ OraşComună
(2) (CodPoştal, Sat) —→ Judeţ
• Dar:
(3) CodPoştal —→ OraşComună
(4) CodPoştal —→ Judeţ
deci dependențele (1) şi (2) sunt DF parţiale.

40
• Relaţia LOCALITĂȚI poate fi descompusă în două relații în FN2:
ORAȘE_COMUNE (CodPoștal, OrașComună, Județ)
SATE (CodPoștal, Sat)
• A fost eliminată redundanța. În LOCALITĂŢI, dacă o comună are şase sate,
de şase ori apare şi codul poştal al comunei, şi denumirea comunei şi a
judeţului. Acum însă, denumirea comunei şi judeţului apare o singură dată în
relaţia ORAŞE_COMUNE. De asemenea, pentru fiecare oraş apare o
singură înregistrare în ORAŞE_COMUNE şi, firesc, nici una în SATE.
SELECT oc.codpostal, orascomuna,

sat, judet
FROM orase_comune oc LEFT
OUTER JOIN sate s
ON oc.codpostal=s.codpostal
41
FORMA NORMALĂ 3
42
43
44
Exemplu 1. Tabelul Piese de schimb, in care cheia primara (și cheie unica)
este #Piese_de_schimb este în FN2 și conține dependență tranzitivă
ProducatorNume →ProducatorAdresa
El se reorganizează în două tabele Piese de schimb și Producător în FN3:
45
Exemplu 2. Fie avem relațiile Student, Subiect și Scor în FN2
# student_id name branch address

10 Albu INFA Orhei
11 Albu IT Chisinau
# subject_id subject_name teacher

1 Java Java Teacher
2 C++ C++ Teacher
3 Php Php Teacher
# student_id # subject_id marks

10 1 70
10 2 75
11 1 80
46
Dorim să modificăm relația Scor, prin adăugarea în ea a două atribute
exam_name și total_marks
student_id subject_id marks exam_name total_marks
Cheia primară a tabelului Scor este o cheie compusă student_id +

subject_id. Atributul exam_name depinde atât de student, cât și de subiect.
De exemplu, un student în inginerie mecanică va avea examen de atelier, dar
un student la informatică nu. Și pentru unele subiecte (materii) sunt prevăzute
examene practice, iar pentru altele nu. Deci putem spune că atributul
exam_name depinde atât de student_id, cât și de subject_id.
Atributul total_marks depinde doar de atributul exam_name,
scorul total modificându-se în funcție de tipul examenului. De exemplu,
practicile pot fi notate cu note mai mici, în timp ce examenele teoretice sunt
notate cu note mai mari, sau invers.
Atributul exam_name este un atribut simplu și nu face parte din cheie
primară, iar atributul total_marks depinde de acesta. Aceasta este o
dependența tranzitivă. 47
Descompunerea relației Scor în două relații Scor și Examen, ambele în
forma normală trei (FN3)
# student_id #subject_id marks # exam_id
# exam_id exam_name total_marks

1 Workshop 200
2 Mains 70
3 Practicals 30
48
Exemplul 3 . În relația EXECUTA_1(cod_obiectiv#, cod_lucrare#,
nr_santier#, descriere, funcție, conducător) continua sa existe redundanța
in date.
Atributul conducător depinde indirect de cheia primară prin intermediul
atributului funcție. Intre atributele relației exista dependențele:
{cod_obiectiv#, cod_lucrare#, nr_santier#} → {descriere},

{cod_obiectiv#, cod_lucrare#, nr_santier#} → {funcție} → {conducător}.
Pentru a aduce relația EXECUTA_1 in FN3 se aplica regula Casey-

Delobel. Relația se desface, prin eliminarea dependențelor funcționale
tranzitive, in proiecțiile:
EXECUTA11(cod_obiectiv#, cod_lucrare#, nr_șantier#, descriere,

funcție)
EXECUTA12(funcție, conducător).
49
FORMA NORMALĂ BOYCE-
CODD
50
Forma normală Boyce-Codd (FNBC)
• O schemă de relaţie R se află în FNBC dacă, pentru toate dependenţele
funcţionale ce au loc în R şi sunt de forma X→Y în care X R şi Y R
sunt îndeplinite condiţiile:
• X → Y este trivială.
• X este o cheie candidat a schemei de relaţie R astfel încât X→R.
• Cu alte cuvinte, fiecare atribut trebuie să depindă de cheie, de întreaga
cheie şi de nimic altceva.
• FNBC este o generalizare a formelor normale doi şi trei.

• Forma normală Boyce-Codd e o versiune puțin mai restrictivă de forma
normala 3.
• Pentru ca o relație să fie în forma Normală Boyce-Codd, ea trebuie să

satisfacă DOUĂ CONDIȚII:
❖ Să fie în FN3 (Third Normal Form)
❖ Pentru orice dependență A → B, A trebuie să fie o super cheie.
51
Exemplu 1. Fie avem relația Subiect în FN3. În această relație student_id + subject
formează cheia primară, deoarece folosind student_id și subject, putem găsi toate
valorile tabelului.
# student_id # subject professor
101 Java P.Java
101 C++ P.Cpp
102 Java P.Java2
103 C# P.Chash
104 Java P.Java
Important este că un profesor predă o singură materie, dar o disciplină poate
avea doi profesori diferiți. Prin urmare, există o dependență între subiect și profesor,
unde subiectul depinde de numele profesorului.
Acest tabel satisface prima formă normală, deoarece toate valorile sunt
atomice, numele coloanelor sunt unice și toate valorile stocate într-o anumită coloană
sunt de același domeniu. Acest tabel satisface formă normală doi , deoarece nu există
dependență parțială. Și nu există o dependență tranzitorie, prin urmare, tabelul
satisface și a 3-a formă normală.
52
# student_id # subject professor

101 Java P.Java
101 C++ P.Cpp
102 Java P.Java2
103 C# P.Chash
104 Java P.Java
Dar acest tabel nu este în forma normală Boyce-Codd.

• În tabelul de mai sus, student_id și subject formează cheia primară, ceea ce
înseamnă că atributul subject este un atribut primar.
• Dar mai există o dependență, professor → subject.
• Și, în timp ce subject este un atribut prim, atributul professor este un atribut non-
primar si nu este cheie candidat, ceia ce nu este permis de FNBC.
53
Pentru ca relația Subiect să satisfacă FNBC, vom descompune acest tabel în

două tabele, tabelul Student și tabelul Professor (nu iutăm de constagerea aplicată un
profesor- o disciplină)
# student_id # p_id # p_id professor subject
101 1 1 P.Java Java
101 2 2 P.Cpp C++
102 3 3 P.Java2 Java
103 4 4 P.Chach C#
104 1
54
Forma normală Boyce-Codd (BCNF)
• De remarcat este faptul că nu întotdeauna este posibilă descompunerea
în FNBC cu păstrarea dependenţelor.
Exemplu 3. Să examinăm relația ADRESA(cod_persoana#, telefon#, adresa) .

În dependenta adresa →telefon se observă că determinantul nu este o cheie
candidat.
Regula Casey Delobel pentru R(K1#, K2#, X) presupunând că există dependența

X→K2 duce la descompunerea R1(K1#, X) și R2(X#, K2).
Ca urmare a acestei reguli relația ADRESA se desface in două relații:
ADRESA_1(cod_persoana#, adresa);
ADRESA_2(adresa#, telefon).
Relațiile sunt în BCNF, se conservă datele, dar nu se conservă dependentele (s-a

pierdut cod_persoana, telefon→ adresa).
55
Algoritmul de aducere a unei relații R din FN1 în BCNF
Pentru ca o relație să fie adusă în BCNF nu trebuie în mod

obligatoriu să fie in FN3. Se pot aduce în BCNF și relații aflate în FN1 sau
FN2. Acest lucru este posibil întrucât dependentele funcționale parțiale și cele
tranzitive sunt tot dependențe noncheie, adică dependențe ai caror
determinanți nu sunt chei candidat.
• Pas 1. Dacă relația conține cel mult două atribute, atunci R este în
BCNF și algoritmul s-a terminat..
• Pas 2. Dacă relația conține mai mult de două atribute, se consideră
toate perechile posibile (X,Y) de atribute distincte din mulțimea
atributelor A.
• Pas 3. Se determină A1+ , închiderea mulțimii A1=A-{X,Y}.
• Pas 4. Dacă pentru orice pereche (X,Y), X A1+ , atunci relația R este
în BCNF și algoritmul s-a terminat.
• Pas 5. În caz contrar (pentru orice pereche (X,Y), X aparține A1+ ),
relația R nu este în BCNF.
• Pas 6. Se reduce progresiv schema relației și se reia algoritmul
explorând relația redusă.
56
FORMA NORMALĂ 4
57
Forma normală patru (FN 4)
Forma normală patru se bazează pe conceptul de
dependenţă multivalorică.
O dependenţă multivalorică apare doar în relaţiile ce au cel
puţin trei coloane. Dacă una dintre coloane are rânduri ale
căror valori corespund unei singure valori ale unui rând dintr-
o altă coloană, atunci se spune că a apărut o dependenţă
multivalorică.
O relaţie se află în forma normală patru (FN4) dacă şi

numai dacă se află în forma normală Boyce-Codd şi dacă
nu are dependenţe funcţionale multivalorice.
FN4 elimina redundanțele datorate relațiilor m:n,

datorate dependentei multiple.
58
59
Exemplu 1. Fiecare restaurant livrează un tip de pizza intr-o arie de distribuție. Pentru ca
aici cheia primară este formata din (#Restaurant, #Tip de pizza, #Aria de distributie) și
nu există atribute non-cheie, nu se încalcă nici o forma normală anterioară (1, 2, 3 ori
BCNF). Dar deoarece varietățile de pizza oferite de un restaurant sunt independente de
ariile de distribuție, există redundante in tabel: pentru fiecare restaurant Jerry’s, se
menționează de 3 ori ca se oferă Tip de pizza “Pufos”. De asemenea, dacă dorim să
adăugăm, de ex. tipul “Subțire” pentru Tip de pizza, la Jerry’s, va trebui sa adaugăm 3
înregistrări, cate una pentru fiecare Arie de distributie.
60
Exemplu 2. Fie avem relația Înscriere.
s_id course hobby Cele două înregistrări pentru s_id egal cu
1 Science Cricket 1, vor da naștere la alte două înregistrări,
așa cum se arată mai jos, deoarece pentru
1 Maths Hockey un student există două hobby-uri, prin
2 C# Cricket urmare, împreună cu ambele cursuri,
aceste hobby-uri ar trebui să fie
2 Php Hockey
specificate.
s_id course hobby Nu există nicio relație între atributele course

și hobby. Ele sunt independente unul de
1 Science Cricket celălalt.
1 Maths Hockey
Așadar, există o dependență cu mai multe
1 Science Hockey valori, ceea ce duce la repetarea inutilă a
1 Maths Cricket datelor și la alte anomalii.
61
Pentru ca relația de mai sus să satisfacă a patra formă normală, putem descompune
tabelul în 2 tabele (Curs și Hobby).
# s_id # course # s_id # hobby

1 Science 1 Cricket
1 Maths 1 Hockey
2 C# 2 Cricket
2 Php 2 Hockey
Acum relațiile satisfac a patra formă normală.
Un tabel poate avea, de asemenea, dependență funcțională, împreună cu

dependență multi-valorică. În acest caz, coloanele dependente funcțional sunt
mutate într-un tabel separat și coloanele dependente multi-valoric sunt mutate în
tabele separate.
62
Exemplu 3. Fie relația INVESTITIE(cod_contractant#, denumire,
telefon) și presupunem că un investitor poate avea mai multe numere de
telefon și că poate investi in mai multe obiective.
Între atributele relației exista multidependentele:

cod_contractant# →→ denumire;
cod_contractant# →→ telefon.
Relația INVESTITIE este in BCNF. Pentru a aduce relația in FN4 o vom

descompune prin proiecție in doua relații:
INVESTITIE_1(cod_contractant#, denumire),
INVESTITIE_2(cod_contractant#, telefon).
INVESTITIE = JOIN(INVESTITIE_1, INVESTITIE_2).
63
FORMA NORMALĂ 5
64
A cincea formă normală (FN 5)
A cincea formă normală se bazează pe conceptul de dependenţă de cuplare.
Dependenţa de cuplare este o proprietate ce garantează că nu se generează
înregistrări false la reunirea relaţiilor obţinute prin descompunere.
O relaţie se află în forma normală cinci dacă ea nu poate fi descompusă în
alte relaţii fără a pierde informaţie.
Cu alte cuvinte, dacă se adaugă un rând suplimentar unei relaţii care nu se află în
forma normală cinci şi dacă această relaţie se descompune în alte relaţii, prin refacerea
relaţiei iniţiale se obţin înregistrări false.
O dependenţă de cuplare (joncţiune) JD(R1, R2, ... ,Rn) reprezintă o
constrângere aplicată relaţiei R, care arată faptul că fiecare instanţă r(R) trebuie să
aibă pierdere de informaţie prin descompunerea în relaţiile R1, R2, ... , Rn.
O dependenţă multivalorică reprezintă un caz special al unei dependenţe de
cuplare în care n = 2.
Dependenţa de cuplare JD(R1, R2,..., Rn) este o dependenţă de cuplare trivială
dacă unele relaţii Ri = R.
O schemă de relaţie R se află în forma normală cinci referitor la o mulţime F de
dependenţe funcţionale, multivalorice, şi de cuplare dacă pentru fiecare dependenţă
de cuplare netrivială JD(R1, R2, ... , Rn) din F, fiecare Ri este o supercheie a lui R.
65
Ассортимент (#продавeц, #фирмa, #товар)

Продавец Фирма Товар
Иванов Рога и Копыта Пылесос
Иванов Рога и Копыта Хлебница
Петров Безенчук&Ко Сучкорез
Петров Безенчук&Ко Пылесос
Петров Безенчук&Ко Хлебница
Петров Безенчук&Ко Зонт
Сидоров Безенчук&Ко Пылесос
Сидоров Безенчук&Ко Телескоп
Сидоров Рога и Копыта Пылесос
Сидоров Рога и Копыта Лампа
Сидоров Геркулес Вешалка
66
Dacă nu există condiții suplimentare, atunci acest tabel, care este în a

4-a formă normală, este corect și reflectă toate restricțiile necesare.
Să presupunem acum că trebuie luată în considerare următoarea
restricție: fiecare vânzător are în sortimentul său o listă limitată de firme și o
listă limitată de tipuri de mărfuri și oferă bunuri din lista de produse fabricate
de firme de pe lista firmelor.
Adică vânzătorul nu are dreptul de a comercializa mărfuri de orice fel
de firme. Dacă vânzătorul P are dreptul de a comercializa mărfuri ale
companiei F, iar dacă vânzătorul P are dreptul de a comercializa mărfuri de tip
T, atunci în sortimentul vânzătorului P includ mărfuri de tip T ale companiei F,
cu condiția ca firma F să producă bunuri de tip T.
O astfel de restricție poate fi cauzată, de exemplu, prin faptul că lista
tipurilor de mărfuri ale vânzătorului este limitată de licențele de care dispune
sau de cunoștințele și calificările necesare pentru vânzarea lor, iar lista
companiilor fiecărui vânzător este determinată prin acorduri de parteneriat.
67
În acest exemplu, în special, se presupune că vânzătorul Ivanov are
dreptul de a comercializa bunuri numai de la compania Horns and Hoofs,
vânzătorul Petrov - numai mărfuri de la compania Bezenchuk & Co., dar
vânzătorul Sidorov nu are dreptul de a comercializa cutii de pâine și ferestrău
etc.
Relația propusă mai sus nu poate exclude situațiile în care această
restricție va fi încălcată. Nimic nu împiedică introducerea de date privind
vânzarea de bunuri pe care firma nu le eliberează deloc, nici datele privind
vânzarea de bunuri ale firmei pe care vânzătorul nu le servește, nici datele
despre vânzarea unui astfel de tip de mărfuri pe care vânzătorul nu are dreptul
să le vândă.
Relația nu este în 5NF, deoarece are o dependență de conexiune
netrivială *{{Vânzător, Firmă}, {Firmă, Produs}, {Vânzător, Produs}}, cu
toate acestea, subseturile de atribute {Vânzător, Firmă}, {Firmă, Produs},
{Vânzător , Produs} nu sunt superchei ale relației inițiale.
În acest caz, pentru a reduce relația inițială la 5NF, tabelul trebuie
împărțit în trei: {#Vânzător, #Firmă}, {#Firmă, #Produs}, {#Vânzător,
#Produs}.
68
Товары продавцов Фирмы продавцов Товары фирм
Продавец Товар Продавец Фирма Фирма Товар
Иванов Пылесос Иванов Рога и Копыта Рога и Копыта Пылесос
Иванов Хлебница Петров Безенчук&Ко Рога и Копыта Хлебница
Петров Сучкорез Сидоров Безенчук&Ко Рога и Копыта Лампа
Петров Пылесос Сидоров Рога и Копыта Безенчук&Ко Сучкорез
Петров Хлебница Сидоров Геркулес Безенчук&Ко Пылесос
Петров Зонт Безенчук&Ко Хлебница
Сидоров Телескоп Безенчук&Ко Зонт
Сидоров Пылесос Безенчук&Ко Телескоп
Сидоров Лампа Геркулес Вешалка
Сидоров Вешалка
69
Concluzii
1. FN1 > FN2 elimina redundantele datorate dependentei netotale a
atributelor care nu participa la o cheie, fata de cheile lui R. Se suprima
dependentele functionale care nu sunt totale.
2. FN2 > FN3 elimina redundantele datorate dependentei tranzitive. Se
suprima dependentele functionale tranzitive.
3. FN3 > BCNF elimina redundantele datorate dependentei functionale. Se
suprima dependentele in care partea stanga nu este o supercheie.
4. BCNF > FN4 elimina redundantele datorate multidependentei. Se
suprima toate multidependentele care nu sunt si dependente functionale.
5. FN4 > FN5 elimina redundantele datorate dependentei ciclice . Se suprima
toate join-dependentele care nu sunt implicate de o cheie.
6. BCNF, FN4 si FN5 corespund la regula ca orice determinant este o cheie,
dar de fiecare data dependenta cu care se defineste determinantul este alta
si anume dependenta functionala, multidependenta sau join-dependenta).
7. Descompunerea unei relatii FN2 in FN3 conserva datele si dependentele,
pe cand descompunerea unei relatii FN3 in BCNF si, respectiv, a unei relatii
BCNF in FN4 conserva doar datele.
70
NORMALIZAREA PRIN
SINTEZĂ
71
Schema de sinteza pentru obținerea lui FN3
Algoritmul de sinteza construieste o acoperire minimala F a

dependentelor funcționale totale.
❖ Se elimina atributele si dependențele funcționale redundante.
❖ Mulțimea F este partiționata in grupuri Fi , astfel încât in
fiecare grup Fi sunt dependențe funcționale care au același
membru stâng si nu există două grupuri având același membru
stâng.
❖ Fiecare grup Fi produce o schema FN3.
❖ Algoritmul realizează o descompunere ce conserva
dependentele.
72
Algoritm SNF3 (aducerea unei relatii in FN3 prin utilizarea unei scheme de sinteza)
73
74
75

Proiectarea BD Tema 6 Normalizarea Relațiilor

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proiectarea BD Tema 6 Normalizarea Relațiilor

Încărcat de

Drepturi de autor:

Formate disponibile

NORMALIZAREA BAZELOR

• Normalizarea precede etapa de implementare a BD deoarece

Să examinăm relația Avion în formă nenormalizată cu constrângerea:

Datorită dependenței introduse pot exista: anomalii la inserare,

2. Anomalie la inserție. S-a cumpărat un B727 cu 150 locuri.

4. Anomalie la modificare. Daca se modifica capacitatea lui

Se observa ca schema AVION3 este diferita de AVION.

• Teoria matematica a normalizării prin descompunere a

Pentru exemplul analizat anterior:

Aplicând regula Casey-Delobel se obțin schemele:

O relație este in prima forma normală, daca fiecărui

Pentru a transforma o relație în prima formă normală

roll_no name subject # roll_no name # subject

Aducerea unei relații în forma normală unu duce la creșterea redundanței

A doua forma normala cere ca toate elementele unui tabel să fie

Dacă tabelul are o cheie primară formată din numai un atribut,

# student_id name branch address # subject_id subject_name

#student_id #subject_id marks teacher

Relațiile Student și Subject sunt și in FN2. În relația Score atributul

# student_id name branch address

# subject_id subject_name teacher

# student_id # subject_id marks

• Începând cu a doua formă normală, relaţiile pot fi decupate în sub-

Fie relația R(K1, K2, X, Y), unde K1 si K2 definesc cheia primară,

Din cauza dependentei funcționale K1 → X care arată că R nu este

Exemplu 4. Presupunem că un șantier poate executa mai multe

LUCRARE(cod_obiectiv#, cod_lucrare#, denumire);

Pentru relația EXECUTA sunt evidente dependențele:

{cod_obiectiv#, cod_lucrare#} → {data_început, data_sfârsit},

Relatia EXECUTA este in FN1, dar nu este in FN2, deoarece

Pentru a obține o relație in FN2 se aplica regula Casey Delobel

EXECUTA_1(cod_obiectiv#, cod_lucrare#, nr_șantier#,

EXECUTA_2(cod_obiectiv#, cod_lucrare#, data_început,

• Să examinăm o relație LOCALITĂȚI în FN1 prezentată în tabel.

CodPoştal OraşComună Sat Judeţ

CodPoştal OraşComună Sat Judeţ

CodPoştal OraşComună Sat Judeţ

SELECT oc.codpostal, orascomuna,

El se reorganizează în două tabele Piese de schimb și Producător în FN3:

# student_id name branch address

# subject_id subject_name teacher

# student_id # subject_id marks

student_id subject_id marks exam_name total_marks

Cheia primară a tabelului Scor este o cheie compusă student_id +

# student_id #subject_id marks # exam_id

# exam_id exam_name total_marks

{cod_obiectiv#, cod_lucrare#, nr_santier#} → {descriere},

Pentru a aduce relația EXECUTA_1 in FN3 se aplica regula Casey-

EXECUTA11(cod_obiectiv#, cod_lucrare#, nr_șantier#, descriere,

• FNBC este o generalizare a formelor normale doi şi trei.

• Pentru ca o relație să fie în forma Normală Boyce-Codd, ea trebuie să

# student_id # subject professor

Dar acest tabel nu este în forma normală Boyce-Codd.

Pentru ca relația Subiect să satisfacă FNBC, vom descompune acest tabel în

Exemplu 3. Să examinăm relația ADRESA(cod_persoana#, telefon#, adresa) .

Regula Casey Delobel pentru R(K1#, K2#, X) presupunând că există dependența

Relațiile sunt în BCNF, se conservă datele, dar nu se conservă dependentele (s-a

Pentru ca o relație să fie adusă în BCNF nu trebuie în mod

O relaţie se află în forma normală patru (FN4) dacă şi

FN4 elimina redundanțele datorate relațiilor m:n,

s_id course hobby Nu există nicio relație între atributele course

# s_id # course # s_id # hobby

Acum relațiile satisfac a patra formă normală.