明確維度定義后，還可以換一種更清晰的方式來審視數(shù)據(jù)庫的結構。

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

E-R圖是個網(wǎng)狀結構，實體(表)之間的外鍵關系直接畫在圖上，當實體較多時這個圖就會顯得非常零亂，關聯(lián)線很隨意，任何兩個實體之間都有可能發(fā)生關聯(lián)，表現(xiàn)出來的數(shù)據(jù)結構耦合度很高。在增加刪除實體時就要考慮與之關聯(lián)的所有其它實體，很可能發(fā)生遺漏關聯(lián)或循環(huán)關聯(lián)的現(xiàn)象。

一

而如果把維度抽取出來之后，我們可以使用總線式的結構圖：

所有維度單獨列出來處于中心地位，實體(表)只和維度發(fā)生關聯(lián)，實體之間沒有直接的關聯(lián)線，數(shù)據(jù)結構的耦合度看起來很低。增加刪除實體時不會影響到其它實體，不會發(fā)生遺漏關聯(lián)和重復關聯(lián)。

不過，需要指出的是。無論是E-R圖還是總線圖，只要畫正確時，其中的關聯(lián)線數(shù)量是差不多的，這是數(shù)據(jù)本身的關系決定的?？偩€圖并不會比E-R中的關聯(lián)線更少，但改變了看待方法后會更清晰。

二

為了提供關聯(lián)查詢能力，有些BI產品將表間關聯(lián)關系(相當于一個局部E-R圖)直接暴露給業(yè)務人員，這不是個好辦法，業(yè)務人員難以理解E-R圖，這個方案的可用性很差。如果能夠由業(yè)務人員選擇了數(shù)據(jù)項(字段)后就自動建立出合理的關聯(lián)，那樣可用性就能提高很多了。

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

業(yè)務人員任意選擇了字段之后，我們可以找出這些字段所在表，再在這些表之間尋找同維字段(優(yōu)先選擇主鍵)，然后使用這些同維字段建立JOIN關系。當某個表上只有***的字段和另一表的主鍵字段同維時，那么基于這兩個字段建立的JOIN關系在絕大多數(shù)情況下都是正確合理的。而且，在數(shù)據(jù)結構不是特別復雜的時候，兩表之間只有***字段同維的條件也常常能夠滿足，這時候就真地能只基于數(shù)據(jù)項自動建立正確的關聯(lián)關系，有些BI產品確實是這么做的。

不過，這種辦法不能處理同表自關聯(lián)和表間有多個同維字段的情況，以及多次遞歸關聯(lián)的問題。想要完善地解決問題，還是需要基于DQL語法來實現(xiàn)關聯(lián)。

三

上面的討論中，我們會把發(fā)現(xiàn)的同維字段JOIN起來，DQL語法也是這樣，只要同維的(廣義)字段就可以JOIN。這樣的JOIN一定有業(yè)務意義嗎?

是的，只要是同維字段，JOIN起來總能想出合理業(yè)務意義。反過來，也只有同維字段之間可以JOIN，不同維字段的JOIN是沒有業(yè)務意義的，不過SQL并不禁止，只要數(shù)據(jù)類型相同就可以JOIN。字段同維和JOIN有業(yè)務意義是等價的，DQL在這方面可以確保這一點。

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

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