BI *_*ude 9 database-design data-warehouse primary-key fact-table
我听说过一些参考资料,事实表上不需要pk.我相信每张桌子都应该有一个PK.
如果没有pk和10+外键,一个人怎么能理解事实表中的一行呢？
has*_*own 21
主键在那里
......但在执法primary key中的约束数据库级别不必需的.
如果您考虑这一点,从技术上讲,唯一键或主键是唯一定义每行特征的键.它可以由该实体的多个属性组成.现在,在Fact表的情况下,foreign keys从其他维度表一起流入已经充当复合主键.并且这些外键组合可以唯一地标识事实表中的每个记录.因此,这个外键组合是事实表的 主键.
为什么不是代理钥匙呢？
现在,如果您愿意,您可以为事实表定义一个代理键.但是,这个目的是什么？您永远不会从引用其代理键的事实表中检索一条记录(而是使用索引).您不会使用该代理键将事实与其他表联系起来.这样的代理键将完全浪费数据库中的空间.
实施数据库约束
在数据库级别定义此概念主键时,数据库需要确保在通过它执行的任何DML操作中不会违反此约束.确保此约束是数据库的开销.对于OLTP系统而言可能无关紧要,但对于批量加载数据的大型OLAP系统,这可能会导致严重的性能损失.此外,为什么您希望数据库在数据加载阶段(通常通过ETL编码)确保相同时确保约束的完整性.
原则上事实表应该有一个键，这是绝对正确的。从数据建模的角度来看，它是必需的。在实现中，数据库中的键约束通常需要一个索引。创建和维护索引的开销使得“关键”属性的唯一性有时是通过控制集成层（“ETL 过程”）而不是数据库中的约束来维护的。
只要可行，就可以在数据库中创建键约束。如果密钥没有在数据库中明确定义，那么应该为用户清楚地记录下来，以便他们能够理解数据的含义。