oracle数据仓库设计指南

标签: oracle 数据仓库 设计 | 发表时间:2015-04-04 23:47 | 作者:czmmiao
出处:http://www.iteye.com

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部分的数据库物理实现,设计数据库参数、操作系统参数、数据存储设计之外,有关数据抽取接口等问题必须清晰定义。

DW 设计指南
    尽管我们看到过很多关于“不考虑应用,先建立数据平台”的说法,但建立一个“万能的”东西是不可能的,所以数据仓库的设计必须参照应用范围、应用类型,例如要考虑到系统用于报表、OLAP、数据挖掘的哪些模型等等,不同的应用对数据仓库的设计有不同的要求。
    数据仓库是面向主题的、集成的、稳定的、随时间变化的数据,数据仓库的这几个特征的含义在这里不具体多介绍,但本人要说明如何实现这些特性。
    在数据仓库的设计中时刻不能忘记的几个问题列举如下:
    1 、数据粒度和数据组织
    在数据仓库的每个主题,都必须知道这个主题所限定的维的层次、事实数据的粒度;事实数据存储的期限,“过期”的数据的处理方法。
     2 、维和度量的唯一性和公用性
    千万不要在不同的主题中定义多个表示同一内容的维,尤其对于业务代码类型的维,如果一个业务代码形成了多个维表,那么在元数据维护过程中将困难重重。在整个系统范围内,要不断检视维定义是否唯一,如果有可能,一个维表要尽量被多个主题引用。
    3 、数据粒度一旦变粗,就要考虑多个主题的融合汇总
    在数据仓库中,我们出于数据组织的规则、业务的要求、性能的要求,都可能对一个主题的事实数据进行汇总,形成粒度较粗的事实数据,但这时候我们往往忘记了粒度变粗的事实数据为最终的用户提供了更宏观的数据视图,这种宏观的数据视图当然需要进行跨主题的数据融合才能更加具有应用的价值。
    4 、不论如何归并,需要保持数据之间的联系
    在数据仓库中,不同主题的数据之间的物理约束或许不再存在,但无论这些数据如何变化,要知道必须有一些“键”在逻辑上保持着不同数据之间的联系,这样就可以保证有联系的主题数据之间可以进行汇总以支持未知的应用,否则数据仓库的数据是一潭死水,不可能灵活支持各种应用的。
    数据仓库设计可以自底向上地进行,也就是说从汇总ODS数据入手,逐渐过渡到应用主题上面去(也就是说,ODS里面的数据主题域与DW中的分析主题完全不是一回事)。我们仍然按部就班地逐项设计,这样并不是完全限定设计思路和步骤,但可以有效地提醒设计者有哪些事情要做。
     第一步:对 ODS 中的各个主题的事实数据进行时间上的汇总
    ODS的事实数据是纯细节的交易数据,进入ODS的第一步就是要按照时间维进行汇总,以实现初步的信息沉淀。这种汇总不是只进行一次,而是要制定下来汇总的级别,比如日汇总信息保留3个月,月汇总信息保留2年,年汇总信息长期保存(当然在时间粒度变粗的同时一般都伴随着其他维粒度的变粗或者舍弃),我们最终一定要定义到何种程度的数据可以在数据仓库中永久保存为止的地步。
     第二步:按照业务逻辑的规则,对数据进行归并
    把ODS中不同主题中的表示相同业务的数据(来自不同的业务系统)进行归并,例如一般企业的客服系统(Call Center)都受理一部分业务,而这些业务受理与在营业厅或销售店的受理是一样的,因此这类数据要归并到一起。
     第三步:把包含细节过多的交易记录进行拆分
    事 实上,一个交易记录所包含的信息内容非常丰富,往往超越了某个人或部门的分析需求,但不同的人有不同的关注点,因此为提高性能起见,我们需要把一个长记录 包含的信息进行分析、分解、汇总。例如在电信企业中,经过二次批价后的通话详单包含多种信息,经过分析,它包括网络信息、业务类型信息、时间信息、地理信 息、费用信息这样几个类别的信息,而每一类信息都由几个字段来进行记录。这些不同类别的信息是很少有人都同时关心的,一般来说网管部门关心网络信息,市场 部门关心业务类型信息,而时间信息和地理信息恰是所有部门都需要的。按照这样的情况,我们把一条话单按照信息内容进行拆分,拆分后进行汇总归并,以支持不 同部门的分析要求。当然,对于数据挖掘应用,可能同时关心所有的信息以发掘不同信息之间的关系,但这种情况一则很少,二则真正的数据挖掘更多的时候依赖于 交易细节数据,也就是说,对于专题问题的研究可以从ODS中进行数据的再次处理。
     第四步:汇总、再汇总
    汇总的问题决不仅仅是为了提高性能而做的事情(当然汇总能够有效提高性能),但汇总同时意味着更高程度的综合,在这个过程中,我们会发现与ODS系统设计过程相反,我们从细节走向了宏观,在ODS中我们初步确定了企业信息模型,对企业信息模型进行初步分解,再分解、再分解,得到了一个个的主题;在数据仓库中,我们从一个个的主题开始,综合、再综合,我们沿着与ODS相反的方向,走向了企业的宏观数据视图。事实上在DW设计中,汇总、综合的终极目标,是要在最后把多个主题汇总成为一个大的主题,而这个主题所包含的维度和度量就是这个企业运行的命脉指标,是企业老板所最为关注的那几个指标。

 

参考至:《oracle数据仓库设计指南》

如意错误,欢迎指正

邮箱:czmcj@163.com



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [oracle 数据仓库 设计] 推荐:

oracle数据仓库设计指南

- - 数据库 - ITeye博客
ODS(Operational Data Store)是数据仓库体系结构中的一个可选部分,ODS具备数据仓库的部分特征和OLTP系统的部分特征,它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据.     一般在带有ODS的系统体系结构中,ODS都设计为如下几个作用:. 1 )    在业务系统和数据仓库之间形成一个隔离层.

数据仓库的设计与开发

- - 数据库 - ITeye博客
     数据仓库系统的设计与开发. 1)       收集和分析业务需求.   用户需求,管理人员需求. 2)       建立数据模型和数据仓库的物理设计.   概念模型,逻辑模型,物理模型. 3)       定义数据源. 数据源面向应用,不是面向主题,而且数据源之间存在多个不一致的情况,所以必须在已有的系统中定义记录系统(内容正确,在多个数据源间起决定作用的操作型数据源).

数据仓库的架构与设计

- - CSDN博客推荐文章
公司之前的数据都是直接传到Hdfs上进行操作,没有一个数据仓库,趁着最近空出几台服务器,搭了个简陋的数据仓库,这里记录一下数据仓库的一些知识. 数据仓库多维数据模型的设计. 数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合,用于对管理决策过程的支持. 这个定义的确官方,但是却指出了数据仓库的四个特点.

【漫谈数据仓库】 如何优雅地设计数据分层

- -
本文主要讲解数据仓库的一个重要环节:如何设计数据分层. 其它关于数据仓库的内容可参考之前的文章. 本文对数据分层的讨论适合下面一些场景,超过该范围场景or数据仓库经验丰富的大神就不必浪费时间看了. 数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务. 数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得.

数据仓库

- Ran - Linux@SOHU
翻译:马少兵、曾怀东、朱翊然、林业. 尽管服务器存储、处理能力得到有效的提高,以及服务器价格的降低,让人们能够负担起大量的服务器,但是商业软件应用和监控工具快速的增加,还是使得人们被大量的数据所困扰. 在数据仓库领域中的许多系统管理员、应用开发者,以及初级数据库管理员发现,他们正在处理“海量数据”-不管你准备与否-都会有好多不熟悉的术语,概念或工具.

漫谈数据仓库之拉链表(原理、设计以及在Hive中的实现)

- - IT瘾-bigdata
本文将会谈一谈在数据仓库中拉链表相关的内容,包括它的原理、设计、以及在我们大数据场景下的实现方式. 先分享一下拉链表的用途、什么是拉链表. 通过一些小的使用场景来对拉链表做近一步的阐释,以及拉链表和常用的切片表的区别. 举一个具体的应用场景,来设计并实现一份拉链表,最后并通过一些例子说明如何使用我们设计的这张表(因为现在Hive的大规模使用, 我们会以Hive场景下的设计为例).

数据仓库概念

- - 互联网 - ITeye博客
数据仓库:是一个数据库环境,它提供用户用于决策支持的当前和历史数据,这些数据在传统的数据库中不方便得到. 特点:面向主题,集成的,相对稳定的,反应历史变化的. 组成:数据仓库的数据库,数据抽取工具,元数据,访问工具,数据集市,数据仓库管理,信息发布系统. 数据挖掘:就是从大量数据中获取有效的,新颖的,潜在有用的,最终可理解的模式的过程.

大数据仓库-kudu

- - 数据库 - ITeye博客
数据仓库里面存储引擎是非常重要的,存储引擎的好坏,基本决定了整个数仓的基础. cloudera公司最近发布了一个kudu存储引擎. 按照cloudera的想法,kudu的出现是为了解决,hbase,parquet不能兼顾分析和更新的需求,所以需要一个新的存储引擎可以同时支持高吞吐的分析应用以及少量更新的应用.

ORACLE数据库优化设计方案

- - CSDN博客推荐文章
本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手,分析ORACLE的系统结构和工作机理,从九个不同方面较全面地总结了ORACLE数据库的优化调整方案. 关键词 ORACLE数据库 环境调整 优化设计 方案. 对于ORACLE数据库的数据存取,主要有四个不同的调整级别,第一级调整是操作系统级包括硬件平台, 第二级调整是ORACLE RDBMS级的调整,.

[原]数据仓库元数据管理

- - oycn2010的专栏
元数据管理, 简单的做就是EXCEL结合版本管理等传统工具管理, 专业点就用专门的元数据管理工具;. 数据字典--> 数据知识库. 业务元数据,技术元数据,管理元数据. 参照:SAP元数据管理平台:按业务(角色)分类,按技术类型分类(特征,关键值,DSO,InfoCube),数据流程图. 按照传统的定义,元数据(Metadata)是关于数据的数据.