DBマガジンのモデリング特集を読んで思ったこと
遅ればせながら、DB Magazineの12月号*1に掲載されているモデリング特集の記事を読んだ。同僚の石川さんが大作22ページの記事を書いている。概念モデリングから、論理設計、物理設計までのプロセスの解説で、仕事も忙しい中でよくこんな長い記事を書いたものだと感心した。
（→DBマガジンのページへ、→Amazonへ）
彼とは以前同じ案件を担当したこともあり、ほぼ同じスタイルでモデリングをやっているので、考え方もよく似ているらしい。最初にUMLで概念モデルを作ってエンティティの切り出しを行い、その後で識別子を考えてERモデルに変換するアプローチである。ただし、この記事の副題の「UMLによる概念モデルをER図に"崩せ"」は、ERモデリング派の多くの人には納得できない表現だろう。
自分は、RDBMSを永続記憶媒体として採用する場合、データモデルは抽象度に応じて次の3段階になると考えている。（これは石川さんもほぼ同じ考えのようである。）
- レベル1：概念モデル：エンティティを切り出して、インスタンスの単位をきちんと定義したモデル
- レベル2：論理モデル：エンティティに識別子を定義して、関数従属で表現したモデル
- レベル3：物理モデル：ディスク容量やパフォーマンスを考慮したモデル
「UMLモデリング・レッスン」で解説しているのはレベル1である。（このブログで「ERモデリングレッスン」として補足しているのはレベル2である）。
しかしERモデリング派の多くの方は、レベル1は存在しないと考えていると思う。以前渡辺幸三さん（→設計者の発言へ）に会社の勉強会で喋っていただいた時にこんな出来事があった。渡辺さんは配付した資料をもとに「エンティティの関係には“親子関係”、“参照関係”、“派生関係”の3種類があります。ほら、この親子関係のエンティティをみてください。子エンティティの識別子に親エンティティの識別子が含まれているでしょ？だから親子関係なんですよ。」と説明したのである。これは自分にとってはちょっとした驚きだった。だって、識別子がそうなっているから親子関係なのではなく、親子関係と先に認識したからこそ識別子をそう設定したはずだから。
しかしこの議論はおそらく意味がないのだろう。なぜならERモデリングでは関数従属が原則なので、レベル1は表現しようがないから。「鳥を見て”鳥”という言葉を思いつく前に、どうやってそれを鳥と認識したか」みたいな話なのかも知れない。（ただし哲学や認識論は得意じゃないので深入りするのはやめておく。）
実務的には、レベル1、2、3の中で、どのモデルを作って、どのモデルを残すかは、トレードオフ判断の問題である。ただしシステムをまともに動かす気があるならレベル3は必須である。したがって問題はレベル1と2の扱いである。自分は、以前ならレベル1と3を残すべきと確信していた。しかし最近あるプロジェクトに関わったことで、（識別子のない）クラス図よりも、論理ER図の方が読める人口が多いことを痛感した。したがってプロジェクトの状況やメンバー構成によっては、1を作らずに2から始めるのもありだと思い始めている。
