長期從事資料倉儲的你，是否還記得資料庫設計中的三大正規化？在設計資料倉儲的表時，是否考慮過規範化和反規範化之間的區別？是否想過資料倉儲和資料庫在設計中對正規化考慮的側重點是什麼？
一起回顧資料庫設計中經典的三大正規化
聊一聊資料倉儲和正規化之間的關係
聊一聊資料倉儲和資料庫在正規化設計中的側重點
全文將會圍繞乙個訂單表（假設乙個訂單中只有一種商品出現）設計的例子，既有資料庫中表的設計，亦有資料倉儲中表的設計，乙個例子貫穿全文，有始有終，簡單易懂。
首先回顧一下正規化是什麼：
設計關聯式資料庫時，遵從不同的規範要求，設計出合理的關係型資料庫，這些不同的規範要求被稱為不同的正規化，各種正規化呈遞次規範，越高的正規化資料庫冗餘越小。目前關聯式資料庫有六種正規化：第一正規化（1nf）、第二正規化（2nf）、第三正規化（3nf）、巴斯-科德正規化（bcnf）、第四正規化(4nf）和第五正規化（5nf，又稱完美正規化）。
我們暫且將第一種設計稱為第零正規化，它滿足乙個基本條件：無重複資料。
如下，是我們按照無正規化設計的第一張訂單表。雖說該設計將成為乙個被挑毛病的壞孩子，但從設計上來看，仍是可被理解的。
該設計和第零正規化的區別在於我們將「購買資訊」這乙個字段拆成了「購買單價」和「購買數量」兩個字段，新錶滿足了第一正規化。
第二正規化在第一正規化的基礎之上更進一層。第二正規化需要確保資料庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。即在第一正規化的基礎上滿足屬性完全依賴於主鍵。
以第一正規化中的設計為例，商品數量、總金額和購買日期是完全依賴於（使用者id，商品id）的，但是商品名和商品**只依賴於商品id，使用者資訊只依賴於使用者id，這屬於部分依賴。
因此，將使用者資訊和商品資訊單獨拎出來後，我們的訂單表設計就變成了如下三張表：訂單表，商品表和使用者表。直觀一點來理解第二正規化的話，就是說乙個資料表中只能儲存一種資料，不可以把多種資料儲存在同一張資料庫表中。
第三正規化需要確保資料表中的每一列資料都和主鍵直接相關，而不能間接相關。即在第二正規化的基礎上滿足屬性只直接依賴主鍵。
以第二正規化中的設計為例，現在訂單表中的資訊已經完全依賴於訂單id了，該設計是滿足第二正規化的。但是在使用者表中，使用者id和位址資訊是存在傳遞依賴的，即：使用者id決定位址id，位址id決定（省，市，縣），這是傳遞依賴。
因此，我在位址資訊表單獨拎出來之後就可以設計出如下滿足第三正規化的表了。
0x02 資料倉儲和三正規化
以上，簡單回顧了一下三正規化的內容，下面將分析一下資料倉儲中的資料建模和三正規化之間的關係。
正規化建模是資料倉儲之父 bill lnmon 提出的建模方法是從全企業的高度設計乙個第三正規化的模型，用實體關係（entity relationship, er）模型描述企業業務，在正規化理論上符合第三正規化。
因此我們可以認為資料倉儲中的正規化建模，在表的設計上和正規化中的第三正規化基本上一致的，具體到表的設計是可以如下內容。
維度模型是資料倉儲領域另一位大師 ralph kimball 所倡導，維度建模以分析決策的需求出發構建模型，構建的資料模型為分析需求服務，因此它重點解決使用者如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應效能。
維度建模的理論就不再細說，我們只介紹兩個主要概念：事實表和維度表。
事實表：我們可以簡單地將事實理解為現實中發生的一次操作型事件。比如訂單表，我們就可以理解為一張事實表，我們每完成乙個訂單，就會在訂單事實表中增加一條記錄。那麼用維度建模的方式進行設計的話，我們會設計如下三張表：訂單事實表、商品維度表和使用者維度表。這種設計，在正規化理論上符合第二正規化。一般大家也會稱維度建模是星星模型，可以將事實表當作是中間最大的一顆星星，維度表圍繞在事實表周圍。星星模型和雪花模型的主要區別在於維度表是否都和事實表直接相連。如下圖，將我們的星星模型轉換成了雪花模型，比如年維度表並不是直接連在訂單事實表上，而是連在日期維度表上。
因此，簡單點來講，我們可以認為星星模型是將同一主題的維度資訊冗餘在了一張維表中。
在維度建模中我們聊到了事實表的設計，它其實是符合第二正規化的設計，但是在實際工作中我們經常會在事實表中存放更多的資訊，以便更好地滿足業務需求。
如下圖，我們會將使用者資訊和商品資訊都冗餘到訂單事實表中，在這種情況下，該事實表的設計在正規化理論上符合第一正規化。
在大部分的資料倉儲設計中，一般是不怎麼考慮是否滿足第幾正規化的，特別是網際網路場景下的資料建設就更少考慮資料倉儲和正規化之間的關係，但是這並不妨礙我們去理解它們設計背後的出發點。至少我們可以搞明白為什麼資料倉儲設計不用過多關注正規化。
我們這裡聊到的資料庫的設計，可以理解是聯機事務處理oltp（on-line transaction processing），主要是基本的、日常的事務處理，例如銀行交易。直白點講，就是各種增刪改查，需要對資料進行操作。而資料倉儲，我們可以理解為是聯機分析處理olap（on-line analytical processing），主要是面向日常資料分析，它的資料主要是插入和查詢，基本不涉及刪除和修改操作。
本文的主人公-正規化，主要優化的是增刪改的問題，比如資料冗餘、更新異常、刪除異常等。這些也正是資料庫設計比較關注的點。而資料倉儲對這方面的關注度則比較少，資料倉儲更關注的是使用是否方便，查詢效率是否高，因此在設計資料倉儲的時候不必太多關注正規化的設計，一般第一或者第二正規化就夠用。
另外，資料倉儲不同層級的設計也會用到不同的建模方式，比如說接近業務資料的層次，會更傾向使用正規化建模，接近資料分析的層次則會更傾向於維度建模，這個話題會在資料分層的文章中有更詳細的講解。
資料倉儲 資料倉儲部署
1 首先用下面的語句查詢是否有要建立的表空間 hospdw tab 和 hospdw idx 如果沒有，則把d database zyhip改為對應的路徑，有的話直接建立使用者 select tablespace name,file name,round bytes 1024 1024 0 size...
資料倉儲入門基礎 1 漫談數倉
資料倉儲，英文名稱為data warehouse，可簡寫為dw或dwh。資料倉儲，是為企業所有級別的決策制定過程，提供所有型別資料支援的戰略集合。它是單個資料儲存，出於分析性報告和決策支援目的而建立。為需要業務智慧型的企業，提供指導業務流程改進 監視時間 成本 質量以及控制。資料倉儲的特徵在於面向主...
資料倉儲,什麼是資料倉儲？
資料倉儲，英文名稱為data warehouse，可簡寫為dw或dwh。資料倉儲是為企業所有級別的決策制定過程提供支援的所有型別資料的戰略集合。它是單個資料儲存，出於分析性報告和決策支援的目的而建立。為企業提供需要業務智慧型來指導業務流程改進和監視時間 成本 質量和控制。資料倉儲是決策支援系統 ds...