資料蔣堂 | JOIN延伸 - 維度其它應用

資料派THU發表於2018-01-11

明確維度定義後，還可以換一種更清晰的方式來審視資料庫的結構。 這是我們常見的E-R圖： E-R圖是個網狀結構，實體（表）之間的外來鍵關係直接畫在圖上，當實體較多時這個圖就會顯得非常零亂，關聯線很隨意，任何兩個實體之間都有可能發生關聯，表現出來的資料結構耦合度很高。

明確維度定義後，還可以換一種更清晰的方式來審視資料庫的結構。

這是我們常見的E-R圖：

1126021832e656d516dddf6fab82844072e6fd6a

E-R圖是個網狀結構，實體（表）之間的外來鍵關係直接畫在圖上，當實體較多時這個圖就會顯得非常零亂，關聯線很隨意，任何兩個實體之間都有可能發生關聯，表現出來的資料結構耦合度很高。在增加刪除實體時就要考慮與之關聯的所有其它實體，很可能發生遺漏關聯或迴圈關聯的現象。

而如果把維度抽取出來之後，我們可以使用匯流排式的結構圖：

839bbc1d29c8c34761c15740838870f817c0a621

所有維度單獨列出來處於中心地位，實體（表）只和維度發生關聯，實體之間沒有直接的關聯線，資料結構的耦合度看起來很低。增加刪除實體時不會影響到其它實體，不會發生遺漏關聯和重複關聯。

不過，需要指出的是。無論是E-R圖還是匯流排圖，只要畫正確時，其中的關聯線數量是差不多的，這是資料本身的關係決定的。匯流排圖並不會比E-R中的關聯線更少，但改變了看待方法後會更清晰。

為了提供關聯查詢能力，有些BI產品將表間關聯關係（相當於一個區域性E-R圖）直接暴露給業務人員，這不是個好辦法，業務人員難以理解E-R圖，這個方案的可用性很差。如果能夠由業務人員選擇了資料項（欄位）後就自動建立出合理的關聯，那樣可用性就能提高很多了。

有了維度概念，就可以一定程度地實現這一目標。

業務人員任意選擇了欄位之後，我們可以找出這些欄位所在表，再在這些表之間尋找同維欄位（優先選擇主鍵），然後使用這些同維欄位建立JOIN關係。當某個表上只有唯一的欄位和另一表的主鍵欄位同維時，那麼基於這兩個欄位建立的JOIN關係在絕大多數情況下都是正確合理的。而且，在資料結構不是特別複雜的時候，兩表之間只有唯一欄位同維的條件也常常能夠滿足，這時候就真地能只基於資料項自動建立正確的關聯關係，有些BI產品確實是這麼做的。

不過，這種辦法不能處理同表自關聯和表間有多個同維欄位的情況，以及多次遞迴關聯的問題。想要完善地解決問題，還是需要基於DQL語法來實現關聯。

上面的討論中，我們會把發現的同維欄位JOIN起來，DQL語法也是這樣，只要同維的（廣義）欄位就可以JOIN。這樣的JOIN一定有業務意義嗎？

是的，只要是同維欄位，JOIN起來總能想出合理業務意義。反過來，也只有同維欄位之間可以JOIN，不同維欄位的JOIN是沒有業務意義的，不過SQL並不禁止，只要資料型別相同就可以JOIN。欄位同維和JOIN有業務意義是等價的，DQL在這方面可以確保這一點。

DQL中GROUP BY總是要對應著ON（如果單表可以看成是省略ON），也就是說，GROUP BY總是針對某個維度進行的。事實上也是這樣，針對測度的分組運算沒有業務意義，不過SQL並沒有明確出維度和測度的概念，也不會禁止這個運算。DQL則確保了不會發生無業務意義的分組。

利用這個特點，可以提高分組運算的效能。維度可能的取值是由維表長度決定的，而維表是事先知道的，這樣在分組時可以採用類似基數排序法的手段提速，當然，針對維度的排序運算也可以用這種辦法。不過，這個演算法細節與本篇主題相關性較低，這裡就不詳細說明了。


原文釋出時間為：2018-01-11

本文作者：蔣步星

本文來自雲棲社群合作伙伴“資料派THU”，瞭解相關資訊可以關注“資料派THU”微信公眾號

原文連結


相關文章