As far as I'm concerned, I have never seen properly a 3NFed Relational Database model in Japan. I really hope I am wrong.
I have never seen a proper data model before the software development project starts. I really hope I am blind.
Software development projects are often compared to building construction projects where blue prints are more than "must" before the projects start. Why not for software? Is it because buildings are hardware?
Can I say software is by nature different from hardware?
さて、突然データモデルの話である。
元々データベースを設計するにあたり、RDBMS（リレーショナル・データベース）を扱おうとすれば、データモデルに触れないわけにはいかない。私が始めてデータモデルに触れたのは1997年のことであるが、当時RDBMS設計に関しての文献は非常に少なかった。丁度そのころインターネットという便利なものが生まれ、amazon.comというとんでもない本屋さんも生まれた。そこで思いっきり検索をしたところ、いくつかデータモデルに関する書籍を購入することができた。１つは、Data Model Patterns (by David C. Hay)であり、もう1冊は、The Data Model Resource Book(by Len Silverston)である。
データモデルと言っても何もそれほど大げさなものではない。例えば、連絡先をどっかに保存しておきたいという単純な要件があった時、当時の電子手帳などは、1社（１人）にひとつの電話番号しか入力できなかったが、これには非常に困った。
また、会社と人は同じ連絡先として登録するのだけど、ある人がどの会社に勤めているかなどの紐付けなどはできない。備考にでも書いておく以外になかった。
そりゃ電子手帳じゃ無理でしょ、と言われるかもしれないが、オフコン、パソコンのソフトでさえそういうものが多かったのである。当然データモデル上、こんな問題はあっという間に解決するのだが、私の場合、扱う対象を全て（1対N）という構造に当てはめていくという作業は、こんなところから始まった。
結果的に、↑で取り上げた、Data Model Patternsという書籍とは10年以上の付き合いをすることになるのである。
なお、電子手帳、オフコンなどの死語については、知らない人も多いと思うが御容赦願いたい。