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
