数据库课程设计

《数据库技术原理与应用教程》

课程设计。学生成绩管理系统。

课程名称数据库技术原理与应用教程

设计题目学生成绩管理系统。

专业班级。学生姓名。

指导教师。2024年 5 月2日。

4 数据结构定义5

第六章 vb界面的建立18

需求分析的任务是调查应用领域，对应用领域中的信息要求和操作要求进行详细分析，形成需求分析说明书。重点是调查，收集与分析用户在数据管理中的信息要求，处理要求，数据的安全性与完整性要求。

为了完成需求分析的任务，要详细调查待开发的数据库应用部门的情况，了解原系统工作概况，分析用户的各种需求，在此基础上确定新系统的功能。新系统必须考虑今后的扩充和改变，不能仅仅按当前应用需求来设计数据库。

（1）调查组织机构的总体状况。本系统主要由学生管理系统，教师管理系统、课程管理系统、成绩管理系统和用户管理系统。

（2）熟悉各部门的业务活动状况。调查各部门的业务活动情况，对现行系统的功能和和所需信息有一个明确的认识。包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输入什么信息，输出什么信息，输出到什么部门，输出的结果的格式是什么等。

(3)根据(1)(2)调查的结果，对管理系统中各应用的信息要求和操作要求进行详细分析，从中得到：该系统的各个应用从数据库中得到哪些信息，这些信息的具体内容和性质是什么，要求完成什么样的处理功能，对某些处理要求的相应时间，既对数据的安全，完整性的要求。

（4）确定系统的边界。确定整个系统中哪些由计算机完成，哪些将来由系统完成，哪些由人工完成。由计算机完成的功能就是新系统完成的功能。

1）学生基本情况管理：通过该成绩管理系统实现对每个学生基本情况的添加，修改，删除，查询等操作．即若有学生中途退学或者降级等原因，则需要删除有关该学生的基本信息，若有学生插班，则直接添加该学生的基本信息．还有助于班上或者系上查询每个学生的基本情况．

2）成绩管理：通过该学生成绩管理系统实现对学生成绩的添加、修改、删除、查询、统计等操作。每经过一次考试，通过该系统可以将成绩添加进去；若老师或者学生发现成绩有误，则可以通过对该管理系统对成绩进行修改；若有学生降级或退学，应该及时删去有关该学生的所有成绩；同样也有助于学生查询自己的各科成绩以及自己的平均成绩，也有助于对本班的基本学习情况有个大概的了解，对系上进行推荐优秀、评奖学金等提供了最重要的依据。

3）课程管理：学生课程管理主要包括对学生所学的专业课程与公共课程的管理。随着学生所学课程的增加，通过该系统能方便实现对课程的添加；若中途课程有所变动，则可以对该课程进行修改或删除；若学生或教师要了解有关课程的信息，可以通过查询实现。

本系统用户信息：学生必须通过用户登录才能访问到整个管理系统。

4）系统维护：能及时更新该系统的所有信息，若查询结束，能及时退出当前窗口，回到上一级住窗口。

所以，本系统要用到五个表：学生表，教师表，课程表，成绩表，用户表。

4 数据结构定义。

数据结构名含义说明组成。

学生表定义了学生有关信息学生号，姓名，性别，出生日期，国籍，班级号。

教师表定义了教师的有关信息教师号，姓名，职称，性别，出生日期，系别。

课程表定义了课程的有关信息课程号，课程名，教师号。

成绩表定义了选课的基本信息学号，课程号，成绩。

用户表定义了用户的有关信息用户名，密码，级别。

概念设计就是通过对需求分析阶段所得到的信息需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型，主要的手段为er图。绘制e-r图的关键是确定e-r图的各种结构，包括实体、属性和联系。

2）概念结构设计的步骤。

概念结构的设计可分为两步：第一步是抽象数据并设计局部视图。第二步是。

集成局部视图，得到全局的概念结构。

2 e-r图。

2.1 实体。

要建立系统的e-r模型的描述，需进一步从数据流图和数据字典中提取系统所有的实体及其属性。这种提出实体的指导原则如下：

1 属性必须是不可分的数据项，即属性中不能包含其它的属性或实体。

2 e-r图中的关联必须是实体之间的关联，属性不能和其它实体之间有关联。

由前面分析得到的数据流图和数据字典，可以抽象得到实体主要有5个：学生，教师，课程，成绩，用户。

1)学生实体属性有：学生号，姓名，性别，出生日期，国籍，班级号。

2)教师实体属性有：教师号，姓名，职称，性别，出生日期，系别。

3)课程实体属性有：课程号，课程名，教师号。

4)成绩实体属性有：学号，课程号，成绩。

5)用户实体属性有：用户名，密码，级别。

2.2 系统局部e-r图。

学生-课程” 选课关系。

教师-课程”实体间的关系。

2.3系统全局e-r图。

系统的局部e-r图，仅反映系统局部实体之间的联系，但无法反映系统在整体上实体间的相互联系。而对于一个比较复杂的应用系统来说，这些局部的e-r图往往有多人各自分析完成的，只反映局部的独立应用的状况，在系统整体的运作需要时，他们之间有可能存在重复的部分或冲突的情况，如实体的划分、实体或属性的命名不一致等，属性的具体含义(包括数据类型以及取值范围等不一致)问题，都可能造成上述提到的现象。

为解决这些问题，必须理清系统在应用环境中的具体语义，进行综合统一，通过调整消除那些问题，得到系统的全局e-r图。

从实际的情况以及上述的局部e-r图我们可以得知，学生实际选修某门课时必须只能对应一位老师的该门课。因此，可以使用一个聚集来表达学生参加实际授课课程的学习关系，会更加切合实际。各局部e-r存在不少的重复的实体，经过上述聚集分析和合并得到系统全局的e-r图如图所示。

该全局e-r图基本上不存在关系的冗余状况，因此它已经是一个优化的。

在概念设计阶段得到的数据模型，是独立于具体dbms产品的信息模型。在逻辑设计阶段就是将这种模型进一步转化为某一种（某些类）dbms产品支持的数据模型。因此，应将概念设计阶段的e-r图模型转化为关系数据模型。

任课教师与课程之间的是多对多的联系类型，因此，将任课教师、课程以及讲授联系分别设计成如下的关系模式：

教师(教师号，姓名，性别，职称，出生日期，系别)

课程(课程号，课程名，教师号)

学生与课程也是多对多的联系类型，因此，将学生、课程以及选修联系分别设计成如下的关系模式：

学生(学生号，姓名，性别，出生日期，国籍，班级号)

课程(课程号，课程名，教师号)

学生实体与讲授是聚集方式的联系类型，它们之间的关系是多对多的关系，可以使用如下关系模式来表示：

学生选课(课程号，学号，成绩)

在提出关系模式后，我们必须在规范化和实际要求进行优化，这实际上是一个权衡的过程。如果设计没有完全规范化，如可能用于决策支持(与需要大量更新的事务处理相对)的数据库(如数据仓库)则可能没有冗余更新，而且可能对查询更易于理解和更高效。不过，在数据库应用程序内，未规范化的数据在设计过程更需要注意。

一般的策略是以规范化设计为出发点，然后出于特定因素有条件地非规范化某些表，以达到系统总体的优化目的。

首先，需要确定上面建立的关系模式中的函数依赖，一般在作需求分析时就了解到一些数据项的依赖关系，如教师的编号决定了教师的姓名和其它的数据项信息，而实体间的联系本身也是反映了一种函数依赖关系，但是这不是研究的对象，针对的是在一个关系模式中的函数依赖对象。

其次，对上一步确立的所有函数依赖进行检查，判别是否存在部分函数依赖以及传递函数依赖，针对有的依赖通过投影分解，消除在一个关系模式中存在的部分函数依赖和传递函数依赖。

大部分数据库系统只要满足第三关系范式就可以，这也是规范化的基本要求。由于需求分析阶段的方法得当，经过简单的分析可以看出，上述所有关系中每个数据项都是基本的，任何非主属性都不存在对主码的部分依赖，也不存在非主属性存在着对主码的传递依赖。可见，以上所有的关系模式都属于3nf。

数据库课程设计

数据库库课程设计

数据库课程设计总结数据库课程设计个人总结

数据库课程设计

其他用户还读了