为什么我的 SUMX DAX 函数会返回此结果？

Question

假设我有 2 张桌子：

fTransactions

ProdID  RepID  Revenue
1       1      10
1       1      10
1       2      10

dSalesReps

RepID   RepName
1       joe
2       sue

dSalesReps 具有以下度量但尚未应用过滤器：

RepSales:=CALCULATE(SUM(fTransactions[Revenue]))
RepSales2:=SUMX(fTransactions, CALCULATE(SUM(fTransactions[Revenue]))

第一个措施执行我认为的方式。它转到 fTransactions 表并汇总 Revenue 列。

第二个措施，经过大量的试验和错误来弄清楚，似乎在 fTransactions 中的唯一行上将自己分组。在上面的示例中，fTransactions 有 2 行所有内容都相同，最后一行内容不同。这似乎导致以下结果：

(10 + 10) 对第一个“分组”求和的第一次迭代
+
(10 + 10) 第二次迭代，再次对第一个“分组”求和
+
(10) 对第二个“分组”求和的最后一次迭代

= 20 + 20 + 10 = 50

至少它看起来是这样运作的。我只是不明白为什么。我认为它会转到 fTransactions 表，将每次迭代的所有收入相加，然后将这些总和作为最后一步。

Answer 1

这是由称为“上下文转换”的东西引起的（请参阅sqlbi 更详细的解释）。

在实践中，您的公式“RepSales”使用“行上下文”（由 SUMX 创建），该“行上下文”被转换为等效的“过滤上下文”（由 CALCULATE），但由于您在表中没有唯一键，它在每次迭代中获取并使用多行，在说明下方。

对于第一行，行上下文是 ProdID=1 AND RepID=1，这会转化为等效的过滤上下文（在这种情况下保持不变）是 ProdID=1 AND RepID=1 但过滤器上下文是全局的，并且两行（前 2 行）与此过滤器匹配。 对每一行重复此操作。

公式“RepSales”不会发生这种情况，因为它不会重复多次（正如您已经注意到的那样）

这是你目前的情况：

为了证明这一点，只需在事务表中添加一个 rowID：

这不会发生，因为等效的过滤上下文还包括 RowID 列，它只匹配一行

希望对你有帮助，参考 sqlbi 文章，这将是理解这一点的详尽指南