リレーショナル・データベースの専用言語 SQL は、よくできた言語だとつくづくよく思っています。わたしは SQL92 というバージョンからおつきあいしています。

ただ、SQL は、他のプログラム言語と親和しにくいと感じられることがしばしばです。これまでに多くのプログラムインターフェースが登場してきましたが、正規化ルールにしたがって、実際のデータ群を分解してテーブルに Insert、Update する。トランザクションを制御する。Select では、非正規化された大量のデータをすべて変数（あるいはフィールド）に写す（あるいはマッピングしておく）など、これらのプログラミング上の煩雑さは大きなままです。

また、リレーショナル・データベースのカラム変更の容易さに比べて、プログラム対応は煩雑となることがしばしばです。

わたしは、だいぶ以前のことですが、EXCEL でデータベースのカラムを定義しておいて、マクロでテーブル定義の SQL 文を出力し、C 言語向けにカラムと対応した構造体と変数を出力するといったようなものを作ったことがありましたが、その効果は限定的でした。その当時は、データフォーマットの調整や、データの変数コピーの煩雑さ、そして、Insert、Update よりも Select の非正規化データの処理のプログラミングなどの煩雑さなどを解決できなかったことを思い出します。

 

さて、今は、オブジェクト指向設計・実装が主流ですから、クラス設計・実装において、このようなリレーショナル・データベースに対するプログラミングの煩雑さをどうやって軽減するか、プロジェクトのたびによく問題にあがることでした。特に非正規化の Select は、複数エンティティのリレーションによって発生し、その条件も内容も流動しやすく、プロセスごとに非正規化を考えると似たような SQL 文が多数発生しやすくなる、といったようなことをふまえて、どのようにクラス設計にするかが問題の中心となることも多かったと思います。

そして、プログラミングにおいては、SQL 文のコーデイング、カラムとフィールドの対応、条件の設定など、単純ではありますが、システムが大きいほどカラムも SQL 文も多くなり、そのコーディング量は膨大となり、単純ミスも発生しやすい作業でした。

 

O/R マッピングは、このようなプログラミング上の煩雑さを軽減するために考案された手法で、無償で公開されているO/R マッピングフレームワークもあります。

このような O/R マッピングの取り組みに、わたしはこの記事の最初にあるような SQL 言語に対する思い以上に感心しています。

 

最近では、モデリングに UML の使用が普及していますが、ER モデリングも使われ続けていて、整合性の調整の手間が気になることがしばしばありました。

オブジェクト指向設計・実装とリレーショナル・データベースの相性は、よいといえるものではありませんが、工夫してなんとかつきあっているといった感じでしょうか。

 

このごろは、XML データベースが書籍や雑誌で扱われるようになりました。オブジェクト指向との相性はよさそうです。これまでのリレーショナル・データベースの正規化・非正規化を主体に考えるのではなく、オブジェクト思考にまかせて考えればよいのかもしれません。

ただ、リレーショナル・データベースと SQL は、EUC のような作業と相性がよいといえそうです。このように考えると、O/R マッピングは、引き続き必要な技術となるのでしょう。しかし、そのような作業でも、思考・アプローチをかえれば、リレーショナルでなくとも本来の目的を達成できるのかもしれません。