CS 4604 Homework #1 Solution Sketches

  1. (8 points) A symmetric relationship is one such that when a is related to b through R, then b is related to a through R (in the same direction). In other words, the relationship is an inverse of itself. For this to happen it is clear that a and b should be part of the same entity set (or class), so that they are indeed eligibile be placed at either end of the relationship. So, the first condition is that the relationship should run from a set to itself.

    Another condition we can state is that the relationship be actually one-one (recall that a many-one means a "can be many" in one direction, not a "has to be many"). This is because for every example of the relationship (e.g., "a1 is related to b1"), we should be able to state the example in the other direction, and this means that the relationship is either many-many or one-one. Only a one-one relationship is a special case of a many-one relationship, and hence a many-one symmetric relationship must in fact be one-one.

    If you stated only the second condition, you get 7 points. The first would fetch you the extra point.

  2. (10 points) Here's the ODL code containing all four modifications. The changed parts are given in blue. 
    
class Ship {
       attribute string name;
       attribute integer yearLaunched;
       relationship Set<TG> assignedTo
          inverse TG::unitsOf;  // requirement (b)
       relationship Set<Ship> sisters
          inverse sisters; // requirement (c)
}

class TG {
       attribute real number;
       attribute string rankofcommander;  // this and next line
       attribute string nameofcommander;  // for requirement (a)
       relationship List<Ship> unitsOf // the "Set" is changed to "List"
          inverse Ship::assignedTo; // for requirement (d)
}
    Each of these changes will fetch 2.5 points.

  3. (12 points) Here's the ODL code. Two new classes have to be added since ODL does not allow attributes on relationships or multiway relationships. Do not forget to specify inverses of relationships! 
    
class Movie {
	attribute string title;
	attribute integer year;
	attribute integer length;
	attribute enum Film {color, blackAndWhite} filmType;
		// copied from book; this can be any type you wish
	relationship Set<Contract> supportedby
             inverse Contract::hasMovie;
}

class Star {
	attribute string name;
	attribute string address;
        relationship Set<Contract> participatesin
	     inverse Contract::participating;
}

class Studio {
	attribute string name;
	attribute string address;
	relationship Set<Contract> engagesin
	     inverse Contract::hasStudio; 
}

class Salary {
	attribute integer dollaramount;
	relationship Set<Contract> usedin
             inverse Contract::hasSalary;
}

class Contract {
	relationship Salary hasSalary
	     inverse Salary::usedin;
	relationship Studio hasStudio
	     inverse Studio::engagesin;
	relationship Movie hasMovie
	     inverse Movie::supportedby;
	relationship Star participating
	     inverse Star::participatesin;
}
    Notice that because of the push-out construction, the sole purpose of the Contract class is to engage in many-one relationships with all the other classes.

  4. (20 points) Everything except the last two sentences talk about "prescribe" as a verb and then suddenly it becomes a noun. This is a hint for "pushing out" a relationship into an entity set. Thus, prescriptions is a connecting entity set which typically will have many-one relationships to Doctor, Drug, and Patient. Due to the constraint in the last sentence, the arrows entering Drug and Patient have to be removed.

    Using prescription as a relationship will cost you 10 points. It is imperative that prescription be an entity set; consider what happens if you left it as a relationship. While such a relationship can indeed connect many drugs and many patients to a single doctor, it will be a different relationship in each case (whereas the question wants them to be linked by the same prescription). More mistakes will have additional penalties.

Return Home