Power BI Desktop 中的複合模型指引
本文的目標是開發 Power BI 複合模型的數據模型工具。 它會描述複合模型使用案例，並提供設計指引。 具體來說，指引可協助您判斷複合模型是否適合您的解決方案。 如果是，本文也會協助您設計最佳的複合模型和報表。
注意
本文未涵蓋複合模型的簡介。 如果您不熟悉複合模型，建議您先閱讀 在 Power BI Desktop 中使用複合模型一文。
因為複合模型至少由一個 DirectQuery 來源所組成，因此您也必須徹底瞭解 模型關聯性、 DirectQuery 模型和 DirectQuery 模型設計指引。
複合模型使用案例
根據定義，複合模型會結合多個 來源群組。 來源群組可以代表匯入的數據或 DirectQuery 來源的連接。 DirectQuery 來源可以是關係資料庫或其他表格式模型，可以是 Power BI 語意模型（先前稱為數據集）或 Analysis Services 表格式模型。 當表格式模型連接到另一個表格式模型時，即稱為 鏈結。 如需詳細資訊，請參閱 使用 DirectQuery for Power BI 語意模型和 Analysis Services。
注意
當模型連接到表格式模型，但不會使用其他數據來擴充它時，它不是複合模型。 在此情況下，它是連線到遠端模型的 DirectQuery 模型，因此它只包含一個來源群組。 您可以建立這種類型的模型來修改來源模型物件屬性，例如數據表名稱、數據行排序順序或格式字串。
當擴充企業語意模型時，連線 至表格式模型特別相關（當它是 Power BI 語意模型或 Analysis Services 模型時）。 企業語意模型是數據倉儲開發和作業的基礎。 它會針對數據倉儲中的數據提供抽象層，以呈現商務定義和術語。 它通常用來作為實體數據模型與報表工具之間的連結，例如Power BI。 在大部分組織中，它是由中央小組管理，這就是為什麼它被描述為 企業的原因。 如需詳細資訊，請參閱 企業 BI 使用案例。
您可以考慮在下列情況下開發複合模型。
- 您的模型可能是 DirectQuery 模型，而且您想要提升效能。 在複合模型中，您可以為每個數據表設定適當的記憶體來改善效能。 您也可以新增 使用者定義的匯總。 本文稍後會說明這兩個優化。
- 您想要將 DirectQuery 模型與更多數據結合，這些數據必須匯入模型。 您可以從不同的資料來源或匯出資料表載入匯入的數據。
- 您想要將兩個或多個 DirectQuery 數據源合併成單一模型。 這些來源可以是關係資料庫或其他表格式模型。
注意
複合模型不能包含特定外部分析資料庫的連線。 這些資料庫包括 SAP Business Warehouse，以及將 SAP HANA 視為多維度來源時 SAP HANA。
評估其他模型設計選項
雖然 Power BI 複合模型可以解決特定的設計挑戰，但它們有助於效能變慢。 此外，在某些情況下，可能會發生非預期的計算結果（本文稍後所述）。 基於這些原因，請在存在時評估其他模型設計選項。
盡可能在匯入模式中開發模型。 此模式提供最大的設計彈性和最佳效能。
不過，與大量數據或報告近乎實時數據相關的挑戰，不一定能透過匯入模型來解決。 在這兩種情況下，您可以考慮 DirectQuery 模型，前提是您的數據會儲存在 DirectQuery 模式支援的單一數據源中。 如需詳細資訊，請參閱 Power BI Desktop 中的 DirectQuery 模型。
提示
如果您的目標只是擴充具有更多數據的現有表格式模型，請盡可能將該數據新增至現有的數據源。
表格儲存模式
在複合模型中，您可以為每個資料表設定 儲存模式 （計算數據表除外）。
- DirectQuery： 建議您為代表大量數據的數據表設定此模式，或需要提供近乎實時結果的數據表。 數據永遠不會匯入這些數據表。 這些數據表通常是 事實類型數據表，也就是摘要的數據表。
- 匯入： 建議您針對未用於篩選和分組 DirectQuery 或混合模式中事實數據表的數據表設定此模式。 它也是根據 DirectQuery 模式不支援之來源之數據表的唯一選項。 匯出數據表一律為匯入數據表。
- 雙重： 建議您為 維度類型數據表設定此模式，當有可能與來自相同來源的 DirectQuery 事實類型數據表一起查詢時。
- 混合式： 建議您藉由新增匯入數據分割，並將一個 DirectQuery 分割區新增至事實數據表，以即時包含最新的數據變更，或當您想要透過匯入分割區快速存取最常使用的數據時，同時讓數據倉儲中大部分不常使用的數據。
Power BI 查詢複合模型時，有幾個可能的情況。
- 查詢只會匯入或雙重數據表： Power BI 會從模型快取擷取所有數據。 其可提供最快的效能。 此案例常見於篩選或交叉分析篩選器視覺效果所查詢的維度類型數據表。
- 從相同來源查詢雙重數據表或 DirectQuery 數據表： Power BI 會藉由將一或多個原生查詢傳送至 DirectQuery 來源來擷取所有數據。 它會提供良好的效能，特別是在源數據表上存在適當的索引時。 此案例常見於建立雙重維度類型數據表和 DirectQuery 事實類型數據表的查詢。 這些查詢是 來源群組內部，因此所有一對一或一對多關聯性都會評估為 一般關聯性。
- 從相同來源查詢雙重數據表或混合式數據表：此案例是前兩個案例的組合。 Power BI 會在匯入數據分割中使用時，從模型快取擷取數據，否則會將一或多個原生查詢傳送至 DirectQuery 來源。 它會提供最快的效能，因為只會在數據倉儲中查詢數據配量，尤其是在源數據表上有適當的索引時。 至於雙重維度類型數據表和 DirectQuery 事實類型數據表，這些查詢是來源群組內部，因此所有一對一或一對多關聯性都會評估為一般關聯性。
- 所有其他查詢：這些查詢涉及跨來源群組關聯性。 這是因為匯入數據表與 DirectQuery 數據表相關，或雙重數據表與不同來源的 DirectQuery 數據表相關，在此情況下會以匯入數據表的形式運作。 所有關聯性都會評估為 有限的關聯性。 這也表示，套用至非 DirectQuery 數據表的群組必須傳送至 DirectQuery 來源作為具體化子查詢（虛擬數據表）。 在此情況下，原生查詢可能效率不佳，尤其是大型群組集。
總而言之，我們建議您：
- 請仔細考慮複合模型是正確的解決方案，雖然它允許不同數據源的模型層級整合，但它也會引入設計複雜度，併產生可能的後果（本文稍後所述）。
- 當數據表是儲存大型數據磁碟區的事實類型數據表，或需要提供近乎實時的結果時，請將儲存模式 設定為 DirectQuery 。
- 請考慮使用混合模式，方法是定義累加式重新整理原則和實時數據，或使用 TOM、TMSL 或第三方工具分割事實數據表。 如需詳細資訊，請參閱 語意模型的 累加式重新整理和實時數據，以及 進階數據模型管理 使用案例。
- 當數據表是維度類型數據表時，請將儲存模式 設定為 [雙重 ]，而且會與位於相同來源群組中的 DirectQuery 或混合式事實類型數據表一起查詢。
- 設定適當的重新整理頻率，讓雙數據表和混合式數據表（以及任何相依計算數據表）與源資料庫保持同步的模型快取。
- 努力確保來源群組的數據完整性（包括模型快取），因為當相關數據行值不相符時，有限的關聯性會消除查詢結果中的數據列。
- 盡可能優化 DirectQuery 數據源與適當的索引，以有效率的聯結、篩選和分組。
使用者定義的匯總
您可以將使用者定義的匯總新增至 DirectQuery 數據表。 其用途是改善較高粒紋查詢的效能。
在模型中快取匯總時，它們的行為就像匯入數據表一樣（雖然不能像模型數據表一樣使用它們）。 將匯入匯總新增至 DirectQuery 模型將會導致複合模型。
注意
混合式數據表不支持匯總，因為某些分割區會以匯入模式運作。 您無法在個別 DirectQuery 數據分割的層級新增匯總。
建議匯總遵循基本規則：其數據列計數至少應小於基礎表的 10 倍。 例如，如果基礎表儲存了10億個數據列，則匯總數據表不應超過1億個數據列。 此規則可確保建立和維護匯總的成本有適當的效能提升。
跨來源群組關聯性
當模型關聯性跨越來源群組時，即稱為 跨來源群組關聯性。 跨來源群組關聯性也是 有限的 關聯性，因為沒有保證「一」端。 如需詳細資訊，請參閱關係評估。
注意
在某些情況下，您可以避免建立跨來源群組關聯性。 請參閱本文稍後的使用同步交叉分析篩選器主題。
定義跨來源群組關聯性時，請考慮下列建議。
- 使用低基數關聯性數據行： 為了獲得最佳效能，我們建議關聯性數據行是低基數，這表示它們應該儲存小於 50,000 個唯一值。 結合表格式模型和非文字數據行時，這項建議特別正確。
- 避免使用大型文字關聯性數據行： 如果您必須在關聯中使用文字數據行，請藉由將基數乘以文字數據行的平均長度來計算篩選的預期文字長度。 可能的文字長度不應超過 1,000,000 個字元。
- 提高關聯性粒度： 可能的話，請在較高層級的數據粒度上建立關聯性。 例如，與其與其日期索引鍵上的日期數據表相關，請改用其月份索引鍵。 此設計方法要求相關數據表包含一個月份索引鍵數據行，而報表將無法顯示每日事實。
- 努力達成簡單的關聯性設計： 只在需要時建立跨來源群組關聯性，並嘗試限制關聯性路徑中的數據表數目。 此設計方法有助於改善效能，並避免 模棱兩可的關係路徑。
警告
因為 Power BI Desktop 不會徹底驗證跨來源群組關聯性，所以可以建立模棱兩可的關聯性。
跨來源群組關聯性案例 1
請考慮複雜關聯性設計的案例，以及如何產生不同但有效的結果。
在此案例中，來源群組 A 中的區域數據表與來源群組 B 中的 Date 數據表和 Sales 數據表有關聯性。Region 數據表與 Date 資料表之間的關聯性為使用中，而 Region 數據表與 Sales 數據表之間的關聯性則為非使用中狀態。 此外，區域數據表與 Sales 數據表之間也有作用中關聯性，這兩者都在來源群組 B 中。Sales 數據表包含名為 TotalSales 的量值，而 Region 數據表包含兩個名為 RegionSales 和 RegionSalesDirect 的量值。
以下是量值定義。
TotalSales = SUM(Sales[Sales])
RegionalSales = CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
RegionalSalesDirect = CALCULATE(SUM(Sales[Sales]), USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
請注意 RegionalSales 量值如何參照 TotalSales 量值，而 RegionalSalesDirect 量值則不會。 相反地，RegionalSalesDirect 量值會使用表示式 SUM(Sales[Sales])，這是 TotalSales 量值的運算式。
結果的差異很微妙。 當 Power BI 評估 RegionSales 量值時，會將來自 Region 數據表的篩選套用至 Sales 數據表和 Date 數據表。 因此，篩選也會從 Date 數據表傳播至 Sales 數據表。 相反地，當 Power BI 評估 RegionSalesDirect 量值時，它只會將篩選從 Region 數據表傳播到 Sales 數據表。 RegionalSales 量值和 RegionalSalesDirect 量值傳回的結果可能會不同，即使表達式在語意上相等。
重要
每當您使用 函 CALCULATE 式搭配遠端來源群組中的量值表示式時，請徹底測試計算結果。
跨來源群組關聯性案例 2
當跨來源群組關聯性具有高基數關聯性數據行時，請考慮案例。
在此案例中，Date 數據表與 DateKey 數據行上的 Sales 數據表相關。 DateKey 資料行的數據類型是整數，儲存使用yyyymmdd格式的整數。 數據表屬於不同的來源群組。 此外，這是高基數關聯性，因為 Date 數據表中的最早日期是 1900 年 1 月 1 日，而最新的日期是 2100 年 12 月 31 日，因此數據表中總共有 73,414 個數據列（1900-2100 年時間範圍中每個日期各有一個數據列）。
有兩種情況值得關注。
首先，當您使用 Date 數據表數據行做為篩選時，篩選傳播會篩選 Sales 數據表的 DateKey 資料行來評估量值。 依單一年份篩選時，例如 2022 年，DAX 查詢會包含篩選表達式，例如 Sales[DateKey] IN { 20220101, 20220102, …20221231 }。 當篩選表達式中的值數目很大，或篩選值是長字串時，查詢的文字大小可能會變得非常大。 Power BI 產生長查詢和數據源執行查詢的成本很高。
第二，當您使用 Date 數據表數據行，例如 Year、Quarter 或 Month，做為分組數據行時，會產生包含年份、季或月份之所有唯一組合的篩選，以及DateKey 數據行值。 查詢的字串大小，其中包含群組數據行和關聯性數據行的篩選，可能會變得非常大。 當聯結數據行（DateKey 數據行）的基數很大時，尤其如此。
若要解決任何效能問題，您可以：
- 將 Date 數據表新增至數據源，產生單一來源群組模型（也就是說，它不再是複合模型）。
- 提高關聯性的粒度。 例如，您可以將 MonthKey 數據行新增至兩個數據表，並在這些數據行上建立關聯性。 不過，藉由提高關聯性的粒度，您將失去報告每日銷售活動的能力（除非您使用 Sales 數據表中的 DateKey 數據行）。
跨來源群組關聯性案例 3
當跨來源群組關聯性中的數據表之間沒有相符的值時，請考慮案例。
在此案例中，來源群組 B 中的 Date 數據表與該來源群組中的 Sales 數據表有關聯性，也與來源群組 A 中的目標數據表有關聯性。所有關聯性都是與 Year 數據行相關的 Date 數據表中的一對多關聯性。 Sales 數據表包含儲存銷售金額的 SalesAmount 數據行，而 Target 數據表則包含儲存目標金額的 TargetAmount 資料行。
Date 數據表會儲存 2021 年和 2022 年。 Sales 數據表會儲存 2021 年（100 年）和 2022 年（200 年）的銷售金額，而目標數據表會儲存 2021 年（100 年）、2022 年（200 年）和 2023 年（300 年）的目標金額，也就是未來的一年。
當 Power BI 數據表視覺效果在 Date 數據表的 Year數據行上分組，並加總 SalesAmount 和 TargetAmount 數據行來查詢複合模型時，它不會顯示 2023 年的目標數量。 這是因為跨來源群組關聯性是有限的關聯性，因此會使用 INNER JOIN 語意來排除兩端沒有相符值的數據列。 不過，它會產生正確的目標數量總計 （600），因為 Date 數據表篩選不適用於其評估。
如果 Date 數據表與 Target 數據表之間的關聯性是來源群組內部關聯性（假設 Target 數據表屬於來源群組 B），則視覺效果會包含 [空白] 年份，以顯示 2023 年（以及任何其他不相符年份）目標數量。
重要
為了避免報告錯誤，請在維度和事實數據表位於不同的來源群組時，確定關聯性數據行中有相符的值。
如需有限關聯性的詳細資訊，請參閱 關聯性評估。
計算
將計算結果列和計算群組新增至複合模型時，您應該考慮特定限制。
計算結果欄
新增至 DirectQuery 數據表的匯出數據行，從關係資料庫，例如 Microsoft SQL Server，僅限於一次在單一數據列上運作的表達式。 這些運算式無法使用 DAX 反覆運算器函式，例如 SUMX、 或篩選內容修改函式，例如 CALCULATE。
注意
您無法新增相依於鏈結表格式模型的匯出資料行或匯出資料表。
遠端 DirectQuery 資料表上的匯出數據行表示式僅限於數據列內部評估。 不過，您可以撰寫這類表達式，但會在視覺效果中使用時產生錯誤。 例如，如果您使用表示式[Product Sales] / SUM (DimProduct[ProductSales])，將導出數據行新增至名為 DimProduct 的遠端 DirectQuery 數據表，您將能夠在模型中成功儲存表達式。 不過，它會在視覺效果中使用時產生錯誤，因為它違反了數據列內部評估限制。
相反地，新增至遠端 DirectQuery 數據表的匯出數據行是表格式模型，也就是 Power BI 語意模型或 Analysis Services 模型，更有彈性。 在此情況下，允許所有 DAX 函式，因為表示式將會在來源表格式模型中進行評估。
許多表達式都需要Power BI將匯出數據行具體化，再將其當做群組或篩選，或匯總計算數據行。 當計算結果列在大型數據表上具體化時，視計算結果列相依的數據行基數而定，在 CPU 和記憶體方面可能很昂貴。 在此情況下，建議您將這些匯出數據行新增至來源模型。
注意
當您將計算結果列加入複合模型時，請務必測試所有模型計算。 上游計算可能無法正確運作，因為它們未考慮對篩選內容的影響。
計算群組
如果計算群組存在於連接到Power BI語意模型或 Analysis Services 模型的來源群組中，Power BI 可能會傳回非預期的結果。 如需詳細資訊，請參閱 計算群組、查詢和量值評估。
模型設計
您應該一律採用星型架構設計來優化Power BI模型。
提示
如需詳細資訊，請參閱了解星型結構描述及其對 Power BI 的重要性。
請務必建立與事實數據表分開的維度數據表，讓Power BI可以正確解譯聯結併產生有效率的查詢計劃。 雖然此指引適用於任何 Power BI 模型，但您辨識的模型會成為複合模型的來源群組，尤其如此。 它可讓下游模型中其他數據表的整合更簡單且更有效率。
盡可能避免在與不同來源群組中事實數據表相關的某個來源群組中建立維度數據表。 這是因為最好擁有 來源群組內部 關聯性，而不是 跨 來源群組關聯性，特別是針對高基數關聯性數據行。 如 先前所述，跨來源群組關聯性依賴關聯性數據行中的相符值，否則報表視覺效果中可能會顯示非預期的結果。
資料列層級安全性
如果您的模型包含使用者定義的匯總、匯入數據表上的匯出數據行或匯出數據表，請確定已正確設定並測試任何數據列層級安全性 （RLS）。
如果複合模型連接到其他表格式模型，則 RLS 規則只會套用至定義它們的來源群組（本機模型）。 它們不會套用至其他來源群組（遠端模型）。 此外，您無法在另一個來源群組的數據表上定義 RLS 規則，也無法在與另一個來源群組有關聯性的本機數據表上定義 RLS 規則。
報表設計
在某些情況下，您可以藉由設計優化的報表配置來改善複合模型的效能。
單一來源群組視覺效果
盡可能建立視覺效果，以使用來自單一來源群組的欄位。 這是因為從單一來源群組擷取結果時，視覺效果所產生的查詢會執行得更好。 請考慮建立兩個並排放置的視覺效果，以從兩個不同的來源群組擷取數據。
使用同步交叉分析篩選器
在某些情況下，您可以設定 同步交叉分析篩選器 ，以避免在模型中建立跨來源群組關聯性。 它可讓您以可視化方式結合來源群組，以提升效能。
當您的模型有兩個來源群組時，請考慮案例。 每個來源群組都有一個用來篩選轉銷商和因特網銷售的產品維度數據表。
在此案例中，來源群組 A 包含與 ResellerSales 數據表相關的 Product 數據表。 來源群組 B 包含與 InternetSales 數據表相關的 Product2 數據表。 沒有任何跨來源群組關聯性。
在報表中，您會新增交叉分析篩選器，以使用 Product 數據表的 Color 數據行來篩選頁面。 交叉分析篩選器預設會 篩選 ResellerSales 數據表，但不會 篩選 InternetSales 數據表。 接著，您可以使用 Product2 資料表的 Color 資料行來新增隱藏的交叉分析篩選器。 藉由設定相同的組名（位於同步交叉 分析篩選器進階選項中），套用至可見交叉分析篩選器的篩選會自動傳播至隱藏的交叉分析篩選器。
注意
雖然使用同步交叉分析篩選器可以避免建立跨來源群組關聯性，但會增加模型設計的複雜性。 請務必教育其他用戶為何設計具有重複維度數據表的模型。 隱藏您不希望其他使用者使用的維度數據表，以避免混淆。 您也可以將描述文字新增至隱藏資料表，以記錄其用途。
如需詳細資訊，請參閱 同步個別交叉分析篩選器。
其他指引
以下是一些其他指引，可協助您設計和維護複合模型。
- 效能和規模：如果您的報表先前已即時連線到 Power BI 語意模型或 Analysis Services 模型，Power BI 服務 可以跨報表重複使用視覺快取。 轉換即時連線以建立本機 DirectQuery 模型之後，報表將不再受益於這些快取。 因此，您可能會遇到效能變慢，甚至重新整理失敗。 此外，Power BI 服務 的工作負載將會增加，這可能需要您相應增加容量，或將工作負載分散到其他容量。 如需數據重新整理和快取的詳細資訊，請參閱 Power BI 中的數據重新整理。
- 重新命名： 不建議重新命名複合模型所使用的語意模型，或重新命名其工作區。 這是因為複合模型會使用工作區和語意模型名稱連接到Power BI語意模型（而不是其內部唯一標識符）。 重新命名語意模型或工作區可能會中斷複合模型所使用的連接。
- 治理： 我們不建議您單 一版本的真人 模型是複合模型。 這是因為它會相依於其他數據源或模型，如果更新，可能會導致複合模型中斷。 相反地，我們建議您將企業語意模型發佈為單一版本的真理。 請將此模型視為可靠的基礎。 然後，其他數據模型建立複合模型，以擴充基礎模型來建立特製化模型。
- 數據譜系： 發佈複合模型變更之前， 請先使用數據譜系 和 語意模型影響分析 功能。 這些功能可在 Power BI 服務 中使用，可協助您了解語意模型的相關方式和使用方式。 請務必瞭解，您無法對歷程檢視中顯示的外部語意模型執行影響分析，但實際上位於另一個工作區中。 若要對外部語意模型執行影響分析，您必須流覽至來源工作區。
- 架構更新： 當對上游數據源進行架構變更時，您應該在Power BI Desktop 中重新整理複合模型。 接著，您必須將模型重新發佈至 Power BI 服務。 請務必徹底測試計算和相依報告。
相關內容
如需本文的詳細資訊，請參閱下列資源。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應