0

Hi everyone,

I need some help with identifying real world entities and their attributes for a hospital scenario. I have listed below the entities and attributes that I could think of. Please comment or give suggestions on how I can improve it.

EMPLOYEE ([U][B]Employee_SSN[/B][/U], Address_ID, Contact_ID,  Employee_Name, Designation, Salary)

PATIENT ([U][B]Patient_SSN[/B][/U], Address ID, Contact_ID  Patient_Name, Disease)

MEDICAL_HISTORY ([U][B]Patient_SSN[/B][/U], Treatment_ID, History)

CONTACT  ([U][B]Contact ID[/B][/U], Email, TelNo)

ADDRESS ([U][B]Address ID[/B][/U], Street, City, State, Zip and Region)

DOCTOR ([U][B]Doc_ID[/B][/U], Doc_Name, Department)

PRESCRIPTION ([U][B]Prescription_ID[/B][/U], Patient_SSN, Medication_Name, Prescription_Type, Frequency, Instruction, Expiry_Date, Stock)

WARD ([U][B]Ward ID[/B][/U], Ward_Name, Main_Treatment, Nurse_In_Charge, Number_Of_Bed)

TREATMENT ([U][B]Treatment_ID[/B][/U], Treatment_Type, Treatment_Date, Treatment_Location, Fee, Result)

PHARMACY ([U][B]Pharmacy_ID[/B][/U], Pharmacy_Name, Pharmacy_Location, Pharmacy_TelNo)

PATIENT_ADMISSION ([U][B]Patient_SSN[/B][/U], Ward_ID, Admission_Date, Discharge_Date, Admission_Reason, Employee_SSN)

I need to also identify a multi-valued attribute, a weak entity, recursive relationship, Super/ subtype entities, a ternary relationship, relationship with cardinality ratio 1:1, 1:M, N:M.

So far I have only identified a multi-valued attribute which is Pharmacy_TelNo in PHARMACY, a weak entity which is MEDICAL_HISTORY and a recursive relationship which is Nurse_In_Charge in EMPLOYEE. As for the other I have not identified them yet.

Please have a look and tell me if what I have done so far is correct.

Thank you so much

Regards.

2
Contributors
5
Replies
6
Views
6 Years
Discussion Span
Last Post by Momerath
0

Employee, patient, doctor and pharmacy all 'have an' address, so I'd just have an address ID in their tables linking to the address table.

I would have admission -> treatment be a 1:M relationship, and History be a 1:M to admission. Prescription would be Treatment -> Prescription in a 1:M.

A doctor is an employee and either could be a patient.

An N:M relationship would be patient to address. A patient might have multiple addresses (home, work, vacation home, moved, etc.) and multiple people might live at the same address.

0

Thank you Momerath for your help.

Can I link the Doctor entity to Employee entity since Doctor would be an Employee of the hospital?

DOCTOR (Doc_ID, Employee_SSN, Doc_Name, Department)

Should I remove the Doc_name attribute since the Employee_SSN would have the name attribute?

Employee, patient, doctor and pharmacy all 'have an' address, so I'd just have an address ID in their tables linking to the address table.

So there is no 1:1 relationship in this design?

I would have admission -> treatment be a 1:M relationship, and History be a 1:M to admission. Prescription would be Treatment -> Prescription in a 1:M.

A doctor is an employee and either could be a patient.

An N:M relationship would be patient to address. A patient might have multiple addresses (home, work, vacation home, moved, etc.) and multiple people might live at the same address.

0

Yes, I'd remove name since it's just duplicate data (from Doctor).

There could be several 1:1s. Doctor to treatment. Patient to Ward. Nurse in charge to ward. It depends on how you want your hospital to work.

0

Ok, if I want to have a 1:1 relationship between Nurse_In_Charge and WARD then I would need to make Nurse_In_Charge an entity and remove it from WARD, because currently Nurse_In_Charge is an attribute in WARD. Is that assumption correct?

Yes, I'd remove name since it's just duplicate data (from Doctor).

There could be several 1:1s. Doctor to treatment. Patient to Ward. Nurse in charge to ward. It depends on how you want your hospital to work.

This question has already been answered. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.