数仓：建模理论

数仓建模理论

范数理论

函数依赖

完全函数依赖

设 \(X,Y\) 是关系 \(R\) 的两个属性集合，\(X'\) 是 \(X\) 的真子集，存在 \(X\rightarrow Y\)，但是对每一个 \(X'\) 都有 \(X'!\rightarrow Y\)，则称 \(Y\) 完全函数依赖于 \(X\)。

例如：学号和课程可以推断出分数，但是单独靠学号是不能推断出分数，所以分数完全函数依赖于学号和课程。

部分函数依赖

假如 \(Y\) 函数依赖于 \(X\)，但是 \(Y\) 并不完全函数依赖于 \(X\)，则称 \(Y\) 部分函数依赖于 \(X\)。

例如：学号和课程可以推断出姓名，但是单独靠学号也可以推断出姓名，所以姓名部分函数依赖于学号和课程。

传递函数依赖

设 \(X,Y,Z\) 是关系 \(R\) 中互不相同的属性集合，存在 \(X\rightarrow Y(Y!\rightarrow X),Y\rightarrow Z\)，则称 \(Z\) 传递函数依赖于 \(X\)。

例如：学号可以推断出院系，院系可以推断出系主任，而院系推断不出学号，则称系主任传递函数依赖于学号。

第一范式

核心原则：属性不可分割

ID	商品	商家
01	5台电脑	XXX旗舰店

上述表格设计不符合第一范式，因为“商品”这一列的数据不是原子数据项，是可以分割的。

ID	商品	数量	商家
01	电脑	5	XXX旗舰店

第一范式是所有关系型数据库最基本的要求。

第二范式

核心原则：不能存在部分函数依赖

学号	姓名	课程名	分数
202301	小明	数据结构	90
202301	小明	高数	88

上述表的主键为（学号，课程名），显然分数是完全函数依赖于（学号，课程名）的，但是姓名是部分函数依赖于（学号，课程名）。因此要去掉部分函数依赖，得到以下两张表。

学号	课程名	分数
202301	数据结构	90
202301	高数	88

学号	姓名
202301	小明

第三范式

核心原则：不能存在传递函数依赖

学号	姓名	系名	系主任
202301	小明	计软系	张三
202302	小红	经济系	李四

上述表存在函数依赖，学号可以推出系名，系名可以推出系主任，但是系主任推不出学号。因此要去掉传递函数依赖，得到以下两张表。

学号	姓名	系名
202301	小明	计软系
202302	小红	经济系

系名	系主任
计软系	张三
经济系	李四

维度模型

维度模型将复杂的业务通过事实和维度两个概念进行呈现。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。维度建模以数据分析作为出发点，为数据分析服务。

事实表

包含与该业务过程有关的维度引用（维度表外键）以及该业务过程的度量（通常是可累加的数字类型字段）。

事实表通常列较少，但行较多，且行的增速快。

事实表有三种类型：事务型事实表、周期快照事实表和累积快照事实表。

事务型事实表

记录各业务过程，保存各业务过程的原子操作事件（最细粒度的操作事件）。

1. 选择业务过程：业务过程可以概括为一个个不可拆分的行为事件，如下单、付款和退单等。
2. 声明粒度：精确定义每张事务型事实表的每行数据表示什么，应该尽可能选择最细粒度。
3. 确定维度：确定与每张事务型事实表相关的维度有哪些。
4. 确定事实：事实是指每个业务过程的度量值（通常是可累加的数字类型的值，例如次数、个数和金额等）。

对于某些特定类型的需求，事务型事实表的逻辑可能会比较复杂，或者效率会比较低下。

• 存量型指标：有一需求要统计截至当日的各用户虚拟货币余额。由于获取货币和使用货币均会影响到余额，故需要对两张事务型事实表进行聚合，且区分两者对余额的影响。
• 多事务关联统计：有一需求要统计最近30天，用户下单到支付的时间间隔的平均值。需要找到下单事务事实表和支付事务事实表，过滤出最近 30 天的记录，然后按照订单 id 对两张事实表进行关联。

周期快照事实表

以具有规律性的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存，账户余额）或者状态型（空气温度，行驶速度）指标。

状态型指标往往是连续的，无法捕获其变动的原子事务操作，所以只能定期对其进行采样，构建周期型快照事实表。

1. 确定粒度：粒度可由采样周期（常选择每日）和维度（统计每个仓库中每种商品的库存）描述。则该表粒度为每日-仓库-商品。
2. 确认事实：可根据统计指标决定，例如指标为统计每个仓库中每种商品的库存，则事实为商品库存。

累积快照事实表

基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。主要用于分析业务过程（里程碑）之间的时间间隔等需求。

订单 id	用户 id	下单日期	支付日期	发货日期	收货日期	订单金额	支付金额
1001	0001	2023-2-12	2023-2-13	2023-2-13	2023-2-13	1000	1000

1. 选择业务过程：选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累积型快照事实表。
2. 声明粒度
3. 确认维度：每各业务过程均需要一个日期维度。
4. 确认事实

维度表

维度表围绕业务过程所处的环境进行设计。主要包含一个主键和各种维度字段（维度属性）。

设计步骤

1. 确定维度：理论上每个相关维度均需对应一张维度表，但是可能存在多个事实表与同一个维度都相关的情况，这时只创建一张维度表。当维度属性很少时，则不创建维度表，把属性添加到事实表中，这个操作叫维度退化。
2. 确定主维表和相关维表：相关维表的粒度通常与主维表相同。
3. 确定维度属性：尽可能生成丰富的维度属性，尽量不使用编码，尽量沉淀出通用的维度属性。

维度设计要点

• 规范化：使用一系列范式设计数据库的过程，减少数据冗余，增强数据的一致性。规范化后得到的维度模型称为雪花模型。
• 反规范化：将多张表的数据冗余到一张表，减少 \(join\) 操作，提高查询性能。反规范化后得到的模型称为星型模型。

维度属性通常不是静态的，而是会随时间变化的，保存维度数据的历史状态有如下方法：

• 全量快照表：优点是简单而有效，缺点是浪费存储空间。
• 拉链表：记录每条信息的生命周期，一旦生命周期结束，就重新开始一条新的记录，并把当前日期放入生效开始日期。该方法适用于每天变化的比例不高的维度。