十一、关系型数据库的三大范式

                       关系型数据库的三大范式

      所谓关系型数据库的三大范式，就是关系型数据的三个判别标准，符合这三个标准我们说他就是关系型数据库。

一、第一范式（单一属性）

    只要是关系型数据库的表，都满足第一范式。
    第一范式：数据库表中所有字段都是单一属性，不可分割。比如整型，字符型，日期类型。
    Redis是非关系型数据库，因为他的一个字段值可以是一个Map，其中存在key、value。key可以是字符型，value可以是日期型。

二、第二范式（推荐单一主键、复合主键不存在外依赖）

    第二范式：数据库表中不存在非关系字段对任一候选关键字段的部分函数依赖。
    告诉我们，不能使用组合键，要使用唯一主键。比如：购物信息表，有顾客编号、产品名称、产品类型、产品详情等字段。当你使用顾客编号和产品名称做组合主键的时候会产生如下问题 ：

1. 数据冗余
   顾客编号、产品名称作为组合键，当一个产品有n个顾客购买的时候同一个产品的时候，就重复n-1次记录"产品名称"这个字段信息（在购买表中数据重复）。当一个旅客n次购买同一个产品的时候就是n-1次重复记录的产品类型（在购买表中数据重复）。

2. 更新异常
   如果这时候去调整一个产品类型，就需要去更新所有顾客够买的产品类型，否则出现同一个产品出现不同类型的情况

3. 插入异常
   当新进一个产品的时候，还没有人购买，就无法插入表中。

第二范式，要求我们使用唯一主键。

三、第三范式(字段之间不能存在传递函数依赖)

第三范式：要求数据表中不存在非关键字段对任一候选关键字段的传递函数依赖。
员工表：员工编号、姓名、年纪、部门名称、部门电话
员工编号决定了姓名、年纪、部门名称、部门电话等等信息。

• 数据冗余：
  当同一个部门存在多个员工，部门电话、部门名称就存在数据冗余。

• 更新异常
  当部门名称更新的时候，每条记录都需要去更新。

• 插入异常
  当部门名称为空的时候，无法插入员工表

第三范式要求：员工表、部门表要分开，第三张表声明部门、员工之间的一对多关系

四、作用小结

第一范式本质更多的是对关系型数据库的一个限定。

第二、第三范式更多的是对数据库表合理设计的一个要求，理解第二、第三范式能够更好的帮助我们设计数据库表。