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

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

データモデルやスキーマに関する設問では、記号や見た目の形だけで判断すると誤りやすくなります。本文に書かれた業務上の決まりごとを根拠として拾い出し、それがモデル側のどこに反映されているかを一つずつ照らし合わせる姿勢が検討の土台になります。

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

この種の設問で問われやすいのは、業務の説明から読み取れる事実と、モデルやスキーマとして表現された内容とが食い違っていないかという点です。自分の知識で補わず、記述に根拠があるかを基準に判断してください。

視点

概念データモデルは業務の事実や規則を抽象化して表したもので、関係スキーマはそれを表の構造として具体化したものです。両者を行き来するときは、ある規則がどの段階で、どの要素として表現されるのかを意識します。統合や変更の場面では、元の業務記述が持っていた意味が失われたり変わったりしていないかを確かめることが基本になります。

確認ポイント

• 業務記述の中から、業務上の決まりごとを示す語句を漏れなく拾い出して整理したか
• 拾い出した決まりごとが、モデルやスキーマのどの要素に対応するのかを自分の言葉で説明できるか
• 記述に根拠のない前提を、一般的な業務知識や思い込みで補って判断していないか

解説

E社の販売物流業務を題材に、①計画生産品の概念データモデルでリレーションシップと属性を補う、②補充生産品のトランザクションを属性対応表からボトムアップに組み立てる、③二つのモデルを統合ルールに従ってスーパタイプとサブタイプにまとめる、という3段階の問題です。拠点・営業部門・得意先の多重の階層、分納や分割補充によって生じる1対多、補充生産品に固有の時刻属性が、正解を導く手がかりになります。

問題の全体像

自動車用ケミカル製品メーカのE社が販売物流システムを再構築する事例です。拠点（工場・物流センタ・営業所）、営業部門（販売部・営業所）、得意先（地域・広域、請求得意先、発注得意先）という階層があります。商品には、需要予測に基づく計画生産品と、下位拠点からの要求に基づく補充生産品の2種類があり、業務の流れが異なります。出題趣旨では、①トップダウンにエンティティタイプとリレーションシップを見抜く能力、②ボトムアップにエンティティタイプと関係スキーマを分析する能力、③類似しているが異なる業務のモデルを統合する能力を評価するとしています。設問1が①、設問2が②、設問3が③に対応します。採点講評では、全体として正答率は高かったものの、スーパタイプとサブタイプの間のリレーションシップ、外部キーの参照先、トランザクション間のリレーションシップ、統合後の属性名で誤りが散見されたと指摘しています。

設問1(1)

公式解答例で太線で追加されているリレーションシップは、次の3種類に整理できます。(A)サブタイプの関係：拠点のサブタイプとしての工場・物流センタ・営業所（拠点種類区分で分類）、営業部門のサブタイプとしての販売部・営業所（営業部門区分で分類）、得意先のサブタイプとしての請求得意先（請求得意先フラグで識別）、広域得意先のサブタイプとしての発注得意先（発注得意先フラグで識別）です。営業所は、拠点と営業部門の両方のサブタイプになります。(B)マスタ・在庫領域内の1対多：請求得意先→得意先（請求得意先は請求書を集約する対象の得意先をもつ）、発注得意先→広域得意先（各広域得意先は、どの発注得意先から発注されるか決められている）、営業所→地域得意先（地域得意先はそれを受け持つ営業所が担当する）です。(C)マスタ・在庫領域からトランザクション領域への1対多：物流センタ→月別商品別物流センタ別入庫計画、地域得意先→地域得意先注文、広域得意先→広域得意先注文、物流センタ→広域得意先納入指示、営業所→補充要求、物流センタ→生産です。これらは図4の属性と照合すると確かめられます。破線下線付きで印刷されている担当営業所拠点コード（地域得意先）と地域得意先コード（地域得意先注文）、入庫計画の主キーの一部として実線下線で示されている物流センタ拠点コードに加え、空欄c・dの区分・フラグ、dの請求得意先コード、eの発注得意先コード、bの営業所営業部門コード、h～kの外部キーがそれぞれの根拠になります。一方、図3に最初から描かれている物流センタ→営業所、販売部→広域得意先、工場→商品は、それぞれbの物流センタ拠点コード、eの担当販売部営業部門コード、fの生産工場拠点コードに対応します。これらは追加するリレーションシップではありません。採点講評では、サブタイプとスーパタイプの間に存在するリレーションシップ（請求得意先→得意先、発注得意先→広域得意先のような関係）を解答できていないものが散見されたと指摘されています。

設問1(2)(a)

公式解答例は「拠点名，拠点種類区分」です。1.(1)①の「拠点の種類は拠点種類区分で分類している。拠点は拠点コードで識別し，拠点名を保持している」に着目します。拠点種類区分は、工場・物流センタ・営業所のどのサブタイプに当たるかを示す区分です。どちらも外部キーではないため、破線の下線は付けません。

設問1(2)(b)

公式解答例は「営業所営業部門コード，物流センタ拠点コード」で、どちらも外部キーです。営業所は拠点のサブタイプとして拠点コードで識別されますが、同時に営業部門のサブタイプでもあります。そのため、営業部門と対応付ける外部キー（営業所営業部門コード）が必要です。これは設問1(1)で追加した営業部門のサブタイプ関係に対応します。また、1.(1)①に「営業所は，物流センタの配下に」あるとあり、図3にも物流センタ→営業所の1対多が最初から描かれています。この関係を表すのが外部キーの物流センタ拠点コードです。

設問1(2)(c)

公式解答例は「営業部門区分」です。1.(1)③に「営業部門が，販売部と営業所のどちらに該当するかは，営業部門区分で分類している」とあり、これはサブタイプを判別するための属性です。外部キーではありません。

設問1(2)(d)

公式解答例は「得意先区分，請求得意先フラグ，請求得意先コード」で、請求得意先コードだけが外部キーです。得意先区分は地域得意先と広域得意先を分類する区分（1.(2)③）、請求得意先フラグは請求得意先に該当するかどうかの識別（1.(2)②）です。請求書の送付先の集約は地域・広域を問わず得意先全般に関わるため、スーパタイプの得意先が、参照先の請求得意先コードを外部キーとして持ちます。これは設問1(1)で追加した請求得意先→得意先の1対多に対応します。

設問1(2)(e)

公式解答例は「発注得意先コード，担当販売部営業部門コード」で、どちらも外部キーです。まとめて発注されるのは広域得意先だけなので（1.(2)④）、発注得意先を参照する外部キーは得意先ではなく広域得意先に置きます。これは設問1(1)で追加した発注得意先→広域得意先に対応します。また「広域得意先に対する営業は，いずれかの販売部が担当する」ため、販売部の主キー（営業部門コード）を参照する担当販売部営業部門コードを持ちます。こちらは図3に最初からある販売部→広域得意先の矢印に対応します。採点講評が指摘する「参照先のエンティティタイプの特定」が問われる箇所です。

設問1(2)(f)

公式解答例は「生産工場拠点コード」で、外部キーです。1.(3)③の「商品ごとに生産する工場を決めており，生産する工場の拠点コード…を設定している」に着目します。参照先は拠点全体ではなく工場なので、それが分かる名称にします。図3に最初からある工場→商品の矢印に対応します。

設問1(2)(g)

公式解答例は「基準在庫数量，補充ロットサイズ，実在庫数量，引当済数量」です。2.(3)①の「在庫には，基準在庫数量と補充ロットサイズを設定」、2.(3)②の「実在庫数量が基準在庫数量を下回った商品」、2.(6)②の「引当済数量に累積する」から、在庫（拠点コード、商品コード）ごとに持つ値を拾い出します。いずれも外部キーではありません。

設問1(2)(h)

公式解答例は「広域得意先コード」で、外部キーです。地域得意先注文が地域得意先コードを持つのと同じ構造で、広域得意先注文は広域得意先を参照します。設問1(1)で追加した広域得意先→広域得意先注文に対応します。

設問1(2)(i)

公式解答例は「納入元物流センタ拠点コード」で、外部キーです。3.(1)⑤に、広域得意先直納の納入指示では「地域得意先納入の記録の他に，納入する物流センタを記録する」とあります。この広域得意先直納に固有の属性があるため広域得意先納入指示がサブタイプになり、物流センタ→広域得意先納入指示のリレーションシップが生じます。

設問1(2)(j)

公式解答例は「要求元営業所拠点コード」で、外部キーです。3.(1)③では補充要求で「要求元の拠点」を記録します。2.(4)⑤に計画生産品では「在庫補充の方式は，営業所だけに適用する」とあるので、要求元は営業所に限られます。したがって参照先は営業所で、営業所→補充要求に対応します。

設問1(2)(k)

公式解答例は「入庫先物流センタ拠点コード」で、外部キーです。3.(1)②の「生産では，…生産した商品の入庫先物流センタを記録する」に着目します。物流センタ→生産のリレーションシップに対応します。

設問2(1)

公式解答例では、太枠内を次のように埋めています。物流センタ補充要求：補充要求番号KF、物流センタ拠点コードAF（営業所補充要求の例に倣う）。補充要求明細：補充要求番号KF、補充要求明細番号K、補充要求数量A、補充生産品商品コードAF。補充出庫：補充要求番号AF、補充番号K、補充出庫年月日A。補充出庫明細：補充要求番号AF、補充要求明細番号AF、補充番号KF、補充明細番号K、補充出庫数量A。補充入庫：補充番号KF、補充入庫年月日A。補充入庫明細：補充番号KF、補充明細番号KF、補充入庫数量A。考え方は次のとおりです。在庫不足の商品は当日の補充対象から外されて翌日以降に補充され（2.(3)③）、別の補充要求をまとめることはないため、補充出庫は一つの補充要求を外部キーで参照し、補充出庫明細は一つの補充要求明細を参照します。補充入庫と補充入庫明細は、対応する補充出庫と補充出庫明細の主キー（補充番号、補充明細番号）をそのまま主キーとして引き継ぎます。

設問2(2)

公式解答例で追加されているのは、トランザクション間の先行後続関係です。①注文→納入指示、注文明細→納入指示明細：分納があるため1対多です（2.(1)②）。②補充要求→補充出庫：一つの要求の明細が日を分けて補充されうるため1対多です。③補充出庫→補充出庫明細、補充入庫→補充入庫明細：ヘッダと明細の1対多です。④補充出庫―補充入庫、補充出庫明細―補充入庫明細：出庫した分を入庫するので1対1です。⑤補充要求明細―補充出庫明細：不足した商品は当日の対象から外して後日まとめて補充するので、公式解答例では1対1の線で表されています。1対1のときは、後から発生する側（補充出庫明細、補充入庫側）に外部キーを置くという設問2(1)の配置と整合しています。採点講評では、トランザクション間のリレーションシップを解答できていないものが散見されたとし、連鎖する業務イベントの先行後続を注意深く読み取るよう求めています。

設問3(1)

公式解答例では、〇を次のように付けています。統合後の補充要求：計画生産品の補充要求と補充生産品の補充要求。営業所補充要求：計画生産品の補充要求と補充生産品の営業所補充要求。物流センタ補充要求：補充生産品の物流センタ補充要求。補充要求明細：計画生産品の補充要求明細と補充生産品の補充要求明細。計画生産品補充要求明細：計画生産品の補充要求明細。補充生産品補充要求明細：補充生産品の補充要求明細。計画生産品の補充要求（補充要求番号、補充要求年月日、要求元営業所拠点コード）は、共通部分が統合後の補充要求に、営業所に固有の部分が営業所補充要求に対応するため、2か所に〇が付きます。補充要求明細は、番号と数量が共通でスーパタイプに入ります。一方、参照する商品の外部キーは、計画生産品側が商品コード、補充生産品側が補充生産品商品コードで、双方に共通でない属性があります。そのため統合ルール③により、共通部分のスーパタイプと、二つのサブタイプに分けて対応付けます。

設問3(2)(ア)

公式解答例は「生産要求年月日，生産要求時刻，補充生産品商品コード，生産要求数量」で、補充生産品商品コードが外部キーです。表1の生産要求の列にある属性（K以外）をそのまま移します。生産要求は補充生産品だけにあるため、統合後は補充生産品生産要求になります。

設問3(2)(イ)

公式解答例は「生産年月日，生産数量」です。計画生産品の生産（図4）と補充生産品の生産（表1）に共通する属性なので、スーパタイプの生産に置きます（統合ルール③）。

設問3(2)(ウ)

公式解答例は「生産完了時刻」です。3.(2)②で、リードタイム計測のために補充生産品の生産でだけ記録される属性なので、サブタイプの補充生産品生産に置きます。図7では、補充生産品生産は補充生産品生産要求と1対1で結ばれ、どちらも生産番号で識別されます。補充生産品生産要求がすでに補充生産品商品コードを持つので、同じ生産番号をキーとする補充生産品生産に商品コードを重ねて持たせると、同じ事実を二重に持つ冗長な構造になります。これは正規形の違反ではなく、同じキーを持つ関係どうしの冗長性の問題です。公式解答例でも、補充生産品生産に商品コードは含まれていません。

設問3(2)(エ)

公式解答例は「商品コード，入庫先物流センタ拠点コード」で、どちらも外部キーです。図4の計画生産品の生産にあり、補充生産品の生産にはない属性です。計画生産品は、工場が生産の都度、入庫先物流センタを決めて入庫するので入庫先を持ちます。これに対して補充生産品は、工場自身が生産入庫を行います（図2）。補充生産品の生産にも固有の属性（生産完了時刻）があるので、共通でない属性が双方に存在する統合ルール③の形になり、計画生産品生産もサブタイプになります。

設問3(2)(オ)

公式解答例は「生産入庫年月日，生産入庫数量」です。計画生産品の生産入庫（図4）と補充生産品の生産入庫（表1）に共通する属性なので、スーパタイプの生産入庫に置きます。

設問3(2)(カ)

公式解答例は「入庫完了時刻」です。補充生産品の生産入庫にだけある属性です。計画生産品側には固有の属性がないので、統合ルール②により、補充生産品の側だけをサブタイプ（補充生産品生産入庫）として切り出します。図7で、生産入庫のサブタイプが一つだけ描かれているのはこのためです。採点講評では、統合後の関係スキーマの属性名を解答できていないものが散見されたが、注意深く状況を読めば分かるはずだと述べています。

学習のポイント

区分・フラグからサブタイプを見抜くこと、スーパタイプとサブタイプの間にある1対多に気付くこと、1対1と1対多を業務ルールから判定すること、統合ルールに従って属性を振り分けることが学習の重点です。