CS 4250: Project Part 2
Due at midnight on Tuesday, February 23, 2021. (Documentation
- Sections 3 and 4, see below -
must be typed, not handwritten. ER diagram may be hand-written, clearly and tidily,
in ink, and photographed. Or ER diagram may be drawn using software.)
One member of the group must submit ER diagram and documentation to the CS Homework system.
- Review 1 due 2/16 (3 pts).
- Review 2 due 2/18 (3 pts).
- Reviews are mandatory. If your group does not
participate in at least one review process, and revise your ER diagram as instructed
during the review, your group will earn a ZERO on all of Part 2.
- (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.
- 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:
- 5 to 8 entity sets, and
- a similar number of relationships, and
- one example of a non-binary relationship (ternary, etc), and
- one example of specialization / generalization, and
- one example of weak entity sets, and
- (optionally) one example of a union.
Your design must satisfy the first two criteria.
Your relationships must also have a variety of multiplicities (one-to-one,
MUST be "rich" in all these goodies
we discussed in class!
The ER diagrams will satisfy at least four out of the six criteria.
Don't forget to underline key attributes, to specify integrity
constraints (cardinality and participation), 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 consider pruning them.
In a section titled "Explanations", write one or two
plain English sentences
for each entity set and each relationship, explaining what
it represents or models.
- If you use the word 'entity' to describe an entity set, it is not plain English.
If you read your description to a History major and they look confused, it is
not plain English. Plain English descriptions are written for your hypothetical
customers and marketing staff, not for your professor.
Discuss and identify any
and restrictions that your domain poses.
Identify (in plain English) at least one constraint that could not be
captured in your ER diagram. (A constraint might be a rule that specifies limits on
the valid values of an attribute, to keep that attribute's values
correct for your data domain.)
Mandatory: Send one or more members of your group
to an appointment with the instructor before at least one Review deadline, to show a
serious ER diagram draft and get feedback. There will be opportunities to sign up
for appointments in class.
If your group revises your diagram based on
the feedback and brings it back for more feedback, your group can earn
points for both Review 1 and 2.
Serious means your group attempts to completely satisfy the needs of your
chosen user group and of this assignment, on your own, before bringing
the ER diagram draft to the instructor for review.
(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!)
What to turn in: Neatly drawn 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.
Common Mistakes in Design:
- Most common mistake: Undercounting entity and relationship sets.
For example, the one weak entity set does not count as one of the standard
5 - 8 entity sets. The subset / child entity sets in a specialization heirarchy
do not (usually) count as some of the 5 - 8 entity sets. (In cases involving especially
complicated subset entity sets, that counting might be relaxed.)
In general, an aspect of your ER diagram created to satisfy criteria 2.4 or 2.5 will not
also count towards 2.1 or 2.2. Do not double-count when deciding if your ER
diagram satisfies the assignment requirements. (Bring a draft of your ER diagram
to the instructor and let the instructor help you figure out if it satisfies requirements!)
- 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.
- Giving your relationships vague names. The names "is," "has," "is-a"
and "has-a" are absolutely forbidden.
- Missing labels on edges identifying cardinality of relationship.
- Using specialization when there is no subset-superset connection between two sets.
- Forgetting that when entity set B inherits from (specializes) 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.
- "Cooking up" examples of weak sets, or of specialization.
- 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 (specializes) 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.
- 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. Is it so hard to think of 10 - 16
- Too few attributes. The attributes ARE the data the database stores.
To satisfy your user group, your database must store plenty of data your user group
would be interested in. I expect an average of at least a half-dozen attributes per entity.
- Forgetting to underline key attributes in the ER model.
- Forgetting to identify overlapping / disjoint constraints in specialization
heirarchies. Or forgetting to label predicates or defining attributes
in predicate-defined or attribute-defined specializations.
- Unfaithfulness to the user group you selected. If your user group is customers
looking to purchase refridgerators, your database should definitely store prices,
because customers want to know prices.
On the other hand, the database should not store the grade point average the
refridgerator design engineer had in college -- why would a customer care, and when
would sharing that private information with customers ever be reasonable?