在上一篇文章中我們簡單介紹了什麼是維度建模以及維度建模的基本要素，這篇文章中我們依然學習瞭解維度建模中的基本要素事實表和維度表的型別以及維度設計方法。首先裡瞭解維度建模中的事實表型別，在依次介紹維度型別，一致性維度和一致性事實，維度設計方法。接下來進入正題。

      一、事實表 

       事實表儲存了從業務活動或事件提煉出來的效能度量，它主要包含維度表的外來鍵和連續變化的可加性數值或半可加事實。事實表產生於業務過程中而不是業務過程的描述性資訊。它一般是行多列少，佔據資料倉庫大約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過程的問題，一起學習一起成長。 

 掃碼加群：

&n