JSON To Dualityマイグレータのコンポーネント: コンバータとインポータ

21.3 JSON To Dualityマイグレータのコンポーネント: コンバータとインポータ

JSON To Dualityマイグレータには、コンバータとインポータの2つのコンポーネントがあります。それぞれのPL/SQLサブプログラムについて説明します。

コンバータ: 元のJSONドキュメントをサポートするために必要なデータベース・オブジェクト(二面性ビューとその基礎となる表および索引)を作成します。
インポータ: 元の外部ドキュメントに対応するOracle Database JSON型のドキュメント・セットを、コンバータによって作成された二面性ビューにインポートします。

コンバータは、パッケージDBMS_JSON_DUALITY内の次のPL/SQLファンクションで構成されます:

infer_schemaは、すべての入力ドキュメント・セットを表すJSONスキーマを推測します。
- 入力: メンバーが推測操作の構成パラメータを指定するJSONオブジェクト。「マイグレータ・パラメータを指定するJSON構成フィールド」を参照してください。
- 出力:推測されたリレーショナル・スキーマを指定するJSONスキーマ・ドキュメント。このようなスキーマが見つからない場合は、入力ドキュメント・セットに対応する二面性ビューをコンバータでは作成できないことを示すエラーが発生します。
generate_schemaは、二面性ビューごとに必要なデータベース・オブジェクトを作成するためのDDLコードを生成します。
- 入力: ファンクションinfer_schemaよって返されるJSONスキーマ。
- 出力: 必要なデータベース・オブジェクトを作成するためのDDLスクリプト。
infer_and_generate_schemaは、両方の操作を実行します。
- 入力: infer_schemaと同じです。
- 出力: generate_schemaと同じです。
validate_schema_reportは、ファンクションgenerate_schemaによって生成されるDDLコードによって作成されるデータベース・オブジェクトの妥当性をチェックします。作成される二面性ビューに従って入力JSONドキュメントの妥当性についてレポートし、サポートできないドキュメントを特定してサポートできない理由も示します。これらは、二面性ビューのJSONスキーマに照らした検証に失敗したドキュメントです。
- 入力:
  - table_owner_name: 表table_nameを所有するデータベース・スキーマ(ユーザー)の名前。
  - table_name: JSONドキュメントの入力表の名前。
  - view_owner_name: ビューview_nameを所有するデータベース・スキーマ(ユーザー)の名前。
  - view_name: generate_schemaによって生成されるDDLコードによって作成される、対応する二面性ビューの名前。
- 出力: 入力JSONドキュメントの検証失敗の表。失敗したドキュメントごとに1行あります(行がない場合は、すべてのドキュメントが有効であることを意味します)。行には、CLOB列DATA (無効なドキュメント)およびERRORS (ファンクションDBMS_JSON_SCHEMA.validate_reportのフィールドerrorsと同じ形式のエラーのJSON配列)があります。

importerは、パッケージDBMS_JSON_DUALITY内の次のPL/SQLサブプログラムで構成されます:

プロシージャimport_allは、コンバータによって作成された二面性ビューすべてに、対応する入力ドキュメント・セットのドキュメント(より正確には、このようなドキュメントをサポートするために必要なリレーショナル・データ)を移入します。エラー・ログ表では、インポートできなかったドキュメントごとにエラーをレポートします。(ドキュメントごとに最初に発生したエラーのみがレポートされます。)
- 入力: メンバーがインポート操作の構成パラメータを指定するJSONオブジェクト。「マイグレータ・パラメータを指定するJSON構成フィールド」を参照してください。
- 出力: (1)基礎となる表を含む二面性ビューで、同じドキュメントをサポートするリレーショナル・データが充填されています。(2)インポートできなかったドキュメントをレポートするエラー・ログ表。
プロシージャimportは、対応する入力ドキュメント・セットのドキュメントを単一の二面性ビューに移入します。エラー・ロギングは、プロシージャimport_allと同じです。
- 入力: (1) Oracle Database JSONドキュメント・セット。つまり、特定の種類のドキュメントを含む単一のJSON型の列を含む表。(2)移入する二面性ビューの名前。(3) (オプション)表の所有者の名前。(4) (オプション)ビューの所有者の名前。(5) (オプション)エラー・ログ表の所有者の名前。(6) (オプション)エラー・ログ表の名前。(7) (オプション)拒否制限値。構成フィールドrejectLimitと同じで、ログに記録できるエラーの最大数(この制限を超えるとインポートは終了)を意味します。
- 出力: (1)基礎となる表を含む二面性ビューで、同じドキュメントをサポートするリレーショナル・データが充填されています。(2)インポートできなかったドキュメントをレポートするエラー・ログ表。
ヒント:

一般に、プロシージャimportではなく、プロシージャimport_allを使用します。単一ビューのimportは、他の二面性ビューのデータに干渉する可能性が低い場合にのみ実行します。

importを使用して複数の単一ビューを個別にインポートすると、ビューの相互依存関係が原因で問題が発生する可能性があります。次に例を示します:
- ルート表student_rootには外部キー列advisor_idがあり、対応する教師のデータがすでに存在する必要があるため、importを使用してビューteacherの前にビューstudentを移入することはできません。
- 一方、教師のドキュメントでは学生の埋込みオブジェクトにdormIdフィールドがあり、対応する列dorm_idは表student_rootから表student_dormitoryへの外部キーであるため、importを使用してビューstudentの前にビューteacherを移入することはできません。このため、表student_dormitoryは、ビューteacherの前に移入する必要があります。また、その表は、既存の学生のドキュメントをインポートすることによってのみ移入できます。
ファンクションvalidate_import_reportは、無効なJSONドキュメントが正常にインポートされたことをレポートします。

出力表の各行は、インポートされたJSONドキュメントの検証失敗に対応します(行がない場合は、すべてのドキュメントが有効であることを意味します)。行には、CLOB列DATA (無効なドキュメント)およびERRORS (エラーのJSON配列。それぞれは、入力ドキュメントと二面性ビュー内の対応するインポートされたドキュメントを比較するJSONパッチ・ドキュメントの形式です)。エラー形式については、JavaScript Object Notation (JSON) Patch, IETF RFC6902を参照してください。
- table_owner_name: 表table_nameを所有するデータベース・スキーマ(ユーザー)の名前。
- table_name: JSONドキュメントの入力表の名前。
- view_owner_name: ビューview_nameを所有するデータベース・スキーマ(ユーザー)の名前。
- view_name: 表table_name内のドキュメントが移入される、対応する二面性ビューの名前。

インポート・エラー・ロギングでは、インポートできなかったドキュメントのみがレポートされ、インポート検証では、正常にインポートされた(ただし、なんらかの問題がある)ドキュメントのみがレポートされます。

関連トピック

フレックス列(基本より詳しい説明)