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

图书馆信息管理系统设计报告项目小组成员：35060602 石洁冰35060603 张 慧目 录1.引言41.1开发背景41.2 开发工具41.3系统运行环境41.4 参考资料41.5 数据库设计的步骤52.可行性研究报告52.1可行性研究的前提52.1.1系统开发要求62.1.2 目标62.1.3条件、假设和限定62.2 可行性研究结果72.2.1管理上的可行性72.2.2 技术上的可行性72.2.373 .需求分析报告83.1 需求分析的任务83.1.1. 信息需求83.1.2. 处理需求83.1.3. 性能需求83.2 需求收集93.2.1 调查用户组成情况93.2.2 调查各个用户的系统利用情况93.2.3. 明确新系统的要求93.3 需求分析93.3.1基本功能需求分析103.3.2系统实现数据流图133.3.3数据元素表163.3.4数据字典184.图书馆信息管理系统的数据库设计194.1 概念结构设计（ER图设计）194.1.1设计局部分ER图194.1.2合并分ER图，生成初步ER图224.1.3消除不必要的冗余，设计基本ER图244.2逻辑结构设计264.2.1 概念模型（ER图）转换为关系数据模型264.2.2关系模型的规范化与优化274.2.3设计用户子模式284.3物理结构设计284.3.1物理结构设计概述284.3.2 存取方法选择294.3.3 存储结构的确定305开发总结311.引言1.1开发背景随着计算机技术的发展以及计算机网络的逐渐普及，英特网成为人们查找信息的重要场所。二十一世纪是信息的时代，所以信息的交换和信息流通显得特别重要。因此，图书馆使用计算机来管理成为必然。建立管理信息系统是一个很好的解决办法，因为随着社会生产力的迅速发展和科学技术的突飞猛进，一个集计算机技术、通迅技术、数据库技术、信息技术、现代管理理论为一体的系统开发方法已经逐渐成熟，我们完全能够结合自己的实际情况开发出实用的管理信息系统，来指导我们的学习。为此，我们通过自主开发这一图书馆信息管理系统，达到提高工作效率的目的。1.2 开发工具本系统主要利用NetBeans作前端的应用开发工具，利用java语言实现相应的功能，利用Mysql5.0作为 后台的数据库，利用WindowsXP作为系统平台。1.3系统运行环境本系统的运行环境是中文版win32平台上运行。1.4 参考资料 1萨师暄，王珊 数据库系统概论， 第四版， 高等教育出版社。2李建中，王珊编著，数据库系统原理，电子工业出版社，1998年。3相关数据库管理系统手册。4图书馆信息管理系统开发工具手册.doc(数据库大作业要求)。5. 求是科技编著,Java信息管理系统开发,人民邮电出版社，2005年。6.sun公司网站。1.5 数据库设计的步骤需求分析概念结构设计逻辑结构设计物理结构设计实施和维护需求说明概念模型逻辑模型物理模式数据库图1-1数据库设计步骤示意图数据库的设计按规范化设计方法，划分为五个阶段(图1-1)，每个阶段有相应的成果：2.可行性研究报告2.1可行性研究的前提当今时代是飞速发展的信息时代。在各行各业中离不开信息处理，这正是计算机被广泛应用于信息管理系统的环境。计算机的最大好处在于利用它能够进行信息管理，使用计算机进行信息控制，不仅提高了工作效率，而且大大的提高了其安全性。尤其对于复杂的信息管理，计算机能够充分发挥它的优越性。计算机进行信息管理与信息管理系统的开发密切相关，系统的开发是系统管理的前提。而图书馆信息管理系统则是这类信息管理系统的典型代表，对于我们这类具有实验性质的实践项目来说是最合适不过的了。图书馆作为一种信息资源的集散地，图书和用户借阅资料繁多，包含很多的信息数据的管理，现今，有很多的图书馆都是初步开始使用，甚至尚未使用计算机进行信息管理。根据调查得知，他们以前对信息管理的主要方式是基于文本、表格等纸介质的手工处理，对于图书借阅情况（如借书天数、超过限定借书时间的天数）的统计和核实等往往采用对借书卡的人工检查进行，对借阅者的借阅权限、以及借阅天数等用人工计算、手抄进行。数据信息处理工作量大，容易出错；由于数据繁多，容易丢失，且不易查找。总的来说，缺乏系统，规范的信息管理手段。尽管有的图书馆有计算机，但是尚未用于信息管理，没有发挥它的效力，资源闲置比较突出，这就是管理信息系统的开发的基本环境。数据处理手工操作，工作量大，出错率高，出错后不易更改。图书馆采取手工方式对图书借阅情况进行人工管理，由于信息比较多，图书借阅信息的管理工作混乱而又复杂；一般借阅情况是记录在借书证上，图书的数目和内容记录在文件中，图书馆的工作人员和管理员也只是当时对它比较清楚，时间一长，如再要进行查询，就得在众多的资料中翻阅、查找了，造成查询费时、费力。如要对很长时间以前的图书进行更改就更加困难了。 基于这众多的问题，有必要建立一个图书管理系统，使图书管理工作规范化，系统化，程序化，避免图书管理的随意性，提高信息处理的速度和准确性，能够及时、准确、有效的查询和修改图书情况。2.1.1系统开发要求小型图书信息管理系统需实现功能：力求通过本系统，1图书馆工作人员对自己的个人资料进行编辑，查询图书的借阅情况从而更有利于系统工作人员维护图书的安全性。2读者通过登陆、对自己的个人信息进行编辑，并且查询书籍的基本情况。3管理人员对图书馆工作人员及书籍的信息进行添加和删除。4出版社通过登陆查询所供应图书的借阅情况以及提供新书的基本信息。2.1.2 目标A. 通过数字化，使图书馆工作所需人力减少；B. 提高图书馆信息管理系统的响应速度；C. 加快相关信息的流动速度，提高效率；D. 通过实际的工程实践，使我们对数据库的认识水平提高，完成课程要求。2.1.3条件、假设和限定A. 由于本项目的实验性质，没有投资方。B. 系统必须运行在Win32平台上。C. 存在权限控制机制，只有管理员才能删除出版商和工作人员账号。2.2 可行性研究结果2.2.1管理上的可行性 这个开发是我们作为数据库课程实践的一项应用工程，任课老师对此十分的重视.希望在课程规定时间内将该数据库系统开发出来，当然如能投入使用更好，以使我们在巩固课堂所学理论知识的基础上对实践有所了解，对图书馆管理的数字化及现代化能起到一些创新促进作用。虽然如今一些大型的图书馆管理系统基本上已经很先进了，但作为信息管理系统的代表，这次的小型图书馆信息管理系统的开发对本科学生数据库理论的实践还是有一定帮助的，因此这个系统在管理上是可行的。2.2.2 技术上的可行性 本次图书馆管理信息系统的开发根据本学期软件工程课程的一些基本要求，使用传统的生命周期法，即给管理信息系统的开发定义一个过程，对其每一个阶段规定它的任务，工作流程，管理目标以及要编制的文档等，使开发工作易于管理和控制，形成一个可操作的规范。 同时，系统需要对数据库的灵活和快捷的操作，因此强大的SQL语言是开发此类数据库系统的最佳选择。NetBeans本身所携带的面向对象程序的开发界面，以及对SQL的支持，符合本系统的开发需求。 正确的理论指导和优秀的开发工具，双重保证了我们这次开发的技术可行性。2.2.3经济上的可行性 首先，从经济效益上讲，而本系统的开发，为统计人员工作效率带来了一个质的飞跃：第一，本系统的运行可以代替人工进行许多繁杂的劳动；第二，本系统的运行可以节省许多资源；第三，本系统的运行可以大大的提高统计人员的工作效率； 其次是，从所需投入来讲，对于一个中小型的图书馆管理系统来说，它的投资成本是十分的低的，应该不会超过5000元。当然，对于我们作为课程设计的系统实现来说，投资成本基本上不用考虑，而一旦开发成功，即可以在此基础上添加外部设备，用于Internet服务，甚至会带来意料之外的收益。而对我们来说，此系统的开发给了我们实践的机会，数据库对我们来说不再只是书本上简简单单的三个字，而是能完成某个功能的可用之物，加深了我们对书本知识的理解和掌握，这是我们另一项收益，无论开发是否完美无缺，这项收益都是存在的，而且是最重要的。 所以，此系统在经济上也是可行的。3 .需求分析报告根据软件工程课程所学以及国标的部分模版，需求分析就是收集、分析用户的需求，是数据库设计过程的起点，也是后续步骤的基础。只有准确地获取用户需求，才能设计出优秀的数据库。本节主要介绍需求分析的任务、过程、方法，以及需求分析的结果。3.1 需求分析的任务需求分析的任务是通过详细调查，获取原有手工系统的工作过程和业务处理，明确用户的各种需求，确定新系统的功能。在用户需求分析中，除了充分考虑现有系统的需求外，还要充分考虑系统将来可能的扩充和修改，从开始就让系统具有扩展性。调查的重点是信息及处理，信息是数据库设计的依据，处理是系统处理的依据。用户需求主要有一下几个方面：3.1.1. 信息需求指用户从数据库中需要哪些数据，这些数据的性质是什么，数据从哪儿来。由信息要求导出数据要求，从而确定数据库中需要存储哪些数据。本系统数据性质比较单一，即CHAR类和FLOAT类即能满足需求，数据库中所存储信息皆来自对该系统未来用户的调查，由系统管理员集中录入即可。当然在本次用来做系统演示的数据库中存入的数据只是为求简便而编纂的一些无意义数据，仅供实验用。3.1.2. 处理需求指用户完成哪些处理，处理的对象是什么，处理的方法和规则，处理有什么要求，如：是联机处理还是批处理？处理周期多长？处理量多大？本系统中用户分了四种，即借阅者、工作人员、管理人员和图书出版社，所需处理信息无非图书信息或者个人的基本信息，要求不高，处理量根据所应用的图书馆的规模大小而有很大的区别。本次演示中所需处理的信息只涉及下文中所列出的六个表格中的信息，信息量不大。3.1.3. 性能需求指用户对新系统性能的要求，如系统的响应时间、系统的容量，以及一些其它属性，如：保密性、可靠性等等。确定用户的需求是比较困难的事情，特别是大型数据库设计，这是因为： 大部分用户缺少计算机知识，不知道计算机究竟能做什么而不能做什么，因而不能准确的表达自己的需求； 数据库设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求； 用户的需求可能是变化的。导致需求变化的因素很多，如：内部结构的调整、管理体制的改变、市场需求的变化等等； 人员的变化可能引起用户需求的变化，由于个人对具体系统的期望不一致，导致人员的变化引起需求的变化。需求分析可以划分为需求收集和需求分析两个阶段，但是这两个阶段没有明确的界限，可能交叉或同时进行。在需求收集时，进行初步需求分析；在需求分析时，对需求不明确之处要进一步收集。3.2 需求收集进行需求分析，首先要进行需求收集，需求收集的主要途径是用户调查，用户调查就是调查用户，了解需求，与用户达成共识，然后分析和表达用户需求。用户调查的具体内容有:3.2.1 调查用户组成情况该系统为小型图书馆信息管理系统，用户主要分为四类：图书借阅者、图书出版社、图书馆工作人员以及系统管理人员，对于小型的管理系统来说，用户类型与数量都不是很大，所以比较容易满足用户对该系统的需求。3.2.2 调查各个用户的系统利用情况一般包括各个用户使用哪些输入数据，输入数据从哪些地方来，输入数据的格式和含义；用户进行什么加工处理，处理的方法和规则及输出哪些数据，输出到什么部门，输出数据的格式和含义。在本系统中，四类用户都需要通过登陆界面进入系统。图书借阅者可以输入自己的号码及密码进入，查看自己的图书借阅情况以及更新个人信息；图书出版社需要输入姓名及代码，只要两者匹配即可登陆，查看馆藏书借阅情况并可发布图书供应信息；图书馆工作人员需要工作证号及密码登陆，进行借书及还书一系列操作，并可以修改读者借阅情况；而该系统管理人员通过密码进入后可对图书情况及其他用户的信息的基本情况进行更新等操作，是权限最大的用户。 3.2.3. 明确新系统的要求和用户一起，帮助用户确定新系统的各种要求，对于计算机不能实现的功能，要耐心地作解释工作。3.3 需求分析通过用户调查，收集用户需求后，要对用户需求进行分析，并表达用户的需求。用户需求分析的方法很多，可以采用结构化分析方法、面向对象分析方法等，本章采用结构化分析方法。结构化分析方法（Structured Analysis 简称SA方法）采用自顶向下、逐层分解的方法进行需求分析，从最上层的组织机构入手，逐步分解。结构化分析方法主要采用数据流图对用户需求进行分析，用数据字典和加工说明对数据流图进行补充和说明。数据流图（Data Flow Diagram，DFD），数据流描述系统中数据流动的过程，反映的是加工处理的对象。其主要成分有四种：数据流、数据存储、加工、数据的源点和终点。数据流用箭头表示，箭头方向表示数据流向，箭头上标明数据流的名称，数据流由数据项组成。数据存储用来保存数据流，可以是暂时的，也可以是永久的，用双划线表示，并标明数据储的名称。数据流可以从数据存储流入或流出，可以不标明数据流名。加工是对数据进行处理的单元，用园角矩形表示，并在其内标明加工名称。数据的源点和终点表示数据的来源和去处，代表系统外部的数据，用方框表示。对于复杂系统，一张数据流图难以描述和难以理解，往往采用分层数据流图。（本系统数据流图将在3.2.2部分中给出，图3-2给出了本系统基本的数据流图，图3-3和3-4是为了更清楚地说明系统中两个比较繁琐的数据处理环节即查询及图书信息处理环节的数据流程二做出的一些简要说明）数据字典（Data Dictionary ，DD）是关于数据信息的集合，它对数据流图中的数据进行定义和说明，主要有数据项、数据流、数据存储。DD可以采用卡片形式。（本系统中设计的数据信息的定义及说明皆在3.3.4部分的“数据字典”部分中给出了详细说明，若在程序实现部分对变量名称有任何不明了之处可查阅给出的数据字典）3.3.1基本功能需求分析图书馆信息管理涉及图书信息、系统用户信息、读者信息、图书借阅等多种数据管理, 从管理的角度可将该信息管理系统分为五大模块：图书管理人员维护模块、图书馆工作人员借阅处理模块、图书信息模块、读者信息操作模块以及图书出版社操作模块，如下图所示：图书馆信息管理系统图书管理人员维护模块图书馆工作人员借阅处理模块读者信息操作模块图书供应商操作模块图书信息模块图31模块信息其中的图书信息管理包括图书征定、借还、查询等操作，系统用户管理包括系统用户类别和用户数据管理，读者数据管理包括读者类别管理和个人数据的录入、修改和删除，图书出版社管理包括供应信息管理以及出版社联系人个人信息管理等。经过实际考察与分析，图书管理系统主要应具有以下功能： 1、图书借阅者的需求是查询图书室所存的图书、个人借阅情况及个人信息的修改。图书借阅者可直接查看图书馆图书情况，如果图书借阅者根据本人借书证号和密码登录系统，还可以进行本人借书情况的查询和维护部分个人信息。当然，一般情况下，图书借阅者只应该查询和维护本人的借书情况和个人信息，若查询和维护其他借阅者的借书情况和个人信息，就要知道其他图书借阅者的借书证号和密码。这些是很难得到的，特别是密码，所以不但满足了图书借阅者的要求，还保护了图书借阅者的个人隐私。2、图书馆工作人员对图书借阅者的借阅及还书要求进行操作，同时形成借书或还书报表给借阅者查看确认。图书馆工作人员有修改图书借阅者借书和还书记录的权限，所以需对工作人员登陆本模块进行更多的考虑。在此模块中，图书馆工作人员可以为图书借阅者加入借书记录或是还书记录，打印生成相应的报表给用户查看和确认。3、图书出版社的需求是能查询到馆中图书的借阅情况以及个人的一些基本信息，另外还可以将自己的可供应书籍情况进行更新，以便与图书馆方面进行供货联系。4、图书馆管理人员的功能最为复杂，包括对工作人员、图书借阅者、图书以及出版社信息进行管理和维护，还有系统状态的查看、维护等。当然在系统进入稳定运行期后，系统管理人员就不需要随时随地的维护了，只要进行一些必要的简单日常处理就可以了。图书馆管理人员功能的信息量大，数据安全性和保密性要求最高。本功能实现对图书信息、借阅者信息、总体借阅情况信息的管理和统计、工作人员和管理人员信息查看及维护。图书馆管理员可以浏览、查询、添加、删除、修改、统计图书的基本信息；浏览、查询、统计、添加、删除和修改图书借阅者的基本信息，浏览、查询、统计图书馆的借阅信息，但不能添加、删除和修改借阅信息，这部分功能应该由图书馆工作人员执行，但是，删除某条图书借阅者基本信息记录时，应实现对该图书借阅者借阅记录的级联删除。并且还应具有生成催还图书报表，并打印输出的功能。在本系统中由于没有打印机设备供试验，所以把报表打印改成报表预览。具体功能如下： 设计不同用户的操作权限和登陆方法 对所有用户开放的图书查询 借阅者维护借阅者个人部分信息 借阅者查看个人借阅情况信息 维护借阅者个人密码 根据借阅情况对数据库进行操作并生成报表 根据还书情况对数据库进行操作并生成报表 查询及统计各种信息 维护图书信息 维护工作人员和管理员信息 维护借阅者信息3.3.2系统实现数据流图 图32系统的总数据流图由于该系统的一些功能所需的信息也比较多，因此以下列出系统查询功能以及图书数据处理的功能的实现的数据流程图：1、系统查询功能实现的流程图：图33查询功能实现流程图2、图书处理数据流程图：图34图书处理数据流程图3.3.3数据元素表 本次图书管理系统设计中，共涉及6个实体，即图书、出版社、借阅者、工作人员、管理人员、身份。根据数据库设计演示要求，暂简单列出演示所用的部分信息，为求简洁明了，有些数据直接用数字或字母等代替。以下即所列的六个表，以供参考：图书的基本信息编号书名作者出版社类别数量是否全部借出1aA甲X20Y2bB乙Y100Y3cC丙Z200Y4dD丁W100Y5eE甲X200Y6fF乙Y100Y7gG丙Z100Y8hH丁W200N9iI甲X100N10jJ乙Y200N11kK丙Z100N12lL丁W200N13mM甲X200N14nN乙Y100N15oO丙Z200N表31图书的基本信息出版社的基本信息编号联系人所在地电话ID供应类别甲萧剑广州000000X,W乙紫薇北京123412X,Y丙尔康上海432121Y,Z丁小燕子天津111111Z,W表32出版社的基本信息借阅者的信息证件号姓名性别身份身份证号电话密码350601乾隆M皇上9889hs350602慈禧F太后9779th350603令妃F妃子9669fz350604咏琪M阿哥9559ag350605晴儿F格格9449gg表33借阅者的基本信息工作人员信息工作号姓名电话密码ID类别01ab111ab1111X、Y02ac222ac2222Y、Z03ad333ad3333Z、W表34工作人员的基本信息 管理人员信息工作号姓名电话密码ID35060602sjb35060602sjb3506060235060603zh35060603zh35060603表35管理人员基本信息身份信息代码类别最大借阅数b本科生6y研究生8j教师9表36身份信息注：1“图书的基本信息”一表中，类别分别用了X、Y、Z、W来表示，代表有四类，如科技或文学等，非缩写无实际意义；最后一栏“是否借出”属性中，当100本（即数量里标明的数字）全部借出时属性值才为Y,否则即为N。2借阅者的信息中，所用姓名及其他纯属笔者玩笑之举，只为在繁杂的工作中找点乐趣，绝无剽窃及侵权意图，若有冒犯，敬请谅解。3以上是设计初根据系统需求所列出的基本初始表格，可能在实际操作中所建立的数据库表格会跟这些初始表格有些出入，但基本上原理不会有变化，只是根据实际需要为了更方便的操作所做出的改变。在这里就不再列出最后成形的表格了，因为在后面的“系统实现报告”中会详细给出。3.3.4数据字典数据库变量定义及其说明：变量名称变量含义变量取值类型变量最大长度限制num编号float10bookn书名char30publ出版社char30author作者char30kind类别char30amo数量float10link联系人char30id证件号float10pho电话float10city所在地char30passw密码char30name姓名char30maxn最大借阅数float10dm身份代码float30表37变量定义及说明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图如下所示（其中以绿颜色标出并加了下划线的属性即表示主码，其余为非主码）：图3-5 局部分ER图（共六个）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图如下所示（其中，用矩形来表示实体，如借阅者，同时用绿色标出；椭圆表示属性，属性中加下划线的为主码，其余为非主码；菱形为实体间的关系，同时用黄色标出）： 图3-6 初步全局ER图4.1.3消除不必要的冗余，设计基本ER图在初步ER图中，可能存在一些冗余的数据和实体间冗余的联系，所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其它联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库的维护增加困难，应当予以消除。消除了冗余后的初步ER图被称为基本ER图，即我们要得到的概念模型。当然，并不是所有的冗余数据与冗余联系都必须消除，有时为了提高效率，而不得不以冗余信息作为代价。在小型的系统设计中，对于比较简单的数据关系，我们常用分析的方法来去掉实际应用中多余的关系或者属性。此外，除了使用分析方法外，还可以用规范化理论来消除冗余。在规范化理论中，函数依赖的概念提供了消除冗余联系的形式化工具，这种方法常用于关系比较多而复杂的数据库设计过程中。在本系统中，由于实体间关系不是很复杂，完全可以根据分析方法对初步ER图进行冗余消除。比如知道图书的“编号”即可推出该图书属于哪一类别的，因为馆藏图书的编号是按类别依次排下来的，所以对于“图书”这一实体来说，“类别”一项可作为冗余信息删掉；管理员通过对图书信息的管理可以与借阅者、图书出版社以及工作人员的信息发生联系，可以起到对这些信息进行管理的效果，所以可以将管理员与其他用户的管理关系删掉，保留管理员对图书信息的管理关系；另外，由于用户的身份可以通过系统编号来识别，故可以将借阅者、图书出版社、工作人员的“身份证号”（ID）这一属性去掉,这样可以避免在同一个人处于不同角色时引起的系统数据混乱。从而得到消除了部分不必要的冗余之后的基本ER图如下：图3-7 基本ER图概念结构设计所得的概念模型（即上面所得的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联系，转换成：表：借阅者（借书号、姓名、性别、密码、电话号码）表：图书（图书号、书名、出版社编号、作者、数量、是否借出）。表：借阅表（借书号、图书号、借书日期、应归还日期、借阅数目）新增表的“借阅表”中“借书号”和“图书号”组合为主码，分别是外码，其中“借书号”是借阅者表的主码，“图书号”是图书表的主码。同时增加了借阅相关的属性：借书日期、应归还日期、借阅数目。故根据以上的转换原则以及转换过程的分析，可以由基本ER图转换出下面的初始关系数据库模式：图书（图书号、书名、出版社编号、作者、数量、是否借出）。借阅者（借书号、姓名、性别、密码、电话号码）借阅表（借书号、图书号、借书日期、应归还日期、借阅数目）出版社（编号、联系人、所在地、电话、供应类别）供求关系表（出版社编号、图书编号）身份（代码、描述、最大借阅数）身份关系表（借书号、身份代码）管理人员（工作号1、姓名、电话、密码）管理关系表（管理人员编号、图书号）工作人员（工作号2、 姓名、电话、维护图书类型、密码）图书维护信息表（工作人员编号、图书号）4.2.2关系模型的规范化与优化关系模型的优化是为了进一步提高数据库的性能，适当地修改、调整关系模型结构。关系模型的优化通常以规范化理论为指导，其目的是消除各种数据库操作异常，提高查询效率，节省存储空间，方便数据库的管理。常用的方法包括规范化和分解：1）. 规范化规范化就是确定表中各个属性之间的数据依赖，并逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定属于哪种范式。根据需求分析的处理要求，分析是否合适从而进行分解。必须注意的是：并不是规范化程度越高的关系就越优，因为规范化越高的关系，连接运算越多，而连接运算的代价相当高。对于查询频繁而很少更新的表，可以是较低的规范化程度。将两个或多个高范式通过自然连接，重新合并成一个较低的范式过程称为逆规范化。规范化和逆规范化是一对矛盾，何时进行规范化、何时进行逆规范化、进行到什么程度，在具体的应用环境中，需要设计者仔细分析和平衡。2）. 分解分解的目的是为了提高数据操作的效率和存储空间的利用率。常用的分解方式是水平分解和垂直分解。水平分解是指按一定的原则，将一个表横向分解成两个或多个表；垂直分解是通过模式分解，将一个表纵向分解成两个或多个表。垂直分解也是关系模式规范化的途径之一，同时，为了应用和安全的需要，垂直分解将经常一起使用的数据或机密的数据分离。当然，通过视图的方式可以达到同样的效果。根据3NF的规范原则，可以将初始数据库关系模式规范化。由于3NF中不存在非主属性对码的传递依赖及部分依赖关系，分析以上所得关系模式，去掉不必要的部分表格，可得到以下具有3NF特性的关系模式：图书（图书号、书名、出版社编号、作者、数量、是否借出）借阅者（借书号、姓名、性别、身份代码、密码、电话号码）借阅表（借书号、图书号、借书日期、应归还日期、借阅数目）出版社（编号、联系人、所在地、电话、供应类别）身份（代码、描述、最大借阅数）管理人员（工作号1、姓名、电话、密码）工作人员（工作号2、 姓名、电话、维护图书类型、密码）4.2.3设计用户子模式概念模型通过转换、优化后成为全局逻辑模型，还应该根据局部应用的需要，结合DBMS的特点，设计用户子模式。用户子模式也称为外模式，是全局逻辑模式的子集，是数据库用户（包括程序用户和最终用户）能够看见和使用的局部数据的逻辑结构和特征。目前，关系数据库管理系统（RDBMS）一般都提供了视图（View）的概念，可以通过视图功能设计用户模式。此外也可以通过垂直分解的方式来实现。定义用户模式的主要目的是：1符合用户的使用习惯。例如：客户在供应部门习惯称为供应商，在消除命名冲突时统一命名为客户。在用户模式设计时，可以设计一个供应商视图，一是要符合使用习惯，二是只仅仅包含提供物资的对象，而不包含销售的客户。2为不同的用户级别提供不同的用户模式保证数据的安全。有些数据，如企业产品的成本信息是企业比较重要的信息，只有部分用户才能查询和使用，客户一般不能查询，可以定义客户视图，屏蔽其中的成本信息，确保系统的安全。3简化用户对系统的使用某些查询是比较复杂的查询，为了方便用户使用，并保证查询结果的一致性，经常将这些复杂的查询定义为视图，大大简化了用户的使用。在本系统中，管理人员的权限最大，他可以查看其他普通用户的所有信息，而像借阅者这样的普通用户，只能查阅自己的个人信息及图书信息，对于他们来说，其他用户的信息是不可见的。所以在设计外模式时，只需要对不同的用户开放不同范围的数据即可，对于该系统而言，不存在需要将已由关系模式拆分的情况，所以只需要根据各类用户对数据的可见范围作出相应的调整即可。具体来说即：所有数据对管理人员来说都是可见的，图书信息的数据对所有人可见，其余的个人信息只对除管理人员之外的个人可见。4.3物理结构设计4.3.1物理结构设计概述物理结构设计的目的主要有两点：一是提高数据库的性能，满足用户的性能需求；二是有效地利用存储空间。总之，是为了使数据库系统在时间和空间上最优。数据库的物理结构设计包括两个步骤： 确定数据库的物理结构。在关系数据库中主要是存储结构和存储方法的确定； 对物理结构进行评价，评价的重点是时间和空间的效率。如果评价结果满足应用要求，则可进入到物理结构的实施阶段，否则要重新进行物理结构设计或修改物理结构设计，有的甚至返回到逻辑结构设计阶段，修改逻辑结构。由于物理结构设计与具体的数据库管理系统有关，各种产品提供了不同的物理环境、存取方法和存储结构，能供设计人员使用的设计变量、参数范围都有很大差别，因此物理结构设计没有通用的方法。在进行物理设计前，注意以下几个方面的问题：1. DBMS的特点物理结构设计只能在特定的DBMS下进行，必须了解DBMS的特点，充分利用其提供的各种手段，了解其限制条件。本次设计的小型图书馆信息管理系统是在WindowsXP支持下的MYSQL环境下开发运行的，具有功能强，使用简单，管理方便，运行速度快，可靠性高，安全保密等特点。2.应用环境特别是计算机系统的性能，数据库系统不仅与数据库设计有关，与计算机系统有关。比如：是单任务系统还是多任务系统，是单磁盘还是磁盘阵列，是数据库专用服务器还是多用途服务器等等。还要了解数据的使用频率，对于使用频率高的数据要优先考虑。此外，数据库的物理结构设计是一个不断完善的过程，开始只能是一个初步设计，在数据库系统运行过程中要不断检测并进行调整和优化。对关系数据库的物理结构设计主要内容有： 为关系模式选取存取方法 设计关系及索引的物理存储结构4.3.2 存取方法选择数据库系统是多用户共享的系统，为了满足用户快速存取的要求，必须选择有效的存取方法。一般数据库系统中为关系、索引等数据库对象提供了多种存取方法，主要有索引方法、聚簇方法、HASH方法。索引存取方法的选择索引是数据库表的一个附加表，存储了建立索引列的值和对应的记录地址。查询数据时，先在索引中根据查询的条件值找到相关记录的地址，然后在表中存取对应的记录，所以能加快查询速度。但索引本身占用存储空间，索引是系统自维护的。B+树索引和位图索引是常用的两种索引。建立索引的一般原则是：(1) 如果某属性或属性组经常出现在查询条件中，则考虑为该属性或属性组建立索引；(2) 如果某个属性经常作为最大值和最小值等聚集函数的参数，则考虑为该属性建立索引；(3) 如果某属性和属性组经常出现在连接操作的连接条件中，则考虑为该属性或属性组建立索引；当然，并不是索引定义越多越好。一是索引本身占用磁盘