# 07 数据需求分析 ## 7.1 分析目的 数据需求分析是需求分析与数据库设计之间的核心桥梁。其主要任务是： - 识别系统中的主要数据对象 - 明确数据对象之间的联系 - 梳理关键数据项及其业务含义 - 明确后续数据库设计必须满足的完整性要求 本章仍处于需求分析阶段，因此重点是“系统需要哪些数据、数据之间有什么关系、数据必须满足什么规则”，而不是直接展开最终 SQL 建表实现。 ## 7.2 数据分层思路 结合本课题业务特点，可以将系统数据大致分为四层： - 主体数据： - 如用户、部门、角色、楼房、房间、专业、课程、资源等 - 关系数据： - 如用户角色、用户部门、角色权限、专业负责人、预约参与人等 - 过程状态数据： - 如预约记录、课程资源状态、封禁记录等 - 事件与审计数据： - 如下载事件、积分事件、审计日志等 这种分层方式有利于后续按主体表、联系表、事实表、日志表进行关系模式设计，也便于说明规范化思路。 ## 7.3 平台基础子系统数据需求 ### 7.3.1 用户与身份数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 用户身份 | 用户编号 | 邮箱、认证状态 | 与用户资料一一对应 | 标识唯一、认证状态可追踪 | | 用户资料 | 用户编号 | 姓名、学号、用户名、头像、状态 | 依附用户身份 | 学号唯一、状态明确 | 对应数据需求： - `DR-PC-01` - 每个用户必须具有唯一身份标识 - `DR-PC-02` - 用户资料应与身份记录建立一一对应关系 - `DR-PC-03` - 学号、邮箱、用户名等识别性字段应具有唯一性约束需求 - `DR-PC-04` - 用户状态必须能够表达待验证、待审核、启用、停用、封禁等生命周期 ### 7.3.2 组织结构数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 部门 | 部门编号 | 部门名称、父部门、排序、状态 | 构成部门树 | 支持层级查询，禁止非法环 | | 岗位 | 岗位编号 | 岗位名称、编码、状态 | 与用户建立多对多关系 | 编码可唯一，状态可控 | | 用户-部门关系 | 复合标识 | 用户编号、部门编号 | 连接用户与部门 | 支持多部门归属 | | 用户-岗位关系 | 复合标识 | 用户编号、岗位编号 | 连接用户与岗位 | 支持多岗位归属 | 对应数据需求： - `DR-PC-05` - 部门之间应形成稳定树状层级关系 - `DR-PC-06` - 用户可归属一个或多个部门 - `DR-PC-07` - 用户可拥有一个或多个岗位 - `DR-PC-08` - 删除部门或岗位时应检查是否仍存在引用关系 ### 7.3.3 角色与权限数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 角色 | 角色编号 | 角色编码、名称、说明、状态 | 与用户、权限关联 | 角色编码唯一 | | 权限 | 权限编号 | 权限编码、名称、说明 | 与角色关联 | 权限编码唯一 | | 用户-角色关系 | 复合标识 | 用户编号、角色编号 | 连接用户与角色 | 支持多角色授权 | | 角色-权限关系 | 复合标识 | 角色编号、权限编号 | 连接角色与权限 | 支持多权限授权 | 对应数据需求： - `DR-PC-09` - 角色编码和权限编码应唯一 - `DR-PC-10` - 用户与角色之间应支持多对多关系 - `DR-PC-11` - 角色与权限之间应支持多对多关系 ### 7.3.4 数据范围数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 角色数据范围 | 角色与模块联合标识 | 角色编号、模块标识、范围类型 | 与角色绑定 | 每角色每模块范围定义清晰 | | 数据范围部门映射 | 复合标识 | 角色编号、模块标识、部门编号 | 与自定义范围关联 | 可表示自定义部门集合 | 对应数据需求： - `DR-PC-12` - 数据范围必须与角色、模块建立稳定联系 - `DR-PC-13` - 自定义部门范围应支持映射到多个部门 - `DR-PC-14` - 数据范围模型应能与组织层级查询结合 ### 7.3.5 审计与配置数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 审计日志 | 日志编号 | 操作者、动作、对象、结果、差异、时间、上下文 | 与管理行为关联 | 追加记录、可检索 | | 配置项 | 配置键 | 配置键、配置值、更新时间、更新人 | 被业务读取 | 值可维护、变更可追踪 | 对应数据需求： - `DR-PC-15` - 审计日志应保留关键管理操作历史 - `DR-PC-16` - 审计日志应避免被普通业务流程修改或删除 - `DR-PC-17` - 系统配置应支持在线读取和更新 ## 7.4 功能房预约子系统数据需求 ### 7.4.1 空间基础数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 楼房 | 楼房编号 | 名称、排序、状态、备注 | 与房间一对多 | 名称可识别、状态可控 | | 房间 | 房间编号 | 楼房编号、楼层、房间名称、容量、状态 | 隶属于楼房 | 容量合理、归属明确 | 对应数据需求： - `DR-FA-01` - 房间必须隶属于某一楼房 - `DR-FA-02` - 房间在同一楼房与楼层范围内应具备区分性 - `DR-FA-03` - 房间容量应满足合理取值范围 ### 7.4.2 预约过程数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 预约记录 | 预约编号 | 房间、申请人、开始时间、结束时间、用途、状态、审核字段、取消字段 | 与房间、用户关联 | 表达完整生命周期 | | 预约参与人 | 复合标识 | 预约编号、用户编号、是否申请人 | 与预约一对多 | 支持多参与人、去重 | | 封禁记录 | 封禁编号 | 用户编号、原因、生效时间、到期时间、撤销信息 | 与用户关联 | 能表达生效、到期与撤销 | 对应数据需求： - `DR-FA-04` - 每条预约必须对应一个房间和一个申请人 - `DR-FA-05` - 每条预约可以包含多个参与人 - `DR-FA-06` - 同一房间在有效预约状态下不应出现冲突时间段 - `DR-FA-07` - 预约结束时间必须晚于开始时间 - `DR-FA-08` - 预约状态必须能够表达待审、通过、驳回、取消等生命周期 - `DR-FA-09` - 封禁记录应能表达是否在当前时刻生效 ### 7.4.3 统计数据要求 - `DR-FA-10` - 预约记录应保留完整时间信息，便于按天、周、月统计 - `DR-FA-11` - 统计应能按房间、用户和时间窗口进行聚合 ## 7.5 课程资源分享子系统数据需求 ### 7.5.1 教学层级数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 专业 | 专业编号 | 名称、状态、排序、备注 | 与课程一对多 | 名称规范、状态可控 | | 课程 | 课程编号 | 专业编号、课程名称、课程代码、状态 | 隶属于专业 | 课程归属清晰 | | 专业负责人关系 | 复合标识 | 专业编号、用户编号 | 连接专业与负责人 | 支持多对多 | 对应数据需求： - `DR-CR-01` - 每门课程必须归属于一个专业 - `DR-CR-02` - 一个专业可以拥有多个负责人 - `DR-CR-03` - 一个用户可以负责多个专业 ### 7.5.2 资源主体数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 课程资源 | 资源编号 | 课程、标题、描述、资源类型、状态、审核字段、发布时间、创建人 | 与课程和用户关联 | 支持完整生命周期和内容约束 | 资源内容可分为两类： - 文件型资源： - 文件名、文件键、文件大小、哈希值等 - 外链型资源： - 原始 URL、规范化 URL 对应数据需求： - `DR-CR-04` - 资源必须关联课程 - `DR-CR-05` - 资源必须具备明确资源类型 - `DR-CR-06` - 文件型字段与外链型字段应互斥 - `DR-CR-07` - 审核流需记录状态、审核人、审核时间和审核意见 - `DR-CR-08` - 已发布资源应保留发布时间 ### 7.5.3 事件与统计数据 | 数据对象 | 标识方式 | 主要数据项 | 关键联系 | 关键要求 | |----------|----------|------------|----------|----------| | 下载事件 | 事件编号 | 资源编号、用户编号、发生时间、上下文 | 与资源关联 | 可追踪下载事实 | | 最佳推荐 | 推荐记录 | 资源编号、推荐人、推荐时间 | 与资源关联 | 表达推荐事实 | | 积分事件 | 事件编号 | 用户编号、资源编号、事件类型、分值、发生时间 | 与用户和资源关联 | 支持幂等和排行 | 对应数据需求： - `DR-CR-09` - 下载行为应与资源主体分离建模 - `DR-CR-10` - 同一资源的推荐行为应受规则控制 - `DR-CR-11` - 积分事件应避免重复发放 ## 7.6 数据联系分析 ### 7.6.1 平台基础联系 - 用户身份与用户资料： - 一对一 - 用户与部门： - 多对多 - 用户与岗位： - 多对多 - 用户与角色： - 多对多 - 角色与权限： - 多对多 - 角色与数据范围： - 一对多 ### 7.6.2 功能房预约联系 - 楼房与房间： - 一对多 - 房间与预约： - 一对多 - 预约与参与人： - 一对多 - 用户与预约申请： - 一对多 - 用户与封禁记录： - 一对多 ### 7.6.3 课程资源分享联系 - 专业与课程： - 一对多 - 专业与专业负责人： - 多对多 - 课程与资源： - 一对多 - 资源与下载事件： - 一对多 - 资源与最佳推荐： - 一对零或一 - 资源与积分事件： - 一对多 ## 7.7 数据完整性需求 ### 7.7.1 实体完整性需求 - 所有核心对象必须具有唯一标识 - 关键标识字段不得为空 - 关系表应具有明确主键或复合主键 ### 7.7.2 参照完整性需求 - 房间必须依附于楼房 - 预约必须依附于房间和申请用户 - 课程必须依附于专业 - 资源必须依附于课程 - 用户角色、角色权限、专业负责人等联系必须建立在真实主体之上 ### 7.7.3 用户定义完整性需求 - 学号、角色编码、权限编码等字段应具有唯一性需求 - 容量、时长、分值等数值字段应具备合法范围 - 预约结束时间必须晚于开始时间 - 文件型资源与外链型资源字段组合必须符合业务规则 - 状态字段与审核、取消、发布时间等辅助字段应保持一致 ## 7.8 规范化导向要求 从需求分析阶段即可提出如下规范化目标： - 一个数据对象只表达一种主要事实，避免在主体表中混入过多无关事实 - 多对多关系应拆分为独立关系表 - 统计与审计数据应尽量独立于主体数据建模 - 如需为性能保留冗余，应在后续设计中说明理由及一致性保障机制 这意味着本课题在后续关系模式设计中应尽量满足 3NF，要能够解释： - 哪些是正常主体字段 - 哪些是必要冗余 - 哪些是事件快照或审计快照 ## 7.9 数据生命周期与保留要求 - 审计日志： - 原则上保留历史，不应随普通业务删除 - 下载事件、积分事件： - 作为统计事实，应保留关键历史 - 预约记录： - 应保留以支持历史查询和统计分析 - 课程资源： - 即使下架，也应保留其业务历史状态 ## 7.10 数据需求分析结论 本课题的数据需求具有以下明显特征： - 主体对象较多，关系复杂 - 多对多关系普遍存在 - 存在层级结构、状态结构和事件结构 - 对完整性、一致性和统计能力要求较高 因此，本课题非常适合采用关系数据库进行规范化建模，并在后续设计阶段重点讨论： - E-R 图与关系模式转换 - 主键、外键与候选键设计 - 检查约束与触发器设计 - 事件事实表与统计查询设计