湖南省大学生程序设计竞赛系统设计
背景：本人一直学习DBA数据库维护技能，出于同学需要，充当数据库设计开发，第一次与同学一起完成了一套小型管理系统的设计开发。自己充当数据库设计者，记录下来自己作为留念。 （相关的UML图已省略）
一、 引言
1.1项目背景
湖南省每年都要举行大学生程序设计竞赛，每次竞赛时，由组委会发布竞赛要求，各大高校分别对自己学校的队伍进行报名。
传统的以人工方式为主进行该项赛事的报名工作，每年将耗费大量的人力物力，同时还伴随着各种突发问题。如果通过计算机网络将竞赛组委会和各大高校联系在一起，使用网络发布竞赛信息，提供报名和查看、下载成绩排名的渠道，利用系统在比赛当日随机产生座位序号，将为湖南省参与这项赛事的老师和同学提供极大的便利，并且可保证比赛的公平性，可避免诸多问题。
1.2 项目计划
|
时间 |
任务 |
里程碑 |
|
2016年12月19日 |
完成需求分析和概要设计，开始任务分解 |
需求分析 概要设计 |
|
2016年12月20日 |
根据任务分解，分工实施 |
数据库设计 详细设计 |
|
2016年12月21日 |
实现 |
主体编码任务 |
|
2016年12月22日 |
实现 |
全部编码任务 |
|
2016年12月23日 |
调试与自测 |
完成测试 |
二、需求分析
2.1 目的
根据湖南省大学生程序设计竞赛的实际管理模式，进行需求分析工作。为下一阶段的设计与开发提供依据。
2.2 具体需求
2.2.1 用户需求
该平台的用户根据其业务可划分为2类，一是参与湖南省大学生程序设计竞赛的各大高校代表，二是负责该项赛事的组委会。
2.2.2 系统功能性需求
系统的功能需求主要包括以下几个方面：
（1） 高校用户可以注册、登录
（2） 高校用户可以浏览比赛详情
（3） 高校用户可以进行网上报名
（4） 高校用户可以查看、下载报名信息表
（5） 高校用户可以查看、下载比赛成绩表
（7） 竞赛组委会用户可以发布、更新比赛详细信息
（8） 竞赛组委会用户可以发布、修改报名要求（包括报名开始、截止日期）
（9） 竞赛组委会用户可以查看各大高校报名信息
（10） 竞赛组委会用户可以对各大高校比赛座位进行随机分配
（11） 竞赛组委会用户可以上传、下载各大高校的成绩表
（12） 竞赛组委会用户可以审核用户的认证信息，确定是否通过
满足上述功能需求的系统应主要包括以下三个模块：
（1） 信息查询模块：信息查询模块主要实现用于高校用户对比赛详情和自身信息的查询。
（2） 基本业务处理模块：基本业务处理模块主要用于实现高校用户合法注册、登录以及网上报名和竞赛组委会用户审核认证信息，管理高校用户，随机分配座位。
（3） 数据库管理模块：数据库管理模块主要实现系统
2.2.3 条件和约束
（1） 高校用户注册时必须要提供认证材料，只有其材料被审核通过之后，其
账号才被设置为合法，账号合法之后才能进行登录。
（2） 竞赛组委会对高校提交的认证审核进行审核后，以邮件的形式将审核结
果发送到该高校提供的邮箱上。
（3） 高校用户报名队伍的数目必须在组委会规定的上限之内。
（4） 高校队伍每队人数必须在组委会规定的上限之内。
（5） 报名渠道必须在竞赛组委会限定的起始日期和截至日期内才开放。
（6） 报名信息表应显示所有高校名字以及该高校所有队伍的报名信息。
2.1.3 用例图及用例规约
根据功能需求绘制简单的用例图，并且对较复杂的用例填写用例规约。
图1 高校用户用例图
图2 组委会用户用例图
|
用例名称 |
高校用户注册 |
|
|
参与者 |
高校用户 |
|
|
假设 |
高校用户的注册信息不在系统中 |
|
|
前置条件 |
高校用户的ID和学校名字已保存在系统中 |
|
|
主要事件流 |
参与者动作 |
系统响应 |
|
1、 用户选择学校 2、 用户填写基本信息，其中包括邮箱地址 3、 用户上传相关证明材料的扫描件 4、 提交所有信息 |
1、 系统接收信息 2、 系统保存信息 |
|
|
异常事件流 |
参与者动作 |
系统响应 |
|
1、 用户未选择学校 2、 用户未填写邮箱地址或邮箱地址不准确 3、 用户账号、密码不合法 4、 证明材料上传失败 |
1、 返回未选择学校提示，注册失败 2、 返回未填写邮箱或者邮箱地址不正确提示，注册失败 3、 返回用户名、账号不合法提示，注册失败 4、 返回证明材料上传失败提示，注册失败 |
|
|
后置条件 |
注册请求成功提交，系统保存信息，等待进一步审核 |
|
|
用例名称 |
登录 |
|
|
参与者 |
高校用户、竞赛组委会用户 |
|
|
假设 |
高校用户和竞赛组委会用户的注册信息已在系统中 |
|
|
前置条件 |
高校用户已通过认证审核并被系统识别和授权 竞赛组委会用户已被系统识别和授权 |
|
|
主要事件流 |
参与者动作 |
系统响应 |
|
1、 用户输入用户名和密码 2、 用户提交登录请求 |
1、 系统匹配用户名和密码 |
|
|
异常事件流 |
参与者动作 |
系统响应 |
|
1、 未输入用户名 2、 用户名不存在 3、 未输入密码 5、 密码不存在 |
1、 提示用户名和密码不能为空，登陆失败 2、 提示用户名或密码不正确，登陆失败 |
|
|
后置条件 |
登录成功，系统进入主界面 |
|
|
用例名称 |
审核用户认证信息 |
|
|
参与者 |
组委会用户 |
|
|
假设 |
组委会用户登录成功 |
|
|
前置条件 |
用户审核信息已被成功保存至系统 |
|
|
主要事件流 |
参与者动作 |
系统响应 |
|
1、 查看待审核的用户注册信息 2、 查看用户基本信息 3、 下载证明材料扫描件 4、 确定该认证信息审核成功或者失败 |
1、 查询并显示待审核的用户注册信息 2、 查找提交注册请求的高校用户的邮箱地址 3、 将审核结果发送至邮箱 |
|
|
异常事件流 |
参与者动作 |
系统响应 |
|
1、用户未下载或查看证明材料扫描件 |
1、系统提示用户下载或查看证 明材料扫描件，返回无法审核提示
|
|
|
后置条件 |
成功审核认证信息，并将结果发送至提交认证者的邮箱 |
|
|
用例名称 |
报名 |
|
|
参与者 |
高校用户 |
|
|
假设 |
高校用户已成功登陆并被识别和授权 |
|
|
前置条件 |
高校用户本次报名的队伍还没有达到上限 报名通道已经开放 |
|
|
主要事件流 |
参与者动作 |
系统响应 |
|
1、 填写队伍名称 2、 填写队员基本信息 3、 填写教练基本信息 4、 点击报名请求 |
1、 系统查询该校已报名的队伍数 2、 将查询到的队伍数与队伍上限进行比较 3、 查询队伍名称是否已在系统中存在 4、 保存队员基本信息 5、 保存教练基本信息 |
|
|
异常事件流 |
参与者动作 |
系统响应 |
|
1、 未填写队伍名称 2、 所填写的队伍名称已有其他队伍使用 3、 队员信息填写不完善 4、 教练信息填写不完善 5、 在队伍达到上限后再次提交报名信息 |
1、 返回队伍已上限提示 2、 返回队伍名称已被使用提示 3、 返回未填写队伍名称提示 4、 返回队员信息填写不完善提示 5、 返回教练信息填写不完善信息 |
|
|
后置条件 |
报名成功，将报名信息保存到系统中 |
|
|
用例名称 |
下载报名表 |
|
|
参与者 |
高校用户 |
|
|
假设 |
高校用户已成功登陆并被识别和授权 |
|
|
前置条件 |
高校用户被系统审核通过的报名队伍至少有一支 |
|
|
主要事件流 |
参与者动作 |
系统响应 |
|
1、 提交查看报名表请求 2、 提交下载报名表请求 |
1、 查询该高校用户所有报名队伍 2、 将所有信息显示到报名表上 3、 下载报名表 |
|
|
异常事件流 |
参与者动作 |
系统响应 |
|
无 |
无 |
|
|
后置条件 |
成功下载报名表 |
|
|
用例名称 |
查看成绩排名 |
|
|
参与者 |
高校用户、组委会用户 |
|
|
假设 |
高校用户和组委会用户已成功登陆并被识别和授权 |
|
|
前置条件 |
比赛成绩已成功导入系统 |
|
|
主要事件流 |
参与者动作 |
系统响应 |
|
1、 用户选择查看队伍成绩排名表 2、 用户点击下载队伍成绩排名表 3、 用户选择查看学校成绩排名表 4、 用户点击下载学校成绩排名表 |
1、 系统生成队伍排名表 2、 系统下载队伍排名表 3、 系统生成学校排名表 4、 系统下载学校排名表 |
|
|
异常事件流 |
参与者动作 |
系统响应 |
|
无 |
无 |
|
|
后置条件 |
成功为每个参赛队伍分配座位 |
|
2.1.4 系统非功能性需求
（1） 系统能够同时让20个以内的人使用。
（2） 系统的反应时间不超过6秒
（3） 系统能7*24小时连续运行
三、 概要设计
3.1 目的
根据湖南省大学生程序设计竞赛管理平台的需求分析，定义系统的主要功能模块及相互之间的联系，并定义模块的技术实现方法。定义平台的机构，确定子系统，I/O接口和处理模式。为下阶段详细设计和代码的编写提供基础。
3.2 总体设计
3.2.1 总体设计原则
（1） 系统要有稳定可靠的性能
（2） 系统要有人性化的设计界面，操作简单易上手
（3） 界面要与数据处理分离，从而能够较灵活的根据实际需求修改系统
（4） 系统应充分考虑实际运用时会出现的问题，避免错误的发生，再出现异常后能给用户明确的提示。
3.2.2 基本设计概念
系统由UI层，逻辑层，数据库三层构成。
其中UI层要尽可能简单，只处理界面控件的响应和显示，避免数据的处理。设计时要尽量模块化，不同功能的页面要分开，减少不同控件之间的耦合性。业务逻辑模块要庞大，它提供各种处理的方法，接受来自UI的数据请求，调用数据库访问模块进行处理，并将处理结果返回给UI层。数据库处理模块封装了对数据库的操作，这里采用Oracle 11g数据库。
3.2.3处理流程
系统根据UI的请求调用业务逻辑层的方法，业务逻辑层调用数据库访问模块进行处理并将结果返回给UI。
3.3 模块设计
3.3.1 界面模块设计
（1） 注册界面：选择高校按钮；账号、密码、邮箱输入框；图片上传域；提交认证控件；
（2） 登录界面：账号、密码输入框；账号类型选择框（竞赛组委会用户或者高校用户）
（3） 组委会管理主界面：主页；比赛详情控件；报名管理控件；
（4） 高校用户主界面：主页；比赛详情控件；报名控件；
（5） 比赛详情界面：比赛详情；
（6） 高校用户报名界面：队伍名输入框；队伍人数选择框；队员信息输入框；教练信息输入框；
（7） 高校用户报名表界面：高校所有队伍信息；
（8） 组委会用户报名管理界面：所有报名的高校队伍信息；
（9） 成绩表上传下载界面：上传、下载控件；
（10） 随即座位分配界面：所有参赛队伍的座位分配情况；
3.3.2 功能模块设计
3.3.2.1注册
高校用户选择高校，输入账号、密码和邮箱地址，并且上传该高校的相关信息的扫描件，提交认证请求；系统处理后保存信息；竞赛组委会查询认证请求，审核后提交是否同意该认证通过。若通过系统修改该账户权限为合法。将结果以邮箱的形式告知。
3.3.2.2登录
用户输入账号、密码，选择账号类型，系统匹配所有信息，若合法则跳转到用户相应的主界面，若不匹配则返回相应的错误信息。
3.3.2.3 发布比赛详情
仅对竞赛组委会用户开放，竞赛组委会用户填写比赛详情，系统保存详情。
3.3.2.4 查看比赛详情
用户点击查看比赛详情，系统查询详情并显示。
3.3.2.4更新报名要求
组委会用户设置报名的开始和截至时间；
3.3.2.5用户报名
在指定的时间区域内开放，开放期间高校用户填写报名队伍信息，队员信息，以及教练信息，系统查询该校已报名队伍，若队伍数低于上限，则受理该报名请求，将报名信息保存；否则返回队伍已上限提示。
3.3.2.6查看报名表
系统查询出该校所有报名队伍信息，以网页表格的形式显示，支持打印及导出。
3.3.2.7座位号随机分配
系统查询出所有报名队伍、所有机房号以及对应的座位数，利用公式随机为队伍分配座位。
3.3.2.8成绩表上传
仅对组委会用户开放，可以上传EXCEL成绩表。
3.3.2.9成绩表下载
对所有用户开放，可以下载EXCEL成绩表。
四、详细设计
4.1目的
根据湖南省大学生程序设计竞赛管理平台的概要设计，进一步说明系统的架构，各个功能模块的处理流程，以及设计所需要用到的数据库，为实现编码提供依据。
4.2系统总体结构设计
在湖南省大学生程序设计竞赛管理平台中，系统的结构设计为三层架构，其中entity包存放实体类；action包提供用户服务，为获取数据，显示信息提供接口；tools为工具包，用以连接oracle数据库和修改编码方式，dao包为业务服务包，它是用户action包和数据库之间的桥梁，提供用户业务的各种操作。
总体结构的包图如下图3所示。
4.3系统数据库设计
School（高校用户表）
|
序号 |
字段 |
字段类型 |
是否主键 |
是否为空 |
是否外键 |
描述 |
|
1 |
Sid |
Number(4) |
Y |
|
|
学校编号 |
|
2 |
Sname |
Varchar2 |
|
|
|
学校名字 |
|
3 |
check_status |
Int |
|
|
|
审核情况，用0、1表示，默认为0，0表示未通过，1表示通过 |
|
4 |
account |
Varchar2 |
|
|
|
账号 |
|
5 |
pwd |
Varchar2 |
|
|
|
密码 |
|
6 |
|
Varchar2 |
|
|
|
邮箱地址 |
|
7 |
Photo_path |
char |
|
|
|
上传的图片路径 |
Manager（竞赛组委会用户）
|
序号 |
字段 |
字段类型 |
是否主键 |
是否为空 |
是否外键 |
描述 |
|
1 |
Username |
Varchar2 |
|
|
|
账号 |
|
2 |
Password |
Varchar2 |
|
|
|
密码 |
Team（队伍）
|
序号 |
字段 |
字段类型 |
是否主键 |
是否为空 |
是否外键 |
描述 |
|
1 |
Tid |
Number(2) |
Y |
|
|
学校名字 |
|
2 |
Tname |
Varchar2 |
|
|
|
|
|
3 |
Number_of_teams |
number |
|
|
|
队伍人数 |
|
4 |
Mentor |
Varchar2 |
|
|
|
指导老师 |
|
5 |
Sid |
Number(4) |
|
|
Y |
学校编号 |
Team_message（队员信息）
|
序号 |
字段 |
字段类型 |
是否主键 |
是否为空 |
是否外键 |
描述 |
|
1 |
Name |
Number(2) |
Y |
|
|
姓名 |
|
3 |
ID |
char |
Y |
|
|
身份证号 |
|
4 |
Coat_size |
char |
|
|
|
上衣尺码 |
|
5 |
Tid |
Number(2) |
|
|
|
队伍编号 |
|
6 |
Sid |
Number(4) |
|
|
Y |
学校编号 |
Mashine_room（机房）
|
序号 |
字段 |
字段类型 |
是否主键 |
是否为空 |
是否外键 |
描述 |
|
1 |
Mid |
Varchar2 |
Y |
|
|
机房编号 |
|
2 |
number_of_seats |
Number(3) |
|
|
|
座位数 |
Race_seat（比赛座位）
|
序号 |
字段 |
字段类型 |
是否主键 |
是否为空 |
是否外键 |
描述 |
|
1 |
Mid |
Varchar2 |
Y |
Y |
|
机房编号 |
|
2 |
Number_of_seats |
Number(3) |
Y |
|
|
座位号 |
|
3 |
Tid |
Number(2) |
|
Y |
|
队伍编号 |
Race_mark（比赛成绩）
|
序号 |
字段 |
字段类型 |
是否主键 |
是否为空 |
是否外键 |
描述 |
|
1 |
Tid |
Number(2) |
Y |
|
Y |
队伍编号 |
|
2 |
Mark |
Number(4) |
Y |
|
|
座位号 |
|
3 |
Time |
Number(4) |
|
|
Y |
比赛年份 |
Time_limit（时限表）
|
序号 |
字段 |
字段类型 |
是否主键 |
是否为空 |
是否外键 |
描述 |
|
1 |
Start_time |
Date |
|
|
|
开始时间 |
|
2 |
Stop_time |
Date |
|
|
|
截至时间 |
4.4 系统静态模型设计
获得系统的基本需求用例以后，通过分析系统对象的各种属性，创建系统的静态模型。
4.4.1参与者类
确定系统参与者的属性。根据属性，可以建立参与者，其初步类图模型如图4所示。
图4 参与者的基本类图
4.4.2实体类
确定在系统当中的主要业务实体类，这些类通常需要在数据库中进行存储。这些业务实体的类图如下图5所示。
图5 实体类图
4.4.3 业务逻辑类
根据系统的功能，分别封装如下几个处理业务逻辑的类，具体如图6所示。
图6 业务逻辑类图
4.4.4 控制类
本系统采用六个类控制系统前后端的交互，具体如下图7所示。
图7 控制类图
4.4.5 工具类
本系统使用的是Oracle数据库，所以一个工具类，用来连接Oracle数据库。其类图如图8所示。
图8 工具类图
4.5 系统动态模型设计
上述的类图只是简单描述了类里面包含的内容以及类与类之间的关系，若要详细描述系统功能的具体实现过程，可用交互作用图、状态图、活动图来描述。
在湖南省大学生程序设计竞赛管理平台的系统中，通过分析得出以下几种交互行为。
（1） 高校用户进行注册
（2） 高校用户进行登录
（3） 高校用户报名
（4） 高校用户查看/下载报名表
（5） 高校用户下载成绩表
（6） 竞赛组委会用户登录
（7） 竞赛组委会用户审核高校认证信息
（8） 竞赛组委会用户查看报名信息
（9） 竞赛组委会用户随机分配座位
（10） 竞赛组委会用户更新竞赛详情
（11） 竞赛组委会用户上传/下载成绩表
4.5.1创建序列图
根据系统的用例模型，还可以通过对象之间的相互作用来考察系统对象的行为，以相互作用的一组对象为中心进行考察，对于一些较为复杂的处理流程建立序列图。
4.5.1.1 高校用户提交注册信息
（1） 高校用户在注册页面选择高校，输入账号、密码，上传相关材料扫描件并提交；
（2） 界面检测信息是否完善，账号密码格式是否正确，若不完善返回信息不完善提示，若账号密码不合法，则返回账号或者密码不合法提示
（3） 界面检测通过后系统验证该学校完整信息是否已经存在，若存在返回已注册提示
（4） 若不存在则保存所有信息，返回注册信息已成功提交提示。
其序列图如图9所示。
图9 高校用户提交注册信息序列图
4.5.1.2 竞赛组委会用户处理认证信息
（1） 竞赛组委会用户通过认证信息查询界面查询认证信息
（2） 系统从数据库查询出认证信息返回给查询界面
（3） 竞赛组委会用户深刻材料后提交审核结果
（4） 系统处理审核结果，修改账户权限
其序列图如图10所示
图10 组委会用户处理认证序列图
4.5.1.3 高校用户报名
（1） 高校用户在报名界面填写队伍名称、选择队伍人数，填写队员和教练信息并提交。
（2） 报名界面初步校检填写信息是否合法、完善
（3） 校检成功后将数据发送至相应的servlet处理
（4） Servlet接收参数，调用dao层相关函数
（5） Dao层查询数据库中该校已报名的队伍数，并与队伍上限比较
（6） 如果达到上限，返回队伍上限提示
（7） 若队伍没有达到上限，将队伍信息保存至数据库
（8） 将队员信息保存至数据库
其序列图如图11所示
图11 高校用户报名序列图
4.5.1.4 生成报名表
（1） 高校用户发起查看报名表请求
（2） 系统查询该校所有报名队伍
（3） 系统显示根据队伍从队伍表和队员信息表查询所有相关信息
（4） 系统以固定的表格的形式显示信息
其序列图如12所示
图12 生成报名表序列图
4.5.1.5 随机分配座位
（1） 竞赛组委会用户在分配座位界面发起座位分配请求
（2） 系统查询机房数、每个机房座位数、队伍数
（3） 系统为查询出的座位依次随机分配队伍，知道所有队伍都被分配为止
（4） 将分配情况存入数据库
（5） 从数据库查询出座位分配情况
其序列图如图13所示。
图13 随机分配座位序列图
4.5.2状态图
对于本系统有明确类型转换的类进行建模时用状态图。本系统中有明确类型转换的类是高校用户类。
（1） 高校用户提交注册申请时，填写相关信息和提交材料等待竞赛组委会的审核。
（2） 由竞赛组委会用户审核待审核的账号，被成功确认后账号为可用
（3） 如果学校改名或者退出该项赛事，竞赛组委会用户删除该账号
其状态图如图14所示。
图14 高校用户账号活动图
4.6创建系统的部署模型
前面的静态模型和动态模型都是按照逻辑的观点对系统进行概念建模，本文采用部署图对系统进行实现结构的建模。
在本系统中，系统包括四种节点，分别是：数据库节点，由一台数据库服务器负责数据的存储、处理等。系统服务器节点，用于处理系统的业务逻辑。客户端浏览器节点，用户通过客户端登录系统并进行操作。还可以加入打印机节点，用来打印报名表，成绩表等。其部署图如图15所示。
图15 系统部署图
——————————————————————————————————————————
具体数据库设计如下：
学校（学校编号 pk，学校名称，审核情况，账号，密码，邮件,照片路径） [审核情况用0,1表示，默认为0,0表示为提交注册请求，1表示已经审核通过]
队伍（学校编号 fk，队伍编号 pk，队伍名称，队伍人数，指导老师）
队员信息表（学校编号 fk, 队伍编号 fk,姓名,身份证号 pk,上衣尺码）
机房（机房编号 pk,座位数）
比赛座位（ 队伍编号 fk, 机房编号 fk，pk，座位号 pk）
比赛成绩（队伍编号 fk，成绩，时间）
时限表（开始时间，截止时间）
管理员（账号，密码）
说明：fk代表外键 pk代表主键
——————————————————————————————————————————————————
表结构：
school(sid number(4),sname varchar2(400 char) not null, check_status number(1),accountant varchar2(20 char),pwd varchar2(20 char),email varchar2(30 char),photo_path varchar2(800 char))
team(sid number(4),tid number(2),tname varchar2(400 char),number_of_teams number(2),mentor varchar2(400 char))
team_message(sid number(4),tid number(2),id_number varchar(20),name varchar(30),coat_size varchar2(6 char))
machine_room(mid varchar2(400 char),number_of_seats number(3))
race_seat(tid number(2),mid varchar2(400 char),number_of_seats number(3))
race_mark(tid number(2),mark number(4),time number(4))
time_limit(start_time date,stop_time date)
manager(username VARCHAR2(20 CHAR), password VARCHAR2(20 CHAR))
——————————————————————————————————————————————————
代码实现：
--学校表
create table school(sid number(4),sname varchar2(400 char), check_status number(1) default 0 check( check_status in(0,1)),accountant varchar2(20 char)unique,pwd varchar2(20 char),email varchar2(30 char),photo_path varchar2(800 char),
constraint pk_t_school primary key(sid));
-- 序列_1 （序列与触发器实现school表中sid字段的自动增长）
create sequence shool_sid_autoinc
minvalue 1
maxvalue 9999999999999999999999999999
start with 1
increment by 1
nocache;
--触发器_1 （序列与触发器实现school表中sid字段的自动增长）
create or replace trigger insert_shool_sid_autoinc
before insert on school
for each row
begin
select shool_sid_autoinc.nextval into :new.sid from dual;
end;
/
--队伍表
create table team(sid number(4),tid number(2),tname varchar2(400 char),number_of_teams number(2),mentor varchar2(400 char),constraint pk_t_team primary key(tid),constraint fk_t_school01 foreign key(sid) references school(sid));
-- 序列_2
create sequence team_tid_autoinc
minvalue 1
maxvalue 9999999999999999999999999999
start with 1
increment by 1
nocache;
--触发器_2 （序列与触发器实现school表中sid字段的自动增长）
create or replace trigger insert_team_tid_autoinc
before insert on team
for each row
begin
select team_tid_autoinc.nextval into :new.tid from dual;
end;
/
--队员信息表
create table team_message(sid number(4),tid number(2),team_name varchar2(400 char),id_number varchar2(18),coat_size varchar2(6 char),constraint pk_t_team_message primary key(id_number),constraint fk_t_school0 foreign key(sid) references school(sid),constraint fk_t_team04 foreign key(tid) references team(tid));
--机房
create table machine_room(mid varchar2(400 char),number_of_seats number(3),constraint pk_t_machine primary key(mid));
--比赛座位
create table race_seat(tid number(2),mid varchar2(400 char),
number_of_seats number(3),constraint pk_t_race_seat primary key(mid,number_of_seats),
constraint fk_t_team02 foreign key(tid) references team(tid),
constraint fk_t_machine_room02 foreign key(mid) references machine_room(mid));
--比赛成绩
create table race_mark(sid number(4),tid number(2),mark number(4),time number(4),
constraint fk_t_team03 foreign key(tid) references team(tid));
--时限表
create table time_limit(start_time date,stop_time date);
--管理员
create table manager(username VARCHAR2(20 CHAR), password VARCHAR2(20 CHAR));
OK，转载请标明出处。
