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

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

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

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

　　这里存在什么问题呢？

　　这里存在两个问题：

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

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

　　图1：星形模式示意图

　　问题发生的原因是什么？

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

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

　　解决方法

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

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

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

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

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

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

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

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

　　图2：雪花模式结构

　　总结

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