上一篇
数据仓库事实表结构是怎样的？事实表设计原则有哪些
事实表（Fact Table）是数据仓库核心架构中的关键组成部分，它存储了业务过程中可度量的、细粒度的业务事件数据，与维度表存储描述性上下文不同，事实表主要包含外键（指向维度表）和数值型度量值，一个设计良好的事实表结构通常遵循第三范式或星型/雪花型模型的规范,以确保查询性能和分析灵活性。
事实表的核心组成要素
事实表的结构主要由三类列组成：外键列、度量列和可选的退化维度列。
-
外键列（Foreign Keys）：
这些列用于关联到维度表，提供业务事件的上下文信息，一个销售事实表会包含“产品ID”、“客户ID”、“时间ID”和“门店ID”,这些ID通常对应维度表的主键。
-
度量列（Measures/Facts）：
这是事实表的核心，存储业务过程中可聚合的数值,度量值通常分为两类：
- 可加性度量（Additive）：可以在所有维度上求和，如销售额、数量。
- 半可加性度量（Semi-additive）：可以在部分维度上求和，如账户余额（可按时间求平均，但不能按产品求和）。
- 不可加性度量（Non-additive）：无法在任何维度上求和，如比率、百分比、单价。
-
退化维度列（Degenerate Dimensions）：
这些列不属于任何维度表，而是直接存储在事实表中，通常用于记录业务过程中的唯一标识符，如订单号、发票号或交易流水号,它们有助于在不连接维度表的情况下快速定位特定业务事件。
典型事实表结构示例：销售事实表
以下是一个典型的“销售事实表”（fact_sales）的结构示例，展示了各列的定义、数据类型及业务含义。
| 列名 | 数据类型 | 约束 | 说明 | 类型 |
|---|---|---|---|---|
| sales_key
| BIGINT | PK, Auto Increment | 事实表的主键，唯一标识每一行记录 | 代理键 |
| date_key | INT | FK | 关联日期维度表，表示销售发生的日期 | 外键 |
| product_key | INT | FK | 关联产品维度表，表示销售的商品 | 外键 |
| customer_key | INT | FK | 关联客户维度表，表示购买者 | 外键 |
| store_key | INT | FK | 关联门店维度表，表示销售发生的地点 | 外键 |
| order_id | VARCHAR(50) | Index | 退化维度，原始业务系统中的订单编号 | 退化维度 |
| quantity | INT | NOT NULL | 销售数量，可加性度量 | 度量值 |
| unit_price | DECIMAL(10,2) | NOT NULL | 商品单价，不可加性度量 | 度量值 |
| total_amount | DECIMAL(12,2) |
NOT NULL | 销售总额，可加性度量（通常由 quantity unit_price 计算得出） | 度量值 |
| discount_amount | DECIMAL(10,2) | Default 0 | 折扣金额，可加性度量 | 度量值 |
| profit_margin | DECIMAL(5,4) | NULL | 利润率，不可加性度量 | 度量值 |
事实表的分类与结构差异
根据粒度（Granularity）的不同，事实表的结构会有显著差异,常见的分类包括：
-
事务事实表（Transaction Fact Table）：
记录每一次业务事务的发生，粒度最细，每发生一笔销售就插入一行，其结构通常包含所有相关的外键和度量值，行数巨大,但数据最详细。
-
周期汇总事实表（Periodic Snapshot Fact Table）：
按固定时间间隔（如每天、每月）对业务状态进行快照，银行账户余额表，每天记录一次每个账户的余额，其结构通常包含时间键、实体键（如账户ID）和状态度量值（如余额），不包含事务性的外键（如交易ID）。
-
累积快照事实表（Accumulating Snapshot Fact Table）：
用于跟踪业务流程中多个关键步骤的状态，订单履行流程，记录从“下单”、“支付”、“发货”到“签收”的各个时间点，其结构包含多个时间戳列（如 order_date, ship_date, delivery_date）和对应的外键,行数随流程推进而更新。
设计最佳实践
- 保持细粒度：事实表应尽可能保持最细的业务粒度，避免在事实表中进行预聚合,以便后续灵活分析。
- 一致性度量：确保度量值的定义在所有事实表中保持一致，销售额”在所有表中都指含税或不含税金额,避免歧义。
- 索引策略：对外键列和退化维度列建立索引,以加速连接查询和过滤操作。
- 分区考虑：对于大型事实表，建议按时间键（如 date_key）进行分区,以提高查询性能和数据管理效率。
相关问题与解答
问题 1：在事实表中，为什么通常不建议直接存储描述性文本（如产品名称、客户姓名），而应通过外键关联维度表？
解答：
在数据仓库设计中，遵循第三范式或星型模型的核心原则是将描述性数据（维度）与可度量数据（事实）分离，如果直接在事实表中存储描述性文本,会导致以下问题：
- 数据冗余：同一产品可能在成千上万条销售记录中出现,重复存储产品名称会浪费大量存储空间。
- 数据不一致：如果产品名称发生变更（如品牌升级），需要更新所有相关的历史事实表记录,这会导致数据维护困难且容易出错。
- 查询性能下降：存储大量文本数据会增加I/O开销，降低查询效率。
通过外键关联维度表，可以实现数据规范化，减少冗余，确保数据一致性,并利用维度表的预聚合能力提升查询性能。
问题 2：什么是“退化维度”，它在事实表设计中有什么作用？
解答：
退化维度（Degenerate Dimension）是指那些没有对应独立维度表，而是直接存储在事实表中的业务标识符列，最常见的例子是订单号、发票号或交易流水号。
其作用主要体现在：
- 业务追踪：允许分析师在不连接维度表的情况下,直接通过订单号等唯一标识符查询特定业务事件的详细信息。
- 简化查询：对于需要按业务单据进行聚合或去重的分析场景，退化维度提供了直接的过滤和分组依据,避免了复杂的多表连接。
- 数据完整性：作为业务过程的唯一标识,有助于确保事实表记录的完整性和可追溯性。
