设想您有一个包含客户订单信息的电子表格。对于每笔订单,您可能会列出所订购的产品、数量、价格、订单日期、客户姓名、完整收货地址和电子邮件。现在,如果一个客户下了100笔订单会怎样?您的电子表格中他们的姓名、地址和电子邮件就会重复100次!这种做法会带来几个问题:数据重复: 您会反复存储相同的客户信息(姓名、地址、电子邮件)。这会浪费存储空间。数据不一致风险: 如果客户搬家了怎么办?您需要找到他们100条订单记录中的每一条并更新地址。如果漏掉一条,您的数据就会不一致,对同一客户显示不同的地址。管理困难: 单个包含所有内容的巨型表会变得笨重且难以管理或理解。查找与订单无关的特定信息(例如仅包含唯一客户电子邮件的列表)会变得效率低下。关系型数据库通过将信息分解为多个相关联的表来解决这些问题。这个过程通常与数据库规范化相关。您可能不会只有一个巨型表,而是拥有:一个 Customers 表:包含特定于每个客户的信息(例如 CustomerID、Name、Address、Email)。每个客户只出现一次。一个 Orders 表:包含特定于每笔订单的信息(例如 OrderID、OrderDate、CustomerID、TotalAmount)。请注意,它包含 CustomerID,这可以将订单与下订单的客户关联起来。一个 Products 表:包含关于每个产品的信息(例如 ProductID、ProductName、Price)。一个 OrderDetails 表:将订单与产品关联,指明哪些产品在哪些订单中以及数量(例如 OrderDetailID、OrderID、ProductID、Quantity)。这种分离提供了显著优势:减少数据重复: 客户详细信息只在 Customers 表中存储一次。产品详细信息只在 Products 表中存储一次。提升数据完整性: 如果客户地址变动,您只需在一处更新:即他们在 Customers 表中的唯一记录。当数据合并查看时,此更改会自动反映在他们所有过去和未来的订单中。类似地,如果产品价格变动,您只需在 Products 表中更新一次。更好的组织结构: 每个表都代表一个独立的实体或抽象物(客户、订单、产品)。这使得数据库结构合乎逻辑、更易于理解且更易于维护。然而,对于数据分析,您经常需要看到合并后的全貌。您可能需要回答以下问题:“哪些客户(姓名)订购了哪些产品(名称)?”“每个客户(姓名)的总消费金额是多少?”“显示订购了特定产品的客户地址。”当数据被拆分到单独的表中时,只查看其中一个表通常无法提供所有必需的信息。例如,一个订单表可能缺少客户详情,而一个客户表不会显示具体的订单项目。为了分析完整的数据并回答各种问题,您需要将来自不同表的相关信息汇集起来。考虑我们简单的 Customers 和 Orders 表:digraph G { rankdir=LR; node [shape=plaintext]; splines=ortho; edge[arrowhead=crow, arrowtail=none, dir=both]; Customers [label=< <TABLE BORDER="0" CELLBORDER="1" CELLSPACING="0"> <TR><TD COLSPAN="3" BGCOLOR="#a5d8ff">客户</TD></TR> <TR><TD BGCOLOR="#dee2e6">客户ID (主键)</TD><TD>姓名</TD><TD>城市</TD></TR> <TR><TD>1</TD><TD>Alice</TD><TD>纽约</TD></TR> <TR><TD>2</TD><TD>Bob</TD><TD>伦敦</TD></TR> </TABLE> >]; Orders [label=< <TABLE BORDER="0" CELLBORDER="1" CELLSPACING="0"> <TR><TD COLSPAN="4" BGCOLOR="#ffd8a8">订单</TD></TR> <TR><TD BGCOLOR="#dee2e6">订单ID (主键)</TD><TD>客户ID (外键)</TD><TD>订单日期</TD><TD>金额</TD></TR> <TR><TD>101</TD><TD>1</TD><TD>2023-01-15</TD><TD>50.00</TD></TR> <TR><TD>102</TD><TD>2</TD><TD>2023-01-16</TD><TD>75.00</TD></TR> <TR><TD>103</TD><TD>1</TD><TD>2023-01-18</TD><TD>25.50</TD></TR> </TABLE> >]; Customers:CustomerID -> Orders:CustomerID [label="将订单与客户关联"]; }一个简单的数据库结构,包含 Customers 和 Orders 表,通过 CustomerID 列关联。PK 代表主键,FK 代表外键。为了获得显示客户姓名及其订单金额的报告,您需要将 Customers 和 Orders 表中 CustomerID 匹配的行合并起来。这正是 SQL 提供 JOIN 子句等机制的原因。它们允许您根据共同列(例如这里的 CustomerID)定义相关表应如何连接,使您能够查询合并后的数据,如同其在单一、统一视图中进行分析。因此,了解如何合并数据是数据科学中一项基本技能,因为它使得能够分析分散在结构良好的数据库中的关系。以下章节将教您具体的 SQL 命令,从 INNER JOIN 开始,以实现此目的。