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

解答の論理構成

1. 発注‐受領業務に対応する実体を洗い出す
   ・問題文では「① 店舗は、必要な自社商品とその発注数量を設定して発注する。」とあり、さらに「③ 発注は、発注番号で識別し、 発注明細は発注番号と発注明細番号で識別する。」と記載されています。
   ・ここから、発注自体を表すエンティティと、その中身（商品単位）を表すエンティティの２段構えが必須であることが読み取れます。
2. スキーマの空欄との突合せ
   ・図２のリレーション(ア)と(イ)には、それぞれ主キーとなる属性が欠けており、(ア)は(ｄ)、(イ)は(ｅ)のみが示されています。
   ・問題文の「発注番号」「発注明細番号」という識別子が唯一対応するため、(ア)＝「発注」、(イ)＝「発注明細」と判断できます。
3. リレーションシップの整理
   ・「店舗は、一つの配送ルートに属し…」より、店舗→配送ルートは１対１または多対１。
   ・「店舗は…発注する」より、店舗→発注は１対多。
   ・「発注は…発注明細をもつ」より、発注→発注明細は１対多。
   ・「一つの発注の中で同一の自社商品を複数回登録することができる。」とあるため、発注明細→自社商品は多対１。
   ・「生産の対象とした発注明細に対して、生産番号を記録する。」および「配送の対象とした発注明細に対して、配送番号を記録する。」より、発注明細→生産明細、発注明細→配送明細は多対１。
   ・これらを図１に追記することで概念データモデルが完成します。
4. 正規形チェック
   ・「発注」は主キー「発注番号」のもとに「店舗の拠点コード」「発注登録日時」「配送予定日時」などが従属しており、第３正規形を満たします。
   ・「発注明細」は複合キー「発注番号＋発注明細番号」で一意に決まり、非キー属性は存在しないか、ある場合も主キー全体に完全従属するため同じく第３正規形を満たします。

誤りやすいポイント

• 発注明細から自社商品への関係を「１対１」と誤認するケース
  →問題文に「同一の自社商品を複数回登録することができる。」とあるので「多対１」が正しいです。
• 生産明細と配送明細を直接結合（多対多）してしまうケース
  →設問指示「“多対多” のリレーションシップを用いないこと」に抵触します。発注明細がハブになります。
• 発注と配送を直接結んでしまうケース
  →配送は必ず配送番号で管理され、「発注明細に配送番号を記録する」と記載。発注と配送は発注明細を介して結ばれます。

FAQ

解答の論理構成

1. (a)
   【問題文】「店舗は、一つの配送ルートに属し、そのルート番号をもつ。 また、配送ルート上何番目に配送されるかを表す配送順序をもつ。」
   ⇒ 店舗リレーションに「ルート番号（破線下線）」と非キー「配送順序」を追加。
2. (b)
   【問題文】「自社商品ごとに生産ロットサイズを決めている。」
   ⇒ 自社商品リレーションの属性はキーではないため下線なしで「生産ロットサイズ」。
3. (c)
   【問題文】「配送ルートは、ルート番号で識別し、ルート名称と一つの配送元の拠点コードをもつ。」
   さらに配送元は生産工場で固定のため外部キー「生産工場拠点コード（破線下線）」。
4. (d)
   発注は【問題文】「発注は、発注番号で識別」「A社本部は、店舗の拠点コード、発注登録日時を確認し、配送予定日時を記録」。
   ⇒ 主キー「発注番号（実線下線）」＋業務記録3項目。店舗拠点コードは外部キー（破線下線）。
5. (e)
   【問題文】「発注明細は発注番号と発注明細番号で識別」「店舗が発注数量を減らす…発注数量」「生産番号を記録」「配送番号を記録」。
   ⇒ 主キー2項目（実線下線）＋商品コード（破線下線）＋発注数量＋生産番号・配送番号（双方破線下線）。
6. (f)
   【問題文】「生産は、生産工場の拠点コード」
   ⇒ 生産リレーションに外部キー「生産工場拠点コード（破線下線）」。
7. (g)
   生産明細・配送明細は【問題文】「生産明細は、生産番号と商品コードで識別」「配送明細は、配送番号と商品コードで識別」。
   ⇒ 商品コードは両リレーションのキー要素（実線下線）。
8. (h)
   【問題文】「配送…配送先の拠点コードを記録」
   ⇒ 配送リレーションに外部キー「店舗拠点コード（破線下線）」。

誤りやすいポイント

• ルート番号の多重利用 配送ルートと納入ルートを混同し「配送」にもルート番号を入れてしまうミス。
• 発注明細の主キー 「発注明細番号だけ」を主キーにする誤設計。問題は「発注番号と発注明細番号で識別」と明示。
• 生産ロットサイズの位置づけ 自社商品に紐付く定義データであって可変データと誤解し別テーブルに切り出すケース。

FAQ

解答の論理構成

1. 工場のサブタイプ
   • 【問題文】には「委託工場は5か所ある。…生産工場を自社工場と呼ぶことにする。自社工場と委託工場を併せて工場と呼ぶ。」とあり、
     工場を２つのサブタイプに分割する必要があることが明示されています。
   • よって、工場の下位に置く（ウ）（エ）は
     ・（ウ）＝「委託工場」
     ・（エ）＝「自社工場」
     となります。
2. ルートのサブタイプ
   • 【問題文】「各自社工場と自社工場内の物流センタ、各委託工場と各物流センタの組を納入ルートと呼ぶ。」
   • 【問題文】「配送ルートの配送元を自社工場から物流センタに変更し…」
   • 【問題文】「配送ルートと納入ルートを併せてルートと呼ぶ。」
     以上より、ルートは “ルート” というスーパタイプの下に
     ・納入ルート（物流センタへ商品を運ぶ経路）
     ・配送ルート（物流センタから店舗へ商品を運ぶ経路）
     の２サブタイプを持つ構造になります。
   • 図３の（オ）（カ）はそれぞれこの２サブタイプを指すため
     ・（オ）＝「納入ルート」
     ・（カ）＝「配送ルート」
     と決定します。
3. 必要なリレーションシップ
   上記サブタイプ決定後、図３を完成させるために次のリレーションシップを記入します。
   • 拠点1 ─ 1工場（サブタイプ包含）
   • 拠点1 ─ 1物流センタ（サブタイプ包含）
   • 工場1 ─ N納入ルート（工場が納入元）
   • 物流センタ1 ─ N納入ルート（物流センタが納入先）
   • 物流センタ1 ─ N配送ルート（配送元）
   • 配送ルート1 ─ N店舗（店舗は１つの配送ルートに属し、配送順序属性を保持）
   • ルート1 ─ 1納入ルート（サブタイプ包含）
   • ルート1 ─ 1配送ルート（サブタイプ包含）
     これにより、サブタイプ構造と業務フロー（工場→物流センタ→店舗）が一貫して表現され、図３の概念データモデルは完成します。

誤りやすいポイント

• 「配送ルートの配送元を自社工場から物流センタに変更」という一文を見落とし、（カ）を旧来どおり “生産工場–店舗” のルートだと誤解する。
• 工場のサブタイプ化を行わずに “生産工場” をそのまま残し、新設 “委託工場” と３階層にしてしまう。スーパタイプ＝工場を必ず設けることに注意。
• 「配送ルートと納入ルートを併せてルートと呼ぶ」を読まずにスーパタイプ “ルート” を作らず、結果として第３正規形を破る冗長設計になる。
• 配送ルート─店舗の多重度。設問冒頭【現状業務】「３〜８の店舗を配送先としている」「店舗は、一つの配送ルートに属し」とあるため、
  配送ルート１に対し店舗３〜８、反対向きは１であることを忘れない。

FAQ

解答の導き方

1. (i) の決定

• 図4に "工場（拠点コード、生産能力）" とあり、工場はサブタイプに分かれていることが示されています。問題文には "B社の工場を委託工場と呼び、 委託工場は委託開始年月日をもつ。" とあります。
• サブタイプの属性設計の原則から、サブタイプ固有の属性（今回であれば委託開始年月日）はサブタイプ側に置き、サブタイプの識別子はスーパタイプの主キーを継承します。図4の "工場（拠点コード,…）" より、工場の識別子は拠点コードです。したがって委託工場サブタイプの識別子も拠点コードであり、委託開始年月日はサブタイプ固有の非キー属性です。
• 以上より (i) は 拠点コード（主キー） と 委託開始年月日（非キー属性）になります。

1. (j) の決定

• 問題文に "各自社工場と自社工場内の物流センタ、各委託工場と各物流センタの組を納入ルートと呼ぶ。納入ルートは、ルート番号で識別する。" とあります。つまり納入ルートは「ある工場」と「ある物流センタ」の組を表すエンティティです。図4の (オ) は "（ルート番号、(j)）" と示されており、ここに納入ルートが必要とする工場側と物流センタ側の参照を持たせることが期待されます。
• したがって (j) には、納入ルートが参照する工場を示す外部キーと、参照する物流センタを示す外部キーを置きます。工場は自社工場・委託工場どちらもあり得るため、参照先はスーパタイプの工場の主キー（拠点コード）を指すのが正しい設計です。役割が分かるように名前は "工場拠点コード" と "物流センタ拠点コード" とします。両属性とも外部キーです。
• 以上より (j) は 工場拠点コード（外部キー）、 物流センタ拠点コード（外部キー）になります。

1. (k) の決定

• 問題文に "配送ルートの配送元を自社工場から物流センタに変更し" とあり、配送ルートの配送元が物流センタになったことが明示されています。図4の (カ) が "（ルート番号、(k)）" と示されているので、配送ルート側で配送元である物流センタを参照する属性を持たせる必要があります。
• したがって (k) は 物流センタ拠点コード（外部キー）になります。

• 拠点コードは工場スーパタイプの主キーであるためサブタイプはこれを継承します。委託開始年月日を主キーに含める必要はなく、含めると同一拠点の複数行や冗長が発生するので避けます。
• 納入ルートは問題文で "ルート番号で識別する" とあるため、工場側・物流センタ側の組み合わせで新たに主キーを作る（複合主キーにする）必要はありません。工場側・物流センタ側は外部キーとして参照で表現します。
• 工場を参照する外部キーは、参照先が自社工場・委託工場のいずれにも対応できるよう工場スーパタイプ（拠点コード）を参照する形とするのが実務的かつ正規化に合致します。

誤りやすいポイント

• 委託開始年月日をサブタイプではなくスーパタイプの工場に置いてしまう。→ 委託開始年月日は委託工場固有の属性なのでサブタイプに置くのが正しい。
• 委託開始年月日を主キーに含める（拠点コード＋委託開始年月日 をPKにする）。→ 拠点コードだけで工場を一意に識別できるため不要かつ第3正規形を乱す可能性がある。
• 納入ルートの主キーを工場拠点コード＋物流センタ拠点コードの複合キーにしてしまう。→ 問題文は "納入ルートは、ルート番号で識別する" と明記しており、ルート番号を識別子とする設計が妥当。
• 工場を参照する外部キーを自社工場テーブルや委託工場テーブルだけに向ける。→ 参照対象は状況により自社／委託どちらにもなり得るため、工場スーパタイプ（拠点コード）を参照するのが正しい。
• 「納入」と「納入ルート」を混同する。→ 納入は運用（納入番号を持つ行為）であり、納入は納入ルート（ルート番号）を参照して実行される。両者は別テーブル/別エンティティで表現する必要がある。

FAQ

解答の論理構成

1. リレーションシップの対象を特定
   • 工場側：自社工場／委託工場
   • 多側（オ）：納入ルート
2. 【問題文】引用により組数を確認
   • 「自社工場内の物流センタ」…一つの工場に対して物流センタは同一敷地内で1つ。
   • 「各委託工場と各物流センタ」…物流センタは自社工場と同数で「3か所」。
3. 組み合わせ数＝納入ルート数
   • 自社工場は1×1＝1 → カーディナリティ「1」。
   • 委託工場は1×3＝3 → カーディナリティ「3」。
4. よって多側のカーディナリティは「1」「3」と決定する。

誤りやすいポイント

• 物流センタの数を「5か所の委託工場」と取り違えて「5」と誤答。
• 「1対多」の“多”を無条件に「複数」とだけ書き具体値を示さない。
• 自社工場にも物流センタが3か所あると読み違える。

FAQ