平成29年度午後Ⅱ試験問2:概念データモデリングに関する問題

2018年4月2日(月)
玉木 学

はじめに

本連載も、いよいよ今回で最終回です。今回は、平成29年度午後Ⅱ試験問2の解き方について紹介します。今回解説する問題のテーマは概念データモデリングです。この問題は毎年類似問題が出題されるため、初めて受験する方や概念データモデリング業務を担当している方は、この問題を選択することをお薦めします。

平成29年度午後Ⅱ試験問2に挑戦!

それでは、早速平成29年度午後Ⅱ試験問2に挑戦しましょう。問題文はこちらからダウンロードしてください。また、解答用紙はこちらに用意しました。解答例はこちらをご覧ください。

設問1の解説

(1)図3 概念データモデルの作成
図3の概念データモデルと図4の関係スキーマ、および問題文から、エンティティタイプに該当する記述とリレーションシップを表す記述を見つけます。エンティティタイプやリレーションシップの見つけ方については昨年度の連載記事を参照してください。

なお、この問題は、「マスタ・在庫領域」に関連する概念データモデルの作成であり、トランザクション領域のみの関連は記載しないので注意してください。

  • 〔業務分析の結果〕1.(1)自社組織
    「E社の販売物流業務に関わる拠点には,工場,物流センタ,営業所の3種類がある」と①にある「拠点の種類は拠点種類区分で分類している」の記載から、エンティティタイプ「拠点」がスーパタイプ、「工場」「物流センタ」「営業所」がサブタイプであることがわかります。これらの4つのエンティティタイプ間のリレーションシップは以下の通りとなります。

    拠点、工場、物流センタ、営業所に関するリレーションシップ

    また、③にある「販売部と営業所を合わせて営業部門と呼び」と「営業部門が,販売部と営業所のどちらに該当するかは,営業部門区分で分類している」の記載から、エンティティタイプ「営業部門」がスーパタイプ、「販売部」「営業所」がサブタイプであることがわかります。これらの3つのエンティティタイプ間のリレーションシップは以下の通りです。

    営業部門、販売部、営業所に関するリレーションシップ

  • 〔業務分析の結果〕1.(2)得意先
    ②にある「得意先の中には,請求書の送付先を集約させるところがあり,その場合の請求書の送付先を請求得意先と呼ぶ」と「得意先が請求得意先に該当するか否かは,請求得意先フラグで識別する」の記載から、エンティティタイプ「得意先」がスーパタイプ、「請求得意先」がサブタイプであることがわかります。
    また、「請求得意先は,請求書を集約する対象の得意先をもつ」の記載から、エンティティタイプ「得意先」には、「請求得意先」の主キーである「得意先コード」を参照する外部キーを持つ関連があることがわかります。これらの2つのエンティティタイプ間のリレーションシップは以下の通りです。

    得意先、請求得意先に関するリレーションシップ

    また、③にある「地域得意先に対する営業は,その地域得意先を受け持つ営業所が担当する」の記載から、エンティティタイプ「地域得意先」と「営業所」に関連があることがわかります。そして、図4の関係スキーマ「地域得意先」には外部キー「担当営業所拠点コード」が存在することから、エンティティタイプ「地域得意先」と「営業所」間のリレーションシップは以下の通りとなります。

    営業所、地域得意先に関するリレーションシップ

    さらに、④にある「広域得意先の中には,全店又は東日本と西日本のようにまとめて発注してくるところがあり,このような得意先を発注得意先と呼ぶ」と「得意先が発注得意先に該当するか否かは,発注得意先フラグで識別する」の記載から、エンティティタイプ「広域得意先」がスーパタイプ、「発注得意先」がサブタイプであることがわかります。
    そして、「各広域得意先は,どの発注得意先から発注されるか決められている」の記載から、エンティティタイプ「広域得意先」には、「発注得意先」の主キーである「得意先コード」を参照する外部キーを持つ関連があることがわかります。これらの2つのエンティティタイプ間のリレーションシップは以下の通りです。

    広域得意先、発注得意先に関するリレーションシップ

  • 〔業務分析の結果〕2.(1)得意先への納入
    ②にある「得意先から注文を受けると」の記載から、エンティティタイプ「得意先」と「注文」に関連がありそうに見えます。ところが、図4の「注文」の関係スキーマには外部キーが含まれていません。その一方で、エンティティタイプ「注文」のサブタイプである「地域得意先注文」の関係スキーマには、エンティティタイプ「得意先」のサブタイプである「地域得意先」の主キー「地域得意先コード」を参照する外部キーを含んでいます。また、エンティティタイプ「注文」のサブタイプには「広域得意先注文」が、エンティティタイプ「得意先」のサブタイプには「広域得意先」がそれぞれ存在することから、エンティティタイプ「広域得意先注文」と「広域得意先」に関連があると推測できます。これらのエンティティタイプ間のリレーションシップは以下の通りです。

    得意先と注文に関するリレーションシップ

  • 〔業務分析の結果〕2.(4)計画生産品の業務
    ②に「商品別物流センタ別に,向こう12か月分の入庫数量を決め,月別商品別物流センタ別入庫計画を立てる」の記載があります。図3にエンティティタイプ「商品」と「月別商品別物流センタ別入庫計画」に関連があることから、エンティティタイプ「物流センタ」と「月別商品別物流センタ別入庫計画」に関連があると推測できます。これらの2つのエンティティタイプ間のリレーションシップは以下の通りです。

    物流センタと月別商品別物流センタ別入庫計画に関するリレーションシップ

  • 〔業務分析の結果〕3.(1)計画生産品の業務
    ②にある「生産では,生産年月日,生産した商品,生産数量,生産した商品の入庫先物流センタを記録する」の記載から、エンティティタイプ「生産」に「物流センタ」の主キーである「拠点コード」を参照する外部キーを持つ関連があることがわかります。これらの2つのエンティティタイプ間のリレーションシップは以下の通りです。

    物流センタと生産に関するリレーションシップ

    また、③にある「営業所は,補充が必要な場合,物流センタに対して補充要求を行う」と「補充要求では,要求年月日,要求元の拠点,要求した商品,数量を記録する」の記載から、エンティティタイプ「補充要求」と要求元の拠点となる「営業所」の間に関連があることがわかります。これらの2つのエンティティタイプ間のリレーションシップは以下の通りです。

    営業所と補充要求に関するリレーションシップ

    さらに、⑤広域得意先直納にある「納入指示では,地域得意先納入の記録の他に,納入する物流センタを記録する」の記載から、エンティティタイプ「広域得意先納入指示」と納入する「物流センタ」の間に関連があることがわかります。これらの2つのエンティティタイプ間のリレーションシップは以下の通りです。

    物流センタと広域得意先納入指示に関するリレーションシップ

以上のリレーションシップを統合すると、解答になります。

(2)図4 関係スキーマの作成

  • (a) 拠点
    〔業務分析の結果〕1.(1)①「拠点の種類は拠点種類区分で分類している。拠点は拠点コードで識別し,拠点名を保持している」の記載から、(a)は「拠点名,拠点種類区分」です。
  • (b) 営業所
    図3より、関係「営業所」には、関係「物流センタ」の主キーを参照する外部キー「物流センタ拠点コード」を保持します。また、 設問1(1)の解答より、関係「営業所」は、関係「営業部門」の主キーを参照する外部キー「営業所営業部門コード」を保持します。したがって、(b)は「営業所営業部門コード, 物流センタ拠点コード」です。
  • (c) 営業部門
    〔業務分析の結果〕1.(1)(1)③にある「営業部門が,販売部と営業所のどちらに該当するかは,営業部門区分で分類している」の記載から、(c)は「営業部門区分」です。
  • (d) 得意先
    設問1(1)の解答より、関係「得意先」は関係「請求得意先」の主キーを参照する外部キー「請求得意先コード」を保持します。また、〔業務分析の結果〕1.(2)(1)②にある「得意先が請求得意先に該当するか否かは,請求得意先フラグで識別する」の記載から、関係「得意先」は属性「請求得意先フラグ」を保持します。さらに、〔業務分析の結果〕1.(2)③にある「得意先には,地域得意先と広域得意先があり,得意先区分で分類している」の記載から、関係「得意先」は属性「得意先区分」を保持します。したがって、(d)は「得意先区分,請求得意先フラグ,請求得意先コード」です。
  • (e) 広域得意先
    図3より、関係「広域得意先」は、関係「販売部」の主キーを参照する外部キー「担当販売部営業部門コード」を保持します。設問1(1)の解答から、関係「広域得意先」は関係「発注得意先」の主キーを参照する外部キー「発注得意先コード」を保持します。したがって、(e)は「担当販売部営業部門コード発注得意先コード」です。
  • (f) 商品
    図3より、関係「商品」は関係「工場」の主キーを参照する外部キー「生産工場拠点コード」を保持します。したがって、(f)は「生産工場拠点コード」です。
  • (g) 在庫
    〔業務分析の結果〕2.(3)①にある「在庫には,基準在庫数量と補充ロットサイズを設定している」の記載から、関係「在庫」は属性「基準在庫数量」と「補充ロットサイズ」を保持します。また、〔業務分析の結果〕2.(3)#9313;にある「実在庫数量が基準在庫数量を下回った商品を対象に」の記載から、関係「在庫」は属性「実在庫数量」を保持します。さらに、〔業務分析の結果〕2.(6)②にある「在庫引当ができた要求は,その要求分が出庫されるまで引当済数量に累積する」の記載から、関係「在庫」は属性「引当済数量」を保持します。したがって、(g)は「基準在庫数量,補充ロットサイズ,実在庫数量,引当済数量」です。
  • (h) 広域得意先注文
    設問1(1)の解答より、関係「広域得意先注文」は関係「広域得意先」の主キーを参照する外部キー「広域得意先コード」を保持します。したがって、(h)は「広域得意先コード」です。
  • (i) 広域得意先納入指示
    設問1(1)の解答より、関係「広域得意先納入指示」は関係「物流センタ」の主キーを参照する外部キー「納入元物流センタ拠点コード」を保持します。したがって、(i)は「納入元物流センタ拠点コード」です。
  • (j) 補充要求
    設問1(1)の解答より、関係「補充要求」は関係「営業所」の主キーを参照する外部キー「要求元営業所拠点コード」を保持します。したがって、(j)は「要求元営業所拠点コード」です。
  • (k) 生産
    設問1(1)の解答より、関係「生産」は関係「物流センタ」の主キーを参照する外部キー「入庫先物流センタ拠点コード」を保持します。したがって、(k)は「入庫先物流センタ拠点コード」です。

設問2の解説

(1) 表1 補充生産品を対象に設計したエンティティタイプと属性の対応表の作成
図5の概念データモデルと問題文から解答を導きます。

  • エンティティタイプ「物流センタ補充要求」
    図5より、エンティティタイプ「物流センタ補充要求」は「補充要求」のサブタイプです。したがって、エンティティタイプ「物流センタ補充要求」は主キーかつ「補充要求」の主キーを参照する属性「補充要求番号」を保持します。また、〔業務分析の結果〕3.(2)①にある「補充要求では,要求年月日,要求元の物流センタ,要求した商品及び要求数量を記録する」の記載、および表1の補充要求と営業所補充要求の属性より、エンティティタイプ「物流センタ補充要求」は「物流センタ」の主キーを参照する属性「物流センタ拠点コード」を保持します。したがって、解答は「補充要求番号:KF、物流センタ拠点コード:AF」となります。
  • エンティティタイプ「補充要求明細」
    図5より、エンティティタイプ「補充要求明細」はスーパタイプ「補充要求」と関連があり、サブタイプ「営業所補充要求」や「物流センタ補充要求」との関連は記載されていません。したがって、エンティティタイプ「補充要求明細」は要求元の拠点の種類に依存しません。このことから、〔業務分析の結果〕3.(2)①にある「補充要求では,要求年月日,要求元の物流センタ,要求した商品及び要求数量を記録する」の記載と図4の関係「補充要求明細」の属性より、エンティティタイプ「補充要求明細」は「補充要求番号」「補充要求明細番号」を複合キーとして、また、エンティティタイプ「商品」の主キーを参照する外部キーとして「補充生産品商品コード」、さらに「補充要求数量」を保持します。したがって、解答は「補充要求番号:KF、補充要求明細番号:K、補充要求数量:A、補充生産品商品コード:AF」となります。
  • エンティティタイプ「補充出庫」
    〔業務分析の結果〕3.(2)①にある「工場は,補充要求に対して補充出庫を行う。補充出庫では,出庫年月日,実際の出庫数量を記録する」の記載と図4の関係「補充出庫」の属性より、エンティティタイプ「補充出庫」は主キーとして「補充番号」を保持します。また、主キー以外には、エンティティタイプ「補充要求」の主キーを参照する外部キー「補充要求番号」、および「補充出庫年月日」を保持します。したがって、解答は「補充要求番号:AF、補充番号:K、補充出庫年月日:A」となります。
  • エンティティタイプ「補充出庫明細」
    〔業務分析の結果〕3.(2)①にある「工場は,補充要求に対して補充出庫を行う。補充出庫では,出庫年月日,実際の出庫数量を記録する」の記載と図4の関係「補充出庫明細」の属性より、エンティティタイプ「補充出庫明細」は主キーとして「補充番号」「補充明細番号」の複合キーを保持します。また、主キー以外には、エンティティタイプ「補充要求明細」の主キーを参照する外部キー「補充要求番号」と「補充要求明細番号」、および「補充出庫数量」を保持します。したがって、解答は「補充要求番号:AF、補充要求明細番号:AF、補充番号:KF、補充明細番号:K、補充出庫数量:A」となります。
  • エンティティタイプ「補充入庫」
    入庫は出庫に対して実施することから、〔業務分析の結果〕3.(2)①にある「補充入庫では,入庫年月日,実際の入庫数量を記録する」の記載と図4の関係「補充入庫」の属性より、エンティティタイプ「補充入庫」は主キーとして「補充出庫」の主キーを参照する外部キー「補充番号」を保持します。また、主キー以外には、「補充入庫年月日」を保持します。したがって、解答は「補充番号:KF、補充入庫年月日:A」となります。
  • エンティティタイプ「補充入庫明細」
    〔業務分析の結果〕3.(2)①にある「補充入庫では,入庫年月日,実際の入庫数量を記録する」の記載と図4の関係「補充入庫」の属性より、エンティティタイプ「補充入庫明細」は主キーとして、「補充出庫明細」の主キーを参照する外部キー「補充番号」「補充明細番号」を保持します。また、主キー以外には「補充入庫数量」を保持します。したがって、解答は「補充番号:KF、補充明細番号:KF、補充入庫数量:A」となります。

(2)図5 補充生産品を対象に設計したトランザクション領域の概念データモデルの作成

  • 〔業務分析の結果〕2.(1)得意先への納入
    ①にある「注文を受けると,在庫を確認し,納入指示を行う」の記載と図4から、エンティティタイプ「注文」と「納入指示」に関連があることがわかります。また、②にある「注文に対して在庫が不足すると,得意先と調整して分納する。分納は,納入可能な一部数量の納入指示を行う。不足分は,在庫が補充され次第,納入指示を行う。ただし,同一の得意先からの別の注文に対してまとめて納入指示を行うことはない」の記載から、エンティティタイプ「注文」と「納入指示」のカーディナリティは1対多であることがわかります。同様に、エンティティタイプ「注文明細」と「納入指示明細」のカーディナリティも1対多となります。これらのエンティティタイプ間のリレーションシップは以下の通りです。

    注文と納入指示関連のリレーションシップ

  • 〔業務分析の結果〕2.(3)在庫補充
    ③にある「補充要求に対して,要求を受けた上位拠点で在庫が不足していた場合,不足した商品を当日の補充対象から外す。翌日以降に,在庫が補充要求を満たした時点で補充を行う」の記載から、1回の補充要求に対して、補充出庫が複数回実施される可能性があることがわかります。また、1つの補充要求明細に対応する補充出庫明細は1つだけであることもわかります。一方、「同一下位拠点からの,別の補充要求をまとめて補充することはない」の記載から、1回の補充出庫に対応する補充要求は1つだけであることがわかります。したがって、エンティティタイプ「補充要求」と「補充出庫」のカーディナリティは1対多、「補充要求明細」と「補充出庫明細」のカーディナリティは1対1、「補充出庫」と「補充出庫明細」のカーディナリティは1対多となります。この内容は表1とも合致します。これらのエンティティタイプ間のリレーションシップは以下の通りです。

    補充要求と補充出庫関連のリレーションシップ

  • 〔業務分析の結果〕3.(2)物流センタ補充
    設問2(1)の内容より、エンティティタイプ「補充出庫」と「補充入庫」のカーディナリティは1対1、「補充出庫明細」と「補充入庫明細」のカーディナリティも1対1、「補充入庫」と「補充入庫明細」のカーディナリティは1対多となります。これらのエンティティタイプ間のリレーションシップは以下の通りです。

    補充出庫と補充入庫関連のリレーションシップ

設問3の解説

(1) 表2 補充要求,補充要求明細の統合前・統合後のエンティティタイプの対応

  • 計画生産品
    〔業務分析の結果〕2.(4)計画生産品の生産・物流の⑤にある「在庫補充の方式は,営業所だけに適用する」の記載と図4、表1、設問1(2)の解答から、統合前の関係「補充要求」に含まれる属性のうち「補充要求番号」「補充要求年月日」は統合後のスーパタイプ「補充要求」に、「補充要求番号」「営業所拠点コード」は統合後のサブタイプ「営業所補充要求」に保持します。したがって、統合前のエンティティタイプ「補充要求」に対応する統合後のエンティティタイプは「補充要求」「営業所補充要求」です。
    また、〔業務分析〕1.(3)の④にある「商品には,計画生産品と補充生産品の2種類がある」の記載から、統合前の関係「補充要求明細」に含まれる属性のうち「補充要求番号」「補充要求明細番号」「補充要求数量」は統合後のスーパタイプ「補充要求明細」に、「補充要求番号」「補充要求明細番号」「商品コード」は統合後のサブタイプ「計画生産品補充要求明細」に保持します。したがって、統合前のエンティティタイプ「補充要求明細」に対応する統合後のエンティティタイプは「補充要求明細」「計画生産品補充要求明細」です。
  • 補充生産品
    表1と設問2(1)の解答、および〔業務分析〕1.(3)の④にある「商品には,計画生産品と補充生産品の2種類がある」の記載から、統合前の関係「補充要求」に含まれる属性「補充要求番号」「補充要求年月日」は統合後のスーパタイプ「補充要求」に、統合前の関係「営業所補充要求」に含まれる属性「補充要求番号」「営業所拠点コード」は統合後のサブタイプ「営業所補充要求」に、統合前の関係「物流センタ補充要求」に含まれる属性「補充要求番号」「物流センタ拠点コード」は統合後のサブタイプ「物流センタ補充要求」に保持します。
    また、統合前の関係「補充要求明細」に含まれる属性のうち「補充要求番号」「補充要求明細番号」「補充要求数量」は統合後のスーパタイプ「補充要求明細」に、「補充要求番号」「補充要求明細番号」「商品コード」は統合後のサブタイプ「補充生産品補充要求明細」に保持します。したがって、統合前のエンティティタイプ「補充要求明細」に対応する統合後のエンティティタイプは「補充要求明細」「補充生産品補充要求明細」です。

(2)図8の関係スキーマの作成

  • (ア)
    表1のエンティティタイプ「生産要求」に含まれる属性から、(ア)は「生産要求年月日,生産要求時刻,生産要求数量,補充生産品商品コード」とします。
  • (イ)(ウ)(エ)
    図4の関係「生産」に含まれる属性と設問1(2)の解答、および表1のエンティティタイプ「生産」に含まれる属性より、計画生産品と補充生産品で共通の属性である「生産番号」「生産年月日」「生産数量」をスーパタイプの「生産」に、主キーの「生産番号」と補充生産品にだけ含まれる属性「生産完了時刻」をサブタイプ「補充生産品生産」に、主キーの「生産番号」と計画生産品にだけ含まれる属性「商品コード」「入庫先物流センタ拠点コード」をサブタイプ「計画生産品」にそれぞれ保持します。
    したがって、(イ)は「生産年月日,生産数量」、(ウ)は「生産完了時刻」、(エ)は「商品コード,入庫先物流センタ拠点コード」とします。
  • (オ)(カ)
    図4の関係「生産入庫」に含まれる属性と表1のエンティティタイプ「生産入庫」に含まれる属性より、計画生産品と補充生産品で共通の属性である「生産番号」「生産入庫年月日」「生産入庫数量」をスーパタイプの「生産入庫」に、主キーの「生産番号」と補充生産品にだけ含まれる属性「入庫完了時刻」をサブタイプ「補充生産品生産」にそれぞれ保持します。
    したがって、(オ)は「生産入庫年月日,生産入庫数量」、(カ)は「入庫完了時刻」とします。

おわりに

今回は、平成29年度午後Ⅱ試験問2の解き方を紹介しました。過去問題が解けた方は自信を持って試験に取り組んでください。解けなかった方は、足りない知識や技術を身につけ、試験に臨んでください。

問題文に記載されている内容は、データモデリングやデータベース設計、実装、運用、保守のための要件や仕様が記載されており、実務でも活用できる内容となっています。また、データベース製品に依存しない、普遍的な知識やスキルを担保できます。筆者も本試験に合格してから20年近く経ちますが、今でも実務で活用しています。この記事をお役立ていただければ幸いです。

NECマネジメントパートナー株式会社 人材開発サービス事業部
1993年日本電気株式会社入社。教育部門に所属し、データベース領域の教育(特にOracleデータベース)を担当。現在は情報システムの開発技術教育を担当し、要件定義や設計担当者を育成している。受講者が主体的に考え、楽しく学べる研修の提供により、高い評価をいただいている。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています