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

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

本地和远程

属于 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 会阻止未经授权的访问。
考虑到此背景，请考虑以下情况：
Admin_user 已使用 Power BI 语义模型或具有“客户”表和“区域”表的 Analysis Services 模型发布了企业语义模型。 Admin_user 将语义模型发布到 Power BI 服务，并设置具有以下效果的 OLS 规则：
财务用户看不到“客户”表
市场营销用户看不到“区域”表
Finance_user 发布一个名为“财务语义模型”的语义模型和一个名为“财务报表”的报表，该报表通过 DirectQuery 连接到步骤 1 中发布的企业语义模型。 “财务”报表包含使用“区域”表中的列的视觉对象。
Marketing_user 打开“财务”报表。 将显示使用“区域”表的视觉对象，但会返回错误，因为在打开该报表时，DirectQuery 会尝试使用 Marketing_user 的凭据从源模型中检索数据，该用户根据企业语义模型上设置的 OLS 规则看不到“区域”表。
Marketing_user 创建一个名为“市场营销报表”的新报表，该报表使用财务语义模型作为其源。 字段列表显示 Finance_user 有权访问的表和列。 因此，“区域”表显示在字段列表中，但“客户”表并非如此。 但是，当 Marketing_user 尝试创建利用“区域”表中的列的视觉对象时，将返回错误，因为此时，DirectQuery 会尝试使用 Marketing_user 的凭据从源模型中检索数据，OLS 规则再次发挥作用来阻止访问。 当 Marketing_user 创建连接到具有 DirectQuery 连接的财务语义模型的新语义模型和报表时，就会发生这种情况，他们会在字段列表中看到“区域”表，因为这是 Finance_user 可以看到的内容，但当他们尝试创建利用该表的视觉对象时，他们将被企业语义模型上的 OLS 规则阻止。
现在，假设 Admin_user 更新企业语义模型上的 OLS 规则，以使财务不会看到“区域”表。
只有在 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 中的模型关系