《Building the Data Warehouse》（數據倉庫 第四版）拆書稿-關係模型（3NF範式建模）重要知識點

拆書稿：《Building the Data Warehouse》（數據倉庫 第四版）

最近覆盤數據倉庫的相關技術，在網上搜了好多關於數倉的帖子，看完之後就是感覺有肉無血，串不起來。因爲好多都是介紹數倉的兩種建模基本理論，但是付諸於實踐的時候感覺還是無從下手。所以才決心整理一下自己這幾年的數倉經驗。分享給大家，剛開始寫帖子，有需要改進的地方大家可以留言給我，或者有什麼需要反饋的問題都可以給我留言或者評論。

閱讀建議：全文可能比較長，建議先收藏在細讀

前言

數據倉庫可能大家非常熟悉的兩位建模理論的創始人：William H.Inmon 和 Ralph Kimball，對應的 Inmon 主要的模型是：實體-關係模型， Kimball主導的模型是：維度模型

本片文章的目錄：

0.數據庫三範式回顧
1.《Building the Data Warehouse》的目錄
2.全書摘要（個人見解）
3. 重要章節技術點詳細講解
    第二章 數據倉庫環境
           粒度
           分區
    第三章 設計數據倉庫
           數據倉庫與數據模型
           規範化與反向規範化
           元數據
           數據週期
           轉換和集成
           星形連接
           四類ODS
    第四章： 數據倉庫中的粒度
    第六章： 分佈式數據倉庫
    第十三章 關係模型和多維模型數據庫設計基礎
4. 全書重點章節的腦圖(由於圖片比較長所以放在最後顯示)

0.數據庫三範式回顧

• 第一範式： 保證數據表的原子性，就是列不可再分，保證不會出現重複的列。是關係模式規範化的最低要求
• 第二範式： 表的非主屬性完全依賴於主關鍵字，就是屬性依賴於主鍵。保證不會出現重複的行
• 第三範式： 所有的非主屬性依賴於主鍵，只能存在這一種依賴關係。（例如： 表字段：學號，姓名，班級，系名稱，系主任；其中系名稱和系主任存在新的函數依賴，並且不依賴與主鍵學號，所以不滿足第三範式）

1.《Building the Data Warehouse》的目錄

2.全書摘要

建造數據倉庫，開始於粒度和分區的設計，基於數據模型和ETL的流程控制才能完成。如果開發者想着大多數需求都明瞭之後纔開始工作，那麼這個倉庫是永遠建不起來的。所以，數據倉庫環境中反饋循環非常重要，在各方用戶和DSS分析員的反饋信息推動下循環調整才能使這個倉庫越來越健壯。

3.重要章節技術點詳細講解

第二章 數據倉庫環境

數據倉庫定義： 一個面向主題的，集成的，非易失的，隨時間變化的用來支持管理人員決策的數據集合。

數據倉庫是體系化環境的核心，是決策支持系統處理的基礎

數據倉庫面向在高層企業數據模型中已經定義好的企業主題域。典型的主題域有：

• 顧客
• 產品
• 交易或活動
• 政策
• 索賠
• 賬目

粒度： 指的是數據倉庫中數據單元的細節程度或者綜合程度的級別，細節程度越高，粒度級別就越低，細節程度越低，粒度級別就約高。
（個人思考：基於大數據時代背景，存儲成本越來越低，分佈式技術越來越成熟。在選取粒度時可以直接選取最低的粒度級別。便於後續的數據分析和數據建模）
雙重粒度： 可以提高存儲和訪問數據的效率。
（個人理解： 雙重粒度就是指數據粒度分層；例如：數據可以分爲明細層和彙總層。根據查詢需求從不同的數據粒度層級檢索數據。可以做到快速響應和靈活提取）

分區：是指把數據分散到可獨立處理的分離物理單元中去。在數據倉庫中不應該考慮是不是該分區的問題，而是如何實現分區的問題
爲何分區？ 因爲在運維人員和設計者在管理小的物理單元是要比管理大的物理單元時享有的更大的靈活性，並且在大的物理單元中進行重構，索引，全局掃描，監控的問題時無法輕鬆的進行。
一般的分區標準：

• 時間（是常用且必然的組成部分）
• 業務範圍
• 地理位置
• 組織單位

若粒度和分區都處理的很好的話，數據倉庫的設計與實現的其他問題幾乎都很容易解決

數據清理： 數據在數據倉庫中有自己的生命週期，所以數據清理也是數據倉庫設計過程中比較重要的一部分。一般的數據清理分爲兩類： 1.改變存儲介質，將數據壓縮備份或者從高性能介質轉移到大容量介質；2.真正的清除數據
數據倉庫中的錯誤數據處理：

（個人經驗：對於上述的異常數據，一般會採取方法一來解決，但是要比方法一更復雜一些。因爲5000元的這筆賬目就是髒數據，那麼是不應該存在於數據倉庫環境中的，在進入7月2日的數據集完成修改後，爲了保證數據一致性，通常會將所有牽連的數據集進行重新計算，並且計算週期應該從7月2日到8月15日）

第三章 設計數據倉庫

任何情況下，數據倉庫都應當以迭代的方式進行建造

a. 數據倉庫與數據模型

數據建模分爲三個層次： 高層建模（實體關係圖，或者ERD），中間層建模（數據項集成或DIS），底層建模（稱爲物理模型）

b. 規範化與反向規範化

數據模型處理的輸出是一系列表，每個表都有主鍵和屬性。有以下設計技術可以提高模型可用性：
1 合併表，節省I/O，將表歸類進行物理合並 ，使I/O代價最小化
2 創建數據數組，在表數據穩定，規範，並是按順序訪問時可以創建數據數組
3 有意引入冗餘數據，減少表間關聯的訪問開銷

4 根據訪問頻率可以將表進行拆分

5 建立創造性索引（創造性概要文件）
根據用戶感興趣的統計需求，或者數據維度篩選有特徵的數據集形成概要文件

6 參照完整性管理：在操作型環境中，參照完整性表現爲數據表之間的動態鏈接。

c.元數據

定義：關於數據的數據
一般，元數據存儲對一下各項進行了記錄：

1. 程序員所知的數據結構
2. DSS分析員所知的數據結構
3. 數據進入數據倉庫時進行的轉換
4. 數據模型
5. 數據模型和數據倉庫的關係
6. 抽取數據的歷史記錄

d.數據週期：

是指從操作型環境中的數據發生變化起，到這個變化反映到數據倉庫中所用的時間，以24小時的時間間隔以現有技術來說比較容易實現（T+1）

e.轉換和集成（從操作型環境到數據倉庫）

• 1 數據格式進行轉化（比如：時間統一轉成 YYYYMMDD格式 進行一致性處理，具有相同含義的數據項進行譯碼，編譯統一的，一直的全局度量標準。（例如：性別，可能在不同的數據來源中表現方式有0/1或者m/f或者x/y，進入數據倉庫後進行一致編碼：0/1））
• 2 數據清理： 取值範圍檢查、交叉記錄驗證、簡單的格式檢驗
• 3 是否存在數據依賴
• 4 記錄數據的轉化，重命名，篩選等操作變化的文檔
• 5 數據編碼的轉換

f.星形連接

用來管理載入數據集市中某個實體的大量數據的設計結構稱爲星形連接。類似於事實表關聯多個維度表，事實表代表發生的事件，維度表是事實表外鍵的所屬實體的詳細描述。星形連接普遍是存在於數據集市層，並且一般設計過程中事實表會存儲大部分編碼，維度表中會存儲編碼對應的中文。

g.數據倉庫和數據集市的關係

數據倉庫中的數據是粒度化的，數據集市中的數據是緊湊和綜合的，數據必須週期性的從數據倉庫流向數據集市。
數據集市是否可以替代數據倉庫？ 答案是否！
數據集市雖然開發週期短，在短時間內可以看到效果，但是從長遠角度看，數據集市永遠不可能替代數據倉庫。

• 數據集市是按照需求定製化建立的，代表的數據價值只侷限於需求的邊界範圍內
• 針對性較強，可能在市場，營銷，賬務等業務線的數據集市都是不同的。不可重用，沒有靈活性。並且容易產生數據孤島，數據價值表現的很侷限
• 數據集市的種類統計粒度可能不同，不利於數據分析

h.四類ODS：（根據更新的時間間隔）

• 第一類：從操作型到ODS數據更新是同步進行
• 第二類：從操作型到ODS數據更新是有2-3小時的間隔
• 第三類：從操作型到ODS數據更新的同步是在夜間完成
• 第四類：從數據倉庫到ODS的更新是不預先規劃的
  

第四章： 數據倉庫中的粒度

a.粗略估算存儲大小：

b. 確定粒度級別，全靠經驗或者一般都是最細粒度

c. 反饋循環

類比於PDCA循環，在第一版數據倉庫建造完成後，收集用戶反饋意見，並根據意見進行調整

第六章： 分佈式數據倉庫

類型：

• 1 局部數據倉庫和全局數據倉庫： 業務是在不同地域或者不同生產線上進行的
• 2 技術上分佈的數據倉庫, 邏輯上是一個整體數據倉庫，物理上有多個處理器進行並行計算（hive）
• 3 獨立演進的分佈式數據倉庫

第十三章 關係模型和多維模型數據庫設計基礎

關係模型： 通過使用關鍵字和外鍵在不同行的數據間建立關聯，數據是非冗餘的

最大優勢： 靈活性， 其次： 多功能性，支持多種視圖，具有適度變化的能力。

多維模型： 也叫星形連接，以事實表爲中心，維度表外圍，建立的星形連接

最大優勢： 訪問的高效性，適合用戶直接訪問

二者對比總結：

數據的生命週期

一般會通過訪問頻率判斷，如果數據長時間不被訪問或者已經經過2-3時間，除非業務需要，一般情況會將數據“歸檔”
歸檔： 表數據一般會直接進行數據庫側的日誌文件備份，然後清理錶的歷史數據

3.重要章節腦圖顯示