数据库设计的三范式

第一范式

数据库设计的第一范式，就是实体类属性都是不可再分的，每个属性都是原子属性
比如：把员工设计成一个表
正确的设计：员工号（主键）、姓名、手机号、电子邮箱、微信号、QQ号
错误的设计：员工号（主键）、姓名、联系方式
错误的设计中，将员工所有的联系方式都合并为一列，而实际上员工可以有不同的联系方式，每一个联系方式都可以是原子的
违反数据库设计的第一范式，是不好的，通常我们设计数据库，都会要求必须满足第一范式

第二范式

数据库设计的第二范式，就是每个在设计每个实体类属性时，都要求有标识每个实体的唯一属性
也就是说要求每一行都要有主键id,
在其它博客中说的是：非主键属性要依赖于主键属性，其实表达的意思差不多
比如，给学生设计一个表
错误的设计：学生表:学号（主键）, 姓名, 年龄, 课程名称, 成绩, 学分;
这个表明显说明了两个事务:学生信息, 课程信息，不符合第二范式，因为课程信息并不是完全依赖于学号，甚至跟学生的学号没有一点关系，不仅如此，还存在着数据冗余
正确的做法：
学生表：学号（主键）, 姓名, 年龄, 学分
课程表：课程号（主键），课程名称
学生成绩表：成绩表id(主键)，学号，课程号，成绩
这样将关系拆分成三个表，就是正确的做法

第三范式

违反第三范式的意思就是数据库表在设计的过程中，存在数据冗余
比如给学生和班级设计数据库表
错误的做法：
学生表：学号，姓名，年龄，班级号，班级名，班级人数
班级表：班级号，班级名，班级人数
这样的设计产生了数据冗余，学生表里的班级名和班级人数是冗余字段
正确的做法：
学生表：学号，姓名，年龄，班级号
班级表：班级号，班级名，班级人数

思考：
我们通常在企业开发中，最低要求满足第一范式，做到实体属性的不可再分，第二范式也要尽量满足，第三范式可以不满足
为什么第三范式可以不用满足呢：因为有的时候，为了减轻数据库访问压力，会把数据在多处存储，提高数据查询速度，比如领导让你做个报表功能，最好的做法，就是设计大量的冗余字段，把领导需要的字段汇总到一张表里，然后查询该表，并保存到报表所在的数据库表里，因为报表这项功能要求的时效性不是很高，我们完全没必要每次查看报表数据，都去主库查询主表里的最新数据，这样也会严重拖垮主库主表，只需要每隔10分钟查询一次，保存到报表中更新即可。