研究生學位信息研究論文

時間:2022-06-23 08:39:00

導語:研究生學位信息研究論文一文來源于網(wǎng)友上傳,不代表本站觀點,若需要原創(chuàng)文章可咨詢客服老師,歡迎參考。

研究生學位信息研究論文

摘要作者開發(fā)的基于Web的研究生學位信息管理系統(tǒng)具有數(shù)據(jù)錄入、數(shù)據(jù)處理、信息查詢、信息輸出、數(shù)據(jù)導出等基本功能。介紹了系統(tǒng)體系結(jié)構(gòu)以及開發(fā)的關(guān)鍵技術(shù),包括基于窗體身份驗證、基于角色的用戶管理以及基于存儲過程的分頁顯示技術(shù)等。

關(guān)鍵詞學位信息管理系統(tǒng);身份驗證;用戶管理;分頁顯示

1引言

研究生學位管理是研究生教育的一個重要環(huán)節(jié),是一項涉及多學科知識,需多部門協(xié)調(diào)工作的管理系統(tǒng)工程。它主要完成數(shù)據(jù)錄入、數(shù)據(jù)處理、信息輸出和數(shù)據(jù)導出等工作。學位管理部門要求:可以從其它部門獲取已有的學生信息,也可以手工錄入學位信息;數(shù)據(jù)經(jīng)過處理后以適當?shù)男问捷敵鱿嚓P(guān)文件或表格,如學位申請表、授予學位文件、授予學位名單、學位證明等,同時將處理后的數(shù)據(jù)按一定格式上報教育部。

針對上述需求,我們開發(fā)了基于Web的研究生學位管理信息系統(tǒng)。該系統(tǒng)采用2.0開發(fā)平臺、C#語言、SQLServer2000數(shù)據(jù)庫管理系統(tǒng),在基于Intranet/Intranet的校園網(wǎng)環(huán)境下運行。

2系統(tǒng)設(shè)計

本系統(tǒng)采用三層B/S體系結(jié)構(gòu),如圖1所示,其中:

圖1系統(tǒng)體系結(jié)構(gòu)圖

表示層:相當于用戶界面,為客戶端提供對整個應用程序的訪問。在本系統(tǒng)中表示層由Web窗體和代碼隱藏文件組成。在.aspx文件中只有html代碼和服務器控件,在頁面程序代碼文件(.cs文件)中調(diào)用.dll組件中的數(shù)據(jù)庫操作方法,返回滿足條件的結(jié)果。

中間層:是整個系統(tǒng)的核心部分,擔當主要的應用處理,包括處理表示層的HTTP請求以及對數(shù)據(jù)庫的訪問。

在設(shè)計系統(tǒng)時,我們把應用程序中的業(yè)務邏輯放在中間層應用服務器上,這樣業(yè)務邏輯和用戶界面分開。如果要修改應用程序代碼,只須對應用服務器進行修改,而不用修改成千上萬的客戶端應用程序。同時由于只支持面向?qū)ο?組件也可以看作類,因此可以在Web項目中添加對數(shù)據(jù)庫操作的組件,并將其編譯為.dll,這樣就把數(shù)據(jù)庫的操作過程封裝起來,便于代碼的安全管理和維護。因此,我們把中間層進一步分解為業(yè)務外觀、業(yè)務規(guī)則、數(shù)據(jù)訪問等層進行處理,并且把它們封裝在了獨立的.dll組件中。

其中,業(yè)務外觀層用作隔離層,它將用戶界面與各種業(yè)務功能的實現(xiàn)隔離開來,它除了為表示層提供服務,還可以訪問業(yè)務規(guī)則和數(shù)據(jù)訪問層,是系統(tǒng)的公共入口點。業(yè)務規(guī)則層包含了各種業(yè)務規(guī)則和邏輯的實現(xiàn)。數(shù)據(jù)訪問層為業(yè)務外觀層和業(yè)務規(guī)則層提供數(shù)據(jù)服務,其中包含了各種數(shù)據(jù)訪問的類。

數(shù)據(jù)層:位于底層,以為接口,SQLServer2000為后臺,主要處理應用層對數(shù)據(jù)的請求。

系統(tǒng)運行時,客戶端瀏覽器發(fā)出對頁面的訪問請求,訪問表示層各aspx文件,再將各請求事件發(fā)送到業(yè)務外觀層,業(yè)務外觀層根據(jù)需要訪問業(yè)務規(guī)則層或數(shù)據(jù)訪問層。而業(yè)務規(guī)則層只能訪問數(shù)據(jù)訪問層,數(shù)據(jù)訪問層通過訪問數(shù)據(jù)層的存儲過程以達到對數(shù)據(jù)庫的操作。由于整個系統(tǒng)由相互交互的各層實現(xiàn),因此可以實現(xiàn)系統(tǒng)的分布式部署,以達到分布式應用來減輕各層的壓力。

由于客戶端向服務器請求頁面時,其復雜的邏輯處理在服務器端進行,在客戶端只能看到該網(wǎng)頁的最終表現(xiàn)和HTML,而不能看到該網(wǎng)頁的程序邏輯,這樣可以有效地保護程序代碼的安全。

圖1對應的研究生學位信息管理軟件模塊結(jié)構(gòu)如圖2所示。

圖2學位系統(tǒng)功能模塊圖

其中,各模塊實現(xiàn)的功能如下:

(1)數(shù)據(jù)導入:輔助學位辦工作人員從其它部門(招生辦、培養(yǎng)科)導入學生已有的基本信息,包括學籍信息和培養(yǎng)信息。

(2)數(shù)據(jù)錄入:輔助學位辦工作人員通過研究生部局域網(wǎng),以及研究生通過互聯(lián)網(wǎng)錄入相關(guān)信息。

(3)數(shù)據(jù)處理:實現(xiàn)學位證書號碼自動生成、數(shù)據(jù)轉(zhuǎn)存數(shù)據(jù)維護等操作。

(4)用戶管理:實現(xiàn)各種登錄用戶的角色、權(quán)限管理以及密碼修改。

(5)數(shù)據(jù)查詢:實現(xiàn)從數(shù)據(jù)庫查找相關(guān)學生記錄,并按一定格式顯示和打印。

(6)數(shù)據(jù)輸出:實現(xiàn)學位申請表的打印、學位信息導入、上報庫dbf表等功能。

3系統(tǒng)實現(xiàn)

1)中的安全機制

學位系統(tǒng)采用安全架構(gòu)中的表單驗證方式實現(xiàn)用戶登錄。使用表單身份驗證時,通過指定的登錄頁面收集用戶的憑證信息,如果未驗證身份的用戶試圖訪問受保護的文件或資源(其中,URL授權(quán)拒絕用戶訪問)將被重新定向到該登錄頁面,用戶在此處嘗試通過身份驗證。用戶提供憑據(jù)并提交該窗體,如果應用程序?qū)φ埱筮M行身份驗證,系統(tǒng)會發(fā)出一個Cookie,其中包含用于重新獲取標識的憑據(jù)或密鑰。隨后發(fā)出的請求在請求頭中具有該Cookie,事件處理程序使用應用程序開發(fā)人員指定的任何驗證方法對這些請求進行身份驗證和授權(quán)。其驗證流程如圖3所示。

圖3基于窗體的身份驗證流程

基于窗體的身份驗證開發(fā)步驟如下:

(1)將IIS配置為使用匿名訪問。

(2)將配置為使用表單身份驗證。在Web.config文件中配置authentication元素的屬性,設(shè)置為身份驗證模式。

<authenticationmode="Forms">

<formsname=".ASPXAUTH"protection="Encryption"timeout="15"loginUrl="Login.aspx"/>

</authentication>

(3)檢索數(shù)據(jù)存儲驗證用戶,從自定義數(shù)據(jù)存儲中檢索角色列表(不是基于角色可不用)。

(4)使用FormsAuthenticationTicket創(chuàng)建一個Cookie并回發(fā)到客戶端,并存儲角色到票中。

FormsAuthentication.SetAuthCookie(Username,true|false)

HttpContext.Current.Response.Cookies[FormsAuthentication.FormsCookieName].Expires=DateTime.Now.AddDays(1)//cookies保存時間

如果需要存儲角色,采用:

FormsAuthenticationTicketauthTicket=newFormsAuthenticationTicket(

1,//版本號,設(shè)置為1

txtUserName.Text,//用戶標示

DateTime.Now,//Cookie的發(fā)出時間,設(shè)置為DateTime.Now

DateTime.Now.AddMinutes(20),//Cookie的有效時間

false,//是否持久性

roles);//roles為存儲的用逗號分割的角色串

stringencryptedTicket=FormsAuthentication.Encrypt(authTicket);//把身份驗證票加密

//設(shè)置驗證票cookie,第一個參數(shù)為cookie的名字,第二個參數(shù)為cookie的值也就是加密后的票

HttpCookieauthCookie=

newHttpCookie(FormsAuthentication.FormsCookieName,

encryptedTicket);

Response.Cookies.Add(authCookie);//把cookie加進Response對象發(fā)生到客戶端

(5)在Global.asax內(nèi)的Application_AuthenticateRequest事件中處理程序中(Global.asax)中,使用票創(chuàng)建IPrincipal對象并存在HttpContext.User中。

HttpCookieauthCookie=Context.Request.Cookies[FormsAuthentication.FormsCookieName];

FormsAuthenticationTicketauthTicket=FormsAuthentication.Decrypt(authCookie.Value);//解密

string[]roles=authTicket.UserData.Split(newchar[]{'''',''''});//根據(jù)存入時的格式分解角色

Context.User=newGenericPrincipal(Context.User.Identity,Roles);//存入HttpContext.User

2)基于角色的用戶管理

基于角色的訪問控制已經(jīng)相當成熟,作為策略中立的鑒別和授權(quán)機制,通過角色的繼承和職責分離等控制約束條件可以實現(xiàn)多種控制策略。基于角色的訪問控制引入角色這個中介,安全管理人員根據(jù)需要定義各種角色,并設(shè)置合適的訪問權(quán)限,而用戶根據(jù)其職責被指派為不同的角色。由于實現(xiàn)了用戶與訪問權(quán)限的邏輯分離,基于角色的策略極大地方便了權(quán)限管理,而且對實際應用環(huán)境的訪問控制需求的描述更自然,而對一個組織來說,其行為特征和功能是比較穩(wěn)定的,因此其角色是比較穩(wěn)定的。由于角色/權(quán)限之間的變化比角色/用戶關(guān)系之間的變化相對要慢得多。

本學位管理系統(tǒng)包含了多種數(shù)據(jù)操作功能,并且擁有不同種類的多個用戶,從總體上考慮可以分為管理員、教師(普通教師、研究生秘書)和研究生(碩士、博士、專業(yè)碩士等)。不同類別的用戶對系統(tǒng)功能的使用權(quán)限是不同的,因此要求系統(tǒng)提供一種對多用戶的權(quán)限管理,以確保具有權(quán)限的用戶能夠獲取或處理數(shù)據(jù)和信息,禁止所有未授權(quán)用戶操作數(shù)據(jù)。針對系統(tǒng)的這一特點,我們在開發(fā)過程中,采用了兩級控制機制分別對頁面資源和數(shù)據(jù)進行控制。在用戶成功登錄系統(tǒng)后根據(jù)用戶角色所具有的權(quán)限動態(tài)生成菜單頁面,從而限制了用戶對未授權(quán)頁面的訪問;在用戶訪問同一頁面時,對于不同的用戶所獲取的數(shù)據(jù)信息是不一樣的。例如,對于不同學院的研究生秘書進入系統(tǒng)后,他們只能操作所在學院的學生數(shù)據(jù)。

在研究生學位管理系統(tǒng)中,我們把所有系統(tǒng)用戶的角色信息保存在數(shù)據(jù)庫的用戶表中。其次,將系統(tǒng)中所有的功能模塊及其子功能訪問接口的訪問權(quán)限信息都存放在數(shù)據(jù)庫中的訪問權(quán)限表中。

當用戶登錄學位管理系統(tǒng)時,權(quán)限管理的系統(tǒng)流程如圖4所示。

圖4權(quán)限管理的系統(tǒng)流程

3)基于存儲過程分頁顯示技術(shù)

顯示數(shù)據(jù)查詢的結(jié)果時,為了縮短頁面數(shù)據(jù)的顯示時間,我們利用分頁的方法來顯示查詢結(jié)果。傳統(tǒng)的數(shù)據(jù)分頁方法是ADO紀錄集分頁法,也就是利用ADO自帶的分頁功能(利用游標)來實現(xiàn)分頁。但這種分頁方法僅適用于較小數(shù)據(jù)量的情形,因為游標本身有缺點:游標是存放在內(nèi)存中,很費內(nèi)存。游標一經(jīng)建立,就將相關(guān)的記錄鎖住,直到取消游標。

對于數(shù)據(jù)量大的數(shù)據(jù)源而言,分頁檢索時,如果按照傳統(tǒng)的每次都加載整個數(shù)據(jù)源的方法是非常浪費資源的。因此在分頁的時候可以檢索當前頁面所需數(shù)據(jù),而非檢索所有的數(shù)據(jù),然后單步執(zhí)行當前行,這就是我們所說的基于存儲過程的分頁顯示技術(shù)。最早較好地實現(xiàn)這種根據(jù)頁面大小和頁碼來提取數(shù)據(jù)的方法是“俄羅斯存儲過程”。這個存儲過程用了游標,由于游標的局限性,該方法沒有得到很好的應用。

事實上,在查詢和提取超大容量的數(shù)據(jù)集時,影響數(shù)據(jù)庫響應時間的最大因素不是數(shù)據(jù)查找,而是物理的I/0操作。例如我們?nèi)〕鰧W科名為計算機應用技術(shù)的前十名學生信息:

selecttop10*from(

selecttop10000Xh,Xm,HsxwrqfromXueWeiXinXiwhereXkm=''''計算機應用技術(shù)''''

orderbyXhdesc)asaorderbyXhasc

從理論上講,整條查詢語句的執(zhí)行時間應該比子句的執(zhí)行時間長,但事實相反。因為,子句執(zhí)行后返回的是10000條記錄,而整條語句僅返回10條語句,所以影響數(shù)據(jù)庫響應時間最大的因素是物理I/O操作。而限制物理I/O操作此處的最有效方法之一就是使用TOP關(guān)鍵詞了。TOP關(guān)鍵詞是SQLSERVER中經(jīng)過系統(tǒng)優(yōu)化過的一個用來提取前幾條或前幾個百分比數(shù)據(jù)的詞。由于使用Top執(zhí)行查詢操作的效率很高。因此我們可以考慮使用Top關(guān)鍵詞來進行分頁查找,由此可以得到如下分頁算法:

SELECTTOP頁大小*FROMTableWHERE(IDNOTIN

(SELECTTOP頁大小*頁數(shù)idFROM表ORDERBYid))ORDERBYID

和游標存儲過程比起來,該存儲過程在速度上有了很大的提高,而且每次查詢只需要取出當前頁面所需的數(shù)據(jù),不需要加載整個數(shù)據(jù)源,是一個非常優(yōu)秀的分頁存儲過程。但是在該存儲過程中,使用了NOTIN關(guān)鍵字進行數(shù)據(jù)讀取。SQL中的關(guān)鍵詞in不符合SARG,SARG是用于限制搜索的一個操作,它通常是指一個特定的匹配,一個值的范圍內(nèi)的匹配或者兩個以上條件的AND連接。形式如下:

列名操作符<常數(shù)或變量>或<常數(shù)或變量>操作符列名

如果一個表達式不能滿足SARG的形式,那它就無法限制搜索的范圍了,也就是SQLSERVER必須對每一行都判斷它是否滿足WHERE子句中的所有條件。因此在該分頁存儲過程中,notin操作會掃描全表,因此在執(zhí)行速度上依然不是很理想。

分頁優(yōu)化的最終目的就是避免產(chǎn)生過大的記錄集,使用TOP可實現(xiàn)對數(shù)據(jù)量的控制,因此在分頁算法中,影響查詢速度的關(guān)鍵因素有兩點:TOP和NOTIN。TOP可以提高查詢速度,而notin會減慢查詢速度,所以要提高整個分頁算法的速度,就要使用其他方法替換notin。SQL中可以通過max(字段)或min(字段)來提取某個字段中的最大或最小值,所以如果某個字段值不重復,那么就可以利用這些不重復字段的max或min值作為分頁算法中分頁的參照物。因此我們可以用操作符“>”或“<”使查詢語句符合SARG形式,于是可以得出如下分頁方案:

SELECTTOP頁大小FROMTable

WHERE(ID>(SELECTMAX(id)FROM

(SELECTTOP((頁碼-1)*頁大小)idFROMTableORDERBYid)AST))ORDERBYID

其中ID是數(shù)據(jù)庫表的主鍵。如果加上索引,查詢效率會有很大的提高。

表1列出了對有著10萬以上數(shù)據(jù)的學位歷史表,在以SID(SID是主鍵,但并不是聚集索引)為排序列,提取Xh,Xm,Hsxwrq字段,分別以第1、10、100、1000、1萬頁為例,測試以上兩種分頁方案的執(zhí)行速度:(單位:毫秒)

表1兩種分頁方案執(zhí)行速度對比

11010010001萬

方案一30167204704500

方案二7663130250140

從表1中,我們可以看出,兩種存儲過程在執(zhí)行1000頁以下的分頁命令時,都是可以信任的,速度都很好。但第一種方案在執(zhí)行分頁1萬頁以上后速度開始降了下來,而第二種方案卻始終沒有大的變化,在大數(shù)據(jù)量的情況下,特別是在查詢最后幾頁的時候,查詢時間一般不會超過9秒,非常適用于大容量數(shù)據(jù)庫的查詢。

4結(jié)束語

本文介紹的基于Web的研究生學位管理信息系統(tǒng)已經(jīng)投入實際運行中。實踐證明,本系統(tǒng)使用方便,易于管理,安全性高、可移植性好,有效地提高了研究生學位管理工作的自動化水平與工作效率,得到用戶的好評。

參考文獻

[1]陳偉鶴,殷新春等.基于任務和角色的雙重Web訪問控制模型[J].計算機研究與發(fā)展,2004,41(9):1466-1473

[2]趙燕飛,朱飛,孫玉星.一種基于Web的分布式應用程序框架的構(gòu)建技術(shù)[J].計算機工程與應用2004,36(36):168-170

[3]張曉輝,王培康.大型信息系統(tǒng)用戶權(quán)限管理[J].計算機應用.2000,20(11):35-36