« システム開発の最終兵器「オープンパッケージ」 | トップページ | XEAD、今後の展開 »

2008.06.30

全テーブルが載っているデータモデルは便利か

 筆者が公開しているデータモデリングツール「XEAD」に関して何度か受け取った意見として「すべてのテーブルを載せたデータモデルが見れるようであればもっといい」というものがある。これに対する筆者の答えは単純だ。「XEADでもすべてのテーブルを載せたモデルは作れる。だけど、それを見せられても他人はうれしくない」である。

 XEADでそのようなモデルを作るために、まず便宜上のサブシステム定義を1個追加する。そして、そのデータモデルを開いて、すべてのテーブルをそこにドラッグ&ドロップすればいい。

 作るのは簡単だが、ひとつのデータモデルに載るテーブルが増えると、図面として読み取りにくくなる。集積回路のようなデータモデルを見て短時間で内容を理解できるのは設計者本人くらいで、それ以外の人間にとっては「ほほう、テーブルがすごく多いですね」くらいの印象しか持てない。

◆ナビゲーション機能やレイアウトルールを活用する

 この問題に対処するための機能が、たいていのモデリングツールには搭載されている。「現在見ている部分図が全体図のどの辺にあたるか」を示してくれる機能が「ナビゲーション」で、表示されるテーブルの属性情報を増減させながらモデル全体のサイズを拡大・縮小するための機能が「ズームイン・アウト」である。

 これらの機能は一見すると気が利いているように見えるが、効果は限定的だ。

 まず、ナビゲーション機能を使って便利だと思えるとしたら、間違いなくそのユーザはモデルに精通している人物である。なぜなら、全体のどの部分にどんなテーブルがあるかを事前に把握していないと、どの領域にフォーカスすればよいかわからないからだ。

 なお、ナビゲーション機能では全体図上のテーブルはシルエットでしか示されないが、ズームイン・アウト機能を使えば、テーブル名を示したままに縮小することもできる。モデルに詳しくないユーザーであっても、テーブル名を手がかりにして関心のあるテーブルを探し出すことも可能ではあるだろう。また、データモデルのどこらへんにどんなテーブルを置くかといった「レイアウトルール」を設けることで、関心のあるテーブルを見出しやすくもなるだろう。

 では、そのときの関心に含まれる複数のテーブルが、モデルのあちこちに散らばっていたらどうだろう(これはふつうにあり得ることだ)。ある情報を眺めてなんらかの洞察を得たい場合、「関心のない情報がさしあたって隠されている」ような見方がしたくなる。このような場合、ナビゲーション機能は役に立たない。データモデルに常に大量のテーブルが載っていることを前提とするナビゲーション系機能の限界は、ここらへんにある。

◆ブロック化機能を使う

 ある種のモデリングツールではこの問題に対処するために、データモデルの一部を切り出して表示できるようになっている。すなわち、任意のブロックを定義して、そこに含まれるべきテーブルを指定することで、関心にしたがったテーブルとそれら同士の関係「だけ」を眺められる。

 XEADではそのようなブロックのことを「サブシステム」と呼ぶ。ひとつのサブシステムにはいくつかのテーブルと機能(プログラムの論理的なまとまり)が含まれる。つまりXEADにおいてこのまとまりは、「関心に応じたデータモデルの部分図」ではなく、「エンジニアリングされるべき実体」である。全テーブル中のいずれかの組み合わせに対する関心があるとしたら、それはいずれかのサブシステムへの関心に連動しているはず、というわけだ。

 結果的に、XEADのデータモデルでは下図のように「内部テーブル(そのサブシステムにおいて定義されているテーブル。紺色で示される)」と「外部テーブル(他のサブシステムにおいて定義されているテーブル。灰色で示される)」の違いが読み取れる。同時に、そのサブシステムに含まれる機能によって、各テーブルに対してどのようなCRUD操作(Create,Read,Update,Delete)がなされているかも示されている。そして、各テーブルに対してCRUDの中のどの操作が欠けるかという「CRUDのゆらぎ」が、そのサブシステムの性格を端的に表してくれる。

Image080630

◆構成感覚を行使する

 テーブルだろうがクラスだろうが設計要素が大量に置かれた図面は、それを書いた本人以外にはわかりにくい。それは、段落も句読点もない長文が読みにくいのと同じ話だ。要するに、膨大な要素を含む情報を他人に理解してもらうためには、構成感覚を駆使した階層的編集が必要なのである。

 データベースに含まれるテーブルの数が数十個を超えたなら、それらを単一のデータモデルに置いて示すやり方は通用しなくなると考えたほうがいい。そのうえで、なんらかの構成的階層を導入すべきだ。それは簡単な課題ではないが、設計実務において構成感覚が行使される過程での、雑多な考慮事項のひとつに過ぎない。

|

« システム開発の最終兵器「オープンパッケージ」 | トップページ | XEAD、今後の展開 »

コメント

以前、業務で基本設計を任されました。私はXEADで設計資料を作成しました。

当資料を作成後、上司とのレビューの際、業務フロー図は問題なかったのですが、データモデル(ER図)に関して、馴染みがなかったのか、クラス図みたいにして、かつ全体がわかるように図示しなおして欲しいと言われました。

私も食い下がって、このデータモデル図法の利点(インスタンスの羅列が可能、エンティティーが階層的であるため直感的な理解が可能など)を説明しました。

しかし、上司はただ一言「普通ER図といったらクラス図みたいなのでしょ」と言われました。

結局、私は上司の指示どおり不本意ながら従来のER図で全体を図示しました。

これらの経験から得たことは、人にもよるのでしょうが、物理法則の慣性の法則みたいな、従来から慣れ親しんだものからの脱却の難しさを感じました(私の説明下手もあったと思いますが)。もう1つ上司が心配していた事は、協力会社との説明の際に、データモデルのような図法では、先方も慣れてない図法だから戸惑うということがあったようです。

渡辺さんであればどのようにこの上司を説得していたでしょうか?

投稿: hiro | 2008.07.01 18:58

ふふふ、たいへんでしたね。気持ちはよくわかります。きっとその方は「提案書のページ数は多いほうがよい。なぜならそのほうが迫力があるし、もっともらしいから」とも言うと思うんですよ。心理的慣性法則ゆえというのもあるとは思うんですが、ようするに「たとえわかりにくいとしても、複雑だったり難解だったりするものはありがたい」と感じる傾向が人間にはあるんではないでしょうか。

で、私は立場上、「基本的な価値観の異なる相手を商売の相手にはしない。なぜなら彼らを説得できるほど人生は長くないから」と言えるんですが、うーん、そんなのはhiroさんには無意味なアドバイスなのでしょうかねぇ(^^;

投稿: わたなべ | 2008.07.02 00:37

なるほど。心理的慣性法則っていうのはあるかと思います。
相手にしないというのもいいアプローチかもしれません。
アドバイスありがとうございました。

投稿: hiro | 2008.07.03 18:03

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 全テーブルが載っているデータモデルは便利か:

» poker online [poker online]
detection trudged Borden,baccarat [url=http://www.akasinos.com/baccarat.html]baccarat[/url] http://www.akasinos.com/baccarat.html [続きを読む]

受信: 2008.07.25 10:30

« システム開発の最終兵器「オープンパッケージ」 | トップページ | XEAD、今後の展開 »