« モデリングセッションに必要な能力「共感力」 | トップページ | 「関連クラス」をデータモデルで解き明かす(後編) »

2005.04.17

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

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

◆参照関係

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

sansyou

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

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

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

◆親子関係

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

oyako1

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

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

instance

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

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

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

(後編へつづく)

|

« モデリングセッションに必要な能力「共感力」 | トップページ | 「関連クラス」をデータモデルで解き明かす(後編) »

コメント

関連クラスの場合は、基本的にセマンティクス上の問題はないです。「関連クラスのノーテーション」=「(渡辺さん言うところの)親子関係に挟まれたエンティティ」という意味ですから。たんに関連クラスの規則を知っているかどうか、という慣れの問題だと思います。
UMLのクラス図でセマンティクスが甘くなるのは、[商品]1-*[在庫]*-1[倉庫]のケースで、[在庫]を(関連クラスではなく)通常のクラスで表現する場合です。この場合、主キーを指定しないと、在庫が「商品/倉庫の組み合わせで一意」であることが表現できません。UMLでは限定子やノートアイコン、制約言語(OCL)といった道具を用意していますが、このケースではERモデリングの方が確かに厳密だと思います。特に三項関連の場合にこの問題は顕著です。

投稿: ひらさわ | 2005.04.17 23:29

>ひらさわさん

確かにノーテーションとしての問題はないですよね。私が問題視しているのは、「関連クラスの独特な意味の理解」が「余計」に必要になるという点です。それは関連クラスには、オブジェクトモデリングの世界観とは異質な視点が盛り込まれているためだと考えます。これは「分析モデル」と「設計モデル」とのギャップの問題につながっていて、後編で書くネタだったりします。

投稿: わたなべ | 2005.04.18 08:01

なんだか話が噛み合ってないような気がします。
「関連クラスがオブジェクトモデリングの世界観とは異質な視点」という意味がよく理解できませんでした。参考までに私が理解する「DOAとオブジェクトモデリングの世界観の違い」を書いておきますね。

・DOA
エンティティを「集合」の単位とし、「集合の要素」同士の結びつきを識別子で表現する。
・OOA
エンティティだけでなく、関連も「集合」としてとらえる。(このため、識別子を指定する必要がない。)

また次のような違いもあると思います。
・DOA
すべてのエンティティを一意に(絶対的に)識別できることが基本。このため、RDBではクエリー条件を指定することで、すべてのエンティティに直接アクセスできる。
・OOA
エンティティ間の結びつきは相対的であり、ナビゲーションでアクセスする。このため、ODBでは、すべてのエンティティがイニシャルコンテキストから始まるネットワークで表現される。

私はこの件に関しては「優劣」というよりも「違い」と考えています。
DBMSの普及度合という観点からするとRDBの優位性は間違いないところですね。ただし、RDBを使わないアプリケーションの場合は、DOAがぎこちなくなります。(これはビジネスアプリケーションであってもそうです。)

投稿: ひらさわ | 2005.04.18 12:16

>ひらさわさん

DOAとOOAの違い、面白いですね。私が「関連クラスがオブジェクトモデリングの世界観とは異質な視点」だというのは、2つ目の比較に近いことになるのかな。また「後編」にツッコミを入れてもらえたらうれしいです。

投稿: わたなべ | 2005.04.20 14:04

ドメインの分析をしている時、関連クラスは使います。
T字形ER図で対照表、対応表の有るところには、ほぼ同じだけの関連クラスが出てきたりします。
ただし、Javaという言語で実装をしようと試みると、関連クラスは実装できません。それぞれと関連を持った一つのクラスになってしまいます。
それと、商品番号などの識別子は、単なる属性になります。そして、その属性の制約が、既にその値を持ったインスタンスが他に無いこと、ってなるだけだと思います。
私はT字形ER(TM)を使っているので、いわゆるDOAの立場はよくわかりません。
T字形ERの正体は、所謂大福帳的事業(何とか番号や何とかコードでものを識別する)の解析に限定したOOAの拡張だと思う。

投稿: いなみ | 2012.08.30 19:41

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「関連クラス」をデータモデルで解き明かす(前編):

« モデリングセッションに必要な能力「共感力」 | トップページ | 「関連クラス」をデータモデルで解き明かす(後編) »