作用中與非使用中關聯性指引
本文以您作為使用 Power BI Desktop 的數據模型工具為目標。 它會提供建立作用中或非使用中模型關聯性時機的指引。 根據預設，作用中關聯性會將篩選傳播至其他數據表。 不過，非作用中關聯性只會在DAX運算式啟動 （使用） 關聯性時傳播篩選。
注意
本文未涵蓋模型關聯性的簡介。 如果您不熟悉關聯性、其屬性或設定方式，建議您先閱讀 Power BI Desktop 中的模型關聯性一文。
您也必須瞭解星型架構設計。 如需詳細資訊，請參閱了解星型結構描述及其對 Power BI 的重要性。
作用中關聯性
一般而言，建議您盡可能定義作用中的關聯性。 它們會擴大報表作者和使用Q&A的使用者如何使用模型的範圍和潛力。
請考慮匯入模型範例，其設計目的是分析航空公司準時航班效能（OTP）。 此模型具有 Flight 數據表，這是一個事實類型數據表，每個正式發行前小眾測試版儲存一個數據列。 每個數據列都會記錄航班日期、航班號碼、出發和抵達機場，以及任何延誤時間（以分鐘為單位）。 還有一個 Airport 數據表，這是維度類型數據表，每個機場儲存一個數據列。 每個數據列都會描述機場代碼、機場名稱和國家或地區。
以下是兩個數據表的部分模型圖表。
Flight 和 Airport 數據表之間有兩個模型關聯性。 在 Flight 數據表中，DepartureAirport 和 ArrivalAirport 數據行與 [機場] 資料表的 [機場] 數據行相關。 在星型架構設計中 ，機場 數據表會描述為 角色扮演維度。 在此模型中，這兩個角色是 出發機場 和 抵達機場。
雖然此設計適用於關係型星型架構設計，但不適用於Power BI模型。 這是因為模型關聯性是篩選傳播的路徑，而且這些路徑必須具決定性。 如需確保篩選傳播路徑具決定性的詳細資訊，請參閱 解決關聯性路徑模棱兩可。因此，如此範例所述，其中一個關聯性為使用中，而另一個關聯性為非使用中狀態（以虛線表示）。 具體來說，這是與使用中 之 ArrivalAirport 數據行的關係。 這表示套用至 Airport 資料表的篩選條件會自動傳播至 Flight 數據表的 ArrivalAirport 資料行。
此模型設計會對如何報告數據施加嚴重限制。 具體來說，無法篩選 機場 數據表來自動隔離出發機場的航班詳細數據。 由於報告需求涉及同時依出發和抵達機場進行篩選（或分組），因此需要兩個積極的關係。 將此需求轉譯為Power BI模型設計表示模型必須有兩個機場數據表。
以下是改善的模型設計。
模型現在有兩個機場數據表： 出發機場 和 抵達機場。 這些數據表與 Flight 數據表之間的模型關聯性為使用中。 另請注意，出發機場和抵達機場數據表中的數據行名稱前面會加上 [出發] 或 [抵達] 一字。
改進的模型設計支持產生下列報表設計。
報表頁面會依墨爾本篩選為出發機場，以及依抵達機場的數據表視覺效果群組。
注意
針對匯入模型，額外的數據表會導致模型大小增加，而且重新整理時間更長。 因此，這與匯入模型化數據縮減技術一文中所述的建議相矛盾。 不過，在此範例中，只有作用中關聯性的需求會覆寫這些建議。
此外，維度類型數據表通常包含相對於事實類型數據表數據列計數的低數據列計數。 因此，增加的模型大小和重新整理時間不太可能太大。
重構方法
以下是將模型從單一角色扮演維度類型數據表重構模型的方法，到每個角色有一個數據表的設計。
拿掉任何非作用中的關聯性。
請考慮重新命名角色扮演維度類型數據表，以更清楚地描述其角色。 在此範例中，Airport 數據表與 Flight 數據表的 ArrivalAirport 數據行相關，因此會重新命名為抵達機場。
建立角色扮演數據表的複本，並提供反映其角色的名稱。 如果是 Import 資料表，建議您定義匯出數據表。 如果是 DirectQuery 數據表，您可以複製 Power Query 查詢。
在此範例中 ，出發機場 數據表是使用下列匯出數據表定義所建立。
Departure Airport = 'Arrival Airport'建立作用中關聯性以建立新數據表的關聯性。
請考慮重新命名數據表中的數據行，以便正確反映其角色。 在此範例中，所有數據行前面都會加上 「出發」或「抵達」一詞。 這些名稱預設可確保報表視覺效果會有自我描述和非模棱兩可的標籤。 它也會改善問答體驗，讓使用者可以輕鬆地撰寫問題。
請考慮將描述新增至角色扮演數據表。 （在 欄位 窗格，當報表作者將游標停留在數據表上時，描述會出現在工具提示中。如此一來，您可以將任何其他篩選傳播詳細數據傳達給報表作者。
非作用中關聯性
在特定情況下，非作用中關聯性可以解決特殊的報告需求。
現在讓我們考慮不同的模型和報告需求：
- 銷售模型包含具有兩個 日期數據行的 Sales 數據表： OrderDate 和 ShipDate
- Sales 數據表中的每個數據列都會記錄單一訂單
- 日期篩選幾乎一律會套用至 OrderDate 數據行，該數據行一律會儲存有效的日期
- 只有一個量值需要日期篩選傳播至 ShipDate 數據行，其中包含 BLANK（直到訂單出貨為止）
- 不需要同時篩選（或依） 訂單 和 出貨日期週期
以下是兩個數據表的部分模型圖表。
Sales 和 Date 數據表之間有兩個模型關聯性。 在 Sales 數據表中，OrderDate 和 ShipDate 資料行與 Date 數據表的 Date 數據行有關。 在此模型中，Date 數據表的兩個角色是訂單日期和出貨日期。 這是作用中 OrderDate 數據行的關聯性。
除了一個量值之外，所有六個量值都必須依 OrderDate 數據行進行篩選。 不過，Orders Ship 量值必須依 ShipDate 資料行進行篩選。
以下是 Orders 量值定義。 它只會計算篩選內容中 Sales 數據表的數據列。 套用至 Date 資料表的任何篩選都會傳播至 OrderDate 數據 行。
Orders = COUNTROWS(Sales)
以下是 Orders Shipped 量值定義。 它會使用 USERELATIONSHIP DAX 函式，此函式只會在表達式評估期間啟用特定關聯性的篩選傳播。 在此範例中，會使用 ShipDate 數據行的關聯性。
Orders Shipped =
CALCULATE(
COUNTROWS(Sales)
,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)
此模型設計支持產生下列報表設計。
報告頁面會依 2019 年第 4 季篩選。 依月份的數據表視覺效果群組，並顯示各種銷售統計數據。 Orders 和 Orders Shipped 量值會產生不同的結果。 它們各自使用相同的摘要邏輯（Sales 數據表的計數數據列），但不同的 Date 數據表篩選傳播。
請注意，四分之一交叉分析篩選器包含空白專案。 此交叉分析篩選器項目會顯示為數據表展開的結果。 雖然每個 Sales 數據表數據列都有訂單日期，但有些數據列有空白出貨日期，但這些訂單尚未出貨。 數據表擴充也會考慮非作用中關聯性，因此BLANK可能會因為關聯性多端的BLANK或數據完整性問題而出現。
注意
數據列層級安全性篩選只會透過作用中關聯性傳播。 即使明確將UseRelationship新增至量值定義，數據列層級安全性篩選也不會針對非作用中關聯性傳播。
建議
總而言之，建議您盡可能定義作用中關聯性，特別是針對數據模型定義數據列層級安全性角色時。 它們會擴大報表作者和使用Q&A的使用者如何使用模型的範圍和潛力。 這表示角色扮演維度類型數據表應該在模型中重複。
不過，在特定情況下，您可以定義角色扮演維度類型數據表的一或多個非作用中關聯性。 在下列情況下，您可以考慮此設計：
- 報表視覺效果不需要同時依不同角色進行篩選
- 您可以使用 USERELATIONSHIP DAX 函式來啟用相關模型計算的特定關聯性
相關內容
如需本文的詳細資訊，請參閱下列資源：
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應