表设计-----三大范式

鱼骨不是鱼翅

于 2024-08-26 17:11:51 发布

阅读量599

点赞数 8

文章标签：数据库

本文链接：https://blog.csdn.net/2301_80251684/article/details/141547193

版权

1.第一范式

关系型数据库的一个最基本的要求，不满足第一范式就不可以称为关系型数据库

第一范式的特点是：表里的字段不能再进行拆分

不满足第一范式的示例1：

创建一个学生表，表里的字段有姓名，学号，性别，年龄，学校

以上这个表是不满足第一范式的

可以继续拆分在关系型数据库中是绝对不允许的

满足第一范式的条件是：每一个字段都不能继续拆分

示例2：

在写文章时，会有许多标题

1.标题1

2.标题2

3.标题3

3.1子标题1

3.2子标题2

在上面的标题中，标题1和标题2不可再分，标题3可以拆分为子标题1和子标题2，这就不满足第一范式

满足第一范式的示例：

创建一个学生表，有姓名，性别，年龄，班级，学号，学校名字，学校电话，学校地址

虽然这样不符合数据库设计的规范，但是每一列都是不可再分的，最起码表明了一个学生和班级，学校之间的关系

在定义表的时候，对照到数据中的数据类型，每一个字段都可以用一个数据类型表示，那么当前这个表就是天然满足第一范式

2.第二范式

在满足第一范式的基础上，不存在非关键字段对候选键的部分函数依赖（存在复合主键的情况下）

非关键字段：可以理解为非主键字段

候选键：可以理解为主键（primary key），外键（foreign key），没有主键时的唯一键（unique）

复合主键：一个表中不能存在两个主键，但是一个主键中可以包含多个列（primary key（列名1，列名2））

反例：

学生选修课的成绩表

创建一个学号，姓名，年龄，班级，课程，学分，成绩的成绩表

1.学生的姓名，年龄，班级由学号决定

2.学分由课程决定

3.成绩由学号和课程决定，一个学生选修的课程，经过一次考试后才会产生成绩

也就是说这个表中可以用学号和课程作为复合主键来确定同学当前选修课的成绩（主要作用）

4.学生的姓名，年龄，班级和课程没有关系，即学生的姓名，年龄，班级只依赖于学号，不依赖于课程

5.学分与学生没有关系，即学分只依赖于课程，不依赖与学生

6.对于由两个或多个关键字段决定一条记录的情况，如果一行数据中有些字段只与关键字段中的一个有关系，那么这种就说他只存在部分函数依赖，如果有这种情况就不满足第二范式

正例：

创建3个表：

学生表：学号，姓名，年龄，班级

课程表：课程编号，课程名，学分

学生选修课成绩表：学号，课程编号，成绩

这样设计，每张表都有非主键字段，都强依赖于主键，满足第二范式

也就是说一个表中没有复合主键（主键只有一列）那么这种的表就满足第二范式

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

 create table student1(
    -> id int,
    -> name varchar(20) not null,
    -> age int not null,
    -> class_name varchar(20),
    -> credits int,
    -> scores decimal(5,2),
    -> primary key(id,class_name)
    -> );

1.数据冗余

学生年龄，课程名都重复出现，造成了大量冗余

2.更新异常

如果需要调整数据结构的学分，那么就需要更新所有记录中关于MYSQL的记录，如果一旦某些记录更新成功，某些更新失败，就会造成数据表中同一门课程出现不同学分的情况，表现为数据不一致

3.插入异常

目前这样的设计1，每一门课与同学的考试是对应关系，只有同学进行考试之后才会生成一条关于这门课程的成绩记录，这条记录中保存了课程的学分，也就是说一门新课在学生考试之前在数据库中是没有相应记录的，因为学生成绩为空时是没有意义的

4.删除异常

把毕业的学生成绩考虑删除之后，删除记录的同时，也可能把课程对应的学分全部删除了（某一课程只有毕业生报了），导致一段时间内，数据中没有课程和学分相应的信息

3.第三范式

在第二范式的基础上，不存在非关键字段，对任意候选键的传递依赖

反例：

创建一个学生表

有学号，姓名，年龄，所在学院，学院地址，学院电话

上面这个表中存在两个实体，一个是学生，一个是学院

因为现在要描述的是学生，所以可以明显的判定出学号就是这个表的主键

在这个表当中，姓名和年龄与学号是强相关的

学院的地址和学院的电话与所在学院是强相关的

要描述清楚学生所在的学院，只需要把学生和学院建立一个关联关系即可

这两种强相关关系存在传递现象

学号---->所在学院---->学院的电话，学院的地址

这样的传递关系称之为传递依赖

这种设计不满足第三范式，因为存在传递依赖

正例：

根据反例中的学生与学院的关系，将学生和学院拆成两张表即可

学生表

学号，姓名，年龄，学院编号

学院表

学院编号，学院名，学院电话，学院地址

这样设计，两张表都依赖于自己的主键，学生表可以通过外键与学院表之间建立联系

第三范式解决了数据冗余，更新异常，删除异常，插入异常的问题