このテキストでは、オブジェクトリレーショナルマッピング（ORM）の機能について簡単に説明し、コレクションリレーショナルマッピング（CoRM）の新しい概念を紹介し、オブジェクトの状態の長期保存という新しい概念の技術的実装の展望と可能性について議論することを提案しますオブジェクトリレーショナルマッピング（ORM）
今日、大規模で複雑なシステムの開発におけるほぼ一般的な場所は、オブジェクト指向マッピング（ORM）の使用です。ORMは、オブジェクト指向プログラミングとリレーショナルプログラミングの理論的基盤のいくつかの共通性を使用して、これら2つの本質的に異なる現実のモデリング方法を組み合わせます。
オブジェクト指向プログラミングは、主に
SQLクエリを実行するシステムの形で提示される
リレーショナルDBMSのパラダイムに適合しない概念に依存してい
ます 。 そのような概念は、階層データ構造、多態性、カプセル化、そしてもちろん継承です。 また、たとえば
PostgreSQLで継承がまだ何らかの形で開発されている場合、たとえば、SQLタプルの基本的なオープン性と値の任意の組み合わせに直接矛盾するカプセル化は、実際には、長期的なリレーショナルDBMSの効果的な使用に対する重大な（おそらく理論的な矛盾に基づく）障害を作成しますクラスオブジェクトの状態ストア。
それでも、リレーショナルDBMSの普及、大規模および非常に大きなデータ配列へのクエリ実行の相対的効率、リレーショナルDBMSを介した異種コンピューティング環境の組み合わせの幅広い可能性、およびそのようなDBMSの使用に関連するその他の利点により、オブジェクト内のシステム設計の利便性の間で妥協点を見つける必要があります指向のスタイルと、これらのDBMSを使用して設計されたシステムに課せられた制限。
ORMフレームワーク内でオブジェクトとリレーショナルパラダイムを組み合わせるための主なサポートは、リレーショナルテーブルに同じ構造の多くの要素（行）が含まれているように、クラスが単一の構造と動作で多くのオブジェクトを結合するという理論です。 したがって、ORM実装で一般的に使用される最も一般的なテンプレートの1つは、クラスのテーブルへのマッピングであり、テーブルのフィールドはクラスオブジェクトの属性（状態を一意に決定するすべてまたは一部）です。
図1オブジェクトリレーショナルマッピングの最も一般的な形式。 クラスはテーブルにマッピングされ、属性はテーブルフィールドにマッピングされます技術的な実装には制限があり、SQL言語に基づいたリレーショナルDBMSの技術は、理論上の前任者である
Codd 代数とは大きく
異なります。 同時に、1対1の関係で相互に関連付けられた値のタプルの物理的媒体としてのテーブルの存在に関連するSQLの技術的な制限はすべて、ORMを使用してそのようなテーブルにマップされたクラスに自然に移動します。
図2クラスからテーブルへの直接マッピングの問題の1つ：複数の性質の属性のマッピングには、個別のテーブルが必要です。コレクションのリレーショナルマッピング
コレクションのリレーショナルマッピング（コレクション-リレーショナルマッピング、CoRM）の概念は、オブジェクトの状態の長期保存としてのテーブルが、開発されたオブジェクト指向環境、つまりコレクション（コレクション）で完全に適切なイメージを持っているという事実に基づいています。
オブジェクトのコレクションの状態をSQLテーブルとして保存することは、新しい発明とはほど遠いものです。 そのため
、Python標準ライブラリにデータを
保存するための専用パッケージの半分は、この特定の技術専用です。 CoRMアプローチの新規性は、オブジェクトの
異なるコレクションが、これらのコレクション間の明確に定義された（明確に定義された）関係関係
によって結合されることです。
（以下が更新されました：05-30-2013、私が正しく指摘されたように、ドキュメント指向のDBMS、特にMongoDBもCoRMのプロトタイプと見なすことができます）CoRMは、特に
ドキュメント指向のDBMSや
MongoDbのように、
同じクラスの異なるオブジェクトが
異なるコレクションに状態を保存する能力、および
異なるクラスに属するオブジェクトを
同時に含むコレクションの能力に制限を課しません。 CoRMとドキュメント指向DBMS、およびそれらに基づくORMなどのツールの主な違いは、CoRMがSQLを使用する機能（わずかに変更された形式）とオブジェクト間の関係関係を使用する機能を保持していることです。 CoRMと従来のORMアプローチの違いは、コレクションがクラスに直接結び付けられておらず、理論的にはこのオブジェクトの最小要件（つまり、特別な方法でシリアル化する機能）を満たしながらオブジェクトを含めることができることです。 同時に、これらの要件には、オブジェクトの構造、特別なデータ型の使用などに関する制限は含まれていません。
後者の状況は、コレクションおよびコレクションに個別にリンクされたクラスも操作する、よく知られた
SQLAlchemyライブラリーを含むCoRMのアプローチを区別します。
コレクションの要素間の関係は、コレクションに含まれるオブジェクトの選択されたプロパティ、属性、または決定論的メソッドの存在と内容（戻り値）によって決定されます。 このような強調表示されたプロパティは、コレクション
インデックスと呼ばれ
ます 。 したがって、コレクションとそのインデックスは、インデックス値を提供するオブジェクト指向プログラミングパラダイムと、取得したインデックス値を使用して格納されたオブジェクト間の関係を確立するSQLリポジトリリレーショナルパラダイムとの間のリンクです。
図3コレクションとそのインデックスは、オブジェクトとリレーショナルデータモデル間のリンクですリレーショナルパラダイムをさらに深く見ていくと
、コレクションの
キーの概念を定義できます。各コンセプトは、このコレクションのインデックスの組み合わせを参照し、この組み合わせの追加の最適化と制限的なプロパティ、たとえばコレクション内のキー値の一意性を定義します。
テーブルの外部キーが別のテーブル
との関係を確立するの
と同じように、個々のコレクションキーは、別のコレクションに格納されているオブジェクトにアクセスするための
外部キーとして機能します。 リレーショナルDBMSの外部キーとまったく同じ方法で、コレクションのリレーショナル表示の外部キーを使用して、外部キーのターゲットのどのキー値とも一致しない外部キー値の保存を禁止することにより、データの整合性を維持できます。コレクション。
コレクション間の関係関係を実際に使用する可能性は、コレクションに関連付けられたテーブルを1つのデータベースに配置することで決まります。 プログラマーにとってのこの事実の反映は、データベースへの接続の詳細とDBMSの一般的な構造的および機能的特性を決定する特別なストレージオブジェクト（ストレージ）の存在であり、このデータベースに含まれるテーブルへのコレクションへのアクセスポイントも含みます。
式のフィルタリング、グループ化、順序付けのデータサンプリングのコレクションに目を向けると、プログラマはコレクションに格納されているオブジェクトのプロパティを操作せず、値をインデックス付けして、オブジェクトのリストまたはオブジェクトと追加の計算式で構成されるタプルのリストを作成しますコレクションインデックス値）。 オブジェクト自体は、クエリ結果の受信時にデシリアライズされるまで、コレクション内に完全にカプセル化されたままになります。
コレクション内にオブジェクトをカプセル化し、リレーショナルストレージ側から（オブジェクトの状態ではなく）利用可能なインデックスからオブジェクトの格納状態を分離すると、式（フィルタリング、グループ化、追加の戻り値の計算および順序付け）を使用されたオブジェクトの式にマッピングする無意味な試みが行われますたとえばSQLAlchemyで発生する言語（この場合はpython）。 代わりに、コレクションからの選択に対するクエリは、たとえば
Google App Engine Datastoreを使用して行われるように、構造的にSQLにできるだけ近い言語で定式化できます。 Google Datastoreコレクションにアクセスする際に使用される
GQL言語は、CoRMを使用してコレクションからデータを取得するために使用できる言語のほぼ最適なモデルです（もちろん、実装によってこの言語に課される奇妙な制限を除きます）。 言語式の名前は、明らかに、コレクションで定義されたインデックスとキーを参照する必要があり、リレーショナルストレージから隠されている保存されたオブジェクトの属性を参照するべきではありません。
コレクションのクエリ構文をオブジェクト言語の構文を超えて使用すると、ターゲットストレージのコンパイル済みクエリの予備コンパイルとキャッシュが可能になり、受信データからオブジェクトを逆シリアル化する可能性が残ります。コレクション内のオブジェクトへのアクセスを最適化するという問題は、一般的に言えば、既存のORMにとってはかなり苦痛です）。
興味深い追加は、コレクションインデックスのカプセル化と個別のエンティティとしての割り当てにより、特に、オブジェクトの格納状態の属性に値が直接含まれず、それらから明確に計算される動的インデックスの実装が容易になることです。
出力の代わりに
コレクションのリレーショナルマッピングを実装すると、既存のORM実装の優れた代替手段となり、リレーショナルストレージの制約からアプリケーションエンティティを削除できます。
注意、質問：