« プログラミングは前後の工程を侵襲しつつ変化してゆく | トップページ | 企業システムに現れるフラクタル構造 »

2011.05.08

「仮想DB」としての開発用プラットフォーム

 XEAD Driverの次のリリース(V1R1)の眼目が「仮想データベース」だ。

 「仮想データベース」が何かを説明する前に「仮想フィールド」を確認しておこう。たとえば受注テーブル上に「受注数」と「受注単価」のフィールドがあれば、それらを掛け合わせた「受注金額」を「仮想フィールド」とみなせる。物理的には存在しないのだが、一定の導出手順をテーブルに教えておくことで、あたかも受注テーブル上のフィールドであるかのようにプログラムで扱えるようになる。そのような考え方は昔からあって、XEAD Driverでも装備されている。

 では「仮想データベース」というものがあるとしたらどんなものだろう。いわゆる「ビュー」はある種の「仮想テーブル」と呼べそうだが、私がここで問題にしようとしているものはテーブルではなく、いくつかのテーブルを含む「データベース」の仮想化である。

 たとえば、Oracleで作ったデータベース上に「商品テーブル」があるとする。さらに、SQL Serverの「在庫テーブル」と「受注テーブル」、PostgreSQLの「得意先テーブル」があるとする。要するに、開発しようとしている「受注エントリー」あたりのアプリケーションに関係するテーブル群が、何かの事情で異種データベースに散らばっている状況だとする。

 多くの場合、それらの一部を定期的にリプリケーションして単一のデータベースにまとめることで対処する。異なるデータベースは運用方法も違うだろうから、それはそれで無難なやり方ではある。

 しかし、煩雑なレプリケーション方式を避けたいこともある。そんなとき開発用プラットフォームに、それらのテーブル群を論理的な単一データベースにまとめるための機構があれば都合がいい(下図)。それがここでいう「仮想データベース」だ。「仮想フィールド」がそうであるように、「仮想データベース」は物理的に存在するわけではないが、開発者にそうであるかのように見せてくれる。

Virtualdb_2

 もちろん従来においても、異種データベース上のテーブル群を組み合わせて結合やトランザクション等の処理を行うことは可能ではあったが、コードが複雑にならざるを得なかった。もし異種データベースへの接続を開発用プラットフォームに委譲できれば、アプリの開発者はテーブルがどのデータベース上に構築されているかを考える必要がなくなる(*1)。

 では、なぜXEAD Driverでそのようなことができてしまうのかというと、データベースの「上っ面」しか使っていないためだ。具体的には、プラットフォーム内部で発行されるSQLにおいては、JOIN句を使わずにカーソル操作を用いた結合ロジックに徹している。また、SQLのエラーメッセージに頼らず、プラットフォーム上のテーブル定義にもとづいてテーブル間の整合性をチェックしている。さらに、ストアドプロシージャやトリガーイベントを監視するための機構をプラットフォーム上に持っている。

 それゆえに、現時点のXEAD DriverはJavaDB(Derby)だけに対応しているが、他のDBMSにも対応しやすいし、対応すればそれらが混在してもかまわない。当初からそれを狙っていたわけではないのだが、あるときに「仮想データベース」を提供する基盤としてXEAD Driverを容易に改善できることに気づいた次第だ。しかし考えてみれば、この役割は開発用プラットフォームがあたりまえに担うべきものであって、リリースアップの眼目などと威張るほどの話ではないのだが。

*1.とはいえ自由自在というわけにもいかない。分散トランザクションの問題を避けるために、更新用DBをひとつだけに限定するといった制約は要るだろう(上記の例ではSQL Serverが更新用DBとして選択されている)。そもそも特殊なアプリでない限り、複数DBに渡って更新が必要だとしたら、前提となるDB編成がまともとはいえない。

|

« プログラミングは前後の工程を侵襲しつつ変化してゆく | トップページ | 企業システムに現れるフラクタル構造 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「仮想DB」としての開発用プラットフォーム:

« プログラミングは前後の工程を侵襲しつつ変化してゆく | トップページ | 企業システムに現れるフラクタル構造 »