完全な関数依存は、第2正規形（2NF）の正規化標準に相当するデータベース正規化の状態です。簡単に言えば、これはFirst Normal Form（1NF）の要件を満たし、すべての非キー属性は主キーに完全に機能的に依存していることを意味します。
これは聞こえるほど複雑ではありません。これをもっと詳しく見てみましょう。
最初の正規形の概要
データベースが機能的に完全に依存することができるようにするには、最初にFirst Normal Formに従わなければなりません。
すべてこれは、各属性が単一の原子値を保持しなければならないことを意味します。
たとえば、次の表は ない 従業員のTinaは1つのセル内の2つの場所にリンクされているため、1NFに準拠しています。
| 従業員 | ロケーション |
|---|---|
| ジョン | ロサンゼルス |
| ティナ | ロサンゼルス、シカゴ |
この設計を許可すると、データの更新やエントリに悪影響を与える可能性があります。 1NF準拠を保証するには、すべての属性（または列セル）が単一の値を保持するように表を再配置します。
最初の標準フォームコンプライアンス
しかし、1NFはまだデータの問題を回避するには十分ではありません。
完全な依存性を保証する2NFの仕組み
完全に依存するには、候補ではないすべてのキー属性は、主キーに依存する必要があります。 （候補キー属性は、データベースレコードを一意に識別するために使用される任意のキー（たとえば、プライマリまたは外部キー）であることに注意してください。
データベース設計者は、表記法を使用して属性間の依存関係を記述します。
属性AがBの値を決定すると、これを書いていますA→B - Bは機能的にAに依存していることを意味します。この関係では、AはBの値を決定し、BはAに依存します。
例えば、以下の 従業員部門 テーブル、EmployeeIDとDeptIDはどちらも候補キーです。EmployeeIDはテーブルの主キーで、DeptIDは外部キーです。
その他の属性（この場合はEmployeeNameおよびDeptName）は、その値を取得するためにプライマリキーに依存する必要があります。
| 従業員ID | 従業員名 | DeptID | DeptName |
|---|---|---|---|
| Emp1 | ジョン | Dept001 | ファイナンス |
| Emp2 | ティナ | Dept003 | 販売 |
| Emp3 | カルロス | Dept001 | ファイナンス |
この場合、EmployeeNameは主キーEmployeeIDに依存しますが、DeptNameはDeptIDに依存するため、表は完全に依存しません。これは 部分依存 .
このテーブルを2NFに適合させるには、データを2つのテーブルに分割する必要があります。
| 従業員ID | 従業員名 | DeptID |
|---|---|---|
| Emp1 | ジョン | Dept001 |
| Emp2 | ティナ | Dept003 |
| Emp3 | カルロス | Dept001 |
我々は、DeptName属性を 従業員 テーブルを作成して新しいテーブルを作成する 部署 :
| DeptID | DeptName |
|---|---|
| Dept001 | ファイナンス |
| Dept002 | 人事 |
| Dept003 | 販売 |
現在、テーブル間の関係は完全に依存しているか、2NFにあります。
完全な依存関係が重要な理由
データベースの属性間の完全な依存関係は、データの整合性を保証し、データの異常を回避するのに役立ちます。
たとえば、1NFにのみ従う上記のセクションの表を考えてみましょう。それはもう一度です：
| 従業員 | ロケーション |
|---|---|
| ジョン | ロサンゼルス |
| ティナ | ロサンゼルス |
| ティナ | シカゴ |
ティナは2つのレコードを持っています。 2つがあることを認識せずに1つを更新すると、結果として矛盾したデータになります。
または、このテーブルに従業員を追加したいのですが、その場所をまだ知っていませんか？ Location属性でNULL値が許可されていない場合は、新しい従業員を追加することもできません。
しかし、正規化に関しては、完全な依存関係は全体像ではありません。データベースがThird Normal Form（3NF）になっていることを確認する必要があります。
