教務系統資料庫設計 （一）

        從11月中旬以來一直在做教務系統，開始階段是各個子系統獨立開發，包括評教系統、選修課系統、考試系統三個子系統，這三個系統已經有原型，我們採用的都是原型開發，因為需求已經確定，研究了一段時間把使用案例圖、類圖等畫了畫，完成了大部分了，快該寫代碼瞭然後，老師說需要把這三個系統整合在一起，做一個教務系統，教務系統是一個平台，可以往裡面擴充子系統，使得資訊可以共用，避免資訊孤島的出現。

 

        對於想要建立共用性、整合性高的系統即要設計一個結構緊密又靈活性好的共用資料庫，下面一段很長的時間就是設計教務系統的資料庫……

       下面是我們資料庫設計的過程中遇到的一些問題

 

       1. 資料庫表之間該不該多用主外鍵呢 ?

            先說我們做的評教系統，單獨從這一個系統角度考慮，建立我們自己的資料庫表，我們多加一些主鍵無所謂，加多點主鍵還可以使得表結構嚴謹，資料一致性好，但是當我們再加入新的系統的時候，把選課系統也加入到這個系統中，那麼評教系統中的表就需要從新設計裡面的主外鍵，出現這樣的情況是當初設計表結構時沒有考慮到靈活性，單獨從一個系統角度考慮，即過多使用主外鍵也會使得表結構過於緊密、靈活性差，在什麼情況下使用還需多多考慮。

 

            那主外鍵就不使用了嗎？當然不是，既然主外鍵可以使得表一致性高、擴充性差，那我們可以避開缺點，使用優點，在需要擴充的地方盡量不使用主外鍵關係，而在要求擴充性不高的地使用主鍵外鍵，根據這一原則更改表結構

           更改後的資料庫設計，如下

          

           新增了中間表（關係表）充當主外鍵的作用鑑效組資料一致性，把基礎資料表中的鍵關係移動到了基礎資料表與關係表中，這看上去好像是降低了基礎資料表與基礎資料表之間的耦合度，給基礎資料表解耦，這讓我想起了中介者模式，通過一個中介類來給各個對象解耦，通過中介通訊，而不是讓各個類直接通訊，舉個例子：各個國家中國、美國、日本等有時並不直接交涉而不是通過聯合國，給各個國家之間解耦，不管是在生活、學習中，設計模式的思想無處不在，值得學習。

          

       2.  基礎資料表與子系統表如何劃分 ?

          從每一個子系統方面考慮，子系統表無論放基礎裡還是放自己系統裡都可以實現，其區別是放基礎裡面別的子系統可以使用，來共用資訊，分表的時候按著資訊是否需要共用來分表，如果這種資訊不需要共用，那我們就沒有必要往基礎資料表裡面放，如果放在基礎資料表裡面反而會增加基礎資料表負擔，增加資料庫表冗餘。

 

          舉個例子：例如TB_Student、TB_Teacher、TB_College、TB_Department等表，只要是學校裡的系統，一般都會用到這些資訊，很顯然，這些表應該歸為基礎資料表，另外還有一些特殊關係表也應該規則基礎資料表，如老師課程關係表等，這也是基礎資訊，這些資訊不依附於某個子系統。

         

          其中，也還有很多細節問題，不一一列舉，下面是資料庫設計一點點經驗

 

          我們設計資料庫時可以遵循這樣的設計原則：

 

          (1)
資料庫中表的個數越少越好。

                   形成了對客觀世界的高度抽象，進行了系統的Data Integration，防止了打補丁式的設計

          (2)
表中組合主鍵的欄位個數越少越好。

                  因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組合主鍵的欄位個數少了，不僅節省了已耗用時間，而且節省了索引儲存空間；

          (3)
表中的欄位個數越少越好。

                  減少資料冗餘，一種方法是“列變行”，所謂“列變行”，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許多空餘的欄位。

 

          (4)
降低範式，增加冗餘, 少用觸發器,
多用預存程序。

          (5)
當計算非常複雜、而且記錄條數非常巨大時,複雜計算要先在資料庫外面。

 

          (6)
發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。

          (7)
對資料庫管理系統DBMS進行系統最佳化，即最佳化各種系統參數，如緩衝區個數。