資料倉儲維度建模筆記

bidwhome發表於2007-08-05
--[@more@]

《資料倉儲工具箱—維度建模的完全指南》是資料倉儲建模方面的經典著作, 1996年第一版出版被認為是資料倉儲方面具有里程碑意義的事件。作者kimballl是資料倉儲方面的權威,他將多年的資料倉儲建模實戰經驗、技巧融入本書。他提出的許多維度建模概念被廣泛應用於資料倉儲的設計和開發中。2002年本書出版了第二版。

這是一部非常好的資料倉儲建模的書,前後完整的讀了三遍,受益匪淺。

以下筆記將本按四個部分組織:一、資料倉儲體系結構和建模過程、技巧。二、維度表建模技術。三、事實表建模技術。四、行業建模經驗。

一、資料倉儲體系結構和建模過程、技巧

關鍵點:資料倉儲體系結構、維度建模的四個步驟、資料倉儲匯流排結構、一致性維度。

1、對於資料倉儲來說,業務需求是第一位的。

2、資料倉儲的目標:(1)、隨心所欲的訪問資料。直觀、明顯、簡單、易用、切割、合併、下鑽、上卷。(2)、一致的展現資料(相對於原來從多個系統中出來的報表不一致)。(3)、適應性、擴充套件性、可維護性。(4)、為領導決策提供支援。

3、資料倉儲的組成。源資料--&gt資料準備區--&gt資料倉儲(維度建模)--&gt資料聚集區(OLAP)--&gt展現。其中原系統到資料準備區屬於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、合併事實表。將兩個事實表透過公共的維度合併在一起。可以透過展現工具進行合併。(第十五章)

四、行業建模經驗

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7600305/viewspace-931820/,如需轉載,請註明出處,否則將追究法律責任。

相關文章