主キーとは？外部キーとの違いを顧客・注文テーブルの例で解説

主キー（PRIMARY KEY）は、テーブルの各行を重複なく識別するための列、または列の組み合わせです。 たとえば、同姓同名の顧客を区別する「顧客ID」が主キーになります。

主キーが「この行はどれか」を決めるのに対し、外部キーは「参照先のどの行と結び付くか」を表します。顧客と注文の具体例で、違いを見ていきましょう。

この記事でわかること

主キー（PRIMARY KEY）とは、データベースのテーブルの中で、各レコード（行）を一意に識別するために指定する列（カラム）、または列の組み合わせのことです。

「一意」とは「重複しない、ただ1つの」という意味です。PRIMARY KEY制約を設定すると、主キー全体の値の重複と、構成する列のNULL（値がない状態）を防げます。PostgreSQL公式ドキュメントの主キー・外部キーの説明でも、この制約を確認できます。

会員ごとに重複しない会員番号を割り当てるお店を考えてください。同じ名前の会員がいても、会員番号で区別できます。データベースの主キーも、このように行を識別する役割を持ちます。

たとえば、顧客テーブルで考えてみましょう。

「田中太郎」が2人いても、顧客IDが001と002で区別できています。これが主キーの役割です。

顧客ID「001」の人が2回注文した場合、注文テーブルでは次のようになります。

注文ID（この表の主キー）	顧客ID（外部キー）	商品
A101	001	ノート
A102	001	ペン

注文IDはそれぞれの注文を識別します。一方、顧客ID「001」は同じ顧客の注文なので繰り返し登場します。外部キーは主キーに限らず、参照先の一意制約などを満たす列を参照できる場合もあります。

行を一意に識別する基準がないと、次のような問題が起きます。

同じデータを区別できない 「田中太郎さんの注文履歴を表示して」とシステムに命令したとき、同姓同名の人が複数いたらどちらのデータを取得すればよいかわかりません。

データの更新や削除で間違いが起きる どのレコードを変更・削除するかを正確に指定できないため、意図しないデータが変更されるリスクがあります。

テーブル間の関係が曖昧になる 複数のテーブルを関連づけるとき（「この注文は誰のものか」など）、一意な顧客IDが基準になります。主キーの宣言がなくても結合自体はできますが、識別の基準が曖昧だと意図しない重複や取り違えにつながります。

実際の業務システムでは、次のような主キーが使われることが多いです。

「社員番号で管理してください」「注文IDをキーにして検索します」といった会話が出てきたら、それは主キーを使ったデータ管理の話です。

名前や住所を主キーにしてはいけない 名前は同姓同名があり、住所は変わることがあります。主キーは「変わらない・重複しない」ものを選ぶのが原則です。

主キーは後から変えにくい 主キーは他のテーブルからも参照されるため、後から変更すると影響範囲が大きくなります。設計段階での決定が重要です。

「複合主キー」という考え方もある 1つの列だけでなく、複数の列を組み合わせて主キーとするケースもあります。たとえば注文明細を「注文ID＋明細番号」で識別する場合です。組み合わせ全体が一意になることを確認します。

自動採番（AUTO INCREMENT）が使われることが多い 「1、2、3…」と自動的に番号が増えていく仕組みを使って、主キーを自動生成することが多いです。

要件定義や設計レビューで「このデータをどのキーで管理しますか？」という議論が出てくることがあります。「どの項目で一意に識別するか」という観点で考えると、主キーの議論が理解しやすくなります。

また、「主キーが重複しました」というエラーが発生した場合、同じIDのデータが2回登録されようとしていることを意味します。データ移行やCSVインポート時によく起きるエラーです。