笔者根据自己理解总结，如有谬误，恳请指正
- 事实表
事实表，即为事实数据表的简称。主要特点是含有大量的数据，并且这些数据是可以汇总，并被记录的。——百度百科
记录既定事实数据的数据集，比如某时某地某物发生某事，记录为一条数据，一般是原始数据；例如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、代理人、联系电话、地址、型号、类型、指导价等属性），为应对这种情况，一般引入雪花模型进行数据数据仓库建模
- 雪花模型
雪花模型是当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。——百度百科
针对上述产品维度和品牌维度的例子，直接画模型：
雪花模型是在星型模型基础上，为了规范化设计而形成的，相比星型模型，雪花模型的特点是贴近业务，数据冗余较少，但由于表连接的增加，导致了效率相对星型模型来的要低一些。星型模型和雪花模型的区别在于：维度表是直接连接到事实表还是其他维度表。
- 星座模型
上述所有例子都考虑了只有一个事实表的情况，维度表都根据该事实表展开，但是实际情况中我们会面对多个事实表的情况，事实表之间会由于引入相同的维度而形成关系模型，我们用星座模型来表述这种关系。
星座模型是一种常见的数据仓库的概念模型。这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。事实星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型。——百度百科
直接上图：
- 宽表
很多场景中，我们都会听到宽表一词，
宽表从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。——百度百科
个人理解：宽表是为了分析和理解数据而构建的，将事实表和维度表合并而成的数据集，是通过牺牲存储空间，通过数据冗余来提高数据分析和理解效率，宽表已经不符合三范式的模型设计规范，常用于数据展示、训练算法模型等场景中。
- 聚合表
在事实表基础上，根据维度表的属性对事实表度量值进行统计分析（例如累加、计数、均值、极值等）而形成的数据表，一般是为了提高查询效率而提前形成的数据集。
- 编码表（码表）
数据仓库中，编码表也是非常重要的组成部分，编码表专门针对代码与实际含义的关联关系而形成的数据集，某种意义上来说，编码表可认为是结构较简单、内容较固定的维度表，主键为代码（编码），属性为实际含义。编码表各系统间差别较大，构建数据仓库时可以参考国家标准、地方标准或行业标准进行编码表设计。
