1 / 22

Il raffinamento dello schema e la normalizzazione nei database relazionali

Il raffinamento dello schema e la normalizzazione nei database relazionali. Eugenio Di Sciascio. Introduzione . La modellazione E-R ci ha consentito di descrivere schemi relazionali Lo strumento base per la modellizzazione è stato finora “la ragionevolezza”

garin
Télécharger la présentation

Il raffinamento dello schema e la normalizzazione nei database relazionali

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Il raffinamento dello schema e la normalizzazione nei database relazionali Eugenio Di Sciascio

  2. Introduzione • La modellazione E-R ci ha consentito di descrivere schemi relazionali • Lo strumento base per la modellizzazione è stato finora “la ragionevolezza” • Esistono però metodi formali per assicurare la scelta di “buoni” schemi relazionali. • Tali metodi verranno essenzialmente utilizzati per verificare e raffinare lo schema.

  3. Linee guida informali • Scelta degli attributi: • Progettare lo schema in modo che sia semplice descrivere il suo significato, prestare cioè attenzione alla semantica degli attributi. • Evitare di riunire in uno schema di relazione attributi propri di entità diverse del mondo reale.

  4. Linee guida informali (2) • Ridurre la ridondanza: • Ha un duplice scopo: ridurre la “storage area” e evitare le anomalie da aggiornamento • Anomalie da aggiornamento: • Anomalie da inserimento • Anomalie da modifica • Anomalie da cancellazione

  5. DipNome Dir_dip Data_ino Impiegato_dipartimento Nome Cognome CF Data_n indirizzo Stip_annuo Superio_id Id_dip Linee guida informali (3) • Anomalie da inserzione: Inserimento di un nuovo impiegato -> inserimento dati dipartimento oppure nulls. Inserimento dati nuovo dipartimento -> almeno 1 impiegato (Id_imp è PK, non null) • Anomalie da cancellazione: Eliminazione dell’ultimo dipendente di un dipartimento -> perdita delle informazioni sul dipartimento • Anomalie da modifica: Nuovo direttore dipartimento -> modifica di tutte le tuple relative a impiegati di quel dipartimento.

  6. Impiegato_fax Nome Cognome CF Data_n indirizzo Stip_annuo Superio_id Id_dip Impiegato Nome Cognome CF Data_n indirizzo Stip_annuo Superio_id Id_dip Tel. Fax_imp Tel. Fax. Id_dip Fax. Linee guida informali (4) • Ridurre il numero di valori null nelle tuple: • Valori null possono essere variamente interpretati: non applicabile, sconosciuto, non inserito • In molti casi conviene creare nuove relazioni per ridurre i null. • Esempio: • Se solo il 5% degli impiegati ha un fax personale avremo il 95% di null.

  7. Linee guida informali (5) • Evitare le tuple spurie: • Una tupla spuria (cioè con informazioni non corrette) può essere generata a seguito di un join naturale • E’ necessario realizzare schemi che consentano di effettuare join con condizioni di uguaglianza su attributi che siano o chiavi primarie o chiavi esterne, così da garantire l’assenza di tuple spurie.

  8. Dipendenze funzionali • Una dipendenza funzionale è un vincolo tra due insiemi di attributi di una base di dati e dipende dalla semantica dello schema. • Data uno schema relazionale R e due sottoinsiemi non vuoti di attributi X e Y esiste una dipendenza funzionale XY se per ogni istanza r di R: t1 r,t2  r, x(t1) = x(t2) y(t1) = y(t2) i.e., date due tuple in r se i valori su X coincidono, anche i valori su Y coincidono.

  9. Dipendenze funzionali (2) • Notare che: • Se un vincolo su uno schema R indica che X sia una chiave candidata di R ciò implica che X Y per ogni sottoinsieme Y di attributi di R. • Non vale la proprietà : X Y YX.

  10. Dipendenze funzionali (3) • Sia F l’insieme delle FD che sono specificate su uno schema R. • In generale ci saranno comunque altre FD non specificate esplicitamente. • Chiamiamo F+ , chiusura di F, l’insieme delle FD implicate da F. • Esistono regole, corrette e complete, per determinare le FD, detti assiomi di Armstrong.

  11. Dipendenze funzionali (4) • Assiomi di Armstrong: • Riflessività: X Y  X Y • Incremento: X Y  XZ YZ • Transitività: X Y , Y Z  X Z Possono essere anche determinate altre utili regole: • Unione: X Y , XZ  X YZ • Decomposizione: X YZ  X Y

  12. Dipendenze funzionali (5) • Un insieme F di dipendenze funzionale è minimo se: • Ogni FD ha 1 solo attributo alla sua destra • Non è possibile rimuovere alcuna FD da F ed avere ancora un insieme equivalente ad F. • La parte sinistra di ogni dipendenza funzionale è minima. • In tal modo otterremmo sicuramente schemi privi di ridondanza • Problemi: il calcolo della F+ è pesante e in genere va accettata una certa quantità di ridondanza per motivi di efficienza.

  13. Forme normali • Un metodo formale per analizzare le relazioni • Consente una eventuale decomposizione di relazioni in schemi che godono di migliori proprietà. • E’ in generale necessario che anche altre proprietà siano verificate per garantire un buon progetto: • Lossless join (join non additivo) • Conservazione delle dipendenze

  14. 1 Forma normale • Coincide in pratica con la definizione di relazione: • Il dominio di ciascun attributo deve consistere di valori atomici e il valore di un attributo in una tupla deve essere un valore singolo del dominio • Il metodo di decomposizione è quello già descritto per il mapping ER relazionale

  15. 2 Forma Normale • Uno schema R è in questa forma se ogni attributo non primo ha una FD piena dalla PK di R. Impiegato_prog Nome Cognome CF N_prog indirizzo Stip_annuo Superio_id Nome_prog Sede Ore_lav Impiegato_prog CF N_prog Ore_lav Progetto Impiegato Nome Cognome indirizzo Stip_annuo Superio_id CF N_prog Nome_prog Sede

  16. Impiegato_dipartimento Impiegato Nome Nome Cognome Cognome CF CF Data_n Data_n indirizzo indirizzo Stip_annuo Stip_annuo Superio_id Superio_id Id_dip Id_dip 3 Forma Normale • Uno schema R è in questa forma se per ogni FD X Y, X è una superchiave di R oppure Y è un attributo primo. DipNome Dir_dip Data_ino Dipartimento Id_Dip DipNome Dir_dip Data_ino

  17. Forma Normale di Boyce-Codd • Uno schema R è in questa forma se per ogni FD X Y, X è una superchiave di R • In altre parole R è in BCNF se le uniche FD non ovvie sono vincoli di chiave. • Se R è in BCNF è ovviamente anche in 3NF. Se una R è in 3NF, ma non in BCNF è ancora possibile ridondanza. • 3NF è comunque accettabile ed è sempre possibile decomporre una R in 3NF relazioni che godano anche del lossless-join e preservino le dipendenze.

  18. Problemi delle decomposizioni • Interrogazioni più costose a causa dei join • Perdita di informazione (tuple spurie) dovuta a join. • Controllo delle dipendenze può richiedere l’effettuazione di join.

  19. Decomposizione senza perdite • La decomposizione di uno schema R(X) in due sottoinsiemi di attributi X1 e X2 tali che X1X2=X e X1X2=X0 è lossless join se è soddisfatta la FD X0  X1 oppure X0  X2 • La decomposizione è lossless se l’insieme degli attributi comuni alle due relazioni risultanti è chiave per almeno 1 delle 2 relazioni. • La condizione è sufficiente, non necessaria • Data R con FD F, se XY viola la BCNF possiamo sempre decomporre in R-Y e XY ottenendo relazioni BCNF e lossless join, ma non è assicurata la conservazione delle dipendenze.

  20. Conservazione delle dipendenze • E’ in generale importante mantenere i vincoli espressi nelle FD in singole relazioni, così da poterli verificare. • Qs. Può essere in contrasto con la normalizzazione • Esiste un algoritmo che garantisce il lossless join e la conservazione delle dipendenze con decomposizione in 3NF (non in BCNF)

  21. Conservazione delle dipendenze (2) • Esempio: • R(impiegato, progetto,sede) • FD: impiegato  sede (un impiegato lavora in una sede); progetto-sede  impiegato (ogni progetto ha più impiegati, in sedi diverse, ogni impiegato può gestire più progetti, ma in ciascuna sede un progetto ha un responsabile) • Non in BCNF: impiegato  sede e impiegato non è superchiave, ma non è decomponibile xchè progetto-sede  impiegato include tutti gli attributi e quindi non è decomponibile.

  22. Riassumendo.. • Relazioni in BCNF sono prive di ridondanza • Se non è possibile ottenere una decomposizione BCNF, lossless join e con conservazione delle dipendenze possiamo accontentarci di una 3NF. • Soprattutto considerare ciò che desideriamo, cioè tenere comunque in conto le prestazioni e le interrogazioni probabili.

More Related