第三范式（3NF）在数据库基础中的应用

第三范式（3NF）是指当一个数据表已经达到第二范式要求，并且表中任何非主键字段之间不存在函数依赖关系时，该数据表符合第三范式。或者说，它涉及商品的单价、数量和总额。

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

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

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

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

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

将R表分解为3个关系表： R1(商店编号，商品编号，部门编号，商品库存数量） R2(商店编号，部门负责人）

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

第一范式的定义听起来挺理论，但其实贴近咱前端日常遇到的数据结构问题。第一范式（1NF）要求字段的数据必须是原子的，也就是说，一个字段只能放一个值，不能搞成列表或者结构体那样复杂。嗯，听起来是不是像你做表单校验时要求字段必须明确、简单？在做前端接口对接时，字段一旦不原子，数据解析就麻烦，比如一个字段同时塞进用户多个爱好，还得你前端自己拆数组，烦不烦？所以数据库建表那会儿就定好规范，能省不少事。想看点实战的内容？我给你挑了几个链接，还不错：关系数据库设计中的第一范式（1NF）：讲得比较基础，适合扫盲第一范式 NF-空间数据库详解：偏进阶，适合深入了解数据库第一范式示例：举了书籍借阅的例子，挺贴生活