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

以下の項目を埋める設問ですが、以下の不要項目を追加してしまいました。なぜ不要なのか分かりませんでした。お忙しいところ大変申し訳ございませんが、どなたかご教示願えませんでしょうか？

f:ユニット受注明細＝仕入取引先コード
⇒解答根拠の設問文「購買ユニット場合の場合は仕入先に発注する」の仕入先に発注するという文言で仕入先取引先コードが必要と判断してしまいました。
h:ソフトウェア受注明細＝仕入取引先コード
⇒解答根拠の設問文「製造部門の要求に応じて、製造を指図するか、仕入先に発注するかを決める」の仕入先に発注するという文言で仕入先取引先コードが必要と判断してしまいました。
j:すり合わせ部品設計＝技術営業社員コード
⇒解答根拠の設問文「すり合わせ部品の設計は、受注を担当した技術営業社員が行う」の文言で技術営業社員コードが必要と判断してしまいました。

よろしくお願いいたします。

f:ユニット受注明細＝仕入取引先コード
⇒解答根拠の設問文「購買ユニット場合の場合は仕入先に発注する」の仕入先に発注するという文言で仕入先取引先コードが必要と判断してしまいました。
h:ソフトウェア受注明細＝仕入取引先コード
⇒解答根拠の設問文「製造部門の要求に応じて、製造を指図するか、仕入先に発注するかを決める」の仕入先に発注するという文言で仕入先取引先コードが必要と判断してしまいました。

この2つはいずれも、他のテーブルに仕入れ先の情報が記載されているので書かなくていいという事でしょうね．
テーブル設計によってはfやhに対して仕入れ先の情報を書く場合もあるでしょうが，その場合製造指図に関しての属性も書かなくてはならず，製造指図と仕入れ先への発注は排他的なのでどちらかが常にNULLになるという考え難い設計になります．．．

j:すり合わせ部品設計＝技術営業社員コード
⇒解答根拠の設問文「すり合わせ部品の設計は、受注を担当した技術営業社員が行う」の文言で技術営業社員コードが必要と判断してしまいました。

受注を担当した技術営業社員は，受注#→商談から一意に定まりますので，技術営業社員コードを書いてしまうと受注との関係性がわからなくなってしまいます．
受注#と社員コードの両方を書いてしまった場合，主キー→受注＃→営業担当社員コード
の推移的関数従属が発生してしまうので不適切です．