根据关系数据库规范范理论，关系数据库中的关系要满足第一范式。
例如一个表: dept
部门号 部门名 部门经理 部门成员
0001 销售部 zhangsan 李四,王五,赵六
在部门关系中，因哪个属性而使它不满足第一范式？（）
1、第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。
2、第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。
3、第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
发表于 2016-03-19 15:58:37
回复(4)
1.先要知道几个概念：
码：一个表中，可以唯一决定一个元组的属性“集合”。而主键则是可以唯一决定元组的‘某个属
性’。
例如：在成绩表中（学号，课程号）合起来叫一个码，而分开看学号是主键，课程号也是主键。
非主属性：不属于码的属性。
主属性：属于码的属性。
候选键：指每个都不一样的、非空的那几个属性，有着潜在的主键意义。
比如一个表中的课程号学号，系别号等等。。
2.通俗的讲范式：
1）第一范式：属性不可拆分。
如：地址这个属性是可拆分成城市地区等等，不可以把地址作为一个属性
解决方案：属性拆分开来，将一个地址属性改成多个属性，按照城市地区..设置多个属性。
2）第二范式：每个表中的非主属性完全依赖于码。
特殊情况：若码只有一个属性，则必满足第二范式。
如：（学号，课程号）这个表中的码被“学生名字”部分函数依赖。即包含有学号→学生名字这种依
赖关系。不符合2NF
解决方案：将部分函数依赖的部分码和依赖这些码的属性拿出来单独成表，在原表中用外键代替以前
的多个属性。
个人理解：将部分单独拿出来，用一个外键在原表中代替，可以大大减少原表中的属性条数。
3）第三范式：消除非主属性之间的依赖关系，只保留非主属性与码的依赖关系。
（消除传递函数依赖的另一说法，本质是一样的）
如：学号，课程号，系别，系主任。系别和系主任是非主属性，学号和课程号是主属性。但是系别和
系主任这两个非主属性之间有函数依赖关系：系别→系主任。必造成传函依赖：学号→系别→系主任。不
符合3NF
解决方案：将这个非主属性与其依赖的码都拿出来单独建表，并设置被依赖的属性为主键，在原表中
则用外键表示。
个人理解：将相互内在关联的非主属性用一个外键在原表中表示，可以大大减少数据冗余。
4）BC范式：每个表中只有一个候选键。
如：学号，学生名字，学生QQ。我们设置学号作主键，但是学生QQ、学号这两个都是候选键，一张
表中有多个候选键，不符合BC范式。
解决方案：保留一个候选键作为主键，拿出其他的候选键单独成表，将原表中的主键放入该表中。在
原表中不显示这个拿出来的候选键，从而 保证每个表中只有1个候选键。
个人理解：主键越少越好。一个表中的候选键越少越好。
但是这个BC范式有些苛刻了，很多情况比如成绩单表(学生 课程 成绩) ，学生、课程为候选键，我们这
样直接建表也是可以的。
设计到第三范式就行了！BC范式太苛刻了，大多数情况用不到。
发表于 2018-03-05 18:31:50
回复(0)
第一范式:原子性(各属性不可分)
eg:
学生编号 姓名 性别 联系方式
20080901 张三 男 email:zs@126.com,phone:88886666
20080902 李四 女 email:ls@126.com,phone:66668888
第一范式后:
学生编号 姓名 性别 email
phone
20080901 张三 男 email:zs@126.com: 88886666
20080902 李四 女 email:ls@126.com;
66668888
第二范式:非主键对主键的完全依赖。所谓的完全依赖是指非主键概念不能部分与主键概念重合.如:主键为课程,非主键中有教材,那么就违背
第二范式,因为课程决定教材.所以对于教材要重新建表,然后采用一对多联系起来.
发表于 2017-02-04 17:52:22
回复(0)
第一范式（1NF）：第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值。
如果出现重复的属性（如公司表中的员工信息），就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
第二范式（2NF）：第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性列被称为主关键字或主键、主码。
第三范式（3NF）：满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
发表于 2016-11-16 20:10:33
回复(0)
问题信息
-
扫描二维码，关注牛客网
- 意见反馈
-
下载牛客APP，随时随地刷题
扫一扫，把题目装进口袋
- 求职之前，先上牛客
-
扫描二维码，进入QQ群
扫描二维码，关注牛客公众号
- 公司地址：北京市朝阳区北苑路北美国际商务中心K1座一层-北京牛客科技有限公司
- 联系方式：010-60728802 投诉举报电话：010-57596212（朝阳人力社保局）
- 牛客科技© All rights reserved admin@nowcoder.com
- 京ICP备14055008号-4 增值电信业务经营许可证 营业执照 人力资源服务许可证
-
京公网安备
11010502036488号
定义：如果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模式。
简单的说，每一个属性都是原子项，不可分割。
1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。
例如(学生信息表)：
学生编号 姓名 性别 联系方式
20080901 张三 男 email:zs@126.com,phone:88886666
20080902 李四 女 email:ls@126.com,phone:66668888
以上的表就不符合，第一范式：联系方式字段可以再分，所以变更为正确的是：
学生编号 姓名 性别 电子邮件 电话
20080901 张三 男 zs@126.com 88886666
20080902 李四 女 ls@126.com 66668888
第二范式（2NF）
定义：如果关系模式R是1NF，且每个非主属性 完全函数依赖(往后看) 于候选键，那么就称R是第二范式。
简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。
例如(学生选课表):
学生 课程 教师 教师职称 教材 教室 上课时间
李四 Spring 张老师 java讲师 《Spring深入浅出》 ３０１ 08:00
张三 Struts 杨老师 java讲师 《Struts in Action》 ３０２ 13:30
这里通过（学生，课程）可以确定教师、教师职称，教材，教室和上课时间，所以可以把（学生，课程）作为主键。但是，教材并不完全依赖于（学生，课程），只拿出课程就可以确定教材，因为一个课程，一定指定了某个教材。这就叫不完全依赖，或者部分依赖。出现这种情况，就不满足第二范式。
修改后，选课表：
学生 课程 教师 教师职称 教室 上课时间
李四 Spring 张老师 java讲师 ３０１ 08:00
张三 Struts 杨老师 java讲师 ３０２ 13:30
课程表：
课程 教材
Spring 《Spring深入浅出》
Struts 《Struts in Action》
所以，第二范式可以说是消除部分依赖。第二范式可以减少插入异常，删除异常和修改异常。