| Oracle® Streams概要および管理 11gリリース2 (11.2) B61351-03 |
|
 前 |
 次 |
ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。ルールのコンポーネントは、次のとおりです。
ルール評価コンテキスト(オプション)
ルール・アクション・コンテキスト(オプション)
各ルールは、SQL問合せのWHERE句の条件と同様の条件として指定します。関連するルールをグループ化してルール・セットを作成できます。1つのルールを1つ以上のルール・セットに含めることができます。また、どのルール・セットにも含めなくてもかまいません。
ルール・セットは、Oracleの組込み部分であるルール・エンジンによって評価されます。ユーザー作成アプリケーションとOracle StreamsなどのOracleの機能の両方が、ルール・エンジンのクライアントとなることができます。
|
注意: ルールを評価するには、ルール・セットに含める必要があります。 |
ルール条件は、1つ以上の式と条件を組み合せてブール値を戻します。ブール値は、TRUE、FALSEまたはNULL(不明)のいずれかです。式は、1つ以上の値と、評価結果が値になる演算子の組合せです。値には、表のデータ、変数のデータ、またはSQLファンクションやPL/SQLファンクションから戻されるデータを使用できます。たとえば、次の式には1つの値のみが含まれます。
salary
次の式には2つの値(salaryおよび.1)と1つの演算子(*)が含まれます。
salary * .1
次の条件は2つの式(salaryおよび3800)と1つの条件(=)で構成されています。
salary = 3800
この論理条件は、salary列が3800の場合は、特定の行についてTRUEと評価されます。この場合、値は表のsalary列のデータです。
複数の条件をAND、ORおよびNOT論理条件で結合して複合条件を形成し、1つのルール条件に含めることができます。論理条件は、コンポーネントである2つの条件の結果を結合し、その結果に基づいて1つの結果を生成します。たとえば、次の複合条件を考えます。
salary = 3800 OR job_title = 'Programmer'
このルール条件には、OR論理条件で結合された2つの条件が含まれています。どちらかの条件がTRUEと評価されると、ルール条件がTRUEと評価されます。論理条件がORではなくANDの場合、ルール条件全体がTRUEと評価されるためには、両方の条件がTRUEと評価される必要があります。
ルール条件には変数を使用できます。その場合は、各変数の先頭にコロン(:)を付けます。ルール条件に使用する変数の例を次に示します。
:x = 55
変数を使用すると、表に格納されていないデータを参照できます。また、変数を使用すると、共通して発生する式を置換することでパフォーマンスを改善できます。これは、同じ式が2回以上評価されるかわりに、変数が1回評価されるためです。
ルール条件には、サブプログラムのコールの評価も含めることができます。このような条件は、他の条件と同じ方法で評価されます。つまり、値TRUE、FALSEまたはNULL(不明)として評価されます。次の例に、従業員がマネージャかどうかを判断する単純なファンクションis_managerのコールを含む条件を示します。
is_manager(employee_id) = 'Y'
この場合、employee_idの値はemployee_id列を持つ表のデータによって決定されます。
変数には、ユーザー定義型を使用できます。したがって、変数では属性を指定できます。変数に属性を指定する場合、各属性には変数の部分データが含まれます。ルール条件内では、属性はドット表記法を使用して指定します。たとえば、次の条件は、変数yの属性zの値が9の場合にTRUEと評価されます。
:y.z = 9
|
注意: ルールには、NULL(または空)のルール条件を含めることはできません。 |
|
関連項目:
|
単純ルール条件とは、次のいずれかの形式で表される条件を指します。
simple_rule_expression condition constant
constant condition simple_rule_expression
constant condition constant
単純ルール条件では、simple_rule_expressionは次のいずれかです。
表の列。
変数。
変数の属性。
引数または定数引数を取らないメソッドの結果。そのメソッドの結果は変数メソッド・ファンクションから戻すことができるため、式は単純ルール用にサポートされているデータ型のいずれかです。このようなメソッドには、これらの要件を満たすGET_TAG、GET_VALUE、GET_COMPATIBLE、GET_EXTRA_ATTRIBUTEなどのLCRメンバー・サブプログラムが含まれます。
表の列、変数、変数の属性およびメソッドの結果については、次のデータ型を単純ルール条件に使用できます。
VARCHAR2
NVARCHAR2
NUMBER
DATE
BINARY_FLOAT
BINARY_DOUBLE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
RAW
CHAR
式に他のデータ型を使用すると、単純ルール条件ではなくなります。
単純ルール条件の例を次に示します。式で使用されているデータ型が、単純ルール条件でサポートされていると想定しています。
tab1.col = 5
tab2.col != 5
:v1 > 'aaa'
:v2.a1 < 10.01
:v3.m() = 10
:v4 IS NOT NULL
1 = 1
'abc' > 'AB'
:date_var < to_date('04-01-2004, 14:20:17', 'mm-dd-yyyy, hh24:mi:ss')
:adt_var.ts_attribute >= to_timestamp('04-01-2004, 14:20:17 PST', 'mm-dd-yyyy, hh24:mi:ss TZR')
:my_var.my_to_upper('abc') = 'ABC'
単純ルール条件を含むルールは、単純ルールと呼ばれます。論理条件ANDおよびORを使用して2つ以上の単純な条件を結合したルールも、単純ルールです。たとえば、次の条件を含むルールは単純ルールです。
tab1.col = 5 AND :v1 > 'aaa'
tab1.col = 5 OR :v1 > 'aaa'
ただし、ルールの条件内でNOT論理条件を使用すると、単純ルールではなくなります。
単純ルールは、次の理由で重要です。
単純ルールは、ルール・エンジンによって内部的に索引を付けられます。
単純ルールは、SQLを実行せずに評価できます。
単純ルールは、部分データを使用して評価できます。
クライアントがDBMS_RULE.EVALUATEプロシージャを使用してイベントを評価する場合、クライアントは、simple_rules_onlyパラメータにTRUEを指定すると、単純ルールのみを評価するように指定できます。
|
関連項目:
|
評価コンテキストは、ルール条件内で参照できる外部データを定義するデータベース・オブジェクトです。外部データは、変数または表データ、あるいはその両方として存在します。次のように類推するとわかりやすくなります。ルール条件がSQL問合せのWHERE句であると考えると、評価コンテキスト内の外部データは、その問合せのFROM句で参照される表およびバインド変数です。つまり、有効なWHERE句を作成するには、ルール条件内の式が評価コンテキスト内の表、表の別名および変数を参照する必要があります。
ルール評価コンテキストは、外部データを参照するルール条件の解析と評価に必要な情報を提供します。たとえば、ルールで変数を参照する場合、ルール評価コンテキスト内の情報には変数の型を含める必要があります。また、ルールで表の別名を参照する場合、評価コンテキストには表の別名を定義する情報を含める必要があります。
ルールによって参照されるオブジェクトは、そのルールに関連付けられたルール評価コンテキストによって決定されます。ルール所有者は、表に対するSELECT権限や型に対するEXECUTE権限など、これらのオブジェクトへのアクセスに必要な権限を持つ必要があります。ルール条件は、評価コンテキストを所有するスキーマ内で解決されます。
たとえば、次の情報を含むルール評価コンテキストhr_evaluation_contextを考えます。
表の別名depは、hr.departments表に対応します。
変数loc_id1およびloc_id2は、どちらもNUMBER型です。
hr_evaluation_contextルール評価コンテキストは、次のルール条件の評価に必要な情報を提供します。
dep.location_id IN (:loc_id1, :loc_id2)
この場合、loc_id1またはloc_id2変数で渡されたいずれかの値に対応する値が行のlocation_id列に含まれていると、hr.departments表のその行についてはルール条件がTRUEと評価されます。hr_evaluation_contextルール評価コンテキスト内に情報がなければ、ルールを適切に解析または評価できません。また、表の別名depでのlocation_id列の指定にドット表記法を使用していることに注意してください。
|
注意: ビューは、評価コンテキストの実表としてはサポートされていません。 |
ルール条件内で参照される変数の値をルールが評価されるときに明示的に指定するか、変数の値を特定のイベントに暗黙的に使用可能にすることができます。
明示的変数は、評価時にコール元から提供されます。これらの値は、DBMS_RULE.EVALUATEプロシージャの実行時にvariable_valuesパラメータで指定します。
暗黙的変数には、評価時にコール元から提供される値が与えられません。暗黙的変数の値は、変数値のファンクションをコールすることで取得されます。このファンクションは、DBMS_RULE_ADMパッケージのCREATE_EVALUATION_CONTEXTプロシージャを使用して評価コンテキストの作成中にvariable_typesリストを指定するときに定義します。暗黙的変数の値が評価中に指定されると、その値によって変数値のファンクションから戻される値がオーバーライドされます。
特に、variable_typesリストはSYS.RE$VARIABLE_TYPE_LIST型であり、SYS.RE$VARIABLE_TYPE型の変数のリストです。リストにあるSYS.RE$VARIABLE_TYPEの各インスタンス内で、暗黙的変数の値の決定に使用されるファンクションをvariable_value_function属性として指定します。
変数が明示的であるか暗黙的であるかは、ルール・エンジンを使用するアプリケーションのデザイナによって選択されます。暗黙的変数を使用する理由は、次のとおりです。
DBMS_RULE.EVALUATEプロシージャのコール元は、変数を意識する必要はありません。このため、ルール・エンジンを使用するアプリケーションの複雑さを軽減できます。たとえば、変数では、評価対象のデータに基づいて値を戻すファンクションをコールできます。
コール元には、変数値のファンクションに対するEXECUTE権限がなくてもかまいません。
DBMS_RULE.EVALUATEプロシージャのコール元は、イベントに基づいた変数値を認識しません。このため、変数値に機密情報が含まれている場合に、セキュリティを向上できます。
変数の使用頻度は低くなり、また変数の値は必要に応じていつでも導出できます。このような変数を暗黙的変数にすると、DBMS_RULE.EVALUATEプロシージャのコール元では、一般的ではない多数の変数を指定する必要がなくなります。
たとえば、次のルール条件では、変数xおよびyの値を明示的に指定し、変数maxの値はmaxファンクションを実行して戻すように指定できます。
:x = 4 AND :y < :max
また、変数xおよびyを暗黙的変数に、変数maxを明示的変数にすることもできます。そのため、ルール条件内では、明示的変数と暗黙的変数に構文上の違いはありません。変数が明示的であるか暗黙的であるかは、DBA_EVALUATION_CONTEXT_VARSデータ・ディクショナリ・ビューを問い合せることで判断できます。明示的変数の場合は、VARIABLE_VALUE_FUNCTIONフィールドがNULLになっています。暗黙的変数の場合、このフィールドにはその変数によってコールされるファンクションの名前が含まれます。
|
関連項目:
|
ルールを評価するには、各ルールが評価コンテキストと関連付けられているか、評価コンテキストに関連付けられたルール・セットの一部である必要があります。1つの評価コンテキストを、複数のルールまたはルール・セットに関連付けることができます。次のリストに、ルールが評価されるときに使用される評価コンテキストを示します。
評価コンテキストがルールに関連付けられている場合は、ルールが評価されるたびにその評価コンテキストが使用され、評価対象のルール・セットに関連付けられている評価コンテキストは無視されます。
ルールに評価コンテキストがなくても、DBMS_RULE_ADMパッケージのADD_RULEプロシージャを使用してルール・セットにルールを追加するときに、ルール用の評価コンテキストを指定した場合、ルール・セットが評価されるときには、ADD_RULEプロシージャで指定した評価コンテキストがルールに使用されます。
ルール評価コンテキストがルールに関連付けられておらず、ADD_RULEプロシージャでも指定されていない場合、ルール・セットが評価されるときには、ルール・セットの評価コンテキストがルールに使用されます。
|
注意: ルールに評価コンテキストがない場合に、そのルールを評価コンテキストのないルール・セットに追加しようとすると、ADD_RULEプロシージャの実行時に評価コンテキストを指定しないかぎりエラーが発生します。 |
ルール評価コンテキストで実行する評価ファンクションを作成できるようにオプションが用意されています。次のような理由で、評価ファンクションを使用できます。
ルール・エンジンをバイパスし、かわりに評価ファンクションを使用してイベントを評価する場合。
イベントをフィルタ処理して、一部のイベントは評価ファンクションを使用して評価し、他のイベントはルール・エンジンを使用して評価する場合。
DBMS_RULE_ADMパッケージのCREATE_EVALUATION_CONTEXTプロシージャを使用してルール評価コンテキストを作成するときに、evaluation_functionパラメータにファンクション名を指定して、ファンクションをルール評価コンテキストに関連付けます。評価ファンクションは、評価コンテキストを使用する任意のルール・セットの評価中に、ルール・エンジンによって起動されます。
DBMS_RULE.EVALUATEプロシージャはオーバーロードされます。ファンクションには、いずれかのDBMS_RULE.EVALUATEプロシージャの各パラメータが必要です。各パラメータには、DBMS_RULE.EVALUATEプロシージャ内の対応するパラメータと同じ型を使用する必要がありますが、パラメータの名前は異なってもかまいません。
評価ファンクションから戻される値は、次のとおりです。
DBMS_RULE_ADM.EVALUATION_SUCCESS: ユーザーによって指定された評価ファンクションが、ルール・セットの評価を正常終了しました。ルール・エンジンは、評価ファンクションによって取得された評価結果をDBMS_RULE.EVALUATEプロシージャを使用してルール・エンジン・クライアントに戻します。
DBMS_RULE_ADM.EVALUATION_CONTINUE: ルール・エンジンは、評価ファンクションが存在しない場合と同様にルール・セットを評価します。評価ファンクションは使用されず、評価ファンクションから戻されるすべての結果は無視されます。
DBMS_RULE_ADM.EVALUATION_FAILURE: ユーザーによって指定された評価ファンクションが失敗しました。ルール・セットの評価は停止し、エラーが発生します。
ルール・エンジンを常にバイパスする場合は、評価ファンクションはEVALUATION_SUCCESSまたはEVALUATION_FAILUREを戻す必要があります。ただし、一部のイベントを評価ファンクションで評価し、他のイベントをルール・エンジンで評価するようにイベントをフィルタ処理する場合は、評価ファンクションが3つの戻り値すべてを戻すことができます。評価にルール・エンジンを使用する必要がある場合は、EVALUATION_CONTINUEを戻します。
評価コンテキストに対して評価ファンクションを指定していると、その評価コンテキストがルール・セットまたはルールによって使用される場合、評価中にその評価ファンクションが実行されます。
|
関連項目: DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXTプロシージャ内に指定する評価ファンクションの詳細およびオーバーロードされたDBMS_RULE.EVALUATEプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照 |
アクション・コンテキストには、イベントのルールの評価時にルール・エンジンのクライアントによって解析されるルールに関連付けられたオプションの情報が含まれています。ルール・エンジンのクライアントは、ユーザー作成アプリケーション、またはOracle StreamsなどのOracleの内部機能です。各ルールのアクション・コンテキストは1つのみです。アクション・コンテキスト内の情報は、名前/値ペアの配列を含む型であるSYS.RE$NV_LIST型です。
ルール・アクション・コンテキスト情報は、ルールがTRUEまたはMAYBEに評価される場合に、ルール・エンジンのクライアントによって実行されるアクションのコンテキストを提供します。ルール・エンジンは、アクション・コンテキストを解析しません。かわりに、ルール・エンジンはアクション・コンテキストを戻し、ルール・エンジンのクライアントがアクション・コンテキスト情報を解析できます。
たとえば、イベントが会社への新規従業員の追加として定義されているとします。従業員情報がhr.employees表に格納されている場合は、この表に行が挿入されるたびにイベントが発生します。会社は、新規従業員を追加するときにいくつかのアクションが実行されるように指定する必要がありますが、アクションは従業員の所属部門に応じて異なります。これらのアクションの1つは、従業員を部門関連のコースに登録することです。
この使用例では、会社は適切なアクション・コンテキストを使用して、各部門用のルールを作成できます。この場合、ルールがTRUEと評価された場合に戻されるアクション・コンテキストでは、従業員が参加する必要のあるコースの番号を指定します。3つの部門がある場合のルール条件の一部およびアクション・コンテキストを次に示します。
| ルール名 | ルール条件の一部 | アクション・コンテキストの名前/値ペア |
|---|---|---|
rule_dep_10 |
department_id = 10 |
course_number, 1057 |
rule_dep_20 |
department_id = 20 |
course_number, 1215 |
rule_dep_30 |
department_id = 30 |
NULL |
これらのアクション・コンテキストでは、クライアント・アプリケーションに次の指示が戻されます。
rule_dep_10ルールのアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をコース番号1057に登録するように指示します。
rule_dep_20ルールのアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をコース番号1215に登録するように指示します。
rule_dep_30ルールのNULLアクション・コンテキストはクライアント・アプリケーションに対して、新規従業員をどのコースにも登録しないように指示します。
各アクション・コンテキストには、0個以上の名前/値ペアを含めることができます。アクション・コンテキストに複数の名前/値ペアが含まれている場合、リスト内のそれぞれの名前は一意である必要があります。この例では、ルール・エンジンからアクション・コンテキストが戻されるクライアント・アプリケーションでは、戻されたコース番号を持つコースに新規従業員が登録されます。NULLアクション・コンテキストが戻される場合や、アクション・コンテキストにコース番号が含まれていない場合、クライアント・アプリケーションでは従業員はコースに登録されません。
複数のクライアントで同じルールを使用する場合や、アクション・コンテキストから複数の名前/値ペアが戻されるようにする必要がある場合は、1つのアクション・コンテキストで複数の名前/値ペアをリストできます。たとえば、会社が新規従業員を部門の電子メール・リストにも追加する場合を考えます。この場合、rule_dep_10ルールのアクション・コンテキストに次の2つの名前/値ペアを含めることができます。
| 名前 | 値 |
|---|---|
course_number |
1057 |
dist_list |
admin_list |
名前/値ペアで指定する名前については、次のことを考慮する必要があります。
異なるアプリケーションで同じアクション・コンテキストを使用する場合は、異なる名前または名前の接頭辞を使用してネーミングの競合を回避してください。
Oracleが提供するアクション・コンテキスト名との競合が発生する可能性があるため、名前には$と#を使用しないでください。
アクション・コンテキストに名前/値ペアを追加するには、RE$NV_LIST型のADD_PAIRメンバー・プロシージャを使用します。アクション・コンテキストから名前/値ペアを削除するには、RE$NV_LIST型のREMOVE_PAIRメンバー・プロシージャを使用します。アクション・コンテキスト内の既存の名前/値ペアを変更する場合は、最初にREMOVE_PAIRメンバー・プロシージャを使用して削除してから、ADD_PAIRメンバー・プロシージャを使用して適切な名前/値ペアを追加する必要があります。
|
注意: Oracle Streamsでは、カスタム・ルールベースの変換にアクション・コンテキストが使用されます。サブセット・ルールが指定されている場合は、UPDATE操作を含むLCRで必要な内部変換にも、アクション・コンテキストが使用されます。また、Oracle Streamsでは、アクション・コンテキストを使用して、ルールを満たすメッセージを適用プロセスがエンキューする宛先キューを指定します。さらに、Oracle Streamsでは、アクション・コンテキストを使用して、適用プロセスのルールを満たすメッセージを適用プロセスで実行するかどうかを指定します。 |
|
関連項目:
|
ルール・エンジンは、イベントに対してルール・セットを評価します。イベントとは、ルール・エンジンのクライアントによって定義された状態変化です。クライアントは、DBMS_RULE.EVALUATEプロシージャをコールして、イベントの評価を開始します。このプロシージャを使用すると、クライアントは、イベントに関するなんらかの情報をルール・セットの評価用のルール・エンジンに送信できます。イベント自体には、クライアントがルール・エンジンに送信する情報以外の情報を含めることができます。
DBMS_RULE.EVALUATEプロシージャのコール時にクライアントによって指定される情報には、次の項目が含まれます。
イベントの評価に使用するルールを含むルール・セットの名前。
評価に使用する評価コンテキスト。指定した評価コンテキストを使用するルールのみが評価されます。
表の値および変数値。表の値にはその表の行のデータを参照するROWIDが含まれ、変数値には明示的変数のデータが含まれます。暗黙的変数に指定された値は、変数値のファンクションを使用して取得される値をオーバーライドします。指定された変数に属性がある場合、クライアントはその変数全体に対する1つの値を送信するか、またはその変数の任意の数の属性の値を送信できます。ただし、変数全体に対する値が指定されている場合は、クライアントは属性の値を指定できません。
オプションのイベント・コンテキスト。イベント・コンテキストは、名前/値ペアを含むSYS.RE$NV_LIST型のVARRAYで、イベントに関する情報を含みます。このオプションの情報がルール・エンジンによって直接使用または解析されることはありません。かわりに、評価ファンクション、変数値のファンクション(暗黙的変数用)、変数メソッド・ファンクションなど、クライアントのコールバックに渡されます。
また、クライアントは、DBMS_RULE.EVALUATEプロシージャを使用して、ルール・セットでのイベントの評価方法に関する情報を送信することもできます。たとえば、最初のTRUEルールまたは最初のMAYBEルール(TRUEルールがない場合)が検出された時点で評価を停止する必要があるかどうかを、コール元が指定できます。
TRUEまたはMAYBEと評価されるすべてのルールをクライアントに戻す必要がある場合、クライアントは、TRUEまたはMAYBEと評価されたルールの完全なリストを使用して評価結果が送信されるようにするか、または評価結果が繰り返し送信されるようにするかを指定できます。評価結果がクライアントに繰り返し送信される場合、クライアントは、DBMS_RULEパッケージのGET_NEXT_HITファンクションを使用して、TRUEまたはMAYBEと評価された各ルールを1つずつ取り出せます。
ルール・エンジンは、指定されたルール・セット内のルールを評価に使用し、クライアントにその結果を戻します。ルールが戻されるときには、EVALUATEプロシージャの2つのOUTパラメータが使用されます。このプロシージャはオーバーロードされ、2つのOUTパラメータはプロシージャのバージョンごとに異なります。
プロシージャの一方のバージョンでは、TRUEと評価されるすべてのルールまたはMAYBEと評価されるすべてのルールが1つのリストで戻されます。プロシージャのこのバージョンでは、2つのOUTパラメータはtrue_rulesおよびmaybe_rulesです。true_rulesパラメータではTRUEと評価されるルールが1つのリストで戻され、maybe_rulesパラメータではさらに情報を与えるとTRUEと評価される可能性があるルールが1つのリストで戻されます。
プロシージャのもう一方のバージョンでは、TRUEまたはMAYBEと評価されるすべてのルールがクライアントの要求に応じて繰り返し戻されます。プロシージャのこのバージョンでは、2つのOUTパラメータはtrue_rules_iteratorおよびmaybe_rules_iteratorです。true_rules_iteratorパラメータではTRUEと評価されるルールが1つずつ戻され、maybe_rules_iteratorパラメータではさらに情報を与えるとTRUEと評価される可能性があるルールが1つずつ戻されます。
クライアント定義のイベントが発生します。
クライアントは、DBMS_RULE.EVALUATEプロシージャを使用してイベントに関する情報をルール・エンジンに送信し、ルール・セットの評価を開始します。
ルール・エンジンが、関連する評価コンテキストを使用してイベントのルール・セットを評価します。クライアントが、DBMS_RULE.EVALUATEプロシージャのコールでルール・セットと評価コンテキストの両方を指定します。評価に使用されるのは、指定されたルール・セット内に存在し、指定された評価コンテキストを使用するルールのみです。
ルール・エンジンが評価の結果を取得します。各ルールは、TRUE、FALSEまたはNULL(不明)と評価されます。
ルール・エンジンが、TRUEと評価されたルールを完全なリストで、または1つずつクライアントに戻します。各ルールとともにアクション・コンテキスト全体が戻されます。アクション・コンテキストには、情報が含まれている場合とNULLの場合があります。
クライアントが、ルール・エンジンから戻された結果に基づいてアクションを実行します。ルール・エンジンでは、ルールの評価に基づくアクションは実行されません。
|
関連項目:
|
部分評価は、指定された評価コンテキストのすべての表および変数にデータがない状態でDBMS_RULE.EVALUATEプロシージャが実行される場合に発生します。部分評価では、一部のルールが使用不可能な列、変数または属性を参照し、別の一部のルールが使用可能なデータのみを参照する場合があります。
例として、評価中に使用可能なデータが次のものにかぎられる場合を考えます。
列tab1.col = 7
属性v1.a1 = 'ABC'
次のルールが評価に使用されます。
ルールR1には、次の条件があります。
(tab1.col = 5)
ルールR2には、次の条件があります。
(:v1.a2 > 'aaa')
ルールR3には、次の条件があります。
(:v1.a1 = 'ABC') OR (:v2 = 5)
ルールR4には、次の条件があります。
(:v1.a1 = UPPER('abc'))
この使用例では、R1およびR4は使用可能なデータを、R2は使用不可能なデータを、R3は使用可能なデータおよび使用不可能なデータを参照します。
部分評価は常に、ルール内の単純な条件のみを評価します。ルール条件に単純でない部分が含まれている場合は、データがどの程度使用可能であるかに応じて、ルールが完全に評価される場合と評価されない場合があります。ルールが完全に評価されない場合、それをMAYBEルールとして戻すことができます。
前述の使用例では、R1と、R3の最初の部分が評価されますが、R2およびR4は評価されません。クライアントには次の結果が戻されます。
R1はFALSEと評価されるため、戻されません。
R2は、属性v1.a2に関する情報が使用可能でないため、MAYBEとして戻されます。
R3は単純ルールであり、v1.a1の値がルール条件の最初の部分と一致するため、R3はTRUEとして戻されます。
R4は、ルール条件が単純ではないため、MAYBEとして戻されます。このルールをTRUEまたはFALSEとして評価するには、クライアントが変数v1の値を指定する必要があります。
DBMS_RULE_ADMパッケージを使用して、次の型のデータベース・オブジェクトを直接作成できます。
評価コンテキスト
ルール
ルール・セット
DBMS_STREAMS_ADMパッケージを使用すると、ルールとルール・セットを間接的に作成できます。これらのデータベース・オブジェクトに対する権限を制御するには、DBMS_RULE_ADMパッケージの次のプロシージャを使用します。
GRANT_OBJECT_PRIVILEGE
GRANT_SYSTEM_PRIVILEGE
REVOKE_OBJECT_PRIVILEGE
REVOKE_SYSTEM_PRIVILEGE
ユーザーに対して独自スキーマ内でのルール・セット、ルールおよび評価コンテキストの作成を許可するには、そのユーザーに次のシステム権限を付与します。
CREATE_RULE_SET_OBJ
CREATE_RULE_OBJ
CREATE_EVALUATION_CONTEXT_OBJ
これらの権限と後述する権限は、ユーザーに直接付与するか、ロールを介して付与できます。
この項の内容は次のとおりです。
|
注意: ANYオブジェクト(ALTER_ANY_RULEなど)に対する権限を付与する場合に、初期化パラメータO7_DICTIONARY_ACCESSIBILITYをFALSEに設定すると、SYSスキーマを除くすべてのスキーマに含まれる指定した型のオブジェクトへのアクセス権をユーザーに付与できます。デフォルトでは、初期化パラメータO7_DICTIONARY_ACCESSIBILITYはFALSEに設定されます。
|
|
関連項目:
|
ユーザーがスキーマ内で評価コンテキスト、ルールまたはルール・セットを作成するには、次の条件を少なくとも1つは満たしている必要があります。
スキーマがユーザー独自のスキーマであり、作成するデータベース・オブジェクトの型に対するCREATEシステム権限を付与されていること。たとえば、ユーザーが独自スキーマ内でルール・セットを作成するには、CREATE_RULE_SET_OBJシステム権限を付与されている必要があります。
作成するデータベース・オブジェクトの型に対するCREATE ANYシステム権限を付与されていること。たとえば、ユーザーが任意のスキーマ内で評価コンテキストを作成するには、CREATE_ANY_EVALUATION_CONTEXTシステム権限を付与されている必要があります。
|
注意: 評価コンテキストを伴うルールを作成する場合、ルール所有者は、評価コンテキストによってアクセスされるすべてのオブジェクトに対する権限を持っている必要があります。 |
ユーザーが評価コンテキスト、ルールまたはルール・セットを変更するには、次の条件を少なくとも1つは満たしている必要があります。
データベース・オブジェクトの所有者であること。
データベース・オブジェクトが他のユーザーのスキーマにある場合は、データベース・オブジェクトに対するALTER OBJECT権限を付与されていること。たとえば、ユーザーが他のユーザーのスキーマにあるルール・セットを変更するには、そのルール・セットに対するALTER_ON_RULE_SETオブジェクト権限を付与されている必要があります。
データベース・オブジェクトに対するALTER ANYシステム権限を付与されていること。たとえば、ユーザーが任意のスキーマにあるルールを変更するには、ALTER_ANY_RULEシステム権限を付与されている必要があります。
ユーザーが評価コンテキスト、ルールまたはルール・セットを削除するには、次の条件を少なくとも1つは満たしている必要があります。
データベース・オブジェクトの所有者であること。
データベース・オブジェクトに対するDROP ANYシステム権限を付与されていること。たとえば、ユーザーが任意のスキーマにあるルール・セットを削除するには、DROP_ANY_RULE_SETシステム権限を付与されている必要があります。
この項では、ルール・セットにルールを含めるために必要な権限について説明します。ユーザーは、ルールについて次の条件を少なくとも1つは満たしている必要があります。
ルールの所有者であること。
ルールが他のユーザーのスキーマにある場合は、そのルールに対するEXECUTE OBJECT権限を付与されていること。たとえば、ユーザーがhrスキーマ内でルール・セットにルールdeptsを含めるには、hr.deptsルールに対するEXECUTE_ON_RULE権限を付与されている必要があります。
ルールに対するEXECUTE ANYシステム権限を付与されていること。たとえば、ユーザーがルール・セットに任意のルールを含めるには、EXECUTE_ANY_RULEシステム権限を付与されている必要があります。
また、ユーザーはルール・セットについて次の条件を少なくとも1つは満たしている必要があります。
ルール・セットの所有者であること。
ルール・セットが他のユーザーのスキーマにある場合は、そのルール・セットに対するALTER OBJECT権限を付与されていること。たとえば、ユーザーがhrスキーマ内でhuman_resourcesルール・セットにルールを含めるには、hr.human_resourcesルール・セットに対するALTER_ON_RULE_SET権限を付与されている必要があります。
ルール・セットに対するALTER ANYシステム権限を付与されていること。たとえば、ユーザーが任意のルール・セットにルールを含めるには、ALTER_ANY_RULE_SETシステム権限を付与されている必要があります。
また、ルール所有者は、ルールによって参照されるすべてのオブジェクトに対する権限を持っている必要があります。この権限は、ルールに関連付けられた評価コンテキストが存在しない場合に重要です。
ルール・セットを評価するには、ユーザーは次の条件を少なくとも1つは満たしている必要があります。
ルール・セットの所有者であること。
ルール・セットが他のユーザーのスキーマにある場合は、そのルール・セットに対するEXECUTE OBJECT権限を付与されていること。たとえば、ユーザーがhrスキーマ内でhuman_resourcesルール・セットを評価するには、hr.human_resourcesルール・セットに対するEXECUTE_ON_RULE_SET権限を付与されている必要があります。
ルール・セットに対するEXECUTE ANYシステム権限を付与されていること。たとえば、ユーザーが任意のルール・セットを評価するには、EXECUTE_ANY_RULE_SETシステム権限を付与されている必要があります。
ルール・セットに対するEXECUTEオブジェクト権限を付与するには、権限付与者のEXECUTE権限で、現在ルール・セットに含まれているすべてのルールについてWITH GRANT OPTIONを指定する必要があります。
次の各項では、Oracle Streamsで使用されるシステム作成の評価コンテキストについて説明します。
グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールを作成する際、システム作成のルール・セットおよびルールでは、SYSスキーマ内のSTREAMS$_EVALUATION_CONTEXTという名前の組込み評価コンテキストが使用されます。この評価コンテキストのEXECUTE権限はPUBLICに付与されます。グローバル・ルール、スキーマ・ルール、表ルールおよびサブセット・ルールは、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントで使用できます。
Oracleのインストール中に、次の文によってOracle Streamsの評価コンテキストが作成されます。
DECLARE
vt SYS.RE$VARIABLE_TYPE_LIST;
BEGIN
vt := SYS.RE$VARIABLE_TYPE_LIST(
SYS.RE$VARIABLE_TYPE('DML', 'SYS.LCR$_ROW_RECORD',
'SYS.DBMS_STREAMS_INTERNAL.ROW_VARIABLE_VALUE_FUNCTION',
'SYS.DBMS_STREAMS_INTERNAL.ROW_FAST_EVALUATION_FUNCTION'),
SYS.RE$VARIABLE_TYPE('DDL', 'SYS.LCR$_DDL_RECORD',
'SYS.DBMS_STREAMS_INTERNAL.DDL_VARIABLE_VALUE_FUNCTION',
'SYS.DBMS_STREAMS_INTERNAL.DDL_FAST_EVALUATION_FUNCTION'));
SYS.RE$VARIABLE_TYPE(NULL, 'SYS.ANYDATA',
NULL,
'SYS.DBMS_STREAMS_INTERNAL.ANYDATA_FAST_EVAL_FUNCTION'));
DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT(
evaluation_context_name => 'SYS.STREAMS$_EVALUATION_CONTEXT',
variable_types => vt,
evaluation_function =>
'SYS.DBMS_STREAMS_INTERNAL.EVALUATION_CONTEXT_FUNCTION');
END;
/
この文には、SYS.DBMS_STREAM_INTERNALパッケージ内の次の内部ファンクションへの参照が含まれます。
ROW_VARIABLE_VALUE_FUNCTION
DDL_VARIABLE_VALUE_FUNCTION
EVALUATION_CONTEXT_FUNCTION
ROW_FAST_EVALUATION_FUNCTION
DDL_FAST_EVALUATION_FUNCTION
ANYDATA_FAST_EVAL_FUNCTION
|
注意: 前述の内部ファンクションに関する情報は、あくまでも参考用です。これらのファンクションは直接実行しないでください。 |
ROW_VARIABLE_VALUE_FUNCTIONでは、SYS.LCR$_ROW_RECORDインスタンスをカプセル化するANYDATAペイロードがSYS.LCR$_ROW_RECORDインスタンスに変換されてから、データに対するルールが評価されます。
DDL_VARIABLE_VALUE_FUNCTIONでは、SYS.LCR$_DDL_RECORDインスタンスをカプセル化するANYDATAペイロードがSYS.LCR$_DDL_RECORDインスタンスに変換されてから、データに対するルールが評価されます。
EVALUATION_CONTEXT_FUNCTIONは、CREATE_EVALUATION_CONTEXTプロシージャのコールでevaluation_functionとして指定されます。このファンションによって、取得LCRに対する通常のルール評価が補足されます。取得プロセスによって行LCRとDDL LCRがそのキューにエンキューされ、このファンクションによってコミット、ロールバック、データ・ディクショナリの変更などの他の内部メッセージをキューにエンキューできます。取得プロセスによってエンキューされる情報は、伝播または適用プロセスのルール評価中にも使用されます。同期取得ではEVALUATION_CONTEXT_FUNCTIONは使用されません。
ROW_FAST_EVALUATION_FUNCTIONでは、ルール評価中に次のLCR$_ROW_RECORDメンバー・ファンクションへのアクセスを最適化することで、パフォーマンスが改善されます。
GET_OBJECT_OWNER
GET_OBJECT_NAME
IS_NULL_TAG
GET_SOURCE_DATABASE_NAME
GET_COMMAND_TYPE
DDL_FAST_EVALUATION_FUNCTIONでは、条件が<、<=、=、>=または>であり、残りのオペランドが定数である場合は、ルール評価中に次のLCR$_DDL_RECORDメンバー・ファンクションへのアクセスを最適化することで、パフォーマンスが改善されます。
GET_OBJECT_OWNER
GET_OBJECT_NAME
IS_NULL_TAG
GET_SOURCE_DATABASE_NAME
GET_COMMAND_TYPE
GET_BASE_TABLE_NAME
GET_BASE_TABLE_OWNER
ANYDATA_FAST_EVAL_FUNCTIONでは、ANYDATAオブジェクト内の値へのアクセスを最適化することで、パフォーマンスが改善されます。
DBMS_STREAMS_ADMパッケージを使用して作成されたルールでは、ADD_SUBSET_RULESまたはADD_SUBSET_PROPAGATION_RULESプロシージャを使用して作成されたサブセット・ルールを除き、ROW_FAST_EVALUATION_FUNCTIONまたはDDL_FAST_EVALUATION_FUNCTIONが使用されます。
|
関連項目:
|
ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEプロシージャを使用してメッセージ・ルールを作成する場合、メッセージ・ルールでは作成時に指定したユーザー定義のメッセージ・タイプが使用されます。このようなシステム作成メッセージ・ルールでは、システム作成評価コンテキストが使用されます。システム作成評価コンテキスト名は、メッセージ・ルールの作成に使用されるメッセージ・タイプごとに異なります。このような評価コンテキストにはシステム生成名が付けられ、ルールを所有するスキーマに作成されます。この評価コンテキストのEXECUTE権限は、この評価コンテキストを所有するユーザーにのみ付与されます。
このタイプのメッセージ・ルールの評価コンテキストには、メッセージ・タイプと同じタイプの変数が含まれます。この変数の名前はVAR$_numberという形式になります(numberはシステム生成番号)。たとえば、メッセージ・ルールの作成時にstrmadmin.region_pri_msgをメッセージ・タイプとして指定すると、システム作成評価コンテキストにこのタイプの変数が組み込まれ、変数がルール条件で使用されます。次の文によってstrmadmin.region_pri_msgタイプを作成したと想定します。
CREATE TYPE strmadmin.region_pri_msg AS OBJECT( region VARCHAR2(100), priority NUMBER, message VARCHAR2(3000)) /
このタイプを使用してメッセージ・ルールを作成すると、次のルール条件を指定できます。
:msg.region = 'EUROPE' AND :msg.priority = '1'
システム作成メッセージ・ルールでは、指定したルール条件の:msgが変数名で置換されます。置換されたメッセージ・ルール条件の例を次に示します。
:VAR$_52.region = 'EUROPE' AND :VAR$_52.priority = '1'
この場合、VAR$_52が変数名、変数VAR$_52のタイプがstrmadmin.region_pri_msgであり、ルールの評価コンテキストにこの変数が含まれます。
メッセージ・ルールそのものに評価コンテキストが含まれます。次のような文によってメッセージ・ルールの評価コンテキストが作成されます。
DECLARE
vt SYS.RE$VARIABLE_TYPE_LIST;
BEGIN
vt := SYS.RE$VARIABLE_TYPE_LIST(
SYS.RE$VARIABLE_TYPE('VAR$_52', 'STRMADMIN.REGION_PRI_MSG',
'SYS.DBMS_STREAMS_INTERNAL.MSG_VARIABLE_VALUE_FUNCTION', NULL));
DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXT(
evaluation_context_name => 'STRMADMIN.EVAL_CTX$_99',
variable_types => vt,
evaluation_function => NULL);
END;
/
評価コンテキストの名前はEVAL_CTX$_numberという形式になります(numberはシステム生成番号)。この例では、評価コンテキスト名はEVAL_CTX$_99になります。
この文には、SYS.DBMS_STREAM_INTERNALパッケージのMSG_VARIABLE_VALUE_FUNCTION内部ファンクションへの参照も含まれています。このファンクションでは、メッセージ・インスタンスをカプセル化するANYDATAペイロードが変数と同じタイプのインスタンスに変換された後、データに対するルールが評価されます。たとえば、変数のタイプがstrmadmin.region_pri_msgである場合、MSG_VARIABLE_VALUE_FUNCTIONでは、メッセージ・ペイロードがANYDATAペイロードからstrmadmin.region_pri_msgペイロードに変換されます。
様々なメッセージ・タイプについてルールを作成する場合、Oracleでは、それぞれのメッセージ・タイプに対して異なる評価コンテキストが作成されます。既存のルールと同じメッセージ・タイプのルールを作成する場合、新規ルールでは既存のルールの評価コンテキストが使用されます。ADD_MESSAGE_RULEまたはADD_MESSAGE_PROPAGATION_RULEによってメッセージ・クライアントまたは適用プロセスのルール・セットを作成する場合は、新規のルール・セットには評価コンテキストが含まれません。
Oracle Streamsで、取得プロセス、同期取得およびメッセージ・クライアントではイベント・コンテキストは使用されませんが、伝播および適用プロセスでは使用されます。取得LCR、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよび永続ユーザー・メッセージの各タイプのメッセージを、キュー内でステージングできます。メッセージがキュー内でステージングされると、伝播または適用プロセスでは、メッセージとイベント・コンテキストを評価するためにルール・エンジンに送信できます。イベント・コンテキストには常に、AQ$_MESSAGEを名前、メッセージを値とする名前/値ペアがあります。
カスタム評価コンテキストを作成する場合は、暗黙的変数を使用して、Oracle Streamsイベントを参照する伝播および適用プロセスのルールを作成できます。各暗黙的変数の変数値ファンクションでは、AQ$_MESSAGEという名前のイベント・コンテキストをチェックできます。この名前のイベント・コンテキストが検出されると、変数値ファンクションによってメッセージに基づく値が返されます。イベント・コンテキストは、評価ファンクションおよび変数メソッド・ファンクションにも渡すことができます。
次の各項では、Oracle Streamsにおけるアクション・コンテキストの用途と、特定のルール条件についてTRUEと評価できるルールがルール・セット内に1つのみであることの重要性について説明します。
Oracle Streamsにおけるアクション・コンテキストの用途は、次のとおりです。
それぞれの用途に対し、ルールのアクション・コンテキストには異なる名前/値ペアが存在する場合があります。ルールのアクション・コンテキストに複数の名前/値ペアが含まれる場合、名前/値ペアで指定または記述されたアクションは、次の順序で実行されます。
サブセットの変換が実行されます。
宣言ルールベースの変換に関する情報が表示されます。
カスタム・ルールベースの変換が実行されます。
実行ディレクティブに従います。指示があれば、その指示が実行されます(適用のみ)。
宛先キューにエンキューされます(適用のみ)。
|
注意: ルールのアクション・コンテキストで指定されたアクションは、そのルールが取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントのポジティブ・ルール・セットに含まれる場合にのみ実行されます。ルールがネガティブ・ルール・セットに含まれる場合、そのルールのアクション・コンテキストはこれらのOracle Streamsクライアントによって無視されます。 |
サブセット・ルールを使用すると、更新操作が、取得、伝播、適用またはデキューされる際に挿入操作または削除操作に変換されることがあります。この自動変換は行の移行と呼ばれ、サブセット・ルールがTRUEと評価された場合に、アクション・コンテキストで指定された内部変換によって実行されます。サブセット変換の名前/値ペアでは、名前はSTREAMS$_ROW_SUBSET、値はINSERTまたはDELETEとなります。
宣言ルールベースの変換は、ルールがTRUEと評価された結果発生する行LCRの内部変更です。宣言ルールベースの変換の名前/値ペアでは、名前はSTREAMS$_INTERNAL_TRANFORM、値は変換に関する追加情報を提供するデータ・ディクショナリ・ビューの名前となります。
宣言ルールベースの変換に追加される名前/値ペアは、あくまでも参考用です。これらの名前/値ペアは、Oracle Streamsクライアントによって使用されません。ただし、アクション・コンテキストに記述された宣言ルールベースの変換は、同じアクション・コンテキストに指定されたどのカスタム・ルールベースの変換よりも前に内部的に実行されます。
カスタム・ルールベースの変換は、ルールがTRUEと評価された場合に発生する、ユーザー定義ファンクションによるメッセージの変更です。カスタム・ルールベースの変換の名前/値ペアでは、名前はSTREAMS$_TRANSFORM_FUNCTION、値は変換ファンクションの名前となります。
DBMS_APPLY_ADMパッケージのSET_EXECUTEプロシージャでは、指定されたルールを満たすメッセージが適用プロセスで実行されるかどうかが指定されます。適用プロセスでメッセージを実行しない場合、実行ディレクティブの名前/値ペアでは、名前はAPPLY$_EXECUTE、値はNOとなります。ルールを満たすメッセージを適用プロセスで実行する場合は、そのルールのアクション・コンテキストにこの名前/値ペアを含めません。
DBMS_APPLY_ADMパッケージのSET_ENQUEUE_DESTINATIONプロシージャでは、指定されたルールを満たすメッセージが適用プロセスによって自動的にエンキューされるキューが設定されます。エンキューの宛先の名前/値ペアでは、名前はAPPLY$_ENQUEUE、値は宛先キューの名前となります。
ポジティブ・ルール・セット内の1つ以上のルールにNULL以外のアクション・コンテキストを使用する場合は、特定のルール条件についてTRUEと評価できるルールが1つのみであることを確認してください。特定の条件について複数のルールがTRUEと評価された場合も、返されるルールは1つのみであるため、予測できない結果が発生する可能性があります。
たとえば、hr.employees表に対するDML変更がLCRに含まれている場合に2つのルールがTRUEと評価されるとします。最初のルールにはNULLのアクション・コンテキストがあります。2つ目のルールには、カスタム・ルールベースの変換を指定するアクション・コンテキストがあります。hr.employees表に対するDML変更が存在する場合、両方のルールが変更についてTRUEと評価されますが、返されるルールは1つのみです。この場合、どちらのルールが返されるかに応じて、変換が行われる場合と行われない場合があります。
いずれかのルールにNULL以外のアクション・コンテキストがあるかどうかに関係なく、TRUEと評価できるルールがどの条件についてもポジティブ・ルール・セット内で1つのみになるようにする必要があります。このガイドラインに従うと、NULL以外のアクション・コンテキストが将来ルールに追加された場合などでも、予測できない結果を回避できます。
スキーマ・ルールまたはグローバル・ルールに、カスタム・ルールベースの変換、エンキューの宛先、または実行ディレクティブのアクション・コンテキストを使用すると、そのアクション・コンテキストで指定されたアクションは、メッセージによってスキーマ・ルールまたはグローバル・ルールがTRUEと評価された場合に、メッセージに対して実行されます。たとえば、スキーマ・ルールにカスタム・ルールベースの変換を指定するアクション・コンテキストがある場合、スキーマ内の表のLCRに対して変換が実行されます。
スキーマ・ルールまたはグローバル・ルールにアクション・コンテキストを使用するが、アクション・コンテキストによって実行されるアクションからLCRのサブセットを除外する場合があります。たとえば、hrスキーマ内のjob_history表を除くすべての表に対してカスタム・ルールベースの変換を実行する場合は、表がjob_historyである場合に変換ファンクションによって元のLCRが返されるようにします。
hrスキーマ内のjob_history表を除くすべての表に対してエンキューの宛先または実行ディレクティブを設定する場合は、スキーマ・ルールを使用して、次の条件を追加できます。
:dml.get_object_name() != 'JOB_HISTORY'
この場合、job_history表のLCRがTRUEと評価されても、エンキューまたは実行ディレクティブが実行されないようにするために、この表の表ルールをポジティブ・ルール・セットに追加できます。つまり、スキーマ・ルールにはエンキューの宛先または実行ディレクティブが含まれますが、表ルールにはそれらが含まれません。
DBMS_STREAMS_ADMパッケージでは、システム作成のルールおよびルール・セットが生成されます。また、Oracleが提供する評価コンテキストがルールおよびルール・セットに対して指定されるか、システム作成評価コンテキストが生成されます。DBMS_STREAMS_ADMパッケージを使用して作成できないルール、ルール・セットまたは評価コンテキストを作成する必要がある場合は、DBMS_RULE_ADMパッケージを使用してそれらを作成できます。
次のような場合に、DBMS_RULE_ADMパッケージを使用します。
特定タイプの操作のルール条件や、LIKE条件を使用するルール条件など、DBMS_STREAMS_ADMパッケージでは作成できないルール条件のあるルールを作成する必要がある場合。
Oracle Streams環境でルールのカスタム評価コンテキストを作成する必要がある場合。
DBMS_RULE_ADMパッケージを使用してルール・セットを作成し、それを取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントに関連付けることができます。このようなルール・セットは、Oracle Streamsクライアントのポジティブ・ルール・セットまたはネガティブ・ルール・セットとして使用でき、1つのルール・セットを1つのOracle Streamsクライアントのポジティブ・ルール・セットおよび別のOracle Streamsクライアントのネガティブ・ルール・セットとして使用することもできます。
この項の内容は次のとおりです。
次の各項では、DBMS_RULE_ADMパッケージを使用して作成できる一部のタイプのルールおよびルール・セットについて説明します。
|
注意: DBMS_STREAMS_ADMパッケージの一部のプロシージャで使用可能なand_conditionパラメータを使用して、ユーザー定義条件をシステム作成ルールに追加できます。and_conditionパラメータを使用する方が、DBMS_RULE_ADMパッケージでルールを作成するよりも簡単な場合があります。 |
特定タイプの操作を含む変更のみの取得、伝播、適用またはデキューが必要になることがあります。たとえば、特定の表に対する挿入操作のみが含まれ、更新や削除などの他の操作が含まれない変更の適用が必要な場合があります。
hr.employees表に対するINSERT操作についてのみTRUEと評価されるルール条件を指定する場合を考えます。そのためには、ルール条件でINSERTコマンド・タイプを指定します。
:dml.get_command_type() = 'INSERT' AND :dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'EMPLOYEES' AND :dml.is_null_tag() = 'Y'
同様に、DELETE操作を除き、hr.departments表に対するすべてのDML操作についてTRUEと評価されるルール条件を指定する場合を考えます。そのためには、次のルール条件を指定します。
:dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'DEPARTMENTS' AND :dml.is_null_tag() = 'Y' AND (:dml.get_command_type() = 'INSERT' OR :dml.get_command_type() = 'UPDATE')
このルール条件は、DELETE操作を除き、hr.departments表に対するINSERTおよびUPDATE操作についてはTRUEと評価されます。hr.departments表にはLOB列が含まれていないため、DML操作のLOBコマンド・タイプ(LOB ERASE、LOB WRITEおよびLOB TRIM)を指定する必要はありませんが、1つ以上のLOB列を含む表のルール条件ではこれらのコマンド・タイプを指定する必要があります。
次のルール条件では、hr.departments表に対して同じ動作が実行されます。つまり、次のルール条件では、DELETE操作を除き、hr.departments表に対するすべてのDML操作についてTRUEと評価されます。
:dml.get_object_owner() = 'HR' AND :dml.get_object_name() = 'DEPARTMENTS' AND :dml.is_null_tag() = 'Y' AND :dml.get_command_type() != 'DELETE'
この項で前述した例のルール条件は、すべて単純ルール条件です。ただし、システム作成ルール条件にカスタム条件を追加すると、条件全体が単純ルール条件でなくなる可能性があり、単純ルールでないルールは効率的に評価されないことがあります。通常は、ルール評価のパフォーマンスを改善するために、可能なかぎり単純ルール条件を使用する必要があります。DBMS_STREAMS_ADMパッケージを使用して作成され、カスタム条件が追加されていないルール条件は常に単純です。
ルール条件で次のファンクションを使用して、サポートされていない変更をカプセル化するLCRを廃棄するようにOracle Streamsクライアントに指示できます。
LCR用のGET_COMPATIBLEメンバー・ファンクション。このファンクションでは、LCRのサポートに必要なデータベースの最小互換レベルが返されます。
DBMS_STREAMSパッケージのCOMPATIBLE_9_2ファンクション、COMPATIBLE_10_1ファンクション、COMPATIBLE_10_2ファンクション、COMPATIBLE_11_1ファンクション、COMPATIBLE_11_2ファンクションおよびMAX_COMPATIBLEファンクション。これらのファンクションでは、それぞれデータベースの9.2.0、10.1.0、10.2.0、11.1.0、11.2.0および最大互換性に対応する定数の値が返されます。Oracle Databaseの互換性は、COMPATIBLE初期化パラメータを使用して制御します。
たとえば、次のルールを考えてみます。
BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.dml_compat_9_2',
condition => ':dml.GET_COMPATIBLE() > DBMS_STREAMS.COMPATIBLE_9_2()');
END;
/
このルールが取得プロセス、伝播、適用プロセスなどのOracle Streamsクライアントのネガティブ・ルール・セットに含まれる場合は、Oracle9i Database リリース2(9.2)と互換性のない行LCRがOracle Streamsによって廃棄されます。
ポジティブ・ルール・セットの場合のより適切な例を次に示します。
BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.dml_compat_9_2',
condition => ':dml.GET_COMPATIBLE() <= DBMS_STREAMS.COMPATIBLE_10_1()');
END;
/
このルールがOracle Streamsクライアントのポジティブ・ルール・セットに含まれる場合、Oracle Database 10g リリース1以下と互換性のない行LCRがOracle Streamsクライアントによって廃棄されます。つまり、Oracle9i Database リリース2(9.2)またはOracle Database 10g リリース1(10.1)と互換性があり、ルール・セットのその他のルールを満たす行LCRはOracle Streamsクライアントによって処理されますが、これらのリリースと互換性のない行LCRは廃棄されます。
次のルールをポジティブ・ルール・セットに追加すると、現在のリリースのOracle DatabaseのOracle Streamsでサポートされていない行LCRを廃棄できます。
BEGIN
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.dml_compat_max',
condition => ':dml.GET_COMPATIBLE() < DBMS_STREAMS.MAX_COMPATIBLE()');
END;
/
MAX_COMPATIBLEファンクションでは、常に、最大互換性が返されます。最大互換性はDBMS_STREAMSパッケージによって返される互換性定数よりも大きい値になります。したがって、このファンクションをルール条件で使用すると、以降のリリースのOracle Databaseにアップグレードする場合にルール条件を変更する必要がありません。以降のリリースで新しくサポートされている変更は自動的に取得され、新たにサポートされる変更を含むLCRは廃棄されません。
前述の例のルールは効率的に評価されます。DBMS_STREAMS_ADMパッケージによって作成されたスキーマ・ルールまたはグローバル・ルールを使用してLCRを取得、伝播、適用またはデキューする場合は、これらのルールを使用して、特定のデータベースでサポートされていないLCRを廃棄できます。
|
注意:
|
|
関連項目:
|
複合ルール条件とは、「単純ルール条件」で説明した単純ルール条件の要件を満たしていないルール条件です。Oracle Streams環境では、DBMS_STREAMS_ADMパッケージによって作成されるルールには単純ルール条件のみが含まれ、システム作成ルールにはカスタム条件が追加されていないことが想定されます。
DBMS_STREAMS_ADMパッケージで作成できる各タイプのシステム作成ルール条件については、表5-3を参照してください。複合条件のあるルールを作成する必要がある場合は、DBMS_RULE_ADMパッケージを使用できます。
様々な複合ルール条件があります。次の各項では、複合ルール条件の例をいくつか示します。
|
注意:
|
NOT論理条件を使用すると、Oracle Streams環境で特定の変更を取得、伝播、適用またはデキューから除外できます。
たとえば、hr.regions表の変更を除き、hrスキーマ内のすべてのデータベース・オブジェクトに対するすべてのDML変更およびDDL変更についてTRUEと評価されるルール条件を指定する必要があるとします。NOT論理条件を使用すると、DML変更用に1つとDDL変更用に1つ、合計2つのルールを使用して、このルール条件を指定できます。これらのルールのルール条件を次に示します。
(:dml.get_object_owner() = 'HR' AND NOT :dml.get_object_name() = 'REGIONS') AND :dml.is_null_tag() = 'Y' ((:ddl.get_object_owner() = 'HR' OR :ddl.get_base_ table_owner() = 'HR') AND NOT :ddl.get_object_name() = 'REGIONS') AND :ddl.is_ null_tag() = 'Y'
この例ではHRやREGIONSなどのオブジェクト名がすべて大文字で指定されていることに注意してください。ルールが正しく評価されるには、表やユーザーなどのオブジェクト名での大/小文字の表記が、データ・ディクショナリでの大/小文字の表記と一致する必要があります。したがって、オブジェクトの作成時に大/小文字の表記が指定されなかった場合、ルール条件ではオブジェクト名をすべて大文字で指定します。ただし、オブジェクトの作成時に二重引用符を使用して特定の大/小文字の表記を指定した場合は、ルール条件でも同じように大/小文字の表記を指定します。ただし、ルール条件ではオブジェクト名を二重引用符で囲むことはできません。
たとえば、HRスキーマ内のREGIONS表が実際には"Regions"という名前で作成された場合、この表に関連するルール条件では、次の例のようにRegionsを指定します。
:dml.get_object_name() = 'Regions'
DBMS_RULE_ADMパッケージを使用してこれらのルールを作成する場合は、Oracle Streams評価コンテキストを使用できます。次の例では、複合ルールを保持するルール・セットを作成し、前述の条件を伴うルールを作成して、それらのルールをルール・セットに追加します。
BEGIN
-- Create the rule set
DBMS_RULE_ADM.CREATE_RULE_SET(
rule_set_name => 'strmadmin.complex_rules',
evaluation_context => 'SYS.STREAMS$_EVALUATION_CONTEXT');
-- Create the complex rules
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.hr_not_regions_dml',
condition => ' (:dml.get_object_owner() = ''HR'' AND NOT ' ||
' :dml.get_object_name() = ''REGIONS'') AND ' ||
' :dml.is_null_tag() = ''Y'' ');
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'strmadmin.hr_not_regions_ddl',
condition => ' ((:ddl.get_object_owner() = ''HR'' OR ' ||
' :ddl.get_base_table_owner() = ''HR'') AND NOT ' ||
' :ddl.get_object_name() = ''REGIONS'') AND ' ||
' :ddl.is_null_tag() = ''Y'' ');
-- Add the rules to the rule set
DBMS_RULE_ADM.ADD_RULE(
rule_name => 'strmadmin.hr_not_regions_dml',
rule_set_name => 'strmadmin.complex_rules');
DBMS_RULE_ADM.ADD_RULE(
rule_name => 'strmadmin.hr_not_regions_ddl',
rule_set_name => 'strmadmin.complex_rules');
END;
/
この場合、ルールはルール・セットからOracle Streams評価コンテキストを継承します。
|
注意: ほとんどの場合、DBMS_STREAMS_ADMパッケージを使用してOracle Streamsクライアントのネガティブ・ルール・セットにルールを追加すれば、NOT論理条件を持つ複合ルールを使用する必要はありません。 |
LIKE条件を使用すると、ルールの条件が指定されたパターンと一致する場合にTRUEと評価される複合ルールを作成できます。たとえば、JOBというパターンで始まるhrスキーマ内のすべてのデータベース・オブジェクトに対するすべてのDML変更およびDDL変更についてTRUEと評価されるルール条件を指定する必要があるとします。DML変更用に1つとDDL変更用に1つ、合計2つのルール条件を指定して、LIKE条件を使用できます。これらのルールのルール条件を次に示します。
(:dml.get_object_owner() = 'HR' AND :dml.get_object_name() LIKE 'JOB%') AND :dml.is_null_tag() = 'Y' ((:ddl.get_object_owner() = 'HR' OR :ddl.get_base_table_owner() = 'HR') AND :ddl.get_object_name() LIKE 'JOB%') AND :ddl.is_null_tag() = 'Y'
評価中に、変数に対する変数値のファンクションからNULLが返される場合、ルール条件内の暗黙的変数は未定義となります。DBMS_RULE.EVALUATEプロシージャの実行時に変数の値がクライアントからルール・エンジンに送信されないと、ルール条件内に属性を持たない明示的変数は未定義となります。
属性を持つ変数に関しては、DBMS_RULE.EVALUATEプロシージャの実行時にクライアントからルール・エンジンへ、変数またはそのいずれかの属性の値が送信されないと、変数は未定義となります。たとえば、変数xが属性aとbを持つ場合、クライアントからxの値が送信されず、aの値もbの値も送信されないと、この変数は未定義となります。ただし、1つ以上の属性の値がクライアントから送信されると、この変数は定義されます。この場合では、クライアントからaの値が送信され、bの値が送信されなくても、この変数は定義されます。
ルール条件内の未定義の変数は、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントを含む、ルール・エンジンのOracle Streamsクライアントに対して NULLと評価されます。これに対し、ルール・エンジンのOracle Streams以外のクライアントに対しては、ルール条件内の未定義の変数が原因で、ルール・エンジンからクライアントにmaybe_rulesが返されることがあります。ルール・セットの評価時に、さらに情報を提供するとTRUEと評価される可能性があるルールがmaybe_rulesです。
未定義の各変数をNULLとして処理すると、Oracle Streamsクライアントに返されるmaybe_rulesの数が削減されます。maybe_rulesの数が削減され、その結果、メッセージの発生時にルール・セットがより効率的に評価されれば、パフォーマンスが改善される可能性があります。Oracle Streams以外のクライアントにmaybe_rulesを返すルールは、次の各例に示すように、Oracle Streamsクライアントに対してはTRUEまたはFALSEのルールとなる可能性があります。
次のユーザー定義ルール条件を考えてみます。
:m IS NULL
評価中に変数mの値が定義されない場合、ルール・エンジンのOracle Streams以外のクライアントにmaybeルールが発生します。ただし、Oracle Streamsクライアントについては、未定義変数mがNULLとして処理されるため、この条件はTRUEと評価されます。このようなルールはすべてのメッセージに対してTRUEと評価されるため、Oracle Streamsクライアントのルール・セットには追加しないでください。そのため、たとえば、取得プロセスのポジティブ・ルール・セットにこのようなルールが含まれる場合、取得の対象外とされているメッセージが取得プロセスによって取得される場合があります。
次に、Oracle Streamsの:dml変数を使用する別のユーザー指定ルール条件を示します。
:dml.get_object_owner() = 'HR' AND :m IS NULL
Oracle Streamsクライアントでは、メッセージがhrスキーマ内の表に対する行変更で構成されていて、評価時に変数mの値が不明な場合、未定義変数mがNULLとして処理されるため、この条件はTRUEと評価されます。
次のユーザー定義ルール条件を考えてみます。
:m = 5
評価中に変数mの値が定義されない場合、ルール・エンジンのOracle Streams以外のクライアントにmaybeルールが発生します。ただし、Oracle Streamsクライアントについては、未定義変数mがNULLとして処理されるため、この条件はFALSEと評価されます。
Oracle Streamsの:dml変数を使用する別のユーザー指定ルール条件を考えてみます。
:dml.get_object_owner() = 'HR' AND :m = 5
Oracle Streamsクライアントでは、メッセージがhrスキーマ内の表に対する行変更で構成されていて、評価時に変数mの値が不明な場合、未定義変数mがNULLとして処理されるため、この条件はFALSEと評価されます。
ルール条件のファンクション・パラメータとして、:dmlおよび:ddl変数を使用しないことをお薦めします。次の例では、:dml変数がmy_functionというファンクションのパラメータとして使用されています。
my_function(:dml) = 'Y'
このようなルール条件を指定すると、ルール評価のパフォーマンスが低下したり、誤ったOracle Streamsデータ・ディクショナリ情報が取得または伝播される結果となる可能性があります。
Oracle Streams環境では、カスタム評価コンテキストを使用できます。LCRに関連するユーザー定義評価コンテキストには、SYS.STREAMS$_EVALUATION_CONTEXT内のすべての変数を含める必要があります。各変数のタイプとその変数値ファンクションは、SYS.STREAMS$_EVALUATION_CONTEXTで変数ごとに定義されているタイプおよびファンクションと同じである必要があります。また、DBMS_RULE_ADM.CREATE_EVALUATION_CONTEXTを使用して評価コンテキストを作成する場合は、evaluation_functionパラメータに対してSYS.DBMS_STREAMS_INTERNAL.EVALUATION_CONTEXT_FUNCTIONを指定する必要があります。DBMS_RULE_ADM.ALTER_EVALUATION_CONTEXTプロシージャを使用すると、既存の評価コンテキストを変更できます。
評価コンテキストに関する情報は、次のデータ・ディクショナリ・ビューで参照できます。
ALL_EVALUATION_CONTEXT_TABLES
ALL_EVALUATION_CONTEXT_VARS
ALL_EVALUATION_CONTEXTS
必要に応じて、これらのデータ・ディクショナリ・ビューの情報を使用し、SYS.STREAMS$_EVALUATION_CONTEXTに基づいて新しい評価コンテキストを作成できます。
|
注意: Oracleが提供する評価コンテキストの変数との競合を回避するために、$や#などの特殊文字を含む変数名は使用しないでください。 |
|
関連項目: これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照 |
