多维分析中的数据模型之星型模型

BI、多维分析中总会遇到两个概念:星型模型和雪花型模型,它俩是用来做什么的?多维分析一般分为两个过程,一是后端数据准备,也就是 cube 或者宽表的准备,二是前端的分析,它俩是属于哪个环节?

我们先上答案,然后再来慢慢具体看。答案就是:星形和雪花型是属于第一阶段,是用来描述 cube 或者宽表的数据关联模式的,就像描述汽车的变速箱是手动的还是自动的一个道理。

下面我们就分两章分别来说明一下星形和雪花型这两种模式各有什么特点,在复杂的多维分析中又各有什么样的利弊,更好的多维分析的 cube 应该是什么样子的。

在了解这俩模型前,我们先要了解两个概念:事实表和维表,因为 cube 就是它俩组成的,星型和雪花型主要就是描述它俩的关系的。事实表,顾名思义是记录描述事实的结构化数据的表,比如银行交易信息、订单信息等;维度表则是事实表引用到的代码表,比如银行账户、订单客户等。

什么是星型模型

就是中间一个事实表,周围辐射出去几个维表,画出来的结构图看起来像星星一样,所以叫做星型模型:

imagepng

星型模型是最简单常用的一种数据模型,它由一个事实表(Fact Table)和一组维表(Dimension Table)组成,以事实表为中心,所有的维度表直接连接在事实表上,,如下图所示:

imagepng

通过这个示例图,可以看出星型模式有以下特点:

  1. 维度表只与事实表关联,维度表之间没有任何联系,也就是说维是单层的;

  2. 每个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键;

3. 以事实表为核心,维度表围绕核心呈现星星分布

换个角度理解星型模型的话,它可以理解为是一种使用关系数据库实现多维分析空间的模式,那么事实表是有外键字段的那个表,维表是外键对应的那个表,它们之间会有个 join 运算,这样就更容易理解下面的内容了。

优点

  1. 相比于雪花型,星型模型中主要数据存储在事实表中,事实表中存储了业务的大部分核心信息,可读性比较好。维度表只和事实表关联,数据结构看起来也更加容易理解。

  1. 相比于宽表,星形模式将事实表和维度表拆开,数据结构相对灵活些,如维度表数据变化(外键不变)不会影响整个数据结构。

缺点

随着现在业务的复杂,数据结构设计时单张事实表内很难存储用户需要的所有数据,所以一般情况下需要提前对多张事实表数据抽取到一张事实表内,形成一张宽表,所以星型模型目前主要是事实宽表 + 维表方式组成,所以宽表的缺点在星型模型中同样存在,之前在《多维分析 - 宽表的利与弊》中列出了宽表的缺点(比如某些原因导致的宽表无法生成),这里就不再细说,这里主要看下星型和雪花型相比有什么缺点:

  1. 星型架构中多维数据集的每一个维度都直接与事实表相连接,不存在渐变维度,所以数据有一定的冗余,比如在地区维度表中,存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录,那么国家 A 和省 B 的信息分别存储了两次。数据存在冗余。

  2. 星型模型中维表必须和事实表关联,这样要求事实表中必须包含指向维表的外键,事实表数据结构相对固定,而用户的数据分析需求可能灵活多变,比如如下结构:

imagepng

销售表(事实表)通过外键和产品表以及人员表关联,此时用户可以根据产品信息做数据分析,但是如果用户还想增加产品类别维度,那么就需要更改销售表的数据结构增加类别字段,如果再增加人员职务等,这样事实表的结构就很难固定下来了,这还是比较简单的维度,如果像一些层级不固定的机构,恐怕事实表都不一定能生成,那么单个事实宽表就无法描述所有需求,只能跟随业务需求,有针对的生成相关的宽表,如果这个过程继续依赖于技术人员,就会导致在线分析无法 "在线"。

总结

虽然星型模型是一种非规范化的模型,但是由于它简单高效,所以在冗余可以接受的前提下,实际运用中星型模型使用更多,也更有效率,比如在数据仓库建设中,大多时候比较适合使用星型模型构建底层数据表。星型模型也适用于处理简单的查询,而且对 OLAP 的分析引擎支持比较友好,适合做指标分析。

但是如果维表的数据量比较大,需要进行更加复杂的层次分析时,维度必须规范化,此时可以考虑采用雪花型模型。雪花型模型满足范式,可以解决星型模型存在的问题,关于雪花型模型的详细内容我们将在后续章节中讲解。