RDBからXMLへの移行

bookmark/言語/XML

• http://www.xmldb.jp/db_contents/xpriori/original/toxmldb.html

例えば注文データにおいて新たに仲介業者情報を追加したいと思ったら、XMLツリーでは部分木をただ「接ぎ木」すればよいのだ。これがRDBモデルの場合、新たなテーブルを別に設計したうえで、さらに既存のテーブルには新たなテーブルと結合するための新規カラムを追加しなければならない。

これでは、RDBモデルをXMLモデルで再構築した意味がまったくない。なぜならRDBで行っていたJOINの数だけ、XMLモデルではXPathによる問い合わせを行わなければならないからだ。当然、データ構造の複雑度に比例して、アプリケーションコードは複雑になる。

また、スキーマ変更に対する耐性にも問題がある。この顧客データに新たに「地区データ」を追加したいと思ったらどうだろう。上記と同じ要領で要素を追加するならば、以下のように<地区データ>要素を追加すると同時に、<顧客>要素の配下にも<地区データ>要素と関連付けるための<地区ID>要素を追加しなければならない。つまり、単純にその情報を必要とするノード配下に部分木を「接ぎ木」するという操作では済まなくなってしまうのだ。ましてや、追加対象のデータが複数の顧客データにまたがっていたり、あるいは、追加する情報そのものが多くなってくれば、結局、スキーマ変更は煩雑となってしまい、XMLモデルの柔軟性を生かすことができなくなってしまう。

正規化されたテーブルをフラットなデータに

上記の例でも分かるように、RDBモデルのデータをそのままXMLモデルに移行するだけでは、XMLモデルの利点は生かせないのだ。

それでは、RDBからXMLへの移行に当たってどのような手順を踏めばよいのだろうか。XMLというと、とかくツリー階層であるという点が強調されるせいか、無理に階層構造を作ろうと考えがちであるが、なにも最初から階層構造を強く意識する必要はない。

特にXMLDBに格納するXMLデータであればインデックスを使用して検索を行うので、階層を持たないフラットなデータでも問題はないのだ。というよりも、無意味な階層を付けることは、アプリケーションからの問い合わせを煩雑にするだけで、これといったメリットはない。それならば、まずは正規化されたRDBのテーブルをJOIN句で結合し、最も単純なフラットの顧客データを作成してみよう

フラットなXMLに階層を追加する

ただし、コード 3ようなフラットなデータでは、扱う要素数が多くなってきた場合に、可読性が損なわれるという難点もある。該当の要素がどのようなカテゴリに属する情報なのかが分かりにくくなるためだ。また、ノード名の衝突を考慮する必要もある。そこで、後々のスキーマ変更に強いツリー構造を作るために、コード 4のように意味あるカテゴリの単位で少しずつ階層化を進めてみよう（「業種」と「職種」の親ノードを「回答」としたのは、アンケート回収アプリケーションを想定しているため）。

繰り返しではあるが、RDBとXMLとはまったく構造の異なるデータモデルだ。RDBのテーブル的思考をそのままにXMLデータを移行してもXMLの利点を生かせない。かといって、一気にXMLのツリー構造を定義しようとしても、慣れないうちはなかなかうまくいかないだろう。そこで、一度、正規化されたRDBデータをExcelワークシートで表現できるようなフラットなデータに変換してみよう。そこから徐々に階層構造を付けていくことで、ごく自然にXML的なデータモデルを作成できるはずだ。難しく考えず、まずは手元のRDBデータを本記事の手順に従ってXMLデータに移行してみよう。