Por que organizar dados em camadas não substitui uma boa modelagem de negócio
No dia 20 de agosto de 2026, realizamos um webinar dos Databricks User Groups sobre um tema cada vez mais importante: modelagem de dados na era dos agentes de dados.
O encontro foi organizado para o Databricks User Group Rio Grande do Sul, com retransmissão para o Databricks User Group Espírito Santo. As duas comunidades são lideradas por Vithor Silva aqui da DEX e têm como objetivo aproximar profissionais, estudantes e entusiastas interessados em dados, analytics e inteligência artificial para o ecossistema Databricks.
O ponto de partida da conversa foi uma dúvida comum em projetos modernos de dados: se já organizamos as informações nas camadas Bronze, Silver e Gold, ainda precisamos modelar os dados?
A resposta é sim. As camadas ajudam a organizar o fluxo de processamento e o nível de refinamento das informações, mas não definem, sozinhas, como o negócio funciona. Uma arquitetura de dados pode estar tecnicamente bem organizada e ainda assim ser difícil de entender, consultar e utilizar para tomar decisões.
O padrão de camadas é uma das formas mais conhecidas de estruturar um Lakehouse:
Essa separação traz benefícios importantes para a engenharia de dados, como rastreabilidade, reprocessamento e organização do pipeline. No entanto, ela não responde a perguntas essenciais para o negócio:
Essas respostas dependem de uma modelagem de negócio. Sem ela, a camada Gold pode se transformar em um conjunto de tabelas criadas para atender necessidades pontuais, com métricas duplicadas, regras divergentes e pouca reutilização.
Agentes de dados e interfaces em linguagem natural ampliam o acesso às informações. Um usuário pode fazer uma pergunta sem conhecer SQL, nomes técnicos de tabelas ou detalhes da implementação do pipeline.
Isso torna a modelagem ainda mais relevante. Quando um agente recebe uma pergunta, ele precisa encontrar dados com significado claro, relacionamentos coerentes e métricas que tenham definições confiáveis. Caso contrário, uma resposta bem escrita pode continuar sendo uma resposta errada.
Uma base preparada para agentes precisa oferecer mais do que colunas preenchidas. Ela deve apresentar:
Nesse cenário, modelar dados não é apenas preparar tabelas para um dashboard. É criar um contexto confiável para pessoas, ferramentas analíticas e agentes de IA.
Durante o webinar, exploramos três abordagens clássicas de modelagem e os contextos em que cada uma pode ser adequada.
O modelo dimensional de Ralph Kimball organiza os dados em tabelas fato e dimensão. Ele é bastante utilizado para analytics porque facilita a compreensão das informações e permite construir consultas orientadas às perguntas do negócio.
flowchart LR
F[Fato de vendas] --> C[Dimensão cliente]
F --> P[Dimensão produto]
F --> T[Dimensão tempo]
F --> L[Dimensão loja]
F --> A[Análises e dashboards]
Kimball: fatos conectados a dimensões para facilitar o consumo analítico.
Em um modelo de vendas, por exemplo, uma tabela fato pode registrar cada item vendido, enquanto dimensões representam cliente, produto, loja e tempo. Essa estrutura ajuda a manter a granularidade clara e facilita a criação de métricas consistentes.
Para agentes de dados, a simplicidade conceitual do modelo dimensional pode ser uma vantagem. As relações entre fatos e dimensões tendem a ser mais fáceis de explicar, documentar e utilizar em perguntas analíticas.
A abordagem associada a Bill Inmon prioriza um modelo corporativo integrado, normalmente mais normalizado, a partir do qual diferentes visões e estruturas de consumo podem ser derivadas.
flowchart LR
ERP[ERP] --> I[Modelo corporativo integrado]
CRM[CRM] --> I
RH[RH] --> I
I --> V1[Data mart comercial]
I --> V2[Data mart financeiro]
I --> V3[Data mart pessoas]
Inmon: uma base corporativa integrada que alimenta visões específicas por domínio.
Essa estratégia pode ser útil quando a organização precisa consolidar definições comuns entre áreas e construir uma base integrada para diferentes domínios. O desafio está no esforço inicial de levantamento, integração e governança.
O Data Vault separa elementos como hubs, links e satellites para preservar o histórico e acomodar a evolução das fontes de dados. Essa abordagem é especialmente interessante em ambientes nos quais os sistemas de origem mudam com frequência ou em que a rastreabilidade das alterações é uma prioridade.
flowchart TB
H1((Hub cliente)) --- L((Link compra)) --- H2((Hub produto))
H1 --> S1[Satellite cliente]
L --> S2[Satellite compra]
H2 --> S3[Satellite produto]
S1 --> H[Histórico e rastreabilidade]
S2 --> H
S3 --> H
Data Vault: hubs, links e satellites preservam relações e histórico das mudanças.
Como em qualquer arquitetura, o Data Vault não deve ser aplicado apenas por tendência. É preciso avaliar a capacidade da equipe, o nível de histórico necessário, os padrões de consumo e a complexidade que será apresentada às camadas analíticas e aos agentes.
Os diagramas ajudam a visualizar a principal diferença de foco entre as abordagens:
| Abordagem | Foco principal | Estrutura mais visível | Boa escolha quando |
|---|---|---|---|
| Kimball | Consumo analítico | Fatos e dimensões | A prioridade é facilitar consultas, métricas e dashboards |
| Inmon | Integração corporativa | Modelo integrado e normalizado | A organização precisa consolidar definições entre áreas |
| Data Vault | Histórico e evolução | Hubs, links e satellites | As fontes mudam muito e a rastreabilidade é essencial |
Não existe uma única técnica correta para todos os projetos. A escolha depende de fatores como:
Também é possível combinar abordagens. Uma organização pode usar Data Vault para integração e histórico, por exemplo, e disponibilizar modelos dimensionais para consumo analítico. O mais importante é manter claras as responsabilidades de cada camada e evitar que a complexidade técnica chegue sem tratamento ao usuário final.
Outro ponto central do webinar foi a diferença entre disponibilizar uma tabela e construir um produto de dados.
Uma tabela pode existir, estar atualizada e ainda não ser útil para o negócio. Um produto de dados precisa ter propósito, consumidores identificados, documentação, qualidade observável e alguém responsável por sua evolução.
Na prática, isso significa responder a perguntas como:
Essa visão é especialmente importante quando agentes de dados passam a utilizar os produtos como fonte de respostas. O agente precisa saber não apenas onde encontrar uma coluna, mas também quando aquela informação é válida, qual regra deve ser aplicada e quais limitações precisam ser consideradas.
Com base nos pontos discutidos, uma evolução possível pode seguir estas etapas:
O objetivo não é criar uma modelagem perfeita antes de entregar qualquer valor. É construir uma base suficientemente clara, governada e evolutiva para que novas experiências de dados possam ser desenvolvidas com confiança.
O webinar também reforçou o papel dos User Groups na troca de experiências. Ao reunir comunidades do Rio Grande do Sul e do Espírito Santo, ampliamos a conversa para além de uma única região e criamos espaço para perguntas, exemplos e diferentes perspectivas sobre arquitetura de dados.
Esse tipo de encontro é importante porque modelagem não é apenas uma decisão de ferramenta. É uma disciplina que envolve negócio, engenharia, analytics, governança e, cada vez mais, inteligência artificial.
Na era dos agentes de dados, a modelagem não perdeu relevância — ela se tornou ainda mais visível.
Camadas Bronze, Silver e Gold organizam o caminho dos dados, mas não substituem a compreensão do negócio. Kimball, Inmon e Data Vault oferecem estratégias diferentes para lidar com análise, integração e histórico. A melhor escolha é aquela que atende ao contexto da organização e consegue transformar dados em produtos confiáveis.
Agentes podem facilitar o acesso às informações, mas dependem de dados bem definidos, relacionamentos coerentes, métricas padronizadas e metadados de qualidade. Antes de perguntar se um agente consegue responder, precisamos garantir que a organização sabe qual é a resposta correta.
Confira a gravação completa do webinar no YouTube:
Se você participou, compartilhe nos comentários quais desafios de modelagem sua equipe enfrenta ao preparar dados para analytics e agentes de IA.