ホームページ > データベース > mysql チュートリアル > データベース設計における正規形の理解: 包括的なガイド

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

Susan Sarandon
リリース: 2024-12-31 22:19:09
オリジナル
754 人が閲覧しました

Understanding Normal Forms in Database Design: A Comprehensive Guide

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

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

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


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)

3NF2NF に基づいて構築され、非プライム属性が別の非プライム属性に依存するときに発生する 推移的な依存関係 に対処します。非主属性は主キーのみに依存する必要があります。テーブルが 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 サイトの他の関連記事を参照してください。

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
著者別の最新記事
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート