Power BI Desktop 中的模型關聯性
此文章以使用 Power BI Desktop 的匯入資料模型製作人員為目標。 這是要提供直覺式、準確和最佳模型的重要模型設計主題。
若要更深入討論最佳模型設計,包括資料表角色和關聯性,請參閱了解星型結構描述及其對 Power BI 的重要性。
關聯性目的
模型關聯性會將一個模型資料表的資料行上所套用的篩選條件傳播至不同的模型資料表。 只要有要遵循的關聯性路徑,就會傳播篩選,這包含傳播到多個資料表。
關聯性路徑具有確定性,表示一律會以相同的方式傳播篩選,而且不會隨機變化。 不過,關聯性可以予以停用,或具有可使用特定 DAX 函數的模型計算所修改的篩選內容。 如需詳細資訊,請參閱此文章稍後的相關的 DAX 函式主題。
重要
模型關聯性不會強制執行資料完整性。 如需詳細資訊,請參閱此文章稍後的關聯性評估主題,其中說明當您的資料發生資料完整性問題時模型關聯性的運作方式。
讓我們透過下列動畫範例來看看關聯性如何傳播篩選。
在此範例中,此模型包含四個資料表:Category、Product、Year 和 Sales。 Category 資料表與 Product 資料表相關,而 Product 資料表與 Sales 資料表相關。 Year 資料表也與 Sales 資料表相關。 所有關聯性都是一對多 (本文稍後會描述其詳細資料)。
一個可能是由 Power BI 卡片視覺效果所產生的查詢,要求針對單一類別 Cat-A 和單一年份 CY2018 銷售訂單的總銷售量進行查詢。 這就是您可以看到 Category 和 Year 資料表上所套用篩選的原因。 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 what-if 參數是可建立已中斷連線資料表的功能。 如需詳細資訊,請參閱在 Power BI Desktop 中建立及使用模擬參數來視覺化變數 (部分機器翻譯)。
關聯性屬性
模型關聯性會將資料表中的一個資料行與不同資料表中的另一個資料行產生關聯。 (有一個特殊案例,其中此需求未滿足,而其僅適用 DirectQuery 模型中的多重資料行關聯性。如需詳細資訊,請參閱 COMBINEVALUES DAX 函式一文)。
注意
您無法將某個資料行與相同資料表中的不同資料行相關聯。 此概念有時會與定義資料表自我參考之關聯式資料庫外部索引鍵條件約束的功能混淆。 您可以將此關聯式資料庫概念用來儲存父子式關聯性 (例如,每個員工記錄會與某個「主管」員工相關聯)。 不過,您無法使用模型關聯性,根據此類型的關聯性產生模型階層。 若要建立父子式階層,請參閱父子式函式。
資料行的資料類型
關聯性中「來源」和「目標」資料行的資料類型應該相同。 使用 DateTime 資料行上定義的關聯性可能無法如預期般運作。 儲存 Power BI 資料的引擎,只會使用「日期時間」資料類型;「日期」、「時間」和「日期/時間/時區」 資料類型均是在上方實作的 Power BI 格式化建構。 任何與模型相依的物件仍將在引擎 (例如關聯性、群組等等) 中顯示為「日期時間」。 因此,如果使用者從這類資料行的 [模型化] 索引標籤中選取 [日期],其仍不會註冊為相同日期,因為引擎仍會考慮資料的時間部分。 深入了解如何處理日期/時間類型。 若要更正此行為,應該在 Power Query 編輯器中更新資料行資料類型,以從匯入的資料中移除「時間」部分,如此一來,當引擎正在處理資料時,值將顯示為一樣。
基數
每個模型關聯性都是由基數類型所定義。 有四個基數類型選項,代表「from」和「to」相關資料行的資料特性。 「一」的那端表示資料行包含唯一值;「多」的那端則表示資料行可以包含重複的值。
注意
如果資料重新整理作業嘗試將重複的值載入「一」端資料行,整個資料重新整理將會失敗。
以下項目符號清單說明這四個選項與其速記標記法:
- 一對多 (1:*)
- 多對一 (*:1)
- 一對一 (1:1)
- 多對多 (*:*)
在 Power BI Desktop 中建立關聯性時,設計工具會自動偵測並設定基數類型。 Power BI Desktop 會查詢模型以得知哪些資料行包含唯一值。 針對匯入模型,使用內部儲存體統計資料;針對 DirectQuery 模型,則會將分析查詢傳送至資料來源。 不過,有時候 Power BI Desktop 可能會出錯。 出錯原因可能是資料表尚未載入資料,或是您認為包含重複值的資料行目前包含唯一值。 不論是哪一種情況,只要任何「一」端資料行包含唯一值 (或資料表尚未載入資料列),您就可以更新基數類型。
一對多 (和多對一) 基數
一對多和多對一基數選項基本上是相同的,而其也是最常見的基數類型。
設定一對多或多對一關聯性時,您會選擇符合您建立資料行關聯性順序的關聯性。 請考慮如何使用每個資料表中找到的 ProductID 資料行,設定從產品資料表到銷售資料表的關聯性。 此基數類型會是「一對多」,因為 Product 資料表中的 ProductID 資料行包含唯一的值。 如果您以相反方向來關聯資料表 (從 Sales 到 Product),則基數會是「多對一」。
一對一基數
一對一關聯性表示兩個資料行都包含唯一的值。 此基數類型並不常見,而且可能會因為儲存備援資料而代表次佳的模型設計。
如需使用此基數類型的詳細資訊,請參閱一對一關聯性指引。
多對多基數
多對多關聯性表示兩個資料行都可以包含重複的值。 這個基數類型不常使用。 設計複雜模型需求時,通常很有用處。 您可以使用該類型來建立多對多事實的關聯,或與更精細的事實建立關聯。 例如,當銷售目標事實儲存在產品類別層級,而產品維度資料表則儲存在產品層級時。
如需使用此基數類型的指引,請參閱多對多關聯性指引。
注意
針對 Power BI 報表伺服器 2024 年一月及更新版本開發的模型,目前不支援多對多基數類型。
提示
在 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 儲存模式資料表之間的一對多和一對一關聯性。 當「多」端資料行不包含 NULL 時,您才能啟用此屬性。
啟用時,傳送至資料來源的原生查詢會使用 INNER JOIN
而不是 OUTER JOIN
,將兩個資料表聯結在一起。 一般而言,啟用這個屬性可改善查詢效能,雖然這取決於資料來源的特定內容。
當這兩個資料表之間存在資料庫外部索引鍵條件約束時,請一律啟用此屬性。 即使外部索引鍵條件約束不存在,只要您確定資料的完整性存在,就可以考慮啟用該屬性。
重要
如果資料完整性遭到入侵,內部聯結將會消除資料表之間不相符的資料列。 例如,假設有一個模型 Sales 資料表,其 ProductID 資料行值不存在於相關的 Product 資料表中。 從產品資料表到銷售資料表的篩選傳播將會排除未知產品的銷售資料列。 這會導致低估銷售結果。
如需詳細資訊,請參閱 Power BI Desktop 中的採用參考完整性設定。
相關的 DAX 函數
有數個與模型關聯性相關的 DAX 函式。 下列項目符號清單中會簡短說明每個函數:
- RELATED:從關聯性的「一」端擷取值。 這在涉及來自資料列內容中所評估之不同資料表的計算時很有用。
- RELATEDTABLE:從關聯性的「多」端擷取資料列的資料表。
- USERELATIONSHIP:允許計算使用非使用中的關聯性。 (技術上來說,此函式會修改特定非使用中模型關聯性的權數,有助於影響其使用方式)。當您的模型包含角色扮演維度資料表,而您選擇從此資料表建立非使用中的關聯性時,這很有用。 您也可以使用此函式來解決篩選路徑中模稜兩可的情況。
- CROSSFILTER:修改關聯性交叉篩選方向 (為一或兩者),否則會停用篩選傳播 (無)。 當您需要在評估特定計算期間變更或忽略模型關聯性時,這很有用。
- COMBINEVALUES:將兩個或多個文字字串聯結成一個文字字串。 此函式用途在於資料表屬於相同來源群組時,支援 DirectQuery 模型中的多資料行關聯性。
- TREATAS:將資料表運算式的結果以篩選形式套用至來自非相關資料表的資料行。 在進階案例中,當您想要在特定計算評估期間建立虛擬關聯性時,這很有用。
- 父代與子系函式:一系列的相關函式,可用來產生計算結果欄,以移植父子式階層。 然後,您可以使用這些資料行建立固定層級階層。
關聯性評估
從評估觀點來看,模型關聯性可分類為「一般」或「有限」。 這不是可設定的關聯性屬性。 事實上,其是從兩個相關資料表的基數類型和資料來源推斷而來。 請務必瞭解評估類型,因為如果資料完整性遭到入侵,可能會造成效能影響或後果。 本主題將說明這些隱含問題和完整性後果。
首先,需要借助一些模型化理論才能充分瞭解關聯性評估。
匯入或 DirectQuery 模型會從 Vertipaq 快取或來源資料庫提供其所有資料。 在這兩個實例中,Power BI 都能夠判斷關聯性的「一」端存在。
不過,複合模型可以包含使用不同儲存模式 (匯入、DirectQuery 或雙重) 或多個 DirectQuery 來源的資料表。 每個來源 (包括已匯入資料的 Vertipaq 快取) 都會被視為「來源群組」。 然後,可將模型關聯性分類為「來源群組內」或「來源群組間」。 來源群組內關聯性會在來源群組中關聯兩個資料表,而來源群組間關聯性會在兩個來源群組之間關聯資料表。 請注意,匯入模型或 DirectQuery 模型中的關聯性一律為來源群組間。
以下是複合模型的範例。
在此範例中,複合模型包含兩個來源群組:Vertipaq 來源群組與 DirectQuery 來源群組。 Vertipaq 來源群組包含三個資料表,而 DirectQuery 來源群組則包含兩個資料表。 有一個跨來源群組關聯性存在,可讓 Vertipaq 來源群組中的資料表與 DirectQuery 來源群組中的資料表產生關聯。
一般關聯性
當查詢引擎可以判斷關聯性的「一」端時,模型關聯性為「一般」。 其可確認「一」端資料行包含唯一值。 所有一對多「來源群組內」關聯性都是一般關聯性。
在下列範例中,有兩個一般關聯性,兩者都標示為 。關聯性包括 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 將遵循的路徑。 下列每個規則描述篩選如何從來源資料表流向目標資料表。
- 包含一對多關聯性的路徑。
- 包含一對多或多對多關聯性的路徑。
- 包含多對一關聯性的路徑。
- 包含從來源資料表到中繼資料表的一對多關聯性,後面接著從中繼資料表到目標資料表之多對一關聯性的路徑。
- 包含從來源資料表到中繼資料表的一對多或多對多關聯性,後面接著從中繼資料表到目標資料表之多對一或多對多關聯性的路徑。
- 任何其他路徑。
當關聯性包含於所有可用路徑中時,會考慮將其從所有路徑中移除。
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 函式來影響關聯性權數,或是移除或修改模型關聯性,來解決模稜兩可的情況。
效能喜好設定
下列清單會排序篩選傳播效能,從最快到最慢的效能:
- 一對多來源群組關聯性
- 透過中繼資料表所達成的多對多模型關聯性,且牽涉到至少一個雙向關聯性
- 多對多基數關聯性
- 跨來源群組關聯性
相關內容
如需本文的詳細資訊,請參閱下列資源︰
- 了解星型結構描述及其對 Power BI 的重要性
- 一對一關聯性指導方針
- 多對多關聯性指引
- 作用中與非作用中關聯性指導方針
- 雙向關聯性指導方針
- 關聯性疑難排解指導方針
- 影片:Power BI 關聯性的建議事項和避免事項 \(英文\)
- 有任何問題嗎? 嘗試在 Power BI 社群提問
- 有任何建議嗎? 貢獻想法來改善 Power BI