1. JSONリレーショナル二面性開発者ガイド
  2. JSONリレーショナル二面性ビューの概要

1 JSONリレーショナル二面性ビューの概要

JSONリレーショナル二面性ビューでは、JSONドキュメントを使用する利点とリレーショナル・モデルの利点が結合され、それぞれの制限が回避されます。

  • 単一のJSONドキュメントは、アプリケーション・オブジェクトを直接表し、そのコンポーネント間の階層関係を取得できます。JSONドキュメントはスタンドアロンです。自己完結型かつ自己記述型であり、外部参照がなく、外部スキーマを参照する必要がありません。分解はありません。つまり、JSONはスキーマ・フレキシブルです。アプリケーションの変更に応じて、フィールドを簡単に追加および削除できます。

    ただし、ドキュメント間の関係はドキュメント自体では表現されません。アプリケーションは、ロジックの一部として、関係を個別にコーディングする必要があります。特に、あるドキュメントの一部である値は、他のドキュメントと共有できません。これにより、(同じ種類または異なる種類のいずれであっても)異なるドキュメント間でデータの重複が発生し、ドキュメントの更新時に不整合が発生する可能性があります。

  • リレーショナル・モデルでは、アプリケーション・オブジェクト(ビジネス・オブジェクト)が正規化された表に分解されます。この表は明示的に関連していますが、そのコンテンツは独立しています。この独立性により、柔軟で効率的なデータの組合せ(結合)が可能になり、厳密な正確性と信頼性が確保されます。

    これにより、データの重複に関する不整合やその他の問題が回避されますが、アプリケーション・オブジェクトとリレーショナル表の間のマッピングの定義という負担がアプリケーション開発者にかかります。アプリケーションの変更では、表へのスキーマ変更が必要になる場合があります。これにより、アジャイル開発が妨げられる場合があります。そのため、開発者は多くの場合、ドキュメント中心のアプリケーションを使用することを好みます。

JSONリレーショナル二面性ビューは、リレーショナル・データベース表に格納されているデータをJSONドキュメントとして公開します。ドキュメントはオンデマンドでマテリアライズ(生成)され、それ自体は格納されません。二面性ビューでは、概念と操作の両方の二面性をデータに提供できます。このビューは、関係的かつ階層的に編成されます。1つ以上の同じ表に格納されているデータに基づいて異なる二面性ビューを作成し、同じ共有データに対して異なるJSON階層を提供できます。

つまり、アプリケーションはJSONドキュメントのセットまたは関連表および列のセットと同じデータにアクセス(作成、問合せ、変更)でき、両方のアプローチを同時に使用できます。

  • ドキュメント中心のアプリケーションでは、Oracle Database API for MongoDBやOracle REST Data Services (ORDS)などのドキュメントAPIを使用することも、SQL/JSON脚注1ファンクションを使用することもできます。二面性ビューによって実現されるドキュメントを、通常のドライバ、フレームワーク、ツールおよび開発方法を使用して、慣れた方法で操作できます。特に、アプリケーションでは任意のプログラミング言語を使用できます。JSONドキュメントは共通言語です。

  • データベース分析、レポート、機械学習などの他のアプリケーションでは、SQL、PL/SQL、C、JavaScriptなどの言語を使用して、同じデータを(表の行と列のセットとして)直接的、関係的に使用できます。JSONドキュメントを使用するために、表データを使用する既存のデータベース機能やコードを適合させる必要はありません。

JSONリレーショナル二面性ビューは、特定の種類のJSONドキュメント(構造およびフィールド・タイプ)の構造を直接定義および反映します。ビューは基礎となるデータベース表に基づいており、この表が自動的に結合されて、該当の種類のドキュメントが実現されます。

基礎となる表のJSON以外のSQLデータ型の列では、ビューでサポートされているドキュメントにスカラーJSON値が生成されます。SQLデータ型JSONの列では、ドキュメントに任意の種類(スカラー、オブジェクトまたは配列)のJSON値を生成でき、JSONデータは(特定のドキュメント形式およびフィールド型を適用するために)スキーマレスまたはJSONスキーマベースにできます。二面性ビューの基礎となる表で使用できる列データ型については、「カーレースの例、表」を参照してください。

基礎となる表から生成されたJSONフィールドは、二面性ビュー・ドキュメントの任意のJSONオブジェクトに含めることができます。ビューを定義するときに、これらを含める場所、および個別に含めるか独自のオブジェクトにネストするかを指定します。デフォルトでは、ネストされたオブジェクトが使用されます。 脚注2

二面性ビューは、定義方法に応じて、読取り専用または完全または部分的に更新可能にできます。SQLまたはGraphQL言語のサブセットを使用して、二面性ビューおよびその更新可能性を宣言的に(どのようにではなく、何を/どこに)定義できます。

JSONドキュメントを挿入、削除または更新するために二面性ビューを変更すると、そのビューの基礎となる関連リレーショナル(表)データが自動的に更新されます。

二面性ビューでは、特定の種類(構造およびタイプ)のJSONドキュメントのセットがサポートされており、(1)ドキュメントは生成され(それ自体は格納されない)、かつ(2)基礎となる表データへの更新は同様にドキュメントに自動的に反映されることを意味します。

共有データのため、ドキュメントのセット(同じまたは異なる二面性ビューでサポート)が相互に関連する場合でも、アプリケーションはドキュメントを読み取り、変更し、書き戻すことができます。データベースはドキュメントの変更を検出し、基礎となるすべての表の行に必要な変更を加えます。これらの行のいずれかが他の二面性ビューの基礎となっている場合、それらの他のビューおよびサポートされているドキュメントにも変更が自動的に反映されます。

逆に、1つ以上の二面性ビューの基礎となっている表内のデータを変更すると、それらの変更は自動的に反映され、それらのビューでサポートされているドキュメントに即時に反映されます。

データは同じですが、その表示/アクセスに2つの方法があります。

二面性ビューを使用すると、ドキュメントおよびリレーショナルに次の利点があります。

  • ドキュメント: 簡単なアプリケーション開発(プログラミング・オブジェクト・マッピング、取得/更新アクセス、共通交換フォーマット)

  • リレーショナル: 一貫性、領域効率、正規化(柔軟なデータの組合せ/構成/集計)

関連項目:

1.1 JSONリレーショナル二面性ビューのユースケース

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二面性ビューの一部の基礎となっています。 脚注3

他の列と同様に、JSON型の列は二面性ビュー間で共有できるため、様々な種類のJSONドキュメント間で共有できます。(列podiumは共有されません。レース・ドキュメントにのみ使用されます。)二面性ビューの基礎となる表へのJSON型の列の格納の詳細は、「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データおよび二面性ビューのデータとやり取りできます(いずれの場合も、JSONドキュメントのセットがあります)。

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

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

既存のリレーショナル・データはすでにデータ分析とファクタリングを実施しているため、既存のリレーショナル・データに基づく二面性ビューの定義は簡単です。つまり、既存のリレーショナル・データをJSONドキュメントのセットとして再利用するドキュメント中心のアプリケーションを簡単に適応または定義できるということです。これには、リレーショナル・データとJSONデータの二面性という非常に優れた点があります。広範囲のリレーショナル・データは、JSONドキュメントのセットとして利用できます。

関連トピック

関連項目:

親トピック: JSONリレーショナル二面性ビューの概要

1.2 プログラミング・オブジェクトではなく、JSONドキュメントのマップ

JSONリレーショナル二面性ビューは、JSONドキュメントとリレーショナル・データの間のマッピングを宣言的に定義します。これは、プログラミング・オブジェクトをリレーショナル・データにマップする方法よりも優れています。

オブジェクト・リレーショナル・マッパー(ORM)またはオブジェクト・ドキュメント・マッパー(ODM)を使用する場合、または概念をよく理解している場合、このトピックは、オブジェクト・リレーショナル・インピーダンスの不一致の問題を処理するための二面性ビューのアプローチをより深く理解するのに役立ちます。

二面性ビューは、ORMの一種であると言えます。階層オブジェクト・データもリレーショナル・データに対してマップします。しかし、代替アプローチとは根本的に異なります。

二面性ビューでは、言語やフレームワークに関係なく、サーバー側とクライアント側(すべてのクライアント)の両方のアプリケーション・オブジェクトの永続性フォーマットを集中管理します。永続性モデルは、同じデータ(表とドキュメント)の2つの側面を提示します。サーバー側のコードは、表のリレーショナル・データを操作できます。クライアント側のコードは一連のドキュメントを操作できます。

クライアント・コードでは、プログラミング・オブジェクトと、慣れていて簡単なJSONとの間で変換するだけで済みます。二面性ビューは、JSONをリレーショナル・データとして自動的に永続化します。個別のマッパーは必要ありません。二面性ビューでマッピングが行われます。

この点の主なポイントは次のとおりです。

  • JSONドキュメントをマップし、プログラミング・オブジェクトをマップしません。

    二面性ビューでは、リレーショナル・データにマップするオブジェクトはJSONドキュメントのみです。二面性ビューはドキュメント・リレーショナル・マッピング(DRM)またはJSONリレーショナル・マッピング(JRM)であると言えます。

    二面性ビューは、(マッピングまたはアプリケーション・プログラミングに)特定の言語の使用や特定の言語への適応に限定されることはありません。あらゆるJSONドキュメントに対応しています。また、すべてのリレーショナル・データにも対応しています。これが二面性ということです。

  • 宣言的にマップします。

    二面性ビューはマッピングであるため、マッパーは必要ありません。二面性ビューをJSONドキュメントとリレーショナル表の間の宣言的なマップとして定義します。以上です。手続き型プログラミングはありません。

  • データベースの内部でマップします。

    二面性ビューは、データベース・オブジェクトです。チューニングするツール生成のSQLコードはありません。ドキュメントに対するアプリケーション操作は、データベース内で最適に実行されます。

    個別のマッピング言語またはツール、プログラミング、デプロイ、構成、設定はありません。マッピング自体に関するものは、任意のデータベース機能および任意のアプリケーションで使用できます。二面性ビューは、特別な種類のデータベース・ビューです。

    これは、アプリケーションとデータベース間のラウンドトリップが少なくなり、読取り一貫性がサポートされ、パフォーマンスが向上することも意味します。

  • アプリケーション・コードではなく、ドキュメントの部分を宣言的に処理するためのルールを定義します。

    二面性ビューでは、どのドキュメント部分が共有されるか、および更新できるかどうかと更新方法を定義します。どのアプリケーションまたは言語が更新を要求するかに関係なく、同じルール検証/施行が自動的に実行されます。

  • プログラミング言語やツールを使用して、ドキュメント(必要なものすべて)にアクセスしたり、これらを操作します。同じドキュメントを様々なアプリケーション、様々なプログラミング言語、様々な方法で使用します。

  • 同じデータを複数の種類のドキュメントで共有します。

    新しい二面性ビューはいつでも作成し、様々な表の内容を組み合せます。一貫性は自動的に維持されます。データベースの停止時間もコンパイルも不要です。新しいビューは(ただちに)動作し、既存のビューやアプリケーションも動作します。二面性ビューは、サポートされているドキュメントの部分が相互に依存している(共有されている)場合でも独立しています。

  • ロックレス/オプティミスティックな同時実行性制御を使用します。

    実際には単一のアプリケーション操作のトランザクション・セマンティクスを確保するために、データをロックし、複数のSQL文を送信する必要はありません。(データベースに送信する生成済SQLはありません。)

二面性ビューは、1つ以上の表の部分を、ビューが定義するJSONドキュメントにマップします。表のすべての列をマップする必要はありません。ドキュメントは、マッピング(二面性ビュー)に直接依存し、基礎となる表にのみ間接的に依存します。これは二面性の一部であり、2つの異なるビューを提示します。様々なもの(表、ドキュメント)のビューだけでなく、通常は多少異なるコンテンツも提示します。コンテンツに関しては、ドキュメントは表データのサブセットを結合します。

この分離/抽象化は、二面性ビューの基礎となる表のすべての列を、サポートされているドキュメントにマップする必要があるとはかぎらないという事実に明確に見てとれます。ただし、列の追加など、基礎となる表への一部の変更は、マッピング(ビュー定義)でそれらの変更を反映していないため、既存のドキュメントに影響を与えることを自動的に防止します。この形式の表レベル・スキーマ展開では、既存の二面性ビュー、ドキュメントまたはアプリケーションを変更する必要はありません。

一方、アプリケーションを更新して一部の表レベルの変更を反映する場合は、ビュー定義を変更して、必要に応じてこれらの変更を考慮に入れます。このアプリケーションの動作の変更は、ビュー定義の変更後に作成されるドキュメントに制限できます。

あるいは、変更された表定義を直接反映する新しい二面性ビューを作成できます。そのビューは新しいバージョンのアプリケーションで使用できる一方で、古いバージョンのアプリケーションでは引き続き古いビューを使用します。このように、停止時間を制限しながら、すべてのクライアントを同時にアップグレードする必要を回避できます。

この場合、基礎となる表のスキーマが展開されると、サポートされているドキュメントのスキーマ展開が発生します。たとえば、ドキュメント・フィールドにマップされている表の列が削除される場合があります。これにより、アプリケーション・ロジックおよびドキュメント定義が変更される可能性があります。

関連トピック

親トピック: JSONリレーショナル二面性ビューの概要

1.3 二面性ビューのセキュリティ: シンプル、集中管理、ユースケース固有

二面性ビューを使用すると、データ・セキュリティが向上します。アクセスと操作を任意のレベルで制御できます。

セキュリティ制御は集中管理されています。二面性ビューに関する他のすべてのものと同様に、データベースで定義、検証、適用および監査されます。これは、各アプリケーションでデータを保護しようとすることと対照的です。権限、付与およびロールを使用して、他のデータベース・オブジェクトへのアクセスを制御するのと同じ方法で、二面性ビューでサポートされるドキュメントへのアクセスを制御します。

二面性ビューのセキュリティは、ユースケースに固有です。表レベルでの広い可視性を提供するのではなく、二面性ビューでは、基礎となる表からデータの関連する列のみが公開されます。たとえば、一部の受講者データを含む教師ビューにアクセスできるアプリケーションでは、社会保障番号や住所などの非公開の受講者データにアクセスできません。

公開/可視性の他に、二面性ビューでは、どのようにしてどのデータを更新できるかを宣言的に定義できます。受講者ビューでは受講者名を変更でき、教師ビューでは変更できない場合があります。教師向けのアプリケーションはコース名を変更できますが、受講者向けのアプリケーションは変更できません。「更新可能なJSONリレーショナル二面性ビュー」および「二面性ビューでのドキュメント/データの更新」を参照してください。

2種類のセキュリティ制御を組み合せて、誰/何がどのフィールドに対して何を実行できるかを制御できます。

  • ドキュメント・フィールドとしてわずかに異なる列セットを公開する類似の二面性ビューを作成します。つまり、アクターの異なるグループを対象とするビューを定義します。(二面性ビューでサポートされるドキュメントは、それ自体は格納されないため、追加コストはかかりません。)

  • 権限とロールを付与して、選択的に異なるグループのユーザー/アプリケーションを様々なビューにアクセスできるようにします。

この宣言的でインデータベースのフィールド・レベルのアクセス制御と、なんらかの方法で(アプリケーション・コードまたはオブジェクト・リレーショナル・マッパー(ORM)を使用して)ユーザーまたはアプリケーションが特定の表またはドキュメントのセット内のすべてのデータにアクセスおよび更新できないようにする必要があることを対比してください。

データベースはドキュメントの変更を自動的に検出し、関連する表の行のみを更新します。逆に、表の更新は、その基になるドキュメントに自動的に反映されます。データベースの外側にマッピング・レイヤーはありません。ORMが再マップの要求を仲介することはありません。

また、クライアント・アプリケーションはJSONドキュメントを直接使用できます。マッパーでは、アプリケーション・オブジェクトおよびクラスをドキュメントおよびドキュメント・タイプに接続する必要はありません。

複数のアプリケーションで、ドキュメントまたは基礎となる表を同時に更新することもできます。どちらかに対する変更は、透過的にただちに他方に反映されます。特に、既存のSQLツールでは、アプリケーションがその行に基づいてドキュメントを更新すると同時に表の行を更新できます。ドキュメント・レベルの一貫性と表の行レベルの一貫性が同時に保証されます。

また、このセキュアな同時実行性はロックフリーになるため、高いパフォーマンスが得られます。「二面性ビューでのオプティミスティックな同時実行性制御の使用」を参照してください。

関連トピック

親トピック: JSONリレーショナル二面性ビューの概要

1.4 Oracle Database: コンバージド、マルチテナント、SQLによる支援

JSONリレーショナル二面性ビューを使用する場合、アプリケーションではコンバージド・データベースの利点を活用できます。

これらの利点は次のとおりです。

  • JavaScript Object Notation (JSON)データのネイティブ(バイナリ)・サポート。これには、更新、索引付け、宣言的な問合せ、生成およびビューが含まれます

  • 高度なセキュリティ(監査や、ロールと付与を使用したファイングレイン・アクセス制御など)

  • 複数のドキュメントおよび表にわたる完全なACID (原子性、一貫性、分離、永続性)トランザクション

  • あらゆる種類のデータ(JSONを含む)でJOINの簡単な標準化

  • 最新の分析、機械学習、レポート作成

Oracle Databaseは、コンバージド・マルチモデル・データベースです。1つにまとめられた様々な種類のデータベースのように機能し、様々な機能にわたって相乗効果をもたらし、様々なワークロードおよびデータ・モデルをサポートします。

Oracle Databaseは、多言語です。複数のアプリケーション言語を使用して、JSONデータを含むあらゆる種類のデータをシームレスに結合および操作できます。

Oracle Databaseは、マルチテナントです。様々なチームおよび目的にあわせて、統合と分離の両方を実現できます。セキュリティ、アップグレード、パッチ適用、メンテナンスに共通の単一のアプローチを使用できます。(Autonomous JSON DatabaseなどのAutonomous Oracle Databaseを使用する場合、Oracleは、このようなデータベース管理の役割をすべて処理します。自律型データベースは、自動管理、自動保護、自己修復およびサーバーレスです。また、自律型データベースへのAlways Freeアクセスがあります。)

標準の宣言型言語SQLは、Oracle Databaseでの処理の基礎となります。一般的なアプリケーション開発言語をOracle Database API for MongoDBやOracle REST Data Services (ORDS)などのAPIとともに使用してアプリケーションを開発している場合でも、SQLの機能によって、そのすべてが支えられており、Oracle Database上のその他すべてのものとそのアプリケーションを連携させることができます。

親トピック: JSONリレーショナル二面性ビューの概要


脚注一覧

脚注1: SQL/JSONは、ISO/IEC 9075-2:2016, Information technology—Database languages—SQL— Part 2: Foundation (SQL/Foundation)で指定されています。SQL標準で、Oracle SQL/JSONサポートとJSONサポートの整合が密接に図られます。
脚注2: キーワードUNNESTをSQLビュー定義で使用するか、GraphQLビュー定義のディレクティブ@unnestを使用して、フィールドを直接含めることができます。「カーレースの例、二面性ビュー」を参照してください。
脚注3: 例2-4および例2-9を参照してください。