▪ We start @ 14:15

▪ Remember to join MS Teams – code: 6esizxc

 Instructor: Krystian Wojtkiewicz
School of Computer Science and Engineering
International University, VNU-HCMC Lecture 2: ER to
Relational Translation
ACKNOWLEDGEMENT
The following slides have been created
adapting the materials of the book
provided by the authors Prof. Jeffrey
D. Ullman and et al.

The following slides are referenced from

Dr. Sudeepa Roy, Duke University.
Notation

Entity/ Weak entity

Attributes

Relationship

• Attributes on relationships
• Multiplicity
• Binary versus n-ary relationships
• ISA relationships
TODAY’S TOPICS
Understand • Understand the real-world domain being modeled

Specify • Specify it using a database design model (e.g., E/R)

Translate • Translate specification to the data model of DBMS (e.g.,

relational)

Create • Create DBMS schema

Reading • Reading material: Chapter 3

 You Translate it
Train (number, engineer, type)
designed to a
an ER Relational Station (name, address,type)
diagram Database
TrainStop (train_number, station_name, time)
Entity set -> relation. Attributes -> attributes.

The keys of the connected entity

Relationships -> relations sets.
whose attributes are only: Attributes of the relationship itself.
Each entity (regular/weak) in the ER is converted into a schema.

For (1,1)-(1,1) relationships. We make one entity’s primary key another entity’s foreign
key and vice versa.

The same for (1,1)-(1,n) relationships, we don’t establish a new schema but bring the
primary key from the (1,n) entity into the (1,1) entity to make a foreign key.

For (1,n)-(1,n) relationships, we establish a new schema containing the primary keys of
the entities that formed it and its own attributes.

For multivalued attribute is converted into a new schema.

For each regular/strong entity type, create a corresponding
relation that includes all the simple attributes (includes
simple attributes of composite relations)

Choose one of the key attributes as primary

• If composite, the simple attributes together form the primary key.

Any remaining key attributes are kept as secondary

unique keys (these will be useful for physical tuning with
reference to indexing analysis)
For each weak entity type, create a corresponding relation that
includes all the simple attributes

Add as a foreign key all of the primary key attribute(s) in the entity
corresponding to the owner entity type

The primary key is the combination of all the primary key attributes
from the owner and the partial key of the weak entity, if any
Three approaches

• Foreign Key
• Usually appropriate
• Merged Relation
• Possible when both participations are total
• Relationship Relation
• Not discussed
Choose one relation as S, the Better if S has total participation
other T (reduces number of NULL values)

Add to S all the simple attributes of the relationship

Add as a foreign key in S the primary key attributes of T

 1 2 3
Choose the S Add as a foreign Another approach:
relation as the key to S all of the create a
type at the N-side primary key relationship
of the relationship, attribute(s) of T relation
other is T
Create a new relation S (termed: Add as foreign keys the primary keys Add any simple attributes of the M :
relationship relation) of both relations; their combination N relationship to S
forms the primary key of S
In some ERD dialects, actually drawn in
 1 2 3
Create a new relation S Add as foreign keys the Add the attribute to S (if
primary keys of the composite, the simple
corresponding relation attributes); the combination
of all attributes in S forms
the primary key
A. Multiple relations –subclass and superclass
▪ Usually works (assumes unique id at parent)

B. Multiple relations –subclass only

▪ Should only be used for disjoint

C. Single relation with one type attribute

▪ Only for disjoint, can result in many NULLs

D. Single relation with multiple type attributes

▪ Better for overlapping, could be disjoint
For each regular/strong entity type, create a corresponding
relation that includes all the simple attributes (includes
simple attributes of composite relations)

Choose one of the key attributes as primary

• If composite, the simple attributes together form the primary key.

Any remaining key attributes are kept as secondary

unique keys (these will be useful for physical tuning with
reference to indexing analysis)
EMPLOYEE

Fname Minit Lmane Ssn Bdate Address Sex Salary

DEPARTMENT

Dname Dnumber

PROJECT

Pname Pnumber Plocation

For each weak entity type, create a corresponding relation that
includes all the simple attributes

Add as a foreign key all of the primary key attribute(s) in the entity
corresponding to the owner entity type

The primary key is the combination of all the primary key attributes
from the owner and the partial key of the weak entity, if any
EMPLOYEE

Fname Minit Lmane Ssn Bdate Address Sex Salary

DEPARTMENT

Dname Dnumber

PROJECT

Pname Pnumber Plocation

DEPENDENT

Essn Dependent_name Sex Bdate Relationship

Three approaches

• Foreign Key
• Usually appropriate
• Merged Relation
• Possible when both participations are total
• Relationship Relation
• Not discussed
Choose one relation as S, the Better if S has total participation
other T (reduces number of NULL values)

Add to S all the simple attributes of the relationship

Add as a foreign key in S the primary key attributes of T

EMPLOYEE
Fname Minit Lmane Ssn Bdate Address Sex Salary

DEPARTMENT
Dname Dnumber Mgr_ssn Mgr_start_date
 1 2 3
Choose the S Add as a foreign Another approach:
relation as the key to S all of the create a
type at the N-side primary key relationship
of the relationship, attribute(s) of T relation
other is T
Create a new relation S (termed: Add as foreign keys the primary keys Add any simple attributes of the M :
relationship relation) of both relations; their combination N relationship to S
forms the primary key of S
In some ERD dialects, actually drawn in
 1 2 3
Create a new relation S Add as foreign keys the Add the attribute to S (if
primary keys of the composite, the simple
corresponding relation attributes); the combination
of all attributes in S forms
the primary key
A. Multiple relations –subclass and superclass
▪ Usually works (assumes unique id at parent)

B. Multiple relations –subclass only

▪ Should only be used for disjoint

C. Single relation with one type attribute

▪ Only for disjoint, can result in many NULLs

D. Single relation with multiple type attributes

▪ Better for overlapping, could be disjoint
B. Multiple relations –subclass only - Should only be used for disjoint
C. Single relation with one type attribute
Only for disjoint, can result in many NULLs
▪ D. Single relation with multiple type attributes
▪ Better for overlapping, could be disjoint
Object-oriented: One relation
per subset of subclasses, with
all relevant attributes.

Use nulls: One relation; entities

have NULL in attributes that
don’t belong to them.

E/R style: One Key

attribute(s).
relation for each Attributes of
subclass: that subclass.
name Beers manf

isa

color Ales
Beers

Name Manf
name Beers manf
Bud Anheuser-Busch

isa
Ales

Name Manf Color color Ales

Summerbrew Pete’s Dark

Good for queries like “find the color of ales made by Pete’s.”
 Beers

Name Manf
Bud Anheuser-Busch
Summerbrew Pete’s
Ales

Name Color
Summerbrew Drak

Good for queries like “find all beers (including ales) made by
Pete’s.”
Name Manf Color
Bud Anheuser- Null
Summerbrew Busch Drak
Pete’s

Saves space unless there are lots of attributes that are

usually NULL.
• Where do the dates go?
• With Users?
• But a user can join multiple groups
on different dates
uid gid
• With Groups? Users
IsMemberOf
Groups

• But different users can join the name name

same group on different dates

fromDate
• With IsMemberOf!
 parent
Users
IsParentOf Parent (parent_uid, child_uid)
child

member
Users Groups
IsMemberOf

initiator
Member (uid, initiator_uid, gid)
 • Similar to the idea of subclasses in object-oriented
programming: subclass = special case, fewer entities, and
possibly more properties
• Represented as a triangle (direction is important)
• Example: paid users are users, but they also get avatars (yay!)

uid gid
Users Groups
IsMemberOf
name name
ISA fromDate
PaidUsers
avatar Automatically “inherits” key, attributes, relationships
 Entity-in-all-superclasses approach (“E/R style”)
• An entity is represented in the table for each subclass to which it
belongs
• A table includes only the attributes directly attached to the
corresponding entity set, plus the inherited key

uid gid
Users Groups
IsMemberOf Group (gid, name)
name name 〈142, Long〉 ∈ User (uid, name)
〈456, John〉
ISA fromDate
Member (uid, gid, from_date)
PaidUsers 〈456, ☺ 〉 ∈ PaidUser (uid, avatar)
avatar
 Entity-in-most-specific-class approach (“OO style”)
• An entity is only represented in one table (the most specific entity
set to which the entity belongs)
• A table includes the attributes attached to the corresponding entity
set, plus all inherited attributes
uid gid
Users Groups
IsMemberOf
name name
ISA Group (gid, name)
fromDate
〈142, Long〉 ∈ User (uid, name)
PaidUsers Member (uid, gid, from_date)
avatar
〈456, Ralph, ☺〉 ∈ PaidUser (uid, name, avatar)
All-entities-in-one-table approach (“NULL style”)
• One relation for the root entity set, with all attributes found in the network of
subclasses (plus a “type” attribute when needed)
• Use a special NULL value in columns that are not relevant for a particular entity

uid gid
Users Groups
IsMemberOf
name name
ISA fromDate
PaidUsers Group (gid, name)
avatar 〈142, Long , NULL〉 ∈
User (uid, name, avatar)
〈456, John, ☺ 〉
Member (uid, gid, from_date)
Thank you for your attention!