Modern Database Management

Thirteenth Edition, Global Edition

Chapter 4
Logical Database Design and
the Relational Model

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Learning Objectives
4.1 Define terms
4.2 Properties of relations
4.3 Transforming EER diagrams into relations
4.4 Introduction to normalization
4.5 Define first, second, and third normal form
4.6 Convert to first, second and third normal form

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Logical Database Design
• A process of transforming conceptual data model into logical data
model
• Logical database design is about the creation of database structure
for a relational data model which is commonly known as a relation

Customer-ID Customer Name

C-1234 Samuel

C-2345 Smith

Order-ID Customer-ID Quantity

O-3421 C-1234 100

O-4327 C-2345 432

O-8967 C-1234 765

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Components of Relational Data Model
• Data structure
– Data are organized in the form of tables (relations) with rows and
columns
Student-ID Student-Name Gender

B-B9-0134-0 Vendi Sally Female

B-B9-1265-9 Donald Duarte Male

• Data integrity
– Mechanisms for implementing business rules that maintain integrity of
manipulated data
▪ Domain constraints: all of the values in a column must be from the
same domain
▪ Entity integrity: ensure every record which has a key field and the
data value for that key field must be valid
• Data manipulation
– Powerful SQL operations for retrieving and modifying data

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Relation
• A relation is a two-dimensional table.
• Consists of rows (records) and columns (attributes or fields)
• Requirements(properties) for a table to qualify as a relation:
– It must have a unique name.
– Every row must be unique.
– Attributes (columns) in tables must have unique names.

Product table
ProductID Name Price Quantity

P-0111 Marker 13.00 100.00

P-0222 Ball pen 5.00 50.00

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Key Fields
• Keys include: slide 7
– Primary keys are unique identifiers of the relation.
Examples include employee numbers, social security
numbers, etc. This guarantees that all rows are unique.
– Foreign keys are identifiers that enable a dependent
table (on the many side of a relationship) to refer to its
parent table (on the one side of the relationship).
• Keys can be simple (a single field) or composite (more than
one field).

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Primary Key Field and Foreign Key Field
Employee table
EmployeeID EmployeeName Salary DeptID

Emp-001 Donald Wong 13,000.00 Dept-01

Emp-002 Carrie Lam 34,000.00 Dept-01

Emp-003 Jonathan Chan 78,000.00 Detp-02

DeptID DeptName

Dept-01 Marketing
Department table
Dept_02 Personnel

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Transforming EER Diagrams into
Relations (1 of 7)

• Mapping Regular Entities to Relations

– Simple attributes: E-R attributes map directly onto the
relation, slide 9
– Composite attributes: Use only their simple
component attributes, slide 10
– Multivalued attributes: Become a separate relation
with a foreign key taken from the superior entity,
slide 11

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-8 Example of Mapping a Regular
Entity
a) CUSTOMER entity type

b) CUSTOMER relation

C-0001 Sonia Vally XXXXXX XXXXXX

C-0002 Peter Goldman XXXXXX XXXXXX

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-9 Mapping a Composite Attribute
a) CUSTOMER entity type with composite attribute

b) CUSTOMER relation with address detail

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-10 Mapping an Entity with a
Multivalued Attribute
a) EMPLOYEE entity type with multivalued attribute

b) EMPLOYEE and EMPLOYEE SKILL relations

EmployeeID Skill-ID SkillName

E-3421 S-01 Typing

E-3421 S-02 Java

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Transforming EER Diagrams into
Relations (2 of 7)

• Mapping Weak Entities, slide 13

– Becomes a separate relation with a foreign key taken
from the strong entity
– Primary key composed of:
▪ Partial identifier of weak entity
▪ Primary key of strong entity

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-11 Example of Mapping a Weak
Entity
a) Weak entity DEPENDENT

b) Relations resulting from weak entity

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Transforming EER Diagrams into
Relations (3 of 7)

• Mapping Binary Relationships

– One-to-Many – Primary key on the one side becomes
a foreign key on the many side, slide 15
– Many-to-Many – Create a new relation with the
primary keys of the two entities as its primary key,
slide 16
– One-to-One – Primary key on mandatory side
becomes a foreign key on optional side, slide 17

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-12 Example of Mapping a 1:N
1 colon N

Relationship
a) Relationship between customers and orders

b) CUSTOMER and ORDER relations with a foreign key in ORDER

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-13 Example of Mapping an M:NM colon N
Relationship
a) Completes relationship

(M:N)

EmployeeID EmployeeName EmployeeBirthDate

b) Three resulting relations
E-001 Carl 12/09/1971
E-002 Vivian 06/01/1992

EmployeeID CourseID DateCompleted

E-001 C-001 03/05/2000
E-001 C-002 07/07/2021
E-002 C-002 07/09/2021

CourseID Course Title

C-001 Java
C-002 C++

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-14 Example of Mapping a Binary 1
1:1
colon 1 Relationship

a) In charge relationship (binary 1: 1)

b) Resulting relations

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Transforming EER Diagrams into
Relations (4 of 7)

• Mapping Associative Entities

– Identifier Not Assigned, slide 19
▪ Default primary key for the association relation is
composed of the primary keys of the two entities
(as in M:N relationship)
– Identifier Assigned, slide 21
▪ It is natural and familiar to end-users
▪ Default identifier may not be unique

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-15 Example of Mapping an
Associative Entity (1 of 2)
a) An associative entity

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-15 Example of Mapping an
Associative Entity (2 of 2)
b) Three resulting relations

Composite primary key formed by the two foreign keys

Copyright © 2020 Pearson Education Ltd. All Rights Reserved
Figure 4-16 Example of Mapping an Associative
Entity with an Identifier (1 of 2)

a) SHIPMENT associative entity

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-16 Example of Mapping an Associative
Entity with an Identifier (2 of 2)

b) Three resulting relations

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Transforming EER Diagrams into
Relations (5 of 7)

• Mapping Unary Relationships

– One-to-Many – Recursive foreign key in the same
relation, slide 24
– Many-to-Many – Two relations: slide 25
▪ One for the entity type
▪ One for an associative relation in which the
primary key has two attributes, both taken from the
primary key of the entity

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-17 Example of Mapping a Unary 1
1:NN Relationship
colon

a) EMPLOYEE entity with unary relationship

b) EMPLOYEE relation with recursive foreign key

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-18 Example of Mapping a Unary M
M :N
colon N Relationship

a) ITEM entity with unary relationship

b) COMPONENT relation with recursive foreign key

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Transforming EER Diagrams into
Relations (6 of 7)

• Mapping Ternary (and n-ary) Relationships

– One relation for each entity and one for the
associative entity, slide 27
– Associative entity has foreign keys to each entity in
the relationship, slide 28

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-18 Example of Mapping a Ternary
Relationship (1 of 2)

a) PATIENT TREATMENT ternary relationship with

associative entity

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-18 Example of Mapping a Ternary
Relationship (2 of 2)

b) Four resulting relations

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Transforming EER Diagrams into
Relations (7 of 7)

• Mapping Supertype/Subtype Relationships, slide 30

– One relation for supertype and for each subtype
– Supertype attributes (including identifier and subtype
discriminator) go into supertype relation, slide 31
– Subtype attributes go into each subtype; primary key
of supertype relation also becomes primary key of
subtype relation
– 1:1 relationship established between supertype and
each subtype, with supertype as primary table

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-20 Supertype/Subtype Relationships

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-21 Example of Mapping
Supertype/Subtype Relationships to Relations

These are implemented as one-to-one relationships.

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Data Normalization

• A process of reducing relations with

anomalies( 異常 ) to produce smaller,
well-structured relations.

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Well-Structured Relations
• Well-structured relations contain minimal data
redundancy and allow users to insert, delete, and
update rows without causing data
inconsistencies, slide 34
• Goal of data normalization is to avoid anomalies:
– Insertion Anomaly – adding new rows forces user to
create duplicate data
– Deletion Anomaly – deleting rows may cause a loss
of data that would be needed for other future rows
– Modification Anomaly – changing data in a row
forces changes to other rows because of duplication

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Example–Figure 4-2b
EMPLOYEE2
EmpID Name DeptName Salary CourseTitle DateCompleted
100 Margaret Simpson Marketing 48,000 SPSS 6/19/2018

100 Margaret Simpson Marketing 48,000 Surveys 10/7/2018

140 Alan Beeton Accounting 52,000 Tax Acc 12/8/2018

110 Chris Lucero Info Systems 43,000 Visual Basic 1/12/2018

110 Chris Lucero Info Systems 43,000 C++ 4/22/2018

190 Lorenzo Davis Finance 55,000 Blank Blank

150 Susan Martin Marketing 42,000 SPSS 6/19/2018

150 Susan Martin Marketing 42,000 Java 8/12/2018

Question: Is this a relation? Answer: Yes; unique rows and no multivalued attributes

Question: What’s the primary key? Answer: Composite — Emp ID, CourseTitle

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Anomalies in This Relation (1 of 2)
• Insertion – can’t enter a new employee without having
the employee take a class, slide 34
• Deletion – if we remove employee 140, we lose
information about the existence of a Tax Acc class
• Modification – giving a salary increase to employee 100
forces us to update multiple records

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4.22 Steps in Normalization

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

First Normal Form
• A relation is in 1st normal form if there are no repeating
groups in the relation
• A primary key has been defined, which uniquely identifies
each row in the relations

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4.25 Invoice Data (Pine Valley
Furniture Company)

Table with multivalued attributes, not in 1st normal form.

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4.26 INVOICE Relation (1NF) (Pine
Valley Furniture Company)

This is a relation, but not a well-structured one.

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Anomalies in This Relation
• Insertion – if new product is ordered for order 1007 of
existing customer, customer data must be re-entered,
causing duplication
• Deletion – if we delete the Dining Table from Order 1006,
we lose information concerning this item’s finish and price
• Update – changing the price of product ID 4 requires
update in multiple records

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Second Normal Form
• Must be in 1st Normal Form and any partial functional
dependencies have been removed
• Partial functional dependency: it exists when a non-key
attribute is functionally dependent on part(but not all) of
the primary key

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-27 Functional Dependency
Diagram for Invoice

OrderID → OrderDate, CustomerID, CustomerName, CustomerAddress CustomerID →

CustomerName, CustomerAddress ProductID → ProductDescription, ProductFinish,
ProductStandardPrice OrderID, ProductID → OrderQuantity

Therefore, not in 2nd Normal Form

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-28 Removing Partial Dependencies

Getting it into Second Normal Form

Partial dependencies are removed, but there are still transitive dependencies

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Third Normal Form
• Must be in 2nd Normal Form and no transitive
dependencies exist
• Transitive dependency: a functional dependency
between the primary key and one or more non-key
attributes that are dependent on the primary key via
another non-key attribute

Copyright © 2020 Pearson Education Ltd. All Rights Reserved

Figure 4-29 Removing Transitive Dependencies

Getting it into Third Normal Form

Transitive dependencies are removed.

Copyright © 2020 Pearson Education Ltd. All Rights Reserved