在一般的数据仓库应用系统中根据系统体系结构的不同数据仓库设计的内容和范围不尽相同并且设计方法也不尽相同下面的两幅图示分别表示带有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）都受理一部分业务而这些业务受理与在营业厅或销售店的受理是一样的因此这类数据要归并到一起
第三步把包含细节过多的交易记录进行拆分
事实上一个交易记录所包含的信息内容非常丰富往往超越了某个人或部门的分析需求但不同的人有
