Project report on 

Pharmacy Management System

FOR

Database Management Systems

Master of Technology
Computer Science & Technology

Submitted By

Anisha Singh
Ankit Kumar
Aqsha Aftab

Faculty Advisor : Dr. T.V Vijay Kumar

School of Computer & Systems Sciences

Jawaharlal Nehru University
New Delhi - 110067
Table of Contents
1.INTRODUCTION..................................................................................................................................1
2.REQUIREMENT ANALYSIS...................................................................................................................1
3. E-R Diagram.......................................................................................................................................4
4.Explanation of E-R Diagram................................................................................................................4
5.Relational schema and normalization.................................................................................................7
5.1 Insurance...........................................................................................................................7
5.2 Patient................................................................................................................................7
5.3 Prescription.........................................................................................................................8
5.4 PrescribedDrug...................................................................................................................9
5.5 Employee............................................................................................................................9
5.6 Order................................................................................................................................11
5.7 Bill.....................................................................................................................................11
5.8 OrderedDrugs...................................................................................................................12
5.9 Medicine...........................................................................................................................12
5.10 DisposedDrugs................................................................................................................13
5.11 Authorizes.......................................................................................................................14
5.12 Notification.....................................................................................................................14
5.13 IsNotified........................................................................................................................15
1.INTRODUCTION
Pharmacy Management System is a Database Management System for
managing both billing and drug inventory which helps in maintaining the
records of medicines, employees, and customers and also reduces the work of
searching the medicine.

The main aim of this system is to apply technology to support the pharmacists
and the stores to reduce the human effort on searching and automation of the
billing.

This system can be used by any store to automate the process of manually
maintaining pharmacy related records.

The system uses insurance of patients and can also notify employee of events
performed in pharmacy.

2.REQUIREMENT ANALYSIS
After studying and analysing the needs of pharmacy management and its use,
we put forward the following requirements and proceeded to the design stage
according to these requirements

Patient

When patients arrive at the store, we will obtain their health ID and identify
them based on their health ID. If they are a new patient, we will collect data
such as name, date of birth, address, health ID, phone number, gender, and
insurance Id. The patient will have a prescription using which order will be
created and the patient will then pay the bill.

Employees

An employee has an employee id, role, license, phone no, salary and name
employee can be a cashier or pharmacist. If an employee is preparing the order
then his/her ID will be used in the order. The employee authorizes the disposal
of medicines. Employees will be notified of orders and disposals.

1|Page
Prescription

Each patient should have one or more prescriptions with them, since most
medicines cannot be sold without a prescription. A prescription contains the
prescription identification number, the patient's health ID, the doctor's name,
the type of illness and the date of the prescription. Prescription includes
prescribed drugs and is used to create the order.

Prescribed Drug

Every prescription contains prescribed drugs and their information. The drug’s

name, quantity and refill limit must be stated on the prescription.

Insurance

If a patient has health insurance, we record the insurance ID (unique for each

patient), company name, start date, end date, insurance percentage and
patient name. Based on the percentage of insurance the insurance company
has to pay for the patient, the system will calculate the amount payable by the
insurance company and the patient.

Order

An order is generated based on a prescription. Each order has unique id and is

identified based on it. It also contains prescription id, employee id, order date,
the drug's name, ordered quantity, and batch no. It is used for bill creation. It
contains ordered drug information.

Ordered Drugs

The ordered drugs will contain information about the drug name, order

number, price, quantity ordered, and batch number. Each order will include
information about the ordered drugs and this information can be extracted
from the inventory.

Bill (Invoice)

When an order is completed, a system-generated invoice is generated. This

invoice is issued to the customer with order information, insurance
information and a breakdown of the amount paid. The breakdown must be

2|Page
calculated automatically by the system using insurance, customer and drug
data.

Medicine (Inventory)

It is beneficial to store an updated inventory for record keeping and to know

when we are short of stock. The inventory will contain all the information on
the medicines in pharmacy that are the name of the medicine, the type of
medicine, the manufacturer, the expiry date, the price, the quantity in stock
and the batch number. When a medicine approaches its expiration date, it will
be disposed of. 

Disposal

Employees will be notified and will authorize the disposal of the drug that is
marked for disposal as per the expiry date. So that the expired medicines can
be disposed of. Disposal will include the expiration date, manufacturer, batch
number, name and quantity of the drug.

Notification

The system is expected to be able to generate notifications.

1. The inventory for a drug is low.

2. There are drugs that will expire within the next 60 days.

3. Drugs are marked for disposal.

4. The medicines are disposed of successfully.

5. The order is created with the employee number.

Notifications are sent to all staffs that are pharmacists.

3|Page
3. E-R Diagram

Fig:- E-r Diagram Pharmacy management system

4.Explanation of E-R Diagram

Patient Holds Prescription

A patient can have many prescriptions. However, a prescription can only

belong to a single patient. Thus the relationship between Patient and
Prescription entity is one to many. Each patient will have a prescription and
each prescription belongs to a patient so the participation is Total of both
sides.

Insurance insures Patient

4|Page
A patient can claim one insurance and insurance can only insure one patient.
Thus the relationship between Insurance and Patient is one to one. A patient
may not have insurance so patient participation in insures is partial. However,
each insurance belongs to a patient so insurance participation is total in
insures.

Patient Pays Bill

A patient can pay several bills, but a bill will only be paid by a single patient.
Thus, the relationship between Patient and Bill is one to many. Each patient
pays for his bill and each bill is paid by a patient so the participation is Total of
both sides.

Prescription consists Of Prescribed Drug

A prescription may have several prescribed drugs but a drug with order id will
be on only one prescription so the relationship between prescription and
prescribed drug is one to many. Each prescription will have prescribed drug on
it and each prescribed drug will be on a prescription so the participation is
Total of both sides.

Prescription Uses Order

A prescription can generate multiple orders but an order will only be

generated using single prescription. Thus, the relationship between
Prescription and order is one to many. Each prescription will be used for some
order and each order will be generated using a prescription. So the
participation is Total of both sides.

Order makes Bill

An order can only generate one bill and a bill be generated for only one order
so the relationship between order and bill is one to one. Each order will
generate a bill and each bill will be generated for an order so the participation
is Total of both sides.

Order Contains Ordered Drugs

An order can contain multiple ordered drugs but an ordered drug with its order
ID and drug name will be only be in an order. Thus the relationship between

5|Page
order and ordered drugs is one to many. Each order will contain some drugs
and each ordered drugs will be in some order. So the participation is Total of
both sides.

Employee Prepares Order

An employee can prepare many orders but an order will be prepared by only
one employee. Thus, the relationship between order and ordered drugs is one
to many. Each order will be prepared by some employee but not every
employee prepares order so the order participation is Total in prepares and
the employee participation is partial in prepares.

Ordered Drugs Fetched Medicine

A medicine will be fetched by an ordered drug and an ordered drug will fetch
only one medicine. So the relationship between ordered drugs and medicine is
one to one. Each ordered drug will fetch some medicine but every medicine
will not be fetched so the participation of ordered drugs in fetched is Total but
participation of medicine in fetched is partial.

Medicine Disposes Disposal

Disposal is weak entity and is dependent on Medicine so the relationship

between them disposed is a weak relationship. Disposal uses foreign key drug
name and batch no as its primary key. Every disposed drug is from medicine so
the participation of disposal is total in disposes. Not every medicine is disposed
so the participation of medicine in disposes is partial.

Employee Authorizes Disposal

An employee can authorize many disposals and a disposal can be authorized by

many employees. So the relationship between them is many to many. Not
every employee authorizes disposal so the participation of employee in
authorizes is partial. Each disposal is authorized by an employee so the
participation of disposal in authorization is Total.

Employee isNotified Notification

An employee can receive many notifications and a notification can be sent to

many employees so the relationship between them is many to many. Not

6|Page
every employee receives notification but every notification is sent to some
employee so the participation of employee in isNotified is partial and the
participation of notification in isNotified is Total.

5.Relational schema and normalization

Normalization:- Normalization is process of reducing redundancy of data in
relational schema.

Giving the Composite attributes, multivalued attributes, Primary Key,

Foreign Key, Functional Dependencies of the relations and then
normalizing them to BCNF.

5.1 Insurance
Insurance (InsuranceID,CompanyName,StartDate,EndDate,InsurancePer)

Primary Key - InsuranceID

Functional Dependencies –

InsuranceID -> CompanyName, InsuranceID -> StartDate,

InsuranceID -> EndDate, InsuranceID -> InsurancePer

Relation Insurance is in 1NF as no attribute is multivalued or composite.

Relation Insurance is in 2NF as it is in 1NF and no non key attribute is partially

dependent on primary key.

Relation Insurance is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation Insurance is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

5.2 Patient
Patient (HealthID, FirstName, LastName, Phone, Gender, Address, DOB,
InsuranceID)

Primary key: HealthID

7|Page
Foreign key: Patient (InsuranceID)-> Insurance(InsuranceID)

Functional Dependencies –

HealthID -> FirstName, HealthID -> LastName, HealthID -> Phone

HealthID -> Gender, HealthID -> Address, HealthID ->DOB,

HealthID ->InsuranceID

Composite Attribute – Address, Multivalued Attribute – Phone

Relation Patient is not in 1NF as Address is composite attribute and Phone is

multivalued attribute.

Inserting separate sub attribute for composite attribute and separate attribute
for multi-valued attribute.

Patient (HealthID, FirstName, LastName, PhoneNo1, PhoneNo2, Gender,

SocietyName, CityName, DOB, InsuranceID)

Now Relation Patient is in 1NF

Relation Patient is in 2NF as it is in 1NF and no non key attribute is partially

dependent on primary key.

Relation Patient is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation Patient is in BCNF as it is in 3NF and no prime attribute is transitively

dependent on primary key.

5.3 Prescription
Prescription ( PrescriptionID, HealthID, DoctorID, PrescriptionDate)

Primary key: PrescriptionID

Foreignkey: Prescription (HealthID) ->Patient(HealthID)

Functional Dependencies –

PrescriptionID -> HealthID, PrescriptionID -> DoctorID

8|Page
PrescriptionID -> PrescriptionDate

Relation Prescription is in 1NF as no attribute is multivalued or composite.

Relation Prescription is in 2NF as it is in 1NF and no non key attribute is

partially dependent on primary key.

Relation Prescription is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation Prescription is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

5.4 PrescribedDrug
PrescribedDrug ( PrescriptionID, DrugName, DrugQuantity, RifillLimit)

Primary key: PrescriptionID, DrugName

Foreign key: Prescribed Drug(PrescriptionID)-> Prescription(PrescriptionID)

Functional Dependencies –

PrescriptionID, DrugName -> DrugQuantity,

PrescriptionID, DrugName -> RifillLimit

Relation PrescribedDrug is in 1NF as no attribute is multivalued or composite.

Relation PrescribedDrug is in 2NF as it is in 1NF and no non key attribute is

partially dependent on primary key.

Relation PrescribedDrug is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation PrescribedDrug is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

5.5 Employee
Employee (EmployeeID, FirstName, LastName, DOB, License, StartDate,
EndDate, Salary, Phone)

9|Page
Primary key: EmployeeID

Functional Dependencies –

EmployeeID -> FirstName, EmployeeID -> LastName

EmployeeID ->DOB, EmployeeID -> Role, EmployeeID -> Salary

EmployeeID -> Phone, EmployeeID -> Licence, EmployeeID ->StartDate

EmployeeID ->EndDate, Licence -> StartDate, Licence -> EndDate

Multi-valued Attribute- Phone

Relation Employee is not in 1NF as phone is a multi-valued attribute.

Inserting separate attributes for multi-valued attribute.

Employee (EmployeeID, FirstName, LastName, DOB, License, StartDate,

EndDate, Salary, PhoneNo1, PhoneNo2)

Now Relation Employee is in 1NF.

Relation Employee is in 2NF as it is in 1NF and no non key attribute is partially

dependent on primary key.

Relation Employee in not in 3NF as-

StartDate and EndDate are non-key attribute and they are transitively
dependent on primary key Employee because of License Attribute.

Decomposing relation Employee into two relations Employee and license.

Employee (EmployeeID, FirstName, LastName, DOB, License, Salary,

PhoneNo1, PhoneNo2)

License (License, StartDate, EndDate)

Primary Key – License

Functional dependencies

License -> StartDate, License -> EndDate

Both Relation Employee and License are now in 3NF.

10 | P a g e
Both Relation Employee and License are in BCNF as it is in 3NF and no prime
attribute is transitively dependent on primary key.

5.6 Order
Order (OrderID, PrescriptionID, EmployeeID, OrderDate)

Primary key: OrderID

Foreign key: Order (PrescriptionID) -> Prescription(PrescriptionID),

Order(EmpID)->Employee(EmpID)

Functional Dependencies –
OrderID -> PrescriptionID, OrderID -> EmployeeID , OrderID -> OrderDate

Relation Order is in 1NF as no attribute is multivalued or composite.

Relation Order is in 2NF as it is in 1NF and no non key attribute is partially

dependent on primary key.

Relation Order is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation Order is in BCNF as it is in 3NF and no prime attribute is transitively

dependent on primary key.

5.7 Bill
Bill (HealthID, OrderID, PymMode, TotalAmount,BillNo)

Primary key: BillNo

Foreign key: Bill (ordered) ->Order (ordered),

Bill (healthID) -> Patient (healthID)

Functional Dependencies –

11 | P a g e
BillNo-> HealthID, BillNo-> OrderID, BillNo-> PymMode

BillNo ->TotalAmount, BillNo -> DrugQuantity

Relation Bill is in 1NF as no attribute is multivalued or composite.

Relation Bill is in 2NF as it is in 1NF and no non key attribute is partially

dependent on primary key.

Relation Bill is in 3NF as it is in 2NF and no attribute is transitively dependent

on primary key.

Relation Bill is in BCNF as it is in 3NF and no prime attribute is transitively

dependent on primary key.

5.8 OrderedDrugs
OrderedDrugs (OrderID, DrugName,BatchNo,Price,Quantity)

Primary key: OrderID, DrugName, BatchNo

Foreign key: OrderedDrugs (Orderid)- >Order(Orderid),

OrderedDrugs (Drugname,BatchNo)->Medicine(Drugname,BatchNo)

Functional Dependencies –

OrderID, DrugName, BatchNo -> Price

OrderID, DrugName, BatchNo -> Quantity

OrderID, DrugName -> Quantity

Relation OrderedDrugs is in 1NF as no attribute is multivalued or composite.

Relation OrderedDrugs is in 2NF as it is in 1NF and no non key attribute is

partially dependent on primary key.

Relation OrderedDrugs is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation OrderedDrugs is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

12 | P a g e
5.9 Medicine
Medicine (DrugName,
Manufacturer,BatchNo,Price,Expirydate,MedType,StockQuantity)

Primary key: DrugName, BatchNo

Functional Dependencies –
DrugName, BatchNo -> Manufacturer, DrugName, BatchNo -> Price

DrugName, BatchNo -> Expirydate, DrugName, BatchNo -> MedType

DrugName, BatchNo -> StockQuantity

Relation Medicine is in 1NF as no attribute is multivalued or composite.

Relation Medicine is in 2NF as it is in 1NF and no non key attribute is partially

dependent on primary key.

Relation Medicine is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation Medicine is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

5.10 DisposedDrugs
DisposedDrugs (DrugName, BatchNo, DrugQuantity, Manufacturer)

Primary key: DrugName, batchNo

Foreign key: DisposedDrug(DrugName,batchNo)->

Medicine(DrugName,batchNo)

Functional Dependencies –

DrugName, batchNo -> DrugQuantity, DrugName, batchNo -> Manufacturer

Relation DisposedDrugs is in 1NF as no attribute is multivalued or composite.

Relation DisposedDrugs is in 2NF as it is in 1NF and no non key attribute is

partially dependent on primary key.

13 | P a g e
Relation DisposedDrugs is in 3NF as it is in 2NF and no attribute is transitively
dependent on primary key.

Relation DisposedDrugs is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

5.11 Authorizes
Authorizes(EmpId,DrugName,BatchNo,DisposalDate)

Primary key: EmployeeID, BatchNo, DrugName

Foreign key: Authorizes (EmpID) -> Employee (EmpID),

Authorizes (drugName,BatchNo)-> DisposedDrug(DrugName,BatchNo)

Functional Dependencies –

EmpID, BatchNo, DrugName -> DisposalDate

Relation Authorizes is in 1NF as no attribute is multivalued or composite.

Relation Authorizes is in 2NF as it is in 1NF and no non key attribute is partially
dependent on primary key.

Relation Authorizes is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation Authorizes is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

5.12 Notification
Notification (NotificationID, Message, Type)

Primary key: NotificationID

Functional Dependencies –

NotificationID -> Message, NotificationID -> Type

Relation Notification is in 1NF as no attribute is multivalued or composite.

14 | P a g e
Relation Notification is in 2NF as it is in 1NF and no non key attribute is
partially dependent on primary key.

Relation Notification is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation Notification is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

5.13 IsNotified
IsNotified (NotificatioID, EmpID)

Primary key: EmployeeID, NotificationID

Foreign key : EmployeeNotification(EmpID)-> Employee(EmpID)

EmployeeNotification(NotificationID) -> Notification(NotificationID)

Functional Dependencies –

EmployeeID, NotificationID -> EmpID, NotificationID

Relation IsNotified is in 1NF as no attribute is multivalued or composite.

Relation IsNotified is in 2NF as it is in 1NF and no non key attribute is partially

dependent on primary key.

Relation IsNotified is in 3NF as it is in 2NF and no attribute is transitively

dependent on primary key.

Relation IsNotified is in BCNF as it is in 3NF and no prime attribute is

transitively dependent on primary key.

15 | P a g e