Oracle考勤请假系统数据库设计：从需求建模到SQL落地

简介：《Oracle数据库课程设计》面向学习数据库管理与开发的学生及IT从业者，围绕“学生考勤系统”的Oracle实现展开，可用于课程设计选题、数据库建模与报告撰写参考。压缩包仅含1个doc文档，大小约227KB，内容以课程设计报告形式组织，涵盖背景分析、用户与功能需求、功能模块划分、E-R模型、数据字典、数据库表逻辑结构，以及表空间和表的创建等环节。已有967人学习或下载，说明其在同类课程设计资料中具备一定参考热度。读者可从中获取较完整的考勤系统设计脉络、Oracle建表与数据库对象创建思路，并借鉴心得体会和报告结构，用于梳理需求、完善E-R图与表结构设计，提升数据库课程设计的规范性和可操作性。

1. 从一次点名说起：这套 Oracle 考勤系统要解决什么

任课老师拿着点名册逐个念名字，班长在 Excel 里打勾，学生请假要跑三趟办公室盖章——这套流程在某高校的日常教学里跑了很多年，直到有一次期末统计出勤，三份 Excel 版本对不上，谁也不知道哪份是真的。这份 Oracle 数据库课程设计要解决的，就是这条链路上的信息断层：学生请假不透明、任课老师看不到请假单、班主任统计不了全班、院系领导拿不到本学院的整体出勤。系统面向学生、任课老师、班主任、院系领导、学校领导、系统管理员六类角色，围绕请假、考勤、后台管理三个模块建库建表，核心交付物是一套能在 Oracle 里跑通、外键齐全、约束站得住的数据库设计与实现脚本。

2. 需求分析与角色建模：六类用户和三大模块的职责边界

课程设计最容易翻车的地方，不是 SQL 写不出来，而是需求分析写成了三段大白话，后面建表时才发现少了一个字段、多了一个角色。我在动手画 E-R 图之前，通常会先把六类用户的诉求摊开写清楚，再收敛成模块，最后翻译成一张能被逐条打勾的功能清单。

2.1 六类用户的诉求差异比想象中大

学生关心的是两件事：请假提交出去之后卡在谁那里，以及自己这学期某门课到底缺了几次。这两件事对数据库的要求完全不同——前者要一条能查审批状态的链路，后者要一张按学生和课程聚合的考勤明细表。

任课老师的核心动作是录入考勤。这里有个容易被忽略的需求：系统要能自动列出还没公布考勤的课次，并且根据学生已有的请假记录，把「请假期间被记旷课」的情况自动纠正过来。这条需求直接决定了请假表和考勤表之间必须存在关联，而不能各存各的。

班主任的需求是审批加查看。审批对象是本班学生的请假申请，查看范围是本班所有课程的出勤统计。院系领导多了一层：请假天数超过三天的，班主任批完还要流转到院系领导，而且院系领导只应该看到本学院的考勤数据。学校领导只看不批，范围是全校。系统管理员是唯一能改基础数据的角色——院系、专业、班级、课表、任课安排、班主任指派，全在他手里。

这六类角色放在一张用户表里还是分六张表？我一般倾向分表：学生、教师、班主任、院系领导、学校领导、管理员各自有独立编号规则和字段集合，硬塞进一张表会出现大量空字段。原文设计里正是分成了 admin、student、teacher、classteacher、collegeleader、schoolleader 六张角色表，代价是登录时要先判断角色再查对应表，这个取舍在课程设计规模下是划算的。

2.2 三大模块的依赖链：请假喂给考勤，后台喂给全部

三个模块不是并列的，是一条单向依赖链：后台管理 → 请假系统 → 考勤系统。

后台管理是地基。每学年的课表在变、班主任在换、学生在流动，如果这些基础数据不能动态更新，上面的请假和考勤全是死数据。所以后台模块要管五件事：院系年级专业班级的增删改、每学期每班的课程安排与任课老师指派、全部用户账号、全校课表、以及请假与考勤数据的兜底维护。

请假系统是中间层。它的审批流是两级：班主任先批，超过三天再进院系领导。请假最长不超过一个月，特殊情况另走线下。这条规则要落到字段上，就得有class_tea_sp_status、coll_leader_sp_status两个状态位和对应的时间戳、审批人编号，否则查不出「卡在谁那里」。

考勤系统是消费端。任课老师录考勤时，系统要读过请假表判断这条记录该记「请假」还是「旷课」；班主任、院系领导、学校领导看到的是不同粒度的聚合结果。这三个模块的依赖关系如果没在需求阶段说清楚，后面建外键时会发现请假表和考勤表之间没有可连的键。

提示：依赖链决定了建表顺序，也决定了外键方向。请假表要引用班级、学生、班主任、院系领导；考勤表要引用学生、教师、课程。先画依赖，再写 CREATE TABLE，能省掉一半返工。

2.3 把需求翻译成可验收的功能点

需求描述写完还不算完，得能落到「用什么数据、查哪张表、输出什么」这个粒度。下面这张表是我在课程设计里用来对需求做收敛的，每一行都能在后面的验收环节原样拿出来测一遍。

这张表的作用不是交差，是自查。比如 F04 里「自动修正」这四个字，逼着你在设计阶段就决定：修正逻辑放在应用层还是数据库端。我一般放在存储过程里，因为课程设计通常没有完整应用层，把逻辑放在库里反而更容易演示和答辩。

还有一条容易被忽略的隐性需求：请假状态的语义必须全系统统一。原文备注里写得很清楚，0 是等待审批、1 是同意、2 是不同意。这三个数字如果在一个模块里写成中文「同意」，另一个模块写成'Y'，联调时就是灾难。状态码要在数据字典里定死，所有表和视图共用一套。

3. 从 E-R 图到十二张表：概念模型、数据字典与逻辑结构

E-R 图和数据字典是课程设计报告里最容易注水、也最容易被答辩老师追问的两节。老师一般不看图漂不漂亮，只看两件事：联系上的基数标对没有，数据字典里的「定义式」是不是真能推导出字段。

3.1 E-R 建模：先定实体，再定联系和基数

这套系统里有十个实体：学院、专业、班级、学生、教师、班主任、院系领导、学校领导、课程、请假条，外加一个考勤记录。实体本身不难，难的是联系。

几个必须标清的基数：一个学院有多个专业，一个专业属于一个学院，是一对多；一个专业有多个班级，一个班级有一个班主任，班主任和班级是一对一；一个学生属于一个班级，班级和学生是一对多；教师和课程是多对多，通过开课关系连接；学生和课程也是多对多，这个多对多就是考勤记录表存在的原因——它是一张带属性的联系表，属性包括上课时间、考勤状态、任课教师。

请假这条线稍微绕一点：学生和请假条是一对多，一个学生一学期可以请多次假；请假条和班主任是多对一（多条假条由同一个班主任批），请假条和院系领导也是多对一。这里不要图省事把班主任和院系领导都画成「人」这一个实体，否则审批人编号就没法做外键约束。

很多同学画 E-R 图时会漏掉「课程性质」「职称」这类描述性属性，觉得不影响关系。实际上课程性质（必修/选修）在考勤统计里是要分组的，职称在领导表里是必填字段，漏了就等于数据字典少一条。

3.2 数据字典：写成定义式，别写成字段罗列

数据字典合格的写法是「实体 = 属性1 + 属性2 + …」，而不是把建表语句抄一遍。举三个例子：

• 请假条信息 = 请假代号 + 班级代号 + 学生学号 + 请假原因 + 开始时间 + 结束时间 + 请假天数 + 申请时间 + 班主任审批状态 + 班主任审批时间 + 院系领导审批状态 + 院系领导代号 + 院系领导审批时间
• 学生信息 = 学号 + 姓名 + 性别 + 所属专业 + 所属院系 + 所属班级
• 考勤记录信息 = 考勤编号 + 上课时间 + 学生学号 + 考勤状态 + 教师编号 + 课程编号

写成定义式的好处是，每加一个「+」，后面就必须有一个字段对应，逻辑结构和概念模型天然对得上。反过来，如果建表时发现多出一个数据字典里没有的字段，说明概念模型漏了东西，得回去补 E-R 图，而不是偷偷加个字段了事。

数据字典里还要显式写出约束语义。比如请假天数的取值范围、考勤状态的枚举值、性别只能是男或女。这些在数据字典里写一句，到物理设计时就有依据写 CHECK 约束。

3.3 十二张表的逻辑结构与主外键方向

原文设计里一共十二张表，我把它们的主键和外键方向整理成一张概览，方便一眼看出依赖顺序。

从这张表能直接读出建表顺序：faculty 最先，因为它不依赖任何人；major 和 collegeleader 紧随其后；classteacher 依赖 major 和 faculty；classes 依赖 classteacher；student 依赖 classes、major、faculty；kaoqin_record 和 qingjia 最后建。

考勤表的设计有个细节值得说：它没有直接存班级编号，而是通过学生学号间接关联班级。这看起来多绕一层，但好处是学生转班之后，历史考勤记录不会被错误地归到新班级——因为班级归属是在查询时按当前学生档案算的。代价是查询要 JOIN，这在课程设计的数据量下完全不是问题。

请假表则同时存了班级代号和学生学号，这属于有意的冗余。原因是班主任审批时要按班级过滤，如果每次都从学生表反查班级，审批列表页的 SQL 会变长；而且学生转班后，历史请假单应该留在原班级的统计里。冗余字段要有明确理由，不能因为「方便」就到处加。

3.4 字段类型选择的三个判断依据

第一，中文姓名别用 CHAR。原文里不少中文字段写成char(10)或char(20)，在 AL32UTF8 字符集下 CHAR 的默认长度语义是字节，char(10)只够放三个汉字，多一个就报 ORA-12899。稳妥的做法是姓名字段统一VARCHAR2(30)，中文占三字节，能放十个汉字名字。

第二，时间字段只能用 DATE 或 TIMESTAMP。Oracle 里没有DATETIME这个类型，原文建表语句里写的datetime是 SQL Server 的习惯，直接搬过来会在 Oracle 里报「无效的数据类型」。课程设计用DATE就够，需要毫秒再上TIMESTAMP。

第三，状态码用 CHAR(1) 而不是 CHAR(10)。状态只有 0、1、2 三个值，定长十位既浪费空间，取出来还带一长串尾部空格，前端做字符串相等比较时莫名其妙不相等——这个坑我在第一次做课程设计时踩过，排查了两个晚上。

4. 物理落地：表空间、建表语句、约束与索引

逻辑结构定完，接下来的活是把图纸变成能跑的库。这一节的所有语句都是可执行的，直接贴进 SQL*Plus 或者 SQL Developer 就能跑，跑不通就说明中间某一步的顺序或类型出了问题。

4.1 表空间与存储参数：给课程设计单独开一块地

把课程设计的表全部丢进 SYSTEM 表空间是不合适的，一是权限上一般不给，二是清理时不好一次性删。建一个独立表空间，数据文件放在自己有权限的目录下。

-- 创建专用表空间，数据文件大小按课程设计数据量给 100M 足够 CREATE TABLESPACE kq_data DATAFILE '/u01/app/oracle/oradata/kq01.dbf' SIZE 100M AUTOEXTEND ON NEXT 50M MAXSIZE 2G DEFAULT STORAGE ( INITIAL 512K NEXT 128K MINEXTENTS 2 MAXEXTENTS 999 PCTINCREASE 0 ) ONLINE;

这段里几个参数值得解释清楚，答辩时被问到能答上来。AUTOEXTEND ON NEXT 50M是自动扩展，空间用完后一次加 50M，上限 2G，避免写满磁盘。INITIAL 512K是初始区大小，NEXT 128K是后续扩展步长，PCTINCREASE 0表示区按固定大小增长而不是按百分比递增——后者在老版本 Oracle 里会引发空间膨胀，设成 0 是稳妥做法。MINEXTENTS 2让对象一开始就分两个区，减少后续分配开销。

路径要改成自己环境里真实存在的目录，写错路径会直接报 ORA-01119。如果只是本地练习，用CREATE TABLESPACE kq_data DATAFILE 'kq01.dbf' SIZE 100M;让 Oracle 用默认路径也行，只是不够规范。

4.2 建表语句：顺序、约束和内联外键的正确写法

按依赖顺序建，先建被引用的表。下面给的是核心几张，其余表同理。

-- 1. 院系表：最顶层，无外键 CREATE TABLE faculty ( faculty_id NUMBER NOT NULL, faculty_name VARCHAR2(30) NOT NULL, CONSTRAINT pk_faculty PRIMARY KEY (faculty_id) ) TABLESPACE kq_data; -- 2. 专业表：引用院系 CREATE TABLE major ( major_id NUMBER NOT NULL, major_name VARCHAR2(30) NOT NULL, major_faculty NUMBER NOT NULL, CONSTRAINT pk_major PRIMARY KEY (major_id), CONSTRAINT fk_major_fac FOREIGN KEY (major_faculty) REFERENCES faculty(faculty_id) ) TABLESPACE kq_data; -- 3. 班主任表：引用专业和院系 CREATE TABLE classteacher ( classtea_no CHAR(5) NOT NULL, classtea_name VARCHAR2(30) NOT NULL, classtea_sex CHAR(1) NOT NULL, classtea_major NUMBER NOT NULL, classtea_faculty NUMBER NOT NULL, CONSTRAINT pk_classteacher PRIMARY KEY (classtea_no), CONSTRAINT ck_ct_sex CHECK (classtea_sex IN ('男','女')), CONSTRAINT fk_ct_major FOREIGN KEY (classtea_major) REFERENCES major(major_id), CONSTRAINT fk_ct_fac FOREIGN KEY (classtea_faculty) REFERENCES faculty(faculty_id) ) TABLESPACE kq_data; -- 4. 班级表：引用班主任 CREATE TABLE classes ( class_no CHAR(10) NOT NULL, class_name VARCHAR2(30) NOT NULL, classtea_no CHAR(5) NOT NULL, CONSTRAINT pk_classes PRIMARY KEY (class_no), CONSTRAINT fk_classes_ct FOREIGN KEY (classtea_no) REFERENCES classteacher(classtea_no) ) TABLESPACE kq_data; -- 5. 学生表：三个外键分别指向班级、专业、院系 CREATE TABLE student ( stu_no CHAR(10) NOT NULL, stu_name VARCHAR2(30) NOT NULL, stu_sex CHAR(1) NOT NULL, stu_class CHAR(10) NOT NULL, stu_major NUMBER NOT NULL, stu_faculty NUMBER NOT NULL, CONSTRAINT pk_student PRIMARY KEY (stu_no), CONSTRAINT ck_stu_sex CHECK (stu_sex IN ('男','女')), CONSTRAINT fk_stu_class FOREIGN KEY (stu_class) REFERENCES classes(class_no), CONSTRAINT fk_stu_major FOREIGN KEY (stu_major) REFERENCES major(major_id), CONSTRAINT fk_stu_fac FOREIGN KEY (stu_faculty) REFERENCES faculty(faculty_id) ) TABLESPACE kq_data;

这里要特别说明一个原文里的语法错误。原文写成stu_class char(5) foreign key references classes(class_no)，这种内联写法在 Oracle 里是非法的——FOREIGN KEY关键字只能出现在表级约束里，列级约束只能写REFERENCES。正确写法有两种：列级写stu_class CHAR(10) REFERENCES classes(class_no)，或者像上面这样用表级CONSTRAINT fk_xxx FOREIGN KEY (...) REFERENCES ...。后者更好，因为可以给约束起名字，后面报错时错误信息里会带约束名，排查快得多。

继续建考勤表和请假表，这两张是业务核心。

-- 6. 考勤记录表：状态 1 出勤 / 2 旷课 / 3 请假 CREATE TABLE kaoqin_record ( kaoqin_id CHAR(13) NOT NULL, sk_time DATE NOT NULL, stu_number CHAR(10) NOT NULL, stu_status CHAR(1) NOT NULL, teacher_no CHAR(10) NOT NULL, course_no CHAR(13) NOT NULL, CONSTRAINT pk_kaoqin PRIMARY KEY (kaoqin_id), CONSTRAINT ck_kq_status CHECK (stu_status IN ('1','2','3')), CONSTRAINT fk_kq_stu FOREIGN KEY (stu_number) REFERENCES student(stu_no), CONSTRAINT fk_kq_tea FOREIGN KEY (teacher_no) REFERENCES teacher(tea_no), CONSTRAINT fk_kq_course FOREIGN KEY (course_no) REFERENCES course(course_no) ) TABLESPACE kq_data; -- 7. 请假信息表：两级审批，0 待批 / 1 同意 / 2 不同意 CREATE TABLE qingjia ( id NUMBER NOT NULL, class_id CHAR(10) NOT NULL, stu_no CHAR(10) NOT NULL, leave_reason VARCHAR2(200) NOT NULL, start_time DATE NOT NULL, end_time DATE NOT NULL, day_number NUMBER(3) NOT NULL, qingjia_time DATE DEFAULT SYSDATE NOT NULL, class_tea_id CHAR(5), class_tea_sp_status CHAR(1) DEFAULT '0' NOT NULL, class_tea_sp_time DATE, coll_leader_sp_status CHAR(1) DEFAULT '0' NOT NULL, coll_leader_id CHAR(5), coll_leader_sp_time DATE, CONSTRAINT pk_qingjia PRIMARY KEY (id), CONSTRAINT ck_qj_days CHECK (day_number BETWEEN 1 AND 31), CONSTRAINT ck_qj_ct_status CHECK (class_tea_sp_status IN ('0','1','2')), CONSTRAINT ck_qj_cl_status CHECK (coll_leader_sp_status IN ('0','1','2')), CONSTRAINT fk_qj_class FOREIGN KEY (class_id) REFERENCES classes(class_no), CONSTRAINT fk_qj_stu FOREIGN KEY (stu_no) REFERENCES student(stu_no), CONSTRAINT fk_qj_ct FOREIGN KEY (class_tea_id) REFERENCES classteacher(classtea_no), CONSTRAINT fk_qj_cl FOREIGN KEY (coll_leader_id) REFERENCES collegeleader(collegeleader_no) ) TABLESPACE kq_data;

请假表用了DEFAULT SYSDATE让申请时间自动落库，用了DEFAULT '0'让新提交的请假单默认处于待审批状态，这两处默认值能省掉应用层不少判空逻辑。day_number加了 1 到 31 的 CHECK，对应「请假最长不超过一个月」这条需求；注意这条约束是硬约束，如果确实有特殊情况要请更长的假，那得走线下流程，数据库层面不该给它开口子。

4.3 约束设计：CHECK 管枚举，外键管引用完整性

约束不是越多越好，但该有的必须有。性别字段加 CHECK 限死男女，看着像形式主义，实际能挡住前端传过来的'M'、'male'、'未知'各种变体。状态码加 CHECK，能防止有人把'9'写进去导致统计全部失真。

外键的删除行为要提前定。学生毕业、班级撤销时，如果直接 DELETE 父表记录，默认的NO ACTION会报 ORA-02292，逼你去处理子表。这是好事，说明数据有依赖。不建议随手写ON DELETE CASCADE，考勤记录和请假单是审计数据，级联删掉就找不回来了。合理的做法是先归档再删。

注意：外键约束在建表时创建，比建完表再用 ALTER TABLE 添加要好——建表时数据为空，校验一次通过；等表里进了脏数据再补外键，会直接报 ORA-02298 找不到父键，得先洗数据。

4.4 索引：只给真正会查的列加

主键自动带唯一索引，外键列不会自动建索引（这点和 MySQL 不同），所以要手动补。这套系统里高频查询有三类，对应三个索引。

-- 按学生 + 课程查考勤明细，学生端和老师端都用得上 CREATE INDEX idx_kq_stu_course ON kaoqin_record (stu_number, course_no, stu_status) TABLESPACE kq_data; -- 按时间范围查某次课的考勤，老师录入和统计用 CREATE INDEX idx_kq_time ON kaoqin_record (sk_time, course_no) TABLESPACE kq_data; -- 班主任按状态拉待审批列表 CREATE INDEX idx_qj_status ON qingjia (class_tea_sp_status, class_id) TABLESPACE kq_data;

第一个索引的列序有讲究：stu_number在前，因为「查某个学生的所有考勤」选择性最高；stu_status放最后，因为它是低基数列（只有三个值），放前面反而降低索引效率。第二个索引服务的是「某门课某天的考勤记录」这类查询。第三个索引针对审批列表页，class_tea_sp_status = '0'配合班级过滤，能避免全表扫描。

索引不是白给的，每加一个都会拖慢 INSERT。课程设计的数据量小，感受不到差别，但答辩时如果被问到「为什么给这一列加索引」，得能说出对应的查询场景，而不是「老师说要加」。

5. 库端逻辑落地与避坑：视图、存储过程、触发器的分工

课程设计里最有含金量的部分，是那些「放在数据库端做」的功能。好处是答辩演示时一条 SQL 就能出结果，不用启动整个应用；坏处是逻辑一旦写错，排查起来比应用层更麻烦。这一节把三类对象的职责边界划清楚，再列五个我见过最多的翻车现场。

5.1 视图：把院系数据隔离做在查询层

院系领导只能看本学院学生的考勤，这是明确的需求。最直觉的写法是给每个学院建一个视图，比如软件学院一个、机械学院一个，视图里把stu_faculty = 5硬编码进去。原文的设计就是这么干的。

这么写能跑通，但学院一多就完蛋——十几个视图，每个都要维护，加一个学院就要多建一个对象。更稳妥的做法是建一个带学院维度的公共视图，查询时由应用层传入当前登录人的学院编号。

-- 公共视图：暴露学院维度，过滤条件交给调用方 CREATE OR REPLACE VIEW v_kaoqin_detail AS SELECT r.kaoqin_id, r.sk_time, r.stu_number, r.stu_status, r.teacher_no, r.course_no, s.stu_name, s.stu_faculty, c.class_name FROM kaoqin_record r JOIN student s ON s.stu_no = r.stu_number JOIN classes c ON c.class_no = s.stu_class;

视图起了两个作用：一是把三表 JOIN 封装起来，院系领导、班主任、学校领导三种角色的查询都基于它，只是 WHERE 条件不同；二是收敛字段，避免上层直接SELECT *拿到不该看的列。调用时院系领导那条 SQL 写成SELECT * FROM v_kaoqin_detail WHERE stu_faculty = :fid，参数由登录态带入，不硬编码在数据库对象里。

如果确实需要在数据库层面强制隔离（比如多个应用共用一套库），Oracle 提供了行级安全策略DBMS_RLS，可以按会话上下文自动追加谓词。课程设计阶段用不上，但知道有这么个东西，答辩时聊到数据权限能加不少分。

5.2 存储过程：缺勤统计和审批流转

统计学生某门课的出勤情况，这个逻辑如果每次都写一遍 JOIN 加 COUNT，SQL 会散落在各处。封装成存储过程，参数化调用，改口径时只改一处。

CREATE OR REPLACE PROCEDURE sp_stu_absence ( p_stu_no IN VARCHAR2, -- 学生学号 p_course_no IN VARCHAR2, -- 课程编号 p_total OUT NUMBER, -- 该课程总考勤次数 p_absent OUT NUMBER -- 其中旷课次数 ) AS BEGIN SELECT COUNT(*) INTO p_total FROM kaoqin_record WHERE stu_number = p_stu_no AND course_no = p_course_no; SELECT COUNT(*) INTO p_absent FROM kaoqin_record WHERE stu_number = p_stu_no AND course_no = p_course_no AND stu_status = '2'; -- 2 表示旷课 EXCEPTION WHEN NO_DATA_FOUND THEN p_total := 0; p_absent := 0; END; /

原文的版本只有一个total_times输出参数，而且写成了total_times=absence_times——PL/SQL 里赋值必须用:=，用等号是语法错误。上面这版拆成总次数和旷课次数两个输出，调用方拿到两个数就能自己算缺勤率，比在过程里算好百分比更灵活。EXCEPTION段兜住空结果，避免学生没上过这门课时过程直接抛异常。

审批流转的过程更值得写，因为它是多角色状态机，纯 SQL 表达不了「班主任没批，院系领导不能批」这个前置条件。

CREATE OR REPLACE PROCEDURE sp_approve_leave ( p_id IN NUMBER, -- 请假单号 p_role IN VARCHAR2, -- 'CLASS' 班主任 / 'COLLEGE' 院系领导 p_result IN NUMBER, -- 1 同意 / 2 不同意 p_op_no IN VARCHAR2 -- 审批人编号 ) AS v_days NUMBER; v_status CHAR(1); BEGIN SELECT day_number, class_tea_sp_status INTO v_days, v_status FROM qingjia WHERE id = p_id FOR UPDATE; -- 行锁，防止并发重复审批 IF p_role = 'CLASS' THEN UPDATE qingjia SET class_tea_sp_status = p_result, class_tea_sp_time = SYSDATE, class_tea_id = p_op_no WHERE id = p_id; ELSIF p_role = 'COLLEGE' THEN -- 前置校验：班主任必须已同意，且请假天数超过三天 IF v_status <> '1' THEN RAISE_APPLICATION_ERROR(-20001, '班主任尚未同意，院系领导不能审批'); END IF; IF v_days <= 3 THEN RAISE_APPLICATION_ERROR(-20002, '三天以内请假由班主任终审'); END IF; UPDATE qingjia SET coll_leader_sp_status = p_result, coll_leader_sp_time = SYSDATE, coll_leader_id = p_op_no WHERE id = p_id; ELSE RAISE_APPLICATION_ERROR(-20003, '未知的审批角色'); END IF; COMMIT; EXCEPTION WHEN NO_DATA_FOUND THEN RAISE_APPLICATION_ERROR(-20004, '请假单不存在'); END; /

FOR UPDATE这行容易被漏掉，但它是并发场景下防止两个班主任同时批同一张单的关键。RAISE_APPLICATION_ERROR的错误码要落在 -20000 到 -20999 之间，这是 Oracle 给用户自定义错误预留的区间。错误信息直接写中文，调用方捕获后能原样展示给用户。

5.3 触发器：可以做提示，但别拿它当约束

缺勤超过三次取消考试资格，这个提示用触发器做是最自然的时机——考勤记录一插入就判断。

-- 告警日志表，用来存触发器产生的提示 CREATE TABLE kaoqin_alert ( alert_id NUMBER GENERATED BY DEFAULT AS IDENTITY, stu_number CHAR(10) NOT NULL, course_no CHAR(13) NOT NULL, alert_time DATE DEFAULT SYSDATE, msg VARCHAR2(200), CONSTRAINT pk_kq_alert PRIMARY KEY (alert_id) ) TABLESPACE kq_data; -- 插入旷课记录后，统计该生该课旷课次数，达阈值写日志 CREATE OR REPLACE TRIGGER trg_kaoqin_alert AFTER INSERT ON kaoqin_record FOR EACH ROW WHEN (NEW.stu_status = '2') DECLARE v_times NUMBER; BEGIN SELECT COUNT(*) INTO v_times FROM kaoqin_record WHERE stu_number = :NEW.stu_number AND course_no = :NEW.course_no AND stu_status = '2'; IF v_times >= 3 THEN INSERT INTO kaoqin_alert (stu_number, course_no, msg) VALUES (:NEW.stu_number, :NEW.course_no, '该课程旷课已达' || v_times || '次，取消考试资格'); END IF; END; /

原文的触发器用dbms_output.put_line输出提示，这在 SQL*Plus 里能看到，但应用端根本收不到——这是个典型的「演示时好好的，交付后没人知道」的问题。改成写日志表，前端查表就能弹出提示，也留下了审计痕迹。

WHEN (NEW.stu_status = '2')这个条件要注意，触发器里的WHEN子句不能用:NEW，要写NEW，到了 BEGIN 块里才用冒号。这是个语法细节，写错了报 ORA-04079。

更重要的是，触发器不该承担「禁止插入」这类职责。比如「同一学生同一课程同一天不能重复记考勤」，用触发器RAISE_APPLICATION_ERROR拦下来，看起来很优雅，实际会让批量导入数据变得极其难处理。这种唯一性约束交回给表上的 UNIQUE 约束更合适。

5.4 五个常见翻车点：现象、原因、解决

第一个：使用 DATETIME 类型，建表直接报错。现象是执行 CREATE TABLE 时报 ORA-00902 无效的数据类型，整段脚本停在第一张表。原因是 Oracle 没有DATETIME这个类型，那是 SQL Server 的写法。解决是把所有时间字段改成DATE，需要毫秒精度再考虑TIMESTAMP。这个问题在从网上抄建表脚本时特别容易发生。

第二个：中文字段长度不够，插入时报 ORA-12899。现象是插入学生姓名'欧阳修文'时报值太大。原因是数据库字符集是 AL32UTF8，CHAR(10)默认按字节算，一个汉字三字节，十个字节只够三个汉字加一个尾巴。解决是把姓名类字段统一改成VARCHAR2(30)以上，建表时显式确认字符集NLS_CHARACTERSET。

第三个：外键列没建索引，考勤统计查询慢到超时。现象是数据量上了几万条后，班主任查全班出勤要等十几秒。原因是 Oracle 不会给外键列自动建索引，kaoqin_record上的stu_number没有索引，每次关联学生表都全表扫描。解决方法是对所有高频 JOIN 的外键列补建索引，用EXPLAIN PLAN确认执行计划里走了 INDEX 而不是 TABLE ACCESS FULL。

第四个：状态码用 CHAR 存，查出来的值永远不相等。现象是WHERE stu_status = '1'查不到数据，但表里明明有。原因是用CHAR(10)存了'1'，Oracle 补了九个空格，和前端的单字符比较时行为不一致。解决方法是将状态字段改为CHAR(1)或VARCHAR2(2)，从根上避免定长补空格。

第五个：请假和考勤各记各的，同一天的记录对不上。现象是学生明明请了假，考勤表里还是旷课。原因是任课老师录考勤时，系统没有回查请假表。解决方法是在录入考勤的存储过程里，先按stu_no + sk_time BETWEEN start_time AND end_time查请假单，命中且已审批同意的，直接把状态置为 '3'（请假），而不是 '2'。这条逻辑必须写进过程，靠人工核对迟早出错。

6. 验收与答辩：用一组 SQL 证明这套库是通的

课程设计交上去之前，我习惯做一轮「空库重跑」：新建一个干净的 schema，把建表、建约束、建索引、建视图和过程的脚本从头到尾跑一遍，中间不许手工干预。只要有一句报错，就说明脚本交付给别人时跑不起来。这一步能筛掉八成的低级错误。

重跑通过之后，用下面这几条 SQL 做功能验收，每条都对应一个设计点，答辩时可以直接演示。

答辩环节，老师最常追问的是三个方向：为什么这么建表、约束为什么这么设、如果数据量涨一百倍会怎样。前两个答案都在数据字典和建表语句里，第三个问题要提前想好——索引列序、分区表、归档策略，能说出一两条就够，不必真做。

还有一个实用技巧：把建表脚本拆成 01_tablespace.sql、02_tables.sql、03_constraints.sql、04_index.sql、05_views_procedures.sql 五个文件，按序号执行。答辩演示时如果某一环节出错，能快速定位到是哪一类对象的问题，不用在一千行的脚本里翻。

从那以后，我每次交数据库设计之前，都会先在空 schema 里把脚本从零跑一遍，再把验收表里的六项逐个点一遍，才敢点提交。这套习惯后来做真实项目也没改过，因为它省下的返工时间远比执行它的时间多。希望帮到你。

本文还有配套的精品资源，点击获取