简介：这份南华大学《数据库原理》实验报告面向大数据技术等专业学生，用于配合课程实验与期末复习，帮助读者系统掌握数据库管理系统操作与SQL语言应用。报告围绕SQL Server Management Studio展开，涵盖数据库与数据表的创建、主码外码与默认值约束的定义、表间一对多及多对多关系的建立，并重点训练单表查询与多表连接查询，涉及条件筛选、排序、分组、内连接与外连接等典型语句，同时延伸至数据更新操作与实体完整性、参照完整性的理解。资源包共1个doc文件，约5.38MB，内容为完整的实验报告文档，含实验题目、要求、代码与总结，目录结构清晰，便于按实验模块对照学习。目前已有375人学习下载，适合需要完成数据库原理实验、巩固SQL查询与建表建库技能的学生参考借鉴。
1. 数据库原理实验报告到底在讲什么：从一张选课表说起
很多人第一次听到“数据库原理实验报告”，脑子里浮现的是一摞打印纸和满屏看不懂的英文命令。其实它要解决的问题特别朴素：怎么把一堆杂乱的信息，变成能随时查、随时改、还不会出错的结构化数据。打个比方，你手里有一张纸，上面记着全班同学的姓名、学号、选了哪门课、考了多少分。人少的时候翻一翻还行，可一旦有几千个学生、上百门课，这张纸就彻底废了——找一个人要翻半天，改一个分数可能漏改另一处，两个人同时改还会打架。数据库就是把这个“纸面账本”搬进电脑，并且定好规矩：谁能改、怎么改、改完怎么保证前后一致。这份实验报告围绕的就是这套规矩的入门操作，从认识管理工具开始，到建库建表，再到用查询语句把数据捞出来。搞懂它，你就能看懂几乎所有信息系统背后那层“数据底座”是怎么搭起来的。
2. 为什么数据库不能只靠一张表：拆开看建库建表的门道
2.1 从“学生选课”看三张表的分工
实验里反复出现一个场景：建一个“学生选课”数据库，里面放三张表——学生表、课程表、选修表。为什么不把学号、姓名、课程名、分数全塞进一张大表里？因为那样会出大问题。假设张三选了“数据库原理”和“高等数学”两门课，如果全放一张表，张三的姓名、性别、院系就要重复写两遍。哪天张三转专业了，你得同时改两行，漏掉一行数据就自相矛盾。这就是所谓的“数据冗余”和“更新异常”。
拆成三张表之后，学生表只存学生本身的信息，课程表只存课程本身的信息，选修表只存“谁选了哪门课、考了多少分”这个关系。想查张三选了什么课，就用学号把学生表和选修表连起来；想查某门课有哪些人选，就用课程号把课程表和选修表连起来。每份信息只存一处，改的时候只改一处，这就是数据库设计最核心的思路——用关系拆解冗余。
实验里给这三张表分别定义了主码：学生表的学号、课程表的课程号、选修表的学号加课程号组合。主码的作用相当于每个人的身份证号，保证每一行数据都能被唯一锁定，不会出现两行一模一样、分不清谁是谁的情况。
2.2 主码、外码和默认值：三个容易被忽视的细节
建表的时候，除了写清楚字段名和数据类型，还有几个约束条件看着不起眼，但少了它们数据库就会“翻车”。
主码（Primary Key）解决的是“这一行到底是谁”的问题。比如学生表的学号设为主码，那就意味着不允许两个学生用同一个学号，也不允许学号为空。实验里选修表用的是学号加课程号的组合主码，因为一个学生可以选多门课，一门课可以被多个学生选，只有两个字段合在一起才能唯一确定一条选课记录。
外码（Foreign Key）解决的是“这一行引用的数据必须存在”的问题。选修表里的学号必须能在学生表里找到对应的人，课程号必须能在课程表里找到对应的课。如果没有外码约束，你完全可以往选修表里插一条“学号99999选了课程XXX”的记录，但学生表里根本没有99999这个人，这条数据就成了孤儿。外码就是数据库层面的“后悔药”，在数据进入之前就拦住这种不一致。
默认值（Default）解决的是“不填的时候给什么”的问题。实验里给性别字段设了默认值，给学分字段也设了默认值。这样做的好处是，插入数据时如果没写这一项，数据库自动填上预设的值，既省事又避免出现空值导致的查询异常。这三个约束加在一起，才让数据库从“能存数据”变成“能可信地存数据”。
2.3 图形界面和 SQL 语句：两条路通同一个终点
实验里有个很有意思的设计：同一个建库建表任务，要求用两种方式各做一遍。一种是在管理工具里点鼠标、填表单；另一种是手写 SQL 语句。很多人会问，既然有图形界面，为什么还要学写语句？
图形界面适合初学者快速上手，所见即所得，不容易拼错关键字。但它有两个局限：一是操作步骤多、重复劳动多，建三张表要点几十次；二是没法版本管理，你没法把“点过的按钮”存成一个文件发给别人。SQL 语句则相反，一开始要记语法、容易写错，但一旦写对，它就是一个可复制、可修改、可存档的文本。建库建表的语句保存下来，换一台电脑直接运行就能重建一模一样的环境。
实验要求两种方式都做，其实是在训练一种思维：图形界面让你理解操作的含义，SQL 语句让你理解操作的逻辑。真正工作中，建库建表往往用语句脚本，因为可以纳入版本控制、可以自动化执行；而日常查数据、看结构，图形界面更顺手。两者不是替代关系，是配合关系。
3. 查询语句为什么让人又爱又恨：从单表到多表的认知台阶
3.1 单表查询：把 WHERE 当成筛子用
实验二的前半段全是单表查询，题目看起来五花八门——查计算机系全体学生、查姓李的学生、查没有先行课的课程、查有不及格成绩的学号。但拆开看，套路是一样的：FROM 决定从哪张表里找，WHERE 决定筛掉哪些行，SELECT 决定最后留下哪些列。
比如“查询姓李的学生的学号和姓名”，FROM 后面跟学生表，WHERE 后面写姓名 LIKE ‘李%’，SELECT 后面写学号和姓名。LIKE 是模糊匹配，百分号代表后面可以是任意字符。再比如“查询考试成绩有不及格的学生的学号”，FROM 后面跟选修表，WHERE 后面写分数小于60，SELECT 后面写学号。这里有个容易踩的坑：同一个学生可能有多门课不及格，直接查会查出重复学号，需要加 DISTINCT 去重。
单表查询里还藏着一个分组统计的入门点：查选修了两门以上课程的学生学号和课程数。这里用到了 GROUP BY 和 HAVING。GROUP BY 把同一个学号的记录归成一组，COUNT 数出每组有几条，HAVING 再筛掉数量不够的组。注意 WHERE 和 HAVING 的区别——WHERE 在分组之前筛行，HAVING 在分组之后筛组。这个区别在实验里反复出现，是初学者最容易混淆的地方之一。
3.2 多表连接查询：把两张表拼成一张宽表
到了多表查询，难度上了一个台阶。实验里要求“查询选修了数据库原理的计算机系学生的学号和姓名”。学号和姓名在学生表里，课程名在课程表里，选课关系在选修表里。要回答这个问题，必须把三张表连起来。
连接的核心是找到表与表之间的“挂钩字段”。学生表和选修表通过学号挂钩，课程表和选修表通过课程号挂钩。写查询的时候，FROM 后面跟多张表，WHERE 后面写连接条件，比如学生表.学号等于选修表.学号，选修表.课程号等于课程表.课程号。这样数据库就会把三张表里匹配的行拼在一起，形成一张临时宽表，然后再用 WHERE 筛出计算机系和数据库原理这两个条件。
实验里还专门要求比较内连接和外连接的结果。内连接只保留两张表里都能匹配上的行，外连接则保留其中一张表的全部行，另一张表匹配不上的地方填空值。举个例子：查所有学生的信息和他们的选课情况。如果用内连接，没选课的学生就不会出现在结果里；如果用左外连接，没选课的学生也会出现，只是课程相关字段显示为空。这个区别在做统计报表的时候特别关键——你到底是只想看选了课的人，还是想看所有人包括没选课的。
3.3 嵌套查询和组合查询：查询里的套娃和集合运算
实验三把难度拉到了嵌套和组合。嵌套查询就是在一个查询语句里面再写一个查询语句，内层的结果给外层用。比如“查询没有选修数据库原理课程的学生信息”，可以先在内层查出选修了数据库原理的学生学号，然后在外层用 NOT IN 排除掉这些人。
组合查询用的是 UNION、INTERSECT、EXCEPT 这三个集合运算符。UNION 把两个查询结果合并去重，INTERSECT 取两个结果的交集，EXCEPT 取差集。实验里要求同一个需求用两种方法实现——比如“查询被0602001或0602002选修的课程号”，既可以用 UNION 组合两个查询，也可以用 IN 条件加子查询。这两种写法结果一样，但思路不同：UNION 是先把两个结果集算出来再合并，IN 是先算出目标集合再逐行判断。理解这两种思路的差异，比记住语法更重要，因为在实际工作中，不同的写法在数据量大的时候性能可能差很多。
4. 这些概念最容易搞混：五个初学者常踩的坑
4.1 主码和外码：一个管唯一，一个管引用
易混点：主码和外码都带“码”字，都跟表里的字段有关，初学者经常分不清哪个是哪个。
为什么混：两者都是约束，都写在建表语句里，而且外码经常引用另一张表的主码，看起来像“亲戚”。
怎么区分：主码管的是“这一行我是谁”，必须唯一、不能为空，一张表只能有一个主码。外码管的是“我引用的那一行必须存在”，可以有重复、可以为空（取决于业务规则），一张表可以有多个外码。简单记：主码是身份证，外码是介绍信——介绍信上写的那个单位必须真实存在，但介绍信本身可以有很多张。
4.2 WHERE 和 HAVING：筛的时机不一样
易混点：两个都是用来筛数据的，写在一起的时候经常搞不清哪个该放前面。
为什么混：语法上 WHERE 在 GROUP BY 之前，HAVING 在 GROUP BY 之后，但写查询的时候是从 SELECT 开始写的，顺序感不强。
怎么区分：WHERE 在分组之前执行，筛的是原始行，不能用聚合函数（比如 COUNT、SUM）。HAVING 在分组之后执行，筛的是分组结果，可以用聚合函数。比如“查平均分大于80的学号”，平均分是聚合出来的，必须用 HAVING；而“查分数大于80的记录”，分数是原始字段，用 WHERE。
4.3 内连接和外连接：丢不丢行的问题
易混点：连接查询写起来差不多，但结果行数可能差很多。
为什么混：内连接和外连接在语法上只差几个关键字，不实际跑数据很难直观感受区别。
怎么区分：内连接只保留两边都能匹配上的行，匹配不上的直接丢掉。左外连接保留左表所有行，右表匹配不上的填空值。右外连接反过来。全外连接两边都保留。判断用哪个的标准很简单：你是不是想看到“没有匹配项”的那些行。想看到就用外连接，不想看到就用内连接。
4.4 UNION 和 UNION ALL：去重与不去重
易混点：两个都是合并结果集，名字只差一个 ALL。
为什么混：大部分时候结果看起来一样，只有在两个查询有重复行的时候才暴露差异。
怎么区分：UNION 会自动去掉重复行，UNION ALL 保留所有行包括重复的。去重是有代价的——数据库要对结果排序或哈希，数据量大时明显更慢。所以如果你确定两个查询结果不会重复，或者你本来就要保留重复，用 UNION ALL 更快。实验里没强调这个区别，但实际工作中这是个性能优化的常识。
4.5 嵌套查询和连接查询：干同一件事的两条路
易混点：很多需求既可以用嵌套查询写，也可以用连接查询写，结果一样，不知道该选哪个。
为什么混：两者在逻辑上可以互相转换，初学者容易觉得“既然结果一样，随便写哪个都行”。
怎么区分：嵌套查询更接近人的思考方式——先找出满足某个条件的人，再查这些人的其他信息。连接查询更接近数据库的执行方式——把表拼在一起再筛。一般来说，数据量小的时候两者差别不大；数据量大的时候，连接查询往往更容易被数据库优化器处理。但嵌套查询在表达“不存在”“全部满足”这类逻辑时更自然。选择的标准不是对错，而是可读性和性能的平衡。
5. 什么时候该用数据库思维：一个选课系统的边界判断
假设你是一个刚学完数据库原理实验的学生，有人找你帮忙做一个“班级小工具”，用来记录同学的交作业情况。你该不该上数据库？
先看数据量和并发。如果只是一个班三四十人，每人每学期交十次作业，总共几百条记录，而且只有你一个人录入和查询，那用电子表格就够了。电子表格有行有列，也能筛选排序，学习成本几乎为零。这时候上数据库，属于杀鸡用牛刀，光装管理工具、建库建表、写连接查询的时间，就够你把表格用得很熟了。
但如果情况变成这样：三个班的同学都要用，每个人自己登录查看自己的作业状态，老师要按班级、按作业次数统计提交率，还要防止有人改掉别人的记录——这时候电子表格就撑不住了。多人同时编辑会冲突，权限控制几乎没有，统计逻辑每次都要手动重算。数据库的价值就体现出来了：用学号做主码保证每人一条记录，用外码关联班级表和作业表，用视图给不同角色看不同的数据，用权限控制谁能改谁不能改。
再往深一层，判断标准可以归纳成三条。第一，数据之间有没有明确的关系需要维护。如果只是孤立的一张清单，表格够用；如果学生、课程、成绩之间有交叉引用，数据库的外码约束能帮你省掉很多手动核对。第二，有没有多人同时读写。数据库的事务机制能保证两个人同时改不会互相覆盖，表格做不到。第三，查询需求是不是经常变化。数据库的 SQL 是声明式的，你描述“要什么”，不用管“怎么找”；表格的筛选虽然简单，但复杂条件组合起来很繁琐。
反过来，什么时候别用数据库？数据量极小且几乎不变、只有一个人用、不需要跨表关联、对查询速度没要求——这四个条件同时满足的时候，老老实实用表格或者文本文件，别给自己找麻烦。我见过有人为了记十个人的通讯录装了一整套数据库环境，每次查电话还要写 SELECT 语句，这就是典型的过度设计。
从那以后我每次动手存数据之前，都强制走一遍这三条判断：有没有关系要维护、有没有并发、查询会不会变复杂。三条里中了两条，才考虑上数据库；只中一条，先想想更轻的方案。希望这个判断习惯也能帮到你。
这份数据库原理实验报告把建库、建表、单表查询、多表连接、嵌套组合查询串成了一条完整的动手路径，适合想系统过一遍数据库入门操作的人对照练习。需要完整资料的话，可以顺着这份实验报告的目录逐项做一遍，比只看不练扎实得多。
本文还有配套的精品资源，点击获取
