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

模範解答

解説

解答の論理構成

1. 列の性質を分類
   • 【問題文】「サービス区分でどの種類のサービスかが識別される」
   • 共通：サービスコード, サービス区分, サービス名, 標準価格
   • 個別専用：サービス内容, 標準作業時間数
   • セット専用：個別サービス選択可能数
   • オプション専用：サービス内容, 標準作業時間数, 個別サービスコード
2. 非キー属性は主キーに完全従属させる
   • 個別サービスの「標準作業時間数」は“個別サービス”.サービスコードにのみ依存。
   • オプションサービスの「個別サービスコード」は、オプションサービスにだけ意味を持つ外部キー。
3. サブタイプ実装方式を決定
   • サービスごとに行を分ける「１対１派生テーブル方式」を採用し、４表でサブタイプを表現。
   • これにより上位表（サービス共通）と下位表が $1:1$ で接続され、検索もシンプル。
4. 主キー・外部キー設定
   • 四つのテーブルすべてでサービスコードを主キー。
   • “オプションサービス”.個別サービスコード は“個別サービス”.サービスコードへの外部キー。

誤りやすいポイント

• 「サービス内容」を“サービス共通”に残すとセットサービスにも必須になり NULL が発生。
• 「標準作業時間数」を“サービス共通”に置くとセットサービスでは無意味。
• オプションサービスが参照する個別サービスを「外部キーにし忘れる」ため、整合性が取れなくなる。
• ４表に分割した後、既存のテーブル（例：注文明細）が参照すべき列を更新し忘れる。

FAQ

模範解答

解説

解答の論理構成

1. テーブル属性の整理
   “継続パターン” テーブルは【図2】に示す
   「継続パターンコード」「期間」「回数」「曜日」「継続割引率」
   の５列で構成されています。
2. 一意性を示す業務記述
   【問題文】4.(2)② に
   「期間,回数,曜日の組合せは,継続パターンコードで識別される。」
   とあるため、
   ・

   継続パターンコード

   は当然一意（候補キー①）。
   ・逆に

   期間

   ＋

   回数

   ＋

   曜日

   も１行を一意に決定（候補キー②）。
3. 他列はキーにならない
   

   継続割引率

   は割引率を示す属性であり、同じ割引率が複数行に出現し得るため一意性を担保しません。
4. よって候補キーは２つ
   ①

   継続パターンコード

   
   ②

   {期間，回数，曜日}

誤りやすいポイント

• 継続割引率

  を含めて

  {期間，回数，曜日，継続割引率}

  としてしまう。
• 「識別される」という文言を見落とし、複合キーを導けない。
• 主キーと候補キーの違いを混同し、「主キーは１つだから候補キーも１つ」と誤解する。

FAQ

継続割引率

模範解答

解説

解答の論理構成

1. 主キーの確認
   【問題文】“継続パターン” テーブルの属性は
   ― “継続パターンコード”
   ― “期間”
   ― “回数”
   ― “曜日”
   ― “継続割引率”
   と列挙され、「“継続パターンコード”に下線：主キー」と明示されています。
2. 関数従属性の列挙
   主キーが一意にレコードを決定するので
   継続パターンコード → 期間, 回数, 曜日, 継続割引率
   が唯一の関数従属性です。
3. 第1正規形の判定
   すべての列は原子値で繰返し項目も無いので第1正規形を満たします。
4. 第2正規形の判定
   主キーが単一列である以上、部分関数従属性は理論的に生じません。従って第2正規形も充足します。
5. 第3正規形の判定
   非キー属性（期間, 回数, 曜日, 継続割引率）間の依存は示されておらず、推移的関数従属性は発生しません。よって第3正規形に到達しています。
6. まとめ
   ・正規形：第3正規形
   ・部分関数従属性：なし
   ・推移的関数従属性：なし

誤りやすいポイント

• 「複合キーかどうか」を確認せずに自動的に部分関数従属性があると決めつける。
• 「期間」「回数」「曜日」の組合せが主キー候補だと勘違いし、余計な依存関係を作る。
• 非キー属性同士を “常識的に関連がありそう” という感覚で結び付け、推移的関数従属性と誤認する。

FAQ

模範解答

解説

解答の論理構成

1. セットサービス ➔ 個別サービス
   • 図 1 に「水まわり３点セット…◆浴室清掃…」の列挙があるため，セットに属する個別サービスが存在する。
   • 一方，「6｜トイレ清掃」や「7｜エアコン清掃」のようにセットに属さない個別サービスも同一注文内に登場する。
   • よって個別サービス側から見て “0 又は 1” のセットに従属，セット側から見ると設定された「選択可能数」が 1 以上なので “1 以上”。
2. 個別サービス ➔ オプションサービス
   • 【問題文】「一つの個別サービスに対して,複数のオプションサービスを追加できる。」
   • 同時に「オプションサービスは…単独では提供しない。」のでオプション側は必ず 1 つの個別サービスに従属。
   • 個別サービスにはオプションを付けなくても良い（図 1 で ◆浴室清掃にオプション無しなど）ため，個別サービス側は “0 以上”。
3. 表記
   • 指定の“ゼロを含むか否かを区別して表現する表記ルール”に合わせ，
     ・「○｜●｜→」で “0 又は 1 対 1 以上”
     ・「●｜○｜→」で “1 対 0 以上”
     を用いると模範解答の図式になります。

誤りやすいポイント

• 「個別サービスは必ずセットかオプションのどちらかに属する」と早合点し，個別サービス単品注文を忘れる。
• オプション側の必須従属（単独禁止）を見落として “0 又は 1” と書いてしまう。
• “選択可能数”をそのまま最大多重度に誤適用し，セット側を “1” 固定で描かない。
• IE 記法の記号位置を逆に書き，0/1 を左右混同する。

FAQ

模範解答

解説

解答の論理構成

1. サービス間の階層関係
   • 問題文「3. サービスの特性 (2) ② セットサービスとは,個別サービスを複数組み合わせたもの」とあるように、セットサービスは必ず個別サービスを内包します。
   • 同じく「3. サービスの特性 (2) ③ オプションサービスとは,…個別サービスに追加する清掃で,単独では提供しない」とあるため、オプションサービスは常に個別サービスに従属します。
2. 図3が要求するリレーションシップ
   • 「図3　注文明細のサブタイプ構造」では “セットサービス 注文明細” → “個別サービス 注文明細” → “オプションサービス 注文明細” の上下関係を明示しています。
   • この上下関係を物理実装するには、子側行から親側行を指すキーが必要です。
3. 追加すべき列の内容
   • セットサービス配下の個別サービスであれば「どのセットサービスに属するか」を示す値が必要。
     ⇒ ①「選択された個別サービスの元となったセットサービスの注文明細番号」。
   • 個別サービス配下のオプションサービスであれば「どの個別サービスに付随するか」を示す値が必要。
     ⇒ ②「追加されたオプションサービスの元となった個別サービスの注文明細番号」。
4. 自己参照で完結
   • “注文明細” テーブル自身に親を示す列を追加すれば、セット・個別・オプションの３層を同一テーブル内で表現できます。
   • 既存の主キー “注文番号＋注文明細番号” は変更不要で、外部キーとして同テーブルを参照するだけで済むため実装が簡潔です。

誤りやすいポイント

• 「セットサービス自体が個別サービスを示す列を持つ」と勘違いし、重複列を作ってしまう。
• オプションサービスは「セットサービスにも直接ぶら下がる」と誤解するが、問題文では必ず個別サービス経由です。
• 親子関係を表す列に “サービスコード” を入れようとしてしまい、“注文明細番号” でなければ階層が一意に特定できない点を見落とす。

FAQ

模範解答

解説

解答の論理構成

1. テーブル間の生成タイミング
   • 注文確定 → “注文明細” に行作成
   • 実施予定登録 → “実施明細” に行作成
2. 実施対象のサービス種別
   • “サービスには,個別サービス, セットサービス及びオプションサービスの３種類”
   • “セットサービスとは,個別サービスを複数組み合わせたもの”
3. 現場で行う作業
   • “１回の実施には一つ又は複数のサービスが含まれ” とあるが、
     個別に作業時間を割り当てる仕様は “個別サービス, オプションサービスごとに,予定作業時間数を割り当てる。”
   • 逆に “セットサービス” に対して作業時間は割り当てない。
4. よって “実施明細” を作る際、実際に清掃しない “セットサービス注文明細の行” は反映不要となり、理由は “セットサービスは実施対象ではないから” となる。

誤りやすいポイント

• “個別サービスを３件まとめたので作業時間を記録するだろう” と考え、セットサービスも実施対象に含めてしまう。
• 「選択した個別サービス」と「親セットサービス」の両方を二重登録して冗長なデータを生む。
• “オプションサービス” を忘れ、実施明細に含めないミス。

FAQ

模範解答

列名：注文変更年月日 テーブル：

解説

解答の論理構成

1. 追加すべき列名
   要件より引用：
   「変更履歴を注文変更年月日ごとに保存する」
   ⇒ 列名はそのまま「注文変更年月日」。
2. どのテーブルに入れるか
   変更が影響する範囲は「注文」～「実施明細」までの４表。
   【問題文】「当初の注文確定時点の情報を含め、変更履歴を…保存する」
   ① 注文：変更を起点とするため必須。
   ② 注文明細：サービス単位の見積りが変わるので必須。
   ③ 実施：次回以降の予定を登録し直すので必須。
   ④ 実施明細：作業時間・価格も版管理が要るので必須。
3. 主キーへの組み込み可否
   • 注文：元々主キーは「注文番号」。版を区別するには複合化が必要 ⇒ 主キー欄に○
   • 注文明細：主キーは「注文番号＋注文明細番号」。注文番号が変わらないので同様に複合化 ⇒ 主キー欄に○、さらに親表を参照するため外部キー欄も○
   • 実施：主キー「実施番号」は変更しない。列は実施版の参照用途のみ ⇒ 外部キー欄に○
   • 実施明細：主キーは「実施番号＋実施明細番号」。版管理は親子参照で足りる ⇒ 外部キー欄に○
4. 以上を表形式に整理

   テーブル名	主キー	外部キー
   注文	○
   注文明細	○	○
   実施		○
   実施明細		○

誤りやすいポイント

• 「実施」「実施明細」には変更列が不要と早合点し、後続実施の履歴が管理できなくなる。
• 列名を「変更年月日」などと省略し、原文「注文変更年月日」と不一致にしてしまう。
• 主キーを追加列で置き換えてしまい、既存システムとの参照整合性を壊す。

FAQ