database management system
Select an organization or case
•Legacy System
•Current System & it’s weakness
•Proposed System
•Features of Proposed System
•(Must have at least three tables)
•Requirement Analysis
•
LibraryManagement System
Saira Iqbal
Concepts on Database
L0290KKKK1110
MSc (IT)QP
A Database Design for College Library
Abstract
Library management refers to the issues involved in managing the resources available in library such
as classification of material, book processing and borrowing materials. UK market is mature and
different systems are employed by the libraries to manage their resources in an efficient manner but
still many libraries remain unconvinced and show reluctance to employ and switch over to new
systems
In the following sections I will analyze the limitations of existing manual system employed by a
college library and will mainly focus on the solution to provide a centralized repository enabling the
library administrator to store, access and process the information when required. A prototype of the
database to hold the information will be designed considering the available techniques and
methodologies and then finally the new system prototype will be created in the light of
recommendations and outcomes of the initial analysis and design. MySQL DBMS will be
recommended and used for developing the prototype of the system. I will use relational database
system to represent the relation between assets of library and which will shows the data library holds.
Report will also include a complete illustration of the final prototype and justification of adopting the
methodologies and technologies.
1.0 Introduction
1.1 Background
Library database system is designed to maintain the library assets in a suitable way. This report is
about a rational database design of a college library in which members of the library can keep track
on availability of books, information about membership either they are student or staff of college,
they can join or leave library and some responsibilities of librarians are added.
The core goals of this report are to define the entities, attributes and their relationship to create a
database that can be easily manage by admin.
Following are the facilities:
Librarian: can find if the book is available or not its status and how much fine is due
Member: can borrow & return books and can leave and join library
In the report the findings describe the deficiency of data keeping method and, which can be increase
the budget to hire manpower. Following these findings, conclusions are drawn and a number of
recommendations are made as to how to increase the reliability of data, reduce redundancy and
accessibility to data has been made stress-free.
1.2 Objectives
The objectives of this report are to provide complete database for college library which will help to
minimize the duplication of data, get rid from paper filling system and it makes the processing of data
very easy without waste of time.
1.3 Scope
This report examines that any educational system can use it in their libraries to determine about the
author detail, publisher’s detail, availability of books, can track members record etc. and it is very
easy to modify by making changes in database. It does not examine online system of library
1.4 Technology Used
MYSQL 5.0.0 in wamp server
MS Visio 2010
DeZign for Database V6
MS word 2010
2.0 Types of
s
There are two types of library management systems; one is old fashioned which is used to keep library
resource’s detail manually but now a days computerized library systems are used because this is the
world of technology and development so people preferred to use computer based systems rather than
manual.
2.1 Advantages of Computer based library management system
It provides fast tracking of material
Increased Consistency
Reduce workforce to maintain library resources
Less expensive because only once you need to spend money on system
No duplication of records
Occupy less space as for paper based system there should be separate space to keep them
Security of the system by authorizing access to limited people according to their rights
2.3 Disadvantages
Risk of hardware or software failure
Data can be crashed
Training required to understand the system
It required high conversion cost to transform file-based system into computer based system
In this section I will describe about the legacy system and about the proposed system.
3.1 Current System
Existing system of the library is manual system which has lack of functionalities. As due to large
volume of books and daily based queries system is not comfortable to handle daily transaction
properly.
Current system work as
i- Membership
Students needs to get membership by filling a “new membership form” available in library
and provide this form to librarian with deposit of £25 which are refundable at the end of
course.
ii- Borrow books
Students request for books then librarian issues them books first by checking in registers if
these books are issued to someone else or not it took so long, once he/she found book, he
took book card from the book and write the date of issue and return of book and attached
student membership card along with this card after that put in to record register which are
sorted by book category wise. Student can hold maximum of nine days one book.
iii- Return books
When student come to return book the librarian check in a record register the data of issue
and date of return of book along with the book card and student card and return the student
membership card to student and place book in rack in sorted manner
.
iv- Fine Calculated
If the due date of books is passed then librarian calculated the difference between the issue
date of book and return date of book. Fine is considered to be 50 p per day after due date.
3.1.1 Current system weaknesses
Difficult to arrange all data in alphabetical order
Take time to find book status
More staff is required to manage library
Expensive
By in/out process of cards may cause damage to card which create problem to identify which
book is issued to which student
Modification of record took so long to find all data in different registers
Loss of assets
Difficult to understand for new employee
3.2 New System
New features which will be incorporated with database design for library which can handle all queries
regarding library and maintain its assets accordingly.
3.2.1 Features of Proposed System
Detail of each student/member is stored in database
Large number of volume of books are easily maintained
List of students with same category can be viewed
List of available books can be viewed
Fine is easily calculated by system automatically
Librarians can add/modify/delete students and books
Can see the list of issued books
List of books not returned on time by entering their id or name of book
Borrowing of book become easy because in database librarian can find in seconds if this is
book is issued to someone else or not
Librarians has password and login detail of database so it is secure process
It’s a right time to rebuild the library system because as day by day number of students and staff are
increasing in our institute and size of library is also expanding so we need workforce to handle it
that’s why there should be a seamless process which can handle all this pressure in proper way. At
that point our teacher suggested the creation of relational database system which can manage all these
problems
4.1 Requirement Analysis
Our library database system provides cost effective and efficient procedure to maintain data of library.
It needs to store student details because it’s an internal library of college so we don’t need to store any
customer’s data. We store staff detail, librarian details and available resources i.e. books, journals,
cds, racks etc. detail in our database.
Students need to register in library to get membership which has limit of one year so at time of
registration he needs to provide his name, course name, id, DOB and address. A library card can be
issued to him after storing details in system.
Books has unique number for their identity and category type, author name, publisher name, copy
number etc. and library must have record of which book is issued to which member of library and
either its return on time or not and calculation of fine overdue.
When a student borrows a book an entry of his name is entered in database by librarian and return
date is automatically comes up in system. It also shows how many books are issued to one member.
They can only borrowed maximum of five books at a time.Before borrowing any book members of
library can check if the book is available or not.
Tasks of librarians are following:
Add members
Add library cards and assign them to members
Handle returns
Check fines
Add books/ assets to the database
Remove assets from the database
Receive payments from members and update the fines
View all member’s detail
There are three phases of database system design model, first is conceptual design second is logical
design and third is physical model in which data has been placed in database. In our system all these
three phases have been designed and described accordingly.
5.1 Conceptual Design (ER Diagram)
“ERD or Entity-relationship model, a graphical representation of entities and their relationships to
each other, typically used in computing in regard to the organization of data within databases”
It is cleared from above discussion that main entities of Library are, members (student or staff), books
and librarians which store data regarding any queries e.g. how many books are borrowed, fine payable
etc. In this diagram we try to show possible entities and their relationship with each other and what
attributes they hold. Using ER Design redundancy of many items can be reduced and it’s a good
practice to show relation among entities.
Cardinality of the relationship/Multiplicity is described as:
An Author can write many books (1:*)
A book can have many authors (1:*)
A book can have many categories (1:*)
A member can be associated with zero or many books borrowed (0:*)
A borrowed transaction must only be associated with one and only one member (1:1)
Books can have zero or many transactions…… (0: *)
Librarian handle transactions ………. (1 :*)
Librarian creates membership… ….. (1 :*)
Librarian perform fine transaction… (1 :*)
Borrow transactions on fines… (1:0)
Members pays fine ……………………….. (1:*)
Members can have only one membership… ………. (1 :1)
logically yes but in database its 1:* because there will be always one active
Identifying relationship is when child object is dependent on parent object.
Shown as dotted line: – – – – – – – – –
Non-identifying relationship is when the primary key attributes of the parent must not become
primary key attributes of the child
Defined as continuous line :
In this diagram we can see that entity borrow_transaction is dependent on librarian, books and
members entities because for every transaction these three requirements are necessary. A librarian can
issue books, Librarian provides membership and done transactions on books and can also get fine
from members. Because many transactions can be done on many books at same time we associate
books with transactions. In this EERD we can see the clear many to many relations of books and
author and similarly for books and categories entity. This diagram show dependencies of relation and
reduce redundancy problems as well.
5.2 Logical Design (Relational Database Schema)
After ER design of library system we found new relations between entities and try to summarize them
into proper relations (tables):
Entities & their Relationships Detail
Table: Author
Column name Primary key Data type Not
NULL
Comment
author_id {PK} Yes INTEGER Yes Primary Key (author_id)
first_name No VARCHAR(40) No First Name of Author
last_name No VARCHAR(40) No Last Name of Author
Relationships:
Name Relationship
type
Parent Child Cardinality
author_books_by_author Identifying author books_by_author Zero Or More
Table: Books
Column name Primary key Data type Not NULL Comment
book_id {PK} Yes INTEGER Yes PRIMARY KEY (book_id)
pub_id {FK} No INTEGER No FOREIGN KEY (pub_id)
REFERENCES
Publisher(pub_id)
book_title No VARCHAR(40) No Title of book
edition No VARCHAR(40) No Name of publisher
availability No BOOL No Book available or not
num_of_copies No INTEGER No Quantity of books
state No VARCHAR(40) No Good,bad,excellent
catalog_number No INTEGER No Rack number
row_number No INTEGER No Rows in a rack
active No BOOL No Is book stolen, damage or lost
then it would be 0 otherwise 1
Created_by No VARCHAR(40) No For internal auditing purpose
name of librarian who created
entry in DB
Updated_by No VARCHAR(40) No For internal auditing purpose
name of librarian who updated
entry in DB
created No DATETIME No Date time of creation
updated No DATETIME No Date time of updating
Relationships:
Name Relationship
type
Parent Child Cardinality
books_books_by_author Identifying books books_by_author Zero Or More
books_books_by_category Identifying books books_by_category Zero Or More
books_borrow_transaction Non Identifying
books borrow_transaction Zero Or More
Publisher_books Non Identifying Publisher books One Or More
Table: books_by_author
Column name Primary key Data type Not Comment
NULL
author_id Yes INTEGER Yes PK & FOREIGN KEY (author_id)
REFERENCES author(author_id)
book_id Yes INTEGER Yes PK & FOREIGN KEY (book_id)
REFERENCES books(book_id)
Relationship:
Name Relationship
type
Parent Child Cardinality
author_books_by_author Identifying author books_by_author Zero Or More
books_books_by_author Identifying books books_by_author Zero Or More
Table: books_by_category
Column name Primary key
Data type Not
NULL
Comment
category_id Yes INTEGER Yes PK & FOREIGN KEY (category_id)
REFERENCES
Categories(category_id)
book_id Yes INTEGER Yes PK & FOREIGN KEY (book_id)
REFERENCES books(book_id)
Relationships:
Name Relationship
type
Parent Child Cardinality
books_books_by_category Identifying books books_by_category Zero Or More
Categories_books_by_category Identifying Categories books_by_category Zero Or More
Table: Borrow_Transactions
Column name Primary
key
Data type Not
NULL
Comment
borrow_transaction_id Yes INTEGER Yes PRIMARY KEY
(borrow_transaction_id)
librarian_id No INTEGER Yes FOREIGN KEY
(librarian_id)
REFERENCES
librarian(librarian_id)
book_id No INTEGER Yes FOREIGN KEY (book_id)
REFERENCES
books(book_id)
member_id No INTEGER Yes FOREIGN KEY
(member_id)
REFERENCES
members(member_id)
borrowed_datetime No DATETIME No When the book is borrowed
returned_datetime No DATETIME No When the book is returned
borrowed_by No VARCHAR(40) No Who borrowed (name of
member)
returned_by No VARCHAR(40) No Who returned
date_due No DATE No Due date of book borrowed
is_returned No BOOL No If returned 1 otherwise 0
created_by No VARCHAR(40) No For internal auditing
purpose name of librarian
who created entry in DB
Updated_by No VARCHAR(40) No For internal auditing
purpose name of librarian
who updated entry in DB
created No DATETIME No Date time of creation
updated No DATETIME No Date time of updating
Relationships:
Name Relationship
type
Parent Child Cardinality
books_borrow_transaction
Non
Identifying
books borrow_transaction Zero Or More
borrow_transaction
_fined_transactions
Non
Identifying
borrow_transaction fined_transactions Zero Or One
librarian_borrow_transaction Non
Identifying
librarian borrow_transaction Zero Or More
members_borrow_transaction Non
Identifying
members borrow_transaction One Or More
Table: Categories
Column name Primary key Data type Not
NULL
Comment
category_id Yes INTEGER Yes PRIMARY KEY (category_id)
category_name No VARCHAR(40) No Name of category e.g Science,
Crime etc
Relationships:
Name Relationship
type
Parent Child Cardinality
Categories_books_by_category Identifying Categories books_by_category Zero Or More
Table: Fined_Transactions
Column name Primary
key
Data type Not
NULL
Comment
fined_transaction_id Yes INTEGER Yes PRIMARY KEY (fined_transaction_id)
member_id No INTEGER Yes FOREIGN KEY (member_id)
REFERENCES members(member_id)
librarian_id No INTEGER Yes FOREIGN KEY (librarian_id)
REFERENCES librarian(librarian_id)
borrow_transaction_id No INTEGER Yes FOREIGN KEY (borrow_transaction_id)
REFERENCES
borrow_transaction(borrow_transaction_id)
amount_added No VARCHAR(40) No Total Amount Fined
amount_received No VARCHAR(40) No Amount received till date
notes No VARCHAR(40) No To add notes
deleted No DATETIME No Date & Time of Deletion
created No DATETIME No Date & time of transaction creation
created_by No VARCHAR(40) No For internal auditing purpose name of
librarian who created entry in DB
Relationship:
Name Relationshi
p type
Parent Child Cardinality
borrow_transaction
_fined_transactions
Non
Identifying
borrow_transaction fined_transactions Zero Or
One
librarian_fined_transactions Non
Identifying
librarian fined_transactions Zero Or
More
members_fined_transactions Non
Identifying
members fined_transactions Zero Or
More
Table: Librarian
Column name Primary
key
Data type Not
NULL
Comment
librarian_id Yes INTEGER Yes PRIMARY KEY
(librarian_id)
name No VARCHAR(40) No Librarian Name
user_name No VARCHAR(40) No User name assigned to
librarian
password No VARCHAR(40) No Password for login
created_by No VARCHAR(40) No For internal auditing
purpose name of librarian
who created entry in DB
updated_by No VARCHAR(40) No For internal auditing
purpose name of librarian
who updated entry in DB
created No DATETIME No Date time of creation
updated No DATETIME No Date time of updating
active No BOOL No If librarian is active or
not
inactive_reason No VARCHAR(40) No Why not active
Relationship:
Name Relationship
type
Parent Child Cardinality
librarian_borrow_transaction Non Identifying librarian borrow_transaction Zero Or More
librarian_fined_transactions Non Identifying librarian fined_transactions Zero Or More
librarian_membership Identifying librarian membership Zero Or More
Table: Members
Column name Primary
key
Data type Not
NULL
Comment
member_id Yes INTEGER Yes PRIMARY KEY
(member_id)
external_id No INTEGER Yes ID For library use
member_type No VARCHAR(40) No Either its staff or student
member_name No VARCHAR(40) No Name of member
phone_number No INTEGER No Contact number of
member
gender No VARCHAR(40) No Male or Female
email No VARCHAR(40) No Email address
active No BOOL No Active or inactive
created_by No VARCHAR(40) No For internal auditing
purpose name of librarian
who created entry in DB
updated_by No VARCHAR(40) No For internal auditing
purpose name of librarian
who updated entry in DB
created No DATETIME No Date time of creation
updated No DATETIME No Date time of updating
Relationships:
Name Relationship type Parent Child Cardinality
members_borrow_transaction Non Identifying members borrow_transaction One Or More
members_fined_transactions Non Identifying members fined_transactions Zero Or More
members_membership Identifying members membership Exactly One
In logical design model we can see the all entities, their data types, constraints on them and their
relations.
5.3 Normalization
Tables in database are designed to use third normal form (3NF). As we know that to use third normal
form our table must satisfy the requirement of first normal form ((1NF) and second normal form
(2NF). Most of the tables in database have been designed to keep optimization in mind. We use
normalization to remove update, delete & insert anomalies.
I have used the following way to normalize my tables. I have explained only one table here:
My books table before normalization
Book_id Book_title Edition Book_category1 Book_category2 Publisher Author_name
1NF
By implementing First Normal formal I have to check that there should be no multiple values against
any field of a table and I have to create a separate table for each set of related data with unique
primary key. To apply first normal form I make some changes in above table, I separate author_name
field into two fields (first name & last name) and identify book_id as primary_key.
Book_id Book_titl e Edition Book_category1 Book_category2 Publisher Author_Fname Author_Lname
2NF
For 2nd Normal form the non key attributes should be fully dependent on composite primary key,
partial dependency is not allowed.
First I created two tables from above tables to associate with repeating group of data and relate them
with foreign key. After this I have to check that each non-key field in the table will be an attribute that
describes that Primary Key
Books Table
Book_id Book_titl
e
Edition Book_categories Publisher
Author Table
Book_id author_fname author_lname
By using 2NF two tables created books table with books detail but no repeat fields as in 1NF and
author table associated with books table none of no-key element is partially dependent on primary
key.
3NF
The final normalization of my table is 3rd normal form. To achieve this normal form I have to
eliminate the non-key values which are not fully functionally dependent on primary key of the table.
Author Table
As author name is not directly dependent on book id so a separate table is created for it with its own
primary key id
author_id First_name lastname
11 Denial Shah
12 Iqbal Mittal
Book_by_author Table:
The relationship between book and author table is maintained in book_author table which is many to
many as many a book has many authors and an author can write many books. This relation is
established by creating a third table book_author which maps book to author and vice versa. This
table contains two fields both as foreign keys which refer to book and author table respectively to
establish one to many relationship on both sides.
Book_id author_id
5001 11
5002 122
Books Table
Publisher id is used as foreign key.
Book_id Book_title Pub_id Edition availability No.of copies state active
5001 COD 620 1st yes 10 good 1
Same rule is applied for category table as author’s table. The membership is separated from member’s
table to avoid functional dependency. And similarly we split publisher table from books table to avoid
data duplication. fined_transactions table is kept separate from borrowed_transactions table in order
to minimize redundancy.
5.4 Physical database Design
After logical design of database I put data in database to create table and their attributes, I run
following queries in MYSQL console:.
Add Table “books”
————————
CREATE TABLE `books` (
`book_id` INTEGER NOT NULL,
`book_title` VARCHAR(40),
`edition` VARCHAR(40),
`pub_name` VARCHAR(40),
`pub_date` DATE,
`availability` BOOL,
`num_of_copies` INTEGER,
`state` VARCHAR(40),
`catalog_number` INTEGER,
`row_number` INTEGER,
`active` BOOL,
`created_by` VARCHAR(40),
`update_by` VARCHAR(40),
`created` VARCHAR(40),
`updated` VARCHAR(40),
CONSTRAINT `PK_books` PRIMARY KEY (`book_id`)
);
Add Table “borrow_transaction”
——————————————
CREATE TABLE `borrow_transaction` (
`borrow_transaction_id` INTEGER NOT NULL,
`librarian_id` INTEGER NOT NULL,
`book_id` INTEGER NOT NULL,
`member_id` INTEGER NOT NULL,
`borrowed_datetime` DATETIME,
`returned_datetime` DATETIME,
`borrowed_by` VARCHAR(40),
`returned_by` VARCHAR(40),
`date_due` DATE,
`is_returned` BOOL,
`created_by` VARCHAR(40),
`updated_by` VARCHAR(40),
`created` VARCHAR(40),
`updated` VARCHAR(40),
CONSTRAINT `PK_borrow_transaction` PRIMARY KEY (`borrow_transaction_id`)
);
Add Table “librarian”
——————————
CREATE TABLE `librarian` (
`librarian_id` INTEGER NOT NULL,
`name` VARCHAR(40),
`user_name` VARCHAR(40),
`password` VARCHAR(40),
`created_by` VARCHAR(40),
`updated_by` VARCHAR(40),
`created` VARCHAR(40),
`updated` VARCHAR(40),
`active` BOOL,
`inactive_reason` VARCHAR(40),
CONSTRAINT `PK_librarian` PRIMARY KEY (`librarian_id`)
);
Add Table “member”
—————————
CREATE TABLE `members` (
`member_id` INTEGER NOT NULL,
`external_id` INTEGER,
`member_type` VARCHAR(40),
`member_name` VARCHAR(40),
`phone_number` INTEGER,
`gender` VARCHAR(40),
`email` VARCHAR(40),
`active` BOOL,
`created_by` VARCHAR(40),
`updated_by` VARCHAR(40),
`created` VARCHAR(40),
`updated` VARCHAR(40),
CONSTRAINT `PK_members` PRIMARY KEY (`member_id`)
);
Add Table “membership”
——————————–
CREATE TABLE `membership` (
`librarian_id` INTEGER NOT NULL,
`member_id` INTEGER NOT NULL,
`registred_datetime` DATETIME,
`registred_by` VARCHAR(40),
`membership_status` BOOL,
`membership_expiry_date` DATE,
PRIMARY KEY (`librarian_id`, `member_id`)
);
Add Table “fined_transactions”
—————————————
CREATE TABLE `fined_transactions` (
`fined_transaction_id` INTEGER NOT NULL,
`member_id` INTEGER NOT NULL,
`librarian_id` INTEGER NOT NULL,
`borrow_transaction_id` INTEGER NOT NULL,
`amount_added` VARCHAR(40),
`amount_received` VARCHAR(40),
`notes` VARCHAR(40),
`deleted` VARCHAR(40),
`created` VARCHAR(40),
`created_by` VARCHAR(40),
CONSTRAINT `PK_fined_transactions` PRIMARY KEY (`fined_transaction_id`)
);
Foreign key constraints
——————————
>ALTER TABLE `borrow_transaction` ADD CONSTRAINT `books_borrow_transaction`
FOREIGN KEY (`book_id`) REFERENCES `books` (`book_id`);
>ALTER TABLE `borrow_transaction` ADD CONSTRAINT ̀ librarian_borrow_transaction`
FOREIGN KEY (`librarian_id`) REFERENCES `librarian` (`librarian_id`);
>ALTER TABLE `borrow_transaction` ADD CONSTRAINT ̀ members_borrow_transaction`
FOREIGN KEY (`member_id`) REFERENCES `members` (`member_id`);
>ALTER TABLE `membership` ADD CONSTRAINT ̀ librarian_membership`
FOREIGN KEY (`librarian_id`) REFERENCES `librarian` (`librarian_id`);
>ALTER TABLE `membership` ADD CONSTRAINT `members_membership`
FOREIGN KEY (`member_id`) REFERENCES `members` (`member_id`);
>ALTER TABLE `fined_transactions` ADD CONSTRAINT `librarian_fined_transactions`
FOREIGN KEY (`librarian_id`) REFERENCES `librarian` (`librarian_id`);
>ALTER TABLE `fined_transactions` ADD CONSTRAINT
`borrow_transaction_fined_transactions`
FOREIGN KEY (`borrow_transaction_id`) REFERENCES `borrow_transaction`
(`borrow_transaction_id`);
>ALTER TABLE `fined_transactions` ADD CONSTRAINT `members_fined_transactions`
FOREIGN KEY (`member_id`) REFERENCES `members` (`member_id`);
>ALTER TABLE `author` ADD CONSTRAINT `books_author`
FOREIGN KEY (`book_id`) REFERENCES `books` (`book_id`);
“is a family of computer languages used by computer programs and/or database users to insert, delete
and update data in a database. Currently the most popular data manipulation language is that of SQL,
which is used to retrieve and manipulate data in a Relational database.”
Following queries are used to insert, update and delete data from database(shown few queries only):
INSERT INTO `author` (`author_id`, `first_name`, `last_name`) VALUES (2006, ‘edoh’, ‘sanda’);
INSERT INTO `books` (`book_id`, `pub_id`, `book_title`, `edition`, `availability`, `num_of_copies`,
`state`, `catalog_number`, `row_number`, `active`, `created_by`, `update_by`, `created`, `updated`)
VALUES (1, 0, ‘COD’, ‘2nd’, 1, 10, ‘excellent’, 3, 5, 1, ‘saira’, ‘saira’, ‘2010-10-12 12:10:03’,
‘2010-10-12 12:10:03’);
INSERT INTO `books_by_author` (`author_id`, `book_id`) VALUES (2006, 3);
INSERT INTO `categories` (`category_id`, `category_name`) VALUES (1746, ‘Computing’);
INSERT INTO `fined_transactions` (`fined_transaction_id`, `member_id`, `librarian_id`,
`borrow_transaction_id`, `amount_added`, `amount_received`, `notes`, `deleted`, `created`,
`created_by`) VALUES (1, 4, 2, 1, ‘0’, ‘0’, ‘no fine’, ‘2011-02-06’, ‘2011-02-02 10:03:01’, ‘saira’);
UPDATE books SET book_title = ‘MCIP’ WHERE book_id= 3;
DELETE from books WHERE book_title =’NE’;
6.1 Functionality of SQL Statements
To fetch available copies of a specific book
——————————————————
SELECT (books.num_of_copies- temp.borrowed_books_count ) as available_copies
FROM books LEFT JOIN (
SELECT count(*) as borrowed_books_count
FROM borrow_transaction
WHERE book_id=1
AND is_returned=0
) as temp
ON books.book_id=1
WHERE books.book_id=1;
To find books with overdue date
——————————————
SELECT members.member_name, books.book_title, borrow_transaction.borrowed_datetime,
borrow_transaction.date_due
FROM borrow_transaction
LEFT JOIN members ON borrow_transaction.member_id=members.member_id
LEFT JOIN books ON borrow_transaction.book_id=books.book_id
WHERE Date_due <= '2011-02-07' AND is_returned=0
Search fine payable against members
-----------------------------------------------------
SELECT members.member_id, members.member_name,
(sum(amount_added)-sum(amount_received) )payable_amount
FROM members
Left Join fined_transactions ON fined_transactions.member_id = members.member_id
group by members.member_id having (sum(amount_added)-sum(amount_received) ) > 0
Some other functions
—————————
SELECT member_id,librarian_id,amount_added from fined_transactions
WHERE amount_added>5;
SELECT member_type, member_name from members
WHERE member_type!=’student’;
SELECT member_name,member_type,gender
FROM members ORDER BY member_name DESC;
SELECT book_title, pub_name
FROM books WHERE pub_name LIKE ‘%william%’;
The main conclusion that can be drawn is therefore that using MySQL database system has been
designed for college library which can be used to store data regarding books, members of library and
can also update, delete and add new records.
This database is designed with that flexibility that it can be implemented in any library in future; it
can be modified easily into new technology. We can add as many data as required.
In the light of these conclusions, I recommend that database should be designed for every library.
We should establish online library system by using this database design at backend
In addition, continue to investigate new languages for database design so that a better access to
database resources would be happen in future.
- Library Management System
- 2.0 Types of Library Management Systems
A Database Design for College Library
1.1 Background
Following are the facilities:
1.2 Objectives
1.4 Technology Used
2.1 Advantages of Computer based library management system
2.3 Disadvantages
3.0 Legacy System and Proposed System
3.1 Current System
Current system work as i- Membership
ii- Borrow books
iii- Return books
iv- Fine Calculated
3.1.1 Current system weaknesses
3.2 New System
3.2.1 Features of Proposed System
4.0 Literature Review
4.1 Requirement Analysis
Tasks of librarians are following:
5.0 New System Design
5.1 Conceptual Design (ER Diagram)
Cardinality of the relationship/Multiplicity is described as:
Entities & their Relationships Detail Table: Author
5.3 Normalization
My books table before normalization
2NF
Books Table
3NF
Author Table
Book_by_author Table:
Books Table
5.4 Physical database Design
Add Table “books”
Add Table “borrow_transaction”
Add Table “librarian”
Add Table “member”
Add Table “membership”
Add Table “fined_transactions”
Foreign key constraints
6.0 Data Manipulation Language (DML)
6.1 Functionality of SQL Statements
To fetch available copies of a specific book
To find books with overdue date
Search fine payable against members
Some other functions
7.0 Conclusion
8.0 Recommendations