一、关系建模与维度建模

（1）关系建模

关系建模将复杂的数据抽象为两个概念——实体和关系，并使用规范化的方式表示出来。关系模型松散、零碎，物理表数量多

说明：关系模型严格遵循第三范式（3NF），数据冗余程度低，数据的一致性容易得到保证。由于数据分布于众多的表中，查询会相对复杂，在大数据的场景下，查询效率相对较低

（2）维度建模

维度模型相对来说清晰、简洁

说明：维度模型以数据分析作为出发点，不遵循三范式，故数据存在一定的冗余。维度模型面向业务，将业务用事实表和维度表呈现出来。表结构简单，故查询简单，查询效率较高

二、维度表和事实表（重点）

（1）维度表

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等

维度表的特征：

1. 维表的范围很宽（具有多个属性、列比较多）
2. 跟事实表相比，行数相对较小：通常< 10万条
3. 内容相对固定：如：编码表

（2）事实表

事实表：表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等），例如，2020年5月21日，小明在京东花了50块钱买了一本书。维度表：时间、用户、商品、商家。事实表：50块钱、一本

每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键，通常具有两个和两个以上的外键
说明：事实表的字段分两类，一类是维度相关的外键，另一类是度量值

度量值（可统计次数、个数、金额等）

事实表的特征：

1. 数据量非常的大，行数多
2. 内容相对的窄：字段列数较少（主要是维度表的外键id和度量值）
3. 经常发生变化，每天会新增加很多

三、事实表类型

（1）事务型事实表
以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新

总结：

适应的业务模块：不会发生变化的业务
同步策略：增量同步

（2）周期型快照事实表
周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。
例如购物车，有加减商品，随时都有可能变化，但是我们更关心每天结束时这里面有多少商品，方便我们后期统计分析。

总结：

适应的业务模块：不关心具体的明细操作，只关心最终的结果
同步策略：全量同步

（3）累积型快照事实表

累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新

总结：

适应的业务模块：会发生周期性变化的业务
同步策略：新增即变化同步

四、维度模型分类

在维度建模的基础上又分为三种模型：星型模型、雪花模型、星座模型

星型模型：星型模型与雪花模型的主要区别在于维度的层级，星型模型对维度表进行规划化，主要目的是消除数据的冗余。标准的星型模型维度只有一层，二雪花模型维度有多层。

雪花模型：因为维度比较高，表拆的比较散，靠近第三范式，但是无法完全遵守，因为第三范式成本太高

星座模型：星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表。其实星座模型只反应是否有多个事实表，并不与前两个模型冲突

模型的选择

模型的选择跟数据和需求有关系，跟设计没关系，不用选择，根据实际情况灵活组合；星型模型性能优先，雪花模型灵活性更优先

参考：atguigu