這是我的第28篇原創(chuàng)

《如何搭建一個數(shù)據(jù)倉庫》這篇文章被幾個大號轉載了。有很多朋友留言，說能不能再細細的講講3NF、維度模型、寬表模型這幾種模型。

最近工作有些忙，今天終于抽出空來好好寫一下。

但凡是計算機科學、軟件工程、信息技術等專業(yè)畢業(yè)的同學，大學的時候肯定有一門必修課《數(shù)據(jù)庫原理》，在那本書里就非常詳細的剖析了3NF（三范式）。但是那個解釋非?；逎y懂，甚至還有數(shù)學論證，擺明了就是不想讓人看懂。

其實3NF很容易理解，換一個說法你就明白了。

三范式是數(shù)據(jù)庫建表（類同于excel的sheet頁）設計原則，分為第一范式、第二范式、第三范式（這也太簡單了吧？），其實還有第四范式、第五范式，不過那都沒人用。

詳細的解釋可以看我之前的文章《抽象真實世界的利器-三范式》，那篇文章講的透透的。

三范式主要應用在業(yè)務數(shù)據(jù)庫中，也就是傳說中的OLTP（聯(lián)機事務處理）。為啥叫聯(lián)機事務處理這么生澀的名字，我當初也是納悶了很久。后來我明白了，其實是相對于單機事務處理來的。

以前都是單機版程序，一臺電腦完成所有業(yè)務流程和數(shù)據(jù)讀寫。后來架構分離了，變成C/S、B/S架構，那就必須得好幾臺機器連在一起，所以叫聯(lián)機。事務處理好理解，就是業(yè)務流程（事務）處理的意思了。

維度模型中，一般分為兩種：星型模型和雪花模型，再往上就是CUBE。

星型模型

看下圖你就知道為啥叫星型模型了，就是抽象出來的樣子像一顆星星。

如果你足夠仔細，其實就能發(fā)現(xiàn)星型模型，乃至于維度模型的秘密。

在維度模型的設計理念中，數(shù)據(jù)工程師把所有的業(yè)務操作抽象成兩類：

這兩類信息必須關聯(lián)起來，才能形成完整的交易鏈條。這兩類信息畫成圖，就是中間是事實表，四周是維表，中間用代碼連接。整個形狀像是一個星星一樣，所以叫星型模型。

雪花模型

我朋友圈里全是聰明人，所以不看圖你也應該能猜到，雪花模型為啥叫這個名字了。是的，沒錯！就是因為形狀像雪花。

邏輯跟星型模型是一樣的，事實表、維度表。

在關系型數(shù)據(jù)庫中，那時候存儲還比較貴，磁盤很小，所以每一份數(shù)據(jù)都要盡量少存一些，所以當時會嚴格按照三范式的要求，把每一個屬性都單獨抽成表。以全國的三級行政區(qū)劃表為例，如果是一張表，三個列，就是省代碼、省名稱、市代碼、市名稱、縣代碼、縣名稱，省代碼和省名稱會重復非常多次。拆成三張表，就是一張省表、一張市表、一張縣表，省表里有三十幾條數(shù)據(jù)，市表里幾百條數(shù)據(jù)；縣表里就幾千條數(shù)據(jù)。

另外一個好處就是表間關系就非常清晰，看到雪花模型圖，一眼就能看明白整個架構有哪些內容，各自的關系是怎樣的。

星系模型

雪花模型還有一個變種，叫做星系模型（星座模型），其實就是多個雪花模型連在一起。

如上表所示，上下是訂單和營銷兩個雪花模型，兩片雪花通過兩個事實表連接在一起，形成一個星系。另外，在星系中還會對每個雪花中相同的維度進行抽象，比如地區(qū)維度，這時候星系就會很復雜，上圖中為了保持簡潔，并沒有體現(xiàn)這種情況。

CUBE模型

之所以叫cube，就是因為抽象出來就像一個魔方-magic cube。

這個形象倒是很形象，但是很多人依然看不明白。你這個CUBE跟上面的維度模型貌似沒啥區(qū)別啊，就是把每個維度中的值給羅列出來了而已。這類圖最坑的地方就是只告訴你cube的維度了，沒告訴大家事實在哪里，所以大家都糊里糊涂的。

這么寫一下你就明白了。我們可以通過類目、訂單狀態(tài)和月份三個維度，去看訂單量、訂單金額的統(tǒng)計結果。減少一個維度，就是上卷，增加一個維度就是下鉆。就這么簡單。

所以理解cube，你可以取個巧：CUBE模型其實就是多維模型的存儲結構。在kylin這類預計算的MOLAP產品中，資料稍微詳細、易懂一些。kylin會把每個組合方式計算一遍，然后存儲下來。在查詢的時候，kylin直接讀取預計算的結果就好了，所以速度非?？欤欠浅Ｕ即鎯?。為了減少存儲，kylin提供了剪枝的功能，就是把不常要的某個分支給刪掉。

以上圖為例，一個類目+訂單狀態(tài)+月份的cube，其實會生成0維1張表，1維3*1=3張表，2維C32=(3*2)/(2*1)=3張表（3張表，兩兩組合），3維1張表，總共8張表。這才3個維啊！我們現(xiàn)在動輒幾十個維度，這個存儲你可想而知了。

前面講過三范式。嚴格按照三范式的規(guī)則設計出來的表就是窄表，每張表只說一件事情，如果順帶說了其他事情，就要拆表。相對于窄表來說，一張表中說了好幾個事情，好幾個概念，就是寬表了。寬表其實就是三范式的退化。寬表在關系型數(shù)據(jù)庫中是異類，但是在NoSQL數(shù)據(jù)庫中大行其道。

上圖就是用三個窄表解決了訂單業(yè)務數(shù)據(jù)存儲。優(yōu)點是關系非常清晰，一眼能看明白實體以及之間的關系。

上表就是一張大寬表，冗余了賣家和買家的信息。對開發(fā)、數(shù)據(jù)分析師非常友好，不用join，直接拖數(shù)據(jù)就好了。

從星型到雪花到星系到CUBE，最后到寬表，面對的業(yè)務越來越多，關系越來越復雜，數(shù)據(jù)量也越來越多。在關系型數(shù)據(jù)庫為數(shù)倉載體的時候，我們盡可能的保證實體與關系之間的清晰邏輯。

但是在NoSQL環(huán)境中，分布式數(shù)據(jù)庫JOIN的代價比較大，另外呢，現(xiàn)在的存儲也非常便宜。所以星系模型是廢了，雪花模型已經(jīng)基本不用了；星型模型和CUBE在一些情況還在用；加上現(xiàn)在對效率的要求越來越高，所以數(shù)據(jù)倉庫靠上的兩層，基本都是直接建大寬表，導致現(xiàn)在很多人就知道寬表，而不知道其他模型了。

但是，這個世界始終還是底層規(guī)則決定上層邏輯。對于底層規(guī)則吃的越透，上層邏輯就越容易理解。

以上，與諸位共勉！