ITパスポート 2009年 秋期 問84

関係データベースの主キー【ITパスポート 解説】

正解の理由

• 関係データベース（relational database）：データを表（テーブル）で管理する方式。
• 主キー（primary key）：各行（レコード）をただ一つで特定するための列（項目）。NULL（値が存在しないこと）を許さず、同じ値が複数行に存在してはいけません。
• NULL：値が存在しないことを表す特別な状態（未設定や不明を表す）。

解法ステップ

1. 問題文は「主キーに関する記述」であることを確認する。主キーの基本条件を思い出す：
   • 一意性（同じ値が2行に存在してはならない）
   • 非NULL（NULLを値にできない）
2. 各選択肢を上の条件に当てはめる：
   • 「主キーだけで関係付けられる」→主キーと外部キーの関係を正しく理解する必要あり（過度な断定は誤り）。
   • 「NULLを持てる」→主キーはNULLを持てないので誤り。
   • 「同一のものがあってもよい」→一意性に反するので誤り。
   • 「複数の項目を組み合わせてよい」→これは主キーの性質として正しい。
3. よって正答は エ。

選択肢別の誤答解説

• ア: 関係データベースの各表は、主キーだけで関係付けられる。
  • 誤り。テーブル同士の関係は「主キー」と「外部キー（foreign key：別の表の主キーを参照する列）」によって表現します。したがって「だけで」と断言するのは不正確です（外部キーの存在や複数のキーで結合する場合もある）。さらに、結合条件は必ずしも主キーだけとは限りません（業務上の複合条件で結合することもあります）。
• イ: 主キーとして指定した項目は、NULLを属性値としてもつことができる。
  • 誤り。主キーはNULLを許しません。NULLだとその行を一意に特定できないためです。
• ウ: 一つの表において、主キーとして指定した項目の値に同一のものがあってもよい。
  • 誤り。主キーは一意性を要求するため、同じ値が複数行に存在してはいけません。
• エ: 一つの表において、複数の項目を組み合わせて主キーとしてもよい。
  • 正しい。複数列を組み合わせて一意性を満たす場合、複合主キーとして指定できます。

よくある誤解

1. 「主キー＝必ず1列だけ」という誤解
   → 実務では単一列の主キー（例：自動採番ID）が多いですが、業務上は複数列の組み合わせが主キーになることがよくあります。複合主キーは正しい設計手法です。
2. 「NULLは空文字と同じ扱い」
   → NULLは「値が存在しない」ことを示す特別な状態です。空文字（""）や0とは別物で、主キーにNULLは認められません。
3. 「テーブル間の結合は必ず主キーと外部キー」
   → 多くはそうですが、業務の都合で自然キー（名前＋生年月日など）で結合する場合もあります。重要なのは一意に識別できるかどうかです。

補足コラム

• 複合主キーの例（業務での具体例）
  受講履歴テーブルを考えます。1人の受講者が複数の講座を受ける場合、(受講者ID, 講座ID) の組み合わせで一意になるなら、この2列を複合主キーにできます。
• 実務での代替：代理キー（surrogate key：システム側が付与するID） 複合主キーが扱いにくい場合、代わりに単一の自動採番IDを主キーにして、業務上の一意性は別にUNIQUE制約（ユニーク制約）で保証することがあります。これにより結合や参照が簡潔になります。
• SQLでの複合主キー定義例：

CREATE TABLE Attendance (
  student_id INT,
  course_id INT,
  attended_date DATE,
  PRIMARY KEY (student_id, course_id)
);

FAQ