www.youtube.com 本件は「令和2年度秋期 データベーススペシャリスト試験 午後Ⅰ 問1」に関する設問1・設問2の解答と解説であり、題材は食料品スーパーマーケットチェーンA社の弁当・総菜類を中心とした生産・配送業務です。午後Ⅰとして重要なのは、図表の穴埋めを単なる推測で埋めるのではなく、業務記述から業務オブジェクトの識別子、依存関係、役割分担、変更点を読み取り、概念データモデルと関係スキーマへ一貫して落とし込む読解力です。採点講評の観点でも、エンティティ名自体は比較的解きやすい一方で、明細系エンティティと商品との関連や、変更後の「納入」と「配送」の意味の取り違えが失点要因になりやすい構造になっています。 設問1は現状業務に基づき、図1の概念データモデルと図2の関係スキーマを完成させる問題です。図1の未完成部分アとイは、店舗からの発注をA社本部が受け付け、発注単位と明細単位で管理するという業務の基本構造をそのままデータモデルに写像する箇所です。店舗の要求は「発注」というトランザクションとして識別され、識別子が発注番号で与えられているため、アは発注となります。発注の中で個々の商品と数量を指定する必要があり、それは発注明細として切り出され、発注番号に加えて発注明細番号で識別される構造になるため、イは発注明細が適切です。ここで採点講評が示唆する典型的な落とし穴は、発注と発注明細の名称は当てられても、発注明細・生産明細・配送明細という明細系エンティティが、どの「商品」を対象としているのかという関係の記入を漏らすことです。業務上、発注明細は商品コードを持ち、同様に生産明細も配送明細も、実体としては「どの商品を、どれだけ」生産・配送するかの記録なので、明細エンティティと自社商品との関係は必ず必要になります。また、明細は親（発注、生産, 配送）に従属するため、発注明細は発注に、生産明細は生産に、配送明細は配送にそれぞれ従属するというリレーションシップも同時に欠かせません。午後Ⅰでは、この「親子関係」と「対象商品の参照」という二種類の関連を、業務文章から抜き出して図に正しく戻すことが読解ポイントになります。 図2の関係スキーマ完成は、現状業務の記述から属性を特定し、主キーと外部キーを整合させる作業です。店舗については、店舗が一つの配送ルートに属し、ルート上での配送順序を持つという要件があるため、店舗表にはルート番号（配送ルートへの参照となる外部キー）と配送順序が必要になります。自社商品は商品コードが主キーで、商品ごとに生産ロットサイズを決めているという要件があるため、生産ロットサイズが属性として入ります。配送ルートは配送元の拠点を持つという要件から、生産工場拠点コードが外部キーとして必要になります。発注は発注番号が主キーであり、発注を行う店舗の拠点コードと、発注登録日時、配送予定日時といった業務上の管理情報を持つため、店舗拠点コード（外部キー）、発注登録日時、配送予定日時が入ります。発注明細は発注番号と発注明細番号の複合で識別され、対象商品（商品コード）と発注数量を持ち、さらに後工程の生産番号、配送番号とひも付くことから、それらが外部キーとして入ります。生産は生産番号が主キーで、生産工場拠点コードが外部キーとして必要になります。生産明細は生産番号と商品コードで識別する形が自然で、商品コードは自社商品への外部キーになります。配送は配送番号が主キーで、配送先である店舗拠点コードを外部キーとして持つ形になります。設問1のスキーマは、現状業務が「工場から店舗へ直接配送」になっている前提で成立しているため、配送ルートの配送元が生産工場であることや、配送が店舗拠点コードを持つことが自然に整合します。読解の観点では、どの属性が「識別子」なのか、どの属性が「参照（外部キー）」なのか、そして業務文章が示す「所属」「順序」「紐付け」をどの表に持たせるべきかを、図1の概念モデルと図2の関係モデルを往復しながら確認するのが失点回避の基本になります。 設問2は、新たにデザート・ケーキ類という委託商品が追加され、委託工場と物流センタが導入される業務変更に対応するために、概念データモデルと関係スキーマを拡張する問題です。ここでの本質は、変更点が単なるエンティティ追加ではなく、役割の分離と物流拠点の追加に伴って、既存概念の上位化・下位化や、物流経路の分割が必要になる点にあります。概念モデルでは、従来「生産工場」として一括りだった工場概念を、工場という上位概念の下に自社工場と委託工場のサブタイプとして分割する必要があります。したがって、工場のサブタイプとしてウが委託工場、エが自社工場となります。同様にルートも、従来は工場から店舗へ直接配送する配送ルート中心の考え方でしたが、物流センタ導入により工場から物流センタへの輸送と、物流センタから店舗への輸送を区別しなければ業務を表現できません。工場から物流センタへの輸送が納入であり、その経路を表すのが納入ルート、物流センタから店舗への経路が配送ルートになるため、オが納入ルート、カが配送ルートになります。採点講評が指摘する「納入と配送の違いを読み取れていない」失点はここに直結し、物流センタが介在することにより、同じ“運ぶ”でも業務目的と管理対象が変わる点を文章から拾えるかが読解ポイントになります。 図4の関係スキーマでは、工場、物流センタ、ルート、および納入を関係として落とし込む必要があり、サブタイプ表の主キー継承と参照整合性の理解が重要です。委託工場は拠点コードを継承し、委託開始年月日を持つため、iは拠点コード（主キーであり拠点への外部キー）と委託開始年月日になります。納入ルートは「納入元の工場」と「納入先の物流センタ」の組で特徴付くため、ルート番号という識別子に加えて、工場拠点コードと物流センタ拠点コードの外部キーが必要になり、これがjに該当します。配送ルートは配送元が生産工場から物流センタへ変更されるため、配送ルート表には物流センタ拠点コードが外部キーとして入ることになり、これがkに該当します。午後Ⅰでの失点要因としては、既存の発想のまま配送ルートの配送元を工場にしてしまう、納入ルートに物流センタ参照を入れ忘れる、あるいはサブタイプの主キー継承の表記ルールを崩すといった整合性崩れが典型です。 設問2(3)のカーディナリティは、業務ルールの違いが概念モデルの多重度にそのまま反映される典型問題です。工場と納入ルートの関係が1対多であること自体は、工場が複数の物流センタに納入し得るという意味で自然ですが、多側の値が工場タイプによって変わるという点が重要です。自社工場の場合は、自社工場内の物流センタへの納入ルートを一つ持つというルールにより、多側のカーディナリティが1になります。一方で委託工場の場合は、A社側の複数物流センタに納入するという業務要件があり、与件では3か所の物流センタに対応するため、多側のカーディナリティが3になります。採点講評が示す通り、この箇所は「工場」という上位概念で一括りにしたまま考えると誤りやすく、サブタイプごとの業務ルール差分が、同一リレーションシップの多重度条件に影響するという読み取りができているかが合否を分けます。 本問の学習上の要点は、概念モデルと関係スキーマを、業務記述という一つの根拠に基づいて整合させることです。設問1では、発注とその明細という取引構造を正しく抽出し、明細と商品との関係を漏らさないことが重要になります。設問2では、物流センタ導入によって輸送が納入と配送に分割され、工場とルートが上位化・下位化するというモデル変形を、用語の似ている部分に引きずられずに正確に読み取ることが難所になります。これらを踏まえて演習することで、午後Ⅰで頻出の「業務変更に耐えるデータモデルの拡張」を、場当たり的な穴埋めではなく、根拠ある設計として再現できるようになります。
