David M. Kroenke and David J.

Auer
Database Processing:
Fundamentals, Design, and Implementation

Chapter Six:
Transforming Data Models
into
Database Designs
 Chapter Objectives
• To understand how to transform data models into
database designs
• To be able to identify primary keys and understand when
to use a surrogate key
• To understand the use of referential integrity constraints
• To understand the use of referential integrity actions
• To be able to represent ID-dependent, 1:1, 1:N, and N:M
relationships as tables
• To be able to represent weak entities as tables

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-2

© 2016 Pearson Education, Ltd.
 The Database Design
• A data model is transformed into a
database design.
• A database design is a set of database
specifications that can actually be
implemented in a specific DBMS product.
– Therefore, a database design for a database
in Microsoft SQL Server 2014 will differ from a
database design for the same database in
Oracle Database or MySQL 5.6.
KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-3
© 2016 Pearson Education, Ltd.
 Steps for Transforming a
Data Model into a Database Design I

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-4

© 2016 Pearson Education, Ltd.
 Steps for Transforming a
Data Model into a Database Design II

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-5

© 2016 Pearson Education, Ltd.
 Create a Table for Each Entity

Primary key is
designated by
the key symbol

Note
shadowless
table

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-6

© 2016 Pearson Education, Ltd.
 Select the Primary Key
• The ideal primary
key is short, numeric,
and fixed.
• Surrogate keys meet
the ideal, but have no
meaning to users.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-7

© 2016 Pearson Education, Ltd.
Specify Candidate (Alternate) Keys
• The terms candidate key and alternate
key are synonymous.
• Candidate keys are alternate identifiers of
unique rows in a table.
• Will use AKn.m notation, where n is the
number of the alternate key, and m is the
column number in that alternate key.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-8

© 2016 Pearson Education, Ltd.
Specify Candidate (Alternate) Keys

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-9

© 2016 Pearson Education, Ltd.
 Specify Column Properties:
Null Status
• Null status indicates
whether or not the
value of the column
can be NULL.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-10

© 2016 Pearson Education, Ltd.
 Specify Column Properties:
Data Type
• Generic data types:
– Char(n), Nchar(n)
– Varchar(n), Nvarchar(n)
– Date
– Time
– Integer
– Decimal(m,n)
– Numeric(m,n)
– Money(m,n)

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-11

© 2016 Pearson Education, Ltd.
 Specify Column Properties:
Data Type + Null Status

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-12

© 2016 Pearson Education, Ltd.
 Specify Column Properties:
Data Constraints
• Data constraints are limitations on data values:
– Domain constraint—column values must be in a
given set of specific values.
– Range constraint—column values must be within a
given range of values.
– Intrarelation constraint—column values are limited
by comparison to values in other columns in the same
table.
– Interrelation constraint—column values are limited
by comparison to values in other columns in other
tables (referential integrity constraints on foreign
keys).

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-13

© 2016 Pearson Education, Ltd.
 Verify Normalization
• The tables should be normalized based on
the data model.
• Verify that all tables are in up to 3NF

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-14

© 2016 Pearson Education, Ltd.
 Create Relationships:
1:1 Strong Entity Relationships I
• Place the primary key of one entity in the
other entity as a foreign key.
– Either design will work—no parent, no child
– Minimum cardinality considerations may be
important.
• O-M will require a different design than M-O.
• One design will be very preferable.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-15

© 2016 Pearson Education, Ltd.
 Create Relationships:
1:1 Strong Entity Relationships II

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-16

© 2016 Pearson Education, Ltd.
 Create Relationships:
1:N Strong Entity Relationships I
• Place the primary key of the table on the
one side of the relationship into the table
on the many side of the relationship as the
foreign key.
• The one side is the parent table and the
many side is the child table, so “place the
key of the parent in the child.”

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-17

© 2016 Pearson Education, Ltd.
 Create Relationships:
1:N Strong Entity Relationships II

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-18

© 2016 Pearson Education, Ltd.
 Create Relationships:
N:M Strong Entity Relationships I
• In an N:M strong entity relationship there is no
place for the foreign key in either table.
– A COMPANY may supply many PARTs.
– A PART may be supplied by many COMPANYs.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-19

© 2016 Pearson Education, Ltd.
 Create Relationships:
N:M Strong Entity Relationships II
• The solution is to create an intersection table
that stores data about the corresponding rows
from each entity.
• The intersection table consists only of the
primary keys of each table which form a
composite primary key.
• Each table’s primary key becomes a foreign key
linking back to that table.
COMPANY_PART_INT (CompanyName, PartNumber)

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-20

© 2016 Pearson Education, Ltd.
 Create Relationships:
N:M Strong Entity Relationships III
COMPANY_PART_INT (CompanyName, PartNumber)

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-21

© 2016 Pearson Education, Ltd.
 Relationships Using ID-Dependent Entities:
Four Uses for ID-Dependent Entities

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-22

© 2016 Pearson Education, Ltd.
 Relationships Using ID-Dependent Entities:
Association Relationships I

• An intersection table
– Holds the relationships between two strong entities in
an N:M relationship
– Contains only the primary keys of the two entities:
• As a composite primary key
• As foreign keys
• An association table
– Has all the characteristics of an intersection table
– PLUS it has one or more columns of attributes
specific to the associations of the other two entities

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-23

© 2016 Pearson Education, Ltd.
 Relationships Using ID-Dependent Entities:
Association Relationships II
QUOTATION (CompanyName, PartNumber, Price)

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-24

© 2016 Pearson Education, Ltd.
 Highline University Data Model

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-25

© 2016 Pearson Education, Ltd.
 Highline University Database Design

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-26

© 2016 Pearson Education, Ltd.
 Design for Minimum Cardinality
• Relationships can have the following types of
minimum cardinality:
– O-O: parent optional and child optional
– M-O: parent mandatory and child optional
– O-M: parent optional and child mandatory
– M-M: parent mandatory and child mandatory
• We will use the term action to mean a
minimum cardinality enforcement action.
• No action needs to be taken for O-O
relationships.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-27

© 2016 Pearson Education, Ltd.
 Actions To Apply to
Enforce Minimum Cardinality

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-28

© 2016 Pearson Education, Ltd.
Implementing Actions for M-O Relationships

• See Figure 6-29(a)

• Make sure that:
– Every child has a parent.
– Operations never create orphans.
• The DBMS will enforce the action as long
as:
– Referential integrity constraints are properly
defined.
– The foreign key column is NOT NULL.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-29

© 2016 Pearson Education, Ltd.
Implementing Actions for M-O Relationships:
DEPARTMENT and EMPLOYEE I

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-30

© 2016 Pearson Education, Ltd.
Implementing Actions for O-M Relationships:
DEPARTMENT and EMPLOYEE I

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-31

© 2016 Pearson Education, Ltd.
 Documenting the Minimum Cardinality Design:
Documenting Required Parents

• COMPANY is parent, DEPARTMENT is child.

• The relationship is M-O.
• This can often be done in the database design
tools.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-32

© 2016 Pearson Education, Ltd.
 Documenting the Minimum Cardinality Design:
Documenting Required Children

• DEPARTMENT is parent,
EMPLOYEE is child.
• The relationship is O-M.
• Use documentation based
on Figure 6-29(b)—see the
next slide.

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-33

© 2016 Pearson Education, Ltd.
 Summary of Minimum Cardinality Design

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-34

© 2016 Pearson Education, Ltd.
 Summary of the Database Design Process

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-35

© 2016 Pearson Education, Ltd.
 David Kroenke and David Auer
Database Processing
Fundamentals, Design, and Implementation
(14th Edition, Global Edition)

End of Presentation:
Chapter Six

KROENKE AND AUER - DATABASE PROCESSING, 14/e, GE 6-36

© 2016 Pearson Education, Ltd.