導語：學員信息管理數(shù)據(jù)庫模型分析一文來源于網(wǎng)友上傳，不代表本站觀點，若需要原創(chuàng)文章可咨詢客服老師，歡迎參考。

1關系數(shù)據(jù)庫簡述

數(shù)據(jù)庫技術發(fā)展至今已有40多年的歷史，它作為數(shù)據(jù)管理的有效手段，大大促進了計算機應用技術的發(fā)展。從早期的文件系統(tǒng)到層次數(shù)據(jù)庫和網(wǎng)狀數(shù)據(jù)庫，從關系數(shù)據(jù)庫到面向對象數(shù)據(jù)庫，以及面向不同應用的時態(tài)數(shù)據(jù)庫、演繹數(shù)據(jù)庫等等，均向人們展示了數(shù)據(jù)庫技術的廣闊應用前景［2］。關系數(shù)據(jù)庫，顧名思義是建立在關系數(shù)據(jù)庫模型基礎上的數(shù)據(jù)庫，借助于集合代數(shù)、離散數(shù)學等概念和方法來處理數(shù)據(jù)庫中的數(shù)據(jù)。關系數(shù)據(jù)庫是一個被組織成一組擁有正規(guī)描述的表格，該形式表格作用的實質是裝載著數(shù)據(jù)項的特殊收集體。這些表格中的數(shù)據(jù)以許多不同的方式被存取或重新召集而不需要重新組織數(shù)據(jù)庫表格［3］。除了相對容易創(chuàng)建和存取之外，關系數(shù)據(jù)庫具有容易擴充的優(yōu)勢。在最初數(shù)據(jù)庫創(chuàng)造之后，一個新的數(shù)據(jù)種類能被添加而不需要修改所有的現(xiàn)有應用軟件。目前主流的關系數(shù)據(jù)庫有Oracle、SQL、Aceess、DB2、MySQL、SQLServer、Sybase等等［4］。根據(jù)本校辦學規(guī)模和處理信息量，采用ACEESS作為本系統(tǒng)數(shù)據(jù)庫的管理工具。

2數(shù)據(jù)庫模型建立

2．1應用需求抽象

根據(jù)學員信息管理的具體任務，按照管理功能進行業(yè)務劃分和模塊化設計。按照簡單性、獨立性及完整性原則，學員信息管理系統(tǒng)后臺可以分為以下幾個子系統(tǒng):即學員檔案管理子系統(tǒng)、課程管理子系統(tǒng)、成績管理子系統(tǒng)、中隊管理子系統(tǒng)、管理統(tǒng)計子系統(tǒng)、系統(tǒng)管理子系統(tǒng)、系統(tǒng)維護子系統(tǒng)。(1)學員檔案管理子系統(tǒng)學員檔案管理主要有學員管理、批量學員添加、按中隊批量學員添加等功能。(2)課程管理子系統(tǒng)課程管理子系統(tǒng)主要有課程管理、批量課程添加、任課管理、任課添加等功能。(3)成績管理子系統(tǒng)成績管理子系統(tǒng)完成成績管理、批量成績添加、按中隊成績添加功能。(4)中隊管理子系統(tǒng)中隊管理子系統(tǒng)完成中隊管理、中隊批量添加兩個子模塊功能。(5)管理統(tǒng)計子系統(tǒng)管理統(tǒng)計子系統(tǒng)顯示學?；拘畔?，包括年級數(shù)、中隊數(shù)、學員數(shù)、教師數(shù)、課程數(shù)、用戶瀏覽統(tǒng)計等相關信息，還可完成學員統(tǒng)計、排名統(tǒng)計功能。(6)系統(tǒng)管理子系統(tǒng)系統(tǒng)管理子系統(tǒng)包括修改管理員密碼、帳號管理、干部管理、年級管理、學期管理功能。(7)系統(tǒng)維護子系統(tǒng)系統(tǒng)維護子系統(tǒng)主要完成系統(tǒng)的相關設置功能，包括站點名稱，站點LOGO設置，網(wǎng)站主體表格屬性設置，年級變遷(這里主要是對年級進行批量升級操作，也可以在中隊管理下單個進行升級)。

2．2數(shù)據(jù)庫表關系建立

關系數(shù)據(jù)庫模式的建立，離不開數(shù)據(jù)表之間關系的建立，只有建立表之間的關系，整個數(shù)據(jù)庫才能形成一個系統(tǒng)，提供強大的信息存儲、查詢、和處理功能［5］。對比應用需求說明和現(xiàn)實學校各部門的業(yè)務流程，設計數(shù)據(jù)庫表之間的關系如圖1所示。(1)學員和評語之間存在一對多的對應關系，即一個學員可以有多條來自不同老師的評語;學員和家長存在一對多的對應關系，即一個學員可以對應一個家長，方便家長對學員相關信息進行查詢。學員和平時成績存在一對多的對應關系，即一個學員可以有多種平時成績;同時，學員還和中隊有多對一對應關系，即一個中隊可以有多個學員。(2)中隊和成績有一對多的對應關系，即一個中隊可以有多條成績;中隊和年級有一對一的對應關系，即一個中隊屬于一個年級。中隊和大隊有一對一的對應關系，即一個中隊屬于一個大隊，中隊和任課信息有一對多的對應關系即一個中隊有多條任課關系與之對應。大隊和中隊有一對多的對應關系，即一個大隊對應多個中隊。(3)任課信息表中的教師ID和教師信息表中ID存在一一對應關系。教師表中ID和任課教師信息表中的ID存在一對多的關系。即一個教師可以有多個任課關系。任課教師表中的課程ID和課程表中的課程ID存在一一對應關系。任課信息表中的學期和學期ID存在一一對應關系。即一個任課信息對應一個學期。成績表中的課程ID和課程信息表中的ID存在一一對應關系，成績表中的學期ID和學期表中的學期ID存在一一對應關系。

2．3數(shù)據(jù)庫模式設計

2．3．1關系數(shù)據(jù)庫設計中存在問題

(1)數(shù)據(jù)冗余:在一個數(shù)據(jù)集合中重復的數(shù)據(jù)稱為數(shù)據(jù)冗余。例如在設計時沒有把教師信息表Teacher和任課信息表tea_sub分開，那么每存儲一條任課信息tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)教師表中的其他信息也要重復存儲［4］。(2)更新異常:更新異常分為插入異常和刪除異常。插入異常:比如學員信息表student，如果不知道學號，那么插入再多的其他信息都是沒有意義的。例如一個剛入職的教師理所當然要在任課信息表中有其相關數(shù)據(jù)，但此時他還沒有任課，即他對應的元組＜ts_sub_id、ts_ter_id、ts_cla_id＞是不完全的，只有＜tsid、ts_tea_user、ts_sub_id＞而沒有＜ts_ter_id、ts_cla_id＞，不能將他的信息放到數(shù)據(jù)庫中。因此無法注冊該教師的任課信息，這與實際需求不符。這樣的操作是不合理的，將這種現(xiàn)象稱為插入異常。刪除異常:例如在沒分解的教師信息表中的任課信息中，相應的任課關系解除。那么刪除整條記錄，該教師的其他信息也被刪除，在查詢的時候無法查閱該教師相關信息，這也與實際需求相悖，將這種現(xiàn)象稱為刪除異常。數(shù)據(jù)庫的性能優(yōu)化包括硬件優(yōu)化，查詢優(yōu)化和設計優(yōu)化三個方面。本文著重介紹設計優(yōu)化即模式優(yōu)化，模式優(yōu)化重點解決數(shù)據(jù)冗余和更新異常問題。

2．3．2數(shù)據(jù)庫模式的規(guī)范化

在對數(shù)據(jù)庫進行模式設計時，對關系的分解并不是盲目的，分解的目的在于減少關系模式的規(guī)模，避免不必要的存儲及操作的冗余和數(shù)據(jù)更新異常。為了清除異常，需要對關系模式進行合理地分解。為此，人們設計數(shù)據(jù)庫設計的規(guī)范化理論，以便能夠設計出異常盡可能少的數(shù)據(jù)庫模式［4］。據(jù)參考文獻［4］所述，數(shù)據(jù)庫模式分為6級，具體的定義見參考書目。分別是1NF:是關系數(shù)據(jù)庫對模式的基本要求，即要求屬性的值必須是原子屬性不可再分。2NF:消除了數(shù)據(jù)庫模式中非主屬性對碼的部分依賴。3NF:消除了數(shù)據(jù)庫模式中非主屬性對碼的傳遞依賴。BCNF:消除了數(shù)據(jù)庫模式中一切屬性對碼的傳遞依賴。4NF:消除了數(shù)據(jù)庫模式中非平凡的和非碼所隱患的多值依賴。5NF:消除了數(shù)據(jù)庫模式中非平凡的和非碼所隱患的連接依賴［4］。范式的級別由小到大分別是有1NF到5NF。范式的級別越低，冗余與更新異常就越容易產(chǎn)生［6］。(1)滿足1NF的學員信息表分解，在學員信息表中每一個屬性都該是原子屬性，故對部職別進行分解。由消防部隊的編制特點，每個省、自治區(qū)、直轄市均有相應的消防總隊;每個地級市、自治州、區(qū)都有相應的消防支隊。學校學員來自五湖四海，故對學員信息表中的部職別屬性進行分解。由于有的學員來自總隊和支隊機關，故把部職別分為總隊和部職別兩個屬性，即＜yuanbubie＞分解為＜yuanbu-bie、province＞，province為province表中的省份ID?？傟牨碓O計為province(pid、pname)。在學員信息表中只要存儲省份ID就行。不用再存儲省份名。最長總隊名新疆維吾爾族自治區(qū)消防總隊所占字節(jié)為26Btye，所占ID為2Byte。按新疆總隊有學員121名計算，模式分解前學員原部別信息中存儲總隊信息需用26Btye×121=3164Byte;而模式分解后存儲ID信息占用2Btye×121=242Byte。(2)滿足BCNF的教師信息表分解，在2．4．1節(jié)數(shù)據(jù)庫設計存在問題中提到數(shù)據(jù)冗余和刪除異常，在沒分解的教師信息表的任課信息中，相應的任課關系解除。那么刪除整條記錄，該教師的其他信息也被刪除，在查詢的時候無法查閱該教師相關信息，這也與實際需求相悖。要解決刪除異常，即把教師信息表Teacher分解為教師基本信息表teacher和任課教師信息表tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)。這樣的分解既解決了數(shù)據(jù)冗余的問題，也解決了刪除異常的問題。分解后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。數(shù)據(jù)庫的規(guī)范化設計還有很多，根據(jù)系統(tǒng)應用需求的變更和數(shù)據(jù)規(guī)模的遞增，需要設計相應的數(shù)據(jù)模式來優(yōu)化昆明消防指揮學校學員綜合信息管理系統(tǒng)的數(shù)據(jù)庫性能，使之滿足應用需求，更好地為學校教師、學員和管理人員提供便捷的信息化服務。

3結束語

本文介紹了昆明消防指揮學校學員綜合信息管理系統(tǒng)的項目開發(fā)背景，以關系數(shù)據(jù)庫為系統(tǒng)數(shù)據(jù)庫設計的切入點，從應用模型抽象、數(shù)據(jù)庫表設計、數(shù)據(jù)庫表之間關系設計、以及數(shù)據(jù)模式設計幾個方面詳細分析和設計了軍校學員綜合信息管理系統(tǒng)的數(shù)據(jù)庫。在應用過程中，系統(tǒng)響應迅速，數(shù)據(jù)存儲、編輯、更新、查詢正確，未發(fā)現(xiàn)明顯的存儲和更新異常。并對數(shù)據(jù)庫設計模式進行了優(yōu)化，進一步減少了數(shù)據(jù)冗余，使整個系統(tǒng)的性能得到進一步的提升。但是，數(shù)據(jù)庫中還存在一定的數(shù)據(jù)冗余，數(shù)據(jù)庫模式規(guī)范化還需進一步優(yōu)化。在下一步的工作中還將繼續(xù)對關系數(shù)據(jù)庫理論進行深入研究，力爭能使本系統(tǒng)的數(shù)據(jù)庫模式性能明顯提升，滿足更高級別的范式規(guī)范，為全校師生、管理人員提供方便快捷的學員綜合信息查詢管理平臺。

作者：李懷義1張紅友1胡靜波2工作單位：1．昆明消防指揮學校2．寶雞文理學院電子電氣工程系