列を追加するテーブル："出荷"
追加する列："事業所コード"

解答では以上のようになっていますが、この回答を導くプロセスは以下であっていますか？

表２より、「商品別返品件数表」が"受注明細"の件数を集計して出力することを確認。
表３より、商品別返品件数表作成の処理は"受注明細"テーブルにアクセスしないことを確認。
今回の問題では、特に分割納品などの指定がない。むしろ、表１よりSKUごとに受注明細と出荷明細が作成されることから、"受注"-"出荷"、"受注明細"-"出荷明細"  とそれぞれ1対1になることを確認。
つまり、受注明細の件数を出力=出荷明細の件数を出力となる。
出荷明細をカウントすることから、"受注"テーブルではなく、"出荷"テーブルが集計の対象になる。
そして、事業所名を拾ってくるためには、出荷（受注番号）⇒受注（受注担当社員番号）⇒所属（事業所コード）⇒事業所（事業者名）とたどる必要があるが、出荷に事業者コードを持たせておけばこのルートをたどる必要がない。
よって、
列を追加するテーブル："出荷"
追加する列："事業所コード"

以上、長々と書いてしまいましたが、これであっているでしょうか。

おおよそ合っているかと思います。

IPAが出している解答例の理由として
「受注担当社員番号と受注年月日によって"所属"テーブルから受注時点の事業所コードを求める時間を削減できるから」
となっておりますので、

受注（受注担当社員番号）⇒所属（事業所コード）の部分は

受注（受注担当社員番号、受注年月日）から以下条件で
所属（事業所コード）を求める事になるのではないかと思います。

条件：
社員番号は受注テーブルの受注担当社員番号
異動年月日は受注テーブルの受注年月日以前で、最も直近の異動年月日

尚、解答例とは違いますが、個人的には
受注テーブルと出荷テーブルでデータが作成されるタイミングが異なるのと
事業所コードは受注時の情報なので、受注テーブルに"事業所コード"を持たせるのも有りかと思いました。
また、名称しか使わなさそうなので、"事業所名"にしてもいいのかなと思いました。

関数従属様

ありがとうございます。
正直なところ、この問題を間違えてしまいまして、解答を見ながらｳﾝｳﾝ唸っていました。
本番でここまで思考が辿り着くかは謎ですが、こういうパターンもあるということで勉強になりました。

ご回答ありがとうございました。