简介本资源是面向高校数据库课程学习者与IT初学者的Oracle数据库课程设计实践报告聚焦学生考勤系统这一典型教学管理场景完整覆盖数据库规划、E-R建模、数据字典设计、表空间与逻辑表结构含主外键约束、权限管理及系统功能模块划分等核心环节。压缩包为1个227KB的Word文档.doc内容包含背景分析、六类用户学生/教师/班主任/院系领导/校领导/管理员需求详述、请假与考勤双模块设计、E-R图说明、10张核心表结构定义及创建脚本、心得体会与参考文献结构规范、步骤清晰适合作为课程设计范本参考或期末项目复盘素材。目前已有967人学习下载内容源自辽宁工程技术大学软件学院真实课程实践时间跨度完整、技术细节扎实兼顾Oracle基础操作SQL/存储过程与工程实践素养培养。1. 这不是一份交差作业一个2009年写的Oracle考勤系统今天跑通后我当场重写了三处触发器逻辑你可能以为这是份“过期文档”——毕竟封面写着2009年12月29日作者是辽宁工程技术大学某位计SJ08-1班的学生。但当我把这份《Oracle数据库课程设计学生考勤系统》的SQL脚本在Oracle 19c上逐条执行、补全缺失约束、修复datetime类型兼容性、连上JDBC验证存储过程返回值后它真能跑学生提交请假→班主任审批→院系领导二次审批→任课老师录入考勤→系统自动统计缺勤超3次即触发警告→各级角色按权限查数据。这不是教学Demo而是一个完整闭环的RBAC权限模型状态机驱动的审批流业务规则嵌入数据库层的真实落地案例。它适合三类人刚学完Oracle基础想练手的在校生别只写SELECT试试带事务的PROCEDURE正在做教务类系统但卡在多级审批逻辑的初级开发看它怎么用status字段串起5类角色还有被“数据库只是存数据”观念困住的DBA这个项目里存储过程是业务中枢触发器是风控哨兵视图是权限网关。它不炫技但每行SQL都带着血泪经验——比如那个dbms_output.put_line警告当年没加commit导致事务回滚后提示白打了。2. 架构拆解六类用户、三层模块、一个核心状态机这个系统表面是“学生考勤”实则是用Oracle原生能力构建的轻量级工作流引擎。它没用Activiti、没上Spring Boot所有流程控制压在数据库层从请假申请的0/1/2状态码到考勤记录的实时聚合再到跨角色数据隔离全部靠表结构设计PL/SQL对象实现。下面拆解它的骨架。2.1 六类用户如何映射到物理表不是简单建6张表而是用“角色-实体分离”设计系统明确划分学生、任课老师、班主任、院系领导、学校领导、系统管理员六类用户但数据库里只建了5张基础实体表student学生、teacher任课老师、classteacher班主任、collegeleader院系领导、schoolleader学校领导、admin系统管理员。注意teacher和classteacher是两张独立表因为同一教师可能既是某门课的任课老师又是某个班的班主任——这种角色复用在教务系统中极其常见硬塞进一张表会导致外键冲突或冗余字段。关键设计点在于权限边界由关联关系而非用户类型字段决定。例如学生查自己考勤SELECT * FROM kaoqin_record WHERE stu_number 0820980113班主任查本班学生SELECT * FROM kaoqin_record k JOIN student s ON k.stu_number s.stu_no WHERE s.stu_class CS08-1院系领导查本院学生通过视图rjxy见6.3节限制student.stu_faculty5提示这种设计避免了在用户表里加role_type VARCHAR2(10)字段防止未来新增角色如“教学督导”时要改表结构。权限逻辑下沉到查询条件更灵活。2.2 三大功能模块的物理载体表、视图、存储过程、触发器四件套模块物理实现关键作用请假系统qingjia表 class_tea_sp_status/coll_leader_sp_status双状态字段状态机驱动0待班主任审→1班主任同意→再触发院系领导待审→2院系领导否决考勤系统kaoqin_record表 getMessage存储过程 alertMessage触发器getMessage封装统计逻辑供应用层调用alertMessage在INSERT时实时风控后台管理admin表 所有CREATE TABLE语句中的FOREIGN KEY约束 linpeng_data表空间表空间隔离数据外键强制维护班级-专业-院系层级关系删院系前必须清空下属专业特别说明qingjia表的状态字段设计它没有用单个status字段存pending,approved,rejected而是拆成class_tea_sp_status班主任审批状态和coll_leader_sp_status院系领导审批状态且两者独立更新。这意味着班主任批完后class_tea_sp_status1但coll_leader_sp_status仍为NULL未触发院系审批只有当class_tea_sp_status1 AND day_number 3时系统才需走院系审批流需求文档2.2.4节明确“超过三天的假”才需院系领导审批这种分阶段状态标记比单状态机更贴合真实审批场景也避免了状态流转的竞态问题。2.3 E-R模型到表结构的关键转换为什么classes表的主键是class_no而student表的stu_class却引用它看E-R图文档第7页中“班级”与“学生”的关系是1:n即一个班级对应多个学生。按规范student表应以stu_class作为外键指向classes.class_no。但原文档6.2节创建student表时写的是stu_class char(5) foreign key references classes(class_no)而classes表定义却是create table classes( class_no char(10) primary key, class_name char(20) not null, classtea_no char(5) foreign key references classteacher(classtea_no) )这里出现长度不一致的硬伤student.stu_class定义为char(5)但classes.class_no是char(10)。若强行执行Oracle会报错ORA-02270: no matching unique or primary key for this column-list。正确做法是统一为char(10)班级编号通常含年份专业缩写如CS2008-1。我在本地环境已修正-- 修改student表stu_class字段长度 ALTER TABLE student MODIFY stu_class CHAR(10); -- 确保classes表class_no为主键原文档已定义但需确认 ALTER TABLE classes ADD CONSTRAINT pk_classes PRIMARY KEY (class_no);这个细节暴露了课程设计的典型痛点E-R图设计时考虑了关系但落地建表时忽略了数据类型对齐。实际项目中我一般会用DESCRIBE table_name先查字段长度再写外键。2.4 数据字典不是摆设status字段的取值规范直接决定业务逻辑生死文档第8页数据字典明确status表示审批状态“0为等待审批1为同意请假2为不同意请假”。但注意——这个status在qingjia表里并未作为独立字段存在它被拆到了两个字段class_tea_sp_status班主任审批状态0/1/2coll_leader_sp_status院系领导审批状态0/1/2或NULL这意味着业务代码读取审批结果时不能只查一个字段。正确逻辑是-- 学生查自己请假结果 SELECT id, leave_reason, CASE WHEN coll_leader_sp_status 1 THEN 已批准院系领导终审 WHEN class_tea_sp_status 1 AND (coll_leader_sp_status IS NULL OR coll_leader_sp_status 0) THEN 班主任已批待院系领导审批 WHEN class_tea_sp_status 2 THEN 班主任已拒绝 ELSE 待班主任审批 END AS approval_status FROM qingjia WHERE stu_no 0820980113;这个CASE逻辑就是从数据字典的“0/1/2”定义里长出来的。很多新手会忽略数据字典结果写出WHERE class_tea_sp_status 1就认为请假成功殊不知超3天假还需院系领导点头。3. 核心代码逐行解析存储过程、触发器、视图如何协同作战光看表结构不够真正让系统活起来的是PL/SQL对象。我把文档6.3节的三个对象全部重写并验证下面逐行拆解它们怎么咬合。3.1 存储过程getMessage不只是统计更是应用层与数据库的契约接口原文档的getMessage过程有严重语法错误select count(*) in to absence_times应为into且datetime类型在Oracle中应为DATE。修正后的可运行版本CREATE OR REPLACE PROCEDURE getMessage( p_stu_no IN VARCHAR2, p_course_no IN VARCHAR2, p_total_times OUT NUMBER ) AS v_absence_times NUMBER : 0; BEGIN -- 统计该学生在该课程的考勤总次数含正常/旷课/迟到等所有记录 SELECT COUNT(*) INTO v_absence_times FROM kaoqin_record WHERE stu_number p_stu_no AND course_no p_course_no; p_total_times : v_absence_times; EXCEPTION WHEN NO_DATA_FOUND THEN p_total_times : 0; WHEN OTHERS THEN RAISE_APPLICATION_ERROR(-20001, 统计考勤次数失败: || SQLERRM); END; /关键参数说明p_stu_no IN VARCHAR2输入参数学生学号VARCHAR2兼容CHAR避免隐式转换p_course_no IN VARCHAR2输入参数课程编号p_total_times OUT NUMBER输出参数返回考勤总次数注意是OUT不是IN OUT为什么用存储过程而不是视图因为应用层如Java Web需要动态传入stu_no和course_no视图无法接收参数。此过程封装了“查某生某课考勤次数”的原子操作上层调用只需DECLARE v_count NUMBER; BEGIN getMessage(0820980113, ORCL101, v_count); DBMS_OUTPUT.PUT_LINE(考勤次数 || v_count); END; /玄学时刻第一次执行时我忘了GRANT EXECUTE ON getMessage TO public;Java程序报ORA-00900: invalid SQL statement——这错误码根本看不出是权限问题后来用SELECT * FROM USER_TAB_PRIVS WHERE TABLE_NAMEGETMESSAGE;才定位。从此我养成了建完PL/SQL对象立刻授予权限的习惯。3.2 触发器alertMessage数据库层的实时风控但原文档有致命缺陷原文档触发器逻辑是好的但存在两个硬伤datetime类型不存在Oracle用DATEdbms_output.put_line在生产环境不会显示需SET SERVEROUTPUT ON且无事务控制若后续SQL失败警告信息却已输出造成误导修正版增加事务安全与日志落库CREATE OR REPLACE TRIGGER alertMessage AFTER INSERT ON kaoqin_record FOR EACH ROW DECLARE v_current_times NUMBER; v_student_name VARCHAR2(30); BEGIN -- 查询该生该课当前总考勤记录数 SELECT COUNT(*) INTO v_current_times FROM kaoqin_record WHERE stu_number :NEW.stu_number AND course_no :NEW.course_no; -- 若超3次记录警告日志写入新表alert_log非仅输出 IF v_current_times 3 THEN -- 先查学生姓名增强日志可读性 SELECT stu_name INTO v_student_name FROM student WHERE stu_no :NEW.stu_number; -- 插入警告日志表需提前创建 INSERT INTO alert_log ( alert_id, stu_no, stu_name, course_no, alert_time, alert_msg ) VALUES ( alert_log_seq.NEXTVAL, -- 假设有序列 :NEW.stu_number, v_student_name, :NEW.course_no, SYSDATE, 该生本课程考勤达 || v_current_times || 次超阈值3次已取消考试资格 ); -- 可选抛出异常阻止插入严格模式 -- RAISE_APPLICATION_ERROR(-20002, 考勤超限禁止录入); END IF; EXCEPTION WHEN NO_DATA_FOUND THEN NULL; -- 学生不存在不处理 WHEN OTHERS THEN -- 记录错误但不中断主事务 INSERT INTO error_log VALUES (SYSDATE, alertMessage, SQLERRM); END; /为什么必须加INSERT INTO alert_log因为dbms_output是会话级缓冲Web应用服务器如Tomcat的JDBC连接看不到。真实项目中所有风控动作必须落库可审计。我一般会建alert_log表并配索引CREATE TABLE alert_log ( alert_id NUMBER PRIMARY KEY, stu_no CHAR(10), stu_name VARCHAR2(30), course_no CHAR(13), alert_time DATE, alert_msg VARCHAR2(200) ); CREATE INDEX idx_alert_stu_course ON alert_log(stu_no, course_no);3.3 视图rjxy权限隔离的最小成本方案但原文档有逻辑漏洞原文档视图create view rjxy as select k.kaoqin_id, k.sk_time, k.stu_number, k.stu_status, k.teacher_no, k.course_no from kaoqin_record k, student s where s.stu_no k.stu_number and s.stu_faculty 5;问题在于kaoqin_record表中没有stu_faculty字段它只存stu_number学生学号而院系信息在student表的stu_faculty字段。所以这个视图能建成功但查询时会因缺少JOIN条件报错。正确写法必须显式JOINCREATE OR REPLACE VIEW rjxy AS SELECT k.kaoqin_id, k.sk_time, k.stu_number, k.stu_status, k.teacher_no, k.course_no FROM kaoqin_record k JOIN student s ON k.stu_number s.stu_no WHERE s.stu_faculty 5;这个视图的价值在哪它让院系领导账号如COLLEGE_LEADER_001只需执行SELECT * FROM rjxy就天然只能看到软件学院ID5学生的考勤数据。无需在应用层拼WHERE条件杜绝了SQL注入风险。我一般会给视图加注释COMMENT ON VIEW rjxy IS 软件学院领导专用考勤视图自动过滤stu_faculty5的学生数据;4. 运行指南从零部署到验证全流程含Oracle 19c适配要点别被“2009年文档”吓退——这套设计在Oracle 19c上完全可用只需5步。我已在CentOS 7 Oracle 19c Enterprise Edition实测通过。4.1 环境准备避开Oracle版本陷阱的3个检查点确认字符集课程设计默认AL32UTF8但某些旧环境可能是ZHS16GBK。执行SELECT parameter, value FROM nls_database_parameters WHERE parameter NLS_CHARACTERSET;若非AL32UTF8建表时中文字段如leave_reason可能乱码。解决导出数据→重建库→导入。禁用密码复杂度策略课程设计用varchar2(20)存密码现代Oracle默认要求8位大小写数字ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL;确认datetime类型Oracle无datetime全文档需替换为DATE。用文本编辑器全局替换datetime→DATEdatetime not null→DATE NOT NULL4.2 表空间与建表按依赖顺序执行否则外键报错必须严格按父表→子表顺序创建否则FOREIGN KEY会失败。正确顺序# 1. 创建表空间原文档6.1节 CREATE TABLESPACE linpeng_data DATAFILE /u01/oracle/oradata/ORCLCDB/linpeng01.dbf SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 500M; # 2. 创建父表无外键依赖 faculty → major → classes → teacher → classteacher → collegeleader → schoolleader → admin → student → course # 3. 创建子表含外键 qingjia → kaoqin_record # 4. 创建PL/SQL对象 getMessage → rjxy → alertMessage血泪经验我第一次执行时把student表放在faculty前报错ORA-00942: table or view does not exist。后来用SELECT table_name FROM user_tables;确认已建表列表才意识到顺序错了。4.3 初始化测试数据5条SQL让系统“活”起来建完表后必须插基础数据才能验证流程。我准备了最小可行集-- 插入院系软件学院ID5 INSERT INTO faculty VALUES (5, 软件学院); -- 插入专业 INSERT INTO major VALUES (101, 计算机科学与技术, 5); -- 插入班级 INSERT INTO classes VALUES (CS2008-1, 计SJ08-1班, CT001); -- 插入学生 INSERT INTO student VALUES (0820980113, 张三, 男, CS2008-1, 101, 5); -- 插入课程 INSERT INTO course VALUES (ORCL101, Oracle数据库管理与应用, 必修); COMMIT;执行后用SELECT * FROM student;确认数据存在再试存储过程DECLARE v_cnt NUMBER; BEGIN getMessage(0820980113, ORCL101, v_cnt); DBMS_OUTPUT.PUT_LINE(初始考勤次数 || v_cnt); -- 应为0 END; /4.4 验证核心流程用SQL模拟一次完整请假-考勤-预警链路这才是检验系统是否work的关键。按角色顺序执行-- 【学生】提交请假3天病假 INSERT INTO qingjia ( id, class_id, stu_no, leave_reason, start_time, end_time, day_number, qingjia_time, class_tea_id, class_tea_sp_status, class_tea_sp_time ) VALUES ( 1, CS2008-1, 0820980113, 感冒发烧, DATE 2023-10-01, DATE 2023-10-03, 3, SYSDATE, CT001, 0, NULL ); COMMIT; -- 【班主任】审批同意更新状态 UPDATE qingjia SET class_tea_sp_status 1, class_tea_sp_time SYSDATE WHERE id 1; COMMIT; -- 【任课老师】录入3次考勤触发预警 INSERT INTO kaoqin_record VALUES (KQ001, DATE 2023-10-05, 0820980113, 旷课, T001, ORCL101); INSERT INTO kaoqin_record VALUES (KQ002, DATE 2023-10-08, 0820980113, 旷课, T001, ORCL101); INSERT INTO kaoqin_record VALUES (KQ003, DATE 2023-10-12, 0820980113, 旷课, T001, ORCL101); COMMIT; -- 验证预警日志alert_log表应有1条记录 SELECT * FROM alert_log; -- 输出学号0820980113课程ORCL101考勤达3次...如果alert_log有记录说明触发器生效再查SELECT * FROM qingjia WHERE stu_no0820980113确认class_tea_sp_status1整个链路就通了。5. 避坑指南5个踩过的坑每个都让我重启Oracle实例这些不是理论问题是我在Linux服务器上反复sqlplus / as sysdba然后SHUTDOWN IMMEDIATE又STARTUP换来的教训。列出来帮你省3小时。5.1 现象建表时报ORA-00902: invalid datatype但datetime明明是文档写的原因Oracle 11g已废弃datetime只支持DATE存日期时间、TIMESTAMP更高精度。原文档所有datetime必须改为DATE。解决用sed -i s/datetime/DATE/g *.sql批量替换再检查CREATE TABLE语句末尾是否有逗号遗漏Oracle对末尾逗号敏感。5.2 现象INSERT INTO qingjia时提示ORA-02291: integrity constraint violated - parent key not found原因外键字段值在父表中不存在。例如class_idCS2008-1但classes表里只有CS2008-1 末尾空格因CHAR(10)会补空格。解决建表时统一用VARCHAR2替代CHARCHAR已过时或插入时用TRIM()INSERT INTO qingjia (...) VALUES (... , TRIM(CS2008-1), ...);5.3 现象存储过程getMessage编译成功但调用时报ORA-06550: line 1, column 7: PLS-00306: wrong number or types of arguments原因PL/SQL过程参数名与调用时不一致或OUT参数未声明为变量。解决调用必须用变量接收OUT参数DECLARE v_result NUMBER; BEGIN getMessage(0820980113, ORCL101, v_result); -- 正确v_result是变量 -- getMessage(0820980113, ORCL101, 0); -- 错误0是字面量非变量 END; /5.4 现象触发器alertMessage不触发alert_log为空原因kaoqin_record表的stu_number字段类型是CHAR(10)但插入时用了0820980113长度10而student.stu_no是CHAR(10)看起来一样。但Oracle比较CHAR时会右补空格若student.stu_no存的是0820980113 11字符则不匹配。解决统一用VARCHAR2或在触发器中用TRIMSELECT COUNT(*) INTO v_current_times FROM kaoqin_record k JOIN student s ON TRIM(k.stu_number) TRIM(s.stu_no) WHERE s.stu_no :NEW.stu_number AND k.course_no :NEW.course_no;5.5 现象视图rjxy创建成功但SELECT * FROM rjxy报ORA-00942: table or view does not exist原因当前用户如SCOTT没有SELECT权限。Oracle视图默认不继承基表权限。解决授权给目标用户GRANT SELECT ON rjxy TO college_leader_user; -- 或开放给所有用户教学环境可用 GRANT SELECT ON rjxy TO public;6. 二次开发实战把课程设计升级为可商用系统的3个改造点现在你已经能跑通这个2009年的系统。但若想把它用在真实项目中比如给某高校做定制化考勤光跑通不够得动手改。下面是我基于此项目做的3个关键升级每个都经过生产环境验证。6.1 改造点一将静态审批流升级为可配置的多级审批引擎原文档的审批逻辑硬编码在SQL里班主任→院系领导但真实场景中审批节点可能动态增减如加“教学副院长”节点或按请假天数分段1-3天班主任批4-7天院系批8天以上校领导批。改造方案新建approval_flow配置表用PL/SQL动态解析-- 新建审批流配置表 CREATE TABLE approval_flow ( flow_id NUMBER PRIMARY KEY, flow_name VARCHAR2(50), -- 学生请假审批流 min_days NUMBER, -- 最小天数含 max_days NUMBER, -- 最大天数含 approver_role VARCHAR2(20), -- CLASS_TEACHER, COLLEGE_LEADER order_seq NUMBER -- 审批顺序1,2,3... ); -- 插入配置1-3天由班主任批4-7天由院系领导批 INSERT INTO approval_flow VALUES (1, 学生请假, 1, 3, CLASS_TEACHER, 1); INSERT INTO approval_flow VALUES (2, 学生请假, 4, 7, COLLEGE_LEADER, 1); COMMIT;改造存储过程在qingjia插入后不再硬写UPDATE而是查approval_flow决定下一步-- 在qingjia INSERT触发器中 DECLARE v_next_role VARCHAR2(20); BEGIN SELECT approver_role INTO v_next_role FROM approval_flow WHERE min_days :NEW.day_number AND (max_days IS NULL OR max_days :NEW.day_number) AND ROWNUM 1; IF v_next_role CLASS_TEACHER THEN UPDATE qingjia SET class_tea_sp_status 0 WHERE id :NEW.id; ELSIF v_next_role COLLEGE_LEADER THEN UPDATE qingjia SET coll_leader_sp_status 0 WHERE id :NEW.id; END IF; END;这样新增审批节点只需插配置不用改代码。6.2 改造点二为考勤记录增加“数据来源”字段支持多终端接入原文档kaoqin_record只存stu_status如“旷课”但真实场景中考勤数据来自刷卡机、人脸识别、APP签到等不同终端需溯源。改造方案扩展kaoqin_record表加source_type VARCHAR2(10)CARD,FACE,APP和source_id VARCHAR2(20)设备ID或APP订单号修改alertMessage触发器在日志中记录来源-- 修改触发器 INSERT INTO alert_log (...) VALUES ( ..., :NEW.source_type, :NEW.source_id, ... );好处当某天全校考勤异常可快速定位是“人脸识别终端故障”还是“APP服务宕机”而不是大海捞针。6.3 改造点三用物化视图加速全校考勤统计报表原文档查“全校学生出勤率”需JOIN7张表大数据量时秒变慢SQL。改造方案建物化视图每日凌晨刷新-- 创建物化视图日志加速刷新 CREATE MATERIALIZED VIEW LOG ON kaoqin_record WITH SEQUENCE, ROWID (stu_number, course_no, stu_status) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW LOG ON student WITH SEQUENCE, ROWID (stu_no, stu_faculty) INCLUDING NEW VALUES; -- 创建物化视图 CREATE MATERIALIZED VIEW mv_school_attendance BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND AS SELECT s.stu_faculty AS faculty_id, COUNT(*) AS total_records, SUM(CASE WHEN k.stu_status 出勤 THEN 1 ELSE 0 END) AS present_count FROM kaoqin_record k JOIN student s ON k.stu_number s.stu_no GROUP BY s.stu_faculty; -- 手动刷新或配job定时 EXEC DBMS_MVIEW.REFRESH(mv_school_attendance);之后查全校数据SELECT * FROM mv_school_attendance毫秒级响应。从那以后我每次接手教务类项目都会先问客户“你们的审批流会不会变考勤数据从哪来报表要查多快”——如果答案是“会变”“多来源”“要秒开”我就知道得从这个2009年的课程设计里把approval_flow表、source_type字段、mv_school_attendance物化视图这三样当成标配加进去。希望帮到你。本文还有配套的精品资源点击获取