| Oracle Databaseルール・マネージャおよび式フィルタ開発者ガイド 11gリリース1（11.1） E05697-01 |
|
 戻る |
 次へ |
アプリケーション開発者は、ルールを使用してビジネス・プロセスを統合し、ワークフローにより作成されたイベントに自動的に応答します。しかし、これらのルールは、多くの場合コード・モジュールや特殊な目的のメモリーベースのルール・リポジトリに埋め込まれているため、メンテナンスが困難です。Oracle Databaseで管理されるルールは、変化するビジネス情勢を反映し、常に最新の状態です。これは、SQLを使用してルールが容易に変更され、アプリケーションにハードコードされたり、メモリーベースのルール・リポジトリにロードされることがないためです。ルールは、Oracle Databaseに格納されている完全なビジネス・コンテキストおよびアプリケーションが提供するデータを使用して効率的に評価されます。イベント応答には柔軟性があり、ルールによってOracle Databaseまたはアプリケーション（あるいはその両方）でアクションをトリガーできます。
ルール・マネージャのApplication Program Interface（API）は、Oracle Databaseで複雑なルールを定義、管理および実行し、特殊な目的のルール製品より優れたスケーラビリティと操作特性を実現します。さらに、データベース機能としてのルール・マネージャは、マルチ・ユーザーとマルチ・セッションの環境で使用できます。
ルール・マネージャは、最も単純な単一イベント/単一ルールのシステムから、数百万のイベントとルールが関係するルールベースのシステムまで、あらゆるイベント・コンディション・アクション（ECA）ベースのシステムをモデル化できます。ルール・マネージャ用のアプリケーションには、情報の配布、タスクの割当て、イベントベースの計算、無線自動識別（RFID）、サプライ・チェーン、エンタープライズ・アプリケーション統合（EAI）、ビジネス資産管理（BAM）およびビジネス・プロセス管理（BPM）などがあります。
ルール・マネージャは、ECAセマンティクスに基づいた一連のルールに対するイベントまたはイベント・グループを処理します。イベントは、個別のエンティティ（単純イベントまたはプリミティブ・イベント）、またはイベント・グループ（コンポジット・イベント）があります。ルール・マネージャは、SQLおよびXMLべースのルール条件言語を使用して複雑なイベントの例をモデル化します。イベントは、受け取ったアプリケーション・データの場合、または1つ以上のリレーショナル表に行として格納されているデータの場合があります。ルール・マネージャは、オラクル社が提供するXMLTypeデータ型をサポートしているため、XMLイベントを処理できます。
イベントが発生し、そのイベントに対してルール条件がTRUEに評価されると、規定のルール・アクションが実行されます。このルール・アクションは即時実行するか、ルール・リストとして取得できます。問合せ可能なこのルール・リストは、アプリケーションまたはその他のコンポーネントが後で実行するイベントに対してTRUEを評価します。
イベントに対する一連のルールの処理時に、ルール・マネージャは、コンポジット・イベント間または一致ルールのグループ間の競合解消、イベントの順序付け、イベントの存続期間、および複数ルール実行時のイベントの共有など、様々なイベント管理ポリシーを実施します。
第1.1項では、ルールの概念を簡単に説明した後、ルール・マネージャの機能の概要を説明します。第1.2項では、ルール・マネージャを使用したルール・アプリケーションの開発に関する一般的な概念を説明します。
使用している既存の式フィルタ・アプリケーションをルール・マネージャ・アプリケーションにアップグレードする場合は、最初に、式フィルタおよびルール・マネージャの実装を記述した第D.1項を参照してください。次に、式フィルタ・アプリケーションからルール・マネージャ・アプリケーションへのアップグレード処理を記述した第D.2項を参照してください。
ルールは、処理動作のガイドとなり、処理動作に影響を与えるディレクティブです。ルールは、対応するイベント構造に定義されている属性を使用して指定された条件式と、イベント構造のインスタンスによってルール条件が満たされた場合に発生するルール・アクションで構成されます。イベント管理ポリシーは、ルール・アクションが実行された際のイベント・インスタンスの処理方法を定義します。つまり、一般的なルールベース・システムの動作方法が記述されます。
ルールは通常、イベント・コンディション・アクション（ECA）ルール・セマンティクスに従います。このセマンティクスでは、イベントが発生し、このイベントに対するルール条件がTRUEに評価されると、規定のいくつかのアクションが実行されます。ECAの各コンポーネントは、次のように定義されます。
Event: プロセスの状態情報
Condition: イベントに対してTRUEまたはFALSEを評価するブール条件
Action: ルール条件がイベントに対してTRUEに評価された場合に実行されるアクション
ECAルールの標準の表記法は、次のとおりです。
ON <event structure> IF <condition> THEN <action>
ON句で、ルールが定義されるイベント構造を識別し、IF句でルール条件を指定し、THEN句でルール・アクションを指定します。
ルールの例では、OrlandoまでのフライトにAbcair Airlinesを利用し、Orlandoでの滞在が7日間を超える顧客には、Acarの販促レンタカーを提供します。ECAの表記法を使用すると、このルールは次のようになります。
ON
AddFlight (Custid, Airline, FromCity, ToCity, Depart, Return)
IF
Airline = 'Abcair' and ToCity = 'Orlando' and Return-Depart >= 7
THEN
OfferPromotion (CustId, 'RenralCar', 'Acar')
各項目の内容は、次のとおりです。
ルール・マネージャ
Oracle Databaseの1機能であるルール・マネージャには、データベースで複雑なルールを定義、管理および実行するためのインタフェースが用意されています。ルール・マネージャ・アプリケーションには、次の5つの要素があります。
イベント構造。イベントの特定の機能を示す属性を持つオブジェクト型として定義されます。
ルール。条件とアクション・プリファレンスで構成されます。
ルール条件は、イベント構造に定義されている属性を使用して表されます。
ルール・アクション・プリファレンスは、各ルールの正確なアクションを決定し、そのアクションの詳細を指定します。
ルール・クラス。イベント構造に対して定義したルールを格納およびグループ化するデータベース表。
アクション・コールバックPL/SQLプロシージャ。ルール・クラスのルール・アクションを実装します。この実装は、イベント構造の一部の属性、およびルールに関連付けられているアクション・プリファレンスに依存する場合があります。
結果ビュー。外部のルール・アクション実行に対するルール・クラスを構成します。
ルール・マネージャは、XMLべースの条件言語、ルール仕様のSQLコマンド、イベントの自動トラッキング、イベント・ポリシーの宣言的管理、ルール・アクションおよびApplication Program Interface（API）をサポートします。
ルール・マネージャは、プリミティブ（単純）イベントおよびコンポジット・イベントをサポートします。また、コンポジット・イベントが必要なルールベース・アプリケーションにも適しています。ルール・マネージャは、否定、セット・セマンティクス、Any n構成、順序付け、および集合に関連する複雑なルール条件をサポートします。さらに、コンポジット・イベントに関連するルールの増分評価をサポートします。複雑なルール条件は、条件式内のXMLタグを使用して、SQLのWHERE句形式で指定されます。ルール・クラスのイベント管理ポリシー（使用率、競合解消、継続時間など）は、各ルール・アプリケーションに対して実行できます。図1-1に、ルール・マネージャ・ルール・アプリケーションの作成と実装の処理手順を示します。これらの手順の詳細は、第2.3項で説明します。
ルール・マネージャ・アプリケーションの作成、使用およびメンテナンスの詳細は、第I部「ルール・マネージャ」の第2章〜第10章を参照してください。
ルール・マネージャを使用したルール・アプリケーションの開発では、アプリケーション開発について多少異なるアプローチが必要です。通常は、新しいAPIと他の参考資料を調べた後、例に基づいてサンプル・スクリプトを作成し、機能の動作方法に慣れるようにします。次に、習熟したこれらの方法を独自のアプリケーションに適用します。しかし、この方法では、実装の詳細で行き詰まる可能性があります。これは、ルール・マネージャのアプリケーション開発では焦点が多少異なるためです。ここで焦点となるのは、独自のアプリケーションにすでに存在している決定点のみです。アプリケーションの中でこれらの決定点に必ずしも関連しないサポート部分すべてに焦点をあわせる必要はありません。
アプリケーション開発者は、次の事項について確認する必要があります。
アプリケーション内の決定点の位置
各決定点で行われる決定の内容
各決定の方法
決定後のアプリケーションでの実行方法
各決定点では1つ以上のルールが使用される場合があり、これらのルールには、ある順序で発生する1つ以上のイベントが関係している場合があります。
アプリケーション内の決定点を判別した後は、ECAルールの標準表記法を使用してルール・マネージャをアプリケーションに統合し、第1.1項の説明に従って各決定点をモデル化します。アプローチは、できるかぎり単純にすることをお薦めします。
最も単純なルール・マネージャの使用例では、アプリケーションに1つ以上のルールを使用する決定点があり、それぞれのルールがアプリケーションで発生するイベント構造の単一インスタンスに依存している場合、プリミティブ・イベント構造を定義して、これらのイベント・アクティビティをモデル化します。複雑なイベントの例では、アプリケーションに1つ以上のルールを使用する別の決定点があり、それぞれのルールが、ある順序で発生する同じまたは異なるイベント構造の複数のインスタンスに依存している場合、発生する各イベントに対して、別々に定義されたプリミティブ・イベントで構成されるコンポジット・イベント構造を定義します。コンポジット・イベント構造では、これらのプリミティブ・イベントを結合して、コンポジット・イベント・アクティビティをモデル化します。次に、ルール・クラスを作成します。ルール・クラスを作成すると、ルール・クラス表が暗黙的に作成されます。この表には、ルール条件を格納する式列と、ルールがTRUEに評価された場合に適切なアクションを決定するために使用される1つ以上のアクション・プリファレンス列があります。ルール・クラス表の他に、前述の手順ではアクション・コールバック・プロシージャも作成されます。このプロシージャは、一致ルールに対するアクションを実行するように変更できます。
このような特有のアプローチによって、新規アプリケーションと同様、簡単にルール・マネージャを既存アプリケーションに迅速に統合できます。これは、焦点をあわせる必要があるのが、独自のアプリケーションまたは新規アプリケーションの独自のデータ分析に含まれている決定点のみのためです。ルール・マネージャは、ルールを格納して処理し、受け取った単一イベントまたはイベント・グループのインスタンスと照合して、各決定点の周辺に集中しているルールを解決します。したがって、次の目的は、ルール・マネージャを使用して、これらの決定点を最も効率よくモデル化する方法となります。この方法については、第I部「ルール・マネージャ」で説明します。
