Cnit272 5

Learner’s Name or ID
Project
Course CNIT272 – Database Fundamentals
Instructor
Section
Assignment Number
Semester
Deadline
Total Earned Points

Page 2 of 11
INTRODUCTION
The system helps hospitals meet the specific needs by enabling them to manage their patients
with ease and precision. The system handles a wide range of clinic activities, from patient
records to delivering check-ups patients, while ensuring timely and cost-effective operations.
Main Functionality:
1. To manage patients by helping to track patient information in real-time and ensuring

optimal service delivery while preventing errors due manual data entry.
2. To manage check-ups for patents by tacking every check-up activity performed by
clinicians and the patients. This system has a smooth user interface for data entry,
verification, and scheduling.
3. To manage patient treatment, the system handles treatment delivery operations
efficiently, including selection of optimized treatment plans for patients.
4. To manage medicines. This system helps clinics manage their medicine inventories
effectively while keeping track of medicine stock information and keeping track of expiry
dates.
System Development Plan
The development of this system uses the iterative development approach. With incremental
enhancements added at each phase. Collaborating closely with clinicians, the development team
gathers requirements, designs the system architecture, implements functionalities, and conducts
rigorous testing to ensure seamless deployment.
Statement of Requirements and Business Rules:
1) The system should ensure data security. This includes data encryption and access controls
to safeguard sensitive data in the database.
2) The system grants user roles and permissions. This system must offer user roles at
different levels such as hospital managers or patients, with appropriate access levels to
maintain data confidentiality and integrity.
3) The system must of offer appointment scheduling. This system must provide a platform
for patients to book for services in good time and update about their treatment plans to be
viewed by their specific clinical personnels.
4) The system must generate reports. Report generation on information such as medicine
stock, booking status and patient population are crucial to aid decision-making and
performance evaluation.
Page 3 of 11
The clinic management System will enhance the quality of clinical operations and business logic.
By automation of these processes, information access to healthcare providers and patients, the
system ensures better services to clinical service providers.
ENHANCED ENTITY-RELATIONSHIP MODEL
The entity-relationship model for this system contains complex features. This section explores
the entities, attributes, relationships, and the cardinalities for the system’s database:
Entities
1. Patient:
The patient entity has attributes as follows: patient_id as the primary key,first_name,
last_name, email, phone_number and address
2. Appointment:
This entity has attributes as follows: appointment_id (primary key), appointment_date,
patient_id (foreign key), doctor_id (foreign key), status and total_fee.
3. Doctor: The doctor entity has doctor_id (primary key), first_name, last_name,
specialization, email and phone_number.
4. Treatment:
This entity has treatment_id (primary key), treatment_name, description and fee.
Relationships and Cardinalities:
1. Appointment-Patient (One-to-Many):
For instance, a patient with many appointments, but each appointment only associated
with only one patient.
In the appointment table the foreign key is patient_id
2. Appointment-Doctor (One-to-Many):
For instance, one doctor can have many appointments, but only one appointment is
associated with only one doctor.
In the appointment table foreign key is doctor_id.

3. Appointment-Treatment has Many-to-Many
Multiple treatments can be part of multiple appointments, and each appointment can have
multiple treatments.
Additional table: Appointment_Treatment with foreign keys appointment_id and

treatment_id.
The unique Identifiers in the database:
1. Patient table:
The primary key is patient_id.
2. Appointment table:
The primary key is appointment_id.
3. Doctor table:
The primary key is doctor_id.
4. Treatment table:
The primary key is treatment_id.
Supertype/Subtype Relationships:
There are no supertype or subtype relationships in the database.
This database does not have disjoint or completeness constraints.

EER Diagram:
THE RELATIONAL SCHEMA
The relational schema for the Logistics Management System is designed as follows:
The relational schema for the Clinic Management System is designed as follows:
The Patient table:
patient_id (Primary Key)

first_name
last_name
email
phone_number
address
The Appointment table:
appointment_id (Primary Key)
appointment_date
patient_id (Foreign Key)
doctor_id (Foreign Key)
status
total_fee
The Doctor table:
doctor_id (Primary Key)
first_name
last_name
specialization
email
phone_number
The Treatment table:
treatment_id (Primary Key)
treatment_name
description
fee
The Appointment_Treatment table:
appointment_id (Foreign Key, references Appointment.appointment_id)
treatment_id (Foreign Key, references Treatment.treatment_id)
Functional dependencies:
In the Patient table:
patient_id -> {first_name, last_name, email, phone_number, address}
In the Appointment table:
appointment_id -> {appointment_date, patient_id, doctor_id, status, total_fee}
In the Doctor table:
doctor_id -> {first_name, last_name, specialization, email, phone_number}
In the Treatment table:
treatment_id -> {treatment_name, description, fee}
Referential integrity:
Foreign key constraint: patient_id references Patient.patient_id
Foreign key constraint: doctor_id references Doctor.doctor_id
Foreign key constraint: appointment_id references Appointment.appointment_id

Foreign key constraint: treatment_id references Treatment.treatment_id
Relational Schema:
THE SQL DATABASE
CONCLUSION
This management system provides the solution for automation of clinical operations. This project
helped us to learn about development of a well-designed database. The designing of the Entity-
Relationship model, relational schema, and SQL queries to manage patients, healthcare
providers, treatment, and data security were the main takeaway.
Through the implementation of the database, this system enhances clinical processes and reduces
manual errors. The EER model helped us to understand the designing of a relational schema and
defining various tables and constraints in the database.
Throughout the project, we learned crucial aspects like data security, user roles and permissions,
treatment tracking, and report generation to meet the specific requirements and business rules of
clinical setup. The iterative approach ensured that the development of this system followed the
right steps and phases to deliver the program in time and provided a user-friendly interface.
I. REFERENCES
Bryla, B. (2020). Oracle Database 19c: Basic SQL.
Brumm, B. (2019). Beginning Oracle SQL for Oracle Database 18c: From Novice to
Professional. Apress.

Cnit272 5

Uploaded by

Copyright:

Available Formats

Cnit272 5

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cnit272 5

Uploaded by

Copyright:

Available Formats

Learner’s Name or ID

Course CNIT272 – Database Fundamentals

Total Earned Points

1. To manage patients by helping to track patient information in real-time and ensuring

System Development Plan

Statement of Requirements and Business Rules:

ENHANCED ENTITY-RELATIONSHIP MODEL

Relationships and Cardinalities:

In the appointment table the foreign key is patient_id

In the appointment table foreign key is doctor_id.

Additional table: Appointment_Treatment with foreign keys appointment_id and

The unique Identifiers in the database:

There are no supertype or subtype relationships in the database.

This database does not have disjoint or completeness constraints.

THE RELATIONAL SCHEMA

The Patient table:

patient_id (Primary Key)

The Appointment table:

appointment_id (Primary Key)

patient_id (Foreign Key)

doctor_id (Foreign Key)

The Doctor table:

doctor_id (Primary Key)

The Treatment table:

treatment_id (Primary Key)

The Appointment_Treatment table:

appointment_id (Foreign Key, references Appointment.appointment_id)

treatment_id (Foreign Key, references Treatment.treatment_id)

In the Patient table:

patient_id -> {first_name, last_name, email, phone_number, address}

In the Appointment table:

appointment_id -> {appointment_date, patient_id, doctor_id, status, total_fee}

In the Doctor table:

doctor_id -> {first_name, last_name, specialization, email, phone_number}

In the Treatment table:

treatment_id -> {treatment_name, description, fee}

Foreign key constraint: patient_id references Patient.patient_id

Foreign key constraint: doctor_id references Doctor.doctor_id

Foreign key constraint: appointment_id references Appointment.appointment_id

Bryla, B. (2020). Oracle Database 19c: Basic SQL.

You might also like