エンティティが弱いかどうかを実際に判断する方法
これはウィキペディアのER図の例です。ここでは、Ordersエンティティを強力なエンティティとしてマークしています。
私が理解しているように、弱いエンティティは、対応する強いエンティティなしでは存在できないエンティティです。
この場合、Ordersエンティティは存在-Customerエンティティに依存していると思います。対応する顧客がいなければ注文は存在しないからです。
つまり、Ordersエンティティの主キーを持つことができても、それはCustomerに依存しているのではないでしょうか？弱いエンティティである必要はありませんか？
誰かがこれを説明できたらうれしいです。
一部の概念をエンティティとしてモデル化するか、弱いエンティティとしてモデル化するかは、少し揺れ動く余地があります。
弱いエンティティは別のエンティティなしでは存在できないというあなたの考えは間違っていません。それは単に定義機能ではありません。強いエンティティは、弱いエンティティになることなく他のエンティティを参照できます。
代わりに、エンティティに含まれる値とは無関係にエンティティが存在するかどうかを確認する必要があります。データベースでは、この質問は通常、次と同等です。このエンティティにはIDがありますか？
強力なエンティティは、その値に関係なく存在するため、IDでのみ識別できます。データモデルでは、2人の異なる顧客が同じ住所に住むことができますが、CustomerNumberが異なるため、異なる顧客です。ここでは、OrdersにOrderNumberがあることをモデル化しています。
弱いエンティティは、その値によって識別されます。ここで、OrderItemは、Order + ItemLineNumber（複合キー）の組み合わせによって識別されます。複数のアイテムが異なる注文の一部である場合、複数のアイテムが同じ行番号を持つ可能性があるため、ItemLineNumberはそれ自体が主キーではありません。
もちろん、これは別の方法でモデル化することもできます。 Ordersは、Customer + OrderNumberで識別される弱いエンティティである可能性があります。または、各OrderItemにIDフィールドを設定して、強力なエンティティに昇格させることもできます。
では、どのバリアントをいつ選択すればよいですか？これは完全にコンテキストに依存します。 「XはYに属している」または「XはYなしでは存在できない」というルールは、Xが弱いエンティティである可能性があることを示す適切なヒューリスティックです。次に、問題のドメインについて考えます。例えば。私の国では、請求書には一意の番号が必要なので、注文のIDとして請求書番号を使用することは理にかなっています。注文には自然キー/ドメインキーがあります。また、データベースがどのように照会されるかについても考慮する必要があります。エンティティが外部キー参照のターゲットである場合、それがIDを持つ強力なエンティティであると、クエリがはるかに簡単になります。代理キー/合成キーを割り当てることができます。
ウィキペディアで 記事 あなたが言及している、それは言う：
弱いエンティティは、その属性だけでは一意に識別できないエンティティです。
アイデアは、エンティティ自体に不完全な情報が含まれているということです。図示の例では、severalOrderItemエンティティがすべて同じ属性を持っている可能性があります（OrderNumber FK）ですが、実際にはdifferentOrderエンティティに関連しています。
対照的に、各Orderは、その主キーによって一意に決定されます。はい、Customerとの関係は存在しますが、CustomerNumberへの参照が削除されても、注文のIDは失われないことに注意してください。 （確かに、注文があり、顧客が誰であるかわからないのは少し奇妙ですが、これが概念化されている方法では、注文は実際には顧客とは独立して存在します。）