背景：本人一直學習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	email	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，轉載請標明出處。