雀巽の日記帳

雀巽が綴る日常の記録

ERD(概念/論理/物理設計)の管理について

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

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

necojackarc.hatenablog.com

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

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

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

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

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

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

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

まとめ

  • 概念設計は実装の経緯や意図が現れているため常に保持すべき
  • 論理/物理設計はほぼ実装そのものであるので二重管理となる場合は不要

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

補足: 概念/論理/物理設計について

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

www.atmarkit.co.jp

概念設計

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

論理設計

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

物理設計

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

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