XML総合情報サイト | 効率的なXMLデザインとは | XMLデータベース(XML DB) 総合サイト

XML技術

効率的なXMLデザインとは

2004年8月23日更新
三井情報開発株式会社
鉢蝋吉久

はじめに

NeoCoreサポートセンタを運営し、様々なご質問をいただき日々回答をさせていただいております。まだまだ新しい分野ということもあり、十分なサポートをご提供できていないのではと、精進を心がけています。

いただく、ご質問の中に「どのようにXMLを設計すればよいのか？スキーマレスとはいってもアプリケーションがどのようにXMLを使用するのかはあらかじめ設計する必要がある。」といったものを受け取ることがあります。

NeoCoreXMSはXMLであればすべてDBが受け入れますので、XMLの変更には非常に柔軟に対応することは可能ですが、根幹となるXMLデザインがどうなっているかは少なからず開発に影響を与えます。

ここでは、NeoCoreXMSの特性を踏まえて、どのようにXMLデザインするべきかを簡単な例をあげて一緒に考えさせていただきたいと思います。もちろん設計上や他の要件による制約もありますので、なにが一番よいデザインであるかを決めることは難しい問題です。少しでも皆様の開発の手助けになれば幸いです。

XMLの特徴

いまさら述べるまでもありませんが、RDBで開発してきたものをXML DBで開発するには以下のXMLが持つ特徴を生かしたいと考えられていると思います。

XMLを利用してデータモデルを記述すると、直感的なやり方で記述することができます。それは以下の点のような特徴を持つからです。

● 半構造性

データ単位（RDBでいうレコード）でデータ項目が揃っている必要はありません。情報が存在するときに制約無しに表現ができます。普段は存在しないデータが特定条件のときにN個現れるという場合には有効です。

● 柔軟性

データの長さに対する制限はありません。各データは必要に応じたサイズを利用できます。

● 拡張性

データ構造をあらかじめすべて決定しておく必要はありません。変更を避けるように設計するのではなく取り込めるように設計することができます。

XMLの表現方法

XMLを構成する以下の4つが組み合わさって表現されます。

● タグ

「データ」が何であるかを定義するものです。データの定義がわからなければ「データ要素」が何であるかがわからなくなります。XMLではタグでデータに意味を持たせます。

● 属性

データ要素についての情報やその解釈方法をあらわします。XMLのデザインについてしばしば議論され、明確な方向性が定まっていないのが、この属性のあらわし方です。デザインする上では、タグと属性のポリシーを統一化させておくことが、XMLの可読性をあげるという面では有効と考えます。

※個人的には、あまり属性を使ったデザインは使っていません。データが何であるかを表すことについてはタグと属性の境界があいまいであり、XML階層を深くすることを嫌ったとしか思えないXMLが多いからです。

● データ要素

これまで「データ」として扱ってきたものです。

● 階層

タグ、属性、データ要素を用いてそれぞれのデータ項目が記述できました。データをすべて一度に記述するには階層構造を用います。個々のデータの関係をカテゴライズし、階層構造でデータの定義を表現していることを意識します。

XMLデザインサンプル

商品情報を例に取って考えてみましょう。商品といってもいろいろなものが想定されますので、PCを例に取ってみます。まずは、PCの商品情報の構成要素を洗い出してみます。

・名称

・品番

・メーカー名

・ CPU

・ HD

・ RAM

・バンドルソフト

・価格

これらをcomputerというタグで始まるXML設計をしてみましょう。

例1

これはすべてを1行でPCを表現しています。また、HDやRAM、priceといったものには、単位と値が混在しています。

例2

<computer>

    <name>name01</name>

    <maker>maker01</maker>

    <CPU>Intel01</CPU>

    <HD>40</HD>

    <RAM>40</RAM>

    <os>Windows2000</os>

    <price>248000</price>

</computer>

DB（NeoCoreXMS）にとってはどちらのXMLであっても格納可能ですし、検索にかかるコストもほとんど同じです。

それでは、PCの登録台数がどんどん増えていった場合を考えてみます。

検索にヒットするXML文書が増加すると、データの転送速度が増大します。そこで必要なデータのみを抽出することにしますが、例1では対象行が全て抽出されます。（検索結果から必要な属性の値のみ抽出することは可能です）

osがWindows2000のnameのみを抽出したいという場合には以下のように記述しますが、例2の方が効率的です。

【例1】/ND/computer[@os='Windows2000']/@name.text()

【例2】/ND/computer[os='Windows2000']/name

XML構造が複雑になればなるほど、このような状況が予想されます。例えば、HDだけでは何を意味するか分かりませんので「単位」を追加する。「回転数」「接続I/F」を追加するとしていきます。

ところがosがWindows2000のPC名を検索するにはこのHD関連の情報は不要なのです。不要なものを処理しようとすれば、その分処理に時間がかかってしまいます。

つまり、どのような処理(Query)を行うのかを、意識した設計が必要となります。また、実際のQueryの実行であっても、取得するデータ量が小さくなるようにすることを意識します。

次の例では、RDBのjoinの考え方をXMLでも行うことを考えてみます。

最初の例のPCの注文情報のデータを考えます。注文情報の情報としては以下のものがあります。

・注文ID

・注文日付

・注文者名

・ PC名

・個数

・単価

・金額

・発送先

・注文状態(受付、確定、発送済み)

        <name>ネオコア
太郎</name>

        <addr>住所</addr>

        <tel>03-1234-5678</tel>

        <email>taro@neocore.jp</email>

    </orderInfo>

    <item>

        <PC>デスクトップPC1</PC>

        <単価>178000</単価>

        <個数>1</個数>

    </item>

    <item>

        <PC>ノートPC1</PC>

        <単価>228000</単価>

        <個数>1</個数>

</item>

</order>

注文者の詳細情報やPCの情報をどこまでこの注文情報の中に含めるかが、処理速度の面で差が出てきます。RDBでの開発でも同じですが正規化しすぎたデータは逆に処理効率を落としてしまいます。「注文情報」としたときに、必要な情報は１つのツリーやレコードに納まっている方が処理速度が高速になるのはご理解いただけると思います。

また、このようなログ型の情報ではマスタの変更を注文情報に反映するのではなく、そのトランザクションが発生した時点でのデータを保持しておきたいという要求も多くあります。

PCに商品IDを追加して、coumputerとorderでデータを管理しているXMLを設計してみます。

<computer ID="PC001">
<name>name01</name>
<maker>maker01</maker>

    <CPU>Intel01</CPU>

    <HD>40</HD>

    <RAM>40</RAM>

    <os>Windows2000</os>