在上一篇文章中我們簡單介紹了什麼是次元模組化以及次元模組化的基本要素，這篇文章中我們依然學習了解次元模組化中的基本要素事實表和次元表的類型以及次元設計方法。首先裡了解次元模組化中的事實表類型，在依次介紹次元類型，一緻性次元和一緻性事實，次元設計方法。接下來進入正題。
一、事實表
事實表存儲了從業務活動或事件提煉出來的性能度量，它主要包含次元表的外鍵和連續變化的可加性數值或半可加事實。事實表産生于業務過程中而不是業務過程的描述性資訊。它一般是行多列少，占據資料倉庫大約90%的空間。在次元模型中也有表示多對多關系的事實表，其他都是次元表。
1、事實表粒度
事實表的粒度是産生事實行資料的度量事件的業務定義。粒度确定了事實表的業務主鍵， 事實表的所有路徑成本必須具有相同的粒度。
2、事實表類型
2.1、事務事實表
它是面向事務的，其粒度是每一行對應一個事務，它是最細粒度的事實表也稱“原子事實表”。事務事實表中的資料在事務事件發生後産生，資料的粒度通常是每個事務一條記錄。一旦事務被送出，事實表資料被插入，資料就不再進行更改，其更新方式為增量更新。
2.2、周期快照事實表
它是按照良好的時間周期間隔(每天，每周，每月)來捕捉業務活動的執行情況，一旦裝入事實表就不會再去更新，它是事務事實表的補充，而非替代。典型的例子如銷售日快照表、庫存日快照表等。周期快照事實表的粒度是每個時間段一條記錄，通常比事務事實表的粒度要粗，是在事務事實表之上建立的聚集表。周期快照事實表的次元個數比事務事實表要少，但是記錄的事實要比事務事實表多。周期快照事實表的日期次元通常是記錄時間段的終止日，記錄的事實是這個時間段内一些聚集事實值。事實表的資料一旦插入即不能更改，其更新方式為增量更新。
2.3、累積快照事實表
它用于描述業務過程中某個不确定時間跨度裡的活動，它随着業務活動的發生會不斷的更新。累積快照事實表和周期快照事實表有些相似之處，它們存儲的都是事務資料的快照資訊。但是它們之間也有着很大的不同，周期快照事實表記錄的确定的周期的資料，而累積快照事實表記錄的不确定的周期的資料。
累積快照事實表代表的是完全覆寫一個事務或産品的生命周期的時間跨度，它通常具有多個日期字段，用來記錄整個生命周期中的關鍵時間點。另外，它還會有一個用于訓示最後更新日期的附加日期字段。由于事實表中許多日期在首次加載時是不知道的，是以必須使用代理關鍵字來處理未定義的日期，而且這類事實表在資料加載完後，是可以對它進行更新的，來補充随後知道的日期資訊。
舉例來說客戶購買商品的整個過程記錄:訂貨日期 預定交貨日期 實際發貨日期 實際交貨日期 數量 金額 運費
在這個累積快照事實表中，記錄的是購買貨物的整個生命周期的資料，記錄第一次産生時，實際發貨日期和實際交貨日期是不确定的，需要用表示未知的代理關鍵字來代替。等實際發貨後，需要對資料倉庫中的這條記錄進行更新操作，将實際發貨日期補上。
3、事實表差別：
二、次元表
次元表是對業務過程的上下文描述，主要包含代理鍵、文本資訊和離散的數字。它是進入事實表的入口，豐富的次元屬性給出了對事實表的分析切割能力，它一般是行少列多。如果屬性值是離散的，用于過濾和标記的，就放到次元表裡，如果是屬性值是連續取值，可用于計算的，就放到事實表中。
1、次元表類型
1.1、緩慢變化維
1）、類型1
字段值發生變化時覆寫原來的值。
2）.類型2
字段值發生變化時會新增一行，重新配置設定代理鍵，每一行添加開始日期，結束日期，版本号，是否目前值。
3）.類型3
每條記錄會新增一列來辨別變化前的值，發生變化時，把舊值放到新增的列中，把新值覆寫舊值。
4）.混合類型
把上面的三種類型混合來使用。
1.2日期維
它是資料倉庫必須有的次元，包含日期，日期所屬的周，月，季度，年等資訊。
1.3角色維
相同的次元表在次元模型中扮演不中的邏輯角色，一般通過建立視圖來表示。
1.4雜項維
如果每個屬性值都很少，可以把這些次元的組合起來生成一個次元表。
1.5支架維
如果次元之間是一對多的關系或差別于原次元的多個描述性次元屬性，可以建雪花型支架次元。
1.6多值次元橋接維
如果二個次元表是多對多的關系，可以使用多值次元設計。
1.7微型維
一個大型維有些屬性變化比較頻繁，把這些屬性單獨生成一個微型次元表。
1.8縮小維
它是次元表的一個子集或部分屬性。
1.9查找維
系統裡代碼表裡次元資訊。
1.10層次維
有些次元表是有層次結構的，可以通過視圖生成樹形結構的次元表。
還需要注意，手工維護的維表，有些資料不在業務系統裡，需要業務使用者手工維護的次元表。
三、次元模組化核心：一緻性次元和事實
企業資料倉庫應該建立一緻性次元和事實，而不是為每個部門建立次元和事實。
3.1、一緻性次元
次元一直是大家所熟知的，但是前面加上了“一緻性”之後便成了資料倉庫特有的一類次元表，其實一緻性次元在表結構和屬性都沒有本質的差別，有一點的差異是資料倉庫的星型模型會使得次元表有一定的備援。那麼一緻性展現在哪裡呢： 次元共享性。共享性展現在整個平台或整個部門共用次元，而不僅僅隻是單純某個業務單獨使用。 一般的次元并沒有把共享性作為一個共性的标準。然而在次元模組化中，一緻性次元将作為重心來做。資料倉庫70%的工作量和複雜度是用在建構一緻性次元。一緻性次元将作用于資料倉庫和資料集市甚至是OLAP。
3.2、一緻性事實
指每個度量在整個資料倉庫中都是唯一的統計口徑，為了避免歧義，一個度量隻有唯一的業務術語。一緻性事實在建立多個資料集市時，完成一緻性次元的工作就已經完成了一緻性的80%－90%的工作量。餘下的工作就是建立一緻性事實。 一緻性事實和一緻性次元有些不同，一緻性次元是由專人維護在背景，發生修改時同步複制到每個資料集市，而事實表一般不會在多個資料集市間複制。需要查詢多個資料集市中的事實時，一般通過交叉探查來實作。 為了能在多個資料集市間進行交叉探查，一緻性事實主要需要保證兩點。第一個是KPI的定義及計算方法要一緻，第二個是事實的機關要一緻性。如果業務要求或事實上就不能保持一緻的話，建議不同機關的事實分開建立字段儲存。
四、次元模型設計方法
次元模組化方法就講解到這裡。下一篇我們開始來資料倉庫的ETL過程。本文中如有錯誤或誤導的地方歡迎大家指出糾正。 希望這篇文章能夠給大家帶來幫助，最後感謝大家的閱讀。歡迎大家一起加入高效資料處理ETL交流群，一起讨論資料分析前ETL過程的問題，一起學習一起成長。
掃碼加群：
小黎子，一個專注于資料分析整體資料倉庫解決方案的程式猿！
作 者：黃昏前黎明後
出 處：http://www.cnblogs.com/fly-bird/
歡迎關注個人公衆号：小黎子資料分析，轉載文章請務必注明出處。