數據倉庫系列之維度建模二

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

      1、事實表 

       事實表存儲了從業務活動或事件提煉出來的性能度量，它主要包含維度表的外鍵和連續變化的可加性數值或半可加事實。事實表產生於業務過程當中而不是業務過程的描述性信息。它通常是行多列少，佔據數據倉庫大約90%的空間。在維度模型中也有表示多對多關係的事實表，其餘都是維度表。 

      一、事實表粒度

        事實表的粒度是產生事實行數據的度量事件的業務定義。粒度肯定了事實表的業務主鍵， 事實表的全部度量值必須具備相同的粒度。 

       二、事實表類型

           2.一、事務事實表

           它是面向事務的，其粒度是每一行對應一個事務，它是最細粒度的事實表也稱「原子事實表」。事務事實表中的數據在事務事件發生後產生，數據的粒度一般是每一個事務一條記錄。一旦事務被提交，事實表數據被插入，數據就再也不進行更改，其更新方式爲增量更新。

          2.二、週期快照事實表

          它是按照良好的時間週期間隔(天天，每週，每個月)來捕捉業務活動的執行狀況，一旦裝入事實表就不會再去更新，它是事務事實表的補充，而非替代。典型的例子如銷售日快照表、庫存日快照表等。週期快照事實表的粒度是每一個時間段一條記錄，一般比事務事實表的粒度要粗，是在事務事實表之上創建的彙集表。週期快照事實表的維度個數比事務事實表要少，可是記錄的事實要比事務事實表多。週期快照事實表的日期維度一般是記錄時間段的終止日，記錄的事實是這個時間段內一些彙集事實值。事實表的數據一旦插入即不能更改，其更新方式爲增量更新。

         2.三、累積快照事實表

         它用於描述業務過程當中某個不肯定時間跨度裏的活動，它隨着業務活動的發生會不斷的更新。累積快照事實表和週期快照事實表有些類似之處，它們存儲的都是事務數據的快照信息。可是它們之間也有着很大的不一樣，週期快照事實表記錄的肯定的週期的數據，而累積快照事實表記錄的不肯定的週期的數據。

         累積快照事實表表明的是徹底覆蓋一個事務或產品的生命週期的時間跨度，它一般具備多個日期字段，用來記錄整個生命週期中的關鍵時間點。另外，它還會有一個用於指示最後更新日期的附加日期字段。因爲事實表中許多日期在首次加載時是不知道的，因此必須使用代理關鍵字來處理未定義的日期，並且這類事實表在數據加載完後，是能夠對它進行更新的，來補充隨後知道的日期信息。

        舉例來講客戶購買商品的整個過程記錄:定貨日期 預約交貨日期 實際發貨日期 實際交貨日期 數量 金額 運費

        在這個累積快照事實表中，記錄的是購買貨物的整個生命週期的數據，記錄第一次產生時，實際發貨日期和實際交貨日期是不肯定的，須要用表示未知的代理關鍵字來代替。等實際發貨後，須要對數據倉庫中的這條記錄進行更新操做，將實際發貨日期補上。

        三、事實表區別： 

 

           2、維度表 

          維度表是對業務過程的上下文描述，主要包含代理鍵、文本信息和離散的數字。它是進入事實表的入口，豐富的維度屬性給出了對事實表的分析切割能力，它通常是行少列多。若是屬性值是離散的，用於過濾和標記的，就放到維度表裏，若是是屬性值是連續取值，可用於計算的，就放到事實表中。

         一、維度表類型

           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、維度建模核心：一致性維度和事實

          企業數據倉庫應該創建一致性維度和事實，而不是爲每一個部門創建維度和事實。 

          3.一、一致性維度

          維度一直是你們所熟知的，可是前面加上了「一致性」以後便成了數據倉庫特有的一類維度表，其實一致性維度在表結構和屬性都沒有本質的區別，有一點的差別是數據倉庫的星型模型會使得維度表有必定的冗餘。那麼一致性體如今哪裏呢： 維度共享性。共享性體如今整個平臺或整個部門共用維度，而不只僅只是單純某個業務單獨使用。 通常的維度並無把共享性做爲一個共性的標準。然而在維度建模中，一致性維度將做爲重心來作。數據倉庫70%的工做量和複雜度是用在構建一致性維度。一致性維度將做用於數據倉庫和數據集市甚至是OLAP。

          3.二、一致性事實

          指每一個度量在整個數據倉庫中都是惟一的統計口徑，爲了不歧義，一個度量只有惟一的業務術語。一致性事實在創建多個數據集市時，完成一致性維度的工做就已經完成了一致性的80%－90%的工做量。餘下的工做就是創建一致性事實。 一致性事實和一致性維度有些不一樣，一致性維度是由專人維護在後臺，發生修改時同步複製到每一個數據集市，而事實表通常不會在多個數據集市間複製。須要查詢多個數據集市中的事實時，通常經過交叉探查來實現。 爲了能在多個數據集市間進行交叉探查，一致性事實主要須要保證兩點。第一個是KPI的定義及計算方法要一致，第二個是事實的單位要一致性。若是業務要求或事實上就不能保持一致的話，建議不一樣單位的事實分開創建字段保存。

        4、維度模型設計方法 

 

        維度建模方法就講解到這裏。下一篇咱們開始來數據倉庫的ETL過程。本文中若有錯誤或誤導的地方歡迎你們指出糾正。 但願這篇文章可以給你們帶來幫助，最後感謝你們的閱讀。歡迎你們一塊兒加入高效數據處理ETL交流羣，一塊兒討論數據分析前ETL過程的問題，一塊兒學習一塊兒成長。 

 掃碼加羣：