Appendix A:

Library Database Case Study

Introduction
The Library Database Case Study provides an overview of the operations at the
West Municipal Library, describes the daily library functions, and presents the
database that was designed for the library.

Overview of Library Operations

Before a database for librarians and members was implemented, an interview
was conducted with the librarians at the West Municipal Library to assess the
library’s business needs. The decisions that the database designer made during
the design process are explained in the following sections. The following figure
shows the overall schema of the database that was designed for the library.

Library
Database Diagram

member loan loanhist

PK member_no PK,FK1 isbn PK,FK1 isbn
PK,FK1 copy_no PK,FK1 copy_no
lastname PK out_date
firstname FK3 title_no
middleinitial FK2 member_no FK2 title_no
photograph out_date member_no
due_date due_date
reservation in_date
PK,FK1 isbn fine_assessed
PK,FK2 member_no fine_paid
fine_waived
log_date remarks
adult
remarks
PK,FK1 member_no

street
city
state
zip copy
phone_no item
expr_date PK,FK1 isbn
PK isbn PK copy_no
FK1 title_no FK2 title_no
translation on_loan
cover
loanable
title
juvenile PK title_no
PK,FK2 member_no
title
author
FK1 adult_member_no
synopsis
birth_date
2 Appendix A: Library Database Case Study

Daily Library Functions

Many daily library functions exist. The following are some of the
most important.

Uniquely Identifying Books

Some books may have the same title; therefore, titles cannot be used as a means
of identification. Librarians call books items. Items are identified by the
International Standard Book Number (ISBN). Books with the same title can
have different ISBN numbers if they are in different languages and have
different bindings (hard cover or soft cover).

Reserving Books
If a member wants a book that is out on loan, the book is placed on reserve for
them. When the book arrives, a librarian must notify the member who has been
waiting the longest. Members can have as many as four books on reserve at
one time.

Determining Book Availability

Librarians must be able to determine how many copies of a book are out on
loan at any given time and which books are on reserve.
A synopsis that ranges from one sentence to several pages exists for each title in
the library. Librarians want to be able to access the synopses when members
request information about books.

Enrolling Members
To become a library member, individuals must provide their mailing addresses
and phone numbers. A librarian then issues the individual a numbered,
machine-readable card. This card is good for one year.
Juveniles (individuals under age 18) can be members of the library, but an adult
member must sign for them when they join. Therefore, a juvenile member’s
card is good only until the associated adult member’s card expires. The only
information that the library keeps on juvenile members is their name and date
of birth. The library must be able to detect when juvenile members turn 18
and then must automatically convert the juvenile memberships to adult
memberships.
A month before membership cards expire, a librarian must notify the member.

Checking Out Books

Books can be checked out for 14 days. Members are allowed to have only four
books checked out at a time. If a book is overdue, members have one week
before the library sends a notice to them.
Members bring books to the front desk after they locate the ones that they want
to check out. A librarian then runs the member’s card through a machine that
reads the card number magnetically. A screen displays information about the
member’s account, such as name, address, phone number, and the card’s
expiration date. Ideally, cards that have expired or are about to expire will
be highlighted.
 Appendix A: Library Database Case Study 3

The screen also displays information about a member’s outstanding loans,

including title, checkout date, and due date. This information is useful because
it is presented in a chronological sequence, with the most overdue loan
appearing first and the most recent loan appearing last. Highlighting also
indicates loans that are overdue or are about to become overdue.
If a member’s account is in order, a librarian checks out the books. Librarians
check out books by running a scanner down the book spines (the ISBN and the
copy number are encoded on the spines). The ISBN, title, and author
information then appear on the computer screen. If the books are not loanable, a
warning message appears.

Checking In Books
When books are returned, librarians check them in by running a scanner down
the book spines. The ISBN, title, and author information then appear on the
computer screen, as well as the member number and name and the book’s
due date.
Occasionally, books are accidentally reshelved before librarians check them in.
If a member tries to check out a book that the database lists as checked out,
librarians need to be able to access the checkout information, including the
member’s name, check out date, and due date. If a member presents a book to
check out that is still officially checked out to another member, a message
appears that alerts librarians that the book is already checked out. Then
librarians can update their records immediately by being forced to clear the
previous loan before they continue with the checkout.

Generating Usage Reports

Occasionally, librarians must compile usage information, mostly for the Town
Council or the Planning Commission. These groups usually want to know
information, such as the volume of circulation, the popularity of various books,
the reliability of return, and the average length of a borrowing term. Therefore,
the librarians need to be able to prepare quick summaries of this information.
The types of questions that are frequently asked include the following:
How many loans did the library do last year?
What percentage of the membership borrowed at least one book?
What was the greatest number of books borrowed by any one individual?
What percentage of the books was loaned out at least once last year?
What percentage of all loans eventually becomes overdue?
What is the average length of a loan?
What are the library’s peak hours for loans?
4 Appendix A: Library Database Case Study

Library Database Design

Based on the information that librarians presented, the project database designer
decided to implement the entities from the preceding scenario in three groups of
tables: tables that contain member information, tables that contain item (book)
information, and tables that contain loan information.

Member Information
The first group of tables models the two types of individuals who check out
books from the West Municipal Library. As the following figure indicates, the
first group comprises three tables: member, adult, and juvenile.

member
member_no lastname firstname middle_i photo
PK NN NN
1 Anderson Andrew A ~~~
2 Barr Andrew R ~~~
3 Barr Bill NULL ~~~
4 Anderson Bill B
5 Anderson Sally A ~~~
6 Henson Jack NULL ~~~
adult
member_no street city state zip phone_no expr_date
PK, FK NN NN NN NN NN
1 Elm St Seattle WA 98022 NULL Jun 06 1992
2 Bowery Ave Seattle WA 98022 (206)555-1212 Aug 07 1992
6 Bowery Ave Kent WA 98206 NULL Mar 03 1993
juvenile
member_no adult_member_no birth_date
PK, FK FK, NN NN
3 2 Jun 01 1980
4 1 Mar 01 1978
5 1 Nov 05 1982

The member table is the master table, while adult and juvenile are subtables.
All three tables use the member_no column as a primary key. Since the values
in this column are different for each member and uniquely identify each row of
information, the member_no column is a good choice for a primary key.
These entities could have been modeled in several different ways: as a single
table or as member and juvenile tables. If a single table had been used for all
members, many addresses would have been duplicated because juveniles in this
model have the same address as their parents.
Librarians need to be able to track birth dates of juveniles only, so splitting the
membership information into several tables eliminates the null column values
that would have resulted for the birth dates of adults.
Dividing the tables in this fashion also models the scenario in a way that
reflects the membership of the library: member-to-adult is a one-to-one
relationship, while adult-to-juvenile is a one-to-many relationship.
 Appendix A: Library Database Case Study 5

Item Information
The title, item, and copy tables form a logical second group. The master table
of this group is the title table.
For each listing in the title table, one or more entries exist in the item table
because a book may be available in several languages, in paperback or
hardback, and be loanable or not loanable. Title-to-item is a one-to-many
relationship. Furthermore, for each listing in the item table, one or more copies
of that item can exist. Therefore, item-to-copy is a one-to-many relationship.

title
title_no title author synopsis
PK NN NN
1 Gone With the Wind Mitchell ~~~
2 Color Purple Walker ~~~
3 Hotel Hailey
4 Winnie the Pooh Milne ~~~
item
isbn title_no language cover loanable
PK FK, NN
1 1 English softback Y
2 2 French NULL N
3 3 French hardback Y
4 4 NULL hardback NULL
5 2 English softback Y
copy
isbn copy_no title_no on_loan
PK, FK PK FK, NN NN
1 1 1 Y
1 2 1 Y
2 1 2 N
3 1 3 Y
4 1 4 Y
4 2 4 Y

The item table has a loanable column. Rather than including information from
this column in the copy table, the database designer assumes that all copies of a
particular item are either loanable or not loanable.
Notice that the copy table has a primary key made up of two columns. This type
of primary key is called a composite key. The combination of isbn and
copy_no uniquely identifies each row in the table.
The copy table contains a duplicate title_no column. This group of tables
has been denormalized to reduce the number of joins that are needed to
retrieve information.
The on_loan column in the copy table is derived data—data that could be
generated with a query each time that the information is needed. But the
information is kept in the table to make it readily available and to reduce the
number of calculations that must be performed. The on_loan column is
populated by using information from the loan table (shown below). Because the
loan table changes frequently, locks could prevent a user from obtaining this
information. The copy table is more likely to be used in a read-only fashion, so
it would not be necessary to prevent users from accessing information that is
stored there.
6 Appendix A: Library Database Case Study

Loan Information
The reservation, loan, and loanhist tables contain the library’s loan
information. The reservation table tracks current reservations for each book;
the loan table tracks information on books that are currently on loan; and the
loanhist table stores information on books that have been loaned and returned.

Note In the following figure, FK1 implies a composite foreign key. FK defines
a single column foreign key.

reservation
reservation loan
loan
isbn
isbn member_no
member_no log_date
log_date state
state remarks
remarks isbn
isbn copy_no
copy_no title_no
title_no member_no
member_no out_date
out_date due_date
due_date
PK,FK
PK,FK PK,PK, FK
FK NN
NN PK,FK1
PK,FK1 PK,
PK, FK1
FK1 FK,NN
FK,NN FK, FK, NN
NN NN
NN NN
NN
11 22 3/7/1992
3/7/1992 WA
WA ~~~
~~~ 11 11 11 11 03/18/92
03/18/92 03/29/92
03/29/92
11 33 NULL
NULL WA
WA NULL
NULL 44 11 44 11 03/15/92
03/15/92 03/29/92
03/29/92
44 33 3/17/1992
3/17/1992 WA
WA ~~~
~~~ 44 22 44 22 03/17/92
03/17/92 04/01/92
04/01/92
33 11 33 33 03/18/92
03/18/92 04/02/92
04/02/92
11 22 11 11 03/15/92
03/15/92 03/29/92
03/29/92

loanhist
loanhist
isbn
isbn copy_no
copy_no out_date
out_date title_no
title_no member_no
member_nodue_date
due_date in_date
in_date fine_assessed
fine_assessed fine_paid
fine_paid fine_waived
fine_waived remarks
remarks
PK,FK1
PK,FK1 PK,
PK, FK1
FK1 NNNN FK,NN
FK,NN FK, FK, NN
NN
11 11 10/13/91
10/13/91 11 44 10/27/91
10/27/91 10/26/91
10/26/91 0.00
0.00 0.00
0.00 0.00
0.00 ~~~
~~~
22 11 07/07/91
07/07/91 22 22 07/21/91
07/21/91 NULL
NULL 0.10
0.10 0.00
0.00 0.10
0.10 ~~~
~~~
22 11 10/13/91
10/13/91 22 44 10/27/91
10/27/91 10/28/91
10/28/91 0.00
0.00 0.00
0.00 0.00
0.00 ~~~
~~~
11 22 11/06/91
11/06/91 11 33 11/20/91
11/20/91 11/14/91
11/14/91 0.20
0.20 0.20
0.20 0.00
0.00 ~~~
~~~
11 11 10/30/91
10/30/91 11 11 11/13/91
11/13/91 11/15/91
11/15/91 0.00
0.00 0.00
0.00 0.00
0.00

It is possible to combine the loan and loanhist tables to reduce redundancy, but
this may create other problems. The loanhist table is essentially a history of all
loans and could become unwieldy. Over time, librarians may want to back up
information from this table, so it makes sense to keep all of this information in
its own table. In addition, this business model requires that several queries be
made against the loanhist table. These queries would be easier to implement
and faster to run if the history information were kept separately from the
loan information.
The loan and loanhist tables also represent different functions of the
application. When a member checks out a book, an entry is made to the loan
table. When a member returns a book, an entry is made to the loanhist table,
and the corresponding entry is deleted from the loan table. By maintaining
separate tables for each function and denormalizing the tables, users can access
the information more quickly. However, because the tables are denormalized,
they require more maintenance. For example, when item.title_no is updated,
the title_no column must be updated in the loan, loanhist, and copy tables as
well. Because updates to the title_no column may be infrequent,
denormalization may speed queries.