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

落ちまして今更反省会してるところですが、
令和7年 午後II 設問2 (1) ④ 出庫明細の属性が納得いきません。。

出庫の属性から考えて、
主キー：DCコード、配送年月日、資材コード、区画番号

と考えるのが自然だと思うのですが、区画番号が外部キーかつ冗長な属性である理由が全く分かりません。。

1.なんで自分の回答じゃダメなのか
2.区画番号が冗長な属性だとして、どのように出庫明細の属性から導出されるのか

こちら分かる方いらっしゃいますでしょうか。。？

 DC資材在庫から継承。
,

この投稿は投稿者により削除されました。(2026.01.04 22:36)

> 1.なんで自分の回答じゃダメなのか
> 主キー：DCコード、配送年月日、資材コード、区画番号
 正規化違反。アノマリーが生じる恐れがあるから。
 矛盾するデータの登録が理論上可能になるのでダメなんじゃないかしら。

> 出庫の属性から考えて

という指摘から、

「出庫明細」の主キーは、「出庫」の主キーを含み、さらに追加の識別子を含むべきである、
と考えておられるのではないでしょうか。

しかし、これは必ずしも鉄則ではありません。

問題文には、次の記述があります。

> (4) 出庫は区画ごとに実施し、出庫明細で区画内の資材を出庫要求に基づいて出庫する。出庫では配送年月日と出庫完了時分を記録し、出庫明細で出庫要求との対応と出庫実績数を記録する。

ここで「出庫要求に基づいて出庫する」という表現から、出庫明細は出庫要求の内容（事実上、資材コード単位）に対応して行が作成されると解釈できます。

仮に、資材コード別・区画別に出庫明細を分割する設計を採った場合、
一つの出庫要求（資材コード単位）に対して、出庫実績が複数行に分かれる可能性が生じます。

この場合、
**出庫要求数と出庫実績数が1対1で対応せず、集計処理が必要になる**というデメリットがあります。

「出庫明細」という名称であっても、
その親となるエンティティが必ずしも「出庫」単独とは限らず、
今回は**出庫要求との対応関係を主眼に置いた明細**と考える方が自然です。

また、テーブル群全体を俯瞰すると、出庫は在庫減少を伴い、
やがて発注点管理、発注・入荷・入庫といった処理に連なっていきます。

そのため、
区画ごとに特定の資材コードしか格納しないという前提がない限り、
入庫時の区画は随時変動すると考えるのが妥当です。

結果として、
**資材コード別の実在庫数量を一元的に把握する必要があり、
出庫明細を区画単位に細分化しすぎる設計は、
システム全体の要請と整合しません。**

過去問を見ても、
明細が必ずしも親エンティティの主キーを完全に継承しない設計例は、
繰り返し出題されています。

ありがとうございます！！
DC資料在庫は"保管"区画番号となっていたので盲点でした。。どこまで正規化できるか最後まで気をつけます。。