前言：本站為你精心整理了圖書館管理畢業范文，希望能為你的創作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

摘要：圖書管理系統是典型的信息管理系統(MIS),其開發主要包括后臺數據庫的建立和維護以及前端應用程序的開發兩個方面。對于前者要求建立起數據一致性和完整性強、數據安全性好的庫。而對于后者則要求應用程序功能完備,易使用等特點。

因此本人結合開入式圖書館的要求，對MSSQLServer2000數據庫管理系統、SQL語言原理、Delphi應用程序設計，Delphi數據庫技術進行了較深入的學習和應用，主要完成對圖書管理系統的需求分析、功能模塊劃分、數據庫模式分析，并由此設計了數據庫結構和應用程序。系統運行結果證明，本文所設計的圖書管理系統可以滿足借閱者、圖書館工作人員和高級管理員三方面的需要。

第一章對數據庫應用系統開發和圖書管理系統進行了簡明的介紹，并分析了開發圖書管理系統所應進行的工作。

第二章對數據庫的設計和SQL語言的使用進行了系統分析，為深入理解數據庫應用打下了基礎。

第三章學習了具體的開發工具Delphi6.0，對其數據庫組件，SQL語言在Delphi中的應用等數據庫編程關鍵技術進行了系統的介紹。

第四章分析了圖書管理信息系統的應用需求，按照數據庫設計理論一步一步地給出了系統需求說明書、局部ER圖、全局ER圖、系統關系模式，子模式，利用MSSQLServer2000建立了數據庫

第五章進行了具體的程序設計，具體劃分了三類用戶的操作權限，設計了了三個操作界面。實現了數據庫表的瀏覽，記錄的添加、刪除和修改，報表的生成，實現了多數據庫表的連接操作，實現了多條件查詢和模糊查詢，并靈活實現了對不可更新查詢結果集的更新操作，實現了主從表操作，實現了密碼維護功能，最后，系統還可以導入數據庫以對任意同結構的數據庫進行操作。

設計充分利用Delphi6、MSSQLServer2000數據庫技術的強大力量，提高了編程效率和可靠性。

關鍵詞：數據庫，SQL語言，MSSQLServer，Delphi6，

數據庫組件，圖書管理，窗體，listview組件

第一章緒論

§1.1數據庫應用系統開發簡介

在數據庫應用系統開發之前，對開發數據庫的基本概念應當了解，對數據庫的結構、開發數據庫應用程序的步驟、開發體系及方法都應當有相當清晰的了解和認識。

數據庫應用系統開發的目標是建立一個滿足用戶長期需求的產品。開發的主要過程為：理解用戶的需求，然后，把它們轉變為有效的數據庫設計。把設計轉變為實際的數據庫，并且這些數據庫帶有功能完備、高效能的應用。

數據庫技術在計算機軟件鄰域研究中一直是非常重要的主題，產生于60年代，30多年來數據庫技術得到了迅速發展，并已形成較為完整的理論體系和一大批實用系統。并且，近年來，隨著WorldWideWeb(WWW)的猛增及Internet技術的迅速發展，使得數據庫技術之時成為最熱門技術之一。

1.1.1數據庫

如圖1.1顯示了數據庫系統的主要組件。數據庫由DBMS（數據庫管理系統）處理，DBMS則由開發人員和用戶通過應用程序直接或間接地使用。它主要包括四個要素：用戶數據、元數據、索引和應用元數據。

1.1.1.1用戶數據

目前，大多數主流數據庫管理系統把用戶數據表示為關系。現在把關系看作數據表。表的列包含域或屬性，表的行包含對應業務環境中的實體的記錄。并非所有的關系都同樣符合要求，有些關系比其它關系更結構化一些。第二章描述了一個用以產生良好結構關系的過程，稱作規范化。

為了對比結構差的關系和結構好的關系之間的差別，以本文所設計的圖書管理系統中的圖書和圖書借閱者關系為例來說明，假若設計關系R1（借書證號，姓名，性別，身份編號，身份證，聯系電話，圖書編號,圖書名稱，圖書類別，作者，出版社，出版日期，備注，價格，數量）；這個關系的問題出在它有關于兩個不同主題的數據，就是圖書借閱者和圖書。用這種方式構成的關系在進行修改時，會出現問題。因為一個圖書借閱者可能借閱多本書，如果某個圖書借閱者的某個字段（如聯系電話）出現變更，它所借閱的圖書記錄（可能多個）也就必須變化，這是不好的。因此數據用兩個關系表示更好。現在如果某圖書借閱者改變了它的聯系電話，只有關系（表）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圖書管理系統

當今時代是飛速發展的信息時代。在各行各業中離不開信息處理，這正是計算機被廣泛應用于信息管理系統的環境。計算機的最大好處在于利用它能夠進行信息管理。使用計算機進行信息控制，不僅提高了工作效率，而且大大的提高了其安全性。

尤其對于復雜的信息管理，計算機能夠充分發揮它的優越性。計算機進行信息管理與信息管理系統的開發密切相關，系統的開發是系統管理的前提。本系統就是為了管理好圖書館信息而設計的。

圖書館作為一種信息資源的集散地，圖書和用戶借閱資料繁多，包含很多的信息數據的管理，現今，有很多的圖書館都是初步開始使用，甚至尚未使用計算機進行信息管理。根據調查得知，他們以前對信息管理的主要方式是基于文本、表格等紙介質的手工處理，對于圖書借閱情況（如借書天數、超過限定借書時間的天數）的統計和核實等往往采用對借書卡的人工檢查進行，對借閱者的借閱權限、以及借閱天數等用人工計算、手抄進行。數據信息處理工作量大，容易出錯；由于數據繁多，容易丟失，且不易查找。總的來說，缺乏系統，規范的信息管理手段。盡管有的圖書館有計算機，但是尚未用于信息管理，沒有發揮它的效力，資源閑置比較突出，這就是管理信息系統的開發的基本環境。

數據處理手工操作，工作量大，出錯率高，出錯后不易更改。圖書館采取手工方式對圖書借閱情況進行人工管理，由于信息比較多，圖書借閱信息的管理工作混亂而又復雜；一般借閱情況是記錄在借書證上，圖書的數目和內容記錄在文件中，圖書館的工作人員和管理員也只是當時對它比較清楚，時間一長，如再要進行查詢，就得在眾多的資料中翻閱、查找了，造成查詢費時、費力。如要對很長時間以前的圖書進行更改就更加困難了。

基于這此問題，我認為有必要建立一個圖書管理系統，使圖書管理工作規范化，系統化，程序化，避免圖書管理的隨意性，提高信息處理的速度和準確性，能夠及時、準確、有效的查詢和修改圖書情況。

§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。由此可以看出圖形組件的功能很弱，圖形組件的用處何在呢？其實使用圖形組件的最大好處在于節省資源，正是因為它們的功能較弱，所以使用的系統資源就要少。在一個應用程序中，如果能在不影響其功能的前提下合理大量地使用圖形組件，將會大減少程序對系統資源的消耗。

非可視組件是與可視組件相并列的另一類組件，非可視組件在程序運行中是不可見的（除各種對話框組件之外，事實上有人認為對話框組件不能歸入非可視組件，應該是另一種介于可視與非可視之間的組件）。

最后要說明一下，常說的控件實際上是一種組件。也就是說組件這個概念要大于控件，控件在內涵上包含于組件中。控件由Windows系列操作系統提出并使用，而組件是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語言的。可以在Tquery或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圖書館身份維護功能的實現

這一部分是對借閱者身份進行管理，能對身份進行添加、刪除、修改。并且同樣的在listview中選中某條或多條記錄時會在相應的右邊的組件中顯示出信息。此功能實現過程與前面所敘有雷同，略。

5.8.7圖書館借閱者統計功能的實現

此功能按借閱者身份進行統計，得出具有某種身份的借閱者總數，此種身份的并借閱圖書的借閱者數和所借閱的圖書數，在下面給出實現過程。

5.8.8圖書館統計借閱過期記錄功能的實現

打印出的借閱過期催還報表如下圖所示：

此報表能顯示按借書證號升序排列的借閱信息超過限定時限的信息，其中主要的SQL語句如下：

5.9系統信息顯示的實現

顯過本系統的信息，并且右邊的字向上滾動顯示，主要實現如下：

……………………