自然关键和事实表

时间:2015-04-28 13:31:01

标签: data-warehouse business-intelligence dimensional-modeling fact-table natural-key

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

在生产系统中,我有一个事务表,例如sales表。唯一标识符是一个名为SaleId的主键。 例如:

enter image description here

我怀疑是在对事实表进行建模时,SaleID是否应作为NaturalKey包含在事实表中?

enter image description here

Fact表还应该有SurrogateKey吗?

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

2 个答案:

答案 0 :(得分:4)

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

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

以下是Kimball集团对Degenerate Dimensions的看法,以防您对它们的工作方式一无所知:

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

就Fact表代理键而言 - 我总是使用它们。正如Kimball的Design Tip #81指出的那样,它们有时是有用的,而且它是我在开始时宁愿放入的那种东西而不是使用而不是稍后意识到它会有用。第2点 - 您可能希望通过插入新行和删除旧行来进行更新 - 当然适用于我已完成的工作。

答案 1 :(得分:4)

事实表中对主键的要求取决于事实表的类型。永远不会更新的交易事实不需要它。定期快照可能不需要它,除非当前时段是迄今为止的度量。累积快照肯定需要它。