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

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

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

第一正規形の要約

データベースが完全に機能的に依存する前に、データベースは最初に準拠する必要があります 第一正規形. これはすべて、各属性が単一のアトミック値を保持する必要があることを意味します。

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

社員	位置
ジョン	ロサンゼルス
ティナ	ロサンゼルス、シカゴ

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

社員	位置
ジョン	ロサンゼルス
ティナ	ロサンゼルス
ティナ	シカゴ

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

2NFが完全な依存関係を確保するためにどのように機能するか

完全に依存するには、すべての非候補キー属性が主キーに依存している必要があります。

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

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

たとえば、次のEmployee Departmentstableでは、 従業員ID と DeptID 両方とも候補キーです： 従業員ID テーブルの主キーですが DeptID 外部キーです。 その他の属性-この場合、 従業員名 と DeptName-値を取得するには、主キーに依存する必要があります。

従業員ID	従業員名	DeptID	DeptName
Emp1	ジョン	Dept001	ファイナンス
Emp2	ティナ	Dept003	販売
Emp3	カルロス	Dept001	ファイナンス

この場合、EmployeeNameは主キーに依存しているため、テーブルは完全には依存していません。 従業員ID、 NS DeptName 代わりにに依存します DeptID. これは部分依存と呼ばれます。

このテーブルを2NFに準拠させるには、データをEmployeesテーブルとDepartmentsテーブルの2つのテーブルに分割する必要があります。 Employeesテーブルは次のとおりです。

従業員ID	従業員名	DeptID
Emp1	ジョン	Dept001
Emp2	ティナ	Dept003
Emp3	カルロス	Dept001

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

DeptID	DeptName
Dept001	ファイナンス
Dept002	人事
Dept003	販売

これで、テーブル間の関係は完全に依存するか、2NFになります。

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

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

たとえば、1NFのみに準拠している上記のセクションの表について考えてみます。 ここに再びあります：

社員	位置
ジョン	ロサンゼルス
ティナ	ロサンゼルス
ティナ	シカゴ

ティナには2つの記録があります。 2つあることに気付かずに1つを更新すると、データに一貫性がなくなります。

または、このテーブルに従業員を追加したいが、場所がまだわからない場合はどうなりますか？ 次の場合、新しい従業員を追加することさえ許可されない可能性があります。 位置 属性はNULL値を許可しません。

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