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

前編の最終段落で「関連クラスを用いた場合と用いない場合での違いを『オブジェクト図』で表すことは困難だ」と書いたが、それは筆者の間違いだった。関連クラスの記法をそのままオブジェクト図に持ち込めばよいことになぜか思い至らなかったためだ。実際、オブジェクト図で「参照関係（通常のクラス）」と「親子関係（関連クラス）」との違いは明確に示せる。問題は「属性のない関連クラス」の扱いで、それが後編のテーマである。

◆識別子を意識することの意義

データモデリングに対する次のような批判を聞くことがある。

データモデリングでは、識別子を設定するために『作為的なデータ項目』が盛り込まれる。いっぽうオブジェクトモデリングでは『今そこにある現実』のみが扱われるので、より自然なアプローチである。

「作為的」という批判は的外れだ。そもそもデータモデリングは「現実を写実するための手法」ではなく、以前にも書いたように「帳簿組織の論理構造を検討・視覚化するための手法」だ。そして、それぞれのビジネス形態に応じた「効果的な帳簿組織の論理構造」はきわめて作為的な思考の結果として生み出される。その作為性は、現実に触れることのできない概念を持ち込むことで現実をうまく認識しようとする「言語活動」の作為性そのものだ。

たとえば、本来、それぞれの１日に「名前」はない。にもかかわらず、「日付（日の名前）」という作為的な概念を語彙の中に盛り込むことによって、個々の１日を識別して日々の活動をうまく管理できるようになる。同様に、「受注番号（受注の名前）」という作為的な概念をモデルに盛り込むことによって、個々の受注単位を識別して営業活動をうまく管理できるようになる。データモデリングは「対象を誠実に写実するための、洗練された科学研究」というよりは「対象を自分にとって都合よく扱うための、洗練された言語活動」と捉えたほうが正確だ。

識別子が明示的に扱われることの実際的な効用はその先にあって、識別子を組み合わせることによって、有用な概念を手に入れることができるようになる。言い換えれば、考案された単独の識別子項目の「組み合わせ」を積極的に意識するおかげで、モデルの「エンティティの網羅性」を配慮できるようになる。

たとえば、ｄ１、ｄ２、ｄ３という単独での識別子項目が認識されているのであれば、ｄ１＋ｄ２、ｄ１＋ｄ３、ｄ２＋ｄ３、ｄ１＋ｄ２＋ｄ３、という４つの組み合わせを識別子とする「思いがけず便利なエンティティ」が存在する可能性がある、とデータモデリングでは考える（このような配慮は第四正規化、第五正規化と呼ばれたりする）。

これはデータモデリングの魅力のひとつでもある。まったく異質な概念を、それらの識別子を複合させることで「概念の子供」を生ませることができる。たとえば「犬」と「電信柱」の２つの概念を結婚させて「犬と電信柱の組み合わせにおける諸問題」というキテレツな概念を生み出して形式化できる。だから、モデラーは「概念の仲人」であり「概念のやり手ババア」である（ひどい喩えだ）。

◆関連クラスは「鬼っこ」

「関連クラス」を用いることによって原理的には同様のモデリングができる。しかし、オブジェクトモデリングはもともと識別子を意識しない枠組みなので、オブジェクトのユニークな組み合わせを配慮するという動因が弱い。

その傾向は属性をともなわないクラスの扱いに顕著に表れている。次の例は、属性項目を伴わない子エンティティ（Ｅ３）が含まれるモデルの例だ。分析レベルのクラス図では、属性を持たないクラスはまともなクラスと認められないため、Ｅ３を載せない。これを見ていると筆者は不安な気持ちになる。それが「両端のインスタンスのユニークな組み合わせ制約」を意味するのか、「未分析のクラスがあるゆえの偶発的な多対多関係」なのかを見かけ上区別できないからだ。

いっぽうデータモデリングでは、属性を持たないエンティティであっても堂々と載せてしまう。というより、どんな属性が載るかというのはデータモデリングでは一義的な問題ではない。重要視されているのは「有効な識別子を網羅すること」であって「属性項目を網羅すること」ではない。属性が載らなければたまたま載っていないだけの話。これは、オブジェクトモデリングにおいて、属性やメソッドの認識がクラスを切り出す出発点になっているのと対照的だ。

関連クラスを「オブジェクトの関連そのものをクラス化したもの」と理解すれば、オブジェクトモデリングの世界に素直におさまっているようには見える。しかし、「興味深いオブジェクトの関連であっても、その上に管理すべき属性やメソッドが存在しないのであればクラスとはみなさない」という姿勢は奇妙に中途半端で、筆者には識別子項目を明示的な管理項目として扱わないことの弊害に見える。なんだか、関連クラスという良いアイデアがオブジェクトモデリングの世界観に邪魔されている感じだ。というより、関連クラスはオブジェクトモデリングの世界観に馴染まない「鬼っこ」のようだ。

◆上流工程と下流工程は本来的に異質

関連クラスは、オブジェクト指向言語ではそのまま実装できないという点でも「鬼っこ」ぶりを発揮している。分析モデル上に描かれた関連クラスを設計モデルに変換する際には、関連クラスを使わない形に、ＯＣＬ（オブジェクト制約言語）や注釈を用いて注意深く書き換えなければならない。

これは、オブジェクトモデリングがシステム開発の上流から下流までを一気通貫に扱える便利な枠組みだと強調したい向きには悩ましい問題だ。分析モデルと設計モデルとの間で「詳細度の違い」では説明できないギャップを生じさせてしまうからだ（これゆえに、関連クラスの記法を使いたがらないモデラーもいる）。

しかし、そもそも上流工程と下流工程とは本来的に異質な枠組みではある。上流であればあるほど、問題領域（ドメイン。たとえば「企業システム」は「ゲームソフト」や「組込みソフト」に並立するドメインのひとつ）に固有の、実装の枠組みとは異質な問題が増える。

だから、上流と下流とでギャップがあるのは当たり前のことで、両方で共通に使える図面体系を考案するのは、相対性理論と量子論を統一するくらいに難しい。無理にやれば体系が際限なく複雑珍妙化するのが目に見えている。両者の異質さに開き直って、ドメイン毎に固有な上流用の枠組みをゼロベースで組み立てたうえで、下流との連係を考えるほうが現実的だ。

「いや、それでもあきらめない。こういうことはやってみるだけの意義がある」というのなら止めはしない。困難な課題に果敢に挑戦する姿もなかなか漢気（おとこぎ）があってよろしい。しかし、それにつき合わされる顧客は気の毒である。