データベーススペシャリスト試験 2013年 午後1 問02

模範解答のキーワードと論点整理

1. スーパークラス／サブクラス構造（垂直分割）
   • “サービス”を共通属性を持つ「サービス共通」と，各種固有属性を持つ「個別サービス」「セットサービス」「オプションサービス」に分割する。
2. 主キーの共有と外部キー参照
   • 各サブクラスは共通キー「サービスコード」を主キーとして持ち，親である「サービス共通」のサービスコードを外部キー参照する。
3. 固有属性の切り出し
   • 各サービス種別にだけ必要な列をサブクラス側に定義し，冗長性を排除する。

テーブル構造

サービス共通

個別サービス

セットサービス

オプションサービス

解答に至る論理的説明

1. 「サービスには,個別サービス, セットサービス及びオプションサービスの3種類があり,サービス区分でどの種類のサービスかが識別される。」（問題文）
   → ３種類のサービスを１つのテーブルに詰め込むと，列の空白や冗長が発生する。そこで共通属性と固有属性を分ける。
2. 各種サービスの固有属性は次の通りです。
   • 個別サービス：「サービス内容, 標準作業時間数」が決まっている（問題文）
   • セットサービス：「個別サービス選択可能数」が決まっている（問題文）
   • オプションサービス：「サービス内容, 標準作業時間数, 適用個別サービス」が決まっている（問題文より「オプションサービスのサービス内容, 適用可能な個別サービス, 標準価格, 標準作業時間数は決まっている」）
3. 「列が冗長にならないように,各テーブルの構造を記述せよ。」との指示より，
   • 重複する「サービス名」「標準価格」は「サービス共通」に集約
   • 各種サービスにしかない列はサブテーブルへ
4. 主キー・外部キー
   • サブクラスはスーパークラスの主キーを兼ね，FK参照を張ることで整合性を担保します。

受験者が誤りやすいポイント

• 「オプションサービス」と「個別サービス」は列名が似ているため，両者をマージしがちですが，オプションは“適用可能な個別サービス”を持つ点で個別サービスとは異なる役割です。
• セットサービスの「選択可能な個別サービス群」は多対多の関係になるため，実際には別に中間テーブルが必要ですが，小問では「個別サービス選択可能数」のみ問われています。
• 主キーと外部キーの定義忘れ。

試験対策として覚えておくべきポイント

1. スーパークラス／サブクラス分割（垂直分割）の考え方
   • 共通属性は親テーブルへ，固有属性は子テーブルへ
2. 主キー共有型の参照方式
   • 子テーブルの主キーに親テーブルの主キーを兼用させ，FK制約を張る
3. 問題文中のキーワードを正確に拾う
   • 「サービス区分」「固有の属性」「冗長にならないように」など
4. ER設計とテーブル設計の橋渡し
   • 多対多や集合として示された属性は，設問の範囲に応じてどう表現するか切り分ける

キーワードと論点の整理

• 候補キー（Candidate Key）：関係において各行を一意に識別できる最小の属性（列）の組合せ
• 問題文の記述から把握すべきポイント
  • 「会員は,期間,回数及び曜日を選択する。」
  • 「期間,回数,曜日の組合せは,継続パターンコードで識別される。」

解答の根拠と論理的説明

1. 主キーとして「継続パターンコード」が想定されている
   問題文の「期間,回数,曜日の組合せは,継続パターンコードで識別される。」から，
   継続パターンを一意に識別するためにまず用意されるのが「継続パターンコード」であることが分かります。
2. 候補キーの要件
   • 一意性を満たす
   • 最小性（不要な属性を含まない）を満たす
3. 属性 {期間, 回数, 曜日} の組合せも一意性を持つ
   問題文に「会員は,期間,回数及び曜日を選択する。…期間,回数,曜日の組合せは,継続パターンコードで識別される。」とあるので，
   同じ「期間」「回数」「曜日」の組合せが重複して登録されることはなく，結果としてこれら３つの列が重複なく各行を識別できます。
4. ほかの列を含める必要がない（最小性）
   • 「継続割引率」は同一パターンごとに決まる既定の値であり，識別に必要な属性ではありません。
   • 「継続パターンコード」はこれ自体が主キーですが，属性の最小集合としてはコード単独または{期間, 回数, 曜日}のいずれかです。

1. 継続パターンコード
2. {期間, 回数, 曜日}

継続パターン表の構造例

受験者が誤りやすいポイント

• 「継続割引率」をキーに含めてしまう
  → 割引率はパターンに依存する値だが，同じ期間・回数・曜日であれば割引率も同じため，一意性のために必要な属性ではありません。
• 候補キーの定義と主キーの混同
  → 主キーは１つだが，候補キーは「主キーとなり得るキー」の集合を指します。

試験対策としてのまとめ

• 候補キーを問われたら，まず「一意性」と「最小性」の要件を意識する。
• 問題文中の「識別される」「一意に」「識別子」といった表現を手掛かりにする。
• 属性の組合せで識別可能かを，重複登録が起こり得るか否かで判断する。
• 主キー＝候補キーではない点を押さえ，複数の候補キーの存在を見逃さない。

1. 模範解答に至るキーワード・論点整理

2. なぜその解答になるのか ― 論理的な説明

2.1 問題文から読み取れる仕様

期間, 回数, 曜日の組合せは, 継続パターンコードで識別される。また, それによって継続割引率は異なる。

2.2 第１正規形（1NF）

2.3 第２正規形（2NF）

2.4 第３正規形（3NF）

3. 受験者が誤りやすいポイント

4. 試験対策：覚えておきたいポイントまとめ

1. 【主キーが単一か複合か】をまず確認する。
   – 単一主キーなら 2NF の部分従属性は必ず「なし」。
2. 正規化のチェック手順
   ① 1NF：非原子値・繰返しグループの排除
   ② 2NF：複合キーの部分従属性排除
   ③ 3NF：非キー属性間の推移従属性排除
3. 関数従属性は “問題文(又は設計書)に書かれているものだけ” で判断する。
   – 「業務的にありそう」な従属性を自分で追加しない。
4. 定義暗記
   • 部分関数従属性：{複合キーの一部} → 非キー属性
   • 推移的関数従属性：主キー → 非キー属性A → 非キー属性B
5. 模範解答の表形式指示
   – 本問のように「あり／なし」「具体例空欄」まで答案欄が決まっているケースが多い。書式ミスで失点しないよう注意。

キーワードと論点整理

• 注文明細のサブタイプ構造
  「セットサービス注文明細」「個別サービス注文明細」「オプションサービス注文明細」の３つのサブタイプが，スーパークラスである「注文明細」から分岐している。
• 対応関係（リレーションシップ）
  １）セットサービス→個別サービス
  ２）個別サービス→オプションサービス
• カーディナリティ（多重度）
  • ゼロを含むか（○ = 0許容，●＝必須）
  • 最小／最大数（縦線＝１，三又＝多）

解答の理由と論理的説明

1. 「セットサービス」と「個別サービス」の対応関係
   【問題文】より引用

   「見積り結果は, セットサービスで選択した個別サービス …の対応関係が分かるように…」
   「② セットサービスとは,個別サービスを複数組み合わせたもので…」

   → １つのセットサービス注文明細に対して，選択された個別サービス注文明細が複数（最大はセット定義の「選択可能数」）存在し得る。
   → 一方，個別サービス注文明細は「単品で選択」される場合もあり得るため，必ずしもセットサービス注文明細に属さない（０～１）。
   したがって，
   • セットサービス注文明細 … 個別サービス注文明細 ： １対多 (1…N)
   • 個別サービス注文明細 … セットサービス注文明細 ： ０または１
2. 「個別サービス」と「オプションサービス」の対応関係
   【問題文】より引用

   「一つのオプションサービスを適用できる個別サービスは,一つだけである。 一つの個別サービスに対して,複数のオプションサービスを追加できる。」

   → 個別サービス注文明細１件に対して，オプションサービス注文明細が複数（０件以上）関連する。
   → オプションサービス注文明細は必ずどれか１つの個別サービス注文明細に紐付く。
   したがって，
   • 個別サービス注文明細 … オプションサービス注文明細 ： １対多 (1…N)
   • オプションサービス注文明細 … 個別サービス注文明細 ： 必須１

対応関係のまとめ

• 「0…N」は「○―三又」で表記
• 「1…N」は「●―三又」，「1」は「●―│」で表記

受験者が誤りやすいポイント

1. 単品選択の個別サービスを忘れる
   個別サービス注文明細は〈セットに属さない単品選択〉を含むため，「必ずセット注文明細と関連する」と誤解しないこと。
2. オプションサービスの必須・任意を取り違える
   オプションは「追加したいときのみ」なので，個別サービスに対しては０件も許容するが，オプション側から見れば必ずどこかの個別サービスに帰属することを押さえる。
3. カーディナリティ下限の値
   「多重度でゼロを含むか否か」は○／●で明確に区別するルールを守る。

試験対策としてのまとめ

• スーパークラスとサブタイプ間では「識別リレーションシップ」を用い，各サブタイプを識別するキー設計を理解する。
• 仕様文中の「一つの…に対して, 複数の…が～できる」「～だけである」は，多重度を導くキーワード。
• カーディナリティ（多重度）を「最小・最大」「ゼロ含むか」で二段階に整理し，モデリング表記（○/●, 縦線/三又）で確実に描けるように練習する。

模範解答案のキーワードと論点整理

1. セットサービス→個別サービス
2. 個別サービス→オプションサービス

• セットサービスの注文明細から展開された個別サービス明細をリンク
• 個別サービス明細に追加されたオプションサービス明細をリンク
  という階層構造を注文明細テーブル１つで管理できます。

解答の根拠と問題文の引用

1．セットサービス→個別サービスのリンク

「セットサービスで選択した個別サービスも, 単品で選択された個別サービスも, “注文明細” テーブルには同様の形式で格納する。」
とあり，
「一つの個別サービスは、複数の異なるセットサービスに組み込まれることがある。」
とも記載されています。
したがって，「どのセットサービスから展開された明細か」を識別するために，
① “選択された個別サービスの元となったセットサービスの注文明細番号”
という参照先を持つ必要があります。

2．個別サービス→オプションサービスのリンク

「オプションサービスを追加できる」
「一つのオプションサービスを適用できる個別サービスは,一つだけである。」
とあることから，オプション明細には「どの個別サービス明細に追加されたのか」を示す必要があります。
そこで，
② “追加されたオプションサービスの元となった個別サービスの注文明細番号”
という参照先が必要です。

受験者が誤りやすいポイント

• 「セットサービス」と「オプションサービス」のリンク方向を逆に考えてしまう
  → 親子関係は〈セットサービス明細〉→〈個別サービス明細〉，〈個別サービス明細〉→〈オプションサービス明細〉です。
• 列の意味を「発注元」「変更元」など曖昧に表現してしまい，どのレコードを指すのか不明になる
  → 「注文明細番号」という具体的な外部キーを明記しましょう。

試験対策として覚えておくべきポイント

• 階層的なサービス構成（セット→個別→オプション）は自己参照（自己結合）で管理できる
• 「元となった明細」を追跡するには，自テーブルの主キーを外部キーとして持つ列を追加
• 問題文中の
  • 「～の元となった～番号」
  • 「～に追加された～番号」
    などの表現をそのまま列の説明に活かすと正確性が高まる
• ER図やリレーションシップ図で親子関係を整理し，必要な外部キーを演繹する訓練を積むこと

1. 模範解答のキーワードと論点整理

• 注文明細テーブル（“注文明細”テーブル）
• 実施明細テーブル（“実施明細”テーブル）
• セットサービス注文明細の行
• 実施対象のサービス
• 「セットサービスは実施対象ではないから」

2. 解答の理由／根拠

1. 【注文明細テーブル】には，注文確定時に以下の行がすべて格納されます。
   「個別サービス」「オプションサービス」「セットサービス」それぞれについて，

   “セットサービスで選択された個別サービスも, 単品で選択された個別サービスも, “注文明細” テーブルには同様の形式で格納する。”
   （設計方針(1)）

2. 一方，【実施明細テーブル】には，実際に会員宅で清掃を行うサービスだけが反映されます。
   業務概要6（実施の流れ）によれば，

   “1回の実施には一つ又は複数のサービスが含まれ, サービスごとに実施明細番号が付与される。”
   実際に実施されるのは「個別サービス」と「オプションサービス」であり，
   セットサービスそのものは清掃対象として実行されないため，
   実施明細を作成する必要がありません。

3. したがって，
   「実施明細テーブルの行は注文明細テーブルの行に基づいて作成されるが，
   実際の清掃実行対象でないセットサービス注文明細の行だけは反映しない」
   という理解に至ります。

3. 受験者が誤りやすいポイント

• 注文明細と実施明細の対応関係
• 実施対象に含まれるサービス区分
• 問われているのは“何を反映しないか”なので，逆パターンに注意する

4. 試験対策におけるまとめ

• 注文明細テーブルには注文サービス（個別・セット・オプション）のすべてが登録される。
• 実施明細テーブルには，実際に清掃を行う「個別サービス」「オプションサービス」のみを反映。
• 「セットサービス」はあくまで価格設定・見積り用の集合体であり，実作業対象ではない。
• 設問文中の「実施対象」「実施明細」をキーワードに正誤を切り分ける練習をする。
• 設問の指示字数まで意識しつつ，キーワードは正確に暗記する。

1. キーワードと論点の整理

• 注文変更年月日：継続注文の変更履歴を「注文変更年月日ごとに保存する」という要件から生まれるキー
• バージョニング（版管理）：同じ「注文」や「注文明細」を変更前後で履歴管理する必要性
• 主キーの拡張：履歴として同一の注文番号で異なるバージョンを区別できるように主キーに列を追加
• 外部キーの整合性：履歴付きの「注文」「注文明細」と常に参照整合性を保つため、子テーブルにも変更日を持たせる

2. 解答が「注文変更年月日」となる理由の論理的説明

「当初の注文確定時点の情報を含め、変更履歴を注文変更年月日ごとに保存する」
とあるように、注文内容の履歴を残すためには、何度も同じ「注文番号」をキーにして行を追加しなければなりません。
そのため、履歴のバージョンを一意に特定する「注文変更年月日」を主キーの一部としてテーブルに加えます。

• 元の主キー：注文番号
• 追加列：注文変更年月日　→　×××（注文番号＋注文変更年月日）でバージョンごとのレコードを区別
• 主キーに含む：○
• 外部キー：不要

• 元の主キー：注文番号＋注文明細番号
• 追加列：注文変更年月日　→　親「注文」をどのバージョンで参照したかを示す
• 主キーに含む：○
• 外部キーに含む：○

• 元の主キー：実施番号
• 追加列：注文変更年月日　→　どのバージョンの注文に基づく実施かを示す
• 主キーに含まない：－
• 外部キーに含む：○

• 元の主キー：実施番号＋実施明細番号
• 追加列：注文変更年月日　→　どのバージョンの注文明細に対応する実施かを示す
• 主キーに含まない：－
• 外部キーに含む：○

追加後の構造一覧

3. 受験者が誤りやすいポイント

• 「履歴管理をどう実現するか？」で、 主キーに追加する列と外部キーに追加する列を区別できていない
• 「注文変更年月日をどのテーブルに入れるか？」で、 実施・実施明細に入れないと参照整合性が取れない という点を見落とす
• 「新規テーブルを作る」と早合点しがちだが、 設問の方針は既存４テーブルへの列追加のみ

4. 試験対策として覚えておくべきポイント

• 【バージョン管理／履歴管理】は主キーを拡張して過去レコードを保持し、外部キーにも同じバージョンキーを持たせて参照整合性を保つ
• 主キーか外部キーかは、そのテーブル内で一意にレコードを識別する必要があるか（主キー）、参照先のキーと合わせる必要があるか（外部キー） で判断
• 問われた方針（「既存テーブルに列を一つ追加」「新規テーブル不可」など）をよく確認し、余計な設計変更を行わないこと