理解上下文转换

显示全部楼层 · 2021-2-21 19:33:14

上下文转换是 DAX 计值过程中一个非常灵活的部分，灵活的同时意味着复杂，DAX 的大部分复杂性都蕴含于此。上下文转换需要在理解 CALCULATE 函数的基础上学习。

初识上下文转换

在理解 CALCULATE 的行为之后，你知道这个函数在计值过程中会执行一项非常重要的任务：将任何现有的行上下文转换为等效的筛选上下文。这就是我们说的上下文转换。

为了演示该行为，我们创建一个包含 CALCULATE 表达式的计算列。由于计算列总是具有行上下文，因此会触发上下文转换。例如，在产品表中定义一个包含以下 DAX 表达式的计算列：

Product[SumOfUnitPrice] = SUM ( Product[Unit Price] )

复制代码

公式对所有产品的标价求和。表达式在行上下文中计算，没有筛选上下文，因此它返回表中所有产品的单价之和，而不是正在计值的当前行产品的单价。你可以在下图中看到这种行为。

SumOfUnitPrice 在计算列中计值，返回所有产品单价的总和

现在，你可以将表达式稍作修改创建一个新的计算列，加入 CALCULATE：

Product[SumOfUnitPriceCalc] = CALCULATE ( SUM ( Product[UnitPrice] ) )

复制代码

什么？只有一个参数的 CALCULATE？筛选器去哪儿了？实际上，我们用的是 CALCULATE 的极简形式。我们之前说过，CALCULATE 惟一的必选参数是第一参数，因此在不使用任何筛选器的情况下调用 CALCULATE 是完全可以的。在这种情况下，CALCULATE 不会使用其他条件更改现有的筛选上下文，它仍然执行你现在正在学习的行为：接受现有的行上下文(如果有的话)，并将它们转换为等效的筛选上下文。请注意，所有现有的行上下文都合并到新的筛选上下文中，稍后我们会详细阐述。

在本例中，CALCULATE 查找现有的行上下文，并在产品表上发现一个由计算列定义的正在执行的行上下文。CALCULATE 考虑这个行上下文，并用一个筛选上下文取而代之，该筛选上下文只包含行上下文正在迭代的当前行。我们将此行为称为上下文转换。一般来说，我们将以上过程简述为CALCULATE 执行上下文转换，将所有行上下文合并到一个新的等效筛选上下文中。

在 CALCULATE 内部，表达式 SUM ( Product[Unit Price] )在只包含产品表当前行的筛选上下文中计值，由于 CALCULATE 执行了上下文转换。这一次的结果与产品单价(unit price)相同，如图所示。

通过使用 CALCULATE，行上下文被转换为筛选上下文，改变了结果

当你第一次观察到这种行为，会发现很难理解为何 CALCULATE 要执行上下文转换。一旦开始使用之后你就一定会喜欢上该特性，因为多亏了它你才能创建强大的公式。

此外，上下文转换还有另一个非常重要的作用。你可能还记得，筛选上下文和行上下文以不同方式在关系中运行：行上下文不会自动沿着关系方向传递，而筛选上下文从关系的“一”端传递到“多”端。因此，当发生上下文转换时，筛选上下文会自动传递到相关的表。

通过在产品表定义以下两个新的计算列公式，你可以观察到这种行为：

Product[SalesAmount] = SUM ( Sales[SalesAmount] )
Product[SalesAmountCalc] = CALCULATE ( SUM ( Sales[SalesAmount] ) )

复制代码

由 CALCULATE 引发的上下文转换影响了对相关表的筛选

如你所见，SalesAmount 列包含所有销售额的总计，而 SalesAmountCalc 只包含当前产品的销售额。CALCULATE 通过转换产品表的行上下文将筛选器传递到销售表，最终显示了当前产品的销售。

请注意，当 CALCULATE 计算时，所有活动的行上下文都会发生上下文转换。实际上，在不同的表上可能有多个行上下文。例如，如果你在产品表创建计算列，使用 AVERAGEX 迭代客户表，那么有两个行上下文(产品和客户)将发生上下文转换，销售表将接收两个筛选器。考虑以下表达式：

Product[SalesWithSUMX] =
AVERAGEX (
Customer,
CALCULATE (
SUM ( Sales[SalesAmount] )
)
)

复制代码

公式计算的是消费者购买该产品的平均花费（不是平均价格，而是总花费的平均值）。CALCULATE 中的 SUM 函数在筛选上下文中计值，它只显示当前客户(由 AVERAGEX 迭代)和当前产品（由计算列迭代）的销售额。记住这个规则有一个简单的方法：在 CALCULATE 中没有行上下文，只存在一个筛选上下文。

理解度量值中的上下文转换

理解上下文的转换非常重要，这是因为 DAX 还有另一个隐藏知识。到目前为止，我们一直使用函数和列来编写 CALCULATE 内部的表达式。但是，你还可以编写调用度量值的表达式。如果从计算列内部调用度量值会发生什么？更一般地说法是，如果从行上下文中调用度量值会发生什么？

作为示例，你可以这样定义一个名为 SumOfSalesAmount 的度量值:

[SumOfSalesAmount] := SUM ( Sales[SalesAmount] )

复制代码

然后，你可以使用以下更简单的代码定义 SalesWithSUMX 计算列:

Product[SalesWithSUMX] =
SUMX (
Customer,
CALCULATE (
[SumOfSalesAmount]
)
)

复制代码

自动添加的 CALCULATE

使用 CALCULATE 表明公式发生了上下文转换，问题是，每当你从另一个表达式中调用已定义好的度量值时，DAX 都会自动将度量值封装在 CALCULATE 中。因此，前面的表达式具有与以下表达式相同的行为：

Product[SalesWithSUMX] =
SUMX (
Customer,
[SumOfSalesAmount]
)

复制代码

这个公式没有显式调用 CALCULATE，不过上下文转换依然在发生，因为DAX 自动为度量值添加了 CALCULATE。

这就是为什么编写代码时要从写法上区分列和度量值的原因，我们遵循的书写标准是对度量值使用不完全限定名，列使用完全限定名。也就是避免将表名放在度量值的前面，但始终在列前面加上表名。

实际上，在前面的公式中，在 SumOfSalesAmount 之前没有表名说明 SumOfSalesAmount 是一个度量值，因此，你知道发生了上下文转换。

在嵌套中使用完整公式

上下文的自动转换使编写通过迭代执行复杂计算的公式变得容易。话虽如此，你仍然需要一些时间才能熟悉和使用这种技术。例如，如果你只想计算购买金额超过总体平均水平的客户的销售额总和，可以按如下方式编写度量值：

[SalesMoreThanAverage] :=
VAR AverageSales =
AVERAGEX (
Customer,
[SumOfSalesAmount]
)
RETURN
SUMX (
Customer,
IF (
[SumOfSalesAmount] > AverageSales,
[SumOfSalesAmount]
)
)

复制代码

在前面的代码中，我们使用 SumOfSalesAmount 作为在不同行上下文中计值的度量值。在定义变量时，我们使用它来计算客户销售额的平均值，而在 SUMX 的迭代中，我们使用它来检查当前客户的销售额与之前存储在变量中的平均值之间的关系。

基于 VAR 的语法更易于阅读和维护（公式的计算也可能更快）。然而，本质在于理解不同语法背后不同的公式计值流，可以不用 VAR，也无论你使用的是哪种 DAX 版本。如果没有真正理解和掌握这种上下文自动转换的机制，你可能花了大量时间阅读公式，但依然无法理解它的计算结果。

在公式内部调用度量值时，上下文转换会自动发生，无法避免。这意味着在调用度量值时避免上下文转换的唯一方法是展开它的代码。例如，假设你用另一种方法编写了前面的代码。不使用变量，而是定义一个称为 AverageSales 的度量值表示客户的平均销售额，如下面的代码所示：

[AverageSales] :=
AVERAGEX (
Customer,
[SumOfSalesAmount]
)
[SalesMoreThanAverage] :=
SUMX (
Customer,
IF (
[SumOfSalesAmount] > [AverageSales],
[SumOfSalesAmount]
)
)

复制代码

在突出显示的行中，使用了[AverageSales]计算客户的平均销售额。问题是此时你正在迭代(SUMX)中调用度量值，这会使上下文转换发生。因此，[AverageSales]的结果将不是所有客户的平均销售额，而是你正在迭代的客户的平均销售额。因此，测试总是会失败，度量值返回一个空值，因为 IF 的真值分支永远不会执行。如果想避免上下文转换，你需要将调用的度量值写成完整形式：

[SalesMoreThanAverage] :=
SUMX (
Customer,
IF (
[SumOfSalesAmount]
> AVERAGEX (
Customer,
[SumOfSalesAmount]
),
[SumOfSalesAmount]
)
)

复制代码

使用完整形式后， SalesMoreThanAverage 现在返回正确的结果。此外，值得注意的是，在这种情况下整个公式有两个嵌套的行上下文，三个度量值调用。其中两个计算由 SUMX 迭代的当前客户的销售额, 另一个 (在 AVERAGEX 内部) 计算由 AVERAGEX 迭代的当前客户的销售额。

理解这种特性之后你才能编写复杂的 DAX 代码来解决特定场景的需求。

触发上下文转换的条件

如果用一句话概况，DAX 中只有 CALCULATE 和 CALCULATETABLE 可以触发上下文转换。但在实际应用中，这句话需要你很好的理解，因为它有很多衍生形式，也就是公式中没有可见的 CALCULATE 函数，但上下文转换依然发生。比如：

引用度量值，隐式调用的 CALCULATE
部分时间智能函数，FIRSTDATE/LASTDATE、FIRSTNONBLANK/LASTNONBLANK 等，它们在内部使用 CALCULATE 函数。

上下文转换之后究竟有多少可见行？

上下文转换是指将行上下文转换为等效的筛选上下文。这个说法需要进一步作些澄清。行上下文总是包含单个行，而转换后 CALCULATE 创建的筛选上下文可能包含多个行，可能影响一列或多列，这取决于表结构。

如果模型中的表定义了主键，那么 CALCULATE 就会创建一个只过滤主键的筛选上下文。实际上，这样的筛选上下文包含一行，由主键唯一标识。需要记住的是，主键可以通过使用表的元数据或创建将表作为目标的关系来定义。在这两种情况下，上下文转换都只筛选单个列，又由于主键列是表的唯一标识，因此只过滤单个行。

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

2020 年 5 月更新：感谢标记日期表的作用一文，我详细介绍了与之相关的一种情况。严格来讲这个覆盖行为上下文转换没有直接关系，但它会影响上下文转换的作用范围，比如：

计算列使用的筛选器参数被指定为 2013 年 1 月 1 日

上图中的日期表通过 Date 列与模型的其他表建立关系，因为Date 列是主键列，并且是日期类型，所以它会覆盖日期表其他列的筛选条件，也就是由上下文转换生成的筛选器，使得公式在 2014 年的行中仍然可以返回记录。

这种覆盖行为的目的是为了让时间智能函数可以高效执行筛选，所以只在日期类型或日期时间类型的主键上存在，如果日期表的主键列是整数类型时，可以使用标记日期表功能人为修改主键。

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

如果表没有主键，那么上下文转换将在表的所有列上创建一个筛选器。这可能导致筛选器包含一个或多个行，具体取决于表内容。事实上，如果表中所有行都不同，那么筛选上下文可以惟一标识行。但是，如果表中有相同的行，那么所有相同行都将包含在筛选上下文中。

在下面的示例中，Wrong Sales 和 Correct Sales 返回不同的值:

[Sales Amount] := SUMX ( Sales, Sales[Quantity] * Sales[Unit Price] )
[Wrong Sales] := SUMX ( Sales, [Sales Amount] )
[Correct Sales] := SUMX ( Sales, Sales[Quantity] * Sales[Unit Price] )

复制代码

事实上，Wrong Sales 遍历了销售表，对于每一行，它计算所有相同行的销售额，而 Correct Sales 计算每一行的销售额。因此，如果销售表中有多个相同的行，Wrong Sales 将得到更高的值。

在处理维度表时，这通常不是问题，因为维度中总是有一个主键。在这种情况下，唯一与当前行相同的行就是它自己。对于事实表或一般意义上没有主键的表，需要考虑可能存在重复的行;否则你可能会得到意想不到的结果。

小结

上下文转换性能开销比较大。如果迭代具有 10 列和 100 万行的表并使用上下文转换，则 CALCULATE 需要应用 10 个筛选器，总共 100 万次。无论如何，这将是一个缓慢的操作。这并不是说应该避免依赖上下文转换。然而，它确实是 CALCULATE 的一个需要小心使用的特性。
上下文转换不仅过滤一行。存在于 CALCULATE 外部的原始行上下文始终标识唯一行，因为行上下文逐行迭代。当通过上下文转换将行上下文转换为筛选上下文时，新创建的筛选上下文将筛选具有相同值集的所有行。因此，您不应该假设上下文转换只创建了一个只有一行的筛选上下文，这一点非常重要，需要仔细体会。
上下文转换使用公式中不存在的列。尽管筛选器使用的这些列不可见，但它们仍然是表达式的一部分。这使得任何带有 CALCULATE 的公式都比最初看起来复杂得多。如果使用上下文转换，则表的所有列都是表达式的一部分，作为隐藏的筛选器参数，此行为可能会创建意外的依赖关系。
上下文转换从行上下文中创建筛选上下文。您可能还记得这段表述：“行上下文迭代表，而筛选上下文筛选整个模型”。一旦上下文转换将行上下文转换为筛选上下文，它将更改筛选器的性质，不再只迭代一行，而是筛选整个模型；关系成为表达式的一部分。换句话说，发生在一个表上的上下文转换可能会将其筛选效果传递到远离行上下文来源的其他表。
只要是存在行上下文的环境，上下文转换就会发生。例如，如果在计算列中使用 CALCULATE，会发生上下文转换。计算列中有一个自动生成的行上下文，这足以使转换发生。
上下文转换所有的行上下文。当对多个表执行嵌套迭代时，上下文转换会考虑所有行上下文。它会使所有这些列无效，并为当前由所有活动行上下文迭代的所有列添加筛选器参数。
上下文转换使行上下文无效。虽然我们已经多次重复这个概念，但它值得再次引起您的注意。CALCULATE计算的表达式中没有任何有效的外部行上下文。所有外部行上下文都被转换为等效的筛选上下文。

理解上下文转换后的计值顺序

结合目前所学，相信你已经了解下面这两个在产品表中创建的计算列之间的区别：

Product[SumOfUnitPrice] = CALCULATE ( SUM ( Product[Unit Price] ) )
Product[SumOfAllUnitPrice] = CALCULATE ( SUM ( Product[Unit Price] ), ALL ( Product ) )

复制代码

它们都是计算列，并且都使用了 CALCULATE，因此，两者都发生了上下文转换。

SumOfUnitPrice 应该只包含当前行的单价。然而，SumOfAllUnitPrice 的值是多少？出于直觉，因为有 ALL (Product)，所以你很可能会期望它包含所有单价的总和。结果确实如此。然而，如果你遵循我们迄今所描述的规则，会发现这其中似乎还有一些问题。

事实上，ALL (Product)从筛选上下文删除了产品表的所有筛选器。然而，与此同时，上下文转换将筛选产品表，筛选后的产品表只有一行。如果上下文转换的优先级更高，结果应该是当前行的单价，而不是所有产品的单价之和，但事实恰恰相反。

原因在于通过上下文转换创建的筛选上下文和 CALCULATE 中编程式创建的筛选上下文之间有明确的优先级顺序。CALCULATE 执行上下文转换在先，应用内部筛选器在后。因此，CALCULATE 的内部筛选器可以覆盖由上下文转换创建的筛选器。

图示两种筛选器的先后作用

上下文转换易于使用但难以描述。事实上，上面的两个公式准确地计算出了我们想要的结果。然而，重要的是理解为什么会发生这种情况，核心在于，来自 CALCULATE 内部的筛选器覆盖了上下文转换而来的筛选器（换句话说，内部筛选器稍后应用），这句话是理解上下文转换中计值顺序的关键，计值顺序是上下文转换中最难理解且容易出错的知识点，后续我会追加更多案例详细介绍

这里描述了上下文转换后计值顺序的一般规则，就像你稍后会了解的，作为 CALCULATE 调节器的 KEEPFILTERS 函数可以修改 CALCULATE 的语义，此时执行的是交集而不是覆盖，详情请参考 KEEPFILTERS 的相关内容。

小测试

上下文转换并不是孤立的知识，需要掌握 CALCULATE 函数的计值过程才能正确理解，这里我假定你已经有一定的基础，通过下面三个案例，你可以测试一下自己对上下文转换的理解程度。

案例一

xSUM 是 Table1 的计算列，请思考在下图中它应该返回什么结果？公式是如何计值的？

当前表为 Table1

案例二

xRANK 是 Table2 的计算列，请思考在下图中它应该返回什么结果？公式是如何计值的？

当前表为 Table2

案例文件下载（附结果）

下载链接

案例三

[Test] 度量值的第 9 行 MAX (‘销售明细'[出库日期] ) 是否被第 3 行 VALUES (‘销售明细'[出库日期] ) 影响，为什么？

Test :=
MAXX (
VALUES ( '销售明细'[出库日期] ),
CALCULATE (
SUM ( '销售明细'[下单数量] ),
FILTER (
ALL ( '销售明细'[出库日期] ),
'销售明细'[出库日期]
= MAX ( '销售明细'[出库日期] )
)
)
)

复制代码

案例解析

案例一结果

xSum 列每行都等于 20。以表的第一行为例，公式计值过程如下：

FILTER 在初始的计值上下文环境中计算，不受上下文转换影响，得到的结果是 Table1 表 A 列等于 a2 的所有行<A=a2, B=b2, Value=20>
CALCULATE 将当前行的行上下文转换为等价的筛选上下文，以第一行为例，这个筛选上下文是<A=a1, B=b1, Value=10>
步骤 1 得到筛选器覆盖步骤 2 的筛选器，得到最终的筛选上下文<A=a2, B=b2, Value=20>
CALCULATE 第一参数在步骤 3 得到的筛选上下文中计值，结果为 20
公式每行重复步骤 1-4，完成计值

FILTER 在初始的计值上下文环境是 CALCULATE 的外部环境，即计算列的当前行，只有行上下文（FILTER 忽略行上下文），没有筛选上下文。步骤 3 的覆盖运算，可参考文章中的图解。

案例二结果

xRANK 列从上至下是 2，2，2，1，1，1。以表的第一行为例，公式计值过程如下：

Rankx 第二参数 CALCULATE(SUM(Table2[value])) 沿着表 ALL(Table2[value]) 每行计值，计值环境是调用 RANKX 的计算列的当前行上下文<Category=a, value=1>和 RANKX 第一参数的行上下文（逐行迭代）
CALCULATE 将这两种行上下文转换成筛选上下文，因为 RANKX 第一参数提供的行上下文位于内层，转换后会替换掉同一列（value 列）的来自外部计算列的筛选条件，最终，沿着 RANKX 第一参数的每一行，CALCULATE 的计值上下文和结果分别是：

沿着 RANKX 第一参数每行计值
RANKX 第二参数在调用 RANKX 的环境中再次计值，此时只有计算列提供的行上下文<Category=a, value=1>，结果是 1。注意我们目前讨论的范围始终限定为公式在 Table2 第一行的计值过程。
将步骤 3 得到的结果与步骤 2 中得到 List 值做比较，计算出最终排名 2。
公式每行重复步骤 1-4，完成计值

如果你将 Value 值改为负数，会发现排名有明显的变化，原因是空值在计算排名时自动转换为 0，原因是数据类型和运算符一文中介绍过的隐式转换。

RANKX 的计值流比较复杂，稍后会在 RANKX 公式篇专门介绍。但值得注意的是，公式的实际运行效率经过专门优化，非常快。

案例三结果

不影响。虽然还没有正式介绍 CALCULATE 计值流，通过前面两个示例，你应该已经了解到：CALCULATE 的筛选器参数在调用 CALCULATE 的初始上下文环境中计值，对于本例而言，公式第九行的 MAX() 在调用 CALCULATE 的外部环境中计值，第三行的 VALUES() 在此环境中提供行上下文，而 MAX 忽略行上下文，所以答案是不影响。

Contoso.xlsx (3.52 MB, 下载次数: 0)