テーブル設計の基本：正規化・主キー・インデックスの考え方

正規化とは？データの重複を防ぐ設計手法

正規化（Normalization）とは、データの重複や不整合を防ぎ、効率的なデータ構造を実現するための設計ルールです。通常、第1正規形（1NF）〜第3正規形（3NF）までを意識すれば実用上十分です。

第1正規形（1NF）：繰り返しを排除

第1正規形では、テーブルの各カラムが「単一の値」を持つように設計します。つまり、1つのセルに複数の値（カンマ区切りなど）を入れてはいけません。これにより、データの検索や更新が容易になり、整合性の高いデータを保つことができます。

■NG例
テーブル名：customers

顧客ID	名前	購入商品
1	田中一郎	リンゴ, バナナ

■改善例
テーブル名：customers

顧客ID	名前
1	田中一郎

テーブル名：customer_products

顧客ID	商品名
1	リンゴ
1	バナナ

第2正規形（2NF）：主キーの一部に依存する項目を分離

第2正規形では、複合主キーを持つテーブルにおいて「主キーの一部にだけ依存する属性」を分離し、別テーブルに切り出します。これにより、データの重複や不整合を防ぎます。例えば、商品情報が商品IDにのみ依存している場合、注文情報とは分けて商品マスタとして管理するのが正しい設計です。

■NG例
テーブル名：order_details（商品情報を含む）

受注ID	商品ID	商品名	単価
1001	A01	キーボード	3000

■改善例
テーブル名：order_details

受注ID	商品ID
1001	A01

テーブル名：products

商品ID	商品名	単価
A01	キーボード	3000

第3正規形（3NF）：推移的な依存関係を排除

第3正規形では、主キーに直接関係しない**間接的な依存（推移的関係）**を排除します。つまり、「A → B → C」という関係があるとき、B→Cの依存関係を別テーブルに切り出します。これにより、1つの情報の更新が他のレコードに影響しにくくなり、保守性が向上します。

■NG例
テーブル名：customers（都道府県を直接含む）

顧客ID	郵便番号	都道府県
1	1000001	東京都

■改善例
テーブル名：customers

顧客ID	郵便番号
1	1000001

テーブル名：zip_codes

郵便番号	都道府県
1000001	東京都

---

主キーの選び方：一意性と変更されないことが重要

主キー（Primary Key）はレコードを一意に識別するための列です。主キーを適切に設計することで、リレーションの整合性や検索効率が向上します。

主キーの条件

• 一意性がある：重複しない値
• NULL不可：空の値があってはいけない
• 変更されにくい：IDの値が変わると紐づくデータも壊れる可能性あり

自然キー vs 人工キー

• 自然キー：業務上すでに一意に定まっているデータ（例：社員番号、メールアドレス）
• 人工キー：システム上で付番するID（例：auto_incrementのID）

推奨：人工キーを主キーにして、自然キーには一意制約（UNIQUE）をつける

---

インデックスの考え方：検索高速化の鍵

インデックス（Index）は本の索引のようなもの。インデックスを張ることで、テーブルの検索速度を大幅に向上させることができます。

インデックスの種類

• 主キーインデックス：自動的にインデックスが張られる
• 一意インデックス（UNIQUE）：重複を許さない
• 通常のインデックス（INDEX）：検索条件に使うカラムに対して設定

使用例

-- name列にインデックスを張る
CREATE INDEX idx_users_name ON users(name);

インデックスを張るべき場面

• WHERE句によく使うカラム
• JOINで使用するキー
• ORDER BYやGROUP BY対象カラム

注意点

• 書き込み（INSERT, UPDATE）が重くなる
• 小さいテーブルでは効果が薄い
• 過剰なインデックスは逆効果

---

まとめ：テーブル設計は正規化＋キー設計＋インデックスで決まる

テーブル設計の基本を押さえることで、データベースは拡張性・保守性・性能面すべてにおいて強くなります。

• 正規化：データの重複を排除し、整合性を保つ
• 主キー：レコードの一意性を確保する
• インデックス：検索性能を高めるが、適切な設計が必要

業務要件やシステムの規模に応じて、正規化をどこまで進めるか、どこにインデックスを張るか、常にバランスを見ながら設計していくことが重要です。