Modelo semântico e ETL sobre Protheus: por que dashboards precisam de base auditável

Publicado pela Erpworks · 23/07/2026

Boa parte dos problemas de BI que aparecem em empresas com Protheus não estão na ferramenta de visualização. Estão em uma camada anterior, menos visível, que costuma ser tratada como "detalhe técnico": a construção do modelo semântico e do ETL que alimentam os dashboards.

Boa parte dos problemas de BI que aparecem em empresas com Protheus não estão na ferramenta de visualização. Estão em uma camada anterior, menos visível, que costuma ser tratada como "detalhe técnico": a construção do modelo semântico e do ETL que alimentam os dashboards.

Este artigo aprofunda essa camada. Explica o que é modelo semântico, o que é ETL sobre Protheus, quais são os riscos de puxar dados brutos direto do banco e por que auditabilidade é característica não negociável em ambientes de BI Executivo.

O público-alvo aqui é técnico. CIO, gerente de TI, analista de BI, controlle com formação técnica. É uma leitura que exige familiaridade com estrutura de dados e vocabulário de arquitetura analítica, e não vai simplificar por conta desse recorte.

O que é modelo semântico e por que ele existe

O modelo semântico é a camada que traduz estrutura técnica de dados em vocabulário de negócio. É onde tabelas viram entidades, campos viram atributos, joins viram relações e cálculos viram indicadores nomeados.

Um exemplo prático dentro do Protheus ajuda a situar. A tabela SF3 armazena movimentações fiscais. A tabela SD2 armazena itens de nota fiscal de saída. A tabela SA1 armazena clientes. Um analista técnico que precisa calcular receita por cliente sabe que precisa juntar essas tabelas com critérios específicos, aplicar filtros de tipo de operação, excluir devoluções, considerar apenas notas efetivadas e assim por diante.

Sem modelo semântico, cada nova análise refaz esse trabalho. Cada dashboard tem sua própria versão do cálculo. Cada relatório recupera "receita" de um jeito ligeiramente diferente. As diferenças, quando aparecem, geram desconfiança e retrabalho.

Com modelo semântico, o conceito "receita por cliente" é definido uma única vez, com regras claras. Cada análise que precisa desse indicador consulta essa definição. Se a regra mudar, muda em um único lugar. Se aparecer divergência, existe fonte única de verdade contra a qual comparar.

Componentes principais de um modelo semântico maduro:

Entidades de negócio. Cliente, fornecedor, produto, serviço, nota fiscal, movimentação, período, unidade de negócio. Cada entidade tem atributos e chaves que a identificam.

Métricas nomeadas. Receita bruta, receita líquida, margem bruta, EBITDA, fluxo de caixa, DSO, DPO. Cada métrica com definição escrita, regra de cálculo, exclusões e responsável pela definição.

Hierarquias. Como as entidades se organizam para navegação analítica. Produto pertence a categoria, que pertence a família. Cliente pertence a segmento, que pertence a região. Sem hierarquia clara, drill down vira confuso.

Vocabulário. Nome dos campos e das métricas em linguagem que a área de negócio reconhece. "Valor total da nota" é técnico. "Receita bruta com impostos" é semântico.

Regras de negócio. Como cada métrica é calculada. Quais operações são consideradas. Quais são excluídas. Como se comportam devoluções, cancelamentos, ajustes, transferências.

O modelo semântico é o ativo mais valioso da arquitetura analítica de uma empresa. Ele é o que garante que "receita" signifique a mesma coisa para todo mundo.

ETL sobre Protheus: extração, transformação, carga

ETL é o processo que move dados da fonte para a camada analítica. Extract, transform, load. No contexto Protheus, essa sequência tem particularidades:

Extração. A leitura dos dados a partir do ambiente Protheus. Envolve decisões sobre método (leitura direta, replicação, API), sobre janela (batch periódico, near real-time, streaming), sobre volume (delta, full load), sobre impacto no ambiente produtivo.

Ler direto do banco produtivo é possível tecnicamente mas envolve risco de performance e concorrência com a operação. A escolha da estratégia depende do porte do ambiente, da carga transacional e da criticidade das rotinas online.

Transformação. O tratamento dos dados extraídos até o formato adequado para análise. Inclui padronização de tipos, tratamento de nulos, aplicação de regras de negócio, cálculos derivados, agrupamentos, denormalização quando necessária.

A transformação é onde o vocabulário do negócio começa a aparecer. Um campo D2_VALLIQ vira "receita líquida do item". Uma soma condicional vira "receita líquida com filtro de operações válidas". As regras aplicadas aqui precisam estar documentadas e alinhadas com o modelo semântico.

Carga. A gravação dos dados transformados na estrutura analítica. Pode ser um data warehouse relacional, um data lake com formatos analíticos, um cubo OLAP ou uma combinação. A escolha depende do volume, do padrão de consulta e das ferramentas envolvidas.

Cada uma dessas etapas tem armadilhas próprias. Extrações mal desenhadas afetam produção. Transformações inconsistentes produzem indicadores errados. Cargas sem controle de erro deixam a camada analítica em estado inconsistente sem que ninguém perceba.

Riscos de puxar dados brutos direto do banco

Um padrão que aparece em empresas sem arquitetura analítica é o "puxa direto". Um analista abre acesso ao banco do Protheus, escreve SQL que junta as tabelas necessárias, conecta o Power BI direto e monta o dashboard. Funciona rapidamente. Entrega valor no curto prazo. Cria dívida técnica que aparece com o tempo.

Os riscos principais:

Performance. Consultas analíticas sobre o banco produtivo concorrem com a operação transacional. Em cenários de volume, isso pode degradar o desempenho do próprio Protheus, com impacto direto no dia a dia dos usuários.

Falta de camada semântica. Cada dashboard precisa reimplementar as regras de negócio. Quando a definição de "receita" muda, é preciso caçar todos os dashboards que calculam receita e alterar cada um individualmente. Isso raramente acontece com sucesso.

Divergências entre dashboards. Como cada análise é feita de forma independente, é natural que apareçam variações. Um dashboard exclui devoluções de uma forma, outro de outra. Um considera nota emitida, outro considera nota efetivada. Chega uma reunião em que dois indicadores com o mesmo nome mostram valores diferentes.

Dependência de conhecimento tácito. As regras aplicadas ficam distribuídas em queries individuais. Quando o analista sai, o conhecimento sai junto. O próximo analista precisa reconstruir a lógica antes de conseguir manter os dashboards.

Ausência de rastreabilidade. Quando aparece divergência, investigar é caro. Precisa entrar no dashboard, ler a query, entender as regras, comparar com o Protheus original. Nada disso está documentado.

Risco de mudança estrutural. Se um upgrade do Protheus altera estrutura de tabela ou nome de campo, todas as queries podem quebrar simultaneamente. Sem camada intermediária que isola essa mudança, o impacto é generalizado.

Segurança e controle de acesso. Acesso direto ao banco significa que qualquer alteração de regra de segurança precisa acompanhar múltiplas conexões. A gestão fica complexa e propensa a erro.

O conjunto desses riscos é motivo suficiente para investir em arquitetura de dados intermediária, mesmo em ambientes que ainda estão no início do trabalho de BI. O custo de fazer certo desde o começo é sempre menor do que o custo de refazer depois.

Auditoria e rastreabilidade dos indicadores

Auditabilidade é característica que separa BI executivo maduro de vitrine visual. Um indicador auditável responde três perguntas objetivamente:

1. De onde vieram os dados?
2. Que regras foram aplicadas?
3. Como o cálculo pode ser reproduzido?

Se essas três perguntas não têm resposta rápida e documentada, o indicador não é auditável. Pode estar certo. Pode estar errado. Não há como saber sem investigação.

Auditoria de indicadores exige:

Documentação da origem. Cada indicador tem lista de tabelas e campos que o alimentam, com procedência clara desde o Protheus até o dashboard.

Documentação das regras. Cada transformação aplicada tem descrição escrita. Quais operações são consideradas. Quais são excluídas. Como se comportam cenários específicos.

Versionamento. Definições evoluem. Métricas podem mudar de cálculo ao longo do tempo. O histórico dessas mudanças precisa ficar registrado para que análises antigas possam ser comparadas com análises novas de forma justa.

Amostras validadas. Cada indicador precisa ter um conjunto de amostras conhecidas, com valor esperado, que podem ser usadas como referência. Se o cálculo mudar sem intenção, essas amostras acusam.

Trilha de execução. As cargas de ETL geram log estruturado do que foi processado, quando, com quais critérios e com quais resultados. Investigar um problema fica mais fácil quando há histórico rastreável.

Responsáveis. Cada indicador tem um responsável nomeado pela definição de negócio e um responsável técnico pela implementação. Sem esses papéis, mudanças acontecem sem coordenação.

Empresas que operam sem essa auditabilidade convivem com desconforto continuado. Cada apresentação de resultado envolve alguma dúvida sobre número. Cada reunião de comitê traz "vamos checar depois". Cada investigação de divergência gasta tempo desproporcional. A ausência de auditabilidade é imposto invisível que a empresa paga em produtividade.

Governança do modelo semântico

Modelo semântico maduro não é apenas um artefato técnico. É objeto de governança contínua. Envolve pessoas, processos e ferramentas para que se mantenha íntegro ao longo do tempo.

Comitê de indicadores. Grupo com representantes das áreas de negócio e da equipe técnica que discute e valida definições de indicadores estratégicos. Sem esse fórum, cada área define o seu, e o vocabulário se fragmenta.

Processo de mudança. Toda alteração em métrica ou entidade passa por fluxo formal. Solicitação, análise de impacto, aprovação, implementação, validação, comunicação. Mudanças informais são fonte comum de indicadores errados.

Catálogo de dados. Ferramenta ou repositório onde todo o modelo semântico está documentado, acessível e pesquisável. Um analista novo precisa poder consultar o catálogo e entender o vocabulário sem depender de conversa com veterano.

Testes automatizados. Rotinas que verificam a integridade do modelo periodicamente. Se uma métrica passa a apresentar valor fora de faixa esperada, alerta é gerado antes que apareça em reunião de diretoria.

Ciclo de revisão. Modelo semântico envelhece. Áreas mudam, produtos evoluem, regras contábeis são atualizadas. Sem revisão periódica, o modelo vai se descolar da realidade da operação.

Ferramentas comuns e escolhas de arquitetura

A escolha de ferramentas para modelo semântico e ETL sobre Protheus depende de vários fatores. Uma leitura resumida:

Ferramentas de ETL/ELT. Talend, SSIS, Airflow, Fivetran, Azure Data Factory, dbt e ferramentas nativas de plataformas de nuvem. Cada uma tem trade-offs de curva de aprendizado, custo, capacidade e integração com o ecossistema existente.

Armazenamento analítico. Data warehouses relacionais como SQL Server, Oracle, Snowflake, BigQuery. Data lakes com formatos como Parquet, Delta, Iceberg. Combinações como lakehouse. A escolha depende do volume, do padrão de consulta e da estratégia de nuvem da empresa.

Camadas semânticas dedicadas. Ferramentas como Cube.js, Looker (com LookML), dbt (com modelos e testes) atuam especificamente na definição de modelo semântico. Podem existir de forma independente da ferramenta de visualização.

Ferramentas de visualização. Power BI, Qlik Sense, Tableau, Looker. Cada uma com forças próprias e integração melhor ou pior com camadas semânticas específicas.

A recomendação universal é escolher com base em contexto real da empresa, não com base em preferência da equipe ou moda de mercado. Um projeto que usa a ferramenta certa para o cenário errado consome mais tempo do que um projeto que usa ferramenta convencional em cenário adequado.

FAQ

Modelo semântico é obrigatório para BI sobre Protheus funcionar?

Não é obrigatório no sentido de o BI conseguir apresentar algum número sem ele. É praticamente obrigatório no sentido de o BI ser confiável e sustentável ao longo do tempo. Ambientes que operam sem modelo semântico convivem com divergências continuadas e custo de manutenção alto.

Posso usar as próprias medidas do Power BI como modelo semântico?

Parcialmente. Ferramentas como Power BI têm capacidade de modelagem interna razoável, e projetos menores podem operar com modelo semântico definido dentro da própria ferramenta. À medida que o volume de dashboards cresce e o número de fontes aumenta, a manutenção fica difícil. Empresas com escala maior costumam separar a camada semântica da ferramenta de visualização.

ETL é a mesma coisa que ELT?

ETL (Extract, Transform, Load) e ELT (Extract, Load, Transform) são estratégias diferentes de organização do processo. Em ETL, a transformação acontece antes da carga. Em ELT, os dados são carregados primeiro e transformados dentro da própria camada analítica. Ambientes modernos, especialmente em nuvem, usam ELT com frequência. A escolha depende da arquitetura e das ferramentas envolvidas.

Como saber se preciso de camada de tratamento entre o Protheus e o BI?

Alguns indicadores ajudam: dashboards que quebram quando algo muda no Protheus, divergências entre indicadores, dificuldade de explicar cálculo, tempo alto para responder pergunta nova, ausência de rastreabilidade de origem. Se pelo menos dois desses sinais aparecem, camada de tratamento adiciona valor.

Consultoria especializada em Protheus consegue ajudar em projeto de BI?

Depende do escopo. Modelo semântico sobre Protheus se beneficia muito de conhecimento profundo do ERP. Consultorias que conhecem as tabelas críticas, as particularidades dos módulos e o vocabulário fiscal e contábil chegam mais rápido no resultado. Consultorias generalistas de BI podem entregar arquitetura, mas costumam demorar mais tempo para dominar a camada Protheus.

Como conviver com mudanças estruturais do Protheus, como upgrades de release?

A camada de ETL bem construída absorve mudanças estruturais em ponto único. Quando um campo muda de nome ou uma tabela ganha estrutura nova, o ajuste é feito na camada de extração e não se propaga automaticamente para todos os dashboards. É uma das razões principais para não conectar ferramentas de visualização direto ao banco produtivo.

Qual o esforço para reconstruir BI existente com essa arquitetura?

Depende do estado atual, do número de dashboards em produção e do porte da empresa. Reconstrução completa costuma ser trabalho de meses. Uma estratégia mais comum é reconstruir aos poucos, começando pelos indicadores mais estratégicos, e ir migrando dashboards à medida que a camada semântica cobre novos temas.

Conclusão

Modelo semântico e ETL são componentes que definem a confiabilidade do BI Executivo sobre Protheus. Ambientes que investem nessas camadas convivem com indicadores auditáveis, com governança de mudança e com capacidade de responder perguntas novas sem retrabalho. Ambientes que ignoram essas camadas pagam custo continuado em divergências, retrabalho e desconfiança.

O caminho maduro passa por decisões técnicas que exigem experiência em Protheus e em arquitetura de dados. Não são projetos que se resolvem rapidamente, mas os que investem cedo colhem resultados que se acumulam ao longo dos anos.

CTA

A Erpworks projeta e opera camadas semânticas e ETL sobre Protheus para ambientes de BI Executivo, com foco em auditabilidade, governança e sustentabilidade. Para conversar sobre o cenário do seu ambiente, entre em contato.

Links internos sugeridos (uso interno)

• Página de solução: Inteligência de Dados e BI Executivo

• Artigo 07: BI Executivo sobre Protheus: as três camadas

• Artigo 05: Governança do ambiente Protheus

• Artigo 06: Atualização de release Protheus