外部キーとは、別のテーブルにある主キーなどの一意な値を参照し、テーブル同士の関係を守るための列、または列の組み合わせです。見た目はただのIDの列でも、役割はとても大切です。データベースでは、データがバラバラにならず、つじつまが合うように支える「約束事」だと考えるとわかりやすいです。
よくある疑問：外部キーって、ただ数字を入れるだけの列とは違うんですか？
はい。外部キーは、別テーブルに本当に存在する値だけを使って、データ同士の関係がずれないようにする仕組みです。
たとえば、会員テーブルと注文テーブルがあるとします。注文には「だれの注文か」を入れたいので、会員テーブルの会員IDを注文テーブルに持たせます。このとき、会員IDを参照する列が外部キーです。もし会員IDが間違っていたら、注文の持ち主がわからなくなります。外部キーは、そうしたミスを起こしにくくします。
基礎解説：外部キーの役割
外部キーのいちばん大きな役割は、テーブル同士の関係をはっきりさせることです。データベースは、1つの大きな表に全部入れるより、目的ごとに表を分けることが多いです。名前、注文、商品、支払いのように分けておくと管理しやすくなります。その代わり、表同士をどう結ぶかを決めないと、後で何のデータかわからなくなります。そこで外部キーが必要になります。
外部キーがあると、次のような助けがあります。
- 存在しない相手のIDを入れにくくなる
- 親データと子データの関係が保ちやすくなる
- テーブルのつながりをSQLや図で追いやすくなる
- データのつじつまが合わない事故を減らしやすい
ここでよく出る言葉が「親テーブル」と「子テーブル」です。会員テーブルのように、参照される側を親テーブル、注文テーブルのように、参照する側を子テーブルと呼ぶことがあります。親は「元のデータ」、子は「そのデータを使っている側」と覚えると混乱しにくいです。
また、外部キーはただ入れれば終わりではありません。親データを更新したり削除したりするときに、子データをどう扱うかも考える必要があります。運用によっては、親を消そうとしたら止める、子も一緒に消す、子の値を空にする、といった動きが設定できます。ここは、データを勝手に壊さないための安全装置です。
テーブルを分ける考え方は、正規化でよく出てきます。データを整理して重複を減らすほど、どの列がどの表を指すのかを外部キーで決める場面が増えます。逆に、表のつながりがあいまいだと、後から探しにくくなります。
身近なたとえ：名簿と出席番号で考える
外部キーは、学校の名簿にたとえるとわかりやすいです。クラス名簿には、児童番号と名前があります。日直表や出席記録には、児童番号を書いておくと、誰の記録かすぐにわかります。このとき、出席記録に存在しない番号を書いてしまうと、名簿と記録が合いません。
つまり、外部キーは「相手の表に本当にいる番号だけを書いてね」というルールです。電話番号のメモのように見えても、実は相手の名簿とつながっているので、勝手な番号を入れると困ります。データベースでも同じで、関係のない番号が入ると、注文の持ち主、所属部署、担当者などが追えなくなります。
もう少し大人向けの仕事の場面で言うと、顧客マスタと受注データの関係です。受注データには顧客IDを入れますが、その顧客IDは顧客マスタにある番号でなければいけません。これが外部キーの考え方です。もし顧客が退職、退会、削除などの状態になっても、受注データとの関係は設計で整理しておかないと、あとで誰の取引かわからなくなります。
実務例：ECサイトの注文データ
ECサイトでは、会員、商品、注文、注文明細のようにテーブルが分かれることが多いです。たとえば、注文テーブルに会員IDを入れておけば、「この注文はどの会員のものか」をすぐに追えます。注文明細には注文IDと商品IDを入れておけば、「どの注文に、どの商品が、何個入っているか」がわかります。こうしたつながりを支えているのが外部キーです。
CREATE TABLE customers (
customer_id INT PRIMARY KEY,
customer_name VARCHAR(100)
);
CREATE TABLE orders (
order_id INT PRIMARY KEY,
customer_id INT,
order_date DATE,
FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);この例では、orders の customer_id が外部キーです。customers にない customer_id を入れようとすると、データベースが止めてくれる設定にできます。これによって、存在しない会員の注文を作ってしまうミスを防ぎやすくなります。
画面で一覧を作るときは、外部キーだけでは足りません。注文一覧に会員名も表示したいなら、JOIN を使ってテーブルをつなぎます。外部キーは「つなぐ約束」、JOINは「つないで見せるSQL」です。役割がちがうので、セットで覚えると整理しやすくなります。
設計を図で考えるなら、ER図 が便利です。ER図では、テーブル同士の線を見ながら、どれが親でどれが子かを確認できます。外部キーがあると、図の線と実際のテーブル定義がそろいやすく、あとで確認するときにも迷いにくいです。
よくある疑問：外部キーがあれば、JOINはもう使わなくていいんですか？
いいえ。外部キーは関係を守るルールで、JOINはその関係を使ってデータを一緒に見るSQLです。どちらも大切ですが、仕事はちがいます。
図解で整理
外部キーで2つの表をつなぐイメージ
顧客テーブル
| 顧客ID（主キー） | 名前 |
|---|---|
| C01 | 田中 |
| C02 | 鈴木 |
注文テーブル
| 注文ID | 顧客ID（外部キー） | 商品 |
|---|---|---|
| 1001 | C01 | 本 |
| 1002 | C01 | ペン |
注文表のC01を見ると、「誰の注文か」を顧客表からたどれます。
ここで、主キーと外部キーのちがいを一度まとめます。主キーは「その表の中で1行を見分けるための番号」、外部キーは「別の表の番号を借りて関係をつなぐ番号」です。見た目は似ていますが、役割ははっきりちがいます。
| 主キー | 外部キー |
|---|---|
| そのテーブルの行を一意に見分ける | 別テーブルの主キーを参照する |
| 重複しない値にする | 相手側に本当にある値だけを使う |
| テーブルの「本人確認」 | テーブル同士の「つながりの証明」 |
この違いをひとことで言うと、主キーは「自分の表の代表」、外部キーは「ほかの表との橋」です。橋があると行き来しやすくなりますが、橋の先に相手がいないと困ります。だから、外部キーには相手の表との整合性を守る意味があります。
実務では、外部キーを付ければ終わりではありません。削除時の動き、更新時の動き、NULL を許すかどうかなど、運用ルールを合わせて考えることが大切です。必要以上に制約を増やしすぎると、逆に管理しにくくなることもあるので、データの流れに合わせて設計します。
3問クイズ
Q1. 外部キーの説明として、いちばん近いものはどれ？
A. テーブル内で行を一意に見分ける列
B. 別テーブルの主キーを参照して関係を保つ列
C. 文字を自動で大きくする機能
D. 画面の色を変える機能
答えを見る
答え：B. 別テーブルの主キーを参照して関係を保つ列です。
Q2. 外部キーがあると、どんなミスを防ぎやすい？
A. 存在しない相手のIDを入れるミス
B. パソコンの電源が切れるミス
C. 文字入力のスピードが落ちるミス
D. 画面を印刷できないミス
答えを見る
答え：A. 存在しない相手のIDを入れるミスです。
Q3. 外部キーと特に相性がよいものはどれ？
A. ER図
B. 画像編集ソフト
C. 音楽再生アプリ
D. ZIPファイル
答えを見る
答え：A. ER図です。
まとめ
外部キーとは、別テーブルにある主キーなどの一意な値を参照して、データ同士の関係を守る列、または列の組み合わせです。主キーは自分の表の本人確認、外部キーはほかの表とのつながりを保つ役目です。正規化、JOIN、ER図 と一緒に覚えると、データベース設計がぐっと理解しやすくなります。まずは「テーブルを安全につなぐ約束」と覚えましょう。
