Normalizzare o denormalizzare i dati: quando conviene cosa?

Normalizzare significa organizzare i dati in tabelle separate in modo che ogni informazione viva in un solo posto: l'indirizzo di un cliente sta nella tabella clienti, non ripetuto in ogni suo ordine. Il vantaggio è l'integrità: se l'indirizzo cambia, lo aggiorni in un punto e tutte le viste lo riflettono, senza rischio che due copie divergano. Denormalizzare fa l'opposto di proposito: duplica deliberatamente informazione tra tabelle per evitare i join a runtime, accettando che una stessa informazione viva in più posti. Le forme normali (prima, seconda, terza, e oltre) sono i gradini formali con cui la teoria dei database descrive quanto lontano si spinge la normalizzazione, ma nella pratica quotidiana pochi team ragionano in quei termini: la domanda concreta resta sempre la stessa, dove serve integrità e dove serve velocità di lettura. Un errore comune è considerare la denormalizzazione un ripiego provvisorio da correggere appena possibile, quando in realtà è spesso una scelta di design definitiva e corretta per il livello di consumo dei dati.

Dove vince l'una e dove l'altra

Un sistema transazionale (OLTP), il gestionale che processa ordini in tempo reale, vuole normalizzazione: ogni scrittura tocca un solo posto, niente rischio di incoerenza tra copie duplicate, e il volume di righe per transazione è basso quindi i join costano poco. Un sistema analitico (OLAP) spinge nella direzione opposta, ma con meno assolutezza di un tempo: sui motori colonnari moderni un join tra fatti grandi e dimensioni piccole costa poco, perché la dimensione viene distribuita ai nodi e usata per filtrare la scansione. Denormalizzare conviene quando i join sono molti, tra tabelle grandi entrambe, o quando la stessa query gira migliaia di volte al giorno; e ha un costo suo, perché una tabella più larga significa più byte da scansionare. La verifica la faccio sempre misurando sul motore in uso, non decidendo a priori.

La regola pratica

La sintesi che regge nella maggior parte delle architetture dati moderne è semplice: normalizza la fonte di verità, denormalizza il livello di servizio. Il sistema operazionale e lo strato integrato del data warehouse restano normalizzati, perché lì l'integrità conta più della velocità di lettura; il livello gold pensato per BI e dashboard viene denormalizzato apposta, perché lì la velocità di lettura conta più della purezza del modello. Applicare la stessa regola ovunque, in un senso o nell'altro, è quasi sempre l'errore: il compromesso giusto dipende da chi legge quei dati e con quale frequenza.