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

キーワード整理

• 関数従属性（Functional Dependency, FD）
  「X → Y」とは，関係において属性集合Xの値が決まれば属性集合Yの値が一意に定まることを指します。
• 主キーと候補キー
  ある関係スキーマにおいて一意性を保証する属性（集合）をキーと呼びます。単一属性のキー、複合属性のキーがあります。
• 図４の構成
  図４では，関係“受講者”，“コース”，“アクセス”を合成的に重ねて描き，①～⑤の矢印が各関数従属性を示しています。矢印の始点（決定側）がどの太枠・細枠に属するかを正確に読み取る必要があります。

図４に示された①～⑤の関数従属性と正誤

なぜ③が誤りか

1. 図４では，中央の太枠が関係“アクセス”または“コース”など，複合キーとして {受講者ID, コースID} をもつ関係を表しています。
2. 矢印③はこの太枠（＝{受講者ID, コースID}）から左側の「パスワード」「姓」「名」「メールアドレス」「電話番号」「住所」の属性群へ伸びています。
3. 同じ受講者が複数のコースを受ける場合，アクセス／コース関係には同じ受講者IDが複数行存在するため，太枠（＝複合キー）から直接これら個人情報を一意に導出することはできません。
4. 本来，これら個人情報は関係“受講者”（キー = 受講者ID または 認証ID）に属する属性であり，
   「受講者ID → パスワード等」は“受講者”関係内では成立しますが，図４の矢印③のように複合キーの関係から導くのは誤りです。

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

• 図４は“三つの関係”を重ねて描いているので，どの矢印がどの関係スキーマ内のFDか見分けにくい。
• 「受講者ID」が“受講者”関係のキーであることと，「受講者ID」が“アクセス”関係のキーでないことを混同しやすい。
• 矢印の始点が単一属性か複合属性か，細枠／太枠のどちらから出ているかを必ず確認すること。

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

1. 関数従属性は同一関係スキーマ内で判断する。異なる関係を合成した図では，枠の区分けに注意する。
2. リレーションの**キー（候補キー）**が何かを確実に押さえる。
3. 図中の矢印の始点・終点の枠を見て，その関係の主キー／非キー属性を整理する訓練を積む。
4. 「ある属性で他の属性が一意に決まるかどうか」は，関係における重複行の有無（同一キーによる複数行の可能性）で判断する。

キーワードと論点整理

• 関数従属性（Functional Dependency）
  あるキー（決定項）が決まれば、必ず一意に他の属性（従属項）が決まる関係を指します。
• 決定項が異なる関数従属性
  図中に示されていないが、別の属性を決定する関数従属性を挙げる問題です。
• 対象となる属性：
  • 受講者ID
  • 認証ID
  • 更新日時
  • パスワード、姓、名、メールアドレス、電話番号、住所

なぜその解答になるのか

① 受講者ID → 認証ID

• 【問題文】より引用
  「認証ID：受講者IDごとに発行されたログイン認証時に使用するID。システム上で一意になるように管理される。」
• 解説
  • 「認証ID」は「受講者IDごとに発行」され，受講者IDごとにただ一つの認証IDが存在します。
  • したがって，受講者IDが分かれば常にその受講者の認証IDが一意に決定されます。
  • この関係は図４に示された「認証ID → 受講者ID」とは逆向きになりますが，同様に妥当な関数従属性です。

② {受講者ID, 更新日時} → {パスワード, 姓, 名, メールアドレス, 電話番号, 住所}

• 【問題文】より引用
  「更新日時：受講者の情報が更新された日時。受講者のパスワード、姓、名、メールアドレス、電話番号、住所が、変更可能なことでこの履歴が保存される。」
• 解説
  • 「更新日時」は「受講者ID」ごとに情報を変更するたびに履歴が残るタイムスタンプです。
  • よって「受講者ID」と「更新日時」の組み合わせは，その時点でのパスワードや氏名・連絡先などを一意に識別します。
  • この複合キーから，パスワード, 姓, 名, メールアドレス, 電話番号, 住所 の６属性が一意に決定されるため，
    {受講者ID, 更新日時} → {パスワード, 姓, 名, メールアドレス, 電話番号, 住所} という関数従属性が成り立ちます。

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

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

1. 関数従属性の双方向性
   ‟A → B” が成り立つとき，必ずしも “B → A” が成り立つとは限りませんが，問題文の制約から逆向きにも意味があるかを検討する。
2. 履歴管理と複合キー
   更新履歴を保存する「更新日時」などは単独ではキーにならないが，組み合わせることで一意性を持つ場合がある。
3. 決定項（LHS）に注目する癖
   問題文で「○○ごとに一意に管理」「履歴が保存される」といった文言を見逃さず，どの属性が決定項になり得るか即座に判断する。

キーワード・論点整理

• 候補キー（candidate key）：関係スキーマ内で一意性を保ち、最小性を満たす属性の集合
• 関数従属性（functional dependency）
• 履歴管理のために「更新日時」が必須
• 「認証ID」と「受講者ID」は一意対応

解答導出の論理的説明

• {受講者ID, 更新日時}
  • 受講者ID で個人を特定し，更新日時で履歴の各レコードを区別
  • この組み合わせが「すべての属性を一意に決定」し，かつ最小

• {認証ID, 更新日時}

誤りやすいポイント

1. 更新日時を外してしまう
   受講者ID や 認証ID 単独では，一人の受講者に対する更新履歴を区別できず，複数行が同一キーと見なされてしまいます。
2. 「ログイン状態」や「パスワード」などをキーに含める
   これらは頻繁に変化し，また履歴の記録ルール（ログイン状態は履歴を残さないなど）からキー要件（不変性・最小性）を満たしません。
3. 認証IDと受講者IDが一意対応でないと誤解する
   問文に「認証ID は 受講者ID ごとに発行」「システム上で一意」とあるため，両者は 1:1 の関係です。

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

1. 候補キーの定義
   • 一意性（uniqueness）と最小性（minimality）
2. 履歴管理のためのスキーマ設計
   • 更新履歴を保持する属性（更新日時など）は，主キーに含めて一意にする
3. 関数従属性図の読み方
   • A → B は「A が決まれば B も決まる」ことを示す
   • 双方向に従属性があれば，それらもキー候補になり得る
4. 混同しやすい属性の切り分け
   • 意味的に変化しやすい属性（ログイン状態など）はキーには向かない
   • 「一意である」と明示された属性はキー候補に注目
5. キー設計の実践
   • 履歴をどう保持するかを考え，必要に応じてタイムスタンプ系属性を主キーに含める

キーワードと論点整理

• 正規形（1NF, 2NF, 3NF）の定義
  • 第1正規形（1NF）：属性値が原子値である
  • 第2正規形（2NF）：1NFかつ主キーの一部に依存する部分関数従属性がない
  • 第3正規形（3NF）：2NFかつ非キー属性間の推移的関数従属性がない
• 関数従属性（FD）の読み取り
  • 図4より
    1. 認証ID → 受講者ID
    2. 受講者ID → 初回アクセス日時, 最終アクセス日時
    3. 受講者ID → パスワード, 姓, 名, メールアドレス, 電話番号, 住所
    4. (受講者ID, コースID) → 開始日時, 終了日時, 総受講時間, ログイン回数
    5. ログイン日時 → IPアドレス
• 主キーの候補
  • “受講者”：認証ID（一意性の条件から）
  • “コース”：複合キー(受講者ID, コースID)
  • “アクセス”：複合キー(受講者ID, ログイン日時)

正規形判定結果一覧

各関係の詳細解説

1. 関係“受講者”の判定

• 主キー：
  「認証ID」は“ログイン認証時に使用するID。システム上で一意になるように管理される。”（問題文）
• 部分関数従属性：
  主キーは単一属性のため、部分従属性は発生しない → なし
• 推移的関数従属性：
  • 認証ID → 受講者ID（図4の①）
  • 受講者ID → パスワード, 姓, 名, メールアドレス, 電話番号, 住所（図4の③）
    → 認証ID → 受講者ID → その他情報 の推移がある → あり
• よって、第3正規形の条件を満たさず 第2正規形 まで

2. 関係“コース”の判定

• 主キー：
  複合キー (受講者ID, コースID)
• 部分関数従属性：
  図4の④「(受講者ID, コースID) → 開始日時, 終了日時, 総受講時間, ログイン回数」
  → 主キーのどちらか一方では決まらない → なし
• 推移的関数従属性：
  非キー属性間の従属性はなし → なし
• よって、第3正規形 を満たす

3. 関係“アクセス”の判定

• 主キー：
  複合キー (受講者ID, ログイン日時)
• 部分関数従属性：
  • 図4の②「受講者ID → 初回アクセス日時, 最終アクセス日時」
    → 主キーの一部(受講者ID)のみで非キー属性が決まる → 部分従属性あり
  • 図4の⑤「ログイン日時 → IPアドレス」
    → 主キーの一部(ログイン日時)のみで非キー属性が決まる → 部分従属性あり
    → あり
• 推移的関数従属性：
  部分従属性を分解すれば非キー属性同士の従属性はない → なし
• よって、第1正規形 で止まる

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

1. 主キーの取り方
   • “受講者”で「受講者ID」を主キーにしてしまうと，FD①が逆向きと矛盾する
   • “アクセス”で「ログイン日時」だけを主キーと誤認しがち
2. 部分従属性と推移的従属性の区別
   • キーが単一属性か複合属性かを意識しないと「部分従属性」と「推移的従属性」を取り違える
3. 図4のFD番号を引用する際，属性名を正確に書く
   • 例：「(受講者ID, コースID) → 開始日時, 終了日時, 総受講時間, ログイン回数」

試験対策まとめ

• 正規化判定の流れ
  1. 主キーを特定
  2. 部分関数従属性の有無 → 2NF到達性判定
  3. 推移的関数従属性の有無 → 3NF到達性判定
• 部分従属性
  • 主キーが複合なら要チェック
  • キーの一部に従属性があると2NF違反
• 推移的従属性
  • 非キー属性間の「A → B → C」を要チェック
  • 存在すると3NF違反
• 図示された関数従属性を正確に読み取り，属性名も誤りなく書けるように練習すること

キーワード・論点整理

• 関数従属性
  • 図５より
    • 中問ID → 中問作成日時, コースID, 制限時間, …
    • {中問ID, 小問番号} → 小問ID
    • 大問ID → 大問作成日時, 出題回数, 最終出題日時
    • {大問ID, 中問番号} → 中問ID
• 第3正規形（3NF）
  • 非キー属性が「キー属性に対してだけ」従属し，かつ推移的従属を排除
• 網掛けされていない属性
  • 図５中で網掛け（shade）されていないものだけを残す

解答の導出手順と論拠

1. 出題関係スキーマ（図２）には多くの属性があるが，図５の網掛けを確認すると，
   「出題回数」「最終出題日時」「中問名称」「導入文」「評価方式」「難易度」などは網掛けされ，
   第３正規形分解の対象外とする。
2. 図５の関数従属性を整理すると，出題のキーとなる複合属性は
   {大問ID, 中問番号, 小問番号} であり，
   • 大問ID → 大問作成日時（網掛けなし）
   • {大問ID, 中問番号} → 中問ID
   • 中問ID → 中問作成日時, コースID, 制限時間（網掛けなし）
   • {中問ID, 小問番号} → 小問ID
3. これらの従属性から，以下のように３NFへ分解する：
   • 大問ID 単独で決まる属性は「大問作成日時」のみ → 関係 出題(大問ID, 大問作成日時)
   • {大問ID, 中問番号} で決まる中問ID → 関係 大問中問(大問ID, 中問番号, 中問ID)
   • 中問ID 単独で決まる属性は「中問作成日時, コースID, 制限時間」のみ → 関係 中問(中問ID, 中問作成日時, コースID, 制限時間)
   • {中問ID, 小問番号} で決まる小問ID → 関係 中問小問(中問ID, 小問番号, 小問ID)

分解後の関係スキーマ

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

• 網掛け属性の取り扱い
  図５で網掛けされた属性は「除外」して記述すること。
• 部分関数従属の見落とし
  大問ID→大問作成日時， 中問ID→中問作成日時 などキーの一部で決まる属性は別関係に分解。
• 推移的従属の除去漏れ
  大問ID→中問ID（via 大問中問）→中問作成日時 を残すと3NF違反となるため，中問関係を独立させる。

試験対策ポイント

• 第3正規形の定義を正確に：
  1. 関係は第2正規形である
  2. 非キー属性間に推移的関数従属がない
• 図示された関数従属性図（FD図）から「決定側→従属側」を正しく読み取り，
  部分従属・推移従属を見極めて分解する演習を重ねる
• 問題文の「網掛け」「太字」「アンダーライン」などの指示は厳密に守ること

キーワード・論点整理

• 第３正規形（3NF）
  └ 全ての非キー属性が「キーの真部分集合」にのみ関数従属しないこと
• 部分関数従属の検出と分解
• 関係“答案”の属性
  ‒ 受講者ID, 大問ID, 小問ID, 解答日時, 解答時間, 解答回数, 評点, 解答, 得点
• 図６（関係“答案”の属性間の主な関数従属性）
  1. {受講者ID, 大問ID, 解答日時} → 解答時間, 評点
  2. {受講者ID, 大問ID} → 解答回数
  3. {受講者ID, 大問ID, 解答日時, 小問ID} → 解答, 得点

解答がこうなる理由

1. 元のスキーマとキー
   問題文より，関係“答案”は
   「受講者ID, 大問ID, 小問ID, 解答日時, 解答時間, 解答回数, 評点, 解答, 得点」
   の９属性をもち，解答の一意性は
   {受講者ID, 大問ID, 解答日時, 小問ID} の複合キーで担保されています（図６の最外枠）。
2. 部分関数従属の抽出
   • 「解答回数」は，【問題文】の説明「解答回数：受講者が**, 同じ大問に対して解答した回数**」
     から，(受講者ID, 大問ID) のみで決まり，主キーの真部分集合に従属しています。
   • 「解答時間」「評点」は，図６の矢印①の関数従属性
     {受講者ID, 大問ID, 解答日時} → 解答時間, 評点
     に従い，主キー全体ではなく「解答日時」を含む部分集合だけで決まります。
   • 「解答」「得点」は，図６の矢印③に示される
     {受講者ID, 大問ID, 解答日時, 小問ID} → 解答, 得点
     で得られ，主キー全体で決まる非キー属性です。
3. 第３正規形への分解
   • 部分関数従属する「解答回数」を独立させ，関係 回数 とする。
   • {受講者ID, 大問ID, 解答日時} → 解答時間, 評点 は，推移従属もないので，関係 採点 にまとめる。
   • 「解答」「得点」は主キー全体にのみ従属するので，関係 解答 に残す。
   • この分解はロスレスかつ依存関係保存を満たします。

分解後の関係スキーマ

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

• 「解答回数」の部分従属に気づかず，元の関係に残したままにすると第３正規形を満たさず，更新時に不整合が起きる。
• 「大問ID」を解答テーブルに残してしまうと，解答ごとに同じ大問IDが繰り返され，冗長性が生じる。
• 関数従属性図で「→」の始点／終点がどの属性群かを正確に読み取る演習を怠ると，誤った分解をしてしまう。

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

1. 第３正規形(3NF)の定義
   • 非キー属性は「キーの真部分集合」へ従属してはならない。
   • 推移従属(非キー属性→非キー属性)も排除。
2. 関数従属性図の読み方
   • 矢印の起点が「決定側」、矢印の先が「従属側」。
   • 部分従属・推移従属を見つけ，分解方針を立てる。
3. 典型的な部分従属の例
   • 集計値（回数・合計・平均など）はキーの部分集合だけで決まる場合が多い。
4. 分解後のロスレス結合と依存関係保存の確認
   • 分解前と同じ情報が復元できることを念頭に，キーの共有属性をチェックする。

キーワード・論点整理

• 図７の役割
  「小問タイプ」と「属性名・属性値」の関係を、破線矢印で（A）・（B）の特殊な関数従属性として示している。
• 設問文
  「小問IDが決まれば,その小問の(a)が決まる。 そのタイプごとに(b)が決まり、 それぞれの(c)が一意に決まる。」
• 模範解答
  a：小問タイプ
  b：属性の組
  c：属性値

解答の理由と論理的説明

1. 「小問IDが決まれば,その小問の(a)が決まる。」
   • 問題文：

     「図7は,小問タイプとその解答形式ごとの属性名, 属性値の関係を示したものである。」

   • 小問ID → 小問タイプ
     図７の左側大枠（小問側）を見ると、小問ID が与えられると必ず１つの 小問タイプ が割り当てられます。
2. 「そのタイプごとに(b)が決まり、」
   • 問題文：

     「図７　関係 ‘小問’, ‘小問タイプ属性’ の属性間の主な関数従属性」

   • 小問タイプ → 属性の組
     破線矢印 (A) は「小問タイプ」からサブタイプ枠（短文型／数値型など）への破線矢印で示され、それぞれのタイプごとに必要となる 属性名の集合（＝属性の組）が定まります。
3. 「それぞれの(c)が一意に決まる。」
   • 図７では、属性名が確定すると、その属性名に対応する 属性値 が必ず１つ決まることを示しています。
   • 破線矢印 (B) は「連番／小問ID」から各サブタイプ枠への破線矢印で、同じサブタイプ内での識別キーと属性名から 属性値 が一意に決定されることを表現しています。

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

1. 「属性名」「属性値」「属性の組」の混同
   • 「属性名」は列の名前、「属性値」はセルに入る実データ、「属性の組」はその属性名をまとめた集合。
   • 設問では「タイプごとに決まる」のは属性の集合そのものなので「属性名」ではなく「属性の組」が適切です。
2. 破線矢印 (A)/(B) の意味取り違え
   • 実線は通常の関数従属性、破線は「条件付き」や「サブタイプ間」の関数従属性を示す。
   • 図７では「破線(A)＝タイプ→属性の組」「破線(B)＝キー→属性値」と覚えると整理しやすいです。

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

• 関数従属性の表記法
  • 実線：標準的な FD
  • 破線：サブタイプ・条件付き FD
• EAVモデル（属性–値ペア）の考え方
  • メタ属性（属性名集合）と実データ（属性値）を分離して扱う場合、
    1. エンティティ（小問ID）→ タイプ
    2. タイプ → 属性名集合
    3. （エンティティ＋属性名）→ 属性値
• 用語の厳密な区別
  • 「属性」：列やフィールド
  • 「属性名」：列の名前
  • 「属性値」：列に入る具体的な値
  • 「属性の組」：あるレコード群に対して定義される属性名の集合
• 図からの読み取り練習
  • 実際の図を見て、矢印の始点（決定側）→先端（従属側）を正確に把握する習慣をつける。

設問３ 解説

1. キーワード・論点整理

• 関数従属性（FD: Functional Dependency）
  → 「ある属性の値が決まれば，別の属性の値も一意に決まる」関係
• 主キーと非キー属性
  → スキーマ全体の主キーが何か，それ以外の属性がどのキーに従属するか
• 推移従属
  → A→B かつ B→C の関係があるとき，A→C を推移従属という
• 第3正規形（3NF）への分解
  → 「すべての非キー属性は主キーに対して直接従属し，推移従属を持たない」形

2. 図８から読み取る関数従属性

1. 小問ID → 小問タイプ
   「小問ID が決まれば，その問題のタイプ（短文型・数値型 …）が一意に決まる」
2. {小問ID, 属性名} → 属性値
   「ある小問（ID）における特定の属性名（例：問文章, 最大値 など）の値は一意」

3. なぜこの FD（小問ID→小問タイプ, 小問ID+属性名→属性値）か

• 問題文に「属性名は小問タイプごとに定義され…異なる小問タイプ間で同じ属性名が使われ得る」とある。
  → 属性名だけでは属性値を一意に決められないので，小問ID と属性名の組で属性値を決定する
• 「受講者は…新規の大問が選択されると…小問ごとに短文型・○×型・数値型…などの解答形式のタイプをもち，小問タイプとして管理する」
  → 小問 ID が分かれば その小問タイプ（短文型 など）も一意に決定できる

4. 推移従属の発見と 3NF 分解手順

1. 主キー {小問ID, 属性名} のみから直接属性値が決まるように分離
2. 小問ID→小問タイプ の FD も別の関係に切り出し

5. 正規化後の関係スキーマ

• 小問タイプ：小問ID→小問タイプ（FD1 を扱う）
• 小問タイプ属性：小問タイプ→（属性名 の集合）
• 小問タイプ属性値：{小問ID, 属性名}→属性値（FD2 を扱う）

• 非キー属性（小問タイプ／属性値）がそれぞれ自前のキーにのみ従属し，
• 改めて「推移従属を持たない」第3正規形を満たします。

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

• 「属性名→属性値」という単純化した FD を想定しがちだが，属性名は小問ID に依存して選ばれるため正しくは {小問ID, 属性名}→属性値
• 推移従属（小問ID→小問タイプ→属性値）を見落として２表にしか分解しないと，第3正規形を満たさず更新異常を招く
• メタ属性テーブル（小問タイプ属性）を用意せずに同じ属性名を重複登録してしまう

7. 試験対策・押さえておくべき知識

• 第3正規形 (3NF)：非キー属性のうち「主キー以外の非キー属性に従属しているもの（推移従属）」を排除
• FDの洗い出し：図示や文章から「どの属性を決めれば他の属性も一意」かを丁寧に抽出
• メタデータ設計パターン：「タイプ」「属性名」「属性値」の３層モデルは，動的に属性を増やす際の典型的手法
• 分解後の参照整合性：外部キーを適切に張り，もとの情報が参照結合で復元できることを確認すること

1. キーワード・論点整理

• EAVモデル（Entity–Attribute–Value パターン）
  ‒ 実体（受講者）に対して任意に属性を追加登録したい場合、属性名と属性値を行方向に持つ設計手法
• 可変属性への対応
  ‒ 受講者ごとに異なる属性を「任意に追加」できる柔軟性
• 主キー設計
  ‒ 受講者ID と 属性名 の組み合わせで一意性を保証

2. なぜこのスキーマになるのか

「図2の関係‘受講者’について,‘関連資格有無’など受講者ごとに固有な属性を,任意に追加登録できるように,関係スキーマを追加する」

• 「受講者ごとに固有な属性」：
  1人の受講者に対して登録する属性の種類や数が固定できない
• 「任意に追加登録できる」：
  独立した列を増やすのではなく、属性名・属性値で動的に扱う必要がある

受講者ID（どの受講者の属性か）
属性名　　（追加したい属性の名称）
属性値　　（その属性に設定する値）

提案スキーマ

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

1. 横展開型に固定列を増やしてしまう
   • 「属性A」「属性B」といった列を追加すると、受講者によって不要な列が増え冗長になりやすい
2. 属性名だけ、あるいは属性値だけを主キーにしてしまう
   • 属性名単体では、異なる受講者間の重複を区別できない
3. 値の型を厳密に複数列で定義する
   • 文字列用、数値用、日付用…と列を分けると、逆に拡張性が失われる
4. EAVモデルの運用コストを見落とす
   • フレキシブルだが、検索・集計のパフォーマンスや型チェックが複雑化する点に注意

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

• EAV（Entity–Attribute–Value）設計
  ‒ 「実体ID × 属性名 × 属性値」の３カラムで可変属性を表現する標準パターン
• 主キーの選び方
  ‒ 重複登録を避けるため、(実体ID, 属性名) の複合キーを設定
• 正規化との関係
  ‒ 第１正規形では「繰り返し属性を行に展開」し、EAVモデルはこの考え方の応用
• 運用時の留意点
  ‒ 属性値は汎用型（文字列）で保持し、必要に応じてアプリ側やビューで型変換・チェックを行う
• 拡張性 vs 性能のトレードオフ
  ‒ 動的属性には有効だが、多数の行が生じるため性能要件とのバランスを考慮