Power BI Data Granularity

No exame da Microsoft o termo “data granularity” aparece em apenas um tópico:

• define the appropriate level of data granularity

Data Granularity, também conhecida como granularidade… Não confundir com Data Cardinality, ou cardinalidade dos dados, e também não confundir com cardinalidade de um relacionamento, são 3 coisas diferentes.

No dia a dia você vai ver pessoas perguntando “qual é o seu grão”, ou “qual a granularidade dos dados que você quer ter?”. Essas são perguntas comuns quando queremos entender qual é o nível de detalhe da informação que queremos mostrar e isso impacta diretamente a modelagem do seu dataset.

Utilizando a Microsoft como fonte: https://docs.microsoft.com/en-us/learn/modules/design-model-power-bi/5-data-granularity. Aqui eles definem Data Granularity como: “Data Granularity é o detalhe representado em seus dados, o que significa que quanto maior a granularidade, maior o nível de detalhes dos dados.“.

Ou seja, se você tem uma tabela fato VENDAS com granularidade a nível de DIA, ou seja, vendas realizadas por dia, então isso significa que seu nível de detalhe é muito grande, logo sua granularidade é alta, logo sua tabela VENDAS vai ser gigante (muitas linhas),

Porém, se você tiver uma fato VENDAS com visão de vendas realizadas por MÊS, seu nível de detalhamento já não é tão grande assim, logo sua granularidade é baixa, logo sua tabela de vendas vai ser bem menor (menos linhas).

Na imagem abaixo represento esses dois tipos de granularidade, por DIA e por MÊS. As duas tabelas tem exatamente os mesmos valores, porém na tabela por MÊS os valores estão agregados nesse nível, tornando a granularidade menor. Seria possível diminuir ainda mais a granularidade se não considerarmos o PRODUTO na tabela por MÊS.

A grande questão em lidar com dados e definir granularidade dos seus dados está em entender o que o negócio quer ver. Por exemplo, pode ser que as pessoas que consomem seu relatório não precisem ver as VENDAS por DIA, para elas o que importa são as vendas por MÊS, nesse caso não faz sentido trazer o detalhamento de DIA para o seu modelo de dados, porque isso, em geral, faria seu modelo ser maior, mais pesado e menos performático.

No entanto, é importante que fique muito claro o seguinte… Se você definir que seu modelo de dados tem granularidade a nível de MES, logo não será possível em nenhum momento você construir qualquer gráfico ou análise a numa granularidade menor, ou seja, será impossível fazer um DRILL DOWN para DIA. (já DRILL UP, ok, vai funcionar, você pode fazer um DRILL UP para ANO).

Diferentes Granularidades

É comum que seja necessário trabalhar com diferentes granularidades usando o mesmo modelo de dados, por exemplo quando temos VENDAS por dia e META por mês. Imagine então que suas vendas estão numa granularidade a nível de DIA enquanto META está numa granularidade a nível de MÊS. Como fazer pra tratar isso?

A resposta é: você precisa criar uma forma de relacionar essas duas tabelas.

Vamos conhecer nosso modelo:

Adicionei META, que tem granularidade MENSAL e quero comparar minhas vendas com minhas metas. Só que, é impossível comparar minhas METAS que são mensais com minhas vendas, que são diárias, então eu só vou conseguir ver o meu total de vendas no MÊS contra meu total de METAS no mês. Pra conseguir fazer isso eu preciso de duas coisas:

• Conseguir agregar minhas vendas por mês
• Conseguir relacionar minhas METAS e minhas VENDAS na mesma dimensão TEMPO

Pra agregar minhas vendas por mês é moleza, basta criar uma nova tabela, dimensão tempo, que vou chamar de CALENDAR, e relacionar a data do dia com a data da tabela CALENDAR.

Já pra conseguir relacionar METAS e VENDAS no mesmo eixo de tempo eu preciso relacionar minha tabela META com a CALENDAR, só que a tabela META não tem um campo de identificador que se relacione com CALENDAR… Porquê em VENDAS usei a coluna DATA pra relacionar com DATA da CALENDAR, mas se você perceber, vai ver que META não tem uma coluna “data”, só tem coluna de MES e ANO. Então o que precisamos fazer é criar uma coluna extra na tabela META e chamar essa coluna de MES_ANO com um formato de data (dd/mm/aaaa), onde dia vai ser sempre 1, então o mês 6 ficaria como 01/06/2020.

Pra criar essa coluna de ANO_MES, vá no Power Query e adicione uma nova “custom column” com esse código:
= Table.AddColumn(#”Changed Type”, “MES_ANO”, each Text.Combine({“1/”, Text.From([MES], “pt-BR”), “/”, Text.From([ANO], “pt-BR”)}), type text)

Ou então crie uma coluna nova “column from examples”… Merge na coluna também funciona, só que tu perde as colunas originais… Enfim, o resultado é que agora você tem uma coluna que pode ser utilizada para relacionar META com CALENDAR.

Depois disso é só montar a tabela que você precisa, relacionando os campos de data da tabela de CALENDAR e as agregações das tabelas de VENDAS e META (você pode usar measures explícitas ou usar implícitas…). O resultado:

Referências

https://docs.microsoft.com/en-us/learn/modules/design-model-power-bi/5-data-granularity
https://www.youtube.com/watch?v=KPoCreRAmNU – Power BI Data Modelling – Marco Russo
https://www.sqlbi.com/articles/obtaining-accurate-totals-in-dax/
https://www.sqlbi.com/articles/working-below-a-dax-formulas-granularity/