MySQL数据库范式
1、范式的优缺点
- 应用数据库范式的好处:
- 减少数据冗余(这是最主要的好处,其他好处都是由此而附带的)
- 消除异常(插入异常,更新异常,删除异常)
- 让数据组织的更加和谐
- 范式设计的缺点:
- 范式越高,意味着表越多,多表联合查询的机率就越大,SQL的效率就变低
- 表越多时,在做更新、删除、插入数据时需要维护的表越多,同样会降低数据库的效率
- 因此:
并不是应用的范式越高越好,视实际情况而定。第三范式已经很大程度上减少了数据冗余,并且基本预防了数据插入异常,更新异常,和删除异常了。
2、第一范式
- 第一范式: 每一列保持原子特性
列都是基本数据项,不能够再进行分割,否则设计成一对多的实体关系
注:不符合第一范式不能称作关系型数据库
- 例如:表中的地址字段,可以再细分为省,市,区等不可再分割(即原子特性)的字段
3、第二范式
- 第二范式:属性完全依赖于主键-主要针对联合主键
非主属性完全依赖于主关键字,如果不是完全依赖主键(即不全依赖联合主键中的所有关键字),应该拆分成新的实体,设计成一对多的实体关系
- 例如:选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分),(学号,课程名称)是联合主键,但是学分字段只和课程名称有关,和学号无关,相当于只依赖联合主键的其中一个字段,不符合第二范式。
4、第三范式
- 第三范式:属性不依赖于其它非主属性
要求一个数据库表中不包含已在其它表中已包含的非主关键字信息
注:一般关系型数据库满足第三范式就可以了
- 示例:学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话),学号是主键,但是学院电话只依赖于所在学院,并不依赖于主键学号,因此该设计不符合第三范式,应该把学院专门设计成一张表,学生表和学院表,两个是一对多的关系。
5、BC范式
- BC范式:每个表中只有一个候选键
BC范式是在第三范式的基础上的一种特殊情况,即每个表中只有一个候选键(在一个数据库中每行的值都不相同,则可称为候选键)
- 示例:每一个员工的email都是唯一的(不可能两个人用同一个email),则此表不符合BC范式,对其进行BC范式化后的关系图为
- 注意:
在要求更好的查询效率时,可以不遵循BC范式(多一个候选键,就多一份表,更多可能需要进行联合查询),候选键储存在主表上也是没有问题的,并不会造成数据的冗余,在一定程度上提高查询效率
6、第四范式
- 第四范式:消除表中的多值依赖(减少维护数据一致性的工作)
比如:noNF表中的skill技能这个字段,有的人是“java,mysql”,有的人描述的是“Java,MySQL”,这样数据就不一致了,解决办法就是将多值属性放入一个新表
样数据就不一致了,解决办法就是将多值属性放入一个新表