数据库系统概论（十八）详细讲解数据库设计的概念

本文系统讲解了数据库设计的概念、流程与方法。数据库设计分为需求分析、概念结构设计、逻辑结构设计、物理结构设计、实施与维护六个阶段，从用户需求出发逐步转化为可运行的数据库系统。需求分析是基础，需明确数据和处理需求；概念设计用ER图构建数据关系；逻辑设计转化为表结构；物理设计优化存储效率。文章还介绍了三层模式架构（外模式、模式、内模式）和需求分析的常用工具（数据流图、数据字典）。整个设计过程强调以用户

珹洺

1013人浏览 · 2025-06-16 19:55:31

珹洺 · 2025-06-16 19:55:31 发布

数据库系统概论（十八）详细讲解数据库设计的概念

前言
一、数据库设计概述
二、需求分析
三、概念结构设计
四、逻辑结构设计
五、物理结构设计
六、数据库的实施和维护

前言

在前几期博客中，我们探讨了 SQL 连接查询，单表查询，嵌套查询，集合查询，基于派生表的查询，数据插入，修改与删除，空值的处理，视图，数据库安全性，数据库规范化与五大范式技术等知识点。
从本节开始，我们将深入讲解数据库设计的概念。

我的个人主页，欢迎来阅读我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的数据库系统概论专栏
https://blog.csdn.net/2402_83322742/category_12911520.html?spm=1001.2014.3001.5482

一、数据库设计概述

1. 数据库设计是什么？

类比理解：假设我们要开一家图书馆，需要将书籍分类存放以便读者快速查找。

数据库设计就像这个「分类存放」的过程，核心是根据用户需求（如按作者/类别检索）和技术环境（如存储容量、性能要求），设计最优的数据存放方案。

1.1 方案的三个层次：

概念模型：用ER图等简单图示描述数据关系（如「读者」与「书籍」的借阅关系），类似图书馆的整体布局图。
逻辑模型：将概念图转化为数据库表结构（如「读者表」包含姓名、学号），类似细化每个书架的格子规划。
物理模型：决定数据在硬盘的存储方式（如选择存储引擎、创建索引），类似选择书架材质和摆放位置以提升查找效率。

1.2 最终目标：

确保数据可高效存储、查询，并满足用户的增删改查需求。

2. 数据库设计分几步？

在这里插入图片描述

阶段1：需求分析阶段

任务：与用户沟通（如图书馆管理员），收集两类需求：
- 数据需求：需存储的信息（读者信息、书籍信息、借阅记录）。
- 处理需求：需实现的功能（查询书籍借阅状态、统计借阅量）。
成果：输出《需求说明书》，明确目标。

阶段2：概念结构设计阶段

任务：用ER图将需求转化为概念模型：
- 实体：读者（属性：学号、姓名）、书籍（属性：ISBN、书名）。
- 关系：读者与书籍为「多对多借阅关系」（一个读者可借多本书，一本书可被多个读者借）。
成果：独立于具体数据库（如MySQL/Oracle）的概念模型，类似图书馆布局草图。

阶段3：逻辑结构设计阶段

任务：根据概念模型和数据库类型（如MySQL）设计表结构：
- 实体→表（读者表、书籍表）。
- 关系→字段或外键（借阅记录表用「学号」和「ISBN」关联读者表和书籍表）。
- 优化表结构（减少冗余、拆分大表）。
成果：表定义示例：

CREATE TABLE 读者表 (
  学号 CHAR(10) PRIMARY KEY,
  姓名 VARCHAR(20),
  学院 VARCHAR(50)
);

阶段4：物理结构设计阶段

任务：结合硬件环境（如SSD/HDD、内存大小）设计存储方案：
- 选择存储引擎（MySQL中InnoDB适合事务，MyISAM适合读多写少）。
- 创建索引（如在「学院」字段建索引，加速按学院查询）。
- 规划数据文件位置（常用表放高速硬盘）。
成果：物理存储方案，类似确定书架材质和摆放顺序。

阶段5：数据库实施阶段

任务：用SQL创建表和索引，导入数据，开发应用程序（如图书馆管理系统）。
成果：可运行的数据库（如包含10万条读者和书籍数据）。

阶段6：运行和维护阶段

任务：
- 日常维护：数据备份、性能监控。
- 升级优化：根据需求变更修改表结构（如新增「按出版社查询」功能）。
- 故障处理：恢复损坏数据。
成果：稳定运行的数据库系统。

3. 整个流程怎么运转？—— 流程图解

在这里插入图片描述

应用需求（数据+处理需求） → 需求收集和分析 → 需求分析阶段 → 生成《需求说明》  
↓  
《需求说明》+ 数据库管理系统功能 → 设计概念结构（画ER图） → 概念结构设计阶段 → 概念模型  
↓  
概念模型 + 转换规则 → 设计逻辑结构（转表结构+优化） → 逻辑结构设计阶段 → 逻辑模型  
↓  
逻辑模型 + 数据库特征（如MySQL存储引擎） → 设计物理结构（选存储+建索引） → 物理结构设计阶段 → 物理模型  
↓  
物理模型 → 评价设计（预测性能） → 不满意？→ 返回修改；满意？→ 物理实现（建库+导数据） → 实施阶段 → 可运行数据库  
↓  
数据库 → 试验性运行（少数用户试用） → 不满意？→ 返回修改；满意？→ 正式使用+持续维护 → 运行维护阶段

4. 数据库的三层模式是什么？

在这里插入图片描述

4.1 外模式（最外层：用户视角）

定制化界面：如图书馆管理员可修改数据，普通读者仅能查询个人借阅记录。
不同应用（如APP/管理后台）对应不同外模式，仅展示所需数据。

4.2 模式（中间层：设计师视角）

全局数据视图：包含所有表结构和关系（如读者表、书籍表的完整定义），类似图书馆总布局图。

4.3 内模式（最内层：计算机视角）

物理存储方式：如数据格式、索引组织形式，决定存储效率，类似图书馆的地基设计。

4.4 三层关系：

外模式通过「映像」关联模式（如普通读者仅关联读者表部分字段）。
模式通过「转换规则」映射为内模式（表结构转化为硬盘文件）。

二、需求分析

1. 为什么必须做需求分析？

类比理解：盖房子若不先问住户要几间卧室、是否需要书房，直接施工可能导致房屋无法居住。数据库设计同理，需求分析是「地基」，有三大作用：

给开发团队指路：明确目标（如图书馆管理系统/电商订单系统），避免方向偏差。
让用户与开发同频：将用户模糊需求（如"快速查书"）转化为具体要求（按书名/作者/出版社查询）。
给测试团队验收标准：按《需求说明书》检查功能是否达标（如"借书超时提醒"是否实现）。

2. 需求分析怎么做？

在这里插入图片描述

四步流程：

调查组织机构：
- 明确用户角色（如出版社编辑部/销售部）及工作流程（编辑校对→排版→印刷→销售）。
熟悉部门业务：
- 梳理各部门处理的数据（如销售部订单/发票）及痛点（手工统计易出错、效率低）。
明确用户要求：
- 区分三类需求：
  - 功能需求：如自动生成销售报表、实时查看库存。
  - 数据需求：需存储的信息（如订单包含买家信息、商品明细）。
  - 性能需求：如查询响应时间≤1秒。
确定系统边界：
- 明确系统「做什么」与「不做什么」（如图书馆管理系统不涉及图书采购流程）。

俩大成果：

数据字典：
- 详细记录数据定义（如"学号：8位字符，前两位代表年级"）及关系（如"学生=学号+姓名+班级"）。
用户需求规格说明书：
- 整理成正式文档，例：“借书时检查超期未还书籍，存在则拒绝借阅”。

3. 怎么收集需求？

六种收集方法：

跟班作业：跟随用户工作，记录数据处理流程（如跟图书馆管理员观察借书步骤）。
开调查会：召集各部门负责人集中讨论需求（如问销售部"最希望系统解决什么问题"）。
专人介绍：与业务骨干单独沟通，深挖细节（如老编辑讲解出版流程关键数据）。
直接询问：按清单逐项提问（如"每天需要打印哪些报表"）。
问卷调查：向大量用户收集共性需求（如"借书流程中最麻烦的环节"）。
查阅记录：分析现有手工表格/旧系统数据，发现潜在需求（如旧表格含"图书丢失赔偿记录"）。

俩个分析工具：

数据流图（DFD）：
- 示例（销售管理系统）：
  顾客提交订单 → 系统核对价格/账目 → 批准订单 → 生成发票，清晰展示数据流向（订单数据→价格数据→应收账款）。
数据字典（DD）：分四类记录：
- 数据项：例"学号：8位字符，唯一标识学生"。
- 数据结构：例"学生=学号+姓名+性别+班级"。
- 数据流：例"选课信息来自选课操作，存至学生选课表，日均200条"。
- 数据存储：例"学生选课表含学号+课程号+成绩，共5万条，支持随机查询"。

4. 用例模型：让需求更直观

在这里插入图片描述

示例：借书场景

参与者：管理员、借阅者。
操作步骤：
1. 管理员输入借书证号 → 系统检查（证号错误/超期未还→拒绝借书）。
2. 输入图书条码 → 显示图书信息 → 确认借阅。
特殊情况：证号错误→提示"拒借"；超期未还→提示"先还书"。
作用：以剧本形式拆解操作细节，便于开发人员理解。

三、概念结构设计

1. 什么是概念结构设计？

想象你要开一家超市：

需求分析阶段你已经知道要卖哪些商品（数据）、怎么收银（功能），但这些信息还是零散的文字。
概念结构设计就像画一张"超市布局图"，用简单的图形把数据和它们的关系画出来，让所有人都能看懂，这个图就是E-R图（实体-关系图）。

它的核心目标是：把需求分析阶段收集的信息，抽象成一个不依赖具体数据库（比如MySQL、Oracle）的"数据蓝图"，方便后续设计表结构。

2. E-R模型：

2.1 三个基本元素

实体（主角）：用矩形表示，比如"学生"“课程”“图书”，是现实中存在的"对象"。
属性（特征）：用椭圆形表示，描述实体的细节，比如"学生"有学号、姓名、性别，"图书"有书号、书名、作者。
联系（关系）：用菱形表示，描述实体之间的关联，比如"学生选修课程"“读者借阅图书”，旁边标上关系类型（1:1、1:n、m:n）。

2.2 实体间的三种关系

在这里插入图片描述

一对一（1:1）：一个A对应最多一个B，反之亦然。

例：一个班级只有一个班长，一个班长只管理一个班级（班级←1:1→班长）。
一对多（1:n）：一个A对应多个B，但一个B只能对应一个A。

例：一个班级有多个学生，一个学生只能属于一个班级（班级←1:n→学生）。

多对多（m:n）：一个A对应多个B，一个B也对应多个A。

例：一个学生可以选多门课程，一门课程可以被多个学生选（学生←m:n→课程）。

2.3 特殊情况：三个以上实体的关系 & 实体内部的关系

多个实体的关系：比如"供应商-项目-零件"的供应关系，可能是多对多对多（m:n:p），表示一个供应商可以给多个项目供应多种零件。
实体内部的关系：比如员工之间的"领导"关系（一个领导管多个员工，1:n），或者课程的"先修课"关系（一门课可能有多个先修课，多对多）。

3. 概念结构设计分两步走

第一步：设计局部E-R图

选局部应用：把整个系统拆分成子模块

比如图书管理系统拆成"读者管理"“图书管理”“借阅管理”。

画分E-R图：
- 从数据字典（DD）中提取该模块的实体和属性，比如"读者"实体有卡号、姓名、手机号。
- 确定实体间的联系和类型，比如"读者"和"图书"是多对多的"借还"联系，联系中还要记录借阅日期、应还日期等属性。
- 示例：图书借阅系统的局部E-R图：
  - 实体：读者（卡号为主码）、图书（书号为主码）、出版社（出版社名为主码）
  - 联系：读者←m:n→图书（借还，含借阅日期等），图书←n:1→出版社（出版）

第二步：集成全局E-R图

合并分E-R图，解决三类冲突（就像统一不同人的绘图习惯）：
- 属性冲突：同一属性在不同模块定义不同，比如"年龄"在人事部是数字，在财务部是"青年/中年"（统一数据类型和单位）。
- 命名冲突：同名不同义（"编号"在学生表是学号，在课程表是课程号），或同义不同名（“手机"和"移动电话”），统一命名。
- 结构冲突：同一对象在不同模块抽象不同，比如"产品"在销售模块是实体，在库存模块是属性（统一抽象成实体）。
消除冗余：去掉重复的数据或联系（这些冗余数据可以通过其他数据计算出来）。
- 例：如果"学生总分"可以通过"各科成绩相加"得到，就不需要单独存"总分"字段。
生成基本E-R图：合并后的图要结构清晰，没有矛盾，能覆盖所有需求。

4. 如何验证你的E-R图是否合格？

4.1 三个验证标准

无矛盾：所有实体、属性、联系的定义一致，比如"读者卡号"不能同时是字符型和数字型。
完整覆盖需求：需求分析中提到的所有数据和关系，比如"图书超期提醒"对应的"是否超期"属性必须在图中体现。
简洁优化：没有不必要的冗余，实体和联系数量合理（不是越多越好，也不是越少越好）。

4.2 一个重要原则：E-R图没有"标准答案"，但有"好坏之分"

允许不同设计方案，只要覆盖需求即可（比如"职称"可以作为"员工"的属性，也可以单独作为实体，取决于是否需要描述职称的详细信息）。
好的E-R图：结构清晰（实体、属性、联系一目了然）、关系简洁（避免复杂的多对多关系）、冗余少（数据不重复存储）。

5. 实战案例：从需求到E-R图的完整过程

以"IT公司管理系统"为例：
需求：

部门有名称、办公地点，一个部门只有一个经理，一个员工最多当一个部门的经理。
员工属于一个部门，参与多个项目，每个项目有负责人（员工），记录参与项目的工作时长。

设计步骤：

画局部E-R图：
- 部门实体（主码：名称），属性：办公地点、部门经理（员工编号）。
- 员工实体（主码：编号），属性：姓名、出生日期、职级、所属部门。
- 项目实体（主码：编号），属性：项目名称、开始日期、结束日期。
- 联系：
  - 部门←1:n→员工（工作，含开始日期）；部门←1:1→员工（领导，经理关系）。
  - 员工←m:n→项目（参与，含工作时长）；员工←m:n→项目（负责，负责人关系）。
集成全局图：
- 检查冲突：比如"员工编号"在部门和员工表中是否一致（统一为主码）。
- 消除冗余：确保"部门经理"和"员工所属部门"没有重复数据。

四、逻辑结构设计

1. 逻辑结构设计

核心定位：承接概念设计的E-R图，将其转化为数据库可识别的关系模型（表结构），类似建筑蓝图到施工图纸的转化。
两大目标：

实体/关系→表/外键：让E-R图中的实体、属性、联系对应表、字段、表间关系。
结构优化：确保表结构合理（低冗余、高性能），满足业务查询需求。

2. 第一步：E-R图转关系模型

在这里插入图片描述

2.1 实体→表：一一对应

规则：实体属性→表字段，实体主键→表主键。
示例：
实体：学生（学号, 姓名, 年龄）→ 表：学生(学号, 姓名, 年龄)，主键为学号。

2.2 实体间联系→表：

（1）一对一联系（1:1）：两种方案任选

方案	操作	适用场景	示例
方案1：独立成表	联系单独建表，包含两端主键+联系属性	需记录联系自身属性（如任职时间）	管理(车间编号, 职工编号, 任职时间)，主键可选车间编号或职工编号
方案2：合并到任一端	在一端表中加入另一端主键+联系属性	简化表数量，无特殊联系属性	车间(车间编号, 名称, 车间主任职工编号, 任职时间)，主键为车间编号

（2）一对多联系（1:n）：合并到"多"端表

规则：在"多"端表中添加"一"端主键（外键）+联系属性。
示例：
班级（1端，班级编号）→学生（n端，学号）的"组成"联系→
学生表：学号, 姓名, 班级编号（外键）, 入学时间
优势：减少表数量，查询学生所属班级直接通过外键关联。

（3）多对多联系（m:n）：必须独立成表

规则：表字段=两端主键+联系属性，主键=联合主键（两端主键组合）。
示例：
学生（学号）→课程（课程号）的"选修"联系（含成绩）→
选修表：学号, 课程号, 成绩，主键为（学号, 课程号）
原因：多对多关系无法直接合并到任一表，需单独表记录关联细节。

3. 特殊情况处理

三个以上实体的联系（如供应商-项目-零件）：
单独建表，主键=所有实体主键组合。
示例：供应(供应商号, 项目号, 零件号, 供应量)，联合主键（供应商号, 项目号, 零件号）。
实体内部联系（如职工"领导"关系）：
在同表中添加自关联外键。
示例：职工(职工号, 姓名, 领导职工号)，领导职工号指向自身表的职工号。

3.数据模型优化

1. 优化三步法

（1）消除冗余数据

目标：避免重复存储可通过关联获取的数据。
示例：学生表若同时存「班级编号」和「班级名称」，可删除「班级名称」（通过班级编号查班级表获取）。

（2）规范化：确定范式等级

范式	核心要求	示例
1NF	字段不可分割（原子性）	“地址"拆分为"省”“市”"区"三个字段
2NF	消除部分依赖（主键完全决定非主键字段）	订单表中，订单号+商品号→商品价格，若商品价格仅依赖商品号，需拆分商品表
3NF	消除传递依赖（非主键字段不依赖其他非主键字段）	学生表中，学号→班级编号→班级地址，班级地址移至班级表，学生表仅留班级编号

（3）表分解策略

水平分解：按数据特征分片（如教师表按性别拆分为男/女教师表，减少单表数据量）。
垂直分解：按字段使用频率拆分（如教师表中常用字段留主表，不常用的"家庭地址"拆至扩展表）。

2. 平衡范式与性能

并非范式越高越好！3NF虽低冗余，但可能增加多表连接查询（降低速度）。
实际策略：根据业务场景调整，允许适度冗余（如高频查询字段可冗余存储以减少连接）。

4. 第三步：设计用户子模式 —— 定制「专属数据视图」

目标：通过外模式（子模式）为不同用户过滤数据，提升易用性和安全性。

1. 三大设计原则

（1）使用别名提升可读性

操作：将技术化字段名转换为业务术语。
示例：「职工号」→「员工编号」，「ISBN」→「图书编码」。

（2）通过视图控制访问权限

操作：为不同用户创建特定视图，限制可见表/字段。
示例：
- 普通读者视图：仅包含「借阅记录表」，隐藏「图书库存表」。
- 管理员视图：全表访问权限。

（3）封装复杂查询简化操作

操作：将多表连接查询封装为视图。
示例：「学生成绩视图」直接展示姓名、课程名、成绩，无需手动连接学生表+课程表+选修表。

五、物理结构设计

1. 物理结构设计

逻辑设计完成后，表结构（如学生表、课程表）已明确，但如何将数据存入硬盘并实现快速读写？

物理结构设计聚焦"存储方式"与"存取效率"，类似超市将畅销商品置于前排货架的策略。

核心目标

定义数据在硬盘的存储机制（索引类型、分区策略等）。
优化查询、插入、更新性能，同时控制存储空间。

2. 三大索引策略深度解析

2.1 B+树索引：最通用的"目录式检索系统"

原理：类似图书馆分类目录（如"计算机→数据库→第3层书架"），适合多层级范围查询。
适用场景：

字段排序需求（如"按成绩降序排列"）；
范围查询（如"查询20-25岁的学生"）；
多表连接关联字段（如学生表与选修表通过学号关联）。
注意：单表索引不超过5个，避免索引冗余影响性能。

2.2 Hash索引：精准定位的"哈希编号检索"

原理：为数据分配唯一哈希值，直接定位存储位置，类似图书ISBN编号。
适用场景：

精确查询（如"根据用户ID查询信息"）；
数据分布均匀（如随机生成的ID，无大量重复）。
缺点：不支持范围查询（如"ID>1000的用户"），大数据量可能引发哈希冲突。

3.3 聚簇索引："相关数据打包存储"策略

原理：将关联数据（如订单表与订单详情表）按关键字段就近存放，利用磁盘预读机制减少IO次数。
适用场景：

高频多表连接查询（如"查询订单对应的商品详情"）；
数据更新频率低（频繁修改会导致存储位置重排）。
限制：单表仅支持1个聚簇索引，类似书架只能有一个主题分类。

3. 数据高效存放的三大策略

1. 数据文件组织形式：选对"书架类型"

堆文件：数据无序存储，适合频繁新增（但查询需全表扫描）；
顺序文件：数据按指定顺序排列（如学号升序），适合范围查询，但插入时可能需移动大量数据。

2. 分区策略：给数据"分仓库"

分区类型	应用场景举例	优势
范围分区	订单表按年份分区（2023年/2024年数据）	历史数据查询时跳过无效分区
列表分区	员工表按部门分区（销售部/技术部）	便于权限管理与分库存储
哈希分区	用户表按ID哈希值分散存储	数据均匀分布，避免单盘压力过大

3. 磁盘存储规划：冷热数据分离策略

热数据（近1个月订单）：存放高速SSD，保障毫秒级响应；
冷数据（3年前订单）：存放HDD机械盘，降低存储成本；
日志与备份：独立磁盘存储，避免IO竞争影响业务查询。

4、"仓库效率测试"指南

4.1 三大核心评价指标

指标	衡量标准	示例要求
时间效率	查询/插入操作耗时	登录验证响应<0.1秒
空间效率	数据与索引占用的磁盘空间	索引空间不超过数据量的30%
维护代价	索引更新频率、备份恢复复杂度	每日自动索引优化，备份耗时<1小时

4.2 优化流程

模拟测试：用真实数据量压测（如1000用户并发查询订单）；
方案对比：例如B+树与Hash索引的查询速度对比（电商选Hash，图书馆选B+树）；
迭代优化：针对慢查询调整索引类型或分区策略，直至满足性能要求。

六、数据库的实施和维护

1. 数据库实施

阶段目标：将数据库设计（需求分析→概念设计→逻辑设计→物理设计）转化为实际运行的系统，类似“盖房后的装修与搬家”。

1.1 数据载入：向数据库“新房”迁移数据

类比：为新书架（数据库表）搬运书籍（数据）。

两种迁移方式：

人工方式：适用于少量数据或初始测试
- 场景：用Excel手动录入几百条学生信息，或通过Navicat等工具逐条插入数据。
计算机辅助方式：适用于大规模数据迁移
- 工具迁移：使用ETL工具（如Kettle）从旧系统同步数据（支持Excel、CSV等格式）。
- 脚本批量导入：用Python/Java编写脚本，按表结构批量插入数十万级数据。

关键注意：

数据格式校验：确保字段符合规范（如“学号”必须为8位字符，无乱码），避免入库失败。

1.2 试运行：给数据库“做全面体检”

类比：新车试驾，验证功能与性能。

核心测试内容：

功能测试：验证是否满足业务需求
- 例：“借书功能”能否正确记录借阅日期，“超期提醒”是否触发。
性能测试：验证运行效率
- 例：“查询全班成绩”是否在1秒内完成，批量插入1万条数据是否卡顿。

实施策略：

分期分批入库：先导入少量数据（如100条）测试功能，再逐步增加至10万条验证性能，避免数据量过大导致问题难排查。
优先测试恢复功能：首次试运行需验证“备份与恢复”能力，例：故意删除数据后，通过备份文件快速还原，确保数据安全。

2. 数据库维护

责任主体：DBA（数据库管理员），类似“房屋日常维护”。

1. 数据备份与恢复：防范“数据丢失灾难”

备份策略：

全量备份：复制整个数据库，适用于数据量较小的系统。
增量备份：仅备份上次备份后更新的数据，适用于数据量大、更新频繁的场景（如电商订单）。
备份频率：建议每日凌晨执行增量备份，每周执行一次全量备份。

恢复机制：

当数据丢失或损坏时（如误删表），通过最近的备份文件快速还原至正常状态。

2. 安全与完整性控制：为数据“加锁加密”

安全性控制：

权限分级：按角色分配权限（例：普通员工仅能查询个人工资，经理可查询部门数据）。
敏感数据加密：对密码、身份证号等信息采用MD5/SHA加密存储，防止泄露。

完整性控制：

唯一性约束：如“学号”字段必须唯一，避免数据重复。
逻辑校验：如“借阅日期”不得晚于“应还日期”，确保数据逻辑正确。

3. 性能监控与优化：让数据库“跑更快”

实时监控要点：

查询效率：关注慢查询（如订单查询耗时从1秒增至5秒，可能是索引失效）。
资源占用：监控磁盘空间是否不足，及时清理过期日志或归档历史数据。

优化手段：

索引优化：为高频查询字段添加索引（例：订单表按“下单时间”建索引）。
参数调优：增加内存缓冲区，减少硬盘读取频率，提升数据访问速度。

以上就是这篇博客的全部内容，下一篇我们将继续探索更多精彩内容。

我的个人主页，欢迎来阅读我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的数据库系统概论专栏
https://blog.csdn.net/2402_83322742/category_12911520.html?spm=1001.2014.3001.5482

非常感谢您的阅读，喜欢的话记得三连哦

在这里插入图片描述