E-R图混乱 [英] E-R diagram confusion

问题描述

我正在为下面已显示其部分内容的商店设计此E-R图（其余内容无关）。请参阅链接：
ER图

I am in the process of designing this E-R diagram for a shop of which I have shown part of below (the rest is not relevant). See the link please: E-R diagram

我的问题是，这家商店只卖两种袜子和鞋子。
我在图表中正确地详细说明了吗？我不确定我的基数和/或设计是否正确。客户必须购买这些物品中的至少一个才能使订单存在（但可以自由购买任何数量）。

The issue that I have is that the shop only sells two items, Socks and Shoes. Have I correctly detailed this in my diagram? I'm not sure if my cardinalities and/or my design is correct. A customer has to buy at least one of these items for the order to exist (but has the liberty to buy any number).

Shoe和Sock实体将拥有其商品各自的ID属性，并且我打算转换为这样的关系模式：

The Shoe and Sock entities would have their respective ID attribute, and I am planning to translate to a relational schema like this:

（我忘记将ORDER_CONTAINS关系添加到图中，以具有名为 Quantity 。

(I forgot to add to my diagram the ORDER_CONTAINS relationship to have an attribute called "Quantity". )

Table: Order_Contains
    ORDER_ID    | SHOEID            | SOCKID           | QTY
    primary key | FK, could be null |FK, could be null | INT

这显然是行不通的，因为数量是没有意义的。有没有一种方法可以将产品缩减为两个产品并使所有这些工作正常进行？

This clearly won't work since the Qty would be meaningless. Is there a way I can reduce the products to just two products and make all this work?

推荐答案

您没有很好地解释过这里的上下文。我会尝试从我的理解中进行解释，并给您一些提示。

You have not explained very well the context here. I'll try to explain from what I understand, and give you some hints.

您的商店是否只（永远）销售2种产品？这些产品的详细信息（颜色，型号，重量，宽度等）是否需要保留在数据库中？如果是，则模型中有两个实体，SOCKS和SHOES。每个实体都有其自己的属性。通常将购买或订单视为ERD上的事件。如果您的客户总是购买（或订购）带鞋袜子，那么三个实体之间总会有联系：

Do your shop only and always (forever) sell 2 products? Do the details of these products (color, model, weight, width, etc...) need to be persisted in the database? If yes, then we have two entities in the model, SOCKS and SHOES. Each entity has its own properties. A purchase or a order is usually seen as an event on the ERD. If your customers always buys (or order) socks with shoes, then there will always be a link between three entities:

客户---鞋---袜子

CLIENTS --- SHOES --- SOCKS

此连接/关联/关系是一个事件，而这就是购买（或订购）。

This connection / association / relationship is an event, and this would be the purchase (or order).

如果客户可以购买单独的鞋子和袜子，则袜子和鞋子是超级实体（称为产品）的子类型，购买是客户与产品之间的事件。在这种情况下，我们具有分区关系。

If a customer can buy separate shoes and socks, then socks and shoes are subtypes of a super entity, called PRODUCTS, and a purchase is an event between CUSTOMERS and PRODUCTS. Here in this case we have a partitioning relationship.

但是，如果您的客户购买单独的产品，而您的商店不会永远只售出2种产品，而这些产品的详细信息并不总是相同，也不会保存为表中的列，那么情况就是另外一种情况。

If however, your customers buy separate products, and your store will not sell forever only 2 products, and details of the products are not always the same and will not be saved as columns in a table, then the case is another.

袜子被视为产品以及将来可以考虑的其他物品。因此，我们在PRODUCTS表中有记录/行。

Shoes and socks are considered products, as well as other items that can be considered in future. Thus, we have records/rows in a PRODUCTS table.

当客户下订单（或购买）时，他（她）正在购买产品。客户与产品之间有很强的联系，通常又是一个事件，那就是购买（或定单）。

When a customer places an order (or a purchase), he (she) is acquiring products. There is a strong link between customers and products here, again usually an event, which would be the purchase (or a order).

我不知道您是否这样做，但是在考虑创建图表之前，请在纸张或文档中键入问题上下文。显示当前情况下的所有详细信息。

I do not know if you do it, but before thinking of start a diagram, type the problem context in a paper or a document. Show all details present in the situation.

实体在具有属性时可以看到。如果您需要保存客户名称，客户的眼睛颜色，客户的电子邮件等等，那么您肯定会有一个CUSTOMER实体。

The entities are seen when they have properties. If you need to save the name of a customer, the customer's eye color, the customer's e-mail, and so on, then you will have certainly a CUSTOMER entity.

如果您看到实体以某种方式关联，那么您就有了关联，您应该问自己这些实体形成什么样的关联。对于您的产品和客户，我们之间有购买关系。既定的关系是购买（或称为订单）。一个客户可以购买各种产品，并且可以为多个客户购买一个产品（不在同一架子上，是型号，型号），因此，我们具有多对多关系。

If you see entities relate in some way, then you have a relationship, and you should ask yourself what kind of relationship these entities form. In your case of products and customers, we have a purchasing relationship there between. The established relationship is a purchase (or an order, you call it). One customer can buy various products, and one product (not on the same shelf, is the type, model) can be purchased for several customers, thus, we have a Many-To-Many relationship.

该关系根据上下文创建了更改。无论如何，我们将在这里发明一些疯狂的例子。说我们有客户和产品。假设您想持续存在客户舔产品的情况（这确实很疯狂，只是为了让您了解上下文如何说明这种关系）。

The relationship created changes according to the context. Whatever, we'll invent something crazy here as examples. Say we have customers and products. Say you want to persist a situation where customers lick Products (something really crazy, just for you to see how the context says the relationship).

会有亲密的联系客户与产品实体之间的联系（确实紧密...我认为...）。在这种情况下，该关系表示顾客舔产品的历史。这将产生一个事件。在这种情况下，您可以输入日期，客户舔适当产品的次数，天气，时间，街道上的交通信号灯颜色等属性，仅根据上下文需要保留，即您的需求。

There would be an intimate connection between customers and products entities (really close... I think...). In this case, the relationship represents a history of customers licking products. This would generate an EVENT. In this event you could put properties such as the date, the amount of times a customer licked a proper product, the weather, the time, the traffic light color on the street, etc., only what you need to persist according to your context, your needs.

请记住，对于已创建的NN关系，我们需要查看是否会出现新实体（不存在关系）。当您将概念模型分解为逻辑模型时，通常会发生这种情况。产品订单可能不会生成一个实体，而是两个实体：ORDER和订单的产品。在订单产品中，您放置了从每个客户订购的产品列表以及数量。

Remember that for N-N relationships created, we need to see if new entities (out of relationship) will emerge. This usually happens when you are decomposing the conceptual model to the logical model. Probably, product orders will generate not one but two entities: The ORDER and the products of orders. It is within the products of orders that you place the list of products ordered from each customer, and the quantity.

I想提供各种材料来研究ERD，但不幸的是，它们都是葡萄牙语。希望我能以某种方式帮助您。如果您想更具体地解决您的问题，我想我真的可以为您提供最好的帮助。有什么事请问。

I would like to present various materials to study ERD, but unfortunately they are all in Portuguese. I hope I have helped you in some way. If you want to be more specific about your problem, I think I can really help you best. Anything, please ask.

这篇关于E-R图混乱的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！