DBMSにおけるエンティティ関係の識別とは?強いエンティティと弱いエンティティの違いをわかりやすく解説
DBMS(データベース管理システム)におけるエンティティ関係の識別は、強いエンティティ(Strong Entity)と弱いエンティティ(Weak Entity)の間の関係を特定するために用いられる重要な概念です。
まず始めに、「教授(Professor)」というエンティティを例に考えてみましょう。これは強いエンティティであり、Professor_ID を主キーとして持っています。
| Professor_ID | Professor_Name | Professor_City | Professor_Salary |
一方、弱いエンティティにあたるのが「教授の扶養家族(Professor_Dependents)」というエンティティです。
| Name | DOB(生年月日) | Relation(続柄) |
それでは、各要素について順番に見ていきましょう。
弱いエンティティ(Weak Entity)
弱いエンティティは強いエンティティに依存して存在するエンティティであり、自ら主キーを持たない点が特徴です。その代わりに部分キー(Partial Key)と呼ばれる属性を持ちます。E-R図上では、二重の長方形で表現されます。
強いエンティティ(Strong Entity)
強いエンティティは、他のエンティティが依存する側のエンティティです。キー属性、すなわち主キー(Primary Key)を持っており、一意に識別することができます。E-R図上では、単一の長方形で表現されます。
識別関係(Identifying Relationship)
識別関係は、強いエンティティと弱いエンティティを結びつける役割を果たします。E-R図上では、二重のひし形(Double Diamond)で表現されます。
それでは、実際に識別関係を使って両方のエンティティを結ぶ例を見てみましょう。
この例から分かるように、扶養家族の「名前(Dependent Name)」だけでは単独で存在することはできず、必ず「教授」というエンティティとの関係の中で初めて意味を持ちます。これこそが、弱いエンティティが強いエンティティに依存しているということの本質です。
最後に、今回のE-R図で使用した要素を整理してまとめます。
| 教授(Professor) | 強いエンティティ |
| 扶養家族(Dependent) | 弱いエンティティ |
| 部分キー(弱いエンティティ) | 名前(Name) |
| 主キー(強いエンティティ) | ID(Professor_ID) |
E-R図を設計する際には、どちらのエンティティが強く、どちらが弱いのかを正しく見極めることが、整合性の高いデータベース設計への第一歩となります。
-
DBMSの機能依存性とは？基本概念から種類・アームストロングの公理まで解説
機能依存性（Functional Dependency）とはDBMSにおける機能依存性とは、その名の通り、テーブル内の属性同士が互いに依存し合う関係を指します。リレーショナルデータベースの提唱者であるE.F.コッド（E. F. Codd）によって導入されたこの概念は、データの冗長性を防ぎ、不良なテーブル設計を発見するための重要な手がかりとなります。概念を正確に理解するために、属性AとBを持つ関係Rを考えてみましょう。機能依存性は「→（矢印）」で表現されます。例えば、次のように記述した場合：A → Bこれは「BはAに関数的に依存している」ことを意味します。つまり、属性Aの値が決まれば、属性Bの値
-
DBMSのデッドロックとは？発生条件と対策手法をわかりやすく解説
デッドロックとはデッドロックとは、2つ以上のプロセスが、それぞれ実行の完了に必要なリソースを相手側が保持しており、互いに待ち続けてしまう状態を指します。上記の図では、プロセス1がリソース1を保持しており、リソース2を必要としています。同様に、プロセス2はリソース2を保持し、リソース1を必要としています。どちらのプロセスも相手の持つリソースがなければ処理を完了できないにもかかわらず、自分のリソースを手放そうとしないため、プロセス1とプロセス2はデッドロック状態に陥ります。コフマン条件（Coffman Conditions）デッドロックが発生するのは、次の4つのコフマン条件がすべて成立している場合