ルール・マネージャのルール条件はSQL WHERE句形式に基づいており、イベント構成の属性で定義されます。たとえば、トラベル・サービスの場合のルール条件は、次に示すように、Airline
、ToCity
、Return
およびDepart
の各属性を使用して表されます。ルール条件は、SQL WHERE句形式に直接対応するプリミティブ・イベント構造で定義されます。
<condition> Airline = 'Abcair' and ToCity = 'Orlando' and Return - Depart >=7 </condition>
すべてのルール条件は、XMLの<condition>タグ内に埋め込まれることに注意してください。追加のXMLタグは、複数のプリミティブ・イベントで構成されるコンポジット・イベントに対してルール条件の増分評価をサポートするために定義されます。
プリミティブ・イベントに基づく条件の評価は基本であり、イベント構造のすべての属性に対する値は基本的に使用可能であることを意味します。その結果、プリミティブ・イベントで定義されたルール条件は即時にTRUEまたはFALSEに評価されます。これに対して、使用可能なプリミティブ・イベントのサブセットに応じて、コンポジット・イベントで定義されたルール条件は中間状態になる場合があります。たとえば、3つのプリミティブ・イベント条件のうちの2つがTRUEに評価される場合、3つのプリミティブ・イベントから構成されたコンポジット・イベントで定義されたルールを起動するように定義できます。
コンポジット・イベントでルール条件をサポートするために、追加のXMLタグは<condition>タグ内で使用されます。これらのタグを使用することで、コンポジット・イベント間の結合をサポートする基本的なWHERE句の機能、およびコンポジット・イベント構造を構成するプリミティブ・イベント・インスタンスの増分評価が拡張されます。
たとえば、トラベル・サービスでの条件式(Flt.Airline = 'Abcair' and Flt.ToCity = 'Orlando' and Flt.CustId = Car.CustId and Car.CarType = 'Luxury'
)には次の3つの述語が含まれます。
プリミティブ・イベントAddFlightで定義した述語(Flt.Airline = 'Abcair' and Flt.ToCity = 'Orlando'
)
プリミティブ・イベントAddRentalCarで定義した述語(Car.CarType = 'Luxury'
)
2つのプリミティブ・イベント間の結合述語(Flt.CustId = Car.CustId
)
ルール・マネージャには、複雑な条件式の各部を識別し、追加のセマンティクスをサポートするためのXMLタグが用意されています。たとえば、前述のルール条件をXMLタグを使用して表すと、次のようになります。脚注1
<condition> <and join="Flt.CustId = Car.CustId
"> <object name="Flt">Airline='Abcair' and ToCity='Orlando'
</object> <object name="Car">CarType = 'Luxury'
</object> </and> </condition>
この表現では、個々のプリミティブ・イベントに対して指定した述語がオブジェクト要素で取得され、2つのプリミティブ・イベント間の結合述語の動作が<and>
要素の1つのjoin属性で取得されます。この形式のルール条件は、対応するルール・クラス表のrlm$rulecond
列に挿入できます。XMLタグは、複雑なルール構成メンバーをサポートするために用意されています。XMLタグについては、図5-1と表5-1に要約を示し、第5.2項〜第5.5項で説明します。
前述の例は、andおよびjoinの組合せを示しています。この組合せは、すべてのプリミティブ・イベント条件が対応するイベントでTRUEに評価された場合に、ルール結合条件も満たすように、TRUEに評価します。anyなどその他の構成メンバーは、プリミティブ・イベント条件のサブセットがTRUEに評価される場合、複雑な条件をTRUEに評価するように指定できます。
コンポジット・イベントの形成に使用された最も共通性の高い結合述語は、複数の表を結合するSQL問合せを使用する等価性述語です。一般的に、各プリミティブ・イベントの1つ以上の属性は、等価性のある他のイベントの1つ以上の属性と比較されます。ルール・マネージャは、適切な構文を使用してルール条件の等価性結合述語を指定し、ルール・クラスのすべてのルールに対してこの結合述語を実行するメカニズムも提供します(第3.5項を参照)。
次の例に、コンポジット・イベントで定義された一般的に使用されるルール構成メンバーを示します。
countはプリミティブ・イベントのサブセットに基づいており、any演算子を使用して指定できます。
演算子anyは、anyのプリミティブ・イベント条件がTRUEに評価された場合、TRUEに評価します。
演算子any 2は、any 2以上のプリミティブ・イベント条件がTRUEに評価された場合、TRUEに評価します。
一般的に、any演算子はプリミティブ・イベント条件のany countがTRUEに評価される場合、TRUEに評価するcount引数を使用してパラメータ化されます。
順序付けされたプリミティブ・イベントのサブセットは次の方法で指定できます。
時間制約を含むJoinの使用。時間制約はイベント・インスタンスに部分的な順序を課すのに使用できます。
sequenceタグを含むandの組合せ。
sequenceタグにはプリミティブ・イベントの特定の順序が必要です。
sequenceタグを含むany countの組合せ。
あるプリミティブ・イベントが別のプリミティブ・イベントの特定の期間内に発生しなかった場合の検出は、notまたはnotanyタグのbyオプションを使用して指定されます。
タイムスタンプ・パラメータを含むnot byタグは、特定の期間内にプリミティブ・イベントの無発生を検出するために使用できます。
notany byタグも同様に使用できます。
図5-1に、ルール条件のXMLスキーマ定義でサポートされているXMLタグ要素とその属性の階層ビューを示します。このルール条件の詳細は、付録Fの「ルール条件」の項で説明します。表5-1には、サポートされている同じXMLタグ拡張のリレーショナル・ビューを示し、XPathおよび要素と属性に関する説明も示します。
表5-1 XMLタグ拡張のリレーショナル・ビュー
XMLタグ | タイプ | 親 | XPath | 親の下位で使用できる回数 | 説明 |
---|---|---|---|---|---|
condition |
要素 |
なし |
condition |
--- |
条件式を示します。 |
and |
要素 |
condition |
condition/and |
1回 |
複数の述語を結合します。 |
any |
要素 |
condition |
condition/any |
1回 |
「or」のかわりに使用します。いずれかの条件が満たされるとTRUEになります。 |
not |
要素 |
and |
and/not |
1回(最後の子要素として) |
論理的な否定。 |
notany |
要素 |
and |
and/notany |
1回(最後の子要素として) |
論理的な否定。無発生を検出します。 |
object |
要素 |
condition and any not notany |
condition/object and/object any/object not/object notany/object |
1回 2つ以上のオブジェクト 2つ以上のオブジェクト 1つのオブジェクト 2つ以上のオブジェクト |
プリミティブ・イベント。 |
collection |
要素 |
condition and |
condition/collection and/collection |
1回 2つ以上のオブジェクトとの結合 |
コレクション・イベント。 |
join |
属性 |
and any not notany |
and/@join any/@join not/@join notany/@join |
1回 1回 1回 1回 |
複数の述語を結合します。 |
sequence |
属性 |
and any |
and/@sequence any/@sequence |
1回 1回 |
順序付けを指定します。 任意の順序付けを指定します。 |
equal |
属性 |
and any |
and/@equal any/@equal |
1回 1回 |
複数の述語を結合します。 |
count |
属性 |
any notany |
any/@count notany/@count |
1回 1回 |
Any n セマンティクス。 Any n セマンティクス。 |
by |
属性 |
not notany |
not/@by notany/@by |
1回 1回 |
無発生の期限。 無発生の期限。 |
name |
属性 |
object |
object/@name |
1回 |
オブジェクト名。 |
collection |
collection/@name |
コレクション名。 |
|||
ref |
属性 |
object |
object/@ref |
1回 |
共有条件への参照。 |
groupby |
属性 |
collection |
collection/@groupby |
1回 |
コレクションの指定によるグループ。 |
having |
属性 属性 |
collection and |
collection/@having and/@having |
1回 1回 |
コレクションのhaving句。 複数のコレクションに結合するhaving句。 |
compute |
属性 |
collection |
collection/@compute |
1回 |
コレクションを計算する追加の集計機能。 |
windowlen |
属性 |
collection |
collection/@windowlen |
1回 |
コレクションのウィンドウ・スペックの移動。 |
windowsize |
属性 |
collection |
collection/@windowsize |
1回 |
コレクションのウィンドウ・スペックの移動。 |
(複数のプリミティブ・イベントで構成される)コンポジット・イベントに対して定義するルールでは、プリミティブ・イベントの発生順序に条件を指定できます。この指定は、順序付けと呼ばれ、プリミティブ・イベントのサブセットに対して部分的に実行するか、すべてのプリミティブ・イベントに対して完全に実行できます。ルール・アプリケーションにおける順序付けは、暗黙的なタイムスタンプ属性(rlm$crtTime
)を使用してサポートされ、この属性は、コンポジット・イベントにある各プリミティブ・イベントに含まれています。
プリミティブ・イベントでのイベント作成時間を使用して、ルール・アプリケーションでの順序付けを実行および検出します。たとえば、トラベル・サービスのアプリケーションで考慮されるルールでは、追加の述語を指定して、AddFlight
イベントの後にAddRentalCar
イベントが生成された場合のみ販促を提供できます。次に示すように、ルール条件はこの順序付け述語を含めるように拡張できます。
<condition>
<and join="Flt.CustId = Car.CustId" sequence="yes"
>
<object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
<object name="Car"> CarType = 'Luxury' </object>
</and>
</condition>
この例では、sequence属性によって、一致するプリミティブ・イベントが<and>
要素内で指定された順序で発生した場合のみ、ルール条件がTRUEと評価されます。このsequence属性は、次に示すように、対応するイベント作成時間の結合述語に置き換えることができます。
<condition>
<and join="Flt.CustId = Car.CustId and Car.rlm$CrtTime >= Flt.rlm$CrtTime
">
<object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
<object name="Car""> CarType = 'Luxury' </object>
</and>
</condition>
順序付けを使用すると、プリミティブ・イベント間の部分的な順序を検出できます(たとえば、コンポジット・イベントに3つのプリミティブ・イベントがあり、その中の2つで結合述語を使用する場合)。また、プリミティブ・イベント・タイプのrlm$CrtTime
属性は、追加の時間制約をルール条件に適用するためにも使用できます。たとえば、トラベル・サービスの場合、航空券を予約してから24時間以内にレンタカーを予約した場合のみ、ルールを有効にできます。これは、次の例で太字のテキストで示され、値1は1日を意味します。日付/タイムスタンプに関する計算の詳細は、『Oracle Databaseアドバンスト・アプリケーション開発者ガイド』を参照してください。
<condition>
<and join="Flt.CustId = Car.CustId and
Flt.rlm$CrtTime >= (Car.rlm$CrtTime - 1)
"
sequence="Yes">
<object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
<object name="Car"> CarType = 'Luxury' </object>
</and>
</condition>
オプションで、DBMS_RLMGR.PROCESS_RULES
プロシージャへのコールで、イベントを特定のイベント作成時間とともに渡すことができます。プリミティブ・イベント内では、rlm$CrtTime
属性はイベント構造のその他の属性として処理されます。ただし、この属性に値が指定されていない場合は、デフォルト値の(データベースの)SYSTIMESTAMP
が割り当てられます。イベントを(アプリケーション層で)検出した時間と、そのイベントをルール・マネージャに追加した時間との差異をアプリケーションで認識した場合、イベント作成時間の値を設定して、完全に指定したイベントをルール・クラスに追加できます。
条件に否定を使用するルールは、通常、ビジネス・プロセスにおける例外を生成するために使用します。たとえば、「Goldクラスの顧客から受けた注文品が24時間以内に出荷されていない場合は、担当者へのアラートを生成する」は否定を使用するルールの一例です。この例の場合、2つのプリミティブ・イベントPlaceOrder
とShipOrder
で構成したコンポジット・イベントに対してルールが定義されます。このコンポジット・イベント構造に対して作成されるタイプは次のようになります。
CREATE or REPLACE TYPE OrderTrack AS OBJECT ( order PlaceOrder, -- primitive event type -- ship ShipOrder); -- primitive event type --
コンポジット・イベントの場合、否定を使用して定義したルールでは、いずれかのプリミティブ・イベントが他のプリミティブ・イベントの遅延時間内に発生しなかった場合にTRUEと評価されます。したがって、否定を使用するルールでは、他のプリミティブ・イベントやコンポジット・イベント内のイベントに関連する遅延時間が常に伴います。たとえば、受注追跡ルールのルール条件は、次の例のように取得できます。この例にある太字のテキスト「sysdate +1」は、翌日の終わりまでを意味します。これは、SQLの日時関数SYSDATE
では、データベースが常駐するオペレーティング・システムの現在の日時が戻されるためです(データベースの起動時に有効になったデータベース・サーバーのオペレーティング・システムのタイムゾーンが考慮されます)。
<condition>
<and equal="order.orderId, ship.orderId">
<object name="order"> Type = 'Gold' </object>
<not by="sysdate+1">
<object name="ship"/> -- empty elem: no conditions on the primitive event --
</not>
</and>
</condition>
ルール条件の<not>
XML要素のセマンティクスは、次のとおりです。
1つのルール条件に含めることができるのは、1つの<not>
要素のみです。
<not>
要素は<and>
要素内でのみ使用でき(他のプリミティブ・イベントに対する結合として)、<and>
要素内で最後の要素である必要があります。
<not>
要素がアクティブ化するのは、コンポジット・イベント内の他のすべてのプリミティブ・イベントが検出された場合のみです。
<not>
要素には、プリミティブ・イベントを表す1つの<object>要素のみ含めることができます。<notany>
要素は<not>
要素のかわりに使用でき、否定ルール内での選言の概念をサポートします。
アクティブ化の時点で、<not>
要素のby
属性が実行され、<not>
要素内のプリミティブ・イベントの期限が計算されます。by
属性の値は、(データベースの)SYSTIMESTAMP
(アクティブ化の時間が設定されます)、または他のプリミティブ・イベントの任意の日付属性(第5.2項で説明したイベント作成時間属性を含みます)、あるいはその両方を使用して表すことができます。SQL日付関数SYSTIMESTAMP
は、データベースが常駐するシステムの小数秒とタイムゾーンを含めたシステム日付を戻します。したがって、前述の例のルール条件は、次のようにも表現できます。
<condition>
<and equal="order.orderId, ship.orderId">
<object name="order"> Type = 'Gold' </object>
<not by="order.rlm$CrtTime+1
">
<object name="ship"/>
</not>
</and>
</condition>
前述のルールは、ユーザー指定の日付を使用して期限を計算するように表すこともできます。たとえば、PlaceOrder
イベントのShipBy
属性で出荷予定時間を保持し、次に示すように、この属性を使用して期限を計算できます。
<condition>
<and equal="order.orderId, ship.orderId">
<object name="order"> Type = 'Gold' </object>
<not by="order.ShipBy-1
">
<object name="ship"/>
</not>
</and>
</condition>
AUTOCOMMIT
プロパティがオフになっているルール・クラスでは、否定を使用するルールにSYSTIMESTAMP
以外の期限を含めることはできません(第3.6項を参照)。これは、DMLEVENTS
に対して構成されたルール・クラスでも同様です(第3.7項を参照)。
否定の構成メンバーを含むルールを使用すると、一連のプリミティブ・イベントが順序どおりに生成されない場合に(対応するルール・アクションで)アラートを生成できます。ワークフローなどのアプリケーションでは、多くの場合、様々なビジネス・イベント間での順序付けを強制するためにルールが使用されます。このようなルールのアクションでは、イベントが順序どおりに生成されていないことが検出されると例外(エージェントへのアラート)が生成されます。このようなルールは、具体的な期限を指定しない(by
属性がない)<not>
要素を使用して定義できます。
ここで、3つのプリミティブ・イベントPlaceOrder
、PaymentReceived
およびShipOrder
を含むコンポジット・イベントについて考えてみます。ルールを使用すると、ShipOrderイベントがPaymentReceived
イベントの前に生成されたことが検出された場合に、エージェントへのアラート(アクション)を生成できます。(ワークフロー・システムでこのアプリケーションをモデル化する方法は他にいくつかありますが、ここで説明する方法は否定の概念を説明するために使用しています。)この例の場合、コンポジット・イベント構造とルール条件は、次のように表すことができます。
CREATE or REPLACE TYPE OrderTrack AS OBJECT ( order PlaceOrder, -- primitive event type –- pay PaymentReceived, -- primitive event type -- ship ShipOrder); -- primitive event type -- <condition> <and equal="order.OrderId, pay.OrderId, ship.OrderId"> <object name="order"/> -- no conditions on the primitive events -- <object name="ship"/><not>
<object name="pay"/></not>
</and> </condition>
前述の例では、期限(by
属性)を指定せずに<not>
を使用しています。したがって、この値のデフォルトはSYSTIMESTAMP
(ルール条件にある他のすべてのプリミティブ・イベントが検出された時間)になります。次の例に示すように、sequence="yes"プロパティ(第5.2項を参照)を使用すると、検出されたイベント間の順序付けを確認できます。
<condition> <and equal="order.OrderId, pay.OrderId, ship.OrderId"sequence="yes"
> <object name="order"/> -- no conditions on the primitive events -- <object name="ship"/><not>
<object name="pay"/></not>
</and> </condition>
前述のルール条件では、PaymentReceived
イベントの期限は、対応するPlaceOrder
イベントの後に続くShipOrder
イベントの発生によって決定します。実際、このルール条件に関連するアクションは、指定された順序に対して、ShipOrder
イベントがPaymentReceived
イベントの前に検出された場合に実行されます。
否定の構成メンバーは、多くの場合、複数のプリミティブ・イベントの無発生を検出するために使用できます。たとえば、「Goldクラスの顧客から受けた注文品が24時間以内に出荷されていない場合または受注が取り消されていない場合は、担当者へのアラートを生成する」というルールでは、2つのイベントShipOrder
およびCancelOrder
で否定を使用します。このようなルール条件は、次の例に示すように、<not>
要素のかわりに<notany>
要素を使用して表すことができます。
<condition> <and equal="order.orderId, ship.orderId, cancel.orderId"> <object name="order"> Type = 'Gold' </object><notany count=1
by="order.rlm$CrtTime+1"> <object name="ship"/> <object name="cancel"/> -- assuming a CancelOrder event --</notany>
</and> </condition>
<not>
または<notany>
要素内に記述されるプリミティブ・イベントは、<and>
要素のjoin
属性の指定では参照できません。ただし、このようなプリミティブ・イベントはEQUAL
プロパティの指定で使用できます。結合条件を指定する必要がある(EQUAL
プロパティの指定ですでに取得されているプリミティブ・イベント以外に)場合は、<not>
要素のjoin
属性を使用できます。次の例に示すように、このjoin
属性に指定した条件式では、<not>
要素内のプリミティブ・イベントも含めて、ルール条件に含まれるすべてのプリミティブ・イベントを参照できます。
<condition>
<and equal="order.orderId, ship.orderId">
<object name="order"> Type = 'Gold' </object>
<not by="order.rlm$CrtTime+1"
join="order.Address_zipcode = ship.Address_zipcode"
>
<object name="ship"/>
</not>
</and>
</condition>
否定を使用するルール条件がTRUEとみなされるのは、<and>
要素内の結合条件がTRUEと評価され、not条件内の結合条件がFALSEと評価された場合(つまり、指定した期限内にこの条件と一致するイベントがない場合)のみです。
一部のアプリケーションでは、コンポジット・イベントを構成する複数のプリミティブ・イベントが同じ構造の場合があります。たとえば、AddItem
は、顧客が品目をショッピング・カートに追加すると生成されるプリミティブ・イベントであるとします。この場合のルールは、ショッピング・カートに追加された複数の品目を監視し、顧客の過去の購買実績に基づいて新たに品目を提案する(データ・マイニング・ツールで生成される関連付けルール)ように定義できます。
たとえば、ビデオカメラの付属品を販売するWebストアの場合を考えてみます。「100ドル以上のビデオカメラ・レンズ、レンズ・フィルタおよび赤外線ライトをショッピング・カートに入れた顧客には、三脚を提案する」は、このようなアプリケーションの典型的なルールです。次の例に示すように、このルールは3つの単純な条件で構成され、これらの条件は、システムでAddItem
イベントが生成されるたびチェックされます。
Accessory = 'Lens' and Price > 100 Accessory = 'Lens Filter' Accessory = 'IR Light'
前述のアプリケーションをサポートするために、次の例に示すように、同じプリミティブ・イベント・タイプ(AddItem
)の埋込みタイプを複数備えたオブジェクト型として、コンポジット・イベント構造をモデル化できます。必要に応じて、同じコンポジット・イベント構造に他のプリミティブ・イベント・タイプを含めることもできます。
CREATE or REPLACE TYPE AddItem AS OBJECT ( Accessory VARCHAR(30), Make VARCHAR(20), Price NUMBER); CREATE or REPLACE TYPE CrossSellEvent AS OBJECT ( Item1 AddItem, Item2 AddItem, Item3 AddItem, Item4 AddItem, Item5 AddItem);
前述のコンポジット・イベントは、ショッピング・カート内のプリミティブ・イベントを5つまで監視するルールに対応するように作成されています。(ショッピング・カートには、5品目以上を入れることができることに注意してください)。このルール・アプリケーションでは、SESSION
継続時間にイベントを構成できます(第3.3項を参照)。この場合、ルールと照合する対象とみなされるのは、ユーザー・セッション内に生成されたプリミティブ・イベントのみです。コンポジット・イベントのルール条件構文を使用すると、前述の条件は次のように表すことができます。
<condition> <and> <object name="Item1"> Accessory = 'Lens' and Price > 100 </object> <object name="Item2"> Accessory = 'Lens Filter' </object> <object name="Item3"> Accessory = 'IR Light' </object> </and> </condition>
要素名Item1
、Item2
およびItem3
が、一致するイベントをCrossSellEvent
インスタンスの該当する属性に割り当てるために使用されていることに注意してください。次に示すように、この割当てによって、(結合)述語をルール条件のプリミティブ・イベント間で使用することもできます。
<condition>
<and join="Item1.Price+Item2.Price+Item3.Price > 300"
>
<object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
<object name="Item2"> Accessory = 'Lens Filter' </object>
<object name="Item3"> Accessory = 'IR Light' </object>
</and>
</condition>
コンポジット・イベントで使用できるプリミティブ・イベントの最大数により、セット・セマンティクスを使用したルール条件内でのプリミティブ・イベントの合計数は制限されます。また、次の標準SQLセマンティクスでは、集計演算子は複数のイベントと関連付ける結合条件で使用できません。有限でありながら多数となる可能性のあるプリミティブ・イベントでの集計演算子に関連するルールベースのアプリケーションに対しては、コレクション・イベントに対してルール・クラスを構成する必要があり、ルール条件はこれらのコレクションでの述語を指定する必要があります。
これまでの説明の例では、ルール条件で指定したすべてのプリミティブ・イベントを一致させるルールを使用してきました。このようなルールでは、すべてのプリミティブ・イベント条件の親として<and>
要素を使用します。しかし、一部のルール・アプリケーションでは、ルール条件で指定したプリミティブ・イベントのサブセットを一致させるルールが必要です。たとえば、3つのプリミティブ・イベントPE1
、PE2
およびPE3
で構成されるコンポジット・イベント CE1
を考えてみます。ここでは、このコンポジット・イベントに対して定義したルール条件では、3つのプリミティブ・イベントのいずれか1つのみが一致する必要があります。この例の場合、コンポジット・イベント構造とルール条件は、次のように表すことができます。
-- Composite event structure -- CREATE or REPLACE TYPE CE1 AS OBJECT ( pe1Inst PE1, pe2Inst PE2, pe3Inst PE3); -- Sample Rule condition -- <condition><any>
<object name="pe1Inst"/> <object name="pe2Inst"/> <object name="pe3Inst"/></any>
</condition>
ルール条件で、3つのプリミティブ・イベントのいずれか2つが一致する必要がある場合は、次の例に示すように、<any>
要素のcount
属性を使用できます。count
属性のデフォルト値は1で、これは<any>
要素内で指定したすべてのプリミティブ・イベントの選言(OR)と同等です。
<condition><any count=2>
<object name="pe1Inst"/> <object name="pe2Inst"/> <object name="pe3Inst"/></any>
</condition>
ルール条件のAny n セマンティクスは、セット・セマンティクスを使用するアプリケーションでよく使用されます。第5.4項で説明した抱合せ販売のルールは、指定した3品目の内、2品目をショッピング・カートに入れた顧客に三脚を提案するように拡張できます。このルールの条件は、次のように、Any n 構文を使用して表すことができます。
<condition>
<any count=2>
<object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
<object name="Item2"> Accessory = 'Lens Filter' </object>
<object name="Item3"> Accessory = 'IR Light' </object>
</any>
</condition>
このルール条件で条件がTRUEと評価されるには、<any>
リストで指定したプリミティブ・イベントの内、いくつかが一致する必要があります。たとえば、前述のルール条件では、レンズ(Item1)を必須品目とし、<any count=2>
指定で一致させる2品目の内の1品目として必ずカウントします。このようなルール条件は、次のように、<any>
要素のjoin属性を使用して表すことができます。
<condition>
<any count=2 join="Item1 IS NOT NULL"
>
<object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
<object name="Item2"> Accessory = 'Lens Filter' </object>
<object name="Item3"> Accessory = 'IR Light' </object>
</any>
</condition>
<any>
リスト内では、発生する複数のプリミティブ・イベントを関係付ける必要が生じる場合があります。たとえば、前述のルールは、一致した2つの品目のMake
属性が同じ場合のみ顧客に三脚を提案するように拡張できます。<and>
要素(3品目すべてを一致させる)を使用している場合、この拡張は、次の例に示すように、各プリミティブ・イベントのMake
属性に対するjoin
述語として記述できます。
<condition>
<and join="Item1.Make=Item2.Make and Item2.Make=Item3.Make"
>
<object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
<object name="Item2"> Accessory = 'Lens Filter' </object>
<object name="Item3"> Accessory = 'IR Light' </object>
</any>
</condition>
ただし、同様の結合述語を使用して<any>
リスト内のプリミティブ・イベントを関係付けることはできません。これは、除外されるプリミティブ・イベント(3品目の内、2品目が一致した後の残り1品目)はNULLで表され、すべての述語(IS NULL以外)はNULL値に対して常にFALSEになるためです。このため、<any count=2>
指定を使用する場合、ルールでは次の結合条件を使用する必要があります。
(Item1.Make is null and Item2.Make = Item3.Make) or (Item2.Make is null and Item1.Make = Item3.Make) or (Item3.Make is null and Item1.Make = Item2.Make)
この結合条件は、<any>
要素内ではequal句を使用して略称で表すことができます。この構文を使用すると、次の例に示すように、結合条件では、<any>
要素のcount属性に割り当てた値が効率的に使用されます。
<condition>
<any count=2 equal="Item1.Make, Item2.Make, Item3.Make"
>
<object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
<object name="Item2"> Accessory = 'Lens Filter' </object>
<object name="Item3"> Accessory = 'IR Light' </object>
</any>
</condition>
コンポジット・イベントのプリミティブ・イベント間における等価結合はよく使用されるため、略称を使用するこの構文は、次の例に示すように、<and>
要素でもサポートされています。
<condition>
<and equal="Item1.Make, Item2.Make, Item3.Make"
>
<object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
<object name="Item2"> Accessory = 'Lens Filter' </object>
<object name="Item3"> Accessory = 'IR Light' </object>
</condition>
<and>
要素または<any>
要素でequal
属性とjoin
属性の両方を使用する場合、equal指定で表される結合述語は、join
属性にリストされた結合述語と結合(論理ANDを使用して)されます。たとえば、次の条件では、同じMake属性の2つの指定品目と、合計値が300を超える品目を一致させます(結合述語でNVL関数が使用されています)。
<condition> <any count=2equal="Item1.Make, Item2.Make, Item3.Make"
join="NVL(Item1.Price,0) + NVL(Item2.Price,0) + NVL(Item3.Price,0) > 300"
> <object name="Item1"> Accessory = 'Lens' and Price > 100 </object> <object name="Item2"> Accessory = 'Lens Filter' </object> <object name="Item3"> Accessory = 'IR Light' </object> </any> </condition>
ルール・クラス・レベル(ルールごとではなく)でのequal属性の使用の詳細は、第3.4項で説明しています。sequence
属性(第5.2項)を<any>
要素で使用すると、一致するプリミティブ・イベントが指定の順序で発生するため、ルール条件がTRUEと評価されます。
<condition>
<any count=2 sequence="yes"
>
<object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
<object name="Item2"> Accessory = 'Lens Filter' </object>
<object name="Item3"> Accessory = 'IR Light' </object>
</any>
</condition>
コレクションは、一部の共通のプロパティに基づいて一連のプリミティブ・イベントをグループ化して形成されるイベント・インスタンスです。プリミティブ・イベントが共有する共通プロパティには特定の属性の等価性が含まれ(たとえば、コレクションのすべてのイベントが同一である識別子の場合)、プリミティブ・イベントのコンテンツの一部の述語を含めます(たとえば、コレクションのすべてのプリミティブ・イベントが述語transType = 'Withdrawal'
を満たす場合)。
3種類のプリミティブ・イベント、BankTransaction、TransportationおよびFieldReportに対して設定されたルール・クラスについて考えてみます。このうちBankTransactionはコレクションが有効です(第4.8項を参照)。ルール・クラスには、銀行取引イベント、特に銀行取引コレクション・イベントで集計述語を検査するルール条件が含まれます。たとえば、次のルール条件では、ルール条件の構文内のコレクション要素を使用して、一部の集計述語を検査します。
<condition> <collection name="bank" groupby="subjectId" having="SUM(amount) > 10000"> tranType = "Withdrawal" and amount > 1000 </collection> </condition>
前述のルール条件では、コレクション要素のテキスト値(tranType = "Withdrawal" and amount > 1000
)として指定された基準と一致するすべてのプリミティブ・イベントはコレクションとみなされます。collection
要素のgroupby
属性に対して指定された値は、それぞれの一意のサブジェクト識別子(subjectId
)の1つである、複数のコレクション・イベントを作成するために使用されます。コレクション・イベントにはプリミティブ・イベントを形成するプリミティブ・イベントの概要が含まれており、個別のイベントのIDは解放されます。これらの概要を使用して、collection
要素のhaving句(having
属性に割り当てられた値)で指定された述語の評価に必要な集計値を計算します。新規のプリミティブ・イベントが発生した場合、必要な集計値は段階的に計算され、having
句の述語が評価されます。having
句で指定された条件がTRUEに評価される場合、ルール条件はTRUEとみなされ、ルールと関連付けられているアクションが実行されます。デフォルトでは、アクションはコレクションの最後のイベント(時間順)と同時に実行されます(またはアクション・コールバック・プロシージャが起動されます)。having句の条件がTRUEのままであるグループの新規の各イベントに対しては、ルール・アクションは1度実行されます。または、EXCLUSIVEまたはRULE使用率ポリシーを使用してアクションが実行された後に、コレクションをリセットできます(第4.8項を参照)。
ルール条件のhaving
句に対して指定された条件式は、結合および選言により結合された1つ以上の述語を含むSQL-HAVING句形式です。having句の述語は、対応するイベント構造の属性の1つでそれぞれ稼働するCOUNT
、SUM
、AVG
、MIN
およびMAX
という5つの集計演算子の1つを使用して形成されます。having句指定のサンプル形式の一部は、次のとおりです。
SUM(amount) > 10000 and AVG(amount) >= 1000 SUM(amount) > 10000 and (AVG(amount) >= 1000 or COUNT(*) < 10) MAX(amount) > 5000 or MIN(amount) > 1000
前述のルール条件構文を使用すると、(コレクション・イベントの使用によって)コレクションがリセットされるまでコレクションに含まれるプリミティブ・イベントの数は単調に増加します。オプションで、2つの移動するウィンドウ・セマンティクスの内の1つを使用して、コレクションに含まれるプリミティブ・イベントの数を制限できます。
固定ウィンドウ・サイズ
固定ウィンドウ長
コレクション・イベントの固定ウィンドウ・サイズを指定すると、新規イベントの追加によって最も古いイベントが削除され、コレクションのプリミティブ・イベントの上限数が増加します。たとえば、次に示すように、前述のルール条件を強化して、各コレクションの最新の100イベント(最後のイベントの発生から時間順)のみの概要を保持できます。
<condition> <collection name="bank" groupby="subjectId" having="SUM(amount) > 10000" windowsize="100"> tranType = "Withdrawal" and amount > 1000 </collection> </condition>
または、ルール条件は、固定時間枠を使用してコレクション内のプリミティブ・イベントを制限できます。固定時間枠の使用によりコレクションに最後に追加されたプリミティブ・イベントで終了できます。たとえば、前述のルール条件は、次に示すように、24時間以内に発生したイベントのみを対称にするよう上書きできます。ウィンドウ長の指定は1日の一部として表示されます。
<condition> <collection name="bank" groupby="subjectId" having="SUM(amount) > 10000" windowlen="1"> tranType = "Withdrawal" and amount > 1000 </collection> </condition>
コレクション構成を含むルール条件がTRUEに評価される場合、一連のプリミティブ・イベントを表すコレクション・イベント・インスタンスへの参照はアクション実行のために戻されます(アクション・コールバック・プロシージャまたは結果ビューで)。コレクション・イベントは、構成されるプリミティブ・イベントと同じ型(前述の例ではBankTransaction)です。ただし、コレクション・イベントでは、グループ化されたプリミティブ・イベントの属性(コレクションのGROUP BY句のネイティブ属性)のみ初期化され、残りはNULLに設定されます。たとえば、前述のルール条件に対して作成されたコレクション・イベントはsubjectId
属性を初期化したBankTransactionイベントです。コレクションの各プリミティブ・イベントに対して潜在的に異なる属性の残りは、NULLに設定されます。
アクション・ロジックを使用可能にする各コレクション・イベントに対しては、コレクションを計算した集計値は、コレクション・イベント識別子およびDBMS_RLMGR.GET_AGGREGATE_VALUEコールを使用して取得できます(第4.8項を参照)。アクション・ロジックが、適用する述語に対する計算よりも集計値による場合、collection
要素のcompute
属性を使用して集計値を指定できます。たとえば、次のルール条件で各コレクション内の金額の合計に加えて最小金額値が計算され、アクション実行時にアプリケーションにフェッチできます。ルール条件の各コレクション・イベントは5つの集計値の合計を保持できます。
<condition>
<collection name="bank" groupby="subjectId"
having="SUM(amount) > 10000"
compute="MIN(amount)"
windowlen="1">
tranType = "Withdrawal" and amount > 1000
</collection>
</condition>
コンポジット・イベントに対するルール条件構文は、他のコレクション・イベント、またはプリミティブ・イベントとコレクション・イベントとの関連付けに使用できます。たとえば、一連の銀行取引を表すコレクション・イベントは、輸送イベントと関連付けて、「対象者が1日に10,000ドル以上を引き出し、警戒区域に向かうためにトラックを片道分借りた場合、ニューヨーク市警の警戒リストにその人物を追加します。」などのルールを形成できます。
ON
BankTransaction(subjectId, amount, tranType, ..) bank,
Transport(subjectId, vesselType, locFrom, locTo, ..) transport
IF
<condition>
<and equal="transport.subjectId, bank.subjectId">
<collection name="bank" groupby="subjectId"
having="SUM(amount) > 10000"
windowlen="1"
>
tranType = "Withdrawal"
</collection>
<object name="transport">
vesselType = 'TRUCK' and locTo != locFrom and IsRestrictedArea(locTo) = 1
</object>
</and>
</condition>
THEN
PerformAction('ADD2WATCHLIST','NYPD',subjectId)
属性がコレクション・イベントと他のコレクションまたはコレクションではない個別のイベント、あるいは両方と関連付ける一方で、groupby
句にリストされる属性をイベント間で結合述語(join
およびequal
句)を形成するのに使用できます。たとえば、前述のルールを使用して形成されるコレクション・イベントには、コレクションにGROUP BY句が含まれるため、コレクションのすべてのプリミティブ・イベントで共通するサブジェクト識別子に対して初期化されたsubjectId
属性があり、この属性を使用して他のイベントとコレクション・イベント(銀行)を結合できます。
前述のルールと関連付けられたアクションは、銀行取引コレクション・イベントおよび輸送イベント、あるいは対応する基準を満たす両方のイベントがsubjectId
属性で一致する場合、実行されます。アクションがプリミティブ・イベントの発生順に依存する場合、このルールに対するアクションは次のイベントと同時に実行されます。
他の基準を満たす輸送イベントがすでにある場合のhaving
句を満たすコレクションの最後の銀行取引イベント
または、独自の基準を満たし、HAVING
句を満たす銀行取引コレクション・イベントとして同様のサブジェクト識別子を要する輸送イベント
collection
要素のhaving
属性は単一のコレクションと関係する述語のみを含むことができます。having句の条件式が複数のコレクションまたは1つのコレクションと他のイベントを関連付ける必要がある場合、and
要素のhaving
属性を使用する必要があります。たとえば、箱単位で品目を管理する次のルール条件で、品目プリミティブ・イベントがcrateid
属性に基づいてグループ化され、計算された集計値は箱のcapacity
属性と比較されます(両方ともRFID読込みイベントとみなされます)。
<condition>
<and equal="crate.id, item.crateid"
having="COUNT(item.*) > crate.capacity*0.8"
>
<object name="crate"/>
<collection name="item" groupby="crateid"/>
</and>
</condition>
and
要素で指定されたhaving
句はいくつかのコレクション、または拡張名(item.*
およびcrate.capacity
など)を使用してand
要素内で定義されたオブジェクトを参照できます。そのような条件で、having
句はコレクションと他のプリミティブ・イベント間で結合条件として機能します。結合条件として機能する集計述語は、特定のコレクションで集計述語と結合できます。ただし、collection
要素のhaving
属性を使用して指定された集計述語のみ、より迅速な評価に合せて最適化されます。たとえば、次に示すように、前述のルール条件を拡張して、箱単位の最小品目数の述語を含むように設定できます。また、このルールを使用して、コレクション・イベントに50以上の個別のイベントが含まれる場合のみ、それ以降の評価を考慮します。
<condition>
<and equal="crate.id, item.crateid"
having="count(item.*) > crate.capacity*0.8">
<object name="crate"/>
<collection name="item" groupby="crateid"
having="COUNT(*) > 50"
/>
</and>
</condition>
and
要素のhaving
句の集計述語を指定する機能は複数のコレクションを関連付けるのにも使用できます。たとえば、一方が引出を、もう一方が預金を表す2つのプリミティブ・イベントのコレクションでは、双方を比較して特定の期間の未払勘定の傾向を確認できます。
ON
Deposits (subjectId, amount, ..) dep,
Withdrawals (subjectId, amount, ..) wdr
IF
<condition>
<and equal ="dep.subjectId, wdr.subjectId"
having = "SUM(wdr.amount) > SUM(dep.amount)"
>
<collection name="wdr" groupby="subjectId" windowlen="30"/>
<collection name="dep" groupby="subjectId" windowlen="30"/>
</and>
</condition>
THEN
Alert (dep.accountId, 'Negative Trend');
現行のリリースでは、ルール条件のコレクション構成は否定(第5.3項を参照)、またはAny構成(第5.5項を参照)では、ルール条件と結合できません。
脚注の凡例
脚注1: このドキュメントで示す例では、簡略化のために、<(<
;)、>(>
;)および'(&apos
;)記号をXML実体参照で表記していません。ルール条件内で、実体参照(<
;)を使用して指定するか、XML CDATAセクション内で使用する必要がある記号は、<記号のみです。他の記号に対する実体参照の使用は必須ではありませんが、互換性の理由から実体参照の使用をお薦めします。XML属性および要素に指定するすべての値は、SQLネーミング規則に従って、大/小文字が区別されません。大/小文字が保持されるのは、値が引用符で囲まれている場合のみです。