Query Transformations

28.4.2.1 Query Transformations

Oracle does query optimization in several steps. One such step is to perform var- ious query transformations and rewrites that fundamentally change the structure of the query. Another step is to perform access path selection to determine access paths, join methods, and join order. Since some transformations are not always beneficial, Oracle uses cost-based query transformations where the transforma- tions and access path selection are interleaved. For each transformation that is tried, access path selection is performed in order to generate a cost estimate, and the transformation is accepted or rejected based on the cost for the resulting execution plan.

Some of the major types of transformations and rewrites supported by Oracle are as follows:

• View merging . A view reference in a query is replaced by the view definition.

This transformation is not applicable to all views. • Complex view merging . Oracle offers this feature for certain classes of views

that are not subject to regular view merging because they have a group by or select distinct in the view definition. If such a view is joined to other tables, Oracle can commute the joins and the sort or hash operation used for the group by or distinct.

1174 Chapter 28 Oracle

• Subquery flattening . Oracle has a variety of transformations that convert var-

ious classes of subqueries into joins, semijoins, or antijoins. Such conversion is also called decorrelation, and is described briefly in Section 13.4.4.

• Materialized view rewrite . Oracle has the ability to rewrite a query automati-

cally to take advantage of materialized views. If some part of the query can be matched up with an existing materialized view, Oracle can replace that part of the query with a reference to the table in which the view is materialized. If need be, Oracle adds join conditions or group by operations to preserve the semantics of the query. If multiple materialized views are applicable, Oracle picks the one that gives the greatest advantage in reducing the amount of data that have to be processed. In addition, Oracle subjects both the rewritten query and the original version to the full optimization process producing an execution plan and an associated cost estimate for each. Oracle then decides whether to execute the rewritten or the original version of the query on the basis of the cost estimates.

• Star transformation . Oracle supports a technique for evaluating queries

against star schemas, known as the star transformation. When a query con- tains a join of a fact table with dimension tables, and selections on attributes from the dimension tables, the query is transformed by deleting the join con- dition between the fact table and the dimension tables, and replacing the selection condition on each dimension table by a subquery of the form:

fact table.fk i in

(select pk from dimension table i

where < conditions on dimension table i > ) One such subquery is generated for each dimension that has some constrain-

ing predicate. If the dimension has a snowflake schema (see Section 20.2), the subquery will contain a join of the applicable tables that make up the dimension.

Oracle uses the values that are returned from each subquery to probe an index on the corresponding fact table column, getting a bitmap as a result. The bitmaps generated from different subqueries are combined by a bitmap and operation. The resultant bitmap can be used to access matching fact table rows. Hence, only those rows in the fact table that simultaneously match the conditions on the constrained dimensions will be accessed. Both the decision on whether the use of a subquery for a particular dimension is cost-effective, and the decision on whether the rewritten query is better than the original, are based on the optimizer’s cost estimates.