Materialized Query Tables
29.7 Materialized Query Tables
Materialized views are supported in DB2 in Linux, Unix, and Windows as well as on the z/ OS platforms. A materialized view can be any general view definition on one or more tables or views. A materialized view is useful since it maintains
a persistent copy of the view data to enable faster query processing. In DB2 a materialized view is called a materialized query table ( MQT ). MQT s are specified by using the create table statement as shown by the example in Figure 29.15.
In DB2 , MQT s can reference other MQT s to create a tree or forest of dependent views. These MQT s are highly scalable as they can be partitioned in an MPP environment and can have MDC clustering keys. MQT s are most valuable if the database engine can route queries to them seamlessly and also if the database engine can maintain them efficiently whenever possible. DB2 provides both of these features.
29.7.1 Query Routing to MQTs
The query-compiler infrastructure in DB2 is ideally suited to leverage the full power of MQT s. The internal QGM model allows the compiler to match the input query against the available MQT definitions and choose appropriate MQT s for consideration. After matching, the compiler considers several options for opti- mization. They include the base query as well as suitable MQT reroute versions. The optimizer loops through these options before choosing the optimal version for execution. The entire flow of the reroute and optimization is shown in Fig- ure 29.16.
29.7.2 Maintenance of MQTs
MQT s are useful only if the database engine provides efficient techniques for maintenance. There are two dimensions to maintenance: time and cost. In the time dimension, the two choices are immediate or deferred. DB2 supports both these choices. If one selects immediate, then internal triggers are created and compiled
29.7 Materialized Query Tables 1213
SQL query
Query semantics (validate reroute possibility)
MQT candidate match phase
MQT definitions
Query candidates
Optimization phase
Select best plan
Figure 29.16 MQT matching and optimization in DB2.
into the insert, update, or delete statements of the source objects to process the updates to the dependent MQT s. In the case of deferred maintenance, the updated tables are moved into an integrity mode and an explicit refresh statement must be issued to perform the maintenance. In the size dimension, the choices are incremental or full. Incremental maintenance implies that only the recently updated rows should be used for maintenance. Full maintenance implies that the entire MQT
be refreshed from its sources. The matrix in Figure 29.17 shows the two dimensions and the options that are most useful along these dimensions. For instance, immediate and full maintenance are not compatible unless the sources are extremely small. DB2 also allows for the MQT s to be maintained by user. In this case, the refresh of the MQT s is determined by users performing explicit processing using SQL or utilities.
The following commands provide one simple example of performing deferred maintenance for the emp dept materialized view after a load operation to one of its sources.
Full Immediate
Choices
Incremental
Usually no Deferred
Figure 29.17 Options for MQT maintenance in DB2.
1214 Chapter 29 IBM DB2 Universal Database
load from newdata.txt of type del insert into employee ;
refresh table emp dept
Parts
» Indian Institute of Technology, Bombay
» Data Mining and Information Retrieval
» Structure of Relational Databases
» Database Schema When we talk about a database, we must differentiate between the database
» Basic Structure of SQL Queries
» Modification of the Database
» • Embedded SQL : Like dynamic SQL , embedded SQL provides a means by
» Advanced Aggregation Features**
» The Cartesian-Product Operation
» The Tuple Relational Calculus
» The Entity-Relationship Model
» • For an n-ary relationship set with an arrow on one of its edges, the primary
» Entity-Relationship Design Issues
» Representation of Generalization
» Alternative Notations for Modeling Data
» Other Aspects of Database Design
» Features of Good Relational Designs
» Atomic Domains and First Normal Form
» Decomposition Using Functional Dependencies
» BCNF Decomposition Algorithm
» Decomposition Using Multivalued Dependencies
» Application Programs and User Interfaces
» Overview of Physical Storage Media
» Magnetic Disk and Flash Storage
» Organization of Records in Files
» Comparison of Ordered Indexing and Hashing
» Implementation of Pipelining
» Evaluation Algorithms for Pipelining
» Transformation of Relational Expressions
» (A, r ), the number of distinct values that appear in the relation r for attribute
» Advanced Topics in Query Optimization**
» Transaction Atomicity and Durability
» Transaction Isolation and Atomicity
» Implementation of Isolation Levels
» Transactions as SQL Statements
» Weak Levels of Consistency in Practice
» Concurrency in Index Structures**
» Failure with Loss of Nonvolatile Storage
» Early Lock Release and Logical Undo Operations
» Centralized and Client – Server Architectures
» Parallelism on Multicore Processors
» Recovery and Concurrency Control
» Distributed Query Processing
» Heterogeneous Distributed Databases
» Partitioning and Retrieving Data
» Transactions and Replication
» Decision-Tree Construction Algorithm
» Relevance Ranking Using Terms
» Synonyms, Homonyms, and Ontologies
» Crawling and Indexing the Web
» Information Retrieval: Beyond Ranking of Pages
» Structured Types and Inheritance in SQL
» Array and Multiset Types in SQL
» Application Program Interfaces to XML
» Native Storage within a Relational Database
» Other Issues in Application Development
» Representation of Geographic Data
» Transaction-Processing Monitors
» Real-Time Transaction Systems
» PostgreSQL Implementation of MVCC
» Database Design and Querying Tools
» Database Administration Tools
» Business Intelligence Features
Show more