J –COMPONENT
REVIEW-2
DATABASE MANAGEMENT
SYSTEMS
Online Library Management
System
GROUP MEMBERS
Vinit Shahdeo
Shreya Deep Anand
Introduction
Manual process of keeping student records, book records,
account details, managing employee is very difficult. There are
various problems also faced by the student in library such as
finding any particular book, information whether book is
available or not, for what time this book will be available,
searching of books using ISBN number etc. To eliminate this
manual system, library management system has been
developed. Library Management System will handle all the
current issues faced by the students and by its admin
personnel.
To store all the information in the database from where user will
place their query and get the results on the basis of their query.
Only valid users will be able to access this Library Management
System. Through this Library Management System, it will be
easy to manage accounts and various details of particular
student and employees working under library along with the
records of book.
The current Library Management System does not eliminate the
process of searching books within the library campus. Students
have to find books manually. They have to wait until they are
not provided with their library card and token. For receiving
book, they have to show their library card and wait in line for
their turns. The admin personnel also have to look manually on
which day which person will take the charge within library to
manage the overall work.
Features
• Searching of books
• Issuing and returning books
• Paying fine(if any) online
• Librarian can read information about any member
• Librarian can track the books issued by a particular student
Functional Requirements
● The system must only allow user with valid id and
password to enter the system.
● The user must be able to logout after they finished using
system.
● System must be able to not allow two books having same
book id.
● System must be able to search if book is available or not
before issuing books.
● Admin can be able to see availability of the particular book,
they can also be able to see the each user data (ie. Which
book is issued to which user and the fine amount of the
user)
Data requirements
● There will be the data of each books in the database.
● There will be the user name and password of each
member and faculty in the database
● The record of the issued books will also be in the database.
● The record of all the members working in the library will be
there.
DETAILED DATA REQUIREMENT:
Library will be managed by the admin. Each admin will have it's
unique login id and password. The library will be managing the
books, staffs and members(both students and faculties).
Each staff will be having it's unique id, a name, designation,
salary, date_of_joining, address and dob.
Each of the books will have its unique book_code, a name, a
subject_code, no_of_books, rack_no, cost, date_of_purchase and
name of the author.
The members are the ones who would be accessing the library
system for issuing and returning books and paying fine when
not returned in time. The library consists of two members
Faculties and Students.
Faculty (member) will be having it's unique faculty id, a name,
an address, a contact number and a department. When the
faculty issues books, it will contain attributes faculty id and
book_id which in turn will contain issue and return date.
Student (member) will be having it's unique id, a name, an
address, a contact number and a branch. When the student
issues books, it will contain attributes id and book_id which in
turn will contain issue and return date.
Software and Languages required
FRONT END:
1. HTML
2. CSS
3. JAVASCRIPT
BACK END:
4. PHP
5. APACHE(server)
6. MYSQL
Entity types
1. BOOK
Strong entity set- book_code is used to identify each entity
uniquely
Book_code,book_name, Author, date_of_purchase, price,
subject_code, rack_no, no_of_books
2. STAFF
Strong entity set- staff_id is used to identify each entity
uniquely
Staff_id, staff_name, dob, address, designation, salary,
date_of_joining,
3. STUDENT
Strong entity type- student_id is used to identify each entity
uniquely
Student_id, name, branch, fine, address, phone_no, issue_date,
expiry_date
4. FACULTY
Strong entity type- f_id is used to identify each entity
uniquely
F_id, name, address, phone_no, department
5. LIBRARIAN
Strong entity type- admin_login is used to identify each
entity uniquely
Admin_login,admin_password
6. AUTHOR
Strong entity type- author_id is used to identify each entity
uniquely
Author_id,author_name, dob, address, experience
7. PERIODICALS
Strong entity type- pr_id is used to identify each entity
uniquely
pr_id, pr_name, month_of_release, publisher_name
Relationships
1. BOOK – STUDENT relationship
It’s a one to many relationship as one book can be issued by
only one student.
This participation is partial from both the side because all the
book cannot be issued and it is also not necessary that all
the students of the library is issuing the book.
2. BOOK – FACULTY relationship
It’s a one to many relationship as one book can be issued by
only one faculty.
This participation is partial from both the side because all the
book cannot be issued and it is also not necessary that all
the faculty is issuing the book.
3. All other relationship is managed by the librarian ie.
managing the other entity types of the library
Entity Relationship (ER) Diagram
Schema
All the entity set used in this entity relationship diagram is
strong so it can be directly reduced into relation schema as
shown in the schema below.
For binary 1: N relationship, relation representing the
participating entity type at N-side of relationship type is
identified. In this relation we include as foreign key the
primary key of relation that represents the other entity
type.
Relation schema
Functional Dependencies: -
{book_code}→{date_of_purchase,book_name,price,rack_no,no_of
_boo ks, subject_code}
{author_id}→{author_name, dob, address, experience}
{staff_id}→{staff_name, DOB, date_of_joining, address, salary,
designation}
{Member_id}→{name, type, address, issue_date, expiry_date,
phone_no, fine}
{faculty}→{name, address, phone_no, department}
{author_id}→{author_name, dob, address, experience}
{book_code,member_id}→{issue_date, return_date}
{book_code,f_id}→{issue_date, return_date}
Normalization: -
ent_id e ess ne_no _date y_date
y hi nagar, 325458 -2016 -2020
Chennai
adi 632588 -2016 7-2016
ash Delhi 0 523456 -2017 -2021
hant alore 965876 3-2015 3-2019
We have reduced the student table from ER diagram, the given
table is already in the First Normal Form since all the
attributes is single valued. All the attributes of the student
table are atomic.
Since the above table is already in the first normal form and
there is no chance of partial dependency on the key
attribute because it has only one key attribute so above
table is in second normal form
Closure of the attribute set
F={student_id→ name, student_id→ type, student_id→ address,
student_id→ fine, student_id→ phone_number, student_id→
issue_date, student_id→ expiry_date}
Student_id+ ={name, type, address, fine, phone_number,
issue_date, expiry_date}
Transitive Dependency
A transitive dependency can occur only in a relation that has
three
or more attributes. Let A, B, and C designate three distinct
attributes
(or distinct collections of attributes) in the relation.
● No non-prime attribute is transitively dependent on prime
key
attribute.
● For any non-trivial functional dependency, X → A, then
either −
● X is a superkey or,
● A is prime attribute.
Since there is no transitive dependency, the table is already in
Third
Normal Form
Boyde - Codd Normal Form
Since there is only one key attribute and key attribute is not
dependent on the non key attribute thus we can say that
the above table is in BCNF
2. Faculty (f_id,name, p
hone no, department, address)
The table is in BCNF. Due to the reason that f_id is the only
candidate
key and all others are non-key attributes thus table is in 2NF. No
non-key dependencies, hence in 3NF. One candidate key,
so in BCNF
3. BOOK (book_code, book_name, subject_code, no_of_books,
rack_no, price, Date_of_purchase)
The table is in BCNF. Due to the reason that book_code is the
only candidate key and all others are non-key attributes
thus table is in 2NF. No non-key dependencies, hence in
3NF. One candidate key, so in BCNF
4. STAFF (staff_id, staff_name, staff_name, address,
date_of_joining, salary, designation)
The table is in BCNF. Due to the reason that staff_id is the only
candidate key and all others are non-key attributes thus
table is in 2NF. No non-key dependencies, hence in 3NF.
One candidate key, so in BCNF
5. PERIODICALS (pr_id, pr_name, month_of_release,
publisher_name)
The table is in BCNF. Due to the reason that pr_id is the only
candidate key and all others are non-key attributes thus
table is in 2NF. No non-key dependencies, hence in 3NF.
One candidate key, so in BCNF
6. LIBRARIAN (admin_login, admin_password)
The table is in BCNF. Due to the reason that pr_id is the only
candidate key and all others are non-key attributes thus
table is in 2NF. No non-key dependencies, hence in 3NF.
One candidate key, so in BCNF
7. AUTHOR (author_id, author_name, dob, address,
experience)
The table is in BCNF. Due to the reason that author_id is the
only candidate key and all others are non-key attributes
thus table is in 2NF. No non-key dependencies, hence in
3NF. One candidate key, so in BCNF
8. issued_by_stu (student_id, book_code, issue_date,
return_date)
The table is in BCNF. Due to the reason each attribute is atomic.
Issue_date and return_date is dependent on the
student_id and book_code and no partial dependency
exists so the table is in second normal form. No transitive
dependency exists in this table so it is in third normal form.
And none of the non- key attribute is dependent on the
key attribute so the above table is in BCNF.
9. issued_by_fac (f_id, book_code, issue_date, return_date)
The table is in BCNF. Due to the reason each attribute is atomic.
Issue_date and return_date is dependent on the f_id and
book_code and no partial dependency exists so the table is
in second normal form. No transitive dependency exists in
this table so it is in third normal form. And none of the non-
key attribute is dependent on the key attribute so the
above table is in BCNF.
