Basi di Dati

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

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

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

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

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

6. Progettazione e Forme Normali >> Introduzione Una Tabella Non in Forma Normale G. Mecca - mecca@unibas.it - Basi di Dati

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

8. sostiene esame di > 0..* 0..* voto Progettazione e Forme Normali >> Intoduzione Una Tabella Non in Forma Normale • Uno schema più corretto G. Mecca - mecca@unibas.it - Basi di Dati

9. Progettazione e Forme Normali >> Introduzione Una Tabella Non in Forma Normale • La base di dati risultante G. Mecca - mecca@unibas.it - Basi di Dati

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

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

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

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

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

15. Progettazione e Forme Normali >> Forma Normale Forma Normale • Nel nostro esempio: • esistono varie sottotabelle con chiavi proprie Studenti = p studente, annoCorso (StudentiCorsiEsami) la specifica mi dice che “studente” è una chiave per la tabella G. Mecca - mecca@unibas.it - Basi di Dati

16. Progettazione e Forme Normali >> Forma Normale Forma Normale • In modo simile: Corsi = p corso, docente (StudentiEsamiCorsi) la specifica mi dice che “corso” è una chiave per la tabella G. Mecca - mecca@unibas.it - Basi di Dati

17. Progettazione e Forme Normali >> Forma Normale Forma Normale • Viceversa, in questa tabella • non esistono sottotabelle con chiavi proprie NON ci sono chiavi proprie Esempio = p studente, voto (Esami) G. Mecca - mecca@unibas.it - Basi di Dati

18. Progettazione e Forme Normali >> Forma Normale Forma Normale • Infatti, guardando l’istanza • non esiste nessuna chiave (vedi specifica) lo stesso discorso vale per tutte le altre possibili proiezioni G. Mecca - mecca@unibas.it - Basi di Dati

19. Progettazione e Forme Normali >> Forma Normale Forma Normale • Un altro esempio questa tabella non è normalizzata Es = p codice, cognome (DocenteNumero) questa tabella è normalizzata “codice” è una chiave propria G. Mecca - mecca@unibas.it - Basi di Dati

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

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

22. Progettazione e Forme Normali >> Forma Normale >> Dip. Funzionale Dipendenza Funzionale studente → annoCorso • Esempi corso → docente studente, corso → voto, annoCorso, docente G. Mecca - mecca@unibas.it - Basi di Dati

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

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

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

26. Progettazione e Forme Normali >> Forma Normale >> Def. Formale Definizione Formale • Esempi: tabella non normalizzata 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

27. Progettazione e Forme Normali >> Forma Normale >> Def. Formale Definizione Formale • Esempi: tabella non normalizzata 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

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

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

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

31. sostiene esame di > 0..* 0..* voto Progettazione e Forme Normali >> Tecniche di Verifica Tecniche di Verifica • Esempio: molti a molti G. Mecca - mecca@unibas.it - Basi di Dati

32. Progettazione e Forme Normali >> Tecniche di Verifica Tecniche di Verifica • Esempio: 1 a molti ha sostenuto > 0..* 1 G. Mecca - mecca@unibas.it - Basi di Dati

33. Progettazione e Forme Normali >> Tecniche di Verifica Tecniche di Verifica • Esempio: attributo multivalore G. Mecca - mecca@unibas.it - Basi di Dati

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

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

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

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

38. Progettazione e Forme Normali >> Modello Concettuale < relativo a 0..* 1 0..* relatore solo se al 3 anno 0..* titolarità 1 ha sostenuto > relatore > 1 0..* 0..1 0..* 0..1 ha svolto > Schema Concettuale tutor > 0..* 0..1 G. Mecca - mecca@unibas.it - Basi di Dati

39. Progettazione Logica >> Algoritmo di Traduzione G. Mecca - mecca@unibas.it - Basi di Dati

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