5. 仕様が抜け落ちないようにするための工夫
さて、4章では概要把握には概念モデルを見るのが手っ取り早いことを示した。また、設計を詳細に実装していくことで本来持っていた意味を失う可能性があることも示せたと思う。
ならば仕様の抜け落ちをできるだけ防ぐにはどうしたらよいのだろうか。その指針をここでは示そう。
5.1 E-R図(概念モデル)の工夫
E-R図は単なる図ではなく、複数の情報を埋め込まれた図だ。だから図の持つ意味を正確に表現しないといけない。
必須事項
- エンティティの独立・従属はしっかりと区別して書く
- 長方形：独立・角丸長方形：従属である。気分で変えないように。
- 多重度の記述は最小・最大を意識して書く
- 0か1か・1か・1以上か。特に多重度に固定値がある場合は正確に記述すること。
- リレーションシップにはきちんと意味を記述する
- なるべく論理モデルとは別立てで作成する
- 論理モデル起因の概念モデル修正はなるべく控える
しておくと便利
- エンティティがリソース系かイベント系かを区別可能な記述（タグなど）を付けておく
- エンティティが核・記述・連関エンティティかを区別可能な記述（タグなど）を付けておく
概念モデルと論理モデルを別立てで作成するとメンテナンスが面倒かもしれない。特に論理モデルで修正が入った場合その都度修正するのは確かに億劫だ。
だがちょっと考えて欲しい。
概念モデルでは主キーや属性を記述しないため論理モデルの都度反映は本来不要であるはずだ。また、概念モデルは業務中心に考えたものであるため業務が増えない限りはそうそうエンティティが追加になることもない。論理モデルでエンティティが増えたとしても、システムを実装する上で必要となったものの反映は不要であるはずなのだ。
もし概念モデルに手を加えなければいけないほどの修正があったとしたら、その修正は影響がかなり大きい証拠でもある。それは影響がかなり大きい修正な証拠でもある。その場合はきちんと概念モデルも反映しないといけない。
また、E-R図を書くときのポイントだがいきなりE-R図を書こうとはしないことだ。業務フロー図や業務定義書からエンティティ候補をある程度抽出し、その関連を考えてから書くとよい
……え？ 業務フロー図や業務定義書がないって？ ……正式なものではなくてもメモ程度のものはあると思う。それすらないのであれば、まずはそれらを作成すべきだ。
5.2 E-R図(論理モデル)の工夫
E-R図のことなので、基本的な注意事項は5.1と同様ではあるが、一応重複する事項も含めて書いておく。
必須事項
- エンティティの独立・従属はしっかりと区別して書く
- 長方形：独立・角丸長方形：従属である。気分で変えないように。
- 多重度の記述は最小・最大を意識して書く
- 0か1か・1か・1以上か。特に多重度に固定値がある場合は正確に記述すること。
- リレーションシップにはきちんと意味を記述する
- 論理モデル上では複合主キーを安易に代替キーで記述しない
- 定義する場合は、必ず候補キーも明記しておくこと（E-R図で表現する方法はないのでメモで追記する）
- 特定の条件でのみ設定するような属性がある場合はサブタイプで表現してみる
- エンティティの持つ属性はなるべく更新タイミングが同一となるもので構成する
しておくと便利
- エンティティがリソース系かイベント系か区別可能な記述（タグなど）を付けておく
- エンティティが核・記述・連関エンティティかを区別可能な記述（タグなど）を付けておく
- 属性の記述はそのエンティティを代表するような重要なものに留める
特に属性の記述についてだが詳細なものは物理モデルで記述するべきである。もし論理モデル上ですべてを記述する場合はツールで重要な属性を色付けするなどほかの属性と区別しやすくするとよい。重要な属性とは主要業務に関係のある情報やそのエンティティのみにある情報である。
また、論理モデルを元に物理モデルを作成するときに実装上の理由からエンティティを分離・結合した場合はその対応を論理モデル方へ残しておくとよい。物理モデルで追加した属性を随時変更する必要はない。だが論理モデルと物理モデル間におけるエンティティの対応付けを怠ると論理モデルを残す意味が半減してしまう。
5.3 テーブル定義書の工夫
残念ながらE-R図を作成しない・もしくは作成してもリバース生成のみで留めるとした場合でもできることはある。だが、本来図で表現するようなことも定義書に書かなくてはいけないために記述量が多くなってしまうのであまりオススメはできない。
必須事項
- 候補キーがある場合はユニーク制約を付けておく
- 制約を付けない場合は、候補キーをテーブル定義に明記する
- 関連があるのに外部制約を付けない場合は、関連があることを明記する
- 特定の条件にのみ成立する関連がある場合、その条件を明記する
- サブタイプのみが持つ関連が該当する
- 関連の多重度に下限・上限がはっきりしている場合はそれを明記する
しておくと便利
- 設計時にエンティティを分類した場合、その分類名をテーブル定義にきちんと残しておく
- 特にリソース系・イベント系程度は記述しておくと便利
- 核・記述・連関も記述しておくとなお良い
6. おまけ
E-R図がとても大事だということは今まで述べてきた通りである。ではそれを書くのに適したツールはなんだろうか。
オススメしたいツールは「A5:SQL」だ。これを用いればE-R図の記法に従った図をきちんと作成できる。サブタイプもふつうに表現可能だ。IDEF1X記法とIE記法どちらも表現できる。また表示レベルも変えられる。エンティティ名のみ・主キーのみ・属性という風にレベルを変えた表示ができる。表示するべき属性も指定できたりする。まさしく論理モデルを書くには打ってつけのツールだ。
E-R図からのDDL自動生成やデータベーススキーマからのE-R図リバース作成もできたりする。作成したE-R図を画像イメージ化もできるし、テーブル定義書の生成もできる。
しかもフリーで使える。使わなければ勿体無い。正直、これフリーでいいの？という出来なのである。これでドメイン定義までできたらまさしく神ツールだったのだが(ドメイン定義機能もあるにはあるのだが機能としては今ひとつである)。
唯一の難点としては、サブタイプを表現した場合E-R図からDDLを自動生成したときにテーブルが分離されて作成されることだろうか。きちんとE-R図の物理モデルを別途作れば済む話ではあるのだが、論理モデルとの同期がとれないためその辺は手動管理していく必要がある。
ちなみに商用ツールの場合はこのあたりの挙動はどうなのだろうか。サブタイプを含むE-R図からDDLを自動生成した場合も同じようにテーブルが分離されるかどうか残念ながらわからない。お高いので触り倒す機会がなかった。
もう一つは「ERMaster」である。A5:SQLはWindows用ツールなのでMacな人には使えない。その点ERMasterはJavaなのでどちらでも使える。
A5:SQLと同様にE-R図の作成からDDLの自動生成・データベースからのE-R図リバース生成・テーブル定義書の自動生成などができる。残念ながらサブタイプの表現ができないため、どちらかと言うと物理モデル寄りのE-R図作成に適していると思われる。
またEclipseのプラグインであるためちょっと動作は重いのが難点か。
ところで、時折ExcelでE-R図を書くような現場もあるのだが、これは絶対にやめた方がいい。E-R図の図や線の形状にはそれぞれ意味がある。そのため形状を間違うと意味まで変わってしまうのだが、Excelの場合はE-R図の意味を考えずに図を作るだけなので誤りの元である。意味の間違ったE-R図なんて存在意義がないしバグの元になる。Excelで書くのだけは絶対に辞めておこう。使うとしても下書き程度に留めるべきだ。