OBT o modellazione dimensionale: quale modello di dati scegliere?

One Big Table, spesso abbreviato in OBT, è un approccio alla modellazione dati che appiattisce fatti e dimensioni in un'unica tabella larga, eliminando i join, per massimizzare le performance di scansione nei data warehouse colonnari moderni. Invece di interrogare una tabella dei fatti e collegarla a più tabelle di dimensione, una query legge una sola tabella già arricchita con tutti gli attributi che servono. La modellazione dimensionale classica, lo star schema di Kimball, fa l'opposto per scelta: separa con cura fatti e dimensioni condivise, così da preservare la storia delle slowly changing dimensions, la governance dei dati e il riuso delle stesse definizioni tra domini diversi. La scelta non riguarda solo le prestazioni: cambia anche dove vive la logica di business, se concentrata in poche dimensioni condivise o distribuita, e potenzialmente duplicata, in più tabelle larghe. Il vantaggio dell'OBT dipende dal motore: le piattaforme cloud-native colonnari tollerano i join molto meglio dei sistemi row-oriented da cui questo dibattito è nato.

Leggi anche: Star schema · Modello dimensionale con una tabella dei fatti centrale collegata a tabelle di dimensione: lo schema sotto la maggior parte delle dashboard BI.

Perché il dibattito è emerso ora

Per anni i join erano il vero collo di bottiglia delle query analitiche, motivo per cui lo star schema, con i suoi join minimi e ben definiti, è rimasto lo standard per decenni. Le piattaforme cloud-native colonnari, come Databricks, rendono oggi i join molto meno penalizzanti di un tempo, riducendo uno dei motivi tecnici storici per separare fatti e dimensioni. Allo stesso tempo, i feature store per il machine learning e gli agenti AI preferiscono sempre più un accesso ai dati piatto e senza join, perché è più semplice da servire a un modello o a un sistema di retrieval. Questa combinazione ha spinto molti team verso l'OBT, soprattutto negli ultimi anni.

La posizione pragmatica del settore

Non è, nella pratica, una scelta assoluta tra i due. Come descrive un'analisi di Brooklyn Data, molti team pratici costruiscono modelli OBT sopra un modello dimensionale esistente: così ottengono il riuso e la governance del dimensionale a monte, e la velocità di query dell'OBT a valle, per i casi d'uso che la richiedono davvero. I due approcci convivono perché risolvono problemi diversi, non sono in competizione per lo stesso strato dell'architettura dati.

Quando scegliere cosa

L'OBT ha senso per dashboard self-service ad alte performance o per il feature engineering nel machine learning, dove la velocità di lettura conta più della flessibilità. La modellazione dimensionale resta preferibile quando serve riuso tra tanti report diversi, storicizzazione accurata delle dimensioni, e governance centralizzata delle metriche condivise tra i reparti.

Perché conta per la tua azienda

La scelta tra OBT e modellazione dimensionale, come per lo star schema, impatta sia le performance delle query sia quanto la logica di business resta centralizzata o finisce duplicata in più tabelle larghe: un semantic layer ben progettato aiuta a mantenere le definizioni condivise, qualunque sia il modello fisico scelto sotto di esso.