天天看點

【資料蔣堂】第30期:JOIN簡化 - 消除關聯

我們将等值JOIN分成三種情況來分别讨論,分情況相當于加強了條件,我們可以充分利用每種情況下的特征。

<b>1. 外鍵屬性化</b>

先看個例子,設有如下兩個表:

【資料蔣堂】第30期:JOIN簡化 - 消除關聯

employee表和delpartment表的主鍵都是其中的id字段,employee表的department字段是指向department表的外鍵,department表的manager字段又是指向employee表的外鍵。這是很正常的表結構設計。

現在我們想問一下:哪些美國籍員工有一個中國籍經理?

用SQL寫出來是這樣的:

句子較長,由于employee表需要兩次參與JOIN,還需要為它起個别名加以區分。

我們換一種寫法:

當然,這不是标準的SQL語句了。

第二個句子中用紅色部分表示目前員工的“所屬部門的經理的國籍”。我們把外鍵字段了解成一個對象,外鍵表的字段被了解為外鍵字段的屬性,department.manager即是”所屬部門的經理“,而這個字段在department中仍然是個外鍵,那麼它的外鍵表字段可以繼續了解為它的屬性,也就會有department.manager.nationality,即“所屬部門的經理的國籍”。

這種的對象式了解方式,顯然比笛卡爾積過濾的了解方式要自然直覺得多。外鍵表JOIN時并不會涉及到兩個表的乘法,外鍵字段隻是用于找到外鍵表中對應的那條記錄,完全不會涉及到笛卡爾積這種有乘法特性的運算。

我們前面約定,外鍵表JOIN時維表中關聯字段必須是主鍵,是以外鍵字段對應的維表記錄一定是唯一的,這樣deparment.manager.nationality對于employee表中每一條記錄都是唯一的,這就不會發生歧義。而如果不做這個約定,就可能發生多對多,department.manager.nationality無法明确定義。

事實上,這種對象式寫法在結構化進階語言(如C,Java)中很常見,在這類語言中,資料就是按對象方式存儲的。employee表中的department字段取值根本就是一個對象,而不是編号。其實許多表的主鍵取值本身并沒有業務意義,僅僅是為了區分記錄,而外鍵字段也僅僅是為了找到外鍵表中的相應記錄,如果外鍵字段直接是對象,就不需要再通過編号來辨別了。不過,SQL缺乏離散性,不能直接使用這種存儲機制,還要借助編号。

外鍵表關系中,事實表和維表是不對等的,隻能基于事實表去找維表字段,而不會有倒過來的情況。

<b>2. 同維表等同化</b>

同維表的情況相對簡單,還是從例子開始,設有兩個表:

【資料蔣堂】第30期:JOIN簡化 - 消除關聯

兩個表的主鍵都是id,經理也是員工,兩表共用同樣的員工編号,經理會比普通員多一些屬性,另用一個經理表來儲存。

現在我們要統計所有員工(包括經理)的總收入(加上津貼)。

用SQL寫出來還是會用到JOIN:

而對于兩個一對一的表,我們其實可以簡單地把它們看成一個表:

同樣地,根據我們的約定,同維表JOIN時兩個表都是按主鍵關聯的,相應記錄是唯一對應的,salary+allowance對employee表中每條記錄都是唯一可計算的,不會出現歧義。

同維表之間的關系是對等的,從任何一個表都可以引用到其它同維表的字段。

<b>3. 主子表一體化</b>

訂單及訂單明細是典型的主子表:

【資料蔣堂】第30期:JOIN簡化 - 消除關聯

Orders表的主鍵是id,OrderDetail表中的主鍵是(id,no),前者的主鍵是後者的一部分。

現在我們想計算每張訂單的總金額。

直接用SQL寫出來會是這樣:

要完成這個運算,不僅要用到JOIN,還需要做一次GROUP BY,否則選出來的記錄數太多。

如果我們把子表中與主表相關的記錄看成主表的一個字段,那麼這個問題也可以不再使用JOIN以及GROUP BY:

與普通字段不同,OrderDetail被看成Orders表的字段時,其取值将是一個集合,因為兩個表是一對多的關系。是以要在這裡使用聚合運算把集合值計算成單值。

這樣看待資料關聯,不僅了解書寫更為簡單,而且不容易出錯。

假如Orders表還有一個子表用于記錄回款情況:

【資料蔣堂】第30期:JOIN簡化 - 消除關聯

我們現在想知道那些訂單還在欠錢,也就是累計回款金額小于訂單總金額的訂單。

簡單地把這三個表JOIN起來是不對的,OrderDetail和OrderPayment會發生多對多的關系,這就錯了(回憶上一篇中多對多大機率錯誤的說法)。這兩個子表要分别先做GROUP,再一起與Orders表JOIN起來才能得到正确結果,寫出來較為繁瑣。

而如果我們把子表看成主表的集合字段,那就很簡單了:

這種寫法就不容易發生多對多的錯誤。

主子表關系是不對等的,不過兩個方向的引用都有意義,上面談了從主表引用子表的情況,從子表引用主表則和外鍵表類似。

我們改變對JOIN運算的看法,摒棄笛卡爾積的思路,把多表關聯運算看成是稍複雜些的單表運算。這樣,我們相當于從最常見的等值JOIN運算中基本消除了關聯,甚至在文法中取消了JOIN關鍵字,書寫和了解都要簡單很多。

原文釋出時間為:2017-11-14

本文作者:蔣步星