Executive summary
Quando un'azienda vuole analizzare i propri dati storici, vendite per periodo, produzione per stabilimento, margini per cliente, ha bisogno di organizzarli in una struttura che renda le domande di business facili da formulare e veloci da risolvere. La modellazione dimensionale è l'approccio più diffuso per progettare questa struttura: separa i numeri misurabili (quanto si è venduto, quanti pezzi prodotti) dal contesto che li descrive (chi ha comprato, quale prodotto, in quale periodo). Questo articolo analizza i principi fondamentali di questo approccio, le sue varianti per gestire i cambiamenti nel tempo, la sua applicazione con gli strumenti moderni, e il confronto con le alternative emerse nell'ultimo decennio, mostrando che la metodologia, pur con trent'anni di storia, resta tra gli approcci più consolidati e diffusi per la progettazione dei sistemi di analisi dati aziendali.
Background
La modellazione dimensionale è stata formalizzata da Ralph Kimball negli anni '90 come risposta a un problema pratico: i database relazionali normalizzati (terza forma normale), ottimali per le operazioni transazionali, producevano query analitiche lente e difficili da scrivere a causa del numero elevato di join necessari [1]. L'intuizione di Kimball è stata la separazione strutturale tra fatti, eventi misurabili che accadono nel business (una vendita, una spedizione, una lavorazione), e dimensioni, il contesto descrittivo che qualifica ogni fatto (cliente, prodotto, tempo, canale, stabilimento).
Il modello di riferimento è lo star schema: una tabella dei fatti al centro, collegata tramite chiavi esterne a tabelle dimensionali disposte a stella. Questa struttura minimizza il numero di join necessari per le query analitiche (tipicamente un join per dimensione) e si presta naturalmente all'aggregazione su qualsiasi combinazione di dimensioni, ciò che nel gergo analitico si definisce slice and dice [1]. I principali warehouse cloud (Snowflake, BigQuery, Redshift) e i motori analitici embedded (DuckDB) adottano storage colonnare e ottimizzatori di query progettati per i pattern di accesso tipici dello star schema, join tra una fact table di grandi dimensioni e dimension table più piccole, con aggregazione e filtro sulle colonne dimensionali [1].
L'approccio alternativo proposto da Bill Inmon, il Corporate Information Factory, prevede una normalizzazione completa nel data warehouse centrale, con i data mart dimensionali derivati come viste aggregate [2]. La distinzione tra i due approcci (Kimball: bottom-up, orientato ai data mart; Inmon: top-down, orientato al warehouse centrale) ha generato un dibattito durato decenni, ma nella pratica la maggior parte delle implementazioni moderne adotta una variante dell'approccio Kimball, spesso mediata da strumenti come dbt che rendono esplicita la stratificazione in staging, intermediate e mart [3].
Star schema: struttura e principi fondamentali
Tabelle dei fatti
La tabella dei fatti registra gli eventi misurabili del business. Ogni riga corrisponde a un singolo evento al livello di granularità più fine (grain). La definizione del grain è la decisione progettuale più critica nella modellazione dimensionale: determina cosa significa una riga nella tabella dei fatti e vincola tutte le analisi possibili [1].
Il grain può essere: transazionale (una riga per ogni riga d'ordine, per ogni movimento di magazzino, per ogni transazione di pagamento), periodico (un riepilogo per periodo, es. fatturato mensile per cliente), o di accumulo (una riga per ogni istanza di un processo, aggiornata man mano che il processo avanza, es. una riga per ogni ordine con colonne per data_ordine, data_spedizione, data_consegna, data_pagamento) [1].
Le colonne della tabella dei fatti sono di due tipi: chiavi esterne verso le dimensioni (fk_cliente, fk_prodotto, fk_data, fk_canale) e misure numeriche che rappresentano i valori di business (quantità, importo, costo, margine). Le misure possono essere additive (sommabili su tutte le dimensioni, es. importo), semi-additive (sommabili solo su alcune dimensioni, es. saldo di conto, sommabile per clienti ma non per tempo), o non additive (non sommabili, es. prezzo unitario, ratio) [1]. La distinzione tra questi tipi di misura è fondamentale per la correttezza delle aggregazioni nelle query analitiche.
Tabelle dimensionali
Le dimensioni forniscono il contesto descrittivo per i fatti. Una dimensione cliente contiene attributi come ragione sociale, settore, zona geografica, fascia di fatturato, agente di riferimento. Una dimensione prodotto contiene codice, descrizione, categoria, sottocategoria, fornitore, unità di misura. Una dimensione tempo, la dimensione universale presente in ogni star schema, contiene data, giorno della settimana, mese, trimestre, anno, festività, stagione [1].
Le dimensioni sono tipicamente wide (molte colonne) e shallow (relativamente poche righe rispetto ai fatti). Questa asimmetria è intenzionale: le colonne dimensionali sono gli attributi su cui gli utenti filtrano, raggruppano e segmentano i dati. Più attributi sono disponibili nella dimensione, più ricche sono le analisi possibili senza richiedere join aggiuntivi.
Le surrogate key (chiavi surrogate) sono chiavi primarie intere auto-generate assegnate a ogni riga dimensionale, distinte dalle chiavi naturali (business key) provenienti dai sistemi sorgente. L'uso di surrogate key isola il warehouse dai cambiamenti nei sistemi operazionali: se il gestionale cambia il formato del codice cliente, la surrogate key nel warehouse resta invariata [1].
Dimensioni conformate
Una dimensione conformata è una dimensione condivisa tra più tabelle dei fatti, con la stessa struttura e gli stessi valori in tutti i contesti. La dimensione tempo è l'esempio più ovvio: le vendite, la produzione e gli acquisti condividono la stessa tabella di date. Ma il principio si estende alle dimensioni prodotto, cliente e stabilimento. Le dimensioni conformate sono il meccanismo che rende possibile l'analisi cross-process: confrontare le vendite con la produzione, correlare gli acquisti con le scorte, analizzare i margini end-to-end [1]. In un contesto dbt, le dimensioni conformate sono implementate come model condivisi nel mart layer, referenziati da più fact table tramite ref() [3].
Slowly Changing Dimensions (SCD)
Gli attributi dimensionali cambiano nel tempo: un cliente cambia categoria, un prodotto viene riclassificato, un dipendente cambia reparto. La gestione di questi cambiamenti, le Slowly Changing Dimensions, è uno degli aspetti più complessi della modellazione dimensionale.
SCD Type 1, Sovrascrittura. Il valore precedente viene sovrascritto con il nuovo. Non si mantiene lo storico. Appropriato per correzioni di errori o attributi per cui lo storico non ha valore analitico (es. correzione di un errore di battitura nel nome del cliente) [1].
SCD Type 2, Versioning. Quando un attributo cambia, si crea una nuova riga nella dimensione con il nuovo valore, mantenendo la riga precedente con il valore originale. Ogni riga ha colonne valid_from e valid_to (o un flag is_current) che indicano il periodo di validità. Questo approccio consente analisi storiche accurate: le vendite del Q1 sono associate ai valori dimensionali vigenti nel Q1, non a quelli attuali [1]. In dbt, le SCD Type 2 sono implementate tramite il meccanismo di snapshot, che monitora le colonne specificate e genera automaticamente le versioni storiche con date di validità [3]. Il costo è la crescita dimensionale: una dimensione cliente con 10.000 clienti e SCD Type 2 su 3 attributi può raggiungere 30.000-50.000 righe in pochi anni.
SCD Type 3, Colonne aggiuntive. Si aggiungono colonne per il valore precedente e quello attuale (es. categoria_attuale, categoria_precedente). Consente un confronto binario (prima/dopo) ma non traccia l'intera cronologia. Raramente sufficiente in pratica, ma utile per scenari semplici con al massimo un cambio atteso [1].
SCD Type 6 (Hybrid). Convenzione informale (non parte del corpus Kimball originale, emersa nella community dei practitioner) che combina Type 1, 2 e 3: la riga più recente contiene sia il valore corrente sia quello storico, con versioning completo. Offre flessibilità analitica al costo di complessità implementativa significativa, ed è raramente adottato in pratica al di fuori di requisiti analitici molto specifici.
Varianti dello schema
Snowflake schema
Lo snowflake schema normalizza le dimensioni in sotto-tabelle: la dimensione prodotto viene suddivisa in tabella prodotto, tabella categoria e tabella sottocategoria, collegate da chiavi esterne. Questo riduce la ridondanza dei dati dimensionali ma aumenta il numero di join necessari per le query. Nei warehouse moderni con ottimizzatori di query avanzati, il vantaggio in termini di storage è trascurabile rispetto al costo in termini di complessità delle query e leggibilità dello schema [1]. Per questa ragione, lo snowflake schema è oggi meno utilizzato rispetto allo star schema, e la raccomandazione prevalente nella comunità dbt è di mantenere le dimensioni denormalizzate [3].
One Big Table (OBT)
L'approccio One Big Table porta la denormalizzazione all'estremo: fatti e dimensioni vengono pre-joinati in un'unica tabella larga. Per workload semplici (filtro su 1-3 dimensioni, aggregazioni dirette), l'OBT elimina completamente i join e può risultare più performante, specialmente su engine colonnari con caching aggressivo. Tuttavia, l'OBT perde efficienza quando le query richiedono il pruning su più di 2-3 dimensioni, i file di storage non possono essere partizionati e ordinati per tutte le combinazioni di filtro simultaneamente, e introduce ridondanza massiccia nei dati dimensionali, complicando la gestione degli aggiornamenti e delle SCD. Su storage colonnare, la ridondanza dimensionale ha un impatto di spazio limitato (grazie alla compressione), ma la complessità di manutenzione resta significativa [1].
Un approccio ibrido, adottato in alcune implementazioni, mantiene il dimensional modeling come struttura portante nel mart layer e produce OBT derivate nel consumption layer come viste materializzate ottimizzate per specifici pattern di query. Questo consente di mantenere la governance dimensionale (un'unica definizione di "cliente", "prodotto") senza sacrificare la semplicità di accesso per gli utenti BI, un compromesso architetturale il cui merito dipende dalla complessità delle query e dal numero di dimensioni effettivamente utilizzate in fase di consumo.
Data Vault 2.0
Data Vault 2.0, formalizzato da Dan Linstedt, è un approccio alla modellazione del data warehouse che separa le chiavi di business (Hub), le relazioni tra entità (Link) e gli attributi descrittivi con storico completo (Satellite) [6]. A differenza della modellazione dimensionale, Data Vault è progettato per la fase di integrazione dei dati, non per il consumo analitico diretto. In architetture ibride, Data Vault funge da raw vault (layer di integrazione e storicizzazione) mentre il layer di consumo adotta star schema per le query analitiche [6]. La complessità implementativa e la curva di apprendimento rendono Data Vault più adatto a organizzazioni con team di data engineering strutturati e requisiti di auditabilità stringenti, piuttosto che alle PMI dove la semplicità dello star schema è un vantaggio operativo.
Modellazione dimensionale nel modern data stack
L'adozione di warehouse cloud con storage e compute separati, e la diffusione di dbt come framework di trasformazione, hanno modificato le modalità di implementazione della modellazione dimensionale senza alterarne i principi fondamentali [3].
Grain declaration esplicita. In dbt, ogni model del mart layer dovrebbe dichiarare il proprio grain nella documentazione: "questo model ha una riga per ogni riga d'ordine, per ogni giorno, per ogni stabilimento". La dichiarazione del grain, centrale nella metodologia Kimball, diventa un test verificabile: un dbt test di unicità sulla combinazione delle chiavi che definiscono il grain verifica automaticamente che non esistano duplicati [3].
Surrogate key come hash. Nei warehouse cloud dove le sequence auto-incrementali non sono disponibili o efficienti, le surrogate key vengono generate come hash deterministici della business key (es. md5(concat(codice_cliente, source_system))). Pacchetti dbt come dbt-utils forniscono macro standard per la generazione di surrogate key [7].
SCD Type 2 con dbt snapshot. Il meccanismo di snapshot di dbt automatizza la gestione delle SCD Type 2: si definisce la tabella sorgente, le colonne da monitorare, e la strategia di rilevamento delle modifiche (check o timestamp). Ad ogni esecuzione dello snapshot, dbt confronta lo stato attuale con lo stato precedente e genera le righe di versioning con dbt_valid_from, dbt_valid_to e dbt_is_current [3].
Semantic layer come evoluzione delle dimensioni conformate. Il semantic layer (MetricFlow, Cube) estende il concetto di dimensione conformata al livello delle metriche: non solo le dimensioni sono condivise tra fact table, ma anche le definizioni di come le misure vengono aggregate. In un semantic model MetricFlow, le entità, dimensioni e misure dichiarate per un model dbt diventano i building block delle metriche, formalmente equivalenti alle dimensioni conformate e alle misure della metodologia Kimball, ma con un'interfaccia programmatica che consente il consumo da parte di strumenti BI, API e applicazioni AI [8].
Limiti e problemi aperti
La modellazione dimensionale presenta limitazioni note che è importante riconoscere nel contesto di una progettazione informata.
Rigidità dello schema. Lo star schema richiede decisioni architetturali anticipate (grain, dimensioni, misure) che sono costose da modificare una volta in produzione. Aggiungere una nuova dimensione a una fact table esistente richiede il backfill dello storico, operazione che può essere computazionalmente costosa e logicamente complessa [1].
Complessità delle SCD. Le SCD Type 2, pur essendo lo standard per la storicizzazione, introducono complessità nella scrittura delle query (join con filtro temporale per recuperare la versione corretta della dimensione) e nella gestione del volume dimensionale. Per dimensioni con alta volatilità (es. attributi CRM aggiornati frequentemente), la crescita delle righe può diventare significativa.
Inadeguatezza per dati semi-strutturati. Lo star schema è progettato per dati relazionali strutturati. Per dati JSON, log, eventi, dati IoT con schema variabile, la modellazione dimensionale richiede una fase di strutturazione preliminare che può essere un collo di bottiglia. Gli approcci basati su schema-on-read (Data Lake, Lakehouse con formati come Apache Iceberg) consentono di posticipare questa strutturazione, producendo il modello dimensionale come layer di consumo finale anziché come struttura di storage primaria [9].
Scalabilità organizzativa. In organizzazioni con molti team che producono dati, mantenere dimensioni conformate richiede governance centralizzata e processi di coordinamento che possono rallentare lo sviluppo. Il pattern dbt Mesh [10] affronta questo problema con model contracts e cross-project references, ma introduce complessità architetturale aggiuntiva.
Riferimenti
[1] R. Kimball, M. Ross, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd ed., Wiley, 2013.
[2] W. H. Inmon, Building the Data Warehouse, 4th ed., Wiley, 2005.
[3] dbt Labs, "Dimensional modeling in dbt," 2025. https://docs.getdbt.com/terms/dimensional-modeling
[4] D. Abadi et al., "The Design and Implementation of Modern Column-Oriented Database Systems," in Foundations and Trends in Databases, vol. 5, no. 3, 2013.
[5] dbt Labs, "How we structure our dbt projects," 2023. https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview
[6] D. Linstedt, M. Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0, Morgan Kaufmann, 2015.
[7] dbt Labs, "dbt-utils package," 2025. https://hub.getdbt.com/dbt-labs/dbt_utils/latest/
[8] dbt Labs, "About MetricFlow," 2025. https://docs.getdbt.com/docs/build/about-metricflow
[9] Apache Software Foundation, "Apache Iceberg Documentation," 2025. https://iceberg.apache.org/docs/latest/
[10] dbt Labs, "Intro to dbt Mesh," 2024. https://docs.getdbt.com/best-practices/how-we-mesh/mesh-1-intro
[11] Kimball Group, "Dimensional Modeling Techniques," 2013. https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/