Mapping ERD to Tables
Instructor: Amna Ikram
Email:
[email protected] Basic rule for converting the ER diagrams
into tables
Converting Strong Entity Types:
• Convert all the Entities in the diagram to tables.
• All single valued attributes of an entity is converted to a column of
the table.
• Key attribute in the ER diagram becomes the Primary key of the
table.
• Declare the foreign key column, if applicable.
• Any multi-valued attributes are converted into new table.
• Any composite attributes are merged into same table as different
columns.
• Derived attributes can be ignored, since it can be calculated at any
time.
Entity example:
• Here address is a composite attribute
• Years of service is a derived attribute (can be calculated from date
of joining and current date)
• Skill set is a multi-valued attribute
• The relational Schema
• Employee (E#, Name, Door_No, Street, City, Pincode,
Date_Of_Joining)
• Emp_Skillset( E#, Skillset)
Entity Example (Contd…)
ERD Example
Consider the ER diagram below and will see how it is converted into
tables, columns and mappings.
ERD Example
Table structure
Converting Weak Entity Types
• Weak entity types are converted into a table of their own, with the
primary key of the strong entity acting as a foreign key in the table.
• This foreign key along with the key of the weak entity form the composite
primary key of this table.
• The Relational Schema
• Employee (E# ,…….)
• Dependant (Employee, Dependant_ID, Name, Address)
Converting weak entity types (Cont…)
Composite Attributes to Tables
• Composite attributes are flattened out by creating
a separate attribute for each component attribute
EmpNo
EmpNo
FirstName
FirstName
Employee
Employee
Name
Name
MidName
MidName
ID
ID
LastName
LastName
Given
Givenananentity
entityset
setcustomer
customerwith
withcomposite
compositeattribute
attributename
namewith
withcomponent
componentattributes
attributes
first-name
first-nameand
andlast-name
last-namethe
thetable
tablecorresponding
correspondingtotothe
theentity
entityset
sethas
hasthree
threeattributes:
attributes:
name-FirstName,
name-FirstName,name-MidName
name-MidName and andname-LastName
name-LastName
9
Multi-valued Attributes to Tables
• A multivalued attribute M of an entity E is represented by a separate table
EM
• Table EM has attributes corresponding to the primary key of E and an
attribute corresponding to multivalued attribute M
– E.g. Multivalued attribute PhoneNo of employee is represented by a table
employee-PhoneNo( employee-id, PhoneNo)
– Each value of the multivalued attribute maps to a separate row of the table
EM
• E.g., An employee entity with primary key 151 and telephone numbers 9241456
and 9245467 maps to two rows:
Employee-id PhoneNo
151 9241456
151 9245467
10
Converting relationships
• The way relationships are represented
depends on the cardinality and the degree of
the relationship
• The possible cardinalities are:
– 1:1, 1:M, M:M
• The degrees are:
– Unary
– Binary
– Ternary …
1:1 relationship
• Case 1: Combination of participation types
• The primary key of the partial participant will become the
foreign key of the total participant
1:1 relationship
• Case 2: Uniform participation types
• The primary key of either of the participants
can become a foreign key in the other.
1:M relationship
• The primary key of the relation on the “1” side
of the relationship becomes a foreign key in
the relation on the “M” side.
M:M Relationship
Self referencing
• The primary key field itself will become foreign
key in the same table.
Self referencing M:N
• There will be two resulting tables. One to
represent the entity and another to represent
the M:N relationship as follows.
Ternary relationship
• Represented by a new table
• The new table contains three foreign keys - one from each of the
participating Entities.
• The primary key of the new table is the combination of all three foreign
keys.
Representing Generalization
Method I
• Form a table for the higher level entity
• Form a table for each lower level entity set,
include primary key of higher level entity set
and local attributes
Table Table Attributes
account account-number, balance
savings-account account-number, interest rate
checking-account account-number, overdraft-amount
Representing Generalization
Method II
• If generalization is disjoint and complete
• Do NOT create a table for the high level entity set
• Form a table for each lower level entity set, and
include each attribute of higher level entity set
Table Table Attributes
savings-account account-number, balance, interest rate
checking-account account-number, balance, overdraft-amount
Representing Generalization
Question 1
What
Whatififthe
thegeneralization
generalizationwas
wasoverlapping
overlappingand
andnot
notdisjoint?
disjoint?
Answer
Some
Somevalues
valueslike
likebalance
balancewould
wouldbe
bestored
storedtwice
twiceunnecessarily
unnecessarily
Representing Generalization
Question 2
What
Whatififthe
thegeneralization
generalizationwere
werenot
notcomplete
complete
Answer
The
Theaccounts
accountswhich
whichare
areneither
neithersavings
savingsnor
norchecking
checkingcould
couldnot
notbe
berepresented
representedinin
the
thedatabase
database
