圖書(shū)館管理系統

 

摘   要
圖書(shū)管理系統是典型的信息管理系統(MIS),其開(kāi)發(fā)主要包括后臺數據庫的建立和維護以及前端應用程序的開(kāi)發(fā)兩個(gè)方面。對于前者要求建立起數據一致性和完整性強、數據安全性好的庫。而對于后者則要求應用程序功能完備,易使用等特點(diǎn)。
因此本人結合開(kāi)入式圖書(shū)館的要求，對MS SQL Server2000數據庫管理系統、SQL語(yǔ)言原理、Delphi應用程序設計，Delphi數據庫技術(shù)進(jìn)行了較深入的學(xué)習和應用，主要完成對圖書(shū)管理系統的需求分析、功能模塊劃分、數據庫模式分析，并由此設計了數據庫結構和應用程序。系統運行結果證明，本文所設計的圖書(shū)管理系統可以滿(mǎn)足借閱者、圖書(shū)館工作人員和高級管理員三方面的需要。
第一章對數據庫應用系統開(kāi)發(fā)和圖書(shū)管理系統進(jìn)行了簡(jiǎn)明的介紹，并分析了開(kāi)發(fā)圖書(shū)管理系統所應進(jìn)行的工作。
第二章對數據庫的設計和SQL語(yǔ)言的使用進(jìn)行了系統分析，為深入理解數據庫應用打下了基礎。
第三章學(xué)習了具體的開(kāi)發(fā)工具Delphi 6.0，對其數據庫組件，SQL語(yǔ)言在Delphi中的應用等數據庫編程關(guān)鍵技術(shù)進(jìn)行了系統的介紹。
第四章分析了圖書(shū)管理信息系統的應用需求，按照數據庫設計理論一步一步地給出了系統需求說(shuō)明書(shū)、局部ER圖、全局ER圖、系統關(guān)系模式，子模式，利用MS　SQL　Server2000建立了數據庫
第五章進(jìn)行了具體的程序設計，具體劃分了三類(lèi)用戶(hù)的操作權限，設計了了三個(gè)操作界面。實(shí)現了數據庫表的瀏覽，記錄的添加、刪除和修改，報表的生成，實(shí)現了多數據庫表的連接操作，實(shí)現了多條件查詢(xún)和模糊查詢(xún)，并靈活實(shí)現了對不可更新查詢(xún)結果集的更新操作，實(shí)現了主從表操作，實(shí)現了密碼維護功能，最后，系統還可以導入數據庫以對任意同結構的數據庫進(jìn)行操作。
設計充分利用Delphi 6、MS SQL Server2000數據庫技術(shù)的強大力量，提高了編程效率和可靠性。
關(guān)鍵詞：數據庫，SQL語(yǔ)言，MS SQL Server，Delphi6，
數據庫組件，圖書(shū)管理，窗體，listview組件
 
目    錄
摘  要 ……………………………………………………………………………… I
第一章  緒  論 …………………………………………………………………… 1
§1.1 數據庫應用系統開(kāi)發(fā)簡(jiǎn)介 ……………………………………………… 1
§1.2 圖書(shū)管理系統 ……………………………………………………… 4
§1.3 本文所做的主要工作 …………………………………………………… 6
第二章  數據庫理論基礎 ………………………………………………………… 7
§2.1 數據庫系統設計及范式分析 …………………………………………… 7
§2.2 SQL語(yǔ)言介紹………………………………………………………………… 11
2.2.1 SQL基礎  ………………………………………………………………… 11
2.2.2 SQL語(yǔ)句  ………………………………………………………………… 12
第三章  應用系統開(kāi)發(fā)工具………………………………………………… 16
§3.1 Delphi6.0　VCL組件的體系結構……………………………………… 16
§3.2 數據庫組件介紹  …………………………………………………………… 17
§3.3 SQL語(yǔ)言在Delphi中的應用  …………………………………………… 18
§3.4 MS SQL Server簡(jiǎn)述  ……………………………………………………  22
第四章  圖書(shū)管理系統設計分析 ………………………………………… 24
§4.1 應用需求分析 …………………………………………………………… 24
§4.2 系統功能模塊劃分 ……………………………………………………… 29
§4.3 系統數據庫設計 ………………………………………………………… 29
第五章  圖書(shū)管理系統應用程序設計 …………………………………… 37
§5.1 系統窗體模塊組成 ………………………………………………………… 37
§5.2 數據模塊窗體的設置 ……………………………………………………… 37
§5.3啟動(dòng)畫(huà)面的實(shí)現…………………………………………………………… 38
§5.4用戶(hù)登錄窗體的的實(shí)現……………………………………………………… 39
§5.5用戶(hù)密碼認證窗體的的實(shí)現………………………………………………… 39
§5.6借閱者服務(wù)模塊的實(shí)現…………………………………………………… 40
5.6.1圖書(shū)查詢(xún)功能的實(shí)現………………………………………………… 41
5.6.2借閱者登錄功能的實(shí)現………………………………………………… 42
5.6.3借閱者借閱情況功能的實(shí)現…………………………………………… 43
5.6.4借閱者個(gè)人資料維護功能的實(shí)現……………………………………… 47
§5.7工作人員－圖書(shū)借閱/歸還模塊的實(shí)現……………………………………… 49
5.7.1工作人員進(jìn)行圖書(shū)借閱功能實(shí)現……………………………………… 50
5.7.2工作人員進(jìn)行圖書(shū)歸還功能實(shí)現……………………………………… 53
§5.8圖書(shū)館管理員模塊的實(shí)現…………………………………………… 54
5.8.1圖書(shū)館管理員圖書(shū)管理功能的實(shí)現…………………………………… 55
5.8.2圖書(shū)館管理員工作人員和管理員管理功能的實(shí)現…………………… 58
5.8.3圖書(shū)館管理員修改圖書(shū)類(lèi)別及統記功能的實(shí)現……………………… 60
5.8.4圖書(shū)館管理員借閱者管理功能的實(shí)現………………………………… 62
5.8.5圖書(shū)館維護借閱者管理功能的實(shí)現………………………………… 62
5.8.6圖書(shū)館身份維護功能的實(shí)現……………………………………… 64
5.8.7圖書(shū)館借閱者統計功能的實(shí)現………………………………… 65
5.8.8圖書(shū)館統計借閱過(guò)期記錄功能的實(shí)現………………………… 67
§5.9系統信息顯示的實(shí)現………………………………………………… 68
第六章 結束語(yǔ) ……………………………………………………………… 69
致  謝 ………………………………………………………………………………70
參考書(shū)目 …………………………………………………………………………… 70
 

第一章  緒  論
§1.1  數據庫應用系統開(kāi)發(fā)簡(jiǎn)介
在數據庫應用系統開(kāi)發(fā)之前，對開(kāi)發(fā)數據庫的基本概念應當了解，對數據庫的結構、開(kāi)發(fā)數據庫應用程序的步驟、開(kāi)發(fā)體系及方法都應當有相當清晰的了解和認識。
數據庫應用系統開(kāi)發(fā)的目標是建立一個(gè)滿(mǎn)足用戶(hù)長(cháng)期需求的產(chǎn)品。開(kāi)發(fā)的主要過(guò)程為：理解用戶(hù)的需求，然后，把它們轉變?yōu)橛行У臄祿�庫設計。把設計轉變?yōu)閷?shí)際的數據庫，并且這些數據庫帶有功能完備、高效能的應用。
數據庫技術(shù)在計算機軟件鄰域研究中一直是非常重要的主題，產(chǎn)生于60年代，30多年來(lái)數據庫技術(shù)得到了迅速發(fā)展，并已形成較為完整的理論體系和一大批實(shí)用系統。并且，近年來(lái)，隨著(zhù)World Wide Web(WWW)的猛增及Internet技術(shù)的迅速發(fā)展，使得數據庫技術(shù)之時(shí)成為最熱門(mén)技術(shù)之一。
1.1.1  數據庫
如圖1.1顯示了數據庫系統的主要組件。數據庫由DBMS（數據庫管理系統）處理，DBMS則由開(kāi)發(fā)人員和用戶(hù)通過(guò)應用程序直接或間接地使用。它主要包括四個(gè)要素：用戶(hù)數據、元數據、索引和應用元數據。

1.1.1.1 用戶(hù)數據
目前，大多數主流數據庫管理系統把用戶(hù)數據表示為關(guān)系�，F在把關(guān)系看作數據表。表的列包含域或屬性，表的行包含對應業(yè)務(wù)環(huán)境中的實(shí)體的記錄。并非所有的關(guān)系都同樣符合要求，有些關(guān)系比其它關(guān)系更結構化一些。第二章描述了一個(gè)用以產(chǎn)生良好結構關(guān)系的過(guò)程，稱(chēng)作規范化。
為了對比結構差的關(guān)系和結構好的關(guān)系之間的差別，以本文所設計的圖書(shū)管理系統中的圖書(shū)和圖書(shū)借閱者關(guān)系為例來(lái)說(shuō)明，假若設計關(guān)系R1（借書(shū)證號，姓名，性別，身份編號，身份證，聯(lián)系電話(huà)，圖書(shū)編號,圖書(shū)名稱(chēng)，圖書(shū)類(lèi)別，作者，出版社，出版日期，備注，價(jià)格，數量）；這個(gè)關(guān)系的問(wèn)題出在它有關(guān)于兩個(gè)不同主題的數據，就是圖書(shū)借閱者和圖書(shū)。用這種方式構成的關(guān)系在進(jìn)行修改時(shí)，會(huì )出現問(wèn)題。因為一個(gè)圖書(shū)借閱者可能借閱多本書(shū)，如果某個(gè)圖書(shū)借閱者的某個(gè)字段（如聯(lián)系電話(huà)）出現變更，它所借閱的圖書(shū)記錄（可能多個(gè)）也就必須變化，這是不好的。因此數據用兩個(gè)關(guān)系表示更好�，F在如果某圖書(shū)借閱者改變了它的聯(lián)系電話(huà)，只有關(guān)系（表）user的對應行需要改變。當然，要想產(chǎn)生一個(gè)，顯示圖書(shū)名稱(chēng)及其借閱者聯(lián)系電話(huà)的報表，就需要將這兩個(gè)表的行結合起來(lái)。結果表明，將關(guān)系分別存儲，在生成報表的時(shí)候將它們結合起來(lái)，比把它們存儲在一個(gè)合成的表中更好。
user（借書(shū)證號，姓名，性別，身份編號，身份證，聯(lián)系電話(huà)，）
book（圖書(shū)編號,圖書(shū)名稱(chēng)，圖書(shū)類(lèi)別，作者，出版社，出版日期，備注，價(jià)格，數量）
1.1.1.2  元數據
數據庫是自描述的，這就意味著(zhù)它自身包含了它的結構的描述，這種結構的描述稱(chēng)作元數據。因為DBMS產(chǎn)品是用來(lái)存儲和操縱表的，所以大多數產(chǎn)品把元數據以表的形式存儲，有時(shí)稱(chēng)作系統表。這些系統表存儲了數據庫中表的情況，指出每一個(gè)表中有多少列，那一列是主關(guān)鍵字，每一列的數據類(lèi)型的描述，它也存儲索引、關(guān)鍵字、規則和數據庫結構的其他部分。
在表中存儲元數據不僅對DBMS是有效的，對用戶(hù)也是方便的，因為他們可以使用與查詢(xún)用戶(hù)數據同樣的查詢(xún)工具來(lái)查詢(xún)元數據。本文第二章所介紹的SQL語(yǔ)言可以同時(shí)用于元數據和用戶(hù)數據。
1.1.1.3  索引
第三種類(lèi)型的數據改進(jìn)了數據庫的性能和可訪(fǎng)問(wèn)性，這種數據經(jīng)常稱(chēng)作開(kāi)銷(xiāo)數據，盡管有時(shí)也采用其他類(lèi)型的數據結構，如鏈表，但它主要還是索引。索引可以用來(lái)排序和快速訪(fǎng)問(wèn)數據。下面以本人的圖書(shū)管理信息系統中的book表為例來(lái)說(shuō)明。
假定數據在磁盤(pán)上是按’圖書(shū)編號’的遞增順序排列的，用戶(hù)想打印一個(gè)按’圖書(shū)名稱(chēng)’排序的圖書(shū)數據報表。為此，所有的數據都需要從源表中提取出來(lái)并排序，除非表很小，否則這是一個(gè)很費時(shí)的過(guò)程�；蛘�，可以在‘圖書(shū)名稱(chēng)’字段上創(chuàng )建一個(gè)索引，該索引的條目按照‘圖書(shū)名稱(chēng)’排序，這樣，該索引的條目可以讀出來(lái)，并用來(lái)按順序訪(fǎng)問(wèn)book數據。
索引用于快速訪(fǎng)問(wèn)數據。例如，一個(gè)用戶(hù)只想訪(fǎng)問(wèn)book表中‘圖書(shū)類(lèi)別’值為‘01’的那些學(xué)生。如果沒(méi)有索引，則必須搜索整個(gè)源表；但有了索引之后，可以找到索引條目，并使用它來(lái)挑選所有合適的行。
索引對排序和查找是有幫助的，但要付出代價(jià)。book表中的行每次改變時(shí)，索引也必須改變，這意味著(zhù)索引并非隨意的，應該在真正需要時(shí)保存。
1.1.1.4  應用元數據
存儲在數據庫中的第四種數據是應用元數據，它用來(lái)存儲用戶(hù)窗體、報表、查詢(xún)和其他形式的查詢(xún)組件。并非所有的DBMS都支持應用組件，支持組件的DBMS也不一定把全部組件的結構作為應用元數據存儲在數據庫中。然而，大多數現代的DBMS產(chǎn)品存儲這種數據作為數據庫的一部分。一般來(lái)說(shuō)，數據庫開(kāi)發(fā)人員和用戶(hù)都不直接訪(fǎng)問(wèn)應用元數據，想反，他們通過(guò)DBMS中的工具來(lái)處理這些數據。
MS SQL Server2000中就支持窗體、存儲過(guò)程等應用元數據。
1.1.2  數據庫管理系統
數據庫管理系統（DBMS）是指數據庫系統中管理數據的軟件系統。DBMS是數據庫系統的核心組成部分。對數據庫的一切操作，包括定義、更新及各種控制,都是通過(guò)DBMS進(jìn)行的。DBMS總是基于某種數據模型，可以把DBMS看成是某種數據模型在計算機系統上的具體實(shí)現。根據數據模型的不同，DBMS可以分成層次型、網(wǎng)狀型、關(guān)系型、面向對象型等。MS SQL Server2000就是一種關(guān)系型數據庫管理系統。
關(guān)系模型。關(guān)系模型主要是用二維表格結構表達實(shí)體集，用外鍵表示實(shí)體間聯(lián)系。關(guān)系模型是由若干個(gè)關(guān)系模式組成的集合。關(guān)系模式相當于前面提到的記錄類(lèi)型，它的實(shí)例稱(chēng)為關(guān)系，每個(gè)關(guān)系實(shí)際上是一張二維表格。
關(guān)系模型和層次、網(wǎng)狀模型的最大判別是用關(guān)鍵碼而不是用指針導航數據，表格簡(jiǎn)單用戶(hù)易懂，編程時(shí)并不涉及存儲結構，訪(fǎng)問(wèn)技術(shù)等細節。關(guān)系模型是數學(xué)化模型。SQL語(yǔ)言是關(guān)系數據庫的標準化語(yǔ)言，已得到了廣泛的應用。
如圖1.1所示，DBMS的特點(diǎn)和功能可以分為三個(gè)子系統：設計工具子系統、運行子系統和DBMS引擎。
設計子系統有一個(gè)方便數據庫及其應用創(chuàng )建的工具集。它典型地包含產(chǎn)生表、窗體、查詢(xún)和報表的工具。DBMS產(chǎn)品還提供編程語(yǔ)言和對編程語(yǔ)言的接口。
運行子系統處理用設計子系統開(kāi)發(fā)的應用組件。它所包含的運行處理器用來(lái)處理窗體和數據庫的數據交互，以及回答查詢(xún)和打印報表等。
DBMS引擎從其他兩個(gè)組件接受請求，并把它們翻譯成對操作系統的命令，以便讀寫(xiě)物理介質(zhì)上的數據。DBMS引擎還涉及事務(wù)管理、鎖、備份和恢復。
1.1.3  創(chuàng )建數據庫
1.1.3.1  數據庫模式
數據庫模式定義了數據庫的結構、表、關(guān)系、域和業(yè)務(wù)規則。數據庫模式是一種設計，數據庫和應用正是建立在此基礎上的。
域是一列可能擁有的值的集合。必須為每一個(gè)表的每一列確定域。除了數據的物理格式外，還需要確定是否有些域對表來(lái)說(shuō)是唯一的。
數據庫模式的最后一個(gè)要素是業(yè)務(wù)規則，它是對需要反映在數據庫和數據庫應用程序中的業(yè)務(wù)活動(dòng)的約束。業(yè)務(wù)規則是模式的一個(gè)重要部分，因為他們指定了無(wú)論什么數據變化到達DBMS引擎，允許的數據值必須滿(mǎn)足的約束。不管無(wú)效的數據變化請求是來(lái)自窗體的用戶(hù)、查詢(xún)/修改請求還是應用程序，DBMS都應該拒絕。
遺憾的是，不同的DBMS產(chǎn)品用不同的方法實(shí)施業(yè)務(wù)規則。在某些情況下，DBMS產(chǎn)品不具備實(shí)施必要業(yè)務(wù)規則的能力，必須以代碼形式把它們編入應用程序。
1.1.3.2  創(chuàng )建表
1.1.3.3  定義聯(lián)系
1.1.4  應用組件
數據庫應用包括窗體、查詢(xún)、報表、菜單和應用程序。
§1.2  圖書(shū)管理系統
當今時(shí)代是飛速發(fā)展的信息時(shí)代。在各行各業(yè)中離不開(kāi)信息處理，這正是計算機被廣泛應用于信息管理系統的環(huán)境。計算機的最大好處在于利用它能夠進(jìn)行信息管理。使用計算機進(jìn)行信息控制，不僅提高了工作效率，而且大大的提高了其安全性。
尤其對于復雜的信息管理，計算機能夠充分發(fā)揮它的優(yōu)越性。計算機進(jìn)行信息管理與信息管理系統的開(kāi)發(fā)密切相關(guān)，系統的開(kāi)發(fā)是系統管理的前提。本系統就是為了管理好圖書(shū)館信息而設計的。
圖書(shū)館作為一種信息資源的集散地，圖書(shū)和用戶(hù)借閱資料繁多，包含很多的信息數據的管理，現今，有很多的圖書(shū)館都是初步開(kāi)始使用，甚至尚未使用計算機進(jìn)行信息管理。根據調查得知，他們以前對信息管理的主要方式是基于文本、表格等紙介質(zhì)的手工處理，對于圖書(shū)借閱情況（如借書(shū)天數、超過(guò)限定借書(shū)時(shí)間的天數）的統計和核實(shí)等往往采用對借書(shū)卡的人工檢查進(jìn)行，對借閱者的借閱權限、以及借閱天數等用人工計算、手抄進(jìn)行。數據信息處理工作量大，容易出錯；由于數據繁多，容易丟失，且不易查找�？偟膩�(lái)說(shuō)，缺乏系統，規范的信息管理手段。盡管有的圖書(shū)館有計算機，但是尚未用于信息管理，沒(méi)有發(fā)揮它的效力，資源閑置比較突出，這就是管理信息系統的開(kāi)發(fā)的基本環(huán)境。
數據處理手工操作，工作量大，出錯率高，出錯后不易更改。圖書(shū)館采取手工方式對圖書(shū)借閱情況進(jìn)行人工管理，由于信息比較多，圖書(shū)借閱信息的管理工作混亂而又復雜；一般借閱情況是記錄在借書(shū)證上，圖書(shū)的數目和內容記錄在文件中，圖書(shū)館的工作人員和管理員也只是當時(shí)對它比較清楚，時(shí)間一長(cháng)，如再要進(jìn)行查詢(xún)，就得在眾多的資料中翻閱、查找了，造成查詢(xún)費時(shí)、費力。如要對很長(cháng)時(shí)間以前的圖書(shū)進(jìn)行更改就更加困難了。
基于這此問(wèn)題，我認為有必要建立一個(gè)圖書(shū)管理系統，使圖書(shū)管理工作規范化，系統化，程序化，避免圖書(shū)管理的隨意性，提高信息處理的速度和準確性，能夠及時(shí)、準確、有效的查詢(xún)和修改圖書(shū)情況。
§1.1 系統所做工作
1) 了解應用開(kāi)發(fā)工具的現狀
2) DelPHi6.0編程基礎
3) MS SQL Server基礎
4) 設計數據庫；設計界面
5) 開(kāi)發(fā)數據庫。數據庫實(shí)現的一些功能有
l 數據和數據說(shuō)明的醒目顯示；
l 多條件的查詢(xún)、多條記錄的檢索、模糊查詢(xún)；
l 數據文件某種存儲格式導入數據窗體，經(jīng)過(guò)數據完整性校驗存入數據庫；
l 數據庫安全性的設計；
l 數據庫的設計、數據接口、界面的設計。

§1.3  本文所作工作
緒論部分對數據庫應用系統的結構、開(kāi)發(fā)進(jìn)行了簡(jiǎn)要介紹，分析了圖書(shū)管理信息系統設計的特點(diǎn)和任務(wù)。
第二章介紹了數據庫的設計和范式分析，并系統介紹了SQL語(yǔ)言，為設計和理解應用程序做了鋪墊。
第三章對系統介紹了Delphi 6.0的數據庫編程技術(shù)、SQL語(yǔ)言在Delphi 6.0中的應用、MS SQL Server基礎。
第四章分析了圖書(shū)管理系統的應用需求，設計了系統的數據庫結構，并根據需求對系統功能進(jìn)行了劃分和細化。
第五章根據第四章的設計結果利用MSSQL Server2000和Delphi 6.0進(jìn)行了具體的應用程序設計。
總結部分介紹了設計體會(huì )和編程體會(huì )，并指出了系統設計中的不足和改進(jìn)的方向。
 
第二章   數據庫理論基礎
一個(gè)成功的信息管理系統，是建立在許多條件之上的，而數據庫是其中一個(gè)非常重要的條件和關(guān)鍵技術(shù)。
信息管理系統所涉及的數據庫設計分五個(gè)步驟：數據庫需求分析、概念設計、邏輯設計、物理設計與加載測試。
（1） 數據庫需求分析的任務(wù)是將業(yè)務(wù)管理單證流化為數據流，劃分主題之間的邊界，繪制出DFD圖，并完成相應的數據字典。
（2） 概念設計的任務(wù)是從DFD出發(fā)，繪制出本主題的實(shí)體－關(guān)系圖，并列出各個(gè)實(shí)體與關(guān)系的綱要表。
（3） 邏輯設計的任務(wù)是從E-R圖與對應的綱要表出發(fā)，確定各個(gè)實(shí)體及關(guān)系的表名屬性。
（4） 物理設計的任務(wù)是確定所有屬性的類(lèi)型、寬度與取值范圍，設計出基本表的主鍵，將所有的表名與字段名英文化（現在很多軟件能支持中文字段，如MS SQL Server，我就是用的中文字段名），實(shí)現物理建庫，完成數據庫物理設計字典。
（5） 加載測試工作貫穿于程序測試工作的全過(guò)程，整個(gè)錄入、修改、查詢(xún)、處理工作均可視為對數據庫的加載測試工作。
要設計出一個(gè)好的信息管理系統數據庫，除滿(mǎn)足系統所要求的功能外，還必須遵守下列原則：
² 基本表的個(gè)數越少越好。
² 主鍵的個(gè)數越少越好。鍵是表間連接的工具，主鍵越少，表間的連接就越簡(jiǎn)單。
² 字段的個(gè)數越少越好。
² 所有基本表的設計均應盡量符合第三范式。
數據庫的設計中，如何處理多對多的關(guān)系和如何設計主鍵，是兩個(gè)有著(zhù)較大難度、需要重點(diǎn)考慮的問(wèn)題。下面我們著(zhù)重從SQL應用、數據庫設計范式和查詢(xún)優(yōu)化等方面來(lái)分析本課題的系統關(guān)鍵技術(shù)和實(shí)現難點(diǎn)并加以解決。

§2.1  數據庫系統設計及范式分析
信息系統的主要任務(wù)是通過(guò)大量的數據獲得管理所需要的信息，這就必須存儲和管理大量的數據。因此建立一個(gè)良好的數據組織結構和數據庫，使整個(gè)系統都可以迅速、方便、準確地調用和管理所需的數據，是衡量信息系統開(kāi)發(fā)工作好壞的主要指標之一。
2.1.1 數據庫系統設計
數據庫設計主要是進(jìn)行數據庫的邏輯設計，即將數據按一定的分類(lèi)、分組系統和邏輯層次組織起來(lái)，是面向用戶(hù)的。數據庫設計時(shí)需要綜合企業(yè)各個(gè)部門(mén)的存檔數據和數據需求，分析各個(gè)數據之間的關(guān)系，按照DBMS提供的功能和描述工具，設計出規模適當、正確反映數據關(guān)系、數據冗余少、存取效率高、能滿(mǎn)足多種查詢(xún)要求的數據模型。
數據庫設計的步驟是：
（1） 數據庫結構定義：目前的數據庫管理系統（DBMS）有的是支持聯(lián)機事務(wù)處理CLTP（負責對事務(wù)數據進(jìn)行采集、處理、存儲）的操作型DBMS，有的可支持數據倉庫、有聯(lián)機分析處理CLAP（指為支持決策的制定對數據的一種加工操作）功能的大型DBMS，有的數據庫是關(guān)系型的、有的可支持面向對象數據庫。針對選擇的DBMS，進(jìn)行數據庫結構定義。
（2） 數據表定義：數據表定義指定義數據庫中數據表的結構，數據表的邏輯結構包括：屬性名稱(chēng)、類(lèi)型、表示形式、缺省值、校驗規則、是否關(guān)鍵字、可否為空等。關(guān)系型數據庫要盡量按關(guān)系規范化要求進(jìn)行數據庫設計，但為使效率高，規范化程度應根據應用環(huán)境和條件來(lái)決定。數據表設計不僅要滿(mǎn)足數據存儲的要求，還要增加一些如反映有關(guān)信息、操作責任、中間數據的字段或臨時(shí)數據表。
（3） 存儲設備和存儲空間組織：確定數據的存放地點(diǎn)、存儲路徑、存儲設備等，備份方案，對多版本如何保證一致性和數據的完整性。
（4） 數據使用權限設置：針對用戶(hù)的不同使用要求，確定數據的用戶(hù)使用權限，確保數據安全。
（5） 數據字典設計：用數據字典描述數據庫的設計，便于維護和修改。
為了更好地組織數據和設計出實(shí)際應用數據庫，應該注意如下問(wèn)題：
規范化地重組數據結構：對數據進(jìn)行規范化表達，這在后面將會(huì )具體討論。
關(guān)系數據結構的建立：在進(jìn)行了數據基本結構的規范化重組后，還必須建立整體數據的關(guān)系結構。這一步設計完成后數據庫和數據結構設計工作基本完成，只待系統實(shí)現時(shí)將數據分析和數據字典的內容代入到所設計的數據整體關(guān)系結構中，一個(gè)規范化數據庫系統結構就建立起來(lái)了。
建立關(guān)系數據結構涉及三方面內容：確定關(guān)聯(lián)的關(guān)鍵指標項并建立關(guān)聯(lián)表；確定單一的父系記錄結構；建立整個(gè)數據庫的關(guān)系結構。
（1）鏈接關(guān)系的確定
在進(jìn)行了上述數據規范化重組后，已經(jīng)可以確保每一個(gè)基本數據表(我們簡(jiǎn)稱(chēng)為表)是規范的，但是這些單獨的表并不能完整地反映事物，通常需要通過(guò)指標體系整體指標數據才能完整全面地反映問(wèn)題。也就是說(shuō)在這些基本表的各宇段中，所存儲的是同一事物不同側面的屬性。那么計算機系統如何能知道哪些表中的哪些記錄應與其它表中的哪些記錄相對應，它們表示的是同一個(gè)事物呢?這就需要在設計數據結構時(shí)將這種各表之間的數據記錄關(guān)系確定下來(lái)。這種表與表之間的數據關(guān)系一般都是通過(guò)主或輔關(guān)鍵詞之間的連接來(lái)實(shí)現的。因為在每個(gè)表中只有主關(guān)鍵詞才能唯一地標識表中的這一個(gè)記錄值(因為根據第三范式的要求，表中其它數據字段函數都依賴(lài)于主關(guān)鍵詞)，所以將表通過(guò)關(guān)鍵詞連接就能夠唯一地標識出某一事物不同屬性在不同表中的存放位置。
（2）確定單一的父子關(guān)系結構
所謂確定單一的父系關(guān)系結構就是要在所建立的各種表中消除多對多（以下用M:N來(lái)表示）的現象，即設法使得所有表中記錄之間的關(guān)系呈樹(shù)狀結構(只能由一個(gè)主干發(fā)出若干條分支，而不能有若干條主干交錯發(fā)出若干條分支狀況)。所謂的“父系”就是指表的上一級關(guān)系表。消除多對多關(guān)系可以借助于E-R圖的方法來(lái)解決，也可以在系統分析時(shí)予以注意，避免這種情況的發(fā)生。
消除這種M:N情況的辦法也很簡(jiǎn)單，只需在二表之間增加一個(gè)表，則原來(lái)M:N的關(guān)系就改成了M:1，1:N的關(guān)系了。
確定數據資源的安全保密屬性：
一般DBMS都提供給我們自己定義數據安全保密性的功能。系統所提供的安全保密功能一般有8個(gè)等級(0-7級)，4種不同方式(只讀、只寫(xiě)、刪除、修改)，而且允許用戶(hù)利用這8個(gè)等級的4種方式對每一個(gè)表自由地進(jìn)行定義。
定義安全保密性的方法一般有如下幾種：
a．原則上所有文件都定義為4級，個(gè)別優(yōu)先級特別高的辦公室(終端或微機的入網(wǎng)賬號)可定義高于4級的級別，反之則定義為低于4的級別。
b．統計文件(表)和數據錄入文件一般只對本工作站定義為只寫(xiě)方式，對其它工作站則定義為只讀方式。
c．財務(wù)等保密文件一般只對中工作站(如財務(wù)科等)定義為可寫(xiě)、可改、可刪除方式，對其它工作站則定義為只讀方式，而且不是每個(gè)人都能讀，只有級別相同和高級別者才能讀。
2.1.2  數據庫設計范式分析
建立起一個(gè)良好的數據指標體系，是建立數據結構和數據庫的最重要的一環(huán)。一個(gè)良好的數據指標體系是建立DB的必要條件，但不是充分條件。我們完全可以認為所建指標體系中的一個(gè)指標類(lèi)就是關(guān)系數據庫中的一個(gè)基本表，而這個(gè)指標類(lèi)下面的一個(gè)個(gè)具體指標就是這個(gè)基本表中的一個(gè)字段。但如果直接按照這種方式建庫顯然還不能算最佳。對于指標體系中數據的結構在建庫前還必須進(jìn)行規范化的重新組織。
a.  數據組織的規范化形式
在數據的規范化表達中，一般將一組相互關(guān)聯(lián)的數據稱(chēng)為一個(gè)關(guān)系(relation)，而在這個(gè)關(guān)系下的每個(gè)數據指標項則被稱(chēng)為數據元素(data element)，這種關(guān)系落實(shí)到具體數據庫上就是基本表，而數據元素就是基本表中的一個(gè)字段(field)。規范化表達還規定在每一個(gè)基本表中必須定義一個(gè)數據元素為關(guān)鍵字(key)，它可以唯一地標識出該表中其它相關(guān)的數據元素。在規范化理論中表是二維的，它有如下四個(gè)性質(zhì)：
l 在表中的任意一列上，數據項應屬于同一個(gè)屬性(如圖中每一列都存放著(zhù)不同合同記錄的同一屬性數據)。
l 表中所有行都是不相同的，不允許有重復組項出現(如圖中每一行都是一個(gè)不同的合同記錄)。
l 在表中，行的順序無(wú)關(guān)緊要(如圖中每行存的都是合同記錄，至于先放哪一個(gè)合同都沒(méi)關(guān)系)。
l 在表中，列的順序無(wú)關(guān)緊要，但不能重復(如圖中合同號和合同名誰(shuí)先誰(shuí)后都沒(méi)關(guān)系，但二者不可重復或同名)。
在對表的形式進(jìn)行了規范化定義后，數據結構還有五種規范化定義，定名為規范化模式，稱(chēng)為范式。在這五種范式中，一般只用前三種，對于常用系統就足夠了。而且這五種范式是“向上兼容”的，即滿(mǎn)足第五范式的數據結構自動(dòng)滿(mǎn)足一、二、三、四范式，滿(mǎn)足第四范式的數據結構自動(dòng)滿(mǎn)足第一、二、三范式，……，依此類(lèi)推。
第一范式(first normal form，簡(jiǎn)稱(chēng)1st NF)就是指在同一表中沒(méi)有重復項出現，如果有則應將重復項去掉。這個(gè)去掉重復項的過(guò)程就稱(chēng)之為規范化處理。在本文所討論的開(kāi)發(fā)方法里，1st NF實(shí)際上是沒(méi)有什么意義的。因為我們按規范化建立的指標體系和表的過(guò)程都自動(dòng)保證了所有表都滿(mǎn)足1st NF。
第二范式(second normal form，簡(jiǎn)稱(chēng) 2nd NF)是指每個(gè)表必須有一個(gè)(而且僅一個(gè))數據元素為主關(guān)鍵字(primary key)，其它數據元素與主關(guān)鍵字一一對應。例如，在圖l9.7中如果我們將合同號定義為主關(guān)鍵字(其它數據元素中的記錄數據都有可能重名，故不能作為主關(guān)鍵字)，故只要知道了一個(gè)合同記錄的合同號，就可以唯一地在同一行中找到該合同的任何一項具體信息。通常我們稱(chēng)這種關(guān)系為函數依賴(lài)(functional depEndence)關(guān)系。即表中其它數據元素都依賴(lài)于主關(guān)鍵字，或稱(chēng)該數據元素唯一地被主關(guān)鍵字所標識。
第三范式(third normal form，簡(jiǎn)稱(chēng) 3rd NF)就是指表中的所有數據元素不但要能夠唯一地被主關(guān)鍵字所標識，而且它們之間還必須相互獨立，不存在其它的函數關(guān)系。也就是說(shuō)對于一個(gè)滿(mǎn)足了 2nd NF的數據結構來(lái)說(shuō)，表中有可能存在某些數據元素依賴(lài)于其它非關(guān)鍵宇數據元素的現象，必須加以消除。
為防止數據庫出現更新異常、插入異常、刪除異常、數據冗余太大等現象，關(guān)系型數據庫要盡量按關(guān)系規范化要求進(jìn)行數據庫設計。
§2.2  SQL語(yǔ)言介紹
2.2.1  SQL基礎
SQL(Structured Query Language，結構查詢(xún)語(yǔ)言)是一個(gè)功能強大的數據庫語(yǔ)言。SQL通常使用于數據庫的通訊。ANSI（美國國家標準學(xué)會(huì )）聲稱(chēng)，SQL是關(guān)系數據庫管理系統的標準語(yǔ)言。SQL語(yǔ)句通常用于完成一些數據庫的操作任務(wù)，比如在數據庫中更新數據，或者從數據庫中檢索數據。使用SQL的常見(jiàn)關(guān)系數據庫管理系統有：Oracle、 Sybase、 Microsoft SQL Server、 Access、 Ingres等等。雖然絕大多數的數據庫系統使用SQL，但是它們同樣有它們自立另外的專(zhuān)有擴展功能用于它們的系統。但是，標準的SQL命令，比如"Select"、 "Insert"、 "Update"、 "Delete"、 "Create"和 "Drop"常常被用于完成絕大多數數據庫的操作。MS SQL Server 就是用的Transact- SQL。
SQL語(yǔ)言有著(zhù)非常突出的優(yōu)點(diǎn)，主要是：
n 非過(guò)程化語(yǔ)言
n 統一的語(yǔ)言
n 是所有關(guān)系數據庫的公共語(yǔ)言
非過(guò)程化語(yǔ)言：SQL是一個(gè)非過(guò)程化的語(yǔ)言，因為它一次處理一個(gè)記錄，對數據提供自動(dòng)導航。SQL允許用戶(hù)在高層的數據結構上工作，而不對單個(gè)記錄進(jìn)行操作，可操作記錄集，所有SQL 語(yǔ)句接受集合作為輸入，返回集合作為輸出。SQL的集合特性允許一條SQL語(yǔ)句的結果作為另一條SQL語(yǔ)句的輸入。
SQL不要求用戶(hù)指定對數據的存放方法， 這種特性使用戶(hù)更易集中精力于要得到的結果；所有SQL語(yǔ)句使用查詢(xún)優(yōu)化器，它是RDBMS的一部分，由它決定對指定數據存取的最快速度的手段，查詢(xún)優(yōu)化器知道存在什么索引，在哪兒使用索引合適，而用戶(hù)則從不需要知道表是否有索引、有什么類(lèi)型的索引。
統一的語(yǔ)言：SQL可用于所有用戶(hù)的DB活動(dòng)模型，包括系統管理員、數據庫管理員、應用程序員、決策支持系統人員及許多其它類(lèi)型的終端用戶(hù)。
SQL為許多任務(wù)提供了命令，其中包括：
n 查詢(xún)數據
n 在表中插入、修改和刪除記錄
n 建立、修改和刪除數據對象
n 控制對數據和數據對象的存取
n 保證數據庫一致性和完整性
以前的數據庫管理系統為上述各類(lèi)操作提供單獨的語(yǔ)言，而SQL 將全部任務(wù)統一在一種語(yǔ)言中。
所有關(guān)系數據庫的公共語(yǔ)言：由于所有主要的關(guān)系數據庫管理系統都支持SQL語(yǔ)言，用戶(hù)可將使用SQL的技能從一個(gè)RDBMS(關(guān)系數據庫管理系統)轉到另一個(gè)，所有用SQL編寫(xiě)的程序都是可以移植的。
2.2.2  SQL語(yǔ)句
SQL功能強大，是一種完備的數據處理語(yǔ)言，不僅用于數據庫查詢(xún)，而且用于數據庫中的數據修改和更新，概括起來(lái)，它可以分成以下幾組：
DML（Data Manipulation Language，數據操作語(yǔ)言）：用于檢索或者修改數據；
DDL（Data Definition Language，數據定義語(yǔ)言）： 用于定義數據的結構，比如創(chuàng )建、修改或者刪除數據庫對象；
DCL（Data Control Language，數據控制語(yǔ)言）：用于定義數據庫用戶(hù)的權限。
DML組可以細分為以下的幾個(gè)語(yǔ)句：
SELECT：用于檢索數據；
INSERT：用于增加數據到數據庫；
UPDATE：用于從數據庫中修改現存的數據；
DELETE：用于從數據庫中刪除數據。
DDL語(yǔ)句可以用于創(chuàng )建用戶(hù)和重建數據庫對象。下面是DDL命令：
CREATE TABLE，ALTER TABLE，DROP TABLE，CREATE INDEX，DROP INDEX
下面是一個(gè)簡(jiǎn)單SQL語(yǔ)句的例子：
我們使用SQL語(yǔ)句來(lái)從Book中檢索‘借書(shū)證號’為‘000001’的借閱者姓名：
SELECT 姓名  FROM  Book   WHERE 借書(shū)證號 = ‘000001’
2.2.2.1 DDL與DML
數據定義語(yǔ)言DDL：它是用來(lái)創(chuàng )建和修改數據庫結構的一種語(yǔ)句，包括 Create、Alter和Drop 語(yǔ)句。
數據操作語(yǔ)言DML：包括數據查詢(xún)與數據更新。數據查詢(xún)主要是由Select語(yǔ)句完成，這一點(diǎn)不再贅述。而數據更新所造成的風(fēng)險大大超過(guò)數據查詢(xún)。數據庫管理系統必須在更改期內保護所存儲的數據的一致性，確保有效的數據進(jìn)入數據庫，數據庫必須保持一致性，DBMS還必須協(xié)調多用戶(hù)的并行更新，以確保用戶(hù)和它們的更改不至于影響其它用戶(hù)的作業(yè)。
用于修改數據庫內容的 SQL 語(yǔ)句主要有以下三個(gè)：
(1)  Insert，向一個(gè)表中加入新的數據行
(2)  Delete，從一個(gè)表中刪除數據行
(3)  Update，更改數據庫中已經(jīng)存在的數據
Insert標準語(yǔ)法：
INSERT INTO  table_name (col1, col2...)  VALUES(value1, value2...)
下例要將借書(shū)證號為‘000001’作為一個(gè)新的借書(shū)情況加入借書(shū)情況表OWNER中
 Insert Into
 owner (借書(shū)證號，圖書(shū)編號，借書(shū)日期)
  values (‘000001’，‘00000001’，‘2002-9-12’)
Insert 語(yǔ)句還可以將多行數據添加到目標表中去，在這種形式的 Insert 語(yǔ)句中，新行的數據值不是在語(yǔ)句正文中明確地指定的，而是語(yǔ)句中指定的一個(gè)數據庫查詢(xún)。添加的值來(lái)自數據庫自身的行，在某些特定的狀態(tài)下，這是非常有用的。多行 Insert 語(yǔ)句為拷貝數據提供了一種緊湊而高效的方法，但我在自已做的圖書(shū)管理系統中沒(méi)有使用這種方法，我在系統中是使用循環(huán)依照上面的用法來(lái)完成多個(gè)記錄的插入。
Update語(yǔ)句用于更新單表中選定行的一列或多列的值。要更新的目標表在語(yǔ)句中定義，Set子句則指定要更新哪些列并計算它們的值。Update語(yǔ)句總是包含Where語(yǔ)句，而且Update語(yǔ)句比較危險，所以您必須明確地認識到Where語(yǔ)句的重要性，Where語(yǔ)句被用來(lái)指定需要更新的行。
標準語(yǔ)法：
UPDATE table_name
SET columnname1 = value1
[, columname2 = value2]...
WHERE search_condition
Delete 語(yǔ)句標準語(yǔ)法：
DELETE FROM  tablename   WHERE  condition
2.2.2.2 復雜操作實(shí)現
在信息管理系統中，我們往往會(huì )遇到歸類(lèi)、匯總、映射、索引、子查詢(xún)等復雜操作，相應的支持與實(shí)現如下：
u GROUP BY方法
GROUP BY子句語(yǔ)法為：
SELECT column1, SUM(column2)
FROM "list-of-tables"
GROUP BY "column-list";
這個(gè)GROUP BY子句將集中所有的行在一起，它包含了指定列的數據以及允許合計函數來(lái)計算一個(gè)或者多個(gè)列。
在本人的系統中在顯示數據時(shí)用到了此語(yǔ)句來(lái)對查詢(xún)所得的內容排序然后再顯示。
u 組合條件和布爾運算符
以下的SQL語(yǔ)句中就含有組合條件：
SELECT column1, SUM(column2)
FROM "list-of-tables"
WHERE "condition1" AND "condition2";
下面是一個(gè)示例：
SELECT 身份描述
FROM ID,user
WHERE ID.身份編號=USER.身份編號 and user.借書(shū)證號=’000001’;
這條SQL語(yǔ)句是從user、id表中查找借閱證號為000001的借閱者的身份描述，第三條語(yǔ)句中如果其中有一個(gè)條件為假，那么就什么都沒(méi)有顯示。
u UNION子句
有些時(shí)候，需要一起瀏覽多個(gè)查詢(xún)的結果、組合它們的輸出，我們可以使用UNION關(guān)鍵字。
 
第三章  應用系統開(kāi)發(fā)工具
§3.1  Delphi6.0　VCL組件的體系結構
Delphi類(lèi)可以粗略地分成兩部分：一部分是組件類(lèi)，這些組件類(lèi)通常以某種方式出現在組件面板上，當用戶(hù)從組件面板上點(diǎn)取一個(gè)類(lèi)的圖標后，在程序中就自動(dòng)生成了該類(lèi)的對象（非可視組件除外）；另一部分是功能類(lèi)，這此功能類(lèi)的對象通常出現在程序代碼中，起著(zhù)不可代替的作用，但是這些功能類(lèi)在組件面板上是找不到的。在Delphi中，每一個(gè)類(lèi)的祖先都是Tobject類(lèi),整個(gè)類(lèi)的層次結構就像一棵倒掛的樹(shù)，在最頂層的樹(shù)根即為Tobject類(lèi)。這樣，按照面向對象編程的基本思想，就使得用戶(hù)可用Tobject類(lèi)這個(gè)類(lèi)型代替任何其它類(lèi)的數據類(lèi)型。實(shí)際上在Delphi的類(lèi)庫中，Tobject類(lèi)派生出了為數相當眾多的子類(lèi)，它們形成了一個(gè)龐大的體系，通常情況下，如果不自行開(kāi)發(fā)組件，就不必了解整個(gè)類(lèi)的體系結構，只用到類(lèi)層次樹(shù)的葉結點(diǎn)就足夠了。
這一小節簡(jiǎn)略介紹一下Delphi 6.0中VCL（可視化組件庫）組件的體系結構。凡是做過(guò)程序開(kāi)發(fā)的人都知道從來(lái)沒(méi)有單純的數據應用程序，也就是說(shuō)，數據庫應用程序必須和用戶(hù)界面（可以是圖形界面，也可以是命令接口）元素相結合，只講界面或只講數據庫本身都構不成數據庫應用程序，因而用Delphi 6.0開(kāi)發(fā)數據庫應用程序就隱含著(zhù)界面開(kāi)發(fā)。Delphi6中的VCL組件可用圖3-1來(lái)說(shuō)明。

組件在Delphi程序的開(kāi)發(fā)中是最顯眼的角色。大家知道，在編寫(xiě)程序時(shí)一般都開(kāi)始于在組件面板上選擇組件并定義組件間的相互作用。但也有一些組件不在組件面板上，例如Tform和Tapplication（典型的非可視組件）。組件是Tcomponents派生出來(lái)的子類(lèi)，可以流的形式存放在DFM文件中，具有事件和Publish屬性。
窗口組件類(lèi)是窗口化的可視化組件類(lèi)，在Delphi的類(lèi)庫中占有最大的份額。在實(shí)際編程中，窗口組件類(lèi)的對象都有句柄，可以接受輸入焦點(diǎn)和包含其它組件。
圖形組件與窗口組件并列，是另一大類(lèi)組件。圖形組件不是基于窗口的，因而不能有窗口句柄，不能接受輸入焦點(diǎn)和包含其它組件。從圖8-43中可以看出，圖形組件的基類(lèi)是TgraphicControl,在實(shí)際編程中，它們必須寄生于它們的宿主——窗口組件類(lèi)的對象，由它們的擁有者負責其顯示，而且它們還能觸發(fā)一些和鼠標活動(dòng)相關(guān)的事件。圖形控件最典型的例子是Tlabel和TspeedButton。由此可以看出圖形組件的功能很弱，圖形組件的用處何在呢？其實(shí)使用圖形組件的最大好處在于節省資源，正是因為它們的功能較弱，所以使用的系統資源就要少。在一個(gè)應用程序中，如果能在不影響其功能的前提下合理大量地使用圖形組件，將會(huì )大減少程序對系統資源的消耗。
非可視組件是與可視組件相并列的另一類(lèi)組件，非可視組件在程序運行中是不可見(jiàn)的（除各種對話(huà)框組件之外，事實(shí)上有人認為對話(huà)框組件不能歸入非可視組件，應該是另一種介于可視與非可視之間的組件）。
最后要說(shuō)明一下，常說(shuō)的控件實(shí)際上是一種組件。也就是說(shuō)組件這個(gè)概念要大于控件，控件在內涵上包含于組件中�？丶�由Windows系列操作系統提出并使用，而組件是Borland和其它廠(chǎng)商在對Windows控件做了必要的擴展之后提出來(lái)的概念，它們是在不同時(shí)期由不同的廠(chǎng)商提出的概念。
§3.2  數據庫組件介紹

用Delphi6開(kāi)發(fā)數據庫應用，重點(diǎn)是和各種數據庫組件打交道，能和數據庫掛鉤的組件對象有5種，它們是：Session（數據庫會(huì )話(huà)）、Database（數據庫）、Dataset（數據集）、DataSource（數據源）、Data control（數據控制組件，也叫data-controls即數據感知組件）。其中前面4種統稱(chēng)為數據訪(fǎng)問(wèn)（Data Access）組件。這些組件的相互關(guān)系如圖3-2所示。
ADO組件  Delphi6.0包含了可以用來(lái)訪(fǎng)問(wèn)Microsoft公司的ActiveX Data Objects（ADO）格式數據庫的組件。ADO是Micrsoft公司關(guān)于各種類(lèi)型數據的高等界面，后來(lái)逐漸演變成滿(mǎn)足所有數據訪(fǎng)問(wèn)需要的完整解決辦法。ADO的對象模型是所有數據訪(fǎng)問(wèn)接口對象模型中最簡(jiǎn)單的一種。Microsoft公司用來(lái)訪(fǎng)問(wèn)ADO數據的應用程序界面技術(shù)是OLE DB。OLE DB是一種底層編程接口，用來(lái)訪(fǎng)問(wèn)許多不同類(lèi)型的數據源，其中包括消息、文件系統以及其他一些非傳統的數據源。OLE DB是一個(gè)由Component Object Model（COM）接口組成的集合，用來(lái)隱藏創(chuàng )建數據訪(fǎng)問(wèn)服務(wù)過(guò)程中的細節。OLEDB提供了訪(fǎng)問(wèn)任何數據資源的方法，包括相互關(guān)聯(lián)的數據庫和相互不關(guān)聯(lián)的數據庫、Email和文件系統、文本和圖形以及用戶(hù)定義的數據對象。
Delphi的ADO組件無(wú)需依靠BDE而是使用ADO技術(shù)，提供了可以通過(guò)數據控制組件訪(fǎng)問(wèn)數據的新方法。唯一的要求是在使用ADO組件時(shí)必須運行ADO/OLE－DB。ADO組件的使用使得DELPHI在訪(fǎng)問(wèn)數據的類(lèi)型和采用的技術(shù)方面都有了很大的突破。
數據模塊設計窗口  數據模塊設計窗口是用來(lái)設計和維護數據模塊的。數據模塊設計窗口中包含了所有以.DTI作為文件擴展名的Data Diagram文件的信息。DTI文件在編譯時(shí)不起任何作用。
§3.3  SQL語(yǔ)言在Delphi中的應用
在Delphi中使用SQL語(yǔ)言非常方便，一般來(lái)說(shuō)，都是通過(guò)Tquery或TADOquery組件來(lái)使用SQL語(yǔ)言的�？梢栽�Tquery或TADOquery組件的SQL屬性中設置SQL語(yǔ)句。設計程序時(shí)，在該組件的屬性對話(huà)框中選擇SQL屬性，單擊帶省略號的按鈕，就可以打開(kāi)String List Editor對話(huà)框，然后我們就可以在對話(huà)框中添加SQL語(yǔ)句。還可以使用Delphi的SQL Builder來(lái)自動(dòng)生成SQL語(yǔ)句，這樣可以避免手工編寫(xiě)SQL而可能造成的語(yǔ)法錯誤。
靜態(tài)SQL語(yǔ)句在程序設計時(shí)便已固定下來(lái)，它不包含任何參數和變量。
動(dòng)態(tài)SQL語(yǔ)句，也被稱(chēng)作參數化的語(yǔ)句，在其中間包含著(zhù)表示字段名或表名的參數，例如下面的語(yǔ)句是一條動(dòng)態(tài)SQL語(yǔ)句：
Select  *  From  Book  Where 圖書(shū)編號 =:bookCode;　
其中的變量bookCode便是一個(gè)參數變量，它由一個(gè)冒號引導，在程序運行過(guò)程中，必須要為該參數賦值，該條SQL語(yǔ)句才能正確執行，每次運行應用程序時(shí)可以為該參數變量賦予不同的值。為參數賦值有三種方法：
①根據參數在SQL語(yǔ)句中出現的順序，設置TADOQuery組件的parameters屬性值為參數賦值。
②直接根據SQL語(yǔ)句中各參數的名字，調用ParamByName方法來(lái)為各參數賦值。
③將TADOQuery組件的DataSource屬性設置為另一個(gè)數據源，這樣將另一個(gè)數據源中與當前TADOQuery組件的SQL語(yǔ)句中的參數名相匹配的字段值賦給其對應的參數。利用這種方法也能實(shí)現所謂的連接查詢(xún)，創(chuàng )建主要—明細型數據庫應用。
在使用動(dòng)態(tài)SQL語(yǔ)句編程時(shí)，常常用到一個(gè)很重要的方法Prepare，調用Prepare 方法之后，Delphi會(huì )將帶參數的SQL語(yǔ)句傳送給與其對應的數據庫引擎，對動(dòng)態(tài)SQL語(yǔ)句進(jìn)行語(yǔ)法分析和優(yōu)化。雖然在用動(dòng)態(tài)SQL語(yǔ)句編程時(shí)，調用Prepare方法并不是必須的，但是調用Prepare方法后，會(huì )極大地提高動(dòng)態(tài)SQL 語(yǔ)句的執行性能，特別是當要反復多次執行同一條動(dòng)態(tài)SQL語(yǔ)句時(shí)，其優(yōu)越性會(huì )更加明顯。 如果在應用程序中執行一條SQL語(yǔ)句之前并沒(méi)有顯式地調用Prepare方法，每次在執行SQL 語(yǔ)句時(shí)，Delphi會(huì )隱含地調用Prepare方法以準備這個(gè)查詢(xún)。
TadoQuery部件還有一個(gè)Prepare屬性，這是一個(gè)布爾型屬性，當其屬性值為True時(shí)， 表明該查詢(xún)已被準備好了( SQL 語(yǔ)句已被傳送到數據庫引擎中 ) ， 當我們使用參數編輯器Parameters Editor來(lái)為動(dòng)態(tài)SQL語(yǔ)句中的參數賦值時(shí)，當設置完相應的參數值并退出參數編輯器時(shí)，Delphi會(huì )隱含地調用Prepare方法以準備好查詢(xún)。
當SQL語(yǔ)句執行完之后，要想準備下一個(gè)查詢(xún)，首先必須調用Close方法，然后才能調用Prepare方法準備下一個(gè)查詢(xún)。一般來(lái)說(shuō)，在一個(gè)應用程序中應該調用一次Prepare方法，常常在窗體的OnCreate事件處理過(guò)程中調用Prepare方法， 然后用上述介紹的方法為參數賦值，最后調用Open方法或ExecSQL方法執行SQL語(yǔ)句，以完成查詢(xún)。
當然在調用Prepare方法準備好一個(gè)查詢(xún)時(shí)，會(huì )消耗一些數據庫資源， 因而每當一個(gè)查詢(xún)執行完畢之后，要養成調用UnPrepare方法以撤消查詢(xún)的好習慣。在運行程序過(guò)程中，通過(guò)程序改變TQuery或TADOquery部件的SQL屬性值時(shí)，Delphi會(huì )自動(dòng)地調用Close方法和UnPrepare 方法，以撤消查詢(xún)。
在程序運行過(guò)程中，要想設置Tquery或TADOquery部件的SQL屬性，必須首先調用Close方法，關(guān)閉TQuery或TADOquery部件，然后再調用Clear方法清除SQL屬性中現存的SQL命令語(yǔ)句，最后再調用Add方法為SQL屬性設置新的SQL命令語(yǔ)句。例如：　
datamodule4.adoquery2.close;
    datamodule4.adoquery2.sql.clear;
    datamodule4.adoquery2.sql.add('SELECT 借書(shū)證號,密碼 FROM [user] WHERE (借書(shū)證號 = :tt)');
    datamodule4.adoquery2.parameters[0].value:=username;
    datamodule4.adoquery2.open;　
在為TQuery或TADOquery部件設置SQL屬性時(shí)調用Close方法總是很安全的，如果TQuery或TADOquery部件已經(jīng)被關(guān)閉了，調用Close方法時(shí)不會(huì )產(chǎn)生任何影響。在應用程序中為SQL屬性設置新的SQL 命令語(yǔ)句時(shí)，必須要調用Clear方法以清除SQL屬性中現存的SQL命令語(yǔ)句，如果不調用Clear方法，便調用Add方法向SQL屬性中設置SQL命令語(yǔ)句，那么新設置的SQL命令語(yǔ)句會(huì )追加在現存SQL命令語(yǔ)句后面， 在程序運行時(shí)常常會(huì )出現出乎意料的查詢(xún)結果甚至程序無(wú)法運行下去。
在這里要特別注意的，一般情況下TQuery或TADOquery部件的SQL屬性只能包含一條完整的SQL語(yǔ)句，它不允許被設置成多條SQL語(yǔ)句。當然有些數據庫服務(wù)器也支持在TQuery或TADOquery部件的SQL屬性中設置多條SQL語(yǔ)句，只要數據庫服務(wù)器允許這樣，我們在編程時(shí)可以為 SQL 屬性設置多條SQL語(yǔ)句。
在為TQuery或TADOquery部件設置完SQL屬性的屬性值之后，也即編寫(xiě)好適當的SQL程序之后，可以有多種方式來(lái)執行SQL程序。
在設計過(guò)程中，設置完TQuery或TADOquery部件的SQL屬性之后將其Active屬性的值置為True， 這樣便可以執行SQL屬性中的SQL程序，如果應用中有與TQuery或TADOquery部件相連的數據瀏覽部件( 如TDDGrid TDBEdit等)那么在這些數據瀏覽部件中會(huì )顯示SQL程序的執行結果。
在應用程序運行過(guò)程中，通過(guò)程序調用TQuery或TADOquery組件的Open方法或ExecSQL 方法可以執行其SQL屬性中的SQL程序。Open方法和ExecSQL方法是不一樣的。Open方法只能用來(lái)執行SQL語(yǔ)言的查詢(xún)語(yǔ)句(Select命令)，并返回一個(gè)查詢(xún)結果集，而ExecSQL方法還可以用來(lái)執行其它常用的SQL語(yǔ)句(如INSERT, UPDATE, DELETE等命令)，例如：
Query1.Open (這樣會(huì )返回一個(gè)查詢(xún)結果集)
如果調用Open方法，而沒(méi)有查詢(xún)結果時(shí)，會(huì )出錯。此時(shí)應該調用ExecSQL 方法來(lái)代替Open方法。如：
Query1.ExecSQL (沒(méi)有返回結果)
當然在設計應用程序時(shí)，程序設計人員是無(wú)法確定TQuery或TADOquery組件中的SQL 語(yǔ)句是否會(huì )返回一個(gè)查詢(xún)結果的。對于這種情況應當用Try…Except模塊來(lái)設計程序。在 Try 部分調用Open方法，而在Except部分調用ExceSQL方法，這樣才能保證程序的正確運行。
例如：　
Try
Query1.Open
Except
Query1.ExecSQL
End
通過(guò)Tquery或TADOquery組件可以獲得兩種類(lèi)型的數據：
u “活動(dòng)”的數據
這種數據就跟通過(guò)TTable部件獲得的數據一樣，用戶(hù)可以通過(guò)數據瀏覽部件來(lái)編輯修改這些數據，并且當調用Post方法或當焦點(diǎn)離開(kāi)當前的數據瀏覽部件時(shí)，用戶(hù)對數據的修改自動(dòng)地被寫(xiě)回到數據庫中。
u 非活動(dòng)的數據(只讀數據)
用戶(hù)通過(guò)數據瀏覽部件是不能修改其中的數據。在缺省情況下，通過(guò)TQuery部件獲得的查詢(xún)結果數據是只讀數據，要想獲得“活動(dòng)”的數據，在應用程序中必須要設置Tquery或TADOquery組件的RequestLive屬性值為True，然而并不是在任何情況下(通過(guò)設置RequestLive的屬值True)都可以獲得“活動(dòng)”的數據的，要想獲得“活動(dòng)”的數據，除了將TQuery部件的RequestLive屬性設置為True外，相應的SQL命令還要滿(mǎn)足以下條件。
本地SQL語(yǔ)句查詢(xún)情況下，要得到可更新的數據集，SQL語(yǔ)句的限制為：
n 查詢(xún)只能涉及到一個(gè)單獨的表
n SQL語(yǔ)句中不能包含ORDER BY命令
n SQL語(yǔ)句中不能含聚集運算符SUM或AVG
n 在Select后的字段列表中不能有計算字段
n 在Select語(yǔ)句WHERE部分只能包含字段值與常量的比較運算，這些比較運算符是：Like, >, <, >=, <=。各比較運算之間可以有并和交運算：AND和OR
當通過(guò)SQL語(yǔ)句查詢(xún)數據庫服務(wù)器中的數據庫表：
n 查詢(xún)只能涉及到一個(gè)單獨的表
n SQL語(yǔ)句中不能包含ORDER BY命令
n SQL語(yǔ)句中不能含聚集運算符SUM或AVG運算
另外，如果是查詢(xún)Sybase數據庫中的表，那么被查詢(xún)的表中只能有一個(gè)索引。
如果在應用程序中要求TQuery或TADOquery組件返回一個(gè)“活動(dòng)”的查詢(xún)結果數據集，但是SQL 命令語(yǔ)句不滿(mǎn)足上述約束條件時(shí)，對于本地數據庫的SQL查詢(xún)，BDE只能返回只讀的數據集。對于數據庫服務(wù)器中的SQL查詢(xún)，只能返回錯誤的代碼。當Tquery或TADOquery組件返回一個(gè)“活動(dòng)”的查詢(xún)結果數據集時(shí)，它的CanModIfy屬性的值會(huì )被設置成True。
§3.4  MS SQL Server簡(jiǎn)述
SQL Server 是一個(gè)后臺數據庫管理系統,它功能強大操作簡(jiǎn)便,日益為廣大數據庫用戶(hù)所喜愛(ài)。越來(lái)越多的開(kāi)發(fā)工具提供了與SQL Server的接口。SQL Server 是一個(gè)關(guān)系數據庫管理系統，它最初是由Microsoft、Sybase 和Ashton-Tate三家公司共同開(kāi)發(fā)的。于1988 年推出了第一個(gè)OS/2 版本，在Windows NT 推出后，Microsoft與Sybase 在SQL Server 的開(kāi)發(fā)上就分道揚鑣了，Microsoft 將SQL Server 移植到Windows NT系統上，專(zhuān)注于開(kāi)發(fā)推廣SQL Server 的Windows NT 版本。
SQL Server 2000 是Microsoft 公司推出的SQL Server 數據庫管理系統的最新版本，該版本繼承了SQL Server 7.0 版本的優(yōu)點(diǎn)，同時(shí)又比它增加了許多更先進(jìn)的功能、具有使用方便、可伸縮性好與相關(guān)軟件集成程度高等優(yōu)點(diǎn)�？煽缭綇倪\行Microsoft Windows 98 的膝上型電腦到運行Microsoft Windows 2000 的大型多處理器的服務(wù)器等多種平臺使用。MSSQL Server不但可以應用于大中型數據庫管理中，建立分布式關(guān)系數據庫，并且也可以開(kāi)發(fā)桌面數據庫。事實(shí)上，SQL Server數據庫處理的基本結構，采取關(guān)系型數據庫模式，盡管如此，相信大家都可以輕易的發(fā)現，在SQL Server的數據庫處理方式，則是使用面向對象的操作方式與精神，也就是說(shuō)，SQL Server的所有功能，都可以基于系統已經(jīng)建立好的一些對象來(lái)達成，是相當OO（面向對象）的一個(gè)系統結構。
SQL Server 企業(yè)管理器是 SQL Server 的主要管理工具，它提供了一個(gè)遵從 MMC 標準的用戶(hù)界面，使用戶(hù)得以：
· 定義 SQL Server 實(shí)例組。
· 將個(gè)別服務(wù)器注冊到組中。
· 為每個(gè)已注冊的服務(wù)器配置所有 SQL Server 選項。
· 在每個(gè)已注冊的服務(wù)器中創(chuàng )建并管理所有 SQL Server 數據庫、對象、登錄、用戶(hù)和權限。
· 在每個(gè)已注冊的服務(wù)器上定義并執行所有 SQL Server 管理任務(wù)。
· 通過(guò)喚醒調用 SQL 查詢(xún)分析器，交互地設計并測試 SQL 語(yǔ)句、批處理和腳本。
· 喚醒調用為 SQL Server 定義的各種向導。
 
· 
第三章 圖書(shū)管理系統設計分析

§4.1  應用需求分析
圖書(shū)管理系統需要滿(mǎn)足來(lái)自三方面的需求，這三個(gè)方面分別是圖書(shū)借閱者、圖書(shū)館工作人員和圖書(shū)館管理人員。圖書(shū)借閱者的需求是查詢(xún)圖書(shū)館所存的圖書(shū)、個(gè)人借閱情況及個(gè)人信息的修改；圖書(shū)館工作人員對圖書(shū)借閱者的借閱及還書(shū)要求進(jìn)行操作，同時(shí)形成借書(shū)或還書(shū)報表給借閱者查看確認；圖書(shū)館管理人員的功能最為復雜，包括對工作人員、圖書(shū)借閱者、圖書(shū)進(jìn)行管理和維護，及系統狀態(tài)的查看、維護并生成催還圖書(shū)報表。
圖書(shū)借閱者可直接查看圖書(shū)館圖書(shū)情況，如果圖書(shū)借閱者根據本人借書(shū)證號和密碼登錄系統，還可以進(jìn)行本人借書(shū)情況的查詢(xún)和維護部分個(gè)人信息。一般情況下，圖書(shū)借閱者只應該查詢(xún)和維護本人的借書(shū)情況和個(gè)人信息，若查詢(xún)和維護其他借閱者的借書(shū)情況和個(gè)人信息，就要知道其他圖書(shū)借閱者的借書(shū)證號和密碼。這些是很難得到的，特別是密碼，所以不但滿(mǎn)足了圖書(shū)借閱者的要求，還保護了圖書(shū)借閱者的個(gè)人隱私。
圖書(shū)館工作人員有修改圖書(shū)借閱者借書(shū)和還書(shū)記錄的權限，所以需對工作人員登陸本模塊進(jìn)行更多的考慮。在此模塊中，圖書(shū)館工作人員可以為圖書(shū)借閱者加入借書(shū)記錄或是還書(shū)記錄，并打印生成相應的報表給用戶(hù)查看和確認。
圖書(shū)館管理人員功能的信息量大，數據安全性和保密性要求最高。本功能實(shí)現對圖書(shū)信息、借閱者信息、總體借閱情況信息的管理和統計、工作人員和管理人員信息查看及維護。圖書(shū)館管理員可以瀏覽、查詢(xún)、添加、刪除、修改、統計圖書(shū)的基本信息；瀏覽、查詢(xún)、統計、添加、刪除和修改圖書(shū)借閱者的基本信息，瀏覽、查詢(xún)、統計圖書(shū)館的借閱信息，但不能添加、刪除和修改借閱信息，這部分功能應該由圖書(shū)館工作人員執行，但是，刪除某條圖書(shū)借閱者基本信息記錄時(shí)，應實(shí)現對該圖書(shū)借閱者借閱記錄的級聯(lián)刪除。并且還應具有生成催還圖書(shū)報表，并打印輸出的功能。
在本系統中由于沒(méi)有打印機設備供試驗，所以預先把報表打印改成報表預覽。
設計不同用戶(hù)的操作權限和登陸方法
對所有用戶(hù)開(kāi)放的圖書(shū)查詢(xún)
借閱者維護借閱者個(gè)人部分信息
借閱者查看個(gè)人借閱情況信息
維護借閱者個(gè)人密碼
根據借閱情況對數據庫進(jìn)行操作并生成報表
根據還書(shū)情況對數據庫進(jìn)行操作并生成報表
查詢(xún)及統計各種信息
維護圖書(shū)信息
維護工作人員和管理員信息
維護借閱者信息
處理信息的完整性
對借閱過(guò)期的圖書(shū)生成報表
圖4-2  圖書(shū)管理系統數據庫應用需求的總結

根據以上所做的需求分析，并略掉一些細節（如不考慮用戶(hù)的登錄；對記錄的維護），得出以下的三層數據流圖。 
§4.2 系統功能模塊劃分
系統功能框圖如圖4-10所示。

§4.3  系統數據庫設計
4.3.1  概念設計
在概念設計階段中，設計人員從用戶(hù)的角度看待數據及處理要求和約束，產(chǎn)生一個(gè)反映用戶(hù)觀(guān)點(diǎn)的概念模式。然后再把概念模式轉換成邏輯模式。將概念設計從設計過(guò)程中獨立開(kāi)來(lái)，使各階段的任務(wù)相對單一化，設計復雜程度大大降低，不受特定DBMS的限制。
利用ER方法進(jìn)行數據庫的概念設計，可分成三步進(jìn)行：首先設計局部ER模式，然后把各局部ER模式綜合成一個(gè)全局模式，最后對全局ER模式進(jìn)行優(yōu)化，得到最終的模式，即概念模式。
（1） 設計局部ER模式
實(shí)體和屬性的定義：
圖書(shū)（圖書(shū)編號，圖書(shū)名稱(chēng)，作者，出版社，出版日期，備注，價(jià)格，數量，）
借閱者（借書(shū)證號，姓名，性別，身份證，聯(lián)系電話(huà)，密碼）
身份（身份編號，身份描述，最大借閱數）
圖書(shū)類(lèi)別（圖書(shū)類(lèi)別編號，類(lèi)別描述）

ER模型的“聯(lián)系”用于刻畫(huà)實(shí)體之間的關(guān)聯(lián)。一種完整的方式是對局部結構中任意兩個(gè)實(shí)體類(lèi)型，依據需求分析的結果，考察局部結構中任意兩個(gè)實(shí)體類(lèi)型之間是否存在聯(lián)系。若有聯(lián)系，進(jìn)一步確定是1:N，M:N，還是1:1等。還要考察一個(gè)實(shí)體類(lèi)型內部是否存在聯(lián)系，兩個(gè)實(shí)體類(lèi)型之間是否存在聯(lián)系，多個(gè)實(shí)體類(lèi)型之間是否存在聯(lián)系，等等。聯(lián)系定義如圖4-5所示。解釋如下：
u 一個(gè)借閱者（用戶(hù)）只能具有一種身份，而一種身份可被多個(gè)借閱者所具有；
u 一本圖書(shū)只能屬于一種圖書(shū)類(lèi)別（類(lèi)別），而一種圖書(shū)類(lèi)別可以包含　多本圖書(shū)；
u 一個(gè)用戶(hù)可以借閱多本不同的書(shū)，而一本書(shū)也可以被多個(gè)不同的用戶(hù)所借閱。
（2）設計全局ER模式
所有局部ER模式都設計好了后，接下來(lái)就是把它們綜合成單一的全局概念結構。全局概念結構不僅要支持所有局部ER模式，而且必須合理地表示一個(gè)完整、一致的數據庫概念結構。
1)確定公共實(shí)體類(lèi)型
為了給多個(gè)局部ER模式的合并提供開(kāi)始合并的基礎，首先要確定各局部結構中的公共實(shí)體類(lèi)型。在這一步中我們僅根據實(shí)體類(lèi)型名和鍵來(lái)認定公共實(shí)體類(lèi)型。一般把同名實(shí)體類(lèi)型作為公共實(shí)體類(lèi)型的一類(lèi)候選，把具有相同鍵的實(shí)體類(lèi)型作為公共實(shí)體類(lèi)型的另一類(lèi)候選。
2)局部ER模式的合并
合并的原則是：首先進(jìn)行兩兩合并；先和合并那些現實(shí)世界中有聯(lián)系的局部結構；合并從公共實(shí)體類(lèi)型開(kāi)始，最后再加入獨立的局部結構。
3)消除沖突
沖突分為三類(lèi)：屬性沖突、結構沖突、命名沖突。
設計全局ER模式的目的不在于把若干局部ER模式形式上合并為一個(gè)ER模式，而在于消除沖突，使之成為能夠被所有用戶(hù)共同理解和接受的同一的概念模型。
3)全局ER模式的優(yōu)化
在得到全局ER模式后，為了提高數據庫系統的效率，還應進(jìn)一步依據處理需求對ER模式進(jìn)行優(yōu)化。一個(gè)好的全局ER模式，除能準確、全面地反映用戶(hù)功能需求外，還應滿(mǎn)足下列條件：實(shí)體類(lèi)型的個(gè)數要盡可能的少；實(shí)體類(lèi)型所含屬性個(gè)數盡可能少；實(shí)體類(lèi)型間聯(lián)系無(wú)冗余。
綜上所述，“圖書(shū)管理系統”的全局ER模式如圖4-13所示。

4.3.2  關(guān)系數據庫的邏輯設計
由于概念設計的結果是ER圖，DBMS一般采用關(guān)系型（本人所使用的MS SQL Server就是關(guān)系型的DBMS），因此數據庫的邏輯設計過(guò)程就是把ER圖轉化為關(guān)系模式的過(guò)程。由于關(guān)系模型所具有的優(yōu)點(diǎn)，邏輯設計可以充分運用關(guān)系數據庫規范化理論，使設計過(guò)程形式化地進(jìn)行。設計結果是一組關(guān)系模式的定義。
（1） 導出初始關(guān)系模式
book（圖書(shū)編號＃，圖書(shū)名稱(chēng)，圖書(shū)類(lèi)別＃，作者，出版社，出版日期，備注，價(jià)格，數量）class（圖書(shū)類(lèi)別#，類(lèi)別名）user（借書(shū)證號＃，姓名，性別，身份編號＃，身份證，聯(lián)系電話(huà)，密碼）ID（身份編號#，身份描述，最大借閱數）Owner（借書(shū)證號#,圖書(shū)編號#，借書(shū)日期）
圖4-14  關(guān)系模式集
（2） 產(chǎn)生子模式
子模式是用戶(hù)所用到的那部分數據的描述。除了指出用戶(hù)用到的數據外，還應指出數據與概念模式中相應數據的聯(lián)系，即指出概念模式與子模式之間的對應性。
借書(shū)子模式（借書(shū)證號#，姓名，圖書(shū)編號＃，圖書(shū)名稱(chēng)，借書(shū)日期）
圖4-15  部分子模式
（3） 根據設計中出現的問(wèn)題本人在寫(xiě)系統時(shí)還加入了兩個(gè)關(guān)系模式：
1、 ownertemp：用于工作人員在處理借書(shū)、還書(shū)工作時(shí)臨時(shí)存儲借書(shū)、還書(shū)信息，以便打印報表時(shí)使用。
2、 keyer：用于存儲工作人員和圖書(shū)館管理員的用戶(hù)名和密碼及權限，以便工作人員或圖書(shū)館管理員進(jìn)入相應的功能模塊時(shí)進(jìn)行驗證用戶(hù)的身份。
4.3.3  數據庫的實(shí)現
我選用Microsoft SQL Server2000(企業(yè)版)數據庫來(lái)進(jìn)行數據庫的邏輯設計。首先創(chuàng )建七個(gè)基本數據庫表如表4-1－4-7所示，然后根據全局ER圖，建立各個(gè)表之間的聯(lián)系，如圖4-8所示。
表4-1  借閱者基本信息表的結構(User)
 

表4-2 圖書(shū)信息表的結構（Book）
 
表4-3 圖書(shū)類(lèi)別信息表的結構（Class）
 
表4-4 借閱者身份信息表的結構（ID）
 
表4-5 借閱情況信息表的結構（Owner）
 
表4-6 借閱情況臨時(shí)存儲信息表的結構（Ownertemp）
 
注：在owner表和ownertemp表中加入了索引字段，用來(lái)唯一標識一條借書(shū)記錄，并且設置為標識，標識種子為1。
表4-7 工作人員和管理員信息表的結構（Keyer）
 

圖4-8  數據庫表間聯(lián)系圖
 
 
第五章   圖書(shū)管理系統應用程序設計
§5.1  系統窗體模塊組成

§5.2  數據模塊窗體的設置
在編寫(xiě)數據庫應用程序時(shí)，經(jīng)常要遇到這樣的情況，即好多組件、窗體同時(shí)訪(fǎng)問(wèn)相同的數據源，如果為每一個(gè)組件或者窗體都設置一個(gè)數據源將是十分耗時(shí)的工件，而且要保證這些數據源的確是相同的也需花一番功夫。那么，能不能將這些數據源集中管理，最好是做成一個(gè)統一的模塊，需要時(shí)就將該模塊引入而不必直接操作數據源本身呢？數據模塊（DataModule）是解決這個(gè)問(wèn)題最好的答案。簡(jiǎn)單說(shuō)來(lái)，數據模塊是用來(lái)集中管理數據源的一個(gè)窗體，該窗體可被需要的地方隨時(shí)引入。
但本人在開(kāi)發(fā)這個(gè)系統時(shí)，開(kāi)始使用了一下數據模塊，但在使用過(guò)程中卻碰到了一些問(wèn)題。并且考慮這個(gè)系統使用到的TADOQuery控件比較多，如果使用數據控件可能會(huì )帶來(lái)管理上的麻煩，如弄混各個(gè)數據控件的作用。還考慮到使用動(dòng)態(tài)生成ADOQuery可能會(huì )更節省資源。所以在本人的系統中，開(kāi)始做的第一個(gè)模塊“借閱者個(gè)人模塊”中還稍微使用了一下數據模塊。但在后面做的兩個(gè)模塊中大多都是用動(dòng)態(tài)生成ADOQuery來(lái)實(shí)現的。并且由于SQL語(yǔ)句是動(dòng)態(tài)加入的所以datamodule中的控件也不會(huì )多。
 
§5.3  啟動(dòng)畫(huà)面的實(shí)現
啟動(dòng)畫(huà)面是為了給用戶(hù)一個(gè)良好的印像，加深軟件的親和力，沒(méi)有實(shí)際的功能，在Form1窗體中加入了Image和Time組件。啟動(dòng)畫(huà)面的窗體略，主要的源代碼如下：

 

§5.4  用戶(hù)登錄窗體的的實(shí)現
本窗體是為三種不同的用戶(hù)（一般用戶(hù)，工作人員，管理員）提供選擇以進(jìn)入不同的模塊，滿(mǎn)足不同用戶(hù)的需求。源代碼比較簡(jiǎn)單，略。
 
§5.5  用戶(hù)密碼認證窗體的的實(shí)現
本窗體是為了讓工作人員或圖書(shū)館管理員按照用戶(hù)名和密碼進(jìn)行登錄，并且跟據用戶(hù)名檢查Keyer表中的“權限”字段，以分辯進(jìn)入圖書(shū)館管理人員模塊還是進(jìn)入工作人員模塊。窗體界面、源代碼如下
 
§5.6  借閱者服務(wù)模塊的實(shí)現
借閱者服務(wù)窗體的功能主要是圖書(shū)的查詢(xún)，個(gè)人借閱情況查看及個(gè)人部分信息的修改。界面圖如下：
 
5.6.1圖書(shū)查詢(xún)功能的實(shí)現
在本系統中，任何人都有權限使用查詢(xún)功能，不做任何限制。界面如下，
 
 
由于實(shí)現的查詢(xún)功能有多種，如按圖書(shū)編號、圖書(shū)名稱(chēng)等字段進(jìn)行完全體配查找和部分體配的模糊查找，還有按多個(gè)條件進(jìn)行邏輯與或是邏輯或的多條件查找。其中實(shí)現的方法者差不多，所以只給出多條件查找的代碼，如下：

5.6.2借閱者登錄功能的實(shí)現
這個(gè)功能的實(shí)現與工作人員和管理人員登錄功能實(shí)現的方法大致一樣，并且還要簡(jiǎn)單。是從User表中查到到借閱證號與密碼，看與用戶(hù)輸入的是否一致。如果一致，那么用戶(hù)就可查看自已的借閱情況并維護自己的部分信息。源代碼與借閱者登錄界面都略。
5.6.3借閱者借閱情況功能的實(shí)現
當借閱者正確登錄到系統后，此功能將被激活，使用戶(hù)能查看到自身的借閱情況。在此系統中，信息的顯示一般用ListView來(lái)實(shí)現，只在較少的情況下用到了DBgrid，因為我覺(jué)得ListView更好實(shí)現，并能使信息數據對用戶(hù)的完全分離。
 
 
在這里跟據借閱者的不同要求實(shí)現借閱情況的查詢(xún)，有檢查所有的借閱情部、某本書(shū)的借閱情況、和根據已借閱天數的來(lái)查詢(xún)。其中根椐借閱天數來(lái)查詢(xún)更有代表性，有方式一和方式二。以下給出此功能的源代碼
按借閱天數查詢(xún)　方式一

按借閱天數查詢(xún)　方式二

5.6.4借閱者個(gè)人資料維護功能的實(shí)現
 
此功能實(shí)現當前借閱者部份資料的修改，但借書(shū)證號和身份類(lèi)別這樣的信息不允許修改，這是圖書(shū)館管理員模塊的功能。在此界面中點(diǎn)擊修改按鈕將出現“修改”窗體（Form8），點(diǎn)擊修改密碼按鈕將出現groupbox8，在這里進(jìn)行密碼修改。關(guān)鍵源代碼如下。
 
 
這里給出個(gè)人部分信息修改的源代碼：

這里給出密碼修改的源代碼：

5.7工作人員－圖書(shū)借閱/歸還模塊的實(shí)現
 

5.7.1工作人員進(jìn)行圖書(shū)借閱功能實(shí)現
 
在這個(gè)功能中，工作人員輸入借閱者的借閱證號和所要借閱的圖書(shū)的圖書(shū)編號，然后點(diǎn)擊借閱按鈕就可進(jìn)行圖書(shū)借閱�？紤]到實(shí)際中可能會(huì )出現只知圖書(shū)名而不知圖書(shū)編號的情況，在此界面下方加入了一個(gè)轉換功能，可以把圖書(shū)名稱(chēng)轉換成圖書(shū)編號，再進(jìn)行圖書(shū)借閱。

在借閱完成后會(huì )生借閱報表以便借閱者檢查和確認，借閱報表的打印效果如下圖，實(shí)現比較簡(jiǎn)單，略去實(shí)現過(guò)程。
 
5.7.2工作人員進(jìn)行圖書(shū)歸還功能實(shí)現
 
在此功能中，工作人員根據借閱者的借書(shū)證號和歸還的圖書(shū)編號進(jìn)行圖書(shū)的歸還工作。并且根據現實(shí)中可能會(huì )出現的只知圖書(shū)名不知圖書(shū)編號的歸還情況，所以加入了按書(shū)籍名稱(chēng)進(jìn)行歸還的功能。這個(gè)功能是圖書(shū)借閱功能中把圖書(shū)名稱(chēng)轉換成圖書(shū)編號的一種改進(jìn)方法，這樣就不用如借閱功能中一樣要先轉換再借閱了。歸還完成后，同樣會(huì )打印出歸還報表以便用戶(hù)檢查和確認。

5.8圖書(shū)館管理員模塊的實(shí)現

5.8.1圖書(shū)館管理員圖書(shū)管理功能的實(shí)現
 

在這個(gè)功能中可以在（＊圖書(shū)編號）中輸入圖書(shū)編號，點(diǎn)查找按鈕后就會(huì )在各個(gè)相應的組件中顯示出信息，或按圖書(shū)名稱(chēng)模糊查找到所要的記錄，在各個(gè)相應的組件中顯示第一條記錄的信息，也可在下端的ListView組件中點(diǎn)擊某一條記錄，在各個(gè)相應的組件中也會(huì )顯示所選記錄的信息。在入庫功能中只要不是相同的圖書(shū)編號并且帶＊號提示的字段不為空就可插入新的圖書(shū)記錄。刪除則刪除那些Book表中的圖書(shū)記錄，如果借出還可依用戶(hù)要求連帶刪除owner表中的記錄。因為圖書(shū)修改與圖書(shū)入庫的功能與工作人員記錄修改和工作人員記錄添加的實(shí)現過(guò)程一樣，所以下面僅給出刪除功能的源代碼，如下

5.8.2圖書(shū)館管理員工作人員和管理員管理功能的實(shí)現
在此功能中可以加入工作人員或是管理員，或是修改他們的密碼、權限。

在此功能中如果選中ListView中的記錄，則在右邊相應的組件中顯示出信息，并且管理員還可對這些記錄進(jìn)行修改或加入新的記錄。并且也可以點(diǎn)刪除按鈕刪除選中的一條或多條記錄。刪除功能與圖書(shū)記錄的刪除一般，所以下面只給出添加與修改的實(shí)現過(guò)程。

5.8.3圖書(shū)館管理員修改圖書(shū)類(lèi)別及統記功能的實(shí)現
 
在此窗體中能對圖書(shū)的類(lèi)別進(jìn)行刪除，添加和修改，這模塊的功能的實(shí)現過(guò)程與圖書(shū)記錄的刪除，添加和修改一樣的，但是這個(gè)窗體還能跟據圖書(shū)類(lèi)別進(jìn)行統計，還可根據Book表和owner表統計出圖書(shū)總數目，庫存圖書(shū)數目，借出圖書(shū)數目及借閱過(guò)期的圖書(shū)數目。在這里給出統計圖書(shū)總數目，庫存圖書(shū)數目，借出圖書(shū)數目及借閱過(guò)期的圖書(shū)數目的實(shí)現過(guò)程中的幾個(gè)函數和過(guò)程

5.8.4圖書(shū)館管理員借閱者管理功能的實(shí)現
 
查詢(xún)借閱者可根據借閱者的借書(shū)證號或姓名或身份編號查找到借閱者的信息，也可以實(shí)行模糊查找，這個(gè)功能的實(shí)現與前面圖書(shū)查找的實(shí)現過(guò)程一般，就不再詳細說(shuō)明。

5.8.5圖書(shū)館維護借閱者管理功能的實(shí)現
 
此功能能對借閱者信息進(jìn)行查看添加、刪除、修改。在這里給出刷新按鈕的實(shí)現過(guò)程

5.8.6圖書(shū)館身份維護功能的實(shí)現
這一部分是對借閱者身份進(jìn)行管理，能對身份進(jìn)行添加、刪除、修改。并且同樣的在listview中選中某條或多條記錄時(shí)會(huì )在相應的右邊的組件中顯示出信息。此功能實(shí)現過(guò)程與前面所敘有雷同，略。
 
5.8.7圖書(shū)館借閱者統計功能的實(shí)現
 
此功能按借閱者身份進(jìn)行統計，得出具有某種身份的借閱者總數，此種身份的并借閱圖書(shū)的借閱者數和所借閱的圖書(shū)數，在下面給出實(shí)現過(guò)程。

5.8.8圖書(shū)館統計借閱過(guò)期記錄功能的實(shí)現
打印出的借閱過(guò)期催還報表如下圖所示：
 
此報表能顯示按借書(shū)證號升序排列的借閱信息超過(guò)限定時(shí)限的信息，其中主要的SQL語(yǔ)句如下：

5.9系統信息顯示的實(shí)現
 
顯過(guò)本系統的信息，并且右邊的字向上滾動(dòng)顯示，主要實(shí)現如下：