簡介
兩種類型的數據集市單獨的DB2資料庫包括企業的數據集市。每個數據集市包括來自中央數據倉庫的歷史數據的子集，用以滿足特定部門、團隊、客戶或應用程式分析和報告需求。主管此DB2資料庫的系統稱為數據集市伺服器。儘管可以有許多數據集市，但只能有一個數據集市伺服器。
數據集市組件需要IBMDB2UniversalDatabaseEnterpriseEdition，您必須在安裝控制伺服器前手工安裝它。
IBMTivoliMonitoringforTransactionPerformance倉庫包創建結構適用於報告界面的數據集市。IBMTivoliMonitoringforTransactionPerformance通過提供一個稱為數據集市ETL的抽取、轉換和裝入（ETL）過程來實現此操作，該進程創建數據集市並將來自中央數據倉庫的數據裝入其中。
可以修改現有的數據集市或創建包含略微不同的數據的新數據集市，以迎合您所在環境下的特定報告需要。要修改或創建數據集市，必須熟悉資料庫ETL過程以及數據集市在Tivoli 。
那么數據集市就是企業級數據倉庫的一個子集，他主要面向部門級業務，並且只面向某個特定的主題。為了解決靈活性和性能之間的矛盾，數據集市就是數據倉庫體系結構中增加的一種小型的部門或工作組級別的數據倉庫。數據集市存儲為特定用戶預先計算好的數據，從而滿足用戶對性能的需求。數據集市可以在一定程度上緩解訪問數據倉庫的瓶頸。
特徵
數據集市2、有特定的套用
3、面向部門
4、由業務部門定義、設計和開發
5、業務部門管理和維護
6、能快速實現
7、購買較便宜
8、投資快速回收
9、工具集的緊密集成
10、提供更詳細的、預先存在的、數據倉庫的摘要子集
11、可升級到完整的數據倉庫
數據結構
數據倉庫與數據集市的區別一、事實表
事實表描述數據集市中最密集的數據。在電話公司中，用於呼叫的數據是典型的最密集數據；在銀行中，與賬目核對和自動櫃員機有關的數據是典型的最密集數據。對於零售業而言，銷售和庫存數據是最密集的數據等等。
事實表是預先被連線到一起的多種類型數據的組合體，它包括：一個反映事實表建立目的的實體的主鍵，如一張訂單、一次銷售、一個電話等等，主鍵信息，連線事實表與維表的外鍵，外鍵攜帶的非鍵值外部數據。如果這種非鍵外部數據經常用於事實表中的數據分析，它就會被包括在事實表的範圍內。事實表是高度索引化的。事實表中出現30到40條索引非常常見。有時實事表的每列都建了索引，這樣作的結果是使事實表中的數據非常容易讀取。但是，導入索引所需的資源數量必須為等式提供因數。通常，事實表的數據不能更改，但可以輸入數據，一旦正確輸入一個記錄，就不能更改此記錄的任何內容了。
二、維表
維表是圍繞著事實表建立的。維表包含非密集型數據，它通過外鍵與事實表相連。典型的維表建立在數據集市的基礎上，包括產品目錄、客戶名單、廠商列表等等。
數據集市中的數據來源於企業數據倉庫。所有數據，除了一個例外，在導入到數據集市之前都應該經過企業數據倉庫。這個例外就是用於數據集市的特定數據，它不能用於數據倉庫的其他地方。外部數據通常屬於這類範疇。如果情況不是這樣，數據就會用於決策支持系統的其他地方，那么這些數據就必須經過企業數據倉庫。
數據集市包含兩種類型的數據，通常是詳細數據和匯總數據。
三、詳細數據
就像前面描述過的一樣，數據集市中的詳細數據包含在星型結構中。值得一提的是，當數據通過企業數據倉庫時，星型結構就會很好的匯總。在這種情況下，企業數據倉庫包含必需的基本數據，而數據集市則包含更高間隔尺寸的數據。但是，在數據集市使用者的心目中，星型結構的數據和數據獲取時一樣詳細。
四、匯總數據
數據集市包含的第二種類型數據是匯總數據。分析人員通常從星型結構中的數據創建各種匯總數據。典型的匯總可能是銷售區域的月銷售總額。因為匯總的基礎不斷發展變化，所以歷史數據就在數據集市中。但是這些歷史數據優勢在於它存儲的概括水平。星型結構中保存的歷史數據非常少。
數據集市以企業數據倉庫為基礎進行更新。對於數據集市來說大約每周更新一次非常平常。但是，數據集市的更新時間可以少於一周也可以多於一周，這主要是由數據集市所屬部門的需求來決定的。
常見問題
BI的數據集市模式建立不同規格的數據倉庫、數據集市的成本，國外的諮詢機構有專門的評估，在一定程度上可以借鑑。但是這些結果在國內也許並不適用，因為國情不同，在國內的構建成本需要專門的調研。以人們為企業構建的客戶主題數據集市為例，一般成本在20萬元到50萬元人民幣之間。
數據集市的設計可以採用疊代式的方法。在疊代式開發中，每個疊代為上一次的結果增加了新的功能。功能增加的順序要考慮到疊代平衡以及儘早發現重大風險。通俗地說，就是在正式交貨之前多次給客戶交付不完善的中間產品“試用”。這些中間產品會有一些功能還沒有添加進去、還不穩定，但是客戶提出修改意見以後，開發人員能夠更好地理解客戶的需求。如此反覆，使得產品在質量上能夠逐漸逼近客戶的要求。這種開發方法周期長、成本高，但是它能夠避免整個項目推倒重來的風險，比較適合大項目、高風險項目。
理論上講，應該有一個總的數據倉庫的概念，然後才有數據集市。實際建設數據集市的時候，國內很少這么做。國內一般會先從數據集市入手，就某一個特定的主題（比如企業的客戶信息）先做數據集市，再建設數據倉庫。數據倉庫和數據集市建立的先後次序之分，是和設計方法緊密相關的。而數據倉庫作為工程學科，並沒有對錯之分，主要判別方式應該是能否解決目前存在的實際問題，並為今後可能發生的問題保持一定的可伸縮性。
二、數據集市的 “獨立” 性
企業規劃數據倉庫項目的時候，往往會遇到很多數據倉庫軟體供應商。各供應商除了推銷相關的軟體工具外， 同時也會向企業灌輸許多概念。其中，數據倉庫和數據集市是最常見的兩個術語了。各個供應商術語定義不統一、銷售策略不一樣，這往往會給企業帶來很大的混淆。最典型的問題是：到底是先上一個企業級的數據倉庫呢？還是先上一個部門級的數據集市？這其實是是否要上獨立型數據集市的問題。
數據集市可以分為兩種類型——獨立型數據集市和從屬型數據集市。獨立型數據集市直接從操作型環境獲取數據，從屬型數據集市從企業級數據倉庫獲取數據，帶有從屬型數據集市的體系結構。
數據倉庫規模大、周期長，一些規模比較小的企業用戶難以承擔。因此，作為快速解決企業當前存在的實際問題的一種有效方法，獨立型數據集市成為一種既成事實。獨立型數據集市是為滿足特定用戶（一般是部門級別的）的需求而建立的一種分析型環境，它能夠快速地解決某些具體的問題，而且投資規模也比數據倉庫小很多。
獨立型數據集市的存在會給人造成一種錯覺，似乎可以先獨立地構建數據集市，當數據集市達到一定的規模再直接轉換為數據倉庫。有些銷售人員會推銷這種觀點，其實質卻常常是因為建立企業級數據倉庫的銷售周期太長以至於不好操作。
多個獨立的數據集市的累積，是不能形成一個企業級的數據倉庫的，這是由數據倉庫和數據集市本身的特點決定的—數據集市為各個部門或工作組所用，各個集市之間存在不一致性是難免的。因為脫離數據倉庫的緣故，當多個獨立型數據集市增長到一定規模之後，由於沒有統一的數據倉庫協調，企業只會又增加一些信息孤 島，仍然不能以整個企業的視圖分析數據。借用Inmon的比喻：人們不可能將大海里的小魚堆在一起就構成一頭大鯨魚，這也說明了數據倉庫和數據集市有本質的不同。
如果企業最終想建設一個全企業統一的數據倉庫，想要以整個企業的視圖分析數據，獨立型數據集市恐怕不是合適的選擇；也就是說“先獨立地構建數據集市，當數據集市達到一定的規模再直接轉換為數據倉庫”是不合適的。從長遠的角度看，從屬型數據集市在體系結構上比獨立型數據集市更穩定，可以說是數據集市未來建設的主要方向。
主要意義
示意圖那么，一個組織為何要構建數據集市呢?雖然OLTP和遺留系統擁有寶貴的信息，但是可能難以從這些系統中提取有意義的信息並且速度也較慢。而且這些系統雖然一般可支持預先定義操作的報表，但卻經常無法支持一個組織對於歷史的、聯合的、“智慧型的”或易於訪問的信息的需求。因為數據分布在許多跨系統和平台的表中，而且通常是“髒的”，包含了不一致的和無效的值，使得難於分析。數據集市將合併不同系統的數據源來滿足業務信息需求。
若能有效地得以實現，數據集市將可以快速且方便地訪問簡單信息以及系統的和歷史的視圖。一個設計良好的數據集市將會：發布特定用戶群體所需的信息，且無需受制於源系統的大量需求和操作性危機。支持訪問非易變（nonvolatile）的業務信息。（非易變的信息是以預定的時間間隔進行更新的，並且不受OLTP系統進行中的更新的影響）。調和來自於組織里多個運行系統的信息，比如賬目、銷售、庫存和客戶管理以及組織外部的行業數據。通過默認有效值、使各系統的值保持一致以及添加描述以使隱含代碼有意義，從而提供淨化的（cleansed）數據。為即席分析和預定義報表提供合理的查詢回響時間（不同於OLTP系統中所需的調優需求）。通過提供對於遺留系統和OLTP應用程式的選擇來減少對這些應用程式的要求，以獲得更多所需信息。
案例分析
中國移動數據集市：深化挖掘第一步
電信行業對於數據倉庫並不陌生，為了實現從產品導嚮往客戶導向的轉變，電信公司紛紛建立以客戶為中心的數據倉庫，希望依據客戶的需要、期望及喜好來制訂策略，提升企業競爭力。簡單說，數據倉庫就是為了保證數據查詢和分析的效率，按照主題將所有的數據分門別類進行存儲，需要的時候，可以按主題提取數據並做進一步的分析處理。
數據集市，可以稱作"小數據倉庫"，是用來分析相關專門業務問題或功能目標而做的專項的數據集合。它建立在具有統一數據存儲模型的數據倉庫下，各級業務人員按照各部門特定的需求把數據進行複製、處理、加工，並最終統一展現為有部門特點的數據集合，數據集市的套用是對數據倉庫套用的補充。
經過近幾年的努力，吉林移動通信有限責任公司已經成功在省級公司建立起了面向決策支持的經營分析系統，BI系統也逐漸完善。省級公司從業務系統中將相關業務數據進行抽取、清洗、加工、整理、載入到數據倉庫中，在數據倉庫中形成基礎的分析數據的存儲，對地市一級公司的行銷策略進行指導。
問題也隨之產生，由於下屬分公司在客戶群體、市場容量、利潤來源等地域差異明顯，省級公司通過全省範圍內分公司數據的匯總和分析，難以對單個地市級分公司產生個性化決策支持。另一方面，地市一級的分公司在開拓終端市場的過程中，激發了旺盛的套用需求，具體表現為對數據粒度的要求更加精細、需求更加靈活多變、要求更強的可操作性。
2005年6月，中國移動通信有限公司制定了《中國移動經營分析系統數據集市（試點）業務技術建議書》。為了使經營分析系統在地市級公司日常生產經營中發揮更大作用，吉林移動最終決定與亞信科技合作，全面進行"數據集市"的搭建。吉林省吉林市成為12個試點中第一個"吃螃蟹"的城市。
吉林移動希望通過數據集市的建設及時準確地了解掌握地市公司的分析需求，更好地為一線地市公司的生產行銷服務。吉林市分公司也希望提升自身的經營分析水平，落實集團公司的精細化行銷戰略。
在總體設計方面，吉林移動希望通過吉林市的試點為吉林省其它分公司建設統一的數據集市的模型，基本涵蓋地市固定統計報表及分析的需求，統一建模，統一管理。在功能上，為地市分公司的市場行銷行為提供客戶個體分析，提高經營分析結果的可實施能力，支持精細化行銷，支持地市開發過靈活專題分析。開發標準化、開放的數據平台，滿足省內不同地市分公司更多個性化的、臨時性的分析需求。
總體來說，吉林移動對亞信科技提出了很實際的業務描述，就是"以提供豐富的數據為基礎，以提供簡要分析功能、提高日常分析能力為主要手段，以解決各類業務目標為最終目的，大力提升地市公司數據綜合運用、分析能力，大力提升分公司主動服務、主動行銷效能"。
數據集市項目從2005年6月開始組織需求調研，經歷了5個月的建設時間，於2005年11月底上線使用，完成了中國移動集團公司試點所要求完成的所有基本集功能以及符合吉林本地特色的擴展集的內容。
作為實施方，亞信科技在吉林數據集市建設過程中遵循了"平台標準化、業務個性化"的原則。亞信一方面在數據集市基礎平台採用標準的系統軟體，使數據集市的邏輯數據模型統一、標準；另一方面，在地市分公司開發套用功能時，結合本地的實際情況，體現了本地的需求特色。在項目建設期間，吉林移動曾兩次就該項目建設的方法與思路向中國移動集團公司領導匯報，亞信的建設思路及建設成果得到了移動總公司的高度認可。
隨著吉林移動、雲南移動等公司"數據集市"項目的成功試點，中國移動31個省的上百家地市級公司將紛紛上馬數據集市項目。可以預見，2006年將是移動公司進一步深入挖掘BI套用，提升BI建設水平的一年，數據集市作為專項的數據集合與分析系統，對中國移動地市級分公司的日常經營管理將產生至關重要的作用，成為中國移動落實精細化經營策略的重點工程。
