Kimball维度建模技术概述
记录一下读《数据仓库工具箱》时的思考，摘录一些书中关于维度建模比较重要的思想与大家分享🤣🤣🤣
第二章前言部分作者提到：技术的介绍应该通过涵盖各种行业的熟悉的用例展开（赞同哈哈 确实比抽象地讲解概念要好理解🤣🤣🤣）。
书中从第三章开始是通过各行业的用例去讲解维度建模，第二章则是维度建模技术的总体介绍（很多概念，挺抽象的🤣🤣🤣）。
前言部分作者也有提到：我们并不期望您一开始就从头到尾阅读本章，但希望您能将本章作为所提供的技术参考。本节介绍的技术，在所有维度设计工作中都需要考虑。本书的每一章几乎都会涉及本节所介绍的概念。
01、基本概念
02、事实表技术基础
03、维度表技术基础
书接上回~（第二章概念比较抽象，博主尽量解释的简单、详细点哈哈）🤣🤣🤣🤣🤣🤣
使用一致性维度集成
- Kimball维度建模技术概述
- 2.4.1 一致性维度
- 2.4.2 缩减维度
- 2.4.3 跨表钻取
- 2.4.4 价值链
- 2.4.5 企业数据仓库总线架构
- 2.4.6 企业数据仓库总线矩阵
- 整理不易🤣 您的支持就是我创作的最大动力💛
2.4.1 一致性维度
一致性维度是干嘛的？🤨 —— 核心🎨是为企业数据仓库架构提供一致性和复用性（一次设计，可供多个事实表复用，减少开发和维护成本）。
一致性维度是指跨多个事实表和数据集共享的一组维度。通过统一的结构和内容，这些维度确保在不同业务过程之间进行一致的分析和比较。
举个栗子😂：
-
时间维度：销售事实表和库存事实表共享相同的时间维度，支持按日期分析销售额和库存水平的变化。
-
客户维度：在销售事实表和服务事实表中，客户维度保持一致，可以分析客户购买行为与售后服务的关系。
- 通过共享维度，可以对多个业务过程进行关联分析，例如按客户对销售和服务进行综合评估。
- ❄❄❄一次设计，可供多个事实表复用，减少开发和维护成本。
2.4.2 缩减维度
在维度建模中，缩减维度（Shrunken Dimensions） 是原始维度的一个简化版本，包含维度的子集数据。
缩减维度 通常基于 一致性维度 创建，用于支持不同的聚合粒度需求。
Demo🤣🤣🤣：
-
原始时间维度：
包含“年”、“月”、“日”级别的详细信息。时间键 年 月 日 星期 20240101 2024 1 1月1日 星期一 20240102 2024 1 1月2日 星期二 -
缩减时间维度：
只保留“年”、“月”数据，用于年度或月度分析。年月键 年 月 202401 2024 1 202402 2024 2
Tips🤣:
- 属性减少：原始维度的部分字段被移除，只保留分析需求中关键的字段。
- 特定业务场景：常用于跨过程汇总分析，或将细粒度维度压缩成高粒度维度。
- 跨过程分析：用于跨多个事实表的对比，例如年度客户购买行为的对比。
- 性能优化：减少数据的存储量，加快查询速度。
2.4.3 跨表钻取
跨表钻取指的是用户在进行数据分析时，通过一个表中的数据查找到相关的、不同表中的数据，从而得到更加全面的信息。
这术语太专业了，简单讲其实就是表之间join😂😂😂
Demo：
销售事实表 (sales_fact)：
| 销售ID | 销售金额 | 产品ID |
|---|---|---|
| 1 | 1000 | 101 |
| 2 | 500 | 102 |
产品维度表 (product_dim)：
| 产品ID | 产品名称 |
|---|---|
| 101 | 手机 |
| 102 | 电视 |
跨表钻取：
从销售事实表钻取，基于产品ID获取产品名称：
| 销售金额 | 产品名称 |
|---|---|
| 1000 | 手机 |
| 500 | 电视 |
销售事实表 (sales_fact)：
| 销售ID | 销售金额 | 客户ID |
|---|---|---|
| 1 | 1000 | 201 |
| 2 | 500 | 202 |
客户维度表 (customer_dim)：
| 客户ID | 客户名称 |
|---|---|
| 201 | 李明 |
| 202 | 王芳 |
跨表钻取：
从销售事实表钻取，基于客户ID获取客户名称：
| 销售金额 | 客户名称 |
|---|---|
| 1000 | 李明 |
| 500 | 王芳 |
Tips：
与钻取（Drill Down 也叫 下钻）的区别：
- 钻取（Drill Down）： 是指在同一个表内，基于某个维度的细节层次查看更深入的数据。比如从年数据钻取到月数据，再到日数据。
- 跨表钻取： 是指跨越不同的表，通过共同字段或关系来查看相关的数据。通常涉及多个表的联合。
2.4.4 价值链
价值链（Value Chain）指的是企业在生产和交付产品或服务的过程中，从原材料获取到最终产品或服务交付给客户的各个环节。
操作型源系统（Operational Source Systems）通常会为价值链上的每个步骤建立事务或快照，以便捕捉和存储与日常业务操作相关的数据。
Demo：
在企业的价值链中，每个环节都会生成操作数据。这些数据通常会通过操作型源系统记录，进而转入数据仓库：
采购事务表（purchase_fact）：记录每个采购交易的详细信息。
| 采购ID | 采购金额 | 采购日期 | 供应商ID |
|---|---|---|---|
| 1 | 1000 | 2024-01-01 | 301 |
| 2 | 500 | 2024-01-02 | 302 |
采购快照表（purchase_snapshot）：记录某一时间点的采购状态。
| 时间 | 供应商ID | 库存量 |
|---|---|---|
| 2024-01-01 | 301 | 500 |
| 2024-02-01 | 302 | 450 |
生产原子事实表（production_fact）：记录每个生产批次的信息。
| 生产ID | 生产数量 | 生产日期 | 产品ID |
|---|---|---|---|
| 1 | 100 | 2024-01-01 | 101 |
| 2 | 200 | 2024-01-02 | 102 |
生产快照表（production_snapshot）：记录某一时间点的生产状态。
| 时间 | 产品ID | 生产数量 |
|---|---|---|
| 2024-01-01 | 101 | 500 |
| 2024-02-01 | 102 | 600 |
销售原子事实表（sales_fact）：记录每笔销售交易的详细信息。
| 销售ID | 销售金额 | 销售日期 | 客户ID | 产品ID |
|---|---|---|---|---|
| 1 | 1000 | 2024-01-01 | 201 | 101 |
| 2 | 500 | 2024-01-02 | 202 | 102 |
客户服务原子事实表（customer_service_fact）：记录每个客户服务请求的详细信息。
| 服务ID | 服务类型 | 服务日期 | 客户ID |
|---|---|---|---|
| 1 | 退货 | 2024-01-01 | 201 |
| 2 | 咨询 | 2024-01-02 | 202 |
服务快照表（customer_service_snapshot）：记录某一时间点的客户服务状态。
| 时间 | 客户ID | 服务请求数量 |
|---|---|---|
| 2024-01-01 | 201 | 1 |
| 2024-02-01 | 202 | 2 |
2.4.5 企业数据仓库总线架构
企业数据仓库总线架构（Enterprise Data Warehouse Bus Architecture）是指在构建企业数据仓库时，采用一种以标准化维度模型为核心的架构。
核心思想💕是将数据仓库中的不同业务领域（例如销售、财务、生产等）通过共享的维度（如时间、产品、客户等）连接起来，从而形成一个统一的数据仓库架构。
- 共享维度：不同业务领域之间共享公共的维度，如
时间维度、客户维度、产品维度等。共享的维度可以实现不同的业务数据进行统一分析和汇总。 - 业务领域事实表：每个业务领域都有对应的事实表，记录该领域的操作数据（如销售额、生产数量等）。这些事实表通过共享的维度与其他领域的事实表进行连接。
Demo：
-
共享维度表：
Time Dimension（时间维度）：记录时间的详细信息，如年份、季度、月、日等。Customer Dimension（客户维度）：记录客户的详细信息，如客户ID、姓名、地址等。Product Dimension（产品维度）：记录产品的详细信息，如产品ID、产品名称、类别等。
-
各业务领域的事实表：
- Sales Fact（销售事实表）：记录每笔销售交易的详细信息，包含销售额、客户ID、产品ID、销售日期等。
- Purchase Fact（采购事实表）：记录每笔采购交易的详细信息，包含采购金额、供应商ID、产品ID、采购日期等。
- Production Fact（生产事实表）：记录生产过程中每个批次的产量和生产成本，包含生产数量、产品ID、生产日期等。
总线架构的工作方式
在总线架构中，所有的事实表都通过共享维度表进行连接。
- 销售事实表中的
客户ID会链接到客户维度表中的客户ID。 - 销售事实表中的
产品ID会链接到产品维度表中的产品ID。 - 销售事实表中的
时间ID会链接到时间维度表中的时间ID。
企业数据仓库总线架构通过标准化共享维度和跨业务领域的事实表连接，帮助企业整合来自不同业务领域的数据，从而实现统一的数据分析和报告。
2.4.6 企业数据仓库总线矩阵
企业数据仓库总线矩阵（Enterprise Data Warehouse Bus Matrix）是指在数据仓库总线架构中，通过一个矩阵来明确每个维度与各个业务领域事实表之间的关系。
一言以蔽之😂——明确不同的业务领域（如销售、采购、生产等）和共享维度（如时间、产品、客户等）之间的关系。
总线矩阵可以看作是一个二维表格，其中：
- 行代表数据仓库中的业务领域（如销售、采购、生产等）。
- 列代表所有的共享维度（如时间、产品、客户等）。
在矩阵中的每个单元格，用来表示某个业务领域是否与某个共享维度相关联。如果某个业务领域需要使用该维度进行分析，那么这个单元格就会被标记。
-
业务领域（行）：
- 销售（Sales）
- 采购（Purchase）
- 生产（Production）
- 客户服务（Customer Service）
-
共享维度（列）：
- 时间维度（Time）
- 产品维度（Product）
- 客户维度（Customer）
总线矩阵：
| 业务领域 | 时间维度 | 产品维度 | 客户维度 |
|---|---|---|---|
| 销售（Sales） | ✔ | ✔ | ✔ |
| 采购（Purchase） | ✔ | ✔ | |
| 生产（Production） | ✔ | ✔ | |
| 客户服务（Service） | ✔ | ✔ |
Tips🤣🤣🤣：
- 清晰的维度使用规划：通过矩阵清晰标识哪些维度是跨业务领域共享的，哪些是特定领域使用的，有助于保持数据的一致性和结构的清晰。
- 便于扩展和调整：如果以后需要新增一个业务领域或修改已有的维度，矩阵可以迅速帮助你识别影响，进行相应调整。
- 跨业务领域的分析：通过共享的维度，数据仓库能够实现不同业务领域之间的联合分析，比如对销售和生产数据的综合分析。
企业数据仓库总线矩阵有助于规划和组织数据仓库中的维度和事实表的结构，确保所有业务领域都能够使用共享维度进行分析。
