一.資料倉儲的資料模型
1.系統記錄域（system of record）：這部分是主要的資料倉儲業務資料儲存區，資料模型在這裡保證了資料的一致性。
2.內部管理域（housekeeping）：這部分主要儲存資料倉儲用於內部管理的元資料，資料模型在這裡能夠幫助進行統一的元資料的管理。
3.彙總域（summary of area）：這部分資料來自於系統記錄域的彙總，資料模型在這裡保證了分析域的主題分析的效能，滿足了部分的報表查詢。(中心，其它域圍繞著他)
4.分析域（analysis area）：這部分資料模型主要用於各個業務部分的具體的主題業務分析。這部分資料模型可以單獨儲存在相應的資料集市中。
5.反饋域（feedback area）：可選項，這部分資料模型主要用於相應前端的反饋資料，資料倉儲可以視業務的需要設定這一區域。
二.資料建模階段劃分
1. 業務建模，這部分建模工作，主要包含以下幾個部分：
劃分整個單位的業務，一般按照業務部門的劃分，進行各個部分之間業務工作的界定，理清各業務部門之間的關係。
深入了解各個業務部門的內具體業務流程並將其程式化。
提出修改和改進業務部門工作流程的方法並程式化。
資料建模的範圍界定，整個資料倉儲專案的目標和階段劃分。
2. 領域概念建模，這部分得建模工作，主要包含以下幾個部分：
抽取關鍵業務概念，並將之抽象化。
將業務概念分組，按照業務主線聚合類似的分組概念。
細化分組概念，理清分組概念內的業務流程並抽象化。
理清分組概念之間的關聯，形成完整的領域概念模型。
3. 邏輯建模，這部分的建模工作，主要包含以下幾個部分：
業務概念實體化，並考慮其具體的屬性
事件實體化，並考慮其屬性內容
說明實體化，並考慮其屬性內容
4. 物理建模，這部分得建模工作，主要包含以下幾個部分：
針對特定物理化平台，做出相應的技術調整
針對模型的效能考慮，對特定平台作出相應的調整
針對管理的需要，結合特定的平台，做出相應的調整
生成最後的執行指令碼，並完善之。
三.資料倉儲建模方法
1. 正規化建模法（third normal form，3nf）
正規化建模法其實是我們在構建資料模型常用的乙個方法，該方法的主要由 inmon 所提倡，主要解決關係型資料庫得資料儲存，利用的一種技術層面上的方法。目前，我們在關係型資料庫中的建模方法，大部分採用的是三正規化建模法。
在資料倉儲的模型設計中目前一般採用第三正規化，它有著嚴格的數學定義。從其表達的含義來看,乙個符合第三正規化的關係必須具有以下三個條件 :
每個屬性值唯一，不具有多義性 ;
每個非主屬性必須完全依賴於整個主鍵，而非主鍵的一部分 ;
每個非主屬性不能依賴於其他關係中的屬性，因為這樣的話，這種屬性應該歸到其他關係中去。
由於正規化是基於整個關係型資料庫的理論基礎之上發展而來的，因此，本人在這裡不多做介紹，有興趣的讀者可以通過閱讀相應的材料來獲得這方面的知識。
根據 inmon 的觀點，資料倉儲模型得建設方法和業務系統的企業資料模型類似。在業務系統中，企業資料模型決定了資料的**，而企業資料模型也分為兩個層次，即主題域模型和邏輯模型。同樣，主題域模型可以看成是業務模型的概念模型，而邏輯模型則是域模型在關係型資料庫上的例項。
從業務資料模型轉向資料倉儲模型時，同樣也需要有資料倉儲的域模型，即概念模型，同時也存在域模型的邏輯模型。這裡，業務模型中的資料模型和資料倉儲的模型稍微有一些不同。主要區別在於：
資料倉儲的域模型應該包含企業資料模型的域模型之間的關係，以及各主題域定義。資料倉儲的域模型的概念應該比業務系統的主題域模型範圍更加廣。
在資料倉儲的邏輯模型需要從業務系統的資料模型中的邏輯模型中抽象實體，實體的屬性，實體的子類，以及實體的關係等。
以筆者的觀點來看，inmon 的正規化建模法的最大優點就是從關係型資料庫的角度出發，結合了業務系統的資料模型，能夠比較方便的實現資料倉儲的建模。但其缺點也是明顯的，由於建模方法限定在關係型資料庫之上，在某些時候反而限制了整個資料倉儲模型的靈活性，效能等，特別是考慮到資料倉儲的底層資料向資料集市的資料進行彙總時，需要進行一定的變通才能滿足相應的需求。因此，筆者建議讀者們在實際的使用中，參考使用這一建模方式。
2.維度建模法，kimball 最先提出這一概念。其最簡單的描述就是，按照事實表，維表來構建資料倉儲，資料集市。這種方法的最被人廣泛知曉的名字就是星型模式（star-schema）。
上圖的這個架構中是典型的星型架構。星型模式之所以廣泛被使用，在於針對各個維作了大量的預處理，如按照維進行預先的統計、分類、排序等。通過這些預處理，能夠極大的提公升資料倉儲的處理能力。特別是針對 3nf 的建模方法，星型模式在效能上佔據明顯的優勢。
同時，維度建模法的另外乙個優點是，維度建模非常直觀，緊緊圍繞著業務模型，可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理，即可以完成維度建模。這一點也是維度建模的優勢。
但是，維度建模法的缺點也是非常明顯的，由於在構建星型模式之前需要進行大量的資料預處理，因此會導致大量的資料處理工作。而且，當業務發生變化，需要重新進行維度的定義時，往往需要重新進行維度資料的預處理。而在這些與處理過程中，往往會導致大量的資料冗餘。
另外乙個維度建模法的缺點就是，如果只是依靠單純的維度建模，不能保證資料**的一致性和準確性，而且在資料倉儲的底層，不是特別適用於維度建模的方法。
因此以筆者的觀點看，維度建模的領域主要適用與資料集市層，它的最大的作用其實是為了解決資料倉儲建模中的效能問題。維度建模很難能夠提供乙個完整地描述真實業務實體之間的複雜關係的抽象方法。
3.實體建模法並不是資料倉儲建模中常見的乙個方法，它**於哲學的乙個流派。從哲學的意義上說，客觀世界應該是可以細分的，客觀世界應該可以分成由乙個個實體，以及實體與實體之間的關係組成。那麼我們在資料倉儲的建模過程中完全可以引入這個抽象的方法，將整個業務也可以劃分成乙個個的實體，而每個實體之間的關係，以及針對這些關係的說明就是我們資料建模需要做的工作。
雖然實體法粗看起來好像有一些抽象，其實理解起來很容易。即我們可以將任何乙個業務過程劃分成 3 個部分，實體，事件和說明，如下圖所示：
上圖表述的是乙個抽象的含義，如果我們描述乙個簡單的事實：「小明開車去學校上學」。以這個業務事實為例，我們可以把「小明」，「學校」看成是乙個實體，「上學」描述的是乙個業務過程，我們在這裡可以抽象為乙個具體「事件」，而「開車去」則可以看成是事件「上學」的乙個說明。
從上面的舉例我們可以了解，我們使用的抽象歸納方法其實很簡單，任何業務可以看成 3 個部分：
實體，主要指領域模型中特定的概念主體，指發生業務關係的物件。
事件，主要指概念主體之間完成一次業務流程的過程，特指特定的業務過程。
說明，主要是針對實體和事件的特殊說明。
由於實體建模法，能夠很輕鬆的實現業務模型的劃分，因此，在業務建模階段和領域概念建模階段，實體建模法有著廣泛的應用。從筆者的經驗來看，再沒有現成的行業模型的情況下，我們可以採用實體建模的方法，和客戶一起理清整個業務的模型，進行領域概念模型的劃分，抽象出具體的業務概念，結合客戶的使用特點，完全可以建立出乙個符合自己需要的資料倉儲模型來。
但是，實體建模法也有著自己先天的缺陷，由於實體說明法只是一種抽象客觀世界的方法，因此，注定了該建模方法只能侷限在業務建模和領域概念建模階段。因此，到了邏輯建模階段和物理建模階段，則是正規化建模和維度建模發揮長處的階段。
因此，筆者建議讀者在建立自己的資料倉儲模型的時候，可以參考使用上述的三種資料倉儲得建模方法，在各個不同階段採用不同的方法，從而能夠保證整個資料倉儲建模的質量。
參考《hadoop 構建資料倉儲實踐》
資料倉儲系列 簡介 李孟 新浪部落格
打算做資料倉儲系列，可能會時間上跨度很大，畢竟現在專案比較繁忙。一.資料倉儲定義 資料倉儲，英文名稱為data warehouse，可簡寫為dw或dwh。資料倉儲，是為企業所有級別的決策制定過程，提供所有型別資料支援的戰略集合。它出於分析性報告和決策支援目的而建立。為需要業務智慧型的企業，提供指導業...
資料倉儲系列 維度表技術 李孟 新浪部落格
維度表技術常見 增加列，維度子集，角色扮演維度，層次維度，退化維度，雜項維度，維度合併，分段維度等基本維度表技術。一 增加列 事實表和維度表上增加列。hive上增加列，慎用alter table。原因老版本的hive對orc格式表的模式修改，尤其是增加列的支援存在很多問題。jira上說2.0.0修復...
hue介紹系列02 李孟 新浪部落格
配置cd etc hue conf vi hue.ini desktop default hdfs superuser hadoop hdfs管理使用者 desktop http host 10.10.41.123 hue web server所在主機 ip desktop http port 80...