ABD (Activity Based Modeling) の体系を想像する(1)


羽生章洋氏のABD (Activity Based Modeling) とはいったい何か、唯一のまとまった資料
http://event.seasar.org/sc2006spring/viewAttachment.do?_pageName_=Materials%2FD4.ppt
からその全体像を復元するシリーズ。
もちろんご本人に伺えばいいんだけど、まずは自習から。


初回はざっと読んで分かった気になったことをメモする。全部俺理解だから正確な情報は原典を見てね。
今回は「ABDすると何が良くなるのか」という最重要な話題は避ける。それはABDで設計したデータベースに触ってから書く。


ABDで設計したら、データ構造はどうなる

ABDでは、外部キーを、resourceだけでなくeventからも追放する。
つまり

  • 売上ヘッダには顧客IDがない。
  • 売上明細には商品IDがない。それどころか売上ヘッダIDすらない。
  • event/resource間のリレーションシップは、別途「リレーションシップのみを表すテーブル」で表現する。このテーブルをIRE(Inter Relation Entity)と呼ぶ。

という形になる。

「コードを外部キーにしない」論との関係

楽々ERDレッスンで提唱されていた「コードを外部キーにしない。identifierを外部キーにする」ということを徹底すると、外部キーというものの意味が変わってくる。
ていうか意味が純化される。外部キーとは、「記録しておきたい事実」そのものではなく、記録したい事実を参照するためのポインタになる。


「記録しておきたい事実」をFact、「記録したい事実を参照するためのポインタ」を Relationship と呼んでみると、従来の「コードを外部キーにしてもよい」データベース設計では、Fact と relationship の区別がないことに気付く。
例えば、出荷伝票明細テーブルに「商品コード」属性があったら、それは出荷伝票に印字されるべき情報であると同時に、商品マスタの当該レコードを指すポインタとしても機能する。
が、identifierを外部キーにすると、(identifierはシステムの外には一切漏れない番号なので)Factとしての意味はなくなる。純粋なrelationshipとなる。


そう思ってeventのテーブルを眺めると、明らかにFactな属性と、明らかにrelationshipな属性が混在しているように見えてくる。
T字形を教わってから、resourceに外部キーが混入しているのが気持ち悪くなったように、Factに混入したrelationshipが気持ち悪くなってくる。
ここでFactとRelationshipを完全に分離してみると、何ともすわりのいいER図になる。

IREの正体

IREのことを「リレーションシップのみを表すテーブル」と書いたが、これは嘘。IREは活動(Activity)というものを表している。「売上」「入金」などが Activity の例。
「売上」IREと「入金」IREは「売上関連ID」を共有しているので、どの売上にどの入金が対応するのか追跡できる。


ABDでは、特定のIREを引けばある業務に必要な情報が全部集まる、という形になる。これは、ABDの見かけ(テーブル数が増える)とは逆に、ある業務のためのデータアクセスが、minimal coverのデータベースより単純になる可能性を示唆する。
また、同じFactに対して業務を追加・削除するには、IREを付けたり外したりすればいいだけになる。既存のテーブルに add column するより create table する方が安全(データベース版 Open-Closed Principle)。

JPAとの相性のよさ

JPAのことはよく知らないから、下手なことしか書けない。
JPAマッピング定義により、IREは全て、オブジェクト間の参照関係に変換される。生成されるオブジェクトグラフからはきれいに抜け落ちる(IRE上には業務で参照したいFactは一切載っていないから、抜け落ちてよい)。
また、更新するときも、JDBCで書いたらIREのレコードを追加削除する手間が加算されるが、JPAだとフレームワークが勝手にやってくれる。
IREに Fact が混入していたらこうは行かない。IREは純粋に relationship しか表現していないから、フレームワーク任せにできる。これが「JPAとの相性が良い」という話。
違ってたらすいませんね。

謎と課題

  • eventの中にFactとRelationshipを混在させることで、我々は今まで何を損してきたのだろうか。
    • 思えば、T字形ER手法で教わった resource の中に Relationship(外部キー)が混在していることのおかしさも、十分に理解できてない。他人を説得できるほどに分かっていない。
  • いままでO/Rマッピングの問題だと思っていたことが、データベースをABDにすることで解消してしまう予感がある。業務ごとにオブジェクトのチェーンを手繰りまくる必要がなくなるような気がする。どうだろう。
  • ABDでは従来の設計よりテーブル数が増えるが、業務単位にIREを作成することにより、各業務専用のデータアクセスがかえって簡単になってしまうような気がする。これはどうだろう。
  • ABDでもresource/eventから排除しなくてよい外部キーというものはないのだろうか。例えば売上明細が売上ヘッダIDを持っていたら、それはrelationshipではなく売上明細自身の属性と見ることはできないか。
    • つまり、RDB上で外部キーの形で表現される事象には、ほんとうは何種類かあるのではないか。

こういうことは自分でサンプルを書いてみないと分からない。適当なデータベースとアプリをABDで書き直して体感してみる予定。