一、前言
數據倉庫得建模方法同樣也有很多種，每一種建模方法其實代表了哲學上的一個觀點，代表了一種歸 納，概括世界的一種方法。目前業界較為流行的數據倉庫的建模方法非常多，這里主要介紹范式建模法，維度建模法，實體建模法等幾種方法，每種方法其實從本質 上講就是從不同的角度看我們業務中的問題，不管從技術層面還是業務層面，其實代表的是哲學上的一種世界觀。我們下面給大家詳細介紹一下這些建模方法。
二、3NF范式建模方法
范式建模法其實是我們在構建數據模型常用的一個方法，該方法的主要由 Inmon 所提倡，主要解決關系型數據庫得數據存儲，利用的一種技術層面上的方法。目前，我們在關系型數據庫中的建模方法，大部分采用的是三范式建模法。
范式是數據庫邏輯模型設計的基本理論，一個關系模型可以從第一范式到第五范式進行無損分解，這個過程也可稱為規范化。在數據倉庫的模型設計中目前一般采用第三范式，它有着嚴格的數學定義。從其表達的含義來看，一個符合第三范式的關系必須具有以下三個條件 :
- 每個屬性值唯一，不具有多義性 ;
- 每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分 ;
- 每個非主屬性不能依賴於其他關系中的屬性，因為這樣的話，這種屬性應該歸到其他關系中去。
由於范式是基於整個關系型數據庫的理論基礎之上發展而來的，因此，本人在這里不多做介紹，有興趣的讀者可以通過閱讀相應的材料來獲得這方面的知識。
根 據 Inmon 的觀點，數據倉庫模型得建設方法和業務系統的企業數據模型類似。在業務系統中，企業數據模型決定了數據的來源，而企業數據模型也分為兩個層次，即主題域模 型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關系型數據庫上的實例話。
從業務數據模型轉向數據倉庫模型時，同樣也需要有數據倉庫的域模型，即概念模型，同時也存在域模型的邏輯模型。這里，業務模型中的數據模型和數據倉庫的模型稍微有一些不同。主要區別在於：
- 數據倉庫的域模型應該包含企業數據模型得域模型之間的關系，以及各主題域定義。數據倉庫的域模型的概念應該比業務系統的主題域模型范圍更加廣。
- 在數據倉庫的邏輯模型需要從業務系統的數據模型中的邏輯模型中抽象實體，實體的屬性，實體的子類，以及實體的關系等。
三、維度建模
維度建模法，Kimball 最先提出這一概念。其最簡單的描述就是，按照事實表，維表來構建數據倉庫，數據集市。這種方法的最被人廣泛知曉的名字就是星型模式（Star-schema）。
上圖的這個架構中是典型的星型架構。星型模式之所以廣泛被使用，在於針對各個維作了大量的預處理，如按照維進行預先的統計、分類、排序等。通過這些預處理，能夠極大的提升數據倉庫的處理能力。特別是針對 3NF 的建模方法，星型模式在性能上占據明顯的優勢。
同時，維度建模法的另外一個優點是，維度建模非常直觀，緊緊圍繞着業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優勢。
但是，維度建模法的缺點也是非常明顯的，由於在構建星型模式之前需要進行大量的數據預處理，因此會導致大量的數據處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度數據的預處理。而在這些與處理過程中，往往會導致大量的數據冗余。
另外一個維度建模法的缺點就是，如果只是依靠單純的維度建模，不能保證數據來源的一致性和准確性，而且在數據倉庫的底層，不是特別適用於維度建模的方法。
因此以筆者的觀點看，維度建模的領域主要適用與數據集市層，它的最大的作用其實是為了解決數據倉庫建模中的性能問題。維度建模很難能夠提供一個完整地描述真實業務實體之間的復雜關系的抽象方法。
四、實體建模法
實 體建模法並不是數據倉庫建模中常見的一個方法，它來源於哲學的一個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由一個個實 體，以及實體與實體之間的關系組成。那么我們在數據倉庫的建模過程中完全可以引入這個抽象的方法，將整個業務也可以划分成一個個的實體，而每個實體之間的 關系，以及針對這些關系的說明就是我們數據建模需要做的工作。
雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何一個業務過程划分成 3 個部分，實體，事件和說明，如下圖所示：
上 圖表述的是一個抽象的含義，如果我們描述一個簡單的事實：“小明開車去學校上學”。以這個業務事實為例，我們可以把“小明”，“學校”看成是一個實體， “上學”描述的是一個業務過程，我們在這里可以抽象為一個具體“事件”，而“開車去”則可以看成是事件“上學”的一個說明。
從上面的舉例我們可以了解，我們使用的抽象歸納方法其實很簡單，任何業務可以看成 3 個部分：
- 實體，主要指領域模型中特定的概念主體，指發生業務關系的對象。
- 事件，主要指概念主體之間完成一次業務流程的過程，特指特定的業務過程。
- 說明，主要是針對實體和事件的特殊說明。
由 於實體建模法，能夠很輕松的實現業務模型的划分，因此，在業務建模階段和領域概念建模階段，實體建模法有着廣泛的應用。從筆者的經驗來看，再沒有現成的行 業模型的情況下，我們可以采用實體建模的方法，和客戶一起理清整個業務的模型，進行領域概念模型的划分，抽象出具體的業務概念，結合客戶的使用特點，完全 可以創建出一個符合自己需要的數據倉庫模型來。
但是，實體建模法也有着自己先天的缺陷，由於實體說明法只是一種抽象客觀世界的方法，因此，注定了該建模方法只能局限在業務建模和領域概念建模階段。因此，到了邏輯建模階段和物理建模階段，則是范式建模和維度建模發揮長處的階段。
五、總結
以上資料來源於社區整理，算是數據倉庫模型的基礎理論介紹，其實幾十年的發展，數據倉庫模型已經有深厚的積累，尤其是一些大的數據倉庫供應商：
銀行業：IBM有BDWM(Banking Data Warehouse Model)；Teradata有FS-LDM(Financial Services Logical Data Model)。
電信業：IBM有TDWM(Telecom Data Warehouse Model)；Teradata有TS-LDM(Telecom Services Logical Data Model)。
Teradata FS-LDM7.0是一個成熟產品，在一個集成的模型內支持保險、銀行及證券，包含十大主題：當事人、產品、協議、事件、資產、財務、機構、地域、營銷、渠道。
不要重復造車輪子，建議采用或者直接參考以上成熟的數據倉庫模型，可以將項目實施的風險降到最低，當然是要花錢購買相關模型的。