オブジェクトリレーショナルマッピング

コンピュータサイエンスにおけるオブジェクト・リレーショナル・マッピング（ORM、O/RM、O/Rマッピングツール）は、リレーショナルデータベースとオブジェクト指向プログラミング言語のメモリ（通常はヒープ）間でデータを変換するプログラミング手法です。これにより、プログラム内から使用できる 仮想オブジェクトデータベースが実質的に作成されます。

オブジェクト指向プログラミングでは、データ管理タスクは、スカラー値をオブジェクトに結合するオブジェクトに対して実行されます。例えば、1人の人物と0個以上の電話番号、そして0個以上の住所を表すアドレス帳のエントリを考えてみましょう。これは、オブジェクト指向実装では、エントリを構成する各データ項目（人物の名前、電話番号リスト、住所リスト）を保持する属性/フィールドを持つ「Personオブジェクト」としてモデル化できます。電話番号リスト自体には、「PhoneNumberオブジェクト」などが含まれます。このようなアドレス帳の各エントリは、プログラミング言語によって単一のオブジェクトとして扱われます（例えば、オブジェクトへのポインタを含む単一の変数によって参照できます）。オブジェクトには、優先電話番号や自宅住所などを返すメソッドなど、様々なメソッドを関連付けることができます。

対照的に、 SQLなどのリレーショナル データベースは、スカラーをタプルにグループ化し、タプルをテーブルに列挙します。タプルとオブジェクトには、コレクション全体を単一の複合エンティティとして操作できるように、値を名前付きフィールドに収集する方法であるという点で、一般的な類似点があります。ただし、ライフサイクル管理 (行の挿入と削除 vs.ガベージ コレクションまたは参照カウント)、他のエンティティへの参照 (オブジェクト参照 vs. 外部キー参照)、継承 (リレーショナル データベースには存在しない) など、多くの違いがあります。また、オブジェクトはヒープ上で管理され、単一のプロセスによって完全に制御されますが、データベース タプルは共有され、ロック、マージ、再試行を組み込む必要があります。オブジェクト リレーショナル マッピングは、これらの違いをすべて考慮しながら、タプルからオブジェクトへのマッピングとその逆のマッピングを自動的にサポートします。[ 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形式との間でデータを変換する必要がなくなります。ドキュメント指向データベースにおけるORMに相当するものは、オブジェクト・ドキュメント・マッパー（ODM）と呼ばれます。

ドキュメント指向データベースでは、ユーザーがオブジェクトをテーブル行に「細分化」する必要もありません。これらのシステムの多くは、データセットを取得するためのXQueryクエリ言語もサポートしています。

オブジェクト指向データベースは、複雑でニッチなアプリケーションで使用される傾向があります。OODBMSの使用に反対する理由の一つは、アプリケーションに依存しないアドホックなクエリを実行できない可能性があることです。そのため、多くのプログラマーは、ほとんどのオブジェクト指向データベースが限られた範囲でSQLクエリを処理できるにもかかわらず、オブジェクトとSQLのマッピングシステムの方が使いやすいと感じています。他のOODBMSは、よく知られたクエリパターンを維持しながらアドホックなクエリのニーズに対応する手段として、SQLデータベースへのレプリケーション機能を提供しています。

課題

オブジェクトシステムをリレーショナルデータベースにどのように適合させるかを考える際には、様々な困難が生じます。これらの困難は、オブジェクト・リレーショナル・インピーダンス・ミスマッチと呼ばれます。[ 3 ]

ORMを実装する代わりに、主要なデータベースに付属するネイティブ手続き型言語を使用する方法があります。これらの言語は、クライアントからSQL文を使って呼び出すことができます。データアクセスオブジェクト（DAO）設計パターンは、これらの文を抽象化し、アプリケーションの残りの部分に軽量なオブジェクト指向インターフェースを提供するために使用されます。[ 4 ]

ORMは定義済みの機能に制限されており、すべてのエッジケースやデータベース機能をカバーしていない可能性があります。通常、 Django ORMのように、生のクエリを記述するためのインターフェースをユーザーに提供することで、この制限を軽減しています。[ 5 ]

参照

参考文献

  1. ^ a b「オブジェクト/リレーショナルマッピングとは？」 Hibernateの概要JBOSS Hibernate 2022年1月27日閲覧。
  2. ^ Barry, D., Stanienda, T. (1998). 「Javaオブジェクトの保存問題の解決」 . Computer . 31 (11). Institute of Electrical and Electronics Engineers (IEEE): 33– 40. doi : 10.1109/2.730734 .この演習では、ODMG Javaバインディングを使用した場合は496行のコードが必要でしたが、JDBCを使用した場合は1,923行のコードで済みました。
  3. ^オブジェクト・リレーショナル・マッピングの再考 ― データベース技術がO/Rマッピング戦略に与える影響に関する定量的研究。M Lorenz、JP Rudolph、G Hesse、M Uflacker、H Plattner。ハワイ国際システム科学会議（HICSS）、4877-4886 (DOI:10.24251/hicss.2017.592)
  4. ^ Feuerstein, Steven; Bill Pribyl (1997年9月). 「Oracle PL/SQLプログラミング」 . 18.5 永続オブジェクトの変更. 2011年8月23日閲覧。{{cite web}}: CS1 メンテナンス: 場所 (リンク)
  5. ^ 「生のSQLクエリを実行する | Djangoドキュメント」Djangoプロジェクト. 2024年9月8日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Object–relational_mapping&oldid=1333501321」より取得