- 永続性をどのように実現するか
- RDB とどのようにマッピングするか
- オブジェクト指向データベースの紹介
永続性の閉鎖の原則
- 永続化する場合、参照先も永続化されなければならない STORABLE クラス → Java の Serializable システム依存形式とシステム非依存形式
保存したくないオブジェクトまで保存するのは不適切 保存方法をカスタマイズ可能
オブジェクトの構成が変化した場合に生合成を保つか
素朴(で現実的でない)アプローチ
- 以前保存されたオブジェクトを見捨てる
- (とはいえ、永続化をする際に、本当に残す必要が有るかは常に考えるべきだと思う)
- 更新時に一度だけ大量に変換する
- (少なくとも RDB の場合は現在は主流なのではないか…)
- (「Refactoring Databases」という本があって、スキーマの更新処理を体系化して解説している)
同時進行オブジェクト変換
- 古い形式のデータのロード時にうまく調整する - 検出、通知、修正のフェーズに分けている
(構成の変化の)検出
- オブジェクト定義にバージョンをつける (名目的アプローチ)
- Java の serialVersionUID
- 構造を元に不一致を検出する (構造的アプローチ)
- クラスの属性と型に変化がないかをチェックするのが現実的、との事
- 不変表明の変化を見る、というやり方もある
通知
- correct_mismatch を呼び出す
修正 ??
本章で言うデータベースとは何を指しているのかを定義しているだけ
RDB の説明
- タプル、リレーション、関係代数
RDB をオブジェクト指向言語で扱う事
- RDB とオブジェクトのモデルは似ている
- 対応させるクラスライブラリがある
- 「オブジェクトリレーショナル相互運用」
- 合致しないこともある(インピーダンスミスマッチ)
オブジェクト指向データベースの機運が高まっている理由
- OO の開発手法に合致する永続性メカニズム
- RDB の概念的限界を克服する
- 現在の技術進歩によって可能になった高度な DB 機能の実現
RDB の貢献を否定するのは無謀で、適している状況もある
- データ構造が標準的
- 構造が単純
- 事前定義済みのプリミティブから構成される
RDB の制約
- 画像などのデータが管理できない
- (LOB が実装されていない時代の話?)
- 参照が(直接的に)辿れない
- オブジェクトの識別ができず、値のみのモデル
- RDB の単純さに貢献しているが…
- (これが本当に重要だと思うが…)
DB が OO である条件 (境界モデル)
- データベース機能を提供している
- カプセル化をサポートしている
- プロパティの隠蔽など
- 各オブジェクトが DB 内で一意の識別子に関連付けられる
- 他のオブジェクトに参照可能
追加の機能
- 継承、動的束縛などの OO 機能
- オブジェクトのバージョン化(過去の状態を保存する)
- スキーマ進化
- 長期トランザクション(日や月のオーダー)
- ソフトウェア開発でも長期トランザクションが使えるのではないか?
- オブジェクトレベルのロック
- クエリ言語
Matisse
- 機能
- クライアントサーバーモデル
- 書き込み操作は新規オブジェクトの作成になる
Versant
- 書き込みロック
- イベント通知
- オブジェクトの追加削除など
- データベースは不要で、クライアントと永続化ができるサーバーがあればよくないか?
- Web の普及で、非構造化情報が有用であることがわかった。構造化情報はもはや不要なのではないか?