Power Platform 的 Power BI 建模指南

Microsoft Dataverse 是 Dynamics 365 Customer Engagement 和 Power Apps 画布应用等许多 Microsoft 商业应用程序产品，以及 Dynamics 365 Customer Voice（以前称为 Microsoft Forms Pro）、Power Automate 审批、Power Apps 门户等的标准数据平台。

本文提供有关如何创建连接到 Dataverse 的 Power BI 数据模型的指南。 其中介绍了 Dataverse 架构和优化的 Power BI 架构之间的差别，并提供了有关扩展 Power BI 中的商业应用程序数据可见性的指导。

由于易于设置、可快速部署且已得到广泛采用，Dataverse 在跨组织的环境中存储和管理越来越多的数据。 这意味着将分析与这些流程集成的需求和机会比以往更大。 机会包括：

• 报告超出内置图表约束的所有 Dataverse 数据。
• 提供对特定记录中相关的、按上下文筛选的报表的轻松访问。
• 通过将 Dataverse 数据与外部数据集成来提高数据的价值。
• 无需编写复杂代码即可利用 Power BI 的内置人工智能 (AI)。
• 通过提高 Power Platform 解决方案的实用性和价值来提高其采用率。
• 将应用中数据的价值传递给业务决策者。

将 Power BI 连接到 Dataverse

将 Power BI 连接到 Dataverse 涉及创建 Power BI 数据模型。 可使用三种方法创建 Power BI 模型。

• 使用 Dataverse 连接器导入 Dataverse 数据：此方法在 Power BI 模型中缓存（存储）Dataverse 数据。 得益于内存中查询，此方法提供快速性能。 它还为建模者提供设计灵活性，使他们能够集成其他源的数据。 由于这些优势，导入数据是在 Power BI Desktop 中创建模型时的默认模式。
• 使用 Azure Synapse Link 导入 Dataverse 数据：此方法是导入方法的一种变体，因为它也在 Power BI 模型中缓存数据，不过会通过连接到 Azure Synapse Analytics 来实现此目的。 使用适用于 Dataverse 的 Azure Synapse Link 将 Dataverse 表持续复制到 Azure Synapse 或 Azure Data Lake Storage (ADLS) Gen2。 此方法用于报告 Dataverse 环境中的数十万甚至数百万条记录。
• 使用 Dataverse 连接器创建 DirectQuery 连接：此方法是导入数据的替代方法。 DirectQuery 模型仅包含定义模型结构的元数据。 当用户打开报表时，Power BI 会将本机查询发送到 Dataverse 以检索数据。 当报表必须显示准实时的 Dataverse 数据时，或者当 Dataverse 必须强制实施基于角色的安全性以便用户只能查看他们有权访问的数据时，请考虑创建 DirectQuery 模型。

重要

虽然当你需要准实时的报告或在报表中强制实施 Dataverse 安全性时，DirectQuery 模型可能是不错的选择，但它可能会导致该报表的性能变慢。

可以在本文稍后了解 DirectQuery 注意事项。

若要确定适合你的 Power BI 模型的方法，应考虑：

• 查询性能
• 数据量
• 数据延迟
• 基于角色的安全性
• 设置复杂性

提示

有关模型框架（导入、DirectQuery 或复合模型）、其优点和限制以及有助于优化 Power BI 数据模型的功能的详细介绍，请参阅选择 Power BI 模型框架。

查询性能

发送到导入模型的查询比发送到 DirectQuery 数据源的本机查询速度更快。 这是因为导入的数据缓存在内存中，并且针对分析查询（筛选、分组和汇总操作）进行了优化。

相比之下，DirectQuery 模型仅在用户打开报表后才从源中检索数据，从而导致呈现报表之前会延迟数秒。 此外，报表的用户交互需要 Power BI 重新查询源，从而进一步降低了响应能力。

数据量

在开发导入模型时，应尽量减少加载到模型中的数据。 对于大型模型（或预计会随时间而变大的模型）尤其如此。 有关详细信息，请参阅用于导入建模的数据缩减技术。

当报表的查询结果不大时，与 Dataverse 的 DirectQuery 连接是不错的选择。 大型查询结果在报表的源表中包含超过 20,000 行，或者应用筛选器后返回到报表的结果超过 20,000 行。 在这种情况下，可以使用 Dataverse 连接器创建 Power BI 报表。

注意

20,000 行大小不是硬限制。 但是，每个数据源查询必须在 10 分钟内返回结果。 本文稍后将介绍如何在这些限制范围内操作，以及其他 Dataverse DirectQuery 设计注意事项。

可以使用 Dataverse 连接器将数据导入数据模型，以提高较大语义模型（以前称为数据集）的性能。

包含数十万甚至数百万行的更大语义模型也可以受益于适用于 Dataverse 的 Azure Synapse Link。 此方法会建立一个持续托管管道，用于将 Dataverse 数据作为 CSV 或 Parquet 文件复制到 ADLS Gen2。 然后，Power BI 可以查询 Azure Synapse 无服务器 SQL 池以加载导入模型。

数据延迟

当 Dataverse 数据快速变化并且报表用户需要查看最新数据时，DirectQuery 模型可以提供准实时的查询结果。

提示

可以创建使用自动页面刷新来显示实时更新的 Power BI 报表，但前提是该报表连接到 DirectQuery 模型。

导入数据模型必须完成数据刷新才能报告最近的数据更改。 请记住，每日计划的数据刷新操作次数有限制。 在共享容量中，每日最多可以计划 8 次刷新。 在高级容量或 Microsoft Fabric 容量中，每天最多可以计划 48 次刷新，这可以实现 15 分钟一次的刷新频率。

重要

有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意，Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。

有关详细信息，请参阅 Power BI Premium 许可即将进行的重要更新和 Power BI Premium 常见问题解答。

还可以考虑使用增量刷新来实现更快的刷新和准实时性能（仅适用于高级或 Fabric）。

基于角色的安全性

需要强制实施基于角色的安全性时，它会直接影响 Power BI 模型框架的选择。

Dataverse 可以强制实施复杂的基于角色的安全性，以控制特定用户对特定记录的访问。 例如，可以只允许销售人员查看其销售商机，而销售经理可以查看所有销售人员的所有销售商机。 可以根据组织的需求定制复杂程度。

基于 Dataverse 的 DirectQuery 模型可以使用报表用户的安全上下文进行连接。 这样，报表用户只能看到他们有权访问的数据。 此方法可以简化报表设计，并提供可接受的性能。

为了提高性能，可以创建一个连接到 Dataverse 的导入模型。 在这种情况下，可根据需要将行级安全性 (RLS) 添加到模型中。

注意

将某些 Dataverse 基于角色的安全性复制为 Power BI RLS 可能具有挑战性，尤其是当 Dataverse 强制实施复杂权限时。 此外，它可能需要通过持续管理来使 Power BI 权限与 Dataverse 权限保持同步。

有关 Power BI RLS 的详细信息，请参阅 Power BI Desktop 中的行级安全性 (RLS) 指南。

设置复杂性

在 Power BI 中可以直接使用 Dataverse 连接器（无论是用于导入模型还是 DirectQuery 模型），不需要任何特殊软件或提升的 Dataverse 权限。 这对于刚成立的组织或部门而言是一大优势。

Azure Synapse Link 选项要求对 Dataverse 拥有系统管理员访问权限，并要求拥有某些 Azure 权限。 这些 Azure 权限是设置存储帐户和 Synapse 工作区所必需的。

建议的做法

本部分介绍在创建连接到 Dataverse 的 Power BI 模型时应考虑的设计模式（和反模式）。 其中只有少数模式是 Dataverse 独有的，但它们往往是 Dataverse 制作者在生成 Power BI 报表时面临的常见挑战。

专注于特定用例

与其试图解决所有问题，不如专注于特定的用例。

此建议可能是最常见且最容易避免的、最具挑战性的反模式。 试图生成单个模型来满足所有自助报告需求是很有难度的。 实际上，生成成功的模型是为了回答有关一组中心事实而不是单个核心主题的问题。 虽然这种做法最初似乎会限制模型，但它实际上是在赋予能力，因为你可以调整和优化模型以回答该主题中的问题。

为帮助确保清晰了解模型的用途，请向自己提出以下问题。

• 此模型将支持哪些主题领域？
• 谁是报表的受众？
• 报表试图回答什么问题？
• 最小可行的语义模型是什么？

不要仅仅因为报表用户存在跨多个主题领域的，并希望通过单个报表解决的问题，就将多个主题领域组合到一个模型中。 通过将该报表拆分为多个报表并让每个报表侧重于不同的主题（或事实表），可以生成更高效、可缩放且可管理的模型。

设计星型架构

熟悉 Dataverse 架构的 Dataverse 开发人员和管理员往往会在 Power BI 中重现相同的架构。 此方法是一种反模式，它可能是最难克服的，因为它只是觉得保持一致性是正确的。

作为一种关系模型，Dataverse 非常适合其用途。 但是，它并非旨在用作针对分析报表进行优化的分析模型。 用于对分析数据建模的最主流模式是星型架构设计。 星型架构是由关系数据仓库广泛采用的成熟建模方法 。 它要求建模者将其模型表分类为“维度”或“事实” 。 可以使用维度表列和汇总事实表列来筛选或分组报表。

有关详细信息，请参阅了解星型架构和 Power BI 的重要性。

优化 Power Query 查询

为了提高效率，Power Query 糅合引擎会尽可能实现查询折叠。 实现折叠的查询将查询处理委托给源系统。

源系统（在本例中为 Dataverse）只需向 Power BI 提供筛选或汇总的结果。 折叠的查询通常比不折叠的查询要快得多且更有效。

有关如何实现查询折叠的详细信息，请参阅 Power Query 查询折叠。

备注

优化 Power Query 是一个宽泛的主题。 若要更好地了解在 Power BI Desktop 中创作和刷新模型时 Power Query 的运行状况，请参阅查询诊断。

最小化查询列数

默认情况下，当你使用 Power Query 加载 Dataverse 表时，它会检索所有行和所有列。 例如，当你查询某个系统用户表时，它可能包含 1,000 多个列。 元数据中的列包括与其他实体的关系，以及对选项标签的查找，因此列的总数随着 Dataverse 表的复杂性而增长。

尝试从所有列中检索数据是一种反模式。 这往往会导致数据刷新操作时间延长，当返回数据所需的时间超过 10 分钟时，会导致查询失败。

我们建议只检索报表所需的列。 在报表开发完成后重新评估和重构查询通常是一个好主意，这样可以识别和删除未使用的列。 有关详细信息，请参阅导入建模的数据缩减技术（删除不必要的列）。

此外，请确保提前引入 Power Query“删除列”步骤，以便折叠回源。 这样，Power Query 就可以避免仅提取源数据，然后又将其丢弃（在非折叠步骤中）这种不必要的工作。

当表包含许多列时，使用 Power Query 交互式查询生成器可能不切实际。 在这种情况下，可以先创建一个空白查询。 然后，可以使用高级编辑器粘贴一个用于创建起点的极简查询。

考虑以下查询，它仅从 account 表的两列中检索数据。

let
    Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false]),
    dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
    #"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name"})
in
    #"Removed Other Columns"

编写本机查询

需要满足特定的转换要求时，可以使用以 Dataverse SQL（Transact-SQL 的一个子集）编写的本机查询来实现更好的性能。 可以编写本机查询来实现以下目的：

• 减少行数（使用 WHERE 子句）。
• 聚合数据（使用 GROUP BY 和 HAVING 子句）。
• 以特定方式联接表（使用 JOIN 或 APPLY 语法）。
• 使用支持的 SQL 函数。

有关详细信息，请参阅：

• 使用 SQL 查询数据
• Dataverse SQL 与 Transact-SQL 的差别

使用 EnableFolding 选项执行本机查询

Power Query 使用 Value.NativeQuery 函数执行本机查询。

使用此函数时，必须添加 EnableFolding=true 选项来确保将查询折叠回 Dataverse 服务。 除非添加此选项，否则本机查询不会折叠。 启用此选项可以显著提高性能 – 在某些情况下，速度最大可以提高 97%。

考虑以下查询，它使用本机查询在 account 表中定位所选的列。 由于设置了 EnableFolding=true 选项，本机查询将会折叠。

let
    Source = CommonDataService.Database("demo.crm.dynamics.com"),
    dbo_account = Value.NativeQuery(
        Source,
        "SELECT A.accountid, A.name FROM account A"
        ,null
        ,[EnableFolding=true]
    )
in
     dbo_account

检索大量数据中的一部分数据时，预期可以实现最大的性能改进。

提示

性能改进还取决于 Power BI 如何查询源数据库。 例如，使用 COUNTDISTINCT DAX 函数的度量在使用或不使用折叠提示的情况下几乎没有任何差别。 将度量公式重写为使用 SUMX DAX 函数后，折叠的查询比没有提示的同一查询的速度可以提高 97%。

有关详细信息，请参阅 Value.NativeQuery。 （EnableFolding 选项未记录，因为它仅特定于某些数据源。）

使评估阶段加速

如果使用 Dataverse 连接器（以前称为 Common Data Service），可以添加 CreateNavigationProperties=false 选项来加速数据导入的评估阶段。

数据导入的评估阶段迭代其源的元数据以确定所有可能的表关系。 该元数据可能很广泛，尤其是对于 Dataverse。 将此选项添加到查询可让 Power Query 知道你不打算使用这些关系。 该选项允许 Power BI Desktop 跳过该刷新阶段并继续检索数据。

备注

当查询依赖于任何扩展的关系列时，请不要使用此选项。

考虑一个从 account 表中检索数据的示例。 该表包含与区域相关的三个列：territory、territoryid 和 territoryname。

如果设置 CreateNavigationProperties=false 选项，则 territoryid 和 territoryidname 列将会保留，但关系列 territory（它显示“值”链接）将被排除。 请务必知道，Power Query 关系列与模型关系是不同的概念，后者在模型表之间传播筛选器。

考虑以下查询，它使用 CreateNavigationProperties=false 选项（在“源”步骤中）来加速数据导入的评估阶段。

let
    Source = CommonDataService.Database("demo.crm.dynamics.com"
        ,[CreateNavigationProperties=false]),
    dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
    #"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name", "address1_stateorprovince", "address1_country", "industrycodename", "territoryidname"}),
    #"Renamed Columns" = Table.RenameColumns(#"Removed Other Columns", {{"name", "Account Name"}, {"address1_country", "Country"}, {"address1_stateorprovince", "State or Province"}, {"territoryidname", "Territory"}, {"industrycodename", "Industry"}})
in
    #"Renamed Columns"

使用此选项时，如果 Dataverse 表与其他表存在许多关系，则性能可能会显著改进。 例如，由于 SystemUser 表与数据库中的所有其他表存在关系，因此设置 CreateNavigationProperties=false 选项可以提高此表的刷新性能。

备注

此选项可以提高导入表或双存储模式表的数据刷新性能，包括应用 Power Query 编辑器窗口更改的过程。 它不能提高 DirectQuery 存储模式表的交互式交叉筛选性能。

解决空白选项标签

如果你发现 Power BI 中的 Dataverse 选项标签为空白，原因可能是标签尚未发布到表格数据流 (TDS) 终结点。

在这种情况下，请打开 Dataverse Maker 门户，导航到“解决方案”区域，然后选择“发布所有自定义项”。 发布过程将使用最新元数据更新 TDS 终结点，使选项标签可用于 Power BI。

使用 Azure Synapse Link 的较大语义模型

Dataverse 能够将表同步到 Azure Data Lake Storage (ADLS)，然后通过 Azure Synapse 工作区连接到该数据。 你可以轻松设置 Azure Synapse Link 以将 Dataverse 数据填充到 Azure Synapse 中，并使数据团队能够发现更深入的见解。

使用 Azure Synapse Link 可将数据和元数据从 Dataverse 连续复制到数据湖中。 它还为 Power BI 查询提供了一个内置的无服务器 SQL 池作为便捷数据源。

此方法的优势非常明显。 通过各种高级服务，客户可以针对 Dataverse 数据运行分析、商业智能和机器学习工作负载。 高级服务包括 Apache Spark、Power BI、Azure 数据工厂、Azure Databricks 和 Azure 机器学习。

创建适用于 Dataverse 的 Azure Synapse Link

若要创建适用于 Dataverse 的 Azure Synapse Link，需要满足以下先决条件。

• 对 Dataverse 环境的系统管理员访问权限。
• 对于 Azure Data Lake Storage：
  • 必须有一个可与 ADLS Gen2 配合使用的存储帐户。
  • 必须对存储帐户拥有“存储 Blob 数据所有者”和“存储 Blob 数据参与者”访问权限。 有关详细信息，请参阅基于角色的访问控制 (Azure RBAC)。
  • 存储帐户必须启用分层命名空间。
  • 建议存储帐户使用读取访问异地冗余存储 (RA-GRS)。
• 对于 Synapse 工作区：
  • 必须有权访问 Synapse 工作区并拥有“Synapse 管理员”访问权限。 有关详细信息，请参阅内置 Synapse RBAC 角色和范围。
  • 工作区必须与 ADLS Gen2 存储帐户位于同一区域。

设置涉及登录到 Power Apps 并将 Dataverse 连接到 Azure Synapse 工作区。 使用类似于向导的体验，可以通过选择存储帐户和要导出的表来创建新链接。 然后，Azure Synapse Link 将数据复制到 ADLS Gen2 存储，并在内置的 Azure Synapse 无服务器 SQL 池中自动创建视图。 然后，你可以连接到这些视图以创建 Power BI 模型。

提示

有关创建、管理和监视 Azure Synapse Link 的完整文档，请参阅使用 Azure Synapse 工作区创建适用于 Dataverse 的 Azure Synapse Link。

创建第二个无服务器 SQL 数据库

可以创建第二个无服务器 SQL 数据库并使用它来添加自定义报表视图。 这样，就可以向 Power BI 创建者呈现一组简化的数据，使他们能够基于有用且相关的数据创建模型。 新的无服务器 SQL 数据库将成为创建者的主要源连接和数据湖中数据的友好表示形式。

此方法向 Power BI 提供聚焦、扩充和筛选的数据。

可以使用 Azure Synapse Studio 在 Azure Synapse 工作区中创建无服务器 SQL 数据库。 选择“无服务器”作为 SQL 数据库类型并输入数据库名称。 Power Query 可以通过连接到工作区 SQL 终结点来连接到此数据库。

创建自定义视图

可以创建用于包装无服务器 SQL 池查询的自定义视图。 这些视图将充当 Power BI 连接到的直接、干净的数据源。 视图应该：

• 包含与选项字段关联的标签。
• 仅包含数据建模所需的列，以降低复杂性。
• 筛选掉不必要的行，例如非活动记录。

考虑以下用于检索营销活动数据的视图。

CREATE VIEW [VW_Campaign]
AS
    SELECT
        [base].[campaignid] AS [CampaignID]
        [base].[name] AS [Campaign],
        [campaign_status].[LocalizedLabel] AS [Status],
        [campaign_typecode].[LocalizedLabel] AS [Type Code]
    FROM
        [<MySynapseLinkDB>].[dbo].[campaign] AS [base]
        LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[OptionsetMetadata] AS [campaign_typecode]
            ON [base].[typecode] = [campaign_typecode].[option]
               AND [campaign_typecode].[LocalizedLabelLanguageCode] = 1033
               AND [campaign_typecode].[EntityName] = 'campaign'
               AND [campaign_typecode].[OptionSetName] = 'typecode'
        LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[StatusMetadata] AS [campaign_status]
            ON [base].[statuscode] = [campaign_Status].[status]
               AND [campaign_status].[LocalizedLabelLanguageCode] = 1033
               AND [campaign_status].[EntityName] = 'campaign'
    WHERE
        [base].[statecode] = 0;

请注意，该视图仅包含四列，每列使用一个易记名称作为别名。 还有一个 WHERE 子句仅返回所需的行（在本例中为正在举办的营销活动）。 此外，该视图查询与 OptionsetMetadata 和 StatusMetadata 表（用于检索选项标签）联接的营销活动表。

提示

有关如何检索元数据的详细信息，请参阅直接从适用于 Dataverse 的 Azure Synapse Link 访问选项标签。

查询相应的表

适用于 Dataverse 的 Azure Synapse Link 可确保数据与数据湖中的数据持续同步。 对于高使用量活动，同时写入和读取可能会创建导致查询失败的锁。 为了确保检索数据时的可靠性，在 Azure Synapse 中同步了两个表数据版本。

• 准实时数据：通过检测自最初提取或上次同步以来发生了哪些数据更改，以有效方式提供通过 Azure Synapse Link 从 Dataverse 同步的数据副本。
• 快照数据：提供准实时数据的、按固定间隔更新（在本例中为每小时）的只读副本。 快照数据表名称的后面追加了 _partitioned。

如果你预期会同时执行大量读取和写入操作，请从快照表中检索数据以避免查询失败。

有关详细信息，请参阅访问准实时数据和只读快照数据。

连接到 Synapse Analytics

若要查询 Azure Synapse 无服务器 SQL 池，需要获取其工作区 SQL 终结点。 可以在 Synapse Studio 中通过打开无服务器 SQL 池属性检索终结点。

在 Power BI Desktop 中，可以使用 Azure Synapse Analytics SQL 连接器连接到 Azure Synapse。 当系统提示输入服务器时，请输入工作区 SQL 终结点。

DirectQuery 注意事项

在很多用例中，使用 DirectQuery 存储模式能够解决要求。 但是，使用 DirectQuery 会对 Power BI 报表性能产生负面影响。 使用 DirectQuery 连接到 Dataverse 的报表不如使用导入模型的报表那样快。 一般情况下，应尽可能将数据导入 Power BI。

我们建议在使用 DirectQuery 时考虑本部分中的主题。

有关确定何时使用 DirectQuery 存储模式的详细信息，请参阅选择 Power BI 模型框架。

使用双存储模式维度表

双重存储模式表设置为同时使用导入存储模式和 DirectQuery 存储模式。 在查询时，Power BI 将确定可用的最有效模式。 Power BI 会尽可能尝试使用导入的数据来满足查询，因为这样更快。

在适当的情况下，应考虑将维度表设置为双存储模式。 这样，切片器视觉对象和筛选器卡列表（通常基于维度表列）将更快地呈现，因为它们将从导入的数据中查询。

重要

如果维度表需要继承 Dataverse 安全模型，它就不适合使用双存储模式。

通常会存储大量数据的事实表应保留为 DirectQuery 存储模式表。 它们将由相关的双存储模式维度表筛选，这些表可以联接到事实表，以实现高效的筛选和分组。

考虑以下数据模型设计。 “所有者”、“帐户”和“营销活动”这三个维度表带有条纹上边框，表示它们已设置为双存储模式。

有关表存储模式（包括双存储）的详细信息，请参阅在 Power BI Desktop 中管理存储模式。

启用单一登录

将 DirectQuery 模型发布到 Power BI 服务时，可使用语义模型设置让报表用户能够通过 Microsoft Entra ID（以前称为 Azure Active Directory）OAuth2 进行单一登录 (SSO)。 当 Dataverse 查询必须在报表用户的安全上下文中执行时，应该启用此选项。

启用 SSO 选项后，Power BI 会在查询中将报表用户经过身份验证的 Microsoft Entra 凭据发送到 Dataverse。 此选项使 Power BI 能够遵守在数据源中指定的安全设置。

有关详细信息，请参阅 DirectQuery 源的单一登录 (SSO)。

在 Power Query 中复制“我的”筛选器

使用 Microsoft Dynamics 365 Customer Engagement (CE) 和基于 Dataverse 生成的模型驱动 Power Apps 时，可以创建仅显示用户名字段（例如“所有者”）等于当前用户的视图。 例如，可以创建名为“我的未处理机会”、“我的活动案例”等的视图。

考虑一个演示 Dynamics 365“我的活动帐户”视图包含“所有者等于当前用户”筛选器的示例。

可以使用嵌入 CURRENT_USER 标记的本机查询在 Power Query 中重现此结果。

考虑以下示例，它演示一个返回当前用户帐户的本机查询。 请注意，在 WHERE 子句中，ownerid 列按 CURRENT_USER 标记筛选。

let
    Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false],
    dbo_account = Value.NativeQuery(Source, "
        SELECT
            accountid, accountnumber, ownerid, address1_city, address1_stateorprovince, address1_country
        FROM account
        WHERE statecode = 0
            AND ownerid = CURRENT_USER
    ", null, [EnableFolding]=true])
in
    dbo_account

将模型发布到 Power BI 服务时，必须启用单一登录 (SSO)，以便 Power BI 将报表用户经过身份验证的 Microsoft Entra 凭据发送到 Dataverse。

创建补充导入模型

可以创建一个 DirectQuery 模型来强制实施 Dataverse 权限，但需要知道，这样性能会变慢。 然后，可以使用面向特定使用者或受众的、能够强制实施 RLS 权限的导入模型来补充此模型。

例如，导入模型可以提供对所有 Dataverse 数据的访问，但不强制实施任何权限。 此模型适合已有权访问所有 Dataverse 数据的主管。

另举一例，当 Dataverse 按销售区域强制实施基于角色的权限时，你可以创建一个导入模型并使用 RLS 复制这些权限。 或者，可为每个销售区域创建一个模型。 然后，可以向每个区域的销售人员授予对这些模型（语义模型）的读取权限。 为了便于创建这些区域模型，可以使用参数和报表模板。 有关详细信息，请参阅在 Power BI Desktop 中创建和使用报表模板。

相关内容

有关本文的详细信息，请查看以下资源。

• 适用于 Dataverse 的 Azure Synapse Link
• 了解星型架构及其对 Power BI 的重要性
• 用于导入建模的数据缩减技术
• 是否有任何问题? 尝试咨询 Power BI 社区
• 建议？ 提出改进 Power BI 的想法