數倉系列 - 數據建模方法#
內容整理自:
數據模型的基本概念#
數據模型是抽象描述現實世界的一種工具和方法，是通過抽象的實體及實體之間聯繫的形式，來表示現實世界中事務的相互關係的一種映射。在這裡，數據模型表現的抽象是實體和實體之間的關係，通過對實體和實體之間關係的定義和描述，來表達實際的業務中具體的業務關係，分為以下幾個層次:
通過上面的圖形，我們能夠很容易的看出在整個數據倉庫的建模過程中，我們需要經歷一般四個過程：
-
業務建模，生成業務模型，主要解決業務層面的分解和程序化。
-
領域建模，生成領域模型，主要是對業務模型進行抽象處理，生成領域概念模型。
-
邏輯建模，生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關係進行數據庫層次的邏輯化。
-
物理建模，生成物理模型，主要解決，邏輯模型針對不同關係型數據庫的物理化以及性能等一些具體的技術問題
範式建模#
在數據倉庫的模型設計中目前一般採用第三範式，它有著嚴格的數學定義。從其表達的含義來看，一個符合第三範式的關係必須具有以下三個條件 :
- 每個屬性值唯一，不具有多義性；
- 每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分；
- 每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去
維度建模#
最簡單的描述就是，按照事實表，維表來構建數據倉庫，數據集市。如星型模式、雪花模型等
星型模型 (Star-schema)#
上圖的這個架構中是典型的星型架構。星型架構是一種非正規化的結構，多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一定的冗餘，如在地域維度表中，存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄，那麼國家 A 和省 B 的信息分別存儲了兩次，即存在冗餘
特點
-
只有一個事實表，並且每一個維度有一個單獨的表。
-
事實表中的每一個元組都是一個外鍵指向維度表的主鍵。
-
每一個維度表的列是組成這個維度的所有屬性
-
事實表與維度表通過主鍵外鍵相關聯，維度表之間沒有關聯，就像很多星星圍繞在一個恆星周圍，故取名為星形模型。
優點
-
星形模型是最簡單，也是最常用的模型。
-
由於星形模型只有一張大表，因此它相比於其他模型更適合於大數據處理。
-
其他模型可以通過一定的轉換，變為星形模型
雪花模型 (Snow Schema)#
當有一個或多個維表沒有直接連接到事實表上，而是通過其他維表連接到事實表上時，其圖解就像多個雪花連接在一起，故稱雪花模型。
雪花模型是對星型模型的維表進一步層次化，原有的各維表可能被擴展為小的事實表，形成一些局部的 "層次" 區域，這些被分解的表都連接到主維度表而不是事實表
如上圖所示，將地域維表又分解為國家，省份，城市等維表。它的優點是：通過最大限度地減少數據存儲量以及聯合較小的維表來改善查詢性能，去除了數據冗餘。
數據倉庫大多數時候是比較適合使用星型模型構建底層數據 Hive 表，通過大量的冗餘來提升查詢效率，星型模型對 OLAP 的分析引擎支持比較友好，這一點在 Kylin 中比較能體現。而雪花模型在關係型數據庫中如 MySQL，Oracle 中非常常見，尤其像電商的數據庫表。
事實星座模型（Fact Constellation）#
星座模型是更複雜的模型，其中包含了多個事實表，而維度表是公用的，可以共享多個事實表共享維表，這種模式可以看作星座模式集，因此稱作星系模式 (galaxy schema)，或者事實星座 (fact constellation)
總結#
維度建模法的優點:
維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模
維度建模法的缺點:
-
由於在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。
-
當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些與處理過程中，往往會導致大量的數據冗餘。
-
如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用於維度建模的方法。
維度建模的領域主要適用於數據集市層，它的最大的作用其實是為了解決數據倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的複雜關係的抽象方法。