Drugstore DB - 1

Christopher Boyd
Jordan Bienz
Roland Bernard
Miguel Solis

Drug Store Relational Database Report

27 February, 2020
 Drugstore DB - 2

INTRODUCTION.

The goal of this relational database is to provide a system in which pharmacies, doctors, and patients
can access information about prescriptions, primary care physicians, and pharmaceutical entities. It will
be used by a drug store chain and its customers. To make the system accessible, we will be providing a
web-based interface for which doctors, patients, pharmacy managers, and government agents can easily
access privileged information relevant to their profession or status as a patient.

During the initial design, we have discovered several major findings that project members and
stakeholders should be made aware of. To begin, prescriptions will require some unit of measurement
to describe a lowest base value. Liquid medications should be measured in the appropriate units, as
should solids. Managers should be separated into their own data table to account for the fact that a
manager may change or be assigned multiple contracts over time. We also discovered that certain
elements within the database need to have their historical value preserved. Due to this, we recommend
that some columns such as refills remaining per prescription be separated into a “MAXIMUM
REFILLS” and “REFILLS REMAINING” column. Our group also established that a separate table is
necessary to describe drug prices for each pharmacy. This could not be included in the primary
pharmacy table without harming our efforts to normalize the database. Finally, we discovered that
separating doctor specialty and UOM (units of measurement) into their own tables allowed our
database to be normalized even further.
 Drugstore DB - 3

ER DIAGRAM.

Our ER model contains 13 total tables that have been designed to normalize the database as much as
possible. All tables are at least in the first normal form, but most should be in the third normal form, as
table keys are fully dependent on their primary key. All required elements are included in this model,
but we found it challenging to accommodate the fluctuating prices of drugs per pharmacy, especially
because there was not necessarily an easy way to determine a base unit of price for all drugs. For that
reason, we created a table named “uom” that defines a unit of measurement to aid with pricing
pharmacy drugs accurately.

The majority of all tables in our database are normalized, with a couple exceptions:
 The state columns are not normalized into separate tables, because for the scope of this
database, building records would require more effort than necessary.
 Drugstore DB - 4

 We also chose not to normalize address columns, because there is no potential for these records
to be repeated between patient, doctor, and pharmacy.

CHALLENGES.

Database design:
As our team developed our ER diagram, we discovered that there was a need to include a new refill
table that could allow the database to track each refill individually and tie it to a prescription ID. We
built this additional table in response.
When the time came to build the database, we chose to build our sample data in a spreadsheet before
developing a script. This minimized some of the effort to import table data, but discovered in the
process that several data types were inconsistent between the tables. We accounted for this mistake and
the data imported correctly.

Working on the database:

Working with data that was consistent and identical across all team members was critical, so it was
determined that the best way to ensure this was to create a Linode server instance that was running
mySQL. After it was operational, the team worked off of the same credentials. This not only helped
keep our data consistent, but allowed other team members to easily access any views that were created
to run specialized queries on the database.

Developing the web applications:

Web applications were tested locally on each member’s machine. A couple of the required servlets were
simplified by creating views in the database, particularly the fourth and fifth bullet point of the design
specification document. This allowed us to reduce the amount of inline mySQL code mixed with Java.
One project member had stalled during this phase due to difficulties with the servlet not producing SQL
data. Our team came together to diagnose the problem. Through a debugging session we discovered a
minor omission of an integral parameter was the source of this problem and corrected it.
 Drugstore DB - 5

FORM INPUT AND OUTPUT IMAGES.

Doctor’s Prescription writing input:

Doctor’s Prescription writing output:

 Drugstore DB - 6

Prescription search input:

Prescription search output:

Fill Prescription/Prescription Cost estimate output:

 Drugstore DB - 7

Fill Prescription/Prescription Cost estimate input:

Pharmacy Manager drug report input:

 Drugstore DB - 8

Pharmacy Manager drug report output:

FDA Government Drug Report input:

 Drugstore DB - 9

FDA Government Drug Report output: