Progettazione e Forme Normali 27/03/2017 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 – mecca@unibas.it – Università della Basilicata

Sommario Introduzione Forma Normale di Boyce-Codd 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Introduzione Idealmente 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Introduzione In realtà E’ necessario quindi 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Introduzione Intuitivamente 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Una Tabella Non in Forma Normale 27/03/2017 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 24 Bruno Pasquale Basi di Dati 30 C. Vieri Rossi Paolo 25 Tecnologie Web A. Del Piero 21 StudentiCorsiEsami T studente CHAR(20) PK corso CHAR(20) annoCorso INTEGER voto INTEGER docente VARCHAR(20) G. Mecca - mecca@unibas.it - Basi di Dati

Una Tabella Non in Forma Normale 27/03/2017 Progettazione e Forme Normali >> Introduzione Una Tabella Non in Forma Normale Da dove nascono i problemi errori in fase di modello concettuale Lo Schema 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. StudentiCorsiEsami <<id>> studente <<id>> corso annoCorso voto docente G. Mecca - mecca@unibas.it - Basi di Dati

Una Tabella Non in Forma Normale 27/03/2017 Progettazione e Forme Normali >> Intoduzione Una Tabella Non in Forma Normale Uno schema più corretto Studente <<id>> nome annoCorso Corso <<id>> nome docente sostiene esame di > 0..* voto G. Mecca - mecca@unibas.it - Basi di Dati

Una Tabella Non in Forma Normale 27/03/2017 Progettazione e Forme Normali >> Introduzione Una Tabella Non in Forma Normale Corso T nome CHAR(20) PK docente VARCHAR(20) La base di dati risultante nome docente Programmazione F. Totti Basi di Dati C. Vieri Tecnologie Web A. Del Piero Studente T nome CHAR(20) PK annoCorso INTEGER studente esame voto Pinco Palla Programmazione 27 Pinco Pietro 24 Bruno Pasquale Basi di Dati 30 Rossi Paolo 25 Tecnologie Web 21 nome annoCorso Pinco Palla 1 Pinco Pietro 2 Bruno Pasquale Rossi Paolo Esami T studente CHAR(20) PK, FK corso CHAR(20) voto INTEGER G. Mecca - mecca@unibas.it - Basi di Dati

Una Tabella Non in Forma Normale 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Una Tabella Non in Forma Normale 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Forma Normale Vincolo sulla struttura di una base di dati 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Forma Normale Forma Normale di Boyce-Codd (FNBC) Approccio 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Forma Normale Intuizione Sottotabella Sottotabella con chiave propria 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Forma Normale Nel nostro esempio: 27/03/2017 Progettazione e Forme Normali >> Forma Normale Forma Normale Nel nostro esempio: esistono varie sottotabelle con chiavi proprie Studenti = p studente, annoCorso (StudentiCorsiEsami) StudentiCorsiEsami T studente CHAR(20) PK corso CHAR(20) annoCorso INTEGER voto INTEGER docente VARCHAR(20) Studenti T studente CHAR(20) annoCorso INTEGER la specifica mi dice che “studente” è una chiave per la tabella G. Mecca - mecca@unibas.it - Basi di Dati

Forma Normale In modo simile: p corso, docente (StudentiEsamiCorsi) 27/03/2017 Progettazione e Forme Normali >> Forma Normale Forma Normale In modo simile: Corsi = p corso, docente (StudentiEsamiCorsi) StudentiCorsiEsami T studente CHAR(20) PK corso CHAR(20) annoCorso INTEGER voto INTEGER docente VARCHAR(20) Corsi T corso CHAR(20) docente VARCHAR(20) la specifica mi dice che “corso” è una chiave per la tabella G. Mecca - mecca@unibas.it - Basi di Dati

Forma Normale Viceversa, in questa tabella 27/03/2017 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) voto INTEGER NON ci sono chiavi proprie Esempio T studente CHAR(20) voto INTEGER Esempio = p studente, voto (Esami) G. Mecca - mecca@unibas.it - Basi di Dati

Forma Normale Infatti, guardando l’istanza 27/03/2017 Progettazione e Forme Normali >> Forma Normale Forma Normale Infatti, guardando l’istanza non esiste nessuna chiave (vedi specifica) studente voto Pinco Palla 27 Pinco Pietro 24 Bruno Pasquale 30 Rossi Paolo 25 21 Esempio T studente CHAR(20) voto INTEGER lo stesso discorso vale per tutte le altre possibili proiezioni G. Mecca - mecca@unibas.it - Basi di Dati

Forma Normale Un altro esempio Es = p codice, cognome (DocenteNumero) 27/03/2017 Progettazione e Forme Normali >> Forma Normale Forma Normale DocenteNumero T codice CHAR(4) cognome CHAR(20) nome CHAR(20) facolta CHAR(10) qualifica CHAR(15) tipo CHAR(10) numero CHAR(15) PK Un altro esempio Docente T codice CHAR(4) PK cognome CHAR(20) nome CHAR(20) facolta CHAR(10) qualifica CHAR(15) tipo CHAR(10) questa tabella non è normalizzata Es = p codice, cognome (DocenteNumero) questa tabella è normalizzata “codice” è una chiave propria G. Mecca - mecca@unibas.it - Basi di Dati

Forma Normale Per formalizzare Concetto di Dipendenza Funzionale 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Dipendenza Funzionale 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Dipendenza Funzionale 27/03/2017 Progettazione e Forme Normali >> Forma Normale >> Dip. Funzionale Dipendenza Funzionale studente → annoCorso Esempi corso → docente studente, corso → voto, annoCorso, docente studente annoCorso corso voto docente Pinco Palla 1 Programmazione 27 F. Totti Pinco Pietro 2 24 Bruno Pasquale Basi di Dati 30 C. Vieri Rossi Paolo 25 Tecnologie Web A. Del Piero 21 G. Mecca - mecca@unibas.it - Basi di Dati

Dipendenza Funzionale 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Dipendenza Funzionale 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Definizione Formale Forma Normale di Boyce-Codd Intuizione 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Definizione Formale Esempi: tabella non normalizzata 27/03/2017 Progettazione e Forme Normali >> Forma Normale >> Def. Formale Definizione Formale Esempi: tabella non normalizzata StudentiEsamiCorsi T studente CHAR(20) PK corso CHAR(20) 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 - mecca@unibas.it - Basi di Dati

Definizione Formale Esempi: tabella non normalizzata 27/03/2017 Progettazione e Forme Normali >> Forma Normale >> Def. Formale Definizione Formale Esempi: tabella non normalizzata DocenteNumero T codice CHAR(4) cognome CHAR(20) nome CHAR(20) facolta CHAR(10) qualifica CHAR(15) tipo CHAR(10) numero CHAR(15) PK codice → cognome, nome, facoltà, qualifica, tipo (suggerisce una qualsiasi sottotabella fatta da codice ed uno degli attributi – anche tutti – della parte sinistra) G. Mecca - mecca@unibas.it - Basi di Dati

Tecniche di Verifica In concreto Idealmente 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Tecniche di Verifica Quindi, il metodo suggerito è 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Tecniche di Verifica In generale Errori frequenti nello schema logico 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Tecniche di Verifica Esempio: molti a molti 0..* 27/03/2017 Progettazione e Forme Normali >> Tecniche di Verifica 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..* voto G. Mecca - mecca@unibas.it - Basi di Dati

Tecniche di Verifica Esempio: 1 a molti 1 0..* 27/03/2017 Progettazione e Forme Normali >> Tecniche di Verifica Tecniche di Verifica StudenteEsame <<id>> matricola cognome nome annoDicorso voto lode <<id> data Esempio: 1 a molti Studente <<id>> matricola cognome nome annoDiCorso Esame voto lode data 1 ha sostenuto > 0..* G. Mecca - mecca@unibas.it - Basi di Dati

Tecniche di Verifica Esempio: attributo multivalore 27/03/2017 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 - mecca@unibas.it - Basi di Dati

in questo caso, risalire ai voti costringe a fare 27/03/2017 Progettazione e Forme Normali >> Tecniche di Verifica Tecniche di Verifica Attenzione bisogna però evitare l’errore opposto, ovvero quello di separare eccessivamente i concetti Votazione voto lode Esame data 0..n ha riportato > 1 in questo caso, risalire ai voti costringe a fare join non necessari G. Mecca - mecca@unibas.it - Basi di Dati

Tecniche di Verifica Concludendo In particolare 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Tecniche di Verifica Successivamente 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Sommario Introduzione Forma Normale di Boyce-Codd 27/03/2017 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 - mecca@unibas.it - Basi di Dati

Schema Concettuale 0..* 1 0..* 0..* 1 1 0..* 0..1 0..* 0..1 0..* 0..1 27/03/2017 Progettazione e Forme Normali >> Modello Concettuale Corso <<id>> codice titolo ciclo Esame voto lode data < relativo a 0..* 1 0..* relatore solo se al 3 anno 0..* titolarità 1 ha sostenuto > Docente cognome nome qualifica numTelefono [0..*] Studente <<id>> matricola cognome nome annoDiCorso Tirocinio sede dataInizio durata relatore > 1 0..* 0..1 0..* 0..1 ha svolto > DocenteInterno facolta Supplente Studente Laurea Triennale Studente Laurea Specialistica Schema Concettuale tutor > 0..* 0..1 G. Mecca - mecca@unibas.it - Basi di Dati

Progettazione Logica >> Algoritmo di Traduzione Titolarità T 27/03/2017 Progettazione Logica >> Algoritmo di Traduzione Titolarità T corso CHAR(3) PK, FK docente CHAR(4) Corso T codice CHAR(3) PK titolo CHAR(20) ciclo CHAR(20) Esame T codice CHAR(5) PK voto INTEGER lode BOOL data DATE corso CHAR(3) FK stud INTEGER Tirocinio T studente INTEGER PK, FK sede CHAR(20) dataInizio DATE durata INTEGER Docente T codice CHAR(4) PK cognome CHAR(20) nome CHAR(20) facolta CHAR(10) qualifica CHAR(15) tipo CHAR(10) Numeri T numero CHAR(15) PK docente CHAR(4) FK Studente T matricola INTEGER PK cognome CHAR(20) nome CHAR(20) ciclo CHAR(15) anno INTEGER relatore CHAR(4) FK Tutorato T studente INTEGER PK, FK tutor INTEGER G. Mecca - mecca@unibas.it - Basi di Dati

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 - mecca@unibas.it - Basi di Dati