1. 什麼是數據集市？數據集市與數據倉庫的區別？
數據倉庫(Data Warehouse) 是一個面向主題的(Subject Oriented) 、集成的( Integrate ) 、相對穩定的(Non -Volatile ) 、反映歷史變化( Time Variant)的數據集合用於支持管理決策。對於數據倉庫的概念我們可以從兩個層次予以理解,首先,數據倉庫用於支持決策,面向分析型數據處理,它不同於企業現有的操作型數據庫;其次,數據倉庫是對多個異構的數據源有效集成,集成後按照主題進行了重組,幷包含歷史數據,而且存放在數據倉庫中的數據一般不再修改。（注：該定義來自於著名的數據倉庫專家W. H. Inmon 的著作《Buildingthe Data Warehouse》一書）。
數據集市也叫數據市場，是一個從操作的數據和其他的爲某個特殊的專業人員團體服務的數據源中收集數據的倉庫。從範圍上來說，數據是從企業範圍的數據庫、數據倉庫，或者是更加專業的數據倉庫中抽取出來的。數據中心的重點就在於它迎合了專業用戶羣體的特殊需求，在分析、內容、表現，以及易用方面。數據中心的用戶希望數據是由他們熟悉的術語表現的。
數據集市是企業級數據倉庫的一個子集，他主要面向部門級業務，並且只面向某個特定的主題。爲了解決靈活性和性能之間的矛盾，數據集市就是數據倉庫體系結構中增加的一種小型的部門或工作組級別的數據倉庫。數據集市存儲爲特定用戶預先計算好的數據，從而滿足用戶對性能的需求。數據集市可以在一定程度上緩解訪問數據倉庫的瓶頸。
數據集市的特徵主要有：1）規模小；2）面向部門；3）有特定的應用；4）由業務部門定義、設計和開發；5）業務部門管理和維護；6）能快速實現；7）購買比較便宜；8）投資快速回收；9）工具集的緊密集成；10）提供更詳細的、預先存在的、數據倉庫的摘要子集；11）可升級到完整的數據倉庫。
數據集市和數據倉庫的主要區別：數據倉庫是企業級的，能爲整個企業各個部門的運行提供決策支持手段；而數據集市則是一種微型的數據倉庫,它通常有更少的數據,更少的主題區域,以及更少的歷史數據,因此是部門級的，一般只能爲某個局部範圍內的管理人員服務，因此也稱之爲部門級數據倉庫。
|
|
數據倉庫 |
數據集市 |
|
數據的來源 |
生產系統、外部數據等 |
數據倉庫 |
|
範圍規模 |
企業級 |
部門級或工作組級 |
|
主題 |
以企業爲主題 |
以部門或特殊的分析爲主題 |
|
數據粒度 |
最細的粒度 |
較粗的粒度 |
|
數據結構 |
第三範式，規範化結構 |
星型模型、雪花模型、星座模型 |
|
歷史數據 |
大量的歷史數據 |
適度的歷史數據 |
|
優化 |
處理海量數據、數據探索 |
便於訪問和分析、快速查詢 |
|
索引 |
高度索引 |
高度索引 |
數據集市可以分爲兩種類型——獨立型數據集市和從屬型數據集市。獨立型數據集市直接從操作型環境獲取數據，從屬型數據集市從企業級數據倉庫獲取數據，帶有從屬型數據集市的體系結構如圖2所示。
數據倉庫規模大、週期長，一些規模比較小的企業用戶難以承擔。因此，作爲快速解決企業當前存在的實際問題的一種有效方法，獨立型數據集市成爲一種既成事實。獨立型數據集市是爲滿足特定用戶（一般是部門級別的）的需求而建立的一種分析型環境，它能夠快速地解決某些具體的問題，而且投資規模也比數據倉庫小很多。
獨立型數據集市的存在會給人造成一種錯覺，似乎可以先獨立地構建數據集市，當數據集市達到一定的規模再直接轉換爲數據倉庫。有些銷售人員會推銷這種觀點，其實質卻常常是因爲建立企業級數據倉庫的銷售週期太長以至於不好操作。
多個獨立的數據集市的累積，是不能形成一個企業級的數據倉庫的，這是由數據倉庫和數據集市本身的特點決定的——數據集市爲各個部門或工作組所用，各個集市之間存在不一致性是難免的。因爲脫離數據倉庫的緣故，當多個獨立型數據集市增長到一定規模之後，由於沒有統一的數據倉庫協調，企業只會又增加一些信息孤島，仍然不能以整個企業的視圖分析數據。借用Inmon的比喻：我們不可能將大海里的小魚堆在一起就構成一頭大鯨魚，這也說明了數據倉庫和數據集市有本質的不同。
如果企業最終想建設一個全企業統一的數據倉庫，想要以整個企業的視圖分析數據，獨立型數據集市恐怕不是合適的選擇；也就是說“先獨立地構建數據集市，當數據集市達到一定的規模再直接轉換爲數據倉庫”是不合適的。從長遠的角度看，從屬型數據集市在體系結構上比獨立型數據集市更穩定，可以說是數據集市未來建設的主要方向。
2. 爲什麼要有數據集市？良好的數據集市有什麼特點？
雖然 OLTP 和遺留系統擁有寶貴的信息，但是可能難以從這些系統中提取有意義的信息並且速度也較慢。而且這些系統雖然一般可支持預先定義操作的報表，但卻經常無法支持一個組織對於歷史的、聯合的、智能的或易於訪問的信息的需求。因爲數據分佈在許多跨系統和平臺的表中，而且通常是“髒的”，包含了不一致的和無效的值，使得難於分析。
數據集市將合併不同系統的數據源來滿足業務信息需求。若能有效地得以實現，數據集市將可以快速且方便地訪問簡單信息以及系統的和歷史的視圖。一個設計良好的數據集市有如下特點（有些特點數據倉庫也具有，有些特點是相對於數據倉庫來講的）：
(1) 特定用戶羣體所需的信息，通常是一個部門或者一個特定組織的用戶，且無需受制於源系統的大量需求和操作性危機（相對於數據倉庫）。
(2) 支持訪問非易變（nonvolatile）的業務信息。（非易變的信息是以預定的時間間隔進行更新的，並且不受 OLTP 系統進行中的更新的影響。）
(3) 調和來自於組織裏多個運行系統的信息，比如賬目、銷售、庫存和客戶管理以及組織外部的行業數據。
(4) 通過默認有效值、使各系統的值保持一致以及添加描述以使隱含代碼有意義，從而提供淨化的（cleansed）數據。
(5) 爲即席分析和預定義報表提供合理的查詢響應時間（由於數據集市是部門級的，相對於龐大的數據倉庫來講，其查詢和分析的響應時間會大大縮短）。
3. 數據集市的數據結構
數據集市中數據的結構通常被描述爲星型結構或雪花結構。一個星型結構包含兩個基本部分——一個事實表和各種支持維表。
（1） 事實表
事實表描述數據集市中最密集的數據。在電話公司中，用於呼叫的數據是典型的最密集數據；在銀行中，與賬目覈對和自動櫃員機有關的數據是典型的最密集數據。對於零售業而言，銷售和庫存數 據是最密集的數據等等。
事實表是預先被連接到一起的多種類型數據的組合體，它包括：一個反映事實表建立目的的實體的主鍵，如一張訂單、一次銷售、一個電話等等，主鍵信息，連接事實表與維表的外鍵，外鍵攜帶的非鍵值外部數據。如果這種非鍵外部數據經常用於事實表中的數據分析，它就會被包括在事實表的範圍內。事實表是高度索引化的。事實表中出現30到40條索引非常常見。有時實事表的每列都建了索引，這樣作的結果是使事實表中的數據非常容易讀取。但是，導入索引所需的資源數量必須爲等式提供因數。通常，事實表的數據不能更改，但可以輸入數據，一旦正確輸入一個記錄，就不能更改此記錄的任何內容了。
（2） 維表
維表是圍繞事實表建立的。維表包含非密集型數據，它通過外鍵與事實表相連。典型的維表建立在數據集市的基礎上，包括產品目錄、客戶名單、廠商列表等等。
數據集市中的數據來源於企業數據倉庫。所有數據，除了一個例外，在導入到數據集市之前都應該經過企業數據倉庫。這個例外就是用於數據集市的特定數據，它不能用於數據倉庫的其他地方。外部數據通常屬於這類範疇。如果情況不是這樣，數據就會用於決策支持系統的其他地方，那麼這些數據就必須經過企業數據倉庫。
數據集市包含兩種類型的數據，通常是詳細數據和彙總數據。
（3） 詳細數據
數據集市中的詳細數據包含在星型結構中。當數據通過企業數據倉庫時，星型結構就會很好的彙總。在這種情況下，企業數據倉庫包含必需的基本數據，而數據集市則包含更高間隔尺寸的數據。但是，在數據集市使用者的心目中，星型結構的數據和數據獲取時一樣詳細。
（4） 彙總數據
數據集市包含的第二種類型數據是彙總數據。分析人員通常從星型結構中的數據創建各種彙總數據。典型的彙總可能是銷售區域的月銷售總額。因爲彙總的基礎不斷髮展變化，所以歷史數據就在數據集市中。但是這些歷史數據優勢在於它存儲的概括水平。星型結構中保存的歷史數據非常少。
數據集市以企業數據倉庫爲基礎進行更新。對於數據集市來說大約每週更新一次非常平常。但是，數據集市的更新時間可以少於一週也可以多於一週，這主要是由數據集市所屬部門的需求來決定的。
4. 如何建立數據集市？
數據倉庫（集市）的設計可以採用迭代式的方法。在迭代式開發中，每個迭代爲上一次的結果增加了新的功能。功能增加的順序要考慮到迭代平衡以及儘早發現重大風險。通俗地說，就是在正式交貨之前多次給客戶交付不完善的中間產品“試用”。這些中間產品會有一些功能還沒有添加進去、還不穩定，但是客戶提出修改意見以後，開發人員能夠更好地理解客戶的需求。如此反覆，使得產品在質量上能夠逐漸逼近客戶的要求。這種開發方法週期長、成本高，但是它能夠避免整個項目推倒重來的風險，比較適合大項目、高風險項目。
理論上講，應該有一個總的數據倉庫的概念，然後纔有數據集市。實際建設數據倉庫（集市）的時候，國內很少這麼做。國內一般會先從數據集市入手，就某一個特定的主題（比如企業的客戶信息）先做數據集市，再建設數據倉庫。數據倉庫和數據集市建立的先後次序之分，是和設計方法緊密相關的。而數據倉庫作爲工程學科，並沒有對錯之分，主要判別方式應該是能否解決目前存在的實際問題，併爲今後可能發生的問題保持一定的可伸縮性。
5. 數據倉庫建模與數據集市建模
數據只是所有業務活動、資源以及企業結果的記錄。數據模型是對那些數據的組織良好的抽象，因此數據模型成爲理解和管理企業業務的最佳方法是極其自然的。數據模型起到了指導或計劃數據倉庫的實現的作用。在真正的實現開始之前，聯合每個業務領域的數據模型可以幫助確保其結果是有效的數據倉庫，並且可以幫助減少實現的成本。
(1)數據倉庫的建模
數據倉庫數據的建模是將需求轉換成圖畫以及支持表示那些需求的元數據的過程。出於易讀性目的，本文將關於需求和建模的討論相分離，但實際上這些步驟通常是重疊的。一旦在文檔中記錄一些初始需求，初始模型就開始成型。隨着需求變得更加完整，模型也會如此。
最重要的是向終端用戶提供良好集成並易於解釋的數據倉庫的邏輯模型。這些邏輯模型是數據倉庫元數據的核心之一。爲終端用戶提供的簡單性以及歷史數據的集成和聯合是建模方法應該幫助提供的關鍵原則。
(2)數據集市的數據建模
因爲倉庫終端用戶直接與數據集市進行交互，所以數據集市的建模是捕獲終端用戶業務需求的最有效工具之一。數據集市的建模過程取決於許多因素。下面描述了三個最重要的：
數據集市的建模是終端用戶驅動的。終端用戶必須參與數據集市的建模過程，因爲他們顯然是要使用該數據集市的人。因爲您應期望終端用戶完全不熟悉複雜的數據模型，所以應該將建模技術和建模過程作爲整體進行組織，以便使複雜性對終端用戶透明。
數據集市的建模是由業務需求驅動的。數據集市模型對於捕獲業務需求十分有用，因爲它們通常由終端用戶直接使用，且易於理解。
數據集市的建模極大地受到了數據分析技術的影響。數據分析技術可以影響所選擇的數據模型的類型及其內容。目前，有幾種常用的數據分析技術：查詢和報表製作、多維分析以及數據挖掘。
如果僅僅意圖提供查詢和報表製作功能，那麼帶有正規（normalized）或非正規（denormalized）數據結構的 ER 模型就是最合適的。維度數據模型也可能是較好的選擇，因爲它是用戶友好的，並具有更好的性能。如果其目標是執行多維數據分析，那麼維度數據模型就是這裏的惟一選擇。然而，數據挖掘通常在可用的最低細節級（level of detail）工作得最好。因此，如果數據倉庫是用於數據挖掘的，就應該在模型中包含較低細節級（level of detail）的數據。
6. 數據集市常見的誤區：
誤區1：數據集市是比較小的。用大小來判斷一個企業是在實施數據倉庫還是數據集市的做法是很天真的。一種定義認爲數據量小於50GB 的數據庫是數據集市，大於50GB 的是數據倉庫。事實上， 數據集市集中解決的是某一種業務功能的特殊需要，並且維持數據和數據模型來滿足這種要求。尺寸大小不是數據集市的本質特徵，因爲它同樣可以有幾百GB 的描述更多細節的數據。數據集市也可以只有幾個GB 的綜合數據就可以滿足面向應用的執行信息系統的需要。真正的問題在於，數據集市（它可能是一個數據倉庫的子集）的數據模型一定是滿足應用的特定需求的。
誤區2：數據集市容易建立，可以更快地投入運行。一個單一的數據集市的確比數據倉庫的複雜性程度低一些，因爲它只針對某一需要解決的特定的商業問題，但是圍繞數據獲取的很多複雜問題並沒有減少。數據獲取包括從可以使用的數據源中提取、確認和集成數據， 把它們輸送到數據集市和數據倉庫中。
參考文獻：
http://www.mie168.com/CRM/2003-04/3733.htm
http://www.hudong.com/wiki/%E6%95%B0%E6%8D%AE%E9%9B%86%E5%B8%82
