6. 不要避免顆粒度和分區問題
在數據倉庫設計過程中有兩個最大的數據存儲問題，第一是如何給轉換數據定位一個恰當的顆粒度等級，第二是如何將數據絕對的分區。為什么這兩點問題如此重要呢？因為整個數據倉庫的響應能力受顆粒度影響，并且數據訪問的效率直接與數據分區性能有關。因此這是具有關鍵性的工作，不要試圖避免面對這些問題。
7. 不要在沒考慮業務問題前就使用OLAP
用戶在親眼見到程序前通常都不知道自己到底想要個什么樣的程序。因此他們的觀點有不少錯誤，比如他們希望分析結果會忠實反應性能度量，或者希望程序會使他們部門或公司的業務工作有所不同。而你必須跳出自己的職責范圍，從IT管理者的角度考慮用戶部門直至整個企業的運行方式，才能在開發過程中避免這類問題。在通常的OLTP開發中，你可以比較方便的理解業務流程。而在聯機分析處理（OLAP）領域，任何事情都需要親自考察，而在你周圍工作的人也許并不會發現你對業務方面存在的誤解。因此，不要自以為已經了解了足夠的信息。不斷的詢問才能使你真正了解"業務智能"中的"業務"到底是什么樣子的
順利開發數據倉庫的七種思路
對于大多數IT顧問來說，實現一個數據倉庫的難度比以前做過的任何項目難度都要大�？紤]到不同的數據結構、用途以及應用程序開發方法，以前所積累的經驗和技巧大部分都無用武之地了。但是只要在你的前進道路上稍加修正，你就會發現實現一個數據倉庫并不是難事，就算你是第一次實現數據倉庫也沒問題。
下面列出了數據倉庫實施過程需要考慮的步驟，有一些你可能從來沒有意識到，而另一些可能已經在實施過程中使用到了，但是重新思考一番也許你會有更多的領悟。開放思維，不斷嘗試新的途徑，找到一種可行的數據倉庫實現方法。
1. 再三考慮應用程序的實現方法
數據倉庫并不涉及事務處理，并且在報表方面也僅占一小部分。而數據倉庫應用程序的本質是分析，尤其是針對業務智能的分析。BI并不是通常所說的數據：它是一種從舊有數據中,模型化得到的新的數據。那么如何才能從舊有數據中挖出這些新數據呢？事實上，這個工作不是讓你來完成的，而是你的客戶所要完成的。從項目主管的角度看，應該有一個經驗豐富的數據表格設計師與你合作，進而決定如何將各類程序融合在一起。其中所遇到的最主要的挑戰將是如何用新的方法觀察數據，這也是你的客戶正在試圖使用的方法。
2. 創建抽象的、良好部署的數據庫訪問組件
在過去你接觸過的數據庫項目和現在的數據倉庫之間，有一點絕對不同，那就是：在Online Transaction Processing （OLTP）環境中，用戶數量非常大，但使用到的數據卻比較少；而在Online Analytical Processing （OLAP）環境中情況卻正好相反，少量的用戶在使用大量的數據。而你的工作就是編寫一個應用程序來優化這種不同。這里有一個線索：在你所有的分析程序中，都要能抓取連續的數據項，這樣在以后建立和訪問的數據結構中才能存放與原數據物理結構類似的數據。具體如何實現呢？首先不要規格化數據。第二將其放入數組中最小化讀取請求數。按照這種方法，DBA會很樂意與你合作。
3. 保持松散
現在回頭看看第一步，你應該可以理解定義一個分析程序不是件簡單事了，而且一般情況下，很難在第一次就實現符合要求的最終產品。而在你將要進行分析的數據結構上同樣存在這種問題。一句話，實現過程會有很多變數，你需要不斷的改動你的程序。通常我們都希望將改動次數降到最低。在一個數據倉庫實現過程中，本質是要分析過程毫無差錯，這也需要DBA的參與。不要死抓住你的程序設計、代碼、框圖，或你建立的其它什么東西不放手，要根據這種變化而不斷進行調整。
4. 將管理放在首位
在分析數據源方面你做的如何呢？你是否認為清理垃圾數據的工作非常困難？并不是只有你一個人這樣想，做過類似工作的人都有這種看法。在一個一般規模的機構中，作為數據倉庫實現過程的一部分，會有大量的舊有數據必須進行一致性處理。所以分析數據源并花費數個小時編寫轉換程序將舊有數據導入數據倉庫是整個數據倉庫實現過程中最艱難的一部分。并且這也是整個項目中最重要的一環，可以占到整個項目周期和預算的四分之三。所以一定要小心對待。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
