PowerBI总计行错误问题有什么彻底解决方法？

我是BI佐罗，总计行错误，这是一个老生常谈的问题，本回答将给你终极解决方案，并带您重新理解一种模式，从入门级到专业级，均有您需要的营养。 （文末有赠送Power BI学习课程福利）。

您可以直接使用本回答的模式和套路立刻优化您的计算。

问题重现

如果你使用 DAX 很快就会发现总计行的问题。例如：

Topic.Problem =
// 这个度量值的总计行会有问题
[KPI] + 1000

出现错误的情况：

很容易看出总计行并不等于以上各行的和，然后大家会觉得 PowerBI 很傻，这个都不能算对。

其实大家误解 PowerBI 了。我们来仔细看看。

原因分析

对于 业务用户 会很自然地认为 总计 = 以上各行的和 。

那再来看看这个案例：

这里的总计行就不等于以上各行的和，而且必须不等于。业务用户会说，嗯，应该不等于。

所以，问题来了：

你到底希望总计行等于以上各行的和还是不等于以上各行的和呢？

得到的答案往往是，该等于的时候等于，不该等于的时候就不等于。晕~~~

理解 PowerBI

PowerBI 进行这项计算的主要方式是通过 DAX，考虑到 通用性 和 一般性 ，DAX 的设计满足：

在可视化层的汇总表的每个单元格都在独立的环境计算。

这就是筛选上下文的根源。

但是，很多情况是 总计 = 以上各行的和 。那么如何处理这个问题呢？

为了把这个问题揭露得更加彻底，让我们来彻底地吐槽出来先：

• 总计 = 以上各行全部的和
• 小计 = 在本区间内各行的和
• 如果用户做出了部分筛选，总计和小计的计算也应该是正确的

能同时满足上述三项的才是好方法。

问题分析

对于这个问题，我们此前就给出了解决方案，很多 DAX 玩家也使用了不同的方式。但今天我们给出更全的方式，而且是一个通用套路。

微软也已经发现了这个问题，就是在可视化层面目前没有给出一个计算方案。用英文的准确写法是：Visual Calculation。

DAX 的强大就在于灵活的上下文，尤其是筛选上下文。而出现的总计行问题也是由总计行引发的。

一般的思路是：

判断当前的计算环境，如果是总计行就计算全部，如果是小计行就计算当前部分，如果是元素行就默认计算。 但问题是，如果用户在最外部筛选了部分元素呢 。

以上这句加粗的如果您还看懂说明还没有掉入这个坑，这是为了您下次回看准备的。

问题的深化

如果认为问题这就结束了，就错了，还会出现四种不同的演化：

• 单列总计
• 多列总计，但属于同一个表
• 多列总计，且不属于同个表，但有共同的桥表
• 多列总计，彻底独立不同表

直接给答案

请仔细观察以下方案：

我晕，这是什么鬼~

左边的蓝色框反映了前 3 种情况，即：

• 单列总计
• 多列总计，但属于同一个表
• 多列总计，且不属于同个表，但有共同的桥表

右边的蓝色框反映了第 4 种情况，即：

• 多列总计，彻底独立不同表

值得注意的是，它们在外部的部分筛选下，还保证了计算的正确性。

下面分别说明。

在继续阅读之前，我们先给出一个套路，然后按照这个套路来看实现，最后再总结这个套路。

总计行通用套路

处理总计行计算，需要分二步：

• 第一步，定义元素计算，例如命名为：
  [KPI.Row]；
• 第二步，定义兼容计算，例如命名为：
  [KPI.Display]，该度量值放置后可确保元素行，小计行，总计行全部计算正确，且在部分筛选下依然正确。

其实，平时我们使用的度量值是[KPI.Row]，之所以出现总计行问题，也是因为没有考虑总计行问题。

在第二步中谈到的 兼容计算 ，就是为了兼容元素，小计，总计，外部筛选等苛刻条件，保持极高的用户友好。

这里涉及一个关键函数是：SUMX。

套路： 用 SUMX 按分组对 [KPI.Row] 进行包裹 。即可。

下面从具体的案例来说明这个套路。

【情况1】单列总计

度量值：

Topic.Value.Display.FromOneTable.OneColumn =
SUMX( VALUES( Model_Product[类别] ) , [Topic.Value.Row] )

Topic.Value.Display.FromOneTable.OneColumn 只是个名字，不必在意。

效果：

请体会这个套路。

【情况2】多列总计，同表

这种情况比上面的情况更加复杂，因为可能是多列，但他们都来自同一个表。

度量值：

Topic.Value.Display.FromOneTable.MutiColumns =
// 多列总计，但多列来自同一个表
SUMX(
    SUMMARIZE(
        Model_Product ,
        Model_Product[类别] ,
        Model_Product[子类别]
    [Topic.Value.Row]

效果：

请体会这个套路。

【情况3】多列总计，不同表，同桥

这种情况更加复杂，多列来自不同的表，当然，有个特点是他们有一个共同的桥。

什么是桥表？
在多个一对多关系中，作为共享的多端的表，就是桥表。
从连接的角度，叫做桥表；从数据仓库的角度，叫做事实表；从业务人员的角度，叫做明细表。

度量值：

Topic.Value.Display.FromMultiTable.ButSameBirdge =
// 多列总计，多列来自不同的表，但共享一个桥表
// 什么是桥表，在多个一对多关系中，作为共享的多端的表，就是桥表。
// 从连接的角度，叫做桥表；从数据仓库的角度，叫做事实表；从业务人员的角度，叫做明细表。
SUMX(
    SUMMARIZE(
        Model_Order ,
        Model_Product[类别] ,
        Model_User[细分]
    [Topic.Value.Row]

效果：

值得说明的是， 产品[类别] 和 客户[分类] 来自不同的表，但都都与 订单表 相连。如下：

其中的核心 DAX 技巧在于：

SUMMARIZE( Model_Order , Model_Product[类别] , Model_User[细分] )

用桥表用做 SUMMARIZE 的第一个参数，与桥表连接的表的列都可以用作后续参数，则这个 DAX 表达式会返回合理的多列分组。

值得一提的是，这里的 产品[类别] 和 客户[分类] 是一个多对多的复杂关系，但也被轻松化解了。完全一模一样的套路。

【情况4】多列总计，不同表，无桥

这种情况更加更加复杂，多列来自不同的表，而且没有共同的桥表。如下：

度量值：

Topic.Value.Display.FromMultiTable.WithoutBirdge =
// 多列总计，多列来自不同的表，且没有桥表可以连接
SUMX(
    CROSSJOIN(
        VALUES( 'Data.A'[Item] ) ,
        VALUES( 'Data.B'[Item] )
    [Topic.X.Row]