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

答えは c です。

「注文表の顧客番号」は「顧客表の顧客番号」を参照する外部キー。つまり、注文に書ける顧客番号は顧客表に存在する番号だけ。選択肢cは新しい顧客番号F020を注文に追加していて、顧客表にF020がないので参照できず、整合性が壊れます。

👉 覚え方：参照整合性＝「相手の表にある値だけ使える」。

ほかの選択肢：a L035削除＝注文表にL035の参照なし→OK／b D010追加＝顧客表にD010あり→OK／d K001削除＝注文がなくなるだけ→OK。

なぜこれが正解か

正解は c。参照整合性（referential integrity）は「外部キーの値は参照先の主キーに存在しなければならない」という制約。

• 顧客表の主キー：C005、D010、K001、L035
• 注文表に新規行 0006 / F020 を追加 → F020は顧客表に存在しない → 参照整合性違反

各選択肢の解説

• a：顧客L035の削除。注文表にL035を参照する行がないので問題なし。
• b：注文に0005/D010の追加。D010は顧客表に存在するため整合。
• d：注文表の0002/K001の削除。子側の削除なので参照整合性に影響しない。

覚え方・ひっかけ注意

参照整合性違反は2方向：①外部キー側で「存在しない値」を入れる（追加・更新時）、②主キー側で「参照されている値」を削除・変更する（削除・更新時）。外部キー制約の動作（CASCADE/SET NULL/SET DEFAULT/RESTRICT/NO ACTION）も応用情報で問われる。

理論的背景

リレーショナルモデルの3つの整合性制約：①実体整合性（Entity Integrity）：主キーはNULL不可・一意、②参照整合性（Referential Integrity）：外部キーは参照先の主キーに存在するか、NULL（オプショナルな場合）、③ドメイン制約：列の値は定義された値域内。E.F.Coddの1970年論文以来、リレーショナルDBの基本制約として組込まれている。

実務での使われ方

DBMSのFOREIGN KEY制約でON DELETE / ON UPDATE時の動作を指定する：①NO ACTION/RESTRICT（参照あり時は操作拒否）、②CASCADE（連鎖削除・連鎖更新）、③SET NULL（外部キーをNULL設定）、④SET DEFAULT（デフォルト値に設定）。MySQL InnoDB・PostgreSQL・Oracle・SQL Serverともこれらの動作を実装。アプリケーション層でも対応する一貫性チェックが必要で、ORM（Hibernate・Entity Framework・SQLAlchemy・Active Record）が支援する。

試験での位置づけ

基本情報・応用情報のデータベース分野で必出。3つの整合性制約、外部キー制約の動作オプション、CRUD操作と整合性の関係、トランザクションのACID特性（特に一貫性Consistency）と組み合わせて出題される。データベーススペシャリストでは分散DB・レプリケーション環境での整合性、結果整合性（Eventual Consistency）、CAP定理が深掘りされる。

選択肢の発展補足

NoSQLデータベース（MongoDB、Cassandra、DynamoDB等）の多くは参照整合性をDB側で保証せず、アプリケーション側で実装する設計。マイクロサービスアーキテクチャでは各サービスがDBを独立保有するため、参照整合性は分散システム全体で「結果整合性」として保証する Saga パターンや Outbox パターンで実現する。CAP定理（一貫性Consistency・可用性Availability・分割耐性Partition tolerance のうち2つしか同時に達成できない）はNoSQL選択時の理論的背景。BASE特性（Basically Available・Soft state・Eventually consistent）はNoSQLの一般原則で、ACIDとのトレードオフとして理解する。