近期，在数据库表结构的设计时遇到点困惑。于是决定回忆一下数据库设计的几大范式。
首先，来搞清楚一个问题，什么是范式NF？NF是 normalize form的缩写。从广义上来说，NF是符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度。从狭义上来说，NF是一张数据表的表结构所符合的某种设计标准的级别。
NF=标准形式=合理化性级别=标准化级别。
其次，再来搞清楚，为什么要有NF。在关系型数据库的设计中，灵活地利用NF可以使数据库的增、删、查、改不会引起误操作或者带来明显的数据冗余，从而提高设计的合理性。
那么，这里主要回忆一下1NF,2NF,3NF,BCNF,4NF。
其中BCNF与4NF是对多值依赖与平凡依赖的定义，在非平凡依赖中，最高就是3NF了。
首先，我们来看一些概念：
1.数据依赖
数据依赖指的是通过一个关系中属性间的相等与否体现出来的数据间的相互关系，其中最重要的是函数依赖和多值依赖。
2.函数依赖
设X,Y是关系R的两个属性集合，当任何时刻R中的任意两个元组中的X属性值相同时，则它们的Y属性值也相同，则称X函数决定Y，或Y函数依赖于X。
3.平凡函数依赖
当关系中属性集合Y是属性集合X的子集时(Y?X)，存在函数依赖X→Y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。
4.非平凡函数依赖
当关系中属性集合Y不是属性集合X的子集时，存在函数依赖X→Y，则称这种函数依赖为非平凡函数依赖。
5.完全函数依赖
设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
6.部分函数依赖
设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
7.传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
8.码
设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码，简称为码。在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）
接下来正式祭出各大范式的定义
第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
1.单值和不重复！
（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之，第一范式就是无重复的列。
2.唯一区分，属性完全依赖于主关键字！
这个唯一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。
3.属性不依赖于其他非主属性
第三范式（3NF）要求一个数据库表中不包含已在其它表中包含的非主关键字信息。例如，在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
4.BCNF范式
在3NF的基础上，主属性没有对于码的部分与传递函数依赖。判断方法：箭头左边的必须是候选码，不是候选码的就不是BC范式。简而言之，即主属性之间不可以有依赖关系！
5.4NF
4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。因为根据定义，对于每一个非平凡的多值依赖X→→Y，X都含有候选码。简而言之，就是没有多值依赖。
实际的应用当中，还要灵活应用，根据实际需求，既不要拘于规范过度设计，又不要能毫无章法造成操作错误或者大量的数据冗余。