文書ドリブン開発 DB設計文書編：システム開発プロジェクトの現場から（25）（2/2 ページ）

CRUD図のデータベース化

　前ページの例はDB設計者向けの用途としてのCRUD図の使い方でしたが、ほかにはエンティティの変更が個々の機能に及ぼす影響の範囲を調べるために用いられるのも一般的です。CRUD図は各機能でのデータのINとOUTを見えるようにしてくれるという側面もあります。これはデータフロー図でも代用可能ですが、影響範囲の一覧化がしやすいというところが、CRUD図のように表形式になっている文書の強みです。

　CRUD図は一般的にはExcelなどの表計算ソフトで作成されることが多いと思いますが、表計算ソフトを使った場合、いくつか不便な点があります。

1. 表の列数が多くなると、表計算ソフトの制約で情報を収容しきれなくなる
2. 表のサイズが大きくなると、参照・更新の動作が重くなる
3. 任意の条件での検索がやりづらい、見づらい

　以上のような不便な点がありますが、特に（3）についてはせっかくの有用な情報が活用しきれないという点で非常にもったいないです。Excelのような表計算ソフトではフィルタ機能によって特定の行を抽出することはできるようになりますが、特定の列を条件によりフィルタリングする機能は付いていません。また、少し複雑な条件（例：データ件数が1万件以上で使用回数が100回以上／日の機能2つ以上に使用されているテーブル）での抽出ということもできません。

　そこで思い切ってCRUD図をデータベース化してしまうことを推奨します。データベース化することで、複雑な条件であってもSQL文で抽出することができるようになり、有効利用度が格段に向上します。ここまですると、もう「文書」と呼べるかどうか疑問ですが、正確に・効率よく・見える形にするという「文書」の用途から考えれば、わたしはこのCRUD図のデータベースを「文書」と呼んでも差し支えがないと考えています。

　参考までに、普段わたしがCRUD図をデータベース化して活用している際のER図を掲載しておきます。わたしはデータ入力の機能を持った画面を作って、それを利用しています。情報の抽出については、あくまでもSQL文での抽出を基本としているので、データ抽出専用の機能は特に用意していません（図4）。

図4　CRUD図データベースのER図（例）

　今回はDB設計文書、特にCRUD図についてお話ししました。DB設計文書はアプリケーション機能の開発者が頻繁に参照することはもとより、ユーザーが快適な性能でシステムを使い続けることができるようにするための設計文書という意味で、とても重要なものです。DB性能に関する設計の成果は、システム稼働の数年後に表れてくるという特殊な位置付けにあるものですので、その意義を考えつつ文書作りを進めていっていただければと思います。

　次回は、機能詳細設計文書の勘所についてお話ししたいと思います。