ERD（概念/論理/物理設計）の管理についてのメモです。

Web サービス企業では設計書の作成や管理がされない傾向にありますが、以前も書いたように ERD は作成し管理すべきだと考えています。

ただ、最近 ERD の管理で煩わしいなと感じる部分がありました。それは、Rails のマイグレーションファイルと論理/物理設計の内容が重複していることです。

概念設計*1はもう一段抽象度の高い内容となっているので重複していると感じないのですが、論理/物理設計に関しては「論理/物理設計 = テーブル構成そのまま」となるので、内容が重複してしまっていました。

これに対する2パターンの解決案を書きます。

パターン1: 概念設計のみ保持する

概念設計の ERD のみドキュメント管理をし、論理/物理設計を作らないパターンです。マイグレーションファイルなので実装自体が管理されている場合、これで良い気がします。

パターン2: 論理/物理設計を保持し DDL を利用する

DDL を利用し、論理/物理設計の変更自体をデータベース自体の変更とするパターンです。 SIer 時代に大規模プロジェクトではこちらのパターンを採用していました。

単純に「同じ抽象度のモノを同時に管理するのは DRY じゃない」という話でした。

それぞれが何をするべきフェーズなのか、以下にわかりやすくまとまっていました。

業務の観点から必要な情報を漏れなく管理できるように設計します。抽出した情報は、正規化し、あるべき姿で情報を整理し、概念ER図に表します。

データ構造の変更を最小限に抑えながら性能向上を図ります。

ユーザー要件として性能要件や可用性を考慮したデータベースを設計します。そのために必要なハードウェア資源、ミドルウェアの選定、パラメータの設定を行います。

正規化が論理設計に含まれているケースもみますが、データベーススペシャリスト試験などの本を見てみると、上記の分け方で書かれていたので、この分け方が一般的なんじゃないかと思います。

また、「概念設計では属性を書き出さない」という誤解もありますが、書き出すケースも書き出さないケースもあると思います

*1:属性を持っていないものこそが概念 ERD だという誤解を耳にしたことがありますが、属性は持っていても良いです。目的とフェーズ次第だと思います。例えば正規化をする際には属性が無いと難しいかと思いますし、概念上のデータをできるだけ正確に表すのであれば、属性も重要な要素になると思います。