# 02 可行性分析

## 2.1 分析目的

可行性分析的目的是判断本课题是否适合作为《数据库原理及应用》课程设计的正式题目，以及是否能够在课程设计周期内完成具有较高质量的数据库分析、设计、实现与报告整理工作。

本章从技术、经济、操作、进度和组织五个方面进行分析。

## 2.2 技术可行性

### 2.2.1 数据库技术可行性

本课题以 PostgreSQL 为核心数据库管理系统，具备如下技术基础：

- 支持关系模型和 SQL 标准操作
- 支持主键、外键、唯一约束、检查约束等完整性机制
- 支持事务、并发控制、索引、视图、函数和触发器
- 支持复杂查询、聚合统计、时间范围查询和层级查询

这些能力能够较好覆盖本课题涉及的主要业务特点：

- 多实体、多联系建模
- 层级组织结构建模
- 审核与状态流转建模
- 事件统计与排行分析
- 关键业务一致性控制

因此，从数据库技术本身来看，本课题是可行的。

### 2.2.2 工程基础可行性

当前项目已具备一定工程基础，包括：

- 现有 Web 与 BFF 层
- 现有 PostgreSQL 运行环境
- 现有模块化代码与文档基础

这些基础虽然不是课程成绩的核心，但能够带来两方面好处：

- 降低重复搭建项目骨架的时间成本
- 使本轮工作能把重点放在需求分析、数据库设计与报告质量上

因此，从实现载体角度，本课题具备较好的工程基础可行性。

### 2.2.3 课程适配性可行性

老师强调本课程设计重点在于数据库设计，而不是界面效果。结合这一评价导向，本课题具有如下适配优势：

- 业务足够具体，便于开展需求分析
- 模块关系复杂，便于展示数据库建模能力
- 可明显体现主键、外键、范式、约束、触发器、事务等数据库知识
- 具备典型的并发、一致性和统计问题，适合进行课程层面的深入讨论

因此，本题与课程目标高度匹配。

## 2.3 经济可行性

本课题属于课程设计项目，不以商业化部署为目标，经济可行性主要体现在开发和演示成本是否可控。

当前使用的主要工具与平台包括：

- PostgreSQL：开源免费
- Next.js、TypeScript、Drizzle：开源工具链
- Supabase 或本地 PostgreSQL 环境：均存在低成本或免费可用方案
- 普通开发设备：即可满足课程设计所需

因此，本项目在硬件、软件和平台成本方面均具有较好的经济可行性。

## 2.4 操作可行性

### 2.4.1 面向使用者的操作可行性

本系统的目标用户均来自校园内部，业务场景贴近校园实际，用户认知成本较低：

- 学生易于理解“预约房间”“浏览资源”“分享资源”等功能
- 管理人员易于理解“审核”“配置角色”“查看审计”等操作
- 业务语义与高校日常管理场景高度一致

因此，从最终用户角度，系统具有良好的操作可行性。

### 2.4.2 面向开发者的操作可行性

本项目已经形成较清晰的主线范围和文档组织方式，便于开发者按以下顺序推进：

1. 需求分析
2. 概念结构设计
3. 逻辑结构设计
4. 物理设计与实现
5. 测试与报告整理

因此，从课程设计实施过程来看，也具有较高的可操作性。

## 2.5 进度可行性

课程设计周期较短，若试图在本轮中同时深化全部历史模块，将带来以下问题：

- 需求分析范围过大
- E-R 图与关系模式过于分散
- 报告重点模糊
- 关键业务无法深入设计

为解决这一问题，本课题采取“题目不变、范围聚焦”的策略，将主线收束为：

- 平台基础子系统
- 功能房预约子系统
- 课程资源分享子系统

数字图书馆作为可选扩展，不影响主线成立。

这种范围控制方式能够保证：

- 需求分析可深入展开
- 数据模型具备代表性
- 报告结构更加集中
- 更有利于在有限时间内做深数据库部分

因此，从进度安排看，本课题是可行的。

## 2.6 组织可行性

本课题在组织层面具备以下有利条件：

- 题目已确定，且老师允许在题目不变前提下聚焦部分模块进行迭代优化
- 已有工程基础可作为演示载体
- 现有文档已逐步按课程设计口径整理
- 本轮工作方向明确，以数据库设计为中心

同时，也存在一定风险：

- 历史模块较多，容易分散精力
- 既有工程思维容易压过课程设计思维
- 若过早进入实现细节，可能削弱需求分析与报告质量

对应的控制措施如下：

- 明确主线范围，只围绕三个重点模块开展分析与设计
- 先完成需求分析文档，再推进数据库设计与代码修改
- 通过独立目录组织正式需求分析材料，降低上下文丢失风险

## 2.7 风险分析与应对

| 风险 | 可能后果 | 应对措施 |
|------|----------|----------|
| 范围过大 | 报告浅、设计散 | 聚焦主线模块，暂不扩展全部历史功能 |
| 过度工程化 | 答辩偏离数据库主线 | 在文档和答辩中突出数据库对象、约束和设计过程 |
| 规则主要停留在应用层 | 数据库课程特色不足 | 后续设计时优先将关键规则下沉到数据库层 |
| 时间紧张 | 设计不完整 | 先完成需求分析和数据库主线，再考虑扩展模块 |

## 2.8 可行性分析结论

综合分析，本课题具有较强的可行性：

- 技术上可行：
  - PostgreSQL 能支撑本课题所需的关系建模、约束、事务和复杂查询
- 经济上可行：
  - 所需工具和环境成本低，适合课程设计
- 操作上可行：
  - 业务贴近校园场景，使用者和开发者都容易理解
- 进度上可行：
  - 通过范围聚焦，可在课程周期内形成高质量成果
- 组织上可行：
  - 题目明确、主线清晰、文档基础逐步完善

因此，本课题适合作为《数据库原理及应用》课程设计的正式选题，并适合在当前范围内继续开展需求分析、数据库设计与实现工作。