我要处理的一切就是让所有的东西都摆脱秩序,并且有一对多的关系.

例如,我确实看到你的OrderDetail不符合Order,但这将永远是Order的一个子集.所有订单将始终有细节;我将OrderDelivery链接到主订单表中,并且可以随时将详细信息作为参考表,而不是脱离OrderDetailDelivery.

我将Office作为OrderDelivery上的一个字段,并且也以这种方式使用Branch.如果你想为他们分开一个表,那没关系,但是我会使用OrderDelivery作为这些表的中心位置. null可以指示是否已经传递,然后可以使用应用程序层来处理进程的顺序.

换句话说,OfficeID和BranchID可以作为字段存在,以指示其在OrderDelivery之外的各个表的外键

编辑

由于设计有所改变(而且看起来更好),我想指出的一点是,您的供应商具有与Delivery相同的元数据.供应商对我来说听起来像一个实体,而交货是一个过程.我认为供应商可能会以自己的身份参与表.换句话说,您不需要在此表上包含所有相同的元数据;相反,您可能希望创建一个表(就像您现在对于供应商一样),而是称为SupplierDelivery.

我看到的是,您希望能够通过其所有检查点跟踪各种产品的所有订单.考虑到这一点,您可能不一定要为此提供单独的实体,而是跟踪SupplierDate作为交付之一的字段之一.无论如何,我不会太太挂在结构上;您的应用程序层将处理好这一切.

有一件事我非常小心：如果多个表具有相同名称的字段,但不是引用对方的键,则可能希望创建不同的名称.例如,如果供应商的DeliveryDate与交货上的相同键不同,您可能需要考虑将其称为shipDate,或者您的意思是到达供应商dateDeliveryDate的日期,否则您将来可能会混淆自己与您的查询,并将使您的代码非常难以解析没有很多评论.

编辑包括图[再次为更好的图编辑]：

以下是我如何处理它.你的重做图非常接近,但这里有一些变化

我的解释：

最简单的方法是首先用不同的实体进行设置,然后设置它们之间的关系,并确定是否需要有一个链接表.

不同的实体如下所述：

>订单
>产品
>供应商
>分行

总部,虽然我包括它,实际上不是图的必要组成部分;大概是在这里订单和要求,但我的理解是,订单没有任何流经总部;它更是一个中央处理领域.我收集的产品不能通过总部,而是直接去分支机构.如果他们这样做(这可能会减慢交付过程,但这取决于您),您可以使用它替换Branch,并将其分支为它之前的链接.否则,我想你可以安全地从图中完全删除它.

链接表

这些是为了出现的多对多关系而设立的.

>订单产品详细信息 – 订单可以有很多产品,很多订单可以有相同的产品.每个主键组合可以与每个订单的多个产品相关联[编辑：见下文,现在通过SupplierProduct将订单,产品和供应商联系起来).因为这是一个链接表,您可以订购任意数量的产品.
>供应商产品 – 这是假定同一产品有多个供应商,一个供应商可能有多个产品,因此创建此链接表以处理每个产品可用的库存.编辑：现在是直接链接到OrderProductDetail,因为个别供应商有一个链接到订单,而不是删除两个表格是有道理的.这可以作为组合供应商和产品的一个中心链接,然后绑定到OrderProducDtail.因为这是一个链接表,您可以有任何数量的供应商提供任何数量或数量的产品.
>交货 – 分行可以收到许多交货,如您所提及的,订单可能会根据可用性分为多个部分.因此,这链接到OrderProductDetail,这是每个产品的具体数量.由于OrderProductDetail已经是具有双主键的链接表,所以orderId具有使用productId和orderId的配对键的OrderProductDetail之外的双主键的外键,以确保与更大订单中的特定产品有明确的关联.

总而言之,供应商产品包含供应商和产品的组合,然后传递给OrderProductDetail,将其与订单的详细信息相结合.该表基本上完成了将所有内容放在一起的大部分工作,然后再将其交付给分支机构.

注意：上次编辑：将供应商ID添加到OrderProductDetail,并从supplierProduct切换到supplierId和productId的双重主键,以确保您能够以更清晰的方式确保您的产品从供应商到OrderProductDetail的方式足够细致.

我希望这有帮助.