Definizione di normalizzazione di un database
Definizione di normalizzazione
Il termine normalizzazione indica il processo di organizzazione dei dati in un database. Tale processo comprende la creazione di tabelle e la definizione di relazioni tra di esse sulla base di regole progettate in modo da proteggere i dati e rendere il database più flessibile mediante l'eliminazione della ridondanza e delle dipendenze incoerenti.La presenza di dati ridondanti comporta uno spreco di spazio su disco nonché problemi di manutenzione. Se è necessario modificare dati presenti in più posizioni, la modifica deve essere effettuata ovunque seguendo le stesse modalità. Ad esempio, è più agevole implementare la modifica relativa all'indirizzo di un cliente se i dati relativi sono memorizzati solo nella tabella Clienti.
Che cos'è una "dipendenza incoerente"? Mentre è intuitivo per un utente cercare nella tabella Clienti l'indirizzo di un cliente specifico, può non avere senso cercare in tale tabella le informazioni relative allo stipendio del dipendente che si occupa di quel cliente. Le informazioni sullo stipendio sono correlate al dipendente, ovvero sono dipendenti da quest'ultimo, pertanto devono essere spostate nella tabella Dipendenti. Le dipendenze incoerenti possono rendere difficile l'accesso ai dati, in quanto il percorso per la ricerca dei dati può risultare mancante o danneggiato.
Per la normalizzazione dei database è necessario seguire alcune regole, ciascuna delle quali viene definita "forma normale". Se si osserva la prima regola, il database viene considerato nella "prima forma normale". Se si osservano le prime tre regole, il database viene considerato nella "terza forma normale". Sebbene siano possibili altri livelli di normalizzazione, la terza forma normale è considerata il livello massimo necessario per la maggior parte delle applicazioni.
Come per molte regole e specifiche formali, gli scenari reali non consentono sempre la conformità totale. In generale poiché la normalizzazione richiede l'uso di tabelle aggiuntive, viene considerata troppo dispendiosa da alcuni clienti. Se si decide di violare una delle prime tre regole di normalizzazione, assicurarsi che l'applicazione sia in grado di prevenire i problemi che possono derivarne, quali la ridondanza dei dati e le dipendenze incoerenti.
Nelle descrizioni che seguono sono inclusi alcuni esempi.
Prima forma normale
- Eliminare i gruppi ripetuti in singole tabelle.
- Creare una tabella separata per ciascun insieme di dati correlati.
- Identificare ciascun insieme di dati correlati associandovi una chiave primaria.
Che cosa succede quando si aggiunge un terzo fornitore? La soluzione non consiste nell'aggiungere un campo. Sono infatti necessarie modifiche al programma e alla tabella che tuttavia non permettono di inserire agevolmente un numero dinamico di fornitori. È invece opportuno inserire tutte le informazioni sui fornitori in un'altra tabella denominata Fornitori e quindi collegare l'inventario ai fornitori tramite una chiave basata sul numero di voce oppure i fornitori all'inventario tramite una chiave basata sul codice fornitore.
Seconda forma normale
- Creare tabelle separate per insiemi di valori validi per più record.
- Correlare queste tabelle a una chiave esterna.
Terza forma normale
- Eliminare i campi che non dipendono dalla chiave.
Ad esempio, in una tabella Colloqui di assunzione è possibile includere il nome e l'indirizzo dell'università dei candidati. Per i gruppi di distribuzione è tuttavia necessario disporre di un elenco completo di università. Se le informazioni sull'università sono memorizzate nella tabella Candidati, non sarà possibile ottenere l'elenco delle università non associate ai candidati correnti. Creare una tabella Università separata e collegarla alla tabella Candidati utilizzando una chiave basata sul codice università.
ECCEZIONE: l'adozione della terza forma normale non è sempre pratica anche se teoricamente auspicabile. Se si dispone di una tabella Clienti e si desidera eliminare tutte le possibili dipendenze tra campi, è necessario creare tabelle separate per città, CAP, rappresentanti, classi di clienti e gli eventuali altri fattori che possono essere duplicati in più record. Nella teoria la normalizzazione è sempre auspicabile, tuttavia l'utilizzo di un numero elevato di tabelle di dimensioni limitate può determinare una riduzione del livello delle prestazioni oppure richiedere capacità di memoria e di apertura dei file superiori a quelle disponibili.
Può risultare più appropriato applicare la terza forma normale solo ai dati soggetti a frequenti modifiche. Se sussistono dei campi dipendenti, progettare l'applicazione in modo da richiedere la verifica di tutti i campi correlati in caso di modifica di un campo.
Altre forme di normalizzazione
Sono inoltre disponibili una quarta forma normale, denominata Boyce Codd Normal Form (BCNF), e una quinta forma anche se vengono raramente prese in considerazione nella progettazione pratica. Il mancato utilizzo di queste regole può non consentire una perfetta progettazione del database, senza tuttavia influire negativamente sulla funzionalità.Normalizzazione di una tabella di esempio
La procedura descritta di seguito illustra il processo di normalizzazione di una tabella Students fittizia.- Tabella non normalizzata:
Student# Advisor Adv-Room Class1 Class2 Class3 1022 Jones 412 101-07 143-01 159-02 4123 Smith 216 201-01 211-02 214-01 - Prima forma normale: nessun gruppo ripetuto
Le tabelle dovrebbero presentare solo due dimensioni. Poiché a un singolo studente sono associate più classi, è necessario elencare tali classi in una tabella diversa. I campi Class1, Class2 e Class3 nel record sopra riportato sono dunque indice di problemi di progettazione.
Nei fogli di calcolo viene spesso utilizzata la terza dimensione, ma non nelle tabelle. Un'altra prospettiva da cui osservare questo problema è l'utilizzo di una relazione uno-a-molti. In questo caso non inserire entrambi i lati della relazione nella stessa tabella, ma creare un'altra tabella utilizzando la prima forma normale ed eliminando il gruppo ripetuto (Class#), come illustrato di seguito:Student# Advisor Adv-Room Class# 1022 Jones 412 101-07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 201-01 4123 Smith 216 211-02 4123 Smith 216 214-01 - Seconda forma normale: eliminazione di dati ridondanti
Considerare i valori multipli di Class# per ciascun valore Student# nella tabella sopra riportata. Class# non è funzionalmente dipendente da Student# (chiave primaria), pertanto questa relazione non è compresa nella seconda forma normale.
Le due tabelle che seguono illustrano la seconda forma normale:
Students:Student# Advisor Adv-Room 1022 Jones 412 4123 Smith 216
Registration:Student# Class# 1022 101-07 1022 143-01 1022 159-02 4123 201-01 4123 211-02 4123 214-01
Nell'ultimo esempio, Adv-Room (il numero dell'ufficio del tutor) non è funzionalmente dipendente dall'attributo Advisor. Per risolvere il problema è possibile spostare tale attributo dalla tabella Students alla tabella Faculty, come illustrato di seguito:
Students:
| Student# | Advisor |
|---|---|
| 1022 | Jones |
| 4123 | Smith |
Faculty:
| Name | Room | Dept |
|---|---|---|
| Jones | 412 | 42 |
| Smith | 216 | 42 |
fonte: Microsoft
Commenti
Posta un commento