楽々ERDレッスンを読む(2) - 第２部 RDBMS総論

本 RDB


羽生氏の 楽々ERDレッスン (CodeZine BOOKS) のまとめ２回目*1。
第２部のポイントは、P-114からの「インピーダンスミスマッチの解決方法」。
その方法とは...

P-115
お薦めしたいのがストアドプロシージャを利用することです。

では、ストアドプロシージャを使うと、どうしてインピーダンスミスマッチが解消するのか。

更新の改善

Javaの中でupdateステートメントを組み立てて実行するのを止め、ストアドプロシージャを作成して、Javaからは更新したいデータを引数として渡すのみにする。
そうすることで、Javaの中からデータベース関係の詳細を排除できる。これがストアドプロシージャ導入のメリットとされる。

P-117
「何という名前のストアドプロシージャを呼び出すのか」「パラメータの何番目に何を設定するのか」
だけを知っていれば、SQLは一切不要になります。そしてプロシージャそのものは、SQLに精通した
プログラマが作成しておけばよいのです。

読み取りの改善

同様にselectステートメントも、Javaプログラムからストアドプロシージャに移動する。
これにより、

P-119
仮にSQLのチューニングが必要になっても、Java側に一切の影響を与えずにストアドプロシージャ内
のコードを変更することが可能です。これはつまり、RDBMSに対するアクセスメソッドのカプセル化を
実現できるということです。

ストアドプロシージャでアプリケーションからデータ構造を不可視にするとどうなるか

インピーダンスミスマッチの解消といえば、O/Rマッパーの導入というのがありがちな答えで、さらにO(bject)とR(elational Database)のマッピングが、クラスとテーブルのマッピングという話にいきなり収斂してしまうというのもありがちな展開。
羽生氏はこの、クラスとテーブルを対応付けるというアプローチを、ばっさり袈裟斬りにする。

P-120
RDBMSを一個のSingletonオブジェクトとして、ストアドプロシージャがメソッドであると
考えるならば、これをUMLで表現すると異様に縦長の1個の巨大なクラスとなります。

全てのストアドプロシージャをpublicメソッドとする「データベースクラス」について、

このクラス内のprivate変数の構造がテーブルだと考えてみる

と言って、RDB内部のデータ構造をアプリケーションに露出させないことを推奨し、
さらに、UMLのクラスとER図のエンティティの関係については、

単に四角というのが似ているだけじゃないの？と考えると自由になれます

と書く。

プログラムから見た個々のテーブルはprivate変数だということ＝「テーブルを表すクラス」よりも「データベースを表すクラス」という見方のほうが正しいことは、数年内に常識になるだろう。
RDBが抱えるデータ構造はリアルワールドのビジネスの写像でなくてはならないが、そのデータにアクセスする個々のプログラムはビジネスのある１局面を担当しているだけなのだから、本当のデータ構造を知る必要はない。自分が見たい形でデータを見ることができれば用は足りる。
そして、本当のデータ構造とは異なるデータの見え方を提供することは、RDBの必殺技だ。これを使わない手はない。


テーブルと同じ形をしたEntityクラスが活躍するアプリケーションは、データベース「クラス」のprivate変数を直接参照しているのだから、データベース「クラス」の変更の影響を全てかぶることになる。そういう設計はオブジェクト指向的じゃないのではないか。オブジェクト指向派の人はどう考えるか。

*1:1回目はこちら: http://d.hatena.ne.jp/tgk/20060526