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

Presentazione sul tema: "S. Costantini 06/05/2006 (parte del materiale è tratto da slide del 2001 di Ceri-Atzeni) Normalizzazione di Schemi."— Transcript della presentazione:

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

2 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

3 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

4 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

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

6 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

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

8 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)

9 06/06/2006Normalizzazione di Schemi Relazionali 9 Come eliminare le anomalie? Mediante un procedimento di normalizzazione Ossia, trasformando una tabella non in forma normale in un’insieme di tabelle in forma normale Forme Normali: Boyce-Codd Normal Form (BCNF) Terza Forma Normale (in subordine)

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

11 06/06/2006Normalizzazione di Schemi Relazionali 11 Normalizzazione: Definizione Intuitiva Occorre separare le informazioni eterogenee in sottoinsiemi omogenei. Ciascun sottoinsieme individuato deve rappresentare un ben preciso concetto. I concetti individuati corrispondono ad un insieme di attributi che nel suo interno ha una potenziale chiave. Dopo aver individuato i concetti rilevanti, la tabella data può essere decomposta in altrettante tabelle separate.

12 06/06/2006Normalizzazione di Schemi Relazionali 12 Per studiare in maniera sistematica come individuare e separare i concetti, è necessario introdurre come strumento un vincolo di integrità: la dipendenza funzionale

13 06/06/2006Normalizzazione di Schemi Relazionali 13 Proprietà dell’esempio considerato 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29 06/06/2006Normalizzazione di Schemi Relazionali 29 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 sola funzione“ non genera ridondanze e anomalie Questo proprio perché Impiegato Progetto è una superchiave

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

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

32 06/06/2006Normalizzazione di Schemi Relazionali 32 Cosa fare 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

33 06/06/2006Normalizzazione di Schemi Relazionali 33

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

35 06/06/2006Normalizzazione di Schemi Relazionali 35 Caso favorevole della normalizzazione si decompone r in tante relazioni quante sono le dipendenze funzionali significative (non banali) con diverso primo membro Le relazioni risultanti sono in BCNF Le proprietà P1 (decomposizione senza perdita) e P2 (conservazione delle dipendenze) sono mantenute.

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

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

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

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

40 06/06/2006Normalizzazione di Schemi Relazionali 40 Decomposizione in BCNF R2 Categoria Stipendio 3 30 4 50 5 72

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

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

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

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

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

46 06/06/2006Normalizzazione di Schemi Relazionali 46 Cosa è accaduto? Ci sono tuple “spurie” perchè, per ogni impiegato, 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.

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

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

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

50 06/06/2006Normalizzazione di Schemi Relazionali 50 Condizione sufficiente per la Decomposizione senza Perdita relazione r sugli attributi ABC proiezioni r1 su AB e r2 su AC. sia A  C Allora, A è chiave per la proiezione r2 su AC  non ci sono in r2 due tuple diverse con gli stessi valori su A  decomposizione senza perdita

51 06/06/2006Normalizzazione di Schemi Relazionali 51 Perchè la condizione data è sufficiente? generica tupla t in r1 join r2 t = (a,b,c) è ottenuta da t1 = (a,b)  r1 e t2 = (a,c)  r2 in r, A  C, dunque esiste un solo valore per C in r associato al valore a dell’attributo A (a,c) compare in r2, dunque tale valore è proprio c (a,b) compare in r1, dunque il valore a può essere associato in r al valore b Si conclude che t = (a,b,c) )  r e quindi r è senza perdita

52 06/06/2006Normalizzazione di Schemi Relazionali 52 Osservazione La condizione sufficiente data è verificata 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, quindi la condizione non è verificata

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

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

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

56 06/06/2006Normalizzazione di Schemi Relazionali 56

57 06/06/2006Normalizzazione di Schemi Relazionali 57

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

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

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

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

62 06/06/2006Normalizzazione di Schemi Relazionali 62 Una nuova forma normale Una relazione r è in terza forma normale (3NF) 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

63 06/06/2006Normalizzazione di Schemi Relazionali 63 Esempio 3NF Telefoni(Prefisso,Numero, Località,Nome,Ind) Chiave Prefisso Numero Altra chiave Località Numero Dipendenze Prefisso Numero  Nome Prefisso Numero  Località Prefisso Numero  Ind

64 06/06/2006Normalizzazione di Schemi Relazionali 64 Esempio Con queste dipendenze, la relazione è in 3NF Ridondanza: i prefissi sono ripetuti

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

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

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

68 06/06/2006Normalizzazione di Schemi Relazionali 68 Strategia Alternativa Riorganizzare la relazione data aggiungendo attributi Obiettivo: renderla decomponibile in BCNF Metodo: i nuovi attributi creano nuove dipendenze funzionali che soddisfano la condizione sufficiente La decomposizione senza perdita è così garantita La conservazione delle dipendenze segue in modo ovvio decomponendo sulle dipendenze stesse

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

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

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

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

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

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

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

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

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

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

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

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