Address

Name PhoneNumber

N N
Phone
Name Participates Pharmacy
Number

N N
Pharmaceutical
Produces
Company

Formula CompanyName
Name StartDate EndDate Contract SSN Name Address Age SSN Name Specialty YearsExperience TradeName
Text

Contracts
with N
N Contract Patient Doctor Drug

1 sells

Has N 1 N
N
N Primary
Doctor prescribed available
SupervisorID ContractName at
N
Yes 1
has
1 patients N
1

DrugTrade Date
receives prescribes Quantity
PatientSSN Name
Contract Phone
Name ID
Supervisor Number N DoctorSSN
N PharmacyName Price
DrugTradeName

DoctorPatientRelation
Prescription
DrugSale
 ADVANCED DATABASE CONCEPTS HW-1
Priyanka Voleti
[email protected]

1) Creating ER Diagram

Key Entities:

1. Pharmaceutical Company:
○ This entity represents the companies that manufacture drugs. Each company is
identified by a unique Name (PK) and has a Phone Number.
2. Contract:
○ This entity captures the agreements made between pharmaceutical companies and
pharmacies. Each contract has a ContractName (PK), StartDate, EndDate, and
ContractText.
3. Contract Supervisor:
○ The role of this entity is to oversee contracts. Each supervisor is identified by a
SupervisorID (PK) and is linked to a ContractName (FK) that they supervise.
4. Patient:
○ Patients are represented as individuals who receive prescriptions. Each patient has
a unique SSN (PK), along with other details such as Name, Address, and Age.
5. Doctor:
○ This entity represents the medical professionals who prescribe drugs. Each doctor
is identified by their SSN (PK) and has attributes like Name, Specialty, and
Years of Experience.
6. DoctorPatientRelation:
○ This entity captures the association between doctors and patients. It stores Doctor
SSN (FK) and Patient SSN (FK), indicating which doctor is responsible for each
patient.
7. Drug:
○ Drugs are represented by this entity. Each drug is uniquely identified by a
TradeName (PK) and includes attributes like Formula and CompanyName
(FK) indicating the producing company.
8. Prescription:
○ This entity stores information about drugs prescribed to patients. Each
prescription has attributes like DoctorSSN (FK), PatientSSN (FK),
DrugTradeName (FK), Date, Quantity, and an ID (PK).
9. Pharmacy:
○ Pharmacies that sell drugs are captured by this entity. Each pharmacy is identified
by a Name (PK) and has an Address and Phone Number.
 10. DrugSale:
○ This entity captures the sale of drugs at pharmacies, identified by a composite key
consisting of PharmacyName (FK) and DrugTradeName (FK), along with the
Price at which each drug is sold.

Relationships and Cardinalities:

1. Contracts - Relationship between Pharmaceutical Company and Pharmacy:

○ From my understanding, a pharmaceutical company can have contracts with
different pharmacies, and a single pharmacy can have contracts with multiple
pharmaceutical companies. This N
relationship captures the complexity of real-world contracting.
2. Has - Relationship between Contract and Contract Supervisor:
○ Each contract must be supervised by one contract supervisor, but a single
supervisor can oversee multiple contracts. This relationship indicates that there’s
always a point of accountability for each contract.
3. Primary Doctor - Relationship between Doctor and Patient:
○ Every patient has exactly one primary doctor, but a doctor can serve as the
primary doctor for many patients. This relationship shows the typical healthcare
structure where a doctor manages multiple patients.
4. Prescribes - Relationship between Doctor and Prescription:
○ Doctors can prescribe multiple drugs to different patients, and each patient can
receive prescriptions from multiple doctors. This N
relationship highlights the dynamic nature of medical prescriptions in healthcare.
5. Receives - Relationship between Patient and Prescription:
○ Each patient can receive multiple prescriptions, and a prescription can apply to
multiple patients (in different contexts). This setup accurately represents the
many-to-many nature of prescriptions.
6. Produces - Relationship between Pharmaceutical Company and Drug:
○ A single pharmaceutical company can produce multiple drugs, but each drug is
manufactured by one company. This relationship captures the one-to-many nature
of drug production.
7. Available At - Relationship between Drug and Pharmacy:
○ Drugs can be available at multiple pharmacies, and each pharmacy can carry
multiple drugs. This N
relationship reflects how drugs are distributed across various outlets.
8. Sold by - Relationship between Pharmacy and DrugSale:
 ○ This relationship indicates that each pharmacy can sell multiple drugs, and each
drug can be sold by multiple pharmacies. It captures the N
cardinality, which is typical for sales.

2) If each drug had to be sold at a uniform price across all pharmacies, I would modify my
design by making the following changes:

1. Remove the "DrugSale" Entity:

● I would eliminate the DrugSale entity since it's no longer needed to capture different
prices at different pharmacies. This change simplifies the design because there’s now
only one price for each drug.

2. Add the "Price" Attribute to the "Drug" Entity:

● I would add a Price attribute directly to the Drug entity to indicate that each drug has a
single, uniform price across all pharmacies. By doing this, I make it clear that the pricing
information is consistent no matter where the drug is sold.

3. Adjust the Relationship Between Drug and Pharmacy:

● The many-to-many relationship between Drug and Pharmacy would remain, but without
the need for the DrugSale intermediary entity since the price is now embedded within the
Drug entity itself.

This modification accurately reflects the requirement for a uniform drug price across all
pharmacies, making the database structure cleaner and easier to manage.

3) If I needed to store multiple prescriptions for the same drug from the same doctor to the same
patient, I would modify my design as follows:

1. Add a Composite Primary Key to the "Prescription" Entity:

● I would make sure that the Prescription entity can handle multiple entries for the same
drug, doctor, and patient by adding a PrescriptionID attribute as a unique primary key.
● This way, instead of relying on the combination of DoctorSSN, PatientSSN, and
DrugTradeName as a unique identifier, I would introduce a PrescriptionID to
differentiate multiple prescriptions for the same drug to the same patient from the same
doctor.
 2. Include a Timestamp Attribute in the "Prescription" Entity:

● I would add a PrescriptionDate attribute (if not already present) to capture the date and
time when each prescription was issued. This will help track multiple prescriptions over
time and differentiate between them.

3. Modification of Relationships:

● The relationship between Doctor, Patient, and Drug through the Prescription entity
would remain, but now it would allow multiple instances of the same combination of
doctor, patient, and drug due to the unique PrescriptionID.

Final Outcome:

● The Prescription entity would now include attributes like PrescriptionID (PK),
DoctorSSN (FK), PatientSSN (FK), DrugTradeName (FK), Quantity, and
PrescriptionDate. This change lets me store multiple prescriptions for the same drug
from the same doctor to the same patient, using the unique PrescriptionID to maintain
accuracy and data integrity.