70-100 : doctors question

[edelwater]

i dont understand why the answer should be A on the question beneath :

For myself i think answer D is much more logical, can anybody explain to me why A is the correct answer ??

tanx !



-------------------
9. You have a database that tracks doctors and patients. The system has three tables doctors, patients, and doctorspatients. How should you construct the business objects?

a. a Patients collection of Patient objects that each contain a Doctors collection of Doctor objects, and a Doctors collection of Doctor objects that each contain a Patients collection of Patients objects

b. a Patients collection of Patient objects that each contain a single PatientDoctor object, and a Doctors collection of Doctor objects that each contain a single PatientDoctor object

c. a Patients collection of Patient objects that each contain a single Doctor object, and a Doctors collection of Doctor objects that each contain a single Patient object

d. a Patients collection of Patient objects that each contain a PatientDoctors collection of PatientDoctor objects, and a Doctors collection of Doctor objects that each contain a PatientDoctors collection of PatientDoctor objects

 

[JefferyDL70]

Well, I'll take a stab at this since no one else has. I agree with the official answer completely, but I'm not sure if I can explain clearly why it's the correct response... I'll try, though.

Just think of the real world problem you're trying to solve -- forget about how the database schema was designed for now. Does a patient have a bunch of patient-doctor links, or does a patient have a bunch of doctors? Does a doctor have a bunch of doctor-patient links, or does a doctor have a bunch of patients? I think you would agree that in both situations, it's the latter. So you wouldn't naturally devise a solution like answer (d) to solve this problem... it would be like answer (a).

The database schema is a different issue. What we have here is a many-to-many relationship. But only in the database; I mean, who cares, when looking at a patient object in the software portion, that each of that patient's doctors have other patients? And actually the many-to-many relationship doesn't affect the database design (to my way of thinking) anyway... if we weren't tracking the patients that each doctor had, but only the doctors that each patient had, then it would only be a one (patient) to many (doctors) relationship, and the way to solve that in the database would still be the same: a link table of patient and doctor keys.

I think you're just concentrating too much on HOW the schema is designed, when you should only be looking at WHY.

Hmm... did I make this easier to understand, or harder? I have a feeling that I didn't explain this very well... :-I

David