圖書館信息管理系統(tǒng)-設計報告

1、圖書館信息管理系統(tǒng)設計報告項目小組成員：35060602 石潔冰35060603 張 慧目 錄 TOC o 1-3 h z u HYPERLINK l _Toc186717561 1.引言 PAGEREF _Toc186717561 h 4 HYPERLINK l _Toc186717562 1.1開發(fā)背景 PAGEREF _Toc186717562 h 4 HYPERLINK l _Toc186717563 1.2 開發(fā)工具 PAGEREF _Toc186717563 h 4 HYPERLINK l _Toc186717564 1.3系統(tǒng)運行環(huán)境 PAGEREF _Toc186717564

2、h 4 HYPERLINK l _Toc186717565 1.4 參考資料 PAGEREF _Toc186717565 h 4 HYPERLINK l _Toc186717566 1.5 數(shù)據(jù)庫設計的步驟 PAGEREF _Toc186717566 h 5 HYPERLINK l _Toc186717567 2.可行性研究報告 PAGEREF _Toc186717567 h 5 HYPERLINK l _Toc186717568 2.1可行性研究的前提 PAGEREF _Toc186717568 h 5 HYPERLINK l _Toc186717569 系統(tǒng)開發(fā)要求 PAGEREF _To

3、c186717569 h 6 HYPERLINK l _Toc186717570 2.1.2 目標 PAGEREF _Toc186717570 h 6 HYPERLINK l _Toc186717571 條件、假設和限定 PAGEREF _Toc186717571 h 6 HYPERLINK l _Toc186717572 2.2 可行性研究結(jié)果 PAGEREF _Toc186717572 h 7 HYPERLINK l _Toc186717573 管理上的可行性 PAGEREF _Toc186717573 h 7 HYPERLINK l _Toc186717574 2.2.2 技術(shù)上的可行性

4、 PAGEREF _Toc186717574 h 7 HYPERLINK l _Toc186717575 PAGEREF _Toc186717575 h 7 HYPERLINK l _Toc186717576 3 .需求分析報告 PAGEREF _Toc186717576 h 8 HYPERLINK l _Toc186717577 3.1 需求分析的任務 PAGEREF _Toc186717577 h 8 HYPERLINK l _Toc186717578 3.1.1. 信息需求 PAGEREF _Toc186717578 h 8 HYPERLINK l _Toc186717579 3.1.2

5、. 處理需求 PAGEREF _Toc186717579 h 8 HYPERLINK l _Toc186717580 3.1.3. 性能需求 PAGEREF _Toc186717580 h 8 HYPERLINK l _Toc186717581 3.2 需求收集 PAGEREF _Toc186717581 h 9 HYPERLINK l _Toc186717582 3.2.1 調(diào)查用戶組成情況 PAGEREF _Toc186717582 h 9 HYPERLINK l _Toc186717583 3.2.2 調(diào)查各個用戶的系統(tǒng)利用情況 PAGEREF _Toc186717583 h 9 HYP

6、ERLINK l _Toc186717584 3.2.3. 明確新系統(tǒng)的要求 PAGEREF _Toc186717584 h 9 HYPERLINK l _Toc186717585 3.3 需求分析 PAGEREF _Toc186717585 h 9 HYPERLINK l _Toc186717586 基本功能需求分析 PAGEREF _Toc186717586 h 10 HYPERLINK l _Toc186717587 系統(tǒng)實現(xiàn)數(shù)據(jù)流圖 PAGEREF _Toc186717587 h 13 HYPERLINK l _Toc186717588 數(shù)據(jù)元素表 PAGEREF _Toc186717

7、588 h 16 HYPERLINK l _Toc186717589 數(shù)據(jù)字典 PAGEREF _Toc186717589 h 18 HYPERLINK l _Toc186717590 4.圖書館信息管理系統(tǒng)的數(shù)據(jù)庫設計 PAGEREF _Toc186717590 h 19 HYPERLINK l _Toc186717591 4.1 概念結(jié)構(gòu)設計（ER圖設計） PAGEREF _Toc186717591 h 19 HYPERLINK l _Toc186717592 設計局部分ER圖 PAGEREF _Toc186717592 h 19 HYPERLINK l _Toc186717593 合并分

8、ER圖，生成初步ER圖 PAGEREF _Toc186717593 h 22 HYPERLINK l _Toc186717594 消除不必要的冗余，設計基本ER圖 PAGEREF _Toc186717594 h 24 HYPERLINK l _Toc186717595 4.2邏輯結(jié)構(gòu)設計 PAGEREF _Toc186717595 h 26 HYPERLINK l _Toc186717596 4.2.1 概念模型（ER圖）轉(zhuǎn)換為關系數(shù)據(jù)模型 PAGEREF _Toc186717596 h 26 HYPERLINK l _Toc186717597 關系模型的規(guī)范化與優(yōu)化 PAGEREF _Toc

9、186717597 h 27 HYPERLINK l _Toc186717598 設計用戶子模式 PAGEREF _Toc186717598 h 28 HYPERLINK l _Toc186717599 4.3物理結(jié)構(gòu)設計 PAGEREF _Toc186717599 h 28 HYPERLINK l _Toc186717600 物理結(jié)構(gòu)設計概述 PAGEREF _Toc186717600 h 28 HYPERLINK l _Toc186717601 4.3.2 存取方法選擇 PAGEREF _Toc186717601 h 29 HYPERLINK l _Toc186717602 4.3.3 存

10、儲結(jié)構(gòu)的確定 PAGEREF _Toc186717602 h 30 HYPERLINK l _Toc186717603 5開發(fā)總結(jié) PAGEREF _Toc186717603 h 311.引言1.1開發(fā)背景隨著計算機技術(shù)的發(fā)展以及計算機網(wǎng)絡的逐漸普及，英特網(wǎng)成為人們查找信息的重要場所。二十一世紀是信息的時代，所以信息的交換和信息流通顯得特別重要。因此，圖書館使用計算機來管理成為必然。建立管理信息系統(tǒng)是一個很好的解決辦法，因為隨著社會生產(chǎn)力的迅速發(fā)展和科學技術(shù)的突飛猛進，一個集計算機技術(shù)、通迅技術(shù)、數(shù)據(jù)庫技術(shù)、信息技術(shù)、現(xiàn)代管理理論為一體的系統(tǒng)開發(fā)方法已經(jīng)逐漸成熟，我們完全能夠結(jié)合自己的實際情況

11、開發(fā)出實用的管理信息系統(tǒng)，來指導我們的學習。為此，我們通過自主開發(fā)這一圖書館信息管理系統(tǒng)，達到提高工作效率的目的。1.2 開發(fā)工具本系統(tǒng)主要利用NetBeans作前端的應用開發(fā)工具，利用java語言實現(xiàn)相應的功能，利用Mysql5.0作為 后臺的數(shù)據(jù)庫，利用WindowsXP作為系統(tǒng)平臺。1.3系統(tǒng)運行環(huán)境本系統(tǒng)的運行環(huán)境是中文版win32平臺上運行。1.4 參考資料 1薩師暄，王珊 數(shù)據(jù)庫系統(tǒng)概論， 第四版， 高等教育出版社。2李建中，王珊編著，數(shù)據(jù)庫系統(tǒng)原理，電子工業(yè)出版社，1998年。3相關數(shù)據(jù)庫管理系統(tǒng)手冊。4圖書館信息管理系統(tǒng)開發(fā)工具手冊.doc(數(shù)據(jù)庫大作業(yè)要求)。5. 求是科技編

12、著,Java信息管理系統(tǒng)開發(fā),人民郵電出版社，2005年。6.sun公司網(wǎng)站。1.5 數(shù)據(jù)庫設計的步驟需求分析概念結(jié)構(gòu)設計邏輯結(jié)構(gòu)設計物理結(jié)構(gòu)設計實施和維護需求說明概念模型邏輯模型物理模式數(shù)據(jù)庫圖1-1數(shù)據(jù)庫設計步驟示意圖數(shù)據(jù)庫的設計按規(guī)范化設計方法，劃分為五個階段(圖1-1)，每個階段有相應的成果：2.可行性研究報告2.1可行性研究的前提當今時代是飛速發(fā)展的信息時代。在各行各業(yè)中離不開信息處理，這正是計算機被廣泛應用于信息管理系統(tǒng)的環(huán)境。計算機的最大好處在于利用它能夠進行信息管理，使用計算機進行信息控制，不僅提高了工作效率，而且大大的提高了其安全性。尤其對于復雜的信息管理，計算機能夠充分發(fā)揮

13、它的優(yōu)越性。計算機進行信息管理與信息管理系統(tǒng)的開發(fā)密切相關，系統(tǒng)的開發(fā)是系統(tǒng)管理的前提。而圖書館信息管理系統(tǒng)則是這類信息管理系統(tǒng)的典型代表，對于我們這類具有實驗性質(zhì)的實踐項目來說是最合適不過的了。圖書館作為一種信息資源的集散地，圖書和用戶借閱資料繁多，包含很多的信息數(shù)據(jù)的管理，現(xiàn)今，有很多的圖書館都是初步開始使用，甚至尚未使用計算機進行信息管理。根據(jù)調(diào)查得知，他們以前對信息管理的主要方式是基于文本、表格等紙介質(zhì)的手工處理，對于圖書借閱情況（如借書天數(shù)、超過限定借書時間的天數(shù)）的統(tǒng)計和核實等往往采用對借書卡的人工檢查進行，對借閱者的借閱權(quán)限、以及借閱天數(shù)等用人工計算、手抄進行。數(shù)據(jù)信息處理工作量

14、大，容易出錯；由于數(shù)據(jù)繁多，容易丟失，且不易查找?？偟膩碚f，缺乏系統(tǒng)，規(guī)范的信息管理手段。盡管有的圖書館有計算機，但是尚未用于信息管理，沒有發(fā)揮它的效力，資源閑置比較突出，這就是管理信息系統(tǒng)的開發(fā)的基本環(huán)境。數(shù)據(jù)處理手工操作，工作量大，出錯率高，出錯后不易更改。圖書館采取手工方式對圖書借閱情況進行人工管理，由于信息比較多，圖書借閱信息的管理工作混亂而又復雜；一般借閱情況是記錄在借書證上，圖書的數(shù)目和內(nèi)容記錄在文件中，圖書館的工作人員和管理員也只是當時對它比較清楚，時間一長，如再要進行查詢，就得在眾多的資料中翻閱、查找了，造成查詢費時、費力。如要對很長時間以前的圖書進行更改就更加困難了。 基于這

15、眾多的問題，有必要建立一個圖書管理系統(tǒng)，使圖書管理工作規(guī)范化，系統(tǒng)化，程序化，避免圖書管理的隨意性，提高信息處理的速度和準確性，能夠及時、準確、有效的查詢和修改圖書情況。系統(tǒng)開發(fā)要求小型圖書信息管理系統(tǒng)需實現(xiàn)功能：力求通過本系統(tǒng)，1圖書館工作人員對自己的個人資料進行編輯，查詢圖書的借閱情況從而更有利于系統(tǒng)工作人員維護圖書的安全性。2讀者通過登陸、對自己的個人信息進行編輯，并且查詢書籍的基本情況。3管理人員對圖書館工作人員及書籍的信息進行添加和刪除。4出版社通過登陸查詢所供應圖書的借閱情況以及提供新書的基本信息。 目標通過數(shù)字化，使圖書館工作所需人力減少；提高圖書館信息管理系統(tǒng)的響應速度；加快相

16、關信息的流動速度，提高效率；通過實際的工程實踐，使我們對數(shù)據(jù)庫的認識水平提高，完成課程要求。條件、假設和限定由于本項目的實驗性質(zhì)，沒有投資方。系統(tǒng)必須運行在Win32平臺上。存在權(quán)限控制機制，只有管理員才能刪除出版商和工作人員賬號。2.2 可行性研究結(jié)果管理上的可行性 這個開發(fā)是我們作為數(shù)據(jù)庫課程實踐的一項應用工程，任課老師對此十分的重視.希望在課程規(guī)定時間內(nèi)將該數(shù)據(jù)庫系統(tǒng)開發(fā)出來，當然如能投入使用更好，以使我們在鞏固課堂所學理論知識的基礎上對實踐有所了解，對圖書館管理的數(shù)字化及現(xiàn)代化能起到一些創(chuàng)新促進作用。雖然如今一些大型的圖書館管理系統(tǒng)基本上已經(jīng)很先進了，但作為信息管理系統(tǒng)的代表，這次的小

17、型圖書館信息管理系統(tǒng)的開發(fā)對本科學生數(shù)據(jù)庫理論的實踐還是有一定幫助的，因此這個系統(tǒng)在管理上是可行的。2.2.2 技術(shù)上的可行性 本次圖書館管理信息系統(tǒng)的開發(fā)根據(jù)本學期軟件工程課程的一些基本要求，使用傳統(tǒng)的生命周期法，即給管理信息系統(tǒng)的開發(fā)定義一個過程，對其每一個階段規(guī)定它的任務，工作流程，管理目標以及要編制的文檔等，使開發(fā)工作易于管理和控制，形成一個可操作的規(guī)范。 同時，系統(tǒng)需要對數(shù)據(jù)庫的靈活和快捷的操作，因此強大的SQL語言是開發(fā)此類數(shù)據(jù)庫系統(tǒng)的最佳選擇。NetBeans本身所攜帶的面向?qū)ο蟪绦虻拈_發(fā)界面，以及對SQL的支持，符合本系統(tǒng)的開發(fā)需求。 正確的理論指導和優(yōu)秀的開發(fā)工具，雙重保證了

18、我們這次開發(fā)的技術(shù)可行性。2.2.3經(jīng)濟上的可行性 首先，從經(jīng)濟效益上講，而本系統(tǒng)的開發(fā)，為統(tǒng)計人員工作效率帶來了一個質(zhì)的飛躍：第一，本系統(tǒng)的運行可以代替人工進行許多繁雜的勞動；第二，本系統(tǒng)的運行可以節(jié)省許多資源；第三，本系統(tǒng)的運行可以大大的提高統(tǒng)計人員的工作效率； 其次是，從所需投入來講，對于一個中小型的圖書館管理系統(tǒng)來說，它的投資成本是十分的低的，應該不會超過5000元。當然，對于我們作為課程設計的系統(tǒng)實現(xiàn)來說，投資成本基本上不用考慮，而一旦開發(fā)成功，即可以在此基礎上添加外部設備，用于Internet服務，甚至會帶來意料之外的收益。而對我們來說，此系統(tǒng)的開發(fā)給了我們實踐的機會，數(shù)據(jù)庫對我們

19、來說不再只是書本上簡簡單單的三個字，而是能完成某個功能的可用之物，加深了我們對書本知識的理解和掌握，這是我們另一項收益，無論開發(fā)是否完美無缺，這項收益都是存在的，而且是最重要的。 所以，此系統(tǒng)在經(jīng)濟上也是可行的。3 .需求分析報告根據(jù)軟件工程課程所學以及國標的部分模版，需求分析就是收集、分析用戶的需求，是數(shù)據(jù)庫設計過程的起點，也是后續(xù)步驟的基礎。只有準確地獲取用戶需求，才能設計出優(yōu)秀的數(shù)據(jù)庫。本節(jié)主要介紹需求分析的任務、過程、方法，以及需求分析的結(jié)果。3.1 需求分析的任務需求分析的任務是通過詳細調(diào)查，獲取原有手工系統(tǒng)的工作過程和業(yè)務處理，明確用戶的各種需求，確定新系統(tǒng)的功能。在用戶需求分析中

20、，除了充分考慮現(xiàn)有系統(tǒng)的需求外，還要充分考慮系統(tǒng)將來可能的擴充和修改，從開始就讓系統(tǒng)具有擴展性。調(diào)查的重點是信息及處理，信息是數(shù)據(jù)庫設計的依據(jù)，處理是系統(tǒng)處理的依據(jù)。用戶需求主要有一下幾個方面：3.1.1. 信息需求指用戶從數(shù)據(jù)庫中需要哪些數(shù)據(jù)，這些數(shù)據(jù)的性質(zhì)是什么，數(shù)據(jù)從哪兒來。由信息要求導出數(shù)據(jù)要求，從而確定數(shù)據(jù)庫中需要存儲哪些數(shù)據(jù)。本系統(tǒng)數(shù)據(jù)性質(zhì)比較單一，即CHAR類和FLOAT類即能滿足需求，數(shù)據(jù)庫中所存儲信息皆來自對該系統(tǒng)未來用戶的調(diào)查，由系統(tǒng)管理員集中錄入即可。當然在本次用來做系統(tǒng)演示的數(shù)據(jù)庫中存入的數(shù)據(jù)只是為求簡便而編纂的一些無意義數(shù)據(jù)，僅供實驗用。3.1.2. 處理需求指用戶完

21、成哪些處理，處理的對象是什么，處理的方法和規(guī)則，處理有什么要求，如：是聯(lián)機處理還是批處理？處理周期多長？處理量多大？本系統(tǒng)中用戶分了四種，即借閱者、工作人員、管理人員和圖書出版社，所需處理信息無非圖書信息或者個人的基本信息，要求不高，處理量根據(jù)所應用的圖書館的規(guī)模大小而有很大的區(qū)別。本次演示中所需處理的信息只涉及下文中所列出的六個表格中的信息，信息量不大。3.1.3. 性能需求指用戶對新系統(tǒng)性能的要求，如系統(tǒng)的響應時間、系統(tǒng)的容量，以及一些其它屬性，如：保密性、可靠性等等。確定用戶的需求是比較困難的事情，特別是大型數(shù)據(jù)庫設計，這是因為： = 1 * GB2 大部分用戶缺少計算機知識，不知道計算

22、機究竟能做什么而不能做什么，因而不能準確的表達自己的需求； = 2 * GB2 數(shù)據(jù)庫設計人員缺少用戶的專業(yè)知識，不易理解用戶的真正需求，甚至誤解用戶的需求； = 3 * GB2 用戶的需求可能是變化的。導致需求變化的因素很多，如：內(nèi)部結(jié)構(gòu)的調(diào)整、管理體制的改變、市場需求的變化等等； = 4 * GB2 人員的變化可能引起用戶需求的變化，由于個人對具體系統(tǒng)的期望不一致，導致人員的變化引起需求的變化。需求分析可以劃分為需求收集和需求分析兩個階段，但是這兩個階段沒有明確的界限，可能交叉或同時進行。在需求收集時，進行初步需求分析；在需求分析時，對需求不明確之處要進一步收集。3.2 需求收集進行需求分

23、析，首先要進行需求收集，需求收集的主要途徑是用戶調(diào)查，用戶調(diào)查就是調(diào)查用戶，了解需求，與用戶達成共識，然后分析和表達用戶需求。用戶調(diào)查的具體內(nèi)容有: 調(diào)查用戶組成情況該系統(tǒng)為小型圖書館信息管理系統(tǒng)，用戶主要分為四類：圖書借閱者、圖書出版社、圖書館工作人員以及系統(tǒng)管理人員，對于小型的管理系統(tǒng)來說，用戶類型與數(shù)量都不是很大，所以比較容易滿足用戶對該系統(tǒng)的需求。 調(diào)查各個用戶的系統(tǒng)利用情況一般包括各個用戶使用哪些輸入數(shù)據(jù)，輸入數(shù)據(jù)從哪些地方來，輸入數(shù)據(jù)的格式和含義；用戶進行什么加工處理，處理的方法和規(guī)則及輸出哪些數(shù)據(jù)，輸出到什么部門，輸出數(shù)據(jù)的格式和含義。在本系統(tǒng)中，四類用戶都需要通過登陸界面進入系

24、統(tǒng)。圖書借閱者可以輸入自己的號碼及密碼進入，查看自己的圖書借閱情況以及更新個人信息；圖書出版社需要輸入姓名及代碼，只要兩者匹配即可登陸，查看館藏書借閱情況并可發(fā)布圖書供應信息；圖書館工作人員需要工作證號及密碼登陸，進行借書及還書一系列操作，并可以修改讀者借閱情況；而該系統(tǒng)管理人員通過密碼進入后可對圖書情況及其他用戶的信息的基本情況進行更新等操作，是權(quán)限最大的用戶。 3.2.3. 明確新系統(tǒng)的要求和用戶一起，幫助用戶確定新系統(tǒng)的各種要求，對于計算機不能實現(xiàn)的功能，要耐心地作解釋工作。3.3 需求分析通過用戶調(diào)查，收集用戶需求后，要對用戶需求進行分析，并表達用戶的需求。用戶需求分析的方法很多，可以

25、采用結(jié)構(gòu)化分析方法、面向?qū)ο蠓治龇椒ǖ?，本章采用結(jié)構(gòu)化分析方法。結(jié)構(gòu)化分析方法（Structured Analysis 簡稱SA方法）采用自頂向下、逐層分解的方法進行需求分析，從最上層的組織機構(gòu)入手，逐步分解。結(jié)構(gòu)化分析方法主要采用數(shù)據(jù)流圖對用戶需求進行分析，用數(shù)據(jù)字典和加工說明對數(shù)據(jù)流圖進行補充和說明。數(shù)據(jù)流圖（Data Flow Diagram，DFD），數(shù)據(jù)流描述系統(tǒng)中數(shù)據(jù)流動的過程，反映的是加工處理的對象。其主要成分有四種：數(shù)據(jù)流、數(shù)據(jù)存儲、加工、數(shù)據(jù)的源點和終點。數(shù)據(jù)流用箭頭表示，箭頭方向表示數(shù)據(jù)流向，箭頭上標明數(shù)據(jù)流的名稱，數(shù)據(jù)流由數(shù)據(jù)項組成。數(shù)據(jù)存儲用來保存數(shù)據(jù)流，可以是暫時的，

26、也可以是永久的，用雙劃線表示，并標明數(shù)據(jù)儲的名稱。數(shù)據(jù)流可以從數(shù)據(jù)存儲流入或流出，可以不標明數(shù)據(jù)流名。加工是對數(shù)據(jù)進行處理的單元，用園角矩形表示，并在其內(nèi)標明加工名稱。數(shù)據(jù)的源點和終點表示數(shù)據(jù)的來源和去處，代表系統(tǒng)外部的數(shù)據(jù)，用方框表示。對于復雜系統(tǒng)，一張數(shù)據(jù)流圖難以描述和難以理解，往往采用分層數(shù)據(jù)流圖。（本系統(tǒng)數(shù)據(jù)流圖將在部分中給出，圖3-2給出了本系統(tǒng)基本的數(shù)據(jù)流圖，圖3-3和3-4是為了更清楚地說明系統(tǒng)中兩個比較繁瑣的數(shù)據(jù)處理環(huán)節(jié)即查詢及圖書信息處理環(huán)節(jié)的數(shù)據(jù)流程二做出的一些簡要說明）數(shù)據(jù)字典（Data Dictionary ，DD）是關于數(shù)據(jù)信息的集合，它對數(shù)據(jù)流圖中的數(shù)據(jù)進行定義和說

27、明，主要有數(shù)據(jù)項、數(shù)據(jù)流、數(shù)據(jù)存儲。DD可以采用卡片形式。（本系統(tǒng)中設計的數(shù)據(jù)信息的定義及說明皆在部分的“數(shù)據(jù)字典”部分中給出了詳細說明，若在程序?qū)崿F(xiàn)部分對變量名稱有任何不明了之處可查閱給出的數(shù)據(jù)字典）3.3.1基本功能需求分析圖書館信息管理涉及圖書信息、系統(tǒng)用戶信息、讀者信息、圖書借閱等多種數(shù)據(jù)管理, 從管理的角度可將該信息管理系統(tǒng)分為五大模塊：圖書管理人員維護模塊、圖書館工作人員借閱處理模塊、圖書信息模塊、讀者信息操作模塊以及圖書出版社操作模塊，如下圖所示：圖書館信息管理系統(tǒng)圖書管理人員維護模塊圖書館工作人員借閱處理模塊讀者信息操作模塊圖書供應商操作模塊圖書信息模塊圖31模塊信息其中的圖書

28、信息管理包括圖書征定、借還、查詢等操作，系統(tǒng)用戶管理包括系統(tǒng)用戶類別和用戶數(shù)據(jù)管理，讀者數(shù)據(jù)管理包括讀者類別管理和個人數(shù)據(jù)的錄入、修改和刪除，圖書出版社管理包括供應信息管理以及出版社聯(lián)系人個人信息管理等。經(jīng)過實際考察與分析，圖書管理系統(tǒng)主要應具有以下功能： 1、圖書借閱者的需求是查詢圖書室所存的圖書、個人借閱情況及個人信息的修改。圖書借閱者可直接查看圖書館圖書情況，如果圖書借閱者根據(jù)本人借書證號和密碼登錄系統(tǒng)，還可以進行本人借書情況的查詢和維護部分個人信息。當然，一般情況下，圖書借閱者只應該查詢和維護本人的借書情況和個人信息，若查詢和維護其他借閱者的借書情況和個人信息，就要知道其他圖書借閱者的

29、借書證號和密碼。這些是很難得到的，特別是密碼，所以不但滿足了圖書借閱者的要求，還保護了圖書借閱者的個人隱私。2、圖書館工作人員對圖書借閱者的借閱及還書要求進行操作，同時形成借書或還書報表給借閱者查看確認。圖書館工作人員有修改圖書借閱者借書和還書記錄的權(quán)限，所以需對工作人員登陸本模塊進行更多的考慮。在此模塊中，圖書館工作人員可以為圖書借閱者加入借書記錄或是還書記錄，打印生成相應的報表給用戶查看和確認。3、圖書出版社的需求是能查詢到館中圖書的借閱情況以及個人的一些基本信息，另外還可以將自己的可供應書籍情況進行更新，以便與圖書館方面進行供貨聯(lián)系。4、圖書館管理人員的功能最為復雜，包括對工作人員、圖書

30、借閱者、圖書以及出版社信息進行管理和維護，還有系統(tǒng)狀態(tài)的查看、維護等。當然在系統(tǒng)進入穩(wěn)定運行期后，系統(tǒng)管理人員就不需要隨時隨地的維護了，只要進行一些必要的簡單日常處理就可以了。圖書館管理人員功能的信息量大，數(shù)據(jù)安全性和保密性要求最高。本功能實現(xiàn)對圖書信息、借閱者信息、總體借閱情況信息的管理和統(tǒng)計、工作人員和管理人員信息查看及維護。圖書館管理員可以瀏覽、查詢、添加、刪除、修改、統(tǒng)計圖書的基本信息；瀏覽、查詢、統(tǒng)計、添加、刪除和修改圖書借閱者的基本信息，瀏覽、查詢、統(tǒng)計圖書館的借閱信息，但不能添加、刪除和修改借閱信息，這部分功能應該由圖書館工作人員執(zhí)行，但是，刪除某條圖書借閱者基本信息記錄時，應實

31、現(xiàn)對該圖書借閱者借閱記錄的級聯(lián)刪除。并且還應具有生成催還圖書報表，并打印輸出的功能。在本系統(tǒng)中由于沒有打印機設備供試驗，所以把報表打印改成報表預覽。具體功能如下： 設計不同用戶的操作權(quán)限和登陸方法 對所有用戶開放的圖書查詢 借閱者維護借閱者個人部分信息 借閱者查看個人借閱情況信息 維護借閱者個人密碼 根據(jù)借閱情況對數(shù)據(jù)庫進行操作并生成報表 根據(jù)還書情況對數(shù)據(jù)庫進行操作并生成報表 查詢及統(tǒng)計各種信息 維護圖書信息 維護工作人員和管理員信息 維護借閱者信息3.3.2系統(tǒng)實現(xiàn)數(shù)據(jù)流圖 圖32系統(tǒng)的總數(shù)據(jù)流圖由于該系統(tǒng)的一些功能所需的信息也比較多，因此以下列出系統(tǒng)查詢功能以及圖書數(shù)據(jù)處理的功能的實現(xiàn)的

32、數(shù)據(jù)流程圖：1、系統(tǒng)查詢功能實現(xiàn)的流程圖：圖33查詢功能實現(xiàn)流程圖2、 SHAPE * MERGEFORMAT 圖書處理數(shù)據(jù)流程圖：圖34圖書處理數(shù)據(jù)流程圖3.3.3數(shù)據(jù)元素表 本次圖書管理系統(tǒng)設計中，共涉及6個實體，即圖書、出版社、借閱者、工作人員、管理人員、身份。根據(jù)數(shù)據(jù)庫設計演示要求，暫簡單列出演示所用的部分信息，為求簡潔明了，有些數(shù)據(jù)直接用數(shù)字或字母等代替。以下即所列的六個表，以供參考：圖書的基本信息編號書名作者出版社類別數(shù)量是否全部借出1aA甲X20Y2bB乙Y100Y3cC丙Z200Y4dD丁W100Y5eE甲X200Y6fF乙Y100Y7gG丙Z100Y8hH丁W200N9iI甲

33、X100N10jJ乙Y200N11kK丙Z100N12lL丁W200N13mM甲X200N14nN乙Y100N15oO丙Z200N表31圖書的基本信息出版社的基本信息編號聯(lián)系人所在地電話ID供應類別甲蕭劍廣州000000X,W乙紫薇北京123412X,Y丙爾康上海432121Y,Z丁小燕子天津111111Z,W表32出版社的基本信息借閱者的信息證件號姓名性別身份身份證號電話密碼350601乾隆M皇上9889hs350602慈禧F太后9779th350603令妃F妃子9669fz350604詠琪M阿哥9559ag350605晴兒F格格9449gg表33借閱者的基本信息工作人員信息工作號姓名電話密

34、碼ID類別01ab111ab1111X、Y02ac222ac2222Y、Z03ad333ad3333Z、W表34工作人員的基本信息 管理人員信息工作號姓名電話密碼ID35060602sjb35060602sjb3506060235060603zh35060603zh35060603表35管理人員基本信息身份信息代碼類別最大借閱數(shù)b本科生6y研究生8j教師9表36身份信息注：1“圖書的基本信息”一表中，類別分別用了X、Y、Z、W來表示，代表有四類，如科技或文學等，非縮寫無實際意義；最后一欄“是否借出”屬性中，當100本（即數(shù)量里標明的數(shù)字）全部借出時屬性值才為Y,否則即為N。2借閱者的信息中，所

35、用姓名及其他純屬筆者玩笑之舉，只為在繁雜的工作中找點樂趣，絕無剽竊及侵權(quán)意圖，若有冒犯，敬請諒解。3以上是設計初根據(jù)系統(tǒng)需求所列出的基本初始表格，可能在實際操作中所建立的數(shù)據(jù)庫表格會跟這些初始表格有些出入，但基本上原理不會有變化，只是根據(jù)實際需要為了更方便的操作所做出的改變。在這里就不再列出最后成形的表格了，因為在后面的“系統(tǒng)實現(xiàn)報告”中會詳細給出。數(shù)據(jù)字典數(shù)據(jù)庫變量定義及其說明：變量名稱變量含義變量取值類型變量最大長度限制num編號float10bookn書名char30publ出版社char30author作者char30kind類別char30amo數(shù)量float10link聯(lián)系人cha

36、r30id證件號float10pho電話float10city所在地char30passw密碼char30name姓名char30maxn最大借閱數(shù)float10dm身份代碼float30表37變量定義及說明4.圖書館信息管理系統(tǒng)的數(shù)據(jù)庫設計4.1 概念結(jié)構(gòu)設計（ER圖設計） 在概念設計階段中，我們從用戶的角度看待數(shù)據(jù)及處理要求和約束，產(chǎn)生一個反映用戶觀點的概念模式。然后再把概念模式轉(zhuǎn)換成邏輯模式。將概念設計從設計過程中獨立開來，使各階段的任務相對單一化，設計復雜程度大大降低，不受特定DBMS的限制。利用ER方法進行數(shù)據(jù)庫的概念設計，可分成三步進行：首先設計局部ER模式，然后把各局部ER模式綜

37、合成一個全局模式，最后對全局ER模式進行優(yōu)化，得到最終的模式，即概念模式。設計局部分ER圖 實體和屬性的基本定義：圖書（圖書編號，圖書名稱，作者，出版社，類型，數(shù)量，是否借出）出版社（出版社編號，聯(lián)系人姓名，身份證號，電話，地址，供應類別）借閱者（證件號，姓名，性別，身份證號，身份，聯(lián)系電話，密碼）身份（身份編號，身份描述，最大借閱數(shù)）工作人員（工作號，姓名，電話，密碼，ID,維護范圍）管理人員（工作號，姓名，電話，密碼，ID） ER模型的“聯(lián)系”用于刻畫實體之間的關聯(lián)。一種完整的方式是對局部結(jié)構(gòu)中任意兩實體類型，依據(jù)需求分析的結(jié)果，考察局部結(jié)構(gòu)中任意兩個實體類型之間是否存在聯(lián)系。若有聯(lián)系，進

38、一步確定是1:N，M:N，還是1:1等。還要考察一個實體類型內(nèi)部是否存在聯(lián)系，兩個實體類型之間是否存在聯(lián)系，多個實體類型之間是否存在聯(lián)系，等等。解釋如下：1）一個借閱者（用戶）只能具有一種身份，而一種身份可被多個借閱者所具有；2）一本圖書只能屬于一種圖書類別（類別），而一種圖書類別可以包含多本圖書；3）一個用戶可以借閱多本不同的書，而一本書也可以被多個不同的用戶所借閱；4）一本圖書只能由一名工作人員來維護，而一名工作人員要負責幾類的多本圖書；5）一本圖書只能由一個出版社來供應，而一個出版社可出版多本圖書；所以根據(jù)一系列的事實描述，可以初步畫出分ER圖如下所示（其中以綠顏色標出并加了下劃線的屬性

39、即表示主碼，其余為非主碼）：圖3-5 局部分ER圖（共六個）合并分ER圖，生成初步ER圖 所有局部ER模式都設計好了后，接下來就是把它們綜合成單一的全局概念結(jié)構(gòu)。全局概念結(jié)構(gòu)不僅要支持所有局部ER模式，而且必須合理地表示一個完整、一致的數(shù)據(jù)庫概念結(jié)構(gòu)。1) 確定公共實體類型 為了給多個局部ER模式的合并提供開始合并的基礎，首先要確定各局部結(jié)構(gòu)中的公共實體類型。在這一步中我們僅根據(jù)實體類型名和鍵來認定公共實體類型。一般把同名實體類型作為公共實體類型的一類候選，把具有相同鍵的實體類型作為公共實體類型的另一類候選。2) 局部ER模式的合并合并有兩種方法：一是多個分ER圖一次性集成，這種方法弊病多，且

40、實施起來不方便，所以不常用；一般用第二種，即逐步集成的方法，用累加方式一次集成兩個分ER圖。 則可知合并的原則是：首先進行兩兩合并；先和合并那些現(xiàn)實世界中有聯(lián)系的局部結(jié)構(gòu)；合并從公共實體類型開始，最后再加入獨立的局部結(jié)構(gòu)。3) 消除沖突 數(shù)據(jù)庫中的沖突可分為三類：屬性沖突、結(jié)構(gòu)沖突、命名沖突。 = 1 * GB2 屬性沖突屬性域沖突：屬性值的類型、取值范圍或單位不同。 = 2 * GB2 命名沖突同名異義：相同的實體名稱或?qū)傩悦Q，而意義不同。如借閱者和工作人員的屬性中都有“姓名”這一屬性，但兩個的意義是不一樣的，這個沖突要消除。異名同義：相同的實體或?qū)傩允褂昧瞬煌拿Q。在合并局部ER圖時，

41、消除實體命名和屬性命名方面不一致的地方也很重要。 = 3 * GB2 結(jié)構(gòu)沖突結(jié)構(gòu)沖突的表現(xiàn)主要是：同一對象在不同的局部ER圖中，有的作為實體，有的作為屬性；同一實體在不同的局部ER圖中，屬性的個數(shù)或順序不一致；同一實體的在局部ER圖中碼不同；實體間的聯(lián)系在不同的局部ER圖中聯(lián)系的類型不同。設計全局ER模式的目的不在于把若干局部ER模式形式上合并為一個ER模式，而在于消除沖突，使之成為能夠被所有用戶共同理解和接受的同一的概念模型。在本次設計中，屬性沖突基本上不存在，因為數(shù)據(jù)類型比較簡單、單一；所以最主要的沖突在于結(jié)構(gòu)沖突與命名沖突。上述設計中結(jié)構(gòu)沖突有一項最為明顯，即“身份”這一對象在借閱者為

42、實體的情況下是作為其屬性存在的，而后面另一局部應用中身份亦作為一個單獨的實體出現(xiàn)，所以通過整體分析，決定將“身份”只抽象為實體，而不再作為借閱者的屬性出現(xiàn)。其次，就是命名沖突比較明顯，所以在合并時對產(chǎn)生了命名沖突的屬性進行了重命名，比如“借閱者”與“工作人員”都有“姓名”這一屬性，則可以用“姓名1”與“姓名2”來進行區(qū)分，依此類推，從而得到了基本可行的初步ER圖。 基于以上理論，對前面所列出的局部分ER圖進行合并，所得到的初步全局ER圖如下所示（其中，用矩形來表示實體，如借閱者，同時用綠色標出；橢圓表示屬性，屬性中加下劃線的為主碼，其余為非主碼；菱形為實體間的關系，同時用黃色標出）： 圖3-6

43、 初步全局ER圖消除不必要的冗余，設計基本ER圖在初步ER圖中，可能存在一些冗余的數(shù)據(jù)和實體間冗余的聯(lián)系，所謂冗余的數(shù)據(jù)是指可由基本數(shù)據(jù)導出的數(shù)據(jù)，冗余的聯(lián)系是指可由其它聯(lián)系導出的聯(lián)系。冗余數(shù)據(jù)和冗余聯(lián)系容易破壞數(shù)據(jù)庫的完整性，給數(shù)據(jù)庫的維護增加困難，應當予以消除。消除了冗余后的初步ER圖被稱為基本ER圖，即我們要得到的概念模型。當然，并不是所有的冗余數(shù)據(jù)與冗余聯(lián)系都必須消除，有時為了提高效率，而不得不以冗余信息作為代價。在小型的系統(tǒng)設計中，對于比較簡單的數(shù)據(jù)關系，我們常用分析的方法來去掉實際應用中多余的關系或者屬性。此外，除了使用分析方法外，還可以用規(guī)范化理論來消除冗余。在規(guī)范化理論中，函數(shù)

44、依賴的概念提供了消除冗余聯(lián)系的形式化工具，這種方法常用于關系比較多而復雜的數(shù)據(jù)庫設計過程中。在本系統(tǒng)中，由于實體間關系不是很復雜，完全可以根據(jù)分析方法對初步ER圖進行冗余消除。比如知道圖書的“編號”即可推出該圖書屬于哪一類別的，因為館藏圖書的編號是按類別依次排下來的，所以對于“圖書”這一實體來說，“類別”一項可作為冗余信息刪掉；管理員通過對圖書信息的管理可以與借閱者、圖書出版社以及工作人員的信息發(fā)生聯(lián)系，可以起到對這些信息進行管理的效果，所以可以將管理員與其他用戶的管理關系刪掉，保留管理員對圖書信息的管理關系；另外，由于用戶的身份可以通過系統(tǒng)編號來識別，故可以將借閱者、圖書出版社、工作人員的“

45、身份證號”（ID）這一屬性去掉,這樣可以避免在同一個人處于不同角色時引起的系統(tǒng)數(shù)據(jù)混亂。從而得到消除了部分不必要的冗余之后的基本ER圖如下：圖3-7 基本ER圖概念結(jié)構(gòu)設計所得的概念模型（即上面所得的ER圖），是獨立于任何一種DBMS的信息結(jié)構(gòu)，與實現(xiàn)無關。4.2邏輯結(jié)構(gòu)設計邏輯結(jié)構(gòu)設計的任務是將概念結(jié)構(gòu)設計階段設計的ER圖，轉(zhuǎn)化為選用的DBMS所支持的數(shù)據(jù)模型相符的邏輯結(jié)構(gòu)，形成邏輯模型?；陉P系數(shù)據(jù)模型的邏輯結(jié)構(gòu)的設計一般分為三個步驟： = 1 * GB2 概念模型(ER圖)轉(zhuǎn)換為關系數(shù)據(jù)模型 = 2 * GB2 關系模型的規(guī)范化和優(yōu)化 = 3 * GB2 設計用戶子模式4.2.1 概念模

46、型（ER圖）轉(zhuǎn)換為關系數(shù)據(jù)模型概念模型向關系數(shù)據(jù)模型的轉(zhuǎn)化就是將用ER圖表示的實體、實體屬性和實體間的聯(lián)系轉(zhuǎn)化為關系模式。具體而言就是轉(zhuǎn)化為選定的DBMS支持的數(shù)據(jù)庫對象?，F(xiàn)在，絕大部分關系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）都支持表(Table)、列(Column)、視圖(View)、主碼(Primary Key)、外碼(Foreign)、約束(Constraint)等數(shù)據(jù)庫對象。一般轉(zhuǎn)換原則如下： = 1 * GB2 一個實體轉(zhuǎn)換為一個表（Table），則實體的屬性轉(zhuǎn)換為表的列（Column），實體的碼轉(zhuǎn)換為表的主鍵（Primary Key）。 = 2 * GB2 實體間的聯(lián)系根據(jù)聯(lián)系的類型，轉(zhuǎn)換

47、如下： = 1 * GB3 1:n的聯(lián)系：1:n的聯(lián)系是比較普遍的聯(lián)系，其轉(zhuǎn)換比較直觀。如：ER圖中出版社和圖書的關系是1:n的聯(lián)系，轉(zhuǎn)換成：表：出版社（編號、聯(lián)系人、所在地、電話、供應類別）；表：圖書（圖書號、書名、出版社編號、數(shù)量、是否借出）。圖書表中增加了一個“出版社編號”屬性，它是一個外碼，是出版社的主碼。轉(zhuǎn)換規(guī)律是在n端的實體對應的表中增加屬性，該屬性是1端實體對應表的主碼。 = 2 * GB3 1:1的聯(lián)系：1:1聯(lián)系是1:n聯(lián)系的特例，兩個實體分別轉(zhuǎn)換成表后，只要在一個表中增加外碼，一般在記錄數(shù)較少的表中增加屬性，作為外碼，該屬性是另一個表的主碼。 = 3 * GB3 m:n的聯(lián)

48、系：通過引進一個新表來表達兩個實體間多對多的聯(lián)系，新表的主碼由聯(lián)系兩端實體的主碼組合而成，同時增加相關的聯(lián)系屬性。如：在ER圖中借閱者和圖書的聯(lián)系是m:n聯(lián)系，轉(zhuǎn)換成：表：借閱者（借書號、姓名、性別、密碼、電話號碼）表：圖書（圖書號、書名、出版社編號、作者、數(shù)量、是否借出）。表：借閱表（借書號、圖書號、借書日期、應歸還日期、借閱數(shù)目）新增表的“借閱表”中“借書號”和“圖書號”組合為主碼，分別是外碼，其中“借書號”是借閱者表的主碼，“圖書號”是圖書表的主碼。同時增加了借閱相關的屬性：借書日期、應歸還日期、借閱數(shù)目。故根據(jù)以上的轉(zhuǎn)換原則以及轉(zhuǎn)換過程的分析，可以由基本ER圖轉(zhuǎn)換出下面的初始關系數(shù)據(jù)庫

49、模式：圖書（圖書號、書名、出版社編號、作者、數(shù)量、是否借出）。借閱者（借書號、姓名、性別、密碼、電話號碼）借閱表（借書號、圖書號、借書日期、應歸還日期、借閱數(shù)目）出版社（編號、聯(lián)系人、所在地、電話、供應類別）供求關系表（出版社編號、圖書編號）身份（代碼、描述、最大借閱數(shù)）身份關系表（借書號、身份代碼）管理人員（工作號1、姓名、電話、密碼）管理關系表（管理人員編號、圖書號）工作人員（工作號2、 姓名、電話、維護圖書類型、密碼）圖書維護信息表（工作人員編號、圖書號）關系模型的規(guī)范化與優(yōu)化關系模型的優(yōu)化是為了進一步提高數(shù)據(jù)庫的性能，適當?shù)匦薷?、調(diào)整關系模型結(jié)構(gòu)。關系模型的優(yōu)化通常以規(guī)范化理論為指導，

50、其目的是消除各種數(shù)據(jù)庫操作異常，提高查詢效率，節(jié)省存儲空間，方便數(shù)據(jù)庫的管理。常用的方法包括規(guī)范化和分解：1）. 規(guī)范化規(guī)范化就是確定表中各個屬性之間的數(shù)據(jù)依賴，并逐一進行分析，考察是否存在部分函數(shù)依賴、傳遞函數(shù)依賴、多值依賴等，確定屬于哪種范式。根據(jù)需求分析的處理要求，分析是否合適從而進行分解。必須注意的是：并不是規(guī)范化程度越高的關系就越優(yōu)，因為規(guī)范化越高的關系，連接運算越多，而連接運算的代價相當高。對于查詢頻繁而很少更新的表，可以是較低的規(guī)范化程度。將兩個或多個高范式通過自然連接，重新合并成一個較低的范式過程稱為逆規(guī)范化。規(guī)范化和逆規(guī)范化是一對矛盾，何時進行規(guī)范化、何時進行逆規(guī)范化、進行到

51、什么程度，在具體的應用環(huán)境中，需要設計者仔細分析和平衡。2）. 分解分解的目的是為了提高數(shù)據(jù)操作的效率和存儲空間的利用率。常用的分解方式是水平分解和垂直分解。水平分解是指按一定的原則，將一個表橫向分解成兩個或多個表；垂直分解是通過模式分解，將一個表縱向分解成兩個或多個表。垂直分解也是關系模式規(guī)范化的途徑之一，同時，為了應用和安全的需要，垂直分解將經(jīng)常一起使用的數(shù)據(jù)或機密的數(shù)據(jù)分離。當然，通過視圖的方式可以達到同樣的效果。根據(jù)3NF的規(guī)范原則，可以將初始數(shù)據(jù)庫關系模式規(guī)范化。由于3NF中不存在非主屬性對碼的傳遞依賴及部分依賴關系，分析以上所得關系模式，去掉不必要的部分表格，可得到以下具有3NF特

52、性的關系模式：圖書（圖書號、書名、出版社編號、作者、數(shù)量、是否借出）借閱者（借書號、姓名、性別、身份代碼、密碼、電話號碼）借閱表（借書號、圖書號、借書日期、應歸還日期、借閱數(shù)目）出版社（編號、聯(lián)系人、所在地、電話、供應類別）身份（代碼、描述、最大借閱數(shù)）管理人員（工作號1、姓名、電話、密碼）工作人員（工作號2、 姓名、電話、維護圖書類型、密碼）設計用戶子模式概念模型通過轉(zhuǎn)換、優(yōu)化后成為全局邏輯模型，還應該根據(jù)局部應用的需要，結(jié)合DBMS的特點，設計用戶子模式。用戶子模式也稱為外模式，是全局邏輯模式的子集，是數(shù)據(jù)庫用戶（包括程序用戶和最終用戶）能夠看見和使用的局部數(shù)據(jù)的邏輯結(jié)構(gòu)和特征。目前，關系

53、數(shù)據(jù)庫管理系統(tǒng)（RDBMS）一般都提供了視圖（View）的概念，可以通過視圖功能設計用戶模式。此外也可以通過垂直分解的方式來實現(xiàn)。定義用戶模式的主要目的是：1符合用戶的使用習慣。例如：客戶在供應部門習慣稱為供應商，在消除命名沖突時統(tǒng)一命名為客戶。在用戶模式設計時，可以設計一個供應商視圖，一是要符合使用習慣，二是只僅僅包含提供物資的對象，而不包含銷售的客戶。2為不同的用戶級別提供不同的用戶模式保證數(shù)據(jù)的安全。有些數(shù)據(jù)，如企業(yè)產(chǎn)品的成本信息是企業(yè)比較重要的信息，只有部分用戶才能查詢和使用，客戶一般不能查詢，可以定義客戶視圖，屏蔽其中的成本信息，確保系統(tǒng)的安全。3簡化用戶對系統(tǒng)的使用某些查詢是比較復

54、雜的查詢，為了方便用戶使用，并保證查詢結(jié)果的一致性，經(jīng)常將這些復雜的查詢定義為視圖，大大簡化了用戶的使用。在本系統(tǒng)中，管理人員的權(quán)限最大，他可以查看其他普通用戶的所有信息，而像借閱者這樣的普通用戶，只能查閱自己的個人信息及圖書信息，對于他們來說，其他用戶的信息是不可見的。所以在設計外模式時，只需要對不同的用戶開放不同范圍的數(shù)據(jù)即可，對于該系統(tǒng)而言，不存在需要將已由關系模式拆分的情況，所以只需要根據(jù)各類用戶對數(shù)據(jù)的可見范圍作出相應的調(diào)整即可。具體來說即：所有數(shù)據(jù)對管理人員來說都是可見的，圖書信息的數(shù)據(jù)對所有人可見，其余的個人信息只對除管理人員之外的個人可見。4.3物理結(jié)構(gòu)設計物理結(jié)構(gòu)設計概述物理

55、結(jié)構(gòu)設計的目的主要有兩點：一是提高數(shù)據(jù)庫的性能，滿足用戶的性能需求；二是有效地利用存儲空間。總之，是為了使數(shù)據(jù)庫系統(tǒng)在時間和空間上最優(yōu)。數(shù)據(jù)庫的物理結(jié)構(gòu)設計包括兩個步驟： = 1 * GB2 確定數(shù)據(jù)庫的物理結(jié)構(gòu)。在關系數(shù)據(jù)庫中主要是存儲結(jié)構(gòu)和存儲方法的確定； = 2 * GB2 對物理結(jié)構(gòu)進行評價，評價的重點是時間和空間的效率。如果評價結(jié)果滿足應用要求，則可進入到物理結(jié)構(gòu)的實施階段，否則要重新進行物理結(jié)構(gòu)設計或修改物理結(jié)構(gòu)設計，有的甚至返回到邏輯結(jié)構(gòu)設計階段，修改邏輯結(jié)構(gòu)。由于物理結(jié)構(gòu)設計與具體的數(shù)據(jù)庫管理系統(tǒng)有關，各種產(chǎn)品提供了不同的物理環(huán)境、存取方法和存儲結(jié)構(gòu)，能供設計人員使用的設計變量

56、、參數(shù)范圍都有很大差別，因此物理結(jié)構(gòu)設計沒有通用的方法。在進行物理設計前，注意以下幾個方面的問題：1. DBMS的特點物理結(jié)構(gòu)設計只能在特定的DBMS下進行，必須了解DBMS的特點，充分利用其提供的各種手段，了解其限制條件。本次設計的小型圖書館信息管理系統(tǒng)是在WindowsXP支持下的MYSQL環(huán)境下開發(fā)運行的，具有功能強，使用簡單，管理方便，運行速度快，可靠性高，安全保密等特點。2.應用環(huán)境特別是計算機系統(tǒng)的性能，數(shù)據(jù)庫系統(tǒng)不僅與數(shù)據(jù)庫設計有關，與計算機系統(tǒng)有關。比如：是單任務系統(tǒng)還是多任務系統(tǒng)，是單磁盤還是磁盤陣列，是數(shù)據(jù)庫專用服務器還是多用途服務器等等。還要了解數(shù)據(jù)的使用頻率，對于使用頻率高的數(shù)據(jù)要優(yōu)先考慮。此外，數(shù)據(jù)庫的物理結(jié)構(gòu)設計是一個不斷完善的過程，開始只能是一個初步設計，在數(shù)據(jù)庫系統(tǒng)運行過程中要不斷檢測并進行調(diào)整和優(yōu)化。對關系數(shù)據(jù)庫的物理結(jié)構(gòu)設計主要內(nèi)容有： = 1 * GB2 為關系模式選取存取方法 = 2 * GB2 設計關系及索引的物理存儲結(jié)構(gòu) 存取方法選擇數(shù)據(jù)庫系統(tǒng)是多用戶共享的系統(tǒng)，為了滿足用戶快速存取的要求，必須選擇有效的存取方法。一般數(shù)據(jù)庫系統(tǒng)中為關系、索引等數(shù)據(jù)庫對象提供了多種存取方法，主要有索引方法、聚簇方法、HASH方法。.1索引存取方法的選擇索引是數(shù)據(jù)庫表的一個附加表，存儲了建立索引列的值和對應的記錄地址。查詢數(shù)據(jù)時，先在索引中