数据库系统 课程实验2
数据库安全性/完整性定义与检查
计科210X 甘晴void 202108010XXX
目录
文章目录
- 数据库系统 课程实验2<br>数据库安全性/完整性定义与检查
- 实验目的
- 实验环境
- 实验内容
- 2.1数据库安全性
- 2.1.1 自主存取控制实验
- 1）实验内容与要求
- 2）实验重难点
- 3）实验过程
- ①预先准备
- ②创建两个部门经理用户并授予创建用户的权限
- ③给予部门经理用户其他权限
- ★激活角色
- ④使用部门经理创建员工用户
- ⑤验证员工用户权限
- ⑥收回员工查看的权限，并验证
- 2.1.2 审计实验
- 1）实验内容与要求
- 2）实验重难点
- 3）实验过程
- ①首先查看审计配置情况：
- ②开启日志
- ③验证审计
- ④关闭日志
- 2.2数据库完整性
- 2.2.1 实体完整性实验
- 1）实验内容与要求
- 2）实验重难点
- 3）实验过程
- ①创建新数据库HNUT2
- ②创建表时定义完整性并验证
- ③创建表之后定义并验证
- ④删除实体完整性并验证
- 2.2.2 参照完整性实验
- 1）实验内容与要求
- 2）实验重难点
- 3）实验过程
- ①创建表时定义参照完整性+验证
- ②创建表后定义参照完整性
- ③定义参照完整性的违约处理
- ④删除参照完整性
- 2.2.3 用户自定义完整性实验
- 1）实验内容与要求
- 2）实验重难点
- 3）实验过程
- ①建立完整性约束
- ②验证完整性约束
- ③删除完整性约束并验证
- 2.3 触发器实验
- 1）实验内容与要求
- 2）实验重难点
- 3）示例
- ①创建触发器（以BEFORE为例）
- ★mysql关于触发器的语法区别
- ②验证触发器（以BEFORE为例）
- ③验证触发器执行顺序
- ④删除触发器
- 实验感悟
实验目的
1）熟悉通过 SQL 对数据库进行安全性控制的方法，其中包括自主存取控制实验和审计实验。
2）熟悉通过 SQL 对数据库进行完整性控制的方法，其中包括实体完整性、参照完整性、用户自定义完整性。
3）熟悉并掌握数据库触发器的设计和使用方法。
实验环境
DBMS：8.0.33 MySQL Community Server - GPL
可视化：Navicat Premium 16.1.6
命令行：Navicat自带命令列
命令行：由Microsoft商店提供的windows终端(version=1.18.2822.0)启动的windows powershell命令行（这个主要是在安全性实验中登录FINANCE用户和U1用户时使用，Navicat自带命令行默认以root登录，不方便这样操作）
实验内容
2.1数据库安全性
2.1.1 自主存取控制实验
1）实验内容与要求
定义用户、角色，分配权限给用户、角色，回收权限，以相应的用户名登录数据库验证权限分配是否正确。选择一个应用场景，使用自主存取控制机制设计权限分配。可以采用两种方案：
方案一：采用 SYSTEM 超级用户登录数据库，完成所有权限分配工作，然后用相应用户名登陆数据库以验证权限分配正确性；
方案二：采用 SYSTEM 用户登陆数据库创建两个部门经理用户，并分配相应的权限，然后分别用两个经理用户名登陆数据库，创建相应部门的 USER, ROLE，并分配相应权限。验证权限分配之前，请备份好数据库；针对不同用户所具有的权限，分别设计相应的 SQL语句加以验证。
【注意】这两种方式是参考文档提供给我们的，不一定需要照抄方案。
我准备采用自己的方案来进行操作。
2）实验重难点
定义角色，分配权限和回收权限，实现权限的再分配与回收。
3）实验过程
我们实验题目提供的示例。过程如下
①预先准备
创建数据库 TEST_COMPANY，包含 salary 工资表、employee 员工表。
根据题目提供的参考示例
构建好数据库和相应的数据集
整体思路：
使用 SYSTEM 超级用户登录数据库创建两个部门经理用户，分配相应权限，然后使用经理用户名登录数据库创建相应部门的 USER、ROLE，分配相应权限。
- 创建用户财务部经理FINANCE和人事部经理HR
- 用户FINANCE管理工资表，拥有查询、删除、修改工资的权限
- 用户HR管理员工表，拥有删除员工、添加员工、更新员工信息的权限
②创建两个部门经理用户并授予创建用户的权限
先创建两个用户并给与他们创建用户的权限。
mysql> CREATE USER 'FINANCE'@'%' IDENTIFIED BY '111111';
Query OK, 0 rows affected (0.01 sec)
mysql> GRANT CREATE USER ON *.* TO 'FINANCE'@'%';
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE USER 'HR'@'%' IDENTIFIED BY '222222';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT CREATE USER ON *.* TO 'HR'@'%';
Query OK, 0 rows affected (0.00 sec)
此时这两个用户只有创建用户的权限，如果它们想查看表，甚至访问数据库都会报错。
mysql> USE TEST_COMPANY
ERROR 1044 (42000): Access denied for user 'FINANCE'@'%' to database 'test_company'
③给予部门经理用户其他权限
Ⅰ 给予两位部门经理用户更新相应表的权限。创建两个角色，然后给这两个角色分别赋予其对应的权限，并将角色权限给用户，同时加上 with grant option 选项，方便其用户赋予员工查询权限。然后将这两个角色赋予部门经理。
CREATE ROLE FIN_ROLE;
GRANT SELECT,DELETE,UPDATE,INSERT ON TABLE SALARY TO FIN_ROLE WITH GRANT OPTION;
GRANT FIN_ROLE TO FINANCE WITH ADMIN OPTION;
CREATE ROLE HR_ROLE;
GRANT SELECT,DELETE,UPDATE,INSERT ON TABLE EMPLOYEE TO HR_ROLE;
GRANT HR_ROLE TO HR WITH ADMIN OPTION;
Ⅱ 这样子仍然会出现问题，两位部门进入数据库还会受到阻拦，即使使用navicat可视化查看其权限，仍然显示不具备该权限。
经杨老师提醒，问题在于GRANT XXX ON TABLE时，具体的TABLE并没有指定该表所在的数据库，因此是失败的。我们需要在授权的同时指定其表所在的数据库，如TEST_COMPANY.SALARY。
Ⅲ 结果仍然发现ROLE上被赋予的权限并没有到达FINANCE上，说明这可能不是主要的问题。
★经过刘lq同学提醒，这个主要问题在于mysql与课本内容的一个区别：激活角色。
★激活角色
一个角色被创造出来并被赋予用户之后，事实上用户并没有立刻获得这个“角色”的权限，因为该角色并没有被激活。只有角色被激活，该用户才能够成功“扮演”这个角色。其实这也是为了提升安全性。
使用
SELECT CURRENT_ROLE();
可以查看当前已经被激活的角色。
有两种激活角色的方法：
#非永久激活
set default role all to FINANCE@'%';
#永久激活
SET global activate_all_roles_on_login=ON;
#由于mysql默认禁止了角色自动激活，我们修改这个系统变量可以将其调整为允许角色自动激活，从此一劳永逸解决这个问题。
我们可以采取第一种方式
然后退出该命令行，以FINANCE的身份进入mysql数据库（这里我使用win提供的shell终端进行操作）
现在可以发现该部门经理FINANCE获得了该角色。
Ⅳ 接下来重新对该角色进行授权，授权会自动转交到FINANCE上。
GRANT FIN_ROLE TO FINANCE WITH ADMIN OPTION;
现在该部门经理再请求进入数据库，就不会受到阻拦了。
mysql> use test_company
Database changed
mysql>
Ⅴ 但是这还是有点烦，不能一劳永逸解决问题，所以采用修改系统变量永久激活角色自动激活的功能。
SET global activate_all_roles_on_login=ON;
之后应该就不会再遇到这种问题了。
④使用部门经理创建员工用户
在 FINANCE 财务部经理下创建员工用户，给与查询权限：
CREATE USER U1 IDENTIFIED BY "111111";
GRANT SELECT ON TABLE SALARY TO U1;
这创建了一个员工U1，并有SELECT权限。
接下来进行验证。
⑤验证员工用户权限
验证如下：
重新开启另一个终端，使用用户U1登录
use test_company;
select * from salary;
INSERT INTO SALARY VALUES('甘晴',3000);
运行截图如下：
可以看到用户 U1 仅有查询权限，不具有修改权限。完全符合预期。
⑥收回员工查看的权限，并验证
使用FINANCE登录sql并收回员工U1的权限
REVOKE SELECT ON SALARY FROM U1;
收回权限后，使用U1登录sql试图查询工资，被拒绝。
如下：
2.1.2 审计实验
1）实验内容与要求
掌握数据库审计的设置和管理方法，以便监控数据库操作，维护数据库安全。打开数据库审计开关，以具有审计权限的用户登录数据库，设置审计权限，然后以普通用户登录数据库，执行相应的 SQL 语句，验证审计设置是否有效，最后再以具有审计权限的用户登录数据库，查看是否存在相应的审计信息。
2）实验重难点
合理的设置各种审计信息，一方面，为了保护系统重要的敏感数据，需要系统地设置各种审计信息，不能留有漏洞，以便随时监督系统使用情况，一旦出现问题，也便于追查;另一方面，审计信息设置过多，会严重影响数据库的使用性能，因此需要合理设置。
3）实验过程
MySQL不支持语句级审计，只能对所有的SQL使用进行日志记录。
①首先查看审计配置情况：
show variables like '%general_log%';
结果如下：
可以看到当前日志的状态（默认是关闭的），以及日志的名称与保存地址（这里没有显示路径，花了点时间查找）
在首次未打开审计之前，文件夹内是没有该log文件的。
路径在E:\MySQL\MySQL Server 8.0\Data\LAPTOP-S8GDLRKI.log
（这个跟自己安装mysql时的地址有关）
②开启日志
SET GLOBAL GENERAL_LOG=ON;
使用该命令打开审计之后，文件夹内可以找到该log文件。
③验证审计
以没有审计权限的用户进行操作，以上一个实验的部门经理FINANCE为例。先验证该用户并没有有审计的权限，然后进行SELECT操作。
然后我们打开log文件查看。
发现该用户的操作确实被记录下来了。
需要指出的是，不同数据库对审计的支持都存在不同。这里只是把审计当作了一个概念，即记录下用户操作的这样一个动作。因此，在这里我们实际上是用日志这个具体的文件去实现了审计这个概念。实际上审计还有其他插件可以支持。
但可以料想得到的是，如果所有操作都被记录下来，那么这个日志文件会变得越来越大，这也是需要考虑的，究竟哪些步骤需要被记录，谁的操作需要被记录，都值得思考，而不是记录下所有的操作。
④关闭日志
为了防止占太多空间，我选择暂时关闭日志。
SET GLOBAL GENERAL_LOG=OFF;
2.2数据库完整性
以下实验将不用TEST_COMPANY表。
2.2.1 实体完整性实验
1）实验内容与要求
定义实体完整性，删除实体完整性。能够写出两种方式定义实体完整性的 SQL 语句：创建表时定义实体完整性、创建表后定义实体完整性。设计SQL 语句验证完整性约束是否起作用。
2）实验重难点
创建表时定义实体完整性，有多个候选码时实体完整性的定义。
3）实验过程
①创建新数据库HNUT2
CREATE DATABASE HNUT2;
②创建表时定义完整性并验证
创建一个学生表，属性包括：学号、姓名、性别、年龄、所在班级，其中学号、
（姓名，所在班级）为候选码，此处设计后者作为候选码，均不允许为空值，性别
只能是男或女，年龄设置小于 25。
Student（sno，name，sex，age，class_num），其中（name，class_num）
做为主码。
CREATE TABLE student(
Sno CHAR(9) UNIQUE NOT NULL,
Sname CHAR(20) ,
Ssex CHAR(2) CHECK(Ssex = '男' OR Ssex = '女'),
Ssage SMALLINT CHECK(Ssage < 25),
Sclass CHAR(10),
PRIMARY KEY(Sname,Sclass)
);
验证完整性约束是否生效：插入一条学生记录，设置年龄为 26：会因为年龄不符合小于 25 的限制而插入失败。
INSERT INTO STUDENT VALUES('202108010','甘晴void','男',26,'CS2');
因为不符合完整性约束，插入的数据被拒绝。
③创建表之后定义并验证
CREATE TABLE Course(
Cno CHAR(9),
Cname CHAR(20),
Cpno CHAR(9),
Ctype CHAR(5),
Cdept CHAR(20),
Chours SMALLINT,
Ccredit SMALLINT
);
ALTER TABLE Course
ADD CONSTRAINT C1 PRIMARY KEY(Cno);
ALTER TABLE Course
ADD CONSTRAINT C2 CHECK(Cno like "GE%");
创建表之后定义完整性，限制课程号只能是类似"GE%"形式的。
验证完整性约束是否生效：插入2条课程记录,期中一条不合法，一条合法。
INSERT INTO COURSE VALUES('SGE001234','数据库系统','计算机系统','专业核心','计算机科学系',40,3);
INSERT INTO COURSE VALUES('GE001234','数据库系统','计算机系统','专业核心','计算机科学系',40,3);
验证截图如下，符合预期。
④删除实体完整性并验证
如果我们此时把限制课程号只能是类似"GE%"形式的这个实体完整性C2给删去。使用如下指令
ALTER TABLE COURSE DROP CONSTRAINT C2;
再次插入这条本来非法的记录。
INSERT INTO COURSE VALUES('SGE001234','数据库系统','计算机系统','专业核心','计算机科学系',40,3);
截图如下：
2.2.2 参照完整性实验
1）实验内容与要求
定义参照完整性，定义参照完整性的违约处理，删除参照完整性。写出两种方式定义参照完整性的 SQL 语句：创建表时定义参照完整性、创建表后定义参照完整性。
2）实验重难点
创建表时定义参照完整性，参照完整性的违约处理定义。
3）实验过程
①创建表时定义参照完整性+验证
创建一个班级表，属性包括姓名，学号，成绩，其中学号作为主码，姓名作为
student 表的外码。
CREATE TABLE Class(
Sname CHAR(10),
Sno CHAR(9) PRIMARY KEY,
Sgrade SMALLINT,
FOREIGN KEY(Sname) REFERENCES STUDENT(SNAME)
);
验证：
先往STUDENT表中成功加入一个学生。
INSERT INTO STUDENT VALUES('202108010','甘晴void','男',20,'CS2');
然后分别试图向Class表中加入一个不合法的学生和一个合法的学生。
INSERT INTO CLASS VALUES('甘晴wolf','202108010',100);
INSERT INTO CLASS VALUES('甘晴void','202108010',100);
截图如下：
可见不合法的记录因为不满足外键要求而被拒绝。
②创建表后定义参照完整性
CREATE TABLE Class(
Sname CHAR(10),
Sno CHAR(9) PRIMARY KEY,
Sgrade SMALLINT
);
ALTER TABLE CLASS
ADD CONSTRAINT C3 FOREIGN KEY(Sname) REFERENCES STUDENT(SNAME);
验证同上，结果符合预期。
③定义参照完整性的违约处理
删除 student 表中内容时级联删除 class 表中相应内容。
一般的违约处理都是拒绝执行。教材指出，若想让系统采取其他策略，必须在创建参照表的时候显式地加以说明。
CREATE TABLE Class(
Sname CHAR(10),
Sno CHAR(9) PRIMARY KEY,
Sgrade SMALLINT,
FOREIGN KEY(Sname) REFERENCES STUDENT(SNAME)
ON UPDATE CASCADE
ON DELETE CASCADE
);
验证外键在delete上的级联是否生效：
在被参考表STUDENT表插入一条合法学生数据，然后子在参考表插入该学生的成绩信息。
INSERT INTO STUDENT VALUES('202108010','甘晴void','男',20,'CS2');
INSERT INTO CLASS VALUES('甘晴void','202108010',100);
接着在STUDENT表删除该学生信息，查看CLASS表是否随之发生变化。
DELETE FROM STUDENT WHERE SNAME='甘晴void';
SQL 语句进行验证违约处理是否生效。
④删除参照完整性
删除参照完整性
ALTER TABLE Course DROP CONSTRAINT C3;
2.2.3 用户自定义完整性实验
1）实验内容与要求
针对具体应用语义，选择 NULL/NOT NULL、DEFAULT，UNIQUE、CHECK 等，定义属性上的约束条件。
2）实验重难点
NULL/NOT NULL, DEFAULT,CHECK。
3）实验过程
①建立完整性约束
创建 source 课程记录表，属性包括学号，姓名，成绩，性别，所在小组，其中学号不能为空且唯一，姓名不能为空，成绩可以为空（期末考之后才会有成绩），性别不能为空，组号限制在 1-10，其中学号为主码。自行设计创建表之后定义完整性约束。
#在定义表时进行完整性约束
CREATE TABLE SOURCE(
SNO CHAR(9) UNIQUE NOT NULL,
SNAME CHAR(10) NOT NULL,
SGRADE SMALLINT,
SSEX CHAR(2) NOT NULL CHECK(SSEX = '男' OR SSEX = '女'),
SGROUP SMALLINT CHECK(SGROUP>=1 AND SGROUP<=10),
PRIMARY KEY(SNO));
#在定义表后进行完整性约束补充
#（列级完整性约束非check子句无法表后定义）
CREATE TABLE SOURCE(
SNO CHAR(9) UNIQUE NOT NULL,
SNAME CHAR(10) NOT NULL,
SGRADE SMALLINT,
SSEX CHAR(2) NOT NULL,
SGROUP SMALLINT,
PRIMARY KEY(SNO));
ALTER TABLE SOURCE ADD CONSTRAINT C1 CHECK(SSEX = '男' OR SSEX = '女');
ALTER TABLE SOURCE ADD CONSTRAINT C2 CHECK(SGROUP>=1 AND SGROUP<=10);
②验证完整性约束
设计 SQL 语句验证完整性约束：插入时姓名为空会因为违反了完整性约束而无法插入。
INSERT INTO SOURCE VALUES('202108010',NULL,100,'男',2);
运行截图如下：
③删除完整性约束并验证
试图插入一组不合法的请求（不符合完整性约束C2）
INSERT INTO SOURCE VALUES('202108010','甘晴void',100,'男',22);
删除完整性约束C2
ALTER TABLE SOURCE DROP CONSTRAINT C2;
再次试图插入该请求
运行截图如下：
在删除该完整性约束之后，该请求能被正常插入了。
2.3 触发器实验
1）实验内容与要求
掌握数据库触发器的设计与使用方法，定义 BEFORE 触发器和 AFTER 触发器，能够理解不同类型触发器的作用和执行原理，验证触发器的有效性。
2）实验重难点
利用触发器实现较为复杂的用户自定义完整性。
3）示例
①创建触发器（以BEFORE为例）
以 before 触发器为例，定义一个 teacher_salary 教师工资表，属性包括 name、job、salary，均不可为空，其中 name 作为主码。
CREATE TABLE TEACHER_SALARY(
NAME CHAR(10) PRIMARY KEY,
JOB CHAR(20) NOT NULL,
SALARY SMALLINT NOT NULL);
Before 触发器定义如下：教授工资不得低于 5000，若低于则自动更改为 5000。
CREATE TRIGGER TS_T
BEFORE INSERT ON TEACHER_SALARY
FOR EACH ROW
BEGIN
IF NEW.JOB = '教授' AND NEW.SALARY < 5000 THEN
SET NEW.SALARY = 5000;
END IF;
END;
★mysql关于触发器的语法区别
特别注意，mysql关于触发器的的语法与教材的不太一致，主要体现在如下：
- 不需要使用REFERENCING NEW AS NEWTURPLE，而是直接使用NEW来指代新表
- mysql触发器支持UPDATE,INSERT,DELETE的触发，但不支持它们的逻辑结合，例如UPDATE OR INSERT这样是不可以的，这个跟教材上有一定区别。
- 赋值语句使用SET而不是:=符号
- 删除触发器时直接DROP TRIGGER <触发器名>，不需要添加ON <表名>
②验证触发器（以BEFORE为例）
验证如下：
#插入一条数据
INSERT INTO TEACHER_SALARY VALUES('甘晴void','教授',2000);
这条数据的salary是2000，这是不合规的，触发器会自动将它修改为5000.
运行截图如下：
③验证触发器执行顺序
触发器的执行是由触发事件激活，执行顺序如下:
- 执行该表上的 before 触发器，
- 激活触发器上 sql 语句，
- 执行表上 after 触发器，
对于表上多个 before 触发器，保持谁先创建谁执行原则，也有的是按照触发器名字的排序执行（这个应该就是不同数据库决定的了）
验证触发器的执行顺序可以这样进行：
- 我们分别创建BEFORE和AFTER触发器
- 每个触发器触发的时候就在另一个表中存一条记录
- 我们新建一个表TS_U来存触发器的这种记录
具体过程如下：
#先删除上面那个触发器，
#新建一个表TS_U
CREATE TABLE TS_U(
NAME CHAR(10),
JOB CHAR(20),
SALARY SMALLINT,
TAG CHAR(10) #这个TAG我是用来标记记录的产生顺序
);
#创建BEFORE触发器
CREATE TRIGGER TS_T1
BEFORE INSERT ON TEACHER_SALARY
FOR EACH ROW
BEGIN
IF (NEW.JOB = '教授') AND (NEW.SALARY<5000) THEN
INSERT INTO TS_U VALUES(NEW.NAME,NEW.JOB,NEW.SALARY,'BEFORE');
END IF;
END;
#创建AFTER触发器
CREATE TRIGGER TS_T2
AFTER INSERT ON TEACHER_SALARY
FOR EACH ROW
BEGIN
IF (NEW.JOB = '教授') AND (NEW.SALARY<5000) THEN
INSERT INTO TS_U VALUES(NEW.NAME,NEW.JOB,NEW.SALARY,'AFTER');
END IF;
END;
#插入一条数据
INSERT INTO TEACHER_SALARY VALUES('甘晴wolf','教授',3000);
验证截图如下：
我们排除顺序的影响，交换BEFORE触发器和AFTER触发器的定义顺序，再试一次。结果如下：
可以发现仍然没有变化，说明的确是BEFORE触发器在AFTER触发器之前执行。
④删除触发器
注意与书上的语法区别，不需要指明所在表。
DROP TRIGGER TS_T1;
实验感悟
实践和理论还是有很大的差别的，特别是数据库的实验。先不说书上的一般范式和mysql数据库自己的“方言”的区别，仅仅是把一样的行为搬到数据库中就有可能产生好多好多的问题，比如mysql触发器的定义就不一样，从格式到作用范围都有差异。再比如说mysql的激活角色，这是很难想到的，这也是教材和mysql实际的一个很大的区别。如果不经过同学的提醒，我可能一直会卡在这里。作为一个初学者，跟着书本上做，就是做不出预期的效果，然后就会以为这是bug，心态非常崩，而且找不到错误的原因，会非常沮丧和气恼。从这里我有一个感悟就是，做实验的时候还是不能仅仅看书，得先研究mysql提供的手册，遇到问题别先怀疑是bug，先查手册。
可惜的是这一周的实验和作业太多了，还有期中考试等，以至于我没有足够的实践对mysql手册进行足够深入的了解。希望以后在项目实战（OceanBase数据库项目）中对数据库系统进行更多的研究。
![【C++入门到精通】 线程库 | thread类 C++11 [ C++入门 ]](https://img-blog.csdnimg.cn/direct/cc54c76d53ef401cb7aab0ccdd65ab56.png#pic_center)
