數據倉庫實施過程所需要考慮的步驟：

一、再三考慮應用程序的實現方法

數據倉庫并不涉及事務處理，并且在報表方面也僅占一小部分。而數據倉庫應用程序的本質是分析，尤其是針對業務智能的分析。BI并不是通常所說的數據：它是一種從舊有數據中,模型化得到的新的數據。那么如何才能從舊有數據中挖出這些新數據呢?事實上，這個工作不是讓你來完成的，而是你的客戶所要完成的。從項目主管的角度看，應該有一個經驗豐富的數據表格設計師與你合作，進而決定如何將各類程序融合在一起。其中所遇到的最主要的挑戰將是如何用新的方法觀察數據，這也是你的客戶正在試圖使用的方法。

二、創建抽象的、良好部署的數據庫訪問組件

在過去你接觸過的數據庫項目和現在的數據倉庫之間，有一點絕對不同，那就是：在Online Transaction Processing (OLTP)環境中，用戶數量非常大，但使用到的數據卻比較少;而在Online Analytical Processing (OLAP)環境中情況卻正好相反，少量的用戶在使用大量的數據。而你的工作就是編寫一個應用程序來優化這種不同。這里有一個線索：在你所有的分析程序中，都要能抓取連續的數據項，這樣在以后建立和訪問的數據結構中才能存放與原數據物理結構類似的數據。具體如何實現呢?首先不要規格化數據。第二將其放入數組中最小化讀取請求數。按照這種方法，DBA會很樂意與你合作。

三、保持松散

現在回頭看看第一步，你應該可以理解定義一個分析程序不是件簡單事了，而且一般情況下，很難在第一次就實現符合要求的最終產品。而在你將要進行分析的數據結構上同樣存在這種問題。一句話，實現過程會有很多變數，你需要不斷的改動你的程序。通常我們都希望將改動次數降到最低。在一個數據倉庫實現過程中，本質是要分析過程毫無差錯，這也需要DBA的參與。不要死抓住你的程序設計、代碼、框圖，或你建立的其它什么東西不放手，要根據這種變化而不斷進行調整。

四、將管理放在首位

在分析數據源方面你做的如何呢?你是否認為清理垃圾數據的工作非常困難?并不是只有你一個人這樣想，做過類似工作的人都有這種看法。在一個一般規模的機構中，作為數據倉庫實現過程的一部分，會有大量的舊有數據必須進行一致性處理。所以分析數據源并花費數個小時編寫轉換程序將舊有數據導入數據倉庫是整個數據倉庫實現過程中最艱難的一部分。并且這也是整個項目中最重要的一環，可以占到整個項目周期和預算的四分之三。所以一定要小心對待。

五、從字里行間發現問題

與用戶交流是個很麻煩的事情，為什么這么說呢?因為很多用戶在見到最終產品前都不知道自己想要什么樣的產品。定義數據倉庫應用程序是一個探索的過程，而且這個過程要反復進行。記住所謂的"業務智能"是用戶自己定義的，他們按照自己的理解來處理業務流程。因此這些用戶就是連接數據和業務處理過程間的橋梁。他們所要的并不是數據本身，而是隱藏在數據后面的智能性。你可以讓他們討論、思考并給出建設性的意見。但千萬不要讓他們解決或讓他們任意想象和發表那些"有可能"的觀點。最后，一定要隨時留意用戶得出的結論。

六、保持領先

數據倉庫看起來沒有傳統的OLTP模式根深蒂固，事實如此。雖然很多人投身數據倉庫的開發中，但由于其框架與以前的系統大相徑庭，因此在開始的一段時間數據倉庫的實現看上去相當混亂。但是堅持下去是很重要的。它具有兩方面重要的作用。

◆技術的領先性。它可以跟蹤項目中任何階段的軟件工具的部署和正確使用，以及開發過程。如果這復合你的背景，你可以對此多加留意。

◆體系結構的領先性。它使得項目在各個階段轉換時，數據倉庫和它所支持的系統的物理以及邏輯架構都具有持續性，不會發生改變。這也是你能提供的。

七、發出警告

最后你要記住，你并不是唯一登上新大陸的人。你周圍的每一個人都會有下面一點或幾點問題：不現實的期望、對技術的誤解、舊習慣或壞習慣、競爭行為，或缺乏對項目的信任度。雖然交流溝通等任務應該是項目經理負責的，但實際上你也要擔負起相同的責任。那么作為技術總監你該怎么作呢?首先當然是要真誠的對待周圍的人，但一定要豎立威信，適當的發出警告。當你發現項目進度緩慢、資源流失，或者員工失去目標，就要直言不諱的說出來。快速明確的給予警告在大部分情況下都是明智之舉。匆忙上馬的數據倉庫項目也許會出軌，但不要讓失敗的項目把你拉下馬。