最近、とつぜんふってわいたかのように『グラフデータベース』にハマってます。
これは、たぶん…丸山自身が1999年あたりから取り組んでいたことを、いとも簡単にあっさりと実現させてくれる可能性をもったデータベースだと確信すらしています。
僕がいま注目しているグラフデータベースは、こちら。
これを少しさわりながら、データ入力の効率化に、これまでに作ってきた「多種類情報資源相互参照システム」が使えないかなぁ〜と思ったところ、なんと！ これまでのシステムを根本的にバージョンアップさせるアイデアがグラフデータベースからもたらされました。
正直なところ、2016年になって「多種類情報資源相互参照システム」をバージョンアップさせることになろうとは、感動するほどのおどろきでした。
ということで、このブログはその感動を少しでもわかっていただければ…と、思って書き始めていますが、できるだけ簡易な言葉でかきますので、どうぞお付き合いいただければ、幸いです。
【第１世代多種類情報資源相互参照システム】
まずは一般的な、多対多のデータベースを考えます。
一般的なリレーショナルデータベースは、簡単にいえばエクセルの表のようなものです。A,B,Cとならぶ列の方向に、人物データベース（テーブル）ならば、整理番号（ID番号）、名前、ふりがな、性別、生年月日などの項目をつくり、1行方向に一人目、二人目、三人目…と、レコードを追加していきます。この人物テーブルとは別に団体テーブルを作ります。団体番号、名称、代表者、住所、などなど。
そして、この人物テーブルと団体テーブルという種類の異なるテーブルを関連付けます。一人の個人が複数の団体に関係性をもち、ひとつの団体が複数の人物と関係性を持つので、ここでは［多対多］の関連付けが必要となります。その際には、両方の関係性を記述するための関連付けのテーブルが必要です。関連付けテーブルには、人物ID、団体ID、関係性という項目を用意します。人物テーブルの人物IDと関連付けテーブルの人物IDをつなぎ、団体テーブルの団体IDと関連付けテーブルの団体IDを関連付けます。これにより人物と団体とが［多対多］の関連づけを持つシステムをつくることができます。
しかしこれには、とても大きな問題がありました。人物と団体だけでなく、場所や出来事、その他のアイテムを相互に関連づけるとなると、それぞれに［関連付けテーブル］を用意しなければなりません。しかもその多対多の関連付けテーブルは、２つの種類なら１つ、５つの種類なら６つ、６つの種類なら10こという具合に、多種類になればなるほど、その関連付けテーブルが増えてしまうのです。
これでは、ちょっとした変更に対してもとても大きな負担が発生します。
関連付けひとつとっても、固定化された関係性よりも、関係性にも始まりと終わりがあったり、様々な関係性の属性が生まれることもあります。そうした変更に対応するには、このシステムでは膨大な手数がかかってしまいます。
そこで、次に考えたのがこちら。
【第２世代の多種類情報資源相互参照システム】
最初の多種類情報資源相互参照システムは、まずは多種類の情報資源の共通部分を抜き出して、ユニティテーブルを用意します。このユニティテーブルは、情報の種類（タイプ）によって、それぞれ人物テーブル、団体テーブル、場所テーブル、出来事テーブルなど個別の項目を用意したテーブルを１対１で関連づけます。これにより、ユニティは種類によって多種類の情報を扱うことができるようになり、新しい情報資源の種類が増えても、このユニティテーブルと新しい情報資源のテーブルとを１対１で繋げばよいだけになります。関連付けも、１つのユニティテーブルをA、関連するBにもユニティテーブルを接続することで、相互参照する基本的な仕組みは１つの関連付けテーブルで実現できます。これならば、関連付けテーブルに後から属性を追加するのも簡単になり、メンテナンスの手間が大幅に削減できます。FileMaker Proで実現する場合は、情報の種類（タイプ）によって表示するレイアウトを変更することで、それぞれの種類の項目のみを表示させることができます。欠点としては、それぞれの情報種類のID番号に重複が生まれてしまうこともあり、レイアウト切り替えだけがたより…になるということがあります。（例えば、ひとつのユニティIDが、人物テーブルにも場所テーブルにも入力可能で、レイアウトの切り替えを間違えると、別の情報がリンクされてしまうことがあります）。
それでも、かなり有効に使えてきていて、このデータベース構造は実験用OPACに使っていたりします。
そして昨日、グラフデータベースを勉強している中で、なんとかデータ入力を効率化してやろうと思って、FileMaker Proを使ったシステムをつくろうとした瞬間に、それは起こったのでした！
【第３世代 多種類情報資源相互参照システム】
グラフデータベースが、ノード（点）とリレーション（線）でできているという特徴があり、Neo4jの場合は、それぞれのプロパティ（属性）も付与されています。実はそれをそのまま、FileMaker Pro というRDBで表現すると、上記の図のようになるのです。
ノードテーブルには、ノードIDとラベル（第二世代でいうところのタイプ）があり、関連付けのリレーションテーブ
ルにはノードA側ID、ノードB側のID、関連性があればOK！
正直なところ、「え！これでよかったのか。」という驚きです。
多種類情報資源は、ラベルの記述によって変更します。ここに、人物、団体、場所、出来事、アイテム…などなどの情報資源の種類を記入。さらにそれらの各項目は、ノードとノードプロパティテーブルを1対１で接続し、いわゆる入力項目は、必要に応じて、Key（キー：項目）とValue（バリュー：値）で、必要な項目と必要な分だけ入力する…という形式にすることができます。これで、人物データベース用の項目、団体データベース用の項目等などを、あらかじめ用意する必要がなくなるのです。データベース的な言い方をすれば、あらかじめスキーマ（データベース構造）を決めなくてもいい！…という画期的な「多種類情報資源相互参照システム」ができあがるのです。パチパチパチ！
一昨日の早朝におもいつき、早速FileMaker Proで実装中。この基本構造に加え、作業効率化のための項目も付け加えながら、システムを構築中で、そのシステムによってNeo4jの入力作業の効率（入力用のテキストデータ作成）の手間が大幅に削減される見通。
で…ここで疑問？？？FileMaker Proで実装できるなら、わざわざNeo4jを使わなくてもいいじゃないか？そう。単純な検索ならば、それでもよいのですが、そこはグラフデータベースの強い［グラフ理論による検索］を必要としているからなのです。これはFileMekerや他のRDB（SQL）では不可能に近い。
ということで、この感動（？）を少しでも共有できれば幸いです。
また、4月以降「グラフデータベース勉強会」を小さいながらも始めてみたいなぁ〜と思っています。興味・関心のある方は、ぜひ山中湖情報創造館のサイトをチェックしていてください。では、また。
平日は山中湖村の森の中にある図書館 山中湖情報創造館に、週末は清里高原の廃校になった小学校を活用したコワーキングスペースもある 八ヶ岳コモンズにいます。「わたしをかなえる居場所づくり」をイメージしながら、テレワークに加えて動画撮影やネット副業などにもチャレンジできる図書館／コワーキングスペースづくりに取り組んでいます。
コメント