数据库工程师下午试题4 ：关系范式

第一范式（1NF）：要具有原子性，不可分割

　　所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

第二范式（2NF）：每个非主属性都完全依赖于候选键

　　在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖。

　　第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。

　　第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键<字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。

　　简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

第三范式（3NF）：每个非主属性都不传递依赖于候选键

　　在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
　　第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。

BCNF范式：每个属性都不传递依赖于候选键

　　消除了非主属性对码的传递依赖。

第四范式（4NF）

　　不允许有非平凡且非函数依赖的多值依赖

总结和实例描述

第一范式：字段的原子性：简单来说就是每一个字段不能分割出其他的属性

　　确保每列的原子性

　　如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元)，则满足第一范式.　

　　例如:顾客表(姓名、编号、地址、……)其中"地址"列还可以细分为国家、省、市、区等。

第二范式：保证主键的唯一性，属性完全依赖于主键

　　在第一范式的基础上更进一层,目标是确保表中的每列都和主键相关

　　如果一个关系满足第一范式,并且除了主键以外的其它列,都依赖于该主键,则满足第二范式.

　　例如:订单表(订单编号、产品编号、定购日期、价格、……)，"订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，应删除该列。

第三范式：消除传递依赖，保证每个属性都直接依赖于主键

　　在第二范式的基础上更进一层,目标是确保每列都和主键列直接相关,而不是间接相关

　　如果一个关系满足第二范式,并且除了主键以外的其它列都不依赖于主键列，则满足第三范式。

　　为了理解第三范式，需要根据Armstrong公里之一定义传递依赖。假设A、B和C是关系R的三个属性，如果A-〉B且B-〉C，则从这些函数依赖中，可以得出A-〉C， 如上所述，依赖A-〉C是传递依赖。

 

 

**码：**数据表中关系的某个属性或者某几个属性的组合，用于区分每个元组。

**候选码：**唯一标识一条记录的最小属性集。

**主码：**某个能够唯一标识一条记录的最小属性集（从候选码挑选的一条）。

**主属性：**候选码属性的并集。

**非主属性：**相对于主属性来说，不包含在候选码中的属性。

 

超键：在关系中能唯一标识元组的属性集称为关系模式的超键 
候选键：不含有多余属性的超键称为候选键 
主键：用户选作元组标识的候选键称为主键

 

 

举例： 
 
超键：用定义解释，如下属性集 {学号} {身份证号} {学号，姓名} {学号，身份证号}等等，只要可以确定一条唯一记录的集合即可

候选键：去掉超键多余的属性，{学号} {身份证号}等等，此时集合{学号，身份证号}便不是候选键，因为，其中任何一条记录便可以确定一条唯一的记录（唯一确认一条记录的，如果一个人有身份证，有毕业证，则毕业证是候选键，因为一个人可能有多个毕业证，而一个毕业证对应1个身份证）

主键：用户从候选键中人为定义一个作为这个关系表的候选键，如：{学号}，从候选键挑选一个即可

 

分解为BCNF范式的时候，需要清楚关系模式中有几类属性，不同类的属性分成不同的关系模式，然后加上外键 即可。

 不正确的范式会导致： 插入 删除 修改异常、