ユーザーの立場からはモデルを書くことではなくモデルを読むことが大切な技術になるので、そのための説明をしてきたわけですが、読んだモデルが良いモデルなのか悪いモデルなのか知りたいと思うこともあるでしょう。そのために必要なことがらを、今回説明します。

●正しいモデルと間違ったモデル

良いモデルは正しいモデルです。間違ったモデルは例外なく悪いモデルです。ある物事を表現しようとする場合に、正しいモデルは一通りではありません。この意味は、正しいか間違っているかの基準が曖昧だということではなく、ひとつの物事を表現するやり方が複数あるということです。間違ったモデルは表現しようとする物事を表現できていない、という点で「明らかに」間違っています。

例えば組織の例でいうと、部、課、係だけからできている「整然とした」組織の場合、

(組織図1)

(ER図1)

このようなモデルは正しいモデルですが、ここに室という名称の組織があるとすれば、

(組織図2)

ER図1ではこういう「物事」は表現できませんから、間違ったモデルになります。しかし、

(ER図2)

は、組織図1でも、組織図2でも正しいモデルになります。しかし

(組織図3)

のように階層が深くなると、ER図2でも表現できませんから、このモデルは間違ったモデルということになり、

(ER図3)

ならば正しいモデル、ということなります。しかし組織の階層が何階層か、ということを決めなくても、とにかく木構造であれば

(ER図4)

で表現できますから、組織図3の下で、ER図3、4は共に正しいモデル、ということになります。(組織図1、2の下でもER図3、4は共に正しいモデルですが、ER図3では、ある表が「空っぽになる」ということを許容した上での話になります。)正しさという点ではER図3、4の区別はありませんが、どちらが良いモデルかという点では違ってきます。これは後で説明します。

表現すべき物事は、組織図のように具体的な事例として与えられる場合もありますが、通常は

部は課から、課は係から構成される

というようなルールで表現されます。この場合は、そのルールに合致したすべてのケースが表現できるモデルが正しいモデルということになります。

部は課から構成され、課は係または室から構成される

というルールの下では、また別のモデルが正しいモデルになります。

組織は階層構造をもっている

というルールを満足できるのは、上記の中ではER図4だけです。

●良いモデルと悪いモデル

正しいか間違っているかを識別する基準に比べて、正しいモデルの中で良いモデルと悪いモデルを識別する基準はモデルの目的に応じて決まってきます。この基準は大きく分けて2つあります。

ひとつは、前回までに出てきた、モデルが表現しようとする物事のバリエーションや変化に対して頑健であるかどうか、という観点です。これはしばしば、システムを作る立場の人が考慮すべき観点であるといえます。これを汎用性基準と呼びましょう。

もう一つの観点は、モデルが表現するべき対象の物事をどれだけ的確に反映しているか、という観点です。モデルが許容する物事が、表現しようとする物事をすべて表現し(これは「正しい」モデルの条件です)、表現しようとしていない物事を的確に排除できているかという立場に立ったものの見方です。これを情報量基準と呼ぶことにします。(モデルの情報量の考え方は、「ERモデルの情報量」をご覧ください。この記事の中で「物事」と言っているものは、実は「可能世界」と呼ばれる考え方で規定されていて、情報量は「可能世界」の数と関係があります。)

汎用性基準の観点に立つと、「起こりうること」の範囲を実際に表現できなければならない物事の範囲を超えてなるべく広くとり、それをすべて表現できるように抽象化、メタ化を駆使して、「何が起こっても大丈夫」という風に作ったモデルがよいモデルとされます。

部は課から、課は係から構成される

というルールの下では、ER図1もER図4も「正しい」モデルですが、部、課、係以外の組織の登場や、組織が3階層以上になるかもしれないということは、システムを作る立場ならば当然考慮しなければならないことで、それを考慮したER図4の方が「良い」モデルということになります。

情報量基準の観点に立つと、データモデルを書くということは、それらの概念の意味を明らかにするということです。「××とは○○のことである」という文で未知の××を既知の○○で説明することが、通常「意味を明らかにする」という行為だと考えられますが、意味という言葉を広くとらえて、××や○○という言葉の使われ方を理解することが「意味を明らかにする」ことである、という意見があります。この考え方は”意味の使用説”と呼ばれていますが、データモデルを書くという行為はそういう風に「意味を明らかにする」行為です。

組織図1を表現しようとする場合、情報量基準の観点からは、ER図4は、部、課、係の意味を明らかにしていない、ということになり、ER図1の方が「良い」モデルということになります。さらにER図1の場合、

【部】のドメイン　｛総務部,経理部,営業部｝
【課】のドメイン　｛予算課,決算課,東日本営業課,西日本営業課｝
【係】のドメイン　｛首都圏営業係,京阪神営業係｝

となり、ER図4の場合は【部】【課】【係】の区別がないので

【組織】のドメイン　｛総務部,経理部,営業部,予算課,決算課,東日本営業課,西日本営業課,首都圏営業係,京阪神営業係｝

となります。(それぞれのドメインを可変長の文字列、とか「ゆるく」定義することもできますが、ここでは最も狭く解釈します。)

すると、3階層の【部】【課】【係】の階層構造の配列に限定しても、

(組織図4)

このような「ナンセンスな」組織は、ER図1では排除されますが、ER図4では受け入れられてしまいます。

しかしルールが

組織は階層構造をもつ

であるならば、もともと組織図4のようなケースもこのルールに合致していることになるので、ER図は【部】【課】【係】については何も述べる必要がなく、代わりに組織の意味を明らかにすればよいので、汎用性基準によっても、情報量基準によってもER図4が良いモデルになります。

前回紹介した「たてもち」は、もっとも極端な例で、【属性】や【属性値】という表を使って、物事を表現しています。情報量基準の観点に立てば殆ど何の説明にもなっていないわけですが、汎用性基準の観点に立てば、きわめて「良い」モデルになります。

汎用性基準と情報量基準の2つの観点は、どちらが正しいということではなく、良いモデルという評価が、目的との関係性で決まってくる、ということに他なりません。

●システムを作る人は何を考えているか

今までの説明では、「表現すべき物事」が決まった場合には「正しいモデル」と「間違ったモデル」は確定する、という言い方をしましたが、実は「表現すべき物事」として何を想定するかということについても、しばしば意見が分かれます。システムを作る立場からは「表現すべき物事」を与えられた仕様より広く考えることが好まれるのです。

部は課から、課は係から構成される

という仕様を与えられても、優秀なシステムエンジニアは「実際に表現すべき物事」は、

組織は階層構造をもつ

だと考えます。これは「表現すべき物事」がしばしば仕様を超えて変化する、ということに対して、作ろうとしているシステムが多少の手直しで対応できるように予め備えておく、という判断に基づくものです。優秀なシステムエンジニアは、こうして仕様を広く解釈したうえで、汎用性基準の観点から「良い」設計をしようとします。

こういう判断を適切にできることが優秀なシステムエンジニアに求められる一つの能力です。場合によってはリスクを予見し、ある場合には今までの痛い経験から、彼らは仕様に対してどのような拡張をあらかじめ織り込んでおくのかという洞察力を働かせます。

データモデルはシステム開発のためだけにあるのではありませんが、やはり日頃データモデルに出会う場面というのは、システム開発の局面であることが多いと思います。多くの場合、情報量基準に従ったモデルは業務で使われる概念に近いレベルで記述されるため、読む立場からは理解しやすいのですが、汎用性基準を重視したモデルは、抽象化のレベルが高く、読みにくくなります。しかしそれでも、あえてそういうモデルを選ぶべき場合もあるのです。

ご意見募集

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