关键词 图书 网络 管理系统 数据库
1 引言
一直以来人们使用传统的人工方式管理图书馆的日常工作，对于图书馆的借书和还书过程，想必大家都已很熟悉。在计算机尚未在图书馆广泛使用之前，借书和还书过程主要依靠手工。一个最典型的手工处理还书过程就是：读者将要借的书和借阅证交给工作人员，工作人员将每本书上附带的描述书的信息的卡片和读者的借阅证放在一个小格栏里，并在借阅证和每本书贴的借阅条上填写借阅信息。这样借书过程就完成了。还书时，读者将要还的书交给工作人员，工作人员根据图书信息找到相应的书卡和借阅证，并填好相应的还书信息，这样还书过程就完成了。
以上所描述的手工过程的不足之处显而易见，首先处理借书、还书业务流程的效率很低，其次处理能力比较低，一段时间内，所能服务的读者人数是有限的。利用计算机来处理这些流程无疑会极大程度地提高效率和处理能力。我们将会看到排队等候借书、还书的队伍不再那么长，工作人员出错的概率也小了，读者可以花更多的时间在选择书和看书上。
为方便对图书馆书籍、读者资料、借还书等进行高效的管理，特编写该程序以提高图书馆的管理效率。使用该程序之后，工作人员可以查询某位读者、某种图书的借阅情况，还可以对当前图书借阅情况进行一些统计，给出统计表格，以便全面掌握图书的流通情况。
本次作业设计题目：“图书管理系统”主要目的是利用数据库软件编制一个管理软件，用以实现图书、读者以及日常工作等多项管理。同时对整个系统的分析、设计过程给出一个完整论证。
图书管理系统是一种基于集中统一规划的数据库数据管理新模式。在对图书、读者的管理，其实是对图书、读者数据的管理。本系统的建成无疑会为管理者对图书管理系统提供极大的帮助。
2 系统设计
2.1 系统指导思想和建设目标
2.1.1 系统指导思想
立足于校园实际，着眼于未来发展，建成符合标准化协议、通用性较强、实用的系统，以提高图书信息的现代化管理水平，实现信息资源的共享。
2.1.1 系统建设目标
（1）要解决的问题：（以某学校为参照） 随着办公自动化水平的不断提高，现在学校管理学生信息也逐步从手工转到计算机自动化信息处理阶段。设计一个功能完整、 *** 作简便、界面友好的学生信息管理系统已经是势在必行的了。
（2）系统开发的目的：提高图书管理工作的效率，减少相关人员的工作量，使学校的图书管理工作真正做到科学、合理的规划，系统、高效的实施。
（3）系统名称：图书管理系统
2.2 总体功能设计
系统要能实现如下功能：
l 登录系统：注销用户、系统退出。
l 管理：用户管理、图书管理、读者管理、借阅管理。
l 查询：图书查询、读者查询、借阅查询。
l 报表打印：所有图书、借出图书、库存图书、所有读者。
l 帮助：使用说明、关于。
3 数据库设计
3.1 数据库系统的选择
本系统是一个中小型管理系统，运行环境是Windows2000 server，因此使用Windows环境下最容易使用且功能还可以的Microsoft Access 2000 作为后台的数据库系统。
3.2 需求分析
图3 图书流通数据流图
1．2
判断能
否借书
索书
信息
读 者
1．2
办理借
书手续
读者信息
查询结果
借书申请
被借图书
借书结果
借书信息
被借图书复本量
(b) 借书
借阅
3
读者
1
图书
5
1．1
图书
查询
借书信息
查询
4
判断
2
判断结果
索书
信息
图书信息
读 者
1
借书
2
还书
读 者
申请借书
还书申请
借书结果
还书结果
(a) 顶层数据流图
3
办借
书证
读者信息
办证信息
需求分析是数据库设计首先要做的工作，通过需求分析，我们作出了图书管理系统的各层数据流图，图3是图书流通数据流图（图中省略了“还书”和“办理借书证”的数据流图）。
在数据流图的基础上，定义数据字典。数据字典是关于数据库中数据的描述，它的作用是在软件分析和设计过程中为有关人员提供关于数据描述信息的查询，以保证数据的一致性。下面在图3的基础上举例说明数据字典的定义。
图3中涉及很多数据项，其中数据项“读者编号”可以描述如下：
数据项名：读者编号
别名：读者条码
含义：唯一标识每个读者
类型：字符型
取值范围：00000000至99999999
取值含义：顺序编号
“读者”一个数据结构，它可以描述如下：
数据结构名：读者
含义说明：是图书管理系统的数据结构之一，定义了一个读者的有关信息
组成：读者编号，姓名，性别，单位
数据流“借阅记录”可描述如下：
数据流名：借阅记录
说明：读者的借书记录
数据来源：办理借阅手续
数据去向：借阅
数据结构：读者编号、图书馆藏号、借阅日期
数据存储“借阅”可以描述如下：
数据存储名：借阅
说明：记录读者的借书情况
流出数据流：借阅记录
流入数据流：借阅记录
数据描述：读者编号、图书馆藏号、借阅日期
数据量：每年5000条以上
存取方式：随机存取
处理过程“判断能否借书”可描述如下：
处理过程“判断能否借书”
说明：根据读者的已借书情况可被借图书的馆藏情况判断读者能否借书
输入：借阅记录、读者信息、被借图书信息
输出：能否借书的标志
处理：读者提出借书请求后，先判断该读者以前的借书量是否达到了10本，如果达到了10本，则不能再借书，如果没有达到10本，则再判断读者要借的图书的可借量是否为0，如果不为0，则该书可以借出。
3.3 数据库设计
在图书管理系统中，数据库设计占重要位置，数据库设计质量的优劣，可直接影响到数据库数据的冗余度、数据的一致性、数据丢失等问题。下面就系统数据库规范化设计进行说明。
3.3.1 数据库设计的理论指导
数据库设计的理论指导是范式理论，其主要内容如下：
1）如果关系模式R，其所有的域为单纯域则称R是规范化的关系，或称第一范式 (1NF)
2）如果关系模式R为第一范式，且每个非主属性完全函数依赖于码，则模式R为第二范式（2NF）。
3) 如果关系模式R为第二范式，且每个非主属性非传递依赖于码，则称关系模式R为第三范式(3NF)。
4)关系模式R为第一范式，满足函数依赖集合F，X和A均为R的属性集合，且X不包含A，如果R满足X－>A且X必包含R的码，称关系模式R为BCNF范式。
3.3.2 数据库设计
图书管理系统数据库常常要设计含有如下数据项：借书证号、姓名、单位、馆藏号(馆藏号为每本书上的条形码号)、书名、分类号、作者、价格等。如何进行模式的设计呢？下面以图书流通模块所涉及的数据库为例来说明。
图 书
读 者
借阅
m
n
借阅时间
馆藏号
书名
分类号
作者
价格
借书证号
姓名
性别
图4 图书流通的E-R图
属于
单 位
1
n
单位名称
单位编号
先设计图书流通的实体－关系图(E-R图)。E-R图由3个相关联的部分构成，即实体、实体与实体之间的关系以及实体和关系的属性。图书流通过程中实体“图书”与“读者”之间的关系是借阅和被借阅的关系，实体“读者”与“单位”之间的关系是属于和被属于的关系，“图书”的属性有“馆藏号”、“书名”、“分类号”、“作者”、“价格”，“读者”的属性有“借书证号”、“姓名”、“性别”，“单位”的属性有“单位编号”和“单位名称”，“借阅”属性“借书日期”，由此得出E-R图如图4。
从图中可以知道：
①“借书证号”是唯一的，所以“借书证号”决定“姓名”，每位读者应只属于一个性别，所以“借书证号”也决定“性别”；
②“馆藏号”是唯一的，所以“馆藏号”决定“书名”、“分类号”、“作者”、“价格”；
③ “单位编号”是唯一的，所以“单位编号”决定“单位名称”；
④ 每位读者在一个时间只能借一本书，所以“借书证号” +“馆藏号”决定“借阅时间”。
如果将这些数据项置于一个关系模式中，根据范式理论，该关系模式属于1NF（第一范式），它存在删除异常和冗余等问题，不是理想的模式，因此要把它分解成满足3NF或BCNF的关系模式。根据范式理论和E-R图转换成关系模型的规则，上面的E-R图可转换为4个关系模式：①图书（馆藏号、书名、分类号、作者、价格）；②读者（借书证号、姓名、性别、单位编号）；③借阅（借书证号、馆藏号、借阅时间），④单位(单位编码、单位名称)，其中打下划线的为码，这样就解决了插入、删除和数据冗余等问题。
我们对数据的结构进行详细的分析，按照上述的设计思想，共设计了读者表，书目表，馆藏表，流通表等百余张数据表，然后创建视图和存储过程。下面举例说明：
读者表：借书证号、姓名、单位、读者类别、职称等字段；
书目表：馆藏号、ISBN、题名、作者、出版社、复本数、语种、文献类型、版次等字段；
馆藏表：馆藏号、索书号、分类号、种次号、馆藏位置、单价、出版日期等字段；
流通表：借书证号、馆藏号、借期、还期、续借、应还期、 *** 作员等字段；
借阅规则表：读者类别编码、图书类别编码、限借册数、每期天数、续借天数、过期日期、罚金等字段。
读者类别表：读者类别编码、读者类别等字段。
图书类别表：图书类别编码、图书类别等字段。
3.4 数据库索引
建立索引是加快查询速度的有效手段，数据库的每一个表建立了主键，主键由一个或几个字段组成，每一个表都按主键建立了索引，部分表为了满足查询和排序的需要，除建立主索引外，还建立了次索引。例如在查询时要用到“馆藏号”、“作者”、“题名”等条件来查找图书，因此，在书目表上除了对主键“馆藏号”建立了主索引外，也对“作者”、“书名”等建立了次索引。
3.5 视图
视图是从一个或几个基本表导出的表，它是定义在基本表之上的，它是一个虚表，数据库中只存放视图的定义，而不存放视图对应的数据，数据仍然存放在原来的基本表中。通过定义视图，可以使用户眼中的数据库结构简单、清晰，并可以简化用户的数据查询 *** 作。由于本系统数据表较多，表中的字段多，为了简化对表的 *** 作，我们创建了图书_按书名查询、期刊_按刊名查询、期刊_按编辑部查询、借阅规则查询、待还书查询、超期记录查询等30余个视图。
3.6 存储过程
存储过程是一段经过编译的程序代码，存放在数据库服务器端。通过调用适当的存储过程，可在服务器端处理大量数据，再将处理结果送到客户端。这样可减少数据在网络上的传送，消除网络阻塞现象；例如：要查询某条记录，若该记录在表中的顺序号是10000，不采用存储过程，服务器将从1至于10000条记录数据逐条送至客户端，采用存储过程后，由于过程是经过编译的并且是在本地，不需要通过网络，因此能很快查出所需记录并将结果送到客户端，大大减少了网上数据传输量。存储过程另一好处是可供不同的开发工具调用，如PB、VB、ASP、Delphi等开发工具均可调用。在流通模块和WEB查询模块上均有图书检索功能，实际上调用同一存储过程完成的。本系统建立了60多个存储过程，实现诸如借还书处理、新书入库统计、编目入馆藏、读者统计、生成索书号等功能。
3.7 数据库调用
采用ODBC接口实现数据库的调用，采用ADO接口调用。
4 条形码的使用
条形码具有唯一性和一次输入后就可反复使用的优点，利用条形码技术作为信息快速输入的手段可迅速且不易发生错误地处理图书管理业务。本系统使用条形码作为图书和读者的标识，实现标识的唯一性。
使用条码后，能够使图书管理工作更加简单、快捷、不易出错。例如，当一本书具有唯一条形码标识，每位读者也具有唯一条形码标识时，图书的借阅、查询就十分便捷了。应用条形码取代了以往填写书袋卡、借书证，核对借阅时间等繁琐的手工劳动。读者在借书时只要将借书证给工作人员，工作人员只需登录借书系统，用条形码阅读器扫描读者借书证上的条形码，屏幕就会显示出该读者的信息，包括读者姓名、单位、可借几本书、已借几本书、是否过期、有无罚款等。如可以借书，工作人员只需用条形码阅读器扫描该读者所需借的书上的条形码符号后，该书的书名和条形码等信息都从数据库中调出显示在屏幕上，自动记录在该读者的借阅档案中，借书工作即告完成。一般借一本书仅需 1至 2秒钟。 *** 作完后，计算机自动地将该借阅者和借阅的图书号码输入对应数据库中，并自动提示借阅期限。
参考文献
[1] 王珊著、数据库系统原理教程，清华大学出版社，2002.1
[2] 齐治昌等著、软件工程，高等教育出版社，2002.1
[3] 网络资源
1、准备项目计划书。项目计划书是医院信息系统实施过程中第一个最重要的文件。它勾画了医院要建设的医院信息系统总轮廓。通常是委托一家咨询公司完成一份项目计划书的标书，该标书的内容为医院准备建设医院信息系统的动机和全面、具体、细致的需求。
然后将标书发给参加竞标的厂商，在收到各厂商的计划书后，进行认真的评价，决定最终执行方案。
2、选择软硬件的集成商、供应商和合作伙伴，通常委托有资质的咨询公司或特别的专家小组进行方案评估。
3、需求分析。首先通过对目标医院使用者的访问、调查，详细了解用户的流程与需求，最后形成文档：《项目结构》文档、《目标范围说明书》文档、《用户需求说明书》文档、初步的《用户界面说明书》文档、《测试战略》文档、《测试规范与通过标准》文档。
4、系统设计与软件客户化。设计阶段要做的工作：把用户的需求变成技术上可实现的步骤；完善用户界面演示程序，让用户完全接受系统的界面形式；制订《客户沟通计划》，收集和控制用户需求；完成《功能规格说明书》的签署并冻结。
初步完成《测试规格》文档；风险评估。要完成的文档：《用户界面说明书》、《概念设计》、《逻辑设计》、《物理设计》、《功能规格说明书》、《测试计划和时间表》、《测试规格》文档和大部分的《测试用例》文档、《项目时间表》。
5、数据准备与装入。数据准备是指将医院的基础数据按照系统的要求统一、规范、格式化的表达出来，并录人系统基础数据库。这些是系统赖以正常运作的基础。
6、系统测试。在系统测试阶段要做的工作：代码错误修改；进行ALPHA测试、BETA测试和RELEASE测试；继续保持与客户/用户的紧密联系，控制用户的期望值；编写联机帮助和用户使用手册；进行用户培训和项目验收；风险评估。
要完成的文档：《用户 *** 作手册》、《实施维护手册》、《测试报告》、《验收报告》、《联机帮助》。阶段到达标准后进行审核。
7、用户培训。供应商应该有事先安排好的计划，专门的教师与教材，要准备设备完善的培训教室和环境。对用户的培训可以为对医院计算机技术人员的培训和对最终用户的培训。
面向对象软件设计说明书模板1 概述
1.1 系统简述
对系统要完成什么，所面向的用户以及系统运行的环境的简短描述，这部分主要来源于需求说明书的开始部分。
1.2 软件设计目标
这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。
1.3 参考资料
列出本文档中所引用的参考资料。（至少要引用需求规格说明书）
1.4 修订版本记录
列出本文档修改的历史纪录。必须指明修改的内容、日期以及修改人。
2 术语表
对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。
3 用例
此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。
4 设计概述
4.1 简述
这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）
4.2 系统结构设计
这部分要求提供高层系统结构的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。
4.2.1 顶层系统结构
4.2.2 子系统1结构
4.2.3 子系统2结构
4.3 系统界面
各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。
4.4 约束和假定
描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。
实现的语言和平台也会对系统有约束，同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。
5 对象模型
5.1 系统对象模型
提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。
对象图应该包含什么呢？
在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多，0..1，*，1..*）。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。
可能经过多次反复之后才能得到系统的正确的对象模型。
6 对象描述
在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。
为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。
对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。
对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。
6.1 子系统1中的对象
6.1.1 对象：对象1
用途：
约束：
持久性：
6.1.1.1 属性描述：
1. 属性：属性1
类型：
描述：
约束：
2. 属性：属性2
6.1.1.2 方法描述：
1. 方法：方法1
返回类型：
参数：
返回值：
Pre-Condition：
Post-Condition：
读取/修改的属性：
调用的方法：
处理逻辑：
测试例：用什么参数调用该方法，期望的输出是什么……
7 动态模型
这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图和状态图。
确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。
7.1 场景（Scenarios）
对每个场景做一则条目，包括以下内容：
场景名：给它一个可以望文生义的名字
场景描述：简要叙述场景是干什么的以及发生的动作的顺序。
顺序图：描述各种事件及事件发生的相对时间顺序。
7.1.1 场景：场景1
描述：
动作1
动作2
7.2 状态图
这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。
7.2.1 状态图1：
8 非功能性需求
在这个部分，必须说明如何处理需求文档中指定的非功能性需求。尽可能客观地评估系统应付每一个非功能性的需求的能力程度。如果某些非功能性需求没有完全在设计的系统中实现，请务必在此说明。另外，你也需要对系统将来的进化作一个估计并描述本设计如何使系统能够适应这些可预见的变化。
9 辅助文档
提供能帮助理解设计的相应文档。
10 词汇索引
文章录入
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）