目次はこちら
1. はじめに
プログラマとしてお仕事をする場合何らかのプロジェクトへ途中参加することが多いだろう。特に雇われの身ともなればプロジェクトに最初から参加することなんて稀だと思う。
さて、プロジェクトに参加したときに最初にやることは対象のシステムがどんなものなのかという概要を知ることだろう。ただ、ふつうのプロジェクトならば最初に概要を説明してくれると思うが、システムの大まかな役割とシステムを構成するモジュールの役割を説明する程度で後はドキュメントを読んでおいてね で終わることも多いのではなかろうか。
だが概要の説明は大雑把すぎるし、かといってドキュメントは無数にありどれを読んだものか迷ってしまう。え？ 読むドキュメントがないって？ その場合はソースファイルというドキュメントがあるじゃないか！ ……それこそ膨大な量になるには違いないが。
ドキュメントの数も膨大だが、その中身もまた膨大だ。テーブル定義を見てもテーブルは無数にあり、テーブルが持つ属性もまた無数にある。どのテーブルが重要なのか見当もつかない。とりあえず読んでは見るもののそのテーブルが使われてないとか一時保存用だったとかよくあることだ。
そのため自分の担当する機能に関係がありそうなドキュメントから読んでいくことになる。あちこちドキュメントを見てソースを見て担当機能の概要を把握していく。そうして三ヶ月もすれば自分が担当する機能とそれに関連するモジュールに関しては概要をつかめているはずだ。おめでとう。ドキュメントをあちこち見た成果だ。だが全体としてはどうだろうか。未だ怪しい。そんな状況だったりしないだろうか？
機能毎に詳細を把握してから全体の概要を把握していく。よくあるシステムの把握方法ではある。だがシステムを知る手段としては逆なのではないだろうか？ 全体の概要を知ってから機能毎の詳細を知った方が理解も早くなる。
ではシステム全体の概要を手っ取り早く知る方法はないだろうか？ そんなことを考えて作ってみたのが本ドキュメントである。
さて、この文章の趣旨は以下のとおりである。
- システムの概要を知るには概念モデルを見るのが最適だ
- E-R図はシステムの仕様を簡潔に表現できるすごい図なのだ
- E-R図もきちんとメンテナンスしようね！
そして以下のような方を読者層として想定している。
- ER図？ そんなもんデータベースからツールで自動生成すればいいじゃないか！と思っている人
- テーブル定義の説明があれば図なんていらんでしょ 線を引くのも面倒いし と思っている人
ちなみにER図？ 何それ？ と思ったからはまずはこちら「ER図」を見てみるとよいですよ。ER図における記号の意味を忘れたという方も同様にどうぞ。
