O/R マッピング

インピーダンスミスマッチ

アプリケーション開発で取り入れられている オブジェクト指向 の概念と リレーショナルデータベースで取り入れられている データ指向 の概念には思想上の違いがあります。アプリケーション開発者がリレーショナルデータベースに詳しくないことも多く、データベースアプリケーション開発ではこの思想の違いが大きな隔たりになります。 そのためこの思想の違いを特に「インピーダンス・ミスマッチ」などとも呼ばれています。

これらインピーダンス・ミスマッチを吸収し、アプリケーション開発者からリレーショナルデータベースの世界を隠蔽することで、アプリケーション開発の効率を上げようと考え出されたのが O/Rマッピング という技術です。

O/R マッピング

O/Rマッピング とは Object / Relational マッピング の略です。 オブジェクト指向の概念とリレーショナルデータベースの概念をマッピングすることで、アプリケーション開発者は、通常のオブジェクトにアクセスする感覚でリレーショナルデータベースにアクセスできる様になります。 O/R マッピングフレームワークで有名どころと言えば、 Hibernate か Trque でしょうか。Cayenne という新しいフレームワークもある様です。これらの細かい仕様を知っているわけではありませんが、 O/R マッピング フレームワークを使用すれば、テーブル構造をオブジェクトと見なしてアクセスできるだけでなく、トランザクションの管理すらも意識せずに済むため開発者はアプリケーション開発に専念できるようになるという訳です。

O/R マッピングへの疑問

異なる思想の違いを吸収してしまって問題ないのか

世間ではO/R マッピングが流行っている様ですが、個人的には疑問です。 O/R マッピングでインピーダンス・ミスマッチを吸収するとは言いますが、そもそも思想の違う２種類の概念を１つにまとめてしまって大丈夫なのでしょうか。 O/R マッピングはアプリケーション側に主眼をおいているため、異なる概念をまとめる行為はリレーショナルデータベース独自の思想を消してしまうのではないかと思います。

O/R マッピングフレームワーク Hibernate の感想

Hibernate に軽くふれたことがあるのですがやはり疑問は残りました。O/R マッピングを利用するには、リレーショナルデータベースのテーブルと対応させたマッピングオブジェクトを作成します。このマッピングオブジェクト作ることは自動生成ツールで簡単にできるのですが、テーブル列に相当するフィールドを持ったオブジェクトが作成されるだけなので、テーブル定義を見なくてもテーブルの列がわかるくらいの利点しか感じませんでした。テーブルを変更した場合もマッピングオブジェクトを作り直したり、その結果呼び出しもともリファクタリングしなければなりません。不整合はコンパイルエラーで知らせてくれるからわかりやすいとは思いますが・。

データ問い合わせやトランザクション制御といったリレーショナルデータベース特有の機能もサポートされていましたが、アプリケーション開発から切り離したいがために Hibernate フレームワークが肩代わりする仕組みになっています。 このデータ問い合わせやトランザクションといったデータ制御の重要な部分が隠蔽されているために、Hibernate に不慣れな開発者はデータの更新がうまくいかないという問題を抱えることになりがちです。結局 Hibernate という固有のプロジェクト知識に加えてデータベースの知識も必要になるのではと感じました。それなら隠蔽する意味はかなり薄くなると思います。

O/R マッピングを利用するなら・・

O/R マッピングフレームワークを利用することで、SQL文 を覚える手間が省けたり、トランザクションルールを決めたりはしやすくなるとは思いますが、重要な部分を隠蔽してしまうので、フレームワークではなくデータベース管理のライブラリを整備するなどしてデータ問い合わせやトランザクション制御へのアクセスを簡単にした方がいいと思います。

アプリケーション開発者はそのライブラリを仕様して、明示的にここからここまでがトランザクション管理の対象で、ここでデータを更新するみたいに明示的に実装した方が、機能の流れも明確になる上、予想しない不具合が発生したりする可能性を少なくすることができると思います。