令和7年度秋期 データベーススペシャリスト 午後Ⅰ 問2 化学メーカーの営業販売管理システムの概念データモデリング

業務ルールから決定関係を読み取る

設計や正規化の判断は、問題文に書かれた業務上の決まりごとから「どの項目の値が決まれば、別の項目の値が一つに定まるか」を丁寧に拾い出すことが出発点です。思い込みではなく記述を根拠に関係を確かめましょう。

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

この分野では、エンティティ間の対応や関係スキーマの妥当性を考える際、属性同士の決定関係を業務記述に照らして一つずつ確認する姿勢が問われやすいです。一般的な商取引の常識で補わず、問題文の条件を優先してください。

視点

ある属性の組の値が定まると、他の属性の値が一意に定まる関係を関数従属と呼びます。キーの選定や正規化の判定は、この関係をどれだけ正確に把握できるかに左右されます。同じ名前の項目でも、業務上の条件によって決定関係が変わることがあります。そのため、一般論で判断せず、記述の細部を根拠に一つずつ確かめる姿勢が大切です。

確認ポイント

• 業務記述の各文から「何が決まれば何が一つに定まるか」を書き出したか
• その決定関係が常に成り立つのか、条件付きなのかを記述で確かめたか
• 書き出した決定関係と検討対象の構造や判定との整合を自分で照合したか

解説

化学メーカーの営業販売管理を題材にした問題です。関係“商談参加従業員”の候補キーと正規形を判定し、第3正規形に分解します。さらに、現状モデルに欠けているリレーションシップと属性を補い、納期調整と出荷を追加したときの概念データモデルと関係スキーマを作ります。解答の根拠は、本文にある識別子の記述、「一つの案件で扱う製品は一つ」「同一案件で同一年月日時分に商談を開始しない」といった制約、そして図3の納期調整シートの構造です。

問題の全体像

A社は営業販売管理システムを導入するにあたり、得意先、製品、案件、商談、見積り、契約、得意先納品要求を分析して、図1の概念データモデルと図2の関係スキーマを作りました。その後、営業部長から、得意先納品要求の前倒しや先送りを調整する納期調整業務と、同じ納品可能年月日時分の納品をまとめて出荷する出荷業務を加えるよう指摘を受けました。出題趣旨によれば、この問題で問われる力は三つあります。関数従属性や正規化理論を使ってデータモデルを分析する力、業務要件をデータモデルに反映する力、設計変更に合わせてデータモデルと関係スキーマを適切に変更する力です。採点講評では、設問1(2)(b)の分解、設問2(2)b、設問3(2)の納期調整の正答率が低かったと述べられています。

設問1(1)

まず、本文4(2)①「同一案件について，複数の商談を同一年月日時分に開始することはない」に着目します。ここから、商談一つは{案件コード，商談開始年月日時分}で特定できます。関係“商談参加従業員”は商談一つにつき参加した従業員一人を1行で表すので、1行を特定するには従業員コードも必要です。従業員氏名や案件担当開始年月日などは、同じ従業員が複数の商談に参加すると同じ値が繰り返し現れるため、キーにはなりません。したがって公式解答例では、候補キーは{案件コード，従業員コード，商談開始年月日時分}の一つだけとしています。

設問1(2)(a)

図2を見ると、どの属性も単一の値をとっており、繰り返し項目はありません。そのため、少なくとも第1正規形は満たしています。一方で、候補キーの一部である従業員コードだけで従業員氏名が決まります（本文1(1)）。また、案件担当開始年月日、案件担当終了年月日、担当業務内容は、案件コードと従業員コードの組で決まります（本文3(2)②）。このように候補キーの一部への部分関数従属があるので、第2正規形ではありません。公式解答例では「第1正規形」を○で囲んでいます。

設問1(2)(b)

根拠は70字以内で書くので、「全ての属性が単一値をとる」ことと、「候補キーの一部である従業員コードに従業員氏名が関数従属する」ことの二点を、具体的な属性名を挙げて書けば足ります。公式解答例も、この二点を一文にまとめています。分解後の関係スキーマは、公式解答例では次の三つです。従業員（従業員コード，従業員氏名）では、従業員コードに実線の下線があります。案件担当従業員（案件コード，従業員コード，案件担当開始年月日，案件担当終了年月日，担当業務内容）では、案件コードと従業員コードの組に実線の下線があります。商談参加従業員（案件コード，商談開始年月日時分，従業員コード）では、三つの属性すべてに実線の下線があります。関係名には、本文にある「従業員」「案件担当従業員」を使います。採点講評では、根拠の正答率は高かった一方で、第3正規形に正しく分解できていない解答が多かったと述べられています。従業員コードへの従属と、{案件コード，従業員コード}への従属の二つを、それぞれ別の関係に切り出す必要があります。

設問2(1)

本文から、図1に欠けている1対多のリレーションシップを読み取ります。一つ目は得意先から案件への1対多です（本文3(1)「得意先に対する営業活動の対象を案件と呼ぶ」）。二つ目は製品から案件への1対多です（3(1)②「一つの案件で扱う製品は一つ」、③「製品は未登録としておき」）。三つ目は案件から商談への1対多です（4(1)と4(2)①。商談は案件ごとに1回又は複数回実施され、案件コードを含むキーで識別されます）。四つ目は案件から見積りへの1対多です（5(2)「当該案件で扱う製品」、5(2)の納品条件ごとの複数見積り、5(3)の継続期間の再見積りでも同じ案件を継続する）。公式解答例では、この4本を補っています。得意先納品要求の領域にあるエンティティとのリレーションシップや、図1に表示されていない従業員などとのリレーションシップは、設問の条件により対象外です。

設問2(2)

aは、本文2(2)「製品は，公表仕様をもつ」から「公表仕様」です。製品の主キーは製品型番なので、公表仕様には下線を付けません。bは、案件が参照する得意先と製品を表す「得意先コード，製品型番」です。案件の主キーは案件コードだけなので、この二つはどちらも主キーではない外部キーとして破線の下線を付けます。製品型番は、製品が確定するまで未登録にできる属性です。採点講評でも、この二つの両方を正しく書けていない解答が多かったと述べられています。cは「案件コード，商談開始年月日時分」です。本文4(2)①から、この二つの組が商談の主キーになるので、両方に実線の下線を付けます。商談は案件に従属して識別されるため、案件コードは主キーの一部になっています。dは「案件コード，合計金額」です。案件コードは、その見積りが属する案件を参照する外部キーです。見積りの主キーは見積番号なので、案件コードには破線の下線だけを付けます。合計金額は、本文5(2)にあるとおり、各見積りで販売単価と諸経費を算出したうえで、納品期間における金額として得意先担当者に提示するものです。つまり見積り一件ごとの値なので、見積りの属性になります。図2の見積りには販売単価と諸経費はありますが、合計金額がありません。合計金額はキーではないので下線を付けません。

設問3(1)

図3の納期調整シートを見ると、要求番号004の一つの得意先納品要求に、納期調整番号01と02の二つの納期回答が対応しています。したがって、得意先納品要求から納期調整への1対多です。また、出荷番号2879は、要求番号002の納期調整01と要求番号003の納期調整01の両方に記載されています。本文〔指摘事項〕2の「同じ納品可能年月日時分の納品は，まとめて自社倉庫から出荷する」とも一致するので、一つの出荷に複数の納期調整が対応する、出荷から納期調整への1対多です。公式解答例では、この2本を補っています。

設問3(2)

公式解答例の納期調整は、納期調整（契約番号，要求番号，納期調整番号，出荷番号，納品可能年月日時分，納品可能数量，確定フラグ）です。主キーは、契約番号、要求番号、納期調整番号の三つを組み合わせたもので、三つとも実線の下線を付けます。納期調整番号は、図3で要求ごとに01、02と振られているため、単独では識別できません。そこで、得意先納品要求の主キーである{契約番号，要求番号}と組み合わせる必要があります。{契約番号，要求番号}は、納期調整が得意先納品要求に従属することも表しています。出荷番号は、出荷が完了した出荷を参照する外部キーで、主キーには含まれないため破線の下線を付けます。出荷はまだ行われていないこともあり、図3でも出荷番号が空欄の行があります。採点講評では、主キーの一つである契約番号が漏れた解答が散見されたと述べられています。図3でシートが契約番号ごとに作られている点を読み取ることが重要です。出荷は、出荷（出荷番号，出荷数量，出荷年月日時分）で、出荷番号だけに実線の下線を付けます。属性は、本文〔指摘事項〕2で記録するとされている出荷数量と出荷年月日時分です。

学習のポイント

本文の記述から関数従属性を読み取り、部分関数従属を見つけて正規化する力を養います。あわせて、弱エンティティの主キーの構成、外部キーを実線と破線の下線で正しく区別すること、帳票サンプルからエンティティ間の1対多の向きを読み取ることを重点的に学びます。