Hostel Management System

Ansh Bhardwaj – 2022UEE0124

Satvik Jain – 2022UEE0148
Pranjal Verma – 2022UEE0145
Ankit – 2022UEE0123
1 Objective
The ER diagram represents a hostel management system designed
to handle student accommodation, room management, furniture
tracking, and financial transactions within a hostel setting.
2 Scope of the Project
 Hostel Administration and management
 Student accommodation management
 Room allocation and tracking
 Furniture inventory
 Financial Transaction and Wallet system
 Student Billing Payment
3 Data Design
3.1 Entity Relationship Diagram
 3.2 Conceptual Schema
Hostel :
hostel_id(PK) hostel_name no_of_rooms

Admin
admin_id(PK) name mob_no password

Room :
room_id(PK) hostel_id(FK) student_id(FK) occupancy_status

Student :
student_id(PK) name mob_no password hostel_id(FK)

Transaction :
transaction_id(PK) student_id date amount status

Wallet :
wallet_id(PK) balance student_id(FK)

Warden :
warden_id name hostel_id password mob_no

4 Entities and Attributes

This section of the document explains the entities used in the
project, their attributes and how they will work together.
Basically, this is intended to make the design more easy and
understandable for everyone.

 Entities
o Hostel
o Admin
o Student
o Room
o Transaction
o Wallet
o Warden

4.1 Hostel
An Institution has many hostels and each hostel is
represented using this ‘Hostel’ entity. Hostel model takes
part in the following relationships.
 Admin Supervises Hostel
  Warden Manages Hostel
 Hostel Has Students
 Hostel Has Rooms
Attributes
Name Data_type Type
hostel_id INT Primary Key
hostel_name VARCHAR Non_key
total_rooms INT Non_key

4.2 Admin
Every hostel has an administrator and is represented using
the ‘administrator’ entity. Administrator entity takes part
in following relationships.
 Admin Supervises Hostel
Attributes
Name Data_type Type
admin_id VARCHAR Primary key
name VARCHAR Non Key
mobile_no VARCHAR Non Key
password VARCHAR Non Key

4.3 Student
Every hostel has students and they are represented by the
‘student’ entity. Student entity participates in the
following relationships.
 Hostel Has Student
 Student stay in Room
 Student has Wallet
 Student conducts Transaction
Attributes
Name Data_type Type
student_id INT Primary Key
name VARCHAR Non key
mobile_number VARCHAR Non key
password VARCHAR Non key
hostel_id INT Foreign key
4.4 Room
Every Hostel has rooms and they are represented using ‘room’
entity. Room entity participates in the following
relationships.
 Hostel Has Room
 Student stays in Room
Attributes
Name Data_type Type
hostel_id INT Foreign Key
room_id INT Primary Key
occupancy_status TINYINT Non key
student_id INT Foreign Key

4.5 Warden
Account entity manages billing and payments. Account entity
participates in:
 Warden manages Hostel
 Admin manages Warden
Attributes
Name Data_type Type
warden_id VARCHAR Primary key
name VARCHAR Non key
Hostel_id INT Foreign Key
Password VARCHAR Non key
Mobile_no VARCHAR Non key

4.6 Wallet
Wallet entity manages student finances. Wallet entity
participates in:
 Student has Wallet
 Wallet used for Transaction
Attributes
Name Data_type Type
id INT Primary Key
student_id INT Foreign Key
balance DECIMAL Non key
 4.7 Transaction
Transaction entity records financial operations.
Transaction entity participates in:
 Transaction involved Wallet
Attributes
Name Data_type Type
transaction_id INT Primary Key
student_id INT Foreign Key
date DATETIME Non key
amount DECIMAL Non key
status VARCHAR Non key

5 DDL (Data Definition Language)

5.1 Hostel

5.2 Admin
5.3 Student

5.4 Room
5.5 Warden

5.6 Wallet

5.7 Transaction
6 Normalization
6.1 Room
 First Normal Form(1NF)
Each room is uniquely identified by room_id, and each
attribute contains atomic values.
 Second Normal Form(2NF)
All attributes depend on the room_id. hostel_id and student_id
are foreign keys that ensure proper relations without partial
dependency.
 Third Normal Form(3NF)
No transitive dependencies exist. occupancy_status depends
directly on room_id.

6.2 Student
 First Normal Form(1NF)
Each student has a unique identifier (student_id), and all
attributes have atomic values.
 Second Normal Form(2NF)
All attributes depend on the student_id. hostel_id is a
foreign key that relates the student to a specific hostel.
 Third Normal Form(3NF)
No transitive dependencies exist. Each attribute depends
directly on the primary key (student_id).
6.3 Hostel
 First Normal Form(1NF)
All attributes are atomic (no multivalued or composite
attributes). Each hostel has a single name and number of
rooms.
 Second Normal Form(2NF)
No partial dependency since hostel_id is the primary key, and
all attributes depend fully on it.
 Third Normal Form(3NF)
No transitive dependencies exist. hostel_name and no_of_rooms
are directly dependent on the hostel_id.

6.4 Admin
 First Normal Form(1NF)
All attributes are atomic; a single name, mobile number, and
password are associated with each admin.
 Second Normal Form(2NF)
All attributes depend fully on the admin_id (primary key).
 Third Normal Form(3NF)
No transitive dependencies exist. Every attribute is
dependent only on the primary key.

6.5 Wallet
 First Normal Form(1NF)
Each wallet is uniquely identified, and all attributes are
atomic.
 Second Normal Form(2NF)
Each attribute depends fully on wallet_id.
 Third Normal Form(3NF)
There are no transitive dependencies; the student_id is a
foreign key linking wallets to students.

6.6 Transaction
 First Normal Form(1NF)
Each transaction is uniquely identified by transaction_id,
and all attributes are atomic.
 Second Normal Form(2NF)
All attributes depend fully on the transaction_id.
 Third Normal Form(3NF)
No transitive dependencies exist. The student_id is a foreign
key but does not introduce transitive dependency.

6.7 Warden
 First Normal Form(1NF)
Each warden is uniquely identified, and all attributes are
atomic.
 Second Normal Form(2NF)
All attributes depend fully on warden_id.
 Third Normal Form(3NF)
No transitive dependencies exist. The hostel_id is a foreign
key but does not cause dependency issues.