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

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

JSONリレーショナル二面性では、同じデータに関して2つの視点が提供されます。1つはドキュメント中心のビュー(一連のJSONドキュメントとして)であり、もう1つは表中心のビュー(一連のリレーショナル表として)です。各視点の利点が組み合され、それぞれの制限事項は回避されます。

JSONリレーショナル二面性ビューでは、基にあるデータベース表に格納されているデータが、JSONドキュメントのコレクションとして公開されます。これは、表データとドキュメントの間のマッピングです。

二面性ビューが関与しなければ、ドキュメント・コレクションとリレーショナル表はまったく異なります。

ドキュメント・コレクション:

メリット:アプリケーション・オブジェクトを直接表して、それらのコンポーネントの間の階層関係を捕捉できます。ドキュメントは、自己完結型であり、スキーマの柔軟性があります。
デメリット: アプリケーションで、ドキュメント間の関係について定義し対処する必要があります。具体的に述べると、それらで、ドキュメント間で値を共有するための(複製するのではない)コードを提供する必要がある場合があります。

リレーショナル表:

メリット: 表は、明示的に宣言されたリレーションを除き、独立しています。これにより、柔軟で効率的な組合せが実現され、重複が回避されます。
デメリット: 開発者が表データをアプリケーション・オブジェクトにマップする必要があります。アプリケーションの変更には表の再定義が必要になる場合があり、それによってアジャイル開発が妨げられる可能性があります。

二面性ビューを使用すると、アプリケーションで、(1)JSONドキュメントのコレクションまたは(2)関連する一連の表および列と同じデータにアクセス(作成、問合せ、変更)できます。どちらの方法も、異なるアプリケーションまたは同じアプリケーションによって同時に採用できます。つまり、JSONリレーショナル二面性は、完全に表中心のリレーショナル・データベースから、完全にドキュメント中心のドキュメント・データベースまで、様々なユーザーおよびユースケースに対応しています。

二面性ビュー・データはリレーショナル形式で格納されており、それには、基にある表を使用して直接アクセスできます。しかしながら、同じ格納データをドキュメントとして読み取ることや更新することもできます。読取り時は、ドキュメントが自動的に表データから組み立てられ、書込み時はその部分が自動的に組み立てられて、関連する表に格納されます。二面性ビューを宣言的に定義すると、表データとドキュメントの間の対応付けがデータベースによって自動的に処理されるようになります。

二面性ビューでは、データに概念と操作の両方の二面性を提供できます。それは、関係的かつ階層的に編成されます。1つ以上の同じ表に格納されているデータに基づいて異なる二面性ビューを作成し、同じ共有データに対して異なるJSON階層を提供できます。

簡単な例を見てみましょう。部門表を定義し、その表の上に部門二面性ビューを定義します。

CREATE TABLE dept_tab
  (deptno     NUMBER(2,0),   
   dname      VARCHAR2(14),   
   code       NUMBER(13,0),
   state      VARCHAR2(15),
   country    VARCHAR2(15),  
   CONSTRAINT pk_dept PRIMARY KEY (deptno));

CREATE JSON RELATIONAL DUALITY VIEW dept_dv AS
  SELECT JSON {'_id'      : d.deptno,
               'deptName' : d.dname,
               'location' : {zipcode : d.code,
                             country : d.country}
    FROM dept_tab d WITH UPDATE INSERT DELETE;

二面性ビューdept_dvでは、最上位フィールド_id、deptNameおよびlocationを含むJSONドキュメントのコレクションがサポートされています。ドキュメント識別子フィールド_idは、二面性ビューごとに自動的に生成されます。その値により、特定のドキュメントが一意に識別されます。フィールドdeptNameには、表dept_tabの列dnameから値が取得されます。フィールドlocationの値は、フィールドzipcodeおよびcountryがあるオブジェクトであり、それらの値はそれぞれ列codeおよびcountryから取得されます。たとえば、これは二面性ビューのコレクション内のドキュメントです:


{_id      : 200,
 deptName : "HR"
 location : {zipcode : 94065,
             country : "USA"}

これらのドキュメントでは、基にある表内の一部のデータが使用され(列stateは使用されない)、それが階層的に表示されます。この二面性ビュー定義は宣言的であり、その形式では、サポートしているJSONドキュメントの構造とタイプが直接反映されています。

クライアント・アプリケーションとデータベース・アプリケーションにより、それぞれ状況に合った方法で(ドキュメントまたはリレーショナル)、同じ二面性ビュー・データにアクセスできます。

ドキュメント中心のアプリケーションでは、Oracle Database API for MongoDBやOracle REST Data Services (ORDS)などのドキュメントAPIを使用するか、データベースのSQL/JSON^脚注1ファンクションを使用することができます。開発者は、通常のドライバ、フレームワーク、ツールおよび開発方法を使用して、いつもどおりの方法で、二面性ビューによって実現されている二面性ビュー・ドキュメントを操作できます。具体的に述べると、それらのアプリケーションでは、任意のプログラミング言語を使用できます。JSONドキュメントは共通言語です。
その他のアプリケーション(データベース分析、レポート、機械学習など)では、SQL、PL/SQL、C、JavaScriptなどの言語を使用して、同じデータを関係的に(表の行と列として直接)使用できます。開発者は、JSONドキュメントを使用するために、表データを使用する既存のデータベース機能やコードを適応させる必要はありません。

二面性ビューの基にあるすべてのデータを完全に正規化する必要はありません。二面性ビューでサポートされているJSONドキュメントの一部をJSONデータとして格納する必要がある場合は、それらをスカラーSQL列値に分解するのではなく、これらのドキュメント部分を基にある表のJSON型の列にマッピングするだけでそれを実現できます。この格納されたJSONデータは、ドキュメント内でそのまま、読取りと書込みの両方に使用されます。JSON型の列は、二面性ビューの基にある他の列と同様に、ビュー間で共有できます。

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

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

ノート:

基礎となる表の特定の列を使用して、ドキュメントの様々なオブジェクトのフィールドをサポートできます。その場合は、各オブジェクトで同じ列値が使用されます。つまり、データは共有されます。

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

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

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

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

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

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

二面性ビューを使用すると、ドキュメントとリレーショナルの両方の利点があります:

ドキュメント: 簡単なアプリケーション開発(プログラミング・オブジェクト・マッピング、取得/更新アクセス、共通交換フォーマット)
リレーショナル: 一貫性、領域効率、正規化(柔軟なデータの組合せ/構成/集計)

_________________________________________________________

JSONリレーショナル二面性の表中心ユースケース
表中心のデータベース・アプリケーションの開発者は、二面性ビューを使用して、JSONドキュメントを使用するアプリケーションとインタフェースで接続しそれらを活用できます。二面性ビューにより、リレーショナル表データがドキュメントにマップされます。
JSONリレーショナル二面性のドキュメント中心ユースケース
ドキュメント中心のアプリケーションの開発者は、二面性ビューを使用して、表に格納されている正規化されたリレーショナル・データとインタフェースで接続しそれらを活用できます。
プログラミング・オブジェクトではなく、JSONドキュメントのマップ
JSONリレーショナル二面性ビューは、JSONドキュメントとリレーショナル・データの間のマッピングを宣言的に定義します。これは、プログラミング・オブジェクトをリレーショナル・データにマップする方法よりも優れています。
二面性ビューのセキュリティ: シンプル、集中管理、ユースケース固有
二面性ビューを使用すると、データ・セキュリティが向上します。アクセスと操作を任意のレベルで制御できます。
Oracle Database: コンバージド、マルチテナント、SQLによる支援
JSONリレーショナル二面性ビューを使用する場合、アプリケーションではコンバージド・データベースの利点を活用できます。