[データベース] 関数の依存関係、候補キー

機能的な依存関係

データベースでは、関数の依存関係とは、一方の属性の値が他方の属性の値を一意に決定できる 2 つの属性間の関係を指します。リレーショナル データベースでは、関数の依存関係とは、1 つ以上の属性の値が他の属性の値を一意に決定できることを意味します。

例えば、学生テーブルでは、学生の学生IDによって学生の名前、性別、年齢などが一意に決まるため、「学生IDによって名前、性別、年齢などの属性が決まる」と言えます。

リレーショナル データベースでは、機能の依存関係はデータベースの設計と正規化の基礎であり、データの整合性と一貫性の確保に役立ちます。たとえば、ある属性の値は他の属性の値に依存しており、これらの依存関係が適切に定義および管理されていない場合、データが冗長で、一貫性がなく、不完全になる可能性があります。

完全な機能依存性

属性セット X は Y に完全に依存しています。つまり、R では、X の適切なスーパーセットが関数依存関係 Y を満たさない場合、Y は X に完全に依存していると言われます。簡単に言うと、X のいずれかの属性を削除すると、Y を一意に決定できなくなります。

例えば、学務部が、ある科目の学生の成績を知りたい場合、学生の学籍番号と科目名、つまり、(X,Y)→Zを知る必要があり、どちらも必須です
。 。これは、Z がセット (X,Y) に完全に依存していることを意味します。

部分的な関数依存性

属性セット X は部分的に Y に依存しています。これは、R には、X' ->
Y となるような X の適切なサブセット X' が存在することを意味します。つまり、Y は、X 自体ではなく、X の適切なサブセットに依存します。簡単に言うと、X の一部の属性が削除されても、Y は依然として一意に決定できます。

たとえば、学務部が学生の平均成績を知りたい場合、コース名は必要なく、学生番号だけが必要です。この場合、U は部分的に集合 (X,Y) に依存します。

推移的な関数の依存関係

属性セット X は Y に推移的に依存します。これは、R には、X -> Z および Z -> Y となる Z が存在することを意味します。つまり、Y は X の間接的なサブセットに依存します。簡単に言えば、X は間接的に Y を決定します。

候補キー

候选键是关系模型中的一组属性,可以唯一地标识关系模型中的每一个元组。

候选键的属性个数最小化,也就是说,不能存在多余的属性。

候选键的属性不能是空值(NULL)。

在一个关系模型中,可能会存在多个候选键,这些候选键中的任何一个都可以被选作主键。

候选键是在满足第一范式的基础上进行的规范化处理。

注: 関数の依存関係では、入次数が 0 の属性が候補キー セットに含まれている必要があります。

このうち、候補キーを構成する属性を主属性それ以外の属性を非主属性といいます。

データベースの 3 つのパラダイム

1NF
第一正規形 (1NF): 必須の属性はアトミックです

第 1 正規形では、関係内のすべての属性がアトミックである必要があります。つまり、属性は分解できません。リレーションシップはテーブルであり、属性はテーブル内の列です。属性に複数の値が含まれている場合、データの冗長性や不整合などの問題が発生し、データベースのパフォーマンスに影響します。

たとえば、テーブルに「名前、性別、年齢」の 3 つの属性が含まれている場合、「名前」列の姓と名が別々に格納されている場合、第 1 正規形に準拠しません。

2NF
第 2 正規形では、リレーショナル テーブル内の属性が主キーに完全に依存している必要があります。つまり、主キー以外の属性は主キーの一部ではなくすべての主キーに依存している必要があります。属性が主キーの一部のみに依存している場合、データの冗長性と更新の例外が発生します。

例えば、テーブルに「注文番号、商品番号、商品名、商品単価、注文数量、合計金額」といった属性が含まれている場合、「商品名、商品単価」を別のテーブルに分離すれば、重複を排除できます。 。

3NF

第 3 正規形では、リレーショナル テーブル内の非主キー属性が他の非主キー属性に依存しないことが要求されます。属性が別の非主キー属性に依存している場合、データの冗長性が発生し、更新例外が発生します。

例えば、テーブルに「生徒番号、科目番号、科目名、教師名、教師電話番号」といった属性が含まれている場合、「教師名、教師電話番号」を別のテーブルに分離すれば、重複を排除できます。

おすすめ

転載: blog.csdn.net/qq_44878985/article/details/130493640