课程设计论文竞赛管理系统代码数据字典流程图.docx
《课程设计论文竞赛管理系统代码数据字典流程图.docx》由会员分享，可在线阅读，更多相关《课程设计论文竞赛管理系统代码数据字典流程图.docx（75页珍藏版）》请在冰点文库上搜索。
信息工程学院
《数据库课程设计》论文
题目：
学科竞赛数据库设计
学号：
专业班级：
姓名：
指导老师：
完成日期：
72
学科竞赛管理系统数据库设计
摘要:
学科竞赛是每个学校有的一项活动，他可以提高学生学习的积极性，培养学生对学科的兴趣，丰富学生的课余生活，让学生在课下可以学到知识，交到朋友。
但学科竞赛的管理十分繁琐，流程复杂，工作量大。
因此老师和教务处都迫切需要一个能方便管理竞赛的系统。
该系统面向学生，老师，教务处，学院领导四种用户，涉及申请比赛，查询比赛，总结比赛，报名参赛，查询成绩等多方面功能。
这次设计包括需求分析，概念结构设计，物理结构设计，数据库实施四个方面。
关键字：
数据库；学科竞赛管理；SQLServer
目录
1．需求分析 1
业务流程图:
2
数据流程图：
3
2．数据库结构设计 7
2.1概念设计 8
2.1.1分E-R图建立 8
2.1.2全局/整体E-R图 8
2.2逻辑设计 9
2.2.1建立关系模式 10
2.2.2关系模式规范化处理 11
2.2.3用户子模式建立 12
2.2.4关系模式逻辑结构定义 14
3．数据库物理设计 15
4．数据库实施与测试 16
4.1SQLServer2008数据库实施与测试 16
4.1.1数据库及数据库对象建立 16
4.1.2数据入库 16
4.1.3数据库测试 17
4.2Oracle数据库实施与测试 41
4.2.1数据库及数据库对象建立 41
4.2.2数据入库 41
4.2.3数据库测试 41
5．总结 52
6．附录 52
附录1 52
数据字典：
52
附录2 56
附录3 59
附录4 64
13级软件工程专业3班数据库应用系统课程设计课程论文
1．需求分析
需求分析是每个应用程序设计前必须的也是最重要的步骤，如果需求分析没做好，后期的工作可能算白费了。
因为软件的设计就是为了服务用户，如果对用户的需求分析错误，那么最终设计的软件就不是用户所需要的。
所以需求分析在软件开发周期中占有比较的的比重。
并且贯穿软件开发始终。
不能为了减少开发时间而缩短需求分析的时间。
需求分析需要全面考虑用户的每个需求，有些用户没提到的需求也要从其他需求中提去出来。
需求分析力求准确、完整、清晰、具体。
为了更好的分析需求，需要设计很多图和表。
包括业务流程图、数据流程图。
需要设计数据字典，包括数据项、数据结构、数据流、数据逻辑、数据存储。
概述：
学科竞赛信息管理系统旨在搭建一个信息平台，方便各类用户处理学科竞赛方面的事务，如方便用户浏览信息，简化管理中的各种操作，提高相关人员工作的效率。
其服务的对象有四个，分别为学生，教师，教务处管理员，学院管理员。
学生主要的业务有报名参赛，老师可以申报比赛，提交比赛总结，教务处和学院负责审核比赛和添加比赛，并且负责各项赛事的统计和分析工作。
所有用户都可以对赛事进行查询。
首先从业务的角度来描述其功能。
业务主要分为两个部分：
报名管理和过程管理，过程管理分为竞赛项目管理，竞赛统计管理，竞赛项目查询三部分。
报名管理：
系统根据竞赛的报名信息推荐给相关学生。
学生如果选择报名，不用填写信息，系统会将其个人信息直接存储在报名表中，待教师和学院进行审核，审核的结果会在开赛前几天公布。
竞赛项目管理：
教师填写竞赛申请表和报名信息，系统先交个学院审核，通过了再交给教务处审核。
通知老师最终的审核结果。
如果都审核通过了，教务处发布到系统中。
如果审核不通过，教务处可以让老师修改项目预算，修改时间或地点后再次申请，或者直接放弃该项赛事。
竞赛统计管理：
学院赛事统计，可以查看某一年份各学院申报竞赛的数量和经费，也可以分析各个学院在某个比赛的表现，查询某个学生在校所获奖项等。
这些都可以作为报表导出。
竞赛赛事查询：
各用户可以根据不同的需求进行竞赛项目的查询操作，查看竞赛的报名情况，成绩等信息。
图1-1系统功能结构图
简化功能结构如下
业务流程图:
图1-2添加比赛业务
图1-3学生报名参赛业务
数据流程图：
图1-4顶层数据流程图
图1-5第一层数据流程图1
图1-6第一层数据流程图2
图1-7第一层数据流程图3
图1-8第二层数据流程图1
图1-9第二层数据流程图2
图1-10第二层数据流程图3
根据数据流程图可以建立数据字典，分别有数据项，数据结构，数据流，数据逻辑和数据存储。
见附录1.
2．数据库结构设计
主要包括概念设计和逻辑设计两个部分。
2.1概念设计
/*阐述概念设计目标、任务和方法，重点介绍概念设计的内容。
*/
概念模型是现实世界到机器世界的一个中间层次。
概念结构设计时整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。
——数据库系统概论（王珊，萨师煊第五版）
概念设计就是将需求分析得到的用户需求抽象为信息结构（即概念模型）。
概念设计是在需求分析的基础上进行设计的，是把需求分析的成果转化为简单、清晰、易于理解的概念模型。
概念模型中最主要的就是E—R图。
2.1.1分E-R图建立
阐述分E-R图建立的思想（以中层数据为切入点，按照分层次/分模块思想），用E-R模式描述。
E-R图的建立以比赛为切入点。
分为教师申请比赛，学院或教务处添加或总结比赛。
学院或教务处审核比赛，学生报名参赛。
教师总结比赛等模块
2.1.2全局/整体E-R图
整体E-R图
整体E-R把各个E-R图按逻辑组合起来。
来粗略的描述整个系统要完成的功能。
E-R图如下：
图2-1全局E-R图
2.2逻辑设计
逻辑结构设计的任务就是把概念结构设计阶段设计的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。
2.2.1建立关系模式
E-R图向关系模型的转换要解决的问题是，如何将实体型和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。
对于不同的实体间的联系有不同的转换方式。
1.一个1:
1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。
如果与某一端实体对应的关系模式合并，则需要再该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
2.一个1:
n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
3.一个m:
n联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，个实体的码组成关系的码或关系码的一部分。
4.三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，个各实体组成关系的码或关系码的一部分。
5.具有相同码的关系模式可以合并。
根据上面的转换原则得到的关系模式如下：
学生信息（学号，姓名，性别，生日，电话，邮箱，专业，所在班级，年级,系统登录密码，学号->姓名，学号->性别，学号->电话，学号->邮箱，学号->所在班级，学号->年级，学号->专业，学号->系统登录密码）；
教师信息（工号，姓名，性别，生日，电话，邮箱，所在学院，登录密码，职务，备注，工号->姓名，工号->性别，工号->生日，工号->电话，工号->邮箱，工号->所在学院，工号->登录密码，工号->职务）；
学院信息（学院名，负责人工号，学院名->负责人工号）；//教务处当做学院处理。
专业信息（专业名称，所在学院，专业名称->所在学院）；
赛事信息（赛事编号，赛事名称，赛事信息，比赛时间，赛事级别，主办方，负责人工号，报名开始时间，报名结束时间，赛事举办地点，赛事预算，赛事申请信息，赛事总结，赛事审核信息，赛事编号->赛事名称,赛事编号->比赛时间,赛事编号->赛事级别，赛事编号->主办方，赛事编号->负责人工号，赛事编号->报名开始时间，赛事编号->报名结束时间，赛事编号->赛事举办地点，赛事编号->赛事申请信息，赛事编号->赛事总结，赛事编号>赛事审核信息）；
竞赛报名信息及结果（赛事编号，报名学生学号，指导老师，报名学生成绩，报名学生排名，报名学生备注，赛事编号+报名学生学号->报名学生学号，赛事编号+报名学生学号->指导老师，赛事编号+报名学生学号->报名学生成绩，赛事编号+报名学生学号->报名学生排名，赛事编号+报名学生学号->报名学生备注）主码：
赛事编号+报名学生学号；
通知信息（通知编号，通知时间，通知发起者，通知内容，通知编号->通知时间，通知编号->通知发起者，通知编号->通知内容）；
学生通知（通知编号，通知对象学号）；
教师通知（通知编号，通知对象工号）；
2.2.2关系模式规范化处理
1.对于学生信息关系模式，姓名，性别，专业，生日，邮箱，手机号，年级，密码，这些属性都是独立的不相互关联的，所以不存在依赖关系，那么处理学号与其他非主属性的函数依赖外，就不存在其他函数依赖，也就不存在传递依赖了，所以满足三范式。
2.对于教师关系模式，与学生信息关系模式相同，所以也满足三范式。
3.对于竞赛信息关系，其中的非主属性互不相关，所以不存在传递关系。
4.对于竞赛成绩信息，他是由竞赛与学生的关系转换而来，非主属性互不依赖，所以也满足三范式。
5.对于通知信息，其中的非主属性互不相关，所以不存在传递依赖，所以满足三范式。
6.学生通知和教师通知是由实体联系转换而得到的关系，其特点类似于竞赛成绩所以也满足三范式。
7.学院和专业关系都只有两个属性，所以不可能存在传递依赖，所以满足三范式。
2.2.3用户子模式建立
用户子模式的设计是根据不同用户或局部应用的需求，结合具体关系数据库来生成多个视图。
视图并不是真正存在的表，而是由基本表导出的表，是一个虚表。
视图的建立对数据库来说意义重大。
视图有以下几个方面的优势：
1.视图能够简化用户的操作。
直接在视图上操作，比在表上操作更方便，因为直接在表上操作，可能需要用到，连接、嵌套查询等操作，如果直接在视图上操作，可能不需要这些操作。
2.视图使用户以多种角度看待同一数据。
视图的建立没有想基本表那样多的约束，它可以根据用户的实际需求来建立表。
比如说成绩信息，在基本表中应该是学号、比赛编号和成绩，但老师希望看到的是学生姓名和比赛成绩。
这个就可以构成一个视图。
3.视图对重构数据库提够了一定程度的逻辑独立性。
意思是说如果数据库要重构，基本表的结构改变了，但由于视图的存在，如果之前有的操作是在视图上的，那么这些操作相关的代码就不用修改了。
4.视图能够对机密数据提供安全保护。
针对不同用户建立不同的视图，使得不同用户只能看到数据表中的部分数据，可以有效防止数据泄露，数据被恶意修改。
5.适当利用视图可以更清晰地表达查询。
如果之前建立好了视图，那么在查询的时候直接对视图进行查询语句会更加简单易懂。
针对该数据库，可建立如下视图：
1.对于学生信息，学生，教师能看到学生信息表和教师信息表中除了密码以外的全部信息。
所以针对学生信息表和教师信息表，建立一个包含除了密码以外的所有信息的视图。
为了方便了解信息，在视图中把学生表中的生日替换为年龄，然后加上学生学院信息。
2.对于赛事信息，除了竞赛申请者、学院负责人，其他人不能看到赛事信息表中的赛事预算，赛事总结，赛事审核信息。
所以把赛事信息表中已经审核通过的比赛除了这些属性外，再建立一个视图，方便学生查看和报名比赛。
3.为了方便学生和教师查看成绩，应该建立含有学生具体信息的成绩视图。
4.为了方便学生查看和报名即将举行的比赛，应对已经审核通过的比赛建立视图。
5.为了方便学院和教务处审核比赛，应对待审核的比赛建立视图。
具体视图信息如下：
1.学生信息视图（学号，姓名，性别，年龄，电话，邮箱，专业，所在学院，年级）；
2.教师信息视图（工号，姓名，性别，年龄，电话，邮箱，所在学院）；
3.已审核赛事信息视图（赛事编号，赛事名称，赛事信息，比赛时间，赛事级别，主办方，负责人工号，报名开始时间，报名结束时间，赛事举办地点）；
4.学生成绩视图（学生姓名，专业，年级，学院，比赛名称，指导老师，比赛成绩，比赛排名，备注）；
5.待审核赛事信息视图（赛事编号，赛事名称，赛事信息，比赛时间，赛事级别，主办方，负责人工号，报名开始时间，报名结束时间，赛事举办地点，赛事预算，赛事申请信息，赛事总结，赛事审核信息）
6.已审核赛事视图（赛事编号，赛事名称，赛事信息，比赛时间，赛事级别，主办方，负责人工号，报名开始时间，报名结束时间，赛事举办地点，赛事预算，赛事申请信息，赛事总结，赛事审核信息）
图2-2全部视图
2.2.4关系模式逻辑结构定义
关系模式总共有九个，一下为其汇总表。
表2-2医院门诊管理系统关系模式汇总表
关系模式名称
含义
备注
studentInfor
学生详细信息
附录2附表1
teacherInfor
教师详细信息
附录2附表2
departInfor
学院信息
附录2附表3
contestInfor
赛事详细信息
附录2附表4
notice
通知相关内容
附录2附表5
stunotice
学生通知记录
附录2附表6
teanotice
教师通知记录
附录2附表7
conResult
竞赛成绩信息
附录1附表8
majInfor
专业学院关系
附录1附表9
3．数据库物理设计
数据库的物理设计时为逻辑数据模型选取一个合适的物理结构（包括存储结构和存取方法）从而最大限度地提高数据库的效率。
数据库的物理设计通常分为两步：
（1）确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构
（2）对物理结构进行评价，评价的重点是时间和空间效率。
由于在建立主键的时候，数据库自动将其当做聚簇索引，而一张表只能建立一个聚簇索引，所以这里主要考虑非聚簇索引的设计。
虽然索引会明显提高数据查询的效率，但索引的加入也会带来弊端。
（1）索引的建立会增加数据库的磁盘占用空间。
索引并不像视图那样是虚的，它是实际存在的一种表，索引任何索引都会占据一定的空间。
（2）索引的建立会影响insert,delete,update等语句的功能。
因为执行这些语句的同时，索引也要做相应的调整和更新。
就该数据库而言，学生信息是该系统的基础，大多数业务都围绕着某个学院的学生进行的，如通知某个学院的学生参加比赛，查询某个学院的学生信息，所以学生表表会经常涉及到关于某个学院的查询和连接操作。
并且学生信息表在建立后就很少插入，更新和删除，根据上面的讨论，可以对学生信息表中的专业名称建立非聚簇索引。
另外竞赛信息也是该系统的基础，在学生查看所在学院竞赛，教务处统计某个学院竞赛经费和举办情况这些业务中会经常涉及到ORDERBY、GROUPBY、UNION、DISTINCT操作，所以对竞赛信息表中的学院名称也建立非聚簇索引。
再者，竞赛成绩信息是该系统的中心，无论是学生，老师，学院，还是教务处，都会涉及到查询某个竞赛成绩的操作，而且每个竞赛都会有排名，这涉及到ORDERBY操作，查询某个竞赛某个学院的比赛情况，这涉及到GROUPBY操作。
并且一但竞赛成绩被录入，就不会对该成绩信息进行更新、插入和删除操作。
所以，对竞赛成绩中的竞赛编号建立非聚簇索引。
图2-3全部索引
4．数据库实施与测试
4.1SQLServer2008数据库实施与测试
4.1.1数据库及数据库对象建立
按照逻辑设计的成果，由于存在外键约束，所以对建表的顺序有约束。
根据各个约束条件。
分别建立学院信息表，专业信息表，教师信息表，学生信息表，赛事信息表，通知信息表，学生通知表，教师通知表，赛事成绩表。
DDL语句见附录3。
4.1.2数据入库
选择一些学院和专业录入到数据库，然后随机录入教师和学生信息。
然后根据，在录入过程中根据外键约束做相应调整。
4.1.3数据库测试
下面主要对建立的存储过程和触发器测试。
/*教师申请比赛的存储过程*/
createproceduretea_apply_contest
@conNamevarchar（30）,
@conInfortext,
@conLevelvarchar（20）,
@conHostvarchar（20）,
@conTeaIdvarchar（10）,
@conBudgetsmallint,
@conApplytext
as
insertintoconInfor
（
conName,
conInfor,
conLevel,
conHost,
conTeaId,
conBudget,
conApply,
conVerify
）
values
（
@conName,
@conInfor,
@conLevel,
@conHost,
@conTeaId,
@conBudget,
@conApply,
'未审核'
）
go
测试代码
exectea_apply_contest
'Java知识大赛',
'数据库设计的比赛,面向全院',
'院级',
'信息工程学院',
'2000000003',
'3000',
'申请说明书'
go
测试结果：
图4-1
图4-2
/*学院或教务处添加比赛的过程*/
createprocedureadd_contest
@conNamevarchar（30）,
@conInfortext,
@conLevelvarchar（20）,
@conHostvarchar（20）,
@conTeaIdvarchar（10）,
@conBudgetsmallint,
@conApplytext
as
insertintoconInfor
（
conName,
conInfor,
conLevel,
conHost,
conTeaId,
conBudget,
conApply,
conVerify
）
values
（
@conName,
@conInfor,
@conLevel,
@conHost,
@conTeaId,
@conBudget,
@conApply,
'审核通过'
）
go
execadd_contest
'C++语言知识大赛',
'关于C语言知识设计的比赛,面向全院',
'院级',
'信息工程学院',
'2000000001',
'3000',
'申请说明书'
go
测试结果：
图4-3
/*显示待审核比赛存储过程*/
createprocedureshow_unverify
as
select
teaInfor.teaName,
conInfor.conName,
conInfor.conInfor,
conInfor.conLevel,
conInfor.conHost,
conInfor.conTeaId,
conInfor.conBudget,
conInfor.conApply
from
conInfor,
teaInfor
whereconVerify='未审核'
andteaInfor.teaID=conInfor.conTeaId
go
execshow_unverify
go
图4-4
/*审核比赛过程*/
createprocedureverify_contest
@conIDint,
@verifyInforvarchar（10）
as
updateconInfor
setconInfor.conVerify=@verifyInfor
whereconInfor.conID=@conID
go
execverify_contest'2','审核未通过'
go
execverify_contest'3','审核通过'
go
图4-5
/*设置报名和比赛信息的过程*/
createprocedureset_reg_infor
@conIDint,
@conTimedatetime,
@regBegindatetime,
@regEnddatetime,
@conAddressvarchar（50）
as
updateconInfor
set
conInfor.conTime=@conTime,
conInfor.regBegin=@regBegin,
conInfor.regEnd=@regEnd,
conInfor.conAddress=@conAddress
where
conInfor.conID=@conID
andconInfor.conVerify='审核通过'
go
execset_reg_infor
8,
'2015/6/2412:
00',
'2015/6/2320:
00',
'2015/6/2410:
00',
'信息工程学院m2'
go
测试结果
图4-6
/*测试ident_current（）函数，该函数返回刚插入后数据项的主键*/
insertintonotice
（
noticeTime,
noticeHostID,
noticeInfo
）
values
（
'2015/6/2400:
05',
'2000000001',
'测试5'
）
selectident_current（'notice'）
go
/*赛事负责人通知学生参加某个比赛*/
dropprocedurecon_notice
go
createprocedurecon_notice
@conIDint,
@noticeTimedatetime,
@noticeHostIDvarchar（10）,
@stuGradechar（4）,
@namevarchar（20）
as
begin
if（selectconInfor.conVerify
fromconInfor
whereconInfor.conID=@conID）='审核通过'
begin
declare
@conNamevarchar（30
升级会员 