數倉模型案例
一、範式建模
1.零範式
爲便於分級說明三範式的特點，我們將不滿足任何範式即無範式的數據稱爲零範式，假設它只滿足一個最基本的條件——數據中不存在重複數據。
假設根據零範式的定義數據庫中有一張保險訂單統計表，表中包含了用戶id、保險id、用戶名、註冊省份、註冊城市、註冊區縣、保險名稱、購買信息(價格、數量)、總保費、購買日期。具體情況如下圖：
2.一範式
在零範式的基礎上加上字段具有原子性即屬性不可分這個條件後便形成了符合一範式的表。基於上面的保險訂單統計表一範式和零範式的區別主要在於將表中的“購買信息”這個字段進行了拆分，形成了“保險價格”和“購買數量”兩個字段，這樣的數據表我們稱其滿足一範式。
3.二範式
相對於一範式，二範式的條件更爲嚴苛。如果要滿足二範式，則數據表需要確保每一列都和主鍵完全相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言，我們這裏的保險訂單統計表使用的即爲聯合主鍵）。
在保險訂單統計表中，購買數量、總保費和購買日期屬於完全依賴聯合主鍵（用戶ID，保險ID），但是保險名稱和保險價格只依賴於保險ID，用戶信息則只依賴於用戶ID，它們都屬於對主鍵部分依賴。顯然，這個時候保險訂單統計表不滿足二範式，下面對其進行調整。
將用戶信息和保險信息從原表中拆出來單獨建表存放，形成如下三張表：保險訂單統計表，保險信息表和用戶信息表。
4.三範式
三範式需要確保數據表中的每一個字段都直接依賴該表的主鍵，而不能間接依賴。經過二範式的拆解後，已經將最初的一張表變成了三張表。在這三張表中，我們發現用戶信息表中的用戶ID和註冊地址信息是存在傳遞依賴的，即：用戶ID決定地址ID，地址ID決定省份、城市、區縣，這屬於傳遞依賴。
因此，需要將用戶信息表地址信息表中的地址單獨拎出來才滿足三範式。
以上即爲三範式建模的一個大致流程，從上面的模型可以看出三範式建模可以最大限度避免數據的冗餘，同時整個業務看起來也更加清晰，不足點是使用起來需要多表關聯，不太方便。這類模型比較適合用於數倉公共層中的比較穩定的業務。
二、維度建模
維度建模主要以分析決策的目的進行模型構建，構建的數據模型爲分析需求提供服務，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。維度建模的核心部分爲事實表和維度表。
事實表：用於存儲某一主題下的主幹信息。比如上面的保險訂單統計，各個用戶保險的購買情況即爲該主題的主要關注內容。
維度表：指對事實表中主題進行分析的角度數據。比如保險維度表表和用戶維度。
用維度建模的方式進行設計，有如下三張表：保險訂單統計事實表、保險維度表和用戶維度表。這種設計，在範式理論上符合二範式，也稱爲反三範式。
使用維度建模形成的模型也稱爲星型模型，可以將事實表當作是中間最大的一顆星星，維度表圍繞在事實表周圍。星型模型進行擴展後可以形成雪花模型，兩者之間的主要區別在於維度表是否都和事實表直接相連。星型模型是將同一主題的維度信息冗餘在了一張維表中。雪花模型如下圖（其中購買月份還可以繼續拆分爲月和年的維表）：
有冗餘的事實表
維度建模中星型模型的設計符合範式建模中的二範式的設計，但是在實際工作中我們經常會在事實表中存放更多的信息，以便使用起來更方便。
如下圖，冗餘後的事實表的設計在範式建模中就只滿足一範式了。
三、數據倉庫和數據庫的側重點
在大部分的數據倉庫設計中，一般是不怎麼考慮是否滿足第幾範式的，特別是互聯網場景下的數據建設就更少考慮數據倉庫和範式之間的關係，但是這並不妨礙我們去理解它們設計背後的出發點。至少我們可以搞明白爲什麼數據倉庫設計不用過多關注範式。
我們這裏聊到的數據庫的設計，可以理解是聯機事務處理OLTP（On-Line Transaction Processing），主要是基本的、日常的事務處理，例如銀行交易。直白點講，就是各種增刪改查，需要對數據進行操作。而數據倉庫，我們可以理解爲是聯機分析處理OLAP（On-Line Analytical Processing），主要是面向日常數據分析，它的數據主要是插入和查詢，基本不涉及刪除和修改操作。
本文的主人公-範式，主要優化的是增刪改的問題，比如數據冗餘、更新異常、刪除異常等。這些也正是數據庫設計比較關注的點。而數據倉庫對這方面的關注度則比較少，數據倉庫更關注的是使用是否方便，查詢效率是否高，因此在設計數據倉庫的時候不必太多關注範式的設計，一般一範式或者二範式就已經夠用。
另外，數據倉庫不同層級的設計也會用到不同的建模方式，比如說接近業務數據的層次，會更傾向使用範式建模，接近數據分析的層次則會更傾向於維度建模。