熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Oracle >> 正文

數據倉庫開發過程中的七個禁忌

2013-11-13 15:28:02  來源: Oracle 

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