データベーススペシャリスト 2010年 午後1 問01
データベースの基礎理論に関する次の記述を読んで、設問1〜3に答えよ。
H社は、各種の資格試験対策の通信教育事業を展開している。H社では,eラーニングを取り入れたサービスを新たに提供するために、受講者が、資格試験対策の模擬試験を Web から受験できるシステム(以下、本システムという)を構築することにした。そこで、受講者、出題及び答案などを管理するデータモデルの検討を次のように行った。
模擬試験問題の出題形式は、図1の例に示すとおり大問、中間、小問の階層構造で、大問は、中間の集まりであり、中間は、小間の集まりである。
各受講者は、過去に出題された大問か又は新規の大問から一つの大問を選択して受験する。新規の大問が選択されると、本システムは、あらかじめライブラリに登録されている中間を組み合わせて大問を動的に作成し、受講者に提示する。 小問ごとに、短文型、型、ペア合わせ型、数値型などの解答形式のタイプをもち、これを小問タイプとして管理する。
関係“受講者”、“コース”、“アクセス”、“出題”、“答案”、“小問”及び“小問タイプ属性”の関係スキーマは、図2のとおりである。 図4〜7は、図3の関数従属性の表記法に従って、属性間の主な関数従属性を表したものである。 図2, 図4〜7の主な属性とその意味及び制約を、表に示す。
将来、新しい解答形式を追加する予定なので、小問タイプのデータモデルの拡張について検討した。 図8は、今後の拡張に対応できるように変更したものである。 受講者のデータモデルについても、属性を追加できるような拡張を考えた。
設問1：図4について、(1)〜(4)に答えよ。
（1）
図中の関数従属性 ①〜⑤のうち、誤っているものを番号で答えよ。
模範解答
③
解説
解答の論理構成
- 図4の関数従属性③
【図補足情報】のとおり「受講者ID → パスワード、姓、名、メールアドレス、電話番号、住所」と示されている。 - 可変であることの確認
【問題文】に「受講者のパスワード、姓、名、メールアドレス、電話番号、住所が、変更可能なことでこの履歴が保存される。」とある。 - 関数従属性の定義
関数従属性 は、同じ 値に対して が常に 1 値に決まるときにのみ成立。 - 履歴管理との衝突
同一の「受講者ID」であっても更新のたびに「パスワード」などが変更されるため、1 対多の関係が発生し が破綻。 - 正しい従属性
「{受講者ID, 更新日時} → パスワード、姓、名、メールアドレス、電話番号、住所」が成立条件であり、③の記述は誤り。
誤りやすいポイント
- 「主キーらしき属性があれば他属性を決定する」と早合点する。
- 図内の矢印を信用しすぎ、【問題文】にある“履歴を残す/変更可能”の文言を見落とす。
- 更新履歴属性（「更新日時」「ログイン日時」等）を含めるべき従属性を、単一属性で判定してしまう。
FAQ
Q: 「④ コースID → 開始日時、終了日時、総受講時間、ログイン回数」は正しいのですか？
A: 【問題文】にはコースごとにこれらが蓄積され、履歴管理の説明がないため、「コースID」ごとに 1 行という想定で従属性は成立します。
A: 【問題文】にはコースごとにこれらが蓄積され、履歴管理の説明がないため、「コースID」ごとに 1 行という想定で従属性は成立します。
Q: 「⑤ ログイン日時 → IPアドレス」は履歴があっても成立するのですか？
A: 「ログイン日時」は毎回異なるタイムスタンプであり、その瞬間の「IPアドレス」は一意に決まるため、関数従属性は成立します。
A: 「ログイン日時」は毎回異なるタイムスタンプであり、その瞬間の「IPアドレス」は一意に決まるため、関数従属性は成立します。
関連キーワード: 関数従属性、履歴管理、第三正規形、主キー、多値依存
設問1：図4について、(1)〜(4)に答えよ。
（2）
図中に示されていない関数従属性のうち、決定項が異なる関数従属性を、二つ挙げよ。
模範解答
①：・受講者 ID→認証 ID
②：・｛受講者 ID、更新日時｝→｛パスワード、姓、名、メールアドレス、電話番号、住所｝
解説
解答の論理構成
- 図4に描かれている決定項
① 認証ID → 受講者ID
② 受講者ID → 初回アクセス日時、最終アクセス日時
③ 受講者ID → パスワード、姓、名、メールアドレス、電話番号、住所
④ コースID → 開始日時、終了日時、総受講時間、ログイン回数
⑤ ログイン日時 → IPアドレス - まだ示されていない決定項を探す
(a) 引用:「認証ID…システム上で一意」「受講者ID…一意」。一意性が双方に付与されているため、受講者ID → 認証ID が導かれる。
(b) 引用:「受講者の情報が更新された日時。受講者のパスワード、姓、名、メールアドレス、電話番号、住所が、変更可能なことでこの履歴が保存される。」履歴を区別できるのは 更新日時 であり、受講者ID 単独ではこれら可変属性を一意に決定できない。よって {受講者ID, 更新日時} → {パスワード、姓、名、メールアドレス、電話番号、住所} が必要。 - 決定項が図4の①〜⑤と重ならないことを確認
①〜⑤に 受講者ID → 認証ID と {受講者ID, 更新日時} を決定項とする矢印は存在しないため、設問条件「図中に示されていない」「決定項が異なる」を満たす。
誤りやすいポイント
- 「認証ID → 受講者ID」があるからといって自動的に逆向きが成り立つと思わない受験生が多い。しかし本文に“双方が一意”と明記されているため逆向きも FD になる。
- {受講者ID} → 可変属性群 と早合点し、更新日時 を決定項に含め忘れる。履歴テーブルでは時点属性を忘れず確認する。
- 「決定項が異なる」を「派生属性が異なる」と誤読し、既に描かれている決定項を再掲して失点。
FAQ
Q: 一意性が書かれていても必ず相互 FD ですか？
A: いいえ。「一意」が両方に付与され、一対一対応であることが読み取れる場合のみ相互 FD と判断できます。本問は両方に「一意」が与えられています。
A: いいえ。「一意」が両方に付与され、一対一対応であることが読み取れる場合のみ相互 FD と判断できます。本問は両方に「一意」が与えられています。
Q: {受講者ID, 更新日時} の決定項に他の属性を含める必要は？
A: ありません。履歴行の識別は 更新日時 で十分であり、他属性はこの FD から従属します。
A: ありません。履歴行の識別は 更新日時 で十分であり、他属性はこの FD から従属します。
Q: 既存 FD の合成や推移で導けるものを書いても良い？
A: 設問は「図中に示されていない」かつ「決定項が異なる」ものを要求しています。合成・推移で得られても決定項が①〜⑤と同じなら不適切です。
A: 設問は「図中に示されていない」かつ「決定項が異なる」ものを要求しています。合成・推移で得られても決定項が①〜⑤と同じなら不適切です。
関連キーワード: 関数従属性、候補キー、履歴管理、決定項、正規化
設問1：図4について、(1)〜(4)に答えよ。
（3）
関係“受講者” の候補キーをすべて列挙せよ。
模範解答
｛受講者 ID、更新日時｝、｛認証 ID、更新日時｝
解説
解答の論理構成
- 関係スキーマ確認
【問題文】には「受講者（受講者ID, 認証ID, パスワード、姓、名、メールアドレス、電話番号、住所、更新日時、ログイン状態）」とある。 - 主な関数従属性整理
図4より
・「① 認証ID → 受講者ID」
・「③ 受講者ID → パスワード、姓、名、メールアドレス、電話番号、住所」
また「受講者ID」や「認証ID」から「更新日時」を決定する矢印は示されていない。 - 更新履歴の影響
属性説明で「更新日時」は“この履歴が保存される”と記載され、同一受講者について複数行が存在する設計と分かる。従って
・受講者ID → 更新日時 は成立しない
・認証ID → 更新日時 も成立しない - 推論
① ｛受講者ID, 更新日時｝- 受講者ID では重複するが、更新日時を加えれば 1 行に特定できる。
- 他属性は図4の従属性より受講者IDに従属し決定される。
- 余分な属性は無く、最小。
② ｛認証ID, 更新日時｝ - 認証ID 単体では重複があり得るが、更新日時を加えると一意。
- 認証ID → 受講者ID があるため、他属性も決定可能。
- これも最小。
よって 2 組が候補キーとなる。
誤りやすいポイント
- 「受講者IDは一意だから単体で主キー」と早合点する。履歴保存の有無を確認すること。
- 「認証IDはシステム上で一意」とあるが、更新履歴により同じ認証IDでも複数行を保持し得る点を見落とす。
- 更新日時を“たまたま変化するだけの属性”と捉え、キー候補から外してしまう。
FAQ
Q: 更新日時はトランザクションで自動更新されるのでキーに入れない方が良いのでは？
A: 本システムは履歴管理を目的に「更新日時」を保持していると明示されています。行を一意に識別するために必要ならキーに含めるのが正解です。
A: 本システムは履歴管理を目的に「更新日時」を保持していると明示されています。行を一意に識別するために必要ならキーに含めるのが正解です。
Q: 認証ID → 受講者ID が成り立つなら ｛認証ID｝ は候補キーになりませんか？
A: 更新日時の履歴があるため、同じ認証IDで複数行が存在します。したがって認証ID単体では一意になりません。
A: 更新日時の履歴があるため、同じ認証IDで複数行が存在します。したがって認証ID単体では一意になりません。
Q: 履歴を別テーブルに分ければ更新日時をキーに含めずに済む？
A: 設計次第で可能ですが、本問題は提示された関係スキーマに基づき候補キーを求める設問です。与件を変更してはいけません。
A: 設計次第で可能ですが、本問題は提示された関係スキーマに基づき候補キーを求める設問です。与件を変更してはいけません。
関連キーワード: 関数従属性、候補キー、履歴管理、正規化、複合キー
設問1：図4について、(1)〜(4)に答えよ。
（4）
関係 “受講者”、“コース”、“アクセス” の正規形を答えよ。 また、正規形の判別の根拠を、部分関数従属性及び推移的関数従属性の“あり”又は“なし”で示せ。“あり” の場合は、その関数従属性の具体例を示せ。
模範解答
解説
解答の論理構成
-
主キーの確認
- 「受講者」は【問題文】「受講者ID」と「更新日時」で履歴を保持するため 。
- 「アクセス」は「受講者ID」と「ログイン日時」で1回のログインを識別するので 。
- 「コース」は「受講者ID」と「コースID」で1コース受講を識別し、履歴列は存在しないため 。
-
部分関数従属性の有無
- 図4矢印①より「認証ID → 受講者ID」。よって の一部「受講者ID」が他属性を決定し、非キー属性「ログイン状態」まで導くため「受講者ID → ログイン状態」は部分関数従属性。
- 同様に②「受講者ID → 初回アクセス日時、最終アクセス日時」は「アクセス」の部分関数従属性。
- 「コース」では④「コースID → 開始日時、…」だが のもう一部「受講者ID」を欠くと一意にならない（同一コースを複数受講する可能性）。したがって部分従属性は成立しない。
-
推移的関数従属性の有無
- 図4に3段階矢印（③・⑤など）がないため、どの関係にも「Ａ → Ｂ → Ｃ」の形は確認できず“なし”。
-
正規形判定
- 部分関数従属性が残る「受講者」「アクセス」は第2正規形の条件を満たさないので第1正規形止まり。
- 「コース」は部分・推移とも“なし”で第3正規形。
誤りやすいポイント
- 「ログイン状態」は“履歴を保存しない”と書かれているため「更新日時」に依存すると誤認しやすいが、実際には図4で「受講者ID」から直接決まる。
- 「コースID → 開始日時、…」をそのまま部分関数従属性と判断すると誤答。「受講者ID」も一意決定に必要であることを見落とさない。
- 推移的関数従属性の判断で、図中の多段矢印が示されていないことを確認せず“あり”と書いてしまう。
FAQ
Q: 「更新日時」が含まれていても第1正規形で良いのですか？
A: 第1正規形は“属性が単一値である”ことが条件です。履歴を示す「更新日時」があっても、複数値格納や繰返しグループが無ければ第1正規形を満たします。問題は第2正規形以降の要件です。
A: 第1正規形は“属性が単一値である”ことが条件です。履歴を示す「更新日時」があっても、複数値格納や繰返しグループが無ければ第1正規形を満たします。問題は第2正規形以降の要件です。
Q: 「アクセス」で「IPアドレス」は推移的関数従属性になりませんか？
A: 図4⑤は「ログイン日時 → IPアドレス」です。主キー の真部分集合「ログイン日時」から決まるので部分関数従属性に近いですが、決定属性が主キーの一部ではないため推移的ではありません。
A: 図4⑤は「ログイン日時 → IPアドレス」です。主キー の真部分集合「ログイン日時」から決まるので部分関数従属性に近いですが、決定属性が主キーの一部ではないため推移的ではありません。
Q: 正規形は必ず高いほど良いのですか？
A: 高次正規形は更新異常を抑制できますが、履歴管理やパフォーマンス要件により意図的に第1・第2正規形を残す設計もあります。本問では“現状のスキーマを評価する”ことが目的です。
A: 高次正規形は更新異常を抑制できますが、履歴管理やパフォーマンス要件により意図的に第1・第2正規形を残す設計もあります。本問では“現状のスキーマを評価する”ことが目的です。
関連キーワード: 第1正規形、第3正規形、部分関数従属性、推移的関数従属性、関係スキーマ
設問2：図5,6について(1)、(2)に答えよ。
（1）
関係“出題”を、第 3 正規形に分解した関係スキーマで示せ。 関係スキーマの属性には、図5中で網掛けされていないものだけを記述せよ。
なお、主キーは、下線で示せ。
模範解答
中問（中問 ID、中問作成日時、コース ID、制限時間）
中問小問（中問 ID、小問番号、小問 ID）
大問中問（大問 ID、中問番号、中問 ID）
出題（大問 ID、大問作成日時）
解説
解答の論理構成
-
図5には次の主要な矢印が描かれている。
- 「中問番号」「大問 ID」から右方向に矢印 → 「大問作成日時」など
- 「中問番号」「大問 ID」から下方向に矢印 → 「中問 ID」「小問番号」
- 「中問 ID」「小問番号」から左方向に矢印 → 「小問 ID」
- 「中問 ID」「小問番号」から右方向に矢印 → 「中問作成日時」「コース ID」「制限時間」
-
矢印元が候補キー
• 【①】「大問 ID」⇢「大問作成日時」
• 【②】「大問 ID、中問番号」⇢「中問 ID」
• 【③】「中問 ID」⇢「中問作成日時、コース ID、制限時間」
• 【④】「中問 ID、小問番号」⇢「小問 ID」 -
第 1 正規形は満たしているので、第 2 正規形へ
- 複合キー【②】【④】で生じる部分従属性を除去するため、「大問 ID、中問番号」「中問 ID、小問番号」をそれぞれ別関係へ。
-
第 3 正規形へ
- 候補キー以外の属性間で推移従属性がないよう整理し、結果的に
• 中問（中問 ID、中問作成日時、コース ID、制限時間）
• 中問小問（中問 ID、小問番号、小問 ID）
• 大問中問（大問 ID、中問番号、中問 ID）
• 出題（大問 ID、大問作成日時）
となる。
- 候補キー以外の属性間で推移従属性がないよう整理し、結果的に
-
いずれの関係も
- すべての非キー属性が候補キーに完全従属
- 非キー属性間に推移従属なし
であるため第 3 正規形を満たす。
誤りやすいポイント
- 「中問番号」は「大問 ID」と組になって初めて一意になるのに、単独主キーと勘違いしてしまう。
- 「小問番号」は「中問 ID」との複合キーであり、「小問 ID」を主キーに取り違えるケース。
- 網掛け属性（図5でハイライトされている列）をうっかり記述して減点。
- 分解後に「大問作成日時」をどこに置くか迷い、「大問中問」に入れてしまう。
FAQ
Q: 「出題」関係を 4 つに分けたあと、元の表は復元できますか？
A: 各関係の主キー同士で外部キー参照を張れば自然結合で完全に復元可能です（損失なし分解）。
A: 各関係の主キー同士で外部キー参照を張れば自然結合で完全に復元可能です（損失なし分解）。
Q: なぜ「中問名称」や「難易度」を書かないのですか？
A: 設問に「図5中で網掛けされていないものだけを記述せよ」とあるためです。これらは網掛けされているため除外します。
A: 設問に「図5中で網掛けされていないものだけを記述せよ」とあるためです。これらは網掛けされているため除外します。
Q: 第 3 正規形ではなく BCNF まで分割すべきでは？
A: 「中問 ID」→「コース ID」のように決定する側が候補キーなので、すでに BCNF も満たしています。設問が第 3 正規形を要求しているためそこで止めています。
A: 「中問 ID」→「コース ID」のように決定する側が候補キーなので、すでに BCNF も満たしています。設問が第 3 正規形を要求しているためそこで止めています。
関連キーワード: 正規化、関数従属、候補キー、複合キー、損失なし分解
設問2：図5,6について(1)、(2)に答えよ。
（2）
関係 “答案”を、第3正規形に分解した関係スキーマで示せ。
なお、主キーは、下線で示せ。
模範解答
採点（受講者 ID、大問 ID、解答日時、解答時間、評点）
回数（受講者 ID、大問 ID、解答回数）
解答（受講者 ID、解答日時、小問 ID、解答、得点）
解説
解答の論理構成
- 【問題文】図2で“答案”は
「答案（受講者ID, 大問ID, 小問ID, 解答日時、解答時間、解答回数、評点、解答、得点）」
である。 - 【問題文】図6が示す主な関数従属性は
- 「受講者ID」「大問ID」で決まる「解答回数」
- 「受講者ID」「大問ID」「解答日時」で決まる「解答時間」「評点」
- 「受講者ID」「解答日時」「小問ID」で決まる「解答」「得点」
- まず候補キーを探索する。
• 上記3本を合わせると「受講者ID, 大問ID, 解答日時、小問ID」が全属性を決定し、かつ最小であるため候補キー。 - 部分関数従属性と推移的関数従属性の排除
• 「解答回数」はキーの真部分集合 {受講者ID, 大問ID} に従属 → 第2正規形違反。
• 「解答時間」「評点」は {受講者ID, 大問ID, 解答日時} に従属 → 同様に部分従属。
• 「解答」「得点」は {受講者ID, 解答日時、小問ID} に従属 → 同様に部分従属。 - よってそれぞれを独立した関係に分解。
• {受講者ID, 大問ID} を主キーとする「回数」へ「解答回数」を分離。
• {受講者ID, 大問ID, 解答日時} を主キーとする「採点」へ「解答時間」「評点」を分離。
• {受講者ID, 解答日時、小問ID} を主キーとする「解答」へ「解答」「得点」を分離。 - 3つの関係はいずれも
・候補キー以外の属性が全て候補キーに対し非推移的完全従属
であり、第3正規形の定義を満たす。
誤りやすいポイント
- 「解答日時」はタイムスタンプだから単独で一意と誤解し、候補キーを縮小しすぎる。
- 第2正規形で“部分従属”を、主キー全体ではなく「真部分集合」に着目することを忘れる。
- 「解答回数」を「受講者ID」「解答日時」で決まると勘違いし、無意味な関係を作る。
- 正規形の判定をBCNFと混同し、「回数」を作らずまとめてしまう。
FAQ
Q: 第3正規形とBCNFの違いは何ですか？
A: 第3正規形は「候補キーでないすべての属性が主キーに対して非推移的完全従属」であればよく、候補キー間の関数従属性は許容します。BCNFは「すべての関数従属性 X → Y で X がスーパーキーである」ことを要求するため、より厳密です。
A: 第3正規形は「候補キーでないすべての属性が主キーに対して非推移的完全従属」であればよく、候補キー間の関数従属性は許容します。BCNFは「すべての関数従属性 X → Y で X がスーパーキーである」ことを要求するため、より厳密です。
Q: 「解答回数」が {受講者ID, 大問ID} に従属するのはなぜですか？
A: 受講者が同じ大問に挑戦するたびに回数が 1,2,3… と更新されるため、同じ受講者が同一大問に対して持つ履歴は 1 本だけです。図6で「受講者ID」「大問ID」から矢印が「解答回数」へ伸びていることが根拠です。
A: 受講者が同じ大問に挑戦するたびに回数が 1,2,3… と更新されるため、同じ受講者が同一大問に対して持つ履歴は 1 本だけです。図6で「受講者ID」「大問ID」から矢印が「解答回数」へ伸びていることが根拠です。
Q: 3つの関係を作ると参照整合性はどう保ちますか？
A: 「採点」と「解答」はいずれも「受講者ID」「大問ID」または「解答日時」を含むため、外部キー制約で「回数」や「採点」から元のキーを参照すれば整合性を保てます。
A: 「採点」と「解答」はいずれも「受講者ID」「大問ID」または「解答日時」を含むため、外部キー制約で「回数」や「採点」から元のキーを参照すれば整合性を保てます。
関連キーワード: 正規化、関数従属性、主キー、第3正規形、外部キー
設問3：データモデルの拡張について、(1)〜(3)に答えよ。
（1）
図7は、小問タイプとその解答形式ごとの属性名、属性値の関係を示したものである。図中の特殊な関数従属性(A)及び(B)に関する次の記述中の(a)〜(c)に入れる適切な字句を答えよ。
模範解答
a：小問タイプ
b：属性の組
c：属性値
解説
解答の論理構成
- 「小問（小問ID, 小問タイプ、…）」より
【問題文】「小問ID, 小問タイプ、…」
ここから「小問ID → 小問タイプ」が明示されます。したがって (a) は「小問タイプ」です。 - 図7の特殊な従属性Ａ
小問タイプが“短文型”なら「問文章」「解文章」、“数値型”なら「最大値」「最小値」…と、列の集合そのものが確定します。これは単一列ではなく“列のグループ”を決めるので (b) は「属性の組」です。 - 図7の特殊な従属性Ｂ
それぞれの列（例：最大値）には実データが一意に格納されます。列が決まれば中に入る内容（バリュー）が決まるという通常の関数従属性に当たるため (c) は「属性値」です。
誤りやすいポイント
- 小問ID が直接「問文章」など具体列を決定すると誤解しがちですが、実際には「小問タイプ」を経由して列集合が確定します。
- 「属性名」と「属性値」を混同しやすいので注意してください。列そのものの名前が決まる段階と、その列に入る値が決まる段階は別です。
- “属性の組”を「複合キー」と読み違えるミスが散見されますが、本問はキーの話ではなく列集合の存在有無を問うています。
FAQ
Q: 「属性の組」は具体的に何を指しますか？
A: 小問タイプごとに現れる列集合です。例として「短文型 → {問文章、解文章}」「数値型 → {最大値、最小値}」のように、一つひとつが列名のペアやグループを表します。
A: 小問タイプごとに現れる列集合です。例として「短文型 → {問文章、解文章}」「数値型 → {最大値、最小値}」のように、一つひとつが列名のペアやグループを表します。
Q: 小問ID が直接「属性値」を決めないのですか？
A: 小問ID はまず「小問タイプ」を決定し、そのタイプが出現させる列集合（属性の組）が確定してはじめて各列が値を保持します。したがって2段階の依存構造になります。
A: 小問ID はまず「小問タイプ」を決定し、そのタイプが出現させる列集合（属性の組）が確定してはじめて各列が値を保持します。したがって2段階の依存構造になります。
Q: 図8との関係は？
A: 図8は将来拡張を見据え、属性名・属性値をメタテーブル化した例です。本設問は図7における従属性を問うもので、図8は理解を補助する参考図と捉えましょう。
A: 図8は将来拡張を見据え、属性名・属性値をメタテーブル化した例です。本設問は図7における従属性を問うもので、図8は理解を補助する参考図と捉えましょう。
関連キーワード: 関数従属性、第三正規形、メタデータ、エンティティ集合、属性値
設問3：データモデルの拡張について、(1)〜(3)に答えよ。
（2）
図8は、関係 “小間タイプ属性” で新しい解答形式の追加に対応できるようにメタ概念を導入したものである。 属性名は小問タイプごとに定義され、異なる小問タイプ間で同じ属性名が使われることがあり得るものとする。 図8の属性間の関数従属性を示す矢印を記入し、図を完成させよ。 また、解答形式の追加に対応した図8の新しい関係を、第3 正規形に分解した関係スキーマで示せ。
なお、主キーは、下線で示せ。、
模範解答
関数従属性：
関係スキーマ：小問タイプ属性（小問タイプ、属性名）
小問タイプ属性値（小問ID、属性名、属性値）
小問タイプ（小問ID、小問タイプ）
関係スキーマ：小問タイプ属性（小問タイプ、属性名）
小問タイプ属性値（小問ID、属性名、属性値）
小問タイプ（小問ID、小問タイプ）解説
解答の論理構成
- メタレベルとデータレベルを分離
- 出題インスタンスを表す「小問ID」は、どのタイプに属するかを示すだけでメタ情報を持たない。
- 解答形式ごとの項目定義は「小問タイプ」「属性名」で管理する。
- 主キーを洗い出す
- 【問題文】の「小問タイプごとに定義され」と「同じ属性名が使われることがあり得る」から、属性名はタイプと組にしないと一意にならない。
- よって関係「小問タイプ属性」の主キーは「小問タイプ、属性名」。
- 関数従属性を整理
- 小問IDは e ラーニングの運用データなので「小問ID → 小問タイプ」が成り立つ。
- インスタンスに紐づく属性値は「{小問ID, 属性名} → 属性値」。
- 正規化
- 関係 (小問ID, 小問タイプ、属性名、属性値) には
- 小問ID → 小問タイプ
- {小問ID, 属性名} → 属性値
- 主キーは {小問ID, 属性名}。
- 部分従属①が第2正規形違反なので「小問ID, 小問タイプ」を独立（表：小問タイプ）。
- 残った (小問タイプ、属性名) は推移従属を起こさないためそのまま「小問タイプ属性」とする。
- 「小問ID, 属性名、属性値」は複合キーがそのまま主キーで第3正規形を満たす。
- 関係 (小問ID, 小問タイプ、属性名、属性値) には
誤りやすいポイント
- 「属性名 → 属性値」と単属性の関数従属を設定してしまい、正規化に失敗する。
- 「小問タイプ → 属性名」が一対多だからと、これだけを候補キーと誤認する。
- 既存の図7の物理属性（最大値・最小値など）をそのまま列に残し、拡張性が失われる。
FAQ
Q: なぜ「小問タイプ属性」に「属性値」を入れないのですか？
A: 「小問タイプ属性」はメタ情報（どんな列が存在するか）だけを保持し、実データ値は「小問タイプ属性値」で小問IDごとに持つ方が、新しい解答形式を追加しても表構造を変えずに済むためです。
A: 「小問タイプ属性」はメタ情報（どんな列が存在するか）だけを保持し、実データ値は「小問タイプ属性値」で小問IDごとに持つ方が、新しい解答形式を追加しても表構造を変えずに済むためです。
Q: 第3正規形に分解した後、問い合わせ性能が落ちませんか？
A: メタ情報と運用データを分離することで更新頻度の低い表と高い表が明確になります。検索時はビューや JOIN を用い、RDBMS の索引設計で十分な性能を確保できます。
A: メタ情報と運用データを分離することで更新頻度の低い表と高い表が明確になります。検索時はビューや JOIN を用い、RDBMS の索引設計で十分な性能を確保できます。
Q: 「小問タイプ」が変更された場合、データ整合性はどう保ちますか？
A: 「小問タイプ」表の主キー「小問ID」を参照整合制約で他表に連鎖更新・削除させることで保証できます。
A: 「小問タイプ」表の主キー「小問ID」を参照整合制約で他表に連鎖更新・削除させることで保証できます。
関連キーワード: 関数従属性、主キー、正規化、第3正規形、メタデータ
設問3：データモデルの拡張について、(1)〜(3)に答えよ。
（3）
図2の関係“受講者”について、“関連資格有無” など受講者ごとに固有な属性を、任意に追加登録できるように、関係スキーマを追加することにした。追加する関係 “受講者追加属性” を適切な三つの属性からなる関係スキーマで示せ。
なお、主キーは、下線で示せ。
模範解答
受講者追加属性（受講者ID、属性名、属性値)
解説
解答の論理構成
- 要件の読み取り
問題文には「“関連資格有無” など受講者ごとに固有な属性を、任意に追加登録できるように」とあります。つまり属性の種類が固定されておらず増減する。 - 既存モデルの限界
関係“受講者”は既に「受講者ID, 認証ID, パスワード、…」と列が確定しており、列追加はテーブル設計変更を伴います。 - 可変属性の一般的解決策
可変列を行として扱うメタデータ方式（属性名・属性値方式）にすれば、列追加が不要で要件を満たせます。 - 属性選定
・「受講者ID」：親エンティティとの関連を示す外部キー
・「属性名」：例として「関連資格有無」などを格納し可変属性を識別
・「属性値」：その具体的な内容 - 主キー設定
「同一受講者で同じ属性名は一意」の制約を表すため「受講者ID, 属性名」を主キーにする。
誤りやすいポイント
- 「属性値」を主キーに含めてしまう
属性値は同じ値が複数行に現れる可能性があるため主キーにしてはいけません。 - 「属性名」を列として固定追加する誤解
例えば「関連資格有無」を列追加すると、将来ほかの任意項目に再びDDL変更が必要になります。 - 「受講者ID」単独主キーにする
これでは同一受講者に複数の追加属性が登録できず要件を満たしません。
FAQ
Q: メタデータ方式にすると検索性能が落ちませんか？
A: 属性名にインデックスを張る、EAV専用のビューを用意するなどで実運用上の性能は確保できます。列追加のたびにDDL変更が不要になるメリットが上回るケースが多いです。
A: 属性名にインデックスを張る、EAV専用のビューを用意するなどで実運用上の性能は確保できます。列追加のたびにDDL変更が不要になるメリットが上回るケースが多いです。
Q: 既存の「受講者」テーブルと正規化の関係は？
A: 「受講者追加属性」は「受講者ID」で「受講者」に従属しており、第3正規形を保てています。可変列を行として扱うため、非キー属性間の関数従属性も存在しません。
A: 「受講者追加属性」は「受講者ID」で「受講者」に従属しており、第3正規形を保てています。可変列を行として扱うため、非キー属性間の関数従属性も存在しません。
関連キーワード: 可変属性、メタデータ、複合主キー、第3正規形、EAVモデル
