AVALIAÇÃO DE CONTEXTO

Se chegou neste post, peço que acesse o novo sobre Avaliação de contexto que está completo. Aqui.

É a base para o entendimento geral e avançado de dax

Dita as regras de como uma função irá funcionar quando executada

Sem o pleno domínio de contexto, DAX se torna extremamente difícil de utilizar e utilizar suas formas.

Os contextos podem ser dois: contextos de filtros e contextos de linhas.

Os contextos de linha são baseados em iterações das linhas nas tabelas e os contextos de filtros são criados como intuito de filtrar dados.

Um não age quando o outro esta agindo, então, se uma determinada expressão tem o contexto de linha, ela não irá filtrar nenhum dado e o mesmo pode ser dito para o contexto de filtro; não irá interagir com linhas.

O QUE É AVALIAÇÃO DE CONTEXTO

É um mecanismo ambiente que avalia toda a expressão DAX criada e executada. Ele quem ‘dá’ o sentido ao que se está executando para o sistema.

Sem essa avaliação a fórmula não teria sentido para o engine do PBI.

Para entendermos melhor, vamos avaliar da seguinte forma: veja essa expressão.

Sem um contexto, essa expressão tem pouco ou nenhum valor / sentido. Ela mostra somente o total de vendas, mas, o que está implícito e por termos criado uma função iteradora (SUMX), podemos aplicar um contexto básico, como esse.

O que temos agora é um contexto maior da função que criamos, onde podemos ver por marcas, quanto cada uma ‘participou’ em vendas financeiras.

Bastou melhorar um pouco a primeira expressão e adicionar a coluna calculada em um filter context que o sentido da fórmula mudou completamente, adicionando um contexto maior para o cálculo criado.

Visto esse primeiro resultado vamos destrinchar por partes.

Quando executamos a expressão e criamos a medida, simplesmente obtemos o total de vendas da empresa.


Ao jogarmos em um painel qualquer, ocorreu uma separação dessa venda por marca, como se a expressão estivesse refazendo o cálculo por cada marca. Mas lembrem-se em nenhum momento na expressão isso foi especificado.


Quando o resultado foi devolvido o que tivemos foi um subtotal por marca e o total geral

“OK, entendi. Mas como isso ocorre?” Essa situação ocorre única e exclusivamente pela avaliação de contexto!

Quando aplicamos a medida criada no card e por ele não ter nenhum contexto, filtro ou qualquer coisa, o que obtivemos ali foi o resultado padrão.


Jogando para outro gráfico e filtrando, nossa medida foi ‘recalculada‘ e passou a considerar um novo contexto, que foi a filtragem por marcas!

Então a avaliação de contexto passou a computar seu resultado por cada linha contendo uma marca.

O que ela faz de fato é pegar sua expressão e recalcular em um subconjunto de dados aplicando essa expressão ao novo contexto. Por isso é importante pensar em quais situações a sua expressão será utilizada, seja para coluna calculada ou medida.

Por exemplo, posso jogar a mesma coluna calculada utilizada acima, em um contexto de filtro por categoria, sem alterar nada na fórmula original.

Tenha em mente que em nenhum momento a fórmula é alterada, só a aplicação ao qual ela é submetida que sim. E ai que temos a alteração do resultado para atender o novo requisito.

Um dos grandes desafios no que tange a avaliação de contexto é entender a sua complexidade e seu grau de independência. Mas como assim, ‘independência’?

No exemplo visto acima, vimos a computação do resultado por cada categoria de produto e entendemos o que ocorre, mas, o problema não para ai. O ambiente de avaliação de contexto trabalha de forma diferente e independente para cada linha, isso mesmo , cada linha tem uma query ‘nova’ executada ali.

“E isso torna o código mais lento?” dependendo sim. Por exemplo, o resultado final da soma das vendas é feita por uma agregação e não uma soma de cada linha, como normalmente poderíamos pensar que ocorreria.

Isso significa que até para esse resultado, ocorreu uma nova agregação, iteração e avaliação de contexto!!! Ainda que todo o engine seja otimizado, cuidado!

Um exemplo dessa situação que foi explicada é adicionar por exemplo, a coluna ano ao gráfico de matriz. Veja que o cálculo é refeito e ‘quebrado’.

Sempre que um novo filtro for adicionado, ele será avaliado e a expressão recalculada para ‘quebrar’ o valor em partes menores, correspondendo ao filtro. Que foi justamente o que ocorreu com a total por marcas.

Mesmo que a sua expressão não possua nenhum filtro, quando for para qualquer gráfico, ele será aplicado pela avaliação de contexto. Independente da medida ou gráfico utilizado!

CONTEXTO DE LINHA

Vimos o contexto de filtro e sua ação no tópico anterior entendo que ele age independente da medida ou coluna calculada ter filtro ou não.

Neste tópico tentaremos entender como age o contexto de linha nas expressões DAX.

Quando criamos o contexto de linha, não estamos filtrando linha por linha de uma tabela como se fosse um cursor, mal comparando. O contexto de linha tem como ação, interagir com a tabela avaliando cada valor de uma determinada coluna.

Vamos entender melhor criando uma coluna calculada:

A ação do context evaluation aqui é diferente do que vimos quando aplicamos o filtro. Nesse caso, da coluna calculada, como é uma iteração há uma avaliação de linha por linha com realização da operação e retorno do resultado; um diferindo do outro.

O row context é habilitado sempre que uma coluna calculada é criada, ainda que não haja nenhuma fórmula. Sempre que ela for executada, o próprio row context por debaixo dos panos, age como um cursor organizando a ordem de execução, indo linha por linha retornando o resultado daquela expressão. Por isso colunas calculadas são mais lentas que medidas, ainda mais se for uma tabela com alguns bilhões de linhas.

O row context só é habilitado automaticamente quando estamos trabalhando com colunas calculadas ou quando computando uma expressão dentro de uma iteração; se for em uma medida, não é possível, somente com as funções iteradoras. Estas o habilitam.

Isso é uma configuração padrão do engine do PBI para cada tipo de estrutura.

Lembre-se que em uma medida, que é mais voltada para filtro, ela não pode ser criada sem uma função de iteração.

E em colunas calculadas, tanto importa se será uma função de iteração ou agregação, o row context irá atuar da mesma forma; Entregando claro, o devido resultado.

ENTENDENDO A RELAÇÃO ENTRE ROW CONTEXT E ITERATORS

Quando trabalhamos com colunas calculadas, entender o row context é bem intuitivo e simples, geralmente não nos preocupamos em estruturar uma função adequada para o que estamos elaborando. O problema é quando iteradores começam a fazer ‘parte’ das expressões e funções criadas.

Nesse tipo de cenário temos que tomar cuidado, pois diferente do habitual das colunas calculadas, com iteradores o row context passa para o modelo ‘manual’ ficando pela responsabilidade do desenvolvedor lidar com essas questões, ainda mais, quando criamos códigos aninhados que vão se tornando cada vez mais complexos.

Então, neste tópico, vamos entender como funciona essa relação com este primeiro exemplo.

A função SUMX possui dois parâmetros, o parâmetro mais interno é avaliado para devolver o resultado para o externo. Isso quer dizer que a função que é ‘avaliada’ pelo row context é a função interna(sublinhado em roxo).

O primeiro (tabela SALES) recebe a chamada de ação, ou seja, o SUM e o segundo recebe duas chamadas de ação:

  • A primeira chamada vem do parâmetro externo que é a ação do SUM.
  • A segunda é a própria expressão criando um resultado para a ação requisitada.

O engine do PBI age assim para todas as funções de iteração, independe qual seja.

  • Avalia qual é o primeiro parâmetro e a ação para determinar quais linhas escanear.
  • Cria um row context para cada linha desse parâmetro; no caso, a tabela.
  • Com esse row context criado, iterage com cada linha desta tabela para obter o resultado.
  • Agrega os valores e finaliza a ação.

É importante destacar que uma função iteradora nunca alterará um filtro de uma função, caso ele exista. Ela adiciona um novo contexto e trabalha nele baseado no primeiro parâmetro, no caso, a tabela passada com o filtro.

A expressão abaixo criada na coluna calculada mostra isso. Independente do valor de cada linha, a expressão só atuou nas que atendiam ao filtro e se o modelo de dados for alterado, o resultado só será acrescido quando corresponder ao filtro.

Entendem que por regra global do PBI, é impossível alterar o filtro externo utilizando uma função de iteração. Veja que quando jogo essa coluna calculada no contexto de filtro, o valor dos produtos mostrado são apenas para os produtos vermelhos, independente da categoria.

CONCLUSÃO

Este post teve o intuito de explicar o que seria a avaliação de contexto e como devemos trabalhar com elas quando estamos criando objetos no PBI.

É de extrema importância que se domine esse assunto para criar fórmulas condizentes em DAX, pois como podemos perceber, dependendo do contexto que uma expressão vá se inserir, seu valor pode se alterar completamente. 

ccTotalBYColor = 
    SUMX(
        FILTER('Product'),
                'Product'[Color] = "RED"),
        Sales[Quantity] * Sales[Net Price])

Experimente criar uma coluna calculada com essa fórmula e insira ela em um gráfico de matriz, veja o resultado.

Então, a lição que fica é: “em qual contexto esse objeto se inserirá!?” Com isso, fica mais fácil estabelecer as funções e expressões corretas, seja para coluna ou medida.

Dax é uma linguagem bem peculiar e diferente de qualquer outra, então, se atente a estes pequenos detalhes!

Espero que tenham gostado, saúde!

Todo material utilizado aqui é o mesmo do post passado sobre DAX.

Olá!

Se chegou até aqui e gostou do conteúdo, deixe seu like e compartilhe com seus amigos! Ajude o blog a crescer e alcançar mais gente.

Não se esqueça de se inscrever e seguir o blog. Seja atualizado sempre que houver um novo artigo.

Voce também pode assinar minha newsletter no LinkedIN, no post fixo clicando aqui.

Siga nas redes sociais!

Obrigado, volte sempre!

Publicidade