我是维度建模的新手我相信你们可以帮助我解决以下疑问。
在生产系统中，我有一个事务表，例如销售表。唯一标识符是一个名为 SaleId 的主键。
例子:
我的疑问是在对事实表进行建模时，是否应该将 SaleID 作为 NaturalKey 包含在事实表中？
事实表也应该有一个 SurrogateKey 吗？
请随时向我发送任何链接作为引用。
提前致谢
最佳答案
从技术上讲，它可能不是自然键——它看起来确实是系统生成的。但是，有时将系统生成的 ID 存储在 Fact 中以用作退化维度是非常有效的。通常，在这些情况下，业务用户确实可以看到此系统生成的 ID(订单号、发票号、采购订单号等)，或者没有其他有用的方法来识别可以有用地组合在一起的某些行.
如果您的 BI 解决方案的用户可能希望能够深入了解信息并通过销售查看它，那么 SaleID 很可能是这种处理的一个很好的候选者。想一想是否还有其他方法可以让他们达到这个水平 - 一个客户是否可以在同一天与两个不同的销售相关联？如果是这样，您的用户是否希望将它们视为两个独立的销售？您可能需要与他们交谈，以了解对他们有用的内容。如果由于某种原因你不能得到明确的答案，我会说保留它 - 没有什么害处，如果不使用它，你可以随时删除它。
这是 Kimball 小组对退化维度的看法，以防您完全不清楚它们是如何工作的:
http://www.kimballgroup.com/2003/06/design-tip-46-another-look-at-degenerate-dimensions/
至于事实表代理键 - 我总是使用它们。正如 Kimball 的 Design Tip #81 指出的那样，它们有时很有用，这是我宁愿在开始时放入而不使用的那种东西，也不愿后来意识到拥有它会很有用。第 2 点 - 您可能希望通过插入新行和删除旧行来进行更新 - 当然适用于我所做的工作。
关于data-warehouse - 自然键和事实表，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/29920984/