Designing Objects for Relational Databases(P159) †
要約 †
- 主にオブジェクト指向のソフトウェアシステムで、最も一般的な「非-オブジェクト」のコンポーネントは、リレーショナルデータベースである。しかし、リレーショナルデータベースは、たいていの他のコンポーネントより、密にオブジェクトモデルに関係している。
- 技術的な関心ごとは別として、このミスマッチは、オブジェクトモデルに重大な影響を与えることにある。
３つのよくある例：
- データベースは、主にオブジェクトのためのリポジトリである。
- データベースは、別のシステムのために設計された。
- データベースは、このシステムのために設計されているが、オブジェクトの格納以外の役割に役立つ。
- データベースのスキーマが、明確にオブジェクトの格納場所として、作成された場合、
とてもシンプルなマッピングを保つために、いくつかのモデルの制限を受け入れることは価値があることである。
- スキーマの設計で、他の要求なしに、データベースは、更新するときに、完全に安全、かつ、より効率的に集約(AGGREGATE)するように構築することができる。
- データベースは、オブジェクトの格納場所と見なされたとき、マッピングツールの力にかかわらず、データモデルとオブジェクトモデルに大きく分岐する。リレーショナルモデルに近づけるには、オブジェクトの関連のいくつかの豊かさを犠牲にする。もしオブジェクトマッピングを簡単にするには、いくつかの正式な関係の標準(正規化として)、を妥協する。
- 外部のオブジェクトシステムの処理は、オブジェクトの格納場所としてアクセスしないべきである。それらは、オブジェクトで実行する不変式に違反することになる。また、それらのアクセスは、データモデルを、変更不能にするので、オブジェクトをリファクタリングするときに変更が難しくなる。
- 他方では、オブジェクトの格納場所として意図してない、レガシーシステムや外のシステムからデータが来る多くのケースがある。
- 例外のもうひとつの理由は、性能である。気まぐれな設計変更を実行時間の問題を解決するために、導入しなければならないかもしれない。
- リレーショナルデータベースが、オブジェクト指向ドメインの永続化方法として機能する
重要なよくある例を別にすれば、シンプルで率直なのが、もっともよい。
- UBIQUITOUS LANGUAGEは、オブジェクトとリレーショナルコンポーネントとをひとつのモデルに、一緒に結びつけることの手助けができる。オブジェクトの名前と要素の関連性は、慎重に関係のあるテーブルに一致させるべきである。
担当者のつぶやき †
- 突っ込み大歓迎です。
- 直訳だらけになってしまいました。すいません（；＞＜）
- 重要なところをピックアップしてみたのですが、うまく訳せず？？の部分があると思います。
みんなの突っ込み †
- p.160中段について誤訳があるようです。
- p.160 l.8以下
- データベースがオブジェクトの格納箇所と見なされる場合には、データモデルとオブジェクトモデルを異なるものにしすぎてはならない。たとえ、どれほどマッピングツールが強力であっても、である。リレーショナルモデル（データモデル）と近づけておくために、オブジェクトの関連が持つ自由度("richness")は犠牲にしなさい。オブジェクトとのマッピングが簡単になるのなら、正規化などによってリレーションを正式に標準化することをある程度妥協しなさい。
- p.160 l.14以下
- オブジェクトシステムの外部で実行される処理は、このようなオブジェクトの格納箇所にアクセスしてはならない。そんなことをしたら、オブジェクトによって守られている不変性が破壊されてしまう。さらに、このようなアクセスはデータモデルを固定化してしまうので、オブジェクトがリファクタリングされた場合に変更することが難しくなってしまう。
- 下から二番目の●について
- （他システムから来るデータがある場合や、パフォーマンスの問題がある場合もあるが、）しかし、リレーショナルデータベースがオブジェクト指向ドメインの永続形態として機能するほとんどの場合には、シンプルで、結びつきが直接的であることが望ましい。 -- 和智?
