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

解答の論理構成

1. 主キーの決定
   • 【問題文】では「患者ID」は「地域で患者を一意に識別する記号」と明記されています。さらに「登録日」は「患者の情報を新規に登録、又は最後に更新した日付」です。更新のたびに重複行が発生するので、行を一意に識別する最小属性集合は
     ｛「患者ID」、「登録日」｝
     です。ここが“患者”関係の候補キーになります。
2. “患者ID”だけで決まる属性
   • 「性別」は「登録日による変更はない。」と説明されています。したがって
     「患者ID」 → 「性別」
   • 「生年月日」は医学的に不変なので同様に
     「患者ID」 → 「生年月日」
3. 「登録日」も絡む属性
   • 「患者名」「患者住所」「家族構成」「職業等」は更新のたびに内容が変わる可能性があるため、候補キー全体で決まります。
     ｛「患者ID」、「登録日」｝ → 「患者名」、「患者住所」、「家族構成」、「職業等」
4. 派生データの扱い
   • 「年齢」は「登録日現在の患者の年齢」です。よって
     ｛「生年月日」、「登録日」｝ → 「年齢」
     図では「生年月日」と「登録日」を一本の水平枠でくくり、そこから「年齢」へ矢印を伸ばして表現しています。
5. 階層（ネスト）された関係の分解
   • 「家族構成（〔同居人数、連絡窓口〕）」は外枠「家族構成」から内部属性へ矢印を引き
     「家族構成」 → 「同居人数」、「連絡窓口」
   • 「職業等（〔職種、通勤手段、徒歩時間〕）」も同様に
     「職業等」 → 「職種」、「通勤手段」、「徒歩時間」
   • これにより、ネストされた内部属性が外側の集合属性に完全従属していることを示します。
6. 図３完成形のまとめ
   • 上記①〜⑤を矢印で可視化すると、模範解答のように
     • 「患者ID」から上へ「職業等」、下へ「家族構成」
     • 「職業等」から右へ３属性
     • 「家族構成」から右へ２属性
     • ｛「生年月日」、「登録日」｝から左へ「年齢」
     • 「患者ID」→「性別」「生年月日」
     • ｛「患者ID」、「登録日」｝→「患者名」「患者住所」
     が配置され、関係 “患者” の主要な関数従属性がすべて表現できます。

誤りやすいポイント

• 「年齢」は「生年月日」だけで決まると勘違いし、「登録日」を忘れる。
• 候補キーを「患者ID」のみと見なしてしまい、更新履歴が区別できなくなる。
• ネストされた「家族構成」「職業等」を個々の内部属性と直接結び付け、外側の集合属性を中継しない図を書いてしまう。
• 「患者名」「患者住所」を「患者ID」だけで決まると誤解して矢印を逆向きに描く。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の導き方

• 矢印①（図4）: 患者ID → 紹介先（病院名、住所、担当医、担当スタッフ）
• 矢印②（図4）: 患者ID → 病院名、住所、担当医、担当スタッフ（右端の病院情報へ直接伸びる矢印）
• 矢印③（図4）: 患者ID → 紹介元（病院名、住所、担当医、担当スタッフ）
• 矢印④（図4）: 患者ID → 退院日
• 矢印⑤（図4）: 患者ID → 入院日
• 矢印⑥（図4）: 入院日 → 身長、体重、BMI、体脂肪率、HbA1c
• 矢印⑦（図4）: 退院日 → 身長、体重、BMI、体脂肪率、HbA1c

• 矢印⑤（患者ID → 入院日）と矢印⑥（実際には {患者ID, 入院日} → 測定値）をそのまま連結して「患者ID → 入院日 → 測定値」の推移的従属性に帰着させることはできません。
• 同様に矢印④・⑦についても、退院日に関する矢印の構造は測定値が患者IDと退院日の組で決まることを示しており、退院日単独が中間属性として他の非キー属性を決定するような推移は図示されていません。
• また紹介先／紹介元については患者IDから直接（①～③）決定されており、中間属性を介した推移的な従属性の例にはなりません。

誤りやすいポイント

• 矢印⑥・⑦を「入院日単独 → 測定値」と読み、矢印⑤（患者ID → 入院日）と結びつけて即座に「患者ID → 入院日 → 測定値」の推移的従属性があると誤判断する。正しくは図2の表記法と図4の枠の重なりを参照し、測定値は患者IDと日付の組に依存すると解釈する必要があります。
• 破線枠（紹介先／紹介元）と右端の病院情報ブロックの関係を混同し、矢印①～③の意味を取り違える。破線枠はネストされたサブ構造を示すので、親→破線枠→その中の属性 という読み方を行うこと。
• 「K→A→Bが見えたら必ず推移的従属性」と扱ってしまう誤解。Aが候補キーの一部（プライム属性）である場合や、図示が複合依存を示す場合は当てはまりません。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

1. 前提整理
   • 関係 “診療” には、識別用の「患者ID」、日付属性「診断日」「指導日」、および治療・指導に関わる属性群（「主診断名」「発症日」「糖尿病の病型」「網膜症」…「薬品名」「調理担当」…）が含まれています。
   • 図5の矢印より、主な関数従属性は次の3系統に大別できます。
     ① ｛「患者ID」、「診断日」｝ → ｛診断、合併症、治療内容｝
     ② ｛「患者ID」、「指導日」｝ → ｛生活指導｝
     ③ 「薬物療法」 → 「薬品名」
2. 分割後の各関係で保持される関数従属性
   (1) 診療・診断（患者ID、診断日、主診断名、発症日、糖尿病の病型）
    → ①の右辺（診断）のみを含むため、決定属性はそのまま｛患者ID、診断日｝。
   (2) 合併症（患者ID、診断日、網膜症、神経障害、じん症、その他）
    → ①の右辺（合併症）のみを含むため、決定属性は同じく｛患者ID、診断日｝。
   (3) 治療・指導
     – 「食事療法」「運動療法」は ① で決まる。
     – 「調理担当」「指示カロリー」「自己血糖測定有無」「測定器」は ② で決まる。
     – 「薬品名」は ① → 薬物療法 と ③ の合成で決まるが、多値（＊）を許すため行を一意にするには「薬品名」自体を含める必要がある。
     – よって３系統すべてを同時に識別できる最小集合は｛患者ID、診断日、指導日、薬品名｝。
3. 以上より候補キーは次のとおりです。
   • 診療・診断：｛患者ID、診断日｝
   • 合併症：｛患者ID、診断日｝
   • 治療・指導：｛患者ID、診断日、指導日、薬品名｝

誤りやすいポイント

• 「薬品名」は多値属性なので、「患者ID」と「診断日」だけでは一意にならない事実を見落としがちです。
• 「指導日」が関数従属性②の決定側にあることを忘れ、｛患者ID、診断日、薬品名｝をキーにしてしまう誤答が頻出します。
• 図5の矢印は “部分集合” ではなく “決定 → 被決定” を表すため、矢印の向きを読み違えると候補キー判定が狂います。

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. 主キーの構成
   • 指導に関する情報を一意にするために、主キーには指導を識別する属性（指導日など）が含まれます。
3. 挿入操作時の問題
   • 診断して治療方針は決まっても、まだ指導を行っていない段階では、主キーの一部となる指導の情報が決まりません。主キーの値が欠けたタプルは登録できないので、診断・治療の情報を先に登録しておくことができません。
4. したがって関係“治療・指導”は「診断しても、指導を行わないと情報を登録できない」という挿入時の問題を抱えます。

誤りやすいポイント

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

FAQ

解答の導き方

1. 分割対象と図から読み取るべき事実の整理

• 問題文（図1）で扱う対象は、関係「診療」であり、主要な属性に「患者ID」、「診断日」、「指導日」、および「診断（主診断名、発症日、糖尿病の病型）」、「合併症（網膜症、神経障害、じん症、その他）」、「治療内容（食事療法、運動療法、薬物療法（＊薬品名））」、「生活指導（調理担当、指示カロリー、自己血糖測定有無、測定器）」が含まれていることが示されています。
• 注1に「＊：複数の値又は値の組を取り得ることを表す」とあるので、薬物療法の「＊薬品名」は同一の診断に対して複数の薬品を持ち得ることを意味します。

1. 図5の矢印から属性間の関数従属性を読み取る（図の矢印の意味をそのまま関係に適用）

• 図5では「診断日」から破線枠「診断」へ矢印が伸び、「診断日」から破線枠「治療内容」へ矢印が伸びています。また破線枠「治療内容」から薬物療法（破線）を経て「*薬品名」へつながっています。一方、「指導日」から破線枠「生活指導」へ矢印が伸びています。
• ただし、図で単に「診断日」と示されている決定子を、リレーション全体の文脈でそのまま単独キーと解釈するのは危険です。異なる患者で同じ日付が起こり得るため、患者ごとの診療イベントを一意に特定するためには「患者ID」を含めて考えるのが妥当です。したがって図5の矢印は実務上および正規化の観点から次のように解釈します。
  • {患者ID, 診断日} → 主診断名, 発症日, 糖尿病の病型
  • {患者ID, 診断日} → 網膜症, 神経障害, じん症, その他（合併症群）
  • {患者ID, 指導日} → 調理担当, 指示カロリー, 自己血糖測定有無, 測定器（生活指導群）
  • {患者ID, 診断日} → 食事療法, 運動療法（治療内容の単-valued要素）
  • {患者ID, 診断日} → 薬品名 の集合（薬物療法は多値属性であり、同一診断に対して複数の薬品を持ち得る）

1. 正規化上の問題点と分割方針

• 多値属性の扱い：注1により「＊薬品名」は多値になり得るため、そのまま一属性に複数値を格納すると第1正規形に反します。多値性は別関係として表現し、各薬品を1行1値で表す必要があります。
• 異なる日時（診断日／指導日）に依存する属性が同一関係に混在しているため、部分従属や推移的従属、更新異常を招きやすい点を解消する必要があります。
• 方針：図5で示された決定子（診断日／指導日に相当）ごとに、その決定子が決定する属性群を独立した関係に分ける。薬品名は多値なので、診断単位で薬品毎の行を持つ関係に分離する。

1. 分割の手順（具体的）と主キーの決定

• 生活指導の分離
  • 根拠：図5の「指導日」→「生活指導」の矢印。生活指導の属性群は指導日単位で決まる。
  • 新関係：生活指導（患者ID、指導日、調理担当、指示カロリー、自己血糖測定有無、測定器）
  • 主キー：{患者ID, 指導日}。この主キーが非キー属性（調理担当等）を完全に決定するため、第3正規形となる。
• 治療内容（診断単位）の分離
  • 根拠：図5の「診断日」→「治療内容（食事療法、運動療法、薬物療法）」。食事療法・運動療法は診断単位で単一値。
  • 新関係：治療内容（患者ID、診断日、食事療法、運動療法）
  • 主キー：{患者ID, 診断日}。この主キーが食事療法・運動療法を完全に決定するため、第3正規形となる。
• 薬物療法（多値の薬品名）の分離
  • 根拠：図5の流れ（診断日→治療内容→薬物療法→＊薬品名）と注1による多値性。薬品名は同一診断に対して複数取り得るため、各薬品を1行で持つ関係にする。
  • 新関係：薬物療法（患者ID、診断日、薬品名）
  • 主キー：{患者ID, 診断日, 薬品名}。これにより1行で1処方薬を表現し、{患者ID, 診断日} が薬品名の集合を決める多値従属性を関係分解で解消する（1NFおよび第3正規形に適合）。

1. 最終的な分割（第3正規形）

• 生活指導（患者ID、指導日、調理担当、指示カロリー、自己血糖測定有無、測定器）
• 治療内容（患者ID、診断日、食事療法、運動療法）
• 薬物療法（患者ID、診断日、薬品名）

1. 各関係が第3正規形であることの確認（要点）

• 各関係の非キー属性はその関係の主キーに対して完全従属している（部分従属なし）。
• 非キー属性間で他の非キー属性を決定する推移的従属は存在しない。
• 薬物療法は多値属性を行分解することで1NFを満たし、かつキーが明示されているため第3正規形である。

誤りやすいポイント

• 「診断日」を単独で決定子とする誤り
  • 図の矢印は「診断日」→…と示されるが、複数患者で同じ日付があり得るため、リレーション全体では必ず「患者ID」を含めた {患者ID, 診断日} を決定子として扱う必要があります。単独解釈はFDの過大評価になります。
• 「薬品名」を食事療法・運動療法等を含む複合キーの一部として誤って扱うこと
  • 薬品名は多値属性であり、食事療法・運動療法が薬品名を決めるとする根拠は図5にありません。薬品名は診断単位で複数取るため、薬品名を別関係にして主キーを {患者ID, 診断日, 薬品名} とするのが正しい扱いです。
• 多値属性をそのまま残す（1NF違反）あるいは単にカンマ区切りで格納する誤り
  • そのままにすると検索・更新で異常が起きるため、薬物療法は行分解すること。
• 主キーを明示せず「主キーに追加する」とだけ書く曖昧さ
  • どの関係のどの主キーに何を追加するのかを明確に記述する必要があります（例：薬物療法関係を新設し、複合主キーを {患者ID, 診断日, 薬品名} とする）。
• 診断関連（診断日基準）と指導関連（指導日基準）を混ぜたままにして正規化を怠ること
  • 異なるイベント単位が混在すると部分従属・更新異常が残るため、イベント単位で分離する。

FAQ

解答の導き方

1. 「検査日」「評価日」が (a) に入る理由
   図6の中央に二重矩形があり、その内部に上部が「検査日」、中央が「患者ID」、下部が「評価日」と配置されています。図上でこれらが同じ大矩形内にあることは、同一の関係スキーマの属性であることを示します。さらに「検査日」から血液検査・尿検査へ、「評価日」からアキレス腱反射へ矢印が伸びていることから、これらの日付属性が各検査・評価を決定するトリガーとして関係内に含まれていると読み取れます。したがって「評価日」「検査日」は (a) に含めます。
2. 「経過月数」「目標値」が (a) に入る理由
   図6では「患者ID」から右向きに矢印が枝分かれして「経過月数」へつながり、さらに「経過月数」から右上向きに矢印が伸びて「目標値」へ至っています。図2の表記法からこれは「患者ID → 経過月数」および「経過月数 → 目標値」を意味し、経過月数と目標値が同じ関係内の属性であることを示します。表の説明に「経過月数は指導日から起算した月数」とありますが、属性をどの関係に格納するかは図6の配置で決まるため、図6に従って「経過月数」「目標値」を「経過・評価」の属性として扱います。以上より (a) は「評価日、検査日、経過月数、目標値」と判断します。
3. (b) 血液検査の属性の読み取り
   図6で「検査日」から左向きに矢印が伸びて点線枠「血液検査」に接続され、その実線枠内に「血糖値」「HbA1c」などが示されています。問題文に「図6中の網掛け部分の属性は省略」とあるため、網掛け（灰色）項目は記述せず、非網掛けの主要項目として (b) は「血糖値、HbA1c」とします。
4. (c) 尿検査の属性の読み取り
   図6で「検査日」から右向きに矢印が伸び点線枠「尿検査」に接続され、実線枠内に「尿糖」「尿たん白」が示されています。したがって (c) は「尿糖、尿たん白」とします。
5. (d) アキレス腱反射の属性の読み取り
   図6で「評価日」から下向きに矢印が伸び点線枠「アキレス腱反射」に接続され、実線枠内に「右」「左」が示されています。したがって (d) は「右、左」とします。

誤りやすいポイント

• 「経過月数」が「指導日から起算」とあるため自動的に診療側（診療）の属性と判断してしまうこと。図6の配置が格納先を示すため、図に従って判断する必要があります。
• 図6の網掛け（灰色）項目を含めてしまうこと。設問は「網掛け部分の属性は省略」と明記しています。
• 矢印の向きを逆に解釈すること。図2の表記法では矢印は決定関係（従属性）の向きを示します。
• 属性名の表記を変えてしまうこと（例：「尿タンパク」など）。問題中の属性名を原文どおりに記述することが重要です。
• 「検査日」「評価日」をイベント扱いして関係属性に含めない誤り。図6ではこれらが関係の属性として図示されています。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ