Cosa sono le Slowly Changing Dimensions (SCD)?
Tecniche per gestire il cambiamento nel tempo degli attributi di una dimensione (es. l'indirizzo di un cliente) in un data warehouse.
Una dimensione, in uno star schema, descrive il contesto di un fatto: il cliente che ha comprato, il prodotto venduto, il negozio dove è avvenuta la transazione. Il problema è che queste entità cambiano nel tempo: un cliente si trasferisce e cambia indirizzo, un prodotto viene riclassificato in un'altra categoria, un negozio cambia insegna. Le Slowly Changing Dimensions (SCD) sono l'insieme di tecniche che rispondono a una domanda precisa: quando genero un report storico su una vendita di due anni fa, devo vedere l'indirizzo che il cliente aveva allora, o quello attuale? Non esiste una risposta giusta in assoluto: dipende da cosa serve al business, ed è proprio questa scelta, fatta dimensione per dimensione e attributo per attributo, a determinare quale tipo di SCD applicare. La letteratura di data warehousing classica, a partire da Kimball, distingue otto tipi numerati da 0 a 7, ciascuno con un comportamento diverso rispetto alla conservazione della storia.
I tipi principali (0-7)
| Tipo | Meccanismo | Storia conservata |
|---|---|---|
| Type 0 | L'attributo non cambia mai una volta scritto, per definizione | Non applicabile (immutabile) |
| Type 1 | Sovrascrive il vecchio valore col nuovo | Nessuna |
| Type 2 | Aggiunge una nuova riga con valid_from/valid_to | Completa, riga per riga |
| Type 3 | Aggiunge una colonna per il valore precedente accanto a quello attuale | Un solo livello indietro |
| Type 4 | Sposta gli attributi a cambiamento rapido in una mini-dimensione separata | Completa, nella mini-dimensione |
| Type 5 | Aggiunge alla dimensione principale un riferimento Type 1 alla mini-dimensione del Type 4 | Come Type 4, più lettura diretta del valore corrente |
| Type 6 | Ibrido "1+2+3": combina i tre approcci nella stessa riga | Corrente, completa e precedente immediato insieme |
| Type 7 | Doppia chiave: naturale (sempre aggiornata) e surrogata (legata alla riga storica) | Entrambe, per report "come è oggi" e "come era allora" |
Un data engineer ha proposto nel 2025 un "Type 8" pensato per dimensioni ad altissima cardinalità e variazione, che sostituisce le date di validità con un evento per ogni combinazione osservata e sfrutta il partizionamento per data: l'autore stesso dichiara che "nome e numero non sono ancora stabiliti". Non è un tipo riconosciuto dalla metodologia Kimball, solo una proposta individuale non ancora verificata dalla comunità: vale la pena saperlo, non applicarlo come fosse uno standard.
Rapidly Changing Dimension (RCD) / Fast Changing Dimension (FCD)
Una dimensione si dice "rapidly changing" o "fast changing" quando uno o più dei suoi attributi cambiano molto spesso e su moltissime righe, tipicamente attributi di natura quasi transazionale (la quantità ordinata, il prezzo applicato, lo stato di un ordine). Applicare un Type 2 classico a questi attributi diventa impraticabile: ogni piccolo cambiamento genererebbe una nuova riga, facendo esplodere la dimensione a milioni di record inutili. La tecnica standard, codificata da Kimball, è proprio il Type 4: spostare gli attributi a cambiamento rapido in una mini-dimensione dedicata, più piccola e gestibile, lasciando la dimensione principale (il cliente, il prodotto) stabile e leggera.
Il Type 2 sotto critica: il "functional data engineering"
Una critica pratica al Type 2 di Zach Wilson (ex Facebook, Netflix, Airbnb) e Sahar Massachi, in "SCD-2 considered harmful" (novembre 2025): la logica valid_from/valid_to nasce quando il disco costava caro, ma oggi crea un problema operativo: ogni esecuzione dipende dallo stato lasciato da quella precedente, quindi un bug su una data costringe a rieseguire in sequenza tutti i giorni successivi. L'alternativa, "functional data engineering", accoda ogni giorno uno snapshot immutabile con colonna data (ds): il backfill diventa parallelizzabile e le query storiche si riducono a un filtro WHERE ds='...'. Non invalida il Type 2 dove serve la storia riga per riga: sposta il trade-off tra parallelizzabilità e semplicità.
Perché conta per un'azienda
Scegliere il tipo SCD giusto per ogni dimensione non è un dettaglio tecnico da lasciare a chi scrive le pipeline: è una decisione di business. Sbagliarla in un senso, usare Type 1 dove serviva Type 2, significa perdere la storia senza che nessuno se ne accorga: la reportistica storica diventa inaffidabile perché ogni fatto passato finisce per mostrare l'attributo attuale invece di quello vero al momento dell'evento. Sbagliarla nell'altro senso, usare Type 2 su una dimensione a cambiamento rapido invece del Type 4 previsto per quel caso, fa esplodere lo schema in dimensioni con milioni di righe di cui nessuno ha bisogno, appesantendo query e costi. Questa disciplina riguarda direttamente lo star schema, ed è la stessa distinzione tra integrità del modello e velocità di consegna che attraversa il dibattito Kimball vs Inmon: la SCD giusta è ciò che rende affidabile, nel tempo, il gold layer che entrambe le filosofie cercano di costruire.
Domande frequenti
Termini correlati
- Star schema · Modello dimensionale con una tabella dei fatti centrale collegata a tabelle di dimensione: lo schema sotto la maggior parte delle dashboard BI.
- Kimball vs Inmon · Due filosofie classiche del data warehouse: Inmon parte da un modello aziendale unico e normalizzato, Kimball da data mart dimensionali per processo di business.
- Data lineage · La mappa del percorso dei dati: da quale sorgente partono, quali trasformazioni subiscono e quali report, modelli o sistemi alimentano.
- Cumulative table design · Pattern che accumula metriche storiche con un FULL OUTER JOIN incrementale, senza rileggere l'intera finestra ogni volta.
Un termine che ti riguarda da vicino? Parliamone.
CONTATTAMI