共用方式為

活躍與非活躍關係指導

  • 發行項

本文針對使用 Power BI Desktop 的數據建模師。 它會提供指導，說明何時建立啟用或停用的模型關聯性。 根據預設，作用中關聯性會將篩選傳播至其他數據表。 不過，非作用中的關聯只有在DAX運算式啟動（使用）該關聯時，才會傳遞篩選。

注意

本文未涵蓋模型關聯性的簡介。 如果您不熟悉關聯性、其屬性或如何設定關聯性，建議您先閱讀 Power BI Desktop 中的 模型關聯性 一文。

您也必須瞭解星型架構設計。 如需詳細資訊，請參閱 瞭解星型架構和Power BI的重要性。

活躍關係

一般而言，建議您盡可能定義活躍的關係。 他們拓展了報表作者和使用 Q&A 的使用者如何使用你的模型的範圍和潛力。

考慮一個名為 的匯入模型，其設計目的是分析航空公司航班的準時表現（OTP）。 此模型具有 Flight 數據表，這是 事實數據表，每個航班會儲存一行。 每個數據列都會記錄航班日期、航班號碼、出發和抵達機場，以及任何延誤時間（以分鐘為單位）。 另外還有一個 Airport 數據表，這是一個 維度數據表，每個機場會儲存一個數據列。 每個數據列都會描述機場代碼、機場名稱和國家或地區。

以下是兩個數據表的部分模型圖表。

顯示包含兩個數據表的模型圖表：航班和機場。下列段落將說明關聯性設計。

Flight 和 Airport 數據表之間有兩個模型關聯性。 在 Flight 數據表中，DepartureAirport 和 ArrivalAirport 數據行與 Airport 數據表的 Airport 數據行有關。 在星型架構設計中，Airport 資料表會描述為 角色扮演維度。 在此模型中，這兩個角色是 出發機場 和 抵達機場。

雖然此設計適用於關係型星型架構設計，但不適用於Power BI模型。 這是因為模型關聯性是篩選傳播的路徑，而且這些路徑必須具決定性。 如需確保篩選傳播路徑具決定性的詳細資訊，請參閱 解析關聯性路徑模棱兩可。因此，如此範例所示，其中一個關聯性為使用中，而另一個關聯性為非使用中狀態（以虛線表示）。 具體來說，這是與作用中 ArrivalAirport 數據行的關聯性，這表示套用至 Airport 數據表的篩選會自動傳播至 Flight 數據表的 ArrivalAirport 數據行。

此模型設計會對如何報告數據施加嚴重限制。 具體來說，您無法篩選 Airport 數據表，以自動隔離出發機場的航班詳細數據。 由於報告需要依出發和抵達機場篩選（或群組），同時，則需要兩個作用中的關聯性。 將此需求轉譯為Power BI模型設計表示模型必須有兩個機場數據表。

以下是改善的模型設計。

圖表顯示包含四個數據表的模型：日期、航班、出發機場和抵達機場。

此模型現在有兩個機場數據表：Departure Airport 和 Arrival Airport。 這些數據表與 Flight 數據表之間的每個模型關聯性都處於作用中狀態。 另請注意，Departure Airport 和 Arrival Airport 數據表中的數據行名稱前面會加上 Departure 或 Arrival一字。

改進的模型設計支持產生下列報表設計。

圖表顯示報告頁面中有兩個切片器和一個表格視覺效果。切片器是月份和出發機場。

報告頁面會將 墨爾本 篩選為出發機場，並且按抵達機場對數據表進行分組。

注意

針對匯入模型，新增另一個維度數據表會導致模型大小增加，而且重新整理時間較長。 因此，它與匯入模型化 一文 數據縮減技術中所述的建議相矛盾。 不過，在此範例中，僅有保持作用中關聯性的需求會取代這些建議。

此外，維度表通常儲存的行數會比事實表的行數少。 因此，模型大小和更新頻率的增加不太可能過於龐大。

重構方法

以下是一種方法，可將模型從單一角色扮演維度表重構為每個角色一個數據表的設計。

  1. 移除任何不活動的關係。

  2. 請考慮重新命名角色扮演維度數據表，以更清楚地描述其角色。 在本文中的範例中，Airport 數據表與 Flight 數據表的 ArrivalAirport 數據行相關，因此會重新命名為 Arrival Airport。

  3. 建立角色扮演表格的複本，並提供能反映其角色的名稱。 如果是匯入數據表，建議您建立計算表格。 如果是 DirectQuery 數據表，您可以複製 Power Query 查詢。

    在此範例中，Departure Airport 數據表是使用下列計算數據表定義所建立。

    Departure Airport = 'Arrival Airport'

  4. 建立啟用關聯以關聯新數據表。

  5. 請考慮重新命名數據表中的數據行，以便正確反映其角色。 在本文中的範例中，所有數據行前面都會加上 出發 或 抵達一詞。 這些名稱預設確保報表的視覺化結果會有自我描述且非模棱兩可的標籤。 它也會改善 Q&A 體驗，讓使用者可以輕鬆地撰寫精確的問題。

  6. 請考慮將描述新增至角色扮演數據表。 （在 [數據] 窗格中，當報表作者將游標暫留在數據表上方時，工具提示中會出現描述。如此一來，您可以將其他篩選條件傳播的詳細信息傳達給報表作者。

非活躍關係

在特定情況下，非活躍的關係可以滿足特定的報告需求。

請考慮不同的模型和報告需求：

  • 銷售模型包含具有兩個日期資料列的 Sales 資料表：OrderDate 和 ShipDate。
  • Sales 數據表中的每個數據列都會記錄單一順序。
  • 日期篩選幾乎一律會套用至 OrderDate 數據行，該數據行一律會儲存有效的日期。
  • 只有一個量值需要日期篩選傳播至 ShipDate 數據行，此數據行可以包含BLANK（直到訂單出貨為止）。
  • 不需要同時篩選（或群組）訂單 和 出貨日期期間。

以下是兩個數據表的部分模型圖表。

顯示包含兩個數據表的模型圖表：Sales 和 Date。Sales 數據表包含六個量值。

Sales 和 Date 數據表之間有兩個模型關聯性。 在 Sales 數據表中，OrderDate 和 ShipDate 數據行與 Date 數據表的 Date 數據行有關。 在此模型中，Date 資料表的兩個角色是 訂單日期 和 出貨日期。 與 OrderDate 數據行的關聯性正在作用中。

除了一個量值之外，所有六個量值都必須依 OrderDate 數據行進行篩選。 不過，Orders Shipped 指標必須依 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 而出現（或因為數據完整性問題）。

註記

列層級安全性（RLS）篩選只會透過有效關聯傳播。 即使量值定義使用 USERELATIONSHIP DAX 函式時，RLS 篩選永遠不會傳播非作用中關聯性。

建議

建議您儘可能定義作用中關聯性，特別是針對數據模型定義 RLS 角色時。 它們擴展了報表作者和使用 Q&A 的使用者如何使用模型的範圍和潛力。 這表示角色扮演維度數據表應該在模型中重複。

不過，在特定情況下，您可以為角色扮演維度表定義一個或多個非活躍關係。 您可以在下列情況下考慮此方法：

  • 報表視覺效果不需要同時依不同角色進行篩選。
  • 您可以使用 USERELATIONSHIP DAX 函式來啟用相關模型計算的特定關聯性。

相關內容

如需本文的詳細資訊，請參閱下列資源：