オブジェクトリレーショナルマッピング（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実装の優れた代替手段となり、リレーショナルストレージの制約からアプリケーションエンティティを削除できます。
注意、質問：