在一般的數據倉庫應用系統中，根據系統體系結構的不同，數據倉庫設計的內容和範圍不盡相同，並且設計方法也不盡相同，下面的兩幅圖示分別表示帶有ODS的數據倉庫應用系統體系結構和不帶ODS的數據倉庫應用系統體系結構。本文將說明兩個體系結構上的差異以及這種差異造成的設計方法的不同，並且重點介紹帶有ODS的體系結構中數據倉庫的設計方法。
在數據倉庫的設計指導思想中，數據倉庫的概念定義是非常重要的，數據倉庫概念規定了數據倉庫所具有的幾個基本特性，這些特性也正是對數據倉庫設計結果進行檢驗的重要依據。
根據Bill.Inmon的定義，「數據倉庫是面向主題的、集成的、穩定的、隨時間變化的，主要用於決策支持的數據庫系統」。
ODS（Operational Data Store）是數據倉庫體系結構中的一個可選部分，ODS具備數據倉庫的部分特征和OLTP系統的部分特征，它是「面向主題的、集成的、當前或接近當前的、不斷變化的」數據。
一般在帶有ODS的系統體系結構中，ODS都設計為如下幾個作用：
1）在業務系統和數據倉庫之間形成一個隔離層
一般的數據倉庫應用系統都具有非常復雜的數據來源，這些數據存放在不同的地理位置、不同的數據庫、不同的應用之中，從這些業務系統對數據進行抽取並不是一件容易的事。因此，ODS用於存放從業務系統直接抽取出來的數據，這些數據從數據結構、數據之間的邏輯關系上都與業務系統基本保持一致，因此在抽取過程中極大降低了數據轉化的復雜性，而主要關註數據抽取的接口、數據量大小、抽取方式等方面的問題。
2）轉移一部分業務系統細節查詢的功能
在數據倉庫建立之前，大量的報表、分析是由業務系統直接支持的，在一些比較復雜的報表生成過程中，對業務系統的運行產生相當大的壓力。ODS的數據從粒度、組織方式等各個方面都保持了與業務系統的一致，那麽原來由業務系統產生的報表、細節數據的查詢自然能夠從ODS中進行，從而降低業務系統的查詢壓力。
3）完成數據倉庫中不能完成的一些功能
一般來說，帶有ODS的數據倉庫體系結構中，DW層所存儲的數據都是進行匯總過的數據，並不存儲每筆交易產生的細節數據，但是在某些特殊的應用中，可能需要對交易細節數據進行查詢，這時就需要把細節數據查詢的功能轉移到ODS來完成，而且ODS的數據模型按照面向主題的方式進行存儲，可以方便地支持多維分析等查詢功能文章來源：中國公務網 2005-6-20 1:51:55。
在一個沒有ODS層的數據倉庫應用系統體系結構中，數據倉庫中存儲的數據粒度是根據需要而確定的，但一般來說，最為細節的業務數據也是需要保留的，實際上也就相當於ODS，但與ODS所不同的是，這時的細節數據不是「當前、不斷變化的」數據，而是「歷史的，不再變化的」數據。
設計方法
在數據倉庫設計方法和信息模型建模方法中，前人的著作對各種思路和方法都做過大量的研究和對比，重點集中在ER模型和維模型的比較和應用上。根據我們的實踐經驗，ER模型和維模型在數據倉庫設計中並非絕對對立，尤其在ODS設計上，從宏觀的角度來看數據之間的關系，以ER模型最為清晰，但從實現出來的數據結構上看，用維模型更加符合實際的需要。因此孤立地看ER模型或者維模型都缺乏科學客觀的精神，需要從具體應用上去考慮如何應用不同的設計方法，但目標是一定的，就是要能夠把企業的數據從宏觀到微觀能夠清晰表達，並且能夠實現出來。
本文中重點介紹維模型的應用。
ODS設計指南
在ODS的概念定義中，已經描述了ODS的功能和特點，實際上ODS設計的目標就是以這些特點作為依據的。ODS設計與DW設計在著眼點上有所不同，ODS重點考慮業務系統數據是什麽樣子的，關系如何，在業務流程處理的哪個環節，以及數據抽取接口等問題。
第零步：數據調研
有關數據調研的內容和要求，在《調研規範》文檔中做了詳細定義，此處不再重復。
第一步：確定數據範圍
確定數據範圍實際上是對ODS進行主題劃分的過程，這種劃分是基於對業務系統的調研的基礎上而進行的，並不十分關心整個數據倉庫系統上端應用需求，但是需要把上端應用需求與ODS數據範圍進行驗證，以確保應用所需的數據都已經從業務系統中抽取出來，並且得到了很好的組織。一般來講，主題的劃分是以業務系統的信息模型為依據的，設計者需要綜合各種業務系統的信息模型，並進行宏觀的歸並，得到企業範圍內的高層數據視圖，並加以抽象，劃定幾個邏輯的數據主題範圍。在這個階段，以ER模型表示數據主題關系最為恰當。
第二步：根據數據範圍進行進一步的數據分析和主題定義
在第一步中定義出來了企業範圍內的高層數據視圖，以及所收集到的各種業務系統的資料，在這一步中，需要對大的數據主題進行分解，並進行主題定義，直到每個主題能夠直接對應一個主題數據模型為止。在這個階段，將把第一步生成的每個ER圖中的實體進行分解，分解的結果仍以ER表示為佳。
第三步：定義主題元素
定義維、度量、主題、粒度、存儲期限
定義維的概念特性：
維名稱，名稱應該能夠清晰表示出這個維的業務含義。
維成員，也就是這個維所代表的具體的數據，
維層次，維成員之間的隸屬與包含的層次關系，每個層次需要定義名稱
定義度量的概念特性：
度量名稱，名稱應該能夠清晰標書這個度量的業務含義
定義主題的概念特性：
主題名稱和含義，說明該主題主要包含哪些數據，用於什麽分析；
主題所包含的維和度量；
主題的事實表，以及事實表的數據。
定義粒度：
主題中事實表的數據粒度說明，這種粒度可以通過對維的層次限制加以說明，也可以通過對事實表數據的業務細節程度進行說明。
定義存儲期限：
主題中事實表中的數據存儲周期。
第四步：叠代，歸並維、度量的定義
在ODS中，因數據來自於多個系統，數據主題劃分時雖然對數據概念進行了一定程度上的歸並，但具體的業務代碼所形成的各個維、以及維成員等還需要進一步進行歸並，把概念統一的維定義成一個維，不允許同一個維存在不同的實體表示（象不同的業務系統中一樣）Www.GongWu.Com.Cn 2007-2-1 5:40:50。
第五步：物理實現
定義每個主題的數據抽取周期、抽取時間、抽取方式、數據接口，抽取流程和規則。
物理設計不僅僅是ODS部分的數據庫物理實現，設計數據庫參數、操作系統參數、數據存儲設計之外，有關數據抽取接口等問題必須清晰定義。
DW設計指南
盡管我們看到過很多關於「不考慮應用，先建立數據平臺」的說法，但建立一個「萬能的」東西是不可能的，所以數據倉庫的設計必須參照應用範圍、應用類型，例如要考慮到系統用於報表、OLAP、數據挖掘的哪些模型等等，不同的應用對數據倉庫的設計有不同的要求。
數據倉庫是面向主題的、集成的、穩定的、隨時間變化的數據，數據倉庫的這幾個特征的含義在這裏不具體多介紹，但本人要說明如何實現這些特性。
在數據倉庫的設計中時刻不能忘記的幾個問題列舉如下：
1、數據粒度和數據組織
在數據倉庫的每個主題，都必須知道這個主題所限定的維的層次、事實數據的粒度；事實數據存儲的期限，「過期」的數據的處理方法。
2、維和度量的唯一性和公用性
千萬不要在不同的主題中定義多個表示同一內容的維，尤其對於業務代碼類型的維，如果一個業務代碼形成了多個維表，那麽在元數據維護過程中將困難重重GongWu.Com.Cn 2005-6-20 1:51:55。在整個系統範圍內，要不斷檢視維定義是否唯一，如果有可能，一個維表要盡量被多個主題引用。
3、數據粒度一旦變粗，就要考慮多個主題的融合匯總
在數據倉庫中，我們出於數據組織的規則、業務的要求、性能的要求，都可能對一個主題的事實數據進行匯總，形成粒度較粗的事實數據，但這時候我們往往忘記了粒度變粗的事實數據為最終的用戶提供了更宏觀的數據視圖，這種宏觀的數據視圖當然需要進行跨主題的數據融合才能更加具有應用的價值。
4、不論如何歸並，需要保持數據之間的聯系
在數據倉庫中，不同主題的數據之間的物理約束或許不再存在，但無論這些數據如何變化，要知道必須有一些「鍵」在邏輯上保持著不同數據之間的聯系，這樣就可以保證有聯系的主題數據之間可以進行匯總以支持未知的應用，否則數據倉庫的數據是一潭死水，不可能靈活支持各種應用的。
數據倉庫設計可以自底向上地進行，也就是說從匯總ODS數據入手，逐漸過渡到應用主題上面去（也就是說，ODS裏面的數據主題域與DW中的分析主題完全不是一回事）。我們仍然按部就班地逐項設計，這樣並不是完全限定設計思路和步驟，但可以有效地提醒設計者有哪些事情要做。
第一步：對ODS中的各個主題的事實數據進行時間上的匯總
ODS的事實數據是純細節的交易數據，進入ODS的第一步就是要按照時間維進行匯總，以實現初步的信息沈澱。這種匯總不是只進行一次，而是要制定下來匯總的級別，比如日匯總信息保留3個月，月匯總信息保留2年，年匯總信息長期保存（當然在時間粒度變粗的同時一般都伴隨著其他維粒度的變粗或者舍棄），我們最終一定要定義到何種程度的數據可以在數據倉庫中永久保存為止的地步。
第二步：按照業務邏輯的規則，對數據進行歸並
把ODS中不同主題中的表示相同業務的數據（來自不同的業務系統）進行歸並，例如一般企業的客服系統（Call Center）都受理一部分業務，而這些業務受理與在營業廳或銷售店的受理是一樣的，因此這類數據要歸並到一起。
第三步：把包含細節過多的交易記錄進行拆分
事實上，一個交易記錄所包含的信息內容非常豐富，往往超越了某個人或部門的分析需求，但不同的人有不同的關註點，因此為提高性能起見，我們需要把一個長記錄包含的信息進行分析、分解、匯總。例如在電信企業中，經過二次批價後的通話詳單包含多種信息，經過分析，它包括網絡信息、業務類型信息、時間信息、地理信息、費用信息這樣幾個類別的信息，而每一類信息都由幾個字段來進行記錄。這些不同類別的信息是很少有人都同時關心的，一般來說網管部門關心網絡信息，市場部門關心業務類型信息，而時間信息和地理信息恰是所有部門都需要的。按照這樣的情況，我們把一條話單按照信息內容進行拆分，拆分後進行匯總歸並，以支持不同部門的分析要求。當然，對於數據挖掘應用，可能同時關心所有的信息以發掘不同信息之間的關系，但這種情況一則很少，二則真正的數據挖掘更多的時候依賴於交易細節數據，也就是說，對於專題問題的研究可以從ODS中進行數據的再次處理。
第四步：匯總、再匯總
匯總的問題決不僅僅是為了提高性能而做的事情（當然匯總能夠有效提高性能），但匯總同時意味著更高程度的綜合，在這個過程中，我們會發現與ODS系統設計過程相反，我們從細節走向了宏觀，在ODS中我們初步確定了企業信息模型，對企業信息模型進行初步分解，再分解、再分解，得到了一個個的主題；在數據倉庫中，我們從一個個的主題開始，綜合、再綜合，我們沿著與ODS相反的方向，走向了企業的宏觀數據視圖。事實上在DW設計中，匯總、綜合的終極目標，是要在最後把多個主題匯總成為一個大的主題，而這個主題所包含的維度和度量就是這個企業運行的命脈指標，是企業老板所最為關註的那幾個指標。
