オブジェクトデータベース
オブジェクトデータベースは、オブジェクト指向プログラミングで使うオブジェクトの形式で表現されるデータを格納するデータベースである。オブジェクト指向データベースともいう。オブジェクト指向プログラミングにおいて、オブジェクトをその接続構造(オブジェクトグラフ)ごと永続化するといった用途に利用するのが容易であるなどといった、オブジェクト指向プログラミングや、オブジェクト指向プログラミング言語との関連がある。 オブジェクトデータベースのデータベース管理システム (DBMS) を、
この項目ではオブジェクトデータベースそのものについての他、オブジェクトデータベース管理システム (ODBMS) についても述べる。 概要ODBMSの実装を使うと、データベースに格納されたオブジェクトを一つもしくは複数のオブジェクト指向プログラミング言語のプログラミング言語のオブジェクトとして継ぎ目なしに利用できる。 また、ODBMSはオブジェクト指向プログラミング言語に次の機能を備えるよう拡張した技術と位置づけることができる。 ODBMSの実装のいくつかは、Smalltalk、C++、Java、C#、Visual Basic .NET などのオブジェクト指向プログラミングと連携して良好に動作するよう設計されている。 別のODBMSの実装のいくつかは、その ODBMS 独自のプログラミング言語をもつ。 ODBMSはデータモデルとしてオブジェクト指向プログラミング言語と厳密に同じモデルを採用している。 オブジェクトデータベースは、一般的には、複雑なデータの高速処理のビジネス要求がある際に、勧められるとされる。 データベース技術にオブジェクト指向の概念を導入する手法には、後述するように、オブジェクトデータベースとオブジェクト関係データベースの2つの手法がある。 ODBMSの実装としては、ObjectStore、Caché、Objectivity/DB、GemStone/S、db4oなどがある。 歴史ODBMSの研究開発ODBMSの技術は、1970年代半ばの、DBMS (データベース管理システム) で、グラフ構造をなすオブジェクト群を扱うための本格的な機能の研究開発から発展してきた。 「オブジェクト指向データベースシステム」という用語が最初に現れたのは1985年頃である。 特筆すべき研究プロジェクトとしては次のようなものがある。
ORIONプロジェクトに関しては、他のどのプロジェクトよりも多くの論文が書かれた。 MCCに在籍していたウォン・キムは、優れた一連の論文を一冊の本にまとめてMIT Pressから出版した[1]。 最初期のODBMSの商用実装としては次のようなものがあった。
1990年代前半にはさらに次のような製品 (商用実装) がODBMS市場に参入した。
ここで挙げた製品のいくつかは、現在もODBMS市場で開発販売を続けている。 ODBMSは、オブジェクト指向プログラミング言語に永続化の機能を追加する。 初期のODBMS実装は、さまざまな言語に永続化機能を追加して統合した。
1990年代のほとんどの期間においては、C++がODBMS市場において支配的な言語であった。 1990年代末期には、商用のODBMS開発企業はJavaに対応し、さらに近年ではC#にも対応するようになった。 ODBMSの必要性データベースを使う人々にとって、ODBMSを必要とする背景には、主に2つの要因があった。
このような状況で関係データベースを使うと、アプリケーションソフトウェアで、オブジェクトとして表現されたデータと関係モデルに基づく関係データベースの関係 (テーブル構造) のデータを相互に変換する処理を、プログラマが自分で記述する必要がある。プログラマにとってそのような作業は退屈でうんざりさせられるものであり、開発生産性が悪く、開発されたソフトウェアの実行速度も遅くなる傾向がある、などのデメリットがある。 こうした、オブジェクト指向プログラミング言語で記述されたアプリケーションソフトウェアと関係データベース(関係モデル)の間の不整合を、インピーダンスミスマッチと呼ぶことがある。インピーダンスミスマッチを軽減する技術として、この項目で説明するオブジェクトデータベースと、オブジェクトリレーショナルマッピングがある。 ODBMSを採用する動き1990年代の初めに、データベースにオブジェクト指向の概念を導入するという課題は、情報技術の研究者や新興企業の人々の中心に、広く関心を持たれるようになった。 データベースにオブジェクト指向の概念を導入するために、さまざまな手法が採られてきた。これらの手法は、2つのグループに分類することができる。
オブジェクトデータベースはいくつかの分野で使われてきた。工学データベース、空間データベース、電気通信のデータベース、高エネルギー物理学や分子生物学(バイオインフォマティクス)など自然科学の分野のデータベースとして、使われてきた。これまではオブジェクトデータベースは、商用のデータ処理にはあまり使われてこなかった。しかし現在では、金融業のいくつかの特定分野において使われる事例がでてきている。 オブジェクトデータベースは、現在、世界最大の容量のデータベースという記録を保持している。 スタンフォード線形加速器センターで 1000 テラバイト以上のオブジェクトデータベースが運用されている ("Lessons Learned From Managing A Petabyte") 。 またこのデータベースは、1日で1テラバイト以上という非常に高いデータ増加ペースという記録ももっている ("High Ingest Benchmark Description") 。 いくつかの ODBMS は、機器やパッケージソフトウェアやリアルタイムシステムへの組み込みの用途を想定している。 一方、ORDBMSは広く使われるようになったが、単なる関係データベース (RDBMS) として使われる傾向があり、現時点ではそのオブジェクト指向の機能を積極的に活用する事例はあまり多くない。オブジェクト関係データベースでは、データ操作言語として、関係データベースの述語論理に基づいた宣言型の言語 (SQL) を引き継いでいる。「オブジェクト関係データベース」という用語は、マイケル・ストーンブレーカーが命名した。オブジェクト関係データベースはハイブリッドデータベースと呼ばれることもある。従来の関係データベース (RDBMS) を開発してきた企業(ベンダ)の多くが、ORDBMSの手法を採用し、もしくはオブジェクト関係データベースの開発企業を買収した。こうした関係データベースの開発企業は、自社の関係データベースにオブジェクト指向の拡張を行った。 ORDBMSの実装としては、PostgreSQL、Illustra、Informix Dynamic Server (IDS) 、IBM Db2、Oracle Database などがある。 2004年から、オープンソースの ODBMSが注目されるようになり、ODBMS は第2の成長期に入っている。こうしたODBMSは、オープンソースであるため少ない費用で導入できる。またODBMS自体がJavaやC++、Python、C#のようなオブジェクト指向プログラミング言語によって全て実装されている。 オープンソースのODBMSとしてはdb4o (db4objects) や Perst (McObject) などがある。 さらに最近ではMagmaというオープンソースのODBMSが開発されている。 Magmaは、Smalltalk環境の一種であるSqueakで実装されている。 技術面の特徴ODBMSでは、オブジェクト指向の考え方を純粋な形で採用しており、データはオブジェクトとしてデータベースに格納(永続化)される。オブジェクトはカプセル化されている。オブジェクトに対しては、その設計図であるクラスで定義されたメソッドを介してのみ、扱うこと (オブジェクトの状態を参照・変更することなど) ができる。オブジェクトはなんらかのタイプ(型)をもつ。おのおののタイプの間には継承関係がある。あるタイプを継承して、そのタイプの特性を引き継いだ別のタイプを定義することができる。継承元となるタイプをスーパータイプといい、継承先のタイプをサブタイプという。スーパータイプを継承してサブタイプが定義される。サブタイプは、単一のスーパータイプのみもつことができる場合と、複数のスーパータイプをもつことができる場合とがある(オブジェクト指向プログラミング言語により異なる)。 アプリケーションソフトウェアは、ナビゲーショナルな方法で、オブジェクトデータベースに格納されているオブジェクトへの参照を取得することができる(ナビゲーショナルデータベース)。オブジェクトは、他のオブジェクトへの参照をもつことができる。これを利用して、アプリケーションソフトウェアは、別のオブジェクトへの参照を取得するために、オブジェクト間の参照関係をたどって目的とするオブジェクトへの参照を取得することができる。 多くの ODBMSでは、オブジェクトデータベースに格納されているオブジェクトへの参照を取得するための、別の方法として、宣言的なデータ操作言語による方法も使うことができる。オブジェクト問い合わせ言語については、後述するODMGの標準(オブジェクト問い合わせ言語、OQL; Object Query Language)が策定されているが、実際にはODBMSごとに差異がある。またオブジェクト問い合わせ言語による方法とナビゲーショナルな方法の、2つの方法のインタフェースの統合のしかたについても、ODBMSごとに違いがある。 ODBMSの検索速度は、関係 (テーブル構造) で実装する RDBMS (関係データベース管理システム) と比較すると、速くなる可能性がある。これはODBMSでは、RDBMSとは異なり、結合 (join) のような処理を行うことはほとんど無く、またオブジェクトの参照をたどるという直接的な方法で目的とするオブジェクトへの参照を取得することができるからである(「結合」はポインタをたどる過程の高水準の抽象であると主張されることがある)。 一般的には、オブジェクトデータベースのスキーマと、オブジェクト指向プログラミング言語は、同じタイプ定義を使う。ただし、ODBMSごとに微妙な違いがある。 オブジェクトデータベースを有効に使うと、マルチメディアを扱うアプリケーションソフトウェアを、比較的容易に開発することができる。マルチメディアの音や映像などのコンテンツは、オブジェクトとして扱われる。そのため、コンテンツを符号化(エンコード)したり復号(デコード)したりすることなどのコンテンツの種類に特有な処理を、そのオブジェクトのメソッドに任せることができ、アプリケーションソフトウェア側で処理する必要は無い。 多くのODBMSでは、バージョニングのサポートを提供している。オブジェクトの状態の全ての変更履歴(バージョンの履歴)を確認することができる。オブジェクトの各バージョンもまた、オブジェクトとして扱うことが可能である。 いくつかのODBMSではまた、アクティブデータベースの基本的な機能である、トリガや制約のシステム的なサポートを提供している。 特長と課題ベンチマークによる性能比較では、いくつかの処理形態において、ODBMSが、RDBMS(関係データベース管理システム)よりも、明らかに優れた性能を示してきている。その主な理由は、ODBMSはその多くの処理を、宣言的な指示に基づいて実行するのではなく、ナビゲーショナルな指示に基づいて、実行しているからである。オブジェクトデータベースに対するナビゲーショナルなアクセスは、ほとんどの場合、参照をたどって目的とするデータ(オブジェクト)を取得するという性能面で有効な方法で実装されている[3]。 ODBMSなどのナビゲーショナルデータベースのDBMSに対する批判として、参照をたどってデータにアクセスする手法は、特定の「探索経路」もしくは視点に対して最適化されている、との意見がある。この意見によると、汎用的なデータ操作言語(ODMGが策定したオブジェクト問い合わせ言語など)によるデータアクセスを行う場合、ODBMSのように参照をたどる手法は、RDBMSなどと比較すると、処理速度が遅く、またデータ操作言語で検索式を記述することも簡単ではない、というデメリットがある。このように、ODBMSのようなナビゲーショナルなDBMSでは、データベース構築時に想定していた用途に対してはアクセスが最適化され簡単になっているが、それは想定していなかったさまざまな用途でアクセスする場合のデメリットを犠牲にした上で実現されているという、見解がある。 (ただし参照ルートの最適化などを適用することができる可能性がある) 他に ODBMSに対して不利にはたらいているとみられる要素としては、多くのツールや機能について、相互運用性が低いことが挙げられる。RDBMSにおいては相互運用性をもつ多くのツールや機能がある。RDBMSでは、例えば、データベースとアプリケーションソフトウェアとの接続について業界で標準化されており(JDBCやODBC)、帳票作成ツールやOLAPのツールがあり、バックアップと復旧(リカバリ)の標準がある。またODBMSには、RDBMSと異なり、形式化された数学的な基盤がない。数学的な基盤がないことが、ODBMSにおけるデータ操作言語のサポートに関して、不利にはたらいているとの批判がある。 しかしながら、現在ではこうした批判は必ずしも妥当ではないようである。 いくつかのODBMS実装では、ナビゲーショナルなアクセスに加え、完全なSQLによるアクセスも提供している(例えば、Objectivity社はObjectivity/SQL++というソフトウェアを提供しており、これは同社製のODBMSであるObjectivity/DBにSQLアクセス機能を追加する。Matisseなどでも同様のことが可能である)。パラダイムの相違を吸収する使い方が必要となる。 実際に、オブジェクト指向におけるカプセル化の概念と、多くのデータベース技術の基本的な前提との間には、本質的に不整合な部分がある。オブジェクト指向のカプセル化の概念では、オブジェクトのデータは隠蔽されており、オブジェクトが公開しているインタフェース(メソッド)を通してのみ扱うことができる。一方データベース技術においては、データベース構築時に予めデータへのアクセスパスを想定しておくという発想よりも、構築時に想定していなかったアクセスパスによるデータアクセスも可能であるべきだとの前提がある。データベース中心の観点では、物事を宣言的な視点で認識する傾向がある。これに対し、オプジェクト指向の観点では、物事を複数のオブジェクトの動的なふるまいとして認識する傾向がある。こうした観点の違いは、オブジェクト指向とデータベースの間のインピーダンスミスマッチの一端である。 一部の人々は、オブジェクトデータベース技術は失敗であったとの見解をもっている。 しかし多くの人々は、オブジェクトデータベース技術の本質的な方向性は、現時点においても有効であると考えている。現在も、オブジェクトデータベース技術を含め、データベースの機能を密接にオブジェクト指向プログラミング言語と統合させる努力が、研究者のコミュニティと開発者のコミュニティの双方で続けられている。 標準化とネイティブクエリDBMSにオブジェクトを格納する移植性のあるアプリケーションソフトウェアを開発できるようにするための、複数の仕様を策定することを目的とした標準化団体として、ODMG (Object Data Management Group) があった。 ODMGに参加していた会員は、ODBMS開発企業およびオブジェクトリレーショナルマッピング技術の開発企業、研究者のコミュニティ、その他 ODMGの目的に関心をもった団体であった。 ODMGは、いくつかの仕様を策定し公開した。 2008年現在の最新バージョンは ODMG 3.0 である。 ODMG 3.0 は次の内容から構成される。
1990年代後半にオブジェクト指向プログラミング言語Javaが普及する状況があり、主なODBMS開発企業とオブジェクトリレーショナルマッピング技術の開発企業の多くは、ODMG Java言語バインディングの仕様を策定すべきだと主張した。 Java言語バインディングは、ODMG仕様に追加された[4]。 2001年に、ODMG Java言語バインディングは Java Community Process (JCP) に提出され、Java Data Objects (JDO) 仕様の基礎となった。 ODMGの参加企業は、Java Data Objects仕様の策定に専念することを決定した。 その結果、標準化団体ODMGは2001年に活動を停止した。 一方、ORDBMSにおいては、多くのオブジェクト指向の機能が、SQL:1999の標準に採用され規定された。 現時点では、実際のORDBMSによる、SQL:1999で規定されたオブジェクト指向機能の実装水準は、さまざまである。 2005年にクック、レイ、ローゼンバーガーが、ODBMSについて、ODMGとは異なる手法で取り組むことを提唱した。彼らは、ODBMSにODMGのような標準化されたオブジェクト指向のデータ操作のインタフェースを追加するという手法を放棄し、オブジェクト指向プログラミング言語(Javaや.NETなど)自体に、オブジェクトデータベースに対するデータ操作機能をもたせることを、提唱している。その結果として、db4oなどネイティブクエリを実装したODBMSがいくつか現れている。こうした動向と同様な動きとして、マイクロソフトが、2005年9月に統合言語クエリ (LINQ; Language Integrated Query) とDLINQ(LINQの実装)を発表した。LINQとDLINQは、マイクロソフトのプログラミング言語であるC#やVisual Basic .NETに、密接にプログラミング言語に統合されたデータベースクエリ機能をもたせる技術である。 2006年2月に、オブジェクト指向技術の標準化団体OMG (Object Management Group) が、ODMG標準の権利を取得し、ODMG 3.0を基にして次世代のオブジェクトデータベース技術を開発すること、およびそのためにオブジェクトデータベース技術作業部会 (ODBT WG; Object Database Technology Working Group) を発足させたことを、発表した。 ODBT WGは、オブジェクトデータベースのさまざまな面での技術的革新の次のような標準群を作成している。
関連項目
脚注
文献案内
外部リンク技術情報
オブジェクトデータベースの実装商用いくつかの商用のオブジェクトデータベースでは、試用版をダウンロードすることができる。
オープンソース・商用
オープンソース
|