Mysql数据库
⽬前关系数据库有六种范式：
第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）、巴斯-科德范式
（BCNF）、第四范式(4NF）和第五范式（5NF，⼜称完美范式）。满⾜最低要求的范式是
第⼀范式（1NF）。在第⼀范式的基础上进⼀步满⾜更多规范要求的称为第⼆范式
（2NF），其余范式以次类推。⼀般说来，数据库只需满⾜第三范式(3NF）就⾏了。所以
这⾥就只记录三范式相关的知识。
⼀ 范式
1NF:字段不可分; 2NF:有主键，⾮主键字段依赖主键; 3NF:⾮主键字段不能相互依赖;
解释: 1NF:原⼦性 字段不可再分,否则就不是关系数据库; 2NF:唯⼀性 ⼀个表只说明⼀个事
物; 3NF:每列都与主键有直接关系，不存在传递依赖;
第⼀范式（1NF）
即表的列的具有原⼦性,不可再分解，即列的信息，不能分解, 只要数据库是关系型数
据库(mysql/oracle/db2/informix/sysbase/sql server)，就⾃动的满⾜1NF。数据库表的每⼀
列都是不可分割的原⼦数据项，⽽不能是集合，数组，记录等⾮原⼦数据项。如果实体中
的某个属性有多个值时，必须拆分为不同的属性 。通俗理解即⼀个字段只存储⼀项信息。
关系型数据库: mysql/oracle/db2/informix/sysbase/sql server ⾮关系型数据库: (特点:
⾯向对象或者集合) NoSql数据库: MongoDB/redis(特点是⾯向⽂档)
第⼆范式（2NF）
第⼆范式（2NF）是在第⼀范式（1NF）的基础上建⽴起来的，即满⾜第⼆范式
（2NF）必须先满⾜第⼀范式（1NF）。第⼆范式（2NF）要求数据库表中的每个实例或⾏
必须可以被惟⼀地区分。为实现区分通常需要我们设计⼀个主键来实现(这⾥的主键不包含
业务逻辑)。即满⾜第⼀范式前提，当存在多个主键的时候，才会发⽣不符合第⼆范式的情况。⽐如有
两个主键，不能存在这样的属性，它只依赖于其中⼀个主键，这就是不符合第⼆范式。通
俗理解是任意⼀个字段都只依赖表中的同⼀个字段。（涉及到表的拆分）
第三范式（3NF）
满⾜第三范式（3NF）必须先满⾜第⼆范式（2NF）。简⽽⾔之，第三范式（3NF）要
求⼀个数据库表中不包含已在其它表中已包含的⾮主键字段。就是说，表的信息，如果能
够被推导出来，就不应该单独的设计⼀个字段来存放(能尽量外键join就⽤外键join)。很多
时候，我们为了满⾜第三范式往往会把⼀张表分成多张表。
即满⾜第⼆范式前提，如果某⼀属性依赖于其他⾮主键属性，⽽其他⾮主键属性⼜依赖于
主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。 通俗解释就是⼀
张表最多只存两层同类型信息。
巴斯-科德范式（BCNF）
Boyce-Codd Normal Form（巴斯-科德范式）
在3NF基础上，任何⾮主属性不能对主键⼦集依赖（在3NF基础上消除对主码⼦集的依赖）
巴斯-科德范式（BCNF）是第三范式（3NF）的⼀个⼦集，即满⾜巴斯-科德范式（BCNF）
必须满⾜第三范式（3NF）。通常情况下，巴斯-科德范式被认为没有新的设计规范加⼊，
只是对第⼆范式与第三范式中设计规范要求更强，因⽽被认为是修正第三范式，也就是
说，它事实上是对第三范式的修正，使数据库冗余度更⼩。这也是BCNF不被称为第四范式
的原因。某些书上，根据范式要求的递增性将其称之为第四范式是不规范，也是更让⼈不
容易理解的地⽅。⽽真正的第四范式，则是在设计规范中添加了对多值及依赖的要求
第四范式
对于第四范式，从理论层⾯来讲是，关系模式R∈1NF,如果对于R对于R的每个⾮平凡多值依
赖X→Y(Y不属于X),X都含有候选码，则R∈4NF。4NF就是限制关系模式的属性之间不允许有
⾮平凡且⾮函数依赖的多值依赖。显然⼀个关系模式是4NF，则必为BCNF。
也就是说，当⼀个表中的⾮主属性互相独⽴时（3NF），这些⾮主属性不应该有多
值。若有多值就违反了第四范式。
第五范式不得存在不遵循键约束的⾮平凡连接依赖。如果且只有⼀个表符合4NF，同时其中的每个
连接依赖被候选键所包含，此表才符合第五依赖。
⼆ 反三范式
没有冗余的数据库未必是最好的数据库，有时为了提⾼运⾏效率，提⾼读性能，就必
须降低范式标准，适当保留冗余数据。具体做法是： 在概念数据模型设计时遵守第三范
式，降低范式标准的⼯作放到物理数据模型设计时考虑。降低范式就是增加字段，减少了
查询时的关联，提⾼查询效率，因为在数据库的操作中查询的⽐例要远远⼤于DML的⽐
例。但是反范式化⼀定要适度，并且在原本已满⾜三范式的基础上再做调整的
