这些表有啥关系？

Posted 2023-05-09

【中文标题】这些表有啥关系？

【英文标题】：How are these tables related?这些表有什么关系？

【发布时间】：2016-05-11 17:24:25

【问题描述】：

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

表 order 和字段 order_number, customer_ID, address

表 customer 和字段 customer_ID, first_name, last_name

为了获得完整、详细的订单“报告”，我将执行 LEFT JOIN 以连接订单表中的数据，以包括客户的名字和姓氏以及他们的地址和订单号。

我的问题是，这些表有什么关系？他们是吗？实体关系图会是什么样子？分开来看，它们似乎没有交互，更像是彼此的查找表。

【问题讨论】：

它们是一对多相关的（1个客户有很多订单，但1个订单有1个客户）

【参考方案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 >---+ 1 Customer_Id ... ...

此 EF 关系来自 MS SQL Server 的示例数据库 Northwind。在那个示例数据库中，就像您的一样，有客户和订单。客户表和订单表通过两个表中的 CustomerId 字段相关联（它是客户表中的主键和订单表中的外键）。当您将其建模为实体关系时，您将拥有上图。客户实体具有指向特定客户订单的“订单”导航属性（通过 customerId）。 Order 实体有一个指向其客户的导航属性（同样通过 CustomerId）。该关系是 1 到 0 或多 (1 - *)，这意味着客户可能有 0 个或更多订单。

当您从客户端进行联接时，您使用 LEFT 联接“如果您想查看所有客户，无论他们是否有订单” - 0 个或更多订单。如果您只想查看那些有 Order(s) 的人，那么您可以使用内部连接。

当您从 Orders 端进行联接时，订单必须有一个 Customer，因此它不能是 LEFT 联接。这是一个 INNER 联接。

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

您不会为“OrderId，CustomerId”创建单独的表，因为它不是多对多关系（这将是纯粹的冗余并会产生规范化异常）。

希望现在更清楚了。

【讨论】：

Order Customer Customer_Id 0...N >---+ 1 Customer_Id 你能详细说明你的意思吗？我不熟悉这种语法

对不起，我只是使用了基于文本的语法。添加了图片和更多解释。 HTH。

@CetinBasoz：您的答案不是基于实体关系模型。

问题的要点是关于表关系 - “我的问题是，这些表是如何相关的？”以及它上面的段落。

问题标记为entity-relationship，但您的答案基于实体框架，它是网络数据模型的实现。

【参考方案2】：

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

如果在 order.customer_ID 上存在引用 customer.customer_ID 的外键约束，则这是确保每个订单的客户都是已知客户的子集关系。因此，表之间的关系和实体之间的关系不是一回事。

关系模型允许我们以任何需要的方式关联（连接）表。对于您的示例，显而易见的连接将在共享域 customer_ID 上，但我可以很容易地找到包含客户 last_name 在其交付 address 中的订单。

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

【讨论】：

我明白，你的图表很清楚。为什么没有来自“订单”的 customer_id 分支？是不是因为 customer_id 是 customer 表的主键所以只显示在那里？

是的，customer_id 代表一个实体，order_number 和 customer_id 之间的关联被认为是关系而不是属性。在 ER 中，属性是从实体集到值集的映射，而关系是实体集之间的关联。

@CetinBasoz 我不确定你的意思。我的观点是关系模型允许我以任何我想要的方式加入表，例如SELECT * FROM customer c JOIN order o ON LOCATE(c.last_name, o.address) > 0。导航数据模型具有固定的访问路径，这使得临时查询变得困难且效率低下。

发票地址和帐单地址和地址实体与OP的问题有什么关系？ In this little model, you cannot use Address instead. 而不是什么？ An Order might have been Ordered by Customer "John Doe" and sent to someone which happens to be another Customer "Frank Smith" 同样，这与 OP 的问题有什么关系？我给出了 SQL 来准确地证明按照我说的去做是多么容易。我哪里错了？

再一次，我的观点和我的例子是为了表明关系模型允许我们以任何可能的方式关联表，而不仅仅是通过预定义的导航路径。我意识到，从网络模型的角度来看，实体关系和外键约束看起来是一回事，甚至没有考虑动态关系，这就是我区分它们的原因。

【参考方案3】：

我的问题是，这些表有什么关系？他们是吗？什么 实体关系图会是什么样子？分开他们不 似乎交互和行为更像是彼此的查找表。

在处理 ER-Diagram 中的数据建模时，更多地是在概念模型中，我们永远不应该开始考虑表、主键、外键和其他东西，因为这是后来的模型到概念模型、逻辑模型.

通过在 ER-Diagram 中建模实体，我们必须始终通过它们的属性/属性来识别它们。当我们可以在实体中找到属性时，实体就会变得具体。我觉得这里缺乏上下文，所以我将继续猜测：

如果您需要将产品持久保存在数据库中，并且您需要 保存它们的属性/属性，然后我们有一个产品 实体。

如果您需要将客户端/用户与一起保存在数据库中 他们的属性/属性，然后我们有一个客户实体。

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

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

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

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

正如其他答案中已经很好讨论的那样，这里需要分离属性。如果“地址”字段是用户居住的地方，而不是产品将交付的地方，则此属性必须存在于客户实体中。

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

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

根据上面所说的，我们找到了以下概念模型：

通过分解此模型并开发逻辑模型，我们将：

现在，为什么我们会采用这种模型？

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

“订单产品”存在的原因是什么？

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

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

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

哪些用户进行了购买/订购。 哪些用户进行了哪些购买/订单。 哪些产品属于哪些购买/订单。 哪些用户购买了哪些产品。 购买/订购了多少种产品。

使用日期字段，您可以了解各个时期的购买次数：

几周。 几个月。 年。 宿舍。 等

如果您有兴趣，另请参阅：

E-R diagram confusion

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

干杯。

【参考方案4】：

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

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

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

Chen 样式的 ER 图将具有 Order 和 Customer 实体类型（框）和 Orders 关系类型（菱形），其中包含从 Orders 到 Order 和到 Customer 的参与（线）。每种类型都有一个表格。这是一个完全合理的关系设计示例，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)

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

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

但是外键对查询无关紧要！ （任何其他约束同上。）查询的结果包含其值（实体和属性信息）由该查询的关系/关联相关/关联的行，由条件和基表关系/协会.