第2章 數據倉庫設計基礎
2.1 關系數據模型
2.1.1 關系數據模型中的結構
6．關系表的屬性
關系表有如下屬性：
● 每個表都有唯一的名稱。
● 一個表中每個列有不同的名字。
● 一個列的值來自于相同的屬性域。
● 列是無序的。
● 行是無序的。
7．關系數據模型中的鍵
（1）超鍵
一個列或者列集，唯一標識表中的一條記錄。超鍵可能包含用于唯一標識記錄所不必要的額外的列，我們通常只對僅包含能夠唯一標識記錄的最小數量的列感興趣。
【舉例】
表一：學號、姓名、性別、身份證號、教室號
表二：教室號、班主任
超鍵：我們可以使用（學號、姓名）的組合鍵來確定性別屬性，則（學號、姓名）就是超鍵。
候選鍵：就是將超鍵中的多余屬性去除掉，我們其實可以使用學號來確定性別，這時候，學號就是候選鍵。
主鍵：學號和身份證號都能夠唯一確定性別，但是我們只會選擇其中的一個來充當主鍵。
外鍵：就是表一的教室號是外鍵，關聯的是表二的教室號。
（2）候選鍵
僅包含唯一標識記錄所必需的最小數量列的超鍵。
表的候選鍵有三個屬性：
● 唯一性：在每條記錄中，候選鍵的值唯一標識該記錄。
● 最小性：具有唯一性屬性的超鍵的最小子集。
● 非空性：候選鍵的值不允許為空。
在我們的例子中，分公司編號是候選鍵，如果每個分公司的郵編都不同，那么郵編也可以作為分公司表的候選鍵。一個表中允許有多個候選鍵。
（3）主鍵
唯一標識表中記錄的候選鍵。主鍵是唯一、非空的。沒有被選做主鍵的候選鍵稱為備用鍵。對于例子中的分公司表，分公司編號是主鍵，郵編就是備用鍵，而員工表的主鍵是員工編號。
主鍵的選擇在關系數據模型中非常重要，很多性能問題都是由于主鍵選擇不當引起的。在選擇主鍵時，我們可以參考以下原則：
● 主鍵要盡可能地小。
● 主鍵值不應該被改變。主鍵會被其他表所引用。如果改變了主鍵的值，所有引用該主鍵的值都需要修改，否則引用就是無效的。
● 主鍵通常使用數字類型。數字類型的主鍵要比其他數據類型效率更高。
● 主鍵應該是沒有業務含義的，它不應包含實際的業務信息。無意義的數字列不需要修改，因此是主鍵的理想選擇。大部分關系型數據庫支持的自增屬性或序列對象更適合當作主鍵。
● 雖然主鍵允許由多列組成，但應該使用盡可能少的列，最好是單列。
（4）外鍵
一個表中的一個列或多個列的集合，這些列匹配某些其他（也可以是同一個）表中的候選鍵。注意外鍵所引用的不一定是主鍵，但一定是候選鍵。當一列出現在兩張表中的時候，它通常代表兩張表記錄之間的關系。如例子中分公司表的分公司編號和員工表的所屬分公司。它們的名字雖然不同，但卻是同一含義。分公司表的分公司編號是主鍵，在員工表里所屬分公司是外鍵。同樣，因為公司經理也是公司員工，所以它是引用員工表的外鍵。主鍵所在的表被稱為父表，外鍵所在的表被稱為子表。
2.1.2 關系完整性
關系數據模型有兩個重要的完整性規則：實體完整性和參照完整性。
1．空值（NULL）
表示一個列的值目前還不知道或者對于當前記錄來說不可用。空值可以意味著未知，也可以意味著某個記錄沒有值，或者只是意味著該值還沒有提供。空值是處理不完整數據或異常數據的一種方式。
2．關系完整性規則
（1）實體完整性
在一個基本表中，主鍵列的取值不能為空。基本表指的是命名的表，其中的記錄物理地存儲在數據庫中，與之對應的是視圖。視圖是虛擬的表，它只是一個查詢語句的邏輯定義，其中并沒有物理存儲數據。
（2）參照完整性
如果表中存在外鍵，則外鍵值必須與主表中的某些記錄的候選鍵值相同，或者外鍵的值必須全部為空。在圖2-1中，員工表中的所屬分公司是外鍵。該列的值要么是分公司表的分公司編號列中的值，要么是空（如新員工已經加入了公司，但還沒有被分派到某個具體的分公司時）。
4．關系數據庫語言
關系數據庫的主要語言是SQL語言。
SQL是Structured Query Language的縮寫，意為結構化查詢語言。SQL已經被國際標準化組織（ISO）進行了標準化，使它成為正式的和事實上的定義和操縱關系數據庫的標準語言。
SQL語言又可分為DDL、DML、DCL、TCL四類。
DDL是Data Definition Language的縮寫，意為數據定義語言，用于定義數據庫結構和模式。典型的DDL有create、alter、drop、truncate、comment、rename等。
DML是Data Manipulation Language的縮寫，意為數據操縱語言，用于檢索、管理和維護數據庫對象。典型的DML有select、insert、update、delete、merge、call、explain、lock等。
DCL是Data Control Language的縮寫，意為數據控制語言，用于授予和回收數據庫對象上的權限。典型的DCL有grant和revoke。
TCL是Transaction Control Language的縮寫，意為事務控制語言，用于管理DML對數據的改變。它允許一組DML語句聯合成一個邏輯事務。典型的TCL有commit、rollback、savepoint、set transaction等。
2.1.3 規范化
沒有規范化，數據的更新處理將變得困難，異常的插入、修改、刪除數據的操作會頻繁發生。為了便于理解，來看下面的例子。
假設有一個名為employee的員工表，它有九個屬性：id（員工編號）、name（員工姓名）, mobile（電話）、zip（郵編）、province（省份）、city（城市）、district（區縣）、deptNo（所屬部門編號）、deptName（所屬部門名稱），表中的數據如表2-5所示。
為了克服這些異常更新，我們需要對表進行規范化設計。規范化是通過應用范式規則實現的。最常用的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。
(1) 第一范式(1NF)
表中的列只能含有原子性（不可再分）的值。
數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。
上例中張三有兩個手機號存儲在mobile列中，違反了1NF規則。為了使表滿足1NF，數據應該修改為如表2-6所示。
(2) 第二范式(2NF)
規則是符合第一范式，而且沒有部分主鍵功能決定其他屬性的現象，也就是主鍵之外的其他屬性都完全的功能相依于主鍵。
第二范式要同時滿足下面兩個條件：
● 滿足第一范式。
● 沒有部分依賴。
例如，員工表的一個候選鍵是{id, mobile, deptNo}，而deptName依賴于{deptNo}，同樣name僅依賴于{id}，因此不是2NF的。為了滿足第二范式的條件，需要將這個表拆分成employee、dept、employee_dept、employee_mobile四個表，如表2-7至表2-10所示。
(3) 第三范式(3NF)
第三范式要同時滿足下面兩個條件：
● 滿足第二范式。
● 沒有傳遞依賴。
例如，員工表的province、city、district依賴于zip，而zip依賴于{id}，換句話說，province、city、district傳遞依賴于{id}，違反了3NF規則。為了滿足第三范式的條件，可以將這個表拆分成employee和zip兩個表，如表2-11、表2-12所示。
在關系數據模型設計中，一般需要滿足第三范式的要求。如果一個表有良好的主外鍵設計，就應該是滿足3NF的表。規范化帶來的好處是通過減少數據冗余提高更新數據的效率，同時保證數據完整性。然而，我們在實際應用中也要防止過度規范化的問題。規范化程度越高，劃分的表就越多，在查詢數據時越有可能使用表連接操作。而如果連接的表過多，會影響查詢的性能。關鍵的問題是要依據業務需求，仔細權衡數據查詢和數據更新的關系，制定最適合的規范化程度。還有一點需要注意的是，不要為了遵循嚴格的規范化規則而修改業務需求。
(4) BCNF范式
BCNF范式(Boyce/Codd Normal Form)，是由R.F.Boycy和E.F. Codd共同提出的，可以算成是第三正則化的補充，規則是符合第三正則化原則，并且沒有非主鍵屬性可以功能性決定部分主鍵的現象。
假設有一個表R，其中的屬性有A，B，C，D，E，以A和B為復合主鍵，R={A，B，C，D，E}，如果存在有非主鍵屬性，比如說C可以功能性決定B，C→B，而B是主鍵的一部分，這時第三正則化是沒有辦法分辨出來這種錯誤的，所以有BCNF正則化規則來把關，同樣地，BCNF正則化的方法也是將原來的表拆開，成立一個新的關聯表R1來裝C→B，R1={C，B}，但原來的表R還是以(A，B)為復合主鍵，以B為外鍵關聯到新的表去，以保留原有的信息。
R={A,B,D,E}，R1={C,B}，R.B=R1.B
2.2 維度數據模型
維度數據模型簡稱維度模型（Dimensional modeling, DM），是一套技術和概念的集合，用于數據倉庫設計。
事實和維度是兩個維度模型中的核心概念。事實表示對業務數據的度量，而維度是觀察數據的角度。事實通常是數字類型的，可以進行聚合和計算，而維度通常是一組層次關系或描述信息，用來定義事實。例如，銷售金額是一個事實，而銷售時間、銷售的產品、購買的顧客、商店等都是銷售事實的維度。維度模型按照業務流程領域即主題域建立，例如進貨、銷售、庫存、配送等。不同的主題域可能共享某些維度，為了提高數據操作的性能和數據一致性，需要使用一致性維度，例如幾個主題域間共享維度的復制。術語“一致性維度”源自Kimball，指的是具有相同屬性和內容的維度。
2.2.1 維度數據模型建模過程
維度模型通常以一種被稱為星型模式的方式構建。所謂星型模式，就是以一個事實表為中心，周圍環繞著多個維度表。還有一種模式叫做雪花模式，是對維度做進一步規范化后形成的。
一般使用下面的過程構建維度模型：
● 選擇業務流程
● 聲明粒度
● 確認維度
● 確認事實
1．選擇業務流程
確認哪些業務處理流程是數據倉庫應該覆蓋的，是維度方法的基礎。因此，建模的第一個步驟是描述需要建模的業務流程。
為了描述業務流程，可以簡單地使用純文本將相關內容記錄下來，或者使用“業務流程建模標注”（BPMN）方法，也可以使用統一建模語言（UML）或其他類似的方法。
2．聲明粒度
在選擇維度和事實前必須聲明粒度，因為每個候選維度或事實必須與定義的粒度保持一致。
不同的事實可以有不同的粒度，但同一事實中不要混用多種不同的粒度。
3．確認維度
維度表是事實表的基礎，也說明了事實表的數據是從哪里采集來的。典型的維度都是名詞，如日期、商店、庫存等。維度表存儲了某一維度的所有相關數據，例如，日期維度應該包括年、季度、月、周、日等數據。
4．確認事實
大部分事實表的度量都是數字類型的，可累加，可計算，如成本、數量、金額等。
2.2.2 維度規范化
與關系模型類似，維度也可以進行規范化。對維度的規范化（又叫雪花化），可以去除冗余屬性，是對非規范化維度做的規范化處理。
總體來說，當多個維度共用某些通用的屬性時，做規范化會是有益的。例如，客戶和供應商都有省、市、區縣、街道等地理位置的屬性，此時分離出一個地區屬性就比較合適。
2.2.4 星型模式
星型模式是維度模型最簡單的形式，也是數據倉庫以及數據集市開發中使用最廣泛的形式。星型模式由事實表和維度表組成，一個星型模式中可以有一個或多個事實表，每個事實表引用任意數量的維度表。星型模式的物理模型像一顆星星的形狀，中心是一個事實表，圍繞在事實表周圍的維度表表示星星的放射狀分支，這就是星型模式這個名字的由來。
星型模式將業務流程分為事實和維度。事實包含業務的度量，是定量的數據，如銷售價格、銷售數量、距離、速度、重量等是事實。維度是對事實數據屬性的描述，如日期、產品、客戶、地理位置等是維度。一個含有很多維度表的星型模式有時被稱為蜈蚣模式，顯然這個名字也是因其形狀而得來的。
1．事實表
事實表記錄了特定事件的數字化的考量，一般由數字值和指向維度表的外鍵組成。通常會把事實表的粒度級別設計得比較低，使得事實表可以記錄很原始的操作型事件，但這樣做的負面影響是累加大量記錄可能會更耗時。事實表有以下三種類型：
● 事務事實表。記錄特定事件的事實，如銷售。
● 快照事實表。記錄給定時間點的事實，如月底賬戶余額。
● 累積事實表。記錄給定時間點的聚合事實，如當月的總的銷售金額。
一般需要給事實表設計一個代理鍵作為每行記錄的唯一標識。代理鍵是由系統生成的主鍵，它不是應用數據，沒有業務含義，對用戶來說是透明的。
2．維度表
維度表的記錄數通常比事實表少，但每條記錄包含有大量用于描述事實數據的屬性字段。
維度表可以定義各種各樣的特性，以下是幾種最長用的維度表：
● 時間維度表。描述星型模式中記錄的事件所發生的時間，具有所需的最低級別的時間粒度。數據倉庫是隨時間變化的數據集合，需要記錄數據的歷史，因此每個數據倉庫都需要一個時間維度表。
● 地理維度表。描述位置信息的數據，如國家、省份、城市、區縣、郵編等。
● 產品維度表。描述產品及其屬性。
● 人員維度表。描述人員相關的信息，如銷售人員、市場人員、開發人員等。
● 范圍維度表。描述分段數據的信息，如高級、中級、低級等。
通常給維度表設計一個單列、整型數字類型的代理鍵，映射業務數據中的主鍵。業務系統中的主鍵本身可能是自然鍵，也可能是代理鍵。自然鍵指的是由現實世界中已經存在的屬性組成的鍵，如身份證號就是典型的自然鍵。
5．示例
假設有一個連鎖店的銷售數據倉庫，記錄銷售相關的日期、商店和產品，其星型模式如圖2-3所示。
Fact_Sales是唯一的事實表，Dim_Date、Dim_Store和Dim_Product是三個維度表。每個維度表的Id字段是它們的主鍵。事實表的Date_Id、Store_Id、Product_Id三個字段構成了事實表的聯合主鍵，同時這個三個字段也是外鍵，分別引用對應的三個維度表的主鍵。Units_Sold是事實表的唯一一個非主鍵列，代表銷售量，是用于計算和分析的度量值。維度表的非主鍵列表示維度的附加屬性。下面的查詢可以回答2015年各個城市的手機銷量是多少。
2.2.5 雪花模式
雪花模式是一種多維模型中表的邏輯布局，其實體關系圖有類似于雪花的形狀，因此得名。與星型模式相同，雪花模式也是由事實表和維度表所組成。所謂的“雪花化”就是將星型模式中的維度表進行規范化處理。當所有的維度表完成規范化后，就形成了以事實表為中心的雪花型結構，即雪花模式。將維度表進行規范化的具體做法是，把低基數的屬性從維度表中移除并形成單獨的表。
星型模式和雪花模式都是建立維度數據倉庫或數據集市的常用方式，適用于加快查詢速度比高效維護數據的重要性更高的場景。這些模式中的表沒有特別的規范化，一般都被設計成一個低于第三范式的級別。
4．示例
圖2-4顯示的是將圖2-3的星型模式規范化后的雪花模式。日期維度分解成季度、月、周、日期四個表。產品維度分解成產品分類、產品兩個表。由商場維度分解出一個地區表。
圖2-4顯示的是將圖2-3的星型模式規范化后的雪花模式。日期維度分解成季度、月、周、日期四個表。產品維度分解成產品分類、產品兩個表。由商場維度分解出一個地區表。
下面所示的查詢語句的結果等價于前面星型模式的查詢，可以明顯看到此查詢比星型模式的查詢有更多的表連接。
2.3 Data Vault模型
參考
（1）Data Vault 數據倉庫模型構建-1
http://www.lxweimin.com/p/df3684c20092
（2）Data Vault初探（三） —— 建立Data Vault模型
https://blog.csdn.net/wzy0623/article/details/50222269
2.4 數據集市
2.4.1 數據集市的概念
數據集市是數據倉庫的一種簡單形式，通常由組織內的業務部門自己建立和控制。
2.4.2 數據集市與數據倉庫的區別
2.4.3 數據集市設計
數據集市主要用于部門級別的分析型應用，數據大都是經過了匯總和聚合操作，粒度級別較高。數據集市一般采用維度模型設計方法，數據結構使用星型模式或雪花模式。
正如前面所介紹的，設計維度模型先要確定維度表、事實表和數據粒度級別，下一步是使用主外鍵定義事實表和維度表之間的關系。數據集市中的主鍵最好使用系統生成的自增的單列數字型代理鍵。模型建立好之后，設計ETL步驟抽取操作型源系統的數據，經過數據清洗和轉換，最終裝載進數據集市中的維度表和事實表中。
2.5 數據倉庫實施步驟
1．定義范圍
首要任務是定義項目的范圍。項目范圍定義了一個數據倉庫項目的邊界。典型的范圍定義是組織、地區、應用、業務功能的聯合表示。定義范圍時通常需要權衡考慮資源（人員、系統、預算等）、進度（項目的時間和里程碑要求）、功能（數據倉庫承諾達到的能力）三方面的因素。定義好清晰明確的范圍，并得到所有項目干系人的一致認可，對項目的成功是非常重要的。項目范圍是設定正確的期望值、評估成本、估計風險、制定開發優先級的依據。
2．確定需求
數據倉庫項目的需求可以分為業務需求和技術需求。
（1）定義業務需求
與業務人員進行面對面的溝通，是理解業務流程的好方式。溝通的結果是使數據倉庫的業務需求更加明確。在為數據倉庫收集需求的過程中，還要考慮設計要能適應需求的變化。
（2）定義技術需求
需要知道如何清理操作型數據，如何移除垃圾數據，如何將來自多個源系統的相同數據整合在一起。另外，還要確認數據的更新頻率。
3．邏輯設計
下面就要進入數據倉庫的邏輯設計階段。邏輯設計過程中，需要定義特定數據的具體內容，數據之間的關系，支持數據倉庫的系統環境等，本質是發現邏輯對象之間的關系。
（1）建立需要的數據列表
細化業務用戶的需求以形成數據元素列表。
（2）識別數據源
應該從最大最復雜的源系統開始，在必要時再查找其他源系統。
（3）制作實體關系圖
邏輯設計的交付物是實體關系圖（entity-relationshipdiagram，簡稱ERD）和對它的說明文檔（數據字典）。實體對應關系數據庫中的表，屬性對應關系數據庫中的列。ERD傳統上與高度規范化的關系模型聯系密切，但該技術在維度模型中也被廣泛使用。在維度模型的ERD中，實體由事實表和維度表組成，關系體現為在事實表中引用維度表的主鍵。因此先要確認哪些信息屬于中心事實表，哪些信息屬于相關的維度表。維度模型中表的規范化級別通常低于關系模型中的表。
4．物理設計
物理設計指的是將邏輯設計的對象集合，轉化為一個物理數據庫，包括所有的表、索引、約束、視圖等。
5．裝載數據
這個步驟實際上涉及整個ETL過程。需要執行的任務包括：源和目標結構之間建立映射關系；從源系統抽取數據；對數據進行清洗和轉換；將數據裝載進數據倉庫；創建并存儲元數據。
6．訪問數據
訪問步驟是要使數據倉庫的數據可以被使用，使用的方式包括：數據查詢、數據分析、建立報表圖表、數據發布等。根據采用的數據倉庫架構，可能會引入數據集市的創建。通常，最終用戶會使用圖形化的前端工具向數據庫提交查詢，并顯示查詢結果。
7．管理維護
這個步驟涵蓋在數據倉庫整個生命周期里的管理和維護工作。這步需要執行的任務包括：確保對數據的安全訪問、管理數據增長、優化系統以獲得更好的性能、保證系統的可用性和可恢復性等。
更多信息請參考作者書籍內容，可各大平臺在線購買。
