制約の内部：参照整合性・チェック制約の実行機構

制約は「宣言」だが実体は「実行コード」

FOREIGN KEY や CHECK、UNIQUE は宣言的に書きますが、DBMS 内部ではそれぞれ特定のタイミングで走る検証コードに変換されます。重要なのは「制約がいつ評価されるか」で、これを把握していないと、正しいはずの一括 INSERT が中途で失敗したり、無害に見える DELETE が連鎖して大量行を消したり、循環参照のあるデータを投入できずに行き詰まったりします。本稿では参照整合性・チェック・一意・遅延評価の4つを、内部の実行機構として分解します。

外部キー：内部トリガとしての実装

参照整合性制約（referential integrity）は、子表（参照する側）の外部キー列の値が、親表（参照される側）の候補キーに必ず存在することを保証します。多くのRDB（PostgreSQL、Oracle、InnoDBなど）はこれをシステムトリガ――ユーザーには見えない内部トリガ――として実装します。発火点は2方向あります。

ポイントは、検証が親表の候補キー側の索引探索で行われることです。子に行が入るたびに親キーの存在確認を行うため、参照先（親の候補キー）には索引が必須で、これは主キーや UNIQUE が自動的に張る一意索引で満たされます。一方、親の DELETE 側では「その親を指す子行」を探す必要があり、子表の外部キー列に索引が無いと全表走査になります。多くのRDBが子側の外部キー索引を自動作成しないため（InnoDB は作る）、親の削除・更新が遅い場合の典型原因がこれです。

子表 INSERT(fk=5) の検証（概念）:
  親表の候補キー索引で key=5 を探索
    存在する  → OK
    存在しない → 参照整合性違反でこの文を中断
親表 DELETE(pk=5) の検証（概念）:
  子表で fk=5 を持つ行を検索（子側索引が無いと全表走査）
    見つかった子行に対し ON DELETE のアクションを適用

カスケードと参照アクション

親側のUPDATE/DELETEで子行が宙に浮く（dangling reference）のを防ぐため、外部キーには参照アクションを指定します。これらは前述の親表側トリガが、見つかった子行に対して実行する処理です。

CASCADE は再帰的に作用します。A を親とする B、B を親とする C があり全て ON DELETE CASCADE なら、A の1行削除が B・C の関連行をまとめて消します。これは内部的に「親トリガが子の DELETE を発行 → その DELETE がさらに孫のトリガを発火」という連鎖で、削除行数も発火回数も実行時まで確定しません。NO ACTION と RESTRICT の違いも内部的で、RESTRICT はそのアクションの実行時点で即チェックするのに対し、NO ACTION は検査を文末（遅延可能制約なら後述のコミット時）まで先送りします。この差は、同一文の中で子を消してから親を消すような操作が NO ACTION だと通る、という形で現れます。

UNIQUE 制約：一意索引そのもの

一意制約（UNIQUE）と主キー（PRIMARY KEY）は、専用の一意索引によって実装されるのが普通です。制約と索引は概念上別物ですが、一意性の検証は「重複キーが既に索引に存在しないか」を索引探索で確かめる操作なので、RDBは制約宣言時に裏で一意索引を作成し、その索引のエントリ挿入時に重複を検出します。つまり UNIQUE 制約には索引依存があり、索引を介さずに一意性を保証する手段は実質ありません（→ クラスタ化インデックスと非クラスタ化インデックスの内部差、索引構造の詳細は B+Tree インデックスの内部構造）。

検証タイミングは行単位で、ある行の索引エントリを挿入する瞬間に、同じキーを持つ可視なエントリが無いかを確かめます。検出されれば一意制約違反です。NULL の扱いは三値論理に従い、多くのRDBでは NULL どうしは「等しいか不明」なので重複とみなされず、UNIQUE 列に複数の NULL を入れられます（→ 3値論理とNULLの意味論・落とし穴）。複合 UNIQUE では一部の列が NULL だと行全体が重複判定から外れる挙動が一般的です。

CHECK 制約：行単位の述語評価

CHECK 制約は、指定した述語（真偽を返す条件式）が各行について偽にならないことを要求します。評価は行のINSERT/UPDATE時に、その行の値だけを使って行われます。ここで三値論理が効きます。CHECK は「結果が FALSE のときだけ拒否」し、UNKNOWN（NULL を含む比較）は許容します。たとえば CHECK (price > 0) は price が NULL だと NULL > 0 = UNKNOWN となり、違反になりません。NULL を弾きたいなら別途 NOT NULL が要ります。

-- price=NULL は UNKNOWN なので CHECK を通過してしまう
CREATE TABLE item (
  price numeric CHECK (price > 0)   -- NULL は許される
);
-- NULL も弾くなら
CREATE TABLE item2 (
  price numeric NOT NULL CHECK (price > 0)
);

標準的な CHECK は単一行・現在値のみを参照でき、他の行や他テーブルを参照する集約・サブクエリは（多くのRDBで）使えません。テーブル横断や複数行にまたがる不変条件は CHECK では表現しきれず、トリガやアサーション相当の仕組みが必要です。

即時評価と遅延評価（DEFERRABLE）

ここまでの検証は既定で即時（immediate）――各文の終わりまでに評価されます。しかし DEFERRABLE INITIALLY DEFERRED を指定すると、制約検証をトランザクションのコミット時まで遅延できます（主に外部キーで使う。標準SQLの機能で、PostgreSQL・Oracle が対応、MySQL/InnoDB は外部キー検査の遅延を基本サポートしません）。

これが効くのは循環参照や相互参照のケースです。表 A が表 B を参照し、B も A を参照するとき、即時評価では「どちらを先に INSERT しても相手がまだ無い」ため詰みます。遅延制約なら、両方を INSERT してからコミット直前に一括検証するので、途中の不整合が許容されます。

-- 相互参照を成立させる典型
ALTER TABLE a
  ADD CONSTRAINT a_b_fk FOREIGN KEY (b_id) REFERENCES b(id)
  DEFERRABLE INITIALLY DEFERRED;

BEGIN;
  INSERT INTO a (id, b_id) VALUES (1, 10);  -- b(10) はまだ無いが遅延中なのでOK
  INSERT INTO b (id, a_id) VALUES (10, 1);  -- ここで両者が揃う
COMMIT;  -- ここで初めて両方向の参照整合性をまとめて検証

ロック・MVCCとの関係

参照整合性の検証は、検証中に親行が消えたり一意キーが二重挿入されたりしないよう、同時実行制御と協調します。外部キー検証は子のINSERT時に親行へ共有ロック（行ロック）を取り、検証完了まで親が削除・更新されないようにするのが一般的です。これが、無関係に見える子表へのINSERTが親表の更新と競合して待機やデッドロックを生む原因になります。複数トランザクションが互いの親行を参照し合うと、ロック獲得順序の食い違いでデッドロックに至ります（→ ロック方式の前提は 2相ロックと直列化可能性、評価タイミングと分離レベルの関係は トランザクション分離レベル）。一意制約も同様で、同じキーを同時に挿入しようとした2トランザクションは、一方が他方のコミット/ロールバックを待ってから重複判定が確定します。

まとめ

• 外部キーは内部のシステムトリガとして、子のINSERT/UPDATE時に親キー存在を、親のDELETE/UPDATE時に参照アクション（CASCADE等）を実行する。検証は親の候補キー索引を引くため参照先には索引が要り、親削除の性能には子側の外部キー索引が効く。
• UNIQUE/PRIMARY KEY は一意索引で実装され、索引エントリ挿入時に重複を検出する。NULL は三値論理で重複扱いされないのが多数派で、複数 NULL を許す（RDBで差あり）。
• CHECK は行単位で述語を評価し、結果が FALSE のときだけ拒否する。NULL を含む UNKNOWN は通すので、NULL 排除には NOT NULL を併用する。
• 制約は既定で即時（文単位）評価だが、DEFERRABLE INITIALLY DEFERRED でコミット時評価に遅延でき、循環参照や順序依存INSERTを成立させられる。代償として違反がコミット時に飛ぶ。
• 検証はロック・MVCCと協調するため、子のINSERTが親行へのロックを誘発し、想定外の待機・デッドロックの原因になりうる。