Comparison Between ER Model and Relational Model
Comparison Between ER Model and Relational Model
The Entity–Relationship (ER) model is a conceptual, high-level design model, while the Relational model is a logical, implementation-level model. Each construct in the ER model is mapped to one or more constructs in the relational model.
1. Conceptual Correspondence Between ER and Relational Models
| ER Model Construct | Relational Model Construct |
|---|---|
| Entity type | Entity relation (table) |
| 1:1 or 1:N relationship type | Foreign key (or relationship relation) |
| M:N relationship type | Relationship relation with two foreign keys |
| n-ary relationship type | Relationship relation with n foreign keys |
| Simple attribute | Attribute (column) |
| Composite attribute | Set of simple component attributes |
| Multivalued attribute | Separate relation with a foreign key |
| Value set | Domain |
| Key attribute | Primary key (or secondary/unique key) |
2. Representation of Relationships
ER Model
-
Relationships are explicitly represented
-
Relationship types are shown as diamonds
-
Cardinality and participation constraints are visually clear
Relational Model
-
Relationships are not explicitly represented
-
They are implemented using:
-
Primary keys
-
Foreign keys
-
-
Two tuples are related when:
-
A foreign key value matches a primary key value
-
📌 Example:
-
EMPLOYEE.Ssn(primary key) -
WORKS_ON.Essn(foreign key)
3. Role of JOIN Operations
In the relational model, relationships are materialized using JOIN operations:
-
EQUIJOIN → when attribute names differ
-
NATURAL JOIN → when attribute names are the same
| Relationship Type | Number of JOINs Required |
|---|---|
| 1:1 or 1:N (foreign key approach) | 1 join |
| M:N relationship | 2 joins |
| n-ary relationship | n joins |
4. Example: EMPLOYEE–PROJECT–WORKS_ON
To retrieve:
Employee name, project name, and hours worked
Steps:
-
Join EMPLOYEE and WORKS_ON
-
Join the result with PROJECT
This requires two joins because WORKS_ON is an M:N relationship relation.
5. Drawback of the Relational Model
-
Foreign key–primary key relationships are not visually obvious
-
Users must know the schema well to write correct joins
-
Incorrect joins can:
-
Produce spurious (meaningless) data
-
Appear syntactically correct but be semantically wrong
-
📌 Example of a meaningless join:
This join does not represent a real relationship.
6. Key Difference Summary
| Aspect | ER Model | Relational Model |
|---|---|---|
| Level | Conceptual | Logical/Implementation |
| Relationship representation | Explicit | Implicit (via keys) |
| Visualization | Clear and intuitive | Less obvious |
| Join requirement | Not needed | Required to reconstruct relationships |
| Risk of wrong combinations | Low | High if joins are incorrect |
7. Conclusion
The ER model represents entities and relationships explicitly and intuitively, making it suitable for conceptual database design. In contrast, the relational model represents relationships implicitly through foreign keys and requires join operations to reconstruct relationships, which can make the schema harder to interpret and more error-prone if joins are not used correctly.
Comments
Post a Comment