1. 摘要
本文介紹數據倉庫中維度數據建模的過程描述，并舉一個示例以加深對相關概念的理解。
2. 內容
2.1 維度模型定義
維度模型是數據倉庫領域大師Ralph Kimall所倡導，他的《數據倉庫工具箱》，是數據倉庫工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型，構建的數據模型為分析需求服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模復雜查詢的響應性能。
2.2 維度建模過程
第一步：選擇業務過程
1、通過對業務需求以及可用數據源的綜合考慮，確定對哪種業務過程開展建模工作
2、建立的第一個維度模型應該是一個最有影響的模型——它應該對最緊迫的業務問題作出回答，并且對數據的抽取來說是最容易的。
第二步：定義粒度
注：粒度是指數據倉庫的數據單位中保存數據的細化或綜合程度的級別，細化程度越高，粒度就越小
1、應該先優先考慮為業務處理獲取最有原子性的信息而開發維度模型。原子型數據是所收集的最詳細的信息，這樣的數據不能再做更進一步的細分。
2、數據倉庫幾乎總是要求在每個維度可能得到的最低粒度上對數據進行表示的原因，并不是因為查詢想看到每個低層次的行，而是因為查詢希望以很精確的方式對細節知識進行抽取。
第三步：選定維度
一個經過仔細考慮的粒度定義確定了事實表的基本維度特性。同時，經常也可能向事實表的基本粒度加入更多的維度，而這些附加的維度會在基本維度的每個組合值方面自然地取得唯一的值。如果附加的維度因為導致生成另外的事實行而違背了這個基本的粒度定義，那么必須對粒度定義進行修改以適應這個維度的情景。
第四步：確定事實
確定將哪些事實放到事實表中。粒度聲明有助于穩定相關的考慮。事實必須與粒度吻合。在考慮可能存在的事實時，可能會發現仍然需要調整早期的粒度聲明和維度選擇
2.3 維度建模的基本要素
維度建模中有一些比較重要的概念，理解了這些概念，基本也就理解了什么是維度建模。
1. 事實表
發生在現實世界中的操作型事件，其所產生的可度量數值，存儲在事實表中。從最低的粒度級別來看，事實表行對應一個度量事件，反之亦然。
額，看了這一句，其實是不太容易理解到底什么是事實表的。
比如一次購買行為我們就可以理解為是一個事實，下面我們上示例。
圖中的訂單表就是一個事實表，你可以理解他就是在現實中發生的一次操作型事件，我們每完成一個訂單，就會在訂單中增加一條記錄。
我們可以回過頭再看一下事實表的特征，在維度表里沒有存放實際的內容，他是一堆主鍵的集合，這些ID分別能對應到維度表中的一條記錄。
2. 維度表
每個維度表都包含單一的主鍵列。維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度表行的描述環境應與事實表行完全對應。 維度表通常比較寬，是扁平型非規范表，包含大量的低粒度的文本屬性。
我們的圖中的用戶表、商家表、時間表這些都屬于維度表，這些表都有一個唯一的主鍵，然后在表中存放了詳細的數據信息。
2.4 維度建模過程舉例
下面我們將以電商為例，詳細講一下維度建模的建模方式，并舉例如果使用這個模型（這點還是很重要的）。
一、業務場景
假設我們在一家電商網站工作，比如某寶、某東。我們需要對這里業務進行建模。下面我們分析幾點業務場景：
- 電商網站中最典型的場景就是用戶的購買行為。
- 一次購買行為的發起需要有這幾個個體的參與：購買者、商家、商品、購買時間、訂單金額。
- 一個用戶可以發起很多次購買的動作。
好，基于這幾點，我們來設計我們的模型。
二、模型設計
下面就是我們設計出來的數據模型，和之前的基本一樣，只不過是換成了英文，主要是為了后面寫sql的時候來用。
我就不再解釋每個表的作用了，現在只說一下為什么要這樣設計。
首先，我們想一下，如果我們不這樣設計的話，我們一般會怎么做？
如果是我，我會設計下面這張表。你信不信，我能列出來50個字段！其實我個人認為怎么設計這種表都有其合理性，我們不論對錯，單說一下兩者的優缺點。
先說我們的維度模型：
- 數據冗余小（因為很多具體的信息都存在相應的維度表中了，比如用戶信息就只有一份）
- 結構清晰（表結構一目了然）
- 便于做OLAP分析（數據分析用起來會很開心）
- 增加使用成本，比如查詢時要關聯多張表
- 數據不一致，比如用戶發起購買行為的時候的數據，和我們維度表里面存放的數據不一致
再說我們這張大款表的優缺點：
- 業務直觀，在做業務的時候，這種表特別方便，直接能對到業務中。
- 使用方便，寫sql的時候很方便。
- 數據冗余巨大，真的很大，在幾億的用戶規模下，他的訂單行為會很恐怖
- 粒度僵硬，什么都寫死了，這張表的可復用性太低。
三、使用示例
數據模型的建立必須要為更好的應用來服務，下面我先舉一個例子，來切實地感受一下來怎么用我們的模型。
需求：求出2016年在帝都的男性用戶購買的LV品牌商品的總價格。
實現：
SELECT
SUM(order.money)
FROM
order,
product,
date,
address,
user,
WHERE
date.year = '2016'
AND user.sex = 'male'
AND address.province = '帝都'
AND product.name = 'LV'
四、總結
維度建模是一種十分優秀的建模方式，他有很多的優點，但是我們在實際工作中也很難完全按照它的方式來實現，都會有所取舍，比如說為了業務我們還是會需要一些寬表，有時候還會有很多的數據冗余。
3. 參考
《Hadoop構建數據倉庫實踐》
漫談數據倉庫之維度建模
https://zhuanlan.zhihu.com/p/27426819
