
🌸雨落在了我的手上:个人主页
🐟个人仓库:Gitee仓库
❄️个人专栏:<<JaveSe>> <<C语言>> <<C语言数据结构>>** <<Java数据结构*** >>***
<<MySQL数据库基础 >>
🔥🔥🔥 人生格言:无人扶我青云志,我自踏雪至山巅
🎬 博主简介

目录
内容大纲:
本文系统介绍了数据库设计的核心概念,包括六大范式及其应用,重点讲解第一至第三范式,强调通过规范化减少数据冗余与异常。结合实例说明了如何通过拆分表实现第二、三范式,提升数据一致性。同时阐述了从现实业务抽象出实体、属性与关系的设计流程,并引入E-R图作为建模工具,明确实体间的一对一、一对多及多对多关系,最终指导SQL建表实践,为高效数据库设计提供理论与方法支持。
一:本节⽬标
了解数据库范式
了解实例之间的关系
了解数据库的设计过程
了解类、实体、表之间的关系
二:范式
数据库的范式是⼀组规则。在设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数 据库,这些不同的规范要求被称为不同的范式。
关系数据库有六种范式:第⼀范式(1NF)、第⼆范式(2NF)、第三范式(3NF)、巴斯-科德 范式(BCNF)、第四范式(4NF)和第五范式(5NF,⼜称完美范式),越⾼的范式数据库冗余越 ⼩。然⽽,普遍认为范式越⾼虽然对数据关系有更好的约束性,但也可能导致数据库IO更繁忙,因此 在实际应⽤中,数据库设计通常只需满⾜第三范式即可。
1.第⼀范式
定义
• 数据库表的每⼀列都是不可分割的原⼦数据项,⽽不能是集合,数组,对象等⾮原⼦数据。
• 在关系型数据库的设计中,满⾜第⼀范式是对关系模式的基本要求。不满⾜第⼀范式的数据库就不能被称为关系数据库
⽰例
• 定义⼀个学⽣表,需要记录学⽣信息和学校信息
反例
• 学校是⼀个对象,可以继续进⾏拆分,所以不满⾜第⼀范式

正例
• 学校信息包含在⼀⾏中,每⼀列都不能再进⾏拆分,此时已满⾜第⼀范式
在 关系型数据库中,每⼀列都可以⽤基本数据类型表⽰,就天然满⾜第⼀范式
2.第⼆范式
定义
在满⾜第⼀范式的基础上,不存在⾮关键字段对任意候选键的部分函数依赖。存在于表中定义了复合 主键的情况下。
候选键:可以唯⼀标识⼀⾏数据的列或列的组合,可以从候选键中选⼀个或多个当做表的主键
⽰例
• 需求:学⽣可以选修课程,课程有对应的学分,学⽣考试后每⻔课程会产⽣相应的成绩
反例
• ⽤⼀张表记录所有信息
学生课程成绩表
| 学号 | 学生姓名 | 年龄 | 性别 | 课程名 | 学分 | 成绩 |
|---|---|---|---|---|---|---|
| 10001 | 张三 | 18 | 男 | MySQL | 50 | 98 |
| 10002 | 李四 | 19 | 女 | MySQL | 50 | 100 |
| 10003 | 王五 | 18 | 男 | MySQL | 50 | 89 |
| 10001 | 张三 | 18 | 男 | Java | 60 | 100 |
| 10002 | 李四 | 19 | 女 | Java | 60 | 99 |
| 10003 | 王五 | 18 | 男 | C++ | 60 | 98 |
• 这张表中使⽤学号+课程名定义复合主键来唯⼀标识⼀个学⽣某⻔课程的成绩,这也是这张表的主 要作⽤
• 学⽣是通过学号来确定的,学⽣的姓名、年龄和性别和课程没有关系,即学⽣的信息只依赖学号, 不依赖课程名;学分是通过课程来确定的,课程的学分与学⽣没有关系,即学分只依赖课程名,不 依赖学⽣
• 对于使⽤复合主键的表,如果⼀⾏数据中的有些列只与复合主键中的⼀个或其中⼏个列有关系,那 么就说他存在部分函数依赖,也就不满⾜第⼆范式
不满⾜第⼆范式时可能出现的问题
- 数据冗余
学⽣的姓名、年龄、性别和课程的学分在每⾏记录中重复出现,造成了⼤量的数据冗余
- 更新异常
如果要调整MySQL的学分,那么就需要更新表中所有关于MySQL的记录,⼀旦执⾏中断导致某些 记录更新成功,某些数据更新失败,就会造成表中同⼀⻔课程出现不同学分的情况,出现数据不⼀致 问题。
- 插⼊异常
⽬前这样的设计,成绩与每⼀⻔课和学⽣都有对应关系,也就是说只有学⽣参加选修课程考试取 得了成绩才能⽣成⼀条记录。当有⼀⻔新课还没有学⽣参加考试取得成绩之前,那么这⻔新课在数据 库中是不存在的,因为成绩为空时记录没有意义。
- 删除异常
把毕业学⽣的考试数据全都删除,此时课程和学分的信息也会被删除掉,有可能导致⼀段时间 内,数据库⾥没有某⻔课程和学分的信息
正例
• 设计表:针对需求应该设计三张表,即:学⽣表、课程表和成绩表
学生表
| Id | 学号 | 学生姓名 | 年龄 | 性别 |
|---|---|---|---|---|
| 1 | 10001 | 张三 | 18 | 男 |
| 2 | 10002 | 李四 | 19 | 女 |
| 3 | 10003 | 王五 | 18 | 男 |
课程表
| Id | 课程名 | 学分 |
|---|---|---|
| 1 | MySQL | 50 |
| 2 | Java | 60 |
| 3 | C++ | 60 |
成绩表
| 学生Id | 课程Id | 成绩 |
|---|---|---|
| 1 | 1 | 98 |
| 2 | 1 | 100 |
| 3 | 1 | 89 |
| 1 | 2 | 100 |
| 2 | 2 | 99 |
| 3 | 3 | 98 |
第 ⼆范式强调的是部分函数依赖,当⼀张表中的主键只有⼀列时,天然满⾜第⼆范式
3.第三范式
定义
在满⾜第⼆范式的基础上,不存在⾮关键字段,对任⼀候选键的传递依赖。
⽰例
要求学⽣表中记录学⽣所属的学院,在满⾜第⼆范式的基础上对学⽣表做出修改反例
反例
学生表
| Id | 学号 | 学生姓名 | 年龄 | 性别 | 学院 | 学院电话 |
|---|---|---|---|---|---|---|
| 1 | 10001 | 张三 | 18 | 男 | 计算机科学与技术学院 | 88888888 |
| 2 | 10002 | 李四 | 19 | 女 | 网络与信息安全学院 | 66666666 |
| 3 | 10003 | 王五 | 18 | 男 | 通信工程学院 | 99999999 |
• 因为是要描述学⽣信息,并且在表中定义了Id为主键,Id可以明确的标识每条学⽣信息
• 在这个表结构中,可以看出学⽣的学号、姓名、年龄、性别与主键Id强相关;学院电话、学院地址 与学院强相关;在⼀个表中出现了两个强相关的关系,⽽且这两个强相关关系⼜存在传递现象,即 通过学⽣Id可以找到学⽣记录,学⽣记录中包含学院名,每个学院⼜有⾃⼰的电话和地址
• 这种传递现象称为传递依赖,所以当前的表不满⾜第三范式
正例
• 把学院信息拆分出来定义学院表,学⽣表与学院表做关联
学院表
| Id | 所在学院 | 学院电话 | 学院 |
|---|---|---|---|
| 1 | 计算机科学与技术学院 | 88888888 | 陕西省 |
| 2 | 网络与信息安全学院 | 66666666 | 陕西省 |
| 3 | 通信工程学院 | 99999999 | 陕西省 |
学生表
| Id | 学号 | 学生姓名 | 年龄 | 性别 | 学院 |
|---|---|---|---|---|---|
| 1 | 10001 | 张三 | 18 | 男 | 1 |
| 2 | 10002 | 李四 | 19 | 女 | 2 |
| 3 | 10003 | 王五 | 18 | 男 | 3 |
此 时所有表设计满⾜第三范式
三:设计过程
-
从现实业务中抽象得到概念类
概念类是从现实世界中抽象出来的,在需求分析阶段就需要确定下来
-
类对应了数据库设计中的实体,实体对应了数据库中的表
-
类中的属性对应实体中的属性,实体的属性对应了表中的列
-
-
确定实体与实体之间的关系,并画出E-R画,方便项目参与人员理解与沟通
-
根据E-R图完成SQL语句的编号并创建数据库
四:实体-关系图
实体-关系图(Entity-RelationshipDiagram)简称E-R图,也称作实体联系模型、实体关系模型,是 ⼀种⽤于描述数据模型的概念图,主要⽤于数据库设计阶段。
1.E-R图的基本组成
E-R图包含了以下三种基本成分:
-
实体:即数据对象,用矩形框表示,比如用户、学生、班级等。
-
属性:实体的特性,用椭圆形或圆角矩形表示,如学生的姓名、年龄等。
-
关系:实体之间的联系,用菱形框表示,并标明关系的类型,并用直线将相关实体与关系连接起来。
2.关系的类型
⼀对⼀关系(1:1)
• ⼀个⽤⼾实体包含的属性有:⽤⼾昵称,真实姓名,⼿机号,邮箱地址,性别,学校
• ⼀个账⼾实体包含的属性有:登录⽤⼾名,密码
• ⽤⼾实体与账⼾实体是⼀对⼀的关系,⽤E-R图表⽰如下:

⼀对多关系(1:N)
• ⼀个学⽣实体包含的属性有:真实姓名,学号,年龄,性别,⼊学时间
• ⼀个班级实体包含的属性有:班级名,学⽣⼈数
• ⼀个班级中有多个学⽣,所以班级实体与学⽣实体是⼀对多的关系,反过来说学⽣实体与班级实体 是多对⼀着么,⽤E-R图表⽰如下:

多对多关系(M:N)
• ⼀个学⽣实体包含的属性有:真实姓名,学号,年龄,性别,⼊学时间
• ⼀个课程实体包含的属性有:课程名
• ⼀个学⽣可以选修改多⻔课程,⼀⻔课程也可以被多名学⽣选修改,所以学⽣与课程之间是多对多 关系,⽤E-R图表⽰如下:

• 对于多对多关系,可以使⽤中间表进⾏记录,⽐如⼀个学⽣参加了某⼀⻔课程的考试得到了相应的 成绩,⽤E-R图表⽰如下:

以上就是我们的全部内容了!!!!