過去我們一直使用的OLTP技術也許隱藏著許多嚴重的缺陷
數據倉庫的實現並不是一個簡單的任務
你會發現以前積累下來的豐富經驗
並不適合處理每個數據倉庫的獨特需求
下面列出的條款是你在實現數據倉庫過程中一定會面對的問題
其中一些看起來並沒有想象中那麼嚴重
但是你還是應該盡量避免出現類似問題
數據倉庫並不是一個事務處理系統
它沒有一定的標准也不會實現某個特定的應用
但它本質上是非常有組織性的
總之
每個公司所建立的數據倉庫都是唯一的
並且每一次數據倉庫的實現方法都不是一成不變的
在實現數據倉庫時需要注意的不單是
應該如何作
更要注意
不該如何做
下面就是我們總結的七點
不該如何作
不要編寫自己無法快速修改的代碼
你所要編寫的程序主要用於數據分析
而不是處理事務
而你的用戶也並不真正知道他們自己真正想要一個什麼樣的程序
因此你不得不反復修改代碼好幾次
才會明白用戶到底需要一個什麼樣的程序
如果你編寫的程序具有良好的結構和靈活性
就算需要修改也不會太浪費力氣
反之
你會被自己累死
不要使用無法修改的數據庫訪問API
在過去
你的數據庫可以為大量的客戶提供穩定的數據查詢服務
而如今
你的程序必須能夠應付更多的數據查詢
這使得重新改寫程序以使得每個查詢請求能得到最大的數據量成為勢在必行的工作
而一般來說這種代碼修改都不會一次成功
所以只有選擇合適的可以修改的API
才能使程序盡快適應新的需求
不要設計任何無法擴展的東西
在聯機處理過程（OLTP）應用中
數據分析並不是一個真正的應用程序
實際上
數據分析的關鍵是獲取大量舊的數據
從中提取數據模型
並以此模型推斷出新的信息
而你所編寫的訪問潛在信息的代碼應該具有可擴展性
可以附加新的數據
千萬別在支持數據分析的代碼中假定數據都是固定格式的
不要附加不必要的功能
一個倉庫要做的是恰到好處的服務
用戶走進倉庫
從貨架上取得自己所需得信息
僅此而已
由於業務智能
分析以及規律性的問題都有各自的處理程序
因此你的客戶唯一的需要就是獲取信息
他們需要一種應用環境
可以讓他們快速的從數據倉庫中取得分析過程所需的數據
而不論這個數據是什麼樣子的
也許你想幫助他們精煉一下獲得的數據
但最好不要這麼做
一定要記住
不要給客戶的數據分析程序添加任何會影響數據訪問性能的功能
不要簡化數據清除和數據源分析的步驟
在實現數據倉庫過程中最應該注意的地方就是為Extract
Transform
Load機制分析數據源
以及為優化負載而清除數據
安全的做法是假設項目經理在這個階段會需要整個項目資源的一半以上
相反
如果你在這方面進行了簡化
稍後肯定會後悔
所以就算系統工作緩慢
也不要簡化清理舊的數據的過程
不要避免顆粒度和分區問題
在數據倉庫設計過程中有兩個最大的數據存儲問題
第一是如何給轉換數據定位一個恰當的顆粒度等級
第二是如何將數據絕對的分區
為什麼這兩點問題如此重要呢？因為整個數據倉庫的響應能力受顆粒度影響
並且數據訪問的效率直接與數據分區性能有關
因此這是具有關鍵性的工作
不要試圖避免面對這些問題
不要在沒考慮業務問題前就使用OLAP
用戶在親眼見到程序前通常都不知道自己到底想要個什麼樣的程序
因此他們的觀點有不少錯誤
比如他們希望分析結果會忠實反應性能度量
或者希望程序會使他們部門或公司的業務工作有所不同
而你必須跳出自己的職責范圍
從IT管理者的角度考慮用戶部門直至整個企業的運行方式
才能在開發過程中避免這類問題
在通常的OLTP開發中
你可以比較方便的理解業務流程
而在聯機分析處理（OLAP）領域
任何事情都需要親自考察
而在你周圍工作的人也許並不會發現你對業務方面存在的誤解
因此
不要自以為已經了解了足夠的信息
不斷的詢問才能使你真正了解
業務智能
中的
業務
到底是什麼樣子的
From:http://tw.wingwit.com/Article/program/Oracle/201311/16760.html
