PharmCo Database Report

May, 2022

CST 363: Database Design

Andrew Kassis, Tiffany Andersen

Project Overview

PharmCo is a growing drug store chain that currently has over 400 locations. The company
requires an updated and efficient database design to effectively organize and track data
involving pharmacy locations, patients, doctors, prescriptions, and ongoing contracts with
pharmaceutical companies.

The goal of Precision Data Consulting is to provide a database solution that will meet and
exceed the needs of our client. We take it upon ourselves to foresee any and all information
that will need to be returned from a query, and organize the data in a way that will be useful in
streamlining day to day operations, as well as provide the information needed to make smart
business decisions and continue to expand the company.

Client Specifications

Every patient in the system will have a unique identification number, and details including their
name, age, address, phone number, and primary physician. Physicians will also have unique
identification numbers and information about their name, specialty, and years of experience.
Although each patient will have exactly one primary physician, any physician must be able to
write a prescription for any patient.

Every drug that Pharmco carries has a unique trade name and a generic formula, and the price
of each drug may vary by pharmacy location. Each drug is supplied by a specific
pharmaceutical company, and the name and phone number of that company will be stored and
readily available.

Every prescription will be for one drug and will have a unique prescription identification number,
the names of the doctor and patient, the date the prescription was written, the quantity included,
the drug identification number, the pharmacy where the prescription was filled and the date it
was filled.

In addition to organizing data surrounding pharmacies, doctors, patients, and prescriptions, the
database will also include information detailing long-term contracts with pharmaceutical
companies. Each pharmacy can have multiple contracts with separate pharmaceutical
companies, and each pharmaceutical company can have multiple contracts with separate
pharmacies. The database will keep track of each contract’s start and end dates and the text of
the contract. There will be a supervisor appointed for each contract, and some contracts may
have a common supervisor.
Entity-Relationship Model

Legend
Primary key

Foreign key

Required field

Optional field

Foreign key reference field

Assumptions and Design Decisions

● All tables have been given a unique, auto-incremented ID field as a primary key. Using
social security numbers to identify individuals is avoided for security reasons. Instead,
we make the SSN field unique, but relate patients to doctors by their IDs.

● In order to support international address formats, addresses are stored in a TEXT field.
Zip codes are stored separately, allowing us to filter by general area, as well as perform
lookups and address validation programmatically.

● Phone numbers are stored as VARCHAR(30) to allow plenty of space for country code,
varying lengths for international numbers, formatting, and any extensions that may be
required.

● Phone numbers are stored for doctors and patients, in case they need to be contacted.

● Dates in the prescription table have been split into two columns, date written and date
filled, to allow for tracking unfilled orders

● Most entity relationships are classified as zero-to-many, rather than one-to-many. This is
designed to account for the following cases:
○ Patients can have multiple prescriptions, but may also have none
○ A single drug can exist in many prescriptions, or may not be prescribed at all
○ New doctors, or doctors assigned to research, may have zero patients
○ Pharmaceutical companies in trial stages may not have public drug data yet
○ A planned or newly-constructed pharmacy may not have inventory or contract data
yet
○ Etc.

● Contract supervisors are given a single name field for flexibility, as a contract supervisor
could potentially be an individual, a company, or some other legal or financial institution.

● Contract text is stored as a TEXT field to allow for an indeterminate length.

Notes on Normalization

We have designed our database in a manner that eliminates redundancy and satisfies
normalization requirements to third normal form (3NF). First normal form (1NF) was adhered to
from the beginning by ensuring that each column of a relation is unique and no row contains
multiple values for the same column. Because each table has a single-column primary key, the
diagram is free of partial functional dependencies and therefore meets second normal form
(2NF) requirements. Finally, since no non-key column determines another non-key column on a
table the design is free of transitive functional dependencies and is normalized to 3NF.

Pre-Implementation Questions

● Are records in the pharmacy table strictly for PharmCo franchises? If so, should the
name simply reflect the store number? It may be useful to store pricing/inventory data for
competing pharmacies.

● Are contract supervisors individuals with a first and last name, or is a single name field
sufficient?

● Should any of the fields or relationships currently marked as optional (non null, or zero to
one) be considered mandatory instead?

● Should an address table be implemented, or is it sufficient to have address fields as

attributes on the patient and pharmacy tables?

What We Learned

This project so far has been an excellent learning experience and has provided us with several
fundamental concepts to get started in database design. We have become more proficient with
MySQL Workbench by utilizing the program to create our ER diagram and generate a database
schema using its forward engineering tool. We learned how to choose appropriate minimum
and maximum cardinality constraints for the relationships needed and how to depict them on our
diagram. While creating the model we practiced handling many-to-many relationships by
implementing intermediate tables. One of the key concepts we were introduced to on this
project was the process of analyzing functional dependencies to determine if restructuring is
required for normalization. We learned about update anomalies and how to maintain
compliance with referential integrity constraints using various delete and update options.
Though we were introduced to several new ideas in the first part of this project, one of the most
valuable experiences thus far has been the critical thinking process involved to plan and design
the database components needed for the assignment. We are enjoying this project and look
forward to learning even more while we work to complete the second part.
Screenshots

Prescription Create form:

A form with valid information entered: The resulting confirmation page:

Doctor’s SSN 1 digit off: The resulting error message: