一、基本概念

函数依赖：

通俗描述：

描述一个学生的关系，可以有学号(SNO),姓名(SNAME),系名(SDEPT)等几个属性。由于一个学号只对应一个学生，一个学生只在一个系学习。因此当学号确定之后，姓名和该学生所在系的值也就唯一被确定了，就像自变量x确定之后，相应的函数值f(x)也就唯一地被确定了一样，称SNO函数决定SNAME和SDEPT，或者说SNAME，SDEPT函数依赖于SNO，记为：SNO -> SNAME， SNO -> SDEPT.

严格定义：

设R(U)是属性集U上的关系模式。X，Y是U的子集。若对于R(U)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不相等，则称X函数确定Y或者Y函数依赖于X。记为X->Y。

（如果不知道“关系”、“属性集”等定义，自己看大学教材去。这里的定义摘自萨师煊&王珊《数据库系统概论》第三版）

完全函数依赖：

在R(U)中，如果Y函数依赖于X,并且对于X的任何一个真子集X'，都有Y不函数依赖于X'， 则称Y对X完全函数依赖。否则称Y对X部分函数依赖。

举个例子就明白了。假设一个学生有几个属性

SNO 学号

SNAME 姓名

SDEPT 系

SAGE 年龄

CNO 班级号

G 成绩

对于(SNO,SNAME,SDEPT,SAGE,CNO,G)来说，G完全依赖于(SNO, CNO), 因为(SNO,CNO)可以决定G，而SNO和CNO都不能单独决定G。

而SAGE部分函数依赖于(SNO,CNO),因为(SNO,CNO)可以决定SAGE，而单独的SNO也可以决定SAGE。

传递函数依赖：

在R(U)中，如果X->Y, Y->Z, 则称Z对X传递函数依赖。

候选键

(又称候选码，候选关键字,码 ，candidate key)：

设K是一个R(U)中的属性或属性集合(注意可以是属性集合，也即多个属性的组合)，若K完全函数确定U，则K为R的候选键(Candidate key);

通俗地说就是，能够确定全部属性的某个属性或某组属性，称为候选键。若候选键多于一个，则选定其中一个作为主键。

主属性：

包含在任何一个候选键中的属性，叫做主属性(Prime attribute),不包含在任何候选键中的属性称为非主属性或非键属性或非关键字段。

例子：

在(SNO, CNO, G)中，SNO和CNO这俩合起来就是一个候选键，因为每个元组只要确定了SNO和CNO，则其它所有属性都可以根据SNO和CNO来确定。而SNO和CNO就都是“主属性”，G是“非主属性”。由于此例中只有一个候选键，于是只能选择(SNO, CNO)作为主键。

在(SNO,SDEPT, SNAME)中，SNO是一个候选键，因为只要SNO确定了，其它所有属性也都确定了，如果保证没有重名的话，则SNAME也是一个候选键，于是可以选SNO或者SNAME之一作为候选键。如果不能保证没有重名，就不能把SNAME当成候选键，于是就只有SNO能够做主键。

二、三大范式介绍

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。

在实际开发中最为常见的设计范式有三个：

1．第一范式(确保每列保持原子性)

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。

上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。

2．第二范式(确保表中的每列都和主键相关)

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

数据库表中不存在非关键字段对任一候选键的部分函数依赖，也即所有非关键字 段都完全依赖于任意一组候选关键字。

2NF的违例只会出现在候选键由超过一个字段构成的表中，因为对单关键字字段不存在部分依赖问题。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。

 订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。

3．第三范式(确保每列都和主键列直接相关,而不是间接相关)

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式

比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。