「危ないデータモデル」の定量的判定基準

　業務システム開発に３０年携わって、結果を見る前にプロジェクトの成功・失敗を予見できるようになった。実装が始まった時点でデータモデルがまともでないプロジェクトは、ほぼ失敗する。「ほぼ」と書いたのは、テーブルが２０個以下であればDB設計がグダグダでもコーディングでカバーできるからだ。テーブルが３０個以上であれば失敗する可能性が高い。その手の案件はデスマーチ化したあげく、使いにくく保守しにくいシステムと鬱病患者を生み出す。社会的影響は甚大である。

　では、「まともでないデータモデル」とはどういうものか。「主キーに含まれるフィールド」、「主キーが同一であるようなテーブル」、および「テーブル関連」を数えることで比較的簡便に判定できる。それぞれを説明しよう。

■「主キーに含まれるフィールド」を数えよう

　各テーブルの主キーに含まれるフィールドの数が多すぎたり少なすぎたりするようであれば、データモデルはまともでないと疑っていい。私の経験から言えば、まともなシステムでの「単独主キー」と「複合主キー」のテーブルは比率で半々、そして、複合主キーにおいて５個以上のフィールドで主キーが構成されるケースは滅多にない。この基準から大きくはずれている場合、データモデルを見直したほうがいい。

　特に注意が必要なのは、Railsのようにサロゲートキーを強制するフレームワーク（ID強制環境と呼んでおこう）を使う場合だ。その種のフレームワークは、テーブル数が２０個以下で済むような案件向けに最適化されていると考えたほうがいい。ところが、新人の頃からID強制環境ばかり使ってきた技術者はしばしば、複合主キーを使わずにどんな規模の案件も扱えると勘違いしてしまう。

　そのような技術者が３０個以上の全テーブルを「id」の主キーで設計すれば、システムがいつまでたっても完成しないか、運用に入ってからデータの不整合に悩まされる。なぜなら彼らは、複数の項目のフィールドの組み合わせにもとづく複雑な関数従属性を認識できないからだ。結果的に、DB構造中にさまざまな疎漏を気づかないまま組み込んでしまう。

　ID強制環境を使うこと自体が間違いという話ではない（私も必要であれば使う）。ただし、サロゲートキーの導入は「正規化崩し」の一環であるため、むしろより高いレベルのDB設計スキルが求められる。とくに３０個以上のテーブルを含む案件であれば、熟練技術者を確保して臨むべきだ。そのうえで、複合主キーを含む形のオードソックスなモデルとしてまとめ、その形で品質評価してから慎重にサロゲートキーを組み込む、という手順を踏めばよい。いかにも面倒だが、それが３０個以上のテーブルを含む案件でID強制環境を使うことの「報い」である。

■「同一の主キーを持つテーブル」を数えよう

　同一の主キーを持つテーブルがいくつもあるようなら、データモデルはまともでないと疑っていい。たとえば主キーが{a,b}のものが３個、{c,d}のものが３個であれば、合計６個。このように計算して合計が１０個を超えているとしたら、有識者を集めて検証する意義がある。

　同一の主キーを持つテーブルがやたらと現れる原因は、だいたいはっきりしている。プロセス指向アプローチ(POA)で構想されているためだ。あるまとまりのデータを処理するプログラムA,B,Cが必要であれば、同一主キーのテーブルA,B,Cが設計される。処理するプログラムが１個増えればテーブルも１個増える。このアプローチにおいてテーブルは「プログラムが正しく動作するための付加的要素」である。

　我々が採るべきアプローチはその逆で、プログラムのほうが「DBの整合性を維持するための付加的要素」である。システムがどんなデータを扱いたいのか――それさえわかれば、本来ならアプリの仕様がわからなくてもデータモデルは描ける。そして、あるべきアプリやあるべき業務連係のあり方は、データモデルから導ける。詳細な説明は省くが、それがデータ指向アプローチ(DOA)の基本テーゼだ。構成的なDB構造を生み出すコツでもあり、システムの開発効率と保守性と可読性を高めるための鍵でもある。

■「テーブル関連」を数えよう

　データモデルは「工学図面」なので、論理的な美しさだけでなく視覚的な美しさを具えていなければいけない。「人は見た目が９割」かどうかはさておき、「図面は見た目が９割」である。なぜなら人は見た目の悪いモノを見つめたくはないからだ。見た目の悪い図面、つまり「じっくりと見つめられることが期待されていない図面」ほど無意味なものはない。美しくない図面には「（出来が悪いので）じっくり見つめないでほしい」という作者の意図が反映されているのかもしれない。

　データモデルにおける論理的な美しさの核が「主キー」であるなら、視覚的な美しさは「テーブル関連」の扱いによってもたらされる。そして、テーブル関連を示す線（関連線）の多寡や配置で設計品質がよくわかる。関連線が多すぎたり少なすぎたりするなら、そのデータモデルはまともでないと疑っていい。

　関連線が少なすぎるとしたら、そのDB構造は現行の引き写しなのかもしれない。現行のDB構造というものは十中八九混乱していて、テーブル間の結合関係がよくわからないという特徴がある。そのようなDB構造を踏襲したデータモデルは、必然的に関連線が散漫かつ貧弱になる。システム開発において扱いにくいだけでなく、混乱したDB構造を見直さないという職務怠慢でもある。ちなみにそのようなモデルは、「ＩＴアーキテクチャのセオリー」の著者中山嘉之氏によって「板チョコモデル」と命名されている。テーブルを表す四角が整然と並ぶ様子が板チョコのように見えるからである。

　いっぽう、関連線が多すぎても問題だ。それは私が「大規模集積回路モデル」と呼ぶものだが、じっくりレビューする気が起こらない図面の代表である。そういうものを眺めるとまさに「なにじろじろ見てるのよ！失礼ね！」という作者の叫びが聞こえてきそうだ。

　では関連線の数はどれくらいが適切なのか。１枚のデータモデルに載るテーブルが２０個以内、関連線はテーブル数の１．５倍程度であれば、第三者がレビューしやすい図面になる。これに対して「データモデルには全テーブルを並べるべきだ」という意見があるが、私としては受け入れ難い。１枚のモデルに全テーブルを載せると、関連線が錯綜して「大規模集積回路モデル」になりやすいし、A4やA3で手軽に印刷できないからだ。

■「言葉で説明できるかどうか」が重要

　以上、「危ないデータモデル」を判定するための３つの定量的基準を紹介した。ただし、こまごました数値については経験則でしかない。大事なことは「どの設計要素を数えたらいいか」であって、評価基準の数値についてはそれぞれの職場で微調整したうえで活用してもらえばよい。

　また、基準を満たしていても、モデルのあり方について合理的説明が出来なければ意味がない。いちばんダメなのが「現行のDB構造がこのようであるから」といった説明である。システム刷新における「DB構造の現行踏襲」は多くの場合、増改築を繰り返した温泉旅館を取り壊した後のゴチャゴチャした基礎の上に、２０階建てのリゾートホテルを建てるような無謀である。「現状がこうであるから」は言い訳にさえならない。

　じっさいのところ素人である顧客は、現行システムのDB構造が的確かどうかなどわかっていない。保守性や使い勝手の悪さがDB構造の稚拙さゆえであることもほとんど気づかれない。ゆえに、業者から「DB構造の作り替えは要らないですよね。作り替えたらデータ移行のコストがかかるだけでなく、過去の情報資産も失われますよ」などと提案（オド）されて拒否する顧客は滅多にいない。そういうわけなので、設計スキルの足りない業者ほど「DB構造については現行踏襲」という「動かせないユーザ要件」を確立したがるものだ。DB構造の問題に関して責任を負わずに済むし、見積額も抑えられるからだ。しかしそれで納品されるのは、その業者にしか保守できない金食い虫なのである。

　けっきょく、現行踏襲されたものであろうが、新たに設計し直されたものであろうが、システムの基礎となるDB構造の妥当性は言葉で説明可能でなければいけない。DB構造は芸術作品などではないからだ。そして何よりも、納得できないデータモデルであることがわかったなら、設計担当をすげ替えるなどして早急に建て直しを図ってほしい。出来の悪いDB設計がもたらす社会的影響を過小評価してはならない。