Previous: テーブルの満たすべき要件
Up: データベースの論理設計
Next: 関数従属
Previous Page: テーブルの満たすべき要件
Next Page: 関数従属

テーブルとキー

リレーショナル・データベースでの行の選択は、次のようなメカニズムで行われる。 テーブル中に行の重複は許されていないから、全ての行は、相互に異なる内容を持つ。 だから、行の内容を全て指定すれば、もしも、それにマッチする行がテーブル内に 存在するならば、その行を選択することが出来る。

「重複行の禁止」は、その行の現れる場所や番地によって、行を指定する方法を取ら ず、その内容によって行を指定する方法を取ったことによる要請である。こうして、 行の選択は、通常の「アドレス指定方式」ではなく、いわば、「連想記憶方式」とい うべき方法で行われることになる。この点では、例えば、テーブルの検索でも、列 方向の検索では、項目名を指定するといった形で、「アドレス指定方式」が用いられ ていることに注目しよう。リレーショナル・データベースでは、テーブルの縦横の 検索方式が非対称なのである。

「重複行の禁止」の要請は、最悪の場合でも、全項目を指定すれば、一意に行を指定 可能であることを保証するのだが、全ての項目の値を指定しなくても、いくつかの 項目の値を指定すれば、一意に行の指定が可能であることもある。 そうした項目の組を、「主キー候補キー」と呼ぶ。これを簡単に「候補キー」と呼ぶ こともある。単に、項目の組が行を一意に決定するかという基準だけなら、全項目で はない、全ての「主キー候補キー」に、そこには含まれていない項目をつけ加えて も、やはり「候補キー」になるので、(なぜなら、「全項目」は、どの場合でも「候 補キー」になるのだから)、通常は、「主キー候補キー」になる最小の項目の組を 「主キー候補キー」と呼ぶことが多い。最小の項目の組とは、それ以上の項目を減ら せば、一意の行の指定が不可能となるという意味である。

「主キー候補キー」の中から、一つを選んで、「主キー」と呼ぶ。ここでも、通常は、 最小構成の項目の組が、「主キー」として選ばれる。最も簡単な場合には、ある項目 が、単独で、「主キー」の役割を果たす。こうした時、「主キー」の内容は、一意に その行を特徴づけることになる。「主キー」には、内容の重複はありえない。

テーブルの項目の中で、自分以外の外部のテーブルの「主キー」の値を、参照する 項目を、「外部参照キー」と呼ぶ。「外部参照キー」は、二つのテーブルのジョイン で、中心的な役割を果たす。

具体的な例で考えてみよう。

先のテーブル「書名著者一覧」では、項目「書名」あるいは、項目「著者」のいずれも 単独では、行を一意に指定できない。一つの本に、複数の著者(共著者)が存在し、 一人の著者が複数の本を書くことがあるからである。ここでは、全項目である、項目 「書名」と項目「著者」のペアが「主キー」ということになる。

 書名                             著者
  -------------------------------- -------------------------------
 スーパーユーザーのためのUNIX     丸山不二夫
 スーパーユーザーのためのUNIX   雪田修一
 スーパーユーザーのためのUNIX   姫宮利融
 スーパーユーザーのためのUNIX   植田龍男
 UNIXデータベース         丸山不二夫
  UNIXデータベース                 片山初子
  -------------------------------- -------------------------------

次のテーブル「利用者台帳稚内編」では、どうであろうか?

 コード   姓     名       電話番号       郵便 住所
  -------- ------ -------- -------------- ----- ----------------------
  999999   丸山   不二夫   0162-33-8177   097   稚内市富岡5-9-1
  999998   雪田   修一     0162-32-2360   097   稚内市富岡2-3-6
  999997   植田   龍男     0162-32-1234   097   稚内市富岡1-2-3
 999996   片山  初子     03-3497-4062   108   東京都港区北青山2-5-1
  999995   姫宮   利融     0162-34-2340   097   稚内市富岡2-3-4

ここでは、項目「コード」が、「主キー」である。「姓」と「名」の組も、「候補キ ー」になりそうに思えるが、世の中には、「同姓同名」の人間が有りうるので、あまり ふさわしくない。電話番号や住所も、その中に複数の家族が存在しうるので、「候補 キー」にはふさわしくない。

このように、ある項目の組が、「主キー」たりうるか否かは、そのテーブルが、いか なる現実の関係を表現しようとしているかにディペンドして判断されるのであり、純 粋に、形式的観点から決められるわけではないことに注意しよう。 同姓同名が許されない世界があれば、そうした世界では、「姓」と「名」の組は、 「主キー」たりうるのであり、もし、「利用者台帳稚内編」に登録さるべき利用者の 総数が百万人を超える世界が、もしもあれば、そうした世界では、「コード」は、 あきらかに、「主キー」たりえないのである。

次のテーブル「書名著者コード一覧」の例では、「候補キー」は、「書名」「著者」 の組か、「書名」「著者コード」の組である。明らかに、「著者」「著者コード」の 組は、「候補キー」たりえない。ここで、項目「著者コード」は、テーブル「利用者 台帳稚内編」に対する「外部参照キー」である。

 書名                             著者             著者コード
  -------------------------------- ---------------- --------------
 スーパーユーザーのためのUNIX     丸山不二夫       999999
 スーパーユーザーのためのUNIX   雪田修一         999998
 スーパーユーザーのためのUNIX   姫宮利融         999995
 スーパーユーザーのためのUNIX   植田龍男         999997
 UNIXデータベース         丸山不二夫       999999
  UNIXデータベース                 片山初子         999996
  -------------------------------- ---------------- --------------

maruyama@wakhok.ac.jp
1995年02月10日 (金) 00時49分16秒 JST