如何構建數據倉庫

⑴ 教你輕松掌握數據倉庫的規劃和構建策略

教你輕松掌握數據倉庫的規劃和構建策略

數據倉庫作為決策支持系統（DSS）的基礎，具有面向主題的、集成的、不可更新的、隨時間不斷變化的特性。這些特點說明了數據倉庫從數據組織到數據處理，都與原來的資料庫有很大的區別，這也就需要在數據倉庫系統設計時尋求一個適合於數據倉庫設計的方法。在一般的系統開發規劃中，首先需要確定系統的功能，這些系統的功能一般是通過對用戶的需求分析得到的。從數據倉庫的應用角度來看，DSS分析員一般是企業中的中高層管理人員，他們對決策支持的需求不能預先做出規范的說明，只能給設計人員一個抽象地描述。
這就需要設計人員在與用戶不斷的交流溝通中，將系統的需求逐步明確，並加以完善。因此數據倉庫的開發規劃過程實際上是一個用戶和設計人員對其不斷了解、熟悉和完善的過程。 數據倉庫的開發應用規劃是開發數據倉庫的首要任務。只有制定了正確的數據倉庫規劃，才能使組織主要力量有序地實現數據倉庫的開發應用。在數據倉庫規劃中一般需要經歷這樣幾個過程：選擇實現策略、確定數據倉庫的開發目標和實現范圍、選擇數據倉庫體系結構、建立商業和項目規劃預算。 當數據倉庫規劃完成後，需要編制相應的數據倉庫規劃說明書，說明數據倉庫與企業戰略的關系，以及與企業急需處理的、范圍相對有限的開發機會，重點支持的職能部門和今後數據倉庫開發工作的建議，實際使用方案和開發預算，作為數據倉庫實際開發的依據。
1、選擇數據倉庫實現策略
數據倉庫的開發策略主要有自頂向下、自底向上和這兩種策略的聯合使用。自頂向下策略在實際應用中比較困難，因為數據倉庫的功能是一種決策支持功能。這種功能在企業戰略的應用范圍中常常是很難確定的，因為數據倉庫的應用機會往往超出企業當前的實際業務范圍，而且在開發前就確定目標，會在實現預定目標後就不再追求新的應用，是數據倉庫喪失更有戰略意義的應用。由於該策略在開發前就可以給出數據倉庫的實現范圍，能夠清楚地向決策者和企業描述系統的收益情況和實現目標，因此是一種有效的數據倉庫開發策略。該方法使用時需要開發人員具有豐富的自頂向下開發系統的經驗，企業決策層和管理人員完全知道數據倉庫的預定目標並且了解數據倉庫能夠在那些決策中發揮作用。
自底向上策略一般從某個數據倉庫原型開始，選擇一些特定的為企業管理人員所熟知的管理問題作為數據倉庫開發的對象，在此基礎上進行數據倉庫的開發。因此，該策略常常用於一個數據集市、一個經理系統或一個部門的數據倉庫開發。該策略的優點在於企業能夠以較小的投入，獲得較高的數據倉庫應用收益。在開發過程中，人員投入較少，也容易獲得成效。當然，如果某個項目的開發失敗可能造成企業整個數據倉庫系統開發的延遲。該策略一般用於企業洗碗對數據倉庫的技術進行評價，以確定該技術的應用方式、地點和時間，或希望了解實現和運行數據倉庫所需要的各種費用，或在數據倉庫的應用目標並不是很明確時，數據倉庫對決策過程影響不是很明確時使用。
在自頂向下的開發策略中可以採用結構化或面向對象的方法，按照數據倉庫的規劃、需求確定、系統分析、系統設計、系統集成、系統測試和系統試運行的階段完成數據倉庫的開發。而在自底向上的開發中，則可以採用螺旋式的原型開發方法，使用戶可以根據新的需求對試運行的系統進行修改。螺旋式的原型開發方法要求在較短的時間內快速的生成可以不斷增加功能的數據倉庫系統，這種開發方法主要適合於這樣一些場合：在企業的市場動向和需求無法預測，市場的時機是實現產品的重要組成部分，不斷地改進對與企業的市場調節是必需的；持久的競爭優勢來自連續不斷地改進，系統地改進是基於用戶在使用中的不斷發現。 自頂向下和自底向上策略的聯合使用具有兩種策略的優點，既能快速的完成數據倉庫的開發與應用，還可建立具有長遠價值的數據倉庫方案。但在實踐中往往難以操作，通常需要能夠建立、應用和維護企業模型、數據模型和技術結構的、具有豐富經驗的開發人員，能夠熟練的從具體（如業務系統中的元數據）轉移到抽象（只基於業務性質而不是基於實現系統技術的邏輯模型）；企業需要擁有由最終用戶和信息系統人員組成的有經驗的開發小組，能夠清楚地指出數據倉庫在企業戰略決策支持中的應用。
2、確定數據倉庫的開發目標和實現范圍
為確定數據倉庫的開發目標和實現范圍，首先需要對企業管理者等數據倉庫用戶解釋數據倉庫在企業管理中的應用和發展趨勢，說明企業組織和使用數據來支持跨功能系統的重要性，對企業經營戰略的支持，以確定開發目標。在該階段確認與使用數據倉庫有關的業務要求，這些要求應該只支持最主要的業務職能部門，將使用精力集中在收益明顯的業務上，使數據倉庫的應用立即產生效果，不應該消耗太多的精力在各個業務上同時鋪開數據倉庫的應用。
在確定開發目標和范圍以後，應該編制需求文檔，作為今後開發數據倉庫的依據。 數據倉庫開發的首要目標是確定所需要信息的范圍，確定用戶提供決策幫助時，在主題和指標域需要哪些數據源。這就需要定義：用戶需要什麼數據？面向主題的數據倉庫需要什麼樣的支持數據？為成功地向用戶提交數據，開發人員需要哪些商業知識？哪些背景知識？這就需要定義整體需求，以文件的形式整理現存的記錄系統和系統環境，對使用數據倉庫中數據的候選應用系統進行標識、排序，構造一個傳遞模型，確定尺度、事實及時間標記演算法，以便從系統中抽取信息且將他們放入數據倉庫。通過信息范圍確定可為開發人員提供一個良好的分析平台，和用戶一起分析哪些信息是數據倉庫需要的，進行商業活動需要什麼數據。開發人員可以和用戶進一步定義需要，例如數據分級層次、聚合的層次、載入的頻率以及需要保持的時間表等。 數據倉庫開發的另一個重要目標是確定利用哪些方法和工具訪問和導航數據？雖然用戶都需要存取並且檢索數據倉庫的內容，但是所存取的粒度有所不同，有的可能是詳細的記錄，有的可能是比較概括的記錄或十分概括的記錄。用戶要求的數據概括程度不同，將導致數據倉庫的聚集和概括工具的需求不同。
數據倉庫還有具有一定功能來訪問和檢索圖表、預定義的報表、多維數據、概括性數據和詳細記錄。用戶從數據倉庫中獲得信息，應該有電子表格、統計分析器和支持多維分析的分析處理器等工具的支持，以解釋和分析數據倉庫中的內容，產生並且驗證不同的市場假設、建議和決策方案。為將決策建議和各種決策方案向用戶清楚地表達出來，需要利用報表、圖表和圖像等強有力的信息表達工具。 數據倉庫開發的其他目標，是確定數據倉庫內部數據的規模。在數據倉庫中不僅包含當前數據，而且包含多年的歷史數據。數據的概括程度決定了這些數據壓縮和概括的最大限度。如果要讓數據倉庫提供對歷史記錄進行決策查詢的功能，就必須支持對大量數據的管理。數據的規模不僅直接影響決策查詢的時間，而且還將直接影響企業決策的質量。
在數據倉庫的開發目標中，還有：根據用戶對數據倉庫的基本需求，確定數據倉庫中數據的含義；確定數據倉庫內容的質量，以確定使用、分析和建議的可信級別；哪種類型的數據倉庫可以滿足最終用戶的需求，這些數據倉庫應該具有怎樣的功能；需要哪些元數據，如何使用數據源中的數據等。 數據倉庫的開發目標多種多樣，十分復雜，需要開發人員和用戶在開發與使用的過程中不斷交互完善。因此，在規劃中需要確定數據倉庫的開發范圍。使開發人員能夠根據需求和目標的重要性逐步進行，並且在開發中吸取經驗教訓，為數據倉庫在企業中的全部實現提供技術准備。因此，在為數據倉庫確定總體開發方向和目標以後，就必須確定一個有限的能夠很快體現數據倉庫效益的使用范圍。在考慮數據倉庫苦的應用范圍時，主要從使用部門的數量和類型、數據源的數量、企業模型的子集、預算分配以及開發項目所需的時間等角度分析。
在分析這些因素時，可從用戶的角度和技術的角度兩方面進行。 從用戶的角度應該分析哪些部門最先使用數據倉庫？是哪些人員為了什麼目的使用數據倉庫？以及數據倉庫首先要滿足哪些決策查詢？因為這些決策查詢往往確定了關於數據維數、報表的種類，這些因素都將確定數據倉庫定義時所需要的數量關系。查詢的格式越具體，越容易提供數據倉庫的維數、聚集和概括的規劃說明。 從技術角度分析，應該確定數據倉庫中元資料庫的規模，數據倉庫的元資料庫是存儲數據倉庫中數據定義的模型。數據定義存儲在倉庫管理器的目錄中，可以作為所有查詢和報表工具構造和查詢數據倉庫的依據。元資料庫的規模直接表示了數據倉庫中必須管理的數據規模。通過對元資料庫規模的管理，實際上就確定了數據倉庫中所需要管理的數據規模。
3、數據倉庫的結構選擇
數據倉庫的結構可以進行靈活的選擇，可將組織所使用的各種平台進行恰當的分割，把數據源、數據倉庫和最終用戶使用的工作站分割開來進行恰當的設計。
（1）數據倉庫的應用結構
基於業務處理系統的數據倉庫 在這種結構中，將運作的數據用於無需修改數據的只讀應用程序中。具有這種結構的數據倉庫元資料庫是一種虛庫，而不是數據倉庫自身的元數據。在數據倉庫元資料庫的直接指導下，對數據倉庫的查詢就是簡單的從資料庫中抽取數據。
單純數據倉庫
利用在數據倉庫中的數據源凈化、集成、概括和集成等操作，將數據源從業務處理系統中傳輸進集中的數據倉庫，各部門的數據倉庫應用只在數據倉庫中進行。這種結構經常發生在多部門、少用戶使用數據倉庫的情況下。這里的集中僅僅是邏輯上的，物理上可能是分散的。
單純數據集市
數據集市是指在部門中使用的數據倉庫，因為企業中的各個職能部門都有自己的特殊需要，而統一的數據倉庫可能不能滿足這些部門的特殊要求。這種體系結構經常發生在個別部門對數據倉庫的應用感興趣，而組織中其他部門卻對數據倉庫的應用十分冷漠之時，由熱心的部門單獨開發式所採用。
數據倉庫和數據集市
企業各部門擁有滿足自己需要的數據集市，其數據從企業數據倉庫中獲取，而數據倉庫從企業各種數據源中收集和分配。這種體系結構是一種較為完善的數據倉庫體系結構，往往發生在組織整體對數據倉庫應用感興趣之時所採用的體系結構。
（2）數據倉庫的技術平台結構 單層結構
單層結構主要是在數據源和數據倉庫之間共享平台，或者讓數據源、數據倉庫、數據集市與最終用戶工作站使用同一個平台。共享一個平台可以降低數據抽取和數據轉換的復雜性，但是共享平台在應用中可能遇到性能和管理方面的問題，這種體系結構一般在數據倉庫規模較小，而組織的業務系統平台具有較大潛力之時所採用。
客戶/伺服器兩層結構
一層為客戶機，一層為伺服器，最終用戶訪問工具在客戶層上運行，而數據源、數據倉庫和數據集市位於伺服器上，該技術機構一般用於普通規模的數據倉庫。
三層客戶/伺服器結構
基於工作站的客戶層、基於伺服器的中間層和基於主機的第三層。主機層負責管理數據源和可選的源數據轉換；伺服器運行數據倉庫和數據集市軟體，並且存儲倉庫的數據；客戶工作站運行查詢和報表運用程序，且還可以存儲從數據集市或數據倉庫卸載的局部數據。在數據倉庫稍具規模，兩層數據倉庫結構已經不能滿足客戶的需求，要講數據倉庫的數據存儲管理、數據倉庫的應用處理和客戶端應用分開之時，可以採用這種結構。
多層式結構
這是在三層機構基礎上發展起來的數據倉庫結構，在該結構中從最內數據層到最外層的客戶層依次是：單獨的數據倉庫存儲層、對數據倉庫和數據集市進行管理的數據倉庫服務層、進行數據倉庫查詢處理的查詢服務層、完成數據倉庫應用處理的應用服務層和面向最終用戶的客戶層。體系層次可能多達五層，這種體系結構一般用於超規模數據倉庫系統。
4、數據倉庫使用方案和項目規劃預算
數據倉庫的實際使用方案與開發預算，是數據倉庫規劃中最後需要確定的問題。因為數據倉庫主要用於對企業管理人員的決策支持，確保其實用性是十分重要的，因此需要讓最終用戶參與數據倉庫的功能設計。這種參與是通過用戶的實際使用方案進行的，使用方案是一個非常重要的需求模型。實際使用方案必須有助於闡明最終用戶對數據倉庫的要求，這些要求有的只使用適當的數據源就可以得到基本滿足，而有的卻需要來自企業外部的數據源，這就需要通過使用方案將這些不同的要求聯系起來。 實際使用方案還可以將最終用戶的決策支持要求與數據倉庫的技術要求聯系起來。因為當用戶確定最終要求後，為元資料庫的范圍確定一個界限。還可以確定所需要的歷史信息的數量，當根據特定的用戶進行數據倉庫的規劃時，就可確定最終用戶所關心的維度（時間、方位、商業單位和生產企業），因為維度與所需要的概括操作有明顯的關系，必須選擇對最終用戶有實際意義的維度，如：「月」、「季度」、「年」等。最後，還可以確定數據集市/數據倉庫的結構需要，使設計人員確定採用單純數據倉庫結構，還是單純的數據集市結構或者是兩者相結合的結構。
在實際使用開發方案確定後，還需要對開發方案的預算進行估計，確定項目的投資數額。投資方案的確定可以依據以往的軟體開發成本，但是這種預算的評估比較粗糙。另一種方法是參照結構進行成本評估，也就是說，將數據倉庫實際使用方案所確定的構件進行分解，根據各個構件的成本進行預算估算。數據倉庫的構件包含在數據源、數據倉庫、數據集市、最終用戶存取、數據管理、元數據管理、傳輸基礎等部分中，這些構件有的在企業原有信息系統中已經具備，有的可以選擇商品化構件，有的則需要自我開發。根據這些構件的不同來源，可以確定比較准確的預算。 在完成數據倉庫規劃後，就需要編制數據倉庫開發說明書，說明系統與企業戰略目標的關系，以及系統與企業急需處理的范圍相對有限的開發機會，所設想的業務機會的說明以及目標任務概況說明、重點支持的職能部門和今後工作的建議。數據倉庫項目應有明確的業務價值計劃開始，在計劃中需要闡明期望取得的有形和無形的利益。無形利益包含利用數據倉庫使決策完成得更快更好等利益。
業務價值計劃最好由目標業務主管來完成，因為數據倉庫是用戶驅動的，應該讓用戶積極參與數據倉庫的建設，在規劃書中要確定數據倉庫開發目標的實現范圍、體系結構和使用方案及開發預算。

⑵ 請問數據倉庫都用什麼建立

1、首先你得搞清楚建設數倉的目的是什麼

是偏向於整合各系統數據，為數據分析決策服務，還是偏向於快速的完成分析決策需求？

如果是前者，那麼在數據倉庫建模的時候一般會選擇ER建模方法；

如果是後者，一般會選擇維度建模方法。

• ER建模：即實體關系建模，由數據倉庫之父BIll Inmon提出，核心思想是從全企業的高度去設計三範式模型，用實體關系描述企業服務。主張的是自上而下的架構，將不同的OLTP數據集中到面向主題的數據倉庫中。

• 維度建模：由Kimball提出，核心思想是從分析決策的需求出發構建模型。這種模型由事實表和維表組成，即星型模型和雪花模型。Kimball倡導自下而上的架構，可以針對獨立部門建立數據集市，再遞增的構建，匯總成數據倉庫。

2、其次你得進行深入的業務調研和數據調研

• 業務調研：深入的業務調研能使你更加明確數倉建設的目的；同時也利於後續的建模設計，隨著調研的開展，如何將實體業務抽象為數倉模型會更加明朗。
  

• 數據調研：各部門或各科室的數據現狀了解，包括數據分類、數據存儲方式、數據量、具體的數據內容等等。這對後續的主數據串聯或者維度一致性處理等等都是必須的基礎。

3、然後是數據倉庫工具選型

• 傳統型數據倉庫：一般會選擇第三方廠家的資料庫和配套ETL工具。因為有第三方支持，相對有保障；但缺點也很明顯，受約束以及成本較高。
  

• NoSQL型數據倉庫：一般是基於hadoop生態的數據倉庫。hadoop生態已經非常強大，可以找到各種開源組件去支持數據倉庫。缺點是需要招聘專門人士去摸索，並且相對會存在一些未知隱患。

4、最後是設計與實施

• 設計：包括數據架構中的數據層次劃分以及具體的模型設計；也包括程序架構中的數據質量管理、元數據管理、調度管理等；
  

• 實施：規范化的項目管理實施，但同時也需記住一點，數據倉庫不是一個項目，它是一個過程。

⑶ 企業如何更好的搭建數據倉庫

0 引 言
隨著計算機應用的深入，大量數據存儲在計算機中，信息的存儲、管理、使用和維護顯得越來越重要，而傳統的資料庫管理系統很難滿足其要求。為了解決大數據量、異構數據集成以及訪問數據的響應速度問題，採用數據倉庫技術，為最終用戶處理所需的決策信息提供有效方法。
1 數據倉庫
數據倉庫是為管理人員進行決策提供支持的一種面向主題的、集成的、非易失的並隨時間而變化的數據集合。數據倉庫是一種作為決策支持系統和聯機分析應用數據源的結構化數據環境。
從目前數據倉庫的發展來講，數據可以存放於不同類型的資料庫中，數據倉庫是將異種數據源在單個站點以統一的模型組織的存儲，以支持管理決策。數據倉庫技術包括數據清理、數據集成、聯機分析處理（OLAP）和數據挖掘（DM）。OLAP是多維查詢和分析工具，支持決策者圍繞決策主題對數據進行多角度、多層次的分析。OLAP側重於交互性、快速的響應速度及提供數據的多維視圖，而DM則注重自動發現隱藏在數據中的模式和有用信息。OLAP的分析結果可以給DM提供分析信息，作為挖掘的依據；DM可以拓展OLAP分析的深度，可以發現OLAP所不能發現的更為復雜、細致的信息。OLAP是聯機分析處理，DM是通過對資料庫、數據倉庫中的數據進行分析而獲得知識的方法和技術，即通過建立模型來發現隱藏在組織機構資料庫中的模式和關系。這兩者結合起來可滿足企業對數據整理和信息提取的要求，幫助企業高層做出決策。在歐美發達國家，以數據倉庫為基礎的在線分析處理和數據挖掘應用，首先在金融、保險、證券、電信等傳統數據密集型行業取得成功。IBM、oracle、Teradata、Microsoft、Netezza和SAS等有實力的公司相繼推出了數據倉庫解決方案。
近幾年開始流行「分布式數據倉庫」，是在多個物理位置應用全局邏輯模型。數據被邏輯地分成多個域，但不同位置不會有重復的數據。這種分布式方法可以為不同的物理數據創建安全區域，或為全球不同時區的用戶提供全天候的服務。此外，有由Kognitio發起數據倉庫託管服務，即DBMS廠商為客戶開發和運行數據倉庫。這種最初出現在業務部門，業務部門購買託管服務，而不是使用企業內IT部門提供的數據倉庫。
2 數據挖掘技術
數據挖掘（DataMining），又稱資料庫中的知識發現（KnoWledge Discoveryin Database，KDD），是指從大型資料庫或數據倉庫中提取隱含的、未知的、非平凡的及有潛在應用價值並最終可為用戶理解的模式過程。它是資料庫研究中的很有應用價值的新領域，是人工智慧、機器學習、數理統計學和神經元網路等技術在特定的數據倉庫領域中的應用。數據挖掘的核心模塊技術歷經數十年的發展，其中包括數理統計、人工智慧、機器學習。從技術角度看，數據挖掘是從大量的、不完全的、有雜訊的、模糊的、隨機的實際數據中，提取隱含在其中的、人們所不知道的、但又是潛在有用的信息和知識的過程。從商業應用角度看，數據挖掘是嶄新的商業信息處理技術，其主要特點是對商業資料庫中的大量業務數據進行抽取、轉化、分析和模式化處理，從中提取輔助商業決策的關鍵知識。
從技術角度講，數據挖掘可應用於以下方面：
（1）關聯規則發現是在給定的事物集合中發現滿足一定條件的關聯規則，簡單來講，就是挖掘出隱藏在數據間的相互關系，為業務主題提供指導。
（2）序列模式分析和關聯規則發現相似，但其側重點在於分析數據間的前後關系。模式是按時間有序的。序列模式發現是在與時間有關的事物資料庫中發現滿足用戶給定的最小支持度域值的所有有序序列。
（3）分類分析與聚類分析，分類規則的挖掘實際上是根據分類模型從數據對象中發現共性，並把它們分成不同的類的過程。聚類時間是將d維空間的n個數據對象，劃分到k個類中，使得一個類內的數據對象間的相似度高於其他類中數據對象。聚類分析可以發現沒有類別標記的一組數據對象的特性，總結出一個類別的特徵。
（4）自動趨勢預測，數據挖掘能自動在大型資料庫裡面尋找潛在的預測信息。一個典型的利用數據挖掘進行預測的例子就是目標營銷。數據挖掘工具可以根據過去郵件推銷中的大量數據找出其中最有可能對將來的郵件推銷作出反應的客戶。
3 聯機分析（OLAP）處理技術
聯機分析（OLAP）是數據倉庫實現為決策提供支持的重要工具，是共享多維信息，針對特定問題的聯機數據訪問和分析的快速軟體技術。是使分析人員、管理人員或執行人員能夠從多種角度對從原始數據中轉化出來，能夠真正為用戶所理解，並真實反映企業維特性的信息進行快速、一致、交互地存取，從而獲得對數據的更深入了解的一類軟體技術（OLAP委員會的定義）。OLAP的特性包括：①快速性：系統應能在5s內對用戶的大部分分析要求做出反應；②可分析性：能處理與應用有關的任何邏輯分析和統計分析；⑨多維性：多維性是OLAP的關鍵屬性。系統必須提供對數據的多維視圖和分析，包括對層次維和多重層次維的完全支持；④信息性：系統應能及時獲得信息，並能管理大容量信息。
OLAP的數據結構是多維，目前存在方式：①超立方結構（Hypercube），指用三維或更多的維數來描述一個對象，每個維彼此垂直。數據的測量值發生在維的交叉點上，數據空間的各部分都有相同的維屬性（收縮超立方結構。這種結構的數據密度更大，數據的維數更少，並可加入額外的分析維）；②多立方結構（Multicube），即將超立方結構變為子立方結構。面向某特定應用對維分割，它具有強靈活性，提高了數據（特別是稀疏數據）的分析效率。分析方法包括：切片、切塊、旋轉、鑽取等。
OLAP也被稱為共享的多維數據的快速分析FASMI，應用在數據密集型行業，如市場和銷售分析、電子商務的分析、基於歷史數據的營銷、預算、財務報告與整合、管理報告、利益率、質量分析等。
4 小 結
採用數據倉庫的數據挖掘及聯機分析技術實現的決策支持系統，是彌補傳統輔助決策系統能力不足的有效途徑，具有重要的現實意義。

⑷ 怎麼在sql server構建數據倉庫

數據倉庫是為了管理數據，主要是思想。
具體實施的工具就是為了解決問題而選取了
比如異構/不同源數據的數據抽取問題，要用到etl，可能會用工具 或者自己寫程序，看情況而定『
數據倉庫的模型建設，要用到erwin等建模工具；
數據的存放一般是藉助關系資料庫來實現，那麼會用到oracle之類。不過現在已經開始慢慢摒棄傳統關系資料庫了，藉助一些No sql平台，比如hadoop上的hive之類。
不過無論用什麼工具，一定要記住，數據倉庫的思想是不變的，就是管理數據、把數據的價值通過有效地管理而展現出來，不經管理的數據就是一堆沒有提煉的金礦，看著很值錢，直接狗屁用沒有。

⑸ 數據倉庫的建立步驟

1)收集和分析業務需求
2)建立數據模型和數據倉庫的物理設計
3)定義數據源
4)選擇數據倉庫技術和平台
5)從操作型資料庫中抽取、凈化、和轉換數據到數據倉庫
6)選擇訪問和報表工具
7)選擇資料庫連接軟體
8)選擇數據分析和數據展示軟體
9)更新數據倉庫 1)數據轉換工具要能從各種不同的數據源中讀取數據。
2)支持平面文件、索引文件、和legacyDBMS。
3)能以不同類型數據源為輸入整合數據。
4)具有規范的數據訪問介面
5)最好具有從數據字典中讀取數據的能力
6)工具生成的代碼必須是在開發環境中可維護的
7)能只抽取滿足指定條件的數據，和源數據的指定部分
8)能在抽取中進行數據類型轉換和字元集轉換
9)能在抽取的過程中計算生成衍生欄位
10)能讓數據倉庫管理系統自動調用以定期進行數據抽取工作，或能將結果生成平面文件
11)必須對軟體供應商的生命力和產品支持能力進行仔細評估
主要數據抽取工具供應商：Prismsolutions.Carleton'sPASSPORT.InformationBuildersInc.'s
EDA/SQL.SASInstituteInc. 一般問題 (不完全是技術或文化，但很重要) 包括但不限於以下幾點:
業務用戶想要執行什麼樣的分析?
你現在收集的數據需要支持那些分析嗎?
數據在哪兒？
數據的清潔度如何？
相似的數據有多個數據源嗎？
什麼樣的結構最適合核心數據倉庫 (例如維度或關系型)？
技術問題包括但不限於以下幾點:
在你的網路中要流通多少數據？它能處理嗎?
需要多少硬碟空間?
硬碟存儲需要多快？
你會使用固態還是虛擬化的存儲？

⑹ 構建企業級數據倉庫的步驟是什麼

現如今，很多企業都開始重視數據倉庫的構建，其實構建數據倉庫不是一個難事，難的地方在於如何構建企業級的數據倉庫，這對於企業來說是一件十分困難又必須提上日程的事情。不過，不要灰心，雖然困難，但是我們也可以通過一些方法去構建企業數據倉庫，在這篇文章中我們就給大家介紹一下構建數據倉庫的步驟。
構建企業級的數據倉庫第一步就是要確定主題，其實確定主題就是確定數據分析或前端展現的主題。主題要體現出某一方面的各分析角度和統計數值型數據之間的關系,確定主題時要綜合考慮。這一點是非常重要的，大家一定要重視。
第二個步驟就是確定量度。當我們確定主題後，需要考慮分析的技術指標。一般來說，這些都是數據值型數據，其中有些度量值不可以匯總。有些是可以匯總起來，以便為分析者提供有用的信息。量度是要統計的指標，必須事先選擇恰當，基於不同的量度可以進行復雜關鍵性指標的設計和計算。
第三個步驟就是確定事實數據粒度。當我們確定量度之後，需要考慮該量度的匯總情況和不同維度下量度的聚合情況。如果我們按照「天」為單位來匯總數據的在ETL處理過程中，按天來匯總數據,些時數據倉庫中量度的粒度就是「天」。如果不能確認將來的分析需求中是否要精確的秒，那麼，我們要遵循」最小粒度原則」,在數據倉庫中的事實表中保留每一秒的數據，對數據提前進行匯總，保障產生分析結果的效率。
第四個步驟就是確定維度，其實維度是分析的各個角度。基於不同的維度，可以看到各個量度匯總的情況，也可以基於所有的維度進行交叉分析。
第五個步驟就是創建事實表。在確定好事實數據和維度後，將考慮載入事實表。業務系統的的一筆筆生產，交易記錄就是將要建立的事實表的原始數據。具體的做法是將原始表與維度表進行關聯，生成事實表。關聯時有為空的數據時，需要使用外連接，連接後將各維度的代理鍵取出放於事實表中，事實表除了各維度代理鍵外，還有各度量數據，不應該存在描述性信息。
在這篇文章中我們給大家介紹了構建企業級數據倉庫的相關步驟，相信大家看了這篇文章以後已經對數據倉庫有所了解了吧？大家在構建數據倉庫的時候一定要謹遵上面的步驟進行操作，這樣才能夠提高工作效率，少走彎路，更出色地完成工作任務。