Unit – 4 Database Design & Query Processing

Contents: Purpose of Normalization, Data Redundancy and Update Anomalies,

Functional Dependencies. The process of Normalization: 1NF, 2NF, 3NF, BCNF.
Introduction to Query Processing: Overview, Measures of Query cost, Selection
and Join operations, Evaluation of Expressions.
Introduction to Query optimization: Estimation, Transformation of Relational
Expression.

Unit Objectives
1. The objective of the course is to present an introduction to database management system
as a subject in its own right.
2. To understand the fundamental concepts of Relational Database management system.

Unit outcomes: On completion the students will be able to :

CO4:Improve the database design by normalization & to incorporate query processing
Database Design & Query Processing
Outcome Mapping: Mapping of PEO,PO, CO, PSO

Books :
R1. Silberschatz A., Korth H., Sudarshan S. “Database System Concepts”, 6th edition,
Tata McGraw Hill Publishers
R2. G. K. Gupta “Database Management Systems” , Tata McGraw Hill
DBMS Project Design
 Understand the organization/ Environment
 Convert the functional units into entities
 Identify the entities and Attributes and Relations amongst
entities very correctly
 Draw an E-R Diagram
 Reduce your E-R Diagram into set of tables i.e. database
 Put all the integrity constraints of the organization
 Bring your databases into normal forms(Normalization)
 Then create your back-end
 And at last front end
 A producer wants to know….
Which are our
lowest/highest margin
customers ?
Who are my customers
What is the most and what products
effective distribution are they buying?
channel?

What product prom- Which customers

-otions have the biggest are most likely to go
impact on revenue? to the competition ?
What impact will
new products/services
have on revenue
and margins?
4
Data, Data everywhere ...
 I can’t find the data I need
◦ data is scattered over the network
◦ many versions, subtle differences

• I can’t get the data I need

• need an expert to get the data

• I can’t understand the data I found

• available data poorly documented

• I can’t use the data I found

• results are unexpected
• data needs to be transformed from
one form to other
RDBMS!!!
5
 The Solution is Normalization
Normalization is a database design technique
which is used to organize the tables in such manner
that it should reduce redundancy and dependency
of data.
Normalization is a technique for producing a set
of relations with desirable properties, given the
data requirements of an enterprise.
It divides larger tables to smaller tables and
links these smaller tables using relationships.
The process of normalization is a formal method
that identifies relations based on their primary or
candidate keys and the functional dependencies
among their attributes.
Pitfalls in Relational Database Design

 Relational database design requires that

we find a “good” collection of relation
schemas. A bad design may lead to

 Repetition of Information
 Inability to represent certain information
Recipe for a Successful DATABASE
 Good Database Design

◦ Design Goals:
◦ Avoid redundant data
◦ Ensure that relationships among attributes are
represented
◦ Facilitate the checking of updates for violation
of database integrity constraints Facilitate the
Ensure that
checking of updates
Avoid redundant relationships among
for violation of
data attributes are
database integrity
represented
constraints
Example
 Consider the relation schema:

 Redundancy:
◦ Data for branch-name, branch-city, assets are repeated for each loan that a branch
makes Wastes space
◦ Complicates updating, introducing possibility of inconsistency of assets value
 Null values
◦ Cannot store information about a branch if no loans exist
◦ Can use null values, but they are difficult to handle.
Functional Dependency
 The attribute of a relation is said to be
dependent on each other when an attribute of a
table uniquely identifies another attribute of the
same table. This is called as functional
dependency.
 Various types of functional dependencies are
1. Single valued functional dependency
2. Multivalued functional dependency
3. Fully functional dependency
4. Partial functional dependency
5. Transitive (Tracient ) functional dependency
6. Trivial functional dependency
7. Non trivial functional dependency
 Functional Dependencies
• Functional dependency describes the relationship
between attributes in a relation.
• An attribute is functionally dependent if its value is
determined by the value of another attribute which is a key.

• For example, if A and B are attributes of relation R, and B is

functionally dependent on A ( denoted A B), if each value
of A is associated with exactly one value of B. ( A and B may
each consist of one or more attributes.)

B is functionally
A B
dependent on A

Determinant Refers to the attribute or group of attributes on

the left-hand side of the arrow of a functional
dependency
1. Single-valued Functional Dependency:
• Database is a collection of related information in which
information depends on another information.
• The information is either single-valued or multi-valued. Eg.
Name of person, DOB are single-valued but phone no. is
multi-valued attribute.
• The single-valued functional dependency is s_id → sname
from relation student(s_id, sname, address, DOB, course)

2. Multi-valued Functional Dependency:

• A multi-valued dependency exists when a relation R has at
least 3 attributes (like A, B, C).
• e.g. published-book(b_id, author_name, price)
Name of particular author is determined by b_id
attribute. B_id → author_name Also b_id → price
• but it is difficult to determine price of book using author
name or vice versa. So this dependency is called as multi-
valued functional dependency.
Functional Dependencies (2)
3. Fully functional dependency: it occurs only in a relation
with composite primary key. Fully functional dependency
occurs when one or more non key attributes are depending on all
parts of the composite primary key.
• Example: Stud_course(s_id, sname, contact_no, course_id,
cname, credit_hours, grade)
• Here the composite primary key is s_id + course_id.
• Attribute grade is fully functionally dependent on the primary
key (s_id + course_id) because both parts of primary keys are
needed to determine grade.
• On other hand both sname, contact_no attributes are not fully
functionally dependent on the primary key.
• Also cname and credit_hourse are not fully functional
dependent on the primary key because only course_id is
needed to determine their values.
Functional Dependencies (3)
4. Partially functional dependency: it occurs only in a relation
with composite primary key. Partial functional dependency
occurs when one or more non key attributes are depending on a
part of the primary key.
e.g. To determine name of the student or contact no. We can use
only s_id attribute which is part of the primary key.
{s_id} → {s_name, contact_no}

5. Tracient (Transitive) functional dependency:

Functional dependency is said to be transitive if it is indirectly
form by using two functional dependencies.
Example: in the expression X→ Y →Z, if X, Y, and Z are
attributes of a table such that if Y is functionally dependent on X
and Z is functionally dependent on Y then Z is Transitively
dependent on X via Y.
Course_id → s_name →s_age then course_id → s_age
Functional Dependencies (4)
6. Trivial functional dependency:
• The dependency of an attribute on a set of attributes is known
as trivial functional dependency if the set of attributes contain
the attribute itself.
• Means that the right-hand side is a subset ( not necessarily a
proper subset) of the left-hand side of the FD. Functional
dependency of the form A → B is trivial if B is a subset of A.
• The functional dependency {A,B} → A is trivial. In a relation,
if A is depend on a set of attribute AB and also the attribute A
is subset of AB then this functional dependency is said to be
trivial.
For example:
staffNo, sName → sName
staffNo, sName → staffNo

We are normally more interested in nontrivial dependencies

because they represent integrity constraints for the relation.
Functional Dependencies (5)
7. Non Trivial functional dependency:
 It is inverse to trivial dependency.
 Functional dependency is said to be non trivial if none of the
attributes of right-hand side of FDs are part of the left-hand
side attributes.
 Functional dependency of the form A → B is non-trivial if
values in B are not present in A i.e. (B is not a subset of A).
 Example : {s_id} → {s_name}