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