熱點推薦:
您现在的位置: 電腦知識網 >> 操作系統 >> Windows系統管理 >> 正文

數據倉庫設計指南

2013-11-11 21:36:55  來源: Windows系統管理 

   在一般的數據倉庫應用系統中根據系統體系結構的不同數據倉庫設計的內容和范圍不盡相同並且設計方法也不盡相同下面的兩幅圖示分別表示帶有ODS的數據倉庫應用系統體系結構和不帶ODS的數據倉庫應用系統體系結構本文將說明兩個體系結構上的差異以及這種差異造成的設計方法的不同並且重點介紹帶有ODS的體系結構中數據倉庫的設計方法
   在數據倉庫的設計指導思想中數據倉庫的概念定義是非常重要的數據倉庫概念規定了數據倉庫所具有的幾個基本特性這些特性也正是對數據倉庫設計結果進行檢驗的重要依據
   根據BillInmon的定義數據倉庫是面向主題的集成的穩定的隨時間變化的主要用於決策支持的數據庫系統
   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
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.