说说数据库的三范式(面试题)
说说数据库的三范式（⾯试题）
第⼀范式（1NF）⽆重复的列（原⼦性）
第⼀范式（1NF）是指数据库表的每⼀列都是不可分割的基本数据项。所有的域都应该是原⼦性的，即数据库表的每⼀列都是不可分割的原⼦数据项，⽽不能是集合，数组，记录等⾮原⼦数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。
说明：在任何⼀个关系数据库中，第⼀范式（1NF）是对关系模式的基本要求，不满⾜第⼀范式（1NF）的数据库就不是关系数据库。
例如，如下的数据库表是符合第⼀范式的：
字段1字段2字段3字段4
⽽这样的数据库表是不符合第⼀范式的：
字段1字段2字段3字段4
字段3.1字段3.2
第⼆范式（2NF）属性完全依赖于主键
第⼆范式（2NF）就是⾮主属性完全依赖于主关键字。
举例⼦说明：
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库表不满⾜第⼆范式，因为存在如下决定关系：
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定⾮关键字的情况。
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同⼀门课程由n个学⽣选修，"学分"就重复n-1次；同⼀个学⽣选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有⾏的"学分"值都要更新，否则会出现同⼀门课程学分不同的情况。
(3) 插⼊异常：
假设要开设⼀门新的课程，暂时还没有⼈选修。这样，由于还没有"学号"关键字，课程名称和学分也⽆法记录⼊数据库。
(4) 删除异常：
假设⼀批学⽣已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插⼊异常。
符合第⼆范式的库表设计应该如下：把选课关系表SelectCourse改为如下三个表：
学⽣：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。
第三范式（3NF）属性不依赖于其它⾮主属性
在1NF基础上，任何⾮主属性不依赖于其它⾮主属性[在2NF基础上消除传递依赖]
第三范式（3NF）是第⼆范式（2NF）的⼀个⼦集，即满⾜第三范式（3NF）必须满⾜第⼆范式（2NF）。简⽽⾔之，第三范式（3NF）要求⼀个关系中不包含已在其它关系已包含的⾮主关键字信息。例如，存在⼀个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员⼯信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加⼊员⼯信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有⼤量的数据冗余。简⽽⾔之，第三范式就是属性不依赖于其它⾮主属性，也就是在满⾜2NF的基础上，任何⾮主属性不得传递依赖于主属性。
由⼀下例⼦说明：
学⽣表Student（学号，姓名，年龄，性别，系别，系办地址、系办电话），关键字为单⼀关键字"学号"，因为存在如下决定关系：
（学号）→ （姓名，年龄，性别，系别，系办地址、系办电话
但是还存在下⾯的决定关系
（学号） → (所在系办）→（系办地点，系办电话）
即存在⾮关键字段"系办地点"、"系办电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插⼊异常和删除异常的情况。
根据第三范式把学⽣关系表分为如下两个表就可以满⾜第三范式了：
什么是关系数据库学⽣：（学号，姓名，年龄，性别，系别）；
系别：（系别，系办地址、系办电话）。
上⾯的数据库表就是符合1NF,2NF,3NF范式的，消除了数据冗余、更新异常、插⼊异常和删除异常。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。