検査制約とは？けんさせいやく
検査制約とは、データベースの列や行が満たすべき条件を宣言として定義し、条件に反する登録・更新をデータベース側で拒否する仕組み（CHECK制約）。業務ルールをアプリケーションの中ではなくデータの側に置くため、どの経路から書き込まれても守られる。ST試験の文脈では、データ品質を人の運用ではなく仕組みで担保するという設計方針の一例として押さえておけばよい。
最終更新：2026-10-06
ITストラテジストを最短で暗記・合格する →背景
同じデータベースへ書き込む経路は、画面からの入力だけとは限らない。他システムからの連携、一括取込み、緊急時の直接更新と増えていき、そのすべてに同じ確認処理を実装するのは現実的でない。どの経路からでも守りたいルールは、経路ごとの実装ではなくデータの置き場所で守る——この切り分けが、データ品質を維持する設計の基本になる。経営会議では「不正なデータが入るのを担当者の確認で防ぐのではなく、そもそも登録できない状態にします。人の注意力に依存する統制は、繁忙期に必ず破れます」と説明できると、内部統制の議論と接続しやすい。
具体例
「数量は1以上」「取引区分はA・B・Cのいずれか」「契約終了日は開始日以降」といった条件を定義しておけば、基幹システムの画面からでも、他システムからの夜間連携からでも違反データは弾かれる。基幹システム刷新でデータ移行を行う際は、この種の制約を先に定義してから旧データを流し込むことで、長年見過ごされてきた不正データが移行前に洗い出され、業務側でどう補正するかを決める材料になる。
試験での引っ掛け
条件の判定が確定しない場合（値が未設定のときの比較など）、この制約は違反とみなさず通してしまうため、値の未設定を禁じたいなら別の指定（NOT NULL制約）が要る。またすべての業務ルールをデータベース側へ寄せればよいわけではなく、部門や時期で変わるルールを制約として固定すると、変更のたびにデータベースの定義変更が必要になり、かえって硬直する。どのルールをデータ側に置き、どれをアプリケーション側に置くかの線引きが設計の判断になる。
出典・参考
解説は資格暗記が独自に作成しています。過去問の出典は各問題に記載のとおりです。