DBMS 规范化：含 SQL 示例的完整指南

如果您再也不想处理不一致、冗余的数据，数据库规范化就是正确的方向。

您可能体会过这样的挫败感：在一张表里更新了客户信息，却发现另外五张表里还散落着过时版本。查询返回相互矛盾的结果，报表因为取数表不同而出现不同的数字，您还要花上数小时去调试本不该出现的数据完整性问题。随着数据库规模增长，这些问题只会倍增。

数据库规范化通过基于成熟数学原理来组织数据，从根本上消除这些痛点。该过程使用“范式”来确保每一条信息只存在于一个位置，使数据库既可靠又高效。

我将带您完整走一遍规范化流程，从基础概念到高级范式，并通过动手示例把凌乱数据转变为干净、易维护的数据库结构。

为什么规范化很重要？

规范化能让您的数据库避免变成维护噩梦。下面看看在真实应用中，正确规范化为何如此重要。

数据冗余 

冗余是数据库性能的隐形杀手。当您在多个地方存储相同信息时，不仅浪费存储空间，还为破坏应用逻辑的不一致性埋下了伏笔。

如果没有规范化，更新某个客户地址就意味着要在每一张存有地址数据的表里“地毯式搜寻”。漏掉一处，报表就会出现相互矛盾的信息；用户在不同界面看到的地址不一致；分析也不再可信。

规范化通过确保每条数据只存放在唯一位置来解决这个问题。当您更新该客户的地址时，所有地方都会自动更新，因为它们都引用同一个源。

数据完整性 

正确规范化后，完整性将“固若金汤”。外键约束可防止“孤儿”记录；您不可能误删仍有未完成订单的客户；数据库在数据层面而非仅在应用代码中就可强制执行业务规则。

这意味着更少的漏洞、更干净的代码，以及即便有多个系统访问同一数据，应用也能可预期地运行。

数据异常 

通过正确规范化，修改异常会消失。所谓修改异常，是指在插入、更新或删除数据时产生不一致，或不得不依赖复杂的权宜之计。

插入异常会迫使您为了创建记录而添加“占位”数据；更新异常要求您在多行中重复修改同一信息；删除异常在您删除单条记录时却意外移除了超出预期的更多信息。

通过将数据组织为每个事实只出现一次，规范化数据库可以根除这些问题。

性能与可扩展性 

结构清晰时，性能与可扩展性都会提升。规范化后的表通常更小，这意味着查询更快、缓存利用更好。索引在更小、更聚焦的表上也更高效。

由于规范化数据有清晰边界，您的数据库可实现水平扩展。您可以进行逻辑分片，而无需在多个分片间复制信息。

安全性 

在规范化数据库中，安全管理更容易。您可以自信地在表级别控制访问，因为敏感数据位于特定且定义明确的位置。无需担心客户信用卡号藏在某些意想不到的表里。

审计轨迹也更清晰——您确切知道更改发生在何处，并且无需在架构里分散的冗余数据中大海捞针就能跟踪它们。

总之，规范化将混乱数据转化为可随应用一同成长的可靠基石。

接下来看看进行规范化前需要具备哪些前提条件。

关键概念与前提条件

在开始对表进行规范化之前，您需要理解支撑规范化发挥作用的要素。下面覆盖整个过程中指导您决策的核心概念。

理解数据库规范化中的键

键是关系型数据库设计的基础——它们用于标识记录并将表关联起来。

一种主键能够唯一标识表中的每一行。两行不能拥有相同的主键值，且它不能为空。可以把它看作数据的“社保号”——每条记录恰好对应一个，且不可能重复。

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    email VARCHAR(255),
    name VARCHAR(100)
);技术支持

在这里，customer_id 是主键。每位客户都会获得一个唯一 ID，您将用它从其他表中引用该客户。

候选键是任何可以充当主键的列（或列的组合）。您的 customers 表中，customer_id 和 email 可能都是候选键，因为两者都能唯一标识客户。您选择其中一个作为主键，其他保持为候选键。

外键用于在表之间创建关系。它们引用另一张表的主键，并建立维护数据完整性的连接。

CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);技术支持

orders 表中的 customer_id 是外键。它必须与 customers 表中存在的 customer_id 匹配。这可以防止“孤儿”订单，并确保每个订单都属于真实存在的客户。

键在数据库层面强制执行业务规则，使您的数据比仅靠应用校验更可靠。

函数依赖的作用

函数依赖描述了表内各列之间的相互关系。它们是驱动规范化决策的数学基础。

当一列的值能决定另一列的值时，就存在函数依赖。我们记为 A → B，意思是“由 A 决定 B”或“B 依赖于 A”。

在 customers 表中，customer_id → email，因为每个客户 ID 恰好对应一个电子邮箱地址。若您知道客户 ID，就能确定邮箱。

图 1 - 函数依赖示例

这里，customer_id → email 和 customer_id → name，因为客户 ID 同时决定邮箱和姓名。

函数依赖能暴露冗余问题。

如果您有一张表满足 order_id → customer_name，却在每行订单里都存客户名，那就是冗余。客户名应该依赖客户 ID，而不是订单 ID。

依赖保持意味着规范化后的各表仍保留原有的函数依赖。当您在规范化中拆分表时，不应失去对原表中业务规则的强制能力。

无损分解保证您可以通过连接规范化后的表来重建原表。拆分表不会丢失任何信息——连接后能精确还原起始数据。

这些概念协同工作：函数依赖指出应拆分之处，而依赖保持与无损分解确保在此过程中不破坏原有功能。

理解这些关系有助于您做出明智的规范化决策，在不损失功能的情况下改进数据库。

逐步规范化流程

现在我们从杂乱数据出发，逐步演练实际的规范化过程。每个范式都建立在前一个之上，因此不能直接从未规范化数据跃迁到 3NF。

第一范式（1NF）

第一范式消除重复组，确保每一列都是原子值。想深入了解，请参阅 第一范式（1NF）深度指南。

原子值意味着每个单元格只承载一条信息——没有列表、没有逗号分隔值、没有把多条数据塞进一个字段。这是让其他一切成为可能的基础。

以下情况违反了 1NF：

CREATE TABLE orders_bad (
    order_id INT,
    customer_name VARCHAR(100),
    products VARCHAR(500), 
    quantities VARCHAR(50) 
);技术支持

图 2 - 违反 1NF 的表

products 与 quantities 列包含多个用逗号分隔的值。您很难轻松查询“包含笔记本电脑的所有订单”，或在不进行字符串解析的情况下计算总数量。

要转换为 1NF，请将重复组拆分为独立的行：

-- 第一范式（1NF）
CREATE TABLE orders_1nf (
    order_id INT,
    customer_name VARCHAR(100),
    product VARCHAR(100),
    quantity INT
);技术支持

图 3 - 满足 1NF 的表

此时每个单元格都只包含一个值。您可以使用标准 SQL 操作进行查询、排序与聚合。

第二范式（2NF）

第二范式移除部分依赖——即非键列仅依赖于复合主键的一部分时。

第二范式（2NF）远不止表面那么简单。想了解更多内容，请参阅我们的深度指南。

当一张表满足 1NF，且每个非键列都依赖于整个主键（而非主键的一部分），即可认为满足 2NF。

我们的 1NF 表存在问题。如果将 order_id 与 product 作为复合主键，customer_name 仅依赖 order_id 而非产品，这会造成冗余——同一订单的每个产品行都重复客户名。

-- 仍存在部分依赖
-- customer_name 只依赖 order_id，不依赖 (order_id, product)
CREATE TABLE orders_1nf (
    order_id INT,
    customer_name VARCHAR(100), -- 部分依赖！
    product VARCHAR(100),
    quantity INT,
    PRIMARY KEY (order_id, product)
);技术支持

为达到 2NF，依据依赖关系拆分表：

-- 订单表（客户信息依赖 order_id）
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_name VARCHAR(100)
);

-- 订单明细表（quantity 同时依赖 order_id 和 product）
CREATE TABLE order_items (
    order_id INT,
    product VARCHAR(100),
    quantity INT,
    PRIMARY KEY (order_id, product),
    FOREIGN KEY (order_id) REFERENCES orders(order_id)
);技术支持

现在 customer_name 每个订单只出现一次，消除了冗余。每张表中的列都依赖于整个主键。

第三范式（3NF）

第三范式消除传递依赖，即非键列依赖于其他非键列而非主键。深入了解第三范式（3NF）的更多细节。

当“列 A”决定“列 B”，而“列 B”又决定“列 C”时，就形成了从 A 到 C 的间接依赖，即传递依赖。

让我们在订单表中加入客户地址信息：

-- 存在传递依赖
CREATE TABLE orders_2nf (
    order_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    customer_city VARCHAR(50),
    customer_state VARCHAR(50),
    customer_zip VARCHAR(10)
);技术支持

问题在于：customer_name → customer_city，且 customer_city → customer_state。州信息依赖于城市，而非直接依赖订单。这造成冗余——来自同一城市的每个订单都重复州信息。

为达到 3NF，通过创建独立表来移除传递依赖：

-- 客户表（移除传递依赖）
CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    city_id INT,
    FOREIGN KEY (city_id) REFERENCES cities(city_id)
);

-- 城市表
CREATE TABLE cities (
    city_id INT PRIMARY KEY,
    city_name VARCHAR(50),
    state VARCHAR(50),
    zip VARCHAR(10)
);

-- 订单表（现在引用客户，而非客户详情）
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    order_date DATE,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);技术支持

现在地理信息集中存放在一个地方。如果某个城市变更州（虽罕见但可能），您只需更新一行，而不必在该城市的所有订单中逐一查找。

每种范式都在保持可通过连接重建原始数据的前提下，解决特定的冗余问题。

高级范式

前三种范式可以处理大多数现实世界的数据库问题，但一些边界场景需要更深入的规范化。这些高级范式处理的是 3NF 无法解决的特定依赖问题。

巴斯-科得范式（BCNF）

BCNF 修复了 3NF 遗漏的一个微妙问题：当一张表有重叠的候选键时。

3NF 允许非键列依赖候选键，但 BCNF 要求更严格。在 BCNF 中，每个决定因素（能决定其他列的列）都必须是超键——即主键或候选键。

以下是 3NF 失效的场景：

-- 满足 3NF 但违反 BCNF 的表
CREATE TABLE course_instructors (
    student_id INT,
    course VARCHAR(50),
    instructor VARCHAR(50),
    PRIMARY KEY (student_id, course)
);技术支持

业务规则如下：

• 每位学生可以选修多门课程
• 每门课程恰好对应一位授课教师
• 每位教师恰好教授一门课程

这导致 course → instructor 和 instructor → course 的依赖。(student_id, course) 与 (student_id, instructor) 均为候选键，但 course 与 instructor 彼此决定，却各自并非超键。

问题会在您尝试在没有学生的情况下添加新教师时暴露。您无法仅插入“Smith 教授教授《数据库设计》”而不同时为该课程新增一名学生。

为达到 BCNF，依据问题依赖进行分解：

-- BCNF 解决方案
CREATE TABLE course_assignments (
    course VARCHAR(50) PRIMARY KEY,
    instructor VARCHAR(50) UNIQUE
);

CREATE TABLE student_enrollments (
    student_id INT,
    course VARCHAR(50),
    PRIMARY KEY (student_id, course),
    FOREIGN KEY (course) REFERENCES course_assignments(course)
);技术支持

现在即便没有学生也能添加教师，且数据库结构与业务规则完全一致。

第四范式（4NF）

4NF 消除多值依赖——即一列能决定另一个列的多组相互独立的值。

当“列 A”决定“列 B”的多个值，且这些值与表中其他列相互独立时，就存在多值依赖。

考虑如下跟踪学生技能与爱好的表：

-- 因多值依赖而违反 4NF
CREATE TABLE student_info (
    student_id INT,
    skill VARCHAR(50),
    hobby VARCHAR(50),
    PRIMARY KEY (student_id, skill, hobby)
);技术支持

图 4 - 违反 4NF 的表

问题在于：student_id 同时决定技能与爱好，但技能与爱好彼此独立。当学生 1 学会一项新技能时，您需要为其每个爱好组合创建新行；当他新增一个爱好时，又需要为其每项技能组合创建新行。

随着技能与爱好数量增长，这会引发“组合爆炸”的冗余。

为达到 4NF，分离这些相互独立的多值依赖：

-- 4NF 解决方案
CREATE TABLE student_skills (
    student_id INT,
    skill VARCHAR(50),
    PRIMARY KEY (student_id, skill)
);

CREATE TABLE student_hobbies (
    student_id INT,
    hobby VARCHAR(50),
    PRIMARY KEY (student_id, hobby)
);技术支持

现在可以独立地添加技能与爱好，而不会产生笛卡尔积式的爆炸。

第五与第六范式（5NF 与 6NF）

5NF（投影-连接范式，PJNF）消除连接依赖：即只有通过连接三个或以上表才能无损重建数据的复杂关系。

当您无法通过连接两张分解后的表来重建原表，但能通过连接三张或更多表来重建时，就存在连接依赖。

考虑供应商、零件与项目这一规则：“只有当供应商能提供该零件且参与该项目时，供应商才能向项目供应该零件。”

-- 存在连接依赖的原始表
CREATE TABLE supplier_part_project (
    supplier_id INT,
    part_id INT,
    project_id INT,
    PRIMARY KEY (supplier_id, part_id, project_id)
);技术支持

为达到 5NF，将其分解为三个二元关系：

-- 5NF 分解
CREATE TABLE supplier_parts (supplier_id INT, part_id INT);
CREATE TABLE supplier_projects (supplier_id INT, project_id INT);  
CREATE TABLE project_parts (project_id INT, part_id INT);技术支持

只有连接这三张表才能重建有效的“供应商-零件-项目”组合，从而在架构层面强制执行业务规则。

6NF 将规范化推向极致：将每个属性放到自己的表中，并使用时间键。

6NF 适用于需要独立追踪每个属性随时间变化的数据仓库和时态数据库。

-- 面向时态数据的 6NF 示例
CREATE TABLE customer_names (
    customer_id INT,
    name VARCHAR(100),
    valid_from DATE,
    valid_to DATE
);

CREATE TABLE customer_addresses (
    customer_id INT,
    address VARCHAR(200),
    valid_from DATE,
    valid_to DATE
);技术支持

这样您就能在不影响其他属性的情况下追踪每个属性的变更时间点，但查询会更复杂，且除专门的时态系统外很少使用。

大多数应用止步于 3NF 或 BCNF。这些高级范式解决特定边界问题，但会带来对普通业务应用而言不必要的复杂度。