建立一個數據倉庫并不是一個簡單的任務，不應該由一個人單獨完成。由于數據倉庫最佳結合了業務慣例和信息系統技術，因此，一個成功的數據倉庫實施需要這兩方面的不斷協調，以均衡其所有的需要，要求，任務和成果。我很樂意與大家分享我在規劃和管理任何數據庫項目時采用的方法，這些數據庫包括交易數據庫，數據倉庫，和混合型數據庫。由于我生活在關系數據庫和數據倉庫以及用以支撐它們的數據提取，轉換和加載(ETL )過程中，所以我會集中在這些領域討論我的方法。然而，您可以將這些方法擴展到整個棧--OLAP立方體和如報告，特征分析(ad-hoc analysis)，記分卡和儀表盤展示之類的信息傳遞應用。

我不是吃撐了要告訴一個真正的項目經理( PM )如何做他或她的工作，相反，我寫的這些是為那些數據庫管理員和開發者，他們沒有好運氣能與有經驗的項目經理一起工作;同樣也適合這樣的IT專業人員，他們被突然要求：“建立一個數據倉庫“，并且需要自己扮演項目經理的角色。我的討論不會是完整的，但我希望這會給您足夠的信息來讓您的項目球滾起來。

如圖1所示，數據倉庫項目有3個軌道(tracks)：數據軌道，技術軌道和應用層軌道。當您在整理任何數據庫項目計劃時，我建議您以這三個軌道為模板來管理和同步您的活動。當您向技術決策者( TDMs ) ，商業決策者( BDMs ) ，和所有其他該數據倉庫項目參與者講解您的計劃時，您也可以把圖1當作一個高級的概要圖來使用。

使用一種生命周期管理方法

我鼓勵您利用您的組織可以提供的資源，比如設計，開發和部署系統和軟件的技術和方法。如果貴公司對于這些工作沒有采用任何正式的方法，繼續前進吧，您可采用我為我自己的數據庫項目開發的7D數據庫生命周期管理方法(Discover, Design, Develop, Deploy, Day to Day , Defend, Decommission), 昵稱“7D法”。

我的“7D”數據庫生命周期管理方法講的是數據庫的生命周期管理，而不是相關的軟件(應用程序)和硬件的生命周期。圖1包括了軟硬件軌道，但我不會進一步闡述它們的管理。為了成功實施數據庫生命周期的方法，有必要調整和同步數據庫生命周期的里程碑、硬件和應用軟件。

數據倉庫的構建從來不會真正結束。不像傳統的數據庫在部署后的一段時間里保持相對的不變，數據倉庫始終處于不斷的變化之中，以應對它所服務的業務環境的變化。當今的業務環境更加復雜，并涉及比以往任何時候都要快的變化。處理這種幾乎是不斷的變化是企業的最大挑戰之一。這就是為什么數據倉庫團隊中的每一個人，包括技術決策者( TDMs ) 和業務決策者( BDMs )，都必須處在同一陣線上，使用同一種生命周期管理方法，以使他們的認識完全得到統一。只有這樣，才有可能對已實施的數據倉庫、企業的構想和宗旨進行調整。在圖1中，我已經展示了我的“7D法”的7個步驟，本文將帶領您完成每一步。

第一步：發掘

我保證任何規模和領域的數據庫項目離開了開始的發掘階段都將失敗。這個階段也被稱為“需求分析和定義”， 發掘階段需要以業務為中心，特別是數據倉庫項目，因為數據倉庫的輸出需要支持組織的目標。發掘這一步實質上就是調查，您應該不斷地問六個基本問題(什么，如何，在何處，誰，何時和為什么)，記錄好答案，并把這些答案包含在您起草的解決方案中。

在“7步”的前3步(發掘，設計，開發)中，必須對業務主和技術專家進行集中的協調，項目經理(PM)應該促成這一進程。項目經理作為一個獨立的專業人員，主要關心項目的及時上線、預算在控制范圍內，有預期的運行效果;項目經理在得到各方的反饋意見后，負責制定嚴格的路線，里程碑和成功指標。如果項目里沒有PM,這些將成為您的工作。

在發掘階段，PM必須收集圖1所示的三個軌道的信息，即技術軌道，數據軌道和應用層軌道。在其他任務中，PM必須確定利益相關者和用戶，必須理解他們各自的角色和相應的數據/視圖 需求。PM必須知道本組織的績效管理策略：目標是什么，倡議什么以及跟蹤業務和項目健康狀況的支撐度量標準/關鍵績效指標。如果上述策略的任何部分遺漏了，該項目很有可能失去最終用戶的評分，這可能會導致低的采用通過率和未來資金的丟失。換句話說，該項目將失敗，而不管項目任務執行得有多么完美。

第二步： 設計

設計這一步的主要活動是定義描述數據倉庫的語義和概要模型。這些模型必須解決企業用戶的管理信息系統(MISs)和商務智能( BI )分析需要。對于數據倉庫項目，您可以為關系型數據倉庫創建概念和邏輯數據模型，為表示多維立方體創建三維模型。您可以使用決策矩陣，以幫助確定每個三維模型需要包含些什么;沿Y軸方向列出被數據倉庫支持的關鍵業務流程，沿X軸方向列出建議的維。這個矩陣將作為當前開發、未來擴展和跨組織集成的向導。在設計階段建立的模型必須反映第一階段您收集的六個問題的答案。標識數據倉庫相關的所有數據源(內部和外部的)，業務/交易數據庫和展平文件是個好注意。您也應該明確說明哪些數據將被導入數據倉庫，哪些只會簡單地作為外部數據源引用。

通常，技術軌道有自己的PM，但您仍然可能需要填補那個角色。數據倉庫可以增長為非常大的內容和十分廣泛的范圍，因此有必要在數據倉庫部署之前恰當地規劃其大小。首先在紙上估計其大小，這樣您就可以大致把握當數據倉庫投入產品應用時所需的處理器速度和磁盤容量。您需要估算一天的業務終端用戶數量以及他們使用的應用(例如，對立方體做一個特別分析，或者從關系數據倉庫中取出緩存的報告)，也要估算數據倉庫一年中將會存儲的數據量。只是因為數據倉庫是一個進展中的工作，您需要兩年和五年預測，同樣，其處理能力和數據存儲需求將隨著時間的推移不斷增加。數據倉庫設施包括各種硬件，通信和軟件解決方案，所有這一切都必須協同工作，為終端用戶提供一個工作的數據倉庫。您需要足夠的時間來計劃和測試您將如何整合所有這些不同的組成部分。

跟技術軌道一樣，應用軌道可能有自己的PM或由一個主導的軟件開發人員充當這一角色。如果你是幸運的，你的工作將是與此人協調以同步任務。如果不是，那你的工作描述會擴大。應用層包括獲取從數據倉庫收集到的輸出，通常是MIS報告和BI分析結果。MIS報告常是屏幕顯示，儀表板，和打印副本的形式，它們幫助企業管理者做出運行日常業務所需的戰術決策。這些輸出相對比較容易界定、編碼和被一系列標準化的進程抓取，這些進程運行在可預定環境中。應用層的BI部分是一組查詢和響應，以幫助執行管理作出戰略決策，推動商務運營。BI解決方案往往是非結構化的，很難預定義，因為他們傾向于用一種特別的方式探索數據。記分牌，圖形和數據透視表是BI的應用例子，它們能刺激更多的數據探索，而這可能導致公司內部戰略方向的改變。#p#分頁標題#e#

在這個階段許多方法要求原型或試點項目。“7D法”不需要。至多，作為應用層的設計活動中的一部分，你可以做一個“點擊模式”--一種輸入/輸出屏幕的快速呈現模型，不涉及或只有極少的代碼但卻能給利益攸關方可視化的概念，同時又不會吃掉寶貴的時間和資源。如果試點或原型是必要的，那么選擇其中的一個切片(slice)作為試點，完成“7D法”的每一步。“7D法”不區分試點，原型和產品系統--它們都被視為項目。

如果按照“7D法”設計了一個原型，并且最終進入了產品(大多數原型都是這樣)，然后您必須比第一個切片更仔細地選擇第二個切片。如果這些切片不能成功地集成在一起，如果他們不支持您在發掘步驟發現的企業宗旨和意圖，那么您在創建“煙囪”， 這是信息的群島，整合彼此只會遇到困難，在某些情況下，甚至根本不可能.

第三步：開發

數據軌道開發步驟主要有兩個部分：第一個涉及將數據模型映射到其對應的物理設計(實質是關系數據倉庫和OLAP立方體的藍圖)，規劃數據庫的大小，必要時對表進行分塊，為數據倉庫對象設定命名約定以便業務用戶和技術用戶都能適應，并制定索引和識別索引候選名單的策略。第二部分涉及數據從外部數據源到數據倉庫的提取轉換加載(ETL)。包含在第二部分但不局限于這一部分的是數據轉換服務( DTS )/SQL Server整合服務( SSIS)補丁的開發與測試，導入/導出和T-SQL腳本開發和測試，以及對外部數據源組件的數據整合測試，這些數據不會導入到數據倉庫。

技術軌道的開發步驟包括審查，測試和選擇產品，并提供其作品的體系結構設計。為了組成通信鏈路的各個層--物理層、數據鏈路層、網絡層以及傳輸層，會話和表現層，這樣做是必需的。雖然許多產品把多層無縫打包到一個解決方案，但有必要認識到這些層中的每一個在未來的負載要求和性能要求，并提前為這些需求作好準備。為了從新的數據倉庫交付數據，您應該選定數據倉庫的服務器和存儲解決方案，以及新的，最終用戶面臨的硬件。這樣做是為了產品數據倉庫和分期數據庫--DTS/SSIS軟件包和T-SQL腳本在這里執行，從外部數據源導入數據，以及把可操作和精心料理的數據導入到關系數據倉庫和OLAP立方體中。根據發掘階段收集到的需求，您的數據倉庫環境可能還要支持數據集市，快照，和報告數據庫，因此，也要準備為這些方面考慮環境。

應用軌道開發步驟聽起來很簡單：只要開發終端用戶應用程序。然而，這可能是整個過程中最復雜和費時的任務，并且可能是代價最高的--如果沒有認真制定和考慮成功的度量標準。正是在這一階段，范圍蠕變(不斷增加特性和功能，而不考慮對其他兩個軌道的設計和開發的影響)可能像魚雷一樣破壞項目。除了開發終端用戶應用程序，您也不得不制定測試這些應用程序的計劃，您需要制定終端用戶培訓計劃以便用戶能學會如何使用這些應用軟件。在每一個里程碑，你必須確保獲得相關各方的簽字或驗收。

這可能聽起來很明顯，但多少令人驚訝的是不知道有多少開發項目是在產品環境中階段化和測試的!別這樣做，只是不要這樣做!為開發，測試，和組件劃分搭建一個單獨的物理環境。對業務系統要這樣做--同樣，對BI/數據倉庫也要這樣做。

第四步：部署

部署數據倉庫和部署交易數據庫是不一樣的，通常，您以一種快速、包羅萬象的風格部署一個交易數據庫-周五晚上終端用戶在使用舊式系統，而周一上午他們登錄到新的數據庫。數據倉庫通常是遞增式地部署到整個企業的各類用戶中。這種遞增的速度和各個組使用數據倉庫的次序是包含在部署階段中部署計劃的一部分。

理想的情況下，數據倉庫的部署以一種迅速級聯的層次進行，首先是技術就位--服務器，存儲設備，通信鏈接等，系統軟件的安裝，測試并準備投入產品。然后是數據軌道各組件的展開--數據倉庫數據庫(關系型和OLAP )的建立，以及ETL進程的聯機。在最終的應用層添加之前往往會打住一下，當您通過ETL進程讓數據流從外部來源進入各種不同的數據倉庫數據庫和立方體時，進行必要的測試和調整。然后應用層被部署。您可能想要逐漸地部署應用層，因為企業內部的不同人員有不同的等級。

作為一個PM，你發揮著非常重要的作用。在你的指導和引導下，三個軌道將按預定計劃到達部署階段，避免數周數月的“誤點”憂慮。一旦技術和數據軌道就緒并測試，并準備繼續，那么開始展開應用層。沒有用戶界面( UI)的數據倉庫對任何人都是沒用的，而一個尺寸不足，弱工程系統架構的數據倉庫會因性能太差而不會被企業用戶采用。

第五步：每一天

日常業務運營的管理是非常重要的;而這常常在規劃和開發過程中被忽視。你不僅必須確保定期(每日，每周等)進行維護，包括硬件和軟件，還必須要不斷監視所有系統的性能和增長。正如我一開始所說，數據倉庫永遠不會結束;隨著越來越多的用戶發現數據的內在價值，并創造新的，有時甚至是具有挑戰性的方式來查詢數據倉庫，它會繼續增長和擴大。有些PM的任務有時你必須準備承擔，包括確保所有的系統(硬件，通信鏈路，系統軟件)的全面運作，打最新的補丁和升級。當業務瓶頸出現時盡可能快地診斷和解決問題; 確保所有需要做備份的系統及時備份，實際上，有備份工作定義和計劃，并要求所有的備份恢復測試，后續測試，開發，或報告數據庫。

業務不是靜止的，它們必須不斷地改造自己，以保持競爭力。數據倉庫數據管理員的職責就是跟蹤數據的使用，評估數據的重要性，并檢測業務什么時候開始需要轉變。隨著業務模式的變化，將會需要更新，更好，更靈活，可能更復雜的用戶應用程序，數據管理員應該能感知到這些要求。有時，當業務方向和重點變化到了一定的程度，就需要重新進入發掘階段，生命周期將回到原點。洗滌，漂洗，重復下去。

第六步：防護

捍衛你的數據倉庫涉及的不僅僅是采取定期備份或確保沒有任何應用程序包括SQL查詢可能會開放給SQL注入式攻擊。你必須計劃整個范圍和寬度的捍衛，因為數據倉庫包含了企業最寶貴的資產--它的數據，以一種經過編譯的，清理過的，以及(在某些情況下)信息化了的格式存在。

數據倉庫的威脅通常分為兩類，物理的和邏輯的。物理方面的威脅可以是外部的(龍卷風，洪水，火災，地震)或內部(有意的，偶然的)。您可以防止來自物理方面威脅的做法既可以是采用簡單的限制訪問計算機和通信室，也可以如位于地理上相距甚遠的容錯站點上的鏡像服務器般復雜(且昂貴)。物理防御取決于您的恢復時間和恢復點目標，也就是多少時間你的數據倉庫離線你可以忍受和多少數據丟失你可以承擔。#p#分頁標題#e#

邏輯威脅要復雜得多，僅僅因為數據倉庫環境的自然特性。操作系統可能會失敗，數據庫管理系統可能會崩潰，一個或多個應用程序可能有意無意損壞、銷毀、誤解數據(尤其出現在承擔數據倉庫給養任務的ETL過程中)。瀏覽器的用戶界面已經把嵌入式SQL調用暴露給了SQL注入式攻擊。每一個潛在的威脅都必須查明和處理; 在威脅發生之前制定補救措施要比它們發生之后好得多。PM的工作是為您的整個數據倉庫安裝制定一個全面的防御。如果你足夠幸運有一個安全管理員，利用此人的專長和經驗。

第七步：退役

可能有一天當數據倉庫，或一個組件部分(分期數據庫，數據集市，報告數據庫，立方體)不再符合要求，解除它的時間就到了。并非每一個數據庫都可以不斷重構或升級，以滿足新的要求。有時候，你僅僅是需要丟棄和重建，特別是如果數據庫實例是“規范建立的”，即沒有適當的架構充分反映企業的目標和意圖。在這種情況下，作為PM，你必須同步進程。

一般來說，退役步驟以如下三種方式之一發生：沒有更換的退役;移交式退役;和逐步到位/逐步淘汰的退役。“沒有更換的退役”是指數據庫用來執行的功能不再需要。不僅是數據庫退休了，在它之上的執行功能也退休了。 “移交式退役”表明另一個數據庫將取代退役的數據庫，并且其對應的執行功能也將從舊的數據庫迅速轉移到新的。某一天，用戶可能訪問舊的數據庫，而第二天他們將訪問新的。“逐步到位/逐步淘汰的退役”表明舊的和新的數據庫將并存運行一段時間，而功能和用戶逐步從舊的轉移到新的，直到最后再也沒有用戶或功能運行舊的數據庫時，它就可以退役了。每個方案都有其風險和回報;作為PM你必須確定何時風險大于收益，確定哪種計劃最適合您的情況。然后你必須與技術軌道和應用軌道的其他人員協同工作，計劃和執行，以確保無縫轉換。

良性循環

在您與這些數據倉庫的各個組件打交道的過程中，隨后將會有新一輪的發現，這期間你會評估隨著時間而發展的新需求。發生這種情況可能來自從存儲在數據倉庫中的數據收集到的信息。這些新的要求可能會導致擴大增強一個或多個軌道的設計和解決方案。您需要將這些變化反映到現有的數據倉庫中，這樣您就可以部署更新、更好的、用戶渴望利用的解決方案。為保持數據倉庫像不可思議的機器一樣運行，一些新的要求可能會導致日常運作的變化。

隨著時間的推移，生命周期的多次迭代過程會導致數據倉庫緊密聯系于企業結構，直到數據倉庫和業務成為無縫的整體。對于這一難題，PM的職責是確保所有活動和任務都是按照規范進行，被既定的成功指標接受，并被同步部署。即使您的數據倉庫項目沒有正式的PM，即使你是人力資源唯一列在這個項目上的人員，你仍然應該做一些PM會做的計劃，并及時更新。然后，當管理層問：“數據倉庫項目進展如何了?”你可以告訴他們項目目前處在什么階段和已經干了些什么工作。