实体关系图销售

时间:2014-01-09 13:56:50

标签: sql database relational-database entity-relationship erd

我想问一下您对以下ERD图表的看法。请记住,我还没有代表关系的基数。

我想要的是:

  • 客户进去买车;
  • 可以升级汽车,增加许多额外费用,加上汽车的基本价格;
  • 推销员可以免费提供额外服务,或者为销售总价提供折扣以吸引客户;

您如何看待我的图表?这样对吗?你看错了吗?

[编辑]

我如何表示以下场景。作为购买新车的一部分,客户向我出售二手车。

1 个答案:

答案 0 :(得分:1)

您的模型是否正确取决于您的模型是否可以捕获您上面描述的所有业务场景 - 恕我直言,您的模型做得非常好(祝贺!);除了少量的小异常,例如,Discount实体中没有Order属性来捕获销售的总体折扣(这是一种可能的业务场景)。

但是当你创建这样的模型时,你应该考虑这个模型的最终目的:

  • 是否用于捕获交易数据( OLTP )?
  • 是否用于存储数据以用于报告目的( OLAP

在您的情况下,我认为您的最终目标是通过设计在线事务处理(OLTP)系统来捕获业务事务。 OLTP模型本质上通常是标准化的(由于标准化的明显好处,例如减少冗余,更新/删除异常预防等)。除了很少的传递依赖性之外,您的模型大多数是 3NF 形式。实体SalesTotal中的列Order似乎是一个可派生列(基于您已存储在其他实体中的PriceDiscount),IMO不一定是单独维护(读取冗余)。

同样基于您的上述评论,

  

在任何给定点额外的变更价格。我应该好好休息一下   在销售中足以看到那天的原始价格

我认为您无法执行此操作,因为您的Extra实体旨在始终存储当前Price。对于任何给定的时间点,您的OrderDeatils都包含CarExtra之间的关系。如果汽车和额外的价格稍后更改,您将丢失旧值,因为您将以新价格更新旧价格。因此,虽然您可以跟踪ID_Car中的ID_ExtraOrderDetails,但您不知道订单创建期间的历史价格是多少。

如果您想存储历史价格,请考虑再添加一个表格CarExtra,以便根据日期存储过去的价格。

  

客户可以充当卖家

在客户可以作为卖家的情况下,该人将在您的ClientSalesman表中独立存在......这是完全正常的(这种设计技术称为垂直分离)。

或者,如果您确实需要3NF模型,那么您应该创建一个新实体 - Person,其中包含nameid等属性。Person实体将用于存储您的客户和销售人员的详细信息,因为从技术上讲,他们都是某个人,但他们的“角色”是不同的。拥有此Person实体后,您可以删除SalesManClient个实体。然后在Order实体中,您已经拥有Clent IDSalesman ID属性来定义两个不同的人之间的关系(这些Clent IDSalesman ID将是Foreign KeyPerson ID实体中的Person。可以从Order实体了解一个人是扮演推销员还是客户的角色。

希望这有帮助