在对数据库建模时，何时应使用弱实体？

这基本上是一个关于弱实体是什么的问题？我们什么时候应该使用它们？应该如何建模？

普通实体和弱实体之间的主要区别是什么？在进行域驱动设计时，弱实体是否对应于值对象？

为了使问题始终保持话题，这里是一个来自维基百科的示例，人们可以用来回答以下问题：

在此示例中OrderItem，我们将其建模为弱实体，但我不明白为什么不能将其建模为普通实体。
另一个问题是，如果我想跟踪订单历史记录（即订单状态的变化），那将是正常实体还是弱实体？

形式上，“弱”实体具有以下特征。

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.

我要说的是，实际上，您不会公开地决定将某事物本身变成一个“弱”的实体。相反，您可以对数据进行结构化以代表您要建模的任何内容。如果在执行完此操作之后，您查看了一个特定的实体，并且该实体具有“弱”实体的特征，那么您可以出于某种原因（如果出于某种原因）需要明确指出这一点或出于某种原因而对其进行记录或绘制图表的形式。

一个OrderItem不能没有订单或产品存在。因此它很弱，因为它是依赖关系来控制它的。

例如，如果您删除订单，则无法知道该物品应运往何处。或者，如果您删除产品，则不知道要运送什么。

根据我在上图中的理解，它们包括两个实体/表，而不是一个实体，即订单和订单项，因此，当设计两个实体时，访问信息变得容易。订单项取决于订单实体，因此被视为弱实体。因为弱实体的特征是它依赖于另一个实体。假设如果您不包括订单项实体，您将如何知道订单项的价格，折扣。就像jgauffin所说的，例如，如果您删除订单，您将无法知道该物品应运往何处。或者，如果您删除产品，则不知道要运送什么。

ER图应根据业务需求进行设计。

请参阅，订单有很多订单项（多值属性）。因此，根据规则，我们创建了单独的表。

现在，假设2个客户具有相同的订单。例如，双方都以相同的价格，折扣，相同的日期等购买iPhone。因此，理想情况下，iPhone的订单项应该有两个确切的元组。但是根据关系的约束，所有元组都应该是唯一的。因此，让两个订单关联到相同的item_line_number。到现在为止没有问题。现在考虑客户取消之一。如果是iPhone订单。还将删除item_line_number元组。现在，其他购买iPhone的客户也因为M：1对应关系而被删除。所以最后数据库是不一致的。这就是为什么我们使用一个描述符字符作为orderid。因此删除订购的一部iPhone不会导致数据库损坏。