DP-900：Microsoft Azure Data Fundamentals Azure のリレーショナルデータ 問7
Azure のリレーショナルデータ／リレーショナルの概念受注システムで、受注テーブルの顧客ID列に、顧客テーブルに存在しない値が誤って登録される事例が複数回発生している。アプリケーション側の入力チェックだけでなく、データベース側でも存在しない顧客IDを持つ受注行の登録を確実に防ぎたい。この目的を達成するためにテーブル設計で行うべきことはどれか。
当サイトのオリジナル問題（DP-900：Microsoft Azure Data Fundamentalsの出題範囲「Azure のリレーショナルデータ」に対応。実際の試験問題ではありません）
- A受注テーブルの顧客ID列にCHECK制約を定義し、入力できる値の範囲をあらかじめ指定する
- B受注テーブルの顧客ID列に、顧客テーブルの主キーを参照する外部キー制約を定義する
- C受注テーブルの顧客IDと受注日を組み合わせた複合主キーに変更する
- D受注テーブルの顧客ID列に一意インデックス（UNIQUE INDEX）を作成する
正解：B
解説
外部キー制約は、子テーブル（本問では受注テーブル）の列に入力できる値を、親テーブル（顧客テーブル）の主キーまたは一意キーに実際に存在する値だけに限定する仕組みです。受注テーブルの顧客ID列に顧客テーブルの主キーを参照する外部キー制約を定義すれば、存在しない顧客IDを持つ行の登録はデータベースエンジンによって拒否されるため、参照整合性を保てます。CHECK制約は値の範囲や形式を検証するだけで他テーブルの実在チェックはできず、複合主キーや一意インデックスも重複防止の仕組みであり、本問の目的には合いません。
選択肢ごとの解説
- A誤り。CHECK制約は列の値が指定した条件（範囲や形式など）を満たすかどうかを検証する仕組みであり、別のテーブルに実際に存在する値かどうかを確認することはできません。
- B正しい。外部キー制約を定義すると、その列に入力できる値は参照先テーブルの主キー（または一意キー）に実際に存在する値に限定されるため、存在しない顧客IDを持つ受注行の登録をデータベース側で確実に防げます。
- C誤り。主キーを複合主キーに変更しても、それは受注テーブル内での行の一意性を保証するだけであり、顧客テーブルに存在しない顧客IDが登録されることを防ぐ仕組みにはなりません。
- D誤り。一意インデックスは同じ列の値が重複して登録されることを防ぐ仕組みであり、値が別のテーブルに実際に存在するかどうかを検証する機能は持ちません。