data-warehouse - 自然键和事实表

Question

我是维度建模的新手，我相信你们可以帮助我解决以下问题。

在生产系统中，我有一个事务表，例如销售表。唯一标识符是一个名为 SaleId 的主键。例子：

我的疑问是在对事实表进行建模时，SaleID 是否应该作为 NaturalKey 包含在事实表中？

Fact 表也应该有一个 SurrogateKey 吗？

请随时向我发送任何链接作为参考。提前致谢

Answer 1

从技术上讲，它可能不是一个自然键——它看起来确实是系统生成的。但是，有时将系统生成的 ID 存储在 Fact 中以用作退化维度是非常有效的。通常，在这些情况下，业务用户确实可以看到此系统生成的 ID（订单号、发票号、采购订单号等），或者没有其他有用的方法来识别可以有用地组合在一起的某些行.

如果您的 BI 解决方案的用户可能希望能够深入了解信息并通过销售来查看它，那么 SaleID 很可能是这种处理的良好候选者。想一想他们是否有任何其他方法可以达到这个水平 - 客户是否可以在同一天与两个不同的销售相关联？如果是这样，您的用户是否希望将它们视为两个单独的销售？您可能需要与他们交谈以了解对他们有用的内容。如果由于某种原因您无法得到明确的答案，我会说保留它-几乎没有伤害，如果不使用，您可以随时将其删除。

这是 Kimball 小组对退化维度的看法，以防你完全不清楚它们是如何工作的：

http://www.kimballgroup.com/2003/06/design-tip-46-another-look-at-degenerate-dimensions/

---

至于事实表代理键 - 我总是使用它们。正如 Kimball 的设计技巧 #81所指出的，它们有时很有用，而且我宁愿在开始时投入而不使用，也不愿后来意识到拥有它会很有用。第 2 点 - 您可能希望通过插入新行和删除旧行来进行更新 - 当然适用于我所做的工作。

Answer 2

事实表中对主键的要求取决于事实表的类型。从未更新的事务事实不需要它。定期快照可能不需要它，除非当前周期是迄今为止的度量。积累快照肯定需要它。