Database Design

Entity Relationship Model

Nguyễn Văn Diêu

Ho Chi Minh City University of Transport

2023

Kiến thức - Kỹ năng - Sáng tạo - Hội nhập

Sứ mệnh - Tầm nhìn
Triết lý Giáo dục - Giá trị cốt lõi
Outline I
1 Overview of the Design Process
2 ER Conceptual Model
A Sample Database Application
Entity
Relationship
Constraints of relationships
Patterns and Relationships
Summary of the notation
Database Example
3 ER Design Methodology
Example
4 Mapping to Relational Database
Mapping Entity
Mapping Relationship
Nguyễn Văn Diêu Table of Contents 2/80
Outline II

5 Weak Entity
Strong Entity
Weak entity and Identifying Relationship
Weak Entity connected Weak Entity
Update Methodology
Mapping Weak Entity to Rational Database
6 Extensions with Binary Relationships
Attributes of Relationship
M:N Relationship
More Entity and Relationship
7 Recursive Relationship
Structural Constraints
Multiple Relationship

Nguyễn Văn Diêu Table of Contents 3/80

Outline III

Mapping Recursive Relationship

8 Derived or Redundant Relationship

9 Enhanced EntityRelationship (EER) Model

Generalization and Specialization
Subclasses of Subclasses
Mapping rules
Union Types
Mapping rules

Nguyễn Văn Diêu Table of Contents 4/80

Main phases of Database design

Nguyễn Văn Diêu 1. Overview of the Design Process 5/80

Company Database sample
• The company is organized into departments. Each department has a unique
name, a unique number, and a particular employee who manages the department.
We keep track of the start date when that employee began managing the
department. A department may have several locations.
• A department controls a number of projects, each of which has a unique name, a
unique number, and a single location.
• The database will store each employee’s name, Social Security number, address,
salary, sex (gender), and birth date. An employee is assigned to one department,
but may work on several projects, which are not necessarily controlled by the same
department. It is required to keep track of the current number of hours per week
that an employee works on each project, as well as the direct supervisor of each
employee (who is another employee).
• The database will keep track of the dependents of each employee for insurance
purposes, including each dependent’s first name, sex, birth date, and relationship
to the employee.
Nguyễn Văn Diêu 2. ER Conceptual Model :: A Sample Database Application 6/80
ER Conceptual Model

• Entity: a thing or object in the real world with an independent existence.

• Attributes: Each entity has attributes — the particular properties that describe it
• Composite versus Simple (Atomic) Attributes
• Single-Valued versus Multivalued Attributes
• Stored versus Derived Attributes
• NULL Values
• Complex Attributes
• Key Attributes

Nguyễn Văn Diêu 2. ER Conceptual Model :: Entity 7/80

ER Conceptual Model

Nguyễn Văn Diêu 2. ER Conceptual Model :: Entity 8/80

ER Conceptual Model

Nguyễn Văn Diêu 2. ER Conceptual Model :: Entity 9/80

Relationship

• Relationship: Whenever an attribute of one entity type refers to another entity

type, some relationship exists.
• Degree of a Relationship: is the number of participating entity.
binary is degree two,
ternary is a degree three.
• Attributes of Relationship
• Recursive Relationships

Nguyễn Văn Diêu 2. ER Conceptual Model :: Relationship 10/80

Cardinality Ratio of a Relationship

• One-to-One (1:1) one entity is associated with one other entity and vice versa
• Many-to-One (M:1) many entity are associated with one another entity
• One-to-Many (1:M)
• Many-to-Many (M:N)
• Participation (Full/Partial)
Full (doube lines): All entity associated with another entity
Partial (single line): Not every entity associated with another entity

Nguyễn Văn Diêu 2. ER Conceptual Model :: Constraints of relationships 11/80

Pattern 1

1(full):1 Relationship

Nguyễn Văn Diêu 2. ER Conceptual Model :: Patterns and Relationships 12/80

Pattern 1

M(full):1 Relationship

Nguyễn Văn Diêu 2. ER Conceptual Model :: Patterns and Relationships 13/80

Pattern 2

1(partial):1 Relationship

Nguyễn Văn Diêu 2. ER Conceptual Model :: Patterns and Relationships 14/80

Pattern 2

M(partial):1 Relationship

Nguyễn Văn Diêu 2. ER Conceptual Model :: Patterns and Relationships 15/80

Pattern 3

1(full):M Relationship

Nguyễn Văn Diêu 2. ER Conceptual Model :: Patterns and Relationships 16/80

Pattern 3

M(full):N Relationship

Nguyễn Văn Diêu 2. ER Conceptual Model :: Patterns and Relationships 17/80

Pattern 4

1(partial):M Relationship

Nguyễn Văn Diêu 2. ER Conceptual Model :: Patterns and Relationships 18/80

Pattern 4

M(partial):N Relationship

Nguyễn Văn Diêu 2. ER Conceptual Model :: Patterns and Relationships 19/80

Summary of the notation for ER diagrams

Nguyễn Văn Diêu 2. ER Conceptual Model :: Summary of the notation 20/80

Summary of the notation for ER diagrams

Nguyễn Văn Diêu 2. ER Conceptual Model :: Summary of the notation 21/80

COMPANY database - Using Tool to draw ERD

Nguyễn Văn Diêu 2. ER Conceptual Model :: Database Example 22/80

ER Design Methodology

• Step 1. Select one primary entity from the database requirements description and
show attributes to be recorded for that entity. Label key if appropriate, and show
some sample data.
• Step 2. Use structured English for entities, attributes, and keys to describe the
database.
• Step 3. Examine attributes in the primary entity (possibly with user assistance)
to find out if information about one of the attributes is to be recorded.
• Step 3a. If information about an attribute is needed, then make the attribute an
entity, and then
• Step 3b. Define the relationship back to the original entity.
• Step 4. If another entity is appropriate, draw the second entity with its attributes.
Repeat step 2 to see if this entity should be further split into more entities.

Nguyễn Văn Diêu 3. ER Design Methodology 23/80

ER Design Methodology

• Step 5. Connect entities with relationships if relationships exist.

• Step 6. State the exact nature of the relationships in structured English from all
sides; for example, if a relationship is A:B::1:M, then there is a relationship from
A(1) to B(M) and from B(M) back to A(1).
• Step 7. Present the “as designed” database to the user complete with the English
for entities, attributes, keys, and relationships. Refine the diagram as necessary.
• Step 8. Show some sample data.

Nguyễn Văn Diêu 3. ER Design Methodology 24/80

Example

Consider a model for a simplified airport where PASSENGERS and FLIGHTS are to
be recorded. Suppose the attributes of PASSENGERS are name, luggage_pieces
and frequent_flier_no. Suppose the attributes for FLIGHT are flight_no,
destination, arrive_time and depart_time. Draw the ER diagram.
ER Design Methodology:
Step 1. Select one primary entity from the database requirements description and
show attributes to be recorded for that entity. Label keys if appropriate and show some
sample data.
Suppose we choose PASSENGERS as our primary entity. PASSENGERS has the
following attributes: frequent_flier_no, name [frst, middle, last], luggage_pieces.

Nguyễn Văn Diêu 3. ER Design Methodology :: Example 25/80

Example

Step 2. Use structured English for entities, attributes, and keys to describe the elicited
database.
Step 3. Examine attributes in the primary entity (possibly with user assistance) to find
out if information about one of the attributes is to be recorded.

Nguyễn Văn Diêu 3. ER Design Methodology :: Example 26/80

Example

Step 4. If another entity is appropriate,

draw the second entity with its attributes.
Repeat step 2 to see if this entity should be
further split into more entities.
Step 5. Connect entities with relationships
if relationships exist.

Nguyễn Văn Diêu 3. ER Design Methodology :: Example 27/80

Example

Step 6. State the exact nature of the relationships in structured English from all sides,
such as, if a relationship is A:B::1:M, then there is a relationship from A(1) to B(M)
and from B(M) back to A(1).
Step 7. Present the “as designed” database to the user complete with the English for
entities, attributes, keys, and relationships. Refine the diagram, as necessary.
Step 8. Show some sample data.

Nguyễn Văn Diêu 3. ER Design Methodology :: Example 28/80

Example

Nguyễn Văn Diêu 3. ER Design Methodology :: Example 29/80

Mapping Entity to Relation

Mapping rule 1: Mapping strong entities. Develop a new table (relation) for each
strong entity and make the indicated key of the strong entity the primary key of the
table. If more than one candidate key is indicated on the ER diagram, choose one for
the primary key. Call this table, TABLE1.
Mapping rule 2: Mapping atomic attributes. For entities with atomic attributes, map
the entities to a table and form columns for each atomic attribute. Here we’d map the
atomic attributes associated with TABLE1 into it.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Entity 30/80

Mapping Entity to Relation

STUDENT(name, phone, school, address, major)

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Entity 31/80

Mapping Entity to Relation

Mapping rule 3: Mapping composite attributes. For entities with composite

attributes, map entities to a table and form columns of each elementary (atomic) part
of the composite attributes.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Entity 32/80

Mapping Entity to Relation

STUDENT(name.first, name.mid, name.last, school, address)

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Entity 33/80
Mapping Entity to Relation

Mapping rule 4: Mapping multivalued attributes. Form a separate table for the
multivalued attribute. Record a row for each value of the multivalued attribute
together with the key from the original table. The key of the new table will be the
concatenation of the multivalued attribute plus the key of the owner entity. Remove
the multivalued attribute from the original table.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Entity 34/80

Mapping Entity to Relation

STUDENT(student_number, name.first, name.mid, name.last, address)

STUDENT_SCHOOL(student_number, school)
Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Entity 35/80
Mapping Relationship to Relation

Mapping rule 5: Mapping binary M:N relationships. For each M:N relationship,
create a new table (relation) with the primary keys of each of the two entities (owner
entities) related in the M:N relationship. The primary key of this new table will be the
concatenated keys of the owner entities. Include any attributes the M:N relationship
may have in this new table.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 36/80

Mapping Relationship to Relation

STUDENT(student_number, name.first, name.mid, name.last, address)

COURSE(c_number, cname, credit_hrs)
ENROLL(student_number, c_number)
Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 37/80
Mapping Relationship to Relation

Mapping rule 6: Mapping a binary 1:1 relationship when one side of the relationship
has full participation and the other has partial participation. When one of the sides of
the relationship has full participation and the other has partial participation, then store
the primary key of the side with the partial participation constraint on the side with
the full participation constraint as a foreign key. Include any attributes on the
relationship on the same side to which the key was added.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 38/80

Mapping Relationship to Relation

AUTOMOBILE(vehicle_id, make,
body_style, color, year,
student_number)
STUDENT(student_number,
name.first, name.mid,
name.last, address)

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 39/80

Mapping Relationship to Relation

Mapping rule 7: Mapping a binary 1:1 relationship when both sides have partial
participation constraints.
When both sides have partial participation constraints in a binary 1:1 relationship, the
relationships can be mapped in one of two ways.
Mapping rule 7A: Select either one of the relations to store the key of the other.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 40/80

Mapping Relationship to Relation

AUTOMOBILE( vehicle_id, make,

body_style, color, year)
STUDENT(student_number,
name.first, name.mid,
name.last, address,
vehicle_id)

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 41/80

Mapping Relationship to Relation

Mapping rule 7B:. Depending on the semantics of the situation, you can create a
new relation to house the relationship to contain the key of the two related entities.

AUTOMOBILE( vehicle_id, make, body_style, color, year)

STUDENT(student_number, name.first, name.mid, name.last, address)
STUDENT_AUTOMOBILE(student_number, vehicle_id)

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 42/80

Mapping Relationship to Relation

Mapping rule 8: Mapping a binary 1:1 relationship when both sides have full
participation constraints. Use the semantics of the relationship to select which of the
relations should contain the key of the other. If this choice is unclear, then use
mapping rule 7B.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 43/80

Mapping Relationship to Relation

Mapping rule 9: Mapping binary 1:N relationships when the N side has full
participation. Include the key of the entity on the 1 side of the relationship as a foreign
key on the N side.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 44/80

Mapping Relationship to Relation

if we assume full participation on the

student side, we will have:
• Dorm rooms may have zero or more
students.
• Student must live in only and only
one dorm room.
STUDENT(student_number,
name.first, name.mid,
name.last, address,
dname)
DORM(dname, superviser)

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 45/80

Mapping Relationship to Relation

Mapping rule 10: Mapping binary 1:N relationships when the N side has partial
participation. This situation would be handled just like a binary M:N relationship with
a separate table for the relationship. The key of the new relation would consist of a
concatenation of the keys of the related entities. Include any attributes on the
relationship on this new table.

Nguyễn Văn Diêu 4. Mapping to Relational Database :: Mapping Relationship 46/80

Strong Entity

Strong entities almost always have a unique identifer that is a subset of all the
attributes.
e.g.

Nguyễn Văn Diêu 5. Weak Entity :: Strong Entity 47/80

Strong Entity

Sample data:

Nguyễn Văn Diêu 5. Weak Entity :: Strong Entity 48/80

Weak Entity

A weak entity clearly will be an entity but

will depend on another entity for its
existence.
A weak entity will not necessarily have a
unique identifer.
• Te attribute dname is a Partial Key.
• Underlined dname with dashes.

Nguyễn Văn Diêu 5. Weak Entity :: Weak entity and Identifying Relationship 49/80
Weak Entity

• The automobile is identifed by the

owner.
• Double diamond on the owns
relationship and the full participation
of the AUTOMOBILE entity in the
owns relationship.
• All automobiles are driven by some
employee.

Nguyễn Văn Diêu 5. Weak Entity :: Weak entity and Identifying Relationship 50/80
Weak Entity - Weak Entity

• Entity EMPLOYEE is the owner of

the weak entity DEPENDENT
• Weak Entity DEPENDENT is the
owner of the weak entity HOBBY

Nguyễn Văn Diêu 5. Weak Entity :: Weak Entity connected Weak Entity 51/80
Methodology (+ Weak Entity)

Step 3. Examine attributes in the primary entity (possibly with user assistance) to find
out if information about one of the attributes is to be recorded.
Step 3a. If information about an attribute is needed, then make the attribute an
entity, and then
Step 3b. Define the relationship back to the original entity.
So, we add
Step 3c. If the new entity depends entirely on another entity for its existence, then
draw the entity as weak (double boxed) and show the connection to the identifying
entity as a double diamond. The participation of the weak entity in the relationship is
full. Dash underline the partial key identifier(s) in the weak entity.

Nguyễn Văn Diêu 5. Weak Entity :: Update Methodology 52/80

Methodology (+ Weak Entity)

Step 4. If another entity is appropriate, draw the second entity with its attributes.
Repeat step 2 to see if any attributes should be further split into more entities.
Step 4a. If the additional entity or entities do not have candidate keys, then draw
them as weak entities (as explained in step 3c) and show the connection to an
identifying entity. The participation of the weak entity in the relationship is full or
mandatory. Dash or dot underline the partial key identifier(s) in the weak entity.

Nguyễn Văn Diêu 5. Weak Entity :: Update Methodology 53/80

Mapping Weak Entity to Relational DB

Mapping Rule 11: Mapping weak entities. Develop a new table (relation) for each
weak entity. As is the case with the strong entity, include any atomic attributes from
the weak entity in the table.
If there is a composite attribute, include only the atomic parts of the composite
attribute and be sure to qualify the atomic parts in order not to lose information. To
relate the weak entity to its owner, include the primary key of the owner entity in the
weak relation. The primary key of the weak relation will be the partial key of the weak
entity concatenated to the primary key of the owner entity.
If a weak entity owns other weak entities, then the weak entity connected to the strong
entity must be mapped first. The key of the weak owner-entity has to be defined
before the “weaker” entity (the one furthest from the strong entity) can be mapped.

Nguyễn Văn Diêu 5. Weak Entity :: Mapping Weak Entity to Rational Database 54/80
Mapping

EMPLOYEE(employee_id, fname,
minit, lname)
DEPENDENT(employee_id, dname,
insurance, birth_date)
HOBBY(employee_id, dname, type,
year_involved)

Nguyễn Văn Diêu 5. Weak Entity :: Mapping Weak Entity to Rational Database 55/80
Attributes of Relationship

Relationship attributes may occur

with an ER diagram containing
any cardinality, but one will most
often find relationship attributes in
the binary, M:N model.

Nguyễn Văn Diêu 6. Extensions with Binary Relationships :: Attributes of Relationship 56/80
Change M:N Relationship

Change to:
• Intersection Weak Entity:
STUDENT-COURSE
• Attribute: grade
• Key: student_ID +
course_ID
• Relationship 1: Rel1
• Relationship 2: Rel2

Nguyễn Văn Diêu 6. Extensions with Binary Relationships :: M:N Relationship 57/80
More Entity and Relationship

Update Methodology:
Step 4. If another entity is appropriate, draw the second entity with its attributes.
Repeat step 2 to see if this entity should be further split into more entities.
Step 5. Connect entities with relationships (one or more) if relationships exist.

Nguyễn Văn Diêu 6. Extensions with Binary Relationships :: More Entity and Relationship 58/80
More Entity and Relationship

Te relationship between
INSTRUCTOR and COURSE is
teach; instructors teach many
courses, and a course is taught by
an instructor.
We add relationship teach.

Nguyễn Văn Diêu 6. Extensions with Binary Relationships :: More Entity and Relationship 59/80
More Entity and Relationship

Nguyễn Văn Diêu 6. Extensions with Binary Relationships :: More Entity and Relationship 60/80
Recursive Relationship

• An employee may supervise

many other employees
• Many employees having one
supervisor

Nguyễn Văn Diêu 7. Recursive Relationship 61/80

One to One Recursive Relationship

e.g.

Nguyễn Văn Diêu 7. Recursive Relationship :: Structural Constraints 62/80

One to Many Recursive Relationship

e.g.

Nguyễn Văn Diêu 7. Recursive Relationship :: Structural Constraints 63/80

Many to Many Recursive Relationship

e.g.

Nguyễn Văn Diêu 7. Recursive Relationship :: Structural Constraints 64/80

Multiple Relationship

e.g.

Nguyễn Văn Diêu 7. Recursive Relationship :: Multiple Relationship 65/80

Mapping Recursive Relationship

Mapping Rule 12: Mapping 1:N recursive relationships. Re-include the primary key of
the table with the recursive relationship in the same table, giving it some other role
name.
e.g.
PERSONNELL(emplye_id, fname, mname, lname, super_id)
Mapping Rule 13: Mapping M:N recursive relationships. Create a separate table for
the relationship (as in mapping rule 5).

Nguyễn Văn Diêu 7. Recursive Relationship :: Mapping Recursive Relationship 66/80

Derived or Redundant Relationship

• Students take courses

• Each course is taught by an
instructor
• We do not need a taught_by
relationship

Nguyễn Văn Diêu 8. Derived or Redundant Relationship 67/80

Generalization or Specialization

• Generalization: Super Class

• Specialization: Sub Class
Constraints: There are two types of constraints on the “Sub-class” relationship.
• Overlapping: Superclass entity may contain more than one subclass
• Disjoint: Superclass entity may be a member of only one of the subclasses

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Generalization and Specialization 68/80
Generalization or Specialization

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Generalization and Specialization 69/80
Generalization or Specialization

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Generalization and Specialization 70/80
Subclasses of Subclasses

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Subclasses of Subclasses 71/80
Subclasses of Subclasses

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Subclasses of Subclasses 72/80
Mapping rules to Relation

• Generalization: New Relation

• Specialization: New Relation with Primary key of Generalization

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Mapping rules 73/80
Union Types

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Union Types 74/80
Union Types

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Union Types 75/80
Union Types

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Union Types 76/80
Union Types

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Union Types 77/80
Union Types

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Union Types 78/80
Union Types

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Union Types 79/80
Mapping rules to Relation

Generalizations have the same primary keys

• Generalizations: New Relations
• Specialization: New Relation with the same Primary key of Generalization

Generalizations have diferent primary keys

• Generalizations: New Relations with foreign key to be PK of specialization
• Specialization: New Relation with

Nguyễn Văn Diêu 9. Enhanced EntityRelationship (EER) Model :: Mapping rules 80/80