［新・XMLとオブジェクト指向］
久しぶりのXML記事になりますが、忘れ去られてはいないでしょうか？タイトルも「新・XMLとオブジェクト指向」と題して新装開店することにしました。（何が変わったんだ？って聞かれそうですが...）今後ともよろしくお願いします。記念すべき第1回は、XMLに手を染めてからまだまだ時間の浅い筆者なりに思うところを書かせてもらいました。ご意見・ご感想、もちろん異論・反論も喜んでお受けします。例のごとく、原稿はXMLで記述しています。ブラウザにIE5.0+MSXML3をお使いの方は、こちらでもご覧いただけます。
注) MSXML3は次の方法でインストールできます。 まず、こちらのMicrosoftサイトの、コンテンツリストから"XML Parser Technology Preview Release"を選択して、msxmlwr.exeをダウンロードしてください。 次に、msxmlwr.exeを実行、終了したら%SystemRoot%\System32\xmlinst.exeを実行してください。
さて、今回はXMLをデータとして捕らえたときに、そのデータをどのように“貯めて”いくべきか考えてみたいと思います。「XMLとオブジェクト指向」というよりは、「XMLとDB」といった方がいいかもしれません。
2. XMLデータって？一口に言ってしまえば、XMLは構造化テキストドキュメントに過ぎません。そのため、XML文書を“データ”としてアプリケーション内で扱うためのAPIが存在します。DOM（Document Object Model）とSAX（Simple API for XML）と呼ばれるAPIです。前者はXMLの各要素それぞれをノードオブジェクトに割り当て、ノード間の関連でその木構造を表現するAPI、後者はXMLの要素ごとにイベントを発生させて処理を行うAPIです。両者について詳しくは書きませんが興味のある方には「XMLとJavaによるWebアプリケーション開発」（ピアソン・エデュケーション ISBNコード：4-89471-135-4）をお薦めします。
一般にアプリケーション内でXMLを更新系データとして扱う場合DOMを利用します。したがって、この文書で記述しているXMLデータとは、言い換えるとDOMオブジェクトであるということになります（正確にはDocumentオブジェクトですが、ここではノードオブジェクトの集合で表現されるドキュメント全体をDOMオブジェクトと呼ぶことにします）。以下、XMLデータ＝DOMオブジェクトとして読み進めてください。
3. 貯め方あれこれアプリケーション中のデータには一時的なデータと永続的なデータが存在しますが、一般にXMLデータは後者の永続データのしての役割を担うものです。であれば、XMLデータをどのようにして外部に保存するか、考えなければいけません。保存形態としては以下の3つが考えられます。
この3つの保存形態について考えてみましょう。
3.1. フラットファイルに格納一番簡単なフラットファイルへの格納、いわゆるXMLファイルです。一般的に拡張子.xmlでネーミングされています。
この方法は最も管理が簡単ですが、扱うXMLデータが同時多数のアプリケーションから更新されるような場合には、別途トランザクション管理の仕組みを考慮しなくてはならず、適切な保存形態とは言えないでしょう。 したがって、この方法はシステムコンフィグレーションやアプリケーションデータのようなスタンドアローンの読取専用の保存形態としての活用が期待されるでしょう。
3.2. RDBに格納既存のデータストレージとして利用されているRDBへの格納です。これまでに蓄えてきた資産（データ、ノウハウ、アプリケーション）の再利用を考えれば、当然、XMLデータもRDBに格納していこうと考えるのではないでしょうか。
さらに、現在では各RDBMSベンダーがXML対応モジュールをリリースしており、ユーザーにとっても比較的容易に既存データをXML化して、システム中で利用することが出来るようになっています。
しかし、RDBへの格納では、XML本来の特徴を十分に生かしきれません。その理由は、木構造のXMLデータと表形式のRDBデータのギャップにあります。XMLデータのRDBへの格納方式として、以下の2つの典型的な例を見ながら考えてみます。
XMLの要素をそれぞれテーブルのカラムにマッピングして格納する方法です。
この格納方法では、各要素が一つのデータとして意味を持つことになり、XMLの特徴の一つである、タグによるコンテンツの意味付けが生かされることになります。
しかし、もう一つの特徴である拡張性が失われてしまいます。この格納方法は各要素とテーブルカラムが一意にマッピングされているので、例えば要素が一つ増えただけでも、DBスキーマの再設計が必要となり、DBレベルで柔軟な対応ができません。（もちろんDTDを定義した、検証済みXMLデータを使用するのであれば、拡張性を意識する必要はないかもしれませんが、将来にわたって変更が起こりえないとは限りません。また、変更・拡張に柔軟に対応できることが、XMLという技術を使う理由の一つでもあるのではないでしょうか。）
また、木構造をなすXMLデータの各要素はRDB上では複数のテーブルにマッピングされてしまうので、ドキュメントの取得時に結合処理などの内部処理が発生し、パフォーマンスの低下は否めません。
3.2.2. ドキュメント全体を格納 では、XMLドキュメント全体をテキストデータとして一つのカラムに格納する方法はどうでしょうか。
この格納方法では、XMLの拡張性には柔軟に対応できます。しかし、ドキュメント全体をテキストデータとして認識するため、その内容、つまりタグによる意味付けは意識されません。したがってコンテンツを意識した検索もできないことになります。
このように、XMLデータをRDBに格納する方法では、XMLの拡張性とコンテンツの意味付けの2つの特徴を十分に生かしきれないものとなってしまいます。
3.3. ODBに格納 最後にオブジェクト指向データベース（ODB）に格納する場合を見てみましょう。
オブジェクト指向DBへ格納すると、XMLの特徴を十分に発揮できます。ODBではオブジェクトとその関連がそのまま永続化されるため、XMLデータ、つまりDOMオブジェクトがそのままDBに格納されます。そのため、拡張性の面から見れば、要素の変更はオブジェクトおよびその関連の追加・削除を意味し、ODBでは問題なく対応できます。また、要素ごとにノードオブジェクトが生成されるため、要素による意味付けにも対応できます。そして、DBからのドキュメントの読み取りもRDB（要素ごとのテーブルマッピング格納）に比べ高いパフォーマンスが得られます。
4. 賢く貯めようここまで、幾つかの保存方法を見てきましたが、必要に応じてその保存方法を使い分ける必要がありそうです。
トランザクション管理を必要としない読み取りデータでれば、フラットファイルでの保存が適しています。 既存の資産を再利用したい、かつ、扱うXMLデータのスキーマが確定しているのであれば、RDBを利用する価値は十分にあるでしょう。 そうではなく、XMLデータを利用するけど、そのスキーマが流動的であるなら、スキーマの変更に柔軟に対応できるODBを利用するべきではないでしょうか。
より柔軟なシステムを構築できるように、XMLデータの賢い使い方だけでなく、賢い貯め方も考えてみてはいかがでしょうか。
| © 2000 OGIS-RI Co., Ltd. |
|
