INTRODUÇÃO
Avaliação de contexto é o ponto de virada para um nível maior em DAX, principalmente em fórmulas extremamente complexas. Sem o pleno domínio, terá grande dificuldade de trabalhar com o desenvolvimento de expressões no PowerBI.
A linguagem de análise de dados foi desenvolvida para trabalhar com dois tipos de contexto:
- Contexto de filtro (filter context) – é o contexto padrão dos gráficos e de algumas funções em DAX. Também é o responsável por dar o ‘sentido’ para medidas criadas.
- Contexto de linha (row context) – é o mais utilizado, principalmente com as funções X e agregações. São a base de trabalho das colunas calculadas dentro de qualquer modelo.
É de extrema importância destacar que o PowerBI não trabalha com contexto simultâneo; seria impossível. Isto quer dizer que se for aberto um contexto de linha, o de filtro é desativado e o contrário também se aplica.
E como o PowerBI gerencia o contexto? Através de um recurso que ele possui chamado Contexto de Avaliação (Evaluation Context). É ele quem vai receberá a fórmula criada pelo usuário e gerenciará da melhor maneira antes de executá-la.
Além do gerenciamento, ele garante que o contexto de linha interaja entre as colunas da tabela e o de filtro, filtre de acordo com o desejado.
Conceitue os contextos da seguinte forma: “o contexto de linha iterage e o de filtro, filtra”. Acredite, irá facilitar muito sua vida.
ÍNDICE:
- INTRODUÇÃO
- CONTEXTO DE FILTRO: CONCEITO E APLICAÇÃO
- CONTEXTO DE LINHA – CONCEITO E APLICAÇÃO
- ANINHAMENTO DE CONTEXTO DE LINHA EM MÚLTIPLAS TABELAS.
- CONTEXTO COM MÚLTIPLAS TABELAS – RELATED & RELATEDTABLE
- CONTEXTO DE FILTRO: ENTENDENDO O RELACIONAMENTO E SUAS DIREÇÕES
- CONCLUSÃO
CONTEXTO DE FILTRO: CONCEITO E APLICAÇÃO
Já mencionamos que o contexto de filtro atribui um sentido às medidas criadas para análise de dados. Isto fica muito claro quando, por exemplo, temos esta simples situação:
Nesta imagem podemos ver o valor total das vendas e sem um contexto, não faz muito sentido, mas o PowerBI agiu exatamente, através da avaliação de contexto, como queríamos; computando o total das vendas.
Não se esqueça que a SUMX, no fundo, ainda é uma SUM e é possível chegar no mesmo resultado, porém, o caminho é um pouco mais longo.
No final, a coluna ccTotal tem o mesmo valor da medida.
E como o contexto de filtro age dando sentido à medida? Ele aplica uma ‘quebra’ na computação do cálculo geral através das relações entre tabelas.
Aplicando a medida anterior em um gráfico, veja que toda a computação do resultado é quebrada, mas não exclui o total geral ao final. (1ºex)
Resumindo:
- A medida é aplicada ao gráfico;
- O gráfico tem o filtro por marca de produto;
- Como nossa construção é com a SUMX, temos o total geral;
- Que é quebrado pela avaliação de contexto, que entende que esta medida está sendo avaliada em um contexto de filtro.
- Logo, temos um computado para cada marca e o total geral. O mesmo se aplica quando jogamos a coluna calculada; que não possui nenhum filtro em sua construção.
É importante frisar que o contexto de filtro, considera cada cédula com um filtro único na estrutura que está sendo utilizado. Por exemplo, nesta simples medida de vendas totais filtrada por marca, cada uma ali foi filtrada e executou a agregação correspondente.
Assim, é correto afirmar que cada uma destas cédulas destacadas são independentes umas das outras.
E à medida que vamos aplicando outros filtros, essa mesma cédula sofre um novo processo de quebra e recálculo para se enquadrar no novo requisito com a inversão dos totais. Tendo o total exibido na coluna referente ao ano e o da linha à marca.
Uma medida pode ter um filtro em sua estrutura e ser aplicada em um contexto externo. Podemos elaborar uma medida que faça a soma das vendas dos produtos de uma determinada cor e filtrar por marca. Veja:
E a quantidade de filtros que se podem aplicar em uma medida e após jogá-la em um contexto não tem limite. Apenas se atente que o resultado ficará mais restrito. Observe:
É importante conceituar que uma função iteradora aplicada a um contexto de filtro exibirá apenas os valores visíveis, mas não quer dizer que seja restrito somente a este grupo. Nas duas construções abaixo, temos um exemplo claro.
Algumas situações foram repetidamente reforçadas durante o post para solidificar o conceito de filtro na construção de expressões de análise de dados. Parte da complexidade nesta linguagem está em entender como os contextos funcionam e a partir, trabalhar com eles de forma correta.
De agora em diante, veremos como o contexto de linha se comporta dentro do PowerBI.
CONTEXTO DE LINHA – CONCEITO E APLICAÇÃO
Entendemos que o contexto de filtro é uma ferramenta para dar sentido às medidas criadas para analisar dados. Vimos que ele também é utilizado em colunas de tabelas quando queremos determinados valores, ainda que haja uma iteração.
Deste ponto em diante, vamos entender como o contexto de linha é gerenciado pelo PowerBI e como as expressões são processadas para retornar o valor desejado pelo usuário ou analista.
Diferente do filtro, esse aqui age em duas situações diferentes:
- Entre expressões utilizando uma ou mais colunas de uma ou mais tabelas;
- Utilizando funções iteradoras nas colunas calculadas e medidas.
Muito importante destacar que este contexto não tem o objetivo de realizar filtros em tabelas, mas sim, trabalhar linha por linha dentro da(s) coluna(s) desejada(s).
Vamos entender na prática como funciona o contexto de linha. O primeiro exemplo será com uma coluna calculada. Irei calcular a margem de lucro na venda.
Se repararem na imagem, verão que o PowerBI executa a operação envolvendo linha por linha das colunas atreladas à expressão. Diferente do que ocorreu quando criamos uma medida, ainda que esteja usando uma SUMX.
Aliás, esse é outro ponto interessante, veja nos ‘bastidores’ como a SUMX age.
Primeiro ela processa a iteração entre as colunas operando linha por linha e obtêm o resultado daquele cálculo e ao final, ela agrega como uma SUM tendo assim, o total exibido.
Claro que existem diversas formas de se chegar ao resultado e todas estão corretas. Mas lembre-se de optar pela melhor performance. Destaco que as colunas calculadas são processadas assim que o modelo carrega, o que pode levar à lentidão no modelo de dados.
Não confundir as linhas de um relatório que recebe uma medida, com o contexto de linha (row context). No relatório, o que está ocorrendo é uma adequação da medida ao filtro. E se jogar uma coluna calculada, é só o valor armazenado sendo reorganizado no filtro.
Veja que nos dois exemplos abaixo, aplicando a medida e a coluna, o total é igual.
Porém, gostaria de chamar atenção para uma situação que pode ocorrer em suas expressões caso não tomem cuidado.
Lembra da coluna calculada que criei (ccMargemDois) utilizando a função SUMX? Veja o que ocorre quando aplico no contexto de filtro. Reforço que ali temos um contexto de linha com uma função iteradora.
Uma das soluções seria adicionar a função RELATEDTABLE para ‘reestruturar’ o relacionamento nesta expressão. Com ela, somente as linhas que possuem relacionamento entre as tabelas participarão da operação.
Mais a frente entenderemos de forma detalhada a ação da função RELATEDTABLE.
Veja abaixo a solução.
E se chegou até aqui e está se perguntando: “Por que existem duas formas de trabalhar com row context, no caso, função e colunas calculadas?”
Porque NÃO podemos criar um row context nas medidas de forma automática, como acontece quando mandamos o PowerBI criar uma coluna calculada no modelo de dados.
Antes de avançarmos para o próximo tópico preciso esclarecer uma situação.
Quando estamos utilizando a função Filter em uma coluna calculada, o que estamos aplicando é uma iteração linha por linha para encontrarmos os valores desejados.
Se desejarmos criar uma coluna calculada com o total dos produtos que possuem o dobro do seu preço de custo, poderíamos utilizar esta expressão.
Não se esqueça da função RELATEDTABLE na criação da expressão.
Um ponto que é importante ressaltar quando tratamos do row context é que funções iteradoras (X-functions), permitem abertura de um novo contexto dentro da sua operação. Adianto que isto é a base do conceito para nested row context que veremos no próximo tópico.
Veja o exemplo da medida abaixo
Na medida utilizei o SUMX como padrão, já que não podemos criar um contexto sem uma função iteradora. Percebam que dentro da medida da função, eu criei um novo row context, só que, ao invés de adicionar uma coluna, eu adicionei uma expressão matemática.
E como mostra a imagem, a medida funcionou corretamente.
O mesmo processo também pode ser aplicado em colunas calculadas, porém, exige maior atenção e o uso da função RELATEDTABLE. Como estamos adicionando um novo contexto em cima de um já existente, no exemplo abaixo, o novo sobrepõe o antigo, daí a necessidade da solução com a função citada.
E como o PowerBI processa isso?
Quando se trata de medida, ele segue os processos abaixo:
- Recebe e avalia a tabela para entender as linhas que irá atuar;
- Cria o row context para cada linha que satisfaz o parâmetro;
- Adiciona o novo contexto ao existente, avalia o parâmetro de tabela e executa a operação;
- Agrega os valores, cria o total e retorna o resultado.
Com a coluna calculada, o procedimento é basicamente o mesmo, a diferença é que temos três row context:
- Nativo quando criamos a coluna;
- Da função SUMX;
- Da nova iteração aumentando em 10% o valor dos preços.
Até o momento vimos a base do row context, como ele funciona e é processado pelo PowerBI. Além disso, vimos parte do seu comportamento quando aplicado em um outro contexto.
Agora vamos avançar um pouco mais e entender como funcionam os aninhamentos e outros conceitos avançados.
ANINHAMENTO DE CONTEXTO DE LINHA EM MÚLTIPLAS TABELAS.
NESTED ROW CONTEXT
Em algumas situações talvez seja necessário ao analista de dados criar expressões que envolvam mais de uma tabela e funções iteradores para criar medida ou coluna calculada. Para suprir este requisito, vamos entender como funciona o aninhamento de contexto.
O aninhamento de contexto pede que aninhemos uma função iteradora dentro de outra utilizando o parâmetro ‘expression’ como porta de entrada para outras no processo.
Ao trabalhar com multiníveis de expressões, não se esqueça que a função mais interna será avaliada primeiro, logo, o core da análise deve partir de lá. Atenção neste ponto.
Veja esta expressão criada para a primeira demonstração. Perceba que eu envolvi três tabelas para criar uma coluna calculada que me traz o total das vendas. Adianto que este resultado está errado e já explico
O que ocorre:
- A SUMX mais interna calcula a multiplicação entre preço e quantidade como tem a função RELATEDTABLE, apenas os produtos que possuem relação com a tabela sales participam temos o totalvendido de todos os produtos.
- Quando esse total vai para a SUMX mais externa, que envolve a Product Category, ocorre uma agregação, já que não há RELATEDTABLE para limitar a ação.
- Deste modo o total que seria 30,591,343.08 é somado 8x (número de categorias na tabela) assim, o valor resultante é o que está sendo exibido: 244,730,751.81)
Adicionando RELATEDTABLE a tabela product temos o total correto – ainda que replicado para todas as linhas.
Resultado das operações:
Destaco que manipulando colunas calculadas com row context aninhado, cada função tem um contexto e não se esqueça do contexto automático quando criamos a coluna calculada. Ao final, no exemplo acima, tínhamos 4 contextos abertos – daí a necessidade da quantidade de RELATEDTABLE na construção.
Quando estamos tratando de medida e filter context, o aninhamento de row context age quase da mesma forma, mas possui algumas particularidades que descobri e gostaria de trazer para vocês.
Eu quebrei a situação em partes para entenderem o processo com mais facilidade. Veja esta estrutura, seu cálculo e o resultado final.
Em vermelho, está a estrutura correta – coloquei para comparação.
Mesmo que a medida tenha processado o valor correto para cada categoria, no agregado, o resultado está completamente errado.
Reestruturando toda a expressão, continuamos com o mesmo resultado no processamento final.
O resultado continua inconsistente. A única solução para esse problema foi:
Esta situação ocorre pois existe uma outra iteração dentro da variável Deluxeproduct. Essa iteração ocorre pela aplicação da função FILTER. Como RELATEDTABLE é uma função tabular que não aceita table expression, o que ocorre na imagem dois utilizando a variável, não conseguimos obter o resultado desejado.
O PowerBI consegue obter o resultado correto, mas como existe uma iteração aberta e ele precisa fechar, acaba multiplicando o resultado por 8, número de categorias.
E embora a estrutura acima não ‘funcione’ quando estamos tratando de medidas, na coluna calculada ela funciona perfeitamente. Veja:
O jeito mais simples de escrever esta expressão seria desta forma.
ANINHAMENTO ENTRE COLUNAS DA MESMA TABELA – PROBLEMA E SOLUÇÃO
Este cenário não é muito usual pois existem outras formas de resolver este problema, como por exemplo, utilizando a função RANKX. Porém, gostaria de mostrar uma solução de contorno caso um dia precisem comparar colunas da mesma tabela.
Imagine o seguinte cenário: surgiu a necessidade de criar uma tabela com o ranking dos produtos com maior preço.
Para essa solução, precisamos comparar o preço dos produtos e listar sua posição na coluna desejada.
Ao replicar este cenário em seu ambiente de estudo verá que todos os produtos possuem a mesma posição (basta abrir o filtro da coluna e verá que só tem um valor).Mesmo que a construção da solução esteja correta, o processamento não está!
O ‘problema’ acontece na avaliação do contexto. Como nós temos dois row contexts abertos nesta expressão, o mais interno, que contém a função FILTER, acaba sobrepondo o que foi criado automaticamente na abertura da coluna calculada.
Para solucionar esta situação, podemos reescrever o código da seguinte forma:
Como a variável é chamada no momento da sua execução e por ordem de criação, ela vem primeiro, podemos utilizá-la como parâmetro dentro do filtro e obter o resultado correto.
FILTER, ALL E COMO INTERAGEM COM OS CONTEXTOS
Ao longo deste post, que não (que não está curto! XD), utilizamos por diversas vezes a função FILTER e debatemos algumas situações peculiares que ocorrem com seu uso.
Sabendo que sempre que desejamos um filtro específico utilizamos esta função, quero abordar com um pouco mais de profundidade como ela atua e é processada pelo engine do PowerBI nos diferentes contextos.
Para entendermos um pouco, observe esta expressão e sua aplicação em um contexto de filtro. Nele, estou utilizando a coluna Brand da tabela produto.
Até o momento o resultado está correto e não precisaríamos ajustar nada nesta expressão. O problema passa a ser quando utilizamos um Slicer para ajustar a exibição.
Embora pareça que seja um erro, é a forma correta como o PowerBI processa quando se depara com este tipo de situação. A maneira mais rápida de solucionar este pequeno problema seria adicionando outros parâmetros dentro da FILTER – ainda que seja inviável quando há muitos valores.
Existe uma forma de sobrepor todo o filter context exibindo, independente inclusive da seleção no slicer, a quantidade para uma determinado filtro, por exemplo.
Pegando o exemplo anterior, repare nesta construção e veja seu resultado.
Como devem se lembrar, ALL é uma função que remove todo o contexto de filtro existente impondo apenas o valor que ela encontra, neste caso, como apliquei dentro de uma FILTER e limitando apenas a classe de produtos Deluxe, houve uma iteração nesta coluna e todos os valores visíveis encontrados e distintos foram agrupados e aplicados ao contexto por marca.
Alerto-os que existem formas de sobrepor esta situação envolvendo o uso de calculate e context transition. O que será revisto em outro momento.
Apenas para reforçar os conceitos, a proposta também se aplica para colunas calculadas.
Podemos dizer que a função ALL sobrepõe os dois contextos a sua maneira entregando apenas o valor visível e distinto agregado ao final, dependendo da situação.
EXTRA FILTER CONTEXT: INTRODUÇÃO A FUNÇÃO ALLLSELECTED
Esta é uma função tabular de comportamento extremamente complexo, mas que ser utilizada de forma básica, gera filtros interessantes no PowerBI.
É muito aplicada quando temos um slicer para selecionar certos valores de filtro mantendo a computação dos cálculos correta.
Veja esta medida que computa a porcentagem das vendas. Quando lançada em um contexto de filtro, o que vemos é a porcentagem que cada valor representa dentro das vendas totais.
Esta é uma função tabular de comportamento extremamente complexo, mas que se utilizada de forma básica, gera filtros interessantes no PowerBI.
É muito aplicada quando temos um slicer para selecionar certos valores de filtro mantendo a computação dos cálculos correta.
Para começar a trabalhar com ALLSELECTED, precisamos desta construção:
Agora, utilizarei esta medida para criar medidas de porcentagem.
Veja esta medida que computa a porcentagem das vendas. Quando lançada em um contexto de filtro, o que vemos é a porcentagem que cada valor representa dentro das vendas totais.
Para construção da primeira medida mrSalesPercent, utilizei essa como apoio na variável ALLSALESAMT:
Como vimos no final do tópico anterior, como uma das medidas construídas tem a função ALL e esta por sua vez remove todo o contexto externo, acaba que o total da porcentagem exibido é oriundo de uma agregação, diferente do que ocorre quando utilizamos ALLSELECTED.
Perceberam a diferença do resultado? Enquanto uma computa a agregação, ALLSELECTED age como se excluísse do cálculo os valores que não foram selecionados no slicer redistribuindo os valores para que alcancem 100%.
Portanto, dentro dos selecionados na coluna mrAllSelPercent, a categoria Cameras and Camcoders representa 75.38% das vendas.
É como se disséssemos o seguinte para o PowerBI: “exclua da operação todos os valores que não foram selecionados pelo filtro externo (slicer) e recompute estes valores restantes para o total de 100% no gráfico de matrix”
Deixando claro que este é o funcionamento básico da função ALLSELECTED e muitos outros detalhes estão ocultos por ser uma função muito diferente do que estamos habituados e por exigir maior entendimento de DAX.
Voltaremos nela futuramente.
CONTEXTO COM MÚLTIPLAS TABELAS – RELATED & RELATEDTABLE
Nos diversos exemplos que vimos até aqui, muitas situações da linguagem DAX foram resolvidas com o uso destas funções, principalmente em aninhamento de contexto de linha e em alguns casos de mudança de contexto.
A grande maioria dos problemas nos resultados eram ocasionados pelo relacionamento entre as tabelas do modelo. Assim, para finalizar este post, vamos entender como os contextos se comportam no relacionamento entre tabelas para evitar problemas na execução.
Primeiro ponto para compreendermos este assunto é saber que o PoweBI possui 4 cenários de avaliação antes de entregar o resultado. Estes cenários são avaliados considerando os seguintes aspectos:
- Dois contextos de avaliação:
- Row context;
- Filter Context.
- Cardinalidade no relacionamento do modelo:
- Cardinalidade 1-N (um para muitos);
- Cardinalidade N-1 (muitos para um)
É muito importante destacar que, embora estes pontos sejam cruciais, existem mais duas situações que devemos prestar atenção nos modelos, que são:
- Existe uma relação em cadeia entre as tabelas? Pode afetar a forma como criamos expressões. Um bom exemplo:
- Product → Product SubCategory → Product Category – esta seria uma relação no formato de cadeia no modelo.
- Se há relação bidirecional entre alguma tabela.
- Product → Sales. Aqui pode existir uma relação bidirecional.
Prestando atenção nestes pontos, podemos criar nossa expressão corretamente e evitar erros de execução por conta dos contextos, principalmente no row context.
Ok? E como o row context funciona quando há diversas tabelas?
Primeiro é preciso deixar claro que o row context funciona apenas para a tabela que ele foi “criado”. Veja a seguinte situação:
Para ambas as tentativas, não foi possível realizar a operação, correto? E o motivo deste erro é simples:
O contexto de linha não é capaz de agir fora da tabela ao qual ele é aberto. Ou seja, todas as operações realizadas ali, devem ser feitas pelas colunas da tabela alvo.
Mesmo que exista relacionamento entre as tabelas, independente da cardinalidade, direção ou corrente, ele fica impedido de acessar outras colunas pelo engine do PowerBI; e é aqui que as funções RELATED E RELATEDTABLE entram.
E qual a diferença entre as duas funções?
Basicamente elas se diferem no lado que deverão ser utilizadas considerando o relacionamento entre as tabelas do modelo. Não se esqueça que temos dois tipos: 1-N e N-M.
Deste modo, podemos conceituar da seguinte forma:
- RELATED – Além de ter uma iteração aberta, a função deve ser utilizada no lado N da tabela. Então, ao criar uma coluna calculada na tabela Sales, a função RELATED é a mais indicada para qualquer outra tabela.
- RELATEDTABLE – age de forma inversa, sendo utilizada no lado 1 da relação, encontrando as linhas que satisfazem o relacionamento com a chave.
A função RELATEDTABLE foi utilizada na tabela Product para criar a coluna ccQtdVendas e a ccDifPrice na Sales.
Partindo da direção 1→N, utilizamos RELATEDTABLE (Product → Sales) e da direção N → 1 RELATED (Sales → Product).
Como comprovado, cada situação exige o uso de uma função específica para alcançar o resultado desejado. E lembram quando pedi para observarem se no modelo existia alguma relação em cadeia? As funções também funcionam neste caso.
Nos exemplos acima, como a função consegue propagar a relação entre as tabelas até chegar na Sales, os relacionamentos entre as linhas são identificados e agrupados para serem exibidos no resultado final.
A aplicação em medidas também segue o mesmo processo lógico, podem aplicar tranquilamente.
Com este conhecimento, podemos acrescentar à explicação do nested row context o motivo de usarmos ambas as funções, repare:
- O processo de execução começa de cima para baixo, avaliando primeiro a variável FILTERDELUXE.
- Como esta variável possui uma função tabular (FILTER), ela é o primeiro parâmetro da função SUMX.
- Abrindo outra SUMX (aninhando) adiciono a tabela Sales, para puxar as duas colunas Net Price e Quantity. E aqui entra a função RELATEDTABLE.
- Como o PowerBI começa a executar a expressão pela mais interna (marrom), eu preciso da função de apoio pois estou no lado N da relação. Ainda que haja o aninhamento, estamos ‘entregando’ o resultado para a tabela Product.
- Com o resultado entregue para a tabela Product, ocorre a interação da função FILTER e a conclusão da operação.
- Aplicamos o RETURN para fechar o resultado.
Agora nós temos a explicação correta e completa sobre o que ocorre no aninhamento de row context e o motivo do uso das funções relacionadas.
Um ponto que é importante destacar diz respeito a direção dos relacionamentos entre as tabelas. Dependendo da direção, não conseguimos criar uma coluna ou medida de forma satisfatória. Veja.
Como as direções dos relacionamentos das tabelas envolvidas vão de encontro um do outro, as tabelas Customer e Product não conseguem se alcançar e o que retornam é a quantidade total de registros de cada uma. Independente se há relacionamento entre as linhas.
E como fica o contexto de filtro na avaliação das direções entre tabelas?
CONTEXTO DE FILTRO: ENTENDENDO O RELACIONAMENTO E SUAS DIREÇÕES
Como mencionado anteriormente, o modelo de dados que importamos para o PowerBI possui relacionamento e estes possuem direções. Estas direções são chamadas de cross-filter e ditam como as funções DAX irão operar quando houver cruzamento entre tabelas.
No row context vimos que ele ocorre somente na tabela ao qual é iniciado e para envolver outras precisamos das funções de apoio RELATED & RELATEDTABLE, mas quando se trata de filter context, a situação muda.
O contexto de filtro, diferente da linha, acontece em todo modelo e claro, não deixa de considerar a direção dos relacionamentos. Por isso conseguimos criar medidas como SalesAmount e jogar em um contexto de filtro por cliente, por exemplo.
Como já sabemos, cada linha da coluna Manufacturer realiza um filtro nas tabelas que utilizamos na criação da medida. Assim, cada fabricante têm suas quantidades exibidas corretamente, somente a mrQtdCustomer que não.
Como no modelo de dados a direção (cross-filter) não alcança a tabela Customer, já que a direção Customer → Sales é oposta, o que temos é o total de clientes. Que é o que o contexto de filtro consegue acessar.
Agora, se mudarmos o filtro utilizando alguma coluna da tabela Customer, o resultado é completamente diferente.
Como a direção Product → Sales é bidirecional, a tabela Customer consegue acessar a tabela Product e filtrar corretamente os valores da medida, o que não quer dizer que chegará a todas, caso haja uma relação corrente.
Reforçando o que vimos no tópico anterior, quando as direções são opostas, não há contexto de filtro que consiga atuar corretamente no retorno do resultado da medida.
Você pode pensar que trocar a direção de todas as tabelas venha a ser uma ótima ideia, mas não é recomendado, pode comprometer o seu trabalho e análise dentro do PowerBI.
Procure sobre a função CROSSFILTER e veja se ela atende alguns dos seus requisitos.
CONCLUSÃO
Até o momento, este foi o post mais longo e mais denso deste blog e por uma ótima razão: entender a avaliação de contexto no PowerBI é fundamental para trabalhar com DAX e criar as medidas de forma correta.
Como vimos ao avançar aqui, qualquer detalhe que passe despercebido pode causar problemas nos seus cálculos e expressões, comprometendo sua análise.
Podemos resumir este capítulo em alguns pontos muito importantes, como:
- Contexto de filtro, filtra; de linha, itera;
- A função FILTER é iteradora e ela pode alterar o seu resultado quando estiver trabalhando com row context;
- A função FILTER “trava” o contexto de filtro no valor que é utilizado, então, use com atenção e certeza que deseja aplicar essa pequena restrição;
- Aninhamento de row context exige muita atenção; Não se esqueça que em colunas calculadas já existe um por padrão, cuidado quando for trabalhar com aninhamento de X-FUNCTIONS;
- Não se esqueça da diferença entre RELATED (quando estamos na tabela que está no lado N da relação) e RELATEDTABLE (quando a operação parte da tabela que está do lado 1 da relação). Principalmente com as medidas;
- Lembre-se que no aninhamento, o que conta é a tabela do topo, logo, quase certo que precisará de RELATEDTABLE.
- As duas funções acima também servem para difundir a ação do contexto de linha; considere a direção dos relacionamentos;
- A direção dos relacionamentos conta muito na hora da criação de colunas e medidas, cuidado. Caso retorne apenas a quantidade total de uma determinada tabela, há algum problema na direção (crossfilter) delas.
- O contexto de filtro atua em todo o modelo, diferente da linha, que atua apenas na tabela criada;
- Quando criar expressões de tabela com ALLEXCEPT, relacione estas tabelas com as principais do modelo, em algumas situações, o cálculo pode ficar comprometido.
- Leia o tópico sobre ALLSELECTED é interessante!
No mais, muito obrigado para quem chegou aqui, você foi um guerreiro, meus parabéns!
Não se esqueça de curtir o post, compartilhar com quem precisa aprender DAX e se inscreva para nossa newsletter abaixo!
Boas festas e que Deus os abençoe!
E se chegou até aqui, não se esqueça de assinar nossa newsletter!
Curta e compartilhe e faça este post chegar a quem precisa entender este assunto!
SQL Server: Baixe aqui o banco de dados utilizado como modelo no PowerBI
PowerBI: Baixe aqui o arquivo .pbi utilizado.
ManageBI 