函数依赖
在数据库中，关系模式中的属性值之间会发生联系。譬如每个学生只有一个姓名，每门课程只能有一个任课老师。这类联系就称为函数依赖（functional dependency，简记为FD）。 X→Y，读作X函数决定Y，即知道了X的值就可以确定Y的值了，比如说：你知道了一个学生的学号，那么就可以确定他的姓名了。
定义：在关系模式R(U)中，X和Y是属性集U的子集，所有的元组都满足X→ Y，那么X→ Y在关系模式R(U)中成立，这种联系就是函数依赖。
一些关键词
传递依赖：在R(U)中，如果X→Y，Y⊈X，Y→Z，则称Z对X传递依赖。
候选码：设K为R(U)中属性的组合，若K→ U，即关系模式R中所有的属性都函数依赖于K，且对于K的任何一个真子集K’都有K'不能决定U，则K为R的候选码。它通常也称为候选关键字。若有多个候选码，则选一个作为主码。
主属性和非主属性：包含在任何一个候选码中的属性称为主属性，否则称为非主属性。
完全函数依赖：在R(U)中，如果X→ Y，且对于X的任何一个真子集X’都有X’不能决定Y，称Y对X完全函数依赖。
部分函数依赖：如果X→ Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，也成为局部函数依赖。
关系模式规范化
关系数据库设计的方法之一就是设计满足适当范式的模式，通常可以通过判断分解后的模式达到几范式来评价模式规范化的程度。范式有1NF、2NF、3NF、BCNF、4NF、5NF，其中1NF的级别最低，如果一个关系模式是高的范式，那么它一定满足低范式的条件。如：R(U)是3范式，那么它一定是2NF，1NF。规范化就是将低一些的范式转化为高一些的范式的过程。
第一范式（First Normal Form）
若关系模式R的每一个分量是不可再分的数据项，则关系模式R属于第一范式。
例如：R（字段1，字段2，字段3），此关系模式就符合第一范式。
R（字段1，字段2，字段3，字段3.1）这就不符合第一范式。
我们一般很少有不符合第一范式的数据库，因为DBMS不允许你把数据库表中的列再一分为二或多列的。第一范式容易造成冗余度大，修改操作易引起不一致性，插入异常，删除异常等问题，所以引入了2NF。
第二范式（Second Normal Form）
若关系模式R∈1NF，且每个非主属性完全依赖于候选码，则关系模式R∈2NF。也就是说，当1NF消除了非主属性对候选码的部分函数依赖，则成为2NF。
第三范式（Third Normal Form）
若关系模式R(U)中若不存在这样的候选码X，属性组Y及非主属性Z（Z⊈Y）使得X→ Y（反过来不行），Y→ Z成立，则关系模式R∈3NF。即当2NF消除了非主属性对候选码的传递函数依赖，则称为3NF。
可以证明，3NF模式必是2NF模式。产生冗余和异常的两个重要原因是部分依赖和传递依赖。因为3NF模式中不存在非主属性对候选码的部分函数依赖和传递依赖，所以具有较好的性能。对于1NF，2NF，其性能弱，一般不宜作为数据库模式，通常要将它们变换成为3NF或更高级别的范式，这个变换过程称为“关系模式的规范化处理”。
BCNF
在第三范式的基础上，数据库表中的每个属性都不传递依赖于R的候选键，那么称R是BCNF的模式。即在第三范式的基础上排除主属性对候选键的传递依赖。
案例分析
设有关系模式R(E,N,M,L,Q)，其函数依赖集为F={E→ N,EM→ Q,M→ L}。则关系模式R达到了1NF；该关系模式需要进行分解，因为存在冗余，修改操作的不一致性、插入和删除异常。
解析：依题意，关系模式R中的属性EM可决定该关系的所有属性，因此EM是关系模式R的主键。又因为EM→ Q，而E→ N、M→ L，可知非主属性N，L都部分依赖于候选码，所以R仅达到了第一范式。而1NF存在冗余度大、修改操作的不一致性、插入和删除异常4个问题，因此需要对R进行分解。“分解”是解决冗余的主要办法，也是规范化的一条原则：“关系模式有冗余问题，就分解它”。