第3正規形 (3NF)

第3正規形のルール: 「別の列を経由して決まる列」を追い出す

第3正規形 (3NF) のルールは 2 つ。

• まず 第2正規形 を満たしていること
• 主キー以外の列が、別の「主キーでない列」を経由して決まっている 状態があってはいけない。

「経由して決まる」を専門用語で 推移関数従属 (transitive functional dependency) と呼ぶ。注文ID → 顧客ID → 顧客名 のように、真ん中の 顧客ID (主キーではない列) を挟んで 注文ID から顧客名が「間接的に」決まっているような状態。 こうなっていると同じ顧客の情報が注文の数だけ何度も繰り返され、更新時異常 の原因になる。

実践例: 2NF まで進めた受注テーブル

前ページ で 2NF に進めた結果、 受注データは 受注 / 商品 / 受注明細 の 3 テーブルに分かれた。 このうち 商品 と 受注明細 はもう分析するべき従属関係は残っていない。 問題は 受注 テーブル — ここに顧客関連の列 (顧客名・顧客住所) がまだ残っており、 これが 3NF で扱う対象になる。

実データで見る冗長: 顧客ID が同じ行で顧客名・顧客住所が繰り返される

まず 2NF 受注テーブルを、列がどう決まっているかで色分けして眺める。 すると「同じ顧客ID の行で顧客名・顧客住所が全く同じ値を繰り返している」ことが目で見える。 これは 2NF まで進めても残っている冗長で、次に「なぜこうなるか」を関数従属で分析する。

関数従属で分析すると推移経路が見つかる

上で見えた冗長がなぜ起きているかを関数従属で分析すると、注文ID → 顧客ID → 顧客名/顧客住所 という非キー属性を経由した 従属経路が見えてくる。

3NF 化: 経由先を別テーブルに切り出す

経由の元 (顧客ID) と経由先 (顧客名・顧客住所) をまとめて 顧客 テーブルとして独立させる。 受注テーブル側には 顧客ID だけを残しておけば、 顧客の詳細が知りたい時は顧客テーブルを見に行けば分かる。

3NF 化 完了後のスキーマ全体像

1NF から出発して、2NF・3NF と分割してきた結果、 最終的に以下の 4 テーブル のスキーマになる。

• 受注 (注文ID, 注文日, 顧客ID) — 注文そのものの事実
• 顧客 (顧客ID, 顧客名, 顧客住所) — 顧客マスタ
• 商品 (商品ID, 商品名, 単価) — 商品マスタ
• 受注明細 (注文ID, 商品ID, 数量) — 注文と商品の関連

非1NF スプレッドシートに詰め込まれていたデータが、3 段階の正規化を経て、 「顧客の事実は顧客テーブルに 1 度」「商品の事実は商品テーブルに 1 度」「注文の事実は受注テーブルに 1 度」 という 一事実一箇所 の構造になった。

練習問題

別のデータで自分でも試してみる。答えを見る前にどこに推移があるか考えてみてほしい。

3NF の先には BCNF もあるが…

3NF より少し厳密な ボイス・コッド正規形 (BCNF) というものもある。 3NF が排除しきれない特殊なケース (候補キーが複数あって、その候補キー同士に従属関係があるとき) をカバーする。

ただし現実の業務モデルではこの特殊ケースは滅多に問題にならないため、実務では 3NF まで進めば十分 とされることが多い。 BCNF の詳しい話は別トピックで扱う予定 (現状は未収録)。

3NF まで進めるとこんな良いことがある

• 「同じ情報を複数の場所に書く」問題がほぼ解消され、更新時異常の心配がなくなる
• 顧客・商品・部署のような「マスタ (基準情報)」が自然に独立したテーブルになる
• その後の外部キー制約・インデックス設計・トランザクション設計といった議論が単純になる

ここまで進めた上で、性能上どうしても必要な箇所についてだけ、 意識的に冗長を戻す 非正規化を検討するのが実務の定番の流れ。