引論：我們為您整理了13篇圖書管理系統論文范文，供您借鑒以豐富您的創作。它們是您寫作時的寶貴資源，期望它們能夠激發您的創作靈感，讓您的文章更具深度。
篇1
過去,大多數學校圖書館都是封閉式管理,通過卡片登記借閱信息,只能實現有限的流通,有的甚至不能正常對學生開放,使得圖書館不能發揮應有的作用;即使是實現了正常流通的,也不能提供領導管理上需要的各種信息如本館各種資料分布及借閱(流通)情況。
目前,我國學校圖書館辦館的要求及領先標志就是藏書全部開放,師生共享開架借閱。這種借閱方式是當前適合我國國情的發揮圖書館應有作用的最佳方式,也是素質教育的最好體現。它充分發揮了圖書館的功效,最大限度地為讀者服務,這也是圖書館自動化管理的最終目標。實現這一目標,必須有現代化的管理手段和管理體制。為此,各地教育主管部門都逐步提出學校要采用圖書館管理系統,從而實現人工管理達不到的一些功能并發揮圖書館的最大效益。而隨著越來越多的學校采用了現代化的管理軟件進行管理,進一步提升了學校管理的現代化水平,從而在競爭中處于有利位置,也對其他兄弟學校起到了示范和促進作用。自身發展的需要和上級部門的要求以及競爭的需要決定了學校采用圖書館管理系統的必要性。
以計算機技術、存儲技術、通訊技術為主要內容的現代信息技術的發展,使人類進入了一個嶄新的信息時代。作為信息資源存儲、傳遞的專業機構,圖書館如何在新的技術條件下,適應形勢發展,發揮自身優勢,開拓信息渠道,更好地為用戶服務,是一個新課題。也必將對現有的圖書館產生全面而深遠的影響。因此,正確認識信息時代對圖書管理工作的要求,使圖書館工作變得更加便利和高效,使資源共享更容易實現,為讀者提供更加優質的服務十分重要。
在信息時代,各種冠以“數字圖書館”之類說法的圖書館現代化論斷到處可見。那么什么是圖書館的現代化呢?判斷一個圖書館的現代化程度,應該從圖書館最本質的特性判斷。圖書館具有信息資源的收集保存、加工整理并使之有序化及傳遞信息資源的功能。這一點是書店和網站都無法做到的,也是圖書館最本質的特性,是圖書館賴以生存的基礎。判斷圖書館的現代化程度,也應該從這個最本質的特性來判斷。
二、成熟的圖書管理系統決定因素
任何一套圖書館管理系統至少必須具備這樣一些功能:對圖書進行編目也就是采集信息并上架、圖書檢索(查找)、圖書流通(借還)。然而僅僅有這些功能是不能稱為真正的現代化的管理型圖書館管理系統的。筆者認為,一套系統是否成熟還決定于以下幾個方面:
1、符合相關的標準
例如教育部最新頒布的《教育管理信息化標準》規范、我國圖書館界通用的CNMARC格式標準、目前通用的《中圖法四》等。
《教育管理信息化標準》的頒布將為教育部門對教育數據進行總體的規劃和組織,建立起統一的數據平臺提供有力的技術保證;它將帶動教育管理信息存儲、訪問、更新、傳遞方式的變革,進一步減輕學校人力資源和財政管理的負擔。
CNMARC是在UNI-MARC(國際通用MARC)的基礎上發展起來的,它有479個字段,這些字段是針對能著錄多種文獻類型及多文種文獻而制定的,數據格式結構復雜繁多,使用時,用其所有字段,只需結合著錄的文獻類型與文種等實際情況選擇適用的機讀目錄格式字段形成數據。
中圖法全稱是《中國圖書館分類法》,是我國建國后編制出版的一部具有代表性的大型綜合性分類法。其編制始于1971年,先后出版了四版。自1999年第四版起更名為《中國圖書館分類法》,簡稱不變,英文譯名為ChineseLibraryClassification,英文縮寫為CLC。由于國家圖書館1975年以后的文獻(善本除外)都采用中圖分類法,館藏目錄檢索系統也提供“中圖分類號”檢索字段,了解中圖分類法有助于讀者準確地查詢到需要的文獻資源
2、開發工具及所采用的數據存放格式要求先進
有些人認為只要看看功能和界面是否令人滿意就行了,其他的與我們沒有多少關系,實際上開發工具及方式和數據格式的存放方式決定了系統的穩定性和性能以及未來的可升級維護性。目前國內絕大多數系統在Windows下運行,最先進流行的開發工具是美國Borland公司的Delphi及Microsoft公司的VC++,后臺數據庫一般采用微軟的SQLServer或Sybase大型數據庫產品。
3、功能是否強大
目前,一般主流的系統包括系統管理、讀者管理、編目、流通、統計、查詢等功能。比較先進的能夠在一個界面下實現圖書、音像、期刊的管理,設置假期、設置暫離鎖(提高安全性)、暫停某些讀者的借閱權、導入導出讀者、交換MARC數據、升級輔助編目庫等。此外,由于學校校園網絡的逐步建立,一個完善的系統還應提供無縫接入校園網的WEB功能,通過IE瀏覽器讓讀者使用借閱資料查詢、更換密碼、預約、資料檢索等功能。有些系統還能提供讀者自助服務,可以開放一些客戶機讓讀者自行管理密碼、查詢自己的借閱史、預約資料、檢索資料等。
4、要有足夠的安全性
安全性一般涉及到操作權限控制和數據自動備份兩方面。主流系統都實現了由管理員分配各操作員可使用的功能并設置其密碼,各操作員均需先登錄系統然后再操作各種允許使用的功能。一個完善的系統還應對各操作員的登錄、退出及重要操作記錄在操作日志中。同時還應提供完善的自動備份服務,以實現數據的全自動按計劃備份,從而最大限度地保障您的數據安全。
5、要有足夠大的輔助編目庫
在對圖書進行編目也就是信息采集時,如果我們通過掃描圖書的ISBN號條碼就能得到大多數書的書名、作者、出版社等各種標準信息,則我們的編目準確性和效率將會得到極大的提高。這就要求有一個比較完善的準確的輔助編目庫。這也是一個容易被學校忽視而軟件開發商有意回避的問題。
6、要具有完善的規則
除了能夠設置讀者的借閱規則外,還應自動實現一些圖書館界通用的管理規則,例如有在借資料的讀者是不能被刪除的,有以下情況的讀者是不能借閱的:某類書的借閱數已達到最大值、有超期資料、有未繳罰款、被暫停借閱等。
7、簡單易用
一個好的系統應具有清楚的操作界面,最簡化的操作過程。日常工作中操作員通過手持式條碼閱讀器應該可以完成絕大部分工作。需要注意的是有些系統將精力花在華麗的界面上,而忽視了用戶真正需要的是實用的完善的功能。
8、有先進的體系結構
當前主流系統采用客戶機服務器(Client/Server)+瀏覽器/服務器(Browser/Server)模式,所有信息均存放在數據庫服務器上,各客戶機通過網絡與數據庫服務器通訊,WEB服務通過ADO模型訪問數據庫服務器,數據與應用安全地隔離,可確保數據存放的安全性。當然在具體選擇中還需考慮是否得到主管部門例如省電教館等推薦及性價比等。
隨著數字化技術的飛速發展,人類正邁向一個以數字化技術革命為中心的新時代。這一新時代最明顯的特征便是全球范圍內的網絡革命。這場革命催生出的數字化信息網絡,大大改善了我們所處的信息環境,信息的類型和形式變得更加復雜,人類信息傳播的途徑及獲取信息的方法,都發生了前所未有的變化,它不僅改變了圖書館信息服務的方式,同時也對圖書館的情報用戶提出了嚴峻的挑戰。
三、圖書管理系統現代化程度的標準
1、信息資源收集的現代化
現代社會信息資源豐富,信息污染也很嚴重,給圖書館信息資源的收集帶來了極大麻煩。傳統圖書館時期,由于各種信息資源極大部分由正規渠道獲得,經過圖書期刊編輯人員的認真校對,信息質量相對可靠。而現代化信息的載體以及出版發行方式發生了很大變化,各種光盤、印刷品、網上信息、聲像讀物等良莠不齊。這就要求圖書館采編人員掌握多方面的信息源,運用現代化的各種手段,對各種信息做出盡可能正確的判斷
2、信息加工整理的現代化
在傳統圖書館時期,文獻資源的分類加工整理比較簡單,所揭示的文獻信息深度有限,對文獻的內在性質、內容的揭示基本沒有。圖書館應用計算機進行分類編目,給文獻內容的揭示帶來了一定的改進,但無實際性的改革。計算機所具有的快速處理數據的能力遠遠沒有發揮出來。信息加工的目的是為了使信息資源有序化,以便于更好地查找和使用文獻信息,如果在文獻信息加工整理上不能實現統一標準的規范,圖書館現代化的物質基礎就不存在
3、圖書館服務的現代化
服務是圖書館的生命。圖書館所做的一切工作,只有一個目的,就是做好圖書館的讀者服務工作。服務的現代化包括兩個方面,一是圖書館工作人員服務的現代化,二是服務手段的現代化。
觀念的現代化要求我們改變原來重管理輕服務的思想,把以讀者為中心真正落到實處,發揮圖書館工作人員的主觀能動性,積極收集各種文獻信息資源。在現代化圖書館時期,判斷一個圖書館的大小是以圖書館獲取信息的能力,提供服務的能力來決定的由于現代化的圖書館是一個有機的網絡,各種信息資源許多都是公開的、共享的.只要有一定的專業技能和一切以讀者為中心的服務觀念,圖書館的服務工作可以比傳統時期有一個質的飛躍。
判斷服務手段的現代化也應該用“一切以讀者為中心”這一圖書館的服務宗旨來判斷。如果圖書館提供的文獻資源必須使用電腦才能得到,這對讀者來說就是服務不好,因為他的要求沒有得到滿足。現代化服務手段真正的含義應該是圖書館根據讀者不同需要,提供適合各種不同類型的服務方式。
總之,我們通過對圖書管理系統的分析,對管理系統在其他情況下的應用,有了一個基礎性的了解與掌握。同時,對熱門圖書的科學管理,進一步提高其利用率,不斷滿足讀者日益旺盛的閱讀需要,有著十分積極的現實意義。
【參考文獻】
[1]顧俐.圖書館圖書管理系統的設計.《中國科技信息》.2007.11.
[2]孫麗莉.圖書管理系統論.《中國科技信息》.2007.1.
[3]馬慧生、王樹芬.對我校圖書館數字化的建議.《桂林航天工業高等專科學校學報》.2005.10.3.
[4]張霞.數字圖書管理系統及其相關技術探究.《安陽大學學報:綜合版》.2003.3.
篇2
為了研究用戶模型，首先研究用戶如何使用云平臺下的圖書檔案管理系統，用戶接入到圖書檔案管理系統，必須使用終端，通過網絡接入。在這個過程中，終端呈現異構化、復雜化、多樣化的特征，①終端目前可能使用電視網、電信網和計算機網中的任何一網，可以通過WLAN、WWAN、Internet、PLMN、HFC、傳統CATV、Ethernet和OAN中任何一網，隨著時代和科技的發展也可能使用其他網絡，其網絡方面的特征呈現異構化、多樣化；②終端類型和型號都很多，其功能、用途等明顯不同，造成構造的不同和復雜化；終端和網絡的異構化、復雜化、多樣化，造成了其效果差異化很大，主要體現在：①顯示效果方面；②音效效果方面；③網絡方面；④計算復雜度方面；⑤可用空間方面。從顯示效果的角度來看，需要注意以下幾點：①終端不同，其顯示屏幕的大小不同，從這個角度來說，手機和電視的差距是最為顯著的之一，筆記本、PC等終端設備屏幕往往適中，顯示屏幕大小的不同一方面和用戶持有終端是否便利有關，另一方面關系著用戶瀏覽信息資源時屏幕的尺寸和效果。②終端不同，其顯示所使用的分辨率不同，體現為顯示時的效果明顯不同，如顯示時的清晰細膩程度、拍照取景和視頻播放的效果等等，而且部分終端的分辨率是固定不變的，無法進行調節。③文件的格式不同，其顯示效果可能不同，例如常見的視頻格式有AVI、MPEG、DIVX、MOV、ASF、WMV、RM等，不同的格式記錄相同的視頻信息，其顯示效果也可能完全不同。④顯示效果的程度決定了用戶視覺角度質量的高低，其對于文本、圖片、圖像、單一的視頻是有決定性作用的，同時對多媒體信息資源的效果也是有一定影響的。⑤顯示效果的程度所帶來的影響，對于不同的用戶是不同的，其高度影響高度依賴視覺的用戶，但當用戶不依賴于視覺的時候影響則不大。從音效效果方面來看，需要注意以下幾點：①終端硬件不同，其發聲所用的效果不同，即使終端硬件相同其發聲的效果也可能不同，例如一臺筆記本電腦，如果其聲卡是集成的則往往沒有獨立的聲卡效果好，同樣不同廠商所生產的聲卡效果往往也有一定的差別，不同時間、不同技術所生產的聲卡效果也往往不同，但音效效果在設備、設置、播放內容等完全相同的前提下是一致的。②不同的音頻文件，其效果可能不同，首先數字音頻技術指標采樣率、壓縮率、比特率、量化級，分別控制單位時間內波形采樣的數據數量、音樂文件壓縮前后大小的比值、記錄每記錄音頻數據一秒鐘所消耗的比特值的平均值、用多少位二進制的數據描述的聲音波形；其次，不同的音頻文件格式不同，其音效的效果也可能不同，常見的音頻文件格式有WAV、MP3、WMA、OGG、APE等。③對于部分終端來說，音效效果是可以調節的，但依然存在音效無法調節的終端。④音頻效果的程度所帶來的影響，對于不同的用戶是不同的，其高度影響高度依賴聽覺的用戶，但當用戶不依賴于聽覺的時候影響則不大。從網絡的角度來看，①目前大部分的電視網依然是單向的，也就是說存在單向和雙向的問題，雖然隨著時代的發展和技術的進步，單向和雙向的問題最終會被解決，但是目前一段來說其依然是問題的一部分。②網絡不同登陸方式可能不同，例如如果用戶借助電信網登陸和使用服務有兩種模式，其一是通過以點播為基礎的短信息服務，需要利用短信服務的平臺來傳輸信息，由于其平臺經常是第三方提供的，因而實時性往往較差；第二種方式則是通過GPRS網絡，這種方案的缺點是覆蓋率較差、傳輸速度低、費用高，但可以實現實時。從計算復雜度方面來看，終端之間的差異很大，以電視網的機頂盒和電視機來說，即使運行一個非常簡單的動畫也會非常困難，而相同的困擾在計算機上往往不存在，換句話說計算復雜度高的資源無法在部分終端上運行，但同時部分終端上如果使用計算復雜度低的文件則也會浪費資源。從某種程度上來說，不同的終端適合使用的信息資源在內容、格式等方面是完全不同的。從可用空間的角度看，如果可用空間的大小無法支持對應的操作，則后續的操作無法進行，同時可用空間較小也會在一定程度上降低運算速度。對于可用空間的大小，不同的用戶可能會有不同的定義，部分用戶可能對終端的最小可用空間有自己的要求；還有一部分人對最小可用空間沒有要求，但是最小可用空間不夠用的時候會有自己期望的行為和操作。
1.2用戶行為研究
用戶的行為，①指用戶使用云平臺下圖書檔案管理系統的行為，其根據用戶的身份、目的、習慣、興趣等不同而不同，用戶可能是進行檢索、獲得、修改、保存信息資源，也可能是對圖書檔案管理系統的管理，如計費等；既包括其行為的種類、參數，同時還應該包括其行為所導致的結果。②用戶的行為受到其本身的制約，既要受到其身份影響，又受到其興趣和目的影響，但最終通過行為表現出來，可以通過用戶的行為獲得用戶的信息，并做出調整，以便更精確地認識和了解用戶。
1.3用戶偏好研究
用戶偏好，指用戶在考慮服務或者商品的時候按照其自身意愿所做出的帶有傾向性的符合理性的選擇，是用戶理性、認知和心理感受權衡后的綜合結論，是用戶個性化的體現。在云計算平臺下的圖書檔案管理系統中，其可以作為個性化服務推薦的基礎，主要包括以下幾個方面的內容，①由終端、網絡等帶來的與視頻、音頻、可用空間等有關的偏好信息，此偏好信息用于確認用戶偏好的信息資源的模態類信息，在此類偏好中用戶往往偏愛一種或者幾種終端，同時對于不同終端參數設置有不同的偏好；②用戶偏好的信息資源內容方面的信息，包括學科、方向、難度等，這種偏好主要來源于用戶原有的背景如職業、專業、知識層次等，并隨著用戶的發展而改變；③其他偏好，主要包括終端、所途經的網絡、所在的位置等；④用戶ID,用以唯一地標識和區別用戶。
2用戶模型研究
2.1用戶基本信息模型
根據對用戶、終端、網絡的研究，建立用戶基本信息模型，包括三類信息，分別是用戶信息、終端信息和網絡信息（詳見圖1）。其一是用戶信息如用戶ID、姓名、身份、年齡、知識層次、密碼、密碼提示問題、組別，其中①用戶ID、密碼是不可以省略的，其需要在用戶登陸的時候確定用戶的基礎信息，同時用戶ID對于整個系統來說是唯一的，也就是說所有用戶的ID是沒有重復的，是“獨一無二”的；②身份、年齡、知識層次三項可以用于輔助確定用戶的身份，以便在后續用戶偏好模型未獲得具體信息之前初步判斷和獲得用戶的偏好信息，但鑒于部分用戶的特殊性某些情況下是允許被省略的；③用戶信息可以通過組別確定用戶的權限的確認。其二是終端信息包括終端ID、終端參數等，其中①終端ID用于確定接入和登陸到圖書檔案系統的終端的身份，通過檢索對應于終端的數據表可以獲得包括其使用者、終端的類型、終端的基本參數及范圍、終端的可能配置等的信息，可以初步確定終端的信息；②終端參數包括的是顯示參數、音效參數、計算復雜度參數、可用空間參數，顯示參數和音效參數分別是用戶提供的其習慣使用的顯示、音效參數的設置，而計算復雜度參數需要通過終端ID判斷用戶終端的具體計算復雜度獲得，可用空間則需要在圖書檔案系統運行的時候通過其與終端之間的通訊獲得；③終端信息中終端ID是不可以缺省的，但終端參數是可以缺省的，在缺省的狀態下，系統依然可以通過終端ID獲得終端的類型及基礎的參數范圍，再根據參數范圍進行其他的判斷，同時由于計算復雜度參數和可用空間參數不需要用戶提供，因而也可以在缺省的情況下獲得。其三則是網絡信息如網絡類型、常見位置等，其中①電視網的單雙向問題可能會帶來新的問題需要給予重點關注；②常見位置，是用戶通常使用終端接入和使用圖書檔案管理系統服務的位置；③網絡ID，用以唯一地標識和區別網絡。關于用戶基本信息模型，需要注意的有：①用戶基本信息模型雖然是由三個部分組成的，但是其是一個整體，可以通過數據庫表示出來，其中的每一條記錄都只說明的是在某一種情況下用戶使用某種終端通過某種網絡接入和使用圖書檔案管理系統的具體設置以及由此而來的各種參數，每個用戶的具體信息可以不只一條而是若干條記錄的組合。②用戶基本信息模型的三個子模型，可以通過一個數據表體現，也可以分成用戶信息表、終端信息表、網絡信息表三個數據表的組合來實現。
2.2用戶行為模型
用戶行為模型，主要用于記錄用戶的行為、狀態等信息，其由用戶ID、用戶行為、行為參數、狀態參數三個部分組成，其中①用戶的行為用于記錄用戶狀態變化的原因，同時可以從中獲得用戶基本信息模型的部分信息，同時也可以完善用戶偏好模型；②用戶行為參數用于說明用戶行為的細節，是用戶行為有機的補充；③狀態參數，用于表明經過用戶的行為之后用戶的變化。
2.3用戶偏好模型
用戶偏好模型是用戶服務推薦的基礎，其主要包括3個方向，其一是對所獲取資源的模態傾向性，是與終端相關的，其中包括格式、顯示性能、音效性能等,其大多數屬性是范圍；其二則是對信息資源內容的傾向性，主要包括用戶的身份、年齡、知識層次、專業等；其三則是用戶通常所在的位置區域，可以用于以就近原則對其提供服務。
3關鍵技術分析
3.1用戶模型應用研究
從用戶登陸并使用系統服務的角度看用戶模型，用戶通過終端接入計算機網、電信網和電視網三網中的一網，可以利用一體化標識網絡技術連接到系統，通過終端ID確定終端的身份（終端信息模型），通過終端所在的位置、IP等可以獲得對應的網絡信息（網絡信息模型），通過用戶ID和密碼登陸系統進而系統可以確定登陸的用戶（用戶信息模型），如果需要調用用戶偏好模型可以根據用戶ID在用戶偏好模型中檢索相應的記錄則找到對應用戶偏好的信息（用戶偏好模型），用戶使用過程中會有所操作記錄下用戶ID、相關操作及對應參數則可以將信息添加到用戶行為模型，根據用戶ID可以從用戶行為模型獲取相關的參數則可以獲得對應信息據此可以修改和完善其他模型。對于用戶模型的應用，本文認為：①對于信息資源的檢索和使用，既涉及到用戶對信息資源模態的偏好，又要涉及到用戶對信息資源內容的偏好，同時還涉及到用戶所使用的終端；在檢索的時候首先要根據終端信息模型和網絡信息模型判斷終端和網絡的特性，獲得支持的模態的信息，獲得顯示、音效、網絡、計算復雜度、可用空間等信息，再根據這些信息和模態結合結合用戶的偏好以集合的形式進行交的運算進而縮小可以接受的信息資源的模態范圍并將其作為用戶即時信息資源模態的偏好，再通過用戶偏好模型內容傾向類偏好可以獲得用戶對信息資源內容的偏好。②顯示、音效、網絡、計算復雜度、可用空間等的變化會帶來很多不同的情況，需要形成對應的策略，該策略既要符合用戶的意愿，又要符合運營商等商家的利益，同時必須符合法律法規并受到相關部門的監管。在實踐的過程中，可以設置相應的閾值來劃分對應的范圍，根據閾值與當前值差別的組合來判斷當前所處的情況，當差距過大或者達到閾值的時候可以按照對應的既定策略采取行動，如在許可的情況下重新生成對應的信息資源、只發送部分信息資源、壓縮等。③用戶基本信息模型中用戶信息模型、終端信息模型和網絡信息模型需要相互結合，是一個有機的整體，在使用的時候相互輔助；同時用戶基本信息模型、用戶行為模型和用戶偏好模型也是一個有機整體，其通過用戶ID彼此關聯。用戶ID在整個模型中是唯一的，其作用是唯一地標識一個用戶，以便與其他用戶區別。
3.2用戶模型的初始化與完善
本文認為用戶模型的初始化信息可以從以下幾個方面獲得：①用戶注冊的信息②利用調查研究等方式從側面獲得的用戶信息；③利用公眾的大眾化特征獲得，其實質是首先獲得用戶基礎信息模型，然后再從用戶基礎信息模型獲取數據，以基礎信息模型數據為基礎結合概率歸類和整理，去生成用戶偏好模型和用戶行為模型的初始數據。本文認為用戶模型的信息完善與補充，是一個不斷學習和修正的動態反饋過程，通過機器學習對參數的重新估計和修正提高了預測的精度，進而提高服務的質量，可以為個性化服務推薦打下基礎。其實質是通過訓練來逐漸完善用戶行為模型，再根據用戶行為模型逐步完善用戶基礎信息模型和用戶偏好模型。具體的實現上，本文認為①用戶行為模型可以作為執行單元，學習單元通過用戶行為模型提供的信息根據用戶基本信息模型和用戶偏好模型建立并改進知識庫，執行單元格局知識庫中的知識執行任務，再將執行后的信息反饋到用戶行為模型作為下一步學習的資源。②可以用命令序列作為最小單元描述用戶行為，通過定義兩個序列、兩個狀態之間的相似度來代表和判斷行為模式之間、狀態之間的相似程度；模型工作的時候，計算序列相似度來判斷行為和狀態的變化。
篇3
第一章對數據庫應用系統開發和圖書管理系統進行了簡明的介紹，并分析了開發圖書管理系統所應進行的工作。
第二章對數據庫的設計和SQL語言的使用進行了系統分析，為深入理解數據庫應用打下了基礎。
第三章學習了具體的開發工具Delphi6.0，對其數據庫組件，SQL語言在Delphi中的應用等數據庫編程關鍵技術進行了系統的介紹。
第四章分析了圖書管理信息系統的應用需求，按照數據庫設計理論一步一步地給出了系統需求說明書、局部ER圖、全局ER圖、系統關系模式，子模式，利用MSSQLServer2000建立了數據庫
第五章進行了具體的程序設計，具體劃分了三類用戶的操作權限，設計了了三個操作界面。實現了數據庫表的瀏覽，記錄的添加、刪除和修改，報表的生成，實現了多數據庫表的連接操作，實現了多條件查詢和模糊查詢，并靈活實現了對不可更新查詢結果集的更新操作，實現了主從表操作，實現了密碼維護功能，最后，系統還可以導入數據庫以對任意同結構的數據庫進行操作。
設計充分利用Delphi6、MSSQLServer2000數據庫技術的強大力量，提高了編程效率和可靠性。
關鍵詞：數據庫，SQL語言，MSSQLServer，Delphi6，
數據庫組件，圖書管理，窗體，listview組件
目錄
摘要………………………………………………………………………………I
第一章緒論……………………………………………………………………1
§1.1數據庫應用系統開發簡介………………………………………………1
§1.2圖書管理系統………………………………………………………4
§1.3本文所做的主要工作……………………………………………………6
第二章數據庫理論基礎…………………………………………………………7
§2.1數據庫系統設計及范式分析……………………………………………7
§2.2SQL語言介紹…………………………………………………………………11
2.2.1SQL基礎…………………………………………………………………11
2.2.2SQL語句…………………………………………………………………12
第三章應用系統開發工具…………………………………………………16
§3.1Delphi6.0VCL組件的體系結構………………………………………16
§3.2數據庫組件介紹……………………………………………………………17
§3.3SQL語言在Delphi中的應用……………………………………………18
§3.4MSSQLServer簡述……………………………………………………22
第四章圖書管理系統設計分析…………………………………………24
§4.1應用需求分析……………………………………………………………24
§4.2系統功能模塊劃分………………………………………………………29
§4.3系統數據庫設計…………………………………………………………29
第五章圖書管理系統應用程序設計……………………………………37
§5.1系統窗體模塊組成…………………………………………………………37
§5.2數據模塊窗體的設置………………………………………………………37
§5.3啟動畫面的實現……………………………………………………………38
§5.4用戶登錄窗體的的實現………………………………………………………39
§5.5用戶密碼認證窗體的的實現…………………………………………………39
§5.6借閱者服務模塊的實現……………………………………………………40
5.6.1圖書查詢功能的實現…………………………………………………41
5.6.2借閱者登錄功能的實現…………………………………………………42
5.6.3借閱者借閱情況功能的實現……………………………………………43
5.6.4借閱者個人資料維護功能的實現………………………………………47
§5.7工作人員－圖書借閱/歸還模塊的實現………………………………………49
5.7.1工作人員進行圖書借閱功能實現………………………………………50
5.7.2工作人員進行圖書歸還功能實現………………………………………53
§5.8圖書館管理員模塊的實現……………………………………………54
5.8.1圖書館管理員圖書管理功能的實現……………………………………55
5.8.2圖書館管理員工作人員和管理員管理功能的實現……………………58
5.8.3圖書館管理員修改圖書類別及統記功能的實現………………………60
5.8.4圖書館管理員借閱者管理功能的實現…………………………………62
5.8.5圖書館維護借閱者管理功能的實現…………………………………62
5.8.6圖書館身份維護功能的實現………………………………………64
5.8.7圖書館借閱者統計功能的實現…………………………………65
5.8.8圖書館統計借閱過期記錄功能的實現…………………………67
§5.9系統信息顯示的實現…………………………………………………68
第六章結束語………………………………………………………………69
致謝………………………………………………………………………………70
參考書目……………………………………………………………………………70
第一章緒論
§1.1數據庫應用系統開發簡介
在數據庫應用系統開發之前，對開發數據庫的基本概念應當了解，對數據庫的結構、開發數據庫應用程序的步驟、開發體系及方法都應當有相當清晰的了解和認識。
數據庫應用系統開發的目標是建立一個滿足用戶長期需求的產品。開發的主要過程為：理解用戶的需求，然后，把它們轉變為有效的數據庫設計。把設計轉變為實際的數據庫，并且這些數據庫帶有功能完備、高效能的應用。
數據庫技術在計算機軟件鄰域研究中一直是非常重要的主題，產生于60年代，30多年來數據庫技術得到了迅速發展，并已形成較為完整的理論體系和一大批實用系統。并且，近年來，隨著WorldWideWeb(WWW)的猛增及Internet技術的迅速發展，使得數據庫技術之時成為最熱門技術之一。
1.1.1數據庫
如圖1.1顯示了數據庫系統的主要組件。數據庫由DBMS（數據庫管理系統）處理，DBMS則由開發人員和用戶通過應用程序直接或間接地使用。它主要包括四個要素：用戶數據、元數據、索引和應用元數據。
1.1.1.1用戶數據
目前，大多數主流數據庫管理系統把用戶數據表示為關系。現在把關系看作數據表。表的列包含域或屬性，表的行包含對應業務環境中的實體的記錄。并非所有的關系都同樣符合要求，有些關系比其它關系更結構化一些。第二章描述了一個用以產生良好結構關系的過程，稱作規范化。
為了對比結構差的關系和結構好的關系之間的差別，以本文所設計的圖書管理系統中的圖書和圖書借閱者關系為例來說明，假若設計關系R1（借書證號，姓名，性別，身份編號，身份證，聯系電話，圖書編號,圖書名稱，圖書類別，作者，出版社，出版日期，備注，價格，數量）；這個關系的問題出在它有關于兩個不同主題的數據，就是圖書借閱者和圖書。用這種方式構成的關系在進行修改時，會出現問題。因為一個圖書借閱者可能借閱多本書，如果某個圖書借閱者的某個字段（如聯系電話）出現變更，它所借閱的圖書記錄（可能多個）也就必須變化，這是不好的。因此數據用兩個關系表示更好?，F在如果某圖書借閱者改變了它的聯系電話，只有關系（表）user的對應行需要改變。當然，要想產生一個，顯示圖書名稱及其借閱者聯系電話的報表，就需要將這兩個表的行結合起來。結果表明，將關系分別存儲，在生成報表的時候將它們結合起來，比把它們存儲在一個合成的表中更好。
user（借書證號，姓名，性別，身份編號，身份證，聯系電話，）
book（圖書編號,圖書名稱，圖書類別，作者，出版社，出版日期，備注，價格，數量）
1.1.1.2元數據
數據庫是自描述的，這就意味著它自身包含了它的結構的描述，這種結構的描述稱作元數據。因為DBMS產品是用來存儲和操縱表的，所以大多數產品把元數據以表的形式存儲，有時稱作系統表。這些系統表存儲了數據庫中表的情況，指出每一個表中有多少列，那一列是主關鍵字，每一列的數據類型的描述，它也存儲索引、關鍵字、規則和數據庫結構的其他部分。
在表中存儲元數據不僅對DBMS是有效的，對用戶也是方便的，因為他們可以使用與查詢用戶數據同樣的查詢工具來查詢元數據。本文第二章所介紹的SQL語言可以同時用于元數據和用戶數據。
1.1.1.3索引
第三種類型的數據改進了數據庫的性能和可訪問性，這種數據經常稱作開銷數據，盡管有時也采用其他類型的數據結構，如鏈表，但它主要還是索引。索引可以用來排序和快速訪問數據。下面以本人的圖書管理信息系統中的book表為例來說明。
假定數據在磁盤上是按’圖書編號’的遞增順序排列的，用戶想打印一個按’圖書名稱’排序的圖書數據報表。為此，所有的數據都需要從源表中提取出來并排序，除非表很小，否則這是一個很費時的過程?；蛘?，可以在‘圖書名稱’字段上創建一個索引，該索引的條目按照‘圖書名稱’排序，這樣，該索引的條目可以讀出來，并用來按順序訪問book數據。
索引用于快速訪問數據。例如，一個用戶只想訪問book表中‘圖書類別’值為‘01’的那些學生。如果沒有索引，則必須搜索整個源表；但有了索引之后，可以找到索引條目，并使用它來挑選所有合適的行。
索引對排序和查找是有幫助的，但要付出代價。book表中的行每次改變時，索引也必須改變，這意味著索引并非隨意的，應該在真正需要時保存。
1.1.1.4應用元數據
存儲在數據庫中的第四種數據是應用元數據，它用來存儲用戶窗體、報表、查詢和其他形式的查詢組件。并非所有的DBMS都支持應用組件，支持組件的DBMS也不一定把全部組件的結構作為應用元數據存儲在數據庫中。然而，大多數現代的DBMS產品存儲這種數據作為數據庫的一部分。一般來說，數據庫開發人員和用戶都不直接訪問應用元數據，想反，他們通過DBMS中的工具來處理這些數據。
MSSQLServer2000中就支持窗體、存儲過程等應用元數據。
1.1.2數據庫管理系統
數據庫管理系統（DBMS）是指數據庫系統中管理數據的軟件系統。DBMS是數據庫系統的核心組成部分。對數據庫的一切操作，包括定義、更新及各種控制,都是通過DBMS進行的。DBMS總是基于某種數據模型，可以把DBMS看成是某種數據模型在計算機系統上的具體實現。根據數據模型的不同，DBMS可以分成層次型、網狀型、關系型、面向對象型等。MSSQLServer2000就是一種關系型數據庫管理系統。
關系模型。關系模型主要是用二維表格結構表達實體集，用外鍵表示實體間聯系。關系模型是由若干個關系模式組成的集合。關系模式相當于前面提到的記錄類型，它的實例稱為關系，每個關系實際上是一張二維表格。
關系模型和層次、網狀模型的最大判別是用關鍵碼而不是用指針導航數據，表格簡單用戶易懂，編程時并不涉及存儲結構，訪問技術等細節。關系模型是數學化模型。SQL語言是關系數據庫的標準化語言，已得到了廣泛的應用。
如圖1.1所示，DBMS的特點和功能可以分為三個子系統：設計工具子系統、運行子系統和DBMS引擎。
設計子系統有一個方便數據庫及其應用創建的工具集。它典型地包含產生表、窗體、查詢和報表的工具。DBMS產品還提供編程語言和對編程語言的接口。
運行子系統處理用設計子系統開發的應用組件。它所包含的運行處理器用來處理窗體和數據庫的數據交互，以及回答查詢和打印報表等。
DBMS引擎從其他兩個組件接受請求，并把它們翻譯成對操作系統的命令，以便讀寫物理介質上的數據。DBMS引擎還涉及事務管理、鎖、備份和恢復。
1.1.3創建數據庫
1.1.3.1數據庫模式
數據庫模式定義了數據庫的結構、表、關系、域和業務規則。數據庫模式是一種設計，數據庫和應用正是建立在此基礎上的。
域是一列可能擁有的值的集合。必須為每一個表的每一定域。除了數據的物理格式外，還需要確定是否有些域對表來說是唯一的。
數據庫模式的最后一個要素是業務規則，它是對需要反映在數據庫和數據庫應用程序中的業務活動的約束。業務規則是模式的一個重要部分，因為他們指定了無論什么數據變化到達DBMS引擎，允許的數據值必須滿足的約束。不管無效的數據變化請求是來自窗體的用戶、查詢/修改請求還是應用程序，DBMS都應該拒絕。
遺憾的是，不同的DBMS產品用不同的方法實施業務規則。在某些情況下，DBMS產品不具備實施必要業務規則的能力，必須以代碼形式把它們編入應用程序。
1.1.3.2創建表
1.1.3.3定義聯系
1.1.4應用組件
數據庫應用包括窗體、查詢、報表、菜單和應用程序。
§1.2圖書管理系統
當今時代是飛速發展的信息時代。在各行各業中離不開信息處理，這正是計算機被廣泛應用于信息管理系統的環境。計算機的最大好處在于利用它能夠進行信息管理。使用計算機進行信息控制，不僅提高了工作效率，而且大大的提高了其安全性。
尤其對于復雜的信息管理，計算機能夠充分發揮它的優越性。計算機進行信息管理與信息管理系統的開發密切相關，系統的開發是系統管理的前提。本系統就是為了管理好圖書館信息而設計的。
圖書館作為一種信息資源的集散地，圖書和用戶借閱資料繁多，包含很多的信息數據的管理，現今，有很多的圖書館都是初步開始使用，甚至尚未使用計算機進行信息管理。根據調查得知，他們以前對信息管理的主要方式是基于文本、表格等紙介質的手工處理，對于圖書借閱情況（如借書天數、超過限定借書時間的天數）的統計和核實等往往采用對借書卡的人工檢查進行，對借閱者的借閱權限、以及借閱天數等用人工計算、手抄進行。數據信息處理工作量大，容易出錯；由于數據繁多，容易丟失，且不易查找?？偟膩碚f，缺乏系統，規范的信息管理手段。盡管有的圖書館有計算機，但是尚未用于信息管理，沒有發揮它的效力，資源閑置比較突出，這就是管理信息系統的開發的基本環境。
數據處理手工操作，工作量大，出錯率高，出錯后不易更改。圖書館采取手工方式對圖書借閱情況進行人工管理，由于信息比較多，圖書借閱信息的管理工作混亂而又復雜；一般借閱情況是記錄在借書證上，圖書的數目和內容記錄在文件中，圖書館的工作人員和管理員也只是當時對它比較清楚，時間一長，如再要進行查詢，就得在眾多的資料中翻閱、查找了，造成查詢費時、費力。如要對很長時間以前的圖書進行更改就更加困難了。
基于這此問題，我認為有必要建立一個圖書管理系統，使圖書管理工作規范化，系統化，程序化，避免圖書管理的隨意性，提高信息處理的速度和準確性，能夠及時、準確、有效的查詢和修改圖書情況。
§1.1系統所做工作
1)了解應用開發工具的現狀
2)DelPHi6.0編程基礎
3)MSSQLServer基礎
4)設計數據庫；設計界面
5)開發數據庫。數據庫實現的一些功能有
l數據和數據說明的醒目顯示；
l多條件的查詢、多條記錄的檢索、模糊查詢；
l數據文件某種存儲格式導入數據窗體，經過數據完整性校驗存入數據庫；
l數據庫安全性的設計；
l數據庫的設計、數據接口、界面的設計。
§1.3本文所作工作
緒論部分對數據庫應用系統的結構、開發進行了簡要介紹，分析了圖書管理信息系統設計的特點和任務。
第二章介紹了數據庫的設計和范式分析，并系統介紹了SQL語言，為設計和理解應用程序做了鋪墊。
第三章對系統介紹了Delphi6.0的數據庫編程技術、SQL語言在Delphi6.0中的應用、MSSQLServer基礎。
第四章分析了圖書管理系統的應用需求，設計了系統的數據庫結構，并根據需求對系統功能進行了劃分和細化。
第五章根據第四章的設計結果利用MSSQLServer2000和Delphi6.0進行了具體的應用程序設計。
總結部分介紹了設計體會和編程體會，并指出了系統設計中的不足和改進的方向。
第二章數據庫理論基礎
一個成功的信息管理系統，是建立在許多條件之上的，而數據庫是其中一個非常重要的條件和關鍵技術。
信息管理系統所涉及的數據庫設計分五個步驟：數據庫需求分析、概念設計、邏輯設計、物理設計與加載測試。
（1）數據庫需求分析的任務是將業務管理單證流化為數據流，劃分主題之間的邊界，繪制出DFD圖，并完成相應的數據字典。
（2）概念設計的任務是從DFD出發，繪制出本主題的實體－關系圖，并列出各個實體與關系的綱要表。
（3）邏輯設計的任務是從E-R圖與對應的綱要表出發，確定各個實體及關系的表名屬性。
（4）物理設計的任務是確定所有屬性的類型、寬度與取值范圍，設計出基本表的主鍵，將所有的表名與字段名英文化（現在很多軟件能支持中文字段，如MSSQLServer，我就是用的中文字段名），實現物理建庫，完成數據庫物理設計字典。
（5）加載測試工作貫穿于程序測試工作的全過程，整個錄入、修改、查詢、處理工作均可視為對數據庫的加載測試工作。
要設計出一個好的信息管理系統數據庫，除滿足系統所要求的功能外，還必須遵守下列原則：
²基本表的個數越少越好。
²主鍵的個數越少越好。鍵是表間連接的工具，主鍵越少，表間的連接就越簡單。
²字段的個數越少越好。
²所有基本表的設計均應盡量符合第三范式。
數據庫的設計中，如何處理多對多的關系和如何設計主鍵，是兩個有著較大難度、需要重點考慮的問題。下面我們著重從SQL應用、數據庫設計范式和查詢優化等方面來分析本課題的系統關鍵技術和實現難點并加以解決。
§2.1數據庫系統設計及范式分析
信息系統的主要任務是通過大量的數據獲得管理所需要的信息，這就必須存儲和管理大量的數據。因此建立一個良好的數據組織結構和數據庫，使整個系統都可以迅速、方便、準確地調用和管理所需的數據，是衡量信息系統開發工作好壞的主要指標之一。
2.1.1數據庫系統設計
數據庫設計主要是進行數據庫的邏輯設計，即將數據按一定的分類、分組系統和邏輯層次組織起來，是面向用戶的。數據庫設計時需要綜合企業各個部門的存檔數據和數據需求，分析各個數據之間的關系，按照DBMS提供的功能和描述工具，設計出規模適當、正確反映數據關系、數據冗余少、存取效率高、能滿足多種查詢要求的數據模型。
數據庫設計的步驟是：
（1）數據庫結構定義：目前的數據庫管理系統（DBMS）有的是支持聯機事務處理CLTP（負責對事務數據進行采集、處理、存儲）的操作型DBMS，有的可支持數據倉庫、有聯機分析處理CLAP（指為支持決策的制定對數據的一種加工操作）功能的大型DBMS，有的數據庫是關系型的、有的可支持面向對象數據庫。針對選擇的DBMS，進行數據庫結構定義。
（2）數據表定義：數據表定義指定義數據庫中數據表的結構，數據表的邏輯結構包括：屬性名稱、類型、表示形式、缺省值、校驗規則、是否關鍵字、可否為空等。關系型數據庫要盡量按關系規范化要求進行數據庫設計，但為使效率高，規范化程度應根據應用環境和條件來決定。數據表設計不僅要滿足數據存儲的要求，還要增加一些如反映有關信息、操作責任、中間數據的字段或臨時數據表。
（3）存儲設備和存儲空間組織：確定數據的存放地點、存儲路徑、存儲設備等，備份方案，對多版本如何保證一致性和數據的完整性。
（4）數據使用權限設置：針對用戶的不同使用要求，確定數據的用戶使用權限，確保數據安全。
（5）數據字典設計：用數據字典描述數據庫的設計，便于維護和修改。
為了更好地組織數據和設計出實際應用數據庫，應該注意如下問題：
規范化地重組數據結構：對數據進行規范化表達，這在后面將會具體討論。
關系數據結構的建立：在進行了數據基本結構的規范化重組后，還必須建立整體數據的關系結構。這一步設計完成后數據庫和數據結構設計工作基本完成，只待系統實現時將數據分析和數據字典的內容代入到所設計的數據整體關系結構中，一個規范化數據庫系統結構就建立起來了。
建立關系數據結構涉及三方面內容：確定關聯的關鍵指標項并建立關聯表；確定單一的父系記錄結構；建立整個數據庫的關系結構。
（1）鏈接關系的確定
在進行了上述數據規范化重組后，已經可以確保每一個基本數據表(我們簡稱為表)是規范的，但是這些單獨的表并不能完整地反映事物，通常需要通過指標體系整體指標數據才能完整全面地反映問題。也就是說在這些基本表的各宇段中，所存儲的是同一事物不同側面的屬性。那么計算機系統如何能知道哪些表中的哪些記錄應與其它表中的哪些記錄相對應，它們表示的是同一個事物呢?這就需要在設計數據結構時將這種各表之間的數據記錄關系確定下來。這種表與表之間的數據關系一般都是通過主或輔關鍵詞之間的連接來實現的。因為在每個表中只有主關鍵詞才能唯一地標識表中的這一個記錄值(因為根據第三范式的要求，表中其它數據字段函數都依賴于主關鍵詞)，所以將表通過關鍵詞連接就能夠唯一地標識出某一事物不同屬性在不同表中的存放位置。
（2）確定單一的父子關系結構
所謂確定單一的父系關系結構就是要在所建立的各種表中消除多對多（以下用M:N來表示）的現象，即設法使得所有表中記錄之間的關系呈樹狀結構(只能由一個主干發出若干條分支，而不能有若干條主干交錯發出若干條分支狀況)。所謂的“父系”就是指表的上一級關系表。消除多對多關系可以借助于E-R圖的方法來解決，也可以在系統分析時予以注意，避免這種情況的發生。
消除這種M:N情況的辦法也很簡單，只需在二表之間增加一個表，則原來M:N的關系就改成了M:1，1:N的關系了。
確定數據資源的安全保密屬性：
一般DBMS都提供給我們自己定義數據安全保密性的功能。系統所提供的安全保密功能一般有8個等級(0-7級)，4種不同方式(只讀、只寫、刪除、修改)，而且允許用戶利用這8個等級的4種方式對每一個表自由地進行定義。
定義安全保密性的方法一般有如下幾種：
a．原則上所有文件都定義為4級，個別優先級特別高的辦公室(終端或微機的入網賬號)可定義高于4級的級別，反之則定義為低于4的級別。
b．統計文件(表)和數據錄入文件一般只對本工作站定義為只寫方式，對其它工作站則定義為只讀方式。
c．財務等保密文件一般只對中工作站(如財務科等)定義為可寫、可改、可刪除方式，對其它工作站則定義為只讀方式，而且不是每個人都能讀，只有級別相同和高級別者才能讀。
2.1.2數據庫設計范式分析
建立起一個良好的數據指標體系，是建立數據結構和數據庫的最重要的一環。一個良好的數據指標體系是建立DB的必要條件，但不是充分條件。我們完全可以認為所建指標體系中的一個指標類就是關系數據庫中的一個基本表，而這個指標類下面的一個個具體指標就是這個基本表中的一個字段。但如果直接按照這種方式建庫顯然還不能算最佳。對于指標體系中數據的結構在建庫前還必須進行規范化的重新組織。
a.數據組織的規范化形式
在數據的規范化表達中，一般將一組相互關聯的數據稱為一個關系(relation)，而在這個關系下的每個數據指標項則被稱為數據元素(dataelement)，這種關系落實到具體數據庫上就是基本表，而數據元素就是基本表中的一個字段(field)。規范化表達還規定在每一個基本表中必須定義一個數據元素為關鍵字(key)，它可以唯一地標識出該表中其它相關的數據元素。在規范化理論中表是二維的，它有如下四個性質：
l在表中的任意一列上，數據項應屬于同一個屬性(如圖中每一列都存放著不同合同記錄的同一屬性數據)。
l表中所有行都是不相同的，不允許有重復組項出現(如圖中每一行都是一個不同的合同記錄)。
l在表中，行的順序無關緊要(如圖中每行存的都是合同記錄，至于先放哪一個合同都沒關系)。
l在表中，列的順序無關緊要，但不能重復(如圖中合同號和合同名誰先誰后都沒關系，但二者不可重復或同名)。
在對表的形式進行了規范化定義后，數據結構還有五種規范化定義，定名為規范化模式，稱為范式。在這五種范式中，一般只用前三種，對于常用系統就足夠了。而且這五種范式是“向上兼容”的，即滿足第五范式的數據結構自動滿足一、二、三、四范式，滿足第四范式的數據結構自動滿足第一、二、三范式，……，依此類推。
第一范式(firstnormalform，簡稱1stNF)就是指在同一表中沒有重復項出現，如果有則應將重復項去掉。這個去掉重復項的過程就稱之為規范化處理。在本文所討論的開發方法里，1stNF實際上是沒有什么意義的。因為我們按規范化建立的指標體系和表的過程都自動保證了所有表都滿足1stNF。
第二范式(secondnormalform，簡稱2ndNF)是指每個表必須有一個(而且僅一個)數據元素為主關鍵字(primarykey)，其它數據元素與主關鍵字一一對應。例如，在圖l9.7中如果我們將合同號定義為主關鍵字(其它數據元素中的記錄數據都有可能重名，故不能作為主關鍵字)，故只要知道了一個合同記錄的合同號，就可以唯一地在同一行中找到該合同的任何一項具體信息。通常我們稱這種關系為函數依賴(functionaldepEndence)關系。即表中其它數據元素都依賴于主關鍵字，或稱該數據元素唯一地被主關鍵字所標識。
第三范式(thirdnormalform，簡稱3rdNF)就是指表中的所有數據元素不但要能夠唯一地被主關鍵字所標識，而且它們之間還必須相互獨立，不存在其它的函數關系。也就是說對于一個滿足了2ndNF的數據結構來說，表中有可能存在某些數據元素依賴于其它非關鍵宇數據元素的現象，必須加以消除。
為防止數據庫出現更新異常、插入異常、刪除異常、數據冗余太大等現象，關系型數據庫要盡量按關系規范化要求進行數據庫設計。
§2.2SQL語言介紹
2.2.1SQL基礎
SQL(StructuredQueryLanguage，結構查詢語言)是一個功能強大的數據庫語言。SQL通常使用于數據庫的通訊。ANSI（美國國家標準學會）聲稱，SQL是關系數據庫管理系統的標準語言。SQL語句通常用于完成一些數據庫的操作任務，比如在數據庫中更新數據，或者從數據庫中檢索數據。使用SQL的常見關系數據庫管理系統有：Oracle、Sybase、MicrosoftSQLServer、Access、Ingres等等。雖然絕大多數的數據庫系統使用SQL，但是它們同樣有它們自立另外的專有擴展功能用于它們的系統。但是，標準的SQL命令，比如"Select"、"Insert"、"Update"、"Delete"、"Create"和"Drop"常常被用于完成絕大多數數據庫的操作。MSSQLServer就是用的Transact-SQL。
SQL語言有著非常突出的優點，主要是：
n非過程化語言
n統一的語言
n是所有關系數據庫的公共語言
非過程化語言：SQL是一個非過程化的語言，因為它一次處理一個記錄，對數據提供自動導航。SQL允許用戶在高層的數據結構上工作，而不對單個記錄進行操作，可操作記錄集，所有SQL語句接受集合作為輸入，返回集合作為輸出。SQL的集合特性允許一條SQL語句的結果作為另一條SQL語句的輸入。
SQL不要求用戶指定對數據的存放方法，這種特性使用戶更易集中精力于要得到的結果；所有SQL語句使用查詢優化器，它是RDBMS的一部分，由它決定對指定數據存取的最快速度的手段，查詢優化器知道存在什么索引，在哪兒使用索引合適，而用戶則從不需要知道表是否有索引、有什么類型的索引。
統一的語言：SQL可用于所有用戶的DB活動模型，包括系統管理員、數據庫管理員、應用程序員、決策支持系統人員及許多其它類型的終端用戶。
SQL為許多任務提供了命令，其中包括：
n查詢數據
n在表中插入、修改和刪除記錄
n建立、修改和刪除數據對象
n控制對數據和數據對象的存取
n保證數據庫一致性和完整性
以前的數據庫管理系統為上述各類操作提供單獨的語言，而SQL將全部任務統一在一種語言中。
所有關系數據庫的公共語言：由于所有主要的關系數據庫管理系統都支持SQL語言，用戶可將使用SQL的技能從一個RDBMS(關系數據庫管理系統)轉到另一個，所有用SQL編寫的程序都是可以移植的。
2.2.2SQL語句
SQL功能強大，是一種完備的數據處理語言，不僅用于數據庫查詢，而且用于數據庫中的數據修改和更新，概括起來，它可以分成以下幾組：
DML（DataManipulationLanguage，數據操作語言）：用于檢索或者修改數據；
DDL（DataDefinitionLanguage，數據定義語言）：用于定義數據的結構，比如創建、修改或者刪除數據庫對象；
DCL（DataControlLanguage，數據控制語言）：用于定義數據庫用戶的權限。
DML組可以細分為以下的幾個語句：
SELECT：用于檢索數據；
INSERT：用于增加數據到數據庫；
UPDATE：用于從數據庫中修改現存的數據；
DELETE：用于從數據庫中刪除數據。
DDL語句可以用于創建用戶和重建數據庫對象。下面是DDL命令：
CREATETABLE，ALTERTABLE，DROPTABLE，CREATEINDEX，DROPINDEX
下面是一個簡單SQL語句的例子：
我們使用SQL語句來從Book中檢索‘借書證號’為‘000001’的借閱者姓名：
SELECT姓名FROMBookWHERE借書證號=‘000001’
2.2.2.1DDL與DML
數據定義語言DDL：它是用來創建和修改數據庫結構的一種語句，包括Create、Alter和Drop語句。
數據操作語言DML：包括數據查詢與數據更新。數據查詢主要是由Select語句完成，這一點不再贅述。而數據更新所造成的風險大大超過數據查詢。數據庫管理系統必須在更改期內保護所存儲的數據的一致性，確保有效的數據進入數據庫，數據庫必須保持一致性，DBMS還必須協調多用戶的并行更新，以確保用戶和它們的更改不至于影響其它用戶的作業。
用于修改數據庫內容的SQL語句主要有以下三個：
(1)Insert，向一個表中加入新的數據行
(2)Delete，從一個表中刪除數據行
(3)Update，更改數據庫中已經存在的數據
Insert標準語法：
INSERTINTOtable_name(col1,col2...)VALUES(value1,value2...)
下例要將借書證號為‘000001’作為一個新的借書情況加入借書情況表OWNER中
InsertInto
owner(借書證號，圖書編號，借書日期)
values(‘000001’，‘00000001’，‘2002-9-12’)
Insert語句還可以將多行數據添加到目標表中去，在這種形式的Insert語句中，新行的數據值不是在語句正文中明確地指定的，而是語句中指定的一個數據庫查詢。添加的值來自數據庫自身的行，在某些特定的狀態下，這是非常有用的。多行Insert語句為拷貝數據提供了一種緊湊而高效的方法，但我在自已做的圖書管理系統中沒有使用這種方法，我在系統中是使用循環依照上面的用法來完成多個記錄的插入。
Update語句用于更新單表中選定行的一列或多列的值。要更新的目標表在語句中定義，Set子句則指定要更新哪些列并計算它們的值。Update語句總是包含Where語句，而且Update語句比較危險，所以您必須明確地認識到Where語句的重要性，Where語句被用來指定需要更新的行。
標準語法：
UPDATEtable_name
SETcolumnname1=value1
[,columname2=value2]...
WHEREsearch_condition
Delete語句標準語法：
DELETEFROMtablenameWHEREcondition
2.2.2.2復雜操作實現
在信息管理系統中，我們往往會遇到歸類、匯總、映射、索引、子查詢等復雜操作，相應的支持與實現如下：
uGROUPBY方法
GROUPBY子句語法為：
SELECTcolumn1,SUM(column2)
FROM"list-of-tables"
GROUPBY"column-list";
這個GROUPBY子句將集中所有的行在一起，它包含了指定列的數據以及允許合計函數來計算一個或者多個列。
在本人的系統中在顯示數據時用到了此語句來對查詢所得的內容排序然后再顯示。
u組合條件和布爾運算符
以下的SQL語句中就含有組合條件：
SELECTcolumn1,SUM(column2)
FROM"list-of-tables"
WHERE"condition1"AND"condition2";
下面是一個示例：
SELECT身份描述
FROMID,user
WHEREID.身份編號=USER.身份編號anduser.借書證號=’000001’;
這條SQL語句是從user、id表中查找借閱證號為000001的借閱者的身份描述，第三條語句中如果其中有一個條件為假，那么就什么都沒有顯示。
uUNION子句
有些時候，需要一起瀏覽多個查詢的結果、組合它們的輸出，我們可以使用UNION關鍵字。
第三章應用系統開發工具
§3.1Delphi6.0VCL組件的體系結構
Delphi類可以粗略地分成兩部分：一部分是組件類，這些組件類通常以某種方式出現在組件面板上，當用戶從組件面板上點取一個類的圖標后，在程序中就自動生成了該類的對象（非可視組件除外）；另一部分是功能類，這此功能類的對象通常出現在程序代碼中，起著不可代替的作用，但是這些功能類在組件面板上是找不到的。在Delphi中，每一個類的祖先都是Tobject類,整個類的層次結構就像一棵倒掛的樹，在最頂層的樹根即為Tobject類。這樣，按照面向對象編程的基本思想，就使得用戶可用Tobject類這個類型代替任何其它類的數據類型。實際上在Delphi的類庫中，Tobject類派生出了為數相當眾多的子類，它們形成了一個龐大的體系，通常情況下，如果不自行開發組件，就不必了解整個類的體系結構，只用到類層次樹的葉結點就足夠了。
這一小節簡略介紹一下Delphi6.0中VCL（可視化組件庫）組件的體系結構。凡是做過程序開發的人都知道從來沒有單純的數據應用程序，也就是說，數據庫應用程序必須和用戶界面（可以是圖形界面，也可以是命令接口）元素相結合，只講界面或只講數據庫本身都構不成數據庫應用程序，因而用Delphi6.0開發數據庫應用程序就隱含著界面開發。Delphi6中的VCL組件可用圖3-1來說明。
組件在Delphi程序的開發中是最顯眼的角色。大家知道，在編寫程序時一般都開始于在組件面板上選擇組件并定義組件間的相互作用。但也有一些組件不在組件面板上，例如Tform和Tapplication（典型的非可視組件）。組件是Tcomponents派生出來的子類，可以流的形式存放在DFM文件中，具有事件和Publish屬性。
窗口組件類是窗口化的可視化組件類，在Delphi的類庫中占有最大的份額。在實際編程中，窗口組件類的對象都有句柄，可以接受輸入焦點和包含其它組件。
圖形組件與窗口組件并列，是另一大類組件。圖形組件不是基于窗口的，因而不能有窗口句柄，不能接受輸入焦點和包含其它組件。從圖8-43中可以看出，圖形組件的基類是TgraphicControl,在實際編程中，它們必須寄生于它們的宿主——窗口組件類的對象，由它們的擁有者負責其顯示，而且它們還能觸發一些和鼠標活動相關的事件。圖形控件最典型的例子是Tlabel和TspeedButton。由此可以看出圖形組件的功能很弱，圖形組件的用處何在呢？其實使用圖形組件的最大好處在于節省資源，正是因為它們的功能較弱，所以使用的系統資源就要少。在一個應用程序中，如果能在不影響其功能的前提下合理大量地使用圖形組件，將會大減少程序對系統資源的消耗。
非可視組件是與可視組件相并列的另一類組件，非可視組件在程序運行中是不可見的（除各種對話框組件之外，事實上有人認為對話框組件不能歸入非可視組件，應該是另一種介于可視與非可視之間的組件）。
最后要說明一下，常說的控件實際上是一種組件。也就是說組件這個概念要大于控件，控件在內涵上包含于組件中?？丶蒞indows系列操作系統提出并使用，而組件是Borland和其它廠商在對Windows控件做了必要的擴展之后提出來的概念，它們是在不同時期由不同的廠商提出的概念。
§3.2數據庫組件介紹
用Delphi6開發數據庫應用，重點是和各種數據庫組件打交道，能和數據庫掛鉤的組件對象有5種，它們是：Session（數據庫會話）、Database（數據庫）、Dataset（數據集）、DataSource（數據源）、Datacontrol（數據控制組件，也叫data-controls即數據感知組件）。其中前面4種統稱為數據訪問（DataAccess）組件。這些組件的相互關系如圖3-2所示。
ADO組件Delphi6.0包含了可以用來訪問Microsoft公司的ActiveXDataObjects（ADO）格式數據庫的組件。ADO是Micrsoft公司關于各種類型數據的高等界面，后來逐漸演變成滿足所有數據訪問需要的完整解決辦法。ADO的對象模型是所有數據訪問接口對象模型中最簡單的一種。Microsoft公司用來訪問ADO數據的應用程序界面技術是OLEDB。OLEDB是一種底層編程接口，用來訪問許多不同類型的數據源，其中包括消息、文件系統以及其他一些非傳統的數據源。OLEDB是一個由ComponentObjectModel（COM）接口組成的集合，用來隱藏創建數據訪問服務過程中的細節。OLEDB提供了訪問任何數據資源的方法，包括相互關聯的數據庫和相互不關聯的數據庫、Email和文件系統、文本和圖形以及用戶定義的數據對象。
Delphi的ADO組件無需依靠BDE而是使用ADO技術，提供了可以通過數據控制組件訪問數據的新方法。唯一的要求是在使用ADO組件時必須運行ADO/OLE－DB。ADO組件的使用使得DELPHI在訪問數據的類型和采用的技術方面都有了很大的突破。
數據模塊設計窗口數據模塊設計窗口是用來設計和維護數據模塊的。數據模塊設計窗口中包含了所有以.DTI作為文件擴展名的DataDiagram文件的信息。DTI文件在編譯時不起任何作用。
§3.3SQL語言在Delphi中的應用
在Delphi中使用SQL語言非常方便，一般來說，都是通過Tquery或TADOquery組件來使用SQL語言的?？梢栽赥query或TADOquery組件的SQL屬性中設置SQL語句。設計程序時，在該組件的屬性對話框中選擇SQL屬性，單擊帶省略號的按鈕，就可以打開StringListEditor對話框，然后我們就可以在對話框中添加SQL語句。還可以使用Delphi的SQLBuilder來自動生成SQL語句，這樣可以避免手工編寫SQL而可能造成的語法錯誤。
靜態SQL語句在程序設計時便已固定下來，它不包含任何參數和變量。
動態SQL語句，也被稱作參數化的語句，在其中間包含著表示字段名或表名的參數，例如下面的語句是一條動態SQL語句：
Select*FromBookWhere圖書編號=:bookCode;
其中的變量bookCode便是一個參數變量，它由一個冒號引導，在程序運行過程中，必須要為該參數賦值，該條SQL語句才能正確執行，每次運行應用程序時可以為該參數變量賦予不同的值。為參數賦值有三種方法：
①根據參數在SQL語句中出現的順序，設置TADOQuery組件的parameters屬性值為參數賦值。
②直接根據SQL語句中各參數的名字，調用ParamByName方法來為各參數賦值。
③將TADOQuery組件的DataSource屬性設置為另一個數據源，這樣將另一個數據源中與當前TADOQuery組件的SQL語句中的參數名相匹配的字段值賦給其對應的參數。利用這種方法也能實現所謂的連接查詢，創建主要—明細型數據庫應用。
在使用動態SQL語句編程時，常常用到一個很重要的方法Prepare，調用Prepare方法之后，Delphi會將帶參數的SQL語句傳送給與其對應的數據庫引擎，對動態SQL語句進行語法分析和優化。雖然在用動態SQL語句編程時，調用Prepare方法并不是必須的，但是調用Prepare方法后，會極大地提高動態SQL語句的執行性能，特別是當要反復多次執行同一條動態SQL語句時，其優越性會更加明顯。如果在應用程序中執行一條SQL語句之前并沒有顯式地調用Prepare方法，每次在執行SQL語句時，Delphi會隱含地調用Prepare方法以準備這個查詢。
TadoQuery部件還有一個Prepare屬性，這是一個布爾型屬性，當其屬性值為True時，表明該查詢已被準備好了(SQL語句已被傳送到數據庫引擎中)，當我們使用參數編輯器ParametersEditor來為動態SQL語句中的參數賦值時，當設置完相應的參數值并退出參數編輯器時，Delphi會隱含地調用Prepare方法以準備好查詢。
當SQL語句執行完之后，要想準備下一個查詢，首先必須調用Close方法，然后才能調用Prepare方法準備下一個查詢。一般來說，在一個應用程序中應該調用一次Prepare方法，常常在窗體的OnCreate事件處理過程中調用Prepare方法，然后用上述介紹的方法為參數賦值，最后調用Open方法或ExecSQL方法執行SQL語句，以完成查詢。
當然在調用Prepare方法準備好一個查詢時，會消耗一些數據庫資源，因而每當一個查詢執行完畢之后，要養成調用UnPrepare方法以撤消查詢的好習慣。在運行程序過程中，通過程序改變TQuery或TADOquery部件的SQL屬性值時，Delphi會自動地調用Close方法和UnPrepare方法，以撤消查詢。
在程序運行過程中，要想設置Tquery或TADOquery部件的SQL屬性，必須首先調用Close方法，關閉TQuery或TADOquery部件，然后再調用Clear方法清除SQL屬性中現存的SQL命令語句，最后再調用Add方法為SQL屬性設置新的SQL命令語句。例如：
datamodule4.adoquery2.close;
datamodule4.adoquery2.sql.clear;
datamodule4.adoquery2.sql.add(''''SELECT借書證號,密碼FROM[user]WHERE(借書證號=:tt)'''');
datamodule4.adoquery2.parameters[0].value:=username;
datamodule4.adoquery2.open;
在為TQuery或TADOquery部件設置SQL屬性時調用Close方法總是很安全的，如果TQuery或TADOquery部件已經被關閉了，調用Close方法時不會產生任何影響。在應用程序中為SQL屬性設置新的SQL命令語句時，必須要調用Clear方法以清除SQL屬性中現存的SQL命令語句，如果不調用Clear方法，便調用Add方法向SQL屬性中設置SQL命令語句，那么新設置的SQL命令語句會追加在現存SQL命令語句后面，在程序運行時常常會出現出乎意料的查詢結果甚至程序無法運行下去。
在這里要特別注意的，一般情況下TQuery或TADOquery部件的SQL屬性只能包含一條完整的SQL語句，它不允許被設置成多條SQL語句。當然有些數據庫服務器也支持在TQuery或TADOquery部件的SQL屬性中設置多條SQL語句，只要數據庫服務器允許這樣，我們在編程時可以為SQL屬性設置多條SQL語句。
在為TQuery或TADOquery部件設置完SQL屬性的屬性值之后，也即編寫好適當的SQL程序之后，可以有多種方式來執行SQL程序。
在設計過程中，設置完TQuery或TADOquery部件的SQL屬性之后將其Active屬性的值置為True，這樣便可以執行SQL屬性中的SQL程序，如果應用中有與TQuery或TADOquery部件相連的數據瀏覽部件(如TDDGridTDBEdit等)那么在這些數據瀏覽部件中會顯示SQL程序的執行結果。
在應用程序運行過程中，通過程序調用TQuery或TADOquery組件的Open方法或ExecSQL方法可以執行其SQL屬性中的SQL程序。Open方法和ExecSQL方法是不一樣的。Open方法只能用來執行SQL語言的查詢語句(Select命令)，并返回一個查詢結果集，而ExecSQL方法還可以用來執行其它常用的SQL語句(如INSERT,UPDATE,DELETE等命令)，例如：
Query1.Open(這樣會返回一個查詢結果集)
如果調用Open方法，而沒有查詢結果時，會出錯。此時應該調用ExecSQL方法來代替Open方法。如：
Query1.ExecSQL(沒有返回結果)
當然在設計應用程序時，程序設計人員是無法確定TQuery或TADOquery組件中的SQL語句是否會返回一個查詢結果的。對于這種情況應當用Try…Except模塊來設計程序。在Try部分調用Open方法，而在Except部分調用ExceSQL方法，這樣才能保證程序的正確運行。
例如：
Try
Query1.Open
Except
Query1.ExecSQL
End
通過Tquery或TADOquery組件可以獲得兩種類型的數據：
u“活動”的數據
這種數據就跟通過TTable部件獲得的數據一樣，用戶可以通過數據瀏覽部件來編輯修改這些數據，并且當調用Post方法或當焦點離開當前的數據瀏覽部件時，用戶對數據的修改自動地被寫回到數據庫中。
u非活動的數據(只讀數據)
用戶通過數據瀏覽部件是不能修改其中的數據。在缺省情況下，通過TQuery部件獲得的查詢結果數據是只讀數據，要想獲得“活動”的數據，在應用程序中必須要設置Tquery或TADOquery組件的RequestLive屬性值為True，然而并不是在任何情況下(通過設置RequestLive的屬值True)都可以獲得“活動”的數據的，要想獲得“活動”的數據，除了將TQuery部件的RequestLive屬性設置為True外，相應的SQL命令還要滿足以下條件。
本地SQL語句查詢情況下，要得到可更新的數據集，SQL語句的限制為：
n查詢只能涉及到一個單獨的表
nSQL語句中不能包含ORDERBY命令
nSQL語句中不能含聚集運算符SUM或AVG
n在Select后的字段列表中不能有計算字段
n在Select語句WHERE部分只能包含字段值與常量的比較運算，這些比較運算符是：Like,>,<,>=,<=。各比較運算之間可以有并和交運算：AND和OR
當通過SQL語句查詢數據庫服務器中的數據庫表：
n查詢只能涉及到一個單獨的表
nSQL語句中不能包含ORDERBY命令
nSQL語句中不能含聚集運算符SUM或AVG運算
另外，如果是查詢Sybase數據庫中的表，那么被查詢的表中只能有一個索引。
如果在應用程序中要求TQuery或TADOquery組件返回一個“活動”的查詢結果數據集，但是SQL命令語句不滿足上述約束條件時，對于本地數據庫的SQL查詢，BDE只能返回只讀的數據集。對于數據庫服務器中的SQL查詢，只能返回錯誤的代碼。當Tquery或TADOquery組件返回一個“活動”的查詢結果數據集時，它的CanModIfy屬性的值會被設置成True。
§3.4MSSQLServer簡述
SQLServer是一個后臺數據庫管理系統,它功能強大操作簡便,日益為廣大數據庫用戶所喜愛。越來越多的開發工具提供了與SQLServer的接口。SQLServer是一個關系數據庫管理系統，它最初是由Microsoft、Sybase和Ashton-Tate三家公司共同開發的。于1988年推出了第一個OS/2版本，在WindowsNT推出后，Microsoft與Sybase在SQLServer的開發上就分道揚鑣了，Microsoft將SQLServer移植到WindowsNT系統上，專注于開發推廣SQLServer的WindowsNT版本。
SQLServer2000是Microsoft公司推出的SQLServer數據庫管理系統的最新版本，該版本繼承了SQLServer7.0版本的優點，同時又比它增加了許多更先進的功能、具有使用方便、可伸縮性好與相關軟件集成程度高等優點。可跨越從運行MicrosoftWindows98的膝上型電腦到運行MicrosoftWindows2000的大型多處理器的服務器等多種平臺使用。MSSQLServer不但可以應用于大中型數據庫管理中，建立分布式關系數據庫，并且也可以開發桌面數據庫。事實上，SQLServer數據庫處理的基本結構，采取關系型數據庫模式，盡管如此，相信大家都可以輕易的發現，在SQLServer的數據庫處理方式，則是使用面向對象的操作方式與精神，也就是說，SQLServer的所有功能，都可以基于系統已經建立好的一些對象來達成，是相當OO（面向對象）的一個系統結構。
SQLServer企業管理器是SQLServer的主要管理工具，它提供了一個遵從MMC標準的用戶界面，使用戶得以：
·定義SQLServer實例組。
·將個別服務器注冊到組中。
·為每個已注冊的服務器配置所有SQLServer選項。
·在每個已注冊的服務器中創建并管理所有SQLServer數據庫、對象、登錄、用戶和權限。
·在每個已注冊的服務器上定義并執行所有SQLServer管理任務。
·通過喚醒調用SQL查詢分析器，交互地設計并測試SQL語句、批處理和腳本。
·喚醒調用為SQLServer定義的各種向導。
·
第三章圖書管理系統設計分析
§4.1應用需求分析
圖書管理系統需要滿足來自三方面的需求，這三個方面分別是圖書借閱者、圖書館工作人員和圖書館管理人員。圖書借閱者的需求是查詢圖書館所存的圖書、個人借閱情況及個人信息的修改；圖書館工作人員對圖書借閱者的借閱及還書要求進行操作，同時形成借書或還書報表給借閱者查看確認；圖書館管理人員的功能最為復雜，包括對工作人員、圖書借閱者、圖書進行管理和維護，及系統狀態的查看、維護并生成催還圖書報表。
圖書借閱者可直接查看圖書館圖書情況，如果圖書借閱者根據本人借書證號和密碼登錄系統，還可以進行本人借書情況的查詢和維護部分個人信息。一般情況下，圖書借閱者只應該查詢和維護本人的借書情況和個人信息，若查詢和維護其他借閱者的借書情況和個人信息，就要知道其他圖書借閱者的借書證號和密碼。這些是很難得到的，特別是密碼，所以不但滿足了圖書借閱者的要求，還保護了圖書借閱者的個人隱私。
圖書館工作人員有修改圖書借閱者借書和還書記錄的權限，所以需對工作人員登陸本模塊進行更多的考慮。在此模塊中，圖書館工作人員可以為圖書借閱者加入借書記錄或是還書記錄，并打印生成相應的報表給用戶查看和確認。
圖書館管理人員功能的信息量大，數據安全性和保密性要求最高。本功能實現對圖書信息、借閱者信息、總體借閱情況信息的管理和統計、工作人員和管理人員信息查看及維護。圖書館管理員可以瀏覽、查詢、添加、刪除、修改、統計圖書的基本信息；瀏覽、查詢、統計、添加、刪除和修改圖書借閱者的基本信息，瀏覽、查詢、統計圖書館的借閱信息，但不能添加、刪除和修改借閱信息，這部分功能應該由圖書館工作人員執行，但是，刪除某條圖書借閱者基本信息記錄時，應實現對該圖書借閱者借閱記錄的級聯刪除。并且還應具有生成催還圖書報表，并打印輸出的功能。
在本系統中由于沒有打印機設備供試驗，所以預先把報表打印改成報表預覽。
設計不同用戶的操作權限和登陸方法
對所有用戶開放的圖書查詢
借閱者維護借閱者個人部分信息
借閱者查看個人借閱情況信息
維護借閱者個人密碼
根據借閱情況對數據庫進行操作并生成報表
根據還書情況對數據庫進行操作并生成報表
查詢及統計各種信息
維護圖書信息
維護工作人員和管理員信息
維護借閱者信息
處理信息的完整性
對借閱過期的圖書生成報表
圖4-2圖書管理系統數據庫應用需求的總結
根據以上所做的需求分析，并略掉一些細節（如不考慮用戶的登錄；對記錄的維護），得出以下的三層數據流圖。
§4.2系統功能模塊劃分
系統功能框圖如圖4-10所示。
§4.3系統數據庫設計
4.3.1概念設計
在概念設計階段中，設計人員從用戶的角度看待數據及處理要求和約束，產生一個反映用戶觀點的概念模式。然后再把概念模式轉換成邏輯模式。將概念設計從設計過程中獨立開來，使各階段的任務相對單一化，設計復雜程度大大降低，不受特定DBMS的限制。
利用ER方法進行數據庫的概念設計，可分成三步進行：首先設計局部ER模式，然后把各局部ER模式綜合成一個全局模式，最后對全局ER模式進行優化，得到最終的模式，即概念模式。
（1）設計局部ER模式
實體和屬性的定義：
圖書（圖書編號，圖書名稱，作者，出版社，出版日期，備注，價格，數量，）
借閱者（借書證號，姓名，性別，身份證，聯系電話，密碼）
身份（身份編號，身份描述，最大借閱數）
圖書類別（圖書類別編號，類別描述）
ER模型的“聯系”用于刻畫實體之間的關聯。一種完整的方式是對局部結構中任意兩個實體類型，依據需求分析的結果，考察局部結構中任意兩個實體類型之間是否存在聯系。若有聯系，進一步確定是1:N，M:N，還是1:1等。還要考察一個實體類型內部是否存在聯系，兩個實體類型之間是否存在聯系，多個實體類型之間是否存在聯系，等等。聯系定義如圖4-5所示。解釋如下：
u一個借閱者（用戶）只能具有一種身份，而一種身份可被多個借閱者所具有；
u一本圖書只能屬于一種圖書類別（類別），而一種圖書類別可以包含多本圖書；
u一個用戶可以借閱多本不同的書，而一本書也可以被多個不同的用戶所借閱。
（2）設計全局ER模式
所有局部ER模式都設計好了后，接下來就是把它們綜合成單一的全局概念結構。全局概念結構不僅要支持所有局部ER模式，而且必須合理地表示一個完整、一致的數據庫概念結構。
1)確定公共實體類型
為了給多個局部ER模式的合并提供開始合并的基礎，首先要確定各局部結構中的公共實體類型。在這一步中我們僅根據實體類型名和鍵來認定公共實體類型。一般把同名實體類型作為公共實體類型的一類候選，把具有相同鍵的實體類型作為公共實體類型的另一類候選。
2)局部ER模式的合并
合并的原則是：首先進行兩兩合并；先和合并那些現實世界中有聯系的局部結構；合并從公共實體類型開始，最后再加入獨立的局部結構。
3)消除沖突
沖突分為三類：屬性沖突、結構沖突、命名沖突。
設計全局ER模式的目的不在于把若干局部ER模式形式上合并為一個ER模式，而在于消除沖突，使之成為能夠被所有用戶共同理解和接受的同一的概念模型。
3)全局ER模式的優化
在得到全局ER模式后，為了提高數據庫系統的效率，還應進一步依據處理需求對ER模式進行優化。一個好的全局ER模式，除能準確、全面地反映用戶功能需求外，還應滿足下列條件：實體類型的個數要盡可能的少；實體類型所含屬性個數盡可能少；實體類型間聯系無冗余。
綜上所述，“圖書管理系統”的全局ER模式如圖4-13所示。
4.3.2關系數據庫的邏輯設計
由于概念設計的結果是ER圖，DBMS一般采用關系型（本人所使用的MSSQLServer就是關系型的DBMS），因此數據庫的邏輯設計過程就是把ER圖轉化為關系模式的過程。由于關系模型所具有的優點，邏輯設計可以充分運用關系數據庫規范化理論，使設計過程形式化地進行。設計結果是一組關系模式的定義。
（1）導出初始關系模式
book（圖書編號＃，圖書名稱，圖書類別＃，作者，出版社，出版日期，備注，價格，數量）class（圖書類別#，類別名）user（借書證號＃，姓名，性別，身份編號＃，身份證，聯系電話，密碼）ID（身份編號#，身份描述，最大借閱數）Owner（借書證號#,圖書編號#，借書日期）
圖4-14關系模式集
（2）產生子模式
子模式是用戶所用到的那部分數據的描述。除了指出用戶用到的數據外，還應指出數據與概念模式中相應數據的聯系，即指出概念模式與子模式之間的對應性。
借書子模式（借書證號#，姓名，圖書編號＃，圖書名稱，借書日期）
圖4-15部分子模式
（3）根據設計中出現的問題本人在寫系統時還加入了兩個關系模式：
1、ownertemp：用于工作人員在處理借書、還書工作時臨時存儲借書、還書信息，以便打印報表時使用。
2、keyer：用于存儲工作人員和圖書館管理員的用戶名和密碼及權限，以便工作人員或圖書館管理員進入相應的功能模塊時進行驗證用戶的身份。
4.3.3數據庫的實現
我選用MicrosoftSQLServer2000(企業版)數據庫來進行數據庫的邏輯設計。首先創建七個基本數據庫表如表4-1－4-7所示，然后根據全局ER圖，建立各個表之間的聯系，如圖4-8所示。
表4-1借閱者基本信息表的結構(User)
表4-2圖書信息表的結構（Book）
表4-3圖書類別信息表的結構（Class）
表4-4借閱者身份信息表的結構（ID）
表4-5借閱情況信息表的結構（Owner）
表4-6借閱情況臨時存儲信息表的結構（Ownertemp）
注：在owner表和ownertemp表中加入了索引字段，用來唯一標識一條借書記錄，并且設置為標識，標識種子為1。
表4-7工作人員和管理員信息表的結構（Keyer）
圖4-8數據庫表間聯系圖
第五章圖書管理系統應用程序設計
§5.1系統窗體模塊組成
§5.2數據模塊窗體的設置
在編寫數據庫應用程序時，經常要遇到這樣的情況，即好多組件、窗體同時訪問相同的數據源，如果為每一個組件或者窗體都設置一個數據源將是十分耗時的工件，而且要保證這些數據源的確是相同的也需花一番功夫。那么，能不能將這些數據源集中管理，最好是做成一個統一的模塊，需要時就將該模塊引入而不必直接操作數據源本身呢？數據模塊（DataModule）是解決這個問題最好的答案。簡單說來，數據模塊是用來集中管理數據源的一個窗體，該窗體可被需要的地方隨時引入。
但本人在開發這個系統時，開始使用了一下數據模塊，但在使用過程中卻碰到了一些問題。并且考慮這個系統使用到的TADOQuery控件比較多，如果使用數據控件可能會帶來管理上的麻煩，如弄混各個數據控件的作用。還考慮到使用動態生成ADOQuery可能會更節省資源。所以在本人的系統中，開始做的第一個模塊“借閱者個人模塊”中還稍微使用了一下數據模塊。但在后面做的兩個模塊中大多都是用動態生成ADOQuery來實現的。并且由于SQL語句是動態加入的所以datamodule中的控件也不會多。
§5.3啟動畫面的實現
啟動畫面是為了給用戶一個良好的印像，加深軟件的親和力，沒有實際的功能，在Form1窗體中加入了Image和Time組件。啟動畫面的窗體略，主要的源代碼如下：
§5.4用戶登錄窗體的的實現
本窗體是為三種不同的用戶（一般用戶，工作人員，管理員）提供選擇以進入不同的模塊，滿足不同用戶的需求。源代碼比較簡單，略。
§5.5用戶密碼認證窗體的的實現
本窗體是為了讓工作人員或圖書館管理員按照用戶名和密碼進行登錄，并且跟據用戶名檢查Keyer表中的“權限”字段，以分辯進入圖書館管理人員模塊還是進入工作人員模塊。窗體界面、源代碼如下
§5.6借閱者服務模塊的實現
借閱者服務窗體的功能主要是圖書的查詢，個人借閱情況查看及個人部分信息的修改。界面圖如下：
5.6.1圖書查詢功能的實現
在本系統中，任何人都有權限使用查詢功能，不做任何限制。界面如下，
由于實現的查詢功能有多種，如按圖書編號、圖書名稱等字段進行完全體配查找和部分體配的模糊查找，還有按多個條件進行邏輯與或是邏輯或的多條件查找。其中實現的方法者差不多，所以只給出多條件查找的代碼，如下：
5.6.2借閱者登錄功能的實現
這個功能的實現與工作人員和管理人員登錄功能實現的方法大致一樣，并且還要簡單。是從User表中查到到借閱證號與密碼，看與用戶輸入的是否一致。如果一致，那么用戶就可查看自已的借閱情況并維護自己的部分信息。源代碼與借閱者登錄界面都略。
5.6.3借閱者借閱情況功能的實現
當借閱者正確登錄到系統后，此功能將被激活，使用戶能查看到自身的借閱情況。在此系統中，信息的顯示一般用ListView來實現，只在較少的情況下用到了DBgrid，因為我覺得ListView更好實現，并能使信息數據對用戶的完全分離。
在這里跟據借閱者的不同要求實現借閱情況的查詢，有檢查所有的借閱情部、某本書的借閱情況、和根據已借閱天數的來查詢。其中根椐借閱天數來查詢更有代表性，有方式一和方式二。以下給出此功能的源代碼
按借閱天數查詢方式一
按借閱天數查詢方式二
5.6.4借閱者個人資料維護功能的實現
此功能實現當前借閱者部份資料的修改，但借書證號和身份類別這樣的信息不允許修改，這是圖書館管理員模塊的功能。在此界面中點擊修改按鈕將出現“修改”窗體（Form8），點擊修改密碼按鈕將出現groupbox8，在這里進行密碼修改。關鍵源代碼如下。
這里給出個人部分信息修改的源代碼：
這里給出密碼修改的源代碼：
5.7工作人員－圖書借閱/歸還模塊的實現
5.7.1工作人員進行圖書借閱功能實現
在這個功能中，工作人員輸入借閱者的借閱證號和所要借閱的圖書的圖書編號，然后點擊借閱按鈕就可進行圖書借閱。考慮到實際中可能會出現只知圖書名而不知圖書編號的情況，在此界面下方加入了一個轉換功能，可以把圖書名稱轉換成圖書編號，再進行圖書借閱。
在借閱完成后會生借閱報表以便借閱者檢查和確認，借閱報表的打印效果如下圖，實現比較簡單，略去實現過程。
5.7.2工作人員進行圖書歸還功能實現
在此功能中，工作人員根據借閱者的借書證號和歸還的圖書編號進行圖書的歸還工作。并且根據現實中可能會出現的只知圖書名不知圖書編號的歸還情況，所以加入了按書籍名稱進行歸還的功能。這個功能是圖書借閱功能中把圖書名稱轉換成圖書編號的一種改進方法，這樣就不用如借閱功能中一樣要先轉換再借閱了。歸還完成后，同樣會打印出歸還報表以便用戶檢查和確認。
5.8圖書館管理員模塊的實現
5.8.1圖書館管理員圖書管理功能的實現
在這個功能中可以在（＊圖書編號）中輸入圖書編號，點查找按鈕后就會在各個相應的組件中顯示出信息，或按圖書名稱模糊查找到所要的記錄，在各個相應的組件中顯示第一條記錄的信息，也可在下端的ListView組件中點擊某一條記錄，在各個相應的組件中也會顯示所選記錄的信息。在入庫功能中只要不是相同的圖書編號并且帶＊號提示的字段不為空就可插入新的圖書記錄。刪除則刪除那些Book表中的圖書記錄，如果借出還可依用戶要求連帶刪除owner表中的記錄。因為圖書修改與圖書入庫的功能與工作人員記錄修改和工作人員記錄添加的實現過程一樣，所以下面僅給出刪除功能的源代碼，如下
5.8.2圖書館管理員工作人員和管理員管理功能的實現
在此功能中可以加入工作人員或是管理員，或是修改他們的密碼、權限。
在此功能中如果選中ListView中的記錄，則在右邊相應的組件中顯示出信息，并且管理員還可對這些記錄進行修改或加入新的記錄。并且也可以點刪除按鈕刪除選中的一條或多條記錄。刪除功能與圖書記錄的刪除一般，所以下面只給出添加與修改的實現過程。
5.8.3圖書館管理員修改圖書類別及統記功能的實現
在此窗體中能對圖書的類別進行刪除，添加和修改，這模塊的功能的實現過程與圖書記錄的刪除，添加和修改一樣的，但是這個窗體還能跟據圖書類別進行統計，還可根據Book表和owner表統計出圖書總數目，庫存圖書數目，借出圖書數目及借閱過期的圖書數目。在這里給出統計圖書總數目，庫存圖書數目，借出圖書數目及借閱過期的圖書數目的實現過程中的幾個函數和過程
5.8.4圖書館管理員借閱者管理功能的實現
查詢借閱者可根據借閱者的借書證號或姓名或身份編號查找到借閱者的信息，也可以實行模糊查找，這個功能的實現與前面圖書查找的實現過程一般，就不再詳細說明。
5.8.5圖書館維護借閱者管理功能的實現
此功能能對借閱者信息進行查看添加、刪除、修改。在這里給出刷新按鈕的實現過程
5.8.6圖書館身份維護功能的實現
篇4
VFP中有一種名為“項目管理器”的管理工具，它可以對圖書以及圖書銷售信息的數據、文檔以及源代碼等進行集中記錄和管理，使各種信息分類明確、條理清晰，便于人們查找。
1.2信息的查詢
VFP采用了先進的Rushmore快速查詢技術，系統能從記錄著眾多圖書及其銷售信息的數據庫表中迅速篩選出人們所需要的內容，整個查詢響應時間只有數秒鐘，非常迅速與高效。
1.3建立信息之間的關聯
一般數據庫管理系統中的各項信息都是相互獨立的，每一項信息與其他信息之間并無關聯，除非通過編程命令來專門描述；而VFP卻在這方面做出了改善，它可以在建表初期就把相關信息關聯起來，便于人們引用。
2基于VFP的圖書銷售管理系統的設計與開發
以VFP為基礎對圖書銷售管理系統進行設計與開發，大體可以分為以下幾個步驟。
2.1前期規劃與需求分析階段
在建立圖書銷售管理系統數據庫之前，一定要先做好規劃工作，因為它直接影響整個數據庫建立的全局運作，關系到數據庫建立的成功與否。具體來說，前期規劃內容主要包括：對建立數據庫的必要性和可行性進行分析，以及確定VFP數據庫在整個圖書銷售管理系統中所處的地位。然后進行需求分析。需求分析指的是，通過與出版社的相關工作人員進行交流與訪談，從而獲知其管理水平、需求情況、發展目標和計算機軟硬件設施條件等信息，再根據這些信息來對圖書銷售管理系統進行規劃設計，使系統更加符合人們的需求，更加人性化。
2.2物理設計階段
基于VFP對圖書銷售管理系統進行物理設計，主要指的是根據管理系統的數據模型以及計算機的系統類型等，對數據庫的物理結構（包括存儲結構與存取方法）進行設計。物理設計的主要目的是為了使計算機的存儲空間得到充分利用，從而提高管理系統的工作效率。
2.3模塊設計階段
基于VFP對圖書銷售管理系統進行模塊設計，主要指的是把管理系統數據庫中所需要記錄和統計的各項信息———如讀者的個人信息、讀者的訂單信息、出版社或書店的書庫信息、讀者的購書及退書信息、讀者的反饋信息、企業的賬簿信息以及管理處信息等，按照不同的分類進行模塊劃分，并且在劃分時要注意各項信息之間的關聯。當然，不同工作人員在設計過程當中還需要分工合作，每個人負責一項專門的工作，這樣才能提高工作效率。比如，由圖書銷售人員負責管理賬戶的創建和修改，并管理讀者及讀者訂單的信息、檢索書籍的信息和統計每日賬目等；由倉庫管理人員負責管理書庫的信息（包括錄入與查詢等）。舉例來說，一種較為常見的基于VFP的圖書銷售管理系統會有以下五大模塊：讀者信息模塊、讀者訂單信息模塊、書庫信息模塊、銀行（賬簿）信息模塊、管理處信息模塊，每個模塊都具有其獨特的功能。
2.2.1讀者信息模塊
讀者信息模塊主要有3個功能，即編輯讀者信息功能（如對讀者的姓名、性別、身份、電話、住址、E－mail等信息進行添加、修改和刪除等）、檢索讀者信息功能（此功能是讀者信息模塊最重要的功能，它能以單一或者組合兩種條件來對相關讀者的信息進行匹配與查找，檢索的字段亦包括讀者的姓名、性別、身份、電話、住址、E－mail等，條件的匹配可以是“大于”“小于”“等于”“不等于”“包含”“在……”等多種形式，條件的組合也有“與”和“或”兩種形式）和打印讀者信息功能。
2.2.2讀者訂單信息模塊
讀者訂單信息模塊主要有3個功能，即編輯讀者訂單信息功能（如對讀者的姓名以及聯系方式，所訂圖書的書名、作者、出版社、訂單號、單價、數量、總價、下單日期等信息進行添加、修改和刪除等）、檢索讀者訂單信息功能（此功能是讀者訂單信息模塊最重要的功能，同樣能以單一或者組合兩種條件來對相關讀者訂單的信息進行匹配與查找，檢索的字段包括讀者的姓名以及聯系方式，所訂圖書的書名、作者、出版社、訂單號、單價、數量、總價、下單日期等，條件的匹配有“大于”“小于”“等于”“不等于”“包含”“在……”等多種形式，條件的組合有“與”和“或”兩種形式）和打印讀者訂單信息功能。
2.2.3書庫信息模塊
書庫模塊又細分為存書查詢、購書和退書3個子模塊。存書查詢模塊主要有3個功能，即編輯存書信息功能（如對圖書的書名、作者、出版社、售價、庫存數量、出版日期等信息進行添加、修改和刪除等）、檢索存書信息功能（與讀者信息模塊和讀者訂單信息模塊類似）和打印存書信息功能。購書模塊主要有3個功能，即編輯購書信息功能（如對購買圖書的書名、作者、出版社、單價、數量、總價等信息進行添加、修改和刪除等）、檢索購書信息功能（與讀者信息模塊和讀者訂單信息模塊類似）和打印購書信息功能。退書模塊亦主要有3個功能，即編輯退書信息功能（如對所退圖書的書名、作者、出版社、單價、數量、總價、退書原因等信息進行添加、修改和刪除等）、檢索退書信息功能（與讀者信息模塊和讀者訂單信息模塊類似）和打印退書信息功能。
2.2.4銀行（賬簿）信息模塊
銀行（賬簿）信息模塊主要有3個功能，即編輯銀行（賬簿）信息功能（如對圖書銷售的總額、費用支出、凈收入、余額和日期等信息進行添加、修改和刪除等）、檢索銀行（賬簿）信息功能（與讀者信息模塊和讀者訂單信息模塊類似）和打印銀行（賬簿）信息功能。
2.2.5管理處信息模塊
管理處信息模塊主要有3個功能，即編輯管理處信息功能（如對各項事件的記錄、備注和日期等信息進行添加、修改和刪除等）、檢索管理處信息功能（與讀者信息模塊和讀者訂單信息模塊類似）和打印管理處信息功能。
2.4實施和運行階段
基于VFP的圖書銷售管理系統在完成前期規劃與需求分析、物理設計以及模塊設計之后，可以開始試運行。這一階段也可以稱為調試或試驗階段，是對管理系統的具體操作實踐和試用。在此期間，工作人員要仔細觀察和體驗系統的運行與使用情況，并將出現的各種問題進行詳細記錄，同時也要做好數據的備份和轉存工作，以免系統出現故障導致數據丟失。觀察與記錄完畢之后，相關人員還要對系統運行中所出現的不良狀況和故障進行探討與分析，并加以改進，直到系統可以正常運行為止。
篇5
總體來說就是在自己的計算機上，為實現讀書治學的目的，使雜亂無章的信息資源變成有組織的信息集合，通過免費的或基本免費的軟件，將網上的有關信息資源，通過該管理軟件進行存取，在軟件內完成編輯管理，根據個人需求，供其有效利用。個人數字圖書館的意義在于，通過這一軟件系統，對于個人知識儲備的數字化整合可以順利完成，用戶能夠自己創建、維護、使用該軟件系統。
這一新形式的個人數字圖書館與傳統圖書館比較，突出的特點是：
（1）數字化。使紙質資料的文獻形態改變，使其數字化。曾經的紙質圖書存放時間較長后，其一、積少成多，體積增大，內容增多，越來越不利于文獻資料的整理和保存，其二、隨著時間的推移，部分資料由于保管不善肯定會發生丟失損毀，舊資料查找時也是一個大工程，那么如何處理這些破舊書刊紙質資料？去粗存精選擇性保管顯然不是最理想的方法，那么使其數字化可以妥善保存，不遺失資料的同時更加能夠便于查找。
（2）數據庫化。當今，互聯網上供人免費下載的數字資源日益增多，大家將自己感興趣的文件和資料下載到本地電腦的文件夾中，供日后查閱或使用。但是文件夾不具有數據庫結構，并不能有效的進行檢索文件，當我們下載的文件日益增多的時候，無法有效的管理這些下載的文件，那么，就可以通過個人數字圖書館對其進行統一管理，在需要時通過搜索引擎，快速準確的查找到目標文件，無論文檔文件還是圖片文件或是視頻文件，均可自動識別并打開后臺運行，操作簡單，使用方便。
（3）檢索功能增強化。因為個人數字圖書館的使用者們并不是專業的情報學工作人員，無法精確的對于所需檢索的內容進行輸入，所以，要快速準確的查找到文獻資料，在檢索功能的設置上要加強，即使是模糊的搜索關鍵詞也一樣能迅速的找到需要的文獻資料?；镜臋z索功能中至少具有字段檢索、單項檢索、截詞檢索、全庫掃描檢索等，并且，各種類型的文件要在統一的檢索界面，使用方便查找快捷，檢索歷史隨時保存便于隨時調用。
2 個人數字圖書館論文管理系統在高校應用的可行性研究與分析
在高校設立個人數字圖書館論文管理系統，不僅為學生讀者帶來很大方便，同時在系統設計初期的可行性研究與分析中得出其具有很多的優勢，下面將通過3個方面詳述分析。
（1）高校圖書館豐富的信息資源，配合校園內完善的網絡環境。豐富的館藏資源，電子文獻資料較全，是高校圖書館館藏的重要特點，面向高校大學生，購買了種類豐富的各類論文數據庫供學生學習查閱，同時自建論文數據資料庫，為學生查閱下載論文資料提供了很大的方便。另外，高校的現代化設施建設完善，如學生宿舍的高速網絡、圖書館的電子閱覽室、校園全網無線覆蓋等，這些設施為個人數字圖書館的建設提供了堅實的基礎和現實保障。
（2）借鑒國內外成功的案例，為我們提供了寶貴經驗。美國康奈爾大學圖書館曾成功開發個人數字圖書館平臺――My liberty。用戶可以自行通過該平臺搜集電子資源，既可以來自公共網絡的任何地方，也可以來自校園網絡的內部門戶，在這個平臺上管理、編輯、下載，打造屬于自己的個人圖書館。在國內，浙江大學也曾成功開發“我的圖書館”，系統功能如：新書通告、數字資源定制、搜索引擎、書簽功能、個人信息保護等。雖然開發項目不是完全相同，但這些成功的案例都具有一定的可借鑒性。
（3）數量穩定的受眾用戶群。高校龐大的用戶群體都具有高學識、高素質，比較熟練掌握計算機應用、網絡通訊知識、文獻檢索知識等，他們無論是論文創作還是課題研發，都需要強大的學術資料支持，這一軟件系統可以為他們提供高水平、多層次的個性化信息服務，相信廣大師生都能夠廣泛的參與其中，構成穩定的軟件系統的受眾群體。
3 個人數字圖書館論文管理系統的開發構想
根據個人數字圖書館的基本研究發現，個人數字圖書館的數字化、數據庫化特點，以及高等學校的軟硬件設施和環境，以及推廣使用面向的目標群體，非常便于個人數字圖書館論文管理系統的開發與利用。
