图书管理系统的数据库设计

实验题目

图书管理系统的数据库设计

一、实验目的 选用一种DBMS作为设计平台，理解并应用课程中关于数据库设计的相关理论，能按照数据库设计步骤完成完整的数据库设计，包括需求分析、概念设计、逻辑设计、物理设计和实施。同时能够正确应用各个阶段的典型工具进行表示。 二、设备与环境 (1) 硬件设备：PC机一台 (2) 软件环境：安装Windows操作系统，安装数据库管理系统SQL Server2012等。 三、实验内容 1.需求分析 针对图书馆的图书管理系统数据库设计，分别对图书馆的读者、一般工作人员和部门负责人进行详细地调研和分析，总结出如下的需求信息: （1）图书馆中的图书具有书号、书名、作者、馆藏册数、在馆册数、价格、出版社及摘要等必要信息。其中每种书具有唯一的书号，即一个书号对应一种书而不是一本书。书名可以重复，但如果只是两本书重名，则这两本书具有不同的书号。馆藏册数和在馆册数可以用于让读者判断是否可以借，另外，馆藏册数必须要大于等于在馆册数。 （2）图书馆中的读者具有卡号、姓名、性别、单位、类型、级别和在借册数这些必要信息。卡号用于唯一地标识读者身份，每个读者对应一个卡号，同样每个卡号也不能对应多个读者。类型这个属性可以用于区分老师或是学生，区分他们的意义在于不同类型的读者可同时借阅的书籍数大不相同。级别则可以体现读者或者说是该卡号一共的借书量，每借一本书，读者档案中的级别属性就应该有所增加，这样图书馆的管理者就可以判断出那些是活跃读者，甚至可以对这些级别高的读者作出相应的奖励。 （3）从读者的角度，可以查阅图书馆相应的图书资料（也可以按要求查找，如输入一些关键字）以及每本书的在馆册数；同时可以查看自己所借的图书表及相应的图书信息；能判断自己所借的一些书是否超期，若超期则自动显示出所需的罚款金额。 （4）图书馆中的工作人员可以分为一般工作人员和部门负责人。部门负责人是从若干个一般工作人员中选出。 （5）一般工作人员是图书馆中最普通的工作人员，一般工作人员可以实现读者的借书和还书操作；也可以实现在读者交罚款之后取消罚款记录。另外，一般工作人员在执行借书或还书操作时，应根据不同读者类型的借书限制册和还书日期等约束条件来实现。 （6）部门负责人是从一般工作人员中选出，拥有在整个图书管理系统中最高的权限。部门负责人可以查看所有图书的借阅情况，以及单本图书被借的总次数和读者中比较活跃的人（即读者中级别这个属性比较高的人）。 （7）图书馆中应当有书架，书架具有书架号和类型两个属性，不同的书架号对应的图书类型也应该不同；另外还需要在图书中增加存放位置这个属性。   2.概念结构设计 各实体型及其属性:       图书这个实体型由书号、书名、作者、价格、出版社、摘要、馆藏册数、在馆册数、存放位置和被借次数这些属性组成，其中书号这个属性为主属性。         读者这个实体型由卡号、姓名、性别、单位、类型、级别和在借册数这些属性组成，其中卡号这个属性为主属性。           书架这个实体型由书架号和类型这两个属性组成，其中书架号这个属性为主属性，类型为本书架中存放书籍的类型，与之前读者中的表示读者身份的类型完全不同。       工作人员这个实体型由工作号，姓名，职务，工资这些属性组成，其中工作号这个属性为主属性。     完整的E-R图:       3.逻辑结构设计 (1)关系模式的设计与优化   首先:将E-R图中的4个实体型转换成4个最基本的关系模式 Ⅰ、图书（书号，书名，作者，价格，出版社，摘要，馆藏册数，在馆册数，存放位置，被借次数） Ⅱ、读者（卡号，姓名，性别，单位，类型，级别，在借册数） Ⅲ、书架（书架号，类型） Ⅳ、工作人员（工作号，姓名，职务，工资）     然后:将实体型之间的联系转换成关系模式，因为是m:n联系，因此直接将与该联系相连的各实体的码以及联系本身的属性转换为关系的属性 Ⅰ、借阅（书号，卡号，借书时间，还书时间）     最后，根据实际的需要将关系模式进行合理的优化 Ⅰ、图书（书号，书名，作者，价格，出版社，摘要，馆藏册数，在馆册数，存放位置，被借次数） 因为只有一个候选码（书号），因此不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性每一个都是只有通过候选码推出，因此，不存在传递依赖，而且因为候选码书号是唯一的决定因素，所以该关系模式不仅满足3NF，也满足BCNF。   Ⅱ、读者（卡号，姓名，性别，单位，类型，级别，在借册数） 因为只有一个候选码（卡号），因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性每一个都是只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码卡号是唯一的决定因素，所以该关系模式也满足BCNF。   Ⅲ、类型（类型，借书时间，最多在借册数） 与上一个关系模式相同，由于只有一个候选码（类型），因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性每一个都是只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码类型是唯一的决定因素，所以该关系模式也满足BCNF。   Ⅳ、正借阅（书号，卡号，借书时间，应还时间，还书时间，罚款金额） 这个关系模式中含有一个候选码，但包含三个主属性（书号、卡号和借书时间），由于主属性借书时间可以直接推出应还时间，因此在该关系模式中存在着非主属性部分依赖，所以该关系模式只能满足2NF。     Ⅴ、已还（书号，卡号，借书时间，还书时间） 这个关系模式中含有一个候选码，也包含三个主属性（书号、卡号和借书时间），但该关系模式中不存在应还时间，还书时间这个属性只能通过三个主属性唯一确定，因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于非主属性只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码是唯一的决定因素，所以该关系模式也满足BCNF。   Ⅵ、书架（书架号，类型） 因为只有一个候选码（书架号），因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性只有一个，也就是类型，只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码书架号是唯一的决定因素，所以该关系模式也满足BCNF。   Ⅶ、工作人员（工作号，姓名，职务，工资） 与上一个关系模式相同，该关系模式只有一个候选码（工作号），因此该关系模式中也不存在非主属性部分依赖的情况；另外，由于除了候选码以外的所有非主属性每一个都是只有通过候选码推出，因此，也不存在传递依赖，而且因为候选码工作号是唯一的决定因素，所以该关系模式也满足BCNF。   (2)设计合适的视图   首先，由于所需要查看该数据库的人员分为读者、一般工作人员和部门负责人。而这三种人员在不同情况下需要看到的信息不同，因此需要根据这三种不同的人员建立所需要的不同视图。 对于读者而言: Ⅰ、读者在需要借书时只需要看到书号、书名、作者、价格、出版社、摘要、馆藏册数和存放位置，可以建立一个视图。   Ⅱ、当读者需要查看自己的信息时，可以查看读者表的的全部信息以及类型表中  的最多在借册数，以便于知道自己还能借几本书，这也需要建立一个视图。   Ⅲ、当读者需要查看自己借书的情况时，需要从正借阅表中查看与自己卡号相同的借书信息与超期信息，需要建立一个视图。     Ⅳ、当读者需要查看自己超期借阅的情况时，需要从正借阅表中查看与自己卡号相同并且超期的借书信息，因此需要建立一个视图。     对于一般工作人员而言: Ⅰ、当一般工作人员需要查看自己的信息时，只需要查看工作人员表中的前三项即可，不能查看工资这一项。   对于部门负责人而言: Ⅰ、部门负责人除了可以查看所有信息外，还可以专门建立一个视图以方便查看图书的借阅情况以及每本书的借阅次数。   Ⅱ、当部门负责人想查看图书馆比较活跃的读者时还可以专门建立一个级别>30的读者情况视图。     4.物理设计 系统已经有的索引: 在建立自定义的索引之前，系统会自动建立一些索引，在建表时，如果设立了主键，则系统会自动根据该主键建立一个索引，如下图:   另外，如果表中带有UNIQUE类型的列，则系统也会自动建立一个以UNIQUE类型的列为标准建立一个索引。   自定义索引:     首先，需要在borrowed表中建立一个索引，可以按学号来排序，因为当工作人员或者部门负责人想要查找某个读者的所有借书记录时，如果所有学号按序排列，查找速度会比之前有所增加。   然后，需要在borrowing表中建立一个索引，也是按学号来排序，因为当工作人员或者部门负责人想要查找某个读者当前正在借阅的所有借书记录时，如果所有学号按序排列，查找速度会比之前有所增加。            最后，还需要在Reader表中建立一个索引，按照类型来排序，当部门负责人查找级别大于某个值或者比较活跃的读者时，查找速度会有所提升。      5.数据库的实现 (1)创建库、表 Ⅰ、数据库的创建   在创建数据库的同时，一定要同时创建日志文件。日志文件文件与数据库文件存放在一起的好处在于能够方便查找，但其弊端在于如果该磁盘发生损坏，则无法进行恢复，因此最好在使用时将其存放到不同的磁盘。 Ⅱ、Reader表的创建   实体完整性:Reader表中以卡号为主键，在对表进行更新操作时，关系数据库管理系统将按照实体完整性规则对相应属性自动进行检查，包括是否唯一以及该属性值是否为空。 参照完整性:Reader表中的类型这个属性是根据typed表中的类型而得，因此需要建立一个外键，使Reader表中的类型能够依赖于typed表中的类型。 自定义完整性: Reader表中的姓名定义为NOT NULL，当输入数据时，必须要输入姓名，使之不能为空，否则这条记录将会没有意义。另外，Reader表中性别这个属性只能从“男”或者“女”中选择，若输入其他的值，关系数据库管理系统将会报错。   Ⅲ、borrowing表的创建   实体完整性: borrowing表中以书号、卡号和借书时间一起作为主键，在对表进行更新操作时，关系数据库管理系统将按照实体完整性规则对相应属性自动进行检查，包括是否唯一以及该属性值是否为空。 参照完整性: borrowing表中的书号这个属性是根据Book表中的书号而得，若Book表中不存在某个书号，则borrowing表中也不能有这个书号，否则该书号将变得没有意义，因此需要建立一个外键，使borrowing表中的书号能够依赖于Book表中的书号。另外，borrowing表中的卡号这个属性是根据Reader表中的卡号而得，若Reader表中不存在某个卡号，则borrowing表中也不能有这个卡号，否则该卡号也将变得没有意义，因此需要建立一个外键，使borrowing表中的卡号能够依赖于Reader表中的卡号。   (2)创建用户 创建角色: Ⅰ、创建一个读者的角色     并为其授权，使之只被允许查看reader_borrow、reader_self、reader_borrowing和reader_overborrow这四个视图。   Ⅱ、创建一个一般工作人员的角色   并为其授权，使之被授权允许查看和修改Book、Reader、borrowing和bookshelf这四个表。   但是要注意的是，出于安全考虑，一般工作人员应该只被允许查看borrowed表和worker_self视图，这样一般工作人员就不能够修改自己的职务以及已经还的书的信息。   Ⅲ、创建一个部门负责人的角色     并为其授权，使之被授权允许对所有表进行所有操作。          创建用户: Ⅰ、创建一个登录名u1     Ⅱ、在u1下创建一个用户user1，并使之加入角色“读者”     Ⅲ、创建一个登录名u2     Ⅳ、在u2下创建一个用户user2，并使之加入角色“一般工作人员”      Ⅴ、创建一个登录名u3         Ⅵ、在u3下创建一个用户user3，并使之加入角色“一般工作人员”        (3)数据库编程 Ⅰ、建立一个用于判断的触发器T1，当向Book表中输入数据时，对馆藏册数和在馆册数进行判断，使馆藏册数不能小于在馆册数，若输入的数据不符合条件，则进行报错并回滚。            Ⅱ、建立一个用于判断的触发器T2，当向Reader表中输入数据时，对在借册数和最大在借册数进行判断，使在借册数不能大于最大在借册数，若输入或者修改的数据不符合条件，则进行报错并回滚。       Ⅲ、建立一个用于修改数据的触发器T3，当向borrowing表中输入数据时，对Reader表的在借册数属性和Book表的被借册数属性进行同步修改，使之能够动态地随着borrowing表中的输入而增加。      Ⅳ、建立一个用于修改数据的触发器T4，当在borrowing表中删除数据时，对Reader表的在借册数属性进行同步修改，使之能够动态地随着borrowing表中的删除而减少，也对Book表的在馆册数属性进行同步修改，使之能够动态地随着borrowing表中的删除而增加。       Ⅴ、建立一个用于修改数据的触发器T5，当在borrowing表中插入数据时，对borrowed表的各属性进行同步的插入操作，使之能够动态地随着borrowing表中的输入而输入。     Ⅵ、建立一个用于修改数据的触发器T6，当在borrowing表中修改数据时，对borrowed表的各属性进行同步的修改操作，使之能够动态地随着borrowing表中的修还而修改。另外，在修改完之后进行判断，若是修改了还书时间（即工作人员进行还书操作），则在borrowing中删除掉这条数据。因为之前已经在borrowed表中做了备份，因此此举能够减少常用表borrowing中的数据，提高查询效率，而数据多的borrowed表则为不常用表。          Ⅶ、建立一个用于修改数据的触发器T7，当在borrowing表中插入数据时，对borrowing表的应还时间属性进行同步的修改操作，使之能够动态地随着borrowing表中的结束时间改变而改变。         Ⅷ、建立一个用于修改数据的触发器T8，当在borrowing表中插入或修改数据时，对borrowing表的罚款金额属性进行同步的计算并修改操作，使之能够动态地随着borrowing表中的时间改变而改变。触发器中会进行判断，当获取到的当前时间>图书的应还时间时，触发器生效进会进行计算，并将计算得到的罚款金额数值更新到borrowing表中的对应位置。         四、实验结果及分析 通过本次实验我学习到了建立一个数据库系统具体需要做些什么，之前老师在上课时曾谈到过建立一个数据库系统需要经历需求分析阶段、概念结构分析阶段、逻辑结构分析阶段、物理结构分析阶段、数据库实施阶段和数据库运行维护阶段，我们只是从理论的角度对其进行了解，而这次大作业却让我切切实实感受到了这个流程的重要性，虽然我们并没有经历数据库运行维护阶段，但也知道了无论少了这些步骤的任何部分，数据库系统的建立就无从谈起。 另外，本次实验也额外让我感受到了数据库恢复技术有多重要。由于一些私人原因，我在完成本次实验的过程中，数据发生了丢失，之前对数据库以及数据库中的数据做的所有操作都不翼而飞。如果那时我能够对数据库系统做好备份，甚至是将数据库系统和它的日志文件分开存放，那么这些事情就不会发生，我也不会面临着重做的命运。而这也警告了我无论多小的一个数据库，都一定要做好备份，并将数据库系统和它的日志文件分开存放。 最后，由于时间原因本次实验的成果仅仅只是用到了一些复杂的触发器，并没有涉及到数据存储或者动态SQL，虽然功能都已经实现，但是代码都比较冗长，有很多地方完全可以更加简单，而且效果更好。除此之外，如果能用VB语言写一个外部程序与之对应，那么整个数据库系统也会变得更加美观并符合实际。这就是本数据库所能拓展的方向，我将会在实验结束后继续进行开发。