Data Warehouse

Ho visto data warehouse costruiti su granularità giornaliere perché “tanto al business basta così” — e diventare inutili il giorno dopo, quando il marketing ha chiesto l’analisi oraria delle conversioni. Ho visto dimensioni cliente senza storicizzazione, che sovrascrivevano il CAP ogni volta che uno si trasferiva — e report dell’anno prima che non tornavano più. Ho visto ETL che caricavano 200 milioni di righe in full ogni notte perché nessuno aveva mai avuto il coraggio di riprogettare il delta.

E ho visto l’esatto contrario: data mart piccoli, ben modellati, con il bus matrix disegnato bene — che rispondono a domande che nessuno aveva ancora pensato di fare, senza che si tocchi una riga di codice.

La differenza non è mai stata la tecnologia. È sempre stato il modello.

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.

Nei database transazionali conta il momento presente: l’ordine che stai inserendo, il saldo corrente, la riga che stai aggiornando. In un data warehouse conta il percorso: com’era quel cliente sei mesi fa, com’è cambiato il prodotto nel tempo, quale versione dell’anagrafica era valida quando è stato emesso quel contratto.

Quasi sempre, il DWH che non regge si riconosce da queste cose:

• granularità sbagliata in tabella dei fatti — troppo grossa e perdi dettaglio, troppo fine e rallenti tutto
• dimensioni piatte senza gestione SCD — storia persa, analisi “as-was” impossibili
• gerarchie non bilanciate che rompono le aggregazioni appena il business chiede un drill-down
• bus matrix mai disegnato — data mart che non dialogano, stesse entità modellate in modo diverso in ogni reparto
• ETL progettati come copia invece che come trasformazione — sporcizia del transazionale che arriva intatta in analisi

Sono problemi che in sviluppo non si vedono. Esplodono dopo sei mesi, quando il business chiede report che il modello non può supportare.

📊 Cosa chiedo al business prima di mettere mano al modello #

Prima ancora di disegnare una tabella dei fatti, ci sono cinque domande che pongo al business. Non sono opzionali — sono la differenza tra un data warehouse che dura dieci anni e uno che va riscritto dopo due.

Cinque domande. Venti minuti di riunione. Settimane di riscritture evitate.

📚 Di cosa parlo qui #

Storie vere di progettazione e ristrutturazione di data warehouse in produzione. Modellazione dimensionale (Kimball letto bene, non a slogan), slowly changing dimensions, bus matrix, gerarchie, strategie di caricamento incrementale e performance analitiche.

Niente ricette da manuale. Solo soluzioni applicate a sistemi veri — assicurazioni, finance, pubblica amministrazione, telco, postale — che servono decisioni aziendali reali.

Un data warehouse non si costruisce per contenere dati.

Si costruisce per rispondere a domande — e quelle domande, inevitabilmente, cambiano.