ITパスポート 令和8年度 問72：databaseに関する問題

答えは b（顧客 → 口座 → 取引明細） です。

これは「親がいないと子は登録できない」という順番のお話です。

まず“お客さん”がいて、そのお客さんが“口座”を作り、その口座で“入金などの取引”をします。つまり順番は、お客さん → 口座 → 取引、と上から下に流れていきます。

たとえば、家を建てる前に「土地」がいるように、口座を作る前に「お客さん」がいないといけません。取引も、口座がないと記録できません。

👉 覚え方：「親（おおもと）から先に登録」。だれ→どこ→なにをした、の順。

ほかの選択肢は、口座やお客さんがまだ無いのに先に作ろうとしていて、つじつまが合いません。

なぜこれが正解か

正解は b（顧客 → 口座 → 取引明細）。外部キー（FK）は他の表の主キー（PK）を参照するため、参照先の行が先に存在していなければデータを追加できない（参照整合性制約）。本問では、口座表が顧客番号(FK)で顧客表を参照し、取引明細表が口座番号(FK)で口座表を参照する。したがって「顧客→口座→取引明細」の順でなければ、FKの参照先が見つからずエラーになる。

各選択肢の解説

• a 口座→顧客→取引明細：口座を入れる時点で参照先の顧客がまだ無く不可。
• c 顧客→取引明細→口座：取引明細を入れる時点で参照先の口座がまだ無く不可。
• d 取引明細→口座→顧客：最初の取引明細で口座・顧客が無く不可。

覚え方・ひっかけ注意

「FKを持つ表は後（あと）」「参照される側（PK側）が先」と覚える。矢印は子→親に伸びるので、登録は親→子の順。削除はこの逆順（子から消す）になる点も合わせて押さえる。

理論的背景

関係データベースにおける外部キー制約（Referential Integrity Constraint）とデータ挿入順序の問題は、参照整合性の維持が根底にある。本問正解bの「顧客→口座→取引明細」の挿入順序は、外部キー制約の方向性（親テーブルが先）から導かれる。

依存関係の分析：口座表の顧客番号（FK）→顧客表の顧客番号（PK）を参照するため、顧客が存在しない口座は作成できない。取引明細表の口座番号（FK）→口座表の口座番号（PK）を参照するため、口座が存在しない取引明細は作成できない。したがって挿入順序は「参照される側（親）から参照する側（子）へ」の原則で決定：顧客（祖父母）→口座（親）→取引明細（子）。

これはデータモデリングの「依存関係グラフのトポロジカルソート（Topological Sort）」の概念に対応する。親子関係を有向グラフで表現した場合、外部キーの方向（子→親）と反対方向（親→子）にデータを挿入することで整合性が維持される。DBMSのトランザクション処理でも同じ原理が適用される。

実務での使われ方

ETL（Extract-Transform-Load）処理・データマイグレーション・テストデータ投入では外部キーを持つテーブルの挿入順序管理が重要な実装上の課題となる。Liquibase・Flyway等のデータベースマイグレーションツールでは、SQLスクリプトの実行順序を制御するためにchangelogファイルで依存順を明示的に管理する。

大規模マイグレーション時は外部キー制約を一時的に無効化（MySQL：`SET FOREIGN_KEY_CHECKS=0`・PostgreSQL：`SET session_replication_role = replica`）して挿入後に再有効化する手法も使われるが、データ整合性の問題を引き起こすリスクがあるため慎重な適用が必要。マイクロサービスアーキテクチャでは「Saga パターン」（分散トランザクションをイベント駆動の連鎖として実装）がデータ一貫性管理の現代的手法として採用されており、各サービスのDB挿入順序もSagaのコレオグラフィ・オーケストレーションで制御される。

試験での位置づけ

外部キー制約とデータ挿入順序の問題はITパスポートのデータベース分野で出題される応用問題。参照整合性の理解（親テーブルが先に存在する必要がある）を実際のデータ操作シナリオに適用できることが求められる。本問のような「具体的な業務シナリオ（口座開設と入金）」での挿入順序判断は、ERD（Entity-Relationship Diagram）の理解と外部キーの依存方向の把握が鍵。近年のITパスポート試験では銀行システム・ECサイト・病院システム等の実業務に近いDBモデルを題材にした問題が増えている。基本情報技術者試験ではSQL（INSERT文の実行順序・トランザクション制御・外部キー制約違反時のエラー処理）・カスケード設定（ON DELETE CASCADE等）の動作まで問われる。

選択肢の発展補足

選択肢aの「口座→顧客→取引明細」が誤りな理由：口座表に顧客番号のFKがあるため、顧客が存在しない状態で口座を挿入しようとすると外部キー制約違反エラーが発生する。選択肢cの「顧客→取引明細→口座」が誤りな理由：取引明細表に口座番号のFKがあるため、口座が存在しない状態で取引明細を挿入するとエラーになる。選択肢dの「取引明細→口座→顧客」は最も依存関係を逆順にした誤り例で、全ステップで外部キー制約違反が連続する。本問で示されたDB設計（顧客→口座→取引明細の3層構造）は、実際の銀行勘定系システムのコアモデルを大幅に単純化したものであり、実際には口座種別（普通/定期/外貨等）・支店情報・利率マスタ等の参照テーブルが追加され、挿入順序管理の複雑度は大幅に増す。データ品質管理（DQM）の観点では参照整合性の維持がデータの正確性確保の基本原則の一つとして位置づけられている。