データベーススペシャリスト 2021年 午前2 問04

外部キー参照方向【午前2解説】

正解の理由

解法ステップ

1. 各表の下線を見て、主キー（実線）と外部キー（破線）を判定する。
2. 関係の各ペアについて、どちらの表が外部キーを持つかを確認する。
3. 外部キーを持つ側を「多（*）」、参照先（主キー）の側を「一（1）」に割り当てる。
4. 選択肢の表現と照合し、全ての関係が一致する選択肢を選ぶ。

選択肢別の誤答解説

• ア
  • 医師−診療科は正しく医師側が*、診療科側が1となっているが、診療科−診察で診療科側が*／診察側が1となっており逆になっている。また診察−患者も逆。よって不適切。
• イ
  • 医師()−診療科(1)、診療科(1)−診察()、診察(*)−患者(1) の三関係がすべて正しく表現されているため正解。
• ウ
  • 全ての関係が逆向き（医師側が1など）に示されており、外部キーのある側を「一」と誤認しているため誤り。
• エ
  • 診療科−診察および診察−患者は正しいが、医師−診療科が逆（医師側が1、診療科側が*）になっているため不正解。

よくある誤解

• 下線の種類を見落として、どちらが主キーか外部キーかを誤判定する（実線＝PK、破線＝FKの識別が重要）。
• 同じ属性名（例：診療科コード）が複数表に存在すると、双方で主キーだと誤認する。実際には片方が参照（FK）であることが多い。
• 外部キーがある＝必ず「多対一」になるが、実務では一意制約が付くこともあり得る（設計次第で1対1にもなる）。

補足コラム

• ER図→RDB設計の変換ルール（簡潔）
  • エンティティはテーブルに、実線下線の属性は主キー、破線下線は外部キーとして扱う。外部キーは参照整合性を保つため参照先の主キーを指す。
• 診察テーブルの主キーについての注意点
  • 問題図は診察に「診療科コード（FK）」「患者番号（FK）」「診察日時」があることを示すにとどまり、主キーの決定は明示されていません。業務的には同一患者が同一診療科で複数回診察を受ける可能性があるため、単に（診療科コード, 患者番号）を主キーにするのは不適切なことがあります。主キーの設計例としては次のような選択肢があります。
    • 診察ID（サロゲートキー）を主キーにして、診療科コード・患者番号は外部キーにする（運用上扱いやすい）。
    • （患者番号, 診察日時）の複合キーとする（診察日時が必ず一意に決まる場合）。
    • （診療科コード, 患者番号, 診察日時）の複合キーとする（業務要件次第）。
  • どの方法を採るかは、重複データの可否、検索性、参照の都合、業務ルール（診察を識別する単位）で決定してください。例：診察IDを主キーにするSQL例

    CREATE TABLE 診察 (
      診察ID INTEGER PRIMARY KEY AUTOINCREMENT,
      診療科コード CHAR(3) NOT NULL,
      患者番号 CHAR(10) NOT NULL,
      診察日時 DATETIME NOT NULL,
      FOREIGN KEY (診療科コード) REFERENCES 診療科(診療科コード),
      FOREIGN KEY (患者番号)   REFERENCES 患者(患者番号)
    );
    

FAQ

• Q: なぜ外部キー側が「多（*）」なのですか？
  A: 外部キーを持つ行は参照先の主キーの1行を指すが、同じ参照先を指す行が複数存在し得るため「多」になります（多対一の性質）。
• Q: もし両側に外部キーや主キーが混在していたら？
  A: どちらが参照しているか（外部キーの有無）を優先して判断します。両方に外部キーがある場合は別表を介した多対多の可能性など設計意図を読み取る必要があります。
• Q: 図に診察日時がある場合、それ単体で主キーにできますか？
  A: 診察日時が必ず一意であると保証できる業務仕様なら可能ですが、同一時刻に複数診察が発生し得るなら不適切です。業務要件に応じて選択してください。