IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
    
     Home      Products      Services & industry solutions      Support & downloads      My IBM     
developerworks > My developerWorks >  Dashboard > IBM Database Wiki > ... > Best Practices > Best Practice - Physical Database Design
developerWorks
Log In   View a printable version of the current page.
Best Practice - Physical Database Design
Added by torodanhan, last edited by torodanhan on Apr 01, 2009  (view change)
Labels: 
(None)

  Physical Database Design

Physical database design is the single most important factor that impacts database performance. Physical database design covers all of the design features that relate to the physical structure of the database such as datatype selection, table normalization and denormalization, indexes, materialized views, data clustering, multidimensional data clustering, table (range) partitioning, and database (hash) partitioning.

Good physical database design reduces hardware resource utilization (I/O, CPU, and network) and improves your administrative efficiency. This, in turn, can help you achieve the following potential benefits to your business:

  • Increased performance of applications that use the database, resulting in better response times and higher end-user satisfaction
  • Reduced IT administrative costs, giving you the ability to manage a wider scope of databases and respond quicker to changes in application requirements
  • Reduced IT hardware costs
  • Improved backup and recovery elapsed time

Figure 1. Illustration of a physical database system

Figure 1 shows an illustration of a physical database system. The three heavy dark-boxed vertical rectangles indicate three distinct database instances. All other square or rectangular boxes represent storage blocks on disk. All symbols represent data values within the table (such as geography or month).

In this example, a table has been hash-partitioned across three instances called P1, P2, and P3. The table has been range-partitioned by month, allowing data to be easily added and deleted by month. Indirectly, this also helps with queries that have predicates by month. Data within each table has been clustered using multidimensional clustering (MDC), and this serves as a further clustering within each range partition. The rows within the table are also indexed using regular row-based (RID-based) indexes. A materialized query table (MQT) is created on the table, which includes aggregated data (such as average sales by geography), which itself has indexing and MDC.

Table of contents

Best Practice - Physical Database Design - 01. Introduction to physical database design
Best Practice - Physical Database Design - 02. Goals of physical database design
Best Practice - Physical Database Design - 03. Datatype selection best practice
Best Practice - Physical Database Design - 04. Table normalization and denormalization
Best Practice - Physical Database Design - 05. Index design
Best Practice - Physical Database Design - 06. Data clustering and multidimensional clustering (MDC)
Best Practice - Physical Database Design - 07. Database partitioning (shared-nothing hash partitioning)
Best Practice - Physical Database Design - 08. Table (range) partitioning
Best Practice - Physical Database Design - 08. UNION All View(UAV) partitioning
Best Practice - Physical Database Design - 09. Database partitioning, table partitioning, and MDC in the same database design
Best Practice - Physical Database Design - 10. Roll-in and roll-out of data with table partitioning and MDC
Best Practice - Physical Database Design - 11. Rolling-in large data volumes using table partitioning
Best Practice - Physical Database Design - 12. Materialized query table (MQT)
Best Practice - Physical Database Design - 13. Post-design tools for improving designs for existing databases
Best Practice - Physical Database Design - 14. Conclusion
Best Practice - Physical Database Design - 15. Best Practices Summary



( You can also download a PDF of this Best Practice from http://download.boulder.ibm.com/ibmdl/pub/software/dw/dm/db2/bestpractices/DB2BP_Physical_Design_0508I.pdf which may not contain updates made in this wiki. )

Docs Best Practice - Physical Database Design - 01. Introduction to physical database design (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 02. Goals of physical database design (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 03. Datatype selection best practice (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 04. Table normalization and denormalization (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 05. Index design (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 06. Data clustering and multidimensional clustering (MDC) (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 07. Database partitioning (shared-nothing hash partitioning) (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 08. Table (range) partitioning (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 08. UNION All View(UAV) partitioning (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 09. Database partitioning, table partitioning, and MDC in the same database design (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 10. Roll-in and roll-out of data with table partitioning and MDC (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 11. Rolling-in large data volumes using table partitioning (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 12. Materialized query table (MQT) (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 13. Post-design tools for improving designs for existing databases (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 14. Conclusion (IBM Database Wiki)
Docs Best Practice - Physical Database Design - 15. Best Practices Summary (IBM Database Wiki)


    About IBM Privacy Contact