基于java的学习系统.rar

# GRE(美国研究生入学考试)学习系统 # 一、需求分析 ### 需求描述 经过分析与设计，我们的 GRE 学习系统的功能主要包括用户登陆与注册、用户做历次考试的试卷、自动评判与打分、试题评论浏览与添加、用户错题库管理、用户生词库管理等五个主要部分。详细需求如下： ① 用户登陆与注册： 管理用户注册账户的操作，并验证用户登录的信息。 ② 用户完成历次 GRE 考试的试卷： 用户可以从系统提供的历次 GRE 考试的试卷中下载所需试卷，并完成试卷中的试题。 ③ 自动评判与打分机制： 当用户完成试卷提交后，可以自动判断用户提交答案的正误，并给出用户完成试卷的总分数。 ④ 试题评论浏览与添加管理： 在用户完成试卷后，可以浏览试卷中每道题目下的评论区中其他用户对该题的评论，自己也可以添加或回复评论。 ⑤ 用户错题库管理： 生成用户专属的错题库，管理用户做错的题目，也支持用户将需要记录的题目添加到错题库中，方便用户日后复习回顾。 ⑥ 用户生词库管理： 管理用户需要记忆的生词，提供生词的拼写以及中文解释等信息，方便用户复习回顾。 ### 数据流图 从学习系统的使用用户的角度描述了该系统的顶层视图如下：  对系统进行细化，描述该系统的具体功能的数据流图如下：  ### 数据元素表 用户信息 | 数据名 | 数据类型 | 长度 | 能否为 NUL | 是否为 KEY | 备注 | | ---------- | -------- | ---- | ---------- | ---------- | ------------ | | USID | int | | 否 | 是 | 用户 ID | | USACCOUNT | char | 50 | 否 | 否 | 用户账户名 | | USPASSWORD | char | 20 | 否 | 否 | 用户登陆密码 | 试卷信息 | 数据名 | 数据类型 | 长度 | 能否为 NULL | 是否为 KEY | 备注 | | -------- | -------- | ---- | ----------- | ---------- | ------------- | | PAID | int | | 否 | 是 | 试卷 ID | | PATIME | char | 11 | 否 | 否 | 试卷时间 | | PAQUES1 | int | | 否 | 否 | 题目 1 的 ID | | PAQUES2 | int | | 否 | 否 | 题目 2 的 ID | | PAQUES3 | int | | 否 | 否 | 题目 3 的 ID | | PAQUES4 | int | | 否 | 否 | 题目 4 的 ID | | PAQUES5 | int | | 否 | 否 | 题目 5 的 ID | | PAQUES6 | int | | 否 | 否 | 题目 6 的 ID | | PAQUES7 | int | | 否 | 否 | 题目 7 的 ID | | PAQUES8 | int | | 否 | 否 | 题目 8 的 ID | | PAQUES9 | int | | 否 | 否 | 题目 9 的 ID | | PAQUES10 | int | | 否 | 否 | 题目 10 的 ID | 题目类型信息 | 数据名 | 数据类型 | 长度 | 能否为 NULL | 是否为 KEY | 备注 | | ------ | -------- | ---- | ----------- | ---------- | -------- | | QUESID | int | | 否 | 是 | 题目 ID | | TTYPE | char | 3 | 否 | 否 | 题目类型 | 单词信息 | 数据名 | 数据类型 | 长度 | 能否为 NULL | 是否为 KEY | 备注 | | ------ | -------- | ---- | ----------- | ---------- | -------- | | WOID | int | | 否 | 是 | 单词 ID | | WOENG | char | 20 | 否 | 是 | 单词英文 | | WOCHI | char | 20 | 否 | 否 | 单词中文 | 用户错题库信息 | 数据名 | 数据类型 | 长度 | 能否为 NULL | 是否为 KEY | 备注 | | ------ | -------- | ---- | ----------- | ---------- | ------- | | USID | int | | 否 | 是 | 用户 ID | | QUESID | int | | 否 | 是 | 错题 ID | 评论信息 | 数据名 | 数据类型 | 长度 | 能否为 NULL | 是否为 KEY | 备注 | | -------- | -------- | ---- | ----------- | ---------- | ----------- | | COID | int | | 否 | 是 | 评论 ID | | COTIME | varchar | 30 | 否 | 否 | 评论时间 | | COCON | varchar | 300 | 否 | 否 | 评论内容 | | CONICE | int | | 否 | 否 | 点赞数量 | | COQUESID | int | | 否 | 否 | 题目编号 | | COFROM | int | | 否 | 否 | 发送用户 ID | 用户生词库信息 | 数据名 | 数据类型 | 长度 | 能否为 NULL | 是否为 KEY | 备注 | | ------ | -------- | ---- | ----------- | ---------- | -------- | | USERID | char | 9 | 否 | 是 | 用户 ID | | UWENG | char | 20 | 否 | 是 | 单词英文 | | UWCHI | char | 20 | 否 | 否 | 单词中文 | | UWTIME | char | 11 | 否 | 否 | 记录时间 | 点赞记录信息 | 数据名 | 数据类型 | 长度 | 能否为 NULL | 是否为 KEY | 备注 | | -------- | -------- | ---- | ----------- | ---------- | ---------------------- | | NIUSERID | int | | 否 | 是 | 用户 ID | | NICOMID | int | | 否 | 是 | 评论 ID | | NITIME | varchar | 50 | 否 | 否 | 点赞时间（精确到分钟） | 做题痕迹信息 | 数据名 | 数据类型 | 长度 | 能否为 NULL | 是否为 KEY | 备注 | | ------ | -------- | ---- | ----------- | ---------- | ------------------ | | USID | int | | 否 | 是 | 用户 ID | | PAID | int | | 否 | 是 | 试卷 ID | | ANS1 | char | 4 | 能 | 否 | 用户试题 1 的答案 | | ANS2 | char | 4 | 能 | 否 | 用户试题 2 的答案 | | ANS3 | char | 4 | 能 | 否 | 用户试题 3 的答案 | | ANS4 | char | 4 | 能 | 否 | 用户试题 4 的答案 | | ANS5 | char | 4 | 能 | 否 | 用户试题 5 的答案 | | ANS6 | char | 4 | 能 | 否 | 用户试题 6 的答案 | | ANS7 | char | 4 | 能 | 否 | 用户试题 7 的答案 | | ANS8 | char | 4 | 能 | 否 | 用户试题 8 的答案 | | ANS9 | char | 4 | 能 | 否 | 用户试题 9 的答案 | | ANS10 | char | 4 | 能 | 否 | 用户试题 10 的答案 | # 二、数据库概念模式设计 下面给出本数据库系统设计的完整 E-R 图：  以下给出一些比较重要的 E-R 图分析，虽然本部分并不在文档要求内，但出于明确设计细节与易于交互理解的目的，我们还是决定给出由 E-R 图到关系模式中的一些关键拆分与合并步骤。 首先，我们需要解释对题目实体的设计。可以看到，我们将题目拆分为了三种题目，而这看似与数据库设计的原则相违背，因为不管有多少种题目，他们终究是题目，可以用属性将他们区分。但是事实上，这三种题目的题干长度有所不同，选项数量有�