點擊藍色“有關SQL”關注我喲

加個“星標”，天天與10000人一起快樂成長

如果有人問起，“L，對于編程，你最后悔的一件事情是什么？”我只能回答：“數據結構”。

故事，要從我最初學編程的動機，開始說起。

踏入編程這個行當，我是從Visual FoxPro 開始的。

上大學那會，本科學農，農學是養花養草的專業，和計算機一點兒關系沒有。但學校是有規定，大一大二要通過計算機二級。被教育了12年，別的本事沒有，要說證書這事，那是相當熱衷。所以早早就把 VFP 學好了，自然考試也輕松通過。

通過也就通過了，也沒留下特別的情感。轉機出現在大二，那年學統計，其中有各種公式，各種參數，紛繁復雜，作業題不難，但很多推演特別麻煩。那天做完統計學作業，正在圖書館發呆，過了2,4,6級，發現人生有些空虛，接下來還有2年半的時間要揮霍，不禁要焦慮，接下來該做什么，才能證明自己？

人生的苦惱，逃不過三大問題，我是誰，我從哪里來，要到哪里去

眼瞅著瞅著，就瞄到了作業題上去。這些可惡的參數，每次都要手寫，一寫就是一個長本，跟寫舞臺劇臺詞一樣。那有沒有好一點的方法來求解最終的答案呢？

就跟棒球突然擊中村上春樹文藝細胞一般，慵懶的午覺，加上一口激爽的冰咖，瞬間蟄醒了已充分回血的大腦。忽然就想到了VFP中的表單，想到了類里面的變量，這些變量不就是參數嘛，表單不就是每次作業題的草稿嘛。至于公式，那就是方法嘛。我把公式，參數，建成類，最終結果就讓計算機程序去算。為什么我要用筆去推算呢？

慢慢的思路磨就出來，于是，說干就干，到機房，插上1.44MB的磁盤，一個下午，把指數平滑公式給寫好了。接下來的作業，只要輸入表單對應參數值，按下計算按鈕，結果就出來了。

從此，作業變成了分析需求，編程成了我真正的作業。

你們看，我開始編程時，就在解決一些實際問題，將作業計算中的定量模型，抽象出K-V的數據模型，而計算公式則抽象出函數。

現在回首，我依然對廣義的數據結構和算法抱著極高的敬畏。同時，我也慶幸，我掌握了解決信息領域的數據結構與算法，即關系型數據庫的數據模型。

如果說，廣義的數據結構，比如鏈表，平衡樹和圖等，是一切編程的基礎，那么理解RDBMS的“數據結構”，比如范式，星型，雪花型，大寬表等，就是叱咤信息領域的基礎。無論你如何努力，都不會精通，卻可以解決無數實用的問題，帶來極大的心理成就感和滿足。

為方便大家直觀地感受數據模型，在這兒出道題，比如對比雙11，雙12等前后價格波動，引起的銷量變化。分享下，你會如何涉及表結構，來滿足分析的需求。

要做好這類數據分析的建模工作，離不開討論 Kimball 與 Inmon 的數據模型。兩種截然不同的模型，帶給項目的便利與挑戰，也是大不同。

當然還有諸如 Data Vault 與 Anchor 模型等等

首先從架構說起

上圖，是 Inmon 的集線器架構圖。數據倉庫，并不是 Inmon 理論的交付產品，它只是一個集企業所有關鍵實體、業務流程數據于一體的存儲。面對各個部門自己的分析需求，數據倉庫最終還會繼續分流出各個業務需要的數據集市，所有單獨的業務都從分配到的數據集市中抽取數據。

從這個架構圖，很容易看出，數據倉庫只是負責收集數據，類似集線器，最終還是要把數據分流出去。

Kimball 的架構就不一樣了。如下圖所示，他也有一個大的數據倉庫，但少了數據集市的概念。

在Kimball的理論模型中，數據集市從來不是正規的交付物，而是ETL過程中自然產生的副產品。即ETL將業務數據集中抽到 Staging 時，會將數據按照實體，業務流程打包成一個ODS層(Operational Data Store)，任何單個業務部門，完全可以從ODS中查詢數據。功能上類似于 Inmon 的數據集市。

最終數據匯總到數據倉庫時，天然就帶有企業全局屬性。只見樹木不見森林的尷尬，就被化解了。好比，面臨企業利潤的下滑，我們就能從成本，訂單量，單價上來做多維度分析，而不再是僅僅盯著訂單量一個維度去看。

所以，Kimball 的理論，更多是數據從局部流向整體的策略，最終交付物，數據倉庫就像是企業數據流總線，誰要誰取，不必切換多個數據庫。

再對比數據模型的落地

曾經有位同事問我，為什么我們的表，設計了很多冗余字段，而不是嚴格按照三范式設計呢？其實答案就是 Kimball 的維度模型使然。在 Kimball 總線架構圖中，我特意用星型模型標注了數據倉庫的 schema.

很好看懂，中間一顆星，周圍直聯其他星星，有且只有一級聯系。這就是 Kimball 數據模型的精髓所在。與 Inmon 最大的區別，也就在這里。Inmon 的數據模型都是ER模型，范式用到了極致。

我們來看 Kimball 的星型模型維度建模：

很直觀，圍繞著SalesOrder（銷售訂單）業務，假設有三個維度（即影響訂單的三個因素，實際上遠不止3個，300個都有，互聯網甚至還有3000個）Employee, Time, Components，即人，貨，時。

人的維度，還包括了人所在的部門，地址和職級；時間維度，算簡單的一個，實際應用中，會有多個記賬周期，時間略有復雜；貨的維度，就是商品，有廠家，地址，廠長和商品本身的屬性，大小，顏色等等。

這就是很多入門的同學迷糊的地方，為什么在一個表里，會有很多看似冗余的數據，為什么不按照三范式拆出來呢？這里有個特別重要的原理，那就是空間換時間。

當所有的屬性都拿來做維度分析時，為了節省Join的時間，通常把這些維度屬性預先計算好。即時查詢分析，用GroupBy去隨機分組統計數據，假如沒有合適的索引，會非常慢。為了提高效率，我們只能把這些組合的統計與聚合，預先計算好，存起來。大部分的 OLAP 引擎，都是基礎這個原理，比如SQL Server Cube, Kylin等。

Kimball 給這種數據模型，起了個名字，“星型模型”。作為最終的交付產品，是數據倉庫的靈魂。

Kimball 理論也沒有放棄數據集市，只不過他將數據集市放在ETL階段實現了，用的是另外一種模型，叫做“雪花模型”。功能與 Inmon 的數據集市類似，實際上，數據模型也一致，就是標準的ER模型，即三范式結構。

人的維度上，只保留人本身的屬性，比如性別，身高，年齡等，其他附屬屬性，比如地址，部門，職級，都分別存在不同的子表里面。其他兩個維度也一樣，自留屬性與附加屬性都分別存儲。這樣一個壞處，就是Join比較多，而且容易造成性能緩慢。

那么現實中，我們該用哪種理論來設計數據倉庫的架構呢，用哪種數據模型來建模呢

現實世界沒有銀彈，一切取決于所在業務的復雜度。Kimball 理論顯然更適合BI套件，但留下冗余數據處理的復雜；Inmon 解決了數據一致性問題，但性能又是老大難的問題。

順便說下，阿里巴巴的大數據實踐，在第三階段，也采用了 Kimball 數據模型方法論。可見，即便是在互聯網應用，數倉的眾多模型也是通用的。具體參考這本書《大數據之路-阿里巴巴大數據實踐》

--完--

往期精彩：

本號精華合集（二）

如何寫好 5000 行的 SQL 代碼

如何提高閱讀 SQL 源代碼的快感

我在面試數據庫工程師候選人時，常問的一些題

零基礎 SQL 數據庫小白，從入門到精通的學習路線與書單

總結

以上是生活随笔為你收集整理的看数据模型界两大长老的神仙打架的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。