数据库三个范式的理解.docxVIP

设计关系型数据库时，遵从不同的规范要求，设计出合理的关系型数据库。这些规范被称作范式。越高的范式数据库的冗余度就越低。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）满足第二范式一定满足第一范式，满足第三范式一定满足第二范式，依次类推。。。关系型数据库的最低要求是满足第一范式。一般来讲，数据库满足到第三范式就行了。第一范式（1NF）无重复的列数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。如果实体中的某个属性有多个值时，必须拆分为不同的属性在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。第二范式（2NF）属性完全依赖于主键第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。当存在多个主键的时候，才会发生不符合第二范式的情况。比如现在有两个主键，不能存在这样的属性，它只依赖于其中一个主键，这就是不符合第二范式。如果存在不符合第二范式的情况，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。第三范式（3NF）属性不能传递依赖于主属性（属性不依赖于其它非主键属性）第二范式（3NF）是在第一范式（2NF）的基础上建立起来的，即满足第二范式（3NF）必须先满足第一范式（2NF）。如果某一属性依赖于其他非主键属性，而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。下面以一个学校的学生系统为例分析说明这几个范式的应用。首先我们确定一下要设计的内容包括那些。学号、姓名、年龄、性别、电话、系别、系办地址、系办电话、课程、学分、成绩，等信息。第一范式举例在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。虽然第一范式一定是满足的，但是为了加强理解，还是举例说明一下如果在某个学生的“电话”属性中填入了“1585858588 025，那么就违反了第一范式。学生电话属性违反了原子性，它还可以再分，分成手机和座机两个属性。第二范式举例我们把（学号、姓名、年龄、性别、电话、系别、系办地址、系办电话、课程、学分、成绩）这些信息放到一个表中，其中“学生学号”和“课程”两个属性是主键。这样不符合第二范式。出现了属性依赖于部分主键的情况（比如”姓名“只依赖于”学号“，和“课程”属性无关）那么违反了第二范式有什么问题呢？下面来分析一下：数据冗余：同一门课程由n个学生选修，学分就重复n-1次；同一个学生选修了m门课程，“姓名”和“年龄”就重复了m-1次。更新异常：1）若调整了某门课程的学分，数据表中所有行的学分值都要更新，否则会出现同一门课程学分不同的情况。2）假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有学号关键字，课程名称和学分也无法记录入数据库。删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。解决方案：分成三个表：学生：Student（学号，姓名，年龄，性别，电话，系别，系办地址、系办电话）课程：Course（课程，学分）选课关系：SelectCourse（学号，课程，成绩）第三范式举例继续看上面改善过了的关系结构。由于Student表只有一个主键“学号”，所以存在如下决定关系：（学号）→ （姓名，年龄，性别，电话，系别，系办地址、系办电话）但是还存在下面的决定关系：（学号） → (系别）→（系办地点，系办电话）即存在非关键字段系办地点、系办电话对关键字段学号的传递依赖。它也会存在数据冗余、更新异常、插入异常和删除异常的情况（这里不作分析，可以参照第二范式的分析）解决方案：继续把学生表分成两个表：学生：（学号，姓名，年龄，性别，电话，系别）　　系别：（系别，系办地址，系办电话）