图书馆信息管理系统设计报告

目 录

1.引言 .............................................................................................................................................. 2

1.1开发背景 ............................................................................................................................ 2 1.2 开发工具 ........................................................................................................................... 2 1.3系统运行环境 .................................................................................................................... 2 1.4 参考资料 ........................................................................................... 错误!未定义书签。

1.5 数据库设计的步骤 .................................................................................................... 3

2.可行性研究报告 ........................................................................................................................... 3

2.1可行性研究的前提 ............................................................................................................ 3

2.1.1系统开发要求 .......................................................................................................... 4 2.1.2 目标 ......................................................................................................................... 4 2.1.3条件、假设和限定 .................................................................................................. 4 2.2 可行性研究结果 ................................................................................................................ 4

2.2.1管理上的可行性 ...................................................................................................... 5 2.2.2 技术上的可行性 ..................................................................................................... 5 2.2.3 ................................................................................................................................... 5

3 .需求分析报告 ............................................................................................................................... 5

3.1 需求分析的任务 ................................................................................................................ 6

3.1.1. 信息需求 ................................................................................................................ 6 3.1.2. 处理需求 ................................................................................................................ 6 3.1.3. 性能需求 ................................................................................................................ 6 3.2 需求收集 ............................................................................................................................ 7

3.2.1 调查用户组成情况 ................................................................................................. 7 3.2.2 调查各个用户的系统利用情况 ............................................................................. 7 3.2.3. 明确新系统的要求 ................................................................................................ 7 3.3 需求分析 .................................................................................................................... 7 3.3.1基本功能需求分析 ........................................................................................................ 8 3.3.2系统实现数据流图 ........................................................................................................ 11 3.3.3数据元素表 .................................................................................................................... 14

3.3.4数据字典 ................................................................................................................ 16

4.图书馆信息管理系统的数据库设计 .......................................................................................... 17

4.1 概念结构设计（ER图设计） ........................................................................................ 17

4.1.1设计局部分ER图 ................................................................................................. 17 4.1.2合并分ER图，生成初步ER图 .................................................................................. 20 4.1.3消除不必要的冗余，设计基本ER图 ........................................................................ 22 4.2逻辑结构设计 ................................................................................................................... 24

4.2.1 概念模型（ER图）转换为关系数据模型 ......................................................... 24 4.2.2关系模型的规范化与优化 .......................................................................................... 25 4.2.3设计用户子模式 .......................................................................................................... 26 4.3物理结构设计 .................................................................................................................. 26

4.3.1物理结构设计概述 ................................................................................................ 26 4.3.2 存取方法选择 ....................................................................................................... 27 4.3.3 存储结构的确定 ................................................................................................... 28

第 1 页 共 29 页

5开发总结...................................................................................................................................... 29

1.引言

1.1开发背景

随着计算机技术的发展以及计算机网络的逐渐普及，英特网成为人们查找信息的重要场所。二十一世纪是信息的时代，所以信息的交换和信息流通显得特别重要。因此，图书馆使用计算机来管理成为必然。

建立管理信息系统是一个很好的解决办法，因为随着社会生产力的迅速发展和科学技术的突飞猛进，一个集计算机技术、通迅技术、数据库技术、信息技术、现代管理理论为一体的系统开发方法已经逐渐成熟，我们完全能够结合自己的实际情况开发出实用的管理信息系统，来指导我们的学习。为此，我们通过自主开发这一图书馆信息管理系统，达到提高工作效率的目的。

1.2 开发工具

本系统主要利用NetBeans作前端的应用开发工具，利用java语言实现相应的功能，利用Mysql5.0作为 后台的数据库，利用WindowsXP作为系统平台。

1.3系统运行环境

本系统的运行环境是中文版win32平台上运行。

第 2 页 共 29 页

1.5 数据库设计的步骤

数据库的设计按规范化设计方法，划分为五个阶段(图1-1)，每个阶段有相应的成果：

需求分析 需求说明 概念结构设计 概念模型 逻辑结构设计 逻辑模型 物理结构设计 物理模式 实施和维护 图1-1数据库设计步骤数据库

2.可行性研究报告

2.1可行性研究的前提

当今时代是飞速发展的信息时代。在各行各业中离不开信息处理，这正是计算机被广泛应用于信息管理系统的环境。计算机的最大好处在于利用它能够进行信息管理，使用计算机进行信息控制，不仅提高了工作效率，而且大大的提高了其安全性。尤其对于复杂的信息管理，计算机能够充分发挥它的优越性。计算机进行信息管理与信息管理系统的开发密切相关，系统的开发是系统管理的前提。而图书馆信息管理系统则是这类信息管理系统的典型代表，对于我们这类具有实验性质的实践项目来说是最合适不过的了。

图书馆作为一种信息资源的集散地，图书和用户借阅资料繁多，包含很多的信息数据的管理，现今，有很多的图书馆都是初步开始使用，甚至尚未使用计算机进行信息管理。根据调查得知，他们以前对信息管理的主要方式是基于文本、表格等纸介质的手工处理，对于图书借阅情况（如借书天数、超过限定借书时间的天数）的统计和核实等往往采用对借书卡的人工检查进行，对借阅者的借阅权限、以及借阅天数等用人工计算、手抄进行。数据信息处理工作量大，容易出错；由于数据繁多，容易丢失，且不易查找。总的来说，缺乏系统，规范的信息管理手段。尽管有的图书馆有计算机，但是尚未用于信息管理，没有发挥它的效力，资源闲置比较突出，这就是管理信息系统的开发的基本环境。数据处理手工操作，工作量大，出错率高，出错后不易更改。图书馆采取手工方式对图书借阅情况进行人工管理，由于信息

第 3 页 共 29 页

比较多，图书借阅信息的管理工作混乱而又复杂；一般借阅情况是记录在借书证上，图书的数目和内容记录在文件中，图书馆的工作人员和管理员也只是当时对它比较清楚，时间一长，如再要进行查询，就得在众多的资料中翻阅、查找了，造成查询费时、费力。如要对很长时间以前的图书进行更改就更加困难了。

基于这众多的问题，有必要建立一个图书管理系统，使图书管理工作规范化，系统化，程序化，避免图书管理的随意性，提高信息处理的速度和准确性，能够及时、准确、有效的查询和修改图书情况。

2.1.1系统开发要求

小型图书信息管理系统需实现功能： 力求通过本系统，

1〉图书馆工作人员对自己的个人资料进行编辑，查询图书的借阅情况从而更有利于系统工作人员维护图书的安全性。

2〉读者通过登陆、对自己的个人信息进行编辑，并且查询书籍的基本情况。 3〉管理人员对图书馆工作人员及书籍的信息进行添加和删除。

4〉出版社通过登陆查询所供应图书的借阅情况以及提供新书的基本信息。

2.1.2 目标

A. B. C. D.

通过数字化，使图书馆工作所需人力减少； 提高图书馆信息管理系统的响应速度； 加快相关信息的流动速度，提高效率；

通过实际的工程实践，使我们对数据库的认识水平提高，完成课程要求。

2.1.3条件、假设和限定

A. 由于本项目的实验性质，没有投资方。 B. 系统必须运行在Win32平台上。

C. 存在权限控制机制，只有管理员才能删除出版商和工作人员账号。

2.2 可行性研究结果

第 4 页 共 29 页

2.2.1管理上的可行性

这个开发是我们作为数据库课程实践的一项应用工程，任课老师对此十分的重视.希望在课程规定时间内将该数据库系统开发出来，当然如能投入使用更好，以使我们在巩固课堂所学理论知识的基础上对实践有所了解，对图书馆管理的数字化及现代化能起到一些创新促进作用。虽然如今一些大型的图书馆管理系统基本上已经很先进了，但作为信息管理系统的代表，这次的小型图书馆信息管理系统的开发对本科学生数据库理论的实践还是有一定帮助的，因此这个系统在管理上是可行的。

2.2.2 技术上的可行性

本次图书馆管理信息系统的开发根据本学期软件工程课程的一些基本要求，使用传统的生命周期法，即给管理信息系统的开发定义一个过程，对其每一个阶段规定它的任务，工作流程，管理目标以及要编制的文档等，使开发工作易于管理和控制，形成一个可操作的规范。 同时，系统需要对数据库的灵活和快捷的操作，因此强大的SQL语言是开发此类数据库系统的最佳选择。NetBeans本身所携带的面向对象程序的开发界面，以及对SQL的支持，符合本系统的开发需求。

正确的理论指导和优秀的开发工具，双重保证了我们这次开发的技术可行性。

2.2.3经济上的可行性

首先，从经济效益上讲，而本系统的开发，为统计人员工作效率带来了一个质的飞跃： 第一，本系统的运行可以代替人工进行许多繁杂的劳动； 第二，本系统的运行可以节省许多资源；

第三，本系统的运行可以大大的提高统计人员的工作效率；

其次是，从所需投入来讲，对于一个中小型的图书馆管理系统来说，它的投资成本是十分的低的，应该不会超过5000元。当然，对于我们作为课程设计的系统实现来说，投资成本基本上不用考虑，而一旦开发成功，即可以在此基础上添加外部设备，用于Internet服务，甚至会带来意料之外的收益。而对我们来说，此系统的开发给了我们实践的机会，数据库对我们来说不再只是书本上简简单单的三个字，而是能完成某个功能的可用之物，加深了我们对书本知识的理解和掌握，这是我们另一项收益，无论开发是否完美无缺，这项收益都是存在的，而且是最重要的。

所以，此系统在经济上也是可行的。

3 .需求分析报告

根据软件工程课程所学以及国标的部分模版，需求分析就是收集、分析用户的需求，是

第 5 页 共 29 页

数据库设计过程的起点，也是后续步骤的基础。只有准确地获取用户需求，才能设计出优秀的数据库。本节主要介绍需求分析的任务、过程、方法，以及需求分析的结果。

3.1 需求分析的任务

需求分析的任务是通过详细调查，获取原有手工系统的工作过程和业务处理，明确用户的各种需求，确定新系统的功能。在用户需求分析中，除了充分考虑现有系统的需求外，还要充分考虑系统将来可能的扩充和修改，从开始就让系统具有扩展性。

调查的重点是信息及处理，信息是数据库设计的依据，处理是系统处理的依据。用户需求主要有一下几个方面：

3.1.1. 信息需求

指用户从数据库中需要哪些数据，这些数据的性质是什么，数据从哪儿来。由信息要求导出数据要求，从而确定数据库中需要存储哪些数据。本系统数据性质比较单一，即CHAR类和FLOAT类即能满足需求，数据库中所存储信息皆来自对该系统未来用户的调查，由系统管理员集中录入即可。当然在本次用来做系统演示的数据库中存入的数据只是为求简便而编纂的一些无意义数据，仅供实验用。

3.1.2. 处理需求

指用户完成哪些处理，处理的对象是什么，处理的方法和规则，处理有什么要求，如：是联机处理还是批处理？处理周期多长？处理量多大？

本系统中用户分了四种，即借阅者、工作人员、管理人员和图书出版社，所需处理信息无非图书信息或者个人的基本信息，要求不高，处理量根据所应用的图书馆的规模大小而有很大的区别。本次演示中所需处理的信息只涉及下文中所列出的六个表格中的信息，信息量不大。

3.1.3. 性能需求

指用户对新系统性能的要求，如系统的响应时间、系统的容量，以及一些其它属性，如：保密性、可靠性等等。

确定用户的需求是比较困难的事情，特别是大型数据库设计，这是因为：

⑴ 大部分用户缺少计算机知识，不知道计算机究竟能做什么而不能做什么，因而不能准确的表达自己的需求；

⑵ 数据库设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求；

⑶ 用户的需求可能是变化的。导致需求变化的因素很多，如：内部结构的调整、管理的改变、市场需求的变化等等；

⑷ 人员的变化可能引起用户需求的变化，由于个人对具体系统的期望不一致，导致人员的变化引起需求的变化。

第 6 页 共 29 页

需求分析可以划分为需求收集和需求分析两个阶段，但是这两个阶段没有明确的界限，可能交叉或同时进行。在需求收集时，进行初步需求分析；在需求分析时，对需求不明确之处要进一步收集。

3.2 需求收集

进行需求分析，首先要进行需求收集，需求收集的主要途径是用户调查，用户调查就是调查用户，了解需求，与用户达成共识，然后分析和表达用户需求。用户调查的具体内容有:

3.2.1 调查用户组成情况

该系统为小型图书馆信息管理系统，用户主要分为四类：图书借阅者、图书出版社、图书馆工作人员以及系统管理人员，对于小型的管理系统来说，用户类型与数量都不是很大，所以比较容易满足用户对该系统的需求。

3.2.2 调查各个用户的系统利用情况

一般包括各个用户使用哪些输入数据，输入数据从哪些地方来，输入数据的格式和含义；用户进行什么加工处理，处理的方法和规则及输出哪些数据，输出到什么部门，输出数据的格式和含义。在本系统中，四类用户都需要通过登陆界面进入系统。图书借阅者可以输入自己的号码及密码进入，查看自己的图书借阅情况以及更新个人信息；图书出版社需要输入姓名及代码，只要两者匹配即可登陆，查看馆藏书借阅情况并可发布图书供应信息；图书馆工作人员需要工作证号及密码登陆，进行借书及还书一系列操作，并可以修改读者借阅情况；而该系统管理人员通过密码进入后可对图书情况及其他用户的信息的基本情况进行更新等操作，是权限最大的用户。

3.2.3. 明确新系统的要求

和用户一起，帮助用户确定新系统的各种要求，对于计算机不能实现的功能，要耐心地作解释工作。

3.3 需求分析

通过用户调查，收集用户需求后，要对用户需求进行分析，并表达用户的需求。用户需求分析的方法很多，可以采用结构化分析方法、面向对象分析方法等，本章采用结构化分析方法。结构化分析方法（Structured Analysis 简称SA方法）采用自顶向下、逐层分解的

方法进行需求分析，从最上层的组织机构入手，逐步分解。结构化分析方法主要采用数据流图对用户需求进行分析，用数据字典和加工说明对数据流图进行补充和说明。

第 7 页 共 29 页

数据流图（Data Flow Diagram，DFD），数据流描述系统中数据流动的过程，反映的是加工处理的对象。其主要成分有四种：数据流、数据存储、加工、数据的源点和终点。数据流用箭头表示，箭头方向表示数据流向，箭头上标明数据流的名称，数据流由数据项组成。数据存储用来保存数据流，可以是暂时的，也可以是永久的，用双划线表示，并标明数据储的名称。数据流可以从数据存储流入或流出，可以不标明数据流名。加工是对数据进行处理的单元，用园角矩形表示，并在其内标明加工名称。数据的源点和终点表示数据的来源和去处，代表系统外部的数据，用方框表示。对于复杂系统，一张数据流图难以描述和难以理解，往往采用分层数据流图。（本系统数据流图将在3.2.2部分中给出，图3-2给出了本系统基本的数据流图，图3-3和3-4是为了更清楚地说明系统中两个比较繁琐的数据处理环节〈即查询及图书信息处理环节〉的数据流程二做出的一些简要说明）

数据字典（Data Dictionary ，DD）是关于数据信息的集合，它对数据流图中的数据进行定义和说明，主要有数据项、数据流、数据存储。DD可以采用卡片形式。（本系统中设计的数据信息的定义及说明皆在3.3.4部分的“数据字典”部分中给出了详细说明，若在程序实现部分对变量名称有任何不明了之处可查阅给出的数据字典）

3.3.1基本功能需求分析

图书馆信息管理涉及图书信息、系统用户信息、读者信息、图书借阅等多种数据管理, 从管理的角度可将该信息管理系统分为五大模块：图书管理人员维护模块、图书馆工作人员借阅处理模块、图书信息模块、读者信息操作模块以及图书出版社操作模块，如下图所示：

第 8 页 共 29 页

图书馆信息管理系统 图书管理人员维护模块 图书馆工作人员借阅处图书信息模块 读者信息操作模块 图书供应商操作模块 理模块

图3—1模块信息

其中的图书信息管理包括图书征定、借还、查询等操作，系统用户管理包括系统用户类别和用户数据管理，读者数据管理包括读者类别管理和个人数据的录入、修改和删除，图书出版社管理包括供应信息管理以及出版社联系人个人信息管理等。经过实际考察与分析，图书管理系统主要应具有以下功能：

1、图书借阅者的需求是查询图书室所存的图书、个人借阅情况及个人信息的修改。图书借阅者可直接查看图书馆图书情况，如果图书借阅者根据本人借书证号和密码登录系统，还可以进行本人借书情况的查询和维护部分个人信息。当然，一般情况下，图书借阅者只应该查询和维护本人的借书情况和个人信息，若查询和维护其他借阅者的借书情况和个人信息，就要知道其他图书借阅者的借书证号和密码。这些是很难得到的，特别是密码，所以不但满足了图书借阅者的要求，还保护了图书借阅者的个人隐私。

2、图书馆工作人员对图书借阅者的借阅及还书要求进行操作，同时形成借书或还书报表给借阅者查看确认。图书馆工作人员有修改图书借阅者借书和还录的权限，所以需对工作人员登陆本模块进行更多的考虑。在此模块中，图书馆工作人员可以为图书借阅者加入借录或是还录，打印生成相应的报表给用户查看和确认。

3、图书出版社的需求是能查询到馆中图书的借阅情况以及个人的一些基本信息，另外

第 9 页 共 29 页

还可以将自己的可供应书籍情况进行更新，以便与图书馆方面进行供货联系。

4、图书馆管理人员的功能最为复杂，包括对工作人员、图书借阅者、图书以及出版社信息进行管理和维护，还有系统状态的查看、维护等。当然在系统进入稳定运行期后，系统管理人员就不需要随时随地的维护了，只要进行一些必要的简单日常处理就可以了。图书馆管理人员功能的信息量大，数据安全性和保密性要求最高。本功能实现对图书信息、借阅者信息、总体借阅情况信息的管理和统计、工作人员和管理人员信息查看及维护。图书馆管理员可以浏览、查询、添加、删除、修改、统计图书的基本信息；浏览、查询、统计、添加、删除和修改图书借阅者的基本信息，浏览、查询、统计图书馆的借阅信息，但不能添加、删除和修改借阅信息，这部分功能应该由图书馆工作人员执行，但是，删除某条图书借阅者基本信息记录时，应实现对该图书借阅者借阅记录的级联删除。并且还应具有生成催还图书报表，并打印输出的功能。在本系统中由于没有打印机设备供试验，所以把报表打印改成报表预览。具体功能如下：

设计不同用户的操作权限和登陆方法 对所有用户开放的图书查询 借阅者维护借阅者个人部分信息 借阅者查看个人借阅情况信息 维护借阅者个人密码

根据借阅情况对数据库进行操作并生成报表 根据还书情况对数据库进行操作并生成报表 查询及统计各种信息 维护图书信息

维护工作人员和管理员信息 维护借阅者信息

第 10 页 共 29 页

3.3.2系统实现数据流图 图书信息更新管理人员用户信息更新用户登录借阅人员个人借阅情况查询 图3—2系统的总数据流图 数据工作人员供应商第 11 页 共 29 页

借书操作还书操作个人信息更新书目出版更新馆藏书借阅情况

由于该系统的一些功能所需的信息也比较多，因此以下列出系统查询功能以及图书数据处理的功能的实现的数据流程图：

1、系统查询功能实现的流程图：

读者信息表读者查询读者情况查询要求读者情况查询类别处理查询借阅信息查询图书情况图书查询图书借阅情况要求图书信息统计图书统计统计表

图3—3查询功能实现流程图

第 12 页 共 29 页

2、图书处理数据流程图：

新书入库图书管理要求入库单图书信息表注销图书单销注要求类型处理借书单借书无效输入还书单借阅信息表还书

图3—4图书处理数据流程图

第 13 页 共 29 页

3.3.3数据元素表

本次图书管理系统设计中，共涉及6个实体，即图书、出版社、借阅者、工作人员、管理人员、身份。根据数据库设计演示要求，暂简单列出演示所用的部分信息，为求简洁明了，有些数据直接用数字或字母等代替。以下即所列的六个表，以供参考：

图书的基本信息

编号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 书名 a b c d e f g h i j k l m n o 作者 A B C D E F G H I J K L M N O 出版社 甲 乙 丙 丁 甲 乙 丙 丁 甲 乙 丙 丁 甲 乙 丙 类别 X Y Z W X Y Z W X Y Z W X Y Z 数量 20 100 200 100 200 100 100 200 100 200 100 200 200 100 200 是否全部借出 Y Y Y Y Y Y Y N N N N N N N N 表3—1图书的基本信息

出版社的基本信息

编号 甲 联系人 萧剑 所在地 广州 电话 0000 ID 00 供应类别 X,W 第 14 页 共 29 页

乙 丙 丁 紫薇 尔康 小燕子 北京 上海 天津 1234 4321 1111 12 21 11 X,Y Y,Z Z,W 表3—2出版社的基本信息

借阅者的信息

证件号 350601 350602 350603 350604 350605 姓名 乾隆 慈禧 令妃 咏琪 晴儿 性别 M F F M F 身份 皇上 太后 妃子 阿哥 格格 身份证号 98 97 96 95 94 电话 79 69 59 49 密码 hs th fz ag gg

表3—3借阅者的基本信息

工作人员信息

工作号 01 02 03 姓名 ab ac ad 电话 111 222 333 密码 ab ac ad ID 1111 2222 3333 类别 X、Y Y、Z Z、W

表3—4工作人员的基本信息

管理人员信息

工作号 35060602 35060603 姓名 sjb zh 电话 35060602 35060603

表3—5管理人员基本信息

密码 sjb zh ID 35060602 35060603 第 15 页 共 29 页

身份信息

代码 b y j 类别 本科生 研究生 教师

表3—6身份信息

最大借阅数 6 8 9 注：

1〉“图书的基本信息”一表中，类别分别用了X、Y、Z、W来表示，代表有四类，如科技或文学等，非缩写无实际意义；最后一栏“是否借出”属性中，当100本（即数量里标明的数字）全部借出时属性值才为Y,否则即为N。

2〉借阅者的信息中，所用姓名及其他纯属笔者玩笑之举，只为在繁杂的工作中找点乐趣，绝无剽窃及侵权意图，若有冒犯，敬请谅解。

3〉以上是设计初根据系统需求所列出的基本初始表格，可能在实际操作中所建立的数据库表格会跟这些初始表格有些出入，但基本上原理不会有变化，只是根据实际需要为了更方便的操作所做出的改变。在这里就不再列出最后成形的表格了，因为在后面的“系统实现报告”中会详细给出。

3.3.4数据字典

数据库变量定义及其说明： 变量名称 num bookn publ author kind amo link id pho city 变量含义 编号 书名 出版社 作者 类别 数量 联系人 证件号 电话 所在地 变量取值类型 float char char char char float char float float char 变量最大长度 10 30 30 30 30 10 30 10 10 30 第 16 页 共 29 页

passw name maxn dm 密码 姓名 最大借阅数 身份代码 char char float float 30 30 10 30

表3—7变量定义及说明

4.图书馆信息管理系统的数据库设计

4.1 概念结构设计（ER图设计）

在概念设计阶段中，我们从用户的角度看待数据及处理要求和约束，产生一个反映用户观点的概念模式。然后再把概念模式转换成逻辑模式。将概念设计从设计过程中开来，使各阶段的任务相对单一化，设计复杂程度大大降低，不受特定DBMS的。利用ER方法进行数据库的概念设计，可分成三步进行：首先设计局部ER模式，然后把各局部ER模式综合成一个全局模式，最后对全局ER模式进行优化，得到最终的模式，即概念模式。

4.1.1设计局部分ER图

实体和属性的基本定义：

图书（图书编号，图书名称，作者，出版社，类型，数量，是否借出） 出版社（出版社编号，联系人姓名，身份证号，电话，地址，供应类别） 借阅者（证件号，姓名，性别，身份证号，身份，联系电话，密码） 身份（身份编号，身份描述，最大借阅数）

工作人员（工作号，姓名，电话，密码，ID,维护范围） 管理人员（工作号，姓名，电话，密码，ID）

ER模型的“联系”用于刻画实体之间的关联。一种完整的方式是对局部结构中任意两实 体类型，依据需求分析的结果，考察局部结构中任意两个实体类型之间是否存在联系。若有联系，进一步确定是1:N，M:N，还是1:1等。还要考察一个实体类型内部是否存在联系，两个实体类型之间是否存在联系，多个实体类型之间是否存在联系，等等。解释如下： 1）一个借阅者（用户）只能具有一种身份，而一种身份可被多个借阅者所具有； 2）一本图书只能属于一种图书类别（类别），而一种图书类别可以包含多本图书； 3）一个用户可以借阅多本不同的书，而一本书也可以被多个不同的用户所借阅； 4）一本图书只能由一名工作人员来维护，而一名工作人员要负责几类的多本图书； 5）一本图书只能由一个出版社来供应，而一个出版社可出版多本图书； ………………

所以根据一系列的事实描述，可以初步画出分ER图如下所示（其中以绿颜色标出并加

第 17 页 共 29 页

了下划线的属性即表示主码，其余为非主码）：

图书编号书名作者出版社 类别数量是否借出供应商编号联系人身份证号电话地址供应类别身份代码名称最大借阅数第 18 页 共 29 页

借阅者证件号姓名身份性别身份证号电话密码工作人员工作号姓名电话密码ID维护范围管理人员工作号姓名电话密码ID

图3-5 局部分ER图（共六个）

第 19 页 共 29 页

4.1.2合并分ER图，生成初步ER图

所有局部ER模式都设计好了后，接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式，而且必须合理地表示一个完整、一致的数据库概念结构。

1) 确定公共实体类型

为了给多个局部ER模式的合并提供开始合并的基础，首先要确定各局部结构中的公共实体类型。在这一步中我们仅根据实体类型名和键来认定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选，把具有相同键的实体类型作为公共实体类型的另一类候选。

2) 局部ER模式的合并

合并有两种方法：一是多个分ER图一次性集成，这种方法弊病多，且实施起来不方便，所以不常用；一般用第二种，即逐步集成的方法，用累加方式一次集成两个分ER图。 则可知合并的原则是：首先进行两两合并；先和合并那些现实世界中有联系的局部结构；合并从公共实体类型开始，最后再加入的局部结构。

3) 消除冲突

数据库中的冲突可分为三类：属性冲突、结构冲突、命名冲突。

⑴ 属性冲突

属性域冲突：属性值的类型、取值范围或单位不同。 ⑵ 命名冲突

同名异义：相同的实体名称或属性名称，而意义不同。如借阅者和工作人员的属性中都有“姓名”这一属性，但两个的意义是不一样的，这个冲突要消除。

异名同义：相同的实体或属性使用了不同的名称。在合并局部ER图时，消除实体命名和属性命名方面不一致的地方也很重要。

⑶ 结构冲突

结构冲突的表现主要是：同一对象在不同的局部ER图中，有的作为实体，有的作为属性；同一实体在不同的局部ER图中，属性的个数或顺序不一致；同一实体的在局部ER图中码不同；实体间的联系在不同的局部ER图中联系的类型不同。

设计全局ER模式的目的不在于把若干局部ER模式形式上合并为一个ER模式，而在于消除冲突，使之成为能够被所有用户共同理解和接受的同一的概念模型。

在本次设计中，属性冲突基本上不存在，因为数据类型比较简单、单一；所以最主要的冲突在于结构冲突与命名冲突。上述设计中结构冲突有一项最为明显，即“身份”这一对象在借阅者为实体的情况下是作为其属性存在的，而后面另一局部应用中身份亦作为一个单独的实体出现，所以通过整体分析，决定将“身份”只抽象为实体，而不再作为借阅者的属性出现。其次，就是命名冲突比较明显，所以在合并时对产生了命名冲突的属性进行了重命名，比如“借阅者”与“工作人员”都有“姓名”这一属性，则可以用“姓名1”与“姓名2”来进行区分，依此类推，从而得到了基本可行的初步ER图。

基于以上理论，对前面所列出的局部分ER图进行合并，所得到的初步全局ER图如下所示（其中，用矩形来表示实体，如借阅者，同时用绿色标出；椭圆表示属性，属性中加下划线的为主码，其余为非主码；菱形为实体间的关系，同时用黄色标出）：

第 20 页 共 29 页

ID1管理人员工作号1管理信息姓名1电话1密码1管理信息编号1书名出版社图书作者类别数量借阅供求是否借出维护编号2供应商工作人员借阅者属于身份性别最大借阅数证件号联系人ID2电话4工作号2姓名3电话3密码2所在地

图3-6 初步全局ER图

第 21 页 共 29 页

姓名2电话2身份描述代码身份证号供应类别密码3ID3维护范围

4.1.3消除不必要的冗余，设计基本ER图

在初步ER图中，可能存在一些冗余的数据和实体间冗余的联系，所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其它联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库的维护增加困难，应当予以消除。消除了冗余后的初步ER图被称为基本ER图，即我们要得到的概念模型。

当然，并不是所有的冗余数据与冗余联系都必须消除，有时为了提高效率，而不得不以冗余信息作为代价。

在小型的系统设计中，对于比较简单的数据关系，我们常用分析的方法来去掉实际应用中多余的关系或者属性。此外，除了使用分析方法外，还可以用规范化理论来消除冗余。在规范化理论中，函数依赖的概念提供了消除冗余联系的形式化工具，这种方法常用于关系比较多而复杂的数据库设计过程中。

在本系统中，由于实体间关系不是很复杂，完全可以根据分析方法对初步ER图进行冗余消除。比如知道图书的“编号”即可推出该图书属于哪一类别的，因为馆藏图书的编号是按类别依次排下来的，所以对于“图书”这一实体来说，“类别”一项可作为冗余信息删掉；管理员通过对图书信息的管理可以与借阅者、图书出版社以及工作人员的信息发生联系，可以起到对这些信息进行管理的效果，所以可以将管理员与其他用户的管理关系删掉，保留管理员对图书信息的管理关系；另外，由于用户的身份可以通过系统编号来识别，故可以将借阅者、图书出版社、工作人员的“身份证号”（ID）这一属性去掉,这样可以避免在同一个人处于不同角色时引起的系统数据混乱。从而得到消除了部分不必要的冗余之后的基本ER图如下：

第 22 页 共 29 页

管理人员工作号1管理信息姓名电话1密码图书号书名出版社编号图书数量供求借阅作者是否借出维护借书日期出版社借阅数量工作人员应归还日期借阅者属于身份性别最大借阅数编号工作号2联系人电话4所在地

借书号密码维护图书类型姓名电话2描述代码姓名密码电话3供应类别图3-7 基本ER图

第 23 页 共 29 页

概念结构设计所得的概念模型（即上面所得的ER图），是于任何一种DBMS的信息结构，与实现无关。

4.2逻辑结构设计

逻辑结构设计的任务是将概念结构设计阶段设计的ER图，转化为选用的DBMS所支持的数据模型相符的逻辑结构，形成逻辑模型。

基于关系数据模型的逻辑结构的设计一般分为三个步骤： ⑴ 概念模型(ER图)转换为关系数据模型 ⑵ 关系模型的规范化和优化 ⑶ 设计用户子模式

4.2.1 概念模型（ER图）转换为关系数据模型

概念模型向关系数据模型的转化就是将用ER图表示的实体、实体属性和实体间的联系转化为关系模式。具体而言就是转化为选定的DBMS支持的数据库对象。现在，绝大部分关系数据库管理系统（RDBMS）都支持表(Table)、列(Column)、视图(View)、主码(Primary Key)、外码(Foreign)、约束(Constraint)等数据库对象。

一般转换原则如下：

⑴ 一个实体转换为一个表（Table），则实体的属性转换为表的列（Column），实体的码转换为表的主键（Primary Key）。

⑵ 实体间的联系根据联系的类型，转换如下： ① 1:n的联系：

1:n的联系是比较普遍的联系，其转换比较直观。如：ER图中出版社和图书的关系是1:n的联系，转换成：

表：出版社（编号、联系人、所在地、电话、供应类别）； 表：图书（图书号、书名、出版社编号、数量、是否借出）。

图书表中增加了一个“出版社编号”属性，它是一个外码，是出版社的主码。转换规律是在n端的实体对应的表中增加属性，该属性是1端实体对应表的主码。

② 1:1的联系：

1:1联系是1:n联系的特例，两个实体分别转换成表后，只要在一个表中增加外码，一般在记录数较少的表中增加属性，作为外码，该属性是另一个表的主码。

③ m:n的联系：

通过引进一个新表来表达两个实体间多对多的联系，新表的主码由联系两端实体的主码组合而成，同时增加相关的联系属性。

如：在ER图中借阅者和图书的联系是m:n联系，转换成： 表：借阅者（借书号、姓名、性别、密码、电话号码）

表：图书（图书号、书名、出版社编号、作者、数量、是否借出）。 表：借阅表（借书号、图书号、借书日期、应归还日期、借阅数目）

新增表的“借阅表”中“借书号”和“图书号”组合为主码，分别是外码，其中“借书号”是借阅者表的主码，“图书号”是图书表的主码。同时增加了借阅相关的属性：借书日期、应归还日期、借阅数目。

第 24 页 共 29 页

故根据以上的转换原则以及转换过程的分析，可以由基本ER图转换出下面的初始关系数据库模式：

图书（图书号、书名、出版社编号、作者、数量、是否借出）。 借阅者（借书号、姓名、性别、密码、电话号码）

借阅表（借书号、图书号、借书日期、应归还日期、借阅数目） 出版社（编号、联系人、所在地、电话、供应类别） 供求关系表（出版社编号、图书编号） 身份（代码、描述、最大借阅数） 身份关系表（借书号、身份代码）

管理人员（工作号1、姓名、电话、密码） 管理关系表（管理人员编号、图书号）

工作人员（工作号2、 姓名、电话、维护图书类型、密码） 图书维护信息表（工作人员编号、图书号）

4.2.2关系模型的规范化与优化

关系模型的优化是为了进一步提高数据库的性能，适当地修改、调整关系模型结构。关系模型的优化通常以规范化理论为指导，其目的是消除各种数据库操作异常，提高查询效率，节省存储空间，方便数据库的管理。常用的方法包括规范化和分解：

1）. 规范化

规范化就是确定表中各个属性之间的数据依赖，并逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定属于哪种范式。根据需求分析的处理要求，分析是否合适从而进行分解。必须注意的是：并不是规范化程度越高的关系就越优，因为规范化越高的关系，连接运算越多，而连接运算的代价相当高。对于查询频繁而很少更新的表，可以是较低的规范化程度。

将两个或多个高范式通过自然连接，重新合并成一个较低的范式过程称为逆规范化。规范化和逆规范化是一对矛盾，何时进行规范化、何时进行逆规范化、进行到什么程度，在具体的应用环境中，需要设计者仔细分析和平衡。

2）. 分解

分解的目的是为了提高数据操作的效率和存储空间的利用率。常用的分解方式是水平分解和垂直分解。水平分解是指按一定的原则，将一个表横向分解成两个或多个表；垂直分解是通过模式分解，将一个表纵向分解成两个或多个表。垂直分解也是关系模式规范化的途径之一，同时，为了应用和安全的需要，垂直分解将经常一起使用的数据或机密的数据分离。当然，通过视图的方式可以达到同样的效果。

根据3NF的规范原则，可以将初始数据库关系模式规范化。由于3NF中不存在非主属性对码的传递依赖及部分依赖关系，分析以上所得关系模式，去掉不必要的部分表格，可得到以下具有3NF特性的关系模式：

图书（图书号、书名、出版社编号、作者、数量、是否借出） 借阅者（借书号、姓名、性别、身份代码、密码、电话号码） 借阅表（借书号、图书号、借书日期、应归还日期、借阅数目） 出版社（编号、联系人、所在地、电话、供应类别） 身份（代码、描述、最大借阅数）

管理人员（工作号1、姓名、电话、密码）

工作人员（工作号2、 姓名、电话、维护图书类型、密码）

第 25 页 共 29 页

4.2.3设计用户子模式

概念模型通过转换、优化后成为全局逻辑模型，还应该根据局部应用的需要，结合DBMS的特点，设计用户子模式。用户子模式也称为外模式，是全局逻辑模式的子集，是数据库用户（包括程序用户和最终用户）能够看见和使用的局部数据的逻辑结构和特征。

目前，关系数据库管理系统（RDBMS）一般都提供了视图（View）的概念，可以通过视图功能设计用户模式。此外也可以通过垂直分解的方式来实现。

定义用户模式的主要目的是： 1〉符合用户的使用习惯。

例如：客户在供应部门习惯称为供应商，在消除命名冲突时统一命名为客户。在用户模式设计时，可以设计一个供应商视图，一是要符合使用习惯，二是只仅仅包含提供物资的对象，而不包含销售的客户。

2〉为不同的用户级别提供不同的用户模式

保证数据的安全。有些数据，如企业产品的成本信息是企业比较重要的信息，只有部分用户才能查询和使用，客户一般不能查询，可以定义客户视图，屏蔽其中的成本信息，确保系统的安全。

3〉简化用户对系统的使用

某些查询是比较复杂的查询，为了方便用户使用，并保证查询结果的一致性，经常将这些复杂的查询定义为视图，大大简化了用户的使用。

在本系统中，管理人员的权限最大，他可以查看其他普通用户的所有信息，而像借阅者这样的普通用户，只能查阅自己的个人信息及图书信息，对于他们来说，其他用户的信息是不可见的。所以在设计外模式时，只需要对不同的用户开放不同范围的数据即可，对于该系统而言，不存在需要将已由关系模式拆分的情况，所以只需要根据各类用户对数据的可见范围作出相应的调整即可。具体来说即：所有数据对管理人员来说都是可见的，图书信息的数据对所有人可见，其余的个人信息只对除管理人员之外的个人可见。

4.3物理结构设计 4.3.1物理结构设计概述

物理结构设计的目的主要有两点：一是提高数据库的性能，满足用户的性能需求；二是有效地利用存储空间。总之，是为了使数据库系统在时间和空间上最优。

数据库的物理结构设计包括两个步骤：

⑴ 确定数据库的物理结构。在关系数据库中主要是存储结构和存储方法的确定； ⑵ 对物理结构进行评价，评价的重点是时间和空间的效率。 如果评价结果满足应用要求，则可进入到物理结构的实施阶段，否则要重新进行物理结构设计或修改物理结构设计，有的甚至返回到逻辑结构设计阶段，修改逻辑结构。

由于物理结构设计与具体的数据库管理系统有关，各种产品提供了不同的物理环境、存取方法和存储结构，能供设计人员使用的设计变量、参数范围都有很大差别，因此物理结构设计没有通用的方法。在进行物理设计前，注意以下几个方面的问题：

1〉. DBMS的特点

物理结构设计只能在特定的DBMS下进行，必须了解DBMS的特点，充分利用其提供的各

第 26 页 共 29 页

种手段，了解其条件。本次设计的小型图书馆信息管理系统是在WindowsXP支持下的MYSQL环境下开发运行的，具有功能强，使用简单，管理方便，运行速度快，可靠性高，安全保密等特点。

2〉.应用环境

特别是计算机系统的性能，数据库系统不仅与数据库设计有关，与计算机系统有关。比如：是单任务系统还是多任务系统，是单磁盘还是磁盘阵列，是数据库专用服务器还是多用途服务器等等。还要了解数据的使用频率，对于使用频率高的数据要优先考虑。此外，数据库的物理结构设计是一个不断完善的过程，开始只能是一个初步设计，在数据库系统运行过程中要不断检测并进行调整和优化。

对关系数据库的物理结构设计主要内容有： ⑴ 为关系模式选取存取方法

⑵ 设计关系及索引的物理存储结构

4.3.2 存取方法选择

数据库系统是多用户共享的系统，为了满足用户快速存取的要求，必须选择有效的存取方法。一般数据库系统中为关系、索引等数据库对象提供了多种存取方法，主要有索引方法、聚簇方法、HASH方法。

4.3.2.1．索引存取方法的选择

索引是数据库表的一个附加表，存储了建立索引列的值和对应的记录地址。查询数据时，先在索引中根据查询的条件值找到相关记录的地址，然后在表中存取对应的记录，所以能加快查询速度。但索引本身占用存储空间，索引是系统自维护的。B+树索引和位图索引是常用的两种索引。建立索引的一般原则是：

(1) 如果某属性或属性组经常出现在查询条件中，则考虑为该属性或属性组建立索引； (2) 如果某个属性经常作为最大值和最小值等聚集函数的参数，则考虑为该属性建立索引；

(3) 如果某属性和属性组经常出现在连接操作的连接条件中，则考虑为该属性或属性组建立索引；

当然，并不是索引定义越多越好。一是索引本身占用磁盘空间；二是系统为索引的维护要付出代价，特别是对于更新频繁的表，索引不能定义太多。而本系统中并不打算采用索引存取的方法，因为对于本次开发的信息系统来说，表格不是很多也不是很繁琐，如果用索引存取方法的话，势必会各系统带来额外的负担，得不偿失。

4.3.2.2．聚簇存取方法的选择

在关系数据库管理系统（RDBMS）中，连接查询是影响系统性能的重要因素之一，为了改善连接查询的性能，很多RDBMS提供了聚簇存取方法。

聚簇主要思想是：将经常进行连接操作的两个和多个数据表，按连接属性(聚簇码)相同的值存放在一起，从而大大提高连接操作的效率。一个数据库中可以建立很多簇，但一个表只能加入一个聚簇中。

第 27 页 共 29 页

设计聚簇的原则是：

(1) 经常在一起连接操作的表，考虑存放在一个聚簇中；

(2) 在聚簇中的表，主要用来查询的静态表，而不是频繁更新的表。

4.3.2.3. HASH存取方法的选择

有些数据库管理系统提供了HASH存取方法。HASH存取方法的主要原理是，根据查询条件的值，按HASH函数计算查询记录的地址，减少了数据存取的I/O次数，加快了存取速度。并不是所有的表都适合HASH存取，选择HASH方法的原则是：

(1) 主要是用于查询的表（静态表），而不是经常更新的表； (2) 作为查询条件列的值域（散列键值），具有比较均匀的数值分布； (3) 查询条件是相等比较，而不是范围（大于或等于比较）。

4.3.3 存储结构的确定

确定数据库的存储结构，主要是数据库中数据的存放位置，合理设置系统参数。数据库中的数据主要是指表、索引、聚簇、日志、备份等数据。存储结构选择的主要原则是：数据存取时间上的高效性、存储空间的利用率、存储数据的安全性。

4.3.3.1. 存放位置

在确定数据存放位置之前，要将数据中易变部分和稳定部分进行适当的分离，并分开存放；要将数据库管理系统文件和数据库文件分开。如果系统采用多个磁盘和磁盘阵列，将表和索引存放在不同的磁盘上，查询时，由于两个驱动器并行工作，可以提高I/O读写速度。为了系统的安全性，一般将日志文件和重要的系统文件存放在多个磁盘上,互为备份。另外，数据库文件和日志文件的备份，由于数据量大，并且只在数据库恢复时使用，所以一般存储在磁带上。

4.3.3.2. 系统配置

DBMS产品一般都提供了大量的系统配置参数，供数据库设计人员和DBA进行数据库的物理结构设计和优化。如：用户数、缓冲区、内存分配、物理块的大小等等。一般在建立数据库时，系统都提供了默认参数，但是默认参数不一定适合每一个应用环境，要做适当的调整。此外，在物理结构设计阶段设计的参数，只是初步的，要在系统运行阶段根据实际情况进一步进行调整和优化。

根据以上原则以及课上数据库系统设计的理论，暂定本系统的物理结构采用最简单常用的方式，关系存取方法采用索引方法，稀疏索引应该就可以解决；而数据库的存储结构方面，因为所开发的该系统明显属于小型的信息管理系统，因此可以直接将数据和日志备份等存储在磁盘上即可。当然物理存储方面还会再后续开发过程中根据实际情况有些许改动，但都会在DBMS允许范围内作改动，不会有太大差距。

第 28 页 共 29 页

5开发总结

本系统是我们运用数据库课程所学知识结合了Java与软件工程的一些知识与理念而进行开发设计的，虽然不知道最后会不会如我们所设计的这样实现一个完美的信息系统，但设计这个过程已经让我们将课内知识加以深化变为了有用的自己的东西。

本系统采取结构化的“自下而上”的系统开发策略与原型开发方法相结合的开发方法。首先按照结构化系统开发策略对系统进行分析和操作做出一个基本符合实际应用的图书馆操作系统，再根据原形法的操作方式对图书馆管理信息系统进行模拟测试、发现问题、进行设计编程修改、完善系统。

它将采用Java集成开发环境和MySQL数据库进行连接操作，具有开发时间短，成本低，而且数据量的传输快等优点。

同时，由于开发者水平的，也会存在一些错误，我们将会在系统的应用过程中发现问题并尽可能的解决相应的问题，使该系统得到进一步完善，为我们第一次的数据库应用课程画上一个的句号。

第 29 页 共 29 页