简介这份zzu数据库实验报告书是计算机科学与技术、软件工程专业学生的课程实验完整记录对应《数据库系统原理实验》课程基于openGauss平台展开。内容覆盖认识DBMS系统、创建数据库表和索引、交互式SQL语句、创建视图、完整性控制、安全性控制、事务与并发控制、数据库备份与恢复、使用JDBC连接数据库等九大实验模块每个实验均包含实验目的、实验内容、操作步骤、问题与解决过程以及结果分析并伴有详细命令示例和截图说明可帮助读者掌握概念模型与关系模型、熟练使用SQL进行查询检索与管理控制理解数据安全性、完整性、并发性和可恢复性的实际处理方式。资源为1个docx文档压缩包共3.23MB目录结构清晰适合正在学习数据库原理、需要实验报告参考或openGauss实操指引的高校学生直接使用或对照复习。已有1522人学习下载具备较高参考价值。1. 一份能跟着复现的 openGauss 实验报告从安装到 JDBC 的全链路边角料数据库实验报告书这类资源平时大家只当作业模板用翻两页就扔。但这本《数据库系统原理实验》报告书不太一样它把 openGauss 从安装部署、建库建表、视图与完整性控制一路做到事务并发、备份恢复和 JDBC 编程九个实验串成一条完整的实操链路。对正在写数据库实验报告的学生来说它是可以照着改的作业底稿对刚接触 openGauss 的从业者来说它把最容易翻车的环境搭建、权限模型、并发控制这些环节全部暴露出来了。我拿到后直接在一台虚拟机上按着走了一遍中间确实踩了几个坑但也正因为有坑这份材料才有复现价值。下面我把每条命令、每个参数、每个容易出问题的地方拆开讲。2. 认识 DBMS 与 gsql 连接先让 openGauss 跑起来再说2.1 三种安装模式怎么选报告书里提到 openGauss 有三种安装模式华为弹性云上安装、虚拟机一键安装、虚拟机安装 openEuler 后再安装 openGauss。这里先别急着选三者的差别直接决定你后续实验是不是顺利。华为弹性云上安装适合有云资源的人但需要申请公网 IP、配置安全组规则对新手来说反而多了网络层面的变量。虚拟机一键安装是最省事的路径——镜像里通常已经把 openGauss 装好了你只需要启动虚拟机、切换用户、启动服务就能直接进 gsql。我当时选的就是一键安装因为实验目的是认识 DBMS而不是折腾编译安装。如果你是第一次接触 openGauss建议也走这条路线把精力留给后面的 SQL 语句。第三种方式虚拟机装 openEuler 再手动装 openGauss适合想搞清楚依赖关系的场景。openGauss 对操作系统的 glibc、python 版本有要求手动装的时候会遇到不少前置依赖的坑。报告书的实验一只是让你「了解三种模式选一个适合自己的」所以在安装上不用过度纠结能跑起来就是胜利。2.2 启动服务与连接默认库三个命令一气呵成安装完成后第一件事是切换用户并启动服务。数据库安装用户是 omm注意切换命令su - omm里的减号不能省它表示同时切换环境变量。我在第一次操作时直接敲了su omm结果 PATH 里没有 gs 系列命令报错说找不到gs_om当时还以为是安装出了问题。# 切换至数据库安装用户注意中间有 - su - omm # 启动数据库服务 gs_om -t start # 连接默认数据库 postgres-r 表示启用 readline 功能 gsql -d postgres -p 26000 -rgs_om -t start是 openGauss 的服务管理命令-t指定操作类型为 start。如果服务已经在运行它会提示unknown node或者直接跳过。连接数据库时-d指定数据库名-p指定端口号openGauss 默认端口是 26000和 PostgreSQL 的 5432 不一样这个数字后面几乎每次连接都要用到建议记牢。-r参数我一般都会加上它让 gsql 支持上下键翻历史命令否则在终端里输错一条长 SQL 就得重新敲一遍。连接成功后默认会进入postgres数据库。它是 openGauss 安装完成后自动生成的初始数据库专门用来做管理操作比如创建新数据库、创建用户。不要在 postgres 库里建业务表这是实验报告里没明确说但实际应该养成的习惯——管理和业务数据混在一起后面导数据、备份的时候会很难受。2.3 gsql 元命令不看文档也能摸清数据库家底gsql 提供了一组反斜杠开头的元命令比 SQL 查询系统表更直观。报告书里列了\l、\dt、\d、\dn、\di这些我整理成了一张表方便对照着用。这些命令的价值在于它们是排查问题的第一手工具——表建没建成功、约束有没有生效、索引有没有创建敲一下就知道。命令作用使用场景\l列出所有数据库确认 db_school 是否创建成功\dt列出当前 schema 下的表确认 Students、Courses 等表是否都在\d tablename查看表完整属性含约束和索引检查主键、外键、CHECK 约束是否生效\d tablename查看表结构快速看字段名和类型\dn列出所有 schema确认 book_eg 是否创建成功\di列出所有索引查看 Student_Dept 索引是否建立\c dbname切换数据库从 postgres 切到 db_school\c - username切换用户从 omm 切到普通用户\q退出 gsql结束会话这里特别说一下\d tablename它是排查建表问题的关键命令。比如你用create table建了一张表结果忘记加外键用\d一看就能发现。报告书里在辨析 schema 时提到「一个数据库用户所拥有的数据库对象就构成这个用户的 schema」这句话放到实际操作中理解就是你在 book_eg 模式下建的表和你在默认 public 模式下建的同名表是两张完全独立的表查询时必须带模式名前缀。3. 创建数据库、模式、表和索引把物理设计和逻辑设计分开做3.1 表空间先行建库前先理解 storage 层实验二的第一个操作是创建表空间这一步很多人会直接跳过因为感觉「建库就建库搞什么表空间」。但 openGauss 里表空间决定了数据库文件落在哪个目录后续做备份恢复时表空间路径是必须知道的参数。-- 创建表空间relative location 后的目录必须存在 CREATE TABLESPACE tpcds_local RELATIVE LOCATION tablespace/tablespace_1; -- 创建数据库并指定使用刚才的表空间 CREATE DATABASE db_sc WITH TABLESPACE tpcds_local;官方文档里RELATIVE LOCATION后面跟的是相对于数据目录的路径如果你指定的目录不存在建表空间会直接报错。我一般会提前在数据目录下建好tablespace/tablespace_1目录。另外openGauss 的表空间和数据库不是一对一关系——一个表空间可以容纳多个数据库一个数据库也可以把不同表放到不同表空间。实验报告里把它类比成「文件夹」这个比喻在理解层面够用了。3.2 模式与级联删除drop 的时候要格外小心创建模式是实验二里的第二个操作命令本身很简单-- 创建模式 book_eg CREATE SCHEMA book_eg; -- 在模式中建表表名必须带模式名前缀 CREATE TABLE book_eg.Teachers ( Tno CHAR(20) PRIMARY KEY, Tname CHAR(20) NOT NULL, Sex CHAR(20) CHECK (Sex 男 OR Sex 女), Birthday DATE, Title CHAR(20), Dno CHAR(20) ); -- 级联删除模式及其中的所有对象 DROP SCHEMA book_eg CASCADE;DROP SCHEMA book_eg CASCADE这行命令值得好好说道——CASCADE表示级联删除模式下的所有表、视图、索引等对象。如果不用 CASCADE而模式里已经有对象openGauss 会拒绝执行并提示schema book_eg is not empty。这个设计是防止误删的但如果你确实想整个模式一起删掉就必须显式加 CASCADE。我在一次操作中路径下有一个视图忘了删直接执行DROP SCHEMA book_eg报错加上 CASCADE 后一切正常。记住CASCADE 是后悔药但也是拆家利器——用之前确认这个模式里的东西都不需要了。3.3 六张表建下来约束的类型和位置就全明白了实验二的主体是建立 TEACHERS、DEPARTMENTS、STUDENTS、COURSES、SC、TEACHES 六张表并填充数据。这六张表的设计有典型的教学意义——主键、非空、CHECK、外键全覆盖而且外键关系形成了环TEACHERS 的 Dno 引用 DEPARTMENTSDEPARTMENTS 的 Dheadno 又引用 TEACHERS 的 Tno这在实操中会带来一个问题先建哪张表都会失败因为被引用的表还不存在。解决办法有两种一种是不管约束顺序先把表建完再通过 ALTER TABLE 补外键另一种是先建不带头外键的表全部建完后统一添加约束。report书里采用的是第二种思路所以你能看到它在建完表后专门有一个「修改表」的步骤通过 ALTER TABLE 来补表级约束。这个顺序不是随意的是数据库理论里「先结构后约束」的实践体现。下面是 STUDENTS 表的完整建表语句CREATE TABLE Students ( Sno CHAR(20) PRIMARY KEY, Sname CHAR(20) NOT NULL, Sex CHAR(20) CHECK (Sex 男 OR Sex 女), Birthday DATE, Enrollyear CHAR(20), Speciality CHAR(20), Dno CHAR(20), FOREIGN KEY (Dno) REFERENCES Departments(Dno) );这条语句同时包含了列级约束PRIMARY KEY、NOT NULL、CHECK和表级约束FOREIGN KEY。区分规则是如果一个约束只作用于单列可以写在列定义后面如果涉及多列必须用表级约束的写法。在实际工作中我习惯把所有约束都写成表级约束格式统一后期维护时一眼能找到。注意Enrollyear用了 CHAR(20) 而不是 INT——这是实验报告里的一个细节表示入学年份作为字符串处理避免年份前面的 0 丢失比如2021和02021的区别这种设计取舍在真实业务里也常见。3.4 索引不是越多越好理解主键索引与普通索引的差异创建索引是实验二的收尾动作。openGauss 里 DBMS 会自动为主键建立索引所以你在建表时没写任何索引语句\di也能看到主键索引。手动创建索引是为了加速特定查询列-- 在 Students 表的 Dno 列上创建索引 CREATE INDEX Student_Dept ON Students(Dno); -- 查看当前数据库下所有索引 \di -- 删除索引 DROP INDEX Student_Dept;这里有几个参数细节。Student_Dept是索引名命名规则建议是「表名_列名」这样看到索引名字就能反推出它是建在哪张表上。索引不是越多越好每次 INSERT、UPDATE 时索引也要同步更新写多读少的表建索引反而拖慢性能。实验报告里辨析了索引和目录的区别——索引帮你快速定位数据行目录展示文章结构。这个类比迁移到数据库里就是主键索引帮你直接找到某一行而全表扫描就是没有目录的逐页翻书。4. 视图、完整性与安全性控制数据库不再只是「存数据的地方」4.1 视图查询逻辑的复用和权限的天然屏障实验四的核心是创建视图。视图本质是一段被命名的 SELECT 语句不占存储空间数据来自底层表。为什么要用视图两个原因一是复用——一个复杂的多表连接查询写成视图后每次只需要SELECT * FROM view_name二是安全——只开放需要的列给特定用户底层表的其他列完全不可见。-- 创建视图学生及其院系名称 CREATE VIEW Student_Department AS SELECT s.Sno, s.Sname, d.Dname FROM Students s JOIN Departments d ON s.Dno d.Dno; -- 查询视图和查表语法一致 SELECT * FROM Student_Department; -- 删除视图 DROP VIEW Student_Department;创建视图时有一个容易踩的坑视图的列名由 SELECT 子句决定如果底层表结构变了比如加列视图不会自动同步。openGauss 会在查询视图时报错或返回新结构你需要用CREATE OR REPLACE VIEW手动更新视图定义。另外如果视图包含聚合函数或 DISTINCT它通常不支持 INSERT、UPDATE 这类操作——这种视图是只读的。这些细节实验报告书里没有细讲但实际做实验时一定会碰到。4.2 完整性控制五种约束的适用边界实验五的完整性控制核心是理解五类约束NOT NULL、UNIQUE、PRIMARY KEY、CHECK、FOREIGN KEY。报告书里有一个很清晰的对比表格思路我按实操角度重新梳理了一遍约束类型列级/表级作用实操注意点NOT NULL仅列级该列不能为空无法通过 ALTER TABLE ADD CONSTRAINT 添加只能用 MODIFY COLUMNUNIQUE均可列值唯一可以为 NULL唯一约束会创建唯一索引PRIMARY KEY均可唯一且非空一张表只能一个DBMS 自动创建索引CHECK均可列值需满足条件openGauss 支持MySQL 低版本不支持FOREIGN KEY表级值必须来自主表引用列创建前被引用表必须存在实验报告里有一段辨析值得划重点「列级约束不能起约束名表级约束可以起约束名主键除外」。这在实际运维中很关键——如果你想在后续通过约束名来删除某个约束就必须在建表时用表级约束的语法并显式命名。比如-- 删除约束前先确认约束名 ALTER TABLE SC DROP CONSTRAINT sc_sno_fkey;如果建表时没命名系统会自动生成一个约束名格式通常是表名_列名_fkey这种用\d 表名能查到。这里我有个习惯凡是后续可能要删的约束建表时就起好名字比如ALTER TABLE Teaches ADD CONSTRAINT teaches_fk_1 FOREIGN KEY (Tno) REFERENCES Teachers(Tno)避免后面查名字浪费时间。4.3 安全性控制GRANT 和 REVOKE 用最小权限原则实验六的安全性控制本质上就是权限管理。openGauss 的安全模型继承自 PostgreSQL用户和角色是两个概念报告书里的比喻很到位角色是「仓库管理员」这个岗位用户是「老王」「小李」这些具体的人。你把角色赋予用户用户就拥有了角色的全部权限。-- 创建用户 db_user1 CREATE USER db_user1 WITH PASSWORD your_password; -- 授予查询权限 GRANT SELECT ON Students TO db_user1; -- 授予所有表的所有权限 GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO db_user1; -- 收回权限 REVOKE SELECT ON Students FROM db_user1; -- 查看所有角色 SELECT * FROM pg_roles;实操中有个权限相关的坑默认情况下普通用户对 public schema 下的表没有任何操作权限哪怕是 SELECT 也不行。很多同学在实验六里创建了一个新用户然后拿这个用户去查 Students 表结果报permission denied for table students然后一脸懵。解决办法就是先 GRANT再查询。另外openGauss 里CREATE USER和CREATE ROLE的差别在于前者默认带 LOGIN 权限后者不带。如果你用 CREATE ROLE 建了一个角色要登录数据库必须额外GRANT CONNECT ON DATABASE db_school TO role_name再ALTER ROLE role_name LOGIN。5. 事务、并发控制与备份恢复高频翻车区的避坑指南5.1 事务的 ACID 在 gsql 里怎么验证实验七的事务与并发控制理论部分考察 ACID实操部分就是 BEGIN、COMMIT、ROLLBACK 的组合拳。在 gsql 里验证事务特性比在代码里直观得多-- 开启事务 BEGIN; -- 插入一条选课记录 INSERT INTO SC (Sno, Cno, Score) VALUES (2021001, C001, 95); -- 查询该数据此时对当前会话可见 SELECT * FROM SC WHERE Sno 2021001; -- 回滚事务 ROLLBACK; -- 再查询数据已经消失 SELECT * FROM SC WHERE Sno 2021001;事务最关键的点在于BEGIN之后的所有操作要么全部提交COMMIT要么全部回滚ROLLBACK不存在中间状态。用两个 gsql 窗口能更直观地看到并发隔离效果——窗口 A 开启事务插入数据但不提交窗口 B 查询同样的数据如果隔离级别是读已提交B 看不到 A 未提交的数据。openGauss 默认隔离级别是读已提交这点和 PostgreSQL 一致和 MySQL 的默认可重复读不同。5.2 并发控制锁和死锁不是理论概念并发控制里最容易出问题的场景是两个事务同时更新同一行数据。openGauss 使用行级锁事务 A 更新了一行没提交事务 B 也更新这一行B 会被阻塞直到 A 提交或回滚。如果在 gsql 里遇到长时间没反应的情况大概率是锁等待。-- 检查当前锁信息 SELECT * FROM pg_locks; -- 查看阻塞会话 SELECT pid, state, wait_event_type, wait_event FROM pg_stat_activity WHERE state active;死锁的经典场景是事务 A 锁了表 1 等表 2事务 B 锁了表 2 等表 1。openGauss 会自动检测死锁并回滚其中一个事务但检测需要时间表现为「卡了几秒然后报错」。遇到死锁不要慌回滚后调整操作顺序让所有事务按同一个顺序访问表基本就能避免。5.3 备份与恢复备份文件放哪里、恢复时注意什么实验八的备份与恢复我用的最多的命令是逻辑备份因为物理备份gs_backup涉及整个数据目录的归档配置复杂学生实验用不上。逻辑备份适合单库或单表迁移# 导出 db_school 数据库到 tar 文件 gs_dump db_school -p 26000 -F t -f /home/omm/db_school.tar # 恢复数据库 gs_restore -p 26000 -d db_school /home/omm/db_school.tar-F t指定导出格式为 tar-f指定输出文件路径。恢复时有个容易忽略的点当恢复的目标数据库不存在时需要先CREATE DATABASE再gs_restore否则会报database does not exist。另外权限相关对象用户、角色不会随逻辑备份自动恢复如果你导出的库里包含用户授权信息恢复后需要手动重建用户和授权。5.4 避坑openGauss 实验高频问题排查记录坑 1切换用户时忘记加-现象执行su omm后输入gs_om -t start报command not found。 原因没有加载 omm 用户的环境变量PATH 里没有数据库工具目录。 解决使用su - omm重新切换或者手动执行source ~/.bashrc加载环境变量后再启动服务。坑 2连接数据库报端口不对现象gsql -d postgres -p 5432连接超时或报port 5432 does not exist。 原因openGauss 默认端口是 26000不是 PostgreSQL 的 5432。 解决检查gs_om -t status确认主节点端口连接时使用-p 26000。如果实例端口做过修改查看 postgresql.conf 里的port参数。坑 3建表时报交叉外键引用错误现象建 TEACHES 表时提示relation teachers does not exist。 原因TEACHES 表同时引用了 TEACHERS 和 COURSES而这两张表此时还没建完。 解决先建不带外键的表全部建完后用 ALTER TABLE 统一添加约束。注意检查表名大小写——openGauss 里不带引号的表名会被转成小写如果建表时用了大写如Teachers后续引用必须加双引号。坑 4删除 schema 时提示 not empty现象DROP SCHEMA book_eg报schema book_eg is not empty。 原因schema 下有表或其他对象直接 drop 被安全机制拦截。 解决使用级联删除DROP SCHEMA book_eg CASCADE或先手动删除其中所有对象再执行 DROP。坑 5新用户无法查询任何表现象CREATE USER db_user1后用该用户登录SELECT * FROM Students报permission denied。 原因openGauss 默认用户对非自己创建的对象没有任何权限需要显式授权。 解决作为 omm 用户执行GRANT SELECT ON Students TO db_user1或者查询前用\dp查看表权限矩阵确认授权已生效。6. JDBC 连接 openGauss驱动参数和事务手控是最后一道关实验九的 JDBC 连接是整份报告书里唯一涉及代码的部分。openGauss 的 JDBC 驱动兼容 PostgreSQL 协议但连接 URL 有自己固定的格式// 加载驱动 Class.forName(org.postgresql.Driver); // 连接 URL格式jdbc:postgresql://host:port/database String url jdbc:postgresql://192.168.1.10:26000/db_school; String user omm; String password your_password; Connection conn DriverManager.getConnection(url, user, password); conn.setAutoCommit(false); String sql INSERT INTO SC (Sno, Cno, Score) VALUES (?, ?, ?); PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, 2021001); ps.setString(2, C001); ps.setInt(3, 92); ps.executeUpdate(); conn.commit(); ps.close(); conn.close();代码里有两个参数值得说明。setAutoCommit(false)是事务手控的关键——不关掉自动提交每一条 SQL 都会立即生效一旦批量操作中间出错前面的数据也要手动回滚。PreparedStatement的?占位符能防止 SQL 注入也避免字符串拼接时的引号转义问题。这里有一个很多人在实验九踩过的坑openGauss 的 JDBC 驱动虽然从 PostgreSQL 协议演变而来但连接 URL 里的端口必须和 openGauss 实例实际监听端口一致否则报连接超时。另外如果你用的是 openGauss 自带的驱动包opengaussjdbc.jarClass.forName 里的驱动类名是org.opengauss.Driver而不是 PostgreSQL 的org.postgresql.Driver这个细节不看清楚代码编译能过但运行必挂。从那以后我每次做 JDBC 连接都会先确认两件事一是驱动包版本和数据库版本要匹配二是setAutoCommit(false)一定放在连接创建后、第一次 SQL 执行前。顺序反了事务边界就糊涂了。这份报告我后来又完整复现过一遍每次都还是会撞上一两个小问题但也正因如此它对我来说始终是值得回翻的参考资料。希望这份拆解能让你少走几步弯路。本文还有配套的精品资源点击获取