弱いエンティティは主キーを持つことができますか？
おそらく非常に基本的な質問で申し訳ありませんが、文献とオンラインで、弱いエンティティの2つの異なる定義に出くわしました。
1）弱いエンティティは、他の（所有者）エンティティなしには存在できないエンティティです。
2）弱いエンティティには主キーではなく部分キーがあり、この部分キーを所有者エンティティの外部キーと組み合わせることによってのみ一意に識別できます。
これらのうちどれが本当ですか？ Customers-> Orders関係の例を見てみましょう。ここで、注文には一意のOrderIDがあります。ここで、注文は顧客なしでは存在できませんが、それでも独自の主キーがあります。それはそれで強い実体か弱い実体か？
主キーは、1つのテーブル内の1つの行を、同じテーブル内の他のすべての行と区別する方法です。関連付けられた行のコンテキストで1つの行を他のテーブルと区別する方法ではありません。
テーブルの主キーが単一の列で構成される場合があります。個人のuser_idがその例です。
時にはそれはいくつかの列で構成されています。場所は緯度と経度の両方です。これは複合キーと呼ばれます。これらの列の1つ以上が外部キーになる場合もあります。これは弱いエンティティタイプと呼ばれます。
例を挙げましょう。Ordersテーブルの1つの行を、Order Numberだけで他のすべての行と区別できますか？通常、はい。注文番号はシステム全体で一意です。したがって、注文番号8765が与えられた場合、それは顧客Aのものであることがわかります。これにより、注文が強力なエンティティタイプになります。
OrderLineテーブルはどうですか？ 「1」のように単一の注文明細行番号を指定すると、関連する注文を明確に見つけることができますか？通常、いいえ。注文ごとに注文ライン番号が再び開始されるためです。したがって、OrderLineは弱いエンティティです。その主キー（注文番号、注文明細番号）には、別の関連テーブルviz。 Orderの主キーが必要なためです。
businessルールによると、顧客なしでOrderが存在することは意味がありませんが、-databaseルールによると、これは問題ありません。 OrderLineは、どちらのルールセットの下でもOrderなしでは存在できません。
どちらも正しい定義です。注文は強力なエンティティです。それはそれ自体で存在します。ただし、OrderItemsは脆弱です。注文番号（外部キー）と行番号（部分キー）があります。両方で一意に識別されるだけです。
弱いエンティティには複合主キーがあります。
http://www.ques10.com/p/3828/we-can-convert-any-entity-set-to-a-strong-entity-s/
エンティティセットPaymentが3つの属性を持っていると考えてください。各支払いエンティティは異なりますが、異なるローンの支払いは同じ支払い番号を共有する場合があります。したがって、このエンティティセットには主キーがなく、エンティティセットです。各弱いセットは、1対多の関係セットの一部である必要があります。次の理由により、弱いエンティティセットが必要です。
- 強力なエンティティのキーの複製によって引き起こされる不整合を回避するため。
私。 適切な属性を追加するだけで、弱いエンティティセットを強いエンティティセットに変換できますが、このアプローチでは、主キーの冗長ストレージが発生します。
ii。弱いエンティティセットの主キーは、強いエンティティセットとの関係から推測できます。ウィークエンティティセットに主キー属性を追加する場合、それらはエンティティセットと関係セットの両方に存在し、同じでなければなりません。
iii。したがって、ER図には冗長性があり、依存関係の概念が失われます。
iv。上記の例では、弱いエンティティセットPaymentに主キー属性を追加すると、主キーが冗長に保存されます。