A Cooly Weblog

             ::  ::  ::  ::  :: 管理

          什么是ODS

          Posted on 2006-10-22 22:00 acooly 閱讀(1744) 評論(0)  編輯  收藏 所屬分類: 技術名詞解釋
          ODS(Operational Data Store)是數據倉庫體系結構中的一個可選部分,ODS具備數據倉庫的部分特征和OLTP系統的部分特征,它是“面向主題的、集成的、當前或接近當前的、不斷變化的”數據。
             一般在帶有ODS的系統體系結構中,ODS都設計為如下幾個作用:
            1) 在業務系統和數據倉庫之間形成一個隔離層。
             一般的數據倉庫應用系統都具有非常復雜的數據來源,這些數據存放在不同的地理位置、不同的數據庫、不同的應用之中,從這些業務系統對數據進行抽取并不是 一件容易的事。因此,ODS用于存放從業務系統直接抽取出來的數據,這些數據從數據結構、數據之間的邏輯關系上都與業務系統基本保持一致,因此在抽取過程 中極大降低了數據轉化的復雜性,而主要關注數據抽取的接口、數據量大小、抽取方式等方面的問題。
            2) 轉移一部分業務系統細節查詢的功能
             在數據倉庫建立之前,大量的報表、分析是由業務系統直接支持的,在一些比較復雜的報表生成過程中,對業務系統的運行產生相當大的壓力。ODS的數據從粒 度、組織方式等各個方面都保持了與業務系統的一致,那么原來由業務系統產生的報表、細節數據的查詢自然能夠從ODS中進行,從而降低業務系統的查詢壓力。
            3) 完成數據倉庫中不能完成的一些功能。
             一般來說,帶有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部分的數據庫物理實現,設計數據庫參數、操作系統參數、數據存儲設計之外,有關數據抽取接口等問題必須清晰定義。
          主站蜘蛛池模板: 天水市| 博野县| 无为县| 体育| 交口县| 阿克陶县| 白城市| 临夏市| 封丘县| 西城区| 区。| 塔河县| 大新县| 锡林浩特市| 秀山| 蒙阴县| 象州县| 陆川县| 紫阳县| 苗栗市| 囊谦县| 琼海市| 罗源县| 浮山县| 汪清县| 大厂| 岳普湖县| 昭平县| 棋牌| 常宁市| 五原县| 依兰县| 宜君县| 什邡市| 大洼县| 阿坝县| 巴里| 新民市| 连平县| 务川| 台北市|