G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati Progettazione e Forme...

G. Mecca – mecca@unibas.it – Università della BasilicataG. Mecca – mecca@unibas.it – 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 - mecca@unibas.it - Basi di DatiG. Mecca - mecca@unibas.it - 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

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

<<id>> nome

docente

sostiene esame di >

0..* 0..*

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

docente

Studente

<<id>> nome

annoCorso

<<id>> nome

docente

sostiene esame di >

0..* 0..*

Esempio: 1 a molti

StudenteEsame

<<id>> matricola

cognome

annoDicorso

<<id> data

Studente

<<id>> matricola

cognome

annoDiCorso

ha sostenuto > 0..*1

Esempio: attributo multivalore

DocenteNumeri

cognome

qualifica

numTelefono <<id>>

Docente

cognome

qualifica

numTelefono [0..*]

Attenzionebisogna però evitare l’errore opposto, ovvero

quello di separare eccessivamente i concetti

Votazione

ha riportato > 10..nEsame

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

annoDiCorso

Docente

cognome

qualifica

numTelefono [0..*]

DocenteInterno

facolta

Supplente Studente

Laurea

Triennale

Studente

Laurea

Specialistica

0..* 0..1tutor >

relatore >

0..*0..1

<<id>> codice

titolo

titolarità

ha sostenuto >10..*

< relativo a

Schema Concettuale

Tirocinio

dataInizio

durata

ha svolto >

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

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 – Università della Basilicata Basi di Dati Progettazione e Forme...

Documents

Transcript of G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati Progettazione e Forme...

G. Mecca – mecca@unibas.it – Università della Basilicata Tecnologie di Sviluppo per il Web Introduzione Architettura di Riferimento versione 2.0 Questo.

G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati Algebra Relazionale Concetti Fondamentali versione 2.0 Questo lavoro è concesso in.

G. Mecca – mecca@unibas.it – Università della Basilicata Tecnologie di Sviluppo per il Web Introduzione Il Protocollo HTTP versione 2.0 Questo lavoro è

Diaporama MECCA JV

G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati SQL-92 Dettagli e Approfondimenti versione 2.0 Questo lavoro è concesso in uso secondo.

Programmazione Orientata agli Oggetti in Linguaggio Java · 26/01/2005 1 G. Mecca – Università della Basilicata – mecca@unibas.it Programmazione Orientata agli Oggetti in Linguaggio

G. Mecca – Università della Basilicata – mecca@unibas.it Tecnologie di Sviluppo per il Web JavaScript Concetti Fondamentali versione 2.0 Questo lavoro.

G. Mecca – mecca@unibas.it – Università della Basilicata Tecnologie di Sviluppo per il Web XHTML Introduzione versione 2.0 Questo lavoro è concesso in.

G. Mecca – mecca@unibas.it – Università della Basilicata Tecnologie di Sviluppo per il Web XML: Dettagli e Approfondimenti versione 2.0 Questo lavoro è

G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati SQL-92 Concetti Avanzati versione 2.0 Questo lavoro è concesso in uso secondo i termini.

G. Mecca – mecca@unibas.it – Università della Basilicata Tecnologie di Sviluppo per il Web Cascading Style Sheets (CSS): Introduzione versione 2.0 Questo.

Programmazione Orientata agli Oggetti in Linguaggio Java · 10/05/2005 1 G. Mecca – Università della Basilicata – mecca@unibas.it Programmazione Orientata agli Oggetti in Linguaggio

Mecca Plan 1946

MAKKAH MECCA uS JA -MECCA · MAKKAH MECCA uS JA -MECCA . Created Date: 5/28/2009 9:28:15 PM

Programmazione Orientata agli Oggettidb.unibas.it/users/mecca/corsi/2002-2003/...Elementi di Base: Ruoli e Responsabilità versione 1.0 2 G. Mecca - Programmazione Orientata agli Oggetti

G. Mecca – mecca@unibas.it – Università della Basilicata Tecnologie di Sviluppo per il Web XML: Concetti Fondamentali versione 2.0 Questo lavoro è concesso.

G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati Modello Concettuale dei Dati: Concetti Fondamentali versione 2.0 Questo lavoro è

G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati Tecnologia di un DBMS: Concorrenza e Affidabilità Concetti Avanzati versione 2.0.

G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati Progettazione Fisica e Tuning: Concetti Avanzati versione 2.0 Questo lavoro è concesso.

G. Mecca – mecca@unibas.it – Università della Basilicata Basi di Dati Sistemi per BD Relazionali: Modello Fisico Concetti Avanzati versione 2.0 Questo.