6. 對大量的前端資源進行數據源分析
在數據倉庫實現過程中，你不得不在舊有的數據中艱難跋涉，這些數據來自老的數據庫、老的磁帶機以及遠程的數據。它們中的大部分都凌亂不堪，并且難以獲取。你要對這些數據進行大量處理，并且還要設計ETL程序來尋找其中的有用信息。如果你希望整個項目做起來比較順利，并且找到一種方法能夠一次成功，那就需要你的開發人員必須花費足夠的時間來充分研究這些舊有數據，將凌亂的數據規則化，并盡力設計和實現強壯的數據采集和轉換過程。數據倉庫的ETL部分會占用整個項目資源的百分之八十，所以一定要確定你的資源都用在刀刃上了。
7. 將人際關系處理放在首位
在數據倉庫實現過程中真正的地獄不是來自技術或者開發方面，而是來自你周圍的人。你也許會遇到一個對項目并不樂觀而又沒時間聽你陳述的領導。你也許會遇到一些開發人員將進度拖延太長時間還抱怨為什么不能用老方法實施。你也許還會遇到一些抱有不切實際的幻想的用戶，他們希望輕點鼠標就能實現想象中的功能，但卻不愿在他們那邊多做些智力投資，更好的培訓他們自己的員工。而你也已經疲憊不堪，鼓勵投資，以及在開發團隊和用戶（甚至老板）中推廣新的開發技巧。
總之你要保持微笑。當一切搞定，你的煩惱也就一掃而空了，笑到最后才笑得最輕松。
數據倉庫開發過程中的七個禁忌
過去我們一直使用的OLTP技術也許隱藏著許多嚴重的缺陷。數據倉庫的實現并不是一個簡單的任務，你會發現以前積累下來的豐富經驗，并不適合處理每個數據倉庫的獨特需求。
下面列出的條款是你在實現數據倉庫過程中一定會面對的問題，其中一些看起來并沒有想象中那么嚴重，但是你還是應該盡量避免出現類似問題。數據倉庫并不是一個事務處理系統，它沒有一定的標準也不會實現某個特定的應用，但它本質上是非常有組織性的�？傊�，每個公司所建立的數據倉庫都是唯一的，并且每一次數據倉庫的實現方法都不是一成不變的。在實現數據倉庫時需要注意的不單是"應該如何作"，更要注意"不該如何做"。下面就是我們總結的七點"不該如何作"。
1.不要編寫自己無法快速修改的代碼
你所要編寫的程序主要用于數據分析，而不是處理事務。而你的用戶也并不真正知道他們自己真正想要一個什么樣的程序。因此你不得不反復修改代碼好幾次，才會明白用戶到底需要一個什么樣的程序。如果你編寫的程序具有良好的結構和靈活性，就算需要修改也不會太浪費力氣。反之，你會被自己累死。
2. 不要使用無法修改的數據庫訪問API
在過去，你的數據庫可以為大量的客戶提供穩定的數據查詢服務。而如今，你的程序必須能夠應付更多的數據查詢。這使得重新改寫程序以使得每個查詢請求能得到最大的數據量成為勢在必行的工作，而一般來說這種代碼修改都不會一次成功，所以只有選擇合適的可以修改的API，才能使程序盡快適應新的需求。
3. 不要設計任何無法擴展的東西
在聯機處理過程（OLTP）應用中，數據分析并不是一個真正的應用程序。實際上，數據分析的關鍵是獲取大量舊的數據，從中提取數據模型，并以此模型推斷出新的信息。而你所編寫的訪問潛在信息的代碼應該具有可擴展性，可以附加新的數據。千萬別在支持數據分析的代碼中假定數據都是固定格式的。
4. 不要附加不必要的功能
一個倉庫要做的是恰到好處的服務，用戶走進倉庫，從貨架上取得自己所需得信息，僅此而已。由于業務智能、分析以及規律性的問題都有各自的處理程序，因此你的客戶唯一的需要就是獲取信息。他們需要一種應用環境，可以讓他們快速的從數據倉庫中取得分析過程所需的數據，而不論這個數據是什么樣子的。也許你想幫助他們精煉一下獲得的數據，但最好不要這么做。一定要記住，不要給客戶的數據分析程序添加任何會影響數據訪問性能的功能。
5. 不要簡化數據清除和數據源分析的步驟
在實現數據倉庫過程中最應該注意的地方就是為Extract-Transform-Load機制分析數據源，以及為優化負載而清除數據。安全的做法是假設項目經理在這個階段會需要整個項目資源的一半以上。相反，如果你在這方面進行了簡化，稍后肯定會后悔。所以就算系統工作緩慢，也不要簡化清理舊的數據的過程。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
