Database design 为什么在维度建模中事实表上需要（不需要）主键？

我听过一些参考资料，事实表中不需要pk。我相信每一张桌子都应该有一个pk

---

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

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

---

只要可行，在数据库中创建键约束是有意义的。如果数据库中没有明确定义密钥，那么应该为用户清楚地记录该密钥，以便他们能够理解数据的含义。

主键在那里

。。。但是在数据库级别强制执行

主键

约束不是必需的

仔细想想，从技术上讲，唯一键或主键是唯一定义每行特征的键。它可以由该实体的多个属性组成。现在，在事实表的情况下，从其他维度表一起流入的

外键已经充当复合主键。这些外键组合可以唯一地标识事实表中的每个记录。因此，这个外键组合是事实表的主键

那么为什么不使用代理密钥呢？

现在，如果需要，可以为事实表定义一个代理键。但这有什么用呢？您永远不会从引用其代理键的事实表中检索一条记录（而是使用索引）。也不打算使用该代理键将事实与其他表连接起来。这样的代理密钥将完全浪费数据库中的空间

强制执行数据库约束

在数据库级别定义此概念主键时，数据库需要确保在对其执行的任何DML操作中都不会违反此约束。确保此约束是数据库的开销。对于OLTP系统来说，这可能无关紧要，但对于批量加载数据的大型OLAP系统来说，这可能会导致显著的性能损失。此外，在数据加载阶段（通常通过ETL编码）可以确保约束的完整性时，为什么要让数据库确保约束的完整性呢？
正如您在其他ANSWE中所读到的，主键约束不是必需的，事实表代理键在物理级别可能会有所帮助

下面是事实表代理键的Kimball设计提示：

将代理密钥分配给
事实表中的行是有益的：

有时，组织的业务规则合法地允许事实表存在多个相同的行。通常作为
designer，您可以通过搜索源代码不惜一切代价避免这种情况
系统为某种事务时间戳生成行
独一无二。但有时你不得不接受这种不受欢迎的观点
输入。在这些情况下，有必要创建代理
键，以允许加载相同的行


某些用于更新事实行的ETL技术只有在为事实行分配代理键时才可行。具体来说，一个
将更新加载到事实行的技术是插入要更新的行
更新为新行，然后作为第二步删除原始行
作为单一交易。该技术的优点来自ETL
透视图包括改进的负载性能、改进的恢复
能力和改进的审计能力。的代理项键
事实表行是必需的，因为需要多个相同的主键
通常存在更新事实行的旧版本和新版本
插入更新的行和删除
老一排


一个类似的ETL要求是确定加载作业被挂起的确切位置，以恢复加载或完全放回作业。
顺序分配的代理项键使此任务变得简单


（来源：）
因为事实表中有外键，这些外键来自其他维度的主键，在每行中都有唯一的值来标识事实表的每个记录，所以这样外键本身就充当主键。
这是一个比我更好的答案。我想说的是，有时有理由为事实表创建代理键。代理可以帮助执行某些ETL操作（更新和删除），还可以支持分区/归档/存储策略。当然，您还应该有一个“业务密钥”（通常是复合密钥）。只要事实表中使用的所有FK都是其他表中的PK，这是准确的，但如果您使用维度视图和/或事实联合（例如更改粒度），则唯一密钥可能会在事实表中重复，例如同一个人在同一天支付两次，在同一家餐厅。实际上，SK表并不像上面提到的那样毫无价值。它取决于DWH体系结构、约束和业务需求；例如，当我们谈论记录客户FK、仓库FK和产品FK的销售时，关于SK的答案是不正确的，因为实际情况是，企业需要一些时间来完成特定的销售，而这时SK会有很大帮助。@JuValencia您不使用SK来查找特定的销售。您使用销售Id/收据编号/