ヘッダーをスキップ
Oracle Databaseルール・マネージャおよび式フィルタ開発者ガイド
11gリリース1（11.1）
E05697-01
  目次
目次		 索引
索引
戻る
戻る		 次へ
次へ		  

2 ルール・マネージャの概要

Oracle Databaseの1機能であるルール・マネージャは、式フィルタとオブジェクト・リレーショナルの機能を使用して特殊な目的のルール・エンジンの機能を提供しますが、その機能は以前より優れたスケーラビリティと操作特性を備えています。

2.1 ルールの用語

ルール・マネージャでは、次の用語が使用されます。

2.2 ルール・クラスとルールのデータベース表現

ルール・マネージャは、リレーショナル表を使用してルール・クラスのコンテンツを格納し、表内の各行で1つのルールを表します。ルール・クラス表には、ルール識別子（rlm$ruleid）、ルール条件（rlm$rulecond）、ルールの説明（rlm$ruledesc）の最低3つの列があります。この他に、ルール・アクション・プリファレンスを格納する列が1つ以上あります。

図2-1に、AddFlightイベント・インスタンスを処理するためのTravelPromotionルール・クラスとそのルールのデータベース表現を示します。

図2-1 ルール・クラスとルールのデータベース表現

図2-1の説明は次にあります
「図2-1 ルール・クラスとルールのデータベース表現」の説明

TravelPromotionルール・クラスは次の列で構成されます。

ECAルールは、TravelPromotionルール・クラス表の1つの行に格納されます。データベースにオブジェクト型として定義されるイベント構造は、ルール条件列に関連付けられ、これによって、ルール条件（列に格納されている）に必要なボキャブラリが提供されます。イベント構造、ルール・クラス表およびアクション・コールバック・プロシージャはすべて、ルール・クラス作成の一部として作成されます。

すべてのルールがルール・クラスに追加されると、イベントを処理し、ルールを評価できる状態になります。実行時に、ルール・クラス内の各ルールは、イベント構造の各インスタンスと照合して処理されます。特定のイベントに対してルールがTRUEに評価されると、PromoActionアクション・コールバック・プロシージャは、ルール・アクション・プリファレンスを使用して指定のOfferPromotionプロシージャをコールし、特定ベンダーから特定の販促タイプを提供する規定のアクションを実行します。ルール・マネージャは、イベントが複数のルールと一致した場合の競合解消や、初回の一致検出のみでそれ以降の評価が不要な場合の即時イベント使用など、様々なイベント管理ポリシーを実行します。このようなイベント管理ポリシーについては、第3章で詳しく説明します。

第2.3項、第2.6項および第2.4項では、単純イベントを使用するルール・アプリケーション、複数層にまたがるルール・アプリケーション、およびコンポジット・イベントを使用するルール・アプリケーションの作成処理についてそれぞれ説明します。基本的な5つの手順は3つの例すべてについて同じですが、詳細は異なり、複数層アプリケーションの場合はいくつかの追加手順が必要です。

2.3 単純（非コンポジット）イベントを使用するルール・アプリケーションの作成

単純（非コンポジット）イベントを使用するルール・アプリケーションを作成する基本手順は、次のとおりです。

  1. データベースにオブジェクト型としてイベント構造を作成します。

    AddFlightの例を使用すると、イベント構造は次のように定義されます。

    CREATE TYPE AddFlight AS OBJECT (
    CustId       NUMBER,
    Airline      VARCHAR2(20),
    FromCity     VARCHAR2(30),
    ToCity       VARCHAR2(30),
    Depart       DATE,
    Return       DATE);

  2. イベント構造に対してルール・クラスを作成します。


    注意:

    ルール・クラスを正常に作成するには、ビュー、オブジェクト型、表、パッケージおよびプロシージャの作成権限が必要です。

    この例の場合は、AddFlightイベント構造に対してTravelPromotionルール・クラスを作成し、そのアクション・プリファレンスとしてPromoType列とOfferedBy列を定義します。このプロシージャは、引数として、ルール・クラスの名前、手順1で作成した既存のイベント構造の名前、アクション・コールバック・プロシージャの名前およびアクション・プリファレンス仕様を使用します。アクション・プリファレンス仕様では、ルール・クラス内の各ルールに関連付けられているアクション・プリファレンスのデータ型が定義されます。

    BEGIN
dbms_rlmgr.create_rule_class (
     rule_class   => 'TravelPromotion',
     event_struct => 'AddFlight',
     action_cbk   => 'PromoAction',
     actprf_spec  => 'PromoType  VARCHAR2(20),
                      OfferedBy  VARCHAR2(20)');
END;

    ルール・クラスの作成では、対応するルール定義とアクション・プリファレンスを格納する表が作成されます。このルール・クラス表は、ルール・クラスと同じ名前を使用して、ユーザーのスキーマに作成されます。ルール・クラス表には、ルール識別子、ルール説明およびルール条件を格納する3つの列が定義されます。この例では、アクション・プリファレンスを格納するために前述のコマンドで指定された、ルール・アクション・プリファレンス列も作成されます。

    TABLE TravelPromotion (
                 rlm$ruleid     VARCHAR2(100),
                 rlm$rulecond   VARCHAR2(4000),
                 rlm$enabled    CHAR(1) DEFAULT 'Y',
                 rlm$ruledesc   VARCHAR2(1000),
                 PromoType      VARCHAR2(20),
                 OfferedBy      VARCHAR2(20));

    ユーザーは、この表を問い合せてルール・クラスに定義されているルールを参照でき、さらに、SQLのINSERT、UPDATEおよびDELETE操作を実行して、ルールを追加、更新および削除できます。

    ルール・クラスの作成では、アクションを実行するコールバック・プロシージャ用のスケルトンが暗黙的に作成されます。アクション・コールバック・プロシージャは、ルール・クラス内のすべてのルールに対してアクションを実行するためのエントリ・ポイントとして機能します。アクション・コールバックは、各ルールがイベントと一致するたびに1回コールされます。アクション・コールバック・プロシージャの実装は、一致ルールに関連付けられているイベント・インスタンスとアクション・プリファレンスの値に依存する場合があります。

    PROCEDURE  PromoAction (rlm$event      AddFlight,
                        rlm$rule       TravelPromotion%ROWTYPE) is
BEGIN
  null;
  --- The action for the matching rules can be performed here.
  --- The appropriate action can be determined from the event
  --- instance and the action preferences associated with each rule.
END;

    この例では、アクション・コールバック・プロシージャは、ユーザーが指定した名前で作成され、引数は2つあります。

    • 対応するオブジェクト型のインスタンスとしてのイベント。

    • 対応するルール・クラス表のROWTYPEとしてのアクション・プリファレンス。%ROWTYPE属性によって、表内の行を表すレコード型が提供されます。

  3. 各一致ルールに対して適切なアクションを実行するために、システム生成コールバック・プロシージャをユーザー実装で置き換えます。次のアクション・コールバック・プロシージャを実装すると、イベント・インスタンスおよびルール定義から取得した引数でOfferPromotionプロシージャを起動できます。

    例:

    PROCEDURE  PromoAction (
            rlm$event      AddFlight,
            rlm$rule       TravelPromotion%ROWTYPE) is
BEGIN
   OfferPromotion (rlm$event.CustId,
                   rlm$rule.PromoType,
                   rlm$rule.OfferedBy);
END;

    この例では、プロシージャOfferPromotionによってアクションが実行され、一致ルールによって適切なアクション・プリファレンスが提供されます。付録Gには、様々なアクション・プリファレンスの選択に対してアクション・コールバック・プロシージャを実装する別の方法が示されています。

  4. ルール・クラスにルールを追加します。

    ルールの追加では、SQL INSERT文を使用して各ルールに対する行を追加します。挿入される各行には通常、アクション・プリファレンスのルール識別子、条件および値が格納されます。TravelPromotion表に、次のルールが挿入されます。

    INSERT INTO TravelPromotion (rlm$ruleid, PromoType, OfferedBy, rlm$rulecond) VALUES
('UN_AV_FL', 'Rental Car', 'Acar',
'Airline= ''Abcair'' and ToCity = ''Orlando'' and Return-Depart >= 7');

  5. イベントに対するルールを処理します。

    dbms_rlmgr.process_rules( )プロシージャを使用して、イベント・インスタンスに対するルール・クラス内のルールを処理します。ルールの処理では、イベント・インスタンスが、名前/値ペア（getVarchar( )プロシージャを使用して生成される）の文字列として渡されるか、第11.3項の説明のようなバイナリ・データ型で構成されるイベントの場合は、AnyDataインスタンスとして渡されます。可能な場合は、データ項目を文字列形式の名前/値ペアとして表すためにオラクル社が提供するgetVarchar( )メソッドが使用されること、およびオラクル社が提供するオブジェクト型AnyDataによって、オラクル社が提供するデータ型とユーザー定義のデータ型の両方のOracleデータ型のインスタンスを格納できることに注意してください。

    次の例では、getVarchar( )関数を使用して、AddFlightイベント・インスタンスに対するTravelPromotionルール・クラス内のルールが処理されます。

    BEGIN
dbms_rlmgr.process_rules (
   rule_class  => 'TravelPromotion',
   event_inst  => AddFlight.getVarchar(987, 'Abcair', 'Boston', 'Orlando', '01-APR-2003', '08-APR-2003'));
END;

    次の例では、AnyData.ConvertObject( )プロシージャを使用して、AddFlightイベント・インスタンスに対するTravelPromotionルール・クラス内のルールが処理されます。

    BEGIN
dbms_rlmgr.process_rules (
   rule_class  => 'TravelPromotion',
   event_inst  => AnyData.convertObject(AddFlight(987, 'Abcair', 'Boston', 'Orlando', '01-APR-2003', '08-APR-2003')));
END;

    前述のコマンドでは、AddFlightイベント・インスタンスに対するTravelPromotionルール・クラス内のルールが処理され、アクション・コールバック・プロシージャを使用して、各一致ルールに関連付けられているアクションが実行されます。

2.4 コンポジット・イベントを使用するルール・アプリケーションの作成

多くの場合、一般的なタイプのルール・アプリケーションでは、2つ以上のプリミティブ・イベントを結合したコンポジット・イベント構造が使用されます。コンポジット・イベントに対するルール・クラスの評価には、追加要件があります。ルール・マネージャでは、これらの要件が次のように処理されます。

コンポジット・イベントを使用したルール・アプリケーションの設計

コンポジット・イベントに対するルール・アプリケーションの開発では、データベース（SQL）アプリケーションの開発と類似する部分があります。ルール・アプリケーションでのイベント構造の定義は、データベース・アプリケーションの表定義と同じです。これらの表で稼働しているSQL問合せは、ルール・クラスで定義されたルール条件と同じです。データベース・アプリケーションでは、各アプリケーションに固有の制約および索引は、データの整合性およびパフォーマンスに対して作成されます。同様に、ルール・アプリケーションの場合、ルール・クラスにプロパティが指定されると、イベント管理ポリシーが実行され、パフォーマンスが改善します。これらのルール・クラス・プロパティについては、第2.5項で要約し、第3章で説明します。

2.4.1 コンポジット・イベントを使用するルール・アプリケーションの作成方法

コンポジット・イベントを使用するルール・アプリケーションを作成する基本手順は、第2.3項で説明した単純イベントに対する手順と同じですが、複数プリミティブ・イベントに対する調整が必要です。

コンポジット・イベントを使用するルール・アプリケーションを作成する手順は、次のとおりです。

  1. データベースにオブジェクト型としてコンポジット・イベント構造を作成します。

    最初に、各プリミティブ・イベント構造がオブジェクト型として作成されます。次に例を示します。

    CREATE or REPLACE TYPE AddFlight AS OBJECT (
    CustId       NUMBER,
    Airline      VARCHAR2(20),
    FromCity     VARCHAR2(30),
    ToCity       VARCHAR2(30),
    Depart       DATE,
    Return       DATE);

CREATE or REPLACE TYPE AddRentalCar AS OBJECT  (
    CustId       NUMBER,
    CarType      VARCHAR2(20),
    CheckOut     DATE,
    CheckIn      DATE,
    Options      VARCHAR2(30));

    次に、コンポジット・イベントを構成するすべてのプリミティブ・イベント構造が、次のオブジェクト型の（第1レベルの）埋込み型として作成されます。次に例を示します。

    CREATE or REPLACE TYPE TSCompEvent AS OBJECT (Flt AddFlight,
                                              Car AddRentalCar);

    属性名FltおよびCarは、個々のプリミティブ・イベントで述語を識別し、プリミティブ・イベント間の結合条件を指定するためのルール条件で使用されます。FltおよびCarは、コンポジット・イベントに使用されるプリミティブ・イベント変数です。

  2. コンポジット・イベント構造に対してルール・クラスを作成します。ルール・クラスは、dbms_rlmgr.create_rule_classプロシージャのプロパティ引数に割り当てられているXMLプロパティ文書を使用して、コンポジット・イベントに対して構成されます。

    BEGIN
   dbms_rlmgr.create_rule_class (
               rule_class    => 'CompTravelPromo',
               event_struct  => 'TSCompEvent',
               action_cbk    => 'CompPromoAction',
               rslt_viewnm   => 'CompMatchingPromos',
               actprf_spec   => 'PromoType  VARCHAR2(20),
                                 OfferedBy  VARCHAR2(20)',
               rlcls_prop    => '<composite equal="Flt.CustId, Car.CustId"/>');
END;

    このコード例では、コンポジット・イベント構造に対してルール・クラスが作成されます。rlcls_prop引数は、XML要素<composite>を指定して、コンポジット・イベントに対するルール・クラスを構成します。プロパティにはequal指定も含まれ、ルール・クラスにあるすべてのルールに共通する等価性結合述語が識別されます。使用率、継続時間およびイベントの順序など、その他の重要なルール・クラス・プロパティは、第3.1項〜第3.7項で説明する構文を使用して指定できます。

    この手順では、プリミティブ・イベント構造を表す各オブジェクト型が再作成され、対応するイベント作成時間を取得するタイムスタンプ属性rlm$CrtTimeが組み込まれます。この属性はTIMESTAMPデータ型で作成され、その値は、イベントのインスタンス化のときにデータベース・タイムスタンプ（SYSTIMESTAMP）にデフォルト設定されます。または、この属性に有効なタイムスタンプ値を割り当てることによって、アプリケーションでイベント作成時間を明示的に設定することもできます。

    すでに説明したように、このルール・クラスの作成では、指定した名前で次のようなアクション・コールバック・プロシージャも作成されます。

    PROCEDURE CompPromotion (Flt       AddFlight,
                         Car       AddRentalCar,
                         rlm$rule  CompTravelPromo%ROWTYPE)  is
BEGIN
   null;
  --- The action for the matching rules can be performed here.
  --- The appropriate action can be determined from the event
  --- instance and the action preferences associated with each rule.
END;

    注意:

    コンポジット・イベント内のプリミティブ・イベントは、別々の引数としてコールバック・プロシージャに渡されます。ルール・クラスがRULE使用率ポリシーに対して構成されている場合、または1つ以上のコレクション・イベントに対して使用可能な場合、アクション・コールバック・プロシージャには引数が追加されます。

  3. 各一致ルールに対して適切なアクションを実行するために、システム生成アクション・コールバック・プロシージャをユーザー実装で置き換えます。次に例を示します。

    PROCEDURE  CompPromoAction (Flt       AddFlight,
                            Car       AddRentalCar,
                            rlm$rule  CompTravelPromo%ROWTYPE) is
BEGIN
   OfferPromotion (Flt.CustId,
                   rlm$rule.PromoType,
                   rlm$rule.OfferedBy);
END;

  4. ルール・クラスにルールを追加します。この例では、XMLタグを使用する条件式を備えたルールを追加します。ルール条件でXMLタグ拡張を使用して複雑なルール構成メンバーをサポートする方法の詳細は、第5.1項を参照してください。

    INSERT INTO CompTravelPromo (rlm$ruleid, PromoType, OfferedBy, rlm$rulecond)
  VALUES ('UN-HT-FL', 'RentalCar', 'Acar',
          '<condition>
             <and join="Flt.CustId = Car.CustId">
                <object name="Flt">
                    Airline=''Abcair'' and ToCity=''Orlando''
                </object>
                <object name="Car">
                    CarType = ''Luxury''
                </object>
             </and>
           </condition>');

  5. プリミティブ・イベントを一度に1つずつ使用してルールを処理します。次に例を示します。

    BEGIN
   dbms_rlmgr.process_rules (
             rule_class     => 'CompTravelPromo',
             event_inst     =>
                AnyData.ConvertObject(
                              AddFlight(987, 'Abcair', 'Boston', 'Orlando',
                                        '01-APR-2003', '08-APR-2003')));


   dbms_rlmgr.process_rules (
             rule_class     => 'CompTravelPromo',
             event_inst     =>
                AnyData.ConvertObject(
                              AddFlight(567, 'Abdair', 'Boston', 'Miami',
                                        '03-APR-2003', '09-APR-2003')));

   dbms_rlmgr.process_rules (
             rule_class     => 'CompTravelPromo',
             event_inst     =>
                AnyData.ConvertObject(
                              AddRentalCar(987, 'Luxury', '03-APR-2003',
                                        '08-APR-2003', NULL)));
END;

このコマンドによって、ルール・マネージャに3つのプリミティブ・イベントが追加されます。手順4で定義したルールの場合は、最初のイベントがAddFlightイベントのプリミティブ・ルール条件と一致し、3番目のイベントがAddRentalCarイベントの条件と一致します。さらに、これらの2つのイベントは、ルール条件の結合述語を満たしています。このため、前述の例では、最初と最後のプリミティブ・イベントによって、手順4で指定したルール条件と一致するコンポジット・イベントが形成されます。これらのプリミティブ・イベント・インスタンスは、アクション実行のためにアクション・コールバック・プロシージャに渡されます。渡されるプリミティブ・イベントの型情報は、対応するAnyDataインスタンスに埋め込まれます。ただし、文字列形式のイベントが使用される場合、プリミティブ・イベントの型情報は、次のように明示的に渡す必要があります。

BEGIN
   dbms_rlmgr.process_rules (
             rule_class     => 'TravelPromotion',
             event_type     => 'AddFlight',
             event_inst     =>
                 AddFlight.getVarchar(987, 'Abcair', 'Boston', 'Orlando',
                                      '01-APR-2003', '08-APR-2003'));
END;

2.4.2 複雑なルール条件を使用するコンポジット・イベントの評価

複雑なルール条件を使用するコンポジット・イベント評価は、ルール・マネージャで次の機能を使用してサポートされます。

  • ルールの増分評価。プリミティブ・イベント間で結合述語を使用できます。

  • ルール条件での否定の使用。プロセス内の例外（つまり、ある事項が発生しなかった場合の処理）を提示します。

  • ルール条件での順序付けの使用。プリミティブ・イベントの作成時間をトラッキングし、イベント間の順序付けを実行または検出します。

  • ルール条件でのセット・セマンティクスの使用。同じタイプのプリミティブ・イベントのインスタンスをグループとして監視できます。

  • ルール条件でのAny n の使用。プリミティブ・イベントのサブセットの照合を可能にします。

さらに、コンポジット・イベントに関連するルールの増分評価をサポートします。複雑なルール条件をサポートするために、SQL WHERE句の条件式は、いくつかのXMLタグで拡張されています。これらのタグは、条件式の様々な部分を識別し、これらの式に特別なセマンティクスを追加します。複雑なルール条件の各タイプについては、第5章で詳しく説明します。ルールの増分評価の実装方法については、第5.1項で説明します。

2.5 ルール・アプリケーションに対するイベント管理ポリシー（ルール・クラス・プロパティ）の設定

ルール・クラス・プロパティでは、ルール・マネージャが各ルール・アプリケーションに対して実施するイベント管理ポリシーが定義されます。ルール・クラス・プロパティの内容は、次のとおりです。

ルール・クラス・プロパティは、dbms_rlmgr.create_rule_set( )プロシージャのrlcls_prop引数に割り当てられているXMLプロパティ文書を使用して、ルール・クラスの作成時に指定されます。コンポジット・イベントに対して構成されるルール・クラスの場合、これらのプロパティは、コンポジット・イベント・レベルで指定されます（すべてのプリミティブ・イベントに対して）。また、プロパティ文書では、1つ以上のプリミティブ・イベントに対して優先イベントを指定できます。これらの各ルール・プロパティの詳細、およびそれぞれの実装方法については、第3.1項〜第3.8項で説明します。

2.6 複数層にまたがるルール・アプリケーションの作成

複数層にまたがるルール・アプリケーションで、ルール管理はデータベースで処理されるが、ルールのアクション実行はアプリケーション・サーバーで処理される場合、イベントと一致するルールのアクションは、アクション・コールバック・プロシージャから起動できません。かわりに、結果ビューは、外部アクションの実行に使用できるイベントと一致ルールを使用して移入されます。結果ビューを問い合せると、イベントと一致するルールを判別でき、それに対応するアクションを実行できます。

アプリケーション・サーバーでアクション実行が発生する特定のルールを備えたルール・アプリケーションを処理するには、アクション・コールバック・プロシージャを構成する以外に、外部実行用のルール・クラスも構成する必要があります。この手順は第2.3項で説明した手順と類似していますが、変更点について次に簡単に説明します（各手順の詳細は、第6章を参照）。

  1. データベースにオブジェクト型としてイベント構造を作成します（第2.3項の手順1と同様）。

  2. ルール・クラスを作成し、結果ビューも定義します。詳細は、第6.1項の手順2を参照してください。

  3. アクション・コールバック・プロシージャを実装します（第2.3項の手順3と同様）。

  4. ルール・クラスにルールを追加します（第2.3項の手順4と同様）。

  5. イベントに対する一致ルールを識別します。各イベントをルール・クラスに一度に1つずつ追加するイベントの追加プロシージャ（dbms_rlmgr.add_event( )）を使用し、結果ビューを使用して後でアクセスされる特定のイベントに対する一致ルールを識別します。詳細は、第6.1項の手順5を参照してください。

  6. 結果ビューを問い合せて一致ルールを検索します。詳細は、第6.1項の手順6を参照してください。

  7. ルール実行で使用されるイベントを使用します。詳細は、第6.1項の手順7を参照してください。

複数層にまたがるルール・アプリケーションの作成方法の詳細は、第6.1項を参照してください。また、複数層モードでルール・アプリケーションを実行する方法の詳細は、第6.2項を参照してください。

2.7 ルール・マネージャと、SQL*LoaderおよびExport/Importユーティリティの併用

第2.7.1項では、SQL*Loaderを使用してルール・クラス表にデータをロードする方法について説明します。第2.7.2項では、ルール・アプリケーションのエクスポートおよびインポート方法について説明します。

2.7.1 SQL*Loader

SQL*Loaderを使用すると、データをASCIIファイルからルール・クラス表にバルク・ロードできます。ローダー操作では、ルール・クラス表のrlm$rulecond列に格納されているルール条件は、VARCHAR2列にロードされる文字列として扱われます。データファイルには、XMLおよびSQLベースのルール条件をVARCHAR2データに許可される任意の書式で格納でき、ルール・クラス表内のアクション・プリファレンス列の値は、通常のSQL*Loaderセマンティクスを使用してロードされます。

ルール条件列にロードされたデータは、ルール・クラスに関連付けられたイベント構造を使用して自動的に検証されます。この検証は、ルール条件列に定義されているトリガーによって実行されます。したがって、ルール・クラス表へのルール定義のロード時にはダイレクト・ロードを使用できません。

2.7.2 エクスポート/インポート

イベント構造とルール・クラスのセットを使用して定義されたルール・アプリケーションは、同じデータベースまたは異なるOracleデータベースに対してエクスポートしたり、インポートして戻すことができます。スキーマ内のルール・クラスは、対応するルール・クラス表がエクスポート・コマンド（expdp）のtablesパラメータを使用してエクスポートされるとき、またはスキーマ全体がエクスポートされるときに、自動的にエクスポートされます。ルール・クラスがエクスポートされると、関連付けられているプリミティブおよびコンポジット・イベント構造の定義、およびルール・クラス内に定義されているルールはすべて、エクスポート・ダンプ・ファイルに格納されます。ただし、部分一致済ルールに対するイベント・インスタンスと増分状態の情報を保持する内部データベース・オブジェクトは、ルール・クラスとともにエクスポートされません。特定のルール・クラスのエクスポートにtablesパラメータを使用すると、アクション・コールバック・プロシージャの実装は、エクスポート・ダンプ・ファイルに書き込まれません。アクション・コールバック・プロシージャは、スキーマ・エクスポートの場合にのみエクスポートされます。


注意:

ルール・クラスが共有可能なプリミティブ・ルール条件を参照している場合、条件を格納する条件表は、スキーマがエクスポートされるか、または条件表がエクスポート・コマンドのtablesパラメータに明示的にリストされないかぎり、エクスポートされません。詳細は、第4.6項の最後にある注意を参照してください。

ルール・クラスのエクスポートで作成されたダンプ・ファイルを使用すると、ルール・クラスとそのイベント構造を同じデータベースまたは異なるOracleデータベースにインポートできます。インポート時に、ルール・クラスの状態保持に使用する内部データベース・オブジェクトが再作成されます。特定のオブジェクトがインポート・セッションで作成およびスキップされる順序によって、ルール・クラスの作成でエラーや警告が発生しますが、これらは無視してかまいません。ルール・クラスのスキーマ・レベル・インポートの場合は、アクション・コールバック・プロシージャの実装もインポート・サイトで再作成されます。ただし、表レベル・インポートの場合は、アクション・コールバック・プロシージャのスケルトンのみが作成されます。


注意:

ルール・クラスが共有可能なプリミティブ・ルール条件を参照している場合、ルールはインポート時に検証され、条件表の欠落または条件表にある特定のプリミティブ条件の欠落が原因で破損した参照には、ORA-41704エラー・メッセージが戻されます。ただし、破損した参照はインポート後の操作として固定できます。そのために、参照が破損しているすべてのルール条件には、「F」を格納するrlm$enabled列にFAILEDマークがつきます。

  戻る
戻る		 次へ
次へ
  目次
目次		 索引
索引