103
社区成员
发帖
与我相关
我的任务
分享哈基米——项目系统设计与数据库设计
文件链接
GitCode团队仓库链接
哈基米队_系统设计说明书
哈基米队_数据库设计说明书
哈基米队_系统设计和数据库设计答辩PPT
系统和数据库设计
1. 定义与缩写
| 缩写 | 全称 | 说明 |
|---|---|---|
| SHP | 校园二手交易平台 | 本文档所描述的核心项目 |
| UI | 用户界面 | 系统与用户交互的可视化界面 |
| MVC | 模型 - 视图 - 控制器 | 一种软件架构模式，用于分离业务逻辑、数据展示和用户交互 |
| B/S | 浏览器 - 服务器 | 系统架构模式，用户通过浏览器访问服务器端资源 |
| API | 应用程序编程接口 | 系统内部模块间或与外部系统交互的接口 |
| ER | 实体 - 关系 | 数据库概念结构设计中用于描述实体、属性及实体间关系的模型 |
2. 系统体系结构设计
2.1 总体架构
SHP 系统采用分层架构设计，自下而上分为 Pojo 层、Dao 层、Service 层、Controller 层和 View 层，各层职责边界清晰、低耦合高内聚，保障系统可扩展性与维护性，具体架构流程如下：
Pojo 层：编写与数据库表结构属性完全一致的实体类（含 User、Admin、IdleItem 等核心实体），定义实体的属性与基础方法（如 get/set 方法、信息获取方法），作为数据传输的基础载体；
Dao 层：基于 MyBatis 框架，编写数据访问接口与 XML 配置文件，封装数据库增删改查操作，支持管理员表（sh_admin）、订单地址关联表（sh_order_address）等特殊表的数据访问；
Service 层：编写 Service 接口及实现类，调用 Dao 层接口处理核心业务逻辑（如用户注册校验、商品审核、订单创建），实现业务规则与数据访问的解耦；
Controller 层：接收前端用户请求，进行数据验证与参数处理后调用 Service 层接口，完成业务逻辑执行并将结果反馈至 View 层，实现页面与业务的逻辑衔接；
View 层：通过 JSP 实现前端界面渲染，支持用户交互操作（如商品浏览、订单提交），并完成页面数据的收集与提交。
2.2 功能模块层次图
系统功能模块层次图清晰展示各层模块的从属关系与交互逻辑，如下所示：
3. 数据库设计
3.1 概念结构设计（ER 分析）
3.1.1 核心实体定义
平台数据库核心实体涵盖业务全流程关键对象，具体包括：
用户（User）：校园内使用平台的学生 / 教职工，是商品发布、订单创建、消息交互的主体；
管理员（Admin）：负责平台管理的角色，承担商品审核、用户管理、订单纠纷处理等职责；
闲置物品（IdleItem）：用户发布的二手商品，是交易流程的核心对象；
订单（Order）：记录用户购买商品的交易信息，关联买家、商品与收货地址；
收货地址（Address）：存储用户收货信息，为订单履约提供地址支持；
收藏（Favorite）：记录用户关注的商品，便于用户后续查看与购买；
消息（Message）：实现买卖双方沟通，支持商品咨询、订单协商等交互场景。
3.1.2 实体属性与关系
各核心实体的关键属性及实体间关联关系如下表所示：
| 实体 | 核心属性 | 与其他实体的关系 |
|---|---|---|
| User | id（用户 ID，主键）、account_number（手机号，唯一）、user_password（加密密码）、nickname（昵称）、user_status（账号状态） | 1 对多：1 个用户可拥有多个 Address/IdleItem/Order/Favorite/Message（发送） |
| Admin | id（管理员 ID，主键）、account_number（管理员账号，唯一）、admin_password（加密密码）、admin_name（姓名） | 无直接关联，通过业务逻辑关联 IdleItem（审核）、User（状态管理） |
| IdleItem | id（物品 ID，主键）、idle_name（名称）、idle_details（详情）、idle_price（价格）、idle_status（状态）、user_id（发布者 ID，外键） | 1 对多：1 个物品可关联多个 Order/Message；多对 1：多个物品归属 1 个 User |
| Order | id（订单 ID，主键）、order_number（订单编号，唯一）、user_id（买家 ID，外键）、idle_id（商品 ID，外键）、order_price（总价）、order_status（状态） | 1 对 1：1 个订单关联 1 个 Address（通过 sh_order_address 表）；多对 1：多个订单归属 1 个 User/IdleItem |
| Address | id（地址 ID，主键）、consignee_name（收货人）、consignee_phone（手机号）、detail_address（详细地址）、user_id（所属用户 ID，外键） | 多对 1：多个地址归属 1 个 User；1 对 1：1 个地址仅关联 1 个 Order |
| Favorite | id（收藏 ID，主键）、user_id（用户 ID，外键）、idle_id（物品 ID，外键）、create_time（收藏时间） | 多对 1：多个收藏归属 1 个 User/IdleItem；1 对 1：1 个 User 对 1 个 IdleItem 仅 1 条收藏记录（唯一约束） |
| Message | id（消息 ID，主键）、user_id（发送者 ID，外键）、to_user（接收者 ID，外键）、idle_id（关联商品 ID，外键）、content（内容） | 多对 1：多个消息归属 1 个 User（发送 / 接收）/IdleItem；1 对 1：1 条消息可回复 1 条其他消息（to_message） |
3.1.3 系统 ER 图
系统 ER 图直观展示核心实体、属性及实体间的关联关系，如下所示：
3.2 逻辑结构设计（表结构设计）
3.2.1 表结构总览
平台数据库共设计 8 张核心表，覆盖用户管理、商品管理、订单管理、交互沟通等全业务场景，具体表清单如下：
sh_user（用户表）：存储用户基础信息与账号状态；
sh_admin（管理员表）：存储管理员账号与权限关联信息；
sh_idle_item（闲置物品表）：存储二手商品的详情、价格、状态等信息；
sh_order（订单表）：存储订单交易信息，包括订单编号、金额、状态等；
sh_order_address（订单地址关联表）：关联订单与收货地址，实现 1 对 1 映射；
sh_address（收货地址表）：存储用户的收货地址信息；
sh_favorite（收藏表）：存储用户的商品收藏记录；
sh_message（消息表）：存储用户间的沟通消息内容与状态。
3.2.2 核心表详细结构
此处列出关键业务表的详细结构，包含字段名、数据类型、约束及描述：
3.2.2.1. sh_user（用户表）
| 字段名 | 数据类型 | 约束 | 描述 |
|---|---|---|---|
| id | bigint (20) | 主键、自增 | 用户唯一标识（对应学号 / 工号） |
| account_number | varchar (20) | 非空、唯一 | 用户手机号，用于登录与身份验证 |
| user_password | varchar (64) | 非空 | 加密后的密码（采用 BCrypt 算法 |
| nickname | varchar (20) | 非空 | 用户昵称，前端展示用 |
| avatar | varchar (255) | 允许空 | 用户头像图片链接 |
| sign_in_time | datetime | 非空 | 用户注册时间 |
| user_status | tinyint (1) | 非空、默认 1 | 账号状态（0 - 锁定，1 - 正常） |
3.2.2.2. sh_idle_item（闲置物品表）
| 字段名 | 数据类型 | 约束 | 描述 |
|---|---|---|---|
| id | int (11) | 主键、自增 | 商品唯一标识 |
| idle_name | varchar (50) | 非空 | 商品名称 |
| idle_details | varchar (255) | 非空 | 商品详细描述 |
| picture_list | varchar (1000) | 允许空 | 商品图片链接列表（用逗号分隔） |
| idle_price | decimal (10,2) | 非空 | 商品价格（保留 2 位小数） |
| idle_place | varchar (50) | 非空 | 发货地区（如 “福州大学旗山校区”） |
| idle_label | varchar (20) | 非空 | 商品分类标签（如 “书籍”“电子产品”） |
| release_time | datetime | 非空 | 商品发布时间 |
| idle_status | tinyint (1) | 非空、默认 0 | 商品状态（0 - 待审核，1 - 在售，2 - 已售，3 - 已下架） |
| user_id | bigint (20) | 非空、外键（关联 sh_user.id） | 商品发布者 ID |
3.2.2.3 sh_order（订单表）
| 字段名 | 数据类型 | 约束 | 描述 |
|---|---|---|---|
| id | int (11) | 主键、自增 | 订单唯一标识 |
| order_number | varchar (50) | 非空、唯一 | 订单编号（格式：YYYYMMDD + 随机 8 位） |
| user_id | bigint (20) | 非空、外键（关联 sh_user.id） | 买家 ID |
| idle_id | int (11) | 非空、外键（关联 sh_idle_item.id） | 关联商品 ID |
| order_price | decimal (10,2) | 非空 | 订单总金额 |
| payment_status | tinyint (1) | 非空、默认 0 | 支付状态（0 - 待支付，1 - 已支付，2 - 支付失败） |
| payment_way | varchar (20) | 允许空 | 支付方式（仅支持 “微信支付”） |
| create_time | datetime | 非空 | 订单创建时间 |
| order_status | tinyint (1) | 非空、默认 0 | 订单状态（0 - 待付款，1 - 待收货，2 - 已完成，3 - 已取消，4 - 纠纷中） |
| is_deleted | tinyint (1) | 非空、默认 0 | 是否删除（0 - 未删，1 - 已删） |
3.2.3 索引与约束设计
为提升查询效率与保障数据完整性，针对核心表设计索引与约束如下：
3.2.3.1 索引设计
| 表名 | 索引字段 | 索引类型 | 作用 |
|---|---|---|---|
| sh_user | account_number | 唯一索引 | 加速用户登录时的账号查询，避免重复注册 |
| sh_user | id | 主键索引 | 加速用户 ID 关联查询（如订单关联用户信息） |
| sh_idle_item | user_id | 普通索引 | 快速查询某用户发布的所有商品 |
| sh_idle_item | idle_status + release_time | 复合索引 | 加速 “按发布时间排序查询在售商品” 的高频操作 |
| sh_order | user_id | 普通索引 | 快速查询某用户的所有订单 |
| sh_favorite | user_id + idle_id | 唯一复合索引 | 防止用户重复收藏同一商品，加速收藏记录查询 |
3.2.3.2 约束设计
主键约束：所有表以 id 字段作为主键，且设为自增（AUTO_INCREMENT），确保记录唯一标识；
外键约束：核心关联字段设置外键（如 sh_order.user_id 关联 sh_user.id），确保数据引用有效性，避免脏数据；
非空约束：关键业务字段（如 sh_user.account_number、sh_order.order_price）设为非空，防止核心数据缺失；
唯一约束：sh_user.account_number、sh_admin.account_number 等账号类字段设为唯一，避免重复账号。
类图、系统安全和权限设计
1. 核心设计类图
1.1 核心类定义
系统核心类涵盖业务实体类与服务类，各核心类的属性与方法如下：
1.1.1 用户相关类
User（用户实体类）：对应 sh_user 表，封装用户基础信息与操作方法；
属性：userId（String，主键）、accountNumber（String，手机号）、password（String，加密密码）、nickname（String，昵称）、userStatus（int，账号状态）、creditScore（Double，信用分）、registerTime（Date，注册时间）；
方法：getUserInfo ()（获取用户信息）、updatePassword (String newPassword)（修改密码）、updateUserStatus (int status)（更新账号状态）。
Admin（管理员实体类）：对应 sh_admin 表，封装管理员信息；
属性：id（int，主键）、accountNumber（String，管理员账号）、adminPassword（String，加密密码）、adminName（String，姓名）；
方法：getAdminInfo ()（获取管理员信息）、updateAdminPassword (String newPassword)（修改密码）。
UserService（用户服务类）：封装用户相关业务逻辑；
方法：register (User user, String code)（用户注册，校验手机号唯一性）、login (String loginId, String password)（支持学号 / 手机号登录）、authenticate (String userId, String campusCardInfo)（校园身份认证）、updateUserStatus (String userId, int status)（修改用户账号状态）。
1.1.2 商品与订单相关类
IdleItem（商品实体类）：对应 sh_idle_item 表，封装商品信息；
属性：id（int，主键）、title（String，商品标题）、description（String，详情）、price（Double，价格）、status（String，状态）、idleLabel（String，分类标签）、userId（String，发布者 ID）、releaseTime（Date，发布时间）；
方法：updateInfo (String title, String description)（更新商品信息）、changeStatus (String status)（修改商品状态）。
Order（订单实体类）：对应 sh_order 表，封装订单信息；
属性：id（int，主键）、orderNumber（String，订单编号）、idleId（int，商品 ID）、buyerId（String，买家 ID）、price（Double，金额）、status（String，状态）、isDeleted（int，是否删除）、createTime（Date，创建时间）；
方法：updateStatus (String status)（更新订单状态）、markAsDeleted ()（标记订单为删除）。
OrderService（订单服务类）：封装订单相关业务逻辑；
方法：create (Order order, int addressId)（创建订单，同步关联地址）、pay (Payment payment)（处理支付）、confirmReceipt (int orderId)（确认收货）、cancel (int orderId, String userId)（取消订单）。
1.1.3 消息相关类
Message（消息实体类）：对应 sh_message 表，封装消息信息；
属性：id（int，主键）、content（String，消息内容）、senderId（String，发送者 ID）、receiverId（String，接收者 ID）、sendTime（Date，发送时间）、readStatus（int，阅读状态）、idleId（int，关联商品 ID）；
方法：markAsRead ()（标记消息为已读）。
MessageService（消息服务类）：封装消息相关业务逻辑；
方法：send (Message message)（发送消息）、getMessagesByIdleId (int idleId)（查询商品关联消息）、markRead (int messageId)（标记消息已读）。
1.2 核心类图
核心类图展示各核心类之间的关联关系（如继承、关联、依赖），如下所示：
2. 系统安全设计
系统从数据安全、接口安全、应用安全三个维度构建安全防护体系，保障平台稳定运行与用户数据安全：
2.1 数据安全
2.1.1 敏感数据加密
密码加密：用户密码（sh_user.user_password）采用 BCrypt 算法加密存储，管理员密码（sh_admin.admin_password）采用 MD5 + 盐值加密，数据库不存储明文；
敏感信息加密：用户手机号（sh_user.account_number）、收货地址（sh_address.detail_address）采用 AES 对称加密存储，密钥通过配置文件管理，每季度更换一次；
2.1.2 数据库安全
访问控制：仅允许应用服务器 IP（如 192.168.1.100）连接数据库，禁止公网直接访问；
备份策略：每日凌晨 3 点执行全量备份，备份文件存储至异地服务器（如 192.168.1.200），保留 30 天备份记录，支持数据恢复；
2.1.3 传输安全
所有 HTTP 请求采用 HTTPS 协议传输，基于 SSL/TLS 1.2 加密数据，防止传输过程中数据被窃取或篡改。
2.2 接口安全
2.2.1 接口鉴权
用户登录后生成 JWT 令牌（含 userId、role 信息），有效期 2 小时；管理员登录生成独立 JWT 令牌（含 adminId），有效期 1 小时；
后续请求需在请求头携带令牌，服务器验证令牌有效性后才处理请求，未携带或无效令牌返回 401 未授权；
2.2.2 防重复提交
订单创建、支付等关键接口采用 “请求唯一标识” 机制（生成 UUID 作为 requestId），服务器存储标识并设置 10 分钟有效期，同一 requestId 重复请求直接拒绝；
2.2.3 接口限流
基于 Redis 实现限流，普通用户每分钟最多发起 30 次请求，管理员每分钟最多发起 50 次请求，单个 IP 每分钟最多发起 100 次请求，超出阈值返回 429 请求过多。
2.3 应用安全
2.3.1 XSS 防护
对用户输入的商品描述（sh_idle_item.idle_details）、消息内容（sh_message.content）进行 HTML 转义，过滤script等恶意标签；前端采用 Vue 框架的 v-text 指令渲染文本，避免直接插入 HTML；
2.3.2 CSRF 防护
开启 Spring Security 的 CSRF 防护功能，生成 CSRF 令牌并嵌入登录、订单提交等表单，请求时携带令牌验证，防止跨站请求伪造；
2.3.3 SQL 注入防护
采用 MyBatis 的参数绑定（#{}）方式，避免直接拼接 SQL 语句；后端过滤用户输入中的 SQL 关键字（如 OR、AND、DROP），防止注入攻击；
2.3.4 文件上传安全
限制商品图片、头像上传格式（仅允许 JPG、PNG、WebP），验证文件后缀与文件头一致性；单个文件大小≤5MB，上传文件存储在独立文件服务器，不与应用服务器同机，避免恶意文件执行。
3. 权限设计
系统采用基于角色的访问控制（RBAC）模型，通过定义角色与权限映射，实现精细化权限管理，确保用户仅能访问权限范围内的功能。
3.1 角色定义
系统分为两类核心角色，覆盖所有用户类型：
普通用户（USER）：校园内注册并完成身份认证的学生 / 教职工，对应 sh_user 表中 user_status=1 的用户，拥有平台基础使用权限；
管理员（ADMIN）：由学校相关部门指定的平台管理者，对应 sh_admin 表中的用户，负责平台运营与管理，拥有高级操作权限。
3.2 权限分配
两类角色的具体权限分配如下表所示，明确各角色可操作的功能与数据范围：
| 权限类别 | 普通用户（USER）权限 | 管理员（ADMIN）权限 |
|---|---|---|
| 用户管理 | 1. 查看 / 修改个人信息（含手机号）; 2. 修改个人密码；3. 提交校园身份认证申请；4. 查看个人信用分 | 1. 查看 sh_user 表所有用户信息；2. 修改用户账号状态（0 - 锁定 / 1 - 正常）；3. 重置普通用户密码；4. 审核用户身份认证申请 |
| 商品管理 | 1. 发布商品（提交审核）；2. 编辑 / 下架自有商品；3. 收藏商品；4. 搜索 / 筛选商品 | 1. 审核待审核商品（通过 / 驳回并填写理由）；2. 下架违规商品；3. 编辑 / 删除违规商品；4. 查看平台所有商品数据 |
| 订单管理 | 1. 创建订单（关联收货地址）；2. 支付订单；3. 确认收货 / 取消订单；4. 申请订单纠纷；5. 查看个人订单及关联地址 | 1. 查看 sh_order 表所有订单；2. 通过 sh_order_address 表关联查看订单地址；3. 处理订单纠纷（更新解决方案）；4. 导出订单数据；5. 仅纠纷处理时修改订单状态 |
| 消息管理 | 1. 发送 / 接收消息；2. 查看个人消息历史；3. 标记消息已读 | 1. 仅纠纷处理时查看相关用户消息记录；2. 无额外消息发送权限 |
| 数据统计 | 无权限 | 1. 查看平台总用户数、月活跃用户数、月订单量；2. 导出统计 Excel 报表（含用户、订单、商品数据） |
3.3 权限控制实现
权限控制在前后端协同实现，确保权限规则落地：
3.3.1 后端权限控制
基于 Spring Security 框架，通过@PreAuthorize注解在接口方法上指定访问角色；
示例：@PreAuthorize("hasRole('USER')") 标注商品发布接口，仅普通用户可访问；@PreAuthorize("hasRole('ADMIN')") 标注用户状态修改接口，仅管理员可访问；无权限用户访问时返回 403 权限不足
3.3.2 前端权限控制
前端根据用户角色动态渲染界面元素；
普通用户登录后，不显示 “商品审核”“用户管理” 等管理员专属菜单；
管理员专属按钮（如 “审核商品”“锁定用户”）仅在管理员登录时显示，普通用户无法通过前端调试触发；
3.3.3 数据权限控制
普通用户查询订单时，仅返回sh_order.buyerId=当前用户ID的订单；管理员查询用户数据时，无法修改 sh_admin 表的管理员信息（需超级管理员权限，当前暂未实现超级管理员角色）。
改进分析
1. 上次需求分析评审问题响应
在上次需求分析作业的评审中，老师、助教提出 核心设计不够新颖问题，核心痛点在于平台缺乏自动化的咨询处理机制，导致用户问题无法及时解决，影响用户体验。
2. 改进部分与改进过程
针对上述问题，团队计划引入AI 客服功能，通过自动化工具辅助处理用户常见咨询（如订单查询、商品发布规则、支付问题等），提升响应效率并减轻人工客服压力。目前改进处于规划阶段，具体改进过程与细节如下：
2.1 改进方向确定
通过需求评审反馈整理，明确 AI 客服需覆盖的核心场景：
基础咨询：解答平台使用规则（如注册流程、商品审核标准）；
业务查询：协助用户查询个人订单状态、收藏商品、消息记录；
问题引导：当 AI 无法解答时，引导用户转接人工客服，并自动同步问题上下文。
2.2 实现形式规划（暂未确定）
当前团队正在评估两种 AI 客服实现形式，尚未最终确定：
1.规则引擎 + 基础 NLP：基于预设规则匹配用户问题（如关键词 “订单查询” 触发订单查询流程），结合简单自然语言处理优化交互体验，开发成本低、部署快，但仅能处理固定场景；
2.对接第三方 AI 接口：调用成熟的第三方 AI 服务（如百度智能云、阿里云 AI），利用其较强的语义理解能力处理复杂咨询，支持多轮对话，但存在接口调用成本，且需适配第三方服务的交互逻辑。
2.3 后续推进计划
需求细化：本周内完成 AI 客服的详细需求文档，明确功能边界与交互流程；
技术选型：下周完成实现形式评估，确定技术方案（自研规则引擎或对接第三方接口）；
原型设计：根据技术方案设计 AI 客服的前端交互原型，确保用户体验流畅；
开发测试：后续迭代中完成 AI 客服功能开发，并通过用户测试验证效果。
团队绩效
| 学号 | 分工内容 | 贡献度 |
|---|---|---|
| 102300416 | 博客 | 11.1% |
| 102300417 | 博客 | 11.1% |
| 102300418 | ppt撰写 | 11.1% |
| 102300419 | 审评表、辅助ppt撰写 | 11.1% |
| 102300420 | 系统设计，文档撰写 | 11.1% |
| 102300421 | 数据库设计，文档撰写 | 11.1% |
| 102300422 | 系统设计，文档撰写 | 11.1% |
| 102300423 | 数据库设计，文档撰写 | 11.1% |
| 102300429 | 系统设计，GitCode仓库整理 | 11.1% |
...全文
请发表友善的回复…
发表回复
