編者按：在任何一個領域，理解了抽象和邏輯，你就更接近上帝;實際上，"上帝"就是邏輯意義上的存在。 正因為此，有神的基督教比無神儒家更有生命力;有了邏輯關係加持的Tableau可以進一步領先於敏捷BI的同行，一騎絕塵。

2020年，tableau最重要的產品功能毫無疑問是"數據關係"，絕不能以update視之;雖然官方公眾號並未連續的、廣泛的宣傳和普及，我卻早在4月份就按耐不住加入了我的書稿之中。

我推薦所有的tableau企業使用者，都應該第一時間嘗試"數據關係"的全新理念，以此將數據準備、數據可視化都推向一個全新的階段。 在《Tableau原理與實踐》一書基礎上，結合近期的學習和培訓所思，進一步闡述如下，並作為後續修訂版本的素材。

1、數據關係的起源

要說數據關係，先要從此前的"多表關聯"的方式說起。 Tableau支援並集（Union）、連接（Join）和混合（Blend）三種數據合併方法。 並集僅限於「數據結構完全相同」的數據，通常為本地數據，適用範圍和方法最易於理解。

難點在於Join和Blend。

我當年折騰了差不多半年時間，才最後理解二者用法背後的原理，並用一張圖片作為最終頓悟的總結。 本書出版時我又增加了一條線區分「數據準備階段」和「數據可視化階段」兩個階段。

可以用簡單幾句話概括如下：

• Join屬於數據準備，在數據明細級別，將多個表預先合併在一起，從而形成一個全新的數據源;
• Blend屬於可視化，在視圖階段（視圖即聚合），將輔助數據源的聚合查詢結果，匹配到主視圖中。

在書的第四章，我用vlookup的查詢和透視圖的拼接形象地描述Join和Blend的兩個過程，旨在強調前者屬於數據明細級別的合併，而後者屬於數據聚合級別的"合併"。

如果更具體的說，二者根本的差異在於，Join一定生成了一個全新的數據源，A Join B之後，再無A和B數據表本身，此為Join;而Blend一定是保持了多個表的獨立性，A Blend B之後，各自獨善其身，並未構建"物理意義上"的全新的數據源。 那，這和數據關係（Relationship）有什麼關係呢？ 上述各自的特徵背後就是各自的優點和缺點。 Join的穩定、Blend的靈活;Join性能上的局限，Blend模型方面的短板。 數據關係旨在結合Join和Blend的優點，同時避免二者各自的缺點。

比如說，Join通常用於層次一致的多表關聯，但是隨著表的增加，就會出現一個龐大無比的數據源，有很多人稱之為"寬表"。 初級的分析師往往對「大寬表」推崇備至，但高級的分析師卻寧可敬而遠之，恐懼在於"性能"。 隨著多表的增加，特別是很多表的層次並非一致，比如客戶的購買明細（100M）與客戶訊息表（10K）做Join，更高層次的數據必然要重複很多遍才能與更低層次的數據對齊，而重複無助於分析，還容易導致聚合錯誤。 正是為了解決Join在多個不同詳細級別的數據表合併方面的性能障礙，Tableau推出的混合Blend才有了用武之地。 Blend在視圖層面聚合，所以無需在行級別將多個表合併，解決了性能問題，但是隨之而來的代價是：視圖層面的Blend無法"重複使用"，這就意味著無法作為數據準備的模型持續完善和更新——隨著數據表的增加，Blend難以駕馭，每次還要從0開始，對於敏捷BI而言，這是致命的弱點。 那有沒有一種可能，既能像Join一樣在數據源階段完成數據準備，從而反覆可用;又能像Blend一樣可以在聚合層次完成合併，從而提高性能？ 於是，數據關係橫空出世。

Tableau官方把「數據關係」冠上了更加高大上的標籤「數據模型」（Data Model），當然，數據關係也足以勝任這個稱號。 當然，數據關係不是拋棄Join和Blend，而是為了讓一切更好。 那如何從此前的三種合併類型，走向四種合併類型，彼此之間的關係又當如何呢？ 這就要回到開篇的那句話——回到邏輯，尋找答案。 （ps：如果上面的部分理解有點難度，先閱讀去年的文章： Tableau 如何合併數據· 頓悟后的究竟指南 ）

2、理解數據關係的階梯從資料庫表的角度看，不存在聚合，只有明細;聚合只存在於可視化分析階段、存在於視圖之中。 之前在視圖層面聚合的blend理念，被糅合到了數據源階段;如何處理數據源階段的「聚合」和「行級別」的關係呢？ 2.1 從邏輯意義上理解關係沒辦法，只能"無中生有"創造一套全新體系——實際上沒有，讓它在邏輯上存在。 就像戴比爾斯（De Beer）告訴全世界女人"鑽石代表愛情"、佛陀告訴大家有一個"西方極樂世界"，有了精神層面的存在，男女之情和禁慾修行就有了額外的意義。 數據關係亦是如此。 為了在數據源階段為「聚合的數據匹配」留出空間，Tableau創造了「邏輯層」和「物理層」的雙層數據模型結構。 物理層對應真實存在的表，邏輯層對應相互獨立的表之間的匹配。

圖4-65 物理層和邏輯層的層次關係

因此，在2020.2之後的Tableau Desktop中，數據並集Union和數據連接Join需要在節點上"打開"到下一層才能看到。 消費者應該假想一個如上圖所示的雙層結構，預設展示的是多個表之間的邏輯關係，按兩下一層是對應的單一物理表或者多個物理層構建的物理表。

於是，理解數據關係的關鍵轉變為：何為物理表/邏輯表，何為物理層/邏輯層？ 根據我的思考和培訓期間的總結，從不同視角看，邏輯層的表可以稱之為物理表，也可以稱之為邏輯表——卻沒有對錯之分。 所以，我建議換一個方式分析：我們把物理層的表的關係界定為"物理關係"，而把邏輯層的表關係界定為"邏輯關係"。

從這個地方作為突破口，模糊"表"的定義，突出表的"關係"，有助於理解數據關係。 ——文辭很重要，定義更重要。

2.2 何為物理關係與邏輯關係？

簡單的說，物理關係指穩定不變、多合一的數據合併方式，合併之後即是整體，再無合併前的多個表;而邏輯關係指保持各表獨立性的數據匹配方式，基於業務邏輯的構建關係，而非合併，因此生成的結果，也只是邏輯上存在，實際上不存在的——這裡的邏輯，即視圖的查詢邏輯。 太抽象了，有必要換一個角度解釋一下。 我們把每一個「人」比做一個「表」，多個人之間的關係有兩類：

• 基於血緣關係的關係，稱之為家庭關係，比如父子、兄弟;
• 沒有血緣關係的關係，稱之為邏輯關係，比如夫妻、朋友;

父子關係再如何爭吵，血緣關係無法打破，關係是穩定的、不變的;而夫妻關係的破裂，可能僅僅隔著幾次吵架的距離，這種關係是脆弱的、靈活的，隨時雙方獨立（回歸單身）的。

用這種方式去看數據表。

基於並集Union和連接Join建立的關係，是穩定不變的、合為一體的，不管分析階段如何使用，都是預先在行級別匹配在一起的，所以稱之為「物理關係」（physical relationship）;

而基於關係建立的多表關係，是各自獨立的、沒有提前合併的，只是基於分析邏輯的需要聚合查詢的，所以稱之為"邏輯關係"（logical relationship）。

物理關係對應的是物理層;邏輯關係對應的是邏輯層。

基於這樣的認識，我們就可以把並集、連接Join、混合Blend和關係融為一體，典型的關係如下所示：

這個是平面圖，如果此時再去看"圖4-65 物理層和邏輯層的層次關係"的立體圖，是不是有那麼點親切感了。

2.3 何為物理表與邏輯表？ （選讀）在用「物理關係」和「邏輯關係」詮釋了物理層和邏輯層之後，我們回來再看物理表和邏輯表。 物理表就是實實在在（physical）存在的表，如同實實在在活著的人;邏輯表就是實際上不存在、但基於某種需要賦予了存在的意義和實際。 基於怎樣的需要？ 基於可視化分析的需要，所以邏輯表其實是相對於視圖的臨時查詢而言的，在數據源階段其實不存在。 理解物理表（physical table）和邏輯表（logical table）極好的參考系是法律意義上的自然人（natural person）和法人（legal person）。

每個人天生都是自然人，不因種族、社會、信仰甚至死亡而改變，這是穩定不變的、天生的，與大自然（nature）的亙古不變相呼應，我們以natural person代指自己。

而"Tableau公司"、"華為公司"甚至政府作為一個實體，並非與天同在，而是基於業務的需要而成立的，都僅僅在法律（law）意義上存在，因此稱之為"法人"（legal person），即法律意義上的擬人化;法律是邏輯的代表。

可以把視圖中的邏輯表，比做基於分析需要的很多數據的臨時組合;就像法人是很多人的臨時組合（只是這裡的"臨時"通常是按年計算的，不過在自然面前，依然是一瞬間）。

至此，大家應該就理解了「數據關係」的設計原理和它背後的充滿邏輯性的智慧。 官方提供了一個bookshop的案例，如下圖所示：

這裡紅色方塊內的表，是使用Join或者Union、在看得見的邏輯關係之後的物理層創建的，只是把雙層的立體關係放在了一個平面中而已。 其他的數據表都保持了獨立性，使用特定的欄位相匹配。 在Tableau Desktop中完成如下圖：

如果你想使用數據關係完成無限可能，推薦點擊"閱讀原文"，查看官方基於上述數據的多重範例（英文）。

劇透一點，之前通過Join無法完成的"取左側僅不匹配值"（Left Only），如今通過"數據關係"可以輕鬆實現了，這樣就把一部分之前必須使用Prep的場景，重歸Desktop。

3、數據關係的性能選項使用數據關係到一定階段，你可能想在性能上更進一步，此時就需要在數據關係層面進一步設置：特別是數據的匹配方式和相互的包含關係。 比如上面的圖書訊息中，一本書可以有多個評論（1：N），但只能有一個出版社（1：1）;不是每本書都能獲獎（圖書訊息表-部分記錄匹配），但是每本獲獎的書必然在圖書訊息表中（獲獎表-全部記錄匹配）。

因此，基於業務邏輯進一步設置數據關係的性能選項，有助於提高構建邏輯表時的查詢性能。 如下圖所示，

性能選項雖然有助於提高性能;但不合理的設置也會導致數據遺失。 所以建議大家在完成部分視圖之後再修改——視圖的背後是邏輯表，理解了多個表的邏輯關係，再回頭設置一下對應的性能選項最好。

至此，本篇較為系統地介紹了2020.2全新功能之"數據關係"的原理，期待大家早日開始使用，享受全新功能帶來的全新體驗。

---

【福利】圖書已經上線20天，特別感謝百勝台灣唐先生、紅塔集團付先生為本書的勘誤作出的突出貢獻;感謝每位讀者的支援與信賴。

微信公眾號--閱讀本文並留言（主題不限），點讚TOP3讀者贈送圖書一本（定價169元）。

曾經，我想找一本説明深入學習Tableau原理與實踐的書，它沒有出現;

於是，我寫了一本，奉獻給大家。

「讓你少走365天坎坷學習路」

「help people see and understand TABLEAU」

---

【圖書】京東·噹噹·天貓多店有售【視頻】觀看

騰訊課程更新了數據關係上/下兩集（購買圖書"如實評價"截圖，贈送視頻課程五折券）

【數據】下載鏈接： https://pan.baidu.com/s/1PDtyJzn2vKqzIIAyATTTjw提取碼： frtu