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.

La teoria: integrità relazionale

Andiamo a definire le regole di integrità all'interno del modello relazionale:

Chiavi primarie, candidate ed alternative

Sia R una relazione, con attributi A1, A2,..., An.

Il sottoinsieme di attributi K = (Ai, Aj,..., Ak) è detta chiave candidata se e solo se soddisfa le due seguenti proprietà:

1. Unicità: in ogni momento, due distinte tuple di R non avranno mai lo stesso valore per gli attributi Ai, Aj,..., Ak.
2. Minimalità: Nessuno tra gli attributi Ai, Aj,..., Ak può essere rimosso da K senza distruggere il vincolo di unicità

Ogni relazione ha almeno una chiave candidata, perché (come minimo) la combinazione di tutti i suoi attributi ha la proprietà di unicità.

Per una data relazione, una chiave candidata venga arbitrariamente designata come chiave primaria; le chiavi candidate rimanenti (se esistono) saranno dette chiavi alternative.

Chiavi esterne

Una chiave esterna è un attributo, o una combinazione di attributi, di una relazione R2 i cui valori corrispondono a quelli della chiave primaria di un'altra relazione R1. R1 ed R2 non devono necessariamente essere distinte.

Regole d'integrità

Il modello relazionale comprende due regole generali sull'integrità, espresse nei termini di chiavi primarie ed esterne. Le regole sono "generali" nel senso che ogni DBMS che affermi di conformarsi al modello relazionale deve soddisfarle.

1. Integrità delle entità: nessun attributo che partecipi alla chiave primaria di una relazione può accettare valori NULL.
2. Integrità relazionale: se la relazione R2 include una chiave esterna FK che corrisponda alla chiave primaria PK di un'altra relazione R1, allora ogni valore di FK in R2 deve alternativamente:

• essere uguale al valore di PK in qualche tupla di R1, oppure
• essere composta esclusivamente di valori NULL

R1 ed R2 non devono necessariamente essere distinte.

Nota: la terminologia del modello relazionale si traduce con la nomenclatura standard delle implementazioni RDBMS: relazione -> tabella; attributo -> colonna; tupla -> riga.

In generale la relazione R può essere realizzata tanto da una tabella quanto da una vista; si consideri però che le regole di integrità si applicano esclusivamente a tabelle reali e non a viste.