为何合并数据？

设想您有一个包含客户订单信息的电子表格。对于每笔订单，您可能会列出所订购的产品、数量、价格、订单日期、客户姓名、完整收货地址和电子邮件。现在，如果一个客户下了100笔订单会怎样？您的电子表格中他们的姓名、地址和电子邮件就会重复100次！

这种做法会带来几个问题：

1. 数据重复： 您会反复存储相同的客户信息（姓名、地址、电子邮件）。这会浪费存储空间。
2. 数据不一致风险： 如果客户搬家了怎么办？您需要找到他们100条订单记录中的每一条并更新地址。如果漏掉一条，您的数据就会不一致，对同一客户显示不同的地址。
3. 管理困难： 单个包含所有内容的巨型表会变得笨重且难以管理或理解。查找与订单无关的特定信息（例如仅包含唯一客户电子邮件的列表）会变得效率低下。

关系型数据库通过将信息分解为多个相关联的表来解决这些问题。这个过程通常与数据库规范化相关。您可能不会只有一个巨型表，而是拥有：

• 一个 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 表：

一个简单的数据库结构，包含 Customers 和 Orders 表，通过 CustomerID 列关联。PK 代表主键，FK 代表外键。

为了获得显示客户姓名及其订单金额的报告，您需要将 Customers 和 Orders 表中 CustomerID 匹配的行合并起来。这正是 SQL 提供 JOIN 子句等机制的原因。它们允许您根据共同列（例如这里的 CustomerID）定义相关表应如何连接，使您能够查询合并后的数据，如同其在单一、统一视图中进行分析。

因此，了解如何合并数据是数据科学中一项基本技能，因为它使得能够分析分散在结构良好的数据库中的关系。以下章节将教您具体的 SQL 命令，从 INNER JOIN 开始，以实现此目的。