比如说{Author, Title, Edition}唯一标识一本书，则以下成立：
它是一个超级键——唯一标识一个元组（行）。
它是不可约的——删除任何列都不会使其成为键。
它是一个候选键——不可约的超键是一个候选键。
现在让我们考虑 ID（整数）
我可以推断Book表键将作为外键显示在少数其他表中，并且也会显示在少数索引中。因此，在每个表以及匹配的索引中，将占用相当多的空间 - 比如说三列 x 40 个字符（或其他......）。
为了使这些“其他”表和索引更小，我可以向Book表用作将被作为外键引用的键。说这样的话：
alter table Book add BookID integer not null identity;
With BookID也（必须是）独特的，Book表现在有两个候选键。
现在我可以选择BookID作为主键。
alter table Book add constraint pk_Book primary key (BookID);
但是，那{Author,Title,Edition} must保留密钥（唯一）以便prevent像这样的东西：
BookID Author Title Edition
-----------------------------------------------
1 C.J.Date Database Design 1
2 C.J.Date Database Design 1
总结一下，添加BookID——并选择它作为主要的——并没有停止{Author, Title, Edition}是（候选）键。它仍然必须有自己的唯一约束，通常还有匹配索引。
另请注意，从设计角度来看，这个决定是在“物理层面”完成的。一般来说，在设计的逻辑层面上，ID不存在——它是在考虑列大小和索引时引入的。因此，物理模式是从逻辑模式派生出来的。根据数据库大小、RDBMS 和使用的硬件，这些大小推理都可能不会产生可测量的效果——因此使用{Author, Title, Edition}作为 PK 可能是完美的设计——除非得到不同的证明。
