Data Warehouse
Un data warehouse non è un database con le tabelle più grandi.
È un modo diverso di pensare ai dati — orientato all’analisi, alla storia, alle decisioni.
La differenza tra un DWH che funziona e uno che diventa un problema sta quasi sempre nel modello. Tabelle dei fatti con la granularità sbagliata, dimensioni mal progettate, gerarchie che non reggono le query di aggregazione. Problemi che non si vedono in fase di sviluppo, ma esplodono quando il business chiede report che il modello non può supportare.
In questa sezione racconto casi reali di progettazione e ristrutturazione di data warehouse: modellazione dimensionale, gerarchie bilanciate, slowly changing dimensions, strategie di caricamento. Non teoria da libro di Kimball, ma soluzioni applicate in produzione su sistemi che servono decisioni aziendali vere.
Perché un data warehouse non si costruisce per contenere dati.
Si costruisce per rispondere a domande.
Gerarchie sbilanciate: quando il cliente non ha un padre e il gruppo non ha un nonno
Un cliente con una gerarchia a tre livelli — Top Group, Group, Client — dove non tutti i rami sono completi. Come ho bilanciato una ragged hierarchy con il self-parenting: chi non ha padre diventa padre di sé stesso.
SCD Tipo 2: la storia che il business non sapeva di volere
Un direttore commerciale chiede quanti clienti aveva la regione Nord a giugno scorso. Il DWH non sa rispondere perché ogni aggiornamento sovrascrive i dati precedenti. Come ho implementato una SCD Tipo 2 con chiavi surrogate e date di validità per restituire al business la memoria storica.
Fatto a grana sbagliata: quando la fact table non risponde alle domande giuste
Una fact table costruita sul totale mensile della fattura sembrava perfetta. Poi il business ha chiesto il dettaglio per prodotto, per riga, per cliente. E il data warehouse è diventato muto.