ヘッダーをスキップ
Oracle Databaseルール・マネージャおよび式フィルタ開発者ガイド
11gリリース1（11.1）
E05697-01
  目次
目次		 索引
索引
戻る
戻る		 次へ
次へ		  

3 イベント管理ポリシー

作成時に指定されるルール・クラス・プロパティには、ルール・マネージャが各ルール・アプリケーションに対して実施するイベント管理ポリシーが含まれています。コンポジット・イベント構造に対して定義されるルールの場合、プリミティブ・イベントは一度に1つずつシステムに追加されます。これらのイベントは、その後、他のプリミティブ・イベントと結合され、1つ以上のルール条件を満たすコンポジット・イベントを形成します。各プリミティブ・イベント間の結合条件に基づいて、プリミティブ・イベントに他のイベントとの1対1、1対N （1対多）またはN 対M （多対多）の関連を指定して、1つ以上のコンポジット・イベントを形成できます。プリミティブ・イベントを再利用したり、重複するコンポジット・イベントを処理するためのアプリケーション固有の要件は、ルール・イベント管理ポリシーを使用してサポートされます。これらのプロパティは、次のように大まかに分類されます。

イベント管理ポリシーのduration（継続時間）およびequal（等価）は、コンポジット・イベントに対して構成されたルール・クラスにのみ適用できます。他のすべてのポリシーは、コンポジット・イベントに対して構成されたルール・クラスおよび単純イベントに対して構成されたルール・クラスに適用できます。イベント管理ポリシーに加えて、ルール・クラス・プロパティによりイベントのコレクション用の仕様が許可されます。個別イベントとは対照的に、コレクションの仕様では、プリミティブ・イベントをコレクション・イベントに関係するルール条件で使用できます。このようなイベントに対して、ルール条件では、有限でありながら多数となる可能性のある同じタイプのプリミティブ・イベントの集計値を計算し、集計結果で述語を指定します。特定のタイプのプリミティブ・イベントは一定のイベント属性および集計演算子に基づいてグループ化され、他の属性上にあるSUM、AVG、MIN、MAX、COUNTなどは述語の適用に使用されます。

すべてのルール・クラス・プロパティは、XMLプロパティ文書で指定され、ルール・クラス作成プロシージャ（dbms_rlmgr.create_rule_class）の引数の1つ（rlcls_prop）として使用されされます。コレクションを使用可能にするルール・クラス・プロパティについては、第4.8項で説明します。その他のすべてのルール・クラス・プロパティについては、次の項で説明します。

3.1 イベントの使用率

コンポジット・イベントの形成に使用されるプリミティブ・イベントは、他のプリミティブ・イベントと結合して別のコンポジット・イベントを形成できます。たとえば、AddFlightイベントの2つのインスタンスをAddRentalCarイベントの1つのインスタンスと結合して、（2つの異なるルールと一致する）異なる2つのコンポジット・イベントを形成できます。一部のルール・アプリケーションでは、プリミティブ・イベントがそれ自体のルールまたは他のプリミティブ・イベントと結合したルールと一致する必要があるため、それ以外のルール実行には使用しないでください。コンポジット・イベントの形成に使用されるプリミティブ・イベントは、システムで使用または削除されます。ルール・クラスのconsumption（使用率）プロパティは、システム内でのプリミティブ・イベントの再利用に関係するポリシーを決定します。使用率ポリシーは、単純イベントに対して定義されたルールとコンポジット・イベントに対して定義されたルールの両方に適用できます。次の2種類のモードのイベント使用率が考えられます。

以前に使用した同じ例に従って、2つのAddFlightイベントがシステムにすでに追加されている場合、次のAddRentalCarイベントは、2つ以上のルールと一致する可能性のある2つのコンポジット・イベントを形成できます。ルール・クラスがイベントを排他（EXCLUSIVE）使用するように構成されている場合は、コンポジット・イベントの1つを使用して、1つのルール・アクションのみを実行できます。適切な競合解消方法が採用されている場合は、このルールを確定的に選択できます（第3.2項を参照）。

単純イベント構造に対して作成されたルール・クラスのEXCLUSIVE使用率ポリシーは、dbms_rlmgr.process_rulesプロシージャに渡されるイベント・インスタンスに対して、1つのルールが実行されることを意味します。イベントが複数のルールと一致する場合、実行対象として選択されるルールは、ルール・クラスの順序付けプロパティを使用して判断されます（順序付けの詳細は第3.2項を参照）。プリミティブ・イベント構造に対して作成されたルール・クラスは、次のXMLプロパティ文書を使用して（dbms_rlmgr.create_rule_classプロシージャへのrlcls_prop引数として）、EXCLUSIVEイベント使用率ポリシー付きで構成できます。

<simple consumption="exclusive"/>

ルール・クラス・プロパティ内の使用率仕様に有効なその他の形式は、次のとおりです。

<composite consumption="exclusive"/>

<composite consumption="shared"/>

ルール・アプリケーションでは、コンポジット・イベントで使用されるプリミティブ・イベントのサブセット用プリミティブ・イベントの再利用に、異なるポリシーを保持できます。このようなアプリケーションでは、次のように各プリミティブ・イベント・タイプについて<composite>要素の子要素として使用率ポリシーを指定できます。

<composite consumption="shared">
   <object type="AddFlight" consumption="shared">
   <object type="AddRentalCar" consumption="exclusive">
</composite>

<composite>要素のconsumption属性の値は、コンポジット・イベントのすべてのプリミティブ・イベントのデフォルト値として使用されます。プリミティブ・イベント・タイプのデフォルト値は、<composite>要素の子要素としてプリミティブ・イベントを指定し、この要素に使用率属性を指定することで上書きされます。

イベント使用率のカスタム・ロジックの指定

EXCLUSIVEおよびSHAREDの使用率ポリシーに加え、RULE使用率ポリシーを使用してコンポジット・イベントのルール・クラスを構成できます。これにより、ルール・クラスで個別のルールを指定し、イベント使用率のカスタム・ロジックを使用できます。RULE使用率ポリシーは、コンポジット・イベント・レベルでのみ指定できます。指定した場合は、プリミティブ・イベント・タイプの使用率ポリシーをEXCLUSIVEに設定することはできません。RULE使用率ポリシーに対してルール・クラスが構成されている場合は、アクション・コールバック・プロシージャおよびルール・クラス結果ビューが作成され、ルールと一致する各プリミティブ・イベントの識別子が戻ります。これらの識別子を基本単位として使用し、プリミティブ・イベントの一部またはすべてを選択的に使用できます。詳細は、「DBMS_RLMGR.CONSUME_PRIM_EVENTSプロシージャ」を参照してください。

3.2 ルール実行順序の指定

あるイベントが、それ自体のルールまたは他のプリミティブ・イベントと結合したルールと一致した場合、デフォルトでは、ルール（アクション）実行順序は確定的ではありません。一部のルール・アプリケーションには、特定の順序で実行するための一致ルールが必要です。実行順序は競合解消基準によって決定されます。また、EXCLUSIVE（排他）イベント使用率の場合は、1つの一致ルールのみが実行されます。なんらかの競合解消基準が指定されていない場合は、このルールが無作為に選択されます。一般的な競合解消方法の1つは、イベント属性値とルール・アクション・プリファレンスに基づいて、結果として生じるコンポジット・イベントと一致ルールに順序を設定することです。

一連のコンポジット・イベントが一連のルールと一致する場合は、コンポジット・イベントの競合解消基準を一致ルールの競合解消基準と結合することで、ルールを実行する正確な順序を指定できます。競合解消基準を指定する構文は、ORDERINGプロパティを使用して記述されます。

ルール・クラスのORDERINGプロパティは、一連のコンポジット・イベントまたは単純イベントと一致する一連のルールの実行順序を決定します。コンポジット・イベント・タイプまたはいくつかのプリミティブ・イベント・タイプの使用率ポリシーがEXCLUSIVEに設定されている場合は、順序付けプロパティにより、実行されるルールのサブセットも決まります。（ルールの実行に必要なEXCLUSIVE（排他）イベントは、最初のルールの実行後に削除されるため、残りの一致ルールは無視されます。）順序付けプロパティは、単純イベントに対して定義されたルールとコンポジット・イベントに対して定義されたルールの両方に適用できます。

コンポジット・イベント構造に対して作成されたルール・クラスの場合は、プリミティブ・イベントをシステムに追加することで、複数のルールと一致する可能性のある複数のコンポジット・イベントを形成できます。したがって、結果的に生じるイベントと一致ルールの順序は、イベントの属性、ルールに関連付けられているアクション・プリファレンス、およびルール識別子を使用して指定できます。トラベル・サービスのルール・クラスの例では、イベントと一致ルールの順序を次のように指定できます。

<composite ordering="Flt.rlm$CrtTime, Car.rlm$CrtTime, rlm$rule.PromoType, rlm$rule.OfferedBy, rlm$rule.rlm$ruleid"/>

この昇順の列で、属性がランク付けされる順序付け仕様rlm$ruleは、ルール・クラスに関連付けられている属性（アクション・プリファレンスPromoTypeとOfferedByおよびルール識別子rlm$ruleid）を参照するために使用され、コンポジット・イベント構造のプリミティブ・イベントに対して宣言される変数（AddFlightにはFlt、AddRentalCarにはCar）は、プリミティブ・イベントの属性値にアクセスするために使用されます。

順序付けプロパティは、使用率や継続時間などの他のポリシーと結合できます。ルール・クラス・プロパティ内の順序付け仕様に有効なその他の形式は、次のとおりです。

<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/>

単純イベント構造に対して作成されたルール・クラスの場合、発生するイベントはいずれかの時点に1回のみであるため、順序付けは一致ルールにのみ基づきます。したがって、順序指定句に使用できるのは、ルールに関連付けられているルール識別子とアクション・プリファレンスのみです。

3.3 イベントの継続時間

アプリケーションでは、ルールの起動をトリガーしないイベントを生成することが一般的であり、したがって、これらのイベントが使用されることはありません。プリミティブ・イベントの継続時間ポリシーは、イベントの最大存続期間を決定します。ルールの増分評価のためにプリミティブ・イベントがルール・マネージャに追加されると、イベントおよび評価結果がデータベースに格納されます。これらのイベントは、その後、一致する他のプリミティブ・イベントと結合され、最終的に1つ以上のルール条件を満たすコンポジット・イベントを形成します。ただし、コンポジット・イベントを形成する一致イベントがない場合もあります。たとえば、第2.6項のトラベル・サービスのルールでは、あるルールでAddFlightイベントが検出される可能性はありますが、対応するAddRentalCarイベントは発生しない（または、AddRentalCarイベントは高級車に対しては発生しない）可能性があります。したがって、プリミティブ・イベントの継続時間（または存続期間）は、一定時間経過した後に完了していない（コンポジット）イベントおよび増分ルール評価の結果が削除されるように設定する必要があります。

プリミティブ・イベントの継続時間は、ルール・アプリケーションに基づいており、次の4種類のいずれかに分類できます。

継続時間ポリシーは、システム内のプリミティブ・イベントの存続期間に影響します。単純イベントに対して作成されたルール・クラスの場合、イベントはシステムには格納されません（各イベントに対してルールが最終的に評価されるため）。したがって、継続時間ポリシーは、コンポジット・イベント構造に対して作成されたルール・クラスにのみ適用できます。各（データベース）トランザクション終了時にすべてのプリミティブ・イベントをリセットするように構成されたルール・クラスでは、次のXMLプロパティ文書を使用します。

<composite duration="transaction"/>

継続時間を経過時間として指定する場合は、継続時間属性の値を次のように{[int] minutes | hours | days}形式で指定できます。

<composite duration="20 minutes"/>
<composite duration="2 hours"/>
<composite duration="10 days"/>

これらの仕様は、コンポジット・イベントを構成するプリミティブ・イベントのすべてに適用されます。一部のプリミティブ・イベント・タイプに別の継続時間仕様が必要な場合は、次のように<composite>要素の子要素として指定できます。

<composite duration="10 days">
   <object type="AddFlight" duration="3 days"/>
   <object type="AddRentalCar" duration="call"/>
</composite>

この場合は、<composite>要素のduration属性の10 days（10日間）という値が、コンポジット・イベントのすべてのプリミティブ・イベントのデフォルト値として使用されます。プリミティブ・イベント・タイプのこのデフォルト値は、たとえば、AddRentalCarイベント・タイプに指定される継続時間プロパティcallが示しているように、<composite>要素の子要素としてプリミティブ・イベントを指定し、この要素にduration属性を指定することで上書きされます。したがって、これらのAddRentalCarイベントは、PROCESS_RULESまたはADD_EVENTコール時にルールに一致しなかった場合は破棄されることになります。

継続時間ポリシーでは、TRANSACTIONまたはSESSIONの値を継続時間ポリシーに指定できるのは、コンポジット・イベント・レベルのみという制限があります。指定した場合、それらの値をプリミティブ・イベント・レベルで上書きすることはできません。

3.4 等価性

コンポジット・イベントに対するルール・クラスの場合、すべてのルール条件において最も共通性の高い等価性結合述語を識別し、EQUALルール・クラス・プロパティを使用してこれらを指定することは、パフォーマンスのために重要です。単一のルール・クラス内のすべてのルールでは、1つ以上の共通の（等価性）結合述語を使用して、コンポジット・イベントを形成するプリミティブ・イベントを関連付けます。これらの結合述語は、対応するプリミティブ・イベント・タイプの属性を使用して定義されます。たとえば、トラベル・サービスのアプリケーションで、コンポジット・イベントにあるAddFlightイベントとAddRentalCarイベントは、これらのプリミティブ・イベントの顧客識別子を介して関連付けられます（Flt.CustId = Car.CustId）。EQUALプロパティを使用して、ルール条件で使用される限られた数の等価性結合述語を最適化するようにルール・クラスを構成できます。


注意:

パフォーマンスを向上させるために、ルール・クラス・レベルでEQUALプロパティを使用することをお薦めします。

単一のルール・クラスに使用されるEQUALプロパティには、そのルール内の同質の結合条件に依存する2つのタイプがあります。すべてのルール条件に対して同一の等価性結合述語を使用する同質のルール・セットがあるルール・クラスの場合、ルール・クラスのequal指定は一意に識別され、equal指定は1つのみです。一方、別のルールのサブセットにより異なる結合述語が使用される場合、そのルール・クラスは限られた数の代替equal指定で構成されます。各equal指定は、関連するプリミティブ・イベントからの単一の属性に基づいているか、またはこの項で説明する補助の各プリミティブ・イベント（連結キー）からの複数の属性に基づきます。

3.4.1 ルール・クラスに対する単一equal指定

ルール・クラスに対する単一equal指定により、ルール・クラス内のすべてのルールで使用される等価性結合述語が識別されます。たとえば、トラベル・サービスのアプリケーション内のすべてのルールによって顧客識別子（Flt.CustId = Car.CustId）に基づいたプリミティブ・イベントが関連付けられる場合、この結合述語はルール・クラスのEQUALプロパティの単一equal指定として構成されます。

この場合、EQUALプロパティがカンマ区切りの属性のリストとして指定され、各プリミティブ・イベント構造から1つの結合述語がルール・クラスに対して構成され、ルール・クラスのルールすべての結合述語として使用されます。このリストは、コンポジット・イベントの形成に等価であることが必要なプリミティブ・イベント属性を識別します。次に例を示します。

<composite equal="Flt.CustId, Car.CustId"/>

コンポジット・イベントに3つ以上のプリミティブ・イベントがある場合、対応するルール条件により、多くの等価性結合述語のうち2つの論理積が選択されます。たとえば、reading1、reading2およびreading3がRFID readingを表す3つのプリミティブ・イベントである場合、これら3つのイベントに関連するルール内の結合条件はreading1.ReaderId = reading2.ReaderIdおよびreading2.ReaderId = reading3.readingIdです（3つすべてのreadingが同一のリーダーに起こることを確認します）。対応するequal指定は、各プリミティブ・イベント（reading1.readerId、reading2.readerId、reading3.readerId）の属性をカンマ区切りのリストで表します。

単一のequal指定の場合、各ルール条件で同一の等価性結合述語を使用することが保証されているので、ルール・クラス・プロパティのequal指定では、同一の結合述語を各ルール条件内に準備する必要はありません。したがって、ルール・クラス内のルールでは、次の例で示すように同一の属性セットに関係する等価性結合述語を省略できます。

次のルール条件により、おそらく非等価性である別の結合述語を使用して論理積に等価性結合述語が明示的に指定されます。この指定では、結合述語に対してSQL WHERE句構文が使用されます。

<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>

次のルール条件では、前述の例で使用した等価性結合述語のかわりにEQUAL句を使用する方法を示します。ルール条件のEQUAL句の指定は、特に、ルール条件に否定の構成メンバーがある場合（第5.3項を参照）、またはANY nの構成メンバーがある場合（第5.5項を参照）、等価性結合述語の短い表現として機能します。

<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>

ルール・クラスのEQUALプロパティがequal="Flt.CustId, Car.CustId"として指定される場合、前述の2つの例で示したように、対応する結合述語またはEQUAL句をルール条件で使用する必要はありません。この場合、ルール・クラスに関連付けられた単一equal指定はルール・クラス内のすべてのルールに対して実行されます。したがって、ルール・クラスが前述のEQUALプロパティで作成された場合、次のルール条件は前述の2つの例と同等になります。

<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>

連結キーを使用するequal指定

プリミティブ・イベント間の等価性結合述語が、各プリミティブ・イベントからの1つ以上の属性に関連する場合が頻繁にあります。たとえば、トラベル・サービスのアプリケーションでは、AddFlightイベントおよびAddRentalCarイベントは、顧客識別子の等価性に加えて、旅程（各イベントからのDepart日およびCheckOut日の等価性述語）に基づいて相互に関連する場合があります。このような結合述語を使用するサンプル・ルールは次のとおりです。

    <and join="Flt.CustId = Car.CustId and Flt.Depart = Car.CheckOut">
        <object name="Flt"> Airline = 'Abcair' and ToCity = 'Orlando' </object>
        <object name="Car"> CarType = 'Luxury' </object>
    </and>

各プリミティブ・イベントからの複数の属性に関連する等価性述語がルール・クラス内のすべてのルールに共通している場合、ルール・クラスは最適なパフォーマンスのための連結キーを含むEQUALプロパティ仕様で構成されます。

<composite equal="(Flt.CustId, Car.CustId), (Flt.Depart, Car.CheckOut)"/>

注意:

3つの連結キーの最大値はルール・クラスのEQUALプロパティで指定できます。

前述の仕様では、[Flt.CustId,Flt.Depart]属性の組合せが各Fltイベントに対する連結キーとして機能しており、Carイベントからの連結キーと一致させ、ルール・クラス内のすべてのルールをTRUEにする必要があります。前述のequal指定はルール・クラスのすべてのルールに対して実行されるため、各ルールの類似するequal指定は省略される場合があります。

3.4.2 代替のequal指定

ルール・クラスのEQUALプロパティ仕様のもう1つの形式は、そのルール内で最も共通性の高い等価性結合述語のリストを識別します。そのために、単一の各equal指定はカッコを使用してグループ化され、代替のequal指定は縦線（|）を使用して区別されます。たとえば、同じRFIDReadタイプの2つのプリミティブ・イベントを使用して作成されたルール・クラスの場合、ルール・クラス内の一方のルールのサブセットでは、そのItemId属性に対してプリミティブ・イベントを結合できます（reading1.ItemId = reading2.ItemId）。同じルール・クラス内のルールのもう一方のサブセットでは、そのReaderId属性に対してプリミティブ・イベントを関連付けることができます（reading1.ReaderId = reading2.ReaderId）。次のEQUALプロパティを使用して、これら両方のタイプのルールを効果的に処理するようにルール・クラスを最適化できます。

<composite equal="(reading1.ItemId, reading2.ItemId) |
                  (reading1.ReaderId, reading2.ReaderId)"/>

注意:

単一のルール・クラスのEQUALプロパティに最大で5個の代替のequal指定を定義できます。

代替のequal指定は、ルール・クラス内で最も共通性の高い結合述語についてルール評価を最適化する方法を提供しますが、そのルールの等価性結合述語がルール・クラスにより自動的に実行されることはありません。最適なパフォーマンスを維持するために、ルール・クラスの各ルール条件では、各EQUAL句に対して1つの代替のequal指定を指定する必要があります。たとえば、次のルールのEQUAL句は、ルール・クラス・レベルで代替のequal指定の1つと一致します。したがって、このルールは最適化されています。

<condition>
  <and equal="reading1.ItemId, reading2.ItemId"/>
    <object name="reading1"/>
    <object name="reading2"/>
  </and>
</condition>

したがって、ルール・クラス内の個別のルールに対するEQUAL句は、等価性結合述語の短い表現として単純に機能するのみでなく、代替のEQUALプロパティ仕様の1つにマップする際にも役立ちます。

代替のequal指定には、連結キーに関連する1つ以上の仕様が含まれます。たとえば、トラベル・サービスのアプリケーションで、顧客識別子に基づいてAddFlightイベントおよびAddRentalCarイベントのみを関連付けるいくつかのルールを使用していて、また旅程内の日付と同様に識別子に基づいたその他のルールも使用する場合、ルール・クラスは次の最適なパフォーマンスのための等価プロパティで構成されます。

    <composite equal="(Flt.CustId, Car.CustId)  |
                       (Flt.CustId, Car.CustId), (Flt.Depart, Car.CheckOut)"/>

ルール・クラス・レベルでのこの仕様では、ルール・クラス内の個別のルールはこれら2つの代替のEQUALプロパティ仕様の両方を使用します。

<condition>
  <and equal="(Flt.CustId, Car.CustId), (Flt.Depart, Car.CheckOut)">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object> CarType = 'Luxury' </object>
  </and>
</condition>

単一のルールに指定されたEQUAL句と代替のequal指定の1つが一致しても、属性の順序には関連がないことに注意してください。

3.5 記憶域プロパティ

<simple>または<composite>要素のSTORAGE属性は、ルール・クラス表およびルール・クラスに対して作成された内部オブジェクトの記憶域プロパティを指定するために使用されます。デフォルトでは、ルール・クラス内のルール管理に使用されるデータベース・オブジェクトは、記憶域プロパティのユーザー・デフォルトを使用して作成されます（例: 表領域仕様）。この属性の値には、一般的なSQL CREATE TABLE文に指定できる有効な記憶域プロパティを割り当てることができます。次のXMLプロパティ文書を（dbms_rlmgr.create_rule_classプロシージャへの引数として）使用して、表領域TBS_1にある単純イベントに対するルール・クラスを作成し、EXCLUSIVE（排他）使用率ポリシーを使用できます。

<simple storage="tablespace TBS_1" consumption="exclusive"/>

次の例は、ルール・クラス・プロパティに記憶域属性を指定しています。

<composite storage="tablespace TBS_1"/>

3.6 自動コミット（AUTOCOMMIT）

ほとんどの場合、ルール・マネージャのすべてのプロシージャは、ルールの追加、ルールの削除およびルールの処理の各操作の直後にコミットします。ルール・クラスをトランザクション境界に従うように構成するには、自動コミット機能をオフに切り替えます。そのために、AUTOCOMMITプロパティをルール・クラス・プロパティ文書に指定できます。次に例を示します。

<simple autocommit="NO"/>

AUTOCOMMITプロパティは、コンポジット・イベントのみでなく、単純イベントに対して作成されたルール・クラスにも指定できます。AUTOCOMMITプロパティに有効なその他の形式は、次のとおりです。

<composite autocommit="NO" consumption="shared"/>
<composite autocommit="YES"/>

AUTOCOMMITプロパティがNOに設定されている場合は、ROLLBACK文を発行することで、トランザクションで実行された一連のルール・マネージャ操作（ルールの追加、ルールの削除、ルールの処理）をロールバックできます。このルールの例外は、アクション・コールバック・プロシージャ（エンド・ユーザーによる実施）で、元に戻せない操作（メールの送信、データ定義言語（DDL）操作の実行、コミット、ロールバックなど）を実行する場合です。アクション・コールバック操作のDDL操作は、そのトランザクションで実行されたすべての操作を自動的にコミットします。この状況を回避するには、DDL操作を自律型トランザクションで実行する必要があります。

ルール・クラスのAUTOCOMMITプロパティをオフに切り替えることで、ルール・クラスに対する同時操作を制限できます。特に、ルール・クラスがコンポジット・イベントに対して作成され、そのイベントがEXCLUSIVE（排他）使用率ポリシーに対して構成された場合に指定します。（トランザクションでは、使用されたイベントはトランザクションがコミットされるまでロックされ、他のセッションはこれらのイベントのリリースを待機できます。）

AUTOCOMMITプロパティのデフォルト値は、他のイベント管理ポリシーに依存しています（表3-1を参照）。このポリシーのデフォルト値は、単純（非コンポジット）ルールに対して構成されたルール・クラス、およびSESSIONまたはTRANSACTIONの継続時間ポリシーを使用して構成されたコンポジット・ルール・クラスではNOです。（これらの構成では、複数のセッションにわたってイベントを共有することに起因する問題は発生しません。）その他すべての構成では、AUTOCOMMITプロパティにはYESのデフォルト値が使用されます。継続時間ポリシーがTRANSACTIONに設定されている場合は、AUTOCOMMITプロパティをYESに設定できないことに注意してください。また、EXCLUSIVEまたはRULEの使用率ポリシーに対して1つ以上のプリミティブ・イベント・タイプが構成されている場合は、AUTOCOMMITプロパティをNOに設定できません。

1つ以上の表の別名の構成メンバーを使用してイベント構造が定義され、対応するルール・クラスがDMLイベント（第3.7項を参照）に対して構成されている場合は、AUTOCOMMITプロパティを必ずNOに設定します。このように設定すると、EXCLUSIVEまたはRULEの使用率ポリシーを併用しているときに、デッドロックが発生する可能性があることに注意してください。

AUTOCOMMITプロパティがNOに設定されているルール・クラスには、否定と期限に関係するルールは指定できません（第5.3項を参照）。

3.7 DMLおよびCNFイベント

イベント構造が1つ以上の表別名属性を使用して作成されている場合（第4.1項を参照）は、対応する表に対するSQL INSERTおよびSQL*Loader操作がルールの評価対象のイベントとみなされるように、対応するルール・クラスを構成できます。このルール・クラスの動作は、ルール・クラスのDMLEVENTSまたはCNFEVENTSプロパティを使用して有効化できます。

<simple dmlevents="I"/>
<simple cnfevents="I"/>

この両方のプロパティは、単純イベントおよびコンポジット・イベントに対して構成されたルール・クラスに指定できます。基礎となる表にあるUPDATE操作およびDELETE操作に対するイベントはコンポジット・イベントに対して構成されたルール・クラスに対してのみ適用できます。

<composite dmlevents="IUD"/>
<composite cnfevents="IUD"/>

表内の行が削除される場合、この行に一致するルールの状態情報には削除のマーク付けがされます。同様に、行が更新されると、既存の状態情報には削除のマーク付けがされ、更新された行に対して新規の状態情報が計算されます。削除された行（または更新された行の古いイメージ）は、過去のルールの状態に影響を与えません。つまり削除操作によって、イベントの取消のために既存のルールの状態が自動的にTRUEになることはありません。この例は、削除前にイベントがルールの否定部分に一致した否定の構成メンバーを含むルール条件に関連します。

DMLEVENTS仕様では、DML操作から生成されたイベントは、同じDMLコマンドの一部としてルール・クラスのルールの処理に使用されます。ここでは、基礎となる表の行レベル・トリガーを使用します。または、CNFEVENTS仕様が使用される場合、ルールはイベントとしてネット・データの変更を使用したDMLトランザクションのコミットの後に処理されます。実際、行が表に挿入されて同じトランザクション内に更新される場合、CNFEVENTS仕様では、ルールは新しく挿入された行（コミットされたデータ付き）のために1回処理されます。一方、DMLEVENTS仕様が使用された場合は、ルールは同じ行のために2回処理され、1回目はINSERT操作で処理され、2回目はUPDATE操作で処理されます。CNFEVENTSの使用の詳細は、第4.9項を参照してください。

DMLEVENTSポリシーが指定されている場合は、ルール・クラスのAUTOCOMMITポリシーをNOにしてください。この場合、NOのAUTOCOMMITポリシーは、使用率ポリシーがEXCLUSIVEまたはRULEに設定されている場合も許可されます（DMLEVENTSポリシーが使用されていない場合は、無効な組合せとみなされます）。EXCLUSIVEまたはRULEの使用率ポリシーをDMLEVENTSポリシーと併用すると、アプリケーションのデッドロックが発生することがあります。

3.8 ルール・クラス・プロパティの依存関係とデフォルト

この項で説明するほとんどのルール・クラス・プロパティ（またはイベント管理ポリシー）は、ルール・クラスを定義する際にうまく組み合せることができます。ただし、これらのプロパティの組合せの一部は、表3-1に示すように無効とみなされます。たとえば、ルール・クラスのAUTOCOMMITプロパティをYESに設定した場合、DURATIONポリシーに対するTRANSACTIONの設定は無効となります。これは、イベントが追加されるとすぐにシステムから削除され、コンポジット・イベントを形成する他のイベントと組み合せることができないためです。DMLEVENTSポリシーは、イベント管理ポリシーの有効および無効な組合せには直接影響しません。このポリシーは、AUTOCOMMITポリシーのデフォルト値のみに影響します。

表3-1 ルール・クラス・プロパティの有効および無効な組合せ


 AUTOCOMMIT CONSUMPTION DURATION

無効

Yes

--

Transaction

有効

Yes

--

Session

有効

Yes

--

[n] Units

有効

No

Shared

--

有効

No

Exclusive

Transaction脚注1 

有効

No

Exclusive

Session脚注1 

無効

No

Exclusive

[n] Units脚注2  

有効

No

Rule脚注3  

Transaction脚注1 

有効

No

Rule

Session脚注1 

無効

No

Rule

[n] Units脚注 2

脚注1 SESSIONまたはTRANSACTIONモードで動作しているルール・クラスでは、イベントおよび増分結果のプライベート・コピーを取得するため、データベース・セッション間での並行性の問題はありません。

脚注2 EXCLUSIVE使用率ポリシーが指定されたルール・クラスは、一部の行をロックして「使用済」とマークしますが、それらの行は実際には使用できません。このような行は、他のデータベース・セッションによる使用が回避されるため、その結果デッドロックとなります。したがって、ロックされた行はAUTOCOMMIT="YES"プロパティでリリースすることをお薦めします。

脚注3 RULEは、特定のイベントの使用がエンド・ユーザーによって開始されるEXCLUSIVE使用率ポリシーの特殊な形式です。

単純イベントに対して構成されたルール・クラスの様々なイベント管理ポリシーのデフォルト値は、次のとおりです。

CONSUMPTION   :  Shared
DURATION      :  Infinite Duration (NULL)
AUTOCOMMIT    :  No

コンポジット・イベントに対して構成されたルール・クラスのイベント管理ポリシーのデフォルト値は、次のようにイベント管理ポリシーに依存することがあります。

CONSUMPTION   :  Shared
DURATION      :  Infinite Duration (NULL)
AUTOCOMMIT
   IF DMLEVENTS = IUD                                 : NO
   ELSE IF DURATION = TRANSACTION / SESSION           : NO
   ELSE                                               : YES
  戻る
戻る		 次へ
次へ
  目次
目次		 索引
索引