数据库范式
当前我们使用的主流数据库是关系型数据库，所以我是记录在关系型数据库中对范式的一些理解和看法。数据库库范式分为六种（其实还有有一个BCNF），分别为从第一范式到第六范式。高级一层是建立在所有低层的基础上的，如第2范式是建立在第一范式的基础上的，依次类推。下面分别举例讲解各种范式：
- 第一范式(1NF)
第一范式的核心描述为：数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值。该范式讲的是列的原子性。有两层意思：一层是说每一列只能存一个属性值（如果把2个属性值存在1列中）。第二层说的是在一张表中属性值不能重复。在现代关系行数据库中，都是默认满足第一范式的，所以你想要写出不满足第一范式的结构来还是不可能的事情，所以第一范式就不再多说。如果想深入，可以研究下其他非关系型的数据库的情况。
- 第二范式(2NF)
第二范式的核心描述为：行有唯一的主键，非主键仅对主键依赖。有2层意思，第一层，每一行都要有主键（单独信息或组合信息），这个容易理解。第二层意思是非主键对主键依赖，如果是复合主键的情况，非主键属性不能依赖于部分主键属性。如 【产品，仓库号，数量，仓库地址，仓库管理员】，这里（产品+仓库号）为复合主键，而仓库地址和仓库管理员依赖于仓库号，这就是上面描述的“主键属性不能依赖于部分主键属性”，因此这是违背第二范式的，符合范式的设计应该为：【产品，仓库号，数量】，【仓库号，仓库地址，仓库管理员】。
- 第三范式(3NF)
第三范式的核心描述为：非主键属性互不依赖。这个很容易理解，直接上例子：【学生编号，姓名，系编号，系办公地点，系办公电话】，这里学生编号是主键。然后这里的非主键属性系编号->系办公室+系办公电话，这里应该把该表拆成2个表，然后外键相连。符合范式的设计应该为：【学生编号，姓名，系编号】和【系编号，系办公地点，系办公电话】。
BC范式(BCNF), 是两个叫 Raymond F. Boyce 和 Edgar F. Codd 的总结出来的，取他们的姓拼成范式名。BC 范式是第三范式的加强版。
- 第四范式（4NF）
第四范式的核心描述为：不允许冗余的多对多关系。这个范式的核心思想也是节省数据库空间。举例来说，【员工，技能，语言】，一个员工能拥有多项技能和多种语言能力，而同一技能或语言可以有多个员工掌握。在这种情况下，依据第四范式，我们应该把表单设计成【员工，技能】+【员工，语言】。在存储时，我们能节省一些空间，但是在操作时，join 往往带来更多的系统开支。
- 第五范式（5NF）
第五范式指在可能的前提下继续打碎数据表。这个范式和第四范式的思想是相同的，希望消除冗余，在可能的情况下，继续打碎信息。例如上面的例子，一个三列的表，如果表的各列是两两之间多对多的关系，则按照第五范式的思想，应该建立三张表，每张表有之前表的两列信息。
- 第六范式（6NF）
第六范式已经挺极端了，按文献的说法，只有数据量大到数据仓储级别，才有使用的必要。貌似是仔细设计表单的依赖关系和 join 关系的，就不仔细研究下去了。
在做数据库设计的时候，满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。一般情况下满足第二和第三范式就OK（第一范式是默认满足的），这并意味着不符合范式要求的设计一定是错误的，这种较特殊的情况下，不符合范式要求反而是合理的。
另一篇:
官方定义：第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。
我的理解：第一范式这个不用說了，只要是关系数据库都满足第一范式
官方定义：第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖
我的理解：在第二范式中组合主键（AB）【注明：也叫做复合主键】里面的A或者B 与其他字段不能存在组合重复，为解决这个问题，通常的做法是咱们不用组合主键，添加一个ID，做为单一主键即可满足第二范式。如果不想添加ID，请满足组合主键（AB）里面的A或者B 与其他字段不能存在组合重复。
如:不满足第二范式,复合主键中的A与字段C组合重复
+------------+-----------+-------------------+
pk pk row
+------------+-----------+-------------------+
A B C
+------------+-----------+-------------------+
A D C
+------------+-----------+-------------------+
A E C
+------------+-----------+-------------------+
改为这样满足第二范式(但是不满足第三范式,字段A与字段C是组合重复):
+---------+------------+-----------+-------------------+
pk row row row
+---------+------------+-----------+-------------------+
1 A B C
+---------+------------+-----------+-------------------+
2 A D C
+---------+------------+-----------+-------------------+
3 A E C
+---------+------------+-----------+-------------------+
官方定义：第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三 范式。
我的理解：在第三范式中字段与字段之间不能存在组合重复
如:不满足第三范式,字段A与字段C组合重复
+---------+------------+-----------+-------------------+---------------+
pk row row row row
+---------+------------+-----------+-------------------+---------------+
1 A B C F
+---------+------------+-----------+-------------------+---------------+
2 A D C G
+---------+------------+-----------+-------------------+---------------+
3 A E C K
+---------+------------+-----------+-------------------+---------------+
改为这样满足第三范式:
表1
+---------+------------+-----------+
pk row row
+---------+------------+-----------+
1 A B
+---------+------------+-----------+
2 A D
+---------+------------+-----------+
3 A E
+---------+------------+-----------+
和表2
+---------+-------------------+------------+
pk row row
+---------+-------------------+------------+
1 C F
+---------+-------------------+------------+
2 C G
+---------+-------------------+------------+
3 C K
+---------+-------------------+------------+
原则:当出现字段与字段的组合重复,如上的A和C的组合重复,首先要考虑的就是把他们拆分为2个表,具体是C拆到表1, 还是A拆到表1,看情况而定，上面的拆分只是一个随便例子，你需要根据实际需要来拆分。
关键要理解定义这种范式标准的主要目的是为了减少数据冗余，数据冗余产生的本质就是在一个表中存在字段与字段之间的一对多，或者多对多关系。解决这个几对几的关系问题，就能轻易实现满足第三范式的数据库设计。
实例型篇：
第一范式
定义：如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的
那么符合第一模式的特点就有
1)有主关键字
2)主键不能为空，
3)主键不能重复,
4)字段不可以再分
例如：
StudyNo | Name | Sex | Contact
20040901 john Male Email:[email protected],phone:222456
20040901 mary famale email:[email protected] phone:123455
以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分
所以变更为正确的是
StudyNo | Name | Sex | Email | Phone
20040901 john Male [email protected] 222456
20040902 mary famale [email protected] 123455
第二范式：
定义：如果关系模式R是第一范式的，而且关系中每一个非主属性不部分依赖于主键，称R是第二范式的。
所以第二范式的主要任务就是
满足第一范式的前提下，消除部分函数依赖。
StudyNo | Name | Sex | Email | Phone | ClassNo | ClassAddress
01 john Male [email protected] 222456 200401 A楼2
02 mary famale [email protected] 123455 200402 A楼3
这个表完全满足于第一范式,
主键由StudyNo和ClassNo组成，这样才能定位到指定行
但是,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),
所以要变为两个表
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john Male [email protected] 222456 200401
02 mary famale [email protected] 123455 200402
表二
ClassNo | ClassAddress
200401 A楼2
200402 A楼3
第三范式：
满足第二范式的前提下，消除传递依赖。
例:
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male [email protected] 优秀 $1000
20040902 mary famale [email protected] 良 $600
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖
更改为：
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male [email protected] 1
20040902 mary famale [email protected] 2
bounsNo | bounsLevel | bouns
1 优秀 $1000
2 良 $600
这里我比较喜欢用bounsNo作为主键，
基于两个原因
1）不要用字符作为主键。可能有人说：如果我的等级一开始就用数值就代替呢？
2）但是如果等级名称更改了，不叫 1，2 ，3或优、良，这样就可以方便更改，所以我一般优先使用与业务无关的字段作为关键字。
一般满足前三个范式就可以避免数据冗余。
第四范式：
主要任务：满足第三范式的前提下，消除多值依赖
product | agent | factory
Car A1 F1
Bus A1 F2
Car A2 F2
在这里，Car的定位，必须由 agent 和 Factory才能得到（所以主键由agent和factory组成）,可以通过 product依赖了agent和factory两个属性
所以正确的是
表1 表2：
product | agent factory | product
Car A1 F1 Car
Bus A1 F2 Car
Car A2 F2 Bus
第五范式：
定义: 如果关系模式R中的每一个连接依赖, 都是由R的候选键所蕴含, 称R是第五范式的
看到定义，就知道是要消除连接依赖,并且必须保证数据完整
例子
A | B | C
a1 b1 c1
a2 b1 c2
a1 b2 c1
a2 b2 c2
如果要定位到特定行，必须三个属性都为关键字。
所以关系要变为 三个关系，分别是A 和B,B和C ，C和A
如下：
表1 表2 表3
A | B B | C C | A
a1 b1 b1 c1 c1 a1
a1 b2 b1 c2 c1 a2
范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦，但是操作难，因为需要联系多个表才能得到所需要数据，而且越高范式性能就会越差。要权衡是否使用更高范式是比较麻烦。
一般我在做项目中都，用得最多的也就是第三范式，我认为使用到第三范式也就足够了，性能好
而且方便管理数据