在 Power BI Desktop 中使用复合模型

之前在 Power BI Desktop 中，当在报表中使用 DirectQuery 时，禁止该报表使用其他数据连接（无论是 DirectQuery 还是导入）。 有了复合模型后，便删除了该限制。 一个报表可以在所选择的任何组合中无缝地包含来自多个 DirectQuery 或导入数据连接的数据连接。

Power BI Desktop 中的复合模型功能包括三个相关功能：

• 复合模型：允许报表具有来自不同源组的两个或更多数据连接。 这些源组可以是一个或多个 DirectQuery 连接和一个导入连接，两个或多个 DirectQuery 连接，或其任意组合。 本文详细介绍了复合模型。

• 多对多关系：借助复合模型，可以在表之间建立多对多关系 。 这种方法删除了对表中唯一值的要求。 它还删除了旧解决办法，如为建立关系而仅引入新表。 有关详细信息，请参阅在 Power BI Desktop 中应用多对多关系。

• 存储模式：现在可以指定哪些视觉对象需要查询后端数据源。 此功能有助于提升性能，并减少后端负载。 以前，甚至是切片器等简单视觉对象，也会启动后端源的查询。 有关详细信息，请参阅管理 Power BI Desktop 中的存储模式。

使用复合模型

通过复合模型，在使用 Power BI Desktop 或 Power BI 服务时可以连接到不同类型的数据源。 可以用两种方法实现实现这些数据连接：

• 将数据导入 Power BI，这是获取数据最常见的方式。
• 使用 DirectQuery 直接连接到其原始源存储库中的数据。 了解有关 DirectQuery 的详细信息，请参阅 Power BI 中的 DirectQuery。

使用 DirectQuery 时，可通过复合模型创建 Power BI 模型，例如单一 .pbix 的 Power BI Desktop 文件，Power BI Desktop 文件可执行下述任一操作或全部两项操作：

• 合并来自一个或多个 DirectQuery 源的数据。
• 合并来自 DirectQuery 源的数据和导入数据。

例如，通过使用复合模型，可以生成结合了以下类型的数据的模型：

• 来自企业数据仓库的销售数据。
• 来自部门 SQL Server 数据库的销售目标数据。
• 从电子表格导入的数据。

将来自多个 DirectQuery 源的数据合并，或将 DirectQuery 与导入的数据相结合的模型称为“复合模型”。

你可以像往常一样在表之间创建关系，即使这些表来自不同的源。 任何跨源的关系都是使用“多对多”基数创建的，而不考虑它们的实际基数。 你可将其更改为一对多、多对一或一对一。 如果设置了任何基数，则跨源关系具有不同的行为。 不能使用数据分析表达式 (DAX) 函数从 many 端检索 one 端的值。 在同一个源中，还可能看到性能影响与多对多关系的对比。

注意

在复合模型的上下文中，所有导入的表实际上都是一个单一源，与实际基础数据源无关。

复合模型示例

有关复合模型的示例，请考虑使用 DirectQuery 连接到 SQL Server 中的公司数据仓库的报表。 在该实例中，数据仓库包含按“Country”、“Quarter”和“Bike (Product)”分类的销售数据，如下图所示 ：

此时，可以使用来自此源的字段构建简单的视觉对象。 下图显示所选季度按“ProductName” 排列的销售总额。

但如果 Excel 电子表格中有关于分配给每个产品的产品经理的数据以及营销优先级，又该怎么操作呢？ 如果要按“Product Manager”查看“Sales Amount”，将此本地数据添加到公司数据仓库可能无法实现 。 也可能最少需要几个月的时间。

也许可以从数据仓库（而不是使用 DirectQuery）导入该销售数据。 然后，可以将销售数据与从电子表格中导入的数据相结合。 但是，这种方法需要首先使用 DirectQuery，因此不合理。 原因可能包括：

• 基础数据源中强制执行的安全规则的某种组合。
• 需要能够查看最新数据。
• 数据的规模庞大。

因此需要用到复合模型。 使用复合模型，可以通过 DirectQuery 连接到数据仓库，然后使用“获取数据”获取其他源。 在此示例中，我们首先建立 DirectQuery 与企业数据仓库的连接。 使用“获取数据” ，选择“Excel” ，然后导航到包含本地数据的电子表格。 最后，导入包含“Product Name”、分配的“Sales Manager”和“Priority”的电子表格 。

在“字段”列表中，可以看见两个表：来自 SQL Server 的原始“Bike”表，以及新的“ProductManagers”表 。 新表包含从 Excel 导入的数据。

同样，在 Power BI Desktop 中的“关系”视图中，现在可以看到另一个名为“ProductManagers”的表。

现在需要将这些表与模型中的其他表相关联。 与往常一样，我们在来自 SQL Server 的“Bike”表和导入的“ProductManagers”表之间创建关系 。 也就是“Bike[ProductName]”和“ProductManagers[ProductName]”之间的关系 。 如前所述，所有跨越源的关系都默认为具有“多对多”基数。

创建此关系后，关系会按照我们所期望的那样显示在 Power BI Desktop 的“关系”视图中 。

现在可以使用“字段”列表的任意字段来创建视觉对象 。 此方法无缝地混合来自多个源的数据。 例如，每个“Product Mnager”的总“SalesAmount”如下图所示 ：

以下示例显示了维度 表（例如“Product” 或“Customer” ）的一种常见用例，它通过从其他位置导入的一些额外数据进行扩展。 还有可能使表借助 DirectQuery 连接到各个源。 若要继续了解示例，假定每个“Country”和“Period”的“Sales Targets”都存储在一个单独的部门数据库中 。 可以像往常那样使用“获取数据” 连接到该数据，如下图所示：

类似于之前的操作，可以在模型中在新表和其他表之间创建关系。 然后，可以创建合并表数据的视觉对象。 让我们再次看看“关系”视图，我们已在其中建立了新关系 ：

下图基于新的数据和已创建的关系。 左下方的视觉对象显示总“Sales Amount”与“Target”的对比，差异计算显示差异 。 “Sales Amount”和“Target”数据来自两个不同的 SQL Server 数据库 。

设置存储模式

复合模型中的每个表都有一个存储模式，指示表是基于 DirectQuery 还是导入。 可以在“属性”窗格中查看和修改存储模式 。 要显示存储模式，请右键单击“字段”列表中的某个表，然后选择“属性” 。 下图显示“SalesTargets”表的存储模式 。

也可以在每个表的工具提示上查看存储模式。

对于包含一些来自 DirectQuery 的表和一些导入表的任何 Power BI Desktop 文件（.pbix 文件），状态栏显示一种称为“混合” 的存储模式。 可以在状态栏中选择该术语，并轻松将所有表切换为导入。

更多有关存储模式的详细信息，请参阅在 Power BI Desktop 中管理存储模式。

注意

可在 Power BI Desktop 和 Power BI 服务中使用“混合”存储模式 。

计算表

可以将计算表添加到使用 DirectQuery 的 Power BI Desktop 中的模型。 定义计算表的数据分析表达式 (DAX) 可以引用导入的表或 DirectQuery 表或两者的组合。

计算表始终是导入的，刷新表时，也会刷新表中的数据。 如果计算表引用 DirectQuery 表，则引用 DirectQuery 表的视觉对象始终显示基础数据源中的最新值。 或者，引用计算表的视觉对象显示上次刷新计算表时的值。

重要

除非满足特定要求，否则 Power BI 服务不支持计算表。 有关此内容的详细信息，请参阅本文中“使用基于语义模型或模型的复合模型”部分。

安全隐患

复合模型有一些安全隐患。 发送到一个数据源的查询可以包括已从另一个源检索的数据值。 在前面的示例中，按“产品经理” 显示“(销售额)” 的视觉对象向“Sales”关系数据库发送 SQL 查询。 SQL 查询可能包含“产品经理”的姓名及其关联的“产品”。

因此，存储在电子表格中的信息现包含在发送到关系数据库的查询中。 如果为机密信息，则应考虑安全隐患。 具体而言，请考虑以下几点：

• 即使对原始源中的数据没有权限，任何可以查看跟踪或审核日志的数据库管理员也都可以查看此信息。 在此示例中，管理员需要权限来查看 Excel 文件。

• 应考虑为每个源设置加密。 若希望避免通过加密连接从一个源检索信息，然后无意中将其包含在通过未加密连接发送到另一个源的查询中。

创建复合模型时，Power BI Desktop 会显示一条警告消息，以便确认已考虑任何安全隐患。

此外，如果作者将模型 A 中的 Table1 添加到复合模型中（我们将其称为模型 C 以作参考），那么查看基于模型 C 构建的报表的用户可以查询模型 A 中不受行级别安全性 RLS 保护的任何表。

出于类似原因，打开从不受信任的源发送的 Power BI Desktop 文件时必须小心谨慎。 如果该文件包含复合模型，某人使用打开文件的用户的凭据从一个源检索的信息会被作为查询的一部分发送到另一个数据源。 Power BI Desktop 文件的恶意作者就可以查看该信息。 初次打开包含多个源的 Power BI Desktop 文件时，Power BI Desktop 将显示警告。 此警告类似于打开包含本机 SQL 查询的文件时显示的警告。

性能影响

使用 DirectQuery 时应始终考虑性能，主要是为了确保后端源具有足够的资源来为用户提供良好体验。 良好的体验意味着视觉对象在五秒或更短的时间内刷新。 有关更多性能建议，请参阅 Power BI 中的 DirectQuery。

使用复合模型还有其他的性能注意事项。 只有一个视觉对象则可能导致向多个源发送查询，这通常会将来自一个查询的结果传递到第二个源。 这种情况可能会导致以下执行形式：

• 包含大量字面量值的源查询：例如，为一组选定的“Product Managers”请求总“Sales Amount”的视觉对象首先需要查找由这些产品经理管理的“Products”。 此序列必须在视觉对象发送包含 WHERE 子句中的所有产品 ID 的 SQL 查询之前发生。

• 在较低粒度级别进行查询、然后在本地聚合数据的源查询：随着满足“Product Manager”筛选条件的“Products”的数量增加，将所有产品包含在“WHERE”子句中可能会效率低下或不可行。 于是，有必要在“产品”的较低级别查询关系源，然后在本地聚合结果。 如果“Products”基数超过 100 万限制，则查询失败。

• 多个源查询，按值一个组一个：如果聚合使用 DistinctCount 并按来自另一个源的某个列分组，且外部源不支持有效传递定义分组的多个文本值，则需要按值每组发送一个 SQL 查询。

  请求按“产品经理”（从电子表格导入）排布的不同数量的 CustomerAccountNumber（来自 SQL Server 表）的视觉对象，需要在发送到 SQL Server 的查询中传递来自“产品经理”表的详细信息。 通过其他源（例如 Redshift），此操作不可行。 相反，会根据每个“销售经理”发送一个 SQL 查询，直到达到某个实际限制，此时查询就会失败。

每一种情况对性能都有其相应的影响，并且每个数据源的具体细节都有所不同。 虽然在连接两个源的关系中使用的列的基数仍然很低（几千），但性能不会受到影响。 随着此基数的增长，应更注重对其产生的性能的影响。

此外，使用“多对多”关系意味着必须将单独查询发送到每个总计或小计级别的基础源，而不是在本地聚合详细值。 一个带总计的简单表视觉对象将发送两个源查询，而不是一个。

源组

源组是来自 DirectQuery 源或数据模型中涉及的所有导入源的项（例如表和关系）的集合。 复合模型由一个或多个源组组成。 请开考虑以下示例：

• 一种复合模型，它连接到名为 Sales 的 Power BI 语义模型，并通过添加原始语义模型中未提供的 Sales YTD 度量来扩充语义模型。 此模型由一个源组组成。
• 一种复合模型，它通过从名为 Targets 的 Excel 工作表和名为 Regions 的 CSV 文件的表中导入数据，并与名为 Sales 的 Power BI 语义模型建立 DirectQuery 连接来组合数据。 在这种情况下，有两个源组，如下图所示：
  • 第一个源组包含 Excel 工作表“Targets”以及 CSV 文件“Regions”中的表。
  • 第二个源组包含 Power BI 语义模型 Sales 中的项。

如果将另一个 DirectQuery 连接添加到另一个源（例如与名为“Inventory”的 SQL Server 数据库的 DirectQuery 连接），来自该源的项将添加为另一个源组：

注意

从另一个源导入数据不会添加另一个源组，因为所有导入源中的所有项都在一个源组中。

源组和关系

复合模型中有两种类型的关系：

• 源组内关系。 这些关系将源组内的项关联在一起。 这些关系始终是常规关系，除非它们是多对多关系，在这种情况下它们会受限。
• 跨源组关系。 这些关系在一个源组中开始，在不同的源组中结束。 这些关系始终是有限关系。

详细了解常规关系和有限关系之间的区别及其影响。

例如，在下图中，添加了三个跨源组关系，将各个源组中的表关联在一起：

本地和远程

属于 DirectQuery 源组的源组中的任何项都被视为远程项，除非项在本地定义为 DirectQuery 源扩展或扩充的一部分且不属于远程源，例如度量或计算表。 计算表（基于 DirectQuery 源组中的表）属于“Import”源组并被视为本地项。 “Import”源组中的任何项都被视为本地项。 例如，如果在使用与 Inventory 源的 DirectQuery 连接的复合模型中定义以下度量，度量就会被视为本地度量：

[Average Inventory Count] = Average(Inventory[Inventory Count])

计算组、查询和度量评估

计算组提供了一种方法来减少冗余度量的数量，并将常用度量表达式组合在一起。 典型的用例是时间智能计算，你希望能从实际值切换到本月至今、本季度至今或本年度至今的计算。 使用复合模型时，请务必要了解计算组之间的交互以及度量是否仅引用来自单个远程源组的项。 如果度量仅引用来自单个远程源组的项，并且远程模型定义了影响度量的计算组，那么即使度量是在远程模型或本地模型中定义的，也将应用此计算组。 但是，如果度量没有专门引用单个远程源组中的项，而是引用应用了远程计算组的远程源组中的项，度量的结果可能仍会受到远程计算组的影响。 请考虑以下示例：

• Reseller Sales 是在远程模型中定义的度量。
• 远程模型包含更改了经销商销售结果的计算组
• Internet Sales 是在本地模型中定义的度量。
• Total Sales 是在本地模型中定义的度量，具有以下定义：

[Total Sales] = [Internet Sales] + [Reseller Sales]

在这种情况下，Internet Sales 度量不受远程模型中定义的计算组的影响，因为它们不属于同一模型。 但计算组可以更改 Reseller Sales 度量的结果，因为它们属于同一模型。 这意味着必须仔细评估 Total Sales 度量返回的结果。 假设我们使用远程模型中的计算组来返回本年度至今的结果。 Reseller Sales 返回的结果现在是本年度至今的值，而 Internet Sales 返回的结果仍然是实际值。 Total Sales 的结果现在可能出乎意料，因为它在本年度至今的结果中增加了一个实际值。

Power BI 语义模型和 Analysis Services 上的复合模型

将复合模型与 Power BI 语义模型和 Analysis Services 配合使用，可以使用 DirectQuery 连接来构建复合模型，以连接到 Power BI 语义模型、Azure Analysis Services (AAS) 和 SQL Server 2022 Analysis Services。 使用复合模型，可以将这些源中的数据与其他 DirectQuery 和导入的数据组合在一起。 如果报表作者想要将其企业语义模型中的数据与他们所拥有的其他数据（如 Excel 电子表格）组合在一起，或者要从其企业语义模型中个性化或丰富元数据，将会发现此功能特别有用。

管理 Power BI 语义模型上的复合模型

若要实现在 Power BI 语义模型上创建和使用复合模型，租户需要启用以下开关：

• 允许通过本地语义模型在 Excel 中使用 XMLA 终结点和分析。 如果禁用此开关，则 DirectQuery 无法连接到 Power BI 语义模型。
• 用户可以使用实时连接在 Excel 中处理 Power BI 语义模型。 如果禁用此开关，用户将无法实时连接到 Power BI 语义模型，因此无法使用“对此模型进行更改”按钮。
• 允许 DirectQuery 连接到 Power BI 语义模型。 有关此开关以及禁用它的效果的详细信息，请参阅以下段落。

此外，对于 Premium 容量和 Premium Per User，应启用“XMLA 终结点”设置并设置为“只读”或“读/写”。

租户管理员可以在管理门户中启用或禁用与 Power BI 语义模型的 DirectQuery 连接。 虽然默认情况下启用此功能，但禁用它将阻止用户将 Power BI 语义模型上的新复合模型发布到服务。

使用 Power BI 语义模型上的复合模型的现有报表将继续运行，并且用户仍可以使用 Desktop 创建复合模型，但无法发布到服务。 相反，通过选择“对此模型进行更改”创建到 Power BI 语义模型的 DirectQuery 连接时，你会看到以下警告消息：

这样，你仍然可以在本地 Power BI Desktop 环境中浏览语义模型并创建复合模型。 但是，你将无法将报表发布到服务。 发布报表和模型时，你将看到以下错误消息，并且发布会被阻止：

与 Power BI 语义模型的实时连接不受此开关的影响，与 Analysis Services 的实时连接或 DirectQuery 连接也不受影响。 无论此开关是否已关闭，这些连接都会继续运行。 此外，使用 Power BI 语义模型上的复合模型的任何已发布报表将继续运行，即使在发布这些报表后禁用了此开关。

在语义模型或模型上生成复合模型

在 Power BI 语义模型或 Analysis Services 模型上生成复合模型要求报表具有本地模型。 可以从实时连接开始，添加或升级到本地模型，或从 DirectQuery 连接或导入数据开始，这将自动在报表中创建本地模型。

若要查看模型中正在使用哪些连接，请查看 Power BI Desktop 右下角的状态栏。 如果你只连接到 Analysis Services 源，则会看到如下所示的消息：

如果连接到 Power BI 语义模型，则会看到一条消息，告诉你连接到哪些 Power BI 语义模型：

如果要自定义实时连接的语义模型中的字段元数据，请在状态栏中选择“对此模型进行更改”。 或者，也可以选择功能区中的“对此模型进行更改”按钮，如下图所示。 在“报表视图”中，“对此模型进行更改”按钮在“建模”选项卡中。在“模型视图”中，此按钮位于“主页”选项卡中。

选择该按钮会显示一个对话框，用于确认是否添加了本地模型。 选择“添加本地模型”，以便为 Power BI 语义模型或 Analysis Services 中的字段创建新列或修改元数据。 下图所示为显示的对话框。

当你实时连接到 Analysis Services 源时，没有本地模型。 若要将 DirectQuery 用于实时连接的源（如 Power BI 语义模型和 Analysis Services），则必须将本地模型添加到报表。 将具有本地模型的报表发布到 Power BI 服务时，还会发布该本地模型的语义模型。

链接

语义模型和它们所基于的语义模型形成链。 此过程称为“链接”，使你可以基于其他 Power BI 语义模型发布报表和语义模型（以前无法实现该功能）。

例如，假设你的同事发布了一个名为“销售和预算”的 Power BI 语义模型，该语义模型基于名为“销售”的 Analysis Services 模型，并将其与名为“预算”的 Excel 工作表结合起来。

在基于同事发布的“销售和预算”Power BI 语义模型发布名为“销售和预算(欧洲)”的新报表（和语义模型）时，在此过程中进行进一步的修改或扩展，可以将报表和语义模型有效地添加到长度为 3 的链，该链从“销售”Analysis Services 模型开始，并以“销售和预算(欧洲)”Power BI 语义模型结束。 下图显示了此链接过程。

上图中的链长度为 3，这是最大长度。 不支持超出 3 的链长度，这会导致错误。

权限和授权

使用复合模型访问报表的用户需要对所有语义模型和链中的模型具有适当的权限。

复合模型的所有者需要对用作源的语义模型具有生成权限，以便其他用户能够代表所有者访问这些模型。 因此，在 Power BI Desktop 中创建复合模型连接或在 Power BI 中创作报表需要对用作源的语义模型具有生成权限。

使用复合模型查看报表的用户通常需要对复合模型本身以及用作源的语义模型具有读取权限。 如果报表位于 Pro 工作区中，则可能需要具有生成权限。 应为用户启用这些租户开关。

可以使用以下示例演示所需的权限：

• 复合模型 A（由所有者 A 所有）

  • 数据源 A1：语义模型 B。
    所有者 A 必须对语义模型 B 具有生成权限，这样用户才能使用复合模型 A 查看报表。

• 复合模型 C（由所有者 C 所有）

  • 数据源 C1：语义模型 D
    所有者 C 必须对语义模型 D 具有生成权限，这样用户才能使用复合模型 C 查看报表。
  • 数据源 C2：复合模型 A
    所有者 C 必须对复合模型 A 具有生成权限，并且对语义模型 B 具有读取权限。

使用复合模型 A 查看报表的用户必须对复合模型 A 和语义模型 B 具有读取权限，而使用复合模型 C 查看报表的用户则必须对 复合模型 C、语义模型 D、复合模型 A 和语义模型 B 具有读取权限。

注意

请参阅此博客文章，了解 Power BI 语义模型和 Analysis Services 模型上复合模型所需的权限相关的重要信息。

如果链中的任何数据集都位于 Premium Per User 工作区中，则访问它的用户需要 Premium Per User 许可证。 如果链中的任何数据集都位于 Pro 工作区中，则访问它的用户需要 Pro 许可证。 如果链中的所有数据集都位于高级容量或 Fabric F64 或更高版本容量中，则用户可以使用免费许可证进行访问。

安全警告

使用“Power BI 语义模型和 Analysis Services 上的复合模型”功能将显示一个安全警告对话框，如下图所示。

数据可以从一个数据源推送到另一个数据源，这是在数据模型中组合 DirectQuery 和导入源的相同安全警告。 若要了解有关此行为的详细信息，请参阅使用 Power BI Desktop 中的复合模型。

支持的方案

可以使用 Power BI 语义模型或 Analysis Services 模型中的数据生成复合模型，以便为以下方案提供服务：

• 连接到不同源中的数据：导入（如文件）、Power BI 语义模型、Analysis Services 模型
• 创建不同数据源之间的关系
• 编写使用不同数据源中的字段的度量值
• 为 Analysis Services 模型的 Power BI 语义模型中的表创建新列
• 创建使用不同数据源中的列的视觉对象
• 可以使用字段列表从模型中删除表，使模型尽可能简洁（如果连接到透视图，则不能从模型中删除表）
• 可以指定要加载的表，而不必在只需要特定表子集时加载所有表。 请参阅本文档后面的“加载表子集”。
• 可以在模型中建立连接后指定是否添加随后添加到语义模型的任何表。

使用基于语义模型或模型的复合模型

使用适用于 Power BI 语义模型和 Analysis Services 的 DirectQuery 时，请考虑以下信息：

• 如果在刷新数据源时出现字段或表名冲突的错误，Power BI 将为你解决这些错误。

• 不能在同一 Power BI 语义模型或 Analysis Services 源中编辑、删除或创建新关系。 如果你对这些源具有编辑访问权限，可以直接在数据源中进行更改。

• 无法更改从 Power BI 语义模型或 Analysis Services 源加载的列的数据类型。 如果需要更改数据类型，请在源中进行更改或使用计算列。

• 若要在 Power BI 服务中基于另一个语义模型的复合模型上生成报表，必须设置所有凭据。

• 连接到本地 SQL Server 2022 和更高版本的 Analysis Services 服务器或 IAAS 需要本地数据网关（标准模式）。

• 与远程 Power BI 语义模型模型的所有连接均使用单一登录进行。 目前不支持使用服务主体进行身份验证。

• RLS 规则将应用于定义它们的源，但不会应用于模型中的任何其他语义模型。 报表中定义的 RLS 不会应用于远程源，远程源上设置的 RLS 不会应用于其他数据源。 此外，不能在从远程源加载的表上定义 RLS，并且在本地表上定义的 RLS 不会筛选从远程源加载的任何表。

• 不会从源导入 KPI、行级别安全性和翻译。

• 使用日期层次结构时，可能会出现一些意外行为。 若要解决此问题，请改用日期列。 将日期层次结构添加到视觉对象后，可以通过单击字段名称中的向下箭头，然后单击该字段的名称来切换到日期列，而不是使用日期层次结构：

  

  有关使用日期列与日期层次结构的详细信息，请参阅在 Power BI Desktop 中应用自动日期或时间。

• 模型链的最大长度为 3。 不支持超出 3 的链长度，这会导致错误。

• 可以在模型上设置“阻止链接”标志，以防止创建或扩展链。 有关详细信息，请参阅管理与已发布语义模型的 DirectQuery 连接。

• 与 Power BI 语义模型或 Analysis Services 模型的连接不会在 Power Query 中显示。

使用适用于 Power BI 语义模型和 Analysis Services 的 DirectQuery 时，以下限制适用：

• 当前禁用了数据库和服务器名称的参数。
• 不支持从远程源定义表中的 RLS。
• 不支持使用以下任何源作为 DirectQuery 的源：
  • 版本 2022 之前的 SQL Server Analysis Services (SSAS) 表格模型
  • SSAS 多维模型
  • SAP HANA
  • SAP Business Warehouse
  • 实时语义模型
  • 示例语义模型
  • Excel 联机刷新
  • 从服务上的 Excel 或 CSV 文件导入的数据
  • 使用情况指标
  • 存储在“我的工作区”中的语义模型
• 当前不支持将 Power BI Embedded 和包含与 Analysis Services 模型的 DirectQuery 连接的语义模型配合使用。
• 不支持使用发布到 Web 功能将报表发布到 Web。
• 不支持远程源上的计算组，其中包含未定义的查询结果。

• 当分配了可共享的云连接和/或细粒度访问控制时，Power BI Service 支持使用单一登录 (SSO) 身份验证从数据源引用 DirectQuery 表的计算表和计算列。

• 如果在设置 DirectQuery 连接后重命名工作区，则需要更新 Power BI Desktop 中的数据源，使报表继续工作。
• 只有某些情况下才支持自动页面刷新 (APR)，具体取决于数据源类型。 有关详细信息，请参阅 Power BI 中的自动页面刷新。
• 目前不支持接管会使用“到其他语义模型的 DirectQuery”功能的语义模型。
• 与任何 DirectQuery 数据源一样，在 DirectQuery 模式下使用 Excel 连接到模型或语义模型时，在 Analysis Services 模型或 Power BI 语义模型中定义层次结构不会显示。

使用适用于 Power BI 语义模型和 Analysis Services 的 DirectQuery 时，还需要考虑一些其他事项：

• 在跨源组关系中使用低基数列：在两个不同的源组之间创建关系时，参与关系的列（也称为联接列）应具有低基数，理想情况下不超过 50,000。 此注意事项适用于非字符串键列；对于字符串键列，请参阅以下注意事项。
• 避免在跨源组关系中使用大型字符串键列：创建跨源组关系时，请避免使用大型字符串列作为关系列，尤其是对于较大基数的列。 当必须使用字符串列作为关系列时，通过将基数 (C) 乘以字符串列 (A) 的平均长度来计算筛选器的预期字符串长度。 确保预期的字符串长度低于 250,000，使 A ∗ C < 250,000。

有关更多注意事项和指导，请参阅复合模型指导。

租户注意事项

与 Power BI 语义模型或 Analysis Services 建立 DirectQuery 连接的任何模型都必须在同一租户中发布，这在使用 B2B 来宾标识访问 Power BI 语义模型或 Analysis Services 模型时尤其重要，如下图所示。 请参阅可以编辑和管理内容的来宾用户，查找用于发布的租户 URL。

考虑下图。 图中带编号的步骤将在下面的段落中介绍。

在此图中，Ash 与 Contoso 合作，正在访问 Fabrikam 提供的数据。 Ash 使用 Power BI Desktop 创建与 Analysis Services 模型的 DirectQuery 连接，该模型托管在 Fabrikam 的租户中。

为了进行身份验证，Ash 使用 B2B 来宾用户标识（图中的步骤 1）。

如果将报表发布到 Contoso 的 Power BI 服务（步骤 2），则在 Contoso 租户中发布的语义模型将不能成功地对 Fabrikam 的 Analysis Services 模型进行身份验证（步骤 3）。 因此，报表将无法工作。

在此方案中，由于使用的 Analysis Services 模型是在 Fabrikam 的租户中托管的，因此还必须在 Fabrikam 的租户中发布该报表。 在 Fabrikam 的租户中成功发布后（步骤 4），语义模型可以成功访问 Analysis Services 模型（步骤 5），报表将正常工作。

使用对象级安全性

当复合模型通过 DirectQuery 从 Power BI 语义模型或 Analysis Services 获取数据，并且源模型受对象级安全性保护时，复合模型的使用者可能会注意到意外的结果。 以下部分说明了这些结果是如何产生的。

对象级安全性 (OLS) 使模型作者可以对模型使用者（例如，报表创建者或复合模型作者）隐藏构成模型架构的对象（即，表、列、元数据等）。 在为某个对象配置 OLS 时，模型作者会创建一个角色，然后为分配给该角色的用户删除对该对象的访问权限。 从这些用户的角度来看，隐藏的对象并不存在。

OLS 是为源模型定义的，并且应用在源模型上。 不能为构建在源模型上的复合模型定义它。

当复合模型通过 DirectQuery 连接构建在受 OLS 保护的 Power BI 语义模型或 Analysis Services 模型之上时，源模型中的模型架构会复制到复合模型中。 复制的内容取决于复合模型作者根据此处应用的 OLS 规则允许在源模型中看到的内容。 数据不会复制到复合模型中，而是在需要时，始终通过 DirectQuery 从源模型中检索数据本身。 换句话说，数据检索始终返回到应用了 OLS 规则的源模型。

由于复合模型不受 OLS 规则保护，因此复合模型使用者看到的对象是指复合模型作者可以在源模型中看到的对象，而不是其本身可能有权访问的对象。 这可能会导致以下情况：

• 查看复合模型的用户可能会在受 OLS 保护的源模型中看到对他们隐藏的对象。
• 相反，他们可能在复合模型中看不到可以在源模型中看到的对象，因为该对象对因 OLS 规则控制对源模型的访问的复合模型作者隐藏。

很重要的一点是，尽管存在第一项中所述的情况，但复合模型使用者将永远不会看到他们不应看到的实际数据，因为这些数据不在复合模型中。 相反，由于 DirectQuery，会根据需要从源语义模型中检索数据，其中 OLS 会阻止未经授权的访问。

考虑到此背景，请考虑以下情况：

1. Admin_user 已使用 Power BI 语义模型或具有“客户”表和“区域”表的 Analysis Services 模型发布了企业语义模型。 Admin_user 将语义模型发布到 Power BI 服务，并设置具有以下效果的 OLS 规则：

   • 财务用户看不到“客户”表
   • 市场营销用户看不到“区域”表

2. Finance_user 发布一个名为“财务语义模型”的语义模型和一个名为“财务报表”的报表，该报表通过 DirectQuery 连接到步骤 1 中发布的企业语义模型。 “财务”报表包含使用“区域”表中的列的视觉对象。

3. Marketing_user 打开“财务”报表。 将显示使用“区域”表的视觉对象，但会返回错误，因为在打开该报表时，DirectQuery 会尝试使用 Marketing_user 的凭据从源模型中检索数据，该用户根据企业语义模型上设置的 OLS 规则看不到“区域”表。

4. Marketing_user 创建一个名为“市场营销报表”的新报表，该报表使用财务语义模型作为其源。 字段列表显示 Finance_user 有权访问的表和列。 因此，“区域”表显示在字段列表中，但“客户”表并非如此。 但是，当 Marketing_user 尝试创建利用“区域”表中的列的视觉对象时，将返回错误，因为此时，DirectQuery 会尝试使用 Marketing_user 的凭据从源模型中检索数据，OLS 规则再次发挥作用来阻止访问。 当 Marketing_user 创建连接到具有 DirectQuery 连接的财务语义模型的新语义模型和报表时，就会发生这种情况，他们会在字段列表中看到“区域”表，因为这是 Finance_user 可以看到的内容，但当他们尝试创建利用该表的视觉对象时，他们将被企业语义模型上的 OLS 规则阻止。

5. 现在，假设 Admin_user 更新企业语义模型上的 OLS 规则，以使财务不会看到“区域”表。

6. 只有在 Finance 语义模型刷新后，更新的 OLS 规则才会在其中体现。 因此，当 Finance_user 刷新财务语义模型时，“区域”表将不再显示在字段列表中，“财务”报表中使用“区域”表中列的视觉对象将为 Finance_user 返回错误，因为现在不允许他们访问“区域”表。

总结：

• 复合模型使用者在创建模型时可以看到适用于复合模型作者的 OLS 规则的结果。 因此，当基于复合模型创建新报表时，字段列表将显示复合模型作者在创建该模型时有权访问的表，而不考虑当前用户在源模型中有权访问的内容。
• 不能在复合模型本身上定义 OLS 规则。
• 复合模型使用者将永远不会看到他们不应看到的实际数据，因为当 DIrectQuery 尝试使用其凭据检索数据时，源模型上的相关 OLS 规则将会阻止他们。
• 如果源模型更新了其 OLS 规则，则这些更改只会在刷新复合模型时对其产生影响。

从 Power BI 语义模型或 Analysis Services 模型加载表的子集

使用 DirectQuery 连接来连接到 Power BI 语义模型或 Analysis Services 模型时，可决定要连接到哪些表。 你也可选择在与模型建立连接后，自动添加任何可能添加到语义模型或模型中的表。 在连接到一个透视时，模型将包含语义模型或模型内的所有表，并且透视中不包含的任何表都将隐藏。 此外，任何可能会添加到透视的表都将被自动添加。 在“设置”菜单中，可以决定在首次设置连接后自动连接添加到语义模型或模型中的表。

对于实时连接，不会显示此对话框。

注意

只有在你将与 Power BI 语义模型或 Analysis Services 模型的 DirectQuery 连接添加到现有模型时，此对话框才会显示。 你也可在创建数据源后，通过在数据源设置中更改与 Power BI 语义模型或 Analysis Services 模型的 DirectQuery 连接来打开此对话框。

设置消除重复规则

可以使用前面所示对话框中的“设置”选项来指定消除重复规则，以保持复合模型中的度量和表名称唯一：

在前面的示例中，我们已将“(marketing)”作为后缀添加到与复合模型中的其他源冲突的表或度量名称。 可以：

• 输入要添加到冲突表或度量名称的文本
• 指定要将文本作为前缀还是后缀添加到表或度量名称中
• 将消除重复规则应用于表、度量或两者
• 选择仅在发生名称冲突时应用消除重复规则还是始终应用。 默认选择是仅在发生重复时应用规则。 在我们的示例中，营销源中没有重复项的任何表或度量都不会更改名称。

建立连接并设置消除重复规则后，字段列表将根据示例中设置的消除重复规则显示“Customer”和“Customer (marketing)”：

如果未指定消除重复规则或指定的消除重复规则未解决名称冲突，则将应用标准消除重复规则。 标准消除重复规则会向冲突项的名称添加一个数字。 如果“Customer”表的名称冲突，其中一个“Customer”表将被重命名为“Customer 2”。

XMLA 修改和复合模型

使用 XMLA 更改语义模型时，必须更新 ChangedProperties 和 PBI_RemovedChildren 集合，以便更改的对象包含任何已修改或删除的属性。 如果不执行该更新，Power BI 建模工具可能会在下次架构与其关联的 Lakehouse 同步时覆盖任何更改。

使用 XMLA 更改语义模型支持的模型如下：

• 表/列重命名 （ChangeProperty = name）
• 删除表（将表添加到 查询表达式中的PBI_RemovedChildren 批注）

注意事项和限制

复合模型存在一些注意事项和限制：

混合模式连接 - 当使用包含联机数据（例如 Power BI 语义模型）和本地语义模型（例如 Excel 工作簿）的混合模式连接时，必须建立网关映射才能让视觉对象正确显示。

当前，只有连接到 SQL、Oracle 和 Teradata 数据源的复合模型支持增量刷新。

以下 Live Connect 表格源不能用于复合模型：

• SAP HANA
• SAP Business Warehouse
• 2022 版本之前的 SQL Server Analysis Services
• 使用指标（我的工作区）

不支持在复合模型中使用流式处理语义模型。

在使用复合模型时，使用 DirectQuery 的现有限制仍然适用。 现在每个表都要遵循其中许多限制，具体视表的存储模式而定。 例如，导入表上的计算列可以引用其他不在 DirectQuery 中的表，但是 DirectQuery 表上的计算列仍只能引用同一表上的列。 如果模型中的任何一个表都是 DirectQuery，则其他限制适用于整个模型。 例如，如果模型中有任何表的存储模式为 DirectQuery，则 QuickInsights 功能在该模型上不可用。

如果在某些表处于 DirectQuery 模式的复合模型中使用行级安全性，则必须刷新模型才能应用 DirectQuery 表中的新更新。 例如，如果 DirectQuery 模式下的“用户”表在源中具有新的用户记录，则只有在下一次模型刷新后才会包含新记录。 Power BI 服务缓存“用户”查询以提高性能，并且在下一次手动或计划刷新之前不会从源重新加载数据。

相关内容

若要详细了解复合模型和 DirectQuery，请参阅以下文章：

• 在 Power BI Desktop 中应用多对多关系
• 在 Power BI Desktop 中管理存储模式
• Power BI 中的 DirectQuery
• Power BI 数据源
• Power BI Desktop 中的模型关系