课程设计论文竞赛管理系统代码数据字典流程图Word下载.docx
《课程设计论文竞赛管理系统代码数据字典流程图Word下载.docx》由会员分享，可在线阅读，更多相关《课程设计论文竞赛管理系统代码数据字典流程图Word下载.docx（75页珍藏版）》请在冰豆网上搜索。
目录
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.对于学生信息，学生，教师能看到学生信息表和教师信息表中除了密码以外的全部信息。
所以针对学生信息表和教师信息表，建立一个包含除了密码以外的所有信息的视图。
为了方便了解
升级会员 