Common Mistakes in the Design of Databases

• Unfaithfulness to the domain being modeled. You are expected to use some real-world assumptions when modeling an application. Some common mistakes include stating that one person can be in two places at the same time or one team can play both basketball and football, or not recognizing the multiplicity of relationships (whether it is many-many, many-one, or one-one).
  
  
• Repeating (reusing) names for entity sets and relationships, i.e., using the same name to denote two different things.
  
  
• Missing (curved or sharp) arrows in a many-one and/or a one-one relationship.
  
  
• Forgetting to underline key attributes in E/R.
  
  
• Using inheritance when there is no ISA connection between two entity sets, i.e., `cooking up' examples of inheritance.
  
  
• Forgetting that when entity set B inherits from entity set A, B gets everything that A has, and perhaps adds attributes of its own. Thus, there is no need to repeat all the attributes which entity set A has for entity set B.
  
  
• Reasoning in the following way: ``Entity set B inherits from entity set A. Entity set A participates in a many-many relationship with entity set C, but entity set B does not have a many-many relationship to entity set C; it has no relationship to C.''
  
  This kind of reasoning is flawed. If entity set B inherits from entity set A, it inherits everything from A. Thus, you do not have the right to make exceptions to this rule. Desire to do so probably means that this is not a real example of inheritance, but rather a cooked up example.
  
  
• When converting a multiway relationship to many binary relationships using a connecting entity set, forgetting to use only many-one relationships.
  
  
• Missing arrows from a weak entity set to the set(s) which provide its key attribute(s).
  
  
• `Cooking up' examples of weak entity sets.
  
  
(the remainder are specific to ODL)


• Incompatibility between E/R and ODL designs. They say different things.
  
  
• There is no such thing as an `ODL diagram.' Only E/R has diagram(s). For ODL, you need to produce a listing of the class definitions.
  
  
• Using declarations such as attribute time today; and not defining time in ODL.
  
  
• Modeling a single number with Set<integer> instead of just an integer in ODL.
  
  
• Forgetting to specify the inverses of relationships in ODL.
  
  
• In an ODL model, note that every relationship has an inverse. Thus, you must specify inverses in all directions.
  
  
• Forgetting that ODL does not have support for multiway relationships. You must convert such relationships to multiple binary relationships.
  
  
• 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.