La Normalizzazione del Database: Dalla Prima alla Terza Forma Normale

La normalizzazione è un processo di progettazione di un database relazionale che mira a organizzare le tabelle in modo da ridurre la ridondanza dei dati e migliorare la loro integrità. L'obiettivo è assicurarsi che ogni "fatto" sia salvato una sola volta. Il processo si articola in diverse "forme normali", ma le prime tre sono le più importanti.

Prima Forma Normale (1NF)

Una tabella è in 1NF se soddisfa due condizioni:

1. Tutti i valori nelle colonne sono "atomici" (indivisibili). Non puoi avere una colonna "colori" che contiene una lista come "rosso, verde, blu". Dovresti creare righe separate per ogni colore.
2. Non ci sono gruppi di colonne ripetute (es. `prodotto1`, `prodotto2`, `prodotto3`). Dovresti creare una tabella separata `prodotti_ordinati`.

Seconda Forma Normale (2NF)

Una tabella è in 2NF se è in 1NF e ogni attributo non-chiave dipende funzionalmente dall'intera chiave primaria. Questo si applica solo a tabelle con una chiave primaria composta (fatta da più di una colonna).

Esempio di violazione: una tabella `ordini_dettagli` con chiave `(ordine_id, prodotto_id)`. Se questa tabella contenesse anche la colonna `descrizione_prodotto`, violerebbe la 2NF, perché `descrizione_prodotto` dipende solo da `prodotto_id`, non dall'intera chiave. La soluzione è spostare `descrizione_prodotto` nella tabella `prodotti`.

Terza Forma Normale (3NF)

Una tabella è in 3NF se è in 2NF e tutti i suoi attributi non-chiave dipendono solo dalla chiave primaria e non da altri attributi non-chiave (non ci sono "dipendenze transitive").

Esempio di violazione: una tabella `prodotti` con le colonne `produttore_id` e `indirizzo_produttore`. Qui, `indirizzo_produttore` dipende da `produttore_id`, che non è la chiave primaria. La soluzione è creare una tabella separata `produttori` con `(produttore_id, indirizzo_produttore)` e mantenere solo `produttore_id` nella tabella `prodotti`.

Raggiungere la 3NF è l'obiettivo standard per un buon design di database relazionale. Sebbene a volte la "denormalizzazione" sia usata per migliorare le performance di lettura, partire da un design normalizzato è la pratica migliore, come discusso nella nostra guida su SQL vs NoSQL.