前の記事に続いてSeasar Conferenceをレポートする。

セッション4

DB-sideのほうは「EJB3時代のERDレッスン - Activity Based Datamodel」
Seasar-sideのほうは「片手でスイスイWebアプリ2.0 - Tuigwaa劇場へようこそ」
ミニセッションのほうは「S2Flex2」

Tuigwaaのセッションは聴衆を感動と興奮の渦に巻き込んだらしいけれど、それは想像に難くない。千葉滋PM採択案件最終成果報告会で一応話は聞いて、私も非常に感動した。

Tuigwaaは一度聞いたからいいやと思って、私は「ERDレッスン」を聞いてきた。

はぶさん

ERDセッションの発表者は、はぶあきひろさん。御本人を見るのは初めてで、少しイメージが違った。

はぶにっきは愛読しているけれども、偶に、SIerさんが書いていると想像するとちょっと鼻につくように取れる文章がある。でも御本人の話っぷりを見るとまったくスーツ族の臭いはしなくて、とても感じが良い。たぶん、御本人の人柄を知って読むと文章のイメージが変わるタイプの人なんだと思う。

ちょっと誤解していたね。うん。はぶさん良い人だ。

イベント系重要

まずは、『楽々ERDレッスン』の簡単なまとめをさらっと触った。一言で言えばnatural keyじゃなくidを付番するのが重要ということ。

そして、その上で「イベント系重要」という話があった。

マスターテーブルは確かに重要だけれども、それだけあっても仕方がないよね、と。顧客マスター、商品マスターだけあっても仕方がない。顧客だけ、商品だけあっても仕方がない。その間に「売り上げ」がなければビジネスにならない。商品、顧客のようなリソース系も大切だけれども、イベント系こそが真に重要である。

イベント系って何かと言えば、顧客と商品が交差するのが売り上げであるように、交差エンティティである。そして、交差エンティティがまた他のエンティティと交差するかもしれないから、交差エンティティにも「id重要」。

Activity Based Datamodel

ここからが凄かった。あまりに大胆なやりかたに、思わず口をあんぐり。Rails、Tuigwaaに続く驚きかもしれない。

まぁ、多対多対応が出てきたらその対応をエンティティに変えられないか、エンティティを見落としていないかチェックせよっていうのは、広く知られている経験則だよね。でも、はぶさんはそのあたりをもっと突っ込んで行く。

そもそも、ChenのERモデルっていうのは「世の中のあらゆるものは実体(Entity)と関連(Relationship)で表現可能である」という考え方。で、最初はEntityを長方形で表して、Entityに属する属性を長方形の下に楕円で描いてぶら下げて、RelationshipはEntity同士の間に菱形を書いて表した。

ところが、次第にRelationshipがForeign Keyだけで表現されるようになって、菱形は省略して長方形を線で結ぶようになって、そして多対多だけが特殊になってしまった。

原点回帰しよう。Entityの間にはRelationshipというものが「在る」。で、ここでさっきの話に結び付く。顧客と商品の関係とは、例えば売り上げだ。関係って何だ？　交差エンティティだ。交差エンティティって何だ？　イベントだ。そりゃそうだ、ビジネス上の何かが起こったから関係が結ばれるんだもの。「製造」「発注」「納品」などなど。

だから、従来のモデリングであればリソース系のEntityに含まれているようなFKを全部抜き出して、それをイベント系として再定義してしまう。リソース系にはFKは含まれなくなる。

リソース系はFactを記録する。
イベント系はActivityを記録する。

従来であれば外部キーとしてリソース系の属性になっていたようなものは全て、イベント系に移る。移せる筈だ。だって、何かが起きたからこそ、記録に値するような関係が結ばれた筈だもの。

テーブル設計における悩みどころというのは、大抵が「どういう風にリレーションを張るのが適切か」である。でも、開きなおって「リソース系はFKを持たない」「いくつかのリソース系の間を結ぶ関係がイベント系。FKの集合体（+ID）がイベント系」と考えてしまえば、悩む余地って殆んど無くなる。

Kuinaの宣伝

このやりかた(ABD)はSQLを複雑にしがちだけれど、テーブル設計をマスターするよりSQLをマスターするほうが遥かに楽でしょ、とのこと。

そして、JDBCに代わる、より高水準なJava標準のデータアクセスであるJPA(Java Persistence API)を使えば、その繁雑さもかなり救われる。アノテーションの力を借りて、面倒なリレーションシップの解決を自動的にやってくれる。

もっとも、JPAはJPAで、SQLをガリガリ書きたいような局面で不自由があったりする。「そこでKuinaですよ」だそうだ。次世代S2DaoであるKuinaで、JPAとSQLの両方の利点を両立しよう、と。

感想

……というお話でした。目から鱗が落ちた。

リソース系はFactの記録であるからして、勿論UPDATEはあるだろうけれど、テーブルの構造自体はそんなに変わらないと考えられる。増してFKを全部外に出してしまったなら。

一方、それらのリソースをどう結びつけるかっていうのはビジネス展開に応じていくらでも変わりうる。リソースの結び付けが変わるたびにリソース系の構造を弄っていたんじゃかなわないけれど、ABD方式の設計なら新しいビジネス展開に応じて新しい関係が発生し、新しい種類のActivityが発生するようになったなら、単に新しいイベント系テーブルを追加すれば良いだけの話だ。

これは変化に強いよなー。