開發數據集市表是什麼

① 數據集市的特徵

1．數據集市的特徵包括規模小。
2．有特定的應用。
3．面向部門。
4．由業務部門定義、設計和開發。
5．業務部門管理和維護。
6．能快速實現。
7．購買較便宜。
8．投資快速回收。
9．工具集的緊密集成。
10．提供更詳細的、預先存在的、數據倉庫的摘要子集。
11．可升級到完整的數據倉庫。

② 什麼是數據集市

數據集市
單獨的 DB2 資料庫包括企業的數據集市。每個數據集市包括來自中央數據倉庫的歷史數據的子集，用以滿足特定部門、團隊、客戶或應用程序分析和報告需求。主管此 DB2 資料庫的系統稱為數據集市伺服器。盡管可以有許多數據集市，但只能有一個數據集市伺服器。

數據集市組件需要 IBM DB2 Universal Database Enterprise Edition，您必須在安裝控制伺服器前手工安裝它。

IBM Tivoli Monitoring for Transaction Performance 倉庫包創建結構適用於報告界面的數據集市。IBM Tivoli Monitoring for Transaction Performance 通過提供一個稱為數據集市 ETL 的抽取、轉換和裝入（ETL）過程來實現此操作，該進程創建數據集市並將來自中央數據倉庫的數據裝入其中。

可以修改現有的數據集市或創建包含略微不同的數據的新數據集市，以迎合您所在環境下的特定報告需要。要修改或創建數據集市，必須熟悉資料庫 ETL 過程以及數據集市在 Tivoli Enterprise Data Warehouse 資料庫中的內部星型模式表示。關於此方面的更多信息，請參閱 Enabling an Application for Tivoli Enterprise Data Warehouse。

③ 數據集市的數據結構

數據集市中數據的結構通常被描述為星型結構或雪花結構。一個星型結構包含兩個基本部分——一個事實表和各種支持維表。 事實表描述數據集市中最密集的數據。在電話公司中，用於呼叫的數據是典型的最密集數據；在銀行中，與賬目核對和自動櫃員機有關的數據是典型的最密集數據。對於零售業而言，銷售和庫存數據是最密集的數據等等。
事實表是預先被連接到一起的多種類型數據的組合體，它包括：一個反映事實表建立目的的實體的主鍵，如一張訂單、一次銷售、一個電話等等，主鍵信息，連接事實表與維表的外鍵，外鍵攜帶的非鍵值外部數據。如果這種非鍵外部數據經常用於事實表中的數據分析，它就會被包括在事實表的范圍內。事實表是高度索引化的。事實表中出現30到40條索引非常常見。有時實事表的每列都建了索引，這樣作的結果是使事實表中的數據非常容易讀取。但是，導入索引所需的資源數量必須為等式提供因數。通常，事實表的數據不能更改，但可以輸入數據，一旦正確輸入一個記錄，就不能更改此記錄的任何內容了。 維表是圍繞著事實表建立的。維表包含非密集型數據，它通過外鍵與事實表相連。典型的維表建立在數據集市的基礎上，包括產品目錄、客戶名單、廠商列表等等。
數據集市中的數據來源於企業數據倉庫。所有數據，除了一個例外，在導入到數據集市之前都應該經過企業數據倉庫。這個例外就是用於數據集市的特定數據，它不能用於數據倉庫的其他地方。外部數據通常屬於這類范疇。如果情況不是這樣，數據就會用於決策支持系統的其他地方，那麼這些數據就必須經過企業數據倉庫。
數據集市包含兩種類型的數據，通常是詳細數據和匯總數據。 數據集市包含的第二種類型數據是匯總數據。分析人員通常從星型結構中的數據創建各種匯總數據。典型的匯總可能是銷售區域的月銷售總額。因為匯總的基礎不斷發展變化，所以歷史數據就在數據集市中。但是這些歷史數據優勢在於它存儲的概括水平。星型結構中保存的歷史數據非常少。
數據集市以企業數據倉庫為基礎進行更新。對於數據集市來說大約每周更新一次非常平常。但是，數據集市的更新時間可以少於一周也可以多於一周，這主要是由數據集市所屬部門的需求來決定的。

④ 數據集市的常見問題

建立不同規格的數據倉庫、數據集市的成本，國外的咨詢機構有專門的評估，在一定程度上可以借鑒。但
是這些結果在國內也許並不適用，因為國情不同，在國內的構建成本需要專門的調研。以人們為企業構建的客戶主題數據集市為例，一般成本在20萬元到50萬元人民幣之間。數據集市的設計可以採用迭代式的方法。在迭代式開發中，每個迭代為上一次的結果增加了新的功能。功能增加的順序要考慮到迭代平衡以及盡早發現重大風險。通俗地說，就是在正式交貨之前多次給客戶交付不完善的中間產品「試用」。這些中間產品會有一些功能還沒有添加進去、還不穩定，但是客戶提出修改意見以後，開發人員能夠更好地理解客戶的需求。如此反復，使得產品在質量上能夠逐漸逼近客戶的要求。這種開發方法周期長、成本高，但是它能夠避免整個項目推倒重來的風險，比較適合大項目、高風險項目。
理論上講，應該有一個總的數據倉庫的概念，然後才有數據集市。實際建設數據集市的時候，國內很少這么做。國內一般會先從數據集市入手，就某一個特定的主題（比如企業的客戶信息）先做數據集市，再建設數據倉庫。數據倉庫和數據集市建立的先後次序之分，是和設計方法緊密相關的。而數據倉庫作為工程學科，並沒有對錯之分。

⑤ 軟體數據架構中的數據倉庫和數據集市是什麼意思

沒有本質的區別，數據集市范圍比較小，一般是個別部門的數據。 而數據倉庫是面向主題的、集成的、相對穩定的、反映歷史變化的一系列整合的數據。

⑥ 數據集市與數據倉庫有什麼區別

都是資料庫裡面的概念，本質上並沒有什麼不同。
從字義上看， 「倉庫」可以想像成一所大房子，高高的貨架，合理的出入路線，是一種集中存儲貨物的地方，一般顧客是不來參觀訪問的； 而說到「集市」，就容易聯想到空曠的場地，川流不息，大小商戶擺出攤子，賣衣物的、賣燒餅及賣藝的，是讓顧客來消費的地方。 具體來說，數據倉庫僅僅是提供存儲的，提供一種面向數據管理的服務，不面向最終分析用戶；而數據集市是面向分析應用的，面向最終用戶。

⑦ ETL是什麼,形象的介紹一下

對於做過 BI 開發的朋友，ETL 並不陌生，只要涉及到數據源的數據抽取、數據的計算和處理過程的開發，都是 ETL，ETL 就這三個階段，Extraction 抽取，Transformation 轉換，Loading 載入。

從不同數據源抽取數據 EXTRACTION ，按照一定的數據處理規則對數據進行加工和格式轉換 TRASFORMATION，最後處理完成的輸出到目標數據表中也有可能是文件等等，這個就是 LOADING。

再通俗一點講，ETL 的過程就跟大家日常做菜一樣，需要到菜市場的各個攤位買好菜，把菜買回來要摘一下，洗一洗，切一切最後下鍋把菜炒好端到飯桌上。菜市場的各個攤位就是數據源，做好的菜就是最終的輸出結果，中間的所有過程像摘菜、洗菜、切菜、做菜就是轉換。

在開發的時候，大部分時候會通過 ETL 工具去實現，比如常用的像 KETTLE、PENTAHO、IBM DATASTAGE、INFORNAICA、微軟 SQL SERVER 裡面的 SSIS 等等，在結合基本的 SQL 來實現整個 ETL 過程。

也有的是自己通過程序開發，然後控制一些數據處理腳本跑批，基本上就是程序加 SQL 實現。

哪種方式更好，也是需要看使用場景和開發人員對那種方式使用的更加得心應手。我看大部分軟體程序開發人員出身的，碰到數據類項目會比較喜歡用程序控制跑批，這是程序思維的自然延續。純 BI 開發人員大部分自然就選擇成熟的 ETL 工具來開發，當然也有一上來就寫程序腳本的，這類 BI 開發人員的師傅基本上是程序人員轉過來的。

用程序的好處就是適配性強，可擴展性強，可以集成或拆解到到任何的程序處理過程中，有的時候使用程序開發效率更高。難就難在對維護人員有一定的技術要求，經驗轉移和可復制性不夠。

用 ETL 工具的好處，第一是整個 ETL 的開發過程可視化了，特別是在數據處理流程的分層設計中可以很清晰的管理。第二是鏈接到不同數據源的時候，各種數據源、資料庫的鏈接協議已經內置了，直接配置就可以，不需要再去寫程序去實現。第三是各種轉換控制項基本上拖拉拽就可以使用，起到簡化的代替一部分 SQL 的開發，不需要寫代碼去實現。第四是可以非常靈活的設計各種 ETL 調度規則，高度配置化，這個也不需要寫代碼實現。

所以在大多數通用的項目中，在項目上使用 ETL 標准組件開發會比較多一些。

ETL 從邏輯上一般可以分為兩層，控制流和數據流，這也是很多 ETL 工具設計的理念，不同的 ETL 工具可能叫法不同。

控制流就是控制每一個數據流與數據流處理的先後流程，一個控制流可以包含多個數據流。比如在數據倉庫開發過程中，第一層的處理是ODS層或者Staging 層的開發，第二層是 DIMENSION維度層的開發，後面幾層就是DW 事實層、DM數據集市層的開發。通過ETL的調度管理就可以讓這幾層串聯起來形成一個完整的數據處理流程。

數據流就是具體的從源數據到目標數據表的數據轉換過程，所以也有 ETL 工具把數據流叫做轉換。在數據流的開發設計過程中主要就是三個環節，目標數據表的鏈接，這兩個直接通過 ETL 控制項配置就可以了。中間轉換的環節，這個時候就可能有很多的選擇了，調 SQL 語句、存儲過程，或者還是使用 ETL 控制項來實現。

有的項目上習慣使用 ETL 控制項來實現數據流中的轉換，也有的項目要求不使用標準的轉換組件使用存儲過程來調用。也有的是因為數據倉庫本身這個資料庫不支持存儲過程就只能通過標準的SQL來實現。

我們通常講的BI數據架構師其實指的就是ETL的架構設計，這是整個BI項目中非常核心的一層技術實現，數據處理、數據清洗和建模都是在ETL中去實現。一個好的ETL架構設計可以同時支撐上百個包就是控制流，每一個控制流下可能又有上百個數據流的處理過程。之前寫過一篇技術文章，大家可以搜索下關鍵字 BIWORK ETL 應該在網上還能找到到這篇文章。這種框架設計不僅僅是ETL框架架構上的設計，還有很深的ETL項目管理和規范性控制器思想，包括後期的運維，基於BI的BI分析，ETL的性能調優都會在這些框架中得到體現。因為大的BI項目可能同時需要幾十人來開發ETL，框架的頂層設計就很重要。

⑧ 數據倉庫和數據集市的區別

數據集市作為數據倉庫的一個組成部分，應從數據倉庫中導出，也就是說，首先要建立數據倉庫，然後從數據倉庫自然生成數據集市。

但在財務、人力資源及管理部門，在技術和管理的成熟度有限的情況下，先建立數據集市可以達到先取得試點經驗，然後成熟一個又一個的效果。這聽起來是不錯，但是需要注意的是數據倉庫的宗旨是為企業信息系統提供一個集成的解決辦法，不管數據集市大小，都要建立在數據倉庫的總體設計框架上，一定要在確定企業級數據倉庫的大前提下著手開發數據集市。不管用哪一種方式，都要實行集中化的設計，任何數據集市設計都要在企業級的數據倉庫概念設計的原則指導下進行，實行標准化並採用共享的參照表和維表。

⑨ 什麼是數據集市

數據集市(Data Mart) ，也叫數據市場，是一個從操作的數據和其他的為某個特殊的專業人員團體服務的數據源中收集數據的倉庫。

⑩ 數據集市的主要意義

快速發展的、充滿競爭的商業世界對於及時、准確的信息有著永無止境的需求，一些IT專家對此認為其必然結果就是創建數據集市。其他專家卻質疑用戶和客戶所要付出的工作和成本。畢竟，難道不能直接從遺留系統和在線事務處理（On Line Transaction Processing，OLTP）系統通過特定的報表獲得相同的信息嗎?在EDS 的商業智能小組里，人們就經常被問到這一問題。經驗讓人們有許多機會使人們的同行和客戶了解這項有用技術的價值。
那麼，一個組織為何要構建數據集市呢?雖然OLTP和遺留系統擁有寶貴的信息，但是可能難以從這些系統中提取有意義的信息並且速度也較慢。而且這些系統雖然一般可支持預先定義操作的報表，但卻經常無法支持一個組織對於歷史的、聯合的、「智能的」或易於訪問的信息的需求。因為數據分布在許多跨系統和平台的表中，而且通常是「臟的」，包含了不一致的和無效的值，使得難於分析。數據集市將合並不同系統的數據源來滿足業務信息需求。
若能有效地得以實現，數據集市將可以快速且方便地訪問簡單信息以及系統的和歷史的視圖。一個設計良好的數據集市將會：發布特定用戶群體所需的信息，且無需受制於源系統的大量需求和操作性危機。支持訪問非易變（nonvolatile）的業務信息。（非易變的信息是以預定的時間間隔進行更新的，並且不受OLTP系統進行中的更新的影響）。調和來自於組織里多個運行系統的信息，比如賬目、銷售、庫存和客戶管理以及組織外部的行業數據。通過默認有效值、使各系統的值保持一致以及添加描述以使隱含代碼有意義，從而提供凈化的（cleansed）數據。為即席分析和預定義報表提供合理的查詢響應時間（不同於OLTP系統中所需的調優需求）。通過提供對於遺留系統和OLTP應用程序的選擇來減少對這些應用程序的要求，以獲得更多所需信息。