データベース基本概念

複合キーふくごうきー

主キー複合主キー候補キー正規化リレーショナルデータベーステーブル設計

複合キーについて教えて

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

「1つの列だけじゃ行を特定できないから、2つ以上の列を組み合わせて”名札”にしちゃおう！」っていう仕組みだよ。たとえば「注文テーブル」で「注文ID」だけでは足りないとき、「注文ID＋商品ID」をセットで使うイメージ！

複合キーとは

複合キー（Composite Key）とは、リレーショナルデータベースにおいて、2つ以上の列（カラム）を組み合わせてレコード（行）を一意に識別するキーのことです。1つの列の値だけでは重複が生じてしまうケースで、複数の列を”セット”として扱うことで、テーブル内のどの行なのかを確実に特定できるようにします。

たとえば「受講履歴テーブル」を考えてみましょう。「学生ID」だけでは同じ学生が複数の講座を受講できますし、「講座ID」だけでは複数の学生が同じ講座を受講します。しかし「学生ID＋講座ID」を組み合わせれば、「誰がどの講座を受講しているか」を一意に特定できます。これが複合キーの典型的な使い方です。

複合キーは特に多対多のリレーション（関連）を解消するための中間テーブル（連関テーブル）でよく登場します。システムの発注・設計を考えるうえで、「このテーブルはどうやって行を特定するの？」という問いに答える重要な概念です。

複合キーの構造と種類

テーブルのキーには様々な種類があり、複合キーはその中の1つです。

キーの種類	説明	単一列？
単一主キー	1つの列で行を一意に識別	✅ 1列
複合キー（複合主キー）	2列以上の組み合わせで行を一意に識別	❌ 複数列
候補キー	主キーになりえる列（複合でも可）	どちらも可
外部キー	他テーブルの主キーを参照する列（複合も可）	どちらも可
代理キー（サロゲートキー）	DBが自動採番するID（複合キーの代替としても使用）	✅ 1列

覚え方：「名字＋名前」で人を特定

「田中」という名字だけでは全国に何万人もいます。「一郎」という名前だけでも同様。でも「田中一郎」という組み合わせなら、特定のグループの中では一意になることが多い――これが複合キーのイメージです。1つでは足りない情報を組み合わせて初めて”名札”になる、と覚えましょう。

複合キーが登場しやすいテーブルの例

【受講履歴テーブル】
┌──────────┬──────────┬──────────────┐
│ 学生ID   │ 講座ID   │ 受講開始日   │
│ (PK)     │ (PK)     │              │
├──────────┼──────────┼──────────────┤
│ S001     │ C101     │ 2026-04-01   │
│ S001     │ C102     │ 2026-04-01   │ ← 同じ学生IDが複数行
│ S002     │ C101     │ 2026-04-05   │ ← 同じ講座IDが複数行
└──────────┴──────────┴──────────────┘
  ↑ 2列セットで初めて「誰がどの講座か」を特定できる

歴史と背景

1970年代：E.F.コッドがリレーショナルモデルを提唱。テーブルの各行を一意に識別する「主キー」の概念が定式化され、複合キーもその一形態として定義された
1980年代：OracleやDB2など商用RDBMSの普及に伴い、複合主キーはERモデル（実体関連モデル）設計の標準的な手法として広まる
1990年代：データベース正規化の教育が体系化。多対多を解消する中間テーブルへの複合キー適用がベストプラクティスとして確立
2000年代以降：ORMツール（Object-Relational Mapping）の普及により、「代理キー（自動採番のID）を使って複合キーを避ける」設計も増加。複合キーとサロゲートキーのどちらを使うかはいまも設計上の議論が続く
現在：SQLの国際規格（ISO/IEC 9075）でも複合キーは正式にサポートされており、RDBを使うシステム設計の基礎として変わらず重要

複合キー vs 代理キー（サロゲートキー）

複合キーの代わりに「自動採番のID列1つ」を主キーにする設計（代理キー方式）と、よく比較されます。

実務での選び方のポイント：

小〜中規模・シンプルな設計：意味が明確な複合キーで設計すると直感的でわかりやすい
大規模・ORM利用・マイクロサービス：代理キー＋UNIQUE制約の組み合わせが保守しやすい
どちらが正解というわけではなく、プロジェクトの規模・使用ツール・チームのスキルに合わせて選択するのが現実的