从第一范式(2nf)到第二范式(3nf)_数据库设计以及三大范式

一 、 数据库设计的概念

1、数据库设计的流程

在数据库设计的流程上，我们通常根据需求画出数据的 ER 图。然后在通过 ER 图生成数据库的建库脚本。

ER 图：所谓的 ER 图就是 数据库关系图。

2、为什么我们使用 ER 图来实现数据库设计的设计呢?

1. 可见即可得，使用 ER 图可以通过图形的方式展示表与表直接的关系
2. 可以根据设置的数据库，方便生成不同的数据库的 SQL 建库脚本
3. 可以快速的生成数据库文档

二 、 数据库设计的基础流程

1、数据库设计的步骤

第一步：标识表的设计

第二步：表字段的设计

第三布：表与表之间的设计

2、标识表的注意事项

表分为实体表以及业务表，但我们通常在标识表时会先标识实体表，再标识业务表。因为业务表一般是用于标识实体表与另一个实体的多对多的关系的。

实体表：记录中描述一个对象的表，就是名词，例如用户、商品、订单等
业务表：就是需求中一个行为，关注、收藏等（大部分是中间表）

3、标识字段要符合数据库三大范式

第一范式：确保标识的字段的原值性，字段的概念分得不能再分。如：姓名可以分为姓和名。

第二范式：确保标识的字段与表有依赖的关系，在用户表定义一个商品价格

第三范式：确保标识的字段与表有直接依赖的关系，用户表，用户类型的名称

三、数据库设计范式

关系数据库中的关系必须满足一定的要求，即满足不同的范式。

关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式（4NF）和第五范式（5NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。

设计关系型数据库时，遵从不同的规范要求，设计出合理的关系型数据库。这些规范被称作范式。越高的范式数据库的冗余度就越低。

一般说来，数据库只需满足第三范式（3NF）就行了。

四、数据库设计的三大范式案例

案例：学生的关系模式 Student（学生编号 , 学生姓名, 班级编号, 院系, 课程编号 , 成绩）

1、第一范式（无重复的列）

数据库表的每一列都是不可分割的原子数据项，而不能是集合、数组、记录等非原子数据项。如果实体中的某个属性有多个值时，必须拆分为不同的属性。

通俗解释：不能表中套表，要保证数据的原子性。

示例： 学生编号---课程编号

不满足第一范式：

它就不满足 1NF，因为 {C1，C2，C3} 和 {C1，C4} 是集合。

第一范式：

2、第二范式（属性完全依赖于主键）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。当存在多个主键的时候，才会发生不符合第二范式的情况。比如有两个主键，不能存在这样的属性，它只依赖于其中一个主键，这就是不符合第二范式。如果存在不符合第二范式的情况，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

通俗解释：任意一个字段都只依赖表中的同一个字段。

示例：

我们发现，对于学生姓名、学生所属的班级编号、院系，这三个属性可以直接通过学生编号来确定，在这里课程编号显得很多余。也就是，学生姓名、班级编号、院系对 学生编号、课程编号部分函数依赖。

它就不满足 2NF，我们需要把 Student 表进行拆分，可以消除部分依赖。

第二范式：

• 学生表：

• 学生-课程表：

3、第三范式（属性不能传递依赖于主属性）

第三范式（3NF）是在第二范式（2NF）的基础上建立起来的，即满足第三范式（3NF）必须先满足第二范式（2NF）。如果某一属性依赖于其他非主键属性，而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。

通俗理解：一张表最多只存2层同类型信息。

示例：

我们发现，对于 Student 表，学生编号可以唯一确定他所在的院系，但是注意到这中间存在传递过程，即学生编号唯一确定该学生所对应的班级编号，班级编号对应唯一的院系。我们称，院系对学生编号传递函数依赖。

它就不满足 3NF，我们需要把 Student 表继续进行拆分，可以消除传递依赖。

第三范式：

• 学生表：

• 班级-院系表：

4、最终的学生关系模式

学生表：

学生-课程表：

班级-学院表：

5、总结

1NF： 字段是最小的的单元不可再分。

2NF：满足 1NF，表中的字段必须完全依赖于全部主键而非部分主键（一般我们都会做到）。

3NF：满足 2NF，非主键外的所有字段必须互不依赖。

知乎视频​www.zhihu.com

希望能够帮到大家，有问题的可以留言讨论哦！