ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 数据仓库之数据模型

数据仓库之数据模型

原创 Linux操作系统 作者:ceo_lxy 时间:2011-02-17 09:29:30 0 删除 编辑

传统的OLTP系统,是面向应用的,我们总是按照应用的需求来设计和建立。而数据仓库则是面向主题的。那么,什么是面向应用,什么又是面向主题呢?举个例子来说吧,在一个集团企业中,其下属各个分公司可能各自运行一套系统,相互之间没有什么关系,各系统之间的数据存在冗余。比如每个系统都会有客户的数据。当针对集团建立其数据仓库时,要把各分公司系统中的数据转换到数据仓库中来。从集团的角度来看,其数据模型不再面向个别应用,而是面向整个集团的主题。ITPUB个人空间
@F fNh9z

数据仓库是一个比较复杂的“世界”,它涉及了很多不同的方面,所以很容易会纠缠在具体细节中并很快迷失方向。因此,在数据仓库中围绕主题建立好数据模型是非常重要的。

建立数据模型的第一步是定义整合范围。整合范围就是描述数据模型中包含什么和不包含什么。整合范围是十分重要的,因为没有它数据模型便会无休止地建立下去,甚至可能包含宇宙级的数据。当这种现象发生时,数据模型的建立永远都不会停止。所以在设计数据仓库模型时还需要划分清楚整合范围的边界

 

数据仓库建立在企业的数据基础之上,大多数机构都有大量的数据。这样,设计人员还需对粒状型数据和概括型数据或聚合型数据有明确的区别。粒状型数据是指体现最底层意义的数据。一个人的姓名是粒状数据,生日也是粒状数据,薪水在一个时间段内可以看成是粒状数据。概括型数据则是诸如一天的销售量、一个月的收入、一年里企业的员工数、一个季度内的费用中和之类的数据

 

我在工作中用的比较多的数据仓库模型是星型模式,星型模式是一种多维的数据关系,由一个事实表和一组维表。每个维表都有一个维作为主键,所有这些维则组成了事实表的主键,换言之,事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实,它们一般都是数值或其他可以计算的数据,而维大都是文字、时间等类型的数据

 

在实际应用中,星型模式数据仓库显著提高了分析报表查询的速度,星型模式之所以速度快,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。比如,按照产品的规格、生产厂家、包装进行预先的销量统计。因此,在星型模式设计的数据仓库中,作报表的速度虽然很快,但是由于存在大量的预处理,其建模过程相对来说比较慢。当业务问题发生变化,原来的维度不能满足要求时,需要增加新的维。由于事实表的主键由所有维表的主键组成,这种维度的变化将是非常复杂、非常耗时的。星型模式另外一个显著的缺点是数据的冗余量很大

 

因此,不难看出,星型模式的数据仓库比较适合于预先定义好的问题,比如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高的场合

 

另外,数据仓库建模,还有一种方式,那就是第三范式。想必熟悉关系型数据库的朋友们都不会陌生吧。关于数据仓库的第三范式建模,据说这种数据仓库模型具有交互性、可扩展性、数据挖掘、知识探索等优点,不过可能查询速度上会比星型模式要差一些了。这也正是鱼和熊掌不可兼得吧。在实际工作中,我们可以根据实际的需要来选择使用哪种数据仓库模型。

 

 

 

 

在许多银行中实施数据仓库、ODS、报表系统时,都会涉及到建立模型的要求。但对模型的认识却不尽相同。

 

 

 

模型应该是对一个系统的抽象,同时具有内部和外部两方面的特征。银行中任何一个工作过程,都可以定义出相应的模型,而非数据仓库、数据集市的专利。

 

在银行的管理信息类系统中,经常谈到按“主题”建立模型,而对于主题,我认为存在着两种类型,一类是业务主题,与之相应的是反映业务处理的业务模型,另一类是分析主题,与之相应的是统计分析模型。

 

业务主题中的业务模型,反映银行是如何进行日常业务处理的,按照正确的企业信息化的步骤,应该是首先确定出银行整体的业务信息模型,然后才会划分出不同的业务主题,通过开发不同的业务处理系统加以实现,在这样前提下实现的各种业务处理系统,才会比较高效的相互配合,形成银行整体的业务处理的体系。我们看到的现实是,许多的银行虽然已经运行着许许多多的业务处理系统,但这些系统的建设并不是基于整体信息模型的规划,各个业务系统自身也未必有非常清晰的业务模型,这方面的情况各个银行差异很大,参差不齐。因此,在建立管理信息系统的过程中,特别是在建立企业“数据仓库”的过程中(我对数据仓库的定义参见《按需选用“数据仓库”》),首先需要重现企业的业务模型,按照业务模型来组织数据,反映银行业务处理的现实状态。数据仓库应按业务主题建立业务模型。

 

分析主题是根据银行管理决策的特定目的而建立的,并随着银行管理的实际需要而不断发展变化的,分析主题中都需要相应的分析模型,基于银行现实的业务数据计算得到所需要的指标数据,特别是在特定的数据集市当中,所实现的就是这种分析模型。

 

分析主题与业务主题有着对应关系,当一个分析主题局限在有个业务领域之内时,分析主题可以包含在业务主题之内,例如会计系统可以直接产生相应的会计统计报表。当分析主题跨越多个业务主题时,例如1104报表,那么就必须要在业务主题之外单独建立分析主题及其分析模型,利用不同的业务主题的数据计算出所需的指标。在我的《管理信息系统主要模块》一文中,统一业务视图的实现,就应该是基于业务主题的,建立业务模型组织数据,而统计分析结果的实现,就应该是基于分析主题的,建立相应的分析模型计算出结果指标。分析模型的特点是,首先有模型,然后根据模型的需要提出数据要求,而业务模型的特点是,基于现有业务的现实情况抽象出模型,反映业务现实,所以在建立ODS、企业“数据仓库”的时候,不应盲目追求所谓先进、深奥的分析模型,而是应该首先对银行自身现有的业务模型有一个清晰的认识,顶多再考虑一些将来可能的业务发展方向,务必要保证银行现有的各种业务数据可以被业务模型所容纳。否则,如果业务模型不能兼容银行自身已有的各项业务,那么这个模型就是不适合该银行的,除非这家银行完全没有自己的业务特色。

 

 

 

在建立银行管理信息系统的实践中,这两类主题、模型在整个管理信息系统的架构中的定位是不同的,是不应该混淆的。例如,某银行引入国外的分析模型建立数据仓库系统,结果不能满足不断增加的其他分析主题的需要。因此,在银行管理信息系统中,应该在数据仓库和数据集市中分别建立相应的业务模型和分析模型,按照各自的定位体现自己的价值。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12122734/viewspace-687385/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-06-02

  • 博文量
    519
  • 访问量
    490386