CS 4250: Project Part 2


Hardcopy due at 12:30 pm on Tuesday, February 16, 2016. (Words must be typed, not handwritten. ER diagram may be hand-written, clearly and tidily.)

  1. (0 points) Before starting, make sure that you have addressed any suggestions and corrections in the feedback to your solution to Part 1 of the project. Do not proceed till you have made these changes! I will not grade assignments turned in that do not make the necessary modifications.

  2. Starting from the two-page writeup that you turned in for Part 1 of the project, design an ER diagram for your application. Your model should provide:
    1. 5 to 8 entity sets, and
    2. a similar number of relationships, and
    3. one or more examples of a constraint your ER diagram cannot capture, and
    4. one example of a multi-way relationship, and
    5. one example of inheritance, and
    6. (preferably) one example of weak entity sets.

    Your design must satisfy the first three criteria.

    Satisfying the last three criteria is optional. However, for each of the last four criteria that your design does not satisfy, you must include in your writeup a clear, convincing and compelling explanation of why you think it is "unnatural" for your application (i.e., explain why multi-way relationships, inheritance, and weak entity sets do not make sense for your application).

    Your relationships should also have a variety of multiplicities (one-to-one, one-to-many, many-to-many).

    In short, your design MUST be "rich" in all these goodies we discussed in class!

    Don't forget to underline key attributes, to specify referential integrity constraints, specify any domain-specific constraints, and to thick-border any weak sets and their connections. It is possible that you may make your design more complicated than necessary! If you have more than eight entity sets, you should probably prune them.

  3. In a section titled "Explanations", write one or two plain English sentences for each entity set and relationship, explaining what it represents or models.
  4. Discuss and identify any constraints and restrictions that your domain poses. For constraints that ER diagrams cannot model, write in plain English what these constraints are.


What to turn in: Neatly drawn hard-copy of ER design, plus accompanying explanations and discussions of constraints. Identify your group by your project title and the team members.

Required but not graded: Include one sentence per group member summarizing each group member's contribution to Project Part 2. These sentences will be required in all project parts. They are not for part of any student grades. They will be used to monitor group dynamics, and to try to intercede in troubled groups (if any) before troubles get out of hand.

VERY VERY Strongly Recommended: Send one or more members of your group to my office hours a few days before the deadline, to show me your current ER diagram draft and get fast feedback. (I have office hours 2-2:50 on Tuesday, and I hope to be in my office from 11 am to 1:30 on Monday and Wednesday. Or make an appointment. Showing me the ER diagram before the deadline is important. You will be required to have a complete and correct ER diagram to work with for Part 3. If there are any flaws in your ER diagram, you will have to both revise and correct Part 2 and complete Part 3 based on your revisions before the Part 3 deadline. So you want the flaws to be very small and easy to fix!)


Common Mistakes in Design:

  1. Unfaithfulness to the domain being modeled. I expect that you will use some real-world assumptions when doing your project. Some possible mistakes might be assuming that one person can be in two places at the same time, one team can play both basketball and football, not recognizing the multiplicity of relationships (whether it is one-one, many-one etc.), etc.
  2. Missing arrows in a many-one and/or a one-one relationship.
  3. Missing arrows from a weak set to the set(s) that provide its key attribute(s).
  4. Giving your relationships vague names. The names "is," "has," "is-a" and "has-a" are absolutely forbidden.
  5. Using inheritance when there is no "ISA" connection between two sets.
  6. Forgetting that when entity set B inherits from entity set A, B inherits everything that A has. In addition, B can define attributes of its own. Therefore, there is no need to repeat all the attributes/relationships that A has again for B.
  7. "Cooking up" examples of weak sets.
  8. "Cooking up" examples of inheritance.
  9. 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; it may have been cooked up.

  10. Forgetting to underline key attributes in the ER model.
  11. 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?


Hint for the future: After you have completed this assignment, start thinking about how you would translate your ER diagram into relations.