設計者の発言

　前回記事で、業務システム開発の上流工程でDB設計がないがしろにされるケースがあると指摘したが、よほど低レベルな職場でない限り、今では上流工程でのER図の作成が標準化されるようになっている。

　ところが、そのER図がまるでショボいにも関わらずレビューで承認されるケースがあとを絶たない。理由は単純で、ER図があるかどうかだけがチェックされて、内容レベルの検証がなされていないためだ。それはとりもなおさず、DB設計を的確にレビューできる技術者がいないためでもある。

　ER図を見れば、プロジェクトが成功するかどうかまではわからないかもしれないが、「デスマーチ化するかどうか」はわかる。それほど便利な図面が提出されながらレビュワーのスキルが足りないのでは、設計標準の持ち腐れというものだ。

　そこで、ER図を効果的にレビューするためのポイントを紹介したい。構成的な心地よさがあるか、キー構成が単純すぎないか、創意工夫が盛り込まれているか、の３点である。これらの最初の２つについては、一定以上の知識があれば新人でも判断できる。組織のレビュースキルを底上げするための参考にしてほしい。

１．構成的な心地よさがあるか

　一見してゴチャゴチャしているようであれば、そのER図はその理由で却下していい。なぜならER図は、複雑なデータ構造を直観的に把握するための図面だからだ。たとえば、１枚に膨大な数のテーブルが載っている「集積回路」のようなER図であってはいけない。テーブル関連を調べるための虫メガネが必要になるし、なによりも本質的な理解を妨げるからだ。

　このアンチパターンを避けるのはじつは簡単で、ER図をサブシステム毎に切り分けたらいい。１枚に全テーブルを並べようと汗水を流すよりは、図面を適切に分割するほうが効果的である。１枚あたりのテーブル数が２０個を超えない程度が適切だ。そのうえでサブシステム間のインタフェースを別途図面化すれば、全テーブルを載せたER図など無用の長物である。それゆえ全テーブルを載せたER図には、読みにくくすることで品質の劣悪さをごまかそうという意図さえ、私などは感じてしまう。

　別の言い方をすれば、ER図は「大事なこと」を直観できるようにまとめられなければいけない。膨大な数のテーブルが載っている理由を問われ「これらの全部が大事なテーブルだから」と答えるのは、「全部大事でないから」と答えるのと同じである。下手な文章が無駄に長いのと同様に、下手な図面には無駄に多くの要素が盛られている。些末な事柄について受け手が悩まずに済むように、適切に編集されるべきだ。

　つまるところ設計成果物というものは、設計者自身の職業適性の発露である。ER図に限らず、技術者が提出する資料や何気なく書いた板書やら何やらまでが、本人がそれを望むかどうかに関係なく、かれの職業適性を値踏みするための「作品」とみなされる。どんな適性か。ややこしい内容をわかりやすく他人に示すための「編集センス」だ。それがプロレベルであるかどうかが見つめられる。しかも「構成的な心地よさがあるかどうか」なら素人でも一瞬で判断できてしまうところが怖い。

２．キー構成が単純すぎないか

　「単純すぎる」どころか、キー構成が示されていないER図を見かけることがあるが、クワセモノである。インスタンス間の多重度が「１：N」などと示されていたとしても意味はない。なぜなら、そのような図面にもとづいては、データ間の精妙な制約をDB構造として形式化しようがないからだ。けっきょくそれらの制約はアプリ上にゴリゴリと記述しなければならないので、ごく小規模な案件でない限り、バギーで保守に手のかかるシステムが生み出される。

　また、「フィールド数のメトリクス」で説明したように、一般的な業務システムに含まれるテーブルの主キーのうち、半数が「単独主キー」で、残りの半数が「（ナチュラルキーでない）複合主キー」である。このバランスが崩れているとしても、ER図の品質を疑ったほうがいい。

　典型的なものが、すべてのテーブルが「id」のような単独主キーとなっているER図だ。開発基盤の中には単独主キーを強制するものがあって、そのような基盤の利用を前提とすれば、全テーブルが単独主キーになることは避けられない。その場合でも、その設計者が「単独主キー方式でしか設計できない」のか「複合主キーを含めた形でも設計できるが、基盤特性を考慮して意図的にサロゲートキーを組み込んだ」のかを見極める必要がある。それは案外簡単で、テーブルの半数が持っていたはずの「本来の複合主キー」が何であったかを問えば済む。

　じっさいのところ、キー設定はDB構造の骨格に相当するもので、これが粗雑だとテーブル関連にまで悪影響を与える。たとえば、テーブルがたくさんある割にテーブル間の関連線が数えるくらいしかない「板チョコモデル(中山嘉之氏)」は却下される。上述したように、そのようなDB構造を扱うアプリは、テーブル結合のための複雑なロジックを抱える羽目になる。業務ルールを可能な限りDB構造という宣言的要素に回収する――それこそがDB設計者の役割であって、アプリのコードを増やすばかりの設計は的外れである。

３．創意工夫が盛り込まれているか

　DB設計は、テスト問題を解くような分析的・収束的過程ではない。「正規化崩しの目的は高速化だけではない」で紹介した抽象テーブルがわかりやすい例で、そういう要素を盛り込むためには、ある種の飛躍的思考が求められる。

　そんなものは科学ではないと思われるかもしれないが、我々の営みは科学ではなくエンジニアリングである。局所的な唯一の正解にたどりつくための機械的作業が多分に含まれるにせよ、それらは本質ではない（機械的な作業など機械にまかせたらいい）。我々に求められていることは、制約された条件下での効果的な実現方法を「創案」することである。

　創造的でないモデルが悪いと言うつもりはない。業務分野別のイディオムをマジメに踏襲するのも悪いことではない。しかし、イディオムをそのまま適用できる例は案外少なく、現実のシステム要件は多かれ少なかれ個別性を帯びている。そのような要素については、イディオムからはずれた工夫で対処するしかない。創造的な要素を含まないER図は、担当者が業務要件を洞察していない証拠なのかもしれない。

　そういうわけで、ER図のレビューにおいてオヤッと思う要素があったなら、その意図を担当者に説明してもらおう。かれはその背景となるシステム要件とかれの工夫を生き生きと解説してくれるだろう。その要素は結果的には却下されるかもしれないが、DB設計が創意工夫の結実であることをかれが理解し実践していることはわかる。反対にそのような要素がまるでないとしたら、レビュワーはちょっと心配したほうがいい。

　以上、３つのポイントを挙げたが、これらは「試行錯誤が重ねられた結果であるかどうか」として１つにまとめられる。稚拙なDB設計はたいてい、最初の形からいつまでたっても代わり映えがしない。それは、他の多くの可能性が考慮されていないという意味で危険な兆候である。設計担当者は、与件にもとづいてさまざまな選択肢を考案・吟味し、最善の落としどころを探らねばならない。その過程で捨てられたアイデアが山ほどあったか。それをER図から読み取るために、これらのポイントを手がかりにしてほしい。

このブログでの参考記事：
拡大・縮小する前に美しいER図を
サロゲートキーは強制されるべきものではない
「設計情報の構造」に現れる設計品質