Mysql数据库设计三范式实例解析

三范式

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）要求数据库表中的每个实例或⾏必须可以被惟⼀地区分。为实现区分通常需要我们设计⼀个主键来实现(这⾥的主键不包含业务逻辑)。即满⾜第⼀范式前提，当存在多个主键的时候，才会发⽣不符合第⼆范式的情况。⽐如有两个主键，不能存在这样的属性，它只依赖于其中⼀个主键，这就是不符合第⼆范式。通俗理解是任意⼀个字段都只依赖表中的同⼀个字段。（涉及到表的拆分）看下⾯的学⽣选课表：学号课程成绩课程学分10001数学100610001语⽂9010001英语8510002数学9010003数学9910004语⽂89

23662

表中主键为 （学号，课程），我们可以表⽰为 (学号，课程) -> (成绩，课程学分)， 表⽰所有⾮主键列 (成绩，课程学分)都依赖于主键 (学号，课程)。 但是，表中还存在另外⼀个依赖：（课程）->(课程学分）。这样⾮主键列 ‘课程学分‘ 依赖于部分主键列 '课程‘， 所以上表是不满⾜第⼆范式的。我们把它拆成如下2张表：学⽣选课表：学号课程成绩10001数学10010001语⽂90

10001英语成绩85学号课程10002数学9010003数学9910004语⽂89课程信息表：课程课程学分数学6语⽂3英语2

那么上⾯2个表，学⽣选课表主键为（学号，课程），课程信息表主键为（课程），表中所有⾮主键列都完全依赖主键。不仅符合第⼆范式，还符合第三范式。再看这样⼀个学⽣信息表：学号

姓名性别班级班主任

男男男

⼀班⼩王⼀班⼩王⼆班⼩李⼆班⼩李

10001张三10002李四10003王五

10004张⼩三男

上表中，主键为：（学号），所有字段 （姓名，性别，班级，班主任）都依赖与主键（学号），不存在对主键的部分依赖。所以是满⾜第⼆范式。

第三范式（3NF）

满⾜第三范式（3NF）必须先满⾜第⼆范式（2NF）。简⽽⾔之，第三范式（3NF）要求⼀个数据库表中不包含已在其它表中已包含的⾮主键字段。就是说，表的信息，如果能够被推导出来，就不应该单独的设计⼀个字段来存放(能尽量外键join就⽤外键join)。很多时候，我们为了满⾜第三范式往往会把⼀张表分成多张表。

即满⾜第⼆范式前提，如果某⼀属性依赖于其他⾮主键属性，⽽其他⾮主键属性⼜依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。 通俗解释就是⼀张表最多只存两层同类型信息。

反三范式

没有冗余的数据库未必是最好的数据库，有时为了提⾼运⾏效率，提⾼读性能，就必须降低范式标准，适当保留冗余数据。具体做法是： 在概念数据模型设计时遵守第三范式，降低范式标准的⼯作放到物理数据模型设计时考虑。降低范式就是增加字段，减少了查询时的关联，提⾼查询效率，因为在数据库的操作中查询的⽐例要远远⼤于DML的⽐例。但是反范式化⼀定要适度，并且在原本已满⾜三范式的基础上再做调整的。

以上就是本⽂的全部内容，希望对⼤家的学习有所帮助，也希望⼤家多多⽀持。