看了很多數據倉庫方面的資料，都涉及到了“數據集市”這一說法，剛開始對數據倉庫和數據集市的區別也理解得比較膚淺，現在做個深入的歸納和總結，主要從如下幾個方面進行闡述：
（1）?基本概念
（2）?為什么提出數據集市
（3）?數據倉庫設計方法論
（4）?數據集市和數據倉庫的區別
（5）?倉庫建模與集市建模
（6）?案例分析：電信CRM數據倉庫
Bill Inmon說過一句話叫“IT經理們面對最重要的問題就是到底先建立數據倉庫還是先建立數據集市”，足以說明搞清楚這兩者之間的關系是十分重要而迫切的！通常在考慮建立數據倉庫之前，會涉及到如下一些問題：
（1）?采取自上而下還是自下而上的設計方法
（2）?企業范圍還是部門范圍
（3）?先建立數據倉庫還是數據集市
（4）?建立領航系統還是直接實施
（5）?數據集市是否相互獨立
?
一、基本概念
數據倉庫一詞尚沒有一個統一的定義,著名的數據倉庫專家W. H. Inmon 在其著作《Buildingthe Data Warehouse》一書中給予如下描述:數據倉庫(Data Warehouse) 是一個面向主題的(SubjectOri2ented) 、集成的( Integrate ) 、相對穩定的(Non -Volatile ) 、反映歷史變化( TimeVariant) 的數據集合用于支持管理決策。對于數據倉庫的概念我們可以從兩個層次予以理解,首先,數據倉庫用于支持決策,面向分析型數據處理,它不同于企業現有的操作型數據庫;其次,數據倉庫是對多個異構的數據源有效集成,集成后按照主題進行了重組,并包含歷史數據,而且存放在數據倉庫中的數據一般不再修改。
為最大限度地實現靈活性，集成的數據倉庫的數據應該存儲在標準RDBMS 中，并經過規范的數據庫設計，以及為了提高性能而增加一些小結性信息和不規范設計。這種類型的數據倉庫設計被稱為原子數據倉庫。原子數據倉庫的子集,又稱為數據集市。原子倉庫存在的主要目的是作為數據集市的工作基礎，同時也作為參照性數據倉庫。原子倉庫的大小、集中存放和數據庫設計可能無法滿足特殊類型用戶的各種需求。其子集,即各個數據集市被拷貝到其它計算機上,可作為它們自己的數據倉庫。數據集市可以和產生它們的原子數據倉庫一樣大,甚至更大。它們可以位于原子數據倉庫的附近，或分布到更靠近用戶的位置，放置在何處取決于使用和通訊成本。數據集市是用來滿足特殊用戶的應用需求的數據倉庫，它們的規模可能達到數百GB。使其成為數據集市的關鍵是它的使用目標、范圍，而非規模大小。
數據集市可以理解為是一個小型的部門或者工作組級別的數據倉庫。有兩種類型的數據集市（如下圖）：
?
獨立型（直接從操作型環境中獲取數據）：這些數據集市是由特定的工作組、部門或業務線進行控制的，完全是為滿足其需求而構建的。實際上，它們甚至與其他工作組、部門或業務線中的數據集市沒有任何連通性
從屬型（從企業級數據倉庫中獲取數據）：這樣的數據集市往往以分布式的方式實現。雖然不同的數據集市是在特定的工作組、部門或生產線中實現的，但它們可以是集成、互連的，以提供更加全局的業務范圍的數據視圖。實際上，在最高的集成層次上，它們可以成為業務范圍的數據倉庫。這意味著一個部門中的終端用戶可以訪問和使用另一部門中數據集市中的數據
?
二、為什么提出數據集市
雖然 OLTP 和遺留系統擁有寶貴的信息，但是可能難以從這些系統中提取有意義的信息并且速度也較慢。而且這些系統雖然一般可支持預先定義操作的報表，但卻經常無法支持一個組織對于歷史的、聯合的、智能的或易于訪問的信息的需求。因為數據分布在許多跨系統和平臺的表中，而且通常是“臟的”，包含了不一致的和無效的值，使得難于分析。
數據集市將合并不同系統的數據源來滿足業務信息需求。若能有效地得以實現，數據集市將可以快速且方便地訪問簡單信息以及系統的和歷史的視圖。一個設計良好的數據集市有如下特點（有些特點數據倉庫也具有，有些特點是相對于數據倉庫來講的）：
(1)?特定用戶群體所需的信息，通常是一個部門或者一個特定組織的用戶，且無需受制于源系統的大量需求和操作性危機（想對于數據倉庫）。
(2)?支持訪問非易變（nonvolatile）的業務信息。（非易變的信息是以預定的時間間隔進行更新的，并且不受 OLTP 系統進行中的更新的影響。）
(3)?調和來自于組織里多個運行系統的信息，比如賬目、銷售、庫存和客戶管理以及組織外部的行業數據。
(4)?通過默認有效值、使各系統的值保持一致以及添加描述以使隱含代碼有意義，從而提供凈化的（cleansed）數據。
(5)?為即席分析和預定義報表提供合理的查詢響應時間（由于數據集市是部門級的，相對于龐大的數據倉庫來講，其查詢和分析的響應時間會大大縮短）。
三、數據倉庫設計方法論
在數據倉庫建立之前，會考慮其實現方法，通常有自頂向下、自底向上和兩者綜合進行的這樣三種實現方案，下面分別對其做簡要闡述：
(1)自頂向下的實現
自頂向下的方法就是在單個項目階段中實現數據倉庫。自頂向下的實現需要在項目開始時完成更多計劃和設計工作。這就需要涉及參與數據倉庫實現的每個工作組、部門或業務線中的人員。要使用的數據源、安全性、數據結構、數據質量、數據標準和整個數據模型的有關決策一般需要在真正的實現開始之前就完成。
(2)自底向上的實現
自底向上的實現包含數據倉庫的計劃和設計，無需等待安置好更大業務范圍的數據倉庫設計。這并不意味著不會開發更大業務范圍的數據倉庫設計；隨著初始數據倉庫實現的擴展，將逐漸增加對它的構建。現在，該方法得到了比自頂向下方法更廣泛的接受，因為數據倉庫的直接結果可以實現，并可以用作擴展更大業務范圍實現的證明。
(3)一種折中方案
每種實現方法都有利弊。在許多情況下，最好的方法可能是某兩種的組合。該方法的關鍵之一就是確定業務范圍的架構需要用于支持集成的計劃和設計的程度，因為數據倉庫是用自底向上的方法進行構建。在使用自底向上或階段性數據倉庫項目模型來構建業務范圍架構中的一系列數據集市時，您可以一個接一個地集成不同業務主題領域中的數據集市，從而形成設計良好的業務數據倉庫。這樣的方法可以極好地適用于業務。在這種方法中，可以把數據集市理解為整個數據倉庫系統的邏輯子集，換句話說數據倉庫就是一致化了的數據集市的集合。這種方案的實施步驟通常分如下幾步：
(6)?從整個企業的角度定義計劃和需求
(7)?構建完整的倉庫體系結構
(8)?使數據內容一致而且標準化
(9)?將數據倉庫作為一種超級數據集市來實施
關于Inmon 和 Kimball的大辯論：
Ralph Kimball 和 Bill Inmon 一直是商業智能領域中的革新者，開發并測試了新的技術和體系結構。
Bill Inmon 將數據倉庫定義為“一個面向主題的、集成的、隨時間變化的、非易變的用于支持管理的決策過程的數據集合”；他通過“面向主題”表示應該圍繞主題來組織數據倉庫中的數據，例如客戶、銷售、產品等等。每個主題區域僅僅包含該主題相關的信息。數據倉庫應該一次增加一個主題，并且當需要容易地訪問多個主題時，應該創建以數據倉庫為來源的數據集市。換言之，某個特定數據集市中的所有數據都應該來自于面向主題的數據存儲。 Inmon 的方法包含了更多上述工作而減少了對于信息的初始訪問。但他認為這個集中式的體系結構持續下去將提供更強的一致性和靈活性，并且從長遠來看將真正節省資源和工作。下圖是他的設計方法圖解：
?
Ralph Kimball 說“數據倉庫僅僅是構成它的數據集市的聯合”，他認為“可以通過一系列維數相同的數據集市遞增地構建數據倉庫”。每個數據集市將聯合多個數據源來滿足特定的業務需求。通過使用“一致的”維，能夠共同看到不同數據集市中的信息，這表示它們擁有公共定義的元素。設計方法如下圖：
?
?? Kimball 的方法將提供集成的數據來回答組織迫切的業務問題并且要快于 Inmon 的方法。Inmon 的方法是只有在構建幾個單主題區域之后，集中式的數據倉庫才創建數據集市。而 Kimball 認為該方法缺乏靈活性并且在現在的商業環境中所花時間太長。
實際上，方法的選擇取決于項目的主要商業驅動。如果該組織正忍受糟糕的數據管理和不一致的數據，或者希望為今后打下良好的基礎，那么 Inmon 的方法就更好一些。 如果該組織迫切需要給用戶提供信息，那么 Kimball 的方法將滿足該需求。而一旦滿足了迫切的信息需求后，就應該考慮包含獨立數據倉庫的數據體系結構的轉換計劃。數據倉庫將使數據集市與遺留系統和 OLTP 系統隔離，并且支持更快地創建將來的數據集市。由于數據倉庫在整個發展中一直承擔了重任，所以它將支持極力關注數據集市。實際上基于商業驅動的需要，采用上面三種設計方案中的最后一種方法：自頂向下和自底向上綜合的方案會很好的適應數據倉庫建立過程中的不同需求。
四、數據倉庫與數據集市的區別
數據倉庫是企業級的，能為整個企業各個部門的運行提供決策支持手段；而數據集市則是一種微型的數據倉庫,它通常有更少的數據,更少的主題區域,以及更少的歷史數據,因此是部門級的，一般只能為某個局部范圍內的管理人員服務，因此也稱之為部門級數據倉庫。數據倉庫和數據集市之間的區別如下圖：
數據倉庫和數據集市的區別可從如下三個方面進行理解：
（1）?數據倉庫向各個數據集市提供數據
（2）?幾個部門的數據集市組成一個數據倉庫
?
（3） 下面從其數據內容特征進行分析，數據倉庫中數據結構采用規范化模式，數據集市中的數據結構采用星型模式，通常倉庫中數據粒度比集市的粒度要細，下圖反映了數據結構和數據內容特征的區別
?
?
五、數據倉庫建模與數據集市建模
數據只是所有業務活動、資源以及企業結果的記錄。數據模型是對那些數據的組織良好的抽象，因此數據模型成為理解和管理企業業務的最佳方法是極其自然的。數據模型起到了指導或計劃數據倉庫的實現的作用。在真正的實現開始之前，聯合每個業務領域的數據模型可以幫助確保其結果是有效的數據倉庫，并且可以幫助減少實現的成本。
(1)數據倉庫的建模
數據倉庫數據的建模是將需求轉換成圖畫以及支持表示那些需求的元數據的過程。出于易讀性目的，本文將關于需求和建模的討論相分離，但實際上這些步驟通常是重疊的。一旦在文檔中記錄一些初始需求，初始模型就開始成型。隨著需求變得更加完整，模型也會如此。
最重要的是向終端用戶提供良好集成并易于解釋的數據倉庫的邏輯模型。這些邏輯模型是數據倉庫元數據的核心之一。為終端用戶提供的簡單性以及歷史數據的集成和聯合是建模方法應該幫助提供的關鍵原則。
(2)數據集市的數據建模
因為倉庫終端用戶直接與數據集市進行交互，所以數據集市的建模是捕獲終端用戶業務需求的最有效工具之一。數據集市的建模過程取決于許多因素。下面描述了三個最重要的：
數據集市的建模是終端用戶驅動的。終端用戶必須參與數據集市的建模過程，因為他們顯然是要使用該數據集市的人。因為您應期望終端用戶完全不熟悉復雜的數據模型，所以應該將建模技術和建模過程作為整體進行組織，以便使復雜性對終端用戶透明。
數據集市的建模是由業務需求驅動的。數據集市模型對于捕獲業務需求十分有用，因為它們通常由終端用戶直接使用，且易于理解。
數據集市的建模極大地受到了數據分析技術的影響。數據分析技術可以影響所選擇的數據模型的類型及其內容。目前，有幾種常用的數據分析技術：查詢和報表制作、多維分析以及數據挖掘。
如果僅僅意圖提供查詢和報表制作功能，那么帶有正規（normalized）或非正規（denormalized）數據結構的 ER 模型就是最合適的。維度數據模型也可能是較好的選擇，因為它是用戶友好的，并具有更好的性能。如果其目標是執行多維數據分析，那么維度數據模型就是這里的惟一選擇。然而，數據挖掘通常在可用的最低細節級（level of detail）工作得最好。因此，如果數據倉庫是用于數據挖掘的，就應該在模型中包含較低細節級（level of detail）的數據。
凡是有該標志的文章，都是該blog博主Caoer（草兒）原創，凡是索引、收藏
、轉載請注明來處和原文作者。非常感謝。