这些表格如何相关？

Question

假设我经营一个在线业务，您可以从我的网站订购产品，我有一个包含两个表的数据库：

表order，字段为order_number, customer_ID, address

表customer，字段为customer_ID, first_name, last_name

获取完整，详细的报告＆＃39;在订单中，我会执行LEFT JOIN来连接订单表中的数据，以包括客户的名字和姓氏以及他们的地址和订单号。

我的问题是，这些表格如何相关？他们在一起吗？实体关系图会是什么样子？另外，他们似乎没有相互作用，更像是互相查找表。

Answer 1

订单总是有客户，不是吗？所以它不是左派，而是内联盟。

它们是customer_id的链接。所以你的SQL很简单：

select o.order_number, o.customer_ID, o.address, 
    c.first_name, c.last_name
from orders o
inner join customer c on o.customer_ID = c.customer_ID;

实体关系：

订购客户 Customer_Id 0 ... N＆gt; --- + 1 Customer_Id ......

此EF关系来自MS SQL Server的示例数据库Northwind。在该示例数据库中，与您的一样，有客户和订单。 Customers和Orders表通过两个表中的CustomerId字段相关（它是Customers中的主键，Orders表中的外键）。当您将其建模为实体关系而不是上图时。客户实体有一个＆＃34;订单＆＃34;导航属性（通过customerId）指向特定客户的订单。 Order实体具有指向其Customer的导航属性（同样通过CustomerId）。关系为1到0或许多（1 - *），表示客户可能有0个或更多订单。

当您从客户方进行加入时，您使用左键加入＆＃34;如果您想要查看所有客户，无论他们是否有订单＆＃34; - 0个或更多订单。如果您只想查看带有订单的那些，那么您使用内部联接。

从Orders＆＃39;进行加入时那么一个订单必须有一个客户，所以它不能成为一个LEFT加入。这是一个INNER联盟。

您可以使用连接的CustomerId字段检查双方的关系。

您不会为＆＃34; OrderId，CustomerId＆＃34;提供单独的表格。因为它不是多对多关系（它将是纯冗余并且会产生规范化异常）。

希望现在更清楚。

Answer 2

在实体关系模型中，我们不会关联表格。相反，我们将由其键值表示的实体关联起来。在您的示例中，customer实体（由customer_ID表示）与order实体（由order_number表示）具有一对多关系，并记录此关系在order表格中（其中order_number与customer_ID相关联）。如果我们严格遵循ER模型，我们会在(order_number, customer_ID)（实体关系）的单独表中记录(order_number, address)（关系关系）。

如果引用order.customer_ID的{​​{1}}上有外键约束，则该子集关系可确保每个订单的客户都是已知客户。因此，表与实体之间的关系是不一样的。

关系模型允许我们以任何我们需要的方式关联（连接）表。您的示例的明显联接将位于共享域customer.customer_ID上，但我可以轻松地在其customer_ID中找到包含客户last_name的订单。

您的示例的ER图可能如下所示：

Answer 3

  

我的问题是，这些表格如何相关？他们在一起吗？什么   实体关系图会是什么样子？另外他们没有   似乎互相交互，更像是互相查找表。

当处理ER-Diagram中的数据建模时，在概念模型中更多，我们永远不应该开始考虑表，主键，外键和东西，因为这是针对后一个模型的概念模型，逻辑模型

通过在ER-Diagram中对实体进行建模，我们必须始终通过其属性/属性来识别它们。当我们可以在其中找到属性时，实体变得具体。我觉得这里缺乏背景，所以我会继续猜测：

• 如果您需要在数据库中保留产品，则需要 保存它们的属性/属性，然后我们有一个产品 实体。

• 如果您需要在数据库中保留客户端/用户以及
  他们的属性/属性，然后我们有一个客户实体。

根据您的说法，客户可以购买产品。因此，您必须以任何方式关联这两个实体。考虑到这一点，请停下来思考以下内容：

• 您需要坚持购买/订单。
• 购买/订单显示哪些用户购买了哪些产品。

通过链接产品和客户，我们会得到什么？购买/订单活动，对吧？

然后，我们将有两个相互关联的实体形成购买（或“命令”，您命名）事件。此事件由对当前业务规则（您的规则）的需求构成。作为建模者，您需要保留订单，并且您知道产品和客户以某种方式相关，因此您可以在表示订单事件的两个实体之间创建关系。

正如其他答案中已经讨论过的那样，这里需要分离属性。如果字段“地址”是用户所在的位置，而不是产品的交付地点，则此属性必须存在于Customers实体中。

如果此字段/属性/属性是交付的最终位置，则它应保留在两个实体，客户和产品之间创建的关系订单中。

现在让我们谈谈基数。如果客户可以购买/订购多个产品，并且同一产品可以由多个用户购买，那么我们在这里有N-N关系。我相信这是你的情况。

根据所说的一切，我们找到以下概念模型：

通过分解这个模型，开发逻辑模型，我们可以：

现在，出于什么原因我们最终得到了这种模型？

关系N-N允许存在属性/属性（如果需要），因此我们可以在Orders关系中拥有属性/属性，从而生成带有显示字段的ORDERS表。此表格表示用户/客户的购买/订单。

出于什么原因存在“订单产品”？

我们需要说明购买/订单中购买了哪些产品，特别是显示购买了多少相同类型的产品。在N-N关系中，一些属性引起新关系的出现，后来成为表格。在这种情况下，建模者可以自行决定。

在“来自订单的产品”实体中，我们有一个复合主键，由外键表示。

使用这种类型的模型，您可以看到：

• 哪些用户进行了购买/订单。
• 哪些用户进行了哪些购买/订单。
• 哪些产品属于哪些购买/订单。
• 哪些用户已获得哪些产品。
• 购买/订购了多少种类型的产品。

使用日期字段，您可以了解在期间内进行的购买次数：

• 周。
• 月。
• 年。
• 宿舍。
• 等

如果您有兴趣，请参阅：

E-R diagram confusion

如果您有任何问题，请发表评论，我会回答。我希望我能帮到您。

干杯。

Answer 4

“相关”是一个模糊而混乱的术语。这是因为“关系”以两种不同的方式使用：作为“关联”（在值之间）和“外键”（在表之间）。

您无需了解外键或公共列如何与表“相关”以进行查询。重要的是查询的结果行中的值如何与查询相关/关联。重要的关系/关联由表表示。

从关系角度来看，在customer_id上会有来自Order引用Customer的外键。

陈式ER图将具有订单和客户实体类型（框）和订单关系类型（菱形）以及从订单到订单和客户的参与（行）。它将为每种类型提供一个表格。这是一个完全合理的关系设计的例子，ER模型，其实体和关系之间的人为和不正常的区别，无法捕捉。但是，人们将使用像您这样的数据库设计来实现这样的ER设计。即使ER设计不是，那么，设计。

-

使用数据库时，值用于标识实体或属性名称和大小。每个基表都包含参与DBA给出的某种关系/关联的值行。每个查询结果都包含参与关系/关联的值行，这些关系/关联是条件的组合以及它提到的基表的关系/关联。您需要知道的只是表的关系/关联。

Order -- order ORDER_NUMBER is by customer CUSTOMER_ID to address ADDRESS
Customer -- customer CUSTOMER_ID is named FIRST_NAME LAST NAME
Order JOIN (Customer WHERE FIRST_NAME='Eddie')
    -- order ORDER_NUMBER is by customer CUSTOMER_ID to address ADDRESS
    AND customer CUSTOMER_ID is named FIRST_NAME LAST NAME
    AND  FIRST_NAME='Eddie'

有时，一个表的一行中的列列表的值也必须显示为另一个表或该表中的列列表的值。这是因为如果列出的值和其他值满足一个表的关系/关联，那么列出的值和其他值将满足另一个表的关系/关联。

/* IF there exist ORDER_ID & ADDRESS satisfying
       order ORDER_NUMBER is by customer CUSTOMER_ID to address ADDRESS
   THEN there exist FIRST_NAME & LAST_NAME satisfying
       customer CUSTOMER_ID is named FIRST_NAME LAST_NAME
*/
FOREIGN KEY Order(customer_id) REFERENCES Customer(customer_id)

这意味着那些特定的表和列列表满足（唯一的）关系/关联“此数据库中的外键”。 （并且数据库将具有其外键关系/关联的元数据表。）

我们说从第一个表的列列到第二个表的列列表“有一个外键”。数据库只有一个外键关系/关联。当有外键时，其表和列列表满足此数据库的外键关系。但外键不是关系/关联。人们称外键为“关系”，但事实并非如此。

但外键与查询无关！ （同样适用于任何其他约束。）查询的结果包含其值（实体和属性信息）与该查询的关系/关联相关/关联的行，这些行是根据条件和基表关系构建的/协会