pengbin518518的个人博客分享 http://blog.sciencenet.cn/u/pengbin518518

博文

研究 Data Warehouse

已有 3950 次阅读 2012-8-9 16:40 |个人分类:学习笔记|系统分类:科研笔记| 雪花, 数据仓库, 多维数据模型, 星型, 外键约束

 

本月我努力学习数据仓库,致力于更好地为应急主题数据仓库与应急智能技术学习研究服务。在学习过程中,边学边遇到问题,边解决问题。下面就几个感悟较深的问题拙笔展开。

事务型数据处理中需要作数据库设计,而在分析型数据处理中则需作数据仓库设计,这两者在原理上是一致的。因此,数据库设计中的很多设计思想与方法都可在数据仓库中得到应用。但是由于事务型与分析型的数据处理的不一致,因此两者在设计中的很多方面也存在着差别。对数据库和数据仓库作比较:

 

 

数据库

数据仓库

系统设计的目标

面向事务型处理

分析型处理,为了支持决策分析

面向的需求

面向应用

在决策分析时,决策者分析问题的角度多种多样,所以数据处理流和信息流不固定,甚至决策者对所要进行的分析处理都不太明了,数据的分析处理的需求更灵活。这就决定了在数据仓库系统设计时,不可能从用户需求出发来进行设计

数据来源

从企业外部通过输入得到,所以系统设计时就是设计如何与外部对话得到数据,如何存储这些数据,它关心的是数据的安全性和完整性

大部分是从企业内部的数据库系统得到,还有一部分是企业外部的非结构化数据,这些数据都是安全可靠且正确有效的,关心的是数据的一致性

数据的处理类型

数据库系统支持的是事务型处理,主要指数据的增、删、改、查等等,系统设计时都是针对某一具体应用

数据仓库是面向分析的,它的数据处理大都是对数据的复杂查询,所以在设计时考虑的是如何更好地面向主题

数据的组织方法及系统设计方法

以客体(Object)为起始点,即以客观操作需求为设计依据,

一般采用系统生命周期法(SDLC

以主题为起始点,进行相关数据的设计,最终建立起一个面向主题的分析型环境,

采用与SDLC相反的CLDS法。(SDLC起始于需求,CLDS起始于数据。)

 

数据仓库的设计过程中遵循的面向主题原则、数据驱动原则和原型法设计原则是依据其特点的,即面向主题的、集成的、不可更新的、随时间的变化而不断变化的,他们决定了数据仓库的系统设计不能采用同开发传统的OLTP数据库一样的设计方法。

数据仓库的设计是一个逐步求精的过程,用户的需求是在设计过程中不断细化明确的。同时,数据仓库系统的开发也是一个经过不断循环、反馈而使系统不断增长与完善的过程。在数据仓库开发的整个过程中,自始至终要求决策人员和开发者的共同参与和密切合作,不做或尽量少做无效工作或重复工作。

 

初学数据仓库是我以为数据仓库就是基于多维数据模型构建,用于OLAP的数据平台,通过深入学习,了解到数据仓库的应用可能远不止这些。但不得不承认多维数据模型是数据仓库的一大特点,也是数据仓库应用和实现的一个重要的方面,通过在数据的组织和存储上的优化,使其更适用于分析型的数据查询和获取。

通过多维数据模型的数据展示、查询和获取就是其作用的展现,但其真的作用的实现在于,通过数据仓库可以根据不同的数据需求建立起各类多维模型,并组成数据集市开放给不同的用户群体使用,也就是根据需求定制的各类数据商品摆放在数据集市中供不同的数据消费者进行采购。

 

深入学习,首先了解两个概念:事实表和维表。事实表是用来记录具体事件的,包含了每个事件的具体要素,以及具体发生的事情;维表则是对事实表中事件的要素的描述信息。比如一个事件会包含时间、地点、人物、事件,事实表记录了整个事件的信息,但对时间、地点和人物等要素只记录了一些关键标记,比如事件的主角叫“Michael”,那么Michael到底“长什么样”,就需要到相应的维表里面去查询“Michael”的具体描述信息了。基于事实表和维表就可以构建出多种多维模型,主要是星形模型和雪花模型。

 

1.星型架构:

2.雪花型架构:

星型模型和雪花模型,星型模型维表一般都很小,甚至可以放在高速缓存中,模式比较直观,不用过多考虑正规化因素,设计维护较为简单,但是会产生冗余数据。雪花模型数据冗余少,在一定程度上减少了存储空间;规范化的结构更容易更新和维护,但是雪花模式也存在不少缺点:雪花模式比较复杂,用户不容易理解而且设计及后期维护复杂;浏览内容相对困难;额外的连接将使查询性能下降。

在网上看到两个路人的发表,比较好:

路人甲说:在实际数据仓库应用中,可以采取上述两种模型的混合体:如:中间层使用雪花结构以降低数据冗余度,数据集市部分采用星型以方便数据提取及和分析。

路人乙说:在数据仓库中,通常不推荐雪花化。因为在数据仓库中,查询性能相对OLTP系统来说更加被重视,而雪花模式会降低数据仓库系统的性能。

 

最后,特别要提的是一个建设数据库的外键(Foreign Key)使用问题。

一个形象的例子使我从玄乎的概念中走出来:主表、从表和外键的定义:我把我的笔记本借给你用,可以把“我”当作是主表、“笔记本”当作外键、“你”当作从表,就是说“你”在使用(引用)“我”的“笔记本”;外键的作用就是:现在你想把我的笔记本卖了扔了送人(增加更新删除等),得看看我允许不允许,我想搬家走人,你不把笔记本还给我,我不能搬;建键原则:借之前首先咱得说好了,我只有这么一台笔记本,你也最好是也只借了我这台笔记本,避免你也借了别人的笔记本,不知道哪个是我的了。事件触发:我说你赶紧把笔记本还给我,你可以选择还给我,可以选择不搭理我等。总而言之,由于这笔记本,“你”和“我”关联起来,这台笔记本怎么样,不能一个人说了算。

随后,“图说东溪”数据库建设表与表之间有没有必要使用外键关联的问题扑面而来,关于这个问题,在网上看到几个路人的发表,比较有参考价值:

路人甲问:在做项目的时候,经常要建很多的表,有时候就要用到外键关联,用的时候就方便,但是有时候要改动表就很麻烦,因为有了外键就不可以随便动表了。到底是建外键好呢,还是不建好?

路人乙说:我觉得要保证数据的完整性,有引用关系的表与表之间建物理外键是非常重要的,而且一旦建了外键,以后维护系统时对这些表之间的关系也会比较清楚。可我们公司做的系统都不建外键,我提了多次都不管用,一个"建了外键不便于导数据"的理由就把我给堵回去了。我该如何说服他们使用外键?

路人丙说:当然是在不需要建的时候最好不要外键咯,用的好的话省事,用的不好的话 呵呵,整自己!做项目时用户的需求是不断的,因此表的改动也是挺频繁的,只要自己将整个业务的逻辑思维理清了,将关联到多张表的操作放在一个事务中去处理,效率还更高些。如果必须要建外键,那就没有办法了! 话说,建外键后,改动数据确实挺麻烦的!
   
路人丁说:我也觉得不引入外键好,虽然会增加额外的程序来检测外键约束,但一旦加了外键不单单是导入数据麻烦,特别是项目大了,牵一发而动全身会很难受。而且也会给测试带来很多不便,我以前做的项目都不用外键约束的。

通过学习,我得出总结:

1.要看看具体业务需求。不是任何情况都要用外键的。用了外键可以保证数据的一致性、完整性, 维护系统时有好处,但同时增加了数据库的附和,增加了项目过程中导入、改动数据的麻烦。
     2.
在大型系统中(性能要求不高,安全要求高),使用外键;在大型系统中(性能要求高,安全自己控制),不用外键;小系统随便,最好用外键。
     3.
用外键要适当,不能过分追求。
     4.
不用外键而用程序控制数据一致性和完整性时,应该写一层来保证,然后个个应用通过这个层来访问数据库。

   5.至于改动表时很麻烦的问题,其实也可以解决。可以先把外键约束disable掉,然后进行表的改动操作,操作完了再enable回来就可以了。
alter table tt(
表名) disable novalidate constraint pk_tt 约束名称);
alter table tt enable novalidate constraint pk_tt;

   
星型架构
雪花型架构 


https://wap.sciencenet.cn/blog-743259-600583.html

上一篇:连环犯罪的时空预测方法
下一篇:应急制图
收藏 IP: 220.160.68.*| 热度|

0

该博文允许注册用户评论 请点击登录 评论 (0 个评论)

数据加载中...

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2024-4-13 17:35

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部