これは基本的に、弱いエンティティとは何かに関する質問ですか？それらをいつ使用する必要がありますか？どのようにモデル化する必要がありますか？
通常のエンティティと弱いエンティティの主な違いは何ですか？ドメイン駆動設計を行う場合、脆弱なエンティティは値オブジェクトに対応しますか？
ここでトピックに関する質問を続けるのを助けるために、人々がこれらの質問に答えるために使用できるウィキペディアから取られた例です：
この例でOrderItemは、弱いエンティティとしてモデル化されましたが、通常のエンティティとしてモデル化できない理由を理解できません。
もう1つの質問は、注文履歴（つまり、ステータスの変更）を追跡したい場合、それは通常のエンティティまたは脆弱なエンティティでしょうか？
回答:
正式には「弱い」エンティティには次の特性があります。
1. It is existence-dependent on another entity, i.e.,
it cannot exist without the entity with which it has a relationship.
2. It inherits at least part of it's primary key from the entity to which
it is related.
i.e. -> A weak entity's primary key must be a composite key that includes
the primary key of the entity on which it is existence-dependent.
実際には、何かをそれ自体が「弱い」エンティティにすることを明確に決定することはないでしょう。代わりに、モデル化しようとしているものを代表するようにデータを構造化します。これを行った後、特定のエンティティを見て、そのエンティティが「弱い」エンティティの特性を持っている場合、何らかの理由でこれを明示的に呼び出す必要があると感じた場合、それに応じて文書化または図化することができます形式的な。
上の図の私の理解によれば、2つのエンティティが設計されている場合に情報へのアクセスが簡単になるように、1つではなく2つのエンティティ/テーブルが含まれています。また、注文アイテムは注文エンティティに依存しているため、弱いエンティティと見なされます。弱いエンティティの特性は、別のエンティティに依存しているためです。注文アイテムエンティティを含めない場合、注文アイテムの価格、割引をどのように知ることができると仮定します。jgauffinが言ったように、たとえば注文を削除した場合、商品の配送先を知る方法がありません。または、製品を削除した場合、何を出荷すればよいかわかりません。
ER図は、ビジネス要件に従って設計されます。
を参照してください。注文には多くの注文アイテムがあります（複数値属性）。したがって、ルールに従って、個別のテーブルを作成します。
今、2人の顧客が同じ注文をしているとしましょう。例えば、両方が同じ価格、割引、同じ日付などでiPhoneを購入します。したがって、理想的には、orderitem関係でiPhoneを注文するための正確な2つのタプルが必要です。しかし、関係の制約に従って、すべてのタプルは一意でなければなりません。したがって、2つの注文を今までと同じitem_line_number.no問題に関連付けましょう。次に、顧客の1人がキャンセルすることを検討します。iPhoneの注文です。item_line_numberタプルも削除されます。iPhoneを購入した他の顧客も、M：1対応のため削除されます。最後に、データベースに一貫性がありません。そのため、orderidとなる記述子キーを使用します。したがって、注文したiPhoneを1つ削除してもデータベースが破損することはありません。
OrderItemに依存しOrderていorderItemsますがorder、なぜItemLineNumberアイテムを単独で識別するために使用できないのかわかりません！実際にItemLineNumber、int一意性を保証するために自動生成され、外部キーorderIDを使用して2つのエンティティをリンクするだけですか？！