2 âIâuâWâFâNâgÄwîⁿâfü[â^âxü[âX

データベース

第 13 回 (2) オブジェクト指向データベー

ス

鈴木幸市

今日の内容

 オブジェクト指向言語とデータベース

 インピーダンスミスマッチ

 プログラム言語のオブジェクトをデータベースに格納

 ₁₉₈₀ 年代後半～ 1990 年代前半に

 C++, Smalltalk など

 _{何らかのクエリは必要}

 _{Query ベースの考え方}

 オブジェクト拡張 SQL

 オブジェクトベースの考え方

 _{トランザクション}

 Optimistic/Pesimistic

 _実装例

オブジェクト指向データベースへのアプ

 ローチ オブジェクト指向データベース (OODB)



Object-Oriented Database の略

 歴史的に複数の観点からのアプローチがあった



プログラム言語からのアプローチ

 オブジェクト指向言語で使うオブジェクトをデータベース上で 永続的に扱いたい



データモデルからのアプローチ

 リレーショナルモデルを拡張して自由度の高いデータ構造を扱 いたい



_{API からのアプローチ}

 リレーショナルデータベースの操作をオブジェクト指向言語の 考え方で行いたい

 現在でも上記のアプローチをそれぞれオブジェクト指向データ

ベースと呼ぶことがあるので注意！！



そもそもどのアプローチなのかを理解することが重要



オブジェクト指向といっても内容はさまざま

プログラム言語からのアプローチ (1)

 インピーダンスミスマッチ問題



_C++ 、 Java などのオブジェクト指向言語がデータベースと

相性が悪い

 プログラムでは一度に一つのオブジェクトを処理する

 データベースは一度に複数の行を処理する



_SQL はあまり使わず、プログラム言語で使うオブジェクトを

永続的にデータベースに格納するアプローチ

 メモリ上のオブジェクトとディスク上のオブジェクトをプログ ラム言語上で区別しない

 オブジェクトのチェインをたどるには、リレーショナルモデ

ルでは性能が出にくい

 実装例： 1980 年代後半から 1990 年前半にかけて多く行わ

れた



ObjectStore (ONTOS): C++ の永続オブジェクト

 現在は XML 用のデータベースエンジンとして存続



_GemStone ： Smalltalk の永続オブジェクト

プログラム言語からのアプローチ (2)

 _{RDBと OODB この間をサポートす}

るのが OR マッピン グ

OODB _{の利用に際しての注意}

 トランザクションモデルが違うことがある

 楽観的制御 (Optimistic Control) を採っていることがある

楽観的制御と悲観的制御

 同時実行制御のやり方が異なる



悲観的制御 (ほとんどのリレーショナル DB)

 ロックは SQL 実行前に取得する

 ロックが取れなければ SQL がエラーリターン (あるいは待たさ れる )

 トランザクションのコミットはシステムエラーがない限り成功 する

 _{エラー処理は単純}

 高負荷時でのコミット失敗は起こりにくい



_{楽観的制御}

 ロックはトランザクションの最後にチェックする

 他のトランザクションと衝突しても読み書きができる

 他のトランザクションとの衝突が起こるとコミットは失敗する

 エラー原因によってエラー処理をきちんと行う必要がある

 最初から処理をやり直すなど

 高負荷時にコミット失敗する可能性がどんどん大きくなる

データモデルからのアプローチ (1)

 _{SQL を拡張する}

 データ型、メソッドをユーザ定義できるようにする

 _SGML/XML 、ストリームデータなど

 外部ファイルもデータベースに取り込む

 データの間のリンク (ポインタ )を導入する

 すべての行を一意に識別できる ID をつける (オブジェクト ID 、 OID 、 Object ID)

 _OID がわかるとそのオブジェクトのクラスや構造がわかるようにする

 _OID をカラムに格納すると、これがポインタとして使える

 テーブルに「継承」の概念を持ち込む

 _{テーブル→クラス}

 _{行→オブジェクト}

 親テーブルへの SQL で子テーブルも読み書きする

 オブジェクトリレーショナルデータベース (ORDB) と呼ばれるこ とがある

 _実装例：

 _PostgreSQL 、 Oracle をはじめ、多くの RDBMS はオブジェクト 拡張を実装している

データモデルからのアプローチ (2)

 複雑な構造を持ったデータを SQL で 読み書きする

 パス式 (path expression) が提案

、実装されている

 この図で、学籍番号が与えられたら、その学生 の主任教授と指導教官の名前を探す

 _SELECT 学部 .主任教授 .氏名 FROM 学籍簿

WHERE 学籍番号 ='xxxx';

 _{SELECT 指導教官 .氏名} FROM 学籍簿

WHERE 学籍番号 ='xxxx';

 テーブル名が一つしか出てこない

 _{結合が現れない}

 リンクをたどるのに結合を使わない→高速化が可 能

リレーショナル DB との比較

 同じことをリレーショナルモデルでやってみる

 この図で、学籍番号が与えられたら、その学生 の主任教授と指導教官の名前を探す

 _{SELECT 教官 .氏名}

FROM 学籍簿 , 学部 , 教官 WHERE 学籍番号 ='xxxx' AND 学部 = 学部 ID AND 主人教授 = 教官 ID;

 _{SELECT 教官 .氏名}

FROM 学籍簿 , 教官

WHERE 学籍番号 ='xxxx' AND 指導教官 = 教官 ID;

 関連するすべてのテーブルを列挙しなければな らない

 _SELECT 句から、ほしい情報が何かを判断しに くい

API _{からのアプローチ}

 データベースへのリクエストをオブジェク

ト指向風に行う

 _SQL は単なる文字列として扱う

JDBC

 _Java 言語におけるデータベースアクセス方法

 _DBMS 独立なクラスとそのメソッドインタフェー

スを規定している

 _SELECT のように複数の行が帰るメソッドのやり

方

 データベースオブジェクトに SQL を渡す

 results = db1.executeQuery("SELECT 氏名 FROM

学籍簿 ");

 その返り値に、結果の複数の行が入っている (ように見

える ) → 上の場合は "results" に複数の行が入っている

 返り値のオブジェクトから 1 行ずつデータを読む

while (results.next()) {

String item=results.getString(" 氏名 ");

System.out.println(item);

}

JDBC _{の特徴とその実装例}

 _特徴

 _Java 言語からデータベースにアクセスする際

に使うクラスとそのメソッドを規定している

 実際の DBMS にあわせた実装はそれぞれの

DBMS _の仕事

 データベースへの依存性の低いアプリケー

ション開発が可能になっている

 _実装例

 ほとんどの DBMS で実装されている