Modelação e engenharia analítica

Modelação de dados

Medidas que reconciliam ao cêntimo. A diferença entre um relatório em que se confia e um relatório que se confere está quase sempre no modelo, não no visual.

Leitura de 6 minutos

Falta um milhão e ninguém sabe onde

O relatório apresenta 1.248.000 de vendas. O ERP apresenta 1.249.100. A diferença é pequena — cerca de um por mil — e é exatamente por isso que é perigosa: não chama a atenção, mas destrói a confiança quando alguém a descobre em reunião.

Na esmagadora maioria dos casos, essa diferença tem uma de cinco causas, todas estruturais e todas detetáveis antes da publicação.

Um modelo correto não é o que produz o número certo hoje. É o que impede que o número errado seja possível.

O modelo estrela

Uma tabela de factos ao centro, com os acontecimentos do negócio a uma granularidade declarada. À volta, dimensões que descrevem esses acontecimentos. Relações de um-para-muitos, todas na mesma direção.

Dim Calendário
  • Data (chave)
  • Ano, trimestre, mês
  • Dia útil, feriado
Dim Produto
  • Código (chave)
  • Família, subfamília
  • Marca, fornecedor
Facto Vendas
  • Grão: uma linha por linha de documento
  • Quantidade, valor, custo
  • Chaves: data, produto, loja, cliente
Dim Loja
  • Código (chave)
  • Província, tipologia
  • Data de abertura
Dim Cliente
  • Código (chave)
  • Segmento, canal
  • Condições comerciais

A frase "uma linha por linha de documento" é a decisão mais importante de todo o modelo. Tudo o resto — relações, medidas, reconciliação — decorre dela.

Porquê estrela e não outra coisa

AbordagemVantagemCusto
Tabela única e plana Simples de construir; familiar a quem vem do Excel Repete descrições em milhões de linhas, ocupa memória, impede filtros cruzados coerentes
Modelo estrela Filtros previsíveis, compressão eficiente, medidas reutilizáveis entre relatórios Exige trabalho prévio de preparação das dimensões
Floco de neve Evita redundância nas dimensões; próximo do modelo relacional de origem Mais saltos de relação, consultas mais lentas, leitura mais difícil para o utilizador
Relações muitos-para-muitos Resolve casos legítimos como orçamentos a granularidade diferente Ambiguidade de filtro e totais que não somam se usada por conveniência

Recomendação: estrela por defeito. Floco de neve apenas quando a dimensão é genuinamente enorme; muitos-para-muitos apenas quando a diferença de granularidade é real e documentada.

As cinco causas de um total que não bate

  • Chaves órfãs. Linhas de factos cujo código não existe na dimensão vão para a categoria em branco e desaparecem de qualquer visual filtrado por essa dimensão. É a causa mais frequente.
  • Granularidade misturada. Valores de cabeçalho de documento — descontos globais, portes — repetidos nas linhas inflacionam qualquer soma.
  • Filtro bidirecional. Ativado para resolver um caso pontual, altera silenciosamente o resultado de outras medidas do modelo.
  • Arredondamento na linha errada. Arredondar por linha e somar dá resultado diferente de somar e arredondar. Em milhões de linhas, a diferença torna-se visível.
  • Critério temporal divergente. Data do documento, data de entrega ou data de lançamento contabilístico produzem três totais legítimos e diferentes.

Regras que aplicamos em todos os modelos

  • Granularidade escrita. Uma frase por tabela de factos, na documentação e no comentário da consulta.
  • Calendário próprio e contínuo. Marcado como tabela de datas, sem lacunas, com colunas de calendário fiscal quando aplicável.
  • Relações unidirecionais. Bidirecional apenas com justificação documentada.
  • Medidas explícitas. Nunca arrastar colunas numéricas para os visuais. Cada indicador é uma medida nomeada, com variáveis para legibilidade e para evitar recálculos.
  • Colunas calculadas com parcimónia. O que for possível calcular na origem ou no Power Query fica fora do modelo: ocupa menos memória e comprime melhor.
  • Reconciliação como teste. Uma página de controlo que compara os totais do modelo com os totais da origem, por mês, e que se verifica antes de cada publicação.

Desempenho é consequência, não afinação

Relatórios lentos raramente se resolvem com ajustes de visual. Resolvem-se a montante: reduzir a cardinalidade das colunas, remover colunas que ninguém usa, tratar datas e horas em campos separados, evitar medidas que percorrem a tabela de factos linha a linha quando existe uma alternativa agregada.

Um modelo bem desenhado costuma ocupar menos de metade da memória do modelo original e responder várias vezes mais depressa — com os mesmos dados e a mesma ferramenta.

Os seus relatórios reconciliam com o ERP?

Auditamos o modelo existente — granularidade, relações, medidas e consumo de memória — e entregamos o plano de correção com as diferenças já identificadas e quantificadas.

Falar com a DAXIS