【資料庫】學生檔案管理系統(續)

NO IMAGE

參見前一篇:【資料庫】學生檔案管理系統

資料庫表的設計及分析

在此我們僅對關鍵表進行分析

學生關係擁有14個屬性,其中學號為主鍵,是學生唯一的標識。外來鍵班級號引用了班級表中的中的主鍵——班級號
該關係不存在多值屬性以及複合屬性
該關係存在函式依賴:
(1)學號->姓名,性別,電話,出生年月,籍貫,家庭地址,入校日期,班級號,職務,檔案號,學籍狀況,免冠照,學生密碼
(2)檔案編號->姓名,性別,電話,出生年月,籍貫,家庭地址,入校日期,班級號,職務,檔案號,免冠照
因此,從屬性的單值性和函式依賴關係可知:該關係符合3 NF.

獎懲記錄關係擁有5個屬性,其中記錄編號作為主鍵,是獎懲記錄的唯一標識。
該關係不存在多值屬性以及複合屬性。
該關係存在函式依賴:
(1)記錄編號->獎懲日期,獎懲事件,性質,獎懲地點
因此,從屬性的單值性和函式依賴關係可知:該關係符合3 NF.

獎懲情況關係不存在主鍵,外來鍵“獎懲記錄編號”引用獎懲記錄表中主鍵——獎懲記錄編號;外來鍵“學號”引用學生表中主鍵——“學生編號”

檔案管理員一共有3個屬性,其中管理員編號為主鍵。是檔案管理員的唯一標識。
該實體不存在多值屬性以及複合屬性
(1)管理員編號->管理員密碼,管理員姓名,管理員密碼
因此,從函式依賴可以看出,該表符合3NF

教育經歷一共有6個屬性,其中教育經歷編號為主鍵。是教育經歷的唯一標識。
該實體不存在多值屬性及複合屬性。
(1)編號->開始日期,終止日期,證明人,學校名稱,在校職務
因此,從函式依賴可以看出,該表符合3NF

教育情況關係不存在主鍵,外來鍵“編號”引用教育經歷記錄表中主鍵——編號;外來鍵,“學號”引用學生表中主鍵——“學生編號”

以上的四個表中具有如下的函式依賴:
班級號->教師號,學院號,專業號,班長,年級名稱,班級名稱
學院號->學院名
專業號->學院號,專業名稱
教師號->學院號,教師姓名,教師密碼
在這些函式依賴中沒有非主元素對主元素的傳遞函式依賴,所以一句這些函式依賴拆分的表示滿足3NF的

開發和執行環境

開發環境

執行環境

效果展示

開始介面
登陸
學生管理
演示視訊
(*點選圖片跳轉到Youku視訊)

總結(*長文慎讀)

因為這次的課程設計題目的需求很明確,所以我們並沒有花太多時間在需求討論上,直接就按題目的模組劃分開始做詳細設計。根據題目的要求進行了專案功能的劃分。分析用例,畫出用例圖對每個功能快的功能進行分析。因為時間較為緊迫於是我們選擇RAD的開發方式,進行任務分配,分開進行編碼,最後進行整合與部署。
在設計資料庫的時候我們開始以為只要按照題目要求,每個模組做一個表就可以,但當仔細考慮之後才發現設計一個優秀的資料庫並沒有那麼簡單。
這其中我們遇到很多問題。比如班級表的設計,較為簡單的一種方法是班級做一張表,學院,專業,年級作為班級的屬性。仔細分析我們就可以看到這樣的函式依賴:班級號->專業,學院;專業->學院;存在非主屬性對主鍵的傳遞函式依賴,同時這樣的表中會有大部分的班級學院的屬性是相同的(即在同一學院的班級學院列屬性相同)會存在大量的資料冗餘。所以我們將班級、專業、學院分別單獨做表,因為專業和班級之間是一對多的關係,學院與專業也是一對多的關係,所以班級表中有引用專業的主鍵——專業號做外來鍵,專業的表中引用學院的主鍵——學院號做外來鍵。這樣雖然滿足了三正規化,但在實際操作的時候我們才發現這種建表方法並不是絕對的好。因為每次查詢學生班級情況或者新增學生的時候都需要將班級、專業、學院三張表連線起來,效率很低,相比還是建在同一張表中更為合理。
另外的問題就是學生與教育經驗以及獎懲記錄之間是“一對多”的關係還是“多對多”的關係。拿“獎懲記錄”來說,似乎一對多更為合理——一個學生可以有多個獎懲記錄或者沒有獎懲記錄;但如果我們這樣考慮——不同的學生可以有相同的獎懲記錄,比如以團隊形式參賽的“全國大學生數學建模大賽”,這似乎也是合理的……這就像大一課程設計時將實際物體抽象成類,用程式語言描述習以為常的事物有時卻不是習以為常的“容易”。最後我們選擇了“多對多”的模式。但是實際操作中我們遇到了這樣的問題,即在刪除獎懲記錄時,若有多個學生由此條記錄,則會出現錯誤,即其他學生的獎懲記錄會變為空值,而若不刪除獎懲記錄中的元組,則會造成大量資料的冗餘,產生大量垃圾佔用了儲存空間,但是由於時間緊迫而且問題發現的較遲,我們就未進行改正,這也是我們的遺憾之一。
我們的程式還有一個致命性的問題,即效率與安全性的問題。在效率方面,我們大量的操作是通過C#語言來實現,雖然我們也用了觸發器、儲存過程、檢視等,但是從程式整體上來說封裝性較差,大量的程式碼使可讀性下降了。
從安全性的角度來說,我們系統的授權是通過應用程式的程式碼授權實現的。主要是因為在SQL中很難實現元組的授權。於是整個SQL的授權機制便受到忽略。好處是會有細密的授權,問題有二,一是,授權程式碼會與應用程式的程式碼混合在一起;二是,通過應用程式的授權而非SQL的授權很難保證沒有漏洞。由於一個疏忽,一個應用程式可能不檢查程式而使沒有許可權的使用者訪問機密資料,要確保所有應用程式都具備所需的許可權檢查,其工作包括通讀所有應用程式伺服器的程式碼,這在一個大系統中是一個較為艱鉅的任務。
但是我們的程式從功能上來說還是比較強大的,雖然是犧牲了效率,但是帶給使用者較大的方便性及可用性,同時我們設計了較為友好的人機互動介面,極大地提高了程式的易用性。

(轉載請註明作者和出處:http://blog.csdn.net/xiaowei_cqu 未經允許請勿用於商業用途)