Database Reference
In-Depth Information
merging of two views as described in this section is as follows:
V 1 =(
S 1
, T
, J 1
, R 1
, Z 1
, )
V 2 =(
S 2
, T
, J 2
, R 2
, Z 2
, )
, R 1 R 2
V 1
V 2 =(
S 1
S 2
, T
, J 1
J 2
, Z 1
Z 2
,
)
{
required
columns
}
We note that all the previous transformations take into account column
equivalences. If both input views contain a join predicate R
.
x
=
S
.
y , then the
.
<
.
<
range predicates R
10 are considered to be the same.
The following example illustrates the ideas described in this section. If V 1
and V 2 are the following materialized views:
x
10 and S
y
V 1 = SELECT x, y
V 2 = SELECT y, z
FROM R, S
FROM R, S
WHERE R.x = S.y AND
WHERE R.x = S.y AND
10 < R.a < 20 AND
15 < R.a < 50 AND
R.b < 10 AND
R.b > 5 AND R.c > 5 AND
R.x + S.d < 8
S.y + S.d < 8 AND
R.d * R.d = 2
the merge of V 1 and V 2 is
V 1
V 2 = SELECT x, y, z, a, b, c, d
FROM R, S
WHERE R.x = S.y AND
10 < R.a < 50 AND
R.x + S.d < 8
8.2.2.2
Case 2: Grouping Columns
We now consider the case of merging views that involve group-by clauses.
Grouping operators partition the input relation into disjoint subsets and
return a representative tuple and some aggregates from each group. Con-
ceptually, we see a GROUP BY operator as a postprocessing step after the
evaluation of the SPJ subquery. Consider the merged view obtained when
the grouping columns are eliminated from the input views. If the group-
ing columns in the input views are different, each view partitions the in-
put relation in different ways. We then need to partition the merged view
in the coarsest way that still allows us to recreate each input view. For
that purpose, the set of grouping columns in the merged view must be the
union of the grouping columns of the input views. Additionally, each column
that is added to the select clause due to predicate relaxation in the input
views must also be added as a grouping column. Note that we need to han-
dle a special case properly. If one of the input views contains no group-by
Search WWH ::




Custom Search