DBMS-正規化

機能依存性

機能依存性（FD）は、リレーションの2つの属性間の制約のセットです。機能的な依存関係によると、2つのタプルの属性A1、A2、…、Anの値が同じ場合、これらの2つのタプルの属性B1、B2、…、Bnの値は同じである必要があります。

機能的な依存関係は、矢印記号（→）、つまりX→Yで表されます。Xは機能的にYを決定します。左側の属性は、右側の属性の値を決定します。

アームストロングの公理

Fが機能的な依存関係のセットである場合、F ^ + ^として示されるFの閉包は、Fによって論理的に暗示されるすべての機能的な依存関係のセットです。 Armstrongの公理は一連のルールであり、繰り返し適用されると機能的な依存関係の閉鎖を生成します。

再帰ルール-アルファが属性のセットであり、ベータがアルファのis_subset_ofである場合、アルファはベータを保持します。
拡張ルール-a→bが成り立ち、yが属性設定されている場合、ay→byも成り立ちます。それは依存関係に属性を追加することであり、基本的な依存関係は変更しません。
推移性ルール-代数の推移性ルールと同じ。a→bが成り立ち、b→cが成り立つ場合、a→cも成り立つ。 a→bは、bを決定する関数として呼び出されます。

些細な機能依存

Trivial -機能的依存関係（FD）X→Yが成り立つ場合（YはXのサブセット）、それは自明なFDと呼ばれます。単純なFDは常に有効です。
非自明-FD X→Yが成り立つ場合、YはXのサブセットではないので、非自明FDと呼ばれます。
完全に非自明-FD X→Yが成り立つ場合、xがY =Φと交差する場合、完全に自明ではないFDと言われます。

正規化

データベース設計が完全でない場合、異常が含まれている可能性があり、これはデータベース管理者にとっては悪い夢のようです。異常を伴うデータベースの管理はほとんど不可能です。

更新の異常-データ項目が散在し、互いに適切にリンクされていない場合、奇妙な状況につながる可能性があります。たとえば、コピーが複数の場所に散らばっている1つのデータ項目を更新しようとすると、いくつかのインスタンスが適切に更新され、他のいくつかのインスタンスには古い値が残ります。このようなインスタンスは、データベースを一貫性のない状態のままにします。
削除の異常-レコードを削除しようとしましたが、その一部が認識されないために削除されずに残っており、データも別の場所に保存されています。
異常の挿入-まったく存在しないレコードにデータを挿入しようとしました。

正規化は、これらすべての異常を取り除き、データベースを一貫した状態にする方法です。

最初の標準形

最初の正規形は、関係（テーブル）自体の定義で定義されます。このルールは、リレーションのすべての属性にアトミックドメインが必要であることを定義します。アトミックドメインの値は分割できない単位です。

未整理の関係

以下のようにリレーション（テーブル）を再配置し、それを最初の正規形に変換します。

1NFの関係

各属性には、定義済みのドメインからの単一の値のみが含まれている必要があります。

第2正規形

私たちは2番目の正規形について学ぶ前に、次を理解する必要があります-

プライム属性-候補キーの一部である属性は、プライム属性として知られています。
非プライム属性-プライムキーの一部ではない属性は、非プライム属性と呼ばれます。

2番目の標準形式に従う場合、すべての非プライム属性は完全に機能的にプライムキー属性に依存する必要があります。つまり、X→Aが成り立つ場合、Yの適切なサブセットYが存在してはならず、Y→Aも成り立ちます。

2NF以外の関係

ここで、Student_Projectリレーションでは、プライムキー属性がStu_IDとProj_IDであることがわかります。ルールによれば、非キー属性、つまり Stu_NameとProj_Nameは、主キー属性に個別に依存するのではなく、両方に依存する必要があります。ただし、Stu_NameはStu_IDで識別でき、Proj_NameはProj_IDで個別に識別できることがわかります。これは*部分依存性*と呼ばれ、第2正規形では許可されていません。

2NFの関係

上記の図に示すように、2つの関係を壊しました。したがって、部分的な依存関係は存在しません。

第3正規形

関係が第3正規形であるためには、第2正規形である必要があり、次の条件を満たす必要があります-

プライムキー属性に推移的に依存する非プライム属性はありません。
自明でない機能的依存関係の場合、X→A、次に
Aは主要な属性です。

3NF以外の関係

上記のStudent_detail関係では、Stu_IDがキーで唯一のプライムキー属性であることがわかります。 Cityは、Stu_IDとZip自体によって識別できることがわかります。 Zipはスーパーキーでも、Cityも主要な属性ではありません。さらに、Stu_ID→Zip→Cityであるため、*推移的な依存関係*が存在します。

この関係を第3の正規形にするには、次のように関係を2つの関係に分けます-

3NFの関係

ボイスコッド標準形

Boyce-Codd Normal Form（BCNF）は、厳密な用語でのThird Normal Formの拡張です。 BCNFの状態-

自明でない機能依存関係、X→Aの場合、Xはスーパーキーでなければなりません。

上の画像では、Stu_IDはリレーションStudent_Detailのスーパーキーであり、ZipはリレーションZipCodesのスーパーキーです。 So,

Stu_ID→Stu_Name、Zip

and

郵便番号→都市

これは、両方の関係がBCNFにあることを確認します。

Dbms-database-normalization

目次