Power BI Desktop 中的複合模型指引
此文章適用於開發 Power BI 複合模型的資料模型製作人員。 其描述複合模型使用案例，並提供設計指導。 具體而言，本指導可以協助您判斷複合模型是否適用於您的解決方案。 若適合，本文也會協助您設計最佳的複合模型和報表。
注意
此文章並未涵蓋複合模型的簡介。 如果您尚未完全熟悉複合模型，建議您先閱讀在 Power BI Desktop 中使用複合模型一文。
由於複合模型至少會包含一個 DirectQuery 來源，您也應該徹底了解模型關聯性、DirectQuery 模型，以及 DirectQuery 模型設計指導。
複合模型使用案例
根據定義，複合模型會結合多個來源群組。 來源群組可以代表匯入的資料或 DirectQuery 來源的連接。 DirectQuery 來源可以是關聯式資料庫或其他表格式模型，可以是 Power BI 語意模型 (先前稱為資料集) 或 Analysis Services 表格式模型。 當表格式模型連接到另一個表格式模型時，即稱為鏈結。 如需詳細資訊，請參閱使用適用於 Power BI 語意模型和 Analysis Services 的 DirectQuery。
注意
當模型連線到表格式模型，但不會使用其他資料來擴充它時，它不是複合模型。 在此情況下，它是連線到遠端模型的 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 中的 Region 資料表與來源群組 B 中的 Date 資料表和 Sales 資料表具有關聯性。Region 資料表與 Date 資料表之間的關聯性為使用中，而 Region 資料表與 Sales 資料表之間的關聯性則為非使用中狀態。 此外，Region 資料表與 Sales 資料表之間也有作用中的關聯性，這兩者都在來源群組 B 中。Sales 資料表包含名為 TotalSales 的量值，而 Region 資料表包含兩個名為 RegionalSales 和 RegionalSalesDirect 的量值。
以下是量值定義。
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 評估 RegionalSales 量值時，會將來自 Region 資料表的篩選套用至 Sales 資料表和 Date 資料表。 因此，篩選也會從 Date 資料表傳播至 Sales 資料表。 相反地，當 Power BI 評估 RegionalSalesDirect 量值時，它只會將篩選從 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 中的 Target 資料表有關聯性。所有關聯性都是與 Year 資料行相關 Date 資料表中的一對多關聯性。 Sales 資料表包含儲存銷售金額的 SalesAmount 資料行，而 Target 資料表則包含儲存目標金額的 TargetAmount 資料行。
Date 資料表會儲存 2021 年和 2022 年。 Sales 資料表會儲存 2021 年 (100) 和 2022 年 (200) 的銷售金額，而 Target 資料表會儲存 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 服務。 請務必徹底測試計算和相依報告。
相關內容
如需本文的詳細資訊，請參閱下列資源。