適用於 Power Platform 的 Power BI 模型化指引
Microsoft Dataverse 是適用於許多 Microsoft 商務應用程式產品的標準資料平台,包括 Dynamics 365 Customer Engagement 和 Power Apps 畫布應用程式,以及 Dynamics 365 Customer Voice (先前稱為 Microsoft Forms Pro)、Power Automate 核准、Power Apps 入口網站等。
此文章提供如何建立連線到 Dataverse 的 Power BI 資料模型的指引。 其描述 Dataverse 結構描述與已最佳化 Power BI 結構描述之間的差異,並提供在 Power BI 中擴展商務應用程式資料可見度的指引。
由於 Dataverse 易於設定、快速部署及廣泛採用,因此,可在跨組織的環境中儲存和管理不斷增加的資料量。 這意味著將分析與那些流程整合的需求 (和機會) 更大。 機會包括:
- 報告超出內建圖表條件約束的所有 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 模型只會在使用者開啟報表之後從來源擷取資料,因而導致報表轉譯時出現數秒的延遲。 此外,報表上的使用者互動需要 PowerBI 重新查詢來源,進一步降低回應性。
資料量
開發匯入模型時,您應該努力將載入到模型的資料量降至最低。 對於大型模型或是您預期大小會隨著時間逐步成長的模型來說更是如此。 如需詳細資訊,請參閱匯入模型化的資料縮減技術。
若報表的查詢結果不大,與 Dataverse 的 DirectQuery 連線是不錯的選擇。 大型查詢結果在報表來源資料表中有超過 20,000 個資料列,或者套用篩選之後傳回給報表的結果超過 20,000 個資料列。 在此情況下,您可以使用 Dataverse 連接器建立 Power BI 報表。
注意
20,000 個資料列大小並非硬性限制。 不過,每個資料來源查詢都必須在 10 分鐘內傳回結果。 您將在此文章稍後了解如何在那些限制內運作,以及其他 Dataverse DirectQuery 設計考量。
您可以使用 Dataverse 連接器將數據匯入數據模型,來改善較大語意模型的效能。
即使是較大語意模型 (具有數十萬甚至數百萬個資料列),也能夠因為使用適用於 Dataverse 的 Azure Synapse Link 而受益。 此方法會設定持續受控的管線,以 CSV 或 Parquet 檔案形式,將 Dataverse 資料複製到 ADLS Gen2。 Power BI 接著可以查詢 Azure Synapse 無伺服器 SQL 集區以載入匯入模型。
資料延遲
若 Dataverse 資料快速變更且報表使用者需要查看最新資料,DirectQuery 模型能夠提供近即時的查詢結果。
提示
您可以建立 Power BI 報表,使用自動頁面重新整理來顯示即時更新,但前提是報表必須連線到 DirectQuery 模型。
匯入資料模型必須完成資料重新整理,才能報告最近的資料變更。 請記住,每日排定的資料重新整理作業數目是有限制的。 您在共用容量上每天最多可排程八次重新整理。 在 Premium 容量或 Microsoft Fabric 容量上,您每天最多可排程 48 次重新整理,其可達到 15 分鐘的重新整理頻率。
重要
此文章有時會提及 Power BI Premium 或其容量訂用帳戶 (P SKU)。 請注意,Microsoft 目前正在整合購買選項,並按容量 SKU 淘汰 Power BI Premium。 新客戶和現有客戶應考慮改為購買 Fabric 容量訂用帳戶 (F SKU)。
如需詳細資訊,請參閱 Power BI Premium 授權的重要更新和 Power BI Premium 常見問題集。
您也可以考慮使用累加式重新整理,以實現更快速的重新整理和近即時的效能 (僅適用於 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 權限。 設定儲存體帳戶和 Synapse 工作區需要這些 Azure 權限。
建議做法
此節描述您在建立連線到 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 Query 在 Power BI Desktop 中製作和模型重新整理時執行的作業,請參閱查詢診斷。
將查詢資料行的數目降至最低
根據預設,當您使用 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 函式。
如需詳細資訊,請參閱
搭配 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 相關的資料行:territory、territoryid 及 territoryidname。
當您設定 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 的資料和中繼資料連續複寫到資料湖。 其也提供內建的無伺服器 SQL 集區作為 Power BI 查詢的便利資料來源。
此方法的優點相當顯著。 客戶能夠使用各種進階服務,跨 Dataverse 資料執行分析、商業智慧及機器學習工作負載。 進階服務包括 Apache Spark、Power BI、Azure Data Factory、Azure Databricks 和 Azure Machine Learning。
建立適用於 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 確保資料會持續與 Data Lake 中的資料同步處理。 針對高使用量活動,同時寫入和讀取可能會建立導致查詢失敗的鎖定。 為了確保擷取資料時的可靠性,會在 Azure Synapse 中同步處理兩個版本的資料表資料。
- 近即時資料:藉由偵測哪些資料自最初擷取或上次同步處理之後已變更,以有效率的方式提供已透過 Azure Synapse Link 從 Dataverse 同步處理的資料複本。
- 快照集資料:提供要定期更新 (在此案例中為每小時) 之近即時資料的唯讀複本。 快照集資料表名稱已將 _partitioned 附加至其名稱。
如果您預期將同時執行大量讀取和寫入作業,請從快照集資料表擷取資料,以避免查詢失敗。
如需詳細資訊,請參閱存取近乎即時資料和唯讀快照集資料。
連線到 Synapse Analytics
若要查詢 Azure Synapse 無伺服器 SQL 集區,您將需要其工作區 SQL 端點。 您可以開啟無伺服器 SQL 集區屬性,從 Synapse Studio 擷取端點。
在 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 儲存模式資料表。 這類資料表將依相關的雙重儲存模式維度資料表進行篩選,其可聯結到事實資料表以實現有效率的篩選和群組。
請考慮下列資料模型設計。 三個維度資料表 (Owner、Account 及 Campaign) 具有條紋的上框線,這表示已將其設定為雙重儲存模式。
如需資料表儲存模式 (包括雙重儲存) 的詳細資訊,請參閱管理 Power BI Desktop 中的儲存模式。
啟用單一登入
當您將 DirectQuery 模型發佈至 Power BI 服務 時,您可以使用語意模型設定,為您的報表使用者使用 Microsoft Entra ID OAuth2 來啟用單一登錄 (SSO)。 當 Dataverse 查詢必須在報表使用者的資訊安全內容中執行時,您應該啟用此選項。
啟用 SSO 選項時,Power BI 會將查詢中報表使用者已驗證的 Microsoft Entra 認證傳送到 Dataverse。 此選項可讓 Power BI 遵守在資料來源中所設定的安全性設定。
如需詳細資訊,請參閱 DirectQuery 來源的單一登入 (SSO)。
在 Power Query 中複寫「我的」篩選
使用 Microsoft Dynamics 365 Customer Engagement (CE) 及建置於 Dataverse 之上模型驅動的 Power Apps 時,您可以建立檢視,只顯示使用者名稱欄位 (例如 Owner) 等於目前使用者的記錄。 例如,您可以建立名為「我的開放商機」、「我的使用中案例」等檢視。
請考慮下列範例: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。
建立補充匯入模型
您可以建立強制執行 Dataverse 權限的 DirectQuery 模型,以「得知」效能將變慢。 接著,可使用以特定主體或對象 (可強制執行 RLS 權限) 為目標的匯入模型來補充此模型。
例如,匯入模型可以提供對所有 Dataverse 資料的存取權,但無法強制執行任何權限。 此模型適用於已經有權存取所有 Dataverse 資料的主管。
另一個範例是,當 Dataverse 依銷售區域強制執行角色型權限時,您可以建立一個匯入模型,並使用 RLS 複寫那些權限。 或者,您可以為每個銷售區域建立一個模型。 然後,將那些模型 (語意模型) 的讀取權限授與每個區域的銷售人員。 為了方便建立這些區域模型,您可以使用參數和報表範本。 如需詳細資訊,請參閱在 Power BI Desktop 中建立及使用報表範本。
相關內容
如需與此文章相關的詳細資訊,請參閱下列資源。