第三范式NF-数据库核心概念

第三范式（3NF）指的是，如果关系模式R已经达到第二范式，并且每个非主属性都不传递依赖于R的任何候选键，则称R是第三范式的模式。传递函数依赖关系是导致删除异常的主要原因。第三范式通过消除传递依赖部分，解决了数据删除异常问题。例如，关系模式SD（学号，姓名，系主任）存在传递依赖问题，因此不符合第三范式的要求。要解决这个问题，可以进一步分解关系模式SD，消除传递依赖关系。

违反第三范式的建模方式，挺适合刚接触数据建模的你琢磨一下怎么拆表合表更合理。它依赖了非主键属性，说白了就是用了一些没参与主键的外键字段。嗯，听着有点绕，但你看几个例子就懂了，像是订单表里把用户地址也存一份，这种设计其实问题挺多的。 第三范式主要是想让你减少数据冗余、提高表结构清晰度。一般来说，符合 3NF 的表，查询写起来更舒服，维护起来也不容易出问题。你要是表设计做得多，就能体会那种‘少一个字段也不行、多一个字段也出事’的精妙感觉。 相关的文章我帮你挑了一些，都是干货。比如《第三范式 SQL 基础入门指南》，适合你入门扫盲；再比如《第三范式-MYSQL 数据库基础和实例教程的详细解读》，讲得

第三范式是在第二范式的基础上，确保表中每列都直接依赖于主键，而非间接依赖。假设数据表中有A、B、C三列，如果A->B，并且B->C，则A->C。这种情况下称A与C之间存在间接依赖（传递依赖）。

工程表 工程号 | 工程名称---|---员工表 职工号 | 姓名 | 职务---|---职务表 职务 | 小时工资率---|---工时表 工程号 | 职工号 | 工时---|---

员工表 职工号 | 姓名 职务表 职务 | 小时工资率 工程表 工程号 | 工程名称 工程分配表 工程号 | 职工号 | 工时

第三范式1.4.8通过规范化方法有效减少数据冗余，是MYSQL数据库设计中的关键步骤。

1、讨论第一范式（1NF）：上述表格是否符合第一范式要求？学生信息包括学号、姓名、学院、地址以及选修课程和成绩（课程号、课程名、成绩）。 9901班张丽，管理学院201班，选修课程包括高等数学（成绩90分）、英语（成绩80分）、计算机（成绩66分）。 9902班李锋，电子电气101班，选修课程包括法律（成绩78分）。

假设关系Booking的属性如下：1． Title, 电影名2． Theater, 正在上映该电影的电影院名3． City, 电影院所在的城市合理的函数依赖：theater -> city；title, city -> theater。在此基础上，将关系模式分解为第三范式，消除不符合BCNF的关系模式和依赖。

第二范式（2NF）是关系数据库中的一个重要概念，确保数据库表中的非主属性对候选键完全依赖。在数据库设计中，遵循第二范式可以有效减少数据冗余，提高数据存储效率。