数据库设计三大范式

目录

第一范式

第二范式

第三范式

第一范式

定义：数据库表的每⼀列都是不可分割的原子数据项，而不能是集合，数组，对象等非原子数据

通俗的来讲，就是数据库中的每项数据都不可再分（实际应用上的“不可再分”，例如datetime其实可以再分成年月日时分秒，但是这个是一项基本数据类型，因为很多应用场景，这个数据都可以独立存在使用，而不用拆分，那么就可以看作“不可再分”）

下面举一组例子

第二范式

定义：满足第⼀范式的基础上，不存在非关键字段对任意候选键的部分函数依赖。存在于表中定义了复合主键的情况下。

解释：

非关键字段：不是候选键的字段

候选键：可以唯⼀标识⼀行数据的列或列的组合，可以从候选键中选⼀个或多个当做表的主键。

函数依赖：如果知道了一个（或一组）字段 X 的值，就能唯一确定另一个字段 Y 的值，那么我们就说 Y 函数依赖于 X

通俗的讲，就是不存在表中的部分关键字段就能确定一部分非关键字段的情况。

反例例如

若姓名和选课作为联合主键，仅通过选课就能确定学分，这就不符合第二范式

应该拆成两个表，一个包含姓名和选课，一个包含选课和学分

不满足第二范式可能出现的问题

1.数据冗余

2.更新异常：如果要调整学分，那么就需要更新表中所有关于MySQL的记录，⼀旦执行中断导致某些记录更新成功，某些数据更新失败，就会造成表中同一门课程出现不同学分的情况，出现数据不⼀致问题。

3.插入异常：目前这样的设计，成绩与每一门课和学⽣都有对应关系，当有一门新课还没有学⽣参加考试取得成绩之前，那么这门新课在数据库中是不存在的。

4.删除异常：毕业时删除毕业生会导致相应课程的学分也没有记录

第三范式

定义：在满足第二范式的基础上，不存在非关键字段，对任⼀候选键的传递依赖。

反例例如：

表中通过候选键姓名可以确定他们的学校，通过学校可以确定地址和电话，这就是传递依赖

应该将其拆成两张表

第一张表主键是姓名，第二张表主键是学校，就可以消除传递依赖。