Basi di Dati

G. Mecca – [email protected] – Università della BasilicataG. Mecca – [email protected] – Università della Basilicata

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)

http://creativecommons.org/licenses/by-sa/1.0/

2G. Mecca - [email protected] - Basi di DatiG. Mecca - [email protected] - Basi di Dati

Sommario Introduzione

Una Tabella non in Forma Normale Forma Normale di Boyce-Codd

Dipendenza FunzionaleDefinizione Formale

Tecniche per la Verifica di Qualità

Progettazione e Forme Normali >> Sommario


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”

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 quindiapprofondire il concetto di forma normale



Introduzione Intuitivamente

una base di dati è in forma normale se i concetti sono opportunamente rappresentati nelle tabelle

non ci sono ridondanzenon si producono anomalie di

aggiornamento, di inserimento e di cancellazione



Una Tabella Non in Forma Normale


studente annoCorso corso voto docentePinco 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

StudentiCorsiEsami T

studente CHAR(20) PK

corso CHAR(20) PK

annoCorso INTEGER

voto INTEGER

docente VARCHAR(20)


Una Tabella Non in Forma Normale Da dove nascono i problemi

errori in fase di modello concettuale


StudentiCorsiEsami

<<id>> studente

<<id>> corso

annoCorso

voto

docente

Ogni studente è identificato dal suo nomeOgni studente è identificato dal suo nomeed è iscritto ad un anno di corso.ed è iscritto ad un anno di corso.Ogni corso è identificato dal suo nomeOgni corso è identificato dal suo nomeed ha un docente.ed ha un docente.Gli studenti sostengono esami per i corsi,Gli studenti sostengono esami per i corsi,riportando voti tra 18 e 30. Ogni studente riportando voti tra 18 e 30. Ogni studente deve sostenere più esami.deve sostenere più esami.

La specificaLo Schema Concettuale


Una Tabella Non in Forma Normale Uno schema più corretto

Progettazione e Forme Normali >> Intoduzione

Studente

<<id>> nome

annoCorso

Corso

<<id>> nome

docente

sostiene esame di >

0..* 0..*

voto


Una Tabella Non in Forma Normale La base di dati

risultante


nome annoCorsoPinco Palla 1

Pinco Pietro 2

Bruno Pasquale 1

Rossi Paolo 2

nome docenteProgrammazione F. Totti

Basi di Dati C. Vieri

Tecnologie Web A. Del Piero

studente esame votoPinco Palla Programmazione 27

Pinco Pietro Programmazione 24

Bruno Pasquale Basi di Dati 30

Rossi Paolo Basi di Dati 25

Pinco Palla Tecnologie Web 27

Bruno Pasquale Programmazione 21

Esami T

studente CHAR(20) PK, FK

corso CHAR(20) PK, FK

voto INTEGER

Corso T

nome CHAR(20) PK

docente VARCHAR(20)

Studente T

nome CHAR(20) PK

annoCorso INTEGER


Una Tabella Non in Forma Normale Intuitivamente

l’errore nasce dalla scelta del modello concettuale

una classe che descrive più di un concettoin generale, invece, ogni classe dovrebbe

descrivere un unico concetto Attenzione

l’errore potrebbe non essere percepibile guardando il modello concettuale



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 verificheche le tabelle prodotte rispettino una “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ù fortenormalmente ottenibile (tranne casi strani)

Terza Forma Normaleè più debole di quella di Boyce-Coddè sempre ottenibile (ma non ne parleremo)

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



Forma Normale Intuizione

R si dice in FNBC se non esiste nessuna “sottotabella” con una “chiave propria”

Sottotabellaqualsiasi proiezione di R

Sottotabella con chiave propriaproiezione per cui è possibile trovare una

chiave primaria non banale che non è chiave per R



Forma Normale Nel nostro esempio:

esistono varie sottotabelle con chiavi proprie


Studenti = studente, annoCorso (StudentiCorsiEsami)

Studenti T

studente CHAR(20)

annoCorso INTEGER

la specifica mi dice che “studente”è una chiave per la tabella



corso CHAR(20) PK

annoCorso INTEGER

voto INTEGER

docente VARCHAR(20)


Forma Normale In modo simile:


Corsi = corso, docente (StudentiEsamiCorsi)

Corsi T

corso CHAR(20)

docente VARCHAR(20)

la specifica mi dice che “corso”è una chiave per la tabella



corso CHAR(20) PK

annoCorso INTEGER

voto INTEGER

docente VARCHAR(20)


Forma Normale Viceversa, in questa tabella

non esistono sottotabelle con chiavi proprie


Esami T


corso CHAR(20) PK

voto INTEGER

Esempio = studente, voto (Esami)

Esempio T

studente CHAR(20)

voto INTEGER

NON ci sonochiavi proprie


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

studente votoPinco Palla 27

Pinco Pietro 24

Bruno Pasquale 30

Rossi Paolo 25

Pinco Palla 27

Bruno Pasquale 21


Forma Normale Un altro esempio


Docente T

codice CHAR(4) PK

cognome CHAR(20)

nome CHAR(20)

facolta CHAR(10)

qualifica CHAR(15)

tipo CHAR(10)

DocenteNumero T

codice CHAR(4)

cognome CHAR(20)

nome CHAR(20)

facolta CHAR(10)

qualifica CHAR(15)

tipo CHAR(10)

numero CHAR(15) PK

Es = codice, cognome (DocenteNumero)questa tabella è normalizzata

questa tabella non è normalizzata

“codice” è una chiave propria


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 sostanzaserve a dire che valori uguali di un attributo

in una tabella implicano valori uguali di altri attributi



Dipendenza Funzionale Sintassi

data una tabella R con attributi A, B, C, D, ...A, B, ... → C, D, ...

Semanticala tabella R è tale per cui ennuple che hanno

valori uguali per gli attributi A, B, ... hanno necessariamente valori uguali per gli attributi C, D, ...

Progettazione e Forme Normali >> Forma Normale >> Dip. Funzionale


Dipendenza Funzionale Esempi

Progettazione e Forme Normali >> Forma Normale >> Dip. Funzionale

studente → annoCorso corso → docentestudente, corso → voto, annoCorso, docente

studente annoCorso corso voto docentePinco 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


Dipendenza Funzionale In effetti

il vincolo di chiave è un caso particolare di dipendenza funzionale

gli attributi della chiave implicano tutti gli altristudente, corso → voto, annoCorso, docente

Notaper definizione, vale anche:


studente, corso → studente, corso, voto, annoCorso, docente


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 generaleuna tabella ha varie dipendenze funzionali

non banali (e moltissime banali)



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

Intuizionese 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

Progettazione e Forme Normali >> Forma Normale >> Def. Formale


Definizione Formale Esempi: tabella non normalizzata


StudentiEsamiCorsi T


corso CHAR(20) PK

annoCorso INTEGER

voto INTEGER

docente VARCHAR(20)

studente → annoCorso

corso → docente

(suggerisce la sottotabellacorrispondente alla proiezione su studente e annoCorso)

(suggerisce la sottotabellacorrispondente alla proiezione su corso e docente)


Definizione Formale Esempi: tabella non normalizzata


codice → cognome, nome, facoltà, qualifica, tipo

DocenteNumero T

codice CHAR(4)

cognome CHAR(20)

nome CHAR(20)

facolta CHAR(10)

qualifica CHAR(15)

tipo CHAR(10)

numero CHAR(15) PK

(suggerisce una qualsiasisottotabella fatta da codiceed uno degli attributi – anche tutti – della parte sinistra)


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

Idealmenteverifica sullo schema concettuale (se lo

schema è corretto, tabelle normalizzate)

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



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



Tecniche di Verifica Esempio: molti a molti


StudentiEsamiCorsi

<<id>> studente

<<id>> corso

annoCorso

voto

docente

Studente

<<id>> nome

annoCorso

Corso

<<id>> nome

docente

sostiene esame di >

0..* 0..*

voto


Tecniche di Verifica Esempio: 1 a molti


StudenteEsame

<<id>> matricola

cognome

nome

annoDicorso

voto

lode<<id> data

Studente

<<id>> matricola

cognome

nome

annoDiCorso

Esame

voto

lode

data

ha sostenuto > 0..*1


Tecniche di Verifica Esempio: attributo multivalore


DocenteNumeri

cognome

nome

qualifica

numTelefono <<id>>

Docente

cognome

nome

qualifica

numTelefono [0..*]


Tecniche di Verifica Attenzione

bisogna però evitare l’errore opposto, ovvero quello di separare eccessivamente i concetti


Votazione

voto

lode

ha riportato > 10..nEsame

data

in questo caso, risalire ai voti costringe a farejoin non necessari


Tecniche di Verifica Concludendo

è necessario trovare il giusto compromesso nella scelta delle classi

In particolareuna classe deve tradurre un concetto ben

identificabile (non accorpare troppo)non bisogna creare classi che rappresentano

concetti irrilevanti (non separare troppo)



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



Sommario Introduzione

Una Tabella non in Forma Normale Forma Normale di Boyce-Codd

Dipendenza FunzionaleDefinizione Formale

Tecniche per la Verifica di Qualità

Progettazione e Forme Normali >> Sommario


Progettazione e Forme Normali >> Modello Concettuale

Studente

<<id>> matricola

cognome

nome

annoDiCorso

Docente

cognome

nome

qualifica

numTelefono [0..*]

DocenteInterno

facolta

Supplente StudenteLaureaTriennale

StudenteLaureaSpecialistica

0..* 0..1tutor >

relatore >

0..*0..1

Corso

<<id>> codice

titolo

ciclo

titolarità

0..*

0..*

Esame

voto

lode

data

ha sostenuto >1 0..*

< relativo a

0..*1

Schema Concettuale

Tirocinio

sede

dataInizio

durata

ha svolto >

1

0..1

relatore solose al 3 anno


Progettazione Logica >> Algoritmo di Traduzione

Tirocinio T

studente INTEGER PK, FK

sede CHAR(20)

dataInizio DATE

durata INTEGER

Tutorato T

studente INTEGER PK, FK

tutor INTEGER PK, FK

Studente T

matricola INTEGER PK

cognome CHAR(20)

nome CHAR(20)

ciclo CHAR(15)

anno INTEGER

relatore CHAR(4) FK

Docente T

codice CHAR(4) PK

cognome CHAR(20)

nome CHAR(20)

facolta CHAR(10)

qualifica CHAR(15)

tipo CHAR(10)

Esame T

codice CHAR(5) PK

voto INTEGER

lode BOOL

data DATE

corso CHAR(3) FK

stud INTEGER FK

Corso T

codice CHAR(3) PK

titolo CHAR(20)

ciclo CHAR(20)

Titolarità T

corso CHAR(3) PK, FK

docente CHAR(4) PK, FK

Numeri T

numero CHAR(15) PK

docente CHAR(4) FK


Termini della Licenza

Termini della Licenza

This work is licensed under the Creative Commons Attribution-ShareAlike 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.



Basi di Dati

Documents

Transcript of Basi di Dati