數據蔣堂｜JOIN延伸

作者：蔣步星

本文長度為1320字， 建議閱讀3分鐘

本文為你講解JOIN延伸之維度的其他應用。

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

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

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

很可能發生遺漏關聯或迴圈關聯的現象。

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

所有維度單獨列出來處於中心地位， 實體（表）只和維度發生關聯， 實體之間沒有直接的關聯線， 資料結構的耦合度看起來很低。

增加刪除實體時不會影響到其它實體， 不會發生遺漏關聯和重複關聯。

不過， 需要指出的是。 無論是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則確保了不會發生無業務意義的分組。

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

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