在 Power BI 中使用複合模型

Power BI 語意模型可透過使用任何支援的資料 表儲存模式，包含來自一個或多個資料來源的資料表。 當資料表使用不同的儲存模式時，模型是一個複合語意模型。 對於 DirectQuery 資料表儲存模式，當 DirectQuery 資料表使用不同的資料來源時，模型是複合式的。

舉例來說，如果你用 DirectQuery（在 DirectQuery 儲存模式下新增資料表）連接到另一個 Power BI 語意模型，並且本地資料表在匯入模式下，你的模型就會變成複合模型，因為它包含了具有不同儲存模式的資料表。

複合模型的類型

根據語意模型中資料表儲存模式的組合，存在不同類型的複合模型。 每種類型在功能性和工具上都有自己的考量。

在 Power BI Desktop 中建立複合模型

在 Power BI Desktop 中，你可以透過本地匯入或 DirectQuery 資料表建立語意模型。 接著，您可以從另一個儲存模式下的「取得資料」功能區按鈕新增更多資料表，以建立複合模型。

從另一個 Power BI 語意模型加入 DirectQuery 資料表會有幾種不同的建立路徑。

1. 在空白的 Power BI 檔案中，先 連線到 Power BI 語意模型。 即時連線後，您可以選擇對 此模型進行更改。 從色帶或頁腳選擇 「變更此模型 」會將即時連線轉換為 DirectQuery 連線。 DirectQuery 連線會建立新的本機語意模型，其中包含 DirectQuery 儲存模式的資料表。 您可以在匯入或 DirectQuery 儲存模式中新增資料表，以及提供覆寫來源語意模型上某些資料行屬性的選項。

2. 在已有匯入或 DirectQuery 資料表的語意模型中，連接到 Power BI 語意模型後，你選擇的資料表會以 DirectQuery 的形式加入。

使用 Direct Lake 資料表建立的語意模型會在 Power BI Desktop 中即時編輯。 你可以新增更多 Direct Lake 表格。 要新增匯入資料表，請在 Power BI 網頁建模中開啟語意模型。 要新增 DirectQuery 資料表，請使用 XMLA。

你可以在桌面版即時編輯 Direct Lake 並匯入語意模型，但不能新增更多資料表。 你只能從Power BI 網頁建模新增 Direct Lake 表格，並匯入複合模型。

在 Web 模型中建立複合模型

在 Power BI 網頁建模中，你可以用匯入或直接湖表建立語意模型。 你無法新增 DirectQuery 表格。 你可以在另一個儲存模式下新增更多資料表來建立複合模型。

使用複合模型

您可以運用複合模型，在使用 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、Direct Lake 與匯入資料表的語意模型，是一種複合語意模型。

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

複合模型範例

如需「複合模型」的範例，請考慮使用 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 或「匯入」為基礎。 你可以在 屬性 面板中查看並修改儲存模式。 查看儲存模式：

1. 在 「模型」 檢視中，選取表格。
2. 在 屬性 面板中，展開 進階 區塊，然後展開 儲存模式 清單。

你也可以在 資料 窗格中將滑鼠移到每個表格上，看到該表格的儲存模式。

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

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

計算資料表

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

計算出來的表格總是會被匯入，且當你刷新表格時，資料也會自動刷新。 如果導出資料表參考 DirectQuery 資料表，則參考 DirectQuery 資料表的視覺效果一律會顯示基礎來源中的最新值。 或者，參考導出資料表的視覺效果，會顯示導出資料表最近一次重新整理時的值。

安全性隱含意義

複合模型對安全性會有一些影響。 發送到一個資料來源的查詢可以包含從另一個來源檢索的資料值。 在先前的範例中，依 Product Manager 顯示 （Sales Amount） 的視覺效果會將 SQL 查詢傳送至 Sales 關聯式資料庫。 該 SQL 查詢可能包含「產品經理」的名稱及其相關聯「產品」。

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

• 任何能查看追蹤紀錄或稽核日誌的資料庫管理員，即使未取得原始來源資料的權限，也能查看這些資訊。 在這個例子中，管理員需要對 Excel 檔案取得權限。

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

為了確認你有考慮任何安全影響，Power BI Desktop 在建立複合模型時會顯示警告訊息。

此外，如果作者將模型 A 的 Table1 加入複合模型（我們暫且稱為模型 C），使用者在查看模型 C 上建立的報告時，可以查詢模型 A 中任何未受列級安全（RLS）保護的資料表。

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

對於效能的影響

使用 DirectQuery 時，務必考慮效能。 確保後端資源充足，能為使用者提供良好的體驗。 良好的體驗表示視覺效果在五秒內重新整理。 如需更多效能建議，請參閱 Power BI 中的 DirectQuery。

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

• 包含大量字面值的來源查詢：例如，一個視覺化請求特定產品經理的總銷售額，首先需要找出這些產品經理管理的產品。 在視覺效果發送 SQL 查詢包含任何 WHERE 子句中的所有產品識別碼之前，必須先完成此排序。

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

• 多重來源查詢，依值每組查詢一次：當聚合使用 DistinctCount ，並依其他來源的欄位分組，且外部來源無法有效傳遞定義分組的多個字面值時，你需要依值每個群組發送一次 SQL 查詢。

  一個視覺化的視覺化，若產品經理從試算表匯入，從 SQL Server 資料表請求不同 CustomerAccountNumber 的數量，必須在發送到 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 連線，例如連接到一個名為 Inventory 的 SQL Server 資料庫，該來源的項目會被加入為另一個來源群組：

來源群組和關聯性

複合模型有兩種關係類型：

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

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

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

本機和遠端

任何源群組中屬於 DirectQuery 來源群組的項目都是 遠端的，除非你在本地定義該項目作為 DirectQuery 來源的擴充或豐富功能，且它不是遠端來源的一部分，例如測量或計算表。 基於 DirectQuery 來源群組資料表計算出的表格屬於「Import」來源群組，且是 本地的。 「匯入」來源群組中的任何項目都是 本地的。 例如，如果你在一個複合模型中定義以下度量，該模型使用 DirectQuery 連接到 Inventory 來源，該度量是局部性的：

[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 中進行分析。 如果你停用這個開關，就無法用 DirectQuery 連接到 Power BI 語意模型。
• 使用者可以使用即時連線在 Excel 中處理 Power BI 語意模型。 如果你停用這個開關，使用者就無法與 Power BI 語意模型進行即時連線，因此「 變更此模型 」按鈕就無法使用。
• 允許 DirectQuery 連線至 Power BI 語意模型。 若要進一步了解此開關及停用影響，請參閱以下段落。

此外，針對 Premium 容量和 Premium 個人版本，應啟用「XMLA 端點」設定，並將其設為「唯讀」或「讀寫」。

租用戶管理員可以在管理入口網站中啟用或停用 Power BI 語意模型的 DirectQuery 連線。 雖然此設定預設為啟用，但若關閉此設定，將阻止使用者將新的複合模型發佈到 Power BI 語意模型，然後再發佈至服務。

現有使用複合模型的報告仍能在 Power BI 語意模型上運作。 使用者仍可在 Power BI Desktop 中建立複合模型，但無法將其發佈到服務中。 相反地，當你透過選擇 「變更此模型」來建立 DirectQuery 連接到 Power BI 語意模型時，你會看到以下警告訊息：

這樣一來，您仍然可以在本機 Power BI Desktop 環境中探索語意模型，並建立複合模型。 不過，你不能把報告發佈給服務。 當您發布報告與模型時，會看到以下錯誤訊息，並阻止發佈：

與 Power BI 語意模型的即時連線不會受到此開關所影響，也不會與 Analysis Services 建立即時或 DirectQuery 連線。 這些連接無論開關設定如何都能正常運作。 此外，任何在 Power BI 語意模型上使用複合模型的已發表報告，即使開關在發布後關閉，仍能正常運作。

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

要在 Power BI 語意模型或分析服務模型上建立複合模型，您的報告需要一個本地模型。 您可以從即時連線開始，然後新增或升級至本機模型，或開始使用 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 工作表合併。 接著你用 Sales and Budget Power BI 語意模型並加你自己的修改，建立並發布一個複合語意模型與報告，稱為 Sales and Budget Europe。 這個語義模型是鏈中的第三個。

1. 第一個鏈結是 Sales Analysis Services 模型。
2. 第二個鏈結是 Sales and Budget Power BI 複合語意模型。
3. 第三個鏈結是您的 Sales and Budget Europe Power BI 複合語意模型。

下圖將此鏈結程序視覺化。

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

權限和授權

使用複合模型存取報告的使用者需要對 鏈中所有語意模型及模型擁有適當的權限。

複合模型的擁有者需要對用作來源的語意模型取得 建置 權限，以便其他使用者能代表擁有者存取這些模型。 因此，在 Power BI Desktop 建立複合模型連線或在 Power BI 撰寫 報告時， 都需要對用作來源的語意模型建立建構權限。

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

以下範例說明所需的權限：

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

  • 資料來源 A1：語意模型 B。
    擁有者 A 必須在語意模型 B 上擁有建置權限，使用者才能查看使用複合模型 A 的報告。

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

  • 資料來源 C1：語意模型 D
    Owner 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 或更大容量，使用者可透過 免費授權存取。

安全性警告

當你在 Power BI 語意模型中使用複合模型和分析服務模型 功能時，你會看到一個安全警告對話框，如下圖所示。

資料可能會從一個資料來源推送到另一個資料來源。 此安全警告適用於將 DirectQuery 與匯入來源合併於資料模型中的情況。 關於此行為的更多資訊，請參閱 Power BI Desktop 中使用複合模型。

支援的案例

你可以利用 Power BI 語意模型或分析服務模型的資料來建立複合模型，以服務以下情境：

• 從各種來源連接資料：匯入（例如檔案）、Power BI 語意模型、Analysis Services 模型
• 建立不同資料來源之間的關係
• 撰寫使用來自不同資料來源欄位的度量
• 從 Power BI 語意模型或分析服務模型建立新的欄位給資料表
• 建立使用不同資料來源欄位的視覺化
• 用欄位列表從模型中移除一個表格，以便讓模型保持精簡（如果您連接到透視圖，則無法從模型中移除表格）。
• 指定要載入哪些資料表，而不是只想要特定子集時必須載入所有資料表。 請參閱本文件中稍後的載入資料表子集。
• 指定是否在您的模型中建立連結後，再將任何新增的表格加入到語意模型中。

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

使用適用於 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 Query 不會顯示與 Power BI 語意模型或分析服務模型的連結。

使用適用於 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 與包含外部 Analysis Services 模型 （Azure Analysis Services/SQL Server Analysis Services） 的 DirectQuery 連線的語意模型搭配使用。
• 不支援使用「發佈到網站」功能將報告發佈到網路。
• 不支援遠端來源上使用未定義查詢結果的計算群組。
• 在具有已指派可共用雲端連線和/或細微存取控制的 Power BI 服務中，若導出資料表與導出資料行所參考的 DirectQuery 資料表來自具有單一登入 (SSO) 驗證的資料來源，則不提供支援。
• 如果你在設定 DirectQuery 連線後重新命名工作區，你需要在 Power BI Desktop 更新資料來源，報告才能繼續運作。
• 視資料來源類型而定，只有在某些情況下，才支援自動頁面重新整理 (APR)。 如需詳細資訊，請參閱 Power BI 的自動頁面重新整理。
• 目前不支援接管使用 DirectQuery to other 語意模型 特性的語意模型。
• 如同任何 DirectQuery 資料來源，Analysis Services 模型或 Power BI 語意模型中定義的階層結構，在使用 Excel 以 DirectQuery 模式連接模型或語意模型時不會顯示。

在使用 Power BI 語意模型與分析服務的 DirectQuery 時，請參考以下指引：

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

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

租用戶考量

你必須在同一租戶中，將任何帶有 DirectQuery 連接的模型發佈到 Power BI 語義模型或 Analysis Services。 當使用 B2B 訪客身份存取 Power BI 語意模型或分析服務模型時，此要求尤為重要，如下圖所示。

請考慮下圖。 圖中編號的步驟將在以下段落中說明。

在圖中，Ash 與 Contoso 合作，並存取 Fabrikam 提供的資料。 使用 Power BI Desktop，Ash 建立一個 DirectQuery 連線到 Fabrikam 所主機的分析服務模型。

為了驗證，Ash 使用一個 B2B 訪客用戶身份（圖中步驟 1）。

如果 Ash 將報告發佈到 Contoso 的 Power BI 服務（步驟 2），則 Contoso 租戶中發佈的語意模型無法成功與 Fabrikam 的分析服務模型進行驗證（步驟 3）。 因此，報表無法運作。

在這種情況下，由於 Fabrikam 承載分析服務模型，你也必須將報告發佈在 Fabrikam 的租戶中。 在 Fabrikam 租用戶中成功發佈之後 (步驟 4)，語意模型就可以順利存取 Analysis Services 模型 (步驟 5)，且報表會正常運作。

使用物件層級安全性

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

物件層級安全性（OLS）使模型作者能夠隱藏構成模型結構的物件（例如資料表、欄位、元資料等），不被模型使用者（例如報表建構器或複合模型作者）發現。 在設定物件的 OLS 時，模型建立者會建立角色，然後移除指派給該角色的使用者對該物件的存取權。 從這些使用者的觀點來看，隱藏的物件根本不存在。

OLS 的定義和套用都在來源模型上。 你無法為建立在來源模型上的複合模型定義它。

當你透過 DirectQuery 連線在 OLS 保護的 Power BI 語意模型或分析服務模型上建構複合模型時，你會將來源模型的模型結構複製到複合模型中。 你複製什麼取決於根據 OLS 規則，你在原始模型中被允許看到什麼。 你不會把資料複製到複合模型——需要時你總是透過 DirectQuery 從來源模型取回資料。 換句話說，資料擷取一律會回到套用 OLS 規則的來源模型。

由於複合模型不受 OLS 規則保護，合成模型的使用者所看見的物件是你在來源模型中可見的，而不是他們自己可能有權限存取的物件。 這種情況可能導致以下結果：

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

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

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

1. Admin_user 會發布一個企業語意模型，使用 Power BI 語意模型或包含客戶資料表與區域資料表的分析服務模型。 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 語意模型或分析服務模型時，你可以選擇要連接哪些資料表。 您也可以選擇在連接到模型後，自動新增任何可以加入語意模型或模型的資料表。 當您連接到檢視方塊時，您的模型將會包含該模型中的所有資料表，而且會隱藏不在檢視方塊中的任何資料表。 此外，系統會自動新增任何可能加入檢視方塊的資料表。 在 [設定] 功能表中，您可以決定在您第一次設定連線之後，自動連線到已新增至語意模型的資料表。

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

設定重複資料刪除規則

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

在前一個例子中，我們為任何與綜合模型中其他來源相衝突的表格或指標名稱加上「（行銷）」作為後綴。 您可以：

• 輸入文字，以附加到有衝突的表格或度量的名稱上。
• 請指定你想將文字加到表格或度量名稱中，作為前綴還是後綴。
• 將去重規則套用於表格、度量或兩者。
• 只有在發生名稱衝突或持續套用重複資料刪除規則時，再選擇套用重複資料刪除規則。 預設值是只有在重複資料發生時才會套用規則。 以我們的例子來說，任何來自行銷來源且銷售來源沒有重複的表格或指標，都不會被更改名稱。

當你建立連結並設定重複刪除規則後，欄位清單會依照我們範例中設定的重複刪除規則，同時顯示「客戶」和「客戶（行銷）」兩個字樣：

如果你沒有指定重複刪除規則，或你指定的重複刪除規則無法解決名稱衝突，標準的重複刪除規則仍然適用。 標準重複資料刪除規則會將數字新增至衝突項目的名稱。 如果「Customer」資料表名稱衝突，其中一個「Customer」資料表會被重新命名為「Customer 2」。

XMLA 修改和複合模型

當你使用 XMLA 更改語意模型時，更新變更物件的 ChangedProperties 和 PBI_RemovedChildren 集合，以包含任何修改或移除的屬性。 如果你不更新這些集合，下一次架構與資料來源同步時，Power BI 建模工具可能會覆蓋你的變更。

欲了解更多關於語意模型物件血緣標籤的資訊，請參閱 Power BI 語意模型的血緣標籤。

考量與限制

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

混合模式連線 - 當你使用包含線上資料（如 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 模式下的 Users 資料表在來源有新的使用者紀錄，這些新紀錄僅在下一次模型更新後才會被納入。 Power BI 服務會快取使用者查詢以改善效能，而且在下次手動或排程重新整理之前，不會從來源重新載入資料。

相關內容

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

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