爱华网设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
1范式简介 设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。
2各类范式
第一范式（1NF）
所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。
如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。
第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
1指导原则 第一范式包括下列指导原则：
数据组的每个属性只能包含一个值；
关系中的每个数组必须包含相同数量的值；
关系中的每个数组一定不能相同。
第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。
但是满足第一范式的关系模式并不一定是一个好的关系模式。
例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法：
一是重复存储职工号和姓名。这样，关键字只能是电话号码。
二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。
2第一范式的关系
规定关系
[1]第一范式规定关系的每一个分量必须是一个不可分的数据项。
非第一范式的例子如表5-5，可以转换为第一范式如表5-6。
表5-5
导师
专业
研究生
第一个研究生 第二个研究生
表5-6
导师
专业
第一个研究生 第二个研究生
几乎所有的商用关系DBMS都要求关系为第一范式，现在流行的关系数据库语言，如SQL，也都只支持第一范式。
如果关系仅仅满足第一范式的条件是不够的，可能会存在更新异常。为了消除这些异常，需要进行关系的规范化。
关系模式实例
下面是满足第一范式的(不好的)关系模式的例子。例如：设有一关系模式R(S#，C#，G，TN，D)，其中(S#)为学号，C#为课程号，G为成绩，TN为任课教师姓名，D为教师所在系名，这些数据具有下列语义：
(1) 学号是一个学生的标识，课程号是一门课程的标识。
(2) 一位学生所修的每门课程都有一个成绩。
(3) 每门课程只有一位任课教师，但一位教师可以教多门课。
(4) 教师中没有重名，每位教师只属于一个系。
下面是一个具体关系实例的数据，如表5-7：
表5-7
学号
S#
课程号
C#
成绩
G
教师
TN
系名
D
s1
c1
g1
t1
d1
s1
c2
g2
t2
d2
s2
c1
g3
t1
d1
s2
c2
g4
t2
d2
s3
c2
g5
t2
d2
s3
c3
g6
t2
d2
虽然上述的关系模式只有四个属性，但它是一个不好的关系模式，因为该模式在使用过程中有以下几个问题：
(1) 数据冗余。例如，教师所在系名对选该教师所开课的所有学生都重复输入一次。
(2) 插入异常。由于关系的主键{S#, C#} 不能为空值，如果一个教师不教课，则这位教师的姓名及所属的系名就不能插入表中。
(3) 删除异常。如果所有学生都退选某一门课，则有关该门课的其它数据(任课教师名及所在系名)也将被删除。
(4) 修改异常。如果改变一门课的任课教师，则需要修改表中选修该门课程的多行记录，如果部分修改，部分不修改，则会导致数据的不一致。
上述关系模式之所以是一个不好的关系模式，是因为模式中存在部分函数依赖和传递函数依赖。消除这些部分函数依赖和传递函数依赖，就可以得到一个比较好的关系模式。
根据上述示例说明的语义，找出有下面的函数依赖集合F：
F = { {S#, C#}→ G，C#→TN，TN → D}
图 5－2
针对函数依赖集合，运用关系数据库设计理论，可以对上述关系进行分解，得到3个关系模式如下：
SCG(S#, C#, G)
CTN(C#, TN)
TND(TN, D)
上述3个关系可以消除数据冗余，插入异常，删除异常和修改异常等现象。是一个比较好的关系模式。把原来一个关系表的数据分解为三个关系表存放。
具体的关系实例的数据如表5-8：
表5-8
S#
C#
G
s1
s1
s2
s2
s3
s3
c1
c2
c1
c2
c2
c3
g1
g2
g3
g4
g5
g6
对于上述示例，是满足第一范式的关系模式，但它不是一个好的关系模式，存在数据冗余和操作异常现象。通过分析模式属性间的函数依赖关系，把一个模式分解为三个关系模式后，消除了数据冗余和操作异常。对于任一给定的模式，如何判断是一个好的还是不好的关系模式呢？又如何把一个不好的关系模式分解转换为好的关系模式呢？这就是在下面要讨论的问题，对关系模式中X→Y的函数依赖关系，给出不同程度的限制，得到满足不同范式要求的模式。
每个非关键字列都独立于其他非关键字列，并依赖于关键字，第三范式指数据库中不能存在传递函数依赖关系。
1简介 关系模式R<U，F> 中若不存在这样的码X、属性组Y及非主属性Z（Z ? Y）, 使得X→Y，Y→Z，成立，Y→X不成立，则称R<U，F> ∈ 3NF。
若R∈3NF，则R的每一个非主属性既不部分函数依赖于候选码也不传递函数依赖于候选码。
如果R∈3NF，则R也是2NF。
采用投影分解法将一个2NF的关系分解为多个3NF的关系，可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。
将一个2NF关系分解为多个3NF的关系后，并不能完全消除关系模式中的各种异常情况和数据冗余。
2详细信息
例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性分别代表学号，姓名，所在系，系名称，系地址。
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
原因：关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在，DNO -> LOCATION, 因此关键字 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。
将第一，第二范式化为第三范式的步骤：
（1）求出R的最小函数依赖集Fmin
（2）找出不在Fmin中出现的属性，并将这些属性从R中去掉，构成一个关系模式
（3）若Fmin中有一个函数依赖涉及R的全部属性，则R不能分解
（4）否则，若Fmin中有X->A,则分解应包含{XA};若有X->A1,X->A2....X->An均属于Fmin，则分解应包含{XA1A2...An}
定义
令：
表一个关系；
表维持 所需的一组函数依赖；
表 属性的子集合；
表 的一个属性
如果对于 这种型式的函数依赖而言，下列叙述任一为真的话，则可以称 符合第三范式：
；也就是说 是明显函数依赖
是超键
是 的候选键的一部份
任何一个具有部份相依性或是转移相依性的关系都违反了第三范式。
示例
以下面这个定义机械组件的关系为例：
机械组件组件编号
(主键)制造商名称制造商地址
1000ToyotaPark Avenue
1001MitsubishiLincoln Street
1002ToyotaPark Avenue
本例中制造商地址很明显地不该被列在这个关系里面，因为和组件本身比起来，制造商地址应该和制造商比较有关系；正确的做法应该是把独立成为一个新的数据表：
制造商制造商名称
(主键)制造商地址
ToyotaPark Avenue
MitsubishiLincoln Street
然后把原本的数据表改成这样：
机械组件组件编号
(主键)制造商名称
1000Toyota
1001Mitsubishi
1002Toyota
先前那个数据表的问题在于每提到一次制造商名称就要多存一次它的地址，而这就不符合第三范式的原则。
下面提供了另一个例子：
订单 (Order)订单编号 (Order Number)
(主键)客户名称 (Customer Name)单价 (Unit Price)数量 (Quantity)小计 (Total)
1000David$35.003$105.00
1001Jim$25.002$50.00
1002Bob$25.003$75.00
在本例中，非主键字段完全依赖于主键订单编号,也就是说唯一的订单编号能导出唯一非主键字段值，符合第二范式。第三范式要求非主键字段之间不能有依赖关系，显然本例中小计依赖于非主键字段单价和数量，不符合第三范式。小计不应该放在这个数据表里面，只要把单价乘上数量就可以得到小计了；如果想要符合第三范式的话，就把小计拿掉吧 (不过在做查询的时候，本来用 "SELECT Order.Total FROM Order" 就要改成用 "SELECT UnitPrice * Quantity FROM Order" 了)。
订单 (Order)订单编号 (Order Number)
(主键)客户名称 (Customer Name)单价 (Unit Price)数量 (Quantity)
1000David$35.003
1001Jim$25.002
1002Bob$25.003
