第2正規形（2NF）とは？データベース正規化の定義・例・注意点

第2正規形（2NF）の定義・判定方法・具体例と注意点を図解で解説。主キーと部分従属性の理解で冗長性を解消し正しいデータ設計を実現。

著者: Leandro Alegsa

第2正規形（2NF）とは、関係モデル、特にテーブルの設計における正規化の基準の一つです。第2正規形は、データの冗長性と更新・挿入・削除の異常（アノマリー）を減らし、データ整合性を保つことを目的としています。

第2正規形の定義（簡潔）

第2正規形の条件は以下の2点です。

  • 表が第一正規形（1NF）を満たしていること。
  • テーブル内のすべての非キー属性（注：主キーの一部ではない属性）が、主キーの「全体」に対して完全関数従属していること（部分従属がないこと）。

用語の説明

  • 主キー（Primary Key）：テーブル内の行を一意に識別する1つまたは複数のカラム。
  • 複合キー：主キーが複数カラムで構成されている場合。第2正規形は主に複合キーを持つテーブルに関係する概念です。
  • 完全関数従属（full functional dependency）：非キー属性が主キーの全てのカラムに依存していること。主キーの一部にだけ依存している場合は「部分従属」と呼び、2NF違反となる。

部分従属（問題）の具体例

以下のような単純化した受注テーブルを考えます（説明のため擬似的に示します）：

  • テーブル名: OrderItems
  • カラム: OrderID, ProductID, ProductName, Quantity, OrderDate
  • 主キー: (OrderID, ProductID) の複合キー

ここで、ProductName は ProductID によって一意に決まる属性であり、(OrderID, ProductID) の「一部」である ProductID にのみ依存しています。従って ProductName は主キーの全体に対して完全には依存しておらず、部分従属が起きています。これにより以下のような問題が発生します：

  • 製品名を更新する際に、同じ製品が複数行に渡っていると複数箇所を更新する必要がある（更新異常）。
  • 製品情報を登録する際に注文が無ければ登録できない（挿入異常）。
  • ある注文を削除すると、その製品の情報も失われる可能性がある（削除異常）。

第2正規形への分割（解決方法）

この問題を解決するには、部分従属する属性を別の表に分割します。上記例では次のように分解します。

  • Products(ProductID, ProductName, Price, ...) — ProductID を主キーとする製品情報テーブル
  • Orders(OrderID, OrderDate, CustomerID, ...) — 注文ヘッダ情報
  • OrderItems(OrderID, ProductID, Quantity, ...) — 注文明細。主キーは (OrderID, ProductID) で、製品名は含めない（必要なら JOIN で取得）。

このように分割すると、ProductName は Products テーブルで ProductID に対して完全に依存するため、OrderItems は第2正規形を満たすようになります。

チェックリスト：2NF かどうか確認する手順

  • テーブルが1NF（各カラムが原子値で繰り返し列がない等）になっているか確認する。
  • 主キーが複合キーか単一キーかを確認する。単一キーの場合、1NF を満たしていれば自動的に2NFを満たす。
  • 各非キー属性が主キーの「一部」に依存していないか（部分従属がないか）を確認する。見つかったら分割を検討する。
  • 分割後は外部キーで参照整合性を保つ。

第2正規形の利点と注意点

  • 利点：冗長性の低減、更新・挿入・削除の異常の回避、データ整合性向上。
  • 注意点：正規化によりテーブル数が増え、JOIN が増えるためクエリ性能が下がる場合がある。実運用ではパフォーマンスを見て一部を意図的に非正規化する（デノーマライズ）判断も必要。
  • 補足：第2正規形は 1NF の次の段階であり、これを満たした後はさらに 推移的依存（transitive dependency） を除去して第3正規形（3NF）へ進むのが一般的です。
  • 設計上の選択：複合キーを避けるためにサロゲートキー（単一の合成キーではない人工的な ID）を使うこともある。これにより2NFの観点での問題は変わるが、設計上のトレードオフを考慮する必要がある。

まとめ（実務的なポイント）

  • 第2正規形は「1NF を満たし、非キー属性が主キーの一部にだけ依存していない」ことを意味する。
  • 複合キーを用いるテーブルでは部分従属に注意し、該当する属性は別テーブルへ分割することで解決する。
  • ただし正規化は万能ではなく、性能や運用性を考慮して適切にデノーマライズする判断も必要。


百科事典を検索する
AlegsaOnline.com - 2020 / 2025 - License CC3