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

キーワード・論点整理

• 主キー候補とバージョン管理
  “患者”関係には「患者ID」と「登録日」の組み合わせで、同一患者の情報更新（氏名・住所・年齢など）の履歴を管理する
• 属性の変更可能性
  • 患者名・患者住所・年齢：「登録日にによって変更があり得る」
  • 性別・生年月日：「登録日による変更はない」
  • 家族構成・職業等：変更頻度の記述なし ⇒ 登録日のバージョン履歴管理の対象外
• ネスト属性（複合属性）
  • 家族構成 ⇒ 同居人数、連絡窓口
  • 職業等 ⇒ 職種、通勤手段、徒歩時間
• 図2の表記法
  • {X, Y} → Z
  • {X} → {R.A, R.B} （Rというリレーション内のネスト属性サブ要素）
• 問題要求
  • 図3未完成図に□として属性名を当てはめる
  • 図2の表記法に従い、主要な関数従属性を明示
  • ネスト属性の内部要素同士、または導出可能な二次的従属性は省略

図3（関係“患者”）の完成イメージ

1. 【複合キー】としての {患者ID, 登録日}
2. 氏名・住所・年齢は履歴管理の対象 ⇒ {患者ID, 登録日} → 患者名, 患者住所, 年齢
3. 性別・生年月日は登録日で変化しない ⇒ 患者ID → 性別, 生年月日
4. 家族構成・職業等は登録日によらず決定 ⇒ 患者ID → 家族構成, 職業等
5. ネスト属性内部への展開
   • 家族構成 → 同居人数, 連絡窓口
   • 職業等 → 職種, 通勤手段, 徒歩時間

※ ネスト属性内部どうしの従属性や、生年月日と登録日から年齢を算出するような導出的関数従属性（例：{生年月日,登録日} → 年齢）は、問題文の指示により省略しています。

なぜこのようになるか ―【問題文】の引用と論理

• 患者名・患者住所・年齢について
  「登録日にによって変更があり得る。」
  ⇒ 更新のたびに前のデータを残すため、履歴のキーに「登録日」を含める必要がある
• 性別・生年月日について
  「登録日による変更はない。」
  ⇒ 登録日をキーに含めず、単純に患者IDだけで一意決定できる
• 家族構成・職業等について
  「患者の家族の構成。…情報を記録する。」「患者の職業など。…情報を記録する。」
  ⇒ 登録日のバージョン管理要件は示されておらず、患者IDだけで管理
• ネスト属性の展開
  「〔同居人数、連絡窓口〕の情報を記録する」「〔職種、通勤手段、徒歩時間〕の情報を記録する」
  ⇒ 「家族構成」「職業等」をキーとする階層的構造

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

1. 主キーの取り違え
   「患者IDだけ」を主キーにすると、氏名・住所・年齢の更新履歴を失う
2. ネスト属性の扱い
   「家族構成」「職業等」を分解せずに全体を多値属性と誤理解しやすい
3. 導出的FDの混在
   生年月日と登録日から年齢を「導出」できるが、本問では「導出は省略」することに注意

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

• 「変更履歴（バージョン管理）」が必要な属性は主キーに『更新日』などのタイムスタンプを含める
• 『属性がいつ変更し得るか』を制約文から正確に読み取る
• ネスト属性（複合属性）は、上位属性をキーにしてサブ属性を展開する
• 図2の表記法（集合括弧{}とドット.）を使いこなし、ネスト属性のFDを明確に記述する

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

• 番号：②
• 対象となる関係：関係“地域連携”
• 問題箇所の属性集合：{病院名，住所，担当医，担当スタッフ}
• 成立しない理由の要点：紹介先と紹介元という２つの多値関係があるため，一意に決まらない

解答へ至る論理的説明

1. 図４の関数従属性②は「患者ID → {病院名，住所，担当医，担当スタッフ}」を示しています。
2. 問題文にあるように、

   「関係“地域連携”」には，
   紹介先（病院名，住所，担当医，担当スタッフ）と
   紹介元（病院名，住所，担当医，担当スタッフ）がある。

3. ここで「患者ID」が決まっても，【紹介先】と【紹介元】の双方の情報を区別せずには，
   {病院名，住所，担当医，担当スタッフ} が一意に定まらないため，関数従属性は成立しません。

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

• 「紹介先」と「紹介元」を同じ属性群とみなし，両者を混同してしまう
• 多値属性（ネストされた関係）がある場合でも，単純に親関係のキーから引けると誤認する

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

• 関数従属性が成立するためには，「ある属性集合→対象属性群」が必ず一意に決定できなければならない
• 多値属性やネストされた関係では，同じ属性名が複数回登場しているケースがあるので，
  「どのサブ関係の属性か」を見落とさない
• 図示された矢印（→）の起点・終点がネスト構造になっていないかを必ず確認する

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

• 推移的関数従属性（transitive dependency）
  ある関数従属性 X→Y と Y→Z が成立し，かつ Y が候補キーの一部でもない「非キー属性」であるとき，X→Z を導く従属性を推移的関数従属性という。
• 図４（関係 “地域連携”）に示される主な関数従属性の一覧化
  → どの従属性ペアが X→Y と Y→Z の形をとり，かつ中間属性 Y が非キー属性かを確認する必要がある。

2. 解答の理由と論理的説明

図４中で,推移的関数従属性があれば、その例を一つ挙げよ。なければ,“なし” と答えよ。

• たとえば⑤と⑥を組み合わせると，一見「患者ID→入院日→身長…」という推移的な関係に見えます。
• しかし「入院日」は候補キーの一部（prime属性）であるため，中間属性 Y が非キー属性でなければ推移的関数従属性とは認められません。
• 図４で中間属性が「すべて候補キーの一部」となっており，“Y が非キー属性” の条件を満たすものが存在しないため，推移的関数従属性の例は 「なし」 となります。

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

• 「患者ID→入院日→身長,体重…」の流れを見て，単に「入院日を介して患者ID→身長」が導かれるので推移的と思い込む誤り。
  → 入院日が候補キーの一部（prime属性） のため，推移的従属性の要件を満たさない。
• 問題文で定義される「推移的関数従属性」の要件（中間属性は非キー属性）を見落としやすい点に注意。

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

1. 推移的関数従属性の定義
   X→Y，Y→Z が成立し，かつ Y が非キー属性（prime属性ではない）である場合に限る。
2. prime属性／non-prime属性
   • prime属性：いずれかの候補キーを構成する属性
   • non-prime属性：prime属性でない属性
     推移的従属性を判定する際は，必ず中間属性が non-prime かを確認する。
3. 図で示される従属性を整理する習慣
   • 左辺 X，右辺 Y を表形式に書き出す
   • 中間属性が候補キーの一部かどうかも併せてチェック

解答のキーワード・論点整理

• 単一値（原子値）
• ネストされた関係属性（例：「診断」など）
• 第1正規形（1NF）の定義：「すべての属性の値が単一の原子値であること」

なぜその解答になるのか

「診断（主診断名、発症日、糖尿病の病型）」

関係“診療”の主な属性例

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

• 「薬物療法」の多値性（＊薬品名）を挙げる誤り
  → 多値属性も1NF違反ですが，本設問が想定するのは「診断」などのネストされたリレーション属性です。
• 1NFの定義を「反復群の排除」とだけ覚えて，ネスト関係との区別があいまいになる
  → 反復群も原子値違反の一種ですが，まずは「属性の値が必ず単一の原子値か」を判定する習慣をつけること。

試験対策のポイント

1. 第1正規形の定義を正確に覚える
   「各属性のドメインは単一値（原子値）でなければならない」
2. 図やスキーマ中の括弧表記に注目
   「〇〇（…）」とサブ属性が列挙されているものは非原子属性の典型
3. ネストされた関係と多値属性を区別
   • ネストされた関係…属性自体がリレーション
   • 多値属性……属性値が複数個保持可能
4. 練習問題で具体的な例に当たる
   図のスキーマを手で写して，どの属性が単一値かを常にチェックする習慣をつけること。

解答の概要とキーワード整理

• 候補キー：関係内のすべての属性を決定する最小の属性集合
• 関数従属性（FD: Functional Dependency）
• 多値属性（「*薬品名」による繰り返し）
• 正規化（MVDの分解）

なぜその候補キーになるのか

1. 元の「診療」関係の構造
   問題文の図1および図5より，「診療」関係には以下の主な属性とFDが存在します。
   • 主キー候補は「患者ID」「診断日」「指導日」の組み合わせ（各診療記録はこれで一意）
   • {患者ID, 診断日} → 診断（主診断名, 発症日, 糖尿病の病型）
   • {患者ID, 診断日} → 合併症（網膜症, 神経障害, じん症, その他）
   • {患者ID, 指導日} → 治療内容（食事療法, 運動療法, 薬物療法）
   • {患者ID, 指導日} → 生活指導（調理担当, 指示カロリー, …）
   • ただし「*薬品名」は多値属性で，ある指導日に複数処方されうる
2. 関係分割（正規化）後の各関係における属性とFD
   (1) 診療・診断
   • 属性：患者ID, 診断日, 主診断名, 発症日, 糖尿病の病型
   • FD：{患者ID, 診断日} → (主診断名, 発症日, 糖尿病の病型)
   • よって候補キーは {患者ID, 診断日}
   (2) 合併症
   • 属性：患者ID, 診断日, 網膜症, 神経障害, じん症, その他
   • FD：{患者ID, 診断日} → (網膜症, 神経障害, じん症, その他)
   • よって候補キーは {患者ID, 診断日}
   (3) 治療・指導
   • 属性：患者ID, 診断日, 指導日, 食事療法, 運動療法, *薬品名, 調理担当, 指示カロリー, …
   • FD：{患者ID, 診断日, 指導日} → (食事療法, 運動療法, 調理担当, 指示カロリー, …)
   • 「*薬品名」は同じ{患者ID, 診断日, 指導日}で複数行を持ちうるので，各行を識別するには 薬品名 をキーに含める
   • よって候補キーは {患者ID, 診断日, 指導日, 薬品名}

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

1. 「診断日」を忘れるミス
   • 診療・診断や合併症の関係では，単に「患者ID」だけでは同一患者の複数回診断を区別できないため，「診断日」を必ず含める必要があります。
2. 多値属性への対応不足
   • 「*薬品名」があるときに，「患者ID＋診断日＋指導日」だけをキーにすると，薬品ごとの行を一意に識別できません。
   • つまり {患者ID, 診断日, 指導日} では多重行（複数薬品）がまとめられてしまうため，「薬品名」をキーに加える必要があります。
3. 最小性の確認不足
   • キーの定義では「最小性」を満たすかが大切です。
   • 不要な属性を含めていないか，候補キーから一属性取り除いても従属性が保持されるかをチェックしましょう。

試験対策ポイント

• 「候補キー」は 最小の決定属性集合 であることを必ず意識する
• 関係分割時は，各部分関係に残るFDを整理しなおし，キーを再導出する
• 多値属性（繰り返し属性） を含む場合は，必ずその値を一意に識別できるようキーを拡張する
• 問題文の 図や注記からFDを正確に読み取り，その上でキー定義に反映する
• 覚えておくべき定義：
  • 関数従属性（X→Y）
  • キー（スーパーキー／候補キー）
  • 正規化（第1正規形, MVD分解）

1. 模範解答の核心となるキーワード・論点整理

• 第1正規形：「属性がすべて，単一値を取る」
• 第2正規形：「非キー属性が，候補キーに完全関数従属する」
• 第3正規形：「候補キーからの推移的関数従属がない」

2. なぜ第3正規形になるのか

関係“診療 診断”の構造と候補キー

関数従属性の把握

{患者ID, 診断日} → {主診断名, 発症日, 糖尿病の病型}

第1～第3正規形の判定

1. 第1正規形
   問題文の注釈に「＊は複数の値又は値の組を取り得ることを表す」とありますが，関係“診療 診断”の各属性はすべて単一値であるため，第1正規形を満たします。
   「属性がすべて，単一値を取る。」
2. 第2正規形
   主キー {患者ID, 診断日} の一部から非キー属性に関数従属するもの（部分関数従属）がありません。
   全ての非キー属性（主診断名, 発症日, 糖尿病の病型）は候補キー全体に対して従属しているため，第2正規形を満たします。
   「非キー属性が，候補キーに完全関数従属する。」
3. 第3正規形
   非キー属性間の推移的関数従属（例： A→B かつ B→C）が存在せず，候補キー以外の属性が他の非キー属性を決定するものがありません。
   よって，第3正規形を満たします。
   「候補キーからの推移的関数従属がない。」

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

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

1. 正規化の定義を正確に
   • 第1正規形：属性は単一値
   • 第2正規形：部分関数従属の排除
   • 第3正規形：推移的関数従属の排除
2. 候補キーの特定
   • 関係の全属性をカバーし，最小で決定できるキーを必ず挙げる。
3. 関数従属性の整理
   • 図2の記法を読み取り，どの集合がどの属性を決定するかを明示的に書き出す。
4. ネスト関係・多値属性の区別
   • ＊ がない場合は多値属性でなく，単一の関係スキーマとみなす。
5. 誤答を防ぐチェックリスト
   • ［　］第1正規形を満たす？
   • ［　］部分従属がない？
   • ［　］推移的従属がない？

キーワード・論点整理

• 挿入異常（Insertion Anomaly）：必要な属性がそろわないとタプルが登録できない問題
• 関係“治療 指導”における主キー候補属性：患者IDと指導日
• 指導日は「患者に生活指導を実施した日付」であり、未実施時には値がない

解答の論理的説明

1. 関係“治療 指導”では，主キーに「患者ID」と「指導日」が含まれています。
2. 属性「指導日」は【問題文】の「指導日：患者に生活指導を実施した日付」で定義されており，
   指導を行わなければ値が存在しません。
3. したがって，たとえ「診断」や「治療内容」の情報がそろっていても，
   「指導日」が未定義ならタプルを挿入できず，挿入異常が発生します。

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

• 「参照制約の違反」と混同しやすいが，本質は 必須項目の欠如による挿入不可。
• 更新／削除異常（Update/Deletion Anomaly）ではなく，挿入時点での制約違反である点に注意。
• 「指導日」を後からNULLで入れればよい、と思いがちだが，リレーショナルモデルではキー属性にNULLは許されない。

試験対策ポイント

• 正規化が不十分だと，主キーに業務シナリオ上未定義の属性が混在し，挿入異常を招く
• 挿入異常・更新異常・削除異常の定義と具体例を整理
• 関係スキーマ設計では，「いつ」「どのような条件で属性値が得られるか」をキー設計時に検討すること

キーワード・論点整理

• 関係“治療・指導”の属性
  患者ID, 診断日, 指導日, 食事療法, 運動療法, 薬物療法（＊薬品名）, 調理担当, 指示カロリー, 自己血糖測定有無, 測定器
• 主な関数従属性（図5より）
  • {患者ID, 診断日} → 食事療法, 運動療法, 薬物療法
  • {患者ID, 診断日, *薬品名} は多値属性（薬物療法）
  • {患者ID, 指導日} → 調理担当, 指示カロリー, 自己血糖測定有無, 測定器
• 3NFへの分割方針
  1. 部分関数従属性・多値属性を除去
  2. 各従属性グループごとにリレーションを分離

解答がこうなる理由

1. 「薬物療法」は ＊薬品名 という多値属性をもつため、1NF（繰り返し属性の排除）で別関係に分割する必要があります。
   【問題文】より引用：

   「薬物療法（ ） …〔*薬品名〕の処方情報を記録する。複数の薬品を処方する場合がある。」

2. 「食事療法」「運動療法」は {患者ID, 診断日} で決定されるので、これらを「治療内容」関係にまとめます。
3. 「調理担当」「指示カロリー」「自己血糖測定有無」「測定器」は {患者ID, 指導日} で決定されるため、日付が異なる「診断日」と分け、「生活指導」関係にまとめます。
4. 以上により、部分関数従属性・多値属性を排除し、各リレーションが主キーに対して属性が完全関数従属する第3正規形（3NF）となります。

第3正規形への分割後スキーマ

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

• 多値属性の見落とし
  「＊薬品名」を通常の属性とみなして「治療内容」に含めると1NF違反となります。
• 部分関数従属性の取り扱い
  「調理担当」などが {患者ID, 診断日} ではなく {患者ID, 指導日} で決まる点を間違え、「治療内容」と混在させることがある。
• キーの設定ミス
  薬物療法のリレーションで主キーに「薬品名」を含め忘れると、同一患者・同一診断日の複数薬品を扱えません。

試験対策ポイント

1. 多値属性（＊付き）は必ず別リレーションへ
   1NFの観点から、繰り返す属性は分割する。
2. 属性決定元（関数従属性）を整理
   ・日付が「診断日」か「指導日」かで、従属する属性群を分ける。
3. 第3正規形の要件
   • 主キー以外の属性同士に推移的関数従属がないこと
   • 部分関数従属を排除し、各属性がリレーションの主キー全体に対して完全関数従属
4. 図5の矢印を読み取る訓練
   問題文中の「図5　関係“診療”の属性間の主な関数従属性」を活用し、FDを正確に抽出する。

核心キーワードと論点整理

• 図１「経過・評価」のスキーマ
  経過・評価（患者ID、[a]、体重、体脂肪率、血液検査（[b]）、尿検査（[c]）、最終眼科受診日、アキレス腱反射（[d]））
• 図６「関係“経過・評価”の属性間の主な関数従属性」
  検査日、評価日、経過月数、目標値、血液検査〈血糖値、HbA1c,…〉、尿検査〈尿糖、尿たん白〉、最終眼科受診日、アキレス腱反射〈右、左〉 など
• 「網掛け部分の属性は省略し、それ以外の…属性名を記述する」
  → 図６で 網掛け(省略)されていない 属性を抜き出す

解答の導出過程

1. 図１の未記入箇所を確認

   経過・評価（患者ID、[a]、体重、体脂肪率、
               血液検査（[b]）、尿検査（[c]）、
               最終眼科受診日、アキレス腱反射（[d]））
   

2. 図６に示された「関係“経過・評価”」の属性一覧（※網掛け部分のみ省略）のうち、図１で明示済みでないものをあてはめる
   • 図６には以下の属性が存在する
     • キー系：検査日、評価日
     • 管理系：経過月数、目標値
     • 計測系：体重、体脂肪率、腹囲
     • 血液検査：血糖値、空腹時随時種別、HbA1c、グリカルビン、T-CHO、TG、HDL-CHO、LDL-CHO、Cre
     • 尿検査：尿糖、尿たん白
     • その他：最終眼科受診日、アキレス腱反射〈右、左〉
3. 図１で既に列挙済みの属性を除外
   • 除外対象：体重、体脂肪率、腹囲（図１にないため網掛けされたと判断）、空腹時随時種別 など
4. 未記入のスロットに対応する属性だけを拾い出す

   スロット	図６中の未記入属性
   a	評価日、検査日、経過月数、目標値
   b	血糖値、HbA1c
   c	尿糖、尿たん白
   d	右、左

なぜその解答になるのか

• 図１の定義：「経過・評価（患者ID、[a]、体重、体脂肪率、血液検査（[b]）、尿検査（[c]）、最終眼科受診日、アキレス腱反射（[d]））」
• 図６の関数従属性図には、経過・評価に含まれる全属性が描かれており、「網掛け部分の属性は省略」とあるため、網掛けされていない属性のみをスロットに埋める
• 図６中、網掛けされていない項目：
  • 検査日／評価日／経過月数／目標値 → [a]
  • 血液検査中の血糖値／HbA1c → [b]
  • 尿検査中の尿糖／尿たん白 → [c]
  • アキレス腱反射〈右／左〉 → [d]

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

1. 「腹囲」や「空腹時随時種別」などを混入
   → 図１に「体重、体脂肪率」のみ明示。腹囲や血液検査中のその他項目は網掛けされているため除外する
2. [a]に単一属性しか書かない
   → [a]は複数属性（検査日／評価日／経過月数／目標値）の集合であることに注意
3. アキレス腱反射の項目名を「アキレス腱反射」だけで埋める
   → ネストされたリレーションなので、内部属性「右」「左」を書き出す必要がある

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

• 「網掛け部分は省略される」という問題文の条件を正確に把握する
• ネストされた関係（多値属性など）は、外側の関係名ではなく内側の属性を列挙する
• 図からスキーマへ転記する際は、既出の属性を重複しないように注意する
• 図１と図６を行き来し、「どの属性をまだ埋めていないか」を常にチェックリスト方式で確認することで漏れ・混入を防ぐ

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

• 関数従属性の前提条件変更
  「血液検査と尿検査を同一日に実施するものとする」という制約が外れたため、両検査を同一キー（検査日）で管理できなくなる
• リレーショナル・スキーマの分割
  １つの関係（“経過・評価”）で管理できない属性群は、演算的に別の関係に分解して扱う
• 正規化（第１～第３正規形）の観点
  検査日によって異なる属性グループを分離し、重複や更新時の異常を防止

2. 解答の論理的説明

「検査日：血液検査及び尿検査を行った日付。両方の検査は同一日に実施するものとする。」

1. 評価情報（評価日をキーとする）
2. 血液検査情報（検査日をキーとする）
3. 尿検査情報（検査日をキーとする）

変更後の “経過・評価” スキーマ例

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

• 「検査日」を “経過・評価” の評価グループに残したままにすると、血液／尿検査の分離が不完全になり更新異常を招く
• (a) で「患者ID」を含めないのは誤り。全リレーションにおいて患者IDは必要な外部キー（主キー一部）
• (b)/(c) の検査項目を複数欲張ってしまい、本試験で問われている最少構成とズレるケース

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

• 「同一キーで複数属性を管理できない」場合は関係を分割する（正規化の基本）
• 関数従属性の定義元が変更されたとき、どの属性群をまとめ、どれを分割するかを明確にする
• 問題文中の制約条件（ここでは「同一日に実施」）を丁寧に把握し、変更時の影響範囲を正しく特定すること