8.3 二面性ビューにJSON型列を使用する状況

二面性ビューの基になる一部のデータをJSONデータ型として格納するかどうかと、格納する場合はその構造および型指定を強制適用するかどうかは、JSONリレーショナル二面性ビューを定義する際に考慮する、設計上の選択です。

二面性ビューでサポート(生成)されるJSONドキュメントに関与する一部のJSONデータを格納することで、ビューを定義する構成要素の粒度および複雑度を選択できます。言い換えると、基礎となるデータに必要な正規化の度合いを選択できます。選択肢が異なれば、トレードオフも異なります。

二面性ビューの基になる表データが完全に正規化されている場合、それらの表列にはスカラーSQLデータ型の値のみが含まれ、そのビューでサポートされているドキュメントの構造、およびそのフィールドの型は、リレーショナル構造を使用して固定され厳密に定義されます。

正規化によりスキーマ柔軟性が低下しますが、完全な正規化により、様々な種類の二面性ビューをサポートするために複数の表からのデータを組み合せることに関して柔軟性が最も高くなります(二面性ビューの用途以外で、より一般的に述べると、ある表データを他の表データと組み合せることに関してです)。

また、重要な特定のユースケースでは、完全な正規化により、ドキュメント中心のアプリケーションから、JSONドキュメントとして既存のリレーショナル表内のデータにアクセスできるようになります。

一方、正規化の度合いが大きいほど、表が多くなるため、JSONデータの挿入時や更新時に分解が増え、その問合せ時に結合(再構成)が増えます。通常、アプリケーションで複雑なオブジェクト全体にアクセスする場合は、正規化が大きいほどパフォーマンスに悪影響を与える可能性があります。

二面性ビューの基になる表内の他の列と同様に、JSON型列は様々な二面性ビューの間で共有でき、それにより、その値を、結果として得た(生成された)様々なJSONドキュメントで共有できます。

デフォルトでは、JSON値は自由形式です: その構造および型指定を、指定したパターン/スキーマによって定義することやそれらに強制的に準拠させることはできません。この場合は、アプリケーションで、必要に応じて値の形式や型(スキーマ柔軟性)を簡単に変更できます。

ただし、JSONスキーマを使用して、JSON型列にあるデータに型指定と構造を強制適用できます。JSONスキーマを使用すると、次のような全面的な制御が可能です:

  1. 値がまったく定義されていないフィールドから、値が厳密に定義されているフィールドまで。

  2. スカラーJSON値から、大規模で複雑なJSONオブジェクトおよび配列まで。

  3. 単純なタイプ定義からJSON言語タイプの組合せまで。次に例を示します。

    • JSONスキーマのセットのanyOf、allOfまたはoneOfを満たす値

    • 特定のJSONスキーマを満たさない(not)値

ノート:

二面性ビュー定義で、SQLスカラー型(DATE、VARCHAR2など)に対応する特定のJSONスカラー型(日付、文字列など)のデータのみを保持するようにJSONスキーマによって制約されているJSON型列を使用する場合は、対応するSQLスカラー型の列を使用する場合と、そのビューでサポートされているJSONドキュメントでの効果が同じです。

ただし、このような格納されたJSON型データに直接作用するコードは、必ずしもこの対応を認識して考慮するとはかぎりません。データのSQL型は結局、JSONであり、DATE、VARCHAR2などではありません。SQLスカラー・データ型の値としてJSONスカラー値を抽出するには、コードでSQL/JSONファンクションjson_valueを使用する必要があります。『Oracle Database JSON開発者ガイド』の「SQL/JSONファンクションJSON_VALUE」を参照してください。

二面性ビューの基になる表での、SQLスカラー列の使用とJSON型列の使用の間のトレードオフについて、いくつか概要を示します。

  1. 組合せの柔軟性。最も細かい組合せにするには、列がすべてSQLスカラーである、完全に正規化された表を使用します。

  2. ドキュメントのタイプおよび構造の柔軟性。任意の時点でのJSONフィールド値の柔軟性を最大限に高めるには、また、時間経過に伴う変化(進化)に対応するには、JSONスキーマ制約のないJSON型列を使用します。

  3. フィールド定義の粒度。最も細かい粒度では、二面性ビューでサポートされるドキュメント内のどこにフィールドがあるかに関係なく、JSONフィールドごとに1列必要です。(列がJSON型の場合でも、フィールド値はJSONオブジェクトまたは配列である可能性があります。)

アプリケーションが様々な種類のドキュメント間で複雑なJSONデータを共有することが理にかなっている場合や、他のドキュメントと、またはSQLスカラーとしてリレーショナル・データと、その複雑なデータの一部のみを組み合せる必要がないと想定する場合は、その複雑なデータの基礎となる列にJSONデータ型を使用することを検討します。

つまり、このようなユースケースでは、JSONドキュメントを構成するスカラー値を共有するのではなく、JSONドキュメントを共有することを検討します。さらに言い換えれば、二面性ビューのレシピでもっと複合材料を使用することを検討してください。

列データの粒度(列内のデータの複雑度)により、更新操作およびETAGチェックの粒度(オプティミスティックな同時実行性制御の場合)も決まることに注意してください。このような操作の最小単位は、二面性ビューの基礎となる個々の列です。JSON型の列内の個々のフィールドに注釈を付けることはできません。

更新操作は、特定のJSON型の列のデータに含まれる特定のフィールドに選択的に適用できますが、特定のビューで使用できる更新操作の制御は、基礎となる列または表全体(これより小さいものはありません)のレベルで定義されます。そのため、よりきめ細かい更新またはETAGチェックが必要な場合は、JSONデータの関連部分をそれぞれのJSON型の列に取り出す必要があります。

関連項目:

親トピック: 二面性ビューでのJSON列によるスキーマ柔軟性