Copyright © 2007 Ramez Elmasri and Shamkant B.

Navathe
Chapter 4

Database Design, Functional

Dependencies and Normalization
Chapter Outline
 Information System Life Cycle
 Phases of Database Design
 Informal Design Guidelines for Relational
Databases
 Semantics of the Relation Attributes
 Redundant Information in Tuples and Update
Anomalies
 Null Values in Tuples

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter Outline
 Functional Dependencies (FDs)
 Definition of FD
 Inference Rules for FDs

 Normal Forms Based on Primary Keys

 Normalization of Relations
 Practical Use of Normal Forms
 Definitions of Keys and Attributes Participating in Keys
 First Normal Form
 Second Normal Form
 Third Normal Form

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Organizational Context for using
Database Systems
 Consolidation and integration of data across organization
 Maintenance of complex data
 Data independence
 Protecting application programs from changes in the
underlying logical organization and in the physical access
paths and storage structures
 External Schemas
 Allow the same data to be used for multiple applications
with each application having its own view of the data

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Information System
 Information System includes all resources
involved in the collection, management, use
and dissemination of the information resources
of the organization
 We consider two systems life cycles:
 Macro Life Cycle

Information System Life Cycle
 Micro Life Cycle

Database System Life Cycle

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Phases of Information System Life Cycle
 Feasibility Analysis
 Analyzing potential application areas
 Identifying the economics of information gathering and
dissemination
 Performing cost benefit studies
 Setting up priorities among applications
 Requirement Collection and Analysis
 Detailed Requirements Collection
 Interaction with Users
 Design
 Design of Database System
 Design of programs that use and process the database

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Phases of Information System Life Cycle
(contd.)
 Implementation

Information system is implemented

Database is loaded & its transactions are implemented and
tested
 Validation and Acceptance Testing

Testing against user’s requirements

Testing against performance criteria
 Deployment, Operation and Maintenance

Data conversion

Training

System maintenance

Performance monitoring

Database tuning

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Database System Life Cycle
 System definition
 Defining scope of database system, its users and
applications
 Database Design
 Logical and physical design of the database system on the
chosen DBMS
 Database implementation
 Specifying conceptual, external and internal database
definitions
 Creating database files
 Implementing software applications

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Database System Life Cycle (contd.)
 Loading or data conversion
 Populating the database
 Application conversion
 Converting applications to the new system
 Testing and validation
 Operation
 Running the new system
 Monitoring and maintenance
 System maintenance
 Performance monitoring

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Database Design Process
 Problem
 Design the logical and physical structure of one
or more databases to accommodate the
information needs of the users in an organization
for a defined set of applications.
 Goals
 Satisfy the content requirements
 Provide easy structuring of information
 Support processing requirements and
performance objectives

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Phases of Database Design and
Implementation Process
 Requirements Collections and Analysis
 Conceptual Database Design
 Choice of a DBMS
 Data Model Mapping (Logical Database Design)
 Physical Database Design
 Database System Implementation and Tuning
(modification)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Phases of Database Design and
Implementation Process (contd.)
 Requirements Collections and Analysis
 Identifying Users
 Interacting with users to gather requirements
 Time consuming BUT very important

Very expensive to fix requirements error

 Conceptual Database Design

 Produce a conceptual schema for the database that is
independent of a specific DBMS
 Involves two parallel activities

Conceptual Schema Design

Transaction and Application Design

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Conceptual Schema Design
 Goal
 Complete understanding of the database structure,
semantics, interrelationships and constraints
 Serves as a stable description of the database
contents
 Good understanding crucial for the users and
designers
 Diagrammatic description serves as an excellent
communication tool

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Desired Characteristics of Conceptual
Data Model
 Expressiveness
 Able to distinguish different types of data, relationships and
constraints
 Simplicity and Understandability
 Easy to understand
 Minimality
 Small number of distinct basic concepts
 Diagrammatic Representation
 Diagrammatic notation for representing conceptual schema
 Formality
 Formal unambiguous specification of data

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Approaches to Conceptual Schema
Design
 Centralized Schema Design Approach
 Also known as one-shot approach
 Requirements of different applications and user groups are
merged into a single set of requirements and a single
schema is designed
 Time consuming, places the burden on DBA to reconcile
conflicts
 View Integration Approach
 Schema is designed for each user group or application
 These schemas are then merged into a global conceptual
schema during the view integration phase
 More practical

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Schema Integration
 Identifying correspondence and conflict among different
schemas

Naming conflicts

Synonyms: The same concept but different names

e.g. entity types CUSTOMER and CLIENT

Homonyms: Different concepts but same name

e.g. entity type PART as computer parts and furniture parts

Domain Conflicts: Attribute has different
domains

Also known as value set conflicts

e.g. SSN as an integer and as a character string

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Schema Integration (contd.)
 Modifying views to conform to one another
 Modifying schemas to conform to one another

 Merging of views
 Merging Schemas to create a global schema
 Specifying mappings between views and global schema

Time consuming and difficult
 Restructuring
 Simplifying and restructuring to remove any redundancies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

View Integration Strategies
 Binary Ladder Integration
 Two similar schemas are integrated first and the
resulting schema is then integrated with another
schema
 The process is repeated until all schemas are
integrated
 N-ary Integration
 All views are integrated in one procedure after
analysis and specification of their correspondences

Requires computerized tools for large designs

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

View Integration Strategies (contd.)
 Binary Balanced Strategy
 Pairs of schemas are integrated first and the resulting
schemas are then paired for further integration.
 This process is repeated until a final global schema

 Mixed Strategy
 Schemas are partitioned into groups based on their
similarity and each group is integrated separately.
 This process is repeated until a final global schema

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

View Integration Strategies (contd.)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Transaction Design
 Design characteristics of known database transactions in
a DBMS
 Types of Transactions
 Retrieval Transactions

Used to retrieve data
 Update Transactions

Update data
 Mixed Transactions

Combination of update and retrieval
 Techniques for Specifying Transactions
 Input/output
 Functional Behavior

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Choice of DBMS
 Many factors to consider

Technical Factors

Type of DBMS: Relational, object-relational etc.

Storage Structures

Architectural options

Economic Factors

Acquisition, maintenance, training and operating costs

Database creation and conversion cost

Organizational Factors

Organizational philosophy

Relational or Object Oriented

Vendor Preference

Familiarity of staff with the system

Availability of vendor services

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Logical Database Design
 Transform the Schema from high-level data model into
the data model of the selected DBMS.
 Design of external schemas for specific applications
 Two stages
1. System-independent mapping

DBMS independent mapping
2. Tailoring the schemas to a specific DBMS

Adjusting the schemas obtained in step 1 to conform to the
specific implementation features of the data model used in
the selected DBMS

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Physical Database Design
 Design the specifications for the stored database in terms of
physical storage structures, record placements and indexes.

 Design Criteria

Response Time

Elapsed Time between submitting a database transaction for
execution and receiving a response

Space Utilization

Storage space used by database files and their access path
structures

Transaction throughput

Average number of transactions/minute

Must be measured under peak conditions
 Result

Initial determination of storage structures and access paths for
database files

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Database System Implementation and
Tuning
 During this phase database and application
programs are implemented, tested and deployed
 Database Tuning
 System and Performance Monitoring
 Data indexing
 Reorganization
 Tuning is a continuous process

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Informal Design Guidelines for Relational
Databases (1)
 What is relational database design?
 The grouping of attributes to form "good" relation
schemas
 Two levels of relation schemas
 The logical "user view" level
 The storage "base relation" level
 Design is concerned mainly with base relations
 What are the criteria for "good" base relations?

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Informal Design Guidelines for Relational
Databases (2)
 We first discuss informal guidelines for good relational
design
 Then we discuss formal concepts of functional
dependencies and normal forms
 - 1NF (First Normal Form)
 - 2NF (Second Normal Form)
 - 3NF (Third Normal Form)
 Additional types of dependencies, further normal forms
will be discussed

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Semantics of the Relation Attributes
 GUIDELINE 1: Informally, each tuple in a relation should
represent one entity or relationship instance. (Applies to
individual relations and their attributes).
 Attributes of different entities (EMPLOYEEs,
DEPARTMENTs, PROJECTs) should not be mixed in the
same relation
 Only foreign keys should be used to refer to other entities
 Entity and relationship attributes should be kept apart as
much as possible.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.1 A simplified COMPANY
relational database schema

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Redundant Information in Tuples and
Update Anomalies
 Information is stored redundantly
 Wastes storage
 Causes problems with update anomalies

Insertion anomalies

Deletion anomalies

Modification anomalies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

EXAMPLE OF AN UPDATE ANOMALY
 Consider the relation:
 EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
 Update Anomaly:
 Changing the name of project number P1 from
“Billing” to “Customer-Accounting” may cause this
update to be made for all 100 employees working
on project P1.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

EXAMPLE OF AN INSERT ANOMALY
 Consider the relation:
 EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
 Insert Anomaly:
 Cannot insert a project unless an employee is
assigned to it.
 Conversely
 Cannot insert an employee unless an he/she is
assigned to a project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

EXAMPLE OF AN DELETE ANOMALY
 Consider the relation:
 EMP_PROJ(Emp#, Proj#, Ename, Pname,
No_hours)
 Delete Anomaly:
 When a project is deleted, it will result in deleting
all the employees who work on that project.
 Alternately, if an employee is the sole employee
on a project, deleting that employee would result in
deleting the corresponding project.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.3 Two relation schemas
suffering from update anomalies

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.4 Example States for
EMP_DEPT and EMP_PROJ

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Guideline to Redundant Information in
Tuples and Update Anomalies
 GUIDELINE 2:
 Design a schema that does not suffer from the
insertion, deletion and update anomalies.
 If there are any anomalies present, then note them
so that applications can be made to take them into
account.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Null Values in Tuples
 GUIDELINE 3:
 Relations should be designed such that their
tuples will have as few NULL values as possible
 Attributes that are NULL frequently could be
placed in separate relations (with the primary key)
 Reasons for nulls:
 Attribute not applicable or invalid
 Attribute value unknown (may exist)
 Value known to exist, but unavailable

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Functional Dependencies (1)
 Functional dependencies (FDs)
 Are used to specify formal measures of the
"goodness" of relational designs
 And keys are used to define normal forms for
relations
 Are constraints that are derived from the meaning
and interrelationships of the data attributes
 A set of attributes X functionally determines a set
of attributes Y if the value of X determines a
unique value for Y

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Functional Dependencies (2)
 X -> Y holds if whenever two tuples have the same value
for X, they must have the same value for Y
 For any two tuples t1 and t2 in any relation instance r(R): If
t1[X]=t2[X], then t1[Y]=t2[Y]
 X -> Y in R specifies a constraint on all relation instances
r(R)
 Written as X -> Y; can be displayed graphically on a
relation schema as in Figures. ( denoted by the arrow: ).
 FDs are derived from the real-world constraints on the
attributes

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Examples of FD constraints (1)
 Social security number determines employee
name
 SSN -> ENAME
 Project number determines project name and
location
 PNUMBER -> {PNAME, PLOCATION}
 Employee ssn and project number determines the
hours per week that the employee works on the
project
 {SSN, PNUMBER} -> HOURS

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Examples of FD constraints (2)
 An FD is a property of the attributes in the
schema R
 The constraint must hold on every relation
instance r(R)
 If K is a key of R, then K functionally determines
all attributes in R
 (since we never have two distinct tuples with
t1[K]=t2[K])

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Inference Rules for FDs (1)
 Given a set of FDs F, we can infer additional FDs that
hold whenever the FDs in F hold
 Armstrong's inference rules:
 IR1. (Reflexive) If Y subset-of X, then X -> Y
 IR2. (Augmentation) If X -> Y, then XZ -> YZ

(Notation: XZ stands for X U Z)
 IR3. (Transitive) If X -> Y and Y -> Z, then X -> Z

 IR1, IR2, IR3 form a sound and complete set of

inference rules
 These are rules hold and all other rules that hold can be
deduced from these

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Inference Rules for FDs (2)
 Some additional inference rules that are useful:
 Decomposition: If X -> YZ, then X -> Y and X ->
Z
 Union: If X -> Y and X -> Z, then X -> YZ
 Psuedotransitivity: If X -> Y and WY -> Z, then
WX -> Z

 The last three inference rules, as well as any

other inference rules, can be deduced from IR1,
IR2, and IR3 (completeness property)

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

3 Normal Forms Based on Primary Keys
 3.1 Normalization of Relations
 3.2 Practical Use of Normal Forms
 3.3 Definitions of Keys and Attributes
Participating in Keys
 3.4 First Normal Form
 3.5 Second Normal Form
 3.6 Third Normal Form

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

3.1 Normalization of Relations (1)
 Normalization:
 The process of decomposing unsatisfactory "bad"
relations by breaking up their attributes into
smaller relations

 Normal form:
 Condition using keys and FDs of a relation to
certify whether a relation schema is in a particular
normal form

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

3.2 Practical Use of Normal Forms
 Normalization is carried out in practice so that the
resulting designs are of high quality and meet the
desirable properties
 The practical utility of these normal forms becomes
questionable when the constraints on which they are
based are hard to understand or to detect
 The database designers need not normalize to the highest
possible normal form

(usually up to 3NF)
 Denormalization:

The process of storing the join of higher normal form
relations as a base relation—which is in a lower normal form

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

3.3 Definitions of Keys and Attributes
Participating in Keys (1)
 A superkey of a relation schema R = {A1, A2, ....,
An} is a set of attributes S subset-of R with the
property that no two tuples t1 and t2 in any legal
relation state r of R will have t1[S] = t2[S]

 A key K is a superkey with the additional

property that removal of any attribute from K will
cause K not to be a superkey any more.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Definitions of Keys and Attributes
Participating in Keys (2)
 If a relation schema has more than one key, each
is called a candidate key.
 One of the candidate keys is arbitrarily designated
to be the primary key, and the others are called
secondary keys.
 A Prime attribute must be a member of some
candidate key
 A Nonprime attribute is not a prime attribute—
that is, it is not a member of any candidate key.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

3.2 First Normal Form
 Disallows
 composite attributes
 multivalued attributes
 nested relations; attributes whose values for an
individual tuple are non-atomic

 Considered to be part of the definition of relation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.8 Normalization into 1NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.9 Normalization nested
relations into 1NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

3.3 Second Normal Form (1)
 Uses the concepts of FDs, primary key
 Definitions
 Prime attribute: An attribute that is member of the primary
key K
 Full functional dependency: a FD Y -> Z where removal
of any attribute from Y means the FD does not hold any
more
 Examples:
 {SSN, PNUMBER} -> HOURS is a full FD since neither SSN
-> HOURS nor PNUMBER -> HOURS hold
 {SSN, PNUMBER} -> ENAME is not a full FD (it is called a
partial dependency ) since SSN -> ENAME also holds

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Second Normal Form (2)
 A relation schema R is in second normal form
(2NF) if every non-prime attribute A in R is fully
functionally dependent on the primary key

 R can be decomposed into 2NF relations via the

process of 2NF normalization

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.10 Normalizing into 2NF and
3NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Figure 10.11 Normalization into 2NF and
3NF

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

3.4 Third Normal Form (1)
 Definition:
 Transitive functional dependency: a FD X -> Z
that can be derived from two FDs X -> Y and Y ->
Z
 Examples:
 SSN -> DMGRSSN is a transitive FD

Since SSN -> DNUMBER and DNUMBER ->
DMGRSSN hold
 SSN -> ENAME is non-transitive

Since there is no set of attributes X where SSN -> X
and X -> ENAME

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Third Normal Form (2)
 A relation schema R is in third normal form (3NF) if it is
in 2NF and no non-prime attribute A in R is transitively
dependent on the primary key
 R can be decomposed into 3NF relations via the process
of 3NF normalization
 NOTE:
 In X -> Y and Y -> Z, with X as the primary key, we consider
this a problem only if Y is not a candidate key.
 When Y is a candidate key, there is no problem with the
transitive dependency .
 E.g., Consider EMP (SSN, Emp#, Salary ).

Here, SSN -> Emp# -> Salary and Emp# is a candidate key.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe