缓慢变化维度：管理数据仓库中的历史数据

数据仓库承诺提供历史分析，但维度数据却不愿保持静止。客户搬迁、产品变更类别、销售员调到新区域。这些变化看似简单，直到你问：历史报表应该反映旧状态还是新状态？ 传统数据库通过更新处理变化——用新值覆写旧值。这对专注于当前状态的事务系统有效，但会破坏使数据仓库有价值的历史背景。当销售员从加州调到伊利诺伊州时，他们过去的销售额应该出现在加州还是伊利诺伊州的区域报表中？ 缓慢变化维度（SCD）解决了这个挑战。与快速变化的事务数据（客户 ID、数量、价格）不同，维度属性如位置、名称和类别的变化频率较低但不可预测。SCD 中的”缓慢”并不意味着变化罕见，而是指它们不是正常事务流程的一部分。 Ralph Kimball 的《数据仓库工具包》推广了处理这些变化的分类系统：类型 0 到 7。每种类型代表历史准确性、数据复杂性和查询性能之间的不同权衡。类型 1 牺牲历史以换取简单性。类型 2 以复杂性为代价保留完整历史。类型 6 结合多种方法以获得最大灵活性。 挑战不仅限于技术实现。SCD 必须维护事实表和维度表之间的引用完整性。销售事实表链接到供应商维度。当供应商搬迁时，历史销售记录必须仍然连接到正确的供应商信息，而不破坏数据库关系。 本文探讨每种 SCD 类型，检视其权衡，并提供针对不同场景选择正确方法的指导。

历史数据问题

在探索解决方案之前，理解问题可以揭示为什么维度变化会产生复杂性。

供应商搬迁场景

考虑一个跟踪供应商关系的数据仓库：

引用完整性挑战

数据库关系使事情变得更加复杂：

为什么”缓慢变化”很重要

缓慢变化和快速变化数据之间的区别至关重要：

SCD 类型分类

Ralph Kimball 的分类系统提供了处理维度变化的结构化方法。

类型系统概述

选择因素

正确的类型取决于具体需求：

类型 0：保留原始值

某些属性根据定义永不改变。

不可变属性

类型 0 适用于具有持久值的属性：

日期维度

日期维度通常对大多数属性使用类型 0：

CREATE TABLE Date_Dimension (
    Date_Key INT PRIMARY KEY,
    Full_Date DATE,
    Day_Of_Week VARCHAR(10),
    Month_Name VARCHAR(10),
    Quarter INT,
    Year INT,
    Is_Holiday BOOLEAN
);

业务价值

类型 0 提供清晰度和保护：

类型 1：覆写

最简单的方法：用新值替换旧值。

类型 1 如何运作

类型 1 就地更新记录： 初始状态：

UPDATE Supplier
SET Supplier_State = 'IL'
WHERE Supplier_Code = 'ABC';

旧值消失。新值取而代之。没有历史，没有复杂性。

何时类型 1 有意义

类型 1 适用于特定场景：

简单性的代价

类型 1 的简单性伴随着重大限制：

聚合重新计算问题

类型 1 产生级联更新：

实现考量

类型 1 需要仔细规划：

类型 2：添加行

最常见的 SCD 方法：为每次变化创建新记录。

类型 2 如何运作

类型 2 通过多笔记录保留完整历史： 初始状态：

实现变化

类型 2 有几种实现模式：

事实表集成

类型 2 的威力来自事实表集成：

查询模式

类型 2 支持多种查询模式： 当前状态查询：

SELECT 
    s.Supplier_Name,
    s.Supplier_State,
    SUM(f.Sales_Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier s ON f.Supplier_Key = s.Supplier_Key
WHERE s.Current_Flag = 'Y'
GROUP BY s.Supplier_Name, s.Supplier_State;

历史状态查询：

SELECT 
    s.Supplier_Name,
    s.Supplier_State,
    SUM(f.Sales_Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier s ON f.Supplier_Key = s.Supplier_Key
WHERE f.Sale_Date BETWEEN s.Start_Date AND s.End_Date
GROUP BY s.Supplier_Name, s.Supplier_State;

时间点查询：

SELECT 
    s.Supplier_Name,
    s.Supplier_State
FROM Supplier s
WHERE s.Supplier_Code = 'ABC'
  AND '2003-06-15' BETWEEN s.Start_Date AND COALESCE(s.End_Date, '9999-12-31');

类型 2 挑战

尽管很受欢迎，类型 2 仍有缺点：

追溯变化问题

类型 2 最大的挑战出现在维度模型变化时：

最佳实践

类型 2 需要纪律才能发挥最佳效果：

类型 3：添加属性

类型 3 通过额外列跟踪有限历史。

类型 3 如何运作

类型 3 不是添加行，而是添加列： 初始状态：

有限历史权衡

类型 3 提供固定的历史深度：

查询简单性

类型 3 启用直接的查询：

-- 当前状态分析
SELECT 
    Current_State,
    SUM(Sales_Amount) as Total_Sales
FROM Supplier s
JOIN Fact_Sales f ON s.Supplier_Key = f.Supplier_Key
GROUP BY Current_State;
-- 原始状态分析
SELECT 
    Original_State,
    SUM(Sales_Amount) as Total_Sales
FROM Supplier s
JOIN Fact_Sales f ON s.Supplier_Key = f.Supplier_Key
GROUP BY Original_State;
-- 转换分析
SELECT 
    Original_State,
    Current_State,
    COUNT(*) as Suppliers_Moved
FROM Supplier
WHERE Original_State != Current_State
GROUP BY Original_State, Current_State;

无日期范围检查。无当前标志。简单的列引用。

何时类型 3 有意义

类型 3 适用于特定的分析需求：

前一个值变化

另一种方法跟踪最近的变化：

类型 3 限制

固定结构产生问题：

混合列方法

类型 3 通常与其他类型结合：

类型 4：添加历史表

类型 4 将当前和历史数据分离到不同的表中。

类型 4 如何运作

类型 4 使用两个表：一个用于当前状态，一个用于历史： Supplier 表（当前）：

数据库审计模式

类型 4 类似于数据库审计表：

事实表集成

类型 4 的独特功能：事实可以引用两个表：

CREATE TABLE Fact_Sales (
    Sale_ID INT PRIMARY KEY,
    Sale_Date DATE,
    Current_Supplier_Key INT,  -- 引用 Supplier
    Historical_Supplier_Key INT, -- 引用 Supplier_History
    Amount DECIMAL(10,2)
);

查询模式

类型 4 启用不同的分析视角： 当前状态分析：

SELECT 
    s.Supplier_State,
    SUM(f.Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier s ON f.Current_Supplier_Key = s.Supplier_Key
GROUP BY s.Supplier_State;

此查询显示按当前供应商州分组的所有销售，无论销售何时发生。 历史状态分析：

SELECT 
    sh.Supplier_State,
    SUM(f.Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier_History sh ON f.Historical_Supplier_Key = sh.Supplier_Key
GROUP BY sh.Supplier_State;

此查询显示按销售时供应商州分组的销售。

ETL 考量

类型 4 需要仔细的 ETL 设计：

何时类型 4 有意义

类型 4 适合特定场景：

类型 4 挑战

双表方法产生复杂性：

维护策略

类型 4 需要持续维护：

类型 6：组合方法

类型 6 结合类型 1、2 和 3（1 + 2 + 3 = 6）以获得最大灵活性。

类型 6 如何运作

类型 6 使用类型 2 的行版本控制，加上类型 3 的当前值列和类型 1 的覆写策略： 初始状态：

• 类型 2：创建新行（Row_Key 2）
• 类型 3：添加 Current_State 列
• 类型 1：Row_Key 1 中的 Current_State 覆写为 IL 第二次搬迁后： | Supplier_Key | Row_Key | Supplier_Code | Supplier_Name | Current_State | Historical_State | Start_Date | End_Date | Current_Flag | |--------------|---------|---------------|---------------|---------------|------------------|------------|----------|--------------| | 123 | 1 | ABC | Acme Supply Co | NY | CA | 2000-01-01 | 2004-12-22 | N | | 123 | 2 | ABC | Acme Supply Co | NY | IL | 2004-12-22 | 2008-02-04 | N | | 123 | 3 | ABC | Acme Supply Co | NY | NY | 2008-02-04 | 9999-12-31 | Y | 所有行现在显示 Current_State = NY（类型 1 覆写），而 Historical_State 保留每个时间段内当前的值（类型 2 历史）。

三种技术的结合

类型 6 将每种技术应用于不同方面：

查询灵活性

类型 6 支持三种查询模式： 当前状态查询：

SELECT 
    s.Current_State,
    SUM(f.Sales_Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier s ON f.Supplier_Key = s.Row_Key
GROUP BY s.Current_State;

显示按当前供应商州分组的所有销售。简单连接，无日期筛选。 历史状态查询：

SELECT 
    s.Historical_State,
    SUM(f.Sales_Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier s ON f.Supplier_Key = s.Row_Key
GROUP BY s.Historical_State;

显示按销售发生时当前的州分组的销售。同样简单，不需要日期筛选。 时间点查询：

SELECT 
    s.Supplier_Name,
    s.Historical_State
FROM Supplier s
WHERE s.Supplier_Code = 'ABC'
  AND '2005-06-15' BETWEEN s.Start_Date AND s.End_Date;

检索特定日期时存在的维度状态。

Kimball 的”具有单一版本覆盖的不可预测变化”

Ralph Kimball 将类型 6 称为”具有单一版本覆盖的不可预测变化”：

实现复杂性

类型 6 是最复杂的 SCD 类型：

何时类型 6 有意义

类型 6 在特定场景中证明其复杂性是合理的：

类型 6 最佳实践

管理类型 6 需要纪律：

CREATE VIEW Supplier_With_Current AS
SELECT 
    h.*,
    c.Supplier_State as Current_State
FROM Supplier h
JOIN Supplier c ON h.Supplier_Code = c.Supplier_Code
WHERE c.Current_Flag = 'Y';

此视图使每个历史行都能访问当前状态，而无需冗余存储。

类型 7：双键策略

类型 7 在事实表中放置代理键和自然键，以获得最大查询灵活性。

类型 7 如何运作

类型 7 使用类型 2 维度结构，但在事实中存储两个键： Supplier 维度（类型 2）：

CREATE TABLE Fact_Sales (
    Sale_ID INT PRIMARY KEY,
    Sale_Date DATE,
    Supplier_Key INT,        -- 代理键（历史）
    Supplier_Code VARCHAR(10), -- 自然键
    Amount DECIMAL(10,2)
);

事实存储事务时当前的代理键（Supplier_Key）和识别所有版本实体的自然键（Supplier_Code）。

查询灵活性

类型 7 启用三种查询模式，无需日期逻辑： 历史状态查询：

SELECT 
    s.Supplier_State,
    SUM(f.Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier s ON f.Supplier_Key = s.Supplier_Key
GROUP BY s.Supplier_State;

在代理键上连接显示历史状态。2003 年的销售连接到 Supplier_Key 123（CA），显示加州销售。 当前状态查询：

SELECT 
    s.Supplier_State,
    SUM(f.Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier s ON f.Supplier_Code = s.Supplier_Code
WHERE s.Current_Flag = 'Y'
GROUP BY s.Supplier_State;

在自然键上连接并使用当前标志显示当前状态。ABC 的所有销售连接到 Supplier_Key 125（NY），显示纽约销售。 时间点查询：

SELECT 
    s.Supplier_State,
    SUM(f.Amount) as Total_Sales
FROM Fact_Sales f
JOIN Supplier s ON f.Supplier_Code = s.Supplier_Code
WHERE f.Sale_Date BETWEEN s.Start_Date AND s.End_Date
GROUP BY s.Supplier_State;

在自然键上连接并使用日期范围显示任何时间点的状态。

相对于类型 2 的优势

类型 7 为类型 2 增加了灵活性：

追溯变化优势

类型 7 最大的优势出现在维度演变时：

类型 7 挑战

双键方法有重大缺点：

引用完整性问题

类型 7 最严重的问题是无法强制执行引用完整性：

何时类型 7 有意义

类型 7 适合特定场景：

类型 7 最佳实践

类型 7 需要仔细实现：

类型 7 vs 类型 6

两者都提供灵活性，但通过不同机制：

选择正确的类型

不同的维度和属性需要不同的 SCD 类型。

决策框架

选择适当的 SCD 类型需要评估多个因素：

类型选择矩阵

选择 SCD 类型的实用指南：

混合方法

大多数数据仓库使用多种 SCD 类型：

按行业的常见模式

不同行业有典型的 SCD 模式：

性能考量

SCD 类型影响查询和 ETL 性能：

存储考量

不同类型有不同的存储特性：

迁移策略

变更 SCD 类型需要规划：

要避免的反模式

常见的 SCD 错误：

实用建议

实际实现的指导方针：

结论

缓慢变化维度代表数据仓库的基本挑战之一：在历史准确性与实际实现限制之间取得平衡。在 SCD 类型之间的选择不是寻找”最佳”方法——而是将技术与业务需求、团队能力和系统限制相匹配。 通过 SCD 类型的旅程揭示了重要的教训： 简单性有代价：类型 1 的简单性以失去历史为代价。在设计期间看似微小的权衡，当业务需求演变时会成为重大限制。“我们 2005 年在加州的销售额是多少？“这个问题在供应商搬迁且类型 1 覆写其位置后变得无法回答。历史数据一旦失去，就无法恢复。 历史需要结构：类型 2 的受欢迎程度源于其平衡的方法。完整的历史保留、合理的查询复杂性和广为理解的实现使其成为默认选择。为变化创建新行、维护时间列和使用代理键的模式已在无数数据仓库中证明了自己。 灵活性需要复杂性：类型 6 和类型 7 提供最大灵活性，但需要复杂的 ETL 流程和仔细的查询设计。只有当更简单的方法证明不足时，复杂性才是合理的。从类型 2 开始并随着需求的出现演变到更复杂的类型可以防止过早优化。 情境很重要：没有单一的 SCD 类型适合所有场景。客户地址可能需要类型 2 以获得历史准确性，而电话号码使用类型 1 以获得简单性。产品类别可能需要类型 2，而产品描述使用类型 1。在单一数据仓库内——甚至在单一维度内——混合类型的能力实现了实用的解决方案。 权衡是不可避免的：每种 SCD 类型代表竞争关注点之间的权衡：

• 历史准确性 vs. 查询简单性
• 存储效率 vs. 时间精确度
• ETL 复杂性 vs. 查询灵活性
• 当前状态访问 vs. 历史状态访问 理解这些权衡能够做出明智的决策，而不是盲目遵循模式。 实现纪律：成功的 SCD 实现需要纪律。一致的日期处理、清晰的命名惯例、全面的文档和强大的 ETL 流程将有效的实现与有问题的实现区分开来。技术模式不如其应用的严谨性重要。 SCD 类型分类系统提供了讨论维度变化策略的词汇。类型 0 到类型 7 不是严格的规则，而是工具包。艺术在于为每种情况选择正确的工具，在适当时组合技术，并保持纪律以一致地实现所选方法。 现代数据仓库通常使用类型 2 作为基础，为历史不重要的属性添加类型 1，仅在特定需求证明额外复杂性合理时才使用类型 6 或类型 7。这种务实的方法平衡了历史准确性、查询性能、存储效率和可维护性的竞争需求。 成功的最终衡量标准不是您选择哪种 SCD 类型，而是您的维度模型是否能让业务准确回答其问题。当历史报表反映实际历史状态，当当前报表显示当前状态，并且两者之间的区别清晰且有意时，无论采用哪种特定类型，SCD 实现都是成功的。 随着数据仓库的演变和业务需求的变化，SCD 策略可能需要调整。在类型之间迁移的灵活性、记录决策的纪律，以及在可能时选择简单性而非复杂性的智慧，比任何特定的技术选择更能决定长期成功。