简介：这份Oracle数据库课程设计资料面向学习数据库管理与开发的学生及IT从业者，以“学生考勤系统”为完整案例，帮助读者掌握从需求分析到数据库落地的全流程设计方法。内容涵盖系统背景分析、多角色用户需求（学生、任课老师、班主任、院系领导、学校领导、系统管理员）、请假与考勤及后台管理三大功能模块划分，并给出E-R模型、数据字典、数据库表逻辑结构设计以及表空间与建表脚本等关键环节，还附有心得体会与参考文献。资源包为1个doc文档，约227KB，结构完整、目录清晰，可直接作为课程设计报告参考或数据库设计练习范本。目前已有965人学习，适合需要完成Oracle课程设计、巩固SQL查询、存储过程、触发器及权限与备份策略的读者借鉴使用。
1. 从一次“点名翻车”说起：这套 Oracle 学生考勤系统到底解决什么问题
高校里最容易被低估的管理动作，大概就是上课点名。任课老师拿着花名册挨个勾，一学期下来纸质记录堆成山，真到期末想统计某个学生缺了几次课，只能靠人工翻。更麻烦的是请假：学生找班主任签字，班主任批完还要看是否超过三天，超过三天得再跑院系领导，一圈下来假条可能还在路上，课已经上完了。这套 Oracle 数据库课程设计要做的，就是把“请假—审批—考勤—统计”这条链路收进一个数据库系统里，让六类用户各看各的数据、各干各的事。
它适合两类人：一类是正在做数据库课程设计、需要一份从需求分析到建表建对象完整走通的参考方案的学生；另一类是想拿一个真实业务场景练 Oracle 表空间、约束、视图、存储过程和触发器的开发者。整套方案的核心不是界面多漂亮，而是数据库端把业务规则扛住——请假审批状态怎么流转、考勤记录怎么和请假结果自动对齐、不同层级的领导怎么只能看到自己权限范围内的数据，这些都在库端解决。
2. 需求分析与角色划分：六类用户、三大模块的职责边界
2.1 六类用户各自要什么
这套系统最容易被做浅的地方，就是把“用户”当成一个登录账号了事。实际上六类用户的诉求差别很大，需求分析阶段必须逐类拆开，否则后面表结构和权限设计一定返工。
学生要的是两件事：在线请假并随时看到审批走到哪一步了，以及查自己整个在校期间每门课的出勤明细，比如“Oracle 数据库管理与应用”这门课这学期请假几次、旷课几次。任课老师要的是管理所教班级的出勤，系统能自动列出还没公布考勤的课程，并根据请假系统的审批结果决定学生最终出勤状态。班主任要审批本班本学期请假，并查看本班所有课程的出勤统计。院系领导审批本院系超过三天的请假，查看本院系出勤。学校领导只看全校出勤统计。系统管理员权限最高，负责院系、年级、专业、班级、课表、用户、请假和考勤数据的动态维护。
这里有个设计上的关键判断：请假审批是两级还是三级，直接决定请假表里要留几组审批字段。本方案采用两级——班主任先审，超过三天再流转到院系领导，所以请假表里班主任审批状态、院系领导审批状态各留一组，这个在后面建表时会体现。
2.2 三大功能模块怎么切
按功能把系统切成请假系统、考勤系统、后台管理三块。请假模块只涉及学生、班主任、院系领导三类用户；考勤模块涉及全部六类用户，因为学生要看自己的、老师要管自己教的、各级领导要看不同范围的；后台管理只归系统管理员。
三块之间不是并列关系，而是有依赖的：考勤结果要借助请假系统的审批结论才能定稿——一个学生某节课没刷卡，但如果他当天有已批准的假条，那这条记录应该是“请假”而不是“旷课”。而请假和考勤又都依赖后台维护的课表、班级、班主任安排，因为每学年课表和班主任都会变。这个依赖链是后面设计存储过程和触发器时的重要依据。
2.3 功能需求落到具体规则
功能需求不能只写“能请假、能考勤”，要落到可验证的规则上。请假最长不超过一个月，特殊情况除外；审批状态用 0/1/2 表示等待审批、同意、不同意；考勤状态要能区分正常、迟到、旷课、请假。这些规则写进需求文档，后面建表时的 CHECK 约束和存储过程里的判断逻辑才有出处。
3. E-R 模型与数据字典：把业务关系翻译成实体和字段
3.1 E-R 模型里的实体与联系
E-R 模型是整套设计的骨架。本系统识别出的实体包括：学院、专业、班级、学生、教师、班主任、院系领导、学校领导、课程、请假条、考勤记录。联系上，学生属于班级、班级属于专业、专业属于学院，这是一条归属链；教师授课、班级开设课程，这是教学链；学生请假产生请假条，请假条被班主任和院系领导审批；学生上课产生考勤记录，考勤记录关联课程和教师。
画 E-R 图时最容易漏的是“班主任”和“教师”的关系。班主任本身也是教师，但在系统里承担审批职责，所以本方案把班主任单独建表，而不是在教师表上加个标志位。这样做的好处是班主任的所属专业、所属学院字段可以独立维护，审批权限的判定也更直接。
3.2 数据字典怎么写才不流于形式
数据字典不是把表名抄一遍，而是把每个实体的属性定义清楚。比如请假条信息定义为：请假代号 + 班级代号 + 学生学号 + 请假原因 + 开始时间 + 结束时间 + 请假天数 + 申请请假时间 + 班主任审批状态 + 班主任审批时间 + 院系领导审批状态 + 院系领导代号 + 院系领导审批时间。这一串定义直接对应后面请假表的字段，写字典的时候其实就是在预演建表。
提示：数据字典里的“定义”一行，建议用“实体 = 属性1 + 属性2 + …”的格式写，评审时一眼能看出字段有没有遗漏，比纯文字描述高效得多。
3.3 从 E-R 到逻辑结构的转换要点
转换时，一对多联系把“一”方的主键放到“多”方做外键，比如学生表里放班级编号、专业编号、学院编号。多对多联系要单独建表，本系统里教师和课程的授课关系、学生和课程的考勤关系都属于这类，考勤记录表实际上就承担了学生—课程—教师三者交叉记录的职责。转换完成后要检查每个外键指向的主键类型是否一致，这是后面建表报错的高发区。
4. 表空间与表结构落地：从建表语句到约束设计
4.1 先建表空间再建表
Oracle 里表是逻辑对象，最终要落到表空间上。本方案创建一个字典管理类表空间，方便用数据字典跟踪磁盘使用。建表空间语句如下：
-- 创建字典管理类表空间，指定数据文件路径与初始大小 create tablespace linpeng_data datafile '/u01/oracle/oradata/tab01.dbf' size 100M default storage( initial 512K -- 初始区大小 next 128K -- 下次分配区大小 minextents 2 -- 最小区数 maxextents 999 -- 最大区数 pctincrease 0 -- 区增长率为0，避免碎片 ) online;参数说明：initial和next控制区的分配节奏，课程设计数据量不大，512K 初始、128K 递增足够；pctincrease 0是为了让区大小保持稳定，减少表空间碎片。数据文件路径按实际环境改，不要照抄。
4.2 核心表建表语句与约束
以系统管理员表、学生表和请假表为例，看约束是怎么落地的：
-- 系统管理员表：主键 + 性别 CHECK 约束 create table admin( admin_no char(5) not null, admin_name char(10) not null, admin_sex char(2) check (admin_sex='男' or admin_sex='女'), admin_title char(20) not null, admin_password varchar2(20) not null, constraint pk_admin primary key (admin_no) ) tablespace linpeng_data; -- 学生表：三个外键分别指向班级、专业、学院 create table student( stu_no char(10) not null, stu_name varchar2(30) not null, stu_sex char(2) check (stu_sex='男' or stu_sex='女'), stu_class char(10) references classes(class_no), stu_major number references major(major_id), stu_faculty number references faculty(faculty_id), constraint pk_student primary key(stu_no) ) tablespace linpeng_data; -- 请假表：两级审批状态 + 审批时间 + 审批人 create table qingjia( id number primary key, class_id char(10) references classes(class_no), stu_no char(10) references student(stu_no), leave_reason varchar2(200) not null, start_time date not null, end_time date not null, day_number number not null, qingjia_time date not null, class_tea_id char(5) references classteacher(classtea_no), class_tea_sp_status char(10), class_tea_sp_time date, coll_leader_sp_status char(10), coll_leader_id char(5) references collegeleader(collegeleader_no), coll_leader_sp_time date ) tablespace linpeng_data;设计说明：性别字段用 CHECK 约束而不是枚举类型，是为了兼容性和可读性；学生表的三个外键让归属关系在库端强制成立，插入脏数据直接报错；请假表把两级审批拆成两组字段，class_tea_sp_status和coll_leader_sp_status用 0/1/2 表示等待、同意、不同意，这样审批流转的每一步都有时间戳可查。
注意：原文建表语句里
datetime在 Oracle 中应写为date，varchar建议统一为varchar2，外键的foreign key references写法在列级约束里直接写references更简洁。这些是课程设计里常见的语法坑，建表前先统一。
4.3 其余表的字段规划
课程表、班级表、教师表、班主任表、院系领导表、学校领导表、考勤记录表按同样思路建。考勤记录表是数据量最大的一张，字段包括考勤编号、上课时间、学生学号、考勤状态、教师编号、课程编号，其中学生、教师、课程三个外键保证每条考勤都能追溯到人、课、师。班级表里放班主任编号做外键，这样班主任和班级的绑定关系在库端固定，后台换班主任时改这一处即可。
5. 视图、存储过程与触发器：把业务规则封装到数据库端
5.1 用视图做院系级数据隔离
不同院系领导只能看本院系学生的考勤，这个需求用视图实现最干净。假设软件学院编号为 5：
-- 软件学院考勤视图：只暴露本院系学生的考勤记录 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;逻辑说明：视图把考勤记录和学生表关联，用stu_faculty = 5过滤出院系范围。院系领导查询时只查这个视图，就看不到其他院系的数据。如果院系多了，可以按院系编号批量生成视图，或者用带参数的存储过程替代，课程设计阶段用视图足够说明权限隔离的思路。
5.2 存储过程统计某学生某课程出勤
学生要查自己某门课的出勤情况，用存储过程封装统计逻辑：
-- 统计指定学生指定课程的缺勤次数 create or replace procedure getMessage( stu_no in varchar2, course_no in varchar2, total_times out number ) as absence_times number; begin select count(*) into absence_times from kaoqin_record where stu_number = stu_no and course_no = course_no; total_times := absence_times; end;参数说明：stu_no和course_no是入参，total_times是出参，调用方拿到结果后展示。把统计放在库端的好处是数据不用全拉到应用层再算，数据量大时优势明显。调用方式是在应用层用call getMessage(...)或匿名块里绑定变量接收出参。
5.3 触发器做缺勤预警
当某学生某课程缺勤次数达到阈值时给出提示，用触发器实现：
-- 插入考勤记录后检查该生该课缺勤次数，达到3次给出预警 create or replace trigger alertMessage after insert on kaoqin_record for each row declare current_times number; begin select count(*) into current_times from kaoqin_record where stu_number = :new.stu_number and course_no = :new.course_no; if current_times >= 3 then dbms_output.put_line( '学号为：' || :new.stu_number || '的学生该门课程被取消考试资格！' ); end if; end;逻辑说明：after insert表示插入考勤记录后触发，for each row是行级触发器，:new取到刚插入的那条记录。统计该生该课的累计记录数，达到 3 次就输出预警。实际项目里预警不会只靠dbms_output，通常会写进一张预警表或发消息，课程设计阶段用输出语句演示触发逻辑即可。
提示：触发器里查同一张表要小心变异表问题。这里是在
after insert里对同一张表做count，Oracle 允许行级触发器读同一张表，但如果逻辑更复杂，建议改成语句级触发器或把统计放到存储过程里由应用层调用。
6. 避坑与排查：课程设计里最容易翻车的五个点
6.1 建表顺序错导致外键报错
现象：建学生表时报“违反唯一性约束”或“表或视图不存在”。原因：学生表引用了班级表、专业表、学院表，但这几张表还没建。解决：按依赖顺序建表，先建无外键的学院、专业、课程、教师、班主任、院系领导、学校领导表，再建班级、学生表，最后建考勤记录和请假表。建表脚本里把顺序排好，别随手写。
6.2 数据类型不匹配导致外键建不上
现象：外键约束创建失败，提示类型不一致。原因：主表主键是number，子表外键写成了char，或者长度不一致。解决：建表前把数据字典里的字段类型和长度对齐，主键和外键的类型、长度必须完全一致。原文里学生表的stu_class是char(13)，班级表的class_no是char(10)，这种长度不一致就会出问题，统一成char(10)。
6.3 触发器逻辑写错导致插入失败
现象：往考勤表插数据时触发器报错，整条插入回滚。原因：触发器里select into没查到数据会抛no_data_found，或者统计逻辑写错。解决：触发器里的select into要么保证有数据，要么加异常处理。统计缺勤次数时确认where条件用的是:new的字段，别写成固定值。
6.4 表空间路径不存在导致建表空间失败
现象：执行create tablespace报“无法创建数据文件”。原因：datafile指定的路径在服务器上不存在，或者 Oracle 进程没有写权限。解决：先确认路径存在，用ls -l看权限，必要时让 DBA 建好目录再执行。课程设计环境里路径按实际改，别照抄示例。
6.5 审批状态流转没做校验
现象：学生请假被班主任拒绝后，院系领导那边还能继续审批。原因：请假表里两级审批状态独立更新，没有在逻辑上做先后约束。解决：在存储过程或应用层加判断——只有班主任审批状态为“同意”且请假天数超过三天时，才允许院系领导审批。这个规则写进存储过程，别只靠界面控制。
7. 验收与答辩：怎么证明这套库设计是站得住的
验收这套课程设计，核心不是看界面，而是看数据库端能不能扛住业务规则。我一般会按下面这张表逐项过：
| 验收项 | 验收方法 | 合格标准 |
|---|---|---|
| 表空间与表 | 查user_tablespaces和user_tables | 所有表建在指定表空间，无遗漏 |
| 主外键约束 | 查user_constraints | 主键、外键、CHECK 约束齐全 |
| 视图隔离 | 用不同院系身份查视图 | 只能看到本院系数据 |
| 存储过程 | 传入学生和课程编号调用 | 返回正确缺勤次数 |
| 触发器 | 插入第 3 条缺勤记录 | 输出预警信息 |
| 审批流转 | 模拟请假两级审批 | 状态按规则流转，拒绝后不再流转 |
答辩时老师最爱问的三个问题：为什么班主任单独建表而不是在教师表加标志位？为什么统计逻辑放存储过程而不是应用层？触发器里查同一张表会不会有性能问题？前两个按本文的设计思路答就行，第三个要承认行级触发器逐行统计在数据量大时确实有开销，实际项目里会改成定时统计或物化视图。
演示的时候，建议按“学生请假→班主任审批→院系领导审批→任课老师录考勤→学生查统计”这条完整链路走一遍，比单独展示每个功能有说服力。数据提前准备好，别现场从空表开始插，容易翻车。
从那以后我每次带课程设计，都强制让学生先把 E-R 图和数据字典对齐再动手建表，建表脚本按依赖顺序排好，验收前用user_constraints查一遍约束完整性。这套流程走下来，答辩时被问住的概率会低很多。希望帮到你。
本文还有配套的精品资源，点击获取
