解析数据库的雪花模式结构

日期: 2012-10-16 作者:Mohit Tayal 来源:TechTarget中国 英文

数据库设计包含几个数据建模方法,如概念设计、逻辑设计和物理设计。但是,目前在软件开发者和企业数据仓库(EDW)人员中流行着两个模式类型,即星型模式和雪花模式。

  在本文中,我们将详细介绍雪花模式,说明它如何从星形模式进化而来,以及它有什么不同。

  在一定程度上,雪花模式是星形模式的扩展;它与星形模式的区别在于对大维度表(dimension table)的处理。星形模式关注于使用事实表(fact table)的集中设计,这个表将以端到端方式连接不同的维度表。

  如图1所示,按照集中式事实表的设计模式,保险销售表(Policy sales)需要连接不同的维度表。如果在汇总保单(sum assured)时想要查询代理人(agent)的策略销售,那么必须“联合(join)”代理人表,才能看到包含渠道(channel)信息的代理表。如果想要查询策略的区域销售额,那么必须“联合”分销区表(branch)。

  这里存在什么问题呢?

  这里存在两个问题:

  1. 即使只查询区域级别信息,也需要联合整个分销区表。
  2. 例如,某一个区域(如“北方”)可能有200至300个分销区。因此,要计算北方的策略数量,我们必须处理全部的300条记录!

  连接大维度表存在问题,因为它会增加数据仓库的查询执行时间。大量用户执行相似语句可能会降低数据库性能,而且这个问题正好会导致无法适时使用在线分析处理(OLAP)。

图1:星形模式示意图

  图1:星形模式示意图

  问题发生的原因是什么?

  如果维度很少,即大多数可能的维度值都不包含数据,并且/或者查询中使用了包含大量属性的维度,那么维度表就会占用大量的数据库空间,这时就适合使用“雪花模式”。

  有时候,人们会在现有的事务数据库上添加多维度视图,以帮助完成报告。在这种情况中,描述维度的表已经存在,并且通常是规范化的。因此,这时更容易实现雪花模式。

  解决方法

  使用雪花模式在星形模式上应用规范化,将超大维度表规范化为多个表。在使用事实表执行汇总查询时,如果想要避免联合大维度表,那么可以将带层次的维度分解为雪花结构。

  如果数据仓库模式中有一个事实表与每一个维度建立了“一对多”关系,那么它就适合使用星形模式。

  但是,如果一个与其维度建立“多对多”关系的事实表(例如,事实表的许多记录与维度的许多记录完全相同),那么您必须使用雪花模式进行解析,其中桥接表包含事实表中每一行记录的唯一键。

  例如,在区域表和区域销售表之间建立联合,避免使用三重联合,就可以轻松获得区域销售或策略数量。

  假设有一个零售系统,其中包含一些大维度表,如“客户表”,其中销售表会通过客户ID与客户表建立联合。由于“销售表”和“客户表”存在几百万行记录,因此生成销售报表会对数据库性能产生负面影响。

  通常,雪花模式会应用第三范式,以实现独立的维度表。使用小维度表建立汇总表,就可以实现使用雪花模式的目标。

  雪花模式的唯一缺点是会增加设计的复杂性,而且增加维度表数量也会增加维护难度。

  图1可以修改为雪花结构,具体如“图2:雪花模式结构”所示。

图2:雪花模式结构

  图2:雪花模式结构

  总结

  • 维度表的规范化会增加维度表或子维度表的数量,在查询数据时需要更多的外键联合,因此会降低查询性能。
  • 雪花模式实现维度表的规范化,有利于节省空间。
  • 由于维度表与子维度表存在多重联合,所以雪花模式查询比星形模式查询更复杂。
  • 对于使用数据仓库系统的业务用户而言,使用雪花模式的难度更大,因为他们操作的数据库表比星形模式多。
  • 创建汇总表,并将它(们)与相应的维度表建立联合,可以减少执行时间,提高查询性能。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐