实体关系图销售

Question

我想就我制作的以下ERD图表征询您的意见。请记住，我还没有代表关系的基数。

我要做的是：

• 客户端中去买车;
• 该汽车可以升级许多附加值，这些附加值加起来就是汽车的基本价格;
• 推销员可以免费提供额外服务，或者为了吸引客户而在销售总价中提供折扣;

您如何看待我的图？这样对吗？你看到有什么不对吗？

[编辑]

我怎么去表示以下情形。作为购买新车的一部分，顾客向我出售二手车。

Answer 1

无论您的模型是否正确取决于您的模型是否可以捕获您上面描述的所有业务场景 - 恕我直言，您的模型做得相当好（祝贺！）;除去一些小的异常情况，例如Order实体中没有Discount属性来捕获整体销售折扣（这是可能的业务情景）。

但是当你像这样建立模型，你应该考虑这种模式的最终目的：

• 它是用于捕捉交易数据（OLTP ）？
• 它是用于存储数据的报告目的（OLAP）

在你的情况，我相信你的最终目标是通过对联机事务处理（OLTP）系统设计来捕捉商业交易。 OLTP模型通常在本质上被归一化（归因于标准化的明显好处，例如减少冗余，更新/删除异常预防等）。除了少量传递依赖性之外，您的模型大部分都是在3NF表单中。实体Order中的列SalesTotal似乎是可导出的列（基于Price和Discount，您已经存储在其他实体中），并且不需要单独维护（读取冗余）。

也是基于以上的评论，

额外的价格变化，在任何给定的点。卜我应该强麦打破 减售不够看的东西，原来的价格在该日期

我不认为你可以做到这一点，因为你Extra实体被设计成存储当前永远都是Price。您的OrderDeatils包含任何给定时间点的Car和Extra之间的关系。如果以后汽车价格和额外价格发生变化，您将会失去旧价格，因为您将以新价格更新旧价格。因此，尽管您可以跟踪OrderDetails的ID_Car和​​，但您不知道在订单创建期间他们的历史价格是多少。

如果要存储历史价格，请考虑在Car和Extra之间再添加一个表格，以将过去的价格与日期相比较。

客户端可以作为卖方

在当一个客户端可以作为卖方行动的情况采取行动，此人将在这两个你Client和Salesman表独立存在的......那是完全没有问题（这样的设计技术被称为垂直分离）。

或者，如果你真的需要一个3NF的模式，那么你应该创建一个新的实体 - Person包含属性如name，id等，这Person实体将用于两个客户和业务员的细节存储在技术上的两他们是某个人，但他们的“角色”是不同的。一旦你有这个Person实体，你可以删除SalesMan和Client实体。然后在Order的实体，您已经有了一个Clent ID和Salesman ID属性来定义两个不同的人之间的关系（这些Clent ID和Salesman ID将Foreign Key到Person ID在Person实体）。从Order实体可以知道一个人是否扮演推销员或客户的角色。

希望这有助于