Drug Store Database

Database Design and Implementation Project: Part 1

CST363-30_SP23
January 23, 2023

Our Team:

Kenneth Ao Jeff Nguyen Michelle Brown

Purpose and Client Requirements

The Drug Store Database’s goal is to efficiently keep track of our client’s entities and records that
they interact with on a daily basis. Our client, a drug store chain, is responsible for making sure
that their patients’ prescriptions are fulfilled accurately and in a timely manner. However, with all
the moving parts that are involved, our company is excited to implement the database that we
have developed to help streamline their processes.
This process begins with a patient and their primary physician. As many of us are familiar, we visit
our doctor when we are not feeling well. The result of this doctor’s visit could be a prescription for
medication to help our condition improve. Our database will make sure to keep track of every
patient, physician and prescription that is written by a doctor for a patient. We also make sure that
each record is unique from one another so that there aren’t any mix ups as to which prescription
is for which patient.
After the prescription is written, it is then sent to the pharmacy for fulfillment. However, to
determine which pharmacy will fulfill the prescription depends on what the drug is and whether it
should be the generic or brand name version. The selection of drugs that are sold at each
pharmacy is determined by a contract between a pharmacy and pharmaceutical company (the
manufacturer of the drugs). A supervisor manages these contracts for each pharmacy to ensure
the correct/desired drugs are being purchased from the pharmaceutical companies and in stock
at the pharmacy.
If the physician has indicated on the prescription that the drug can be generic, then the
prescription can be fulfilled with any drug of the same name, manufactured from any
pharmaceutical company. However, if the physician indicated that the drug should be brand
name, the fulfillment is stricter and can only be fulfilled by that drug name from a specific
pharmaceutical company. With our database, these rules can be enforced with the information
stored from various related tables.
Once the appropriate pharmacy has filled the patient’s prescription, the date and pharmacy that
filled it is recorded on the patient’s original prescription. With the drug that was used to fill the
prescription, we can also trace back to which pharmaceutical company was the manufacturer of
the drug. As seen with many of our client’s other entities, our database relates all of them in one
way or another, allowing to dot walk to different pieces of data when needed,
Now that the patient knows which pharmacy to go pick up their prescription, another important
factor to determine is how much their drug will cost. A drug may not cost the same price,
depending on which pharmacy the patient picks it up from. To keep track of the cost differences,
our database will store the different prices based on the combination of the drug and the
pharmacy it's sold at.
When a patient is anxiously waiting to pick up their prescription in hopes to feel better, the last
thing that they, their doctor or the pharmacy should have to worry about is delays due to
misplaced or scattered information. Our company’s goal is to help keep our clients’ data clean,
organized and easily accessible!

1
ER Model

Link for larger view:

ER model.png

How the entities, attributes and relationships in our design address the requirements:
There are a total of nine tables to address the requirements of the client. Pharmaceutical
company and pharmacy tables are linked with a main table known as contract via foreign keys.
Similarly, the prices table serves a link between the pharmacy and drug tables also through
foreign keys. Above shows the full diagram of the tables, attributes, and their relationships.

Database Tables Descriptions

doctor Contains information on the doctor and their background

patient Contains information about the patients

pharmaceutical_co Contains information about pharmaceutical companies and how to get in touch
mpany with them via telephone

pharmacy Contains detailed information of the pharmacy retail, their location, and their

2
 telephone number

contract Serves as the main link between pharmaceutical companies and pharmacy retails
and contains detail about their partnership and how long it will continue.

prices Serves as the main link between drug and pharmacy retails and contains
information about the set prices of generic drug vs branded drugs.

prescriptions Contains detailed information on which doctor prescribed what drug to which of
their patients.

drug Contains detail about drugs who have a “generic” formula and drugs that were
developed by branded pharmaceutical companies

supervisor Contains a supervisor’s id and name. A supervisor’s id is indicated on a Contract

to identify which supervisor is managing the contract.

The database allows the client to bring up information of doctors and their patients. Information
from the database on the doctors ranges from their SSN, years of expertise, and their specialty.
Since every patient has one primary physician, they are able to list out which client seeks
attention from which physician. Also, the client would be able to gather information if a doctor has
prescribed drugs, generic or branded, to their patients. If the drug that is branded was prescribed,
the client would be able to track back to which pharmaceutical company that developed the drug.
Since any physician can prescribe as many medications the patient needs, every prescription
would include the following: RX number, quantity amount per bottle, doctor who prescribed it, the
patient, and date it was filled. In addition, the information about the drug can show if it contains a
generic formula or a branded one. If the drug contains a generic formula, it can be sold at various
stores at varying prices.
In order for pharmaceutical companies and pharmacy retailers to work together properly, they
create a contract between them. Each contract lists out the details of how they will operate
together and how long they will do business with each. Along with each contract, there is an
appointed supervisor who will oversee the terms of the contract being fulfilled.

Other assumptions and constraints:

Some assumptions based on what the client requested is utilizing the decimal dataset to have a
range of values of .01 to 99,999.99 for both generic and branded drug prices. The decimal values
were set at a reasonable price for prescriptions and can assume multiple drugs can be in one
transaction. Names for both doctors and patients are set as Varchar(45) to give a variable amount
of characters rather than having a set amount of characters due to names that can be lengthy
and hyphenated. The constraint is still there due to trying to avoid an overlap in the dataset. Most
primary keys were developed naturally throughout the process. There were two entities that were
developed through the use of artificial surrogate keys, which are the contract and prices entities.
Due to the client’s requirement of pharmaceutical companies and retail pharmacies having many
relationships, a bridge between the entities was created called contract.
3
Relational Database Schema

-- MySQL Script generated by MySQL Workbench

-- Sun Jan 22 18:10:29 2023

-- Model: New Model Version: 1.0

-- MySQL Workbench Forward Engineering

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;

SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;

SET @OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERRO
R_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

-- -----------------------------------------------------

-- Schema mydb

-- -----------------------------------------------------

-- -----------------------------------------------------

-- Schema mydb

-- -----------------------------------------------------

CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET utf8 ;

USE `mydb` ;

-- -----------------------------------------------------

-- Table `doctor`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `doctor` (

`doctorid` VARCHAR(3) NOT NULL,

`doctor_name` VARCHAR(45) NOT NULL,

`doctor_SSN` INT NOT NULL,

`speciality` VARCHAR(45) NOT NULL,

`years_experience` DECIMAL(4,2) NOT NULL,

PRIMARY KEY (`doctorid`),

4
 UNIQUE INDEX `doctor_SSN_UNIQUE` (`doctor_SSN` ASC) VISIBLE)

ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `patient`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `patient` (

`patientid` VARCHAR(3) NOT NULL,

`patient_name` VARCHAR(45) NOT NULL,

`patient_DOB` DATE NOT NULL,

`patient_SSN` INT NOT NULL,

`patient_address` VARCHAR(100) NOT NULL,

`doctorid` VARCHAR(3) NOT NULL,

PRIMARY KEY (`patientid`),

UNIQUE INDEX `patient_SSN_UNIQUE` (`patient_SSN` ASC) VISIBLE,

INDEX `fk_patient_doctor1_idx` (`doctorid` ASC) VISIBLE,

UNIQUE INDEX `patientid_UNIQUE` (`patientid` ASC) VISIBLE,

CONSTRAINT `fk_patient_doctor1`

FOREIGN KEY (`doctorid`)

REFERENCES `doctor` (`doctorid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `pharmaceutical company`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `pharmaceutical company` (

`companyid` INT NOT NULL AUTO_INCREMENT,

`company_name` VARCHAR(45) NOT NULL,

`phone_number` INT NOT NULL,

5
 PRIMARY KEY (`companyid`),

UNIQUE INDEX `company_name_UNIQUE` (`company_name` ASC) VISIBLE)

ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `pharmacy`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `pharmacy` (

`pharmacyid` INT NOT NULL AUTO_INCREMENT,

`pharmacy_name` VARCHAR(45) NOT NULL,

`pharmacy_address` VARCHAR(100) NOT NULL,

`pharmacy_number` INT NOT NULL,

PRIMARY KEY (`pharmacyid`))

ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `drug`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `drug` (

`drugid` INT NOT NULL,

`generic_drug` VARCHAR(45) NOT NULL,

`brand_drug` VARCHAR(45) NULL,

`companyid` INT NOT NULL,

PRIMARY KEY (`drugid`),

UNIQUE INDEX `brand_drug_UNIQUE` (`brand_drug` ASC) VISIBLE,

INDEX `fk_drug_pharmaceutical company1_idx` (`companyid` ASC) VISIBLE,

CONSTRAINT `fk_drug_pharmaceutical company1`

FOREIGN KEY (`companyid`)

REFERENCES `pharmaceutical company` (`companyid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)
6
ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `perscription`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `perscription` (

`perscriptionid` INT NOT NULL AUTO_INCREMENT,

`RX_number` INT NOT NULL,

`quantity` INT NOT NULL,

`patientid` VARCHAR(3) NOT NULL,

`drugid` INT NOT NULL,

`doctorid` VARCHAR(3) NOT NULL,

`date_filled` DATETIME NULL,

`pharmacy_filled` INT NULL,

`generic_or_brand` VARCHAR(45) NOT NULL,

PRIMARY KEY (`perscriptionid`),

INDEX `fk_perscription_patient1_idx` (`patientid` ASC) VISIBLE,

INDEX `fk_perscription_drug1_idx` (`drugid` ASC) VISIBLE,

INDEX `fk_perscription_doctor1_idx` (`doctorid` ASC) VISIBLE,

UNIQUE INDEX `RX_number_UNIQUE` (`RX_number` ASC) VISIBLE,

INDEX `fk_perscription_pharmacy1_idx` (`pharmacy_filled` ASC) VISIBLE,

CONSTRAINT `fk_perscription_patient1`

FOREIGN KEY (`patientid`)

REFERENCES `patient` (`patientid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `fk_perscription_drug1`

FOREIGN KEY (`drugid`)

REFERENCES `drug` (`drugid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `fk_perscription_doctor1`
7
 FOREIGN KEY (`doctorid`)

REFERENCES `doctor` (`doctorid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `fk_perscription_pharmacy1`

FOREIGN KEY (`pharmacy_filled`)

REFERENCES `pharmacy` (`pharmacyid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `prices`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `prices` (

`drugid` INT NOT NULL,

`pharmacyid` INT NOT NULL,

`pricesid` INT NOT NULL,

`generic_prices` DECIMAL(5,2) NOT NULL,

`brand_prices` DECIMAL(5,2) NOT NULL,

PRIMARY KEY (`drugid`, `pharmacyid`, `pricesid`),

INDEX `fk_drug_has_pharmacy_pharmacy1_idx` (`pharmacyid` ASC) VISIBLE,

INDEX `fk_drug_has_pharmacy_drug1_idx` (`drugid` ASC) VISIBLE,

CONSTRAINT `fk_drug_has_pharmacy_drug1`

FOREIGN KEY (`drugid`)

REFERENCES `drug` (`drugid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `fk_drug_has_pharmacy_pharmacy1`

FOREIGN KEY (`pharmacyid`)

REFERENCES `pharmacy` (`pharmacyid`)

ON DELETE NO ACTION
8
 ON UPDATE NO ACTION)

ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `supervisor`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `supervisor` (

`supervisorid` INT NOT NULL AUTO_INCREMENT,

`supervisor_name` VARCHAR(45) NOT NULL,

PRIMARY KEY (`supervisorid`))

ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `contract`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `contract` (

`contractid` INT NOT NULL,

`start_date` DATETIME NOT NULL,

`end_date` DATETIME NOT NULL,

`contract_text` VARCHAR(200) NOT NULL,

`companyid` INT NOT NULL,

`pharmacyid` INT NOT NULL,

`supervisor_supervisorid` INT NOT NULL,

PRIMARY KEY (`contractid`),

INDEX `fk_companyid` (`companyid` ASC) VISIBLE,

INDEX `fk_pharmacy_idx` (`pharmacyid` ASC) VISIBLE,

INDEX `fk_contract_supervisor1_idx` (`supervisor_supervisorid` ASC) VISIBLE,

CONSTRAINT `fk_companyid`

FOREIGN KEY (`companyid`)

REFERENCES `pharmaceutical company` (`companyid`)

ON DELETE NO ACTION
9
 ON UPDATE NO ACTION,

CONSTRAINT `fk_contract_pharmacy1`

FOREIGN KEY (`pharmacyid`)

REFERENCES `pharmacy` (`pharmacyid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `fk_contract_supervisor1`

FOREIGN KEY (`supervisor_supervisorid`)

REFERENCES `supervisor` (`supervisorid`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB;

SET SQL_MODE=@OLD_SQL_MODE;

SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;

SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

10
5 Interesting Questions for Management

Query 1 text: List the drugid’s produced by X pharmaceutical company that are sold at Y
pharmacy
Query 1 SQL statement:
select drug.drugid

from `pharmaceutical company` pc join drug on pc.companyid=drug.companyid

join prices on drug.drugid=prices.drugid

join pharmacy on prices.pharmacyid=pharmacy.pharmacyid

where pc.company_name = 'X';

Query 2 text: Which drug did doctor X write the most prescriptions for?
Query 2 SQL statement:
select drug.drugid

from doctor join perscription on doctor.doctorid=perscription.doctorid

join drug on perscription.drugid=drug.drugid

where drug.drugid = (select MAX(drugcount)

from (select COUNT(drug.drugid) as drugcount

from drug

group by drug.drugid) as druglist);

Query 3 text: Which pharmaceutical company does pharmacy X have contracts with?
Query 3 SQL statement:
select pc.companyid

from `pharmaceutical company` pc join contract on pc.companyid=contract.companyid

join pharmacy on contract.pharmacyid=pharmacy.pharmacyid

where pharmacy.pharmacyid = 'X';

11
Query 4 text: How many different pharmacies can patient X fill their prescription from?
Query 4 SQL statement:
select COUNT(pharmacy.pharmacyid)

from patient join perscription on patient.patientid=perscription.patientid

join drug on perscription.drugid=drug.drugid

join prices on drug.drugid=prices.drugid

join pharmacy on prices.pharmacyid=pharmacy.pharmacyid;

Query 5 text: On average, how much does each patient spend on drugs?
Query 5 SQL statement:
select patient.patientid, AVG(prices.brand_prices)

from patient join perscription on patient.patientid=perscription.patientid

join drug on perscription.drugid=drug.drugid

join prices on drug.drugid=prices.drugid

group by patient.patientid;

12
Design Normalization

Check your design for normalization and what actions (if any) you took and why.
Because this was a top-down design, we were able to keep our relational schema in 3NF fairly
easy. As we designed and created each relation, if any relation had one column and then
additional columns after it where the information was always the same, a new relation was
created. For example, in the patient relation, there is one column for the patient’s primary
physician (doctorid). However, instead of including additional columns in the patient relation for
the doctor’s name, SSN, etc., this was created into a separate relation (doctor). That way, the
patient relation refers to the doctor table, but information about the doctor is stored in a separate
relation. We did not identify any unnormalized tables in our schema. Also, because we did not
identify any unnormalized tables, we also did not find any potential for update anomalies.

Conclusions

Our group has created a database schema that keeps track of tables commonly used in
the pharmaceutical industry. By connecting many different data tables together, clients will be
able to easily fill prescriptions for patients quickly and efficiently.
This project gave our group more hands-on experience in creating schemas using MySQL
Workbench. Creating a diagram in MySQL first helped us visualize how the tables should be
relating to each other, which made it easier to write the question queries. In the future, we will be
able to graph out the broad ideas before moving on to write each individual part.

13