企业官网建设流程全解析

        维度模型是数据仓库大师 Ralph Kimball 提出的一种面向分析的逻辑模型。其核心思想是：将数据组织成“事实”和“维度”两部分，通过星型或雪花型结构，提供高性能、易理解的查询体验。

一、事实表（Fact Table）

        事实表存储业务过程的可度量的事件或指标（如销售额、数量、金额），以及关联维度表的外键。每一行对应一个业务事件或一个度量快照。

1. 事实表的类型（按粒度划分）

事实表有四种基本类型，适用于不同的分析场景：

（1）事务事实表：记录每个业务过程的原子操作事件，以最细粒度保存每条事务。一旦事务提交，数据即插入且不再更改。适用于对灵活性和细节程度要求最高的分析场景，例如每一笔订单记录、每一笔支付记录。

（2）周期快照事实表：按固定周期（每天、每周、每月）对某个状态拍快照。适用于需要跟踪存量或状态型指标的场景，比如“每月底的库存量”或“每天的账户余额”。它关注的是某个时间点上的累积状态，而非单次事务。

（3）累积快照事实表：跟踪一个实体从开始到结束的整个生命周期，记录多个关键业务过程的日期和状态。典型的例子是订单全链路：创建订单 → 买家付款 → 卖家发货 → 买家确认收货，每个关键节点都作为字段存在同一行中，便于计算各环节的时间间隔。与事务事实表不同，累积快照事实表会随着业务过程的推进而被更新。

（4）无事实的事实表：是一种特殊的事实表，它没有数值度量，只包含维度的外键组合，用于记录事件是否发生。每一行代表一个事实：某个组合的维度在某个时间点存在。学生考勤表：记录某天某学生是否出勤。

快速选择指引：

• 事务明细 → 事务事实表

• 周期性状态 → 周期快照事实表

• 业务流程跟踪 → 累积快照事实表

• 仅记录存在性 → 无事实事实表

2. 事实表的实现方式

3. 维度退化（Degenerate Dimension）

        退化维度是指原本应该作为维度的属性，因为本身没有更多描述信息，干脆直接留在事实表中，不为其单独建立维度表。

展开来讲，满足以下条件时，就适用维度退化策略：

条件 1：它是业务操作产生的“自然键”
        这个标识符不是数据仓库生成的代理键，而是来自源系统的业务单据号码，比如交易流水号、订单号、发票号、运单号、支付流水号等。

条件 2：它除了自己，没有其他描述信息
        这是最核心的判断点。你可以问自己：如果为这个字段单独建一张维度表，表里除了这个 ID 本身，还能有什么列？如果答案几乎是“什么都没有”，那它就适合退化。

        比如：订单号 —— 没有任何“订单号类别”“订单号状态”这类有意义的属性（订单自身的状态是事实，不是订单号的属性）。

核心区分：标识的属性 vs. 业务的属性

• A类. 用来描述“订单号这个符号本身”的属性
         这指的是独立于任何业务含义，纯粹描述这个字符串物理或逻辑特征的属性。比如：这个号码是几位数？它是什么编码规则生成的？它属于哪种单据类型？

  • 结论：对于订单号，这类属性几乎永远不存在或无需分析。

• B类. 用来描述“订单这个业务事件”的属性
         这指的是订单这个业务事件的属性：订单金额、下单时间、订单状态、支付方式、收货地址、用户ID等等。

  • 结论：这些都不是订单号的属性，而是订单本身的属性。

        退化维度的判断准则，针对的是A类属性。一个标识符之所以被“退化”，是因为它在仓库中找不到能作为“维度属性”存在的A类信息。

条件 3：它在事实表中几乎就是“主键”
退化维度通常和事实表的粒度高度对应：

• 在事务事实表中，它往往就是该业务事件的唯一标识（或组合唯一标识的一部分），例如一笔交易记录对应一个交易流水号。

• 在累积快照事实表中，它是跟踪整个生命周期的业务主键（如一个订单号贯穿全部里程碑），每一行代表一个业务实例。

条件 4：分析时需要用它做分组、过滤、钻透
        退化维度虽然不参与求和，但常常是 BI 用户下钻最细粒度明细的入口，比如“按订单号查询所有明细”“追踪某个运单的全链路状态”。这种场景下直接用它过滤，远比 Join 一张空洞的维度表高效。

举例：