SCD类型1
假设我在来自操作系统的以下数据上构建了SCD类型1：
ID | CHANNEL_CODE | NAME | TYPE
1 | A | X | 0
2 | B | Y | 1
因为，即使对于SCD类型1，代理密钥也是优选的，所以我们放弃了ID列，并从自然密钥(CHANNEL_CODE(生成SRK：
SRK | CHANNEL_CODE | NAME | TYPE
11 | A | X | 0
12 | B | Y | 1
意味着在发生NAME或TYPE更新-覆盖的情况下，CHANNEL_CODE预计永远不会更改。
这是SCD类型1的正确标准实现吗
SCD 1+耐用钥匙
自然密钥可能会因为sim卡或信用卡更改、重复、源系统集成、业务原因等而更改。根据Kimball的设计提示#147，我知道使用耐用srk可以解决这个问题。
意味着，操作系统必须向我发送一个事件，比如：；从现在起，CHANNEL_CODE＝A是CHANNEL_CODE＝C〃；。所以我应该有以下数据(事实表包含两个srk(：
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的设计技巧#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的正确实现吗
SCD TYPE1
是的，这是正确的，尽管没有必要丢弃ID，我可能会保留它，因为它可能有助于ETL和调试目的，因为它允许轻松识别源系统中的相应记录(见下一段的示例(。
SCD1+耐用钥匙
如果这是SCD1，那么您的示例是不正确的。如果同一源记录上的通道代码已更改，则它将覆盖维度表中的记录，而不是插入新记录。这是一个很好的例子，说明了为什么应该保留ID，因为它清楚地表明了维度中的记录与源的关系。对于SCD1来说，SK和耐用SK几乎是同一回事。
我意识到，与现实世界的场景相比，你的例子可能会被简化，但我认为频道代码是一个真正的自然密钥，因此永远不会改变：不同的频道代码意味着不同的记录。只有当源记录中没有真正的唯一商业标识符时，自然密钥才会真正改变，例如，一个人可能有一个真正的唯一标识符，如社会安全号码(永远不会改变(，但如果这不可用，他们可能会通过名字来识别，姓氏和电子邮件地址-其中任何一个都可能更改，因此不是真正的自然密钥-这将是一个很好的例子，包括耐用的SK.
SCD类型7
对于这种类型，Dimension表完全是SCD type 2，并包括耐用SK。SCD1方面可以被认为是虚拟的，因为它被实现为维度上的视图，其中Current Flag=True。任何连接到此表的事实表都有两个FK-一个保存事件发生时适用行的维度SK(标准SCD2逻辑(，另一个保存耐用SK并引用视图(以获得类似SCD1的记录(