はじめに
この連載は、第1回に紹介したDBMSの3階層構造における「アーキテクチャと実装」についての技術の紹介から始まり、前回は中間の階層である「データ・モデルとデータ型」を起点にJSONをDBMSで扱う方法を議論しました。今回は、JSONと同様、表以外のデータモデルのひとつとして語られることの多いグラフを題材に、DBMSの3階層構造によるインターフェイスと実装の分離という指針がどのように適用できるか考えてみます。前回までの連載をまだお読みでない方は、第1回をご一読いただくことで今回の議論がわかりやすくなるかと思います。
なお、本連載で例として挙げるデータベースはオラクルが提供しているものが多いですが、オラクル製品を使っていない方にも参考にしていただけるように解説します。
対象読者
この連載では以下の読者を想定しています。
- データ資産を活用する、新しいアプリケーションの構想や設計を担われる方
- データ基盤の運用を担われている方や、今後検討される方
- 新たに開発するアプリケーションの、最適なデータベースをお探しの方
- 目的別データベースから、価値ある情報を素早く引き出す検討をされている方
グラフというデータモデルの特徴を再考する
グラフ・データベースと呼ばれるDBMS（これを正確に表現するため以降では「グラフDBMS」と表記することにします）は10年以上前から市場に存在しており、今では多くの開発者がその概要、たとえばグラフという直感的なモデルや「辿る」処理の性能メリット、について見聞きしたことがあるかと思います。その一方で、実際のシステム、とりわけ可用性や安定性が求められるビジネス・クリティカルなシステムでグラフDBMSが採用されている例は今のところ非常に稀です。
これはなぜでしょうか。グラフというデータモデルはDBMSで扱うビジネス価値がないのでしょうか。または、長らく注目されているグラフのユースケース（金融の不正検知、製造のトレーサビリティ分析、犯罪や税の不正の調査など）には障壁があるのでしょうか。これらの疑問について、特定のグラフDBMSの実装に関する議論にならないよう、まずはグラフというデータモデルについてその特徴を再考してみます。
グラフというデータモデル
グラフDBMSが扱うデータモデルには、一般にRDF（Resource Description Framework）とプロパティ・グラフの2種類があります。これらはどちらもグラフと呼ばれることがある一方で、データモデルが異なるだけでなく、APIも実装も異なっていることが多く、同時に議論することが難しいです。そこで、今回はプロパティ・グラフのみに着目することにして、多少正確さには欠けますが、これを「グラフ」と呼ぶことにします。
例えばOracle Graph（Oracle Databaseの一機能）やAmazon Neptuneは上記2種類のグラフの両方を扱うために、それぞれに対する別々の実装を持っています。
グラフは以下の図にあるようにノードとエッジに加えてそれぞれのプロパティ（Key-Valueペア）で構成されていて、グラフを利用した通常のモデリング手法では、ノードがエンティティ（＝物や人など、一意の対象物としてみなされるもの）、エッジがエンティティ間の関係性を表現するように割り当てます。ノードが「自分の情報」のみを持っているのに対して、エッジは始点と終点の情報（ノードID）も持っているという構造の違いがあるわけです。
表とグラフとの違い
それでは、表を用いたモデル（＝リレーショナルモデル）と対比してみます。ひとつのノードとそのプロパティについては、次の図のperson表やdog表のように、表の一行に格納できることは容易に理解できます。ではエッジはどうなるかというと、実はこれもリレーショナルモデルでは表に格納されることになります。そうすることで、次の図のhas_dog表のように1対多（さらに多対多）の関係が表現できます。このように、リレーショナルモデルではエンティティも関係性も表に格納しているのに対して、グラフモデルではノードとエッジという２種類の構造を使い分けることで、より直感的なモデリングを可能にしていることがわかります。
