G. Mecca – [email protected] – Università della Basilicata Basi di Dati Progettazione e Forme...

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)

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

Sommario

IntroduzioneUna Tabella non in Forma Normale

Forma Normale di Boyce-CoddDipendenza FunzionaleDefinizione Formale

Tecniche per la Verifica di Qualità

Progettazione e Forme Normali >> Sommario


Introduzione

Idealmentese lo schema concettuale è di qualità

(corretto, completo e non ridondante)se la progettazione logica è condotta

applicando correttamente l’algoritmola 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

Intuitivamenteuna 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 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

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 annoCorso

Pinco Palla 1

Pinco Pietro 2

Bruno Pasquale 1

Rossi Paolo 2

nome docente

Programmazione F. Totti

Basi di Dati C. Vieri

Tecnologie Web A. Del Piero

studente esame voto

Pinco 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 datigarantisce 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 datiuna tabella che rispetta il vincolo si dice

“normalizzata”altrimenti si dice “non normalizzata”

Approcciodaremo prima l’intuizione, poi la

formalizzazione



Forma Normale

IntuizioneR 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



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 tabellanon 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’istanzanon esiste nessuna chiave (vedi specifica)


Esempio T

studente CHAR(20)

voto INTEGER

lo stesso discorso vale per tutte le altre possibili proiezioni

studente voto

Pinco 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 formalizzareabbiamo bisogno di una nozione ulteriore

Concetto di Dipendenza Funzionalevincolo 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

Sintassidata 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



Esempi

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

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



In effettiil vincolo di chiave è un caso particolare di

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

Notaper definizione, vale anche:


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



Dipendenze non banalinon ci sono attributi che compaiono sia a

destra che a sinistraogni 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-Codduna 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 concretoscoprire 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



Quindi, il metodo suggerito èattenzione alla creazione dello schema

concettualeverifica della correttezza delle classi rispetto

ai concettiverifica a posteriori sulle tabelle derivate

dalla progettazione logicautilizzando le dipendenze funzionali




In generaleogni classe deve rappresentare un concetto

Errori frequenti nello schema logicouna classe traduce due o più concetti in

relazione molti-a-moltiuna classe traduce due o più concetti in

relazione uno-a-moltiuna classe traduce in modo scorretto un

attributo multivalore




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



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



Esempio: attributo multivalore


DocenteNumeri

cognome

nome

qualifica

numTelefono <<id>>

Docente

cognome

nome

qualifica

numTelefono [0..*]



Attenzionebisogna 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



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)




Successivamentein 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

IntroduzioneUna Tabella non in Forma Normale

Forma Normale di Boyce-CoddDipendenza 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 Studente

Laurea

Triennale

Studente

Laurea

Specialistica

0..* 0..1tutor >

relatore >

0..*0..1

Corso

<<id>> codice

titolo

ciclo

titolarità

0..*

0..*

Esame

voto

lode

data

ha sostenuto >10..*

< 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.

G. Mecca – [email protected] – Università della Basilicata Basi di Dati Progettazione e Forme...

Documents

Transcript of G. Mecca – [email protected] – Università della Basilicata Basi di Dati Progettazione e Forme...