[轉載] 第二篇 數據倉庫與數據集市建模

閱讀目錄

• 前言
• 維度建模的基本概念
• 維度建模的三種模式
• 實例：零售公司銷售主題的維度建模
• 更多可能的事實屬性
• 經典星座模型
• 緩慢變化維度問題
• 數據倉庫建模體系之規範化數據倉庫
• 數據倉庫建模體系之維度建模數據倉庫
• 數據倉庫建模體系之獨立數據集市
• 三種數據倉庫建模體系對比
• 小結

回到頂部

前言

        數據倉庫建模包含了幾種數據建模技術，除了以前在數據庫系列中介紹過的ER建模和關係建模，還包括專門針對數據倉庫的維度建模技術。

        本文將詳細介紹數據倉庫維度建模技術，並重點討論三種基於ER建模/關係建模/維度建模的數據倉庫整體建模體系：規範化數據倉庫，維度建模數據倉庫，以及獨立數據集市。

回到頂部

維度建模的基本概念

        維度建模(dimensional modeling)是專門用於分析型數據庫、數據倉庫、數據集市建模的方法。

        它自己屬於一種關係建模方法，但和以前在操做型數據庫中介紹的關係建模方法相比增長了兩個概念：

        1. 維度表(dimension)

        表示對分析主題所屬類型的描述。好比"昨天早上張三在京東花費200元購買了一個皮包"。那麼以購買爲主題進行分析，可從這段信息中提取三個維度：時間維度(昨天早上)，地點維度(京東), 商品維度(皮包)。一般來講維度表信息比較固定，且數據量小。

        2. 事實表(fact table)

        表示對分析主題的度量。好比上面那個例子中，200元就是事實信息。事實表包含了與各維度表相關聯的外碼，並經過JOIN方式與維度表關聯。事實表的度量一般是數值類型，且記錄數會不斷增長，表規模迅速增加。

        注：在數據倉庫中不須要嚴格遵照規範化設計原則(具體緣由請看上篇)。本文示例中的主碼，外碼均只表示一種對應關係，此處特別說明。

回到頂部

維度建模的三種模式

        1. 星形模式

        星形模式(Star Schema)是最經常使用的維度建模方式，下圖展現了使用星形模式進行維度建模的關係結構：

        能夠看出，星形模式的維度建模由一個事實表和一組維表成，且具備如下特色：

                a. 維表只和事實表關聯，維表之間沒有關聯；

                b. 每一個維表的主碼爲單列，且該主碼放置在事實表中，做爲兩邊鏈接的外碼；

                c. 以事實表爲核心，維表圍繞核心呈星形分佈；

        2. 雪花模式

        雪花模式(Snowflake Schema)是對星形模式的擴展，每一個維表可繼續向外鏈接多個子維表。下圖爲使用雪花模式進行維度建模的關係結構：

        星形模式中的維表相對雪花模式來講要大，並且不知足規範化設計。雪花模型至關於將星形模式的大維表拆分紅小維表，知足了規範化設計。然而這種模式在實際應用中不多見，由於這樣作會致使開發難度增大，而數據冗餘問題在數據倉庫裏並不嚴重。

        3. 星座模式

        星座模式(Fact Constellations Schema)也是星型模式的擴展。基於這種思想就有了星座模式：

 

        前面介紹的兩種維度建模方法都是多維表對應單事實表，但在不少時候維度空間內的事實表不止一個，而一個維表也可能被多個事實表用到。在業務發展後期，絕大部分維度建模都採用的是星座模式。

        4. 三種模式對比

        概括一下，星形模式/雪花模式/星座模式的關係以下圖所示：

        雪花模式是將星型模式的維表進一步劃分，使各維表均知足規範化設計。而星座模式則是容許星形模式中出現多個事實表。本文後面部分將具體講到這幾種模式的使用，請讀者結合實例體會。

回到頂部

實例：零售公司銷售主題的維度建模

        在進行維度建模前，首先要了解用戶需求。而筆者在數據庫系列的第一篇就講過，ER建模是當前收集和可視化需求的最佳技術。所以假定和某零售公司進行屢次需求PK後，獲得如下ER圖：

        隨後可利用建模工具將ER圖直接映射到關係圖： 

        需求蒐集完畢後，即可進行維度建模了。本例採用星形模型維度建模。但不論採起何種模式，維度建模的關鍵在於明確下面四個問題：

        1. 哪些維度對主題分析有用？

        本例中，根據產品(PRODUCT)、顧客(CUSTOMER)、商店(STORE)、日期(DATE)對銷售額進行分析是很是有幫助的；

        2. 如何使用現有數據生成維表？

                a. 維度PRODUCT可由關係PRODUCT，關係VENDOR，關係CATEGORY鏈接獲得；

                b. 維度CUSTOMER和關係CUSTOMER相同；

                c. 維度STORE可由關係STROE和關係REGION鏈接獲得；

                d. 維度CALENDAR由關係SALESTRANSACTION中的TDate列分離獲得；

        3. 用什麼指標來"度量"主題？

        本例的主題是銷售，而銷量和銷售額這兩個指標最能直觀反映銷售狀況；

        4. 如何使用現有數據生成事實表？

        銷量和銷售額信息能夠由關係SALESTRANSACTION和關係SOLDVIA，關係PRODUCT鏈接獲得；

        明確這四個問題後，便能輕鬆完成維度建模：

        細心的讀者會發現三個問題：1. 維表不知足規範化設計(不知足3NF)；2. 事實表也不知足規範化設計(1NF都不知足)； 3. 維度建模中各維度的主碼由***ID變成***Key；

        對於前兩個問題，因爲當前建模環境是數據倉庫，而沒有更新操做，因此不須要嚴格作規範化設計來消除冗餘避免更新異常。

        所以雖然能夠以雪花模型進行維度建模，以下所示： 

        但這樣會加大查詢人員負擔：每次查詢都涉及到太多表了。所以在實際應用中，雪花模型僅是一種理論上的模型。星座模型則出如今"維度建模數據倉庫"中，本文後面將會講到。

        對於第三個問題，***Key這樣的字段被稱爲代理碼(surrogate key)，它是一個經過自動分配整數生成的主碼，沒有任何其餘意義。使用它主要是爲了可以處理"緩慢變化的維度"，本文後面會仔細分析這個問題，這裏不糾結。

回到頂部

更多可能的事實屬性

        除了對應到維度的外碼和度量屬性，事實表中還經常考慮另外兩個屬性：事務標識碼(transaction identifier)和事務時間(transaction time)。

        事務標識碼一般被命名爲TID，其意義就是各類訂單號，事務編號...... 爲何將這個屬性放到事實表而不是維表中呢？一個主要緣由是它的數量級太大了，這樣每次查詢都會耗費不少資源來Join。這種將某些邏輯意義上的維度放到事實表裏的作法被稱爲退化維度(degenerate dimension)。

        將事務時間維度放到事實表中的考慮也是出於相同考慮。然而這麼設計又一次"逆規範化"了：事務標識碼非主碼卻決定事務標識時間，顯然違背了3NF。但如今咱們是爲數據倉庫建模，因此這樣作是OK的。另外在分佈式的數據倉庫中，這個字段十分重要。由於事實表的數量級很是大，Hive或者Spark SQL這類分佈式數據倉庫工具都會對這些數據進行分區。任何成熟的分佈式計算平臺中都應禁止開發人員創建非分區事實表，並默認分區字段爲(當天)日期。

回到頂部

經典星座模型

        前文已經講過，有多個事實表的維度模型被稱爲星座模型。星座模型主要有如下兩大做用：共享維度和設置細節/彙集事實表。下面分別對這兩種狀況進行分析：

        1. 共享維度

        之前文提到的零售公司爲例，假如該公司質量監管部門但願用分析銷售主題一樣的方法分析劣質產品，那麼此時不須要從新維度建模，只需往模型里加入一個新的劣質產品事實表。以後新的數據倉庫維度建模結果以下：

        2. 細節/彙集事實表

        細節事實表(detailed fact tables)中每條記錄表示單一事實，而彙集事實表(aggregated fact tables)中每條記錄則聚合了多條事實。從表的字段上看，細節事實表一般有設置TID屬性，而彙集事實表則無。

        兩種事實表各有優缺點，細節事實表查詢靈活可是響應速度相對慢，而彙集事實表雖然提升了查詢速度，但使查詢功能受到必定限制。一個常見的作法是使用星座模型同時設置兩種事實表(可含多個彙集事實表)。這種設計方法中，彙集事實表使用和細節事實表細節事實表的維度。以下維度建模方法採用星座模型綜合了細節事實表和兩種彙集事實表：

回到頂部

緩慢變化維度問題

        雖然，維表的數據比事實表更穩定。但不論如何維度在某些時候總會發生一些變化。在以前曾拋出一個問題：爲何維度建模後的關係不是***ID，而是***Key了。這樣作的目的其實就是爲了解決一種被稱爲緩慢維度變化(slowly changing dimension)的問題。在維度變化後，一部分歷史信息就被丟掉了。好比張三是某公司會員。

        但僅僅這麼作仍是不夠的，代理碼須要配合時間戳，以及行標識符使用才能解決緩慢維度變化的問題。以下CUSTOMER表使用該方法避免緩慢維度變化：

        能夠看到用戶張三對應新維度的TaxBracket狀態由Low變成了High。若是須要統計張三的相關行爲，那麼可讓全部記錄用CustomerID字段Join事實表；若是要統計當前TaxBracket爲Low的用戶狀態，則可將Row Indicator字段爲Current的記錄用CustomerKey字段Join事實表；若是要統計歷史TaxBracket狀態爲Low的用戶狀況，則只須要將TaxBracket屬性爲Low的用戶記錄的CustomerKey屬性與事實表關聯。

回到頂部

數據倉庫建模體系之規範化數據倉庫

        所謂"數據倉庫建模體系"，指的是數據倉庫從無到有的一整套建模方法。最多見的三種數據倉庫建模體系分別爲：規範化數據倉庫，維度建模數據倉庫，獨立數據集市。不少書將它們稱爲"數據倉庫建模方法"，但筆者認爲數據倉庫建模體系更能準確表達意思，請容許我自做主張一次吧：）。下面首先來介紹規範化數據倉庫。

        規範化數據倉庫(normalized data warehouse)顧名思義，其中是規範化設計的分析型數據庫，而後基於這個數據庫爲各部門創建數據集市。整體架構以下圖所示：

        該建模體系首先對ETL獲得的數據進行ER建模，關係建模，獲得一個規範化的數據庫模式。而後用這個中心數據庫爲公司各部門創建基於維度建模的數據集市。各部門開發人員大都從這些數據集市提數，一般來講不容許直接訪問中心數據庫。    

回到頂部

數據倉庫建模體系之維度建模數據倉庫

        非維度建模數據倉庫(dimensionally modeled data warehouse)是一種使用交錯維度進行建模的數據倉庫，其整體架構以下圖所示：

        該建模體系首先設計一組經常使用的度集合(conformed dimension)，而後建立一個大星座模型表示全部分析型數據。若是這種一致維度不知足某些數據分析要求，天然也可在數據倉庫之上繼續構建新的數據集市。

回到頂部

數據倉庫建模體系之獨立數據集市

        獨立數據集市的建模體系是讓公司的各個組織本身建立並完成ETL，本身維護本身的數據集市。其整體架構以下圖所示：

 

        從技術上來說這是一種很不值得推崇的方式，由於將使信息分散，影響了企業全局範圍內數據分析的效率。此外，各組織之間的ETL架構相互獨立沒法複用，也浪費了企業的開發資源。然而出於某些公司制度及預算方面的考慮，有時也會使用到這種建模體系。

回到頂部

三種數據倉庫建模體系對比

        規範化數據倉庫和維度建模數據倉庫分別是Bill Inmon和Ralph Kimball提出的方法。關於哪一種方法更好，哪一種方法更優秀的爭論已經由來已久。但隨着這兩種數據倉庫應用愈來愈多，人們也逐漸瞭解到兩種數據倉庫的優劣之處，以下表所示：

        產生這些區別的根本之處在於規範化數據倉庫須要對企業全局進行規範化建模，這將致使較大的工做量。但這一步必須完成好，才能繼續往上建設數據集市。所以也就致使規範化數據倉庫須要必定時間才能投入使用，敏捷性相對後者來講略差。可是規範化數據倉庫一旦創建好了，則之後數據就更易於管理。並且因爲開發人員不能直接使用其中心數據庫，更加確保了數據質量。還有因爲中心數據庫是採用規範化設計的，冗餘狀況也會更少。

        然而另外一方面維度建模數據倉庫除了敏捷性更強，並且適用於業務變化比較頻繁的狀況，對開發人員的要求也沒有規範化數據倉庫那麼高。總之各有利弊，具體實施時須要仔細的權衡。

回到頂部

小結

        數據倉庫建模是一個綜合性技術，須要使用到ER建模、關係建模、維度建模等技術。並且當企業業務複雜的時候，這部分工做更是須要專門團隊與業務方共同合做來完成。所以一個優秀的數據倉庫建模團隊既要有堅實的數據倉庫建模技術，還要有對現實業務清晰、透徹的理解。

 

文章出處：http://www.cnblogs.com/muchen/p/5310732.html