ＥＲ図を読むために必要なルールは、一通り説明しましたので、今回からは何回かに分けて特徴的なデータ構造がＥＲ図でどのように表現されるかを説明します。ＥＲ図におけるモデリングパターンのようなものとお考えください。ＥＲ図を書く場合には、実際には１対多の関係を一つ一つ吟味しながら書いていることはそれほど多くはなく、あるデータ構造に当てはまるものはあるモデリングパターンで表現する、というやり方の方がむしろ多いくらいです。ベテランのモデラーは、複雑なデータの関係の中に、パターンに当てはまる部分的な構造を素早く発見します。これでずいぶん時間の節約になるのです。

ＥＲ図を読む立場でも、モデリングパターンの知識があれば、書き手の意図を素早く的確に理解できるようになります。すでに取り上げた多対多の関係を解消する「交差」なども、パターンの一つと見なしてもよいかもしれません。

今回は「木構造」取り上げます。第１回で「木構造を越えて」と言った以上、木構造がＥＲ図という「表」の組み合わせの構造で表現できなければいけないはずです。そのためのモデリングパターンはきちんと用意されています。

木構造は至る所にあって、NDCコードもそうですし、官庁統計の職業分類や商品分類、生物の分類体系も木構造をしています。データモデルの世界で木構造を説明するときに出てくるのが「部品展開」「工事積算」「組織」などの構造です。部品展開は完成品を部品に、その部品がさらに小さな単位の部品に・・・と展開されていきます。工事積算は大きな工事を小さな作業に分割していって、最終的にはそれぞれの単位に所用資源やコストが与えられます。

ここでは組織の構造を例に木構造を説明します。会社の中には部とか課とか係とかの組織があって、部は課を含み、課は係を含むという構造になっています。二つ以上の部にまたがる課はありませんし、二つ以上の課にまたがる係もありません。

この関係をそのままＥＲ図に書くとこのようになります。

【部】

【課】

【係】

【部】【課】【係】の構造を示すだけならこの書き方は間違っているわけではありませんが、たとえば、総務部の中に新店舗開設準備室などという組織ができ、さらに新店舗開設準備室の下に課や係ができると、このモデルはとたんに修正を余儀なくされ、複雑化していきます。

これを防ぐためにこういうモデルを考えます。

【組織】という表はいままでの【部】【課】【係】【室】を抽象化して全て包含したものを表します。それどころか、これ以降【本部】ができようが、【センター】ができようが、とにかく木構造になってさえいれば、どのような【組織】でも受け入れることができます。

【組織】が自分自身に対して参照関係を持っています（自己参照関係などと言います）。連載の３回目で説明したように、どの行とどの行が対応してるかを明示するために、参照先の行の主キーが参照元の行になければなりません。自己参照の場合も同じで、《組織コード》という主キーが参照元の《親組織コード》に記録されます。木構造ですから一つの親に対して子は複数あります。子からみれば親は（あるとすれば）ただ一つに定まります。【組織】表の各行は子を表し、その中に自分の親の行を表すために《親組織コード》を持っていると考えてください。

この表の中に行（タプル）はこのように格納されています。（《組織コード》《親組織コード》は、先ほどの例とは別に付け替えています。）

【組織】

余談ですが《組織コード》をつけるときにたとえば最初の２カラムを部コード、次の２カラムを課コード、次の２カラムを係コードにして・・・などと設計して、そのコード体系に依存したプログラムを書いたりすると、前にみたように本部や室や、この体系に当てはまらないような組織改編があったときにはコード体系が破綻するだけではなくプログラムも書き換えになります。このような事態が予測される場合、コードは「その行を識別する」と言う機能だけを担うものと考えて、カラム毎の意味など持たせずにただ連続した番号や記号をつける（サロゲートキーとか意味なしキーと呼ばれます）、と考えた方がシステムが環境の変化に対して頑健になります。「構造」はコード体系ではなくデータの関係で表現するのが鉄則です。

“総務部”“経理部”“営業部”のように、木構造の「てっぺん」は《親組織コード》を持たないので、その列は空欄になります。空欄のことを、データベースの用語では null と呼びます。そこに値がないことはデータモデルを読む立場からはさほど問題はないのですが、実際にデータベースや、データベースを扱うプログラムを書く立場からはとても厄介な問題を引き起こしますので、なるべく null を使わずにモデルを書こうという考え方もあります。その場合は木構造はこういう表現になります。

ルートというのが、木構造の「てっぺん」のことです。《ルート組織》には《親組織コード》は不要です。《ルート以外の組織》は必ず《親組織コード》があります。こうしておけば、 null の問題を回避することができますが、多くの場合、木構造は自己参照関係を使って表現されます。

データモデルを書く立場の人は、世の中の想定される範囲の変化が、モデルを修正することなしにきちんと受け入れられるように考えてモデルを設計します。【部】【課】【係】の代わりに【組織】という表を作るという風な「抽象化」はしばしばこういう目的のために使われます。抽象化の度合いをどんどん上げていくと、おおよそ世の中に存在する全ての【対象】とその間の【関係】からなるモデルを記述することが原理的には可能です。ですがそのモデルは何でも受け入れることができる代わりに何も表現していないモデルになります。ある範囲の変化をきちんと受け入れることができる一方で、何を表現しているのかがわからなくなるほど抽象的では「ない」モデルが、よいモデルですし、モデルを読む方も適切な抽象化レベルになっているかを考えながらモデルを読む必要があります。

モデルを読む人たちが理解しやすいレベルの抽象化に比べて、システムを作る人たちが適切と考える抽象化のレベルの方が高い、という傾向にあります。システムを作る人たちは、世の中の変化に対して頑健なシステムを作るためにそうしているのですが、その両者の橋渡しをするのもモデルを作る人に課された使命だといえるでしょう。

ご意見募集

ここまでの内容で質問やコメントがある方は、 編集部までお問い合わせお問い合わせ下さい。
「入門」なのであまり高度な質問にはお答えできませんが、みなさまの役に立ちそうな内容については、この連載の中でとりあげたいと思います。