La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

G. Mecca – – Università della Basilicata Basi di Dati Progettazione e Forme Normali versione 2.0 Questo lavoro è concesso in uso secondo.

Presentazioni simili


Presentazione sul tema: "G. Mecca – – Università della Basilicata Basi di Dati Progettazione e Forme Normali versione 2.0 Questo lavoro è concesso in uso secondo."— Transcript della presentazione:

1 G. Mecca – – 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)

2 2 G. Mecca - - Basi di Dati Sommario m Introduzione Una Tabella non in Forma Normale m Forma Normale di Boyce-Codd Dipendenza Funzionale Definizione Formale m Tecniche per la Verifica di Qualità Progettazione e Forme Normali >> Sommario

3 3 G. Mecca - - Basi di Dati Introduzione m Idealmente se lo schema concettuale è di qualità (corretto, completo e non ridondante) se la progettazione logica è condotta applicando correttamente lalgoritmo la base di dati risultante dovrebbe essere di qualità in particolare: dovrebbe essere in forma normale Progettazione e Forme Normali >> Introduzione

4 4 G. Mecca - - Basi di Dati Introduzione m 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 m E necessario quindi approfondire il concetto di forma normale Progettazione e Forme Normali >> Introduzione

5 5 G. Mecca - - Basi di Dati Introduzione m 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 Progettazione e Forme Normali >> Introduzione

6 6 G. Mecca - - Basi di Dati Una Tabella Non in Forma Normale Progettazione e Forme Normali >> Introduzione studenteannoCorsocorsovotodocente Pinco Palla1Programmazione27F. Totti Pinco Pietro2Programmazione24F. Totti Bruno Pasquale1Basi di Dati30C. Vieri Rossi Paolo2Basi di Dati25C. Vieri Pinco Palla1Tecnologie Web27A. Del Piero Bruno Pasquale1Programmazione21F. Totti StudentiCorsiEsamiT studente CHAR(20)PK corso CHAR(20)PK annoCorso INTEGER voto INTEGER docente VARCHAR(20)

7 7 G. Mecca - - Basi di Dati Una Tabella Non in Forma Normale m Da dove nascono i problemi errori in fase di modello concettuale Progettazione e Forme Normali >> Introduzione StudentiCorsiEsami > studente > corso annoCorso voto docente 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. La specifica Lo Schema Concettuale

8 8 G. Mecca - - Basi di Dati Una Tabella Non in Forma Normale m Uno schema più corretto Progettazione e Forme Normali >> Intoduzione Studente > nome annoCorso Corso > nome docente sostiene esame di > 0..* voto

9 9 G. Mecca - - Basi di Dati Una Tabella Non in Forma Normale m La base di dati risultante Progettazione e Forme Normali >> Introduzione nomeannoCorso Pinco Palla1 Pinco Pietro2 Bruno Pasquale1 Rossi Paolo2 nomedocente ProgrammazioneF. Totti Basi di DatiC. Vieri Tecnologie WebA. Del Piero studenteesamevoto Pinco PallaProgrammazione27 Pinco PietroProgrammazione24 Bruno PasqualeBasi di Dati30 Rossi PaoloBasi di Dati25 Pinco PallaTecnologie Web27 Bruno PasqualeProgrammazione21 EsamiT studente CHAR(20)PK, FK corso CHAR(20)PK, FK voto INTEGER CorsoT nome CHAR(20)PK docente VARCHAR(20) StudenteT nome CHAR(20)PK annoCorso INTEGER

10 10 G. Mecca - - Basi di Dati Una Tabella Non in Forma Normale m Intuitivamente lerrore nasce dalla scelta del modello concettuale una classe che descrive più di un concetto in generale, invece, ogni classe dovrebbe descrivere un unico concetto m Attenzione lerrore potrebbe non essere percepibile guardando il modello concettuale Progettazione e Forme Normali >> Introduzione

11 11 G. Mecca - - Basi di Dati Una Tabella Non in Forma Normale m Per evitare questi problemi è necessario effettuare verifiche ripetute sui risultati della progettazione logica ed, in caso di errori, correggere lo schema concettuale m Oggetto delle verifiche che le tabelle prodotte rispettino una forma normale Progettazione e Forme Normali >> Introduzione

12 12 G. Mecca - - Basi di Dati Forma Normale m Vincolo sulla struttura di una base di dati garantisce che non si generano anomalie m Discuteremo la F. N. di Boyce-Codd è quella più forte normalmente ottenibile (tranne casi strani) m Terza Forma Normale è più debole di quella di Boyce-Codd è sempre ottenibile (ma non ne parleremo) Progettazione e Forme Normali >> Forma Normale

13 13 G. Mecca - - Basi di Dati Forma Normale m Forma Normale di Boyce-Codd (FNBC) vincolo sullorganizzazione delle tabelle della base di dati una tabella che rispetta il vincolo si dice normalizzata altrimenti si dice non normalizzata m Approccio daremo prima lintuizione, poi la formalizzazione Progettazione e Forme Normali >> Forma Normale

14 14 G. Mecca - - Basi di Dati Forma Normale m Intuizione R si dice in FNBC se non esiste nessuna sottotabella con una chiave propria m Sottotabella qualsiasi proiezione di R m Sottotabella con chiave propria proiezione per cui è possibile trovare una chiave primaria non banale che non è chiave per R Progettazione e Forme Normali >> Forma Normale

15 15 G. Mecca - - Basi di Dati Forma Normale m Nel nostro esempio: esistono varie sottotabelle con chiavi proprie Progettazione e Forme Normali >> Forma Normale Studenti = studente, annoCorso (StudentiCorsiEsami) StudentiT studente CHAR(20) annoCorso INTEGER la specifica mi dice che studente è una chiave per la tabella StudentiCorsiEsamiT studente CHAR(20)PK corso CHAR(20)PK annoCorso INTEGER voto INTEGER docente VARCHAR(20)

16 16 G. Mecca - - Basi di Dati Forma Normale m In modo simile: Progettazione e Forme Normali >> Forma Normale Corsi = corso, docente (StudentiEsamiCorsi) CorsiT corso CHAR(20) docente VARCHAR(20) la specifica mi dice che corso è una chiave per la tabella StudentiCorsiEsamiT studente CHAR(20)PK corso CHAR(20)PK annoCorso INTEGER voto INTEGER docente VARCHAR(20)

17 17 G. Mecca - - Basi di Dati Forma Normale m Viceversa, in questa tabella non esistono sottotabelle con chiavi proprie Progettazione e Forme Normali >> Forma Normale EsamiT studente CHAR(20)PK corso CHAR(20)PK voto INTEGER Esempio = studente, voto (Esami) EsempioT studente CHAR(20) voto INTEGER NON ci sono chiavi proprie

18 18 G. Mecca - - Basi di Dati Forma Normale m Infatti, guardando listanza non esiste nessuna chiave (vedi specifica) Progettazione e Forme Normali >> Forma Normale EsempioT studente CHAR(20) voto INTEGER lo stesso discorso vale per tutte le altre possibili proiezioni studentevoto Pinco Palla27 Pinco Pietro24 Bruno Pasquale30 Rossi Paolo25 Pinco Palla27 Bruno Pasquale21

19 19 G. Mecca - - Basi di Dati Forma Normale m Un altro esempio Progettazione e Forme Normali >> Forma Normale DocenteT codice CHAR(4)PK cognome CHAR(20) nome CHAR(20) facolta CHAR(10) qualifica CHAR(15) tipo CHAR(10) DocenteNumeroT 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

20 20 G. Mecca - - Basi di Dati Forma Normale m Per formalizzare abbiamo bisogno di una nozione ulteriore m Concetto di Dipendenza Funzionale vincolo di integrità aggiuntivo sulle tabelle è una generalizzazione del vincolo di chiave m In sostanza serve a dire che valori uguali di un attributo in una tabella implicano valori uguali di altri attributi Progettazione e Forme Normali >> Forma Normale

21 21 G. Mecca - - Basi di Dati Dipendenza Funzionale m Sintassi data una tabella R con attributi A, B, C, D,... A, B,... C, D,... m 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,... Progettazione e Forme Normali >> Forma Normale >> Dip. Funzionale

22 22 G. Mecca - - Basi di Dati Dipendenza Funzionale m Esempi Progettazione e Forme Normali >> Forma Normale >> Dip. Funzionale studente annoCorso corso docente studente, corso voto, annoCorso, docente studenteannoCorsocorsovotodocente Pinco Palla1Programmazione27F. Totti Pinco Pietro2Programmazione24F. Totti Bruno Pasquale1Basi di Dati30C. Vieri Rossi Paolo2Basi di Dati25C. Vieri Pinco Palla1Tecnologie Web27A. Del Piero Bruno Pasquale1Programmazione21F. Totti

23 23 G. Mecca - - Basi di Dati Dipendenza Funzionale m 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 m Nota per definizione, vale anche: Progettazione e Forme Normali >> Forma Normale studente, corso studente, corso, voto, annoCorso, docente

24 24 G. Mecca - - Basi di Dati Dipendenza Funzionale m 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 m In generale una tabella ha varie dipendenze funzionali non banali (e moltissime banali) Progettazione e Forme Normali >> Forma Normale

25 25 G. Mecca - - Basi di Dati Definizione Formale m 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 m 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 Progettazione e Forme Normali >> Forma Normale >> Def. Formale

26 26 G. Mecca - - Basi di Dati Definizione Formale m Esempi: tabella non normalizzata Progettazione e Forme Normali >> Forma Normale >> Def. Formale StudentiEsamiCorsiT studente CHAR(20)PK corso CHAR(20)PK annoCorso INTEGER voto INTEGER docente VARCHAR(20) studente annoCorso corso docente (suggerisce la sottotabella corrispondente alla proiezione su studente e annoCorso) (suggerisce la sottotabella corrispondente alla proiezione su corso e docente)

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

28 28 G. Mecca - - Basi di Dati Tecniche di Verifica m In concreto scoprire lerrore dopo aver creato la base di dati sarebbe grave è opportuno verificare continuamente i risultati della progettazione per accorgersi tempestivamente degli errori m Idealmente verifica sullo schema concettuale (se lo schema è corretto, tabelle normalizzate) Progettazione e Forme Normali >> Tecniche di Verifica

29 29 G. Mecca - - Basi di Dati Tecniche di Verifica m 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 Progettazione e Forme Normali >> Tecniche di Verifica

30 30 G. Mecca - - Basi di Dati Tecniche di Verifica m In generale ogni classe deve rappresentare un concetto m 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 Progettazione e Forme Normali >> Tecniche di Verifica

31 31 G. Mecca - - Basi di Dati Tecniche di Verifica m Esempio: molti a molti Progettazione e Forme Normali >> Tecniche di Verifica StudentiEsamiCorsi > studente > corso annoCorso voto docente Studente > nome annoCorso Corso > nome docente sostiene esame di > 0..* voto

32 32 G. Mecca - - Basi di Dati Tecniche di Verifica m Esempio: 1 a molti Progettazione e Forme Normali >> Tecniche di Verifica StudenteEsame > matricola cognome nome annoDicorso voto lode data Studente > matricola cognome nome annoDiCorso Esame voto lode data ha sostenuto > 0..* 1

33 33 G. Mecca - - Basi di Dati Tecniche di Verifica m Esempio: attributo multivalore Progettazione e Forme Normali >> Tecniche di Verifica DocenteNumeri cognome nome qualifica numTelefono > Docente cognome nome qualifica numTelefono [0..*]

34 34 G. Mecca - - Basi di Dati Tecniche di Verifica m Attenzione bisogna però evitare lerrore opposto, ovvero quello di separare eccessivamente i concetti Progettazione e Forme Normali >> Tecniche di Verifica Votazione voto lode ha riportato > 1 0..n Esame data in questo caso, risalire ai voti costringe a fare join non necessari

35 35 G. Mecca - - Basi di Dati Tecniche di Verifica m Concludendo è necessario trovare il giusto compromesso nella scelta delle classi m In particolare una classe deve tradurre un concetto ben identificabile (non accorpare troppo) non bisogna creare classi che rappresentano concetti irrilevanti (non separare troppo) Progettazione e Forme Normali >> Tecniche di Verifica

36 36 G. Mecca - - Basi di Dati Tecniche di Verifica m 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 Progettazione e Forme Normali >> Tecniche di Verifica

37 37 G. Mecca - - Basi di Dati Sommario m Introduzione Una Tabella non in Forma Normale m Forma Normale di Boyce-Codd Dipendenza Funzionale Definizione Formale m Tecniche per la Verifica di Qualità Progettazione e Forme Normali >> Sommario

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

39 39 G. Mecca - - Basi di Dati Progettazione Logica >> Algoritmo di Traduzione TirocinioT studente INTEGERPK, FK sede CHAR(20) dataInizio DATE durata INTEGER TutoratoT studente INTEGERPK, FK tutor INTEGERPK, FK StudenteT matricola INTEGERPK cognome CHAR(20) nome CHAR(20) ciclo CHAR(15) anno INTEGER relatore CHAR(4)FK DocenteT codice CHAR(4)PK cognome CHAR(20) nome CHAR(20) facolta CHAR(10) qualifica CHAR(15) tipo CHAR(10) EsameT codice CHAR(5)PK voto INTEGER lode BOOL data DATE corso CHAR(3)FK stud INTEGERFK CorsoT codice CHAR(3)PK titolo CHAR(20) ciclo CHAR(20) TitolaritàT corso CHAR(3)PK, FK docente CHAR(4)PK, FK NumeriT numero CHAR(15)PK docente CHAR(4)FK

40 40 G. Mecca - - Basi di Dati Termini della Licenza m This work is licensed under the Creative Commons Attribution- ShareAlike License. To view a copy of this license, visit or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. m m Questo lavoro viene concesso in uso secondo i termini della licenza Attribution-ShareAlike di Creative Commons. Per ottenere una copia della licenza, è possibile visitare oppure inviare una lettera allindirizzo Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.


Scaricare ppt "G. Mecca – – Università della Basilicata Basi di Dati Progettazione e Forme Normali versione 2.0 Questo lavoro è concesso in uso secondo."

Presentazioni simili


Annunci Google