Proiectarea bazelor de date relaţionale

(anomalii de actualizare, dicţionar de

date, dependenţa datelor, normalizare
(FN1,FN2, FN3)
Anomalii de actualizare și anomalii de stocare
Tabel “Facturare”
 Anomalii de actualizare și anomalii de stocare
Tabel “Facturare”
• Anomalii la adăugare - adăugarea unui client nou, este condiționată de existența
unei facturi către acesta.
• Anomalii la modificare - dacă se schimbă denumirea unui produs, această operație
ar trebui realizată, în toate aparițiile produsului în cadrul tabelului. Dacă ar fi vorba
de mii de facturi, în care apare acel produs, ar trebui modificată denumirea în toate
înregistrările
• Anomalii la ștergere - ștergerea facturii cu numărul 3 are ca efect pierderea
informațiilor referitoare despre clientul “SC XYZ SA”, aceasta fiind singura apariție a
acestuia în cadrul tabelului
• Anomalii de stocare
▪ Redundanțe->Risipă de spațiu stocare
▪ Redundanțe->Producerea unor erori în date și/sau risipă de timp
▪ Atribute calculate ->Risipă de spațiu stocare
▪ Atribute calculate ->Producerea unor erori în date și/sau risipă de timp
 Proiectarea BD prin normalizare

SCOP:
❑Eliminarea anomalilor de actualizare
❑Definirea corectă a atributelor
❑Structurarea coerentă a acestora în tabele
❑Stabilirea corectă legăturilor între tabele
❑Definirea corectă a unor restricții de integritate
asociate.
 Proces normalizare - etape
• Stabilirea dicționarului atributelor şi a regulilor de gestiune
(restricţiilor) ce se aplică acestora
• Eliminarea sinonimelor și a celor derivate din altele
• Stabilirea dependențelor dintre atribute – matricea
dependențelor funcționale, graful DF
• Determinarea tabelelor în FN3, a restricțiilor și a legăturilor
• Stabilirea modelului relațional

5
 Normalizarea

• Se bazează pe noţiunea de dependenţele existente

între atribute:
❑Dependențe funcționale
❑Dependențe multivaloare

6
 DEPENDENȚA FUNCȚIONALĂ
A→B
- o valoare din atributul A determină o singură valoare din atributul B
- A poate fi cheie candidat/primara
Tabel Persoane:

• CNP → Nume CNP Nume Prenume

1750212123456 Mihai Tudorel
• CNP → Prenume
2730303123456 Mihai Marioara
• Nume → CNP
1760404123456 Tudor Daniel
• Prenume → CNP
2781211123456 Radu Daniel
• Nume → Prenume
• Prenume → Nume 7
 DEPENDENȚA FUNCȚIONALĂ COMPLETĂ
(A,B) → C
-o singură pereche de valori din grupul de atribute A, B determină o singură valoare din C
-nu există dependență funcțională între A și C sau între B și C ( A → C și B → C )
Perechea A, B este cel mai mic grup de atribute care determină funcțional pe C.
Denumire Data
SerieFactura NrFactura CodProdus Cantitate Pret
Produs factura
AA 1111 1 Cuie 10 11 1/1/2010
AA 1111 2 Tabla 20 12 1/1/2010
BB 1111 1 Cuie 10 11 2/2/2011
BB 2222 2 Tabla 30 20 3/2/2012
(SerieFactura, NrFactura) → DataFactura
CodProdus→DenumireProdus
(SerieFactura, NrFactura, CodProdus)→DenumireProdus (dependența nu este
completă deoarece există CodProdus->DenumireProdus)
• Toate atributele (grupurile de atribute) care determină alte atribute prin 8
 DEPENDENȚA FUNCȚIONALĂ TRANZITIVĂ
A→B→C A->C prin tranzitivitate
SerieFactura NrFactura DataFactura CUIClient DenumireClient
AA 1111 1/1/2013 RO100 XYZ SA
AA 2222 1/1/2013 RO200 ABC SRL
BB 1111 1/1/2014 RO100 XYZ SA
BB 2222 2/2/2014 RO200 ABC SRL

A (SerieFactura, NrFactura)→CUIClient

B CUIClient→DenumireClient

C (SerieFactura, NrFactura)→CUIClient→DenumireClient 9
 DEPENDENȚA MULTIVALOARE
A→→ B

CodAutor→→CodISBN
CodISBN→→CodAutor

Nume->->CNP
DataNasterii->->CNP

10
 FORMELE NORMALE – FN1 (NF1)
– toate atributele atomice şi nerepetitive.

Data->(Zi, Luna, An)

?
Adresa->(Strada, Numar, Bloc, Etaj, Scara, Apartament etc.)

NumePrenume->(Nume, Prenume, Initiala)

?
?
11
 FORMELE NORMALE – FN1

Exemplu de grup repetitiv pe orizontală:

• Student(CNPStudent, Nume, Prenume, Taxa1, Taxa2, Taxa3, Taxa4)

Soluție posibilă:
• Student(CNPStudent, Nume, Prenume)
• TaxaPlatita(CNPStudent, Taxa)

12
 FORMELE NORMALE – FN2
– se află în forma normală unu
– toate atributele sale non cheie se află în dependenţă funcţională
completă faţă de cheia primară

Persoane(CNP, Nume, Prenume)

Facturi(SerieFactura, NrFactura, Data, CUIClient, DenumireClient)
- Respectă FN1
SerieFactura, NrFactura
- Între cheia primară și
celelalte atribute există DF
Data
CUIClient DenumireClient completă
- FN2 = OK!
 FORMELE NORMALE – FN3
– tabelul se află în forma normală doi
– NU există dependenţe funcţionale tranzitive între cheia primară şi
celelalte atribute.

Facturi(SerieFactura, NrFactura, Data, CUIClient, DenumireClient)

- Respectă FN1
SerieFactura, NrFactura
- Între cheia primară și celelalte
Dependență
Dependență funcțională
funcțională

Data
tranzitivă
tranzitivă
atribute există DF completă
CUIClient DenumireClient - FN2 = OK!
- Există CUIClient->DenumireClient
- Nu este în FN3!
 FORMELE NORMALE – FN3
Facturi(SerieFactura, NrFactura, Data, CUIClient, DenumireClient)

- Respectă FN1
- Între cheia primară și celelalte
atribute există DF completă
- FN2 = OK!
- Nu există DF tranzitive
- FN3 = OK!
Facturi(SerieFactura, NrFactura, Data, CUIClient)
Clienti(CUIClient, DenumireClient)
 Proces normalizare - etape
• Stabilirea dicționarului atributelor şi a regulilor de gestiune
(restricţiilor) ce se aplică acestora
• Eliminarea sinonimelor și a celor derivate din altele
• Stabilirea dependențelor dintre atribute – matricea
dependențelor funcționale
• Determinarea tabelelor în FN3, a restricțiilor și a legăturilor
• Stabilirea modelului relațional

16
Studiu de caz
Studiu de caz

18
Reguli de gestiune

19
20
Dependențele funcționale pot fi reprezentate și sub formă de
graf sau sub formă de matrice a dependențelor funcționale.

21
a). Determinarea dependentelor funcționale dintre atribute – chei candidat

22
b). Stabilitea determinanților compuși pentru atributele rămase libere

23
b). Stabilitea determinanților compuși pentru atributele rămase libere

24
c). Determinarea dependentelor funcționale dintre atribute – eliminarea dependențelor
funcționale reciproce

25
d). Determinarea dependentelor funcționale tranzitive (FN3)

26
Graful
dependențelor
funcționale

27
Modelul relațional al BD (FN3)

28
 Modelul
relațional al BD
Restrictiile de integritate
Restrictia PK:
RI1. NrFactura este PK in tabelul Factura
RI2. CodClient este PK in tabelul CLient
….
RI5. CodClient din Factura este FK pentru tabelul Client
RI6. NrFactura din FacturaProdus este FK pentru Factura
RI7. CodProdus din FacturaProdus este FK pentru Produs
RI8. Cantitate > 0
RI9. Pret >0
RI10. DenumireClient <> NULL
….