データ正規化入門

データベースのテーブルがまるでガラクタ置き場みたいになってるの、見たことある？あるセルには電話番号のリスト、別のセルには長い一文で書かれた住所、さらに別のセルにはカンマ区切りで複数の日付が入ってたり。こんな「カオス」だと、データの検索や更新、管理がめっちゃ大変。でも、ちゃんと整理する方法があるんだ。それが「データ正規化」ってやつ。

ざっくり言うと、データ正規化はテーブル内のデータを整理して、データの冗長性を最小限にしつつ、更新・削除・挿入時の問題をなくすためのプロセスだよ。

データ正規化が解決してくれる問題はこんな感じ：

1. データの重複排除。同じ情報を2回も3回も保存する必要ある？無駄にDBが大きくなるし、データの不整合も起きやすい。
2. 異常の最小化。リアルでも「異常」ってあるよね？例えば、元同僚を連絡先リストから消し忘れたり。DBでも同じ。正規化でこういう気まずいミスを防げる。
3. データ構造のシンプル化。シンプルな構造なら管理も楽ちん。
4. DBのパフォーマンス向上。データが少なければクエリも速い！

正規化しないとどうなる？

正規化しないと、データが「ベタベタ」になって、余計な情報を常に引きずることになる。

例えば、学生テーブルを考えてみて：

何が問題になるかというと：

• データの重複: Otto Linが何回も出てくる。なぜ？複数のコースを取ってるから。
• 情報の更新が大変: もしOtto Linの電話番号が変わったら、全部のレコードを探して更新しなきゃいけない。
• データ削除で整合性が壊れる: Ottoがコースをやめた場合、全部の行を消すと名前まで消えちゃう。

正規化がやりすぎになる時は？

ぶっちゃけ、正規化って「厳しいスケジュール」みたいなもんで、基本はいいけど、たまには自由が欲しい時もある。実際、非正規化の方がいい場合もあるんだ：

1. 分析系DBでは、データ量よりクエリの速さが大事な時。
2. 構造が複雑になりすぎる時: 正規形を守るためにテーブルが何十個も増えると、クエリがどんどん重くなる。
3. よく使う集計値: いつも同じ合計を計算するなら、テーブルに持たせた方が楽。

例えばネットショップで、ユーザーが注文の合計金額をよく検索するなら、その合計を注文テーブルに持たせておくのもアリ。毎回計算するより速いしね。

ただし、非正規化はトレードオフ。データ更新時のミスが増えるリスクもあるから注意！

問題ある構造と正規化の例

まずは正規化前のテーブル例を見てみよう：

ここで明らかな問題：

• 顧客データが重複してる。
• 商品がリストで保存されてて、データの原子性が守られてない。

正規化後

このテーブルを3つに分けるよ： テーブル顧客

テーブル商品

テーブル注文

これで：

• データの重複がなくなった。
• 商品は1行ずつ独立してる。
• 新しい商品や注文も簡単に追加できる。

正規化は、カオスから秩序を作るアートだよ。時には厳しすぎて面倒に感じるかもだけど、最終的な目的は絶対に価値がある！次のレクチャーでは、正規形を順番に学んでいくよ。まずは1NF、次に2NF、最後に3NF。さあ、整理されたデータの世界へレッツゴー！