「関連クラス」をデータモデルで解き明かす（前編）

ＵＭＬのクラス図に登場する「関連クラス」はわかりにくい。オブジェクト図を描いてもなかなか直感的にイメージできない難物だが、同じ内容のデータモデルと突き合わせることで意味が明確になる。その過程で、データモデリングにおいて識別子を重要視することの意義もわかってくる。

◆参照関係

まずは「関連クラス」が関係しないノーマルなパターンで見よう。データモデルでの「参照関係」の例と、それに対応するクラス図だ。

データモデルのほうがデータ項目が多いが、それはデータモデリングにおいては「識別子（データモデルで水色に示されている項目）」をエンティティの認識単位とするためだ。だから、データモデリングにおいてエンティティを一覧する作業は、有効な識別子を一覧する作業そのものと言っていい。

いっぽう、クラス図において識別子にもとづくユニーク性は問題にされないため、データモデルで認識されるような識別子が載っていないことが多い。このクラス図も識別子項目が載っていない例として示されている。

これだけ見ると、データモデリングのやり方のほうが、識別子を問題にするぶん面倒な感じがするかもしれない。しかし、識別子を意識することの効用は、親子関係を問題にすることでわかってくる。

◆親子関係

こんどは、親子関係の例とそれに対応するクラス図を示す。クラス図で中央からぶら下がっている形で示されている要素が「関連クラス」だ。

このように、関連クラスはデータモデルで言う親子関係に相当する要件を表現するものだ。データモデル上の識別子の様子を参照関係と親子関係とで見比べてほしい。その形式の違いが、オブジェクトモデルにおいて関連クラスを使う場合と使わない場合との違いも端的に示している。

形式上の違いだけを見てもピンとこない読者のために、参照関係と親子関係の違いを「具体値のあり方の違い」として示す。

参照関係（上）の場合、Ｅ３においてｄ１とｄ３の値の組み合わせが重複してもかまわない。いっぽう、親子関係（下）の場合、Ｅ３においてｄ１とｄ３の値の組み合わせが重複することは許されない。Ｅ３の識別子がｄ１＋ｄ３の具体値の組み合わせがユニークであることを要求しているためだ。

データ項目やエンティティがｄ１だのＥ１といった記号で表されているからよくわからないという読者は、拙書「業務別データベース設計のためのデータモデリング入門」の８０～８１ページを見てほしい。「女性とデート先」の問題として具体的に説明されている。

このように、インスタンスレベルでの参照関係と親子関係の違いは明らかなのだが、関連クラスを用いた場合と用いない場合での違いを「オブジェクト図」で表すことは困難だ。それは他でもなく、オブジェクトモデリングでは、インスタンスを識別するデータ項目が明示的に扱われないためだ。（後編参照）

（後編へつづく）