この連載は今回で最終回です。最後にデータモデルを作る人たちのことについて考えてみたいと思います。

いままで、モデルのユーザーの立場からモデリングに関する必要な知識を説明する、という観点から連載を書いてきました。モデルの（というよりER図の）表記法の規約に関することだったり、パターンの理解だったり、評価の基準だったりという内容だったわけですが、その前提として「誰かが正しいモデルを書いてくれている（良いモデルかどうかはともかく）」ということを前提としてきました。

が、残念ながらこの前提は、いつも満たされているというわけではありません。正しいモデルを書く技術者が払底していること、モデルを書く機会がないことが大きな理由です。この2つは鶏と卵の関係なので、ある意味ではデータモデリングは負のスパイラルの中にありますが、そのあたりの構造を考えてみたいと思います。

ひとつには、データモデルの利用がソフトウェア開発の局面に限定されてきた、ということがあげられます。元々この技術は1970年頃、ソフトウェア開発の技術として誕生し、システムエンジニアの社会の中で教育され、継承されてきました。データマネジメントというもっと広い分野の中のあちらこちらで応用できるにも関わらず、このような隣接部門からデータモデルが注目されることはほとんどありませんでした。

ふたつ目の要因は、オブジェクト指向をはじめとした、新しいプログラミングパラダイムの流行です。データモデル、特にER図の考え方は、オブジェクト指向とは異なっています。データモデリングの知識を継承してきたシステムエンジニアが、この流行に巻き込まれ、モデリングの知識を継承することをやめてしまいました。これは技術の誤解に基づくものですが、議論しはじめるとこの連載の範囲を超えてしまいますので、やめておきます。

この負のスパイラルから脱出するためには、

1）データモデルの適用領域を広げていくこと
2）広い分野の技術者に知識を伝え、継承していくこと

が必要になります。裏返しの鶏と卵なのですが、とにかくどこからか一歩を踏み出さないとはじまりません。この連載もその一つの試みです。

1）データモデルの適用領域を広げていくこと

データモデルはデータの「意味」や「定義」に関する豊富な情報を含んでいます。データモデルを書く知識の中には、「意味」や「定義」を体系的に、標準化したやり方で記述するやりかたが含まれています。

（この連載の中で解説したデータモデルを読むために必要な知識よりも、若干沢山のことを理解する必要があります。）標準化されていますから、あるプロジェクトの中での約束ごと、などというモデルと違って、プロジェクトをまたがり時間を超えてモデルの内容を伝えることができます。

このような観点からみると、データモデルの用途をデータベースの設計のためだけに限定するのは、いかにももったいない話だということになります。例えばデータのセキュリティを考える場合、例えば分析作業に伴ってデータのリネージを記録する場合、例えば誤った値を含むデータのクレンジングをする場合、いずれもデータモデルがあるか、そうでなくてもデータモデルを書く知識を持っていれば、効率的で質の高い仕事をすることができます。

会社の中にある沢山のプロジェクトの要員数をプロジェクト別・年度別に記録したデータがあるとします。このデータの素性を厳密に明らかにするために、実際にデータベースにデータが入っているかどうかは関係なく、

このようなデータモデルを書いて

と決めれば、言葉で延々と説明するよりもはるかに的確に意味が伝わります。《着任年月》《離任年月》などの「意味」はER図、データディクショナリからわかります。【要員】が複数の【プロジェクト】に同時にアサインされている可能性があること、一つの【プロジェクト】に複数回【アサイン】される可能性があること、どの【プロジェクト】にも【アサイン】されていない【要員】がいる可能性があること、なども、ER図を見ればわかるからです（全【要員】が最低1つ何かの【プロジェクト】に【アサイン】されていなければならないのでしたら、ER図はこのようにはなりません）。さらに上記の定義では、Ｘ年度に同じ【要員】が2回以上同じ【プロジェクト】にアサインされた場合、その回数だけカウントされてしまうことまでわかってしまいます。

データモデルが幅広い応用分野を持っていることを世の中の人々に認めてもらうために、実際にデータモデルを書いて、役に立つことを実証しなければいけません。もっとも前回書いたように、「何が良いモデルか」は利用目的によって決まってくるので、データベースの設計のために書いたモデルをそのまま他の目的に使い回すのは限界があります。

2）広い分野の技術者に知識を伝え、継承していくこと

データモデルの教育には、原理に関わる知識を学んだ後、優れたモデルをたくさん読むことが有効です。ソフトウェアの開発の現場では、知的所有権の問題があって、データモデルがプロジェクトの外部の人たちの目に触れることはほとんどありません。これが、知識の継承を困難にしているひとつの理由なのですが、ほかにデータモデルに触れる場がないわけではありません。ひとつ参考書をあげると、

The Data Model Resource Book vol.1-3

Len Silverston

この本には業務別、業種別のしのかも質の高いデータモデルが沢山収録されています。このほかWeb上にもときどきデータモデルが公開されています。たとえば

Oracle Retail Data Modelリファレンス

それなりに訓練を受けた技術者が書けば「正しい」データモデルは必ず書けます。目的に依存するのでそれが「良い」モデルかどうか一概には言えませんが、それでも訓練を受けた技術者が作ったモデルは「そこそこ良いモデル」になっています。ですから、データモデルを秘技奥伝のように知的所有権で守ることはあまり意味がありません。むしろユーザー企業がこの「業界の慣行」を破ることで、優秀な技術者が育ち、データモデリングのレベルがあがっていく正のスパイラルが始まって、ユーザー企業自らが利益を得ることになると思います。

が、それを待っていてもしょうがないので、JEMUGという団体では「データモデリングコンテスト」という催しを年に1回開催しています。

JEMUGデータモデリングコンテスト

この催しには、JEMUGのメンバー以外の方も参加できます。毎回共通のテーマに対してそれぞれの参加者がデータモデルを作ってお互いに見せ合うことで、技術のレベルを上げていこうという意図のもとに開催しています。

JEMUGはこの連載を掲載している日揮情報システムという会社が販売しているERwin Data Modelerというデータモデリング支援ツールのユーザー会でしたが、現在はユーザーでなくてもデータモデリングに関心のある方でしたら、どなたでも加入できます。私もJEMUGの一員ですので、日揮情報システムを通せば連絡はつきます。データモデリングの負のスパイラルを断ち切り、正のスパイラルに変えていくためにできる範囲のことはお手伝いさせていただきますので、ご連絡をお待ちしております。

それではまた、どこかでお目にかかりましょう。

ご意見募集

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