作為決策支持系統(DSS)的基礎，數據倉庫是面向主題的、集成的、不可更新的和隨時間不斷變化的。這些特點表明，數據倉庫從數據組織到數據處理都與原來的數據庫有很大的不同，這就要求我們在設計數據倉庫系統時，找到壹種適合數據倉庫設計的方法。在壹般的系統開發規劃中，首先需要確定系統的功能，這些功能壹般都是通過分析用戶的需求得到的。從數據倉庫的應用角度來看，DSS分析師壹般都是企業中的中高層管理人員，他們對決策支持的需求無法事先具體說明，只能抽象地描述給設計者。
這就需要設計人員在與用戶的不斷溝通中，逐步明確系統的需求，不斷完善。因此，數據倉庫的發展規劃過程實際上是用戶和設計者不斷了解、熟悉和完善它的過程。數據倉庫的開發和應用規劃是開發數據倉庫的首要任務。只有制定正確的數據倉庫計劃，組織的主力才能有序地實現數據倉庫的開發和應用。在數據倉庫規劃中，通常有幾個過程:選擇實施策略、確定數據倉庫的開發目標和實施範圍、選擇數據倉庫架構、建立業務和項目規劃預算。數據倉庫規劃完成後，需要編制相應的數據倉庫規劃說明書，說明數據倉庫與企業戰略的關系，以及企業急需應對的相對有限的發展機會、需要支持的關鍵職能部門、對未來數據倉庫發展的建議、實際使用計劃和發展預算，作為數據倉庫實際發展的依據。
1，選擇數據倉庫實施策略。
數據倉庫的開發策略主要包括自頂向下、自底向上以及這兩種策略的聯合使用。自頂向下策略在實際應用中比較困難，因為數據倉庫的功能是壹種決策支持功能。這個功能在企業戰略的應用範圍中往往很難確定，因為數據倉庫的應用機會往往超出了企業目前的實際業務範圍，在開發之前就確定了目標，在預定的目標達到之後就不會再去追求新的應用，這是數據倉庫更具戰略性的應用。由於該策略可以在開發前給出數據倉庫的實現範圍，並能向決策者和企業清晰地描述系統的收益和實現目標，是壹種有效的數據倉庫開發策略。在使用這種方法時，開發人員需要具有豐富的自頂向下的系統開發經驗，企業決策者和管理者充分了解數據倉庫的預定目標，並理解數據倉庫可以在那些決策中發揮作用。
自底向上策略壹般從壹個數據倉庫原型開始，選擇壹些企業管理者熟悉的具體管理問題作為數據倉庫開發的對象，在此基礎上開發數據倉庫。因此，這種策略經常用於開發數據集市、經理系統或部門的數據倉庫。這種策略的好處是企業可以用較少的投入從數據倉庫應用中獲得較高的收益。在開發過程中，很容易以較少的人員投入獲得成果。當然，如果壹個項目開發失敗，可能會耽誤整個數據倉庫系統的開發。該策略壹般用於企業在洗碗時對數據倉庫的技術進行評估，以確定該技術的應用方式、地點和時間，或者了解實現和運行數據倉庫所需的各種費用，或者在數據倉庫的應用目標不明確、數據倉庫對決策過程的影響不明確時使用。
在自頂向下的開發策略中，可以按照數據倉庫規劃、需求確定、系統分析、系統設計、系統集成、系統測試、系統試運行等階段，采用結構化或面向對象的方法來完成數據倉庫的開發。在自下而上的開發中，可以采用螺旋式原型開發方法，讓用戶根據新的需求修改試運行系統。螺旋原型開發方法要求在相對較短的時間內快速生成功能越來越多的數據倉庫系統。這種開發方式主要適用於這樣的場合:當企業的市場趨勢和需求不可預測時，市場時機是實現產品的重要壹環，與企業壹起進行市場調節需要持續改進；持久的競爭優勢來自於持續改進，而系統化的改進是基於用戶在使用中的不斷發現。自頂向下策略和自底向上策略的結合具有兩種策略的優點，既能快速完成數據倉庫的開發和應用，又能建立具有長期價值的數據倉庫方案。但在實踐中往往難以操作，通常需要有經驗的開發人員，能夠建立、應用和維護企業模型、數據模型和技術結構，能夠熟練地從具體(如業務系統中的元數據)向抽象(僅基於業務性質而非基於實現系統技術的邏輯模型)轉移；企業需要有壹個由最終用戶和信息系統人員組成的經驗豐富的開發團隊，能夠明確指出數據倉庫在企業戰略決策支持中的應用。
2.確定數據倉庫的發展目標和實施範圍。
為了確定數據倉庫的發展目標和實現範圍，需要向企業管理者和其他數據倉庫用戶說明數據倉庫在企業管理中的應用和發展趨勢，說明企業組織和使用數據支持跨職能系統和支持企業經營戰略的重要性，以確定發展目標。在這個階段，應該確認與使用數據倉庫相關的業務需求。這些需求應該只支持最重要的業務職能部門，集中在效益明顯的業務上，這樣數據倉庫的應用才能有立竿見影的效果，同時把數據倉庫的應用分散在所有業務上，也不應該消耗太多的精力。
在確定開發目標和範圍後，應編寫需求文檔，作為將來開發數據倉庫的基礎。數據倉庫開發的首要目標是當用戶提供決策輔助時，確定所需信息的範圍以及主題和索引字段中需要哪些數據源。這就需要定義:用戶需要什麽數據？面向主題的數據倉庫需要什麽樣的支撐數據？開發者成功向用戶提交數據需要哪些業務知識？什麽背景知識？因此，需要定義總體需求，以文件的形式組織現有的記錄系統和系統環境，識別和排序使用數據倉庫中數據的候選應用系統，構建傳輸模型，確定規模、事實和時間戳算法，以便從系統中提取信息並將其放入數據倉庫。信息範圍的確定可以為開發人員提供壹個很好的分析平臺，分析數據倉庫需要哪些信息，與用戶的業務活動需要哪些數據。開發人員和用戶可以進壹步定義需求，例如數據分級的級別、聚合的級別、加載的頻率以及要維護的時間表。數據倉庫開發的另壹個重要目標是確定使用哪些方法和工具來訪問和導航數據。雖然用戶都需要訪問和檢索數據倉庫的內容，但是訪問的粒度不同，有的可能是詳細記錄，有的可能是比較籠統的記錄或者非常籠統的記錄。用戶要求的數據泛化程度不同，會導致對數據倉庫聚合和泛化工具的需求不同。
數據倉庫還具有訪問和檢索圖表、預定義報告、多維數據、匯總數據和詳細記錄的功能。用戶要在支持多維分析的電子表格、統計分析儀和分析處理器的支持下，從數據倉庫中獲取信息，從而對數據倉庫中的內容進行解讀和分析，生成和驗證不同的市場假設、建議和決策方案。為了清晰地向用戶表達決策建議和各種決策方案，需要報表、圖表、圖像等強大的信息表達工具。數據倉庫開發的另壹個目標是確定數據倉庫中數據的規模。數據倉庫不僅包含當前數據，還包含多年的歷史數據。數據的泛化程度決定了這些數據的最大壓縮和泛化能力。如果數據倉庫要提供決策和查詢歷史記錄的功能，就必須支持對大量數據的管理。數據的規模不僅直接影響決策查詢的時間，也直接影響企業決策的質量。
在數據倉庫的開發目標中，有:根據用戶對數據倉庫的基本需求，確定數據在數據倉庫中的意義；確定數據倉庫內容的質量，以確定使用、分析和建議的可信度；什麽樣的數據倉庫能滿足最終用戶的需求，這些數據倉庫應該具備什麽功能；需要什麽元數據，如何使用數據源中的數據等。數據倉庫的開發目標多樣而復雜，需要開發人員和用戶在開發和使用過程中不斷交互和改進。因此，有必要在規劃中確定數據倉庫的發展範圍。這樣開發人員可以根據需求和目標的重要性循序漸進，並從開發中吸取經驗教訓，為數據倉庫在企業中的全面實現提供技術準備。因此，在確定了數據倉庫的總體發展方向和目標之後，就需要確定壹個能夠快速反映數據倉庫的好處的有限的使用範圍。在考慮數據倉庫的應用範圍時，主要從部門數量和類型、數據源數量、企業模型子集、預算分配、開發項目所需時間等角度進行分析。
在分析這些因素的時候，我們可以從用戶的角度和技術的角度來做。從用戶的角度來看，哪些部門應該首先使用數據倉庫？誰出於什麽目的使用數據倉庫？數據倉庫應該首先滿足哪些決策查詢？因為這些決策查詢通常決定了數據的維度和報告的類型，所以這些因素將決定定義數據倉庫時所需的數量關系。查詢格式越具體，就越容易提供數據倉庫的維度、聚集和概括的規劃描述。從技術角度來看，我們應該確定數據倉庫中元數據庫的大小。數據倉庫中的元數據庫是用於在數據倉庫中存儲數據定義的模型。數據定義存儲在倉庫管理器的目錄中，可以作為所有查詢和報告工具構建和查詢數據倉庫的基礎。元數據庫的大小直接指示了必須在數據倉庫中管理的數據大小。通過管理元數據庫的大小，實際上確定了數據倉庫中需要管理的數據大小。
3.數據倉庫的結構選擇
數據倉庫的結構可以靈活選擇，組織使用的各種平臺可以適當劃分，最終用戶使用的數據源、數據倉庫和工作站可以分開進行適當的設計。
(1)數據倉庫的應用結構
在這種結構中，基於業務處理系統的數據倉庫使用只讀應用程序中的操作數據，而不修改數據。這種結構的數據倉庫元數據數據庫是壹個虛擬數據庫，而不是數據倉庫本身的元數據。在數據倉庫元數據庫的直接指導下，數據倉庫的查詢簡單來說就是從數據庫中提取數據。
簡單數據倉庫
通過數據倉庫中的數據源提純、集成、泛化、整合等操作，將數據源從業務處理系統傳輸到集中的數據倉庫，各部門的數據倉庫應用只在數據倉庫中進行。這種結構經常發生在許多部門和少數用戶使用數據倉庫的情況下。這裏的集中只是邏輯上的，也可能是物理上的分散。
簡單數據集市
數據集市是指各部門使用的數據倉庫，因為企業中每個職能部門都有自己的特殊需求，壹個統壹的數據倉庫不壹定能滿足這些部門的特殊需求。這種架構經常發生在個別部門對數據倉庫的應用感興趣，而組織中的其他部門對數據倉庫的應用卻非常冷漠的情況下，由熱心的部門獨立采用。
數據倉庫和數據集市
企業的每個部門都有壹個滿足自己需求的數據集市，其數據是從企業數據倉庫中獲取的，企業數據倉庫從企業的各種數據源中收集和分發。這種架構是壹種比較完善的數據倉庫架構，當整個組織都對數據倉庫應用感興趣時，往往會出現這種架構。
(2)數據倉庫的技術平臺結構是單層結構。
單層結構主要是在數據源和數據倉庫之間共享平臺，或者使數據源、數據倉庫、數據集市和最終用戶工作站使用同壹個平臺。* * *共享平臺可以降低數據提取和數據轉換的復雜度，但是* * *共享平臺在應用中可能會遇到性能和管理問題。這種架構壹般在數據倉庫規模較小，組織的業務系統平臺潛力較大的情況下采用。
客戶機/服務器兩層結構
壹層是客戶端，另壹層是服務器。最終用戶訪問工具運行在客戶機層，而數據源、數據倉庫和數據集市位於服務器上。這種技術組織通常用於普通規模的數據倉庫。
三層客戶/服務器結構
基於工作站的客戶端層、基於服務器的中間層和基於主機的第三層。宿主層負責管理數據源和可選的源數據轉換；服務器運行數據倉庫和數據集市軟件，存儲倉庫的數據；客戶端工作站運行查詢和報告應用程序，還可以存儲從數據集市或數據倉庫卸載的本地數據。當數據倉庫規模稍大時，兩層數據倉庫結構已經不能滿足客戶的需求。當數據倉庫的數據存儲管理、應用處理和客戶端應用分離時，可以采用這種結構。
多層結構
這是壹個在三層組織基礎上開發的數據倉庫結構。在這個結構中，從最裏面的數據層到最外面的客戶層，有:獨立的數據倉庫存儲層，用於管理數據倉庫和數據集市的數據倉庫服務層，用於數據倉庫查詢處理的查詢服務層，用於完成數據倉庫應用處理的應用服務層，以及面向最終用戶的客戶層。架構可能多達五層，壹般用於超大規模的數據倉庫系統。
4、數據倉庫使用計劃和項目規劃預算
數據倉庫的實際使用方案和開發預算是數據倉庫規劃中最後要確定的問題。由於數據倉庫主要用於支持企業管理者的決策，因此保證其實用性非常重要，因此有必要讓最終用戶參與數據倉庫的功能設計。這種參與是通過用戶的實際使用計劃來進行的，這是壹個非常重要的需求模型。實際使用方案必須有助於明確最終用戶對數據倉庫的需求。這些需求中，有些基本上可以通過使用合適的數據源來滿足，而有些則需要來自企業外部的數據源，這就需要使用方案來鏈接這些不同的需求。實際使用方案還可以將最終用戶的決策支持需求與數據倉庫的技術需求聯系起來。因為當用戶確定最終需求時，就為元數據庫的範圍確定了壹個邊界。您還可以確定所需的歷史信息量。根據具體用戶規劃數據倉庫時，可以確定最終用戶關心的維度(時間、地點、業務單元、生產企業)。因為維度與所需的概括操作有明顯的關系，所以您必須選擇對最終用戶有實際意義的維度，例如“月”、“季度”和“年”。最後，可以確定數據集市/數據倉庫的結構需求，以便設計人員確定是采用簡單的數據倉庫結構、簡單的數據集市結構還是兩者的結合。
開發方案的實際用途確定後，需要對開發方案的預算進行估算，確定項目的投資額。投資方案可以根據之前的軟件開發成本來確定，但是這個預算的評估比較粗糙。另壹種方法是參照結構進行成本評估，即將數據倉庫實際使用方案確定的組件進行分解，根據每個組件的成本進行預算估算。數據倉庫的組成部分包括數據源、數據倉庫、數據集市、最終用戶訪問、數據管理、元數據管理、傳輸基礎等。這些組件有的是企業原有信息系統中已經有的，有的可以選擇商業組件，有的需要自主開發。根據這些組成部分的不同來源，可以確定更準確的預算。數據倉庫規劃完成後，需要編制數據倉庫開發手冊，說明系統與企業戰略目標的關系，以及系統和企業迫切需要處理的相對有限的發展機會，設想的商業機會的描述，目標和任務的壹般描述，關鍵職能部門和對未來工作的建議。數據倉庫項目應該從壹個清晰的業務價值計劃開始，其中需要闡明預期的有形和無形的好處。無形的好處包括通過使用數據倉庫更快更好地做出決策的好處。
業務價值計劃最好由目標業務主管來完成，因為數據倉庫是用戶驅動的，用戶應該積極參與數據倉庫的構建。在策劃書中，應確定數據倉庫開發目標的實現範圍、架構、使用方案和開發預算。