Database Concepts

Ninth Edition

Chapter 5
Database Design

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Learning Objectives
2

• Learn how to transform E-R data models into relational designs

• Practice applying the normalization process
• Understand the need for denormalization
• Learn how to represent weak entities with the relational Model
• Know how to represent 1:1, 1:N, and N:M binary relationships
• Know how to represent 1:1, 1:N, and N:M recursive
relationships
• Learn SQL statements for creating joins over binary and
recursive relationships

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
The Purpose of a Database Design
3

Learn how to transform E-R data models into

relational designs
• A database design is a set of database specifications that can
actually be implemented as a database in a DBMS.
• The three designs are:
– conceptual design (conceptual schema)
– logical design (logical schema)
– physical design (physical schema)
• The design studied in this chapter is equivalent to the logical
design.

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.1 The Steps for Transforming
4

a Data Model into a Database Design

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.2 The ITEM Entity and Table
5

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.3 The Final ITEM Table
6

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.4 The CUSTOMER Entity
7

and Table

CUSTOMER (CustomerNumber, CustomerName, StreetAddress, City, State, ZIP,

ContactName, Phone)
Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.5 The Normalized
8

CUSTOMER and Associated Tables

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Denormalization
9

Understand the need for denormalization

• Normalizing relations (or breaking them apart into many
component relations) may significantly increase the complexity
of the data structure.
• The question is one of balance:
– trading complexity for modification problems
• There are situations where denormalized relations are
preferred.

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
 10

Figure 5.6 The Denormalized CUSTOMER

and Associated CONTACT Tables

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Represent Weak Entities
11

Learn how to represent weak entities with the

relational model
• If not ID-dependent, use the same techniques as for strong
entities
• If ID-dependent, then must add primary key of the parent entity

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.7 The SALES_COMMISSION
12

Entity and Table

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
A Relational Design for the
13

SALES_COMMISSION Entity (1 of 2)
Understand the need for normalization
• Consider the original attributes of the SALES_COMMISSION entity on
the previous slide

• Three additional functional dependencies are:

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
A Relational Design for the
14

SALES_COMMISSION Entity (2 of 2)
Understand the need for normalization
• One look at the previous functional dependencies reveals that the
original table, given the primary key CheckNumber, should actually be
called COMMISSION_CHECK.
• Once normalized properly you have…

• This is now shown in Figure 5.8 on the next slide.

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.8 The Normalized SALES_
15

COMMISSION And Associated Tables

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Representing 1:1 Relationships
16

Know how to represent 1:1, 1:N, and N:M binary

relationships
• The maximum cardinality determines how a relationship is
represented.
• 1:1 Relationship:
– the key from one relation is placed in the other as a foreign
key
– it does not matter which table receives the foreign key

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.10 1:1 Strong Entity
17

Relationships

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Results of a 1:1 Relationship
18

Know how to represent 1:1, 1:N, and N:M binary

relationships
• Because of a 1:1 relationship both of the following examples
would not produce any unassigned employees.

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.11 1:1 Strong Entity
19

Relationship Between CUSTOMER

and CONTACT

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Representing 1:N Strong Entity
20

Relationships
Know how to represent 1:1, 1:N, and N:M binary
relationships
• Like a 1:1 relationship, a 1:N relationship is saved by placing
the key from one table into another as a foreign key.
• However, in a 1:N the foreign key always goes into the many-
side of the relationship:
– the 1 side is called the parent
– the N side is called the child

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.12 1:N Strong Entity
21

Relationships

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Results of a 1:N Relationship
22

Know how to represent 1:1, 1:N, and N:M binary

relationships
• In a 1:N relationship, the key of the parent must be placed in
the child relation

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Representing N:M Strong Entity
23

Relationships
Know how to represent 1:1, 1:N, and N:M binary
relationships
• To create an N:M relationship, a new table is created. This
table is called an intersection table.
• An intersection table has a composite key consisting of the
keys from each of the tables that it connects.

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.13 N:M Strong Entity
24

Relationships

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.14 Incorrect Representation
25

of an N:M Relationship

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.15 Representing a N:M
26

Strong Entity Relationship

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Results of a N:M Relationships
27

Learn SQL Statements for creating joins over

binary and recursive relationships
• In a N:M relationship, an intersection table must be created that
will contain the primary keys of each of the other two tables as
a composite primary key.

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.18 The Association
28

Relationship

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.19 Mixed Entity Relationship
29

Example

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.20 Representing Subtypes
30

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Representing Recursive
31

Relationships
Know how to represent 1:1, 1:N, and N:M
recursive relationships
• A recursive relationship is a relationship among entities of the
same class (a relationship with itself).
• There are three types of recursive relationships:
– 1:1 and 1:M relationships are saved using foreign keys
– M:M relationships are saved by creating an intersecting
relation

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.21 Example Recursive
32

Relationships

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.22 Example 1:1 Recursive
33

Relationship

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.23 Example 1:N Recursive
34

Relationship

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.24 Example N:M Recursive
35

Relationship

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Figure 5.25 The Final Data Model for
36

Heather Sweeney Designs

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Specifying Column Properties
37

Learn how to transform E-R data models into

relational designs
• Column properties must be specified for each table.
• The finalized column properties for the HSD tables are on
the next set of slides – these are the column
characteristics after additional needed foreign keys have
been added. This includes any new intersection tables.

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
 38

Figure 5.26 Heather Sweeney Designs HSD

Database Column Specifications (1 of 3)
Column Name Data Type (Length) Key Required Default Value Remarks
SeminarID Integer Primary Yes DBMS Surrogate Key:
Key supplied Initial value=1
Increment=1

SeminarDate Date No Yes None Format: yyyy-mm- dd

SeminarTime Time No Yes None Format: 00:00:00.000

Location VarChar (100) No Yes None Blank

SeminarTitle VarChar (100) No Yes None Blank

Column Name Data Type (Length) Key Required Default Value Remarks
CustomerID Integer Primary Yes DBMS Supplied
Key Surrogate Key:
Initial Value=1
Increment=1
LastName Char (25) No Yes None Blank
FirstName Char (25) No Yes None Blank
EmailAddress VarChar (100) Primary Key Yes None Blank
EncryptedPassword VarChar(50) No No None Blank
Phone Char (12) No Yes None Format: ###-###-####

StreetAddress Char (35) No No None Blank

City Char (35) No No Dallas Blank
State Char (2) No No TX Format: AA
ZIP Char (10) No No 75201 Format: #####-####

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
 39

Figure 5.26 Heather Sweeney Designs HSD

Database Column Specifications (2 of 3)
Column Name Data Type (Length) Key Required Default Value Remarks
CustomerID Integer Primary Key, Yes None REF: CUSTOMER
Foreign Key
ContactNumber Integer Primary Key Yes None Blank
ContactDate Date No Yes None Format: yyyy-mm-dd

ContactType Char (15) No Yes None Blank

Column Name Data Type (Length) Key Required Default Value Remarks
InvoiceNumber Integer Primary Key Yes DBMS supplied Surrogate Key:
Initial
value=35000
Increment=1
InvoiceDate Date No Yes None Format: yyyy-
mm-dd
PaymentType Char (25) No Yes Cash Blank
Subtotal Numeric (9,2) No No None Blank
Shipping Numeric (9,2) No No None Blank
Tax Numeric (9,2) No No None Blank
Total Numeric (9,2) No No None Blank

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
 40

Figure 5.26 Heather Sweeney Designs HSD

Database Column Specifications (3 of 3)
Column Name Data Type (Length) Key Required Default Value Remarks
InvoiceNumber Integer Primary Key, Yes None REF: INVOICE
Foreign Key
LineNumber Integer Primary Key Yes None This is not quite a
Surrogate Key—for
each InvoiceNumber:
Increment=1
Application logic will
be needed to supply
the correct value

Quantity Integer No No None Blank

UnitPrice Numeric (9,2) No No None Blank
Total Numeric (9,2) No No None Blank

Column Name Data Type (Length) Key Required Default Value Remarks
ProductNumber Char (35) Primary Key Yes None Blank
ProductType Char (24) No Yes None Blank
ProductDescription VarChar (100) No Yes None Blank
UnitPrice Numeric (9, 2) No Yes None Blank
QuantityOnHand Integer No Yes 0 Blank

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
 41

Figure 5.27 Database Design for Heather

Sweeney

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Heather Sweeney’s Database Design
42

Schema
Learn how to transform E-R data models into
relational designs

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
 43

Figure 5.29 Referential Integrity Constraint

Enforcement for Heather Sweeney Designs

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved
Copyright
44

This work is protected by United States copyright laws and is

provided solely for the use of instructors in teaching their
courses and assessing student learning. Dissemination or sale of
any part of this work (including on the World Wide Web) will
destroy the integrity of the work and is not permitted. The work
and materials from it should never be made available to students
except by instructors using the accompanying text in their
classes. All recipients of this work are expected to abide by these
restrictions and to honor the intended pedagogical purposes and
the needs of other instructors who rely on these materials.

Copyright © 2020, 2017, 2015 Pearson Education, Inc. All Rights Reserved