我是不是正确实施了 SCD 类型 1 和 7

Posted 2023-03-29

【中文标题】我是不是正确实施了 SCD 类型 1 和 7

【英文标题】：Am I implementing SCD type 1 & 7 correctly我是否正确实施了 SCD 类型 1 和 7

【发布时间】：2020-08-31 18:09:46

【问题描述】：

SCD 类型 1

假设我已经基于来自操作系统的以下数据构建了 SCD 类型 1：

ID | CHANNEL_CODE | NAME | TYPE
1  |      A       |  X   |  0
2  |      B       |  Y   |  1

因为，Surrogate Keys are preferable even for SCD type 1，我们正在丢弃 ID 列并从自然键 (CHANNEL_CODE) 生成 SRK：

SRK | CHANNEL_CODE | NAME | TYPE
11  |      A       |  X   |  0
12  |      B       |  Y   |  1

意味着CHANNEL_CODE 预计永远不会改变，以防NAME 或TYPE 更新 - 发生覆盖。

这是 SCD 类型 1 的正确标准实现吗？

SCD 1 + 耐用键

自然密钥可能会因 sim 卡或信用卡更改、重复、源系统集成、业务原因等而更改。从Kimball's Design Tip #147，我知道问题已通过 durable srk 解决。

意味着，操作系统必须向我发送一个事件，例如：“从现在开始，CHANNEL_CODE=A 就是 CHANNEL_CODE=C”。所以我应该有以下数据（事实表包含两个 srks）：

DURABLE_SRK | SRK | CHANNEL_CODE | NAME | TYPE
    11      | 11  |      A       |  X   |  0
    12      | 12  |      B       |  Y   |  1
    11      | 13  |      C       |  X   |  0

仍更改为 NAME 或 TYPE 列将导致简单覆盖（没有新行）。

NAME 应在此处被SRK 或DURABLE_SRK 覆盖吗？还是 SCD 1 吗？

SCD 类型 7

据我了解，来自Kimball's Design Tip #152，SCD 7 = SCD 1 + durable key + SCD 2 (history for not natural key columns)。所以 SCD 类型 7 应该在每列更新时生成一个新行。比如NAME update from X to Z where CHANNEL_CODE=C:

DURABLE_SRK | SRK | CHANNEL_CODE | NAME | TYPE | EFFECTIVE_START_DATE | EXPIDATION_DATE | IS_CURRENT_IND
    11      | 11  |      A       |  X   |  0   |      2020-05-02      |    2020-06-12   | False
    12      | 12  |      B       |  Y   |  1   |      2020-01-12      |    2100-01-01   | True
    11      | 13  |      C       |  X   |  0   |      2020-06-12      |    2020-08-15   | False
    11      | 13  |      C       |  Z   |  0   |      2020-08-15      |    2100-01-01   | True

这是 SCD 类型 7 的正确实现吗？

【参考方案1】：

SCD TYPE1

是的，这是正确的，尽管不需要丢弃 ID，我可能会保留它，因为它可能有助于您的 ETL 和调试目的，因为它可以轻松识别源系统中的相应记录（请参阅下一个以段落为例）。

SCD 1 + 耐用钥匙

如果这是 SCD1，那么您的示例不正确。如果同一源记录上的通道代码已更改，则它将覆盖 Dimension 表中的记录，而不是插入新记录。这是一个很好的例子，说明了为什么应该保留 ID，因为它使维度中的记录与源的关系变得显而易见。对于 SCD1，SK 和 Durable SK 在定义上几乎是同一个东西。

我意识到与真实场景相比，您的示例可能会被简化，但我建议 Channel Code 是真正的自然键，因此永远不会改变：不同的 Channel Code 将意味着不同的记录。只有当源记录中没有真正的唯一业务标识符时，自然键才会真正改变，例如一个人可能有一个真正的唯一标识符，例如社会安全号码（它永远不会改变），但如果它不可用，他们可能会通过名字、姓氏和电子邮件地址来识别——其中任何一个都可能改变，因此不是真实的自然键 - 这将是一个包含 Durable SK 的好案例。

SCD 类型 7

对于这种类型，维度表完全是 SCD 类型 2，并且包括一个 Durable SK。 SCD1 方面可以被认为是虚拟的，因为它被实现为当前标志 = True 的维度上的视图。任何加入该表的 Fact 表都有两个 FK - 一个保存事件发生时适用的行的 Dimension SK（标准 SCD2 逻辑），另一个保存 Durable SK 并引用视图（以获得类似 SCD1记录）

【讨论】：

为了构建SCD，我们必须以某种方式加入“旧”和“新”记录。您能否澄清一下 - 如果有 ID 列，通过 CHANNEL_CODE 加入是否有意义？如果是，那为什么？