所谓范式，是关系型数据库关系模式规范化的标准，从规范化的宽松到严格，分别
为不同的范式，通常使用的有第一范式、第二范式、第三范式及BC范式等。范式是建立
在函数依赖基础上的。
函数依赖
定义：设有关系模式R(U)，X和Y是属性集U的子集，函数依赖是形为X→Y的一个命题，
对任意R中两个元组t和s，都有t[X]=s[X]蕴涵t[Y]=s[Y]，那么FD X→Y在关系模式R(U)中成
立。X→Y读作‘X函数决定Y’，或‘Y函数依赖于X’。
通俗的讲，如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确
定的，就称为Y函数依赖于X。
函数依赖应该是通过理解数据项和企业的规则来决定的，根据表的内容得出的函数
依赖可能是不正确的。
第一范式（1NF）
定义：果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模
式。
简单的说，每一个属性都是原子项，不可分割。
1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称
为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。
第二范式（2NF）
定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么就称R是第
二范式。
简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完
全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的
，而不能由主键的一部分来决定。
举个例子：
有股票日行情表的主键是股票代码和交易日期组成。非主属性中有收盘价和成交量
等，都是由主键，即股票代码和交易日期函数决定的，单独的股票代码或者交易日期都
不能函数决定这些非主属性。如果这个表中有非主属性股票简称，则股票简称是可以由
股票代码来函数决定的，这样股票简称这个非主属性就不是完全函数依赖于候选键，这
样的设计就不满足第二范式。
第三范式（3NF）
定义：如果关系模式R是2NF，且关系模式R（U，F）中的所有非主属性对任何候选关键
字都不存在传递依赖，则称关系R是属于第三范式。
简单的说，第三范式要满足以下的条件：首先要满足第二范式，其次非主属性之间不存
在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属
性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。
举个例子：
在股票基本情况表中，主键是股票代码，有非主属性所属一级行业和所属二级行业。根
据业务规则，所属二级行业能够函数决定所属一级行业，这就表示存在这样一种关系：
股票代码函数决定所属二级行业，所属二级行业函数决定所属一级行业，这就形成了传
递依赖，这样的设计就不符合第三范式。
不过在实际运用中，为查询和使用的方便，有时也会违反第三范式。如上例，如果没有
所属一级行业的属性，需要查询所属一级行业的相关股票，需要查询时使用函数来从二
级行业中函数生成所属一级行业，使用性能上会受影响。所以通常会加上所属一级行业
的属性。
BC范式（BCNF）
BC范式是第三范式的增强版，不过也有人说是直接从1NF发展过来的，即每个属性，包
括主属性或非主属性，都完全依赖于候选键，并且不存在传递依赖情况。
