★ DISPONIBILE PER FORMAZIONE E PROGETTI
enrico chiolo

Slowly Changing Dimensions

La famiglia di tecniche per gestire il cambiamento temporale nelle dimension table, e la critica che la considera obsoleta nell'era dello storage economico.

Le Slowly Changing Dimensions (SCD) sono una famiglia di tecniche di data modeling per gestire i cambiamenti temporali nei dati di una dimension table. Il caso tipo: un utente cambia paese, o un prodotto cambia categoria, e la dimension deve conservare sia la versione precedente (per gli eventi anteriori al cambio) sia la nuova. I manuali della tradizione dimensionale di Ralph Kimball ne catalogano vari “tipi”; Sahar Massachi, nella serie “Stop using Slowly-changing Dimensions!” su DataExpert.io, li critica come obsoleti, progettati per un’epoca di storage costoso, e propone come alternativa il date stamping: snapshot giornalieri append-only, dove “lo stato al tempo T” è la riga con datestamp T.1

I tipi principali

Type-1: overwrite

La pipeline sovrascrive la dimension ogni giorno con lo snapshot corrente. Semplice, ma senza storia: se dopo sei mesi qualcuno chiede quanti follower avevano gli utenti a marzo, il dato non esiste più.1

Type-2: valid_from / valid_to

Il tipo più diffuso. Si aggiungono colonne valid_from, valid_to e is_current: quando il dato cambia, la riga vecchia si “chiude” (valid_to = CURRENT_DATE - 1, is_current = false) e se ne inserisce una nuova. La storia c’è, ma al prezzo che Massachi documenta in dettaglio:1

  • le pipeline richiedono logica custom per chiudere le righe vecchie prima di inserire le nuove, e un errore nei valid_to produce buchi o sovrapposizioni nella storia;
  • il backfilling diventa sequenziale: ogni giorno dipende dallo stato del precedente, quindi riprocessare un mese significa trenta esecuzioni in fila, con una codebase separata da quella del run giornaliero;
  • le query storiche richiedono logica di intervallo a ogni join. Lo stato di dim_users al primo ottobre diventa:
SELECT * FROM dim_users
WHERE user_id = 123
  AND valid_from <= '2024-10-01'
  AND (valid_to > '2024-10-01' OR valid_to IS NULL)

Con più tabelle storiche da incrociare (utenti, dispositivi, relazioni), ogni join ripete quella logica di BETWEEN; dimenticarne una produce risultati silenziosamente sbagliati, perché si stanno incrociando snapshot di momenti diversi.1

Type-4: tabella corrente più tabella storica

Si mantengono dim_users (lo stato corrente) e dim_users_history (tutto il resto): due fonti di verità da tenere sincronizzate, analisti che devono ricordare quale tabella interrogare, e UNION ALL per qualsiasi analisi che attraversi il presente e il passato.1

Il confronto con il date stamping

SCD TYPE-2 user_id country valid_from valid_to is_current 123 IT 2024-01-01 2024-09-30 false 123 DE 2024-10-01 NULL true Ogni cambio "chiude" una riga: la storia sta nella logica degli intervalli. DATE STAMPING user_id country ds 123 IT 2024-09-30 123 DE 2024-10-01 WHERE ds='2024-09-30' lo stato passato è un filtro Una riga per entità per giorno: la storia sta nei dati, non nella logica.
Lo stesso cambio di paese di un utente nei due modelli. Con SCD-2 lo stato passato si ricostruisce con la logica degli intervalli; con il date stamping è una riga da filtrare.

Perché Massachi le considera obsolete

L’argomento economico: tutti i tipi di SCD cercano di risparmiare storage, e questo aveva senso quando il disco era costoso. Con il crollo dei costi di storage e compute dopo il 2015 (la “golden age” del data warehouse), il risparmio non vale più la complessità: quella di SCD-2 è una tassa ricorrente pagata in bug, allarmi notturni e analisi storiche che nessuno fa perché troppo dolorose.1

L’argomento teorico viene dal functional data engineering di Maxime Beauchemin: SCD-2 gestisce il tempo come stato mutabile da aggiornare, il date stamping lo gestisce come dato esplicito da appendere. La query di retention che chiude la Parte 2 della serie mostra la differenza: con gli snapshot datestampati la complessità resta tutta nella logica di business, non nella lotta con valid_from e valid_to.1

La critica è una posizione di Massachi, per quanto argomentata: la tradizione dimensionale di Kimball, da cui i tipi di SCD provengono, resta il riferimento storico del data modeling e la terminologia è ancora in uso corrente nella letteratura e nei colloqui tecnici.2

Voci correlate

Bibliografia e sitografia

  • Sahar Massachi, SCD-2 considered harmful! (Stop using Slowly-changing Dimensions! Part 2), DataExpert.io, 4 novembre 2025. blog.dataexpert.io
  • Sahar Massachi, The data warehouse setup no one taught you (Stop using Slowly-changing Dimensions! Part 1), DataExpert.io, 24 ottobre 2025. blog.dataexpert.io

Footnotes

  1. Massachi, SCD-2 considered harmful! Part 2, DataExpert.io, 2025. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. Massachi, Stop using SCD! Part 1, DataExpert.io, 2025. ↩