Loading article…
リレーショナル データベースでは、 弱いエンティティとは、その属性だけでは一意に識別できないエンティティです。したがって、外部キーをその属性と組み合わせて使用して主キーを作成する必要があります。外部キーは通常、関連するエンティティの主キーです。
外部キーは、識別エンティティセット（または所有者、親、または主要エンティティセット）の属性です。弱いエンティティセット内の各要素は、所有者エンティティセット内の正確に1つの要素と関係を持つ必要があります。[1]したがって、関係は多対多の関係にすることはできません。
2つのエンティティは、それぞれが独自の属性を持っている限り、一方が他方に依存している場合でも、どちらかが弱いエンティティとして分類されることなく関連付けることができます。[1]たとえば、人エンティティは、どちらかが弱いエンティティと見なされることなく、 車にリンクできます。
エンティティ関係図 (ER 図)では、弱いエンティティ セットは、太字 (または二重線) の四角形 (エンティティ) と、太字 (または二重線) の矢印で太字 (または二重線) のひし形 (関係) が接続された形で示されます。このタイプの関係は識別関係と呼ばれ、IDEF1X表記では、基本テーブルでは四角形のエンティティではなく楕円形のエンティティで表されます。識別関係とは、主キーが子の弱いエンティティにそのエンティティの主キーとして設定される関係です。
一般的に (必ずしもそうとは限りませんが)、弱いエンティティの主キーには、継承された主キーとシーケンス番号以外の項目はありません。弱いエンティティには、連想エンティティとサブタイプ エンティティの 2 種類があります。後者は、スーパータイプ エンティティが識別子の値に基づいてサブタイプ エンティティに属性を継承する、重要なタイプの正規化を表します。
要件を把握するための政府標準であるIDEF1Xでは、考えられるサブタイプの関係は次のとおりです。
- すべてのカテゴリがわかっている場合のサブタイプの関係を完了します。
- すべてのカテゴリが不明な場合の、不完全なサブタイプの関係。
サブタイプの関係を持たない弱いエンティティの典型的な例としては、クレーム、注文、請求書など、多くの実際の状況における「ヘッダー/詳細」レコードが挙げられます。ヘッダーはすべてのフォームに共通する情報を取得し、詳細は個々の項目に固有の情報を取得します。
完全なサブタイプ関係の標準的な例は、パーティエンティティです。識別子 PARTY TYPE (個人、パートナーシップ、C 法人、サブ チャプター S 協会、協会、政府機関、準政府機関など) が指定されている場合、2 つのサブタイプ エンティティは、姓名や生年月日などの個人固有の情報を含む PERSON と、正式名称やコスト センターなどの組織階層などの属性を含む ORGANIZATION です。
サブタイプの関係がデータベースにレンダリングされると、スーパータイプはベース テーブルと呼ばれるものになります。サブタイプは派生テーブルと見なされ、弱いエンティティに対応します。参照整合性は、カスケード更新と削除によって強制されます。
例
顧客の注文を記録するデータベースを考えてみましょう。注文は、企業が販売する 1 つ以上の品目に対するものです。データベースには、顧客番号 (主キー) で顧客を識別するテーブル、製品番号 (主キー)で販売可能な製品を識別するテーブル、および注文を記述する 1 組のテーブルが含まれます。
テーブルの 1 つを Orders と呼び、このテーブルには、この注文を一意に識別するための注文番号 (主キー) と、製品の販売先を識別するための顧客番号 (外部キー) が含まれます。さらに、注文が行われた日時、支払い方法、配送先などのその他の情報も含まれます。
もう 1 つのテーブルはOrderItemという名前で、注文番号 (外部キー) と品目番号の両方で構成される複合キーで識別されます。また、注文された製品番号 (外部キー)、数量、価格、割引、特別オプションなどの他の非主キー属性も識別されます。Orderエントリに対応するOrderItemエントリは 0 個、1 個、または複数個ある可能性がありますが、対応する Order エントリが存在しない限り、 OrderItemエントリは存在できません ( OrderItemが 0 の場合は通常、注文が最初に入力され、最初の注文品目が記録される前に一時的にのみ適用されます)。
OrderItemテーブルに弱いエンティティが格納されるのは、OrderItemが Order から独立して意味を持たないためです。OrderItemはそれ自体に何らかの意味を持つと主張する人もいるかもしれません。つまり、レコードで識別されていないある時点で、レコードで識別されていない誰かが特定の製品を特定の数量注文したことを記録します。この情報はそれ自体でいくらか役立つかもしれませんが、その用途は限られています。たとえば、商品の販売の季節的または地理的傾向を調べたい場合、関連する Order レコードの情報が必要になります。
注文は、製品と注文を作成する人がいなければ存在しないため、注文は弱いエンティティとして記述され、注文された製品は注文の多値属性になると主張することもできます。