1 第一范式(1NF)无重复的列
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。
1.2 第二范式(2NF)属性完全依赖于主键[消除部分子函数依赖]
第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。例如员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是惟一的,因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之,第二范式就是属性完全依赖于主键。
1.3 第三范式(3NF)属性不依赖于其它非主属性[消除传递依赖]
满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范式就是属性不依赖于其它非主属性。
II、范式应用实例剖析
下面以一个学校的学生系统为例分析说明,这几个范式的应用。首先第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话等信息。为了简单我们暂时只考虑这些字段信息。我们对于这些信息,说关心的问题有如下几个方面。
学生有那些基本信息
学生选了那些课,成绩是什么
每个课的学分是多少
学生属于那个系,系的基本信息是什么。
2.1 第二范式(2NF)实例分析
首先我们考虑,把所有这些信息放到一个表中(学号,学生姓名、年龄、性别、课程、课程学分、系别、学科成绩,系办地址、系办电话)下面存在如下的依赖关系。
(学号)→ (姓名, 年龄,性别,系别,系办地址、系办电话)
(课程名称) → (学分)
(学号,课程)→ (学科成绩)
2.1.1 问题分析
因此不满足第二范式的要求,会产生如下问题
数据冗余: 同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。
更新异常:
1)若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。
2)假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。
删除异常 : 假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。
2.1.2 解决方案
把选课关系表SelectCourse改为如下三个表:
学生:Student(学号,姓名, 年龄,性别,系别,系办地址、系办电话);
课程:Course(课程名称, 学分);
选课关系:SelectCourse(学号, 课程名称, 成绩)。
2.2 第三范式(3NF)实例分析
接着看上面的学生表Student(学号,姓名, 年龄,性别,系别,系办地址、系办电话),关键字为单一关键字"学号",因为存在如下决定关系:
(学号)→ (姓名, 年龄,性别,系别,系办地址、系办电话)
但是还存在下面的决定关系
(学号) → (所在学院)→(学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况。 (数据的更新,删除异常这里就不分析了,可以参照2.1.1进行分析)
根据第三范式把学生关系表分为如下两个表就可以满足第三范式了:
学生:(学号, 姓名, 年龄, 性别,系别);
系别:(系别, 系办地址、系办电话)。
总结
上面的数据库表就是符合I,II,III范式的,消除了数据冗余、更新异常、插入异常和删除异常。
分享到:
相关推荐
数据库设计的第一范式第二范式第三范式描述和实例 数据库设计的范式是指数据库设计时需要遵循的一些基本规则,以确保数据库的结构清晰、简洁、高效。常见的数据库设计范式包括第一范式(1NF)、第二范式(2NF)、第...
目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多...
数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,...第三范式:在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。
其中包括第一范式(1NF)、第二范式(2NF)和第三范式(3NF)等。 第一范式(1NF) 第一范式是最基本的数据库设计规范,它要求每个表中的每一行都具有唯一的值,且每个字段都不可分割。换言之,每个表中的每一行都...
三个范式是数据库规范化的基本概念,它们分别是第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。 第一范式(1NF) 第一范式是对属性的原子性约束,要求属性具有原子性,不可再分解。换言之,每个记录中的每个...
例如,在一个学生关系表中,如果存在“学院”决定“学院地点”和“学院电话”,那么这个数据库表就不满足第三范式。因为存在传递函数依赖关系,即“学院”决定“学院地点”和“学院电话”。 四、BCNF BCNF 的定义...
第三范式是在第二范式的基础上,确保所有的非主键列不仅直接依赖于主键,而且不依赖于其他非主键列。换句话说,表中的每列都应该直接依赖于主键,或者不依赖于任何其他列。这有助于消除不必要的冗余数据,并提高数据...
数据库范式通常有三种:第一范式、第二范式和第三范式。下面将对每种范式进行详细的介绍。 第一范式 第一范式是最基本的范式,它要求关系模式 R 中所有属性的值域都是单纯域。也就是说,每个列都只能包含单个值,不...
在众多的规范化理论中,第三范式(3NF)是数据库设计中的一个重要概念,它有助于消除数据冗余,提高数据一致性,降低更新异常,从而优化数据库性能。本文将深入探讨第三范式,并通过具体的案例分析来帮助理解其应用...
目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多...
数据库设计是信息系统构建的核心环节,其中的三大范式——第一范式、第二范式和第三范式,是确保数据规范化和避免数据冗余的关键原则。这些范式是根据关系数据库理论建立的,目的是提高数据库的逻辑独立性和减少数据...
尤其是数据库设计范式 现简单介绍1NF(第一范式),2NF(第二范式),3NF(第三范式)和BCNF,另有第四范式和第五范式留到以后再介绍。 在你设计数据库之时,若能符合这几个范式,你就是数据库设计的高手
总结来说,数据库设计三范式中的第一范式和第二范式是构建高效、稳定数据库结构的基础。它们帮助我们避免数据冗余,减少更新异常,提高数据一致性,并使得数据库设计更加规范。在实际的数据库设计过程中,理解和应用...
##### 第三范式(3NF): 消除非主属性的传递依赖 - **前提条件**:符合2NF。 - **定义**:在符合2NF的基础上,要求非主属性既不部分依赖于码,也不传递依赖于码。 - **示例**:如果一个课程的教材由教师决定,而教师...
目前关系数据库有六种设计范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)、第五范式(5NF)和第六范式(6NF)。每种范式都有其特点和应用场景,关系数据库的设计需要根据实际情况选择...
3. 应用第一范式、第二范式和第三范式来消除数据冗余和异常。 4. 应用鲍依斯-科得范式来消除传递函数依赖。 5. 优化数据库的性能和安全性。 数据库设计三大范式是数据库设计的基本原则,为我们提供了一个基本的框架...
3. **第三范式(3NF)**:在满足第二范式的基础上,进一步要求所有非主键字段之间相互独立,不存在传递依赖。换句话说,就是消除非主属性对码的传递函数依赖。例如,如果在表中有字段A依赖于字段B,字段B依赖于主键C,...