Design 1

hospital-simple

Each patient is cared for by one doctor. Each doctor cares for many patients. A test must be done on some patient. Each test is done on only one patient. A patient can have many tests, including repetitions of the same test type. The doctor who ordered a given test can be identified since the care and log relationships are both one-to-many.


Design 2

hospital-ternary

Use a ternary relationship to allow a patient to be cared for by many doctors, while still allowing identification of the doctor who ordered a given test. The arrow notation is inadequate for representing the mapping cardinality constraints properly. Instead, use two sets of written constraints for each entity set, one for each of the other two related entity sets. This design cannot represent a doctor-patient relationship without some test being involved.


Design 3

hospital-redundant

Use a binary relationship for care, and a separate ternary relationship for log. This is not redundant if a test can be ordered by a doctor who is not considered to be caring for a patient. This allows a doctor-patient relationship to be represented even if no tests are done. But in most cases the two relationships will have considerable redundancy.


Design 4

hospital-with-agg

Use aggregation so that the doctor-patient relationship can be established in the absence of any tests. Then each test is seen as related to a doctor-patient pair. This removes the redundancy of the previous design.