オブジェクトモデルと関係モデルの設計

オブジェクトモデルと関係モデルを、なぜ別々に設計しなければならないのか。

Ruby on RailsとActive Recordパターンが示した「データ構造を一度だけ定義する」という考え方を出発点に、Domain ModelとEntity Modelを分離する二重モデル方式との違いを整理します。

DRY、データベース管理者の事情、Mapper、現在のエコシステムまで含めて、Active Record方式の利点と現実的な制約を考えます。

Transcript

1. オブジェクトモデルと関係モ デルの設計 Active Recordパターンを使ったデータベース設計について
2. 業務モデルのデータ設計 オブジェクトモデル オブジェクト指 向で利用され るデータ設計 関係モデル RDBで利用さ れるデータ設 計
3. 疑問 データ設計って２回やらないと ダメなの？
4. RUBY ON RAILSの登場 2004年公開 2007年に大ヒット
5. RAILS LIKEにあらずんばWEBフレーム ワークにあらず Ruby on Rails後にほぼすべての 言語の主流フレームワークは、 Ruby on Railsをまねしたものに置 き換わった。
6. DRY Ruby on Railsで注目された設計技法のひとつ 同じことは二度書かない。 •例外は本当に無理じゃなければ認めない。
7. 一度ならどこに書くか オブジェクトモデル 処理の記述とデータ構造の記述が書ける 関係モデル データ構造しか記述できない 処理を考慮しないデータなんてあまり 意味がないので、ほぼ一択では
8. ACTIVE RECORDパターン 定義はいろいろあるが、データ構造の定義を一種類にするのが本質の一つ。 Ruby on Rails内のORMに採用された ORMの名前もActiveRecordとした マーチン・ファウラーがデザインパターンとして整理したものの一つ
9. 結論？ めでたしめでたし、とはならなかった
10. データベース管理者 データベース管理者 データベースを管理 データの書き換えも行う 開発部署と別の部署のことも多い データベース管理者は、開発の都合 だけでデータ構造を決められたら困る DBを直接参照・修正する運用が難しくなる
11. データ構造の二重定義 Entity Model データベースのデータを扱うクラス 関係モデルと同等のデータ構造を記述する Domain Model オブジェクト指向で扱うデータと処理を扱うク ラス Mapper Entity ModelとDomain Modelを相互に 単純処理で変換する 以上の三つを実装するとデータベース管理者の要望にも対応できる データ定義の工程が２回必要になるけれども
12. ACTIVE RECORD方式 VS 二重モデル 方式 Active Record方式 二重モデル方式 Domain Model Entity Model O/R Mapper RDB Domain Model Entity Model O/R Mapper RDB Mapper
13. ACTIVE RECORD方式 VS 二重モデル 方式 技術的には残念なことにDomain Modelと は別にEntity Modelも作るやり方が主流に。 まあMapperをきれいに作れば許容範囲で すし。
14. エコシステム ライブラリやツールの充実も含む世界の開発環境 主流のやり方はサポートが強くやりやすい 技術的には良いものでも、主流じゃないとエコシステムの サポートが弱くなり、技術的によろしくなくなる。
15. ACTIVE RECORD方式のメリット、デメ リット アプリケーション全 体に対して、データ 設計を二重に行わ なくてもいい メリッ ト データベース管理 者が怒る 現在のエコシステ ムに合わない可能 性 デメ リット