数据库设计基石：从函数依赖到范式（1NF至BCNF）的实战解析

1. 函数依赖：数据库设计的隐藏规则

第一次接触函数依赖这个概念时，我正被一个学生选课系统的数据冗余问题困扰。每次修改学生所在院系，都要更新几十条记录，稍不注意就会导致数据不一致。直到理解了函数依赖，才明白问题根源在于表结构设计违反了基本的数据库设计原则。

函数依赖本质上描述的是属性之间的约束关系。举个生活中的例子：在我们公司，每个员工工号(emp_id)唯一对应一个员工姓名(emp_name)，这就是一个典型的函数依赖关系，记作emp_id→emp_name。这意味着：

• 同一个emp_id不可能对应多个emp_name
• 知道emp_id就一定能确定emp_name
• 这种关系适用于所有情况，没有例外

在数据库设计中，我们主要关注三类函数依赖：

1.1 完全依赖 vs 部分依赖
想象一个订单明细表(order_id, product_id, product_name, quantity)。这里(order_id, product_id)是联合主键。product_name其实只依赖于product_id，与order_id无关，这就是部分依赖。而quantity则同时依赖于order_id和product_id，缺少任何一个都无法确定，这就是完全依赖。

1.2 传递依赖的陷阱
我曾经设计过一个员工表(emp_id, dept_id, dept_location)，其中：

• emp_id → dept_id
• dept_id → dept_location
  这就形成了传递依赖，导致修改部门地址时需要更新多条记录。好的做法是拆分成两个表：(emp_id, dept_id)和(dept_id, dept_location)。

1.3 平凡依赖的普遍性
任何包含所有属性的依赖都是平凡依赖，比如(order_id, product_id)→product_id。这类依赖虽然总是成立，但对数据库设计没有实际意义。

理解这些概念后，再看我之前的学生选课系统问题就清晰了：学生院系信息部分依赖于学号（而不是完全依赖于学号和课程号的组合），这正是导致数据冗余的元凶。

2. 码：数据库实体的唯一标识

刚开始用数据库时，我经常混淆主码、候选码这些术语。直到有次面试被问得哑口无言，才下决心彻底搞明白。现在看，码的概念其实就像