淺析考試系統的數據庫設計與實現

劉錦培

?

淺析考試系統的數據庫設計與實現

劉錦培1,2

1.福州大學數學與計算機科學學院；2.福建師范大學信息技術學院

數據庫的應用設計在軟件開發中的應用日趨廣泛，它是數據庫應用系統開發生命周期中的重要一環和系統開發成敗的決定性一步。該文通過“考試系統”實例，深入分析數據庫設計的基本原則和相關技巧。

數據庫設計 主外鍵 檢索 數據字典

數據庫設計是指對于一個給定的應用環境，構造最優的數據庫模式，建立數據庫及其應用系統，有效存儲數據，滿足用戶信息要求和處理要求。本文對數據庫應用設計介紹以下幾個方面內容：

1 主外鍵的使用

數據庫中的主鍵是為了使記錄能惟一標識，外鍵用來關聯表與表之間的聯系，主鍵和外鍵是把多個表組織為一個有效的關系數據庫。可以通過主鍵和外鍵來了解數據庫的設計架構，因此就出現以數據庫為驅動的開發方式。開發人員根據數據庫的設計和流程順序開發程序，軟件設計人員只需嚴格控制數據庫的設計方向即可控制開發人員的開發過程。目前多數ERP或MIS系統都是按照這種模式進行，因為系統本身的特點就是過程化的，數據庫驅動方式就是一種過程化的開發方式，也是一種較為簡捷快速的開發方式。

這里，通過“考試系統”中的試題管理模塊來體現主外鍵的使用。試題編號作為惟一標識來標識每道試題，而試題中的試題選項不該與試題放在同一張表中，而是通過另一張試題選項表來管理，此時試題選項表中的試題編號就要外鍵關聯試題表中的試題號，試題選項表再通過試題編號和其自身的選項編號來組合起來作為主鍵惟一標識，詳細表設計如下：

Create table T_Subject(

SubjectID int,

Descriptions text

Primary key(SubjectID))

Create table T_SubjectOption(

SubjectID int,

OptionID int,

Descriptions text

Primary key(SubjectID,OptionID),

Foreign key(SubjectID) references T_Subject(SubjectID))

通過以上表設計，可以保證在試題選項表T_Subject- Option中的試題號都可以在試題表T_Subject中找到，體現了數據的相互依賴關系，同樣通過這樣的表結果可以看出試題表與試題選項表之間的關系。

2 數據字典的設計

數據字典（Data Dictionary）是一種用戶可以訪問的記錄數據庫和應用程序元數據的目錄。其特點是供人查詢對不了解的條目的解釋，數據量基本有限，在軟件中用于搭配其他模塊的屬性選擇，比如“考試系統”中安排考試的時候下拉選擇年級、專業、班級等字典信息，常規的設計方法是每個屬性設計一張字典表，如：

年級表

Create table T_Grade(

GradeID char(10),

GradeName varchar(100),

Primary key(GradeID))

專業表

Create table T_Major(

MajorID char(10),

MajorName varchar(100),

Primary key (MajorID))

此時只需對這些數據字典表進行編輯即可，但是這樣的設計還會存在些問題，這里專業代碼MajiorID是主鍵，不允許重復，且一旦被其他模塊選中后，則不允許再被修改，在實際軟件使用過程中經常會有需要修改鍵值屬性的時候，比如“網絡系統管理”這個專業的專業代碼原來是“wlxtgl”，軟件經使用后發現代碼太長，不方便用戶記憶使用，需要將其縮短為wg,而按照以上字典設計就無法再進行修改代碼。

當然，數據庫中可以將這些關聯表的外鍵設置級聯更新，實現專業代碼更新，其他有關聯的模塊都級聯更新過來，可想而知，當數據量少的時候級聯更新沒問題，當數據量大的時候，級聯更新就變得很慢，會造成極大的資源浪費，而且在編輯數據字典時，主鍵的重復判斷也不好處理，有什么方法可以解決這些問題呢？不妨看如下表設計結構：

Create table T_Major(

MajorID int identity,

MajorCode char(10) unique,

MajorName varchar(100),

Primary key(MajorID))

以上設計是將主鍵用自動增長類型來實現，由數據庫來控制表中記錄的惟一性，此時程序就無需擔心表記錄的重復，而專業編號由另一個屬性MajorCode來表示，且該屬性設置成unique（惟一），在其他模塊關聯專業的主鍵MajorID，并不關聯MajorCode，程序可以通過視圖來讀取MajorCode，這樣就可以實現專業代碼允許用戶修改（即使專業代碼已被其他模塊關聯使用），似乎這樣的表結構設計已經滿足了我們數據字典的要求，編程人員也很方便實現，這樣的設計結構并沒有真正發揮數據字典的特點。

上文提到，數據字典的數據特點是數據量少（相對其他模塊數據而言數據量相對少很多），屬性比較單一，一般只有主鍵和值組成。要是按照以上設計方法就會導致每個字典數據都要創建一張表，而且表中的記錄就幾十上百。例如“考試系統”中的專業表，一個學院乃至一個學校，最多也就上百個專業，用一張表來存儲較為浪費，浪費些磁盤空間沒關系，問題是實際軟件中數據字典會非常多，從而就得創建很多表來管理數據字典。并且有一點非常被動的就是，當你要添加一個數據字典的時候，就要再添加一張表來支持。比如在財務軟件中經常需要添加字典數據，要是按照這樣的方法來設計數據字典的話，那數據庫中會有百張表都是數據字典，這會給開發人員就會帶來極大的不便。綜合以上分析，得出的結論就是得想辦法將多張數據字典表給合并到一個地方，統一來管理。由于數據量并不是很大，合并后的數據量對現有的數據庫軟件來說也不會有太大壓力，可以考慮將多個數據字典表合并成一張表來處理，具體設計如下：

Create table T_DataDictionary(

DataDictionaryID int identity,

DataDIctionaryType char(10),

DataDictionaryCode char(10 ) unique,

DataDictionaryName varchar(100),

Primary key(DataDictionaryID))

在DataDictionaryType中存儲的就是數據字典的類型，比如“考試系統”中數據字典類型有：學期（Term）、年級（Grade）、專業（Major）、班級(Class)等等。在此數據字典的設計似乎可以告一段落，但實際軟件開發過程中遠遠不夠，數據之間會有復雜關系，比如年級與專業的關系，一個年級有那么多個專業，不同年級下的專業有可能不大相同，那在設計數據字典的時候怎么保證數據字典之間的關系呢？而且在實際使用過程中關系有可能嵌套，比如一個年級下有多個專業，一個專業下又有多個班級，難道我們要再通過兩張表來記錄他們之間的關系嗎？要是這樣的話，那關系多的話，豈不是關系表又越來越多，又回到了之前字典表太多的問題上？這樣設計固然可用，但并不科學，有沒有辦法能夠實現父與子關系的結構（樹形結構），這里我們就應用父子表的概念來設計數據庫中數據字典之間的關系，表設計如下：

Create table T_DataRelation(

DataRelationID int not null,

ParentDataRelationID int null,

primary key (DataRelationID),

foreign key(DataRelationID) references T_DataDictionary(DataDictionaryID),

foreign key(ParentDataRelationID) references T_DataDictionary (DataDictionaryID));

程序可以通過一個遞歸算法來構造出字典數據之間的關系，關系可以是多級樹形結構也可以是一級平行結構。在這里，我們數據字典的設計才算基本完成，當然，在實際軟件實施過程中還會有些其他的功能需求，在設計上還需要加以調整，而一般軟件的數據字典通過以上兩張表來管理即已足夠。

可能會發現，為什么在設計表的時候Code列的字段類型都用char類型，而不用varchar類型，這因為char類型是固定長類型，在檢索的時候比varchar類型要快的多，而且在SQLSever老版本的數據庫上用varchar類型做主鍵，數據量大時會導致檢索出錯，所以一般比較固定的列或比較經常要檢索的列的屬性都設置成固定長度類型。

3 數據檢索技巧

數據庫中對數據的檢索有多種，一般會以視圖的形式表現出來，例如學生信息表。

學生表：

Create table T_Student(

StudentID int,

StudentCode char(12),

StudentName varchar(100),

MajorID int,

GradeID int,

ClassID int,

Primary key(StudentID))

學生視圖：

Create view V_Student

As

Select

a.StudentID,

a.StudentCode,

a.StudentName,

a.MajorID,

b.MajorName,

a.GradeID,

c.GradeName,

a.ClassID,

d.ClassName

From T_Student a

Left join T_Major b on a.MajorID = b.MajorID

Left join T_Grade c on a.GradeID = c.GradeID

Left join T_Class d on a.ClassID = d.ClassID

假設學生表經多年使用后數據量非常龐大，要在其中找出專業名稱為“網絡系統管理”學生的所有信息，自然想到直接查詢視圖，條件鎖定在專業名稱，SQL語句如下：Select * from V_Student where MajorName =‘網絡系統管理’

若學生數據量并不多，使用視圖來檢索并不會慢，但是當數據量大的時候檢索就會變得非常慢，其原因就在于視圖中左連接了三張數據字典表，若使用視圖來檢索，數據庫內部的操作流程是首先對學生表中的所有記錄左連接這三張數據字典表，然后再去檢索專業名稱為“網絡系統管理”學生，檢索速度慢是因視圖內部的左連接了所有的數據導致，應該先找出指定專業的學生，然后左連接專業、年級、班級到這些指定專業的學生上，這樣就大大減少了左連接的數據量，因此類似于這樣的檢索數據就不能用視圖來完成，需要實時編寫SQL語句來滿足不同的需要，按照以上要求改造后的SQL語句如下：

Create view V_Student

As

Select

a.StudentID,

a.StudentCode,

a.StudentName,

a.MajorID,

b.MajorName,

a.GradeID,

c.GradeName,

a.ClassID,

d.ClassName

From(Select * from T_Student where StudentID=( Select MajorID from T_Major where MajorName ='網絡系統管理')) a

Left join T_Major b on a.MajorID = b.MajorID

Left join T_Grade c on a.GradeID = c.GradeID

Left join T_Class d on a.ClassID = d.ClassID

經改進后的SQL語句變得非常復雜，因此在實際開發過程中可以考慮用存儲過程來實現，將復雜的SQL語句寫入存儲過程中。如果經常對某些列，比如學號列、專業列等要頻繁做檢索操作，可以考慮在其表上對這些列創建索引，這樣可以加快檢索索引。

4 結束語

數據庫的設計要結合軟件的需求來完成。隨著時間的推移，軟件的需求是不斷變化的，一個好的數據庫設計必須能適應其需求的變化。當然在很多情況下無法適應，這時就要做詳細的分析，判斷是否重構系統，如果前期設計得當，將大大減輕軟件在后期的使用和維護方面的工作量，而目前許多軟件開發在前期細節方面投入不多，導致后期修改的工作量加大，這是本文討論數據庫設計中應注意的細節問題。

[1] 吳爽．軟件開發中的數據庫設計的理論和實踐[J]．計算機光盤軟件與應用, 2011(6): 182.

[2] 李維. Delphi MDA/DDA程序設計——使用ECO[M]. 北京: 電子工業出版社, 2007.