精选_毕业设计_基于Python Flask框架和Mysql实现的二手物品交易平台_完整源码

# 基于Python Flask框架和Mysql实现的二手物品交易平台 # 1、需求分析 ## 1.1 系统目标 二手物品发布平台是一个专为校内同学提供二手物品交易平台的系统。同学们可以首先注册账号，然后登录。登录之后可以在网站上浏览其他人或自己发布的二手物品及其相关信息，可以收藏自己喜欢的物品。用户也可以发布自己的二手物品。如果有感兴趣的物品，可以通过卖家留下的联系方式，线下通过第三方渠道进行支付、交易。 该系统的目标是建立一个学校自己的二手物品交易平台，为需要出售二手闲置物品和需要购置二手物品的同学提供平台。 ## 1.2 系统功能需求 该二手物品交易系统针对用户群体和系统管理员。 用户的功能需求如下图所示：  管理员的功能需求包括管理所有已发布的物品、管理所有用户发布的评论，如下图所示：  ## 1.3 系统的输入输出需求 系统的输入应满足最小量原则、简单性原则以及及早检验原则，即在满足处理要求的前提下应使输入量尽量小，系统能够计算出的数据不要由用户输入；输入过程应尽量简单；对输入数据的检验尽量接近原始数据发生点，使错误能及时得到改正。 系统的输出内容应简洁明了，使得用户一目了然；本系统中输出设备选择在屏幕上输出。 ## 1.4 系统的性能需求 系统的性能需求主要表现在数据库中的各个表需要频繁地被插入、删除以及更新。对于用户来说，系统地相应时间不宜太长，否则会降低用户体验，为此需要建立良好的表结构，加上足够的存储空间以及硬件性能。 # 2、可行性分析 ## 2.1 可行性研究前提 随着互联网时代的飞速发展，人们的购物需求也在不断地增长。许多人也因此会产生许多闲置不用的物品，如何处理这些闲置的物品就成为一个难题。实地去二手市场进行买卖不失为一种选择，但是不符合互联网时代的“便捷”。在高校之中，学生们去二手市场进行交易显然是不可行的。因此，设计这样一个二手物品交易发布平台就显得十分必要。 系统要求界面简洁直观，交互方便。能方便管理员管理用户们发布的二手物品交易和用户发表的评论，维护一个干净的平台。对于用户而言，浏览、搜索自己想要的二手物品是必要的功能(包括收藏自己喜爱的物品)。除此之外，用户也应该能够管理自己已经发布的二手物品，可以进行关闭交易、打开交易、撤销交易等操作。 ## 2.2 要求 ### 2.2.1 主要功能 - **用户账户管理**：用户可以在网站上自行注册及登录，离开时注销退出 - **二手物品查询**：用户以及管理员都可以在网站首页浏览所有用户发布的未关闭的二手物品，并且通过点击超链接进入查看详情 - **用户评论管理**：进入每一个已发布的未关闭的二手物品交易的详情页面之后，用户可以在下方发表评论。只有管理员可以管理删除这些评论 - **二手物品管理**：只有管理员可以管理所有人发布的二手物品交易，对于用户发布的不符合规范或者长期没有交易成功的物品撤销 - **二手物品发布**：所有非管理员用户均可发布二手物品，填写相应的资料和上传图片后即可发布 - **搜索功能**：可以根据物品名关键字进行搜索，搜索框中输入的字段必须完全包含在物品名称中 ### 2.2.2 安全性 具有一定的安全性。系统中只有两级权限级别，即普通用户和系统管理员。普通用户的权限仅限于发布物品、管理自己发布的物品、发布评论，系统管理员的权限更大，能够管理所有普通用户发布的物品和所有用户发布的评论。由于权限等级的划分，系统的安全性、稳定性得到了一定地满足。 ### 2.2.3 性能 可以方便快捷地完成二手物品查询，发布等各项操作。有一定的输入数据合法性检查功能，如用户发布物品时上传的物品只能属于规定的格式集合，用户注册时输入的邮箱地址的合法性。 ### 2.2.4 可扩展性 能够适应需求的变化，开发新的功能。数据库表结构清晰，不产生冗余。 # 3、数据库详细设计 ## 3.1 概念结构设计 本二手物品交易平台中一共有用户、管理员、物品、评论这三个基本的模型(实体)。一个用户可以发布多个物品，而一个物品只能对应于一个用户。一个用户可以发布多条评论，而一条评论只能对应于一个用户。一个物品交易下可以有多条评论，但一条评论只能对应于一个物品。ER图如下：  - **用户(非管理员)**：用户ID、用户名、用户密码、用户邮箱 - **物品**：物品ID、物品名称、物品价格、物品详细描述、物品图片 - **评论**：评论ID、评论内容、评论时间、评论所属物品、评论所属用户 - **感兴趣**：用户ID、物品ID 管理员的属性和用户的属性基本相同，但管理员拥有管理所有发布的物品和发布的评论的功能，且管理员不能发布物品和评论。管理员是唯一的。 ## 3.2 逻辑结构设计 将概念结构设计中的各个模型转化为DBMS支持的表结构，同时保持不会出现插入异常、删除异常和修改异常。表结构应该做到符合第三范式。在本系统中，一共有三个实体，实体转化为数据库模型为如下所示： - 实体转化为关系模式： - 用户(用户ID、用户名、用户密码、用户邮箱、用户权限) - 物品(物品ID、物品名称、物品价格、物品详细描述、物品图片) - 评论(评论ID、评论内容、评论时间、评论所属用户ID、评论所属物品ID) - 一个一对多联系转化为一个关系模式 - 用户-物品(用户ID,物品ID) - 用户-评论(用户ID,评论ID) - 物品-评论(物品ID，评论ID) - 兴趣(用户ID、物品ID) 利用以上关系模式得到的所有数据表如下所示： **用户表** | 列名 | 数据类型 | 数据长度 | 可否为空 | 备注 | | --------- | ------- | ---- | --------- | -------- | | Id | integer | 4 | Not null | 用户ID（主键） | | Username | varchar | 20 | Not null | 用户名 | | Password | varchar | 100 | Not null | 用户密码 | | Email | varchar | 30 | Not null | 用户邮箱 | | Authority | boolean | 1 | Not null | 用户权限 | **物品表** | 列名 | 数据类型 | 数据长度 | 可否为空 | 备注 | | ----------- | -------- | ---- | --------- | -------- | | Id | integer | 4 | Not null | 物品ID（主键） | | Name | varchar | 30 | Not null | 物品名 | | Description | text | 不定 | Null | 物品详细描述 | | Price | flaot | 4 | Not null | 物品价格 | | Imgpath | varchar | 300 | Null | 物品图片URL | | Create_time | datetime | 8 | Not null | 物品发布时间 | | Is_closed | integer | 4 | Not null | 交易是否被关闭 | | Ownerid | Integer | 4 | Not null | 所属用户ID | **评论表** | 列名 | 数据类型 | 数据长度 | 可否为空 | 备注 | | ----------- | -------- | ---- | --------- | -------- | | Id | integer | 4 | Not null | 评论ID（主键） | | Content | text | 不定