ImageVerifierCode 换一换
格式:DOCX , 页数:75 ,大小:5.32MB ,
资源ID:13270875      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/13270875.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(课程设计论文竞赛管理系统代码数据字典流程图Word下载.docx)为本站会员(b****2)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

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

1、目录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 数据库测试4

2、15总结526附录52附录152数据字典:52附录256附录359附录46413级软件工程专业3班数据库应用系统课程设计课程论文1需求分析需求分析是每个应用程序设计前必须的也是最重要的步骤,如果需求分析没做好,后期的工作可能算白费了。因为软件的设计就是为了服务用户,如果对用户的需求分析错误,那么最终设计的软件就不是用户所需要的。所以需求分析在软件开发周期中占有比较的的比重。并且贯穿软件开发始终。不能为了减少开发时间而缩短需求分析的时间。需求分析需要全面考虑用户的每个需求,有些用户没提到的需求也要从其他需求中提去出来。需求分析力求准确、完整、清晰、具体。为了更好的分析需求,需要设计很多图和表。包

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

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

5、不同的需求进行竞赛项目的查询操作,查看竞赛的报名情况,成绩等信息。图 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 概念设计/*阐述概念设计目标、任务和方法,重点介绍概念设计的内容。*/概念模型是现实世界到机器世界的一个中间层次

6、。概念结构设计时整个数据库设计的关键,它通过对用户需求进行综合、归纳与抽象,形成一个独立于具体数据库管理系统的概念模型。 数据库系统概论(王珊,萨师煊第五版)概念设计就是将需求分析得到的用户需求抽象为信息结构(即概念模型)。概念设计是在需求分析的基础上进行设计的,是把需求分析的成果转化为简单、清晰、易于理解的概念模型。概念模型中最主要的就是ER图。2.1.1 分E-R图建立阐述分E-R图建立的思想(以中层数据为切入点,按照分层次/分模块思想),用E-R模式描述。E-R图的建立以比赛为切入点。分为教师申请比赛,学院或教务处添加或总结比赛。学院或教务处审核比赛,学生报名参赛。教师总结比赛等模块2.

7、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联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式,则与该联系相连的各

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

9、连的各实体的码以及联系本身的属性均转换为关系的属性,个各实体组成关系的码或关系码的一部分。5. 具有相同码的关系模式可以合并。根据上面的转换原则得到的关系模式如下:学生信息(学号,姓名,性别,生日,电话,邮箱,专业,所在班级,年级,系统登录密码, 学号-姓名, 学号-性别, 学号-电话,学号-邮箱,学号-所在班级, 学号-年级, 学号-专业,学号-系统登录密码);教师信息(工号,姓名,性别,生日,电话,邮箱,所在学院,登录密码,职务, 备注,工号-姓名, 工号-性别,工号-生日,工号-电话, 工号-邮箱, 工号-所在学院, 工号-登录密码, 工号-职务);学院信息(学院名, 负责人工号, 学院

10、名-负责人工号);/教务处当做学院处理。专业信息(专业名称,所在学院, 专业名称-所在学院);赛事信息(赛事编号,赛事名称,赛事信息,比赛时间,赛事级别,主办方,负责人工号,报名开始时间,报名结束时间,赛事举办地点,赛事预算,赛事申请信息,赛事总结,赛事审核信息,赛事编号-赛事名称, 赛事编号-比赛时间,赛事编号-赛事级别,赛事编号-主办方,赛事编号-负责人工号,赛事编号-报名开始时间,赛事编号-报名结束时间,赛事编号-赛事举办地点,赛事编号-赛事申请信息,赛事编号-赛事总结,赛事编号赛事审核信息);竞赛报名信息及结果(赛事编号, 报名学生学号,指导老师, 报名学生成绩,报名学生排名,报名学生

11、备注,赛事编号+报名学生学号-报名学生学号,赛事编号+报名学生学号-指导老师,赛事编号+报名学生学号-报名学生成绩,赛事编号+报名学生学号-报名学生排名,赛事编号+报名学生学号-报名学生备注) 主码:赛事编号+报名学生学号;通知信息(通知编号,通知时间,通知发起者,通知内容, 通知编号-通知时间, 通知编号-通知发起者,通知编号-通知内容);学生通知(通知编号,通知对象学号);教师通知(通知编号,通知对象工号);2.2.2 关系模式规范化处理1. 对于学生信息关系模式, 姓名,性别,专业,生日,邮箱,手机号,年级,密码, 这些属性都是独立的不相互关联的,所以不存在依赖关系,那么处理学号与其他非

12、主属性的函数依赖外,就不存在其他函数依赖,也就不存在传递依赖了,所以满足三范式。2. 对于教师关系模式,与学生信息关系模式相同,所以也满足三范式。3. 对于竞赛信息关系,其中的非主属性互不相关,所以不存在传递关系。4. 对于竞赛成绩信息,他是由竞赛与学生的关系转换而来,非主属性互不依赖,所以也满足三范式。5. 对于通知信息,其中的非主属性互不相关,所以不存在传递依赖,所以满足三范式。6. 学生通知和教师通知是由实体联系转换而得到的关系,其特点类似于竞赛成绩所以也满足三范式。7. 学院和专业关系都只有两个属性,所以不可能存在传递依赖,所以满足三范式。2.2.3 用户子模式建立用户子模式的设计是根

13、据不同用户或局部应用的需求,结合具体关系数据库来生成多个视图。视图并不是真正存在的表,而是由基本表导出的表,是一个虚表。视图的建立对数据库来说意义重大。视图有以下几个方面的优势:1. 视图能够简化用户的操作。直接在视图上操作,比在表上操作更方便,因为直接在表上操作,可能需要用到,连接、嵌套查询等操作,如果直接在视图上操作,可能不需要这些操作。2. 视图使用户以多种角度看待同一数据。视图的建立没有想基本表那样多的约束,它可以根据用户的实际需求来建立表。比如说成绩信息,在基本表中应该是学号、比赛编号和成绩,但老师希望看到的是学生姓名和比赛成绩。这个就可以构成一个视图。3. 视图对重构数据库提够了一

14、定程度的逻辑独立性。意思是说如果数据库要重构,基本表的结构改变了,但由于视图的存在,如果之前有的操作是在视图上的,那么这些操作相关的代码就不用修改了。4. 视图能够对机密数据提供安全保护。针对不同用户建立不同的视图,使得不同用户只能看到数据表中的部分数据,可以有效防止数据泄露,数据被恶意修改。5. 适当利用视图可以更清晰地表达查询。如果之前建立好了视图,那么在查询的时候直接对视图进行查询语句会更加简单易懂。针对该数据库,可建立如下视图:1. 对于学生信息,学生,教师能看到学生信息表和教师信息表中除了密码以外的全部信息。所以针对学生信息表和教师信息表,建立一个包含除了密码以外的所有信息的视图。为了方便了解

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1