简介一份zzu数据库实验报告书完整对应《数据库系统原理实验》课程九个实验环节认识DBMS并安装openGauss、创建数据库/表/索引、编写交互式SQL、创建视图、实施完整性控制、配置安全性权限、处理事务与并发控制、数据库备份恢复以及使用JDBC连接数据库。报告以docx文档呈现压缩包共1个文件、大小3.23MB每个实验均包含实验目的、操作步骤、问题描述与结果分析并对openGauss的gsql命令行工具、用户与数据库创建、锁机制等细节做出记录。已有1521人学习浏览适合计算机科学与技术、软件工程专业学生在完成数据库实验或准备相关考试时对照练习也可作为课程报告撰写的结构参考。报告按实验顺序组织目录清晰可以直接定位到具体章节便于逐项核对操作结果有助于理解关系模型与SQL语言在真实数据库系统中的落地方式。从环境搭建到JDBC编程覆盖了数据库原理课程的核心知识点能为后续数据库应用开发打下基础。1. 为什么“zzu数据库实验报告书”不是写作文而是一条完整的实验流水线课程进入收尾阶段A同学对着空白的文档发愁SQL实验他一次就通过了但那份“zzu数据库实验报告书”却不知道从哪儿写起。这不是个别现象很多同学把报告书当成作文上来就写“心得体会”最后交上去的文档里只有几个截图没有设计过程也没有排错记录老师想看的关键证据链全是空的。我接过不少这类报告书的修改最深的感触是数据库实验报告书不是实验的“事后记录”而是实验流程本身的可复现文档。老师评分看的不是你写了多少字而是能不能顺着你的文档把建库、查询、异常处理重新跑一遍。这篇内容面向正在赶数据库课设、需要提交一份完整实验报告书的同学也面向想把自己的练习沉淀成可复查文档的开发者核心就三件事结构怎么立、技术怎么落、坑怎么避。2. 实验报告书的结构骨架先定章节再动手实验流程反过来决定报告目录2.1 报告书的主流章节结构从“实验目的”到“附录”的顺序逻辑数据库实验报告书虽然每个课程班的要求略有差异但主干结构非常稳定。我一般会建议学生先搭好下面的骨架再往里填内容。章节核心内容老师实际看什么封面与基本信息课程名、实验名、姓名学号、提交时间是否符合提交规范是否有明显敷衍实验目的与环境实验目标、操作系统、数据库版本、客户端工具环境是否写全能否复现需求分析题目拆解、业务规则、数据项说明有没有理解问题还是直接抄题概念与逻辑设计ER图、关系模式、主外键、范式分析设计能力和理论功底物理设计与实现建表语句、索引设计、SQL实现动手能力语句是否真能跑实验结果与运行截图查询结果、功能演示、数据对比结果是否真实数据量是否合理问题与解决报错类型、原因分析、处理办法排错意识是否独立完成总结与附录收获、全部SQL清单、参考资料态度和完整性这个顺序没什么稀奇但它是沿着“需求 → 设计 → 实现 → 验证 → 复盘”来的正好对应一次完整的数据库实验。我写报告前一般先把这些章节名放进文档里然后倒着填空先整理实验结果再回头补设计过程反而比顺着写顺手得多。因为实验做完时记忆最清楚的是结果和代码设计过程是回溯出来的顺着写容易卡在第二章就写不下去。2.2 把实验题目拆成“数据需求”和“功能需求”让报告有内容可写拿到题目先别急着建表。我通常让学生先做一步拆解把题目里的自然语言拆成“数据需求”和“功能需求”两张表。以最常见的“学生选课”为例。类型对象具体内容数据需求实体学生学号、姓名、院系、专业数据需求实体课程课程号、课程名、学分、开课院系数据需求联系选课学号、课程号、成绩、学期功能需求查询按学号查成绩、按院系列平均分功能需求统计各课程选课人数、不及格名单功能需求视图某院系学生的选课视图功能需求存储过程实现选课操作自动判断是否重复选课功能需求触发器成绩超出 0100 范围时拒绝写入功能需求备份恢复对数据库进行导出和导入这张表整理完报告里的“需求分析”章节就已经有了大半内容。后面画 ER 图时实体和属性从数据需求里取写 SQL 时功能需求直接变成第四章节的标题。“需求分析”不是写一段话描述题目而是把题目变成可操作的数据项。很多同学报告写得空就是因为跳过了这一步直接贴代码老师看不到“你是怎么把题目翻译成设计的”。2.3 “可复现性”是报告书的第一标准每个截图对应一个可执行操作老师翻报告时最怕看到“运行结果如下”但不知道这个结果是怎么跑出来的。合格的做法是“三段对应”截图前写上题目要求贴上对应的 SQL截图里带有输入条件或执行结果。报错截图则要有错误原文和解决后的对比。我一般会把每条 SQL 编号并映射到目录里。比如建表语句放在第四章的 4.1查询结果截图放在 4.2。这样老师按节查看时立刻知道这段代码要解决什么问题不需要来回翻页。这份报告是给别人复查用的不是给自己回忆用的所以“可复现”比“字数多”重要得多。截图建议统一在数据库客户端里执行带上数据库名或影响行数能增加不少可信度。3. 数据库设计怎么写进报告书ER图、关系模式与范式校验3.1 从需求表到ER图实体、属性、联系的圈定方法ER 图贵的不在画图而在“圈对象”。我见过不少报告ER 图尺寸不小但实体之间连线的语义是乱的。回到 2.2 那张表实体就是名词属性就是名词的修饰项联系就是动词。学生选课场景里实体是“学生”和“课程”联系是“选课”。画图前建议先在草稿上完成一张表对象类型属性主键学生实体学号、姓名、院系、专业学号课程实体课程号、课程名、学分、开课院系课程号选课联系学号、课程号、成绩、学期(学号, 课程号)然后才是画图。画图用什么工具无所谓保存成高分辨率图片就行。老师在 ER 图上主要看三点实体有没有冗余属性、主键是否标清楚、联系类型和后面建的表是否一致。如果你在 ER 图上画了“选课”这个联系但后面建表时没有一张表对应它老师一眼就能看出来设计断链了。3.2 多对多关系拆解为什么先拆关系再写 SQL这是实验报告里最容易翻车的地方。学生和课程之间是典型的多对多联系ER 图上如果直接一条线连过去建表时根本建不出来——因为一张表存不下多个成绩记录。正确做法是必须在 ER 图上把多对多联系拆成一个中间关系也就是选课表。报告里我会建议这样写“学生—课程是多对多联系需拆分为选课关系其主键为学号课程号的组合键。”就这一句话能挡住老师一半的追问。一对一和一对多相对简单一对多时在“多”方加外键一对一尽量合并成一张表除非有特殊的扩展需求。对于数据库实验这种规模的项目绝大多数场景都到不了保留一对一的必要。报告里每出现一个联系都要能对应到建表语句里的外键或中间表这是设计落地的基本要求。3.3 范式校验的三步检查法报告里的“分析”环节该写什么范式分析是设计类实验报告里必须有的硬内容但大多数学生只写一句“本表满足第三范式”没有任何推导过程。老师看到这种话基本不会给高分。正确的做法是给一个可复现的检查过程。检查项操作报告呈现候选键识别找出所有能唯一确定元组的属性组合写出一句话结论非主属性完全依赖确认每个非主属性是否完全依赖候选键用箭头写出依赖关系传递依赖检查是否有属性存在对候选键的间接依赖写出拆表原因拿“选课表学号课程号成绩开课院系”举例。候选键是 (学号, 课程号)成绩完全依赖于这个组合键但“开课院系”只依赖于课程号不依赖学号属于对候选键的部分依赖不满足第二范式。于是要把开课院系从选课表里拆出去放进课程表。报告中这样写“选课表中存在开课院系对课程号的部分依赖因此拆分为选课表学号课程号成绩与课程表课程号课程名学分开课院系。”一段话就把分析过程说明白了。到第三范式再检查有没有传递依赖比如“院系办公室电话”依赖“院系”不依赖主键就需要再拆。把这个过程完整写进报告比空泛写“满足3NF”有说服力得多。4. SQL 实验的正文写法DDL/DML/视图/存储过程怎么编排才能让老师一眼看懂4.1 建库建表语句把约束和注释写进报告而不只是贴一堆 CREATE TABLE建库建表是报告书里最基础但最容易敷衍的部分。很多同学的正文就是一个连着一个的 CREATE TABLE没有注释没有约束说明老师看三行就失去耐心。我一般建议在每段 SQL 前加一行注释说明“这张表对应哪个实体”并在关键约束后面写明理由。-- 创建数据库指定 utf8mb4 字符集避免中文乱码 CREATE DATABASE IF NOT EXISTS student_course DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE student_course; -- 学生表s_id 定长字符串作为主键s_name 不允许为空 CREATE TABLE student ( s_id CHAR(9) PRIMARY KEY, s_name VARCHAR(20) NOT NULL, dept VARCHAR(40), major VARCHAR(40) );逻辑说明学生表的学号用 CHAR(9) 而不是 INT是因为学号通常有前导零或固定格式用定长字符型避免存储变形。主键直接写在字段上符合“每个关系模式必须有主键”的规范。字符集用 utf8mb4 是为了存中文内容不出现问号这也是实验报告中环境信息要写清楚的原因。参数说明如果你的实验环境是其他数据库比如某国产数据库或 PostgreSQL语法略有差异但报告里要写一句“在 xx 版本数据库下验证通过”。建表语句不要只贴成功执行的最好把字段选择的原因也写一句比如“dept 用 VARCHAR(40) 是因为按常见院系名称长度预留了冗余”。4.2 查询与分析语句每个 SELECT 都要配“题目要求”和“结果说明”查询语句是实验报告里占比最高的部分。常见的问题是把题目和 SQL 分开写中间没有任何连接老师得自己对照。我的写法是“三段式”题目要求 → SQL 代码 → 运行结果说明。-- 题目要求查询每个院系学生的选课平均分结果按平均分降序排列 SELECT s.dept, AVG(sc.score) AS avg_score FROM student s JOIN stu_course sc ON s.s_id sc.s_id GROUP BY s.dept ORDER BY avg_score DESC;逻辑说明这里用了内连接把学生表和选课表关联起来GROUP BY 按院系分组后计算平均分。SELECT 列表中出现的非聚合列 dept 必须出现在 GROUP BY 子句里这是 SQL 标准对分组查询的硬性要求也是老师批改时看得最仔细的地方。参数说明JOIN 的条件 s_id 是学生表主键、选课表外键这里的外键关系必须在建表时就建立否则查询结果会变大。ORDER BY 放在 GROUP BY 之后是对分组后的结果排序。报告里贴结果截图时要补一句数据说明比如“平均分最高的院系是计算学院符合各院系选课人数分布情况”让结果看起来是经过核验的而不是随手跑出来的。4.3 视图、存储过程与触发器的“输入条件 输出效果”写法视图和存储过程是实验报告书里拉开差距的地方。视图的写法相对简单重点是报告里写清“为什么用视图”。-- 创建计算机学院学生的选课视图方便后续按学院统计 CREATE VIEW dept_student AS SELECT s.s_id, s.s_name, s.dept, sc.c_id, sc.score FROM student s JOIN stu_course sc ON s.s_id sc.s_id WHERE s.dept 计算机学院;逻辑说明视图本身不存数据每次查询时动态执行。这里把院系条件封装在视图里后续查询就不需要重复写 WHERE 条件同时还能隐藏学生表的其他字段起到权限控制作用。报告里一定要带一句“通过视图查询的结果”以及对应 SELECT 语句否则老师无法判断这个视图你有没有真正用过。存储过程是很多同学的痛点因为弄不清 DELIMITER 的作用。DELIMITER // CREATE PROCEDURE add_stu_course( IN p_s_id CHAR(9), IN p_c_id CHAR(9), IN p_score DECIMAL(5,2) ) BEGIN -- 避免重复选课插入前先检查是否存在记录 IF NOT EXISTS (SELECT 1 FROM stu_course WHERE s_id p_s_id AND c_id p_c_id) THEN INSERT INTO stu_course(s_id, c_id, score) VALUES(p_s_id, p_c_id, p_score); END IF; END// DELIMITER ;逻辑说明存储过程封装了“插入前先检查是否重复”的业务规则应用层只需要调用过程名不需要重复书写业务判断。IN 参数表示外部传入的学号、课程号和成绩DECIMAL(5,2) 表示成绩最多 3 位整数加 2 位小数。DELIMITER 的作用是临时把语句分隔符从分号改写成 //防止 BEGIN...END 内部的分号提前截断整段过程定义。参数说明很多同学在命令行下执行这段代码报错以为是语法错误其实是没有执行 DELIMITER //。报告中要主动写一句“在 mysql 命令行客户端下需要先修改定界符”这一句能暴露你是否亲手跑过。执行调用时用 CALL add_stu_course(20240001, C001, 95.00)截图里要包含调用语句、返回状态和选课表前后的数据对比。触发器的写法类似。DROP TRIGGER IF EXISTS check_score; DELIMITER // CREATE TRIGGER check_score BEFORE INSERT ON stu_course FOR EACH ROW BEGIN IF NEW.score 0 OR NEW.score 100 THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT score must be between 0 and 100; END IF; END// DELIMITER ;逻辑说明触发器在 INSERT 前触发NEW 表示即将插入的新行。SIGNAL 语句主动抛出一个异常阻止错误数据写入。实验环境需要支持 SIGNAL 语法报告里要在“实验环境”中写清数据库版本否则换到旧版本环境跑不出来会被质疑。4.4 备份与恢复实验用命令行跑通导入导出写进报告才算闭环备份恢复几乎是每个数据库实验的标配也是学生最容易糊弄过去的部分。很多人的报告只写“使用工具导出成功”没有实际命令和验证数据。备份恢复本身就是命令行场景直接给出完整顺序。# 1) 导出整个数据库包含表结构和数据 mysqldump -u root -p student_course student_course_backup.sql # 2) 恢复前先创建目标库再导入备份文件 mysql -u root -p -e CREATE DATABASE IF NOT EXISTS student_course_restore; mysql -u root -p student_course_restore student_course_backup.sql # 3) 验证恢复结果对比原库和恢复库的行数 mysql -u root -p -e SELECT COUNT(*) FROM student_course.student; mysql -u root -p -e SELECT COUNT(*) FROM student_course_restore.student;逻辑说明mysqldump 是逻辑备份工具导出的文件是一整段 SQL 文本包含建表语句和 INSERT 语句。恢复时通过输入重定向把文件内容交给 mysql 客户端逐行执行。注意 mysqldump 默认不会自动创建数据库所以导入前需要手动 CREATE DATABASE。最后一步 SELECT COUNT 是验证备份是否完整的关键动作报告里必须贴出对比结果。参数说明-u 指定用户名-p 会在命令行交互式提示输入密码避免把密码写进脚本和报告。 是输出重定向 是输入重定向。如果数据库比较大可以加 --single-transaction 参数避免锁表但实验数据量下不需要。报告里写这段时贴三个部分导出命令、导入命令、行数对比截图。三步齐了备份实验才算闭环。5. 数据库实验报告书的5个常见翻车点现象、原因与解决5.1 多对多关系没拆ER图与建表语句对不上现象ER 图里学生和课程直接用一条线连起来但建表时没有选课表或者选课表临时拍脑袋加出来没有任何设计推导过程。原因分不清“联系”和“关系表”的区别。多对多联系在关系模型里必须用独立的关系表示否则两个实体之间没法存储多个成绩记录。解决在设计阶段先问自己一句“这个联系的属性放哪里”。成绩不是学生或课程本身的属性它属于“选课”这个联系因此必须拆表。报告中把拆表过程写出来“学生—课程是多对多联系拆分为选课表主键为 (学号, 课程号) 组合键”。这一步做完ER 图和建表语句自然一致。5.2 主键外键标注不清关系模式写成一段话现象关系模式写成“学生表有学号、姓名、院系这些字段”主键、外键完全没有符号标记老师看完整段也不知道哪些字段能唯一确定一条记录。原因把逻辑设计章节写成了需求描述没有按关系模式的标准格式表达。解决用带标记的格式写。主键加下划线或者写 PK外键写 FK。例如“学生(学号 PK, 姓名, 院系, 专业)”、“选课(学号 FK, 课程号 FK, 成绩, 学期, 主键(学号, 课程号))”。ER 图上用同色或相同记号标主键和外键老师一眼就能定位。这是报告里成本最低但收益最明显的改进。5.3 只贴成功截图问题与解决章节全靠编现象报告正文从头到尾都是成功运行结果“问题与解决”章节里写的错因明显是从网上复制来的跟自己贴的 SQL 没有任何关系。原因把“问题与解决”当成凑字数的章节忽略了它其实是实验报告最有含金量的一部分。解决挑选实验中真实遇到的一个报错按“报错原文 → 原因分析 → 修改后 SQL → 运行结果”四段式写。比如忘记加 GROUP BY 导致查询报错这个报错很常见原因分析也容易写透。老师考察的不是你有没有犯错而是你面对错误时能不能定位和解决。真实的一条排错记录比十句“通过本次实验掌握了……”都有说服力。5.4 DELIMITER 没写导致存储过程编译失败被当成语法错误现象在命令行客户端里执行存储过程创建语句一直报语法错误学生认为是数据库版本问题实际上是客户端解析逻辑的问题。原因命令行客户端以分号作为语句默认结束符而 BEGIN...END 内部也使用分号导致客户端在内部第一条语句结束时就把整个 CREATE PROCEDURE 截断了。解决执行前先执行 DELIMITER //把定界符临时改成 //创建完成后用 DELIMITER ; 改回。这份内容我在第四章已经写了完整示例。报告里要主动写出这一步因为它能证明你是在命令行环境里亲手调试过的而不是只在客户端工具里点了“执行”。如果换用图形化客户端通常不需要这一步但报告里写清环境更严谨。5.5 范式分析只写结论不写推导被老师一眼识破现象报告里通篇写“本表符合第三范式设计合理”但没有一处依赖分析也没有任何拆表过程。原因范式知识只是用来应付检查没有真正用来校验设计自然写不出分析过程。解决每张表至少写一句依赖判断。例如“选课表中开课院系只依赖于课程号不依赖于组合主键 (学号, 课程号)属于部分依赖因此拆出课程表独立存放。”这段话不需要很深的数学表达但能证明你是用范式规则一步步推下来的。明显的违反反例是强行把所有字段塞进一张大表那样的表既违反第二范式也会在增删数据时出现冗余异常和删除异常。6. 让报告书从“能用”到“好看”的三个交付技巧6.1 用文档样式和自动目录把格式统一交给编辑器提交前的排版往往比内容更影响第一印象。我习惯先把每一个章节标题设置成标准的标题 1 和标题 2 样式再插入自动目录。这样修改章节顺序时目录会跟着刷新不需要手动改页码。代码块统一用等宽字体SQL 关键词保持相同风格截图宽度统一调成与正文同宽避免出现半个截图像素模糊的情况。6.2 最后通读检查清单交付前一天只做一致性检查检查项检查动作环境信息数据库版本、字符集、操作系统是否写全ER图与表结构每个实体是否都有对应建表语句多对多是否拆出中间表SQL编号报告中功能点是否都有 SQL 支撑编号和目录是否对应截图清晰度截图是否高清是否包含执行结果或影响行数结论一致性查询结果是否符合原始数据的统计预期交付前一天我不建议再改正文只做一致性检查。因为深夜改正文容易引入新的不一致比如改了表结构忘了换 ER 图或者改了一个字段名忘了同步查询语句。把这些搜索通读一遍目录页码再刷新一次就可以提交了。我自己的习惯是保存两份文档一份是带截图的完整版一份是只含 SQL 的附录方便后续自己复用代码。希望这份梳理能帮你把一份本来只值“交了”的报告写成真正能代表你设计能力的作品。希望帮到你。本文还有配套的精品资源点击获取