RXDB

次期基幹システム(2)で紹介したシステムコンセプトを、
もう少し詳しく書きたいと思います。
まずは、RXDBから…

RXDB

　ビジネスで取り扱う大部分のデータは、値単独で存在するのではなく、データを格納する構造と一体を成しています。そして、値の変化を扱うことは簡単ですが、構造の変化を扱うことは非常に厄介です。私の在籍する会社は不動産業を営んでいますが、例えば、こんなデータが厄介です。
　不動産（賃貸住宅など）には、交通という属性があります。これは最寄駅へのアクセスを示すものであり、具体的には「JR横浜駅徒歩5分」というようなデータです。一見簡単に扱えそうなデータですが、このデータの構造は変化します。例を挙げてみましょう。

1. JR関内駅徒歩5分。または市営地下鉄関内駅徒歩4分。
2. JR逗子駅より京急バス15分。バス停葉山大道下車徒歩3分。または京急新逗子駅からバス13分にて葉山大道まで。

　つまり、それぞれの属性が対象の不動産によりN個出現するということです。さて、このようなデータをどのように扱うべきか？

　ここで論点を明確にしますと、私は伝統的情報処理技術（RDBなど）によっていかに実装するかを論じたいのではありません。さまざまな技術を用いていかにエレガントに実装できるかを論じたいのです。つまり、このようなデータをRDBで実装すること自体は簡単です。最も単純な方法は、文字列の固まりとして記録する方法。ちょっと複雑にしてテーブルを分割する方法などが考えられますが、このような方法はメンテナンス性やデータ処理の柔軟性を失わせたり、データベースオブジェクトやアクセスロジックを複雑化させてしまったりします。これをどう回避するか？ ということを考えていきたいのです。

　そこで私はXMLの処理技術に注目しています。
　XMLは、多次元構造を持つデータをエレガントに表現できる手段です。より正確にいうならば、XMLにより記述できるツリーというメカニズムは、多次元なデータ構造を表現することができます。そして、多次元構造を表現できるメカニズムは、RDB（2次元）を遙かに超えるデータ構造のバリエーションを扱うことできます。
　先程の交通をXMLで記述してみましょう。RDBよりスマートに表現できていませんか？

　まあ、スマートとか、エレガントといったことは主観によるでしょうが、XMLは多次元、RDBは2次元である事実は明かです。ここに疑問を感じる方は、さまざまなデータ構造をXMLでモデリングしてみると、多次元の良さを実感できると思います。
　また、多くのRDBMSが大きなコストによりOLAPなどのサービスを提供することに比べて、単なるプレーンテキストであるXMLは、実に安価な多次元データベースといえます。
　しかし、いいことばかりではなく、メモリやプロセッサなどのリソースに関する制約との兼ね合いや、検索などのパフォーマンスに関する課題など、実装においてはいくつかの課題解決が必要となるでしょう。

　以上から、私は現在の技術レベルにおいて最良の選択は、XMLを扱えるRDBMSにより、2次元と多次元の良いところをバランス良く活用するということです。
　例えば、SQL Serverにおいては、構造変化の少ないデータ（硬度なデータ）に対しては通常のRDBの方法論でアプローチし、構造変化が起こるデータ（軟度なデータ）には、XML型により処理するというアプローチです。
　私はこれらのことを称して、RXDB(Relational & XML Database)と呼んでいます。