课程设计论文竞赛管理系统代码 数据字典 流程图.docx

《课程设计论文竞赛管理系统代码 数据字典 流程图.docx》由会员分享，可在线阅读，更多相关《课程设计论文竞赛管理系统代码 数据字典 流程图.docx（65页珍藏版）》请在第一文库网上搜索。

1、信息工程学院数据库课程设计论文题目：学科竞赛数据库设计学号:专业班级:姓名:指导老师:完成日期:学科竞赛管理系统数据库设计摘要：学科竞赛是每个学校有的一项活动，他可以提高学生学习的主动性，培育学生对学科的爱好，丰富学生的课余生活，让学生在课下可以学到学问，交到挚友。但学科竞赛的管理特别繁琐，流程困难，工作量大。因此老师和教务处都迫切须要一个能便利管理竞赛的系统。该系统面对学生，老师，教务处，学院领导四种用户，涉及申请竞赛，查询竞赛，总结竞赛，报名参赛，查询成果等多方面功能。这次设计包括需求分析，概念结构设计，物理结构设计，数据库实施四个方面。关键字：数据库；学科竞赛管理；SQ1Server书目

2、1.需求分析1业务流程图:2数据流程图：32 .数据库结构设计72.1 概念设计82.1.1 分E-R图建立82.1.2 全局/整体E-R图82.2 逻辑设计92.2.1 建立关系模式102.2.2 关系模式规范化处理112.2.3 用户子模式建立122.2.4 关系模式逻辑结构定义143 .数据库物理设计154 .数据库实施与测试164.1 SQ1Server2008数据库实施与测试164.1.1 数据库及数据库对象建立164.1.2 数据入库164.1.3 数据库测试174.2 Orac1e数据库实施与测试414.2.1 数据库及数据库对象建立414.2.2 数据入库414.2.3 数据库

3、测试415 .总结526 .附录52附录152数据字典：52附录256附录359附录4641 .需求分析需求分析是每个应用程序设计前必需的也是最重要的步骤，假如需求分析没做好，后期的工作可能算白费了。因为软件的设计就是为了服务用户，假如对用户的需求分析错误，那么最终设计的软件就不是用户所须要的。所以需求分析在软件开发周期中占有比较的的比重。并且贯穿软件开发始终。不能为了削减开发时间而缩短需求分析的时间。需求分析须要全面考虑用户的每个需求，有些用户没提到的需求也要从其他需求中提去出来。需求分析力求精确、完整、清楚、具体。为了更好的分析需求，须要设计许多图和表。包括业务流程图、数据流程图。须要设计

4、数据字典，包括数据项、数据结构、数据流、数据逻辑、数据存储。概述：学科竞赛信息管理系统旨在搭建一个信息平台，便利各类用户处理学科竞赛方面的事务，如便利用户阅读信息，简化管理中的各种操作，提高相关人员工作的效率。其服务的对象有四个，分别为学生，老师，教务处管理员，学院管理员。学生主要的业务有报名参赛，老师可以申报竞赛，提交竞赛总结，教务处和学院负责审核竞赛和添加竞赛，并且负责各项赛事的统计和分析工作。全部用户都可以对赛事进行查询。首先从业务的角度来描述其功能。业务主要分为两个部分：报名管理和过程管理，过程管理分为竞赛项目管理，竞赛统计管理，竞赛项目查询三部分。报名管理：系统依据竞赛的报名信息举荐

5、给相关学生。学生假如选择报名，不用填写信息，系统会将其个人信息干脆存储在报名表中，待老师和学院进行审核，审核的结果会在开赛前几天公布。竞赛项目管理：老师填写竞赛申请表和报名信息，系统先交个学院审核，通过了再交给教务处审核。通知老师最终的审核结果。假如都审核通过了，教务处发布到系统中。假如审核不通过，教务处可以让老师修改项目预算，修改时间或地点后再次申请，或者干脆放弃该项赛事。竞赛统计管理：学院赛事统计，可以查看某一年份各学院申报竞赛的数量和经费，也可以分析各个学院在某个竞赛的表现，查询某个学生在校所获奖项等。这些都可以作为报表导出。竞赛赛事查询：各用户可以依据不同的需求进行竞赛项目的查询操作，

6、查看竞赛的报名状况，成果等信息。竞赛查询管理赛项经费查询赛项查询赛项年份变化学生奖项统计导出EXCe1学科竞赛信息管理系统竞赛统计管理学生报名统计赛项类型统计赛项级别统计学院赛项统计竞赛总结查看导出报表简化功能结构如下竞赛项目管理报名管理图1-1系统功能结构图发布竞赛通知审核竞赛项目申报竞赛项目查看报名结果报名审核赛项报名业务流程图:教务处审核图1-2添加竞赛业务图1-3学生报名参赛业务数据流程图:图1-4顶层数据流程图a9用名信星揖名甲用户像曜除名tt幄名值1i值电91第字限翕北隶忖w,*wW!如鼻T1Q处收啧一助值W1W-友有郁学变喳总X班筌*w*90川鳍1*啖/“用处季摘*陆附典持中僧费

7、展（1.史j以I-I1处喷泉“警处MI学生I统计 查启w* w项信息14M处稣列刖S豪09P2.2密防审旗理P2.3费斯通知理P2.3品色申他Ir谏S 申根寒项I构申报卡喙r-?Re岩秀及申报喷一tie-一指定款T除一图1-9其次层数据流程图2软秀处频Sii-Pii班接计 袋fe!s If 499 值PJ-2字除助娘If质加窈坡计超辱财目宣中PX4PIS学生报名城计P17塞陈宾2?陵计吸9*11Wttf1ttu图1-10其次层数据流程图3依据数据流程图可以建立数据字典，分别有数据项，数据结构，数据流，数据逻辑和数据存储。见附录12 .数据库结构设计主要包括概念设计和逻辑设计两个部分。2.1 概

8、念设计/*阐述概念设计目标、任务和方法，重点介绍概念设计的内容。*/概念模型是现实世界到机器世界的一个中间层次。概念结构设计时整个数据库设计的关键,它通过对用户需求进行综合、归纳与抽象,形成一个独立于具体数据库管理系统的概念模型。数据库系统概论（王珊,萨师熠第五版）概念设计就是将需求分析得到的用户需求抽象为信息结构（即概念模型）。概念设计是在需求分析的基础上进行设计的，是把需求分析的成果转化为简洁、清楚、易于理解的概念模型。概念模型中最主要的就是ER图。分E-R图建立阐述分E-R图建立的思想（以中层数据为切入点，依据分层次/分模块思想），用E-R模式描述。E-R图的建立以竞赛为切入点。分为老师

9、申请竞赛，学院或教务处添加或总结竞赛。学院或教务处审核竞赛，学生报名参赛。老师总结竞赛等模块全局/整体E-R图整体E-R图整体E-R把各个E-R图按逻辑组合起来。来粗略的描述整个系统要完成的功能。E-R图如下:2.2逻辑设计逻辑结构设计的任务就是把概念结构设计阶段设计的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。建立关系模式E-R图向关系模型的转换要解决的问题是，如何将实体型和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。对于不同的实体间的联系有不同的转换方式。1. 一个1:1联系可以转换为一个独立的关系模式，也可以与随意一端对应的关系模式合并。假

10、如转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。假如与某一端实体对应的关系模式合并，则须要再该关系模式的属性中加入另一个关系模式的码和联系本身的属性。2. 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。假如转换为一个独立的关系模式，则与该联系相连的各实体的码及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。3. 一个m:n联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，个实体的码组成关系的码或关系码的一部分。4. 三个或三个以上实体间的一个

11、多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，个各实体组成关系的码或关系码的一部分。5. 具有相同码的关系模式可以合并。依据上面的转换原则得到的关系模式如下：学生信息（堂是，姓名，性别，生日，电话，邮箱，支业，所在班级，年级，系统登录密码，学号-姓名，学号-性别，学号-电话，学号_邮箱，学号-所在班级，学号-年级，学号-专业，学号-系统登录密码）；老师信息（工,姓名，性别，生日，电话，邮箱，所在学院,登录密码，职务，备注，工号-姓名，工号-性别，工号-生日，工号-电话，工号-邮箱，工号-所在学院，工号-登录密码，工号-职务）；学院信息（学院名

12、,负责人工号，学院名-负责人工号）；教务处当做学院处理。专业信息（专业名称,所在学院，专业名称-所在学院）；赛事信息（赛事编号，赛事名称，赛事信息，竞赛时间，赛事级别，主办方,负责人工号,报名起先时间，报名结束时间，赛事举办地点，赛事预算，赛事申请信息，赛事总结，赛事审核信息，赛事编号-赛事名称，赛事编号-竞赛时间，赛事编号-赛事级别，赛事编号-主办方，赛事编号-负责人工号，赛事编号-报名起先时间，赛事编号-报名结束时间，赛事编号-赛事举办地点，赛事编号-赛事申请信息，赛事编号-赛事总结，赛事编号赛事审核信息）；竞赛报名信息及结果（赛事编号,报名学生学号,指导老师，报名学生成果，报名学生排名，

13、报名学生备注，赛事编号+报名学生学号-报名学生学号，赛事编号+报名学生学号-指导老师，赛事编号+报名学生学号-报名学生成果，赛事编号+报名学生学号-报名学生排名，赛事编号+报名学生学号-报名学生备注）主码：赛事编号+报名学生学号；通知信息（通知编号,通知时间，通知发起者，通知内容，通知编号-通知时间，通知编号-通知发起者，通知编号-通知内容）；学生通知（通知编号，通知对象学号）;老师通知（通知编号，通知对象工号）;关系模式规范化处理1 .对于学生信息关系模式，姓名，性别，专业，生日，邮箱，手机号，年级，密码，这些属性都是独立的不相互关联的，所以不存在依靠关系，那么处理学号与其他非主属性的函数依靠外，就不存在其他函数依靠，也就不存在传递依靠了，所以满意三范式。2 .对于老师关系模式，与学生信息关系模式相同，所以也满意三范式。3 .对于竞赛信息关系，其中的非主属性互不相关，所以不存在传递关系。4 .对于竞赛成果信息，他是由竞赛与学生的关系转换而来，非主属性互不依靠，所以也满意三范式。5 .对于通知信息，其中的非主属性互不相关，所以不存在传递依靠，所以满意三范式