The document discusses physical database design and tuning in relational database systems. It covers topics such as indexing attributes, partitioning tables horizontally and vertically, avoiding unnecessary operations that impact performance like DISTINCT, and using temporary tables strategically. The goals of database tuning are to make applications faster, lower response times, and improve transaction throughput. Warnings are also provided about premature optimization potentially hurting clarity and maintainability.

2. Practical Database Design And Tuning Chapter 16

3. Physical Database Design in Relational Databases An Overview of Database Tuning in Relational Systems Chapter Outline

4. 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 transactions The expected frequency of invocation of queries and transactions The time constraints of queries and transactions The expected frequencies of update operations The uniqueness constraints on attributes Physical Database Design

5. 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

6. 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

7. 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 tables EMPLOYEE1 ( 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 another e.g. Partname might be spelt out instead of using PartNumber Horizontal partitioning e.g. one table per product number But this makes queries that need all of the data more complex An Overview of Database Tuning

8. 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 EMPLOYEE WHERE 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 the index to be used. An Overview of Database Tuning

9. Avoid using DISTINCT, since it causes a sort operation But 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 An Overview of Database Tuning

10. Sometimes temporary results are useful, e.g. the query SELECT SSN FROM EMPLOYEE E WHERE SALARY = SELECT MAX (SALARY) FROM EMPLOYEE M WHERE M.DNO = E.DNO; can be broken into SELECT MAX (SALARY) AS HSAL, DNO INTO TEMP FROM EMPLOYEE GROUP BY DNO; and SELECT SSN FROM EMPLOYEE, TEMP WHERE SALARY=HSAL AND EMPLOYEE.DNO = TEMP.DNO; An Overview of Database Tuning

11. 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)

12. 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 &quot;Performance anxiety leads to premature optimization.&quot; ― Anonymous ( http://c2.com/ cgi / wiki ? PrematureOptimization )