第二正規形 (2NF) の原則

テーブルが第二正規形になっていると言えるのは、次の条件を満たしている場合だよ：

1. すでに第一正規形 (1NF) になっている。
2. すべての非キー列が主キー全体に依存していて、主キーの一部だけに依存していない。

もし主キーが複数のフィールド（複合キー）で構成されている場合、どの非キー属性（カラム）もそのキーの一部だけに依存しちゃダメ。つまり、2NFは部分的な依存関係を排除するってことだね。

2NF違反の例

たとえば、student_courses（学生とコース）というテーブルがあって、学生・コース・担当講師の情報を保存しているとしよう：

• student_idとcourse_idが一緒になって複合主キーを作ってる。
• でもcourse_nameとinstructor_nameのカラムに注目してみて。これらはcourse_idだけに依存していて、(student_id, course_id) のペア全体には依存していない。

これが部分的な依存関係ってやつ！course_nameとinstructor_nameは複合キーの一部（course_id）だけに依存してる。これが2NFの原則違反だよ。

テーブルを2NFにする方法

やるべきことは、部分的な依存関係を解消するためにテーブルを2つに分けること。これで冗長性がなくなって、データの一貫性もアップする。

コースに関する情報を別テーブルcoursesに分離しよう：

メインのテーブルはこんな感じにシンプルになる：

これで、すべてのカラムが主キー全体に依存するようになった。データを論理的に分けて、2NF違反を解消できたね。

冗長性解消のマジック

正規化前のテーブルを見てみて。instructor_nameカラムには「Lin」って名前が何度も出てくる。実際のDBで何千件もあったら、どれだけ繰り返されるんだろう？テーブルを分けることで冗長性をなくして、例えば「Lin」と「Ling」みたいなタイプミスも減らせるよ。

実生活の例

たとえば、商品の注文管理をしているとしよう。次のorder_items（注文と商品）テーブルがあって、order_idとitem_idが主キーになってる：

見ての通り、商品名や価格が繰り返されてる。これは2NF違反のサイン。なぜならitem_nameとpriceはitem_idだけに依存してるから。

2NFにするためにitemsテーブルを作ろう：

そしてorder_itemsテーブルは注文IDと商品IDだけにする：

これでデータはコードレビュー後みたいにクリーン。冗長性ゼロ！

実践課題：自分でやってみよう！

たとえばemployee_projectsテーブルがあって、社員・プロジェクト・プロジェクトマネージャーの情報が入ってるとする：

やってみよう：

1. 2NFの要件を破っている依存関係を見つけてみて。
2. テーブルを2つに分けて、違反を解消しよう。

なぜ2NFを守るのが大事なの？

そもそも、なんで第二正規形（2NF）を守る必要があるの？理由はシンプル。データの重複や混乱を防ぐためだよ。部分的な依存関係をなくすことで、テーブルがスッキリして、同じ講師名が何度も出てくるみたいな繰り返し情報がなくなる。これでスペースも節約できるし、矛盾も起きにくい。名前を一箇所変えれば、全部最新になるからね。

さらに、こういう構造だとクエリも書きやすい。論理的な構造で、データがバラバラになってないから、フィルタやグループ化も速くて確実。もちろん、テーブルが増える分、SQLのJOINがちょっと増えるけど、同じ名前が何十行も並ぶよりJOIN一発の方がマシ。ほとんどの場合、正規化する価値は十分あるよ。

実プロジェクトでの活用

2NFの知識はこんな場面で役立つよ：

• データベース設計時：テーブルがカオスになるのを防げる。
• 面接のとき：よく「正規形に直して」とか聞かれる。
• 実務で：既存DBの最適化を任されたとき、「モノリシック」なテーブルを正規化して分割できる。

第二正規形 (2NF) は、主キーが複合キーの場合にテーブル内の部分的な依存関係を排除するのに役立つ。テーブルを論理的なブロックに分けて、すべてのカラムが主キー全体だけに依存するようにする。これでDBの質が上がり、冗長性がなくなって、柔軟性もアップ。さあ、第三正規形に進む準備はできた？次に行こう！

2

タスク

SQL SELF, レベル 25, レッスン 2

ロック未解除

2NFへの正規化

2NFへの正規化

オープン