DBMSの機能依存性
名前が示すように、DBMSの機能依存性は、相互に依存するテーブルの属性間の関係です。 E. F. Coddによって導入され、データの冗長性を防ぎ、悪い設計について知るのに役立ちます。
概念を完全に理解するために、Pは属性AおよびBとの関係であると考えてみましょう。関数従属性は->（矢印記号）
で表されます。次に、以下は矢印記号-
で属性間の機能依存性を表します。| A-> B |
上記は次のことを示唆しています：
例
以下は、関数従属性を理解しやすくする例です-
<部門>があります 2つの属性を持つテーブル-DeptId およびDeptName 。
| DeptId =部門ID DeptName =部門名 |
DeptId 主キーです。ここでは、 DeptId DeptNameを一意に識別します 属性。これは、部門名を知りたい場合は、最初に DeptIdが必要になるためです。 。
| DeptId | DepartmentName |
| 001 | 財務 |
| 002 | マーケティング |
| 003 | HR |
したがって、 DeptId間の上記の機能依存性 およびDeptName DeptIdとして決定できます DeptNameに機能的に依存しています −
| DeptId-> DeptName |
機能従属性の種類
関数従属性には3つの形式があります-
- 重要な機能依存性
- 非自明な機能依存性
- 完全に非自明な機能依存性
自明な機能従属性から始めましょう-
重要な機能依存性
これは、Bが-
のAのサブセットである場合に発生します。| A-> B |
例
同じ<部門>を検討しています 自明な依存関係の概念を理解するための2つの属性を持つテーブル。
以下は、 DeptId以降の些細な機能依存性です。 DeptIdのサブセットです およびDeptName
| {DeptId、DeptName}-> Dept Id |
非自明な機能依存性
これは、Bが-
のAのサブセットではない場合に発生します。| A-> B |
例
| DeptId-> DeptName |
DeptNameはDeptIdのサブセットではないため、上記は重要な機能依存性です。
完全に非自明な機能依存性
-
でA交差点Bがnullの場合に発生します| A-> B |
関数従属性のArmstrongのAxiomsプロパティ
ArmstrongのAxiomsプロパティは、機能依存性について推論するために1974年にWilliamArmstrongによって開発されました。
プロパティは、以下が満たされる場合に当てはまるルールを提案します。
- 推移性
A->BおよびB->Cの場合、A-> C、つまり推移的な関係です。 - 再帰性
A-> B、BがAのサブセットである場合。 - 拡張
最後のルールは次のことを示唆しています：AC-> BC、A-> B
-
DBMSのデータディクショナリ
データディクショナリはデータベースメタデータで構成されています。データベース内のオブジェクトに関するレコードがあります。 データディクショナリの構成 データディクショナリは次の情報で構成されています- データベース内のテーブルの名前 テーブルの制約（キー、関係など） 相互に関連するテーブルの列 テーブルの所有者 オブジェクトの最後にアクセスされた情報 オブジェクトの最後に更新された情報 データディクショナリの例としては、学生の個人情報があります- 例 Student_ID Student_Name Student_Address Stu
-
DBMSのデッドロック
デッドロックは、2つ以上のプロセスが、他のプロセスによって保持されている実行を完了するために何らかのリソースを必要とする場合に発生します。 上の図では、プロセス1にはリソース1があり、リソース2が必要です。同様にプロセス2にはリソース2があり、リソース1が必要です。これらの各プロセスは、完了するために他のリソースを必要としますが、どちらもリソースを放棄する意思はありません。したがって、プロセス1とプロセス2はデッドロック状態にあります。 コフマンの状態 デッドロックは、4つのコフマン条件が当てはまる場合にのみ発生します。これらの条件は、必ずしも相互に排他的ではありません。それらは： 相