大量の非定型データを管理するのに適したRDFデータベース

ユビキタスコンピューティング時代において、大量の非定型データを管理するのに適したRDFデータベースについて紹介します。

新しいデータモデルの必要性

まず、特徴的な例として、文房具などのカタログをデータベースで管理する場合を考えてみましょう。文房具としては、鉛筆やノートといったさまざまな種別が管理対象となります。これらは、どれも型番、名称、価格、メーカーといった属性を持ちますが、一方では、鉛筆は、色、硬さ、...、ノートは、サイズ、ページ数、表紙の色、...というように、種別ごとに異なる属性を持つことになります。このように異なる属性集合を持つ複数種別の対象を関係データベース（RDB)で管理する方法として、いくつかのよく知られた方法があります。

ひとつは、種別ごとに一つの表を用意するという方法です。

ただし、このままでは、複数種別の文房具の合計金額などを集計するにむいていませんから、すべての種別に共通な名称、価格、メーカーといった属性(列）は別表にするのが理想的な設計でしょう。

しかし、この方法では、鉛筆と消しゴムの組み合わせなどの複合商品がある場合には、表の数が組み合わせの数だけ必要になることや、きれいに種別の分類が行えない場合には、困ってしまいます。

この問題を回避するため、すべての種別の属性をそれぞれひとつの列として表現する方法が考えられます。

このような表現では、各種別がもつ属性集合の和がどんどん大きくなるにしたがって、各レコードが使用している属性は、そのうちのごくわずかになってしまいます。また、取り扱う種別が追加された場合には、その新しい種別が持つ属性をテーブルに追加しなければなりません。

そこで、窮余の策として、列名には意味のある名前はつけないで、その列に何を格納するかを種別ごとに決めるという方式が採用されることもあります。

種別ごとに列1、列2、...が何を表すのかは異なるので、それを管理する別のテーブルが必要になります。

この表を処理するプログラムは、製品の種別から、後者の表を参照して、前者の表のそれぞれのレコードにおいて、列１が何を表しているかを知ることができますが、表の定義をみただけでは、個々のレコードにおいて、列1の値が何を表しているのか知るすべはありません。

つまり必ずしも二次元の表の形にきれいに格納することはできないが、それらを一まとめにして管理したいような対象（データ）が少なからず存在する。それを無理に二次元の表の形に押し込むと、どこかに歪が生じて、開発、実行、運用に余計な負荷がかかる。また、そのデータが何を表しているのか明確になっていなければ、そのデータを活用することはできない。ということです。

このように二次元の表にはおさまらないけれど、何らかの構造を持ったデータを「半構造化データ」と呼びます。ユビキタスコンピューティング時代において、センサーネットワークや、モバイル装置といったデータソースからさまざまなデータが取得できるようになると、データソースごとに得られる情報の形式は異なる場合があるため、それらをまとめて単純な二次元の表に格納することは困難です。また、ひとつのデータソースをとってみても、センサーや装置の改良によって、時間経過に従って得られる情報の内容や精度が変化する場合もあります。

また、別の視点からみると、いかにテクノロジーが進歩しようと、5年分のデータは5年かけないと収集することができません。ある瞬間に、過去のデータを使って、新しいビジネスを始めたいと考えても、その時点で、データが蓄積されていなければ、ビジネス機会の損失に直結します。しかし、逆に5年後にデータがどのように使われるかを予測して、それに必要な形式でデータを蓄積することは不可能です。無理に表の形に格納できるようにデータを編集すると、そこに情報の損失が発生し、結局、蓄積してはみたものの、使えないデータとなりかねません。このような事態に陥らないためには、できるだけデータが発生したときの構造をそのまま蓄積する必要があります。

RDF(Resouce Description Framework)データベース

このような半構造化データを永続的に管理すためのひとつの解としてXMLデータベースがあります。ただし、一般に木構造によって表現されたXML文書では、管理対象間の関係を記述しにくい場合もあります。一方、RDF(Resource Description Framework)のデータモデルは、トリプルと呼ばれる三つ組を基本関係としたグラフ構造によって管理対象を表現することができるため、管理対象間の関係をより柔軟かつ明確に表現することができます。（ここにRDFの平易な解説があります。）また、レイヤーケーキと呼ばれるRDFの階層アーキテクチュアに含まれるオントロジー機能(OWL)を使用して、これらの関係を詳細に規定することができるのも、RDFの特長のひとつです。

RDFデータベース(RDFDB)は、このRDFのデータモデルの基本要素であるトリプルを永続媒体で管理するシステムです。アプリケーションプログラムは、RDFDBが提供するライブラリを用いて、次のような操作を行うことができます。

• RDFトリプルの追加および削除
• 問い合わせ言語を用いた格納されているトリプルの検索

Rinza RDF Repositoryは、このRDFDBの実装の一つで、レイヤーケーキのRDF M&S部分に相当します。今後は、標準化の動向や実フィールドでの適用からのフィードバックを元に、機能追加をしていく方針です。

RDFデータベース（RDFDB）と関係データベース（RDB）の連携

あくまでもRDFDBはRDB（あるいは多次元DB）を置き換えるものではなく、互いに補完する関係にあるものです。これはセマンティックWebの提唱者であるTim Berners-Leeも、同じような所見を述べています。（日本語抄訳）)二次元の表に素直に格納することのできるデータは、RDBの表として格納すべきです。RDBの表として格納すれば、他の表との関係演算を行うことや、列を指定した集計などを効率よく行うことができます。一方では、二次元の表として格納するには無理のあるデータは、RDFDBに格納することで、それぞれのデータが個別に持つ属性も表現することができます。また、システムの拡充に伴って、データの構造や属性が変化した場合にも、柔軟に対応することができます。このようにRDFDBとRDBを相互に補完するように利用するためには、RDFDBとRDBの間のデータ変換や、データ共有が必要になります。このデータ変換・共有のやりかたとして、次のような二つに大別することができます。

• RDBまたはRDFDBの一方がマスターデータベースとなり、もう一方にデータの複製を作成する。
例えば、RDBに新たなデータが投入されたことを契機として、そのデータのコピーをRDFDBにも格納する（あるいはその逆）。もしくは、毎日定時に、RDBに格納されたデータの複製をRDFDBに転送する（あるいはその逆）。
• ひとつの業務処理単位の中で、RDBに含まれるデータ、およびRDFDBに含まれるデータの双方を参照する。

前者の方式は、一般には、いわゆるデータ移行ツールやデータ変換ツールによって実現されます。代表的なものとしてDataSpider Servistaがあります。tyzohより提供（予定）のRinza RDF Repository用のアダプタを用いると、DataSpider Servistaによって、さまざまな形式のデータベース、ファイル、ネットワークプロトコルとRDFデータの間で、相互にデータ変換を行うことができます。

後者の方式としては、既存のRDBの表をRDFデータとして取り扱うことのできるRDBラッピングがあります。RDBよりもRDFDBのほうが制約が緩いので、RDBの表をRDFデータとして自然に解釈することができます。具体的には、特定の表の二つの列を指定して、それをRDFステートメントして取り扱うというものです。（列の一つは、RDFステートメントの主語に対応し、もう一つの列が目的語に対応します。この表によって表現されているこの二つの列の関係が述語に対応します。）RDBラッピングによって、アプリケーションプログラムは、RDBの表に含まれるデータもRDFDBデータとして取り扱えることで、統一されたRDFの枠組みの中でアプリケーションを実装することができるのです。

まとめ

RDFDBとRDBは互いに補完する関係にあります。データの特性やその利用方法を考慮して、どちらのデータベースで管理するのが適切であるかを判断すべきです。また、RDFDBとRDBにまたがったデータ処理を行なうために、データ連携・変換ツールや、RDBラッピング機能を活用していくことが、ユビキタスコンピューティング時代におけるデータ利活用のあるべき姿でしょう。

連絡先

日本ユニシス株式会社
総合技術研究所 先端技術部
川辺 治之

コミュニティの人々 | ソフトウェア | 技術紹介 | 適用分野 | Tyzohとは | ご意見お問い合わせ

Copyright (C) 2004-2011 Nihon Unisys, Ltd. All Rights Reserved.
Powered by Movable Type Open Source