第一正規形 (1NF) の原則

第一正規形 (First Normal Form, 1NF) はデータベース正規化の最初のステージで、テーブル構造に厳しい制約を課すんだ。テーブルが1NFになるには、次の条件を満たす必要がある：

1. すべてのデータがアトミックである。テーブルの各セルの値は分割できないものじゃないとダメ。さよなら、「1つのセルにリスト」！データベースでそれはNGだよ。
2. 各行がユニークである。つまり、テーブルにはPrimary Key（主キー）やユニークなIDが必要。
3. 繰り返しグループが存在しない。同じエンティティの値が同じカラムに複数入ってちゃダメ。

簡単に言うと、データベースのテーブルは自分の部屋みたいなもので、アトミックな値は個々のアイテム：ランプ、机、本みたいな感じ。もし部屋がごちゃごちゃ（たとえば全部の物が山積み）だと、ランプを探したり、予備の机があるかすぐ分からないよね。正規化は「全部をちゃんと整理する」手助けをしてくれるんだ。

1NF違反の例

例えば、学生のテーブルがあって、受講しているコース情報を保存しているとする：

この構造の何がダメなの？コース（coursesカラム）がカンマ区切りで1つのセルに入ってる。たとえば物理を勉強している学生を探したい時、クエリがめっちゃ面倒になるし、テキスト変換も大変。もし誰かが物理をリストから消したい場合もまた問題。こういうデータはアトミックじゃなくて、1NFの基本ルールに違反してるんだ。

テーブルを1NFにするには？

この問題を解決するために、データを分割して、各セルの値がアトミックになるようにするよ：

これでOK！テーブルを変換して、各セルの値が分割できないようにした。これが1NFの原則に合ってる状態だよ。

1NF違反と修正の詳しい例

例えば、ネットショップの注文テーブルがあるとする：

ここで明らかにitemsがカンマ区切りで複数の値を持っていて、1NF違反だよね。

1NFにするために、注文ごとに1つの商品を1行で保存するようにする：

これでテーブル構造が1NFの原則に合ったよ。各注文と商品が別々の行になって、値はアトミックだ。

主キーの追加

テーブルを変換した後は、ユニークなID（主キー）を各行に追加して、ユニーク性を保証するのが大事。上の例だと、order_idとitemの組み合わせを複合主キーにできるけど、実際はidという別フィールドを作ることが多いよ。

実践課題

1つのセルに学んでいる科目が入っている学生テーブルがある：

このテーブルを1NFに合う形に直してみよう。

変換後のテーブルはこんな感じになる：

1NFでよくあるミス

データベースを扱うとき、1NF違反はこんな場面でよく出てくる：

• リストや配列をそのままテーブルに保存しちゃう。これが一番多いミス。
• 行のユニークID（主キー）がない。これだと重複データが入りやすくなる。
• 同じ情報を複数カラムで保存しちゃう。たとえば "course_1", "course_2", "course_3" みたいなやつ。本当は正しい構造にすべき。

このポイントを覚えておけば、データベースは第一正規形を守れるよ。

1NFの実践的な使い方

実際のプロジェクトでも1NFは超重要。例えば：

• 顧客管理アプリ（CRM）では、顧客データやアクションはアトミックであるべき。分析や検索が楽になるからね。
• ネットショップでは、注文・商品・顧客情報を効率よく保存するために1NFが使われてる。
• 銀行システムでは、顧客・口座・取引データがアトミックじゃないと、いろんな操作がごちゃごちゃになっちゃう。

1NFの原則を守れば、高負荷にも耐えられて使いやすいデータベース設計ができるよ。バッチリだけど、データの重複が出てきたね。だから次は第二正規形（2NF）に進んで、テーブルの部分的な依存関係をどう解決するかを学ぼう。

なぜ第一正規形（1NF）を守るのが大事なのか？例えば、1つのセルに複数の値（たとえば注文商品のリスト）が入ってるテーブルを想像してみて。そうなると、たとえば「キーボード」を注文した人を探すのがめっちゃ大変になるし、一部の情報を変更・削除したい時もミスしやすい。データがアトミック（各フィールドに1つの値だけ）なら、操作がずっと安全で分かりやすい。しかも、そういうテーブルはスケールや更新、再設計も簡単なんだ。