玫子甜品菜单一个常见的问题是，为什么Power BI 总计不准确，因为它不是显示的各个行的总和。在本文中，将解释这些总计数出现的原因。

　　在查看报告时，报表使用人员都会仔细检查报表中的总计数是否正常。最简单和最直观的方法是，验证总数是否等于单个行的总和。这种行为非常正常，而且大多有效。但是，总计只是累加度量的行总和，累加度量是自然计算为总和的度量。

　　使用商业智能解决方案时，开发人员迟早会编写非累加计算。此时，由于这一个理由，无法再通过对行求和来计算总数：因为这将是不准确的。当用户抱怨行不相加时，经验丰富的BI 开发人员会合理解释数字未求和的原因：此过程通常可以更好地了解值的计算方式。

　　让我们从一份非常简单的报告开始，该报告展示了该问题。我们希望生成一个报告，显示在不同大洲销售的销售额和产品数量。这两个度量是：

　　该报告清楚地表明，销售额是累加的：总销售额是每个大洲的销售额总和。所有产品的销售额是每个产品的销售额的总和。一年中的销售额是该年每天的销售额之和。事实上，销售额是一个简单的加法衡量标准。

　　Products 度量的行为不同。你可以清楚地看出，在总级别显示的值不是单个行的总和。原因是，如果同一产品在澳大利亚和欧洲同时销售，则在澳大利亚计算一次，在欧洲计算一次，但总数仅计算一次。如果我们要添加单个行，我们最终会得到比实际销售产品数更多的产品，如下面的报告所示，我们在#

　　Products wrong的总数- 顾名思义 -是错误的值。通过修改度量，我们将准确的值转变为不准确的值。

　　为了在列（或表）上引入可加性，我们迭代列（或表的行）的值并计算一组部分结果，然后由SUMX聚合。这是一种标准模式，你应该很快在DAX 学习路径中学习。

　　尽管这只是本文的开头，但第一次回顾已经很有用，因为这是一个重要的主题，细节很重要：

　　计算是累加的还是非相加的并不重要。Power BI 通过观察 DAX 代码中所述的内容并生成符合开发人员意图的加法（或非相加）总计来计算总数。

　　开发人员可以通过引入迭代来制作非累加性度量加法。有时，这是正确的做法;大多数情况下，事实并非如此。

　　在我们概述的具体示例中，引入可加性是不正确的。原因是强制度量值是累加的，这显示了重复计算问题。我们不想重复计算产品，因此我们将措施保留为非添加剂，尊重其性质。请注意，这里没有什么特别的。Power BI 的行为是完全自然的。我们很容易理解这些数字，因为不同的计数在直觉上是非相加的。

　　如果我们不计算不同的计数，而是计算Sales中交易记录的平均折扣，则度量方案会变得更加复杂。平均折扣度量仍然很简单：

　　总计 57.06不是三大洲显示的值的平均值。事实上，通过计算，我们发现55.11+56.91+57.34 等于169.36 除以3，得到56.45。为什么Power BI 显示57.06 而不是56.45？因为56.45 是不准确的。让我们来了解一下原因。

　　Transactions），以美元表示的总折扣也是如此。一个大洲中的交易数量越多，为该大洲计算的值就越相关。在下面的报告中，我们添加了两个度量交易和总折扣，后者以美元表示。

　　Transactions等于平均折扣也是如此。57.06的总折扣是正确的。

　　有时，用户要求通过对单个行求平均值来产生更具可读性的结果的度量值。尽管如此，答案总是（或应该是）相同的：平均部分结果意味着产生平均值的平均值，这是一个不同的数字。平均值的平均值很少是所需的结果。尽管临时用户如果能用计算器检查结果会更高兴，但业务分析师宁愿花时间解释为什么结果是准确的，而不是允许产生不准确的数字。平均值本质上是非加法的。

　　接下来，让我们进一步阐述这个话题。假设无论出于何种原因，我们都希望平均折扣是单个行的平均值。我们可以在整个大洲上引入迭代，就像我们之前在#

　　我们特意保留了最后两列：56.45现在可以解释为显示的平均折扣值的平均值，但不能再通过其最自然的解释来解释：总折扣除以交易数量（#

　　总数中显示的值仍然是56.45。但是，这一次不能通过查看报告中的任何其他数字来解释。在本报告中，平均值应为59.52。作为旁注，按年份浏览时显示59.52，按大洲浏览时显示56.45 会更加令人困惑。

　　问题是：计算平均值的度量是非加法的。因此，它不能从行中的值派生：它需要在总级别进行新的计算。

　　到目前为止，我们分析了两个计算：一个不同的计数和一个平均值。非重复计数显然是非相加的;因此，我们很容易接受它不能通过对行求和来计算。平均值也是非累加的。尽管如此，我们不得不进一步阐述，以说明为什么我们需要接受它的非加性。

　　在这两种情况下，Power BI 都做了正确的事情：它在聚合级别计算度量值;它没有使用显示行中的值来生成一些数字。Power BI 显示的数字始终是正确的数字。

　　有时，由于 DAX开发人员编写的代码不准确，可加性会丢失。让我们看一个写得不好的代码的简单例子。我们创建了一个新度量值，用于显示事务数减去500。DAX新手可能会这样写：

　　具有一定经验的 DAX开发人员会立即发现问题：代码在减法中混合在一起，一个值根据上下文而变化，一个常量值表示相同的数字，无论矩阵通过什么进行切片。可以预见的是，结果看起来很奇怪。

　　Transactions 减去500的三大洲之和应该是12，415，而不是13，415。问题是，通过使用常量值500，我们创建了一个非累加度量值。我们请求的事务数减去500，无论报告筛选依据是什么。在每一行中，度量值显示交易记录数减去500。在总级别，它显示事务数减去500。正是我们所要求的。为什么它没有显示12，415？因为我们没有要求。我们问了交易数量减去500，这就是我们得到的。

　　这种行为有一个很好的理由。总计级别的值为13，415 – 无论报告切片的内容如何。如果我们不是按大洲切片，而是按国家/地区切片，哪又会怎样呢？这是结果。

　　这一次，这个数字似乎更糟。有八个国家;通过按国家/地区对值求和，我们得到9，915。相反，结果仍然是13，415。如果创建非累加计算，然后通过对各个行求和来计算它，则数字会根据用于切片的列而变化。我们可以在下一个示例中仔细检查这一点，我们将交易减去500 错误地包括在内，这迫使在全国范围内增加加法：

　　如你所见，在非累加性度量上强制加法通常会导致不准确的结果。Power BI 不会强制显示结果的相加性，因为它会产生不准确的值。

　　现在我们已经介绍了理论片段，让我们分析一个更实际的例子。我们希望编写一个度量值，用于计算销售额超过1，000，000的国家/地区的销售额。第一个错误的尝试如下：

　　乍一看，Power BI 似乎不知道如何对数字求和。但是，我们了解到问题不在于Power BI;它很可能在我们编写的代码中。要求是显示金额超过1，000，000的国家/地区的销售额。在DAX 代码中，没有提及国家/地区的概念。我们显然错过了一些东西。

　　事实上，由于计算需要在国家/地区级别进行，因此我们需要将DAX代码更改为针对国家/地区的迭代。我们逐个国家/地区检查条件，然后将在国家/地区级别计算的值相加以生成总计。正确的公式如下：

　　该公式现在完全反映了这一要求。事实上，当在报表中使用时，Sales GT 1M会显示正确的总数。

　　你的项目中出现的非累加性计算就越多。每当一项措施是非累加的时，解决方案就是不要以某种天真的方式强制加法。你需要花时间与用户一起了解应在哪个粒度下计算度量值，然后以正确的粒度执行迭代，仅在以后对值求和。

　　非相加性是一个复杂的话题。在本文中，我们只是触及了表面。但是，基本水平的经验足以发现，每当Power BI 显示的总数不准确时，都是因为我们编写了非累加性计算。解决方案始终相同：花一些时间来优化度量值、检查要求并编写适用于任何报表的DAX代码。