Kimball维度建模技术概述
记录一下读《数据仓库工具箱》时的思考，摘录一些书中关于维度建模比较重要的思想与大家分享🤣🤣🤣
第二章前言部分作者提到：技术的介绍应该通过涵盖各种行业的熟悉的用例展开（赞同哈哈 确实比抽象地讲解概念要好理解🤣🤣🤣）。
书中从第三章开始是通过各行业的用例去讲解维度建模，第二章则是维度建模技术的总体介绍（很多概念，挺抽象的🤣🤣🤣）。
前言部分作者也有提到：我们并不期望您一开始就从头到尾阅读本章，但希望您能将本章作为所提供的技术参考。本节介绍的技术，在所有维度设计工作中都需要考虑。本书的每一章几乎都会涉及本节所介绍的概念。
01、基本概念
02、事实表技术基础
03、维度表技术基础
04、使用一致性维度集成
书接上回~（第二章概念比较抽象，博主尽量解释的简单、详细点哈哈）🤣🤣🤣🤣🤣🤣
处理缓慢变化维度属性
- Kimball维度建模技术概述
- 2.5.1 类型0：原样保留
- 2.5.2 类型1：重写
- 2.5.3 类型2：增加新行
- 2.5.4 类型3：增加新属性
- 2.5.5 类型4：增加微型维度
- 2.5.6 类型5：增加微型维度及类型1支架
- 2.5.7 类型6：增加类型1属性到类型2维度
- 2.5.8 类型7：双类型1和类型2维度
- 感谢各位的支持😊
🍕缓慢变化维度（SCD, Slowly Changing Dimension）是指维度表中某些属性会随时间变化，但变化速度较慢。
2.5.1 类型0：原样保留
- 特点🍿：维度表中的数据不会更新，即使属性值发生了变化，表中的值仍然保持原样。
- 适用场景🍔：历史数据不允许修改，例如法律要求数据不可更改的情况下。
Demo🌿：假设有一个客户维度表，记录客户的城市。如果客户搬家，表中仍然保留原来的城市。
| 客户ID | 客户名 | 城市 |
|---|---|---|
| 101 | 张三 | 上海 |
| 102 | 李四 | 北京 |
客户 101 从上海搬到了杭州，但表中仍然保留 上海。
2.5.2 类型1：重写
- 特点🥓：用新值覆盖旧值，历史信息会丢失。
- 适用场景🥗：不需要保留历史数据的情况下，如更正数据错误。
Demo🌿：如果客户 101 搬到了杭州，直接更新记录。
| 客户ID | 客户名 | 城市 |
|---|---|---|
| 101 | 张三 | 杭州 |
| 102 | 李四 | 北京 |
2.5.3 类型2：增加新行
- 特点🥪：为每次变化增加一行，保留历史记录，并通过一个有效时间范围或标记表示当前记录。
- 适用场景🌯：需要完整的历史记录。
Demo🌿：客户 101 搬到杭州后，增加一行，并标记当前有效记录。
| 客户ID | 客户名 | 城市 | 生效开始日期 | 生效结束日期 | 当前记录 |
|---|---|---|---|---|---|
| 101 | 张三 | 上海 | 2024-01-01 | 2024-05-01 | 否 |
| 101 | 张三 | 杭州 | 2024-05-02 | NULL | 是 |
2.5.4 类型3：增加新属性
- 特点🍦：在维度表中为属性变化增加一个额外的列，保留之前的值。
- 适用场景🥠：只需要保留有限的历史记录（通常是上一次的值）。
Demo🌿：为客户表增加“原城市”列。
| 客户ID | 客户名 | 当前城市 | 原城市 |
|---|---|---|---|
| 101 | 张三 | 杭州 | 上海 |
| 102 | 李四 | 北京 | NULL |
2.5.5 类型4：增加微型维度
- 特点🍜：将经常变化的属性单独拆分到一个新的维度表中，减少原维度表的更新频率。
- 适用场景🍨：某些属性变化频繁，且需要保留所有历史记录。
Demo🌿：将客户的“城市”属性单独拆分为一个微型维度表。
客户维度表：
| 客户ID | 客户名 |
|---|---|
| 101 | 张三 |
| 102 | 李四 |
城市微型维度表：
| 城市ID | 城市 |
|---|---|
| 1 | 上海 |
| 2 | 杭州 |
| 3 | 北京 |
事实表：
| 客户ID | 城市ID |
|---|---|
| 101 | 1 |
| 101 | 2 |
2.5.6 类型5：增加微型维度及类型1支架
- 特点🥩：结合类型4（增加微型维度）和类型1（重写），将变化频繁的属性拆分到微型维度，同时在主维度表中保留一个类型1支架（当前值）。
- 适用场景🍤：既需要减少维度更新，又需要快速访问当前值。
Demo🌿：
客户维度表（含类型1支架）：
| 客户ID | 客户名 | 当前城市 |
|---|---|---|
| 101 | 张三 | 杭州 |
| 102 | 李四 | 北京 |
城市微型维度表：
| 城市ID | 城市 |
|---|---|
| 1 | 上海 |
| 2 | 杭州 |
| 3 | 北京 |
事实表：
| 客户ID | 城市ID |
|---|---|
| 101 | 1 |
| 101 | 2 |
2.5.7 类型6：增加类型1属性到类型2维度
- 特点🥧：结合类型1（重写）和类型2（增加新行），在类型2的维度表中增加一个类型1属性，用来存储当前值。
- 适用场景🍻：需要类型2的历史记录，又需要快速访问当前值。
Demo🌿：客户表既保留历史记录，又在同一表中标记当前值。
| 客户ID | 客户名 | 城市 | 当前城市 | 生效开始日期 | 生效结束日期 | 当前记录 |
|---|---|---|---|---|---|---|
| 101 | 张三 | 上海 | 杭州 | 2024-01-01 | 2024-05-01 | 否 |
| 101 | 张三 | 杭州 | 杭州 | 2024-05-02 | NULL | 是 |
2.5.8 类型7：双类型1和类型2维度
- 特点🍪：创建两个独立的维度表，一个作为类型1（重写）的当前维度，一个作为类型2（增加新行）的历史维度。
- 适用场景🍰：需要分开管理当前值和历史记录的情况下。
Demo🌿：
类型1维度表（当前维度）：
| 客户ID | 客户名 | 当前城市 |
|---|---|---|
| 101 | 张三 | 杭州 |
| 102 | 李四 | 北京 |
类型2维度表（历史维度）：
| 客户ID | 客户名 | 城市 | 生效开始日期 | 生效结束日期 |
|---|---|---|---|---|
| 101 | 张三 | 上海 | 2024-01-01 | 2024-05-01 |
| 101 | 张三 | 杭州 | 2024-05-02 | NULL |
