The rule class properties specified at the time of creation include the event management policies that the Rules Manager should enforce for each rules application. In the case of rules defined for composite event structures, the primitive events are added to the system one at a time. These events are later combined with other primitive events to form composite events that match one or more rule conditions. Depending on the join conditions between primitive events, a primitive event can participate in a 1 to 1, 1 to N, or N-to-M relationship with other events to form one or more composite events. Application-specific requirements for reusing primitive events and for handling duplicate composite events are supported using rule class properties and they are broadly classified as follows:
Consumption -- determines if an event can be used for multiple rule executions or a single rule execution
Conflict resolution or ordering -- determines the order in which matching rules with various events are to be executed
Duration -- determines the lifetime of unconsumed primitive events
Auto-commit -- determines if each interaction with a rule class should be committed automatically
Storage -- determines the storage characteristics of the rule class in the database
Equal -- specifies the common equality join predicates for all the rules in a rule class, that is, what are the lists of primitive event attributes that are equal in the composite events configured for a rule class
DML Events -- specifies when an event structure is created with one or more table alias attributes, that the corresponding rule class can be configured to consider the DML operation (INSERT
) on the corresponding tables as the events for which the rules are evaluated
The event management policies duration
and equal
are only applicable to rule classes configured for composite events. All other policies are applicable to rule classes configured for simple events as well as rule classes configured for composite events. Each rule class property is described in the sections that follow.
A primitive event used to form a composite event can be combined with other primitive events to form a different composite event. For example, two instances of the AddFlight
event can be combined with one instance of AddRentalCar
event to form two different composite events (that could match two different rules). In some rule applications, it is required that once a primitive event matches a rule on its own or in combination with other primitive events, it should not be used with any more rule executions. This implies that a primitive event used to form a composite event is consumed or removed from the system. The consumption
property for a rule class determines the policy regarding the reuse of primitive events in the system. The consumption policy is applicable to both the rules defined for simple events and the rules defined for composite events. Two modes of event consumption are possible:
EXCLUSIVE -- when the consumption mode is EXCLUSIVE
, a primitive event can be used to match only one rule (which ever matches first). Once the corresponding rule action is executed, this event is removed from the system, irrespective of the event duration specification (TRANSACTION
, SESSION
, or Elapsed time
).
SHARED -- when the consumption mode is SHARED
, a primitive event can be used to match any number of rules and execute their actions. The primitive event is removed from the system only when its duration specification is met. The default consumption policy for a rule class created with no consumption property is SHARED
.
Following the same example used previously, if two AddFlight
events are already added to the system, the next AddRentalCar
event could form two composite events that could match two or more rules. If the rule class is configured for EXCLUSIVE
consumption of events, only one of the rule actions can be executed using one of the composite events. This rule can be chosen deterministically if appropriate conflict resolution techniques are employed (see Chapter3).
The EXCLUSIVE
consumption policy for a rule class created for a simple event structure implies that, at most, one rule is executed for any event instance passed to the dbms_rlmgr.process_rules
procedure. If the event matches more than one rule, the rule that is chosen for execution is determined using the ordering property of the rule class (see Chapter3 that describes ordering). The rule class created for a primitive event structure can be configured with the EXCLUSIVE
event consumption policy using the following XML properties document (as the rlcls_prop
argument to the dbms_rlmgr.create_rule_class
procedure).
<simple consumption="exclusive"/>
Other valid forms of consumption specification within the rule class properties include the following:
<composite consumption="exclusive"/> <composite consumption="shared"/>
Rule applications can have different policies regarding the reuse of primitive events for a subset of primitive events used in a composite event. For such applications, the consumption policy can be specified for each primitive event type as a child element of the <composite>
element, such as the following:
<composite consumption="shared"> <object type="AddFlight" consumption="shared"> <object type="AddRentalCar" consumption="exclusive"> </composite>
The value for the consumption
attribute of the <composite>
element is used as the default value for all the primitive events in the composite event. This default value is overridden for a primitive event type by specifying it as the child element of the <composite>
element and specifying the consumption attribute for this element.
Specifying Custom Logic for Event Consumption
In addition to EXCLUSIVE
and SHARED
consumption policies, a rule class for composite events can be configured with a RULE
consumption policy, which allows individual rules in the rule class to use some custom logic for event consumption. The RULE
consumption policy can only be specified at the composite event level and when specified, the consumption policy for the primitive event type cannot be set to EXCLUSIVE
. When the rule class is configured for RULE
consumption policy, the action callback procedure and the rule class results view are created to return the identifiers for the individual primitive events matching a rule. These identifiers can be used to selectively consume some or all of the primitive events atomically. See the DBMS_RLMGR.CONSUME_PRIM_EVENTS
procedure for more information.
When an event matches a rule on its own or in combination with other primitive events, by default, the order of rule (action) executions is not deterministic. Some rule applications may need the matching rules to execute in a particular order, which is determined by some conflict resolution criteria. Additionally, in the case of exclusive consumption of events, only one of the matching rules is executed. Unless some conflict resolution criterion is specified, this rule is chosen randomly. One of the common techniques of conflict resolution is to order the resulting composite events and matching rules based on the event attribute values and the rule action preferences.
Conflict resolution among composite events
The composite events resulting from the addition of a primitive event can be ordered based on the attributes of the corresponding primitive events. For example, the travel services application may decide to resolve among a set of composite events, consisting of AddFlight
and AddRentalCar
primitive events, based on the primitive event creation times. So, the conflict resolution criterion for this composite event structure is represented as [Flt.rlm$CrtTime
, Car.rlm$CrtTime
], implying that an event with earliest creation time is consumed before the others. This notation is similar to that of an ORDER BY
clause in a SQL query. Optionally, the DESC
keyword can be used with some of the attributes to sort the events in descending order (see Chapter3 for complete syntax). When the rule class is configured for exclusive consumption of events, only the top-most event in this sorted list is chosen for rule execution.
Conflict resolution among matching rules for simple and composite events
A composite or a simple event can match one or more rules in a rule class. If more than one rule is matched, by default, their actions are executed in a non-deterministic order. If the order of the rule action executions is important, the rule identifiers and the action preferences associated with the rules can be used to sort the matching rules. For example, the travel services application can resolve among matching rules by using the conflict resolution criterion - [rlm$rule.PromoType
, rlm$rule.OfferedBy
, rlm$rule.rlm$ruleid
]. In this case, sorting the matching rules is done in ascending order and ordered first by the action preference PromoType
, then by the action preference OfferedBy
, then by the rule identifier rlm$ruleid
. As shown in this example, rlm$rule
is used to refer to any rule-specific attribute. The notation and semantics used for specifying conflict resolution criteria are similar to that of an ORDER BY
clause in a SQL query. Optionally, the DESC
keyword can be used with some of the attributes to sort the rules in the descending order (see Chapter3 for a complete syntax). When the rule class is configured for exclusive consumption of events, only the top-most rule in the sorted list is chosen for execution.
When a set of composite events matches a set of rules, the exact order of rule executions can be specified by combining the conflict resolution criterion for the composite events with that of the matching rules. The syntax for specifying the conflict resolution criteria is described in Chapter3.
The ORDERING
property of the rule class determines the order in which a set of rules that match a set of composite events or a simple event are executed. When the consumption policy for a composite event type or for some primitive event types is set to EXCLUSIVE
, the ordering property also determines the subset of rules that are executed. (The rest of the matching rules are ignored, because the exclusive events that are required to execute the rules are deleted after the first rule execution). The ordering property is applicable to both the rules defined for simple events and the rules defined for composite events.
In the case of a rule class created for a composite event structure, the addition of a primitive event to the system could form multiple composite events that could match multiple rules. So, the ordering of the resulting events and the matching rules can be specified using the attributes in the events, the action preferences associated with the rules, and the rule identifiers. For the travel services rule class example, the ordering of the events and the matching rules can be specified as follows:
<composite ordering="Flt.rlm$CrtTime, Car.rlm$CrtTime, rlm$rule.PromoType, rlm$rule.OfferedBy, rlm$rule.rlm$ruleid"/>
In this ascending column, attribute ranked, ordering specification, rlm$rule
is used to refer to the attributes associated with the rule class (action preferences PromoType
and OfferedBy
and the rule identifier rlm$ruleid
) and the variables declared for the primitive events in the composite event structure (Flt
for AddFlight
and Car
for AddRentalCar
) are used to access the primitive events' attribute values.
The ordering property can be combined with some other policies, such as consumption and duration. Other valid forms of ordering specification within the rule class properties include:
<composite consumption="exclusive" ordering="Flt.rlm$CrtTime, rlm$rule.PromoType, rlm$rule.rlm$ruleid DESC"/> <simple ordering="rlm$rule.PromoType, rlm$rule.OfferedBy, rlm$rule.rlm$ruleid/>
In the case of a rule class created for a simple event structure, as there is only one event at any point in time, the ordering is only based on the matched rules. So, only the rule identifier and action preferences associated with the rules are allowed in the ordering clause.
It is common for applications to generate events that will never trigger a rule firing, thus these events will never be consumed. The duration policy for primitive events determines the maximum lifetime of the events. When a primitive event is added to the Rules Manager for incremental evaluation of rules, the event and the evaluation results are stored in the database. These events are later combined with other matching primitive events to form a composite event that conclusively satisfies one or more rule conditions. However, there may not be a matching event to form a composite event. For example, the travel services rule discussed in Chapter2 may detect an AddFlight
event for a rule, but the corresponding AddRentalCar
event may not occur (or the AddRentalCar
event occurring may not be for a luxury car). So, the duration (or the life) of the primitive events should be set such that the incomplete (composite) events and the results from the incremental rule evaluations are deleted after a certain period.
The duration of a primitive event depends on the rule application and it can be classified into one of following four scenarios.
TRANSACTION: In this scenario, the primitive events added to the system during a database transaction are preserved until the end of the transaction (COMMIT
or ROLLBACK
). So, a rule for the composite event evaluates to true only if all the required primitive events are detected within a database transaction.
SESSION: In this scenario, the primitive events added during a database session are preserved until the end of the session (CONNECT
or DISCONNECT
). So, a rule for the composite event evaluates to true only if all the required primitive events are detected within a database session.
CALL: In some rule applications, a subset of primitive events are truly transient in that an event is considered for a possible match with the rules only at the instance at which the event is added. Such events do not contribute to the event history and they are not considered for any future rule matches. Hence, these events are said to be valid only for the duration of the call (PROCESS_RULES
or ADD_EVENT
) that processes the rules. A subset of primitive events within a composite event can be configured for the CALL
duration. A CALL
duration event contributes to a rule execution only if the event, in combination with other events in the system, evaluates a rule condition to true at the time of the call. Such events are not considered for rule matches after the call regardless of any rule executions during the call.
Elapsed time: In this scenario, the duration of a primitive event added to the system is determined by an event timeout associated with the rule class. The event timeout is specified as elapsed time (for example 10 hours, 3 days) and this is added to the creation time (determined by its rlm$CrtTime
attribute) to determine the exact time of event deletion.
The duration policy dictates the life span of the primitive events in the system. In the case of a rule class created for simple events, Rules Manager does not store the events in the system (as the rules are evaluated conclusively for each event). So, the duration policy is applicable only for the rule classes created for composite event structures. A rule class configured to reset all the primitive events at the end of each (database) transaction uses the following XML properties document:
<composite duration="transaction"/>
While specifying the duration as elapsed time, the value for the duration attribute can be specified in {[int] minutes | hours | days} format, such as shown here:
<composite duration="session"/> <composite duration="20 minutes"/> <composite duration="2 hours"/> <composite duration="10 days"/>
These specifications apply to all the primitive events that constitute the composite event. If different duration specifications are required for some primitive event types, they can be specified as child elements of the <composite>
element, such as shown here:
<composite duration="10 days"> <object type="AddFlight" duration="3 days"/> <object type="AddRentalCar" duration="call"/> </composite>
In this case, the value of 10 days for the duration
attribute of the <composite>
element is used as the default value for all the primitive events in the composite event. This default value is overridden for a primitive event type by specifying it as the child element of the <composite>
element and specifying the duration
attribute for this element, for example, as shown by the duration property call
specified for the AddRentalCar
event type. So these AddRentalCar
events would be discarded if they did not match a rule during either a PROCESS_RULES
or ADD_EVENT
call.
A restriction on the duration policy is that the TRANSACTION
or SESSION
values for the duration policy can only be specified at the composite event level. When specified, these values cannot be overridden at the primitive events level.
In rule applications using composite events, all the rules defined in a rule class have one or more common (equality) join predicates between two or more or all primitive events (that form a composite event). These join predicates are defined using the attributes of the corresponding primitive event types. For example, in the travel services application, the AddFlight
and AddRentalCar
events in a composite event are related through the customer identifiers in these primitive events (Flt.CustId = Car.CustId
). The rule class using a fixed number of distinct equality join predicates for its rules can be optimized by configuring the rule class as discussed in this section.
Note:
Use of theEQUAL
property at the rule class level is recommended for better performance.For a rule class configured for the composite event structure, the EQUAL
property identifies either the only equality join predicate that relates multiple primitive events within each composite event, or a list of the most common equality join predicates used in forming each composite event. If there is only one equality join predicate, the equal property is specified as a comma-delimited list of attributes, one from each primitive event structure configured for the rule class and it is used as the join predicate for all the rules in the rule class. This list identifies the primitive event attributes that must be equal to form a composite event. For example:
<composite equal="Flt.CustId, Car.CustId"/>
When the EQUAL
property is specified as a comma separated list of attributes, the rules in the corresponding rule class may skip the equality join predicates involving the same set of attributes. So, for a rule class created with the previous properties document, the following three rule conditions have the same effect:
<condition>
<and join="Flt.CustId = Car.CustId and Car.rlm$CrtTime > Flt.rlm$CrtTime ">
<object name="Flt"> Airline=''Abcair'' and ToCity=''Orlando'' </object>
<object> CarType = ''Luxury'' </object>
</and>
</condition>
<condition>
<and join="Car.rlm$CrtTime > Flt.rlm$CrtTime">
<object name="Flt"> Airline=''Abcair'' and ToCity=''Orlando'' </object>
<object name="Car"> CarType = ''Luxury'' </object>
</and>
</condition>
<condition>
<and equal="Flt.CustId, Car.CustId"
join="Car.rlm$CrtTime > Flt.rlm$CrtTime">
<object name="Flt"> Airline=''Abcair'' and ToCity=''Orlando'' </object>
<object> CarType = ''Luxury'' </object>
</and>
</condition>
The last rule condition in the previous example also demonstrates the use of the EQUAL
property for individual rules in a rule class. The EQUAL
property specification for a rule condition acts as a short representation of the equality join predicate, especially when the rule condition has ANY n or negation constructs. The list of attributes specified for the EQUAL
property are converted into appropriate join predicates and appended (as conjunctions) to the join condition of each rule in the rule class.
Another form of EQUAL
property specification for a rule class identifies a list of the most common equality join predicates in its rules. For this purpose, each EQUAL
property specification is grouped using parenthesis and alternate EQUAL
property specifications are separated using a vertical bar ( '|') character. For example, in a rule class created with two primitive events of the same RFIDRead
type, a subset of rules in the rule class may join the primitive events on their ItemId
attributes (reading1.ItemId = reading2.ItemId
). Another subset of the rules in the same rule class may relate the primitive events on their ReaderId
attributes (reading1.ReaderId = reading2.ReaderId
). The rule class can be optimized to process both types of these rules efficiently using the following equal property:
<composite equal="(reading1.ItemId, reading2.ItemId) | (reading1.ReaderId, reading2.ReaderId)"/>
The previous syntax for the EQUAL
property can be used to specify up to five alternate EQUAL
property specifications for a rule class. The alternate EQUAL
property specifications provide a means for optimizing the rule evaluation for the most common join predicates in a rule class and it does not automatically use any equality join predicates for its rules. The rules in the rule class are mapped into one of the alternate EQUAL
property specifications based on the EQUAL
property used for the individual rules. For example, the following rule's EQUAL
property specification matches one of the EQUAL
property specifications at the rule class level and hence, this rule is optimized:
<condition> <and equal="reading1.ItemId, reading2.ItemId"/> <object name="reading1"/> <object name="reading2"/> </and> </condition>
Hence, the EQUAL
property for individual rules in a rule class not only acts as a short representation for the equality join predicate but also helps map it into one of the alternate EQUAL
property specifications.
The STORAGE
attribute of the <simple>
or <composite>
element is used to specify the storage properties for the rule class table and the internal objects created for the rule class. By default, the database objects used to manage the rules in a rule class are created using user defaults for the storage properties (Example: tablespace specification). The value assigned for this attribute can be any valid storage properties that can be specified in a typical SQL CREATE TABLE
statement. The following XML properties document can be used (as the argument to the dbms_rlmgr.create_rule_class
procedure) to create a rule class for simple events that resides in a tablespace TBS_1
and uses exclusive consumption policy:
<simple storage="tablespace TBS_1" consumption="exclusive"/>
An example of specifying storage attributes in the rule class properties is as shown:
<composite storage="tablespace TBS_1"/>
In most cases, all the Rules Manager procedures commit immediately after each add rule, delete rule, and process rule operation. The rule class can be configured to follow transaction boundaries by turning off the auto-commit functionality. For this purpose, the AUTOCOMMIT
property can be specified in the rules class properties document. For example:
<simple autocommit="NO"/>
The AUTOCOMMIT
property can be specified for the rule class created for simple as well as composite events. Other valid forms of specifying the AUTOCOMMIT
property include:
<composite autocommit="NO" consumption="shared"/> <composite autocommit="YES"/>
When the AUTOCOMMIT
property is set to NO
, the set of Rules Manager operations (add rule, delete rule, and process rule) performed in a transaction can be rolled back by issuing a ROLLBACK
statement. An exception to this rule is when the action callback procedure (implemented by the end user) performs an irreversible operation (sending a mail, performing a data definition language (DDL) operation, commit, rollback, and so forth). A DDL operation within an action callback operation automatically commits all the operations performed in that transaction. To avoid this situation, any DDL operations should be performed in an autonomous transaction.
Turning off the AUTOCOMMIT
property for a rule class can limit the concurrent operations on the rule class. This is especially the case when the rules class is created for composite events that is configured for exclusive consumption policy. (In a transaction, the consumed events are locked until the transaction is committed and the other sessions may wait for these events to be released.)
The default value for the AUTOCOMMIT
property is dependent on other event management policies (see Table 3-1). The default value for this policy is NO
for a rule class configured for simple (non-composite) rules and a composite rule class configured with the SESSION
or TRANSACTION
duration policy. (These configurations do not pose issues with sharing of events across sessions). For all other configurations, a default value of YES
is used for the AUTOCOMMIT
property. Note that the AUTOCOMMIT
property cannot be set to YES
when the duration policy is set to TRANSACTION
. Also, the AUTOCOMMIT
property cannot be set to NO
when one or more primitive event types are configured for EXCLUSIVE
or RULE
consumption policy.
When the event structure is defined with one or more table alias constructs and the corresponding rule class is configured for DML events (see Chapter3) the AUTOCOMMIT
property is always set to NO
. Note that this could result in deadlocks while working with EXCLUSIVE
or RULE
consumption policies.
A rule class with the AUTOCOMMIT
property set to "NO
" cannot contain rules involving negation and a deadline (See Chapter4).
When an event structure is created with one or more table alias attributes (see Chapter3), then the corresponding rule class can be configured to consider the SQL INSERT
and SQL*Loader operations on the corresponding tables as the events for which the rules are evaluated. This rule class behavior can be enabled using the DMLEVENTS
property for the rule class:
<simple dmlevents="I"/>
This property can be specified for a rule class configured for simple and composite events. In the current release, UPDATE
and DELETE
operations on the underlying tables are ignored and only the INSERT
operations are recognized as events.
<composite dmlevents="I"/>
When the DMLEVENTS
policy is specified, the AUTOCOMMIT
policy for the rule class should be NO
. In this case, the AUTOCOMMIT
policy of NO
is allowed even when the consumption policy is set to EXCLUSIVE
or RULE
(which is considered an invalid combination when the DMLEVENTS
policy is not used). Note that the use of the EXCLUSIVE
or RULE
consumption policy with the DMLEVENTS
policy could result in application deadlocks.
Most of the rule class properties (or event management policies) described in this section can be mixed and matched while defining a rule class. However, some of the combinations of these properties are considered invalid as shown in Table 3-1. For example, if the rule classes' AUTOCOMMIT
property is set to YES
, setting the DURATION
policy to TRANSACTION
is invalid. This is because the events are deleted from the system as soon as they are added and they cannot be combined with other events to form composite events. The DMLEVENTS
policy has no direct influence on the valid and invalid combination of event management policies. This policy only effects the default value for the AUTOCOMMIT
policy.
Table 3-1 Valid and Invalid Rule Class Property Combinations
AUTOCOMMIT | CONSUMPTION | DURATION | |
---|---|---|---|
Invalid |
Yes |
-- |
Transaction |
Valid |
Yes |
-- |
Session |
Valid |
Yes |
-- |
[n] Units |
Valid |
No |
Shared |
-- |
Valid |
No |
Exclusive |
TransactionFoot 1 |
Valid |
No |
Exclusive |
SessionFootref 1 |
Invalid |
No |
Exclusive |
[n] UnitsFoot 2 |
Valid |
No |
RuleFoot 3 |
TransactionFootref 1 |
Valid |
No |
Rule |
SessionFootref 1 |
Invalid |
No |
Rule |
[n] UnitsFootref 2 |
SESSION
or TRANSACTION
mode has no concurrency issues across the database session, as each session gets a private copy of the events and incremental results.EXCLUSIVE
consumption policy locks some rows in order to mark them "consumed" and may not actually consume the rows. Such rows are kept from being consumed by other database sessions and thus result in deadlocks. So, it is recommended that the locked rows be released with AUTOCOMMIT="YES" property.RULE
is a special form of the EXCLUSIVE
consumption policy where the consumption of certain events is initiated by the end-user.The default values for various event management policies for a rule class configured for simple events are as follows:
CONSUMPTION : Shared DURATION : Infinite Duration (NULL) AUTOCOMMIT : No
The default values for the event management policies for a rule class configured for a composite event is sometimes dependent on other event management policies, as follows:
CONSUMPTION : Shared DURATION : Infinite Duration (NULL) AUTOCOMMIT IF DMLEVENTS = I : NO ELSE IF DURATION = TRANSACTION / SESSION : NO ELSE : YES
The rule applications considered so far use rule conditions that are defined on some application data. That is, the concept of an event instance exists in the application and it may or may not be stored in the database. Often however, the data in the event instances correspond to some rows stored in relational tables. For such applications, the row identifiers (ROWIDs) of these rows can be used to pass the data to the Rules Manager procedures by reference, for example using the event_inst
parameter to represent an event instance of the PROCESS_RULES
call (event_inst => :FlightDataRowid
). For this purpose, the corresponding event structure should be modeled using Expression Filter's table alias constructs. See the ADD_ELEMENTARY_ATTRIBUTE
procedure for more information. See Chapter9 and Appendix A for more examples.
For the travel services application considered in Chapter2, if the AddFlight
and AddRentalCar
primitive events are stored in two relational tables FlightData
and RentalCarData
respectively, the corresponding composite event structure can be created to refer to rows in these tables as follows:
BEGIN dbms_rlmgr.create_event_structure (event_structure => 'TSCompEvent'); dbms_rlmgr.add_elementary_attribute ( event_structure => 'TSCompEvent', attr_name => 'Flt', --- Prim event name attr_type => exf$table_alias('FlightData')); dbms_rlmgr.add_elementary_attribute ( event_structure => 'TSCompEvent', attr_name => 'Car', --- Prim event name attr_type => exf$table_alias('RentalCarData')); END;
Now the composite event structure TSCompEvent
can be used to configure a rule class (Same as step 2 in Chapter2). The representation of the rules in the rule class does not vary with this event structure. However, within the action callback procedure, the primitive event instances that match a rule are each passed in as ROWIDs from the corresponding tables and these ROWIDs can be used to obtain the original event data. Also, with this new event structure, the primitive event instances, for which the rules are processed, are passed in by reference using the ROWIDs for the corresponding table rows.
BEGIN dbms_rlmgr.process_rules ( rule_set_nm => 'TravelPromotion', event_type => 'FlightData', event_inst => :FlightDataRowid); -- rowid of a row --- END;
Note that the conditions corresponding to a primitive event are evaluated when the dbms_rlmgr.process_rules
procedure is invoked with the appropriate ROWID. However, Rules Manager does not keep track of any changes to the original row through an UPDATE
operation.
Optionally, the PROCESS_RULES
call can be eliminated by configuring the preceding rule class to consider all the INSERT
operations into the corresponding tables as events. This is done by setting the DMLEVENTS
property to "I" during rule class creation (see Chapter3). This specification automatically creates a few statement triggers that make the necessary PROCESS_RULES
calls for the rule class.
When the duration and consumption policies are set for the primitive events derived from relational data, it is the references to the table rows that are consumed or deleted from the rule class. The original rows are not affected by these event management policies.A composite event structure can be formed using a combination of table alias constructs and embedded abstract data types (ADTs) (for various primitive events). The rule conditions defined for a composite event structure consisting of one or more table alias constructs may not use the (short form of) the SEQUENCE
property to enforce sequencing among primitive events (see Chapter4). This is because the implicit attribute rlm$crttime
may not exist for the rows stored in the relational tables. The user can enforce partial sequencing using the join property in the rule conditions.
The XMLType
data type supplied by Oracle can be used to create attributes in the event structures and rule classes that can process rules defined on XML documents. For this purpose, a primitive event structure can be created with one or more XMLType
attributes (along with some non-XML attributes), such as the following:
CREATE or REPLACE TYPE AddFlight AS OBJECT (
CustId NUMBER,
Airline VARCHAR(20),
FromCity VARCHAR(30),
ToCity VARCHAR(30),
Depart DATE,
Return DATE,
Details sys.XMLType)
If a primitive event is just an XML document, then the preceding object type can be created with just one attribute, that is of XMLType
. The predicates on the XMLType
attributes are specified using the EXTRACT
and EXISTSNODE
operators supplied by Oracle, as shown in the following example.
<condition> <!-- optional for conditions on primitive events --> Airline='Abcair' and ToCity='Orlando' and EXTRACT(doc, '/preferences/seat[@class="economy"]') is not null </condition>
A composite event structure for XML events can be formed by including two or more primitive event types that contain an XMLType
attribute. So, the composite event structure is created as an object type with embedded primitive event types (as described in Chapter2). Once the event structures are created with XMLType
attributes, all the other concepts described in Chapter2 apply to the XML data that is part of the events.
Note:
The Oracle Spatial or the Locator components must be installed in order to use spatial predicates in stored expressions.The SDO_GEOMETRY
data type supplied by Oracle can be used to create event structures and rule classes that can process rules defined on spatial geometries. For this purpose, a primitive event structure can be created with one or more attributes of the MDSYS.SDO_GEOMETRY
type, as follows:
CREATE or REPLACE TYPE AddHotel AS OBJECT ( CustId NUMBER, Type VARCHAR(20), CheckIn DATE, CheckOut DATE, Location MDSYS.SDO_GEOMETRY)
In order to specify predicates on the spatial attributes and index them for efficiency, the geometry metadata describing the dimension, lower and upper bounds, and tolerance in each dimension should be associated with each spatial geometry attribute. This metadata information can be inserted into the USER_SDO_GEOM_METADATA
view using the event structure name in the place of the table name. For more information on the USER_SDO_GEOM_METADATA
view and its semantics, see Oracle Spatial User's Guide and Reference.
INSERT INTO user_sdo_geom_metadata VALUES ('ADDHOTEL','LOCATION', mdsys.sdo_dim_array( mdsys.sdo_dim_element('X', -180, 180, 0.5), mdsys.sdo_dim_element('Y', -90, 90, 0.5)), 8307);
When the event structure with spatial attributes is used to create a rule class, the rule conditions stored in the rule class table can include predicates in these attributes using SDO_WITHIN_DISTANCE
or SDO_RELATE
operators, as shown in the following examples:
<condition> Type = 'Luxury' and CheckOut-CheckIn > 3 and SDO_WITHIN_DISTANCE (Location, SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-77.03644, 37.89868, NULL), NULL, NULL), 'distance=0.5 units=mile') = 'TRUE' </condition>
<condition> Type = 'Luxury' and CheckOut-CheckIn > 3 and SDO_RELATE (Location, SDO_GEOMETRY(2001, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARRAY(-77.03644, 37.89868, -75, 39), 'mask=anyinteract') = 'TRUE' </condition>
A composite event structure involving spatial attributes can be formed by including two or more primitive event structures that contain SDO_GEOMETRY
attributes. In the case of rules specified for composite events, the spatial predicates involving SDO_WITHIN_DISTANCE
or SDO_RELATE
operators are not allowed in the join clause of the rule condition. If needed, functions defined in the MDSYS.SDO_GEOM
package may be used to achieve this functionality. See Oracle Spatial User's Guide and Reference for additional information.
The predicates in a rule condition may use user-defined functions, references to database table data, and database state information. In the case of a condition specified for a simple or a primitive event, the corresponding predicates are evaluated using the state information at the time the event is added to the rule class (using either the PROCESS_RULES
or the ADD_EVENT
call. This is the case even for conditions specified for individual primitive events within a composite event. So, when multiple primitive events are used to capture a composite event, the predicates associated with individual primitive events will be evaluated at different times, corresponding to the occurrences of their respective event. Only the predicates specified in the join attribute of the composite condition are evaluated at the time of composite event creation. So, this aspect should be considered when using database state or schema object references in the rule conditions.