何時使用多重要素關係模型
多重要素關係模型是一種資料模型，可讓您在單一資料來源中新增不關聯的資料表，然後在視覺化分析期間使用關聯欄位，以根據內容將資料表拼接在一起。與混合不同，資料存在於單一資料來源中—主要和從屬資料來源的概念不適用，並且不會從剩餘聯結中刪除任何資料。與單一表資料模型不同，多個基底資料表會根據他們之間共用的表維護自己的內容。多重要素關係資料模型為您提供在 Tableau 中執行多事實分析的更多選項。
假設您想要分析天氣和冰淇淋銷售趨勢。天氣和冰淇淋銷售都發生在特定時間和特定地點，但冰淇淋銷售和天氣之間沒有直接連結。這些是不關聯的資料，但都與日期和位置的共用概念關聯。
這個問題有助於建立多重要素關係模型。冰淇淋銷售和天氣各自都可以新增為基底資料表，並與日期和位置關聯，這些表是共用表。
多基底資料表資料模型，具有兩個不關聯的表（冰淇淋銷售和天氣）和兩個共用表（日期和位置）。在冰淇淋銷售和位置之間有一個中繼表 Parlor 資訊。
為什麼我們需要建立不關聯表格模型的功能？
分析通常涉及將資料表匯集在一起，這些資料表甚至彼此沒有直接關係，但都與相同的公用資訊（例如日期或位置）關聯。多重要素關係模型透過引入關聯度的概念以及使用多個不關聯的基底資料表來建立資料模型的能力來支援鬆散語意結合。
語意結合是用來描述資料合併緊密程度的術語。聯結或聯集是緊密的語意結合；他們將多個表組合在一起形成一個新的實體資料表，然後當作單一表使用。關係是表之間的鬆散結合，將表根據邏輯綑綁一起，並保持它們作為分別表的不同狀態。沿著語意結合光譜更進一步的是資料混合，其中來自不同資料來源的結果根據兩個資料來源之間共用的元素進行視覺化合併。多重要素關係模型更接近光譜的混合端，但是在單一資料來源內而不是跨資料來源。
多事實關係模型（有多個基底資料表的資料模型）允許模型中存在非關聯資料表，只要模型中也存在共用資料表。在分析過程中，共用資料表中的欄位根據其共有的共用維度（例如發生在同一地點或同一時間）將原本非關聯資料表「拼接」在一起。這樣可以保留關係的所有好處，包括保留每個資料表的粒度或原生詳細資料層級。
與單一基底資料表資料模型類似，Tableau 根據視覺效果的結構來確定在幕後使用的最佳聯結類型。但在多事實關係模型中，聯結選項已擴展為包括外部聯結和交叉聯結，以處理不同層級的關聯性。有關詳情，請參閱關於多事實關係資料模型。
名稱從哪裡打來？
多重要素關係因多事實分析而得名。在資料倉儲模型中，資料儲存在由維度表包圍的中央事實資料表中。在此內容下，事實指度量或指標，它們是捕獲有關資料的事實的資料數字欄位 - Tableau 的度量。維度表包含有關這些事實的屬性。
基於事實資料表的模式通常被建構為星形或雪花形，取決於維度表的組織方式。當需要跨事實資料表進行分析時，稱為多事實分析。分析是在通用維度資料表（稱為共用維度或一致維度）的內容中完成的。在 Tableau 中，可以使用關係來建置這些資料模型，因此我們將這套功能命名為多事實關係。
何時使用多重要素關係資料模型
如果資料由彼此關聯的表組成，可以堅持使用透過關係建立的單一基底資料表資料來源。當資料（以多個事實資料表的形式或不同的不關聯內容形式）跨越不同的概念時，就需要使用多重要素關係模型。
只要有可能，請使用單一基底資料表建置資料來源。在單一基底資料表資料模型中，每個表都是關聯的，無需考慮關聯度。僅當需要資料模型結構時才使用多重要素關係。
多事實分析
多事實分析是 Tableau 中多重要素關係的核心使用案例。在此範例中，事實 A 和事實 B 共用表「日期」。
為了在 Tableau 中對此建立模型，事實資料表將成為基底資料表，並為其共用維度表建立多個傳入關係。
其他情境
然而，多重要素關係資料模型不僅僅用於多事實分析。Tableau 不需要事實資料表或維度表的嚴格定義。任何表都可以作為基底資料表（儘管它應該符合基底資料表的特徵）。指示多基底資料表資料來源的一些情境可能會有所幫助，包括：
- 經歷階段，例如共用學生表的申請表、成績單和校友活動的基底資料表。
- 同一事件的不同內容，例如醫療預約和帳單發票事件的基底資料表，以及為醫生或患者設定內容的共用表。
- 可能關聯的不同領域，例如以前最好透過資料混合處理的情境，例如透過日期和位置共用表關聯的冰淇淋銷售和天氣。
要深入瞭解多事實關係何時有用，請參閱此 Tableau 部落格貼文：在 Tableau 中何時以及如何使用多事實關係。
識別基底資料表
在多重要素關係模型中，方向性很重要。也就是說，哪些表是模型左側的基底資料表以及哪些表在下游共用會影響如何評估關係以傳回分析結果。
考慮發票、預約、醫生和病人的概念領結：
在 Tableau 中建立資料模型的正確方法是以發票和預約作為基底資料表，以醫生和患者作為共用表（而不是以醫生和患者作為基底資料表）。
正確：發票和預約作為基底資料表 | 不正確：以醫師和病人為基底資料表 |
 |  |
從概念上講，患者（或醫生）是將預約事件和發票事件拼接在一起的實體。
如果資料模型是向後的（例如以醫生和患者作為基底資料表而不是預約和發票），則外部聯結拼接行為效果將大打折扣。分析可能會顯示大量表範圍的度量和不明確值。如果發現自己具有期望外的不明確關聯欄位，請重新評估用作基底資料表的表，並查看是否需要反轉資料模型。
基底資料表和共用表的特徵
如果正在執行多事實分析，事實資料表將成為基底表，任何共用維度表都是共用表。Tableau 不要求嚴格遵守事實和維度資料表特徵。但是，某些屬性可以幫助您確定哪些表應該是基底資料表，哪些表應該是共用表。
基底資料表 | 共用表 |
資料倉儲結構描述中的事實資料表 | 資料倉儲結構描述中的共用或一致維度資料表 |
具體到內容或分析 （航班資訊、能源使用） | 不同內容下的一致概念 （資料、位置） |
度量 heavy | 主要維度 |
更新/交易更頻繁 （醫療預約、處方、生命體征） | 更穩定/耐用 （醫生、病人） |
具有外部索引鍵欄位 | 有主索引鍵欄位 |
基於事件 （課表、作業成績） | 基於實體 （學生、教室） |
請注意，如果基底資料表和共用表之間存在中繼表，則可以任意交換作為基底資料表，無需從根本上改變資料模型。（例如第一個範例中的 Parlor 資訊和冰淇淋銷售。）重要的是哪些表位於共用表的上游，以及哪些表是共用的。
嘗試使用額外的基底資料表
有多種情境可能表明您應該使用多個基底資料表而不是單一基底資料表資料來源來建置多事實關係模型：
- 如果嘗試建立具有循環的資料來源，則下游表應該是另一個基底資料表。
- 如果您有一系列與同一組關係子句（比如日期和位置）關聯的資料表，則應將這些維度拉出並製作為共用資料表。
- 這特別有用，因為多個關係子句必須全部為 true（邏輯上為 AND）才能使資料表與這些記錄關聯。
- 相反，若想分析的記錄中每次有一筆記錄可能為 true（關聯式 OR），則可以透過設定具有共用維度資料表的資料模型來提供這種彈性。
- 如果正在使用混合，但希望在沒有主要和從屬資料來源的情況下獲得等效混合，請建立資料模型，將混合中的資料來源與其在共用表中的連結欄位合併起來。