19-07-2013, 04:34 PM
LIBRARY MANAGEMENT SYSTEM: DESIGN AND IMPLEMENTATION
LIBRARY MANAGEMENT .pdf (Size: 299.9 KB / Downloads: 410)
ABSTRACT
This report describes our group's implementation of a library
management system. We used the Entity-Relationship model to design
a database that will store and organize the library's data. We have
created the database using SQL and populated it with some sample
data. The system can keep track of library cards, customers,
librarians, library locations, books, videos, and the relationships
between them. Using Java Server Pages, servlets, and JDBC, we have
created an Internet-based graphical user interface that allows
customers and librarians to access the system remotely.
INTRODUCTION
This report will provide a detailed account of the processes our group
used to design and implement a database that can be used to manage
a library system. Each subsection of the report corresponds to an
important feature of database design.
REQUIREMENT ANALYSIS
A library database needs to store information pertaining to its users
(or customers), its workers, the physical locations of its branches, and
the media stored in those locations. We have decided to limit the
media to two types: books and videos.
The library must keep track of the status of each media item: its
location, status, descriptive attributes, and cost for losses and late
returns. Books will be identified by their ISBN, and movies by their
title and year. In order to allow multiple copies of the same book or
video, each media item will have a unique ID number.
Customers will provide their name, address, phone number, and date
of birth when signing up for a library card. They will then be assigned
a unique user name and ID number, plus a temporary password that
will have to be changed. Checkout operations will require a library
card, as will requests to put media on hold. Each library card will have
its own fines, but active fines on any of a customer's cards will prevent
the customer from using the library's services.
ER DESIGN
It is clear that the physical objects from the previous section – the
customers, employees, cards, media, and library branches –
correspond to entities in the Entity-Relationship model, and the
operations to be done on those entities – holds, checkouts, and so on
– correspond to relationships. However, a good design will minimize
redundancy and attempt to store all the required information in as
small a space as possible.
NORMALIZATION
As stated earlier, the tables in this database are in the Third Normal
Form (3 NF.) In order to decompose the relationships into this form,
we had to split Status table from the Media table. Each Media object
has a status code, and each status code has an associated description.
It would be redundant to store both codes and descriptions in the
Media object, so we created a dedicated Status table with the code as
the primary key.
The other tables were designed with optimization in mind. The Card
entity, for instance, was separated from the Customer entity to avoid a
functional dependency (since the "num" attribute of the Card entity
determines the "fines" attribute.)
GUI DESIGN
The first step in designing the GUI was to choose a means of accessing
the database. After evaluating various options, we settled on using the
JDBC API. The availability of JavaServer Pages on UNCC's servers was
an important factor, as it allowed us to develop our application using a
three-tier architecture. By using JDBC we could separate the
application logic from the DBMS as well as from clients. In addition to
simplifying operations on the database, this architecture makes
extending the functionality of our system easier. When adding a new
feature or improving an existing one, we will not need to change the
database; it will only be necessary to modify the Java portion of the
code.