# 校园生活平台数据库课程设计需求分析报告

## 摘要

本报告围绕“校园生活平台”数据库课程设计展开需求分析。结合课程设计要求与现有项目基础，报告将研究范围聚焦为平台基础子系统、功能房预约子系统和课程资源分享子系统，并将数字图书馆作为可选扩展进行说明。全文从课题背景、建设目标、可行性分析、系统范围、用户角色、业务流程、功能需求、数据需求、非功能需求和方案比较等方面，对系统建设需求进行了系统梳理。需求分析结果表明，本课题具有多角色协同、多实体联系、多状态流转、多约束控制和多统计场景等特点，适合作为数据库原理及应用课程中的综合建模案例。该报告将作为后续概念结构设计、关系模式设计、完整性约束设计、事务设计和测试分析的直接依据。

## 关键词

校园生活平台；需求分析；数据库设计；功能房预约；课程资源分享

## 1 引言

### 1.1 课题背景

随着高校信息化建设的不断推进，校园中的用户管理、组织管理、场地预约、教学资源共享等业务逐渐由分散、人工和纸质化管理转向统一、数字化和可追溯化管理。这些业务普遍具有数据对象多、实体联系复杂、权限边界细、状态流转明确、统计分析需求强等特点，是数据库系统分析与设计中的典型应用场景。

本课题以“校园生活平台”为题，在已有项目基础上，按照《数据库原理及应用》课程设计要求，对系统进行需求分析与数据库导向的重新梳理。与一般 Web 项目不同，本课题不以界面展示为核心，而以数据库对复杂业务的建模能力为重点，强调实体联系设计、完整性约束表达、事务一致性控制和统计查询支撑。

### 1.2 编写目的

本报告的主要目的如下：

- 明确课题建设背景、研究目标和系统边界；
- 识别主要用户角色及其典型业务场景；
- 梳理主线业务流程并归纳核心功能需求；
- 明确系统所需的主要数据对象、关键联系和完整性要求；
- 为后续概念结构设计、逻辑结构设计、物理结构设计及测试分析提供依据。

### 1.3 课题定位

本课题题目保持为“校园生活平台”，但本轮课程设计不追求覆盖全部历史业务模块，而是围绕数据库设计最具有代表性的业务进行深化。系统建设重点集中在以下三个方面：

- 平台基础子系统：身份与鉴权、组织结构、RBAC、数据范围、审计日志；
- 核心业务子系统一：功能房预约；
- 核心业务子系统二：课程资源分享；
- 可选扩展：数字图书馆。

这一定位有利于在有限课程周期内突出数据库课程设计的主线，使需求分析、数据库建模和后续实现验证具有清晰而集中的对象。

## 2 可行性分析

### 2.1 技术可行性

本课题以 PostgreSQL 为核心数据库。PostgreSQL 具备关系模型、主键外键、唯一约束、检查约束、触发器、事务、索引和复杂查询等能力，能够较好支撑本课题中的多实体、多关系、多状态和多统计场景。现有项目基础已经提供了较为完整的运行环境和业务雏形，使本轮工作能够把主要精力投入到需求分析、数据库建模和报告质量上，而不必重复进行底层项目骨架搭建。

### 2.2 经济可行性

本课题所依赖的开发工具、数据库内核和基础环境以开源或低成本方案为主，普通开发设备即可满足课程设计要求，不需要额外采购昂贵软硬件资源，因此具有良好的经济可行性。

### 2.3 进度可行性

课程设计周期有限，若继续覆盖全部历史模块，将导致分析范围过大、重点分散、数据库设计深度不足。为保证课题质量，本课题采用“题目不变、范围聚焦”的策略，将平台基础、功能房预约和课程资源分享确定为主线模块，并将数字图书馆作为可选扩展。这一范围控制有利于在课程时间内完成规范、完整、可答辩的设计成果。

### 2.4 组织可行性

当前项目题目明确，主线模块清晰，需求分析、数据库设计和报告材料正在按课程设计口径逐步整理，具备继续开展概念结构设计、关系模式设计、约束设计和实现验证的组织基础。

### 2.5 可行性结论

综合技术、经济、进度和组织四方面分析，本课题具备良好的实施条件。采用聚焦主线模块的方式，既能满足课程设计对完整性的基本要求，又能够更突出数据库设计的学习成果，因此具有较高的整体可行性。

## 3 系统范围与边界

### 3.1 本轮纳入范围

本轮课程设计的正式研究范围见表 3-1。

| 范围类别 | 具体内容 |
|----------|----------|
| 平台基础子系统 | 身份与鉴权、组织结构、RBAC、数据范围、审计日志 |
| 核心业务子系统一 | 功能房预约 |
| 核心业务子系统二 | 课程资源分享 |
| 可选扩展 | 数字图书馆 |

### 3.2 本轮不作为重点的内容

以下历史模块虽然在仓库中仍保留实现，但不属于本轮课程设计的重点需求分析范围：

- 通知公告；
- 问卷；
- 投票；
- 材料收集；
- 失物招领；
- AI 工作台等历史辅助功能。

### 3.3 系统边界说明

本系统边界内部主要包括：

- 面向普通用户的前台业务使用界面；
- 面向管理人员的后台管理界面；
- 负责业务编排与权限校验的 BFF 接口层；
- 作为核心数据载体的 PostgreSQL 数据库；
- 文件对象存储的元数据管理。

本轮课程设计重点关注数据库相关内容，即业务对象识别、实体联系建模、完整性约束、事务一致性和统计支撑，不将底层部署、消息通知、支付结算、复杂外部系统集成等内容作为重点研究对象。

## 4 用户角色与典型业务场景

### 4.1 用户角色分析

系统中的主要角色及其职责见表 4-1。

| 角色 | 职责说明 |
|------|----------|
| 普通用户（user） | 注册登录、维护个人资料、查询房间、发起预约、浏览资源、投稿资源 |
| 工作人员（staff） | 执行预约审核及部分业务管理 |
| 专业负责人（major_lead） | 审核和管理所负责专业范围内的课程资源 |
| 管理员（admin） | 管理用户、组织、角色、房间、专业、课程、系统配置与统计 |
| 超级管理员（super_admin） | 承担系统级全局管理与高权限控制 |
| 图书管理员（librarian，可选） | 在图书馆扩展模块中负责图书资源审核与运营 |

### 4.2 典型业务场景

#### 4.2.1 学生预约功能房

普通用户在前台按楼房、楼层和时间窗口查询房间占用情况，选择合适房间和时间段后提交预约申请。系统根据审核配置、时间规则、参与人规则和封禁状态生成预约结果，并保留后续审核、取消、驳回重提和统计分析所需数据。

#### 4.2.2 工作人员审核预约

工作人员在后台查看待审核预约，对预约执行通过或驳回操作，并记录审核人、审核时间和审核意见，以便后续查询、追溯和统计。

#### 4.2.3 学生投稿课程资源

普通用户选择专业和课程，创建资源草稿，上传文件或录入外链，填写标题、描述等元数据后提交审核。系统需保存资源主体信息，并为后续审核、下载和统计提供基础。

#### 4.2.4 专业负责人审核资源

专业负责人仅能管理自己负责专业范围内的课程资源。其主要操作包括通过、驳回、下架和推荐资源，并触发相应的审核记录、推荐记录和积分记录。

#### 4.2.5 管理员查看审计日志

管理员在后台查看一定时间范围内的关键管理行为，对操作者、动作、目标对象和执行结果进行追踪，用于责任认定、异常排查和运维分析。

### 4.3 角色分析结论

本课题是一个典型的多角色、多权限、多业务对象系统。平台基础子系统为各业务模块提供统一的身份、组织、权限、数据范围和审计能力，因此后续数据库设计必须同时考虑：

- 用户与组织关系；
- 用户与角色关系；
- 角色权限与数据范围的协同表达；
- 审核流、统计流和审计流的统一支撑。

## 5 业务流程分析

### 5.1 平台基础子系统业务流程

平台基础子系统的核心流程主要包括：

1. 用户完成注册、登录和邮箱验证，形成身份事实；
2. 系统同步或维护用户资料，并根据业务规则确定用户状态；
3. 管理员维护部门、岗位、角色、权限和数据范围；
4. 管理员为用户配置部门、岗位和角色；
5. 系统对管理端关键写操作自动记录审计日志。

该流程的数据库关注点在于：用户生命周期表达、组织层级表达、多对多关系拆分、数据范围配置表达，以及审计信息的可追溯保存。

### 5.2 功能房预约子系统业务流程

功能房预约模块的主要流程如下：

1. 用户按楼房、楼层和时间窗口查询房间占用情况；
2. 用户选择目标房间、使用时间和用途，填写参与人后提交预约；
3. 系统校验时间合法性、参与人合法性、封禁状态和预约规则；
4. 系统根据审核开关决定直接通过或进入待审核状态；
5. 审核人员对待审预约执行通过或驳回；
6. 用户可在符合条件时取消预约，或修改被驳回预约后重新提交；
7. 系统依据预约事实数据生成房间使用排行和用户使用排行。

该流程的数据库关注点在于：房间与预约的从属关系、时间区间冲突控制、预约状态流转、参与人关系建模、多表写入的一致性以及统计查询支撑。

### 5.3 课程资源分享子系统业务流程

课程资源模块的主要流程如下：

1. 管理员维护专业、课程和专业负责人；
2. 用户选择专业和课程后创建资源草稿；
3. 用户上传文件或填写外链，补充标题和描述；
4. 用户在信息完整后提交审核；
5. 审核人员执行通过或驳回；
6. 已发布资源可被用户查询、浏览、下载和统计；
7. 管理人员可对资源执行下架、推荐等运营动作；
8. 系统依据下载事实和积分事实生成资源排行与用户排行。

该流程的数据库关注点在于：教学层级关系建模、资源状态机建模、文件型与外链型资源约束、主体数据与事件数据分层，以及推荐和积分语义的一致性表达。

## 6 功能需求分析

### 6.1 功能需求说明

在需求分析阶段，系统功能不宜停留在简单的“页面有什么按钮”，而应从业务目标出发，明确系统必须支持哪些功能组、由哪些角色使用、完成后产生什么业务结果。结合本课题范围，功能需求可分为平台基础、功能房预约、课程资源分享和可选扩展四部分。

### 6.2 平台基础子系统功能需求

平台基础子系统的核心功能需求见表 6-1。

| 功能组 | 主要需求编号 | 需求说明 | 优先级 |
|--------|--------------|----------|--------|
| 用户注册与资料维护 | FR-PC-01 ~ FR-PC-02 | 支持用户注册、登录、邮箱验证以及个人资料查看维护 | 高 |
| 用户状态管理 | FR-PC-03 | 支持审核、启用、停用、封禁、删除等状态管理 | 高 |
| 组织结构管理 | FR-PC-04 ~ FR-PC-07 | 支持部门树管理、岗位管理以及用户部门/岗位分配 | 高 |
| 角色与权限管理 | FR-PC-08 ~ FR-PC-10 | 支持角色管理、权限字典管理和用户角色分配 | 高 |
| 数据范围配置 | FR-PC-11 | 支持按模块为角色配置数据可见范围 | 高 |
| 审计与配置管理 | FR-PC-12 ~ FR-PC-14 | 自动记录关键管理行为，并支持审计查询与系统配置维护 | 高 |

### 6.3 功能房预约子系统功能需求

功能房预约模块的核心功能需求见表 6-2。

| 功能组 | 主要需求编号 | 需求说明 | 优先级 |
|--------|--------------|----------|--------|
| 楼房与房间管理 | FR-FA-01 ~ FR-FA-03 | 支持楼房、房间基础数据维护以及按楼房楼层查询房间 | 高 |
| 时间占用查询 | FR-FA-04 | 支持按时间窗口查询房间占用情况 | 高 |
| 预约申请与参与人维护 | FR-FA-05 ~ FR-FA-06 | 支持用户提交预约并维护参与人信息 | 高 |
| 审核与取消重提 | FR-FA-07 ~ FR-FA-10 | 支持预约审核、取消、驳回后修改重提和个人预约查询 | 高 |
| 封禁与配置管理 | FR-FA-11 ~ FR-FA-12 | 支持对违规用户封禁及预约规则配置 | 高 |
| 统计排行 | FR-FA-13 | 支持按时间窗口生成房间和用户使用排行 | 中 |

### 6.4 课程资源分享子系统功能需求

课程资源模块的核心功能需求见表 6-3。

| 功能组 | 主要需求编号 | 需求说明 | 优先级 |
|--------|--------------|----------|--------|
| 专业与课程管理 | FR-CR-01 ~ FR-CR-03 | 支持专业维护、课程维护和专业负责人配置 | 高 |
| 草稿与内容录入 | FR-CR-04 ~ FR-CR-06 | 支持资源草稿创建、编辑以及文件或外链录入 | 高 |
| 审核与发布流转 | FR-CR-07 ~ FR-CR-09 | 支持提交审核、审核通过或驳回、资源发布与下架 | 高 |
| 资源浏览与查询 | FR-CR-10 ~ FR-CR-11 | 支持按专业、课程、关键词查询已发布资源并查看详情 | 高 |
| 下载、推荐与积分 | FR-CR-12 ~ FR-CR-14 | 支持下载记录、最佳推荐、积分事件与排行统计 | 高 |
| 我的资源管理 | FR-CR-15 | 支持用户查看和管理自己的资源列表与状态 | 高 |

### 6.5 可选扩展功能需求

数字图书馆作为可选扩展，其核心需求包括图书元数据管理、图书资源投稿、图书审核发布以及下载与收藏统计。该模块与课程资源分享在“主体数据 + 资产数据 + 下载事实数据”的建模思路上具有较高相似性，可作为后续模型复用与扩展的案例。

### 6.6 功能需求结论

从功能需求分析可以看出，本课题并不是单纯的 CRUD 系统，而是一个具有明显多角色协作、状态流转、统计分析和治理控制特征的业务系统。因此，后续数据库设计必须重点考虑：

- 多对多关系和层级关系的规范表达；
- 状态字段与辅助字段之间的一致性；
- 统计类需求对事实数据结构的依赖；
- 权限、数据范围和审计需求的统一支撑。

## 7 数据需求与数据库设计约束

### 7.1 数据分层思路

结合本课题业务特点，系统数据可分为以下四层：

- 主体数据：如用户、部门、角色、楼房、房间、专业、课程、资源等；
- 关系数据：如用户角色、用户部门、角色权限、专业负责人、预约参与人等；
- 过程状态数据：如预约记录、资源审核状态、封禁记录等；
- 事件与审计数据：如下载事件、积分事件、审计日志等。

这种分层有利于后续按照主体表、联系表、过程表、事实表和日志表进行数据库设计，也有利于从范式角度说明哪些数据属于主事实、哪些数据属于附属关系或过程记录。

### 7.2 核心数据对象需求

各模块的核心数据对象及主要联系见表 7-1。

| 模块 | 核心数据对象 | 主要联系 |
|------|--------------|----------|
| 平台基础 | 用户身份、用户资料、部门、岗位、角色、权限、数据范围、审计日志、配置项 | 用户与资料一对一；用户与部门/岗位/角色多对多；角色与权限多对多；角色与数据范围一对多 |
| 功能房预约 | 楼房、房间、预约记录、预约参与人、封禁记录 | 楼房与房间一对多；房间与预约一对多；预约与参与人一对多；用户与封禁记录一对多 |
| 课程资源分享 | 专业、课程、专业负责人、资源主体、下载事件、推荐记录、积分事件 | 专业与课程一对多；专业与负责人多对多；课程与资源一对多；资源与下载/推荐/积分事实一对多或一对一 |
| 数字图书馆（扩展） | 图书主体、图书资产、收藏记录、下载事件 | 图书与资产一对多；图书与收藏/下载事实相关联 |

### 7.3 数据完整性需求

#### 7.3.1 实体完整性需求

用户、部门、岗位、角色、权限、楼房、房间、预约、专业、课程、资源等核心业务对象，均必须具备稳定且唯一的标识。对于用户角色、角色权限、预约参与人、专业负责人等联系型数据，应优先使用复合标识或等价的唯一约束表达其业务唯一性。

#### 7.3.2 参照完整性需求

系统中的核心从属关系必须得到明确表达，主要包括：

- 房间必须依附于楼房；
- 预约必须依附于房间和申请用户；
- 课程必须依附于专业；
- 资源必须依附于课程；
- 多对多关系必须建立在真实主体存在的前提之上；
- 审计、统计和配置等辅助结构，应与其业务主体形成清晰联系。

#### 7.3.3 用户定义完整性需求

系统除实体完整性和参照完整性外，还应满足以下用户定义完整性要求：

- 学号、角色编码、权限编码等识别性字段应具有唯一性约束需求；
- 容量、分值、时间区间等字段应满足合法范围约束；
- 文件型资源与外链型资源的字段组合应满足业务规则；
- 状态字段与审核、取消、发布时间等辅助字段应保持一致；
- 下载、推荐和积分等事件记录应避免重复和错乱。

### 7.4 对后续数据库设计的要求

结合课程设计目标和老师对数据库设计的关注点，需求分析阶段可进一步提出以下数据库设计约束：

1. 核心事务型表应尽量满足第三范式，避免无意义重复存储；
2. 多对多关系应拆分为独立联系表，而不以字符串集合等非规范方式保存；
3. 核心关系优先采用显式物理外键，并明确删除策略；
4. 关键业务规则应优先通过主键、外键、唯一约束、检查约束和触发器等机制表达；
5. 若因查询、统计或业务范围控制需要保留冗余字段，必须说明其存在原因及一致性保证方式；
6. 下载事件、积分事件、审计日志等过程性记录应与主体数据分离建模。

### 7.5 数据需求结论

从数据需求角度看，本课题既包含稳定的主数据层，也包含复杂的关系层、状态层和事件层，能够较好体现关系数据库对复杂业务的建模能力。这也说明后续数据库设计不能仅停留在“能建表”，而应进一步从完整性、范式、约束和查询支撑角度进行系统设计。

## 8 非功能需求分析

### 8.1 非功能需求重点

本课题的非功能需求重点不在于超大规模互联网指标，而在于数据库课程设计所强调的几个核心问题：数据是否正确、规则是否清晰、权限是否有效、事务是否可靠、统计是否可解释、设计与测试是否可追溯。

### 8.2 主要非功能需求

系统的主要非功能需求见表 8-1。

| 类别 | 主要要求 |
|------|----------|
| 性能 | 常规分页查询、房间占用查询和统计排行应具备基本可用的响应性能，关键查询应有明确索引支撑 |
| 安全 | 未登录用户不得访问受保护数据，管理端操作必须经过角色权限校验，数据范围控制应在后端生效 |
| 一致性 | 多表联动操作应具备清晰事务边界，同一房间同一时间段不应出现冲突预约，资源状态与辅助字段应保持一致 |
| 可靠性 | 关键业务失败时不应留下明显不一致数据，审计日志应长期保留关键管理行为记录 |
| 可维护性 | 需求、设计、实现和测试之间应保持可追溯，命名规范应清晰统一，关键规则不应全部散落在应用层 |
| 可测试性 | 系统应能够验证外键、唯一约束、检查约束和异常场景下的业务流程正确性 |
| 文档质量 | 课程设计报告应结构清晰、术语准确、表达规范，能够直接服务于课程评审和课堂分享 |

### 8.3 非功能需求结论

本课题的非功能需求本质上服务于数据库课程设计的核心目标，即确保系统在正确性、一致性、可追溯性和可解释性方面具备基本质量。这意味着后续设计中必须优先考虑完整性约束、事务控制、索引设计、审计机制和测试验证，而不是把重点放在界面效果和工程炫技上。

## 9 方案比较与选型依据

### 9.1 课题范围方案

在范围选择上，曾考虑“继续覆盖全部历史模块”和“聚焦数据库主线模块”两种方案。前者覆盖面更广，但容易导致需求分析和数据库设计流于罗列；后者虽然范围更收敛，但更利于围绕复杂业务做深入建模。综合课程周期和评分重点，本课题最终采用“题目不变、范围聚焦”的方案。

### 9.2 数据库运行环境方案

在运行环境上，曾考虑“完全迁移为本地 PostgreSQL 环境”和“以 PostgreSQL 为数据库内核，继续使用现有兼容运行环境”两种方案。前者更符合传统实验环境直觉，但会增加环境迁移成本；后者既能保持数据库设计口径统一，又能复用现有工程基础，更适合本轮课程设计。因此，本课题采用后者，在报告中强调 PostgreSQL 的数据库设计，而不把托管运行平台本身作为设计重点。

### 9.3 身份认证方案

在认证方案上，曾考虑“完全自建认证系统”和“使用现有身份事实源，重点建设业务数据库”两种方案。前者工程成本高、容易分散主线；后者有利于把精力集中在业务数据库设计上。因此，本课题采用后者，在数据库设计中重点研究用户资料扩展、组织、权限、数据范围和业务表，而不将重写认证链路作为重点任务。

### 9.4 外键与规则表达方案

在关系表达上，曾考虑“逻辑外键为主”和“显式物理外键为主”两种方案；在规则落点上，曾考虑“规则主要放在应用层”和“关键规则尽量数据库化”两种方案。考虑到课程设计更强调数据库本身的主动作用，本课题最终选择：

- 核心关系优先采用显式物理外键；
- 关键业务规则尽量通过数据库结构和约束表达；
- 应用层主要承担流程编排与友好提示职责。

### 9.5 关键业务建模方案

在平台基础模块中，组织层级建模采用“父节点字段 + 层级扩展结构”的思路，以满足部门树和数据范围查询需求；在功能房预约模块中，冲突控制方案目标是向“数据库约束配合应用层提示”靠拢；在课程资源模块中，建模原则是优先遵循规范化，再在必要时对冗余字段进行受控保留并说明其存在理由。

### 9.6 方案选择结论

本课题的总体选型原则可以概括为：在不脱离现有工程基础的前提下，尽量采用更符合数据库课程设计评价标准的方案，使后续关系模式、完整性约束、事务设计和测试设计具有更强的可展示性和可解释性。

## 10 结论

本报告围绕“校园生活平台”数据库课程设计，从课题背景、建设目标、可行性、系统范围、角色场景、业务流程、功能需求、数据需求、非功能需求和方案比较等方面，完成了较完整的需求分析。

分析结果表明，本课题具有以下特点：

- 业务对象多，实体联系复杂；
- 平台基础与具体业务之间存在明显的治理与复用关系；
- 功能房预约体现了时间资源冲突与事务一致性问题；
- 课程资源分享体现了审核流、去重、事件事实和统计需求；
- 系统整体适合通过关系数据库完成规范化建模和完整性表达。

因此，本课题具备继续开展概念结构设计、关系模式设计、物理设计与测试分析的良好基础。后续工作应在本需求分析结论之上，进一步完成 E-R 图、关系模式、主键外键设计、完整性约束设计、索引设计、事务设计以及约束验证与测试分析，从而形成完整的数据库课程设计成果。