ER Design Issues – Explained with Examples
This document explains important ER Design Issues as mentioned in the syllabus and reference PDF, with
simple examples suitable for exams, viva, and practical understanding.
1. Entity Set vs Attribute
Sometimes it is confusing whether a property should be modeled as an attribute or as a separate entity set. If
the property has its own attributes or participates in relationships, it should be modeled as an entity.
Example: PhoneNumber can be an attribute of Employee. But if phone number has type, provider, and validity,
it should be a separate entity.
2. Entity Set vs Relationship Set
Sometimes an object can be represented either as an entity set or as a relationship set. If the object
represents an action or association, it is better modeled as a relationship.
Example: Enrollment between Student and Course is better represented as a relationship rather than an
entity.
3. Binary vs N-ary Relationship Sets
Most relationships in ER models are binary. Although n-ary relationships exist, they can often be replaced by
multiple binary relationships for simplicity.
Example: A ternary relationship among Supplier, Part, and Project can be converted into a new entity and
three binary relationships.
4. Placement of Relationship Attributes
The placement of relationship attributes depends on the cardinality of the relationship.
One-to-Many: Relationship attributes can be placed on the many-side entity. One-to-One: Relationship
attributes can be placed on either entity. Many-to-Many: Relationship attributes must be placed in a separate
entity created for the relationship.
5. ER Design Methodology
ER Design Methodology provides guidelines for designing an effective ER diagram.
Steps: 1. Identify entity sets 2. Identify relationship sets 3. Identify attributes 4. Define cardinality and
constraints 5. Identify keys and discriminators 6. Draw the ER diagram
Conclusion
Understanding ER design issues helps in creating clear, efficient, and correct database designs. These
concepts are essential for database normalization, implementation, and real-world database modeling.