ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。ルールのコンポーネントは、次のとおりです。
ルール評価コンテキスト(オプション)
ルール・アクション・コンテキスト(オプション)
各ルールは、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
句を作成するには、ルール条件内の式が評価コンテキスト内の表、表の別名および変数を参照する必要があります。
ルール評価コンテキストは、外部データを参照するルール条件の解析と評価に必要な情報を提供します。たとえば、ルールで変数を参照する場合、ルール評価コンテキスト内の情報には変数の型を含める必要があります。また、ルールで表の別名を参照する場合、評価コンテキストには表の別名を定義する情報を含める必要があります。
ルールによって参照されるオブジェクトは、そのルールに関連付けられたルール評価コンテキストによって決定されます。ルール所有者は、表に対するREAD
または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
ファンクション、COMPATIBLE_12_1
ファンクションおよびMAX_COMPATIBLE
ファンクション。これらのファンクションでは、それぞれデータベースの9.2.0、10.1.0、10.2.0、11.1.0、11.2.0、12.1.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 リリース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 リリース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リファレンス』を参照 |