实体关系图冗余：商店、产品、订单、类别答案

【问题标题】：Entity-Relationship Diagram Redundancy: store, product, orders, categories实体关系图冗余：商店、产品、订单、类别
【发布时间】：2018-03-25 00:36:58
【问题描述】：

我正在尝试设计一个模型，允许用户通过一个帐户成为买家和卖家，但一些老师告诉我，这个图是错误的，因为它有冗余。

我已经查看了图表，但我还没有找到解决这种冗余的方法。在表orders 中我需要知道谁是买家，因此我没有从表中删除它。有什么想法吗？

【问题讨论】：

该图中没有用户。你的意思是Orders.buyer 和Product.seller 都引用了TBL_store？就像这是一种企业对企业的销售模式？我看不到那里有任何冗余。您应该请老师澄清哪个部分有冗余，或者他们可能会描述由于冗余而可能发生的异常情况。
是的，是b to b，谢谢你的评论。
与您的问题无关 - 但您可能希望将数量添加到 Product 和 OrderProduct。以及一个产品存在 2 个或更多 sellers 的情况
Please edit the corresponding DDL into your quesion. 请在您的问题中编辑说明，而不是 cmets。 PS“冗余”是模糊的。设计的具体问题涉及或不涉及可以粗略地用冗余来描述的事情。如果您的老师这么说，那么他们希望您遵循与“冗余”相关的步骤的设计方法。告诉我们你的任务/规范，给我们一个你应该遵循的方法的参考并向我们展示你是如何遵循它的。

标签： mysql database normalization entity-relationship database-normalization

【解决方案1】：

您的方案中唯一“冗余”（准确地说未标准化）是：

不需要特殊ID，复合PK就够了。

-------------------
|   ORDERPRODUCT  |
-------------------
| PK | PRODUCT_ID |
| PK | ORDER_ID   |
-------------------

ADD CONSTRAINT pk 
PRIMARY KEY (PRODUCT_ID, ORDER_ID);

【讨论】：

Ids 与标准化无关，无论是 1NF 还是更高。

【解决方案2】：

除了@Blag 所说的之外，对于Categories，您还有两个字段可以做同样的事情：categoryname 和description。您已经有一个带有 PK_IdCategory 的标识符，因此其中一个可能是不必要的

【讨论】：