ER 图 - 显示交付到办公室及其分支机构
ER Diagram - Showing Deliveries to Office and to its Branches
对于一个小项目，我正在为一个简单的股票跟踪应用程序创建一个实体关系图。
用户故事
产品由产品供应商销售。产品由办公室订购并交付给他们。可能需要一次或多次交货才能完成订单。该办事处订购的这些产品依次交付给各个分支机构。有没有一种通用的方式可以表示办公室如何将库存分配给它负责的分支机构？
ER图
这是描述上述内容的非常简化的图表。
交付将被送到办公室，然后是分支机构。 HeadQuarters 的每个子部门（图中未显示）都有不同数量的库存，这些库存不一定与 OrdersDetail 具有一一对应关系。问题是如何在给定当前模式的情况下显示各个部门的库存，或者以更容易显示的方式修改它。
更新：开始悬赏并创建新的 ERD 图。
这个结构有点奇怪。通常我处理这个问题的方式不会是你这里的菊花链结构，而是会反过来使用某种基于事务的系统。
我处理它的方式是把所有东西都从 order 和 have one-to-many 关系中去掉。
例如，我确实看到您在 Order 中添加了 OrderDetail，但这始终是 Order 的子集。所有订单将始终有详细信息；我会 link OrderDelivery 脱离主要 Order table，并在任何时候都可以访问详细信息作为参考 table 而不是 而不是 OrderDetailDelivery。
我将 Office 作为 OrderDelivery 上的一个字段，并且也以这种方式使用 Branch。如果您想为它们设置单独的 table，那很好，但我会使用 OrderDelivery 作为它们的中心位置。一个null可以表示是否已经交付，然后你可以使用你的应用层来处理流程的顺序。
换句话说，OfficeID 和 BranchID 可以作为字段存在，以指示它们各自 table 的外键 OrderDelivery
编辑
由于设计发生了一些变化（看起来确实更好），我想指出的一件事是您的 supplier 具有与 Delivery 相同的元数据。 Supplier 对我来说听起来像是一个实体，而 Delivery 是一个过程。我认为 Supplier 可以作为参考 table 单独使用。换句话说，您不需要在此 table 上包含所有相同的元数据；相反，您可能想创建一个 table（就像您现在为 supplier 创建的一样），而是调用 SupplierDelivery.
我看到的一点是，您希望能够通过其所有检查点跟踪各种产品订单的所有部分。考虑到这一点，您可能不一定希望为此设置一个单独的实体，而是将 SupplierDate 之类的内容作为 Delivery 上的字段之一进行跟踪。无论哪种方式，我都不会太在意结构。您的应用程序层将处理大量此类事务。
有一件事我会 非常 小心： 如果多个 table 具有同名的字段，但不是相互引用的键，您可能希望创建不同的名称。例如，如果供应商上的 deliveryDate 与 Delivery 上的相同密钥不同，您可能需要考虑将其命名为 shipDate 或者如果您指的是它到达供应商的日期, supplierDeliveryDate 否则您将来可能会因查询而感到困惑，并且如果没有大量注释，将使您的代码极难解析。
编辑以包含图表[再次编辑以获得更好的图表]：
以下是我的处理方式。您的重做图非常接近，但这里有一些变化
我的解释：
最简单的方法是先设置不同的实体，然后设置它们之间的关系，并确定是否需要link table.
不同的实体如下所述：
- 订单
- 产品
- 供应商
- 分行
Headquarters，虽然我把它包括在内，但实际上并不是图表的必要组成部分；大概是在这里发出命令和请求，但我的理解是，命令绝不会流经总部；它更像是一个中央处理区。我收集产品不通过总部运行，而是直接到分支机构。如果他们这样做（这可能会减慢交付过程，但这取决于您），您可以用它替换 Branch，并像您一样将分支作为它的 link前。否则，我认为您可以安全地将其从图表中完全删除。
Link 表格
这些是为出现的多对多关系设置的。
- OrderProductDetail - 订单可以有很多产品，很多订单可以有相同的产品。每个主键组合可以与每个订单的多个产品相关联[编辑：见下文，这现在通过 SupplierProduct] 将订单、产品和供应商联系在一起。因为这是 link table，每个订单可以有任意数量的产品。
- SupplierProduct - 假设同一产品有多个供应商，并且一个供应商可能有多个产品，因此 link table 的创建是为了处理每个产品的可用库存。 编辑： 现在这是指向 OrderProductDetail 的直接 link，因为个别供应商有一个 link 订单，而不是两个tables removed 这可以作为中央 link 来组合供应商和产品，但随后绑定到 OrderProducDtail。因为这是 link table，您可以让任意数量的供应商交付任意数量或数量的产品。
- 交货 - 分支机构可以收到很多交货，正如您提到的，一个订单可能会根据可用性分成多个部分。出于这个原因，这个 links 到 OrderProductDetail 是每个产品的特定数量。由于OrderProductDetail已经是双主键的linktable，所以orderId有一个双主键的外键OrderProductDetail 使用 productId 和 orderId 的配对键来确保与较大订单中的特定产品。
综上所述，supplierProduct 包含供应商和产品的组合，然后传递给 OrderProductDetail，后者将这些与详细信息组合在一起订单。这 table 基本上完成了大部分工作，将所有内容放在一起，然后再交付给分支机构。
注意：最后编辑：添加供应商id到OrderProductDetail，并从supplierProduct切换到supplierId和productId的双主键，以确保您有更清晰的方式来确保您产品从供应商到 OrderProductDetail 的方式可以足够精细。
希望对您有所帮助。
我建议您按以下方式简化您的 ER
然后定义tables
Suppliers(SupplierId) where SupplierId is PK
Products(ProductId) where ProductId is PK
HeadQuarters(HeadQuarterId) where HeadQuarterId is PK
Branches(BranchId, HeadQuarterId) where BranchId is PK and HeadQuarterId references HeadQuarters
Orders(OrderId, OrderDate, SupplierId) where OrderId is PK and SupplierId references Suppliers
Deliveries(OrderId, DeliveryNumber, DeliveryDate, BranchId) where (OrderId, DeliveryNumber) is PK, OrderId references Orders and BranchId referenced Branches
DeliveriedProducts(OrderId, DeliveryNumber, ProductId, ProductQuantity) where (OrderId, DeliveryNumber, ProductId) is PK, (OrderId, DeliveryNumber) references Deliveries and ProductId references Products
完成后，您可以通过以下查询获取库存：
select HeadQuarterId, BranchId, SupplierId, OrderDate, OrderId, DeliveryNumber, DeliveryDate, ProductId, ProductQuantity
from Branches
join Deliveries using (BranchId)
join Orders using (OrderId)
如果可以由不同的办公室（总部）向分支机构发出订单，则接收分支机构不再隐式定义订购办公室，因此订单 table 应包含一个代表新的分支机构的列 (OrderingHeadQuarterId)关系 "Orders Made by HeadQuarters".
希望这能解决您的问题。如果有问题，请告诉我。
谢谢
这里有一些问题，假设您已将供应商更正为只有主键 supplierId。
最明显的是您缺少订单中的分支，因此请将 Order.headQuartersId 替换为 Order.branchId。
另外你应该清楚主键。来自两个供应商的同一产品是否有两条记录？假设是。那么 Delivery 上的 supplierId 将是多余的，除非您想确保一次交付只有一个供应商（您可能会这样做）。这是一个有效的非规范化。或者从产品中删除供应商。或者不要，这没什么大不了的。
如果您假设每个 product/order 一次交货，则 OrderDetailDelivery table 可能是多余的。即使 product/order 有多次送货，您也可以仅使用 deliveryId 来容纳它，但您可能希望在不更改原始订单的情况下更改送货。在任何情况下，我都看不到 OrderDetailDelivery 上需要 orderId。
综上所述，您可以获得总部为其每个分支机构交付的订单列表：
JOIN Supplier
/
SELECT * FROM Delivery JOIN OrderDetailDelivery
JOIN OrderDetail JOIN Product
\
JOIN Order JOIN Branch JOIN HQ
一直都是合适的外键。如果（正如@alessandro 指出的那样）订购总部可能与分支总部不同，那只是额外信息。
我不知道这如何让你存货。我认为您必须记录外出或至少去分支机构的事情。我想 @qazifarhan 给了你类似的东西，但你可以为分支机构和总部设置两个可为空的交付日期。 null 表示尚未交付。带有 HQ 交货日期但没有 Branch 交货日期的记录将是您的 HQ 库存。
对于一个小项目，我正在为一个简单的股票跟踪应用程序创建一个实体关系图。
用户故事
产品由产品供应商销售。产品由办公室订购并交付给他们。可能需要一次或多次交货才能完成订单。该办事处订购的这些产品依次交付给各个分支机构。有没有一种通用的方式可以表示办公室如何将库存分配给它负责的分支机构？
ER图
这是描述上述内容的非常简化的图表。
交付将被送到办公室，然后是分支机构。 HeadQuarters 的每个子部门（图中未显示）都有不同数量的库存，这些库存不一定与 OrdersDetail 具有一一对应关系。问题是如何在给定当前模式的情况下显示各个部门的库存，或者以更容易显示的方式修改它。
更新：开始悬赏并创建新的 ERD 图。
这个结构有点奇怪。通常我处理这个问题的方式不会是你这里的菊花链结构，而是会反过来使用某种基于事务的系统。
我处理它的方式是把所有东西都从 order 和 have one-to-many 关系中去掉。
例如，我确实看到您在 Order 中添加了 OrderDetail，但这始终是 Order 的子集。所有订单将始终有详细信息；我会 link OrderDelivery 脱离主要 Order table，并在任何时候都可以访问详细信息作为参考 table 而不是 而不是 OrderDetailDelivery。
我将 Office 作为 OrderDelivery 上的一个字段，并且也以这种方式使用 Branch。如果您想为它们设置单独的 table，那很好，但我会使用 OrderDelivery 作为它们的中心位置。一个null可以表示是否已经交付，然后你可以使用你的应用层来处理流程的顺序。
换句话说，OfficeID 和 BranchID 可以作为字段存在，以指示它们各自 table 的外键 OrderDelivery
编辑
由于设计发生了一些变化（看起来确实更好），我想指出的一件事是您的 supplier 具有与 Delivery 相同的元数据。 Supplier 对我来说听起来像是一个实体，而 Delivery 是一个过程。我认为 Supplier 可以作为参考 table 单独使用。换句话说，您不需要在此 table 上包含所有相同的元数据；相反，您可能想创建一个 table（就像您现在为 supplier 创建的一样），而是调用 SupplierDelivery.
我看到的一点是，您希望能够通过其所有检查点跟踪各种产品订单的所有部分。考虑到这一点，您可能不一定希望为此设置一个单独的实体，而是将 SupplierDate 之类的内容作为 Delivery 上的字段之一进行跟踪。无论哪种方式，我都不会太在意结构。您的应用程序层将处理大量此类事务。
有一件事我会 非常 小心： 如果多个 table 具有同名的字段，但不是相互引用的键，您可能希望创建不同的名称。例如，如果供应商上的 deliveryDate 与 Delivery 上的相同密钥不同，您可能需要考虑将其命名为 shipDate 或者如果您指的是它到达供应商的日期, supplierDeliveryDate 否则您将来可能会因查询而感到困惑，并且如果没有大量注释，将使您的代码极难解析。
编辑以包含图表[再次编辑以获得更好的图表]：
以下是我的处理方式。您的重做图非常接近，但这里有一些变化
我的解释：
最简单的方法是先设置不同的实体，然后设置它们之间的关系，并确定是否需要link table.
不同的实体如下所述：
- 订单
- 产品
- 供应商
- 分行
Headquarters，虽然我把它包括在内，但实际上并不是图表的必要组成部分；大概是在这里发出命令和请求，但我的理解是，命令绝不会流经总部；它更像是一个中央处理区。我收集产品不通过总部运行，而是直接到分支机构。如果他们这样做（这可能会减慢交付过程，但这取决于您），您可以用它替换 Branch，并像您一样将分支作为它的 link前。否则，我认为您可以安全地将其从图表中完全删除。
Link 表格
这些是为出现的多对多关系设置的。
- OrderProductDetail - 订单可以有很多产品，很多订单可以有相同的产品。每个主键组合可以与每个订单的多个产品相关联[编辑：见下文，这现在通过 SupplierProduct] 将订单、产品和供应商联系在一起。因为这是 link table，每个订单可以有任意数量的产品。
- SupplierProduct - 假设同一产品有多个供应商，并且一个供应商可能有多个产品，因此 link table 的创建是为了处理每个产品的可用库存。 编辑： 现在这是指向 OrderProductDetail 的直接 link，因为个别供应商有一个 link 订单，而不是两个tables removed 这可以作为中央 link 来组合供应商和产品，但随后绑定到 OrderProducDtail。因为这是 link table，您可以让任意数量的供应商交付任意数量或数量的产品。
- 交货 - 分支机构可以收到很多交货，正如您提到的，一个订单可能会根据可用性分成多个部分。出于这个原因，这个 links 到 OrderProductDetail 是每个产品的特定数量。由于OrderProductDetail已经是双主键的linktable，所以orderId有一个双主键的外键OrderProductDetail 使用 productId 和 orderId 的配对键来确保与较大订单中的特定产品。
综上所述，supplierProduct 包含供应商和产品的组合，然后传递给 OrderProductDetail，后者将这些与详细信息组合在一起订单。这 table 基本上完成了大部分工作，将所有内容放在一起，然后再交付给分支机构。
注意：最后编辑：添加供应商id到OrderProductDetail，并从supplierProduct切换到supplierId和productId的双主键，以确保您有更清晰的方式来确保您产品从供应商到 OrderProductDetail 的方式可以足够精细。
希望对您有所帮助。
我建议您按以下方式简化您的 ER
然后定义tables
Suppliers(SupplierId) where SupplierId is PK
Products(ProductId) where ProductId is PK
HeadQuarters(HeadQuarterId) where HeadQuarterId is PK
Branches(BranchId, HeadQuarterId) where BranchId is PK and HeadQuarterId references HeadQuarters
Orders(OrderId, OrderDate, SupplierId) where OrderId is PK and SupplierId references Suppliers
Deliveries(OrderId, DeliveryNumber, DeliveryDate, BranchId) where (OrderId, DeliveryNumber) is PK, OrderId references Orders and BranchId referenced Branches
DeliveriedProducts(OrderId, DeliveryNumber, ProductId, ProductQuantity) where (OrderId, DeliveryNumber, ProductId) is PK, (OrderId, DeliveryNumber) references Deliveries and ProductId references Products
完成后，您可以通过以下查询获取库存：
select HeadQuarterId, BranchId, SupplierId, OrderDate, OrderId, DeliveryNumber, DeliveryDate, ProductId, ProductQuantity
from Branches
join Deliveries using (BranchId)
join Orders using (OrderId)
如果可以由不同的办公室（总部）向分支机构发出订单，则接收分支机构不再隐式定义订购办公室，因此订单 table 应包含一个代表新的分支机构的列 (OrderingHeadQuarterId)关系 "Orders Made by HeadQuarters".
希望这能解决您的问题。如果有问题，请告诉我。
谢谢
这里有一些问题，假设您已将供应商更正为只有主键 supplierId。
最明显的是您缺少订单中的分支，因此请将 Order.headQuartersId 替换为 Order.branchId。
另外你应该清楚主键。来自两个供应商的同一产品是否有两条记录？假设是。那么 Delivery 上的 supplierId 将是多余的，除非您想确保一次交付只有一个供应商（您可能会这样做）。这是一个有效的非规范化。或者从产品中删除供应商。或者不要，这没什么大不了的。
如果您假设每个 product/order 一次交货，则 OrderDetailDelivery table 可能是多余的。即使 product/order 有多次送货，您也可以仅使用 deliveryId 来容纳它，但您可能希望在不更改原始订单的情况下更改送货。在任何情况下，我都看不到 OrderDetailDelivery 上需要 orderId。
综上所述，您可以获得总部为其每个分支机构交付的订单列表：
JOIN Supplier
/
SELECT * FROM Delivery JOIN OrderDetailDelivery
JOIN OrderDetail JOIN Product
\
JOIN Order JOIN Branch JOIN HQ
一直都是合适的外键。如果（正如@alessandro 指出的那样）订购总部可能与分支总部不同，那只是额外信息。
我不知道这如何让你存货。我认为您必须记录外出或至少去分支机构的事情。我想 @qazifarhan 给了你类似的东西，但你可以为分支机构和总部设置两个可为空的交付日期。 null 表示尚未交付。带有 HQ 交货日期但没有 Branch 交货日期的记录将是您的 HQ 库存。