Mapping an ERD to a
Relational Database
To map an ERD to a relational database, five rules are
defined to govern how tables are constructed.
1) Rule for entity types
2) Rule for relationships
3) Rule for attributes
4) Rule for generalization/specialization hierarchies
(will not be discussed in this course)
5) Rule for participation constraint
1. Entities
Each entity set is implemented with a separate relation.
a. Strong Entities
Strong, or regular, entities are mapped to their own
relation.
The PK (Primary Key) is chosen from the set of keys
available.
Example: Strong Entities
d
c
A
e
A
c d e
1. Entities
Each entity set is implemented with a separate relation.
b. Weak Entities
Weak entities are mapped to their own relation
The PK of the weak entity is the combination of the PKs
of entities related through identifying relationships and
the discriminator (partial key) of the weak entity.
Example: Weak Entities
d
c
e
A
B
c x y
B
x
y
2. Relationships
We’ll consider binary relationships only
All relationships involve the use of foreign keys: the PK
attribute of one entity set is added as an attribute to the
relation representing the other entity set
a. Binary One-To-One
In general, with a one-to-one relationship, you have a
choice regarding where to implement the relationship.
You may choose to place a foreign key in one of the two
relations, or in both.
Example: 1-1
d
c
e
c is a FK
in B
A
1
B
x y c
1
B
x
y
Example: 1-1
d
c
e
X is a FK
in A
A
1
A
c …X
1
B
x
y
If the participation constraint on an entity set is mandatory,
we must choose the table for that entity set.
d
c
e
X is a FK
in B
A
1
A
c …X
1
B
x
y
2. Relationships
b. Binary One-To-Many
With a one-to-many relationship you must place a foreign
key in the relation corresponding to the many side of the
relationship.
Example: 1-n
d
c
e
c is a FK
placed on
the “many”
side of the
relationship
A
1
B
n
x y c
B
x
y
Example: 1-n
d
c
e
s is also
involved in
the table
A
1
s
B
n
x y c s
B
x
y
2. Relationships
c. Binary Many-To-Many
A many-to-many relationship must be implemented with
a separate relation for the relationship. This new relation
will have a composite primary key comprising the
primary keys of the participating entity sets plus any
discriminator attribute.
Example: m-n
d
c
e
A
AB
m
s
x c s
n
B
x
x and c are FKs,
and together they
form the PK of AB
y
3. Attributes
All attributes, with the exception of derived and
composite attributes, must appear in relations.
a. Simple, atomic
These are included in the relation created for the pertinent
entity set, many-to-many relationship, or n-ary
relationship.
Example: Atomic Attributes
d
c
A
e
A
c d e
3. Attributes
b. Multi-valued
Each multi-valued attribute is implemented using a new
relation. This relation will include the primary key of the
original entity set. The primary key of the new relation
will be the primary key of the original entity set and the
multi-valued attribute. Note that in this new relation, the
attribute is no longer multi-valued.
Example: Multi-valued Attributes
d
c
A
e
A
e is a multi-valued attribute.
AE
c d
c e
3. Attributes
c. Composite
Composite attributes are not included. However the
atomic attributes comprising the composite attribute must
appear in the pertinent relation.
Example: Composite Attributes
d
c
e
n
A
A
c d e
4. Generalization/Specialization Hierarchies
91.2914 can ignore this section
5. Participation constraints
If a relationship is mandatory for an entity set, then
if the entity set is on the “many” side of the
relationship, then a specification is required to ensure
a foreign key has a value, and that it cannot be null
•setting the ‘required’ property for the FK in MS
Access (91.2914 should know how to do this), or
•NOT NULL constraint in the DDL.
d
A
y
x
1
N
c
B
A
B
c d
x y c
The “required” property for attribute c
is set “yes”.
Setting the required
property to Yes
5. Participation constraints
Otherwise, if the entity set is on the “one” side of a
relationship, then a check constraint or database
trigger can be specified to ensure compliance.
d
A
y
x
1
N
c
B
A
B
c d
x y c
A program should be produced to check that any value
appearing in c-column in table A must appear at least
once in c-column in table B.
Example
The company database keeps track of a company’s
employees, departments, and projects:
Requirements:
concerning the department:
1.
2.
3.
4.
5.
company is organized into departments
a department has a unique name, a unique number, and a specific
employee is its’ manager
we track the start date for the manager function
a department may be in several locations
a department controls a number of projects
concerning the project:
6.
a project has a unique name, a unique number, and is in a single
location
example continued
concerning the employee:
7.
each employee has a name, social insurance number,
address, salary, sex, and birth date
8. an employee is assigned to one department but may work on several
projects which are not necessarily controlled by the same department
9. we track the number of hours per week that an employee works on
each project
10. we keep track of the direct supervisor of each employee
11. we track the dependents of each employee (for insurance purposes)
concerning the dependent:
12. we record each dependent’s first name, sex, birth date,
and relationship to the employee
The entities:
employee
department
project
dependent
The entities:
fname
minit
lname
name
sex
ssn
address
dependent
salary
name
employee
sex
birthdate
relationship
bdate
name number
location
department
project
name number
location
With relationships:
1
N
department
works for
1
1
employee
supervisee
1
supervision
1
controls
N
supervisor
N
manages
N
M
works on
1
project
dependents of
N
dependent
partial constraint
total constraint
name number
fname
name
ssn
minit
sex
1
lname
address
salary
startdate
employee
1
1
1
N hours
supervisee
N
M
1
works on
supervision
dependents of
N
dependent
sex
number of
employees
controls
manages
supervisor
name
department
works for
N
bdate
degree
location
birthdate relationship
project
name number
location
Summary
1.Entities
a. Each entity set is implemented with a separate relation.
b.Weak Entities
Weak entities are mapped to their own relation
The PK of the weak entity is the combination of the PKs
of entities related through identifying relationships and
the discriminator (partial key) of the weak entity;
2. All relationships involve foreign keys. If the relationship
is identifying then the primary key of the strong entity
must be propagated to the relation representing the weak
entity.
a. Binary One-To-One
In general, with a one-to-one relationship, you have
a choice regarding where to implement the
relationship. You may choose to place a foreign key
in one of the two relations, or in both.
b. Binary One-To-Many
With a one-to-many relationship you must place the
foreign key in the relation corresponding to the many
side of the relationship.
c. Binary Many-To-Many
A many-to-many relationship must be implemented with
a separate relation for the relationship. This new relation
will have a composite primary key comprising the
primary keys of the participating entity sets plus any
discriminator attribute.
d. n-ary, n>2
new relation is generated for the n-ary relationship.
This new relation will have a composite primary key
comprising the primary keys of the participating entity
sets plus any discriminator attribute. If the cardinality
related for any entity set is 1, then the primary key of
that entity set is only included as a foreign key and not
as part of the primary key of the new relation.
3. Attributes
a. Simple, atomic
These are included in the relation created for the
pertinent entity set, many-to-many relationship, or n-ary
relationship.
b. Multi-Valued
A multi-valued attribute is implemented using a new
relation. This relation will include the primary key of the
entity set. The primary key of the new relation will be
the primary key of the entity set and the multi-valued
attribute. Note that in this relation, the attribute is no
longer multi-valued.
c. Composite
Composite attributes must be replaced by their equivalent
atomic attributes in the pertinent relation.
4. Generalization/Specialization Hierarchies
There are several options available for this case …
(ignore for 91.2914)
5. Participation constraints.
If a relationship is mandatory for an entity set, then
if the entity set is on the “many” side of the relationship,
a specification is required (a NOT NULL constraint)
to ensure a foreign key has a value, and that it cannot be
null.
If the entity set is on the “one” side of a relationship, then
that “one” side will be chosen as the primary table and
the other is chosen as the referenced table. A NOT NULL
constraint for the foreign key should be specified.