如何解决我是否正确实施了类型1和7的SCD
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列，并根据自然键（SRK）生成CHANNEL_CODE：
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开始，我知道问题是通过耐用解决的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'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类的正确实现吗？
解决方法
SCD TYPE1
是的，这是正确的，尽管不需要丢弃ID，我可能会保留它，因为它可以帮助您的ETL和调试目的，因为它可以轻松识别源系统中的相应记录（请参阅下一个）例如）
SCD 1 +耐用密钥
如果这将是SCD1，则您的示例不正确。如果同一源记录上的通道代码已更改，则它将覆盖Dimension表中的记录，而不插入新记录。这是一个为什么要保留ID的好例子，因为它可以使维记录与源之间的关系变得显而易见。就SCD1而言，从定义上看，SK和耐用SK几乎是同一回事。
我意识到与实际情况相比，您的示例可以简化，但是我建议频道代码是真正的自然键，因此永远不会更改：不同的频道代码将意味着不同的记录。仅当源记录中没有真正唯一的业务标识符时，自然键才会真正更改。一个人可能具有真正的唯一标识符，例如社会保险号（从未更改），但是如果无法使用，则可以通过名字，姓氏和电子邮件地址来识别-可能会更改，因此不是真实的自然键-这将是包括耐用SK的一个很好的例子。
SCD类型7
对于此类型，“尺寸”表完全是SCD类型2，并包含一个耐用的SK。可以将SCD1方面视为虚拟方面，因为它是在“当前标志= True”的维度视图上实现的。连接到该表的任何Fact表都有两个FK-一个FK持有事件发生时适用的行的Dimension SK（标准SCD2逻辑），另一个持有Durable SK并引用View（以获取类似于SCD1的表）记录）
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。