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

模範解答

解説

解答の論理構成

1. 第1正規形(1NF)の定義
   すべての属性値は「単一・不可分(atomic)」でなければなりません。
2. 本問での属性一覧
   【問題文】
   “会員（会員ID，…，オプション選択，有料メニュー選択）”
   ここに “有料メニュー選択” が存在します。
3. “有料メニュー選択” の実態
   専任スタッフが「個人トレーニングなどの有料メニュー」を複数提案・管理する業務フローのため，1人の会員が複数メニューを同時に持つケースがあると読み取れます。
   → 1属性でメニューIDの集合を保持。
4. 結論
   したがって関係“会員”は「非原子的な集合値を含む」ため1NF違反となります。
   模範解答は
   “有料メニュー選択は，複数のメニューIDの集合であり，値が単一値ではない。”

誤りやすいポイント

• 「オプション選択」も複数になるのでは？と迷って二者を併記してしまう。設問は1つの具体的理由を聞いており過剰記述は減点対象です。
• 1NFと2NF・3NFを混同し，「主キー従属」「部分関数従属」など別次元の話を書いてしまう。
• 「NULLがあると1NF違反」と覚えている受験生がいますが，1NFの必須条件はあくまで原子性です。

FAQ

模範解答

解説

解答の論理構成

1. 候補キーの確認
   • 【問題文】には“会員種別ID”“オプションID”“メニューID”が「…を一意に識別する」と記載されています。
   • よって各 ID がその関係の主キー＝候補キーになります。
2. 関数従属性の方向性
   • 候補キーから他属性へは必ず関数従属性が成り立ちます。
   • 逆方向（例：

     入会金 → 会員種別ID

     ）はスキーマ説明からは導けません。
3. 図2の凡例へのマッピング
   • 図2［例1］は

     A → B

     を示すシンプルな形式。
   • 本問では従属先が複数なので

     A → {B, C, …}

     のようにカンマで列挙します。
4. 個別に列挙

   • 会員種別ID → 入会金, 月会費, 利用可能日, 利用可能時間

   • オプションID → オプション名, 追加月額

   • メニューID → メニュー名, 標準時間, 料金, 定員

5. 以上が模範解答図とも一致します（【模範解答】画像参照）。

誤りやすいポイント

• “利用可能日, 利用可能時間”だけを別矢印にしてしまう
  → すべて

  会員種別ID

  に従属します。
• “料金, 定員”が

  メニューID

  ではなく

  メニュー名

  に従属すると誤解
  → 同名メニューでも料金が異なる可能性を排除できないため，識別子である

  メニューID

  を起点にします。
• 多値従属性と混同
  → 本問に多値従属性は無い。図2［例4］の表記を使わないよう注意。

FAQ

メニューID

メニュー（メニューID，…，定員）

メニューID

メニュー名

メニューID

メニュー名

ID → 新属性

模範解答

解説

解答の論理構成

1. 図4中央の大枠には 「スタッフID」「更新日」 が描かれ、そこから右側へ矢印が伸び 「担当可能日時」 に到達しています。これは【問題文】の表記規則（図2）より
   $\{\text{スタッフID},\text{更新日}\}\to \text{担当可能日時}$
   を意味します。
2. 同じ中央枠から上方へ伸びる矢印は 「登録日」 に接続しており、
   $\{\text{スタッフID},\text{更新日}\}\to \text{登録日}$
   が成り立ちます。
3. 右側ブロック 「担当可能日時」 から下方へ矢印が分岐し 「担当設定日」「勤務店舗」 を指しているため、
   $\{\text{スタッフID},\text{担当可能日時}\}\to \{\text{担当設定日},\text{勤務店舗}\}$
   が成立します。
4. 左側二つの情報ブロック（個人情報、取得資格／対応可能トレーニング）から中央枠へ矢印が入っているので、
   $\{\text{個人情報等}\}\to \{\text{スタッフID},\text{更新日}\}$
   も読み取れます。
5. 関係 “スタッフ” の全属性集合は
   ｛スタッフID, 姓, 名, 性別, 生年月日, 電話番号, 住所, プロフィール, 取得資格, 対応可能トレーニング, 登録日, 更新日, 担当可能日時, 担当設定日, 勤務店舗｝
   です。上記 1)〜3) により ｛スタッフID, 更新日, 担当可能日時｝ で他のすべてが一意に決まるためスーパーキーになります。
6. ただし
   • ｛スタッフID, 更新日｝ では 3) が不足
   • ｛スタッフID, 担当可能日時｝ では 2) が不足
   • ｛更新日, 担当可能日時｝ では個人情報を決定できない
   よって最小決定集合は ｛スタッフID, 更新日, 担当可能日時｝ であり、これは候補キーです。

誤りやすいポイント

• 「スタッフID は固有だから単独キー」と早合点する
• “矢印の向き”を読み違え、決定側と従属側を逆に解釈する
• 更新日と担当可能日時のどちらか一方だけで登録日や担当設定日を決められると誤認する
• 左側ブロックからの矢印を無視し、個人情報がキーに不要と判断してしまう

FAQ

模範解答

解説

解答の論理構成

1. 候補キーの同定
   • 図5では “自己記録” の決定因子として「会員ID」「記録日」が示され、そこから体重や総歩数へ矢印が伸びている。よって {会員 ID, 記録日} が候補キー。
   • “測定” も同様に「会員ID」「測定日時」から全属性へ矢印が出ているので {会員 ID, 測定日時} が候補キー。
   • “目標” では中央ブロックに「会員ID」「設定日」「経過日数」が描かれ、その3属性を起点に右下へ派生している。従って {会員 ID, 設定日, 経過日数} が候補キー。
2. 第1〜第3正規形の判定手順
   第1正規形：繰返し集合がない（図5はすべて単一値属性）→3関係とも満たす。
   第2正規形：主キーの一部 → 非キー属性 が存在しないこと。
   • “自己記録”／“測定” は該当する矢印がなく部分関数従属性なし。
   • “目標” は {会員 ID, 設定日} → {基準日, スタッフ ID} が存在し、主キーの一部から非キー属性が決定しているので未達。
   第3正規形：非キー属性間の推移的関数従属性がないこと。
   • “自己記録” と “測定” には推移的な矢印が図示されておらず、条件を満たす。
   • “目標” は第2正規形を満たしていないため第3正規形にも到達しない。
3. 部分・推移的関数従属性の有無
   • “自己記録”：部分「なし」、推移「なし」
   • “目標”：部分「あり」 {会員 ID, 設定日} → {基準日, スタッフ ID}、推移「なし」
   • “測定”：部分「なし」、推移「なし」

誤りやすいポイント

• 「{会員 ID, 設定日} → 基準日」は推移と誤認しがちだが、決定因子が主キーの一部なので部分関数従属性。
• “目標” の主キーを {会員 ID, 設定日} と短絡し、経過日数を落としてしまうミス。図5では経過日数が中央枠内に描かれており候補キーに含まれる。
• “自己記録” の「入力日」矢印を推移的依存と勘違いするケース。図示されているのは主キー側からの直接依存で推移ではない。

FAQ

模範解答

解説

解答の論理構成

1. “目標” の属性は【問題文】「会員ID, スタッフID, 基準日, 経過日数, 設定日, 体脂肪率, 筋肉量, 体重, 腹囲」。
2. 図5 から以下の関数従属が読み取れます。
   ・{会員ID, 設定日} → {基準日, スタッフID}
   ・{会員ID, 設定日, 経過日数} → {体脂肪率, 筋肉量, 体重, 腹囲}
3. 主キー候補は {会員ID, 設定日, 経過日数}。
4. {基準日, スタッフID} が主キーの「真部分」{会員ID, 設定日} に従属しているため、部分関数従属が存在し第3正規形に違反。
5. 対処として、部分従属する属性を切り離す。
   ・目標1：{会員ID, 設定日} を主キーに {基準日, スタッフID} を保持。
   ・目標2：主キーを維持し、残りの測定目標項目と経過日数を保持。
6. いずれも
   ① すべての非キー属性が候補キーに完全関数従属し、
   ② 候補キー以外の属性間に推移的従属がない
   ため第3正規形を満たします。

誤りやすいポイント

• 会員ID＋設定日を主キーと誤認し、「経過日数」を取りこぼす。
• {基準日, スタッフID} と {経過日数} を混同し、推移的従属だと誤解する。
• 分解後の主キーを下線で示さず減点される。

FAQ

模範解答

解説

解答の論理構成

1. 主キー候補を確認
   表2から「

   予約枠 ID

   」が時間帯・担当スタッフ・メニューを識別しているが，同じ枠に複数会員が入るため一意にならない。
   ➔ 実質的なキーは

   {予約枠 ID, 会員 ID}

   。
2. 関数従属性の把握
   

   予約枠 ID → {予定日時, スタッフ ID, メニューID}

   が成立。
   ところが

   会員 ID

   はこの決定要素に含まれず，部分関数従属が発生。
3. 生成される更新異常
   • 削除異常
     「

     会員 ID＝A1

     を削除すると

     スタッフ ID＝S1

     が

     メニューID＝M1

     を担当する枠

     R1

     の情報も失われる」
   • 更新異常
     「

     会員 ID＝C1

     の予定日時を修正する際，

     R3

     と

     R4

     の両行を変更しないと食い違いが発生」
   • 挿入異常
     「

     スタッフ ID＝S1

     が

     メニューID＝M1

     を担当する新枠を追加したくても，対応する

     会員 ID

     が決まらないと行を挿入できない」
4. したがって「一つの関係に複数の事実（予約枠情報と予約参加者情報）が混在している」ことが不都合の原因となる。

誤りやすいポイント

• 「

  予約枠 ID

  が主キー」と思い込み，重複行を見落とす
• 更新異常＝重複行だけと誤解し，挿入・削除異常を忘れる
• 具体例に 別 ID を混ぜる／数字を改変する と減点対象

FAQ

予定日時

2011-04-01 19:00

R2

模範解答

解説

解答の論理構成

1. 自明でない多値従属性とは
   凡例［例4］によれば，$X$ ──≫ $Y\mid Z$ は「$X$ が同じなら $Y$ と $Z$ が互いに独立に複数値を取る」ことを示します。
2. 表3 の観察
   • 「予約枠ID」が同じ “R2” には，
     「会員ID」＝“B1”，“B2” と 「スタッフID」＝“S2” の組合せが列挙されています。
   • 「予約枠ID」が同じ “R4” には，
     「会員ID」＝“C1”，“C2”，“C3” と 「スタッフID」＝“S2”，“S3” の組合せが列挙されています。
   • いずれも “会員” と “スタッフ” の全組合せが存在しており，例えば “C1–S2” と “C1–S3” の双方が登録されています。
3. キーの特定
   表3 の行を一意に識別できるのは「予約枠ID」「会員ID」「スタッフID」の組であり，そのうち多値従属性の左側に置ける候補キーは「予約枠ID」。
4. 多値従属性の成立
   「予約枠ID」＝“R4” という同一値で，
   • 「会員ID」は {“C1”，“C2”，“C3”}
   • 「スタッフID」は {“S2”，“S3”}
     が独立に出現する。ゆえに
     「予約枠ID」 ──≫ 「会員ID」｜「スタッフID」
     が成り立つ。
5. 図6 へのマッピング
   凡例の形式に従い，左側の箱 (a) に左辺の属性「予約枠ID」，右側上段 (b)・下段 (c) に右辺の二集合「会員ID」「スタッフID」を配置する。順不同なので (b)(c) の入れ替えも正解。

誤りやすいポイント

• 「会員ID」と「スタッフID」が同時に決まると誤認し，関数従属性 {予約枠ID}→{会員ID, スタッフID} と考えてしまう。全組合せが存在するためこれは誤りです。
• 「予定日時」まで含めてキーと見なす勘違い。表3 には掲載されていませんが，「予約枠ID」で一意と設計されている点に注意が必要です。
• 多値従属性と第４正規形の関係を混同し，「分割しなくても第３正規形を満たす」などと判断を止めてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 多値従属性の確認
   表2には「予約枠 ID」が “R4” で「会員 ID」が “C1”“C2”“C3” と複数示され、同じく “R4” に「スタッフ ID」が “S3” “S2” と複数示されています。これは【問題文】の
   「表2は、関係 “予約時間割” の具体例である。」
   に基づき、1 つの「予約枠 ID」から “会員 ID” と “スタッフ ID” が相互に無関係に増える構造であると読み取れます。
2. 第4正規形の判定
   第4正規形は「候補キー以外の多値従属性を禁止」する形式です。主キー候補が単独属性「予約枠 ID」のとき、
   予約枠 ID ──≫ 会員 ID
   予約枠 ID ──≫ スタッフ ID
   はどちらも候補キーを左辺に持つ自明でない多値従属性であり、4NF 違反が確定します。
3. 分解手順
   4NF では “X──≫Y” が成立するとき、関係 R(X,Y,Z) を
   R1(X,Y) と R2(X,Z)
   に分解するのが原則です。本問では
   X = 予約枠 ID
   Y = 会員 ID
   Z = スタッフ ID
   となるため、解答例の 2 つの関係に分かれます。
4. 完全性の検証
   分解後も両関係を自然結合すれば元の射影（「予約枠 ID, 会員 ID, スタッフ ID」）を復元でき、損失分解でないことが保証されます。

誤りやすいポイント

• 「予定日時」や「メニュー ID」まで含めた 3 表以上の分割を考えてしまう
  → 多値従属性は独立同士だけを扱う点に注意します。
• 主キーを複合（例: 「予約枠 ID, 会員 ID」）だと誤認し、3NF で止めてしまう
  → 表2のデータ重複が示すとおり「予約枠 ID」は一意です。
• 重複行（“R4”“C3” が 2 行ある）を見て異常と判断しがち
  → データ品質の話であり、正規化判定そのものには影響しません。

FAQ