多維資料庫（Multi Dimensional Database，MDD）使用Dimension（維度）和Cube（資料立方體、資料集市）模型描述資料。
多維資料模型
關係型資料庫（Relational Database，RDB）中的星型結構或雪花型結構就是模擬上述多維模型結構的，但無法提供真正意義上的多維資料分析能力，這裡不做過多解釋。
下文講解Oracle Essbase以及IBM Cogons這種真正的多維資料庫的原理。
多維資料庫中模型結構與事實資料分別以概要檔案（profile）和資料塊（data block）的形式存在。
profile和data block
概要檔案用來描述以下資訊：
維度和維度成員資訊
與維度相關的層級（Hierarchy）和級別（Level）資訊
Cube的描述性資訊，以及Cube與維度的關聯性
其他描述性的資訊，如實體模型屬性
Cube中度量資料存放在data block中，data block可以被理解成為多維陣列結構，其大小與相關維度的明細成員數量有直接關係。
計算公式：data block size = 維度1明細成員總數 * 維度2明細成員總數 * …… * 維度N明細成員總數
資料塊容量等於相關維度明細成員數量的笛卡爾積。
資料塊大小
明細度量值一般採用double型別，按8bytes算，上圖所描述的Cube的資料塊大小為480bytes。
除了資料塊中的明細度量值外，其他非明細度量值並沒有直接儲存，因為其可以透過對應的明細度量值計算出來。
非明細度量值計算方式
一些不存在的度量值會造成資料空洞問題，假設2018年4季度河北省B品牌手機的銷售量是未知的，則會在資料塊中產生一個空洞。
注意：資料空洞表示不存在的值，與數值0的意義不同，數值0表示一個有意義的值。
如果資料空洞比較多，則資料塊的資料密度就會下降，將造成儲存空間的浪費。
資料空洞
除了資料空洞問題，還存在資料爆炸問題。資料塊大小由全部維度明細成員數量的笛卡爾積決定，假如某個Cube關聯三個維度，每個維度明細成員數量均為100，則：data block size = 100 ^ 3 = 1000000，如果度量值按double型別儲存（8bytes），資料塊檔案大約為7。62M。如果每個維度明細成員數量增加至150，則資料塊檔案將膨脹到25。74M（data block size = 150 ^ 3 * 8bytes / 1024 / 1024）。
當資料塊極度膨脹並且存在很多資料空洞的時候，會極大地浪費儲存空間，並且可能導致資料儲存無法實現。
極度膨脹和存在大量空洞的多維陣列
為了解決資料空洞和資料膨脹問題，引入了密集維度組合和稀疏維組合的概念。
判斷維度組合是密集還是稀疏的原則是看其所對應的明細度量值的存在情況，例如：
北京地區只有ABC三種手機的銷售額，天津地區只有BCD三種手機的銷售額，河北地區賣出的手機只有AE兩種，表明並不是每個地區對於每一種手機都有銷售額，所以地區與產品屬於稀疏的維度組合。
2018年的四個季度都有手機銷售額，所以日期維度自身可以構成密集的維度組合。
注意！在其他講解多維資料庫的文章中都把維度分為稀疏維與密集維，這是非常錯誤的，對於維度本身來講沒有稀疏與密集之分，稀疏與密集表示的是維度之間的組合！對於有N個維度的Cube而言，如果其只有一個維度退化成索引，或者有N - 1個維度退化成索引，則此時稀疏與密集的維組合只包含一個維度，但這只是一種特例，並不代表維度本身是稀疏或密集的。
在引入稀疏與密集的維度組合之後，原本由於資料空洞和資料爆炸而失控的資料塊結構將變成索引和密度相對較高的小資料塊結構。
索引和小資料塊
之前資料檔案大小為3 * 4 * 5 = 60，結構變換之後每個小資料塊大小為4（共8個），在不計算索引所佔儲存大小的情況下，儲存容量變為原來的一半。
度量值的變化可能引起稀疏維度組合和密集維度組合的改變，如下圖所示。
重構
雖然解決了資料空洞和資料爆炸的問題，但稀疏與密集的維組合所帶來的負作用是一旦度量值的變化導致了資料塊密度中心的改變，相關的索引和子資料塊必須重構，而這種重構的效能代價與時間成本是極為昂貴的。Cogons、Essbase等傳統多維資料庫以及其他MOLAP都存在此問題。
基於向量計算引擎（Vector Calculation Engine）的新型分散式多維資料庫很好的解決了資料重構問題。
向量計算引擎將海量資料的運算從多維資料庫核心分離出來，進而將多維分析時的邏輯運算與聚集計算解耦。多維資料庫核心只負責邏輯運算，完全不需要再考慮資料量的問題。向量計算引擎採用極為簡單的資料結構儲存TB、PB級資料，並且只負責進行一種演算法上極為簡單的聚集運算，針對此種特性，適宜採用更加接近底層的程式語言進行開發（如C語言），不僅得到了效能上的提升，也因為資料儲存結構的簡單而獲得了更加穩定的執行效果。
基於向量計算引擎的多維資料庫
如上圖所示，在多維資料庫核心角度來看，向量計算引擎是更加底層的一種基礎服務，所以可以根據各種應用場景切換不同的實現方式，而這一切對於多維資料庫核心來說都是透明的，多維資料庫本身對更上層的應用提供一致的資料查詢能力，從而更好的支援了100%面向業務的探索式資料分析能力。