いま知るべきオブジェクトデータベースの世界（1）

オブジェクト指向の開発、そしてRDBの限界

オブジェクトデータベースのもう1つの要件

　ここからは異論のあるところかもしれませんが、オブジェクトデータベースのもう1つの要件について、私見を述べさせていただきます。それは「オブジェクトデータベースは、クラスのインスタンス間の関係を含めた静的な構造のみにフォーカスすればよいのか」という点です。

　データモデリングの本には、「データ間の関係とは、ビジネスロジックである」と説明している場合もあります。つまりこれは、データとデータの関係には、物理的な構造だけで表現できないものがあることを意味しています。

　データ間の関係を表現するときに、「カーディナリティ」（日本語では無理やり濃度と訳します）という概念があります。

　「カーディナリティが1対多の関係である」と表現されていても、1の方にゼロはありえるのか、多の方の最大値は何かなど状況によってバリエーションがあります。これらは静的な構造というよりは、ある時点での動的な状態です。その状態を記述するものは、構造プラスその関係に付随する属性値だったりします。

　例えば、「あるエンティティとあるエンティティの間に1対多の関係があり、多の方の最大値は10である」といった記述です。最大値が10といった場合に、その値は、状況により0から10までの値を取り得ることになります。そして最大値が存在する場合には、ある状況下でその値を超えないような仕組みが必要になります。これを、一般的に「制約」と呼びます。

　さらに、存在しないエンティティを参照できないという制約も考えられます。これは、一般的に「参照整合性制約」と呼ばれます。

　これらの制約を表現するには、何らかのロジックが必要となり、その記述には、プログラミング言語が必要になります。そして、データの各属性についても、データの型というものがあり、データベースシステムがその型のチェックを行ってくれると便利です。これは想定しない値が入ることによる誤動作を防ぐ自己防衛的な意味も含まれます。その型チェックも、整数や文字列といった単純なチェックもあれば、ある一定のパターンの文字列でなければならないなど、複雑な型チェックが必要なケースなどさまざまです。

　現存するオブジェクトデータベースシステムのほとんどは、永続データの生成、取得にのみフォーカスし、上記のロジックが必要な部分に関しては、言語側（C++、Java、Smalltalkなど）に頼る形態が主流です。

　一方、プログラム言語とオブジェクトデータベースは不可分と考えて、データベース操作を含めたロジック記述用の言語系も含めた実装もあります。オブジェクト指向の大原則が、データと振る舞いのカプセル化であるということを念頭に置けば、データベースといえどもデータの延長にすぎず、それは単に永続性という属性があるだけで、揮発性のデータとそれ以外は大きくは変わらないと考えると、この発想の方が自然に思えます。

　以上の説明で、オブジェクトデータベースというものがどういうものであるか理解できたでしょうか。

リレーショナルデータベースとオブジェクトデータベースの差異

　次に、リレーショナルデータベースと何が違うかについて、ここでは最も重要な差異についてだけお話します。

　まずは、またWikipediaからの引用です。

　この文章がほとんどのことを説明していますが、また少し補足してみます。

　リレーショナルデータベースとオブジェクト指向言語を使ってアプリケーションを開発する際には、それぞれで利用している2つの言語を駆使しながらプログラミングしていく必要があります。これは、人間の会話に例えるとデータベースシステムとの会話の際には、必ず通訳を通して会話をする必要があるということに例えられるかと思います。もちろん、オブジェクトDBを使っても、問い合わせ言語がまったく必要ないということではありません。

　しかし、必要なオブジェクトモデルがメモリ上に構築されたあとでは、ほとんどのアクセスは、オブジェクト指向言語が定めたシンタックスとセマンティクスによって実現されます。これは、まったく継ぎ目のないものなので、なんの抵抗もなく記述できます。

　一方、リレーショナルデータベースを使う場合は、データベースにアクセスする際には、どんな場合でも必ずSQL文を記述する必要があります。ここに大きな抵抗が発生します。

開発生産性とインピーダンスマッチの解消

　大分前の個人的な経験で恐縮ですが、あるときアメリカ人の講演を通訳することになりました。英語を聞いて日本語でしゃべるというのは、想像を超えて疲労困憊（こんぱい）するものでした。文字通り、講演の最後の方は、頭が真っ白になったのを覚えています。

　完全なるバイリンガルであれば、こんなこともあまり苦にならないのかもしれませんが、開発者の世界であっても、オブジェクト指向言語とSQLの両方が得意である開発者はそういないという現実を考えれば、ほとんどの開発者は、相当苦労されているのではないかと思います。

　開発者にとって、プログラミングに集中できるか否かで、生産性はものすごく大きく変わってきます。この抵抗、つまりインピーダンスミスマッチを解消する作業は、退屈でうんざりする作業ですので、集中することが非常に難しいです。

　さらにこのインピーダンスミスマッチを解消する作業は、完全に開発者の裁量に任されてしまっています。段取り力、そしてリレーショナルデータベースのクエリエンジンの詳細知識の有無を含めた性能チューニングのスキルといった開発者の力量で、作業効率、実行効率に雲泥の差が出る可能性が高いです。

　これでは、アプリケーションエンジニアはビジネスロジックに集中し、性能を含めたインフラ的な領域はデータベースエンジニアが担当するという、ある種の分業体制がうまく働かないということになります。

　つまり、オブジェクトモデルを構築する際に、最初に必要なSQL処理を連続で行うのがよいのか、処理のある区切り単位で必要なオブジェクトモデルを構築するのがよいのか、あるいは、SQLを駆使し、非常に複雑であるが1回で結果が返ってくるクエリを構築するのがよいのか、要件次第で最適解は変わってきます。そういうことを意識できていない開発者がプログラミングを行うと、とんでもなく効率の悪いやり方で処理を記述してしまうかもしれません。

2/3

Index
オブジェクト指向の開発、そしてRDBの限界
	Page 1 オブジェクトデータベースとは 永続化と直列化：オブジェクトデータベースが持つべき必須条件 インスタンスをメモリに展開」の意味
	Page 2 オブジェクトデータベースのもう1つの要件 リレーショナルデータベースとオブジェクトデータベースの差異 開発生産性とインピーダンスマッチの解消
	Page 3 オブジェクトデータベースの課題

いま知るべきオブジェクトデータベースの世界

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）