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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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