最終更新日：2026年8月17日

fe fe-technology database sql

まず結論

参照整合性とは、ある表の外部キーが別の表を参照するときに、参照先として存在しない値を持たせないためのルールです。

基本情報技術者試験では、次の2つを先に確認すると判断しやすくなります。

子表へ行を追加
→ 外部キーの値が親表に存在するか確認

親表から行を削除
→ その値が子表から参照されていないか確認

子へ追加・親から削除をまず疑う。

これが、参照整合性の問題を解くときの中心となる判断基準です。

直感的な説明

社員と経費申請の関係で考えてみます。

社員表

社員番号 社員名
E001 田中
E002 鈴木
E003 佐藤

経費申請表

申請番号 社員番号 金額
R101 E001 5,000
R102 E003 12,000

経費申請表の 社員番号 が、社員表の 社員番号 を参照する外部キーだとします。

このとき、経費申請表に存在してよい社員番号は、社員表に存在する番号です。

社員表に E004 がない
↓
経費申請表へ E004 の申請を追加
↓
参照先が存在しない
↓
参照整合性に違反

逆に、経費申請表が E001 を参照しているのに、社員表から E001 を削除すると、申請データだけが残って参照先を失います。

経費申請表が E001 を参照中
↓
社員表から E001 を削除
↓
参照先が消える
↓
参照整合性に問題

つまり、参照整合性は親子関係が途中で切れないようにする仕組みと考えると分かりやすいです。

定義・仕組み

主キーと外部キー

主キーは、表の各行を一意に識別するための列です。

外部キーは、別の表の主キーなどを参照し、表同士の関係を表す列です。

先ほどの例では、次の関係です。

社員表
社員番号 ← 主キー
   ↑
   │ 参照
   │
経費申請表
社員番号 ← 外部キー

このとき、一般に

  • 社員表：親表
  • 経費申請表：子表

と考えます。

参照整合性が守られている状態

子表の外部キーに入っている値が、親表の参照先に存在している状態です。

子表の外部キー = E001
親表の主キーに E001 が存在
→ OK

一方、

子表の外部キー = E004
親表の主キーに E004 が存在しない
→ NG

となります。

操作ごとの基本判断

操作 参照整合性の観点
親表へ行を追加 基本的に問題になりにくい
親表から行を削除 子表から参照されていないか確認
子表へ行を追加 外部キーの値が親表に存在するか確認
子表から行を削除 基本的に問題になりにくい

科目Aでは、この4パターンを使って選択肢を切る問題がよく出ます。

SQLでは FOREIGN KEY と REFERENCES を使う

SQLでは、外部キーと参照先を次のように定義できます。

CREATE TABLE 社員 (
    社員番号 CHAR(4) PRIMARY KEY,
    社員名 VARCHAR(50)
);

CREATE TABLE 経費申請 (
    申請番号 CHAR(4) PRIMARY KEY,
    社員番号 CHAR(4),
    FOREIGN KEY (社員番号)
        REFERENCES 社員(社員番号)
);

ここでは、

FOREIGN KEY
→ 参照する側の列

REFERENCES
→ 参照先の表と列

を指定しています。

したがって、FOREIGN KEY と REFERENCES が出てきたら、参照制約・参照整合性を守るための定義だと判断できます。

このテーマは、基本情報技術者試験のデータベース分野に関係します。公式の出題範囲やシラバスは、IPA：基本情報技術者試験から確認できます。

科目Aでどう出る？

科目Aでは、親表と子表のデータを見て、どの追加・削除が参照整合性を損なうかを判断する形に注意します。

まず操作の向きを見る

問題文を読んだら、最初に次のどちらかを探します。

子表へ追加
親表から削除

この2つは、参照整合性を壊しやすい操作です。

子表へ追加する場合

社員表に次の社員がいるとします。

E001
E002
E003

経費申請表へ、

R103, E002

を追加するなら、E002 は社員表に存在するので問題ありません。

一方、

R104, E005

を追加しようとすると、社員表に E005 が存在しないため、参照整合性に違反します。

親表から削除する場合

経費申請表が E001 を参照している状態で、社員表から E001 を削除すると、子表の外部キーが参照先を失います。

子表が E001 を参照中
↓
親表から E001 を削除
↓
NG

一方、どの子表からも参照されていない社員なら、削除しても参照整合性は損なわれません。

SQLキーワードを問われる場合

操作ではなく、制約名を問う問題では次のように切り分けます。

キーワード・説明 対応する制約・用語
FOREIGN KEY + REFERENCES 参照制約
CHECK 検査制約
PRIMARY KEY 主キー
UNIQUE 一意性制約
NOT NULL NULL禁止 
別表の値との整合性
→ 参照制約

値の範囲や条件
→ CHECKによる検査制約

この違いも選択肢を切るポイントです。

どんな場面で使う？

参照整合性は、複数の表に分けてデータを管理するときに重要です。

例えば、次のような関係があります。

顧客表 ← 注文表
社員表 ← 経費申請表
商品表 ← 注文明細表
部署表 ← 社員表

もし参照整合性がなければ、存在しない顧客の注文や、存在しない商品の注文明細が登録される可能性があります。

顧客番号 C999 は顧客表に存在しない
↓
注文表に C999 の注文を登録
↓
誰の注文か分からない

このような不整合を防ぐために、データベースでは外部キー制約を設定します。

また、親表のデータを削除するときの動作として、DBMSでは次のような設定を使うことがあります。

設定例 動作
RESTRICT / NO ACTION 参照中なら削除を拒否する
CASCADE 子表側も連動して削除する
SET NULL 子表の外部キーをNULLにする

FE試験の基本問題では、まず参照中の親行を何の設定も考えずに削除すると問題になると押さえれば十分です。

よくある誤解・混同

子表から行を削除すると参照整合性違反になる？

通常はなりません。

子表の行を削除すると、その参照自体がなくなるだけです。

子表から削除
→ 参照が減る
→ 基本的に問題なし

親表に行を追加すると参照整合性違反になる？

通常はなりません。

親表に新しい参照先が増えるだけなので、既存の子表との関係を壊しません。

外部キーの値は必ず主キーと同じ列名？

列名が同じである必要はありません。

重要なのは、どの列を参照するように定義されているかです。

例えば、

社員表.社員番号
経費申請表.申請者ID

という別名でも、申請者ID が 社員番号 を参照する外部キーとして定義されていれば、参照関係は成立します。

外部キーには同じ値を複数回入れられない？

入れられます。

主キーは一意である必要がありますが、外部キーは複数行で同じ値を参照できます。

R101, E001
R105, E001

同じ社員が複数回申請することはあるので、この状態は問題ありません。

FOREIGN KEY と CHECK は同じ？

違います。

FOREIGN KEY + REFERENCES
→ 別表との参照関係を守る

CHECK
→ その列の値の条件を確認する

例えば、年齢が0以上という条件は CHECK、部署番号が部署表に存在するという条件は参照制約です。

確認問題（FE試験対策）

次の二つの表がある。

社員表

社員番号 社員名
E101 高橋
E102 山田
E103 伊藤

経費申請表

申請番号 社員番号
X001 E101
X002 E103

経費申請表の 社員番号 は、社員表の 社員番号 を参照する外部キーである。

参照整合性を損なう操作はどれか。

  • ア. 社員表に E104, 中村 を追加する
  • イ. 経費申請表から X002, E103 を削除する
  • ウ. 経費申請表に X003, E105 を追加する
  • エ. 社員表から、どの申請からも参照されていない E102, 山田 を削除する
▶ クリックして答えと解説を見る（ここを開く）

正解：ウ

E105 は社員表に存在しないため、経費申請表へ E105 を外部キーとして追加すると、参照先が存在しない状態になります。

  • ア：親表に新しい行を追加するだけなので問題ありません。
  • イ：子表の行を削除するので、参照が一つ減るだけです。
  • ウ：正解です。存在しない社員番号を子表から参照しています。
  • エ：子表から参照されていない親表の行なので削除できます。

👉 判断ポイント
子表へ追加するときは、その外部キーの値が親表に存在するか確認する。

まとめ（試験直前用）

  • 参照整合性は、子表の外部キーと親表の参照先の関係を正しく保つためのルール
  • 子表へ追加するときは、外部キーの値が親表に存在するか確認
  • 親表から削除するときは、子表から参照されていないか確認
  • 親表への追加と子表からの削除は、基本的に参照整合性を壊しにくい
  • FOREIGN KEY + REFERENCES は参照制約

子へ追加・親から削除をまず疑う。

© 2024-2026 stemtazoo. All rights reserved.