文章目錄
歡迎訪問筆者個人技術博客：http://rukihuang.xyz/
學習視頻來源於尚硅谷，視頻鏈接：尚硅谷大數據項目數據倉庫,電商數倉V1.2新版，Respect！
1 數倉分層
1.1 基本分層模型
- 分層原因：
- 把複雜問題簡單化：將複雜的任務分解成多層來完成，每一層只處理簡單任務，方便定位問題。
- 減少重複開發：規範數據分層，通過中間層數據，能夠減少大量的重複計算，增加一次計算結果的複用性。
- 隔離原始數據：不論是數據的異常還是數據的敏感性，使真實數據與統計數據隔離開。
1.2 數據集市和數據倉庫
- 數據集市：部門級。一種微型的數據倉庫，通常具有更少的數據，更少的主題區域，以及更少的歷史數據。
- 數據倉庫：企業級。能爲整個企業各個部門運轉提供決策支持手段。
2 數倉理論
2.1 範式理論
詳見過往文章對範式理論的解釋：Java Web 02 — MySQL_02（數據庫的設計、數據庫的備份和還原、多表查詢、事務、DCL）
- 第一範式1NF：屬性不可切割
- 第二範式2NF：不能存在部分函數依賴
- 第三範式3NF：不能存在傳遞函數依賴
2.2 關係建模和維度建模
- 當今的數據處理大致可以分爲2類：聯機事務處理OLTP （ on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP 是傳統的關係型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP 是數據倉庫系統的主要應用，支持複雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。二者的主要區別對比如下表所示。
| 對比屬性 | OLTP | OLAP |
|---|---|---|
| 讀特性 | 每次查詢只返回少量數據 | 對大量數據進行彙總 |
| 寫特性 | 隨機、低延時寫入用戶的輸入 | 批量導入 |
| 使用場景 | 用戶，JavaEE項目 | 內部分析師，爲決策提供支持 |
| 數據表徵 | 最新數據狀態 | 隨時間變化的歷史狀態 |
| 數據規模 | GB | TB、PB |
2.2.1 關係建模
- 關係模型如圖所示，嚴格遵循第三範式（3NF），從圖中可以看出，較爲鬆散、零碎，物理表數量多，而數據冗餘程度低。由於數據分佈於衆多的表中，這些數據可以更爲靈活地被應用，功能性較強。關係模型主要應用與OLTP 系統中，爲了保證數據的一致性以及避免冗餘，所以大部分業務系統的表都是遵循第三範式的。
2.2.2 維度建模
- 維度模型如圖所示，主要應用於OLAP 系統中，通常以某一個事實表爲中心進行表的組織，主要面向業務，特徵是可能存在數據的冗餘，但是能方便的得到數據。
- 關係模型雖然冗餘少，但是在大規模數據，跨表分析統計查詢過程中，會造成多表關聯，這會大大降低執行效率。所以通常我們採用維度模型建模，把相關各種表整理成兩種：事實表和維度表兩種。
2.2.2.1 維度建模的三種模型
- 星型模型：事實表周圍只有一層維度表
- 雪花模型：維度表有多個層級
- 星座模型：多張事實表
2.3 維度表和事實表
2.3.1 維度表
- 維度表：一般是對事實的描述信息。每一張維表對應顯示世界中的一個對象或者概念。
- 維度表特徵：
- 維度的範圍很寬（具有多個屬性，多個列）
- 和事實表相比，行數相對少
- 內容相對固定：編碼表
- 如商品信息表，每一行表示一種商品的具體特徵和概念（小米手機，128G，白色，4999元）
2.3.2 事實表
- 每一個事實表的行包括：具有可加性的數值型的度量值、與維表相連接的外鍵、通常具有兩個和兩個以上的外鍵、外鍵之間表示維表之間多對多的關係。可統計的
- 特徵：
- 非常大
- 內容相對窄（列數少）
- 經常發生變化，每天會新增很多
- 如訂單表（小明，小米手機，4999元，優惠券200元，下單時間20200521 09：00）