Principi della terza forma normale (3NF)

La terza forma normale (3NF) è un passo verso ancora più ordine nei nostri dati. In breve, una tabella è in 3NF se:

1. È già in seconda forma normale (2NF).
2. Tutti gli attributi non chiave dipendono solo dalla chiave primaria e da nient'altro (niente dipendenze transitive!).

In altre parole, la 3NF richiede che tutti i dati nella tabella siano direttamente collegati alla sua chiave primaria e non dipendano da altri attributi non chiave.

Una dipendenza transitiva si verifica se l'attributo A dipende dall'attributo B, e l'attributo B dipende dall'attributo C, creando una catena di dipendenze A → B → C. Per esempio, "Dipendente" dipende da "Dipartimento", e "Dipartimento" dipende da "Posizione". Quindi, "Dipendente" dipende transitivamente da "Posizione".

Esempio di violazione della 3NF

Supponiamo di avere una tabella employees che contiene dati sui dipendenti:

Qui:

• employee_id — chiave primaria.
• department e department_manager — attributi non chiave.

A prima vista sembra tutto ok, ma se guardiamo meglio, notiamo un problema: department_manager dipende non da employee_id, ma da department. Quindi, c'è una dipendenza transitiva: employee_id → department → department_manager.

Problemi che possono sorgere

Se cambiamo il nome del manager del dipartimento ("Finance"), dovremo aggiornare tutte le righe dove è indicato quel dipartimento. Se per caso dimentichiamo di aggiornare una delle righe, i dati diventano incoerenti. Un bel mal di testa che si può evitare.

Portare la tabella in 3NF

Per eliminare le dipendenze transitive, dividiamo la tabella in due: una conterrà i dati sui dipendenti, l'altra sui dipartimenti.

Tabella employees

Tabella departments

Ora tutto è strutturato, e ogni tabella fa il suo lavoro:

1. La tabella employees contiene i dati sui dipendenti.
2. La tabella departments contiene i dati sui dipartimenti e i loro manager.

Se il manager di un dipartimento cambia, dobbiamo aggiornare solo una riga nella tabella departments, non tutte le righe dei dipendenti.

Come capire se una tabella viola la 3NF?

Per capire se una tabella viola la 3NF, controlla:

1. Ci sono dipendenze transitive nella tabella? Per esempio, l'attributo A dipende dall'attributo B, che dipende dall'attributo C.
2. Tutti gli attributi non chiave dipendono direttamente dalla chiave primaria? Se qualcosa dipende da un altro attributo non chiave, la tabella non è in 3NF.

Esempio pratico: negozio

Vediamo la tabella sales, che contiene dati sulle vendite:

Qui vediamo chiaramente la ridondanza: l'informazione sul prezzo del prodotto si ripete per ogni vendita. Se il prezzo cambia, i dati diventano subito incoerenti.

Per eliminare la violazione della 3NF, dividiamo la tabella in due:

1. La tabella sales conterrà le informazioni sulle vendite.
2. La tabella products — dati sui prodotti e i loro prezzi.

Tabella sales

Tabella products

Ora, se il prezzo di un prodotto cambia, aggiorniamo solo una riga nella tabella products e i dati restano coerenti.

Esercizio pratico

Ecco un esercizio: hai una tabella students_courses fatta così:

Dividi la tabella in modo che rispetti la 3NF. Suggerimento: devi creare tre tabelle (students, courses, teachers) e collegarle nel modo giusto.

Perché è importante rispettare la 3NF?

Perché dovresti sbatterti con la terza forma normale (3NF)? Perché ti semplifica davvero la vita. Quando le tabelle sono in 3NF, i dati sono più ordinati — niente duplicazioni inutili, quindi meno possibilità di rompere qualcosa per sbaglio. Gli aggiornamenti sono più veloci e semplici, perché tutto è in un posto solo, non copiato in tutte le righe.

In più, la struttura del database diventa più flessibile. Vuoi aggiungere un nuovo campo o cambiare uno vecchio? Non devi stravolgere tutto il sistema.

Ma, come in ogni bella storia, c'è un dettaglio: una normalizzazione troppo spinta può portare a un sacco di tabelle minuscole e query complicate con tanti JOIN. A volte può davvero rallentare. Quindi la cosa più importante è il buon senso. Dove serve — normalizza, dove è più semplice lasciare un po' di ridondanza — non aver paura.

Andremo ancora più a fondo: impareremo a collegare bene le tabelle e a creare database che siano sia comodi che affidabili. Avanti, verso un database design top!