Chapter 6
Mapping E-R Diagrams /EERD
to Relational Schemas
Introduction
E-R model : the database represented is
viewed as a graphical drawings of:
Entities and attributes
Relationships among those entities
- not tables
Relational model: the database is viewed as a
Tables
And their attributes (keys)
E-R Diagrams
Need to convert E-R diagrams to an
implementation schema.
Easy to map E-R diagrams to relational model,
and then to SQL.
Three components of conversion process:
Specify schema of relation itself
Specify primary key on the relation
Specify any foreign key references to other
relations
Strong entity
Each entity type becomes a table.
Each single-valued attribute becomes a
column
Derived attributes are ignored
Composite attributes are represented by
components
Multi-valued attributes are represented by a
separate table
The key attribute of the entity type becomes
the primary key of the table
Example 1: single value
attribute
Example 2
Composite attribute – attribute which
can be broken into few attribute
Relational model doesn’t handle composite
attributes
When mapping E-R composite attributes to relation
schema:
–Each component attribute maps to a separate
attribute in relation schema
–In relation schema, simply can’t refer to composite
as a whole
Composite attribute - example
Multivalued attribute
Multivalued attributes require a separate
relation schema
No such thing as a multivalued attribute in
relational model
For multivalued attribute M in entity-set E
Create a relation schema R to store M, with few
attribute A corresponding to M
A is single-valued version of M
Attributes of R are: A and primary key for E
Primary key of R includes all attributes of R
Foreign key constraint from R to E, is the
primary key of E attribute
Multivalued attribute -
Example
Relationship-set Primary key (1)
For binary relationship-sets:
e.g. between strong entity-sets A and B
For one-to-one relationship mapping, one
relation will include the primary key from the
other relation as FK or vice versa.
A (a1, a2, a3, b1), B (b1, b2, b3, b4) OR
b1 is the FK for the relation A
A (a1, a2, a3). B (b1, b2, b3, b4, a1)
a1 is the FK for the relation B
Selection of Foreign key in 1:1 relationship
Case ER Relationship Constraints Action
I One side is mandatory and the Place the PK of the entity on the mandatory
other side is optional. side in the entity on the optional side as a FK
and make the FK mandatory.
II Both sides are optional. Select the FK that causes the fewest number of
nulls or place the FK in the entity in which the
(relationship) role is played.
III Both sides are mandatory. See Case II or consider revising your model to
ensure that the two entities do not belong
together in a single entity.
Relationship-set Primary key (2)
For many-to-one or one-to-many mappings:
e.g. between strong entity-sets A and B
Primary key from one side relation schema will
become the FK of the many side relation.
Example: relationship R between A and B
One-to-many mapping, with B on “many” side
Schema for A will be A (a1, a2, a3, a4, a5)
Schema for B will be B (b1, b2, b3, b4, a1)
Relationship-set Primary key (2)
For many-to-many relationship, need to create a
separate entity (called associative entity), and this
entity will has attributes which are the PK from the
two participating entities.
For example:
A (a1, a2, a3, a4)
B (b1, b2, b3, b4, b5)
C (a1, b1)
The extra attribute of the C, is the single value
attribute of C (not the primary key)
Relational-set : Example
Summary of Mapping constructs and constraints
Correspondence between ER and Relational Models
ER Model Relational Model
Entity type “Entity” relation
1:1 or 1:N relationship type Foreign key (or “relationship” relation)
M:N relationship type “Relationship” relation and two foreign keys
n-ary relationship type “Relationship” relation and n foreign keys
Simple attribute Attribute
Composite attribute Set of simple component attributes
Multivalued attribute Relation and foreign key
Value set Domain
Key attribute Primary (or secondary) key
Step 8: Mapping EEER Model Constructs
to Relations
Options for Mapping Specialization or Generalization.
Using one of the four following options:
Option A: Multiple relations-Superclass and
subclasses
Option B: Multiple relations-Subclass relations
only
Option C: Single relation with one type attribute
Option D: Single relation with multiple type
attributes
Mapping EEER Model Constructs to
Relations
Option A: Multiple relations-Superclass and
subclasses
Create relation for superclass and subclasses.
The primary key of superclass with be the primary key of
each subclasses.
This option works for any specialization (total or partial,
disjoint of over-lapping).
FIGURE 4.4
EER diagram notation for an attribute-defined specialization on
JobType.
FIGURE 7.4
Options for mapping specialization or generalization.
(a) Mapping the EER schema in Figure 4.4 using option A.
Mapping EERD to relations
Option B: Multiple relations-Subclass relations
only
Create a relation for each subclass where the
attributes of the superclass with the attributes of
the subclasses added with the attributes of each
subclass
Primary key of the superclass will be the primary key
of each subclasses
This option only works for a specialization whose
subclasses are total (every entity in the superclass
must belong to (at least) one of the subclasses).
FIGURE 4.3
Generalization. (b) Generalizing CAR and TRUCK into
the superclass VEHICLE.
FIGURE 7.4
Options for mapping specialization or generalization.
(b) Mapping the EER schema in Figure 4.3b using option 8B.
Tonnage
Mapping EER Model Constructs to Relations (contd.)
Option C: Single relation with one type attribute
Create one single relation with all the attributes from
superclass and subclass
Added a single attribute indicates the subclass to which each
tuple belongs
The attribute t is called a type (or discriminating) attribute
that indicates the subclass to which each tuple belongs
Option D: Single relation with multiple type attributes
Create a single relation with the attributes from superclass
and subclasses.
Added multiple type attributes with Boolean data type which
indicating whether a tuple belongs to the subclass.
FIGURE 4.4
EER diagram notation for an attribute-defined specialization on JobType.
FIGURE 7.4
Options for mapping specialization or generalization.
(c) Mapping the EER schema in Figure 4.4
using option C.
EngType
Slid
e 7-
27
FIGURE 4.5
EER diagram notation for an overlapping (non-disjoint)
specialization.
FIGURE 7.4
Options for mapping specialization or generalization.
(d) Mapping Figure 4.5 using option D with Boolean type fields Mflag and
Pflag.
Slid
e 7-
29
Mapping EER Model Constructs to
Relations (contd.)
Mapping of Shared Subclasses (Multiple Inheritance)
A shared subclass, such as STUDENT_ASSISTANT, is a
subclass of several classes, indicating multiple
inheritance. These classes must all have the same key
attribute; otherwise, the shared subclass would be
modeled as a category.
We can apply any of the options discussed in Step 8 to
a shared subclass, subject to the restriction discussed
in Step 8 of the mapping algorithm. Below both 8C and
8D are used for the shared class STUDENT_ASSISTANT.
Slid
e 7-
30
FIGURE 4.7
A specialization lattice with multiple inheritance for a UNIVERSITY
database.
FIGURE 7.5
Mapping the EER specialization lattice in Figure 4.6 using multiple
options.
Slid
e 7-
32
Chapter Summary
ER-to-Relational Mapping Algorithm
Step 1: Mapping of Regular Entity Types
Step 2: Mapping of Weak Entity Types
Step 3: Mapping of Binary 1:1 Relation Types
Step 4: Mapping of Binary 1:N Relationship Types.
Step 5: Mapping of Binary M:N Relationship Types.
Step 6: Mapping of Multivalued attributes.
Step 7: Mapping of N-ary Relationship Types.
Mapping EER Model Constructs to Relations
Step 8: Options for Mapping Specialization or
Generalization.
Step 9: Mapping of Union Types (Categories).
Exercises…
