Sunteți pe pagina 1din 7

CURSUL 3- Proiectarea BD relationale

Normalizarea relaiilor
E. F. Codd, a artat c ntr-o anumit form relaiile posed proprieti nedorite, pe
care le-a numit anomalii de actualizare:

Anomalia de tergere const n faptul c anumite date care urmeaz s fie terse,
fac parte din tupluri n care se gsesc i alte date care mai sunt necesare n
continuare, ori tergerea fcndu-se la nivelul tuplului, acestea se pierd.

Anomalia de adugare const n faptul c anumite date care urmeaz s fie


adugate fac parte din tupluri incomplete (pentru care nu se cunosc toate datele),
ceea ce face ca acestea s nu poat fi adugate.

Anomalia de modificare rezult din faptul c este dificil de modificat o valoare a


unui atribut atunci cnd ea apare n mai multe tupluri ale relaiei.

Pentru a nltura aceste anomalii, Codd a stabilit trei forme normale pentru relaii i a
introdus procesul de normalizare care se bazeaz pe noiunea de dependen
funcional (FD) ca relaie ntre atributele unei entiti ce are un caracter invariant.
Fie date dou atribute D i E i notm domeniul valorilor lui D cu DOM (D) i
domeniul valorilor lui E cu DOM (E) i o funcie f: DOM (D) DOM (E). Spunem
c f este o dependen funcional, dac pentru () d DOM (D) distinct i
corespunde o singur valoare e DOM (E). Atributul D se numete determinantul
dependenei, iar dependena se simbolizeaz D E. Dependena funcional poate fi
generalizat pe mai multe atribute: f: A1, A2, , An B1, B2, , Bm unde A1, A2, ,
An se numete partea stng iar B1, B2, , Bm se numete partea dreapt a FDului.
O dependen funcional f: DOM (D) DOM (E) este elementar (complet), dac
nu exist o alt dependen f: DOM (D) DOM (E), unde DOM (D) DOM (D)
sau, altfel spus, dac partea stng nu mai poate fi descompus astfel nct
rezultatul obinut s fie tot o dependen funcional. Dac f: D1, D2,, Dm, Dm + 1,
, Dn E i g: D1, D2,, Dm E sunt dou FD-uri, unde m < n, atunci atributele Dm
+ 1, , Dn se numesc atribute superflue pentru f, deoarece atributele D1, D2,, Dm
sunt suficiente pentru a-l determina funcional pe E. n aceast situaie spunem c E
este dependent parial de D1, D2,, Dn.
Fie R [A1, A2,, An] o relaie i K o submulime a mulimii de atribute (K {A1,
A2,, An}). Spunem c submulimea K este cheie primar pentru relaia R dac sunt
ndeplinite urmtoarele condiii:

() Ai K, Ai este dependent funcional pe K;

() K K, Ai nu este dependent funcional pe K.

Armstrong a introdus un set de axiome i reguli de inferen, care permit prelucrarea


dependenelor funcionale. Notnd cu M mulimea atributelor relaiei R, axiomele lui
Armstrong sunt:
A1. Reflexivitatea: dac A B M A B;

BD Cursul 3 NP

1/7

A2. Creterea: dac A B i X M AX BX;


A3. Tranzitivitatea: dac A B i B C A C.
Din cele trei axiome rezult urmtoarele reguli de inferen:
R1. Reuniunea: dac A B i A C A BC;
R2. Pseudotranzitivitatea: dac A B i XB C AX C;
R3. Descompunerea: dac A BC A B i A C.
a)
U
P#
X
Q
C
L
T

B#

P#

B#

P1
P1
P1
P1
P2
P2
P2
P3
P3
P4
P5

buc
buc
buc
buc
Kg
Kg
Kg
m
m
buc
buc

20
20
20
20
10
10
10
5
5
25
30

100
200
50
10
250
120
60
100
50
6
10

B1
B2
B3
B4
B5
B2
B3
B1
B4
B5
B2

Braov
Alba
Arad
Braov
Arad
Alba
Arad
Braov
Braov
Arad
Alba

400
500
550
400
550
500
550
400
400
550
500

0268
0258
0257
0268
0257
0258
0257
0268
0268
0257
0258

R2
P#

B#

R3
B#

P1
P1
P1
P1
P2
P2
P2
P3
P3
P4
P5

B1
B2
B3
B4
B5
B2
B3
B1
B4
B5
B2

100
200
50
10
250
120
60
100
50
6
10

B1
B2
B3
B4
B5

Braov
Alba
Arad
Braov
Arad

400
500
550
400
550

0268
0258
0257
0268
0257

b)
R1
P#

P1
P2
P3
P4
P5

buc
Kg
m
buc
buc

20
10
5
25
30
U

P#
X

C
B#

L
T

P#

Q
B#

c)
R31
B#
B1
B2
B3
B4
B5

R32
L
Braov
Alba
Arad

L
Braov
Alba
Arad
Braov
Arad

C
400
500
550

T
0268
0258
0257
C

B#

L
T

Figura 1 Normalizarea relatiilor


BD Cursul 3 NP

2/7

O relaie este n forma normal 1 (1NF), dac i numai dac toate atributele ei
conin numai valori atomice (fig. 1.a.).
Cheia primar a relaiei R este compus din P# i B#, iar atributele U, X, C, L i T nu
sunt complet dependente funcional de aceasta. De asemenea perechile de atribute (L,
C) i (L, T) sunt mutual dependente. Aceast relaie posed anomaliile de actualizare
prezentate mai nainte, de exemplu:

nu putem aduga un rnd pentru care nu cunoatem beneficiarul (B#) i localitatea


(L), deoarece conform regulii de integritate a entitii nici o component a cheii
primare (P#, B#) nu poate fi nul;

dac produsul P5 nu mai poate fi fabricat temporar, deci trebuie ters rindul(P5,
buc, 30, 10, B2, Alba, 500, 0258), nseamn c se pierd i informaiile despre
beneficiarul B2, care mai sunt necesare n continuare;

dac dup o perioad de timp intervine o schimbare a preurilor produselor,


modificarea acestora se face greu datorit faptului c acelai pre intervine n mai
multe rnduri din tabel (redundan mare).

Pentru a nltura anomaliile de actualizare, utiliznd operatorul de proiecie,


descompunem relaia R n trei relaii R1, R2 i R3 (fig. 1.b.) care sunt n forma
normal 2 (2NF) i care conserv datele din relaia R.
O relaie este n forma normal 2 (2NF) dac i numai dac este n 1NF i orice
atribut noncheie este complet dependent funcional de cheia primar.
Analiznd diagrama dependenelor funcionale asociat relaiei R3 din fig. 1. b,
observm existena dependenelor tranzitive B# L, L C i B# L, L T care
genereaz i ele anomalii de actualizare, cum sunt:

dac tergem tuplul referitor la beneficiarul B1 (B1, Braov, 400, 0268) se pierd
i datele referitoare la localitatea, codul potal i prefixul telefonic, care mai sunt
necesare;

modificarea codului potal (C) se face greu, datorit faptului c aceiai valoare
apare n mai multe tupluri (redundan mare);

nu putem aduga o nou localitate dac nu exist cel puin un beneficiar din
localitatea respectiv.

Pentru a nltura aceste anomalii, descompunem relaia R3 n dou relaii R31 i R32
(fig. 1.c.) care sunt n forma normal 3NF.
O relaie este n forma normal 3 ( 3NF ) dac i numai dac este n 2NF i
fiecare atribut noncheie nu este dependent tranzitiv pe cheia primar. Relaiile
R1, R2, R31 , R32 sunt n forma normal 3.
Avantajele modelului relaional
Fcnd o analiz a modelelor nerelaionale comparativ cu modelul relaional rezult
urmtoarele avantaje n favoarea celui din urm:

BD Cursul 3 NP

3/7

modelul relaional este un model simplu care permite utilizatorului s vad baza
de date ca o colecie de tabele (relaii) - o reprezentare mental larg accesibil att
informaticienilor ct i neinformaticienilor;

asigur independena fizic i logic a programelor de prelucrare fa de


structura datelor, eliminnd din schema conceptual i schemele externe toate
detaliile privind structura de memorare i strategiile de acces;

operaia de normalizare introdus de modelul relaional asigur gsirea structurii


optime a datelor prin nlturarea anomaliilor de actualizare i diminuare a
redundanei.

Prin introducerea conceptului de dependen funcional modelul relaional


depete stadiul limitat al reprezentrii datelor n calculator, avansnd spre
formalizarea elementelor de semantic ce guverneaz domeniul informaiilor;

este un model omogen, deoarece reprezint legturile i asocierile dintre relaii tot
prin relaii, spre deosebire de modelele ierarhic i reea care utilizeaz n acelai
scop conexiunea i respectiv setul.

suplee n comunicare cu utilizatorul neinformatician prin intermediul unor


limbaje neprocedurale de nivel nalt.

n funcie de complexitatea bazei de date, exist doua metode de proiectare a


modelului relaional:

Conceperea modelului relaional pe baza unui model conceptual semantic


(Entitate-Asociere). Modelul entitate-asociere permite modelarea realitii prin
intermediul unor concepte abstracte: entiti, asocieri i atribute. Aceasta este
metoda cea mai utilizat n practic, mai ales n cazul unor baze de date complexe.

Obinerea modelului relaional prin procesul de normalizare, care presupune


aplicarea formelor normale asupra unui set de atribute ce formeaz iniial un
singur tabel. n urma normalizrii va rezulta un set de tabele normalizate. Aceast
metod se poate aplica numai n cazul unor baze de date de dimensiuni mici.

Proiectarea modelului relaional prin normalizzare


Metoda se bazeaz pe primele trei forme normale (FN1, FN2, FN3) i presupune
parcurgerea urmtoarelor etape:
1. Inventarierea atributelor: Proiectantul va selecta atributele din diverse
documente utilizate n circuitul informaional: nomenclatoare (nomenclatorul
materialelor, lista furnizorilor etc.), documente primare i centralizatoare
(facturi, chitane, situaia aprovizionrilor, balana stocurilor etc.).
Exemplu:
Numr factur
Data factur
Cod furnizor
Denumire furnizor
Adresa

BD Cursul 3 NP

4/7

2. Specificarea regulilor de gestiune: diversele restricii/condiii impuse datelor


sunt atent studiate deoarece vor constitui logica dependenelor dintre atribute i
a regulilor de validare.
Exemplu:
- o factur este emis de un singur furnizor;
- codul materialului este unic;
- o factur conine mai multe materiale ;
- furnizorii pot fi numai persoane juridice etc.
Algoritmii de calcul sunt asimilai regulilor de gestiune.
3. Matricea dependeelor funcionale
Cod
Furnizor
Cod
Furnizor
Denumire
Furnizor
Adresa
Furnizor
Numr
Factur
Data
Factur

Denumire
Furnizor

Adresa
Furnizor

Numr
Factur

Data
Factur

1T

1T

n acest caz, dependenele funcionale dintre atribute sunt reprezentate prin valoarea
1 pe linie iar cele tranzitive au fost marcate cu 1T. Dependenele dintre aceleai
atribute pot fi reprezentate i prin intermediul unui graf:
Denumire Furnizor
Cod Furnizor

Adresa Furnizor

Numr Factur

Data Factur
Graful dependeelor funcionale

n aceast variant, dependenele funcionale sunt reprezentate prin sgei iar cele
tranzitive prin sgei punctate.

BD Cursul 3 NP

5/7

4. Pentru atributele rmase izolate se vor cuta grupuri de cmpuri ce pot constitui
determinani ai acestora. Toate atributele (grupuri de atribute) determinante
devine chei candidate. Cheile candidate ce vor aparine aceluiai tabel sunt
caracterizate prin dependene funcionale reciproce (CodFurnizor<>DenumireFunizor, CodFurnizor<->Adresa)
5. Se stabilesc cheile primare dintre atributele candidate. Exemplu: CodFurnizor,
NumrFactur
6. Cu fiecare cheie primar i atributele determinate direct (netranzitiv) de aceasta
se va forma o relative(un tabel). Exemplu:
Furnizor(CodFurnizor, DenumireFurnizor, AdresaFurnizor)
Factur(NumrFactur, Data, CodFurnizor)
7. Se stabilesc cheile externe (cmpuri ce sunt chei primare n alte tabele)
Exemplu:
Furnizor(CodFurnizor, DenumireFurnizor, AdresaFurnizor)
Factur(NumrFactur, Data, CodFurnizor)
Exemplu
Se dorete realizarea unei baze de date pentru gestiunea comenzilor primite de la
clieni. Firma dispune de un catalog de produse n care sunt menionate codul,
denumirea i unitatea de msur . Clienii firmei sunt persoane fizice despre care se
cunosc: codul clientului, numele, localitatea, adresa, i numrul de telefon la
care se pot cere detalii suplimentare. Comenzile primite sunt numerotate i datate
consemnndu-se termenul de livrare exprimat n zile. Pe unele comenzi se poate
specifica i un procent de discount ce se aplic la valoarea total a comenzii. Pentru
fiecare produs solicitat pe comand se va preciza preul unitar i cantitatea
comandat calculnd valoarea produsului. n final se consemneaz valoarea total,
valoarea discountului i suma de plat.
Reguli de gestiune:
1. Un client poate efectua oricte comenzi dar o comand aparine unui singur
client
2. Pe o comand pot figura oricte produse
3. Preurile produselor sunt variabile n timp i negociabile cu clienii
4. Procentele de discount acordate sunt variabile
Valoarea produsului I = Cantitate I * Pret unitar I
ValoareTotal = Cantitatei * Preti
Valoare Discount = ValoareTotala x ProcentDiscount
SumaDePlat = ValoareTotal ValoareDiscount

BD Cursul 3 NP

6/7

Matricea dependenelor funcionale(nu sunt luate n considerare atributele


calculate)
Denumire atr
1.CodProdus
2. Denumire
3. Um
4. CodClient
5. NumeC
6. Localitate
7. Adresa
8. Telefon
9. NrCom
10. Data C
11. Termen
12. Discount
13. Pret U
14 Cant
15 1+ 9

2
1

3
1

1T

1T

1T 1T

10

11

12

13

14

Observaii:
1. n momentul crerii tabelelor se ine cont de faptul c atributele NumeC,
Localitate, Adresa i Telefon sunt determinate tranzitiv de ctre NrFactur prin
intermediul Codului de client (au fost marcate cu 1T).
2. ntruct pentru atributele Pret U i Cant nu s-a gsit nici un determinant s-a
recurs la un determinant compus format din CodProdus i NrComand
Modelul relaional rezultat este urmtorul:
Produse(CodProdus, DenumireProdus, UM)
Clienti (CodClient, Nume, Localitate, Adresa, Telefon)
Comenzi(NrComanda, DataComanda, Termen, Discount, CodClient)
ContinutComenzi(CodProdus, NrComanda, Cantitate, PretUnitar)

BD Cursul 3 NP

7/7

15