Question 1


  • 1A -1.0 Using arrows on operation relationship (should be many-many-many)
  • 1B -1.0 Attributes of a relationship cannot be keys
  • 1C -1.0 Missing key
  • 1D -1.0 Missing attributes (entity set or relationship)
  • 1E -1.0 Weak entity set should be double boxed
  • 1F -2.0 Used weak entity set instead of ISA relationship
  • 1G -2.0 Missing weak entity set & supporting relationship
  • 1H -1.0 Supporting relationship not double boxed
  • 1I -2.0 Using a relationship instead of an entity set
  • 1J -2.0 Missing relation/entity set
  • 1K -1.0 Improper use of weak entity set
  • 1L -1.0 Improper multiplicity on relationship
  • 1M -1.0 Extraneous relationship/entity set
  • 1N -2.0 Linked operation just to people (not to doctor and patient)
  • 1O -2.0 Made operation a supporting relationship
  • 1P -1.0 Arrows not supposed to be on ISA relationship
  • 1Q -1.0 Attributes of child entity set cannot be keys

    Most people had trouble with the multiplicity of the operation relationship. Granted, no solution would be ideal given the requirement that date and time be attributes on operation (and not its own entity set), but the best solution is to have operation as a many-many-many relationship. Having any arrows just doesn't make sense. Consider adding an arrow towards room. This says that a given doctor and patient can only have one operation in one room. An arrow towards doctor would mean that a given room and patient uniquely determine a doctor in the operation relationship - also nonsensical. There was also a tendency to make the date & time attribute of the operation be keys, however you can't have keys on attributes of a relation. If you wanted to have these be unique per operation, DateTime would need to be its own entity set and this was prohibited by the problem. Given all these considerations grading was fairly lenient.