データベースにおける論理設計と物理設計

　データベースのテーブルを設計する際には、テーブルに置きたいデータ(フィールド)を並べた後、正規化と呼ばれるプロセスを経て設計を完了させるという手順が一般的と言われているようです。この手順は、プログラムコード内の特にビジネスロジックで SQL を直接記述するような開発形態を前提にしている場合には良いのですが、最近の SQLCLR のような、オブジェクト指向とデータベースアクセスが密接に繋がるような開発形態においては、その限りではないだろうと感じます。

　もう10年以上昔に、Delphi + Oracle でクライアントサーバシステムを開発していた時に感じていたのは、例えば階層化テーブルのようなデータ構造を実現しようとした場合、テーブルは最低でも2つに分離されざるを得ず、かといって、プログラム上での構造体はヘッダ＋可変長レコードを表現できるので、プログラムから見た断面を論理設計、テーブル設計を物理設計として、これらの間を埋めるというのが、本来の正規化という作業なのではないだろうかということでした。