模型設計，通俗理解就是如何去設計表，使得表與表之間的關係組成一張有規律的大網。
在上一節《所以，什麼是資料倉儲》中提及數倉建模的方法論，其中點出了兩位重要人物Kimball的維度建模和Inmon的3NF建模。在開始建設資料倉儲前，模型的選擇是最重要的一關之一，它是整個數倉中資料組織的基本骨架。在本節，我們整理了業界常用的四種建模方法詳細討論。
維度建模
Kimball提出的維度建模，是一種快速迭代和交付的模型建設方法。在目前眾多建模方法中備受推崇，因為無論從資料理解、模型構建或者是BI分析等方面都相對於其他建模方式好。又因為現代數倉大部分是基於Hadoop構建，允許以空間換時間，維度建模就漸漸變成了首選 —— 我會在後面章節詳細介紹這一建模方法。
特點
維度建模是通過高度冗餘維度表，以此提升開發者對資料的理解能力、提高資料一致性。又因為關聯少，可以減少下游ETL產生的I/O壓力，但缺點是浪費儲存。
概念
維度：看待事物的角度，如店鋪、使用者等
粒度：資料粒度，指結合多少個維度去看資料，如店鋪商品粒度（細粒度）、店鋪粒度（粗粒度）
事實：發生的某一件不可改變的事，如購買商品、訂單退貨等
度量：用來給事實發生的程度給定一個數字，如金額，長度，容量等
假設有這麼個需求：領導想看所有店鋪在昨天一天內成交的金額維度：店鋪，日期事實：成交度量：金額
模型圖
理想狀態下，維度建模呈現的是一個標準的星型模型，多個維度圍繞著事實表為中心。
一般來說，維度建模的設計過程如下：
- 選擇業務過程，如上圖的商品交易、商品退貨過程
- 宣告粒度
- 設計維度
- 設計事實
當新需求來時，我們都需要重走以上過程，來建立和豐富模型，如果業務過程不存在，則新建一套維度和事實與之對應；如果維度或者事實已經存在，請更新或者豐富表中的欄位即可，所以維度建模方式是一個不斷迭代，不斷完善的建模方法。
實際設計中可能會從某個維度表中再分拆一個子維度表，如商品維度表，可以再拆分品類維度表，用外來鍵依附於商品維度表，這種呈現方式稱為雪花模型。
DataVault建模
Data Vault（下面稱：DV）建模也是資料倉儲建模的一種方法，在《Hadoop構建資料倉儲實踐》一書中有詳細介紹。這種建模方式相對於維度建模來說，資料冗餘度少，能自動適應未來不可預見的業務關係（表和表的關係）變化。如果你的公司比較注重歷史資料的維護，或者是針對審計型（對資料作出證據蒐集及分析）的業務，在資料進入模型的時候又不想過多對資料邏輯進行正確與否的判斷的話，DV模型合適你。如果聽不明白上面說啥很正常，我們可以先了解這種模型能解決什麼問題！
其中重點摘錄1. 這種模型能最大限度的適應業務系統關係和關係間的變化。如：訂單-客戶 以往是 N:1 關係，但是目前已經有了拼單玩法，就變成了 1:N，如果業務變化後，我們 只需要在Link表裡增加記錄或者列即可，不需推倒重來2. DV不推薦做髒資料處理，它僅僅反映上游系統資料的真實性，也就是說資料正確與否都應該記錄到數倉裡面並讓他反映出來
特點
結構有點類似3NF，宣告中心表和連結表來構建實體與實體之間的關係，把實體的描述資訊全部放到衛星表中儲存。這種建模方法適用於：要儲存完完整整的歷史資料更改記錄的情況。所以基本上每一種表型別都有自己的代理鍵。
代理鍵：說白了就是通過資料加工方法，給表每一條記錄生成一個唯一的ID，用來表示其每一次的變化。
假設我們有一張商品表：ID ITEM_ID ITEM_NAME0000001 20391 Iphone 11-新貨上市！速購！0000002 20391 Iphone 11-雙卡雙待！來買！0000003 20391 Iphone 11-虧本賣！店主不要錢！這裡的代理鍵就是ID，業務主鍵就是ITEM_ID。
概念
如果 Hub 是人的骨架，那麼 Link 就是連線骨架的韌帶，Satellite 就是骨架上的血肉。
維度建模有維度和事實的概念，相同的，DV模型也有自己的一套“表型別”，其中包含三種表
- Hub：中心表，每個實體單獨建一箇中心表，每個中心表只有代理鍵、業務主鍵、裝載時間、資料來源四個欄位。中心表與中心表之間是平等關係，不存在父子關係。
|
欄位屬性
|
描述
|
|
主鍵
|
系統生成的代理鍵，供內部使用
|
|
業務主鍵
|
唯一標識的業務單元，用於已知業務的源系統
|
|
裝載時間
|
資料第一次裝載到資料倉儲時系統生成的時間戳
|
|
資料來源
|
定義了資料來源（例如源系統或表）
|
- Link：儲存不同的Hub（兩個或者以上）之間的關係，儲存實體表的代理鍵、失效標記、裝載時間、資料來源等。
|
屬性
|
描述
|
|
主鍵
|
系統生成的代理鍵，供內部使用
|
|
外來鍵{1-n}
|
引用中心表的代理鍵
|
|
裝載時間
|
資料第一次裝載到資料倉儲時系統生成的時間戳
|
|
資料來源
|
定義了資料來源（例如源系統或表）
|
- Satelites：衛星表，儲存Hub或者是Link的詳細描述。
|
屬性
|
描述
|
|
主鍵
|
系統生成的代理鍵，供內部使用
|
|
外來鍵
|
引用中心表的連結表的代理鍵
|
|
裝載時間
|
資料第一次裝載到資料倉儲時系統生成的時間戳
|
|
失效時間
|
資料失效時間的時間戳
|
|
資料來源
|
定義了資料來源（例如源系統或表）
|
|
屬性{1-n}
|
屬性自身
|
模型圖
3NF建模
資料倉儲之父 Bill INmon 提出的建模方法：從全企業的高度設計一個 3NF 模型，用實體關係（ER）模型描述企業業務，在正規化理論上符合 3NF。
資料倉儲中的 3NF 和 OLTP 系統中的 3NF 的區別：資料倉儲的 3NF 是站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體物件關係的抽象。
資料倉儲的 3NF 特點：
- 需要全面連線企業業務和資料；
- 實施週期非常長；
- 節省儲存，資料高度精簡；
- 對建模人員的要求較高；
- 採用 ER 模型建設資料倉儲模型的出發點是整合資料，將各個系統中的資料以整個企業角度按主題進行相似性組合和合並，並進行一致性處理，為資料分析決策服務，但並不能直接用於分析決策；
由於三正規化建模在企業中不常用，應用面不廣而且沒什麼難度，所以這裡就不展開討論了。不過可以順便回顧一下什麼是3NF。
我們在設計OLTP系統時要遵循3NF，這是關係型資料庫理論的基礎和指導方法。
第一正規化-1NF
強調列的原子性，要求列不能再切分。
例子：考慮這樣一個表【聯絡人】（姓名，性別，電話）
|
姓名
|
性別
|
電話
|
|
張三
|
男
|
1376776352，(020)-97698769
|
在實際場景中，一個聯絡人有家庭電話和公司電話，那麼這種表結構設計就沒有達到 1NF。要符合 1NF 我們只需把列（電話）拆分，
即：【聯絡人】（姓名，性別，家庭電話，公司電話）
|
姓名
|
性別
|
個人電話
|
家庭電話
|
|
張三
|
男
|
1376776352
|
(020)-97698769
|
第二正規化-2NF
在遵循1NF前提下，要求表必須有主鍵，且非主鍵列要完全依賴此主鍵，不能部分依賴。
例子：考慮訂單明細表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）
主鍵為（OrderID，ProductID），明顯看出，標紅的幾個列是隻依賴於主鍵之一的ProductID，所以（UnitPrice，ProductName）屬於冗餘欄位，不符合2NF。
解決辦法：【OrderDetail】表拆分為
【OrderDetail】（OrderID，ProductID，Discount，Quantity）和
【Product】（ProductID，UnitPrice，ProductName）
第三正規化-3NF
在遵循2NF前提下，要求非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。
例子：考慮一個訂單表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主鍵是（OrderID），CustomerName，CustomerAddr，CustomerCity 直接依賴的是 CustomerID（非主鍵列），而不是直接依賴於主鍵，它是通過傳遞才依賴於主鍵，所以不符合 3NF。企業應該把這種外戚排除掉！
Anchor建模
太少人用了，這裡不展開說。
Anchor模型由Lars. Rönnbäck提出，是DataVault模型的進一步正規化化處理，核心思想是隻新增、不修改的可擴充套件模型，Anchor模型構建的表極窄，類似於K-V結構化模型。它主要包括Anchors（實體且只有主鍵），Atributes（屬性），Ties（關係），Knots（公用列舉屬性)）。Anchor是應用中比較少的建模方法，只有傳統企業和少數幾家網際網路公司有應用，例如：螞蜂窩等。
總結
資料倉儲的建模方式大體來說就以上幾種，在日益發展的技術水平、資料爆炸和儲存成本降低的趨勢中，維度建模是最多公司使用的。每個公司都需要按照實際情況選擇合適的模型，不過，萬變不離其宗，量體裁衣，從人力成本、資料使用成本、儲存成本、加工複雜度等角度權衡，一定能找到適合自己的“大網”。