ITE 2422 – Database Management Systems Week 06

8.0 ER to Relational Mapping

Introduction

During this 8th lesson you will learn how to map an ER diagram to a relational model.
In the previous lesson, you have learnt about the main concepts in a relational data
model that can be directly implemented by any relational database management
system (RDBMS). Also, you have learnt about creating a proper ER diagram to a given
scenario.

Let us start the lesson 8.

Learning outcomes

After completing this lesson, you will be able to convert an ER diagram to a

relational model.

You will be able to:

1. Map Regular Entity Types.
2. Map Multivalued attributes.
3. Map Weak Entity Types.
4. Map Binary 1:1 Relation Types
5. Map Binary 1:N Relationship Types.
6. Map Binary M:N Relationship Types.
7. Map various Degree of Relationship Types.

After designing an ER diagram to a given scenario, we need to convert it to a

relational model, which is useful in creating an actual relational database.

ER to Relational Mapping 1/14

ITE 2422 – Database Management Systems Week 06

ER diagrams can be mapped to relational models. That is, it is possible to create a

relational model using an ER diagram. We will focus about mapping EER diagrams to
relational model in the next lesson.

Let’s try to map ER diagrams to relational models using the set of steps mentioned
below.

8.1 Map Regular (Strong) Entity Types

What is a regular entity? It is also known as a strong entity.
To understand what a strong entity is, it is important to know the difference between
strong entity and weak entity.
Strong entity can be used independently compared to a weak entity. Weak entity
depends on a strong entity. Records in a strong entity can be identified uniquely by its
primary key. Weak entity has only a partial key, that is, to uniquely identify each
item in a weak entity we need to use the primary key of its strong entity (owner) as
well.

So, how to convert a regular (strong) entity? It is important to consider the following
facts.
• Each entity type becomes a table in the relational model.
• Each single-valued attribute becomes a column.
• Derived attributes are ignored.
• Composite attributes are represented by components.
• The key attribute of the entity type becomes the primary key of the table.

Let us see an example (Figure 8.1).

ER to Relational Mapping 2/14

ITE 2422 – Database Management Systems Week 06

FName
MName
e

ENo LName
FullName
DateOfBirth
NIC

Employee Age

Figure 8.1: Regular entity

ER diagram in Figure 8.1 can be mapped to the following Relational schema:

Employee (ENo, NIC, FName, MName, LName, DateOfBirth)

As you can see:

• Employee entity is converted to an Employee relation.
• FullName is a composite attribute. Thus, each component (FName, MName,
LName) is included in the relational schema as attributes. FullName is not
included in the relational schema.
• Age is a derived attribute (can be calculated from date of birth). Thus, it is not
included in the relational schema as an attribute.

8.2 Map Multivalued Attributes

If there are multivalued attributes, for each multivalued attribute, a new relation is
created.

Let us consider an example (Figure 8.2).

ER to Relational Mapping 3/14

ITE 2422 – Database Management Systems Week 06

ENo DateOfBirth

Name
Employee SkillSet

Figure 8.2: Multivalued attribute in Employee entity

From the ER Diagram in Figure 8.2, the following relational schema can be created.

Employee (ENo, Name, DateOfBirth)

SkillSet (ENo, Skill)

As can be seen in the relational schema,

• A new relation is created for the skillset as it is a multivalued attribute in the

ER diagram.
• Skillset has a composite primary key (ENo and Skill). To uniquely identify each
record in the SkillSet relation, both ENo and Skill are required. There could be
many employees with the same skill, as such, Skill cannot be the only primary
key in the SkillSet relation.
• ENo in SkillSet is a foreign key to ENo in Employee relation.

If there is another multivalued attribute, then another relation will be created from
that.

ER to Relational Mapping 4/14

ITE 2422 – Database Management Systems Week 06

8.3 Map Weak Entity Types

In section 8.1, we have already discussed about the difference between strong and
weak entities. Weak entity types are converted into a relation with the primary key of
the strong entity acting as a foreign key in the relation created from the weak entity.
This foreign key along with the key of the weak entity form the composite primary
key of this relation.

Let us consider an example (Figure 8.3).

…
ENo Name DependentId DependentName

Employee Has Dependent

Address

Figure 8.3: Dependent weak entity

From the ER Diagram in Figure 8.3, the following relational schema can be created.

Employee (ENo, ……, Name)

Dependent (ENo, DependentId, DependentName, Address)

As can be seen in Figure 8.3, Dependent is a weak entity. A relation will be created as
Dependent. However, to identify the dependents of each employee, a foreign key will
be created from the Dependent relation to Employee relation.

ER to Relational Mapping 5/14

ITE 2422 – Database Management Systems Week 06

In the next section, we will be learning about mapping a relationship to a relational

schema.

8.4 Map Binary 1:1 Relation Types

We can differentiate the mapping process based on the type of participation in a
binary relationship.

Let us try to understand it with some example scenarios.

Case 1: Combination of participation types

Here, Employee entity and Manges relationship has a partial participation and
Department and Manges has a total participation (double lines to connect) as
illustrated in Figure 8.4. The primary key of the partial participant (Employee) will
become the foreign key of the total participant (Department).

StartDate
As can be seen in the Figure 8.4

1 1
Employee Manages Department

Figure 8.4: Binary 1:1 relationship with partial/total participation

From the ER Diagram in Figure 8.4, the following relational schema can be created.

Employee (ENo, EName, ….)

Department (DepartmentNo, DName, …, StartDate, ManagerENo)

Here, ManagerENo is a foreign key referring to ENo in Employee. If there is an

attribute in the Manages relationship, it will be moved to the total participant (to
Department).

ER to Relational Mapping 6/14

ITE 2422 – Database Management Systems Week 06

Case 2: Uniform participation types

Both sides are having same type of participation. Employee and Desktop computer are
having total participation with the Has relationship as shown in Figure 8.5. The
primary key of either of the participants can become a foreign key in the other.

1 1
Employee Has Desktop

Figure 8.5: Binary 1:1 relationship with partial participation

From the ER Diagram in Figure 8.5, the following relational schema can be created.

Employee (ENo, EName, ….)

Desktop (DNo, IPAddress, Model, Brand, …, UserENo)

or

Employee (ENo, EName, …., DesktopId)

Desktop (DNo, IPAddress, Model, Brand, …)

Thus, Desktop can have a foreign key called UserENo referring to ENo in Employee or
Employee can have a foreign key called DesktopId referring to DNo in Desktop. Either
one of these options can be used when converting to a relational schema.

Case 1 and case 2 are known as Foreign Key approach.

ER to Relational Mapping 7/14

ITE 2422 – Database Management Systems Week 06

Case 3: Both participations are total

Here, the two entity types and the relationship can be merged into a single relation.
If not, case 2 could be used.

From the Figure 8.5, the following relational schema can be created.

Employee (ENo, EName, DNo, IPAddress, Model, Brand, ….)

All the attributes of Employee and Desktop are placed in the same relation. Thus,
foreign keys are not used as in case 1 and case 2.

Next, we will consider how to map a binary 1:N relationship.

8.5 Map Binary 1:N Relationship Types.

The primary key of the relation on the “1” side of the relationship becomes a foreign
key in the relation on the “N” side.
Let us try to understand it through an example (Figure 8.6).

N 1
Employee Works_in Department

Figure 8.6: Binary 1:N relationship

From the Figure 8.6, the following relational schema can be created.

Employee (ENo, EName, …., DNo)

Department (DNum, DName, …)

Foreign key will be created in the Employee relation as it is the “N” side. DNo in
Employee refers DNum in Department.

ER to Relational Mapping 8/14

ITE 2422 – Database Management Systems Week 06

8.6 Map Binary M:N Relationship Types.

When there is M:N relationship as in Figure 8.7:
• A new table is created to represent the relationship
• It contains two foreign keys - one from each of the participants in the
relationship
• The primary key of the new table is the combination of the two foreign keys

Let us try to understand it through an example (Figure 8.7).

N M
Employee Works_in Project

Figure 8.7: Binary M:N relationship

From the ER Diagram in Figure 8.7, the following relational schema can be created.

Employee (ENo, EName, …., DNo)

Works_in (ENo, PNo, Hours_Worked)

Project (PNo, PName, …)

As can be seen in Figure 8.7, a new relation is created as Works_in. It has ENo as a
foreign key referring to Employee and PNo as a foreign key referring to Project. In
Works_in relation, both ENo and PNo are a composite primary key. If there are any
attributes in the Works_in relationship, then they will be included in the Works_in
relation (Hours_Worked).

Up to now we have discussed about binary relationships. So, what happens if there
are N-ary relationships?

ER to Relational Mapping 9/14

ITE 2422 – Database Management Systems Week 06

8.7 Mapping Degree of Relationship

Based on the degree of a relationship we can identify several types of relationships as
unary, binary (already discussed), ternary and n-ary.

Let us try to understand it with some example scenarios.

Unary Relationships:
Self-Referencing 1: 1 Relationship
As shown in Figure 8.8, a couple works in the same company. Both husband and wife
are employees of the company. Thus, two relations will not be created to represent
husband and wife. They will be considered as roles of the Employee. Therefore, the
primary key field itself will become a foreign key in the same relation. This is called
as self-referencing.

Wife
Married_to
1

Employee
1
Husband

Figure 8.8: Self-referencing 1:1 relationship

From the ER Diagram in Figure 8.8, the following relational schema can be created.

Employee (ENo, EName, …., Spouse)

The ENo of the spouse will be mentioned in the Spouse attribute of Employee
relation. Spouse is a foreign key referring to the ENo in Employee.

Self-Referencing 1: N Relationship
This will be handled as same as self-referencing 1:1 relationship. That is, the primary
key field itself will become a foreign key in the same relation (Figure 8.9).

ER to Relational Mapping 10/14

ITE 2422 – Database Management Systems Week 06

Manager
Manager_of
1

Employee
N
Subordinate

Figure 8.9: Self-referencing 1:N relationship

From the ER Diagram in Figure 8.9, the following relational schema can be created.

Employee (ENo, EName, …., ManagerENo)

Self-Referencing M: N Relationship
As illustrated in Figure 8.10, an employee can be a guarantor for many employees and
an employee can be beneficiary from many employees (as guarantors). Even though,
only Employee entity is used in the ER diagram, there will be two resulting relations
in the relational model. One relation represents the entity and the other relation
represents the M:N relationship.

M Guarantor_of

Employee
N

Figure 8.10: Self-referencing M:N relationship

From the ER Diagram in Figure 8.10, the following relational schema can be created.

ER to Relational Mapping 11/14

ITE 2422 – Database Management Systems Week 06

Employee (ENo, EName, ….)

Guaranty (Guarantor, Beneficiary)

Here, from M:N relationship a relation is created as Guaranty. Then there will be two
primary keys in the Guaranty relation to represent the two roles (Guarantor and
Beneficiary) of the employee in the unary relationship. Guarantor and Beneficiary in
Guaranty relation are foreign keys referring to Employee relation.

N-ary Relationships:
Here, we will be considering both ternary and n-ary relationships. There are three
entities participating with the prescription relationship in Figure 8.11. A new relation
will be created from the Prescription relationship. This new relation contains three
foreign keys - one from each of the participating Entities. Thus, the primary key of
the new relation is the combination of all three foreign keys.

Doctor Prescription Patient

Medicine

Figure 8.11: Ternary relationship

From the ER diagram in Figure 8.11, the following relational schema can be created.

ER to Relational Mapping 12/14

ITE 2422 – Database Management Systems Week 06

Doctor (DocNo, DName, ….)

Prescription (DoctorNo, PatientId, MedicineId)

Patient (PatientId, PName, …)

Medicine (MId, MName, ….)

We have come to the end of the lesson.

Do Activity 8.1 to get a better understanding of the mapping.

Activity 8.1

Complete the table below.

ER Diagram Relational Model
N-ary relationship type
Ternary relationship type
Unary 1:M relationship type
Unary N:M relationship type
Binary N:M relationship type
Simple attribute
Composite attribute
Key attribute
Regular entity

ER to Relational Mapping 13/14

ITE 2422 – Database Management Systems Week 06

Summary
Now we have completed Lesson 8. In this lesson, we discussed various concepts in
mapping an ER diagram to a relational model.

Based on the type of the entity, relationships and their attributes there are
variations in converting an ER diagram to a relation model. By following the steps
mentioned in this lesson, you will be able to create a relational database for an ER
diagram.

In the lesson 9, you will learn more details about converting an EER diagram to a
relational model. Thus, you will be able to start creating a relational database.
Before you go to the next lesson, complete the activities to check what you
have learnt in the Lesson 8.

ER to Relational Mapping 14/14