Os dados brutos falam a língua dos sistemas de origem — customer_id, transact_date, amt. O negócio fala de clientes, de períodos, de faturamento. Entre esses dois mundos? Um fosso que gera confusão, erros, discussões intermináveis.
"O que é um cliente resiliente?" "Qual status usamos?" "Quem tem razão na definição?" Após três reuniões, você tem três respostas. O Gartner (2025) relata que dados mal alinhados causam 35% dos erros de interpretação. Um business glossary bem construído reduz em 50% essas idas e vindas.
As melhores equipes de dados em 2026 constroem tabelas intermediárias que são essa ponte — alinhadas com o vocabulário de negócio, reutilizáveis, testadas. É a arte de fazer os dados falarem a linguagem do negócio.
O fosso semântico: causa raiz invisível
Um exemplo concreto. A tabela bruta tem "status" com valores "ACTIVE", "INACTIVE", "DORMANT". O negócio quer "cliente resiliente". Qual filtro? Qual dos três? As discussões se multiplicam. Os relatórios dão números diferentes dependendo de quem solicitou.
É o fosso semântico. Os dados brutos são agnósticos ao negócio — eles refletem o sistema de origem, não a lógica business. As tabelas mal alinhadas causam caos e desconfiança. A camada intermediate do dbt é o lugar onde se cria esse glossário operacional: "um cliente resiliente" = "status = ACTIVE E sem interação há < 6 meses".
Uma vez definido, é reutilizável em todo lugar. Sem mais debate. Uma fonte de verdade.
Arquitetura: staged → intermediate → marts
As camadas do dbt se baseiam nessa hierarquia semântica.
Staging bruta (raw): transformação minimalista, renomeação das colunas do sistema de origem. Sem lógica de negócio.
Intermediate business: é onde se aplica a lógica de negócio, onde se criam os conceitos que importam para o business. Clientes resilientes. Pedidos de alto faturamento. Períodos de atividade. É aqui que se juntam as tabelas de origem, que se calculam os indicadores compostos, que se aplicam os filtros de negócio complexos.
Marts finais: prontos para BI, construídos por composição dos intermediários.
Vantagem: uma lógica de negócio complexa é definida apenas uma vez em intermediate, reutilizada por 10 marts finais. Sem essa camada, cada mart redefine a lógica. Caos garantido.
Convenções de nomenclatura: a base
Uma convenção clara guia o universo. Prefixos explícitos: is_ para booleanos (is_active), cnt_ para contagens (cnt_orders), amt_ para montantes (amt_revenue).
Nomes explícitos e de negócio: "customer_ltv" em vez de "cust_val". Sem abreviações crípticas. Sufixos de cálculo: _total para agregações, _flag para booleanos de segmentação.
Um business glossary documentado e centralizado (no dbt YAML ou em uma wiki) define cada termo de negócio e sua tradução técnica. "Faturamento" = "montante dos pedidos faturados no período, todas as categorias, excluindo descontos". Definição precisa, sem ambiguidade.
Quando todos falam a mesma linguagem, os erros de confusão estatísticos desaparecem.
Reutilizável e DRY
O princípio DRY aplicado aos dados: uma lógica de negócio = uma tabela intermediate. "Pedido de alto faturamento" = "montante total > 10.000". Definido uma vez, usado por 5 marts. Se a regra mudar, uma única modificação.
A camada intermediate reduz em 60% o número de tabelas finais necessárias pois elas compartilham componentes. Vantagem colateral: testes centralizados. Testar a lógica "cliente resiliente" uma vez em intermediate em vez de 5 vezes em marts finais. Os testes são herdados automaticamente.
É a economia de escala da modelagem de dados.
Self-service aumentado: quando negócios e intermediários se alinham
Com intermediários bem nomeados e documentados, o self-service se torna poderoso. Os usuários de negócio veem tabelas com nomes que compreendem — "customers_segments", "orders_monthly", "product_categories". Sem necessidade de tradutor de dados.
Os joins pré-definidos reduzem os erros. Uma pessoa do marketing pode criar um dashboard sem solicitar à equipe de dados 10 vezes para esclarecer a semântica. Os erros de query caem porque os dados falam a linguagem do negócio.
A documentação dos intermediários acelera a autonomização. É o verdadeiro self-service: empowerment pela clareza, não pela permissividade.
Iteração e evolução
O modelo de dados nunca é estático. O negócio evolui, novas segmentações emergem, métricas perdem relevância. A camada intermediate permite iterar rapidamente.
Adicionar uma coluna "is_premium_customer" em intermediate leva 1 dia e se torna imediatamente disponível para todos os marts dependentes. Sem intermediários, são 5 dias de coordenação entre marts incompatíveis.
Os feedbacks dos negócios são implementados em 2-3 sprints dbt em vez de 2-3 meses. A camada intermediate é a alavanca da agilidade do modelo de dados.
O coração da estratégia
Os intermediários não são uma camada técnica gratuita, são o coração da estratégia semântica. Quando os dados falam a linguagem do negócio, tudo se torna mais fluido — menos erros, mais autonomia para o negócio, manutenção reduzida.
É a arte de fazer os dados falarem a linguagem do negócio. E é operacional.
