sql - 我如何设计一个数据库系统来跟踪客户订单和运输信息

Question

我正在尝试设计一个能够跟踪订单并以尽可能少的重复跟踪信息的数据库。我拥有一家从多个零售商处获取产品的公司，这些零售商将产品直接发送给客户。所以对于每个订单，都会有多个产品和多个跟踪链接。这是迄今为止数据库的设计：

这仍然略有重复，因为每个订单在订单详细信息和跟踪表中都有多行。我只是想知道是否有更聪明的方法来设计这个。这是否尽可能标准化？

谢谢

标签： sqldatabasepostgresqldatabase-designschema

Answer 1

我从您的模型中无法理解的是 和 之间的业务tracking_details规则order_details。您的模型显示，tracking_item并且product两者都有一个retailer. tracking_details所以我可能猜测和之间存在一对一的关系order_details。列出这样的业务规则并绘制一个说明它们的图表是一个非常好的主意。

这是我不久前用 UML 表示法制作的模型。据我所知，如果您在我的图表中重命名Contract为order几乎等同于您的模型。我的图表试图捕捉订单中的事物（我称之为它们LineItem，你称之为它们order_details）和它是如何运输（我称之为它们Delivery，你称之为它们tracking_details）之间的业务规则之类的东西：

我使用免费的在线工具umletino来绘制那个 UML 图。

要真正理解业务规则，您需要明确说明它们。例如，我的模型的业务规则是：

1. 一份合同有很多项目
2. 一份合同有很多交货
3. 到某个位置的交货包含一个或多个订单项
4. 订单项是合同中给定产品的数量
5. 一个 lineitem 只能是零个或一个交付
6. 更改合同中的项目会更新合同的总成本

在那个高级 UML 模型中还有一些其他的东西。黑色三角形表示“聚合”或“所有权”。因此，该图表明Contract（您称它为order）控制它在其下拥有的项目的生命周期。这意味着如果我删除订单，我也会删除它Deliveries（你称之为 those tracking_details）和它LineItems（你称之为 those order_details）。

UML 图的另一个方面是它将一些表标记为<<Root Entity>>. 这是一个基本上关于如何不破坏数据库模型的概念。在我的模型中，合同/订单的总成本必须等于 order_details/lineitems 成本的总和。然而，我可以编写错误的代码，把事情搞砸。我可以添加或更新 lineitems/order_details 并忘记更新订单表上的总成本。根实体的重要思想是您没有仅在订单背后写入数据的代码。控制订单的代码负责更新总质量并执行 LineItems/order_details 的插入/更新/删除。该单一代码路径确保订单的总数量始终与数据库中 LineItems/order_details 的总和相匹配。这Product也被标记为根实体，它可能控制自己的一组聚合实体，这些实体未显示在该图表上，该图表专注于仅记录合同/订单。

总之，我在您的模型中看不到任何重复。如果我正在处理您的项目，我希望在关系模型旁边看到业务规则和如何组织代码以帮助避免破坏模型或破坏业务规则的想法。我还想了解模型中事物的生命周期，例如聚合。我鼓励您列出您的业务规则，就像我在上面列出的一样。然后尝试绘制一个包含所有业务规则的图表（尝试上面链接中的免费工具）。我们称之为逻辑模型。然后制作物理数据模型。（警告：我不建议疯狂使用 UML 只使用足以捕捉关键业务想法。）

为了实现物理模型，我需要比 UML 中的框所暗示的多一张表。我需要delivery/tracking_details 和lineitems/order_details 之间的连接表。该表将捕获哪些delivery/tracking_detail 正在跟踪订单中的哪些东西。如果您列出业务规则并通读它们，它可以帮助您发现这些细节。我的模型说 lineitem/order_detail 只能在一次交付中。该业务规则不能通过诸如外键约束之类的东西来强制执行。相反，我的根实体的单一代码路径确保围绕订单的所有业务规则都在一个地方检查，然后单元测试逻辑将更新所有关联的表。如果您使用的是面向对象语言，那么该代码将在您的合同/订单类中。