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