數據倉庫和範式

0x00 概述

長期從事數據倉庫的你，是否還記得數據庫設計中的三大範式？在設計數據倉庫的表時，是否考慮過規範化和反規範化之間的區別？是否想過數據倉庫和數據庫在設計中對範式考慮的側重點是什麼？

本文，將包含以下幾個方面：

1. 一塊兒回顧數據庫設計中經典的三大範式
2. 聊一聊數據倉庫和範式之間的關係
3. 聊一聊數據倉庫和數據庫在範式設計中的側重點

全文將會圍繞一個訂單表（假設一個訂單中只有一種商品出現）設計的例子，既有數據庫中表的設計，亦有數據倉庫中表的設計，一個例子貫穿全文，善始善終，簡單易懂。

0x01 三範式

首先回顧一下範式是什麼：

設計關係數據庫時，聽從不一樣的規範要求，設計出合理的關係型數據庫，這些不一樣的規範要求被稱爲不一樣的範式，各類範式呈遞次規範，越高的範式數據庫冗餘越小。

目前關係數據庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。

數據庫範式有這麼多，可是在工做中經常使用到的通常是前三個範式，所以，本文將只舉例分享第1、2、三範式。爲了方便理解，先上一個關於各個範式核心點的圖鎮樓，後面的說明會參考該圖來進行。

 

 

第零範式

咱們暫且將第一種設計稱爲第零範式，它知足一個基本條件：無重複數據。

以下，是咱們按照無範式設計的第一張訂單表。雖然說該設計將成爲一個被挑毛病的壞孩子，但從設計上來看，還是可被理解的。

 

第一範式

第一範式的核心在於 Atomic colums（cells have single value），即屬性不可分。

該設計和第零範式的區別在於咱們將「購買信息」這一個字段拆成了「購買單價」和「購買數量」兩個字段，新表知足了第一範式。

 

 

第二範式

第二範式在第一範式的基礎之上更進一層。第二範式須要確保數據庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。即在第一範式的基礎上知足屬性徹底依賴於主鍵。

以第一範式中的設計爲例，商品數量、總金額和購買日期是徹底依賴於（用戶ID，商品ID）的，可是商品名和商品價格只依賴於商品ID，用戶信息只依賴於用戶ID，這屬於部分依賴。

所以，將用戶信息和商品信息單獨拎出來後，咱們的訂單表設計就變成了以下三張表：訂單表，商品表和用戶表。直觀一點來理解第二範式的話，就是說一個數據表中只能保存一種數據，不能夠把多種數據保存在同一張數據庫表中。

 

 

第三範式

第三範式須要確保數據表中的每一列數據都和主鍵直接相關，而不能間接相關。即在第二範式的基礎上知足屬性只直接依賴主鍵。

以第二範式中的設計爲例，如今訂單表中的信息已經徹底依賴於訂單ID了，該設計是知足第二範式的。可是在用戶表中，用戶ID和地址信息是存在傳遞依賴的，即：用戶ID決定地址ID，地址ID決定（省，市，縣），這是傳遞依賴。

所以，我在地址信息表單獨拎出來以後就能夠設計出以下知足第三範式的表了。

 

0x02 數據倉庫和三範式

以上，簡單回顧了一下三範式的內容，下面將分析一下數據倉庫中的數據建模和三範式之間的關係。

 

 

範式建模

範式建模是數據倉庫之父 Bill lnmon 提出的建模方法是從全企業的高度設計一個第三範式的模型，用實體關係（Entity Relationship, ER）模型描述企業業務，在範式理論上符合第三範式。

所以咱們能夠認爲數據倉庫中的範式建模，在表的設計上和範式中的第三範式基本上一致的，具體到表的設計是能夠以下內容。

 

 

 

維度建模

維度模型是數據倉庫領域另外一位大師 Ralph Kimball 所倡導，維度建模以分析決策的需求出發構建模型，構建的數據模型爲分析需求服務，所以它重點解決用戶如何更快速完成分析需求，同時還有較好的大規模複雜查詢的響應性能。

維度建模的理論就再也不細說，咱們只介紹兩個主要概念：事實表和維度表。

 

事實表：咱們能夠簡單地將事實理解爲現實中發生的一次操做型事件。好比訂單表，咱們就能夠理解爲一張事實表，咱們每完成一個訂單，就會在訂單事實表中增長一條記錄。

維度表：咱們能夠簡單地理解維度表包含了事實表中指定屬性的相關詳細信息。好比商品維度表表和用戶維度表。

 

那麼用維度建模的方式進行設計的話，咱們會設計以下三張表：訂單事實表、商品維度表和用戶維度表。這種設計，在範式理論上符合第二範式。

 

 

通常你們也會稱維度建模是星星模型，能夠將事實表看成是中間最大的一顆星星，維度表圍繞在事實表周圍。星星模型和雪花模型的主要區別在於維度表是否都和事實表直接相連。以下圖，將咱們的星星模型轉換成了雪花模型，好比年維度表並非直接連在訂單事實表上，而是連在日期維度表上。

所以，簡單點來說，咱們能夠認爲星星模型是將同一主題的維度信息冗餘在了一張維表中。

 

有冗餘的事實表

在維度建模中咱們聊到了事實表的設計，它實際上是符合第二範式的設計，可是在實際工做中咱們常常會在事實表中存放更多的信息，以便更好地知足業務需求。

以下圖，咱們會將用戶信息和商品信息都冗餘到訂單事實表中，在這種狀況下，該事實表的設計在範式理論上符合第一範式。

 

 

0x03 數據倉庫和數據庫的側重點

在大部分的數據倉庫設計中，通常是不怎麼考慮是否知足第幾範式的，特別是互聯網場景下的數據建設就更少考慮數據倉庫和範式之間的關係，可是這並不妨礙咱們去理解它們設計背後的出發點。至少咱們能夠搞明白爲何數據倉庫設計不用過多關注範式。

咱們這裏聊到的數據庫的設計，能夠理解是聯機事務處理OLTP（On-Line Transaction Processing），主要是基本的、平常的事務處理，例如銀行交易。直白點講，就是各類增刪改查，須要對數據進行操做。而數據倉庫，咱們能夠理解爲是聯機分析處理OLAP（On-Line Analytical Processing），主要是面向平常數據分析，它的數據主要是插入和查詢，基本不涉及刪除和修改操做。

本文的主人公-範式，主要優化的是增刪改的問題，好比數據冗餘、更新異常、刪除異常等。這些也正是數據庫設計比較關注的點。而數據倉庫對這方面的關注度則比較少，數據倉庫更關注的是使用是否方便，查詢效率是否高，所以在設計數據倉庫的時候沒必要太多關注範式的設計，通常第一或者第二範式就夠用。

另外，數據倉庫不一樣層級的設計也會用到不一樣的建模方式，好比說接近業務數據的層次，會更傾向使用範式建模，接近數據分析的層次則會更傾向於維度建模，這個話題會在數據分層的文章中有更詳細的講解。

 

 

0xFF 總結

本文主要是聊一聊數據倉庫和範式之間的關係，算是對數據倉庫相關理論的一種梳理。雖然說對平常工做的影響不大，可是仍能夠做爲補充知識的學習。