RESIDENCY MANAGEMENT SYSTEM

A PROJECT REPORT

Submitted by

Manish Anand [RA2211003030361]

Utkarsh Gupta [RA2211003030362]
Sukriti Shukla [RA2211003030363]]
Archi Jaiswal [RA2211003030369]
Rohit Raj[RA2211003030392]

Under the guidance of

Ms Swati Sheron
(Assistant Professor, Department of Computer Science & Engineering)

SRM INSTITUTE OF SCIENCE & TECHNOLOGY, NCR CAMPUS

APRIL 2024
SRM INSTITUTE OF SCIENCE & TECHNOLOGY
(Under Section 3 of UGC Act, 1956)

BONAFIDE CERTIFICATE
Certified to be the bonafide record of work done by Manish Anand of 4th semester 2nd year
B.TECH degree course in SRM INSTITUTE OF SCIENCE AND
TECHNOLOGY, NCR Campus of Department of Computer Science & Engineering in
Database Management Systems Lab, during the academic year 2023-2024.

SIGNATURE SIGNATURE

Ms Swati Sheron Dr. Avneesh Vashistha

Assistant Professor Head of the Department
Computer Science & Engineering Computer Science & Engineering

SRM INSTITUTE OF SCIENCE & TECHNOLOGY

(Under Section 3 of UGC Act, 1956)

BONAFIDE CERTIFICATE

Certified to be the bonafide record of work done by Utkarsh Gupta of 4th semester 2nd year
B.TECH degree course in SRM INSTITUTE OF SCIENCE AND
TECHNOLOGY, NCR Campus of Department of Computer Science & Engineering in
Database Management Systems Lab, during the academic year 2023-2024.

SIGNATURE SIGNATURE

Ms. Swati Sheron Dr. Avneesh Vashistha

Assistant Professor Head of the Department
Computer Science & Engineering Computer Science & Engineering

SRM INSTITUTE OF SCIENCE & TECHNOLOGY

(Under Section 3 of UGC Act, 1956)

BONAFIDE CERTIFICATE

Certified to be the bonafide record of work done by Sukriti Shukla of 4th semester 2nd
year B.TECH degree course in SRM INSTITUTE OF SCIENCE AND
TECHNOLOGY, NCR Campus of Department of Computer Science & Engineering in
Database Management Systems Lab, during the academic year 2023-2024.
SIGNATURE SIGNATURE

Ms. Swati Sheron Dr. Avneesh Vashistha

Assistant Professor Head of the Department
Computer Science & Engineering Computer Science & Engineering

SRM INSTITUTE OF SCIENCE & TECHNOLOGY

(Under Section 3 of UGC Act, 1956)

BONAFIDE CERTIFICATE

Certified to be the bonafide record of work done by Archi Jaiswal of 4th semester
2nd year B.TECH degree course in SRM INSTITUTE OF SCIENCE AND
TECHNOLOGY, NCR Campus of Department of Computer Science & Engineering in
Database Management Systems Lab, during the academic year 2023-2024.

SIGNATURE SIGNATURE
Ms. Swati Sheron Dr. Avneesh Vashistha
Assistant Professor Head of the Department
Computer Science & Engineering Computer Science & Engineering

Table of Contents

S.N. Artifacts Signature

1 Introduction of the Project

Identification of Entities and Relationships, Construction of ER

2
Model

3 Conversion of ER Diagram to Relational Database

4 Implementation of SQL Queries

5 Identifying Dependencies and Applying Normalizations

 6 Concurrency Control and Recovery Mechanisms

7 Final Outcome and Conclusions

ABSTRACT
The Residency Management System (RMS) is a Java-based
software solution with MySQL for database management,
designed to automate and streamline the management of residency
programs in various institutions.

With a user-friendly interface, residency management system

offers comprehensive functionality for administrators,
coordinators, residents, and stakeholders. It facilitates user
management, program creation, resource allocation, and progress

tracking. Features include resident tracking, scheduling,

communication tools, document management, evaluation, and
analytics. Leveraging Java's power and modern software
development principles, residency management system ensures
efficiency, scalability, and customization. It empowers institutions
to enhance residency program quality, compliance, and efficiency
seamlessly.
PROBLEM IDENTIFICATION

1. Manual Processes: Many institutions still rely on manual, paper-based

processes for managing residency programs, including record-keeping,
scheduling, and communication. These manual processes are
timeconsuming, error-prone, and inefficient, leading to delays and
administrative burden.
2. Communication Challenges: Communication among residents, faculty
members, and administrative staff is often fragmented and inefficient,
relying on emails, phone calls, and paper notices. This lack of centralized
communication channels can lead to misunderstandings, missed
messages, and delays in critical information dissemination.
3. Scheduling Complexity: Residency program scheduling involves
coordinating multiple rotations, on-call duties, meetings, and educational
activities for residents. Managing these schedules manually can be
challenging, with the potential for conflicts, scheduling errors, and
difficulties in accommodating resident preferences.
4. Tracking and Evaluation: Tracking resident activities, duty hours, and
performance evaluations manually is labor-intensive and prone to errors.
Institutions need a centralized system to accurately track resident
progress, evaluate performance, and ensure compliance with accreditation
requirements.
5. Document Management: Important documents such as policies,
procedures, handbooks, and training materials related to residency
programs are often stored in disparate locations or in paper format,
making it difficult to access and manage them efficiently.
6. Compliance Concerns: Residency programs are subject to
accreditation standards and regulatory requirements that demand
meticulous recordkeeping, reporting, and compliance monitoring. Manual
processes make it challenging for institutions to ensure compliance and
demonstrate adherence to accreditation standards.
7. Scalability Issues: As institutions grow or expand their residency
programs, manual processes become increasingly unsustainable and
difficult to scale. There is a need for a scalable solution that can
accommodate the evolving needs and complexities of residency program
management.

INTRODUCTION

The Residency Management System (RMS) project aims to revolutionize

the way residency programs are managed. This project recognizes the
challenges inherent in traditional manual processes for residency program
management and seeks to address them through the development of a
comprehensive software solution. By leveraging the power of Java
programming language and modern software development principles, the
residency management system project aims to automate and streamline
key aspects of residency program management, including user
management, communication, tracking, evaluation, and compliance. This
introduction sets the stage for the project, highlighting the critical need
for a centralized, efficient, and scalable solution to enhance the quality,
efficiency, and compliance of residency programs. Through the
development of the RMS, institutions will be empowered to overcome
the challenges associated with manual processes and embrace a more
efficient and effective approach to residency program management.

The key components of the Residency Management System are:

1. Residents Information Management
2. Complaint System
3. New Registrations
4. Scalability and customization
ER Diagram:

1. Resident
• Description: The Resident entity represents a collection of details
about the residents (admin or users) of the residency.
• Attributes:
o r_id: A unique identifier for each resident, serving as a
primary key for the Resident entity. It distinguishes one
resident from another in the database. o name: A
composite attribute comprising two sub-
attributes that collectively represent the user’s name. It includes:
▪ FirstName: The first name of the user.
▪ LastName: The last name of the user. o l-id: A foreign
attribute that references from the login entity.
o DoB: The date of birth of the user. o gender: The gender
of the user, male or female. o r_role: The role of the user
whether they are just an user or admin of the residency.
o phone_no: The phone number of the user. o email: The
email of the user.
o r-address: The address of the user within the society.
2. ComplaintList
• Description: The ComplaintList entity is a weak entity that
depends on the login table for its details. It represents the
complaints made by the users on the application. It contains
information about each complaint made, including the l_id of the
user, the problem, its description and the date & time when the
complaint was placed.
• Attributes:
o l_id: The complaints are defined by their l_id. o problem: This
contains the main problem or the issue of registering a complaint.
o description: The details about the complaint or the problem.
o date_time: The date & time whem the complaint was resgistered.
3. Login_Details
• Description: The Login_details entity contains the details that an
user will use to get into the application, whether they are an user
or admin.
• Attributes:
o l_id: This attribute uniquely defines each entry in this table. o
Idname: This is the username that the user will use to login. o
Password: The password to their profile.
COMPLETE ER DIAGRAM:
Relationships:
1. Resident can complaint:
• One-to-many relationship from Resident to ComplaintList
(one resident can have multiple complaints)
• Total Participation of ComplaintList (Every Complaint must be
associated with a resident)
• Partial Participation of Resident ( A resident may or may not have
a resident)
2. Resident has Login_Details:
• One-to-one relationship from Resident to Login_Details (One
resident can be associated with one login and a login can have
only one resident)
• Total Participation of Resident (Every resident must belong to a
login)
• Total Participation of Login_Details ( Every login must have a
resident)

Conversion of ER Diagram to Relational Model

1. Entity: Login_Details Since “Login_Details is a strong
entity, we create the relational table with all the normal
attributes.

Table: Login_Details

2. Entity: Resident Since “Resident” is a strong entity, we

include all the normal attributes in the relational table.
Also, it has a relation of one to one with Login_details, and also it is
the total participant, so we include the primary key of
Login_Details entity in the resident table.

Table: Resident

3. Entity: ComplaintList
It is a weak entity, so we include the primary key of the
Login_Details table as a foreign key in the ComplaintList table.
Also, since it has a many to one relation with Login_Details entity.

Table: ComplaintList
SQL Queries

SQL Constraints:
1. Primary Key:
CREATE TABLE Login_Details(
l_id integer primary key, Idname
varchar(50),
password varchar(50)
);

By declaring l_id as the primary key, you ensure that each user in the
Login_Details table can be uniquely identified by their l_id. This
helps maintain data integrity and enables efficient data retrieval and
manipulation operations.

2. Unique:
CREATE TABLE Login_Details( l_id
integer primary key unique, Idname
varchar(50),
password varchar(50)
);

By adding a unique constraint to the l_id column, you ensure that each
l_id in the Login_Details table must be unique. This constraint helps
maintain data integrity by preventing duplicate l_id from being entered
into the table. It also allows for efficient querying of l_id, as the
database management system (DBMS) automatically creates a unique
index on the column to enforce uniqueness.

3. Not Null:

CREATE TABLE Login_Details( l_id

integer primary key unique, Idname
varchar(50) not null, password
varchar(50) not null
);
By adding the NOT NULL constraint to the Idname and Password
columns, you ensure that each user in the login_details table must have a
valid idname and password associated with their account. This
constraint helps maintain data integrity by preventing the insertion of
incomplete or invalid data into the table. Additionally, it enables
efficient querying and retrieval of user data, as NULL values do not
need to be handled specially in database queries.

4. Foreign Key:
CREATE TABLE ComplaintList(
l_id integer references Login_details(l_id),
problem varchar(50), description
varchar(255),
date_time datetime
);
By adding this foreign key constraint, you establish a relationship between the
ComplaintList table and the Login_Details table.
Specifically, it ensures referential integrity by enforcing that every value
in the Has column of the ComplaintList table must correspond to a valid
l_id value in the Login_details table. This constraint helps maintain
data consistency and prevents orphaned records in the database.

5. Default:
CREATE TABLE ComplaintList(
l_id integer references Login_details(l_id),
problem varchar(50), description
varchar(255),
date_time datetime default current_timestamp
);
By adding a default constraint to the date_time column, you ensure that
every complaint in the ComplaintList table will have a date & time
value, even if one is not explicitly provided during insertion. This helps
maintain data consistency and prevents NULL values from being
inserted into the column. Additionally, it simplifies data entry by
providing a default value that can be overridden if necessary.

6. Check:
CREATE TABLE Login_Details( l_id
integer primary key unique, Idname
varchar(50) not null, password
varchar(50) not null,
constraint check_length check(length(password)>=8)
);

By adding a check constraint to the password column, you enforce data

integrity by ensuring that only valid password values are allowed in the
Login_details table. This prevents the insertion of invalid or out-of-
range values, such as negative numbers, into the column. Check
constraints help maintain the consistency and correctness of data within
the database
Normalization:
Since all the tables in the above database does not violate any of the rules of
1NF, 2NF, 3NF, BCNF or 4NF, thus we produce the following modifications
in some of the tables in order to apply normalization over them:

1: Table: Login_Details
We can introduce a multivalued dependency by adding a new attribute to
the Login_Details table called Complains, where multiple Complains
can be registered.
l_id idname PASSWORD Complains
1 Ishita26 ********* Electricity
problem,
Parking issues,
Pest Control
2 anshika ********* Noise
Complains,
Neighbour
Dispute

Complains violates the 1NF because it contains multiple values separated by

commas. Each cell in a relational table should contain a single value, and
multi-valued attributes should be avoided. Also, the Complain column is
dependent only on l_id hence, partial dependency exists and thus it violates
2NF rules.
Now, to resolve this we'll split the multivalued attribute Complains into a
separate table with a composite primary key.
l_id idname PASSWORD
1 Ishita26 *********
2 anshika *********
Table: Login_Details

l_id Complains
1 Parking issues
2 Noise Complains
1 Pest Control
1 Electricity problem
2 Neighbour Dispute
 •
Table: Login_Details_Complain

Result:

This is the home page, that the user will see as soon as they open their
application.
• If the user chooses the “Login” option, then they can access the features
through their login credentials.
 If the user does not have a login id, then he/she will go on the “New
Login” page, they can create their login id from there.

• The “Important Contacts” page is accessible to everyone, and it contains

the some of the important contacts of the places/people that are required
in our day-to-day life.
•

If the person logins as a USER:

This is the user home page.

• View: Residents Details- Here, a user can see some selected details of
the other fellow users.
New Registration Form- If you have just formed a new login id, then
you must add your credentials in this form.
•
Once you enter your details, a dialogue box will appear, telling you that
your account has been formed.
•
Complaint: In this page, the user can register new complaints.

When the complaint details are filled, a dialogue box will appear
informing you about the complaint being registered successfully.
•

Logout: On logging out of your profile, this dialogue box will appear
telling you that you have been logged out, and it will take you to the

If you login as a A DMIN:

main page of the application.

This is the admin home page, that will appear on logging in as an admin.
•

View: Residents Details:

This page will contain detailed information about the residents.

• Complaints:
This page will show all the complaints that have been registered by the
residents, in the latest to oldest order.
•

Logout: This page will show that you have been logged out of your
application and it will take you back to the main page of the application.
•
Conclusion:

In conclusion, the Residency Management System (RMS) project

represents a significant step forward in improving the efficiency, quality,
and compliance of residency program management.

By addressing the challenges inherent in traditional manual processes,

the Residency Management System project offers a comprehensive
software solution that automates and streamlines key aspects of
residency program administration. Through its user-friendly interface,
robust functionality, and scalability, the residency management system
empowers institutions to efficiently manage resident activities,
streamline communication, optimize scheduling, track progress,
evaluate performance, and ensure compliance with accreditation
standards and regulatory requirements.

As the project concludes, the Residency Management System has the

potential to revolutionize residency program management, enhancing
the educational experience for residents, improving workflow efficiency
for administrators, and ultimately, delivering better patient care
outcomes in healthcare settings. Moving forward, continued
development, implementation, and refinement of the Residency
Management System will be essential to realizing its full potential and
maximizing its impact on residency programs across various
institutions.