Views present data from one or more tables to the user in some way that is attractive to business users, but departs from the underlying table structure in which the data is actually stored. Unfortunately, you cannot always automatically manipulate data in views in the same way as in the underlying tables.
Rule-based Logical Views solve this. They let you determine what should happen when a user manipulates the view. You do this by declaring special rules that execute when a user performs a manipulation (INSERT, UPDATE, or DELETE) via the view.
For example, you can make sure that when a user inserts a record into a Logical View, this INSERT is translated by special rules into multiple INSERTs into 2 or more different underlying tables.
You can make a Logical View rule-based for each of the 3 DML actions (INSERT, UPDATE, DELETE) separately. Do this by setting the Use Constraints ... flag for that action. Each flag informs the Rules Engine that the default behavior for that action is to be overridden by your special rule(s). Here is a view that is rule-based for INSERT and UPDATE action, but not for the DELETE action:
Logical View rule-based for Insert and Update but not for Delete
|
You declare the special rules underlying the rule-based logical view by creating transitional constraints on the view. There are two general strategies:
•Providing a transitional constraint that calls a USoft batch job where you can provide the implementation as a sequence of statements. Providing the implementation as a sequence of statements gives you the possibility to execute statements in a specific order. In this strategy, all the special rules (DML statements) are found in the same place. This makes the implementation easier to read, maintain and debug. The disadvantage is that you need to provide a job and an external set for the sole purpose of performing a DML action on a view. •Providing only transitional constraints that implement the special rules directly. This solution has the advantage of only using the constraint mechanism, but you cannot enforce the order in which the constraint statements are executed. If you choose the constraints-only strategy, a special "Rule-based Implementation" tab in the Logical Views tab or window helps you debug and maintain your constraints. Here, you can view and edit the constraints connected to the view without having to navigate to the Constraints tab or window:
List view in "Rule-based Implementation" tab in Logical Views tab/window
|
See also
Logical views
How to define a rule-based logical view
Example: Rule-based logical view
|