Cálculos semanais DAX – Problemas de inteligência de tempo do LuckyTemplates

No tutorial de hoje, fornecerei algumas técnicas e dicas sobre como lidar com problemas comuns causados ​​pela granularidade semanal do DAX em cálculos de inteligência de tempo. Você pode assistir ao vídeo completo deste tutorial na parte inferior deste blog.

Recentemente, fiz um tutorial sobre como obter os valores da semana anterior no LuckyTemplates. Desde então, tenho várias perguntas relacionadas à inteligência do tempo e principalmente relacionadas aos valores semanais do DAX. Isso não é surpreendente porque as semanas são realmente a granularidade mais mal comportada na esfera de inteligência de tempo.

No caso de meses, você sempre tem 12 meses em um ano. No caso das moedas, você sempre tem quatro moedas. As semanas são diferentes porque há sete dias em uma semana e 52 semanas em um ano – ou seja, 364 dias. Então, você tem aquele dia extra por aí. Nos anos bissextos, você tem dois dias extras.

Então, isso realmente acaba em alguns anos, com base no esquema de numeração para o número da semana ISO, às vezes com 52 semanas, às vezes com 53 semanas. A semana 53 é a que vai causar mais problemas.

Índice

• Questões de inteligência de tempo de um cálculo semanal DAX
• Conclusão

Questões de inteligência de tempo de um cálculo semanal DAX

Neste exemplo, estou usando o Preço Spot Total. Com totais, é mais fácil visualizar e falar.

Neste caso, para cada um dos anos, queremos mostrar uma linha para a semana 53, se houve uma semana 53 naquele ano ou não. Então, você pode ver em 2018 e 2019, não há semana 53, mas em 2020, há. Queremos que seja consistente para que a 53ª linha seja em cada ano. Mas então, a métrica ficaria em branco para os anos em que não houvesse um 53º ano.

Uma das maneiras comuns de fazer isso é Mostrar itens sem dados e verificar se está ativado. Nesse caso, está ativado, mas não vai ajudar porque funciona quando você tem uma linha física, mas não há dados associados a essa linha. Nesse caso, nem temos a linha.

Técnicas como usar ou Remove Filters não vão funcionar porque não há nada para remover. O filtro nessa linha simplesmente não existe. E então, a questão é como inserir essa linha em cada ano em que ela não existe? E então, isso realmente se torna um problema de modelagem de dados.

Uma das coisas que podemos potencialmente fazer é ir para um esquema de floco de neve onde filtramos a tabela Dates por algo que forçará essa 53ª semana em nosso visual a cada ano. A função que vem à mente para isso é .

CROSSJOIN é usado para combinar dois campos que podem ou não ter um relacionamento. Eles não precisam ter um relacionamento ao contrário da maioria ou ou outras funções de tabela.

Nesse caso, CROSSJOIN pega duas colunas e cria todas as combinações dessas duas colunas, existindo ou não no conjunto de dados. Isso é exatamente o que queremos.

Temos nossos para criar uma tabela a partir da coluna. CROSSJOIN pega duas tabelas e, em seguida, VALUES no número da semana ISO, e nós apenas os combinamos. Isso nos dará 53 semanas a cada ano.

E então, estamos adicionando uma terceira coluna à tabela. Poderíamos fazer isso no Power Query, mas é mais fácil mostrar a lógica no DAX. O que estamos fazendo aqui é pegar e concatenar o Ano com um hífen e, em seguida, o número da semana, para que tenhamos um campo-chave para uni-lo à tabela Datas.

No entanto, temos que fazer um pouco mais de trabalho aqui porque a maneira como o campo-chave funciona na tabela Dates é um hífen de ano de quatro dígitos e uma semana de dois dígitos. Assim, nos casos em que o número da semana ISO é de dois dígitos, podemos fazer apenas a concatenação simples. Nos casos em que é um dígito, precisamos pegar o número do ano e concatená-lo com um hífen, depois um zero à esquerda e o número da semana.

Assim que tivermos isso, podemos pegar essa tabela no modelo de dados e encontrar nossa coluna Semana e Ano. Em seguida, juntamos aqueles em um relacionamento um-para-muitos. Eu sempre gosto de ativar esta opção nos campos relacionados ao Pin no topo do cartão para que, quando verificarmos, possamos vê-lo imediatamente.

Se voltarmos ao visual, teremos que mudar as linhas. Em vez do número de ano e semana, queremos usar o número de ano e semana da tabela CROSSJOIN. E agora, temos a 53ª semana em 2018 em branco e a 53ª semana em 2019 em branco. Em 2020, temos um número real, pois está na 53ª semana.

Poderíamos parar por aqui, exceto pelo fato de que agora saímos do modelo Star Schema. Sempre que você sai do Star Schema no LuckyTemplates, está saindo do âmbito do que geralmente é considerado uma prática recomendada.

E assim, para Snowflake Schema, não é uma grande violação. Existem casos em que você pode definitivamente querer usá-lo, mas se puder evitá-lo, tente. Ele reduz a duplicação, mas não necessariamente o tamanho. Ele permite que você use medidas de contagem direta, mas há problemas de desempenho e possíveis problemas de usabilidade e, definitivamente, aumenta a complexidade do DAX. Isso impede que você crie hierarquias entre as tabelas e, provavelmente, o mais problemático é que pode realmente atrapalhar sua capacidade de sincronizar segmentações em diferentes campos.

Portanto, embora isso resolva o problema, o faz de uma maneira que não é ótima. Vamos ver se podemos fazer melhor do que isso. Vamos pular para outro modelo de dados. Neste modelo, peguei exatamente os mesmos dados, as datas e o preço à vista, mas desta vez removi a tabela CROSSJOIN. Ainda existe, mas não está conectado.

Mas se olharmos para o DAX, veremos que é exatamente o mesmo DAX que criou aquela tabela no outro relatório. Então, em vez de conectá-lo em um relacionamento físico e, em seguida, violar o Esquema Estelar e convertê-lo em um Esquema Floco de Neve, podemos manter o Esquema Estelar e apenas usar um relacionamento virtual.

Para isso, usaremos uma função chamada . Ele cria esse relacionamento entre as tabelas, mas o faz virtualmente. Fazemos isso usando porque vamos mudar o contexto. Nesse caso, o contexto será em relação ao relacionamento. Portanto, temos nosso preço total à vista e, em seguida, temos TRATAS. Temos o para transformar essa coluna em uma tabela.

E então, temos o campo Year & Week, que é a chave que criamos. Nós juntamos isso de forma virtual a Week & Year na tabela Dates. Portanto, agora temos a tabela Crossjoint filtrando a tabela Dates da mesma forma que quando tínhamos um relacionamento físico, mas sem violar o Star Schema.

Agora podemos pegar e soltar o Preço Spot Total TREATAS na matriz e o que vemos são exatamente os mesmos totais. Dessa forma, fizemos isso sem interromper nosso modelo de dados e incorrer em nenhuma das desvantagens de que falamos em relação ao Snowflake Schema.

Obtenha os valores da semana anterior do LuckyTemplates usando DAX e Power Query
Calculando vendas semanais com DAX no LuckyTemplates
Time Intelligence no DAX: como selecionar dinamicamente o período inicial

Conclusão

Neste tutorial, mostrei algumas maneiras de resolver o problema de cálculo semanal DAX no LuckyTemplates. Uma delas é usando CROSSJOIN, mas tem algumas desvantagens. A segunda maneira é usando TRATAS, criando um relacionamento virtual e não violando a abordagem do Star Schema.

Essa é uma técnica bastante útil para lidar com o problema da semana 53. Espero que você tenha achado isso útil. Eu quero saber seus pensamentos sobre isso. Deixe-me saber nos comentários abaixo.

Tudo de bom,