轉摘:http://blog.itpub.net/7600305/viewspace-931820/
《數據倉庫工具箱—維度建模的完全指南》是數據倉庫建模方面的經典著作， 1996年第一版出版被認為是數據倉庫方面具有里程碑意義的事件。作者kimballl是數據倉庫方面的權威，他將多年的數據倉庫建模實戰經驗、技巧融入本書。他提出的許多維度建模概念被廣泛應用於數據倉庫的設計和開發中。2002年本書出版了第二版。
這是一部非常好的數據倉庫建模的書，前后完整的讀了三遍，受益匪淺。
以下筆記將本按四個部分組織：一、數據倉庫體系結構和建模過程、技巧。二、維度表建模技術。三、事實表建模技術。四、行業建模經驗。
一、數據倉庫體系結構和建模過程、技巧
關鍵點：數據倉庫體系結構、維度建模的四個步驟、數據倉庫總線結構、一致性維度。
1、對於數據倉庫來說，業務需求是第一位的。
2、數據倉庫的目標：（1）、隨心所欲的訪問數據。直觀、明顯、簡單、易用、切割、合並、下鑽、上卷。（2）、一致的展現數據（相對於原來從多個系統中出來的報表不一致）。（3）、適應性、擴展性、可維護性。（4）、為領導決策提供支持。
3、數據倉庫的組成。源數據-->數據准備區-->數據倉庫（維度建模）-->數據聚集區（OLAP）-->展現。其中原系統到數據准備區屬於ETL過程。數據倉庫和數據聚集區本書稱為數據展示。展現本書稱為數據存取工具。
4、數據倉庫應特別注意的幾點特點：（1）、數據應該以維度的形式進行展示、存儲和訪問。（2）、數據倉庫中必須包含詳細的原子數據。（3）、必須采用共同的維度和事實表來建模。
5、數據倉庫采用使用維度建模的好處：易理解、查詢的高性能、修改的靈活性和可擴充性。
6、維度建模的擴展性。表現在三個方面：（1）、在現有的事實表中增加維度。（2）、在事實表中增加事實。（3）、在維度表中增加屬性。（第一章）
7、維度模型設計的四個步驟。（1）、選取業務（主題）。（2）、定於業務處理的粒度。（3）、選擇維度。（4）、選擇事實。
8、應優先為模型選擇有原子性的信息，因為原子性的數據提供了最大限度的靈活性，可以接受任何可能形式的約束。（第二章）
9、數據倉庫總線結構。實際上是一種增量建模方式，通過一致性維度來集成數據中心。數據總線矩陣：業務處理、公共維度。一級數據中心：衍生於單個基本源系統的數據中心，建議從一級數據中心開始建模，因為導致失敗的主要風險是ETL。合並數據中心：合並多個位於不同源系統的一級數據中心。（第三章）
10、維度建模復查。考慮的問題：粒度，日期維度，退化維度，維度屬性采用名稱而不是編碼，代理關鍵字，維度的多少。
11、維度建模常犯的錯誤：（1）、舍棄一致性維度和一致性事實表。（2）、事實表的粒度不采用原子型。（3）、基於報表來設計維度表。（4）、不使用代理關鍵字。（5）、忽視維度的變化的需求。（6）、將體系與體系層次分解成多個維度。（7）、在維度表中為節省空間而限制使用詳細的描述屬性。（8）、在事實表中放置用於約束與分組操作的文本屬性。（第十五章）
12、數據倉庫成功的五個前提：
（1）、擁有精明、強干的業務用戶。用戶應該對數據倉庫具有獨特的見解，堅信數據倉庫項目具有實現的價值。
（2）、機構必須存在建立數據倉庫堅實而有說服力的業務動機。
（3）、數據倉庫的可用性。
（4）、業務用戶與IT人員之間的溝通。
（5）、業務分析人員的分析文化，是基於圖形、數據還是直覺、傳聞和一時沖動。（第十六章）
二、維度表建模技巧
關鍵點：退化維度、代理關鍵字、一致性維度、漸變維度、角色模仿、雜項維度、微型維度、深度可變的層次建模方法、審計維度、多值維度解決辦法、異構產品解決辦法。
1、維度表傾向於將行數做得相當少，而將列數做的特別大。數據倉庫的能力直接與維度表的屬性的質量和深度成正比。
2、維度的屬性采用文字而不是編碼。
3、維度表通常是不規范的，幾乎總是用空間換取簡明性和可訪問性。（第一章）
4、日期維度，應包含星期、周末指示符、月末指示符、節假日指示符、重大事件、財政時間等。
5、如果需要處理一天中不同時間，則增加一個時間維度。
6、一個維度包含多個體系（層次），每個層次包含若干級別。
7、退化維度。一方面可以通過退化維度對數據進行分組，另一方面可以使用退化維度關聯到源數據上，有利於ETL更新及排錯。
8、一般情況維度個數應該控制在15個以內，唯獨過多影響查詢性能和磁盤空間。一些小維度可以進行組合，這取決於具體的業務。
9、代理關鍵字。使用代理關鍵字的優點：能實現漸變維度；獲得性能上的優勢，節省事實表空間；可以記錄沒有操作源碼的數據（ETL過程生成）；處理關鍵字段的修改、刪除等。（第二章）
10、一致性維度。具有一致性的維度關鍵字，以致的屬性名稱，以致的屬性定義，一致的屬性值。一致性維度對於設計可以進行集成的數據中心來說，具有絕對的決定性作用。（第三章）
11、漸變維度。漸變維度的處理辦法。類型1：改寫屬性值；類型2：添加維度行；類型3：添加維度列。第二種類型最常用。
12、快變維度的處理辦法：將這些迅速變化的屬性分裂成一個或者多個單獨的維度。（第四章）
13、維度的角色模仿。在同一個維度表上通過視圖的形式建立多個維度。在實際運用中，很多OLAP工具都支持在同一個維度表上建多個維度，而並不需要建立視圖。
14、實體之間存在固定的，不隨時間變化的，強烈相關的關系時，顯然應該將它們當作單一維度進行建模。
15、雜項維度。將標志與指標符從設計中剝離出來，將其封裝成一個或者多個雜項維度。（第五章）
16、將聚集事實放入維度表的優缺點。優點：查詢時可以對聚集屬性進行約束。缺點：ETL過程變麻煩了。
17、雪花模型的使用場合：粒度懸殊，節省空間（屬性眾多）。
18、寬度變化的屬性集的處理辦法：拆分成兩個維度。Oracle數據庫不存在這個問題。
19、采用類型2的方式處理維度慢性變化時，應該注意避免計數過度。
20、深化不變的體系結構（層次、級別）。一個層次建立單獨的字段。如果某一個級別沒有值，就應該用較低級別的屬性覆蓋該值。
21、深度可變的體系結構。使用橋接標來解決。父到子的每一條路徑都包含一行記錄，到其自身長度為0的路徑包含一行。實際上是把循環遞歸的過程通過表數據的形式實現。大量olap工具以提供了對小於64000個成員的中小尺寸維度中這些體系進行導航操作得更加強勁的內置功能支持。（第六章）
22、依照十五描述內容在每行加入生效和截止日期標記，可以將類型2漸變維度設計方案修改為允許自然的對維度在時間上進行非常精細的切割。
23、審計維度。源系統的情況；抽取軟件的版本；抽取記錄數；開始時間；完成時間等。
24、維度的屬性數量不確定時，使用關鍵詞支架維度。相當於將橫表設計成縱表。使用union和intersect命令解決SQL跨行約束問題。（第八章）
25、維度類型：因果維度、多日期或時間標記維度、退化維度、角色模仿維度、狀態維度、審計維度、雜項維度。
26、多值維度。概念：一個賬戶擁有多個客戶，一個客戶也可能擁有多個賬戶。解決辦法：橋接表。
27、異構產品方案。概念：每種產品類型都有大量的專用屬性與度量事實不能為其他產品所用。解決方案：核心維度，定制維度，使用相同的代理關鍵字。采用支架結構。（第九章）
28、日期維度。國別歷法的處理辦法，做成日期維度的支架。
29、多個時區日期的處理辦法，增加維度。（第十章）
30、多值維度解決方案。所謂多值維度是指一個事實表對應多個值的維度，比如，住院結算事實表擁有多個疾病。通過組橋表來實現。組橋表可以增加起止時間來滿足住院漸變維度。可以增加加權因子來實現財務報表關於疾病的分類統計。
31、稀疏事實表的解決方案。事實維度表。實際上是縱表和橫表的設計思想。優點：靈活、結構簡單、節省空間。缺點：生成查詢、報表復雜、行間計算困難。
32、遲到維度行的處理辦法。所謂遲到維度是指某項屬性到當前時間才知道其以前的值。通過漸變維度（類型2）的方法處理，在維度表中增加記錄並修改其他型的起止時間，在事實表中修改該維度的代理關鍵字。（第十三章）
三、事實表建模技術
1、事實表中的事實分為三種類型：可加性事實，半可加性事實，非可加性事實。
2、事實表的三種粒度：事務，周期快照，累計快照。
3、事實表傾向於具有更多的行和更少的列。
4、事實表的主鍵應采用復合主鍵，引入唯一的rowid關鍵字作為主鍵字並無什么優點可言。（第一章）
5、明顯屬於不同粒度的事實必須放在單獨的事實表中。
6、將可計算得值作為事實的原因：消除用戶出錯的可能性，一致的引用它。例如，利潤=銷售額-成本額，將利潤作為一個事實而不是通過展現工具進行計算得到。
7、非可加性的數據項盡量不要放到事實表中。例如，毛利潤率是非可加性數據，不應該保存在事實表中，應保存分子和分母，再通過前端展現工具進行計算得到。
8、非事實型事實表。解答什么促銷產品沒有賣出去的問題。建立一張非事實型事實表，促銷產品（周期快照）中每個商場的每隔促銷產品每天創建一行。再關聯銷售事實表來解決什么產品沒有賣出去這個問題。
9、事實表的粒度很關鍵，決定了維度模型的擴展性。過早匯總或者聚集處理必然限制對維度的增補。
10、半可加性事實。對特定的維度具有可加性，對其他維度不具有可加性。
11、周期快照事實表是最常見的庫存設計方案。
12、一致性事實。一致的事實定義，一致的測量單位。（第三章）
13、使用單個事實表（通過增加事務類型維度）還是多個事實表的選擇：（1）、業務需求（目標是降低復雜度，用最有效的形式將數據展示給用戶）。（2）、業務處理的關聯性。（3）、源系統。（4）、維度是否完全一致。（第四章）
14、事實表的規范化。縱表和橫表的設計方式。優缺點。事實設置顯得比較稀疏並且不在事實之間運算的情形是有用的。
15、不同粒度事實的處理辦法。例如，訂貨系統中的訂貨分列項事實表（基於產品）與裝運費（基於訂單）。兩種處理方式：（1）、分配到細節層次（裝運費à產品）。（2）、建立兩個事實表。優先采用第一種方式。
16、累計快照。采用對整個訂單處理流程的分析感性趣，他們想了解產品的移動速度，累計快照很好的體現這種業務情景。適用：具有明確起止時間的短期處理應用。
17、多個計量單位的處理辦法。將轉移因子寫入事實表。
18、三種事實粒度的比較：（第五章）
| 時間段 | 粒度 | 加載 | 更新 | 日期維度 | 事實 | |
| 事務 | 時間點 | 每個事務一行 | 插入 | 不 | 事務日期 | 事務活動 |
| 周期快照 | 規律間隔 | 每段一行 | 插入 | 不 | 時間段終止日期 | 間隔事務 |
| 累計快照 | 不確定跨度，一般短期 | 每個生命期一行 | 插入更新 | 行為發生時更新 | 關鍵環節多日期 | 生命周期性能 |
19、至今為止事實：應該計算出來，而不是保存在事實表中。數字型事實必須與粒度保持一致。
20、事實的變化通過增加一行沖減記錄，而不是通過修改原事實數據。
21、事實的自由分段。通過分段定義表連接到事實表上，來靈活划分和定義分段。分段事實字段需建索引。（第七章）
22、時間點結余建模。在事實表中增加最后標記字段和事務結束結余來實現。使用事務表來代替日快照事實表。（第九章）
23、多個事實表粒度。不是很理解。（第十一章）
24、非事實型事實表。沒有度量值，記錄發生的事件。分為兩類。第一類記錄事件與大量維度實體同時出現的內容進行記錄。第二類，范圍表。可用來實現沒有發生的事件。Loap在分析沒有發生的事件方面做出了卓有成效的工作。（第十二章）
25、稀疏事實建模。將稀疏事實做成事實維度。縱表和橫表。
26、遲到的事實行的處理辦法。根據時間在各維度表中找到對應的代理關鍵字，然后插入事實表中。（第十三章）
27、異構產品事實表建模。建立一個核心事實表和一簇定制事實表。使用相同的代理關鍵字。
28、合並事實表。將兩個事實表通過公共的維度合並在一起。可以通過展現工具進行合並。（第十五章）
四、行業建模經驗