Batch: A4 Roll No.

: 1821008

Experiment No. 03

Grade: AA / AB / BB / BC / CC / CD /DD

Title: Database Tuning

______________________________________________________________________________
____

Objective:Tuning the database to improve system performance

____________________________________________________________________________
______
Expected Outcome of Experiment:

CO1 : Design and tune database.

______________________________________________________________________________
_____
Books/ Journals/ Websites referred:

1. Elmasri & Navathe “ fundamentals of Database Systems” V edition. PEARSON

Education.
2. Korth, Silberschatzsu darshan “Database systems, concepts” 5th edition McGraw
Hill.
3. Raghu Ramkrishnan & Johannes Gehrke “Database Management System” Tata
McGraw Hill. III edition.

___________________________________________________________________________
_____
Pre Lab/ Prior Concepts: Database, ER diagram, Relation mapping, SQL

______________________________________________________________________________
______
 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Implementation Details:

CREATION OF TABLE QUERIES:

create table Seller(name varchar(20),

Address varchar(40),
GST_ID int PRIMARY KEY,
Age int);

create table Consumers

(name varchar(20),
id int PRIMARY KEY,
address varchar(30),
Age int,
DOB varchar(20));

create table Payment

(payment_id varchar(30) PRIMARY KEY,
order_id int NOT NULL);

create table Courier_service

(shipping_info int PRIMARY KEY,
order_id int );

create table about_us

(contact_no int,
Distribution_center varchar(10));

Perform following;

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 2

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

1. Index tuning

Index tuning is part of database tuning for selecting and creating indexes. The index tuning
goal is to reduce the query processing time. Potential use of indexes in dynamic environments
with several ad-hoc queries in advance is a difficult task. Index tuning involves the queries based
on indexes and the indexes are created automatically on-the-fly. No explicit actions are needed by
the database users for index tuning.

Example 1:

Before index creation:

select * from consumers where id = 200 ;

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 3

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 4

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

After index tuning:

create index index_con on consumers(id);

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 5

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Example 2:

select * from seller where gst_id in

(select gst_id from seller where age > 36)

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 6

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 7

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

After index creation:

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 8

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Example 3:

Before index creation

SELECT payment.order_id, courier_service.shipping_info, payment.payment_id

FROM payment
INNER JOIN courier_service ON payment.order_id=courier_service.order_id;

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 9

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

After index creation-

As we can see above, after applying index tuning, It took less time for the same query to get
executed, and it also compares less number of rows.

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 10

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Effect of Index Tuning:

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 11

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)
The index tuning goal is to reduce the query processing time. Index tuning involves thequeries
based on indexes and the indexes are created automatically on-the-fly. No explicitactions are
needed by the database users for index tuning.

2. Query Tuning

Sql Statements are used to retrieve data from the database. We can get same results by
writing different sql queries. But use of the best query is important when performance is
considered. So you need to sql query tuning based on the requirement. Here is the list of queries
which we use regularly and how these sql queries can be optimized for better performance.

Example 1:

Before Tuning

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 12

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 13

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

After Tuning-

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 14

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

By using * it takes longer time to execute the query and displays the output whereas using select
clause along with column names took less time which is more effective.

Example 2:

SELECT address, count(address) FROM consumers GROUP BY address

HAVING address != 'Ghatkopar';

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 15

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 16

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Without using having clause-

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 17

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

In the above query having clause takes longer time for execution along with where clause
whereas using only where clause displays the output much faster.

Example 3:

Select * from courier_service natural join payment;

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 18

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

The cross joins produces the cross product or Cartesian product of two tables whereas the natural
join is based on all the columns having the same name and data types in both the tables

Select * from courier_service cross join payment;

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 19

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 20

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

3. Database Tuning

In, Database Tuning we are doing denormalization of tables as well as columns.

Denormlization is required as it will improve the performance by minimizing the need for joins
and reducing the number of tables and columns in database.

Considering the scenario where two tables are selected :

1) Courier_service
2) payment

by applying denormalization given below:

courier_service

shipping_info order_id

payment

payment_info order_id

By applying de-normalization

New payment table includes:

shipping_info payment_info order_id

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 21

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Courier_service

Payment

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 22

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

After applying join

Effect of database tuning:

By applying join between courier_service and payment table we can display all tables when
required to display summary of particular order but by using de-normalization it can be reduced
of using join instead of using new table payment which consist of all info about payment and
courier service which is much effective in database tuning.

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 23

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

New payment table (npayment):

insert into npayment (shipping_info,payment_id,order_id)

values(112,'RS99',2000),
(113,'HS95',2001),
(114,'VS100',2419);

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 24

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 25

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)

Conclusion:
Hence, here we have learnt about Index tuning which reduces the overall response and
running time of a query, Query Tuning which reduces overall running time when the
query is directly executed and the concept Database Tuning by doing de-normalization.

Post Lab Descriptive Questions:

1. What are the factors that influence Physical Database Design?

ANS-

Factors That Influence Physical Database Design

Physical design is an activity where the goal is not only to create the appropriate
structuring of data in storage, but also to do so in a way that guarantees good
performance. For a given conceptual schema, there are many physical design alternatives
in a given DBMS. It is not possible to make meaningful physical design decisions and
performance analyses until the database designer knows the mix of queries, transactions,
and applications that are expected to run on the database. This is called the job mix for
the particular set of database system applications. The database administrators/designers
must analyze these applications, their expected frequencies of invocation, any timing
constraints on their execution speed, the expected frequency of update operations, and
any unique constraints on attributes. We discuss each of these factors next.

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 26

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)
A. Analyzing the Database Queries and Transactions.

Before undertaking the physical database design, we must have a good idea of the
intended use of the database by defining in a high-level form the queries and
transactions that are expected to run on the database. For each retrieval query, the
following information about the query would be needed:

The files that will be accessed by the query. The attributes on which any selection
conditions for the query are specified. Whether the selection condition is equality,
inequality, or a range condition. The attributes on which any join conditions or conditions
to link multiple tables or objects for the query are specified. The attributes whose values
will be retrieved by the query. The attributes listed in items 2 and 4 above are candidates
for the definition of access structures, such as indexes, hash keys, or sorting of the file.

For each update operation or update transaction, the following information would be
needed:

The files that will be updated.

The type of operation on each file (insert, update, or delete).

The attributes on which selection conditions for a delete or update are specified.

The attributes whose values will be changed by an update operation.

Again, the attributes listed in item 3 are candidates for access structures on the files,
because they would be used to locate the records that will be updated or deleted. On the
other hand, the attributes listed in item 4 are candidates for avoiding an access structure,
since modifying them will require updating the access structures.

B. Analyzing the Expected Frequency of Invocation of Queries and Transactions.

Besides identifying the characteristics of expected retrieval queries and update

transactions, we must consider their expected rates of invocation. This frequency
information, along with the attribute information collected on each query and

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 27

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)
transaction, is used to compile a cumulative list of the expected fre-quency of use for
all queries and transactions. This is expressed as the expected fre-quency of using
each attribute in each file as a selection attribute or a join attribute, over all the queries
and transactions. Generally, for large volumes of processing, the informal 80–20
rule can be used: approximately 80 percent of the processing is accounted for by only
20 percent of the queries and transactions. Therefore, in prac-tical situations, it is
rarely necessary to collect exhaustive statistics and invocation rates on all the queries
and transactions; it is sufficient to determine the 20 percent or so most important ones.

Analyzing the Time Constraints of Queries and Transactions-

Some queries and transactions may have stringent performance constraints. For example,
a transaction may have the constraint that it should terminate within 5 seconds on 95
percent of the occasions when it is invoked, and that it should never take more than 20
seconds. Such timing constraints place further priorities on the attributes that are
candidates for access paths. The selection attributes used by queries and transactions with
time constraints become higher-priority candidates for primary access structures for the
files, because the primary access structures are generally the most efficient for locating
records in a file.

Analyzing the Expected Frequencies of Update Operations-

A minimum number of access paths should be specified for a file that is frequently
updated, because updating the access paths themselves slows down the update operations.
For example, if a file that has frequent record insertions has 10 indexes on 10 different
attributes, each of these indexes must be updated whenever a new record is inserted. The
overhead for updating 10 indexes can slow down the insert operations.

Analyzing the Uniqueness Constraints on Attributes-

Access paths should be specified on all candidate key attributes—or sets of attributes—
that are either the primary key of a file or unique attributes. The existence of an index (or
other access path) makes it sufficient to only search the index when checking this
uniqueness constraint, since all values of the attribute will exist in the leaf nodes of the
index. For example, when inserting a new record, if a key attribute value of the new

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 28

 K. J. Somaiya College of Engineering, Mumbai-77
(Autonomous College Affiliated to University of Mumbai)
record already exists in the index, the insertion of the new record should be rejected, since
it would violate the uniqueness constraint on the attribute.

Once the preceding information is compiled, it is possible to address the physical

database design decisions, which consist mainly of deciding on the storage structures and
access paths for the database files.

Date: _____________

Department of Computer Engineering ADBMS Sem-V July-Nov 2018 Page 29