By Tole Fikadu Aga

From Adama Science and Technology University, 2021

1, Introduction

ASTU Student Clinic Management System provides the benefits of streamlined

operations, enhanced administration, control, superior patient care, strict cost
control and improved profitability. This System is somehow powerful, flexible, and
easy to use and is designed and developed to deliver really conceivable benefits to
students’ healthcare. More importantly it is backed by reliable and dependable
support. The project ‘ASTU Student Clinic Management System’ is based on the
database. As there are many areas where we keep the records in database for which
we are using.
1.1, Background

Healthcare is characterized by rapidly increasing use of information technology in

patient care, increasing documentation, coding, billing, and management. Due to
this the rise of health information technology and the implementation of updated
and latest systems increases the efficiency of health service delivery, reducing
medical errors, improving quality of care and providing better information for
patients and physicians as well as it secures the safely storing of the database. The
overall goal of the database management function is to obtain, manage, and use
data to improve health care and medical services, performance, administration and
management and support processes.
1.2, Objectives/Purpose of the system

The objective of this project is to develop Student Clinic database management

system based on Microsoft SQL Server Management Studio with structured Query
language as the back-end database hospital from file-based system to a computer
database system. This database will help the clinic to be more efficient in handling
the daily activities and registration of their patients and also to give a complete
requirement documentation, design, and implementation of the database. But
keeping track of all the activities and their records on paper is very cumbersome
and error prone. It also is very inefficient and a time-consuming process.
Observing the continuous increase in population and number of students visiting
the clinic recording and maintaining all these records is highly unreliable,
inefficient and error-prone. It is also not economically & technically feasible to
maintain these records on paper. Thus, keeping the working of the manual system
as the basis of our project we have developed an automated version of the manual
system, named as “ASTU Student Clinic Management System”.
1.3 Problems in the existing system

Lack of immediate retrievals: - The information is very difficult to retrieve and to

find particular information. [E.g., To find out about the patient’s history, the user
has to go through various registers. This results in inconvenience and wastage of
time.]
Lack of immediate information storage: - The information generated by various
transactions takes time and efforts to be stored at right place.
Lack of prompt updating: - Various changes to information like patient details or
immunization details of child are difficult to make as paper work is involved.
Error prone manual calculation: - Manual calculations are error prone and take a
lot of time this may result in incorrect information. [E.g., calculation of patient’s
bill based on various treatments.]
Preparation of accurate and prompt reports: - This becomes a difficult task as
information is difficult to collect from various registers.

2.Conceptual Database Design

The middle level in the data abstraction is the conceptual level. This level contains
the logical structure of the entire database as seen by the DBA (Database
Administrator). It is a complete view of the data requirements of the organization
that is independent of any storage considerations. The conceptual level represents:
 all entities, their attributes, and their relationships;
 the constraints on the data;
 semantic information about the data;
  security and integrity information.
The conceptual level supports each external view, in that any data available to a
user must be contained in, or derivable from, the conceptual level. However, this
level must not contain any storage-dependent details. For instance, the description
of an entity should contain only data types of attributes (for example, integer, real,
character) and their length (such as the maximum number of digits or characters),
but not any storage considerations, such as the number of bytes occupied.
2.1, Entities identification and description
 Patient
 Doctor
 Pharmacist
 Clinic Manager
 Pathologist
 Receptionist
 Medical History
 Drug
 Disease
 Schedule
2.2 Attribute’s identification and description
The following templet show the attribute’s identification and descriptions
[Patient]
 Patient_Id
 Patient_FName
 Patient_LName
 Patient_Age*(drived attribute) The underlined attribute
 Contact_No represents the Primary Key
 Patient_Gender
 Patient_Birthdate
 Dormitory_Block
 Dormitory_Room

[Doctor]
 Doctor_Id
 Doctor_FName
 Doctor_LName The underlined attribute
 Contact_No represents the Primary Key
 Doctor_Gender
 Doctor_Email
 Specialization
 [Pharmacist]
 Pharmacist_Id
 Pharmacist _FName
 Pharmacist _LName The underlined attribute
 Contact_No represents the Primary Key
 Pharmacist _Gender
 Pharmacist _Email
[Clinic_Manager]
 Manager_Id
 Manager _FName
 Manager _LName The underlined attribute
 Contact_No represents the Primary Key
 Manager_Email
 Office_No
 Manager_Gender

[Pathologist]
 Pathologist_Id
 Pathologist _FName The underlined attribute
 Pathologist _LName represents the Primary Key
 Pathologist_Gender
 Contact_No
 Pathologist _Email

[Receptionist]
 Receptionist_Id
 Receptionist_FName The underlined attribute
 Receptionist_LName represents the Primary Key
 Receptionist_Gender
 Contact_No
 Receptionist_Email
  Office_No

[Medical_History]
 Medical_Id
 Major_Disease The underlined attribute
 Diagnosis_Date represents the Primary Key
 Diagnosis_Result

[Drug]
 Drug_Id
 Drug_Name The underlined attribute
 Manufactured_Date represents the Primary Key
 Expiration_Date

[Disease]
 Disease_Name The underlined attribute
 Disease_Cause represents the Primary Key

[Schedule]
 Schedule_Day The underlined attribute
 Start_Time represents the Primary Keys
 End_Time

2.3, Relationship identification and description

 Manager manages Doctor (one to many)
 Manager manages Pharmacist (one to many)
 Manager manages Pathologist (one to many)
 Manager manages Receptionist (one to many)
 Manager schedules Schedule (one to many)
 Doctor prescribes Drug (many to many)
 Doctor diagnose Patient (many to many)
 Doctor updates medical history (many to many)
  Doctor follows Schedule (many to many)
 Patient takes Drug (many to many)
 Disease attacks Patient (many to many)
 Patient has medical history (one to one)
 Pharmacist follows Schedule (many to many)
 Pharmacist gives Drug (many to many)
 Pathologist follows Schedule (many to many)
 Pathologist tests Patient (many to many)
 Receptionist registers Patient (many to many)
 Receptionist follows Schedule (many to many)
 Drug heals Patient (one to one)

2.4, Entity Relationship (ER) Diagram

The entity-relationship (E-R) data model was developed to facilitate database
design by allowing specification of an enterprise schema that represents the overall
logical structure of a database. The E-R model is very useful in mapping the meanings and
interactions of real-world enterprises onto a conceptual schema. Because of this usefulness,
many database-design tools draw on concepts from the E-R model. The E-R data model
employs three basic concepts: entity sets, relationship sets, and attributes.
The ER-Diagram of the Student Clinic Management is drawn as the following: -
3, Logical Database Design
The schema of a relation refers to its logical design, while an instance of the relation refers to its
contents at a point in time. The schema of a database and an instance of a database are similarly
defined. The schema of a relation includes its attributes, and optionally the types of the attributes
and constraints on the relation such as primary and foreign key constraints.

3.1, ER to Table Mapping

Mapping [Patient] Entity

[Patient]
Patient_Id Patient_FName Patient_LNam Patient_Gender Patient_Birthdate Patient_Age Dormitory_Block Dormitory
e

Contact_No
Patient_Id Contact_No

Mapping [Doctor] Entity

[Doctor]
Doctor_I Doctor_FName Doctor_LName Doctor_Gender Doctor_Email Specialization Manager_ID
d

[Email]
Doctor_Id Email_account

Contact_No
Doctor_Id Contact_No

Mapping [Pharmacist] Entity

 [Pharmacist]

Pharmacist_I Pharmacist_FName Pharmacist_LName Pharmacist_Gender Manager_ID

d

Contact_No
Pharmacist_Id Contact_No

[Email]
Pharmacist_Id Email_Account

Mapping [Pathologist] Entity

Pathologist_Id Pathologist _FName Pathologist _LName Pathologist _Gender Pathologist _Email Manager_ID

[Pathologist]

Contact_No
Pathologist_Id Contact_No

[Email]
Pathologist_Id Email_Account

Mapping [Receptionist] Entity

[Receptionist]
Receptionist _Id Receptionist_FN Receptionist_LNam Receptionist_Gender Receptionist_Email Office_No Manage
ame e

Contact_No
Receptionist _Id Contact_No

[Email]
Receptionist t_Id Email_Account
Mapping [Clinic_Manager] Entity
[Clinic_Manager]
Manager _Id Manager_FName Manager_LName Manager_Email Office_No

[Contact_No]
Manager _Id Contact_No

[Email]
Manager_Id Email_Account

Mapping [Medical_History] Entity

[Medical_History]

Medical_ID Major_disease Diagnosis_date Diagnosis_Result

Mapping [Drug] Entity

[Drug]
Drug_ID Drug_Name Expiry_date Issued_date Disease_Name

Mapping [Schedule] Entity

[Schedule]
Schedule_day Start_time End_time Manager_ID

Mapping [Attacks] Relationship

[Attacks ]
Patient_Id Disease_Name Start_date

Mapping [See/Update] Relationship

[See/Update]
Doctor_Id History_ID Updated_date

Mapping [Has] Relationship

[Has ]Medical_|History
Patient_Id Disease_Name Date_of_History

Mapping [Diagnose] Relationship

[Diagnoses ]
Patient_Id Doctor_ID Diagnosis_Date Diagnosis_time

Mapping [Tests] Relationship

[Tests ]
Patient_Id Pathologist_Id Test_result

Mapping [Register] Relationship

[Register ]
Patient_Id Receptionist_Id Registratoin_date

Mapping [Prescribes] Relationship

[Prescribes]
Doctor_Id Drug_ID Prescribed_Drug_Name Dose_prescribed

Mapping [Follows] Relationship

[Follows ]
Doctor_Id Schedule_Day Schedule_endtime Schedule_StartTime

Mapping [Follows] Relationship

[Follows ]
Pathologist_Id Schedule_Day Schedule_endtime Schedule_StartTime
Mapping [Follows] Relationship
[Follows ]
Receptionist_Id Schedule_Day Schedule_endtime Schedule_StartTime

Mapping [Follows] Relationship

[Follows ]
Manager_Id Schedule_Day Schedule_endtime Schedule_StartTime

Mapping [Follows] Relationship

[Follows ]
Pharmacist_Id Schedule_Day Schedule_endtime Schedule_StartTime

Mapping [Gives] Relationship

[Gives ]
Pharmacy_Id Drug_ID

3.2, Validate Model Using Normalization

Normalization Is the process of decomposing unsatisfactory relations or multivalued attributes into a

single attribute.
Normalization is the branch of relational theory that provides design insights; it is the process of
determining how much redundancy exists in a table. The goals of normalization are:
 be able to characterize the level of redundancy in relational schema
 provide mechanisms for transforming schemas in order to remove redundancy

1. First Normal Form (1NF)

In the first normal form, only single values are permitted at the intersection of each row and column;
there are no repeating groups.
Referring to the rule of first normal form (1NF) all of the ER-Mapping tables drawn above are
normalized to first normal form.

2. Second Normal Form (2NF)

Second normal form of a table is decomposed using functional dependency or fully functional
dependency theorem.
Functional Dependency, A  B, or
Fully Functional Dependency, (A, B)  C
For the second normal form, the relation must first be in 1NF. The relation is automatically in 2NF if,
and only if, all non-primary key attributes are fully functionally dependent on primary keys.
Following this rule all of the above tables are in 2NF except the following five tables.
If they are redrawn in 2NF they will be as following

Mapping [Doctor] Entity

[Doctor]

Doctor_Id Doctor_FNam Doctor_LName Doctor_Gender Specialization

e

Doctor_Id Manager_ID

Mapping [Pharmacist] Entity

[Pharmacist]

Pharmacist_I Pharmacist_FName Pharmacist_LNam Pharmacist_Gender

d e

Pharmacist_Id Manager_ID

Mapping [Pathologist] Entity

[Pathologist]

Pathologist_Id Pathologist _FName Pathologist _LName Pathologist _Gender

Pathologist_Id Manager_ID

Mapping [Receptionist] Entity

[Receptionist]
 Receptionist _Id Receptionist_FName Receptionist_LName Receptionist_Gender Office_No

Receptionist _Id Manager_ID

Mapping [Prescribes] Relationship

[Prescribes]
Doctor_Id Drug_ID Dose_prescribed

Drug_ID Prescribed_Drug_Name

3. Third Normal Form (3NF)

The third normal form of a table uses transitive property of relations.
A  B and B  C, then A  C
To be in third normal form, the relation must be in second normal form. Also, all transitive
dependencies must be removed; a non-key attribute may not be functionally dependent on
another non-
As there is no any transitive functional dependency between attributes and all the tables become in
2NF, the tables are in 3NF.

4, Implementation and Support

The Following diagram is Drawn from the SQL Query of the project: -