Quali sono le forme di Normalizzazione di un database in informatica

Il termine normalizzazione indica il processo di organizzazione dei dati in un database (DB). Tale processo di normalizzazione 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.

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.

Non utilizzare campi multipli in una singola tabella per memorizzare dati simili. Ad esempio, per controllare una voce di inventario proveniente da due possibili origini, è possibile creare un record di inventario contenente i campi per Codice fornitore 1 e Codice fornitore 2.

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.

I record devono dipendere solo dalla chiave primaria di una tabella, se necessario una chiave composta. Si consideri, ad esempio, l’indirizzo di un cliente in un sistema contabile. Si noterà che l’indirizzo è richiesto non solo dalla tabella Clienti, ma anche dalle tabelle Ordini, Spedizioni, Fatture, Contabilità fornitori e Raccolte. Invece di memorizzare l’indirizzo del cliente come voce separata in ciascuna tabella, è preferibile memorizzarlo in un’unica tabella, ovvero nella tabella Clienti oppure in una tabella Indirizzi separata.

Terza forma normale

•     Eliminare i campi che non dipendono dalla chiave.

I valori di un record non compresi nella relativa chiave non appartengono alla tabella. In generale, ogni volta che il contenuto di un gruppo di campi può essere applicabile a più record della tabella, provare a inserire tali campi in una tabella separata.

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