令和8年度 ITパスポート試験 公開問題 問72 解説 データベースの参照整合性

この問題の解き方は、表同士の「依存関係」を確認し、先に存在しなければならない親から順番にデータを登録することです。今回のケースでは、顧客がいなければ口座を作れず、口座がなければ取引明細を作れないという親子関係があるため、顧客→口座→取引明細の順で登録する必要があります。

参照整合性制約という考え方

この問題の核心は、関係データベースにおける「参照整合性制約」というルールにあります。これは、データベースのデータの整合性を保つための非常に重要な仕組みです。

具体的には、外部キーとして設定されている項目には、必ず対応する主キー（参照先のデータ）が存在していなければならないというルールです。

1. 顧客表の「顧客番号」は、口座表の「顧客番号（外部キー）」から参照されています。つまり、先に顧客表にデータを登録しないと、口座表のデータが「どこの誰の口座かわからない」状態になってしまい、エラーになります。
2. 同様に、口座表の「口座番号」は、取引明細表（図には明示されていませんが、取引には必ず対象の口座が必要なため）から参照されます。そのため、口座を作ってからでないと、取引記録を生成することはできません。

このように、外部キー制約がある場合、子となる表にデータを挿入するよりも先に、親となる表にデータを挿入しておく必要があるのです。

実務での活かし方

システム開発の現場では、この順序を意識しないとデータの不整合やプログラムエラーが多発します。

例えば、ECサイトでユーザーが注文する場面を想像してください。

1. ユーザー情報が登録される（顧客テーブル）
2. 注文情報が作成される（注文ヘッダーテーブル：ユーザーIDを参照）
3. 注文した商品の詳細が記録される（注文明細テーブル：注文IDを参照）

もし、この順番を守らずに「注文明細」から先に作成しようとすれば、注文番号がまだ存在しないためシステムは処理を拒否します。このように、業務プロセスをデータベース設計に落とし込む際、どのデータがどのデータに依存しているのかを整理することは、ITエンジニアにとって必須のスキルです。

また、逆にデータを削除する際は、この逆の順序（子から先に削除する）が必要になります。親である「顧客」を削除しようとしても、その顧客に紐づく「口座」データが残っていると、データベースは「まだデータが使われているので削除できません」と警告を出します。データのライフサイクル管理において、この制約を理解しておくことは、データの安全を守るための基礎知識となります。

参考リンク

• データベースの整合性（参照整合性）を分かりやすく解説！
• リレーショナルデータベースにおける「主キー」と「外部キー」の役割
• 参照整合性（Wikipedia）