La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Forma normale di Boyce e Codd Definizione. 2 Le DF di Dipartimento ImpiegatoStipendioProgettoBilancioFunzione Rossi20Marte2tecnico Verdi35Giove15progettista.

Presentazioni simili


Presentazione sul tema: "Forma normale di Boyce e Codd Definizione. 2 Le DF di Dipartimento ImpiegatoStipendioProgettoBilancioFunzione Rossi20Marte2tecnico Verdi35Giove15progettista."— Transcript della presentazione:

1 Forma normale di Boyce e Codd Definizione

2 2 Le DF di Dipartimento ImpiegatoStipendioProgettoBilancioFunzione Rossi20Marte2tecnico Verdi35Giove15progettista Verdi35Venere15progettista Neri55Venere15direttore Neri55Giove15consulente Neri55Marte2consulente Mori48Marte2direttore Mori48Venere15progettista Bianchi48Venere15progettista Bianchi48Giove15direttore Impiegato Stipendio Progetto Bilancio Impiegato Progetto Funzione

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

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

5 5 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 Linserimento è possibile anche attribuendo valori nulli agli attributi diversi da Impiegato e Progetto

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

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

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

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

10 10 Un esempio di normalizzazione ImpiegatoProgettoFunzione RossiMartetecnico ImpiegatoStipendioVerdiGioveprogettista Rossi20VerdiVenereprogettistaProgettoBilancio Verdi35NeriVeneredirettoreMarte2 Neri55NeriGioveconsulenteGiove15 Mori48NeriMarteconsulenteVenere15 Bianchi48MoriMartedirettore MoriVenereprogettista BianchiVenereprogettista BianchiGiovedirettore

11 11 Non sempre così facile ImpiegatoProgettoSede RossiMarteRoma VerdiGioveMilano VerdiVenereMilano NeriSaturnoMilano NeriVenereMilano ImpiegatoSedeProgettoSede RossiRomaMarteRoma VerdiMilanoGioveMilano NeriMilanoSaturnoMilano VenereMilano Impiegato Sede Progetto Sede

12 12 Proviamo a ricostruire ImpiegatoSedeProgettoSede RossiRomaMarteRoma VerdiMilanoGioveMilano NeriMilanoSaturnoMilano VenereMilano ImpiegatoProgettoSede RossiMarteRoma VerdiGioveMilano VerdiSaturnoMilano VerdiVenereMilano NeriGioveMilano NeriSaturnoMilano NeriVenereMilano Diversa dalla relazione di partenza!

13 13 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 R 1 (X 1 ) e R 2 (X 2 ) se, per ogni istanza legale r su R(X), il join naturale delle proiezioni di r su X 1 e X 2 è uguale a r stessa X 1 (r) X 2 (r) = r

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

15 15 Decomposizione senza perdita ImpiegatoProgettoSede RossiMarteRoma VerdiGioveMilano VerdiVenereMilano NeriSaturnoMilano NeriVenereMilano ImpiegatoSedeImpiegatoProgetto RossiRomaRossiMarte VerdiMilanoVerdiGiove NeriMilanoVerdiVenere NeriSaturno NeriVenere

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

17 17 Un altro problema (2/3) ImpiegatoSedeImpiegatoProgetto RossiRomaRossiMarte VerdiMilanoVerdiGiove NeriMilanoVerdiVenere NeriSaturno NeriVenere NeriMarte

18 18 Un altro problema (3/3) Proviamo a ricostruire ImpiegatoProgettoSede RossiMarteRoma VerdiGioveMilano VerdiVenereMilano NeriSaturnoMilano NeriVenereMilano NeriMarteMilano La dipendenza Progetto Sede non è preservata

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

20 20 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 Nellesempio 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

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

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

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

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

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

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

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

28 28 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 linformazione sul prefisso viene replicata per ogni abbonato PrefissoNumeroLocalit à AbbonatoIndirizzo BolognaRossiVia Roma ModenaVerdiVia Bari BolognaBianchiVia Napoli CastenasoNeriPiazza Borsa VignolaMoriVia Piave 65

29 29 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 NumeroLocalit à AbbonatoIndirizzoPrefissoLocalit à BolognaRossiVia Roma 8051Bologna ModenaVerdiVia Bari 16059Modena BolognaBianchiVia Napoli 77051Castenaso CastenasoNeriPiazza Borsa 12059Vignola VignolaMoriVia Piave 65

30 30Osservazioni 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 lattività 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

31 31Osservazioni Lapproccio 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

32 32 Decomposizione in 3NF Lidea alla base dellalgoritmo 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: R 1 (ABCDE), R 2 (CF), R 3 (FG)

33 33 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 R 1 (ABC), R 2 (CD) Decomposizione in 3NF

34 34 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 R 1 (AC), R 2 (BD), R 3 (AB) Decomposizione in 3NF

35 35 Una limitazione non superabile DirigenteProgettoSede RossiMarteRoma VerdiGioveMilano VerdiMarteMilano NeriSaturnoMilano NeriVenereMilano Progetto Sede Dirigente Dirigente Sede

36 36 Una limitazione non superabile Nellesempio 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

37 37 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 lapplicazione 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

38 38 BCNF e 3 a 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

39 39 Uno schema non in BCNF DirigenteProgettoSede RossiMarteRoma VerdiGioveMilano VerdiMarteMilano NeriSaturnoMilano NeriVenereMilano Progetto Sede Dirigente Dirigente Sede

40 40 Una possibile riorganizzazione DirigenteProgettoSedeReparto RossiMarteRoma 1 VerdiGioveMilano 1 VerdiMarteMilano 1 NeriSaturnoMilano 2 NeriVenereMilano 2 Dirigente Sede Reparto Sede Reparto Dirigente Progetto Sede Reparto

41 41 Decomposizione in BCNF ProgettoSedeReparto DirigenteSedeRepartoMarteRoma1 RossiRoma1GioveMilano1 VerdiMilano1MarteMilano1 NeriMilano2SaturnoMilano2 VenereMilano2

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

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

44 44 Analisi dellentità Lentità viola la terza forma normale a causa della dipendenza: PartitaIVA NomeFornitore Indirizzo Possiamo decomporre sulla base di questa dipendenza

45 45Decomposizione Indirizzo Partita IVA Nome fornitore Nome prodotto Prezzo Codice Fornitura ProdottoFornitore (1,1)(0,N)

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

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

48 48Decomposizione Afferenza (1,1) (0,N) ProfessoreStudente Corso di laurea (0,N)(0,1) (0,N) Dipartimento Tesi

49 49 Ulteriore analisi sulla base delle dipendenze Lassociazione Tesi in BCNF sulla base delle dipendenze Studente CorsoDiLaurea Studente Professore Le due proprietà sono indipendenti Questo suggerisce una ulteriore decomposizione

50 50 Ulteriore decomposizione Afferenza (1,1) (0,N) ProfessoreStudente Corso di laurea (0,N)(0,1) Dipartimento Tesi Iscrizione (1,1) (0,N)

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

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

53 53Riferimenti 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


Scaricare ppt "Forma normale di Boyce e Codd Definizione. 2 Le DF di Dipartimento ImpiegatoStipendioProgettoBilancioFunzione Rossi20Marte2tecnico Verdi35Giove15progettista."

Presentazioni simili


Annunci Google