數據庫表的設計及分析

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

學生關系擁有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?未經允許請勿用于商業用途）

總結

以上是生活随笔為你收集整理的学生档案管理系统（续）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。