Project 1: DB Design

&
Project 2 Web App and JDBC SQL
CST363: Intro to Database Systems
May 2022
Christian Vargas, Laurand Osmeni
Introduction
Databases are the center of information processing in pharmacy and health care. Medical and
pharmaceutical databases range in scale and scope, but the focus remains the same, which is
to provide better workflow and decision making.

At Express Tech, we pride ourselves on providing the best database development services that
fit the needs of any client. Our solutions seek to improve how a company can organize and
manage their data most effectively while also improving business processes. Through best
practices in layout design, our goal is to help clients increase healthcare services and more
importantly patient outcomes.

Our consulting company is focused exclusively on helping medical and pharmaceutical

companies accelerate strong business systems and operational performance through
databases and web resources. Express Tech is equipped to tackle some of the most complex
database performance issues and design challenges. We are excited to offer customized
technology solutions that can confidently optimize your business for cost savings and
maximum efficiency.

Processes and Requirements

Our databases and web resources will provide a smooth experience for any company to
access the needed information in the most efficient and user-friendly manner. Like for many
of our clients, this project will involve creating a pharmacy database for a growing drugstore
chain in need of a system to store data and rapidly search and retrieve data. The client has
outlined a set of requirements. These requirements can be briefly summarized in terms of the
entities and relationships needed, which involve the patient, prescription, pharmacy, doctor,
pharmaceutical company, contract, and the drug itself.

These goals and requirements were met by taking the following steps:

After careful analysis of the client requirements, a list of database requirements were made.
Through this, a Entity Relationship (ER) Diagram was created to easily visualize the data stored
(the attributes and entities) as well as the various relationships between tables. The ER
Diagram functions as a blueprint of what transactions need to be executed, which makes the
code writing easier to reproduce and understand. Next, the Relational Schema derived from
the ER Model is formulated using MySQL. After this process is completed, the database goes
through a series of normalization checks to make sure redundancy is eliminated and data is
logically stored. The final functionality test is based on a few SQL queries to demonstrate
effectiveness in our schema design. With careful consideration of this design process, Express
Tech provides some of the most reliable database resources available to meet any business
needs or requirements.

Express Tech 2
Safely Collect and Our streamlined workflow allows for companies to log a patient’s
Store Patient Data SSN, name, age, address, and other identifiable information. The
database is also capable of identifying a patient’s primary doctor and
their individual prescription(s).

Medical Professional Maintain a doctor’s identifying information such as their SSN, name,
Information Library specialty, and years of experience.

Pharmaceutical Drug Exceptional data management of products and formulas (trade or

Information generic) pharmaceutical companies provide.

Know Your Pharmacy Seamlessly track pharmacy locations and contact information based
on a patient’s information and prescription. Keep track of pricing
variations across pharmacies.

Normalized Database A pharmaceutical database optimized for reading and writing data in
the most efficient manner. Data is grouped logically to reduce
duplication and increase performance.

Pharmaceutical Our database keeps track of contractual agreement information and

Contractual supervisors appointed to these contracts as well as the start dates
Information and end dates between pharmaceutical companies and pharmacies.

ER Diagram Requirements
- Patient table has a one-to-many non-identifying relationship with the Doctor table and through
the use of the patient’s unique identifier we are able to identify whether the patient has a
primary physician, primary physician information, as well the patient prescription. One thing to
account for is that each patient can have a primary physician as well as many other doctors,
and doctors can have many patients and be the primary doctor for many patients. Patient has
a one-to-many identifying relationship with the Prescription table.
- The Doctor table has a one-to-many non-identifying relationship with both Doctor and
Prescription tables and there is a dependency for the Prescription table. The Prescription side
of the relationship is not mandatory, meaning the field can be NULL. Doctors can prescribe
one or many drugs for many patients.
- The Prescription table has a one-to-many non-identifying relationship with both the Pharmacy
and Doctor tables in addition to a one-to-many identifying relationship with the Patient and
Drug tables. The prescription identifier allows us to identify the pharmacy that filled the
prescription and the drugs that make up that prescription.
- The Pharmacy table has a non-identifying one-to-many relationship with both the Prescription
and Contract tables. Through the use of identifying one-to-many relationships with the Sells
table and its identifier we are able to determine the drugs that are sold at which pharmacies in
addition to the differences in pricing at each pharmacy. Another key component to the
Pharmacy table is the contractual agreements of the specified pharmacy.
- The Drug table has a one-to-many identifying relationship with both the Sells and Prescription
tables. The Drug table also has an identifying one-to many relationships with PharmaCompany.
Through the use of the identifier, we are able to determine the pharmacies that sell the
specified drug. This table also helps to determine the companies and their contractual
agreement for the specific drug. For a drug to exist there must be a pharmaceutical company
involved so both the Drug and PharmaCompany are involved.
- The Contract table has a one-to-many relationship with the PharmaCompany, Pharmacy, and
Supervisor tables. Through the use of the identifier from the Pharma_Company and Pharmacy
tables we can check the agreement between the tables. Lastly, the Supervisor table relationship
is a one-to-many relationship because it's possible a Supervisor can have many Contracts, even
though each contract has one Supervisor.

Express Tech 3
ER Model
The diagram below meets the client database requirements stated above. Below the ER
Diagram there are more technical descriptions and reasoning on why and how these
requirements are met.

Express Tech 4
Assumptions and Constraints
- The Patient can have a primary physician as well as many other doctors, and a Doctor can have multiple
patients. To resolve this, we created a idPrimaryDoctor attribute in the Patient table.
- The age attribute in the Patient table is a hardcoded INT value and provides a constraint, since a Date of
Birth attribute could be used instead, so the age can automatically be calculated with each passing year.
Similarly, in the Doctor table a Data Hired attribute could be used instead of doctorYearsOfExperience to
automatically calculate years of experience with each passing year.
- American SSNs are nine digits, but the patientSSN and doctorSSN are declared as VARCHAR(11) instead of
being constrained as INT(11) to avoid a MySQL warning indicating MySQL not supporting passing INT
values in the future.
- The phone number attributes in Patient, Doctor, and Pharmacy tables are constrained to a number of 13
characters to make up for dashes between area code and phone number itself.
- The Contracts table has a text attribute due to contractual agreements containing long text.
- End Dates of contracts are not accounted for on the Contracts table.
- Some addresses are broken into attributes of street number and name, city, state, zip instead of one TEXT
address. We assume addresses are in the United States and not in other countries.
- The Patient, Doctor, Pharmacy tables include added attributes not in specifications in order to provide for
more querying information.
- The Supervisor table could’ve easily been an attribute but we decided to make it its own table to make it
simpler in case the supervisor was to change.
- The Supervisor relationship is a one-to-many relationship because it's possible a Supervisor can have many
Contracts, even though each contract has one Supervisor.
- The price attribute in the Sales table must be a positive number since the price should not reach below
zero, in the real world with issuance it could be possible where the price could be zero.

Normalization Checks
Our ER Diagram satisfies all of the normalization checks with the foundation of bringing efficiency to the database
by not storing a piece of data in multiple places, but in one place to avoid redundancy. There were a series of steps
taken to verify the relational schema accurately followed a normalized form. Our ER diagram meets the
qualifications given that the 3rd Normal Form (3NF) satisfies the rules for 2nd Normal Form (2NF), and 2nd Normal
Form (2NF) adheres to those for 1st Normal Form (1NF). For 1NF: Each record has a unique identifier and each
table cell has a single value.. For 2NF: Each of the tables has a single primary key. For 3NF: The final check was to
eliminate any transitive dependency and maintain data integrity by eliminating any indirect relationship by having
separate tables.

Relational Schema Derived from the ER Model

-- 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,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

-- -----------------------------------------------------
-- Schema ProjectPharmacy
-- -----------------------------------------------------

-- -----------------------------------------------------
-- Schema ProjectPharmacy
-- -----------------------------------------------------
CREATE SCHEMA IF NOT EXISTS `ProjectPharmacy` DEFAULT CHARACTER SET utf8 ;
USE `ProjectPharmacy` ;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Doctor`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Doctor` (
`idDoctor` INT NOT NULL AUTO_INCREMENT,
`doctorFirstName` VARCHAR(45) NOT NULL,
`doctorLastName` VARCHAR(45) NOT NULL,

Express Tech 5
 `specialty` VARCHAR(45) NOT NULL,
`practice_since` INT NOT NULL,
`doctorSSN` VARCHAR(11) NOT NULL,
PRIMARY KEY (`idDoctor`))
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Patient`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Patient` (
`idPatient` INT NOT NULL AUTO_INCREMENT,
`patientFirstName` VARCHAR(45) NOT NULL,
`patientLastName` VARCHAR(45) NOT NULL,
`birthdate` DATE NOT NULL,
`patientSSN` VARCHAR(11) NOT NULL,
`patientStreet` VARCHAR(50) NOT NULL,
`patientCity` VARCHAR(25) NOT NULL,
`patientState` VARCHAR(2) NOT NULL,
`patientZip` VARCHAR(25) NOT NULL,
`idPrimaryDoctor` INT NOT NULL,
PRIMARY KEY (`idPatient`),
INDEX `fk_Patient_Doctor1_idx` (`idPrimaryDoctor` ASC) VISIBLE,
CONSTRAINT `fk_Patient_Doctor1`
FOREIGN KEY (`idPrimaryDoctor`)
REFERENCES `ProjectPharmacy`.`Doctor` (`idDoctor`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Pharmacy`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Pharmacy` (
`idPharmacy` INT NOT NULL AUTO_INCREMENT,
`pharmName` VARCHAR(45) NOT NULL,
`pharmAddress` VARCHAR(100) NOT NULL,
`pharmPhoneNumber` VARCHAR(13) NOT NULL,
PRIMARY KEY (`idPharmacy`))
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Drug`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Drug` (
`idDrug` INT(11) NOT NULL,
`tradeName` VARCHAR(100) NOT NULL,
`genericFormula` VARCHAR(200) NOT NULL,
PRIMARY KEY (`idDrug`))
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Prescription`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Prescription` (
`idPrescription` INT NOT NULL AUTO_INCREMENT,
`quantity` INT NOT NULL,
`prescriptionDate` DATE NOT NULL,
`dateFilled` DATE NULL,
`idDoctor` INT NOT NULL,
`idPatient` INT NOT NULL,
`idPharmacy` INT NULL,
`idDrug` INT NOT NULL,

Express Tech 6
 PRIMARY KEY (`idPrescription`, `idPatient`, `idDrug`),
INDEX `fk_Prescription_Doctor1_idx` (`idDoctor` ASC) VISIBLE,
INDEX `fk_Prescription_Patient1_idx` (`idPatient` ASC) VISIBLE,
INDEX `fk_Prescription_Pharmacy1_idx` (`idPharmacy` ASC) VISIBLE,
INDEX `fk_Prescription_Drug1_idx` (`idDrug` ASC) VISIBLE,
CONSTRAINT `fk_Prescription_Doctor1`
FOREIGN KEY (`idDoctor`)
REFERENCES `ProjectPharmacy`.`Doctor` (`idDoctor`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Prescription_Patient1`
FOREIGN KEY (`idPatient`)
REFERENCES `ProjectPharmacy`.`Patient` (`idPatient`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Prescription_Pharmacy1`
FOREIGN KEY (`idPharmacy`)
REFERENCES `ProjectPharmacy`.`Pharmacy` (`idPharmacy`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Prescription_Drug1`
FOREIGN KEY (`idDrug`)
REFERENCES `ProjectPharmacy`.`Drug` (`idDrug`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`PharmaCompany`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`PharmaCompany` (
`idPharmaCompany` INT NOT NULL AUTO_INCREMENT,
`pharmaCompanyName` VARCHAR(45) NOT NULL,
`pharmaCompanyPhone` VARCHAR(13) NOT NULL,
PRIMARY KEY (`idPharmaCompany`))
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Supervisor`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Supervisor` (
`idSupervisor` INT NOT NULL AUTO_INCREMENT,
`supervisorFirstName` VARCHAR(45) NOT NULL,
`supervisorLastName` VARCHAR(45) NOT NULL,
`supervisorPhone` VARCHAR(13) NOT NULL,
PRIMARY KEY (`idSupervisor`))
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Contract`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Contract` (
`idContract` INT NOT NULL AUTO_INCREMENT,
`startDate` DATE NOT NULL,
`endDate` DATE NOT NULL,
`contractText` VARCHAR(45) NOT NULL,
`idPharmaCompany` INT NOT NULL,
`idSupervisor` INT NOT NULL,
`idPharmacy` INT NOT NULL,
PRIMARY KEY (`idContract`),
INDEX `fk_Contract_PharmaCompany1_idx` (`idPharmaCompany` ASC) VISIBLE,
INDEX `fk_Contract_Supervisor1_idx` (`idSupervisor` ASC) VISIBLE,
INDEX `fk_Contract_Pharmacy1_idx` (`idPharmacy` ASC) VISIBLE,

Express Tech 7
 CONSTRAINT `fk_Contract_PharmaCompany1`
FOREIGN KEY (`idPharmaCompany`)
REFERENCES `ProjectPharmacy`.`PharmaCompany` (`idPharmaCompany`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Contract_Supervisor1`
FOREIGN KEY (`idSupervisor`)
REFERENCES `ProjectPharmacy`.`Supervisor` (`idSupervisor`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Contract_Pharmacy1`
FOREIGN KEY (`idPharmacy`)
REFERENCES `ProjectPharmacy`.`Pharmacy` (`idPharmacy`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Sells`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Sells` (
`idDrug` INT NOT NULL,
`idPharmacy` INT NOT NULL,
`price` DECIMAL(7,2) NOT NULL,
PRIMARY KEY (`idDrug`, `idPharmacy`),
INDEX `fk_Drug_has_Pharmacy_Pharmacy1_idx` (`idPharmacy` ASC) VISIBLE,
INDEX `fk_Drug_has_Pharmacy_Drug1_idx` (`idDrug` ASC) VISIBLE,
CONSTRAINT `fk_Drug_has_Pharmacy_Drug1`
FOREIGN KEY (`idDrug`)
REFERENCES `ProjectPharmacy`.`Drug` (`idDrug`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Drug_has_Pharmacy_Pharmacy1`
FOREIGN KEY (`idPharmacy`)
REFERENCES `ProjectPharmacy`.`Pharmacy` (`idPharmacy`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `ProjectPharmacy`.`Drug_has_PharmaCompany`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `ProjectPharmacy`.`Drug_has_PharmaCompany` (
`Drug_idDrug` INT(11) NOT NULL,
`PharmaCompany_idPharmaCompany` INT NOT NULL,
PRIMARY KEY (`Drug_idDrug`, `PharmaCompany_idPharmaCompany`),
INDEX `fk_Drug_has_PharmaCompany_PharmaCompany1_idx` (`PharmaCompany_idPharmaCompany` ASC) VISIBLE,
INDEX `fk_Drug_has_PharmaCompany_Drug1_idx` (`Drug_idDrug` ASC) VISIBLE,
CONSTRAINT `fk_Drug_has_PharmaCompany_Drug1`
FOREIGN KEY (`Drug_idDrug`)
REFERENCES `ProjectPharmacy`.`Drug` (`idDrug`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Drug_has_PharmaCompany_PharmaCompany1`
FOREIGN KEY (`PharmaCompany_idPharmaCompany`)
REFERENCES `ProjectPharmacy`.`PharmaCompany` (`idPharmaCompany`)
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;

Express Tech 8
SQL Queries
After testing various SQL statements against our relational schema, the database proved to be dynamic
and functional. The design was reviewed for normalization and no problems were found. In order to
demonstrate effectiveness in our schema design, we can give an idea of the various queries possible.
These queries were chosen because they do a good job of defining how elements within a database
relate to each other. Also, many of these queries are similar to something many standard pharmacy
databases would be capable of accomplishing. However, the schema design is not limited to these
queries and can be used for many other interesting queries to gather and analyze information of any
pharmacy system.

Query #1: Display the idPharmacy and corresponding count as "RxCount" for the pharmacy
that receives the most prescriptions orders excluding null values.
SELECT idPharmacy, MAX(presOrders) AS 'RxCount'
FROM (SELECT idPharmacy, COUNT(p.idPrescription) AS 'presOrders'
FROM Prescription p WHERE idPharmacy != "NULL" GROUP BY idPharmacy) AS pharmacyCount;
-- This query let's pharmacy personnel know which specific pharmacy receives the most prescriptions
orders, which might mean this store needs to have more staff to meet demand.

Query #2: Display patientFirstName, patientLastName, idPharmacy, and dateFilled

(prescription filled date) for all patients that have filled their prescriptions at branch CVS #12.
SELECT p.patientFirstName, p.patientLastName, ph.idPharmacy, pres.dateFilled
FROM Patient p
INNER JOIN Prescription pres ON p.idPatient = pres.idPatient
INNER JOIN Pharmacy ph ON pres.idPharmacy = ph.idPharmacy
WHERE ph.pharmName IN ('CVS #12');
-- This query provides valuable store data in terms of prescriptions and can let company owners and
providers know which stores are performing well and which stores are underperforming.

Query #3: Display doctorFirstName, doctorLastName, and "NumOfPatients" for the doctor with
the most patients born after a specific date, in this case, 2009-04-21. Order by “NumOfPatients”.
SELECT d.doctorFirstName, d.doctorLastName, COUNT(p.idPrimaryDoctor) AS
'NumOfPatients' FROM Patient p, Doctor d WHERE p.idPrimaryDoctor = d.idDoctor
AND p.birthdate > "2009-04-21" GROUP BY d.doctorFirstName
ORDER BY NumOfPatients DESC LIMIT 1;
-- This query could serve to crosscheck information on doctor specialties, such as a doctor specializing in
pediatrics should be prescribing more to patients ages 18 and below. Also, a pharmacy might be interested
in knowing which doctor deals with which population.

Query #4: Display the idDoctor, doctorFirstName, doctorLastName and

doctorYearsOfExperience, and a count of prescriptions given as 'RxCount' if the doctor gave out
prescriptions in the year 2021. Order by idDoctor.
SELECT pres.idDoctor, d.doctorFirstName, d.doctorLastName, d.practice_since, COUNT(*)
AS 'PrescriptionsGiven' FROM prescription pres INNER JOIN doctor d ON pres.idDoctor =
d.idDoctor WHERE pres.prescriptionDate LIKE '2021%' GROUP BY pres.idDoctor;
-- This query can be useful to see if the number of prescriptions given is correlated to the years of
experience a doctor has. Also, this query can help identify busy or prescription-happy doctors.

Express Tech 9
Query #5: Display patientZip as the zip code where the highest number of patients reside as
well as the corresponding number of patients as ‘highestNumOfPatients’.
SELECT patientZip, MAX(patients) AS 'highestNumOfPatients'
FROM (SELECT patientZip, COUNT(p.idPatient) AS 'patients'
FROM Patient p GROUP BY patientZip) AS zipCount;

-- This query can be used by public health and pharmacy professionals to understand which
areas have the highest need and therefore invest more resources in those areas.

Conclusions Till Now

What We Learned:
Firstly, we learned how to create a relational schema from scratch from learning how to think
about sets of tables and how to efficiently set associations between items. Designing the
database schema made the SQL code database easier to complete. Our group learned about
the important role ER Diagrams play in planning, designing, and analyzing databases. The ER
Diagram is everything, and in some cases, it makes more sense to see the ER Diagram than
the actual code itself, because with the diagram and knowing the layout and what
transactions need to be executed, you can easily rewrite the code. Our database for this
assignment was relatively small, but we’d imagine that when you’re dealing with databases
with hundreds of tables, having some sort of a "map" is extremely useful.

We learned about how ER diagrams specify the data stored (the attributes and entities) as
well as the relationships in terms of one-to-one, one-to-many, and many-to-many
relationships. In this way, we learned about relation database constructs, and also had the
chance to create relationships between the various tables in the database. There were some
challenges the group faced during data modeling, but we learned about normalization which
helped us check our tables to ensure they were designed properly. We learned how to use
smaller tables to minimize redundancy and undesirable anomalies in order to check that only
the related data was stored in each table. We learned about the First Normal Form, Second
Normal Form, and Third Normal Form and how generally normalization achieves its best in
3rd Normal Form.

Open Questions to Be Addressed in Part 2:

Should we account for the Defined Daily Dose (DDD), which is the assumed average dose per
day for a drug used for its main indication in adults? In other words, should the database seek
to be more explicit in regards to prescribed doses a patient should be taking on a daily basis?
Similarly, should the database account for refill limits? This ties into the quantity of a
prescription as well as frequency and special instructions, which could also be invaluable and
add an extra layer of safety. Should we account more for the Drug Item itself? This can also
provide potentially valuable information in terms of potentially listing chemical names in a
specific drug capable of inducing a drug allergy.

In terms of the Pharmacy table if the records are composed of many companies, each store
name be followed by a store and or franchise number? Lastly, should we account for this
database being able to work in any country? This might require changing the columns for
addresses.

Express Tech 10
Application Functional Requirements
Following the creation of the database, the next stage was to create a web application that
allowed users to access the database in a user-friendly manner. For the Application Functional
Requirements, two criteria were identified to complete the project:

1. A program to generate 100 random patients, 10 random doctors and 100 random
prescriptions.
2. A pharmacy manager should be able to request a report of the quantity of drugs that
have been used to fill prescriptions by the pharmacy. The report will consist of the
names of drugs used and the quantity of each drug used. In order to accomplish this
the input required is pharmacy id and a start and end date range.

Web App Functional Requirements

For the Web App Functional Requirements the following two parts were also identified based on the
client's instructions:

1.
Part A)
● A doctor should be able to create a new prescription which the patient can get filled at a
pharmacy.
○ A doctor requests a blank form for a new prescription. There’s validation that
the Doctor’s SSN exists and matches the Doctor’s name. Likewise, there’s
validation that the Patient SSN exists and matches the Patient’s name. Lastly,
there’s validation that the Drug name exists. Lastly, the new prescription is
inserted . If successful the prescription with the rxid number that was generated
by the database is returned. Otherwise, if an error occurs, there is a return
message and the prescription form.
Part B)
● A patient should be able to request for a prescription to be filled. Once a prescription is
made successfully with the data input, the patient should be shown the prescription
form with the data.
○ A patient requests a form to search for a prescription. The prescription fill
request from the patient is processed. This involves validating the prescription
contains rxid, pharmacy name, and pharmacy address to uniquely identify a
prescription and a pharmacy. From here, updates to the prescription are made
in terms of pharmacyid, name and address, as well as an update to today's date.
Lastly, the final updated prescription is displayed, unless there is an error, in
which case the error form is shown with a message.
2.
● A patient should be able to register themselves to the system and choose a primary
care doctor. The goal is to process a new patient registration.
○ The patient enters their name, social security number, address, birthdate and
chooses a primary care physician. The program validates the information for
logicality.
○ The idea here is that a primary care physician should be a doctor who
specializes in Family Medicine, Internal Medicine or, if the patient is a child,
Pediatrics and not surgery or oncology.

Express Tech 11
Project Implementation and Visualization
Web Applications
Communicating design and product implementation throughout the process is important,
therefore the following screenshots present potential frontend design plans to meet the
dependability of our dynamic and flexible database design. One design decision made was to
not allow the user to continue onto the next page until all of the information was correct.
Therefore, there should not be cases where database updates are submitted with errors.
However, that is accounted for and the user would be notified of an error.

Upon opening the application the user is presented with the following Main Menu:

As you will find with many of the options in the application, there are various outcomes,
mostly in terms of the application taking in either valid input and invalid input. The first link at
the top labeled “Write a new prescription (for Doctors only)” sends the user to the New
Prescription form page which is where the user, in this case the doctor, would fill in the empty
spaces with their information as well as the patient’s data.

This screenshot displays an empty prescription form to be filled out by a doctor.

Express Tech 12
For example, below is what would appear if the Doctor fills out the form correctly with all of
the correct information. In other words, if successful the prescription with the rxid number
that was generated by the database is returned. The image below is what would appear if the
form was filled out and submitted successfully.

This screenshot displays a prescription successfully created. The empty prescription information is
filled once the patient goes out and gets the prescription filled.

This screenshot displays an error message due to an illegal character entered into the Doctor SSN.

Express Tech 13
This screenshot displays the error message for when the doctor SSN does not match with the first
and last name pair in the database. In addition, the program will not move forward considering
fields are left blank.

Once the correct last name, “Good” is entered, a new error message appears which is in regards to
the patient information now not matching. The correct Patient First Name should be “Fernando.”

Express Tech 14
In the next screenshot valid information is entered for both doctor and patient, but the error is in
regards to the drug name not being entered so the drug is not found. A simple error message
printing “Fields cannot be blank” can be used but the direct field being printed is cleaner.

The screenshot below shows an invalid drug name entered.

Express Tech 15
 Lastly, the final screenshot shows an error for the “quantity” input

Furthermore, invalid submissions are presented with an error message and a detailed
description of the type of error that happened. For valid submissions, as described above, the
prescription with the rxid number that was generated by the database is returned. As seen in
the successful form photo, there is no type of error message.

The second link is for the patient to request for a prescription to be filled by selecting the
second option labeled “Request for prescription to be filled (for Patients only).” An empty
“Request Prescription to be filled” form will appear which takes in the following information:

This screenshot displays an empty form for a patient to request for their prescription to be filled.

Express Tech 16
The case of a successful input and output involves the prescription fill request from the
patient being processed by first validating the prescription contains rxid, pharmacy name, and
pharmacy address to uniquely identify a prescription and a pharmacy. In turn, updates to the
prescription are made in terms of pharmacyid, name and address, as well as an update to
today's date as seen below:
This screenshot below displays a successful prescription made.

On the original form, if there is an error, at the top of the screen there will be an error
message with an explanation indicating the reason for failure:

In the case below, the errors are that the prescription id number and prescription last name do not
match in addition to the two empty fields.

Express Tech 17
 Now that the prescription id number and prescription last name match, the error no longer
appears. However the pharmacy name and pharmacy address are empty.

The following displays the error that the pharmacy name and pharmacy address do not match,
thus firing an error that the pharmacy is invalid.

Express Tech 18
The third link is for the patient to be able to register themselves to the system and choose a
primary care doctor. The link is labeled “Register as a new patient (for Patients only).” Once
selecting this the following screen appears:

For a successful page, the patient enters their name, social security number, address,
birthdate and chooses a primary care physician.

The program validates the information for logicality and if successful a screen validating a
successful registration appears. If there is an error, a screen indicating various errors appears.
The implementation for this phase is still in progress, therefore no validation is pictured.

JDBC Applications
The images below display console output for two programs based on requirements. The first
requirement being a program to generate 100 random patients, 10 random doctors and 100
random prescriptions. The java class is named DataGenerate and uses the com.csumb.cst 363
package.

Express Tech 19
 The screenshot below shows confirmation from the console that the doctor, the patient, and the
prescription tables have been populated with the automatically generated data needed.

The screenshot below shows the database populated with ten random doctors.

The screenshot below shows the database populated with one hundred random patients.

Express Tech 20
The screenshot below shows the database populated with one hundred random prescriptions. The
dataFilled and idPharmacy fields will be null or blank until the prescription has been filled.

The second requirement is that the pharmacy manager has the option to request a report of
the quantity of drugs that have been used to fill prescriptions by the pharmacy. The report will
take in the inputs of pharmacy id and a start and end date range as input. The output consists
of the original parameters of pharmacy id (by pharmacy name), Start Date, and End Date. As
seen in the screenshot below, the drug report is composed of the names of drugs used and
the quantity of each drug filled. There is also the case in which no results are found, which
would result in empty space under drug and quantity used.

Console output of the pharmacy report using two filled prescriptions as an example.

Express Tech 21
Final Conclusions and Summary
The pharmacy database required for a growing drugstore chain in need of a system to store
data and rapidly search and retrieve data was completed according to the requirements. As
pictured above, the database and web resources provide a smooth experience for each type
of user to access the needed information in the most efficient and user-friendly manner. With
each incremental step in design and implementation there were various improvements
completed in order to produce the best workflow and decision making in the application.

The first phase in design involved a series of five steps before proceeding to creating a web
based data application. First, there was a careful analysis of the client requirements and a list
of database requirements were made. Second, a Entity Relationship (ER) Diagram was made
to conveniently visualize the data stored, the different relationships across tables, and the
transactions needed to be executed. Third, the Relational Schema derived from the ER Model
was formulated utilizing MySQL. Fourth, the database went through a variety of normalization
checks in order to ensure that redundancy was eliminated and to make sure the data
dependencies are reasonable. Fifth, the database was tested with sample data and various
queries in order to demonstrate consistency and logicality in the schema design.

The second phase involved implementing a user-friendly web application to access the
database, which was accomplished using Spring Boot JDBC. Before this step, more validating
and testing was done on the database in order to ensure that the database was functioning as
required. The application was created with the goal to accomplish a series of four tasks, which
allowed various personnel to access the information in the databases to their specific needs,
while keeping good design concepts and sensitive data hidden.

Ultimately, our dynamic project design and implementation streamlines workflow allowing for
companies to seamlessly access information for different needs. Through our final layout
design and implementation, we have succeeded in meeting the ultimate goal to increase
healthcare services and more importantly patient outcomes.

Express Tech 22