教务管理系统是与高校学生的学习活动联系最紧密的信息系统之一,也是教师开展教学活动,以及教务员进行管理工作所必不可少的信息系统。教务管理系统包括个人信息查询、选课系统、历史修读课程及成绩、修读计划完成情况、查询实时绩点等服务。 其中选课系统是高校进行学生信息管理的一项重要功能,不仅方便了学生自主查询课程相关信息,并允许学生自主进行选课、退课,同时也方便了教师管理其所开设的课程。本小组以本科选课系统为出发点,并在此基础上分析其他的业务需求和业务流程,建立起教务系统的数据库,实现教务系统中的具体服务,如上文所提到修读计划完成情况等。
本科生的选课系统(xk.fudan.edu.cn)中基本上仅包含“选课”和“退课”两项实质性操作,一旦过了选课开放时间,同学们如果需要进行开课查询或者课表查询就需要进入另外的系统。建立教务管理系统的目的是把同学们经常使用的、与教务管理相关的服务集中到一起,比如选课系统、课表查询、成绩查询、修读计划完成情况等。通过合理设计数据库减少数据的冗余性,为学生、教师、教务员三种用户管理和查询自己的教务信息提供便利。
主要用户:
- 本科生
- 教师
- 教务员
主要功能:
- 个人信息查询
- 本科生选课系统
- 历史修读课程
- 修读计划完成情况
- 实时绩点查询
- 教学活动安排
- 课程学生名单
- 课程成绩单
- 增改选课名单
- 课程教材查询
正如上文中提到的,教务系统是为了方便师生使用而存在的,因此该需求切实存在并可行。需求分析的获取来源于身为学生的自身经历、对教师和教务员的采访使用心得,了解不同的用户对于教务系统功能的评价和期待,这决定了我们最终将哪些功能整合到教务管理系统中去。
学生:个人信息查询和修改、选课系统、查看历史选课记录、查询历史成绩、查询实时绩点、查看课表、查看修读计划完成情况、查看课程教材
教师:个人信息查询和修改、查看教学活动安排、选课名单、输入成绩、修改课程教材
教务员:增改选课名单
第一层数据流图
第二层数据流图
选课模块
成绩模块
修读课程模块
排课模块
个人信息模块
编号 | 数据项名 | 含义说明 | 数据类型 | 长度 | 限制 | 数据项关系 |
---|---|---|---|---|---|---|
1 | 学号 | Char | 11 | 非空,唯一 | ||
2 | 姓名 | Char | 10 | 非空 | ||
3 | 密码 | Char | 10 | 非空 | ||
4 | 性别 | Char | 2 | 限定 男or女 | ||
5 | 出生年月 | Date | 非空 | |||
6 | 年级 | 以四位级数表示 | Interger | |||
7 | 联系方式 | 手机/固定电话 | Char | 11 | 非空 | |
8 | 专业名称 | Char | 20 | |||
9 | 专业编号 | Char | 4 | 非空,唯一 | ||
10 | 课程编号 | Char | 10 | 非空,唯一 | ||
11 | 课程名称 | Char | 20 | 非空 | ||
12 | 课程属性 | Char | 10 | 非空 | ||
13 | 学分要求 | Real | ||||
14 | 学分 | Real | 非空 | |||
15 | 人数限制 | Integer | 非空 | |||
16 | 实际人数 | Integer | 非空 | |||
17 | 学期 | Char | 6 | 非空 | ||
18 | 上课时间 | Char | 20 | |||
19 | 上课地点 | Char | 20 | |||
20 | 工号 | Char | 11 | 非空,唯一 | ||
21 | 职称 | Char | 10 | |||
22 | 成绩 | 等级制 | Char | 2 | ||
23 | GPA | Real | ||||
24 | 教材名称 | Char | 50 | 非空 | ||
25 | 作者 | Char | 20 | 非空 | ||
26 | 出版社 | Char | 20 | 非空 | ||
27 | 价格 | Real | 非空 | |||
28 | ISBN编码 | Char | 20 | 非空 |
编号 | 数据结构名 | 含义说明 | 组成(属性名) |
---|---|---|---|
1 | 个人信息 | 记录个人信息,分为学生个人信息和教师个人信息两张表 | 学号/工号、姓名、性别、出生年月、年级、联系方式、专业 |
2 | 专业对照表 | 对照院系编号和院系名称 | 专业编号、专业名称 |
3 | 排课表 | 可供选择的全部课程的具体介绍 | 课程编号、课程名称、人数限制、学分、上课时间、授课教师、(教师)工号、学期、课程属性 |
4 | 选课表 | 记录所有的选课记录,以学期作区分,成绩可为空 | 课程编号、课程名称、学号、姓名、学期、成绩 |
5 | 课程教材表 | 为减少冗余,独立于选课表之外,每门课对应一条教材记录 | 课程编号、(教师)工号、教材名称、ISBN编码、作者、出版社、价格 |
6 | 修读计划(必修) | 把修读计划分成必修和选修两种,各对应一张表。必修课根据课程编号检索。 | 专业、年级、课程编号 |
7 | 修读计划(选修) | 选修课根据课程属性和学分要求检索,例如:信管-14-三模-2 | 专业、年级、课程属性、学分要求 |
8 | 绩点计算规则 | 对于成绩转绩点的规则说明。 | 成绩、绩点 |
编号 | 数据流名 | 数据流来源 | 数据流去向 | 组成:{数据结构} |
---|---|---|---|---|
1 | 学生个人信息 | 学生输入 | 学生 | 个人信息 |
2 | 教师个人信息 | 教师输入 | 学生 | 个人信息 |
3 | 排课表 | 教务员输入 | 学生和教师 | 排课表 |
4 | 课程教材表 | 教务员输入 | 学生 | 课程教材表 |
5 | 成绩 | 教师输入 | 学生 | 选课表 |
6 | 选课表 | 学生选课 | 学生、教师和教务员 | 选课表 |
7 | 修读计划 | 教务员输入 | 学生和教务员 | 修读计划(必修)、修读计(选修) |
编号 | 数据储存名 | 输入 | 输出 | 说明 |
---|---|---|---|---|
1 | 学生个人信息 | 学号、密码、姓名、性别、出生年月、年级、联系方式、专业编号 | 个人信息 | 与教师个人信息类似 |
2 | 教师个人信息 | 工号、密码、姓名、性别、出生年月、联系方式、专业编号 | 个人信息 | |
3 | 排课表 | 课程编号、课程名称、学分、上课时间地点、授课教师、学期、课程属性 | 排课表 | |
4 | 课程教材表 | 课程编号、授课教师工号、课程教材ISBN | ||
5 | 选课表 | 学号(登录)、课程编号(选课)、成绩 | 选课表、学生课程表、课程名单、成绩单、修读计划完成情况 | 选课表SC包含课程编号、课程名称、学号、姓名、学期、成绩等属性,将过去的选课记录和现时的选课记录在一张表中。分数为百分制。 |
6 | 修读计划(必修) | 年级、专业、课程编号 | 修读计划(必修) | |
7 | 修读计划(选修) | 年级、专业、课程属性、学分 | 修读计划(选修) | |
8 | 绩点计算规则 | 成绩、绩点 | 绩点计算规则 |
编号 | 处理过程名 | 输入 | 输出 | 说明 |
---|---|---|---|---|
1 | 增改排课表课程 | 课程编号 | 排课表 | |
2 | 选课 | 学号(登录)课程编号(选课) | 学生课程表、课程名单 | |
3 | 增改选课名单 | 课程编号/课程名称、学号 | (修改后的)课程名单 | |
4 | 修改个人信息 | 学号/工号、(密码)、被修改项 | (修改后的)个人信息 | |
5 | 查看修读计划完成情况 | 学号、(密码) | 个人修读计划完成情况 | 显示学生的所有修读课程记录,并对比修读计划 |
6 | 实时绩点查询 | 学号、(密码) | 个人实时绩点 | 先查询学生的所有修读课程记录,再计算实时绩点 |
7 | 查看课程学生名单 | 课程编号 | 选课的学生名单 | 从选课表中获取数据 |
8 | 查看教学活动安排 | 工号、(密码)、学期 | 课程编号、课程名称、上课时间 | 从选课表中获取数据 |
9 | 增改修读计划 | 专业、年级、课程编号(课程属性)、(学分) | 修读计划(总) | 对于选修和必修分别进行修改 |
10 | 修改成绩 | 学号、课程编号、成绩 | 成绩 |
安全性:
系统的控制防范对象是非法用户和非法操作,防止他们对数据库的非法存取。为保障信息安全,在设计系统时采取以下预防手段:
(1) 采用实名验证,通过系统鉴别后为用户提供相应的数据库管理系统权限。比如,通过实名注册用户名登录密码等,并采取动态口令鉴别。
(2) 为不同的用户定义不同的视图(教师仅能够检索学生选课信息的视图,而教务人员则能够看到全部学生的选课信息的视图,并拥有增删改的权限),把数据对象限制在一定的范围内,对数据提供一定程度的安全保护。
(3) 对于不同类型的用户进行不同等级的授权,保障数据库的信息安全。对于数据库管理员而言,即教务人员而言,拥有最高权限,能够几乎对于全部用户进行基本表操作;教师和学生的权限相对较低,例如学生仅能对于自己的课程表进行选课设置,查询自己的选课情况和绩点等。
(4)对于不同时间段的安全性要求也不同,由于应用环境的变化,安全性需求也会发生相应的变化,需要数据库管理员不断的及时修正,满足用户需求,同时满足数据库的安全需求。例如,在选课事务结束之后,学生便不能够对自己的选课进行继续选课或者退课的操作,需要对于学生的权限设置做出及时的修改。
保障运行安全的手段有:
(1)采取审计功能,把用户对于数据库全部的操作记录自动记录下来放入审计日志中(尤其是高权限用户的操作记录),审计员对于审计日志进行分析,可以在发生问题时重现数据库状态,找出非法用户。并且能够对于潜在危险提前采取预防措施。由于审计功能费时费力,可以在选课期间开放,保障高峰时期的频繁访问数据库时的数据库安全。
(2)对于数据库中重要信息采取数据加密,保障数据内部信息的安全。
(3)数据库逻辑语句要求正确,避免错误的运算。
(4)预防数据库物理方面的问题,进行及时备份,以防止数据丢失。并且数据库中,各表之间根据实体完整性、参照完整性、域完整性设置了各种约束,一旦某个对象被非法修改,将影响其他各个表,因此进行数据备份尤为重要。
(5)定期进行计算机硬件、操作系统、网络环境的维护,以保障数据库的安全性。
完整性: 控制的防范对象是不合语义的数据,防止他们进入数据库。
正确性: 保证输入、输出和运行的正确,数据均符合当前的现实状态。
相容性: 数据库中,各表之间根据实体完整性、参照完整性、域完整性设置了各种约束,在这之中的统一对象在不同表中的数据符合逻辑且符合约束。
专业(专业编号,专业名称)
学生(学号,姓名,性别,出生年月,专业编号,联系方式,年级,密码)
教师(工号,姓名,性别,出生年月,专业编号,联系方式,职称,密码)
课程(课程编号,学期,课程名称,课程属性,人数限制,实际人数,学分, 上课时间, 上课地点)
教材(教材名称,ISBN编码,出版社,价格,作者)
成绩-绩点转换(成绩,绩点)
专业-必修课 (专业、年级、课程编号)
专业-选修课 (专业、年级、课程属性、学分要求)
首先,我们在设计整个项目时,想了很多实用的小功能,但是很多其实仅仅是对数据库数据的增删改查的运用,而不是表的设计。这导致了我们在前期画E-R图的时候找不清实体,分不清实体和用户之间的关系以及表和实体之间的关系。因此,我们通过重新整理了我们所需要的数据项等得出了我们的真正的实体是什么,实体和实体之间的联系又是怎样的。例如,我们起初将学生和个人信息作为实体其联系写为查询/修改,但实际上,个人信息中的内容大多可以作为学生的属性出现而不是作为一个单独的实体。
之后,我们曾经希望能够将各个模块的E-R图分别画出来,最后整合出一个完整的E-R图。但是事实上,我们将几个模块的E-R图画出后,发现每个部分都比较简单,有的部分的实体中的属性其实也是可以作为另一个实体出现,也将产生很多的不统一性。介于此,并且我们的数据库概念结构应该较为简单的前提下,我们先绘制了整体的框架E-R图,再进行各个实体的属性的填充与展开。例如,本身将教材列为了课程的一个属性,之后通过整理发现,教材不仅仅依赖于课程还依赖于不同的授课教师以及教材本身还有自己的属性,因此我们将教材单独列出其与授课教师和课程的三元联系。
此外,我们在绘制E-R图时,发现有些实体中其实联系较多,如何合理区分实体、联系和属性,合理设计联系对于降低数据库系统冗余度显得至关重要。最后在多次的反复修改和讨论中终于得到较为满意的结果。
学生(学号,姓名,性别,出生年月,专业编号,联系方式,年级,密码)
教师(工号,姓名,性别,出生年月,专业编号,联系方式,职称,密码)
专业(专业编号、专业名称)
排课表(课程编号、学期、课程名称、学分、上课时间地点、课程属性)
选课表(课程编号、学号、学期、成绩),前三个作为主码
课程教材表(工号、课程编号、学期、ISBN编码),前三个主属性合并为主码
教材详情(ISBN编码,教材名称、出版社、作者、价格)
修读计划-必修(专业、年级、课程编号)
修读计划-选修(专业、年级、课程属性、学分要求)
成绩-绩点转换(成绩,绩点)
学生 BCNF(学号,姓名,性别,出生年月,专业编号,联系方式,年级,密码)
教师 BCNF(工号,姓名,性别,出生年月,专业编号,联系方式,职称,密码)
专业 BCNF (专业编号、专业名称)
排课表 BCNF (课程编号、课程名称、学分、上课时间、学期、课程属性)
选课表 BCNF (课程编号、学号、学期、成绩),前三个作为主码
课程教材表 BCNF(工号、课程编号、学期、ISBN编码),三个主属性合并为主码
教材详情表 BCNF(ISBN编码,教材名称、出版社、作者、价格)
修读计划-必修 BCNF(专业、年级、课程编号)
修读计划-选修 BCNF (专业、入学年份、课程属性、学分要求)
成绩-绩点转换 BCNF(成绩、绩点)