データベーススペシャリスト 試験情報＆徹底解説

図2 関係スキーマの「案件」の属性の中に外部キーとして「担当営業部コード」がありますが、必要ないのでは？と思いました。
「案件」の属性には「顧客番号」があるので、それをもとに「顧客」→「顧客グループ」→「営業部」と遡れば「担当営業部コード」は特定されるはずなのでそう思ったのですが、いかがでしょうか？
まあ、問題文にそう書いてあるんだから気にするなということかもしれませんが、これだと顧客と営業部が矛盾する恐れがあるような気がしたものでこちらでおうかがいしてみた次第です。

細かいところまで見てないですが、たしかにそうですね。

ただ、今回のように「担当営業部コード」を特定するためにガチガチに正規化しない例もあります。
ご記載の通り、複数テーブルを結合する必要があり
営業部ごとの案件数の集計をするなどの場合は都度結合が発生するためです。
一切の冗長な列を持たせない、ガチガチの正規化をしない典型としては
・その列を見つけるために計算コストの高い結合（データ量が大きい、複数回など）が発生する
・その列がほぼ値が変わらない。夜間バッチなどで最新の値にすればいい。

今回の例だと
・案件ごとの担当営業部コードは実務上かなり使用頻度が高い
・都度、必要テーブルの結合により抽出するのは時間がかかる
・深夜のバッチ処理で「担当営業部コード」列を最新状態にして、通常業務ではそれを使用する
ということなのかなと思いました。

ご回答ありがとうございます。
おっしゃる通り、このケースでは案件ごとの担当営業部は変更されることはないと思いますし、もし担当営業部コードを持たせていなかったら例えば「担当営業部名」を求めるためにテーブルを4つも結合する必要が出てきますね。

とりあえず私の抱いた疑問が何かの見落としによるものではないことがわかってひと安心しました。
私はガチガチ正規化派なのでついつい気になってしまいました。
ありがとうございました。

この投稿は投稿者により削除されました。(2022.07.01 02:10)

こちらですが「案件」に「担当営業部コード」を持っているのは
『案件発生当時に担当していた営業部』を履歴として残すためだと思います。

例えば案件発生当時の顧客グループAの担当が第一営業部だったとします。
月日が流れ、顧客や会社都合などで顧客グループAの担当が第二営業部に切り替わり、顧客の過去の案件を探ろうとした時に該当案件の顧客番号から担当を辿ってしまうと、今現在担当の第二営業部が紐づいてしまい、案件発生当時に対応したのは第一営業部なのに、第二営業部が対応したかのような情報になってしまいます。

案件のような都度発生するタイプの情報をデータベースに残すときは、
発生当時の情報を履歴として残すという可能性を考慮してみるといいかもしれません。

※ちょっと書き直しました。

そうですね、「案件」テーブルはあくまで案件の履歴ですね。
「案件」に紐づく担当部署を記録しているので
「顧客」に紐づく担当部署を反映すると結果が変わっちゃいますね。。

ありがとうございます。
「担当営業部コード」は「案件変更履歴」テーブルにも持っている列なので、担当営業部が変わるのならそこに記録すればいいのでは？  と思いましたが、『「受注」になった以降は案件が変更されることはない』と書かれているのでダメですね。
マスタテーブルではないのであくまでも案件発生当時の記録ということと捉えるようにします。
わかりやすいご説明をありがとうございました。