數據倉庫設計的21條原則：7個步驟，7個禁忌和7種思路

高效實現數據倉庫的七個步驟 

數據倉庫和咱們常見的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）應用中，數據分析並非一個真正的應用程序。實際上，數據分析的關鍵是獲取大量舊的數據，從中提取數據模型，並以此模型推斷出新的信息。而你所編寫的訪問潛在信息的代碼應該具備可擴展性，能夠附加新的數據。千萬別在支持數據分析的代碼中假定數據都是固定格式的。 

4. 不要附加沒必要要的功能

一個倉庫要作的是恰到好處的服務，用戶走進倉庫，從貨架上取得本身所需得信息，僅此而已。因爲業務智能、分析以及規律性的問題都有各自的處理程序，所以你的客戶惟一的須要就是獲取信息。他們須要一種應用環境，可讓他們快速的從數據倉庫中取得分析過程所需的數據，而不論這個數據是什麼樣子的。也許你想幫助他們精煉一下得到的數據，但最好不要這麼作。必定要記住，不要給客戶的數據分析程序添加任何會影響數據訪問性能的功能。

5. 不要簡化數據清除和數據源分析的步驟

在實現數據倉庫過程當中最應該注意的地方就是爲Extract-Transform-Load機制分析數據源，以及爲優化負載而清除數據。安全的作法是假設項目經理在這個階段會須要整個項目資源的一半以上。相反，若是你在這方面進行了簡化，稍後確定會後悔。因此就算系統工做緩慢，也不要簡化清理舊的數據的過程。

6. 不要避免顆粒度和分區問題

在數據倉庫設計過程當中有兩個最大的數據存儲問題，第一是如何給轉換數據定位一個恰當的顆粒度等級，第二是如何將數據絕對的分區。爲何這兩點問題如此重要呢？由於整個數據倉庫的響應能力受顆粒度影響，而且數據訪問的效率直接與數據分區性能有關。所以這是具備關鍵性的工做，不要試圖避免面對這些問題。

7. 不要在沒考慮業務問題前就使用OLAP

用戶在親眼見到程序前一般都不知道本身到底想要個什麼樣的程序。所以他們的觀點有很多錯誤，好比他們但願分析結果會忠實反應性能度量，或者但願程序會使他們部門或公司的業務工做有所不一樣。而你必須跳出本身的職責範圍，從IT管理者的角度考慮用戶部門直至整個企業的運行方式，才能在開發過程當中避免這類問題。在一般的OLTP開發中，你能夠比較方便的理解業務流程。而在聯機分析處理（OLAP）領域，任何事情都須要親自考察，而在你周圍工做的人也許並不會發現你對業務方面存在的誤解。所以，不要自覺得已經瞭解了足夠的信息。不斷的詢問才能使你真正瞭解"業務智能"中的"業務"究竟是什麼樣子的

順利開發數據倉庫的七種思路 

對於大多數IT顧問來講，實現一個數據倉庫的難度比之前作過的任何項目難度都要大。考慮到不一樣的數據結構、用途以及應用程序開發方法，之前所積累的經驗和技巧大部分都無用武之地了。可是隻要在你的前進道路上稍加修正，你就會發現實現一個數據倉庫並非難事，就算你是第一次實現數據倉庫也沒問題。 

下面列出了數據倉庫實施過程須要考慮的步驟，有一些你可能歷來沒有意識到，而另外一些可能已經在實施過程當中使用到了，可是從新思考一番也許你會有更多的領悟。開放思惟，不斷嘗試新的途徑，找到一種可行的數據倉庫實現方法。 

1. 再三考慮應用程序的實現方法

數據倉庫並不涉及事務處理，而且在報表方面也僅佔一小部分。而數據倉庫應用程序的本質是分析，尤爲是針對業務智能的分析。BI並非一般所說的數據：它是一種從舊有數據中,模型化獲得的新的數據。那麼如何才能從舊有數據中挖出這些新數據呢？事實上，這個工做不是讓你來完成的，而是你的客戶所要完成的。從項目主管的角度看，應該有一個經驗豐富的數據表格設計師與你合做，進而決定如何將各種程序融合在一塊兒。其中所遇到的最主要的挑戰將是如何用新的方法觀察數據，這也是你的客戶正在試圖使用的方法。 

2. 建立抽象的、良好部署的數據庫訪問組件

在過去你接觸過的數據庫項目和如今的數據倉庫之間，有一點絕對不一樣，那就是：在Online Transaction Processing （OLTP）環境中，用戶數量很是大，但使用到的數據卻比較少；而在Online Analytical Processing （OLAP）環境中狀況卻正好相反，少許的用戶在使用大量的數據。而你的工做就是編寫一個應用程序來優化這種不一樣。這裏有一個線索：在你全部的分析程序中，都要能抓取連續的數據項，這樣在之後創建和訪問的數據結構中才能存放與原數據物理結構相似的數據。具體如何實現呢？首先不要規格化數據。第二將其放入數組中最小化讀取請求數。按照這種方法，DBA會很樂意與你合做。

3. 保持鬆散

如今回頭看看第一步，你應該能夠理解定義一個分析程序不是件簡單事了，並且通常狀況下，很難在第一次就實現符合要求的最終產品。而在你將要進行分析的數據結構上一樣存在這種問題。一句話，實現過程會有不少變數，你須要不斷的改動你的程序。一般咱們都但願將改動次數降到最低。在一個數據倉庫實現過程當中，本質是要分析過程毫無差錯，這也須要DBA的參與。不要死抓住你的程序設計、代碼、框圖，或你創建的其它什麼東西不放手，要根據這種變化而不斷進行調整。

4. 將管理放在首位

在分析數據源方面你作的如何呢？你是否定爲清理垃圾數據的工做很是困難？並非只有你一我的這樣想，作過相似工做的人都有這種見解。在一個通常規模的機構中，做爲數據倉庫實現過程的一部分，會有大量的舊有數據必須進行一致性處理。因此分析數據源並花費數個小時編寫轉換程序將舊有數據導入數據倉庫是整個數據倉庫實現過程當中最艱難的一部分。而且這也是整個項目中最重要的一環，能夠佔到整個項目週期和預算的四分之三。因此必定要當心對待。

5. 從字裏行間發現問題

與用戶交流是個很麻煩的事情，爲何這麼說呢？由於不少用戶在見到最終產品前都不知道本身想要什麼樣的產品。定義數據倉庫應用程序是一個探索的過程，並且這個過程要反覆進行。記住所謂的"業務智能"是用戶本身定義的，他們按照本身的理解來處理業務流程。所以這些用戶就是鏈接數據和業務處理過程間的橋樑。他們所要的並非數據自己，而是隱藏在數據後面的智能性。你可讓他們討論、思考並給出建設性的意見。但千萬不要讓他們解決或讓他們任意想象和發表那些"有可能"的觀點。最後，必定要隨時留意用戶得出的結論。

6. 保持領先

數據倉庫看起來沒有傳統的OLTP模式根深蒂固，事實如此。雖然不少人投身數據倉庫的開發中，但因爲其框架與之前的系統截然不同，所以在開始的一段時間數據倉庫的實現看上去至關混亂。可是堅持下去是很重要的。它具備兩方面重要的做用。

第一，技術的領先性。它能夠跟蹤項目中任何階段的軟件工具的部署和正確使用，以及開發過程。若是這複合你的背景，你能夠對此多加留意。

第二，體系結構的領先性。它使得項目在各個階段轉換時，數據倉庫和它所支持的系統的物理以及邏輯架構都具備持續性，不會發生改變。這也是你能提供的。

7. 發出警告

最後你要記住，你並非惟一登上新大陸的人。你周圍的每個人都會有下面一點或幾點問題：不現實的指望、對技術的誤解、舊習慣或壞習慣、競爭行爲，或缺少對項目的信任度。雖然交流溝通等任務應該是項目經理負責的，但實際上你也要擔負起相同的責任。那麼做爲技術總監你該怎麼做呢？首先固然是要真誠的對待周圍的人，但必定要豎立威信，適當的發出警告。當你發現項目進度緩慢、資源流失，或者員工失去目標，就要直言不諱的說出來。快速明確的給予警告在大部分狀況下都是明智之舉。匆忙上馬的數據倉庫項目也許會出軌，但不要讓失敗的項目把你拉下馬。