1. Self-tuning of the Relationships among Rules’ Components in Active Database Systems
David Botzer and Opher Etzion
IEEE Transactions on Knowledge and Data Engineering, Mar. 2004

2. Active Database Systems
Detect events and trigger actions according to specified conditions.
Event-Condition-Action (ECA) Rules
Event detected
Rules identified
Conditions evaluated
Actions activated (event triggered)

3. Performance Issues No flexibility for: Possible solution:
Partitioning rules to transactions
Specifying timing constraints
Possible solution:
Add design primitives
Use “Coupling Modes” as a design primitive

4. Coupling Modes Example: Definition:
A package of decisions about the interrelationships among ECA components.
Example:
A condition should be evaluated immediately when the event is detected, delaying any other activity in the transaction.

5. Solution Problems
Coupling mode research prototypes express only a subset of design alternatives.
Event/Condition
Condition/Action
Systems designers might not employ design primitives / coupling modes correctly.

6. Author’s Proposed Solution
Self-tuning model for optimizing:
Response time of system activities (esp. time critical)
Storage space of system parameters/variables
Goal (cost-benefit) function for system needs
Uses independent, specified “goal function”
Two-phase:
Select from original coupling modes
Select from new “coupling policies”

7. Original Coupling Modes
Immediate
Deferred
Detached Parallel Dependent
Detached Sequential Dependent
Detached Independent

8. Coupling Mode Extension
Reason:
Provides a significant quantity of new possible combinations
Allows for interrule coupling, i.e., rule -> event -> rule
Basic Assumption:
Any ECA component can be located in any transaction, and any transaction can include any ECA component.

9. Coupling Policies (1)
Five coupling modes are extended to “coupling policies”
Transaction
Timing
Abort
Commit
Synchronization
Let ‘X’ and ‘Y’ be various rule components (event, condition, action)

10. Coupling Policies (2) The Transaction Policy The Timing Policy
Partition ECA components into transactions
X and Y are executed in same/different transaction
The Timing Policy
Temporal relationship between ECA execution times
Given X and Y are in the same transaction, Y is executed immediately/generally after X

11. Coupling Policies (3) The Abort Policy The Commit Policy
Abort dependencies among transactions that execute related components
The Commit Policy
A transaction may commit when it finishes, or wait for the commit of related transactions

12. Coupling Policies (4) The Synchronization Policy
The synchronization between components and the conclusion of related transactions
Seven possibilities
X  Y
X  Commit/Abort (Y Transaction)
Y  Commit/Abort (X Transaction)
Commit/Abort (X Transaction)  Y
Commit/Abort (X Transaction)  Commit/Abort (Y Transaction)
Commit/Abort (Y Transaction)  Commit/Abort (X Transaction)
No Synchronization

13. The Optimization Model

14. The Goal Function Definition: Independent of the solution’s algorithm
A function that the optimization model strives to minimize.
Independent of the solution’s algorithm
Provided for every specific application
Configured by system designer via GUI

15. Goal Function Establishment
Consider:
Important activities for system evaluation
Negligible activities
Parameter stabilization
Parameter Measurement:
Time costs
Rules probabilities
Etc.

16. Conclusion Author’s Further Research:
Creation/evaluation of specific goal functions
Establishment of appropriate learning mechanism