Logical Database Design

and the Relational Model

Chapter 5 Part B
Objectives
 Define and Understand the Insertion,
Deletion, and Update Anomalies
 Define & Understand Integrity Constraints
 Define the normal forms and understand
Normalization
 Describe 4 problems that may occur when
merging relations
 Design Well-Structured Relations
 A relation that contains minimal data redundancy and
allows users to insert, delete, and update rows without
causing data inconsistencies
 Goal 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
Example :A Poorly-Structured Relation
This is relation, but NOT a well-structured one
 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 the price of product ID 4 requires update in
several records

Why do these anomalies exist?

Because there are multiple themes (entity types) into one
relation. This results in duplication, and an unnecessary
dependency between the entities
Data Normalization
 Process for deciding which attributes
should be grouped in a relation/table.
 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 to produce smaller, well-
structured relations.
Normalization Steps
 Removed Multi-valued Attributes
 Remove Partial Dependencies
 Remove Transitive Dependencies
 Remove remaining anomalies resulting from
functional dependencies
 Remove multi-valued dependencies
 Remove remaining anomalies
 Functional Dependencies
 Functional Dependency: The value of one attribute
(the determinant) determines the value of another
attribute.
 ID → Name, Address
 ID determines Name and Address attributes
 Partial Dependency
 A nonkey attribute is functionally dependent on part (but
not all) of a composite primary key
 Transitive Dependency
 A functional dependency between two ore more nonkey
attributes.
 Partial Dependency

Composite Primary key: Order_ID + ProductID

Order_Date, Customer_ID, Customer Name, Customer_Address are
determined by the Order_ID.
They do not depend on the Product_ID
Order_ID→Order_Date, Customer_Name, Customer_Address
 Transitive Dependency

Composite Primary key: Order_ID + ProductID

Both Customer_Name and Customer_Address are
dependent on the nonkey, Customer_ID
Customer_ID → Customer_Name, Customer_Address
Normalization
Steps
Normal Forms
 First Normal Form (1NF)
 No multi-valued attributes,
 A primary key has been defined
 Second Normal Form (2NF)
 1NF + Contains no partial dependencies
 Third Normal Form (3NF)
 2NF + Contains no transitive dependencies
 The remaining Normal Forms are not discussed in
this chapter (Boyce-Codd, 3NF and 5NF)
 Example: First Normal Form (1NF)
 A table with multi-valued attributes is NOT 1NF
This is NOT First Normal Form –
This is not even a relation
 Example: First Normal Form (1NF)
 This table IS in First Normal Form
 The primary key is Order_Id + Product_ID
 No Multi-valued attributes

This is relation not well-structured. There is more work to do…..

Example: Second Normal Form (2NF)
 Remove Partial Dependencies – all attributes should
depend on ALL parts of a composite primary key.

 Result: All Partial Dependencies removed

The Order relation not well-structured. There is more work to do …

Example: Third Normal Form (3NF)
 Remove all Transitive dependencies (functional
dependency between non-key attributes.)

 Result:
Another Normalization Example
 What is the normal form?
EmpID CourseTitle Name DeptName Salary DateCompleted

•First Normal Form (1NF)

• No multi-valued attributes,
•A primary key has been defined
•Second Normal Form (2NF)
•1NF + Contains no partial dependencies
•Third Normal Form (3NF)
•2NF + Contains no transitive dependencies
Functional Dependencies in EMPLOYEE2

Dependency on entire primary key

EmpID CourseTitle Name DeptName Salary DateCompleted

Dependency on only part of the key

EmpID, CourseTitle  DateCompleted

EmpID  Name, DeptName, Salary

Therefore this is in 1NF. It is NOT in 2NF

Getting it into 2nd Normal Form
 Decomposed into two separate relations

EmpID Name DeptName Salary

EmpID CourseTitle DateCompleted

Are the above tables or relations in 3NF?

Merging Relations

During integration you will have to

combine entities from multiple ER
models into common relations
 Merging Relations
 Issues to watch out for when merging entities
from different ER models:
 Synonyms – two or more attributes with different
names but same meaning
 Homonyms – attributes with same name but
different meanings
 Transitive dependencies – even if relations are in
3NF prior to merging, they may not be after merging
 Supertype/subtype relationships – may be hidden
prior to merging
 Integrity Constraints
 Entity Integrity - Assures that every relation has a
primary key
 A primary key (or component of a primary key) can’t be null
 Referential Integrity - Consistency among the rows of
two relations
 Each Foreign key must match a Primary key in another
table or the Foreign key must be null
 Ex: Delete Rules: Restrict, Cascade, Set-to-Null
 Domain Constraints – all attribute values must be taken
from the same domain (allowable values)
 A Zip Code cannot be “AA22”
 Operational Constraints - Action Assertions based on
Business Rules
Referential integrity constraints (Pine Valley Furniture)