基本情報 平成29年度 春期 問27：テクノロジ系に関する問題

答えは c「参照制約」 です。

FOREIGN KEY（外部キー）と REFERENCES は 「別の表のキーを“参照する”」 という意味の指定。たとえば「注文表のお客様IDは、必ず顧客表に存在するIDでないとダメ」というルールを作る仕組みです。これにより存在しないIDで注文できないようにデータの矛盾を防ぎます。

👉 覚え方：REFERENCES＝参照する＝参照制約、そのまま！

ほかの選択肢：a キー制約＝主キーやUNIQUEなど「ユニークさ」のルール／b 検査制約＝CHECK（年齢>0など値の妥当性チェック）／d 表明（ASSERTION）＝表全体のルール（実装DBはほぼなし）。

なぜこれが正解か

正解は c。SQLで `FOREIGN KEY (列名) REFERENCES 親表(列名)` と書くと、その列の値は親表の主キー（または一意キー）に存在する値しか格納できない、という参照制約（参照整合性制約）が設定される。子表の値が親表に必ず対応する状態を保証することで、データの矛盾（孤立行）を防ぐ。

各選択肢の解説

• a キー制約：PRIMARY KEY、UNIQUE 等。行の一意性を保証する。
• b 検査制約：CHECK 句で値の範囲・条件を制約（例：CHECK (age >= 0)）。
• c 参照制約：FOREIGN KEY / REFERENCES → 正解。
• d 表明（ASSERTION）：表をまたぐグローバル制約。SQL標準にあるが多くのRDBMSで未実装。

覚え方・ひっかけ注意

「Foreign（外部の）+ References（参照する）＝参照制約」と語感で覚える。`ON DELETE CASCADE / RESTRICT / SET NULL` 等の参照アクションも合わせて出題される。親行削除時の挙動を制御するこれら4種の意味も押さえておくこと。

理論的背景

参照整合性制約は関係モデルの3大整合性制約（実体整合性=主キー非NULL、参照整合性、ドメイン整合性=データ型・CHECK）の一つ。Coddの関係モデル理論で定義され、SQL-92以降の規格に正式採用。

参照アクション（referential action）

親表の行が削除・更新された際の挙動をFOREIGN KEY定義で指定可能：

• CASCADE：親変更が子に自動波及。
• SET NULL：子列をNULLに（子列がNOT NULLなら不可）。
• SET DEFAULT：子列をデフォルト値に。
• RESTRICT / NO ACTION：参照されている親行の変更を拒否（多くのRDBMSのデフォルト）。

性能・運用上の留意点

• 外部キーにはインデックスが自動付与されない（PostgreSQL等）ので、子表のFK列に手動でインデックス作成しないと親更新時に全表走査になる。
• 一括ロード時はFKを一時的に無効化（DISABLE / DEFERRABLE INITIALLY DEFERRED）して高速化する運用が一般的。
• マイクロサービスでは論理的FKにとどめDB物理FKを使わない設計も増えている（サービス境界とのトレードオフ）。

試験での位置づけ

FE「データベース」分野の超頻出。DDL（CREATE TABLE）の制約句、トランザクション整合性、正規化と並ぶ三大論点。応用情報・DBスペシャリストでは参照アクションの組合せや多対多関連表の設計まで深掘りされる。

選択肢の発展補足

dのASSERTIONはSQL標準では「複数表にまたがる任意のCHECK」を実現する強力な機能だが、OracleやMySQLなど主要DBは未実装。代替としてトリガで実装することが多い。CHECK制約も2017年のSQL標準で他表参照（部分問合せ）が許される拡張があるが実装は限定的。