在 Power BI Desktop 使用複合模型

先前在 Power BI Desktop 中，當您在報表中使用 DirectQuery 時，該報表都不允許其他 DirectQuery 或「匯入」資料連線。 複合模型可以移除該限制。 報表能以各種組合，完美地包含來自多個 DirectQuery 或「匯入」資料連線的資料連線。

Power BI Desktop 中的複合模型功能包含三種相關功能：

• 複合模型：允許報表具有來自不同來源群組的兩個或多個資料連線。 這些來源群組可以是一或多個 DirectQuery 連線及一個匯入連線、兩個或更多個 DirectQuery 連線，或上述項目的任意組合。 本文會詳細描述複合模型。

• 多對多關聯性：使用複合模型，可以在資料表之間建立「多對多關聯性」。 此方法會移除資料表中唯一值的需求。 其也會消除先前的因應措施，例如只引進新的資料表來建立關聯性。 如需詳細資訊，請參閱在 Power BI Desktop 中套用多對多關聯性。

• 儲存模式：您現在可以指定哪些視覺效果查詢後端資料來源。 此功能可提升效能，並減輕後端的負載。 先前即使是像交叉分析篩選器這類簡單的視覺效果，都會起始查詢，以查詢後端來源。 如需詳細資訊，請參閱管理 Power BI Desktop 中的儲存模式。

使用複合模型

您可以運用複合模型，在使用 Power BI Desktop 或 Power BI 服務時，連線到不同類型的資料來源。 您可以用幾種方式進行這些資料連線：

• 將資料匯入至 Power BI，這是取得資料的最常見方式。
• 透過使用 DirectQuery 直接連線到資料原始來源存放庫中的資料。 如需 DirectQuery 的詳細資訊，請參閱 Power BI 中的 DirectQuery。

當您使用 DirectQuery 時，可透過「複合模型」建立可執行下列作業其中之一或兩者的 Power BI 模型 (例如，單一 .pbix Power BI Desktop 檔案)：

• 結合來自一或多個 DirectQuery 來源的資料。
• 結合來自 DirectQuery 來源的資料與「匯入」資料。

例如，您可以藉由使用複合模型來建置結合下列資料類型的模型：

• 來自企業資料倉儲的銷售資料。
• 來自部門 SQL Server 資料庫的銷售目標資料。
• 從試算表匯入的資料。

結合多個 DirectQuery 來源的資料或結合 DirectQuery 與「匯入」資料的模型，即稱為「複合模型」。

您能如往常一般，建立資料表之間的關聯性 (即使這些資料表來自不同的來源)。 不論實際基數為何，任何跨來源的關聯性都會使用「多對多」基數來建立。 您可以將其變更為一對多、多對一或一對一。 無論您設定哪一種基數，跨來源的關聯性都有不同的行為。 您無法使用資料分析運算式 (DAX) 函式，從 many 端抓取 one 端的值。 您也可能會看到相同來源中多對多關聯性對效能的影響。

複合模型範例

如需「複合模型」的範例，請考慮使用 DirectQuery 連線到 SQL Server 中公司資料倉儲的報表。 在此情況下，資料倉儲會包含「依國家/地區的銷售額」、「季」和「腳踏車 (產品)」資料，如下圖所示：

此時，您可以使用此來源中的欄位，以建置簡單的視覺效果。 下圖是依 ProductName 顯示所選季度的總銷售額。

但是，如果您有資料在 Excel 試算表中，且是關於指派給每個產品的產品經理以及行銷優先順序，該怎麼辦？ 如果您想要依「產品經理」檢視「銷售額」，可能無法將此本機資料新增至公司的資料倉儲。 或者，在最佳的情況下可能需要幾個月的時間。

可能可以從資料倉儲匯入銷售資料，而不是使用 DirectQuery。 銷售資料便可以與您從試算表匯入的資料結合。 不過，該方法並不合理，因為會導致在一開始時使用 DirectQuery。 原因可能包括：

• 在基礎來源實施的某個安全性規則組合。
• 要能夠檢視最新資料的需求。
• 純粹因為資料規模。

這就是複合模型派上用場的地方。 複合模型可讓您使用 DirectQuery 連線到資料倉儲，然後針對其他來源使用 [取得資料]。 在此範例中，我們會先建立對公司資料倉儲的 DirectQuery 連線。 我們使用 [取得資料]、選擇 [Excel]，然後瀏覽至包含我們本機資料的試算表。 最後，我們匯入試算表，其中包含「產品名稱」、指派的「銷售經理」和「優先順序」。

在 [欄位] 清單中，您可以看到兩個資料表：來自 SQL Server 的原始 Bike 資料表，和新的 ProductManagers 資料表。 新資料表會包含從 Excel 匯入的資料。

同樣地，在 Power BI Desktop 的 [關聯性] 檢視中，現在可看到稱為 ProductManagers 的其他資料表。

我們現在需要將這些資料表與模型中的其他資料表相關聯。 如往常，我們在來自 SQL Server 的 Bike 資料表，與匯入的 ProductManagers 資料表之間建立關聯性。 亦即，關聯性是在 Bike[ProductName] 與 ProductManagers[ProductName] 之間。 如先前所述，跨來源的所有關聯性預設為「多對多」基數。

現在我們已經建立此關聯性，它就會如我們所預期，顯示在 Power BI Desktop 的 [關聯性] 檢視中。

我們現在可以使用 [欄位] 清單中的任何欄位來建立視覺效果。 這種方法可順暢地混合使用多個來源的資料。 例如，每個「產品經理」的 SalesAmount 總計會顯示在下圖中：

下列範例顯示使用從他處所匯入一些額外資料來擴充「維度」資料表 (例如「產品」或「客戶」) 的常見情況。 也可以讓資料表使用 DirectQuery 連線到各種來源。 為了繼續我們的範例，假設每個 Country 與 Period 的 SalesTargets 都儲存在個別部門資料庫中。 您可以照常使用 [取得資料] 來連線到該資料，如下圖所示：

如我們先前所執行，可在新的資料表與模型中其他資料表之間建立關聯性。 然後，我們可以建立結合資料表資料的視覺效果。 讓我們再次查看 [關聯性] 檢視，我們已在此建立了新的關聯性：

下圖是以新資料和我們所建立的關聯性為基礎。 左下角的視覺效果顯示「銷售額」總計與「目標」，而變異數計算則顯示差異。 「銷售額」和「目標」資料來自兩個不同的 SQL Server 資料庫。

設定儲存模式

複合模型中的每個資料表都有儲存模式，指出該資料表是以 DirectQuery 或「匯入」為基礎。 儲存模式可在 [屬性] 窗格中檢視和修改。 若要顯示儲存模式，請以滑鼠右鍵按一下 [欄位] 清單中的資料表，然後選取 [屬性]。 下圖顯示 SalesTargets 資料表的儲存模式。

每個資料表的工具提示上也可檢視儲存模式。

針對包含來自 DirectQuery 的一些資料表與一些「匯入」資料表的任何 Power BI Desktop 檔案 (.pbix 檔案)，狀態列會顯示稱為 [混合] 的儲存模式。 您可以選取狀態列中的該字詞，然後將所有資料表輕鬆地切換為匯入。

如需儲存模式的詳細資訊，請參閱管理 Power BI Desktop 中的儲存模式。

計算資料表

您可以將導出資料表新增至使用 DirectQuery 的 Power BI Desktop 內模型。 定義導出資料表的資料分析運算式 (DAX) 可以參考匯入或 DirectQuery 資料表，或兩者的組合。

導出資料表一律為匯入，而且會在您重新整理資料表時，重新整理其資料。 如果導出資料表參考 DirectQuery 資料表，則參考 DirectQuery 資料表的視覺效果一律會顯示基礎來源中的最新值。 或者，參考導出資料表的視覺效果，會顯示導出資料表最近一次重新整理時的值。

安全性隱含意義

複合模型對安全性會有一些影響。 傳送至某個資料來源的查詢，可能包含從其他來源擷取的資料值。 在先前範例中，依「產品經理」顯示「銷售額」的視覺效果，會傳送 SQL 查詢給 Sales 關聯式資料庫。 該 SQL 查詢可能包含「產品經理」的名稱及其相關聯「產品」。

因此，傳送至關聯式資料庫的查詢現在會包含儲存在試算表中的資訊。 如果這是機密資訊，您應該考慮安全性影響。 特別是，請考慮下列幾點：

• 可以檢視追蹤或稽核記錄檔的任何資料庫系統管理員，都可以檢視這項資訊，即使沒有資料原始來源的資料權限亦然。 在此範例中，系統管理員需要 Excel 檔案的權限。

• 應該考慮每個來源的加密設定。 您想要避免透過加密連線從其中一個來源擷取資訊，然後意外地將它包含在透過未加密連線傳送至另一個來源的查詢中。

為了允許確認您已經考慮過所有安全性意涵，當您建立複合模型時，Power BI Desktop 會顯示警告訊息。

此外，如果作者將「模型 A」中的「資料表 1」新增至複合模型 (以下統稱「模型 C」)，則當使用者檢視建置於「模型 C」中的報表時，即可查詢在「模型 A」中不受低層級安全性 RLS 保護的任何資料表。

基於類似原因，當您開啟從不受信任來源傳送的 Power BI Desktop 檔案時，請小心。 如果檔案包含複合模型，則某人使用檔案開啟者的使用者認證來從某一個來源擷取的資訊會作為部分查詢傳送到另一個資料來源。 Power BI Desktop 檔案的惡意作者可能會檢視這項資訊。 當您初次開啟包含多個來源的 Power BI Desktop 檔案時，Power BI Desktop 會顯示警告。 此警告和開啟包含原生 SQL 查詢的檔案時所顯示的警告類似。

對於效能的影響

使用 DirectQuery 時，您應該一律考量效能，主要是為了確保後端來源有充足的資源，以便為使用者提供良好的體驗。 良好的體驗表示視覺效果在五秒內重新整理。 如需更多效能建議，請參閱 Power BI 中的 DirectQuery。

使用複合模型會增加額外的效能考量。 單一視覺效果可能會導致傳送查詢到多個來源，這通常會將某一個查詢的結果傳遞到第二個來源。 這種情況可能會導致下列執行形式：

• 包含大量常值的來源查詢：例如，針對一組選取的「產品經理」要求「銷售額」總計的視覺效果，必須先找出哪些「產品」是由那些產品經理管理。 此順序必須在視覺效果傳送以 WHERE 子句包含所有產品識別碼的 SQL 查詢之前進行。

• 以較低粒度層級進行查詢的來源查詢，然後資料在本機進行彙總：當符合「產品經理」篩選準則的「產品」數目變大時，將所有產品包含在一個 WHERE 子句中可能會變得沒有效率或不可行。 相反地，您可以較低「產品」層級來查詢關聯式來源，然後在本機彙總結果。 如果「產品」基數超過 1 百萬的上限，查詢就會失敗。

• 依值分組，每個群組一個的多個來源查詢：當彙總使用 DistinctCount 且是依據另一來源的某資料行來分組時，如果外部來源不支援有效率地傳遞定義群組的許多常值，就有必要依值分組，每個群組傳送一個 SQL 查詢。

  依「產品經理」(從試算表匯入) 要求 CustomerAccountNumber (來自 SQL Server 資料表) 相異計數的視覺效果，就需要在傳送至 SQL Server 的查詢中傳遞來自「產品經理」資料表的詳細資料。 針對其他來源 (例如 Redshift)，此動作不可行。 相反地，針對每個「銷售經理」會傳送一個 SQL 查詢；最多以實際限制為限，超過就會查詢失敗。

上述每一種情況對於效能各有其影響，確切的細節也會隨每個資料來源而異。 雖然在聯結兩個來源的關聯性中，會維持使用低資料行基數 (數千個)，但效能應不會受到影響。 當這個基數增加時，您應該更加注意對於結果效能的影響。

此外，使用「多對多」關聯性時，表示必須針對每個總計或小計層級，將個別查詢傳送至基礎來源，而不是在本機彙總詳細值。 一個包含總計的簡單資料表視覺效果會傳送兩個來源查詢，而不是一個。

來源群組

來源群組是來自 DirectQuery 來源或資料模型中所有匯入來源的項目集合，例如資料表和關聯性。 複合模型是由一或多個來源群組所組成。 請參考下列範例：

• 複合模型連接到稱為 Sales 的 Power BI 語意模型，並藉由新增原始語意模型中無法使用的 Sales YTD 量值來擴充語意模型。 此模型包含一個來源群組。
• 結合資料的複合模型，其方式是從名為 Targets 的 Excel 工作表和稱為 Regions的 CSV 檔案匯入資料表，以及建立 DirectQuery 連線，連至稱為 Sales 的 Power BI 語意模型。 在此情況下，有兩個來源群組，如下圖所示：
  • 第一個來源群組包含來自 Targets Excel 工作表的資料表，以及 Regions CSV 檔案。
  • 第二個來源群組包含來自 Sales Power BI 語意模型的項目。

如果您已將另一個 DirectQuery 連線新增至另一個來源，例如 DirectQuery 連線至名為 Inventory的 SQL Server 資料庫，則來自該來源的項目會新增另一個來源群組：

來源群組和關聯性

複合模型中有兩種類型的關聯性：

• 內部來源群組關聯性。 這些關聯性會將來源群組內的項目關聯在一起。 除非這些關聯性是多對多的，否則這些關聯性一律是一般關聯性，在此情況下會受到限制。
• 跨來源群組關聯性。 這些關聯性會從一個來源群組開始，並結束在不同的來源群組中。 所有關聯性都一律會是受限關聯性。

深入瞭解一般和有限關聯性之間的差異和其影響。

例如，在下圖中，我們新增了三個跨來源群組關聯性，將不同來源群組的資料表關聯在一起：

本機和遠端

屬於 DirectQuery 來源群組的來源群組中，任何項目都會被視為遠端，除非項目在本機定義為 DirectQuery 來源的延伸模組或擴充的一部分，而且不屬於遠端來源，例如量值或導出資料表。 以 DirectQuery 來源群組資料表為根據的導出資料表屬於「匯入」來源群組，被視為本機群組。 「匯入」來源群組中的任何項目都會視為本機項目。 例如，如果您在使用 DirectQuery 連線至庫存來源的複合模型中定義下列量值，則會將量值視為本機量值：

[Average Inventory Count] = Average(Inventory[Inventory Count])

計算群組、查詢和量值評估

計算群組提供一種方式，以減少備援量值的數目，並將一般量值運算式分組在一起。 一般使用案例是時間智能計算，能夠從實際值切換為月初至今、季初至今或年初至今計算。 使用複合模型時，請務必注意計算群組之間的互動，以及量值是否只參考來自單一遠端來源群組的項目。 如果量值只參考來自單一遠端來源群組的項目，而遠端模型定義會影響量值的計算群組，則會套用該計算群組，即使量值是在遠端模型或本機模型中定義也一樣。 不過，如果量值並未唯獨參考單一遠端來源群組中的項目，而是參考了套用遠端計算群組的遠端來源群組項目，則量值的結果仍會受到遠端計算群組的影響。 請考慮下列範例：

• 轉銷商銷售是遠端模型中定義的量值。
• 遠端模型包含可變更轉銷商銷售結果的計算群組
• 網際網路銷售是本機模型中定義的量值。
• 總銷售是本機模型中定義的量值，且具有下列定義：

[Total Sales] = [Internet Sales] + [Reseller Sales]

在此案例中，網際網路銷售量值不會受到遠端模型中定義的計算群組所影響，因為不屬於相同模型。 不過，計算群組可以變更轉銷商銷售量值的結果，因為位於相同的模型中。 這表示必須仔細評估總銷售量值傳回的結果。 假設我們使用遠端模型中的計算群組來傳回年初至今的結果。 轉銷商銷售所傳回的結果現在是年初至今的值，而網際網路銷售傳回的結果仍然是實際值。 總銷售的結果現在可能出人意料，因為會將實際值新增至年初至今的結果。

Power BI 語意模型和 Analysis Services 上的複合模型

您可以透過複合模型搭配 Power BI 語意模型和 Analysis Services，使用 DirectQuery 連線來建置複合模型，以連線到 Power BI 語意模型、Azure Analysis Services (AAS) 和 SQL Server 2022 Analysis Services。 您可以使用複合模型，將這些來源中的資料與其他 DirectQuery 和匯入的資料結合。 若報表作者想要將其企業語意模型的資料與其擁有的其他資料 (例如 Excel 試算表) 合併，或者想要將其企業語意模型的中繼資料個人化或加以擴充，則會發現此功能特別有用。

在 Power BI 語意模型上管理複合模型

若要在 Power BI 語意模型上啟用複合模型的建立和取用，您的租用戶必須啟用下列參數：

• 允許內部部署語意模型的 XMLA 端點，以及在 Excel 中進行分析。 如果停用此開關，就無法與 Power BI 語意模型建立 DirectQuery 連線。
• 使用者可以使用即時連線在 Excel 中處理 Power BI 語意模型。 如果停用此開關，使用者就無法即時連線至 Power BI 語意模型，所以就會無法使用變更此模型按鈕。
• 允許 DirectQuery 連線至 Power BI 語意模型。 若要進一步了解此開關及停用影響，請參閱以下段落。

此外，若使用 Premium 容量和 Premium Per User，則應啟用 [XMLA 端點] 設定並設定為 [唯讀] 或 [讀取/寫入]。

租用戶管理員可以在管理入口網站中啟用或停用 Power BI 語意模型的 DirectQuery 連線。 雖然這項功能預設為啟用，但如果停用，將會阻止使用者在 Power BI 語意模型上將新的複合模型發佈至服務。

在 Power BI 語意模型上使用複合模型的現有報表將繼續運作，而且使用者仍然能夠使用 Desktop 建立複合模型，但將無法發佈至服務。 系統會改為在您選取 [變更此模型] 來建立 Power BI 語意模型的 DirectQuery 連線時，顯示下列警告訊息：

這樣一來，您仍然可以在本機 Power BI Desktop 環境中探索語意模型，並建立複合模型。 但是會無法將報表發佈至服務。 當您發佈報表和模型時，您會看到下列錯誤訊息，且系統會禁止發佈：

與 Power BI 語意模型的即時連線不會受到此開關所影響，也不會與 Analysis Services 建立即時或 DirectQuery 連線。 無論此開關是否已關閉，這些連線都會繼續運作。 而且，在 Power BI 語意模型上使用複合模型的任何已發佈報表，即使在發佈之後關閉此開關，仍會繼續運作。

在語意模型或模型上建置複合模型

若要在 Power BI 語意模型或 Analysis Services 模型上建置複合模型，報表必須具有本機模型。 您可以從即時連線開始，然後新增或升級至本機模型，或開始使用 DirectQuery 連線或匯入的資料，這會在您的報表中自動建立本機模型。

若要查看您的模型中正在使用哪些連線，請檢查 Power BI Desktop 右下角的狀態列。 如果您只連線到 Analysis Services 來源，則會看到如下圖所示的訊息：

如果您連線到 Power BI 語意模型，就會看到一則訊息，告知您已連線到哪個 Power BI 語意模型：

如果您想要在即時連線語意模型中自訂欄位的中繼資料，請在狀態列中選取 [對此模型進行變更]。 或者，您可以選取功能區中的 [對此模型進行變更] 按鈕，如下圖所示。 在 [報表檢視] 中，[對此模型進行變更] 按鈕位於 [模型化] 索引標籤中。在 [模型檢視] 中，該按鈕位於 [常用] 索引標籤中。

選取此按鈕，即會顯示一個對話方塊來確認要新增本機模型。 選取 [新增本機模型]，以針對來自 Power BI 語意模型或 Analysis Services 的欄位，建立新的資料行或修改中繼資料。 下圖顯示對話方塊。

當您即時連線到 Analysis Services 來源時，不會有本機模型。 若要針對即時連線來源 (例如 Power BI 語意模型和 Analysis Services) 使用 DirectQuery，您必須在報表中新增本機模型。 當您將具有本機模型的報表發佈至 Power BI 服務時，也會發佈該本機模型的語意模型。

鏈結

語意模型及其所依據的語意模型會形成一個鏈結。 此程序稱為鏈結，可讓您根據其他 Power BI 語意模型發佈報表和語意模型，這是前所未有的功能。

例如，假設您的同事發佈稱為「銷售與預算」的 Power BI 語意模型，該資料集以稱為「銷售」的 Analysis Services 模型為基礎，而且與稱為「預算」的 Excel 工作表合併。

當您發佈稱為「歐洲銷售與預算」的新報表 (和語意模型) 時，會以您同事發佈的「銷售與預算」Power BI 語意模型為基礎。當您進行某些進一步修改或擴充時，可以有效地將報表和語意模型新增至長度三的鏈結中，這會從「銷售」 Analysis Services 模型開始，並以您的「歐洲銷售與預算」Power BI 語意模型作為結尾。 下圖將此鏈結程序視覺化。

上圖中的鏈結長度為三，這是最大長度。 不支援鏈結長度超過三的延伸，而且會導致錯誤。

權限和授權

使用複合模型存取報表的使用者對於鏈結中的所有語意模型和模型，必須具有適當權限。

複合模型的擁有者在作為來源的語意模型上，需要具有建置權限，讓其他使用者可以代表擁有者存取這些模型。 因此，若要在 Power BI Desktop 中建立複合模型連線，或在 Power BI 中製作報表，需要在作為來源的語意模型上具有建置權限。

使用複合模型檢視報表的使用者通常需要在複合模型本身以及作為來源的語意模型上，具有讀取權限。 如果報表位於 Pro 工作區中，可能需要建置權限。 應為使用者啟用這些租用戶交換器。

您可以使用下列範例來說明所需的權限：

• 複合模型 A (由擁有者 A 所擁有)

  • 資料來源 A1：語意模型 B。
    擁有者 A 在語意模型 B 上必須具有建置權限，使用者才能透過複合模型 A 檢視報表。

• 複合模型 C (由擁有者 C 所擁有)

  • 資料來源 C1：語意模型 D
    擁有者 C 必須在語意模型 D 上具有建置權限，使用者才能透過複合模型 C 檢視報表。
  • 資料來源 C2：複合模型 A
    擁有者 C 必須在複合模型 A 上具有建置權限，並且在語意模型 B 上具有讀取權限。

使用複合模型 A 檢視報表的使用者在複合模型 A 和語意模型 B 上必須都具有讀取權限，而使用複合模型 C 檢視報表的使用者在複合模型 C、語意模型 D、複合模型 A 和語意模型 B 上必須具有讀取權限。

如果鏈結中的任何資料集位於 Premium Per User 工作區中，則存取它的使用者需要 Premium Per User 授權。 如果鏈結中的任何資料集位於 Pro 工作區中，則存取它的使用者需要 Pro 授權。 如果鏈結中的所有資料集都位於 Premium 容量上，或 Fabric F64 或更大的容量，則使用者可以透過 Free 授權來存取。

安全性警告

使用 Power BI 語意模型和 Analysis Services 模型上的複合模型功能將會顯示安全性警告對話方塊，如下圖所示。

資料可能會從一個資料來源推送至另一個，這與在資料模型中合併 DirectQuery 和匯入來源的安全性警告相同。 若要深入了解此行為，請參閱在 Power BI Desktop 中使用複合模型。

支援的案例

您可以使用 Power BI 語意模型或 Analysis Services 模型的資料來建置複合模型，以用於下列案例：

• 連接各種來源的資料：匯入 (例如檔案)、Power BI 語意模型、Analysis Services 模型
• 建立不同資料來源之間的關聯性
• 撰寫使用來自不同資料來源之欄位的量值
• 針對來自 Power BI 語意模型或 Analysis Services 模型的資料表，建立新的資料行
• 建立使用來自不同資料來源之資料行的視覺效果
• 您可以使用欄位清單從模型中移除資料表，讓模型盡可能簡潔精實 (如果您連接到檢視方塊，則無法從模型移除資料表)
• 當您只想要特定資料表子集時，可以指定要載入的資料表，而不需要載入所有資料表。 請參閱本文件中稍後的載入資料表子集。
• 在模型中建立連線之後，您可以指定是否要新增任何後續要加入語意模型的資料表。

根據語意模型使用複合模型

使用適用於 Power BI 語意模型和 Analysis Services 的 DirectQuery 時，請考慮下列資訊：

• 如果您重新整理資料來源，且發生欄位或資料表名稱相衝突的錯誤，Power BI 會為您解決錯誤。

• 您不能在相同的 Power BI 語意模型或 Analysis Services 來源中編輯、刪除或建立新的關聯性。 如果您有這些來源的編輯存取權，可以改為直接在資料來源中進行變更。

• 您無法變更從 Power BI 語意模型或 Analysis Services 來源載入的資料行資料類型。 如果您需要變更資料類型，請在來源中變更，或使用導出資料行。

• 若要在以另一個語意模型為基礎的複合模型上，於 Power BI 服務中建置報表，必須設定所有認證。

• 連線到 SQL Server 2022 和更新版本的 Analysis Services 伺服器內部部署或 IAAS，需要內部部署資料閘道 (標準模式)。

• 遠端 Power BI 語意模型的所有連線都是使用單一登入。 目前不支援使用服務主體進行驗證。

• RLS 規則將會在其定義所在的來源上套用，但不會套用到模型中的任何其他語意模型。 報表中定義的 RLS 不會套用到遠端來源，而且遠端來源上設定的 RLS 不會套用到其他資料來源。 此外，您無法在從遠端來源載入的資料表上定義 RLS，而本機資料表上定義的 RLS 不會篩選從遠端來源載入的任何資料表。

• 不會從來源匯入 KPI、資料列層級安全性和翻譯。

• 使用日期階層時，您可能會看到一些非預期的行為。 若要解決此問題，請改為使用日期資料行。 將日期階層新增至視覺效果之後，您可以透過按一下欄位名稱中的向下箭號，然後按一下該欄位的名稱，而不是使用 [日期階層]，來切換到日期資料行：

  

  如需使用日期資料行與日期階層的詳細資訊，請參閱在 Power BI Desktop 中套用自動日期或時間。

• 模型鏈結的最大長度為三。 不支援鏈結長度超過三的延伸，而且會導致錯誤。

• 可以在模型上設定 [不鼓勵鏈結] 旗標，以防止建立或延伸鏈結。 如需詳細資訊，請參閱管理已發佈語意模型的 DirectQuery 連線。

• Power BI 語意模型或 Analysis Services 模型的連線不會顯示在 Power Query 中。

使用適用於 Power BI 語意模型和 Analysis Services 的 DirectQuery 時，適用下列限制：

• 目前已停用資料庫和伺服器名稱的參數。
• 不支援在來自遠端來源的資料表上定義 RLS。
• 不支援使用下列任何來源作為 DirectQuery 來源：
  • 2022 版之前的 SQL Server Analysis Services (SSAS) 表格式模型
  • SSAS 多維度模型
  • SAP HANA
  • SAP Business Warehouse
  • 即時語意模型
  • 樣本語意模型
  • Excel Online 重新整理
  • 從服務上的 Excel 或 CSV 檔案匯入資料
  • 使用量指標
  • 儲存在「我的工作區」中的語意模型
• 目前不支援使用 Power BI Embedded 搭配使用 DirectQuery 連接 Analysis Services 模型的語意模型。
• 不支援使用發佈至 Web 功能將報表發佈至 Web。
• 不支援遠端來源上使用未定義查詢結果的計算群組。

• 在具有已指派可共用雲端連線和/或細微存取控制的 Power BI 服務中，若導出資料表與導出資料行所參考的 DirectQuery 資料表來自具有單一登入 (SSO) 驗證的資料來源，則不提供支援。

• 如果您在設定 DirectQuery 連線之後重新命名工作區，則必須更新 Power BI Desktop 中的資料來源，報表才能繼續運作。
• 視資料來源類型而定，只有在某些情況下，才支援自動頁面重新整理 (APR)。 如需詳細資訊，請參閱 Power BI 的自動頁面重新整理。
• 目前不支援接管使用 DirectQuery 連接其他語意模型功能的語意模型。
• 如同使用任何 DirectQuery 資料來源，使用 Excel 連接到 DirectQuery 模式中的模型或語意模型時，將不會顯示 Analysis Services 模型或 Power BI 語意模型中定義的階層。

使用適用於 Power BI 語意模型和 Analysis Services 的 DirectQuery 時，有一些其他考量事項：

• 在跨來源群組關聯性中使用低基數資料行：跨兩個不同的來源群組建立關聯性時，參與關聯性的資料行 (也稱為聯結資料行) 應具有低基數，理想情況下為 50,000 或更少。 此考量適用於非字串索引鍵資料行；若為字串索引鍵資料行，請參閱下列考量。
• 避免在跨來源群組關聯性中使用大型字串索引鍵資料行：建立跨來源群組關聯性時，請避免使用大型字串資料行作為關聯性資料行，特別含有較大基數的資料行。 當您必須使用字串資料行作為關聯性資料行時，請將基數 (C) 乘以字串資料行的平均長度 (A)，以計算篩選的預期字串長度。 請確定預期的字串長度低於 250,000，所以是 A ∗ C < 250,000。

如需更多考量和指引的詳細資訊，請參閱複合模型指引。

租用戶考量

任何使用 DirectQuery 連接 Power BI 語意模型或 Analysis Services 的模型都必須在相同的租用戶中發佈，這在使用 B2B 來賓身分識別存取 Power BI 語意模型或 Analysis Services 模型時特別重要，如下圖所示。 若要尋找用於發佈的租用戶 URL，請參閱可以編輯和管理內容的來賓使用者。

請考慮下圖。 接下來的段落會說明圖表中的編號步驟。

在此圖表中，Ash 會與 Contoso 合作，存取 Fabrikam 所提供的資料。 Ash 使用 Power BI Desktop，與 Fabrikam 租用戶裝載的 Analysis Services 模型建立 DirectQuery 連線。

若要進行驗證，Ash 使用 B2B 來賓使用者身分識別 (圖表中的步驟 1)。

如果報表發佈至 Contoso 的 Power BI 服務 (步驟 2)，則 Contoso 租用戶中發佈的語意模型無法成功驗證 Fabrikam 的 Analysis Services 模型 (步驟 3)。 因此，報表無法運作。

在此案例中，由於使用的 Analysis Services 模型裝載於 Fabrikam 租用戶中，因此報表也必須在 Fabrikam 租用戶中發佈。 在 Fabrikam 租用戶中成功發佈之後 (步驟 4)，語意模型就可以順利存取 Analysis Services 模型 (步驟 5)，且報表會正常運作。

使用物件層級安全性

當複合模型透過 DirectQuery 從 Power BI 語意模型或 Analysis Services 取得資料，且該來源模型受到物件層級安全性保護時，複合模型的取用者可能會注意到發生非預期的結果。 下一節說明這些結果的發生原因。

物件層級安全性 (OLS) 可讓模型建立者隱藏構成模型結構描述的物件 (亦即資料表、資料行、中繼資料等)，不向模型取用者顯示 (例如報表產生器或複合模型建立者)。 在設定物件的 OLS 時，模型建立者會建立角色，然後移除指派給該角色的使用者對該物件的存取權。 從這些使用者的觀點來看，隱藏的物件根本不存在。

OLS 的定義和套用都在來源模型上。 無法針對建置在來源模型上的複合模型定義 OLS。

當複合模型透過 DirectQuery 連線建置在 OLS 保護的 Power BI 語意模型或 Analysis Services 模型上時，則可以將模型結構描述從來源模型完整複製到複合模型。 複製的內容則取決於按照套用的 OLS 規則，允許複合模型建立者在來源模型上所看到的物件。 資料並不會複製到複合模型，而是在必要時，一律透過 DirectQuery 從來源模型中擷取。 換句話說，資料擷取一律會回到套用 OLS 規則的來源模型。

由於複合模型不受 OLS 規則保護，所以複合模型取用者所看到的物件會是複合模型建立者可以在來源模型中看到的物件，而不是他們本身可能有權存取的物件。 這可能導致下列狀況：

• 查看複合模型的使用者可能會看到 OLS 在來源模型中隱藏的物件。
• 相反地，他們可能會在複合模型中「看不到」在來源模型中可以「看到」的物件，這是因為控制來源模型存取的 OLS 規則向複合模型建立者隱藏了該物件。

重點是，儘管在第一個項目符號所述的情況下，複合模型取用者永遠不會看到他們不應該看到的實際資料，因為資料實際上並不在複合模型中。 但由於使用 DirectQuery，取用者可以在必要時，從 OLS 封鎖未獲授權存取的來源語意模型中擷取資料。

考慮到這樣的背景情況，請思考以下案例：

1. Admin_user 使用含有「客戶」資料表和「國家/地區」資料表的 Power BI 語意模型或 Analysis Services 模型，發佈了企業語意模型。 Admin_user 將該語意模型發佈到 Power BI 服務，並設定具有下列作用的 OLS 規則：

   • 財務使用者看不到「客戶」資料表
   • 行銷使用者看不到「國家/地區」資料表

2. Finance_user 發佈了稱為「財務語意模型」的語意模型，以及稱為「財務報表」的報表，該報表透過 DirectQuery 連接到步驟 1 中發佈的企業語意模型。 「財務」報表中的視覺效果使用了「國家/地區」資料表中的一個資料行。

3. Marketing_user 開啟「財務」報表。 系統會顯示使用「國家/地區」資料表的視覺效果，但會傳回錯誤，因為開啟報表時，DirectQuery 會嘗試使用 Marketing_user 的認證從來源模型擷取資料，而根據企業語意模型設定的 OLS 規則，系統會 Marketing_user 不讓他們看到「國家/地區」資料表。

4. Marketing_user 會建立名為「行銷報表」的新報表，使用「財務」語意模型作為其來源。 欄位清單顯示 Finance_user 有權存取的資料表和資料行。 因此，「國家/地區」資料表顯示在欄位清單中，但「客戶」資料表則沒有。 不過，當 Marketing_user 嘗試使用「國家/地區」資料表中的資料行來建立視覺效果時，就會傳回錯誤，因為此時 DirectQuery 會嘗試使用 Marketing_user 的認證從來源模型擷取資料，而 OLS 規則會再次啟動並封鎖存取。 當 Marketing_user 建立新的語意模型和報表並透過 DirectQuery 連線連接到「財務」語意模型時，會發生同樣的情況：他們會在欄位清單中看到「國家/地區」資料表，因為這本就是 Finance_user 可以看到的內容，但是當他們嘗試建立使用該資料表的視覺效果時，就會遭到企業語意模型上的 OLS 規則封鎖。

5. 現在，假設 Admin_user 更新企業語意模型上的 OLS 規則，不讓「財務」使用者看到「國家/地區」資料表。

6. 更新的 OLS 規則只有在重新整理時才會反映在 Finance 語意模型中。 因此，當 Finance_user 重新整理「財務」語意模型時，「國家/地區」資料表將不再顯示在欄位清單中，且「財務」報表中使用「國家/地區」資料表中資料行的視覺效果將會為 Finance_user 傳回錯誤，因為他們現在不允許存取「國家/地區」資料表。

總括來說：

• 複合模型的取用者會看到複合模型建立者在建立該模型時可套用的 OLS 規則結果。 因此，依據複合模型建立新的報表時，欄位清單會顯示複合模型建立者在建立該模型時有權存取的資料表，不論目前使用者在來源模型中有權存取的內容為何。
• 複合模型本身無法定義 OLS 規則。
• 複合模型的取用者永遠不會看到他們不應該看到的實際資料，因為來源模型上的相關 OLS 規則會在 DirectQuery 嘗試使用其認證擷取資料時加以封鎖。
• 如果來源模型更新其 OLS 規則，則這些變更只會在重新整理後影響複合模型。

從 Power BI 語意模型或 Analysis Services 模型載入資料表子集

使用 DirectQuery 連線連接到 Power BI 語意模型或 Analysis Services 模型時，您可以決定要連接的資料表。 您也可以選擇在連接到模型後，自動新增任何可以加入語意模型或模型的資料表。 當您連接到檢視方塊時，您的模型將會包含該模型中的所有資料表，而且會隱藏不在檢視方塊中的任何資料表。 此外，系統會自動新增任何可能加入檢視方塊的資料表。 在 [設定] 功能表中，您可以決定在您第一次設定連線之後，自動連線到已新增至語意模型的資料表。

即時連線不會顯示此對話方塊。

設定重複資料刪除規則

您可以使用先前所示對話方塊中的 [設定] 選項，指定重複資料刪除規則來保留複合模型中唯一的量值和資料表名稱：

在上一個範例中，我們新增了「(行銷)」作為後置詞，當資料表或量值名稱與複合模型中的其他來源衝突時可適用。 您可以：

• 輸入要新增至衝突資料表或量值名稱的文字
• 指定是否要將文字新增至資料表或量值名稱，作為前置詞或後置詞
• 將重複資料刪除規則套用至資料表和/或量值
• 只有在發生名稱衝突或持續套用重複資料刪除規則時，再選擇套用重複資料刪除規則。 預設值是只有在重複資料發生時才會套用規則。 在我們的範例中，行銷來源的任何資料表或量值如果在銷售來源中沒有重複資料，名稱就不會變更。

建立連線並設定重複資料刪除規則之後，您的欄位清單會根據我們範例中設定的重複資料刪除規則，顯示「客戶」和「客戶 (行銷)」：

如果您未指定重複資料刪除規則，或您指定的重複資料刪除規則無法解決名稱衝突，則仍會套用標準重複資料刪除規則。 標準重複資料刪除規則會將數字新增至衝突項目的名稱。 如果「客戶」資料表上發生名稱衝突，其中一個「客戶」資料表會重新命名為「客戶 2」。

考量與限制

複合模型有一些考量和限制：

混合模式連線 - 使用包含線上資料的混合模式連線 (例如 Power BI 語意模型) 和內部部署語意模型 (例如 Excel 活頁簿) 時，您必須建立閘道對應，讓視覺效果能夠正確顯示。

目前，只有連接到 SQL、Oracle 和 Teradata 資料來源的複合模型才支援累加式重新整理。

下列 Live Connect 表格式來源不能與複合模型搭配使用：

• SAP HANA
• SAP Business Warehouse
• 早於 2022 版本的 SQL Server Analysis Services
• 使用計量 (我的工作區)

不支援在複合模型中使用串流語意模型。

使用複合模型時，仍然受限於 DirectQuery 的現有限制。 這其中有許多限制現在會依個別資料表的儲存模式而異。 例如，「匯入」資料表上的導出資料行可以參考不在 DirectQuery 中的其他資料表，但 DirectQuery 資料表上的導出資料行仍僅能參考相同資料表上的資料行。 如果模型內有任何資料表為 DirectQuery，則其他限制會套用至整個模型。 例如，當 QuickInsights 功能中有任何資料表採用 DirectQuery 的儲存模式時，該模型便無法使用該功能。

如果您在複合模型中使用列層級安全性，搭配 DirectQuery 模式中的某些資料表，您必須重新整理模型，才能從 DirectQuery 資料表套用新的更新。 例如，如果 DirectQuery 模式中的使用者資料表在來源有新的使用者記錄，則只會在下一個模型重新整理之後包含新的記錄。 Power BI 服務會快取使用者查詢以改善效能，而且在下次手動或排程重新整理之前，不會從來源重新載入資料。

相關內容

如需複合模型及 DirectQuery 的詳細資訊，請參閱下列文章：

• 在 Power BI Desktop 中套用多對多關聯性
• 管理 Power BI Desktop 中的儲存模式
• Power BI 中的 DirectQuery
• Power BI 資料來源
• Power BI Desktop 中的模型關聯性