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

キーワード・論点整理

• 第1正規形（1NF）
  「リレーションの各属性が**単一値（原子値）**を保持する」という制約
• 多値属性（集合）
  1NF違反の典型例は「属性の値が集合（複数の値）になっている」こと
• 有料メニュー選択
  会員が契約した有料メニューを複数のメニューIDの集合として保持

解答の論理的説明

1. 問題文の関係スキーマ「会員」には次の属性があります。

   「会員（会員ID, …, オプション選択, 有料メニュー選択）」

2. 第1正規形の条件は

   「各タプルの各属性は単一の値（原子値）を持たなければならない」

3. 模範解答にもあるように

   「有料メニュー選択は，複数のメニューIDの集合であり，値が単一値ではない。」

   つまり属性「有料メニュー選択」は
   • {M1, M2, M3} のように集合を格納しており
   • 1つのセルに複数の値を持っているため
   • 第1正規形の「単一値であること」を満たしていない

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

• 「オプション選択」も多値属性か
  → 問題が指摘しているのは「有料メニュー選択」。
  　「オプション選択」も同様の形式なら違反だが、設問文では対象外。
• 第1正規形と第2正規形の混同
  → 2NF以降はキーへの部分従属性などを扱うため、まずは「単一値制約」を意識。
• 「集合を持つ」＝違反をすぐ連想できない
  → 設問では「集合」というキーワードに注意し、すぐに1NF違反と結びつける。

試験対策ポイント

• 第1正規形（1NF）は「原子性（Atomicity）」の確保。
  属性値が1つの値であることを常に確認する。
• 多値属性を見つけたら、別リレーションに分解することで1NFを満たす（正規化）。
• 正規形ごとの要件整理

  正規形	要件
  1NF	全属性が単一値（原子値）である
  2NF	1NF ＋ 主キーの部分従属性がない
  3NF	2NF ＋ 非キー属性間の推移的従属性がない
  BCNF	全ての関数従属性がスーパーキーによって決定される

キーワード・論点整理

• 関数従属性（functional dependency）
• 主キー → 従属属性の関係記述
• 図２の表記法：二重線枠と矢印による FD の表現
• リレーション定義（図３注釈欄）から，キーと属性群を読み取る

解答の論理的説明

会員種別（会員種別ID、入会金、月会費、利用可能日、利用可能時間）
オプション（オプションID、オプション名、追加月額）
メニュー（メニューID、メニュー名、標準時間、料金、定員）

1. 「会員種別」リレーション
   • 主キー：会員種別ID
   • 従属属性：入会金, 月会費, 利用可能日, 利用可能時間
     → 図２の「{A,B}→C」ではなく，単一属性キーなので「A→B1,B2,…」の形式で表記します。
2. 「オプション」リレーション
   • 主キー：オプションID
   • 従属属性：オプション名, 追加月額
     → 同様に オプションID → オプション名, 追加月額
3. 「メニュー」リレーション
   • 主キー：メニューID
   • 従属属性：メニュー名, 標準時間, 料金, 定員
     → メニューID → メニュー名, 標準時間, 料金, 定員

完成イメージ（テキスト版）

[二重枠] 会員種別ID  ──→ [単線枠] 入会金 | 月会費 | 利用可能日 | 利用可能時間
[二重枠] オプションID ──→ [単線枠] オプション名 | 追加月額
[二重枠] メニューID   ──→ [単線枠] メニュー名 | 標準時間 | 料金 | 定員

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

• 「利用可能日」「利用可能時間」を「メニュー」リレーションと誤って結びつける
• 図３の画面で空欄になっている上段ブロックを読み飛ばし，キー属性を正しく把握できない
• 図２の多値従属性（↔記号）と混同して，誤って上下関係を両向き矢印で表現してしまう

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

1. FD の表記法（図２）を確実にマスターする
   • 二重線枠は「属性集合」を一括して示す
   • 単線枠は「従属属性群」を示し，縦棒 “|” で複数属性を区切る
2. リレーション定義から主キーと従属属性を正確に読み取る
   • 注釈欄や関係スキーマに示された属性一覧を漏れなくチェック
3. 関数従属性 vs. 多値従属性 を区別する
   • 関数従属性は一方向の単純な→
   • 自明でない多値従属性は ↔ や “→ A|B” で表現
4. 図示演習 を繰り返す
   • 手を動かして何度も図を完成させることで，短時間で FD を見つける力が身につきます。

キーワード・論点整理

• 関数従属性
  図４から読み取れる主な関数従属性は以下の２つです。
  1. スタッフID → {姓，名，性別，生年月日，電話番号，住所，プロフィール，取得資格，対応可能トレーニング，登録日，更新日，担当可能日時}
  2. 担当可能日時 → {担当設定日，勤務店舗}
• 候補キー
  関係のすべての属性を決定し，かつ最小の属性集合である「候補キー」を求める。
• 最小性の検証
  どの属性を外すと一意性（すべてのタプルを区別できること）が失われるかを確認する。

解答の論理的説明

1. スタッフID
   • スタッフID → 登録日，更新日，担当可能日時 まで決定します。
   • しかし，「更新日」や「担当可能日時」は，あるスタッフが時系列で情報を更新したり，複数の担当可能日時を持ったりするため，スタッフIDだけではタプル（一行）を一意に識別できません。
     • 例）同じスタッフIDで異なる更新日に登録された履歴が複数ある。
     • 例）同じスタッフID・同じ更新日でも，異なる担当可能日時が複数ある。
2. スタッフID＋更新日
   • これで「時点ごとの履歴」は区別できますが，担当可能日時ごとの行が区別できません。
     • 例）2021-01-01 にスタッフ A が３つの担当可能日時を持つ場合，同一タプルにまとめられないので，行があいまいになります。
3. スタッフID＋担当可能日時
   • これで「いつどのスタッフが担当可能か」は区別できますが，それをいつの情報か（更新日）がわかりません。

• スタッフID→…でとらえられるすべての属性を含み，
• かつ最小の決定属性集合である

{スタッフID, 更新日, 担当可能日時}

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

1. スタッフID だけをキーと考える
   図を見て「スタッフID → すべての属性を決める」とだけ判断しやすいですが，実務上は更新履歴や複数担当日時の情報を別タプルで管理するため，単独では一意性を保てません。
2. 更新日を外して考える
   履歴管理がある場合は，更新日がないと「どの時点の情報か」が区別できず，重複したタプルが生じます。
3. 担当可能日時を外して考える
   一人のスタッフが複数のスケジュールを持つため，スケジュール単位で一意性が取れず，キーが不完全になります。

試験対策ポイント

• 候補キーの定義
  「関係内のすべての属性を関数従属性によって決定でき，かつ最小の属性集合」を正確におさえる。
• 多段階の関数従属性
  図示された矢印をたどり，A→B, B→C なら A→C も成り立つことを意識して，属性クローズ（X⁺）を計算できるようにする。
• 実務的な正規化
  更新履歴（時点情報）や多値属性（担当可能日時など）がある場合は，キーに時点属性や多値属性を含める必要がある点を理解する。
• 最小性の検証
  キー候補から属性を１つずつ除き，それでもすべての属性を決定できるか（まだキーか）を確認し，「取り除けない属性」が何かを見極める練習をしておく。

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

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

2.1 関係“自己記録”

2.2 関係“目標”

2.3 関係“測定”

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

4. 試験対策まとめ

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

• 第3正規形（3NF）
• 主キー（候補キー）
• 関数従属性
• 非キー属性間の推移的従属性
• 関係スキーマの分解

2. 解答に至る論理的説明

関係 “自己記録”, “目標”, “測定” のうち, 第3正規形でないものを一つ選んで関係名を示し, 第3正規形に分解した関係スキーマで示せ。

会員ID, スタッフID, 基準日, 経過日数, 設定日, 体脂肪率, 筋肉量, 体重, 腹囲

1. 主キーの決定
   「目標」では，ある会員がいつ設定した結果かを区別するために

   【会員ID, 設定日】
   

   が候補キー（主キー）になります。
2. 推移的関数従属性の検出
   図中から読み取れる主な関数従属性は，
   • {会員ID, 設定日} → スタッフID, 基準日, 体脂肪率, 筋肉量, 体重, 腹囲
   • 設定日 → 経過日数
   特に「設定日 → 経過日数」は，主キーではない非キー属性（設定日）から別の非キー属性（経過日数）を決定しており，推移的関数従属性に該当します。
   これがあるため，元の「目標」は第3正規形の要件を満たしません。
3. 第3正規形への分解
   推移的従属性を除去するために，
   • 「設定日 → 経過日数」に関わる属性群を切り出し，別関係とする
   • 残りを主キー → 非キー属性の関係のみが残るようにする
   その結果，次のように2つの関係に分解できます。

• 目標1：主キー（会員ID, 設定日）→ 基準日, スタッフID
• 目標2：主キー（会員ID, 設定日）→ 経過日数, 体脂肪率, 筋肉量, 体重, 腹囲

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

• 主キーの誤認
  「会員ID」だけ，あるいは「基準日と会員ID」の組み合わせを主キーと誤ると，従属性の判定が狂い，正しい分解ができません。
• 推移的従属性の見落とし
  「設定日 → 経過日数」のように，非キー属性同士の従属性を意識せずにスルーし，第3正規形違反に気づかないケースが多いです。
• 他の関係を選びがち
  「自己記録」や「測定」は主キー → 全非キー属性という形で，推移的従属性を持たずすでに第3正規形を満たしています。安易に誤答しないように注意してください。

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

1. 正規形の定義
   • 第1正規形：すべての属性値がアトミック
   • 第2正規形：主キーが複合キーの場合，部分従属性が存在しない
   • 第3正規形：主キーでない属性→非キー属性を決定する従属性（推移的従属性）がない
2. 関数従属性の整理手順
   1. 候補キーを確定する
   2. すべての関数従属性 X→A を列挙
   3. X がスーパーキーでなければ第2NF/第3NF違反
   4. 推移的従属性は分解して解消
3. 問題演習
   実際の試験問題では図や表でFDを示すパターンが多いので，「主キー→非キー」「非キー→非キー」に着目して正規形を判定するクセをつけましょう。

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

2. 解答になる理由

関係“予約時間割”の構造と問題点

1. 削除異常
   「会員ID＝A1の予約をすべて削除すると，スタッフID＝S1が担当するメニューID＝M1の情報もなくなる」
   → R1行しか持たない (S1, M1) の情報が消えてしまう（【模範解答】より引用）。
2. 更新異常
   「会員ID＝C1の予定日時の変更時に，複数行の予定日時をすべて変更しなければ不具合が生じる」
   → C1はR3とR4の２つの行に登場し，かつR4には同じ予定日時の行が重複しているため，すべてを更新しなければ一貫性が保てない。
3. 挿入異常
   「会員ID＝A1の予約がないと，スタッフID＝S1が担当するメニューID＝M1の情報も登録できない」
   → 関係には “スタッフID＋メニューID＋予定日時” だけを持つ行を登録できず，会員予約と結びつけざるを得ない。

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

• 関係の主キーが何かを曖昧にして「R2」「R4」の重複を見落としやすい
  → 表２では「予約枠ID」だけを主キーにすると重複行があるため，複合キーを誤認するとアノマリーの把握が難しくなる。
• 挿入異常、削除異常、更新異常の区別を曖昧にしてしまう
  → 削除で困るのは「情報が消失する」こと，更新で困るのは「複数行を漏れなく更新しなければならない」こと，挿入で困るのは「必要な情報を登録できない」こと，と整理しておくと混同しにくいです。
• アノマリーの原因が「関数従属性の不適切な組み合わせ（二重従属性）」であることを認識せず，「重複レコード問題」とだけ考えてしまう

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

• アノマリーの種類と特徴：
  1. 削除異常（Deletion Anomaly）
  2. 更新異常（Update Anomaly）
  3. 挿入異常（Insertion Anomaly）
     をそれぞれ例文で説明できるようにする。
• 正しい正規化の手順：
  1. 第1正規形（1NF）：繰り返し属性の除去
  2. 第2正規形（2NF）：部分関数従属性の除去
  3. 第3正規形（3NF）／BCNF：推移的関数従属性の除去
• 関係スキーマ設計では，「要素（会員ID, スタッフID, メニューID, 予定日時）」をどこまで１つのテーブルにまとめるかを検討し，必要に応じて中間テーブル（予約枠と会員の紐付けテーブルなど）を設ける。
• 問題文中の関数従属性図（図３～５）をきちんと読み取り，「何が主キー候補か」「どの属性がどこに従属しているか」を正確に理解した上で，アノマリー発生の原因を説明できるように演習する。

コアとなるキーワード・論点整理

• 自明でない多値従属性（non-trivial multivalued dependency）
• 図２の表記法「C → A|B」（＝C ↠ A|B）の意味
• 分割後の関係 “クラス”（表３）における属性構成：

  予約枠ID	会員ID	スタッフID
  R1	A1	S1
  R2	B1	S2
  R2	B2	S2
  …	…	…

解答が「a：予約枠ID」「b：会員ID」「c：スタッフID」になる理由

1. 問題文より：

   「表3は, 関係 “予約時間割” を分割した関係 “クラス” の具体例であり、自明でない多値従属性が含まれている。」

2. 図２の表記法によると
   • 「C → A|B」は「C が A, B を独立に決定しうる」
   • 左辺 C が従属先 A, B を多値従属性で決定することを示す
3. 表３を見ると、同一の 予約枠ID に対して
   • 複数の 会員ID（例：R2 → B1,B2）
   • 複数の スタッフID（例：R4 → S2,S3）
     がそれぞれ独立に組合せで現れている。
4. したがって決定側 C に当たる属性は 予約枠ID、
   従属側 A,B に当たる属性は 会員ID と スタッフID となり、
   図６の (a)＝予約枠ID、(b),(c)＝会員ID,スタッフID となる。

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

• FD（関数従属性）との混同
  • FD なら「X→Y」で同一の X に対し Y が一意に決まる必要があるが、
    本問では同一 予約枠ID に対し複数の会員・スタッフが存在するため FD ではなく MVD。
• 決定側と従属側の取り違え
  • 属性を左右逆に考えてしまいがち。
  • 「どの属性がキー（C）なのか」を常に確認する。
• (b),(c)は順不同
  • どちらを先に書いてもよいが、両方を挙げることが必要。

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

1. 多値従属性の定義
   • X ↠ Y とは「同一の X であれば Y は複数取り得るが、それらの組合せは X に依存し，かつ他の属性と独立している」こと。
2. 正規化と第4正規形（4NF）
   • 4NF では「非自明な多値従属性を持たない」ことが要件。
3. 図2の表記法の読み方
   • 二重矢印（↔）や縦棒（|）の有無で FD と MVD を区別。
   • 「C → A|B」と「C → A,B」は別物である点を押さえる。
4. 問題文のキーワード確認
   • 「自明でない多値従属性が含まれている」とあれば、MVD を意識して図２の表記に当てはめる。

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

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

2.1 元の関係（表３「クラス」＝表２「予約時間割」の簡略形）

クラス(予約枠ID, 会員ID, スタッフID)

2.2 表２から読み取れる依存関係

1. 予約枠ID ↠ 会員ID
   R2 が B1・B2、R4 が C1・C2・C3 と 複数値が存在。
2. 予約枠ID ↠ スタッフID
   R4 に S2・S3 がある。
3. 会員ID と スタッフID の間には FD も MVD も存在しない
   （同じ会員がどのスタッフとも自由に組める／スタッフも同様）。

2.3 4NF の要件

2.4 分解の手順

2.5 出力すべき２つの表（模範解答）

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

4. 試験対策まとめ

1. 第４正規形（4NF）の定義
   主キー以外を決定項に持つ非自明な MVD を許さない。
   → 出たら 「左側が主キーか？」を真っ先に確認。
2. 多値従属性の見抜き方
   ① 同じ決定項値で右側が複数現れる。
   ② その複数の組合せが互いに独立（順列をすべて列挙可能）。
   ③ 右側どうしに FD が無い。
3. 分解の原則
   ・MVD X ↠ Y があるとき R(XY) を R1(XY) と R2(XZ) に。
   ・分解後に 無損失結合 と 従属性保存 を必ず確認。
4. 出題パターン
   ・「予約」「在庫」「履修」など “１対多対多” が同時に発生しやすいテーブル。
   ・「図２の記号」＝ MVD 表記をそのまま利用する年もある。
   → 記号が出たら 4NF／5NF を疑う。
5. 用語の暗記
   FD（関数従属性）、MVD（多値従属性）、ジョイン従属性、無損失分解、従属性保存、候補キー。