Cost-Based Optimization of Integration Flows - Datenbanken ...

3.2 Prerequisites for Cost-Based Optimization
In [LRD06], semantic constraints are modeled locally for each individual plan by the
user in order to preserve semantic correctness by using application knowledge. There,
constraints between operators are explicitly specified in order to exclude these operators
from any plan rewriting. In contrast to this approach, we define semantic correctness of
plans with global constraints—that are independent of specific plans and thus, reduce the
required modeling and configuration efforts for a user—as follows:
Definition 3.1 (Semantic Correctness). Let P denote an original plan and let P ′ denote
a plan that was created by rewriting P . Then, semantic correctness of P ′ refers to
the semantic equivalence of P ≡ P ′ . This equivalence property is given if the following
constraints hold:
1. There are no dependencies δ between operators of concurrent subflows (parallel subflows
of a Fork operator).
2. If there is a dependency δ between an interaction-oriented operator and another
operator, the temporal order of them must be equivalent in P and P ′ .
3. If there are two interaction-oriented operators, where at least one performs a write
operation and both refer to the same external system, the temporal order of them
must be equivalent in P and P ′ .
4. If there exists an anti-dependency between two operators, the temporal order of these
operators must be equivalent in P and P ′ .
5. If there is a data dependency between two operators, the sequential order of these
operators must be equivalent in P and P ′ or the applied optimization technique must
guarantee semantic correctness (equivalent results) of the changed sequential order.
According to Rule 5, the specific optimization techniques decide whether or not operators,
with dependencies between these operators, can be reordered. This is necessary
because the reordering decision must be made based on the concrete involved operators
and their parameterizations. For example, two Selection operators can be reordered,
while this is impossible for a sequence of Selection and Projection operators if the selection
attribute is removed by the projection. In case there was a dependency δ between
two operators and if their sequential order (and thus, also the temporal order) was changed
when rewriting P to P ′ , the parameters of the two operators (and hence, the new data
flow) must be changed accordingly. Thus, when rewriting a plan, incremental maintenance
(transformation) of the dependency graph is applied as well. Due to the importance of
this dependency graph, we use Example 3.1 to illustrate its core concepts.
Example 3.1 (Dependency Graph). We use the plan P 3 from Example 2.6. Figure 3.2(a)
shows the related dependency graph. Consider the dependency δ D msg 3
. It is a data dependency
(D) over the message msg 3 from o 4 to o 3 ; i.e., operator o 4 reads the result of o 3
as one of its join operands. Hence, o 4 depends on o 3 . The dependency graph is used to
determine rewriting possibilities. For example, since there are no dependencies between
operators o 2 and o 3 and none of them is a writing interaction, we can insert a Fork operator
and execute those as parallel subflows (Figure 3.2(b)). If there are data dependencies
between local operators (no interaction-oriented operators), we can yet exchange their sequential
order (e.g., o 4 and o 5 by the optimization technique eager group-by). However,
we are not allowed to exchange o 6 and o 7 because this would change the external behavior.
Further, the output and anti dependencies determine that we are not allowed to exchange
the order of the involved operators (e.g., o 3 and o 6 ).
37