II

The Entity-Relationship Model

Conceptual Modeling, ER Diagrams, and Extended ER Features

100% Exam Frequency

ER/EER diagram questions appear in every exam. The most common scenario is Hospital Management System. Be prepared to draw complete diagrams and map them to relational schema.

1. Introduction to ER Model

What is the ER Model?

The Entity-Relationship (ER) Model is a high-level conceptual data model used to describe the structure of a database. It models an enterprise as a collection of entities and relationships among entities.

The ER model was developed by Peter Chen in 1976 and is widely used for database design. The main components are:

πŸ“¦

Entities

Objects in the real world that are distinguishable from other objects. Examples: person, company, event, place.

πŸ”—

Relationships

Associations among entities. Shows how entities are related to each other.

πŸ“

Attributes

Properties that describe entities. Examples: name, address, salary.

2. Entities and Entity Sets

Entity

An entity is an object that exists in the real world and is distinguishable from other objects. It can be a physical object (person, car) or a conceptual object (course, job).

Entity Set

An entity set is a set of entities of the same type that share the same properties (attributes). Examples: set of all students, set of all courses.

πŸ’ͺ

Strong Entity

An entity that has a primary key and can exist independently. It does not depend on any other entity for its identification.

EMPLOYEE

Represented by a single rectangle

πŸ”—

Weak Entity

An entity that cannot be uniquely identified by its own attributes alone. It depends on a "strong entity" (owner) for its existence.

DEPENDENT

Represented by a double rectangle

Example: Entity Sets

  • EMPLOYEE entity set: All employees in a company
  • DEPARTMENT entity set: All departments in the organization
  • PROJECT entity set: All projects being worked on
  • DEPENDENT entity set: Dependents of employees (weak entity)

3. Attributes

What are Attributes?

Attributes are descriptive properties possessed by all members of an entity set. Each attribute has a domain (set of permitted values).

Types of Attributes

Name
Simple (Atomic) Attribute

Cannot be divided into smaller parts. E.g., Age, SSN

Address
Composite Attribute

Can be divided into smaller sub-parts. E.g., Address β†’ Street, City, Zip

Phone
Multivalued Attribute

Can have multiple values. E.g., Phone numbers, Email addresses

Age
Derived Attribute

Value can be computed from other attributes. E.g., Age from DOB

ID
Key Attribute

Uniquely identifies an entity. Shown with underline.

Optional
Stored Attribute

Directly stored in database, not computed.

Example: Instructor Entity with Attributes

INSTRUCTOR ID name first_name last_name salary phone dept_name age Legend: Underline = Key | Double border = Multivalued | Dashed = Derived

4. Keys

πŸ”‘

Super Key

A set of one or more attributes whose values uniquely determine each entity. May contain extra attributes.

For INSTRUCTOR: {ID}, {ID, name}, {ID, salary} are all super keys

🎯

Candidate Key

A minimal super key - no proper subset of it is a super key. Also called a "minimal super key".

For CAR: {State, Reg#} and {SerialNo} are candidate keys

⭐

Primary Key

One candidate key chosen by the database designer to uniquely identify entities. Shown with underline in ER diagrams.

πŸ”—

Partial Key (Discriminator)

An attribute that partially identifies a weak entity when combined with the owner entity's primary key.

5. Relationships and Relationship Sets

Relationship

A relationship is an association among several entities. It shows how entities are related to each other.

Relationship Set

A relationship set is a set of relationships of the same type. It is a mathematical relation among entities.

Example

44553 (Peltier) advisor 22222 (Einstein)

Here, advisor is a relationship between a student entity and an instructor entity.

Degree of Relationship

Unary (Recursive)

Degree 1 - Involves only one entity set. Example: Employee manages Employee

Binary

Degree 2 - Involves two entity sets. Most common type. Example: Student takes Course

Ternary

Degree 3 - Involves three entity sets. Example: Student works on Project under Instructor

Relationship Attributes

Relationships can also have attributes. For example, the advisor relationship might have a date attribute indicating when the student started with the advisor.

6. Cardinality Constraints (Mapping Cardinality)

Mapping Cardinality

Expresses the number of entities to which another entity can be associated via a relationship. Most useful for binary relationships.

1️⃣

One-to-One (1:1)

An entity in A is associated with at most one entity in B, and vice versa.

Example: One department has one manager, and one manager manages only one department.

DEPT MANAGER 1 1
1οΈβƒ£βž‘οΈβ™ΎοΈ

One-to-Many (1:N)

An entity in A is associated with many entities in B, but an entity in B is associated with at most one entity in A.

Example: One department has many employees, but each employee belongs to only one department.

DEPT EMPLOYEE 1 N
♾️⬅️1️⃣

Many-to-One (N:1)

Many entities in A are associated with one entity in B. Reverse of one-to-many.

Example: Many students have one advisor.

♾️↔️♾️

Many-to-Many (M:N)

An entity in A can be associated with many entities in B and vice versa.

Example: Students enroll in many courses, and each course has many students.

STUDENT COURSE M N

7. Participation Constraints

═══

Total Participation

Every entity in the entity set participates in at least one relationship. Represented by a double line.

Example: Every section must have an associated course (total participation of section in sec_course).

───

Partial Participation

Some entities may not participate in any relationship. Represented by a single line.

Example: Not every instructor needs to be an advisor (partial participation of instructor in advisor).

Participation Constraint Example

COURSE has SECTION 1 N (Total)

Double line indicates total participation - every section must be associated with a course

8. Weak Entity Sets

Weak Entity

An entity set that does not have a primary key is called a weak entity set. Its existence depends on a strong entity (also called the identifying/owner entity).

Characteristics

  • No primary key of its own
  • Depends on a strong (owner) entity
  • Has a partial key (discriminator)
  • Represented by double rectangle
  • Connected via identifying relationship (double diamond)
  • Always has total participation in identifying relationship

Example: DEPENDENT

  • Owner entity: EMPLOYEE
  • Weak entity: DEPENDENT
  • Partial key: Dependent_name
  • Primary key: (ESSN, Dependent_name)
  • A dependent cannot exist without an employee

Weak Entity Representation

EMPLOYEE has DEPENDENT Name Double rectangle = Weak entity | Double diamond = Identifying relationship

9. Extended ER (EER) Features

Exam Tip

EER features like Specialization and Generalization are explicitly requested in recent exams. Make sure to understand the constraints (disjoint/overlapping, total/partial).

The Extended ER model adds additional semantic concepts to the basic ER model:

  • Specialization - Top-down process of defining subclasses
  • Generalization - Bottom-up process of combining entity types
  • Aggregation - Treating relationship as higher-level entity
  • Category (Union Type) - Subset of union of entity types

10. Specialization

Specialization (Top-Down)

The process of defining a set of subclasses of an entity type based on some distinguishing characteristic. Subclasses inherit all attributes from the superclass.

Example

EMPLOYEE can be specialized into:

  • ENGINEER (with attribute: Eng_type)
  • SECRETARY (with attribute: Typing_speed)
  • TECHNICIAN (with attribute: Tech_grade)

Each subclass inherits Emp_name, Address, Salary from EMPLOYEE.

Constraints on Specialization

Disjointness Constraint

  • Disjoint (d): An entity can belong to only ONE subclass
  • Overlapping (o): An entity can belong to MULTIPLE subclasses

Disjoint: Employee is either Engineer OR Secretary (not both)

Overlapping: Person can be both Student AND Employee

Completeness Constraint

  • Total (double line): Every superclass entity MUST belong to at least one subclass
  • Partial (single line): Some superclass entities may NOT belong to any subclass

Total: Every person must be either Student or Employee

Partial: Some employees may not be engineers, secretaries, or technicians

Specialization with ISA Triangle

EMPLOYEE ISA d ENGINEER SECRETARY TECHNICIAN

'd' in triangle indicates disjoint constraint

11. Generalization

Generalization (Bottom-Up)

The process of combining multiple entity types that share common features into a higher-level superclass. It's the reverse of specialization.

Example

CAR and TRUCK can be generalized into VEHICLE:

  • Common attributes: Vehicle_no, Average_kilometer, No_of_wheels
  • CAR-specific: No_of_doors
  • TRUCK-specific: Capacity

Specialization vs Generalization

Both are inverses of each other and are represented the same way in ER diagrams using the ISA triangle. The difference is in the design approach:

  • Specialization: Start with general entity β†’ define specific subclasses
  • Generalization: Start with specific entities β†’ abstract common features into superclass

12. Aggregation

Aggregation

A technique that allows treating a relationship as an abstract entity. It's used when we need to express a relationship between a relationship and an entity.

Example: Project Guide Evaluation

Consider: Students work on projects under the guidance of instructors (proj_guide relationship). Now we want to record evaluations of students by guides.

  • We can't directly create a relationship between a relationship (proj_guide) and an entity (evaluation)
  • Solution: Aggregate proj_guide into an abstract entity, then create relationship with evaluation

Aggregation Representation

AGGREGATION INSTRUCTOR proj_guide STUDENT PROJECT eval_for EVALUATION

13. ER to Relational Mapping

Exam Tip

Questions often ask to "Draw an ER diagram AND Map it to Relational Model". Learn the mapping algorithm step by step.

Mapping Algorithm

1

Strong Entity Mapping

Create a relation for each strong entity. Include all simple attributes. Primary key of entity becomes primary key of relation.

EMPLOYEE(SSN, Fname, Lname, Salary)
2

Weak Entity Mapping

Create relation with all attributes. Include owner's primary key as foreign key. Primary key = Owner's PK + Partial key.

DEPENDENT(ESSN, Dependent_name, Relationship)
3

Binary 1:1 Relationship Mapping

Add foreign key to one of the entities (preferably the one with total participation). Include relationship attributes.

DEPARTMENT(Dnumber, Dname, Mgr_ssn, Mgr_start_date)
4

Binary 1:N Relationship Mapping

Add the primary key of the "one" side as foreign key to the "many" side relation.

EMPLOYEE(SSN, Fname, Lname, DNO)
5

Binary M:N Relationship Mapping

Create a new relation with primary keys of both entities as foreign keys. Their combination forms the primary key. Include relationship attributes.

WORKS_ON(ESSN, PNO, Hours)
6

Multivalued Attribute Mapping

Create a new relation containing the attribute and the primary key of the parent entity as foreign key.

DEPT_LOCATIONS(Dnumber, Dlocation)
7

N-ary Relationship Mapping

Create a new relation with primary keys of all participating entities as foreign keys, plus relationship attributes.

SUPPLY(Sname, Partno, Projname, Quantity)
8

Specialization/Generalization Mapping

Option A: Create relation for superclass and each subclass (subclass has superclass PK as FK)
Option B: Create relations only for subclasses with all inherited + own attributes

14. ER Diagram Examples

Hospital Management System

This is the most frequently asked scenario. Key entities and relationships:

Entities

  • PATIENT: Patient_ID (PK), Name, DOB, Address, Phone
  • DOCTOR: Doctor_ID (PK), Name, Specialization, Phone
  • DEPARTMENT: Dept_ID (PK), Dept_Name, Location
  • ROOM: Room_No (PK), Room_Type, Charges
  • NURSE: Nurse_ID (PK), Name, Qualification
  • TREATMENT: (Weak entity) Treatment_Date, Description

Relationships

  • admits (Patient - Room): M:1
  • treats (Doctor - Patient): M:N with Treatment as relationship entity
  • works_in (Doctor - Department): M:1
  • assigned_to (Nurse - Department): M:1
  • attends (Nurse - Patient): M:N

Specialization

PATIENT can be specialized into:

  • INPATIENT: Admission_Date, Discharge_Date, Room_No
  • OUTPATIENT: Visit_Date, Time

Library Management System

Entities

  • BOOK: ISBN (PK), Title, Author, Publisher, Year
  • MEMBER: Member_ID (PK), Name, Address, Phone
  • LIBRARIAN: Lib_ID (PK), Name, Contact
  • COPY: (Weak) Copy_No, Status

Relationships

  • borrows (Member - Copy): M:N with Date, Due_Date
  • has (Book - Copy): 1:N (identifying)
  • manages (Librarian - Book): M:N

Company Database

Entities

  • EMPLOYEE: SSN (PK), Name, Address, Salary
  • DEPARTMENT: Dnumber (PK), Dname, Locations (multivalued)
  • PROJECT: Pnumber (PK), Pname, Location
  • DEPENDENT: (Weak) Name, Relationship

Relationships

  • works_for (Employee - Department): M:1
  • manages (Employee - Department): 1:1
  • works_on (Employee - Project): M:N with Hours
  • controls (Department - Project): 1:N
  • supervision (Employee - Employee): 1:N
  • has_dependents (Employee - Dependent): 1:N (identifying)

15. Practice Questions

Draw an Extended E-R diagram for Hospital Management System and Map it to Relational Model. [10 marks]

β–Ό

Entities:

  • PATIENT (Patient_ID, Name, DOB, Address, Phone) - Strong
  • DOCTOR (Doctor_ID, Name, Specialization, Phone) - Strong
  • DEPARTMENT (Dept_ID, Name, Location) - Strong
  • NURSE (Nurse_ID, Name, Qualification) - Strong
  • ROOM (Room_No, Type, Charges) - Strong

Relationships:

  • treats (Doctor-Patient): M:N with Date, Prescription
  • admits (Patient-Room): M:1 with Admission_date
  • works_in (Doctor-Department): M:1
  • assigned_to (Nurse-Department): M:1

EER Features - Specialization:

PATIENT specialized into INPATIENT and OUTPATIENT (disjoint, total)

Relational Schema:

PATIENT(Patient_ID, Name, DOB, Address, Phone, Type)
DOCTOR(Doctor_ID, Name, Specialization, Phone, Dept_ID)
DEPARTMENT(Dept_ID, Name, Location)
NURSE(Nurse_ID, Name, Qualification, Dept_ID)
ROOM(Room_No, Type, Charges)
TREATMENT(Doctor_ID, Patient_ID, Date, Prescription)
ADMISSION(Patient_ID, Room_No, Admission_date)

Describe weak entity. Provide an example of weak entity and strong entity. [5 marks]

β–Ό

Weak Entity:

  • An entity that cannot be uniquely identified by its own attributes alone
  • Depends on a strong (owner) entity for its existence
  • Has a partial key (discriminator) that partially identifies it
  • Primary key = Owner's PK + Partial key
  • Represented by double rectangle in ER diagram
  • Connected via identifying relationship (double diamond)

Example:

  • Strong Entity: EMPLOYEE with attributes SSN (PK), Name, Address
  • Weak Entity: DEPENDENT with partial key Dependent_name, Relationship
  • DEPENDENT cannot exist without EMPLOYEE
  • Primary key of DEPENDENT: (ESSN, Dependent_name)

Discuss Generalization, Specialization, and Aggregation with suitable examples. [10 marks]

β–Ό

1. Specialization (Top-Down):

  • Process of defining subclasses from a superclass
  • Based on distinguishing characteristics
  • Subclasses inherit attributes from superclass
  • Represented by ISA triangle

Example: EMPLOYEE β†’ ENGINEER, SECRETARY, TECHNICIAN

Constraints:

  • Disjoint (d): Entity belongs to only one subclass
  • Overlapping (o): Entity can belong to multiple subclasses
  • Total: Every superclass entity must be in some subclass
  • Partial: Some entities may not belong to any subclass

2. Generalization (Bottom-Up):

  • Process of combining entity types into superclass
  • Identifies common features among entities
  • Reverse of specialization

Example: CAR + TRUCK β†’ VEHICLE (common: Vehicle_no, Wheels)

3. Aggregation:

  • Treats a relationship as a higher-level entity
  • Used when relationship participates in another relationship
  • Eliminates redundancy

Example: proj_guide relationship (Student-Project-Instructor) aggregated to relate with EVALUATION entity

Explain ER to Relational Mapping Algorithm. [5 marks]

β–Ό

Step 1 - Strong Entity: Create relation with all simple attributes. Entity PK β†’ Relation PK.

Step 2 - Weak Entity: Create relation with all attributes + owner's PK as FK. PK = Owner's PK + Partial key.

Step 3 - Binary 1:1: Add FK to one relation (preferably total participation side).

Step 4 - Binary 1:N: Add PK of "one" side as FK to "many" side.

Step 5 - Binary M:N: Create new relation with both PKs as FKs. Composite PK from both.

Step 6 - Multivalued: Create new relation with attribute + parent's PK as FK.

Step 7 - N-ary: Create relation with all participating entity PKs as FKs.

Step 8 - Specialization: Option A (tables for super + sub) or Option B (only sub with inherited attributes).