複合主キーとは?仕組み・設計方法・代理キーとの違いを解説

複合主キーは、複数の列を組み合わせて行を一意に識別する主キーです。

設計の前には、業務上の一意性がどの列の組合せで表せるかを確かめておく必要があります。列の数や順序を後から変えると、参照側の定義も見直すことになります。

  • 単一列では表せない自然な一意性を、データベースの制約として記録できます。
  • 構成列をNOT NULLかつ一意な組合せとして定義し、外部キーとインデックス、更新と列順序、ORMとの関係を決めます。
  • 組合せ自体が識別子になる場合に向き、多対多の関連表、期間やテナントを含む識別、既存の業務キーなどが当てはまります。

複合主キーの定義と役割

複数の列の組合せで行を一意に識別する複合主キーの構造図
組合せ自体を一意性として記録

一つの列だけでは行を特定できず、列を組み合わせて初めて一意になる場合に、複合主キーを使います。その一意性をデータベースの制約として記録しておけば、重複したデータが登録されることを防げます。

発注側の担当者と開発会社は、組合せそのものが識別子になっているかを、業務の側から一緒に確かめます。

ポイント

一つの列で行を特定できないかを先に確かめ、組合せが業務上の一意性そのものを表すときにだけ、複合主キーを検討します。迷ったら、代理キーとの比較を並べて考えます。

複合主キーの仕組み|設計と判断の流れ

目的の定義から候補設定の検証と意思決定までを3層で示す複合主キーの設計図
定義・検証・意思決定を順に確認

1. 目的とデータの単位の定義

構成列はNOT NULLかつ一意な組合せとして定義します。列の一部がNULLになると一意性の扱いに注意が要るため、この条件を先に決めておきます。続いて、開発会社が外部キーとインデックス、ORMマッピングの設計に進みます。

2. 候補設定の学習と推定

構成列と列順序を記録します。外部キーやインデックス、ORMマッピングについても、内容を残します。そのうえで、実際の参照と更新の条件に当てはめて検証します。

3. 意思決定に使える形への変換

重複拒否と検索性能、外部キーの長さを確かめます。さらに、更新コストやORMの扱いやすさ、インデックス利用も材料にして、判断を進めます。

ポイント

構成列の定義を先に固め、そのあとで外部キーや更新、ORMへの影響を検証する順にすると、判断の材料を一度にそろえられます。

複合主キーの使い方|実務での適用場面

小さな検証からの開始

小さく試すなら、組合せ自体が識別子になる場面から選びます。多対多の関連表や既存の業務キーなど、組合せが一意性を担う対象が候補になります。

評価期間と利用者の統一

開発会社は、設計記録に構成列と列順序、NULLの条件を書き残します。さらに、外部キーの長さや更新コストも記載し、ORMとインデックスへの影響を添えます。

本番運用への移行

本番運用へ移す前に、重複拒否と検索性能、参照整合性を確かめます。更新コストとORMの扱いも見直し、キー構成を変えたときは再検証します。

複合主キーと関連手法の違い

代理キーは単一の人工IDを使い、参照を簡単にします。一方、複合主キーは業務上の一意性を直接表します。さらに、自然キーの変更や長さも比べる対象になります。

比べるときは、データの分け方や目的、評価期間をそろえ、前処理や計算予算も同じにします。手法ごとに答えられる問いが違う場合は、順位だけで単純に並べず、判断表を作ります。判断表には、精度と安定性に加えて、説明、費用、保守性も並べます。

ポイント

代理キーと比べるときは、参照のしやすさと業務上の一意性のどちらを優先するかを先に決めてから、判断表を作ります。

複合主キーの評価方法|数字だけに頼らない点

主要指標と不確実性

診断と再現性

平均値だけでなく、期間別やグループ別、極端なケース別の結果も確認します。設定を変えた感度分析や別データでの確認、複数シードでの再実験を行い、結論が一つの偶然に頼っていないかを点検します。

複合主キーで起きやすい失敗と対策

複合主キーで注意するNULL・列順序・キー長・構成列変更を示すチェックリスト
設計と運用の変化を点検

データと前処理の問題

全データで集計や標準化、補完をしてから分割したり、未来の値を入力に含めたり、結果を見てから評価対象を選んだりすると、性能や推定が楽観的になります。そこで、前処理は学習側に限り、処理の前後で件数と値域を監査します。

指標と問いの混同

構成列の一部がNULLになる、列順序を誤る、キーが長くなりすぎる、といった点に注意します。さらに、構成列を変えたときの参照更新や、参照側で定義が重複していないかも確かめます。

運用条件の変化への対応

業務上の一意性や構成列が変わったときは、外部キーと参照側の定義を見直す必要があります。

ポイント

NULL、列の順序、キーの長さ、構成列の変更を設計の段階で点検し、構成列を変えたときは外部キーと参照側の定義も見直します。

複合主キーを採用する判断基準

組合せの一意性が業務ルールとして安定していて、参照や更新が複雑になることを受け入れられる場合に採用します。採用前には、代理キーとの比較も行います。

設計資料には、構成列と列順序、NULLの扱いを残します。さらに、外部キーや更新への影響と、インデックスやORMへの影響も同じ資料に書きます。

ポイント

業務ルールが変わりにくく、キーの変更が起きにくいと見込めるかが、迷ったときの目安になります。代理キーで足りる場合は、そちらを選ぶ余地も残しておきます。

複合主キーまとめ|目的・前提・評価の統一

複合主キーは、複数の列の組合せで行を一意に識別する主キーです。単一列では表せない自然な一意性を、データベースへ制約として記録できます。

価値を出すには、まず対象と時間の範囲を定義します。入力、出力、仮定も明確にしたうえで、基準となる手法と同じ条件で評価することが重要です。

小さく検証してから適用範囲を広げ、設定やデータ、評価結果を後から再現できる形で保存します。判断では、精度や有意性だけでなく、誤りのコストや説明可能性も含めて考えてください。さらに、運用負荷と、影響を受ける人への公平性も見てください。

よくある質問(FAQ)

Q. 複合主キーとは何ですか?

複数の列を組み合わせて行を一意に識別する主キーです。単一の列では表せない自然な一意性を、制約としてデータベースに記録できます。

Q. 複合主キーはどのような場面で使いますか?

行を一意に識別するのに複数の列の組合せが必要なテーブルで使います。

Q. 複合主キーを使うときの評価指標は何ですか?

重複の有無と検索性能、外部キーの扱いを確認します。さらに、更新、ORM、インデックスへの影響も見ます。

Q. 複合主キーで起きやすい失敗は何ですか?

列のNULL、列の順序、キーの長さに注意が必要です。構成列の変更や参照側の定義も見落とさないようにします。

Q. 複合主キーと似た手法はどう使い分けますか?

代理キーは単一の人工IDを使うのに対し、複合主キーは業務上の組合せをそのまま一意性として表します。

参考資料

本記事の定義と実務上の注意は、次の公式資料に基づいています。

PostgreSQL公式資料とMySQL公式資料を参照しています。利用するときは、該当するバージョンの資料を確認してください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。