深入了解数据库三大范式
什么是范式?
当一个关系中的所有分类都是不可再分的数据项时，该关系是规范化的。不可再分的数据项，即不存在组合数据项和多项数据项。一个低一级的关系模式，通过模式分解可以转换为若干高一级范式的关系模式的集合，这个过程就叫规范化。二维数据表可以分为5级范式为1NF、2NF、3NF、4NF、5NF。第一范式满足最低的要求条件，第五范式满足最高要求的条件。
第一范式条件：
必须不包含重复组的关系，即每一列都是不可拆分的原子项。
如以下表存在可再分项（用户名称，订单号），所以不满足第一范式
非规范化转换为规范化的第一范式方法很简单，将表分别从横向、纵向展开即可。将高级职称横向展开即可以得到满足第一范式的表结构。
第二范式条件：
关系模式必须满足第一范式，并且所有非主属性都完全依赖于主码。注意，符合第二范式的关系模型可能还存在数据冗余、更新异常等问题。
举例如关系模型（职工号，姓名，职称，项目号，项目名称）中，职工号->姓名，职工号->职称，而项目号->项目名称。显然依赖关系不满足第二范式，常用的解决办法是差分表格，比如拆分为职工信息表和项目信息表。
如以下表存在一个问题，如果我们在新添加一种电器，你会发现没法放入这张表，因为没有订单号！
虽然说（产品编码，订单号）是主键，但是产品名称和单价并不依赖于订单号，所以不满足第二范式。
于是订单细节表从身上拆分出了一个产品表
第三范式的条件：
关系模型满足第二范式，所有非主属性对任何候选关键字都不存在传递依赖。即每个属性都跟主键有直接关系而不是间接关系，像：a–>b–>c。一般数据库设计中，一般要求达到3NF，第四第五较少涉及。
比如Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）这样一个表结构，就存在上述关系。 学号–> 所在院校 --> (院校地址，院校电话)。我们应该拆开来，如下：
（学号，姓名，年龄，性别，所在院校）–（所在院校，院校地址，院校电话）
如以下表存在一个问题，虽然通过了第二范式但订单号能决定用户ID，而用户ID可以决定用户名称，这就出现了传递依赖：
订单号->用户ID->用户名称，这样一来用户信息就无法单独管理，所以不满足第三范式，应该继续拆分。
此时的订单表和用户表就满足了数据库表三大范式。
好了到这我们的教程也结束了????
希望以上方法可以帮到您，祝您工作愉快！????
????
对您有帮助的话记点赞得收藏哦！????
我是 沁禹 一个在互联网摸爬滚打的工具人 ????