Loading article…
コンピュータサイエンスにおけるオブジェクトリレーショナルマッピング（ORM、O/RM、O/Rマッピングツール）とは、リレーショナルデータベースとオブジェクト指向プログラミング言語のメモリ（通常はヒープ）との間でデータを変換するためのプログラミング手法です。これにより、プログラム内から使用できる仮想オブジェクトデータベースが実質的に作成されます。
オブジェクト指向プログラミングでは、データ管理タスクは、スカラー値をオブジェクトに組み合わせたオブジェクトに対して実行されます。たとえば、1人の人物と0個以上の電話番号、0個以上の住所を表すアドレス帳エントリを考えてみましょう。オブジェクト指向の実装では、これは「Personオブジェクト」としてモデル化できます。Personオブジェクトには、エントリを構成する各データ項目（人物の名前、電話番号のリスト、住所のリスト）を保持する属性/フィールドがあります。電話番号のリスト自体には「PhoneNumberオブジェクト」などが含まれ、以下同様です。このようなアドレス帳エントリは、プログラミング言語によって単一のオブジェクトとして扱われます（たとえば、オブジェクトへのポインタを含む単一の変数で参照できます）。オブジェクトには、優先電話番号や自宅住所などを返すメソッドなど、さまざまなメソッドを関連付けることができます。
対照的に、 SQLなどのリレーショナル データベースでは、スカラーをタプルにグループ化し、それをテーブルに列挙します。タプルとオブジェクトには、値を名前付きフィールドに収集して、コレクション全体を単一の複合エンティティとして操作できるという点で、一般的な類似性があります。ただし、ライフサイクル管理（行の挿入と削除、ガベージ コレクションまたは参照カウント）、他のエンティティへの参照（オブジェクト参照、外部キー参照）、および継承（リレーショナル データベースには存在しない）など、多くの違いがあります。また、オブジェクトはヒープ上で管理され、単一のプロセスによって完全に制御されますが、データベースのタプルは共有され、ロック、マージ、および再試行を組み込む必要があります。オブジェクトリレーショナル マッピングは、これらのすべての違いを考慮しながら、タプルをオブジェクトにマッピングしたり、オブジェクトからタプルにマッピングしたりするための自動化されたサポートを提供します。[ 1 ]
問題の核心は、オブジェクトの論理表現を、オブジェクトのプロパティとそれらの関係性を保持したままデータベースに保存できる原子化された形式に変換し、必要に応じてオブジェクトとして再ロードできるようにすることです。この保存および取得機能が実装されると、オブジェクトは永続的であると言われます。[ 1 ]
ストレージドライバの実装固有の詳細は、一般的に使用されているプログラミング言語のAPIにラップされており、ストレージメディアとやり取りするためのメソッドを、よりシンプルで周囲のコードのパラダイムに沿った形で公開しています。
以下は、データベースエンジンを使用してSQLで記述されたクエリを実行する、C#コードで書かれた簡単な例です。
System.Collections.Genericを使用します。string sql = "SELECT id, first_name, last_name, phone, birth_date, sex, age FROM persons WHERE id = 10" ; List < Person > result = context . Persons . FromSqlRaw ( sql ). ToList (); string name = result [ 0 ][ "first_name" ];それに対し、以下ではORMジョブAPIを利用することで、言語の機能を自然に活用するコードを記述することが可能になります。
Person person = repository.GetPerson ( 10 ) ; string firstName = person.GetFirstName ( ) ;上記の例では、ストレージリポジトリを表すオブジェクトとそのオブジェクトのメソッドを使用しています。他のフレームワークでは、以下の例のように静的メソッドとしてコードを提供する場合もありますが、オブジェクト指向システムを全く実装しないメソッドもあります。多くの場合、ORMが周囲の言語の設計原則に最も適合するようにパラダイムが選択されます。
Person person = Person.Get ( 10 ) ;オブジェクト指向言語とリレーショナルデータベース間の従来の交換手法と比較して、ORMは記述する必要のあるコード量を削減することが多い。[ 2 ]
ORMツールの欠点は一般的に、抽象化レベルが高すぎるために、実装コードで実際に何が起こっているのかが分かりにくくなることに起因する。
別の方法として、オブジェクト指向データベース管理システム（OODBMS）や、データモデリングの柔軟性を高めるネイティブXMLデータベースなどのドキュメント指向データベースを使用する方法があります。OODBMSは、オブジェクト指向の値を扱うために特別に設計されたデータベースです。OODBMSを使用すると、データは元のオブジェクト表現で格納され、結合テーブルや操作を必要とせずにリレーションシップが直接表現されるため、データをSQL形式に変換したり、SQL形式から変換したりする必要がなくなります。ドキュメント指向データベースにおけるORMに相当するものは、オブジェクト・ドキュメント・マッパー（ODM）と呼ばれます。
ドキュメント指向データベースは、ユーザーがオブジェクトをテーブルの行に「分割」する必要性をなくします。これらのシステムの多くは、データセットを取得するためのXQueryクエリ言語もサポートしています。
オブジェクト指向データベースは、複雑でニッチなアプリケーションで使用される傾向があります。OODBMSの使用に対する反対意見の一つは、アドホックな、アプリケーションに依存しないクエリを実行できない可能性があることです。そのため、多くのプログラマーは、オブジェクト指向データベースの多くが限定的ながらSQLクエリを処理できるにもかかわらず、オブジェクト-SQLマッピングシステムの方が使いやすいと感じています。また、他のOODBMSは、既知のクエリパターンを維持しながらアドホッククエリのニーズに対応する手段として、SQLデータベースへのレプリケーションを提供しています。
オブジェクトシステムをリレーショナルデータベースに適合させる方法を検討する際には、さまざまな困難が生じます。これらの困難は、オブジェクトとリレーショナルのインピーダンスミスマッチと呼ばれます。[ 3 ]
ORMを実装する代替手段として、主要なデータベースに付属するネイティブの手続き型言語を使用する方法があります。これらは、SQL文を使用してクライアントから呼び出すことができます。データアクセスオブジェクト（DAO）デザインパターンは、これらの文を抽象化し、アプリケーションの他の部分に軽量なオブジェクト指向インターフェースを提供するために使用されます。[ 4 ]
ORMは、定義済みの機能に限定されており、すべてのエッジケースやデータベース機能を網羅しているとは限りません。通常、 Django ORMのように、生のクエリを記述するためのインターフェースをユーザーに提供することで、この制限を軽減しています。[ 5 ]
この演習では、ODMG Javaバインディングを使用した場合496行のコードが必要でしたが、JDBCを使用した場合は1,923行のコードが必要でした。
{{cite web}}: CS1メンテナンス: 場所 (リンク)