Entity-Relationship (ER) Model: Components, Symbols, and Attributes

What is the Entity-Relationship (ER) Model? (In Simple Words)

Introduced by Peter Chen in 1976, the Entity-Relationship (ER) Model is a high-level conceptual data model used to visually plan and design a database before writing actual SQL tables.

Think of an ER diagram as the architectural blueprint of a house. Just as an architect draws bedrooms, doors, and plumbing on paper before masons lay bricks, a database designer draws entities, attributes, and relationships on paper before creating physical database tables.

1. Core Components of the ER Model

The ER model is built upon three foundational building blocks:

2. Standard ER Modeling Symbols (Chen’s Notation)

In university examinations (DAVV BCA), students must draw ER diagrams using standard geometric shapes:

3. Types of Entities: Strong vs. Weak Entity

Real-World Example of a Weak Entity:

• In a company database, EMPLOYEE is a Strong Entity with primary key Emp_ID.
• An employee’s children or spouse are stored in entity set DEPENDENT.
• If an employee leaves the company, their family records have no reason to exist.
• Therefore, DEPENDENT is a Weak Entity connected to EMPLOYEE via an Identifying Relationship HAS_DEPENDENT (double diamond).
• Its partial discriminator is Dependent_Name (underlined with a dotted line).

4. Types of Attributes

Attributes characterize an entity. They are classified into five major categories:

1. Simple vs. Composite Attributes:
   • Simple (Atomic): Cannot be divided further (e.g., Gender, Roll_No).
   • Composite: Can be broken down into sub-components (e.g., Full_Name can be split into First_Name, Middle_Name, Last_Name; Address splits into Street, City, State, Pincode).
2. Single-Valued vs. Multi-Valued Attributes:
   • Single-Valued: Has at most one value per entity instance (e.g., Aadhar_Number, Date_of_Birth).
   • Multi-Valued: Can store multiple values for the same entity instance (e.g., a person having three Mobile_Numbers, or a developer with multiple Programming_Skills). Represented by a double ellipse.
3. Stored vs. Derived Attributes:
   • Stored: Stored permanently in the database table (e.g., Date_of_Birth).
   • Derived: Computed dynamically on demand (e.g., Age = Current_Date - Date_of_Birth). Storing Age directly is bad practice because it changes every year! Represented by a dashed ellipse.
4. Key Attribute: Uniquely identifies each record (e.g., Student_ID). Represented by an underlined text inside an ellipse.

5. Relationship Types, Degree, and Cardinality Ratios

A Relationship is an association among two or more entities.

A. Degree of a Relationship

The number of participating entity sets:

• Unary (Recursive): Degree 1. An entity relates to itself (e.g., an EMPLOYEE manages other EMPLOYEEs).
• Binary: Degree 2. Association between two entity sets (e.g., STUDENT enrolls in COURSE). Most common in real life.
• Ternary: Degree 3. Association between three entity sets simultaneously (e.g., DOCTOR prescribes MEDICINE to PATIENT).

B. Cardinality Ratios (Mapping Cardinality) for Binary Relationships

Specifies the maximum number of entity instances that can be associated with another entity:

1. One-to-One (1:1):
   • An entity in A is associated with at most one entity in B, and vice-versa.
   • Example: One CITIZEN possesses exactly one PASSPORT.
2. One-to-Many (1:N):
   • An entity in A can relate to multiple entities in B, but an entity in B relates to at most one entity in A.
   • Example: One DEPARTMENT employs many PROFESSORs, but each professor belongs to only one department.
3. Many-to-One (N:1):
   • Multiple entities in A map to a single entity in B.
   • Example: Many STUDENTs belong to one COLLEGE.
4. Many-to-Many (M:N):
   • An entity in A can relate to multiple entities in B, and an entity in B can relate to multiple entities in A.
   • Example: A STUDENT can enroll in multiple COURSEs, and a COURSE has multiple STUDENTs enrolled.

C. Participation Constraints (Total vs. Partial)

• Total Participation (Existence Dependency): Every single entity in the set must participate in the relationship. Drawn using a double line.
  (e.g., Every STUDENT must be enrolled in at least one COURSE).
• Partial Participation: Some entities in the set may not participate. Drawn using a single line.
  (e.g., Not every FACULTY member is a HEAD_OF_DEPARTMENT).

💡 DAVV Exam Preparation Tips

5-Mark Question: “Differentiate between Strong Entity and Weak Entity. Give a suitable diagrammatic example.”

• Explain the difference in primary key existence, independent existence, and diagram symbols (single vs double rectangle).
• Draw the EMPLOYEE (strong) —<> (double diamond) — DEPENDENT (weak) example.

10-Mark Question: “Explain the components of the ER Model. Describe all types of attributes with examples. Explain mapping cardinalities (1:1, 1:N, M:N) and draw their standard symbols.”

• List Chen’s notation symbols in a neat table.
• Detail Simple vs Composite, Single-valued vs Multi-valued, and Stored vs Derived attributes.
• Clearly illustrate all four cardinality ratios with arrows and real-life examples.