Report - Final (PDF Library)
Report - Final (PDF Library)
ABSTRACT
LIST OF ILLUSTRATIONS
Figures
Figure 1: ER Diagram................................................................ 4
Tables
Table 1: Relational Database Schema.......................................... 6
TABLE OF CONTENTS
Abstract................................................................................. ii
List of Illustrations................................................................ iii
Introduction.......................................................................... 1
Requirement Analysis............................................................ 2
ER Design.............................................................................. 4
Relational Database Design.................................................... 6
Normalization........................................................................ 8
Physical Database Design...................................................... 9
GUI Design............................................................................ 13
Conclusions and Future Work................................................. 19
Appendices............................................................................ 20
A. ER Diagram............................................................. 20
B. Website Layout........................................................ 21
1
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.
2
REQUIREMENT ANALYSIS
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.
○ 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
4
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:
Figure 1: ER Diagram
Refer to Appendix A for a zoomed-in view.
Notice that the information about books and videos has been
separated from the Media entity. This allows the database to store
multiple copies of the same item without redundancy. The Status
entity has also been separated from Media in order to save space. The
5
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.)
9
The next step was to create the physical database and input some
sample data. In order to turn the relational design into a database, we
ran the following script in UNCC's Oracle database:
CREATE TABLE Status ( code INTEGER, description CHAR(30), PRIMARY KEY (code) );
CREATE TABLE Media( media_id INTEGER, code INTEGER, PRIMARY KEY (media_id),
FOREIGN KEY (code) REFERENCES Status );
CREATE TABLE Book(ISBNCHAR(14), title CHAR(128), author CHAR(64),
year INTEGER, dewey INTEGER, price REAL, PRIMARY KEY (ISBN) );
CREATE TABLE BookMedia( media_id INTEGER, ISBN CHAR(14), PRIMARY KEY (media_id),
FOREIGN KEY (media_id) REFERENCES Media,
FOREIGN KEY (ISBN) REFERENCES Book);
CREATE TABLE Customer( ID INTEGER, name CHAR(64), addr CHAR(256), DOB CHAR(10),
phone CHAR(30), username CHAR(16), password CHAR(32), PRIMARY KEY (ID),
UNIQUE (username) );
CREATE TABLE Card( num INTEGER, fines REAL, ID INTEGER, PRIMARY KEY (num),
FOREIGN KEY (ID) REFERENCES Customer );
CREATE TABLE Checkout( media_id INTEGER, num INTEGER, since CHAR(10),
until CHAR(10), PRIMARY KEY (media_id),
FOREIGN KEY (media_id) REFERENCES Media,
FOREIGN KEY (num) REFERENCES Card );
CREATE TABLE Location( name CHAR(64), addr CHAR(256), phone CHAR(30),
PRIMARY KEY (name) );
CREATE TABLE Hold( media_id INTEGER, num INTEGER, name CHAR(64), until CHAR(10),
queue INTEGER, PRIMARY KEY (media_id, num),
FOREIGN KEY (name) REFERENCES Location,
FOREIGN KEY (num) REFERENCES Card,
FOREIGN KEY (media_id) REFERENCES Media );
CREATE TABLE Stored_In( media_id INTEGER, name char(64), PRIMARY KEY (media_id),
FOREIGN KEY (media_id) REFERENCES Media ON DELETE CASCADE,
FOREIGN KEY (name) REFERENCES Location );
CREATE TABLE Librarian( eid INTEGER, ID INTEGER NOT NULL, Pay REAL,
Loc_name CHAR(64) NOT NULL, PRIMARY KEY (eid),
FOREIGN KEY (ID) REFERENCES Customer ON DELETE CASCADE,
FOREIGN KEY (Loc_name) REFERENCES Location(name) );
CREATE TABLE Video( title CHAR(128), year INTEGER, director CHAR(64),
rating REAL, price REAL, PRIMARY KEY (title, year) );
CREATE TABLE VideoMedia( media_id INTEGER, title CHAR(128), year INTEGER,
PRIMARY KEY (media_id), FOREIGN KEY (media_id) REFERENCES Media,
FOREIGN KEY (title, year) REFERENCES Video );
INSERT INTO Customer(ID, name, addr, DOB, phone, username, password) VALUES
(60201, 'Jason L. Gray', '2087 Timberbrook Lane, Gypsum, CO 81637',
'09/09/1958', '970-273-9237', 'jlgray', 'password1');
INSERT INTO Customer(ID, name, addr, DOB, phone, username, password) VALUES
(89682, 'Mary L. Prieto', '1465 Marion Drive, Tampa, FL 33602',
'11/20/1961', '813-487-4873', 'mlprieto', 'password2');
INSERT INTO Customer(ID, name, addr, DOB, phone, username, password) VALUES
10
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.
/* *\
Functions available to customers
\* */
FROM Customer C
WHERE C.username = <user input> AND C.password = <user input>;
/* Find all copies of a book (used for placing holds or viewing detailed
information). */
SELECT BM.media_id, S.description,
nvl((SELECT SI.name
FROM Stored_In SI
WHERE SI.media_id = BM.media_id), 'none') AS name
FROM BookMedia BM, Media M, Status S
WHERE BM.ISBN = <user input> AND M.media_id = BM.media_id AND S.code = M.code;
/* Find all copies of a video (used for placing holds or viewing detailed
information). */
SELECT VM.media_id, S.description,
nvl((SELECT SI.name
FROM Stored_In SI
WHERE SI.media_id = VM.media_id), 'none') AS name
FROM VideoMedia VM, Media M, Status S
WHERE VM.title = <user input> AND VM.year = <user input> AND
M.media_id = VM.media_id AND S.code = M.code;
/* *\
Functions reserved for librarians
\* */
/* Find a customer */
SELECT C.ID, C.name, C.addr, C.DOB, C.phone, C.username,
nvl((SELECT 'Librarian'
FROM Librarian L
WHERE L.ID = C.ID), 'Customer') AS role
FROM Customer C
WHERE C.username = <user input> AND C.name LIKE '%<user input>%';
The menus change based on the user's role: customers have basic
functions to search for media, view their account options, fines, and so
on, while librarians get an extended menu with administration-related
links. It should be noted that there is no special log in for librarians;
instead, the system accesses the database to find out whether the
user is a librarian and builds the menu dynamically.
APPENDIX A: ER Diagram
21