数据库设计样例—校运会管理系统.doc

。
项目案例（一）
——校运会管理系统
1需求分析
1.1 编写目的
使用该文档的使用成员为实现校运会管理系统的开发人员以及学校的运动会组织管理人员。
1.2 背景
项目名称：校运会管理系统
项目提出者：
项目开发者：项目开发小组
项目鉴定者：暂无。
项目开始时间：
1.3 定义
系统数据流程图的一些定义

1.4 目标
　　当学校运动会管理人员使用了《校运会管理系统》软件后，可以由计算机完成：运动员报名的自动核对；比赛时各种人员信息的查询、核对、更新、删除。
校运会管理系统用户分为两类：
普通操作员：只须具有初级的计算机操作能力，一般高中生以上经过稍稍培训都可胜任，只是负责比赛进行时一些简单数据的插入、更新、查询。
管理人员：这些人员应具备一定的数据库知识，不过只要了解就行，这些人员负责对数据库中重要数据及基本数据的更新，如对静态表的重新定义，普通用户的权限分配。
1.5 需求分析
1.5.1系统的功能需求
通过对运动会各个步骤、所需的各项信息等的分析，我们规定：
(1) 项目有个人项目、集体项目之分．
(2) 对于集体项目，我们并不关心具体参加比赛的运动员．在每一项集体项目中，每个学院的参赛人数不可超过限制的参赛人数，且必须是该学院的学生．
(3) 一个项目可有多名运动员参加，但一名运动员最多只能参加两项个人项目（用一个触发器实现），且只能属于一个学院．
(4) 一个项目可由多名裁判主持，每一个裁判在此项目中所担任的职务不同，且有主、副裁判之分．
(5) 在同一时间内可同时举行多项比赛，但是只能进行一项径赛比赛（用一个触发器实现）．
(6) 在同一时间内，一名裁判只能主持一项比赛、担任一个职务（用一个触发器实现）．但在不同的时间内，一名裁判可主持不同的项目、担任不同的职务．
(7) 一名运动员在同一时间内只能参加一项比赛（用一个触发器实现）．
(8) 在同一时间内，一个学院只能参加一项集体项目比赛（通过用一个触发器限制在同一时间内只能举行一项集体项目）．
(9) 在某一项目中，只有一个主裁判，其余都为副裁判．
(10) 一项个人项目可有多个同时破记录者，一名运动员同时破多项记录．一项集体项目可同时有多个破记录的学院，一个学院可同时破多项记录．
1.5.2 系统总体功能图

1.5.3系统流程图

1.5.4 实体与数据
通过对运动会各方面分析，运动会中包含的实体有学院、运动员（不包含集体项目中的运动员）、项目（集体项目和个人项目）、裁判、职务、奖励（集体项目奖励和个人项目奖励，名次为0表示破记录）、赛事类别（田赛、径赛、集体项目等）．集体项目奖励和个人项目奖励不同．包含的数据项分别如下：
(1) 学院编号，学院名称，上届运动会名次，历史最高名次，本次运动会总分，本次运动会名次等．
(2) 运动员编号，学号，姓名，性别，所属学院，班级等．
(3) 项目编号，项目名称，参赛者性别（男或女或不限）、每个学院限参赛人次，比赛时间，结束时间等．
(4) 裁判编号，姓名，性别等．
(5) 职务编号，职务名称（如计时员、测量员、记录员等），职务级别（主裁判和副裁判）等．
(6) 名次，奖励分数，奖励物品（如奖状等），奖励金额等．
(7) 赛事类别编号，赛事类别名称等．

实体之间的联系有：
(1) 学院与运动员之间（1：M）．
(2) 运动员、个人项目与个人项目奖励之间（1：M，1：1）．
(3) 学院、集体项目与集体项目奖励之间（1：M，1：1）．
(4) 赛事类别与项目之间．（1：M）
(5) 裁判、项目与职务之间．（M：N）l

通过以上分析，运动会数据库包含的模块有：
输入模块　主要是各种信息的输入，如学院信息、运动员信息、项目信息、比赛信息、奖励信息等．
输出模块　主要是各种查询结果的输出等。
2 概念设计
采用自底向上的方法．用E-R图表示各实体之间的联系。
2.1实体学院与运动员之间的联系

上述E-R图表示一个学院有多名运动员参加个人项目，一名运动员只能属于一个学院．
2.2运动员、个人项目和个人项目奖励之间的联系

上述E-R图表示一个项目可有多项不同的奖励（如第一名、第二名等的奖励不同）对于每一项奖励可在不同的项目中出现；一名运动员最多只能有两项个人项目奖励（此时p=0…2）,每一项奖励可有多名运动员获得；一名运动员最多能参加两项个人项目（此时m=1…2），一项个人项目可有多名运动员参加。
2.3学院、集体项目和集体项目奖励之间的联系

上述E-R图表示一个学院可获得多项集体项目奖励、参加多项集体项目，一项集体项目可有多个学院参赛、有多项不同的奖励，一项集体项目奖励可被多个学院获得、可在多项集体项目中出现。
2.4赛事类别与项目之间的联系

2.5裁判、项目、职务之间的联系

上述E-R图表示一名裁判在不同的时间内可主持多项比赛、担任多项职务，同一职务可被多名裁判担任、可出现在多项比赛中，一项项目可由多名裁判共同主持、可有多个职务（如计时员、测量员、记录员等）。
2.6 总E-R图
将上述分E-R全部合并，并化简的到如下的总E-R图（为简化画图工作，上述各实体中的属性 未画出，并把集体项目和个人项目合并为项目、集体项目奖励和个人项目奖励合并）：

上述E-R图中学院、项目和奖励之间的联系如上述３中的E-R图一样，运动员、项目和奖励之间表示的联系如上述2中的E-R图一样．
3 逻辑设计
本次设计的数据库在SQL Server 2000上实现，将概念结构设计中的E-R图转换成SQL Sever 2000支持的关系数据模型后，结合上述分析得到如下数据表：
3.1 关系设计
(1) 运动员表（运动员编号,运动员姓名,性别,联系方法,班级编号）;
(2) 班级表（班级编号,班级全称,班级总得分）;
(3) 项目表（项目编号,项目名称, 性别限制，集体项目人数,开始时间,结束时间,田径赛区分,每班最大人数,已选人数,规则编号,场地编号）;
(4)（联）记录表（项目编号,项目名称,运动员编号,运动员姓名,班级编号,班级描述,运动会名,田径赛区分,成绩）;
(5)（静）规则表（规则编号,规则名称,文本路径）;
(6)（静）工作人员表（工作人员编号,工作人员姓名,单位,运动会职务）;
(7)（静）场地表（场地编号,场地名称,具体地址）;
(8)（静）器材表（器材编号,器材名称,存放简介）;
(9)（联）项目人员表（项目编号,工作人员编号）;
(10)（联）项目器材表（项目编号,器材编号）;
(11)（联）运动员成绩表（项目编号,运动员编号,田径赛区分, 比赛性质，小组号，跑道号，
成绩,名次）;
(12)（联）团体赛成绩表（项目编号,班级编号,田径赛区分, 比赛性质，小组号，跑道号，成绩,名次）;
(13)（联）班级总分表（班级编号，总分，总分排名）；
3.2 约束的说明:
(1)每次运动会报名时，记录一个运动员信息需有几个自动处理过程：
①“运动员表”做删除操作时应先判断该运动员是否已经有成绩,有的话则不充许做删除操作，并回退事务并做出相应的用户提示。否则应判断相应的“运动员成绩表”中有没有该运动员的的记录，有的话一同删除。
②“运动员表”做插入、更新操作时应判断要插入、更新的运动员信息是否已经存在也就是对运动员的姓名和班级进行判断（具体判断用来报学生配合报名管理者来实现，不由机算机控制，机算机只提供相关信息）。有的话不再插入，并回退事务并提示用户，运动员若有相同的姓名则应在性名后加a\b\c等处理。
③“运动员成绩表” 删除操作时应判断相应的“运动员表”中有没有相应的数据，有的话一同删除。
④“集体项目人数” 的特别触发：一方面用来确定该项目是否为集体项目，另一方面用来确定集体项目的人数要求，人数方面的要求主要是为了更方便地生成秩序册（因为项目的具体规定在“规则表中”，而规则表是用文本的方式存储的，不方便查询）。
⑤同一场地的两个不同项目，开始时间与结束时间之间的时间段不应相交。
⑥每一个运动员报名，都应该能够判断否其所在班级的报该项目的人数是否到了人数限度。及对已选人数做相应的增减操作。

(2)每次有新成绩更新时，有几个自动处理过程
①每次更新一个决赛成绩时，判断“记录表”中的记录是否被打破，是则更新之。
②每次生成一个成绩时，相应地修改班级总分表中的相关数据。
③名次可考虑自动生成，当然也可以跟据系统计员的相关资料直接输入。

(3)各种“意义＋流水号”的编号可以考虑由系统生成，而且证明确是可以实现的。

4 物理设计
(1)将本届和历届运动会数据进行分开存放(可根据具体软硬件限制选择“完全记录形式”及“比赛要素形式”
① 完全记录形式：把所有今年的表都存入到对应的历届表中)
②比赛要素形式：用于存放“班级表”、“运动员表”及“运动员成绩表”
(2)将静态表与动态表分开存放
(3)将备份数据与现行数据进行分开存放
(4)在，“项目表”，“项目器材表”这几个表上查询操作比较频繁，而相对更新操作比较少，于是考虑在这几个表上查询常用列上加上索引；
对于“运动员表”，“运动员成绩表”，“团体赛成绩表”这几个表，虽然在“报名系统”阶段有许多更新操作，但在进入后几个阶段后几乎就没有更新了，而更多的是查询，所以考虑在这几个表的查询常用列上加上索引，而具体的索引加入时可考虑由应用程序控制。

THANKS !!!

致力为企业和个人提供合同协议，策划案计划书，学习课件等等
打造全网一站式需求

欢迎您的下载，资料仅供参考

-可编辑修改-