データの正規化とE-R図

関係データベースの表は行の集まりで、行を1本に特定する列（の組）が主キーです。正規化は「主キーが決まれば、その行の他の列が自動的に決まる」状態（＝関数従属が主キーからだけ伸びる状態）に近づける作業。逆に言えば、主キー以外の列が別の列を決めてしまう形が残っていると、そこが冗長＝異常の発生源になります。

3行目だけ単価が1,250になっています。どちらが正しいのか、この表からは決められません。これが更新時異常です。1つの事実（P10の単価）が複数の場所に散っていると、更新はその全部に届かなければならず、1か所でも漏れれば矛盾が残る。ほかにも挿入時異常（受注がまだ無い新商品を登録できない）、削除時異常（最後の受注を消すと商品の情報まで消える）が同じ原因から起きます。「同じ値が何度も現れる列」を本文の表から見つけたら、そこが分割対象です。

「2NFは部分従属、3NFは推移従属」を丸暗記すると、設問の表で判定できません。手順にすると簡単です。①主キーを確定する→②各列について『この列は主キー全体がないと決まらないか』を1つずつ問う。主キーの一部だけで決まるなら2NF違反、主キーでない列から決まるなら3NF違反。判定の入口は常に主キーの確定で、ここを間違えると全部ずれます。なお、単一列が主キーの表には「主キーの一部」が存在しないので、1NFなら自動的に2NFです。

関連の向きを迷ったら、外部キーを持っている側が「多」と覚えます。受注表が顧客番号を持つ＝顧客1に対し受注が多。1件の顧客番号は受注表の何行にも現れられるが、1本の受注行が持てる顧客番号は1つだけだからです。設問で「未記入の多重度を答えよ」と問われたら、その表の列に相手の主キーが入っているかどうかを見に行けば決まります。文章から読むときは両方向で言い切ってみるのも有効です（「1人の顧客は複数の受注をする／1件の受注は1人の顧客のもの」＝1対多）。

多対多はそのままでは表にできません。受注と商品は多対多ですが、間に「明細」という表（連関エンティティ）を置き、両側の主キーを外部キーとして持たせて複合主キーにすることで1対多×2に分解します。E-R図に多対多が残っていたら、そこに表が1枚増えるサインです。設問の「追加すべきエンティティを答えよ」はほぼこの形。

データベースの設問は、業務の説明文を読んで表とE-R図に写せるかを測っています。だから問われ方は毎年ほぼ同じ形をとります――（1）未完成のE-R図の多重度や関連線を埋める、（2）表の主キー・外部キーに下線を引く、（3）業務の追加要件（履歴を残す・複数担当を許す）に対しどの表を足すかを答える。(3)はいずれも「1つのマスに複数の値を入れたくなったら表を分ける」という1NFの原則の応用です。要件が『複数の…』と言った瞬間に、表が1枚増えると身構えられれば、その場で解けます。