概念、論理、物理。

• 概念モデル
• 論理モデル
• 物理モデル(物理ファイル設計)

データモデルの基本的な考え方は3階層になりますよね。
概念モデルは、実装非依存の、業務の世界を現すモデル。
論理モデルは、概念モデルを実装依存(RDBMS依存)で
置きかえたモデル。
最後に、物理モデル。これは物理ファイル設計の成果物。
RDBMSに対する物理ファイルの配置を決めたもの。
厳密にはモデルとは呼ぶべきではなく、また呼ぶ必要も
ないと考えます。

重要なのは、業務を表す、概念モデル。
例えば、TH法では、概念モデルと物理モデル(=論理モデル)
の2階層に分ける。論理と物理は実装依存ということで
特に分ける必要もない。

実際のシステム開発の現場で、時々感じるのが、実装依存と
実装非依存がきちんと区別されていないところ。
確かに、最初に概念モデルもどきを考える。
しかし、業務を表すはずの概念モデルが完成する前に
正規化を崩し、論理モデルの世界を、持ち込み始める。
「パフォーマンス確保」の旗印の下、この混沌とした
モデリングが進められることになる。
（実際には、ご存知のとおり正規化さえ崩せば良い
　というモノでは無い）
かくして実際の業務を現すモデル図が、最終的にも存在しない
という事態になってしまう。
（ん？何のためにモデリングしていたんだろう？）

概念⇔論理の混乱の他には、概念＝概略という誤った考えが
ある。
「今は最初のモデル(=概念モデル)を作っているから
　ざっくりでええねん(=概略)。」
概略の概念モデルを作るのは間違いではない。
しかし、いずれにしても詳細な概念モデルは作る必要がある。

TH法に則れば、
概念モデル(概略)→概念モデル(詳細)→物理モデルと
進めべきです。
しかし、
概念モデル(概略)→物理モデル
となっていることが往々にしてある。
というか、寧ろ、
物理モデル
しかないプロジェクトも数多く存在するはずです。

私達が、システム開発という迷いの森で、いずれこへ向かえば
良いのか、彷徨い始めたとき、何を頼りに進めばよいのか。
それは、概念モデル図であると思っています。
要求や仕様に対して、方向性を打ち出すために必要なモノ。
方向に迷った時は、概念モデルに立ち返えればいい。