赵丽红的空间

我们一直在努力....

数据仓库之数据模型

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

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

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

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

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

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

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

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

关于第三范式数据仓库,我还没有用过,有实践过或者建议的朋友,欢迎前来交流哦:)

    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

相关博客:


评论


发表评论

关注此文的人们还关注