第2正規形 (2NF)

第2正規形のルール: 「主キーの一部だけで決まる列」を追い出す

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

• まず 第1正規形 を満たしていること
• 主キーが 2 列以上の組 (複合キー) のとき、「複合キーの一部だけで決まってしまう列」があってはいけない。

この「主キーの一部だけで決まる関係」を専門用語で部分関数従属 (partial functional dependency) と呼ぶ。 言葉は難しいが、実データで見ると「同じ商品IDの行では商品名が全部同じ」みたいな、 素朴に「これ重複してるよね」と感じる状態のこと。

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

前ページ で 1NF 化した受注テーブルをそのまま引き継ぐ。 1 行が「1 注文の 1 商品」を表すフラットな表になっている。 このテーブルは 注文ID だけでは 1 行に絞れない (同じ注文で複数商品がある)、商品ID だけでも絞れない (同じ商品が複数注文で買われる)。 両方を組み合わせて (注文ID, 商品ID) の複合キーが主キーになる。

実データで見る冗長: 同じ色の列で同じ値が繰り返される

まず 1NF 受注テーブルを、列がどう決まっているかで色分けして眺める。 すると「同じ色の列で同じ値が何度も繰り返されている」ことが目で見える。 これが冗長性の正体で、次に「なぜこうなるか」を関数従属で分析していく。

関数従属で整理すると 3 グループに分かれる

なぜ「同じ色の列」で同じ値が繰り返されているのか。 それは「その列は主キーの一部だけで決まっている」から。 列がどう決まっているかを関数従属で分類すると、9 列がきれいに 3 グループに分かれる。 そしてこの 3 グループがそのまま「2NF 化後に分かれる 3 テーブル」の原型 になる。

2NF 化: 3 グループを 3 テーブルに切り出す

あとは分析結果の通りに分ければいい。 「注文ID だけで決まる列」は 受注 テーブルに、 「商品ID だけで決まる列」は 商品 テーブルに、 「(注文ID, 商品ID) の組み合わせで決まる列」は 受注明細 テーブルに、 それぞれ切り出す。

主キーが 1 列だけのテーブルは考えなくて OK

2NF の話は「主キーの一部だけで決まる列があってはいけない」というものなので、 そもそも主キーが 1 列だけのテーブルには関係がない (「主キーの一部」というものが存在しないから)。 つまり 主キーが 1 列だけのテーブルは、1NF を満たしていれば自動的に 2NF も満たす。

2NF 違反を気にする必要があるのは、主キーが複数列の組み合わせになっているテーブル (関連テーブル / 中間テーブルなど) だけ。

練習問題

別のデータで自分でも試してみる。答えを見る前にどう分割すればいいか考えてみてほしい。

2NF のチェック手順

1. そのテーブルの主キーを確認する (複数列の組み合わせか？)
2. 複合キーなら、主キーの「一部だけ」の組み合わせを全部書き出す (例: 主キーが (A, B) なら「A」と「B」)
3. それ以外の各列について、その「一部だけ」で値が決まってしまわないかを確認する
4. 決まっていたら、その一部を主キーとする別テーブルに切り出す

ここまで来れば、「主キーの一部で決まる列が重複する」問題は解消される。 ただしまだ別の重複が残っていることが多い。 今回の例で言えば、受注テーブルの中で 顧客ID → 顧客名, 顧客住所 という関係が残っており、 同じ顧客の情報が注文行ごとに繰り返し書かれている。 これを扱うのが次の 第3正規形 だ。