top / index / prev / next / target / source
日記形式でつづる いがぴょんコラム ウェブページです。
blancoDb EE概要の説明文を書きました。関連して R/Oマッピングツール定義を記載しました。
blancoDb Enterprise Edition概要の説明文を更新しました。併せて R/Oマッピングツール定義について改めて記載しました。これをスナップショットとして日記の方に転載しておきます。基本的に、更新はblancoDbホームページ側に対してのみ行っていきます。
比較して特徴を書いてみると、「低機能」・「自由度の低さ」などという刺激的な用語が並びました。未来からこの日記を振り返ったら刺激は感じないかも知れませんね。でも、この日記を書いている時点での一般通念としては、ソフトウェアは高機能で自由度が高いもののほうが良いとされているのです。「低機能」・「自由度の低さ」には価値があるというパラダイムシフトをここで考えています。このパラダイムシフトについては、ある程度解説を加えないと 一般の方々には理解いただけないかも知れませんね。
私は 次世代オープンソース・ミドルウェアは 「低機能」・「自由度の低さ」・「カスタマイズ性」という特徴が重要な仕様のひとつとなっていくものと考えています。ミドルウェアは高水準なものと低水準なものに二極化が進んでいくことでしょう。これは EclipseのGUI基盤である SWTとJFaceから 改めて概念の着想を得ました。(blancoDbそのものは、前身のソフトも含めると前世紀から一貫して同じ指向を持っています) SWTは極めて低機能で自由度が低く、クラスとしてラッピングも薄っぺらいものです。反して JFaceは高機能で自由度が高く、クラスとして一般的なGUI部品としてのラッピングを行っています。Eclipseは SWTとJFaceという二極化されたオープンソース・ミドルウェアによって初めて実現されています。ここで大事なことは、低水準APIというものに非常に価値があるということです。(高水準APIの価値は敢えて説明しなくてもわかってもらえることが現時点では多いです) 低水準APIを薄っぺらくラッピングして低機能であり続け、自由度を低く設定し (例えば、SWTは継承が許されません)、とても高性能に動作することが出来ます。これがJFaceだけでモノリシックに実装されていたら、Eclipseはあのように高速には動作しなかったことでしょう。
リレーショナルデータベースについても、SWTのような低水準APIが必要なのです。かといって 単純にJDBC APIだけでは不足する面もあるものと考えます。一方で SQL文は Java言語のようなノイマン型プログラミング言語とはかなり異質な、集合代数を扱う言語です。SQL文とJDBC APIとJavaソースコードとを適切に結びつけるための低水準APIが、今のリレーショナルデータベースプログラミングに不足しているものの一つであると考えているのです。blancoDbはそういう低水準APIという仕様を満たしているように考えています。
関連する日記
blancoDb Enterprise Edition (以降 blancoDb)は Java言語/JDBC用の R/Oマッピングツール実装の一つです。
理念・思想
blancoDbは下記のような理念および思想を特徴としています。
低機能でありつづける JDBCドライバが提供する低水準APIの機能性・特徴を妨害・阻害することなく、そのままJavaソースコードにマッピングします。このことにより、リレーショナルデータベースの機能および性能を最大限引き出すことが出来ます。ツールとしては低機能であることにより、高性能に動作させることができ、またJDBCの機能を最大限利用することができます。もちろんスクロールカーソルやNULL許容列対応など最低限の機能は当然サポートします。
自由度の低さ リレーショナルデータベース上の型をJavaの特定のオブジェクト型に強制的にマッピングを行います。型マップに関しては極力自由度を排除しています。このことによりJDBCドライバの実装に起因したJDBCレベルでの型マッピングによる不具合発生を最小限にとどめることが出来ます。加えて自由度が低いために 極めて少ない設定によりマッピングを自動生成することができます。原則として列名や型情報はJDBCドライバから得られるメタ情報を活用して自動的に決定します。自由度の低さゆえに非常に安全に動作させることもできます。多くの場合 自由度の高さは設定を増やして不確実性を押し上げ、各種トラブルを誘発するのです。
カスタマイズの容易さ (現バージョンでは 未達部分が含まれる) カスタマイズの容易さを理念としています。基幹系・大規模開発で利用される際にはカスタマイズが発生することでしょう。生成されるソースコードにいろいろ手が加わるのはもちろんのこと、blancoDbのソースコードそのものにもカスタマイズが入ることを想定しています。そういったカスタマイズのしやすさを実現するための方法として、機能を増加させず自由度を増やさずblancoDbそのものの規模の肥大化を抑制している側面もあります。blancoDbの規模が小さいことはカスタマイズ実施後のテスト規模を抑制することも出来ます。
特徴
ごく普通のSQL文が そのまま利用できます。 ターゲットRDB向けに準備されたSQL文が そのまま利用できます。当然のことですが、複数表を結合した検索が可能です。ある程度複雑なサブクエリやUNION付きSQL文なども、あたりまえのことですが、ごく当然のものとして利用できます。SQL文という観点では blancoDbは極めて自由度が高くなるよう設計されています。
ごく普通にJDBC APIをラッピングしています。 ごく普通の JDBCプログラミング・ソースコードを自動生成するため、既存のJDBCノウハウおよびスキルが転用でき、学習コストがとても低いです。
よくありがちなJDBCプログラミングにおけるバグを予防するための仕組みをもっています。
一意制約違反は特別な例外として扱うことにより、一意制約違反の処理忘れバグを予防できます。
検索・実行結果が1件であるSQL文について、実行結果が1件でない場合には例外を発生させることよにり処理忘れバグを予防できます。
ステートメントのクローズ忘れについて、これを検知して警告を出すことによりクローズ忘れバグを予防できます。
リレーショナルデータベースのカーソルが利用できます。
(リレーショナルデータベースがサポートしていれば) FOR UPDATEを伴った行ロックを伴った検索および行の更新が可能です。
実行時に特別なクラスライブラリを必要としません。生成したソースコードだけで完結して動作します。またソースコード自動生成時に 解決可能なものは最大限解決を済ませます。このことにより実行時コストを極小化することが実現できます。
基幹系システム開発に対応しています。 基幹系システム開発における一般的な開発プロセスに沿った形で設計および実装されています。
下記の仕様を満たしているものが R/Oマッピングツールの仕様を満たしているものと定義します。
ANSI SQL (ごくあたりまえのSQL文) が利用できること。
リレーショナルデータベース上の型を強制的に オブジェクトの型にマッピングを行うこと。型に関する設定が少ないこと。
リレーショナルデータベースが持つ機能を阻害しないこと。
リレーショナルデータベースが持つ性能を阻害しないこと。
リレーショナルデータベースのカーソルが利用できること。
トランザクション分離レベルを適切に扱うことが出来ること。
トランザクションのコミットとロールバックを任意のタイミングで呼び出すことが出来ること。
NULL許容列を適切に扱うことができること。
ストアドプロシージャ呼び出しに対応していること。
意外なことですが、世の O/Rマッピングツールの多くは 上記とは逆の指向性を持っています。ツールとしては高機能である反面、リレーショナルデータベースの機能や性能を大きく損なっているというものが多く存在します。R/OマッピングはリレーショナルデータベースおよびSQLを中心としたアプローチをとります。