数据库(第一范式,第二范式,第三范式)

范式来自于英文Normal form,简称NF。要想设计一个好的关系,必须使得关系满足一定的约束条件,此约束已经形成了规范,分成几个等级,一级比一级要求的严格。满足这些规范的数据库是简洁的、结构清晰的。同时不会发生插入、删除、更新操作异常。

第一范式:是指在关系模型中,对于添加的一个规范要求,所有的域应该都是原子性的。即数据库中的每一列都是不可分割的原子数据项,而不能是集合、数组,记录等原子数据项。即实体中的某个属性有多个值时,必须拆分为不同的属性。在符合第一范式(1NF)表中的每个域值只能是实体的一个属性或者属性的一部分。简而言之,第一范式就是无重复的域。

例如:考虑这样一个表:【联系人】(姓名,性别,电话)

如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。


第二范式:

2NF要求的是对记录的唯一性,要求记录有唯一标识,即实体的唯一性,即不存在部分依赖。没有包含主键的列必须完全依赖于主键,而不能只依赖于主键的一部分。

例如:表:学号、课程号、姓名、学分;

这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键,这里学分依赖课程号姓名依赖与学号,所以不符合二范式。

可能出现的问题:

数据冗余:每条记录都含有相同信息

删除异常:删除所有学生成绩,就把课程信息全删除了;

插入异常:学生未选课,无法记录进数据库;

更新异常:调整课程学分,所有行都调整。

正确做法:

学生:Student(学号, 姓名);

课程:Course(课程号, 学分);

选课关系:StudentCourse(学号, 课程号, 成绩)。



第三范式:

在2NF基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)。即不能存在:

非主键列A依赖于非主键列B,非主键列B依赖于主键的情况。

考虑一个订单表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主键是(OrderID)。其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。

通过拆分【Order】为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。

第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。






引用:
https://blog.csdn.net/famousdt/article/details/6921622

https://segmentfault.com/a/1190000013695030

推荐阅读更多精彩内容