データベースの正規化とは

データベース設計の目的は、効率的かつ信頼性の高いデータ管理を実現することです。
しかし、データベースが無秩序に構築されると、データが重複したり、変更や更新が困難になったりするため、データの一貫性を保つのが難しくなります。

こうした問題を解決するために行われるのが「正規化」です。

正規化は、データを整理し、冗長性を取り除くことで、データの更新・削除・検索などが効率的になるようデータベースを構築するプロセスです。

正規化を実施する際に基本となるのが、「主キー」と「外部キー」の概念です。

これらは、各テーブルのレコードを一意に識別したり、テーブル間の関係性を定義したりするために重要な役割を果たします。それでは、まずこれらのキーについて詳しく見ていきましょう。

主キーと外部キー

主キー

データベースのテーブルには、各行（レコード）を唯一無二に識別するためのキーが必要です。

この役割を果たすのが主キー（Primary Key）です。

主キーは、データの一意性を保証し、データベース内で重複を許さないため、データの整合性を保つために欠かせません。

一意誓約と非NULL誓約

• 一意誓約（Unique Constraint）
  主キーには「一意誓約」が課され、同じテーブル内で重複する値を持つことが禁止されています。
  これにより、主キーを利用して各レコードを正確に識別することができます。
• 非NULL誓約（Not Null Constraint）
  主キーは常に値を持つ必要があるため、「非NULL誓約」が適用されます。
  NULL（空の値）は許可されないため、主キーは常に有効な値で埋められ、一意にアクセスできるようになります。

複合キー

複合キー（Composite Key）は、複数の列を組み合わせて一意性を確保する場合に使用されます。

たとえば、社員が複数のプロジェクトに参加している場合、「社員ID」と「プロジェクトID」を組み合わせて複合キーとし、各参加記録を一意に識別することができます。

外部キー

外部キー（Foreign Key）は、異なるテーブル間での関連性を構築するためのキーです。

外部キーを使うことで、他のテーブルの主キーを参照し、テーブル間のデータの整合性を保つことが可能になります。

例：社員一覧表と部署一覧表

例えば、社員の情報を管理する「社員一覧表」と、部署の情報を管理する「部署一覧表」があるとします。

社員一覧表には「部署ID」を設け、部署一覧表の主キー「部署ID」を参照する外部キーとします。

これにより、社員一覧表から各社員の所属部署を関連付けることができます。

表を分ける理由（正規化の考え方）

社員一覧表と部署一覧表を分ける理由は、データの重複や不整合を防ぎ、管理しやすくするためです。

たとえば、部署の名前を変更する際に、部署一覧表の1か所を更新するだけで済み、全ての社員レコードに変更を反映できます。

このように、テーブルを分けて関連付けることで、データの一貫性が確保されます。

---

データベースの正規化

正規化とは

正規化は、データの冗長性（重複）を減らし、データの一貫性を保つためのプロセスです。

データベースにおける正規化は、テーブルを分割し、データを効率的に整理することで、データ更新や管理の際の矛盾を減らすことを目的としています。

正規化により、データベースは「第1正規形（1NF）」「第2正規形（2NF）」「第3正規形（3NF）」といった段階を経て最適化されていきます。

正規化の手順

第1正規形（1NF）

第1正規形（1NF）では、各列が「単一の値」を持つようにします。

テーブル内に繰り返しのグループや配列のような形式でデータを持つことは許されません。

たとえば、「電話番号」という列に複数の電話番号を入れずに、別の行に分けるか、新しいテーブルを作成して関連付けます。

第1正規化の具体例：繰り返しグループを排除

Before（非正規形の例）

顧客テーブルには「電話番号1」「電話番号2」といった繰り返し項目が存在し、1つの列に複数の値が含まれています。

顧客ID	顧客名	電話番号
1	田中	080-1234-5678, 090-2345-6789
2	鈴木	080-3456-7890
3	佐藤	090-4567-8901, 070-5678-9012

After（第1正規形適用後）

各列には単一の値のみを含むようにし、繰り返し項目を別行に分割しました。

顧客ID	顧客名	電話番号
1	田中	080-1234-5678
1	田中	090-2345-6789
2	鈴木	080-3456-7890
3	佐藤	090-4567-8901
3	佐藤	070-5678-9012

第2正規形（2NF）

第2正規形（2NF）では、部分関数従属性を排除することが求められます。

部分関数従属性とは、複合キーの一部にだけ依存する属性のことです。

第2正規形にするためには、複合キーを持つテーブルの場合、すべての非キー属性が複合キーの全てに依存するようにします。

第2正規化の具体例：部分関数従属性を排除

Before（第1正規形適用後）

注文テーブルにおいて、「商品名」が「商品ID」だけに依存しているため、部分関数従属性が発生しています。

注文ID	商品ID	商品名	数量
101	A001	ノートパソコン	2
102	A002	マウス	1
103	A001	ノートパソコン	3

After（第2正規形適用後）

商品情報を別テーブルに分け、注文テーブルには商品IDのみを残しました。

注文テーブル

注文ID	商品ID	数量
101	A001	2
102	A002	1
103	A001	3

商品テーブル

商品ID	商品名
A001	ノートパソコン
A002	マウス

第3正規形（3NF）

第3正規形（3NF）では、推移的関数従属性を排除します。

推移的関数従属性とは、主キーに直接依存しない属性が存在する場合のことです。

第3正規形では、すべての非キー属性が主キーに直接依存するようにテーブルを分割します。

第3正規化の具体例：推移的関数従属性を排除

Before（第2正規形適用後）

学生テーブルには「指導教員名」が含まれていますが、指導教員名は学籍番号に直接依存しているわけではなく、「指導教員ID」に依存しているため、推移的関数従属性が存在します。

学籍番号	学生名	指導教員ID	指導教員名
S001	山田	T01	佐藤教授
S002	田中	T02	鈴木教授
S003	鈴木	T01	佐藤教授

After（第3正規形適用後）

指導教員情報を別のテーブルに分け、学生テーブルには指導教員IDのみを残しました。

学生テーブル

学籍番号	学生名	指導教員ID
S001	山田	T01
S002	田中	T02
S003	鈴木	T01

指導教員テーブル

指導教員ID	指導教員名
T01	佐藤教授
T02	鈴木教授

このようにして、第1正規形から第3正規形まで段階を追って正規化を進めることで、データの重複や不整合を防ぎ、管理が容易で一貫性のあるデータベース構造が構築されます。

---

参考：部分関数従属性と関数従属性

部分関数従属性とは

部分関数従属性とは、複合キーの一部にだけ依存する属性のことです。

関数従属性とは

関数従属性とは、ある列の値が他の列の値に依存して決まる関係です。

例えば、社員IDによって社員名が一意に決まる場合、社員IDと社員名の間に関数従属性があるといいます。

---

まとめ

データベースの正規化は、データを効率的かつ整合性のある形で管理するための重要な手法です。

主キーや外部キーの概念を正しく理解し、正規化の各段階を順に適用することで、データの冗長性を減らし、更新や検索の効率を高めることができます。

正規化は一見複雑ですが、データの一貫性や保守性を高めるために不可欠なステップです。
正規化を適用することで、データベースをより柔軟かつ安全に運用できるようになります。