介绍数据库的雪花模式结构
发布时间：2021-06-25 16:24:44 所属栏目：大数据 来源：互联网
导读：数据库设计包含几个数据建模方法，如概念设计、逻辑设计和物理设计。但是，目前在软件开发者和企业数据仓库（EDW）人员中流行着两个模式类型，即星型模式和雪花模式。 在本文中，我们将详细介绍雪花模式，说明它如何从星形模式进化而来，以及它有什么不同。
|
数据库设计包含几个数据建模方法，如概念设计、逻辑设计和物理设计。但是，目前在软件开发者和企业数据仓库（EDW）人员中流行着两个模式类型，即星型模式和雪花模式。
在本文中，我们将详细介绍雪花模式，说明它如何从星形模式进化而来，以及它有什么不同。
在一定程度上，雪花模式是星形模式的扩展；它与星形模式的区别在于对大维度表（dimension table）的处理。星形模式关注于使用事实表（fact table）的集中设计，这个表将以端到端方式连接不同的维度表。
如图1所示，按照集中式事实表的设计模式，保险销售表（Policy sales）需要连接不同的维度表。如果在汇总保单（sum assured）时想要查询代理人（agent）的策略销售，那么必须“联合（join）”代理人表，才能看到包含渠道（channel）信息的代理表。如果想要查询策略的区域销售额，那么必须“联合”分销区表（branch）。
这里存在什么问题呢？
这里存在两个问题：
1.即使只查询区域级别信息，也需要联合整个分销区表。
2.例如，某一个区域（如“北方”）可能有200至300个分销区。因此，要计算北方的策略数量，我们必须处理全部的300条记录！
连接大维度表存在问题，因为它会增加数据仓库的查询执行时间。大量用户执行相似语句可能会降低数据库性能，而且这个问题正好会导致无法适时使用在线分析处理（OLAP）。
图1:星形模式示意图
问题发生的原因是什么？
如果维度很少，即大多数可能的维度值都不包含数据，并且/或者查询中使用了包含大量属性的维度，那么维度表就会占用大量的数据库空间，这时就适合使用“雪花模式”.
有时候，人们会在现有的事务数据库上添加多维度视图，以帮助完成报告。在这种情况中，描述维度的表已经存在，并且通常是规范化的。因此，这时更容易实现雪花模式。[page]
解决方法
使用雪花模式在星形模式上应用规范化，将超大维度表规范化为多个表。在使用事实表执行汇总查询时，如果想要避免联合大维度表，那么可以将带层次的维度分解为雪花结构。
如果数据仓库模式中有一个事实表与每一个维度建立了“一对多”关系，那么它就适合使用星形模式。
但是，如果一个与其维度建立“多对多”关系的事实表（例如，事实表的许多记录与维度的许多记录完全相同），那么您必须使用雪花模式进行解析，其中桥接表包含事实表中每一行记录的唯一键。
例如，在区域表和区域销售表之间建立联合，避免使用三重联合，就可以轻松获得区域销售或策略数量。
假设有一个零售系统，其中包含一些大维度表，如“客户表”,其中销售表会通过客户ID与客户表建立联合。由于“销售表”和“客户表”存在几百万行记录，因此生成销售报表会对数据库性能产生负面影响。
通常，雪花模式会应用第三范式，以实现独立的维度表。使用小维度表建立汇总表，就可以实现使用雪花模式的目标。
雪花模式的唯一缺点是会增加设计的复杂性，而且增加维度表数量也会增加维护难度。
图1可以修改为雪花结构，具体如“图2:雪花模式结构”所示。
图2:雪花模式结构
总结
●维度表的规范化会增加维度表或子维度表的数量，在查询数据时需要更多的外键联合，因此会降低查询性能。
●雪花模式实现维度表的规范化，有利于节省空间。
●由于维度表与子维度表存在多重联合，所以雪花模式查询比星形模式查询更复杂。
●对于使用数据仓库系统的业务用户而言，使用雪花模式的难度更大，因为他们操作的数据库表比星形模式多。
●创建汇总表，并将它（们）与相应的维度表建立联合，可以减少执行时间，提高查询性能。
 （编辑：我爱制作网_潮州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330565号