この付録では、式フィルタとルール・マネージャの違い、および式フィルタのルール・アプリケーションをルール・マネージャのルール・アプリケーションに変換する方法を説明します。
式フィルタ・アプリケーションをルール・マネージャ・アプリケーションに変換する前に、それぞれの機能の違い、およびルール・マネージャを使用する理由を把握する必要があります。これらをすでに把握し、式フィルタ・アプリケーションをルール・マネージャ・アプリケーションに変換する準備ができている場合は、第D.2項に進んでください。
式フィルタは、単純なルールベース・システムのモデル化に最適です。単純なルールベース・システムは、少数から多数(数百から数百万)のルールを含めることができる1つのプリミティブ・イベントで構成されます。
ルール・マネージャは、最も単純なものから複雑なものまで幅広いルールベース・システムのモデル化に最適です。単純なルールベース・システムは、前述したように、少数から多数(数百から数百万)のルールが含まれる1つのプリミティブ・イベントです。これに対して、非常に複雑なルールベース・システムには、多数のコンポジット・イベントを含めることができます。各コンポジット・イベントは複数のプリミティブ・イベントで構成され、それぞれ多数(数百万)のルールが含まれます。これによって、非常に複雑なルール条件を表すことができ、プリミティブ・イベントの再利用や重複するコンポジット・イベントの処理などを必要とするイベント管理ポリシーを適用できます。
表D-1に、(単純な)プリミティブ・イベントを使用する式フィルタ機能とルール・マネージャ機能について、実装および使用手順の違いを示します。
表D-1 (単純な)プリミティブ・イベントを使用するルール・アプリケーションにおける式フィルタとルール・マネージャの実装手順の違い
式フィルタ | ルール・マネージャ |
---|---|
1. イベント構造とその属性セットを作成するか、既存のオブジェクト型定義を使用します。 |
1. イベント構造とその属性セットを作成するか、既存のオブジェクト型定義を使用します。 |
2. ルール条件および関連する情報を格納する表を作成します。 |
2. イベント構造に対してルール・クラスを作成します。 o アクションを実行するためのコールバック・プロシージャ用のスケルトンが暗黙的に作成されます。 o 対応するルール定義とルール・アクション・プリファレンスを格納するためのルール・クラス表が暗黙的に作成されます。 o ルール・クラス定義で指定されている場合は、ルールの処理結果を一時的に格納するための結果ビューが定義されます。 |
3. 式フィルタの属性セットとして取得されるイベント構造を、表内の条件列に割り当てます。 |
注意: ルール・マネージャでは、生成されたルール・クラス表にExpressionデータ型列( |
4. デフォルトの索引パラメータを属性セットとともに構成します。 |
注意: ルール・マネージャでは、デフォルトの索引パラメータが属性セットとともに暗黙的に作成されます。 |
5. ユーザー表のExpression列に対して式フィルタ索引を作成します。 |
注意: ルール・マネージャでは、ルール・クラス表の必要なExpression列に対して式フィルタ索引が暗黙的に作成されます。 |
6. ユーザー表で定義したルールに対してアクションを実行するプロシージャを実装します。 |
3. 各一致ルールに対して適切なルール・アクションを実行するために、システム生成コールバック・プロシージャをユーザー実装で置き換えます。 |
7. ルール条件式および付随情報をユーザー表に挿入します。 |
4. ルールをルール・クラス表に挿入します。 |
8. ユーザー表のルールがコンポジット・イベントに依存している場合は、過去のイベントを格納するイベント表を作成します。 |
注意: ルール・マネージャでは、過去のイベントが不要になるまで追跡するためのイベント表が暗黙的に作成されます。 |
9. SQL |
5. イベントに対するルールを処理します。注意: ルール・マネージャでは、 |
10. 前の問合せで戻された1つ以上の行に対してアクション・プロシージャを実行します。 |
注意: ルール・マネージャでは、 |
11. ルール・アクションの実行直後にアプリケーションでイベントの使用が要求される場合は、イベント表からイベントを削除します。 |
注意: ルール・マネージャでは、適切なイベント管理ポリシーを使用してイベントを自動的に使用するように構成できます。 |
表D-1に示すように、通常は式フィルタを使用して手動で実行する必要がある多くの操作が、ルール・マネージャでは(式フィルタ機能を組み込むことによって)自動的に実行されます。多くの式フィルタ機能がルール・マネージャで暗黙的に使用されるため、ルール・マネージャは使いやすく、特にコンポジット・イベントを含む複雑なルール・アプリケーションの場合はルール・マネージャの使用をお薦めします。
式フィルタを使用するルールベース・システム・アプリケーションをすでにモデル化して実装しており、そのアプリケーションをルール・マネージャ・アプリケーションに変換する必要がある場合は、第D.2項で変換プロセスの詳細を参照してください。
式フィルタはルール・マネージャのコンポーネントです。ルール・マネージャは、Oracle Database 10g リリース2(10.2)でルール・アプリケーションの開発用に使用する最適な機能です。Oracle Database 10g リリース1(10.1)で開発した式フィルタ・アプリケーションは、ルール・マネージャ・アプリケーションに変換できます。そのためには、式やルールを格納する表に関してこれら2つの機能の主な違いを理解する必要があります。実装に関する主な違いは、式フィルタ・アプリケーションのExpression列を格納するユーザー表、ルール・マネージャ・アプリケーションのルール条件列およびアクション・プリファレンス列を格納するルール・クラス表のそれぞれの名前と構造にあります。
式フィルタ・アプリケーションをルール・マネージャ・アプリケーションに変換するには、最初に表D-1の「ルール・マネージャ」列で説明した手順1〜3を完了します。次に、手順4で説明したSQL INSERT
文を使用してルール・クラス表を移入するのではなく、次のSQL構文を使用して、式フィルタのユーザー表からルール・マネージャのルール・クラス表に行をコピーします。
SQL INSERT INTO <rules-manger-rules-class-table> (field1, field3, field4,
field2)
SELECT field1, field2, field3, field4 from <expression-filter-user-table>;
このSQL INSERT
構文によって、ルール・マネージャのルール・クラス表に、式フィルタのユーザー表にあるExpression列の条件から条件式が移入され、必要なアクション・プリファレンス列も移入されます。たとえば、次のSQL文では、コピーする列とコピー順序をユーザーが決定できるように、SQL DESCRIBE
文を実行してそれぞれの表の構造を表示し、その後でこの移入操作を実行します。
--Assume the Expression Filter user table has the following structure: SQL> DESCRIBE user_exprfiltertable; Name Null? Type ----------------------------------------- -------- --------------------------- ID VARCHAR2(100) CONDITION VARCHAR2(200) POSTALCODE VARCHAR2(10) PHONE VARCHAR2(10) --Assume the Rules Manager rule class table has the following structure: SQL> DESCRIBE rm_rules_classtable; Name NULL? TYPE --------- ----- ------------- RLM$RULEID VARCHAR2(100) PostalCode VARCHAR2(10) Phone VARCHAR2(10) RLM$RULECOND VARCHAR2(4000) RLM$RULEDESC VARCHAR2(1000) RLM$ENABLED CHAR(1) DEFAULT 'Y' --Insert statement to use that copies rows from the Expression Filter user table --to the Rules Manager rule class table: INSERT INTO rm_rules_classtable (rlm$ruleid, PostalCode, Phone, rml$rulecond) SELECT ID, PostalCode, Phone, Condition FROM user_exprfiltertable;
ルール・クラス表に式フィルタのユーザー表の行が移入された後、表D-1の「ルール・マネージャ」列の説明にある手順5〜7を完了します。これらの手順を完了すると、ルール・マネージャのルール・アプリケーションとして使用できます。
ルール・マネージャを既存のアプリケーションに適合させるには、前述のSQL INSERT INTO
構文を使用して、既存のアプリケーションの表内にあるデータをルール・クラス表に移入します。ただし、移入操作ができるのは、ルール・マネージャで最初にそのルール・クラス表が作成された後です。つまり、表D-1の「ルール・マネージャ」列の手順2に従ってルール・クラスを作成する際に定義される列と同じ列に対して、必要な値をルール・クラス表に移入するのが最適な方法です。このように、既存のアプリケーションを適合させてルール・マネージャを使用する手順は簡単で、ルール・マネージャを使用してルール・アプリケーションを開発する方法を理解すると、簡単に結果を得ることができます。開発プロセスの概念の詳細は、第1.2項を参照してください。