数据库设计包含几个数据建模方法，如概念设计、逻辑设计和物理设计。但是，目前在软件开发者和企业数据仓库（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:雪花模式结构

    总结

    ●维度表的规范化会增加维度表或子维度表的数量，在查询数据时需要更多的外键联合，因此会降低查询性能。

    ●雪花模式实现维度表的规范化，有利于节省空间。

    ●由于维度表与子维度表存在多重联合，所以雪花模式查询比星形模式查询更复杂。

    ●对于使用数据仓库系统的业务用户而言，使用雪花模式的难度更大，因为他们操作的数据库表比星形模式多。

    ●创建汇总表，并将它（们）与相应的维度表建立联合，可以减少执行时间，提高查询性能。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。