基本情報技術者 2016年 春期 午前(科目A) 問29
問題文
関係データベースにおいて、外部キーを定義する目的として、適切なものはどれか。
選択肢
ア:関係する相互のテーブルにおいて、レコード間の参照一貫性が維持される制約をもたせる。(正解)
イ:関係する相互のテーブルの格納場所を近くに配置することによって、検索、更新を高速に行う。
ウ:障害によって破壊されたレコードを、テーブル間の相互の関係から可能な限り復旧させる。
エ:レコードの削除、追加の繰返しによる、レコード格納エリアのフラグメンテーションを防止する。
🔒 解説は解答すると表示されます
外部キー制約【午前解説】
正解の理由
選択肢の中で外部キーの目的を正確に表しているのはアです。外部キー(foreign key)はリレーショナルデータベースにおいて、あるテーブル(子)が別のテーブル(親)の主キーまたは候補キーを参照することを明示し、その参照の整合性をデータベース側で保証するための制約です。これにより、存在しない親を参照する子レコードの挿入や、参照先が削除されて子側が孤立する事態を防止できます。したがって「参照一貫性が維持される制約をもたせる」というアの記述が正解です。
解法ステップ
- 問題文のキーワードを確認:「外部キー」「目的」「制約」「参照一貫性」などを探す。
- 各選択肢の述語が「論理的整合性(参照整合性)」か「物理的/運用的課題」かを分類する。
- 「参照一貫性」を直接表現する選択肢(ア)を正解とし、他は外部キーの役割と照らして排除する。
- 迷った場合は「外部キーはデータの存在関係を保証する制約である」と記憶しているか確認する。
選択肢別の誤答解説
- 正解: ア:関係するテーブル間で参照一貫性(参照整合性)を維持するための制約を定義する、これは外部キーの本質です。
- イ:格納場所を近くに配置して性能を上げるのは物理設計(パーティショニングやクラスタリング等)の話で、外部キーの目的ではありません。
- ウ:障害からの復旧はバックアップ/リカバリやレプリケーションの役割であり、外部キーは復旧機能を提供しません。
- エ:フラグメンテーション防止はストレージ管理やガベージコレクション、テーブル再編成等の話で、外部キー制約とは無関係です。
よくある誤解
- 「外部キーは物理的な配置(格納場所)を制御する」:外部キーは論理的な参照整合性の制約であり、データの物理的な配置やクラスタリングを指定するものではありません(イは誤り)。
- 「外部キーは障害からの自動復旧機能を持つ」:外部キーは整合性チェックを行うのみで、障害時の復旧やデータ復元をするメカニズムではありません(ウは誤り)。
- 「外部キーがフラグメンテーションを防ぐ」:レコードの断片化(フラグメンテーション)はストレージ管理やDBMSの物理配置・再編成の問題であり、外部キーは関係ありません(エは誤り)。
補足コラム
- 外部キーは参照整合性を保証する一方で、INSERT/UPDATE/DELETE 時に追加のチェックが入るため性能に影響を与える場合があります。実務では親キー/子キーに適切なインデックスを張ることで性能低下を軽減します。
- ON DELETE/ON UPDATE 句で参照時の振る舞いを指定できます(例:CASCADE=親削除で子も削除、SET NULL=子の外部キーをNULLにする)。DBMS によってデフォルト動作や制約のサポート状況が異なります。
- 外部キーは論理設計(ER図)での関係表現を物理設計にも反映させる重要な要素であり、データの整合性を保つ最も基本的な仕組みです。
FAQ
Q1. 外部キーは自動的にインデックスを作成しますか?
A1. DBMS によります。多くのDBMSでは参照される親側のキーはインデックスが必要であり、子側のカラムにもインデックスを張ることが推奨されますが、外部キー制約自体が必ずインデックスを作るわけではありません。実運用ではパフォーマンスのために明示的にインデックスを用意します。
A1. DBMS によります。多くのDBMSでは参照される親側のキーはインデックスが必要であり、子側のカラムにもインデックスを張ることが推奨されますが、外部キー制約自体が必ずインデックスを作るわけではありません。実運用ではパフォーマンスのために明示的にインデックスを用意します。
Q2. 外部キーのない設計はダメですか?
A2. 小規模や一時的な用途ではアプリケーション側で整合性を保つケースもありますが、長期運用や複数アプリがアクセスする環境ではデータベース側で外部キー制約を定義しておくのが安全です。
A2. 小規模や一時的な用途ではアプリケーション側で整合性を保つケースもありますが、長期運用や複数アプリがアクセスする環境ではデータベース側で外部キー制約を定義しておくのが安全です。
Q3. 循環参照(相互に外部キーを張る)は可能ですか?
A3. 技術的には可能ですが、削除や挿入の順序問題、参照整合性チェックで制約違反が発生しやすくなるため、設計上の配慮や制約の遅延(deferred constraint)が必要になることがあります。
A3. 技術的には可能ですが、削除や挿入の順序問題、参照整合性チェックで制約違反が発生しやすくなるため、設計上の配慮や制約の遅延(deferred constraint)が必要になることがあります。
関連キーワード: 外部キー、参照整合性、リレーショナルデータベース、制約、ON DELETE CASCADE、インデックス、論理設計

\ せっかくなら /
基本情報技術者を
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

