Relational Database For Drug Store Chain
Relational Database For Drug Store Chain
Grid has been contracted by Drug Store Chain (DSC) to design and implement a database
management system. The purpose of this system is to provide a relational database capable of
storing and managing the details related to DSC’s business of selling drugs and filling
prescriptions. As part of this initiative, Grid has prepared the following report. Part one of the
report details out the project’s requirements, the proposed entity relationship (ER) diagram,
normalized relational schema, and SQL queries answering questions relevant to DSC needs. Part
Part One
Requirements
companies. In addition, it must be able to store records of the drugs DSC stores sell or are
requested to fill. The database must also maintain records of the prescriptions DSC stores are
being requested to fill along with records of each fill. Finally, the database must be capable of
creating records containing the details of contracts DSC stores have with various pharmaceutical
companies as well as details of the supervisors DSC stores have appointed to maintain each
contract. Each of these components have more detailed requirements that are summarized in the
following sections.
Patient Records
Patient records represent the person who is receiving/taking a particular drug and who is
being treated by a doctor. Each patient record must have a SSN that will be used to uniquely
identify each patient. In addition, each record will allow DSC to capture the patient’s first name,
3
last name, age, and address (street address, city, state, and zip code). Finally, each patient record
Doctor Records
Doctor records represent the person who is prescribing medication to one or more
patients. Each doctor record must have a SSN that will be used to uniquely identify each doctor.
The records will also store the doctor’s first name, last name, specialty, and number of years of
experience.
Pharmacy records represent a particular location of a DSC store. Each pharmacy record
will have an ID number that will be automatically generated to uniquely identify each pharmacy.
These records will also capture the name, address (street address, city, state, zip code), and phone
Pharmaceutical company records represent a company that manufactures and sells drugs
pharmaceutical company’s name and will also capture its phone number.
Drug Records
Drug records represent a particular trade name and formulation of a drug sold by a
pharmaceutical company. These records capture the trade name and formula of the drug along
with the name of the pharmaceutical company that sells the drug. In combination, the trade
Drug pricing records will allow each unique pharmacy to set and store the price that it
sells a particular drug for. (Note: A drug is identified by its trade name, formula, and
pharmaceutical company name.) These records will be uniquely identified by the combination of
Prescription Records
Prescription records represent the drug and amount of drug being prescribed to a patient
by a provider. Each prescription record will capture the patient, doctor, drug, quantity, and date
patient can be prescribed many prescriptions and a doctor can write many prescriptions.
particular prescription. These records are uniquely identified by the prescription and the
pharmacy. In addition, these records capture the date the prescription was filled.
Contract Records
pharmacies. These records capture the pharmaceutical company and pharmacy along with the
text of the contract and the start and end date of the contract. These records will have their own
companies may contract with many different pharmacies and vice versa. Each contract record
Supervisor Records
5
Supervisor records represent the person from the pharmacy that is responsible for a
contract. These records capture the first and last name of the supervisor. Each record will have
Relational Schema
-- -----------------------------------------------------
-- Schema Project1
-- -----------------------------------------------------
CREATE SCHEMA IF NOT EXISTS `Project1` DEFAULT CHARACTER SET utf8 ;
USE `Project1` ;
-- -----------------------------------------------------
-- Table `Project1`.`Doctor`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Doctor` (
`doctorssn` INT NOT NULL,
`firstname` VARCHAR(45) NOT NULL,
`lastname` VARCHAR(45) NOT NULL,
`specialty` VARCHAR(45) NOT NULL,
`yearsofexperience` INT NOT NULL,
PRIMARY KEY (`doctorssn`),
UNIQUE INDEX `doctorssn_UNIQUE` (`doctorssn` ASC) VISIBLE)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `Project1`.`Patient`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Patient` (
`patientssn` INT NOT NULL,
`firstname` VARCHAR(45) NOT NULL,
`lastname` VARCHAR(45) NOT NULL,
`age` INT NOT NULL,
`streetaddress` VARCHAR(255) NOT NULL,
`city` VARCHAR(100) NOT NULL,
`state` VARCHAR(45) NOT NULL,
`zipcode` VARCHAR(45) NOT NULL,
`Doctor_doctorssn` INT NOT NULL,
6
-- -----------------------------------------------------
-- Table `Project1`.`Pharmaceutical Company`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Pharmaceutical Company` (
`companyid` INT NOT NULL AUTO_INCREMENT,
`companyname` VARCHAR(45) NOT NULL,
`phonenumber` VARCHAR(45) NOT NULL,
PRIMARY KEY (`companyid`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `Project1`.`Drug`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Drug` (
`drugid` INT NOT NULL AUTO_INCREMENT,
`tradename` VARCHAR(45) NOT NULL,
`formula` VARCHAR(45) NOT NULL,
`companyid` INT NOT NULL,
PRIMARY KEY (`drugid`),
INDEX `fk_Drug_Pharmaceutical Company1_idx` (`companyid` ASC) VISIBLE,
CONSTRAINT `fk_Drug_Pharmaceutical Company1`
FOREIGN KEY (`companyid`)
REFERENCES `Project1`.`Pharmaceutical Company` (`companyid`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `Project1`.`Pharmacy`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Pharmacy` (
`pharmacyid` INT NOT NULL AUTO_INCREMENT,
`pharmacyname` VARCHAR(45) NOT NULL,
`pharmacyphonenumber` VARCHAR(45) NOT NULL,
`streetaddress` VARCHAR(255) NOT NULL,
`city` VARCHAR(100) NOT NULL,
`state` VARCHAR(45) NOT NULL,
`zipcode` VARCHAR(45) NOT NULL,
PRIMARY KEY (`pharmacyid`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `Project1`.`Prescription`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Prescription` (
`prescriptionid` INT NOT NULL AUTO_INCREMENT,
`date` DATE NOT NULL,
`quantity` INT NOT NULL,
7
-- -----------------------------------------------------
-- Table `Project1`.`Supervisor`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Supervisor` (
`supervisorid` INT NOT NULL AUTO_INCREMENT,
`supervisorfirstname` VARCHAR(45) NOT NULL,
`supervisorlastname` VARCHAR(45) NOT NULL,
PRIMARY KEY (`supervisorid`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `Project1`.`Company Contract`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Company Contract` (
`contractid` INT NOT NULL AUTO_INCREMENT,
`startdate` DATE NOT NULL,
`enddate` DATE NOT NULL,
`contracttext` TEXT(100000) NOT NULL,
`Pharmacy_pharmacyid` INT NOT NULL,
`Pharmaceutical Company_companyid` INT NOT NULL,
`Supervisor_supervisorid` INT NOT NULL,
PRIMARY KEY (`contractid`),
INDEX `fk_Company Contract_Pharmacy1_idx` (`Pharmacy_pharmacyid` ASC) VISIBLE,
INDEX `fk_Company Contract_Pharmaceutical Company1_idx` (`Pharmaceutical Company_companyid` ASC) VISIBLE,
INDEX `fk_Company Contract_Supervisor1_idx` (`Supervisor_supervisorid` ASC) VISIBLE,
CONSTRAINT `fk_Company Contract_Pharmacy1`
FOREIGN KEY (`Pharmacy_pharmacyid`)
REFERENCES `Project1`.`Pharmacy` (`pharmacyid`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Company Contract_Pharmaceutical Company1`
FOREIGN KEY (`Pharmaceutical Company_companyid`)
REFERENCES `Project1`.`Pharmaceutical Company` (`companyid`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Company Contract_Supervisor1`
8
-- -----------------------------------------------------
-- Table `Project1`.`Pharmacy_filled_Prescription`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Pharmacy_filled_Prescription` (
`Pharmacy_pharmacyid` INT NOT NULL,
`Prescription_prescriptionid` INT NOT NULL,
`datefilled` DATE NULL,
PRIMARY KEY (`Pharmacy_pharmacyid`, `Prescription_prescriptionid`),
INDEX `fk_Pharmacy_has_Prescription_Pharmacy1_idx` (`Pharmacy_pharmacyid` ASC) VISIBLE,
INDEX `fk_Pharmacy_filled_Prescription_Prescription1_idx` (`Prescription_prescriptionid` ASC) VISIBLE,
CONSTRAINT `fk_Pharmacy_has_Prescription_Pharmacy1`
FOREIGN KEY (`Pharmacy_pharmacyid`)
REFERENCES `Project1`.`Pharmacy` (`pharmacyid`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Pharmacy_filled_Prescription_Prescription1`
FOREIGN KEY (`Prescription_prescriptionid`)
REFERENCES `Project1`.`Prescription` (`prescriptionid`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `Project1`.`Pharmacy_has_Drug`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `Project1`.`Pharmacy_has_Drug` (
`Pharmacy_pharmacyid` INT NOT NULL,
`Drug_drugid` INT NOT NULL,
`price` DECIMAL(6,2) NOT NULL,
PRIMARY KEY (`Pharmacy_pharmacyid`, `Drug_drugid`),
INDEX `fk_Pharmacy_has_Drug_Pharmacy1_idx` (`Pharmacy_pharmacyid` ASC) VISIBLE,
INDEX `fk_Pharmacy_has_Drug_Drug1_idx` (`Drug_drugid` ASC) VISIBLE,
CONSTRAINT `fk_Pharmacy_has_Drug_Pharmacy1`
FOREIGN KEY (`Pharmacy_pharmacyid`)
REFERENCES `Project1`.`Pharmacy` (`pharmacyid`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Pharmacy_has_Drug_Drug1`
FOREIGN KEY (`Drug_drugid`)
REFERENCES `Project1`.`Drug` (`drugid`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
USE `Project1`;
DELIMITER $$
USE `Project1`$$
$$
DELIMITER ;
SET SQL_MODE=@OLD_SQL_MODE;
9
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
SQL Queries
When it comes to questions that are of interest to management, we realized that there are
a multitude of tables and relations to be seen. For the sake of this report we will limit our focus
2. How many contracts between pharmacy and pharmaceutical companies are there?
Question 1 (one), would give us a better understanding of what prescription drug is in the most
demand and which drugs fail to meet criteria or are not working well amongst most patients. A
great example of this would be two very similar drugs, but one may cause more side effects than
Question 2 (two), can provide insight to which pharmaceutical companies have the best
relationship with fellow pharmacies. One can assume having more contracts would mean better
business, better quality medications, and all around better satisfaction not only for management
Questions 3 (three) and 4 (four) are somewhat related. Question 3 allows us to see the number of
patients that each primary care doctor has and question 4 allows us to see whether or not they are
writing prescriptions and to what ratio they are writing prescriptions to patients. However, the
prescriptions they write do not have to be from those who label them as primary care doctors
since the doctor could write prescriptions for those that he feels need the prescribed medication.
-- Question 3
select doc.firstname, doc.lastname, count(p.Doctor_doctorssn) as
totalpatients
from Doctor as doc
join Patient as p on doc.doctorssn=p.Doctor_doctorssn
group by doc.doctorssn
order by totalpatients;
-- Question 4
select doc.firstname, doc.lastname, count(pres.Doctor_doctorssn) as
totalprescriptions
from Doctor as doc
join Prescription as pres on doc.doctorssn=pres.Doctor_doctorssn
group by doc.doctorssn;
11
Question 5 (five), allows us to better understand which pharmacies are filling out the most
prescriptions and which are not quite meeting the quota. Along with that, we will also better
understand which drugs are bringing in the most revenue when each prescription is filled.
Lastly, question 6 (six) understanding how many patients share the same doctor could lead us to
find trends in regards to prescription habits and generally what is being prescribed the most as
seen by tendencies. Patients sharing the same doctor could end up being prescribed more of the
same drug which would cause us to refill our inventory more on a regular basis.
ER Model
The above ER diagram contains multiple relationships about a growing drug store chain.
The first is a non-identifying one to many relationship between a doctor and one or more of its
patients. A patient contains a primary key of the patient's SSN along with its first name, last
name, age, street address, city, state and zipcode. In addition the patient has its own doctor ssn to
which links the patient to its primary physician through its foreign key. The doctor has its
primary key being its doctor’s SSN along with its first name, last name, specialty and years of
prescription. The prescription’s primary key includes the prescription id along with its date and
quantity. Also the prescription table has the foreign keys of drug id, patient ssn and doctor ssn. A
doctor can prescribe multiple prescriptions for any given patient. A drug has the primary key of
the drug id along with its trade name formula, in addition has the foreign key company id. The
Drug table has a 1 to many non-identifying relationship with the prescription table. In addition a
administered. The pharmaceutical company to which the drug is produced has the primary key of
its company id along with its company name and phone number. To fill a prescription it goes
through a many to many identifying relationship with a pharmacy. A pharmacy’s primary key is
the pharmacy id along with its pharmacy name, pharmacy phone number, street address, city,
state and zip code. The prescription and pharmacy tables are linked through the pharmacy id and
the prescription id along with the date filled. The pharmacies have a many to many identifying
relationship with drugs. The many to many relationship between the drug and pharmacy tables
determine whether or not the desired pharmacy contains a drug is by the pharmacies id, drugs id
and the price of the drug. In order for a pharmacy to get distribution for a particular drug, they
need a company contract with a pharmaceutical company. Between the pharmacy and company
contract tables, there is a non-identifying one to many relationship. In addition between the
pharmaceutical company and the company contract table, there is also a non-identifying one to
many relationship. The contract between the pharmacy and the pharmaceutical company needs a
supervisor as well to conduct the business end of the relationship. A supervisor’s primary key is
its supervisor id along with its supervisor first name and supervisor last name. The supervisor
and the company contract tables have a non-identifying one to many relationship. The company
contract tables have the primary key of contract id along with a start date, end date and contract
text. Also the company contract contains the pharmacy id, company id and supervisor id as
foreign keys.
In summary, Grid has detailed out the requirements as Grid understands them, created an
initial ER diagram that conforms to and addresses the requirements, produced relational schema
in alignment with the ER diagram, and provided a list of suggested queries to be used as
14
potential reports. During the course of compiling this information, Grid has obtained a more
thorough understanding of the database design process and gained experience in utilizing tools to
create database diagrams and schema. Moving into the next phase of the project, Grid has
additional questions related to the types of reports DSC would like to include in its application as
well as questions regarding the layouts for the different types of user interfaces the application
should have.
15
Part 2
In part two of the project we develop the appropriate java program necessary to interact
with the web browser and MySQL database using Spring Boot and JDBC. Through the use of
mapping annotations the spring server will call the method associated with the URL.
When the initial Drug System web page is displayed the user is presented with the 4
choices. After selecting a choice the user is brought to the appropriate web page and given the
When a Doctor selects the first link they will be presented with a form to fill out the
prescription for the patient. The form contains entries for the Doctor SSN, Doctor Name, Patient
SSN, Patient Name, Drug Name, and Quantity. When the Doctor is finished they can click the
“Create Prescription” button. In the event the Doctor enters the wrong information for example
an incorrect SSN, the form will display a message alerting them of the mistake. After the doctor
has successfully created the prescription the request is sent to the Spring Boot Server for
processing. The @GetMapping will map the url to the form and the @PostMapping will begin
the process of validating the entries. At anypoint an error is encountered for example, a quantity
of zero for the drug, the error message will display alerting the Doctor of the mistake. If the
information is valid, the MySQL statement is created using the PreparedStatement object. Also
used is the ResultSet object to execute a query with the user provided information. Upon
successful database queries, the insertion of the prescription is made into the database and the
The following screenshots show the initial screen, an error message for unknown drug
name, and the screenshot of a correctly filled form, and a successfully created prescription:
16
17
Prescription Filled
● A patient requests that a pharmacy fill a prescription. The patient enters a prescription
number and the name and address of a pharmacy. The prescription is updated with the
pharmacy data, cost and current date, and redisplayed to the user.
Joey Dirt enters a prescription number and the name and address of a pharmacy. The prescription
18
updates with the updated cost of the total quantity of drugs dispensed along with the current date
For the case where a prescription is already filled, we add an attribute message “Rxid
already filled” to the prescription/fill page to inform the user. In addition, we handled the case of
user input being a wrong Rx. We added an attribute message to indicate to the user that they
The Pharmacy Drug Report allows any of DSG’s pharmacies to obtain details about the
quantity of drugs they have dispensed while filling prescriptions. The report is intended to
provide the details about which drugs were filled and the total quantity of each drug filled over a
Report users will provide the ID of the pharmacy they are interested in and then provide
the period of time they would like to report over. When the report user leaves the drug field
blank, the report will provide details for every drug filled.
If the report user would like to limit the results to a specific drug they can provide the
name of the drug they are interested in. They may choose to only input the first few letters of a
drug name and the report will provide results for any drugs that match the partial name. In
addition, if the user does not provide a start date, the report will default the start date to
‘01/01/1900”. Likewise, if the user does not provide an end date, the report will default the end
If the report user enters a Pharmacy ID that does not exist, the results will inform the user
that the pharmacy does not exist. The report will also provide the user notice if an invalid date
range has been provided, such as in instances where the start date comes after the end date.
21
FDA REPORT
For FDA reports, we have made the process simpler and easy to use to assist in getting
the correct information quickly and reliably. Below, you will find examples of how the form
works and also some of the checks we have implemented in the course of designing the
application. Here, you will see screenshots of a successful input and output coming from the
user.
● Successful Input/Output
Notice in this example, how the user has input a partially complete drug name. We have designed
our application to find the full drug name and output in our FDA report for easy understanding
and easy access. We also include the Doctor’s first name and also the quantity of drug he has
What about the cases when we have incorrect output such as a drug not being found
within our system or improper dates being inserted (i.e. start date that comes after the end date or
no date at all)? We did not forget to account for these errors also and within the next several
screenshots.
22
In the case where a drug is not found within our database, notice how we handle the
situation. We still show the report to the user, with the dates that they have input, however, we
display a message in the “drug” attribute to show the drug does not exist or the drug was not
Here, we can see that the user has input a start date that comes after our end date. As
done with our failed drug input, we still display the report with an improper date. However, we
concatenate a message to the improper date, notifying the user that the start date should come
before the end date. Which is why we do not show anymore information.
23
● No Date Input
Lastly, there is the case of no start date and no end date entered into the form. To handle
this, we as a team decided to fill in those dates in the case of no input. As our default start date,
we have set it to be “1900-01-01” and for our end date, we made our default to be that of the
current date. One thing to note is that we still get proper output for both “Doctor” and “Quantity
Prescribed” columns. This is because the drug is still a proper entry and we have prescriptions