Power BI Desktop 中的模型關聯性

本文的目標是使用 Power BI Desktop 的匯入數據模型工具。 這是提供直覺、準確且最佳模型的重要模型設計主題。

如需最佳模型設計的更深入討論,包括數據表角色和關聯性,請參閱 瞭解星型架構和 Power BI 的重要性。

關聯性目的

模型關聯性會將一個模型資料表的資料行上所套用的篩選條件傳播至不同的模型資料表。 只要有要遵循的關聯性路徑,就會傳播篩選,這包含傳播到多個資料表。

關聯性路徑具有確定性,表示一律會以相同的方式傳播篩選,而且不會隨機變化。 不過,關聯性可以予以停用,或具有可使用特定 DAX 函數的模型計算所修改的篩選內容。 如需詳細資訊,請參閱 本文稍後的相關 DAX 函 式主題。

重要

模型關聯性不會強制執行數據完整性。 如需詳細資訊,請參閱本文稍後的 關聯性評估 主題,其中說明當數據發生數據完整性問題時,模型關聯性的行為。

讓我們透過下列動畫範例來看看關聯性如何傳播篩選。

關聯性篩選傳播的動畫圖表。

在此範例中,此模型包含四個資料表:CategoryProductYearSalesCategory 資料表與 Product 資料表相關,而 Product 資料表與 Sales 資料表相關。 Year 資料表也與 Sales 資料表相關。 所有關聯性都是一對多關係(本文稍後會說明的詳細數據)。

一個可能是由 Power BI 卡片視覺效果所產生的查詢,要求針對單一類別 Cat-A 和單一年份 CY2018 銷售訂單的總銷售量進行查詢。 這就是您可以看到 CategoryYear 資料表上所套用篩選的原因。 Category 資料表上的篩選會傳播至 Product 資料表,以隔離指派給類別 Cat-A 的兩個產品。 然後 Product 資料表篩選會傳播至 Sales 資料表,只隔離這些產品的兩個銷售資料列。 這兩個銷售資料列代表指派給類別 Cat-A 的產品銷售。 其合併數量為 14 個單位。 同時,會傳播 Year 資料表篩選以進一步篩選 Sales 資料表,只造成一個銷售資料列,而此銷售資料列適用於指派給類別 Cat-A 的產品,而且之前是以年 CY2018 進行排序。 查詢所傳回的數量值為 11 個單位。 請注意,將多個篩選套用至一個資料表時 (例如本範例中的 Sales 資料表),一律為 AND 作業,而這需要所有條件都必須為 True。

套用星型結構描述設計準則

建議您套用星型結構描述設計準則,以產生包含維度和事實資料表的模型。 通常設定 Power BI 來強制執行篩選維度數據表的規則,讓模型關聯性有效率地將這些篩選傳播至事實數據表。

下圖是 Adventure Works 銷售分析資料模型的模型圖表。 這會顯示星型結構描述設計,其中包含名為 Sales 的單一事實資料表。 其他四個資料表是支援依日期、狀態、區域和產品分析銷售量值的維度資料表。 請注意連線所有資料表的模型關聯性。 這些關聯性會將篩選 (直接或間接) 傳播至 Sales 資料表。

Power BI Desktop 模型圖表的螢幕快照,其中包含上一段所述的數據表和關聯性。

已中斷連線的數據表

模型資料表與另一個模型資料表無關,並不常見。 有效模型設計中的這類數據表會描述為 已中斷連線的數據表。 已中斷連線的資料表不是要將篩選傳播至其他模型資料表。 相反地,其接受「使用者輸入」(或許是透過交叉分析篩選器視覺效果),讓模型計算能夠以有意義的方式使用輸入值。 例如,請考慮以貨幣匯率值範圍載入的已中斷連線數據表。 只要所套用的篩選條件是依據單一匯率值來進行篩選,量值運算式就可使用該值來轉換銷售值。

Power BI Desktop what-if 參數是可建立已中斷連線資料表的功能。 如需詳細資訊,請參閱在 Power BI Desktop 中建立及使用模擬參數來視覺化變數 (部分機器翻譯)。

關聯性屬性

模型關聯性會將資料表中的一個資料行與不同資料表中的另一個資料行產生關聯。 (有一個特製化案例,其中此需求不成立,且僅適用於 DirectQuery 模型中的多數據行關聯性。如需詳細資訊,請參閱 COMBINEVALUES DAX 函式一文。

注意

您無法將資料列與相同資料表中的不同 資料行產生關聯。 此概念有時會與定義數據表自我參考的關係資料庫外鍵條件約束的能力混淆。 您可以將此關聯式資料庫概念用來儲存父子式關聯性 (例如,每個員工記錄會與某個「主管」員工相關聯)。 不過,您無法使用模型關聯性,根據這種類型的關聯性產生模型階層。 若要建立父子式階層,請參閱父子式函式

數據行的數據類型

關聯性之 「from」 和 「to」 資料行的數據類型應該相同。 使用 DateTime 資料行上定義的關聯性可能無法如預期般運作。 儲存 Power BI 資料的引擎,只會使用 DateTime 資料類型; 日期、時間和日期/時間/時區數據類型是 Power BI 格式建構,其實作於最上層。 任何模型相依物件仍會顯示為 引擎中的 DateTime (例如關聯性、群組等等)。 因此,如果使用者從這類數據行的 [模型化] 索引標籤中選取 [日期],它們仍然不會註冊為相同的日期,因為引擎仍會考慮數據的時間部分。 深入瞭解如何處理日期/時間類型。 若要更正行為,數據行數據類型應該在 Power Query 編輯器更新,以從匯入的數據中移除 Time 部分,因此當引擎處理數據時,值會顯示相同。

基數

每個模型關聯性都是由基數類型所定義。 有四個基數類型選項,代表「from」和「to」相關資料行的資料特性。 「一」的那端表示資料行包含唯一值;「多」的那端則表示資料行可以包含重複的值。

注意

如果資料重新整理作業嘗試將重複的值載入「一」端資料行,整個資料重新整理將會失敗。

以下項目符號清單說明這四個選項與其速記標記法:

  • 一對多 (1:*)
  • 多對一 (*:1)
  • 一對一 (1:1)
  • 多對多(*:*)

在 Power BI Desktop 中建立關聯性時,設計工具會自動偵測並設定基數類型。 Power BI Desktop 會查詢模型以得知哪些資料行包含唯一值。 針對匯入模型,它會使用內部記憶體統計數據;針對 DirectQuery 模型,它會將分析查詢傳送至數據源。 不過,有時候 Power BI Desktop 可能會出錯。 出錯原因可能是資料表尚未載入資料,或是您認為包含重複值的資料行目前包含唯一值。 不論是哪一種情況,只要任何「一」端資料行包含唯一值 (或資料表尚未載入資料列),您就可以更新基數類型。

一對多 (和多對一) 基數

一對多多對一基數選項基本上相同,而且也是最常見的基數類型。

設定一對多或多對一關聯性時,您會選擇符合您建立資料行關聯性順序的關聯性。 請考慮如何使用每個資料表中找到的 ProductID 資料行,設定從產品資料表到銷售資料表的關聯性。 基數類型會是一對多,因為 Product 數據表中的 ProductID 數據行包含唯一值。 如果您以相反方向關聯資料表,Sales to Product,則基數會是多對一。

一對一基數

一對一關聯性表示兩個資料行都包含唯一的值。 此基數類型並不常見,而且可能會因為儲存備援資料而代表次佳的模型設計。

如需使用此基數類型的詳細資訊,請參閱一對一關聯性指引

多對多基數

多對多關聯性表示兩個資料行都可以包含重複的值。 這個基數類型不常使用。 設計複雜模型需求時,通常很有用處。 您可以使用該類型來建立多對多事實的關聯,或與更精細的事實建立關聯。 例如,當銷售目標事實儲存在產品類別層級,而產品維度資料表則儲存在產品層級時。

如需使用此基數類型的指引,請參閱多對多關聯性指引

注意

針對 2024 年 1 月和更新版本 Power BI 報表伺服器 開發的模型,支援多對多基數類型。

提示

在 Power BI Desktop 模型檢視中,您可以藉由查看關聯線任一端的指標 (1 或 *) 來解讀關聯性的基數類型。 若要判斷哪些數據行相關,您必須選取或將游標暫留在關聯性行上方,以醒目提示數據行。

模型圖表中兩個數據表的螢幕快照,其中已醒目提示基數指標。

交叉篩選方向

每個模型關聯性皆透過交叉篩選方向定義。 您的設定會決定篩選將傳播的方向。 可能的交叉篩選選項取決於基數類型。

基數類型 交叉篩選選項
一對多(或多對一) Single
兩者
一對一 兩者
多對多 單一 (Table1 至 Table2)
單一 (Table2 至 Table1)
兩者

一交叉篩選方向表示「單向」,而 兩者 都表示「雙向」。 雙向篩選的關聯性通常描述為 雙向

針對一對多關聯性,交叉篩選方向一律來自「一」的那端,並可選擇性地來自「多」的那端 (雙向)。 針對一對一關聯性,交叉篩選方向一律來自兩個資料表。 最後,針對多對多關聯性,交叉篩選方向可以來自其中一個資料表,或來自兩個資料表。 請注意,當基數類型包含「一」端時,篩選一律會從該端傳播。

當交叉篩選方向設定為 [兩者] 時,另一個屬性就會變成可用。 當 Power BI 強制執行資料列層級安全性 (RLS) 規則時,便可套用雙向篩選。 如需 RLS 的詳細資訊,請參閱 Power BI Desktop 的數據列層級安全性 (RLS)。

您可以使用模型計算來修改關聯性交叉篩選方向,包括停用篩選傳播。 使用 CROSSFILTER DAX 函式來達成此目的

請記住,雙向關聯性可能會對效能造成負面影響。 此外,嘗試設定雙向關聯性可能導致模棱兩可的篩選準則傳播路徑。 在此情況下,Power BI Desktop 可能無法認可關聯性變更,並會發出錯誤訊息來警示您。 不過,有時 Power BI Desktop 可能會允許您定義資料表之間的模棱兩可關聯性路徑。 本文稍後將說明解決關聯性路徑模棱兩可。

我們建議僅視需要使用雙向篩選。 如需詳細資訊,請參閱雙向關聯性指引

提示

在 Power BI Desktop 模型檢視中,您可以藉由沿著關聯線指出箭頭來解譯關聯性的交叉篩選方向。 單箭頭代表箭頭方向的單向篩選;雙箭頭代表雙向關聯性。

模型圖表中兩個資料表的螢幕擷取畫面,其中醒目提示交叉篩選箭頭。

設為使用中的關聯性

兩個模型資料表之間只能有一個作用中的篩選傳播路徑。 不過,雖然您必須將這些關聯性設定為 使用中,但可能會引入其他關聯性路徑。 非作用中關聯性只能在模型計算評估期間變成作用中。 使用 USERELATIONSHIP DAX 函式來達成此目的

一般而言,建議您盡可能定義作用中的關聯性。 這些關聯性會擴大報表作者使用您模型的範圍和可能性。 只使用作用中的關聯性表示角色扮演維度資料表應於模型中重複使用。

不過,在特定情況下,您可以為角色扮演維度資料表定義一或多個非作用中的關聯性。 在下列情況下,您可以考慮此設計:

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

如需詳細資訊,請參閱作用中與非使用中關聯性指引

提示

在 Power BI Desktop 模型檢視中,您可以解譯關聯性的作用中與非使用中狀態。 作用中關聯性是以實線表示;非作用中關聯性則是以虛線表示。

模型圖表中兩個數據表和兩個關聯性的螢幕快照;一條實線用於使用中,一條虛線用於非使用中

假設參考完整性

採用參考完整性屬性僅適用於屬於相同來源群組的兩個 DirectQuery 儲存模式資料表之間的一對多和一對一關聯性。 只有當「多」端數據行不包含 NUL 時,您才能啟用這個屬性。

啟用時,傳送至資料來源的原生查詢會使用 INNER JOIN 而不是 OUTER JOIN,將兩個資料表聯結在一起。 一般而言,啟用這個屬性可改善查詢效能,雖然這取決於資料來源的特定內容。

當兩個數據表之間存在資料庫外鍵條件約束時,請一律啟用這個屬性。 即使外部索引鍵條件約束不存在,只要您確定資料的完整性存在,就可以考慮啟用該屬性。

重要

如果資料完整性遭到入侵,內部聯結將會消除資料表之間不相符的資料列。 例如,假設有 ProductID 數據行值不存在於相關 Product 數據表中的模型 Sales數據表。 從產品資料表到銷售資料表的篩選傳播將會排除未知產品的銷售資料列。 這會導致低估銷售結果。

如需詳細資訊,請參閱 Power BI Desktop 中的採用參考完整性設定

相關的 DAX 函式

有數個與模型關聯性相關的 DAX 函式。 每個函式會在下列點符清單中簡短描述:

  • 相關:從關聯性的「一」端擷取值。 當涉及數據列內容中評估之不同數據表的計算時,它很有用。
  • RELATEDTABLE:從關聯性的「多」端擷取數據列數據表。
  • USERELATIONSHIP:允許計算使用非使用中關聯性。 (從技術上來說,此函式會修改特定非使用中模型關聯性的權數,以協助影響其使用方式。當您的模型包含角色扮演維度數據表,並選擇從此數據表建立非作用中關聯性時,會很有用。 您也可以使用此函式來解決 篩選路徑中的模棱兩可。
  • CROSSFILTER:修改關聯性交叉篩選方向(一或兩者),或停用篩選傳播(無)。 當您需要在評估特定計算期間變更或忽略模型關聯性時,它很有用。
  • COMBINEVALUES:將兩個或多個文字字串聯結成一個文字字串。 此函式用途在於資料表屬於相同來源群組時,支援 DirectQuery 模型中的多資料行關聯性。
  • TREATAS:將數據表運算式的結果套用為來自不相關數據表的數據行篩選。 當您想要在特定計算評估期間建立虛擬關聯性時,在進階案例中很有説明。
  • 父函式和子函式:可用來產生導出數據行以自然化父子式階層的相關函式系列。 然後,您可以使用這些資料行建立固定層級階層。

關聯性評估

從評估的觀點來看,模型關聯性會分類為 一般有限。 這不是可設定的關聯性屬性。 它實際上是從基數類型和兩個相關數據表的數據源推斷而來。 請務必瞭解評估類型,因為如果資料完整性遭到入侵,可能會造成效能影響或後果。 本主題將說明這些含意和完整性後果。

首先,需要借助一些模型化理論才能充分瞭解關聯性評估。

匯入或 DirectQuery 模型會從 Vertipaq 快取或源資料庫,從其所有數據來源。 在這兩個實例中,Power BI 都能夠判斷關聯性的「一」端存在。

不過,複合模型可以組成使用不同儲存模式的數據表(匯入、DirectQuery 或雙重),或多個 DirectQuery 來源。 每個來源,包括匯入數據的 Vertipaq 快取,都會被視為 來源群組。 模型關聯性接著可以分類為 來源群組 內部或 跨來源群組。 來源群組內部關聯性會關聯來源群組內的兩個數據表,而跨來源群組關聯性則與兩個來源群組之間的數據表相關聯。 請注意,匯入或 DirectQuery 模型中的關聯性一律在來源群組中。

以下是複合模型的範例。

由兩個來源群組組成的複合模型圖表。

在此範例中,複合模型包含兩個來源群組:Vertipaq 來源群組和 DirectQuery 來源群組。 Vertipaq 來源群組包含三個數據表,而 DirectQuery 來源群組則包含兩個數據表。 有一個跨來源群組關聯性存在,可讓 Vertipaq 來源群組中的資料表與 DirectQuery 來源群組中的資料表產生關聯。

一般關聯性

當查詢引擎可以判斷關聯性的「一端」時,模型關聯性是 一般的 。 其可確認「一」端資料行包含唯一值。 所有一對多「來源群組內」關聯性都是一般關聯性。

在下列範例中,有兩個一般關聯性,兩者都標示為 R。關聯性包括 Vertipaq 來源群組中包含的一對多關聯性,以及 DirectQuery 來源內含的一對多關聯性。

複合模型的圖表,由兩個來源群組組成,並標示了一般關聯性。

針對匯入模型,其中所有數據都儲存在 Vertipaq 快取中,Power BI 會在數據重新整理時為每個一般關聯性建立數據結構。 資料結構是由所有資料行對資料行值的索引對應所組成,其用途是在查詢時間加速聯結資料表。

在查詢時,一般關聯性允許 數據表展開 發生。 資料表擴充會導致建立虛擬資料表,方法是包含基底資料表的原生資料行,然後展開至相關的資料表。 針對匯入數據表,數據表擴充會在查詢引擎中完成;如果是 DirectQuery 數據表,則會在傳送至源資料庫的原生查詢中完成(只要 未啟用假設引用完整性 屬性)。 然後,查詢引擎會根據展開資料表資料行中的值套用篩選準則和群組。

注意

即使計算未使用關聯性,也會展開非作用中的關聯性。 雙向關聯性不會影響資料表擴充。

若是一對多關聯性,資料表展開會使用 LEFT OUTER JOIN 語義,從「多」的那端執行到「一」的那端。 當「多」端到「一」端的相符值不存在時,會將空白的虛擬資料列新增至「一」側邊資料表。 此行為僅適用於一般關聯性 (部分機器翻譯),不適用於有限的關聯性 (部分機器翻譯)。

資料表展開也會發生在一對一的「來源群組內」關聯性,但須使用 FULL OUTER JOIN 語義。 聯結類型可確保在必要時,會在任一端新增空白的虛擬資料列。

空白虛擬數據列實際上是 未知的成員。 未知的成員代表參考完整性違規,完整性中「多」端值沒有對應的「一」端值。 在理想情況下,這些空白不應該存在。 可以透過清理或修復來源資料的方式排除這些空白。

以下是數據表擴充如何與動畫範例搭配運作。

數據表展開的動畫圖表。

在此範例中,此模型包含三個資料表:[類別]、[產品] 和 [銷售]Category 數據表與 Product 數據表具有一對多關聯性,而 Product 數據表則與 Sales 數據表有一對多關聯性。 [類別] 資料表包含兩個資料列、[產品] 資料表包含三個資料列,而 [銷售] 資料表則包含五個資料列。 所有關聯性的兩端都有相符的值,這表示沒有引用完整性違規。 系統會顯示查詢時間展開的資料表。 資料表是由這三個資料表中的資料行所組成。 這實際上是三個資料表中所含資料的反正規化檢視方塊。 新的資料列會新增至 [銷售] 資料表,而且其生產識別碼值 (9) 在 [產品] 資料表中沒有相符的值。 這違反參考完整性。 在展開的資料表中,新資料列有 [類別] 和 [產品] 資料表資料行的 (空白) 值。

有限關聯性

沒有保證「一」端時,模型關聯 性會受到限制 。 有兩個原因可能會導致有限關聯性:

  • 關聯性使用多對多基數類型 (即使其中一個或兩個資料行包含唯一值)。
  • 關聯性為「來源群組間」(只存在於「複合」模型的案例)。

在下列範例中,有兩個有限關聯性,兩者都標示為 L。這兩個關聯性包括 Vertipaq 來源群組中包含的多對多關聯性,以及一對多跨來源群組關聯性。

複合模型的圖表,其中包含兩個標示有限關聯性的數據表。

對於匯入模型來說,永遠都不會為有限關聯性建立資料結構。 在此情況下,Power BI 會在查詢時解析資料表進行聯結。

資料表擴充永遠不會對有限關聯性發生。 數據表聯結是使用 INNER JOIN 語意達成,因此不會新增空白虛擬數據列來補償引用完整性違規。

有與有限關聯性相關的其他限制:

  • RELATED DAX 函數無法用來擷取「一」這端的資料行值。
  • 強制 RLS 具有拓撲限制。

提示

在 Power BI Desktop 模型檢視中,您可以將關聯性解譯為有限。 在基數指標之後,以括弧狀標記 () 表示有限的關聯性。

模型圖表中兩個數據表的螢幕快照,其中已醒目提示有限的關聯性。

解決關聯性路徑模棱兩可

雙向關聯性可以在模型資料表之間引進多個 (也因此而不明確) 的篩選傳播路徑。 評估模棱兩可時,Power BI 會根據其 優先順序權數來選擇篩選傳播路徑。

優先順序

優先順序層會定義Power BI用來解析關聯性路徑模棱兩可的規則序列。 第一個規則比對會決定Power BI將遵循的路徑。 下列每個規則描述篩選如何從源數據表流向目標數據表。

  1. 包含一對多關聯性的路徑。
  2. 包含一對多或多對多關聯性的路徑。
  3. 由多對一關聯性組成的路徑。
  4. 路徑,包含從源數據表到中繼數據表的一對多關聯性,後面接著從中繼數據表到目標數據表的多對一關聯性。
  5. 路徑,包含從源數據表到中繼數據表的一對多或多對多關聯性,後面接著從中繼數據表到目標數據表的多對一或多對多關聯性。
  6. 任何其他路徑。

當關聯性包含在所有可用的路徑中時,它會從所有路徑的考慮中移除。

Weight

路徑中的每個關聯性都有權數。 根據預設,除非使用 USERELATIONSHIP 函式,否則每個關聯性權數都會相等。 路徑權數是路徑上所有關聯性權數的最大值。 Power BI 會使用路徑權數來解決相同優先順序層中多個路徑之間的模棱兩可。 它不會選擇優先順序較低的路徑,但會選擇具有較高權數的路徑。 路徑中的關聯性數目不會影響權數。

您可以使用 USERELATIONSHIP 函式來影響關聯性的權數。 權數是由呼叫這個函式的巢狀層級所決定,其中最內層的呼叫會接收最高的權數。

請思考一下下列範例。 Product Sales 量值會將較高的權數指派給 Sales[ProductID]Product[ProductID] 之間的關聯性,後面接著 Inventory[ProductID]Product[ProductID] 之間的關聯性。

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

注意

如果 Power BI 偵測到具有相同優先順序和相同權數的多個路徑,則會傳回模棱兩可的路徑錯誤。 在此情況下,您必須使用 USERELATIONSHIP 函式或移除或修改模型關聯性來影響關聯權數,來解決模棱兩可的問題。

效能喜好設定

下列清單會排序篩選傳播效能,從最快到最慢的效能:

  1. 一對多來源群組關聯性
  2. 透過中繼資料表所達成的多對多模型關聯性,且牽涉到至少一個雙向關聯性
  3. 多對多基數關聯性
  4. 跨來源群組關聯性

如需本文的詳細資訊,請參閱下列資源: