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.

A

Example: Strong Entities

A

cd

e 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.

B

Example: Weak Entities

A

cd

e

c x yB

xy

2. Relationships

We’ll consider binary relationships only

All relationships involve the use of foreign keys: the PKattribute of one entity set is added as an attribute to therelation representing the other entity set

a.   Binary One-To-One

In general, with a one-to-one relationship, you have achoice regarding where to implement the relationship.You may choose to place a foreign key in one of the tworelations, or in both.

B

1

1

Example: 1-1

A

cd

e

x y cB

xy

c is a FK in B

A

1

1

Example: 1-1

A

cd

e

c … XB

xy

X is a FK in A

A1

1

If the participation constraint on an entity set is mandatory, we must choose the table for that entity set.

A

cd

e

c … XB

xy

X is a FK in B

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

A

cd

e

x y c

B

B

xy

1

n

c is a FK placed on the “many” side of the relationship

Example: 1-n

A

cd

e

x y

B

cB

xy

1

n

s is also involved in the table

s

s

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

A

cd

e

x c s

AB

B

xy

m

n

x and c are FKs, and together they form the PK of AB

s

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.

A

Example: Atomic Attributes

A

cd

e 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

A

cd

e c d

A

c e

AE

e is a multi-valued attribute.

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

cd e

c d e

A

A

n

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.

N

A

c d

B

x y

1

c d

A

x y c

B

The “required” property for attribute cis 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.

N

A

c d

B

x y

1

c d

A

x y c

B

A program should be produced to check that any valueappearing in c-column in table A must appear at leastonce 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. company is organized into departments2. a department has a unique name, a unique number, and a specific

employee is its’ manager3. we track the start date for the manager function4. a department may be in several locations5. 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 date8. an employee is assigned to one department but may work on several

projects which are not necessarily controlled by the same department9. we track the number of hours per week that an employee works on

each project10. we keep track of the direct supervisor of each employee11. 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:

bdate

ssn

name

lnameminitfname

sex address salary

birthdatename sex relationship

name number location

name number location

employee

department

project

dependent

With relationships:

employee

department

project

dependent

works for

manages

works on

dependents of

controls

supervision 1

N

N

1N M

1

N

1

1

N

1

supervisorsupervisee

partial constrainttotal constraint

employee

department

project

dependent

works for

manages

works on

dependents of

controls

supervision

bdate

ssn

name

lnameminitfname

sex address salary

birthdatename sex relationship

name number location

name number

number ofemployeesstartdate

hours

1

1

1

N

supervisorsupervisee

M

N

11

NNdegree

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 relationshipis identifying then the primary key of the strong entitymust be propagated to the relation representing the weakentity.a. Binary One-To-One

In general, with a one-to-one relationship, you havea choice regarding where to implement therelationship. You may choose to place a foreign keyin one of the two relations, or in both.

b. Binary One-To-Many With a one-to-many relationship you must place theforeign key in the relation corresponding to the manyside of the relationship.

c. Binary Many-To-Many A many-to-many relationship must be implemented witha separate relation for the relationship. This new relationwill have a composite primary key comprising theprimary keys of the participating entity sets plus anydiscriminator attribute.

d. n-ary, n>2 new relation is generated for the n-ary relationship.This new relation will have a composite primary keycomprising the primary keys of the participating entitysets plus any discriminator attribute. If the cardinalityrelated for any entity set is 1, then the primary key ofthat entity set is only included as a foreign key and notas part of the primary key of the new relation.

3. Attributesa. Simple, atomicThese are included in the relation created for thepertinent entity set, many-to-many relationship, or n-aryrelationship.b. Multi-Valued A multi-valued attribute is implemented using a newrelation. This relation will include the primary key of theentity set. The primary key of the new relation will bethe primary key of the entity set and the multi-valuedattribute. Note that in this relation, the attribute is nolonger multi-valued.c. CompositeComposite attributes must be replaced by their equivalentatomic attributes in the pertinent relation.

4. Generalization/Specialization HierarchiesThere 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 benull.

 If the entity set is on the “one” side of a relationship, thenthat “one” side will be chosen as the primary table andthe other is chosen as the referenced table. A NOT NULLconstraint for the foreign key should be specified.