データモデルに「概念モデル」、「論理モデル」、「物理モデル」の３種類があることは広く理解されている。しかし、これらを律儀に作成・保守しているプロジェクトがどれだけあるだろう。ただでさえデータモデリングはないがしろにされがちなので、３種類のデータモデルを作成しているプロジェクトなど例外的といえそうだ。それもそのはずで、全種類をコンプリートすることに意義がないとはいえないが、コストパフォーマンスが悪すぎる。どういうことか。
3種類のデータモデルを作成・維持するためには多大なコストがかかるが、コストの投入量と効果の関係は図1のようになる。経済学でいう収穫逓減の法則がここでも働いている。データモデリングすることで設計品質もプロジェクトの成功率も向上するが、手間が増えるにしたがって効果は頭打ちになる。「全種類コンプリート」を達成するようなレベル(a)より少ないコストで極大値に近い効果を得たい(b)。あるいは、同じコストでより大きな効果を得たい(c)。そのためにどんな工夫が出来るだろう。
答を示す前に、概念、論理、物理の違いをおさらいしておこう。この考え方はもともと、米国のANSIが1975年に提案した「3層スキーマ」がもとになっている。これには外部スキーマ、概念スキーマ、内部スキーマが含まれている。ここで言うスキーマとは「データ構造」くらいの意味で、データモデルの別名と考えてもらえばいい。
外部スキーマとは「ユーザが認識するデータの形」で、ようするにUIに相当するものだ。概念スキーマは「データストア上で保持されるべき概念とそれらの関係」を図示したもので、RDBの利用が前提とされない点が特徴だ。内部スキーマは「（RDB等の特定のデータストア技術を前提とする）コンピュータ上で扱われるデータの形」である。
この「内部スキーマ」をさらに「論理スキーマ」と「物理スキーマ」に分けることで、概念、論理、物理の3種類のスキーマが揃う（図2）。論理と物理では、論理フィールドの扱いやフィールドIDやデータ型といったフィールド属性に関する扱いが異なっている。一般的には、論理モデルではフィールドが日本語で示され、物理モデルではフィールドIDとデータ型とが示されると理解されているが、違いは厳密ではないしそれほど重要でもない。
話を戻そう。より少ないコストでデータモデリングの効果を高めたい。そのためには「論理モデル」だけを作成・維持すればよい。なぜ「物理モデル」が要らないのか。テーブルの物理定義については、テーブル関連を伴う図面ではなく、伝統的なテーブルレイアウトの様式でじゅうぶん管理できるからだ。ただし、最新の論理モデルから物理定義用のcreate文やalter文を取り出せるような仕掛けはほしい。DBの実定義とスムーズに連係するためで、そのためにも専用のエンジニアリングツールが欠かせない。
ではなぜ「概念モデル」まで除外されるのか。まあ作るべきでないとは言わないが、いかんせん意義が薄いからだ。記法にもよるのだが、概念モデルと呼ばれる図面の多くは「当たり前な事実の箇条書き」以上のものではない。その端的な例として、IPAによる応用情報技術者試験の設問を取り上げよう（図3）。
答は「ウ」なのだが、モデルといい設問といいズッコケそうにならないだろうか。従業員と部署とがN対Nであることが読み取れる図面の何がうれしいのか。本来であれば、1対Nの組み合わせに因数分解された概念構成が主キーを明示した形で示されなければいけない。これでは偵察から戻った斥候が「敵の数ですか...けっこう多いですね」と報告しているようなものだ。システム要件であれば「効率的に出荷できるようになること」と書いてあるようなもので、何の役にも立たない。
それにしても、こういった中途半端な表現をむざむざ許してしまうという意味でも、UMLはデータモデルの記法に向かないのではないか（本ブログでの参考記事「UML版在庫データモデルの問題」）。主キーやこれにもとづく論理構造を意識する必要のない図法では、容易に「当たり前な事実」や「お花畑のような要件」の箇条書きが生み出されてしまう。主キーが意識されないので、複合主キー（ナチュラルキーではない）にもとづく関数従属性も見落とされやすい。
こういった批判に対して「概念データモデルは、観測・想起された概念とそれらの関連を淡々と示すための図面である。従業員と部署がN対Nであることも、分析結果として表明する意義はある」との反論があるかもしれない。もっともらしく聞こえるが、そういった分析重視・手順重視の設計スタイルに私は昔から疑問を感じている。その種のスタイルには創造性や楽しさといった要素が欠けているように思う。
もちろんデータモデリングには事前の分析作業が必要だが、そのコストと効果も図１で示したような関係をとる。ところが、多くのプロジェクトは「分析すればするほど的確なデータモデルが手に入る」と信じているのか、不毛で陰鬱な分析祭りと化している。最悪の場合、コンサルあたりが「我々は手間暇かけて素晴らしい概念モデルを完成させた。あとはよろしく」と言い残して去るようなことが起こる。そんな詐欺まがいの商売ネタにされるリスクを思えば、概念データモデルを正式な成果物と認めることにはデメリットのほうが多いのではないだろうか。
いっぽう、熟練した開発者の設計姿勢においては、分析と創造のバランスが取れている。彼らはAs-Is（現状）の分析作業と併行して、To-Be（あるべき姿）の論理データモデルをとっとと描き広げてしまうものだ。To-Beが出来上がれば、As-Isにこだわる意味はなくなる。概念データモデルのような経過的成果物を経由する必要もない。業務システムのデータモデルというのはパターンの組み合わせでしかなく、当該事業に固有な特殊性に注目するだけで済むからである。作業に時間がかかり過ぎているとしたら、設計担当者の人選ミスを疑ったほうがいい。ようするに、データモデリングにはスキルは必要だが工数は不要なのだ。
そういうわけなので、概念モデルと物理モデルは作らなくていい。しかしそれだけではモデリングの工数が減る（図1-b）だけで、効果が高まる（図1-c）わけではない。そこで、このブログで何度も説明しているように、論理モデルにもとづいて動作する実システムのプロトタイプを組み立てることをお勧めしたい。なぜなら、実際にシステムを動かしてみなければ、論理モデルの細かいレベルの妥当性まで検証できないからだ。使いやすいローコード開発基盤はいくらでもある。こんな時代に、プロトタイプによって検証されていないデータモデルを信用してはいけない。
結論。工数を抑えてデータモデリングの効果を最大化させる。そのために、削減すべき作業は「概念モデルと物理モデルの作成・維持」で、追加すべき作業は「論理モデルにもとづくプロトタイピング」である。効果的な業務システムを残業せずに生み出すための秘訣として参考にしてほしい。
