Oracle数据仓库设计指南
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Oracle数据仓库设计指南
在一般的数据仓库应用系统中,根据系统体系结构的不同,数据仓库设计的内容和范围不尽相同,并且设计方法也不尽相同,下面的两幅图示分别表示带有ODS的数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构。本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同,并且重点介绍带有ODS的体系结构中数据仓库的设计方法。
在数据仓库的设计指导思想中,数据仓库的概念定义是非常重要的,数据仓库概念规定了数据仓库所具有的几个基本特性,这些特性也正是对数据仓库设计结果进行检验的重要依据。
根据Bill.Inmon的定义,“数据仓库是面向主题的、集成的、稳定的、随时间变化的,主要用于决策支持的数据库系统”。
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中,因数据来自于多个系统,数据主题划分时虽然对数据概念进行了一定程度上的归并,但具体的业务代码所形成的各个维、以及维成员等还需要进一步进行归并,把概念统一的维定义成一个维,不允许同一个维存在不同的实体表示(象不同的业务系统中一样)。
第五步:物理实现
定义每个主题的数据抽取周期、抽取时间、抽取方式、数据接口,抽取流程和规则。