JSONリレーショナル二面性のドキュメント中心ユースケース

1.2 JSONリレーショナル二面性のドキュメント中心ユースケース

ドキュメント中心のアプリケーションの開発者は、二面性ビューを使用して、表に格納されている正規化されたリレーショナル・データとインタフェースで接続しそれらを活用できます。

ドキュメント中心のユースケース:

ドキュメント中心の1つ以上のアプリケーション(つまり、JSONドキュメントをプライマリ・データとして使用)を所有しているか、これを開発します。ほとんどの場合、通常のドライバ、フレームワーク、ツール、開発方法およびプログラミング言語を使用して、慣れた方法で、アプリケーションによるドキュメントの操作(問合せ、更新)を可能にする必要があります。
アプリケーションが使用する様々な種類のJSONドキュメントの基本的な構造が比較的安定した状態を維持する必要があります。
使用しているJSONドキュメントの一部は、全体的な構造が異なっていても、同じ部分があります。これらのドキュメントは階層型(ツリー)ですが、一部の共通部分に相互に関連しています。それぞれは個別にツリーになっていますが、まとめると1つのグラフを構成します。
Oracle Databaseで提供されるすべての高度な処理、高パフォーマンスおよびセキュリティ機能をアプリケーションで活用できるようにする必要があります。

このような場合に、Oracle Database JSONリレーショナル二面性ビューを使用すると、アプリケーション・データを定義および格納するというメリットが得られます。たとえば、これらの条件の一部のみが適用されるケースなど、他のケースでもメリットが得られる可能性があります。二面性ビューの導入の背後にある主な動機として、それらがもたらす様々な利点を提示するのに、このケースは役立ちます。

共有データ

二面性ビューのユースケースの重要な部分は、様々なJSONドキュメントがあり、その一部は同じままにする必要があるという点です。常に同じデータを複製することは、無駄なことです。最終的に、これはアプリケーションのメンテナンスと進化に問題をもたらします。共通部分の同期を維持するアプリケーションが必要です。

ドキュメント中心のアプリケーションによって提示される暗黙的な問題は、JSONドキュメントが階層型でしかないことです。また、同じアプリケーションの場合でも、1つの階層がすべてのものの要件を満たすわけではありません。

受講者、教師およびコースが関係するスケジューリング・アプリケーションを考えてみます。受講者のドキュメントには、受講者が登録しているコースに関する情報が含まれています。教師のドキュメントには、教師が教えているコースに関する情報が含まれています。コースのドキュメントには、コースに登録されている受講者に関する情報が含まれています。問題は、同じまたは異なる形式の複数の種類のドキュメントに同じ情報が存在することです。これは、これらのドキュメントを使用してこの固有の共有を管理するアプリケーションに残されています。

二面性ビューでは、これらの部分は複製されるのではなく、自動的に共有されます。共有する必要のあるもののみが共有されます。このような共有データの更新は、使用されているすべての場所で反映されます。これにより、ユーザーに階層ドキュメントの世界と関連データおよび共有データの世界の両方が最適に提供されます。

異なるドキュメントの様々な部分で必要な他の制約や関係が何であっても、アプリケーション自体でこれらを管理しなければならないという理由はありません。Oracle Databaseで対応可能です。この情報は、宣言的に、1回のみ指定できます。

いくつかの部分を共有する様々な種類のJSONドキュメントの例を次に示します。このドキュメントでは、カーレース情報の例を使用しています。

ドライバ・ドキュメントには、特定のレースカーのドライバに関する情報(ドライバ名、チーム名、獲得したレーシング・ポイント、参加レースのリストおよびレース名とドライバ・ポジション)が記録されます。
レース・ドキュメントには、特定のレースに関する情報(名前、ラップ数、日付、入賞者(上位3人のドライバ)、および参加したドライバのリストとそのポジション)が記録されます。
チーム・ドキュメントには、レーシング・チームに関する情報(名前、獲得ポイント、ドライバのリスト)が記録されます。

関連項目:

カーレースの例、JSONドキュメント

安定したデータ構造とタイプ

二面性ビューのユースケースのもう1つの重要な部分は、JSONドキュメントの基本的な構造およびフィールド・タイプがそれらの定義を尊重し、比較的安定した状態を維持していることです。

二面性ビューでは、この安定性が自動的に適用されます。これは、正規化された表、つまり、コンテンツが相互に独立している表(ただし、相互に関連している可能性があります)に基づいて実行されます。

この方法でドキュメント設計を尊重する必要があるドキュメント部分と必要でない部分のみを定義できます。このような安定した構造と型指定を持つ必要がない部分は、ドキュメントおよびアプリケーションの柔軟性を提供できます。基礎となるデータはOracle SQLデータ型JSON (ネイティブ・バイナリJSON)です。

これらの柔軟性の高い部分には、二面性ビューによる制限は課せられません。(ただし、これらはJSONデータ型であるため、必ず整形式のJSONデータです。)データは、二面性ビューの基礎となる表に従って構造化または型指定されません。ただし、JSONスキーマを使用して、任意の数の構造または型の制限を個別に課すことができます(次を参照)。

格納されたJSON型データを二面性ビューにその定義の一部として直接組み込む例は、race表の列podiumです。この表は、このマニュアル内のF1カーレースの例で使用されているrace_dv二面性ビューの一部の基になっています。^脚注1

他の列と同様に、JSON型の列は二面性ビュー間で共有できるため、様々な種類のJSONドキュメント間で共有できます。(列podiumは共有されません。レース・ドキュメントにのみ使用されます。)二面性ビューの基になる表へのJSON型列の格納については、「二面性ビューでのJSON列によるスキーマ柔軟性」を参照してください。

JSONデータは完全にスキーマレスであり、認識されていないか、頻繁な変更に影響を受けやすい構造とタイプがあります。または、特定のJSONスキーマへの準拠を要求することで、これにある程度の定義を設定できます。JSONスキーマは、他のJSONドキュメントを記述するJSONドキュメントです。JSONスキーマを使用すると、ドキュメントおよびアプリケーションの柔軟性の程度を定義および制御できます。

データベース表に基づいているため、もちろん二面性ビュー自体では、特定の種類の構造およびタイプの安定性が適用されます。表は正規化され、それぞれが特定のSQLデータ型である特定の数の列を格納します。ただし、JSONスキーマを使用すると、JSON型の列に対して、様々な方法(JSON言語に固有の方法)で詳細なドキュメントの形式およびタイプの整合性を適用できます。

二面性ビュー定義では、サポートするドキュメントになんらかの構造およびフィールドの型指定が課されるため、JSONスキーマを暗黙的に定義します。このスキーマは、二面性ビュー自体が規定する内容のみを反映するドキュメントの説明です。静的ディクショナリ・ビューDBA_JSON_DUALITY_VIEWS、USER_JSON_DUALITY_VIEWSおよびALL_JSON_DUALITY_VIEWSの列JSON_SCHEMAで使用できます。PL/SQLファンクションDBMS_JSON_SCHEMA.describeを使用してスキーマを表示することもできます。

二面性ビューでは、定義済の関係によって各データを構成します。データは別の表にあるが他の表のデータに関連する表にJSONドキュメントのベースを置くことで、データの共有を正確に制御できます。

正規化とJSONスキーマ制約の両方によって、データの柔軟性が低下します。これは、ユーザーが(安定したドキュメント形式とフィールド・タイプを)必要とする場合も、必要としない場合もあります。

Oracle Databaseは、JSONドキュメントを使用するための完全な柔軟性と制御を提供します。二面性ビューでは、JSON型の列を組み込んで、正規化されていない、および(デフォルトでは)JSONスキーマ制約されない柔軟な部分をドキュメントに提供できます。二面性ビューのスキーマ柔軟性の制御については、「二面性ビューでのJSON列によるスキーマ柔軟性」を参照してください。

アプリケーションでは、二面性ビューによって生成されず、JSONデータ型の列として格納されているJSONドキュメント全体を使用することもできます。アプリケーションは、まったく同じ方法でJSON列のデータおよび二面性ビューのデータとやり取りできます(いずれの場合も、JSONドキュメント・セットがあります)。

JSONデータとやり取りする方法には、(1) Oracle Database API for MongoDBやOracle REST Data Services (ORDS)などのドキュメントAPIを使用したドキュメントストア・プログラミングと、(2) SQL、PL/SQL、CまたはJavaScriptを使用したSQL/JSONプログラミングがあります。

JSONリレーショナル二面性ビューは、特別なJSONコレクション・ビューです。通常の(非二面性)JSONコレクション・ビューは更新できません。JSONコレクション・ビューは、JSONコレクション表(更新可能)とともにJSONコレクションです。JSONコレクションは、ドキュメントAPIで直接使用できます。特に、二面性ビューのドキュメントとJSONコレクション表のドキュメントは、同じ形式にできるため、交換可能です。

つまり、たとえば、JSONコレクション表を使用してアプリケーションの開発を開始し、JSONドキュメントを永続的にスキーマなしで格納し、後でアプリケーションが安定しているときに、かわりにJSONリレーショナル二面性ビューをコレクションとして使用するように透過的に切り替えることができます。コレクションにアクセスするアプリケーション・コードは、同じ(更新、挿入、削除および問合せの)ままです。(これは、コレクション表に格納されているドキュメントの形状が、二面性ビューでサポートされているものと同じであることを前提としています。)

JSON二面性ビューは、これらの静的ディクショナリ・ビューにおいて、特異性の降順でリストされます。『Oracle Databaseリファレンス』の*_JSON_COLLECTION_VIEWS、*_JSON_COLLECTIONS、*_VIEWSおよび*_OBJECTSを参照してください。

構造的およびタイプの安定性を適用することは、特定のアプリケーションにとっての意味を定義することです。これは難しいことではありません。ただ、(1)様々なドキュメントの本当に共通にする(つまり、共有する)必要がある部分、(2)それらの共有部分がどのようなデータ型である必要があるか、(3)該当する場合は、どのような種類の更新が許可されているのかを特定する必要があります。これを指定することが、JSONリレーショナル二面性ビューを定義することの意味です。

関連トピック