简介：一份围绕广东工业大学数据库课程设计而完成的机房管理系统课程设计报告，以机房上机管理为业务场景，完整覆盖系统需求分析、总体设计、数据库设计、应用程序调试与界面设计等环节，适合作为数据库课程设计学生、管理信息系统初学者及相关项目开发者的参考模板。报告为单个Word文档，压缩包共1个doc文件，大小1.27MB；文档从问题描述、开发背景、开发目的出发，逐步给出系统总体功能模块图、菜单设计、E-R图设计、数据库逻辑模型、T-SQL建表语句和PowerBuilder下的应用调试细节，涵盖设备采购、登记、借用归还、配件与消耗品管理等功能说明，章节安排清晰，可直接对照学习。已有185人学习浏览，对同类课程作业或毕业设计具有一定借鉴意义。借助这份资料，读者可以掌握如何将机房设备采购、登记、借用归还、配件与消耗品管理、设备问题登记、维修与报废等业务需求转化为数据库表结构，并理解查询统计模块与操作界面的实现路径；同时，报告还展示了问题描述至成果显示的完整行文逻辑，适合用于课程设计文档撰写、系统实现复盘和答辩准备。
1. 机房管理系统课设的核心不是界面，而是那张“上机记录表”
很多同学下载过“广东工业大学数据库课程设计机房管理系统设计”这类完整word版课设文档，打开一看，需求分析、ER图、表结构、界面截图、测试用例全都有，心里就踏实了。但照着折腾两三天就会发现，真正卡人的永远不是界面能画多好看，而是数据库里那张“上机记录表”怎么设计——它同时关联学生、机器、机房、计费四类数据，一个字段类型选错、一个外键关系理不清，后面所有增删改查和统计报表全部返工。下面按做这个方向最常见的成熟路径讲清楚：需求怎么拆、ER图怎么画、表怎么建、业务函数怎么写、答辩时怎么把设计讲圆。这里的读者应该是正在做数据库课程设计的学生，或者准备带同样题目的助教。
2. 先把管理需求拆成实体关系：机房课设里的ER图为什么不能省
2.1 四类角色和一条核心业务链
机房管理系统在设计层面的第一步，不是打开MySQL写建表语句，而是先把机房里的真实业务压缩成一条流程。常见做法是分四类角色：学生、值班管理员、系统管理员、维护员。学生要做的是预约机房、上机、下机、查看余额；值班管理员处理上下机登记和临时换机；系统管理员维护学生信息、机器状态和计费规则；维护员只看机器故障。
核心业务流程只有一条：学生刷卡或输入账号上机，系统从该机房挑一台空闲机器分配出去，开始计时；学生下机时，系统根据计费规则算出费用，从余额里扣款，释放机器，把整段过程写进上机记录。这条链里的每一个环节都会被后面设计的表接住。所谓“系统设计”，在数据库课程设计里就是指把这条链完整映射成表、字段和表间关系，而不是堆功能菜单。
还要注意机房管理系统的特殊点：它天然带有“时间段”属性。同一台机器上午被A用、下午被B用，是两条互不干扰的上机记录；同一个学生今天用3号机、明天用7号机，也是两条记录。这意味着学生和机器之间不是简单的一对多，而是多对多关系，必须靠中间表来承接。这一点想不清楚，后面画ER图一定会别扭。
2.2 ER图的关键不是画得漂亮，而是把“上机记录”这张联系表画对
ER图里最容易被画错的就是“上机记录”这个实体。很多人把它画成学生和机器之间的一根连线，旁边写个“上机”，然后就没下文了。但仔细拆业务，上机这件事自带一堆属性：开始时间、结束时间、使用时长、费用、当时用的是哪台机器、机器所在机房、是否已结算。这些属性任何一个都不能挂在学生头上，也不能挂在机器头上，只能挂在“上机记录”这一条关系上。
正确画法是把它提升成“联系实体”。学生和上机记录是一对多，一个学生可以有很多条上机记录；机器和上机记录也是一对多，一台机器被不同学生使用会积累多条记录。联系实体的主键建议用自增记录ID，不要把学生ID+机器ID拼成联合主键，因为同一个人在一台机器上用两次是完全合法的，联合主键会限制业务。
除了这个核心联系，ER图里还要有预约记录。预约和学生、机房产生关系，但它不等同于上机记录。预约只是“预定某个时间段的使用权”，上机是“实际发生了一次使用”。很多课设把预约和上机混在一张表里，导致一个字段要同时表达“已预约”“已上机”“已取消”“已完成”，状态机混乱。这是设计层面的第一个坑，宁可多建一张表，也别用一张表硬撑。
2.3 范式选型：课设推进到第三范式就停手
数据库知识点概念里，范式是必考的，但课设里要不要把表拆到4NF、5NF，答案基本是不需要。机房管理系统做到第三范式就足够撑起完整业务，而且好答辩。
第一范式要求每个字段不可再分。比如“姓名”不要拆成“姓”和“名”；“机器IP+机器名”这种复合信息不要塞进同一个字段。第二范式要求非主键字段完全依赖主键，而不是依赖主键的一部分。比如机器表里，机器IP只依赖机器编号，机房位置也只依赖机器编号，这没问题；但如果你把“机房负责人电话”也放进机器表，它就只依赖机房而不是机器，这就是部分依赖，违反了第二范式。
第三范式要求消除传递依赖。举个例子，机器表里存了机房编号，这是对的；但如果同时存了机房名称和机房位置，机房名称其实是通过机房编号推导出来的，一旦机房改名就要改很多行，这就是传递依赖。正确做法是单独建机房表，机器表只存机房编号，查询时用JOIN把机房名称带出来。
要不要故意留一点冗余？其实可以，但要能解释清楚。学生表里的“余额”字段，严格来说可以从充值记录累加得到，属于冗余；但计费模块每次上机都要立刻判断余额是否够扣，每次都去汇总充值记录和消费记录会拖慢事务，所以余额字段是“面向高频查询的冗余”，这在课设答辩里是个加分项，重点是要主动讲出来，而不是等老师问。
3. 把ER图落成MySQL建表脚本：五张核心表与两个必填字段
3.1 最小建库脚本：编码、引擎、主键一次到位
回到数据库增删改查这条主线上，机房管理系统的最小落地是建五张表：学生表、机房表、机器表、上机记录表、计费规则表。预约表可以等主流程跑通后再加。这里给一套能直接跑的MySQL建库脚本，我在课设里也常用这套结构：
CREATE DATABASE IF NOT EXISTS lab_manage DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE lab_manage; CREATE TABLE student ( stu_id CHAR(12) NOT NULL COMMENT '学号，主键', stu_name VARCHAR(20) NOT NULL COMMENT '姓名', college VARCHAR(50) DEFAULT '计算机学院' COMMENT '学院', balance DECIMAL(8,2) DEFAULT 0.00 COMMENT '账户余额', status TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0停用', PRIMARY KEY (stu_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表'; CREATE TABLE room ( room_id INT NOT NULL AUTO_INCREMENT COMMENT '机房编号', room_name VARCHAR(30) NOT NULL COMMENT '机房名称', location VARCHAR(50) DEFAULT NULL COMMENT '所在位置', open_time TIME DEFAULT '08:00:00' COMMENT '开放时间', close_time TIME DEFAULT '22:00:00' COMMENT '关闭时间', PRIMARY KEY (room_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='机房表'; CREATE TABLE computer ( computer_id INT NOT NULL AUTO_INCREMENT COMMENT '机器编号', room_id INT NOT NULL COMMENT '所属机房', ip_address VARCHAR(15) DEFAULT NULL COMMENT 'IP地址', status TINYINT NOT NULL DEFAULT 1 COMMENT '1空闲 2使用中 3故障 4维护', PRIMARY KEY (computer_id), KEY idx_room (room_id), CONSTRAINT fk_computer_room FOREIGN KEY (room_id) REFERENCES room (room_id) ON UPDATE CASCADE ON DELETE RESTRICT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='计算机信息表';这段脚本里有几个选择不是随手写的。字符集用utf8mb4而不是utf8，因为机房管理系统里学生姓名、学院名都可能出现生僻字或表情符号，utf8mb4才能完整覆盖；引擎用InnoDB，因为上机记录表需要事务和行级锁，MyISAM在这两种场景下都靠不住。学号用CHAR(12)固定长度，因为高校学号一般不会变长度，定长字符串在等值查询里性能更好。机器表的room_id建了普通索引，外键约束用ON DELETE RESTRICT，意思是机房下有机器时不允许直接删机房，这是为了避免误删导致机器变成“无主资产”。
3.2 上机记录表要设计成“事实表”：状态用tinyint，金额用decimal
上机记录表是整个系统的核心，它承载的是一次上机事件的完整事实，至少要包含“谁、在哪台机器、什么时候开始、什么时候结束、用了多久、花了多少钱、现在什么状态”。建表语句如下：
CREATE TABLE usage_record ( record_id BIGINT NOT NULL AUTO_INCREMENT COMMENT '上机记录ID', stu_id CHAR(12) NOT NULL COMMENT '学号', computer_id INT NOT NULL COMMENT '机器编号', start_time DATETIME NOT NULL COMMENT '上机开始时间', end_time DATETIME DEFAULT NULL COMMENT '下机结束时间', duration_min INT DEFAULT NULL COMMENT '使用时长，分钟', total_fee DECIMAL(6,2) DEFAULT NULL COMMENT '本次上机费用', status TINYINT NOT NULL DEFAULT 1 COMMENT '1上机中 2已下机 3已结算 4异常', PRIMARY KEY (record_id), KEY idx_stu_time (stu_id, start_time), KEY idx_computer_status (computer_id, status), CONSTRAINT fk_record_stu FOREIGN KEY (stu_id) REFERENCES student (stu_id) ON UPDATE CASCADE ON DELETE RESTRICT, CONSTRAINT fk_record_computer FOREIGN KEY (computer_id) REFERENCES computer (computer_id) ON UPDATE CASCADE ON DELETE RESTRICT ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='上机记录表';这张表里有两个字段选择值得展开。第一个是status字段，很多课设习惯用VARCHAR存“上机中”“已下机”这种中文描述，但真实项目里几乎不用这种写法。中文状态值在代码里没法方便地比较，比如Java中判断记录是否有效要写成“已上机”.equals(status)，一旦有空格或别名就翻车。用TINYINT配合COMMENT注释，既能索引又能枚举，代码里用常量判断，数据库里可读性靠注释保住。
第二个是费用字段，必须用DECIMAL，不能用FLOAT。浮点类型在算钱时会有精度误差，比如0.1+0.2可能在数据库里算成0.30000000000000004，虽然显示时可四舍五入，但累计统计收入时误差会放大。DECIMAL(6,2)表示费用最多存9999.99元，对机房计费场景完全够用。duration_min字段属于冗余存储，实际可以通过TIMESTAMPDIFF算出来，但这里保存它是因为统计报表要频繁按时长分组，每次都现场计算会拖慢查询，这是典型的时间换空间。
3.3 从表到业务：上下机的两个事务函数
表建好之后，最直接的验证是写一段上下机逻辑跑一遍。这里用Python连接MySQL，展示上机事务的标准写法：
import pymysql def borrow_computer(conn, stu_id, computer_id): try: conn.begin() cur = conn.cursor() # 锁定学生行，防止并发下机时余额被扣成负数 cur.execute( "SELECT balance, status FROM student WHERE stu_id=%s FOR UPDATE", (stu_id,) ) stu = cur.fetchone() if stu is None or stu["status"] != 1: raise Exception("学生不存在或已停用") # 同样锁定机器行，防止同一台机器被同时分配 cur.execute( "SELECT status FROM computer WHERE computer_id=%s FOR UPDATE", (computer_id,) ) comp = cur.fetchone() if comp is None or comp["status"] != 1: raise Exception("机器不在空闲状态") # 写入上机记录，状态为“上机中” cur.execute( "INSERT INTO usage_record(stu_id, computer_id, start_time, status) " "VALUES (%s, %s, NOW(), 1)", (stu_id, computer_id) ) # 机器状态改为“使用中” cur.execute( "UPDATE computer SET status=2 WHERE computer_id=%s", (computer_id,) ) conn.commit() return cur.lastrowid except Exception: conn.rollback() raise这个函数的重点是两把锁和一个事务边界。连接对象的begin()开启事务，两条SELECT FOR UPDATE分别锁定学生行和机器行，锁的作用是在并发场景下，两个请求同时来抢同一台机器时，第二个请求会被阻塞到第一个事务提交后，然后再读取最新状态，发现机器已经是“使用中”就抛出异常。如果不加锁，两台客户端可能同时读到机器空闲，都执行INSERT和UPDATE，最终发生一台机器被两个人占用的逻辑错误。committed之后返回insert的record_id，后续下机操作直接拿这个记录ID来结算。
下机事务和上机对称，核心逻辑是更新end_time、计算时长和费用、扣减余额、释放机器。计算时长用TIMESTAMPDIFF(MINUTE, start_time, NOW())，费用按计费规则算出后更新usage_record，再UPDATE student表扣余额。扣余额时要防止余额不足，也就是把“余额大于本次费用”放在同一个事务里，先查再扣，配合FOR UPDATE锁住学生行，保证不会出现余额扣成负数。这套增删改查结构，本质上就是在回答数据库课程设计最核心的问题：事务边界划在哪里，锁加在哪一行。
4. 预约、计费、统计三条业务链的SQL写法
4.1 预约模块：用唯一约束和时间段查重
机房管理系统除了上下机，预约是第二个高频功能。预约的逻辑是学生选定机房和时间段，系统列出该时间段内空闲的机器，学生确认后生成一条预约记录。在数据库层面，预约表需要设计成能应对“同一台机器在同一时间段只能被一个人预约”的约束。常见做法是在预约表里加时间段表达字段，配合唯一索引兜底，再用查询语句列出可预约的机器。
CREATE TABLE reservation ( resv_id INT NOT NULL AUTO_INCREMENT COMMENT '预约编号', stu_id CHAR(12) NOT NULL COMMENT '学号', room_id INT NOT NULL COMMENT '机房编号', computer_id INT DEFAULT NULL COMMENT '预约的机器编号', resv_date DATE NOT NULL COMMENT '预约日期', time_slot VARCHAR(20) NOT NULL COMMENT '时间段，如18:00-20:00', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待生效 1已上机 2已取消 3已过期', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (resv_id), UNIQUE KEY uk_computer_slot (computer_id, resv_date, time_slot) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预约记录表';唯一键uk_computer_slot是防重复预约的最后一道闸门。即使业务代码里查重逻辑写漏了，数据库也会在插入重复记录时抛出唯一键冲突，直接把错误拦截在底层。查询可预约机器的SQL，核心是排除掉“已被他人占用”的机器：
SELECT c.computer_id, c.ip_address FROM computer c WHERE c.room_id = 101 AND c.status = 1 AND c.computer_id NOT IN ( SELECT computer_id FROM reservation WHERE room_id = 101 AND resv_date = '2025-03-10' AND time_slot = '18:00-20:00' AND status IN (0, 1) ) ORDER BY c.computer_id;这段SQL的NOT IN子查询会先查出目标时间段内状态为“待生效”或“已上机”的机器编号，这些机器不可预约；外层再过滤出当前空闲且不在预约冲突列表里的机器。这里要注意，子查询里的status要包含“已上机”，因为预约过并且已经开始上机的时段，也不能再被预约。如果漏掉这个状态，就会出现预约记录显示空闲、实际已经在使用的脏数据。
4.2 计费模块：费率规则表驱动，费率别写死在代码里
计费是机房管理系统里最容易出现“写死”冲动的地方。有人嫌费表麻烦，直接在代码里写“if 时长<60: 收费2元”，这种写法短期能用，但一旦机房调价，就要改代码重新编译，而且不同的机器类型可能对应不同费率。正确的做法是单独建一张计费规则表，规则引擎从表里读费率。
CREATE TABLE fee_rule ( rule_id INT NOT NULL AUTO_INCREMENT COMMENT '规则编号', rule_name VARCHAR(30) NOT NULL COMMENT '规则名称，如普通上机/通宵', free_minutes INT DEFAULT 0 COMMENT '免费分钟数', initial_minutes INT NOT NULL COMMENT '首段时间，分钟', initial_fee DECIMAL(6,2) NOT NULL COMMENT '首段费用', per_hour_fee DECIMAL(6,2) NOT NULL COMMENT '超出后每小时费用', is_active TINYINT DEFAULT 1 COMMENT '1启用 0停用', PRIMARY KEY (rule_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='计费规则表';费用计算逻辑不要写在SQL里硬算，用代码函数处理更直观。常见规则是“前30分钟收2元，超出部分每小时3元，不足一小时按一小时收，有10分钟免费时长”。Python函数可以这样写：
def compute_fee(rule, duration_min): # rule: 从fee_rule表查出来的一行 free = rule["free_minutes"] if duration_min <= free: return 0.0 remain = duration_min - free if remain <= rule["initial_minutes"]: return float(rule["initial_fee"]) extra = remain - rule["initial_minutes"] hours = (extra + 59) // 60 # 向上取整到小时 return float(rule["initial_fee"]) + hours * float(rule["per_hour_fee"])计费模块要注意两个细节。第一，费用计算的入参duration_min应该是整数分钟，由数据库的TIMESTAMPDIFF得出，避免在应用层用两个Datetime相减得到的浮点数参与计算。第二，计费规则表的is_active字段很重要，机房可能同时存在普通计费和优惠活动两套规则，新上机记录创建时就把当时启用的rule_id快照进上机记录表，避免后续费率调整影响历史记录的对账。
4.3 统计报表：日期分组、COUNT DISTINCT和SUM遇到NULL
机房课设的最后一个大模块是统计报表，常见需求是“按天统计上机人数和收入”“统计各机房机器利用率”“查询某个学生的上机时长排行”。这些报表SQL写起来不难，但有好几个容易翻车的聚合细节。先看最典型的日报表：
SELECT DATE_FORMAT(start_time, '%Y-%m-%d') AS biz_date, COUNT(DISTINCT stu_id) AS user_cnt, IFNULL(SUM(total_fee), 0) AS total_income FROM usage_record WHERE status = 3 AND start_time >= '2025-03-01 00:00:00' AND start_time < '2025-03-02 00:00:00' GROUP BY biz_date ORDER BY biz_date DESC;COUNT(DISTINCT stu_id)统计的是当天实际有多少个学生上过机，而不是上机行为发生多少次。如果一个学生当天上了三次机，COUNT(stu_id)会得到3，COUNT(DISTINCT stu_id)才会得到1，这两者在“上机人数”这种指标里含义完全不同。SUM(total_fee)在MySQL里对全NULL列会返回NULL，不是0，所以要用IFNULL包一层，否则Java或Python后端拿到None直接塞进图表会报错。
日期范围条件用“大于等于当天零点”和“小于明天零点”这种半开区间，比用DATE(start_time) = '2025-03-01'效率高，因为DATE函数包裹在字段上会让索引失效，全表扫描一遍当天的数据才能完成过滤。这也是“数据库知识点概念”里索引失效的典型例子，课设答辩时能主动说清楚这句SQL为什么这么写，比列一堆理论名词更有说服力。
5. 机房管理系统课设避坑：5条让我翻过车的具体问题
5.1 word版文档里的ER图跑不通，得按自己数据库重画
现象：从网上下载的完整word版课设文档里，ER图、关系模式都画得很完整，照着它的描述建表，结果发现有些字段在后面的SQL脚本里根本不存在，或者字段名对不上，整个文档前后矛盾。
原因：流传的课设文档经常是几届学生拼凑的，ER图可能是早期版本，SQL脚本可能是另一个人的最终版，两者之间没有同步。
解决：不要直接信任文档里的ER图。把下载文档当作需求参考，自己用MySQL Workbench或draw.io重新画ER图，每画一个实体就对照建表脚本核一遍字段名和类型。建完表后，用一条SHOW CREATE TABLE语句核对实际表结构，以数据库里的为准。文档里的图只能用来帮你理解业务，不能用来当验收依据。
5.2 外键ON DELETE CASCADE把历史上机记录删没了
现象：测试时删除一个“测试学生”，结果这个学生的所有上机记录也自动消失了，几分钟前刚验证的统计报表数据全部清空。管理员本来只想清掉一个误录入的学生，结果把历史消费数据全带走了。
原因：上机记录表的外键用了ON DELETE CASCADE，学生删除时级联删除了所有关联的上机记录。这在测试阶段看起来很“省事”，但上机记录是业务事实，删了就无法对账。
解决：业务上机记录表的外键一律用ON DELETE RESTRICT，有历史记录的学生不允许直接删除。如果确实要停用某个学生，设计上应该用status字段置为停用，而不是物理删除。这是一条数据库课程设计里的通用原则：事实表只追加、不物理删除，用逻辑删除代替物理删除。
5.3 时间字段用VARCHAR存，统计报表全部乱掉
现象：上机记录表的start_time字段被设计成VARCHAR(20)，存的是“2025-3-1 10:30”这种手写格式。单条插入没问题，但报表SQL一执行就翻车——“3月10日”排在“3月9日”前面，因为字符串排序先比较“3”，再比较“1”，字典序和日期序根本不是一回事。
原因：当初建表时觉得时间就是字符串，又担心DATETIME格式不好看，结果给统计埋了雷。
解决：时间字段统一使用DATETIME。需要展示格式化时间时，用DATE_FORMAT函数在查询时处理，不要在存储层用字符串。已经踩坑的话，写一个ALTER TABLE脚本转换字段类型，但前提是原字符串能被MySQL正确解析，解析不了的脏数据要先清洗。
5.4 同一台机器被并发预约成功：忘记加锁
现象：两个学生同时点击预约同一台机器，前端都显示“预约成功”，查数据库发现有两条相同时间段的预约记录，机器被重复分配。
原因：预约流程里的查机器状态和插入预约记录是两个独立的SQL，没有放在同一个事务里，更没有加锁。两个请求同时读到机器空闲，然后各自插入一条预约，互相不知道对方的存在。
解决：前台业务代码把“检查重复预约”和“插入预约记录”放进一个事务，插入前用SELECT FOR UPDATE锁住机器行或预约时间段行，让第二个请求等待第一个提交后再判断。更稳妥的办法是第四章节里那张预约表增加UNIQUE KEY(computer_id, resv_date, time_slot)，数据库层面直接拒绝重复预约，即使业务代码漏了，插入时也会报唯一键冲突。
5.5 文档里写的“功能已实现”，代码里只有登录和查询
现象：报告里写着预约管理、计费统计、报表导出都已实现，打开源代码发现只有一个登录页面和一个学生信息维护页面，报表功能根本没有对应代码，答辩演示时点开页面是空的。
原因：课设报告先写完了，功能还没来得及补齐，或者代码是别人写的，自己还没跑通。
解决：把报告里写的每个功能名称逐条对照自测清单，每项至少跑通一个正向场景和一个异常场景。报告里的功能模块图应与验收演示的路径一一对应，宁可少写一个“规划中”的功能，也不要写一个演示时会暴露为空的功能。答辩老师最反感的就是描述和实际演示不一致，这一点直接决定课设成绩上限。
6. 拿“能跑”去换“能讲”：功能自测清单和一条SQL串起全部设计
6.1 答辩前按这张自测清单过一遍
自测不是为了走流程，是为了发现“文档里写过但代码里没实现”的隐藏缺口。我一般建议按下面这张表逐项打勾，每项都要实际点一遍：
| 功能模块 | 操作路径 | 预期结果 | 最容易翻车的地方 |
|---|---|---|---|
| 学生上机 | 输入学号，选择空闲机器 | 生成上机记录，机器状态变为使用中 | 机器状态忘记更新 |
| 学生下机 | 点击下机 | 计算费用、扣余额、机器恢复空闲 | 时长计算边界错误 |
| 余额不足 | 余额低于本次费用 | 拦截下机，提示先充值 | 余额被扣成负数 |
| 预约机器 | 选择机房和时间段 | 只列出可预约机器，重复预约被拒 | 并发重复插入 |
| 日报表 | 查看指定日期报表 | 人数和收入正确 | SUM返回NULL |
| 停用学生 | 管理员停用学生账号 | 该学生无法上机，历史记录保留 | 外键级联删除历史 |
6.2 数据字典配一张截图，比大段原理管用
完整word版课设文档里最实用的部分通常是数据字典。一个合格的数据字典不只是列字段名，还要包含字段类型、是否为空、默认值、备注说明。答辩时老师扫一眼数据字典，就能判断你是真做过还是照抄的。准备好一张核心表的数据字典截图，比如usage_record表，把status的每个取值含义写清楚，这一页的价值比十页原理描述都高。
6.3 用一条统计SQL把ER图、索引和聚合一次讲完
答辩时如果能用一条SQL把整个系统串起来讲，效果会很好。这条SQL就是“统计本周各机房的上机总时长排名”：
SELECT r.room_name, SUM(ur.duration_min) AS total_minutes FROM usage_record ur JOIN computer c ON ur.computer_id = c.computer_id JOIN room r ON c.room_id = r.room_id WHERE ur.status = 3 AND ur.start_time >= DATE_SUB(CURDATE(), INTERVAL WEEKDAY(CURDATE()) DAY) GROUP BY r.room_name ORDER BY total_minutes DESC;讲解思路可以这样组织：JOIN把usage_record、computer、room三张表按外键关系串起来，覆盖了ER图里最核心的联系；WHERE条件用DATE_SUB计算本周起始时间，体现对日期函数的理解；GROUP BY和SUM体现聚合能力；ORDER BY DESC解决排序场景。老师从这条SQL出发问索引，就回答usage_record表上已经建了idx_stu_time和idx_computer_status两个联合索引，分别支撑按学生查记录和按机器查状态的请求。
我早年带课设时最怕听到的一句话是“你这个表和表之间有关系吗”。后来养成一个习惯，每次做完系统，先把所有JOIN语句列出来，对着ER图检查一遍，凡是JOIN里用到的关联字段，确认都建了索引。说实话，机房管理系统这个选题不复杂，复杂的是把每张表为什么存在、每个字段为什么这么设、每条SQL为什么这么写讲清楚。做课设的目的不是交一份文档，而是让你在数据库这门课上真的有东西能拿出来讲。希望帮到你。
本文还有配套的精品资源，点击获取
