さまざまな通常のフォーム（1NF、2NF、3NF、BCNF）を説明します。

さまざまな通常のフォーム（1NF、2NF、3NF、BCNF）を説明します。

正規化は、データの冗長性を削減し、データの整合性を改善することを目的としたデータベース設計手法です。異なるレベルの正規化を定義するいくつかの通常の形式があります。それらを詳細に探索しましょう：

1。最初の通常のフォーム（1NF）：
データベースを正規化する最初のステップは、最初の通常の形式であることを確認することです。次の条件を満たす場合、テーブルは1NFにあります。

• テーブルの各列には、原子（不可分）値を含める必要があります。
• 行の各列には、同じタイプの値が含まれている必要があります。
• 各列には一意の名前が必要です。
• データが保存される順序は重要ではありません。

2。2番目の通常のフォーム（2NF）：
1NFにある場合、テーブルは2NFにあり、すべての非キー列がテーブルの主キーに完全に依存しています。つまり、テーブルの主キーが複数の列で構成されている場合、キーの一部のみに依存しないでください。

3。3番目の通常のフォーム（3NF）：
テーブルは2NFにあり、推移的な依存関係がない場合は3NFにあります。これは、非キー列が別の非キー列に依存する場合、別のテーブルに移動する必要があることを意味します。言い換えれば、すべての非キー列は、キー、キー全体、およびキー以外の事実についての事実を提供する必要があります。

4。Boyce-Codd Normal Form（BCNF）：
BCNFは、3NFのより厳しいバージョンです。 3NFにある場合はBCNFにあり、そのわずかな機能的依存関係のすべてについてx-> y、xはスーパーキーです。つまり、xは候補キーまたはそのスーパーセットです。 BCNFは、特定のタイプの機能的依存関係により、3NFテーブルで発生する可能性のある異常の可能性を排除するように設計されています。

1NFと2NFの重要な違いは何ですか？

1NFと2NFの主な違いは、テーブル内の依存関係の性質にあります。

• 1NFはデータの構造に焦点を当て、各セルに原子値が含まれ、データの順序が重要ではないことを確認します。データ項目間の関係には対応していません。
• 一方、 2NFは、部分的な依存関係を排除することにより、1NFに基づいて構築されます。キー列がコンポジット（マルチコラム）プライマリキーを備えたテーブル内のプライマリキーの一部のみに依存する場合、部分依存性が発生します。 2NFでは、すべての非キー列は、プライマリキー全体に完全に機能的に依存する必要があります。

説明するには、複合プライマリキーを備えた1NFのテーブルを検討してください。非キー列が一次キーの一部にのみ依存している場合、2NFに違反します。たとえば、テーブルトラッキングオーダーに複合プライマリキー（OrderID、ProductID）があり、ProductIDのみに依存するProductPrice用の列がある場合、ProductPriceを別のテーブル（ProductIDを主キーとして）に移動すると、元のテーブルが2NFになります。

3NFは、データの冗長性の削減にどのように役立ちますか？

3番目の通常のフォーム（3NF）は、推移的依存関係を排除することにより、データ冗長性を減らす上で重要な役割を果たします。非キー列が別の非キー列に依存すると、推移的依存性が発生し、次にプライマリキーに依存します。

たとえば、従業員（プライマリキー）、DepartmentID、およびDepartmentNameの列を含む2NFのテーブルを検討してください。 DepartmentNameがemployeeDに依存しているDepartmentIDに依存している場合、DepartmentNameはDepartmentIDを介してEmployeeIDに推移的な依存関係を持っています。このセットアップは、同じ部門の名前をテーブルで複数回繰り返す可能性があるため、データの冗長性につながる可能性があります。

これに対処するために、3NFは部門の名前を別の部門テーブルに移動する必要があります（部門がプライマリキーとして）、推移的依存関係を排除します。この正規化ステップにより、DepartmentNameが1回だけ保存され、冗長性が低下し、データの整合性が向上することが保証されます。更新が必要な場合は、1か所のみで作成する必要があり、矛盾のリスクを最小限に抑える必要があります。

BCNFが3NFよりも優先される場合の例を提供できますか？

Boyce-Codd Normal Form（BCNF）は、決定要因（依存関係の左側）がスーパーキーではない場合に機能的な依存関係がある場合、3番目の通常のフォーム（3NF）よりも好まれます。 BCNFは、3NFテーブルで持続する可能性のある異常を排除するためのより厳しい基準を提供します。

大学のコース登録システムを含む例を考えてみましょう。

表：Courseregistration

• 列：StudentID、CourseID、Instructorid

• 機能依存関係：

  • （dustentid、courseid） - > installorid（プライマリキー）
  • instruporid-> courseid（インストラクターは1つのコースのみを教えます）

このシナリオでは、推移的な依存関係がないため、テーブルは3NFにあります。ただし、Instructorid-> CourseIDは、SuperKeyではないInstructoridが別の非キー列であるCourseIDを決定することを意味するため、BCNFに違反します。

BCNFを満たすには、テーブルを2つに分割する必要があります。

表1：courseregistration

• 列：StudentID、CourseID、Instructorid
• 主キー：（ dustentid、courseID）

表2：インストラクターコース

• 列：Instructorid、CourseID
• プライマリキー：Instruporid

これを行うことにより、機能依存関係のすべての決定要因がスーパーキーであることを確認し、BCNF基準を満たしています。この分離は、テーブルが3NFに残った場合に発生する可能性のある挿入、削除、更新の異常などの潜在的な異常を排除します。

以上がさまざまな通常のフォーム（1NF、2NF、3NF、BCNF）を説明します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。