S. Costantini 06/05/2006 (parte del materiale è tratto da slide del 2001 di Ceri-Atzeni) Normalizzazione di Schemi

06/06/2006Normalizzazione di Schemi Relazionali 2 Forme normali Una forma normale è una proprietà di una base di dati relazionale che ne garantisce la “qualità”, cioè l'assenza di determinati difetti Quando una relazione non è normalizzata: presenta ridondanze, si presta a comportamenti poco desiderabili durante gli aggiornamenti Le forme normali sono di solito definite sul modello relazionale, ma hanno senso in altri contesti, ad esempio il modello E-R

06/06/2006Normalizzazione di Schemi Relazionali 3 Forme Normali Forma normale: proprietà delle relazioni di un DB Altrimenti: comportamenti indesiderati Verifica forma normale = verifica di qualità Metodologie di progettazione  Schemi già in forma normale Normalizzazione: Schema  Schema normalizzato

06/06/2006Normalizzazione di Schemi Relazionali 4 Normalizzazione Procedura che permette di trasformare schemi non normalizzati in schemi che soddisfano una forma normale La normalizzazione va utilizzata come tecnica di verifica dei risultati della progettazione di una base di dati Non costituisce una metodologia di progettazione

06/06/2006Normalizzazione di Schemi Relazionali 5 Una relazione con anomalie

06/06/2006Normalizzazione di Schemi Relazionali 6 Proprietà di questa Tabella lo stipendio di ciascun impiegato è unico (indipendentemente dai progetti cui partecipa) il bilancio di ciascun progetto è unico (indipendentemente dagli impiegati che vi partecipano) La funzione di un impiegato in un progetto è unica Ridondanze: stipendio di ciascun impiegato ripetuto in tutte le tuple relative ad esso bilancio di ciascun progetto ripetuto per ogni impiegato che partecipa

06/06/2006Normalizzazione di Schemi Relazionali 7 Anomalie anomalia di aggiornamento: lo stipendio di un impiegato varia  modifica di tutte le tuple corrispondenti anomalia di cancellazione: un impiegato interrompe la partecipazione a tutti i progetti  spariscono nome e stipendio (a meno di valori nulli sull'unica chiave) anomalia di inserimento: impossibile inserire nuovo impiegato senza progetto motivo di questi inconvenienti: unica relazione per gestire dati e associazioni tra dati di tipo diverso.

06/06/2006Normalizzazione di Schemi Relazionali 8 Difetti fra Relazioni su Concetti Disomogenei Dati ripetuti in diverse tuple, senza aggiungere informazioni significative. Informazioni ripetute  aggiornamento ripetuto per ciascuna occorrenza Informazioni ripetute  la cancellazione di una tupla può comportare l’ eliminazione di concetti ancora necessari Inserimento di informazioni relative ad uno solo dei concetti non possibile se esse non costituiscono una tupla completa (o almeno la sua chiave primaria)

06/06/2006Normalizzazione di Schemi Relazionali 9 Perché questi fenomeni indesiderabili? abbiamo usato un'unica relazione per rappresentare informazioni eterogenee gli impiegati con i relativi stipendi i progetti con i relativi bilanci le partecipazioni degli impiegati ai progetti con le relative funzioni

06/06/2006Normalizzazione di Schemi Relazionali 10 Per studiare in maniera sistematica questi aspetti, è necessario introdurre un vincolo di integrità: la dipendenza funzionale

06/06/2006Normalizzazione di Schemi Relazionali 11 Proprietà Ogni impiegato ha un solo stipendio (anche se partecipa a più progetti) Ogni progetto ha un bilancio Ogni impiegato in ciascun progetto ha una sola funzione (anche se può avere funzioni diverse in progetti diversi)

06/06/2006Normalizzazione di Schemi Relazionali 12 Dipendenza Funzionale dipendenza funzionale: vincolo di integrità per il modello relazionale  descrive legami di tipo funzionale tra gli attributi di una relazione Esempio: il valore dell'attributo Impiegato determina il valore dell'attributo Stipendio: esiste una funzione che associa ad ogni elemento del dominio dell'attributo Impiegato un solo elemento del dominio dell'attributo Stipendio

06/06/2006Normalizzazione di Schemi Relazionali 13 Formalizzazione Relazione r su uno schema R(X) sottoinsiemi di attributi non vuoti Y e Z di X insieme I di coppie di tuple t1 e t2 di r con uguali valori sugli attributi Y esiste su r una dipendenza funzionale tra Y e Z, se, per ogni coppia (t1,t2)  I, t1 e t2 hanno gli stessi valori anche sugli attributi Z Sintassi:Y  Z il vincolo cosi’ definito si associa a schema R(X) Semantica: relazione r su schema R(X) corretta se soddisfa le dipendenze funzionali che la coinvolgono

06/06/2006Normalizzazione di Schemi Relazionali 14 In sintesi relazione r su R(X) due sottoinsiemi non vuoti Y e Z di X esiste in r una dipendenza funzionale (FD) da Y a Z se, per ogni coppia di ennuple t 1 e t 2 di r con gli stessi valori su Y, risulta che t 1 e t 2 hanno gli stessi valori anche su Z FD = Functional Dependency

06/06/2006Normalizzazione di Schemi Relazionali 15 Notazione XYXY Esempi: Impiegato  Stipendio Progetto  Bilancio Impiegato Progetto  Funzione

06/06/2006Normalizzazione di Schemi Relazionali 16 Osservazione Dato schema R(K,V) e dato insieme di attributi A  V si ha sempre K  V ossia, il vincolo di dipendenza funzionale generalizza il vincolo di chiave Una dipendenza funzionale Y  Z su uno schema R(X) dove Y è la chiave degenera nel vincolo di chiave se Y  Z = X Nell’ esempio Impiegato Progetto  Stipendio Bilancio Funzione

06/06/2006Normalizzazione di Schemi Relazionali 17 Dipendenze Funzionali banali Impiegato Progetto  Progetto Si tratta però di una FD “banale” (sempre soddisfatta) Y  A è non banale se A non appartiene a Y Y  Z è non banale se nessun attributo in Z appartiene a Y

06/06/2006Normalizzazione di Schemi Relazionali 18 Le anomalie sono legate ad alcune FD gli impiegati hanno un unico stipendio Impiegato  Stipendio i progetti hanno un unico bilancio Progetto  Bilancio

06/06/2006Normalizzazione di Schemi Relazionali 19 Non tutte le FD causano anomalie In ciascun progetto, un impiegato svolge una sola funzione Impiegato Progetto  Funzione Il soddisfacimento è più "semplice"

06/06/2006Normalizzazione di Schemi Relazionali 20 Una differenza fra FD Impiegato  Stipendio Progetto  Bilancio causano anomalie Impiegato Progetto  Funzione non causa anomalie Perché?

06/06/2006Normalizzazione di Schemi Relazionali 21 Impiegato  Stipendio Progetto  Bilancio Impiegato Progetto  Funzione

06/06/2006Normalizzazione di Schemi Relazionali 22 FD e anomalie La terza FD corrisponde ad una chiave e non causa anomalie Le prime due FD non corrispondono a chiavi e causano anomalie La relazione contiene alcune informazioni legate alla chiave e altre ad attributi che non formano una chiave

06/06/2006Normalizzazione di Schemi Relazionali 23 Motivo delle Anomalie abbiamo usato un'unica relazione per rappresentare informazioni eterogenee gli impiegati con i relativi stipendi i progetti con i relativi bilanci le partecipazioni degli impiegati ai progetti con le relative funzioni

06/06/2006Normalizzazione di Schemi Relazionali 24 Impiegato  Stipendio Progetto  Bilancio Impiegato Progetto  Funzione Impiegato Progetto è chiave Impiegato solo no Progetto solo no Le anomalie sono causate dalla presenza di concetti eterogenei: proprietà degli impiegati (lo stipendio) proprietà di progetti (il bilancio) proprietà della chiave Impiegato Progetto

06/06/2006Normalizzazione di Schemi Relazionali 25 In particolare La proprietà "Lo stipendio di ciascun impiegato è funzione del solo impiegato, indipendentemente dai progetti cui partecipa" vuol dire che Impiegato  Stipendio La proprietà "Il bilancio di ciascun progetto dipende dal solo progetto, in­dipendentemente dagli impiegati che vi partecipano" vuol dire che Progetto  Bilancio Queste due proprietà (e quindi le corrispondenti dipendenza funzionali) generano ridondanze e anomalie indesiderate

06/06/2006Normalizzazione di Schemi Relazionali 26 In particolare Poichè gli attributi Impiegato Progetto formano una chiave, allora Impiegato Progetto  Funzione che significa: "In ciascun progetto, ciascuno degli impiegati coinvolti può svolgere una so­ la funzione" Questa dipendenza non genera ridondanze o anomalie proprio perché Impiegato Progetto è una superchiave

06/06/2006Normalizzazione di Schemi Relazionali 27 Forma normale di Boyce e Codd (BCNF) Una relazione r è in forma normale di Boyce e Codd se, per ogni dipendenza funzionale (non banale) X  Y definita su di essa, X contiene una chiave K di r

06/06/2006Normalizzazione di Schemi Relazionali 28 Forma normale di Boyce e Codd (BCNF) BCNF = Boyce-Codd Normal Form La forma normale di Boyce-Codd richiede che i concetti in una relazione siano omogenei (solo proprietà direttamente associate alla chiave)

06/06/2006Normalizzazione di Schemi Relazionali 29 Che facciamo se una relazione non soddisfa la BCNF? La rimpiazziamo con altre relazioni che soddisfano la BCNF Come? Decomponendo sulla base delle dipendenze funzionali, al fine di separare i concetti

06/06/2006Normalizzazione di Schemi Relazionali 30

06/06/2006Normalizzazione di Schemi Relazionali 31 Normalizzazione Procedimento che consiste nel decomporre r non in forma normale rispetto alle dipendenze funzionali D1,..., Dk in n relazioni r1,..., rn in forma normale si vuole che: r = r1 join r2 join rn (P1: decomposizione senza perdita) ogni dipendenza funzionale Dj su r sia soddisfatta in almeno una delle r1,..., rn date (P2: conservazione delle dipendenze)

06/06/2006Normalizzazione di Schemi Relazionali 32 Caso favorevole della normalizzazione si decompone r in tante relazioni quante sono le dipendenze funzionali (non banali) con diverso primo membro

06/06/2006Normalizzazione di Schemi Relazionali 33 Rispetto all’esempio D1: Impiegato  Stipendio D2: Progetto  Bilancio D3: Impiegato Progetto  Funzione Decomposizione R1(Impiegato, Stipendio ) R2(Progetto, Bilancio) R3(Impiegato, Progetto, Funzione) ciascuna dipendenza corrisponde ad una diversa relazione la cui chiave è proprio il primo membro della dipendenza stessa

06/06/2006Normalizzazione di Schemi Relazionali 34 Dipendenze con struttura complessa può non essere necessario (o possibile) basare la decomposizione su tutte le dipendenze può essere difficile individuare quelle su cui si deve basare la decomposizione. Impiegato Categoria Stipendio Neri330 Verdi330 Rossi450 Mori450 Bianchi572

06/06/2006Normalizzazione di Schemi Relazionali 35 Proprietà Esempio Relazione nell’esempio: soddisfa le dipendenze (non banali) D1: Impiegato  Categoria D2: Categoria  Stipendio

06/06/2006Normalizzazione di Schemi Relazionali 36 Decomposizione in BCNF R1 Impiegato Categoria Neri3 Verdi3 Rossi4 Mori4 Bianchi5

06/06/2006Normalizzazione di Schemi Relazionali 37 Decomposizione in BCNF R2 Categoria Stipendio

06/06/2006Normalizzazione di Schemi Relazionali 38 Osservazione Attenzione: Scegliendo invece le dipendenze D1’: Impiegato  Categoria Stipendio D2: Categoria  Stipendio forma normale non possibile, perchè D1’ copre tutti gli attributi, quindi impossibile decomporre Quindi: no dipendenze che coprono tutti gli attributi

06/06/2006Normalizzazione di Schemi Relazionali 39 Non sempre così facile Impiegato  Sede Progetto  Sede

06/06/2006Normalizzazione di Schemi Relazionali 40 Relazione nell’esempio soddisfa le dipendenze (non banali) D1: Impiegato  Sede D2: Progetto  Sede Osservazione: ciascun impiegato può partecipare a più progetti, ma tutti nella stessa sede

06/06/2006Normalizzazione di Schemi Relazionali 41 Decomponiamo sulla base delle dipendenze

06/06/2006Normalizzazione di Schemi Relazionali 42 Proviamo a ricostruire Diversa dalla relazione di partenza!

06/06/2006Normalizzazione di Schemi Relazionali 43 Cosa è accaduto? Ci sono tuple “spurie” perchè, per ogni impioegato, la sua sede si è “combinata” nel join con tutti i progetti di quella sede. C’è quindi perdita di informazione: a quali progetti partecipa realmente ciascun impiegato? Nel risultato del join se ne è persa traccia.

06/06/2006Normalizzazione di Schemi Relazionali 44 Proprietà delle relazioni decomposte Non si vuole perdita di informazione Una decomposizione in BCNF è valida se è senza perdita (di informazione), ossia se il join delle relazioni decomposte restituisce la relazione di partenza (senza aggiungere tuple spurie)

06/06/2006Normalizzazione di Schemi Relazionali 45 Formalizzazione Relazione r su un insieme di attributi X dove X = X1  X2 r1 ed r2 ottenute per proiezione da r su X1 e X2 r1 join r2 contiene in generale tutte le tuple di r, più eventualmente tuple "spurie". r si decompone senza perdita su X1 e X2 se r1 join r2 = r

06/06/2006Normalizzazione di Schemi Relazionali 46 Decomposizione senza perdita Una relazione r si decompone senza perdita su X 1 e X 2 se il join delle proiezioni di r su X 1 e X 2 è uguale a r stessa (cioè non contiene ennuple spurie) La decomposizione senza perdita è garantita se gli attributi comuni alle relazioni decomposte contengono una chiave per almeno una di esse

06/06/2006Normalizzazione di Schemi Relazionali 47 Osservazione Ciò avviene se gli attributi comuni costituiscono il primo membro di almeno una delle dipendenze su cui si effettua la decomposizione Nell'esempio: l'intersezione degli insiemi di attributi su cui sono effettuate le due proiezioni è costituita dall'attributo Sede che non è il primo membro di alcuna dipendenza funzionale

06/06/2006Normalizzazione di Schemi Relazionali 48 Proviamo a decomporre senza perdita Impiegato  Sede Progetto  Sede

06/06/2006Normalizzazione di Schemi Relazionali 49 Osservazione Abbiamo usato il buon senso, non il metodo usuale La decomposizione è soddisfacente, ma non è in BCNF

06/06/2006Normalizzazione di Schemi Relazionali 50 Un altro problema Supponiamo di voler inserire una nuova ennupla che specifica la partecipazione dell'impiegato Neri, che opera a Milano, al progetto Marte Impiegato  Sede Progetto  Sede

06/06/2006Normalizzazione di Schemi Relazionali 51

06/06/2006Normalizzazione di Schemi Relazionali 52

06/06/2006Normalizzazione di Schemi Relazionali 53 Conservazione delle dipendenze Una decomposizione conserva le dipendenze se ciascuna delle dipendenze funzionali dello schema originario coinvolge attributi che compaiono tutti insieme in uno degli schemi decomposti Progetto  Sede non è conservata

06/06/2006Normalizzazione di Schemi Relazionali 54 Qualità delle decomposizioni Una decomposizione dovrebbe sempre soddisfare: la decomposizione senza perdita, che garantisce la ricostruzione delle informazioni originarie la conservazione delle dipendenze, che garantisce il mantenimento dei vincoli di integrità originari

06/06/2006Normalizzazione di Schemi Relazionali 55 Una relazione non-normalizzata Progetto Sede  Dirigente Dirigente  Sede

06/06/2006Normalizzazione di Schemi Relazionali 56 La decomposizione è problematica Progetto Sede  Dirigente coinvolge tutti gli attributi e quindi nessuna decomposizione può preservare tale dipendenza quindi in alcuni casi la BCNF “non è raggiungibile”

06/06/2006Normalizzazione di Schemi Relazionali 57 Una nuova forma normale Una relazione r è in terza forma normale se, per ogni FD (non banale) X  Y definita su r, è verificata almeno una delle seguenti condizioni: X contiene una chiave K di r ogni attributo in Y è contenuto in almeno una chiave di r

06/06/2006Normalizzazione di Schemi Relazionali 58 BCNF e terza 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”

06/06/2006Normalizzazione di Schemi Relazionali 59 Decomposizione in terza forma normale si crea una relazione per ogni gruppo di attributi coinvolti in una dipendenza funzionale si verifica che alla fine una relazione contenga una chiave della relazione originaria Dipende dalle dipendenze individuate

06/06/2006Normalizzazione di Schemi Relazionali 60 Una possibile strategia se la relazione non è normalizzata si decompone in terza forma normale alla fine si verifica se lo schema ottenuto è anche in BCNF Se una relazione ha una sola chiave allora le due forme normali coincidono

06/06/2006Normalizzazione di Schemi Relazionali 61 Uno schema non decomponibile in BCNF Dirigente  Sede Progetto Sede  Dirigente

06/06/2006Normalizzazione di Schemi Relazionali 62 Una possibile riorganizzazione Dirigente  Sede Reparto Sede Reparto  Dirigente Progetto Sede  Reparto

06/06/2006Normalizzazione di Schemi Relazionali 63 Decomposizione in BCNF

06/06/2006Normalizzazione di Schemi Relazionali 64 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

06/06/2006Normalizzazione di Schemi Relazionali 65 Prodotto Nome prodotto Prezzo Nome fornitore Indirizzo Partita IVA Codice PartitaIVA  NomeFornitore Indirizzo

06/06/2006Normalizzazione di Schemi Relazionali 66 Analisi dell’entità L’entità viola la terza forma normale a causa della dipendenza: PartitaIVA  NomeFornitore Indirizzo Possiamo decomporre sulla base di questa dipendenza

06/06/2006Normalizzazione di Schemi Relazionali 67 Indirizzo Partita IVA Nome fornitore Nome prodotto Prezzo Codice Fornitura ProdottoFornitore (1,1) (0,N)

06/06/2006Normalizzazione di Schemi Relazionali 68 ProfessoreStudente Corso di laurea Tesi (0,N) (0,1) (0,N) Dipartimento (0,N) Studente  Corso di laurea Studente  Professore Professore  Dipartimento

06/06/2006Normalizzazione di Schemi Relazionali 69 Analisi della relationship La relationship viola la terza forma normale a causa della dipendenza: Professore  Dipartimento Possiamo decomporre sulla base di questa dipendenza

06/06/2006Normalizzazione di Schemi Relazionali 70 ProfessoreStudente Corso di laurea Tesi (0,N) (0,1) (0,N) Dipartimento Afferenza (1,1) (0,N)

06/06/2006Normalizzazione di Schemi Relazionali 71 Ulteriore analisi sulla base delle dipendenze La relationship Tesi è in BCNF sulla base delle dipendenze Studente  CorsoDiLaurea Studente  Professore le due proprietà sono indipendenti questo suggerisce una ulteriore decomposizione

06/06/2006Normalizzazione di Schemi Relazionali 72 ProfessoreStudente Tesi (0,N) (0,1) Dipartimento Afferenza (0,N) (1,1) Corso di laurea (0,N) Corso di laurea Iscrizione (0,N) (1,1)