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

模範解答

解説

解答の論理構成

1. 主識別子の確認
   表では「患者ID」を「地域で患者を一意に識別する記号」と定義している。よって

   患者ID → 生年月日, 性別
   

   は自明。
2. 時点情報の取り扱い
   「患者名」「患者住所」「家族構成」「職業等」は登録毎に変わると記載されている。従って

   患者ID, 登録日 → 患者名, 患者住所, 家族構成, 職業等
   

   が成立し、図３中央の太枠（患者ID と 登録日 を内包）から上下の破線枠へ矢印を引く。
3. 年齢の導出
   表には「登録日現在の患者の年齢」とある。図２の「複数属性が決定側」パターンを用い

   生年月日, 登録日 → 年齢
   

   を水平枠（生年月日 と 登録日 をまとめた枠）から 年齢 へ描く。
4. ネスト関係の分解
   (1) 「職業等（職種, 通勤手段, 徒歩時間）」より
   職業等 → 職種, 通勤手段, 徒歩時間
   (2) 「家族構成（同居人数, 連絡窓口）」より
   家族構成 → 同居人数, 連絡窓口
   破線枠から実線子枠へ矢印を引くのは図２下段の規則に従う。

誤りやすいポイント

• 「患者名」「患者住所」の決定側に「登録日」を入れ忘れる
• 「年齢」を 生年月日 → 年齢 と単純化してしまう
• ネストされた下位属性に直接 患者ID から矢印を引く（親→孫の従属性は導出扱いで省略が指示されている）
• 図２の記号ルールを読み替えずに左右逆に描いて減点

FAQ

模範解答

解説

解答の論理構成

1. 関係スキーマ確認
   図1より “地域連携” は
   「患者ID, 入院日, …, 紹介先（病院名, 住所, 担当医, 担当スタッフ）,
   紹介元（病院名, 住所, 担当医, 担当スタッフ）」
   を持つ。
2. ② の内容整理
   図4 の ② は “患者ID” から直接
   ｛病院名, 住所, 担当医, 担当スタッフ｝ への関数従属性を示す。
3. 一意性の検証
   ・同一患者が複数回入退院するケースがある。
   ・かつ “紹介先” と “紹介元” のどちらにも同じ 4 項目が出現する。
   したがって “患者ID” 値が同じでも
   4 項目は “紹介先”／“紹介元”／入退院の都度で変わり得る。
4. 帰結
   条件を満たすキーが不足するため
   “患者ID → 病院名, 住所, 担当医, 担当スタッフ” は成立しない。
   よって ② が誤りである。

誤りやすいポイント

• “紹介先” と “紹介元” を別関係と見誤り、同じ 4 項目が重複して
  登場していることに気付かない。
• “患者ID” が主キーだと早合点し、他属性との複合キーの可能性を
  検討しない。
• 図中の破線（サブリレーション）と実線（属性）の意味を混同し、
  関数従属性の読み取りを誤る。

FAQ

模範解答

解説

解答の論理構成

1. 推移的関数従属性の定義
   X → Y、Y → Z、かつ X ↛ Z のとき Z は X に対して推移的に従属。
2. 図4の主な関数従属性（問題本文にある矢印①〜⑦を整理）
   • 「患者ID → 紹介先」（①）
   • 「紹介先 → {病院名, 住所, 担当医, 担当スタッフ}」（破線枠内の矢印）
   • 「患者ID → {病院名, 住所, 担当医, 担当スタッフ}」（②）
   • 「患者ID → 入院日」（⑤）
   • 「入院日 → {身長, 体重, BMI, 体脂肪率, HbA1c}」（⑥）
   • 「患者ID → {身長, 体重, BMI, 体脂肪率, HbA1c}」（図中明示）
3. 各鎖の判定
   (a) 患者ID → 紹介先 → 病院名
   ③に反し、直接「患者ID → 病院名」（②）が成立。
   (b) 患者ID → 入院日 → 身長
   同様に「患者ID → 身長」が直接示されている。
   他の鎖も同様で、X ↛ Z を満たす組合せは見当たらない。
4. 結論
   推移的関数従属性の３条件を同時に満たす例が無いため、解答は“なし”。

誤りやすいポイント

• 「２段矢印＝推移的」と早合点する
  直接の X → Z を見落とさないこと。
• 「紹介先」「紹介元」の中の下位属性（病院名など）を別物と考え、鎖の終点と誤認する。下位属性も図4で直接 “患者ID” に従属している。
• 推移的 FD の定義で “X ↛ Z” を抜かす。定義を一字一句確認する習慣が必要です。

FAQ

模範解答

解説

解答の論理構成

1. 第１正規形の定義
   各属性値は原子値（１行１列に単一値）であることが条件です。
2. 関係 “診療” の構造確認
   【問題文】
   「診療（患者ID, 診断日, 指導日,
     診断（主診断名, 発症日, 糖尿病の病型）,
     合併症（網膜症, 神経障害, じん症, その他）,
     治療内容（食事療法, 運動療法, 薬物療法（＊薬品名））,
     生活指導（調理担当, 指示カロリー, 自己血糖測定有無, 測定器））」
   とあり，１つの属性位置に関係 “診断” などがそのまま格納されています。
3. 原子性の判定
   たとえば「診断」は３つの属性をまとめた複合値であり，１セル１値の原則を破ります。また「＊薬品名」は可変個数の繰返し値で同様に非原子値です。
4. 結論
   よって「関係の中に単一値とならない関係“診断”などがあるから」と説明できます。

誤りやすいポイント

• 「主キーが決まらない＝1NF違反」と勘違いする
• 可変数の繰返し（＊）よりもネスト関係の方が本質的問題であることを見落とす
• 関数従属性図に気を取られ，セル内の複合値の存在を確認し忘れる

FAQ

模範解答

解説

解答の論理構成

1. 関係分割の確認
   【小問説明】では関係“診療”を
   “診療 診断（患者ID，診断日，診断）”，
   “合併症（患者ID，診断日，合併症）”，
   “治療指導（患者ID，診断日，指導日，治療内容）”
   に分割している。
2. 【図５】中の主要な関数従属性
   • “診断日” → “診断”
   • “診断日” → “合併症”
   • “指導日” → “生活指導”
   • “治療内容” → “薬物療法” → *薬品名
   • “患者ID” は単独では他属性を決定しない（診療は繰返し可）。
3. “診療 診断” の候補キー
   • 必要属性：{患者ID，診断日}
   • この２属性で“診断”が決まり，他に属性は残らない。
   • どちらか１属性を欠くと一意性を失うため最小。
4. “合併症” の候補キー
   • 完全に同一の理由で {患者ID，診断日} が候補キー。
5. “治療指導” の候補キー
   • {患者ID，診断日，指導日} で “治療内容” までは決定。
   • しかし “治療内容” から *薬品名 は複数値が生じる。
   • 一意識別には “薬品名” も追加し {患者ID，診断日，指導日，薬品名} が最小。

誤りやすいポイント

• “患者ID” を主キーと早合点し，全行での重複を許さないと思い込む。
• “指導日” と “診断日” をどちらもキーに入れ忘れ，日付の区別による多重行を見落とす。
• “薬品名” を多値属性と気付かず除外し，治療指導の一意性を壊す。

FAQ

模範解答

解説

解答の論理構成

1. 候補キーの特定
   • 【図1】“診療” の列挙より対象サブ関係の属性は
     「患者ID, 診断日, 主診断名, 発症日, 糖尿病の病型」。
   • 医療実務では同一患者が同一日に複数の主診断を登録することは想定しづらく，【図5】の矢印も「患者ID」「診断日」で一意に診断が決まることを示している。よって候補キーは {患者ID, 診断日}。
2. 第1正規形 (1NF) の確認
   • 「主診断名」「発症日」「糖尿病の病型」はいずれも単一値で格納される（＊印もなし）。
   • ネスト関係は論理モデル上の表記であり，物理実装ではフラット化されるため重複グループや繰返し属性は存在しない。
3. 第2正規形 (2NF) の確認
   • 非キー属性すべてが候補キー {患者ID, 診断日} に “完全” 関数従属することを【図5】の矢印が示す。部分従属は存在しない。
4. 第3正規形 (3NF) の確認
   • 「主診断名 → 発症日」や「糖尿病の病型 → 主診断名」など，非キー属性間の関数従属性は図示されていない。
   • 従って非キー属性の間に推移的依存はなく，3NF の条件 $X\to Y,X⊉$ 候補キー → $Y$ がキー属性でない，というケースがない。

誤りやすいポイント

• 「診断日」単独で主診断を決めると誤認し，候補キーを「診断日」のみとする。患者が複数名いるため誤りです。
• ネスト表記を “複数値” と読み違え，1NF を満たしていないと判断する。図中の＊印の有無で確認が必要です。
• 「主診断名」→「糖尿病の病型」のような医学的連想で推移従属を想定してしまう。問題文中に示されない従属は採点対象外です。

FAQ

模範解答

解説

解答の論理構成

1. 関係“診療”の機能的従属性
   • 図５より
     「診断日」→「診断」「合併症」
     「指導日」→「生活指導」
     と二系統に分かれている。
2. 主キーの重複包含
   • 患者を識別する「患者ID」に加え，診断を一意化する「診断日」，指導を一意化する「指導日」までも複合キーに含まれる。
3. 挿入操作時の矛盾
   • 「診断日」は決まったが「指導日」が未定のケースでは，複合キーが未確定となりタプルを登録できない。
4. したがって関係“診療”は「診断しても，指導を行わないと情報を登録できない」という挿入異常を抱えると結論付く。

誤りやすいポイント

• 更新異常・削除異常と取り違える。今回はタプルが「入らない」ため挿入異常。
• 「治療内容」や「薬物療法」をキー候補と誤解し，問題の本質を外す。
• 「診断日」と「指導日」を片方だけで主キーと考え，異常が起きないと早合点する。

FAQ

模範解答

解説

解答の論理構成

1. 初期関係の取り出し
   関係 “診療” には【問題文】「治療内容（食事療法, 運動療法, 薬物療法（＊薬品名））」と「生活指導（調理担当, 指示カロリー, 自己血糖測定有無, 測定器）」が含まれ，さらにキー候補となる「患者ID」「診断日」「指導日」が存在します。
2. 関数従属性の把握
   図５より
   • 「診断日」→「治療内容」
   • 「指導日」→「生活指導」
   • 「治療内容」→「薬物療法（＊薬品名）」
     が読み取れます。したがって

   {患者ID, 診断日} → {食事療法, 運動療法, 薬物療法}
   {患者ID, 指導日} → {調理担当, 指示カロリー, 自己血糖測定有無, 測定器}
   {患者ID, 診断日, 食事療法, 運動療法} → {薬品名}
   

3. キーの決定
   患者が複数回受診するため，【問題文】「患者ID」で一意とはならず，日付を加えた
   • {患者ID, 診断日}
   • {患者ID, 指導日}
     が候補キーになります。
4. 非キー属性同士の依存を排除（第2→第3正規化）
   • {患者ID, 診断日} が決定しているのに “薬品名” がさらに “治療内容” に依存するのは第3正規形違反。
   • {患者ID, 指導日} が決定しているのに “調理担当” などが “指導日” のみに依存するのは第2正規形違反。
5. 分割
   ・“治療内容” から “薬物療法” を分離し，主キーに “薬品名” を追加
   ・“生活指導” は「患者ID」「指導日」をキーに独立
   ・残った “食事療法”“運動療法” は「治療内容」として保持
   以上より模範解答どおりの３関係に帰着します。

誤りやすいポイント

• 薬品名 を多値属性だからと削除・集約してしまう
• 「診断日」「指導日」を混同し，キーを {患者ID, 診断日, 指導日} としてしまう
• 第2正規形を飛ばして一気に分割しようとして依存関係を取り違える

FAQ

• 生活指導：非キー属性は全て {患者ID, 指導日} のみに従属
• 治療内容：非キー属性は全て {患者ID, 診断日} のみに従属
• 薬物療法：非キー属性なし
  で条件を満たします。

模範解答

解説

解答の論理構成

1. 経過・評価関係の構造確認
   【問題文】図1の関係定義に「経過・評価（患者ID, (a), 体重, 体脂肪率, …）」とある。従って (a) は“患者ID に次いでまとめて列挙される一群の属性”を表す。
2. 図6の中心ブロックから導ける属性
   【問題文】図6には二重枠内に「患者ID」「検査日」「評価日」が描かれ、そこから「経過月数」「目標値」へ矢印が伸びている。矢印は関数従属性を示すため、これら４つはセットで (a) に収まる。
3. 血液検査グループ (b) の抽出
   【問題文】図6で「検査日」→“血液検査”→具体属性の順に矢印が伸びる。網掛けでないのは「血糖値」「HbA1c」であり、この２つが (b)。
4. 尿検査グループ (c) の抽出
   同様に“尿検査”には「尿糖」「尿たん白」が描かれており、網掛けは無い。よって (c) はこの２属性。
5. アキレス腱反射グループ (d) の抽出
   【問題文】図6で“アキレス腱反射”の枠内に「右」「左」の２値が示されている。これが (d)。
6. 以上を図1の空欄に当てはめ、解答確定。

誤りやすいポイント

• 網掛けの「空腹時随時種別」「グリカルビン」「TG」「腹囲」などを含めてしまう。
• “目標値”を (a) に入れ忘れ、「検査日」「評価日」のみで止めてしまう。
• “右・左”を個別属性と認識せず、「アキレス腱反射」とだけ書いてしまう。
• (b)(c) を「血液検査」「尿検査」と上位概念で書いてしまう（設問は具体属性名を要求）。

FAQ

模範解答

解説

解答の論理構成

1. 変更前スキーマの確認
   • 【問題文】関係 “経過・評価”：
     「患者ID, (a), 体重, 体脂肪率, 血液検査((b)), 尿検査((c)), 最終眼科受診日, アキレス腱反射((d))」
   • 図６から読み取れる主な従属性
     「検査日 → 血液検査」，「検査日 → 尿検査」
2. 業務要件の追加
   • 【問題文】「実際の業務では,血液検査と尿検査を同一日に行えない場合がある」
   • よって「検査日 → 血液検査 ∧ 尿検査」という従属性が成り立たなくなる。
3. スキーマ改変の方針
   • “血液検査” と “尿検査” のそれぞれに専用の「検査日」を持たせる。
   • 上位から「検査日」を除去し、代わりに“評価” に関係する属性のみを (a) とする。
4. (a) の決定
   • 図６で “評価” 側に従属している「評価日」「経過月数」「目標値」が上位に残る。
   • したがって (a) = 評価日，経過月数，目標値
5. (b) と (c) の決定
   • “血液検査” サブリレーションの先頭に「検査日」を追加し、代表的な検査値として「血糖値」「HbA1c」を列挙する → (b)。
   • “尿検査” も同様に「検査日」を追加し、「尿糖」「尿たん白」を列挙する → (c)。

誤りやすいポイント

• 上位の (a) に「検査日」を残したままにする
  → 同一日に行えないという要件を満たせず失点。
• (b)(c) に「評価日」を入れてしまう
  → 評価関連属性と検査関連属性を混在させると機能従属性が崩れる。
• 検体項目を列挙する際に “HbAlc” の大文字小文字や “尿たん白” の表記を誤記する。

FAQ