18-05-2012, 04:56 PM
LIBRARY MANAGEMENT SYSTEM: DESIGN AND IMPLEMENTATION
LIBRARY.pdf (Size: 299.9 KB / Downloads: 980)
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.
The library will have branches in various physical locations. Branches
will be identified by name, and each branch will have an address and a
phone number associated with it. Additionally, a library branch will
store media and have employees.
Employees will work at a specific branch of the library. They receive a
paycheck, but they can also have library cards; therefore, the same
information that is collected about customers should be collected about
employees.
Functions for customers:
● Log in
● Search for media based on one or more of the following criteria:
○ type (book, video, or both)
○ title
○ author or director
○ year
● Access their own account information:
○ Card number(s)
○ Fines
○ Media currently checked out
○ Media on hold
● Put media on hold
● Pay fines for lost or late items
● Update personal information:
○ Phone numbers
○ Addresses
○ Passwords
Functions for librarians are the same as the functions for customers
plus the following:
● Add customers
● Add library cards and assign them to customers
● Check out media
● Manage and transfer media that is currently on hold
● Handle returns
● Modify customers' fines
● Add media to the database
● Remove media from the database
● Receive payments from customers and update the customers'
fines
● View all customer information except passwords
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. After some consideration, we have decided
on the following design:
![Adobe Acrobat PDF .pdf](https://seminarproject.net/images/attachtypes/pdf.gif)
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.
The library will have branches in various physical locations. Branches
will be identified by name, and each branch will have an address and a
phone number associated with it. Additionally, a library branch will
store media and have employees.
Employees will work at a specific branch of the library. They receive a
paycheck, but they can also have library cards; therefore, the same
information that is collected about customers should be collected about
employees.
Functions for customers:
● Log in
● Search for media based on one or more of the following criteria:
○ type (book, video, or both)
○ title
○ author or director
○ year
● Access their own account information:
○ Card number(s)
○ Fines
○ Media currently checked out
○ Media on hold
● Put media on hold
● Pay fines for lost or late items
● Update personal information:
○ Phone numbers
○ Addresses
○ Passwords
Functions for librarians are the same as the functions for customers
plus the following:
● Add customers
● Add library cards and assign them to customers
● Check out media
● Manage and transfer media that is currently on hold
● Handle returns
● Modify customers' fines
● Add media to the database
● Remove media from the database
● Receive payments from customers and update the customers'
fines
● View all customer information except passwords
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. After some consideration, we have decided
on the following design: