考試系統資料庫設計的幾點感受

        鑒於教務系統基礎資料庫的構建整整用了我們一個月時間，為了這一個月，也需要寫篇部落格總結一下。首先說一下教務系統現有部分，方便對下面內容的說明：教務系統包括四部分：基礎系統、考試系統、評教系統、選課系統，其中基礎系統用於對基礎資料的維護，其它系統看只看系統名就可以知道其功能。

命名

        資料庫設計的第一步就是怎麼命名，第一版的命名規則是：

• T_表示表類型，V_表示檢視類型
• E_表示實體表，R_表示關係表
• K_表示考試系統資料表，B_表示基礎系統資料表，C_表示選課系統資料表

        於是一張表的命名就可以使T_E_K_ExamStudent，最開始會這種命名方法得意：資料庫中，表可以按命名規則自動排序。但是問題出來了，這樣命名，一條簡答SQL語句就會成為：

SELECT * FROM T_E_K_ExamStudent

        如果再加上跨表查詢，得多少個_，這不是為自己找罪受嗎？再說K是考試拼音第一個字元，而B表示英語Basic的第一個字元，中英文混亂，修改後，最終的命名規則為：

• T表示表類型，V表示檢視類型
• 實體表沒有首碼，R表示關係表，H表示曆史表
• E表示考試系統，A表示評教系統，C表示選課系統

        這時，一條SQL語句可以是

SELECT * FROM TE_ExamStudent

        這樣的語句，清晰、易寫、容易維護。

設計

        教務系統整體設計如：

        

        基礎資料由基礎系統維護，例如：學生資訊、教師資訊、班級資訊等，負責對這些資訊的增刪改查。其它系統有自己的表，對於基礎資訊，其它表只有讀取的權利，不能修改或是刪除。

        教務系統中的表設計如：

        

        即實體表之間不能直接有關聯，都是通過第三張關係表關聯。這與以前的資料庫設計有很大的區別，以前只有表資料為多對多時，才用第三張表關聯；但現在是只要兩張表有關係，不管是一對多還是多對多，都是通過第三張表關聯。

        這樣設計的好處是，加入某個學院下不再有某個專業時，只需把關係表中的資料刪除即可，兩個實體表都不要改變，這樣可以充分保證表之間的獨立性和擴充性，而這正是基礎資料最重要的因素。

討論

        當初設計資料庫時，分歧很大的一個問題是，基礎資料庫表欄位豐富好還是精簡好？例如，學生表要不要包含社會安全號碼、郵箱等欄位？

        一種方案是，精簡型，當需要額外添加欄位時，這些欄位添加到建立的關係表中；另外一張方案是豐富型，認為是應該把所有能用到或是暫時用不到的欄位添加到實體表中。因為把實體欄位存在於關係表中，造成的資料冗餘大於在實體表中，所以經過討論採用的是豐富型。

        現在想想當初為什麼會產生這個討論，很大程度上是因為設計資料庫時直接跨越到了邏輯設計階段，忽視了概念設計階段，由此產生了對實體屬性的討論。        

補充

        到此階段對教務系統基礎資料庫設計已經結束，在此需要再補充幾點：

• 曆史資料處理，不能刪除資料，但是可以轉移到曆史表中，方便以後統計查詢。
• 子系統表、功能表，每個系統都是獨立的子系統，所以需要有一張表，記錄每個系統名稱、logo、發布地址、發布時間、是否可用等欄位，保證介面可以動態載入子系統。
• 記錄每個操作，對系統的每個操作，例如登入、增加記錄、修改、刪除等都應該記錄時間、許可權、使用者、機器等資訊。
• 對每個實體的操作，只要許可權足夠，都能進行增刪改查操作。同時因為一般使用者不能修改資料庫，只能通過系統間接修改資料，所以對每個實體的增刪改查操作都要體現到介面上。

        教務系統資料庫就總結到這裡，這次設計的感觸很深的是：盡信書不如無書，站在已有的理論上很重要，但不要把自己綁在上面，因地制宜靈活運用才能切合實際使用。