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

我正试图设计一个数据库，能够跟踪订单，并尽可能少地重复跟踪信息。我拥有一家公司，从多个零售商那里获得产品，这些零售商直接将产品发送给客户。因此，对于每个订单，将有多个产品和多个跟踪链接。 以下是迄今为止db的设计：

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

---

谢谢

从您的模型中，我不明白的是

跟踪\u详细信息

和

订单\u详细信息

之间的业务规则。您的模型显示，

跟踪商品

和

产品

都有一个

零售商

。因此，我可能会猜测，

跟踪_详细信息

和

订单_详细信息

之间存在一对一的关系。列出这样的业务规则并绘制一张图表来说明它们是一个非常好的主意

这是我刚才用UML表示法做的一个模型。从我可以看出，如果您在我的图表中将

合同

重命名为

订单

，那么它与您的模型非常相似。我的图表试图捕获订单中的内容（我称之为

LineItem

，您称之为

order\u details

）和如何发货（我称之为

Delivery

，您称之为

tracking\u details

）之间的业务规则：

我使用免费的在线工具来绘制UML图

要真正理解业务规则，您需要将它们明确地表达出来。例如，我的模型的业务规则是：

合同有许多行项目

一份合同有很多次交货

到某个位置的传递包含一个或多个行项目

行项目是合同中给定产品的数量

行项目只能在零次或一次交付中

更改合同中的行项目会更新合同的总成本

在这个高级UML模型中还有一些其他的东西。黑色三角形表示“聚合”或“所有权”。因此，该图表明，

合同

（您称之为

订单

）控制其下所拥有项目的生命周期。这意味着，如果我删除订单，我也将删除它的

交付

（您称之为

跟踪(u details

）和

行项目

（您称之为

订单(u details

）

UML图的另一个方面是，它将一些表标记为

。这是一个基本上关于如何不损坏数据库模型的概念。在我的模型中，合同/订单的总成本必须等于订单/明细/行项目的成本之和。但我可以编写错误代码，把事情搞砸。我可能会添加或更新行项目/订单详细信息，而忘记更新订单表上的总成本。根实体的主要思想是，您没有只在订单后面写入数据的代码。控制订单的代码负责更新总体质量并插入/更新/删除行项目/订单详细信息。该单一代码路径确保订单总量始终与数据库中的行项目/订单详细信息之和相匹配。

产品

也被标记为根实体，它可能控制自己的一组聚合实体，这些聚合实体未显示在该图上，该图仅侧重于记录合同/订单

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

---

为了实现物理模型，我需要比UML中方框所暗示的多一个表。我需要在交货/跟踪详细信息和行项目/订单详细信息之间建立一个联接表。该表将捕获哪个交付/跟踪详细信息正在跟踪订单中的哪些内容。如果您列出业务规则并通读它们，它将帮助您发现这些细节。我的模型说，行项目/订单的详细信息只能在一次交付中。该业务规则不能用外键约束之类的东西强制执行。相反，我的根实体的单一代码路径确保在一个位置检查订单周围的所有业务规则，然后单元测试逻辑将更新所有关联表。如果您使用的是OO语言，那么该代码将位于Contract/order类中。表示其他根实体（如Product）的其他类将强制执行自己的业务规则并管理自己的表。

您的数据模型是合理的。但是，我确实注意到，

TrackingDetails

和

OrderDetails

都处于

OrderId

/

ProductId

级别

这表明

TrackingDetails

实际上应该有一个

OrderDetailsId

，而不是

OrderId

和

ProductId

也就是说，我不知道从商业角度来看这是否合理

OrderDetails

没有“数量”，所以我不知道这是一个疏忽还是多个产品都是di