DBデータベーススペシャリスト試験 午後Ⅱ

令和7年度秋期 データベーススペシャリスト 午後Ⅱ 問2

事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。

問題

問2 宅配ピザチェーンにおける店舗への資材配送業務の概念データモデリングに関する次の記述を読んで,設問に答えよ。 B社は,宅配ピザチェーンである。B社では,店舗資材配送システムの再構築を進めており,業務分析を行い,概念データモデル及び関係スキーマを設計した。 〔現状の業務分析の結果〕 1.社内外の組織に関連する資源 (1) 全国を対象に,人口分布及び道路状況を考慮して幾つかの郵便番号の指す区域を束ねて地区として設定している。地区は地区コードで識別する。 (2) 首都圏及び地方中核都市のベッドタウンに重点的に店舗を展開しており,約500店がある。店舗は店舗コードで識別し,いずれかの地区に立地する。 (3) 物流センター(以下,DCという)は全国に12あり,DCコードで識別する。 ① DCは,幾つかの地区を束ねて,それらにある店舗を配送対象にしている。 ② DCは,店舗への資材の配送及び調達先からの資材の受入れを行う。 ③ DC内の倉庫には80~120程度の区画があり,DCごとに区画番号で識別する。区画のほとんどは冷蔵保管の機能で,残りの一部が常温保管と冷凍保管の機能となっている。区画がいずれの機能かは,機能区分で分類する。 ④ 区画は,幾つかの棚に仕切られており,棚が幾つあるかの棚数をもつ。 ⑤ 棚は,区画ごとに棚番号で識別する。 (4) DCから店舗へ配送するトラックのルートを整備している。ルートはDCごとのルート番号で識別し,車両番号をもつ。 ① ルートの店舗への納入は13~16時の間に終わるように設定している。 ② ルートごとに店舗への納入順を決めている。 (5) 資材の調達先をベンダーと呼び,ベンダーコードで識別する。 2.商品及び資材に関連する資源 (1) 店舗で販売する商品は,商品コードで識別し,商品名をもつ。 ① 商品の種類には,ピザ,追加トッピング,サイドメニュー,ドリンクがあり,商品種類区分で分類する。 ② 商品には,ピザであればマルゲリータ,ハワイアンなど,サイドメニューであればフライドチキン,サラダなどがある。 ③ ピザ及び追加トッピングには,S,M,Lの3サイズがある。 ④ ドリンクには,MサイズとLサイズの2サイズがある。 ⑤ 全てのサイドメニューはMサイズの1サイズだけである。複数のサイドメニューの組合せ及び入れる個数の違うものは,別の商品としている。 ⑥ ピザのようにサイズのある商品もあるが,商品はサイズ別には登録しない。商品には,その商品に幾つサイズがあるかのサイズ数をもつ。 ⑦ ハーフ&ハーフなどの組合せ商品は,マルゲリータ&ハワイアンのように商品名を付けてあらかじめ全ての組合せを登録する。 ⑧ 商品の販売には,定番商品,期間限定商品,新商品があり,商品販売区分で分類する。 ・定番商品は,その商品の前年日販数をもつ。 ・期間限定商品は,販売期間の開始と終了の年月日をもつ。 ・新商品は,3か月の評価期間の売れ行きで判断し,定番化するか否か決めるもので,販売開始の年月日と定番化判断の結果をもつ。 (2) 資材は資材コードで識別し,資材名,調達先ベンダーコードなどをもつ。 ① 資材には,食材と梱包材がある。梱包材は,調理したピザやサイドメニューの梱包に用いる。資材がいずれであるかは食材梱包材区分で分類する。 ② 資材が,冷蔵保管,常温保管,冷凍保管のいずれの対象かを保管温度帯区分で分類する。 ③ 定番商品に用いる食材及び梱包材を共通資材と呼ぶ。共通資材には,食材であればピザ台,チーズ,サラミ,ハム,カット野菜,食用油などがあり,梱包材であれば商品共通の箱やポリ袋などがある。3か月平均単価をもつ。 ④ 期間限定商品と新商品に固有で用いる食材及び梱包材を企画資材と呼ぶ。企画期間単価をもつ。 ⑤ 資材が,共通資材であるか企画資材であるかは,共通企画区分で分類する。 ⑥ 資材には計量単位を設定する。枚,グラム,個,ミリリットルなどがある。 (3) 資材をベンダーから購入する荷姿を購入荷姿と呼ぶ。主に容量が50リットル程度の段ボール箱である。 (4) DCから資材を店舗に配送する荷姿を配送荷姿と呼ぶ。配送の最小単位であり,購入荷姿の段ボール箱を開梱した小箱,袋,ボトルなどである。DCでは,この単位で保管するので保管荷姿とも呼ぶ。 (5) 資材には,購入荷姿の入数と配送荷姿の入数をもつ。DCから店舗への配送は,配送荷姿の入数の整数倍で行う。 (6) 資材を調達するベンダーは,資材ごとに1社に決めている。 3.資源の組合せで定める資源及び在庫 (1) 商品とサイズの組合せで,資材ごとの使用量をレシピとして登録している。使用量は調理時のロスを考慮している。 (2) DCごとに資材の在庫をもつ。 4.商品企画のやり方 (1) 商品企画の対象は期間限定商品と新商品である。期間限定商品と新商品で商品企画のやり方は同じである。 (2) 期間限定商品のレシピ及び販売期間はB社の本部が定める。 (3) 本部は,新商品の評価期間後に定番商品にするか廃番にするかを決める。新商品を定番商品にする場合,新たに定番商品として登録する。 5.DCからベンダーへの発注のやり方 定量発注と計画発注がある。どちらも1日に高々1回行う。 (1) 定量発注のやり方 ① 共通資材を対象として,定量発注を実施している。 ② B社が採用している定量発注は,DCごと資材ごとに発注ロットサイズ,発注リードタイムを調達条件として取り決めておき,DCの実在庫数が,DCごと資材ごとに設定した基準在庫数を下回ったときに,発注ロットサイズ分の発注を日次で行う方式である。発注ロットサイズは購入荷姿の入数の整数倍にする。調達条件は必要に応じてベンダーと協議する。 ③ 定量発注では,確かに在庫を確認して発注したものか否かを表す在庫確認サイン及び発注年月日を記録する。 (2) 計画発注のやり方 ① 企画資材を対象として,計画発注を実施している。 ② 計画発注では,全販売期間にわたって週次の調達量をあらかじめ発注する。発注年月日,発注数及び希望納期年月日を記録する。 6.DCでの在庫保管のやり方 (1) 倉庫内の資材の保管は,固定ロケーション方式を採用している。 ① 倉庫の区画に対して一つ又は複数の資材を割り当てるが,一つの資材は一つの区画だけに収めている。DCごと資材ごとに保管区画を決めている。 ② 資材は一つ又は複数の棚に割り当てるが,一つの棚には一つの資材だけを割り当てる。 (2) 同じ資材は,先に入庫したものから先に出庫する先入先出を行う。 ① 資材に割り当てた棚には,次に入庫する棚を示す後続棚番号をもたせ,同じ資材に割り当てた棚の中で後続棚番号が一巡するように設定する。棚には,同じことが目視で判別できるように,棚番号,後続棚番号,割り当てている資材コードと資材名を記載したプレートを掲示する。 ② 最後に入庫した棚番号を最終入庫棚番号として記録する。最後に出庫した棚番号を最終出庫棚番号として記録する。最終入庫棚番号と最終出庫棚番号は,DCの資材在庫にもつ。これによって,次の入庫又は出庫をどの棚番号から行えばよいかを知ることができる。 7.入荷及び入庫のやり方 (1) 入荷では,ベンダーの納品を受けて資材ごとに現物を確認し,入荷年月日,検品サイン,どの発注に基づく入荷かの対応を記録する。 ① 定量発注による入荷では,入荷時分を記録する。 ② 計画発注による入荷はベンダーの都合で分納され得る。入荷数を記録する。 (2) 入荷した段ボール箱を開梱して保管荷姿の現品を入庫する。入庫は入荷の単位に行い,入庫時分を記録する。 (3) 保管荷姿の現品には,資材の情報を記したバーコードラベルを貼付する。 8.DCでの出庫のやり方 (1) DCでは毎営業日の8~11時に出庫を行う。出庫は摘取方式で行う。摘取方式とは,店舗ごとの出庫要求に従って倉庫を回って資材を出庫し,店舗ごとに用意したかご台車に積むやり方である。 (2) 出庫に先立って出庫要求をまとめる。出庫要求では,共通資材の補充要求,企画資材の計画要求,店舗の追加要求の3種類の資材要求を作り,資材要求から店舗ごと資材ごとに対象の配送年月日の出庫要求を導く。3種類の資材要求は要求区分で分類する。 (3) 共通資材の補充要求は,各店舗の販売実績から求めることのできる共通資材ごとの使用量を必要量として,配送の1営業日前に次の手順で求めたものである。共通資材の補充要求は,算出時分をもつ。 ① 店舗の営業終了時に,各店舗から当日の販売実績として,販売年月日,店舗コード,商品コード,販売サイズ,販売数を連携してもらう。 ② 連携された販売実績とレシピを基に,全ての資材の使用量を求める。 ③ ②の結果のうち共通資材だけを対象に,店舗ごと資材ごとに集計して共通資材の使用量を求め,配送荷姿の入数で除して四捨五入することで配送荷姿での必要数とし,資材要求数を導く。 (4) 企画資材の計画要求は,販売期間及び各店舗の販売実績を勘案して求めた営業日ごと企画資材ごとの必要量をDCが事前に登録したものである。登録年月日を記録する。 (5) 店舗の追加要求は,店舗責任者が事前に登録してある共通資材の補充要求と企画資材の計画要求を前提に判断し,全ての資材について追加で必要な資材を要求する。登録年月日時分を記録する。 (6) 出庫は,導いた出庫要求に基づいて行う。店舗ごとに出庫すべき資材を全て出庫し終わったら出庫完了時分を記録し,内訳の出庫実績数を記録する。 9.DCでの出荷のやり方 (1) 店舗への出荷を毎営業日に1回,13時から実施する。 (2) 出荷では,配送車が出発するごとに配送年月日,出荷時分を記録する。 (3) 出荷の店舗ごとの内訳では対象店舗を記録する。 (4) 出荷の店舗ごと資材ごとの内訳として出荷店舗資材明細を作り,どの出庫の内訳を対応させたかと出荷実績数を記録する。 10.店舗への納入のやり方 (1) ルートの納入順に店舗へ納入を行う。納入は,かご台車のまま納品書を添えて店舗に引き渡し,店舗が確認することで完了する。 (2) 納入は,出荷店舗明細と対応付け,納入時分と店舗の確認サインを記録する。 (3) 店舗からは,前回の納入で用いたかご台車を回収する。かご台車の回収は特に記録しない。 〔再構築における店舗への出庫及び出荷のやり方の変更〕 1.変更の背景 B社は,創業以来DCでの出庫は摘取方式で行ってきたが,DC当たりの店舗数が増えてきたので,作業効率を上げるために種まき方式に変更することにした。 2.変更する出庫のやり方 (1) 種まき方式とは,資材ごとに全ての店舗分をまとめて一度に出庫し,出庫した資材を各店舗向けのかご台車に種まきをするように仕分けるやり方である。 (2) 共通資材の補充要求の求め方,企画資材の計画要求の登録の仕方,店舗の追加要求の仕方の3種類の資材要求数の導き方は変えず,資材要求からDCごと資材ごとに対象配送年月日の出庫要求を導くように変更する。 (3) 出庫要求とは別に,出荷の段取りとして資材要求から店舗ごと資材ごとに対象配送年月日の出荷予定明細を導き,出荷予定数をもつ。 (4) 出庫は区画ごとに実施し,出庫明細で区画内の資材を出庫要求に基づいて出庫する。出庫では配送年月日と出庫完了時分を記録し,出庫明細で出庫要求との対応と出庫実績数を記録する。 3.出庫のやり方の変更に伴う出荷のやり方の変更 (1) 出荷の店舗ごと資材ごとの内訳で,どの出荷予定明細に基づいたか,どの出庫明細と対応付けたかを記録する。 (2) 出荷店舗資材明細に出荷実績数を記録する。 〔概念データモデルと関係スキーマの設計〕 1.概念データモデル及び関係スキーマの設計方針 (1) 関係スキーマは第3正規形にし,多対多のリレーションシップは用いない。 (2) リレーションシップが1対1の場合,意味的に後からインスタンスが発生する側に外部キー属性を配置する。 (3) 概念データモデルでは,リレーションシップについて,対応関係にゼロを含むか否かを表す「○」又は「●」は記述しない。 (4) 実体の部分集合が認識できる場合,その部分集合の関係に固有の属性があるときは部分集合をサブタイプとして切り出す。 (5) サブタイプが存在する場合,他のエンティティタイプとのリレーションシップは,スーパータイプ又はいずれかのサブタイプの適切な方との間に設定する。 (6) 概念データモデル及び関係スキーマは,マスター及び在庫領域と,トランザクション領域を分けて作成し,マスターとトランザクションの間のリレーションシップは記述しない。 (7) 関係スキーマでは,可読性を重視するので自然キー(ナチュラルキー)だけを用い,代理キー(サロゲートキー)は用いない。 (8) 自然キーを参照する外部キーには冗長な属性が必要になる場合がある。この場合,属性名の前後を「[」と「]」で挟んで明示する。結合して求まる冗長な属性を明示する例を図1に示す。また,スーパータイプからサブタイプに継承した冗長な属性を明示する例を図2に示す。 図1 結合して求まる冗長な属性を明示する例 図2 継承して冗長な属性を明示する例 2.設計した概念データモデル及び関係スキーマ (1) 〔現状の業務分析の結果〕を基に設計した現状のマスター及び在庫領域の概念データモデルを図3に,現状のトランザクション領域の概念データモデルを図4に,現状のマスター及び在庫領域の関係スキーマを図5に,現状のトランザクション領域の関係スキーマを図6に示す。 図3 現状のマスター及び在庫領域の概念データモデル(未完成) 図4 現状のトランザクション領域の概念データモデル(未完成) 図5 現状のマスター及び在庫領域の関係スキーマ(未完成) 図6 現状のトランザクション領域の関係スキーマ(未完成) (2) 〔再構築における店舗への出庫及び出荷のやり方の変更〕を基に,トランザクション領域の概念データモデルと関係スキーマの一部を変更した。図4に対して変更を検討する範囲を示した概念データモデルを図7に,変更した概念データモデルを図8に,変更した関係スキーマを図9に示す。 図7 変更を検討する範囲を示した概念データモデル(図4の再掲,未完成) 図8 変更した概念データモデル(未完成) 図9 変更した関係スキーマ(未完成) 解答に当たっては,巻頭の表記ルールに従うこと。また,エンティティタイプ名,関係名,属性名は,本文中の字句を用いて適切な名称とすること。関係スキーマに入れる属性名を答える場合,主キーを表す下線,外部キーを表す破線の下線についても答えること。 設問1 〔現状の業務分析の結果〕を基にした概念データモデル及び関係スキーマについて,次の問いに答えよ。 なお,解答に当たっては,本文中に示した設計方針に従うこと。 (1) 図3は,幾つかのリレーションシップが欠落している。欠落しているリレーションシップを補って図を完成させよ。 (2) 図4は,幾つかのリレーションシップが欠落している。欠落しているリレーションシップを補って図を完成させよ。 (3) 図5中の【ア】~【ケ】に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。 (4) 図6中の【コ】~【ナ】に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。 設問2 〔再構築における店舗への出庫及び出荷のやり方の変更〕に基づいて変更した概念データモデル及び関係スキーマについて,次の問いに答えよ。 (1) 図8には,四つのエンティティタイプが欠落している。欠落したエンティティタイプ及び関連するリレーションシップを補って図を完成させよ。 なお,欠落しているエンティティタイプを補うときのエンティティタイプ名は,本文中の字句を参考に,現状と同じエンティティタイプ名の使用も含めて意味的にふさわしく命名せよ。 (2) 図9において,(1)で補った四つのエンティティタイプに対応する関係を追加する必要がある。追加する関係について,関係スキーマを答えよ。 なお,(1)で補った四つのエンティティタイプに対応する関係の関係名は,(1)で補ったエンティティタイプ名を用いること。 (3) 図9中の【ニ】,【ヌ】に入れる一つ又は複数の適切な属性名を補って関係スキーマを完成させよ。
図1 結合して求まる冗長な属性を明示する例。概念データモデルと関係スキーマの例を示し,結合によって求める冗長な属性を関係スキーマに角括弧で示している。
図1 結合して求まる冗長な属性を明示する例。概念データモデルと関係スキーマの例を示し,結合によって求める冗長な属性を関係スキーマに角括弧で示している。
図2 継承して冗長な属性を明示する例。スーパータイプとサブタイプの概念データモデル及び関係スキーマを示し,継承した冗長な属性を角括弧で示している。
図2 継承して冗長な属性を明示する例。スーパータイプとサブタイプの概念データモデル及び関係スキーマを示し,継承した冗長な属性を角括弧で示している。
図3 現状のマスター及び在庫領域の概念データモデル(未完成)。DC,地区,店舗,区画,棚,資材,商品など,マスター及び在庫領域のエンティティタイプを配置した未完成の概念データモデル。
図3 現状のマスター及び在庫領域の概念データモデル(未完成)。DC,地区,店舗,区画,棚,資材,商品など,マスター及び在庫領域のエンティティタイプを配置した未完成の概念データモデル。
図4 現状のトランザクション領域の概念データモデル(未完成)。販売実績,資材要求,出庫,出荷,入荷,発注など,トランザクション領域のエンティティタイプを配置した未完成の概念データモデル。
図4 現状のトランザクション領域の概念データモデル(未完成)。販売実績,資材要求,出庫,出荷,入荷,発注など,トランザクション領域のエンティティタイプを配置した未完成の概念データモデル。
図5 現状のマスター及び在庫領域の関係スキーマ(未完成)。DC,地区,店舗,資材,商品,レシピ及びDC資材在庫などの関係スキーマと空欄属性を示している。
図5 現状のマスター及び在庫領域の関係スキーマ(未完成)。DC,地区,店舗,資材,商品,レシピ及びDC資材在庫などの関係スキーマと空欄属性を示している。
図6 現状のトランザクション領域の関係スキーマ(未完成)。販売実績,資材要求,出庫,出荷,納入,発注,入荷及び入庫などの関係スキーマと空欄属性を示している。
図6 現状のトランザクション領域の関係スキーマ(未完成)。販売実績,資材要求,出庫,出荷,納入,発注,入荷及び入庫などの関係スキーマと空欄属性を示している。
図7 変更を検討する範囲を示した概念データモデル(図4の再掲,未完成)。図4のうち,資材要求から出庫及び出荷店舗資材明細までの変更検討対象を破線枠で示している。
図7 変更を検討する範囲を示した概念データモデル(図4の再掲,未完成)。図4のうち,資材要求から出庫及び出荷店舗資材明細までの変更検討対象を破線枠で示している。
図8 変更した概念データモデル(未完成)。変更後の資材要求,出荷,出荷店舗明細及び出荷店舗資材明細を配置した未完成の概念データモデル。
図8 変更した概念データモデル(未完成)。変更後の資材要求,出荷,出荷店舗明細及び出荷店舗資材明細を配置した未完成の概念データモデル。
図9 変更した関係スキーマ(未完成)。変更後の資材要求,出荷,出荷店舗明細及び出荷店舗資材明細の関係スキーマと空欄属性を示している。
図9 変更した関係スキーマ(未完成)。変更後の資材要求,出荷,出荷店舗明細及び出荷店舗資材明細の関係スキーマと空欄属性を示している。
解き方のヒントを見る

業務記述とモデルの対応を確かめる

データモデルの問題では、業務の説明に書かれた一文一文が、モデル上のどの要素や制約に反映されているかを対応づけて読むことが基本です。推測で補わず、根拠となる記述を必ず探してから判断する姿勢を保ちましょう。

この問題で問われていること

確認すべき観点は一つです。検討中の箇所について、それを裏付ける業務上の記述がどこにあるかを特定し、その記述とモデルの表現が過不足なく対応しているかを確かめてください。変更の話題でも同じ観点で読み直します。

視点

概念データモデルや関係スキーマは、業務のルールを形式的に書き表したものです。モデル上の要素は業務の説明のどこかに根拠を持つはずであり、逆に業務の説明にあるルールはモデルのどこかに表れているはずです。この双方向の対応を意識すると、一般知識や思い込みではなく、与えられた状況に即した判断がしやすくなります。

確認ポイント

  • 判断しようとしている箇所の根拠となる業務上の記述を、自分で指し示せるか
  • その記述が表す条件を、モデル側の表現と照らして過不足なく読み取れているか
  • 一般的な業務の常識ではなく、与えられた状況の記述だけに基づいて判断しているか
正解と解説を見る

解説

宅配ピザチェーンB社の店舗資材配送業務について、マスター及び在庫領域とトランザクション領域の概念データモデル・関係スキーマを完成させる問題です。公式解答例のポイントは三つあります。一つ目は、DC・地区・ルート・区画・棚・DC資材在庫の関係を、固定ロケーション方式と先入先出という在庫コントロールの工夫から読み取ることです。二つ目は、資材要求から出庫要求・出庫・出荷・納入へ続くデータの粒度を、店舗単位・配送年月日単位で正しく捉えることです。三つ目は、摘取方式から種まき方式に変えると、出庫要求と出庫がDC単位・区画単位に変わり、出荷予定明細が新たに加わることを反映することです。自然キーだけで参照するため、[DCコード]などの冗長属性が必要になる箇所も多くあります。

問題の全体像

B社は宅配ピザチェーンで、店舗資材配送システムを再構築しています。本文には、次の三つの業務が細かく書かれています。(1)DC・地区・郵便番号・ルート・店舗・区画・棚などの組織と資源、(2)商品・資材・レシピ・DC資材在庫、(3)資材要求→出庫要求→出庫→出荷→納入の流れと、発注→入荷→入庫の流れ。後半では、出庫を摘取方式から種まき方式に変えることで、トランザクション領域の一部が作り変わります。設計方針には、第3正規形にすること、多対多を使わないこと、1対1では後から発生する側に外部キーを置くこと、自然キーだけを使い、必要な冗長属性は[ ]で示すことが定められています。出題趣旨では、トップダウンにエンティティタイプとリレーションシップを分析する力、ボトムアップに関係スキーマを導く力、自然キーだけで読みやすい関係スキーマを設計する力、業務のやり方の変更による影響を読み取る力を問うとされています。採点講評では、全体として正答率は高かったとしています。一方で、DC資材在庫・店舗・棚・資材要求・出荷・出荷店舗明細の誤答が多かったことと、設問2で図と関係スキーマが整合しない答案が見られたことが指摘されています。

設問1(1)

公式解答例で追加されているリレーションシップは次のとおりです。

・DC→地区、DC→ルート、DC→区画、地区→郵便番号、ルート→店舗、DC→共通資材調達条件、商品→レシピ、資材→棚、区画→DC資材在庫:いずれも1対多

・棚とDC資材在庫の間:1対1が2本

・棚の自己参照:1対1

根拠は次の記述です。「DCは幾つかの地区を束ねる」「郵便番号の区域を束ねて地区とする」ことから、DC→地区→郵便番号となります。「ルートはDCごとのルート番号で識別」「区画はDCごとに区画番号で識別」ことから、DC→ルートとDC→区画です。「ルートごとに店舗への納入順を決めている」ことから、ルート→店舗です。調達条件は「DCごと資材ごと」なのでDC→共通資材調達条件、レシピは「商品とサイズの組合せで資材ごと」なので商品→レシピになります。在庫は固定ロケーション方式で、「一つの棚には一つの資材だけ」を割り当てるので資材→棚です。「DCごと資材ごとに保管区画を決めている」ので区画→DC資材在庫です。先入先出のため、後続棚番号によって棚は1対1で自分自身を参照します。DC資材在庫が持つ最終入庫棚番号と最終出庫棚番号は、それぞれ特定の棚を1対1で指します。採点講評は、DC資材在庫に関わるリレーションシップの正答率が低かったとし、在庫をどうコントロールするかという業務の工夫によってデータ構造が決まると述べています。

設問1(2)

公式解答例で追加されているリレーションシップは次のとおりです。

・出庫要求→資材要求:1対多

・出庫要求と出庫明細、出庫明細と出荷店舗資材明細、出荷店舗明細と納入、定量発注と定量発注入荷、入荷と入庫:いずれも1対1

・計画発注→計画発注入荷:1対多

資材要求は要求区分(3種類)ごとに作られ、それを店舗ごと資材ごと配送年月日ごとにまとめたものが出庫要求なので、1対多になります。出庫は出庫要求に基づいて行われ、摘取方式では両者の粒度が同じなので、出庫明細は出庫要求と1対1です。出荷店舗資材明細は「どの出庫の内訳を対応させたか」を記録するので、出庫明細と1対1です。納入は出荷店舗明細と対応付けるので1対1、入庫は「入荷の単位に行う」ので入荷と1対1です。発注と入荷の対応はサブタイプ同士で結びます。定量発注は分納がないので定量発注入荷と1対1、計画発注は「ベンダーの都合で分納され得る」ので計画発注入荷と1対多です。採点講評は、業務のやり方によってデータが集約されたり分解されたりするトランザクションの連鎖を見誤った答案が多かったと指摘しています。

設問1(3)

公式解答例の各空欄と根拠は次のとおりです。

・ア(地区):外部キーのDCコード。DCが地区を束ねるためです。

・イ(郵便番号):外部キーの地区コード。

・ウ(ルート):主キーはDCコードとルート番号、属性に車両番号。

・エ(店舗):地区コード、ルート番号、納入順、[DCコード]。ルートの主キーはDCコードとルート番号なので、店舗からルートを参照するにはDCコードも必要です。DCコードは地区との結合で求まるため、冗長属性として[ ]で示します。採点講評は、納入順を店舗に設定すべきことが読み取れていない誤りが多かったと指摘しています。

・オ(区画):主キーはDCコードと区画番号、属性に機能区分と棚数。

・カ(棚):主キーはDCコード、区画番号、棚番号。外部キーとして資材コードと後続棚番号を持ちます。

・キ(共通資材調達条件):DCコード(主キーの一部)、発注ロットサイズ、発注リードタイム。

・ク(レシピ):商品コードとサイズを主キーに加え、属性に使用量。

・ケ(DC資材在庫):保管区画番号、基準在庫数、実在庫数、最終入庫棚番号、最終出庫棚番号。保管区画番号・最終入庫棚番号・最終出庫棚番号は外部キーで、DCコードと組み合わせて区画や棚を参照します。備考によると、基準在庫数はキに解答してもよいとされています。

設問1(4)

公式解答例の各空欄と根拠は次のとおりです。

・コ(資材要求とそのサブタイプ):店舗コード、配送年月日、資材コード、要求区分。3種類の要求を要求区分で区別し、店舗ごと資材ごと配送年月日ごとに作るためです。

・サ(出庫要求):店舗コード、配送年月日、資材コード。

・シ(出庫):店舗コード、配送年月日。摘取方式では店舗ごとに出庫完了時分を記録するためです。

・ス(出庫明細):店舗コード、配送年月日、資材コード。

・セ(出荷):DCコード、ルート番号、配送年月日。「配送車が出発するごと」、つまりルートごとに記録するためです。

・ソ(出荷店舗明細):主キーは店舗コードと配送年月日。出荷を参照するための[DCコード][ルート番号]は、店舗マスターから求まる冗長属性です。

・タ(出荷店舗資材明細):店舗コード、配送年月日、資材コード。

・チ(納入):店舗コード、配送年月日。

・ツ(発注とそのサブタイプ):DCコード、発注年月日、資材コード。発注は1日に高々1回だからです。

・テ(入荷):外部キーではない発注年月日。発注との対応はサブタイプ側で表すためです。

・ト(定量発注入荷・計画発注入荷):[発注年月日]。スーパータイプから継承した冗長属性を外部キーとして使い、各発注を参照します。

・ナ(入庫):DCコード、入荷年月日、資材コード。

採点講評は、資材要求では集約前のデータの粒度、出荷と出荷店舗明細では納入に向けて集約した粒度の読み取りが不十分な誤答が多かったと指摘しています。

設問2(1)

公式解答例で追加されているエンティティタイプは、出庫要求、出荷予定明細、出庫、出庫明細の四つです。リレーションシップは次のとおりです。

・出庫→出庫明細、出庫要求→資材要求、出荷予定明細→資材要求、出庫明細→出荷店舗資材明細:いずれも1対多

・出庫要求と出庫明細、出荷予定明細と出荷店舗資材明細:いずれも1対1

種まき方式では、出庫要求は「DCごと資材ごとに対象配送年月日」で導かれるため、店舗単位の資材要求を集約する1対多になります。一方、出荷予定明細は「店舗ごと資材ごと」に資材要求から導かれるので、これも資材要求と1対多です。出庫は区画ごとに行い、出庫明細は出庫要求と1対1で対応します。資材ごとにまとめて出庫したものを店舗へ仕分けるので、一つの出庫明細が複数の出荷店舗資材明細に対応する1対多です。出荷店舗資材明細は、どの出荷予定明細に基づいたかを記録するので、出荷予定明細と1対1です。

設問2(2)

公式解答例の関係スキーマは次の四つです。

・出庫要求(DCコード、配送年月日、資材コード、出庫要求数)

・出荷予定明細(店舗コード、配送年月日、資材コード、出荷予定数)

・出庫(DCコード、区画番号、配送年月日、出庫完了時分)

・出庫明細(DCコード、配送年月日、資材コード、[区画番号]、出庫実績数)

出庫は区画ごと配送年月日ごとに行うため、区画番号が主キーに入ります。出庫明細は出庫要求と同じキーを持ち、出庫を参照するのに区画番号が必要です。区画番号はDC資材在庫の保管区画番号から求まるので、冗長属性として[ ]で示します。採点講評は、(1)で答えた対応関係と(2)の関係スキーマの構造が整合しない答案が散見されたと指摘しています。(1)で1対多・1対1とした関係が、キーの構成に正しく表れているかを確認することが重要です。

設問2(3)

公式解答例の解答と根拠は次のとおりです。

・ニ(資材要求):店舗コード、配送年月日、資材コード、要求区分、[DCコード]

・ヌ(出荷店舗資材明細):店舗コード、配送年月日、資材コード、[DCコード]

変更後の出庫要求と出庫明細はDCコードを主キーに持ちます。そのため、店舗単位の資材要求や出荷店舗資材明細からこれらを参照するにはDCコードが必要です。DCコードは店舗から地区を通じて求まるので、結合で求まる冗長属性として[ ]で示します。出荷予定明細や出荷店舗明細への参照は、店舗コード・配送年月日・資材コードで表せます。関係スキーマから概念データモデルを見直し、両者の整合を確認することが採点講評でも求められています。

学習のポイント

本文の「〜ごと」「1日に1回」などの記述から主キー(識別子)を決める練習が中心です。あわせて、1対1・1対多の判断、冗長属性[ ]の付け方、業務のやり方の変更に伴うデータ粒度の変化を読み取る練習をしましょう。

出典:独立行政法人 情報処理推進機構(IPA)令和7年度秋期 データベーススペシャリスト試験 午後Ⅱ 問2(公式資料:問題冊子(PDF) / 解答例 / 採点講評)

関連する過去問一覧

IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針