データベーススペシャリスト 2018年 午後1 問01

解答の導き方

• 根拠：「組織には、コピー機を販売する営業所と、 コピー機の設置と保守を行うサービスセンタ(以下、 SCという)があり、 組織区分で分類する。」
• 解説：組織を「営業所／サービスセンタ」で区分するので、組織エンティティに分類を示す属性が必要であり、(a) は 組織区分 となります。

• 根拠：「地域ごとに、 担当SCを決めている。」
• 解説：地域が担当するSCを保持するため、地域にSCを参照する属性が必要です。図2のサービスセンタ側の識別子がSC組織コード であるため、(b) はSC組織コード（外部キー）になります。

• 根拠：「営業担当者は、いずれか一つの営業所に所属する。」／「営業担当者は、X社の社員であり、 社員番号で識別する。」
• 解説：営業担当者が所属する営業所を参照する属性が必要です。営業所の識別子は 営業所組織コード なので、(c) は 営業所組織コード（外部キー）です。

• 根拠：「顧客ごとに、担当営業所を決めている。」
• 解説：顧客が担当する営業所を記録するため、顧客テーブルにも営業所を参照する属性が必要です。営業所を一意に識別するのは 営業所組織コード なので、(d) は 営業所組織コード（外部キー）とします。注意点は、親の組織を示す組織コード（組織コード）と混同せず、営業所を参照するときは営業所側の主キー名である 営業所組織コード を使うことです（図2の表記に合わせる）。

• 根拠：「設置事業所 ... は、顧客コードと設置事業所コードで識別し、名称、住所、 その住所を基にした地域コードを登録する。」
• 解説：設置事業所は 「顧客コード + 設置事業所コード」 の複合主キーで識別されます。図2の (e) はそのうちの顧客側のキーなので、(e) は 顧客コード（主キー）です。※設置事業所側のもう一方の主キーである 設置事業所コード も主キーに下線（実線）を付けるべきである点に留意してください。

• 根拠：「その住所を基にした地域コードを登録する。」（設置事業所の説明）
• 解説：設置事業所が所属する地域を示す属性として 地域コード を登録するため、(f) は 地域コード（外部キー）です。

• 根拠：「見積りは、見積番号で識別し、 ... 顧客コード、 担当営業所の組織コード、営業担当者の社員番号、 見積年月日、 ... を登録する。」
• 解説：見積テーブルに必要な参照項目は「顧客」「担当営業所」「営業担当者」です。図2の (g),(h),(i) は順不同と明示されているため、代表的な対応として (g)=社員番号、(h)=営業所組織コード、(i)=顧客コード を割り当てます。いずれも他表の主キーを参照する外部キーです。

• 根拠：「受注は、受注番号で識別し、 該当する見積番号、 受注年月日を登録する。」
• 解説：受注がどの見積に基づくかを示すために 見積番号 を保持します。よって (j) は 見積番号（外部キー）です。

• 根拠：設置事業所が「顧客コードと設置事業所コードで識別」されること、および「受注明細は... 設置事業所」を登録すること（受注明細の属性一覧に設置事業所コードがある）。
• 解説：受注明細が設置事業所を参照するには設置事業所の複合主キー (顧客コード, 設置事業所コード) が必要です。図2の 受注明細 属性一覧には設置事業所コードがあるため、もう一方のキーである 顧客コード を (k) として設け、設置事業所を正しく参照できるようにします。したがって (k) は 顧客コード（外部キー）です。

• a：組織区分
• b：SC組織コード
• c：営業所組織コード
• d：営業所組織コード
• e：顧客コード （設置事業所の主キーは 顧客コード と 設置事業所コード の複合）
• f：地域コード
• g：社員番号
• h：営業所組織コード
• i：顧客コード
• j：見積番号
• k：顧客コード

誤りやすいポイント

• 営業所参照の属性名を混同する：親エンティティの組織コード（組織コード）と、営業所サブタイプの主キー（営業所組織コード）を混同しやすい。営業所を参照する箇所は 図2表記に合わせて 営業所組織コード を使うこと。
• 設置事業所の主キーを忘れる：設置事業所は「顧客コード＋設置事業所コード」で識別されるので、受注明細などで設置事業所を参照する際は両方必要（設置事業所コードだけでは不十分）。
• 見積の (g),(h),(i) は順不同：図2注記にある通り順序に意味はないので、属性の意味（顧客・営業所・社員）で判断する。
• 「組織区分」と「組織コード」を取り違える：分類を表す組織区分（属性）と、組織を一意に識別する組織コード（主キー）は別物。用途を明確にする。

FAQ

解答の導き方

1. 組織と営業所・サービスセンタ（サブタイプ関係）

• 根拠：「組織には、コピー機を販売する営業所と、 コピー機の設置と保守を行うサービスセンタ(以下、 SCという)があり、 組織区分で分類する。」
• 考え方：組織は親で、営業所とサービスセンタはサブタイプです。図2に「営業所」「サービスセンタ」の個別表があることも一致します。
• 図に引く線：組織 → 営業所、組織 → サービスセンタ（specialization／包含関係として描く）。

1. 営業所・営業担当者と見積の関係

• 根拠：「営業担当者は、いずれか一つの営業所に所属する。」および「顧客から見積依頼があると、 担当営業所の営業担当者が見積りを行う。」さらに見積の説明に「担当営業所の組織コード、営業担当者の社員番号」を登録するとある。
• 考え方：営業担当者は営業所に属する（所属＝外部キーを持つ）。見積は「担当営業所」と「営業担当者」を参照して登録される。
• 図に引く線：営業所 → 営業担当者（所属）、営業担当者 → 見積（作成者）、営業所 → 見積（担当組織を記録）。

• 図2の「営業担当者」に (c) があり、これは所属する営業所の組織コードを示す（営業担当者 → 営業所の外部キー）。
• 見積の属性として顧客コードとともに担当営業所の組織コードと営業担当者の社員番号が登録されるため、見積は顧客・営業所・営業担当者を参照する。

1. 顧客・設置事業所・地域・サービスセンタの関係

• 根拠：「設置事業所 は、顧客コードと設置事業所コードで識別し、…その住所を基にした地域コードを登録する。」かつ「地域ごとに、 担当SCを決めている。」
• 考え方：設置事業所は顧客に属し（顧客コードを持つ）、設置事業所は地域コードを持つ。地域は担当SCを参照する（図2の地域に (b) がある）。
• 図に引く線：顧客 → 設置事業所、設置事業所 → 地域、地域 → サービスセンタ。
• 補足（図2との照合）：図2の「設置事業所」先頭の (e) は顧客コードに対応し、「設置事業所」に (f) がありこれは地域コードである。図2の「地域」にある (b) はSC_組織コード に相当し、地域が担当SCを参照する。

1. 見積・見積明細と受注・受注明細・受注明細内訳の連鎖

• 根拠：「見積りは、見積番号で識別し、 ... 商品コード、商品コードごとの数量、 見積単価を登録する。」（見積明細がある）および「成約に至ったときに、 見積りと同じ単位で受注登録を行う。受注は、該当する見積番号、受注年月日を登録する。」さらに受注明細・内訳の説明。
• 考え方：
  • 見積 → 見積明細（明細は見積番号を持つ）
  • 見積明細 → 商品（商品コードを参照）
  • 受注 → 見積（受注は該当見積番号を保持）
  • 受注 → 受注明細、受注明細 → 受注明細内訳（内訳は受注番号＋受注明細番号で参照される）
  • 受注明細内訳 → 商品（内訳は商品コードを持つ）。セット製品の場合はセット自体と展開した成分の両方を内訳に登録し、成分行は展開元受注明細内訳番号でセット行に紐づく。
• 図に引く線：見積 → 見積明細、見積明細 → 商品、受注 → 見積、受注 → 受注明細、受注明細 → 受注明細内訳、受注明細内訳 → 商品。さらに受注明細（の属性） → 受注明細内訳（本体製品受注明細内訳番号での参照）を表す線。

• 図2の「見積明細」は見積番号＋商品コードをもつので見積←→見積明細の線は明確です。
• 図2の「受注」(j) は該当見積番号を保持するため受注→見積の線が必要です。
• 「受注明細」には設置事業所コードがあり、受注明細 → 設置事業所 の関係（受注明細が設置箇所を持つ）も図に示します。

1. 商品とセット製品構成の関係（自己参照を含む）

• 根拠：「セット製品は、一つの本体製品と一つ以上のオプション製品を組み合わせたもので、どのオプション製品で構成されるかについて、 セット製品構成に登録する。」および「設置サービスには複数種類があり、製品ごとに、どの設置サービスを適用するかを決めている。」
• 考え方：
  • 商品（セット） ←→ セット製品構成 ←→ 商品（本体・オプション）：構成表がセットとその構成品を結ぶ。
  • 商品は設置サービスを示す商品コード（図2の設置サービス商品コード）や、セット製品であればセット製品本体を示す属性（図2のセット製品本体製品商品コード）を持つため、商品内部で自己参照がある（商品 → 商品）。
  • 受注明細内訳へは、セット製品構成の情報を基に展開して登録するので、セット製品構成 → 受注明細内訳 を表す線も必要。
• 図に引く線：商品 → セット製品構成、セット製品構成 → 商品（構成品）、商品 → 商品（設置サービス参照、セットの本体参照）、セット製品構成 → 受注明細内訳（受注時の展開のため）。

• 組織 → 営業所（サブタイプ）
• 組織 → サービスセンタ（サブタイプ）
• 組織 → 顧客（組織が顧客を持つことを示す線／図の主要データフローとして）
• 営業所 → 営業担当者（所属）
• 営業担当者 → 見積（見積作成）
• 営業所 → 見積（担当組織を記録）
• 見積 → 見積明細
• 見積明細 → 商品
• 顧客 → 見積（見積は顧客のために作成）
• 顧客 → 設置事業所
• 設置事業所 → 地域
• 地域 → サービスセンタ（地域が担当SCを参照：図2の (b) = SC_組織コード）
• 受注 → 見積（受注は該当する見積番号を保持）
• 受注 → 受注明細
• 受注明細 → 受注明細内訳
• 受注明細 → 設置事業所（受注明細に設置事業所コードがある）
• 受注明細内訳 → 商品
• 商品 → セット製品構成（セットを定義）
• セット製品構成 → 商品（構成品）
• セット製品構成 → 受注明細内訳（受注時の展開結果につなぐ）
• 商品 → 商品（設置サービス商品コード、セット製品本体製品商品コードなど自己参照）

誤りやすいポイント

• 地域とサービスセンタの参照方向を逆にする
  • 正しくは「地域ごとに、担当SCを決めている。」＝地域が担当SCを参照（図2の地域の (b) がSC_組織コード）。よって地域側にSCの参照（外部キー）が入ります。
• 顧客と営業所の関係の扱い
  • 「顧客ごとに、担当営業所を決めている。担当営業所は、組織変更によって変更する場合がある。」とあるため、履歴が必要なら見積／受注に担当営業所を登録しておく（図2の見積に担当営業所の組織コードがある）。顧客表に現在の担当を持たせることは可能だが、履歴管理は見積／受注側で行うのが確実です。
• セット製品の取り扱いをあいまいにする
  • セット製品は「セット製品自体」と「展開した単体製品」を受注明細内訳に両方登録する必要がある。展開した行は展開元受注明細内訳番号でセット行に紐づける点を忘れないこと。
• 見積明細・受注明細・受注明細内訳の単位を混同する
  • 見積明細は見積の明細（商品単位）、受注明細は設置単位（本体1台orセット1セット）、受注明細内訳はその受注明細の中での商品内訳（部品・サービスの明細）と役割が異なります。要件文の単位指定を正確に図に反映してください。

FAQ

解答の論理構成

1. サブタイプの整理
   【問題文】には「製品」「設置サービス」、さらに「単体製品」「セット製品」、「本体製品」「オプション製品」が記載されています。つまり
   • 親：商品
   • 子：製品 / 設置サービス
   • 孫：単体製品 / セット製品（製品の下位）
   • ひ孫：本体製品 / オプション製品（単体製品の下位）
     の多段サブタイプ構造になります。
2. 各属性を業務記述から位置付け
   • 「商品名」「商品区分」は全サブタイプ共通。したがって最上位の「商品」。
   • 「単体製品かセット製品かは、単体セット製品区分で分類する。」より「単体セット製品区分」は“製品”に属する。
   • 「製品ごとに、どの設置サービスを適用するかを決めている。」から「設置サービス商品コード」も“製品”に属する。
   • 「製品には、単体製品とセット製品がある。」→単体／セットの区別は“製品”より深い。「単体製品には、製品サイズを登録する。」ので「製品サイズ」は“単体製品”。
   • 「単体製品には、本体製品(コピー機本体)とオプション製品がある。」→「製品区分」は“単体製品”。
   • 「オプション製品には、給紙オプション、排紙オプションなどがあり、オプション区分で分類する。」より「オプション区分」は“オプション製品”。
   • 「本体製品には、製品のシリーズを表すシリーズコードを登録する。」で「シリーズコード」は“本体製品”。
   • 「セット製品は...一つの本体製品と一つ以上のオプション製品を組み合わせたもので...」および「セット製品自体で決まる設置サービスを適用」から、「セット製品本体製品商品コード」は“セット製品”。
   • 「設置サービスには標準設置時間を登録する。」→「標準設置時間」は“設置サービス”。
3. 第3正規形の確認
   いずれのエンティティでも主キーはコード（例：商品コード）、今回付与した属性は全てその主キーに完全従属し、相互依存や推移的従属は生じないため第3正規形を満たします。

誤りやすいポイント

• 「製品区分」を“本体製品／オプション製品だから本体・オプション側”と誤って上下2か所に置く。実際は区分値が存在するのは“単体製品”エンティティ。
• 「設置サービス商品コード」を“設置サービス側の属性”と勘違いする。仕様にある通り“製品側がどのサービスを選ぶか”を持つ。
• 「単体セット製品区分」を“商品”に置いてしまう。値が付くのは「製品」だけで「設置サービス」は該当しないため共通属性ではない。

FAQ

解答の論理構成

1. サブタイプの抽出
   • 商品の最上位分類は、【業務の概要】5.(2) にある
     「商品には、製品と設置サービスがあり、 商品区分で分類する。」
     です。したがってスーパタイプ「商品」の直下にサブタイプ「製品」と「設置サービス」を置きます。
2. 製品の再細分化
   • 【業務の概要】5.(3) で
     「製品には、単体製品とセット製品がある。」
     と規定されているので、「製品」の下位に「単体製品」「セット製品」を配置します。
3. 単体製品の再細分化
   • 【業務の概要】5.(4) で
     「単体製品には、本体製品(コピー機本体)とオプション製品がある。」
     とあるため、「単体製品」の下に「本体製品」「オプション製品」をぶら下げます。
4. 設置サービスと製品のリレーション
   • 【業務の概要】5.(6) に
     「設置サービスには複数種類があり、製品ごとに、どの設置サービスを適用するかを決めている。」
     と明示されています。適用先は「製品」レベルなので、「設置サービス」―「製品」の間にリレーションシップ（1対多）を設定します。
   • 同じ文の後段
     「セット製品の場合、 セット製品自体で決まる設置サービスを適用し、 セット製品を構成する単体製品で決まる設置サービスは適用しない。」
     から、リレーション先はスーパタイプ「製品」ではなくサブタイプ「セット製品」がより適切とも読めますが、単体製品にも設置サービスが必要なので、「製品」と結びます。
5. セット製品と本体製品の対応
   • 【業務の概要】5.(5) で
     「セット製品は、一つの本体製品と一つ以上のオプション製品を組み合わせたもの」
     と示されています。ここでは
     ① １セット製品に対し必ず１本体製品
     ② 同じ本体製品が複数のセット製品に採用されうる
     という構造です。したがって「本体製品」―「セット製品」の１対多リレーションを設定します。
6. セット製品とオプション製品の多対多構造
   • 同じ5.(5) 後段
     「どのオプション製品で構成されるかについて、 セット製品構成に登録する。」
     から、セット製品とオプション製品は多対多関係であり、その媒介エンティティが「セット製品構成」です。よって
     ・「セット製品」―「セット製品構成」
     ・「オプション製品」―「セット製品構成」
     の２本のリレーションシップを配置します。
7. 図３の空欄へのエンティティタイプ名とリレーション
   上記1〜6を図へ反映すると、模範解答と同じ以下の完成図になります。
   商品
   　　├── 製品
   　　│　　 ├── 単体製品
   　　│　　 │　　 ├── オプション製品 ─┐
   　　│　　 │　　 └── 本体製品 ────┘│
   　　│　　 └── セット製品 ──┬────┘
   　　└── 設置サービス ─────┘
   最下部に多対多連結用の「セット製品構成」を配置し、
   「オプション製品」→「セット製品構成」←「セット製品」
   を結びます。

誤りやすいポイント

• 「設置サービス」を「製品」のサブタイプと誤認し、「商品」直下に置かない。
• 「本体製品」と「セット製品」を直接多対多で結んでしまい、1：1の要件を崩す。
• 「セット製品構成」をリレーションシップではなくエンティティとして実装し忘れる。
• 「オプション製品」と「本体製品」を横並びにし、サブタイプ階層を途切れさせる。
• サブタイプ間リレーションの向きを統一せず、主従逆転で解釈する。

FAQ

解答の論理構成

1. 出荷指示エンティティの特定
   • 問題文より「出荷指示は、出荷指示番号で識別」かつ「出荷指示年月日を登録」。
     ⇒ 属性は 出荷指示番号、出荷指示年月日 の2つで十分。
2. 出荷指示と受注明細の関係
   • 「受注明細をまとめて出荷指示を行う」＝1つの出荷指示に複数の受注明細が対応。
     ⇒ 外部キーは多側である 受注明細 に置く。
3. 追加すべきもの
   • 新関係：出荷指示（出荷指示番号、出荷指示年月日）
   • 既存関係：受注明細 に 出荷指示番号 追加（外部キー、NULL可）。

誤りやすいポイント

• 出荷指示番号を 受注明細内訳 に入れてしまう
  → 内訳は単体製品やサービスレベルで明細をさらに展開した行。まとめ単位は受注明細であるため粒度が合わない。
• 出荷指示に設置事業所コードを持たせる
  → 同じ出荷指示番号でも将来複数事業所が対象になる仕様変更があり得る。正規化観点でも冗長。
• 出荷指示年月日を受注明細側へコピー
  → マスタ側（出荷指示）で一元管理すれば良く、従側へ持たせると更新異常の原因。

FAQ

解答の論理構成

1. 受注明細内訳に登録されるレコードを整理
   • 本体製品・オプション製品などの「単体製品」
   • セット製品そのもの
   • セット製品に展開した単体製品
   • 「設置サービス」
2. 出荷指示対象の定義
   【問題文】「出荷指示は、コピー機メーカの物流センタから出荷する製品を対象とする。」
   物流センタから出荷しないものは対象外。
3. 出荷可否の判定
   • 単体製品 … 製品なので対象
   • 展開後の単体製品 … 同上で対象
   • セット製品そのもの … 物流センタから直接出荷されず、構成品を出荷するため対象外
     【問題文】「セット製品を構成する単体製品に展開し…」
   • 設置サービス … 物理的な出荷物がないため対象外
4. よって出荷指示の対象外は
   ①セット製品の場合 ②設置サービスの場合

誤りやすいポイント

• 「セット製品も製品だから対象」と早合点する
• 「オプション製品」を対象外と勘違いする（オプション製品は単体製品なので対象）
• 「受注明細」と「受注明細内訳」を混同し、内訳レベルでの判断を忘れる

FAQ