Project 1: Data Design

January 26th, 2020

Austin Steward
Emerald Kunkle
Introduction
 This project aims to design and implement a SQL-based database tailored for a
pharmaceutical business. Relevant tables included in this database include Patient, Doctor,
Company, Drug, Pharmacy, Prescription, Contract, DrugPricing, DrugFilled, and Supervisor. With
these tables, our requirement is to design an ER diagram, alongside the corresponding database
schema that captures the tables mentioned, in which we will fill with preliminary data to
exercise the relationship of tables through a series of five questions.
The five questions have been chosen by us but written to the beneficiary perspective of
the pharmaceutical business. The questions chosen to be exercised in this project are as
follows:
1. What prescriptions were filled on this specific month by this specific doctor?
2. Which pharmacy supervisor is assigned to the most contracts, and display all of
them.
3. Which drug is being prescribed the most in this certain age group?
4. Which drug is being prescribed the most during this month?
5. Which pharmacy has sold the most/filled drugs for this month and display the total
amount made.

ER Model
After establishing the introduction to this report, the next discussion point is the ER
model developed for this assignment. We established the following entities and relationships in
our diagram to reflect the schema:

Entity: Patient
Patients are one of the entities in the model, with the possible attributes of patientSSN,
name, age, and address. These attributes can be described as followed: patientSSN is the
Patient’s Social Security number as an INT number, name is the Patient’s first name as a
VARCHAR of length 50, age is the Patient’s age in years as an INT number, and address is the
Patient’s home address as a VARCHAR of length 50. The key attribute for a Patient is their
patientSSN.
Patients have two relationships. Patients have a one-to-many relationship with Doctors,
in which a Doctor can have zero to many Patients, and a Patient must have exactly one Doctor.
In addition, Patients also have a one-to-many relationship with Prescription, in which a Patient
can have zero to many Prescriptions, and a Prescription must have exactly one Patient.
There is one relationship attribute for Patient, assigned. This relationship attribute
assigned is between Patient and Prescription.
Entity: Doctor
 Doctors are one of the entities in the model, with the possible attributes of doctorSSN,
yearsOfExp, name, and specialty. These attributes can be described as followed: doctorSSN is
the Doctor’s Social Security number as an INT number, yearsOfExp is the Doctor’s years of
experience in their profession as an INT number, name is the Doctor’s first name as a VARCHAR
of length 50, and specialty is the Doctor’s practicing specialty as a VARCHAR of length 50. The
key attribute for a Doctor is their doctorSSN.
Doctors have two relationships. Doctors have a one-to-many relationship with Patients,
in which a Doctor can have zero to many Patients, and a Patient must have exactly one Doctor.
In addition, Doctors also have a one-to-many relationship with Prescription, in which a Doctors
can have zero to many Prescriptions, and a Prescription must have exactly one Doctor.
There is one relationship attribute for Doctor, prescribes. This relationship attribute
prescribes is between Doctor and Prescription.

Entity: Prescription
Prescriptions are one of the entities in the model, with the possible attributes of
doctorSSN, patientSSN, perscriptionID, quantity, dateAssigned, and tradeName. These attributes
can be described as followed: doctorSSN is the Social Security number of the Prescription’s
Doctor as an INT number, patientSSN is the Social Security number of the Prescription’s Patient
as an INT number, perscriptionID is the identification number of the Prescription as an INT
number, quantity is the quantity of the Prescription’s Drug as an INT number, dateAssigned is
the date of the Doctor prescribed the Prescription as an DATE, and tradeName is the
Prescription’s Drug tradename as an VARCHAR of length 50. The key attributes for a
Prescriptions are their doctorSSN, patientSSN, and tradeName.
Prescriptions have four relationships. Prescriptions have a one-to-many relationship
with Patients, in which a Patient can have zero to many Prescriptions, and a Prescription must
have exactly one Patient. In addition, Prescriptions also have a one-to-many relationship with
Doctors, in which a Doctors can have zero to many Prescriptions, and a Prescription must have
exactly one Doctor. In addition, Prescriptions also have a many-to-many relationship with
Pharmacy, in which a Prescription can have zero to many Pharmacies, and a Pharmacy can
have zero to many Prescriptions. In addition, Prescriptions also have a one-to-many
relationship with Drug, in which a Drug can have zero to many Prescriptions, and a Prescription
must have exactly one Drug.
There are four relationship attributes for Prescriptions, assigned, prescribes, includes,
and drugFilled. The relationship attribute assigned is between Patient and Prescription. The
relationship attribute prescribes is between Doctor and Prescription. The relationship attribute
includes is between Drug and Prescription. The relationship attribute drugFilled is between
Pharmacy and Prescription.
Entity: Drug
 Drugs are one of the entities in the model, with the possible attributes of formula, and
tradeName. These attributes can be described as followed: formula is the chemical formula of
the Prescription’s Drug as a VARCHAR of length 50, and tradeName is the Drug’s tradename as
an VARCHAR of length 50. The key attribute for Drugs is their tradeName.
Drugs have three relationships. Drugs have a one-to-many relationship with
Prescriptions, in which a Drugs can have zero to many Prescriptions, and a Prescription must
have exactly one Drug. In addition, Drugs also have a one-to-many relationship with
PharmaCompany, in which a PharmaCompany can have zero to many Drugs, and a Drug must
have exactly one PharmaCompany. In addition, Drugs also have a one-to-many relationship
with PharmaCompany, in which a PharmaCompany can have zero to many Drugs, and a Drug
must have exactly one PharmaCompany. In addition, Drugs also have a many-to-many
relationship with Pharmacy, in which a Drug can have zero to many Pharmacies, and a
Pharmacy can have one to many Drugs.
There are two relationship attributes for Drugs, includes, and drugPricing. The
relationship attribute includes is between Drugs and Prescription. The relationship attribute
drugPricing is between Drugs and Pharmacy.

Entity: Pharmacy
Pharmacies are one of the entities in the model, with the possible attributes of
phoneNum, address, and pharmaName. These attributes can be described as followed:
phoneNum is the telephone number of the Pharmacy as a VARCHAR of length 50, address is the
Pharmacy’s physical address as an VARCHAR of length 50, and pharmaName is the Pharmacy’s
name or title as a VARCHAR of length 50. The key attribute for Pharmacies is their
pharmaName.
Pharmacies have four relationships. Pharmacies have a many-to-many relationship with
Drugs, in which a Drug can have zero to many Pharmacies, and a Pharmacy can have one to
many Drugs. In addition, Pharmacies have a many-to-many relationship with Prescription, in
which a Prescription can have zero to many Pharmacies, and a Pharmacy can have zero to
many Prescriptions. In addition, Pharmacies have a many-to-many relationship with
PharmaCompany, in which a PharmaCompany can have zero to many Pharmacies, and a
Pharmacy can have zero to many PharmaCompanies. In addition, Pharmacies have a one-to-
many relationship with Supervisor, in which a Supervisor must have exactly one Pharmacy, and
a Pharmacy can have one to many Supervisors.
There are three relationship attributes for Pharmacies, drugFilled, contract, and
drugPricing. The relationship attribute drugFilled is between Pharmacy and Prescription. The
relationship attribute contract is between Pharmacy and PharmaCompany. The relationship
attribute drugPricing is between Pharmacy and Drug.
Entity: PharmaCompany
 PharmaCompanies are one of the entities in the model, with the possible attributes of
phoneNum, and compName. These attributes can be described as followed: phoneNum is the
telephone number of the PharmaCompanies as a VARCHAR of length 50, and compName is the
PharmaCompanies’ name or title as a VARCHAR of length 50. The key attribute for
PharmaCompanies is their compName.
PharmaCompanies have two relationships. PharmaCompanies have a one-to-many
relationship with Drugs, in which a PharmaCompany can have one to many Drugs, and a Drug
must have exactly one PharmaCompany. In addition, PharmaCompanies have a many-to-many
relationship with Pharmacy, in which a PharmaCompany can have one to many Pharmacies,
and a Pharmacy can have one to many PharmaCompanies.
There is one relationship attributes for PharmaCompanies, contract. The relationship
attribute contract is between Pharmacy and PharmaCompany.

Entity: Supervisor
Supervisors are one of the entities in the model, with the possible attributes of name,
contractID, and pharmaName. These attributes can be described as followed: name is the given
name of the Supervisor as a VARCHAR of length 50, contractID is the individual Supervisor’s
contract identification number as an INT number, and pharmaName is the name of the
pharmacy the Supervisor works at as a VARCHAR of length 50. The key attributes for
Supervisors are their contractID and pharmaName.
Supervisors have two relationships. Supervisors have a one-to-one relationship with
Contracts, in which a Contract must have exactly one Supervisor, and a Supervisor must have
exactly one Contract. In addition, Supervisors have a one-to-many relationship with Pharmacy,
in which a Pharmacy can have one to many Supervisors, and a Supervisor must have exactly
one Pharmacy.
There is one relationship attributes for Supervisors, contract.

Relationship: DrugFilled
DrugFilled is one of the relationships in the model, between Prescription and Pharmacy.
It has the attributes of pharmaName, perscriptionID, and dateFilled. These attributes can be
described as followed: pharmaName is the given name of the Pharmacy the Prescription is
being filled at as a VARCHAR of length 50, perscriptionID is individual Prescription identification
number as an INT number, and dateFilled is the date the Prescription was filled at the
Pharmacy as a DATE. The key attributes for Drugfilled are their pharmaName and
perscriptionID.

Relationship: DrugPricing
 DrugPricing is one of the relationships in the model, between Drug and Pharmacy. It has
the attributes of price, tradeName, and pharmaName. These attributes can be described as
followed: price is the given numerical price of the Drug at the Pharmacy as an INT number,
tradeName is the Drug’s tradename as a VARCHAR of length 50, and pharmaName is the name
or title of the Pharmacy the Drug is being filled at as a VARCHAR of length 50. The key
attributes for DrugPricing are their pharmaName and tradeName.

Relationship: Contract
Contract is one of the relationships in the model, between Pharmacy and
PharmaCompany. It directly interacts with the entity Supervisor. It has the attributes of text,
startDate, endDate, pharmaName, companyName, and contractID. These attributes can be
described as followed: text is the written textual agreement of the Contract between the
Pharmacy and PharmaCompany concerning the Supervisor as a VARCHAR of length 100,
startDate is the Contract’s starting date as a DATE, endDate is the Contract’s ending date as a
DATE, pharmaName is the name or title of the Pharmacy the Contract is being enacted at as a
VARCHAR of length 50, companyName is the name or title of the PharmaCompany the Contract
is being enacted at as a VARCHAR of length 50, and contractID is the individual identifying
number of the Contract as an INT number. The key attributes for Contract are their
pharmaName and companyName.

The Graphical Representation of the ER Model:

 Relational Schema Derived from the ER Model
With the establishment and definitions of the ER Model and its entities and
relationships, next in this report would be the documentation of the schema in SQL that depicts
the implementation of our ER Model.

Entity: Patient
CREATE TABLE: CONSTRAINTS:
Update command will cascade. The
attributes patientSSN, age, name, and address
all can not be set to NULL.
Delete command will cascade. The
attributes patientSSN, age, name, and address
all can not be set to NULL.

Entity: Doctor
CREATE TABLE: CONSTRAINTS:
Update command will cascade. The
attributes doctorSSN, name, specialty, and
yearsOfExp all can not be set to NULL.
Delete command will cascade. The
attributes doctorSSN, name, specialty, and
yearsOfExp all can not be set to NULL.

Entity: Prescription
CREATE TABLE: CONSTRAINTS:
Update command will cascade. The attributes
doctorSSN, paitentSSN, tradeName, dateAssigned,
quantity, and perscriptionID all can not be set to
NULL.
Delete command will cascade. The
attributes doctorSSN, paitentSSN, tradeName,
dateAssigned, quantity, and perscriptionID all can
not be set to NULL.
 Entity: Drug
CREATE TABLE: CONSTRAINTS:
Update command will cascade. The
attributes tradeName, and formula both can
not be set to NULL.
Delete command will cascade. The
attributes tradeName, and formula both can
not be set to NULL.

Entity: Pharmacy
CREATE TABLE: CONSTRAINTS:
Update command will cascade.
The attributes pharmaName, address,
and phoneNum all can not be set to
NULL.
Delete command will cascade.
The attributes pharmaName, address,
and phoneNum all can not be set to
NULL.

Entity: PharmaCompany
CREATE TABLE: CONSTRAINTS:
Update command will cascade. The
attributes compName and phoneNum
both can not be set to NULL.
Delete command will cascade. The
attributes compName and phoneNum
both can not be set to NULL.
 Entity: Supervisor
CREATE TABLE: CONSTRAINTS:
Update command will cascade. The
attributes contractID, pharmaName, and
name all can not be set to NULL.
Delete command will cascade. The
attributes contractID, pharmaName, and
name all can not be set to NULL.

Relationship: DrugFilled
CREATE TABLE: CONSTRAINTS:
Update command will
cascade. The attributes
pharmaName, perscriptionID, and
dateFilled all can not be set to NULL.
Delete command will
cascade. The attributes
pharmaName, perscriptionID, and
dateFilled all can not be set to NULL.

Relationship: DrugPricing
CREATE TABLE: CONSTRAINTS:
Update command will
cascade. The attributes tradeName,
pharmaName, and price all can not
be set to NULL.
Delete command will
cascade. The attributes tradeName,
pharmaName, and price all can not
be set to NULL.
 Relationship: Contract
CREATE TABLE: CONSTRAINTS:
Update command will cascade. The
attributes compName, pharmaName,
startDate, endDate, text, and contractID all
can not be set to NULL.
Delete command will cascade. The
attributes compName, pharmaName,
startDate, endDate, text, and contractID all
can not be set to NULL.

Normalized Relational Schema

The design was normalized by trying to reduce the number of repeating groups as much
as possible. This allowed for only the relationships of DrugPricing, DrugFilling, and Contract to
need attributes, and thus reduce repetition.
Areas of the design with no repetition would be sections like includes, prescribes, and
assigned.

SQL Queries
1. “What prescriptions were filled on this specific month by this specific doctor?”
This question would be useful to know to keep try of how many prescriptions a month a
doctor is giving out.

2. Which pharmacy supervisor is assigned to the most contracts, and display all of them.
In management, its important to keep track of employees, including supervisors.
Displaying the one with the most contracts can be useful.
 3. Which drug is being prescribed the most in this certain age group?
For both studies and demographic reasons, knowing the most popular drugs by age
group is very crucial information.

4. Which drug is being prescribed the most during this month?

Stocking staff might find it necessary to know what drugs are being prescribed the most,
so that they know what to order more of.

5. Which pharmacy has sold the most/filled drugs for this month and display the total
amount made.
The financial heads of the pharmacy would find it useful to track the most sold/filled
drugs, and the revenue those transactions gained.

Conclusion
What we have learned in this project was the creation and implementation of ER
diagrams and schemas, as well as how to map and design entities and relationships with that. It
taught us a lot about the interconnection between multiple working databases and tables, and I
do not believe we have any open question for part 2, although it was never specified what part
2 is or what it is going to be.
 Screenshots

Objective #1: a doctor writes a prescription for a patient for a drug and a quantity. The
input form will have fields for the doctor to enter their ssn and name, the patient ssn and
patient name, the drug name and quantity. Output should be the prescription RX# and display
of the prescription data. The pharmacy data is empty until the next step.
Valid Data Invalid Data

Objective #2: 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 user.
Valid Data Invalid Data
 Objective #3: a pharmacy manager requests a report of the quantity of drugs that have
been used to fill prescriptions by the pharmacy. Report contains the name of the drug and the
quantity used. Input is pharmacy id and the date range.
Valid Data Invalid Data

Objective #4: an FDA government official is looking for the quantity of drugs that each
doctor has prescribed. The report shows doctor’s name and quantity prescribed. Input is drug
name(may be partial name)and date range.
Valid Data Invalid Data