数据库课后题重点摘要

1.DB:数据库

DBS：数据库系统

DBMS：数据库管理系统

DBS =DB+DBMS

数据模型的三要素：数据结构 数据操作 完整性约束

2.简述数据库管理技术发展的三个阶段和各个阶段的特点

1）人工管理阶段：数据不保存，应用程序管理数据，数据不能共享，及数据不具有独立性

2）文件系统阶段：数据可以长期保存，有文件系统管理数据，文件多样化，数据共享性差，冗余度大，数据独立性差

3）数据库系统阶段：面向全组织的复杂数据结构，数据共享性；高冗余度小，容易扩充，有较高的数据和程序的独立性，统一的数据控制功能（数据的安全性控制，完整性控制，并发控制，数据库的恢复）

3.简述数据库系统特点

4.概念理解

实体：客观存在并相互区别的事物

实体集：性质相同的同类实体的集合

属性：实体具有的某一方面的特性或性质

实体键（码）：能唯一区分同类实体中的各个实体的属性或属性集

域：属性的取值范围

字段：标记实体属性的命名单位

记录：字段的有序集合

数据库系统的三级模式：模式，内模式，外模式（外模式/模式映像 模式/内模式映像）

两级数据独立性：物理独立性和逻辑独立性

模式：概念模式 数据库模式 主体是数据库的数据模型

外模式：子模式 用户模式

内模式：存储模式

一个数据库可以有多个外模式但是模式和内模式只能有一个

数据库管理系统功能：数据定义；数据操纵；数据库运行管理；数据库建立和维护；

数据模型：概念模型；物理模型；逻辑模型；

1.码：键，关键字

全码：关系模式所有属性组是这个关系模式的候选码

主码：若一个关系有多个候选码，则选定其中一个作为主码

主属性：候选码的属性

2.关系中没有行序的原因是 关系是集合，集合中的元素无序

3.关系的并 交 差 操作要求两个关系具有相同的关系模式

关系模式的定义：对关系的描述，关系模式是型 关系是值，形象化定义为

R(U,D,dom,F)

关系（属性，域，域映射，函数依赖集）

4.关系操作的特点：集合操作方式

5.关系的名称和它的属性列表称为关系的模式

6.关系性质：

列是同质的；不同的列可出自同一个域，每一列称为一个属性，不同属性要给与不同的属性名；列的顺序无所谓；任意两个元组的候选码不能相同；行的顺序无所谓；分量必须取原子值，每一个分量都是不可再分的数据项

7.关系运算：

传统的集合运算：并 交 差 笛卡尔积

专门的关系运算：选择 连接 投影 除

8.关系的五种基本运算：选择 投影 并 差 笛卡尔积

9.等值连接和自然连接

联系：自然连接是一种特殊的等值连接

区别：等值连接的等值条件是任意属性间的相等，而自然连接要求两个关系中同名属性进行等值连接；

​ 等值连接会保留连接后的所有属性，而自然连接会去重

10.关系模型的完整性规则包括？

实体完整性：要求关系的主码中属性值不能是空值

参照完整性：要求外码的值要么为空值，要么等于被参照关系中某个元组的主码值

用户定义的完整性：根据具体需求设定的约束条件

11.外码在什么情况下允许取空值？什么情况不允许？

允许：当外码所表示的联系是可选的，即该属性并非必须关联到被参照关系的元组时

比如 学生的导师编号是外码，暂未分配导师，该字段可空

不允许：当外码所表示的联系是必须的，即该属性必须关联到被参照关系的元组时

比如 学生的系编号是外码，学生必须属于某个系，因此该字段不能为空

1.SQL特点：

一体化

高度非过程化

面向集合的操作

提供多种使用方式

功能强大，简洁易用

2.相关子查询和不相关子查询区别：核心差异在于 "子查询是否依赖外层查询的字段" ------ 不相关子查询是 "独立计算一次"，相关子查询是 "随外层每行数据重复计算"。

维度	不相关子查询（非关联子查询）	相关子查询（关联子查询）
依赖关系	子查询独立于外层查询，不引用外层的任何字段	子查询引用外层查询的字段（如外层表的列），依赖外层数据
执行顺序	先执行子查询 → 得到一个结果集 → 再代入外层查询执行（仅执行 1 次）	先取外层查询的 1 行数据 → 代入子查询执行 → 子查询结果决定外层该行是否保留 → 重复此过程直到外层所有行处理完（子查询执行次数 = 外层结果行数）
结果复用	子查询结果可复用（一次计算，全局生效）	子查询结果不可复用（每行都要重新算）
性能特点	通常性能更好（仅执行 1 次）	性能易差（多次执行），需依赖索引优化

3.视图：一个虚表，是从一个或者几个基本表导出的表，数据库只存放视图的定义，而不存放视图对应的数据，当基本表的数据发生变化，从视图中查询出的数据也随之改变

子查询不允许含有ORDER BY 和 DISTINCT

WITH CHECK OPTION表示对视图进行更新操作系统自动加上视图定义中的谓词条件

作用：简化用户操作；提供数据保密；保证数据的逻辑独立性；使用户能以多种角度看待同一数据；

4.在sql中，对于查询结果是否出现元组是否允许存在重复元组是通过distinct实现的

1.Mysql客户端程序具有哪些功能？

1）实现sql执行，数据读写，连接管理

2）可视化管理对象，监控性能，优化sql

3）备份恢复，权限管理，服务器监控

2.Mysql存储过程中是否可以调用其他存储过程？为什么？

答：可以。分为普通调用和带返回值/输出参数调用

3.Mysql主要包括哪些数据类型？

数值型 字符串型 日期时间型

4.请分析比较Mysql存储过程和函数

维度	存储过程（Stored Procedure）	函数（Function / 自定义函数）
核心定位	封装 "一系列操作"（增删改查、调用其他过程），侧重流程执行	封装 "计算逻辑"（输入参数→输出单个值），侧重数据计算 / 返回
返回值规则	无强制返回值；可通过 OUT/INOUT 参数返回多个值；无 RETURN 语句（仅能 LEAVE 退出）	必须有且仅有一个返回值（通过 RETURN 语句）；不支持 OUT/INOUT 参数
调用方式	必须用 CALL 关键字调用（CALL 过程名(参数)）；不能嵌入 SELECT 等查询语句	可直接作为表达式调用（如 SELECT 函数名(参数)）；可嵌入 WHERE/ORDER BY 等子句
参数类型	支持 IN（输入）、OUT（输出）、INOUT（输入输出）三种	仅支持 IN 类型（即使省略，默认也是 IN）
适用操作	支持所有 SQL 操作（DML/DDL/DCL）；可执行事务、调用其他过程 / 函数	仅支持只读操作（默认）；禁止执行 DDL（如 CREATE TABLE）、事务；仅能做计算 / 查询
异常处理	支持复杂异常捕获（DECLARE HANDLER）；可主动抛出错误（SIGNAL）	异常处理能力弱；抛出错误会直接中断调用语句
使用场景	复杂业务流程（如订单创建、库存扣减）、批量操作、多步骤逻辑	数据计算（如金额换算、日期差计算）、字段值转换（如状态码转文字）、查询条件封装

5.设计一个存储过程，根据学号返回学生的学分，注意，成绩在60分以上才有学分

一、需求分析

核心逻辑：

1. 输入参数：学号（学生唯一标识）；
2. 核心规则：成绩≥60 分的课程，才累加对应学分；
3. 输出结果：该学生的总学分（无符合条件课程时返回 0）。

二、前提表结构（需先创建 / 确认以下表）

-- 1. 学生表（基础信息）
CREATE TABLE students (
    student_id INT PRIMARY KEY COMMENT '学号',
    student_name VARCHAR(50) NOT NULL COMMENT '姓名'
);

-- 2. 课程表（存储课程学分）
CREATE TABLE courses (
    course_id INT PRIMARY KEY COMMENT '课程ID',
    course_name VARCHAR(50) NOT NULL COMMENT '课程名',
    credit FLOAT NOT NULL COMMENT '课程学分'
);

-- 3. 成绩表（关联学生、课程、成绩）
CREATE TABLE scores (
    student_id INT COMMENT '学号',
    course_id INT COMMENT '课程ID',
    score FLOAT NOT NULL COMMENT '成绩',
    PRIMARY KEY (student_id, course_id), -- 复合主键：一个学生一门课仅一条记录
    FOREIGN KEY (student_id) REFERENCES students(student_id),
    FOREIGN KEY (course_id) REFERENCES courses(course_id)
);

三、存储过程实现

DELIMITER // -- 临时修改语句结束符（避免;冲突）

-- 存储过程：根据学号计算学生有效总学分
CREATE PROCEDURE get_student_credit(
    IN in_student_id INT,        -- 输入参数：学号
    OUT out_total_credit FLOAT   -- 输出参数：总学分（60分以上课程累加）
)
BEGIN
    -- 步骤1：初始化总学分为0（避免NULL值）
    SET out_total_credit = 0.0;

    -- 步骤2：校验学号是否存在（可选，增强鲁棒性）
    IF NOT EXISTS (SELECT 1 FROM students WHERE student_id = in_student_id) THEN
        SET out_total_credit = -1; -- 用-1标记学号不存在，便于调用方识别
        LEAVE; -- 退出存储过程
    END IF;

    -- 步骤3：累加60分以上课程的学分
    SELECT SUM(c.credit) INTO out_total_credit
    FROM scores s
    JOIN courses c ON s.course_id = c.course_id
    WHERE s.student_id = in_student_id -- 匹配指定学号
      AND s.score >= 60; -- 仅统计成绩≥60分的课程

    -- 步骤4：处理无有效课程的情况（SUM无结果时会返回NULL，需重置为0）
    IF out_total_credit IS NULL THEN
        SET out_total_credit = 0.0;
    END IF;
END //

DELIMITER ; -- 恢复默认结束符

四、关键逻辑说明

1. 参数设计 ：
   • IN in_student_id：接收外部传入的学号；
   • OUT out_total_credit：返回计算后的总学分（-1 = 学号不存在，0 = 无有效学分，>0 = 有效总学分）。
2. 学号校验 ：通过 EXISTS 判断学号是否存在，避免统计不存在学生的学分；
3. 学分累加 ：通过 JOIN 关联成绩表和课程表，仅筛选 score ≥ 60 的记录，用 SUM(c.credit) 累加学分；
4. NULL 值处理 ：若学生无 60 分以上课程，SUM 会返回 NULL，需重置为 0，保证返回值始终是数值。

五、测试示例

插入测试数据

-- 插入学生
INSERT INTO students VALUES (1001, '张三'), (1002, '李四');

-- 插入课程（课程ID/名称/学分）
INSERT INTO courses VALUES 
(1, 'MySQL数据库', 3.0),
(2, 'Java编程', 4.0),
(3, 'Python基础', 2.5);

-- 插入成绩
INSERT INTO scores VALUES 
(1001, 1, 85),  -- 张三：MySQL 85分（有效，3学分）
(1001, 2, 58),  -- 张三：Java 58分（无效）
(1001, 3, 90),  -- 张三：Python 90分（有效，2.5学分）
(1002, 1, 55);  -- 李四：MySQL 55分（无效）

调用存储过程

-- 测试1：查询张三（学号1001）的学分
CALL get_student_credit(1001, @total_credit);
SELECT @total_credit AS 张三总学分; -- 结果：5.5（3+2.5）

-- 测试2：查询李四（学号1002）的学分
CALL get_student_credit(1002, @total_credit);
SELECT @total_credit AS 李四总学分; -- 结果：0.0

-- 测试3：查询不存在的学号（1003）
CALL get_student_credit(1003, @total_credit);
SELECT @total_credit AS 无效学号学分; -- 结果：-1

六、扩展优化（可选）

1. 增加异常处理：捕获查询过程中的异常（如表不存在、权限不足）；
2. 支持批量查询：若需批量计算多个学生学分，可增加循环逻辑；
3. 返回明细：新增输出参数，返回学生的有效课程列表（如用 JSON 格式）。

七、核心注意事项

1. 确保 scores 表和 courses 表的关联字段（course_id）正确，避免关联错误导致学分计算偏差；
2. 成绩字段（score）建议用 FLOAT/DECIMAL 类型，兼容小数成绩（如 60.5 分）；
3. 调用存储过程时，输出参数需用用户变量（如 @total_credit）接收，无法直接返回结果。

1.简述数据库安全性控制的常用方法和技术

身份认证技术：账户与密码认证；多因素认证（短信验证，U盾）；主机/IP绑定

权限控制技术：基于角色的访问控制；颗粒化权限分配；权限回收与审计

数据保护技术：传输加密；存储加密；数据脱敏

审计与监控技术：操作日志审计：异常监控；

攻击防御技术：SQL注入防御；拒绝服务防御；漏洞修复

灾备与恢复技术：定期备份；容灾部署；应急恢复

2.简述数据库安全性控制的常用方法和技术

GRANT	为用户 / 角色分配数据库操作权限	核心 DCL，所有关系型数据库支持
REVOKE	回收已分配给用户 / 角色的权限	核心 DCL，与GRANT配套使用
CREATE USER	创建数据库用户账户	扩展 DCL，管理访问主体
DROP USER	删除数据库用户账户	扩展 DCL，清理无用账户
ALTER USER	修改用户属性（如密码）	扩展 DCL，维护用户信息
COMMIT/ROLLBACK	提交 / 回滚事务	事务控制（TCL），常与 DCL 联动保障权限操作一致性

3.请说明数据库审计的重要性

数据库审计是对数据库所有操作行为进行全程记录，监控，分析和追溯的核心安全功能

特性为：全量覆盖；不可篡改；多维度记录；可追溯性；实时性

重要性：故障排查；权限管控优化；合规性满足；安全事件溯源

4.使用Mysql数据库管理系统，创建多个新用户，并对这些用户进行管理，分配相应的数据库操作权限

本次操作将完整演示 创建新用户、分配精细化权限、权限查询、权限回收、用户属性修改、删除用户 全流程，遵循 "最小权限原则"，适配实际生产场景的安全规范（以 MySQL 8.0 为例，兼容 5.7 版本）。

前置准备

1. 登录 MySQL 管理员账户（如 root）：

mysql -u root -p
# 输入root密码后进入MySQL命令行

1. （可选）创建测试数据库 / 表（用于权限分配验证）：

-- 创建测试库
CREATE DATABASE IF NOT EXISTS school;
USE school;
-- 创建学生表
CREATE TABLE IF NOT EXISTS students (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) NOT NULL,
    age INT,
    score FLOAT,
    id_card VARCHAR(18) -- 敏感字段：身份证号
);
-- 创建成绩表
CREATE TABLE IF NOT EXISTS scores (
    stu_id INT,
    course VARCHAR(50),
    score FLOAT,
    FOREIGN KEY (stu_id) REFERENCES students(id)
);

一、创建新用户

CREATE USER '用户名'@'访问主机' IDENTIFIED BY '密码';

• 访问主机：localhost（仅本地访问）、%（任意主机）、具体 IP（如 192.168.1.100）、网段（如 192.168.1.%）；
• 密码要求：强密码（长度≥8，含大小写、数字、特殊字符），避免弱密码。

实操示例（创建 3 类典型用户）

-- 1. 只读用户：仅允许本地访问，用于业务查询
CREATE USER 'read_user'@'localhost' IDENTIFIED BY 'Read@123456';

-- 2. 业务操作用户：允许192.168.1.0/24网段访问，可增删改查
CREATE USER 'oper_user'@'192.168.1.%' IDENTIFIED BY 'Oper@654321';

-- 3. 管理员用户：仅本地访问，拥有测试库全权限
CREATE USER 'admin_user'@'localhost' IDENTIFIED BY 'Admin@987654';

-- 4. 临时用户：允许任意主机访问（测试用，生产环境禁止）
CREATE USER 'temp_user'@'%' IDENTIFIED BY 'Temp@111222';

二、分配数据库操作权限

GRANT 权限列表 ON 数据对象 TO '用户名'@'访问主机';
-- 刷新权限缓存（低版本MySQL需执行）
FLUSH PRIVILEGES;

权限类型说明

权限分类	常用权限	适用场景
数据操作	SELECT、INSERT、UPDATE、DELETE	业务层操作
结构操作	CREATE、ALTER、DROP	表结构维护
管理权限	ALL PRIVILEGES、GRANT OPTION	管理员
特殊权限	LOCK TABLES、EXECUTE	锁表、执行存储过程

实操示例（精细化权限分配）

1. 给只读用户分配查询权限

-- 仅允许read_user查询school库下所有表，且仅能查看非敏感字段
GRANT SELECT (id, name, age, score) ON school.students TO 'read_user'@'localhost';
GRANT SELECT ON school.scores TO 'read_user'@'localhost';
-- 禁止访问身份证号等敏感字段，无需显式配置（默认无权限）

2. 给业务用户分配操作权限

-- oper_user可对school库下students表执行增/改/查，仅允许删除scores表数据
GRANT SELECT, INSERT, UPDATE ON school.students TO 'oper_user'@'192.168.1.%';
GRANT SELECT, DELETE ON school.scores TO 'oper_user'@'192.168.1.%';
-- 禁止删除students表、修改表结构（最小权限原则）

3. 给管理员用户分配全权限

-- admin_user拥有school库所有表的全部操作权限
GRANT ALL PRIVILEGES ON school.* TO 'admin_user'@'localhost';
-- 允许管理员给其他用户分配权限（可选）
GRANT GRANT OPTION ON school.* TO 'admin_user'@'localhost';

4. 给临时用户分配临时权限

-- temp_user仅允许查询所有库的表，无修改权限（测试完成后立即回收）
GRANT SELECT ON *.* TO 'temp_user'@'%';

三、用户权限管理与验证

1. 查询用户权限

-- 查看指定用户的权限
SHOW GRANTS FOR 'read_user'@'localhost';
SHOW GRANTS FOR 'oper_user'@'192.168.1.%';

-- 查看当前登录用户的权限
SHOW GRANTS;

-- 查看所有数据库用户（含主机）
SELECT user, host FROM mysql.user;

2. 验证权限（以 read_user 为例）

# 退出root，登录read_user
exit
mysql -u read_user -p
# 输入密码Read@123456

# 验证查询权限（可执行）
SELECT id, name FROM school.students;
# 验证插入权限（无权限，报错）
INSERT INTO school.students (name, age) VALUES ('张三', 20);
# 验证访问敏感字段（无权限，报错）
SELECT id_card FROM school.students;

3. 修改用户属性

-- 重置oper_user的密码
ALTER USER 'oper_user'@'192.168.1.%' IDENTIFIED BY 'NewOper@654321';

-- 锁定临时用户（禁止登录）
ALTER USER 'temp_user'@'%' ACCOUNT LOCK;

-- 解锁临时用户（恢复登录）
ALTER USER 'temp_user'@'%' ACCOUNT UNLOCK;

-- 修改用户访问主机（将temp_user限制为仅本地访问）
RENAME USER 'temp_user'@'%' TO 'temp_user'@'localhost';

4. 回收用户权限

-- 回收temp_user的全局查询权限
REVOKE SELECT ON *.* FROM 'temp_user'@'localhost';

-- 回收oper_user的删除权限（禁止删除scores表数据）
REVOKE DELETE ON school.scores FROM 'oper_user'@'192.168.1.%';

-- 回收管理员的权限分配权限
REVOKE GRANT OPTION ON school.* FROM 'admin_user'@'localhost';

5. 删除无用用户

-- 删除临时用户
DROP USER 'temp_user'@'localhost';

-- 删除只读用户（若无需使用）
DROP USER 'read_user'@'localhost';

四、关键注意事项

1. 最小权限原则 ：仅授予用户完成工作所需的最低权限（如业务用户禁止分配DROP/ALTER权限）；
2. 安全加固 ：
   • 禁止root用户远程访问（仅保留root@localhost）；
   • 定期修改用户密码，删除离职 / 无用用户；
   • 避免使用%（任意主机），生产环境限制为具体 IP / 网段；
3. 权限生效 ：MySQL 8.0 无需手动执行FLUSH PRIVILEGES（权限即时生效），5.7 版本需执行；
4. 审计日志 ：开启审计功能记录权限变更（如general_log），便于追溯权限操作。

五、常见问题排查

1. 用户登录失败 ：
   • 检查用户名 / 主机是否匹配（如oper_user仅允许 192.168.1.% 访问，从 192.168.2.100 登录会失败）；
   • 检查密码是否正确，或用户是否被锁定（ACCOUNT LOCK）；
2. 权限不生效 ：
   • 确认权限分配的对象是否正确（如school.students而非school.*）；
   • 退出重登用户（权限变更需重新建立会话）；
3. 敏感字段访问 ：
   • 列级权限需显式指定允许访问的字段，未指定则默认无权限。

1.数据库完整性和数据库安全性的概念有什么区别和联系

数据库完整性：数据的正确性，一次性，有效性

数据库安全性：保护数据库免受未授权的访问使用修改泄露破坏

对比维度	数据库完整性	数据库安全性
核心目标	保证数据本身的正确性、一致性、有效性（数据质量）	保证数据的访问安全，防止非法 / 越权操作（访问控制）
保护对象	数据的 "内容"（是否符合规则）	数据的 "访问权限"（谁能操作、如何操作）
威胁来源	合法用户的误操作（如输入无效值）、系统故障导致数据不一致	非法用户的恶意攻击（如 SQL 注入、破解密码）、合法用户的越权操作
关注重点	数据是否 "对"（语义 / 规则层面）	操作是否 "合法"（权限 / 身份层面）
实现手段	约束（主键、外键、唯一、检查约束）、触发器、存储过程	身份认证、权限控制（GRANT/REVOKE）、加密、审计、防火墙
失败后果	数据错误、矛盾（如成绩为 - 10、订单关联不存在的用户）	数据泄露、篡改、删除（如黑客窃取用户信息、越权删除订单）

联系：都是为了保障数据库可靠运行；相互依赖缺一不可；实现手段相互配合

2.Mysql是如何实现实体完整性约束的

实体完整性是三大完整性约束的核心，主要通过PRIMARY KEY,UNIQUE,AUTO_INCREMENT（自增列）实现的

3.数据库完整性约束条件可分为哪几类

实体完整性；参照完整性；域完整性；用户自定义完整性

4.数据库管理系统的完整性控制机制应具有哪三个方面的功能？

定义；检查；违约处理

5.简述mysqlDBMS的完整性控制策略

围绕 约束定义----校验执行---违约处理 为核心，结合自身引擎特性，通过内置约束，扩展工具和引擎级强制执行，实现对实体，参照，域，用户自定义四类完整性的全维度管控

1.简述事务的概念和特性

概念：一组不可分割的数据库操作序列

特性（ACID特性）：原子性；一致性；隔离性；持久性

2.并发执行可能产生的问题：

丢失数据修改；

读脏数据

不可重复读

产生幽灵数据

3.简述不同级别封锁协议的要求

一级封锁协议：对事务T要修改的数据加X锁，直到事务结束才释放，可以防止丢失修改，并保证T是可恢复的

二级封锁协议：在一级封锁协议的基础上加上事务T对要读取的数据加S锁，读完后即释放S锁。

也就是说，对要修改的是数据加X锁，直到事务结束才释放X

​ 对要读取的数据必须加S锁，读完后即可释放S锁

防止丢失修改，防止读脏数据

三级封锁协议：对要读取的数据必须加上S锁，对要修改的数据必须加X锁，直到事务结束后才释放所有的锁。

防止丢失修改，防止读脏数据，防止不可重复读

3.简述活锁死锁产生原因和预防方法

活锁：事务持续尝试获取资源，但因调度策略或其他事务的抢占，始终无法获得资源，处于等待状态

预防：采用先来先服务的策略，指多个事务请求封锁同一数据对象时，按请求封锁的先后次序对这些事务排队，该数据对象上的锁一旦释放，首先批准申请队列中第一个事务获得锁

死锁：两个或多个事务互相持有对方所需的资源，且均不释放已占资源，导致所有事务永久阻塞，无法继续执行

预防：一次封锁法：要求每个事务必须一次将所有要使用的数据全部加锁，否则不能执行

​ 顺序封锁：要求预先对数据对象规定一个封锁顺序，所有事务按顺序封锁。

解除：超时法；等待图法

4.并发调度可串行化：如果多个事务在某个调度策略下的执行结果与这些事务在某个串行调度策略下的执行结果相同

遵守两段锁协议是可串行化调度的充分条件而非必要条件。遵守两段锁协议一定可串行化，反之不然

5.

1）查询姓名为王梅的所有科目的考试成绩，保存到历史成绩表

2)删除王美的所有科目的考试成绩

3）查询学生表S中姓名为王美的记录，保存到历史学生表

4）删除学生表S中姓名为王美的记录

5）提交事务，查看各表数据变化

6）回滚事务，查看各表数据变化

-- 开启事务

START TRANSACTION;

-- (1) 查询姓名为"王美"的所有科目的考试成绩，保存到历史成绩表history-grade

INSERT INTO history-grade (sno, cno, grade)

SELECT sc.sno, sc.cno, sc.grade

FROM sc

JOIN S ON sc.sno = S.sno

WHERE S.sname = '王美';

-- (2) 删除"王美"的所有科目的考试成绩

DELETE sc

FROM sc

JOIN S ON sc.sno = S.sno

WHERE S.sname = '王美';

-- (3) 查询学生表S中姓名为"王美"的记录，保存到历史学生表history-student

INSERT INTO history-student (sno, sname, ...) -- 补充学生表其他字段

SELECT sno, sname, ... -- 与history-student字段对应

FROM S

WHERE sname = '王美';

-- (4) 删除学生表S中姓名为"王美"的记录

DELETE FROM S

WHERE sname = '王美';

-- (5) 提交事务，查看各表中数据的变化

COMMIT;

-- (6) 回滚事务（需先重新执行步骤1-4，再执行ROLLBACK）

-- 重新开启事务执行步骤1-4后，执行：

-- ROLLBACK;

1.码：键，关键字

全码：关系模式所有属性组是这个关系模式的候选码

主码：若一个关系有多个候选码，则选定其中一个作为主码

主属性：候选码的属性

2.关系中没有行序的原因是 关系是集合，集合中的元素无序

3.关系的并 交 差 操作要求两个关系具有相同的关系模式

关系模式的定义：对关系的描述，关系模式是型 关系是值，形象化定义为

R(U,D,dom,F)

关系（属性，域，域映射，函数依赖集）

4.关系操作的特点：集合操作方式

5.关系的名称和它的属性列表称为关系的模式

6.关系性质：

列是同质的；不同的列可出自同一个域，每一列称为一个属性，不同属性要给与不同的属性名；列的顺序无所谓；任意两个元组的候选码不能相同；行的顺序无所谓；分量必须取原子值，每一个分量都是不可再分的数据项

7.关系运算：

传统的集合运算：并 交 差 笛卡尔积

专门的关系运算：选择 连接 投影 除

8.关系的五种基本运算：选择 投影 并 差 笛卡尔积

9.等值连接和自然连接

联系：自然连接是一种特殊的等值连接

区别：等值连接的等值条件是任意属性间的相等，而自然连接要求两个关系中同名属性进行等值连接；

​ 等值连接会保留连接后的所有属性，而自然连接会去重

10.关系模型的完整性规则包括？

实体完整性：要求关系的主码中属性值不能是空值

参照完整性：要求外码的值要么为空值，要么等于被参照关系中某个元组的主码值

用户定义的完整性：根据具体需求设定的约束条件

11.外码在什么情况下允许取空值？什么情况不允许？

允许：当外码所表示的联系是可选的，即该属性并非必须关联到被参照关系的元组时

比如 学生的导师编号是外码，暂未分配导师，该字段可空

不允许：当外码所表示的联系是必须的，即该属性必须关联到被参照关系的元组时

比如 学生的系编号是外码，学生必须属于某个系，因此该字段不能为空

1.简述数据库系统中的主要故障和恢复策略

故障种类：

事务内部故障；系统故障；戒指故障；计算机病毒

恢复技术：

数据库转储法（静态转储和动态转储/海量转储和增量转储）；日志文件法（以记录为单位的日志文件/以数据块为单位的日志文件）

恢复策略：

事务故障的恢复：反向扫描日志文件，查找该事务的更新操作；

​ 对该事务的更新操作进行逆操作

​ 继续反向扫描日志文件，擦护照该事务的其他更新操作，做同样处理

​ 循环，直到此事务的开始标记

系统故障的恢复：正向扫描日志文件，产生重做和撤销队列

​ 对撤销队列事务进行撤销处理

​ 对重做队列事务进行重做处理

介质故障的恢复：装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态

​ 装入有关的日志文件副本，重做已完成的事务

2.数据库镜像的优缺点

优点：数据库镜像提供完整或接近完整的数据冗余，增强保护功能；发生故障时，快速使用数据库备用副本提供服务，使数据不会丢失，提高数据的可用性；提高数据库系统在升级期间的可用性

缺点：需要频繁的复制数据自然会降低系统运行效率

3.为什么要先写日志文件

保障数据可靠性额，事务持久性和故障恢复能力的核心设计原则，避免数据丢失和事务不一致，保证数据修改的原子性和一致性，优化磁盘IO性能，支持崩溃恢复和数据回滚；避免脏写和数据破坏

总结：

：以 "顺序 IO 的低开销" 换取 "数据的高可靠性"，同时保障事务的 ACID 特性，兼顾性能与数据安全。

4.登记日志文件的原则是什么？

先写日志后写数据；

日志记录的原子性原则

日志记录的持久性原则

日志记录的完整性原则

日志记录的顺序性原则

事务隔离的日志隔离原则

5.数据库恢复机制的问题在于？

恢复效率低下，业务中断时间长；

数据一致性风险无法消除；

资源开销巨大，影响正常业务；

场景覆盖不足，应对极端故障能力有限；

运维复杂度高，人为失误风险大

1.在mysql中可以授予的权限有哪几组？

全局权限组：

GRANT 权限 ON . TO '用户'@'主机';

数据库权限组：

GRANT 权限 ON 数据库名.* TO '用户'@'主机';

表权限组：

GRANT 权限 ON 数据库名.表名 TO '用户'@'主机';

列权限组：

GRANT 权限 (列1, 列2) ON 数据库名.表名 TO '用户'@'主机';

存储程序权限组：

GRANT 权限 ON 数据库名.存储过程名 TO '用户'@'主机';

权限管理组：

2.在MySQL的权限授权语句中，可用于指定权限级别的值有哪几类格式？

权限级别格式	作用范围	适用场景	示例
*.*	所有数据库的所有对象	全局权限（管理员专用）	GRANT SUPER ON *.* TO 'dba'@'%'
数据库名.*	指定数据库的所有表 / 程序	数据库级权限（库管理员）	GRANT CREATE ON school.* TO 'admin'@'localhost'
数据库名.表名	指定数据库的指定表	表级权限（业务用户）	GRANT SELECT ON school.students TO 'oper'@'%'
数据库名.表名(列)	指定数据库表的指定列	列级权限（敏感字段管控）	GRANT SELECT(id,name) ON school.students TO 'read'@'%'
数据库名.程序名	指定数据库的存储过程 / 函数	存储程序级权限（程序执行）	GRANT EXECUTE ON school.proc_get_score TO 'proc'@'%'

3.为什么在Mysql中需进行数据库的备份和恢复操作？

在出现硬件损坏或非人为因素而导致数据丢失时，可以使用备份恢复数据，从而将损失降低到最小程度

4.数据库备份方式？

热备份：可以在数据库运行中直接进行备份

​ 逻辑备份：备份出的文件内容可读，一般是文本内容。

​ 裸文件备份：复制数据库的物理文件

冷备份：必须在数据库停止情况下进行备份，数据库的读写操作不能执行

温备份：在数据库运行中进行，仅支持读不支持写

完全备份：对数据库进行一个完整的备份】

部分备份：

​ 增量备份

​ 差异备份

数据库恢复方式：

mysql - u username - p [dbname] <filename.sql>

5.二进制日志文件用途：

数据恢复；

主从复制；

数据同步/迁移

审计与合规检查

增量备份

数据一致性验证

1.数据库系统的数据抽象级别？

物理级别；对应于内模式，反应数据库在物理存储方面的信息

逻辑级别；对应于逻辑模式，反应数据库中全部数据的整体逻辑结构的信息

视图级别；对应于外模式，反应用户与数据库系统的接口信息

2.数据建模的主要阶段：

概念建模阶段：客户交流，理解需求，形成实体工作

逻辑建模阶段：对实体进行细化，同时丰富表结构

物理建模阶段：将逻辑建模阶段创建的各种数据库对象生成为对应的sql的代码，运行后创建相应具体数据库对象

3.实体-联系模型主要由 实体，属性，联系三部分组成

设计原则：尽量减小实体，能作为属性就不要作为实体。同时属性不能再具有需要描述的性质，必须是不可分割的数据项，不能包括其他属性。属性不能再与其他实体具有联系。在E-R图的所

有联系必须是实体间的联系，而不能有属性与实体的联系。

1.关系模式的形式化定义是指关系模式由五部分组成R(U,D,DOM,F)

R:关系名

U：组成该关系的属性名集合

D：U中属性所来自的域

DOM：属性向域的映像集合

F：属性间数据的依赖关系集合

平凡函数依赖：一个属性能决定的属性，本身就包含在这个属性组里

• （学号，姓名）→ 姓名："姓名" 本来就在左边的（学号，姓名）里，左边一定能决定右边，这就是平凡的。
• 学号 → 学号：自己决定自己，也是平凡函数依赖。

非平凡函数依赖：一个属性能决定的属性，不在这个属性组里

• 学号 → 姓名："姓名" 不在左边的 "学号" 里，学号能唯一确定姓名，这就是非平凡的。
• （学号，课程号）→ 成绩："成绩" 不在左边的（学号，课程号）里，这也是非平凡的。

总结：

• 平凡：右边属性是左边的 "子集"（自己推自己）；
• 非平凡：右边属性和左边 "没关系"（A 推 B，B 不在 A 里）。

完全函数依赖：

如果一个属性组（比如 A+B）能决定某个属性（比如 C），但单独去掉属性组里任何一个属性（只留 A，或只留 B），都没法决定 C，就是完全函数依赖。👉 例子：（学号，课程号）→ 成绩：

• 只拿 "学号"，没法确定某一门课的成绩（一个学生有多门课）；
• 只拿 "课程号"，没法确定是哪个学生的成绩（一门课有多个学生）；
• 必须学号 + 课程号一起，才能唯一确定成绩 → 成绩完全依赖于（学号，课程号）。

部分函数依赖：

如果一个属性组（比如 A+B）能决定某个属性（比如 C），但去掉属性组里某一个属性后，剩下的属性依然能决定 C，就是部分函数依赖（"部分" 就是指只用属性组里的一部分就够了）。👉 例子：（学号，课程号）→ 姓名：

• 哪怕去掉 "课程号"，只拿 "学号"，也能唯一确定姓名；
• 课程号在这组里是 "多余的" → 姓名部分依赖于（学号，课程号）。

第一范式：

如果一个关系模式R的所有属性都是不可分的基本数据项

第二范式：

满足第一范式前提下，每一个非主属性都完全函数依赖于主码

第三范式：

满足第二范式前提下，每一个非主属性不传递函数依赖于主码

BC范式：

当且仅当关系中的每个函数依赖的决定因子都是候选码时。满足BCNF一定时是3NF，反之不一定。

2.规范化过程：

1.判断是否为1NF

2.确定函数依赖关系

3.分析该关系模式是否存在问题

4.模式分解为2NF

5.模式分解为3NF

3.模式分解的基本要求：

分解具有无损连接性；

分解要保持函数依赖；

分解既要保持函数依赖，又要具有无损连接性

1.数据库设计分为六个阶段：（书p261）

2.概念结构设计的特点和策略

真实充分的反应现实世界

易于理解；

易于更改；

易于向关系，网状，层次等各种数据模式转换

3.E-R向关系模式转换原则：

实体型的转换；

实体型间的联系的转换；