今までは、「ともかく表にしよう」ということで、表を基礎にして、データがどのように振る舞うかを見てきました。表は非常に便利で、まず、データを掲示できる点で、具体性があります。さらに、どんなフィールドがあるかということも記述できるので設計情報も記録できます。完全ではないとしても、これで十分と思ってしまうかもしれません。しかしながら、実際の開発で使うような表（正確には「テーブル」です）にあるフィールドは非常に大量にあります。最近は大画面ディスプレイが一般的なので、少々フィールド数が多くてもそれなりに一覧性はありますが、やはり横スクロールが多くなると見落としがちですし、当然ながら俯瞰して見ることはできません。また、実データを集める必要はあるものの、たくさんのデータを集めると、それはそれで縦スクロールが必要になりやはり俯瞰性は落ちるということになります。
システムの開発に携わる人たちは、もっとコンパクトに、どんなテーブルが用意されているのかということを知りたいわけです。そのために、設計結果をモデルとして記述することになります。代表的な図はERですが、その前に、今までにどういう設計情報が出てきたでしょうか？ まとめると次のようになります。
- 表を特定するための表の名前
- どんな名前のフィールドがあるのか
- どのフィールドが主キーなのか
- どのフィールドが外部キーなのか
- 表同士の関連性はあるのかないのか
- あるとしたら、どのフィールドを照合するのか
- １対多の関係はどこにあるのか
こうした情報をコンパクトに示せれば、モデルとして有益になります。例えば、架空の会社の例をER図に記載するとしたら、次のようになります。なお、ER図にもいろいろなルールがありますが、ここではIE（Information Engineering）記法と言われるものを紹介します。
ボックス１つ１つが表、すなわちテーブルになります。ボックスの上に記載されたのがテーブル名となります。そして、ボックス内部は線で区切られた上部と下部に分かれていて、上部には主キー、下部には残りのキーを記載します。外部キーとなるものはフィールド名の右に(FK)と書かれています。つまり、箱にフィールド名を記載することで、表の骨格を示すことができています。もちろん、実データはありませんが、このER図を読み解く時には、ボックスを表としてみなして、記載されていませんけど、いろんなデータがそこにずらずらとレコードとして存在するということを想像するのは基本です。なお、データベースではフィールドの型を指定する必要がある場合が一般的なのですが、記載可能なER図もあるものの、コンパクトに表現したい場合は省略されている方が都合が良いので、図の中には記載されない場合が多いでしょう。
そして、テーブル間に線が引かれていて、独特のデザインになっています。まず、線があるということは「関連性がある」ということを意味しています。もう少し詰めた言い方をすれば、「直接的な関連性がある」ということです。ともかく、ある表の内容と、別の表の内容が関連している場合には、線を引きます。販売明細と商品が関連していますが、販売明細側ではどの商品への明細なのかを記録するためには商品IDフィールドの値だけを覚えています。ここで、商品名や、図にはありませんが、単価など商品にまつわるざまざまな情報を明細で必要になった場合、販売明細のテーブルと、商品のテーブルを合成、すなわち結合をして、この場合は販売明細に対して商品の情報を商品テーブルから供給するような動作ができたことを思い出してください。要するに「商品マスター」なのですが、いずれにしても、商品名などの実データは、販売明細には存在せず、商品テーブルから取ってくることができるということを示しているのが関連です。
関連の線の一方は単なる線ですが、全てがもう一方の端は3つに分かれています。この形から「カラスの足跡」のような言い方がされるのですが、これは、１対多の関係であることを示しています。この表記が、非常に分かりやすく直感的であることが、ER図を利用する理由の１つであります。いろいろな表を作った時、どのテーブルと、どのテーブルが関連性があり、１対多の関係がどうなっているのか（つまり、どっちが多なのか）ということが明確にわかるからです。関連の線にはそれ以外に、線に垂直の短い棒と、◯があります。この短い棒は数字の１を示していて、◯は0を意味しています。ですが、1と0と読むのではなく、◯は対応するレコードとして、0個〜複数個あり得るということを記載しています。また、1個以上や、0ないしは1個のような書き方もできる場合があり、個数自体をきちんと記述しようとする仕組みも持っています。例えば、関連性の双方が、1対1以上のような表記の場合、多の側に対応するレコードがないということはあり得ないということを設計上想定している可能性が高く、データベースの設計というよりもプログラム等の実装においてそのことを考慮して、開発を進めないといけない場合も出てきます。このことに限らず、データベースの設計は単にデータモデルということだけでなく、システム全体がどのように動くのかを期待する場面も含めて記述しているとも言えます。
そして、ER図を見ながら、実際に納品書を作って、製造部門が製造をして…といったデータの発生や変更などを頭の中に巡らせるのがまずはこの図を読み解く基本です。その時、あるデータを別のテーブルに保存するとしたら、おそらく、１対多、つまり、あるデータに対して、複数の別のテーブルのレコードが関連して、そのためには、外部キーのこのフィールドに、この値を入れて…ということが想像できるということが期待されています。そして、忘れている１対多の関係がないかとか、ここは１対多ではなく、多対多ではないかなど、テーブル間の関連性の検証を一生懸命行います。結果的に各テーブルでの１レコードが何に相当するのかということの把握も行うことになり、１レコードという素なデータの存在意味を加味した上で、関連付けによって現実の世界の表現に至っているかという点をこの図を見ながら検証するのです。
あと、関連性の線に点線と実践があります。前者は非依存、後者は依存と呼ばれています。関連が依存の場合、依存性がある方のテーブルは、角丸のデザインで表記されます。点線で記述する非依存の関連は、関連のないレコードがあっても良いということを意味しています。一方、依存するとは、関連性のないレコードは存在しないということを意味しています。関連づけは、主キーと外部キーで行なっています。つまり、納品書テーブルの納品書IDと、販売明細テーブルの納品書IDで関連づけを行なっています。これらが同一のデータが、納品書とおそらく複数個存在しそうな明細のレコードの関連づけの手がかりになっています。ここで、単に関連づけを行うだけなら、外部キーであれば良く、販売明細テーブルの納品書IDのフィールドがNULLであれば、対応する納品書はないレコードになります。多分、そういうレコードは意味がない、あるいはない方が望ましいということを考えれば、依存があるようにしておくことで、そういうレコードの作成時にエラーが出て作成されなくなります。つまり、データベース自身が設計に反する状態にならないように排除してくれているのです。外部キーを主キーに入れることによって、その値がNULLでないことが期待されます。そして、通常は対応する主キーに存在する値、つまり外部キーに入力して関連づけが可能な値を、外部キーに入れることになるでしょう。その結果、依存関係が確実になりということで、設計時に依存か非依存かをきちんと把握するという意味で、ER図は設計を記述できるということになります。ただ、この依存性と外部キーが主キーになってしまう点については異論がある方もいらっしゃるかと思いますが、ER図ではともかくそういうルールで記述されます。外部キーが主キーになるのを嫌う場合には、全ての関連を非依存で記述して、自分でキーフィールドの定義などを管理すれば良いでしょう。もちろん、依存がある場合にはそれなりの対処はされると思います。
こうしてER図を書けば、実はデータベースに理解可能なテーブル定義のためのSQL文を作成可能です。言い換えれば、テーブル作成のSQL文を、図として表現したのがER図でもあると言えるでしょう。ツールでSQL文を生成できるのは一般的になっています。もちろん、特定のデータベースソフト向けのオプションなどは自分で手で直すことになりますが、ともかくフィールドを書き並べるといった単純作業を一気にやってくれる機能と思えば便利です。また、論理設計と物理設計という２面的な機能があって、画面では日本語などの日常会話で使っている単語で「商品名」などと示し、実際のデータベース上では「prod_name」みたいな変数名のようなキーワードを使うという仕組みも持っているのが一般的です。
ということで、ER図を書きましょうということになるかというと、不便な場面もあります。まず、実際の開発で出てくる表にはフィールドが大量にあって、そのままでは縦に長い表が作られてしまいます。最も、私が使っているastha*professionalだと、フィールドのエリアを非表示にできるので、テーブル名と主キーだけを表示した図にしておくことも可能です。仕様書に記載する時にはフィールド名と主キーだけを表示したボックスにして、フィールドの定義は表にするくらいがちょうど見やすいです。やはり関連図でもあるERは一覧性が欲しいです。全フィールドを収めるとかなりでかい紙に印刷しないといけなくなりますが、フィールドを主キーだけにすると、比較的巨大な設計でも、A4１枚に収まってくれるかもしれません。よく、仕様書にフィールドの表があっても無意味という話もありますが、ER図でフィールドを省略したら、やはりあったほうが良く、フィールドの存在意図や使用方法についての注釈など、ワープロの表に記載する方がよほど自由に記載できて便利です。そういう仕様書の書き方をすれば、フィールドの表には意味があります。
ER図を否定する訳ではありませんが、次回はクラス図を使ってモデル記述する方法について紹介してみたいと思います。