外鍵・とは？初心者にもわかるデータベースの基本と使い方共起語・同意語・対義語も併せて解説！

この記事を書いた人

岡田康介

名前：岡田康介（おかだこうすけ）ニックネーム：コウ、または「こうちゃん」年齢：28歳性別：男性職業：ブロガー（SEOやライフスタイル系を中心に活動）居住地：東京都（都心のワンルームマンション）出身地：千葉県船橋市身長：175cm 血液型：O型誕生日：1997年4月3日趣味：カフェ巡り、写真撮影、ランニング、読書（自己啓発やエッセイ）、映画鑑賞、ガジェット収集性格：ポジティブでフランク、人見知りはしないタイプ。好奇心旺盛で新しいものにすぐ飛びつく性格。計画性がある一方で、思いついたらすぐ行動するフットワークの軽さもある。 1日（平日）のタイムスケジュール 7:00 起床：軽くストレッチして朝のニュースをチェック。ブラックコーヒーで目を覚ます。 7:30 朝ラン：近所の公園を30分ほどランニング。頭をリセットして新しいアイデアを考える時間。 8:30 朝食＆SNSチェック：トーストやヨーグルトを食べながら、TwitterやInstagramでトレンドを確認。 9:30 ブログ執筆スタート：カフェに移動してノートPCで記事を書いたり、リサーチを進める。 12:30 昼食：お気に入りのカフェや定食屋でランチ。食事をしながら読書やネタ探し。 14:00 取材・撮影・リサーチ：街歩きをしながら写真を撮ったり、新しいお店を開拓してネタにする。 16:00 執筆＆編集作業：帰宅して集中モードで記事を仕上げ、SEOチェックやアイキャッチ作成も行う。 19:00 夕食：自炊か外食。たまに友人と飲みに行って情報交換。 21:00 ブログのアクセス解析・改善点チェック：Googleアナリティクスやサーチコンソールを見て数字を分析。 22:00 映画鑑賞や趣味の時間：Amazonプライムで映画やドラマを楽しむ。 24:00 就寝：明日のアイデアをメモしてから眠りにつく。

外鍵・とは？データベースの関係を作る基本ルール

データベースは情報を整理するために表と呼ばれる箱をいくつも作り、それぞれの箱の中にデータを並べて保存します。表と表は単独でも使えますが、現実の世界では情報同士がつながることが多いです。たとえばお店の注文データと顧客データを別々の表に分けて保存しておくと管理が楽ですが、実際にはどの注文がどの顧客に結びつくかを知る必要があります。ここで登場するのが外鍵です。

外鍵とは別の表の主キーを参照する列のことです。外鍵があることである表の中の値が必ず別の表の存在する値と結びつき、情報同士のつながりを作ることができます。つまり外鍵はデータ間の関係を作る“つなぎ役”であり、データ同士が分断されることを防ぐ仕組みです。

なぜ外鍵が必要なのか

現実の世界では色んな情報が互いに関連しています。たとえば注文を管理する場合、どの注文がどの顧客に属するのかを知る必要があります。もし顧客データがなくなってしまうと、その注文の意味が薄れてしまいます。外鍵を使うとこのような不整合を防ぐことができます。外鍵により 参照整合性 が保たれ、データの信頼性が高まります。

実例で理解する外鍵

以下のような2つの表を考えます。顧客表 customers は顧客を一意に識別する主キー id を持ちます。注文表 orders には注文番号 order_id と顧客を表す customer_id が含まれます。customer_id は customers の id を参照する外鍵です。

このとき orders の customer_id に存在しない値を入れるとデータベースは拒否します。これにより注文データと顧客データの間に矛盾が生まれません。

表の関係を表す簡易表

able> テーブル主キー/外鍵説明顧客id顧客を一意に識別する主キー注文order_id注文を一意に識別する主キー customer_id外鍵として顧客.id を参照 ble>

外鍵の作り方の基本

実務ではデータベース設計の段階で外鍵を設定します。典型的な流れは次のとおりです。まず顧客表と注文表を作成します。次に注文表の customer_id 列を外鍵として設定し、顧客表の id を参照するようにします。最後に参照整合性を保つためのルールを決めます。代表的なルールには以下のようなものがあります。

ON DELETE と ON UPDATE の指定です。例えば ON DELETE CASCADE を設定すると親である顧客が削除されたとき関連する注文も自動で削除されます。逆に ON DELETE SET NULL のように設定すると削除された場合は外部キーを null にします。こうした選択肢を組み合わせることでデータの整合性を柔軟に保つことができます。

実践的なポイントと注意点

外鍵を使うときは次の点に気をつけましょう。まずはデータ型と長さをそろえることです。例えば外鍵と参照先の主キーの型が異なるとエラーになります。次に外部キーの参照先テーブルが先に存在していないと参照できません。設計段階で正しい順序で作成することが大切です。最後にデータの更新時にも注意が必要です。親の主キーが変わるケースは少ないですが、もし変更が必要なら子の外鍵も適切に更新する必要があります。

SQL で外鍵を作る基本の例

実務では SQL を使って外鍵を設定します。以下は代表的な書き方の例です。なおここでは引用符や括弧の使い方に注意しつつ説明します。ALTER TABLE orders ADD CONSTRAINT fk_orders_customers FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE ON UPDATE CASCADE;

この一文は orders テーブルの customer_id を外鍵として設定し親テーブルである customers の id を参照します。On delete の挙動と On update の挙動をそれぞれカスケードに設定しています。実際の環境では自社のデータの性質に合わせて適切な動作を選ぶことが大切です。

外鍵のよくある誤解

外鍵は単なるデータの結びつきではなく データの整合性を守るための仕組み です。外鍵があるからといって全ての不整合が自動的に解消されるわけではありません。データの入力時のルール設計やデータの保守運用がきちんとされていなければ思わぬ不整合が生まれることもあります。設計時には実務での運用を想定して適切な制約とルールを決めましょう。

このように外鍵はデータベースの中で表と表を結びつける大切な道具です。正しく使えばデータの信頼性が高まり、後からデータを分析する際にも整った関係データとして活用できます。

外鍵の同意語

外部キー: 別の表の主キーを参照するためのキー。テーブル間の参照関係を作り、参照整合性を保つ役割を担う。
参照キー: 他の表のキーを参照する目的のキー。実務では『外部キー』と同義で使われることが多い表現。
外部参照キー: 他の表の主キーを参照する役割のキー。外部キーと同義に用いられることがある言い換え表現。
FK: Foreign Keyの略称。データベース設計やSQLで頻繁に見かける表記。

外鍵の対義語・反対語

主キー（Primary Key）: 自テーブルの行を一意に識別するキー。外部キーが他のテーブルを参照するのに対して、主キーは自テーブル内での識別手段として機能し、外部参照の起点となることが多い外部キーとは用途が反対です。
内部キー（Internal Key）: テーブル内での識別・結合に使われるキー。外部キーのように他テーブルを参照する目的ではなく、内部的な識別子として扱われることを強調する表現です。
参照なしキー（No-Foreign-Key / 外部参照なしキー）: 他テーブルを参照しない状態のキー。外部キーの“参照”に対して、内部的・自テーブル内の識別に留まる点を指す表現です。
ローカル識別キー（Local Identifier Key）: 自テーブル内で行を一意に識別する役割を持つキー。外部テーブルを参照せず、同一テーブル内での結合・識別に用いられる点を強調します。