# 04 用户角色与业务场景 ## 4.1 分析目的 用户角色与业务场景分析是需求分析的重要组成部分。其作用在于： - 明确系统中“谁在使用系统” - 明确不同角色分别负责什么业务 - 明确哪些数据由谁创建、审核、维护和查询 - 为后续 RBAC、数据范围、审计与业务流程设计提供依据 ## 4.2 利益相关者分析 从业务关系看，本课题的主要利益相关者包括： - 普通学生用户： - 关注预约、资源获取和资源投稿体验 - 业务管理人员： - 关注审核效率、数据准确性和日常管理便利性 - 平台管理员： - 关注用户、组织、角色、数据范围和系统配置的统一管理 - 课程设计评审教师： - 关注系统是否体现数据库课程要求，尤其是需求分析合理性和数据库建模质量 ## 4.3 角色划分原则 本课题中的角色划分遵循以下原则： - 从业务职责出发，而非单纯从技术账号出发 - 区分普通使用者与管理者 - 区分“能否进入某模块”和“能看到哪些数据”两个层次 - 尽量与后续角色、权限和数据范围设计一致 ## 4.4 主要角色定义 ### 4.4.1 普通用户（user） 普通用户主要指平台前台的普通学生用户。 主要职责： - 注册、登录和维护个人资料 - 查询功能房信息和空闲时段 - 提交预约申请、查看和取消自己的预约 - 浏览已发布的课程资源 - 创建课程资源草稿并提交审核 - 查看自己的投稿记录和审核结果 主要涉及数据： - 用户资料 - 预约记录 - 预约参与人记录 - 课程资源草稿与发布记录 - 下载行为记录 ### 4.4.2 工作人员（staff） 工作人员是后台中的业务审核角色之一，主要负责功能房预约的日常审核和部分业务管理。 主要职责： - 查看待审核预约 - 执行预约通过或驳回 - 在授权范围内查看业务数据 - 配合处理违规预约与封禁事务 主要涉及数据： - 预约记录 - 审核结果 - 封禁记录 - 审计日志 ### 4.4.3 专业负责人（major_lead） 专业负责人是课程资源分享模块中的核心管理角色。 主要职责： - 负责所辖专业内课程资源的审核与管理 - 查看本专业课程资源统计与榜单 - 维护本专业范围内的资源质量 主要涉及数据： - 专业负责人映射 - 专业与课程 - 课程资源 - 下载事件 - 积分事件 ### 4.4.4 管理员（admin） 管理员负责平台级或模块级的综合管理。 主要职责： - 管理楼房、房间、专业、课程等基础业务数据 - 管理组织结构、角色、权限和用户状态 - 配置系统级规则 - 查询审计日志 主要涉及数据： - 用户与组织数据 - 角色权限数据 - 功能房基础数据 - 专业与课程基础数据 - 审计日志与配置数据 ### 4.4.5 超级管理员（super_admin） 超级管理员是系统中的最高权限角色。 主要职责： - 全局管理平台数据 - 维护角色权限体系 - 处理跨模块高权限操作 - 审核和追踪关键系统级管理行为 ### 4.4.6 图书管理员（librarian，可选扩展） 图书管理员是数字图书馆扩展模块中的运营角色。本轮仅作为扩展保留，不进入主线设计重点。 ## 4.5 角色与子系统对应关系 | 角色 | 平台基础 | 功能房预约 | 课程资源分享 | 数字图书馆 | |------|----------|------------|--------------|------------| | user | 登录、维护资料 | 查询、申请、取消、查看我的预约 | 浏览、投稿、查看我的资源 | 浏览、投稿 | | staff | 受权限控制 | 审核预约、处理违规 | 一般不作为主审核角色 | 一般不作为主审核角色 | | major_lead | 受权限控制 | 非主角色 | 审核并管理本专业资源 | 非主角色 | | admin | 综合管理 | 管理空间、封禁和配置 | 管理专业、课程、资源 | 综合管理 | | super_admin | 全局控制 | 全局管理 | 全局管理 | 全局管理 | ## 4.6 角色目标矩阵 | 角色 | 主要目标 | 对数据库设计的启示 | |------|----------|--------------------| | user | 完成预约与资源使用 | 需要清晰的主体标识、状态记录和个人数据归属 | | staff | 高效处理预约审核 | 需要明确预约状态、审核字段和审计记录 | | major_lead | 管理本专业资源 | 需要专业负责人映射与数据范围控制 | | admin | 管理基础数据与系统规则 | 需要组织、角色、权限、配置和审计模型 | | super_admin | 全局治理与追溯 | 需要全局权限与高可靠审计能力 | ## 4.7 典型业务场景 ### 4.7.1 场景一：学生预约功能房 场景描述： 普通用户为社团活动预约功能房，先查看房间空闲情况，再选择时间段、填写用途、添加参与人并提交预约申请。 涉及角色： - user - staff 或 admin（当系统开启审核时） 涉及数据： - 房间 - 预约记录 - 预约参与人 - 封禁记录 对数据库设计的启示： - 需要支持时间冲突判断 - 需要支持预约状态流转 - 需要支持申请人与参与人的联系建模 ### 4.7.2 场景二：工作人员审核预约 场景描述： 工作人员查看待审核预约，根据时间、用途和参与人信息对预约执行通过或驳回，并记录审核结果。 涉及角色： - staff - admin 涉及数据： - 预约记录 - 审核人、审核时间、审核意见 - 审计日志 对数据库设计的启示： - 状态字段与审核字段之间需要一致性约束 - 关键审核动作需要被追溯 ### 4.7.3 场景三：管理员维护楼房与房间 场景描述： 管理员维护楼房、楼层和房间基础信息，为预约业务提供可用资源基础。 涉及角色： - admin - super_admin 涉及数据： - 楼房 - 房间 - 房间启停状态 对数据库设计的启示： - 需要明确楼房与房间的从属关系 - 房间命名、容量、启停状态等字段应有合理约束 ### 4.7.4 场景四：学生投稿课程资源 场景描述： 普通用户为某课程整理资料后，在平台选择专业和课程，填写标题与描述，上传文件或填写外链，并提交审核。 涉及角色： - user - major_lead 或 admin 涉及数据： - 专业 - 课程 - 课程资源 - 审核结果 对数据库设计的启示： - 需要清晰建模专业、课程和资源的从属关系 - 需要支持文件型资源与外链型资源的区分与约束 ### 4.7.5 场景五：专业负责人审核课程资源 场景描述： 专业负责人进入后台，仅查看自己负责专业范围内的待审资源，并执行通过、驳回、下架或推荐等操作。 涉及角色： - major_lead - admin - super_admin 涉及数据： - 专业负责人映射 - 专业与课程 - 课程资源 - 下载事件与积分事件 - 审计日志 对数据库设计的启示： - 需要将角色权限和业务范围控制结合起来 - 需要支持事件型数据与主体数据分层建模 ### 4.7.6 场景六：管理员查看审计日志 场景描述： 管理员需要在后台查看某时间段内的关键管理行为，例如角色调整、资源审核、用户封禁等，用于责任追踪和问题排查。 涉及角色： - admin - super_admin 涉及数据： - 审计日志 - 操作人快照 - 操作对象 - 请求上下文 对数据库设计的启示： - 审计记录应具有追加性和可检索性 - 审计数据与当前业务状态应适当解耦，保留历史真实性 ## 4.8 角色分析结论 通过角色与场景分析可以得出以下结论： - 本课题是典型的多角色、多权限、多业务对象系统 - 平台基础子系统对其他业务模块具有前置支撑作用 - 功能房预约和课程资源分享都同时涉及普通用户和后台管理者 - 后续数据库设计必须重点考虑： - 用户与组织关系 - 用户与角色关系 - 数据范围与业务范围的结合 - 审核、统计、审计等管理需求