Pharmaceutical Chain Service Request Database

Project Database Design and Implementation

CST363: Intro to Database Systems

May 2023

Alexandra Comaduran, Oscar Ochoa

Overview

The Pharmaceutical Chain Service (PCS) provides worldwide medical services, encompassing
the entire journey of prescription drugs from production to delivery to patients. The primary
objective of this database and implementation is to streamline the process of making
prescription drugs accessible to patients in need.

The following requirements for the system include:

● Each patient must have a unique Social Security Number (SSN) and provide their name,
age and address.
● Every patient must also be assigned a primary physician.
● Doctors must also possess a distinct SSN, as well as a name speciality and years of
experience. Any licensed physician is authorized to issue prescriptions for any patient.
● Each prescription is uniquely distinguished by an RX number and is intended for one
specific drug, one patient and is written by one doctor.
● Each prescription includes a date and quantity associated with it. If the prescription
specifies a trade name, it is specifically for a particular drug from a specific
pharmaceutical company. If the prescription is for a generic name, any drug with that
generic formula name from any pharmaceutical company can be used.
● When a prescription is dispensed, it is essential to track the pharmacy that filled it, the
data of dispensing, and if it is for a generic name, the pharmaceutical company that
supplied the drug is used for filling the prescription.
● A patient can receive multiple prescriptions from different doctors.
● Each pharmaceutical company should be identified by its name and associated phone
number.
● Prescription drugs are produced and distributed by pharmaceutical companies to retail
pharmacies.S
● Pharmaceutical companies establish long-term contracts with pharmacies. A
pharmaceutical company can enter into contracts with multiple pharmacies, and a
pharmacy can have contracts with multiple pharmaceutical companies.
● For each contract, it is necessary to document the start date, end date, and details of the
contract.
● Pharmacies designate a supervisor for each contract. Every contract has an assigned
supervisor.
● Pharmacies are required to provide their name, address, and phone number.
● Each pharmacy offers multiple drugs for sale, with individual prices for each drug.
● Each drug is assigned a “generic” name and may also have a unique trade name if
applicable.
● A drug may also be available at multiple pharmacies, and prices vary across different
pharmacies.
Requirements

As for the requirements, here is how the following table fulfills each and every one:
1. The model has a patient table with PatientSSN referring to their social security number,
PatientName referring to the patient's full name, PatientAge referring to the patient's current
age, and PatientAddress referring to the patient's current address.

2. The model has a doctor table with DoctorSSN referring to the doctor's social security number,
DoctorName referring to the doctor's name, DoctorSpecialty referring to the doctor's specialty,
and DoctorsYrsExp referring to the doctor’s years of experience in his field.

3. The model has a Pharmaceutical Comp table with PCName as the Pharmaceutical
Company's Name, and PCPhone as the pharmaceutical company's phone number.

4. The model has a drug table and is connected to the pharmaceutical company table by a one
to many relationship with the many relationship referring to the drugs and the one relationship
referring to the pharmaceutical company. The drug table has columns nameGeneric referring to
the generic name, and nameTrade referring to the trade name. The NOT NULL attribute for
nameTrade is unchecked, leaving it optional, and the unique attribute is checked.

5. There is a pharmacy table with PharmName referring to the pharmacy's name,

PharmAddress referring to the pharmacy's address and PharmPhone referring to the
pharmacy's phone number.

6. There is a one to many relationship between doctor and patient with the many relationship
referring to patient and the one relationship referring to doctor.

7. There is a many to many relationship with a bridge table of "Prescription" between patient and
doctor.

8. There is a bridge table showing there is a many to many relationship between the tables
Pharmacy and Drug and within that table there is a DrugPrice column to define the prices of
each different drug from each and every pharmacy.

9. There is a prescription table that has a primary key of RXNumber. It contains foreign keys
relating to the generic name primary key of the drug table, patientssn key of the patient table,
and the doctorssn key of the doctor table. There is a many-to-many relationship that bridges on
the prescription table from doctor and patient.

10. In the prescription table there are columns for the date and quantity as shown through the
columns PrescDate and PrescQuantity. By having the nameGeneric and nameTrade columns in
the Drug table we will be able to identify if the specific drug is from a specific pharmaceutical
company.
11. By having a table for prescriptions filled labeled as PrescriptionFill in the model, it tracks the
pharmacy name by having a foreign key relating to the pharmacyname in the pharmacy table, it
tracks the fill date by having its own column labeled DateFilled with a type of DateTime. The
PCName foreign key relates to the pharmaceutical company table's column of PCName and the
column is unchecked for NOT NULL showing this is an optional part of the table.

12. To fulfill this requirement, there is a bridge table between pharmaceutical company table and
the pharmacy table labeled contract with a many to many relationship, as many pharm.
companies can contract with many pharmacies. Also, for each contract we have the columns
StartDate to record the start date, EndDate to record the end date, and Description to record the
text of the contract.

13. Lastly, there is a ContractSupervisor column in the Contract table to fulfill this requirement.
ERD
Summary

The initial phase of this project proved to be a valuable learning experience for both of us,
considering our lack of prior database design experience. It served as beneficial practice for a
real-world application, allowing us to understand the intricacies of client communication and
effectively presenting our rationale to clients unfamiliar with database design and
implementation. Our primary concern now is establishing communication between our database
and application, as this is uncharted territory for us. While we anticipate other questions to arise
during the implementation processes, we don’t have any specific queries at the moment.
Nevertheless, we are enthusiastic about bringing our design to life.