阅读圣经丨测试上下文理解

在《圣经2》中，关于上下文理解这一块，白茶看到两个有意思的小测试，决定分享给各位小伙伴。

这是一份销售数据，将其导入到PowerBI中。

结果如图。

现在开始进行问题描述。

问题一：

为数据模型添加计算列，输入如下代码公式，结果是什么？

销售额 =
SUM ( '示例'[销售价] )

A、[销售额]所在的每一行的数字都不一样。

B、[销售额]所在的每一行数字都一样。

C、公式报错；无法显示，因为计算列不允许使用SUM函数。

小伙伴们，请根据上面的示例文件，思考计算列的结果。

开始思考！
1
2
3
4
5
6
7
…
小伙伴们，有结果了么？
没有的话可以在这里停留一下。
…

问题二：

在度量值界面编写下面代码，不嵌套任何聚合函数，结果是什么？

利润率 =
( '示例[销售价]-'示例'[进价] ) / '示例'[进价]

A、公式输入没问题，但是显示没结果。

B、错误，系统提示不行，有红色波浪线。

C、公式没问题，但是显示结果不对。

开始思考！
1
2
3
4
5
6
7

看到这里，咱来看看正确答案。

问题一的答案：

B、每一行的数字都显示的一样。

解析：

因为SUM本身是一个聚合类的函数，它本身的聚合只是针对表中的某一列，唯一影响它计算结果的是筛选上下文。

在表中添加新列输入SUM函数，这个时候它的计算环境是行上下文。

环境是行上下文，执行要求是筛选上下文，这二者相碰撞结果是什么？

就是筛选上下文为空！就像在表格中我们不选择某一对象，那么默认无筛选，就会显示所有结果的汇总一样，所以这里呈现的结果是每一行都相同。

与SUM函数类似的还有MIN、MAX等基本聚合类函数。

问题二的答案：

B、错误，系统提示不行，有红色波浪线。

解析：

度量值计算的前提是什么？上下文！

还记得之前白茶提过的概念么？

激发迭代→逐行取值→计算。

度量值不像计算列一样，计算列会依据左边的列，逐行的匹配值，进行相关的结果计算，说白了就是自带行上下文。在题二的度量值中，每一行都有不同的数字，没有对它进行上下文设定，度量值就懵了！

它的内心想法就是：

卧槽！

80要减去哪个16？

这么多16！

16前面这么多值，谁是他对象！？

这不是刁难我度量值一样么！

明白了吧，就好比有人告诉你，你的相亲对象是大街上的一个女的！

这咋找？范围太广了啊！完全没思路啊！

通过两个小例子，希望小伙伴们能够明白行上下文与筛选上下文的区别。如果白茶表述的不当，也请各位小伙伴多多谅解。

（白茶：T^T瞎唠叨一通，各位大佬别较真）

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

下面这个知识星球是针对有实际需求的小伙伴，有需要的请加入下面的知识星球。
（这个星球里面有白茶之前所有的案例文件。）

ID:Storysming