【SQL・DB基礎編 第1回】システム設計の第一歩！データの矛盾をなくす「正規化」の魔法

全4回の「データベース・SQL入門編」、お疲れ様でした！

これまでの連載で、データの検索、集計、そして追加・更新・削除（CRUD）という、SQLの基本的な「使い方」はバッチリ身についたはずです。

さて、今回からはいよいよ「基礎編」へとステップアップします。 入門編が「すでにあるデータベースを使う方法」だったのに対し、基礎編のテーマは「美しくて壊れにくいデータベースを作る（設計する）方法」です。

今回は特別編として、システム設計の第一歩であり、入門編第3回で学んだ「テーブルの結合（JOIN）」がなぜ必要なのかが腑に落ちる、「正規化（せいきか）」という概念について解説します。

単なる「コードを書く人」から、システム全体を見渡す「設計できるエンジニア」へ視点を引き上げていきましょう！

1. なぜデータを1つの巨大な表にしないのか？

Excelで顧客や売上の管理をしていると、すべての情報を1つの巨大なシートにまとめたくなることはありませんか？

例えば、以下のような「全部入り」の売上管理表です。

一見、パッと見てわかりやすいですよね。しかし、これをそのままデータベースにしてしまうと、実務において致命的な問題が複数発生します。

• 更新の悲劇：山田さんが引っ越した場合、O-001とO-002の両方の住所を更新しなければなりません。もし片方だけ更新を忘れると「データに矛盾」が生じます。

• 登録の悲劇：新商品の「キーボード」を登録したいだけなのに、誰かが注文してくれないとこの表にデータを追加できません（商品だけの行を作ると、顧客情報が空欄になって不自然になります）。

こうした悲劇（データの重複や矛盾）を防ぐために、表を意味のある単位に綺麗に分割していく作業を「正規化」と呼びます。

2. 美しいデータベースを作る「正規化」の3ステップ

正規化にはいくつか段階がありますが、実務で重要となる「第3正規形」までの流れを簡単にご紹介します。

ステップ1：第1正規形（1つのセルには1つのデータ）

データベースの絶対ルールです。例えば、「商品名」のセルに「ノートPC, マウス」のように複数のデータをカンマ区切りで入れてはいけません。必ず1行ずつに分け、表をフラット（平坦）な状態にします。

ステップ2：第2正規形（「注文」と「商品」を分ける）

ここからが本番です。「全体のカギ（主キー）」に完全に依存していないデータを切り離します。

先ほどの表で、「商品名」や「単価」は「注文」に紐づいているのではなく、「商品ID」さえ分かれば決まるデータですよね。

これをそのままにしておくと、先述した「商品単体で登録できない」問題が起きます。そこで、「商品の情報」を別のテーブルとして独立させます。

ステップ3：第3正規形（「注文」と「顧客」を分ける）

さらに、「顧客名」や「顧客住所」も、「注文番号」に直接紐づくわけではなく、「顧客ID」が分かれば決まるデータです。これも「顧客テーブル」として独立させます。

3. 正規化の完成と、JOIN（結合）の伏線回収

上記のステップを踏まえて正規化を行うと、最初の巨大な表は以下の3つのスッキリとした表に分割されます。

① 顧客テーブル（顧客ID、顧客名、顧客住所）

② 商品テーブル（商品ID、商品名、単価）

③ 注文履歴テーブル（注文番号、顧客ID、商品ID、数量）

どうでしょう？

山田さんが引っ越した時は「①顧客テーブル」の住所を1箇所書き換えるだけ（UPDATE）で済みます。新商品が出たら「②商品テーブル」に追加するだけ（INSERT）です。データに矛盾が起きる余地がなくなりました。

そして、「山田さんが何をいくつ買ったか、住所も含めた一覧表を出したい」という時はどうするのでしょうか？

そうです。ここで入門編で学んだ「JOIN（テーブルの結合）」の出番です！

-- 注文履歴をベースに、顧客と商品テーブルをJOINして元の巨大な表を復元する
SELECT * FROM 注文履歴
INNER JOIN 顧客 ON 注文履歴.顧客ID = 顧客.顧客ID
INNER JOIN 商品 ON 注文履歴.商品ID = 商品.商品ID;

バラバラに管理して矛盾を防ぎ、必要な時だけSQL（JOIN）の力でガッチャンコして取り出す。これが、現在世界中のシステムで使われているリレーショナルデータベース（RDB）の真髄であり、最も美しい設計思想なのです。

まとめ

• データを1つの巨大な表で管理すると、更新漏れなどの矛盾（エラー）が生じやすい。

• データの重複をなくし、意味のある単位に表を分割していくプロセスを「正規化」と呼ぶ。

• 正規化されたバラバラの表を、必要な時に繋ぎ合わせる魔法が「JOIN」である。

「なぜSQLにはJOINなんて面倒な機能があるんだろう？」と思っていた方の疑問が、今回の「正規化」の話で氷解していれば嬉しいです。

次回からの基礎編では、この美しいデータベースからさらに複雑なデータ分析を行うための「高度な集計」や「型変換」などの実践テクニックに入っていきます。お楽しみに！