DBMS_JSON_DUALITY

112 DBMS_JSON_DUALITY

DBMS_JSON_DUALITYパッケージは、JSONリレーショナル二面性ビューの作成とアクセスを簡略化します。

このパッケージには、次の目的のサブプログラムが含まれています:

JSONコレクションのセットをJSONリレーショナル二面性ビューに移行または変換
二面性ビューでの複数操作非対話型トランザクションの実行

この章では、パッケージの「概要」、パッケージに関連付けられている「セキュリティ制限」の概要、およびパッケージ内で使用可能な「サブプログラム」の詳細を示します。

DBMS_JSON_DUALITYの概要

DBMS_JSON_DUALITYパッケージを使用すると、JSONドキュメントとリレーショナル・データベース間のシームレスな統合が可能になります。このパッケージには、JSONコレクションをJSONリレーショナル二面性ビューに変換し、データを二面性ビューにインポートし、二面性ビューでの複数操作トランザクションをサポートするサブプログラムが用意されています。

DBMS_JSON_DUALITYパッケージには、リレーショナル・スキーマの検索と作成、JSONドキュメントの二面性ビューへのインポート、およびインポートされた二面性ビューでの非対話型トランザクションの実行を可能にする一連のプロシージャおよびファンクションが含まれています。

JSON-To-Duality Migrator : 次に示す適切なJSON-To-Duality Migrator PL/SQLファンクションのいずれかを実行して、入力コレクション(JSON表)のリレーショナル・スキーマを検索して作成します。
- INFER_SCHEMA: すべての入力ドキュメント・セットを表すJSONスキーマを推測します。
- GENERATE_SCHEMA: 各二面性ビューに必要なデータベース・オブジェクトを作成するためのDDLコードを生成します。
- INFER_AND_GENERATE_SCHEMA: INFER_SCHEMAとGENERATE_SCHEMAの両方の操作を実行します。
JSON-to-Dualityインポータ:
この機能は、アプリケーション・データをJSONドキュメントのセットからJSON-To-Dualityコンバータ機能を使用して定義された二面性ビューにインポートするPL/SQLプロシージャIMPORTです。 JSON-To-Dualityコンバータで作成されたリレーショナル・スキーマに基づいて、入力データは自動的に分解され、リレーショナル表に正規化されます。正常にインポートできないデータは、エラー・ログに記録され、可能な場合はエラーの理由と問題を修正するための提案が示されます。

ノート:
インポータ機能は、JSONリレーショナル二面性コンバータ機能で推奨されるリレーショナル・スキーマに問題がない場合にのみ使用します。
非対話型トランザクション
この機能は、二面性ビューで複数操作トランザクションを実行できるPL/SQLプロシージャのセットです。 DBMS_JSON_DUALITYパッケージの非対話型プロシージャを次に示します:
- BEGIN_TRANSACTION: 複数操作トランザクションを開始します。
- REGISTER: 最後の読取りとしてドキュメントのETAG値が、トランザクションの開始時にデータベース内のドキュメントのETAG値と一致することを確認します。
- COMMIT_TRANSACTION: 複数操作トランザクションをコミットします。

DBMS_JSON_DUALITYセキュリティ

DBMS_JSON_DUALITYパッケージ内のすべてのサブプログラムは、実行者権限で実行されます。これを使用するには、サブプログラムで参照される表およびビューに対するSELECT権限が必要です。

特に、INFER_SCHEMA、GENERATE_SCHEMAおよびINFER_AND_GENERATE_SCHEMAサブプログラムで構成されるJSON-To-Dualityマイグレータには、次の制限があります:

SYSスキーマでは実行できません。
targetSchemaが現在のスキーマでない場合は、任意の表の選択権限が必要です。これがない場合、targetSchemaの表へのアクセスを試行中に二面性ビューの作成が失敗します。
例:
```
grant select any table to targetSchema;
```

DBMS_JSON_Dualityサブプログラムのサマリー

この表は、DBMS_JSON_DUALITYサブプログラムを示し、簡単に説明しています。

DBMS_JSON_DUALITYパッケージのサブプログラム

サブプログラム	説明
`INFER_SCHEMA`ファンクション	JSONコレクションのセット(単一のJSON列を持つ表)およびJSONドキュメントとしてフォーマットされた構成パラメータを入力として受け取ります。コレクションをJSONドキュメントとして表す、検証済で正規化されたリレーショナル・スキーマを戻します
`GENERATE_SCHEMA`ファンクション	JSONドキュメントとして表される正規化されたリレーショナル・スキーマを入力として受け取り、スキーマを生成するためのDDLスクリプトを戻します。
`INFER_AND_GENERATE_SCHEMA` ファンクション	JSONコレクションのセット(単一のJSON列を持つ表)およびJSONドキュメントとしてフォーマットされた構成パラメータを入力として受け取ります。コレクションをCLOBとして表す検証済で正規化されたリレーショナル・スキーマを生成するDDLスクリプトを戻します。
`VALIDATE_SCHEMA_REPORT` ファンクション	スキーマ検証のレポートを返す表ファンクション。 `GENERATE_SCHEMA`または`INFER_AND_GENERATE_SCHEMA`ファンクションによって生成されたスキーマを検証し、検証に失敗したドキュメントのレポートを生成します。ノート: スキーマを検証するには、適切なDDLスクリプトを実行してスキーマを作成したと想定されます。
`IMPORT` プロシージャ	二面性ビューの基礎となる表にデータをインポートします。インポートに失敗したドキュメントをエラー・ログに記録します。
`IMPORT_ALL` プロシージャ	複数の表から対応する二面性ビューにデータをインポートするプロシージャ。
`VALIDATE_IMPORT_REPORT` ファンクション	インポート検証用のレポートを返す表ファンクション。入力JSONコレクション内のドキュメント(単一のJSON列を持つ表)と対応する二面性ビューのドキュメントを比較し、検証に失敗したドキュメントのレポートを生成します。ノート: インポートを検証するには、「IMPORTプロシージャ」またはIMPORT_ALLプロシージャを使用してデータをインポートしたと想定されます。
`BEGIN_TRANSACTION` プロシージャ	特別な複数操作トランザクションを開始します。
`COMMIT_TRANSACTION` プロシージャ	複数操作トランザクションをコミットします。
`REGISTER` プロシージャ	トランザクションで変更する各ドキュメントを登録し、前回の読取り以降にドキュメントが変更されていないことを確認します。

INFER_SCHEMAファンクション

この項では、INFER_SCHEMAファンクションの構文、入力および出力形式について説明します。

概要

このファンクションは、単一のJSON列を持つ表と、JSONドキュメントとしてフォーマットされた構成パラメータを入力として受け取ります。 JSON構成ドキュメントの入力フィールドについては、「入力構成パラメータ」の項を参照してください。コレクションをJSONドキュメントとして表す、検証済で正規化されたリレーショナル・スキーマを戻します。

構文

FUNCTION INFER_SCHEMA(config in JSON)
RETURN JSON;

例112-1 INFER_SCHEMAファンクションの例

DECLARE
  schema_json json;
  schema_sql  clob;
BEGIN
  -- infer schema
  schema_json :=
    dbms_json_duality.infer_schema(
    json('{
           "tableNames"    : ["EMPLOYEE_TAB", "DEPARTMENT_TAB"],
           "viewNames"     : ["EMPLOYEES", "DEPARTMENTS"],
           "hints"         : json({"type" : "key", 
                                   "table" : "EMP",
                                   "path" : "$", 
                                   "value" : "empName"}),
           "useFlexFields" : true,
           "updatability"  : true,
           "sourceSchema"  : "HR",
           "targetSchema"  : "HR",
           "tablespace"    : "HR_TBS",
           "outputFormat"  : "executable"
          }'));

入力構成フィールド

ノート:

INFER_SCHEMA、INFER_AND_GENERATE_SCHEMAおよびIMPORT_ALLは、入力としてJSON構成ドキュメントを取ります。これらのファンクションのパラメータ・リストは異なりますが、重複しています。ただし、ファンクションと、そのファンクションに適用されないパラメータの両方に使用できる共通の構成ドキュメントを作成することは無視されます。

フィールド	値
tableNames	処理するJSONコレクションの表名の文字列のJSON配列
viewNames	生成される出力二面性ビュー名の文字列のJSON配列
useFlexFields	二面性ビューでフレックス・フィールドを使用する必要があるかどうかを示すブール・フィールド。 `true`の場合、二面性ビューごとに、サポートされているドキュメント内のオブジェクトの最上位フィールドの直下にある各表にフレックス列が追加されます。このフィールドのデフォルト値は`true`です。
updatability	マイグレータによって作成された二面性ビューをデフォルトで更新可能にするかどうかを示すブール・フィールド。 `true`の場合、マイグレータはすべての二面性ビューを更新可能としてマークします(つまり、二面性ビューの更新可能性を最大限にするために注釈が設定されます)。 `false`の場合、作成されるすべての二面性ビューは読取り専用になります。このフィールドのデフォルト値は`true`です。
normalize	ミグレータがデータの重複解除のために参照するリレーショナル表の正規化を試行するかどうかを示すブール・フィールド。このパラメータのデフォルト値は'true'です
sourceSchema	この文字列フィールドは、入力表のスキーマ名を定義します。このフィールドのデフォルト値は、現在のユーザー・スキーマです。
targetSchema	この文字列フィールドは、出力表および二面性ビューのスキーマ名を定義します。このフィールドには、デフォルト値はありません。指定しない場合、出力DDLにデータベース・スキーマは指定されません。作成されるデータベース・オブジェクトの名前は修飾されません。つまり、使用されるスキーマは、DDLコードの(生成時ではなく)実行時の現在のスキーマになります。
tablespace	この文字列フィールドは、マイグレータによって作成されたすべての表に使用する`tablespace`名を定義します。このフィールドにデフォルトはありません。このフィールドを指定しない場合、マイグレータによって作成された表の`tablespace`は未指定のままになります。
ingestLimit	この数値フィールドは、リレーショナル・スキーマを推測するために各JSONコレクションで分析されるドキュメントの最大数を定義します。このパラメータのデフォルト値は100000です。
outputFormat	この文字列フィールドは、出力DDLスクリプトの形式を定義します。このフィールドに指定できる値は"standalone"および"executable"です。 "executable"形式では、"execute immediate" PL/SQL構造を使用して直接実行できるDDLスクリプト出力が作成されます。 "standalone"形式では、SQLファイルにコピーして個別に実行する必要があるDDLスクリプトが作成されます。 "execute immediate" PL/SQL構造を使用して実行することはできません。このフィールドのデフォルト値は"executable"です。ノート: 出力DDL文が32k文字よりも大きい場合、ユーザーは"standalone"オプションを使用する必要があります。
minFieldFrequency	この数値フィールドは、高エントロピ・フィールドを識別するためのしきい値(パーセント)を定義します。このフィールドのデフォルト値は5で、コレクション内のドキュメントの5%未満で表示されるフィールドはスキーマからプルーニングされます。
minTypeFrequency	この数値フィールドは、特定のフィールドの上位エントロピ・タイプを識別するためのしきい値をパーセンテージで定義します。このフィールドのデフォルト値は5です。つまり、コレクション内のドキュメントの5%未満で表示されるフィールドのタイプは、スキーマからプルーニングされます。
softnessThreshold	この数値フィールドは、入力データのファンクション依存性を識別する際に許容される'ソフトネス'のしきい値(パーセント)を定義します。このフィールドのデフォルト値は99です。つまり、データの1%に情報が欠落しているか、正しくない情報が含まれる可能性があります。このフィールドの値は、入力データの'ダーティネス'に基づいて設定できます。データがダーティである(より多くのエラーを含む)ほど、このフィールドの値を小さくする必要があります。
hints	フィールドでリレーショナル・スキーマの生成時のコンバータの動作に対するオーバーライドを指定するJSONオブジェクトである要素を含むJSON配列。ヒント・オブジェクトにはこれらのフィールドが必要です(それ以外の場合はエラーが発生します): `type`, `table`, `path`および`value`。 `value`以外のすべてのパラメータは文字列型です。 `type` : ヒントのタイプは、`datatype`、`key`または`normalize`で、移行子動作オーバーライドのタイプを指定できます。 `value` : ヒントを定義する詳細を提供する、特定の`type`に固有の情報。 (これは、必ずしも文字列ではない唯一のヒント・フィールドです。) `table` : 文書セット・データが二面性ビューの定義に使用される入力表を指定する文字列。 `path` : 入力JSONドキュメント内のデータをターゲットとするSQL/JSONパス式文字列。ノート: `hints`フィールドの詳細は、ここにあります : JSON-To-Dualityマイグレータの構成フィールド

GENERATE_SCHEMAファンクション

この項では、GENERATE_SCHEMAファンクションの構文、入力および出力形式について説明します。

概要

このファンクションは、JSONドキュメントとして表される正規化されたリレーショナル・スキーマを入力として受け取り、スキーマを生成するためのDDLスクリプトを戻します。

構文

FUNCTION GENERATE_SCHEMA(er_schema in JSON)
  RETURN CLOB;

例112-2 GENERATE_SCHEMAファンクションの例


DECLARE
  schema_json json;
  schema_sql  clob;
BEGIN
  -- infer schema
  schema_json :=
    dbms_json_duality.infer_schema(
    json('{
           "tableNames"    : ["EMPLOYEE_TAB", "DEPARTMENT_TAB"],
           "viewNames"     : ["EMPLOYEES", "DEPARTMENTS"],
           "useFlexFields" : true,
           "updatability"  : true,
           "sourceSchema"  : "HR",
           "targetSchema"  : "HR",
           "tablespace"    : "HR_TBS",
           "outputFormat"  : "executable"
          }'));
  
   -- modify schema as needed
   ...
 
   -- generate schema
   schema_sql = dbms_json_duality.generate_schema(schema_json);
    
  -- create schema
  execute immediate schema_sql;
END;
/

ノート:

schema_sqlは、INFER_SCHEMAファンクションの出力です。 INFER_SCHEMAファンクションの詳細は、ここを参照してください。

INFER_AND_GENERATE_SCHEMAファンクション

この項では、INFER_AND_GENERATE_SCHEMAファンクションの構文、入力および出力形式について説明します。

概要

このファンクションは、JSONコレクションのセット(単一のJSON列を持つ表)と、JSONドキュメントとしてフォーマットされた構成パラメータを入力として受け取ります。 JSON構成ドキュメントの入力フィールドは、INFER_SCHEMAファンクションと同じであり、ここにリストされています。コレクションをCLOBとして表す検証済で正規化されたリレーショナル・スキーマを生成するDDLスクリプトを戻します。

構文

FUNCTION INFER_AND_GENERATE_SCHEMA(config in JSON)
  RETURN CLOB;

例112-3 INFER_AND_GENERATE_SCHEMAファンクションの例

DECLARE
  schema_sql clob;
BEGIN
  -- infer and generate schema
  schema_sql :=
    dbms_json_duality.infer_and_generate_schema(
    json('{
           "tableNames"    : ["EMPLOYEE_TAB", "DEPARTMENT_TAB"],
           "viewNames"     : ["EMPLOYEES", "DEPARTMENTS"],
           "useFlexFields" : true,
           "updatability"  : true,
           "sourceSchema"  : "HR",
           "targetSchema"  : "HR",
           "tablespace"    : "HR_TBS",
           "outputFormat"  : "executable"
          }'));
  
   -- create schema
   execute immediate schema_sql;
END;
/

VALIDATE_SCHEMA_REPORTファンクション

この項では、VALIDATE_SCHEMA_REPORTファンクションの構文、入出力形式について説明します。

概要

VALIDATE_SCHEMA_REPORTは、スキーマ検証のレポートを返す表ファンクションです。 GENERATE_SCHEMAまたはINFER_AND_GENERATE_SCHEMAファンクションによって生成されたスキーマを検証し、検証に失敗したドキュメントのレポートを生成します。出力の各行は、単一のJSONドキュメントの検証失敗に対応します。無効なドキュメントが見つからない場合、ファンクションは行を返しません。 VALIDATE_SCHEMA_REPORTの出力形式は、2つのCLOB列dataおよびerrorsを持つ表です。列dataには誤ったJSONドキュメントが含まれ、列errorsにはスキーマ・エラーの配列が含まれます。 VALIDATE_SCHEMA_REPORTのエラーの値は、JSONスキーマ検証エラーを含むJSON配列です。配列の形式は、DBMS_JSON_SCHEMA.VALIDATE_REPORTの出力の「errors」フィールドの形式と同じです。

構文

FUNCTION VALIDATE_SCHEMA_REPORT(
  table_owner_name in VARCHAR2 DEFAULT NULL,
  table_name       in VARCHAR2,
  view_owner_name  in VARCHAR2 DEFAULT NULL,
  view_name        in VARCHAR2
) return validate_report_tab_t PIPELINED;

入力パラメータ

表112-1 DBMS_JSON_DUALITY.VALIDATE_SCHEMA_REPORTの入力パラメータ

パラメータ	説明
`table_owner_name`	単一のJSON列を持つ入力表の所有者の名前。このフィールドの値は、データ・ディクショナリに存在する表の所有者名と同じである必要があります。そうしない場合は、現在接続しているユーザーのスキーマが使用されます。
`table_name`	単一のJSON列を持つ入力表の名前。このフィールドの値は、データ・ディクショナリに存在する表名と同じである必要があります。
`view_owner_name`	出力二面性ビューの所有者の名前。このフィールドの値は、データ・ディクショナリに存在するビュー所有者名と同じである必要があります。そうしない場合は、現在接続しているユーザーのスキーマが使用されます。
`view_name`	出力二面性ビューの名前。このフィールドの値は、データ・ディクショナリに存在するビュー名と同じである必要があります。

例112-4 VALIDATE_SCHEMA_REPORTファンクションの例

ノート:

スキーマを検証するには、「GENERATE_SCHEMAファンクション」または「INFER_AND_GENERATE_SCHEMAファンクション」を使用してスキーマを生成したと想定されます。

select * from dbms_json_duality.validate_schema_report('HR, 'EMPLOYEE_TAB', 'HR', 'EMPLOYEES');
select * from dbms_json_duality.validate_schema_report('HR, 'DEPARTMENT_TAB', 'HR', 'DEPARTMENTS');

IMPORTプロシージャ

この項では、IMPORTプロシージャの構文、入力および出力形式について説明します。

概要

このプロシージャは、単一のJSON列を持つ表から二面性ビューにデータをインポートします。また、インポートに失敗したドキュメントをエラー・ログに記録します。

ノート:

正規化のプロセスでは、データが変換されたり、異なるデータ型にキャストされたり、最大サイズ制限を考慮して切り捨てられることがあります。また、結果のスキーマに準拠していないデータは、インポート・フェーズ中に拒否される場合があります。検証テストを実行し、エラー・ログでインポート・エラーの解決を確認して、すべてのデータが正常にインポートされたことを確認することをお薦めします。

構文

PROCEDURE IMPORT(table_owner_name   in VARCHAR2 DEFAULT NULL,
                 table_name         in VARCHAR2,
                 view_owner_name    in VARCHAR2 DEFAULT NULL,
                 view_name          in VARCHAR2,
                 err_log_owner_name in VARCHAR2 DEFAULT NULL,
                 err_log_name       in VARCHAR2 DEFAULT NULL,
                 reject_limit       in NUMBER   DEFAULT NULL);

入力パラメータ・フィールド

パラメータ値

table_owner_name

単一のJSON列を持つ入力表の所有者の名前。 table_nameで所有者を指定できます。そうしない場合は、現在接続しているユーザーのスキーマが使用されます。

table_name

単一のJSON列を持つ入力表の名前。

view_owner_name

出力二面性ビューの所有者の名前。 veiw_nameで所有者を指定できます。そうしない場合は、現在接続しているユーザーのスキーマが使用されます

view_name

出力二面性ビューの名前。

err_log_owner_name

正常にインポートできないドキュメントに使用するエラー・ログの所有者の名前。 err_log_nameで所有者を指定できます。そうしない場合は、現在接続しているユーザーのスキーマが使用されます。

err_log_name

使用するエラー・ログの名前。デフォルト値はNULLであるため、デフォルトではエラーは記録されません。

reject_limit

操作を中断する前にログに記録できるエラーの最大数を指定します。デフォルト(NULL)は無制限であるため、error_log_nameが指定されている場合、デフォルトでは操作は中断されません。

例112-5 IMPORTプロシージャの例

BEGIN
  dbms_errlog.create_error_log(dml_table_name => 'EMPLOYEES', err_log_table_name => 'ERR$_EMP', skip_unsupported => TRUE);
  dbms_errlog.create_error_log(dml_table_name => 'DEPARTMENTS', err_log_table_name => 'ERR$_DEPT', skip_unsupported => TRUE);
  dbms_json_duality.import('HR', 'EMPLOYEE_TAB', 'HR', 'EMPLOYEES', 'HR', 'ERR$_EMP', 100);
  dbms_json_duality.import('HR', 'DEPARTMENT_TAB', 'HR' 'DEPARTMENTS', 'HR', 'ERR$_DEPT', 100);
END;
/

IMPORT_ALLプロシージャ

この項では、IMPORT_ALLプロシージャの構文、入力および出力の形式について説明します。

概要

IMPORT_ALLは、複数の表から対応する二面性ビューにデータをインポートするプロシージャです。複数のインポートが必要な場合は、外部キー制約違反のリスクを回避するために、IMPORTプロシージャのかわりにこのプロシージャを使用する必要があります。 IMPORT_ALLプロシージャの入力は、JSONドキュメントの形式で提供される構成オプションのセットです。 IMPORT_ALLはプロシージャであるため、出力はありません。

PROCEDURE IMPORT_ALL(config in JSON);

表112-2 JSON構成ドキュメントの入力フィールド

フィールド	説明
`tableNames`	単一のJSON列をインポートする表の名前の配列。このフィールドの値は、データ・ディクショナリに存在する表名と同じである必要があります。
`viewNames`	二面性ビューの名前の配列。順序は、`tableNames`と`viewNames`の間に維持する必要があります。指定しない場合、`viewNames`は`tableNames`から導出され、その後に'_DUALITY'で固定されます。このフィールドの値は、データ・ディクショナリに存在するビュー名と同じである必要があります。
`sourceSchema`	この文字列パラメータは、入力表の引用符で囲まれたスキーマ名を定義します。このフィールドの値は、データ・ディクショナリに存在するソース・スキーマと同じである必要があります。このパラメータのデフォルト値は、現在のユーザー・スキーマです。
`targetSchema`	この文字列パラメータは、二面性ビューの引用符で囲まれたスキーマ名を定義します。このフィールドの値は、データ・ディクショナリに存在するターゲット・スキーマと同じである必要があります。このパラメータのデフォルト値は、現在のユーザー・スキーマです。
`errorLog`	使用するエラー・ログの文字列名、OR 使用するエラー・ログの名前の文字列配列(二面性ビューごとに1つ)。このフィールドの値は、データ・ディクショナリに存在するエラー・ログ名と同じである必要があります。
`errorLogSchema`	正常にインポートできないドキュメントに使用するエラー・ログのスキーマの名前。所有者は`errorLog`で指定できます。そうしない場合は、現在接続しているユーザーのスキーマが使用されます。このフィールドの値は、データ・ディクショナリに存在するエラー・ログ・スキーマと同じである必要があります。
`rejectLimit`	操作を中断する前にログに記録できるエラーの最大数を指定します。デフォルト(NULL)は無制限であるため、`errorLog`が指定されている場合、操作はデフォルトでは中断されません。

ノート:

tableNames以外のすべてのパラメータはオプションです。 INFER_SCHEMA、INFER_AND_GENERATE_SCHEMAおよびIMPORT_ALLは、入力としてJSON構成ドキュメントを取ります。これらのファンクションのパラメータ・リストは異なりますが、重複しています。ただし、ファンクションと、そのファンクションに適用されないパラメータの両方に使用できる共通の構成ドキュメントを作成することは無視されます。

例112-6 IMPORT_ALLプロシージャの例

BEGIN
  dbms_errlog.create_error_log(dml_table_name => 'EMPLOYEES', err_log_table_name => 'ERR$_EMP', skip_unsupported => TRUE);
  dbms_errlog.create_error_log(dml_table_name => 'DEPARTMENTS', err_log_table_name => 'ERR$_DEPT', skip_unsupported => TRUE);
  dbms_json_duality.import_all(json('{"tableNames" : ["EMPLOYEE_TAB","DEPARTMENT_TAB"],
                                      "viewNames" : ["EMPLOYEES","DEPARTMENTS"],
                                      "sourceSchema" : "HR",
                                      "targetSchema" : "HR",
                                      "errorLog" : ["ERR$_EMP","ERR$_DEPT"]
                                     }'));
END;
/

VALIDATE_IMPORT_REPORTファンクション

この項では、VALIDATE_IMPORT_REPORTファンクションの構文、入出力形式について説明します。

概要

VALIDATE_IMPORT_REPORTは、インポート検証用のレポートを返す表ファンクションです。 IMPORTおよびIMPORT_ALLファンクションへの入力として渡されたドキュメントと、対応する二面性ビューのドキュメントを比較し、検証に失敗したドキュメントのレポートを生成します。出力の各行は、単一のJSONドキュメントの検証失敗に対応します。無効なドキュメントが見つからない場合、ファンクションは行を返しません。 VALIDATE_IMPORT_REPORTの出力形式は、2つのCLOB列dataおよびerrorsを持つ表です。列dataには誤ったJSONドキュメントが含まれ、列errorsにはインポート・エラーの配列が含まれます。 VALIDATE_IMPORT_REPORTのエラーの値は、表内の入力JSONドキュメントと二面性ビュー内の出力JSONドキュメントのJSON差異です。 diffの形式は、「JSONパッチ」の形式と同じです。

構文

FUNCTION VALIDATE_IMPORT_REPORT(
  table_owner_name in VARCHAR2 DEFAULT NULL,
  table_name       in VARCHAR2,
  view_owner_name  in VARCHAR2 DEFAULT NULL,
  view_name        in VARCHAR2
) return validate_report_tab_t PIPELINED;

入力パラメータ

表112-3 DBMS_JSON_DUALITY.VALIDATE_IMPORT_REPORTの入力パラメータ

パラメータ	説明
`table_owner_name`	単一のJSON列を持つ入力表の所有者の名前。このフィールドの値は、データ・ディクショナリに存在する表の所有者名と同じである必要があります。そうしない場合は、現在接続しているユーザーのスキーマが使用されます。
`table_name`	単一のJSON列を持つ入力表の名前。このフィールドの値は、データ・ディクショナリに存在する表名と同じである必要があります。
`view_owner_name`	出力二面性ビューの所有者の名前。このフィールドの値は、データ・ディクショナリに存在するビュー所有者名と同じである必要があります。そうしない場合は、現在接続しているユーザーのスキーマが使用されます。
`view_name`	出力二面性ビューの名前。このフィールドの値は、データ・ディクショナリに存在するビュー名と同じである必要があります。

例112-7 VALIDATE_IMPORT_REPORTファンクションの例

ノート:

インポートを検証するには、「IMPORTプロシージャ」またはIMPORT_ALLプロシージャを使用してデータをインポートしたと想定されます。

select * from dbms_json_duality.validate_import_report('HR, 'EMPLOYEE_TAB', 'HR', 'EMPLOYEES');
select * from dbms_json_duality.validate_import_report('HR, 'DEPARTMENT_TAB', 'HR', 'DEPARTMENTS');

BEGIN_TRANSACTIONプロシージャ

この項では、BEGIN_TRANSACTIONという名前の非対話型プロシージャの構文について説明します

概要

非対話型トランザクションの一般的なワークフローには、次の順序で次のプロシージャが含まれます:

トランザクションを開始します
ドキュメントを登録します
二面性ビューに対して問合せまたはDMLを実行します
トランザクションをコミットします

BEGIN_TRANSACTIONプロシージャは、次のプロパティを持つ特別な複数操作トランザクションを開始します:

複数操作トランザクションでは、繰返し可能な読取り(つまり、トランザクションの開始時にスナップショット時点で実行されるすべての読取り)が提供されます。
ロックは、変更された行に対してのみ実行され、変更されていない行はトランザクション全体でロックされていないままになります

構文

 procedure begin_transaction;

例112-8 BEGIN_TRANSACTIONプロシージャの例

dbms_json_duality.begin_transaction()

ノート:

通常、BEGIN_TRANSACTIONプロシージャの後にREGISTERプロシージャが続きます。 REGISTERプロシージャの詳細は、ここを参照してください。

COMMIT_TRANSACTIONプロシージャ

この項では、 COMMIT_TRANSACTIONという名前の非対話型プロシージャの構文について説明します

概要

このプロシージャは、特別な複数操作トランザクションをコミットします。トランザクション内のすべての変更されたドキュメントを検証します。つまり、他のセッションでこれらのドキュメントが変更されていないことを確認します。

構文

procedure commit_transaction;

例112-9 COMMIT_TRANSACTIONプロシージャの例

COMMIT_TRANSACTIONプロシージャは通常、二面性ビューに対して問合せが実行された後の、非対話型トランザクションの最後のステップです。

dbms_json_duality.commit_transaction();

REGISTERプロシージャ

この項では、REGISTERという名前の非対話型プロシージャの構文について説明します

概要

このプロシージャは、オブジェクトの現在のetagが前の読取りから変更されていないことを確認します。 etagが想定されたetagと一致しない場合、このファンクションからエラーがスローされます。登録プロシージャでは、登録および検証するオブジェクト/ドキュメントを識別するためにオブジェクトID (oid)を使用します。オブジェクトIDは、二面性ビューからresid非表示列を問い合せることで取得できます。この値は、二面性ビュー内のルート表のすべての主キー列を連結したバイナリ・エンコーディングです。

構文

 procedure register(view_name in VARCHAR2,  /* duality view name */                    
                    oid       in RAW,       /* duality view obj identifier */                    
                    etag      in RAW);      /* document etag */

例112-10 REGISTERプロシージャの例

この例では、二面性ビューteam_dvがすでに作成されていることを前提としています。二面性ビューの作成の詳細は、『Oracle Database JSONリレーショナル二面性開発者ガイド』の二面性ビューの作成を参照してください。 REGISTERプロシージャをコールする前に、RESIDおよびETAGを取得する必要があります。次に、二面性ビューteam_dvのRESIDおよびETAGを取得するコードの例を示します:

SELECT RESID, DATA FROM team_dv dv
  WHERE dv.DATA.name LIKE 'Mercedes%';

これにより、次に示すように、oid (RESID)およびETAG情報を含む出力が生成されます:


RESID
-----
DATA
----
FB03C2040400
{"_id" : 303,
 "_metadata":
  {"etag" : "039A7874ACEE6B6709E06E42E4DC6355",
   "asof" : "00000000001BE239"},
 "name" : "Mercedes",
 ...}

ノート:

REGISTERプロシージャは通常、BEGIN_TRANSACTIONプロシージャの実行後に実行されます。 BEGIN_TRANSACTIONプロシージャの詳細は、ここを参照してください。


BEGIN
  DBMS_JSON_DUALITY.begin_transaction();
  DBMS_JSON_DUALITY.register('team_dv',
                             hextoraw('FB03C2040400'),
                             hextoraw('039A7874ACEE6B6709E06E42E4DC6355'));
  .............................................
  ****Perform the updating (DML) operations****
  .............................................

  DBMS_JSON_DUALITY.commit_transaction();
END