数据仓库中的星型模型与雪花模型

在这里插入图片描述

数据仓库模型分析

在数据仓库的建设中,一般都会围绕着星型模型和雪花模型来设计表关系或者结构。下面我们先来理解两种模型的概念。

星型模型图如下:

在这里插入图片描述
星型模型:是一种使用关系型数据库实现多维度分析空间的模式,用星型模型可以通过关系数据库来模拟OLAP模式,使用关系数据库+星型模型能够优化存储并且保持数据结构的灵活性。
星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键,所有这些维表的主键组合成事实表的主键。强调的是对维度进行预处理,将多个维度集合到一个事实表,形成一个宽表。
宽表一般是事实表,包含了维度关联的主键和一些度量信息。
维度表则是事实表里面维度的具体信息,使用的时候一般通过Join来组合数据,相对来说对于OLAP的分析比较方便。

OLAP多维度数据模型对数据做预先技术,建成多维度立方体,它需要很大的内存存储所有事实。无论是稠密维还是稀疏维,无论数据库是否包含事实,都必须预留单元。星型模型的基本思想就是保持立方体的多维功能,同事增加了小规模数据存储的灵活性。

雪花模型图如下:

有时候需要对星型模型的维度进行规范化,这时,星型模型就演变成雪花模型。原因如下:
  1. 我们需要更复杂的维度,例如时间。分析员希望根据周、月、季度等识别模式。
  2. 维度必须进行规范化。我们不需要冗余的维度表,这只会使数据切片变得更加复杂。这种过程中我们得到的模式称为雪花模型
  3. 当存在多对多的关联时,无法在关系型数据库中实现,需要使用雪花模式雪花模式可以存在切片,切块。
    在这里插入图片描述
    雪花模型:当有一个或多个维度没有直接连接在事实表上,而是通过其他维度表连接到事实表时,其图解就像是多个雪花连接在一起,所以称为雪花模型雪花模型是对星型模型的扩展。它对星型模型的维表进一步细化,原有的各维度表可能被扩展成小维度表,形成一些局部的“层次”区域,这些被分解的表都连接到主维度表而不是事实表。
    雪花模型更加符合数据库范式,减少数据冗余,但是在分析数据的时候,操作比较复杂,需要Join的表比较多,所以性能方面并不一定比星型模型高。

星型模型与雪花模型对比:

属性星型模型雪花模型
数据总量
可读性容易
表个数
查询速度
冗余度
对事实表的情况增加宽度字段少,冗余低
扩展性

应用场景

星型模型的设计方式主要带来的好处是能够提升查询效率,因为生成的事实表已经经过预处理,主要的数据都在事实表里面,所以只要扫描事实表就能够进行大量的查询,而不必进行大量的Join,其次维表数据一般比较少,可以直接放入内存Join提升效率,除此之外,星型模型的事实表可读性比较好,不用关联多个表就能获取大部分核心信息,设计维护相对比较简单。
雪花模型的设计方式是比较符合数据库范式的概念,设计方式比较正规,数据冗余少,但在查询的时候可能需要Join多张表从而导致查询效率下降,此外规范化操作在后期维护比较复杂。

总结

通过上面的对比,我们可以发现数据仓库中星型模型更适用于宽表,通过大量的冗余来提升查询效率,星型模型对OLAP的分析引擎支持比较友好。而雪花模型在关系型数据库中如MySQL、Oracle中尤为常见,尤其像电商的数据库表。在数据仓库中雪花模型的应用场景比较少,但也不是没有,所以在具体设计的时候,可以考虑是不是能结合两者的优点参与设计,以此达到设计的最优目的。

©️2020 CSDN 皮肤主题: 技术黑板 设计师:CSDN官方博客 返回首页