【賽迪網－IT技術報道】高效實現數據倉庫的七個步驟
數據倉庫和我們常見的RDBMS系統有些親緣關係，但它又有所不同。如果你沒有實施過數據倉庫，那麼從設定目標到給出設計，從創建數據結構到編寫數據分析程式，再到面對挑剔的用戶的評估，整個過程都會帶給你一種與以往的項目完全不同的體驗。一句話，如果你試圖以舊有的方式創建數據倉庫，那你所面對的不是預算超支就是所建立的數據倉庫無法良好運作。
在處理一個數據倉庫項目時需要注意的問題很多，但同時也有很多有建設性的參考可以幫助你更順利的完成任務。開放思維，不斷嘗試新的途徑，對於找到一種可行的數據倉庫實現方法來說也是必需的。
1. 配備一個全職的項目經理或你自己全面負責項目管理
在通常情況下，項目經理都會同時負責多個項目的實施。這麼做完全是出於資金和IT資源方面的考慮。但是對於數據倉庫項目的管理，絕對不能出現一人身兼數個項目的情況。由於你所處的領域是你和你的團隊之前沒有進入過的領域，有關數據倉庫的一切－數據分析、設計、編程、測試、修改、維護－全都是嶄新的，因此你或者你指派的項目經理如果能全心投入，對於項目的成功會有很大幫助。
2. 將項目管理職責推給別的項目經理
由於數據倉庫實現過程實在是太困難了，為了避免自虐，你可以在當前階段的項目完成後就將項目管理職責推給別的項目經理。當然，這個新的項目經理一定要複合第一條所說的具有全職性。為什麼要這麼做呢？首先，從項目經理的角度看，數據倉庫實施過程的任何一個階段都足以讓人身心疲憊。從物理存儲設備的開發到Extract-Transform-Load的實現，從設計開發模型到OLAP，所有階段都明顯的比以前接觸的項目更加困難。每個階段不但需要新的處理方法、新的管理方法，還需要創新性的觀點。所以將管理職責推給別的項目經理不但不會對項目有損害，還可以起到幫助作用。
3.與用戶進行溝通
這裡所講的內容遠比一篇文章本身要重要的多。你必須明白，在數據倉庫的設計階段，那些潛在用戶自己也不清楚他們到底需要數據倉庫為他們做什麼。他們在不斷的探索和發現自己的需求，而你的開發團隊也在和客戶的接觸中做著同樣的事情。更加頻繁的與客戶接觸，多做記錄，並讓你的團隊更關注于項目需求討論的結果而不是討論的過程本身。
既然你和客戶的交流是為了了解存儲的數據是何種類型以及如何有效存儲數據，你也許需要（和你的用戶一起）採用一種新的方法觀察數據，而不是直接處理數據。你可以嘗試從中找出隱藏的資訊，比如在一段時期內的數字漲落等。不要試圖追尋項目需求的答案，而是要讓答案找上門來。
4. 以技術/資訊庫作為領導
由於數據倉庫實施的各個階段都有很大不同，因此你需要有人能起到維持整個項目的連續進行的作用，不過這個職責並不需要那種全職性。項目實施有三個重要方面：架構、技術和業務。將架構作為重點可以保證在整個項目中，數據倉庫的架構從物理層往上，都會受到良好的維護。而我們應該將技術作為重點，因為開發團隊和關鍵用戶都在使用他們以前從未用過的工具，必須有人監督開發過程以及工具使用的一致性。
最後，在數據倉庫的應用過程中浮現出來的業務需求必須被詳細分析和記錄，以促機開發過程持續下去。如果用戶不能很好的開發人員以及其他用戶溝通，那麼數據分析和度量方面的開發進程就會延期，所以必須有人關注業務方面的開發，推動開發進入更高級別。
5. 跳出反復修改程式的陷阱
第一次實現的數據倉庫肯定不會是最終交付的版本。為什麼呢？實際上在真正見到產品前，你無法確定的知道自己的目標是什麼。或者說，最終用戶只有在使用數據倉庫產品一段時間後，才能明確告訴你這個產品是不是他所希望的。與你以往處理的項目不同，業務智慧還處於發展的初期，每個公司對業務智慧都有不同的解釋，因此你的項目決不會一次成功。
為了以正確的格式獲得數據，你需要在不斷變化的狀況中摸索前進。BI具有很強的個性，不同的環境、不同的市場以及不同的企業都有不同的BI。這又代表什麼呢？這表示你需要把數據庫管理員放在一個消息相對封閉的環境中，不要讓他知道數據倉庫的數據結構以及ETL程式在不斷的改變。對此沒有別的辦法。這樣可以減輕你和DBA所承受的壓力。
6. 對大量的前端資源進行數據源分析
在數據倉庫實現過程中，你不得不在舊有的數據中艱難跋涉，這些數據來自老的數據庫、老的磁帶機以及遠程的數據。它們中的大部分都淩亂不堪，並且難以獲取。你要對這些數據進行大量處理，並且還要設計ETL程式來尋找其中的有用資訊。如果你希望整個項目做起來比較順利，並且找到一種方法能夠一次成功，那就需要你的開發人員必須花費足夠的時間來充分研究這些舊有數據，將淩亂的數據規則化，並盡力設計和實現強壯的數據採集和轉換過程。數據倉庫的ETL部分會佔用整個項目資源的百分之八十，所以一定要確定你的資源都用在刀刃上了。
7. 將人際關係處理放在首位
在數據倉庫實現過程中真正的地獄不是來自技術或者開發方面，而是來自你周圍的人。你也許會遇到一個對項目並不樂觀而又沒時間聽你陳述的領導。你也許會遇到一些開發人員將進度拖延太長時間還抱怨為什麼不能用老方法實施。你也許還會遇到一些抱有不切實際的幻想的用戶，他們希望輕點滑鼠就能實現想像中的功能，但卻不願在他們那邊多做些智力投資，更好的培訓他們自己的員工。而你也已經疲憊不堪，鼓勵投資，以及在開發團隊和用戶（甚至老闆）中推廣新的開發技巧。
總之你要保持微笑。當一切搞定，你的煩惱也就一掃而空了，笑到最後才笑得最輕鬆。
數據倉庫開發過程中的七個禁忌
過去我們一直使用的OLTP技術也許隱藏著許多嚴重的缺陷。數據倉庫的實現並不是一個簡單的任務，你會發現以前積累下來的豐富經驗，並不適合處理每個數據倉庫的獨特需求。
下面列出的條款是你在實現數據倉庫過程中一定會面對的問題，其中一些看起來並沒有想像中那麼嚴重，但是你還是應該儘量避免出現類似問題。數據倉庫並不是一個事務處理系統，它沒有一定的標準也不會實現某個特定的應用，但它本質上是非常有組織性的。總之，每個公司所建立的數據倉庫都是唯一的，並且每一次數據倉庫的實現方法都不是一成不變的。在實現數據倉庫時需要注意的不單是"應該如何作"，更要注意"不該如何做"。下面就是我們總結的七點"不該如何作"。
1.不要編寫自己無法快速修改的代碼
你所要編寫的程式主要用於數據分析，而不是處理事務。而你的用戶也並不真正知道他們自己真正想要一個什麼樣的程式。因此你不得不反復修改代碼好幾次，才會明白用戶到底需要一個什麼樣的程式。如果你編寫的程式具有良好的結構和靈活性，就算需要修改也不會太浪費力氣。反之，你會被自己累死。
2. 不要使用無法修改的數據庫訪問API
在過去，你的數據庫可以為大量的客戶提供穩定的數據查詢服務。而如今，你的程式必須能夠應付更多的數據查詢。這使得重新改寫程式以使得每個查詢請求能得到最大的數據量成為勢在必行的工作，而一般來說這種代碼修改都不會一次成功，所以只有選擇合適的可以修改的API，才能使程式儘快適應新的需求。
3. 不要設計任何無法擴展的東西
在連線處理過程（OLTP）應用中，數據分析並不是一個真正的應用程式。實際上，數據分析的關鍵是獲取大量舊的數據，從中提取數據模型，並以此模型推斷出新的資訊。而你所編寫的訪問潛在資訊的代碼應該具有可擴展性，可以附加新的數據。千萬別在支援數據分析的代碼中假定數據都是固定格式的。
1
2
下一頁>>
