通过在表之间建立数据关联，在模型中定义初始逻辑，以便对数值进行汇总、筛选和切片分析。
在本系列中，我们分享如何高效构建语义模型的实用技巧。 在上一篇文章中，我们介绍了如何连接并转换数据，以便在语义模型中使用。 到这里，你的模型里已经有了表和列，可以开始添加业务逻辑了。
本文将介绍通过在表之间创建关系来添加这些逻辑的最初步骤之一。 关系是模型中最重要的对象之一。 但它们也很容易让人误判：创建关系很直接，但类型和属性却很多。 如果关系及其关联列未正确设置，就很容易在模型中引发问题。
注意 |
什么是关系？为什么它如此重要？
关系让你可以用第二张表的列来筛选或分组第一张表的数据。 为此，你要在每张表中匹配等价的列（称为键列，或键）。 关系是从一组彼此孤立的数据点，过渡到可用于描述业务流程的功能性模型的关键。
图 1： 你通过关系，按“Customer”、“Region”或“Date”维度对“Invoices”表中的数据进行分组。 使用关系而不是把这四张表直接联接起来，可以让模型更有条理、性能更好。 例如，你可以创建一个矩阵（或 Tabular Editor 中的 Pivot Grid），按 ‘Regions’[System]、‘Customers’[Key Account Name] 和 ‘Date’[Calendar Year]（例如 2021）列汇总发票明细（来自 ‘Invoices’）。
在模型中，你可以创建不同类型的关系，但物理关系最常见。 这些关系是在模型视图中用表之间的箭头表示的。 你在两列之间创建关系，并指定关系方向以及它是否处于活动状态。 在语义模型中，物理关系使用内存中的数据结构，以便在相关表之间高效导航。 这些内存数据结构在概念上类似于 SQL 索引，但不同之处在于，它们源自 VertiPaq 如何在内存中压缩和存储数据。
在其他博客、视频和文章中，你会听到不同类型的物理关系。 下图按基数对关系进行了概览（含示例）。
图 2： 关系在基数上有所不同，例如一对多（或多对一）、一对一，以及 多对多。 它们在方向性上也不同，包括单向和双向关系。 一对一关系必须是双向的，但其他关系类型既可以是单向，也可以是双向。 请注意，这个示例展示的是受限的单向多对多关系，而不是双向多对多关系。
警告直到最近，默认 Tabular 模型中的关系都是不区分大小写的。 这意味着键列中的大小写不会影响该关系的基数。 不过，在 Fabric 中创建的 Direct Lake 模型里的关系是区分大小写的，因为这些语义模型使用区分大小写的排序规则。 通常，Power BI Desktop 中的Power BI 语义模型的排序规则属性为空。
图 3：你在 Fabric 门户（即 Lakehouse 体验）中创建的 Direct Lake 语义模型具有区分大小写的排序规则属性。 这是一种新的行为，与之前使用 Power BI Desktop 创建的导入和 DirectQuery 模型不同：那些模型的排序规则为空。 区分大小写的排序规则意味着：关系一侧的值会要求另一侧的值在大小写上完全一致。 如果你在关系中使用整数代理键，则不会受到影响；当然，64 位整数不存在排序规则。 看看下面的示例：
图 4：在 Power BI Desktop 创建的典型导入或 DirectQuery 模型中，大小写既不会影响模型推断的基数，也不会影响在 Power BI Visual 中显示的DAX 查询结果。 相反，区分大小写的模型在确定关系基数并返回查询结果时会考虑大小写。 在转换数据并准备把它用于 Direct Lake 语义模型时，记住这一点。 当你在 Fabric 门户中通过 Web 创作创建 Direct Lake 模型时，记得提前考虑这种大小写敏感性带来的影响。 要创建不区分大小写的 Direct Lake 模型，你必须先使用 Tabular Editor 创建它，然后将其部署到 Fabric 门户。 不过要注意，Fabric Warehouse 的 SQL 终结点使用区分大小写的排序规则，因此在这种情况下，DirectQuery 回退可能会产生与 Direct Lake 不同的结果。 为避免这种情况，你可以将 Direct Lake 回退设置为“仅回退到 Direct Lake”。 排序规则一旦设置，就无法更改。 |
如何创建关系
你可以使用 Power BI Desktop 和 Tabular Editor 来创建和管理关系。 正如本文引言所述，创建关系很容易；难的是确保你配置了正确的键列和属性。
使用 Power BI Desktop 创建关系
你可以在 Power BI Desktop 的模型视图窗口中通过界面创建关系，如下图所示。 注意，默认情况下，当你首次加载或刷新本地语义模型时，Power BI Desktop 会自动检测关系。
图 5：在 Power BI Desktop 中，你可以在模型视图中创建关系。
你可以通过三种方式在 Power BI Desktop 中创建关系。
- 在模型视图中拖放：选择模型视图，找到相应的表，然后将“from”键列拖到“to”键列。 你可以双击任意关系以编辑其属性。
- 关系编辑器：在模型视图顶部选择“管理关系”，然后选择“新建…”来创建新关系。 你也可以管理现有关系。
- 自动检测关系：Power BI Desktop 默认会自动检测名称和数据类型相似的列之间的关系。 你可以在 Power BI Desktop 选项中调整此行为。 在使用 Power BI Desktop 开发语义模型时，通常建议禁用自动关系检测，因为当你新增列或修改现有列的名称和数据类型时，它可能会创建意外的关系。
提示Power BI Desktop 会自动停用会造成歧义的双向关系。 当你尝试激活这些关系时，系统会就这些存在歧义的路径向你发出警告。 你应避免创建存在歧义的模型，因为它会产生意外的查询结果。
图 6：如果你尝试激活一个会导致歧义、处于非活动状态的关系，Power BI Desktop 会给出警告。 |
|
|
使用 Tabular Editor 3 创建关系
你可以在 Tabular Editor 中通过用户界面或 C# Script 对话框创建关系，如下图所示。
图 7：在 Tabular Editor 中，你可以在模型图表视图、TOM Explorer 或通过 C# Script 创建关系。
在 Tabular Editor 中，你可以通过四种不同方式创建关系。
- 模型图表：创建新的模型图表，添加表，然后将“to”键列拖到“from”键列。 注意，这与 Power BI Desktop 的方向相反。 你可以右键单击任意关系以编辑其属性。
- TOM Explorer（关系组）：右键单击“关系”组，然后选择 Create > Relationship。 你也可以选择任意现有关系，并在属性窗口中修改其属性。
- TOM Explorer（键列）：右键单击某个键列，然后选择 Create > Relationship From 或 Relationship To。 在接下来的关系对话框中选择表时，Tabular Editor 会自动推荐适合作为关系键的列。
- C# Script：你可以使用 C# Script 以编程方式创建和修改关系。 例如，你可以使用 C# Script 在名称或数据类型相似的列之间自动创建关系，或基于你指定的其他元数据来创建关系。 你可以根据需要调整它，以便使用更多元数据，甚至使用 DAX 查询结果，并将脚本保存为宏，这样你每次创建新模型时都能运行它。
提示当你尝试创建可能存在 RI 违规或其他潜在问题的关系时，Tabular Editor 3 会向你发出警告。 你可以在 新建关系 对话框或 信息 窗口中找到这些警告。
|
关系看似简单，但远不止拖放那么回事。 这取决于参与的键列以及你配置的关系属性，你可能会得到不同的查询结果、性能和功能表现。
创建关系时，你应该检查以下内容：
- 基数是否符合你的预期？ 大多数关系都应从维度表到事实表为一对多。 如果你打算使用不同的关系基数，例如 多对多 或 一对一，确保你了解它对模型性能和查询结果的影响。
- 方向性是否符合你的预期？ 大多数关系都应为从维度表到事实表的单向关系。 如果你打算使用双向关系——通常应避免——请确保你能 避免歧义，并了解它对模型性能和查询结果的影响。
- 关系是否为活动状态？ 大多数物理关系都应该是活动的，除非你在使用 角色扮演维度，并在 CALCULATE 中使用 USERELATIONSHIP DAX 函数来激活该关系。
- 是否存在缺失键？关系要有效，就必须确保引用完整性，也就是说：事实表中（在一对多关系的“到”端或“多”端）的所有值，都应在维度表中（在一对多关系的“从”端或“一”端）有对应的值。 如果存在缺失键，最终会出现一些值映射到 (Blank) 或空白行。
注意在某些场景下，使用多对多或双向关系等非典型属性也可能是合理做法。 但只有在你测试过它们对模型的影响，并理解其后果之后，才应选择这些非常规方案。 |
根据你要构建的模型以及需要满足的 需求，关于关系还有许多进阶概念可能对你很有帮助。
- 日期数据类型列之间的关系：日期列之间的关系会被当作 DateTime 数据类型来处理，即使其格式设置为 Date、Time 或 Date/Time/Timezone 也是如此。 当你必须在日期和整数数据类型列之间做选择时，还需要考虑一些 特殊因素。
- 当你创建日期维度表并决定它如何与事实表建立关系时，通常会遇到这一点。
- 整数列之间的关系与性能：人们通常认为，整数列之间的关系比其他数据类型列之间的关系性能更好。 但与关系数据库不同，实际情况并不总是如此。
- 这通常会在你设计模型并转换数据时遇到。
- 虚拟关系：一种你在 DAX 度量值或计算列中定义的关系类型。 为此，你会使用诸如 TREATAS 之类的函数，它可以将筛选语境从一张表传递到另一张表。 与物理关系不同，虚拟关系无法利用关系索引，因此性能更差。
- 你会用虚拟关系来实现多种不同的高级功能和特性。 例如，如果你想进行选择性度量值替换，或者想同步 Report 切片器。
- 无效关系与 (Blank) 行：如果关系存在引用完整性违规，模型会添加一行 (Blank)。 引用完整性违规是指：在 N 端表中出现了“孤立行”，因为键包含一些值，而这些值在关系另一端没有对应值。 在验证关系时，你可以识别 RI 违规（将在本系列的下一篇文章中讨论）。 例如，你可以在 Tabular Editor 3 中使用 VertiPaq分析器来识别 RI 违规，并查看缺失值示例。
- 当事实表中存在维度表缺失的键时，你经常会遇到这种情况。 例如，‘Budget’ 表中出现了新客户，但你还没有为他们建立客户主数据记录。 这是一个常见的问题。
- 非活动关系：一种默认不会使用的关系，除非在 DAX 中通过 USERELATIONSHIP 函数将其激活。 你会在使用角色扮演维度时用到非活动关系。 在判断参照完整性违规，以及 VertiPaq 引擎是否应向表中添加 (Blank) 行时，非活动关系也会被计入。
- 当某个维度，例如 Date，需要与事实表中的多个列建立关系时，你可能会用到它，例如 [Order Date]、[Billing Date] 和 [Goods Issue Date]。 例如，你可能希望让用户选择用哪个日期来汇总数据。
- 双向关系与 DAX 中的歧义：一种场景：多个双向关系可能会形成替代路径来传播筛选器。 在汇总数据时，这可能会产生意料之外的结果。
- 当你决定在模型中使用双向关系时，可能会遇到这种情况。 如果你用双向关系来同步切片器（不建议这么做；有更好的方法）。
- 双向关系与行级安全性 (RLS)：一种场景：你使用双向关系，并选择让安全筛选器也在两个方向上传播。
- 当你在语义模型中为某个表配置了 RLS，而该表处在一个关系链中，且其中一个或多个关系使用了双向交叉筛选时，你可能会遇到这种情况。
- DAX 中的扩展表：DAX 中的一个概念：在多对一或一对一关系中，“基表”会包含所有相关表的列。 在某些 DAX 表达式中，你会使用扩展表来访问被引用表的相关列。
- 当你想进行更高级的 DAX 计算时，可能会用到这一概念。 例如，当你想做动态货币转换时。
- 有限关系：一种概念：无法保证参照完整性；一对多关系中并不存在可保证的“一”端。 有限关系不会使用扩展表。
- 当你使用多对多关系，或在某些复合模型中使用关系（也叫跨源组关系，cross source group relationships）时，可能会遇到这种情况。
- 假定参照完整性：当你的语义模型处于 DirectQuery 存储模式时，你可以在 Power BI Desktop 或 Tabular Editor 中启用的关系属性（在 Tabular Editor 中称为 Rely on Referential Integrity）。 启用“假定参照完整性”后，表之间会使用内连接而不是外连接，从而可能提升性能。 这种性能提升取决于 DirectQuery 模型所用源数据库中的查询规划器和索引。
- 当你构建并优化 DirectQuery 模型，或启用了 DirectQuery 回退的 Direct Lake 模型时，可能会遇到这种情况。
注意建议使用关系并创建星型架构，但绝非强制。 这取决于你的需求以及数据的形态，你可能根本不需要一个使用关系的模型。 例如，刚开始使用 Power BI 的自助式用户通常会先从分析一张大表入手。 这是一种完全可行的做法。 |
结论
关系是模型中最重要的对象之一，也是你在设置好表和列之后最先创建的对象。 创建关系很简单，但要让关系按预期工作，还需要考虑许多额外属性和使用场景。 在本系列的下一篇文章中，我们将演示如何使用 Power BI Desktop、Microsoft Fabric 和 Tabular Editor，在语义模型中验证你的关系。
