64

このようなテーブルがある場合：

本（「ISBN」が存在しないふりをする）

  • 著者
  • タイトル
  • 版
  • 発行年
  • 価格

{Author、Title、Edition}が候補/主キーである可能性があると主張する人もいるかもしれません。

候補/主キーを{Author、Title、Edition}にするか、ID列を{Author、Title、Edition}で一意のインデックス/キー制約を使用して使用するかを決定するのは何ですか？

そうです

  • 著者（PK）
  • タイトル（PK）
  • エディション（PK）
  • 発行年
  • 価格

より良い、または：

  • ID（PK）
  • 著者
  • タイトル
  • 版
  • 発行年
  • 価格

ここで、{Author、Title、Edition}は追加の一意のインデックス/制約ですか？

4

4 に答える 4

56

{Author, Title, Edition}それが本を一意に識別すると言うと、次のことが成り立ちます。

  1. これはスーパーキーです-タプル（行）を一意に識別します。

  2. それは既約です-列のいずれかを削除しても、それはもはやキーにはなりません。

  3. これは候補キーです。既約スーパーキーは候補キーです。

次に、ID（整数）について考えてみましょう。

Bookテーブルキーが他のいくつかのテーブルに外部キーとして表示され、いくつかのインデックスにも表示されると考えることができます。したがって、これらの各テーブルと一致するインデックスには、かなりのスペース（たとえば、3列x 40文字（またはその他...））が必要になります。

これらの「その他の」テーブルとインデックスを小さくするためにBook、外部キーとして参照されるキーとして使用される一意の整数列をテーブルに追加できます。次のように言います。

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として使用することは、別の方法で証明されるまで、完全に優れた設計になる可能性があります。

于 2013-01-29T20:04:00.343 に答える
24

一般に、主キーの値を変更する必要はありません。これが、ブラインドまたは代理の主キーが使用される理由です。

主キーの一部としてAuthorを使用してBookテーブルを作成したと仮定します。

約1年後に、「レイ・ブラッドベリ」のつづりを間違えたことがわかったとします。さらに悪いことに、「レイチェルブルーム」のつづりを間違えました。スペルミスを修正するために変更する必要のあるデータベース行の数を想像してみてください。変更する必要のあるインデックス参照の数を想像してみてください。

ただし、代理キーを持つAuthorテーブルがある場合は、1行を修正するだけで済みます。インデックスを変更する必要はありません。

最後に、データベーステーブル名は通常、複数形（Books）ではなく、単数形（Book）です。

于 2013-01-29T17:18:58.963 に答える
7

代理主キーシナリオを使用するもう1つの理由は、一意性の制約が将来変更される必要がある場合です（たとえば、本を一意にするためにISBNを追加する必要があります）。データのキーの再生成ははるかに簡単になります。

于 2013-01-29T21:30:27.157 に答える
4

これに関連する記事はたくさんあります。あなたの場合の複合キーの問題：

  1. 本を他のエンティティとリンクするのは難しい
  2. ほとんどのグリッドは複合キーをサポートしていないため、グリッドでそれらを編集するのは難しい（例：剣道グリッド、jqgrid）
  3. 著者、タイトル、エディションのスペルを間違える可能性があります

データを正規化し、（dasblinkenlight）が提案したように作成者にIDだけを保存するのも良いでしょう。最悪のシナリオでは、彼/彼女は彼/彼女の名前を変更します（例えば、彼女は結婚し、彼女は彼女の新しい名前が好きです）。

于 2013-01-29T17:29:19.513 に答える