Basi di Dati e Sistemi Informativi

Basi di Dati e Sistemi Informativi
Normalizzazione Home page del corso:

Progettazione logica Analisi dei requisiti e progettazione in dettaglio … Studio/analisi dei requisiti Risultati Fasi della progettazione SCHEMA CONCETTUALE Progettazione concettuale SCHEMA LOGICO Progettazione logica SCHEMA FISICO Progettazione fisica

Normalizzazione dei dati
Lo schema logico prodotto dalla progettazione dovrebbe rispettare dei requisiti di qualita’: Completezza  lo schema logico deve contenere tutti i concetti del diagramma E-R Correttezza  lo schema logico deve preservare la semantica del diagramma E-R Efficienza  lo schema logico non deve contenere ridondanze sui dati …

Le ridondanze sui dati possono essere di due tipi: Ridondanza concettuale  non ci sono duplicazioni dello stesso dato, ma sono memorizzate informazioni che possono essere ricavate da altre gia’ contenute nel DB. Ridondanza logica  esistono duplicazioni sui dati, che possono generare anomalie nelle operazioni sui dati …

Esempi di ridondanze concettuali che possono presentarsi gia’ nel diagramma E-R… ATTRIBUTI DERIVABILI Lordo Netto Tasse Lo stipendio netto si puo’ ricavare dal lordo e dalle tasse. STIPENDIO Il Numero Abitanti si puo’ ricavare contando le Persone Codice Fiscale Nome Codice Descrizione Numero Abitanti (1,1) RESIDENTI (1,N) PERSONA CITTA ANALISI DEI COSTI!

Le ridondanze sui dati possono essere di due tipi: Ridondanza concettuale  non ci sono duplicazioni dello stesso dato, ma sono memorizzate informazioni che possono essere ricavate da altre gia’ contenute nel DB. Ridondanza logica  esistono duplicazioni sui dati, che possono generare anomalie nelle operazioni sui dati …

Q. Cosa c’e’ di strano in questa tabella? Docente Livello Salario Dipartimento Direttore Corso Rossi 4 15000 Fisica Neri Mat. Discreta Chimica Rossini Analisi I Bianchi 3 10000 Informatica Viola Basi di Dati Programmazione Matematica Bruni Inf. di base Geometria

Q. Cosa c’e’ di strano in questa tabella? Docente Livello Salario Dipartimento Direttore Corso Rossi 4 15000 Fisica Neri Mat. Discreta Chimica Rossini Analisi I Bianchi 3 10000 Informatica Viola Basi di Dati Programmazione Matematica Bruni Inf. di base Geometria A. Lo stipendio di ciascun docente e’ ripetuto in tutte le tuple relative  Ridondanze sui dati!

Q. Cosa c’e’ di strano in questa tabella? Docente Livello Salario Dipartimento Direttore Corso Rossi 4 15000 Fisica Neri Mat. Discreta Chimica Rossini Analisi I Bianchi 3 10000 Informatica Viola Basi di Dati Programmazione Matematica Bruni Inf. di base Geometria A. Il direttore di un dipartimento e’ ripetuto in tutte le tuple relative  Ridondanze sui dati!

Q. Cosa c’e’ di strano in questa tabella? Docente Livello Salario Dipartimento Direttore Corso Rossi 4 15000 Fisica Neri Mat. Discreta Chimica Rossini Analisi I Bianchi 3 10000 Informatica Viola Basi di Dati Programmazione Matematica Bruni Inf. di base Geometria Anomalia di aggiornamento  se varia lo stipendio, devo modificare tutte le tuple del docente!

Q. Cosa c’e’ di strano in questa tabella? Docente Livello Salario Dipartimento Direttore Corso Rossi 4 15000 Fisica Neri Mat. Discreta Chimica Rossini Analisi I Bianchi 3 10000 Informatica Viola Basi di Dati Programmazione Matematica Bruni Inf. di base Geometria Anomalia di cancellazione  Se un docente non ha corsi, dobbiamo eliminare tutti i suoi dati …

Q. Cosa c’e’ di strano in questa tabella? Docente Livello Salario Dipartimento Direttore Corso Rossi 4 15000 Fisica Neri Mat. Discreta Chimica Rossini Analisi I Bianchi 3 10000 Informatica Viola Basi di Dati Programmazione Matematica Bruni Inf. di base Geometria Anomalia di inserimento  Non posso inserire un docente che non ha un corso associato …

Docente Livello Salario Dipartimento Direttore Corso V1. Ogni dipartimento ha un solo direttore. V2. Ogni docente ha un solo stipendio (anche se ha piu’ corsi). V3. Lo stipendio dipende dal livello e non dal dipartimento o dal corso tenuto! PROBLEMA: Abbiamo usato un’unica relazione per rappresentare informazioni eterogenee!

Da dove deriva una ridondanza? Traduzioni non corrette nel modello logico… Codice Cognome Salario Nome Sede PARTECIPAZIONE (0,N) (1,N) PERSONA PROGETTO PERSONA Codice NomeProgetto Cognome Salario SedeProgetto

Da dove deriva una ridondanza? Errori durante la progettazione concettuale .. Nome NomeComponente L’entita’ PRODOTTO contiene sia le informazioni sul prodotto sia quelle sulle sue componenti. PrezzoProdotto CollocazioneProdotto PRODOTTO TipoComponente Meglio ristrutturare lo schema E-R, partizionando l’entita’ ed introducendo delle relazioni uno-a-molti o molti-a-molti!

Per risolvere le anomalie viste fin qui, si introduce un nuovo vincolo di integrita’ sul modello relazionale: la Dipendenza Funzionale (DF). Data una relazione r su uno schema R(X) e due attributi Y e Z di X. Esiste la dipendenza funzionale Y Z se per ogni coppia di tuple t1 e t2 di r con t1[Y]=t2[Y], si ha anche che t1[Z]=t2[Z].

Impiegato Stipendio Progetto Sede Ruolo Rossi 20000 Marte Roma Tecnico Verdi 35000 Giove Bologna Venere Milano Progettista Neri 55000 Direttore Bianchi 48000 Consulente DF1: Impiegato  Stipendio Spiegazione: [Ogni impiegato ha un unico stipendio]

Impiegato Stipendio Progetto Sede Ruolo Rossi 20000 Marte Roma Tecnico Verdi 35000 Giove Bologna Venere Milano Progettista Neri 55000 Direttore Bianchi 48000 Consulente DF2: Progetto  Sede Spiegazione: [Ogni progetto ha un’unica sede]

Impiegato Stipendio Progetto Sede Ruolo Rossi 20000 Marte Roma Tecnico Verdi 35000 Giove Bologna Venere Milano Progettista Neri 55000 Direttore Bianchi 48000 Consulente DF3: Impiegato Progetto  Impiegato Spiegazione: ovvia! (ed inutile)

Impiegato Stipendio Progetto Sede Ruolo Rossi 20000 Marte Roma Tecnico Verdi 35000 Giove Bologna Venere Milano Progettista Neri 55000 Direttore Bianchi 48000 Consulente DF4: Impiegato Progetto  Ruolo Spiegazione: Un impiegato puo’ coprire un solo ruolo per progetto!

Le dipendenze funzionali sono definite a livello di schema e non a livello di istanza! Matricola Cognome Corso Voto 1244 Rossi Basi di Dati 18 1567 Bianchi Programmazione 22 1898 Analisi I 20 2040 Verdi 2121 2678 Bruni Dipendenza funzionale Corso  Voto? NO!

Le dipendenze funzionali sono definite a livello di schema e non a livello di istanza! Matricola Cognome Corso Docente Voto 1244 Rossi Basi di Dati Di Felice 18 1567 Bianchi Programmazione Messina 22 1898 Analisi I Sordoni 20 2040 Verdi 2121 2678 Bruni Dipendenza funzionale Corso  Docente ? Puo’ essere, occorre considerare le specifiche del sistema …

Le dipendenze funzionali hanno sempre un verso! Matricola Cognome Corso Docente Voto 1244 Rossi Basi di Dati Di Felice 18 1567 Bianchi Programmazione Messina 22 1898 Analisi I Sordoni 20 2040 Verdi 2121 2678 Bruni 4354 LAM 28 Corso  Docente? OK Docente  Corso? NO!

Le dipendenze funzionali sono una generalizzazione del vincolo di chiave. Data una relazione r con schema R(X), con chiave K. Esiste un vincolo di dipendenza funzionale tra K e qualsiasi attributo dello schema r. Q. Che accade se K e’ una superchiave?

Impiegato Stipendio Progetto Sede Ruolo ESEMPIO. Impiegato,Progetto e’ una chiave della relazione  non possono esistere due tuple con lo stesso valore della coppia <Impiegato, Progetto>! DF1: Impiegato Progetto  Stipendio DF2: Impiegato Progetto  Sede DF3: Impiegato Progetto  Ruolo DF4: Impiegato Progetto  Sede Ruolo …. DFn: Impiegato Progetto  Impiegato Stipendio Progetto Sede Ruolo

Impiegato Stipendio Progetto Sede Ruolo Rossi 20000 Marte Roma Tecnico Verdi 35000 Giove Bologna Venere Milano Progettista Neri 55000 Direttore Bianchi 48000 Consulente DF1: Impiegato  Stipendio DF2: Progetto  Sede DF3: Impiegato Progetto  Sede

Dipendenze funzionali “ buone” e “cattive”. DF1: Impiegato  Stipendio DF2: Progetto  Sede Ridondanza sui dati, possibili anomalie (aggiornamento, cancellazione, etc) nelle operazioni sui dati … DF3: Impiegato Progetto  Ruolo Non determina ridondanze sui dati …

Perche’ DF3 non causa anomalie a differenza di DF1 e di DF2? DF1: Impiegato  Stipendio DF2: Progetto  Sede DF3: Impiegato Progetto  Ruolo Motivo: DF3 ha sulla sinistra una (super)chiave. DF1 e DF2 non contengono una (super)chiave.

FORMA NORMALE di BOYCE-CODD (FNBC) Uno schema R(X) si dice in forma normale di Boyce e Codd se per ogni dipendenza funzionale (non ovvia) Y Z definita su di esso, Y e’ una superchiave di R(X). Se una relazione e’ in FNBC, non presenta le anomalie e ridondanze viste fin qui. Se una relazione NON e’ in FNBC, bisogna trasformarla (normalizzarla) -se possibile- in FNBC.

Esempi di relazioni… Localita Stato Abitanti Roma Italia Cambridge UK 50000 US 200000 Bologna 400000 NY Localita Stato Prefisso Roma Italia 0039 Cambridge US 001 UK 0044 Bologna NY DF: Localita Stato  Abitanti Rispetta la FNBC! DF: Stato  Prefisso NON rispetta la FNBC!

Esempi di relazioni… Localita Stato Abitanti Roma Italia Cambridge UK 50000 US 200000 Bologna 400000 NY Localita Stato Prefisso Roma Italia 0039 Madrid Spagna 0034 Cambridge UK 0044 Parigi Francia 0033 NY US 001 DF: Localita Stato  Abitanti Rispetta la FNBC! DF: Stato  Prefisso NON rispetta la FNBC!

Q. Come normalizzare una relazione? A. Creare tabelle separate per ogni dipendenza funzionale, ognuna in FNBC! IMPIEGATO, PROGETTO  RUOLO Impiegato Progetto Ruolo Rossi Marte Tecnico Verdi Giove Venere Progettista Neri Direttore Bianchi Consulente IMPIEGATO STIPENDIO Impiegato Stipendio Rossi 20000 Verdi 35000 Neri 55000 Bianchi 48000 PROGETTO  SEDE Progetto Sede Marte Roma Giove Bologna Venere Milano

Q. Tutte le decomposizioni vanno bene? IMPIEGATO SEDE Impiegato Progetto Sede Rossi Marte Roma Verdi Giove Milano Venere Neri Saturno Impiegato Sede Rossi Roma Verdi Milano Neri PROGETTO SEDE Progetto Sede Marte Roma Giove Milano Venere Saturno DF1. Impiegato  Sede (Ogni impiegato lavora in una sola sede) DF2. Progetto  Sede (Ogni progetto ha la stessa sede)

Q. Tutte le decomposizioni vanno bene? Impiegato Sede Rossi Roma Verdi Milano Neri Progetto Sede Marte Roma Giove Milano Venere Saturno Impiegato Progetto Sede Rossi Marte Roma Verdi Giove Milano Venere Saturno Neri = Se combino le due relazioni della decomposizione tramite operatore di join, non ottengo la relazione di partenza! (decomposizione con perdita) TUPLE SPURIE

DECOMPOSIZIONE SENZA PERDITA Uno schema R(X) si decompone senza perdita negli schemi R1(X1) ed R2(X2) se, per ogni possibile istanza r di R(X), il join naturale delle proiezioni di r su X1 ed X2 produce la relazione r di partenza. In caso di decomposizione con perdite, possono generarsi delle tuple spurie dopo il join.

Sia r una relazione con schema R(X) e siano X1 ed X2 sottoinsiemi di R(X) con Sia inoltre X0 un attributo comune di X1 ed X2. La relazione r si decompone senza perdita negli schemi R(X1) ed R(X2) se soddisfa una delle due dipendenze funzionali: X0  X1 o X0  X2. (In pratica, X0 e’ una superchiave di X1 o di X2)

Anche se una decomposizione e’ senza perdite, puo’ comunque presentare dei problemi di conservazione delle dipendenze … Impiegato Progetto Rossi Marte Verdi Giove Venere Neri Saturno Impiegato Progetto Sede Rossi Marte Roma Verdi Giove Milano Venere Neri Saturno IMPIEGATO SEDE Impiegato Sede Rossi Roma Verdi Milano Neri Con questa decomposizione, non ho tuple spurie …

Anche se una decomposizione e’ senza perdite, puo’ comunque presentare dei problemi di conservazione delle dipendenze … Impiegato Progetto Rossi Marte Verdi Giove Venere Neri Saturno IMPIEGATO SEDE Impiegato Sede Rossi Roma Verdi Milano Neri Che accade se aggiungo l’impiegato Neri al progetto Marte?

Q. Tutte le decomposizioni vanno bene? IMPIEGATO SEDE Impiegato Sede Rossi Roma Verdi Milano Neri Impiegato Progetto Rossi Marte Verdi Giove Venere Neri Saturno Impiegato Progetto Sede Rossi Marte Roma Verdi Giove Milano Venere Neri Saturno = Violazione del vincolo di dipendenza Progetto  Sede

REGOLA PRATICA: Per conservare le dipendenze in una decomposizione, ogni dipendenza funzionale dello schema dovrebbe coinvolgere attributi che compaiono tutti insieme in uno degli schemi decomposto … r1 r2 Impiegato Sede Impiegato Progetto DF1: IMPIEGATO  SEDE, OK, Compare nella prima relazione DF2: PROGETTO  SEDE, Non compare in nessuna relazione

Q. Tutte le decomposizioni vanno bene? NO! Le decomposizione dovrebbero sempre soddisfare tre proprieta’: Soddisfacimento della FNBC: ogni relazione prodotta deve essere in FNBC. Decomposizione senza perdita: il join delle relazioni decomposte deve produrre la relazione originaria. Conservazione delle dipendenze: il join delle relazioni decomposte deve rispettare tutte le DF originarie.

Q. Data una relazione non in FNBC, e’ sempre possibile ottenere una decomposizione in FNBC? A. NO! consideriamo un controesempio … Dirigente Progetto Sede Rossi Marte Roma Verdi Giove Milano Neri Saturno Venere DF1. Progetto Sede  Dirigente DF2. Dirigente  Sede PROBLEMA: DF1 coinvolge tutti gli attributi, nessuna decomposizione puo’ preservare la dipendenza!

Per risolvere casi come quello precedente, si introduce una nuova definizione di forma normale meno restrittiva della forma di Boyce e Codd… TERZA FORMA NORMALE (TFN) Una relazione r e’ in terza forma normale se per ogni dipendenza funzionale XA dello schema, almeno una delle seguenti condizioni e’ verificata: X contiene una chiave K di r A appartiene ad almeno una chiave K di r

La relazione considerata fin qui rispetta la TFN! DF1. Progetto Sede  Dirigente DF2. Dirigente  Sede DF1: Progetto Sede e’ una chiave  Condizione 1 soddisfatta! DF2: Sede e’ parte di una chiave  Condizione 2 soddisfatta! Dirigente Progetto Sede Rossi Marte Roma Verdi Giove Milano Neri Saturno Venere Se e’ gia’ in TFN, non e’ necessaria alcuna nomalizzazione! Putroppo le ridondanze sui dati restano …

CONFRONTO TRA TFN e FNBC (SVANTAGGI) La TFN e’ meno restrittiva della FNBC Tollera alcune ridondanze ed anomalie sui dati. Certifica meno lo qualita’ dello schema ottenuto. (VANTAGGI) La TFN e’ sempre ottenibile, qualsiasi sia lo schema di partenza. COME? Algoritmo di normalizzazione in TFN!

ALGORITMO DI NORMALIZZAZIONE IN TERZA FORMA NORMALE (TFN)

TERZA FORMA NORMALE (TFN) Una relazione r e’ in terza forma normale se per ogni dipendenza funzionale XA (non banale) dello schema, almeno una delle seguenti condizioni e’ verificata: X contiene una chiave K di r (X e’ una superchiave di r) A appartiene ad almeno una chiave K di r

DIPENDENZA FUNZIONALE BANALE Una dipendenza funzionale XY e’ banale se Y e’ contenuto in X. ESEMPI: Impiegato Progetto  Impiegato Impiegato Progetto Sede  Impiegato Progetto Questo genere di dipendenze funzionali non ci interessano, e non le conseriamo come tali nel resto della trattazione …

Data una relazione r con schema R(X) non in TFN, normalizzare in TFN vuol dire: decomporre r nelle relazioni r1,r2, … rn, garantendo che: Ogni ri (1<=i<=n) e’ in TFN. La decomposizione e’ senza perdite. La decomposizione conserva tutte le dipendenze F definite sullo schema R(X) di partenza.

Ad esempio, data la relazione: R(MGCRDSPA), con dipendenze funzionali: F= {MRSDG, MS  CD, G R, DS, SD, MPDAM} Qual e’ la sua decomposizione in 3FN? In molti casi, la decomposizione non e’ intuitiva …

IDEE alla base dell’algoritmo di normalizzazione: Semplificare l’insieme di dipendenze F, rimuovendo quelle non necessarie, e trasformando ogni dipendenza in modo che nella parte destra compaia un singolo attributo. Raggruppare gli attributi coinvolti nelle stesse dipendenze, e costruire le relazioni corrispondenti. Assicurarsi che almeno una delle relazioni prodotte contenga la chiave della relazione originaria.

IDEE alla base dell’algoritmo di normalizzazione: Semplificare l’insieme di dipendenze F, rimuovendo quelle non necessarie, e trasformando ogni dipendenza in modo che nella parte destra compaia un singolo attributo. Raggruppare gli attributi coinvolti nelle stesse dipendenze, e costruire le relazioni corrispondenti. Assicurarsi che almeno una delle relazioni prodotte contenga la chiave della relazione originaria. NECESSARIO INTRODURRE DEFINIZIONI FORMALI PER CHIARIRE LE FRASI IN ROSSO …

IMPLICAZIONE FUNZIONALE Dato un insieme di dipendenze funzionali F, ed una dipendenza funzionale f, diremo che F implica f se ogni relazione r che soddisfa F soddisfa anche f. F: {Impiegato  Livello, Livello  Stipendio} f: Impiegato  Stipendio In questo caso, F implica f? SI! Dim. Devo dimostrare che se in una relazione r sono vere entrambe le dipendenze funzionali di F, allora vale anche la dipendenza funzionale f…

IMPLICAZIONE FUNZIONALE Dato un insieme di dipendenze funzionali F, ed una dipendenza funzionale f, diremo che F implica f se ogni relazione r che soddisfa F soddisfa anche f. F: {Impiegato  Livello, Impiegato  Stipendio} f: Livello  Stipendio In questo caso, F implica f? NO! Impiegato Livello Stipendio Neri 4 13400 Rossi 15000

Q. Come verificare se F implica f? CHIUSURA DI UNA DIPENDENZA FUNZIONALE Dato uno schema R(U), con un insieme di dipendenze F. Sia X un insieme di attributi contenuti in U. Si definisce la chiusura di X rispetto ad F (X+F) come l’insieme degli attributi che dipendono funzionalmente da X:

Esempio (facile). Siano: R=(ABCDE) F={A B, A  C} Vogliamo conoscere la chiusura di A: A+F A+F={B,C}

Esempio (facile). Siano: R=(ABCDE) F={A B, A  C, C D} Vogliamo conoscere la chiusura di A: A+F A+F={B,C,D}

INPUT: X (attributi) e F (dipendenze) OUTPUT: La chiusura di X rispetto ad F: X+F 1) X+F=X. 2) Per ogni dipendenza f: YA in F 3) Ripeti il passo 2 finche’ non e’ possibile aggiungere nuovi elementi in X+F.

Esempio. Siano: R=(ABCDE) F={A B, BCD, BE, EC} A+F={A} A+F={A,B} // con f: AB A+F={A,B,E} // con f: BE A+F={A,B,E,C} // con f: EC A+F={A,B,E,C,D} // con f: BCD

Q. Come verificare se F implica f: XA? Calcolare la chiusura X+F Se A appartiene ad X+F, allora F implica f. ESEMPIO F={A B, BCD, BE, EC} f: A E A+F={A,B,E,C,D} …. Quindi F implica A E

Data una relazione r con schema R(U), l’algoritmo per determinare la chiusura X+F puo’ essere usato anche per verificare se X e’ una chiave di r. …COME? Dato uno schema R(U), con un insieme F di dipendenze funzionali, allora: un insieme di attributi K e’ una (super)chiave di R(U) se F implica KU.

Dato uno schema R(U), con un insieme F di dipendenze funzionali, allora: un insieme di attributi K e’ una (super)chiave di R(U) se F implica KU. ESEMPIO R=(ABCDE) F={A B, BCD, BE, EC} Se A e’ una chiave allora F implica A  ABCDE. A+F={A,B,E,C,D} quindi A e’ una chiave!

INSIEMI DI DIPENDENZE EQUIVALENTI Dati due insiemi di dipendenze funzionali F1 ed F2, essi si dicono equivalenti se F1 implica ciascuna dipendenza di F2 e viceversa. ESEMPIO F={A B, AB  C} F1={AB, AC} F e F1 sono equivalenti! Occorre fare 4 verifiche …

INSIEMI DI DIPENDENZE NON RIDONDANTI Dato un insieme di dipendenze funzionali F definito su uno schema R(U), esso si dice non ridondante se non esiste una dipendenza f di F tale che F-{f} implica f. ESEMPIO F={A B, AB  C, AC} F e’ ridondante perche’: F-{AC} implica AC!

INSIEMI DI DIPENDENZE RIDOTTE Dato un insieme di dipendenze funzionali F definito su uno schema R(U), esso si dice ridotto se(1) non e’ ridondante, e (2) non e’ possibile ottenere un insieme F’ equivalente ad F eliminando attributi dai primi membri di una o piu’ dipendenze di F. ESEMPIO F={A B, AB  C} F NON e’ ridotto perche’ B puo’ essere eliminato da ABC e si ottiene ancora un insieme F2 equivalente ad F!

Dato uno schema R(U) con insieme di dipendenze F, per trovare una copertura ridotta di F si procede in tre passi: Sostituire F con F1, che ha tutti i secondi membri composti da un singolo attributo. MRSDG, MS  CD, G R, DS, SD, MPDAM F1={ MR, MS, MD, MG, MS  C, MS D, GR, DS, SD, MPD A, MPD  M }

STEP 2. Eliminare gli attributi estranei. Supponiamo di avere F={AB C, AB}, e calcoliamo A+F A+F=A A+F=AB // da A B A+F=ABC // da AB  C C dipende solo da A, quindi l’attributo B in ABC puo’ essere eliminato preservando l’uguaglianza! F1={AC, A  B}

STEP 2. Eliminare gli attributi estranei. Q. In generale, se ho una dipendenza funzionale del tipo: AX  B, come faccio a stabilire se l’attributo A puo’ essere eliminato preservando l’uguaglianza? A. Si calcola X+ e si verifica se esso include B, nel qual caso A puo’ essere eliminato dalla dipendenza!

STEP 3. Eliminare le ridondanze non necessarie. Supponiamo di avere F={B C, BA, CA}: BA e’ ridondante, in quanto bastano le relazioni BC, e C A per capire che A dipende da B! Formalmente, dovrei dimostrare che: F-{BA} implica {BA} quindi, verificare che: B+F-{BA} contiene A …

STEP 3. Eliminare le ridondanze non necessarie. Q. In generale, come posso stabilire se la dipendenza del tipo XA e’ ridondante? A. Si elimina da F, si calcola X+F-{XA}, e si verifica se tale insieme include ancora A. Nel caso lo includa, si elimina la dipendenza funzionale XA.

Dati R(U), ed un insieme di dipendenze F, l’algoritmo di normalizzazione in terza forma normale procede come segue: STEP 1. Costruire una copertura ridotta F1 di F. F={MRSDG, MS  CD, G R, DS, SD, MPDAM} F1={MD, MG, M C, GR, DS, SD, MPA}

STEP 2. Decomporre F1 nei sottoinsiemi F1(1), F1(2), … F1(n), tali che ad ogni sottoinsieme appartengano dipendenze con gli stessi lati sinistri. F1(1)={MD, M G, MC} F1(2)={GR} F1(3)={DS} F1(4)={SD} F1(5)={MPA}

STEP 3. Se due o piu’ lati sinistri delle dipendenze si implicano a vincenda, si fondono i relativi insiemi. F1(1)={MD, M G, MC} F1(2)={GR} F1(3)={DS} F1(3)={DS, SD} F1(4)={SD} F1(5)={MPA}

STEP 4. Trasformare ciascun F1(i) in una relazione R(i) con gli attributi contenuti in ciascuna dipendenza. Il lato sinistro diventa la chiave della relazione. F1(1)={MD, M G, MC}: R(1)(MDGC) F1(2)={GR}: R(2)(GR) F1(3)={DS, SD}: R(3)(SD) F1(4)={MPA}: R(4)(MPA)

STEP 5. Se nessuna relazione R(i) cosi’ ottenuta contiene una chiave K di R(U), inserire una nuova relazione R(n+1) contenente gli attributi della chiave. Nel nostro caso, la chiave e’ costituita da: (MP). R(1)(MDGC) R(2)(GR) R(3)(SD) R(4)(MPA) R(4)(MPA) contiene la chiave  non c’e’ necessita’ di aggiungere altre relazioni!

In conclusione, data la relazione: R(MGCRDSPA), con dipendenze funzionali: F= {MRSDG, MS  CD, G R, DS, SD, MPDAM} La sua decomposizione in 3FN e’ la seguente: R(1)(MDGC) R(2)(GR) R(3)(SD) R(4)(MPA)

Esempio: R(ABCDE) F={CAB, BC DE, DB} STEP (1.a) Ridurre F. (semplificare parte destra delle dipendenze) F1={CA, CB, BCD, BCE, DB} STEP (1.b) Ridurre F. (semplificare parte sinistra delle dipendenze) Calcolo C+F1 ={C,A,B, D, E}, e noto che include B! F2={CA, CB, CD, CE, DB}

F2={CA, CB, CD, CE, DB} STEP (1.c) Ridurre F. (rimuovere dipendenze) Che succede se elimino C B? F3={CA, CD, CE, DB} STEP (2) Decomporre F (in insiemi di dipendenze con lo stesso lato sx) F31={CA, CD, CE} F32={DB}

F31={CA, CD, CE} F32={DB} STEP (3) Fondere gli insiemi. (le cui parti sinistre si implicano) STEP (4) Costruire le relazioni associate. R1(CADE) R2(DB} STEP (5) Verificare esistenza della chiave. C+={A,B,C,D,E}  quindi C e’ una chiave dello schema r

Perche’ si chiama Terza Forma Normale (TFN)? Prima Forma Normale (PFN)  ovvia,si suppone sempre rispettata Seconda Forma Normale (SFN)  variante debole della TFN. Procenendo per gradi, si dovrebbe normalizzare in PFN, poi in SFN, e quindi in TFN.

Una relazione r con schema R(U) e’ in Prima Forma Normale (PFN) quando rispetta i requisiti del modello relazionale, ossia ogni attributo e’ elementare, e non ci sono righe/colonne ripetute. Esempi di relazioni non in PFN: PAZIENTE (Nome, Cognome, Recapito(Via, Citta, CAP)) PAZIENTE(Nome, Nome, Cognome)

Perche’ si chiama Terza Forma Normale (TFN)? Prima Forma Normale (PFN)  ovvia,si suppone sempre rispettata Seconda Forma Normale (SFN)  variante debole della TFN. Procenendo per gradi, si dovrebbe normalizzare in PFN, poi in SFN, e quindi in TFN.

Una relazione r con schema R(U) e’ in Seconda Forma Normale (SFN) quando non presenta dipendenze parziali, della forma: Y A, dove: Y e’ un sottoinsieme proprio della chiave A e’ un qualsiasi sottoinsieme di R(U) IMPIEGATO(Impiegato, Categoria, Stipendio) Impiegato  Categoria Categoria  Stipendio IN SFN MA NON IN TFN!

Una relazione r con schema R(U) e’ in Seconda Forma Normale (SFN) quando non presenta dipendenze parziali, della forma: Y A, dove: Y e’ un sottoinsieme proprio della chiave A e’ un qualsiasi sottoinsieme di R(U) IMPIEGATO(Impiegato, Stipendio, Progetto, Budget) Impiegato  Stipendio Progetto  Budget DIPENDENZA PARZIALE! Non in SFN Non in TFN

Basi di Dati e Sistemi Informativi

Presentazioni simili

Presentazione sul tema: "Basi di Dati e Sistemi Informativi"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back

Entrare

Autorizzarsi attraverso i social network:

Basi di Dati e Sistemi Informativi

Presentazioni simili

Presentazione sul tema: "Basi di Dati e Sistemi Informativi"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back