DBMS-正規化

機能従属性

関数従属性(FD)は、リレーション内の2つの属性間の一連の制約です。関数従属性は、2つのタプルが属性A1、A2、...、Anに対して同じ値を持つ場合、それらの2つのタプルは属性B1、B2、...、Bnに対して同じ値を持つ必要があることを示しています。

関数従属性は、矢印記号(→)、つまりX→Yで表されます。ここで、Xは機能的にYを決定します。左側の属性は、右側の属性の値を決定します。

アームストロングの公理

Fが関数従属性のセットである場合、F +として示されるFの閉包は、Fによって論理的に暗示されるすべての関数従属性のセットです。アームストロングの公理は、繰り返し適用されると関数従属性の閉包を生成する一連のルールです。 。

  • Reflexive rule − alphaが属性のセットであり、beta is_subset_of alphaの場合、alphaはbetaを保持します。

  • Augmentation rule− a→bが成り立ち、yが属性セットの場合、ay→byも成り立ちます。つまり、依存関係に属性を追加することであり、基本的な依存関係は変更されません。

  • Transitivity rule−代数の推移規則と同じように、a→bが成り立ち、b→cが成り立つ場合、a→cも成り立ちます。a→bは、bを決定する関数として呼び出されます。

些細な機能依存性

  • Trivial−関数従属性(FD)X→Yが成り立つ場合(YはXのサブセット)、それは自明なFDと呼ばれます。些細なFDは常に成り立ちます。

  • Non-trivial − FD X→Yが成り立つ場合(YはXのサブセットではない)、それは自明でないFDと呼ばれます。

  • Completely non-trivial − FD X→Yが成り立ち、xがY =Φと交差する場合、それは完全に自明でないFDであると言われます。

正規化

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

  • Update anomalies−データ項目が散在し、適切にリンクされていない場合、奇妙な状況につながる可能性があります。たとえば、コピーが複数の場所に散在している1つのデータ項目を更新しようとすると、いくつかのインスタンスが適切に更新され、他のいくつかのインスタンスには古い値が残ります。このようなインスタンスは、データベースを不整合な状態のままにします。

  • Deletion anomalies −レコードを削除しようとしましたが、知らないうちに一部が削除されず、データも別の場所に保存されています。

  • Insert anomalies −まったく存在しないレコードにデータを挿入しようとしました。

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

第一正規形

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

関係(表)を以下のように再配置して、第一正規形に変換します。

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

2番目の正規形

2番目の正規形について学習する前に、次のことを理解する必要があります。

  • Prime attribute −候補キーの一部である属性は、プライム属性と呼ばれます。

  • Non-prime attribute −プライムキーの一部ではない属性は、非プライム属性であると言われます。

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

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

上の写真のように、関係を2つに分けました。したがって、部分的な依存関係はありません。

第3正規形

関係が第3正規形であるためには、それは第2正規形である必要があり、以下は-を満たす必要があります。

  • 非プライム属性が一時的にプライムキー属性に依存することはありません。
  • 自明でない関数従属性の場合、X→Aの場合、次のいずれか-
      Xはスーパーキーまたは、
    • Aは主要な属性です。

上記のStudent_detail関係では、Stu_IDがキーであり、主要なキー属性のみであることがわかります。Cityは、Zip自体だけでなくStu_IDでも識別できることがわかりました。Zipはスーパーキーではなく、Cityも主要な属性ではありません。さらに、Stu_ID→Zip→Cityなので、存在しますtransitive dependency

この関係を第3正規形にするために、次のように関係を2つの関係に分割します。

ボイスコッド正規形

Boyce-Codd Normal Form(BCNF)は、厳密な条件でのThird NormalFormの拡張です。BCNFは次のように述べています-

  • 重要な機能依存性の場合、X→A、Xはスーパーキーである必要があります。

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

Stu_ID→Stu_Name、Zip

そして

Zip→City

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