2021

Project 1: Database
Design
TRINIDAD RAMIREZ
JERRIDAN BONBRIGHT
Introduction:
The goal of designing this database for the drug store chain is to keep it simple and
promote continuity. We want the database relations to mirror the actual logistics of obtaining
prescribed drugs from the company to the patient. In addition, this business contains lots of
sensitive data that we must protect in regards to updates and access to data. In order to achieve
this goal, we will need additional entities to bridge the gaps between distributing the drug to the
pharmacy, and from the pharmacy to the doctor. We will add prescription, contract, and sales
transaction entities to ensure we keep track of where the drugs are supplied from and who they
are prescribed to.
The initial requirements of this design call for patient, doctor, pharmacy, drug, and
company entities. The patients and doctors will be easily distinguishable with the use of social
security numbers. We will also keep track of the patient’s name, age, and address. For each
doctor, we will store their name, specialty, and years of experience. Each pharmacy will have its
own name, address, and phone number. Through the use of a prescription entity, we can cover
the requirement of allowing each pharmacy to sell a drug at its own price. As for the companies
supplying the pharmacies, they will be distinguishable by name. If a company is deleted, the
drugs that they provide will be deleted as well. Doctors will prescribe and distribute the drug to
the patient. Patients should be able to obtain drugs from various doctors. A contract entity will
keep track of the contractual details regarding start and end date, text, company name, pharmacy
name, and pharmacy supervisor.
Entity Relationship Diagram:

Relational Schema Derived From ER Model:

CREATE TABLE doctor (
`doctor_ssn` VARCHAR(15) NOT NULL,
`doctor_name` VARCHAR(50) NOT NULL,
`doctor_specialty` VARCHAR(50),
`years_of_experience` INT NOT NULL,
PRIMARY KEY (`doctor_ssn`)
);
CREATE TABLE patient (
`patient_ssn` VARCHAR(15) NOT NULL,
`doctor_ssn` VARCHAR(15) NOT NULL,
`patient_name` VARCHAR(50) NOT NULL,
`patient_age` INT NOT NULL,
`patient_address` VARCHAR(50) NOT NULL,
PRIMARY KEY (`patient_ssn`),
FOREIGN KEY (doctor_ssn) REFERENCES doctor(doctor_ssn)
);

CREATE TABLE pharmacy (

`pharmacy_id` INT NOT NULL,
`pharm_name` VARCHAR(50) NOT NULL,
`pharm_address` VARCHAR(50) NOT NULL,
`pharm_phone` VARCHAR(12) NOT NULL,
PRIMARY KEY (`pharmacy_id`)
);

CREATE TABLE prescription (

`prescription_id` INT NOT NULL,
`patient_ssn` VARCHAR(15) NOT NULL,
`doctor_ssn` VARCHAR(15) NOT NULL,
`price` DOUBLE NOT NULL,
`date_filled` VARCHAR(10) NOT NULL,
 PRIMARY KEY (`prescription_id`),
FOREIGN KEY (patient_ssn) REFERENCES patient(patient_ssn),
FOREIGN KEY (doctor_ssn) REFERENCES doctor(doctor_ssn)
);

CREATE TABLE company (

`company_id` INT NOT NULL,
`company_name` VARCHAR(50) NOT NULL,
`company_phone` VARCHAR(12) NOT NULL,
PRIMARY KEY (`company_id`)
);

CREATE TABLE drug (

`trade_name` VARCHAR(50) NOT NULL,
company_id INT NOT NULL,
`formula` VARCHAR(50) NOT NULL,
PRIMARY KEY (`trade_name`),
FOREIGN KEY (company_id) REFERENCES company(company_id)
);

CREATE TABLE salestransaction (

`tid` INT NOT NULL,
`pharmacy_id` INT NOT NULL,
`trade_name` VARCHAR(50) NOT NULL,
PRIMARY KEY (`tid`),
FOREIGN KEY (pharmacy_id) REFERENCES
pharmacy(pharmacy_id),
FOREIGN KEY (trade_name) REFERENCES drug(trade_name)
 );

CREATE TABLE contract (

`contract_text` VARCHAR(500),
company_id INT NOT NULL,
pharmacy_id INT NOT NULL,
`start_date` VARCHAR(10) NOT NULL,
`end_date` VARCHAR(10) NOT NULL,
`pharm_supervisor` VARCHAR(50) NOT NULL,
PRIMARY KEY (`contract_text`),
FOREIGN KEY (company_id) REFERENCES company(company_id),
FOREIGN KEY (pharmacy_id) REFERENCES pharmacy(pharmacy_id)
);

CREATE TABLE includes (

`prescription_id` INT NOT NULL,
`tid` INT NOT NULL,
`quantity` INT NOT NULL,
PRIMARY KEY (`prescription_id`, `tid`),
FOREIGN KEY (prescription_id) REFERENCES
prescription(prescription_id),
FOREIGN KEY (tid) REFERENCES salestransaction(tid)
);
Normalized Relational Schema:
As for normalization of the relational schema, there were a few possibilities regarding
which normal form we wanted to design our database around. For the sake of this project, the
optimal choice was to go with the first normal form. This greatly reduced the amount of
redundant data that may have occurred with an unnormalized database. Our use of IDs for
primary keys also helped with potential future changes, additions, or deletions as each attribute
was unique as a result of these IDs. Although the second and third normal forms were still an
option, our lack of composite keys already does a decent job of reducing partial dependencies,
meaning that we do not have to protect against them so meticulously.

SQL Tables:
SQL Queries:
1. Which patients have received repeat prescriptions from the pharmacy, “Pharma Med”?
Explanation:
This information may be helpful as it shows customers who have received refills or
frequently visit the pharmacy.

2. For patients who have been prescribed Albuterol, what is the name of the doctor and their
area of specialty?
Explanation:
Knowing the name of the doctor and their specialty can be useful as it tells us if doctors
are writing appropriate prescriptions for the patients they are dealing with.’

3. Which contract will expire the soonest? Display the name of the pharmacy and company
as well as the name of the contract supervisor.
Explanation:
Knowing which contract is expiring soonest can give the company or pharmacy time to
plan for a new contract and know who they need to connect with in order to discuss a
new contract.

4. Display the drug trade_name that is prescribed from doctors the most (by quantity)
Explanation:
This will help the drug store chain keep track of the drug that is being prescribed the
most. In turn, this will allow the company to prepare to order more of that drug to ensure
it’s always in stock.

5. Display the trade names, pharmacy IDs, and prices of the drugs that are above average in
price. Order by prices.
Explanation:
This can help the drug store chain keep track of items that are more expensive than the
average price. This query can be used to provide more clarity when making price
changes. The drug store chain can determine which of the expensive products they can
afford to lower the price on.
Conclusions:
Composing an ER diagram was incredibly helpful in that it provided more clarity and direction
on how we wanted to structure the tables. With the diagram created, it made the coding process
much easier since we had a reference. When processing the design phase, it helped us better
understand our project by creating visual tables and color-coating their keys. The visual
references make it clear which tables and keys we either have to union or join to produce the
desired query results.
Regarding the development process, this project exemplified the importance of design. Diagrams
and cardinalities provided a better logistical understanding of organizing data. It offered a real-
world situation and helped us think like consultants to meet customer demand.