it

ER図の外部キー・FKとは?書き方と設定方法を解説!(FK・複合キー・主キー・リレーション・データベース設計など)

当サイトでは記事内に広告を含みます

ER図を学んでいると「外部キー」や「FK」という言葉が頻繁に登場します。

「主キーとの違いがよくわからない」「どのテーブルにどう設定すればいいのか迷う」という方も多いのではないでしょうか。

外部キー(FK)は、テーブル間のリレーションを実現するうえで欠かせない仕組みであり、データベース設計の精度を左右する重要な要素です。

この記事では、外部キーの意味・主キーとの違い・ER図での書き方・実際の設定方法・複合キーとの関係まで、図を交えてわかりやすく解説していきます。

外部キー(FK)とは別テーブルの主キーを参照する列のことである

それではまず、外部キー(FK)とは何かという結論から解説していきます。

外部キー(Foreign Key・FK)とは、あるテーブルの列が別のテーブルの主キーを参照していることを示す仕組みです。

たとえば「注文テーブル」に「顧客ID」という列がある場合、この「顧客ID」は「顧客テーブル」の主キー「顧客ID」を参照しています。

この「注文テーブルの顧客ID」が外部キーにあたります。

外部キー(FK)の定義

外部キーとは、あるテーブルの列が他のテーブルの主キー(PK)を参照するように設定された列のことです。

外部キーを設定することで「参照先に存在しない値は登録できない」という参照整合性制約が働き、データの一貫性が自動的に保たれます。

外部キーはER図においてテーブル間をつなぐ線の根拠となるものです。

ER図の線が「リレーションの存在」を視覚的に示しているとすれば、その実体がデータベース上の外部キーといえるでしょう。

主キー(PK)と外部キー(FK)の違い

主キーと外部キーは混同されやすいですが、役割がまったく異なります。

主キーは「そのテーブル内でレコードを一意に識別するための列」であり、外部キーは「別テーブルの主キーを参照するための列」です。

項目 主キー(PK) 外部キー(FK)
役割 レコードを一意に識別する 他テーブルの主キーを参照する
重複 許可されない 許可される(1対多のため)
NULL 許可されない 設定によって許可される場合がある
設定場所 すべてのテーブルに1つ リレーションがある「多」側のテーブル
ER図での表記 「PK」と記載・下線を引く 「FK」と記載・斜体にする場合も

1つのテーブルに主キーは必ず1つ(または複合キーとして複数列)存在しますが、外部キーは複数設定することができます。

参照整合性制約とは何か

外部キーを設定することで「参照整合性制約」が働きます。

参照整合性制約とは、外部キーに設定できる値を参照先テーブルの主キーに存在する値だけに制限する仕組みです。

たとえば「顧客テーブルに存在しない顧客IDを注文テーブルに登録しようとするとエラーになる」という制約が自動的に働きます。

これによってデータの整合性が保たれ、孤立したレコード(親テーブルに対応するレコードがない子テーブルのレコード)が生まれるのを防ぐことができるでしょう。

ER図での外部キーの書き方

続いては、ER図における外部キーの書き方を確認していきましょう。

ツールや記法によって表現方法は異なりますが、基本的なルールは共通しています。

エンティティ内でのFKの表記方法

ER図のエンティティ(テーブルを表す四角い箱)の中では、外部キーの列名の横に「FK」と記載するのが一般的です。

主キーが「PK」と記載されるのと同様に、「FK」の表記でひと目でリレーション用の列だとわかるようにします。

エンティティ内の表記例

注文テーブル

注文ID (PK) ← 主キー

顧客ID (FK) ← 外部キー:顧客テーブルのPKを参照

注文日

合計金額

ツールによってはFKの列をイタリック体にしたり、色を変えたりして視覚的に区別できるよう表示するものもあります。

リレーション線とFKの対応関係

ER図において、2つのエンティティを結ぶ線は「どちらかのエンティティにFKが存在する」ことを意味します。

1対多のリレーションでは必ず「多」側のエンティティにFKを持たせるのが基本ルールです。

線の「多」側の端がFKを持つテーブル、「1」側の端がPKを持つテーブルという対応関係になります。

この関係を正しく把握することで、ER図の線を見るだけでどのテーブルにFKがあるかを即座に判断できるようになるでしょう。

ER図でのFK表記と線の対応
顧客
顧客ID(PK)
氏名
メール
1(PK側)

多(FK側)
注文
注文ID(PK)
顧客ID(FK)
注文日
「多」側の注文テーブルにFKを持たせ、「1」側の顧客テーブルのPKを参照している

複数の外部キーを持つテーブルの書き方

1つのテーブルが複数の外部キーを持つケースもよくあります。

中間テーブルがその典型例で、「注文明細テーブル」であれば「注文ID(FK)」と「商品ID(FK)」の2つの外部キーを持ちます。

ER図では各FKに対して対応するエンティティへの線を引くため、中間テーブルからは複数の線が伸びる形になります。

複数のFKが存在するテーブルは、ER図上でリレーションの中心的な役割を担うテーブルとして識別できるでしょう。

外部キーの設定方法(SQLでの記述)

続いては、実際にデータベースで外部キーをSQLで設定する方法を確認していきましょう。

ER図の設計をデータベースに実装する際に必要な知識です。

CREATE TABLE時のFK設定方法

テーブル作成時にFKを設定するには、FOREIGN KEY句を使います。

「FOREIGN KEY(列名)REFERENCES 参照先テーブル名(参照先列名)」という形式で記述します。

外部キー設定のSQL例

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列(PK)」を参照する外部キーとして設定されています。

この設定により、customersテーブルに存在しないcustomer_idはordersテーブルに登録できないという制約が働きます。

CASCADE(カスケード)オプションとは

外部キー設定時には「ON DELETE」「ON UPDATE」オプションでカスケード動作を指定できます。

カスケードとは、参照先のレコードが削除・更新された場合に、参照元のレコードに対して自動的に処理を連鎖させる仕組みです。

オプション 動作
CASCADE 参照先が削除・更新されると参照元も自動で削除・更新される
SET NULL 参照先が削除されると参照元のFK列がNULLになる
RESTRICT 参照元が存在する限り参照先の削除・更新をエラーにする
NO ACTION RESTRICTと同様(デフォルト)

カスケード設定を正しく選択することで、データ削除時の整合性を自動的に管理できるようになります。

どのオプションが適切かはシステムの要件によって異なるため、設計段階でしっかり検討しておきましょう。

既存テーブルへのFK追加方法

すでに作成済みのテーブルにあとからFKを追加する場合は、ALTER TABLE文を使います。

既存テーブルへのFK追加SQL例

ALTER TABLE orders

ADD CONSTRAINT fk_customer

FOREIGN KEY (customer_id) REFERENCES customers(customer_id);

CONSTRAINT句でFK制約に名前を付けておくと、後からFKを削除・変更する際に便利です。

FK制約名は「fk_テーブル名_参照先テーブル名」のような命名規則を統一して使うと管理しやすいでしょう。

複合キーとFKの組み合わせ

続いては、複合キーと外部キーの関係について確認していきましょう。

中間テーブルの設計でよく登場する組み合わせです。

複合キーとは何か

複合キーとは、複数の列を組み合わせて主キー(PK)として扱う設計手法です。

単独の列では一意性を保てない場合に使います。

中間テーブルの典型例として「注文明細テーブル」では「注文ID」と「商品ID」の組み合わせで1レコードを一意に識別するため、この2列の組み合わせが複合キー(複合主キー)になります。

複合キー(PK)とFK の組み合わせ
注文
注文ID(PK)
注文日

注文明細(中間テーブル)
注文ID(PK・FK)
商品ID(PK・FK)
数量
↑この2列が複合主キー

商品
商品ID(PK)
商品名
注文明細テーブルの「注文ID+商品ID」が複合PKであり、それぞれ外部キー(FK)でもある

複合キーのSQL設定方法

複合キーをSQLで設定する場合は、PRIMARY KEY句に複数の列名をカンマ区切りで指定します。

複合キー設定のSQL例

CREATE TABLE order_items (

order_id INT,

product_id INT,

quantity INT,

PRIMARY KEY (order_id, product_id),

FOREIGN KEY (order_id) REFERENCES orders(order_id),

FOREIGN KEY (product_id) REFERENCES products(product_id)

);

上記のように、複合PKを構成する2列がそれぞれ別テーブルへのFKでもある、という設計が中間テーブルの基本パターンです。

FKを設定する際によくある間違いと注意点

FK設定でよくある間違いとして、参照先テーブルが存在しない状態でFKを設定しようとするケースがあります。

FKは参照先テーブルと列が先に存在していないと設定できないため、テーブルの作成順序に注意が必要です。

また、参照先の列と参照元の列はデータ型を一致させる必要があります。

型が異なるとFKの設定自体がエラーになるため、ER図の設計段階からデータ型を統一して定義しておくことが重要でしょう。

FK設定の正しい手順と注意点
参照先テーブルより先に参照元テーブルを作成しようとする → エラー
FKと参照先PKのデータ型が異なる(INT vs VARCHAR) → エラー
参照先テーブル(PKあり)を先に作成する
FKと参照先PKのデータ型を一致させてから設定する

まとめ

この記事では、外部キー(FK)の意味・主キーとの違い・ER図での書き方・SQLでの設定方法・複合キーとの関係について解説しました。

外部キーとは別テーブルの主キーを参照する列のことで、テーブル間のリレーションをデータベース上で実現する仕組みです。

1対多のリレーションでは「多」側のテーブルにFKを持たせるのが基本ルールであり、中間テーブルでは複数のFKが複合キーを構成することになります。

参照整合性制約やカスケードオプションを正しく設定することで、データの一貫性を自動的に保つことができるでしょう。

ER図の設計段階からFKの位置とデータ型を明確にしておくことが、堅牢なデータベース構築への近道です。