Chapter16

Elmasri/Navathe, Fundamentals of Database Systems, 4th Edition


Practical Database Design And Tuning

Chapter 16


Physical Database Design in Relational Databases

An Overview of Database Tuning in Relational Systems

Chapter Outline


Meaningful design decisions can be made if we know the queries, transactions, and applications that are expected to run on the database.

The physical database design decision mainly considers the storage structure and access paths for database files. It requires analyzing:

The database queries and transactionsThe expected frequency of invocation of queries and transactionsThe time constraints of queries and transactionsThe expected frequencies of update operationsThe uniqueness constraints on attributes

Physical Database Design


Design decision about indexing a relation falls into the following categories:

Whether to index an attribute

What attribute or attributes to index on

Whether to set up a clustered index

Whether to use a hash index over a tree index

Whether to use dynamic hashing for the file

Physical Database Design


The goals of Database tuning:To make applications run faster

To lower the response time of queries/transactions

To improve the overall throughput of transactions

Tuning indexes for the following reasons:Certain queries may take too long to run for lack of index

Certain indexes may not get utilized at all

Certain indexes may be causing excessive overhead

An Overview of Database Tuning


Changes to the conceptual schema for tuning the database may be of the following nature:

Existing tables may be joined (denormalization)But the resulting redundancy causes problems during updates and redesigns

An alternative design for a given set of tables

Vertical partitioning a table. For example the table EMPLOYEE (SSN, Name, Phone, Grade, Salary)May be split into two tablesEMPLOYEE1 (SSN, Name, Phone) ,EMPLOYEE2 (SSN, Grade, Salary)

Makes some sense if some attributes tend to be accessed often or together, and others rarely

Attribute(s) from one table may be repeated in anothere.g. Partname might be spelt out instead of using PartNumberHorizontal partitioning e.g. one table per product numberBut this makes queries that need all of the data more complex



Query tuning may be needed in the following situations:

When query optimizer do not use indexes because of the presence of particular operators (e.g., >, <, etc.)

Indexes are often not uses for nested queries using IN, e.g., SELECT SSN

FROM EMPLOYEEWHERE DNO IN (SELECT DNUMBER FROM EPARTMENT WHERE MGRSSN=‘333445555’);

May not use the index on DNO, whereas using DNO = DNUMBER in the WHERE of query block may cause

theindex to be used.



Avoid using DISTINCT, since it causes a sort operationBut relying on duplicates is not part of the relational model

Avoid unnecessary use of temporary result tables

If multiple options for join condition are possible, choose one that uses a clustering index and avoid those that contain string comparisons

In the FROM clause, reorder the tables such that the JOIN processing implies to scan the smaller tables and uses the indexes from large tables

Avoid using view tables that are defined by a join, as long as the base tables can be used



Sometimes temporary results are useful, e.g. the query SELECT SSN FROM EMPLOYEE EWHERE SALARY = SELECT MAX (SALARY)

FROM EMPLOYEE M WHERE M.DNO = E.DNO;

can be broken into

SELECT MAX (SALARY) AS HSAL, DNO INTO TEMPFROM EMPLOYEE GROUP BY DNO; and

SELECT SSNFROM EMPLOYEE, TEMPWHERE SALARY=HSAL AND EMPLOYEE.DNO =

TEMP.DNO;



Warnings

Optimisation doesn’t always destroy clarity, and maintainability, but it certainly can

Today’s clever optimisation hack could become tomorrow’s unmaintainable bottleneck

Optimisation capabilities and biases of database systems vary, and are subject to change

The normalised forms eliminate redundancy for a reason

Strive for a structure that is fast without redundancy

Find out what the database is really doing(e.g. “explain” command in PostgreSQL)


More Warnings

Using hint commands is better than writing mangled SQL

“Premature optimization is the root of all evil”― C. A. R. Hoare

“More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.” ― W.A. Wulf

"Performance anxiety leads to premature optimization." ― Anonymous (http://c2.com/cgi/wiki?PrematureOptimization)

Documents

Chapter16