在设计数据模型时，有一个涉及复杂内容的主题需要注意，即公式中的循环依赖关系。在本节中，你将学习什么是循环依赖以及如何在模型中避开循环依赖。

线性依赖

在讨论循环依赖之前，有必要先讨论简单的线性依赖关系。让我们看一个示例，其中包含以下计算列：

Product[Profit] = Product[Unit Price] - Product[Unit Cost]

新的计算列依赖于同一表的另外两列。在这种情况下，我们说利润列取决于单位价格和单位成本。然后，你可以用以下公式创建一个名为 ProfitPct 的新列：

Product[ProfitPct] = Product[Profit] / Product[Unit Price]

很明显, ProfitPct 的结果取决于利润和单价。因此，当 DAX 计算这两列时，它知道只有在计算利润之后才能计算 ProfitPct。否则就无法计算出 ProfitPct 公式的有效值。

线性依赖通常不需要担心，DAX 会在数据模型刷新期间检测到计算列之间的正确计值顺序。在一个有许多计算列的普通数据模型中，列之间的依赖性形成了一个复杂的关系图，但引擎可以很好地处理这个问题。

当这个关系图中出现循环引用时就会发生循环依赖。例如，如果你试图按以下方式修改 Profit 公式，循环依赖就会发生：

Product[Profit] = Product[ProfitPct] * Product[Unit Price]

因为 ProfitPct 依赖于 Profit,，而在这个新公式中，Profit 依赖于 ProfitPct， DAX 拒绝修改公式, 并显示错误 “检测到循环依赖关系”。

到目前为止，你已经从公式的角度了解了什么是循环依赖；也就是说，不需要注意表中的数据，你在查看表达式时已经发现了依赖项的存在。不过，通过 CALCULATE 还可以产生一种更微妙、更复杂的依赖关系。让我们从产品表的子集开始，用一个示例来展示这个场景，请注意在本例中我们只加载了产品表，从模型中删除了所有其他表，以便使场景更加明显。

产品表的这个子集对于理解循环依赖关系很有用

我们的兴趣在于了解使用了 CALCULATE 函数的新计算列的依赖关系列表，如下所示:

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

乍一看，这一列似乎只取决于单价，因为这是公式中使用的唯一一列。不过，请注意我们使用了 CALCULATE 将当前行上下文转换为筛选上下文。因为我们没有定义与其他表的关系，也没有为它设置主键，所以当 CALCULATE 进行上下文转换时，它会筛选表的所有列。如果我们扩展 CALCULATE 调用的含义，公式实际上说的是:

检查产品表中对于 Product key、Product Name、Unit Cost 和 Unit Price 具有相同值的所有行，将它们的 Unit Price 值相加。

如果你以这种方式阅读公式，可以清楚地发现，代码依赖于产品表的所有列，因为新引入的筛选上下文将筛选表的所有列。你可以在图中看到结果。

在这里可以看到带有 SumOfUnitPrice 计算列的产品表

你可以尝试使用相同的公式在同一个表中定义一个新的计算列。比如使用以下公式定义 NewSumOfUnitPrice，这个公式与前一个公式相同。

Product[NewSumOfUnitPrice] = CALCULATE ( SUM ( Product[Unit Price] ) )

观察循环依赖现象

令人惊讶的是, 此时 DAX 提示了一个错误, 称它检测到循环依赖关系。这很奇怪, 因为它在相同的的公式中检测到了以前没有发现的循环依赖关系。这其中的原因在于表的列数发生了变化。假设我们能够将 NewSumOfUnitPrice 添加到表中, 这两个公式将分别具有以下含义：

• SumOfListPrice 对产品表中的以下 5 列有相同值的所有行的单价求和，这 5 列分别为 ProductKey, Product Name, Unit Cost, Unit Price 和 NewSumOfListPrice。
• NewSumOfListPrice 对产品表中的以下 5 列有相同值的所有行的单价求和，这 5 列分别为 ProductKey, Product Name, Unit Cost, Unit Price 和 SumOfListPrice。

任何添加到数据模型中的计算列都成为由 CALCULATE 引入的筛选上下文的一部分，因此所有计算列都成为依赖列表的一部分。阅读上述定义，两个公式之间存在着明确地循环依赖，这恰恰是 DAX 拒绝创建 NewSumOfListPrice 列的原因。

解决方案

理解该错误并不容易，但是找到解决方案很简单，即使这个方案看上去不是很直观：

如果表没有主键，任何包含 CALCULATE（或对任何度量值的调用，这些调用都自动添加一个 CALCULATE）的计算列都会创建对表的所有列（也包括计算列）的依赖关系。如果表中有一个行标识符（用数据库术语来说是主键），情况将会有所不同。当表中含有这个作为行标识符的列时，包含 CALCULATE 的所有列仅依赖于该行标识符，从而将依赖列表的数目降低到单列。

在产品表中，有一列可以唯一地标识出每一行，即 ProductKey。要将 ProductKey 标记为行标识符（主键），你有三种选择：

• 使用 ProductKey 列创建事实表和产品表之间的关系。执行此操作将确保 ProductKey 列可以唯一区分产品表。
• 在 Excel PowerPivot 中，你可以使用表行为属性设置将 ProductKey 列设为行标识符。
• 在 Power BI Desktop 中，你可以在模型视图 – 属性 – 常规 – 键列 中为当前表设置包含唯一值的列。

以上任一操作都会使得 DAX 知道该表中存在行标识符，避免了在定义 NewSumOfListPrice 列的同时遇到循环依赖，因为使用了 CALCULATE 的两个计算列都只依赖于新设置的主键列。

例外情况

通过上面的介绍，我们已经知道 DAX 中的循环依赖绝大部分都是由于 CALCULATE 在执行上下文转换时产生的，但上下文转换并非发生始终发生在所有情境中，在某些特殊情况下，DAX 引擎会避免发生这种转换。观察下面这个案例，c1 列是 Table 表的原始列，cc1 和 cc2 是计算列，这里并没有提示循环依赖。

按照我们之前的理解，上下文转换会使得 cc1 和 cc2 互相依赖，而实际上，