La teoria: normalizzazione di un database

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

Poiché la normalizzazione richiede in generale l'uso di tabelle aggiuntive, viene considerata troppo dispendiosa da alcuni clienti. 

• Prima forma normale: Una tabella di un database si dice "tabella in prima forma normale" se,e solo se, le informazioni presenti in due colonne sono identiche e quindi abbiamo dati ripetuti. Per portare il database alla prima forma normale, basta eliminare una delle due colonne doppie. Ad esempio, proviamo a pensare cosa succederebbe in termini sia di tempo e di spazio se in una tabella comparissero due campi con nome diversi ma contenenti il nome ed il cognome della persona in questione. Lo spazio sprecato sarebbe molto di più e anche le ricerche (avendo più dati da consultare) si allungherebbero come tempi.
• Seconda forma normale: Una tabella di un database si dice "tabella in seconda forma normale" se, e solo se, non vi è presente al suo interno una colonna che contiene dati che possono derivare da altre colonne presenti all'interno della stessa tabella. Prendiamo come esempio un catalogo prodotti di fine 2001. Ormai è inutile inserire all'interno della tabella una colonna contenente i prezzi in lire ed una coi prezzi in euro. Infatti per ottenere un dato dall'altro basta solamente dividere (se dalle lire si vuol passare all'euro) o moltiplicare (se dall'euro si vuol passare alle lire) per il valore 1936.27 . Se in un database troviamo entrambi le colonne dei prezzi, questa tabella non si può ritenere di seconda forma normale. Se invece è presente solo un prezzo e l'altro lo ricaviamo tramite un semplice calcolo, questa tabella è considerata uniforme alla seconda forma di normalizzazione.
• Terza forma normale: Un database si dice di terza forma normale se e solo se non vi sono dati duplicati all'interno dello stesso. Questo tipo di normalizzazione dobbiamo vederlo come l'ampliamento della prima. Mentre nella prima non vi devono essere dati ripetuti nella stessa tabella, qui la ripetizione dei dati non deve avvenire nelle colonne delle tabelle del database. Basta infatti una sola colonna con determinati valori e poi ci si relaziona a quella. 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. 
• 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à.

Nota: può risultare 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.