{Author, Title, Edition}と言います 本を一意に識別する場合、次のことが当てはまります。
-
これはスーパーキーです。タプル（行）を一意に識別します。
-
既約です。列を削除しても、それ以上キーにはなりません。
-
これは候補キーです。既約スーパーキーは候補キーです。
次に、ID（整数）を考えてみましょう
Book テーブルキーは、他のいくつかのテーブルに外部キーとして表示され、いくつかのインデックスにも表示されます。したがって、これらの各テーブルと一致するインデックスには、かなりのスペース（たとえば、3列x 40文字（またはその他...））が必要になります。
これらの「その他の」テーブルとインデックスを小さくするために、Bookにunique-integer-columnを追加できます。 外部キーとして参照されるキーとして使用されるテーブル。次のように言います：
alter table Book add BookID integer not null identity;
BookIDを使用 Bookも（必ず）ユニークである テーブルに2つの候補キーがあります。
これで、BookIDを選択できます 主キーとして。
alter table Book add constraint pk_Book primary key (BookID);
ただし、{Author,Title,Edition} 必須 防止するためにキー（一意）を維持する このようなもの：
BookID Author Title Edition
-----------------------------------------------
1 C.J.Date Database Design 1
2 C.J.Date Database Design 1
要約すると、BookIDを追加します -そしてそれをプライマリとして選択-{Author, Title, Edition}を停止しませんでした （候補）キーであること。それでも、独自の制約と通常は一致するインデックスが必要です。
また、設計の観点から、この決定は「物理レベル」で行われたことにも注意してください。一般に、設計の論理レベルでは、このID 存在しません-列のサイズとインデックスの検討中に導入されました。したがって、物理スキーマは論理スキーマから派生しました。使用するDBサイズ、RDBMS、およびハードウェアによっては、そのサイズの理由のいずれも測定可能な効果をもたらさない可能性があります。したがって、{Author, Title, Edition}を使用します。 PKは完全に優れた設計である可能性があるため、別の方法で証明されるまでは。