データベース設計における正規形の理解: 包括的なガイド

データベース設計におけるさまざまな正規形

データベース設計における 正規化 は、データを整理して冗長性と依存性を最小限に抑え、データの整合性を向上させるプロセスです。このプロセスには、大きなテーブルを管理しやすい小さなテーブルに分割し、テーブル間の関係を確立することが含まれます。これにより、データベースに挿入、更新、削除の異常がないことが保証されます。

さまざまな 正規形式 は、特定のレベルの正規化を表します。各正規形は前の正規形に基づいて構築されており、独自のルールのセットがあります。以下は最も一般的な正規形の説明です:

---

1.第一正規形 (1NF)

1NF は、重複データを排除し、各列にアトミック値 (繰り返しグループがない) が含まれるようにテーブル内のデータが編成されるようにすることに重点を置いた、最も基本的なレベルの正規化です。

• 1NF のルール:
  1. 表の各セルには単一の値 (原子性) が含まれている必要があります。
  2. 各レコード (行) は一意である必要があります。
  3. 各列には、単一タイプの値 (例: すべての整数、すべての文字列) が含まれている必要があります。
  4. 列のグループを繰り返したり、1 つの列に複数の値を入れたりすることはできません。

1NF の例:

1NF より前:

OrderID	Products	Quantities
1	Apple, Banana	2, 3
2	Orange	5

---

1NF に変換した後:

OrderID	Product	Quantity
1	Apple	2
1	Banana	3
2	Orange	5

---

2.第 2 正規形 (2NF)

2NF は、部分的な依存関係 を削除することにより、1NF に基づいて構築されます。部分依存関係は、非主属性 (主キーの一部ではない列) が主キーの一部のみに依存している場合 (複合主キーの場合) に発生します。 2NF を達成するには、テーブルがまず 1NF の要件を満たしている必要があります。

• 2NF のルール:
  1. テーブルは 1NF にある必要があります。
  2. すべての非主属性は、主キー全体に完全に機能的に依存する必要があります (部分的な依存関係を排除します)。

2NF の例:

2NF より前 (部分的な依存関係):

OrderID	Product	CustomerName	Price
1	Apple	John	10
1	Banana	John	5
2	Orange	Jane	8

---

ここで、CustomerName は、完全な主キー (OrderID、Product) ではなく、OrderID のみに依存します。これを削除するために、テーブルを分割しました。

2NF以降:
テーブル:

• 注文 (注文ID、顧客名)
• 注文詳細 (注文ID、製品、価格)

注文テーブル:

OrderID	CustomerName
1	John
2	Jane

---

OrderDetails テーブル:

OrderID	Product	Price
1	Apple	10
1	Banana	5
2	Orange	8

---

3.第 3 正規形 (3NF)

3NF は 2NF に基づいて構築され、非プライム属性が別の非プライム属性に依存するときに発生する 推移的な依存関係 に対処します。非主属性は主キーのみに依存する必要があります。テーブルが 2NF にあり、すべての推移的な依存関係が削除されている場合、テーブルは 3NF にあります。

• 3NF のルール:
  1. テーブルは 2NF にある必要があります。
  2. 非プライム属性は別の非プライム属性に依存すべきではありません (推移的な依存関係を削除します)。

3NF の例:

3NF (推移的依存関係) より前:

OrderID	Product	Category	Supplier
1	Apple	Fruit	XYZ
2	Carrot	Vegetable	ABC

---

ここで、サプライヤーは、OrderIDに直接依存するのではなく、カテゴリに依存します。これを解決するために、テーブルを分割しました。

3NF以降:
テーブル:

• 注文 (OrderID、製品、カテゴリ)
• カテゴリ (カテゴリ、サプライヤー)

注文テーブル:

OrderID	Product	Category
1	Apple	Fruit
2	Carrot	Vegetable

---

カテゴリ表:

Category	Supplier
Fruit	XYZ
Vegetable	ABC

---

4.ボイス・コッド正規形 (BCNF)

BCNF は、3NF のより厳密なバージョンです。次の場合、テーブルは BCNF にあります:

• 3NFにあります。
• すべての関数の依存関係について、左側は 候補キー (つまり、最小限のスーパーキー) でなければなりません。

もっと簡単に言うと、BCNF は、テーブルが 3NF にあるものの、候補キーではない属性に関係する依存関係がまだあるという状況に対処します。

• BCNF のルール:
  1. テーブルは 3NF にある必要があります。
  2. すべての行列式は候補キーでなければなりません。

BCNF の例:

BCNF の前:

CourseID	Instructor	Room
101	Dr. Smith	A1
102	Dr. Smith	B1
101	Dr. Johnson	A2

---

ここでは、インストラクター が 部屋 を決定しますが、インストラクター は候補キーではないため、BCNF に違反します。 BCNF を実現するには、依存関係を異なるテーブルに分割します。

BCNF 後:
テーブル:

• コース (コースID、講師)
• 部屋（インストラクター、部屋）

コース表:

CourseID	Instructor
101	Dr. Smith
102	Dr. Smith
101	Dr. Johnson

---

部屋のテーブル:

Instructor	Room
Dr. Smith	A1
Dr. Smith	B1
Dr. Johnson	A2

---

5.第 4 正規形 (4NF)

4NF は、ある属性が別の属性の複数の値を決定し、それらの値が互いに独立している場合に発生する 複数値の依存関係 に対処します。次の場合、テーブルは 4NF にあります:

• BCNFにあります。
• 複数値の依存関係はありません。

4NF の例:

4NF (多値依存関係) より前:

StudentID	Subject	Hobby
1	Math	Painting
1	Science	Cycling

---

4NF以降:
テーブル:

• 学生 (StudentID、件名)
• 学生の趣味 (学生ID、趣味)

学生テーブル:

StudentID	Subject
1	Math
1	Science

---

学生の趣味テーブル:

StudentID	Hobby
1	Painting
1	Cycling

---

結論

データベース設計において、正規化はデータを効率的に整理するための基本的なプロセスです。さまざまな正規形式 (1NF、2NF、3NF、BCNF、4NF) により、データが冗長性なく保存され、整合性が維持され、管理が容易になります。それぞれの正規形は、特定の種類の依存関係や異常を排除することによって、前の正規形に基づいて構築されます。正規化によりデータ品質は向上しますが、パフォーマンスに関する考慮事項とのバランスをとることが重要であり、最適化に必要な場合には非正規化を選択することもあります。

こんにちは、アバイ・シン・カタヤットです!
私はフロントエンドとバックエンドの両方のテクノロジーの専門知識を持つフルスタック開発者です。私はさまざまなプログラミング言語やフレームワークを使用して、効率的でスケーラブルでユーザーフレンドリーなアプリケーションを構築しています。
ビジネス用メールアドレス kaashshorts28@gmail.com までお気軽にご連絡ください。

以上がデータベース設計における正規形の理解: 包括的なガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。