21.2 JSONから二面性への移行について

既存および新規アプリケーションのJSON-To-Dualityマイグレータのユースケースについて学習します。

二面性ビューの基になる表にJSONデータ型の列を含めると、アプリケーションで、そのビューによってサポートされているドキュメントに対して、フィールドの追加と削除、フィールド値の型変更ができるようになります。格納されているJSONデータは、スキーマレスにもJSONスキーマベース(特定の型の値を適用するため)にもできます。

移行には監視は必要ありませんが、結果として得られる二面性ビューおよびサポートされているドキュメントをチェックして、ニーズに適切かどうかを確認する必要があります。移行動作を変更すると、結果を変更できます。

JSON-to-Dualityマイグレータには、2つの主なユースケース脚注1があります:

  • 既存のアプリケーションとそのJSONドキュメント・セットをドキュメント・データベースからOracle Databaseに移行します。

  • 使用する様々な種類のJSONドキュメント(構造および型指定)の知識に基づいて、新しいアプリケーションを作成します。マイグレータは、必要な二面性ビューを自動的に作成することで、このジョブを簡素化できます。

既存の格納されたドキュメント・セットを二面性ビューでサポートされているドキュメント・コレクションに移行するには、次の操作を実行ます。ステップ3から8ではコンバータを使用し、ステップ9から13ではインポータを使用します。ステップ1から2は準備段階です。ステップ2、4、7、10および13はオプションです。

  1. Oracle Databaseで、元の外部ドキュメント・セットからJSON型のドキュメント・セットを作成します。

    各ドキュメント・セットのコンバータへの入力は、JSONデータ型の単一列を含むOracle Database表です。ドキュメント・データベースからJSONドキュメント・セットをエクスポートし、JSON型の列にインポートできます。

  2. 必要に応じて、入力ドキュメント・セットを記述するJSONスキーマであるJSONデータ・ガイドを作成します。

    これらは、コンバータによって推測されるJSONスキーマの一部、または移行によって完成したドキュメント・コレクションと後で比較するときに役立つ場合があります。

  3. 入力ドキュメント(リレーショナル表、索引および二面性ビュー)をサポートするために必要なデータベース・オブジェクトを推測します。

    このステップでは、まず既存の入力データを検証し、ドキュメント・セットを実際に二面性ビュー・サポートに変換できるかどうかをチェックします。

    表は、正規化されたリレーショナル・スキーマを構成します。正規化は、ドキュメント・セット全体とドキュメント・セット内の両方で行われます。異なるドキュメント・セット内の同等のデータは、同じ表に格納することで共有されます。

  4. 必要に応じて、推測されたJSONスキーマを変更/編集します。

  5. 入力データをサポートするために必要なデータベース・オブジェクトを作成します:

    1. データベース・オブジェクト(二面性ビューとその基礎となる表および索引)を作成するSQLデータ定義言語(DDL)スクリプトを生成します。

    2. 必要に応じて、DDLスクリプトを変更/編集します。

    3. スクリプトを実行して、データベース・オブジェクトを作成します。

  6. 作成されたデータベース・オブジェクト(二面性ビューとその基礎となるリレーショナル・スキーマ)を検証します。つまり、入力ドキュメントをデータベース・オブジェクトに照らして検証し、存在する場合は、どのドキュメントが二面性ビューでサポートされていないかと、その理由を確認します。

  7. 必要に応じて、入力ドキュメントまたはDDLスクリプトを改良/修正(変更/編集)します。

    1. 必要に応じて、誤った入力ドキュメント(そのまま保持しない外れ値や、異なるドキュメント間でのデータの競合)を変更/編集して、作成されたデータベース・オブジェクトに適合するようにします。

    2. 必要に応じて、DDLスクリプトを変更/編集し、変換動作や作成するビュー、表または索引の名前を変更します。

  8. インポートするドキュメント・セットと(移入されていない)二面性ビューが希望どおりに適合するまで、ステップ3から9を繰り返します。

  9. ドキュメント・セットを二面性ビューにインポートします。ログに記録されたエラーを確認します。

  10. 必要に応じて、入力ドキュメントまたはDDLスクリプトを改良/修正(変更/編集)し、インポート・エラーを修正します。

  11. 必要に応じて、ステップ9から10 (または3から10)を繰り返して、すべてのドキュメントが正常にインポートされるまで、ログに記録されたインポート・エラーを修正します。

  12. インポートの検証: 正常にインポートされたドキュメントで問題がないか確認します。

  13. 必要に応じて、入力ドキュメントまたはDDLスクリプトを改良/修正(変更/編集)し、インポート検証の問題を解決します。

  14. 必要に応じて、ステップ9から13 (または3から13)を繰り返して、インポートの問題を修正します。

JSON-to-Dualityマイグレータの使用を説明するために、学校経営アプリケーションで使用できる3つの小規模なドキュメント・セット(学生、教師およびコースのドキュメント)を使用します。(実際のアプリケーションでは、ドキュメント・セット内にさらに多くのドキュメントが存在する可能性が高く、ドキュメントは複雑になる場合があります。)「学校経営の例(マイグレータの入力ドキュメント)」の学生のドキュメント・セット、教師のドキュメント・セットおよびコースのドキュメント・セットに、既存の入力ドキュメント・セットを示します。

各ドキュメント・セットは、特定の種類のドキュメント(学生のドキュメントなど)のドキュメント・データベース・ダンプ・ファイルから一時転送表のJSON型の列dataにロードされます。転送表名には、接尾辞_tabが付きます(たとえば、学生のドキュメントの場合はstudent_tab)。列dataは、転送表の唯一の列です。

マイグレータは、対応する二面性ビュー(たとえば、学生のドキュメントの場合はビューstudent)を作成し、格納されたドキュメントの転送表からデータを移入します。これが完了し、二面性ビューの妥当性を検証したら、転送表は不要になるので、削除できます。その後、ドキュメント・セットは、そのどおりには格納されなくなります。現在正規化されているデータは、二面性ビューの基礎となる表に格納されます。

ノート:

二面性ビューへの移行により、既存のアプリケーション・データがすべて完全に保持されるという保証はありません。正規化のプロセスでは、一部のデータが変換されたり、異なるデータ型にキャストされたり、最大サイズ制限を考慮して切り捨てられることがあります。宛先リレーショナル・スキーマに準拠していない入力データは、インポート時に拒否される場合があります。

マイグレータ検証テストを実行してエラー・ログを調べ、すべてのデータが正常にインポートされたことを確認する必要があります。

入力ドキュメント・セット内のドキュメントを対応する二面性ビューでサポートされているドキュメントと比較し、二面性ビューのドキュメントに想定されるフィールドのみが含まれ、フィールドが欠落していないまたは許容できない方法で変更されていないことを確認することで、インポートしたデータが有効であることを確認できます。

関連トピック

親トピック: JSONから二面性への移行


脚注一覧

脚注1: マイグレータは、二面性ビューの3番目の主要ユースケース(JSONドキュメントで使用するための既存のリレーショナル・データ(表)の再使用)には役立ちません。