Basi di Dati
Progettazione e
Forme Normali
versione 2.0
Questo lavoro è concesso in uso secondo i termini di una licenza Creative Commons
(vedi ultima pagina)
G. Mecca – [email protected] – Università della Basilicata
Progettazione e Forme Normali >> Sommario
Sommario
 Introduzione
Una Tabella non in Forma Normale
 Forma
Normale di Boyce-Codd
Dipendenza Funzionale
Definizione Formale
 Tecniche
per la Verifica di Qualità
G. Mecca - [email protected] - Basi di Dati
2
Progettazione e Forme Normali >> Introduzione
Introduzione
 Idealmente
se lo schema concettuale è di qualità
(corretto, completo e non ridondante)
se la progettazione logica è condotta
applicando correttamente l’algoritmo
la base di dati risultante dovrebbe essere di
qualità
in particolare: dovrebbe essere in forma
“normale”
G. Mecca - [email protected] - Basi di Dati
3
Progettazione e Forme Normali >> Introduzione
Introduzione
 In
realtà
è possibile commettere errori nella fase di
analisi e in quella di progettazione logica
è necessario effettuare verifiche di qualità
continue, per accertarsi che il risultato sia
corretto
 E’
necessario quindi
approfondire il concetto di forma normale
G. Mecca - [email protected] - Basi di Dati
4
Progettazione e Forme Normali >> Introduzione
Introduzione
 Intuitivamente
una base di dati è in forma normale se i
concetti sono opportunamente rappresentati
nelle tabelle
non ci sono ridondanze
non si producono anomalie di
aggiornamento, di inserimento e di
cancellazione
G. Mecca - [email protected] - Basi di Dati
5
Progettazione e Forme Normali >> Introduzione
Una Tabella Non in Forma Normale
studente
annoCorso
corso
voto
docente
Pinco Palla
1
Programmazione
27
F. Totti
Pinco Pietro
2
Programmazione
T
1StudentiCorsiEsami
Basi di Dati
24
F. Totti
30
C. Vieri
Rossi Paolo
2studente CHAR(20)
Basi di Dati
PK
25
C. Vieri
Pinco Palla
1corso CHAR(20)
Tecnologie Web PK
27
A. Del Piero
INTEGER
1annoCorso
Programmazione
21
F. Totti
Bruno Pasquale
Bruno Pasquale
voto INTEGER
docente VARCHAR(20)
G. Mecca - [email protected] - Basi di Dati
6
Progettazione e Forme Normali >> Introduzione
Una Tabella Non in Forma Normale
 Da
dove nascono i problemi
errori in fase di modello concettuale
La specifica
Ogni studente è identificato dal suo nome
ed è iscritto ad un anno di corso.
Ogni corso è identificato dal suo nome
ed ha un docente.
Gli studenti sostengono esami per i corsi,
riportando voti tra 18 e 30. Ogni studente
deve sostenere più esami.
G. Mecca - [email protected] - Basi di Dati
Lo Schema
Concettuale
StudentiCorsiEsami
<<id>> studente
<<id>> corso
annoCorso
voto
docente
7
Progettazione e Forme Normali >> Intoduzione
Una Tabella Non in Forma Normale
 Uno
schema più corretto
Studente
Corso
sostiene esame di >
<<id>> nome
annoCorso
0..*
<<id>> nome
0..*
docente
voto
G. Mecca - [email protected] - Basi di Dati
8
Progettazione e Forme Normali >> Introduzione
Una Tabella Non in Forma Corso
Normale
nome CHAR(20)
base di dati
risultante
Studente
T
nome CHAR(20)
PK
annoCorso INTEGER
nome
annoCorso
PK
docentedocente
VARCHAR(20)
nome
 La
Programmazione
F. Totti
Basi di Dati
C. Vieri
Tecnologie Web
A. Del Piero
studente
esame
voto
Pinco Palla
Programmazione
27
Pinco Palla
1
Pinco Pietro
Programmazione
24
Pinco Pietro
2
Bruno Pasquale
Basi di Dati
30
Bruno Pasquale
1
Rossi Paolo
Rossi Paolo
2
Pinco Palla
Basi di Dati
Esami
Tecnologie
Web
25
27T
studente CHAR(20)
Bruno Pasquale Programmazione
corso CHAR(20)
G. Mecca - [email protected] - Basi di Dati
T
voto INTEGER
21PK, FK
PK, FK
9
Progettazione e Forme Normali >> Introduzione
Una Tabella Non in Forma Normale
 Intuitivamente
l’errore nasce dalla scelta del modello
concettuale
una classe che descrive più di un concetto
in generale, invece, ogni classe dovrebbe
descrivere un unico concetto
 Attenzione
l’errore potrebbe non essere percepibile
guardando il modello concettuale
G. Mecca - [email protected] - Basi di Dati
10
Progettazione e Forme Normali >> Introduzione
Una Tabella Non in Forma Normale
 Per
evitare questi problemi
è necessario effettuare verifiche ripetute sui
risultati della progettazione logica
ed, in caso di errori, correggere lo schema
concettuale
 Oggetto
delle verifiche
che le tabelle prodotte rispettino una “forma
normale”
G. Mecca - [email protected] - Basi di Dati
11
Progettazione e Forme Normali >> Forma Normale
Forma Normale
 Vincolo
sulla struttura di una base di dati
garantisce che non si generano anomalie
 Discuteremo
la F. N. di Boyce-Codd
è quella più forte
normalmente ottenibile (tranne casi strani)
 Terza
Forma Normale
è più debole di quella di Boyce-Codd
è sempre ottenibile (ma non ne parleremo)
G. Mecca - [email protected] - Basi di Dati
12
Progettazione e Forme Normali >> Forma Normale
Forma Normale
 Forma
Normale di Boyce-Codd (FNBC)
vincolo sull’organizzazione delle tabelle della
base di dati
una tabella che rispetta il vincolo si dice
“normalizzata”
altrimenti si dice “non normalizzata”
 Approccio
daremo prima l’intuizione, poi la
formalizzazione
G. Mecca - [email protected] - Basi di Dati
13
Progettazione e Forme Normali >> Forma Normale
Forma Normale
 Intuizione
R si dice in FNBC se non esiste nessuna
“sottotabella” con una “chiave propria”
 Sottotabella
qualsiasi proiezione di R
 Sottotabella
con chiave propria
proiezione per cui è possibile trovare una
chiave primaria non banale che non è chiave
per R
G. Mecca - [email protected] - Basi di Dati
14
Progettazione e Forme Normali >> Forma Normale
Forma Normale
 Nel
nostro esempio:
esistono varie sottotabelle con chiavi proprie
StudentiCorsiEsami
T
studente CHAR(20)
PK
corso CHAR(20)
PK
Studenti =
p studente, annoCorso (StudentiCorsiEsami)
Studenti
T
annoCorso INTEGER
voto INTEGER
docente VARCHAR(20)
studente CHAR(20)
annoCorso INTEGER
la specifica mi dice che “studente”
è una chiave per la tabella
G. Mecca - [email protected] - Basi di Dati
15
Progettazione e Forme Normali >> Forma Normale
Forma Normale
 In
modo simile:
Corsi =
StudentiCorsiEsami
T
studente CHAR(20)
PK
corso CHAR(20)
PK
p corso, docente (StudentiEsamiCorsi)
annoCorso INTEGER
voto INTEGER
Corsi
T
corso CHAR(20)
docente VARCHAR(20)
docente VARCHAR(20)
la specifica mi dice che “corso”
è una chiave per la tabella
G. Mecca - [email protected] - Basi di Dati
16
Progettazione e Forme Normali >> Forma Normale
Forma Normale
 Viceversa,
in questa tabella
non esistono sottotabelle con chiavi proprie
Esami
T
studente CHAR(20)
PK
corso CHAR(20)
PK
NON ci sono
chiavi proprie
voto INTEGER
Esempio =
p studente, voto (Esami)
G. Mecca - [email protected] - Basi di Dati
Esempio
T
studente CHAR(20)
voto INTEGER
17
Progettazione e Forme Normali >> Forma Normale
Forma Normale
 Infatti,
guardando l’istanza
non esiste nessuna chiave (vedi specifica)
Esempio
T
studente CHAR(20)
voto INTEGER
lo stesso discorso vale per tutte
le altre possibili proiezioni
G. Mecca - [email protected] - Basi di Dati
studente
voto
Pinco Palla
27
Pinco Pietro
24
Bruno Pasquale
30
Rossi Paolo
25
Pinco Palla
27
Bruno Pasquale
21
18
Progettazione e Forme Normali >> Forma Normale
Forma Normale

Un altro esempio
DocenteNumero
T
codice CHAR(4)
cognome CHAR(20)
Docente
T
nome CHAR(20)
codice CHAR(4)
PK
facolta CHAR(10)
cognome CHAR(20)
qualifica CHAR(15)
nome CHAR(20)
tipo CHAR(10)
facolta CHAR(10)
numero CHAR(15)
PK
qualifica CHAR(15)
tipo CHAR(10)
questa tabella è normalizzata
questa tabella non è normalizzata
Es = p codice, cognome (DocenteNumero)
“codice” è una chiave propria
G. Mecca - [email protected] - Basi di Dati
19
Progettazione e Forme Normali >> Forma Normale
Forma Normale
 Per
formalizzare
abbiamo bisogno di una nozione ulteriore
 Concetto
di Dipendenza Funzionale
vincolo di integrità aggiuntivo sulle tabelle
è una generalizzazione del vincolo di chiave
 In
sostanza
serve a dire che valori uguali di un attributo
in una tabella implicano valori uguali di altri
attributi
G. Mecca - [email protected] - Basi di Dati
20
Progettazione e Forme Normali >> Forma Normale >> Dip. Funzionale
Dipendenza Funzionale
 Sintassi
data una tabella R con attributi A, B, C, D, ...
A, B, ... → C, D, ...
 Semantica
la tabella R è tale per cui ennuple che hanno
valori uguali per gli attributi A, B, ... hanno
necessariamente valori uguali per gli attributi
C, D, ...
G. Mecca - [email protected] - Basi di Dati
21
Progettazione e Forme Normali >> Forma Normale >> Dip. Funzionale
Dipendenza Funzionale
 Esempi
studente → annoCorso
corso → docente
studente, corso → voto, annoCorso, docente
studente
annoCorso
corso
voto
docente
Pinco Palla
1
Programmazione
27
F. Totti
Pinco Pietro
2
Programmazione
24
F. Totti
Bruno Pasquale
1
Basi di Dati
30
C. Vieri
Rossi Paolo
2
Basi di Dati
25
C. Vieri
Pinco Palla
1
Tecnologie Web
27
A. Del Piero
Bruno Pasquale
1
Programmazione
21
F. Totti
G. Mecca - [email protected] - Basi di Dati
22
Progettazione e Forme Normali >> Forma Normale
Dipendenza Funzionale
 In
effetti
il vincolo di chiave è un caso particolare di
dipendenza funzionale
gli attributi della chiave implicano tutti gli altri
studente, corso → voto, annoCorso, docente
 Nota
per definizione, vale anche:
studente, corso → studente, corso, voto, annoCorso, docente
G. Mecca - [email protected] - Basi di Dati
23
Progettazione e Forme Normali >> Forma Normale
Dipendenza Funzionale
 Dipendenze
non banali
non ci sono attributi che compaiono sia a
destra che a sinistra
ogni dipendenza è riducibile alla forma non
banale eliminando dalla parte destra gli
attributi che compaiono a sinistra
 In
generale
una tabella ha varie dipendenze funzionali
non banali (e moltissime banali)
G. Mecca - [email protected] - Basi di Dati
24
Progettazione e Forme Normali >> Forma Normale >> Def. Formale
Definizione Formale
 Forma
Normale di Boyce-Codd
una tabella R è in FNBC se, per ogni
dipendenza funzionale non banale su R, il
membro sinistro è una chiave per R
 Intuizione
se ci fosse una dipendenza A, B → C, D e A
B non sono chiavi per R, la proiezione di R
su A, B, C, D sarebbe una sottotabella con
chiave propria
G. Mecca - [email protected] - Basi di Dati
25
Progettazione e Forme Normali >> Forma Normale >> Def. Formale
Definizione Formale
 Esempi:
tabella non normalizzata
StudentiEsamiCorsi
T
studente CHAR(20)
PK
corso CHAR(20)
PK
annoCorso INTEGER
voto INTEGER
docente VARCHAR(20)
studente → annoCorso
(suggerisce la sottotabella
corrispondente alla proiezione
su studente e annoCorso)
corso → docente
(suggerisce la sottotabella
corrispondente alla proiezione
su corso e docente)
G. Mecca - [email protected] - Basi di Dati
26
Progettazione e Forme Normali >> Forma Normale >> Def. Formale
Definizione Formale
 Esempi:
tabella non normalizzata
DocenteNumero
T
codice CHAR(4)
codice → cognome, nome,
facoltà, qualifica, tipo
cognome CHAR(20)
nome CHAR(20)
facolta CHAR(10)
qualifica CHAR(15)
tipo CHAR(10)
numero CHAR(15)
PK
G. Mecca - [email protected] - Basi di Dati
(suggerisce una qualsiasi
sottotabella fatta da codice
ed uno degli attributi – anche
tutti – della parte sinistra)
27
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
 In
concreto
scoprire l’errore dopo aver creato la base di
dati sarebbe grave
è opportuno verificare continuamente i
risultati della progettazione per accorgersi
tempestivamente degli errori
 Idealmente
verifica sullo schema concettuale (se lo
schema è corretto, tabelle normalizzate)
G. Mecca - [email protected] - Basi di Dati
28
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
 Quindi,
il metodo suggerito è
attenzione alla creazione dello schema
concettuale
verifica della correttezza delle classi rispetto
ai concetti
verifica a posteriori sulle tabelle derivate
dalla progettazione logica
utilizzando le dipendenze funzionali
G. Mecca - [email protected] - Basi di Dati
29
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
 In
generale
ogni classe deve rappresentare un concetto
 Errori
frequenti nello schema logico
una classe traduce due o più concetti in
relazione molti-a-molti
una classe traduce due o più concetti in
relazione uno-a-molti
una classe traduce in modo scorretto un
attributo multivalore
G. Mecca - [email protected] - Basi di Dati
30
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
 Esempio:
molti a molti
StudentiEsamiCorsi
<<id>> studente
<<id>> corso
annoCorso
voto
docente
Studente
Corso
sostiene esame di >
<<id>> nome
annoCorso
0..*
<<id>> nome
0..*
docente
voto
G. Mecca - [email protected] - Basi di Dati
31
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
StudenteEsame
<<id>> matricola
 Esempio:
1 a molti
cognome
nome
annoDicorso
voto
lode
<<id> data
Studente
<<id>> matricola
cognome
Esame
1
ha sostenuto >
nome
0..*
voto
lode
data
annoDiCorso
G. Mecca - [email protected] - Basi di Dati
32
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
 Esempio:
attributo multivalore
DocenteNumeri
cognome
nome
qualifica
numTelefono <<id>>
Docente
cognome
nome
qualifica
numTelefono [0..*]
G. Mecca - [email protected] - Basi di Dati
33
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
 Attenzione
bisogna però evitare l’errore opposto, ovvero
quello di separare eccessivamente i concetti
Esame
Votazione
0..n
data
ha riportato >
1
voto
lode
in questo caso, risalire ai voti costringe a fare
join non necessari
G. Mecca - [email protected] - Basi di Dati
34
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
 Concludendo
è necessario trovare il giusto compromesso
nella scelta delle classi
 In
particolare
una classe deve tradurre un concetto ben
identificabile (non accorpare troppo)
non bisogna creare classi che rappresentano
concetti irrilevanti (non separare troppo)
G. Mecca - [email protected] - Basi di Dati
35
Progettazione e Forme Normali >> Tecniche di Verifica
Tecniche di Verifica
 Successivamente
in fase di progettazione fisica e messa a
punto “tuning” è possibile ritornare su queste
decisioni
in alcuni casi, per motivi di prestazioni, è
possibile tollerare tabelle non normalizzate
ma questa è una scelta che va fatta
successivamente
G. Mecca - [email protected] - Basi di Dati
36
Progettazione e Forme Normali >> Sommario
Sommario
 Introduzione
Una Tabella non in Forma Normale
 Forma
Normale di Boyce-Codd
Dipendenza Funzionale
Definizione Formale
 Tecniche
per la Verifica di Qualità
G. Mecca - [email protected] - Basi di Dati
37
Progettazione e Forme Normali >> Modello Concettuale
Corso
Esame
< relativo a
<<id>> codice
0..*
voto
1
titolo
0..*
relatore solo
se al 3 anno
ciclo
titolarità
data
1
Docente
lode
ha sostenuto >
Studente
cognome
relatore >
nome
<<id>> matricola
cognome
0..* qualifica
0..1
0..*
numTelefono [0..*]
0..*
Tirocinio
sede
1
dataInizio
nome
durata
annoDiCorso
ha svolto >
DocenteInterno
Supplente
facolta
Schema Concettuale
G. Mecca - [email protected] - Basi di Dati
Studente
Laurea
Triennale
0..*
0..1
Studente
Laurea
Specialistica
tutor >
0..1
38
Progettazione Logica >> Algoritmo di Traduzione
Titolarità
T
Corso
T
corso CHAR(3)
PK, FK
codice CHAR(3)
PK
docente CHAR(4)
PK, FK
titolo CHAR(20)
codice CHAR(5) PK
ciclo CHAR(20)
voto INTEGER
Tirocinio
T
studente INTEGER
PK, FK
sede CHAR(20)
Docente
T
codice CHAR(4)
PK
cognome CHAR(20)
dataInizio DATE
Esame
T
lode BOOL
data DATE
corso CHAR(3)
FK
stud INTEGER
FK
nome CHAR(20)
durata INTEGER
Studente
T
matricola INTEGER
PK
facolta CHAR(10)
Numeri
T
qualifica CHAR(15)
numero CHAR(15) PK
tipo CHAR(10)
docente CHAR(4)
FK
cognome CHAR(20)
nome CHAR(20)
Tutorato
T
ciclo CHAR(15)
studente INTEGER
PK, FK
anno INTEGER
tutor INTEGER
PK, FK
relatoreG.CHAR(4)
FK
Mecca - [email protected]
- Basi di Dati
39
Termini della Licenza
Termini della Licenza

This work is licensed under the Creative Commons AttributionShareAlike License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/1.0/ or send a letter to
Creative Commons, 559 Nathan Abbott Way, Stanford, California
94305, USA.

Questo lavoro viene concesso in uso secondo i termini della
licenza “Attribution-ShareAlike” di Creative Commons. Per ottenere
una copia della licenza, è possibile visitare
http://creativecommons.org/licenses/by-sa/1.0/ oppure inviare una
lettera all’indirizzo Creative Commons, 559 Nathan Abbott Way,
Stanford, California 94305, USA.
G. Mecca - [email protected] - Basi di Dati
40