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

解答の論理構成

1. 関数従属性の妥当性は、属性の意味と制約を照らして判断します。
2. ①～⑤を順に検証します。

1. 以上より、誤っているのは「③」であるため模範解答と一致します。

誤りやすいポイント

• 「履歴保存」の有無を見落とし、属性が時間によって変わる可能性を誤判定しがちです。
• 「ログイン日時 → IPアドレス」は“日時”が主キー候補かどうかで迷いが生じますが、同時刻で多重ログインを許さない仕様ならFDが成立します。
• 「コースID → 開始日時 …」は「受講者ID」との組を主キーと思い込み、関数従属性の決定属性を余分に含めてしまうケースがあります。

FAQ

解答の導き方

• 根拠：属性説明に「受講者IDごとに発行されたログイン認証時に使用するID。システム上で一意になるように管理される。」とあります。
• 解釈と論理：この記述は（A）認証IDは各受講者IDに割り当てられるものであること、かつ（B）認証IDの値はシステム内で重複しないよう管理されることを意味します。図4の番号①は認証ID → 受講者IDを示しており（認証IDから受講者IDが一意に決まる）、上の（A）と（B）を合わせると各受講者IDに対応する認証IDは一つであると解釈できます。したがって受講者ID → 認証IDも成立します。図4には受講者ID → 認証IDの矢印は描かれていないため、これが「図中に示されていない関数従属性」の一つになります。

• 根拠：属性説明に「受講者の情報が更新された日時。受講者のパスワード、姓、名、メールアドレス、電話番号、住所は、変更が可能でその履歴が保存される。」とあります。
• 解釈と論理：ここから、パスワード等の属性は変更可能であり、変更のたびに履歴が保存されることが明示されています。履歴が保存されるということは同一の受講者IDに対して複数の更新日時（異なる更新時点）が存在し得るため、受講者ID単独ではパスワード等の値を一意に特定できません。特定の時点の値を一意に取り出すには受講者IDと更新日時の組合せが必要になります。したがって {受講者ID、更新日時} → {パスワード、姓、名、メールアドレス、電話番号、住所} が成立し、図4に明示されていない従属性となります（図4の③が単に受講者ID → パスワード等を示しているように見えても、説明文を考慮すると履歴管理のため更新日時が決定項に必要です）。

• 受講者ID → 認証ID
• ｛受講者ID、更新日時｝ → ｛パスワード、姓、名、メールアドレス、電話番号、住所｝

誤りやすいポイント

• 更新日時だけで履歴行を識別してしまう
  更新日時は全受講者間で一意とは限らないため、更新日時単独ではどの受講者の履歴行か分からない可能性があります。履歴行を一意に識別するには受講者IDとの組合せが必要です。
• 図の矢印を鵜呑みにして属性説明を無視する
  図4は「未完成」と明示されている箇所があるため、図中の従属性だけを見て決めつけず、属性説明の文（履歴が保存される等）を必ず参照してください。
• 「システム上で一意になるように管理される」の解釈を誤る
  この表現は認証IDが重複しないことを示しますが、実運用で再発行があるかどうかまでは示さないことがあります。設問文の意図は一対一対応と読むのが妥当ですが、実務設計では再発行や履歴保持の扱いを確認する必要があります。
• ログイン状態の扱いを間違える
  属性説明に「ログイン状態が変更されても履歴は保存されない」とあるため、ログイン状態に関しては更新日時等で履歴を取る前提の従属性を立てないこと。

FAQ

解答の論理構成

1. 関係スキーマ確認
   【問題文】には「受講者（受講者ID, 認証ID, パスワード、姓、名、メールアドレス、電話番号、住所、更新日時、ログイン状態）」とある。
2. 主な関数従属性整理
   図4より
   ・「① 認証ID → 受講者ID」
   ・「③ 受講者ID → パスワード、姓、名、メールアドレス、電話番号、住所」
   また「受講者ID」や「認証ID」から「更新日時」を決定する矢印は示されていない。
3. 更新履歴の影響
   属性説明で「更新日時」は“この履歴が保存される”と記載され、同一受講者について複数行が存在する設計と分かる。従って
   ・受講者ID → 更新日時 は成立しない
   ・認証ID → 更新日時 も成立しない
4. 推論
   ① ｛受講者ID, 更新日時｝
   • 受講者IDでは重複するが、更新日時を加えれば1行に特定できる。
   • 他属性は図4の従属性より受講者IDに従属し決定される。
   • 余分な属性は無く、最小。
     ② ｛認証ID, 更新日時｝
   • 認証ID単体では重複があり得るが、更新日時を加えると一意。
   • 認証ID → 受講者IDがあるため、他属性も決定可能。
   • これも最小。
     よって2組が候補キーとなる。

誤りやすいポイント

• 「受講者IDは一意だから単体で主キー」と早合点する。履歴保存の有無を確認すること。
• 「認証IDはシステム上で一意」とあるが、更新履歴により同じ認証IDでも複数行を保持し得る点を見落とす。
• 更新日時を“たまたま変化するだけの属性”と捉え、キー候補から外してしまう。

FAQ

解答の導き方

1. 受講者

• 主キー候補の決定
  図2の属性説明に「受講者の情報が更新された日時。受講者のパスワード、姓、名、メールアドレス、電話番号、住所は、変更が可能でその履歴が保存される。」とあり、各受講者について複数の更新履歴を保存する設計であるため、行を一意に識別するには「受講者ID」と「更新日時」の組合せが必要です。したがって主キーを (受講者ID, 更新日時) とします。
• 図4からの関数従属性（主要なもの）
  図4は次を示しています（要点を取り出すと）：
  • 「認証ID → 受講者ID」（図4の①）
  • 「受講者ID → パスワード、姓、名、メールアドレス、電話番号、住所」（図4の③）
  • 「受講者ID → ログイン状態」（図4の上向き矢印。かつ属性説明に「ログイン状態が変更されても履歴は保存されない」）
• 部分関数従属性の判定（2NFの観点）
  主キーは (受講者ID, 更新日時) で、ログイン状態は更新履歴で保存しない属性なので「受講者IDの値だけで決まる」ことが図4で示されています。すなわち「受講者ID → ログイン状態」が成り立ち、これは主キーの真部分（受講者ID）による非キー属性の決定なので部分関数従属性あり。よって2NFを満たさず、最高でも第1正規形です。
• 推移的関数従属性の判定（3NFの観点）
  図4の①「認証ID → 受講者ID」はありますが、属性説明に「認証ID … システム上で一意になるように管理される」とあるため認証IDは候補キー的（prime）属性と扱えます。推移的従属性が問題となるのは「非キー属性Aがさらに別の非キー属性Bを決定する」場合です。ここでは認証IDが非キー属性の中間になっているわけではなく（候補キー／準キーの性質をもつため）、図4に示されたほかの非キー→非キーの連鎖はありません。したがって推移的関数従属性はなしと判断します。
• 結論（受講者）
  正規形：第1正規形
  部分関数従属性：あり（具体例：受講者ID → ログイン状態）
  推移的関数従属性：なし

1. コース

• 主キー候補の決定
  関係“コース”には受講者IDとコースIDがあり、受講者ごとに受講するコースの開始日時・終了日時・総受講時間・ログイン回数を管理します。図4の④は ｛受講者ID, コースID｝ から「開始日時、終了日時、総受講時間、ログイン回数」へ出ているので、主キーは ｛受講者ID, コースID｝ です。
• 部分関数従属性の判定
  非キー属性はいずれも ｛受講者ID, コースID｝ の組で決まり、受講者ID だけ、コースID だけで決まるものは図4にありません。部分関数従属性はありません。
• 推移的関数従属性の判定
  図4に示される従属性は ｛受講者ID, コースID｝ → （複数属性）であり、非キー属性同士での決定（非キーA → 非キーB）のチェーンは示されていません。よって推移的従属性もありません。
• 結論（コース）
  正規形：第3正規形
  部分関数従属性：なし
  推移的関数従属性：なし

1. アクセス

• 主キー候補の決定
  アクセスはログイン履歴を保存する関係です。図2の属性説明に「ログイン日時：受講者が、ログイン認証した日時。毎回、ログイン認証時のIPアドレスの履歴が保存される。」とあり、個々のアクセス行を一意にするには (受講者ID, ログイン日時) の組合せが自然です。よって主キーは (受講者ID, ログイン日時) とします。
• 図4からの関数従属性（主要なもの）
  図4は「受講者ID → 初回アクセス日時、最終アクセス日時」（図4の②）および「ログイン日時 → IPアドレス」（図4の⑤）を示しています。
• 部分関数従属性の判定
  「初回アクセス日時」「最終アクセス日時」は受講者ごとの属性でありログイン日時に依存しないため、主キー (受講者ID, ログイン日時) に対して受講者IDのみで決まります。つまり部分関数従属性あり（具体例：受講者ID → 初回アクセス日時, 最終アクセス日時）。したがって2NFを満たさず、第1正規形です。
• 推移的関数従属性の判定
  「ログイン日時 → IPアドレス」は図4に示されていますが、ログイン日時は主キーの一部（素属性／prime）なので、主キー→（素属性）→非キー のような「主キーから非キーを経由して別の非キーを決める」典型的な推移的従属性には該当しません。したがって推移的関数従属性はなしと判断します。
• 結論（アクセス）
  正規形：第1正規形
  部分関数従属性：あり（具体例：受講者ID → 初回アクセス日時、最終アクセス日時）
  推移的関数従属性：なし

• 受講者：第1正規形、部分関数従属性あり（受講者ID → ログイン状態）、推移的関数従属性なし
• コース：第3正規形、部分関数従属性なし、推移的関数従属性なし
• アクセス：第1正規形、部分関数従属性あり（受講者ID → 初回アクセス日時、最終アクセス日時）、推移的関数従属性なし

誤りやすいポイント

• コースの主キーを コースID 単独としてしまう誤り。図4の④は ｛受講者ID, コースID｝ から出ており、受講者ごとのコースの受講状況を表しています。
• 「更新日時があるから全属性が更新履歴でバージョン管理される」と思い込み、主キーを誤る点。属性説明に「ログイン状態が変更されても履歴は保存されない」など履歴保存の有無が明記されている箇所を必ず確認してください。
• 認証ID → 受講者IDのような関数従属性を見て「推移的従属性がある」と判断する誤り。推移的従属性は「非キー属性」を経由することが条件なので、認証IDが候補キー的に扱える（システム上一意に管理される）場合は問題になりません。
• ログイン日時 → IPアドレス を見て即座に「推移的」だと結論づける誤り。ログイン日時が主キーの一部（素属性）であれば推移的従属性の定義には当てはまりません。

FAQ

解答の導き方

1. 元表と主キーの確認
   問題文の関係定義から、出題関係には「大問ID、中問番号、中問ID、小問番号、小問ID、大問作成日時、出題回数、最終出題日時、中問作成日時、コースID、制限時間、中問名称、導入文、評価方式、難易度」などの属性が含まれます（図2）。また図1に「中問番号、小問番号」が「大問の中の中問の順番、及び中問の中の小問の順番」であるとあることから、ある大問における特定の小問を一意に識別する組は「大問ID、 中問番号、 小問番号」です。よって元表の主キーを K = （大問ID、 中問番号、 小問番号） と定めます。
2. 図5から読み取れる関数従属性（決定関係）を整理する
   図5の矢印の向きと属性の意味から、元表内で主に次の決定関係（関数従属性）が成り立つと読み取れます（以下、網掛け属性は後で除外します）。

• 「中問ID」 → 「中問作成日時、 コースID、 制限時間」
  （図5の中央から中問に関する属性群へ矢印が伸びていることと、属性の意味「中問を作成した日時」等から中問IDがこれらを決めると判断できます。）
• （中問ID、 小問番号） → 小問ID
  （図5で中問IDと小問番号の組が小問IDへ向かう矢印になっているため、同一の中問内での小問番号が小問IDを決定します。）
• （大問ID、 中問番号） → 中問ID
  （図5左上の「中問番号／大問ID」から中央へ矢印が伸びているため、ある大問の中の位置（中問番号）がどの中問IDを参照するかを決めます。）
• 大問ID → 大問作成日時、出題回数、最終出題日時
  （「大問作成日時」は「大問を作成した日時」であり、出題回数・最終出題日時も大問ごとの集計値なので、大問IDで一意に決まります。図5ではこれらが大問レベルの属性として示されています。）

1. 部分従属性・推移的従属性の検出（第2正規形・第3正規形へ向けて）
   元の主キーK = （大問ID、 中問番号、 小問番号）に対して、

• （大問ID、 中問番号） はKの真部分集合であり、これが中問IDを決定しています。したがって中問IDはKに対して「部分従属性」を持ち、2NFを満たしていません。
• 中問ID → 中問作成日時 等があるため、K → 中問ID → 中問作成日時 のような「推移的従属性」も生じます。これを放置すると3NFに違反します。
• また、小問IDは（中問ID、 小問番号） で決まるため、これも別関係に分離すべき対象です。

1. 分解手順（部分従属性と推移的従属性の除去）
   上の関数従属性に基づき、次のように分解します（図5で網掛けされていない属性のみを用いる）。

• 中問に関する属性は中問IDに完全に従属するので、これを独立した関係にする：
  中問（中問ID、中問作成日時、コースID、制限時間）
  根拠：中問ID → 中問作成日時, コースID, 制限時間 （図5の中央矢印）
• 中問内の小問の並びとライブラリ小問IDの対応は中問IDと小問番号の組で決まるので：
  中問小問（中問ID、小問番号、小問ID）
  根拠：（中問ID、小問番号） → 小問ID（図5）
• 大問内での中問の順序と中問IDの対応は大問IDと中問番号の組で決まるので：
  大問中問（大問ID、中問番号、中問ID）
  根拠：（大問ID、中問番号） → 中問ID（図5）
• 大問レベルの属性（大問作成日時）は大問IDに従属するため、大問単位の関係を残す：
  出題（大問ID、大問作成日時）
  根拠：大問ID → 大問作成日時（属性の意味と図5の配置）

誤りやすいポイント

• 図中の矢印元＝必ずしも「候補キー」と決めつけない。矢印は「決定項（determinant）」を示すが、その決定項が元表全体の候補キーかどうかは別に検討する必要があります（例：中問IDは中問属性を決めるが、出題全体の候補キーではない場合がある）。
• 元表の主キーを明示しないまま分解を進めると、どの従属性が「部分従属性」か判別できず誤った分解になる。必ず元の主キー（ここでは「大問ID、 中問番号、 小問番号」）を書いて部分従属性を確認してください。
• 網掛け（図5）の指示を無視して属性を残すと設問の要求に反する。設問が「図5中で網掛けされていないものだけを記述せよ」としている場合は、網掛け属性（今回なら「導入文」「難易度」「出題回数」「最終出題日時」など）を出力に含めないこと。
• 推移的従属性の見落とし（例：K → 中問IDと 中問ID → 中問作成日時 があるとき、中問作成日時 は中問IDを別関係に分離しないと3NF違反になる）に注意すること。

FAQ

解答の論理構成

1. 【問題文】図2で“答案”は
   「答案（受講者ID, 大問ID, 小問ID, 解答日時、解答時間、解答回数、評点、解答、得点）」
   である。
2. 【問題文】図6が示す主な関数従属性は
   • 「受講者ID」「大問ID」で決まる「解答回数」
   • 「受講者ID」「大問ID」「解答日時」で決まる「解答時間」「評点」
   • 「受講者ID」「解答日時」「小問ID」で決まる「解答」「得点」
3. まず候補キーを探索する。
   • 上記3本を合わせると「受講者ID, 大問ID, 解答日時、小問ID」が全属性を決定し、かつ最小であるため候補キー。
4. 部分関数従属性と推移的関数従属性の排除
   • 「解答回数」はキーの真部分集合 {受講者ID, 大問ID} に従属 → 第2正規形違反。
   • 「解答時間」「評点」は {受講者ID, 大問ID, 解答日時} に従属 → 同様に部分従属。
   • 「解答」「得点」は {受講者ID, 解答日時、小問ID} に従属 → 同様に部分従属。
5. よってそれぞれを独立した関係に分解。
   • {受講者ID, 大問ID} を主キーとする「回数」へ「解答回数」を分離。
   • {受講者ID, 大問ID, 解答日時} を主キーとする「採点」へ「解答時間」「評点」を分離。
   • {受講者ID, 解答日時、小問ID} を主キーとする「解答」へ「解答」「得点」を分離。
6. 3つの関係はいずれも
   ・候補キー以外の属性が全て候補キーに対し非推移的完全従属
   であり、第3正規形の定義を満たす。

誤りやすいポイント

• 「解答日時」はタイムスタンプだから単独で一意と誤解し、候補キーを縮小しすぎる。
• 第2正規形で“部分従属”を、主キー全体ではなく「真部分集合」に着目することを忘れる。
• 「解答回数」を「受講者ID」「解答日時」で決まると勘違いし、無意味な関係を作る。
• 正規形の判定をBCNFと混同し、「回数」を作らずまとめてしまう。

FAQ

解答の論理構成

• 【問題文】の図７には、
  「小問ID」「小問タイプ」「連番」などの属性間に二つの特殊な関数従属性 (A)(B) が描かれています。
• まず (A) は、図中で「小問ID」から上向き矢印が出て「小問タイプ」に接続されています。これは
  「小問（小問ID, 小問タイプ, …）」という関係スキーマにおいて
  “小問ID → 小問タイプ”
  の関数従属性が成立していることを示します。したがって文中(a)には「小問タイプ」が入ります。
• 次に (B) は、「小問タイプ」から点線で４種類の属性グループ
  「問文章／解文章」「最大値／最小値」「○解答／×解答」「問文リスト／解文リスト」
  へつながっています。これは
  “小問タイプ → {そのタイプ特有の全ての属性名}”
  という集合値の関数従属性を意味します。よって文中(b)は、タイプごとに決まる“属性の組”となります。
• 属性名が決まったあとは、各行（レコード）で保持される“属性値”が一意に対応します。ゆえに文中(c)には「属性値」が入ります。

誤りやすいポイント

• 「小問ID → 小問タイプ」を見落とし、(a) に「連番」など他の属性を書いてしまう。
• (B) を通常の単一属性の関数従属性と勘違いし、(b) に「属性名」と単数形で記入する。
• (c) に「データ」や「内容」といった曖昧語を入れて減点される。

FAQ

解答の導き方

1. 図8の構成要素を確認します。上段に「小問タイプ」、中段に「小問ID」「属性名」、下段に「属性値」があります。問題文に「属性名は小問タイプごとに定義され、異なる小問タイプ間で同じ属性名が使われることがあり得る」とあるため、属性名は小問タイプにスコープされる（タイプごとにどの属性名が定義されるかが決まる）ことが読み取れます。
2. 図2の関係スキーマ等から「小問」には小問IDと小問タイプの対応が存在することがわかるので、まず次の関数従属性が成り立ちます。
   「小問ID」 → 「小問タイプ」
   理由：各小問IDは一つの小問タイプを持つため、小問IDでそのタイプが一意に決まります。
3. 属性値（実際の値）は、同じ「属性名」でも異なる小問（異なる小問ID）で異なり得ます。したがって属性値は単に「属性名」だけで決まるわけではなく、どの小問についての値かを示す「小問ID」と合わせて一意に決まります。従って次が成り立ちます。
   {「小問ID」、「属性名」} → 「属性値」
   重要点：ここで「属性名」 → 「属性値」としてしまうのは誤りです。属性値は小問ごとに異なり得るため、必ず小問IDと属性名の組で決まります。
4. なお、「属性名は小問タイプごとに定義される」ことは、小問タイプと属性名の組を管理する関係（関係“小問タイプ属性”）で表されます。小問タイプが決まっても属性名は一つに決まらない（一つの小問タイプに複数の属性名がある）ので、「小問タイプ → 属性名」という関数従属性はありません。図8に矢印を引くことはしません。
5. 以上をまとめると、もし図8を一つの関係で表すとR(小問ID, 小問タイプ, 属性名, 属性値) となり、主要な関数従属性は次の二つです。
   • 小問ID → 小問タイプ
   • {小問ID, 属性名} → 属性値
6. 正規化（第3正規形）への分解手順：
   • キー候補を求めると、{小問ID, 属性名} が全属性を決定するので候補キーは {小問ID, 属性名} です。
   • しかし部分従属性が存在します。すなわち小問ID（候補キーの部分集合）が小問タイプを決定する（小問ID → 小問タイプ）。このためRは第2正規形を満たさず分解が必要です。
   • 分解の方針は、部分従属性（小問ID → 小問タイプ）を分離し、さらに「属性名は小問タイプごとに定義される」ことを保持するため、次の三つの関係に分解します。
7. 第3正規形に分解した関係スキーマ（主キーは下線で示します）：
   • 小問タイプ属性（小問タイプ、属性名）
     理由：小問タイプごとに定義される属性名を保持します。属性名はタイプ内で一意です。
   • 小問タイプ属性値（小問ID、属性名、属性値）
     理由：各小問（小問ID）について、タイプで定義された属性名ごとの値を保持します。主キーは (小問ID, 属性名) です。
   • 小問タイプ（小問ID、小問タイプ）
     理由：小問IDからその小問のタイプを一意に決定します。
8. 各関係が第3正規形であることの確認（要点）：
   • 小問タイプ：主キーは小問ID。小問タイプは主キーに対する完全従属性で、非キー属性間の従属性はありません。
   • 小問タイプ属性：複合主キー (小問タイプ, 属性名) のみで他に非キー属性がない（または非キー属性があっても主キーに従属）ため3NFです。
   • 小問タイプ属性値：主キーは (小問ID, 属性名) で属性値は主キーに完全従属します。小問タイプはこの関係に含めていないため、小問ID → 小問タイプ による伝達的従属性は発生しません。よって3NFです。
9. 図8に記入する矢印（関数従属性）をまとめると次の2本です（解答例の図と同じ）：
   • 中段左の「小問ID」から上段「小問タイプ」へ矢印（小問ID → 小問タイプ）
   • 中段の「小問ID」「属性名」を合わせて下段「属性値」へ矢印（{小問ID, 属性名} → 属性値）

誤りやすいポイント

• 「小問タイプ → 属性名」の矢印を引いてしまう誤り。一つの小問タイプには複数の属性名があるので、関数従属性にはなりません。
• 「属性名 → 属性値」としてしまう誤り。実際は値は小問ごとに異なり得るため、必ず {小問ID, 属性名} → 属性値 と表現する必要があります。
• 属性名をグローバルに一意と扱い「属性名」を主キーにしてしまう誤り。問題文は「属性名は小問タイプごとに定義され、異なる小問タイプ間で同じ属性名が使われることがあり得る」と明記しています。
• 主キーの見落とし：属性値関係の主キーは (小問ID, 属性名) です。小問ID単独や属性名単独にすると一意性が保てません。
• 参照整合性の扱い忘れ：小問タイプ属性値 の属性名が、その小問IDの小問タイプで定義された属性名であることを保証する制約（外部キー整合性）を設計で考慮しないと不整合が起きます。

FAQ

解答の論理構成

1. 要件の読み取り
   問題文には「“関連資格有無” など受講者ごとに固有な属性を、任意に追加登録できるように」とあります。つまり属性の種類が固定されておらず増減する。
2. 既存モデルの限界
   関係“受講者”は既に「受講者ID, 認証ID, パスワード、…」と列が確定しており、列追加はテーブル設計変更を伴います。
3. 可変属性の一般的解決策
   可変列を行として扱うメタデータ方式（属性名・属性値方式）にすれば、列追加が不要で要件を満たせます。
4. 属性選定
   ・「受講者ID」：親エンティティとの関連を示す外部キー
   ・「属性名」：例として「関連資格有無」などを格納し可変属性を識別
   ・「属性値」：その具体的な内容
5. 主キー設定
   「同一受講者で同じ属性名は一意」の制約を表すため「受講者ID, 属性名」を主キーにする。

誤りやすいポイント

• 「属性値」を主キーに含めてしまう
  属性値は同じ値が複数行に現れる可能性があるため主キーにしてはいけません。
• 「属性名」を列として固定追加する誤解
  例えば「関連資格有無」を列追加すると、将来ほかの任意項目に再びDDL変更が必要になります。
• 「受講者ID」単独主キーにする
  これでは同一受講者に複数の追加属性が登録できず要件を満たしません。

FAQ