信息工程学院《数据库课程设计》论文题 目：学科竞赛数据库设计学号：专业班级：姓名：指导老师：完成日期：72学科竞赛管理系统数据库设计摘 要: 学科竞赛是每个学校有的一项活动，他可以提高学生学习的积极性，培养学生对学科的兴趣，丰富学生的课余生活，让学生在课下可以学到知识，交到朋友但学科竞赛的管理十分繁琐，流程复杂，工作量大因此老师和教务处都迫切需要一个能方便管理竞赛的系统该系统面向学生，老师，教务处，学院领导四种用户，涉及申请比赛，查询比赛，总结比赛，报名参赛，查询成绩等多方面功能这次设计包括需求分析，概念结构设计，物理结构设计，数据库实施四个方面关键字：数据库；学科竞赛管理；SQL Server目录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 SQL Server 2008数据库实施与测试 164.1.1 数据库及数据库对象建立 164.1.2 数据入库 164.1.3 数据库测试 174.2 Oracle数据库实施与测试 414.2.1 数据库及数据库对象建立 414.2.2 数据入库 414.2.3 数据库测试 415．总结 526．附录 52附录1 52数据字典： 52附录2 56附录3 59附录4 6413级软件工程专业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. 对于学生信息，学生，教师能看到学生信息表和教师信息表中除了密码以外的全部信息所以针对学生信息表和教师信息表，建立一个包含除了密码以外的所有信息的视图为了方便了解。