Star Schema ou One Big Table (OBT): qual usar no seu Data Warehouse?
O OBT elimina JOINs na consulta, mas não é um substituto do Star Schema. Entenda quando cada modelo faz sentido e por que a ferramenta de BI acaba reconstruindo fato e dimensão de qualquer forma.
O One Big Table (OBT), ou 'tabelão', é uma técnica de desnormalização que junta fato e dimensões em uma única tabela wide, eliminando JOINs no momento da consulta. É um assunto que gera bastante discussão na comunidade de dados, mas a recomendação padrão continua sendo o Star Schema (Kimball): o OBT é uma exceção pontual, avaliada em conjunto entre engenharia e análise de dados, e não um substituto.
Tecnicamente, a boa prática é sempre construir a OBT a partir de um Star Schema já validado — nunca direto do dado bruto — materializando o resultado do JOIN uma única vez, na escrita, em vez de pagar esse custo a cada leitura. Isso se encaixa naturalmente na arquitetura Medallion: o Star Schema vive na camada Silver, e a OBT, quando realmente necessária, é derivada dele na camada Gold.
O ponto mais importante, porém, é o que acontece na ferramenta de visualização: ao conectar uma OBT no Power BI, Tableau ou Metabase, o analista precisa reclassificar as colunas em métricas e atributos — ou seja, a ferramenta reconstrói um Star Schema conceitual por dentro, só que de forma implícita e sem a governança que o modelo original já oferecia. Por isso, na Maraca Hub, mantemos o Star Schema como padrão de projeto e tratamos o OBT como uma decisão de arquitetura, não como atalho de conveniência.
Star Schema or One Big Table (OBT): which one should you use?
OBT removes JOINs at query time, but it isn't a Star Schema replacement. Understand when each model makes sense — and why your BI tool ends up rebuilding fact and dimension anyway.
One Big Table (OBT) is a denormalization technique that merges fact and dimension tables into a single wide table, removing JOINs at query time. It's a topic that sparks plenty of debate in the data community, but the standard recommendation remains the Star Schema (Kimball): OBT is a targeted exception, evaluated jointly by engineering and analytics, not a replacement.
Technically, best practice is to always build the OBT from an already validated Star Schema — never straight from raw data — materializing the JOIN result once, at write time, instead of paying that cost on every read. This fits naturally into a Medallion architecture: the Star Schema lives in the Silver layer, and the OBT, when truly needed, is derived from it in Gold.
The most important point, though, is what happens in the visualization tool: when you connect an OBT to Power BI, Tableau or Metabase, the analyst still has to reclassify columns into metrics and attributes — the tool rebuilds a conceptual Star Schema internally, just implicitly and without the governance the original model already provided. That's why at Maraca Hub we keep the Star Schema as the project default and treat OBT as an architecture decision, not a convenience shortcut.