Melhores Práticas para Modelagem de Dados Tabular

O processo de fazer a modelagem de dados para um cubo tabular envolve principalmente identificar o escopo do negócio para extrair o real significado por traz dos dados que evidenciam a situação de um processo de negócio. Neste primeiro momento a preocupação fica restrita a encontrar os limites que definem o assunto que o modelo de dados busca suportar. Superando essa fase, iniciamos um estágio mais técnico, onde algumas configurações precisam ser realizadas para garantir um modelo de dados mais eficiente.

A primeira e mais importante recomendação é: buscar a desmoralização das dimensões e a criação de um modelo estrela. Isso é importante porque resulta em um modelo mais simples, tanto para o usuário navegar entre os atributos quanto para o desenvolvedor criar as medidas em DAX. Entre outras práticas não menos importantes estão:

Não trazer chaves primárias ou colunas date/time com horário para o modelo, se for necessário utilizar o horário, separar em outra coluna. Isso aumenta o tamanho do modelo significativamente por causa do método de armazenamento colunar do Power BI.

Desabilitar a opção auto date/time do Power BI. Essa opção que cria internamente tabelas com intervalos de Datas, máximo e mínimo para cada coluna de data do modelo, caso uma das colunas esteja com uma data muito antiga, as tabelas de datas irão impactar no tamanho da base de dados sem necessidade. 

Crie sempre a sua própria tabela de datas: Existe diversas formas de criar sua própria tabela com intervalos de datas contínuos. Pode ser via script sql, por um arquivo em excel, usando a linguagem M no Power Query ou usando DAX. O ponto importante aqui é garantir que ela atenda 100% dos intervalos de datas do seu modelo e tenha o ano completo, começando no primeiro dia do primeiro ano e terminando no último dia do maior ano. Isso é importante para o funcionamento das funções de tempo.

Remover todas as colunas não utilizadas: Manter no modelo apenas o que for usado para análise e relacionamento, ou seja, idealmente o modelo deve ter apenas chaves estrangeiras e colunas utilizadas em medidas na tabela de fatos. Nas dimensões, apenas os atributos utilizados para análise.

Não criar colunas calculadas apenas para suportar um cálculo de uma medida, utilize ou funções iterativas e variáveis. Isso é importante porque cada nova coluna calculada criada o modelo de dados precisam ser  pré-processados, prejudicando a performance do modelo.

Oculte todas as chaves estrangeiras: A princípio a única função delas é manter o relacionamento, por isso, não deixe que elas fiquem visíveis.

Definir corretamente os tipos de dados para cada atributo: Não utilize decimal quando não for necessário. Defina para colunas de localização como município, estados, lat-long, as categorias corretas.

Não utilize as colunas numéricas para fazer a agregações. Crie sempre uma medida, isso é importante porque alguns recursos como transição de contexto em colunas calculadas, ou o recurso calculation groups não funcionam a menos que inclua a coluna dentro de uma função calculate. Mas se for usar as colunas numéricas para agregação, define previamente todas as formas de sumarização e desabilite a agregação para colunas numéricas como ano que não precisam.

Não utilize relacionamento bidirecional. Esse tipo de relacionamento pode causar referência circular no modelo. Esse tipo de relacionamento físico também impacta na forma como o conceito de tabelas expandidas funciona. Para contornar isso e fazer uma medida receber um filtro que não está chegando por falta de relacionamento bidirecional, use o modificador de contexto CROSSFILTER. 

Identifique se existem chaves na tabela de fatos que não possuem valor correspondente nas dimensões. Apesar do Power BI fazer o tratamento destes casos adicionando um valor Blank na dimensão, isso pode gerar distorções quando usamos a funções VALUES ou DISTINCT, ou dúvidas quando o atributo é usado como slice.

Use sempre a função DIVIDE para evitar erros quando houver divisões por Zero.

Utilize nomes claros para atributos. Os nomes padronizados e autoexplicativos podem melhorar muito a experiência de construção e análise do modelo.

Estas são apenas algumas das muitas coisas que podemos fazer para melhorar a experiência de análise e construção de modelos tabular.

Power BI é Simples, Mas Será que é Fácil?

Há alguns anos, falar de BI não era tão simples, explicar o conceito, diferenciar as tecnologias de BI dos relatórios operacionais, justificar o valor para o cliente, engajar ele em um processo de coleta e tratamento cuidadoso dos dados nem sempre era uma tarefa simples. Tudo isso parece estar mudando muito rápido, depois que a Microsoft apostou na centralização dos produtos de BI (antes pulverizados em add-ons, excel, componentes sharepoint, report server), em uma solução como Power BI, com opções gratuitas e acessíveis. No início parecia uma guinada radical e problemática, clientes que tinham grandes projetos implantados utilizando cubos multidimensionais teriam que jogar fora ou reconstruir, um retrabalho que poderia retardar a implantação, no início sequer havia suporte para todos os recursos que já existiam e mesmo assim tudo isso aconteceu bem rápido. Agora a questão se inverteu, o Power BI se popularizou e temos que lidar com clientes que tem a percepção de que tudo passou a ser muito simples e em apenas alguns dias toda a modelagem e os indicadores de negócio podem ser entregues em produção com versão desktop e mobile para toda a empresa com baixo custo. Mas a situação muda rapidamente quando o projeto cresce e os desafios de lidar com bases de dados grandes, que precisam de estratégias de agregação, atualização incremental, medidas complexas em DAX, dimensões com hierarquias desbalanceadas, relacionamentos virtuais, medidas com resultados incorretos começam a surgir, a performance começa a cair, as análises mais complexas não são feitas, e custos de licenciamento de contas Pro ou Premium pressionam o orçamento.

A Microsoft fez e ainda faz um produto incrivelmente simples e produtivo, mas na prática vejo que apesar de todos os esforços as análises que agregam mais valor continuarão sempre dependendo de um profundo conhecimento da linguagem DAX e técnicas de modelagem adequadas. Isso parece não mudar.

Então, mas porque DAX é simples mas não é facil?

Porque é uma linguagem funcional.

Para quem está acostumado com linguagens procedurais, ou com outro paradigma não funcional, onde a execução segue um algoritmo passo a passo, sequencial, pode ter alguma dificuldade em virar a chave para uma visão mais relacionada à matemática, com funções e retornos encadeados, com comportamentos implícitos não declarados no código. 

Porque cada medida é executada em um contexto de avaliação

É necessário entender que os valores apresentados por uma medida não são aqueles agregados a partir do que sendo apresentado na tela, o que para usuários de Excel pode parecer pouco intuitivo. As medidas apresentam o resultado seguindo o contexto de filtro atual, independentemente da linha da tabela que ela está sendo apresentada. Isso é complicado de visualizar, e por isso pode gerar muitas dúvidas. O contexto da linha é apenas um dos filtros, podem ainda existir filtro vindo de outros visuais (explícitos), de parâmetros da medida (implícitos) ou até mesmo pode não haver filtros explícitos quando isso é removido usando algumas funções. Em resumo, os resultados visualizados em tabelas e gráficos podem não ter relação nenhuma com o que está sendo apresentado.

Porque existe algo chamado transição de contexto

O contexto de avaliação do filtro no qual os cálculos são executados podem mudar implicitamente, entre contexto de linha ou contexto de filtro. Identificar em que momento isso está acontecendo não é simples, depende de vários fatores como o tipo de função se é iterativa ou não, qual parâmetro da função está sendo usada, se é medida, tabela calculada, se está dentro de uma chamada CALCULATE, se uma coluna calculada ou não.

Porque depende da forma que foi feita a modelagem dos dados

A modelagem diretamente no tamanho da base de dados, na performance e uso de memória, impacta em recursos como o uso de funções de inteligência de tempo, em como a propagação dos contextos de de filtro irá se comportar. Dependendo dos tipos de relacionamentos entre as tabelas um filtro pode ou não se propagar no modelo, afetando diretamente os resultados das medidas e mudando resultados.

Como a própria ferramenta Power BI, a linguagem é simples com alguns poucos conceitos chave importantes. Mas neste caso, a simplicidade vem aliada a uma mudança de paradigma que faz com que esses princípios sejam imprescindíveis para a evolução na aprendizagem ferramenta.

Gostaria de deixar a referência deste artigo off-topic do site sqlbi.com que traz uma discussão sobre como é o processo de aprendizagem.

https://www.sqlbi.com/blog/alberto/2020/06/20/7-reasons-dax-is-not-easy/