Power BI Desktop 中的複合模型指引
本文的目標是開發Power BI複合模型的數據模型設計師。 其描述複合模型使用案例，並提供設計指導。 具體而言，本指導可以協助您判斷複合模型是否適用於您的解決方案。 若適合，本文也會協助您設計最佳的複合模型和報表。
注意
此文章並未涵蓋複合模型的簡介。 如果您尚未完全熟悉複合模型，建議您先閱讀在 Power BI Desktop 中使用複合模型一文。
由於複合模型至少會包含一個 DirectQuery 來源，您也應該徹底了解模型關聯性、DirectQuery 模型，以及 DirectQuery 模型設計指導。
複合模型使用案例
根據定義，複合模型會結合多個來源群組。 來源群組可以代表匯入的資料或 DirectQuery 來源的連接。 DirectQuery 來源可以是關係資料庫或其他表格式模型，可以是 Power BI 語意模型或 Analysis Services 表格式模型。 當表格式模型連接到另一個表格式模型時，即稱為鏈結。 如需詳細資訊，請參閱 在 Power BI Desktop 中使用複合模型。
注意
當模型連線到表格式模型，但不會使用其他資料來擴充它時，它不是複合模型。 在此情況下，它是連線到遠端模型的 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
請考慮複雜關聯性設計的案例，以及如何產生不同但有效的結果。
在此案例中，來源群組中的 Region 數據表 A 與來源群組中的 Date 數據表和來源群組中的 Sales 數據表 B有關聯性。
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
請考慮當跨來源群組關聯性中的資料表之間沒有相符的值時的案例。
在此案例中，來源群組中的 Date 數據表 B 與該來源群組中的 Sales 數據表有關聯，而且與來源群組中的 Target 數據表 A關聯。 所有的關聯性是從 Date 數據表到 Year 數據列的一對多關聯。
Sales 數據表包含儲存銷售金額的 SalesAmount 數據行，而 Target 數據表則包含儲存目標金額的 TargetAmount 資料行。
Date 數據表會儲存 2021 年和 2022 年。
Sales 表儲存2021年（100）和2022年（200）的銷售額，而Target 表則儲存2021年（100）、2022年（200）、和2023年（300）的目標金額，2023年是一個未來年份。
當 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 服務。 請務必徹底測試計算和相依報告。
相關內容
如需本文的詳細資訊，請參閱下列資源。