明確維度定義後，還可以換一種更清晰的方式來審視數據庫的結構。
這是我們常見的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則確保了不會發生無業務意義的分組。
利用這個特點，可以提高分組運算的性能。維度可能的取值是由維表長度決定的，而維表是事先知道的，這樣在分組時可以採用類似基數排序法的手段提速，當然，針對維度的排序運算也可以用這種辦法。不過，這個算法細節與本篇主題相關性較低，這裏就不詳細說明了。本文轉載於潤乾軟件官方網站。