A data warehouse stores information that is collected from multiple, heterogeneous information sources for the purpose of complex querying and analysis [IK93, Wid95]. The information in the warehouse is typically processed and integrated before it is loaded in order to detect and resolve any inconsistencies and discrepancies among related data items from different sources. Since the amount of information in a data warehouse tends to be large and queries may involve hundreds of complex aggregates at a time, the organization of the data warehouse becomes a critical factor in supporting efficient online analytical query processing (OLAP) as well as in allowing periodic maintenance of the warehouse contents. Data in the warehouse is often organized in summary tables, or materialized views [Rou97], which represent pre-computed portions of the most frequently asked queries. In this way, the warehouse query processor avoids having to scan the large data sets for each query, a task that is even more wasteful if the query occurs frequently. However, in order to keep these materialized views consistent with the data at the sources, the views have to be maintained. Rather than periodically refreshing the entire view, a process that may be time consuming and wasteful, a view can be maintained in an incremental fashion, whereby only the portions of the view which are affected by the changes in the relevant sources are updated [GM95, ZGH+95].

Besides this so-called view maintenance or update cost, each materialized view in the warehouse also requires additional storage space which must be taken into account when deciding which and how many views to materialize. For example, given a set of frequently asked OLAP queries, materializing all possible views will certainly increase query response time but will also raise the update costs for the warehouse and may exceed the available storage capacity. Thus by trading space for time and vice versa, the warehouse administrator must carefully decide on a particular warehouse configuration which balances the three important factors given above: query response time, maintenance cost, and storage space. The problem of selecting a set of materialized views for a particular warehouse configuration which represents a desirable balance among the three costs is known as the view 1 selection problem .

In this paper we focus on a solution to the maintenancecost view selection problem which minimizes query response time given varying upper bounds on the maintenance cost, assuming unlimited amount of storage space because storage space is regarded cheap and not a critical resource. Specifically, we explore the view selection problem in the context of OR view graphs, in which any view can be computed from any of its related views. Although the view selection problem has been addressed previously (e.g., see [Gup97], [GM99], [TS97]), existing algorithms do not perform well when computing warehouse configurations involving more than 20-25 views or so. In those cases, the search space becomes too large for any kind of exhaustive search method and even the best heuristics can only compute acceptable solutions for a small set of special cases of the problem. To this end, we have designed a solution involving randomization techniques which have proven successful in other combinatorial problems. We show that our solution is superior to existing solutions in terms of both its expected run-time behavior as well as the quality of the warehouse configurations found. The analysis proves that our genetic algorithm yields a solution that lies within 90% of the optimal query benefit while at the same time exhibiting only a linear increase in execution time. We expect our algorithm to be useful in data warehouse design; most importantly in those scenarios where the queries which are supported by the existing warehouse views change frequently, making it necessary to reconfigure the warehouse efficiently and quickly. Supporting data warehouse evolution in this way may increase the usefulness of the data warehousing concept even further.

The paper is organized as follows. In the Sec. 2 we present an overview of the related work. Sec. 3 describes our technical approach. Specifically, we briefly introduce the idea behind genetic algorithms (which are a special class of randomized algorithms) and how we are using the technique to find an efficient solution to the view selection problem. In Sec. 4 we describe the implementation of our prototype which was used to generate the simulation runs which we present and analyze in Sec. 5. Sec. 6 concludes the paper with a summary of our results and future plans. 2

All of the related work on view selection uses some form of greedy strategy or heuristics-based searching technique to avoid having to exhaustively traverse the solution space in search of the optimal solution. The problem of selecting additional structures for materialization was first studied by Roussopoulos [Rou82] who proposed to materialize view indices rather than the actual views themselves. 1 Sometimes the problem is also referred to as the view index selection problem (VIS) when the solution includes a recommendation on which index structures should be maintained in support of the materialized views. View indices are similar to views except that instead of storing the tuples in the views directly, each tuple in the view index consists of pointers to the tuples in the base relations that derive the view tuple. The algorithm is based on A* to find an optimal set of view indexes but uses a very simple cost model for updating the view which does not take into account which subviews have been selected. As a result, the maintenance cost for the selected view set is not very realistic.

More recently, Ross et al. [RSS96] and Labio et al. [LQA97] have examined the same problem using exhaustive search algorithms that make use of heuristics for pruning the search space. The work by Labio et al. is an extension of the work by Ross et al. considering indexes and also improving upon the efficiency of the algorithm. In addition, Labio et al. are the first to provide a valuable set of rules and guidelines for choosing a set of views and indexes when their algorithm cannot compute the optimal warehouse configuration within a reasonable time due to the complexity of the solution. Similarly, Theodoratos et al. [TS97] present an exhaustive search algorithm with pruning to find a warehouse configuration for answering a set of queries given unlimited space for storing the views. Their work also focuses on minimizing query evaluation and view maintenance. [HRU96] present and analyze greedy algorithms for selection of views in the special case of “data cubes” that come within 63% of the optimal configuration. However, their calculations do not figure in the update costs for the selected views.

Our work is most closely related to that of Gupta [GM99] who has used both the greedy approach as well as the A* algorithm for solving the maintenance-cost view selection problem in the context of both OR/AND view graphs and the general case of AND-OR view graphs. His approach also balances query response time and view maintenance cost while assuming an unlimited amount of storage space. 3

In [Gup97] the view selection problem is stated to be NPhard (see, for example, [Coo71, GJ79]), as there is a straightforward reduction to the minimum set cover problem. Roughly speaking, it is very difficult to find an optimal solution to problems in this class because of the fact that the solution space grows exponentially as the problem size increases. Although some good solutions for NP-hard problems in general and the view selection problem in specific exist, such approaches encounter significant problems with performance when the problem size grows above a certain limit. More recent approaches use randomized algorithms in solving NP-hard problems. Randomized algorithms are based on statistical concepts where the large search space can be explored randomly using an evaluation function to guide the search process closer to the desired goal. Randomized algorithms can find a reasonable solution within a relatively short period of time by trading executing time for quality. Although the resulting solution is only near-optimal, this reduction is not as drastic as the reduction in execution time. Usually, the solution is within a few percentage points of the optimal solution which makes randomized algorithm an attractive alternative to traditional approaches such as the ones outlined in Sec. 2, for example.

Our approach uses a genetic algorithm, which is one form of a randomized algorithm. The motivation to use genetic algorithms in solving the view selection problem was based on the observation that data warehouses can have a large number of views and the queries that must be supported may change very frequently. Thus, a fast solution is needed to provide new configurations for the data warehouse: an ideal starting point for the genetic algorithm. However, genetic algorithms do not provide a magical solution by themselves and their success (or failure) often depends on the proper problem specification, the set-up of the algorithm, as well as the outcome of the extremely difficult and tedious fine-tuning of the algorithm that must be performed during many test runs. After a brief overview of genetic algorithms, we provide details on how to apply these techniques to design an optimal solution to the view selection problem. Specifically, we elaborate on a suitable representation of the solution space as well as the necessary evaluation functions needed by our genetic algorithm. 3.1

A genome represents a candidate solution of the problem to be solved. A genome can be represented appropriately as a string as follows: Either as a binary string composed of 0s and 1s, or as a string of alphanumeric characters. The content of the string is flexible, but the representation of the solution must be carefully designed so that it is possible to properly represent all possible solutions. As alphanumeric strings are good for representing solutions to ordering problems and binary strings are used for selection problems, we use a binary string to represent a solution. The views in the OR view graph may be enumerated as v1, v2, …, vm where m is the total number of views. We can represent a selection of these views as a binary string of m bits. If the bit in position i (starting from the leftmost bit as position 1) is 1, view vi is selected. Otherwise, view vi is not selected. For example, the bit string 001101001 encodes the fact that only views v3, v4, v6 and v9 are selected.

The initial population consists of a pool of randomly generated bit strings of size m. In future implementations, however, it is straightforward to start with an initial population which represents a favorable configuration based on external knowledge about the problem and its solution. It will be interesting to see if and how this affects the quality as well as the run-time of our algorithm. For the experiments described in this paper, we have chosen a population size of 30.

Step 3 – Selection, Crossover, Mutation, Termination The selection process uses the roulette wheel method. The crossover and mutation operators are assigned probabilities pc and pm, respectively. The specific values used in our simulation are 0.001 and 0.9. The crossover operation is applied to two genomes by exchanging information between the two, thereby creating two new genomes. Crossover works as follows:

Each genome is selected with a probability of pc. Pair genomes.

For each pair, do the following : // Assuming two genomes // g1 = (b1 b2 ... bpos bpos+1 ... bm) and // g2 = (c1 c2 ... cpos cpos+1 ... cm) (1) Randomly decide a crossover point pos. (2) Exchange information among genomes, and replace g1, g2 with g1', g2' // (ex) g1' = (b1 b2 ... bpos cpos+1 ... cm) and // g2' = (c1 c2 ... cpos bpos+1 ... bm)

For each bit in genome,

mutate (flip) bit with probability of pm The selection, crossover, mutation and evaluation (described in Step 4) processes will be repeated in a loop until the termination condition is satisfied. The termination condition is reached after 400 generations. The values used for the probabilities and termination condition are based on empirical values used in other examples, and although reference [Mic94] mentioned that no improvement was observed after 500 generations, we have reduced this value to 400 in our experiments since our algorithm converged more rapidly.

The fitness function measures how good a solution (i.e., a genome) is by providing a fitness value as follows: If the fitness is high, the solution is closer to an optimal solution; if the fitness is low, the solution is far away from the optimal solution. There are many possible fitness functions and finding the best possible one (i.e., one that can truthfully evaluate the quality of a particular warehouse configuration) requires a lot of fine-tuning. For our problem, the fitness function has to evaluate a genome (i.e., a set of selected views to materialize) with respect to the query benefit as well as with respect to the maintenance constraint. This is similar to the goal of the 0/1 knapsack problem, for example, where the goal is to maximize the profit of the packed load while satisfying a specific capacity constraint of the knapsack. The difference is that in the view selection problem, when a view is selected, the benefit will not only depend on the view itself but also on other views that are selected. A good way to model such a complex problem is by introducing a penalty value as part of the fitness function. This penalty value will reduce the fitness if the maintenance constraint is not satisfied. When the maintenance constraint is satisfied, the penalty value will have no effect and only the query benefit should be evaluated. We have applied the penalty value in three different ways when calculating the fitness: Subtract mode (S), Divide mode (D), and Subtract & Divide mode (SD). 3-4 The subtract mode will calculate the fitness by subtracting the penalty value from the query benefit. Because the fitness value is not allowed to have a negative value, the fitness is set to 0 when the result of the calculation becomes negative (i.e., the penalty value exceeds the query benefit). The divide mode will divide the query benefit with the penalty value in an effort to reduce the query benefit. When the penalty value is less than 1, the division is not performed in order to prevent the fitness from increasing. The subtract & divide mode combines the two methods discussed above. If the query benefit is larger than the penalty value, the subtract mode is used. If the penalty value is larger than the query benefit, the divide mode is used. The penalty value can be calculated using a penalty function, which will be discussed afterwards. Thus, we have defined a fitness function, called Eval, as follows: Subtract mode (S): Eval(x)=B(G,M)-Pen(x) (if B(G,M)-Pen(x)≥ 0) =0 (if B(G,M)-Pen(x)<0) for all x[i]=1, vi ∈ M for all x[i]=0, vi ∉ M Divide mode (D): Eval(x)=B(G,M) / Pen(x) (if Pen(x)>1)

=B(G,M) (if Pen(x)≤ 1) Subtract&Divide mode (SD): Eval(x)=B(G,M)-Pen(x) (if B(G,M)>Pen(x)) =B(G,M)/Pen(x) (if Pen(x)≥ B(G,M) and

Pen(x) >1) =B(G,M) (if Pen(x)≥ B(G,M) and

Pen(x) ≤ 1) where B is the query benefit function, Pen is the penalty function, x is a genome, G is the OR view graph, and M is the set of selected views given by x.

The penalty function itself can also take on various forms. For example, we have experimented with logarithmic, linear and exponential penalty functions as shown in ④ ,⑤ , and ⑥ .

Logarithmic penalty (LG):

Pen(x) = log 2 ( 1 + ρ ( U(M) - S ) ) Linear penalty (LN):

Pen(x) = ( 1 + ρ ( U(M) - S ) ) Exponential penalty (EX):

Pen(x) = ( 1 + ρ ( U(M) - S ) )2 where ρ is defined as a constant calculated from the given OR-view graph G, U(M) is the total maintenance cost of the set of materialized views M, and S is the maintenance cost constraint.

We combined the three types of penalty modes (i.e., S, D, SD) and the three types of penalty functions (i.e., LG, LN, EX) in our prototype to evaluate and determine the best possible strategy for solving the view selection problem. Please note, the details as well as the formulas for the query benefit function B(G,M), the total maintenance cost U(M), and ρ are provided in a full version of this paper ② ① ③ ⑤ ⑥ ④ [LH99] which is available for download via ftp and http from our publication server. 4