令和2年度10月 データベーススペシャリスト 午後Ⅰ 問1

業務記述と設計要素の対応を確かめる

設計の各要素がどの業務記述に裏付けられているかを一つずつ突き合わせる視点に絞ります。思い込みや一般的な設計慣習ではなく、提示された業務の条件そのものから判断できるかを意識して検討を進めてください。

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

問われている箇所に関係する業務の記述を先に特定し、その記述が何を定めていて何を定めていないのかを区別してから、設計上の判断と照らし合わせることが検討の中心になります。根拠の範囲を意識しましょう。

視点

データモデルや関係スキーマの設計では、設計の良し悪しを一般論で決めるのではなく、業務要件として書かれた条件に根拠を求めます。業務の記述には、明示されている条件と、書かれていないため判断材料にならない事柄があります。この二つを混同すると、要件にない前提を持ち込んだり、要件で定められた条件を見落としたりしやすくなります。まず該当する記述を探し、その記述が設計に何を求めているかを自分の言葉で言い直してから、設計内容と対応づける習慣を持つと、判断の筋道が安定します。

確認ポイント

• 問われている箇所に関係する業務記述を、問題の中から具体的に探し出せているか
• その記述が明示している条件と、記述からは読み取れない事柄を区別できているか
• 自分の判断が業務記述に基づくものか、一般的な設計の慣習や思い込みに基づくものかを確認したか

解説

食料品スーパの自社商品について、発注・生産・配送の業務を概念データモデルと関係スキーマで表し、委託商品・委託工場・物流センタの追加に合わせてモデルを拡張する問題です。「〜で識別する」「〜を記録する」という記述から主キー・外部キーとリレーションシップを読み取ることが基本になります。そのうえで、工場・ルート・自社仕様商品をサブタイプに分け、リレーションシップをスーパタイプとサブタイプのどちらに結ぶか判断します。採点講評では、明細系と自社商品の間のリレーションシップの記入漏れ、納入と配送の混同、1対1と1対3の読み取りについて、できていない解答が散見されたとされています。

問題の全体像

A社は、自社商品（弁当・総菜類）を生産工場で生産し、配送ルートに沿って店舗へ配送しています。店舗からの発注（発注・発注明細）をもとに、生産工場ごとの生産の指示（生産・生産明細）と、店舗ごとの配送の指示（配送・配送明細）を行い、発注明細には生産番号と配送番号を記録します。設問1では、この現状業務を概念データモデル（図1）と関係スキーマ（図2）にまとめます。設問2では、デザート・ケーキ類をB社の委託工場で生産する委託商品として追加し、工場内の仕分け・配送の役割を物流センタとして独立させ、工場から物流センタへの「納入」を新設します。これに伴い工場（自社工場・委託工場）、ルート（納入ルート・配送ルート）、自社仕様商品（自社商品・委託商品）をサブタイプに分けたモデル（図3、図4）を完成させます。出題趣旨では、業務要件に基づくデータモデルの把握力、リレーションシップと外部キーの設計能力、業務要件の変化に伴うデータモデルの拡張や設計変更の能力を問うとしています。

設問1(1)ア

図1では、アとイは1対多で結ばれており、アの下にイが従属する形です。問題文3.(1)③に「発注は発注番号で識別し、発注明細は発注番号と発注明細番号で識別する」とあります。図1には生産・生産明細、配送・配送明細はすでにあるのに、発注に当たるエンティティタイプがありません。したがって、公式解答例ではアを「発注」としています。採点講評では、ア・イともに正答率が高かったとされています。

設問1(1)イ

アを発注とすると、アに対して多側となるイは、発注番号と発注明細番号で識別される「発注明細」です。一つの発注の中で同じ自社商品を複数回登録でき、マイナス数量による減量・取消しも明細単位で扱うため（3.(1)②）、商品ごとの行は発注明細として別のエンティティタイプになります。公式解答例ではイを「発注明細」としています。

設問1(1)リレーションシップ

図2の外部キーとなる属性から、追加すべき線を洗い出します。公式解答例で追加されているのは次の7本で、いずれも1対多です。①店舗→発注：発注に店舗の拠点コードを確認・記録する（3.(1)④）。②店舗→配送：配送に配送先の拠点コードを記録する（3.(3)②）。③自社商品→発注明細、④自社商品→生産明細、⑤自社商品→配送明細：各明細は商品コードを持つ。⑥生産明細→発注明細：生産の対象とした発注明細に生産番号を記録する（3.(2)④）。発注明細は生産番号と商品コードを持つので、生産明細（生産番号、商品コード）を参照することになる。⑦配送明細→発注明細：同様に配送番号を記録する（3.(3)④）ので、配送明細（配送番号、商品コード）を参照する。店舗・生産工場は拠点のサブタイプなので、線は店舗（サブタイプ）側に結びます。採点講評では、概念データモデルの作成は正答率がやや低く、「発注明細」「生産明細」及び「配送明細」と「自社商品」のエンティティタイプ間のリレーションシップが記入できていない解答が散見されたとしています。状況記述や関係スキーマ、属性の意味・制約から業務ルールを読み取るよう求めています。

設問1(2)a

店舗について、1.(4)③に「店舗は、一つの配送ルートに属し、そのルート番号をもつ。また、配送ルート上何番目に配送されるかを表す配送順序をもつ」とあります。公式解答例では、aを「ルート番号、配送順序」としています。ルート番号は配送ルートを参照する外部キーなので破線の下線、配送順序は下線なしです。これが図1の配送ルート→店舗の1対多に対応します。

設問1(2)b

2.(4)に「自社商品ごとに生産ロットサイズを決めている」とあり、3.(2)③では生産数量を「自社商品の生産ロットサイズの倍数」で設定するとしています。生産ロットサイズは商品コードだけで決まる属性なので、自社商品の属性です。公式解答例ではbを「生産ロットサイズ」（下線なし）としています。

設問1(2)c

1.(4)②に、配送ルートは「ルート名称と一つの配送元の拠点コードをもつ」とあり、配送元は生産工場です（1.(4)①）。属性名は意味が識別できるよう、単なる「拠点コード」ではなく役割を示す名前にします。公式解答例ではcを「生産工場拠点コード」（外部キーの破線の下線）としています。これが図1の生産工場→配送ルートの1対多に対応します。

設問1(2)d

発注は発注番号で識別し（3.(1)③）、店舗の拠点コード、発注登録日時を確認し、配送予定日時を記録します（3.(1)④）。公式解答例ではdを「発注番号、店舗拠点コード、発注登録日時、配送予定日時」としています。発注番号が主キー（実線の下線）、店舗拠点コードが店舗を参照する外部キー（破線の下線）です。

設問1(2)e

発注明細は発注番号と発注明細番号で識別します（3.(1)③）。商品ごとの発注数量を持ち、生産番号（3.(2)④）と配送番号（3.(3)④）を記録します。公式解答例ではeを「発注番号、発注明細番号、商品コード、発注数量、生産番号、配送番号」としています。発注番号と発注明細番号は主キー（実線の下線）、商品コード・生産番号・配送番号は外部キー（破線の下線）です。一つの発注の中で同じ商品を複数回登録できるため、商品コードは主キーに含めません。

設問1(2)f

3.(2)②に「生産は、生産番号で識別し、生産工場の拠点コード、生産完了予定日時を記録する」とあります。公式解答例では、fを「生産工場拠点コード」（外部キーの破線の下線）としています。図1の生産工場→生産の1対多に対応します。

設問1(2)g

生産明細は「生産番号と商品コードで識別し」（3.(2)③）、配送明細は「配送番号と商品コードで識別し」（3.(3)③）とあります。gはどちらの関係にも入る共通の属性で、公式解答例では「商品コード」とし、主キーを構成するので実線の下線が付いています。この商品コードによって自社商品とのリレーションシップが生じます。

設問1(2)h

3.(3)②に「配送は、配送番号で識別し、配送完了予定日時と配送先の拠点コードを記録する」とあり、配送先は店舗です。公式解答例ではhを「店舗拠点コード」（外部キーの破線の下線）としています。図1の店舗→配送の1対多に対応します。

設問2(1)ウ

〔新たな商品の追加〕1.(3)で、工場は自社工場と委託工場に分かれます。図3のウからは委託商品へ1対多の線が出ています。「個々の委託商品を生産する委託工場は、一つに決まっている」ので、委託工場1に対して委託商品多となります。図4でもウは固有の属性を持つ工場のサブタイプです。公式解答例ではウを「委託工場」としています。

設問2(1)エ

工場のもう一つのサブタイプは、生産工場を改称した自社工場です（1.(3)）。図4のエは「拠点コード、操業開始年月日」を持ち、現状の生産工場が持っていた操業開始年月日が残っています。共通の生産能力はスーパタイプの工場に移っています。公式解答例ではエを「自社工場」としています。

設問2(1)オ

2.(1)①で、自社工場と物流センタ、委託工場と物流センタの組を納入ルートと呼び、2.(3)で配送ルートと併せてルートと呼んでいます。図3のオには工場から1対多の線が来ており、工場を出発点とするルートは納入ルートです。公式解答例ではオを「納入ルート」としています。

設問2(1)カ

図3のカからは店舗へ1対多の線が出ています。店舗は一つの配送ルートに属するという現状の関係（1.(4)③）がそのまま残っているので、カはルートのもう一つのサブタイプの配送ルートです。公式解答例ではカを「配送ルート」としています。

設問2(1)リレーションシップ

公式解答例で追加されているのは次のとおりです。①工場をスーパタイプ、委託工場・自社工場をサブタイプとする。②ルートをスーパタイプ、納入ルート・配送ルートをサブタイプとする。③物流センタ→納入ルート（納入先）。④物流センタ→配送ルート（配送元を物流センタに変更、2.(2)）。⑤納入ルート→納入（納入するルート番号を記録、2.(1)③）。⑥工場→生産（委託工場も自社工場と同様に生産を記録する（2.(4)③）ので、スーパタイプの工場と結ぶ）。⑦店舗→発注、⑧店舗→配送。⑨自社仕様商品→発注明細・納入明細・生産明細・配送明細（各明細が自社商品と委託商品の両方を扱うので、スーパタイプの自社仕様商品と結ぶ）。⑩納入明細→発注明細（納入の対象となる発注明細に納入番号を記録、2.(1)⑤）、生産明細→発注明細、配送明細→発注明細。工場→納入ルートは工場全体に共通するため、スーパタイプの工場から出ています（既存の線）。

設問2(2)i

ウは委託工場で、1.(3)に「委託工場は委託開始年月日をもつ」とあります。主キーはスーパタイプの工場と同じ拠点コードです。生産能力は工場（スーパタイプ）にあり、委託商品との関係は委託商品側が参照するので、委託工場に商品コードは持たせません。公式解答例ではiを「拠点コード、委託開始年月日」とし、拠点コードに主キーの実線の下線を付けています。採点講評では、設問2(2)は正答率が低かったとされています。

設問2(2)j

オは納入ルートで、工場と物流センタの組です（2.(1)①）。自社工場でも委託工場でも出発点となるので、スーパタイプの工場の拠点コードを参照する「工場拠点コード」と、納入先の「物流センタ拠点コード」の二つを持ちます。公式解答例ではjを「工場拠点コード、物流センタ拠点コード」とし、どちらも外部キーの破線の下線です。採点講評では、納入は工場から物流センタへの商品の移動、配送は物流センタから店舗への商品の移動を表すとしたうえで、納入と配送の違いを正確に読み取れていない解答が散見されたとしています。

設問2(2)k

カは配送ルートです。2.(2)で配送ルートの配送元が自社工場から物流センタに変わったので、現状の生産工場拠点コードに代わって配送元の物流センタを参照する属性を持ちます。配送先の店舗は店舗側がルート番号を持つので、配送ルートには入れません。公式解答例ではkを「物流センタ拠点コード」（外部キーの破線の下線）としています。jと同じく、納入（工場→物流センタ）と配送（物流センタ→店舗）の向きを区別することがポイントです。

設問2(3)①カーディナリティの値

工場1件に対して納入ルートが何件あるかを考えます。2.(1)①で、自社工場の納入ルートは「各自社工場と自社工場内の物流センタ」の組と定義されています。物流センタは、自社工場内で仕分け・配送を行っていた役割に付けた拠点なので（1.(5)）、自社工場1か所につき内部の物流センタは一つです。よって自社工場から出る納入ルートは1本で、公式解答例では値を「1」としています。

設問2(3)①発生する場合

値1になるのは、工場が自社工場で、自社工場内の物流センタへ納入する場合です。公式解答例は「自社工場から物流センタに納入する場合」で、25字以内に収まっています。答案では「自社工場」と「物流センタへの納入」の二つを押さえます。採点講評では、設問2(3)は正答率が低かったとされています。

設問2(3)②カーディナリティの値

委託工場の納入ルートは「各委託工場と各物流センタ」の組です（2.(1)①）。物流センタは自社工場ごとに一つあり、自社工場（旧生産工場）は3か所です（〔現状業務の概要〕1.(3)）。したがって物流センタは3か所で、委託工場1か所から出る納入ルートは3本になります。公式解答例では値を「3」としています。

設問2(3)②発生する場合

値3になるのは、工場が委託工場で、全ての物流センタへ納入する場合です。公式解答例は「委託工場から物流センタに納入する場合」です。①と対になるよう、工場の種類（委託工場）と納入先（物流センタ）を25字以内で示します。採点講評では、「工場」と「納入ルート」の間のリレーションシップについて、自社工場から物流センタへの納入の場合に1対1、委託工場から物流センタへの納入の場合に1対3になることが正確に読み取れていない解答が散見されたとしています。業務ルールの変更が概念データモデルにどう反映されたかを注意深く読み取るよう求めています。

学習のポイント

「識別する」「記録する」「〜をもつ」という記述から主キー・外部キー・リレーションシップを漏れなく洗い出す練習を重ねてください。あわせて、サブタイプを導入したときにリレーションシップをどちらに結ぶか、業務要件（拠点の数、組合せの定義）からカーディナリティを数値で導く手順を身に付けることが重要です。