データベーススペシャリスト 2020年 午後1 問01
データベース設計に関する次の記述を読んで、設問1, 2 に答えよ。
A社は、関東圏に展開している食料品スーパマーケットチェーンである。 A社が取り扱う商品には、青果、鮮魚、精肉などがあるが、その中の自社商品の弁当・総菜類について、商品配送管理システムを用いて配送業務を実施してきた。 A社は、デザートケーキ類の追加を計画しており、データベース設計を見直すことにした。
〔現状業務の概要〕
1.拠点
(1) 拠点は、拠点コードで識別し、拠点名、所在地 代表電話番号をもつ。
(2) 拠点には生産工場と店舗があり、拠点区分で分類する。
(3) 生産工場は、A社の自社商品だけを生産する。 A社には3か所の生産工場がある。 生産工場には、自社商品を生産する役割と、自社商品を仕分けして各店舗へ配送する役割がある。 生産工場は、生産能力と操業開始年月日をもつ。
(4) 店舗は、約70 あり、店舗基本情報をもつ。
① 生産工場から店舗への配送では、配送ルートを設定している。 一つの配送ルートは、1台のトラックで2〜3時間で配送できる3〜8の店舗を配送先としている。 店舗への配送順序をあらかじめ決めている。
② 配送ルートは、ルート番号で識別し、ルート名称と一つの配送元の拠点コードをもつ。
③ 店舗は、一つの配送ルートに属し、そのルート番号をもつ。 また、配送ルート上何番目に配送されるかを表す配送順序をもつ。
2.自社商品
(1) 自社商品は,A社の商品仕様に基づく弁当、総菜、おにぎりなどである。
(2) 自社商品は、商品コードで識別し、商品名、商品価格、商品仕様をもつ。
(3) 各生産工場は、全ての自社商品を生産する。
(4) 自社商品ごとに生産ロットサイズを決めている。
3.発注から配送まで
(1) A社本部は、店舗からの発注を、昼食前と夕食前の時間帯に合わせて受け付ける。
① 店舗は、必要な自社商品とその発注数量を設定して発注する。
② 発注は、配送を受ける時間帯に対する締め時刻 (以下、締め時刻という) まで、複数回に分けて行うこともある。 一つの発注の中で同一の自社商品を複数回登録することができる。 店舗が発注数量を減らす又は取り消す場合、当該自社商品の発注数量をマイナスの値で設定して発注する。
③ 発注は発注番号で識別し、発注明細は発注番号と発注明細番号で識別する。
④ A社本部は、店舗からの発注について、店舗の拠点コード、発注登録日時を確認し、配送予定日時を記録する。
(2) A社本部は、店舗からの発注に基づき生産の指示を行う。 生産工場は、生産の指示に基づき生産する。
① A社本部は、締め時刻の対象となる発注について、生産工場ごとに配送先の店舗の自社商品ごとの発注数量を集計し、生産の指示とする。
② 生産は、生産番号で識別し、生産工場の拠点コード、生産完了予定日時を記録する。
③ 生産明細は、生産番号と商品コードで識別し、生産数量を記録する。 生産数量は、集計した発注数量を満たすように、自社商品の生産ロットサイズの倍数で設定する。
④ 生産の対象とした発注明細に対して、生産番号を記録する。
⑤ 生産工場は、生産完了後に生産完了日時を記録する。
(3) 生産工場は、自社商品を店舗ごとに仕分けて配送する。
① A社本部は、締め時刻の対象となる発注に対して店舗ごとに自社商品別に発注を集計し、配送の指示を行う。
② 配送は、配送番号で識別し、配送完了予定日時と配送先の拠点コードを記録する。
③ 配送明細は、配送番号と商品コードで識別し、配送数量を記録する。配送数量は、実際の配送数量である。
④ 配送の対象とした発注明細に対して、配送番号を記録する。
⑤ 店舗は、配送された自社商品を受領し、配送に対して、店舗受領日時、店舗受領担当者を記録する。
〔概念データモデルの関係スキーマの設計〕
〔現状業務の概要〕についての概念データモデルを図1に、関係スキーマを図2に示す。


〔新たな商品の追加〕
1.新たな商品及び委託先
(1) A社は、新たな商品として、デザート・ケーキ類を追加することにした。
(2) デザート・ケーキ類は、B社に生産を委託する。 委託して生産する商品を委託商品と呼ぶ。 委託商品は、A社の商品仕様に基づいて生産する。 自社商品と委託商品を併せて自社仕様商品と呼ぶ。
(3) B社の工場を委託工場と呼び、委託工場は委託開始年月日をもつ。 委託工場は5か所ある。 個々の委託商品を生産する委託工場は、一つに決まっている。また、委託工場の追加に伴って、生産工場を自社工場と呼ぶことにする。 自社工場と委託工場を併せて工場と呼ぶ。
(4) A社は、既存の配送ルートを使って自社商品と委託商品を併せて店舗へ配送する。
(5) これまで自社工場内で仕分けと配送を行っていた役割に、工場の拠点コードとは別に物流センタとしての拠点コードを付与する。
(6) 自社工場から物流センタへ、委託工場から物流センタへ、自社仕様商品を運ぶことを納入と呼ぶ。
2.物流センタ追加に伴う納入ルートの追加と配送ルートの変更
(1) 納入の指示及び納入は、次のように行う。
① 各自社工場と自社工場内の物流センタ、各委託工場と各物流センタの組を納入ルートと呼ぶ。 納入ルートは、ルート番号で識別する。
② A社本部は、締め時刻の対象となる発注について、次のように納入の指示を行う。
・自社商品については、物流センタごとに配送先の店舗の発注数量を自社商品別に集計して、納入の指示とする。
・委託商品については、物流センタごとに配送先の店舗の発注数量を委託商品別に集計し、委託商品を生産する委託工場ごとに分けて、納入の指示とする。
③ 納入は、納入番号で識別し、納入するルート番号と納入予定日時を記録する。納入が完了後、納入完了日時を記録する。
④ 納入明細は、納入番号と商品コードで識別し、納入数量を記録する。
⑤ 納入の対象となる発注明細に対して、納入番号を記録する。
(2) 配送ルートの配送元を自社工場から物流センタに変更し、物流センタに対する配送の指示及び店舗への配送は、現状業務と同様に行う。
(3) 配送ルートと納入ルートを併せてルートと呼ぶ。
(4) 生産の指示及び生産は、次のように行う。
① 自社工場に対する生産の指示及び生産は、現状業務と同様に行う。
② 委託工場に対する生産の指示は、全店舗の委託商品ごとの発注数量を集計して行う。
③ 委託工場は、生産の指示に基づいて、生産を行い、自社工場と同様の記録を行う。
新たな商品の追加に対応するために、工場、ルート及び自社仕様商品をサブタイプに分割した。 新たな商品を追加した概念データモデルを図3に、工場、物流センタ、ルート及び納入の関係スキーマを図4に示す。


解答に当たっては、巻頭の表記ルールに従うこと。 ただし、エンティティタイプ間の対応関係にゼロを含むか否かの表記は必要ない。
なお、エンティティタイプ間のリレーションシップとして “多対多” のリレーションシップを用いないこと。 エンティティタイプ名及び属性名は、それぞれ意味を識別できる適切な名称とすること。 また、識別可能なサブタイプが存在する場合、他のエンティティタイプとのリレーションシップは、スーパタイプ又はサブタイプのいずれか適切な方との間に記述せよ。 また、関係スキーマは第3正規形の条件を満たしていること。
設問1:図1,2について、(1)、(2)に答えよ。
(1)図1の概念データモデルは未完成である。 図1中の(ア)、(イ)に入れる適切なエンティティタイプ名を答えよ。また、必要なリレーションシップを全て記入し、概念データモデルを完成させよ。
模範解答
ア:発注
イ:発注明細


解説
解答の論理構成
- 発注業務の独立性
- 【問題文】「店舗は、必要な自社商品とその発注数量を設定して発注する。」
- 発注そのもの(誰が・いつ行ったか)は “店舗” と 1対多。発注行為の履歴管理・締め時刻判定に必要なため、「発注」エンティティを作成。
- 明細行の必要性
- 【問題文】「一つの発注の中で同一の自社商品を複数回登録することができる。」
- 単一の“発注”だけでは「同一商品複数行」を表現できない。明細行を個別エンティティ「発注明細」とし、主キーを〈発注番号、発注明細番号〉で重複を排除。
- 多対多の解消
- “店舗”と“自社商品”は本来多対多。これを「発注明細」で分解し、
・店舗 1 — * 発注 1 — * 発注明細 * — 1 自社商品
の連鎖で第3正規形を満たす。
- “店舗”と“自社商品”は本来多対多。これを「発注明細」で分解し、
・店舗 1 — * 発注 1 — * 発注明細 * — 1 自社商品
- 生産・配送との接続
- 【問題文】「生産の対象とした発注明細に対して、生産番号を記録する。」
- 【問題文】「配送の対象とした発注明細に対して、配送番号を記録する。」
- よって “生産明細”―“発注明細”、“配送明細”―“発注明細” に 0または1対1 リレーションを設定し、作業トレーサビリティを保持。
- 完成形
- (ア)発注:主キー〈発注番号〉、外部キー=店舗の拠点コード
- (イ)発注明細:主キー〈発注番号、発注明細番号〉、外部キー=商品コード、生産番号(任意)、配送番号(任意)
- 必要リレーションシップ:
・店舗 1 — * 発注
・発注 1 — * 発注明細
・自社商品 1 — * 発注明細
・発注明細 0または1 — 1 生産明細
・発注明細 0または1 — 1 配送明細
誤りやすいポイント
- 「発注と自社商品を直接多対多で結んでしまう」
→ 正規化違反。明細行で分割する。 - 「発注明細」と「生産明細/配送明細」の対応を N対N と誤認
→ 【問題文】は「対象とした発注明細“に対して、生産番号を記録する」ので 1明細が1生産明細にひも付く(数量は生産ロットで調整)。 - 発注番号と発注明細番号のどちらを主キーに含めるか迷う
→ 同じ発注明細番号が異なる発注で重複し得るため、両方を含める。
FAQ
Q: 発注明細にマイナス数量が入る場合、ER 図を拡張する必要はありますか?
A: いいえ。数量は属性値の範囲で扱えるため、ER 図上は通常の数値属性で問題ありません。
A: いいえ。数量は属性値の範囲で扱えるため、ER 図上は通常の数値属性で問題ありません。
Q: 生産明細・配送明細と発注明細の関係は 1対多 ではありませんか?
A: 【問題文】どちらの明細にも「対象とした発注明細に対して、○○番号を記録する」とあるため、1 発注明細が 0 または 1 件の生産明細/配送明細に対応します(多側は発注明細ではなく生産側)。
A: 【問題文】どちらの明細にも「対象とした発注明細に対して、○○番号を記録する」とあるため、1 発注明細が 0 または 1 件の生産明細/配送明細に対応します(多側は発注明細ではなく生産側)。
Q: 発注と締め時刻の管理はどこで表現しますか?
A: 締め時刻は “発注” エンティティに属性(例:対象締め時刻区分)として保持し、発注登録日時と併せて業務ロジックで管理します。
A: 締め時刻は “発注” エンティティに属性(例:対象締め時刻区分)として保持し、発注登録日時と併せて業務ロジックで管理します。
関連キーワード: 正規化、エンティティ識別、リレーションシップ、トレーサビリティ、主キー
設問1:図1,2について、(1)、(2)に答えよ。
(2)図2中の(a)〜(h)に一つ又は複数の適切な属性名を入れ、図を完成させよ。 また、主キーを構成する属性の場合は実線の下線を、外部キーを構成する属性の場合は、破線の下線を付けること。
模範解答
a:ルート番号、配送順序
b:生産ロットサイズ
c:生産工場拠点コード
d:発注番号、店舗拠点コード、発注登録日時、配送予定日時
e:発注番号、発注明細番号、商品コード、発注数量、生産番号、配送番号
f:生産工場拠点コード
g:商品コード
h:店舗拠点コード
解説
解答の論理構成
-
(a)
【問題文】「店舗は、一つの配送ルートに属し、そのルート番号をもつ。 また、配送ルート上何番目に配送されるかを表す配送順序をもつ。」
⇒ 店舗リレーションに「ルート番号(破線下線)」と非キー「配送順序」を追加。 -
(b)
【問題文】「自社商品ごとに生産ロットサイズを決めている。」
⇒ 自社商品リレーションの属性はキーではないため下線なしで「生産ロットサイズ」。 -
(c)
【問題文】「配送ルートは、ルート番号で識別し、ルート名称と一つの配送元の拠点コードをもつ。」
さらに配送元は生産工場で固定のため外部キー「生産工場拠点コード(破線下線)」。 -
(d)
発注は【問題文】「発注は、発注番号で識別」「A社本部は、店舗の拠点コード、発注登録日時を確認し、配送予定日時を記録」。
⇒ 主キー「発注番号(実線下線)」+業務記録3項目。店舗拠点コードは外部キー(破線下線)。 -
(e)
【問題文】「発注明細は発注番号と発注明細番号で識別」「店舗が発注数量を減らす…発注数量」「生産番号を記録」「配送番号を記録」。
⇒ 主キー2項目(実線下線)+商品コード(破線下線)+発注数量+生産番号・配送番号(双方破線下線)。 -
(f)
【問題文】「生産は、生産工場の拠点コード」
⇒ 生産リレーションに外部キー「生産工場拠点コード(破線下線)」。 -
(g)
生産明細・配送明細は【問題文】「生産明細は、生産番号と商品コードで識別」「配送明細は、配送番号と商品コードで識別」。
⇒ 商品コードは両リレーションのキー要素(実線下線)。 -
(h)
【問題文】「配送…配送先の拠点コードを記録」
⇒ 配送リレーションに外部キー「店舗拠点コード(破線下線)」。
これらにより第3正規形(主キーに完全関数従属・推移従属なし)を維持したまま図2が完成します。
誤りやすいポイント
- ルート番号の多重利用 配送ルートと納入ルートを混同し「配送」にもルート番号を入れてしまうミス。
- 発注明細の主キー 「発注明細番号だけ」を主キーにする誤設計。問題は「発注番号と発注明細番号で識別」と明示。
- 生産ロットサイズの位置づけ 自社商品に紐付く定義データであって可変データと誤解し別テーブルに切り出すケース。
FAQ
Q: 発注数量をマイナスで入力するときも同じ明細行を更新しないのですか?
A: 【問題文】「一つの発注の中で同一の自社商品を複数回登録することができる」とあるため、同商品でも別行(発注明細番号で区別)を追加する仕様です。
A: 【問題文】「一つの発注の中で同一の自社商品を複数回登録することができる」とあるため、同商品でも別行(発注明細番号で区別)を追加する仕様です。
Q: 生産番号・配送番号を発注明細に持たせると非正規化になりませんか?
A: 双方とも「発注明細 1 対 0..1 生産/配送」の外部キーであり、多値属性ではないため第3正規形を破りません。
A: 双方とも「発注明細 1 対 0..1 生産/配送」の外部キーであり、多値属性ではないため第3正規形を破りません。
Q: 「配送順序」はキーに含めないのですか?
A: 配送順序は配送ルート内でのみ一意ですが、店舗表の主キーは拠点コード単独で成立するので非キー属性として保持します。
A: 配送順序は配送ルート内でのみ一意ですが、店舗表の主キーは拠点コード単独で成立するので非キー属性として保持します。
関連キーワード: 第3正規形、外部キー、主キー設計、エンティティリレーション、集計発注
設問2:〔新たな商品の追加〕について、(1)〜(3)に答えよ。
(1)図3中の(ウ)〜(カ)に入れる適切なエンティティタイプ名を答えよ。また、必要なリレーションシップを全て記入し、概念データモデルを完成させよ。
模範解答
ウ:委託工場
エ:自社工場
オ:納入ルート
カ:配送ルート


解説
解答の論理構成
-
サブタイプ名の決定
- 工場の下位分類
【問題文】「委託工場は5か所ある」「生産工場を自社工場と呼ぶことにする」より、工場のサブタイプは「委託工場」と「自社工場」。 - ルートの下位分類
【問題文】「配送ルートと納入ルートを併せてルートと呼ぶ」より、ルートのサブタイプは「配送ルート」と「納入ルート」。
- 工場の下位分類
-
リレーションシップ①・②:工場と物流センタをつなぐ納入ルート
- 【問題文】「各自社工場と自社工場内の物流センタ、各委託工場と各物流センタの組を納入ルートと呼ぶ」
- よって 1 つの工場は複数の納入ルートを持ち、1 つの物流センタも複数の納入ルートを持つ。
-
リレーションシップ③:物流センタと配送ルート
- 【問題文】「配送ルートの配送元を自社工場から物流センタに変更し」
- 1 つの物流センタから複数の配送ルートが出る構造になる。
-
リレーションシップ④:配送ルートと店舗
- 現状業務より【問題文】「店舗は、一つの配送ルートに属し」が維持されるため 1:M。
-
リレーションシップ⑤:各明細と自社仕様商品
- 納入・生産・配送の各明細はそれぞれ商品単位で数量を保持する設計で、「自社商品」と「委託商品」をまとめた上位概念「自社仕様商品」と 1:M 関係を張る。
-
正規化の確認
- ルート(ルート番号、ルート名称)をキーに持つ下位表「配送ルート」「納入ルート」は、親キーを継承しており第3正規形を満たす。
- 工場とその下位表も同様。
誤りやすいポイント
- 「納入ルート」と「配送ルート」を別々の親にぶら下げてしまい“ルート”のスーパタイプを忘れる。
- 物流センタを“拠点”のサブタイプではなく独立エンティティにしてしまい、拠点コードが二重管理になる。
- 「委託工場は一つに決まっている」を店⇔委託工場の関係と誤読して 1:1 で結んでしまう。実際は委託商品ごとに生産工場が決まる。
FAQ
Q: 「工場」―「納入ルート」を 1:1 にする案は誤りですか?
A: 誤りです。各工場は【問題文】「各委託工場と各物流センタの組を納入ルートと呼ぶ」ように、物流センタの数だけ複数の納入ルートを持てます。
A: 誤りです。各工場は【問題文】「各委託工場と各物流センタの組を納入ルートと呼ぶ」ように、物流センタの数だけ複数の納入ルートを持てます。
Q: 「配送ルート」は店舗側から管理してはいけないのですか?
A: 店舗は「店舗は、一つの配送ルートに属し」と単一ルートに紐づくため、主キーは「店舗」に置き、「配送ルート」は参照(外部キー)で持たせるのが正規化の観点で適切です。
A: 店舗は「店舗は、一つの配送ルートに属し」と単一ルートに紐づくため、主キーは「店舗」に置き、「配送ルート」は参照(外部キー)で持たせるのが正規化の観点で適切です。
Q: 「自社商品」と「委託商品」を別テーブルに分けると何が問題になりますか?
A: 共通項目【問題文】「商品コード、商品名、商品価格、商品仕様」を持つため重複管理になり、納入・生産・配送明細の外部キーが2本必要になります。上位概念「自社仕様商品」にまとめることで冗長性を排除できます。
A: 共通項目【問題文】「商品コード、商品名、商品価格、商品仕様」を持つため重複管理になり、納入・生産・配送明細の外部キーが2本必要になります。上位概念「自社仕様商品」にまとめることで冗長性を排除できます。
関連キーワード: サブタイプ化、第3正規形、リレーションシップ、スーパタイプ、外部キー
設問2:〔新たな商品の追加〕について、(1)〜(3)に答えよ。
(2)図4中の(i)〜(k)に一つ又は複数の適切な属性名を入れ、図を完成させよ。また、主キーを構成する属性の場合は実線の下線を、外部キーを構成する属性の場合は、破線の下線を付けること。
模範解答
i:拠点コード、委託開始年月日
j:工場拠点コード、物流センタ拠点コード
k:物流センタ拠点コード
解説
解答の論理構成
- 工場サブタイプの主キー
- 【問題文】「委託工場は委託開始年月日をもつ。」
- スーパタイプ「工場」の主キー拠点コードをそのまま継承し、第3正規形維持のため「委託開始年月日」を追加 → (i) 完成。
- 納入ルートの外部キー
- 【問題文】「各自社工場と自社工場内の物流センタ、各委託工場と各物流センタの組を納入ルートと呼ぶ。」
- ルート表の主キールート番号に対し、組を構成する双方の識別子が必要 → (j) は「工場拠点コード」「物流センタ拠点コード」を破線下線で表す。
- 配送ルートの外部キー
- 【問題文】「配送ルートの配送元を自社工場から物流センタに変更し…」
- 「ルート」-「物流センタ」は 1:N 関係なので、「ルート」側に外部キーを置くより「物流センタ」を「配送ルート」側が参照する形が妥当。図4ではサブタイプ別バーティカル配置のため (k) に「物流センタ拠点コード」を設定し破線下線を付す。
誤りやすいポイント
- 工場拠点コードと物流センタ拠点コードを一つの多値属性と誤解し、複合主キーにしてしまう。
- (k) に「工場拠点コード」を入れてしまい、配送元変更後の仕様を読み違える。
- スーパタイプから継承した主キーに再度破線下線を付け忘れ、キー属性表記ルールを逸脱する。
FAQ
Q: 納入ルートはルート番号だけでは一意にならないのですか?
A: 【問題文】で「納入ルートは、ルート番号で識別する。」とあるため、関係スキーマ上の主キーはルート番号のみです。ただし納入先と納入元を示す外部キーも保存する必要があります。
A: 【問題文】で「納入ルートは、ルート番号で識別する。」とあるため、関係スキーマ上の主キーはルート番号のみです。ただし納入先と納入元を示す外部キーも保存する必要があります。
Q: 委託工場と自社工場を別テーブルにしなくても良いのですか?
A: スーパタイプ「工場」に対し、識別可能なサブタイプが存在するため、第3正規形を保ちながら属性を分離する設計が推奨されます。これにより各サブタイプ固有属性(例:委託開始年月日)が NULL にならず整合性が高まります。
A: スーパタイプ「工場」に対し、識別可能なサブタイプが存在するため、第3正規形を保ちながら属性を分離する設計が推奨されます。これにより各サブタイプ固有属性(例:委託開始年月日)が NULL にならず整合性が高まります。
関連キーワード: 正規化、サブタイプ継承、外部キー、エンティティ識別、リレーションシップ
設問2:〔新たな商品の追加〕について、(1)〜(3)に答えよ。
(3)工場と(オ)の間のリレーションシップは1対多に設定しているが、このリレーションシップの多側のカーディナリティは2種類の値をとる。 それぞれについて、カーディナリティの値(数値)と、どのような場合に発生するかを25字以内で具体的に答えよ。
模範解答
①:カーディナリティの値:1
発生する場合:自社工場から物流センタに納入する場合
②:カーディナリティの値:3
発生する場合:委託工場から物流センタに納入する場合
解説
解答の論理構成
- リレーションシップの対象を特定
- 工場側:自社工場/委託工場
- 多側(オ):納入ルート
- 【問題文】引用により組数を確認
- 「自社工場内の物流センタ」…一つの工場に対して物流センタは同一敷地内で1つ。
- 「各委託工場と各物流センタ」…物流センタは自社工場と同数で「3か所」。
- 組み合わせ数=納入ルート数
- 自社工場は 1×1=1 → カーディナリティ「1」。
- 委託工場は 1×3=3 → カーディナリティ「3」。
- よって多側のカーディナリティは「1」「3」と決定する。
誤りやすいポイント
- 物流センタの数を「5か所の委託工場」と取り違えて「5」と誤答。
- 「1対多」の“多”を無条件に「複数」とだけ書き具体値を示さない。
- 自社工場にも物流センタが3か所あると読み違える。
FAQ
Q: 委託工場が5か所あるのだから「5」では?
A: 組を作るのは「各委託工場 × 各物流センタ」です。物流センタは3か所なので1工場あたり3ルートです。
A: 組を作るのは「各委託工場 × 各物流センタ」です。物流センタは3か所なので1工場あたり3ルートです。
Q: 物流センタはどこに存在すると考える?
A: 【問題文】「自社工場内で…物流センタとしての拠点コードを付与する」とあるように、自社工場敷地内に1か所ずつ設けられます。
A: 【問題文】「自社工場内で…物流センタとしての拠点コードを付与する」とあるように、自社工場敷地内に1か所ずつ設けられます。
Q: 自社工場から他の物流センタへ納入するケースは?
A: 設問条件では「自社工場と自社工場内の物流センタ」をルートと定義しているため想定しません。
A: 設問条件では「自社工場と自社工場内の物流センタ」をルートと定義しているため想定しません。
関連キーワード: カーディナリティ、納入ルート、サブタイプ、リレーションシップ、正規化


