问数据仓库中代理键与组合键的比较

EN

这是因为很少通过维度以外的任何东西引用事实数据表。

数据仓库的效率与其加载数据并在以后访问数据的能力一样有效。正如Ronnis所解释的；我们很少需要在事实表中引用组合键组合的能力来执行任何操作；在加载时，如果我们有一个主键，那么加载需要更长的时间，如果我们需要通过主键访问记录，这是很好的；否则这是浪费时间。

考虑以下事实

CustomerId
Date
PartId
NumberofOrders
OrderQuantity
InvoiceAmount

键为CustomerId、Date、PartId

为键的组合添加一条记录不会影响对该事实表所做的任何分析，因此拥有一个主键可能是多余的。

考虑以下事实

CostCenterId
DivisionId
Month
DepartmentId
OpeningBalance
Credits
Debits

有两种类型的设计是可能的；一种是当您只需要此组合的一条记录时；在这种情况下，您将定义一个主键

另一种设计也是可能的；在处理事务时，在每月初创建期初余额记录，将期初余额填充为零，在这种情况下，您可以有多条记录

底线是确保您有一个可管理的记录数量来汇总，更重要的是确保您的加载速度更快。

我希望这能解释不使用主键的设计趋势

取决于您最常使用的报告/应用程序用例。在大多数数据仓库中，最终都会使用dim表中的代理键作为FK。事实上，您可能有重复的(部分行)，并且出于完全合法的原因。因此，除非您确实需要，否则通常不会定义PK。

根据您的RDBMS技术及其在索引、PK /主索引端的能力，您将定义一个最适合您的数据仓库的最佳PDM (物理数据模型)。例如，在Teradata中，我将在用于我的目的的事实表中定义一个主索引(而不是PK)，并且其中可能没有完整的组合键。在我们将每个事件记录为事务的事件事实表或网络活动事实表中，事件ID将足以作为主索引，以确保数据的最佳分布，从而获得更好的性能。如果大多数报告用例根据客户id或产品id或站点id或任何经常使用的ID查询此表，则可以定义单独的索引来优化报告。然后，您可以在这样的ID上定义类似的索引，只要它出现在其他事实或维度中，就可以为您提供最佳访问路径。

这在很大程度上取决于您的用例、rdbms功能和访问路径设计，以便巧妙地定义PDM。

如果是代理键，请参考我的帖子作为指南Managing surrogate keys in a data warehouse