Important
此功能目前以公共预览版提供。
借助仪表板关系，可以在 AI/BI 仪表板中的数据集之间对联接逻辑建模，以便可以构建多事实、多粒度的数据模型和可重用的跨数据集度量值，而无需在 SQL 中预先联接数据。 对关系建模一次，然后在仪表板中的每个可视化效果中使用它。
关系可以解决什么问题？
在引入关系功能之前，如果作者想要按区域分组，联接多个事实表中的指标（例如 orders.revenue 和 shipments.cost），就必须先将这两个事实表都连接到区域维度表，并谨慎地进行聚合，以避免扇出——也就是连接操作没有进行一对一匹配，而是使行数倍增时发生的行重复。 该联接逻辑写在 SQL 里，并且在每个需要它的数据集中都要重复一遍。
对于关系，作者只需定义一次联接。 查询引擎根据可视化中的字段，在运行时决定要联接哪些内容。 没有扇出、双计数或重复的 SQL。
仪表板关系的工作原理是什么？
可以通过在两个仪表板数据集中分别选择一个联接字段，并设置基数关系（例如从事实表到维度表的多对一关系），来定义它们之间的关系。 然后，相关数据集形成可遍历图，查询引擎会在查询时解析每个可视化效果所需的联接，因此筛选器和度量值在连接数据集之间流动，而无需在 SQL 中预先联接数据。
一个模型可以跨多个通过共享维度相连的事实表，一个维度还可以以雪花状进一步扩展到更多维度。 图 1 显示了一个模型，其中三个事实表通过四个共享维度连接起来，而这四个共享维度中有两个进一步按雪花模型展开了一层。
图 1. 仪表板关系模型涵盖多个通过共享维度连接的事实表，其中某些维度还进一步扩展了一层雪花结构。 即使是像地理这样的雪花型维度，仍然可以从每个已连接的事实表访问到。
若要创建关系和跨数据集度量值，请参阅 “创建仪表板关系”。
支持哪些数据模型？
仪表板关系会根据关系的指定基数，在查询时对表进行联接。 可以通过一致维度（由多个事实表共享的维度）来联接事实表，但不能通过多对多联接将事实表彼此直接联接起来。
下表说明了支持和不支持的模式，以及在出现不支持的模式时应如何解决：
| Pattern | 支持 | 它的外观 | 解决方案 |
|---|---|---|---|
| 雪花型架构 | ✅ 是的 | 事实数据表连接到一个维度链，例如 Line items → Orders → Customers |
不需要 |
| 共享维度 | ✅ 是的 | 两个事实表连接到同一个一致维度，例如 Orders 和 Shipments 都连接到 Regions |
不需要 |
| 不明确的联接路径 | ❌ 否 | 可通过多条路径从一个事实表访问到的维度，例如 Orders 可通过 Country 和 Regions 两条路径到达 Customers |
为一个路由设置别名，例如 Country (region) 和 Country (customer) |
| 循环关系 | ❌ 否 | 没有唯一明确路径的联接闭环，例如 A → B → C → 返回到 A |
为循环中的一个表设置别名以打破循环 |
如何解决不明确和循环联接路径？
别名之所以有效，是因为表的每个别名实例在图中都是一个独立节点，因此每条连接路径都恰好对应一个目标。 这两种不受支持的模式分别会产生不同类型的重复路径，而别名机制会将其消除。
当事实数据表可以通过多个路由到达同一维度时，会发生不明确的联接路径。 例如，Orders 可以通过 Country 和 Regions 到达 Customers，所以，按国家/地区对订单进行分组的查询有两个候选联接，且无法在两者之间作出选择。 若要解析它，请为每个路由命名维度一次，例如 Country (region) 和 Country (customer)。 随后，每个路由都指向各自的副本，因此像“客户国家/地区”这样的字段只会解析到唯一一条路径。
图 2. 为共享维度设置别名后，每条路由都有各自的目标，因此联接路径不会产生歧义。
循环关系是由联接构成的闭环。 如果 Orders 与 Regions 联接，Regions 与 Customers 联接，且 Customers 再联接回 Orders，这个循环就不会给查询引擎提供一个明确且无歧义的起点或终点，因此它无法解析这些联接。 若要解决该问题，请为循环中的其中一个表设置别名，从而将其拆分为一条查询引擎可以从头到尾遵循的单一路径。 在图 3 中，A、B 和 C 表示此类循环中的任意三个表，而 A′ 是打破该循环的别名。
图 3. 为循环中的某个表设置别名，可将该循环打破为一条可遍历的路径。
跨数据集度量值的工作原理是什么？
当事实数据表共享一个符合的维度时，可以在模型级别定义一次度量值，并使其绘制在多个事实数据表上。 查询引擎独立聚合每个事实数据表，并将结果合并到共享维度上，因此无论查看器添加到可视化效果中的哪些字段，度量值都保持正确。
例如，将Orders、Shipments和Returns通过共享维度联接起来后，可以在模型级别定义如下跨数据集度量值：
Net Revenue = SUM(Orders.revenue) - SUM(Returns.refund)
Fulfillment Rate = SUM(Shipments.units) / SUM(Orders.units)
Return Rate = SUM(Returns.units) / SUM(Orders.units)
每一个都同时绘制两个事实数据表，无需扇出或双计数。 图 1 显示了其所依赖的共享维度，其中三个事实表在四个一致维度处汇合。
字段顺序为何重要
添加的第一个字段会设定根表，其他所有字段都基于该表进行解析。 从这一根节点开始，三种类型的字段行为各不相同：
| 字段类型 | 可从非根表访问？ |
|---|---|
| 字段（维度） | 是的，可以通过任意多对一链路，无论经过多少跳 |
| 度量值（聚合） | 是的，它独立聚合，然后在共享维度上联接 |
| 原生列（未聚合） | 不是，除非该事实数据表是根节点。 |
因此，从 orders revenue 开始，customer region 和 shipments cost 都可用，但 ship mode 不可用：它是 Shipments 上的原始列，无法访问，因为 Shipments 不是根。 改为从 ship mode 开始，这样根节点会翻转，因此现在 Shipments 自身的列也可用了。
仪表板关系如何与指标视图进行比较？
两者都可以对相同的联接图建模，但它们可以解决不同的问题：
- 指标视图是固定粒度。 使用 SQL 直接查询它们，非常适合星型和雪花型架构。
- 仪表板关系是动态粒度。 它们允许你混合和匹配语义图中任何表中的字段和度量值，因此它们更适合跨多个事实数据表进行建模。
仪表板关系图可以包含作为节点的指标视图，而关系则作为连接这些节点的边。 指标视图处理单粒度层面的逻辑，关系则处理其上的多事实层。
| 方面 | 仪表板关联 | 指标视图 |
|---|---|---|
| Scope | 单一仪表板 | Unity 目录，跨仪表板、Genie 代理和其他工具共享 |
| 最适用于 | 原型设计、针对仪表板的分析、快速迭代 | 需要持续管理和重复使用的指标 |
| 创建 UC 对象 | 否 | 是的 |
如果从仪表板关系开始，以后需要管理并共享相同的模型，则可以将其提升为指标视图。 请参阅 Unity Catalog 指标视图 和 导出到 Unity Catalog 指标视图。 有关 AI/BI 仪表板中提供的所有数据建模选项的更广泛比较，请参阅 “选择正确的方法”。
固定粒度和动态粒度之间的区别是什么？
粒度会影响您可以选择哪些字段，以及这些字段的呈现粒度。 指标视图会将表锁定在固定粒度上，例如客户级别；而关系则是动态的，取决于仪表板中使用的字段，例如按客户、订单或发货级别。
差异归结于根。 指标视图在定义阶段将根固定在维度中：Customer 始终是根，因此每个查询都按 Customer 分组，并且字段选择器也只会提供 Customer 作为分组字段，尽管它仍会从任何已连接的事实表中提取度量值。 仪表板关系改为按每个查询选择根表：Orders或Shipments都可以作为根表，具体取决于你先添加哪个字段，因此字段选择器允许你按任何已连接的表分组，而不只是按维度分组。
图 4. 根节点在指标视图中是固定的，但在仪表板关系中会针对每个查询单独选择。
尽管存在这种差异，但两者共享相同的基础限制：仍不能将一个事实数据表的度量值直接分组到另一个事实数据表的列中，因为两者仅在共享维度上满足。
为什么仪表板关系的范围限定为仪表板？
Unity Catalog 对关系的支持正在开发中。