为语义模型设计星型模型

你选择了数据流入语义模型的方式。 现在，设计一个星型架构，用于组织它，以便进行明确的高性能查询。 星型架构通过关系将事实数据表与维度表相连，从而创建报表和 AI 消耗所依赖的筛选路径。 如果你熟悉在 Power BI Desktop 中构建星型架构，本单元重点讨论的是在模型复杂度和规模增加时的关键关系设计决策。

语义模型中的星型架构

在星型架构中，事实数据表存储可衡量的业务事件（如销售交易、订单行和 Web 访问），维度表提供描述性上下文（如产品详细信息、客户信息和日期属性）。 维度表通过关系筛选事实数据表，这允许用户按任何描述性属性对指标进行切片。

在 Fabric 语义模型中，此模式为报表以及 AI 应用提供高效的筛选器传播。 当Copilot或数据代理生成自然语言查询时，组织良好的星型架构为 AI 提供了正确的数据路径。 不明确或循环的关系混淆报表使用者和 AI 工具。

存储模式如何影响关系

语义模型中的关系根据存储模式的行为方式不同。 了解这些差异对于设计跨不同方案表现良好的星型架构至关重要。

Direct Lake 关系

在 Direct Lake 模式下，引擎直接从 Delta 表元数据读取关系。 关系在以下情况下表现最佳：

• 维度键列相对于事实数据表行的基数较低。
• 引用完整性保留在源数据中。 当引用完整性保留时，引擎使用 INNER 联接而不是 LEFT OUTER 联接，从而提高查询性能。
• 关系中使用的列在基础 Delta 表中已经编制了索引。

跨源关系

Fabric语义模型可以连接来自不同数据存储的表。 Lakehouse 中的事实数据表可以与仓库中的维度表建立关系，或者与通过 SQL 分析终结点访问的表建立关系。 这些跨源连接使用复合模型功能。

当表来自不同源时，每个表的存储模式决定了关系在查询时的工作方式。 引擎独立解析每一端并联接结果。

关系类型

一对多关系

一对多是星型架构中最常见的关系类型。 维度表中的一个唯一值与事实数据表中的许多行相关。 例如，产品维度中的一个产品行与 Sales 事实数据表中的数千个订单行匹配。

配置一对多关系，使筛选器方向从维度（“一”端）流向事实数据表（“多”端）。 这是标准星型模式过滤模式。

多对多关系

如果两个表都没有关系列的唯一值，则需要多对多关系。 使用桥接表来解决这些关系。 桥接表位于两个表之间，每侧都有独特的按键组合。

例如，如果客户可以有多个帐户，并且一个帐户可以属于多个客户，则 Customer-Account 桥表可以解析关系。 桥接表与顾客表和客户表之间存在一对多关系。

筛选器方向

在大多数星型架构实现中，使用从维度到事实的单向筛选。 这提供了可预测的筛选器传播，并避免了查询结果中的歧义。

有时需要对多对多关系进行双向筛选，或者当维度表需要按事实数据表中的值进行筛选时。 请谨慎使用双向筛选器，因为它们可能会降低查询性能，并在报表中创建意外的筛选器行为。

引用完整性

假设引用完整性设置告知引擎在跨关系查询时使用内联接，而不是左外联接。 在 Direct Lake 和 DirectQuery 模式下，此设置可以显著提高性能，因为它减少了引擎处理的行数。

如果确信事实数据表中的每个外键值在维度表中都有匹配值，请启用此设置。 如果违反引用完整性，则不匹配键的行会无提示地从查询结果中消失。

非活动关系和 USERELATIONSHIP

一次两个表之间只能存在一个活动关系。 当需要多个关系路径（例如订单日期和发货日期都与同一日期维度相关）时，使一个关系处于活动状态，而另一个关系处于非活动状态。

使用 DAX 中的USERELATIONSHIP函数在计算中激活不活动关系：

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

此模式使模型保持干净，同时支持对同一数据进行多个分析透视。

在语义模型中处理雪花模式

源数据通常以规范化的雪花模式到达，其中维度表被拆分为多个相关的数据表。 例如，产品维度可能分为产品、子类别和类别表，每个表通过外键链接。

在语义模型中，有两个选项：将雪花平展为星型架构，或保留规范化结构。

展平为星型架构

平展化是指将规范化维度表合并成一个非规范化维度表。 Product 表将直接包含子类别和类别列，从而减少额外的表格和关系。

在以下情况下展平：

• 组合维度表相对于事实数据表仍然很小（维度几乎总是如此）。
• 您希望能够从维度到事实有更简单的过滤路径。 每个筛选器都通过一个关系而不是链。
• 人工智能使用是一个优先事项。 表格数量减少、关系更简单，让Copilot和数据代理更容易找到正确数据的路径。

在数据到达语义模型之前，在湖仓一体或数据流中的数据准备过程中对维度表进行展平。 使用 Power Query 合并、SQL 联接或笔记本转换将规范化表合并为单个维度。

保留雪花结构

在某些情况下，保持规范化结构是有意义的：

• 维度层次结构具有多个级别，展平操作将会创建数十个冗余列。
• 多个事实数据表共享子维度表（例如 Sales 和 Inventory 事实使用的共享类别表），去规范化可能导致副本不一致。
• 行级安全性需要在层次结构中的特定级别实施。

保留雪花结构时，请仔细配置关系。 链中的每个关系都必须使用从最外层表到事实数据表的单向筛选，以便筛选器正确传播。 类别筛选器需要流经子类别，然后流经产品，最后流向事实数据表。

何时对跨源方案使用复合模型

当星型架构跨越多个Fabric数据存储或包括外部源时，请使用复合模型。 常见方案包括：

• 湖仓一体中的事实数据表，维度表保存在仓库中。
• 来自事件仓的实时流数据与湖仓中的历史数据相结合。
• 来自外部源的参考数据（导入）与 Fabric 原生事实数据表 (Direct Lake) 相结合。

在这些场景中，分别为每个表配置存储模式，并验证跨源关系在预期数据量下的性能表现是否可接受。