Tag: data-warehouse, etl, olap, bi, star-schema, snowflake-schema, scd
Livello: intermedio
TL;DR: Un Data Warehouse (DWH) è un database centralizzato progettato per l'analisi dei dati e la business intelligence (OLAP), alimentato storicamente da fonti eterogenee.
Sistema orientato al soggetto, integrato, time-variant e non volatile (definizione classica di Bill Inmon).
OLAP (Online Analytical Processing) vs OLTP (Online Transaction Processing): il DWH è ottimizzato per query in lettura complesse su enormi moli di dati (OLAP).
Pipeline ETL (Extract, Transform, Load): il flusso che estrae i dati dai sistemi operazionali, li pulisce, li trasforma e li carica nel DWH.
Data Mart: un sottoinsieme logico o fisico del DWH focalizzato su un singolo dipartimento o processo aziendale (es. HR, Vendite).
Star Schema (Schema a Stella): architettura di modellazione con una tabella dei fatti centrale (misure/metriche) e tabelle dimensionali denormalizzate (contesto).
Snowflake Schema (Schema a Fiocco di Neve): variante in cui le tabelle dimensionali sono normalizzate in gerarchie, riducendo la ridondanza ma aumentando le join.
SCD (Slowly Changing Dimensions): pattern per tracciare le modifiche storiche ai dati di contesto (es. Tipo 1 sovrascrive, Tipo 2 crea nuova riga con date di validità).
Q: Qual è la differenza principale tra ETL ed ELT?R: In ETL la trasformazione avviene prima del caricamento nel DWH. In ELT i dati grezzi vengono caricati subito e le trasformazioni avvengono direttamente nel database di destinazione sfruttandone la potenza di calcolo.
Q: Quando sceglieresti uno Snowflake Schema rispetto a uno Star Schema?R: Lo uso se sono strettamente vincolato dallo spazio di archiviazione o se ho gerarchie dimensionali molto complesse, accettando però un degrado delle performance di query per via delle join aggiuntive.
Q: Come gestisci lo storico degli indirizzi di un cliente se il business vuole vedere le vendite passate con l'indirizzo vecchio?R: Implemento una Slowly Changing Dimension (SCD) di Tipo 2 sulla dimensione cliente, aggiungendo date di inizio e fine validità e generando una nuova chiave surrogata a ogni modifica.
Applicare i principi di normalizzazione (es. 3NF) al design del DWH, degradando pesantemente le performance analitiche in lettura.
Sottovalutare la fase di data cleansing e standardizzazione durante l'ETL, causando metriche inaffidabili nei report (garbage in, garbage out).
Non definire chiavi surrogate per le dimensioni, appoggiandosi esclusivamente alle chiavi naturali dei sistemi sorgente che potrebbero cambiare.
Trascurare il monitoraggio e la gestione degli errori dei job ETL schedulati, causando dipendenze a catena interrotte e dati mancanti.
[ ] Implementazione pratica di SCD Tipo 2 e Tipo 3
[ ] Architetture ibride modernizzate (es. Data Lakehouse)
[ ] Strategie di partizionamento per tabelle dei fatti massive