View Selection and Materialization

Introduction

Nowadays, materialized views are increasingly being supported by a variety of commercial DBMS to speed up query response time. This technique is also very useful in data warehousing for optimizing OLAP queries. In such systems, data are extracted in advance and stored in a repository. Then, user queries are addressed directly to the data warehouse system and processed without needing to access the data sources. At an abstract level, a data warehouse can be seen as a set of materialized views. Furthermore, new applications of the problem of view selection arise namely in data placement in distributed databases and in peer to peer data sharing systems.

The problem addressed in this paper is similar to that of deciding which views to materialize in data warehousing. However, most existing view selection methods are static. Moreover, none of these methods have considered the problem of dematerializing the already materialized views. Yet it is a very important issue since the size of storage space is usually restricted.

Many database systems support creation and use of materialized views. The presence of appropriate materialized views can significantly improve performance and speed up the processing of queries by several orders of magnitude. For this reason the problem of view selection has received significant attention in recent literature. The majority of these works (Yang, 1997; Kotidis, 1999; Theodoratos, 2001; Baril, 2003) presents the solution for data warehousing environments that are used for On-Line Analytical Processing (OLAP) and Decision Support System applications. The problem in this context is the following: given a database scheme R, a storage space B, and a workload of queries Q, choose a set of views V over R to materialize, whose combined size is at most B. The goal of view selection process is to find a set of views that minimizes the expected cost of evaluating the queries in Q. Traditionally, view selection has been carried out statically. With static view selection, a system administrator decides what kinds of queries might be carried out in the system. Several models and tools have been designed to take the expected query workload and choose set of views to materialize; e.g., (Yang, 1997; Gupta, 1999; Baril, 2003). Obviously, static selection of views has several weaknesses: (i) the query workload is often not predictable; (ii) even if the workload can be predicted, the workload is likely to change, and the workload might change so quickly that the system administrator cannot adjust the view selection quickly enough so the static view selection might very quickly become outdated. This means that the administrator should monitor the query pattern and periodically “recalibrate” the materialized views by rerunning these algorithms. This task for a large warehouse where many users with different profiles submit their queries is rather complicated and time consuming