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

Question

假设我有 2 张桌子：

f交易

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 表，对每次迭代的所有收入求和，然后将这些总和作为最后一步。

标签： exceldaxpowerpivot

Answer 1

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

在实践中，您的公式“RepSales”使用“行上下文”（由 SUMX 创建），它在等效的“过滤上下文”（由 CALCULATE）中打开，但由于您在表中没有唯一键，因此它得到并在每次迭代中使用多行，在说明下方。

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

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

这是你目前的情况：

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

它不会发生，因为等效的筛选上下文还包括 RowID 列，该列仅匹配一行

希望这会有所帮助，使用 sqlbi 文章作为参考，这将是理解这一点的详尽指南