資料倉庫模組化包含了幾種資料模組化技術，除了之前在資料庫系列文章中介紹過的ER模組化和關系模組化，還包括專門針對資料倉庫的次元模組化技術。本文将詳細介紹資料倉庫次元模組化技術，并重點讨論三種基于ER模組化/關系模組化/次元模組化的資料倉庫總體模組化體系：規範化資料倉庫，次元模組化資料倉庫，以及獨立資料集市...
前言
資料倉庫模組化包含了幾種資料模組化技術，除了之前在資料庫系列中介紹過的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模組化、關系模組化、次元模組化等技術。而且當企業業務複雜的時候，這部分工作更是需要專門團隊與業務方共同合作來完成。是以一個優秀的資料倉庫模組化團隊既要有堅實的資料倉庫模組化技術，還要有對現實業務清晰、透徹的了解。