背景

接著上個文章數據倉庫簡述，想寫一篇數據倉庫常用模型的文章，但是自己對數據倉庫模型的理解程度和建設架構並沒有下面這個技術專家理解的深刻，並且自己去組織語言，可能會有不準確的地方，怕影響大家對數據倉庫建模的理解，數據倉庫屬於一個工程學科，在設計上要體驗出工程嚴謹性，所以這次向大家推薦這篇文章，畢竟IBM在數據倉庫和數據集市方面已經做得很成熟了，已經有成型的商業數據倉庫組件，這篇文章寫的很好，可以讓大家很好的理解數據倉庫。

版權

作者 周三保([email protected]) IBM 軟件部信息技術專家.
原文地址 https://www.ibm.com/developer...

簡介

本文的主要內容不是介紹現有的比較流行的主要行業的一些數據模型，而是將筆者在數據倉庫建設項目中的一些經驗，在這裏分享給大家。希望幫助大家在數據倉庫項目建設中總結出一套能夠合乎目前業界規範的，滿足大部分行業數據倉庫建設標準的一種方法。

所謂水無定勢，兵無常法。不同的行業，有不同行業的特點，因此，從業務角度看，其相應的數據模型是千差萬別的。目前業界較為主流的是數據倉庫廠商主要是 IBM 和 NCR，這兩家公司的除了能夠提供較為強大的數據倉庫平臺之外，也有各自的針對某個行業的數據模型。

例如，在銀行業，IBM 有自己的 BDWM(Banking data warehouse model)，而 NCR 有自己的 FS-LDM 模型。在電信業，IBM 有 TDWM（Telecom Data warehouse model），而 NCR 有自己的 TS-LDM 模型。因此，我們看到，不同的公司有自己針對某個行業的理解，因此會有不同的公司針對某個行業的模型。而對於不同的行業，同一個公司也會有不同的模型，這主要取決於不同行業的不同業務特點。

舉例來說，IBM 的 TDWM 的模型總共包含了以下 9 個概念，如下圖：

圖 1. IBM 的 TDWM 概念模型

可能很多人要問，為什麽你們的模型是 9 個概念而不是 10 個，11 個呢？你們的數據倉庫模型的依據又是什麽？其實這是我們在給客戶介紹我們的數據模型時，經常被問到的一個問題，我希望讀者在讀完本文時，能夠找到自己的答案。

雖然每個行業有自己的模型，但是，我們發現，不同行業的數據模型，在數據建模的方法上，卻都有著共通的基本特點。

本文的主要目的之一，就是希望讀者能夠通過對本文的閱讀，同時，結合自己對數據倉庫建設的經驗，在建設數據倉庫的時候能夠總結出一套適合自己的建模方法，能夠更好的幫助客戶去發揮數據倉庫的作用。

本文主要的主線就是回答下面三個問題：

什麽是數據模型
為什麽需要數據模型
如何建設數據模型
最後，我們在本文的結尾給大家介紹了一個具體的數據倉庫建模的樣例，幫助大家來了解整個數據建模的過程。

一、 什麽是數據模型

數據模型是抽象描述現實世界的一種工具和方法，是通過抽象的實體及實體之間聯系的形式，來表示現實世界中事務的相互關系的一種映射。在這裏，數據模型表現的抽象的是實體和實體之間的關系，通過對實體和實體之間關系的定義和描述，來表達實際的業務中具體的業務關系。

數據倉庫模型是數據模型中針對特定的數據倉庫應用系統的一種特定的數據模型，一般的來說，我們數據倉庫模型分為幾下幾個層次，如圖 2 所示。

圖 2. 數據倉庫模型

通過上面的圖形，我們能夠很容易的看出在整個數據倉庫得建模過程中，我們需要經歷一般四個過程：

業務建模，生成業務模型，主要解決業務層面的分解和程序化。
領域建模，生成領域模型，主要是對業務模型進行抽象處理，生成領域概念模型。
邏輯建模，生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關系進行數據庫層次的邏輯化。
物理建模，生成物理模型，主要解決，邏輯模型針對不同關系型數據庫的物理化以及性能等一些具體的技術問題。
因此，在整個數據倉庫的模型的設計和架構中，既涉及到業務知識，也涉及到了具體的技術，我們既需要了解豐富的行業經驗，同時，也需要一定的信息技術來幫助我們實現我們的數據模型，最重要的是，我們還需要一個非常適用的方法論，來指導我們自己針對我們的業務進行抽象，處理，生成各個階段的模型。

二、 為什麽需要數據模型

在數據倉庫的建設中，我們一再強調需要數據模型，那麽數據模型究竟為什麽這麽重要呢？首先我們需要了解整個數據倉庫的建設的發展史。

數據倉庫的發展大致經歷了這樣的三個過程：

簡單報表階段：這個階段，系統的主要目標是解決一些日常的工作中業務人員需要的報表，以及生成一些簡單的能夠幫助領導進行決策所需要的匯總數據。這個階段的大部分表現形式為數據庫和前端報表工具。
數據集市階段：這個階段，主要是根據某個業務部門的需要，進行一定的數據的采集，整理，按照業務人員的需要，進行多維報表的展現，能夠提供對特定業務指導的數據，並且能夠提供特定的領導決策數據。
數據倉庫階段：這個階段，主要是按照一定的數據模型，對整個企業的數據進行采集，整理，並且能夠按照各個業務部門的需要，提供跨部門的，完全一致的業務報表數據，能夠通過數據倉庫生成對對業務具有指導性的數據，同時，為領導決策提供全面的數據支持。
通過數據倉庫建設的發展階段，我們能夠看出，數據倉庫的建設和數據集市的建設的重要區別就在於數據模型的支持。因此，數據模型的建設，對於我們數據倉庫的建設，有著決定性的意義。

一般來說，數據模型的建設主要能夠幫助我們解決以下的一些問題：

進行全面的業務梳理，改進業務流程。在業務模型建設的階段，能夠幫助我們的企業或者是管理機關對本單位的業務進行全面的梳理。通過業務模型的建設，我們應該能夠全面了解該單位的業務架構圖和整個業務的運行情況，能夠將業務按照特定的規律進行分門別類和程序化，同時，幫助我們進一步的改進業務的流程，提高業務效率，指導我們的業務部門的生產。
建立全方位的數據視角，消滅信息孤島和數據差異。通過數據倉庫的模型建設，能夠為企業提供一個整體的數據視角，不再是各個部門只是關註自己的數據，而且通過模型的建設，勾勒出了部門之間內在的聯系，幫助消滅各個部門之間的信息孤島的問題，更為重要的是，通過數據模型的建設，能夠保證整個企業的數據的一致性，各個部門之間數據的差異將會得到有效解決。
解決業務的變動和數據倉庫的靈活性。通過數據模型的建設，能夠很好的分離出底層技術的實現和上層業務的展現。當上層業務發生變化時，通過數據模型，底層的技術實現可以非常輕松的完成業務的變動，從而達到整個數據倉庫系統的靈活性。
幫助數據倉庫系統本身的建設。通過數據倉庫的模型建設，開發人員和業務人員能夠很容易的達成系統建設範圍的界定，以及長期目標的規劃，從而能夠使整個項目組明確當前的任務，加快整個系統建設的速度。
三、 如何建設數據模型

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

1) 數據倉庫數據模型架構

數據倉庫的數據模型的架構和數據倉庫的整體架構是緊密關聯在一起的，我們首先來了解一下整個數據倉庫的數據模型應該包含的幾個部分。從下圖我們可以很清楚地看到，整個數據模型的架構分成 5 大部分，每個部分其實都有其獨特的功能。

圖 3. 數據倉庫數據模型架構

從上圖我們可以看出，整個數據倉庫的數據模型可以分為大概 5 大部分：

系統記錄域（System of Record）：這部分是主要的數據倉庫業務數據存儲區，數據模型在這裏保證了數據的一致性。
內部管理域（Housekeeping）：這部分主要存儲數據倉庫用於內部管理的元數據，數據模型在這裏能夠幫助進行統一的元數據的管理。
匯總域（Summary of Area）：這部分數據來自於系統記錄域的匯總，數據模型在這裏保證了分析域的主題分析的性能，滿足了部分的報表查詢。
分析域（Analysis Area）：這部分數據模型主要用於各個業務部分的具體的主題業務分析。這部分數據模型可以單獨存儲在相應的數據集市中。
反饋域（Feedback Area）：可選項，這部分數據模型主要用於相應前端的反饋數據，數據倉庫可以視業務的需要設置這一區域。
通過對整個數據倉庫模型的數據區域的劃分，我們可以了解到，一個好的數據模型，不僅僅是對業務進行抽象劃分，而且對實現技術也進行具體的指導，它應該涵蓋了從業務到實現技術的各個部分。

2) 數據倉庫建模階段劃分

我們前面介紹了數據倉庫模型的幾個層次，下面我們講一下，針對這幾個層次的不同階段的數據建模的工作的主要內容：

圖 4. 數據倉庫建模階段劃分

從上圖我們可以清楚地看出，數據倉庫的數據建模大致分為四個階段：

1. 業務建模，這部分建模工作，主要包含以下幾個部分：

劃分整個單位的業務，一般按照業務部門的劃分，進行各個部分之間業務工作的界定，理清各業務部門之間的關系。
深入了解各個業務部門的內具體業務流程並將其程序化。
提出修改和改進業務部門工作流程的方法並程序化。
數據建模的範圍界定，整個數據倉庫項目的目標和階段劃分。

1. 領域概念建模，這部分得建模工作，主要包含以下幾個部分：

抽取關鍵業務概念，並將之抽象化。
將業務概念分組，按照業務主線聚合類似的分組概念。
細化分組概念，理清分組概念內的業務流程並抽象化。
理清分組概念之間的關聯，形成完整的領域概念模型。大數據精英課程，雲計算，數據分析，數據倉庫，數據爬蟲，項目實戰，用戶畫像，日誌分析，全文檢索，項目監控，性能調優，系統架構，電商數據分析，電商行為日誌分析，電商實時分析系統，分布式計算平臺，分布式集群部署，實時流計算，全端數據統計分析系統，堵車預測系統實戰，共享單車實戰，電信級海量數據處理，分布式消息系統，日誌傳輸實戰，大型電商項目與數據應用實戰，Hadoop，Flink，Spark，Kafka，Storm，Docker，Kubernetes(K8s)，ElaticStack，HBase，SparkSQL，Hive，Flume，ETL，DMP等高端視頻課程......

1. 邏輯建模，這部分的建模工作，主要包含以下幾個部分：

業務概念實體化，並考慮其具體的屬性
事件實體化，並考慮其屬性內容
說明實體化，並考慮其屬性內容

1. 物理建模，這部分得建模工作，主要包含以下幾個部分：

針對特定物理化平臺，做出相應的技術調整
針對模型的性能考慮，對特定平臺作出相應的調整
針對管理的需要，結合特定的平臺，做出相應的調整
生成最後的執行腳本，並完善之。
從我們上面對數據倉庫的數據建模階段的各個階段的劃分，我們能夠了解到整個數據倉庫建模的主要工作和工作量，希望能夠對我們在實際的項目建設能夠有所幫助。

3) 數據倉庫建模方法

大千世界，表面看五彩繽紛，實質上，萬物都遵循其自有的法則。數據倉庫的建模方法同樣也有很多種，每一種建模方法其實代表了哲學上的一個觀點，代表了一種歸納，概括世界的一種方法。目前業界較為流行的數據倉庫的建模方法非常多，這裏主要介紹範式建模法，維度建模法，實體建模法等幾種方法，每種方法其實從本質上講就是從不同的角度看我們業務中的問題，不管從技術層面還是業務層面，其實代表的是哲學上的一種世界觀。我們下面給大家詳細介紹一下這些建模方法。

1. 範式建模法（Third Normal Form，3NF）

範式建模法其實是我們在構建數據模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關系型數據庫得數據存儲，利用的一種技術層面上的方法。目前，我們在關系型數據庫中的建模方法，大部分采用的是三範式建模法。

範式是數據庫邏輯模型設計的基本理論，一個關系模型可以從第一範式到第五範式進行無損分解，這個過程也可稱為規範化。在數據倉庫的模型設計中目前一般采用第三範式，它有著嚴格的數學定義。從其表達的含義來看，一個符合第三範式的關系必須具有以下三個條件 :

每個屬性值唯一，不具有多義性 ;
每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分 ;
每個非主屬性不能依賴於其他關系中的屬性，因為這樣的話，這種屬性應該歸到其他關系中去。
由於範式是基於整個關系型數據庫的理論基礎之上發展而來的，因此，本人在這裏不多做介紹，有興趣的讀者可以通過閱讀相應的材料來獲得這方面的知識。

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

圖 5. 範式建模法

從業務數據模型轉向數據倉庫模型時，同樣也需要有數據倉庫的域模型，即概念模型，同時也存在域模型的邏輯模型。這裏，業務模型中的數據模型和數據倉庫的模型稍微有一些不同。主要區別在於：

數據倉庫的域模型應該包含企業數據模型的域模型之間的關系，以及各主題域定義。數據倉庫的域模型的概念應該比業務系統的主題域模型範圍更加廣。
在數據倉庫的邏輯模型需要從業務系統的數據模型中的邏輯模型中抽象實體，實體的屬性，實體的子類，以及實體的關系等。
以筆者的觀點來看，Inmon 的範式建模法的最大優點就是從關系型數據庫的角度出發，結合了業務系統的數據模型，能夠比較方便的實現數據倉庫的建模。但其缺點也是明顯的，由於建模方法限定在關系型數據庫之上，在某些時候反而限制了整個數據倉庫模型的靈活性，性能等，特別是考慮到數據倉庫的底層數據向數據集市的數據進行匯總時，需要進行一定的變通才能滿足相應的需求。因此，筆者建議讀者們在實際的使用中，參考使用這一建模方式。

1. 維度建模法

維度建模法，Kimball 最先提出這一概念。其最簡單的描述就是，按照事實表，維表來構建數據倉庫，數據集市。這種方法的最被人廣泛知曉的名字就是星型模式（Star-schema）。

圖 6. 維度建模法

上圖的這個架構中是典型的星型架構。星型模式之所以廣泛被使用，在於針對各個維作了大量的預處理，如按照維進行預先的統計、分類、排序等。通過這些預處理，能夠極大的提升數據倉庫的處理能力。特別是針對 3NF 的建模方法，星型模式在性能上占據明顯的優勢。

雪花模型也是維度建模中的一種選擇。雪花模型的維度表可以擁有其他維度表的，雖然這種模型相比星型模型更規範一些，但是由於這種模型不太容易理解，維護成本比較高，而且性能方面需要關聯多層維表，性能也比星型模型要低。所以一般不是很常用。雪花模型如下圖

同時，維度建模法的另外一個優點是，維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優勢。

但是，維度建模法的缺點也是非常明顯的，由於在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些與處理過程中，往往會導致大量的數據冗余。

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

因此以筆者的觀點看，維度建模的領域主要適用與數據集市層，它的最大的作用其實是為了解決數據倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的復雜關系的抽象方法。

1. 實體建模法

實體建模法並不是數據倉庫建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關系組成。那麽我們在數據倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關系，以及針對這些關系的說明就是我們數據建模需要做的工作。

雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業務過程劃分成 3 個部分，實體，事件和說明，如下圖所示：

圖 7. 實體建模法

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

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

實體，主要指領域模型中特定的概念主體，指發生業務關系的對象。
事件，主要指概念主體之間完成一次業務流程的過程，特指特定的業務過程。
說明，主要是針對實體和事件的特殊說明。
由於實體建模法，能夠很輕松的實現業務模型的劃分，因此，在業務建模階段和領域概念建模階段，實體建模法有著廣泛的應用。從筆者的經驗來看，再沒有現成的行業模型的情況下，我們可以采用實體建模的方法，和客戶一起理清整個業務的模型，進行領域概念模型的劃分，抽象出具體的業務概念，結合客戶的使用特點，完全可以創建出一個符合自己需要的數據倉庫模型來。

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

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

四、 數據倉庫建模樣例

上面介紹得是一些抽象得建模方法和理論，可能理解起來相對有些難度，因此，筆者在這裏舉一個例子，讀者可以跟著我們的這個樣例，來初步了解整個數據倉庫建模的大概過程。

熟悉社保行業的讀者可以知道，目前我們國家的社保主要分為養老，失業，工傷，生育，醫療保險和勞動力市場這 6 大塊主要業務領域。在這 6 大業務領域中，目前的狀況養老和事業的系統已經基本完善，已經有一部分數據開始聯網檢測。而，對於工傷，生育，醫療和勞動力市場這一塊業務，有些地方發展的比較成熟，而有些地方還不夠成熟。

1.業務建模階段

基於以上的背景介紹，我們在業務建模階段，就很容易來劃分相應的業務。因此，在業務建模階段，我們基本上確定我們本次數據倉庫建設的目標，建設的方法，以及長遠規劃等。如下圖：

大數據數據倉庫-基於大數據體系構建數據倉庫（Hive，Flume，Kafka，Azkaban，Oozie，SparkSQL）