我是维度建模的新手，我相信你们可以帮助我解决以下疑问。
在生产系统中，我有一个事务表，例如销售表。唯一标识符是一个名为 SaleId 的主键。 示例:
我的疑问是在对事实表进行建模时，SaleID 是否应该作为 NaturalKey 包含在事实表中？
Fact 表也应该有一个 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/