輕鬆七步順利開發資料倉儲

[@more@]

對於大多數IT顧問來說，實現一個資料倉儲的難度比以前做過的任何專案難度都要大。考慮到不同的資料結構、用途以及應用程式開發方法，以前所積累的經驗和技巧大部分都無用武之地了。但是隻要在你的前進道路上稍加修正，你就會發現實現一個資料倉儲並不是難事，就算你是第一次實現資料倉儲也沒問題。

下面列出了資料倉儲實施過程需要考慮的步驟，有一些你可能從來沒有意識到，而另一些可能已經在實施過程中使用到了，但是重新思考一番也許你會有更多的領悟。開放思維，不斷嘗試新的途徑，找到一種可行的資料倉儲實現方法。

1. 再三考慮應用程式的實現方法

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

2. 建立抽象的、良好部署的資料庫訪問元件

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

3. 保持鬆散

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

4. 將管理放在首位

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

5. 從字裡行間發現問題

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

6. 保持領先

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

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

第二，體系結構的領先性。它使得專案在各個階段轉換時，資料倉儲和它所支援的系統的物理以及邏輯架構都具有持續性，不會發生改變。這也是你能提供的。

7. 發出警告

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