維度建模（dimensional modeling）是專門用於分析型資料庫、資料倉儲、資料集市建模的方法，資料集市可以理解為是一種小型的資料倉儲。
維度表示你要對資料進行分析時所用的乙個量，比如，你要分析產品銷售情況，你可以選擇按照類別來進行分析，或者按照區域進行分析。這樣的按照xx進行分析的就構成了乙個維度。再比如「昨天下午我在星巴克話費200元喝了一杯卡布奇諾」，那麼以消費為主題進行分析從這段訊息中可以提取三個維度：時間維度（昨天下午）、地點維度（星巴克）、商品維度（卡布奇諾）。通常來說維度表資訊比較固定，且資料量小。
表示對分析主題的度量。事實表包含了與各維度表相關聯的外來鍵，並呼叫join方式與維度表關聯。事實表的度量通常是數值型的，且記錄數會不斷增加，表規模迅速增長。比如上面消費的例子，他的消費事實表結構示例如下所示：
消費事實表：prod_id（引用商品維度表id）、timekey(引用時間維度表)、place_id（引用地點維度表）、unit（銷售量）。
總的來說，在資料倉儲中不需要嚴格按照規範化設計原則，因為資料倉儲的主導功能就是面向分析，以查詢為主，不涉及資料更新操作。事實表的設計是以能夠正確記錄歷史資訊為準則，維度表的設計是以能夠以合適的角度來聚合主題內容為原則。
星型模型（star schema）是最常用的維度建模方式。星型模型是以事實表為中心，所有的維度表都直接連線在事實表身上，像星星一樣。
維度表只和事實表關聯，維度表之間沒有關聯；
每個維度主鍵為單列，且該主鍵被放在事實表中，作為兩邊連線的外來鍵。
以事實表為核心，維度表圍繞核心呈星型分布。
雪花模型（snawflake schema）是對星型模式的擴充套件。雪花模式的維度表可以擁有其他維度表。雖然這種模型相比星型模型更規範一些，但是由於這種模型不太容易理解，維護成本比較高，而且效能方面需要關聯多層維度表，效能也比星型模型要低，所以一般不是很常用。
星座模型是星型模型延伸而來，星型模型是基於一張事實表，而星座模型是基於多張事實表的而且共享維度資訊。
前面介紹的兩種維度建模的方式是對應單事實表，但是在很多時候維度空間的事實表不止乙個，而乙個維度表也可能被多個事實表用到，在業務發展後期，絕大部分維度表建模都是採用星座模型。
維度表命名遵循 dim_的規則，其中dimension_name用來描述維度的內容。
維度一般是指 人員（who）、時間（when）、地點（where）、事件（what）來劃分。
事實表的命名遵循fact_的規則，其中fact_name用來描述事實表的內容。
事實表一般是以多少（how much）來劃分的。
10 維度建模10大基本原則
一 前言 特別宣告 本文整理自網際網路。遵循這些原則進行維度建模可以保證資料粒度合理，模型靈活，能夠適應未來的資訊資源，違反這些原則你將會把使用者弄糊塗，並且會遇到資料倉儲障礙。二 正文 原則1 載入詳細的原子資料到維度結構中 維度建模應該使用最基礎的原子資料進行填充，以支援不可預知的來自使用者查詢...
資料中臺模型設計系列（一） 維度建模初探
操作型業務系統 對於這個概念大家都不陌生。企業業務賴以運轉的交易系統就屬於操作型業務系統。因此它是為了保障業務正常運轉，能夠更快的處理事務。但是因為它是針對某一特定的意圖 例如滿 易業務 它不需要承諾與其他業務系統共享公共資料。因此就出現了適合於企業中交叉應用的erp 主資料系統。當然對於有建設業務...
資料倉儲專題（7） 維度建模10大基本原則
一 前言 特別宣告 本文整理自網際網路。遵循這些原則進行維度建模可以保證資料粒度合理，模型靈活，能夠適應未來的資訊資源，違反這些原則你將會把使用者弄糊塗，並且會遇到資料倉儲障礙。二 正文 原則1 載入詳細的原子資料到維度結構中 維度建模應該使用最基礎的原子資料進行填充，以支援不可預知的來自使用者查詢...