前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >阅读圣经丨筛选上下文与行上下文

阅读圣经丨筛选上下文与行上下文

原创
作者头像
PowerBI丨白茶
修改2021-09-02 09:25:35
1.2K0
修改2021-09-02 09:25:35
举报
文章被收录于专栏:PowerBIPowerBI

最近白茶在读《圣经第二版》,再加上有很多小伙伴问过白茶总计栏显示不合理的地方,白茶决定抽出一期来描述一下上下文。

(坦白说,这个地方不太好说,因为白茶对于一些地方理解的也不是很到位,只能说是一家之言。小伙伴们权当白茶瞎咧咧就好,别去较真,也请各位大佬收起手中的大刀。)

先来看看本期的示例文件。

将其导入PowerBI中:

添加参数索引:

编写如下代码:

基础代码:

代码语言:txt
复制
销售 =
SUM ( '示例'[销售金额] )

排名代码:

代码语言:txt
复制
RANKX =
IF ( HASONEVALUE ( '示例'[客户] ), RANKX ( ALL ( '示例'[客户], '示例'[时间] ), [销售] ) )

TOPN排名代码:

代码语言:txt
复制
TOPN =
IF (
    [RANKX] <= [移动平均 值],
    CALCULATE ( [销售], FILTER ( VALUES ( '示例' ), [RANKX] < [移动平均 值] ) )
)

看到这小伙伴们已经等着急了吧?来,看下面的结果:

小伙伴们,看明白没?

首先,左边的表,白茶放的是原始的数据文件,可以看得出来所有销售金额的总和是6822;而右边的TOPN随着参数切片器的变化而变化,但是右边的总计栏显示的不合理。

一会儿白茶会继续说,继续编写代码:

代码语言:txt
复制
解决总计TOPN =
SUMX ( SUMMARIZE ( '示例', '示例'[客户], '示例'[时间] ), [TOPN] )

结果如下:

小伙伴们,这次看出来区别没?优化之后的结果总计栏显示的完全正确,那么问题出现在哪里呢?

其实这里面就涉及到DAX计算逻辑中的上下文概念了。

在圣经中曾提到过,DAX的计算逻辑有两种上下文:

行上下文与筛选上下文。

什么叫行上下文?

图片上原始数据,一行接着一行排列,这个就叫行上下文关系。说白了就是原始数据中存放的位置。

在这个图片中,TOPN的显示受到切片器的筛选影响,排名大于11的不显示,这个就是筛选上下文,因为有一部分数据不符合筛选要求被踢出去了。

在DAX语言中,行上下文与筛选上下文是一个特别重要的问题,我们在进行DAX代码编写的时候,必须要考虑到这两点,不然计算结果很容易出现问题。二者就是计算环境。

圣经中有句话说的特别好:

筛选上下文是对数据进行筛选,

行上下文是对表格进行迭代。

白茶的理解就是:

筛选不迭代,迭代不筛选!

这个东西可能有的小伙伴不太理解,其实单抽出概念,每一个字白茶都认识,但是实际写DAX的时候把这几个字放在一起就懵了。

在这段代码中,白茶利用IF使不符合条件的项目不显示,但是实际结果存在不?必然是存在的,不显示归不显示。这种情况下总计栏不会考虑你显示还是不显示的问题,它就知道,有,我就需要汇总,哪怕它看不着。

这段代码需要分开解释:

利用SUMMARIZE函数,构建了一个虚拟计算表,这个表显示的就是符合筛选条件的项目,按照@冬哥的解释就是,可见项目

TOPN为这个虚拟表提供了一些值,本身不符合筛选逻辑的值,直接就被PASS掉了。这里已经进行上下文转换了。

最后,SUMX只对总计生效。它只计算可见项目的可计算值。像是一些排名符合要求的组合,SUMMARIZE为它提供环境,TOPN提供值,由SUMX进行二者汇总。

这样的话,三者就完成了:

行上下文转换筛选上下文→提供筛选计算值→汇总计算

有时候写DAX经常因为上下文考虑的不周到,导致计算结果出问题,没有太好的解决办法,只能说经历的多了,写的DAX多了,才会慢慢让上下文这个概念长存于心。


小伙伴们❤GET了么?

白茶会不定期的分享一些函数卡片

(文件在知识星球PowerBI丨需求圈)

这里是白茶,一个PowerBI的初学者。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档