Physical Data Warehouse Design - Data Warehouse Systems: Design and Implementation - page 231

them also need to be updated. The process of updating a materialized view in
response to changes in the base relations is called view maintenance . Under
certain conditions, it is possible to compute changes to the view caused by
changes in the underlying relations without recomputing the entire view from
scratch. This is called incremental view maintenance .Asthisproblemis
central to data warehousing, we will describe it with some detail.
The view maintenance problem can be analyzed through four dimen-
sions:
￿ Information: Refers to the information available for view maintenance, like
integrity constraints, keys, access to base relations, and so on.
￿ Modification: Refers to the kinds of modifications that can be handled by
the maintenance algorithm, namely, insertions, deletions, and updates; the
latter are usually treated as deletions followed by insertions.
￿ Language: Refers to the language used to define the view, most often SQL.
Aggregation and recursion are also issues in this dimension.
￿ Instance: Refers to whether or not the algorithm works for every instance
of the database or for a subset of all instances.
For example, consider a relation Sales ( ProductKey , CustomerKey , Quantity )
and a materialized view TopProducts that keeps the products for which at
least one customer ordered more than 150 units. The view TopProducts is
defined as follows:
TopProducts = π ProductKey ( σ Quantity > 150 ( Sales )) .
It is clear that inserting a tuple like ( p2 , c3 , 110 ) in the table Sales would
have no effect on the view, since the tuple does not satisfy the view condition.
However, the insertion of the tuple ( p2 , c3 , 160 ) would possibly modify the
view. An algorithm can easily update it without accessing the base relation,
basically adding the product if it is not already in the view.
Let us now analyze the deletion of a tuple from Sales , for example,
( p2 , c3 , 160 ). We cannot delete p2 from the view until checking if p2 has
not been ordered by some other customer in a quantity greater than 150,
which requires to scan the relation Sales .
In summary, although in some cases insertion can be performed just
accessing the materialized view, deletion always requires further information.
Consider now a view FoodCustomers which includes a join. The view
contains the customers that ordered at least one product in the food
category (we use the simplified and denormalized Product dimension defined
in Sect. 5.7 ):
FoodCustomers = π CustomerKey ( σ CategoryName= ' Food ' ( Product ) ∗ Sales )
If we insert the tuple ( p3 , c4 , 170 )intable Sales , we cannot know if c4 will
be in the view FoodCustomers (of course assuming that it is not in the view
already) unless we check in the base relations whether or not p3 is in the
food category.