建設數據模型既然是整個數據倉庫建設中一個非常重要的關鍵部分，那么，怎么建設我們的數據倉庫模型就是我們需要解決的一個問題。這里我們將要詳細介紹如何創建適合自己的數據模型。

數據倉庫建模方法

大千世界，表面看五彩繽紛，實質上，萬物都遵循其自有的法則。

數據倉庫的建模方法同樣也有很多種，每一種建模方法其實代表了哲學上的一個觀點，代表了一種歸納，概括世界的一種方法。

目前業界較為流行的數據倉庫的建模方法非常多，這里主要介紹范式建模法，維度建模法，實體建模法等幾種方法，每種方法其實從本質上講就是從不同的角度看我們業務中的問題，不管從技術層面還是業務層面，其實代表的是哲學上的一種世界觀。

我們下面給大家詳細介紹一下這些建模方法。

范式建模法

范式建模法(Third Normal Form，3NF)其實是我們在構建數據模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關系型數據庫得數據存儲，利用的一種技術層面上的方法。?

目前，我們在關系型數據庫中的建模方法，大部分采用的是三范式建模法。?

范式是數據庫邏輯模型設計的基本理論，一個關系模型可以從第一范式到第五范式進行無損分解，這個過程也可稱為規范化。?

在數據倉庫的模型設計中目前一般采用第三范式，它有著嚴格的數學定義。從其表達的含義來看，一個符合第三范式的關系必須具有以下三個條件 :?

每個屬性值唯一，不具有多義性 ;?

每個非主屬性必須完全依賴于整個主鍵，而非主鍵的一部分 ;?

每個非主屬性不能依賴于其他關系中的屬性，因為這樣的話，這種屬性應該歸到其他關系中去。?

由于范式是基于整個關系型數據庫的理論基礎之上發展而來的，因此，本人在這里不多做介紹，有興趣的讀者可以通過閱讀相應的材料來獲得這方面的知識。?

根據 Inmon 的觀點，數據倉庫模型得建設方法和業務系統的企業數據模型類似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關系型數據庫上的實例。

從業務數據模型轉向數據倉庫模型時，同樣也需要有數據倉庫的域模型，即概念模型，同時也存在域模型的邏輯模型。?

這里，業務模型中的數據模型和數據倉庫的模型稍微有一些不同。主要區別在于：?

數據倉庫的域模型應該包含企業數據模型的域模型之間的關系，以及各主題域定義。?

數據倉庫的域模型的概念應該比業務系統的主題域模型范圍更加廣。?

在數據倉庫的邏輯模型需要從業務系統的數據模型中的邏輯模型中抽象實體，實體的屬性，實體的子類，以及實體的關系等。?

以筆者的觀點來看，Inmon 的范式建模法的最大優點就是從關系型數據庫的角度出發，結合了業務系統的數據模型，能夠比較方便的實現數據倉庫的建模。?

但其缺點也是明顯的，由于建模方法限定在關系型數據庫之上，在某些時候反而限制了整個數據倉庫模型的靈活性，性能等，特別是考慮到數據倉庫的底層數據向數據集市的數據進行匯總時，需要進行一定的變通才能滿足相應的需求。

維度建模法

維度建模法，Kimball 最先提出這一概念。其最簡單的描述就是，按照事實表，維表來構建數據倉庫，數據集市。

事實表是用來記錄具體事件的，包含了每個事件的具體要素，以及具體發生的事情；維表則是對事實表中事件的要素的描述信息。

比如一個事件會包含時間、地點、人物、事件，事實表記錄了整個事件的信息，但對時間、地點和人物等要素只記錄了一些關鍵標記，比如事件的主角叫“Michael”，那么Michael到底“長什么樣”，就需要到相應的維表里面去查詢“Michael”的具體描述信息了。

基于事實表和維表就可以構建出多種多維模型，包括星形模型、雪花模型和星座模型。

維度建模法最被人廣泛知曉的名字就是星型模式(Star-schema)。

上圖的這個架構中是典型的星型架構。星型模式之所以廣泛被使用，在于針對各個維作了大量的預處理，如按照維進行預先的統計、分類、排序等。?

通過這些預處理，能夠極大的提升數據倉庫的處理能力。?

特別是針對 3NF 的建模方法，星型模式在性能上占據明顯的優勢。?

同時，維度建模法的另外一個優點是，維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。?

不需要經過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優勢。?

但是，維度建模法的缺點也是非常明顯的，由于在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。?

而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。?

而在這些與處理過程中，往往會導致大量的數據冗余。?

另外一個維度建模法的缺點就是，如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用于維度建模的方法。?

因此以筆者的觀點看，維度建模的領域主要適用與數據集市層，它的最大的作用其實是為了解決數據倉庫建模中的性能問題。?

維度建模很難能夠提供一個完整地描述真實業務實體之間的復雜關系的抽象方法。

實體建模法

實體建模法并不是數據倉庫建模中常見的一個方法，它來源于哲學的一個流派。?

從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關系組成。?

那么我們在數據倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關系，以及針對這些關系的說明就是我們數據建模需要做的工作。?

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。?

即我們可以將任何一個業務過程劃分成 3 個部分，實體，事件和說明。?

例如我們描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體，“上學”描述的是一個業務過程，我們在這里可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。?

從上面的舉例我們可以了解，我們使用的抽象歸納方法其實很簡單，任何業務可以看成 3 個部分：?

實體，主要指領域模型中特定的概念主體，指發生業務關系的對象。?

事件，主要指概念主體之間完成一次業務流程的過程，特指特定的業務過程。?

說明，主要是針對實體和事件的特殊說明。?

由于實體建模法，能夠很輕松的實現業務模型的劃分，因此，在業務建模階段和領域概念建模階段，實體建模法有著廣泛的應用。從筆者的經驗來看，再沒有現成的行業模型的情況下，我們可以采用實體建模的方法，和客戶一起理清整個業務的模型，進行領域概念模型的劃分，抽象出具體的業務概念，結合客戶的使用特點，完全可以創建出一個符合自己需要的數據倉庫模型來。?

但是，實體建模法也有著自己先天的缺陷，由于實體說明法只是一種抽象客觀世界的方法，因此，注定了該建模方法只能局限在業務建模和領域概念建模階段。因此，到了邏輯建模階段和物理建模階段，則是范式建模和維度建模發揮長處的階段。?

因此，筆者建議讀者在創建自己的數據倉庫模型的時候，可以參考使用上述的三種數據倉庫得建模方法，在各個不同階段采用不同的方法，從而能夠保證整個數據倉庫建模的質量。

維度建模法數據模型的區別

多維數據模型是最流行的數據倉庫的數據模型，多維數據模型最典型的數據模式包括星型模式、雪花模式和事實星座模式，本文以實例方式展示三者的模式和區別。

星型模式(star schema)

星型模式的核心是一個大的中心表(事實表)，一組小的附屬表(維表)。星型模式示例如下所示：

可以看出，星形模式的維度建模由一個事實表和一組維表成，且具有以下特點：

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

b. 每個維表的主碼為單列，且該主碼放置在事實表中，作為兩邊連接的外碼；

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

雪花模式(snowflake schema)

雪花模式是星型模式的擴展，其中某些維表被規范化，進一步分解到附加表(維表)中。雪花模式示例如下圖所示：

從圖中我們可以看到地址表被進一步細分出了城市(city)維。supplier_type表被進一步細分出來supplier維。

星形模式中的維表相對雪花模式來說要大，而且不滿足規范化設計。雪花模型相當于將星形模式的大維表拆分成小維表，滿足了規范化設計。然而這種模式在實際應用中很少見，因為這樣做會導致開發難度增大，而數據冗余問題在數據倉庫里并不嚴重。

事實星座模式(Fact Constellation)

數據倉庫由多個主題構成，包含多個事實表，而維表是公共的，可以共享，這種模式可以看做星型模式的匯集，因而稱作星系模式或者事實星座模式。本模式示例如下圖所示：

如上圖所示，事實星座模式包含兩個事實表：sales和shipping，二者共享維表。

事實星座模式是數據倉庫最常使用的數據模式，尤其是企業級數據倉庫(EDW)。

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

這也是數據倉庫區別于數據集市的一個典型的特征，從根本上而言，數據倉庫數據模型的模式更多是為了避免冗余和數據復用，套用現成的模式，是設計數據倉庫最合理的選擇。

三種模式對比

歸納一下，星形模式/雪花模式/星座模式的關系如下圖所示：

實例

在進行維度建模前，首先要了解用戶需求。而筆者在數據庫系列的第一篇就講過，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)，它是一個通過自動分配整數生成的主碼，沒有任何其他意義。使用它主要是為了能夠處理”緩慢變化的維度”。

經典星座模型

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

共享維度

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

細節/聚集事實表

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

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

END

來源：CSDN(侵刪)

作者：張小凡vip(侵刪)

編輯：實施曉記

原文：https://blog.csdn.net/zzq900503/article/details/78492505

▼更多精彩推薦，請關注我們▼

總結

以上是生活随笔為你收集整理的星形和雪花模型_数据仓库多维数据模型设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。