RedmineのER図
RedmineのER図を作る方法が公開されていたのでメモ。
【元ネタ】
redmineのER図を生成してみた | ぷろぐらま
Railsのテーブル名や主キーは、CoCで厳格なルールがあるおかげで可読性も高い。
だから、Redmineもこれだけの頻繁なVerUp、豊富な機能改善が可能だったのだろうと思う。
Railsの最大の特徴である「サロゲートキーの重視」については、渡辺さんが下記の記事を書かれている。
複合キーをなくしサロゲートキーに統一する手法では、ER図に親子関係が発生せず、全ては外部キーによる参照関係になる。
多分、普通のRails開発では、テーブル間のリレーションシップはアプリケーション層で実装するだろう。
つまり、DBMSでリレーションを貼ることはしないので、テーブルは入れ物にすぎない。
DOAの立場の人がサロゲートキーに違和感がある理由は、親子関係という基本的なリレーションシップがなくななるため、データモデルの表現力が落ちてしまうからだ。
だが、Railsがサロゲートキー一辺倒にした理由の一つは、HTTPのURIをRESTで書けるようにしたいから。
URLがDBのCRUDに対応するように書ける。
Railsの思想から言えば、サロゲートキーは単なるデータモデルだけでなく、HTTPアクセスのURLはCRUDであるべきというREST思想にも基づく観点があるからこそ、サロゲートキーだけのデータモデルでもWebシステムで特に有効なのだと思っている。
だから「サロゲートキーは必要なのか、不要なのか」という議論は不要で、個人的には、分析(概念)モデルと実装モデルの違いに過ぎないと思っている。
例えば、OOAでも概念モデルでは、注文と注文明細を区別せず、一つのオブジェクトで表現して、荒い粒度でモデルのあるべき姿を描き、実装モデルはソースに近いレベルの粒度故に、たくさんのオブジェクトが表現される。
つまり、DOAでも、分析者が見るレベルのモデルと、開発者が実際に使うレベルのモデルで区別してもいいはず。
そもそも、ユーザ(顧客)観点のモデルと開発者の観点のモデルは粒度が大きく異なるのは、外部設計・内部設計、基本設計・詳細設計というWF型開発の工程による区別からしても、自然な考え方だ。
でも、DOAの前提では、モデルは唯一つであり、分析者も開発者も同じER図を見るから、ロールによるモデルの区別は存在しない。
だから、そのような不毛な議論が発生するのだろうと思う。
とはいえ、Railsの普及によって、DOAの重要性は以前よりも増していると考えている。
何故ならば、きちんとテーブル設計さえできれば、Railsのマイグレーション機能によって一発でCRUD画面を作れてしまうからだ。
Redmineがこれだけ豊富なプラグインを持つ理由の一つは、Redmineのデータモデルがシンプルであるだけでなく、テーブル設計が非常に優れているため、機能拡張しやすいのだろうと推測している。
色々考える。
| 固定リンク
「モデリング」カテゴリの記事
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- Go言語でできることは何なのか(2022.11.06)
- クラウド上の開発がJavaに与えた影響は何なのか(2022.10.16)
- 「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった(2022.09.18)
- 組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク(2022.06.17)
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
コメント