DBMSでのエンティティ関係の識別
始める前に、教授の例を見てみましょう。 強力なエンティティであるエンティティ 、 Professor_ID 主キーとして −
| Professor_ID | Professor_Name | Professor_City | Professor_Salary |
弱い実体はProfessor_Dependents エンティティ：
| 名前 | DOB | 関係 |
では、続けましょう
弱実体
弱いエンティティは強いエンティティに依存しており、主キーを持っていません。弱実体には部分的なキーがあります。二重長方形として表されます-
強力なエンティティ
他のエンティティはStrongEntityに依存しており、キー属性、つまり主キーを持ち、単一の長方形として表されます。
関係の特定
強い実体と弱い実体を結び、二重のひし形の記号で表されます。
関係の識別を使用して両方のエンティティをリンクする例を見てみましょう：
上記で見たように、扶養家族の名前はそれ自体では存在できず、教授との関係で存在することができました。
残り、E-R図で使用した次の-
| 教授 | 強力なエンティティ |
| 依存 | 弱実体 |
| 部分キー（弱実体） | 名前 |
| 主キー（強力なエンティティ） | ID |
-
DBMSの機能依存性
機能従属性とは 名前が示すように、DBMSの機能依存性は、相互に依存するテーブルの属性間の関係です。 E. F. Coddによって導入され、データの冗長性を防ぎ、悪い設計について知るのに役立ちます。 （矢印記号）で表されます。 次に、以下は矢印記号-で属性間の機能依存性を表します。 B 上記は次のことを示唆しています： 例 以下は、関数従属性を理解しやすくする例です- があります 2つの属性を持つテーブル-DeptId およびDeptName 。 DeptId =部門ID DeptName =部門名 DeptId 主キ
-
DBMSのデッドロック
デッドロックは、2つ以上のプロセスが、他のプロセスによって保持されている実行を完了するために何らかのリソースを必要とする場合に発生します。 上の図では、プロセス1にはリソース1があり、リソース2が必要です。同様にプロセス2にはリソース2があり、リソース1が必要です。これらの各プロセスは、完了するために他のリソースを必要としますが、どちらもリソースを放棄する意思はありません。したがって、プロセス1とプロセス2はデッドロック状態にあります。 コフマンの状態 デッドロックは、4つのコフマン条件が当てはまる場合にのみ発生します。これらの条件は、必ずしも相互に排他的ではありません。それらは： 相