数据库设计中的三大范式

关系（二维表）的设计规范，范式

范式：Normal format是指对表结构的要求
目的：1.规范结构  2.减少数据冗余

第一范式 1NF

要求每个字段具有原子性，  
原子性是指每个字段不能在分了，
什么叫不能再分了呢？
比如说

比赛id	比赛名称	教练	参与人员	开始时间结束时间
1	游泳	Helios	小明	一点~三点
2	跳水	Helios	小红	两点~五点
3	蛙跳	Helios	小张	一点~八点

像上面的开始时间和结束时间就是没有原子性，因为如果查表的时候还是可以只是查结束时间和开始时间，这样的话就不能使数据库方便了；
把上面的表换位原子性表为：

比赛id	比赛名称	教练	参与人员	开始时间	结束时间
1	游泳	Helios	小明	一点	三点
2	跳水	Helios	小红	两点	五点
3	蛙跳	Helios	小张	一点	八点

像上面表那样就是具有原子性，因为其中的每个字段已经不能再分了，这样把时间多部分进行存储不仅更加方便还提高了数据库的性能；

第二范式2NF

要求每个字段对主键不能部分依赖，
什么是部分依赖：针对于联合主键来说的，如果对于单一的主键来说是不会出现部分依赖的，因为那是完全的依赖主键（应该叫完全依赖），也就是说一个数据表中只能保存一种数据，不能把多个数据保存到一个数据表中；

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

 订单信息表



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

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



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

第三范式 3NF

第三范式要求每个字段个主键是直接相关，不能是间接相关（不能出现传递性）
传递性是什么：要求每个只能和主键相关联，不能字段依靠字段，然后和主键相关

id	姓名	性别	比赛项目	举办方
1	小红	女	游泳	Helios
2	小钟	男	跳远	Helios
3	小张	男	蛙跳	Helios

像上面的表所示：当姓名确定了，性别就一定确定了，性别是依靠姓名的；当比赛项目确定了，举办方就确定了，举办方是依靠比赛项目的；
这样就会出现了传递依赖   性别-->姓名-->id    举办方-->比赛项目-->id
在这种情况下，就能多建几张表，将独立的实体信息用独立的关系（二维表）来表示

姓名id	姓名	性别
11	小红	女
21	小钟	男
31	小张	男

项目id	比赛项目	举办方
12	游泳	Helios
22	跳远	Helios
32	蛙跳	Helios

id	姓名id		项目id
1	11		12
2	21		22
3	31		32

这样就可以把 上面的那一个大表，划分为三个这样的字表，并且都与相应的主键直接相关
总的来说就是每个实体建立一个表，每个表有一个自己的主键；