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

這是我們常見的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則確保了不會發生無業務意義的分組。

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