|
オブジェクト関係マッピングオブジェクト関係マッピング（英: Object-relational mapping, O/RM, ORM）とは、データベースとオブジェクト指向プログラミング言語の間の非互換なデータを変換するプログラミング技法である。オブジェクト関連マッピングとも呼ぶ。実際には、オブジェクト指向言語から使える「仮想」オブジェクトデータベースを構築する手法である。オブジェクト関係マッピングを行うソフトウェアパッケージは商用のものもフリーなものもあるが、場合によっては独自に開発することもある。 背景オブジェクト指向プログラミングでは、データ管理タスクは一般に単純なスカラー[要曖昧さ回避]ではない値を持つオブジェクトを操作するよう実装される。例として、1人の人物に0個以上の電話番号と0個以上の住所が対応している住所録での住所検索を考えてみよう。オブジェクト指向的な実装では、「人物オブジェクト」に住所録の内容を格納する「スロット」が備わっているような形態でモデル化される。スロットとしては、氏名、電話番号のリスト（または配列）、住所のリストが考えられる。電話番号リストは「電話番号オブジェクト」で構成され、他も同様に対応するオブジェクトで表される。プログラミング言語からは、ある人物の住所録がひとつの値として扱われる（例えば、1つの変数で参照される）。このオブジェクトに対して、推奨電話番号を返すメソッド、自宅電話番号を返すメソッド、などの各種メソッドが関連付けられる。 しかし、データベース言語SQLを使った一般的なデータベース製品では、格納し操作できるのはスカラー値（整数、文字列）だけであり、スカラー値による表を形成している。 プログラマは、オブジェクトをデータベースに格納可能な単純な値のグループに変換するか、プログラムをデータベースに合わせて単純な値だけを扱うようにしなければならない。オブジェクト関係マッピングは前者の手法を実装するものである。 この問題の要点は、オブジェクトをデータベースに格納可能な形式に変換し、後で容易に検索できるようにし、同時にオブジェクト同士の関係の特性を保持する点である。このようなオブジェクトを永続的であるという。 実装最も一般的なデータベースはデータベース言語SQLを使った関係データベースであり、これらは1990年代のオブジェクト指向プログラミングの隆盛以前に既に一般化していた。関係データベースは表という概念でデータを格納する。異なる関係 (表) に存在するデータ間の関連は宣言的制約によって示され、具体的なポインタやリンクは存在しない。オブジェクト指向なら同じデータは1つのオブジェクトに格納されるが、関係データベースでは必要に応じて複数の関係 (表) に格納される。 オブジェクト関係マッピングの実装は体系的かつ予測可能な手法で表を選択し、必要なSQLを生成する。 オブジェクト関係マッピングを開発する際の手間を削減するために様々なパッケージが提供されてきており、これらはマッピングを自動で行うクラス群のライブラリのような形態となっている。データベース内の関係 (表) のリストを与えると、自動的に要求をマッピングする。人物オブジェクトに電話番号を問い合わせると、適切なクエリが生成されて送られ、結果が直接電話番号オブジェクトに格納されるようプログラムされる[1]。 プログラマからすれば、システムは永続的なオブジェクト保管所のように見える。オブジェクトを新たに生成して適切な処理をすると、最終的にそれがデータベースに自動的に保存される。 しかし実際のところ、話はそう単純ではない。全てのオブジェクト関係マッピング (O/RM) システムは全く見えないように働くわけではなく、ある程度データベースを意識せざるを得ない。さらに変換層は遅くて機能が不十分な場合もあり（特に生成するSQLの質の面で問題が多い）、結果としてプログラムの性能が低下し、メモリを余分に消費する。 全てのオブジェクト関係マッピング (O/RM) システムは各種開発されてきたが、その市場への影響は様々である。NeXT の Enterprise Objects Framework (EOF) は優れた製品だったが、OPENSTEP上でしか動作できなかったため、市場への影響はほとんどなかった。これは後に NeXT のオブジェクト指向アプリケーションサーバ WebObjects に統合された。1997年、Apple Computerは NeXT を買収し、同社の電子商取引サイトである .Mac サービスや ITunes Store に EOF の技術が使われることになった。アップルは EOF を二種類の実装で提供している。1つはmacOS上で稼働するCore Data、もう1つは WebObjects 5.2 の Pure Java 実装である。EOF に着想を得て開発されたのが、オープンソースの Apache Cayenne である。Cayenne は EOF と似ており、JPA standard に準拠している。 他の手法として RDF や SPARQL がある。RDF は主語-述語-目的語のトリプルによるシリアライズであり、RDF/XML はそのXML表現、SPARQL は RDF 用のSQL的クエリ言語である。このトリプルでやりとりできるデータベースをトリプルストア (triplestore) と呼ぶ。 その後、Java関連で新たな類似のシステムが Java Data Objects (JDO) として登場した。EOF とは異なり、JDO は標準規格であり、いくつかのベンダーから実装したものが登場している。Enterprise JavaBeans 3.0 (EJB3) も同様の分野をカバーしている。両者の間で標準規格としての競合状態が発生した。他にも Java 関連でよく使われているオブジェクト関係マッピングとして Hibernate がある。 Webフレームワーク Ruby on Rails では、オブジェクト関係マッピングが中心的役割を果たしており、Active Recordのデザインパターンを使って制御される。同様に Perl の Catalyst では DBIx::Class モジュールが同じような役割を果たしているが、他にも選択肢は存在する。 非SQLデータベースCachéのようなデータベースではオブジェクト関係マッピング (ORM) を必要としない。スカラー[要曖昧さ回避]値以外へのSQLアクセスが組み込まれているためである。Caché では任意のオブジェクト指向プログラミング言語と組合わせて利用可能で、その際に外部ツールによる補助を必要としない。 他の解決策としてオブジェクトデータベースを使う。これは名前が示す通り、もともとオブジェクト指向で利用されることを目的に設計された。オブジェクトデータベースでは、オブジェクトがそのまま格納されるので、SQLを生成するなどの変換の手間は不要である。 オブジェクトデータベースは広く利用されるには至っていない。その主な要因として、関係データベースからオブジェクトデータベースに乗り換えるコストと、SQLによる簡便なクエリができなくなる点が挙げられる。このため、商用のオブジェクトデータベースはある程度SQL経由で利用できるようになっているにもかかわらず、オブジェクト関係マッピングの利用を選択することが多い。 批評オブジェクト関係マッピングは、オブジェクト指向と関係モデルのインピーダンス・ミスマッチ問題の対症療法にすぎないとも言われている。関係データベースの原則から見れば、オブジェクト指向はデータ操作には不十分であり、パラダイム全体として問題がある。現状のオブジェクト関係マッピングのマッピングは間違っているとも言われ、正しくは型 (定義域) とオブジェクトを対応させるべきとも言われている。 関連項目脚注外部リンク
|