読者です 読者をやめる 読者になる 読者になる

雀巽の日記帳

雀巽が綴る日常の記録

ERD(論理設計・物理設計)の管理について

ITライフ

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

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

necojackarc.hatenablog.com

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

論理設計はもう一段抽象度の高い内容となっているので重複していると感じないのですが、 物理設計に関しては「物理設計 = データベースの実装」となるので、内容が重複してしまっていました。

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

パターン1: 論理設計のみ保持する

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

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

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

まとめ

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

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

補足: 論理設計と物理設計について

論理設計

論理設計は実現性、つまり実装や性能を考慮せず、理想的なリレーショナルデータモデルを作成します。

物理設計

物理設計は実現性(実装や性能)を考慮し、インデックス設計やテーブルの統廃合、非正規化などを行います。


この辺りの情報については、このページが簡潔にまとまっていていわかりやすいです。

gihyo.jp

簡単な具体例を挙げると、Rails + MySQL を使った物理設計をする際、

  • 継承関係の実装方法を決める
    • 例) Rails が扱いやすい STI (シングルテーブル継承) を選択する
      • シングルテーブル継承、クラステーブル継承、具象テーブル継承が有名な継承実現方法
  • 階層構造の実装方法を決める
    • 例) Ancestry を利用して扱いやすくする
  • ActiveRecord::Enum の適用を行う
    • 例) ステータスなどを論理設計では1つのテーブルとして設計していたが、それを削除し Enum を利用する

といったようなことを行ったりします。