Converting From ER model
to Relational (Logical) model
Prof. Kline
Where we are in the Db development process
ER or
Conceptual
Design
Based on
User Req’ts
ER Model
Entity
Entity Instance
Attribute
Identifier
Relationship
Logical
Database
Design
Using
Relational
Model
Relational Model
Relation
Tuple
Attribute
Key
Foreign Key /
Multiplicity
Normalize
Relational
Design
Physical
Database
Design
Normalized
Relational
Model
Apply
normalized
forms up to
3NF
Physical Model
Table
Row (or Record)
Column
Data values
Primary Key
Foreign Key
Converting an ER model to Relational
model
In this process, business requirements are further modeled with the use of
one or more advanced features. Using UML these features can be
represented graphically.
• Primary Key/Foreign Keys
– Weak (dependent) vs strong (independent)
• Cardinality (max/min)
– 1:1
– 1:*
– *:*
• Inheritance
• Composition
• Aggregation
3
Converting ER model to Relational
 Previously, we modeled the user’s view as an E-R diagram. Entities,
Relationships, Attributes and Identifiers.
 We now need to convert this conceptual representation to a relational
model (set of relations).
 Relational Model includes: Relations, Tuples/Record, Attributes, keys
and foreign keys.
 Relation: A two dimensional table make up of tuples (previously an entity).
 Tuple / Record: A row of data in a relation made up of one or more
attributes.
 Attribute: A characteristic of the relation contained in a row.
 Key: Unique identifier (one or more attributes). Primary key.
 Foreign Key: Key propagated to related relations
4
Converting ER model to Relational
For a majority of ER Models, entities and weak entities
convert easily into Relations.
General steps:
Entities – In general, each Entity will be converted directly
to a Relation.
The attributes of the entity become the attributes of the
Relation.
The Identifier of the Entity becomes a Key of the Relation.
Relationships between Entities will be mapped as Foreign
Keys.
There are a number of variations to this last step that will be
described in more details below.
5
Converting ER model to Relational
 Is more of a mechanical set of steps but is important to get the
foreign keys (FK) propagated through the model.
 Relational model should be the first time FKs are modeled.
 One to One Relationship: Copy the key from one relation to the
other side (side does not matter)
 One to Many: Copy the key from the one side to the relation on
the many side.
 Many to Many: Create an intersection relations with the keys
from both participating relations.
 ID-Dependent relation: ID-Dependent relation is modeled having
a composite key (see slide # in ).
 Its important to use the correct vocabulary for the appropriate
model (ER vs Relational).
 Normalization. Define relations up through 3NF.
6
Shortlist of Types of Relational model
Keys
• Key (Primary) – An attribute, or set of attributes,
that is selected to uniquely identify rows / records
within the relation.
• Candidate key – minimum set of attributes the
uniquely identifies row / records within the relation.
Relations may have more than one candidate key.
• Alternate key – Candidate keys other than primary
key.
• Foreign Key – An attribute, or set of attributes,
within one relation that matches the candidate key
(usually the Primary key) of some other relation.
– Used to create relationships between relations
– Used to enforce certain types of integrity constraints7
ID dependent Entities / Relations
(Weak)
As you develop your relational model, you may
discover certain entities that depend upon the value
of the foreign key attribute for uniqueness. For
these entities, the foreign key must be a part of the
key of the child entity in order to uniquely define
each entity.
In relational terms, a child relation that depends on
the foreign key attribute for uniqueness is called a
dependent entity (relations).
Relations that do not depend on any other relation
in the model for identification are called
independent entities (relations)
If a weak relation is ID Dependent, then the parent
relation’s key (Identifier) is copied into the
dependent relation and made into a Composite Key.
8
Weak Entities and ID Dependent Entities
 Broad definition. Weak Entity: An entity that depends on another for its existence.
Another definition of Weak entity: Entity types that do not have key attributes of their
own.
ID Dependent Entity: A weak entity that includes the identifier of the related strong
entity.
Examples of strong entities:
People, Employees, Customers, Clients, Vendors, Students
Products, Services, Parts, Resources, Materials
Banks
Examples of ID Dependent entities: Dependents (of employees), Bank Branches (of
Banks).
ID Dependent entities are sometimes shown with double-lined boxes or curved
boxes as in the Visible Analyst ER example. Note that an ITEM can not exist by
itself. It must be identified with a specific Order.
9
UML Multiplicity (see pg 304 P & L)
• At each end of each association is an expression that represents
multiplicity.
• Multiplicity indicates the number of objects that can be related to
an individual object at the other end of the relationship.
• UML multiplicity provides various alternatives for representing the
number of objects in terms of minimum (i.e. participation) and
maximum (i.e. cardinality).
• The first symbol in UML multiplicity represents the minimum
number of objects, and the second symbol separated by two
periods represents the maximum number of objects. A second
symbol of n indicates that there is not a maximum number of
objects.
•
An relation in a relationship with participation of zero plays
an optional role in the relationship
• An relation with a participation of one plays a mandatory role
in the relationship
10
Participation
Participation: Determines whether all or only some entity
occurrences participate in a relation
- The participation constraint represents whether all entity
occurrences are involved in a particular relationship
(referred to as mandatory participation, 1) or only some
(referred to as optional participation, 0).
- Note: participation for a given entity in a relationship is
represented by the minimum value on the opposite side of
the relationship.
Branches are
managed by Staff. Staff
Mandatory
participation for
Branch
1..1
manages
Branch
0..1
S
B
B
It is optional that
Staff manages
Branch. Optional
participation for
Staff
11
Cardinality
Describes the maximum number of possible relationship
occurrences for an entity participating in a given relationship
type.
- The cardinality of a binary relationship is referred as one
to one (1:1), one to many (1:*), and many to many (*:*)
- The cardinality of a relationship appears as the maximum
values for the multiplicity ranges on either side of the
relation.
- How to represent Cardinality, for Staff managing more
than one Branch? For up to 5?
The manages
Staff manages up
to 1 Branch, and
a Branch is
managed by 1
Staff.
Staff
1..1
manages
Branch
0..1
relationship
between Staff
and Branch is a
1:1 relationship
12
UML Multiplicity (Min / Max)
Practice interpreting the various multiplicity indicators
between relations in your exercises.
One-to-One Relationship
Considerations
• Simply include the identifier of each entity as a
identifier in the other table
– No guarantee that the information will match
• One solution: create a single table
– Workable, but not the best solution
• Better solution
– Create separate entities for customers and sales
reps, each having the others identifier/PK
• Provide an example of 1 :1 with data…
©2015 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part, except for use as
permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use.
14
Entity to Relation Conversion

1:1 Relationships. The key of each relation is stored in the second
relation.
has
 1: 1 Relationships.
Represent each Entity as a relation.
Copy the key of one relation into the other, and vice versa.
Company (CompanyID, name, location, BoardID (fk))
BoardOfDirectors (BoardID, ChairPerson, CompanyID (fk))
15
One-to-One Relationship
Considerations
• Simply include the identifier/PK of each entity as a
identifier in the other table
– No guarantee that the information will match
• One solution: create a single table
– Workable, but not the best solution
• Better solution
– Create separate entities for customers and sales
reps, each having the others identifier
• Provide an example of 1 :1 with data…
©2015 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part, except for use as
permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use.
16
1:N Relationships.
• Parent – Relation on the “1” side.
• Child – Relation on the “Many” side.
• Represent each Entity as a relation.
• Copy the key of the parent into the child relation.
-CustomerID
17
Many-to-Many Relationship
Considerations
• Complex issues arise when more than two entities
are related in a many-to-many relationship
• Typically represented by two 1 : * relationships with
an association entity sharing the identifiers of the
participating entities.
• Provide an example of m : n with data
©2015 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part, except for use as
permitted in a license distributed with a certain product or service or otherwise on a password-protected website for classroom use.
18
Representing Relationships – M : N
SUPPLIER (SupplierID, FirmName, Address, …)
PRODUCT (ProductID, Description, …)
PRODUCT_SUPPLIER (SupplierID (fk), ProductID (fk))
Providing >
Supplier 1..1
Product
0..* Product_
Supplier
< Supplied by
19
Representing many : many associations
• Many:many relationship
between two relations is
mapped to an intersect
relation
• This relation comprises keys
of the two relations.
• Resolved the many:many by
converting it into two 1:many
relationshipsii
Another example
Representing Relationships – Recursive one to many
 We can implement 1 : * for Part directly by
including another copy of the key in the relation.
PART (Part_ID, Parent_Part_ID (fk),
partDescription)
A part can be made up
of one or more other
parts. (One or more
parts can make up
another part)
21
Representing Relationships –
Recursive Many to many
Other kinds of recursive relationships N : M
 STUDENT tutors one or more other STUDENTS – Also, that STUDENT
can be tutored by one more other STUDENTS.
STUDENT (Student_ID, Name, Address, …)
TUTOR_INTERSECTION ( Student_ID (fk), Tutored_by_ID (fk))
22
Representing Ternary and IS-A Relationships
Ternary Relationships

For most situations, we can treat a ternary relationship as several binary
relationships between the entities.

If we can re-write the ternary relationship as several binary relationships,
then the above steps can be used to convert the entities into relations.

Example: ORDER, CUSTOMER, SALESPERSON becomes:
ORDER (Order_Number, Order_Date, Customer_ID(fk) Salesperson_Id(fk))
CUSTOMER (Customer_ID, Contact, Address…Salesperson_id (fk))
SALESPERSON (Salesperson_Id, Name, Department, Phone)
SALESPERSON
Salesperson_ID
1
1..*
ORDER
Order_Number
Customer_ID fk
Salesperson_ID
fk
CUSTOMER
Customer_ID
Salesperson_ID fk
23
Subtype Entities
• Attributes of two or more Entities may overlap significantly but not completely.
• Consider:
FullTimeEmployee (EmployeeID,Name,Address,Phone,AnnualSalary,BenefitsCategory)
PartTimeEmployee (EmployeeID,Name,Address,Phone,HourlyRate,MaxHoursPerWeek)
• One approach would be to put all of the attributes into a single entity.
Second approach, put common attributes into a parent or supertype entity and then
have two subtype entities.
Relationship is called an IS-A relationship, or an Inheritance relationship. UML
symbols are used….
24
Inheritance
IS-A Relationships
Recall that some entities may have subtypes
associated with them. Often referred to inheritance
structures.
25
Representing IS-A Relationships
Strategy is:

Convert the supertype entity directly into a relation using only those
attributes in the supertype – note the key.
•
Convert each of the subtype entities into relations – also only with the
attributes they contain.

Copy the primary key for the supertype entity into each of the
subtypes.
So our example becomes:
CALL (Call_Identifier, Customer_Id, Source_Number,
Destination_Number, TimeOfDay)
REGULAR_CALL (Call_Identifier, Duration)
LONG_DISTANCE CALL (Call_Identifier, Duration,
LongDistanceCarrier)
CELL_CALL (Call_Identifier, Air_Time, Land_Time)
26
Inheritance modeling can be
mapped further
Additional Relationships
• Aggregation and Composition
– Collecting together related entities that represent ‘parts’ of a
‘whole’
– Aggregation (non-exclusive subpart): parts can change
parents
– Composition (exclusive subpart): single parent, very strong
association - parts make no sense without parent
– Examples:
• Branch (whole) has Staff (part)
• Newspaper (whole) contains Story (part)
Aggregation
Composition
• EER representation is diamond with arrow from “part”
– Open for aggregation, closed for composition
Composition
http://www.umldiagrams.org/composition.html
What is Composition
• A form of association in which the
whole is completely responsible for its
parts and each part object is only
associated with one whole object.
• In composition there is a strong life
cycle dependency between the two
classes, meaning that when Class A is
deleted then Class B is also deleted as
a result
Composition Examples
Aggregation
Represents a “has a”
or “is part of”
relationship between
entity types, where
one represents the
whole and the other
the part. It is a non
exclusive sub part. If
the whole ceases to
exist, the subpart can
still exist as a part of
another whole. Ex.
Branch (whole), Staff
(part)
Summary
• Converting from E-R to Relational model is a process made up of
multiple steps.
• It is important to get the FKs propagated through the model for
relations that are associated.
• One to One relationship: copy the key from one relation to the
other (does not matter which side is first)
• One to Many: Copy the key from the one side to the relation on
the many side
• Many to Many: Create an intersection relation with keys from
both participating relations
• Id-dependent entity: Key of dependent relation and FK of
independent relation = composite key of dependent relation
Exercise 1 – Advanced features
http://agilemodeling.com/artifacts/physicalDataModel.htm
Exercise 2 – advanced features