維度建模（dimensional modeling）是數據倉庫建設中的一種數據建模方法，將數據結構化的邏輯設計方法，它將客觀世界劃分為度量和上下文，Kimball 最先提出這一概念。
基本介紹
簡介,基本原則,維度建模步驟,簡介,商業智慧型項目規劃,商業智慧型項目業務需求定義,數據倉庫邏輯設計,數據倉庫物理設計,ETL設計與開發,多維數據集開發,
簡介
其最簡單的描述就是，按照事實表，維度表來構建數據倉庫，數據集市。這種方法的最被人廣泛知曉的名字就是星型模式（Star-schema）。實體關係模型(E-R)建模通常用於為單位的所有進程創建一個複雜的模型。這種方法已被證實在創建高效的在線上事務處理 (OLTP) 系統方面很有效。相反，維度建模針對零散的業務進程創建個別的模型。例如，銷售信息可以創建為一個模型，庫存可以創建為另一個模型，而客戶帳戶也可以創建為另一個模型。每個模型捕獲事實數據表中的事實，以及那些事實在連結到事實數據表的維度表中的特性。由這些排列產生的架構稱為星型模式或雪花模式，已被證實在數據倉庫設計中很有效。
維度建模將信息組織到結構中，這些結構通常對應於分析者希望對數據倉庫數據使用的查詢方法。1999 年第三季度西北地區的食品銷售額是多少？表示使用三個維度（產品、地理、時間）指定要匯總的信息。
星型模式之所以廣泛被使用，在於針對各個維作了大量的預處理，如按照維進行預先的統計、分類、排序等。通過這些預處理，能夠極大的提升數據倉庫的處理能力。特別是針對 3NF 的建模方法，星型模式在性能上占據明顯的優勢。
同時，維度建模法的另外一個優點是，維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優勢。維度建模的優點可以總結如下：
a) 維度建模是可預測的標準框架。允許資料庫系統和最終用戶查詢工具在數據方面生成強大的假設條件，這些數據主要在表現和性能方面起作用。
b) 星型連線模式的可預測框架能夠忍受不可預知的用戶行為變化。
c) 具有非常好的可擴展性，以便容納不可預知的新數據源和新的設計決策。可以很方便在不改變模型粒度情況下，增加新的分析維度和事實，不需要重載數據，也不需要為了適應新的改變而重新編碼。較好的擴展性意味著以前的所有套用都可以繼續運行，並不會產生不同的結果。
但是，維度建模法的缺點也是非常明顯的，由於在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些與處理過程中，往往會導致大量的數據冗餘。
另外一個維度建模法的缺點就是，如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用於維度建模的方法。
基本原則
原則1、載入詳細的原子數據到維度結構中
維度建模應該使用最基礎的原子數據進行填充，以支持不可預知的來自用戶查詢的過濾和分組請求，用戶通常不希望每次只看到一個單一的記錄，但是你無法預測用戶想要掩蓋哪些數據，想要顯示哪些數據，如果只有匯總數據，那么你已經設定了數據的使用模式，當用戶想要深入挖掘數據時他們就會遇到障礙。當然，原子數據也可以通過概要維度建模進行補充，但企業用戶無法只在匯總數據上工作，他們需要原始數據回答不斷變化的問題。
原則2、圍繞業務流程構建維度模型
業務流程是組織執行的活動，它們代表可測量的事件，如下一個訂單或做一次結算，業務流程通常會捕獲或生成唯一的與某個事件相關的性能指標，這些數據轉換成事實後，每個業務流程都用一個原子事實表表示，除了單個流程事實表外，有時會從多個流程事實表合併成一個事實表，而且合併事實表是對單一流程事實表的一個很好的補充，並不能代替它們。
原則3、確保每個事實表都有一個與之關聯的日期維度表
原則2中描述的可測量事件總有一個日期戳信息，每個事實表至少都有一個外鍵，關聯到一個日期維度表，它的粒度就是一天，使用日曆屬性和非標準的關於測量事件日期的特性，如財務月和公司假日指示符，有時一個事實表中有多個日期外鍵。
維度建模步驟
簡介
在商業智慧型項目的實施過程中，維度建模技術和企業數據倉庫建模是兩種不同的方法論，以下是在以套用驅動、提供快速原型的商業智慧型項目的實施和規划過程中使用的維度建模方法時的標準實施過程。具體到項目中則根據項目的規模及所涉及的業務範圍而有所補充或裁減。
商業智慧型項目規劃
a) 數據倉庫項目的定義及範圍
b) 項目準備評估
c) 業務合理性證明
商業智慧型項目業務需求定義
a) 業務需求收集
b) 業務需求審查
c) 數據審計
數據倉庫邏輯設計
3.1. 維度建模
維度建模是一種邏輯設計技術，該技術試圖採用某種直觀的標準框架結構來表現數據，並且允許高性能存取。維度模型是用來設計向最終用戶交付的資料庫的一種快速交付技術。
3.2. 定義數據倉庫匯流排結構
a) 業務驅動維度建模
b) 數據倉庫匯流排結構矩陣
c) 一致性維度
d) 一致性事實
一致性維度和一致性事實是數據倉庫的“匯流排”
e) 單元數據集市
購貨訂單，裝船，付款
來源於單個事務
f) 多元數據集市
客戶利潤率，其中描述收益的傳統源必須與描述成本的傳統源組合在一起使用。
來源於多個事務
應該從單元數據集市開始創建數據集市。
g) 事務模式數據集市
h) 周期快照數據集市
i) 累計快照數據集市
3.3. 定義高級數據模型邏輯圖
3.4. 維度模型的設計過程
a) 選取業務處理
b) 定義粒度
c) 選定維度
d) 確定事實
3.5. 源數據－目標數據映射（ETL規則定義）
a) 維度表映射
b) 事實表映射
3.6. 產出文檔
a) 數據倉庫匯流排結構文檔
b) 高級數據模型文檔
c) 數據模型及ETL設計文檔
數據倉庫物理設計
4.1. 創建物理數據模型
a) 選擇數據建模工具
b) 物理數據結構的設計
4.2. 制定最初的索引計畫
a) 為事實表創建索引
b) 為維度表創建索引
4.3. 設計和創建資料庫實例
a) 保存資料庫創建腳本和參數檔案
b) 創建物理存儲結構
4.4. 產出文檔
a) 數據模型設計文檔
b) 資料庫創建腳本文檔
c) 資料庫初始化腳本文檔
d) 在數據模型及ETL設計文檔中加入相關部分的設計內容
ETL設計與開發
5.1. 維度表裝載設計
5.2. 事實表裝載設計
5.3. 聚合表和多維在線上分析處理裝載
5.4. 數據倉庫的操作與自動化
數據倉庫操作都是在非公開方式下定期執行裝載處理。
5.5. 產出文檔
a) 項目開發文檔
b) 在數據模型及ETL設計文檔中加入相關部分的設計內容
多維數據集開發
6.1. 數據集市定義
a) 維度定義
b) 度量值組定義
c) 計算成員定義
6.2. 透視定義
根據用戶套用需求將多個度量值組組合在一起，定義出一個多維數據集的子集。
6.3. 產出文檔
a) OLAP 多維數據集項目開發文檔
b) OLAP 多維數據集業務說明文檔
