笔者根据自己理解总结,如有谬误,恳请指正
- 事实表
事实表,即为事实数据表的简称。主要特点是含有大量的数据,并且这些数据是可以汇总,并被记录的。——百度百科
记录既定事实数据的数据集,比如某时某地某物发生某事,记录为一条数据,一般是原始数据;例如2020年1月1日购物平台袜子销售金额为1000元,这条数据也可以继续细分,如2020年1月1日1时1分1秒20元卖出一双A牌B型号袜子。
因此,事实表的设计与平台能记录的事实数据的最小粒度有关。 如果记录了每双袜子的销售情况,则每次销售记录的集合为事实表,每天的销售数据可以通过该事实表聚合而得;如果仅记录了每天的销售数据,那每天的销售记录的集合为事实表;
事实表由键值和度量值组成,一个事实表中可以包含多个键值和度量值。如上述的例子中,2020年1月1日1时1分1秒为时间维度键值,A牌为品牌维度键值,B型号为型号维度键值,20元为金额度量值,事实表结构如下:
时间 | 品牌 | 型号 | 类型 | 金额 |
---|---|---|---|---|
2020年1月1日1时1分1秒 | A | B | 袜子 | 20 |
如果对该事实表进行简化,如A品牌B型号袜子简化为产品A,对应产品ID为0001,则事实表结构如下:
时间 | 产品ID | 金额 |
---|---|---|
2020年1月1日1时1分1秒 | 0001 | 20 |
此时会发现在事实表我们会丢失A品牌B型号袜子等关键信息,就需要引入维度表来管理这些信息
- 维度表
维度表可以看作是用户来分析数据的窗口,维度表中包含事实数据表中事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据表数据,以便为分析者提供有用的信息,维度表包含帮助汇总数据的特性的层次结构。——百度百科
还是以上述例子为例,我们构建产品维度表:
产品ID | 品牌 | 型号 | 类型 | 指导价 |
---|---|---|---|---|
0001 | A | B | 袜子 | 20 |
0002 | A | C | 袜子 | 30 |
0003 | B | D | 鞋子 | 30 |
通过产品维度表+销售记录事实表,我们就可以得到关于销售信息的数据模型了;
维度表由主键和属性组成,一个维度表只能有一个主键,且主键的值不能重复,一个维度表可以包含多个属性,且这些属性可以进行扩展。一般我们用DIM来表示维度表
上述例子中,销售记录事实表与产品维度表形成1对1的关联关系,但是一般情况下,事实表和维度表都是1对多的关系,例如销售记录事实表的结构增加销售人员ID和购买者ID两个键值,结构如下:
时间 | 产品ID | 销售人员ID | 购买者ID | 金额 |
---|---|---|---|---|
2020年1月1日1时1分1秒 | 0001 | 0011 | 0111 | 20 |
此时,我们需要引入三个维度表:产品维度表,销售人员维度表和消费者维度表,此时形成了我们常说的星型模型
- 星型模型
星型模式是多维的数据关系,它由事实表(Fact Table)和维表(Dimension Table)组成。每个维表中都会有一个维作为主键,所有这些维的主键结合成事实表的主键。事实表的非主键属性称为事实,它们一般都是数值或其他可以进行计算的数据。——百度百科
例如上述例子中,销售记录事实表与产品维度表,销售人员维度表、消费者维度表构成的星型模型为:
星型模型
星型模型特点:
维度表只与事实表关联,维度表之间不关联;
每个维度表都有一个主键,事实表通过每个维度表的主键与维度表进行关联;
以事实表为核心,呈星型分布;
假设有这样一个场景,产品维度表改造为:
产品ID | 品牌ID | 型号 | 类型 | 指导价 |
---|---|---|---|---|
0001 | 100 | B | 袜子 | 20 |
0002 | 100 | C | 袜子 | 30 |
0003 | 101 | D | 鞋子 | 30 |
增加品牌信息维度表,并增加一些品牌相关的属性,结构如下:
品牌ID | 代理人 | 联系电话 | 地址 |
---|---|---|---|
100 | 张三 | XXXXX | 上海市 |
101 | 李四 | XXXXX | 北京市 |
102 | 张三 | XXXXX | 贵州省 |
这种情况下,品牌维度表无法和事实表直接关联,需要通过销售记录事实表->产品维度表->品牌维度表的关系获得,如果采用星型模型,这在产品维度表中会冗余品牌的信息(此时产品维度表包含产品ID、品牌ID、代理人、联系电话、地址、型号、类型、指导价等属性),为应对这种情况,一般引入雪花模型进行数据数据仓库建模
- 雪花模型
雪花模型是当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。雪花模型是对星型模型的扩展。——百度百科
针对上述产品维度和品牌维度的例子,直接画模型:
雪花模型
雪花模型是在星型模型基础上,为了规范化设计而形成的,相比星型模型,雪花模型的特点是贴近业务,数据冗余较少,但由于表连接的增加,导致了效率相对星型模型来的要低一些。星型模型和雪花模型的区别在于:维度表是直接连接到事实表还是其他维度表。
- 星座模型
上述所有例子都考虑了只有一个事实表的情况,维度表都根据该事实表展开,但是实际情况中我们会面对多个事实表的情况,事实表之间会由于引入相同的维度而形成关系模型,我们用星座模型来表述这种关系。
星座模型是一种常见的数据仓库的概念模型。这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。事实星座模型需要多个事实表共享维度表,因而可以视为星形模型的集合,故亦被称为星系模型。——百度百科
直接上图:
星座模型- 宽表
很多场景中,我们都会听到宽表一词,
宽表从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。——百度百科
个人理解:宽表是为了分析和理解数据而构建的,将事实表和维度表合并而成的数据集,是通过牺牲存储空间,通过数据冗余来提高数据分析和理解效率,宽表已经不符合三范式的模型设计规范,常用于数据展示、训练算法模型等场景中。
- 聚合表
在事实表基础上,根据维度表的属性对事实表度量值进行统计分析(例如累加、计数、均值、极值等)而形成的数据表,一般是为了提高查询效率而提前形成的数据集。
- 编码表(码表)
数据仓库中,编码表也是非常重要的组成部分,编码表专门针对代码与实际含义的关联关系而形成的数据集,某种意义上来说,编码表可认为是结构较简单、内容较固定的维度表,主键为代码(编码),属性为实际含义。编码表各系统间差别较大,构建数据仓库时可以参考国家标准、地方标准或行业标准进行编码表设计。
网友评论