数据仓库中的星型模型与雪花模型
数据仓库模型分析
在数据仓库的建设中，一般都会围绕着星型模型和雪花模型来设计表关系或者结构。下面我们先来理解两种模型的概念。
星型模型图如下：
星型模型：是一种使用关系型数据库实现多维度分析空间的模式，用星型模型可以通过关系数据库来模拟OLAP模式，使用关系数据库+星型模型能够优化存储并且保持数据结构的灵活性。
星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维表的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。
宽表一般是事实表，包含了维度关联的主键和一些度量信息。
维度表则是事实表里面维度的具体信息，使用的时候一般通过Join来组合数据，相对来说对于OLAP的分析比较方便。
OLAP多维度数据模型对数据做预先技术，建成多维度立方体，它需要很大的内存存储所有事实。无论是稠密维还是稀疏维，无论数据库是否包含事实，都必须预留单元。星型模型的基本思想就是保持立方体的多维功能，同事增加了小规模数据存储的灵活性。
雪花模型图如下：
有时候需要对星型模型的维度进行规范化，这时，星型模型就演变成雪花模型。原因如下：
- 我们需要更复杂的维度，例如时间。分析员希望根据周、月、季度等识别模式。
- 维度必须进行规范化。我们不需要冗余的维度表，这只会使数据切片变得更加复杂。这种过程中我们得到的模式称为雪花模型
- 当存在多对多的关联时，无法在关系型数据库中实现，需要使用雪花模式。雪花模式可以存在切片，切块。
雪花模型：当有一个或多个维度没有直接连接在事实表上，而是通过其他维度表连接到事实表时，其图解就像是多个雪花连接在一起，所以称为雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步细化，原有的各维度表可能被扩展成小维度表，形成一些局部的“层次”区域，这些被分解的表都连接到主维度表而不是事实表。
雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要Join的表比较多，所以性能方面并不一定比星型模型高。
星型模型与雪花模型对比：
| 属性 | 星型模型 | 雪花模型 |
|---|---|---|
| 数据总量 | 多 | 少 |
| 可读性 | 容易 | 差 |
| 表个数 | 少 | 多 |
| 查询速度 | 快 | 慢 |
| 冗余度 | 高 | 低 |
| 对事实表的情况 | 增加宽度 | 字段少，冗余低 |
| 扩展性 | 差 | 好 |
应用场景
星型模型的设计方式主要带来的好处是能够提升查询效率，因为生成的事实表已经经过预处理，主要的数据都在事实表里面，所以只要扫描事实表就能够进行大量的查询，而不必进行大量的Join，其次维表数据一般比较少，可以直接放入内存Join提升效率，除此之外，星型模型的事实表可读性比较好，不用关联多个表就能获取大部分核心信息，设计维护相对比较简单。
雪花模型的设计方式是比较符合数据库范式的概念，设计方式比较正规，数据冗余少，但在查询的时候可能需要Join多张表从而导致查询效率下降，此外规范化操作在后期维护比较复杂。
总结
通过上面的对比，我们可以发现数据仓库中星型模型更适用于宽表，通过大量的冗余来提升查询效率，星型模型对OLAP的分析引擎支持比较友好。而雪花模型在关系型数据库中如MySQL、Oracle中尤为常见，尤其像电商的数据库表。在数据仓库中雪花模型的应用场景比较少，但也不是没有，所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优目的。