DB2 database materialized Views: Use of materialized query tables for MQTS

Materialized query tables using MQTS (materialized query tables, MQTS)

The definition of an MQT is based on the results of the query. Mqts can significantly improve the performance of queries. This tutorial introduces Mqts, Summary tables (summary table), and staging tables, and shows you how to create and use materialized query tables with practical examples.

An MQT is a table that is defined based on the result of a query. The MQT contains data from one or more tables on which the MQT definition is based. Summary tables (also known as Auto summary tables [AST]) should be familiar to IBM DB2 for Linux, UNIX, and Windows users, and they can be viewed as special mqts. Fullselect is part of the summary table definition, which contains a GROUP by clause that summarizes the data in the table referenced in Fullselect.

You can consider mqts as a materialized view. Both the view and the MQT are defined based on a query. The query on which the view is based will run whenever the view is referenced. However, Mqts actually store the query results as data, and you can use the data in the MQT instead of the data in the underlying table. Mqts can significantly improve the performance of queries, especially for complex queries. If the optimizer determines that a part of a query or query can be resolved with an MQT, the query can be overridden to take advantage of MQTS. MQTS can be defined when a table is created, either by system maintenance or by user maintenance.

The data in this MQT is maintained by the system. When creating this type of MQT, you can specify whether the table data is either refresh IMMEDIATE or refresh DEFERRED. You can specify how data is maintained by using the REFRESH keyword. DEFERRED means that the data in the table can be refreshed at any time through the Refresh table statement. System-maintained Mqts, either the Refresh DEFERRED type or the refresh IMMEDIATE type, are not allowed for INSERT, UPDATE, or delete operations. However, for a system-maintained MQT of the REFRESH IMMEDIATE type, you can update the underlying table's changes (that is, insert, UPDATE, or delete operations).

The following section shows an example of a system-maintained MQT that creates a REFRESH IMMEDIATE type. This table, named EMP, is based on the underlying table EMPLOYEE and DEPARTMENT in the SAMPLE database. Since the REFRESH IMMEDIATE MQT requires at least one unique key from each table referenced within the query to appear in the select list, we first define a uniqueness constraint on the EMPNO column of the EMPLOYEE table, in addition to the DEPARTMENT table DE Defines a uniqueness constraint on the Ptno column. The data initially DEFERRED clause means that when you execute a CREATE table statement, you do not insert it into the table. After the MQT is created, it is in the check pending state and cannot be queried until the SET INTEGRITY statement is executed on it. The IMMEDIATE CHECKED clause specifies that the data must be checked against the query used to define the MQT and that the data be refreshed. The NOT incremental clause specifies an integrity check for the entire table.

CONNECT TO SAMPLE
...
ALTER TABLE EMPLOYEE ADD UNIQUE (EMPNO)
ALTER TABLE DEPARTMENT ADD UNIQUE (DEPTNO)
CREATE TABLE EMP AS (SELECT E.EMPNO, E.FIRSTNME, E.LASTNAME, E.PHONENO, D.DEPTNO,
SUBSTR(D.DEPTNAME, 1, 12) AS DEPARTMENT, D.MGRNO FROM EMPLOYEE E, DEPARTMENT D
WHERE E.WORKDEPT = D.DEPTNO)
DATA INITIALLY DEFERRED REFRESH IMMEDIATE
SET INTEGRITY FOR EMP IMMEDIATE CHECKED NOT INCREMENTAL