データベーススペシャリスト 2009年午前2 問05

問題文

属性間の従属関係を次のように表記するとき、属性a~eで構成される関係を第3正規形にしたものはどれか。

🖊️ 解答を隠して解いてみる

選択肢

ア：

イ：

ウ：

エ：（正解）

🔒 解説は解答すると表示されます

第3正規形分解【午前2解説】

正解の理由

与えられた関数従属性は整理すると次のとおりです。
a → b, c, d, e（aが全属性を決定）
b ↔ c（b→cとc→bの双方向）
d → c
b → e

ここからaが単一属性で全属性を決定するため、主キーは属性aのみであり、部分従属（主キーの一部に依存する非キー属性）は存在しません。問題となるのは非キー属性間の従属（相互依存・推移的従属）です。選択肢のうちエの分解はこれらの非キー属性間の依存を分離し、各分割スキーマで「非キー属性がそのスキーマの主キーにのみ依存する」構成を作ります。分解は元の従属性を保存（各FDが単一の関係に含まれるか、分解後の関係群のFDから推論できる）しており、各部分スキーマが第3正規形の条件を満たします。したがってエが正答です。

解法ステップ

図の従属性を明示する：a→b,c,d,e、b→c、c→b、d→c、b→eを書き出す。
主キー候補を判定する：aが全属性を決定するため、主キーはa（単一属性）。部分従属はなし。
非キー間の依存（b↔c, d→c, b→e）を分離する必要性を認識する（推移的従属の解消）。
選択肢の分解が各FDを保存するか、かつ各スキーマが3NFになるかを検証する。
保存性と3NFの観点から最も適切なのがエであると判断する。

選択肢別の誤答解説

ア：R(a,b,c,d) とR(b,d,e) の二つに分けた形。R(a,b,c,d) にbとc間の相互依存やd→cが混在し、非キー間の依存が完全に分離されないため、推移的従属を残す。従って3NFとして不十分。
イ：アにさらにR(b,c) を加えた形。R(a,b,c,d) が依然として存在し、a→cやd→c等を通じて非キー間の依存が残るため冗長性が除去しきれない。
ウ：R(a,b,d) とR(b,d,c,e) の二関係に分けた形。R(b,d,c,e) にb↔cとd→cとb→eが集中するため、cとdの関係がbと絡んだままになり、aによる推移的従属の分離が不完全となる。
エ：R1(a,b,d)、R2(b,c)、R3(b,d,e) の三つに分割するため、bとcの相互依存はR2に隔離され、b→eはR3に、aによる直接依存（a→b,a→d）はR1にまとまる。結果として非キー間の依存が適切に分離され、3NFを満たす。

よくある誤解

「a→全属性だから部分従属がある」：主キーが単一属性aの場合、主キーの一部というものが存在しないため部分従属は起こりえません。部分従属は複合キーがあるときに初めて議論対象になります。
「FDが同じ関係にないと保存されない」：FD保存性は「あるFDが単一の分割にそのまま含まれる」か「分割に含まれるFD群から推論できる（合成して得られる）」かのいずれかで満たされます。単にLHSとRHSが同じスキーマにあることだけが条件ではありません。

補足コラム

第3正規形（3NF）化の実務的な考え方は、主キー以外の属性同士の依存（推移的従属や相互依存）を別関係に切り出し、更新異常を防ぐことにあります。3NF構築の標準アルゴリズム（3NF合成法）は、まず最小被覆（minimal cover）を作り、各FDの左辺と右辺を元にスキーマを作成・統合する手順を取ります。本問題の分解エは、その考え方に沿って非キー間の依存をローカライズしています。

FAQ

Q1: なぜ「部分従属を検出する」ではなく「非キー間の従属に着目する」のか？
A1: 今回は主キーが単一属性aであり、部分従属（主キーの一部に依存する）が起きる余地がありません。従って正規化で問題になるのはa以外の属性同士（b,c,d,e）の依存（推移的・相互）をどう扱うかです。

Q2: 元のFDのd→cはどの関係に保存されるのか？
A2: d→c自体はdとcが同一の分割にいるわけではありませんが、分解後はR1でのd→b（原FDとc↔bの組合せにより元のFD群が暗黙に含む）とR2のb→cを合わせることでd→cを導出できます。したがって分解後の関係群から推論可能であり、保存されています。

Q3: R2(b,c) はどの正規形に近いか？
A3: R2はbとcが相互に決定し合う構造なので、b（またはc）が主キーとなる。従ってR2はBCNFに近く、3NFを満たすどころかより強い制約（候補キーによる決定）を満たします。

関連キーワード: 正規化, 第3正規形, 関数従属性, 主キー, 推移的従属, 相互依存, FD保存性