为什么维度建模中的事实表需要（不）主键？

Question

我听过一些在事实表上不需要pk的引用。我相信每张桌子都应该有一个PK。

如果没有pk和10个以上的外键，一个人如何理解事实表中的一行。

Answer 1

主键是

...但是，数据库级别中的primary key约束强制要求 。

如果您考虑这一点，从技术上讲，唯一键或主键是唯一定义每行特征的键。它可以由该实体的多个属性组成。现在，在Fact表的情况下，从其他维度表流入的foreign keys已经充当复合主键。并且这些外键组合可以唯一地识别事实表中的每个记录。因此，此外键组合是事实表的 主键。

为什么不是代理密钥？

现在，如果您愿意，可以为事实表定义一个代理键。但是，这个目的是什么？您永远不会从引用其代理键的事实表中检索一条记录（而是使用索引）。您不会使用该代理键将事实与其他表联系起来。这样的代理键将完全浪费数据库中的空间。

实施数据库约束

在数据库级别定义此概念主键时，数据库需要确保在通过它执行的任何DML操作中不会违反此约束。确保此约束是数据库的开销。对于OLTP系统而言，它可能无关紧要，但对于批量加载数据的大型OLAP系统，这可能会导致严重的性能处罚。此外，为什么您希望数据库在数据加载阶段（通常通过ETL编码）确保相同时确保约束的完整性。

Answer 2

你是完全正确的，原则上一个事实表应该有一把钥匙。从数据建模的角度来看，这是必需的。在实现中，数据库中的关键约束通常需要索引。创建和维护索引的开销是这样的，“关键”属性的唯一性有时通过控制集成层（“ETL过程”）而不是数据库中的约束来维护。

在实际应用中，在数据库中创建密钥约束是有意义的。如果未在数据库中明确定义密钥，则应该为用户清楚地记录密钥，以便他们能够理解数据的含义。

Answer 3

正如您在其他答案中所看到的那样，不需要主键约束，事实表代理键在物理级别上可能会有所帮助。

以下是事实表代理密钥的Kimball设计技巧：

在某些情况下，将替代密钥分配给 事实表中的行是有益的：

1. 有时，组织的业务规则合法地允许事实表存在多个相同的行。通常作为 设计师，您尝试通过搜索资源不惜一切代价避免这种情况 某种交易时间戳的系统，使行 独特。但是偶尔您会被迫接受这种不受欢迎的 输入。在这些情况下，有必要创建一个代理 事实表的键，以允许加载相同的行。

2. 用于更新事实行的某些ETL技术仅在将替代密钥分配给事实行时才可行。具体来说，一个 向事实行加载更新的技术是将行插入 更新为新行，然后第二步删除原始行 作为一次交易。 ETL中此技术的优点 观点是改善负载性能，改善恢复 功能和改进的审核功能。代理键 事实表行是必需的，因为多个相同的主键将 更新事实行的旧版本和新版本通常存在 在插入更新行和删除行之间 老行。

3. 类似的ETL要求是确切确定要暂停的加载作业，以恢复加载或完全放回该作业。 顺序分配的代理密钥使此任务变得简单。

（来源：Design Tip #81 Fact Table Surrogate Key）

Answer 4

由于事实表中有外键，这些外键来自其他维度的主键，每行在每行中具有唯一值以标识事实表的每个记录，因此，外键本身就是主键。 / p>