Forma normale di Boyce e Codd Definizione

Impiegato Progetto  Funzione Le DF di Dipartimento Impiegato Stipendio Progetto Bilancio Funzione Rossi 20 Marte 2 tecnico Verdi 35 Giove 15 progettista Venere Neri 55 direttore consulente Mori 48 Bianchi Impiegato  Stipendio Progetto  Bilancio Impiegato Progetto  Funzione

Impiegato  Stipendio La Df riporta che lo stipendio di ciascun impiegato dipende solo dall’impiegato stesso indipendentemente dai progetti a cui partecipa e quindi presenta Ridondanza Anomalia di aggiornamento Anomalia di cancellazione Anomalia di inserimento

Progetto  Bilancio La DF riporta che il bilancio di ciascun progetto dipende solo dal progetto stesso indipendentemente dalla partecipazione degli impiegati ai progetti e quindi presenta Ridondanza Anomalia di aggiornamento Anomalia di cancellazione Anomalia di inserimento

Impiegato Progetto  Funzione La DF riporta che in ogni progetto ogni impiegato svolge una ed una sola funzione. Si noti che, essendo (Impiegato, Progetto) chiave di Dipartimento non esistono due tuple con stessa chiave e Funzione (non esistono ridondanze) La modifica interviene su una sola tupla La cancellazione non comporta perdita di informazioni che potrebbero essere ancora utili L’inserimento è possibile anche attribuendo valori nulli agli attributi diversi da Impiegato e Progetto

DF ed anomalie Le anomalie viste si riconducono alla presenza delle DF: Impiegato → Stipendio Progetto → Bilancio Viceversa la FD Impiegato, Progetto → Funzione non causa problemi Le anomalie sono causate dalla presenza di concetti eterogenei: proprietà degli impiegati (lo stipendio) proprietà dei progetti (il bilancio) proprietà della chiave Impiegato Progetto

La causa delle anomalie Le prime due FD non corrispondono a chiavi e causano anomalie La terza FD corrisponde ad una chiave e non causa anomalie Impiegato  Stipendio Impiegato non è chiave Progetto  Bilancio Progetto non è chiave Impiegato Progetto  Funzione Impiegato Progetto è chiave

Forma Normale di Boyce e Codd Uno relazione r è in forma normale di Boyce e Codd se: per ogni dipendenza funzionale (non banale) X → Y definita su R(T), X contiene una chiave K di r Ossia X è una superchiave di r

Normalizzazione La normalizzazione è il processo di trasformazione che data una relazione che non soddisfa una forma normale la scompone in altre relazioni che invece soddisfano la forma normale Nel caso della forma normale di Boyce e Codd la trasformazione si basa su un semplice criterio: Individuazione dei diversi concetti riportati insieme nella relazione Decomposizione della relazione in relazioni più semplici, una per ogni concetto.

Un esempio di normalizzazione Impiegato Progetto Funzione Rossi Marte tecnico Stipendio Verdi Giove progettista 20 Venere Bilancio 35 Neri direttore 2 55 consulente 15 Mori 48 Bianchi

Non sempre così facile Impiegato  Sede Progetto  Sede Impiegato Rossi Marte Roma Verdi Giove Milano Venere Neri Saturno Impiegato  Sede Progetto  Sede

Proviamo a ricostruire Impiegato Sede Progetto Rossi Roma Marte Verdi Milano Giove Neri Saturno Venere Diversa dalla relazione di partenza!

Decomposizione senza perdita La decomposizione non deve assolutamente alterare il contenuto informativo del DB Si introduce pertanto il seguente requisito Decomposizione senza perdita (lossless) Uno schema R(X) si decompone senza perdita negli schemi R1(X1) e R2(X2) se, per ogni istanza legale r su R(X), il join naturale delle proiezioni di r su X1 e X2 è uguale a r stessa X1(r)  X2(r) = r

Decomposizione senza perdita Una decomposizione con perdita può generare tuple spurie Per decomporre senza perdita è necessario e sufficiente che il join naturale sia eseguito su una superchiave di uno dei due sottoschemi, ovvero che valga X1 ∩ X2 → X1 oppure X1 ∩ X2 → X2 La decomposizione senza perdita è garantita se gli attributi comuni contengono una chiave per almeno una delle relazioni decomposte

Decomposizione senza perdita Impiegato Progetto Sede Rossi Marte Roma Verdi Giove Milano Venere Neri Saturno

Un altro problema (1/3) Supponiamo di voler inserire una nuova ennupla che specifica la partecipazione dell'impiegato Neri, che opera a Milano, al progetto Marte Ricordiamo che le dipendenze sullo schema originario sono Impiegato  Sede Progetto  Sede Ossia un impiegato deve operare su una sola sede e anche i progetti devono insistere su una sola sede

Un altro problema (2/3) Impiegato Sede Progetto Rossi Roma Marte Verdi Milano Giove Neri Venere Saturno

Proviamo a ricostruire La dipendenza Progetto  Sede non è preservata Un altro problema (3/3) Proviamo a ricostruire Impiegato Progetto Sede Rossi Marte Roma Verdi Giove Milano Venere Neri Saturno La dipendenza Progetto  Sede non è preservata

Conservazione delle dipendenze Una istanza legale nello schema decomposto genera sullo schema ricostruito una soluzione non ammissibile Ogni singola istanza è (“localmente”) legale, ma il DB (“globalmente”) non lo è Infatti il progetto “Marte” risulta essere assegnato a due sedi, in violazione del vincolo Progetto  Sede Problemi di consistenza dei dati si hanno quando la decomposizione “separa” gli attributi di una FD. Per verificare che la FD sia rispettata si rende necessario far riferimento a entrambe le relazioni.

Conservazione delle dipendenze Una decomposizione preserva le dipendenze se ciascuna delle dipendenze funzionali dello schema originario coinvolge attributi che compaiono tutti insieme in uno degli schemi decomposti Nell’esempio la dipendenza Progetto  Sede non è conservata Se una FD non si preserva diventa più complicato capire quali sono le modifiche del DB che non violano la DF stessa

Alcune definizioni: attributo primo Un attributo di uno schema di relazione R è detto attributo primo di R se esso è membro di una qualche chiave candidata di R. Un attributo è detto non primo se non è un attributo primo, cioè se non è membro di nessuna chiave candidata.

1 Forma Normale La 1FN è parte integrante della definizione formale di relazione nel modello relazionale di base. La 1FN impone che il dominio di un attributo comprenda solo valori atomici. La 1FN non consente quindi di usare attributi multivalore, composti o una loro qualsiasi combinazione.

2 Forma normale La 2FN si basa sul concetto di dipendenza funzionale completa. Una dipendenza funzionale X->Y è una dipendenza funzionale completa se la rimozione di un qualsiasi attributo A da X fa decadere la DF. Una DF è parziale se è possibile rimuovere da X attributi senza che essa venga meno. Uno schema di relazione R è in 2FN se ogni attributo non primo A di R dipende funzionalmente in modo completo dalla chiave primaria di R

2 Forma normale: considerazioni Uno schema di relazione è in 2FN se ogni attributo non primo A di R non è parzialmente dipendente da nessuna chiave di R. La verifica comporta l’esame delle DF i cui attributi della parte sinistra fanno parte della chiave primaria. Se la chiave primaria è fatta da un sol attributo (il che stabilisce che le DF sulla chiave sono complete) allora lo schema di relazione è già in 2FN.

3 Forma Normale La 3FN si basa sul concetto di DF transitiva. Una DF X->Y definita sullo schema di relazione R è transitiva se esiste un insieme Z, che non è né chiave candidata né appartiene ad una chiave di R, per cui valgono contemporaneamente X->Z e Z->Y Uno schema di relazione R è in 3FN se soddisfa la 2FN e nessun attributo non primo di R dipende in modo transitivo dalla chiave primaria (definizione originaria di Codd).

3 Forma Normale: generalizzazione Uno schema di relazione R è in 3FN se ogni volta che sussiste in R una DF non banale X->A o X è una superchiave di R o A è un attributo primo di R Quindi uno schema di relazione R non è in 3FN quando viola entrambe le condizioni. Da cui si ricava: Uno schema di relazione R è in 3FN se ogni attributo non primo di R è funzionalmente dipendente in modo completo da ogni chiave di R e non è dipendente in modo transitivo da alcuna chiave di R.

3FN e BCNF La forma normale di Boyce e Codd è stata proposta come una forma più semplice di 3FN ma difatti è più restrettiva. Ogni relazione in BCNF è anche in 3FN. Le relazioni in 3FN non necessariamente sono in BCFN

Ancora anomalie Lo schema TEL(Prefisso,Numero,Località,Abbonato,Indirizzo) ha vincoli Prefisso,Numero → Località,Abbonato, Indirizzo Località → Prefisso Lo schema è in 3NF, in quanto Prefisso è primo (non c’è dipendenza transitiva) Nella seguente istanza legale l’informazione sul prefisso viene replicata per ogni abbonato Prefisso Numero Località Abbonato Indirizzo 051 457856 Bologna Rossi Via Roma 8 059 452332 Modena Verdi Via Bari 16 987856 Bianchi Via Napoli 77 552346 Castenaso Neri Piazza Borsa 12 387654 Vignola Mori Via Piave 65

Decomposizione in BCNF Una soluzione consiste nel decomporre lo schema in NUM_TEL(Numero,Località,Abbonato,Indirizzo) PREF_TEL(Località, Prefisso) La decomposizione è lossless perché (NUM_TEL  PREF_TEL) = TEL Numero Località Abbonato Indirizzo Prefisso 457856 Bologna Rossi Via Roma 8 051 452332 Modena Verdi Via Bari 16 059 987856 Bianchi Via Napoli 77 Castenaso 552346 Neri Piazza Borsa 12 Vignola 387654 Mori Via Piave 65

Osservazioni Benché gli schemi in 3NF non siano esenti da problemi, tale livello di normalizzazione è comunemente accettato nella pratica Nel caso generale, problemi di complessità computazionale rendono improponibile affrontare l’attività di normalizzazione mediante tecniche di “analisi”. Tutti i seguenti problemi sono NP-completi: Determinare se un attributo è primo Verificare se esiste una chiave di grado minore di k Verificare se uno schema è in 3NF

Osservazioni L’approccio adottato è di tipo costruttivo, ovvero anziché verificare se uno schema è al livello di normalizzazione richiesto, si progettano schemi che siano a tale livello di normalizzazione. Qualità di una decomposizione (ottenibile con algoritmi di normalizzazione): deve essere senza perdita, per garantire la ricostruzione delle informazioni originarie dovrebbe conservare le dipendenze, per semplificare il mantenimento dei vincoli di integrità originari

Decomposizione in 3NF L’idea alla base dell’algoritmo che produce una decomposizione in 3NF è creare una relazione per ogni gruppo di FD che hanno lo stesso lato sinistro (determinante) e inserire nello schema corrispondente gli attributi coinvolti in almeno una FD del gruppo Esempio: Se le FD individuate sullo schema R(ABCDEFG) sono: AB→ CD, AB →E, C → F, F → G si generano gli schemi: R1(ABCDE), R2(CF), R3(FG)

Decomposizione in 3NF Se 2 o più determinanti si determinano reciprocamente, si fondono gli schemi (più chiavi alternate per lo stesso schema) Esempio: Se le FD su R(ABCD) sono: A →BC, B → A, C →D si generano gli schemi R1(ABC), R2(CD)

Decomposizione in 3NF Alla fine si verifica che esista uno schema la cui chiave è anche chiave dello schema originario (se non esiste lo si crea) Esempio: Se le FD su R(ABCD) sono: A →C, B →D si generano gli schemi R1(AC), R2(BD), R3(AB)

Una limitazione non superabile Dirigente Progetto Sede Rossi Marte Roma Verdi Giove Milano Neri Saturno Venere Progetto Sede  Dirigente Dirigente  Sede

Una limitazione non superabile Nell’esempio la dipendenza Progetto,SedeDirigente coinvolge tutti gli attributi e quindi nessuna decomposizione può preservare tale dipendenza Quindi, in funzione del pattern di FD, potrebbe non essere possibile decomporre in BCNF e preservare le FD

In pratica… Se la relazione non è normalizzata si decompone in terza forma normale Si verifica se lo schema ottenuto è anche in BCNF Si noti che se una relazione ha una sola chiave allora le due forme normali coincidono Se uno schema non è in BCNF si hanno 3 alternative: Si lascia così com’è, gestendo le anomalie residue (se l’applicazione lo consente) Si decompone in BCNF, predisponendo opportune query di verifica (per verificare le dipendenze originarie vengano violate) Si cerca di rimodellare la situazione iniziale, al fine di permettere di ottenere schemi BCNF

BCNF e 3a Forma Normale La terza forma normale è meno restrittiva della forma normale di Boyce e Codd (e ammette relazioni con alcune anomalie) Ha il vantaggio però di essere sempre “raggiungibile”

Progetto Sede  Dirigente Uno schema non in BCNF Dirigente Progetto Sede Rossi Marte Roma Verdi Giove Milano Neri Saturno Venere Progetto Sede  Dirigente Dirigente  Sede

Una possibile riorganizzazione Dirigente Progetto Sede Reparto Rossi Marte Roma 1 Verdi Giove Milano Neri Saturno 2 Venere Dirigente  Sede Reparto Sede Reparto  Dirigente Progetto Sede  Reparto

Decomposizione in BCNF Progetto Sede Reparto Dirigente Marte Roma 1 Rossi Giove Milano Verdi Neri 2 Saturno Venere

Progettazione e normalizzazione La teoria della normalizzazione può essere usata nella progettazione logica per verificare lo schema relazionale finale Si può usare anche durante la progettazione concettuale per verificare la qualità dello schema concettuale

Es.: entità non normalizzata Prodotto Nome prodotto Prezzo fornitore Indirizzo Partita IVA Codice PartitaIVA  NomeFornitore Indirizzo

Analisi dell’entità L’entità viola la terza forma normale a causa della dipendenza: PartitaIVA  NomeFornitore Indirizzo Possiamo decomporre sulla base di questa dipendenza

Decomposizione Fornitura Prodotto Fornitore Indirizzo Partita IVA Nome Prezzo Codice Fornitura Prodotto Fornitore (1,1) (0,N)

Es.: associazione non normalizzata Professore Studente Corso di laurea (0,N) (0,1) Dipartimento Tesi Studente  Corso di laurea Studente  Professore Professore  Dipartimento

Analisi dell’associazione L’ associazione viola la terza forma normale a causa della dipendenza: Professore  Dipartimento Possiamo decomporre sulla base di questa dipendenza

Decomposizione Afferenza Professore Studente Corso di laurea (1,1) (0,N) Professore Studente Corso di laurea (0,1) Dipartimento Tesi

Ulteriore analisi sulla base delle dipendenze L’associazione Tesi in BCNF sulla base delle dipendenze Studente  CorsoDiLaurea Studente  Professore Le due proprietà sono indipendenti Questo suggerisce una ulteriore decomposizione

Ulteriore decomposizione Tesi (0,N) (0,1) Professore Studente (1,1) (1,1) Afferenza Iscrizione (0,N) (0,N) Dipartimento Corso di laurea

Normalizzazione vs. performances Potremmo voler utilizzare schemi non normalizzati per aumentare la performances Ad es. collegare e mostrare informazioni memorizzate in due tabelle differenti richiede il join delle tabelle

Normalizzazione vs. performances Alternativa 1: usare schemi denormalizzati che contengono gli attributi di entrambe le relazioni accesso più veloce spazio e tempo di esecuzione superiore per gestire le modifiche maggiore sforzo di programmazione per gestire la ridondanza, con conseguente maggiore incidenza degli errori di programmazione Alternativa 2: usare una vista materializzata stessi vantaggi e svantaggi della alternativa 1, eccetto il maggiore sforzo di programmazione

Riferimenti Atzeni, Ceri, Paraboschi, Torlone – Basi di dati – McGraw-Hill, 1999 Cabibbo, Torlone, Batini – Basi di dati: progetti ed esercizi svolti – Pitagora editrice, Bologna, 1995 Atzeni, Batini, De Antonellis – Teoria relazionale dei dati – Boringhieri, Torino, 1985