RedmineのER図

RedmineのER図を作る方法が公開されていたのでメモ。

【元ネタ】
redmineのER図を生成してみた | ぷろぐらま

Railsのテーブル名や主キーは、CoCで厳格なルールがあるおかげで可読性も高い。
だから、Redmineもこれだけの頻繁なVerUp、豊富な機能改善が可能だったのだろうと思う。

Railsの最大の特徴である「サロゲートキーの重視」については、渡辺さんが下記の記事を書かれている。

「強制されたサロゲートキー」の事例を眺める: 設計者の発言

複合キーをなくしサロゲートキーに統一する手法では、ER図に親子関係が発生せず、全ては外部キーによる参照関係になる。
多分、普通のRails開発では、テーブル間のリレーションシップはアプリケーション層で実装するだろう。
つまり、DBMSでリレーションを貼ることはしないので、テーブルは入れ物にすぎない。

DOAの立場の人がサロゲートキーに違和感がある理由は、親子関係という基本的なリレーションシップがなくななるため、データモデルの表現力が落ちてしまうからだ。

だが、Railsがサロゲートキー一辺倒にした理由の一つは、HTTPのURIをRESTで書けるようにしたいから。
URLがDBのCRUDに対応するように書ける。

SOAPからRESTへ: プログラマの思索

Railsの思想から言えば、サロゲートキーは単なるデータモデルだけでなく、HTTPアクセスのURLはCRUDであるべきというREST思想にも基づく観点があるからこそ、サロゲートキーだけのデータモデルでもWebシステムで特に有効なのだと思っている。

だから「サロゲートキーは必要なのか、不要なのか」という議論は不要で、個人的には、分析(概念)モデルと実装モデルの違いに過ぎないと思っている。
例えば、OOAでも概念モデルでは、注文と注文明細を区別せず、一つのオブジェクトで表現して、荒い粒度でモデルのあるべき姿を描き、実装モデルはソースに近いレベルの粒度故に、たくさんのオブジェクトが表現される。

つまり、DOAでも、分析者が見るレベルのモデルと、開発者が実際に使うレベルのモデルで区別してもいいはず。
そもそも、ユーザ(顧客)観点のモデルと開発者の観点のモデルは粒度が大きく異なるのは、外部設計・内部設計、基本設計・詳細設計というWF型開発の工程による区別からしても、自然な考え方だ。

でも、DOAの前提では、モデルは唯一つであり、分析者も開発者も同じER図を見るから、ロールによるモデルの区別は存在しない。
だから、そのような不毛な議論が発生するのだろうと思う。

とはいえ、Railsの普及によって、DOAの重要性は以前よりも増していると考えている。
何故ならば、きちんとテーブル設計さえできれば、Railsのマイグレーション機能によって一発でCRUD画面を作れてしまうからだ。
Redmineがこれだけ豊富なプラグインを持つ理由の一つは、Redmineのデータモデルがシンプルであるだけでなく、テーブル設計が非常に優れているため、機能拡張しやすいのだろうと推測している。

色々考える。