平成30年度春期 データベーススペシャリスト 午後Ⅱ 問2

業務ルールから関連の多重度を読み取る

エンティティ間の関連を完成させる際は、業務の記述に書かれた数量の対応関係を一つずつ拾い出し、どちら側が一でどちら側が多になるのかを根拠となる記述と結び付けて確認することが基本的な検討の出発点になります。

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

受注・製造指図・発注・入荷のように業務が段階的に連なる場面では、ある段階の一件が次の段階の何件に対応するか、また分割や集約が起こり得るかを記述から読み取り、関連と参照の向きを判断する観点が問われます。

視点

概念データモデルの関連と関係スキーマの外部キーは、同じ業務ルールを二通りに表現したものです。関連の多重度は、担当者の想定や一般的な慣習ではなく、業務の記述にある『一回の〜で』『複数の〜を』『〜ごとに』といった数量の表現を根拠に決めます。多重度が定まると、どちら側の関係が相手を参照する属性を持つべきかも連動して決まるため、図と表の整合を一つの観点で点検できます。

確認ポイント

• 二つのエンティティについて、一方の一件に対して相手が何件対応し得るかを両方向から確かめたか
• その判断の根拠となる記述を業務の説明の中で具体的に指し示せるか
• 決めた多重度と、関係スキーマで参照する属性を置く側との対応に矛盾がないか

解説

製菓ラインメーカE社の受注・製造指図・発注・入荷業務を題材に、決定表、品目サブタイプの整理、概念データモデル、関係スキーマを完成させる問題です。出題趣旨では、トップダウンでエンティティタイプとリレーションシップを見抜く力、ボトムアップで関係スキーマを分析する力、サブタイプを分析する力が評価対象とされています。採点講評では、概念データモデルのうち得意先・品目・発注のサブタイプ部分と、関係スキーマのトランザクション部分の正答率が低かったと指摘されています。

問題の全体像

E社は、ユニット・すり合せ部品・ソフトウェア・設置・試運転を提供する製菓ラインのメーカです。業務は次の順に進みます。商談→受注→受注明細（5分類）→製造指図（5分類）または発注（5分類）→入荷。内製ユニットについては、品目構成に基づく所要量展開で在庫を引き当て、不足分を中間仕掛品製造指図や構成部品都度発注にまとめます。設問は4つです。(1)表1の決定表の空欄、(2)表2の品目とサブタイプの対応、(3)図1の空欄エンティティ名と欠落したリレーションシップ・発注サブタイプ、(4)図2の属性（主キーは実線、外部キーは破線の下線）と発注サブタイプの関係スキーマです。採点講評では、得意先・品目・発注のサブタイプ部分の正答率が低かったとされ、外部キーがどの主キーを参照しているかを意識するよう求めています。

設問2(1)(ア)

表1で空欄アに X が付くのは3列目と4列目です。どちらも「必要な中間仕掛品を全て引き当てできたか」が N の列です。所要量展開④には「在庫引当後、中間仕掛品が不足する場合には製造指図を行う」とあります。そのため公式解答例では、アは「中間仕掛品の製造を指図する」です。構成部品の条件（3列目は Y、4列目は N）とは関係なく X になっている点も確認しましょう。

設問2(1)(イ)

空欄イに X が付くのは2列目と4列目です。どちらも「必要な構成部品を全て引き当てできたか」が N の列です。所要量展開④には「構成部品が不足する場合には発注を行う」とあり、1(2)には構成部品は全て他社から仕入れるとあります。したがって公式解答例では、イは「構成部品を発注する」です。

設問2(2)

公式解答例の対応は次のとおりです。購買ユニット＝受注品目・発注品目。中間仕掛品＝投入品目・製造品目。構成部品＝投入品目・発注品目。専用すり合せ部品＝受注品目・製造品目。汎用すり合せ部品＝受注品目・発注品目。ソフトウェア＝受注品目・製造品目・発注品目。設置・試運転＝受注品目のみ。

根拠は次のとおりです。

・購買ユニットは他社から仕入れる。

・中間仕掛品は内製ユニットに投入され、不足すれば自社で製造する。

・構成部品は全て仕入れる。

・すり合せ部品は、専用品なら製造を指図し、汎用品なら発注する。

・ソフトウェアは、同じ品目でも要員状況によって製造と発注のどちらにもなる。

受注品目と投入品目は同時に○にならず、図2の品目にある受注投入品目区分で分ける排他関係です。一方、製造品目フラグと発注品目フラグは独立しているため、ソフトウェアのように両方に○が付くことがあります。

設問2(3)(あ)

取引先は、取引先区分によって販売相手と購買相手に排他的に分かれます。図1では仕入先と並ぶサブタイプなので、公式解答例では「得意先」です。図2の同じ行には(取引先コード、 c)とあり、c に契約先フラグ・出荷先フラグが入ることとも整合します。

設問2(3)(い)

受注の上位にあり、1件で複数の受注を生むエンティティです。5(1)②には、商談#で識別し、案件名などを記録するとあります。図2の同じ行も(商談#、 d)なので、公式解答例では「商談」です。

設問2(3)(う)

発注から1対多の矢印を受けるエンティティです。5(6)には、1件の発注が分割入荷されることはあるが、複数の発注が1件の入荷にまとめられることはないとあります。したがって公式解答例では「入荷」です。

設問2(3)(概念データモデル)

公式解答例の図で追加されている線と発注サブタイプを、全て挙げます。表記は、「A→B」がBを多側とする1対多、「A―B」が1対1です。

【マスタ系】

①部門→部門：自己参照。上位1部門に対して下位が多で、図2の上位部門コードに対応します。

②得意先→契約先、得意先→出荷先：サブタイプ関係を三角形で1本ずつ別々に描きます。一つの得意先が両方を兼ねられ、契約先フラグ・出荷先フラグで別々に識別するため、共存的サブタイプになります。

③仕入先→発注品目：発注品目ごとに仕入先が一つ決まるため1対多です（仕入取引先コード）。

④品目のサブタイプ：受注品目と投入品目を一つの三角形でまとめます（受注投入品目区分による排他）。製造品目と発注品目は、それぞれ単独の三角形で品目につなぎます（各フラグ）。

【商談・受注系】

⑤社員→商談（技術営業社員コード）

⑥契約先→商談（契約取引先コード）

⑦出荷先→受注（出荷取引先コード）

⑧受注品目→受注明細（受注品目コード）

【受注明細サブタイプの後続】

⑨ユニット受注明細―ユニット製造指図

⑩ユニット受注明細―ユニット発注

⑪すり合せ部品受注明細―すり合せ部品設計

⑫すり合せ部品設計―すり合せ部品製造指図

⑬すり合せ部品設計―すり合せ部品発注

⑭ソフトウェア受注明細―ソフトウェア製造指図

⑮ソフトウェア受注明細―ソフトウェア発注

⑯設置・試運転受注明細→設置・試運転指示（複数の指示に分かれるため1対多）

全体設計受注明細には、追加する線はありません。

【製造指図・発注】

⑰製造品目→中間仕掛品見込製造指図

⑱製造品目→中間仕掛品製造指図

⑲発注の下に、一つの三角形でユニット発注・すり合せ部品発注・ソフトウェア発注・構成部品定量発注・構成部品都度発注を追加します（発注区分による排他）。

⑳発注品目→構成部品定量発注

㉑発注品目→構成部品都度発注

【所要量展開】

㉒ユニット受注明細→所要量展開（主キーの一部である受注#・受注明細#）

㉓投入品目→所要量展開（投入品目コード）

㉔中間仕掛品製造指図→所要量展開（製造#）

㉕構成部品都度発注→所要量展開（発注#）

設計方針(6)に従い、関係は具体的に対応するサブタイプ側に引きます。例えば、所要量展開は受注明細全体ではなく内製ユニットのユニット受注明細に、中間仕掛品の製造指図は品目ではなく製造品目に結びます。

設問2(4)(a)

部門の階層は、下位部門が上位の一つの部門に所属する自己参照の1対多です。公式解答例では「上位部門コード」で、部門コードを参照する外部キーなので破線の下線を付けます。主キーではないため、実線の下線は付けません。

設問2(4)(b)

取引先を得意先と仕入先に排他的に分類する属性は、3(3)にある取引先区分です。公式解答例では「取引先区分」で、主キーでも外部キーでもないので下線は付けません。

設問2(4)(c)

得意先に固有の属性として、3(4)にある契約先フラグと出荷先フラグを置きます。二つのフラグを別々に持つので、両方を兼ねる得意先も表せます（共存的サブタイプ）。公式解答例では「契約先フラグ，出荷先フラグ」で、どちらも下線は付けません。

設問2(4)(d)

5(1)②で記録するとされる属性を並べます。公式解答例は「案件名，案件内容，商談年月日，契約取引先コード，技術営業社員コード」です。このうち契約取引先コード（契約先の取引先コードを参照）と技術営業社員コード（社員の社員コードを参照）は外部キーなので破線の下線を付けます。案件名・案件内容・商談年月日には下線を付けません。

設問2(4)(e)

5(2)⑤(i)より、全体設計受注明細に固有の属性は全体設計内容です。設計方針(4)に従ってサブタイプ側に置きます。公式解答例では「全体設計内容」で、下線はありません。

設問2(4)(f)

5(2)⑤(ii)より、ユニット受注明細に固有の属性は工程順です。公式解答例では「工程順」で、下線はありません。ユニット製造指図やユニット発注との1対1関係は、後から発生する製造指図・発注の側が外部キーを持つため、ここには外部キーを置きません。

設問2(4)(g)

5(2)⑤(iii)より、すり合せ部品受注明細に固有の属性はすり合せ箇所です。公式解答例では「すり合せ箇所」で、下線はありません。すり合せ部品設計は後から発生するので、外部キーは設計側（j）に置きます。

設問2(4)(h)

5(2)⑤(iv)より、ソフトウェア受注明細に固有の属性は詳細仕様です。同じ品目を基本仕様で共有し、詳細仕様は受注ごとに異なるためです。公式解答例では「詳細仕様」で、下線はありません。

設問2(4)(i)

5(2)⑤(v)より、設置・試運転受注明細に固有の属性は開始予定年月日と終了予定年月日です。公式解答例では「開始予定年月日，終了予定年月日」で、下線はありません。

設問2(4)(j)

すり合せ部品設計は、すり合せ部品受注明細ごとに一つ割り振られる1対1関係です。後から発生する設計側に、受注明細の主キーを外部キーとして持たせます。公式解答例は「受注#，受注明細#，専汎区分」で、受注#と受注明細#は二つで一組の複合外部キーなので、両方に破線の下線を付けます。専汎区分には下線を付けません。主キーは設計#だけです。

設問2(4)(k)

設置・試運転指示は、設置・試運転受注明細1件から複数発生する1対多関係の多側です。公式解答例は「受注#，受注明細#，指示年月日」で、受注#と受注明細#は設置・試運転受注明細を参照する複合外部キーとして両方に破線、指示年月日は下線なしです。

設問2(4)(l)

ユニット製造指図は、受注数量がそのまま製造指図数量になります。そのため数量は持たず、どのユニット受注明細に基づくかだけを記録します。公式解答例は「受注#，受注明細#」で、両方に破線の下線（複合外部キー）を付けます。

設問2(4)(m)

すり合せ部品製造指図は、5(4)②(ii)のとおり設計#を記録します。数量は受注数量と同じなので持ちません。公式解答例は「設計#」で、すり合せ部品設計を参照する外部キーなので破線の下線を付けます。受注明細は設計#をたどれば分かるため、受注#・受注明細#を重ねて持つ必要はありません。

設問2(4)(n)

ソフトウェア製造指図は、受注数量がそのまま製造指図数量になり、納品方法を記録します。公式解答例は「受注#，受注明細#，納品方法」で、受注#と受注明細#はソフトウェア受注明細への複合外部キーとして破線、納品方法は下線なしです。

設問2(4)(o)

中間仕掛品見込製造指図は、受注に結び付かず、製造部門が品目・製造指図数量・優先度を決めて記録します。公式解答例は「製造品目コード，製造指図数量，優先度」で、製造品目コードは製造品目を参照する外部キーとして破線、残り二つは下線なしです。

設問2(4)(p)

中間仕掛品製造指図は、1日分の所要量展開をまとめて品目と製造指図数量を記録します。公式解答例は「製造品目コード，製造指図数量」で、製造品目コードは破線（外部キー）、製造指図数量は下線なしです。どの所要量展開がまとめられたかは、所要量展開側の製造#で表します（r）。

設問2(4)(q)

入荷のスキーマは、括弧内の全属性が空欄になっています。5(6)①から、入荷#で識別し、入荷年月日・入荷数量・対応する発注を記録します。公式解答例は「入荷#，入荷年月日，入荷数量，発注#」です。入荷#は主キーで実線、発注#は発注を参照する外部キーで破線、入荷年月日と入荷数量は下線なしです。1件の入荷は1件の発注にだけ対応するので、多側の入荷が発注#を持ちます。

設問2(4)(r)

5(3)③より、所要量展開は受注#・受注明細#・所要量明細#の組合せで識別し、必要品目・必要数量・引当済数量を記録します。さらに5(4)②(v)で製造#を、5(5)②(v)で発注#を記録します。公式解答例は「所要量明細#，投入品目コード，必要数量，引当済数量，発注#，製造#」です。下線は次のとおりです。

・所要量明細#：複合主キーの一部として実線

・投入品目コード：投入品目を参照する外部キーとして破線

・発注#：構成部品都度発注を参照する外部キーとして破線

・製造#：中間仕掛品製造指図を参照する外部キーとして破線

・必要数量・引当済数量：下線なし

設問2(4)(発注サブタイプ)

公式解答例では、次の5つを追加します（【実】＝実線の下線、【破】＝破線の下線）。

・ユニット発注(発注#【実】、 受注#【破】、 受注明細#【破】、 直納区分)

・すり合せ部品発注(発注#【実】、 設計#【破】、 発注数量)

・ソフトウェア発注(発注#【実】、 受注#【破】、 受注明細#【破】、 瑕疵担保期間)

・構成部品定量発注(発注#【実】、 発注品目コード【破】、 発注数量、 発注時在庫数量)

・構成部品都度発注(発注#【実】、 発注品目コード【破】、 発注数量、 希望納入年月日)

発注#は、各サブタイプの主キーであると同時に、スーパタイプの発注を参照する値です。公式解答例では、主キーとして実線の下線で示されています。

ユニット発注とソフトウェア発注は、受注数量がそのまま発注数量になります。そのため発注数量は持たず、受注明細への複合外部キー（受注#＋受注明細#）で1対1に結び付けます。すり合せ部品発注は、ロットサイズを加味して数量が変わるので発注数量を持ち、設計#ですり合せ部品設計を参照します。構成部品の2つの発注は受注に結び付かないので、発注品目コードで品目を参照し、それぞれ固有の属性（発注時在庫数量／希望納入年月日）を持ちます。仕入先は発注品目からたどれるため、発注側には持ちません。

学習のポイント

サブタイプが排他か共存かを区分とフラグで見分けること、1対1関係で外部キーをどちらに置くか、外部キーが参照する主キーを確かめてリレーションシップを引く習慣を重点的に練習しましょう。