關鍵詞：信息管理評職論文發表,發表論文期刊網,學員信息管理,數據庫模型

　　1關系數據庫簡述

　　數據庫技術發展至今已有40多年的歷史,它作為數據管理的有效手段,大大促進了計算機應用技術的發展。從早期的文件系統到層次數據庫和網狀數據庫,從關系數據庫到面向對象數據庫,以及面向不同應用的時態數據庫、演繹數據庫等等,均向人們展示了數據庫技術的廣闊應用前景[2]。

　　關系數據庫,顧名思義是建立在關系數據庫模型基礎上的數據庫,借助于集合代數、離散數學等概念和方法來處理數據庫中的數據。關系數據庫是一個被組織成一組擁有正規描述的表格,該形式表格作用的實質是裝載著數據項的特殊收集體。這些表格中的數據以許多不同的方式被存取或重新召集而不需要重新組織數據庫表格[3]。

　　除了相對容易創建和存取之外,關系數據庫具有容易擴充的優勢。在最初數據庫創造之后,一個新的數據種類能被添加而不需要修改所有的現有應用軟件。目前主流的關系數據庫有Oracle、SQL、Aceess、DB2、MySQL、SQLServer、Sybase等等[4]。根據本校辦學規模和處理信息量,采用ACEESS作為本系統數據庫的管理工具。

　　2數據庫模型建立

　　2.1應用需求抽象

　　根據學員信息管理的具體任務,按照管理功能進行業務劃分和模塊化設計。按照簡單性、獨立性及完整性原則,學員信息管理系統后臺可以分為以下幾個子系統:即學員檔案管理子系統、課程管理子系統、成績管理子系統、中隊管理子系統、管理統計子系統、系統管理子系統、系統維護子系統。

　　(1)學員檔案管理子系統學員檔案管理主要有學員管理、批量學員添加、按中隊批量學員添加等功能。

　　(2)課程管理子系統課程管理子系統主要有課程管理、批量課程添加、任課管理、任課添加等功能。

　　(3)成績管理子系統成績管理子系統完成成績管理、批量成績添加、按中隊成績添加功能。

　　(4)中隊管理子系統中隊管理子系統完成中隊管理、中隊批量添加兩個子模塊功能。

　　(5)管理統計子系統管理統計子系統顯示學�；�本信息,包括年級數、中隊數、學員數、教師數、課程數、用戶瀏覽統計等相關信息,還可完成學員統計、排名統計功能。

　　(6)系統管理子系統系統管理子系統包括修改管理員密碼、帳號管理、干部管理、年級管理、學期管理功能。

　　(7)系統維護子系統系統維護子系統主要完成系統的相關設置功能,包括站點名稱,站點LOGO設置,網站主體表格屬性設置,年級變遷(這里主要是對年級進行批量升級操作,也可以在中隊管理下單個進行升級)。

　　2.2數據庫表關系建立

　　關系數據庫模式的建立,離不開數據表之間關系的建立,只有建立表之間的關系,整個數據庫才能形成一個系統,提供強大的信息存儲、查詢、和處理功能[5]。對比應用需求說明和現實學校各部門的業務流程。

　　(1)學員和評語之間存在一對多的對應關系,即一個學員可以有多條來自不同老師的評語;學員和家長存在一對多的對應關系,即一個學員可以對應一個家長,方便家長對學員相關信息進行查詢。學員和平時成績存在一對多的對應關系,即一個學員可以有多種平時成績;同時,學員還和中隊有多對一對應關系,即一個中隊可以有多個學員。

　　(2)中隊和成績有一對多的對應關系,即一個中隊可以有多條成績;中隊和年級有一對一的對應關系,即一個中隊屬于一個年級。中隊和大隊有一對一的對應關系,即一個中隊屬于一個大隊,中隊和任課信息有一對多的對應關系即一個中隊有多條任課關系與之對應。大隊和中隊有一對多的對應關系,即一個大隊對應多個中隊。

　　(3)任課信息表中的教師ID和教師信息表中ID存在一一對應關系。教師表中ID和任課教師信息表中的ID存在一對多的關系。即一個教師可以有多個任課關系。任課教師表中的課程ID和課程表中的課程ID存在一一對應關系。任課信息表中的學期和學期ID存在一一對應關系。即一個任課信息對應一個學期。成績表中的課程ID和課程信息表中的ID存在一一對應關系,成績表中的學期ID和學期表中的學期ID存在一一對應關系。

　　2.3數據庫模式設計

　　2.3.1關系數據庫設計中存在問題

　　(1)數據冗余:在一個數據集合中重復的數據稱為數據冗余。例如在設計時沒有把教師信息表Teacher和任課信息表tea_sub分開,那么每存儲一條任課信息tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)教師表中的其他信息也要重復存儲[4]。

　　(2)更新異常:更新異常分為插入異常和刪除異常。插入異常:比如學員信息表student,如果不知道學號,那么插入再多的其他信息都是沒有意義的。例如一個剛入職的教師理所當然要在任課信息表中有其相關數據,但此時他還沒有任課,即他對應的元組是不完全的,只有而沒有,不能將他的信息放到數據庫中。

　　因此無法注冊該教師的任課信息,這與實際需求不符。這樣的操作是不合理的,將這種現象稱為插入異常。刪除異常:例如在沒分解的教師信息表中的任課信息中,相應的任課關系解除。那么刪除整條記錄,該教師的其他信息也被刪除,在查詢的時候無法查閱該教師相關信息,這也與實際需求相悖,將這種現象稱為刪除異常。數據庫的性能優化包括硬件優化,查詢優化和設計優化三個方面。本文著重介紹設計優化即模式優化,模式優化重點解決數據冗余和更新異常問題。

　　2.3.2數據庫模式的規范化

　　在對數據庫進行模式設計時,對關系的分解并不是盲目的,分解的目的在于減少關系模式的規模,避免不必要的存儲及操作的冗余和數據更新異常。為了清除異常,需要對關系模式進行合理地分解。為此,人們設計數據庫設計的規范化理論,以便能夠設計出異常盡可能少的數據庫模式[4]。據參考文獻[4]所述,數據庫模式分為6級,具體的定義見參考書目。

　　分別是1NF:是關系數據庫對模式的基本要求,即要求屬性的值必須是原子屬性不可再分。2NF:消除了數據庫模式中非主屬性對碼的部分依賴。3NF:消除了數據庫模式中非主屬性對碼的傳遞依賴。BCNF:消除了數據庫模式中一切屬性對碼的傳遞依賴。4NF:消除了數據庫模式中非平凡的和非碼所隱患的多值依賴。5NF:消除了數據庫模式中非平凡的和非碼所隱患的連接依賴[4]。范式的級別由小到大分別是有1NF到5NF。范式的級別越低,冗余與更新異常就越容易產生[6]。

　　(1)滿足1NF的學員信息表分解,在學員信息表中每一個屬性都該是原子屬性,故對部職別進行分解。由消防部隊的編制特點,每個省、自治區、直轄市均有相應的消防總隊;每個地級市、自治州、區都有相應的消防支隊。學校學員來自五湖四海,故對學員信息表中的部職別屬性進行分解。

　　由于有的學員來自總隊和支隊機關,故把部職別分為總隊和部職別兩個屬性,即分解為,province為province表中的省份ID。總隊表設計為province(pid、pname)。在學員信息表中只要存儲省份ID就行。不用再存儲省份名。最長總隊名新疆維吾爾族自治區消防總隊所占字節為26Btye,所占ID為2Byte。按新疆總隊有學員121名計算,模式分解前學員原部別信息中存儲總隊信息需用26Btye×121=3164Byte;而模式分解后存儲ID信息占用2Btye×121=242Byte。

　　(2)滿足BCNF的教師信息表分解,在2.4.1節數據庫設計存在問題中提到數據冗余和刪除異常,在沒分解的教師信息表的任課信息中,相應的任課關系解除。那么刪除整條記錄,該教師的其他信息也被刪除,在查詢的時候無法查閱該教師相關信息,這也與實際需求相悖。要解決刪除異常,即把教師信息表Teacher分解為教師基本信息表teacher和任課教師信息表tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)。這樣的分解既解決了數據冗余的問題,也解決了刪除異常的問題。

　　分解后Teacher和tea_sub關系模式都是1NF,且在其中不存在這樣的屬性A,A傳遞依賴與Teacher和tea_sub的碼、由于關系模式Teacher={R1,R2…,Rn}和tea_sub={R1,R2…,Rn}中Ri(i=1,2,…,n)為BC范式,則關系模式Teacher和tea_sub也滿足BCNF。數據庫的規范化設計還有很多,根據系統應用需求的變更和數據規模的遞增,需要設計相應的數據模式來優化昆明消防指揮學校學員綜合信息管理系統的數據庫性能,使之滿足應用需求,更好地為學校教師、學員和管理人員提供便捷的信息化服務。

　　3結束語

　　本文介紹了昆明消防指揮學校學員綜合信息管理系統的項目開發背景,以關系數據庫為系統數據庫設計的切入點,從應用模型抽象、數據庫表設計、數據庫表之間關系設計、以及數據模式設計幾個方面詳細分析和設計了軍校學員綜合信息管理系統的數據庫。在應用過程中,系統響應迅速,數據存儲、編輯、更新、查詢正確,未發現明顯的存儲和更新異常。并對數據庫設計模式進行了優化,進一步減少了數據冗余,使整個系統的性能得到進一步的提升。

　　但是,數據庫中還存在一定的數據冗余,數據庫模式規范化還需進一步優化。在下一步的工作中還將繼續對關系數據庫理論進行深入研究,力爭能使本系統的數據庫模式性能明顯提升,滿足更高級別的范式規范,為全校師生、管理人員提供方便快捷的學員綜合信息查詢管理平臺。