「大規模集積回路モデル」と「板チョコモデル」

　大量のテーブルとそれらの関連がびっしり置かれたデータモデル（ER図）を私は「大規模集積回路モデル」と呼んでいる。大判の用紙で印刷しても文字が小さいうえに、関連を追う気が失せるくらいに関連線が込み入っていたりする。

大規模集積回路モデル

　これはモデリングのアンチパターンというよりは、モデリングツールの問題である。データモデルというものはなんらかのサブジェクト別に眺めるもので、すべてのテーブルを一度に眺めてもせいぜい「テーブルがものすごく多い」ということしか読み取れない。テーブル数が多すぎない程度に切り出して示すべきだ。

　拙作のXEAD Modelerにおいて、データモデルは「サブシステム」単位で示される。サブシステムとは「いくつかのテーブル定義と機能定義のまとまり」のことだ。データモデル上には、そのサブシステムに所属するテーブル（内部テーブル）の他に、他のサブシステムに所属するテーブル（外部テーブル）も示される。次図で青く示されているのが内部テーブルで、灰色のものが外部テーブルである。

「発注・入荷データ管理サブシステム」のデータモデル

　赤丸で示したように、そのサブシステムにおいてそれぞれのテーブルにどんな操作がなされているかが、CRUD(Create,Read,Update,Delete)として自動的に示される点にも注目してほしい。基本的に内部テーブルはCRUDのすべて、外部テーブルはRだけとして示されることになる。というか、サブシステムはそのように切り出されるべきだ。外部テーブルを更新しているとしたら、サブシステム間の結合度が強すぎるからだ。

　「大規模集積回路モデル」の親戚に「板チョコモデル」と呼ばれるアンチパターンがある。この愉快なネーミングは、尊敬するモデラー仲間であるＩＴイノベーションの中山嘉之さんによるものだ。テーブルが整然と並んでいて関連線が妙に少ないために「板チョコ」のように見えるモデルのことを言う。私も何度かそういうモデルを目にしたことがあるが、最近見たものには３０個ほどのテーブルが並んでいて関連線が２本しかなかった。

板チョコモデル

　テーブル関連が少ない理由はいくつかある。まず、主キー設計が甘いためだ。そもそも主キーがなかったり、あっても正規化されていないので参照関係を引けなかったりする。２つ目の理由は、レコードの対応関係がプログラム中で記述されているためだ。いちいちコードを読まない限りテーブル関連を理解できないとしたら、システムの保守性が悪すぎる。ようするに、データモデリングの意義を理解しないままにDB設計して、確定後に「ＥＲ図を出せと言われたからしかたなく書いた」ような不調法な図なのである。

　じつは板チョコモデルも、ある意味ではモデリングツールの問題である。一部のテーブルだけを切り出して示せないだけでなく、示されるべきテーブル関連がツールの制約上定義できないことがあるためだ。

　例を示そう。次のモデルでは、受注明細と販売契約単価の間に関連はない。販売契約単価の主キーである｛顧客コード＋商品コード｝に対応する外部キーが受注明細上に存在しないからだ。しかし、受注単価は規定の契約単価として参照されるのだから、受注明細と販売契約単価の間にはある種の参照関係が成立しているはずだ。

　受注明細において顧客コードは、受注見出しから推移的に関数従属する属性である。これを「継承項目」等として外部キーに組み込めるようであったほうがいい。XEAD Modelerではそれが可能で、継承項目はカッコ付で示されるようになっている（図のように関連線の端にマウスを置けば、どのキーにもとづいて関連が成立しているかが示される）。

　では次の例はどうだろう。販売契約単価の主キーに「有効開始日」が含まれている。受注明細にはこれに相当する項目は存在しないので、参照関係は定義できないように思える。

　受注見出し上の「受注日」にもとづいて有効開始日が探索され契約単価が決定するとしよう。受注明細上に「有効開始日」を「導出項目」として置くことで、参照関係に必要な外部キーを構成できる。単価と数量を掛け合わせた「金額」が導出項目の典型例だが、この例のようになんらかのテーブル操作を伴いつつ値が決まるとしたら、その項目も導出項目とみなせる。通常の参照関係が「静的」であるなら、継承属性や導出項目を外部キーに含む参照関係は「動的」である。その関係はなんらかの手続きを伴いつつ成立しているからだ。

　このように、気の利いたツールを使ってまともにデータモデリングすれば、テーブル関連は想像以上に豊かに示せるものである。結果的に、テーブル数をしぼっても関連線が多すぎたりするので、ある種の関連を些末なものとして意図的に隠せたほうがいい。示すテーブルを絞込み、さらに重要な情報だけを示すことで、モデルはシャープさを増す。参考にしてほしい。

本ブログでの関連記事：
全テーブルが載っているデータモデルは便利か