| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
ルールとは、イベントの発生時に条件が満たされている場合に、クライアントでアクションを実行できるようにするデータベース・オブジェクトです。ルールのコンポーネントは、次のとおりです。
ルール評価コンテキスト（オプション）
ルール・アクション・コンテキスト（オプション）
各ルールは、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つの結果を生成します。または、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メンバー・プロシージャを使用して適切な名前/値ペアを追加する必要があります。
アクション・コンテキストには、次のデータ型の情報を含めることはできません。
CLOB
NCLOB
BLOB
LONG
LONG RAW
また、アクション・コンテキストには、これらのデータ型の属性を持つオブジェクト型、および型進化や型継承を使用するオブジェクト型を含めることはできません。
|
注意: 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を指定する必要があります。
