Database Reference

In-Depth Information

Aggregation:
Generators allow us to duplicate a constraint multiple

times by replacing a free variable in the
ASSERT
clause with a range

of values given by the generator. In many situations, we want a con-

straint acting on an
aggregate
value calculated over the elements in a

generator. As a simple example, we can rewrite the original storage con-

straint used in physical design tools using generators and aggregates as

follows:

FORIinC

ASSERT sum(size(I))
≤
200M

As a more complex example, the following constraint ensures that the

combined size of all indexes defined over table
T
is not larger than four

times the size of the table itself:

FORIinC

WHERE table(I) = TABLES["T"]

ASSERT sum(size(I))

≤

4 * size(TABLES["T"])

where
TABLES
is the collection of all the tables in the database, and

function
size
on a table returns the size of its primary index.

Nested constraints:
Constraints can have free variables that are bound

by outer generators, effectively resulting in nested constraints. The net

effect of the outer generator is to duplicate the inner constraint by bind-

ing each generated value to the free variable in the inner constraint. The

following constraint generalizes the previous one over all tables:

FOR T in TABLES

FORIinC

WHERE table(I) = T

ASSERT sum(size(I))
≤
4 * size(T)

Soft constraints:
The implicit meaning of the language defined so far is

that a configuration has to satisfy all constraints to be valid. Among

those valid configurations, we keep the one with the minimum expected

cost for the input workload. There are situations, however, in which

we would prefer a relaxed notion of constraint. For instance, consider a

constraint that enforces that every non-
UPDATE
query results in at least

10% improvement over the currently deployed configuration. In general,

no configuration may satisfy this constraint, especially in conjunction

with a storage constraint. In these situations, a better alternative is

to specify a
soft constraint
, which states that the final configuration

should get as close as possible to a 10% improvement (a configuration

with, say, 8% improvement would still be considered valid). We specify

Search WWH ::

Custom Search