データベーススペシャリスト試験 2020年 午後1 問01

模範解答のキーワードと論点整理

• ア：発注
• イ：発注明細
• 関連リレーションシップ
  • 拠点（店舗）⇆発注
  • 発注⇆発注明細
  • 発注明細⇆自社商品

なぜ「発注」「発注明細」になるのか

「発注は発注番号で識別し, 発注明細は発注番号と発注明細番号で識別する。」

「発注は,配送を受ける時間帯に対する締め時刻まで、複数回に分けて行う」
「同一の自社商品を複数回登録できる。店舗が発注数量を減らす又は取り消す場合，当該自社商品の発注数量をマイナス値で設定して発注する。」

関係スキーマ対応イメージ

受験者が誤りやすいポイント

1. 「発注」と「配送」の混同
   発注は店舗が本部に対して行う注文情報，配送は本部から店舗への物流指示です。名前だけで判断せず，業務説明文の「受け付け」「指示」「完了日時」を手がかりに区別しましょう。
2. 明細エンティティの役割
   「生産明細」「配送明細」と似た構造だが，発注明細は店舗目線の注文情報を管理します。番号体系（発注番号＋発注明細番号）を確認して区別してください。
3. 多対多リレーションを避ける
   発注と自社商品は多対多に見えますが，そこは中間に「発注明細」を置く１対多 × 多対１のモデルです。

試験対策として覚えておくべきポイント

• 業務フロー中の「～明細」はほぼ明細エンティティで管理され，「主キー＋明細番号」の複合キーを持つ。
• 「注文」「生産」「配送」などのプロセス名がそのままエンティティ名になることが多い。
• E-R 図では，大きな業務ステップ（発注・生産・配送）を表す実体と，その詳細を管理する明細実体を必ずセットで考える。
• 多対多の関係は必ず中間エンティティ（明細や交差テーブル）を挟んで表現する。
• 問題文の識別要件（「■は■で識別」「■と■で識別」など）は，そのまま主キー設計のヒントになる。

模範解答のキーワードと論点整理

解答の論理的根拠

1. a：ルート番号, 配送順序
   「店舗は,一つの配送ルートに属し, そのルート番号をもつ。 また, 配送ルート上何番目に配送されるかを表す配送順序をもつ。」
   → 店舗（拠点コード）が所属する「ルート番号」と「配送順序」を属性として格納する。
2. b：生産ロットサイズ
   「自社商品ごとに生産ロットサイズを決めている。」
   → 自社商品（商品コード）に対する追加属性として「生産ロットサイズ」を格納。
3. c：生産工場拠点コード
   「配送ルートは, ルート番号で識別し, ルート名称と一つの配送元の拠点コードをもつ。」
   → 配送ルートに「配送元の拠点コード」として生産工場の拠点コードを外部キーで格納。
4. d：発注番号, 店舗拠点コード, 発注登録日時, 配送予定日時
   • 「発注は発注番号で識別し」→ 主キー「発注番号」
   • 「発注は, 店舗の拠点コード, 発注登録日時を確認し, 配送予定日時を記録する。」
     → 外部キー「店舗拠点コード」と，登録日時・予定日時を属性として格納。
5. e：発注番号, 発注明細番号, 商品コード, 発注数量, 生産番号, 配送番号
   • 「発注明細は発注番号と発注明細番号で識別する。」→ PK：(発注番号, 発注明細番号)
   • 「一つの発注の中で同一の自社商品を複数回登録することができる。」→ 属性「発注数量」
   • 「生産の対象とした発注明細に対して, 生産番号を記録する。」→ 外部キー「生産番号」
   • 「配送の対象とした発注明細に対して, 配送番号を記録する。」→ 外部キー「配送番号」
   • 商品コードは自社商品の外部キーとして格納。
6. f：生産工場拠点コード
   「生産は, 生産番号で識別し, 生産工場の拠点コード, 生産完了予定日時を記録する。」
   → 外部キー「生産工場拠点コード」を属性として格納。
7. g：商品コード
   「生産明細は, 生産番号と商品コードで識別し, 生産数量を記録する。」
   → PKの一部かつ自社商品参照用の外部キー「商品コード」を格納。
8. h：店舗拠点コード
   「配送は, 配送番号で識別し, 配送完了予定日時と配送先の拠点コードを記録する。」
   → 外部キー「配送先の拠点コード＝店舗拠点コード」を属性として格納。

受験者が誤りやすいポイント

• 主キー／外部キーの判断ミス
  発注明細(e)など、一つの表に複数の外部キー（商品コード・生産番号・配送番号）が入る点を取りこぼしやすい。
• 属性の記載漏れ
  「配送順序」(a)や「生産ロットサイズ」(b)は本文に１文で記載されるだけのため発見が遅れがち。
• エンティティ同士の対応関係の理解不足
  発注(ア)と発注明細(イ)、生産と生産明細、配送と配送明細の親子関係を把握しないまま属性配置すると，キーの構成も誤りやすい。

試験対策として覚えておくべきポイント

1. ER図→関係スキーマへの変換手順
   1. エンティティごとに主キーを明確化
   2. リレーションシップに応じた外部キーの付与
   3. 多対多は間接エンティティ(明細)化
   4. 正規形（第3正規形）を保つ
2. 設問の本文から「識別」「記録する」といったキーワードを拾う
   → 「識別」は主キー，「記録する」は属性として追加。
3. サブタイプ／スーパタイプ設計の際は，サブタイプごとの固有属性を忘れない
   → 本問では(c),(f)などを「生産工場拠点コード」として個別に定義。
4. 属性名は本文そのまま：数字・固有名詞は原文と完全一致で記述
   → 例：「生産ロットサイズ」「配送予定日時」など。

模範解答のキーワードと論点整理

• 汎化／特化
  − スーパタイプ「工場」「ルート」を、それぞれ適切なサブタイプに分割する設計
• サブタイプの抽出条件
  − スーパタイプに共通する属性をまとめ、サブタイプには固有の属性を持たせる
• 空欄対応

  空欄	解答（エンティティタイプ名）
  ウ	委託工場
  エ	自社工場
  オ	納入ルート
  カ	配送ルート

解答が導かれる論理的な説明

1. 「工場」→「委託工場」「自社工場」への特化
   （問題文より引用）

   「B社の工場を委託工場と呼び，…委託工場は5か所ある。…生産工場を自社工場と呼ぶことにする。自社工場と委託工場を併せて工場と呼ぶ。」

   したがって，図３中のウ・エにはそれぞれ
   • ウ：委託工場
   • エ：自社工場
     を置き，汎化／特化（逆三角形）で関係付けます。
2. 「ルート」→「納入ルート」「配送ルート」への特化
   （問題文より引用）

   「各自社工場と自社工場内の物流センタ，…の組を納入ルートと呼ぶ。…配送ルートと納入ルートを併せてルートと呼ぶ。」
   「配送ルートの配送元を自社工場から物流センタに変更し，…」

   よって図３中のオ・カには
   • オ：納入ルート
   • カ：配送ルート
     を置き，同様に汎化／特化で結びます。
3. 各サブタイプと他エンティティのリレーションシップ
   • 自社工場 —〈納入〉— 物流センタ
   • 委託工場 —〈納入〉— 物流センタ
     → それぞれ「納入ルート」サブタイプに参加
   • 物流センタ —〈配送〉— 店舗
     → 「配送ルート」サブタイプに参加
   • 自社仕様商品 —〈納入／配送〉— 各ルートサブタイプ
   • ルートサブタイプ（納入ルート／配送ルート）—〈所属〉— 店舗

受験者が誤りやすいポイント

1. 生産工場＝自社工場 と 委託工場 を混同
   − 「生産工場を自社工場と呼ぶ」ことを見落とすと，ウ・エの逆転や両方を「工場」のまま扱いがちです。
2. 納入ルート／配送ルート の役割取り違え
   − 「納入ルート」は工場→物流センタ，「配送ルート」は物流センタ→店舗，と配送元・配送先が異なる点を押さえましょう。
3. 汎化／特化の表記漏れ
   − 図３で「逆三角形」がある位置には必ずスーパタイプ／サブタイプ関係を書く必要があります。

試験対策として覚えておくべきポイント

• 汎化／特化の要件
  1. 同一のスーパタイプから分岐するサブタイプは「排他的」か「重複可能」かを把握
  2. サブタイプ固有の属性を明確に分離
  3. スーパタイプには共通属性のみを残す
• 業務フローの要件定義をデータモデルに反映
  − 「納入」「配送」など業務区分が変わる箇所は，サブタイプ化や中間エンティティで扱う
• 関係スキーマ設計の正規化
  − 汎化／特化後にリレーションスキーマを第3正規形まで整える

1. 模範解答のキーワード・論点整理

• スーパタイプ／サブタイプ
  • 「工場」→「委託工場（ウ）」「自社工場（エ）」「ルート」→「納入ルート（オ）」「配送ルート（カ）」
• 主キーと外部キーの継承
  • サブタイプはスーパタイプの主キーを受け継ぐ
• 属性の割り当て
  • 「委託工場は，委託開始年月日をもつ」（問題文）
  • 「納入ルートは，工場と物流センタの組を表す」
  • 「配送ルートは，物流センタを配送元とする」

2. 解答が導かれる論理的な説明

i：ウ（委託工場）の属性

「(3) B社の工場を委託工場と呼び, ... 委託工場は委託開始年月日をもつ。」
サブタイプ「委託工場」は，スーパタイプ「工場」の主キーである「拠点コード」を受け継ぎ，固有属性「委託開始年月日」をもつため，

ウ（拠点コード，委託開始年月日）

j：オ（納入ルート）の属性

「(1) ① … 各自社工場と自社工場内の物流センタ, 各委託工場と各物流センタの組を納入ルートと呼ぶ。納入ルートは,ルート番号で識別する。」
納入ルートが表すのは「工場」と「物流センタ」の組み合わせであり，主キー「ルート番号」に加えて，それぞれの外部キー「工場拠点コード」「物流センタ拠点コード」をもつため，

オ（ルート番号，工場拠点コード，物流センタ拠点コード）

k：カ（配送ルート）の属性

「(2) 配送ルートの配送元を自社工場から物流センタに変更し, 物流センタに対する配送の指示及び店舗への配送は, 現状業務と同様に行う。」
配送元が「物流センタ」へ変わった配送ルートは，主キー「ルート番号」と外部キー「物流センタ拠点コード」をもつため，

カ（ルート番号，物流センタ拠点コード）

3. 受験者が誤りやすいポイント

1. ウ（委託工場）から「拠点コード」を抜かしてしまう
   • サブタイプには必ずスーパタイプの主キーを持たせる
2. j（納入ルート）を「ルート番号＋工場拠点コード」のみとし，「物流センタ拠点コード」を入れ忘れる
   • 納入ルートは「工場」と「物流センタ」の組を表す
3. k（配送ルート）を旧来の「拠点コード（＝自社工場）」と勘違いする
   • 新業務では「物流センタ拠点コード」を配送元とする

4. 試験対策として押さえるべきポイント

• スーパタイプ／サブタイプ設計では，サブタイプに必ずスーパタイプの主キーを継承させる
• 属性は「役割の変化」を問題文から正確に読み取り，ルート設計では配送元／納入元を見落とさない
• リレーションスキーマを第3正規形に保つには，重複や多対多を避け，サブタイプ化で属性を分離する

まとめ：関係スキーマ（完成形イメージ）

1. 模範解答のキーワードと論点整理

2. なぜその解答になるのか（論理的説明）

1. 問題文 2.1① より

   各自社工場と自社工場内の物流センタ，各委託工場と各物流センタの組を納入ルートと呼ぶ。

2. 物流センタの数
   • 現状で自社工場は３か所（現状業務 1.(3)）。
   • 5か所の委託工場を追加しても，物流センタは「自社工場内の３つ」のみ。
     （委託工場には物流センタを新設しない点に注意）
3. 納入ルート生成の違い
   | 工場種別 | 物流センタとの対応 | １工場当たりの納入ルート数 | |----------|--------------------|------------------------------| | 自社工場 | 「自社工場内の物流センタ」とだけペアを作成 | 1（＝同居の物流センタのみ） | | 委託工場 | ３か所ある全物流センタとペアを作成 | 3（＝物流センタ数分） |
4. よって
   • 自社工場レコード → 納入ルートは 1 本
   • 委託工場レコード → 納入ルートは 3 本
     となり，カーディナリティ N が 1 または 3 に分岐する。

3. 受験者が誤りやすいポイント

4. 試験対策として覚えておくべきポイント

1. サブタイプ（自社工場／委託工場）の業務ルールがリレーションシップの多重度を変える代表例。
2. 「○○と○○の組（ペア）」と書かれていたらアソシエーティブ・エンティティ（ここでは納入ルート）を設け，多対多を回避する。
3. カーディナリティの数値は「個体数 × 業務ルール」で決まる。必ず“何個あるのか”を文章から抽出する。
4. 問題文の“内” “ごとに” “全部”などの副詞は多重度判断のヒントになる。
5. 第３正規形設計時，1:N が可変（1 または 3 など）の場合でも ER 図上は 1:N と書き，多側の上限をコメントで補足するのが一般的。