13 - ER-to-Relational Mapping
1937 words
10 min read
Visual companion
Python
Type and operator map
Python Week 1: the first filter for runtime behavior
View
Revision summary
What this note is really saying
Short form
# 13 - ER-to-Relational Mapping ## 🎯 Learning Objectives After reading this topic, you will be able to: - Convert an ER diagram into a set of relational tables - Determine the minimum number of tables needed - Handle weak entities, multi-valued attributes, and specialization - Map relationships of various cardinali...

13 - ER-to-Relational Mapping
🎯 Learning Objectives
After reading this topic, you will be able to:
- Convert an ER diagram into a set of relational tables
- Determine the minimum number of tables needed
- Handle weak entities, multi-valued attributes, and specialization
- Map relationships of various cardinalities correctly
📋 Prerequisites
- 12 - ER Model — Entity sets, attributes, relationships, cardinality
- 04 - SQL DDL — CREATE TABLE, PRIMARY KEY, FOREIGN KEY
📖 Core Content
13.1 Intuition: From Blueprint to Building
You've designed an ER diagram — the blueprint of your database. Now you need to build it by creating actual tables. This is ER-to-relational mapping.
Each ER construct maps to a specific relational pattern:
- Entity set → Table
- Attribute → Column
- Relationship → Foreign key or junction table
- Key → Primary key constraint
Why This Matters: ER-to-relational mapping is a core skill tested heavily in exams (~3% of all questions). After this, you can go from problem description → ER diagram → SQL tables.
13.2 Mapping Steps (Overview)
(Diagram)
13.3 Step 1: Strong Entity Sets
Each strong entity set becomes a table with the entity's attributes as columns.
ER:
instructor(ID, name, dept_name, salary)
Relational:sqlCREATE TABLE instructor ( ID VARCHAR(5) PRIMARY KEY, name VARCHAR(20) NOT NULL, dept_name VARCHAR(20), salary NUMERIC(8,2) );
The primary key of the table = the primary key of the entity set.
13.4 Step 2: Weak Entity Sets
Each weak entity set becomes a table. The table includes:
- All attributes of the weak entity
- The primary key of the identifying strong entity set (as a foreign key)
Primary key = discriminator + identifying strong entity's primary key.
ER:
Payment(payment_number, amount)depends onLoan(loan_number)Relational:
sqlCREATE TABLE payment ( payment_number NUMERIC(3,0), loan_number VARCHAR(5), amount NUMERIC(10,2), PRIMARY KEY (payment_number, loan_number), FOREIGN KEY (loan_number) REFERENCES loan(loan_number) );
13.5 Step 3: 1:1 Relationships
Three approaches, from best to worst:
Approach A: Merge into one table (preferred if both are total participation)
If both entities must participate (total participation on both sides):
ER:
Team 1:1 Captain (every team has a captain, every player captains exactly one team)
Result: One table is sufficient:sqlCREATE TABLE team_captain ( team_code VARCHAR(5) PRIMARY KEY, team_name VARCHAR(20), player_num NUMERIC(3,0), player_name VARCHAR(20) );
Approach B: Foreign key in either table (choose one side)
Add the primary key of one entity as a foreign key in the other:
sql-- Option 1: FK in student table (most common) CREATE TABLE student ( ID VARCHAR(5) PRIMARY KEY, name VARCHAR(20), advisor_ID VARCHAR(5), -- FK to instructor FOREIGN KEY (advisor_ID) REFERENCES instructor(ID) ); -- Option 2: FK in instructor table CREATE TABLE instructor ( ID VARCHAR(5) PRIMARY KEY, name VARCHAR(20), advisee_ID VARCHAR(5), -- FK to student FOREIGN KEY (advisee_ID) REFERENCES student(ID) );
Choose the option that minimizes NULLs (put FK on the partial participation side).
13.6 Step 4: 1:N (or N:1) Relationships
Add the primary key of the "1" side as a foreign key in the "N" side table.
ER:
Department 1 → N Instructor (one department has many instructors)sqlCREATE TABLE instructor ( ID VARCHAR(5) PRIMARY KEY, name VARCHAR(20), dept_name VARCHAR(20), salary NUMERIC(8,2), FOREIGN KEY (dept_name) REFERENCES department(dept_name) );
The
dept_name FK in instructor links each instructor to their department.Rule: Always put the FK on the "many" side table.
13.7 Step 5: M:N Relationships
Create a separate table for the relationship containing:
- Primary keys of both entity sets (as foreign keys)
- Relationship attributes (if any)
ER:
StudentM — NCoursewith attributegrade
sqlCREATE TABLE takes ( ID VARCHAR(5), course_id VARCHAR(8), semester VARCHAR(6), year NUMERIC(4,0), grade VARCHAR(2), PRIMARY KEY (ID, course_id, semester, year), FOREIGN KEY (ID) REFERENCES student(ID), FOREIGN KEY (course_id) REFERENCES course(course_id) );
Primary key = combination of both foreign keys (plus any relationship attributes needed for uniqueness).
13.8 Step 6: Multi-valued Attributes
Create a separate table for the multi-valued attribute.
ER: Student has multiple
phone_numberssqlCREATE TABLE student_phone ( ID VARCHAR(5), phone_number VARCHAR(15), PRIMARY KEY (ID, phone_number), FOREIGN KEY (ID) REFERENCES student(ID) );
13.9 Step 7: Specialization/Generalization
Two strategies:
Approach A: One table per entity (with parent's key)
sqlCREATE TABLE employee ( ID VARCHAR(5) PRIMARY KEY, name VARCHAR(20), salary NUMERIC(8,2) ); CREATE TABLE secretary ( ID VARCHAR(5) PRIMARY KEY, typing_speed NUMERIC(4,0), FOREIGN KEY (ID) REFERENCES employee(ID) ); CREATE TABLE engineer ( ID VARCHAR(5) PRIMARY KEY, degree VARCHAR(20), FOREIGN KEY (ID) REFERENCES employee(ID) );
Approach B: Single table (for disjoint specialization)
sqlCREATE TABLE employee ( ID VARCHAR(5) PRIMARY KEY, name VARCHAR(20), salary NUMERIC(8,2), employee_type VARCHAR(10) CHECK (type IN ('Secretary', 'Engineer')), typing_speed NUMERIC(4,0), -- NULL for engineers degree VARCHAR(20) -- NULL for secretaries );
| Strategy | Pros | Cons |
|---|---|---|
| Separate tables | No NULLs, normalized | Need joins |
| Single table | No joins, fast | Many NULLs |
13.10 Worked Examples
Example 1: Complete Mapping
Problem Description: A university has instructors who teach courses. Each instructor belongs to one department. A course can have at most one instructor. An instructor can teach many courses.
ER Diagram:
- Entities:
instructor(ID, name),department(dept_name, building),course(course_id, title) - Relationships:
belongs_to(instructor → department, N:1),teaches(instructor → course, 1:N) Mapping:
sql-- Strong entities CREATE TABLE department ( dept_name VARCHAR(20) PRIMARY KEY, building VARCHAR(15) ); CREATE TABLE instructor ( ID VARCHAR(5) PRIMARY KEY, name VARCHAR(20) NOT NULL, dept_name VARCHAR(20), FOREIGN KEY (dept_name) REFERENCES department(dept_name) ); CREATE TABLE course ( course_id VARCHAR(8) PRIMARY KEY, title VARCHAR(50), instructor_id VARCHAR(5), -- FK for 1:N relationship FOREIGN KEY (instructor_id) REFERENCES instructor(ID) );
Example 2: Minimum Tables
Question: How many tables are needed for a 1:1 relationship with total participation on both sides?
Answer: 1 table.
If
Team and Captain have a 1:1 relationship and every team has a captain (and every captain captains a team), they can be merged:sqlCREATE TABLE team_captain ( team_code VARCHAR(5) PRIMARY KEY, team_name VARCHAR(20), player_num NUMERIC(3,0), player_name VARCHAR(20) );
📐 Key Formulas / Concepts
| ER Construct | Mapping | Table Count |
|---|---|---|
| Strong entity | One table | 1 |
| Weak entity | One table (includes strong entity's PK) | 1 + strong |
| 1:1 relationship | FK in either table (or merge) | 0 additional |
| 1:N relationship | FK on the "many" side | 0 additional |
| M:N relationship | Junction table with both PKs | 1 additional |
| Multi-valued attribute | Separate table | 1 additional |
| Specialization | Separate tables (or single with type) | 1 per sub-type |
⚠️ Common Pitfalls
Pitfall 1: Mapping M:N as 1:N
The Mistake: Adding a FK in one table instead of creating a junction table.
Why It's Wrong: For M:N, a single FK can't represent multiple relationships. Student A takes 5 courses — where would you store 5 course_ids in the student table?
Fix: Create a junction table with both PKs as foreign keys.
Pitfall 2: Wrong Direction for FK in 1:N
The Mistake: Putting FK on the "1" side instead of the "N" side.
Why It's Wrong: If each department has many instructors, and you put FK in department, you'd need multiple FKs (one per instructor) — impossible with fixed columns.
Fix: FK goes on the many (N) side — each instructor stores their department's ID.
Pitfall 3: Forgetting the Weak Entity's Full Key
The Mistake: Only including the discriminator as the primary key.
Why It's Wrong: The discriminator alone doesn't uniquely identify a weak entity. Payment #1 for Loan L-101 is different from Payment #1 for Loan L-102.
Fix: Primary key = (discriminator + strong entity's primary key).
📝 Practice Questions
Q1. How do you map a 1:N relationship to tables?
AnswerAdd the primary key of the "1" side table as a foreign key in the "N" side table.Example: If Department (1) has many Instructors (N), adddept_nameas a FK in theinstructortable. Each instructor stores which department they belong to.
Q2. When do you need a separate junction table?
AnswerA separate junction table is needed for:
- M:N relationships — Student m:n Course → junction table
takes- Multi-valued attributes — Person has many phones → junction table
person_phone- Relationships with their own attributes — takes has
grade
Q3. Map the following ER diagram to tables:
- Entity:
Employee(emp_id, name) - Entity:
Project(proj_id, title) - Relationship:
works_on(M:N withhoursattribute)
AnswersqlCREATE TABLE employee ( emp_id INTEGER PRIMARY KEY, name VARCHAR(50) ); CREATE TABLE project ( proj_id INTEGER PRIMARY KEY, title VARCHAR(50) ); CREATE TABLE works_on ( emp_id INTEGER, proj_id INTEGER, hours NUMERIC(4,1), PRIMARY KEY (emp_id, proj_id), FOREIGN KEY (emp_id) REFERENCES employee(emp_id), FOREIGN KEY (proj_id) REFERENCES project(proj_id) );
Q4. What is the minimum number of tables needed for two entities with a 1:1 relationship (partial on both sides)?
Answer2 tables (minimum).Each entity gets its own table. Since participation is partial (not everyone participates), the relationship is represented by adding a foreign key in one of the tables (whichever you choose).Example:sqlCREATE TABLE person (id INTEGER PRIMARY KEY, name VARCHAR(50)); CREATE TABLE passport (num VARCHAR(20) PRIMARY KEY, person_id INTEGER UNIQUE, FOREIGN KEY (person_id) REFERENCES person(id));
Q5. How do you map a weak entity set?
AnswerCreate a table with:
- All attributes of the weak entity
- The primary key of the identifying strong entity (as FK)
- Primary key = discriminator + strong entity's primary key
Example — Weak entityPaymentdepends on strong entityLoan:sqlCREATE TABLE payment ( payment_no INTEGER, loan_no VARCHAR(5), amount NUMERIC(10,2), date DATE, PRIMARY KEY (payment_no, loan_no), FOREIGN KEY (loan_no) REFERENCES loan(loan_no) );
Q6. Compare the two approaches for mapping specialization.
Answer
| Approach | Schema | When to Use |
|---|---|---|
| Separate tables | Parent table + one child table per subtype | Subtypes have many unique attributes; disjoint types |
| Single table | One table with discriminator column + nullable subtype attributes | Subtypes share most attributes; overlapping allowed |
Example:Employeewith subtypesSecretaryandEngineer:
- Separate:
employee(ID, name),secretary(ID, typing_speed),engineer(ID, degree)- Single:
employee(ID, name, type, typing_speed, degree)
Q7. Given an ER diagram with entities A, B and a ternary relationship R, how many tables are needed?
AnswerMinimum: 3 tables (one for each entity).If the ternary relationship has no attributes and appropriate cardinalities, the FKs can be placed in existing entity tables. But typically, a ternary relationship needs its own table (a junction table with three foreign keys) for proper normalization.The general answer depends on the cardinalities, but at minimum, each entity set = 1 table.
Q8. Create tables for: A Person has multiple addresses. Each address has street, city, state.
AnswersqlCREATE TABLE person ( person_id INTEGER PRIMARY KEY, name VARCHAR(50) ); -- Multi-valued attribute → separate table CREATE TABLE person_address ( person_id INTEGER, street VARCHAR(100), city VARCHAR(50), state VARCHAR(20), PRIMARY KEY (person_id, street, city, state), FOREIGN KEY (person_id) REFERENCES person(person_id) );
🔗 Cross-References
- Next Topic: 14 - Functional Dependencies
- Previous Topic: 12 - ER Model
- Related: BSCS2003 (MAD 1) — Creating database schemas from requirements
- Related: 16 - Normalization (ensuring the mapped schema is well-designed)
- Textbook: Silberschatz, Korth, Sudarshan — Chapter 7 (ER Model), Chapter 8 (Relational Database Design) Join Discord Previous12 - ER ModelNext14 - Functional Dependencies