CHAPTER 4: PART 1

LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL

Modern Database Management

11th Edition
Jeffrey A. Hoffer, V. Ramesh,
Heikki Topi

© 2013 Pearson Education, Inc.  Publishing as Prentice Hall

1
 OBJECTIVES
 Define terms
 List five properties of relations
 State two properties of candidate keys
 Define first, second, and third normal form
 Describe problems from merging relations
 Transform E-R and EER diagrams to relations
 Create tables with entity and relational integrity
constraints
 Use normalization to convert anomalous tables to
well-structured relations

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 2

 COMPONENTS OF RELATIONAL MODEL
 Data structure
 Tables (relations), rows, columns
2 Employee records
Employee in 2 rows 1 Ahmed
2 Mohamed
Employee ID
Employee Name 2 Attributes in
2 Columns

 Data manipulation
 Powerful SQL operations for retrieving and modifying data

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 3

 COMPONENTS OF RELATIONAL MODEL
 Data integrity
 Mechanisms for implementing business rules that maintain
integrity of manipulated data

 Data Normalization
 Primarily a tool to validate and improve a logical
design so that it satisfies certain constraints that avoid
unnecessary duplication of data

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 4

 RELATION
 A relation is a named, two-dimensional table of data.
 A table consists of rows (records) and columns (attribute or
field).
 Requirements for a table to qualify as a relation:
 It must have a unique name.
 Attributes (columns) in tables must have unique names.
 Every attribute value must be atomic (not multivalued, not composite).
 Every row must be unique (can’t have two rows with exactly the same
values for all their fields).
 The order of the columns and rows must be irrelevant.

NOTE: All relations are in 1st Normal form.

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 5
 MAPPING ENTITIES INTO RELATIONS
 Simple attributes: E-R attributes map directly onto the relation

(a) CUSTOMER entity Figure 4-8 Mapping a

type with simple regular entity
attributes

Primary key (b) CUSTOMER relation

(c) CUSTOMERS’ Instants

12 Ahmed Mohamed 6 Tahrir Square, Apt 6, Cairo,Egypt 11471
8 Mohamed youssef 7 Giza square - Giza -Egypt 15888
Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 6
MAPPING ENTITIES INTO RELATIONS
 Composite attributes: Use only their simple,
component attributes
(a)

CUSTOMER
entity type with
composite
attribute

(b) CUSTOMER relation with address detail

(c ) Customers’ Instants
12 Ahmed Mohamed 6 Tahrir Square Cairo Egypt 11471
8 Mohamed youssef 7 Giza square Giza Egypt 15888
Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 7
 MAPPING ENTITIES INTO RELATIONS
 Multivalued Attribute: Becomes a (a)
separate relation with a foreign key
taken from the superior entity

(b)
Primary key

One–to–many relationship
between original entity
Foreign key and new relation
(c)
12 Ahmed Mohamed 6 Tahrir Square, Apt 6, Cairo,Egypt 12 Programming in C++
8 Mohamed youssef 7 Giza square - Giza -Egypt 8 Programming in C++
12 Programming in Java
12 DBMS
Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 8
 KEY FIELDS
 Keys are special fields that serve 2 main purposes:
 Primary keys are unique identifiers of the relation.
This guarantees that all rows are unique
 Foreign keys are identifiers that enable a dependent
relation (on the many side of a relationship) to refer
to its parent relation (on the one side of the
relationship).
 Is either simple or composite
 Word relation (in relational database) is NOT the same
as the word relationship (in E-R model).

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 9

 TEST YOURSELF
 A customer places an order, the order have different products with
different quantity?
 Draw ER Model?
 Are you going to need an associative entity(s) or not?
 Change each entity into relation?
 Assign Primary keys and foreign Keys?
 After you are done look at the next slide and correct your answer?

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 10

 Figure 4-3 Schema for four relations (Pine Valley Furniture Company)

Primary Key
Foreign Key
(implements 1:N relationship
between customer and order)

Combined, these are a composite

primary key (uniquely identifies the
order line)…individually they are
foreign keys (implement M:N
relationship between order and product)

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall

11
INTEGRITY CONSTRAINTS
 Data integrity
 refers to the overall accuracy, completeness, and reliability of data

 Domain Constraints
 Allowable values for an attribute (See Table 4-1)

 Entity Integrity
 No primary key attribute may be null. All primary key fields MUST have data.

 Action Assertions
 It is a type of business rules.
 Is a statement that ensures that certain conditions are always enforced in the database
no matter what
 Is a statement or constraint or control on the actions of the organization.

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 12

 Domain definitions enforce domain integrity constraints.

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall

13
 INTEGRITY CONSTRAINTS
 Referential Integrity–rule states that any foreign key value (on the relation of the
many side ”Dependent”) MUST match a primary key value in the relation of the
one side (”Parent”). (Or the foreign key can be null)
 For example: Delete Rules
 Restrict–don’t allow delete of “parent” side if related rows exist in
“dependent” side
 Cascade–automatically delete “dependent” side rows that correspond with
the “parent” side row to be deleted
 Set-to-Null–set the foreign key in the dependent side to null if deleting
from the parent side  not allowed for weak entities

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 14

 Figure 4-5
Referential integrity constraints (Pine Valley Furniture)

Referential
integrity

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall

15
TRANSFORMING EER DIAGRAMS INTO
RELATIONS :MAPPING WEAK ENTITIES
 Becomes a separate relation with a foreign key
taken from the superior entity
 Primary key composed of:
 Partial identifier of weak entity
 Primary key of identifying relation (strong entity)
(b) Domain constraint for the
(a) foreign key should NOT allow
null value if DEPENDENT is
a weak entity

Foreign key
Composite primary key

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 16

MAPPING BINARY RELATIONSHIPS
 One-to-Many–Primary key on the one side becomes a
foreign key on the many side
a) Relationship between customers and orders
(a)
Note the mandatory one

b) Mapping the relationship

(b)

Again, no null value in the

foreign key…this is because
Foreign key of the mandatory minimum
cardinality.
Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 17
© 2013 Pearson Education, Inc.  Publishing as Prentice Hall
MAPPING BINARY RELATIONSHIPS
 Many-to-Many–Create a new relation with the primary
keys of the two entities as its primary key
(a)
The Completes
relationship will
need to become a
separate relation.

(b)

Foreign key
new intersection
relation
Composite primary key
Foreign key

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 18

 MAPPING BINARY RELATIONSHIPS
 One-to-One–Primary key on mandatory side becomes a
foreign key on optional side
(a) In charge
relationship (1:1)
Often in 1:1 relationships,
one direction is optional

(b) Foreign key goes in the

relation on the optional side,
matching the primary key on
the mandatory side

Figure 4-14 Example of mapping a binary 1:1 relationship

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall

19
MAPPING ASSOCIATIVE ENTITIES TO
RELATIONS : IDENTIFIER NOT ASSIGNED
 Default primary key for the association relation is composed of the primary
keys of the two entities (as in M:N relationship)

(a)

(b)
Composite primary key
formed from the two foreign
keys

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 20

 MAPPING ASSOCIATIVE ENTITIES INTO
RELATIONS : IDENTIFIER ASSIGNED
 Associative entity has its own identifier, in this case use this
identifier.
(a)
SHIPMENT
associative
entity

(b)

Primary key differs from foreign keys

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 21

TEST YOURSELF

We need to store the students’ hobbies in a

database. You Have the following entities:
1) STUDENT: (student_id, student_name,
student_hobbies)
Q1: Draw ER Model
Q2: Draw RM

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 22

TRANSFORMING EER DIAGRAMS INTO RELATIONS: MAPPING
UNARY RELATIONSHIPS

 One-to-Many–Recursive foreign key in same relation

(a) EMPLOYEE 1 (Top Manager)
entity with unary
relationship 2 (Middle Manager)

3 (Sales Manager) 4 (R&D Manager)

10 11 12 13 14

(b)
EMPLOYEE
relation with
recursive
foreign key

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 23

 TRANSFORMING EER DIAGRAMS INTO RELATIONS: MAPPING
UNARY RELATIONSHIPS
(a) Bill-of-materials relationships (M:N)
 Many-to-Many–Two relations:
 One for the entity type
 One for an new associative relation in
which the primary key has two
attributes, both taken from the primary
key of the entity

(b) ITEM and COMPONENT relations

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 24

TRANSFORMING EER DIAGRAMS INTO RELATIONS:
MAPPING A TERNARY RELATIONSHIP
a) PATIENT
 One relation for each TREATMENT
entity and one for the Ternary relationship
with associative
associative entity entity
 Associative entity has
foreign keys to each
entity in the relationship
b) Mapping the ternary relationship
PATIENT TREATMENT

This is why treatment

Remember that the date and time are It would be better to create
But this makes a very
primary key MUST included in the a surrogate (substitute) key
cumbersome (clumsy)
be unique. composite primary like Treatment#.
key…
Chapter 4 © 2013 key.
Pearson Education, Inc.  Publishing as Prentice Hall
25
DATA NORMALIZATION
 Primarily a tool to validate and improve
a logical design so that it satisfies certain
constraints that avoid unnecessary
duplication of data
 The process of decomposing relations
with anomalies (abnormalities) to
produce smaller, well-structured
relations
Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 26
 Figure 4.22 Steps in normalization

3rd normal form is

generally considered
sufficient

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall

27
 WELL-STRUCTURED RELATIONS
 contains minimal data redundancy and allows users to insert, delete, and update
rows without causing data inconsistencies
Question–Is this a relation? Answer–Yes: Unique rows and no multivalued attributes
Question–What’s the primary key? Answer–Composite: EmpID, CourseTitle

EXAMPLE–FIGURE 4-2B

Insertion Anomaly–adding new rows forces , an Employee should complete a course

because of Composite Key condition.
Deletion Anomaly–deleting rows may cause a loss of data needed later on. Eg. If we
delete EmpID =140 we lose Tax Acc class .
Modification Anomaly–changing data in a row forces changes to other rows because of
duplication. Eg. If we modify salary of EmpID =100,we will modify 2 rows.
Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 28
 WELL-STRUCTURED RELATIONS

Why do these anomalies exist?

Because there are two themes (entity types) in this
one relation. This results in data duplication and an
unnecessary dependency between the entities.
Foreign Key

EMPLOYEE ENTITY COURSE ENTITY

General rule of thumb:

A table should not pertain (apply) to more than one
entity type.

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 29

FUNCTIONAL DEPENDENCIES AND KEYS
 The value of one attribute determines the value of another
attribute
 Each non-key field is functionally dependent on primary key.

PK ———–> NON PK
Left side: is called the determinant
Right side: is the dependent

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 30

 1ST NORMAL FORM
(a)

This is NOT a relation.

(b)

This is a relation, but not a

Chapter 4 © 2013 Pearson Education, Inc.  Publishingwell-structured
as Prentice Hall one.
31
 ANOMALIES IN THIS TABLE
 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 price of product ID 4 requires update in multiple records

Why do these anomalies exist?

Because there are multiple themes (entity types) in one relation. This results in
duplication and an unnecessary dependency between entities.
Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 32
 SECOND NORMAL FORM
 1NF PLUS and No partial functional
dependencies
 No Partial functional dependencies
 If every non-key attribute is fully functionally
dependent on the ENTIRE primary key

Order Date depends on OrderID only while composite

primary key consists of OrderID and ProductID

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 33

 SECOND NORMAL FORM
 To eliminate partial functional dependencies do:
1. Create a new relation for each primary key.
2. Move all non-key attributes that are dependent on that primary key
from old relation to the new one
Non Key attribute OrderI ProductI

}
D D
Order _date √ ---- Customer_Order relation
Customer_ID √ ----
OrderI Order Custome Customer_Nam Customer
Customer_Name √ ---- D _date r_ID e Address
Customer Address √ ----

}
Product _description ---- √ Product relation
Product Product
ProductID Unit Price
Product _Finish ---- √ _description _Finish

Unit Price ---- √

Order Line
Ordered-Quantity √ √
Ordered-
OrderID ProductID
Quantity

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 34

 THIRD NORMAL FORM
 2NF PLUS no transitive dependencies
 Transitive dependencies occurs
because the primary key is a determinant for another attribute, which in turn is a
determinant for a third attribute
Customer Order relation

OrderID Order _date Customer_ID Customer_Name Customer Address

1 2 3

Example of Transitive dependencies occurrence

Customer_Name & CustomerAddress depends on Customer_ID and
Customer_ID depends on the Primatry Key (Order_ID).

Non Key attribute OrderID Name of Determinant

Order _date √ OrderID
Customer_ID __ OrderID
Customer_Name __ Customer_ID
Customer Address __ Customer_ID
Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 35
THIRD NORMAL FORM
 2NF PLUS no transitive dependencies
 Steps to remove Transitive dependencies occurs
1. Create a new relation.
2. Move each determinant attribute (PK) and non_Key attribute (or set of attributes) to new
relation.
3. Keep a copy of determinant attribute (PK) in old relation to act as a foreign key.

OrderID Order _date Customer_ID Customer_Name Customer Address

Customer
Customer_ID Customer_Name
Address

OrderID Order _date Customer_ID

Chapter 4 © 2013 Pearson Education, Inc.  Publishing as Prentice Hall 36