浅谈数据仓库建设中的数据建模方法
http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0803zhousb/
所謂水無定勢，兵無常法。不同的行業，有不同行業的特點，因此，從業務角度看，其相應的數據模型是千差萬別的。目前業界較為主流的是數據倉庫廠商主要是 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 個呢？你們的數據倉庫模型的依據又是什么？其實這是我們在給客戶介紹我們的數據模型時，經常被問到的一個問題，我希望讀者在讀完本文時，能夠找到自己的答案。
雖然每個行業有自己的模型，但是，我們發現，不同行業的數據模型，在數據建模的方法上，卻都有著共通的基本特點。
本文的主要目的之一，就是希望讀者能夠通過對本文的閱讀，同時，結合自己對數據倉庫建設的經驗，在建設數據倉庫的時候能夠總結出一套適合自己的建模方法，能夠更好的幫助客戶去發揮數據倉庫的作用。
本文主要的主線就是回答下面三個問題：
- 什么是數據模型
- 為什么需要數據模型
- 如何建設數據模型
最后，我們在本文的結尾給大家介紹了一個具體的數據倉庫建模的樣例，幫助大家來了解整個數據建模的過程。
什么是數據模型
數據模型是抽象描述現實世界的一種工具和方法，是通過抽象的實體及實體之間聯系的形式，來表示現實世界中事務的相互關系的一種映射。在這里，數據模型表現的抽象的是實體和實體之間的關系，通過對實體和實體之間關系的定義和描述，來表達實際的業務中具體的業務關系。
數據倉庫模型是數據模型中針對特定的數據倉庫應用系統的一種特定的數據模型，一般的來說，我們數據倉庫模型分為幾下幾個層次，如圖 1 所示。
圖 2. 數據倉庫模型
通過上面的圖形，我們能夠很容易的看出在整個數據倉庫得建模過程中，我們需要經歷一般四個過程：
- 業務建模，生成業務模型，主要解決業務層面的分解和程序化。
- 領域建模，生成領域模型，主要是對業務模型進行抽象處理，生成領域概念模型。
- 邏輯建模，生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關系進行數據庫層次的邏輯化。
- 物理建模，生成物理模型，主要解決，邏輯模型針對不同關系型數據庫的物理化以及性能等一些具體的技術問題。
因此，在整個數據倉庫的模型的設計和架構中，既涉及到業務知識，也涉及到了具體的技術，我們既需要了解豐富的行業經驗，同時，也需要一定的信息技術來幫助我們實現我們的數據模型，最重要的是，我們還需要一個非常適用的方法論，來指導我們自己針對我們的業務進行抽象，處理，生成各個階段的模型。
回頁首
為什么需要數據模型
在數據倉庫的建設中，我們一再強調需要數據模型，那么數據模型究竟為什么這么重要呢？首先我們需要了解整個數據倉庫的建設的發展史。
數據倉庫的發展大致經歷了這樣的三個過程：
- 簡單報表階段：這個階段，系統的主要目標是解決一些日常的工作中業務人員需要的報表，以及生成一些簡單的能夠幫助領導進行決策所需要的匯總數據。這個階段的大部分表現形式為數據庫和前端報表工具。
- 數據集市階段：這個階段，主要是根據某個業務部門的需要，進行一定的數據的采集，整理，按照業務人員的需要，進行多維報表的展現，能夠提供對特定業務指導的數據，并且能夠提供特定的領導決策數據。
- 數據倉庫階段：這個階段，主要是按照一定的數據模型，對整個企業的數據進行采集，整理，并且能夠按照各個業務部門的需要，提供跨部門的，完全一致的業務報表數據，能夠通過數據倉庫生成對對業務具有指導性的數據，同時，為領導決策提供全面的數據支持。
通過數據倉庫建設的發展階段，我們能夠看出，數據倉庫的建設和數據集市的建設的重要區別就在于數據模型的支持。因此，數據模型的建設，對于我們數據倉庫的建設，有著決定性的意義。
一般來說，數據模型的建設主要能夠幫助我們解決以下的一些問題：
- 進行全面的業務梳理，改進業務流程。在業務模型建設的階段，能夠幫助我們的企業或者是管理機關對本單位的業務進行全面的梳理。通過業務模型的建設，我們應該能夠全面了解該單位的業務架構圖和整個業務的運行情況，能夠將業務按照特定的規律進行分門別類和程序化，同時，幫助我們進一步的改進業務的流程，提高業務效率，指導我們的業務部門的生產。
- 建立全方位的數據視角，消滅信息孤島和數據差異。通過數據倉庫的模型建設，能夠為企業提供一個整體的數據視角，不再是各個部門只是關注自己的數據，而且通過模型的建設，勾勒出了部門之間內在的聯系，幫助消滅各個部門之間的信息孤島的問題，更為重要的是，通過數據模型的建設，能夠保證整個企業的數據的一致性，各個部門之間數據的差異將會得到有效解決。
- 解決業務的變動和數據倉庫的靈活性。通過數據模型的建設，能夠很好的分離出底層技術的實現和上層業務的展現。當上層業務發生變化時，通過數據模型，底層的技術實現可以非常輕松的完成業務的變動，從而達到整個數據倉庫系統的靈活性。
- 幫助數據倉庫系統本身的建設。通過數據倉庫的模型建設，開發人員和業務人員能夠很容易的達成系統建設范圍的界定，以及長期目標的規劃，從而能夠使整個項目組明確當前的任務，加快整個系統建設的速度。
回頁首
如何建設數據模型
建設數據模型既然是整個數據倉庫建設中一個非常重要的關鍵部分，那么，怎么建設我們的數據倉庫模型就是我們需要解決的一個問題。這里我們將要詳細介紹如何創建適合自己的數據模型。
數據倉庫數據模型架構
數據倉庫的數據模型的架構和數據倉庫的整體架構是緊密關聯在一起的，我們首先來了解一下整個數據倉庫的數據模型應該包含的幾個部分。從下圖我們可以很清楚地看到，整個數據模型的架構分成 5 大部分，每個部分其實都有其獨特的功能。
圖 3. 數據倉庫數據模型架構
從上圖我們可以看出，整個數據倉庫的數據模型可以分為大概 5 大部分：
- 系統記錄域（System of Record）：這部分是主要的數據倉庫業務數據存儲區，數據模型在這里保證了數據的一致性。
- 內部管理域（Housekeeping）：這部分主要存儲數據倉庫用于內部管理的元數據，數據模型在這里能夠幫助進行統一的元數據的管理。
- 匯總域（Summary of Area）：這部分數據來自于系統記錄域的匯總，數據模型在這里保證了分析域的主題分析的性能，滿足了部分的報表查詢。
- 分析域（Analysis Area）：這部分數據模型主要用于各個業務部分的具體的主題業務分析。這部分數據模型可以單獨存儲在相應的數據集市中。
- 反饋域（Feedback Area）：可選項，這部分數據模型主要用于相應前端的反饋數據，數據倉庫可以視業務的需要設置這一區域。
通過對整個數據倉庫模型的數據區域的劃分，我們可以了解到，一個好的數據模型，不僅僅是對業務進行抽象劃分，而且對實現技術也進行具體的指導，它應該涵蓋了從業務到實現技術的各個部分。
數據倉庫建模階段劃分
我們前面介紹了數據倉庫模型的幾個層次，下面我們講一下，針對這幾個層次的不同階段的數據建模的工作的主要內容：
圖 4. 數據倉庫建模階段劃分
從上圖我們可以清楚地看出，數據倉庫的數據建模大致分為四個階段：
業務建模，這部分建模工作，主要包含以下幾個部分：
- 劃分整個單位的業務，一般按照業務部門的劃分，進行各個部分之間業務工作的界定，理清各業務部門之間的關系。
- 深入了解各個業務部門的內具體業務流程并將其程序化。
- 提出修改和改進業務部門工作流程的方法并程序化。
- 數據建模的范圍界定，整個數據倉庫項目的目標和階段劃分。
領域概念建模，這部分得建模工作，主要包含以下幾個部分：
- 抽取關鍵業務概念，并將之抽象化。
- 將業務概念分組，按照業務主線聚合類似的分組概念。
- 細化分組概念，理清分組概念內的業務流程并抽象化。
- 理清分組概念之間的關聯，形成完整的領域概念模型。
邏輯建模，這部分的建模工作，主要包含以下幾個部分：
- 業務概念實體化，并考慮其具體的屬性
- 事件實體化，并考慮其屬性內容
- 說明實體化，并考慮其屬性內容
物理建模，這部分得建模工作，主要包含以下幾個部分：
- 針對特定物理化平臺，做出相應的技術調整
- 針對模型的性能考慮，對特定平臺作出相應的調整
- 針對管理的需要，結合特定的平臺，做出相應的調整
- 生成最后的執行腳本，并完善之。
從我們上面對數據倉庫的數據建模階段的各個階段的劃分，我們能夠了解到整個數據倉庫建模的主要工作和工作量，希望能夠對我們在實際的項目建設能夠有所幫助。
數據倉庫建模方法
大千世界，表面看五彩繽紛，實質上，萬物都遵循其自有的法則。數據倉庫得建模方法同樣也有很多種，每一種建模方法其實代表了哲學上的一個觀點，代表了一種歸納，概括世界的一種方法。目前業界較為流行的數據倉庫的建模方法非常多，這里主要介紹范式建模法，維度建模法，實體建模法等幾種方法，每種方法其實從本質上講就是從不同的角度看我們業務中的問題，不管從技術層面還是業務層面，其實代表的是哲學上的一種世界觀。我們下面給大家詳細介紹一下這些建模方法。
1. 范式建模法（Third Normal Form，3NF）
范式建模法其實是我們在構建數據模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關系型數據庫得數據存儲，利用的一種技術層面上的方法。目前，我們在關系型數據庫中的建模方法，大部分采用的是三范式建模法。
范式是數據庫邏輯模型設計的基本理論，一個關系模型可以從第一范式到第五范式進行無損分解，這個過程也可稱為規范化。在數據倉庫的模型設計中目前一般采用第三范式，它有著嚴格的數學定義。從其表達的含義來看，一個符合第三范式的關系必須具有以下三個條件 :
- 每個屬性值唯一，不具有多義性 ;
- 每個非主屬性必須完全依賴于整個主鍵，而非主鍵的一部分 ;
- 每個非主屬性不能依賴于其他關系中的屬性，因為這樣的話，這種屬性應該歸到其他關系中去。
由于范式是基于整個關系型數據庫的理論基礎之上發展而來的，因此，本人在這里不多做介紹，有興趣的讀者可以通過閱讀相應的材料來獲得這方面的知識。
根據 Inmon 的觀點，數據倉庫模型得建設方法和業務系統的企業數據模型類似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關系型數據庫上的實例話。
圖 5. 范式建模法
從業務數據模型轉向數據倉庫模型時，同樣也需要有數據倉庫的域模型，即概念模型，同時也存在域模型的邏輯模型。這里，業務模型中的數據模型和數據倉庫的模型稍微有一些不同。主要區別在于：
- 數據倉庫的域模型應該包含企業數據模型得域模型之間的關系，以及各主題域定義。數據倉庫的域模型的概念應該比業務系統的主題域模型范圍更加廣。
- 在數據倉庫的邏輯模型需要從業務系統的數據模型中的邏輯模型中抽象實體，實體的屬性，實體的子類，以及實體的關系等。
以筆者的觀點來看，Inmon 的范式建模法的最大優點就是從關系型數據庫的角度出發，結合了業務系統的數據模型，能夠比較方便的實現數據倉庫的建模。但其缺點也是明顯的，由于建模方法限定在關系型數據庫之上，在某些時候反而限制了整個數據倉庫模型的靈活性，性能等，特別是考慮到數據倉庫的底層數據向數據集市的數據進行匯總時，需要進行一定的變通才能滿足相應的需求。因此，筆者建議讀者們在實際的使用中，參考使用這一建模方式。
2. 維度建模法
維度建模法，Kimball 最先提出這一概念。其最簡單的描述就是，按照事實表，維表來構建數據倉庫，數據集市。這種方法的最被人廣泛知曉的名字就是星型模式（Star-schema）。
圖 6. 維度建模法
上圖的這個架構中是典型的星型架構。星型模式之所以廣泛被使用，在于針對各個維作了大量的預處理，如按照維進行預先的統計、分類、排序等。通過這些預處理，能夠極大的提升數據倉庫的處理能力。特別是針對 3NF 的建模方法，星型模式在性能上占據明顯的優勢。
同時，維度建模法的另外一個優點是，維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優勢。
但是，維度建模法的缺點也是非常明顯的，由于在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些與處理過程中，往往會導致大量的數據冗余。
另外一個維度建模法的缺點就是，如果只是依靠單純的維度建模，不能保證數據來源的一致性和準確性，而且在數據倉庫的底層，不是特別適用于維度建模的方法。
因此以筆者的觀點看，維度建模的領域主要適用與數據集市層，它的最大的作用其實是為了解決數據倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的復雜關系的抽象方法。
3. 實體建模法
實體建模法并不是數據倉庫建模中常見的一個方法，它來源于哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實體，以及實體與實體之間的關系組成。那么我們在數據倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成一個個的實體，而每個實體之間的關系，以及針對這些關系的說明就是我們數據建模需要做的工作。
雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業務過程劃分成 3 個部分，實體，事件和說明，如下圖所示：
圖 7. 實體建模法
上圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體，“上學”描述的是一個業務過程，我們在這里可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。
從上面的舉例我們可以了解，我們使用的抽象歸納方法其實很簡單，任何業務可以看成 3 個部分：
- 實體，主要指領域模型中特定的概念主體，指發生業務關系的對象。
- 事件，主要指概念主體之間完成一次業務流程的過程，特指特定的業務過程。
- 說明，主要是針對實體和事件的特殊說明。
由于實體建模法，能夠很輕松的實現業務模型的劃分，因此，在業務建模階段和領域概念建模階段，實體建模法有著廣泛的應用。從筆者的經驗來看，再沒有現成的行業模型的情況下，我們可以采用實體建模的方法，和客戶一起理清整個業務的模型，進行領域概念模型的劃分，抽象出具體的業務概念，結合客戶的使用特點，完全可以創建出一個符合自己需要的數據倉庫模型來。
但是，實體建模法也有著自己先天的缺陷，由于實體說明法只是一種抽象客觀世界的方法，因此，注定了該建模方法只能局限在業務建模和領域概念建模階段。因此，到了邏輯建模階段和物理建模階段，則是范式建模和維度建模發揮長處的階段。
因此，筆者建議讀者在創建自己的數據倉庫模型的時候，可以參考使用上述的三種數據倉庫得建模方法，在各個不同階段采用不同的方法，從而能夠保證整個數據倉庫建模的質量。
回頁首
數據倉庫建模樣例
上面介紹得是一些抽象得建模方法和理論，可能理解起來相對有些難度，因此，筆者在這里舉一個例子，讀者可以跟著我們的這個樣例，來初步了解整個數據倉庫建模的大概過程。
背景介紹
熟悉社保行業的讀者可以知道，目前我們國家的社保主要分為養老，失業，工傷，生育，醫療保險和勞動力市場這 6 大塊主要業務領域。在這 6 大業務領域中，目前的狀況養老和事業的系統已經基本完善，已經有一部分數據開始聯網檢測。而，對于工傷，生育，醫療和勞動力市場這一塊業務，有些地方發展的比較成熟，而有些地方還不夠成熟。
1.業務建模階段
基于以上的背景介紹，我們在業務建模階段，就很容易來劃分相應的業務。因此，在業務建模階段，我們基本上確定我們本次數據倉庫建設的目標，建設的方法，以及長遠規劃等。如下圖：
圖 8. 業務建模階段
在這里，我們將整個業務很清楚地劃分成了幾個大的業務主線，例如：養老，失業，工傷，生育，醫療，勞動力等著幾個大的部分，然后我們可以根據這些大的模塊，在每個業務主線內，考慮具體的業務主線內需要分析的業務主題。
因此，業務建模階段其實是一次和業務人員梳理業務的過程，在這個過程中，不僅能幫助我們技術人員更好的理解業務，另一方面，也能夠發現業務流程中的一些不合理的環節，加以改善和改進。
同時，業務建模階段的另一個重要工作就是確定我們數據建模的范圍，例如：在某些數據準備不夠充分的業務模塊內，我們可以考慮先不建設相應的數據模型。等到條件充分成熟的情況下，我們可以再來考慮數據建模的問題。
2.領域概念建模階段
領域概念建模階段是數據倉庫數據建模的一個重要階段，由于我們在業務建模階段已經完全理清相應的業務范圍和流程，因此，我們在這個領域概念建模階段的最主要的工作就是進行概念的抽象，整個領域概念建模的工作層次如下圖所示：
圖 9. 領域概念建模階段
從上圖我們可以清楚地看到，領域概念建模就是運用了實體建模法，從紛繁的業務表象背后通過實體建模法，抽象出實體，事件，說明等抽象的實體，從而找出業務表象后抽象實體間的相互的關聯性，保證了我們數據倉庫數據按照數據模型所能達到的一致性和關聯性。
從圖上看，我們可以把整個抽象過程分為四個層次，分別為：
- 抽象方法層，整個數據模型的核心方法，領域概念建模的實體的劃分通過這種抽象方法來實現。
- 領域概念層，這是我們整個數據模型的核心部分，因為不同程度的抽象方法，決定了我們領域概念的不同。例如：在這里，我們可以使用“參與方”這個概念，同時，你也可以把他分成三個概念：“個人”，“公司”，和“經辦機構”這三個概念。而我們在構建自己的模型的時候，可以參考業務的狀況以及我們自己模型的需要，選擇抽象程度高的概念或者是抽象程度低的概念。相對來說，抽象程度高的概念，理解起來較為復雜，需要專業的建模專家才能理解，而抽象程度低的概念，較適合于一般業務人員的理解，使用起來比較方便。筆者在這里建議讀者可以選用抽象概念較低的實體，以方便業務人員和技術人員之間的交流和溝通。
- 具體業務層，主要是解決具體的業務問題，從這張圖我們可以看出，具體的業務層，其實只是領域概念模型中實體之間的一些不同組合而已。因此，完整的數據倉庫的數據模型應該能夠相應靈活多變的前端業務的需求，而其本身的模型架構具有很強的靈活性。這也是數據倉庫模型所具備的功能之一。
- 業務主線層，這個層次主要劃分大的業務領域，一般在業務建模階段即已經完成這方面的劃分。我們一般通過這種大的業務主線來劃分整個業務模型大的框架。
通過領域概念建模，數據倉庫的模型已經被抽象成一個個的實體，模型的框架已經搭建完畢，下面的工作就是給這些框架注入有效的肌體。
3.邏輯建模階段
通過領域概念建模之后，雖然模型的框架已經完成，但是還有很多細致的工作需要完成。一般在這個階段，我們還需要做非常多的工作，主要包括：
- 實例話每一個抽象的實體，例如：在上面的概念模型之后，我們需要對“人”和“公司”等這些抽象實體進行實例化。主要是，我們需要考慮“人”的屬性包括那些，在業務模塊中，用到的所有跟“人”相關的屬性是哪些，我們都需要將這些屬性附著在我們數據模型的“人”這個實體上，例如“人”得年齡，性別，受教育程度等等。同理，我們對其他屬性同樣需要做這個工作。
- 找出抽象實體間的聯系，并將其實例話。這里，我們主要考慮是“事件”這個抽象概念的實例話，例如：對于養老金征繳這個“事件”的屬性得考慮，對于失業勞動者培訓這個“事件”的屬性得考慮等等。
- 找出抽象事件的關系，并對其進行說明。在這里我們主要是要針對“事件”進行完善的“說明”。例如：對于“事件”中的地域，事件等因素的考量等等。
總而言之，在邏輯建模階段，我們主要考慮得是抽象實體的一些細致的屬性。通過邏輯建模階段，我們才能夠將整個概念模型完整串聯成一個有機的實體，才能夠完整的表達出業務之間的關聯性。
在這個階段，筆者建議大家可以參考 3NF 的建模方法，表達出實體的屬性，以及實體與實體之間的聯系。例如：在這個階段，我們可以通過采用 ERWIN 等建模工具等作出符合 3NF 的關系型數據模型來。
4.物理建模階段
物理建模階段是整個數據建模的最后一個過程，這個過程其實是將前面的邏輯數據模型落地的一個過程。考慮到數據倉庫平臺的不同，因此，數據模型得物理建模過程可能會稍微有一些不同，在這個階段我們主要的工作是：
- 生成創建表的腳本。不同的數據倉庫平臺可能生成不同的腳本。
- 針對不同的數據倉庫平臺，進行一些相應的優化工作，例如對于 DB2 數據倉庫來說，創建一些 MQT 表，來加速報表的生成等等。
- 針對數據集市的需要，按照維度建模的方法，生成一些事實表，維表等工作。
- 針對數據倉庫的 ETL 車和元數據管理的需要，生成一些數據倉庫維護的表，例如：日志表等。
經過物理建模階段，整個數據倉庫的模型已經全部完成，我們可以按照自己的設計來針對當前的行業創建滿足自己需要的數據模型來。
這里，筆者通過一個數據建模的樣例，希望能夠給讀者一個關于數據倉庫建模的感性的認識。希望讀者在利用這些數據倉庫得建模方法創建自己的數據模型的時候，可以根據業務實際的需要和自己對抽象能力的把握來創建適合自己的數據模型。
回頁首
參考資料：
- 用 Rational Data Architect 簡化數據建模和集成設計。
- 通過訪問 IM 和 Rational 集成應用開發專欄 獲得更多建模方面的文章、教程和多媒體課件等的技術資源。
- 通過訪問 developerWorks IM 專區 獲得更多文章、教程和多媒體課件等的技術資源。
- 通過參與 developerWorks blog 加入 developerWorks 社區。
關于作者
周三保(zhousb@cn.ibm.com) IBM 軟件部信息技術專家.
?
總結
以上是生活随笔為你收集整理的浅谈数据仓库建设中的数据建模方法的全部內容，希望文章能夠幫你解決所遇到的問題。
