# 05 业务流程分析

## 5.1 分析目的

业务流程分析的目的在于：

- 梳理业务从开始到结束的完整过程
- 找出流程中的状态变更、角色协作和异常分支
- 识别哪些业务规则需要数据库负责表达和约束
- 为后续 E-R 图、关系模式、事务设计和测试设计提供依据

## 5.2 平台基础子系统流程

### 5.2.1 用户注册与激活流程

#### 流程目标

完成用户从“注册申请”到“成为可正常使用用户”的全过程管理。

#### 前置条件

- 系统具备可用的身份事实源
- 平台允许新用户注册

#### 正常流程

1. 用户填写注册信息并提交
2. 系统创建身份记录
3. 系统创建业务侧用户资料记录
4. 用户完成邮箱验证
5. 若注册审核开关关闭，则用户进入可使用状态
6. 若注册审核开关开启，则用户进入待审核状态
7. 管理员审核后，用户进入激活或停用状态

#### 异常流程

- 邮箱未验证：
  - 用户不能进入系统正常使用状态
- 注册信息重复或不完整：
  - 系统拒绝创建
- 审核未通过：
  - 用户不能获得正常使用权限

#### 对数据库的要求

- 用户身份与业务资料应建立明确关联
- 用户状态必须具备清晰生命周期
- 学号、邮箱、用户名等识别信息应具备唯一性要求
- 注册和审核行为应可追溯

### 5.2.2 组织、角色与数据范围配置流程

#### 流程目标

建立平台治理基础，为后续业务模块提供可复用的组织、授权和数据可见范围控制能力。

#### 正常流程

1. 管理员维护部门树
2. 管理员维护岗位信息
3. 管理员为用户分配部门和岗位
4. 管理员维护角色与权限字典
5. 管理员为用户分配角色
6. 管理员为角色配置模块级数据范围

#### 异常流程

- 部门形成循环层级
- 删除仍有子部门或用户绑定的部门
- 删除仍在使用的角色、权限或岗位
- 配置非法模块标识或非法数据范围

#### 对数据库的要求

- 部门应支持层级关系查询
- 多对多关系应通过中间表表达
- 数据范围配置应与角色、模块和部门建立稳定联系
- 所有关键变更应产生审计记录

### 5.2.3 审计记录流程

#### 流程目标

对后台关键管理行为形成可检索、可追溯的审计数据。

#### 正常流程

1. 管理员执行后台管理操作
2. 系统完成业务处理
3. 系统记录操作者、动作、对象、时间和上下文
4. 管理员按条件查询审计日志

#### 对数据库的要求

- 审计表应支持追加写入
- 审计记录应避免被普通流程修改或删除
- 应支持按时间、操作者、对象和动作检索

## 5.3 功能房预约子系统流程

### 5.3.1 房间查询流程

#### 流程目标

帮助用户在预约前了解可用空间和时间占用情况。

#### 正常流程

1. 用户选择楼房和楼层
2. 系统返回该范围内房间列表
3. 系统返回指定时间窗口内的预约占用信息
4. 用户据此选择可用房间和时间段

#### 对数据库的要求

- 楼房与房间之间需有稳定从属关系
- 预约记录需支持按房间、时间范围查询
- 时间轴查询需要适合的索引支撑

### 5.3.2 预约申请流程

#### 流程目标

完成用户发起预约申请的全过程。

#### 前置条件

- 用户已登录
- 房间处于可预约状态
- 用户未处于有效封禁状态

#### 正常流程

1. 用户选择房间和时间段
2. 用户填写预约用途
3. 用户添加参与人
4. 系统校验时间、参与人和业务规则
5. 若系统配置要求审核，则预约进入待审状态
6. 若系统配置无需审核，则预约直接进入通过状态
7. 系统保存预约记录及参与人记录

#### 异常流程

- 时间段与已有有效预约冲突
- 参与人不存在、重复或状态不合法
- 预约时长超过限制
- 用户处于封禁状态

#### 对数据库的要求

- 需要记录预约主体、申请人、参与人和时间区间
- 需要明确表达预约状态
- 需要支持时间冲突控制和事务一致性

### 5.3.3 预约审核流程

#### 正常流程

1. 审核人员查看待审核预约
2. 审核人员执行通过或驳回
3. 系统更新预约状态
4. 系统记录审核人、审核时间和审核意见
5. 系统写入审计日志

#### 异常流程

- 非待审预约被误审核
- 审核人无权限处理该预约
- 审核操作与状态流转不一致

#### 对数据库的要求

- 预约状态与审核字段必须保持一致
- 审核结果应具备完整历史可追溯性

### 5.3.4 预约取消流程

#### 正常流程

1. 用户在预约开始前发起取消
2. 系统判断当前状态是否允许取消
3. 系统更新预约状态为取消
4. 系统记录取消人和取消时间

#### 异常流程

- 预约已开始，不允许取消
- 预约已取消、已结束或状态不允许取消

#### 对数据库的要求

- 预约状态与取消字段需保持一致
- 取消操作需要具备时序约束

### 5.3.5 封禁与统计流程

#### 正常流程

1. 管理员对违规用户执行封禁
2. 系统保存封禁记录，可包含到期时间
3. 被封禁用户无法继续发起新预约
4. 系统基于预约事实记录生成房间使用榜和用户使用榜

#### 对数据库的要求

- 封禁记录需能表达生效、到期和撤销语义
- 统计应尽量基于事实数据而非手工汇总

## 5.4 课程资源分享子系统流程

### 5.4.1 专业与课程维护流程

#### 流程目标

建立课程资源的教学层级基础数据。

#### 正常流程

1. 管理员维护专业信息
2. 管理员在专业下维护课程信息
3. 管理员为专业配置一个或多个负责人

#### 对数据库的要求

- 专业与课程之间应保持明确从属关系
- 专业与专业负责人之间需支持多对多关系

### 5.4.2 资源投稿流程

#### 流程目标

完成普通用户从创建资源草稿到提交审核的全过程。

#### 正常流程

1. 用户选择专业和课程
2. 用户创建资源草稿
3. 用户上传文件或填写外链
4. 用户补充标题、描述等元数据
5. 用户提交审核

#### 异常流程

- 课程不存在或不属于所选专业
- 文件格式或大小不合法
- 外链不合法
- 与现有资源重复

#### 对数据库的要求

- 资源必须与课程建立清晰归属关系
- 资源类型应能区分文件型与外链型
- 去重规则应有明确数据支撑

### 5.4.3 资源审核与发布流程

#### 正常流程

1. 审核人员查看待审资源
2. 审核人员执行通过或驳回
3. 系统更新资源状态
4. 若审核通过，则资源进入可见状态
5. 若审核驳回，则记录驳回意见
6. 已发布资源后续可被下架，并在需要时重新提交

#### 对数据库的要求

- 资源状态必须支持完整生命周期
- 审核人、审核时间和审核意见应可追踪
- 状态字段与审核、发布时间字段应保持一致

### 5.4.4 下载、推荐与积分流程

#### 正常流程

1. 用户浏览已发布资源
2. 用户通过受控入口下载资源
3. 系统记录下载事件并更新统计
4. 管理人员可将资源标记为最佳推荐
5. 系统按规则生成积分事件和排行榜

#### 异常流程

- 非已发布资源被下载
- 重复推荐导致统计失真
- 积分重复发放

#### 对数据库的要求

- 下载事件应与资源主体分离建模
- 推荐事实应独立记录
- 积分发放应具备唯一性和幂等控制

## 5.5 业务流程分析结论

通过业务流程分析，可以归纳出本课题后续数据库设计需要重点解决的几个核心问题：

- 用户、组织、角色和数据范围的统一建模问题
- 功能房预约中的时间冲突与状态流转问题
- 课程资源中的审核流、去重和事件统计问题
- 管理行为的审计追踪问题

这些问题均具有明确的数据库设计价值，因此本课题适合作为数据库课程设计对象。