[https://www.youtube.com/watch?v=ebdDgVf2m1k:embed:cite]
この動画では、データベース設計において多くの人がつまずきやすい「外部キー」について、サクラ先輩と一緒に完全攻略します。令和6年秋期の試験問題である午前II問21を題材に、直感ではなく実務の現場に置き換えて選択肢を一つずつ検証していく思考プロセスを解説しています。試験対策としてはもちろん、システム開発の現場でも必須となる知識を、分かりやすい図解とともにお届けします。一緒に最強のエンジニアを目指しましょう。 データベースの関係モデルを理解する上で、外部キーは非常に重要な役割を担っています。外部キーとは、別の表、つまり関係の主キーまたは候補キーを参照するための列のことです。例えば、注文データを管理する子テーブルの中に顧客IDを持たせることで、誰がその注文を行ったのかを把握することができます。このように外部キーは、このデータはあちらの表に実在しますよ、ということを保証するための架け橋のような存在であり、この仕組みによって参照整合性が保たれています。もし参照先の関係に一致するデータが存在しない、幽霊会員からの注文を受け付けてしまったら、システムは大混乱に陥ってしまうため、これを防ぐことは外部キーの最大の役割と言えます。外部キーの制約条件について考えるとき、いくつか間違えやすいポイントがあります。まず、外部キーの値はその関係の中で必ずしも一意である必要はありません。もし一意でなければならないとしたら、一人の顧客が一度しか注文できないことになってしまいます。常連客が何度も注文できるように、同じ顧客IDが何度も出てきても問題ありません。次に、比較可能性についてです。外部キーは、それが参照する候補キーと比較可能である必要があります。数字のデータ型と文字のデータ型のように、データ型や構造が一致していないとコンピュータは照合ができないため、同じ型でなければ参照制約は成立しません。また、一つの関係に外部キーが複数存在しても構いません。実際の現場で使われる売上明細などの複雑な業務データは、商品や顧客、担当者など多くのマスタテーブルと紐付く必要があり、外部キーの個数に制限はありません。さらに、外部キーと主キーの違いとして、NULL、つまり空の値の扱いが挙げられます。主キーはNULLが禁止されていますが、外部キーはNOT NULL制約がない場合、設定次第でNULLが許容されます。例えば、担当者IDが外部キーとして設定されているものの、担当者がまだ決まっていない状態において、NULLでデータを登録することは可能です。ここを混同しないように注意が必要です。また、クラウド時代における最新の現場の視点も重要です。従来の試験で正解とされるOracleやPostgreSQLなどのリレーショナルデータベース管理システムでは、外部キー制約は必須級であり、データの整合性を厳密に守ることが求められます。しかし、マイクロサービスアーキテクチャや分散データベース、NoSQLなどが主流となっている最新の現場では、結果整合性によるパフォーマンスを優先するために物理的な外部キー制約をあえて外すこともあります。試験では教科書通りの厳密な正解が求められますが、実際の開発現場においてはパフォーマンスと整合性のトレードオフを考慮して設計する視点も併せて持っておくことがプロのエンジニアとして大切です。
