physical database design distributed .ppt

Physical Database Design
and Tuning
Copyright © 2004 Pearson Education, Inc.

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 16-2
Chapter Outline
1. Physical Database Design in Relational Databases
2. An Overview of Database Tuning in Relational
Systems.

1. Physical Database Design in Relational
Databases
Factors that Influence Physical Database Design:
A. Analyzing the database queries and transactions
For each query, the following information is needed.
1) The files that will be accessed by the query;
2) Whether the selection condition is an equality,inequality,
or a range condition.
3) The attributes on which any join conditions or conditions
to link multiple tables or objects for the query are
specified;
4) The attributes whose values will be retrieved by the query.

Factors that Influence Physical Database Design (cont.)
A. Analyzing the database queries and transactions (cont.)
For each update transaction or operation, the following
information is needed.
1) The files that will be updated;
2) The type of operation on each file (insert, update or delete);
3) The attributes on which selection conditions for a delete or
update operation are specified;
4) The attributes whose values will be changed by an update
operation.

B. Analyzing the expected frequency of invocation of queries and
transactions
– The expected frequency information, along with the attribute
information collected on each query and transaction, is used to
compile a cumulative list of expected frequency of use for all
the queries and transactions.
– It is expressed as the expected frequency of using each
attribute in each file as a selection attribute or join attribute,
over all the queries and transactions.

C. Analyzing the time constraints of queries and transactions
– Performance 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 structure.
D. Analyzing the expected frequencies of update operations
A minimum number of access paths should be specified for a file that is updated
frequently.
E. Analyzing the uniqueness constraints on attributes.
Access paths should be specified on all candidate key attributes — or set of attributes
— that are either the primary key or constrained to be unique.

 Design decisions about indexing
1. Whether to index an attribute?
2. What attribute or attributes to index on?
3. Whether to set up a clustered index?
4. Whether to use a hash index over a tree index?
5. Whether to use dynamic hashing for the file?
Physical Database Design Decisions

Physical Database Design Decisions
 Denormalization as a design decision for speeding up
queries
– The goal of normalization is to separate the logically related
attributes into tables to minimize redundancy and thereby
avoid the update anomalies that cause an extra processing
overhead to maintain consistency of the database.
– The goal of denormalization is to improve the performance
of frequently occurring queries and transactions. (Typically
the designer adds to a table attributes that are needed for
answering queries or producing reports so that a join with
another table is avoided.)

2. An Overview of Database Tuning in
Relational Systems
 Tuning: the process of continuing to revise/adjust the
physical database design by monitoring resource utilization as
well as internal DBMS processing to reveal bottlenecks such
as contention for the same data or devices.
 Goal:
– To make application run faster
– To lower the response time of queries/transactions
– To improve the overall throughput of transactions

Statistics internally
collected in DBMSs:
 Size of individual tables
 Number of distinct values in a
column
 The number of times a particular
query or transaction is
submitted/executed in an interval
of time
 The times required for different
phases of query and transaction
processing
Statistics obtained from
monitoring:
 Storage statistics
 I/O and device performance
statistics
 Query/transaction processing
statistics
 Locking/logging related
statistics
 Index statistics
A brief overview of the tuning process

Problems to be considered in tuning:
Problems to be considered in tuning:
 How to minimize overhead of logging and
unnecessary dumping of data?
 How to optimize buffer size and scheduling of
processes?
 How to allocate resources such as disks, RAM and
processes for most efficient utilization?

 Reasons to tuning indexes
– Certain queries may take too long to run for lack of an index;
– Certain indexes may not get utilized at all;
– Certain indexes may be causing excessive overhead because the index
is on an attribute that undergoes frequent changes
 Options to tuning indexes
– Drop or/and build new indexes
– Change a non-clustered index to a clustered index (and vice versa)
– Rebuilding the index
Tuning Indexes

Tuning the Database Design
 Dynamically changed processing requirements
need to be addressed by making changes to the
conceptual schema if necessary and to reflect those
changes into the logical schema and physical design.

Tuning the Database Design (cont.)
 Possible changes to the database design
– Existing tables may be joined (denormalized) because certain
attributes from two or more tables are frequently needed together.
– For the given set of tables, there may be alternative design choices, all
of which achieve 3NF or BCNF. One may be replaced by the other.
– A relation of the form R(K, A, B, C, D, …) that is in BCNF can be
stored into multiple tables that are also in BCNF by replicating the key
K in each table.this is called vertical partitioning
– Attribute(s) from one table may be repeated in another even though
this creates redundancy and potential anomalies.
– Apply horizontal partitioning as well as vertical partitioning if
necessary.

Tuning Queries
 Indications for tuning queries
– A query issues too many disk accesses
– The query plan shows that relevant indexes are not being
used.
 Typical instances for query tuning
1. Many query optimizers do not use indexes in the presence
of arithmetic expressions, numerical comparisons of
attributes of different sizes and precision, NULL
comparisons, and sub-string comparisons.
2. Indexes are often not used for nested queries using IN;

Tuning Queries (cont.)
 Typical instances for query tuning (cont.)
3. Some DISTINCTs may be redundant and can be avoided
without changing the result.
4. Unnecessary use of temporary result tables can be avoided
by collapsing multiple queries into a single query unless
the temporary relation is needed for some intermediate
processing.
5. In some situations involving using of correlated queries,
temporaries are useful.
6. If multiple options for join condition are possible, choose
one that uses a clustering index and avoid those that
contain string comparisons.

Tuning Queries (cont.)
 Typical instances for query tuning (cont.)
7. The order of tables in the FROM clause may affect the join
processing.
8. Many applications are based on views that define the data
of interest to those applications. Sometimes these views
become an overkill.

Additional Query Tuning Guidelines
1. A query with multiple selection conditions that are connected
via OR may not be prompting the query optimizer to use any
index. Such a query may be split up and expressed as a union
of queries, each with a condition on an attribute that causes an
index to be used.
2. Apply the following transformations
– NOT condition may be transformed into a positive expression.
– Embedded SELECT blocks may be replaced by joins.
– If an equality join is set up between two tables, the range predicate on
the joining attribute set up in one table may be repeated for the other
table
3. WHERE conditions may be rewritten to utilize the indexes on
multiple columns.

physical database design distributed .ppt

More Related Content

Similar to physical database design distributed .ppt (20)

More from ubaidullah75790 (20)

Recently uploaded (20)

physical database design distributed .ppt