CS 4604 Course Project: Step 2

1. (0 points) Before starting, make sure that you have addressed any suggestive corrections in our feedback to your Step 1. Do not proceed till you have made those corrections! Assignments turned in that do not address such modifications will *not* be evaluated.
   
   
2. (50 points) Go back to the 2-page writeup that you turned in Step 1. Design an E/R diagram for your application. Your application should provide *at least* (i) 4-5 entity sets, (ii) a similar number of relationships, (iii) one example of inheritance and (iv) (preferably) one example of weak entity sets. (i) and (ii) are a must but if it is too difficult to do (iii) and (iv), don't worry about them. But do state in your response, why you think it is too "unnatural" for your application to think of inheritance/weak sets. So, your example of inheritance should not be a "cooked-up" one, just to satisfy the requirements. Also, your relationships should provide a variety of possiblities: many-many, many-one, one-one etc. Your attributes should also come from a mix of backgrounds (strings, composite structures (like addresses, dates), integers, floats etc.) In short, your design should be "rich" in all these goodies! Don't forget to underline key attributes, include arrowheads, specify any domain-specific constraints or double-border any weak sets and their connections. You will not lose points if you do not have inheritance or weak entity sets, so please do not cook these up!
   
   Strange, though as it might seem, it is possible that you overcomplicate your design! If you have more than 6 entity sets, we will ask you to prune them, so do not try to be over-ambitious. The reason is that the future steps will get much much more complicated after this stage.
   
   
3. (50 points) Likewise, specify an ODL schema for your application. Be sure to include keys, inverses of relationships and such. Make sure both the ODL and E/R designs provide the same functionality!
   
   

1. Unfaithfulness to the domain being modeled. While some of these can be debated, it is expected that you use some real-world assumptions when doing your project. Some of the common mistakes last semester were assuming that one person can be in two places at the same time, one team can play both basketball and football, not recognizing the multipicity of relationships (whether it is one-one, many-one etc.), modeling a single number by a Set<integer> (why on earth?) instead of just by an integer ...
   
   
2. Missing arrows in a many-one and/or a one-one relationship.
   
   
3. Using lines such as "attribute time today;" and not defining time!
   
   
4. Missing arrows from a weak set to the set(s) that provide its key attribute(s).
   
   
5. Using inheritance when there is no "ISA" connection between two sets.
   
   
6. Forgetting that when set B inherits from set A, B gets *Everything* that A has, plus maybe adds some more attributes of its own. So, there is no need to repeat all the attributes/relationships that set A has again for B.
   
   
7. Forgetting to underline key attributes in E/R and/or specifying keys in ODL. Note that every relationship has an inverse, so you have to specify them in all directions!
   
   
8. Repeating (reusing) names for different entity sets or for different relationships within the same entity set, i.e., using the same name to denote two different things. Come on, is it so hard to think of different names?
   
   
9. Forgetting that ODL does not allow multiway relationships. You need to replace it by a connecting entity set!
   
   
10. When converting a multiway relationship to many two-way relationships using a connecting entity set, forgetting to introduce many-one relationships!
    
    
11. Incompatibility between E/R and ODL designs. They say different things!
    
    
12. Forgetting to specify the inverses of relationships in ODL.
    
    
13. "Cooking up" examples of weak sets.
    
    
14. "Cooking up" examples of inheritance.
    
    
15. Reasoning in the following way:
    
    "Set B inherits from Set A. Set A participates in a many-many relationship with Set C. *But* Set B does not have a many-many relationship to Set C, it has no relationship to C."
    
    This kind of reasoning is flawed. If Set B inherits from Set A, it gets everything from A, so you do not have the right to make exceptions to this rule. This probably means that this is not a real example of inheritance; you just cooked it up.
    
    
16. There is no such thing as an "ODL Diagram". Only E/R has diagram(s). For ODL, you need to enter a listing of the class definitions.
    
    
17. Carelessness in defining weak classes in ODL. You should either opt for the "no weak classes, we will use the OID" principle or make the key to contain the identifying relationship for the weak class. Thus, you do not need to "take over" the attributes from the "strong class" and place them with the weak class and/or specify these attributes in the key for the weak class.