数据仓库基础理论—维度建模（图文详解）

数据仓库基础理论—维度建模

维度建模是数据仓库设计中的一种核心方法，旨在以业务角度组织数据，使其更易于理解、查询和分析。
在这里插入图片描述

1. 维度模型的基本概念

1.1 事实表（Fact Table）：

事实表是维度模型的核心，存储了业务过程中的事实或事件，通常是数值型的数据，如销售金额、数量等。
事实表通常比较“细长”，即列较少，但行较多，且行的增速快。

在这里插入图片描述

事实表中包含了业务过程的度量（Measures），可以通过与维度表关联来进行分析和查询。

在这里插入图片描述
事实表是星型模式中的中心表格，用于存储业务事实或事件的数据，通常与多个维度表通过外键关联。

数据类型：事实表包含两种类型的列：一种是实际的事实数据，如销售额、数量等；另一种是指向维度表的外键。
主键：事实表的主键通常是一个由所有外键组成的复合键，这样可以确保每个事实行都能唯一地与其相关的维度组合。
粒度：事实表通常包含同一级别的事实数据，可以是详细级别的事实或已经聚合的事实（如果包含聚合事实，则通常称为汇总表）。

在这里插入图片描述
当设计数据仓库中的事实表时，常见的三种类型是事务事实表、周期快照事实表和累积快照事实表。

事务事实表（`Transactional Fact Table`）

事务型事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件。

粒度是指事实表中一行数据所表达的业务细节程度。

特点：
- 记录事务级别的事件或业务活动，通常是每个事务的单独记录。
- 每条记录通常包含时间戳、事实数据和维度键。
- 可能包含大量的细节数据，例如订单、交易、事件等。
适用场景：
- 需要详细记录每个事务的细节和具体事件。
- 对数据的插入操作比较频繁，更新操作相对较少。
- 适合支持实时或接近实时的数据加载。
设计流程：

设计事务事实表时一般可遵循以下四个步骤。选择业务过程→声明粒度→确认维度→确认事实。

选择业务过程：
在业务系统中，选择我们感兴趣的业务过程，例如电商交易中的下单、取消订单、付款、退单等。每个业务过程对应一张事务型事实表。
声明粒度：
确定每个业务过程的粒度，即定义每张事务型事实表的每行数据表示什么。应选择最细粒度，以满足各种详细需求。例如，订单事实表中的一行数据表示一个订单中的一个商品项。
确定维度：
确定与每张事务型事实表相关的维度。应选择与业务过程相关的环境信息，丰富维度模型，以支持多样化的指标需求。
确定事实：
确定每个业务过程的度量值，即可累加的数字类型的值，如次数、个数、金额等。

周期快照事实表（`Periodic Snapshot Fact Table`）

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

对于商品库存、账户余额这些存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，就能轻松应对此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合了。

特点：
- 记录在给定周期内的状态或快照，通常是固定时间间隔（如每天、每周）的快照。
- 每个快照周期内只存储一条记录，反映在该周期结束时的状态。
- 包含当前周期内的聚合数据，如订单总额、库存量等。

在这里插入图片描述

适用场景：
- 需要分析和比较不同时间点的状态变化。
- 对历史数据的查询和分析比较频繁。
- 适合用于周期性报告、趋势分析等场景。
设计流程：

确定粒度：
周期型快照事实表的粒度由采样周期和维度描述决定。通常选择每日作为采样周期。维度根据统计指标确定，例如统计每个仓库中每种商品的库存，确定粒度为每日-仓库-商品。
确认事实：
事实根据统计指标确定，例如统计每个仓库中每种商品的库存，则事实为商品库存。

累积快照事实表（`Accumulating Snapshot Fact Table`）

累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。

累积型快照事实表通常具有多个日期字段，每个日期对应业务流程中的一个关键业务过程（里程碑）。

订单id	用户id	下单日期	支付日期	发货日期	确认收货日期	订单金额	支付金额
1001	1234	2022-06-08	2022-06-09	2022-06-16	2022-06-17	1000	1000

累积型快照事实表主要用于分析业务过程（里程碑）之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。

特点：
- 记录一个业务过程中的多个关键阶段的状态，通常涵盖整个过程的生命周期。
- 每个阶段会有多条记录，每条记录代表一个关键状态（如订单的下单、发货、送达等）。
- 包含多个日期键和相关维度，如开始日期、结束日期、状态等。

在这里插入图片描述

适用场景：
- 需要跟踪和分析业务过程中每个阶段的进展和状态。
- 适合于分析业务过程的整体性能和效率。
- 对于跨部门协作和过程优化有很好的支持。
设计流程：

选择业务过程：
选择一个关键业务流程，例如电商平台的订单处理流程。
声明粒度：
定义每行数据所表示的具体内容，选择最小的数据粒度。例如，每行数据可能表示每个订单的某个关键时间点或事件。
确认维度：
确定与每个业务过程相关联的维度，确保包含一个日期维度用于时间分析。
确认事实：
选择每个业务过程中需要记录和分析的度量值。例如，订单的金额、数量等。

1.2 维度表（Dimension Table）：

维度表描述了事实表中度量数据的上下文或背景信息，例如时间、地点、产品、客户等。
维度表通常包含文本型数据，用于筛选、分组和标识事实数据。
维度表的每一行对应一个唯一的维度成员，例如一个特定的时间点、地理位置或产品。

在这里插入图片描述

维度表用于描述事实表中数据的上下文或背景信息，例如时间、地理位置、产品、客户等。

组织结构：维度是由一个或多个层次结构组成，用于对数据进行分类和分层。如果维度没有层次结构和级别，则称为平面维度或列表。
主键：每个维度表的主键是事实表复合主键的一部分，确保了维度数据的唯一性和完整性。
描述性属性：维度表包含描述性的文本型数据，帮助对事实数据进行筛选、分组和标识。

维度表设计流程：

1）确定维度（表）

在设计事实表时，已经确定了与每个事实表相关的维度，理论上每个相关维度均需对应一张维度表。

需要注意到，可能存在多个事实表与同一个维度都相关的情况，这种情况需保证维度的唯一性，即只创建一张维度表。

另外，如果某些维度表的维度属性很少，例如只有一个**名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为维度退化。

在这里插入图片描述

2）确定主维表和相关维表

此处的主维表和相关维表均指业务系统中与某维度相关的表。

例如业务系统中与商品相关的表有sku_info，spu_info，base_trademark，base_category3，base_category2，base_category1等，其中sku_info就称为商品维度的主维表，其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。
3）确定维度属性
- （1）尽可能生成丰富的维度属性
  维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。
- （2）尽量不使用编码，而使用明确的文字说明，一般可以编码和文字共存。
- （3）尽量沉淀出通用的维度属性
  有些维度属性的获取需要进行比较复杂的逻辑处理，例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理，可将这些维度属性沉淀到维度表中。

在这里插入图片描述

2. 常见的维度模型结构

2.1 星型模式（Star Schema）：

星型模式是最简单和最常见的维度模型结构，由一个中心的事实表和多个维度表组成，事实表与各个维度表通过外键关联。

在这里插入图片描述

这种结构形成了一个星型的图形，事实表位于中心，维度表则位于周围，类似星星的形状，因此得名。

在这里插入图片描述

中心事实表：星型模式的核心是一个事实表，用于存储业务事实或事件的数值型数据，如销售额、数量等。事实表通常包含一个复合主键，由与之相关的各个维度表的外键组成，确保了数据的唯一性和完整性。
多个维度表：维度表用于描述事实数据的上下文或背景信息，如时间、地理位置、产品、客户等。每个维度表都有一个唯一的主键，该主键同时也是事实表复合主键的一部分。
外键关联：事实表通过与维度表的外键关联，实现了事实数据与其上下文信息的结合。这种关系设计使得数据分析者能够快速、直观地理解和查询业务数据。
简单直观：星型模式的结构简单明了，易于理解和实施。它提供了一种直观的数据模型，有助于用户进行复杂数据分析和决策支持。

星型模式适合那些以分析查询为主要目的的数据仓库应用，尤其是对于 OLAP（联机分析处理）工作负载而言，效果显著。

它提供了灵活性和性能优势，使得数据仓库可以快速响应用户复杂的分析需求。