データベース正規化における完全な機能依存性

完全な関数依存は、 第2正規形（2NF）の正規化標準に相当するデータベース正規化の状態です。 簡単に言えば、これはFirst Normal Form（1NF）の要件を満たし、すべての非キー属性は主キーに完全に機能的に依存していることを意味します。

これは聞こえるほど複雑ではありません。 これをもっと詳しく見てみましょう。

最初の正規形の概要

データベースが機能的に完全に依存することができるようにするには、 最初にFirst Normal Formに従わなければなりません。

すべてこれは、各属性が単一の原子値を保持しなければならないことを意味します。

たとえば、次の表は1NFに準拠していません。その理由は、従業員Tinaが2つの場所にリンクされており、その両方が単一のセル内にあります。

この設計を許可すると、データの更新やエントリに悪影響を与える可能性があります。 1NF準拠を保証するには、すべての属性（または列セル）が単一の値を保持するように表を再配置します。

しかし、1NFはまだデータの問題を回避するには十分ではありません。

完全な依存性を保証する2NFの仕組み

完全に依存するには、候補ではないすべてのキー属性は、主キーに依存する必要があります。 （ 候補キー属性は、データベースレコードを一意に識別するために使用される任意のキー（たとえば、プライマリまたは外部キー）であることに注意してください。

データベース設計者は、表記法を使用して属性間の依存関係を記述します。

属性AがBの値を決定するならば、これはA - > B - AがBに機能的に依存していることを意味します。この関係では、AはBの値を決定し、BはAに依存します。

たとえば、次のEmployee Departmentsテーブルでは、EmployeeIDとDeptIDは両方とも候補キーです。EmployeeIDはテーブルの主キーで、DeptIDは外部キーです。

その他の属性（この場合はEmployeeNameおよびDeptName）は、その値を取得するためにプライマリキーに依存する必要があります。

この場合、EmployeeNameは主キーEmployeeIDに依存しますが、DeptNameはDeptIDに依存するため、表は完全に依存しません。 これを部分依存といいます。

このテーブルを2NFに適合させるには、データを2つのテーブルに分割する必要があります。

EmployeesテーブルからDeptName属性を削除し、新しいテーブルを作成しますDepartments ：

現在、テーブル間の関係は完全に依存しているか、2NFにあります。

完全な依存関係が重要な理由

データベースの属性間の完全な依存関係は、データの整合性を保証し、データの異常を回避するのに役立ちます。

たとえば、1NFにのみ従う上記のセクションの表を考えてみましょう。 それはもう一度です：

ティナは2つのレコードを持っています。 2つがあることを認識せずに1つを更新すると、結果として矛盾したデータになります。

または、このテーブルに従業員を追加したいのですが、その場所をまだ知っていませんか？ Location属性でNULL値が許可されていない場合は、新しい従業員を追加することもできません。

しかし、正規化に関しては、完全な依存関係は全体像ではありません。 データベースがThird Normal Form （3NF）になっていることを確認する必要があります。