简介这份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 中应写为datevarchar建议统一为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里对同一张表做countOracle 允许行级触发器读同一张表但如果逻辑更复杂建议改成语句级触发器或把统计放到存储过程里由应用层调用。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查一遍约束完整性。这套流程走下来答辩时被问住的概率会低很多。希望帮到你。本文还有配套的精品资源点击获取