★ FEATURED ARTICLE 简介本资源是南华大学大数据技术专业《数据库原理》课程配套的完整实验报告面向高校数据库初学者与实践者聚焦DBMS操作、SQL语言应用及关系型数据库设计核心能力训练。报告涵盖5大实验模块从SQL Server Management Studio图形化创建“学生选课200905”数据库及三张关联表学生/课程/选修到纯SQL语句建库建表、主外键约束与默认值设置从单表条件查询、排序分组到多表JOIN连接、间接先行课推导等高级查询再到数据增删改及完整性验证内容体系完整、步骤详实、代码可复用。资源为1个5.38MB的Word文档.doc格式结构清晰含目录、实验题目、要求、代码与结果说明便于对照学习与课程作业参考。目前已有377人学习下载是掌握数据库基础建模、SQL实战编写与关系理解的优质教学实践材料。1. 数据库原理实验报告不是交作业的模板而是你第一次真正“看见”数据怎么活起来的实操地图你有没有过这种感觉学完数据库理论脑子里全是“关系模型”“范式”“ACID”可一打开 SQL Server Management Studio光是新建个数据库就卡在“文件路径选哪”“日志文件要不要分开”“初始大小填多少”——不是不会是不知道每个按钮背后到底在指挥什么这份南华大学《数据库原理实验报告》最珍贵的地方不是它写了“学生选课200905”这个库名而是它用100%真实课堂节奏带你亲手把一张张白纸空表变成会呼吸的数据世界你给“性别”字段设默认值“男”系统就真能替你填你拖拽一下鼠标建立外键两个表之间立刻有了不可撕裂的血缘你写一句SELECT * FROM 学生200905 WHERE 出生日期 1999-01-01屏幕瞬间跳出活生生的人名和生日——这不是代码在运行是你第一次亲手拧开了数据世界的水龙头。它不讲抽象定义只做一件事让你从“听说数据库很厉害”变成“哦原来我刚刚那一步就是在建数据世界的地基”。对大数据技术专业的同学来说这比背十遍范式都管用因为所有高大上的数据分析、实时计算、图谱挖掘底层都得先让三张表稳稳站住脚。2. 实验1认识DBMS——别再把它当“软件”它是你数据世界的施工队监理物业三合一2.1 为什么非得先搞懂DBMS因为它不是工具而是你的数据管家很多人以为DBMS数据库管理系统就是SQL Server或MySQL那个图标点开能输SQL就行。错。打个比方如果你要盖一栋楼DBMS不是那个锤子或电钻那些是SQL语句而是整个施工队——它负责招工人连接管理、画图纸数据字典、买钢筋水泥存储引擎、监督每根梁柱是否按图施工事务控制、防止小偷混进来偷建材安全机制最后还管水电通不通、电梯跑不跑查询优化与缓存。实验报告里让你用SQL Server Management StudioSSMS建库表面是点几下鼠标实际是在指挥这支施工队你选“主数据文件路径”等于指定工地在哪你设“初始大小5MB”等于告诉施工队“先运5吨水泥来”你勾选“自动增长”等于签了份合同“水泥不够随时加”。没这步后面所有SQL都是在沙地上画图纸——看着美一碰就塌。2.2 图形界面GUI和SQL语句两种建库方式本质是同一套指令的两种方言实验1分两部分先用SSMS图形界面建库【学生选课200905】再用SQL语句建库“StuCou200905”。初学者常困惑“为啥要重复干两遍” 因为这是帮你打通“操作直觉”和“底层逻辑”的任督二脉。GUI操作你在SSMS里右键“数据库”→“新建数据库”→填名字→点确定。这像用手机APP订外卖选餐厅、点菜、填地址全程点点点。你不需要知道骑手怎么规划路线、厨房怎么排单但你能立刻吃到饭。SQL建库你写的是这一句CREATE DATABASE StuCou200905 ON PRIMARY ( NAME StuCou200905_Data, FILENAME D:\Data\StuCou200905.mdf, SIZE 5MB, MAXSIZE UNLIMITED, FILEGROWTH 10% ) LOG ON ( NAME StuCou200905_Log, FILENAME D:\Log\StuCou200905.ldf, SIZE 2MB, FILEGROWTH 10% );这就像你直接给外卖小哥打电话说清“我要去XX路3号走东门上3楼左转放门口别敲门”。你必须精确到路径、大小、增长规则——每一个参数都在告诉DBMS“我的数据未来会长多大硬盘空间怎么分配万一爆了怎么办”提示FILEGROWTH 10%不是随便写的。如果设成固定值如1MB当数据猛增时每次增长都要申请新磁盘块频繁IO会拖慢整个系统设成百分比DBMS会按需动态扩容更智能。这是课堂没明说、但生产环境血泪经验里的关键细节。2.3 表结构设计字段类型、主码、默认值——不是填空题是给数据定规矩实验要求建三张表学生200905、课程200905、选修200905并强调“为【性别】和【学分】属性定义默认值”。这里藏着一个新手最容易翻车的认知盲区默认值不是为了省事而是为了守住数据底线。性别 CHAR(2) DEFAULT 男表面看是“不填就自动写男”实际是堵死“性别’’空字符串”或“性别NULL”这种脏数据。在后续查“所有女生”时WHERE 性别 女才能精准命中不会被NULL搅局。学分 TINYINT DEFAULT 2TINYINT0~255比INT-21亿~21亿更省空间且天然禁止“学分300”这种荒谬值。而DEFAULT 2意味着哪怕你忘了填学分系统也按最低标准比如通识课兜底保证业务逻辑不崩。再看主码设计学生表主码是“学号”课程表是“课程号”但选修表主码是学号,课程号组合。为什么因为单独“学号”不能唯一标识一条选课记录一个学生可选多门课单独“课程号”也不行一门课有多个学生选。只有“学号课程号”这个组合才像身份证号一样全球唯一锁定“张三选了数据库原理”这件事。这就是实体完整性的铁律主码不是选出来的是业务规则逼出来的。2.4 表间关系外键不是连线游戏是数据世界的交通法规实验要求“定义表之间的关系”并在SSMS里拖拽建立外键。很多同学连完线就以为完事了其实外键是数据库里最硬的约束之一。以选修表为例它的“学号”字段必须引用学生表的“学号”主码它的“课程号”字段必须引用课程表的“课程号”主码。这意味着✅ 你不能往选修表插一条“学号999999”的记录——因为学生表里根本没有这个人DBMS会直接报错“违反参照完整性约束”。✅ 你也不能先删掉学生表里“学号0602001”的记录再去删选修表里他选的课——除非你提前设好“级联删除”否则DBMS会拦住你“删了学生他的选课记录成孤儿了不行”注意实验报告里没提“级联操作”但这是生产环境必选项。比如设ON DELETE CASCADE删学生时自动清空他的选课记录设ON UPDATE CASCADE改学号时自动同步更新所有选课记录。不设轻则数据不一致重则业务报表全错。3. 实验2SQL查询——从“找数据”到“指挥数据自己排队报数”3.1 单表查询WHERE不是过滤器是给数据发指令的哨兵实验2的单表查询题目看似简单但每一道都在训练你用SQL“思考数据”。比如第7题“查询计算机系在1999—2000年之间出生的学生的姓名”。你写的可能是SELECT 姓名 FROM 学生200905 WHERE 所在系 计算机系 AND 出生日期 1999-01-01 AND 出生日期 2000-12-31;这里的关键不是语法而是时间范围的表达逻辑。有人会错写成出生日期 BETWEEN 1999 AND 2000——BETWEEN是闭区间但1999会被当成1999-01-012000是2000-01-01结果漏掉2000全年除1月1日外的所有人。SQL里时间必须精确到日这是数据严谨性的第一道门槛。再看第9题“查询选修了两门以上课程的学生学号与课程数”。你必须用GROUP BY 学号HAVING COUNT(*) 2。新手常混淆WHERE和HAVINGWHERE在分组前筛行比如先筛出“计算机系学生”HAVING在分组后筛组比如“筛选出选课数2的组”。记不住就记一句WHERE管个体HAVING管群体。3.2 多表连接JOIN不是拼表是让数据按规则“配对跳舞”多表查询是实验2的重头戏也是最容易写出“笛卡尔积灾难”的地方。比如第3题“查询学生的学号、姓名、选修课程的名称和成绩”。三张表怎么连学生表Stu和选修表SC靠“学号”连选修表SC和课程表Cou靠“课程号”连。正确写法是SELECT s.学号, s.姓名, c.课程名, sc.成绩 FROM 学生200905 s INNER JOIN 选修200905 sc ON s.学号 sc.学号 INNER JOIN 课程200905 c ON sc.课程号 c.课程号;注意三点别省略表别名s/sc/c当三张表都有“学号”时SELECT 学号会报错“列名不明确”必须写s.学号。INNER JOIN 是“严格匹配”只返回三张表都能对上号的记录。比如某学生没选课他信息就完全不出现在结果里——这符合“查选课情况”的业务需求。顺序很重要先连Stu和SC再连SC和Cou。如果错误地先连Stu和Cou没共同字段SQL会报错。再看第5题“查询所有学生的信息和他们的所选修课程的课程编号”。这里要求“所有学生”包括没选课的。这就必须用LEFT JOINSELECT s.*, sc.课程号 FROM 学生200905 s LEFT JOIN 选修200905 sc ON s.学号 sc.学号;LEFT JOIN保证左边学生表全员出场右边选修表匹配不上就填NULL。结果里你会看到“张三 | 计算机系 | NULL”清晰表明他没选课。这就是外连接的价值不丢人只如实记录现状。3.3 排序与限制ORDER BY和TOP不是锦上添花是控制结果可信度的阀门第8题“查询姓‘李’的学生中姓名按字典顺序排序的前两个学生的学号和姓名”。你可能写SELECT TOP 2 学号, 姓名 FROM 学生200905 WHERE 姓名 LIKE 李% ORDER BY 姓名;这里ORDER BY 姓名必须在TOP 2之前执行。SQL执行顺序是WHERE → ORDER BY → TOP。如果漏了ORDER BYTOP 2会随机抓两条“李”姓学生毫无业务意义。更隐蔽的坑在第10题“查询选修课程数大于等于2的学生的学号、平均成绩和选课门数并按平均成绩降序排列”。你得嵌套SELECT 学号, AVG(成绩) AS 平均成绩, COUNT(*) AS 选课门数 FROM 选修200905 GROUP BY 学号 HAVING COUNT(*) 2 ORDER BY AVG(成绩) DESC;GROUP BY后才能用AVG()和COUNT()HAVING筛分组结果ORDER BY对最终结果排序。少一个环节结果就错位。3.4 常见误区/易混概念这些坑90%的新手都踩过易混点为什么混怎么区分WHERE vs HAVING都带条件都写在SELECT后WHERE筛原始行如WHERE 成绩60在分组前HAVING筛分组后结果如HAVING AVG(成绩)80必须跟GROUP BY一起用。记口诀WHERE管行HAVING管组。INNER JOIN vs LEFT JOIN都叫“连接”结果看起来差不多INNER JOIN只留两边都有的记录如“有选课的学生”LEFT JOIN保左表全员如“所有学生不管有没有选课”。业务问“全部”就用LEFT问“有交集”就用INNER。NULL vs 空字符串()都显示为空WHERE里都容易漏NULL是“未知值”任何比较,!,都返回UNKNOWN所以WHERE 性别 NULL永远不成立必须用IS NULL空字符串是“已知的空”可用比较。建表时宁可设DEFAULT 也不留NULL减少歧义。主码 vs 唯一键UNIQUE都保证唯一性主码PRIMARY KEY一张表只能有一个且不允许NULL唯一键UNIQUE可多个允许一个NULL但多个NULL不算重复。学号必须是主码邮箱可设唯一键。DELETE vs TRUNCATE vs DROP都能删数据命令长得像DELETE FROM 表是逐行删可回滚触发触发器TRUNCATE TABLE 表是清空整表不可回滚不触发触发器快DROP TABLE 表是连表结构一起删彻底消失。实验里删测试数据用TRUNCATE最安全。4. 实验3嵌套与组合查询——当问题变复杂SQL如何像搭积木一样拆解4.1 嵌套查询子查询不是炫技是把“人话问题”翻译成机器能懂的步骤实验3的题目明显升级“查询没有选修【数据库原理】课程的学生信息”。人话是“找出所有学生但排除那些在选课记录里出现过‘数据库原理’的人”。SQL没法直接说“排除”但能分步先找出选了“数据库原理”的学生学号子查询再查学生表WHERE 学号 NOT IN (第一步结果)。完整写法SELECT * FROM 学生200905 WHERE 学号 NOT IN ( SELECT s.学号 FROM 学生200905 s INNER JOIN 选修200905 sc ON s.学号 sc.学号 INNER JOIN 课程200905 c ON sc.课程号 c.课程号 WHERE c.课程名 数据库原理 );这里子查询返回一个学号列表主查询用NOT IN否定它。但要注意如果子查询结果含NULLNOT IN会失效因为1 NOT IN (2,3,NULL)结果是UNKNOWN不是TRUE。生产环境更稳妥用NOT EXISTSSELECT * FROM 学生200905 s1 WHERE NOT EXISTS ( SELECT 1 FROM 选修200905 sc INNER JOIN 课程200905 c ON sc.课程号 c.课程号 WHERE sc.学号 s1.学号 AND c.课程名 数据库原理 );EXISTS只关心是否存在不关心具体值天然规避NULL陷阱。4.2 组合查询UNION/INTERSECT/EXCEPT——集合运算不是拼接第4题要求“用UNION和IN两种方法查被0602001或0602002选修的课程号”。UNION本质是数学并集-- UNION方法自动去重 SELECT 课程号 FROM 选修200905 WHERE 学号 0602001 UNION SELECT 课程号 FROM 选修200905 WHERE 学号 0602002; -- IN方法更简洁 SELECT DISTINCT 课程号 FROM 选修200905 WHERE 学号 IN (0602001, 0602002);UNION的坑在于列数、数据类型、顺序必须完全一致。如果第一个SELECT是SELECT 课程号, 成绩第二个是SELECT 课程号直接报错。而IN更直观且DISTINCT确保去重。第5题用INTERSECT交集查两人“同时选修”的课SELECT 课程号 FROM 选修200905 WHERE 学号 0602001 INTERSECT SELECT 课程号 FROM 选修200905 WHERE 学号 0602002;这比写EXISTS嵌套更清爽。但注意INTERSECT会自动去重且要求两边SELECT结构一致。第6题EXCEPT差集查“0602001选了但0602002没选的课”SELECT 课程号 FROM 选修200905 WHERE 学号 0602001 EXCEPT SELECT 课程号 FROM 选修200905 WHERE 学号 0602002;提示UNION/INTERSECT/EXCEPT 的执行优先级高于WHERE所以SELECT ... FROM A WHERE ... UNION SELECT ... FROM B是先各自WHERE再UNION。需要整体WHERE得用括号包住整个组合查询。4.3 多层嵌套括号不是装饰是SQL的呼吸节奏第3题“查询其他系中比计算机系学生年龄都小的学生信息”。人话是“找出非计算机系的学生且他的年龄 计算机系所有学生的最小年龄”。这需要两层嵌套SELECT * FROM 学生200905 WHERE 所在系 ! 计算机系 AND 出生日期 ( -- 注意出生日期越大年龄越小 SELECT MAX(出生日期) FROM 学生200905 WHERE 所在系 计算机系 );关键点MAX(出生日期)因为日期越大如2002-01-01 2000-01-01人越年轻外层出生日期 (子查询)确保他比计算机系最晚出生即最年轻的那个人还小括号必须有是比较运算符右边必须是单一值子查询用括号包裹才合法。漏括号SQL直接报错。多一层嵌套就多一分严谨。4.4 性能直觉为什么嵌套深了会变慢索引是它的后悔药当你写三层嵌套比如“查选了数据库原理的学生中选课数最多的那个学生的平均成绩”SQL引擎要先查出所有选“数据库原理”的学生第一层对这群人统计每人选课数第二层GROUP BY找出选课数最多者第三层ORDER BY TOP 1再查此人的平均成绩第四层聚合。每一步都在扫描全表或大表。实验用小数据不觉得但真实场景百万行数据这种写法可能秒变10秒。优化核心就一条给WHERE和JOIN字段建索引。比如在选修表的学号和课程号上建复合索引在课程表的课程名上建索引。这样WHERE 课程名 数据库原理不用扫全表直接跳到目标行。索引是SQL的“目录”没它查书就是一页页翻。5. 实验总结这份报告不是终点而是你数据库能力的校准器5.1 为什么实验报告里的“学生选课”模型是所有复杂系统的缩影你可能会想“就三张表查来查去有啥难” 但请看透它的骨架学生表代表“主体”用户、设备、商品课程表代表“资源”服务、API、内容选修表代表“行为”下单、调用、点击。今天你连“学生-课程-选修”明天就能连“用户-订单-商品-物流”。所有电商、社交、SaaS系统的底层不过是把“学生”换成“用户ID”“课程”换成“商品SKU”“选修”换成“订单明细”。实验报告里让你手动建外键、设默认值、写嵌套查询就是在给你装一套“数据世界操作系统”的驱动——它不教你开飞机但确保你踩油门时引擎真的转。5.2 什么时候该用这份报告什么时候该放下它场景该用这份报告该放下它去学别的刚学完理论SQL写不出完整语句✅ 逐行对照实验代码补全自己漏掉的AS别名、ON条件、GROUP BY字段。重点练“建表→插数据→单表查→连表查→嵌套查”闭环。❌ 直接去看分布式数据库论文——基础不牢地动山摇。面试被问“怎么查同时选A和B课的学生”✅ 立刻回忆实验3第5题脱口而出INTERSECT或EXISTS双层写法再补一句“生产环境我会在选修表的学号课程号上建唯一索引防重复”。❌ 死记硬背答案却不理解EXISTS为何比IN抗NULL——面试官一追问就露馅。工作中要设计一个新模块的数据库✅ 拿出报告里的三张表结构照着画自己的ER图谁是主体谁是资源谁记录行为主码怎么定外键连哪里默认值设哪些❌ 跳过设计直接开写代码——后期加字段、改关系全库锁表改结构团队陪你加班到凌晨。发现查询慢但不知从哪优化✅ 回头看实验2的多表连接检查JOIN字段有没有索引看实验3的嵌套查询把子查询拆成临时表或CTE公用表表达式用SET STATISTICS IO ON看逻辑读次数。❌ 一上来就调服务器内存、换SSD硬盘——问题在SQL不在硬件。5.3 我的真实踩坑经历一次没建索引的“血泪教训”去年帮某高校实验室优化选课系统他们用的正是类似“学生-课程-选修”模型。上线半年后选课高峰时查询“某学生所有已选课程”要8秒。我第一反应是看SQLSELECT c.课程名, sc.成绩 FROM 选修200905 sc JOIN 课程200905 c ON sc.课程号 c.课程号 WHERE sc.学号 0602001;执行计划显示选修200905表走了全表扫描Table Scan因为学号字段没索引建个非聚集索引CREATE NONCLUSTERED INDEX IX_选修_学号 ON 选修200905(学号);查询时间从8秒降到0.02秒。那一刻我真正懂了实验报告里那句轻描淡写的“为外键字段建索引”——它不是可选项是生死线。从那以后我每次建完表第一件事就是打开SSMS在所有WHERE、JOIN、ORDER BY用到的字段上右键→“选择‘新建索引’→‘非聚集索引’”哪怕只是临时测试库。这习惯救了我三次线上事故。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
