CSC 2702

Relational Database
Design by ER-to-
Relational Mapping
Department of Computer Science
School of Natural Sciences
University of Zambia
Overview

• Builds on ER models and relational models

• Focuses on logical database design or data model mapping

• Looks at the process of designing a relational database schema from a

conceptual schema
• Covers converting an entity-relationship (ER) schema into a relational schema

• Outlines a seven-step process for converting ER model constructs (entity types,

relationships, and attributes) into relations

• Many CASE tools use ER diagrams to develop schemas and convert

them into relational schemas automatically
ER-to-Relational Mapping Algorithm

• The ER-to-Relational Mapping Algorithm is used to convert an ER

schema into a relational database schema
• The mapping results in tables with simple, single-valued attributes, and
includes relational model constraints such as primary keys, unique keys,
and referential integrity constraints
• Recall that:
• ER Schema: Diagrammatic representation of entities, relationships, and attributes
(Figure 9.1)
• Relational Schema: The corresponding relational database schema with tables and
constraints (Figure 9.2)

• The algorithm systematically transforms the ER diagram into a format

suitable for implementation in a relational database system
ER-to-Relational
Mapping Algorithm

• ER Schema based on
the COMPANY
database example

• Diagrammatic
representation of the
ER schema with
entities, relationships,
and attributes
ER-to-Relational
Mapping Algorithm

• Relational Schema
based on the
COMPANY database
example

• Diagrammatic
representation of
relational database
schema with tables and
constraints
ER-to-Relational Mapping Algorithm - Step 1: Mapping of
Regular Entity
• Objective: Convert each regular (strong) entity type from the ER schema into a
corresponding relation (table) in the relational schema

• Process
1. Create a Relation: For each strong entity type E in the ER schema, create a relation R
that includes all the simple attributes of E

2. Composite Attributes: Include only the simple components of any composite attributes

3. Primary Key Selection: Choose one of the key attributes of E as the primary key for R
• If the primary key is composite, the combination of its simple attributes will form the primary key
of R

4. Additional Keys: If multiple keys are identified for E, record them for possible
specification as additional (unique) keys in R and for indexing or analysis purposes
ER-to-Relational Mapping Algorithm - Step 1: Mapping of
Regular Entity
• Example
• Entity Types: EMPLOYEE, DEPARTMENT, and PROJECT from the ER schema (Fig. 9.1)
• Created Relations: Corresponding tables EMPLOYEE, DEPARTMENT, and PROJECT in
the relational schema (Fig. 9.2)
• Primary Keys: Ssn for EMPLOYEE, Dnumber for DEPARTMENT, and Pnumber for
PROJECT
• Unique Keys: Knowledge that Dname (DEPARTMENT) and Pname (PROJECT) are
unique is retained for possible use later

• Output
• Step 1 results in creating relations that correspond directly to the regular entity types.
• These relations are sometimes referred to as entity relations because each tuple in the
relation represents an entity instance – result shown in Fig 9.3 (a)
ER-to-Relational Mapping Algorithm - Step 1: Mapping of
Regular Entity
ER-to-Relational Mapping Algorithm - Step 2: Mapping of
Weak Entity Types
• Objective: Convert each weak entity type from the ER schema into a
corresponding relation in the relational schema, ensuring the relationship with the
owner entity type is properly represented
• Process
1. Create a Relation: For each weak entity type W with an owner entity type E, create a
relation R that includes all simple attributes of W
2. Include Foreign Key: Add the primary key of the relation corresponding to the owner
entity type E as a foreign key in R
• This handles the identifying relationship

3. Define Primary Key: The primary key of R is a combination of the primary key of the
owner entity type(s) and the partial key of the weak entity type W
4. Cascading Rules: Consider applying the propagate (CASCADE) option for referential
actions (ON UPDATE and ON DELETE) to maintain the existence dependency of the
weak entity on its owner
ER-to-Relational Mapping Algorithm - Step 2: Mapping of
Weak Entity Types
• Example
• Weak Entity Type: DEPENDENT from the ER schema
• Created Relation: The relation DEPENDENT is created
• Foreign Key: The primary key Ssn from the EMPLOYEE relation (the owner) is
included as a foreign key in DEPENDENT, renamed as Essn
• Primary Key: The primary key of DEPENDENT is the combination of Essn and
Dependent_name (where Dependent_name is the partial key of the weak entity)

• Output
• Step 2 results in the creation of relations that correspond to weak entity types, ensuring
that their dependency on owner entities is maintained
• The process ensures that referential integrity is upheld, especially with the use of
cascading options – result shown in Fig. 9.3(b)
ER-to-Relational Mapping Algorithm - Step 3: Mapping of
Binary 1:1 Relationship Types
Process: For each binary 1:1 relationship type R in the ER schema, the following
steps can be taken to map it into the relational schema:
1. Foreign Key Approach
• Identify Relations: Determine the relations S and T corresponding to the entity types
involved in R
• Choose a Foreign Key: Select one of the relations, typically S, and include the primary key
of T as a foreign key in S
• Total Participation Preference: Preferably, choose S where R has total participation
• Include Attributes: Add the simple attributes of the relationship R to S
• Example
• Relationship Type: MANAGES (1:1 relationship between EMPLOYEE and DEPARTMENT)
• Mapping: Include the primary key of EMPLOYEE as Mgr_ssn in DEPARTMENT and add the
Start_date attribute as Mgr_start_date
ER-to-Relational Mapping Algorithm - Step 3: Mapping of
Binary 1:1 Relationship Types
2. Merged Relation Approach
• Merge Entities: Combine both entity types and the relationship into a single relation

• Condition: This is viable when both sides of the relationship have total participation, meaning they always
correspond 1:1

3. Cross-Reference or Relationship Relation Approach

• Create a New Relation: Set up a third relation R that cross-references the primary keys of the original relations S
and T

• Include Primary Keys: The relation R will contain the primary keys of S and T as foreign keys

• Primary Key and Unique Key: Make one of these foreign keys the primary key of R, and the other a unique key

• Use Case: This approach is typically required for binary M relationships but can also be applied to 1:1
relationships if needed

• The choice of approach depends on the nature of the relationship and the specific requirements of
the database schema
• The foreign key approach is most common unless specific conditions favor the other methods
ER-to-Relational Mapping Algorithm - Step 4: Mapping of
Binary 1:N Relationship Types
Process: There are two possible approaches for mapping binary 1:N relationship types

1. Foreign Key Approach

• Identify the N-Side Relation: Determine the relation S that represents the entity type on the N-side of the
relationship

• Add Foreign Key: Include the primary key of the relation T (which represents the entity type on the 1-side) as a
foreign key in S

• Include Attributes: Add any simple attributes of the 1 relationship type to S

• Example
• WORKS_FOR Relationship: Include the primary key Dnumber of the DEPARTMENT relation as a foreign key in
EMPLOYEE and call it Dno

• SUPERVISION Relationship: Since this relationship is recursive, include the primary key of EMPLOYEE as a foreign key in
the same EMPLOYEE relation, and call it Super_ssn

• CONTROLS Relationship: Map to the foreign key attribute Dnum of PROJECT, which references the primary key Dnumber
of DEPARTMENT

• Advantages: This approach reduces the number of tables and is generally preferred
ER-to-Relational Mapping Algorithm - Step 4: Mapping of
Binary 1:N Relationship Types
• Relationship Relation Approach
• Create a Separate Relation: Establish a new relation R that includes the primary keys of
both S and T as foreign keys.

• Primary Key of R: The primary key of R is typically the same as the primary key of S.

• When to Use: This approach is useful if only a few tuples in S participate in the
relationship, thereby avoiding many NULL values in the foreign key within S.

• In practice, the Foreign Key Approach is generally the preferred method due to
its simplicity and efficiency in reducing the number of tables

• However, the Relationship Relation Approach can be useful in specific

scenarios where it helps to avoid unnecessary NULL values
ER-to-Relational Mapping Algorithm - Step 5: Mapping of
Binary M:N Relationship Types
• Create a New Relation: For each binary M:N relationship type, create a new
relation S
• Include Foreign Keys: Add the primary keys of the participating entity types as
foreign keys in S
• These foreign keys together form the primary key of S

• Add Relationship Attributes: Include any simple attributes of the M:N

relationship type as additional attributes in S
• Why This Approach: Unlike 1:1 or 1:N relationships, M:N relationships cannot
be represented by a single foreign key in one of the participating relations due
to the M:N cardinality ratio
• A separate relation S is necessary to properly represent the relationship
ER-to-Relational Mapping Algorithm - Step 5: Mapping of
Binary M:N Relationship Types
• Example
• WORKS_ON Relationship: Create the relation WORKS_ON to represent the M:N
relationship between PROJECT and EMPLOYEE

• Include Foreign Keys: The primary keys of PROJECT and EMPLOYEE are included as
foreign keys in WORKS_ON, renamed as Pno and Essn respectively (renaming is optional)

• Add Relationship Attribute: Include the attribute Hours in WORKS_ON to represent the
number of hours an employee works on a project

• The primary key of WORKS_ON is the combination of Essn and Pno

ER-to-Relational Mapping Algorithm - Step 5: Mapping of
Binary M:N Relationship Types
• Referential Integrity
• It is advisable to specify the propagate (CASCADE) option for referential integrity actions on the
foreign keys in the relationship relation S

• This ensures that any updates or deletions in the related entities are reflected in the relationship
relation

• Applicability to 1:1 and 1:N Relationships

• Although the cross-reference approach can also be used for 1:1 or 1:N relationships, it is
generally recommended only when there are few relationship instances, to avoid unnecessary
NULL values

• For 1:N relationships, the primary key of the relationship relation is typically the foreign key that
references the entity on the N-side

• For 1:1 relationships, either foreign key can serve as the primary key of the relationship relation
ER-to-Relational Mapping Algorithm - Step 6: Mapping of
Multivalued Attributes
• Create a New Relation
• For each multivalued attribute A, create a new relation R

• This relation will include:

• Attribute A itself

• The primary key attribute K of the related entity or relationship, included as a foreign key in R

• Primary Key of R
• The primary key of R is the combination of A and K

• If A is composite, include its simple components as attributes in R

ER-to-Relational Mapping Algorithm - Step 6: Mapping of
Multivalued Attributes
• Example: DEPT_LOCATIONS Relation
• Dlocation represents the multivalued attribute LOCATIONS of DEPARTMENT

• Dnumber (as a foreign key) represents the primary key of the DEPARTMENT relation

• The primary key of DEPT_LOCATIONS is the combination of {Dnumber, Dlocation}

• Cascade Options
• The CASCADE option for referential integrity should be specified for both ON UPDATE and
ON DELETE actions on the foreign key in R
ER-to-Relational Mapping Algorithm - Step 6: Mapping of
Multivalued Attributes
• Composite Multivalued Attributes
• If the multivalued attribute is composite, some analysis is required to determine
which component attributes should be part of the key of R
• This is similar to determining the partial key of a weak entity type

• Note
• In modern relational models that support array data types, multivalued attributes might be
mapped directly to an array attribute instead of requiring a separate table

• Step 6 helps ensure that multivalued attributes are properly represented in the
relational schema, typically by creating an additional table to handle the multiple
values associated with a single entity
ER-to-Relational Mapping Algorithm - Step 7: Mapping of N-
ary Relationship Types
• For each n-ary relationship type (where n > 2), create a new relationship relation S to
represent the relationship

• Include Foreign Keys

• S should include as foreign key attributes the primary keys of the relations representing the
participating entity types

• Include Relationship Attributes

• Include any simple attributes (or simple components of composite attributes) of the n-ary
relationship type as attributes of S

• Primary Key of S
• The primary key of S is usually a combination of all the foreign keys that reference the
participating entity types
• Exception: If any participating entity type has a cardinality constraint of 1, exclude the
corresponding foreign key from the primary key of S
ER-to-Relational Mapping Algorithm - Step 7: Mapping of N-
ary Relationship Types
• Example: SUPPLY Relationship
• SUPPLY relates SUPPLIER s, PART p, and PROJECT j

• The corresponding relation SUPPLY includes the foreign keys Sname, Part_no, and
Proj_name

• The primary key of SUPPLY is the combination of these three foreign keys: {Sname,
Part_no, Proj_name}

• Step 7 ensures that n-ary relationships (relationships involving more than

two entities) are correctly represented in the relational schema by creating a
new table that captures the associations between the multiple entities
involved

• The table will also store any attributes that are specific to the relationship
Discussions &Summary of Mapping for ER Model
Constructs
Discussions & Summary of Mapping for ER Model
Constructs
• ER and Relational Model Correspondence
• In relational schemas, relationship types are not explicitly represented
• Relationships are indicated by attributes that serve as primary and foreign keys in related
tables

• Join Operations
• EQUIJOIN/NATURAL JOIN: Used to combine related tuples from two tables by matching
primary and foreign keys
• For 1:1 or 1:N relationships, usually one join operation suffices
• M:N relationships require two joins, while n-ary relationships need n joins
• Example: To get employee names, project names, and hours worked on each project, two
joins are needed between EMPLOYEE, WORKS_ON, and PROJECT relations
Discussions & Summary of Mapping for ER Model
Constructs
• Foreign Key Awareness
• Users must correctly use foreign keys when combining tuples to avoid meaningless or spurious results
• Incorrect joins can lead to irrelevant data, like joining PROJECT and DEPT_LOCATIONS on non-
corresponding attributes

• Multivalued Attributes
• A separate relation is created for each multivalued attribute
• The entity’s key is repeated in each tuple corresponding to a different value of the multivalued attribute
• Example: In DEPT_LOCATIONS, department 5 with three locations results in three tuples

• Limitations of Basic Relational Algebra

• Basic relational algebra lacks operations to combine multiple values of a multivalued attribute into a single
tuple
• This limitation is addressed in object-relational systems and object data models, which support multivalued
attributes via array types