データベース基本概念

候補キーこうほきー

主キー一意性最小性関係データベース正規化スーパーキー

候補キーについて教えて

簡単に言うとこんな感じ！

「この列（または列の組み合わせ）さえあれば、どの行かをピタリと特定できる！」という資格を持った列のことだよ。社員番号でも、メールアドレスでも、どちらか1つで本人を特定できるなら、どちらも「候補キー」なんだ！

候補キーとは

候補キー（Candidate Key）とは、リレーショナルデータベース（表形式のデータベース）のテーブルにおいて、各行を一意に識別できる列または列の組み合わせのうち、最小限の列だけで構成されているもののことを指します。

テーブルには「どの行かを一意に特定できる列」が複数存在することがあります。たとえば「社員テーブル」であれば、「社員番号」でも「メールアドレス」でもどちらか1つで社員を特定できる場合、どちらも候補キーです。この中から実際に主キーとして採用されるものを1つ選び、残りは代替キー（Alternate Key）と呼びます。

候補キーを正しく把握することは、テーブル設計や正規化（データの重複や矛盾をなくす整理作業）を進めるうえで非常に重要な出発点となります。候補キーが曖昧なまま設計を進めると、同じデータが別々の形で重複登録されるなどのトラブルが発生しやすくなります。

候補キーの2大条件：一意性と最小性

候補キーとして認められるには、以下の2つの条件を両方とも満たす必要があります。

条件	意味	違反するとどうなるか
一意性（Uniqueness）	その列（または組み合わせ）の値が、テーブル内で重複しない	同じ値の行が2つ存在してしまい、どちらを指しているか分からなくなる
最小性（Minimality）	一意性を保つために必要な最小限の列しか含まない	余分な列を含んでいるものは「スーパーキー」と呼ばれ、候補キーではない

覚え方：「一意に・最小で・特定できる＝候補キー」

語呂合わせとして「い（一意）さい（最小）こう（候補キー）」と覚えてみましょう。一意性・最小性・候補キーの3点セットです。

候補キー・スーパーキー・主キーの関係

全ての列の組み合わせ（スーパーキー候補）
├── 一意性あり → スーパーキー
│    ├── さらに最小性あり → 【候補キー】 ← ここに注目！
│    │    ├── 採用された1つ → 主キー（Primary Key）
│    │    └── 採用されなかった残り → 代替キー（Alternate Key）
│    └── 最小性なし（余分な列を含む） → スーパーキーのみ
└── 一意性なし → キーになれない

歴史と背景

1970年 — エドガー・F・コッド（IBM）が関係モデル（リレーショナルモデル）を提唱。テーブルの各行を識別するキーの概念が生まれる
1972年頃 — コッドがキーの理論を精緻化。「候補キー」という概念が明確に定義され、主キー選択の前提となる
1980年代 — Oracle・DB2・SQL Serverなどの商用RDBMSが普及。候補キーの考え方は実装における制約（UNIQUE制約・PRIMARY KEY制約）として具体化
現在 — NoSQLやクラウドDBでも「どうやって行を一意に特定するか」という問題は不変。候補キーの概念はデータ設計の基礎として普遍的に使われ続けている

候補キー・主キー・代替キー・スーパーキーの比較

4種類のキーがどういう関係にあるのかを整理します。

キーの種類	一意性	最小性	主キーとして使われる	説明
スーパーキー	✅	❌（余分な列を含みうる）	—	一意性だけ満たす。候補キーの上位概念
候補キー	✅	✅	候補の中から1つ選ぶ	一意性と最小性の両方を満たす
主キー（Primary Key）	✅	✅	✅（1つだけ選ばれる）	候補キーの中から実際に採用されたもの
代替キー（Alternate Key）	✅	✅	❌（選ばれなかった）	主キーにならなかった候補キー。UNIQUE制約で管理

社員テーブルの具体例

社員テーブル
┌──────────┬──────────────────────────┬──────────────┬──────┐
│ 社員番号 │ メールアドレス            │ 氏名         │ 部署 │
├──────────┼──────────────────────────┼──────────────┼──────┤
│ E001     │ tanaka@example.com        │ 田中 太郎    │ 営業 │
│ E002     │ suzuki@example.com        │ 鈴木 花子    │ 総務 │
│ E003     │ sato@example.com          │ 佐藤 一郎    │ 開発 │
└──────────┴──────────────────────────┴──────────────┴──────┘

候補キー① → 社員番号（重複なし・これだけで特定できる）
候補キー② → メールアドレス（重複なし・これだけで特定できる）
非キー   → 氏名（同姓同名がありうる）、部署（複数人が同じ部署）

この場合、「社員番号」を主キーに採用した場合、「メールアドレス」は代替キーとなり、データベース上ではUNIQUE制約を設けて一意性を保証します。