数据库大作业：图书管理系统

一、需求分析

1.1项目背景

项目背景：随着人们知识水平层次的提高，图书馆成为日常生活中不可缺少的一部分，图书管理也变得困难而重要，需要可靠的图书管理系统对图书进行有效的管理，理由如下：图书存书量和业务量庞大，仅靠传统的记帐式管理不可行；
图书馆需要为学校或社会有需求者提供图书的详细信息和馆内库存情况，需要建立庞大的数据库；

1.2系统定位与功能

针对图书馆的图书管理系统数据库设计，分别对图书馆的读者、一般工作人员和部门负责人进行详细地分析，总结出如下的需求信息:
（1）图书馆中的图书具有书号、书名、作者、馆藏册数、在馆册数、价格、出版社及摘要等必要信息。其中每种书具有唯一的书号，即一个书号对应一种书而不是一本书。书名可以重复，但如果只是两本书重名，则这两本书具有不同的书号。馆藏册数和在馆册数可以用于让读者判断是否可以借，另外，馆藏册数必须要大于等于在馆册数。
（2）图书馆中的读者具有卡号、姓名、性别、单位、类型、级别和在借册数这些必要信息。卡号用于唯一地标识读者身份，每个读者对应一个卡号，同样每个卡号也不能对应多个读者。类型这个属性可以用于区分教员、学员，区分他们的意义在于不同类型的读者可同时借阅的书籍数大不相同。
（3）从读者的角度，可以查阅图书馆相应的图书资料（也可以按要求查找，如输入一些关键字）以及每本书的在馆册数；同时可以提交借书和还书的申请；能判断自己是否因超期而欠款，若超期则自动显示出所需的罚款金额。
（4）图书馆中的工作人员可以分为图书管理员和系统管理员。
（5）图书管理员是图书馆中最普通的工作人员，图书管理员可以实现读者的借书和还书操作；也可以实现在读者交罚款之后取消罚款记录。另外，图书管理员在执行借书或还书操作时，应根据不同读者类型的借书限制册和还书日期等约束条件来实现。
（6）系统管理员主要管理各类人员信息，包括读者信息和图书馆管理员信息这两项。
（7）图书馆中应当有书架，书架具有书架号和类型两个属性，不同的书架号对应的图书类型也应该不同；另外还需要在图书中增加存放位置这个属性。

1.3开发进度安排

2023年5月15日，星期一确定开放方向，拟出管理系统的ER模型。
2023年5月21日，星期日完成数据库的建立，初步建立用户界面。
2023年6月12日，优化用户界面，完善用户端功能。
2023年6月 21日，前端应用连接数据库。
2023年6月 25日，完成最后调试。

1.4开发人员介绍

二、数据库设计

2.1 概念结构设计

图书这个实体型由书号、书名、作者、价格、出版社、摘要、馆藏册数、在馆册数、存放位置和被借次数这些属性组成，其中书号这个属性为主属性。

读者这个实体型由学号、姓名、性别、单位、类型、可借册数、在借册数、登陆密码和欠款这些属性组成，其中学号这个属性为主属性。

书架这个实体型由书架号和类型这两个属性组成，其中书架号这个属性为主属性，类型为本书架中存放书籍的类型，与之前读者中的表示读者身份的类型完全不同。

图书管理员和系统管理员这两个实体型由工作号，姓名和登录密码这些属性组成，其中工作号为主属性。

借还申请这个实体型由学号、书号、提交时间和借还类型这些属性组成，这些属性均为主属性。

2.2整体ER图

2.3逻辑结构设计

(一)关系模式的设计与优化

首先:将E-R图中的6个实体型转换成6个最基本的关系模式
1、图书（书号，书名，作者，价格，出版社，摘要，馆藏册数，在馆册数，存放位置，被借次数）
2、读者（卡号，姓名，性别，单位，类型，在借册数，可借册数，密码，欠款）
3、书架（书架号，类型）
4、图书管理员（工作号，姓名，密码）
5、系统管理员（工作号，姓名，密码）
6、借还申请（学号，书号，提交时间，类型）
然后:将实体型之间的联系转换成关系模式，因为是m:n联系，因此直接将与该联系相连的各实体的码以及联系本身的属性转换为关系的属性
1、借阅（书号，卡号，借书时间）
最后，根据实际的需要将关系模式进行合理的优化
1、图书（书号，书名，作者，价格，出版社，摘要，馆藏册数，在馆册数，存放位置，被借次数）
因为只有一个候选码（书号），因此不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性每一个都是只有通过候选码推出，因此，不存在传递依赖，而且因为候选码书号是唯一的决定因素，所以该关系模式不仅满足3NF，也满足BCNF。
2、读者（卡号，姓名，性别，单位，类型，在借册数）
因为只有一个候选码（卡号），因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性每一个都是只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码卡号是唯一的决定因素，所以该关系模式也满足BCNF。
3、类型（类型，借书时间，最多在借册数）
与上一个关系模式相同，由于只有一个候选码（类型），因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性每一个都是只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码类型是唯一的决定因素，所以该关系模式也满足BCNF。
4、借阅（书号，卡号，借书时间）
这个关系模式中包含三个主属性（书号、卡号和借书时间），该关系模式也满足BCNF。
5、书架（书架号，类型）
因为只有一个候选码（书架号），因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性只有一个，也就是类型，只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码书架号是唯一的决定因素，所以该关系模式也满足BCNF。
6、工作人员（工作号，姓名，职务）
与上一个关系模式相同，该关系模式只有一个候选码（工作号），因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性每一个都是只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码工作号是唯一的决定因素，所以该关系模式也满足BCNF。

(二)设计合适的视图

首先，由于所需要查看该数据库的人员分为读者、一般工作人员和部门负责人。而这三种人员在不同情况下需要看到的信息不同，因此需要根据这三种不同的人员建立所需要的不同视图。
对于读者而言:
1、读者在需要借书时只需要看到书号、书名、作者、价格、出版社、摘要、馆藏册数和存放位置，可以建立一个视图。
2、当读者需要查看自己的信息时，可以查看读者表的的全部信息以及类型表中的最多在借册数，以便于知道自己还能借几本书，这也需要建立一个视图。
对于图书管理员而言:
1、当图书管理员需要查看自己的信息时，只需要查看工作人员表中的前三项即可。
2、当图书管理员需要审批借阅/归还信息时，可根据职责分工单独查看其中一类申请。
对于系统管理员而言:
1、系统管理员除了可以查看所有信息外，还可以专门建立一个视图以方便查看图书的借阅情况以及每本书的借阅次数。
2、系统管理员可以查看登陆日志，通过日期信息来建立视图。

2.4数据库设计

主要设计了8个表，具体表结构如下：
Books（书）

Bookshelfs（书架）

Borrow（借书信息）

Item（借还申请）

Loginrecord（登陆日志）

Readers（读者）

Readertype（读者类型）

Workers（工作人员）

三、系统实现与设计

3.1 图形化界面设计

本系统的UI设计使用Python第三方库PyQt5。 Pyqt5是一套Python绑定Digia QT5应用的框架。它可用于Python 2和3。Qt库是最强大的GUI库之一。pyqt5做为Python的一个模块，它有620多个类和6000个函数和方法。这是一个跨平台的工具包，它可以运行在所有主要的操作系统，包括UNIX，Windows，Mac OS。
安装好PyQt5后，系统会默认安装QtDesigner工具。Qtdesigner是Python设计里面一个非常实用的工具，使得人们编写qt界面可以不仅仅是使用纯代码，而可以在可视化的基础上设置。
根据需求我们设计了以下4个界面：
1、登陆界面：

2、读者系统界面：

3、图书管理员界面：

4、系统管理员界面：

3.2系统功能实现思路

设计好UI后，具体功能的实现是将UI中各种控件的信号连接到相应的槽函数上。我们的思路是将这四个UI定义为类，实现功能的槽函数定义为类中的方法。在主函数中导入这几个类并实例化，这样在之后的优化中只需要对UI的类进行修改。
槽函数的实现需调用pymysql库，将需要数据库提供的数据转换为SQL语句，用库中的游标来执行，并返回相应值，进而实现具体功能。
以读者系统为例：
类的定义如下：

槽函数的连接如下:

槽函数的实现如下：

四、回顾与展望

通过这一段时间的系统开发，图书管理系统终于完成。在开发的过程中，在以前觉得很抽象的东西变得清晰起来，并且通过解决开发过程该所遇到的困难的过程中，虽然由于时间的紧迫，该系统做得不是很好，功能也不够强大，但学到的知识确实很多，有了一次自己亲手做个小系统的经验。
通过咨询同学和查询大量的资料，对该系统有了一定的了解，也知道了开发的步骤。虽然这个系统很小，但是对于我们来说工程量还是有点大的，尤其是要在这短短的一个多月内完成，所以导致实现的系统存在着许多不足。主要的不足有：
1、功能简单，只实现了图书管理系统必须具有的部分功能。
2、数据不能共享。
3、实现的性能较差。
4、缺少并发控制。
这次的设计开发，我的收获主要有几点：
1、对原型化的系统开发方法有了一定的了解。通过这次开发，我们对系统开发的流程有了初步的了解，对我们以后的开发有很大的帮助。
2、通过实践，提高了系统分析的能力，对数据流图、系统流程图等系统设计工具的使用有了更深刻的认识。为以后的工作、学习的进一步提高打下了坚实的基础。