学员信息管理数据库模型分析

导语：学员信息管理数据库模型分析一文来源于网友上传，不代表本站观点，若需要原创文章可咨询客服老师，欢迎参考。

1关系数据库简述

数据库技术发展至今已有40多年的历史，它作为数据管理的有效手段，大大促进了计算机应用技术的发展。从早期的文件系统到层次数据库和网状数据库，从关系数据库到面向对象数据库，以及面向不同应用的时态数据库、演绎数据库等等，均向人们展示了数据库技术的广阔应用前景［2］。关系数据库，顾名思义是建立在关系数据库模型基础上的数据库，借助于集合代数、离散数学等概念和方法来处理数据库中的数据。关系数据库是一个被组织成一组拥有正规描述的表格，该形式表格作用的实质是装载着数据项的特殊收集体。这些表格中的数据以许多不同的方式被存取或重新召集而不需要重新组织数据库表格［3］。除了相对容易创建和存取之外，关系数据库具有容易扩充的优势。在最初数据库创造之后，一个新的数据种类能被添加而不需要修改所有的现有应用软件。目前主流的关系数据库有Oracle、SQL、Aceess、DB2、MySQL、SQLServer、Sybase等等［4］。根据本校办学规模和处理信息量，采用ACEESS作为本系统数据库的管理工具。

2数据库模型建立

2．1应用需求抽象

根据学员信息管理的具体任务，按照管理功能进行业务划分和模块化设计。按照简单性、独立性及完整性原则，学员信息管理系统后台可以分为以下几个子系统:即学员档案管理子系统、课程管理子系统、成绩管理子系统、中队管理子系统、管理统计子系统、系统管理子系统、系统维护子系统。(1)学员档案管理子系统学员档案管理主要有学员管理、批量学员添加、按中队批量学员添加等功能。(2)课程管理子系统课程管理子系统主要有课程管理、批量课程添加、任课管理、任课添加等功能。(3)成绩管理子系统成绩管理子系统完成成绩管理、批量成绩添加、按中队成绩添加功能。(4)中队管理子系统中队管理子系统完成中队管理、中队批量添加两个子模块功能。(5)管理统计子系统管理统计子系统显示学校基本信息，包括年级数、中队数、学员数、教师数、课程数、用户浏览统计等相关信息，还可完成学员统计、排名统计功能。(6)系统管理子系统系统管理子系统包括修改管理员密码、帐号管理、干部管理、年级管理、学期管理功能。(7)系统维护子系统系统维护子系统主要完成系统的相关设置功能，包括站点名称，站点LOGO设置，网站主体表格属性设置，年级变迁(这里主要是对年级进行批量升级操作，也可以在中队管理下单个进行升级)。

2．2数据库表关系建立

关系数据库模式的建立，离不开数据表之间关系的建立，只有建立表之间的关系，整个数据库才能形成一个系统，提供强大的信息存储、查询、和处理功能［5］。对比应用需求说明和现实学校各部门的业务流程，设计数据库表之间的关系如图1所示。(1)学员和评语之间存在一对多的对应关系，即一个学员可以有多条来自不同老师的评语;学员和家长存在一对多的对应关系，即一个学员可以对应一个家长，方便家长对学员相关信息进行查询。学员和平时成绩存在一对多的对应关系，即一个学员可以有多种平时成绩;同时，学员还和中队有多对一对应关系，即一个中队可以有多个学员。(2)中队和成绩有一对多的对应关系，即一个中队可以有多条成绩;中队和年级有一对一的对应关系，即一个中队属于一个年级。中队和大队有一对一的对应关系，即一个中队属于一个大队，中队和任课信息有一对多的对应关系即一个中队有多条任课关系与之对应。大队和中队有一对多的对应关系，即一个大队对应多个中队。(3)任课信息表中的教师ID和教师信息表中ID存在一一对应关系。教师表中ID和任课教师信息表中的ID存在一对多的关系。即一个教师可以有多个任课关系。任课教师表中的课程ID和课程表中的课程ID存在一一对应关系。任课信息表中的学期和学期ID存在一一对应关系。即一个任课信息对应一个学期。成绩表中的课程ID和课程信息表中的ID存在一一对应关系，成绩表中的学期ID和学期表中的学期ID存在一一对应关系。

2．3数据库模式设计

2．3．1关系数据库设计中存在问题

(1)数据冗余:在一个数据集合中重复的数据称为数据冗余。例如在设计时没有把教师信息表Teacher和任课信息表tea_sub分开，那么每存储一条任课信息tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)教师表中的其他信息也要重复存储［4］。(2)更新异常:更新异常分为插入异常和删除异常。插入异常:比如学员信息表student，如果不知道学号，那么插入再多的其他信息都是没有意义的。例如一个刚入职的教师理所当然要在任课信息表中有其相关数据，但此时他还没有任课，即他对应的元组＜ts_sub_id、ts_ter_id、ts_cla_id＞是不完全的，只有＜tsid、ts_tea_user、ts_sub_id＞而没有＜ts_ter_id、ts_cla_id＞，不能将他的信息放到数据库中。因此无法注册该教师的任课信息，这与实际需求不符。这样的操作是不合理的，将这种现象称为插入异常。删除异常:例如在没分解的教师信息表中的任课信息中，相应的任课关系解除。那么删除整条记录，该教师的其他信息也被删除，在查询的时候无法查阅该教师相关信息，这也与实际需求相悖，将这种现象称为删除异常。数据库的性能优化包括硬件优化，查询优化和设计优化三个方面。本文着重介绍设计优化即模式优化，模式优化重点解决数据冗余和更新异常问题。

2．3．2数据库模式的规范化

在对数据库进行模式设计时，对关系的分解并不是盲目的，分解的目的在于减少关系模式的规模，避免不必要的存储及操作的冗余和数据更新异常。为了清除异常，需要对关系模式进行合理地分解。为此，人们设计数据库设计的规范化理论，以便能够设计出异常尽可能少的数据库模式［4］。据参考文献［4］所述，数据库模式分为6级，具体的定义见参考书目。分别是1NF:是关系数据库对模式的基本要求，即要求属性的值必须是原子属性不可再分。2NF:消除了数据库模式中非主属性对码的部分依赖。3NF:消除了数据库模式中非主属性对码的传递依赖。BCNF:消除了数据库模式中一切属性对码的传递依赖。4NF:消除了数据库模式中非平凡的和非码所隐患的多值依赖。5NF:消除了数据库模式中非平凡的和非码所隐患的连接依赖［4］。范式的级别由小到大分别是有1NF到5NF。范式的级别越低，冗余与更新异常就越容易产生［6］。(1)满足1NF的学员信息表分解，在学员信息表中每一个属性都该是原子属性，故对部职别进行分解。由消防部队的编制特点，每个省、自治区、直辖市均有相应的消防总队;每个地级市、自治州、区都有相应的消防支队。学校学员来自五湖四海，故对学员信息表中的部职别属性进行分解。由于有的学员来自总队和支队机关，故把部职别分为总队和部职别两个属性，即＜yuanbubie＞分解为＜yuanbu-bie、province＞，province为province表中的省份ID。总队表设计为province(pid、pname)。在学员信息表中只要存储省份ID就行。不用再存储省份名。最长总队名新疆维吾尔族自治区消防总队所占字节为26Btye，所占ID为2Byte。按新疆总队有学员121名计算，模式分解前学员原部别信息中存储总队信息需用26Btye×121=3164Byte;而模式分解后存储ID信息占用2Btye×121=242Byte。(2)满足BCNF的教师信息表分解，在2．4．1节数据库设计存在问题中提到数据冗余和删除异常，在没分解的教师信息表的任课信息中，相应的任课关系解除。那么删除整条记录，该教师的其他信息也被删除，在查询的时候无法查阅该教师相关信息，这也与实际需求相悖。要解决删除异常，即把教师信息表Teacher分解为教师基本信息表teacher和任课教师信息表tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)。这样的分解既解决了数据冗余的问题，也解决了删除异常的问题。分解后Teacher和tea_sub关系模式都是1NF，且在其中不存在这样的属性A，A传递依赖与Teacher和tea_sub的码、由于关系模式Teacher={R1，R2…，Rn}和tea_sub={R1，R2…，Rn}中Ri(i=1，2，…，n)为BC范式，则关系模式Teacher和tea_sub也满足BCNF。数据库的规范化设计还有很多，根据系统应用需求的变更和数据规模的递增，需要设计相应的数据模式来优化昆明消防指挥学校学员综合信息管理系统的数据库性能，使之满足应用需求，更好地为学校教师、学员和管理人员提供便捷的信息化服务。

3结束语

本文介绍了昆明消防指挥学校学员综合信息管理系统的项目开发背景，以关系数据库为系统数据库设计的切入点，从应用模型抽象、数据库表设计、数据库表之间关系设计、以及数据模式设计几个方面详细分析和设计了军校学员综合信息管理系统的数据库。在应用过程中，系统响应迅速，数据存储、编辑、更新、查询正确，未发现明显的存储和更新异常。并对数据库设计模式进行了优化，进一步减少了数据冗余，使整个系统的性能得到进一步的提升。但是，数据库中还存在一定的数据冗余，数据库模式规范化还需进一步优化。在下一步的工作中还将继续对关系数据库理论进行深入研究，力争能使本系统的数据库模式性能明显提升，满足更高级别的范式规范，为全校师生、管理人员提供方便快捷的学员综合信息查询管理平台。

作者：李怀义1张红友1胡静波2工作单位：1．昆明消防指挥学校2．宝鸡文理学院电子电气工程系